Advertisement

access to gamestate

Started by February 04, 2005 03:25 AM
4 comments, last by pi2r 20 years ago
hi all, we're currently working on a multiplayer shoot game and we have some question about accessing to the server gamestate : In our server, we maintain a gamestate which represente the real current world state (players positions, shoots, ennemys, ...) so we update this gamestate each time we receive a request from a client. At every tick, we send the new gamestate to all the clients. The problem is that we update the gamestate (cause we continue to receive requests) while we're sending it to clients for update, so what is the way to deal with concurrent access troubles ? hope that's clear and sorry for my bad english :) vince
I'd say pipe it, once a gamestate is populated with as many as what have replied send it out regardless - with movements of other players recieved yet set at their last movements.

Once every few frames force a sync where everybody has to have replied before the game continues... eg it pauses everyones screen until it has the whole picture.

Using that method though the game experience is tied to your slowest connected player.
Anything posted is personal opinion which does not in anyway reflect or represent my employer. Any code and opinion is expressed “as is” and used at your own risk – it does not constitute a legal relationship of any kind.
Advertisement
hi paulecoyote,

thanks for answering but could you be more explicit ?
I didn't understand everything

what do you mean by "pipe it" ?
isn't there a way in order not to be tied to the slowest connected player ?
Maybe this can be of interest for you http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.html
I think what you're saying is that your networking code changes the state of the world while you're in the process of simulating the world. If that is the case, you should not run network response in a different thread from simulation.

Instead, the networking should accumulate messages from players into a queue. The server should simulate the world at a fixed rate (say, 50 steps a second). Each simulation step looks something like:

- dequeue messages intended for this step
- apply messages
- update world
- send updates to clients if appropriate

Thus, the state does not change while you're simulating, because you queue the incoming messages.
enum Bool { True, False, FileNotFound };
ok it seems clear to me now :)

thanks all !

This topic is closed to new replies.

Advertisement