Earthquake

This program is a maze/escape game in which the player (represented by “+”) must navigate to an exit marker (“E” in inverse video) inside a pyramid before a countdown timer expires or they become trapped by falling blocks. The playing field uses a 21×31 DIM array (A$) to track inverse-space wall cells, with movement on keys 5/6/7/8 checked both against the array and screen boundaries. Each keypress also triggers a random GOSUB (lines 350–386) that places an additional inverse-space block adjacent to the player, simulating falling debris from the earthquake. The trap-detection condition at line 290 contains a redundant duplicate check (A$(X+1,Y) is tested twice instead of checking A$(X-1,Y) on one of the occurrences), meaning the player can still escape upward even when surrounded. A flickering “GAME OVER” effect is created by alternating between a normal-video and inverse-video version of the message in lines 270–272 and 290–296, which loop back on themselves indefinitely.

---

Program Analysis

Program Structure

The program is divided into three logical regions:

1. Initialisation / instructions (lines 1000–2000): A GOSUB at line 10 jumps to the instruction screen subroutine, sets B$ to the inverse-E character, and waits for a keypress before returning.
2. Game setup (lines 15–112): Variables are initialised, the exit position (M, N) is randomised, and the border row is printed.
3. Main game loop (lines 120–386): Redraws the HUD, moves the player, places a random wall block via GOSUB, and loops back to line 120.

Data Representation

The playing field is modelled with a string array A$(21,31) declared at line 50. Each element holds either a normal space (open floor) or the two-character string "% " (an inverse-space, representing a solid block). Movement checks compare array cells to "% " before allowing a step, so the array acts as a shadow screen buffer. The player position is tracked purely in numeric variables X (row) and Y (column).

Movement and Input

Input is polled with INKEY$ at line 190 (no PAUSE, so the loop runs at full speed). Lines 200–230 handle the four directions mapped to keys 5/6/7/8:

• Left (5): decrement Y if Y>2 and cell to the left is not a wall.
• Right (8): increment Y if Y<39 and cell to the right is not a wall.
• Down (6): increment X if X<20 and cell below is not a wall.
• Up (7): decrement X if X>2 and cell above is not a wall.

If no key is held (F$=""), line 300 loops back immediately to 120 without adding a wall block or incrementing the score, giving the player a brief respite.

Random Wall Placement

Every keypress causes the timer to decrement by 1 (line 285) and the score to increase by 11 (line 310). A random direction 1–4 is chosen at line 320, and the computed GOSUB at line 330 (GOSUB (R*10)+340) dispatches to one of four short subroutines:

R value	Line called	Block placed
1	350	One row above player
2	360	One row below player
3	370	One column left of player
4	380	One column right of player

Each subroutine writes "% " into both A$ and the screen at the corresponding position, then RETURNs. This tightens the noose around the player with each move.

Win and Loss Conditions

The exit is placed at randomised coordinates (M, N) and drawn with B$ (inverse E). If the player reaches that cell (lines 240–257), the score is updated, a congratulatory message is shown, and the game restarts via GOTO 15. The time limit E starts at a random value between 10 and 59; when it reaches zero the game enters an alternating-message infinite loop at lines 270–272. A similar loop handles the trapped condition at lines 290–296.

Bugs and Anomalies

• Trap detection is incorrect (line 290/295/296): The condition checks A$(X+1,Y)="% " twice and never checks A$(X-1,Y)="% ". The upward neighbour is therefore never verified, so the player can always escape upward even when genuinely surrounded on all four sides.
• Spelling errors: The word “TRAPED” (should be “TRAPPED”) appears in both the instruction screen (line 1010) and game-over messages (line 290), and the instruction at line 1020 reads “YOUR TRAPED” rather than “YOU’RE TRAPPED”.
• Alternating GAME OVER loops: Lines 270–272 and 290–296 each print a normal-video version of the message then an inverse-video version, then loop back unconditionally. This creates a rapid flicker effect that never exits without a hardware reset.
• Border row width: The inverse-space string at lines 112 and 122 contains 32 two-character pairs, but a standard 32-column display fits exactly 32 characters; using two-character inverse-space tokens means only 16 inverse blocks actually display per line, leaving the border visually sparse.
• Dead code after line 2000: Lines 2010–2030 (CLEAR, SAVE, RUN) are never reached during normal execution.
• A$ bounds vs. screen bounds: A$ is dimensioned (21,31) but Y can reach 39 (line 210 allows up to 39). Accessing A$(X,39) or A$(X,40) would cause a subscript error; the right-boundary check Y<39 partly mitigates this but not fully for the array accesses on lines 210–210 when Y is already 39.

Key BASIC Idioms

• PAUSE 4E4 (lines 255 and 1085) is used as a long pause (~40 000 frames) to wait for any keypress, a common idiom in lieu of PAUSE 0.
• The computed GOSUB GOSUB (R*10)+340 at line 330 is an efficient dispatch table built entirely in BASIC arithmetic.
• Inverse-video characters (written as %X in the source) are used extensively for borders, the exit marker, and status-bar text to provide visual contrast without any PAPER/INK attribute manipulation.