[eluser]Nick Husher[/eluser]
I disagree that it should be entirely client-side. If game-critical logic is executed by your client, you're handing your players a potential means of exploitation. Were I creating something like this, I'd have a 10-second tick function on the client that requests the game state from the server. The server stores the game state in a database or other persistent solution, and hands back updates to the game state to any registered requesting clients. Think about it like a double-blind game of Axis and Allies played over the phone.
Player A calls Controller: "What's the change in state of the game since the last time I called?"
Controller: "Since that time, the Germans have moved into Spain. The Japanese were pushed back in northern China. You received X production points."
Player B calls Controller: "What's the change in state of the game since the last time I called?"
Controller: "::as above::"
Player A: "I would like to move into western Africa, here."
Controller: "Okay. Since the last time you called, the Japanese invaded northern China."
etc...
In this way, all the game logic is held on the server-side and it represents the "blind" in a double-blind game. Almost all card games are such double-blind imperfect-knowledge games, which makes this model suitable.
The details of how you pass those messages back and forth is up to you. I'd use JSON-RPC for simplicity's sake, but you may already have something thought out.
