I’m currently working on a singleplayer physics-orientated game where I would like the physics to be simulated server-side. This because the game will have leadersboards, persistant player progression, etcetera and I want to prevent any type of cheating – basically a pure client-server architecture, the client is “dumb” and only displays what the server wants you to display.

The problem however is that the game will most likely be played by hundreds (maybe thousands) of people at the same time. This concerns me, as it will most likely kill server-processing power if I have to do and maintain hundreds of states at the same time.

I would have no problems moving all of the physics simulations to the client-side, but then I would really need a way to validate if the result of a client simulation is valid. However, I can't figure out how.

I have thought about running the simulation server-side once in a while to validate if the client is still playing fair, but I really want the server to have as less strain as possible.

Physics will become about as complex as the GDC 2011 demo by Glenn Fiedler, maybe even simpler. However, a lot more always-colliding rigid-bodies will be in a single scene and they will all be visible at once.

I have a hard time getting an answer to this particular case, as most resources on the web - again, Glenn Fiedlers site being a great one - speak about small-scale networked physics (eg. a FPS with 30 players, like Halo).

Any advice, websites, papers or the like on the subject will be very appreciated.

A recap of the questions I would like an answer to:

  • How feasible is a client-server model? Is my server-processing power concern legit and grounded?
  • Is it possible to reliably validate a physic simulation run by the client on the server? If so, how?
  • \$\begingroup\$ I'll leave this question open a little bit longer in hopes more people will post their thoughts. My thanks go out to those who alread did! \$\endgroup\$ – Lennard Fonteijn Mar 8 '12 at 15:12
  • \$\begingroup\$ As long as different clients are independent, you should have no problem scaling horizontally. Use something like EC2, bring capacity online as-needed. \$\endgroup\$ – ipeet Mar 8 '12 at 17:52
  • 1
    \$\begingroup\$ Where is the problem if somebody cheats in a single player game? Just let them, better drop the leaderboard idea and focus on making a fun single player game \$\endgroup\$ – Maik Semder Mar 8 '12 at 19:08
  • 2
    \$\begingroup\$ "Is it possible to reliably validate a physic simulation run by the client on the server?" Yes its possible to validate it, but reading your comments below: Your planning on giving out RL money to top scores, and its similar to a game of darts, ie after the initial throw physics take over. The problem here is less to validate the physics, this is easy. The problem is that you will have cheaters who let a computer program do the throw to give them perfect scores. \$\endgroup\$ – Daniel Carlsson Mar 8 '12 at 19:30
  • \$\begingroup\$ Server validated physics in a shared world is entirely possible, DCUO is a good example of this. Please note that "server" really means "a bunch of server boxes" while you seem to write in terms of a "sever" being a single box sitting somewhere. You cannot currently simulate thousands of independent actors in the same physical space, thus the lack of discussion about it; what you can do is spread thousands of players out into independent islands of simulation that don't interact. \$\endgroup\$ – Patrick Hughes Mar 8 '12 at 20:22

You can validate client-side the submissions of other users, and have the client report to the server if a submission looks invalid.

Then you can take action (either ban the cheater, or ban who forged the false report). To check yourself if that submission is really invalid or not you can use a special client or whatever.

  • 3
    \$\begingroup\$ That is actually pretty damn smart! Wouldn't have thought of that, obviously at least 2 or 3 clients would have to run the simulation in case the client running someone else his simulation is cheating - in which case the server can always do the final simulation if all clients report something weird. \$\endgroup\$ – Lennard Fonteijn Mar 8 '12 at 11:43

Your game is singleplayer, the only 'interaction' with the other players is a leaderbord. You could spawn an instance to check a simulation on your server for each submission, you don't need all the tricks of making sure physics are the same over 30 clients, so I don't think you need more resources than you have already since the physics are already working :).

Checking every result is gonna be a bit overkill, you could send the simulation compressed to the server whenever someone sends a score to the leaderbord, then only check the top 5% scores on your own server, or maybe even the top 1% or even smarter only check new highscores and assume everyone not better than #1 probably has a non-cheated simulation.

