What Was Unique About Next Space

Next Space can be described in a single sentence: it is a game made in the 1990s by a small group of friends from Bratislava who built almost everything themselves. Here are the things that surprised us most as we studied it.

Video that fitted on a CD

The game contains 25 full-screen 3D animations. If they were stored as ordinary images, a single frame (640 × 300 pixels, 256 colours) would take up 192,000 bytes. At twenty frames per second, that comes to almost 4 MB per second. A CD-ROM drive at the time could manage 300 to 600 KB per second.

The authors therefore created their own video format, called HVI. As Peter Hegyi recalls, the player for it was written by Michal Weis and Michal Horka at machine-code level, so that it could manage 20 frames per second straight from the CD. The format works like this:

The screen is divided into 12,000 squares of 4 × 4 pixels each.
For each square only three bytes are stored instead of sixteen. One picks a sample from a “dictionary” of 256 entries; the second and third determine where each of the sample’s four colours goes, using one of eight patterns (stripes, diagonals, corners). The technical term is vector quantisation.
The result is compressed once more using standard LZSS-type compression.
Sound is added – always 1,102 bytes per frame – so that picture and sound never drift out of step.

Overall compression works out at roughly 10 : 1. Of those 192,000 bytes, about 18,600 remain on average. And from that, the player can rebuild the picture 20 times a second on a PC with a 1997 processor.

For comparison: videos compressed this way average 395 KB per second, not 4 MB. Without this compression, the 8.4 minutes of animation would take up 2 GB.

The dictionary and the colour palette change segment by segment within the file, so they can adapt to the scene.

Game rules as data

The key decision that makes Next Space an unusual game: the game’s logic is not in the program. The program is 284 KB in size and does not contain a single puzzle. All the puzzles, conversations and the order of events are stored in the data, in the room files, as bytecode for a simple internal language.

The interpreter understands 86 instructions and handles 3,772 rules (3,596 in the rooms and 176 general responses such as “I don’t know how to open that.”). Each rule has two parts: IF (conditions) and THEN (actions). For example, this is what a rule from the first screen outside the bar looks like, put into words:

IF the flag “Frank has just stepped out of the ship” is set and Frank has reached the spot (100, 320), THEN clear the flag, have Frank say “What am I, where am I?!”, then “Damn!” and “I have to explore this place properly!”, and hand control back to the player.

This has a practical advantage: puzzles can be changed without recompiling the program. The script is compact, too: the entire game logic takes up about 87 kilobytes (84 KB in the rooms and 3 KB of general responses). And, most valuable of all today: when we rewrote the game in JavaScript, we only had to write an interpreter for these 86 instructions – everything else came from the original data.

Music in four bits

The music files have the extension .MOD, so at first glance they look like classic tracker modules from the demoscene. They are not. They are custom compressed audio files in which every sample takes only 4 bits instead of 8. The method is called ADPCM and is similar to the one Yamaha used. Instead of the full value of each sample, only the change from the previous one is stored, and the step size adapts automatically to the volume.

The result: the music takes up half the space. Nineteen tracks (plus one silent file), 34.34 minutes in total, fit into 23 MB. At audio-CD quality (44.1 kHz, 16-bit, stereo) they would take 360 MB – more than half a CD.

The music loops in the game, and the authors also made the loop seamless: when playback returns to the start of a track, the decoder is reset so that the music joins up without an audible jump.

Actors in painted scenes

The human characters in Next Space are digitised real people. This is how the game places them in a scene:

Size by depth. Every room has a depth map. When Frank walks away from the viewer into the background, the game shrinks him on the fly (using integer arithmetic, for speed) and adjusts his walking speed to match.
Order by height. Characters are sorted by how far down the screen they stand, so that they overlap furniture and other objects correctly.
Soft edges. Character edges are blended into the background using a separate 256 × 256 colour table, so that they do not look as if they had been cut out with scissors. Every room has its own.
Shared palette. The first 56 colours are the same throughout the game. Frank, who is made up of only 22 shades, can therefore stand in any room and look right.

Voice acting without lip-sync

Some 1990s games handled voice acting by synchronising a character’s lip movements with the voice. Next Space does not do that. Instead it works like this:

Every line has a number. The on-screen text and the recording share the same number. The game therefore knows which recording to play, without anyone having to pair them up by hand.
While the voice is playing, the character runs a generic talking animation.
Subtitles and voices can also be switched on independently.

The upside: the game can be localised without redrawing the characters. The Slovak and Czech versions use the same logic, only with different texts and a different voice track. The Slovak version has 2,935 lines, 2 h 54 min in total. The Czech version has 2,935 lines, totalling 2 h 48 min.

Walking routes that work

Less visible, but just as important:

Character walking. Every room has a “where you can walk” mask (320 × 200 bits). The route is found by flood fill (BFS) and then smoothed into straight segments using line of sight. It works even when other characters are moving around the room.
Drawing only the changes. In every frame the game redraws only the four-pixel segments that have changed. On a slow computer, this was what kept the game running smoothly.
Room compression. Everything large in the ROOMn.DAT files is compressed with the LZSS method (Okumura), which the authors also implemented in assembler. All 651 compressed blocks unpack to exactly their declared size.
Saved games. A saved game is a dump of 58 blocks of memory (flags, variables, inventory, the state of objects and characters).

Traces the authors left behind

Reading the files also reveals the human side of the work:

Notes in the texts. The message tables contain lines that are not meant for the player, in Slovak: ”--- keď prídeš za …” (roughly “when you go to see …”), ”--- FIRE ---”, ”--- loop”, “po zlom horení záchoda” (roughly “after the bad burning of the toilet”). This is how the authors noted what comes next in each scene.
A path in an animation header. The original file path from the computer on which the animation was made (D:\ANIM-NOV\DOLE\POSUNUTE.CEL) was written into one animation file. This shows that the team probably worked with Autodesk Animator Pro (both the FLC format and the .CEL extension come from it).
Unused rooms. Room 52 is a copy of room 1 with English test messages (I don’t know how to open it). Room 54 is not a real room but a black screen for deaths and the credits.
Fixes between releases. The Slovak CD dates from June 1997, the Czech one from September. In between, the authors fixed 14 rooms, while 631 of the program’s 681 functions remained identical, instruction for instruction, and all 86 script instructions behave the same way. The most serious fix was for a freeze in room 37.

Why this matters

Any one of these would merit an article of its own. Together they show that the makers of Next Space relied on nothing off the shelf: their own codec, their own scripting language, their own sound mixer, their own sound-card driver. And all this was done by a group of students and enthusiasts for whom it was their first project, and who worked on it for more than four years.

That is why the game can run in a browser today from its original data: everything it needs to know is in the data and in a small interpreter.