Little secrets of big savings

Why 16 bytes is enough to save the game, and other little things

Fifty and a hundred years later, programmers will have all the same problems: they will very much miss the amount of available memory to implement everything they want.

25 years ago, game cartridges contained 64–128 kilobytes of memory, but somehow this volume was enough to fit the game for tens of hours of gameplay. Today, 128 kilobytes is the size of small JPEGs, and what's available in a modern consumer computer in the era of Super Mario Bros. do not even have to dream.

There were music, and sounds, and quite good graphics for those times. Yes, some could be done using what was already in the game console or computer, but basically I had to go for various tricks to fit a huge amount of sounds, music, animation, images and game algorithms into these modest possibilities. How did the developers of those years manage to do it?

The main secret: the games were written in assembler, that is, you had to almost directly tell the processor which operations to perform. This is the cause and the consequence: it would be difficult to work on large projects written at such a low level.
')
Another small detail: a lot of software needs to be written so that another programmer after you can edit and correct it. Game developers for the Atari 2600, Sega Master System, NES and SNES, and even later consoles of the late 90s such as the PlayStation 1 or Nintendo 64, had nothing to worry about: why would anyone outside the team know how the product works? After the release, nothing can be fixed, the patch on the cartridge can not be rolled. On the contrary, it was preferable to avoid all hackers who released cheat systems, for example, Game Genie . The games had almost complete control over the console without any operating systems, so there was no need for a multi-layered architecture that is crammed into all modern products to improve independence from software and hardware.

Basic techniques include maximum code reuse, the same functionality has been used over and over. The same thing happened with the data: AI, graphics, music, sounds, they were only slightly changed to create the illusion of diversity. Games could generate code and data needed for execution, but this complicated debugging. Avoid the use of meaningless large arrays. Often their own libraries were written.

A bitmap of 16 colors does not take up much space, a block of 20 × 20 pixels will require only ½ × 20 × 20 = 200 bytes. For one processor cycle, you can process 2 pixels.

The graphics had a low resolution and was two-dimensional. But it was possible to successfully deceive feelings with the help of pseudo-3D or 2.5D. The most famous 2.5D auto simulator is the 1984 Rad Racer . The Lotus Esprit Challenge (right) of 1992 looks plausible enough.

The 2.5D elements are Doom and Wolfenstein 3D first-person shooters. On the left is a fragment of The Train: Escape to Normandy (1987) for Commodore 64 .

Music was generated on the fly, no one kept it in a recorded form - it simply would not have enough space. Sometimes there were exceptions, but they only illustrate the inexpediency for that era to store the sounds of the game in the form of audio recordings. Sonic the Hedgehog, the very first game in the series about a running blue hedgehog from 1991, occupied this sound with a duration of one to two seconds, the eighth part of the 512 kilobyte cartridge. It was needed to ensure that the name of the publisher was played at launch.

An example of this kind of music generation could be the MIDI format, although the games of that time worked at a much lower level. Instead of notes, the order of patterns was used, which needed much less memory. Here is an example of what can be achieved with a single-bit sound.



The Legend of Zelda , the very first of the legendary series about an elf-like boy in a green cap, for 1986 was a huge game that even had to fit on an expensive cartridge in as much as 128 kilobytes. Today, this figure sounds ridiculous, but the game is really rather big: it consisted of one big nadmir and two dungeons, each of which was twice as large as nadmir. Images are clickable.



The first trick is immediately visible: a maximum would be squeezed out of a standard grid. Dungeons consist of 16 × 16 = 256 screens, the overworld of 16 × 8 = 128. Therefore, the data on which screen the Link is in fit into one byte: 4 bits for each of the coordinates, while for the world above, one of the bits does not was used. Interestingly, the second dungeon has a blue L-shaped area that does not fit in the space allotted to it, so its additional two screens are located to the left.

If you look closely, then each of the screens is a matrix. Screens nadmir and dungeons were processed differently. The nadmir screen is a grid of 16 × 11 tiles, each of which can be ground, sand, stone, bush, water, waterfall, gravestone, ladder, bridge / pier, hatch or hole in the wall, plus several options for special decorations - trees and entrances to dungeons that were processed in a special way.

