Early Prototyping – Turn Order: Who Does What, and When?

This is the  third post in a short series on quick and dirty board game prototyping.

Before I start, here are some quick links to all posts in the series:

1. Early Prototyping – Quick and Dirty
2. Early Prototyping – Dice Mechanics
3. Early Prototyping – Turn Order, Who Does What, and When?
4. Early Prototyping – Completing the Systems
5. Early Prototyping – First Test Build

My previous post looked at dice mechanics and a simple dice based combat system.

In this post, I look at how I approached solving some of the ‘macro’ design issues, which are arguably the most important problems to work on. Here, the biggest problem was comming up with a mechansim to govern the order in which players and their summoned creatures act.

I found it quite difficult to separate out a bunch of different mechanics, so I’ll cover them all here:

• Player turn order
• When to move creatures
• Summoning creatures

My approach

During the month between building components and running with my first test build, I took opportunities to think about specific problems when I could. For example, when driving to see my dad I thought about how spell power, spell flavours and how I could possibly differentiate between different schools of spells. Additionally, I took advantage of lunch hours at work, the advantage here being that I could make notes and sketch out pictures (I work best visually) which you cant do when driving.

Being able to take advantage of such opportunities relies on having a clear picture of the next few problems that you need to solve. Without having these in your head, you can’t think about them when you get the opportunity. In future posts I’ll talk about making notes and managing information – these skills and processes help prepare for when you get time to think.

Making firm ‘anchoring’ decisions

Now, the design process is helped along when you are able to make firm decisions as they help anchor the design process by redcing the scope of what has to be explored and developed. Decisons can always be overturned at a later date.

For example, I want the game turn order to be determined by game mechanics rather than an arbitrary “clockwise around the table” or whatever type approach. Having made this decison really helped steer the direction of my thinking;  I knew it was something that I’d need to develop, but I could rule out any mechanism that was simplistic and abritary. 

Another example is that I wanted creature combat to be decided by rolling a variety of different dice, and to use D8 rather than traditional D6 (see my previous post). 

The ‘activity’ track

Probably the biggest design problem to solve was determining the order in which each player and their summoned creatures act. This is what I call a ‘macro’ design problem since it affects a wide variety of other mechanics and systems. I came up with the idea of having a track onto which players would place counters that represented their right to take a turn or action. Players use special counters that represented their own wizard characters, and use generic ‘activity’ counters that represented a player’s right to take an action with any other non-wizard creature. This is very similar to some turn-based computer games where a track is used to show the order that player characters and NPCs act in.

My activity track would work like this:

• The left-most counter on the track would be picked up by its owning player
• If it was a wizard counter, the player could act with their wizard
  • Once done, the player would place their wizard counter back on the next free space on the track (right-most; at the end)
• If it was a creature counter that the player picked up, the owning player would discard the counter and use it to ‘pay’ for a creature action, and act with one of their creatures

This system solved a number of problems:

• It provided a system where there was no fixed or stagnant turn order
• The turn order itself was now a system istelf that could be interfered with (by spells etc.)
• There would be no dominant ‘first player’ like there is in Star Wars Armada (for example) – while one of the players would always act first. After a short amount of play the original turn order would be obfuscated by activity in the game.
• Game rounds would not be necessary. They’re an arbitrary concept and this activity track is much more organic/real world

Generic vs specific representation

I faced the decision of whether or not each individual creature should have a counter of its own on the activity track, or if not, how to deal with generic counters on the track.

There are a number of problems with using creature-specific counters.

Firstly, there would need to be a way to show counter ownership. If you have two wolf counters, who do they belong to?

Secondly, each and every creature on the game board would need a representative counter on the activity track. That’s more cost and complexity. Additionally, it would be a faff to have to locate the matching counters when setting up the game; counters could get lost, and many more counters would need to be designed and produced. These problems would be exacerbated with the addition of any of game expansions.

Consequently, I chose to run with generic counters, but this introduced a different problem.

It would be possible for a player to use multiple generic counters to activate a creature multiple times in a row. I decided to solve this by introducing the concept of ‘rested’ and ‘tired’ creatures. After taking a turn, a creature would become tired. I’d need a counter to mark tiredness, but that would be a single counter type with a single graphic – much simpler than having individual counters for each specific creature. I’d also need a mechanic for transitioning a creature’s state from ‘tired’ to ‘rested’; I didn’t mind this new requirement as it is a very ‘real world’ and easy to understand the concept. It would also be a simple mechanic that could be interfered with via spells and the like.

Activity track’s physical form

There was still the problem of how to physically make an activity track – I didn’t solve this before I started testing the first build. More on this later. (I have since evolved the activity track concept, and have some ideas to try out in future test builds).

My next blog post will cover the final design challenges to address before playtesting it all.