Jumper

“Jumper” is a two-dimensional dodging game in which the player moves a character sprite around the screen while avoiding two scrolling rows of obstacles. The player uses keys 5–8 for movement, and reaching row 2 awards 10 points while colliding with an obstacle ends the current life. Five user-defined graphics are loaded via a DATA/POKE USR loop at startup: four form the obstacle tiles (\a–\d) and one represents the player sprite (\e). The scrolling effect is achieved by rotating string slices — b$ shifts its first character to the end, and a$ shifts in the opposite direction — giving independent leftward and rightward scroll on alternating obstacle rows. A lives counter (ml) initialized to 5 governs how many collisions the player can survive before the session ends.

---

Program Analysis

Program Structure

The program is organized into a main game loop, three subroutines, and a DATA block. Execution flows as follows:

1. Line 360: UDG initialization subroutine — reads 40 bytes and POKEs them into five UDG definitions.
2. Line 20: Calls UDG init, then zeroes the high score.
3. Line 30/320: New-game setup subroutine — resets score, border/paper, and initializes scroll strings and lives.
4. Line 40/240: Screen-draw subroutine — clears screen, prints HUD, obstacle rows, and the player sprite.
5. Lines 50–140: Main movement and collision loop.
6. Lines 150–210: Death/game-over handler.
7. Lines 220–230: Score increment when the player reaches the top row.

User-Defined Graphics

Five UDGs are defined by the DATA block at lines 390–420 and the partially hand-coded line 430. The READ/POKE loop at lines 360–380 uses POKE USR "\a"+a to fill characters \a through \e (8 bytes each, 5 × 8 = 40 bytes total). The comment at line 440 names the UDGs explicitly: \a and \b pair as the left and right halves of one obstacle tile type; \c and \d form another; \e is the player sprite.

Scrolling Technique

The two obstacle rows are stored in the 32-character strings a$ and b$. Each frame, b$ is rotated left by moving its first character to the end (line 110: LET b$=b$(32)+b$( TO 31) — note this appends the 32nd character and drops the 31 after; effectively a rightward visual shift), while a$ is rotated right (line 120: LET a$=a$(2 TO )+a$(1)). This gives the two rows opposite scroll directions for visual variety, all without any array manipulation or machine code.

Movement and Collision Detection

Player position is tracked by integer variables v (row) and h (column). Movement on each axis is computed in a single expression using Boolean arithmetic (lines 60–70): pressing “6” increments v if h<21, “7” decrements it if v>0, etc. Note that lines 60 and 70 each sample INKEY$ independently, so diagonal movement is possible but diagonal key-presses are read twice per frame.

Collision is tested at line 90 using SCREEN$(v,h)="": if the cell is blank (space), the player is safe; otherwise the death sequence is triggered. The player sprite itself is printed with PAPER 8 (transparent paper) so it composites cleanly onto the obstacle characters without altering background color.

Lives System and Scoring

The lives counter ml is set to 5 at line 350 and decremented at line 180 on each death. If lives remain, the game re-enters the draw subroutine at line 40, preserving sc and the scroll state. Reaching row 2 (line 130 checks v=2) branches to line 220, which adds 10 to sc before re-entering the draw loop. The high score is updated only when a full game ends (line 190).

The subroutine at line 240 also prints the lives indicators in a FOR loop (line 310): one \e sprite per remaining life across row 1, using INK 5.

Screen Layout

Row(s)	Content
0	HUD: HIGH score and SCORE values (TAB-positioned)
1	Life indicators (one \e sprite per remaining life)
2 (target)	Reaching here scores +10 points
4–5	Obstacle rows (a$ and b$, PAPER 1)
11–12	Obstacle rows (b$ and a$, PAPER 4)
14	Player start row

Notable Idioms and Techniques

• PAPER 8 (transparent) is used for the player sprite to avoid overwriting background colors — a TS2068/Spectrum-specific attribute trick.
• OVER 1 at line 170 XORs a blank DIM s$(704) string over the play area during the death flash, effectively inverting displayed attributes without explicit loops.
• String slice rotation for scrolling avoids any loop overhead; the entire scroll update is two assignment statements.
• The obstacle strings a$ and b$ are 32 characters long — one full screen row — allowing direct printing with PRINT a$.

Potential Anomalies

• Line 110 reads b$(32)+b$( TO 31). The slice b$( TO 31) yields characters 1–31, and b$(32) yields character 32, so the full string is reassembled with character 32 moved to the front — this is a rightward rotation (the string content shifts right), causing a leftward visual scroll when printed. The direction is intentional but the code reads non-obviously.
• Lines 60 and 70 each call INKEY$ twice per variable. Since INKEY$ is re-evaluated each time it appears, a key held between the two evaluations will work correctly, but a very brief tap could be missed in one of the two axis checks.
• Line 160 dimensions s$ to 704 characters on every death. Since 704 = 22 × 32, this covers the entire text screen; the subsequent PRINT AT 0,0; OVER 1; PAPER 8; INK 2;s$ uses XOR to flash the screen. Re-dimensioning inside the loop is harmless but slightly wasteful.