Jack5

This program implements a two-entity maze/grid game featuring a player character and an adversary named “Jack,” with UDG (User Defined Graphics) characters defined via DATA statements at line 1460 onward. The player sprite is drawn using CHR$ 144–148 UDGs loaded at startup, and movement is controlled via keys 5–8 in the Sinclair cursor-key layout. The arena is constructed using a layered PRINT routine with a re-entry flag variable `f` that allows the same PRINT lines to be reused both for initial drawing and partial redraws via GOSUB. Scoring tracks both a session score and a high score stored in variables `s` and `h`, with the high-score holder’s name captured via INPUT and limited to 11 characters. A short melody is played at game start using BEEP with note and duration data in lines 1260–1270, and collision detection relies on SCREEN$ and ATTR reads rather than coordinate arrays.

---

Program Analysis

Program Structure

The program divides into several functional phases executed in sequence:

1. Initialization (lines 10–70): Variables zeroed, player name defaulted to “Jack”, UDGs loaded from DATA.
2. Arena drawing (lines 80–300): The play-field border and interior are printed using a layered approach controlled by flag f.
3. Game intro / melody (lines 310–330): GOSUB to line 1230 plays a startup tune and displays the high score.
4. Main game loop (lines 340–910): Handles player movement, adversary movement, collision detection, and scoring.
5. Subroutines (lines 920–1450): Adversary steering (920), scoring/game-over (1050), bonus target placement (1340/1390), intro melody (1230).
6. UDG DATA (lines 1460–1500): Eight-byte sprite bitmaps for five UDG characters.

UDG Sprite Loading

Lines 30–40 load 64 bytes (8 bytes × 8 UDGs) from DATA starting at line 1460 directly into UDG RAM using POKE USR "\a"+b,c. The variable b iterates 0–63, so UDGs \a through \h are all populated. The sprites include directional arrow/ball shapes used for both the player (\f) and adversary (\h) characters, as well as target markers (\g).

Note that the DATA at line 1460 contains the literal identifier C rather than a numeric constant, and line 1480 also uses C and y as DATA values. Since y=0 at startup and c=144 during the game, this is intentional reuse of variable names inside DATA statements — a known BASIC technique where READ resolves variable names in DATA as their current values.

Arena Drawing with Re-entry Flag

The arena is drawn once at startup by executing lines 90–290 sequentially with f=0. After the full draw, f is set to 1 at line 300 and a GOSUB to line 250 is issued. The IF-THEN-GO TO and IF-THEN-RETURN guards at lines 100, 120, 140, etc. create a jump table: when re-entered with f=1, execution falls through until it hits the matching guard and either RETURNs or jumps to a specific row’s PRINT statement. This allows individual screen rows to be redrawn without reprinting the whole arena.

Movement and Collision Detection

Both the player and the adversary use a direction-vector scheme. The player uses du (delta-row) and dp (delta-column); the adversary uses da and dt. Collision with walls is detected by reading SCREEN$ at the target cell before moving (lines 520, 540). When a wall is hit, the direction vector is rotated 90 degrees by swapping and negating components (lines 1180–1220), implementing simple billiard-ball reflection. The player sprite CHR$ code c increments on each wall bounce (lines 1180, 1190) cycling through UDGs 144–148 to show a directional arrow graphic, with wrap-around at 148.

Adversary Steering Logic

The subroutine at line 920 implements rudimentary homing behavior for the adversary (“Jack”). Variables lj and lf represent “lane” positions for the player and adversary respectively. Each call to the subroutine moves lf one step toward lj (line 930) and adjusts the adversary’s trajectory components da/dt accordingly (lines 950–1030). The variable q acts as a steering rate limiter — it counts down from v (speed factor) before a direction change is applied (line 940). As the game progresses and v decreases (line 700), steering becomes more frequent and the adversary more aggressive.

Scoring and Difficulty Scaling

Two score variables are maintained: s (total session score) and s2 (level progress counter). Collecting a bonus target (\g) awards 1 point via s and s2 increments (line 690). Reaching the special target at coordinates (ba,rl) awards 5 points (line 1370). When s2 reaches 244, the speed variable v is decremented by a small RND amount and the arena is redrawn (line 700), increasing difficulty over time. Bonus targets are placed randomly but are excluded from the score display area rows 8–12 and from cells already occupied by walls or other targets (line 1420).

Input Handling

The main loop polls INKEY$ repeatedly. Lines 730–850 validate that the pressed key is in the range 53–56 (characters ‘5’–’8′, the Sinclair cursor keys). The movement logic at lines 810–820 computes new coordinates only along the axis perpendicular to current travel: if moving vertically (dp≠0), only left/right keys 5/8 are accepted, and vice versa. This enforces grid-aligned movement typical of snake-style games. The expression ((i$="6")-(i$="7")) computes +1, 0, or -1 inline without branching.

High Score Persistence

The high score h and name e$ are stored in variables that persist across game restarts since the game loops back to line 50 (not line 10) on game over. Line 1130 prompts for a new name only if the session score beats the stored high score, with a length check enforcing a maximum of 11 characters. If the name is too long, the game loops back to line 1050 (the game-over handler) rather than to the name prompt directly, which re-triggers the musical fanfare — a minor behavioral quirk.

Notable Techniques

• PAPER PI at line 60 uses the fact that INT PI = 3 to set PAPER color 3 (magenta) without a numeric literal.
• Color strings y$ and z$ are prebuilt at line 50 using CHR$ 16+CHR$ color+char as embedded control sequences, avoiding repeated INK keywords in the arena-drawing PRINTs.
• The DATA at lines 1260–1280 encodes a two-phrase melody (resembling “Happy Birthday”) with note pitch and duration pairs read by the BEEP loop at lines 1280–1300.
• ATTR (a+da,t+dt)>128 at line 560 detects inverse-video cells (ATTR values ≥128 indicate FLASH or BRIGHT with INVERSE), used to identify special screen objects without checking the character itself.
• Line 500 uses BEEP .01,0 triggered on any keypress before the direction-check, providing tactile audio feedback independently of movement validity.

Potential Bugs and Anomalies

• Line 790 reads j from DATA at line 750, but the DATA contains the string "6" not a number, so j will receive 0 (or cause an error) unless the BASIC interpreter coerces the string. The intent appears to be checking whether du=0 or dp=0, using variable names as DATA values similar to the UDG DATA technique, but du and dp are not in the DATA — only the literal strings "6", "7", "5", "8" and the variable name du/dp written as bare identifiers. This section of movement validation may not function as intended.
• At line 1130, if the entered name is too long, PRINT AT u,p-5 uses the last player position, which may be off-screen or overlap game graphics depending on where the player died.
• The variable i$ is set at line 720 but lines 810–830 also read INKEY$ directly rather than using i$, meaning a key released between line 720 and line 830 could cause i$ and the inline INKEY$ reads to disagree.