Android Nim

Android Nim is a two-player strategy game where the human competes against the computer to remove “android” figures from one of six rows, with the player removing the last android losing (or winning, depending on interpretation). The computer opponent uses a Nim-value algorithm based on binary decomposition: each row’s count is broken into base-2 digits across a 6×3 matrix, and a position is deemed “safe” (winning for the side that just moved) when all column sums are even. Custom UDG characters defined via DATA statements and POKE USR represent the android figures, with four two-character UDG pairs forming the body and three pairs for the legs. The animation subroutines cycle through UDG variants and use BEEP calls to produce sound effects when androids are highlighted or removed.

---

Program Structure

The program is organized into a main game loop and a set of clearly delineated subroutines. Execution begins at line 10, which initializes the UDG characters and displays the title/explanation screen before entering the game proper.

1. Lines 10–20: Initialization — RANDOMIZE, call explanation page (line 160), call UDG setup (line 210), then call board setup (line 380).
2. Lines 30–90: Coin-toss to determine who starts; computer move logic.
3. Lines 100–150: Human move input and validation loop.
4. Lines 160–200: Explanation/title display subroutine; also initializes p$.
5. Lines 210–370: UDG DATA and POKE loop; DIM and assignment of UDG string arrays.
6. Lines 380–400: Board setup subroutine — randomizes row lengths, draws initial androids.
7. Lines 410–460: Nim-value (safe/unsafe position) calculation subroutine.
8. Lines 470–520: Android animation subroutine — animates figures to “look” at the chosen row.
9. Lines 530–570: Android removal subroutine with animated erasure and sound.
10. Line 580: SAVE with autostart.

UDG Character Design

Lines 210–350 define 14 UDGs (\a through \n) using 8-byte DATA blocks, POKEd into UDG RAM via POKE USR "\a"+N. The 112 bytes cover 14 characters (14×8=112). These are organized as four two-character “body” pairs (a$(1)–a$(4)) representing different android poses, and three two-character “leg” pairs (b$(1)–b$(3)). Note the DATA at lines 210–340 contains the letter O (or o) instead of the digit 0 in several places — these will be read as 0 by READ/DATA on this platform but represent a data-entry anomaly.

Nim Strategy Algorithm

The computer’s winning strategy is implemented in the subroutine at lines 410–460. It performs a standard binary (base-2) Nim analysis:

• Each row’s count is decomposed into its base-2 digits (ones, twos, fours) stored in array b(n,1..3).
• For each binary column, the subroutine counts how many rows have a 1-bit in that position and stores whether that sum is odd in c(n), using the idiom c(n)=(c(n)<>b(m,n)) which toggles a boolean.
• c is set to the sum c(1)+c(2)+c(3); a value of 0 means the position is “safe” (the previous player is in a winning position in standard Nim theory).
• The computer first tries a random row (line 50); if that doesn’t yield a safe position, it systematically searches all rows and removal counts (lines 70–80) until it finds a move that makes c=0.

The subroutine accepts a hypothetical move via parameters d (row) and e (new count after removal), substituting them into the position before evaluation, so no actual board modification is needed during search.

Animation Subroutines

The subroutine at lines 470–520 animates androids to “face” the selected row. It distinguishes three zones: rows above the target (lines 490), the target row itself (line 500), and rows below (line 510). Each zone cycles through different UDG pose indices (q) and leg pairs (p) in different orders, giving a directional appearance. BEEP calls are woven into the animation loops with pitch values computed from loop variables, producing a cascading sound effect.

The removal subroutine (lines 530–570) cycles through all four body UDGs and all three leg UDGs per android being erased, accompanied by a sliding BEEP pitch, finishing with a FLASH display and a long 1-second BEEP before blanking the cell.

Key BASIC Idioms

• p$= CHR$ 22+ CHR$ 21+ CHR$ 0 (line 200) constructs an AT 21,0 control sequence stored as a string, used throughout to reposition the cursor to the bottom of the screen for status messages.
• PAUSE VAL "100" uses VAL on a string literal as a minor memory optimization to encode the numeric argument.
• Input validation at lines 100 and 120 is done inline using chained IF conditions on LINE z$, checking string length and character range before converting with VAL.
• Row totals are accumulated with LET a=0:FOR n=1 TO 6:LET a=a+a(n):NEXT n to detect end-of-game (all rows empty).

Notable Anomalies and Bugs

• Letter O in DATA: Lines 210–340 use the letter O (or o) where the digit 0 is clearly intended in the UDG bitmap data. BASIC’s READ will accept these as 0 due to implicit VAL conversion only if the implementation is lenient; on a strict interpreter this would cause a “Invalid argument” error. This is almost certainly a transcription error.
• Variable name collision: The program uses both an array a() (row counts) and a plain variable a (selected row / temporary accumulator) throughout. Spectrum BASIC treats these as distinct, but the dual use makes the logic harder to follow and could cause confusion if not carefully managed — the code does handle this correctly by context.
• Computer move randomness: Line 50 picks a random row a (1–6) and checks a(a)>0 (non-empty) and NOT c (unsafe position), but the check is done with the original d=1, e=a(1) evaluation from the GO SUB at the start of line 50, not with the randomly chosen a. The random selection affects the jump to line 90 but the position evaluation is of row 1. This means the “random first try” does not correctly evaluate whether the random row leads to a safe position — the systematic search at lines 70–80 is what actually finds the correct move.
• Android display orientation: In the board setup (line 390), androids are always drawn with a$(1) and b$(1) (the first pose), while the animation subroutine uses poses 2–4 for body and 1–3 for legs. After animation the board is not reset to pose 1, so the display remains in whichever pose the animation ended on.

Variable Summary

Variable	Role
a(6)	Array of current android counts per row
a	Selected row (player/computer move); also used as temp accumulator
b	Number of androids to remove
b(6,3)	Binary digit matrix for Nim evaluation
c(3)	Column parity bits for Nim evaluation
c	Sum of column parities (0 = safe position)
d, e	Hypothetical row and count for Nim subroutine
p$	AT 21,0 control string for status line positioning
a$(4,2)	Two-char UDG strings for android body poses
b$(3,2)	Two-char UDG strings for android leg poses
z$	LINE input buffer for user responses
s	Random INK color offset (0–2) for android coloring