Please put up some screenies.

Sorry for the late reply, I thought I'm ignored all together.

That much I have figured out. The question is how do I efficiently manage the states when server states and client states work differently. I have found a solution as listed but I think it's too convoluted for the task.

No, I know how to implement networking. It's definitely a design problem.

Hello, I'm a newcomer. Gotta remark that the registration question was the most interesting of all the forums I've been to.


Long story:

In my game objects (mostly units) can have different sprites and animation depending on the state like idling, moving from A to B, attacking X, etc. Since these states are standard among all units and (I guess) there are potentially infinite of them I think I should pluck that bit out and put it as its own somewhere, like an animator set of classes. At the moment the game just draw the "idle" sequence for everything.

The game is multiplayer, turn-based has a server-client structure. Actions arent revealed until the resolution phase. The server doesnt care about sprite facing or states; it just carry out instructions sent from the client when the player hit the "resolve turn" button (and sprite facing doesn't matter with 360 degree vision). An unit who is "moving from A to B" to one person might still be "idle" for an other. For it to work, I guess the client side should memorize its own set of known units as well as their states and duct tape the animation handling to the unit which I think involving extending the original Unit class of the server to accommodate the extra properties.


The problem:

Sounds too complex and too much work just to choose which sprite to draw to the screen. I've flipped over some game dev books but they dont touch this kind of details. Any suggestion?