Alien Blaster

Alien Blaster is a single-player shoot-the-aliens game in which the player moves a cannon left and right along the bottom of the screen and fires upward to destroy descending alien invaders before five of them land. The program defines two custom UDG characters (loaded via READ/POKE USR into slots \\a and \\b/\\c) to represent the two alien types — a “Raider” and a “Droid” — each worth different point values depending on how far they have descended. Collision detection is handled by comparing the cannon’s pixel X coordinate (derived from its column position) against the alien’s column, using PLOT/DRAW to render the laser beam and OVER 1 to erase it. The game tracks a persistent high score in variable ss across replays, and scoring is calculated as b+(ch*2), rewarding lower-altitude shots and the higher-value alien type.

---

Program Structure

The program is organized into clearly separated functional blocks:

1. Lines 10–50: Initialization — UDG setup, high score reset.
2. Lines 60–110: Per-game setup and instructions prompt.
3. Lines 120–290: Main game loop — alien descent, cannon movement, firing.
4. Lines 300–420: Alien landing, game-over sequence, replay prompt.
5. Lines 430–580: Multi-page instructions screens.
6. Lines 590–630: Title screen subroutine with musical sweep.
7. Lines 640–670: Game-over sound effect subroutine.
8. Lines 680–700: Column-correction subroutines selected by w based on alien spawn position.
9. Line 710: Instruction page header subroutine.
10. Lines 720–740: UDG DATA for the two alien shapes (24 bytes total).
11. Lines 750–760: SAVE with auto-run and a restart stub.

UDG Character Loading

Lines 40 reads 24 bytes of DATA in a FOR/NEXT loop using POKE USR "\\a"+n to define three UDG slots (\\a, \\b, \\c), each 8 bytes. Two alien sprites — Raider (\\b) and Droid (\\c) — are selected in-game by the random variable ch (1 or 2), displayed as CHR$(ch+144). The cannon is drawn with the third UDG (\\a).

Alien Spawning and Column Correction

An alien’s column c is chosen randomly in the range 1–30. Lines 160–180 then select subroutine address w based on the column value: columns 1–5 call line 690 (c=c+1), columns 6–25 call line 700 (no adjustment), and columns 26–30 call line 680 (c=c-1). This prevents aliens from spawning so close to the screen edge that the three-character sprite would be clipped.

Cannon Movement and Laser Firing

The cannon’s screen column is held in a, and its pixel X coordinate is calculated as x=(a*8)+12 at line 210. Movement uses the compact idiom on lines 220 and 280:

• a=a+(INKEY$="2" AND a<=28)-(INKEY$="1" AND a>=1)

This exploits the fact that boolean expressions evaluate to 1 (true) or 0 (false), incrementing or decrementing a in a single assignment with boundary guards.

Firing (line 240) uses DRAW INK 5;0,y to draw a vertical laser beam 120 pixels upward from z=31, then erases it with DRAW OVER 1;0,y, giving a flash effect. The BEEP provides auditory feedback.

Collision Detection

Collision is detected at line 330 by comparing the cannon’s pixel X position x against the alien’s expected pixel X, calculated as (c*8)+4. This is a purely arithmetic check rather than attribute or pixel reading. If they do not match, execution falls through to line 340 which jumps back to line 250 (the alien movement subroutine), continuing the descent without registering a hit.

Scoring System

Upon a successful hit (line 360), the score increment is b+(ch*2), where b is the alien’s current row (2–18) and ch is the alien type (1 or 2). This means lower-altitude (closer to landing) kills score more, and the Droid (ch=2) is worth 4 extra points over the Raider. The cumulative score s is compared to the persistent high score ss at game over.

Sound Design

The program uses BEEP extensively for atmosphere:

• Title screen: a descending sweep FOR n=-10 TO 40: BEEP .1,40-n.
• Alien descent: BEEP .01,19-b creates a rising pitch as the alien approaches.
• Hit explosion: a short loop FOR n=-3 TO -1: BEEP .04,n produces a low rumble.
• Game over: subroutine at line 640 alternates tones with a nested loop structure.

Bugs and Anomalies

Line 650 contains a structural anomaly: BEEP .1,n:NEXT n appears after the loop at line 640 (FOR n=0 TO 2) has already consumed its NEXT n. This orphaned NEXT n will reuse the most recent loop variable n (value 3 after the FOR/NEXT at line 640), so BEEP .1,3 plays once and execution continues — a likely unintentional leftover of editing.

Line 200 prints the cannon using " \\a " (a space, the UDG, a space) but the sprite string in the listing appears as " \\a "; the alignment between the cannon’s character column a and its pixel coordinate x=(a*8)+12 is slightly offset by the leading space, which is compensated by the +12 offset in the pixel calculation rather than a pure column-to-pixel mapping.

The instructions loop at line 570 uses IF INKEY$<>"" THEN GO TO 120 followed by GO TO 570 — a correct wait-for-keypress pattern, but the key must still be held when line 570 is reached after line 570’s BEEP, which may occasionally require a long keypress to register reliably.