In addition to the ground, more than 3 tiles were not used, so two bytes, divided into 4-bit nibbles, are enough to store information about what types of tiles should be on the screen. Each of the tiles requires only 2 data bits. As a result, each screen requires 44 bytes of data (and two bytes to store information about the tiles used). Total supram fit in a little less than 6 kilobytes.

Most of the screens above the world use either white, brown or green, and some use brown on green, green on brown, or white on brown. Two colors can be used as the color of the outer frame and the color of the inner elements. Only 6 options that fit in three bits or nibble (half a byte).

Each of the dungeon rooms is a 12 × 7 grid of the actual contents. But this space was cut in a peculiar way: almost all rooms, except for special ones (entrances, end rooms, and others) have no more than one type of barrier. This means that to store all the information you need only a bit per tile, a byte per column, and 12 bytes per room.

We have 12 extra bits left. It is necessary to store information about each of the walls (nothing, 3 types of doors, a point for a bomb, a blasted passage). 6 options × 4 walls = 24, that is, everything fits in 5 bits. In addition, you need to store information about the type of barrier: stone, statue, water / lava, sand or void, which takes 3 bits. The last 4 bits define the color scheme of the room. Each of the color schemes is determined by the byte (2 options for 16 colors).

So, the storage of the entire game world due to the many tricks go some kilobytes.

Conservation is also an example of various tricks. 4 bits are used to store information about bombs, the second half of a byte is used to store information on the number of keys (up to 7). Arrows and money use the same value in byte length, so each shot of 255 possible costs in rupee. To store information about the number of pieces of Trifors, a whole byte is allocated, since you need to take into account the order of their collection.

In total there are 8 used treasures, but one of them has three levels, and the other two - two levels. There are 6 "passive" treasures, which, for example, allow you to move through the water or move heavy stones, and one of them also has two levels. Finally, Link can have either a bronze, white, or magic sword, or he may be unarmed. In total, it is possible to have 22 different items in the inventory, which will require 3 bytes to store, but only 2 bits will remain.

You can have up to 16 containers of hearts (4 bits) with different levels of occupancy (4 bits). Half of the hearts are considered one of the remaining bits from the inventory. Finally, the first quest can be either passed or not, which requires another bit.

Six bits can be set 26 letters, 10 digits and a few special characters. The name of the save allocated as much as 8 characters, which are stored in 6 bytes. The Japanese version had to use the entire ASCII range, so there the maximum length is 6 characters. A byte goes to the coordinate of the screen in the overworld or dungeon, one byte to the other various data.

Thus, the preservation of the game fits in 16 bytes , while it is not just saving, it is signed with text. For comparison: this space is enough for 8 Cyrillic characters in UTF-8. And today, game developers are doing a lot to fit their storage in file system clusters, but 16 bytes is just an error for modern software and data transfer.

When developing Crash Bandicoot for the PlayStation 1, there were also its own features. RAM was the main problem, and then - just the console had 2 megabytes of memory, so I had to take insane steps. There were levels with more than 10 megabytes of data that had to be loaded dynamically, avoiding subsidence of the frame rate below 30 Hz.

To do this, it was written by the excellent paging system, which loads pieces of 64 kilobytes as the player moves along the map. Everything was written in such a way that even at the speed of a console disk drive of 300 kilobytes per second everything was loaded by the time the game character appeared in a given area of ​​the map.

To store game resources (sounds, textures, models, code) in these pieces of 64 kilobytes the packing utility was written. Some levels hardly fit, so the utility used a variety of algorithms - first-fit, best-fit and others. After reviewing several attempts, the best option was chosen. The task was complicated by the fact that with the change in the level of design, the possibilities of packing data changed, which was due to the complexity of the mathematical component of the process - this is difficult to explain to artists who suddenly wanted to remake something. Optimization of the code in C and assembler remained the biggest problem, but in the end everything fit under the outset - only 4 bytes of free space left from two megabytes of RAM.

In the 1984 car simulator, Revs had its little trick. The graphics of the game looked like the one below. A large part of the screen was assigned to evenly blue sky



This was used by the creator of the game, the British Jeff Crammond . He used this area of ​​video memory data to store a fairly large piece of code, for which there was very little room in the BBC Micro . This area was painted in blue, so the player did not know about it, unless the game ended with an error - then the screen was filled with some kind of garbage.

Many of these tricks are used to this day, although the power of consumer computers and game consoles has increased by many orders of magnitude.

Based on materials on Quora .