Hi, I am creating a turn based online strategic game similar to Empire Deluxe using Silverlight and WCF as my web server. I also have SQL and SQL Express available if I need to use a database. My question is what's the best way to store the game state on the server side? Are there any good articles on this? Each time a player does a action the server will have to validate, process and update the state returning the result to the client. Does the server need to pull the entire state of the game each time a player makes a move? Obviously I shouldn’t store the entire game state in memory on the server since you never know when a player will make their next move and there could be hundreds of games running simultaneously. Any pointers would be appreciated. Thanks, --Mike http://www.flaired.com [Edited by - silverlightDev on March 11, 2010 4:05:18 PM]

Thanks for the reply. Looks like using a DB is the best way to capture and store the state of the game.

This means that each time a player does an action i'll have to update the database with the change of state.

Thanks for the tables also!

--Mike

Quote:Original post by silverlightDev
Hi, I am creating a turn based online strategic game similar to Empire Deluxe using Silverlight and WCF as my web server. I also have SQL and SQL Express available if I need to use a database.

Cool! [smile]

Quote:My question is what's the best way to store the game state on the server side? Are there any good articles on this?

There's really no best way to do things. Do what makes sense, but feel free to ask questions about specific problems.

Quote:Each time a player does a action the server will have to validate, process and update the state returning the result to the client.

Yep, unless client actions can somehow be chained together without side effects and send in one batch. Often this is not the case.

Quote:Does the server need to pull the entire state of the game each time a player makes a move?

I'm a little unsure about the "server pulling state", because the server is either pushing state to the client or sends a response due to a client's request for state.

Ideally, the client should be as thin as possible. I should be able to play the game by just sending commands and receiving the new state, no matter what the client looks like or how it behaves. This ensures that you can rely on the integrity of the state on the server at all time, and there's always a way to synchronize the client if it falls behind.

On the other hand, you don't want to create more network traffic than necessary. Not even so much because of bandwidth, but rather because you want to provide a 'smooth' user experience. If every mouse click triggers a round trip to the server, the interface might become unresponsive and slow and might frustrate the user.

Send or request whatever is needed to have the game client accurately reflect the game's state as stored on the server.

Quote:Obviously I shouldn’t store the entire game state in memory on the server since you never know when a player will make their next move and there could be hundreds of games running simultaneously.

No, if this is an event driven and turn based game, you may not need to explicitly keep things in memory, let the database engine take care of that.