Lunar Land

This program simulates a lunar lander descent game in which the player must manage fuel burns each second to achieve a safe touchdown velocity below 5 ft/sec. The physics model increments time in one-second steps, applying a constant 5 ft/sec gravitational acceleration and subtracting the player’s chosen burn from the descent velocity each turn. A random engine deterioration mechanic (lines 440–460) uses a deliberately odd conditional — `IF E<9 OR E>6` — which is always true, meaning the subroutine at line 700 fires every turn, steadily degrading the maximum burn limit `L`. Initial altitude, velocity, and maximum burn are all randomized at the start of each game, providing replayability. The POKE at line 30 sets system variable FLAGS2 to enable caps-lock mode, ensuring uppercase input without requiring the player to hold Shift.

---

Program Analysis

Program Structure

The program is organized into four logical blocks:

1. Setup and instructions (lines 10–180): Displays the backstory and rules if the player requests them.
2. Initialization (lines 190–330): Randomizes starting altitude, velocity, fuel, and maximum burn, then prints the instrument panel header.
3. Main game loop (lines 330–540): Accepts a burn value each second, updates physics, checks for landing or crash, and loops back to line 310.
4. Outcome and subroutine block (lines 540–780): Handles out-of-fuel, crash, damaged-landing, and safe-landing messages, plus the engine deterioration subroutine at lines 700–780.

Physics Model

Each iteration of the game loop represents one second of flight. The velocity update at line 420 is V=(V-5)+B, where −5 represents lunar gravity and B is the player’s burn. Height is updated at line 430 as H=H+V. Because velocity is negative (descent), gravity makes it more negative each turn while thrust counters this. The landing outcome is determined by checking whether V+100<=95 (velocity ≤ −5, safe) or V+100<=98 (velocity ≤ −2, capsule survives but is damaged).

Notable Bug: Always-True Deterioration Condition

Line 450 reads IF E<9 OR E>6 THEN GO SUB 700. The variable E is assigned RND*12, giving a value in [0, 12). The condition E<9 OR E>6 is logically equivalent to “any number that is less than 9 or greater than 6,” which covers all real numbers — so the subroutine is called unconditionally every turn. The intent was presumably to give only a partial chance of engine degradation (perhaps E<3 was intended for a 25% failure chance), but as written, the engine always deteriorates each second.

Engine Deterioration Subroutine (Lines 700–780)

The subroutine reduces the maximum burn limit L by a random amount: L=L-(RND*10)+1. If L drops to zero or below (tested with IF L+100<=100), the thrust units are declared completely failed and L is set to 0, after which the player can burn nothing. This progressive degradation is the core tension mechanic, though because the deterioration fires every turn due to the bug above, the engine degrades much faster than intended.

Key BASIC Idioms and Techniques

• Zero-or-negative test via addition: IF B+100<=100 (line 388) and IF L+100<=100 (line 710) are idiomatic ways to test B<=0 and L<=0 without using a negative constant, avoiding parser ambiguities on some Sinclair BASIC dialects.
• POKE 23658,8 (line 30): Writes to the FLAGS2 system variable to force caps-lock on, ensuring clean uppercase INPUT without user intervention.
• FLASH 1 / FLASH 0: Used extensively for dramatic emphasis on warnings and congratulations messages.
• PAUSE 60 (line 500): Introduces a one-second delay between display updates, giving the game a real-time feel tied to the 50 Hz frame rate (60 frames ≈ 1.2 seconds at 50 Hz).
• PRINT ”””’: Consecutive apostrophes after PRINT generate multiple blank lines efficiently in a single statement.

Variable Reference

Variable	Role
L	Maximum burn limit (ft/sec), degrades over time
T	Elapsed time in seconds
H	Current altitude in feet
V	Current vertical velocity (negative = descending)
F	Fuel remaining (units)
B	Player’s chosen burn this turn
E	Random value used (incorrectly) to trigger engine failure
Z$	Player’s yes/no input string

Input Validation

Burn input validation is minimal. Line 350 clamps B to L if the player over-burns, and line 370 forces B=0 when fuel is exhausted. Line 380 clamps non-positive burn values to zero using the addition idiom. There is no explicit upper-bound check preventing the player from entering a number larger than the fuel remaining, meaning a single large burn can deplete F into negative values — line 390 performs F=F-B without clamping F at zero.