Brick-Yard Bill

Brick-Yard Bill is a maze-navigation game in which the player steers a character (UDG “b”, a stick figure) around a yard filled with randomly placed bricks (UDG “a”) using the cursor keys 5–8, trying to avoid becoming completely surrounded. The playing field is a 20×32 bordered arena drawn with repeated UDG “a” brick characters; obstacle placement uses ATTR reads to detect occupied cells before randomly positioning each brick, ensuring the field is navigable at start. Scoring is calculated as a percentage of the yard covered with bricks, derived from the formula INT ((score*100)/(599-h)), where h controls difficulty and increases by 10 each round if the player scores 80% or above. The title screen features a scrolling marquee implemented by rotating a long string one character at a time with a$(2 TO )+a$(1), with BEEP pitch derived from CODE a$(28)/4 to produce a musical accompaniment. A cumulative score variable fr accumulates percentage scores across rounds, and the hi-score persists for the session.

---

Program Analysis

Program Structure

The program is organized into clearly separated functional blocks, each introduced with a REM comment:

1. Lines 11–17: UDG definition, subroutine call for instructions, variable initialization
2. Lines 18–55: Game setup — draws border, places bricks randomly, plays intro tune
3. Lines 60–500: Main game loop — draws player, waits for keypress, dispatches to movement routines
4. Lines 1000–1090: LEFT movement (key 5)
5. Lines 2000–2090: DOWN movement (key 6)
6. Lines 3000–3090: UP movement (key 7)
7. Lines 4000–4090: RIGHT movement (key 8)
8. Lines 5000–5095: End-of-game scoring and round transition
9. Lines 6000–7000: Instructions subroutine
10. Lines 9998–9999: SAVE/VERIFY

UDG Definitions

Two UDGs are defined at the start via READ/POKE loops:

UDG	Character	Data bytes	Role
\a	Brick	0,119,119,119,0,238,238,238	Wall/obstacle tile
\b	Bill (stick figure)	24,24,60,90,153,36,36,102	Player character

The brick UDG uses alternating byte patterns (119 = 01110111, 238 = 11101110) to create a half-brick offset pattern. The stick figure bytes sketch a recognizable humanoid: head (24=00011000), arms (60=00111100), body (90=01011010), legs (36=00100100), feet (102=01100110).

Arena Construction

The border is drawn by printing a full row of 32 \a bricks at rows 0 and 21, and single bricks at columns 0 and 31 for rows 1–20. Bricks are placed randomly in the interior with the following constraints enforced in the placement loop (lines 45–50):

• Row must not be 10 (reserved for possible player start area)
• The cell must have ATTR value ≤ 100 (unoccupied) — the ATTR of a placed brick with PAPER 7, INK 2, BRIGHT 1 is above 100
• h bricks are placed per round, starting at 20 and increasing by 10 each time the player scores ≥ 80%

Movement and Collision Detection

Each directional routine checks the target cell using ATTR before moving. If the attribute exceeds 32 (indicating any non-default coloring, i.e., a brick or border), movement is blocked and control returns to line 100. After each move, the old position is overprinted with \a (a brick), effectively leaving a trail and permanently reducing the navigable space.

The entrapment check at line 455 uses a compound AND condition testing all four neighbors:

• ATTR (x+1,y)>32 — below
• ATTR (x-1,y)>32 — above
• ATTR (x,y+1)>32 — right
• ATTR (x,y-1)>32 — left

If all four are blocked, the game ends via GO TO 5000.

Scoring Formula

The percentage score is calculated as INT ((score*100)/(599-h)). The denominator 599-h approximates the total number of moves available in the interior. With h=20 (round 1), this gives a divisor of 579. The cumulative score fr accumulates these percentages across rounds and is used as the displayed running total. A hi-score hi tracks the maximum fr achieved in the session.

Scrolling Marquee Technique

The instructions screen at line 6095–6130 implements a character-by-character horizontal scroll by rotating the string a$ with a$(2 TO )+a$(1), then printing a 28-character window at AT 10,2. The BEEP pitch is generated from CODE a$(28)/4, producing a melody derived from the ASCII values of the scrolling text — a common technique for “typing” sound effects. The loop runs 136 iterations (0 TO 135), cycling the 136-character message string exactly once.

Notable Bugs and Anomalies

• Line ordering anomaly: Line 1024 appears after line 1030 in the listing. In BASIC, lines are executed in numerical order, so 1024 executes between 1020 and 1025 — the listing is misleadingly formatted but functionally correct as entered.
• Boundary clamping: Lines 1035, 2035, 3035, 4035 clamp coordinates but allow the player to overlap with the border row/column, which may cause the player to appear inside the border.
• Unreachable lines: Lines 5160 and 5170 (the in-game description text) are never called from the main program flow and appear to be dead code from an earlier version.
• Typo in string: Line 5160 contains the misspelling “PRECENTAGE” (should be “PERCENTAGE”), which is unreachable anyway.
• BEEP duration at line 2050: BEEP .00,21-x uses a duration of zero, producing no audible sound during downward movement, unlike the other directions which use .01.
• Screen 1 score display: The score is printed to #1 (the lower screen) but position AT 0,1 addresses a row/column within the two-line lower screen area — row 0 of stream #1 maps to the first line of the lower display.

Key BASIC Idioms

• ATTR-based collision detection throughout — avoids maintaining a separate map array
• PAUSE 0 at lines 80, 5069, 6135, 6180 for clean keypress gating
• Directional routines as separate line-number blocks (1000/2000/3000/4000), cross-jumping between them to allow diagonal-feel movement when a key is held
• PRINT #1 for the status bar, keeping it separate from the main play area