Treasure Hunt

This is a Hunt the Wumpus-style cave adventure game in which the player navigates a network of interconnected caves, shoots arrows at monsters, and attempts to escape with treasure. The cave map is encoded in the string B$ using ASCII-offset character codes (subtracting 37 from the CODE of each character) to store up to three exits per room in a compact format. Movement uses the classic Sinclair key layout (5/6/7/8), and the program employs PEEK of the system variable at address 16396/16397 to find the top of the BASIC program area for collision detection via character-cell scanning. A special cave (PR=21) triggers a boss-room sequence with a bouncing enemy that uses a simple reflection algorithm for wall collision.

---

Program Analysis

Program Structure

The program is divided into several functional blocks:

1. Initialisation (lines 5–95): Dimensions arrays, builds the decorative border string C$, sets up the cave map in B$, and jumps to line 1300 (which is absent — likely a separate loader or the game starts at line 1340 via fall-through to the nearest higher line).
2. Room renderer (lines 150–265): Draws the cave walls with block graphics, places monsters (DEM enemies), shows arrow count and room numbers in the border.
3. Main game loop (lines 265–360): Reads keys 5/6/7/8 for movement, fires arrows with “F”, detects wall collisions via PEEK, and calls monster-movement subroutine.
4. Room transition (lines 805–970): Handles movement between caves, decodes exits from B$, and re-renders the new room.
5. Arrow flight (lines 1000–1125): Traces the arrow’s path cell by cell, checking for monster hits and boundary collisions.
6. Monster movement (lines 1201–1255): Moves each monster one step toward the player using SGN.
7. Entrance hall / scoring (lines 1340–1660): Starting cave selection, safe-zone score banking, and arrow purchase system.
8. Death screen (lines 2005–2040): Penalises the score by 15 if the player has enough points; otherwise stops.
9. Boss room — cave 21 (lines 2050–2115): Draws a special diamond-shaped room using sliced string printing, places treasure markers, and launches the bouncing enemy loop.
10. Bouncing enemy (lines 3000–3035): Moves the Wumpus-like creature and handles wall reflection.

Cave Map Encoding

The map data is stored compactly in B$ (lines 70–76). Each cave occupies exactly three characters in the string; the exit room numbers are retrieved by CODE R$ - 37, converting printable ASCII characters (starting at code 38, i.e., &) to room indices 1–20. The three exits per room are stored at positions PR*3-2, PR*3-1, and PR*3. When the player arrives from room LR, the code at lines 960–965 replaces whichever exit leads back to LR with the third exit R3, so only two novel directions are shown on screen.

Collision Detection via PEEK

Line 55 computes Q = PEEK 16396 + 256*PEEK 16397 + 1, which reads the display file address from the ZX81 system variables (D_FILE, address 16396). Adding 33*row + column to Q gives the character-cell content of any screen position. Lines 320–325 use this to test whether the player is walking into a wall character (code > 62), and line 1053 does the same for the arrow’s path. This avoids storing a separate map array and directly queries the display.

Movement and Key Handling

Player movement uses the standard Sinclair cursor-key layout. Lines 310–315 use the Boolean-arithmetic idiom (1 AND INKEY$="x") to add or subtract 1 from the row/column variables in a single expression, avoiding IF statements in the hot loop. Arrow firing on key “F” calls GOSUB 1000, which traces the projectile cell by cell using a direction vector (MX, MY) derived from the last key pressed before “F” was held.

Boss Room (Cave 21)

Cave 21 is a special case throughout the code. The diamond-shaped room at lines 2050–2115 is drawn by printing substrings of C$ — C$(TO AI) where AI = ABS I for I from -10 to 10 — creating a diagonal border effect purely with string slicing. The bouncing creature at lines 3000–3035 uses a reflection algorithm: if the next cell is occupied, the direction vector components are swapped or negated to simulate a bounce off a wall.

Scoring and Economy

Two score accumulators are used: S for banked permanent score and TR for treasure collected in the current run. Dying deducts 15 from S provided S+TR >= 50+PS (where PS is the previous high-water mark), giving a soft continue system. Arrows cost 4 points each and are bought at the entrance hall between runs. Killing a monster awards 5 points (line 1098).

Notable Techniques

• RAND (PR*10+NOW) at line 162 seeds the random number generator deterministically per room and session start time, so each room visit produces consistent but varied layouts.
• The decorative border C$ is built using concatenation with block graphic escapes (\## = solid block, % = space/checker pattern) at initialisation rather than being recomputed each frame.
• Monster positions are stored in the 2-D array D(3,2) — limiting the maximum number of monsters per room to 3 — with a swap-and-decrement idiom at lines 1100–1110 for O(1) deletion from the active list.
• GOTO 1300 at line 95 targets a non-existent line, so execution falls through to line 1340, a well-known ZX81 technique for computed or conditional entry points.
• The T(20) array tracks whether each cave has been visited before; an asterisk is printed on the exit marker only for unvisited caves (line 222), and the flag is cleared on entry (line 224).

Potential Bugs and Anomalies

• Line 800 is referenced by GOTO 800 at line 335 (triggered when character code 8 — a ZX81 backspace/delete glyph — is detected underfoot), but the actual label is line 805. On the ZX81, GOTO to a non-existent line jumps to the next higher line, so this works correctly.
• The arrow-firing subroutine starts at line 1000 but the first executable line is 1003. Lines 1000–1002 are absent; the entry point relies on fall-through from GOSUB 1000 landing at 1003.
• DIM D(3,2) limits monsters to 3, but DEM = INT(RND*4) at line 230 can produce values 0–3, so the maximum of 3 is valid. However, line 86 in the boss room sets DEM=1 without re-dimensioning, reusing the same array safely.
• The arrow direction is taken from F$ (last non-fire keypress) at lines 1030–1035, but F$ is also used as a general input variable elsewhere, so rapid key changes could theoretically affect arrow direction.