Super Tilt Bro. for NES

[RogerBidon | 151]

Did you notice that all Nintendo systems coming after the N64 have their own version of Super Smash Bros? It is a shame that this (wonderful) experience is not ported to earlier systems!

Super Tilt Bro. for NES is my humble attempt at filling this void. It adapts this fun and nervous gameplay to the NES and its eight buttons controller.

You can freely download the ROM, play in a browser or hack the source.

 

It now has an ONLINE mode! Short story: Wi-Fi chipset in the cart. Long story: here.

To find an online opponent, join the discord.

 

Pre-order at Broke Studio's shop!

 

Here is the (old and dated) trailer:

In this topic there will be different kinds of updates:

• Technical highlights: small articles about technical challenges of developing Super Tilt Bro. and how they are solved.
• Patch notes: when the game receives an update, details are available right here.
• News: Less often, I may announce something big (like a new physical edition)

Edited June 5, 2024 by RogerBidon
Pre-orders

[neodolphino | 273]

Glad to see you here!

It will be much easier to follow your progress on here, than on Twitter!
I also look forward to adding the new physical edition to my collection when it comes around.

[SoleGoose | 95]

Glad you made it over to VGS, excited to see the updates!

[TylerBarnes | 184]

Such a great concept and execution. I will certainly hold out for a physical of this.

[RogerBidon | 151]

Wow thanks for the kind words!

I get some sleep, then I will (re)post the last three technical highlights. That's the ones that begin the journey of developping Super Tilt Bro. version 2 

[TylerBarnes | 184]

I noticed the rom on your site is 40KB. Does that mean this was all done with NROM? And is V2 going to go any larger? UNROM512 perhaps? 

Edited November 1, 2019 by TylerBarnes

[RogerBidon | 151]

You got it. V1 runs on NROM boards, because it was my first homebrew and there was enough to learn without worrying about bank-switching.

V2 runs on UNROM512, but the mapper may change one day. Don't ask why, I cannot say that it is because I want to port to a still non-existing internet-enabled mapper. It would sound crazy.

[RogerBidon | 151]

Originally posted on May 8, 2019

Technical highlight: Beginning the work on v2, rethinking positions

All Super Tilt Bro. cartridges are now shipped. It is time to begin to work on the second version. It all begins with in-depth refactoring. Let's fix version 1's shortcomings before making a better game. We will begin by changing the way we handle positions.

The NES generates 256x240 pictures. Nice! We can describe any on-screen position with two bytes: one 8-bits unsigned integer for the horizontal component and another for the vertical component. In Super Tilt Bro. v1, if you go out of screen, you die. Technically, you will always be on screen, so this simple "one byte per component" system is enough.

Some objects, like characters, need more flexibility. In this case, we can add a second byte, the sub-pixel position. It becomes a fixed point number, allowing to have finer-grained positions for this object. It is especially useful when it comes to movement speed, we can easily move such an object by 1.5 pixels per frame.

This system works well, but has two shortcomings.

The first is technical, and we can live with it: signed and unsigned integers don't mix well. Indeed, when we have two on-screen points, subtracting one by another and you get a vector... At least that's what my math teachers told me. Actually, with this system, we subtract two unsigned integers. It is flawless while the result is positive. When the result is negative, since we work with unsigned numbers, we overflow. There is always a path to work with it, but sometimes it is a pain.

The second problem has no workaround, Super Tilt Bro. v1 was released with it: allowing the character to go slightly off-screen before dying makes the game more pleasant. With this positioning system everywhere in the game (characters, hitboxes, platforms, particles,...), we cannot simply implement the concept of "out of screen" without reworking a good part of the engine. Super Tilt Bro. v1 just does not understand the idea of "out of screen". By the way, in its logic, we do not die "when we go out of screen" (it is meaningless), but "when we are moving to the left and finish on the right of the screen".

To solve these shortcomings, the positioning system is rethought. Instead of storing a component in an unsigned byte, a two-bytes signed integer is used. The most significant byte is the screen byte, the least significant one is the pixel byte. Of course, objects needing a fine-grained position can add a sub-pixel byte.

This new system avoids mixing signed and unsigned integers and opens the way to let characters go off-screen. That's nice. Moreover, we have lots of space. One byte for the screen, there is 256 possible screens. If, one day, we want to add an adventure mode based on scrolling, it would be feasible.

This change comes at a cost. Storing positions requires more RAM while computing it puts more load on the CPU. Happily for CPU budget, there was a big optimization done while refactoring animations. It is much more impacting than some 16 bits additions.

Most of it was done during a mini marathon. You will find the resulting ROM here: http://supertiltbro.wontfix.it/files/preview/Super_Tilt_Bro_marathon(E).nes

Do not hesitate to give me feedback about how it impacts the game's feel, or some bug reports.

While I was doing this marathon, I posted my daily progress on Twitter: https://twitter.com/RogerBidon/status/1122047017444880384 Tell me if this kind of report is interesting for you. I will surely do it again, I loved it.

Edited November 1, 2019 by RogerBidon

[RogerBidon | 151]

Originally posted on June 17, 2019

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.

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.

[RogerBidon | 151]

Originally posted on October 9, 2019

Technical highligh: 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.

Structure of a Super Tilt Bro. mod

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.

To compile a mod means converting it to assembly files that can be integrated to the project

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!

