Hacker News Reader

Comment by sehrope | Hacker News Reader

> It is faster paced games where you can't do everything server side that are the problem, first person shooters being the prime example.

First person shooters can be (and I believe usually are) done server side. Official movement, firing, health, and overall physics is handled 100% on the server. To smooth things out though, the client interpolates its view of the world.

For example lets say you fire your gun at a person right in front of you. The server would have final say of whether you actually hit the target. Rather than waiting for a round trip to the server, your client may choose to immediately show some blood/shrapnel effects to give you the illusion that you hit them. If you actually did, the server will handle the health deduction. If not, you probably wouldn't even notice.

View on HN

Right and wrong.

Movement and such can be done server-side, mainly.

But visibility pretty much has to be done client-side. Which means that people can hack the client to see through walls. You can do culling server-side to an extent, but not entirely - because otherwise someone with a high latency coming around a corner will have no chance against someone with low latency on the other side.

Also, servers pretty much have to (well, not really. But otherwise games become unplayable to those with higher latencies, as where you see other players is not where you need to fire to hit them) allow you to hit someone that was, according to your client game tick, in target when you fired. Which means that the client has to tell the server what game "tick" the client fired on. Which allows for cheating if the client deliberately tells the server that it fired/started to move on an earlier tick than it actually did.

First person shooters are split, part server and part client. For example, an enemy comes in range of you, your cheat automatically triggers a "shoot at the precise direction of their head" command to be send to the server. The server does not check if you were actually facing that direction, it does not check if you actually turned to face them in a manner that a human could. So things like aimbots are common where you literally click "next target" and it cycles through all the enemies heads. There is really no way to prevent this kind of cheating. Slower paced RPG style games where you just send "attack target with ability X" can be handled entirely server side. As we start seeing more fast paced action style MMOGs and fewer "computer reproduction of pen+paper+dice" style MMOGs the line gets blurred and more impossible to deal with cheats become problems.

But, but, you just said how to prevent it! "Check if you actually turned to face them..." would work just fine?

If you just check that they did face the right way, then cheating is still trivial. Just instantly turn and fire instead of just firing (this is what aimbots actually do anyways). The problem is you can't have the client send all 1000 "the mouse position changed" events to the server and have it approve them to ensure that you actually moved the mouse rather than just instantly changing to pointing straight at the enemy's head.

You can't validate each mouse click before updating the client's view, but you can do the same aim validation as you do movement validation to prevent teleportation or excessive movement. Basicly, validating 1,000 motions a second is no problem it's latency that's the issue. So now you can still cheat but your limited to human reaction times or the server can detect and boot you.

Maybe stats on the behavior would work. You can tell who's typing on a keyboard by running stats on the inter-key delays etc. Probably stats on commands to the server (turn, fire delay etc) would identify bots pretty well.

Reply on news.ycombinator.com