51–60 of 155 posts
Earlier quoted context omitted.
Yeah, isn't this basically the first thing you learn in game networking?
Or in any sort of networking work where you don't control both ends of a connection.
Earlier quoted context omitted.
If you have a deterministic game model(RNG seeded properly, pure functions, etc) you can actually just send the user inputs(which are very small compared to the whole game state) and replay the whole game to verify. This is the common model in RTS games called Lock Step since all clients are advancing a number of frames based on all inputs from other clients in "lock step". It's also very common way to implement repl…
Using the Bejeweled example of a single-player game, and assuming it's properly deterministic, could a malicious actor not just falsify the steps taken as well as the score? It would be more difficult, but not that much more difficult considering the challenge is the time limit and lack of undo. Both would be removed if you were simulating steps.
Earlier quoted context omitted.
If you have a deterministic game model(RNG seeded properly, pure functions, etc) you can actually just send the user inputs(which are very small compared to the whole game state) and replay the whole game to verify. This is the common model in RTS games called Lock Step since all clients are advancing a number of frames based on all inputs from other clients in "lock step". It's also very common way to implement repl…
Using the Bejeweled example of a single-player game, and assuming it's properly deterministic, could a malicious actor not just falsify the steps taken as well as the score? It would be more difficult, but not that much more difficult considering the challenge is the time limit and lack of undo. Both would be removed if you were simulating steps.
There's a sibling comment below that mentions this. Most RTS games checksum the game state and send an out of sync when the checksums fail. If you generated different random values you'd definitely hit this.
Always sucked when it happens about 1 hour into a game of Homeworld.
"Never trust the client" is good advice for every kind of application. Clients are filthy liars. Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you. The server should always be the source of truth. It shoul…
Things like Punk Buster, et. al. are more like anti-virus software: they try to find the signatures of known chat clients.
So it's best to write you own...and rename your debugging process to "Google Chrome." He got pretty far with his auto-walker in some MMOs. He had limiters so his runs wouldn't be too fast and would go up/downhill correctly...or so he though. He forgot to multiple by -1 somewhere and the server banned him for attempting to fly of into space.
Earlier quoted context omitted.
If you have a deterministic game model(RNG seeded properly, pure functions, etc) you can actually just send the user inputs(which are very small compared to the whole game state) and replay the whole game to verify. This is the common model in RTS games called Lock Step since all clients are advancing a number of frames based on all inputs from other clients in "lock step". It's also very common way to implement repl…
Using the Bejeweled example of a single-player game, and assuming it's properly deterministic, could a malicious actor not just falsify the steps taken as well as the score? It would be more difficult, but not that much more difficult considering the challenge is the time limit and lack of undo. Both would be removed if you were simulating steps.
They missed one key bit on CS's network model(which is what made it so great) is that they would actually re-wind the gamestate to do hitchecks so you could have a latency of 200ms+ and have a reasonable experience. Also the common term for resolving these types of things on the client is called "dead-reckoning". You've always got a diverging states from latency so you're continuously trying to reconcile this on the…
There's something I always wondered about the gamestate rewind thing: Is it correct that the gamestate rewind only works for hitscan weapons (instant hit bullet)? What about slow moving projectiles or physically accurate bullets? Can the server spawn the projectile 200ms in the past at the time you pressed the button? But then other clients would receive the information about 400ms later after the initial keypress, w…
Since as a player you're trying to shoot the projectile to "predict" where it will intersect you're actually playing to the strength of latency and dead reckoning(that's the SubSpace case above).
You want to segregate your action into twitch(reactionary: hitscan, parry, etc) and predictive(slow projectile, > 250ms ttl, etc) and only rewind/replay for the twitch case.
There's also the case that when you rewind and do confirm a gamestate change you need to gracefully handle resolving it on all clients. That's why you'd see people warp back around corners when shot in Counter-Strike. Their player movement speed slowed after being hit and the server reconciles it and then the clients interpolate the result.
Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…
For us, there was no foolproof method. So our main goal was to ensure that the leaderboard wasn't full of obvious cheating.
First, to reduce the volume of cheating, we obfuscated things:
1) We encrypted all communication.
2) We required a single use submit token, generated by the server, with each game play.
We also manually reviewed scores. In particular, the top 10 scores of each game.
Beyond that, since we required a single use submit token, it means that we knew how long the player took to obtain their score. For most games, the higher your score, the longer you played. So we flagged any scores with an out of whack score/play time ratio for further review before showing the score to anyone else.
"Never trust the client" is good advice for every kind of application. Clients are filthy liars. Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you. The server should always be the source of truth. It shoul…
I saw a talk where a guy was showing how to cheat at some games. A lot of games will detect and crash you out if they detect a debugger attached to them. Things like Punk Buster, et. al. are more like anti-virus software: they try to find the signatures of known chat clients. So it's best to write you own...and rename your debugging process to "Google Chrome." He got pretty far with his auto-walker in some MMOs. He h…
Console port gone horribly wrong? I mean, how else do you violate the most simple of game rules - never trust the client?
The irony is that the console versions are the least-impacted, as the client-side hacks are only loadable on the PC version.
Porting that same idea to PCs gets you into trouble almost instantly.
Hence my question - is this a console port gone horribly wrong?
Console port gone horribly wrong? I mean, how else do you violate the most simple of game rules - never trust the client?
The irony is that the console versions are the least-impacted, as the client-side hacks are only loadable on the PC version.
It could have been developed for console first.