Frogger

Frogger is a scrolling arcade game in which the player guides a frog across lanes of moving traffic and river hazards, closely following the gameplay of the original Frogger arcade cabinet. The program uses 18 user-defined graphics (UDGs, characters 144–161) loaded via DATA statements and POKE USR to render the frog sprite and vehicle/log tiles in four graphical variants for odd and even lanes. Two separate subroutines (lines 15 and 200) build scrolling lane data into string arrays x$ and y$ of length 128, allowing left- and right-moving rows to be displayed by slicing different offsets each frame. A timer counts down each level, and difficulty scales with the variable r, which increases the number of obstacles per lane with each successful crossing. The score, top score, remaining lives (fl), and time remaining are tracked persistently across rounds within a single play session.

---

Program Structure

The program is organized into several distinct functional blocks:

• Lines 1–4: Initialization, top-score reset, title screen display using block graphics.
• Lines 10–11: Level entry point; calls the lane-building subroutine and jumps to the game screen setup.
• Lines 15–76: Subroutine to build water/river lane data (logs/platforms) for odd rows moving right, even rows moving left.
• Lines 80–155: Main game loop — draws road/water background, scrolls lanes, calls the player subroutine, manages the countdown timer.
• Lines 200–265: Alternative lane-builder for road traffic (cars), used when p=1.
• Lines 1000–1140: Player subroutine — reads keypress, moves frog, checks collision with obstacles, erases and redraws frog sprite.
• Lines 3000–3025: Level/phase controller — switches between water phase (p=7) and road phase (p=1), increments difficulty level r.
• Lines 5000–5015: Success handler — plays victory tune, increments score, advances to next phase.
• Lines 7000–7010: UDG loader — reads 144 bytes of DATA and POKEs them into UDG definitions for characters 144–161 (18 UDGs).
• Lines 8000–8020: Death handler — plays descending beep sequence, decrements lives fl, restarts current screen.
• Lines 9500–9520: Game over — displays flashing message, plays long descending glissando, updates top score, returns to title.

UDG Definitions

The subroutine at line 7000 reads 144 bytes of DATA into an outer loop over characters 144–161 and an inner loop over the 8 bytes per character, using POKE USR CHR$(a)+b,c. This defines 18 UDGs (characters \a through \r in Spectrum notation) used for the frog sprite, vehicle halves, and log tiles. The frog occupies a 2×2 UDG cell ([UDG-M][UDG-N] / [UDG-O][UDG-P]), and separate UDG pairs are assigned for odd-lane objects (rows 1 and 3, [UDG-A][UDG-B]/[UDG-C][UDG-D]) and even-lane objects (rows 2 and 4, [UDG-E][UDG-F]/[UDG-C][UDG-D]).

String-Array Scrolling Technique

Each of the four lane rows is represented by a 128-character string within the arrays x$ and y$ (top and bottom halves respectively). The lane is logically 64 cells wide; each cell is expanded to 2 characters (one UDG pair per obstacle cell). The screen is 32 characters wide, so a 32-character window is extracted from the 128-character buffer each frame.

Odd-numbered lanes scroll left-to-right by slicing x$(a, b TO b+31) where b increments from 1 to 96. Even-numbered lanes scroll right-to-left by slicing x$(a, 97-b TO 128-b), which counts backwards through the buffer. This is an elegant, branch-free scrolling approach that avoids any character shifting.

Obstacle Population

The subroutine at lines 15–76 fills the 64-element logical lane (a$) by placing "1" markers at random positions for 3*r iterations. If the random position c is less than 17, the position is also mirrored to 48+c, ensuring objects wrap symmetrically in the buffer. The road subroutine (lines 200–265) uses 60-3*r iterations instead, so roads become less dense (more cars) as the level increases, while rivers become more densely packed (more logs).

Collision Detection

Collision is resolved by inspecting the logical lane array a$(g, g1) and a$(g, g2) rather than by pixel testing. The frog’s screen column f and the current scroll offset b are used to back-calculate positions g1 and g2 in the lane array, with a rounding step (INT((g1/2)+0.5)) to convert from double-width character coordinates back to logical cell indices. Two distinct collision rules apply:

• On the road (p=7): hitting a cell marked "1" (a vehicle) kills the frog.
• On the river (p=1): landing on a cell marked " " (not a log) kills the frog.

Player Movement and Controls

The frog is moved with four keys: m (up), n (down), z (left), x (right), each moving 4 character positions at a time. Vertical movement snaps to multiples of 4 rows. Boundary guards at lines 1120–1125 prevent the frog from moving off-screen horizontally; if a movement would take f out of range, it is reversed. Any keypress triggers a short three-note ascending beep sequence (lines 1126). Reaching row 0 triggers the success handler at line 5000.

Phase and Difficulty Progression

The game alternates between two phases per round: water (river, p=7 background paper color) and road (p=1). Completing the water phase calls GO TO 3010 to set up the road; completing the road phase increments r at line 3025 and restarts from the water phase. The variable r is capped at 17, which would make the river entirely filled with logs and the road almost clear of vehicles.

Timer Mechanism

The countdown timer t is initialized to 105 - r*5 at line 100, so harder levels have shorter time limits. It is decremented by 1 every two half-frames (once per odd-lane scroll, once per even-lane scroll) via line 147. When t reaches zero, the death routine at line 8000 is triggered. The current value is displayed each iteration at line 107.

Notable Anomalies and Observations

• Line 1200 contains only RETURN and appears unreferenced — it is dead code, likely a leftover from an earlier revision.
• The frog’s vertical position f1 starts at 19 (bottom road row). The check at line 1015 skips collision detection entirely when the frog is at row 19 (the safe starting zone), preventing a false death on spawn.
• The level variable r is not reset when a new game begins from line 3 — only s (score) and fl (lives) are reset at line 4, so replaying after game over continues at the same difficulty.
• Lines 105–155 form an inner loop over b (scroll offset 1–96), and line 155 loops back to line 105 indefinitely, with the timer and death/win conditions providing the only exits.
• The PAPER color variable p doubles as both the background color and a phase indicator (7 = road, 1 = water), which is a compact but implicit design choice.