I'm making a 2D, top down MMO game. ATM I can connect a player to a server and they get the map data from a DB. They can move around and hit some stuff and if they move near a viewport edge, the server sends new data etc.
Even a few players can do this, but since I don't have an, lets call it, "update manager" which tells the players where they are and the DB that the map has been altered. It's just a read only game at the moment.
My idea is, to tell the server where a player is and how big his viewport is. Then if any other player is in this viewport, the server will distribute the updates to each other player.
So I wouldn't have to tell the whole world what's going on.
The problem, however, is the ping.
If I have a ping of ~300ms, every other player would probably "jump" over the map, and not move smoothly. I could keep this synchronized with vector clocks, but it would still lag.
Also, how to keep the players from cheating? All ideas I got, don't really work. The only "safe" thing seems to be to calculate the game on the server and client, then throw away all data when the calculations are wrong. But this seems rather excessive to me.
--- Edit ---
Ok, I had some ideas after I read the comments.
I will send an absolute state to the server for ever game entity I have. This state object will consist of the position, orientation, speed and an "action", which can be anything someone can do.
I'm gonna keep the clients seperated in "small" arrays, each representing a area of the map. So I can calculate which client is near or in my viewport and needs to get my information.
I have to find out if it's possible to get a timestamp of the request, to use it for sanity checking, so no player can send me actions from an invalid time-range to get his actions evaluated before the other players.
Only only updates from other clients and errors from the server get sent to the client, if everything is ok the server just takes the informations.
Answer
You have identified the key problems. Your "bounding box" solution to what-to-update seems fine. You may want to make the update box a little wider than the view box, so that actors outside the view are already available if your player starts walking.
The usual solutions to jumping are:
Some assumptions, e.g. other players keep moving in the same direction until the client knows otherwise. This allows the client to project what will happen, providing smooth movement of the other players.
Interpolation / gentle catch up: when the client is told that a player should be 5 squares away from what the client currently sees, instead of jumping him to that position, he is slowly animated to his new projected position over time. So clients will see false information, but activity will appear smooth to them, which is the important thing! If the player is very far away from his correct position (e.g. >15 squares), then jumping him to the new position may be preferable.
You got the right idea about cheating. Only the server should decide what really happened, with the information he has. The clients must defer to whatever the server says, and throw away any wrong information they have.
For this reason, sometimes crucial feedback such as death-animations, frag count, player health, are not automatically updated/projected on the client; instead the client must wait for updates/triggers from the server, before such things are shown. The delay this necessarily causes is seen as a better payoff than showing the client false information.
So animations such as small explosions of a projectile can be shown, if they are identical whether or not they hit a player. But animations describing a hit on a player might be better off delayed, if it is important to players that these are always correct.
No comments:
Post a Comment