I'm working on a multiplayer asteroids style game, a demo is web startable from:http://www.cokeandcode.com/astroprime
Currently each client maintains a picture of the arena they are playing in. Each client sends updates of their player N times a second (currently N = 10) to the server. The server then broadcasts the state of all the players to all the players M times a second (currently M = 10).
Although I'm going to add stuff about only sending updates based on changes but this currently seems to work fine for a small number of players just flying around.
I've just started implementing the ships shooting. My orignal idea was to let the status of the ships (e.g. is the fire button pressed) let each of the players know when shots should be produced. This would mean that although the shots wouldn't be perfectly synchonized, it would be [good enough (tm)].
Starting to think about collisions, where to perform the caculation and the assocaited health decrement?
I seem to have 3 options:
1) Maintain a full picture on the server. Every single shot that gets produced, is only produced on the server. All collision detection goes on there. This seems great from a consistancy point of view, but with the overhead of sending message for each shot (and possible maintaining movement?)
2) Each client produces shots for itself, only shots that hit the player on its host machine count. This means that only shots the player "sees" shots hit them actually do damage. Of course, nothing is consistant now. Also, how to handle non-player controled objects. [Also prone to cheats]
3) Some sort of halfway house, maybe players report what they see and server takes what most people "saw". Not quite sure about this, maybe some more refinement.
Currently my fave is number 2, since it fits with the way things currently work.
I'd really appreciate feedback/ideas/pointers..