🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Smash Bros Ultimate's netcode doesn't use Rollback because it would cause "too many side-effects"

Started by
4 comments, last by ddlox 3 years, 6 months ago

I read an article recently that talked about how players of Smash Bros. Ultimate are complaining about the netplay experience. It's too laggy. I've also read that Ultimate has 5 frames of delay, even in local play, so that when you're online and there's some lag… say 3 frames of it, the game will reduce this delay to 2, so that it evens out, and the local play and netplay will feel pretty much the same. This seems like a cheat; cheating the local players out of a smoother experience. It also begs the question: Why didn't they go with rollback?

Smash Bros. designer Sakurai said that they had considered Rollback, but that they decided against it because it would have “too many side-effects”. There's a version of Dolphin called Slippi, that fans have modified to use Rollback for Smash Bros. Melee specifically, and it works like a dream. Granted, Slippi is only used for 1-1 games without any items, stage hazards, etc.. but surely with enough time and effor that could have been made to work too? What I'm wondering is: What kind of “side-effects” is he talking about?

Advertisement

Rollback can be difficult, and can be expensive in terms of compute time and memory, as well as development time. It is usually reserved for dedicated servers, as the burst of processing can be too intense for machines running a game client.

It can be extra difficult depending on authority models used in games. When games use a star model where one player is the authority it isn't too difficult, but using a consensus model rollback would be quite difficult; not only would you need consensus on game state, you'd need consensus about rollback which would take even more time.

As for “surely with enough time and effort that could have been made to work too”, I'm not so sure. The game appears quite demanding for the hardware. Even without network lag occasionally the game will stutter a bit. I doubt Nintendo were willing to front the cost of dedicated servers for all the machines PLUS forgo direct connections, which is one engineering solution. Or that they were willing to sacrifice the player experience, which is the other major engineering solution.

I would be less worried about the computational cost of rollback and more about the jarring effect it has on gameplay. The computational cost of a fighting game can be made completely trivial. Street Fighter 2 ran on the SNES, after all. But rollback means that you can press a button to perform an action, see the animation of performing that action, and then retroactively never have performed that action at all because you retroactively were in a different state when you pressed that button.

If a system with rollback works “like a dream”, there's a good chance that you're either not paying close enough attention or that your latency is so short that the system ends up not having to roll back all that much.

The problem with rollback in a game like Smash is that some wind-ups are very short, and thus a player would never be able to see the hit coming – they'd just suddenly be rolled back to post-hit state, without any way of reacting ahead of time.

Some games are just really hard to make work multi-player across a latent network. You have to game-design your way out of that, you can't wishful-think your way to a good solution there.

enum Bool { True, False, FileNotFound };

totesmagotes said:
Smash Bros. designer Sakurai said that they had considered Rollback, but that they decided against it because it would have “too many side-effects”.

Usually this means, they spiked rollback in standalone sandbox, which further means that they were actually testing rollback with their game and thus observed that rollback was the reason for several of their gameplay issues;

to us the nature of these issues is unknown but not to them, they would have assessed each issue and concluded after the attempt of solving all these issues that rollback was not ideal for their game;

By speculation:

  • performance could have been their issue
  • gameplay affects could have been affected
  • an inconsistent amount of re-sims
  • lag
  • framerate drops
  • and the list goes on…

when the list goes on like this, game and dev ain't no fun no more -lol-

have fun ?

EDIT: not related to Sakurai, but this might be of interest to u: https://gamedev.net/forums/topic/708348-rollback-prediction-management/

This topic is closed to new replies.

Advertisement