Zombies

Zombies in the Swamp is a grid-based maze game in which the player guides a raft from the bottom-right corner to the exit at the top-left while being pursued by a zombie monster. The play field is a 9×9 array `a()` where values of -1 represent impassable swamp, 0 represents open water, and 1 marks cells where the player has already been. Movement is controlled with keys 5–8 (the arrow keys), and the game checks for valid moves using computed GO TO targets based on the cell value (`GO TO 1300+100*a(px+dx,py+dy)`). The zombie’s pathfinding logic uses a direction-preference system with subroutines at lines 2100–2130 that set dx/dy deltas, trying to continue straight, turn, or pick a random direction when swamp blocks the path. Characters are rendered as 2×3-cell block graphic sprites stored in string variables `p$` (player), `m$` (monster), and `d$` (drowned monster), each printed in two halves via a shared display subroutine at line 1000.

---

Program Structure

The program is organized into clearly labeled subroutine blocks, each preceded by a REM comment. The main loop begins at line 3000 and calls three major subroutines in sequence:

1. Init (line 1100) — Sets up the grid, draws the swamp, and places the player.
2. Move (line 1200) — Handles player input and movement.
3. Monster (line 1600) — Executes the zombie’s AI move.

The monster is only summoned when the probabilistic condition at line 3040 is met ((px+py)*RND>4 OR m<5), suppressing it for the first 5 player moves and then triggering it stochastically thereafter, increasing tension as the player approaches the exit.

Grid Representation

The 9×9 array a() uses three sentinel values to encode cell state:

Value	Meaning
-1	Impassable swamp (borders and visited trail)
0	Open water (traversable)
1	Occupied by player or already visited

The border cells (row/column 1 and 9) are all initialized to -1 in the loop at lines 20–50. The player’s starting cell a(8,8) and the two exit-adjacent cells a(2,1) and a(1,2) are seeded to 1 at lines 60 and 1110, carving a valid corridor.

Computed GO TO for Move Dispatch

A key idiom appears at line 1260:

GO TO 1300+100*a(px+dx,py+dy)

This uses the cell value (-1, 0, or 1) as an arithmetic offset to dispatch to one of three handlers: line 1200 (re-prompt, cell value -1 → 1300-100), line 1300 (trail/throw, value 1 → 1400), or an implicit fall-through. In practice, movement onto swamp (-1) goes back to 1200 to re-read input, while movement onto a previously visited cell (1) goes to 1300 to handle the “throw” mechanic. This compact dispatch avoids multiple IF statements.

Sprite Rendering

Each sprite occupies a 2-row × 3-column block graphic cell on screen. Three sprites are defined as 6-character strings using block graphic escape sequences:

• p$ (line 80) — the player’s raft
• m$ (line 90) — the zombie monster
• d$ (line 100) — a drowned monster (solid blocks)

The shared print subroutine at line 1000 splits the string at character 3 and prints the first half at row 2*y, column 3*x, and the second half one row below, using PAPER 5 (cyan background) for contrast. The blank sprite e$ (six spaces) erases a cell before redrawing it in a new position.

Zombie Pathfinding AI

The zombie’s movement logic (lines 1600–2230) implements a simple directional preference algorithm using four direction-setting subroutines at lines 2100–2130 (up, left, down, right). On each turn:

1. If the path ahead is clear (cell ≥ 1), continue in the same direction.
2. If a perpendicular turn is available, randomly try a new direction.
3. If blocked by swamp, pick a random direction and retry until valid.

A zombie that steps onto a cell with value 0 (open water) is considered drowned: its cell is set to -1 and it is drawn with the d$ sprite, then control returns without further movement. Crucially, only one zombie (mx, my) is tracked per game; if it drowns, no new zombie spawns, effectively ending the threat. The initial zombie position is hardcoded to (7,7) each time the monster subroutine is called.

Notable Anomalies and Observations

• Line 6 assigns INKEY$ to z$ but this value is never used; it exists purely as a dummy read before the actual wait loop at line 7.
• Line 3990 (GO TO 4000) and line 4000 (STOP) are dead code, never reachable from the main loop flow.
• Line 5555 (RUN) is also unreachable dead code, likely a safety remnant.
• The “throw” mechanic at line 1300 (when the player tries to move to a previously visited cell) erases the destination cell’s sprite without advancing the player — effectively a no-op move that consumes a turn.
• The zombie’s initial position (7,7) is always reset at line 1610 on each monster call, so if a zombie drowns, the next monster activation spawns a fresh one at the same starting location.
• Lines 3 and 4 contain intentional line-wrap artifacts in the text strings (“infestedswamp” and “persuit” — also a misspelling of “pursuit”) that are baked into the PRINT statements.