Hacker News Reader

Comment by alvarosevilla95 | Hacker News Reader

Slightly related, a couple of weeks ago a guy named Fizzi released a dolphin build with rollback netcode support for Super Smash Bros Melee, making it a game with better netcode than most current big name fighters.

The way he implemented it is insane, he had to reverse engineer a way to generate arbitrary game states in game, as using dolphin savestates was not performant enough.

He's also added other amazing features, like in game matchmaking, or my favorite, being able to stream a game state through the Wiis ethernet port, so two players can be competing on original hardware while a stream setup upscales that footage in realtime to 16:9 4k through Dolphin, and also generates real time match stats, saves replays... Incredible stuff.

Here's the project page: https://slippi.gg/ and a video from a top melee player showcasing the matchmaking: https://www.youtube.com/watch?v=erbZV8u6-hA

View on HN

I always love when technical accomplishments like this show how insanely effective lone people can be when they throw themselves at a task with a heart full of love for the subject.

Commercial environments would have called these ideas unfeasible before the first line of code was written.

I know a guy who added basically full collaborative support to IDA Pro, doing something similar (IIRC, hooking all state transitions). Some people are just way out there.

Is this the same definition for "rollback" netcode? https://en.wikipedia.org/wiki/GGPO#Design

> GGPO uses a netcode technique called “rollback”. Rather than waiting for input to be received from other players before simulating the next frame, GGPO predicts the inputs they will send and simulates the next frame without delay using that assumption. When other players’ inputs arrive, if any input didn’t match the prediction, GGPO rolls back the state of the game to the last correct state, then replays all players’ revised inputs back until the current frame. The hope is that the predictions will be correct most of the time, allowing smooth play with minimal sudden changes to the game state.[6][7] The system in itself is highly similar to client-side prediction, but applied to a peer-to-peer setup.

Yes. This is a custom implementation, not CGPO itself, but the concept is the same.

Do you have a link to any blog posts, i would love to read about it. I tried to look on http://slippi.gg, but development appears to be closed source?

I'm just an outside observer, but i love the topic. For others like myself, this is a great GDC video to watch on the topic

> 8 Frames in 16ms: Rollback Networking in Mortal Kombat and Injustice 2

https://www.youtube.com/watch?v=7jb0FOcImdg

I submitted a blog post a few weeks ago about the way they handled game state synchronization in replays [0]. The netplay release is still relatively new, so if there is a blog post in the works, it'll probably be at a later date.

[0] https://news.ycombinator.com/item?id=23643784

It's not obvious on the website but everything is on Github[0] with different repos for the forked Dolphin build, the desktop app, melee assembly...

As to dev blogs, they have a medium[1] with some interesting posts, but nothing too recent, I hope they'll do one in time with all the new stuff.

On top of the rollback, something very notable they did was realising melee has 3 frames of input lag when running on native hardware, so they managed to remove them from Dolphin when running on 120hz screens. This allowed them to keep those frames as a delay buffer without actually having a real effect on gameplay.[2]

[0] Slippi Github: https://github.com/project-slippi/

[1] Dev Blog: https://medium.com/project-slippi

[2] Post about Faster Melee, the previous netcode iteration, going into the input delays: https://www.reddit.com/r/SSBM/comments/azoiqz/faster_melee_2...

> Fizzi released a dolphin build with rollback netcode ... making it a game with better netcode than most current big name fighters.

I see this repeated often without justification. Why is rollback better?

Based on my basic understanding, rollback netcode would absolutely fall apart under any suboptimal network conditions. If there's too much lag or packet loss, you and the opponent character will start teleporting all over the screen, missing lots of inputs, etc.

