Page: Guide.ModelingDesign32 - Last Modified : Tue, 30 Sep 14 - 1668 Visits

Turn Sequence

I want to talk a bit about turn sequence because this is the part of the rules that is not attached to any object in particular. It's like our game engine. There are various ways to handle turn order and it gets more complicated if multiple players are involved. So I will talk about what you should be dealing with, but there are possibly other options to explore.

Actors

First there is the entity doing the action. Most of the time stuff are being done by either the player or the game. Either it's the time for a player to make one or multiple actions, or either it's the time for the game do to certain actions. Game actions are normally used for game upkeep or for simulating an artificial intelligence. While players actions are actually things done for the player.

It could be possible that a player is forced to do something, like roll a die before moving. Even if the player does not get to chose anything in the roll and move step of the game, it is still the player that is doing the action for himself (moving his won pawn). While game actions are done by players because there is nobody else that could do so. But players don't do it for themselves, they do it to make the game progress.

For example, in shadow over camelot, players can chose which bad action they will do. But the resolution of those action, like adding a despair to the grail quest is a game maintenance operation done by the player but not for the player.

Single or Multiple actions

During a player or a game phase, one or multiple actions can be done. This impact the amount of things players can do before it's time for the game to update itself. In shadow over camelot, each player action will trigger a game action. In starcraft, players will be able to do 4 actions before the regrouping phase, which is a game upkeep operation. This all depends on the pacing, how much do you want the player to do before the game update itself.

Multi players VS Solitaire

Multi player screw up many things especially when multiple actions per player are involved. Some game makes a player play all his actions then skip to the next player. This creates down time for the other players. While other games like Twilight Imperium 3 and Eclipse makes each player do 1 action at a time until they did all their actions. This creates the "Who's turn is it?" syndrome. There can also be simultaneous actions, which could create confusion and conflict or even unintentional cheating, but saves downtime.

Solitaire games are most likely to let the player do a certain number of actions, then do some game upkeep operation. Maybe not all upkeep step are done all the time, but it still follow the same logic. When you add players now you need to determine how to switch between players, this is why there is more options.

Different phases or actions lists

In one of the 19XX game, you have a development step and 2 operating step. So in that case the things that could be done in the development step was not the same than in the operating steps. Game upkeep that are long, should make sure they don't happen often. Else they could be split in various smaller task. One idea I had for my game could look like something similar: Each 2 weeks update the shops, each month update the repairs, each 3 months update the diplomatic progress, etc. So that I don't have to do everything every 2 weeks or even every day.

So it was a vague exploration of the turn order. For solo game, I think there will be one or 2 working model that will be reused in all game. If the game offer a 2 player options, then you'll have to determine how the switching between players is done and make sure there is no conflicts.

Work flow

Is the work flow any different then regular board game design? Well no, you are still going to use an iterative work flow, it would just be more structured than before. For those not familiar with work flow, originally people thought that computer software used the waterfall work flow which is do step A then B then C and the program is over. But in practice, people do step A, B and C. Check what does not work, refine their design and go through A, B, C again. Here is some images I googled to illustrate those concepts:

Iterative Workflow	Waterfall Workflow

Now about the model view controller, are you going to design those in that specific order? Not necessarily. The order seems quite important because for example view and and controller depends largely on model. But sometimes you'll need to know certain things about the view aspect to design the model aspect. So you are constantly going to switch from one aspect to another until you are satisfied. Then you are going to make a protptype and playtest the design and see how it works. Then modify the model for the second iteration and continue the process.

Now one thing important to specify is that we build up this modeling structure to help building the game, especially a working game. It's like building a wire frame around a new building. Without that frame, we would not be able to make the building, but when only the interior are left building, we don't need the exterior frame anymore.

This is why it will be important in the first few iteration to update the board game model as we make changes, but once we have a working game and know that we are not going to do an overhaul of the mechanics, we do not need to update that design model anymore, because it would only slow us down for no good reason.

I should be ready to start my game example. The following pages will be constantly updated as the game design progress, so keep looking back once a while.

<< Model, View, Controller applied to board games | Table of contents | Fleets and Ships >>