The Super Tilt Bro.'s engine is now capable of handling multiple characters. That took a good chunk on work, but there is nothing to show. No ROM with hundreds of characters and so many hours of gameplay. For now, it is “simply” a new feature of the engine. That's what I will talk about: technical problems and their solution in Super Tilt Bro.

Ok, there is a new “playable” character: Squareman, the character incapable of doing anything.

Why do we want multiple characters?

Short answer: because that's awesome!

Actually, allowing the player to choose between a bunch of characters was an idea floating around since the beginning of Super Tilt Bro. But it was not realistic. More than just the limited workforce on the project, the limited ROM's size makes it particularly hard. Sinbad takes 6 Kilobytes, with the game itself, Super Tilt Bro. v1 has not enough free space for a second 6 KB character. Another issue is the video memory. Video memory is a ROM containing 256 tiles, Sinbad's graphics use 94 tiles. We could not even put tiles for three characters without some in-depth optimization.

Anyway, times are changing! Super Tilt bro. v2 is stored on a bigger cartridge. 512 Kilobytes instead of 32, that's an incredible upgrade. Video memory cannot be magically increased like that. What we can do is to replace the video ROM by some RAM chip. As the RAM can be rewritten at any time, we can store on it only graphics of characters actually in use. Finally, Super Tilt Bro. v1 was a nice project to see what can be done with an NES, v2 aims to push it to the limit.

Oh, and ... Having many characters is awesome!

So, how do we make a game with many characters?

First problem first, storing the characters. The CPU in the NES sees a ROM of 32 Kilobytes. To access more space, we will have to cheat. The trick is to put a larger ROM in the cartridge which cannot be entirely seen by the CPU. Just make it such that we can change the window seen by the CPU at any time. Bingo! We can access more than 32 Kilobytes, just not everything at the same time.

That's the basic idea of bank-switching. The space in the cartridge is split in 16 Kilobytes chunks (the banks). So, there can be two banks in the 32 Kilobytes seen by the CPU. One bank is always visible by the CPU, we call it the fixed bank. The other bank visible by the CPU can be switched at any time.

Super Tilt Bro. v2's cartridge is gigantic!

Super Tilt Bro. uses a simple strategy to store characters in separate banks. All data defining a character must be in the same bank. In the fixed bank, there is a table telling the storage bank of each character. When the engine needs one character's data, it just selects the appropriate bank with the help of this table.

The index in the fixed bank allows to find any character's storage bank

The video memory problem is handled with another solution. There is not enough space for all sprites, but bank switching would be inefficient. Every on-screen character must be visible at the same time in the video memory, the graphic chipset needs it to display it. A banking system is just not fine-grained enough to choose two random characters. The solution is to use video RAM. When the game is starting, it can write tiles from chosen characters in video RAM, and voilà!

That's only the beginning!

OK, we have an engine capable of handling many characters. Do you think that the next logical step is to create a lot of stylish characters? No! For now, creating a character means writing a lot of assembly (to implement its move-set) and binary (for its graphics and animations). That's slow, hard and distract from designing the character. This process has to be easier.

The next step will be to create tools. First, a file format capable of storing everything about a character. This files will be compiled in assembly when building the project. Next, it would be nice to have an editor in which we simply draw character's animations, the tool taking care of everything else to produce a playable ROM.

Once tools are good enough, creating a new character would be realistic. It will be simpler than implementing it in assembly/binary and will be the occasion to play with our new tools.

Next post >>