Munchie Man

Munchie Man is a Pac-Man-style maze game that uses joystick input via the STICK function to move a player character through a maze, eating dots and special pellets. Nine custom UDG characters (labeled \a through \i) are defined at startup using POKEd DATA values, providing directional mouth animations for the player sprite and a ghost enemy sprite. The maze is drawn entirely through two long PRINT statements containing ASCII characters, where underscores represent walls, periods represent dots, and “o” represents power pellets. A single ghost enemy moves randomly through the maze, triggering a life-loss sequence with descending BEEP tones when it catches the player. The game tracks score, a session high score, remaining lives, and a dot count to detect level completion.

---

Program Analysis

Program Structure

The program is organized into a main game loop and several subroutines, with line numbers used as semantic separators:

• 10–250: Main game loop — initialization calls, player and ghost movement, collision detection
• 2000–2050: Game Over screen with high-score tracking and restart prompt
• 5000–5140: Death sequence — animated player collapse with descending BEEPs, life decrement
• 6000–6010: Power pellet subroutine — bonus score (200–299 points) and sound effect
• 7000–7100: Maze drawing subroutine — sets colors, CLSes, and PRINTs two long layout strings
• 8000–8990: Game variable initialization (player position, score, lives, dot count)
• 9000–9990: UDG definition loop with DATA, plus REMarks labeling each UDG

UDG Sprite Definitions

Nine UDGs (\a through \i) are defined at lines 9030–9110 by POKEing 8 bytes each into memory starting at USR "a". The loop at line 9000 iterates from USR "a" to USR "i"+7, consuming DATA values one per POKE. The REMark at line 9980–9990 documents the mapping:

UDG	Description	Usage
\a	Full circle (closed mouth)	Player idle / death start
\b	Mouth open left	Moving left
\c	Mouth open right	Moving right / initial sprite
\d	Mouth open down	Moving down
\e	Mouth open up	Moving up
\f	Partial collapse frame 1	Death animation
\g	Partial collapse frame 2	Death animation
\h	Partial collapse frame 3	Death animation
\i	Ghost sprite	Enemy character

Maze Representation

The maze is stored as two long string literals in PRINT statements at lines 7010–7020. Walls are encoded as _ (underscore), collectible dots as . (period), power pellets as o, and open corridors as spaces. Collision detection throughout the main loop uses SCREEN$ to read these characters back from the display, making the screen itself serve as the game state map — a common technique in Sinclair BASIC games that avoids maintaining a separate map array.

Joystick Input via STICK

Input is handled using the STICK (1,1) function (TS2068 extended keyword). The directional values used are: 1=up, 2=down, 4=left, 8=right. The sprite selection at line 70 uses a string-arithmetic idiom: each direction string is ANDed with the Boolean result of the corresponding STICK comparison, so exactly one non-empty string is concatenated into m$. Movement deltas at lines 100–110 use the same Boolean-as-integer trick ((condition) evaluating to 1 or 0) to compute row and column offsets in a single expression each.

Ghost AI

The ghost (stored at position z, x) uses a simple random walk. At line 170, movement deltas are computed from direction variable m1 (values 5–8 mapping to up/down/left/right). When the ghost hits a wall (SCREEN$ (z,x)="_"), a new random direction is chosen via INT(RND*4)+5 and the ghost reverts to its previous position. Lines 190–195 restore any dot or pellet that the ghost had moved over, preventing the ghost from permanently erasing collectibles.

Collision Detection

All game entity interactions are resolved by reading SCREEN$ at the player’s or ghost’s new position before rendering:

• SCREEN$="_ " → wall, revert position
• SCREEN$="." → dot eaten, +10 score, increment dot counter
• SCREEN$="o" → power pellet, go to bonus score subroutine at line 6000
• SCREEN$="" (empty string / space) → player–ghost collision, go to death sequence at line 5000

Note that the ghost-catch condition at line 140 and line 200 checks for SCREEN$="", meaning an empty cell. This relies on the ghost sprite being printed at that cell first (line 210), but in some frame orderings the ghost sprite character \i would be there instead — this is a minor logic fragility in the collision system.

Screen Wrap-Around

Lines 85–86 implement horizontal screen wrap: if h (column) falls below 1 it wraps to 30, and above 30 it wraps to 0. There is no equivalent vertical wrap, so the player can be stopped by walls at the top and bottom of the maze. This asymmetry is typical for simple maze layouts where corridors don’t cross the vertical edge.

Death Animation

The death sequence at lines 5000–5140 steps through UDGs \a, \b, \f, \g, \h, then a space, each paired with a BEEP call at a descending pitch (15, 11, 7, 3, 0, −5 semitones). After the animation, the dot count is reset, player position is reset to v=12, h=16, and lives are decremented. Level completion is checked at line 240 by comparing count against tot=286, which matches the total number of dot characters embedded in the two maze PRINT strings.

Notable Techniques and Anomalies

• Using the display as a game map (via SCREEN$) avoids a separate DATA array, saving significant memory.
• The string-AND idiom at line 70 for sprite selection is idiomatic Sinclair BASIC, exploiting the fact that "str" AND 0 returns "" while "str" AND 1 returns "str".
• The ghost restores dots/pellets it passes over (lines 190–195), but only at the previous position z1, x1 — this correctly handles one step of memory but could misfire if the ghost backtracks across a pellet it already consumed.
• Line 140 uses SCREEN$ (v,h)="" to detect the player walking into the ghost; this works because the ghost was just printed at z,x using UDG \i, and the player moves into empty space — the condition is fragile but functional given the fixed draw order.
• The session high score (hi) is initialized to 0 at line 20 and persists across replays since GO TO 30 (not GO TO 20) is used at line 2050.