Keep and share the game

Meteor Storm is finished. This lesson adds no new game code. It checks the release the way a player would meet it, loading from tape on a fresh machine, and gathers the files you need to build that tape yourself and share it.

The browser experiments in these lessons place the program straight into a prepared machine. That proves the code runs, but a tape someone else loads has to work from nothing: through the ROM, from a cold start, with the sound on.

What the release is made of

The tape is built from the files in the final checkpoint’s folder:

The program includes assets.inc, and screen.asm includes meteor-storm.scr, so keep them all in one folder. Saving only the assembly file leaves its include missing. You can download the program and assets.inc from the editor below as well.

With Asm198x and Build198x installed, these commands build the tape in that folder, the same steps as unit 35’s Makefile:

mkdir -p build && cd build
build198x basic ../loader.bas --machine sinclair-zx-spectrum -o meteor.tap --name meteor
asm198x --dialect pasmo --cpu z80 --tap ../screen.asm -o screen
asm198x --dialect pasmo --cpu z80 --tap ../meteor-storm.asm -o storm
cat meteor.tap screen storm > ../meteor-storm.tap

The editor’s tape download is something else. It assembles whatever is in the two editors into a tape with a minimal loader and no loading screen. It is the quick way to try a change on a real tape. Edits that have not been run yet are still included in that download, so test the version you intend to distribute. Revert restores both editors.

Load what you will share

The player at the top of this page loads the release tape through the ROM. To load your own build, open the Sinclair ZX Spectrum page, press the play button under its screen and tick Sound, which starts unticked. Press Choose program or disk, pick your meteor-storm.tap, then press Start. The ROM loads the tape on its own; you will hear the loading tones. Click the screen before using the keys.

On the desktop, start a fresh 48K Spectrum in Emu198x, the recommended emulator, with the tape loaded. From the emulator’s folder, this command does that and enters LOAD "" and plays the tape for you:

./emu198x-spectrum --rom "path/to/48.rom" --machine spectrum_48k --tape meteor-storm.tap --autoload-tape --scale 3

Replace the paths with your ROM and tape locations; getting started covers downloading Emu198x and the ROM it needs. In another 48K Spectrum emulator, mount meteor-storm.tap, enter LOAD "" and start tape playback.

Then work through the game:

• While it loads: the screen turns black, and the loading screen appears and stays up, with no message printed over it, until the game starts.
• The title: its colour bands, SPACE TO LAUNCH flashing at the top, and the first storm falling behind the text. Space launches after you release it.
• In flight: O/P steer and held Space boosts. The time and speed are cyan over a white score, and STORM 1/5 sits at the top right. Each meteor changes colour as it falls.
• The sounds: a chirp for a star, a lower one when you press Space in flight (and none while you keep holding it), and a rising fanfare in clear space.
• A crash: the border flashes red, the storm freezes, and the ship breaks into eight pieces that land during a rattling, falling tone. About a second later the result appears, with a black border and no pieces left.
• Clear space: the fanfare, then two seconds of CLEAR SPACE with the bonus and its multiplier, then the next storm with the clock at 00.00, the ship in the centre and the storm’s own colours. From the second storm on, meteors fall faster and closer together.
• The records: retry after a crash, then return to the title. BEST STORM and BEST VOYAGE survive within the session, and the title shows the voyage record.

If the storm is all white, the border stays red, clear space ends the game after one storm or the title is still, you are not running the finished program.

A snapshot saves a machine’s state and can be useful while investigating a fault. It is not the same evidence as a fresh ROM load of the tape: a snapshot can preserve an already configured stack, interrupt mode or record that a fresh launch has not set up yet.

Choose a next experiment

Keep a working copy before changing the game. Try one design change with a prediction: a different set of storm rules, a sixth storm, revised star artwork, a new sound or your own loading screen. State which behaviour should change and which should stay the same, then retest collision, retry, clear space and the records. For a sound, work out its length in T-states first: a star or boost sound plays in the time an update leaves over, and one longer than that is split across several waits and flutters. For storm rules, keep every gap cut below the smallest delay.

We have built a game whose positions and rules live in state, whose picture is drawn from that state, and whose progress is measured separately from time. Its sounds are data too, and the ones heard in flight play in time the game would otherwise spend waiting. Even its crash is state: eight small records, moved by one rule and drawn from the ship’s own artwork. Its colours belong to places, not objects, so nothing ever clashes. Its storms are data: five courses chosen by one address, and five records of rules that make each harder than the last. And it presents itself the way games of its time did, with a title that plays itself and a picture to watch while the tape loads. Those ideas will still matter when another game needs a different renderer, more objects or a different machine.