So this is something kind of new, as I've never saw anywhere, but maybe already exists:

The game is divided in 3 pieces: the actual game logic (game), the visual part (view) and something that link the game to the view. Nothing new until now.

Now this is a board game, therefore there are no physic involved, so I do like this:

Here is what happens when I roll the dices:

  • game calculates the dices
  • controller listen the dices rolled event and report to the view*
  • game move the player from A to B
  • controller listen and report to the view*

This happens instantly until this point. *: the controller run the method "rollDices" on the view, and the view queue the action for when it can. Then the view queue the "movePlayer" action too.

So after the 4 steps showed before the view actually starts to update itself, making the animation for the dices that takes 5 seconds and moving the player, which takes another 3 seconds.

If you roll the dices while the view is still animating the game acts normally, as is not coupled in any way to the view. So the view will also queue the next dices and player move. When the game needs some player interaction such as a confirmation or so, it will wait for it.

What do you think? is this bad/can have flaws or is not scalable?

My objective is to decouple entirely the game logic from the view.

thanks for your oppinion

  • \$\begingroup\$ I don't think this is constructive. What could go wrong is a pretty broad question, and this question is asking for a discussion. See the FAQ to learn what types of questions to ask here. \$\endgroup\$ – MichaelHouse Dec 25 '12 at 8:16
  • \$\begingroup\$ can you say to me a place where I might ask this? thanks \$\endgroup\$ – Totty.js Dec 25 '12 at 13:32
  • \$\begingroup\$ If you read the FAQ as I suggested, you will find other places to ask. Gamedev.net or reddit.com/r/gamedev are two. \$\endgroup\$ – MichaelHouse Dec 25 '12 at 16:30

I've used a very similar architecture for a non-real-time game before, with great success. I had a simple action list (the queue variety) that was filled mostly with animations but also with game state commands ("wait for player to select valid move" or whatnot). I hence feel that it's an entirely reasonable architecture.

One of my particular goals was allowing the UI to play out pre-recorded games with almost no extra logic from games that were being played actively; events were fed into the view layer and it played them. This also let us easily build a local AI option to smoke test the game, which was invaluable (as it has been on every game I've worked on that had it, turn-based or real-time).

You will likely need to add more advanced scheduling to your animation queue at some point. e.g., "play these two animations now and wait for both of them to finish," or even "play these two sequences of animations, and wait for both to finish." You'll also want separate animation queues for disconnected parts of the game UI, like menus UI vs the actual game board.

The tricky part comes down to animations that are in direct response to user interaction. Say you want to have a game object moved by the player by dragging it to a desired location (in your case, say, to move a piece on the board). These kinds of animations don't fit quite as well into a queue pattern, since they are not "fire and forget" but rather are constantly updated and modified as the player interacts with the pieces. I solved this by having two different animation managers: the queue for system-driven state-change animations, and then a simpler layered animation system targeted specifically at drag-n-drop, hover effects, selection effects, etc.

Another interesting note is that you can well have a mixture of both types of animations in some cases. Say you have a long system-driven animation, like dice rolling and pieces moving in your example, but you don't want the game board to become completely non-interactive while the animations play (because that makes your game look and feel like a 1990's relic, and users expect iOS-like smoothness and interactivity these days). I solved this by having the animations in the queue control an object's "natural" transform/state, and the interaction animations controlling "actual" transform/state information (and if there are no interaction animations on an object, then the actual transform is equal to the natural one). A few specialized tweaks were needed to make it feel and look really good, but it worked quite well even without those.

While I assume you're working in 2D, I did this all in 3D, and it worked equally well there. The animations and interaction code are slightly more complex but the architecture to manage and schedule them can all be the same.

| improve this answer | |
  • \$\begingroup\$ thanks for your answer (: was exactly what I was looking for. I didn't even considered "play these two sequences of animations, and wait for both to finish." \$\endgroup\$ – Totty.js Dec 25 '12 at 13:37
  • \$\begingroup\$ I accomplished that efficiently using masks. Each animation has a bitmask, and only one animation with any particular bit set in the mask can run at a time. So the two sequences were just set with different bits, say 0x01 and 0x02. Afterwards is a do-nothing empty animation with all bits set, which "syncs" any prior animations in the queue (which isn't strictly a queue, really) and must complete before any following animation can run. \$\endgroup\$ – Sean Middleditch Dec 25 '12 at 20:06

You might want to check out the MVC-pattern:


| improve this answer | |
  • \$\begingroup\$ I know about it, the question is about the queue in the view \$\endgroup\$ – Totty.js Dec 25 '12 at 2:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.