It makes sense that rollback netcode would be preferable when paired with a very good, reliable network (e.g. so if any rollback is needed, it's only a frame or two). But if you're selling a casual game meant for anyone to be able to play, a delay based netcode makes more sense to me. An average Joe can understand "the game is buffering", but if the game starts rolling back too much and you can't control your character because he's teleporting all around, that just looks like a broken game.

An interesting follow up question: if rollback is objectively the better approach, why is it implemented less often? Is it significantly more difficult to develop and does that offset how much value it would add to the game?

Rollback more or less massages the differences between players connections. Comparing this to old netplay (Anthers Ladder & co) is night and day differences.

Teleporting rarely happens for me, if ever - and if it does, then I can cancel and move on to the next opponent who generally doesn't exhibit the issue. In a game like Melee, this is huge - you really need to play both to understand how impactful the difference is.

Rollback is not a replacement for delay-based, but an enhancement to delay. Slippi, for example, still delays the inputs by 2 frames to minimize the inconsistencies that appear. This can (in theory, not sure if it’s implemented in slippi) be increased to any number of frames to reap the benefits that delay based netcode has. Only using delay is objectively inferior because any flaw that rollback has is also shared by delay. You are welcome to try out the old Melee netplay and compare it to the new Slippi to experience this for yourself.

The reason rollback is rarely implemented is because it is hard to motivate a company to do it when the benefits are so intangible. “Better netcode” doesn’t really sell games, flashy graphics does. And since most of the FGC has existed offline, online is just an afterthought.

This video explains fairly well: https://youtu.be/1JHetORRpfQ

That and most developers are in Japan, where rollback doesn't show any real benefit because the infrastructure there is small and fast enough to make even the worst netcode viable.

If there's "too much" lag or packet loss, delay-based netcode will also become unplayable; the difference is that rollback has more tools to address bad connections, so that rollback is often not even visible:

- predicting that the buttons held down in frame X will be the buttons held down in frame X+1 is actually a pretty good heuristic

- in fighting games, changing directions and attacking generally have windup animations, so if a correction skips a few of the initial animation frames, it still hasn't diverged the overall game state much

- even in bad connections, you still have control of your character; the game doesn't freeze and take you out of the flow (this can be subjective)

- hybrid approaches are possible, where a small fixed delay is used in addition to rollback; short enough to not be obvious to the player, but long enough to avoid rollback in the cases where delay would be sufficient. (delay-based netcode is not good intercontinentally anyways due to the necessary delay for synchronization becoming obvious input lag)

As for why rollback is rarer, yes, it is more difficult; it usually requires a fully deterministic game engine with the ability to snapshot and restore game state, which can be a very intensive retrofit if you didn't design it in from the start.

It's a balance between normal delay-input and rollback netcode, not one or the other. You can increase the delay which will reduce teleporting but obviously makes the game more delayed.

Rollback requires your game to be able to rollback to a previous game state. Some games are not developed with this in mind (too much reliance on global state, hard to go backwards in time)

I don't see why you would think that. On the contrary it is with solely delay-based netcode that the game would miss your inputs, because it will freeze under bad network conditions and anything you input while it is frozen will be missed. Rollback netcode allows the game to keep running and processing your inputs regardless of the network conditions. You might see the other character jump around somewhat but it's unlikely that your character will warp as the game knows all of your inputs. Your own character can basically continue to react perfectly to your input regardless of network conditions.

Notably, anybody who's interested in this kind of stuff/if you're looking to hack on a fun project - the issues page is great to scan. The Discord people are generally friendly.

I jumped in and have been poking at some stuff for the macOS build, tons of fun.

That's remarkable. What do these devs do for their day job?

The developer (to be pedantic, there's only one full-time developer, Fizzi, the others are volunteers) quit their day job last year to work on Slippi full-time [0], with funding from Patreon. More details are available on the project site about the other contributors [1].

[0] https://twitter.com/fizzi36/status/1199734629252653057

[1] https://slippi.gg/about

Fizzi actually left his job at smash.gg on November to focus solely on the rollback project. He has a Patreon [0], and the community has shown quite the support: he gained 1k patreons in the 24h following the release. Another main contributor, UnclePunch, who's written most of the ASM to directly interact with the game, also has some Patreon support. There's also other contributors working on their free time AFAIK.

[0]: I'm not affiliated with Fizzi but I'm not sure if sharing his patreon would be spam, so I'll say you can find it in the project website from my previous comment.

Super Smash Bros Melee was released in 2008, networking was way different back then + all the good libraries language you have now it's much easier.

Melee came out in 2001. Neither the game nor it's original console have any networking support.

If you're referring to my comparison, I'm talking about current gen titles. In fact, with this you can now play play cross-country with less input lag than Smash Ultimate offline

It did have networking support with an add-on network adapter that goes underneath the Gamecube, but that was used for a handful of games only.

Are you saying the gamecube didn't have networking support because it required an additional peripheral, or because you weren't aware of the whole 8[1] games that had either LAN or online capabilities?

[1] https://en.wikipedia.org/wiki/GameCube_online_functionality#...

In the context of SSBM, networking support for the GameCube (hardware) is irrelevant

You're thinking of Brawl, not Melee.

Reply on news.ycombinator.com