Moon Rescue

Moon Rescue is a action game in which the player pilots a lander to rescue stranded astronauts on the lunar surface and return them to a moving mothership. The game uses 14 user-defined graphics (UDGs “a” through “n”), loaded via a POKE loop at line 9100, to render the lander, mothership, and surface personnel. Scrolling alien-landscape rows are implemented by rotating string slices with the TO syntax (e.g., `a$(c,pointer TO )` concatenated with `a$(c, TO pointer-1)`), creating a parallax scrolling effect across five terrain rows. Difficulty scales with the number of missions completed: the probability of obstacle placement uses `RND*(11-man)<.4`, so terrain density increases as `man` grows. Line numbers are stored in variables (e.g., `stage1=1000`, `shiploss=6000`) and used in computed GO TO statements, a common memory-saving idiom.

---

Program Structure

The program is organized into well-separated functional blocks:

• Lines 2–40: Bootstrap and game-loop dispatcher. Calls initialization routines, then branches to stage1 or stage2 depending on game state.
• Lines 1000–1999: Stage 1 — descending phase. The player drops the lander from the mothership to pick up an astronaut on the surface.
• Lines 2000–2999: Stage 2 — ascending phase. The player lifts off with the rescued astronaut and docks with the moving mothership.
• Lines 3000–3050: Wait/title screen with starfield, awaiting a keypress before play.
• Lines 4000–4010: Surface drawing subroutine — renders the lunar terrain using UDGs and embedded control codes, plus plots rescued-astronaut positions from array m().
• Lines 5000–5020: Top status bar subroutine — prints SCORE, HIGH, and SHIP labels with a decorative separator line of block graphics.
• Lines 5500–5510: Docking/home routine — flashes the lander in cycling INK colors with sound, awards 300 points, and exits to the game-loop dispatcher.
• Lines 6000–6010: Ship-loss routine — animates a falling explosion, sounds a long beep, increments the ship-loss counter, and returns to the dispatcher.
• Lines 8000–8999: Game-over screen, high-score check with fanfare, then restarts at line 5.
• Lines 9000–9080: Main initialization: dimensions arrays, sets all game variables and computed line-number variables, reads astronaut position data.
• Lines 9100–9899: UDG loader and high-score reset.
• Lines 9900–9989: UDG pixel data as DATA statements.

Computed GO TO via Variables

All major subroutine and jump targets are stored in plain numeric variables at lines 9030–9048:

• stage1=1000, stage2=2000, endgame=8000
• wait=3000, surface=4000, topprint=5000
• shiploss=6000, home=5500

These are then used in statements like GO TO stage1 and GO SUB wait. On the Spectrum, Sinclair BASIC evaluates the variable’s numeric value as the target line, so this is functionally identical to GO TO 1000 but saves tokenized space and improves readability.

User-Defined Graphics

Fourteen UDGs (characters "a" through "n") are defined at startup. Line 9100 uses a single FOR/POKE loop spanning USR "a" to USR "n"+7 to sequentially write 8 bytes per character from the DATA blocks at lines 9900–9913. The UDGs represent: the player’s lander (\e), mothership components (\a\b\c and \d \f), terrain tiles (\g, \h), and surface/astronaut decorations (\i through \n). The mothership is printed as a two-row composite string built with embedded INK control characters in m$ and n$ at line 9015.

Scrolling Terrain Technique

Five rows of terrain are stored in the string arrays a$(5,32) (stage 1, enemy terrain) and i$(5,32) (stage 2, friendly terrain). A pointer variable pointer is advanced by pinc=2 each frame. Each row is printed as two string slices concatenated inline:

PRINT AT 4+c*2,0; a$(c,pointer TO ); a$(c, TO pointer-1)

This wraps the string around itself, producing a smooth horizontal scroll without any array shifting. When pointer exceeds 32 it resets to 1, completing the cycle.

Difficulty Scaling

Terrain density is controlled at line 1020 by:

IF RND*(11-man)<.4 THEN LET a$(c,d)="\g"

As man (mission count) increases toward 10, the divisor (11-man) shrinks, so the scaled random value is more likely to fall below 0.4, placing more obstacles. This gives an elegant single-expression difficulty curve without branching logic.

Game-Loop and Stage Transitions

The top-level dispatcher at lines 2–40 handles all inter-stage routing:

1. Line 7: GO SUB wait — shows the ready screen.
2. Line 10: GO TO stage1 — enter descent phase.
3. Line 20: GO TO stage2 — entered when the lander lands (ATTR check at line 1235).
4. Line 30: checks ship<4 AND man<10; loops back to stage 1 if lives remain and missions are incomplete.
5. Line 40: GO TO endgame when conditions fail.

Both stage routines branch directly to shiploss or home by name, bypassing the dispatcher, then the ship-loss/home routines themselves GO TO 30 to re-enter the condition check.

Collision Detection

Two complementary methods are used:

• ATTR (y,x)=3 at line 1235 — detects landing on the surface (green INK on black gives attribute value 3), triggering the stage 2 transition.
• SCREEN$ (y,x)="" at lines 1240 and 2190 — detects collision with any non-space character (terrain obstacles or other sprites), triggering ship loss. An empty string return from SCREEN$ means the cell is blank, so a non-empty result indicates a collision.
• Line 2160: exact coordinate match y=3 AND x=mothx+2 — checks docking with the mothership.

Sound Design

Sound is tightly coupled to game state:

• Drop/ascent engine: BEEP .005,24*drop-12 and BEEP .005,24*drop-10 — when drop or up is 0, both BEEPs play at –12 and –10 (idle hum); when 1, at +12 and +14 (thrust tone).
• Rescue pickup: rising/falling tone pair in a FOR loop at line 2000.
• Docking success: cycling INK with paired BEEPs at line 5500.
• Ship loss: descending-pitch explosion at line 6000, followed by a long low BEEP.

Notable Anomalies and Details

• Line 1999 and 2999 contain STOP statements acting as safety guards — they are never reached in normal play but prevent fall-through between stage blocks if line targets are miscalculated.
• The ship-loss counter uses ship initialized to 1; the condition at line 30 tests ship<4, so the player effectively has 3 lives (ship becomes 2, 3, then 4).
• Line 2005 sets m(nman)=0 before incrementing nman, which would zero out an already-zero slot — this appears to be a redundant but harmless reset of the astronaut position array entry for the current mission.
• The RESTORE 9900 at line 2 followed by GO SUB 9100 ensures the DATA pointer is at the UDG data before loading; line 5’s plain RESTORE resets to the start for the astronaut position DATA at line 9070.
• The m$ mothership string at line 9015 is constructed with embedded CHR$ 16 (INK) and CHR$ 2 (red) control codes inline, making the mothership always print in red regardless of surrounding INK state.