Kitchen Chaos

This program implements a kitchen-themed arcade game called “Kitchen Chaos” in which the player moves a pan (using Z and X keys) at the bottom of the screen to catch falling eggs. Three separate “flights” of eggs follow waypoint paths stored as coordinate pairs in DATA statements at lines 710–730, with each egg’s position animated through a 48-element array read into the three-row array v(3,48). User-defined graphics (UDGs a through u, 21 characters total) are loaded via machine-code POKEs at line 1010, providing the sprites for the pan, falling eggs, kitchen scenery, and decorative elements. The screen layout uses PLOT/DRAW for geometric outlines and CIRCLE for a clock-like decoration, while a short musical tune with paired note/duration data is played at game-over using a nested BEEP/PAUSE loop at lines 3010–3045.

---

Program Analysis

Program Structure

The program is organized into clearly delineated sections connected by GO SUB and GO TO jumps:

1. Initialization (lines 1–40): Declares all arrays, sets the high score, and calls the UDG loader.
2. Data load (lines 55–61): RESTOREs to line 700 and fills the waypoint array v(3,48).
3. Game reset (lines 90–190): Resets score, lives, position, and sprite counters, then draws the screen and optionally plays the title tune.
4. Main game loop (lines 500–590): Iterates over three sprite channels (n=1 TO 3), moves each active sprite along its waypoint path, handles player input, and checks for collision.
5. End-of-life handler (lines 600–650): Decrements lives, resets sprites, plays a sound flourish, and loops back to the game reset.
6. Game-over screen (lines 660–699): Displays the title, final score, and high score, then waits for SPACE.
7. Subroutines: Screen draw (900), score update (800), UDG loader (1000), and music player (3000/3010).
8. UDG data (lines 1020–1110): Binary data for 21 UDG characters (a–u).
9. Music data (line 3060): Note/pause pairs for the game-over tune.
10. Debug/utility lines (9000–9010): Print all UDGs to stream 3 for visual checking; not reached in normal play.

Array Layout

Array	Size	Purpose
v(3,48)	3×48	Waypoint coordinates (y,x pairs) for each of the three sprites
z(3)	3	Current index into each sprite’s waypoint list (steps by 2)
p(3)	3	INK color for each sprite (3, 6, 7)
i(3)	3	Active flag: 1 = sprite is moving, 0 = waiting for its start counter
s(3)	3	Frame counter threshold at which each sprite activates
d(3), e(3)	3 each	Previous draw position (row, col) used to erase the sprite’s last position

Sprite Animation Technique

Each of the three falling objects is represented by a two-cell tall UDG pair. The sprite positions are pre-encoded as (y, x) coordinate pairs stored in the v array, loaded from DATA at lines 710–730. On each iteration the pointer z(n) advances by 2, selecting the next waypoint. The previous screen position is stored in d(n) and e(n) and cleared with spaces before drawing at the new position (line 523), giving smooth flicker-free movement without CLS.

All three sprites share identical waypoint data (lines 710–730 are identical), so they follow the same path but are staggered by randomized activation counters s(2) and s(3) (line 130). Sprite 1 always activates immediately (i(1)=1, line 126).

UDG Loading

Line 1010 uses a single FOR loop from USR "a" to USR "u"+7 (covering all 21 UDG slots, 168 bytes) to POKE each byte read from DATA. This is the standard Spectrum/TS2068 UDG initialization idiom. The data at lines 1020–1110 contains the letter a embedded as a literal DATA value in several places (e.g., DATA 0,128,255,254,255,128,0,a,a,63,…), which would be read as the numeric variable a (initialized to 0 by default on the TS2068) — effectively substituting 0 for those bytes. This is either intentional (blank pixels) or an artifact of data entry using variable a as a shorthand for 0.

Collision Detection

Collision between a falling sprite and the pan is detected at line 531 by checking whether the sprite has reached row 17 (y=17) and whether the attribute at the cell one row below (ATTR (y+1,x)) is not equal to 7. Since the floor/pan area uses INK 7, a non-7 attribute at that position indicates the pan is not underneath, triggering the hit/death sequence. This attribute-based collision is a well-known Spectrum technique that avoids coordinate comparison.

Player Input and Pan Movement

Input is polled inside the sprite loop at lines 538–545. INKEY$ is checked without a PAUSE, so it is non-blocking. The pan (h column variable) jumps in increments of 10 columns (Z left, X right) clamped between 1 and 21, giving three discrete positions. The pan sprite is four UDG characters wide (UDGs \a\b\c\d) drawn at AT 18,h. The previous pan position is erased with four spaces at line 539 before redrawing at the new position.

Music and Sound

The game-over/title tune (subroutine at line 3000) reads note and pause pairs from line 3060. Each note is played with BEEP .1*pause,note followed by PAUSE pause and a short trailing BEEP .01,note. The variable le controls how many notes are played: 32 for the full tune (line 3005) or 13 for a short intro (line 170). A descending glissando (FOR f=60 TO 1 STEP -3) closes the sequence. In-game sound effects use short fixed-frequency BEEPs for movement and a rapid random-ink flash loop on collision (line 531).

Screen Construction

The kitchen background is built entirely in subroutine 900 using a combination of PRINT AT with block-graphic UDGs, PLOT/DRAW for geometric lines (window frame, counter edge), and CIRCLE for a clock face (line 973). Floor rows 19–21 are filled with solid-block characters (\:: = █) in INK 1 (blue). The high-score display at line 985 is updated each time the screen is redrawn.

Notable Anomalies and Notes

• DIM z(3) is declared twice — at line 5 and again at line 15 — with no effect other than redundancy.
• The DATA at lines 710–730 is identical for all three sprites, meaning all three objects follow exactly the same path. Variety comes only from staggered start times.
• Line 537 is referenced as a GO TO target at line 513 (IF NOT i(n) THEN GO TO 537), but the next existing line is 538, which is functionally the same jump destination. The missing line 537 is harmless because GO TO to a non-existent line falls through to the next higher line.
• Lines 9000–9010 are developer debug utilities that print all UDG characters to the lower screen stream; they are never reached during normal execution.
• The scoring at line 810 awards 100*n points, making sprites 2 and 3 worth more than sprite 1 (200 and 300 vs. 100), adding difficulty incentive.