What a big build chain!

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

Addendum

Uppon request for seeing what it looks like to mod Super Tilt Bro. here is a practical example: adding a mustache to a character.

English subs available.

 

[dale_coop | 171]

RogerBidon, SuperTiltBro is awesome ! Always fun palying with a friend (...or a son, in my particular case).

[RogerBidon | 151]

I need some more years before playing it with my son... For now, I can just hope he will not beat me at my own game 

[RogerBidon | 151]

Hey! Long time without an update, I was busy on details that are not worth devlog entries like fixing bugs, polishing menus, improving AI,... All this to come to a releasable state.

Here comes the first ALPHA of Super Tilt Bro. version 2! As always, free to grab here.

That's an ALPHA, which means that there are tons of stuff to be added later. Most notably network support, but also more characters, more stages, better music and whatever seems cool, time will tell.

• New character:
  •  Her name is Kiki, she is the mascot of the Krita project
  •  With her big brush, she is able to draw platforms to recover or block her opponent
  •  She has a long range that largely compensate for being slower than Sinbad
• Gameplay:
  • Made it easier to input recovery moves
  • Characters can go out of screen before losing a stock
  • You can fall through slim platforms by briefly tapping down
• New graphics:
  • The hunt now takes place in deep caves
  • The pit is now in stiffing jungle
  • Skyride and Flatland make you fight in antique ruins
• Improved menus:
  • Title screen is now animated
  • Transition between menus is more nervous
• Improved AI:
  • The bot no more misses its strikes when you are not moving
  • The bot is no more stuck when on a platform above you
  • There is actually one AI specific to each character
  • Hard mode CPU is more challenging (especially Kiki's bot)

Hope you enjoy playing it as much as I love coding it! 

Edited March 5, 2020 by RogerBidon

[DefaultGen | 5,970]

Omg, it fixed everything I ever complained about and this game is already dope as hell.

[RogerBidon | 151]

Hehe, yes the idea to down-tap to fallthrough platforms was yours! Thanks for that 

I hope that the CPU upgrade is enough, that's more tweaking numbers (and using down-tap) than really making it smarter.

[Scrobins | 1,881]

If you do a physical run of version 2, count me in!!

[RogerBidon | 151]

Haha that's not soon, but I'll remember 

[erockbrox | 33]

I played a version I downloaded a while back. One thing that I wanted to see is a mechanic where if you go off to the right of the screen that your character then appears on the left off the screen (wrap around) like in the Mario Bros arcade game where you kick the crabs and flies that come out of the pipes.

This seems like a really fun two player experience. If you added an option for 4 player support I'm sure that you would get the type of response that Micro Mages got.

Edited March 6, 2020 by erockbrox

[RogerBidon | 151]

Wrapping from one side to the other is definitely feasible as a stage-specific rule, but I don't like it. It violates a major rule of the game (the fact that you die when going out of screen), and I do not find it particularily fun. Actually some stages behave like that in Super Smash Bros. and I never saw anybody use it smartly, most of the time players just don't go to screen's limits voluntarily.

Anyway, The Pit is an excellent candidate to test this rule. I guess, if there is more demand I may implement it there.

About four players support, I will not do it. It would require to impose harsh limitations on VRAM usage per character, while characters all have tens of animations (22 for Sinbad.) I prefere focusing the design on the two-players experience than fighting against a too restrictive tiles budget. More than two players can still play the game, just print brackets and bring a beer for the winner Ingame tournament support would be cool though, and it is definitely in my todo-list.

[RogerBidon | 151]

Hey, some news from the project: there is a prototype for online versus.

I am interested in it since @Broke Studio revealed his plans to develop a mapper with an integrated WiFi chipset. Actually, I worked with him to help with emulator support of his mapper while he was developing the hardware. The current state of this project is that there is some prototype cartridges (not yet generally available) and a patched version of FCEUX that support it.
Writing netcode is not an easy task. Especially for real time, fast paced games that run on a hardware with 2KB RAM (I will certainly write an article on that). So before making it in the public alpha, I made an online prototype. It comes with the emulator, the roms, and two public servers: one in North America, the other in Europe. All this bundled in a convenient zip archive, so you just have to unzip it and run the launcher "noth-america" or "europe" depending on where you are.

Here is the link: http://supertiltbro.wontfix.it/online.html

Note that the servers may not see a lot of players, you should definitely bring a friend to play with you. Also, I am eager for feedback (that's the goal of a prototype), do not hesitate to comment on your experience, being good or terrible. Thanks for your time!

[Deadeye | 1,604]

Very exciting.  Hope you get a lot of users to test it out!

[Scrobins | 1,881]

Maybe a scheduled VGS tournament...?

[RogerBidon | 151]

That would be awesome!

And a nice stress test if conducted on the prototype, but it would need to be nicely synchronized (the current matchmaking don't even let you know who is your opponent), maybe on discord?

[Scrobins | 1,881]

You could create a signup thread and people could state their timezones and preferred range of time to play and you could schedule accordingly, e-mailing whoever is scheduled to bout a specific time to logon to fight each other.

[RogerBidon | 151]

I'd prefere not to organize it myself. I do not feel legitimate enough to push my own game so hard, especially as it is still a prototype and I cannot guarantee that it will be a good experience.If it came to life, I could of course help in any imaginable way.