Spacman

This program implements a Pac-Man-style maze game called “Spacman” in which the player navigates a dot-eating character through a 20×20 maze while being pursued by two ghosts. The maze is stored as a 20×20 string array, with solid wall cells represented by the block graphic █ (two-cell wide), and dots encoded as periods within the array strings. Player movement is controlled via keys 5–8 for left, down, up, and right, with collision detection performed by comparing array cells against the wall character before allowing movement. Five UDG characters are defined via POKEs to USR addresses: directional Pac-Man mouth sprites for up, right, down, and left (UDGs \u, \r, \d, \l), plus a ghost sprite (UDG \a). The two ghosts use a simple AI that biases random movement toward the player’s current coordinates, and the game triggers a level-clear animation subroutine at scores of 180, 460, and 740 before resetting the maze.

Originally published in Sinclair Programs – type-in from issue #4 – 1982/Nov.

---

Program Analysis

Program Structure

The program is organized into several clearly separated functional blocks:

1. Lines 1–3: Title REM and variable initialization (player position, ghost positions, score, direction).
2. Lines 9–210: Maze definition and initial rendering. The 20×20 string array a$ is populated row by row, then printed.
3. Lines 1000–3130: Main game loop — input reading, player movement, dot collection, ghost AI, and collision detection.
4. Lines 7000–7060: Level-clear animation subroutine showing the player sprite traversing the screen.
5. Lines 9000–9080: UDG initialization subroutine using DATA and POKE to define five custom characters.
6. Line 9999: SAVE statement with auto-run flag.

Maze Representation

The maze is stored as a DIM a$(20,20) two-dimensional string array, where each row is exactly 20 characters wide. Wall cells are represented by the block graphic █ (\::), and open passages contain either a dot "." or a space " " after being eaten. This dual-purpose array simultaneously acts as the game map and tracks which dots have been consumed — when the player moves onto a dot cell, that entry is replaced with a space (line 1000), and the score increments at line 1070. The printed maze is offset one column to the right by printing a leading "\::" before each row at line 210, effectively adding a left border wall.

UDG Sprite Definitions

Subroutine 9000 defines five UDG characters using POKE and READ from DATA statements:

UDG	Lines	Represents
\u	9045	Pac-Man facing up
\r	9050	Pac-Man facing right
\d	9060	Pac-Man facing down
\l	9070	Pac-Man facing left
\a	9075	Ghost

The direction variable d$ is therefore both a movement indicator and a directly printable UDG sprite character — the current direction string is printed at the player’s position (line 1064), so the sprite automatically reflects the direction of travel without any additional logic.

Player Movement and Collision Detection

Lines 1060–1063 handle movement in all four directions. Before updating the player’s row (x) or column (y), each line checks that the destination cell in a$ is not a wall ("\::"). This array-lookup collision method is efficient and requires no separate collision map. The old player position is erased with a space at line 1055 before the new position is calculated and printed at line 1064 with INK 0.

Ghost AI

Two ghosts are tracked by coordinate pairs (gx,gy) and (gx1,gy1). Each ghost’s movement is decided by four independent checks (lines 1080–2010 for ghost 1; lines 3080–3110 for ghost 2). Each check uses the idiom INT (RND*2)+(gx>x) — the Boolean comparison yields 0 or 1 and is added to a random 0–1 value, giving a result of 0, 1, or 2. The move only occurs when this sum is non-zero AND the target cell is not a wall. This produces a bias toward the player rather than a strict chase, adding unpredictability. Ghost 1 is printed in INK 3 (yellow) and ghost 2 in INK 4 (green).

Score Milestones and Level Reset

Line 1001 checks for scores of 180, 460, and 740, which correspond to levels being cleared. On a match, the score is incremented by 100 (to prevent re-triggering), the level-clear animation at subroutine 7000 is called, and then execution jumps back to line 10 to rebuild and redisplay the maze. This means the maze resets completely but dot consumption is not tracked between levels — the array is reloaded from the literal string assignments each time.

Level-Clear Animation

Subroutine 7000 (lines 7000–7060) animates the Pac-Man sprite moving right across row 10 of the screen (columns 0–25) with a ghost trailing behind, using BEEP for sound effects. It then reverses the animation, sweeping left. The ghost sprite in this sequence is displayed with INK 5 (cyan). A fixed “O” is printed at column 29 as a static target element throughout the forward sweep.

Notable Techniques and Idioms

• Using d$ as both the direction state variable and a printable UDG character is an elegant space-saving technique.
• The maze is defined entirely in string literals without any procedural generation, making level layouts hand-crafted.
• Line 1080 prints the ghost’s current cell content from a$(gx,gy) to erase it before the ghost moves — this restores walls or dots beneath the ghost sprite correctly.
• Dot-eating feedback uses BEEP .1,-10 (a low tone) immediately after incrementing the score.
• Collision between player and either ghost triggers FLASH 1 on the player character followed by STOP, providing a visual death indicator without a dedicated game-over routine.

Potential Bugs and Anomalies

• The ghost movement code at lines 1080–2010 does not update a$(gx,gy) to restore the cell before moving, only printing it. If a ghost moves over a dot cell, the dot character is visually restored but a$ still contains the dot, meaning the player could re-eat it for points — though in practice the ghost’s PRINT at line 1080 only affects the display.
• At line 1001, the score is incremented by 100 to skip the trigger value, but the conditions are fixed values (180, 460, 740) rather than a general “all dots eaten” check, so level resets depend on reaching exact scores.
• Ghost 2’s movement (lines 3080–3110) checks a$(gx1,gy1-1) for horizontal movement but uses the updated gx1 from the vertical movement checks immediately above, meaning vertical and horizontal movement can interact within the same frame.