send keys or let the client calculate?

Networking & Multiplayer
#1

hi folks - it’s my first post here so I hope I’m in the right forum (read some quite interesting threads already though)

this is the situation - me and a friend are trying to plan (no coding yet and won’t be for some more time) an mmog - yes I know everybody now says “oh my god another one” - anyway we’re both developers and fully aware of the problems and the size of the job, it’s only for fun really

we already have quite a elaborated plan on how to do the load balancing and position calculating / distributing - the big problem though is that everything is done client side which directly writes into our position-caches and thus finally in the database. the way we planned it we even let them calculate distributed jobs like movement of asteroids and moons and other slow objects and orbits aso (it’s a space shooter) up to now we use almost no processing power on server side and think it might work

now one of our big questions is: if we let clients calculate their position we’re damned to have loads of cheaters and, maybe even more dangerous, false data coming back as we got no serverside check of the calculations (well we do for the distributed jobs but not for the player himself) - so our only solution atm would be to heavily encrypt all communication and build in complicated checks for the calculation client side hoping to prevent cheaters from inserting their code too easily, anyway I’m aware that there will be a way around it

so do you think it is possible to do it that way or do we have to calculate everything serverside (by sending only the keypress). that would mean a lot more processing power server side and it has to be quick as we need a good ping contrary to WoW for example which you can play with a ping of 700…

many thanks for any help / suggestions!
Muffin

#2

Sending just keypresses is going to lead to bad responsiveness for the player. Let the client maintain its own state and transmit it to the server. However, run crosschecks against the recieved state on the server against what the player has sent you. I.e. if their speed is limited to X is it possible that they’ve travelled to where they say they are.

Any client code you write will be open to cheaters (no matter the lanaguage, protocol, intricacy), just plan on the cheaters.

Some times voting systems also work well, let the player self regulate, if they see some cheat accept a cheater report get too many and the cheater starts getting extra crosschecks and/or gets kicked off.

Kev

#3

I agree. The best way that I know of is to let the client be pretty much authoritative about its position, orientation, and other factors that require responsiveness.

Then your task is to make intelligent validation code on the server. This is a challenge, but you can get most of the way there pretty quickly. You can certainly determine whether the player is physically capable of being where he says he is. However you certainly need some kind of thresholding to get over lag, packet loss, and other factors. So for instance on the server you might allow the player to move 110% as fast as he should. Without a threshold you can get into the situation of ‘false positives’ of invalid movement, causing a undesirable rubberband effect when it is not appropriate.

You might also be able to do some historical collection per-player, such as:

  • how often does this player trip the validator
  • what is the average rate the player falls within the valid range (e.g. 80% mean, some sigma deviation). Is the player maintaining an unusually high mean movement rate?
  • does the player’s movement rate mean / re-validation rate appropriately correspond to the measured latency/packet loss to the player? If the player has a good connection to the server, and is sending/receiving updates in a timely manner, validation errors should decrease.

etc…

#4

As others have said, tyo do internet games you need to deal with latncy hiding. The only way to do that is with open-loop communication and handloing as much of the visible response as you reasonably can locally,.

#5

thanks folks - that’s about what we expected, although we’re not sure about how to ensure correct positions without recalculating a lot. ah well we’ll see

thanks again! and expect more questions to follow :wink:

#6

You WONT ensure correct positions.

Each player’s game will be a slightly different version of the world-- an approximation of everyone elses.

They key is to figure out who’s POV matters when makign a decision.

Take any FPS as an example. The shooter has a reticle and can see whether hes on or off the target, everyoen else has a general idea only by virtue of the direction the shooter is pointing, so you can let the shooter decide if its a hit or miss.

The only issue with this is cheating. if cheating is something you think you might have to dela withm then you run a process on ther server that is ALSO approximating and let it decide if a call of any of the clients is within reasonable toleranes of what it thinsk the world state is.

#7

yep and that’s the problem as we didn’t want to use server side processing power to check the player’s calculations - if we can help it. so the main task for us is now to find a good check algorythm that only runs very occasionally, is really primitive and uses almost no bandwith and server cpu - ah well I guess it will have to wait until we have a working client (and that’s anyway after we found a solution to minimize our server-client traffic) atm we’re discussing and discussing and for every problem we solve 3 new ones pop up :-\

#8

Well your p2p solution is to allow each clients to validate the positions of all the other clients and report violations to each other. If an agreement is reached, the offending client can be handicapped or kicked.

#9

Problwem is definign well what constitutes a “violation” since every client will have a slightly different view of the world. How different is “too different”?

Additionally, what do you do if the other clinets disagree?

If you do it by majority vote, a coordinated group of cheaters could really screw up a game.
If you do it by “any objection is too many” then one hacked client cna send bogus objections and screw up the game.

When you have no process you can trust, building trust is hard, plain and simple.

#10

The trust thing is interesting. One possible solution, is each time someone disagrees, you mark it for that client. In the case of a ground of cheaters, the group attacks someone who isn’t, they say they killed, the person being attacked doesn’t, the group each get a ‘disagreed’ count increment, and so does the person being attacked. The kill is allowed. Over time, the group of cheaters will get more and more ‘disagreed’ increments, where as the non cheaters won’t, unless the cheaters always attack the same people. You can then give more consideration to a trusted players vote than a non trusted. If you also log the disagreements, then your game masters will be able to look at whats going on, and should be able to spot the cheaters, or at least flag them as possibles.

It’s a difficult problem, and no single solution would stop a determined cheater for long. You have to have more time to counter them, than they do to cheat. It’s the same as hackers and firewalls. Determine a level of risk you are happy to accept for the amount of work it costs.

Endolf