This is a good article to read first on my blog, because it will explain a lot about why I write my future articles a particular way.

A lot of times you might see explain something as the "Objectively Best" solution or implementation. And you might be tempted to fire back with "Art is subjective, there is no best implementation". And while that's technically true, it doesn't apply the way you might think it does.

While there really such a thing as "The Best Game Mechanic", there is better or worse mechanics in specific contexts. Another way you can think of it is that there's no best tool, but there's a best tool for the job.

This is why it's important to figure out what a developer was trying to do before you discern whether or not a mechanic is good or bad. Lots of times players will have something they don't like happen to them in a game and will have a kneejerk reaction saying it's a bad mechanic without taking the time to consider why the game works like that, what would happen if it were removed, or whether or not it serves the game well.

I've also found some people have a biased tendency to want the game benefit them in the moment but in a way that would be bad for the game long-term. Like for example someone might ask for a particular buff, or the removal of a mechanic they don't like, but if that actually happened, the meta would evolve into something they hate more. But that's mostly a topic for another day.

Let me go over an example. This assumes that you're already familiar with the various kinds of netcode which is maybe a stretch but whatever.

Netcode Example

I'm using this one as an example because it's very uncontroversial. I'm sure you've heard people say before "Rollback has no downsides", and they're basically right because of the context of the problem.

When creating netcode for a fighting game, we generally want to make the game feel like offline play. So it's helpful to break that down into smaller objectives:

• Minimize input latency.
• Make the game look as normal as possible.
• Maintain the gameplay mechanics perfectly.

These are our objectives, and we can use them to analyze different kinds of netcode.

Server Reconciliation

First is the netcode most games use, where the game just sends you updates to position and animation data on the fly, with the goal of eventually correcting things. When you land a hit, it's sent to the server, and eventually the other guy will figure out he's in hitstun.

The problem with this is that it violates objective 3, and does not maintain the gameplay mechanics perfectly. If you saved both players inputs and played them back the match would look completely different. It's too loosey goosey. It also somewhat violates objective 2, because it still suffers from the same kind of teleporting that rollback can have.

Delay-Based Netcode

Next is delay-based netcode. This is what fighting games used for a long time, and it's better than the previous alternative.

Because the game is being simulated normally and waiting for both players' inputs, it's guaranteed to both look normal, and maintain gameplay mechanics.

Where it fails is on objective 1. It does not minimize input latency AT ALL. Delay-based netcode is arguably the worst possible netcode for input latency because it requires both players to wait for their inputs to be transmitted before anything can happen.

It's for this reason that fighting games don't use this form of netcode anymore.

Rollback Netcode

This is where we get into rollback, which is the modern gold standard. It does satisfy all 3 objectives, but there is still a small catch. It can't satisfy objectives 1 and 2 at the same time. They're somewhat of a tradeoff.

Rollback netcode minimizes latency by having your inputs register immediately, and by only sending inputs, which minimizes the amount of bandwidth it uses and makes the game feel silky smooth.

Rollback can sort of be thought of like delay based netcode, but instead of seeing the present, you're actually seeing into a predicted future where your input has already been registered.

The downside is that when a rollback occurs, the game can look a bit choppy. This can be fixed by increasing the delay time, which slowly brings it closer to delay-based netcode benefitting visual clarity at the direct cost of responsiveness.

But it still surpasses delay-based netcode in its ability to allow each player to customize their own input latency, and in its ability to adapt to fluctuating networking conditions.

This is why most developers consider rollback netcode to be the objectively best netcode solution. Because it solves all of the problems the other netcode solutions solve, but better, and no additional downsides.