Super Tilt Bro. 2.0-alpha4

What's new in the game?

Sinbad's gameplay reworked

Sinbad is now way more interesting to play. Focus points are to improve his recovery, fix weird behaviors, and reward skilled player.

First notable change, Sinbad now has a wall jump. It comes in addition to his double jump, and can be done while in helpless fall. The wall jump is a lot more than a simple bonus jump, doing it in helpless means you can chain a second up-special or forward-special after cancelling your helpless fall. Sinbad's recovery is greatly improved, and allow off-stage mind-game as this opens a lot of recovery options. Edge guarding is also safer now.

And he keeps his double jump!

Another big change is the grounded special. It was a first draft of the move that never got the love it deserves. In its old state it had a frame-1 hitbox, and weird momentum behavior, making it overpowered in some ways while unexpectedly weak in others. Now it has a big startup time, and cancels momentum. It is a finish move, requiring anticipation to place correctly but very rewarding.

So powerful!

Airborn special is now cancellable into helpless by pressing B again. Allowing for slightly speedier fall speed, and wall jump. The spike of side special is now stronger. Finally, Sinbad bot has been updated to use wall jumps for recovery.

Kiki's counter slide

Kiki's special is a counter strike. While in counter's animation Kiki retained her momentum in a strange way: only horizontal momentum while on ground. She could slide long distances when countering at the end of a jump. It is changed by having reduced ground friction, so she can still slide, in a more natural way.

This is post-patch, before she would have slide beyond platform's limit.

Better netplay

Connection quality of both players is displayed briefly before starting an online game.

The game has been optimized to be able to rollback more frames, improving netplay on unstable connections. More details on the technical parts of this release note.

What's new under the hood?

Fixed server

Rollback netcode is something notoriously hard. The smaller the game system, the harder it is to rollback frames. Some says that it is impossible to do it on the Switch, because its lack of computing power. Don't listen to them, nothing is impossible, but that's hard. The NES, with its 2 KB of RAM, and its 1.5 Mhz CPU is far beyond minimal specs. The server helps notably with memory management, sending checkpoints so the NES does not have to keep them in memory. The NES receives opponent's inputs with an associated checkpoint to rollback from if necessary.

This solution requires the server to be able to compute the game's state to create those checkpoints. It was originally done by reimplementing the game's logic in C++ (the language of the server), since the game itself is made of 6502 assembly which is not compilable for modern CPUs. Maintaining two completely different implementations of the same logic was terribly time-consuming, and led to inconsistencies between the game and the server.

Now the server embeds a very lite emulator, able to emulate game's logic from the ROM. This solution is slower than the C++ implementation but is guaranteed to be consistent with game's code, it is game's code. The biggest part has been to make it reasonably speedy, the original emulator came without specific optimization. Detailing how to optimize a 6502 emulator would require a full article, here are some hint: avoid a maximum function pointers, avoid branching, and recompile what you can. Easier said than done, if you want a more detailed history of my progress, here is a real-time twitter thread of the optimizations done: https://twitter.com/RogerBidon/status/1319175188450344962

Optimized client

The NES has checkpoints on hand when needed, but it still needs to rollback frames. That means, playing multiple frames worth of gameplay on the time allocated to only one frame. Playing a frame worth of gameplay has to be lightning fast. In this version the code has been optimized exactly for that reason.

The first step was to create tools. Believe it or not, 1980's systems have terrible profiling tools compared to modern systems. Thankfully, emulators are extremely versatile nowadays. With some scripting we can output the game's code annotated with the time consumed by each line, or even flamegraphs.

Each rectangle is a function. The larger the rectangle, the most time spent in the function.

With that tooling, and good knowledge of the code, it is easy to spot bottlenecks. Some were simply old code that became critical, other required little refactoring. Everything considered, the hardest part was to make tools. With good tools, optimization is straightforward.