Cannon Balls

Cannon Balls is a single-player arcade-style game in which the player moves a catcher left and right along the bottom of the screen to intercept bouncing cannon balls fired from a cannon. The game tracks score, remaining cannon balls (starting at 50), and catchers (starting at 7), ending when either resource reaches zero. Four custom UDG characters (A–D) are defined at startup using POKEd pixel data to render the cannon, cannon ball, and explosion graphics. Ball movement uses independent horizontal and vertical delta variables, with ATTR checks used to detect collisions with the catcher and walls rather than coordinate comparison alone.

---

Program Structure

The program is organized into clearly labeled sections separated by REM statements, using high line numbers for subroutines and setup routines:

Lines	Section
1–30	Header and high-score initialization, then jump to UDG setup
100–190	Main game loop
200–230	Row 17 collision: catch or lose catcher
300–340	Row 18 bounce (floor)
400–430	Row 14 bounce (ceiling/cannon level)
500–510	Ball exits right edge; deduct cannon ball
900–930	Opening screen and instructions
1000–1600	Stage setup: floor, cannon graphics, HUD
2000–2999	Variable initialization and ball launch
3000–3600	Catcher destroyed sequence
4000–4500	Game over closing animation
5000–5600	New game / high score handling
6000–7200	UDG definition via DATA and POKE, then jump to opening

UDG Graphics

Four UDG characters are defined at lines 6200–7100 using a FOR/READ/POKE USR loop. The character letter is itself read from a DATA string, making the loop compact:

• "A" — lower cannon base (two pixels, bottom rows only)
• "B" — upper cannon base (two pixels, top rows only)
• "C" — cannon ball (solid rounded shape, z=255 used for full rows)
• "D" — explosion/hit graphic (circular burst pattern)

The variable z is set to 255 at line 6100 as a shorthand to avoid typing the literal three times in the DATA at line 7000, reducing keystrokes and potential entry errors.

Ball Movement and Collision Detection

The cannon ball position is tracked by column a and row d, with directional deltas aa (horizontal) and dd (vertical). Movement is applied at line 150. Collision logic is row-based:

• Row 17 (lines 200–230): Uses both ATTR and SCREEN$ checks. If ATTR matches the catcher’s destroyed state (46) and the impact flag i=1, the catcher is lost. If SCREEN$ returns "y" (the catcher character) and i=1, a successful catch is scored (+5 points).
• Row 18 (lines 300–330): Ball bounces vertically; horizontal direction may randomly reset to zero using INT(RND*2+1).
• Row 14 (lines 400–420): Ball bounces back down; horizontal delta is forced to 1 and impact flag i set to 1 (ball is “live” for catching).
• Column >31 (line 100/500): Ball exits the right side, costing one cannon ball from j.

The flag i distinguishes a ball traveling downward from cannon (catchable) versus one still ascending or bouncing along the floor (not catchable), preventing false catch detections.

Catcher Movement

Line 120 handles catcher movement in a single expression using Boolean arithmetic — a common Sinclair BASIC idiom:

LET f=f+(INKEY$="8" AND f<=29)-(INKEY$="5" AND f>=11)

Keys 8 (right) and 5 (left) are read, with boundary clamping built into the Boolean conditions. Movement is only read after each ball-position update, so the catcher responds once per game loop iteration rather than in a separate polling loop.

HUD and Score Display

The heads-up display printed at lines 1400 and updated throughout tracks: current score (s), high score (h), remaining cannon balls (j), and remaining catchers (g). The high score h is initialized once at line 20 (LET h=0) and persists across games within a session; it is only updated at line 5400 when the session ends.

Game Over and Restart

The closing sequence (lines 4000–4500) runs a border color cycling loop three times, counting down from 7 to 0 with an accompanying BEEP tone for each step. After the animation, lines 5100–5300 wait for the Enter key (CHR$ 13) using a tight IF INKEY$ polling loop before resetting state and jumping back to line 2000 to reinitialize variables without recreating the stage graphics.

Notable Techniques and Anomalies

• Line 300 contains IF ATTR(d,a)=30 THEN LET a=a-1: LET aa=0 — this detects a wall attribute at row 18 and nudges the ball left, preventing it from embedding in a wall tile.
• The cannon firing animation at line 2950 uses a sequence of PRINT AT placements with UDGs A and D, followed by erasure, to simulate a muzzle flash.
• At line 1200, the cannon is assembled from multiple UDG characters using TAB 0 to return to column 0 after each row segment within a single PRINT statement — a compact multi-row sprite technique.
• The FOR a=1 TO 20 sound loops at lines 930 and 1600 play ascending then descending BEEP sequences (and vice versa) as stage transition fanfares without requiring separate subroutines.
• Line 110 erases the previous catcher position before redrawing, but the erase is conditional on ATTR(17,f)<>40 — this avoids accidentally blanking the catcher if the attribute already matches a non-catcher tile.