1990 · System 3

Last Ninja Remix

This minisite awaits a maintainer’s check. A model this site has not proven yet worked on it (one whose name was not recorded), so its claims have not been tested against the game (how the check works). It is not complete either: 1 of its 7 parts is analysed, and 99.6 % of that is explained. Clone https://github.com/gamesexplained/gamesexplained and follow kit/START.md to continue games/c64/last-ninja-remix to Silver.

01 · Movement boundaries

The scenery and the walking limits are separate

Central Park stores collision lines apart from its pictures. At an area change, the game expands short chains into endpoint records used by the movement tests. Choose an area and highlight a segment to see that geometry.

Coordinates from the original collision compiler. Orange lines have a nonzero action field; blue lines have zero. This view shows movement geometry, without the scenery or the ninja’s collision dimensions. The compiled records cover 18 areas; two lists are empty. Compiler $B950 · Encoded lists $9D8A.

02 · Combat timing

An enemy meter rebuilt from elapsed ticks

When an opponent returns, an eligible path calculates its meter from elapsed game ticks. The meter stays zero until tick 96, then grows by one for each group of 32 ticks, up to 44. Move the slider across those boundaries.

The subtraction uses a 16-bit counter that wraps. This control shows the meter calculation when an opponent is eligible to return. Fight outcomes and spawn rules also depend on other state. Calculation $B3D6.

03 · Sprite browser

A ninja assembled from small images

Animation frames place several sprite components around the actor. Each component can use a compressed image. Browse the 162 images from Central Park and inspect the tokens that expand them.

Encoded bytes
Actual sprite bytes from $CF98 onwards. The colors are illustrative. The checkbox chooses a display interpretation; the captured images contain pixel bits, without a palette.
04 · Inside the game
Compressing empty space
Most space around a limb or weapon is empty. The decoder replaces short runs of zero bytes with one token. An escape token preserves literal values that would otherwise look like commands.
TokenOutput
$68 followed by xOne literal byte x
$69–$6FOne to seven zero bytes
Everything elseOne literal byte
The pointer table at $CE54 stores biased addresses: add $0E54 to obtain the source location. All of its records expand to 63 bytes, the bitmap content of a C64 sprite.
The stopping condition
At $BF69 the decoder compares the output count with 63 and continues while it is smaller. It writes an entire zero run before that test. The captured streams end at exactly 63; every captured record ends at the next pointer boundary.
Evidence: decoder $BF3F, pointer table $CE54, and independent expansion of all 162 records from the gameplay capture.
Central Park features
Explore an isometric park, fight opponents, collect objects and solve puzzles, with animated characters and music. This contribution covers Central Park; later levels remain open work.
Reference screen
The ninja in Central Park
Central Park gameplay reached from a hard-reset disk boot with trainer cheats disabled.
Analysis in progress
The Source tab is built from this gameplay snapshot. Imported Ghidra annotations seed the coverage and verification work needed for Silver. See About for scope, provenance and open work.