Client side hit detection vs server side with prediction

Started by
7 comments, last by hplus0603 8 years, 10 months ago

So I'm working on a multiplayer game, and I've been reading that a lot of games lately have been switching to client side hit detection. I thought that the best way was supposed to be server side hit detection with hitbox rewinding, not client side hit detection. I know client side gives a better feel to the guns, but it's supposed to be much easier to cheat too and as far as I understand, rewinding hitboxes and predicting the effects on the client should be able to produce the same feeling of responsiveness. What are the benefits to doing it client side that are causing more games to use it lately? Is it just that it's easier to write? Or are there some other advantages to doing it client side that I'm not aware of?

Advertisement
It is easier to write, which is sometimes an important trait.
Also, server rewind may still suffer from dropped/delayed packets, where the server comes to a different conclusion than the client.
If you use client-side hit detection, the client will "never" have the feeling of lag (but may, instead, have the feeling of someone else shooting them when they feel they alread dove into cover.)
enum Bool { True, False, FileNotFound };

What about for games with really fast movement speed? It actually makes sense if you think about it then, because the feeling of getting shot around a corner might not be so common when you fly past the corner at insane speeds (like TitanFall) and people aren't really going to be able to hit that easily anyways.

It is easier to write, which is sometimes an important trait.
Also, server rewind may still suffer from dropped/delayed packets, where the server comes to a different conclusion than the client.
If you use client-side hit detection, the client will "never" have the feeling of lag (but may, instead, have the feeling of someone else shooting them when they feel they alread dove into cover.)

With server-rewind strategies you can experience the worst of both worlds: where sometimes what the client sees isn't what happens on the server, and also client players taking damage after finding cover from an attacker.

As a gamer, though, I would rather that my attacks register exactly, even if that means I may get hit behind a corner. It is vastly more frustrating to me to be skilled and capable of pulling off really great shots, only to have them not register because of high latency jitter, than it is to get hit after running behind a corner. I feel more cheated when my shots don't "register" than when I get hit behind a corner.

Im curious, what games are you reading are switching to client side hit detecrion? Are they on console?

Console games are harder to hack, making client side hit detection more of an acceptable risk. Because there are so many console shooters now, it may be more popular.

Keep in mind, not all games that employ a shooting mechanic have the same requirements.

The penalty for inviting "cheating" in a 1v1 shooting game with hitscan weapons, is much higher than a squad-based PvE experience.

Take Firefall (MMOFPS) for example.

For each client, for each shot, you could rewind all enemies that could potentially be hit. This is a massive performance cost for the scale of the game.

Or you could give authority to the client - this would only have a very small quality degradation for other players, whilst drastically reducing performance cost on server.

You would still have, for example, other validation on "fire" inputs, e.g. delay between firing.

Engine, graphics, low-level, security and cross-platform programming. xsngine

Im curious, what games are you reading are switching to client side hit detecrion? Are they on console?

Console games are harder to hack, making client side hit detection more of an acceptable risk. Because there are so many console shooters now, it may be more popular.

Battlefield series swithed to (semi) client side hit detection in bf4 and bf3.
It was a huge problem at start (instalkill hackers) but got gradually better when they added allot of checks on the server side to determine if shots were possible.

Isn't it shortsighted to invite cheaters when you know many of them exist? I'd think requiring people to aim a little ahead would be less damaging than having people suffer from being cheated?
If they needed to add server checks anyway they gained nothing from avoiding them?

Isn't it shortsighted to invite cheaters when you know many of them exist?


Cheaters are not drawn to a game until there exists a large community so that the pay-off of seeming better than you are actually is worth the trouble.
To get to the point where you have a large community, you need to build a game that is fun to play.
Building a game that is fun to play is probably easier when using client-side detection and not worrying about cheaters yet.

It's better to have a popular game, and having to start coming up with anti-cheat code, than it is to have an unpopular game that dies because of a lack of players.
A popular game that doesn't have cheat problems is, of course, the best, if you have that option.

When considering schedule and technology, you really should consider the capabilities of your team and your budget, to avoid wasting effort of features you don't need /yet/.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement