Gladiators

Gladiator is a two-player combat game in which two sprite characters fight each other on a bordered arena screen, each controlled by a pair of keys (Z/X for Player 1, N/M for Player 2). The program uses eight-row by six-column string arrays (A$–H$) to store multiple sprite frames for each gladiator: standing poses, attacking poses, and death animations, all drawn using ZX81 block graphics characters. Collision detection is handled by checking whether the two players’ column positions differ by exactly six (line 1240), which triggers the attack subroutine at line 2000. Hit resolution is randomised with a 50% probability (RND*10 > 5), reducing each player’s hit counter from 9 to 0, and when either reaches zero the corresponding death animation and scrolling victory message are displayed.

---

Program Analysis

Program Structure

The program is organised into clearly separated regions, navigated primarily by GOTO rather than structured subroutines:

1. Lines 1–2: REM header and immediate GOTO 7000 to bypass all game code on first run.
2. Lines 450–999: Screen setup routine — draws the arena border, score display, and title graphic using block graphics strings.
3. Lines 1000–1300: Main game loop — renders both gladiator sprites at their current column positions, reads keypresses, enforces boundary limits, and checks for combat range.
4. Lines 2000–2500: Attack subroutine — draws attack-pose sprites for both fighters, applies random hit logic, updates scores, and checks for death conditions.
5. Lines 3000–4000 / 5000–5100: Death sequences for Player 2 and Player 1 respectively, showing a flashing kill message before jumping to the end screen.
6. Lines 7000–7186: Initialisation — sets starting positions and scores, then DIMs and populates all eight sprite arrays.
7. Lines 8000–9220: End/title screen — scrolls the display clear, draws a decorated title panel, shows instructions, and waits for a keypress before restarting.

Sprite System

All character graphics are stored as fixed-length string arrays, each row being six characters wide and eight rows tall, using ZX81 block graphic characters embedded directly in string literals. Eight separate arrays cover the different animation states:

Array	Purpose	Rows used
A$(8,6)	Player 1 standing	1–8
B$(8,6)	Player 2 standing	1–8
C$(6,6)	Player 1 attacking	4–6
D$(6,6)	Player 2 attacking	4–6
E$(8,6)	Player 2 dying	4–8
F$(8,6)	Player 1 dying	4–8
G$(8,6)	Player 1 victory	1–8
H$(8,6)	Player 2 victory	1–8

Only a subset of rows in the attack and death arrays are explicitly populated; the others remain as spaces (the default after DIM), which effectively erases the upper body when those frames are drawn — a deliberate cropping technique rather than a bug.

Main Game Loop

The loop at lines 1000–1300 is tight and unconditional. It redraws both sprites every iteration regardless of input, then samples INKEY$ four times in sequence (lines 1040–1055) for the four movement keys. Because each IF INKEY$= is a separate statement, only one key can be acted upon per pass, and holding multiple keys will only register one. Boundary clamping follows immediately (lines 1200–1260), and the loop ends with an unconditional GOTO 1000.

Collision and Combat Detection

Combat is triggered exclusively by line 1240: IF Y=Z-6 THEN GOSUB 2000. This means the attack subroutine fires only when Player 1’s column position Y is exactly six less than Player 2’s column Z. There is no symmetric check (i.e. Player 2 moving left into Player 1 does not trigger combat), which means combat can only occur with Player 1 to the left of Player 2 at that precise distance — a significant gameplay asymmetry.

Hit Resolution

Within the attack subroutine, each hit is resolved independently with a 50 % probability:

• K = INT((RND*10)+1) → if K>5, Player 1 loses a hit point (V).
• N = INT((RND*10)+1) → if N>5, Player 2 loses a hit point (J).

Both players start with 9 hit points. The subroutine does not return normally to the main loop — after updating scores and checking for death, control falls through to GOTO 1030 (line 2500), bypassing the boundary check at lines 1200–1260 for that iteration.

Death and End-Game Sequences

When a player’s hit counter reaches zero, the program jumps directly to a death animation block. A FOR N=1 TO 40 loop alternates between printing the kill message in normal and inverse video, creating a flashing effect. Both death routines then jump to line 8000, the shared end screen, which uses SCROLL in a loop to wipe the display before showing the title/instructions screen and waiting on IF INKEY$="" THEN GOTO 9192.

Screen Layout

The arena is drawn with a decorative border using block graphic characters (▀ top, ▄ bottom, ▌ sides) at lines 500–900. The title graphic at lines 911–915 spells out “GLADIATOR” in inverse characters surrounded by block art. Player scores are printed at fixed positions (AT 2,10 and AT 2,26) and refreshed only when a hit occurs, not every game loop iteration.

Notable Techniques and Idioms

• The entry point bypass (GOTO 7000 at line 2) ensures initialisation always runs before game code, while keeping the functional game code at lower line numbers for faster lookup.
• The end screen uses FAST (line 8025) before the heavy block-graphic printing and SLOW (line 8100) before the text display, managing display speed deliberately.
• Lines 9200–9220 (CLEAR / SAVE / RUN) are utility lines for saving the program with auto-run, not part of normal execution flow.
• The flashing kill-message technique (alternating normal/inverse strings in a tight loop) is a common ZX81 animation idiom requiring no timing hardware.

Bugs and Anomalies

• Line 9195 jumps to line 3, which does not exist. This is a deliberate technique — on the ZX81, GOTO to a non-existent line number jumps to the next higher line, which here is line 450 (the screen setup routine), effectively restarting the game without re-initialising scores or positions.
• The attack-range check (Y=Z-6) is one-directional; if Player 2 moves to within range from the left side, no combat occurs.
• Line 7178 contains %"\ : — a literal quote character inside the string literal for H$(4), likely a data entry error producing unexpected graphics in that sprite row.
• Line 7180 contains %$\' and line 7182 contains \## — the $ and ## sequences are not standard zmakebas escapes, suggesting possible corruption or non-standard characters in those sprite rows.
• The attack subroutine is called with GOSUB 2000 but exits via GOTO 1030 rather than RETURN, making it effectively a jump rather than a true subroutine — the GOSUB stack entry is never cleared, which will cause a stack growth issue over a long game.