I don't know if your simulation is like, set up and don't interact (easy to check) or if players can interact with the sim while it is running, but be sure to do your physics in such a way that different floating point representations don't mess stuff up and make a valid run look invalid .

  • \$\begingroup\$ I don't want to get into specifics of the gameplay itself, but you can compare my game to that of the game of darts: Once you've aimed and made the throw, physics take over and there is nothing you can change about it anymore. Would this knowledge change your answer? \$\endgroup\$ – Lennard Fonteijn Mar 8 '12 at 10:45
  • \$\begingroup\$ Nope, it wouldn't change a thing :). Just store replays on the server and only check suspicious ones (eg new highscores) \$\endgroup\$ – Roy T. Mar 8 '12 at 18:49

Don't do it, I can assure you that simulating physics solely on the server is a very bad idea. The main problem isn't server load, but responsiveness. The responsiveness on the client will be incredibly poor. The player will hit a button, then you'll have to make a round trip to the server before you get the results of the simulation. I've done variations of this in the past (mostly just button presses), and the results aren't pretty and should solely be done for very slow games which have any chances of getting away with it (and even in those cases the perceived lack of responsiveness is a huge issue).

A better scheme which I've been intending to try the next time this type of scenario presents itself is to pick players a very small subset of your playerbase, then you simulate for them server side for a short while and compare your results to theirs, without their knowledge. If they're deviating by to much (you have to expect some degrees of divergence), then you classify them as potential cheaters, and continue to simulate them for a while longer to confirm. What you'll get is some sort of curve by how much a legit player diverges compared to the server, influenced by network conditions etc, and you'll quickly see that the cheaters are outside of this curve. This system has the following benefits:

  • Automated
  • You don't sacrifice responsiveness
  • As you just simulate a very small subset of your playerbase the load will be manageable, and even scalable (perhaps you pick fewer players to simulate if the load is high)
  • Applicable to every game I can think of, so highly reusable
  • \$\begingroup\$ So, like Roy, you basically say: Keep it client-side, store "replays" when clients submit a score and only validate those replays once in a while (not all of them, a small percentage). What if based on the score the client submits a credit-payout is done - the player-progression part, credits can also be bought with real money (!!!) - do you still recommend this approach? If cheating gives excessive amounts of credits and I only validate once in a while, I would basically lose money. You can probably flag a person when his score is above a certain threshold, but would there be a better way? \$\endgroup\$ – Lennard Fonteijn Mar 8 '12 at 11:19
  • \$\begingroup\$ If the physics engine is deterministic (it should be) and the server simulates using the same start state and inputs as the client (which should be feasible), then the results should be within reasonable floating point error bounds (insignificant). Even if there are random effects, and it isn't feasible to pass over the RNG state, you can pass over the random numbers and use them for checking (and even check their distribution, in case fudging random rolls makes a big gameplay difference). \$\endgroup\$ – ipeet Mar 8 '12 at 17:50
  • \$\begingroup\$ Ones credits are involved you'd better check every single replay since the cheating is no longer to get on top of the highscore list but to get money. You want a lot more security if money is involved, I can't help you there. \$\endgroup\$ – Roy T. Mar 8 '12 at 18:50
  • \$\begingroup\$ @RoyT. I'll probably do that anyway, even if I don't payout money based on credits (someone misread that I guess?). I intend to have a zero-tolerance policy, so I just batch the replay-file for validation. If it's really suspicious, I take action. \$\endgroup\$ – Lennard Fonteijn Mar 9 '12 at 8:04

As Daniel stated, the big issue here is going to be programs which perform the action for the player; no in-game physics skewing would be necessary if the player was robotic arm with precision normally resolved for neurosurgery.

  • \$\begingroup\$ I might have been a bit unclear. My games will grant you virtual credits after you've completed a game. You can use these credits to unlock new content to play with. You can also use real money to buy credits to unlock content faster (mind you it's not Pay2Win, I hate that). I have no intentions paying out real money based on credits. That said, darts was only a metaphore to describe how much influence a gamer has on the state of the rigid-bodies, I'm not afraid of "aimbots" as that will give you 0 advantage. \$\endgroup\$ – Lennard Fonteijn Mar 9 '12 at 7:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.