Alright. Can actually talk for an extended period again instead of making one-offs, so let's talk a little more about GGPO and rollback netcode implementing.

There's a tendency to either frame GGPO as some sort of drop-in magic that will make your game better immediately, which is false, or as basically useless because the majority of the work is still on the developers; which is also false, I feel.

GGPO _does_ satisfactorily handle the network side. But, to fully implement a rollback-style network model, you must also

- Have a fully deterministic game
- Your game update loop must be safely re-entrant
- Visual and audio errors must be accounted for

None of this is trivial.

Let's go down that list.

A fully deterministic game means that, for the same inputs, your game will always have the same output. This is only really viable for games that do not transmit state directly, just what will cause state changes: Inputs.

This means all 'data' about the current game's position must be accounted for, AND the logic must be consistent; if you intend on having cross-play with other platforms (eg Win/Mac, or Win/PS4), compilers can generate slightly different code (hi floating point!) which is trouble.

Every input delay game must be deterministic; so pretty much all fighting games have this covered. This, however, would be particularly difficult for a lot of games that have either a lot of state or rely heavily on floating point values.

This determinstic state needs to be able to be stored and restored, like a saved game, every single frame. You can't miss a single value. You can't cost too much performance.

If you don't build with that in mind you will have a serious goose chase on your hands!

Game must be re-entrant:

This means that your game has to be structured so that you can run an update, _without_ affecting external things like video and sound.

Separating game logic and game visuals it not always viable, especially in modern 3D engines.

Again, if you haven't built for it from the beginning, separating these two can be difficult at best. It is not terribly hard in 2d games to just.. not draw things, but 3d games often make heavy use of stateful information and it would need to be be fully separated.

So at this point your game is rolling back properly and it is playable, woo!

Except now you've got visual and audio errors, everywhere.

A sound was rolled back over and should never have been played, but it's still playing. What do?

Unlike a traditional game, you now have to keep full track of not just every sound you play, but the status of every sound that has been played, and whether or not it has been 'canceled out' by things that occured in the rollback.

That's not easy to do!

There's a lot of ways to approach audio falling out of sync with the expected result, but ultimately all of them are going to involve drastically more work than just playing sounds.

Many visual effects are the same way! Like particles.

So while GGPO does handle the network side of things correctly, there's a _huge huge huge_ burden on the developer to do a lot of these things, and to do a lot of them right from day one, because retrofitting these things is often a lot of work!

I know that, as players, we know what we want, and as devs, we struggle with both what we want to give and what we are capable of doing, so I really genuinely ask that people be patient with everyone involved.

The only way to do a lot of this is hard work and a lot of time.

that's all I have to say on it for now. I wrote an article some years back that I'm told is of a lot of help for people understanding rollback networking itself, the magic of GGPO itself, and I hope that helps some people:

http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking.html

p.s. don't believe stadia's lies