Great news that you'll be adding characters!  Re: the name, how about Super Smash Crew?  If that's too close to the original name, how about Super Slam Crew?  Just a thought!   

 

Or Super Slap Band, to be an SSB game =)

By the way, the "Tilt" also has a story. Super Tilt Bro. has no "Smash attack" like in Super Smash Bros., instead the game is focused on "Tilt attacks" (in ssb, when you push gently the stick while attacking)

Ah, tilt attacks vs smash attacks, got it.  Well, Super Tilt Crew it should be, then!  Can't wait for the new juiced-up game!

 

Technical highlight: Adding new characters to Super Tilt Bro.

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.
 

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. 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 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.

Hi!

The next technical highlight is coming soon. I wanted to say “hello” and drop some non-technical lines about the project.

First, I wanted to state that this project is far from dead. Technical highlights fell behind actual development because ... life. Actually, a new life. I am the proud father of a little boy now! That said, you'll understand that my precious free time is more focused on the code than writing walls of text.

There are two big things that happened in the code recently:

The second character is in development. She is named Kiki, is the mascot of Krita and draws walls at will:



There is also some new graphics. Made by nobody else than Martin Le Borgne, the artist behind Twin Dragons.







Hoping to find time to lurk more often on this forum, I am glad to be able to show some concrete progress =)

Loving the animations! And congrats on the life news!

(Thanks SoleGoose!)

Technical highlight: Making a moddable game

The last entry in this devlog concluded that, before implementing new characters, we needed a storage format for them. Indeed, making a new character for a game imply designing it, drawing it and possibly implementing some specific behavior. With all that work to do, we really don't want to care about engine's internals like banks layout.

To achieve that, we will make the game moddable.

First we have to forget about the code. Just think about everything that makes a character distinct from others: its animations, hitboxes, special moves,... An easy to edit file format made to contain all that is the base of the mod. When building the game, a script can read this info and integrate it to game's code.
In Super Tilt Bro.'s case the storage format is based on two foundations: JSON and GIF. JSON is handy when it comes to describe hierarchical information, like “it is a mod, containing a character, having an attack animation, with a powerful hitbox”. About GIF, it is an image format, handy to... store images, you know   OK, there is one property of GIF that is too often overlooked, but make it the ideal format: it stores colors in a palette. As NES graphics are also based on palettes, it is really smooth to work with GIF as graphics source.
The storage format for mods being defined is a good step forward, there is no more need to fight engine's internals to get a new character in the game. Sadly, writing JSON manually is particularly painful. Better writing tools to take care of that.

Let's get some tools!

The perfect tool would be a graphical editor, running in the browser, easy to use, covering all engine's features, with... OK, stop dreaming. Maybe one day somebody will have enough time to implement such an awesome software. In the meantime reusing existing software will do the trick.

I work a lot with The Gimp, from there comes the idea of reusing its interface. Conforming to a precise hierarchy of layers (animations in a “anims” layers group, hitboxes defined by layers named “hitbox”,...) allows to script the conversion of the file to JSON+GIF mod's format. This way, characters can be drawn directly in the graphics editor, which is definitively more comfortable than editing a bunch of data files.

A word about Open Raster. The Gimp saves XCF files, Krita produces KRA files, Photoshop PSD. Those formats are designed to cover all features of their respective editor, even when it makes them hard to use by other software. When someone wants to share layered graphics, nowadays PSD is commonly used because it is almost universally (partially) supported. It leads too often to the “your file does not work in my editor” kind of issues. Open Raster appeared while there was an argument between Krita's and The Gimp's communities about who should support the format of the other. As such, it is really designed as an exchange format, it is simple and supports only the common feature: layered graphics. It is really simple. Writing a parser that meets the needs of Super Tilt Bro. was trivial. So, technically, build scripts support the Open Raster format, not The Gimp. Character creators can use their favorite editor.
tl;dr Open Raster rocks!
As you can see, the problem has been treated step-by-step, resulting in a multi-steps solution. Formerly we had some assembly source and made a ROM from it. Now, that's more something like that: work is done in The Gimp, image saved to Open Raster, converted to JSON+GIF, becomes assembly code then finally a ROM. That is simpler to use, the creator draws the character and some scripts take care of the details. To avoid obscure errors from the complex build system, each step zealously checks for inconsistencies. So errors can be detected early in the chain and reported with high level messages. Nobody wants to see an assembly related message because of a misnamed layer, or worse a valid ROM that crashes from time to time with no clear reason.

Cool, now what's next?

Super Tilt Bro. is moddable! Victory! If building projects  is your jam, you can begin by adding a mustache to characters, modify characters to fit your playstyle or even create a new one from scratch. All that by modifying the official mod.

For now, only characters can be modded. Stages will come next  

I think it would be great if you had a level where if the player goes all the way to the RIGHT then they emerge on the LEFT of the screen. This way you can transfer from side to side like Mario Bros Arcade.

It is totally doable. Super Smash Bros has such a level where you die only if you are thrown out of screen by the opponent, but transfer to the other side if you are just walking. I hate playing on this stage, but to each is own.

As I implement new stages, I'll be sure to make one based on this idea. Thanks for sharing it.

About the character limitation, what abput sharing tiles with other characters?
Like SMB did with the clouds and grass, but instead you share-repeat less elements, like just the pants or upper body.
Like what KOFXIII did with some characters that were mostly headswaps.

Im not an expert or anything like that, just throwing that possible solution to add more characters, Micro Mages did something like that to save space.

There are two issues with tiles sharing between characters:

First and foremost: I am not as talented nor dedicated as Nicolas Bétoux (artist on Micro Mages). As a programmer, I already struggle to put out half-decent graphics without adding hard tiles limitations.

Second to that is the game genre itself. In a brawler it is expected for characters to be vastly different gameplay wise. This gameplay differences have to be reflected in graphics for added immersion: a though guy will be large and strong, a rapid one will be little and nervous. All this means that a maximum of freedom should be kept for characters' drawers.

Note that instead of tiles sharing between characters, we could further optimize each character. That is a thing that positively surprised players: a character has a lot of moves. Actually characters have more than 20 animations. There is actually some tiles sharing going here, but I am sure it could be improved. Anyway, it is less problematic than before as the game switched to UNROM512, using VRAM... while we do not talk about 4-players mode we are good =)

Well, then the idea could work if you have 2 tiny chars or 2 string ones, etc, but maybe you dont need to share between characters but in the character itself, like old KOF games did and SMB1 iirc.

Like some item throw sprites animations could work for a punch or something different.

Keep the good work, will like to see how this project ends.

Thanks for the nice words <3

And yeah tile sharing is the way. For now tiles are only shared between animations of the same character, notably the weapon, thanks to a metasprite format that allows independent placement of individual sprites. Tile sharing in a single metasprite would be the way to go for bigger characters.