Pac Man

This program implements a Pac-Man-style maze game in which the player navigates a character through a nested-border playfield while eating dots and avoiding a pursuing enemy. Seven UDGs (characters \a through \g) are loaded at startup from DATA statements, defining the custom sprites used for the player, enemy, and pellets. The maze is drawn using INVERSE 1 mode with nested rectangular borders printed by a clever re-entrant GOSUB structure controlled by the flag variable `f`. The enemy AI tracks the player using a lane-based alignment system stored in variables `lj` and `lf`, and the game features a high-score table with a name-entry prompt persisting across playthroughs via variables `h` and `e$`.

---

Program Analysis

Program Structure

The program divides into several logical phases:

1. Initialization (lines 2–78): Sets persistent variables (h, e$), loads 56 bytes of UDG data into characters \a–\g, and resets per-game state.
2. Maze drawing (lines 79–290): Prints a concentric nested-border maze using a re-entrant flag technique.
3. Game loop (lines 310–700): Handles player movement, collision detection, dot eating, scoring, and enemy movement.
4. Subroutines (lines 710–1250): Enemy turning logic (710), game-over sequence (800), music playback (1040), bonus sound/score (1150), and pellet placement (1200).
5. Persistence and restart (lines 880–890): High score is retained in h and e$ across games; GO TO 75 restarts without re-running UDG loading.

UDG Setup

Lines 10–60 read 56 bytes from DATA and POKE them into USR "\a" through USR "\g" (7 UDGs × 8 bytes). Character \g is used throughout as the dot/pellet tile. The player sprite cycles through four UDG characters (c runs 144–147, wrapping at 148 back to 144) to animate the Pac-Man mouth. The enemy is represented by the character "H" printed directly, and the player’s current cell by "F".

Maze Drawing Technique

The nested rectangular borders are built using a re-entrant GOSUB trick. Variable f is initially 0. The code prints each concentric ring line by line (lines 80–280). After all lines are printed once with f=0, line 290 sets f=1 and line 300 does GO SUB 240. On this second pass, the IF f=1 THEN GO TO / RETURN guards at lines 90, 110, 130, … cause the GOSUB to return after printing only the innermost row, creating the illusion of a re-drawn partial maze efficiently.

Player Movement

The player’s grid position is tracked by (u, p) with direction deltas (du, dp). Keys 5–8 are used for movement (standard Spectrum directional keys). Lines 630–680 implement turn requests: the player can only turn perpendicular to the current direction of travel ((du=0) or (dp=0) guards), and the new position is computed two cells ahead to check feasibility. Variable lj tracks the player’s lane for the enemy AI.

Enemy AI

The enemy at (a, t) moves with deltas (da, dt). Subroutine 710 is called when the enemy’s screen cell matches a dot character. It computes a turning preference based on the relative lane positions of the enemy (lf) and player (lj). The logic in lines 730–780 uses boolean arithmetic to derive signed offsets, nudging the enemy’s column or row toward the player’s lane over successive turns — a lightweight AI that avoids a full pathfinding implementation.

Collision Detection

All collision detection is done via SCREEN$ rather than coordinate comparison. Line 440 checks whether the player’s next cell contains "x" (a wall character); lines 1000–1015 handle the wall-bounce by rotating the direction deltas. Similarly, line 470 checks the enemy’s next cell. Line 542 uses ATTR to detect the player reaching a special cell (ATTR=6 signals the game-over trigger at line 800).

Dot and Pellet System

Regular dots are detected by SCREEN$ returning "," (a comma character used as a sentinel). The s2 variable counts total dots eaten; when it reaches 224 (line 557), the level is won (line 1110 increases difficulty by incrementing v with a random component, then restarts the maze). Power pellets are placed by subroutine 1200 at random valid positions, rendered with FLASH 1. Collecting a pellet (line 547 calls subroutine 1150) awards 5 bonus points and plays a descending beep.

Scoring and High Score

Variable s holds the current score; h and e$ hold the high score and name and are initialized only once at lines 2 and 5, persisting across game restarts (which loop back to line 75, skipping those initializations). On game over (line 875), if the current score beats the high score, the player is prompted for their name via INPUT, with a length check enforcing a maximum of 11 characters.

Music

Subroutine 1040 plays a two-phrase melody (56 notes total, stored in DATA at lines 1050–1055) using BEEP with durations divided by 10. It is called at startup (line 307) and between levels. The game-over sequence at lines 800–870 plays four notes from inline DATA and then 64 rapid beeps at pitch 25.

Notable Anomalies and Bugs

• Line 200 prints INK z;"z" (the letter z) instead of INK z;"x" for a wall segment — this is likely a typo causing a visual glitch in the maze border.
• Line 525 sets LET t=dt instead of LET t=t+dt, meaning the enemy’s column is assigned the raw delta value rather than being incremented — a probable bug in enemy horizontal movement.
• Line 655 references I$ (uppercase I) which is a different variable from i$ (lowercase); on this platform variable names are case-insensitive for keywords but string variable names differing only in case may behave unexpectedly depending on the interpreter.
• Line 510 compares g$<>"," twice in succession on the same line with no effect — the second condition is redundant.
• The DATA at line 585 mixes numeric and string values (du,"6","7",dp,"5","8"), relying on the interpreter reading numeric variables as numbers and strings as strings in alternating READ calls — an unusual but functional BASIC technique.
• Line 515 is jumped to by lines 1020 and 1030 (enemy wall-bounce), bypassing the subroutine call at line 517 and the dot-detection at line 520, which is intentional to avoid recursive re-entry during bounce resolution.
• The REM at line 9990 (“Needs fixin?”) acknowledges that the author was aware of outstanding issues.