Early Prototyping - First Test Build

Early Prototyping – First Test Build

This is the last post in a short series on designing a prototype board game.

Quick jump to all posts in the series:

Here I look at the initial test build that followed a couple of months of spare-time idea development.

Set-up

Getting started, I played out the following pre-made components:

4 sticky corners made from Post-It notes to signify the pay area
2 wizards, one at each end of the play area
A deck of spell cards
A pile of excess counters from Star Wars Armada to use for a variety of purposes
A cardboard range ruler
2 player areas – each had:
- A ‘Wizard Card’ to show the Wizard’s stats
- A hand of 5 spells taken from the spell deck

Knocking-up the missing parts

At the point of trying my first test build I had only come up with the creature activity track idea in theory, so I had to put one together on-the-fly before I could start. A handy tip – always have a pen, some cardboard and some scissors handy so you can realise ideas as you have them.

Immediate feedback

After a few turns of wizards activating, and summoning creatures, it became apparent that I’d need another bit of cardboard. As players buy activations and place the counters on the activity track, the track eventually fills up. The simple solution to this was to wrap-around any new counters and place them on the left of the track once the track had filled up. I figured that this could introduce some confusion as where to take the next activity counter from, so I created a super high-tech triangle (not an angry triangle, I should add) to point to where in the activity track the current counter should be pulled from.

This is an obvious instance of where getting real feedback from running a test build is invaluable. It also highlighted obvious future problems – in a many-player game, how do you stop the track getting completely full to the point where no more counters can be added? This was something to note down as a future design problem. I’d ideally want to be able to have a varied track length to allow for a varied number of players – more players would require more space on the track.

The activity track with two Star Wars Armada tokesn to represent when the Wziard characters wil act

The activity track with a hastily created yellow pointer that indicates who on the track is currently acting.

Play testing results

The first thing to note was that even though the game was really crude and basic, I enjoyed playing it. Obviously, this was an encouraging sign. I noted lots of things during the play testing, some of which were obvious problems like the magic dice being super over-powered, and other items were things to observe time to get a feel for, for example, how far should creatures be able to move?

The first test build in play

A hand of spell cards

Here are some other observations and questions that came up during testing:

The current movement and range tool should be suitable for both functions. Spell ranges and creature movement are different scales. It would be nice if there was just a single distance scale in the game – I find having two scales in Star Wars Armada overcomplicated (there is a shooting scale of Short, Medium and Long, and then a distance scale of 1 to 5) especially when they seem to be used inconsistently
How to determine which player goes first? Is this a big enough advantage to care about?
How should ranged combat work? The Elf creature that I tested appeared to be very powerful – being able to cause damage to other creatures at range with no risk to itself could be annoying if there were not any suitable counters. Making them weak ( i.e. glass cannons) would be one obvious but unsatisfactory fix. It’s a good problem to have – there’s lots of scope for experimentation here.
Spell power costs will need balancing. More powerful spells take more ‘power’ to cast. This will also need to be factored into whatever system I create for building wizards for example, if spells have a ‘points cost’ associated with them.
I need to consider whether or not to include some kind of ‘ability test’ mechanic. For example, if a creature was ‘stupid’ and needs to pass some kind of test in order to be activated

During the testing session I made a load of notes in Evernote. The importance of making and processing notes will be the focus of a future post; this testing session highlighted that I need some kind of process to ensure that the processing step happens before memory fails me and I start forgetting what I wrote down really means!

The play area for Wizard 1

Using two Android devices with the Custom Image Dice open in order to roll two sets of contensted dice.

Testing Challenges

By far the biggest challenge that I found with the “just do it” approach to running a test build was that I frequently forgot what was happening in the game. For example, as I dipped in to modify a component or interfere with the design in some way, I would return to the game and not remember whose turn it was, or what I’d just been doing in the game. This problem was aggravated by using non-representative tokens for things like marking creature ownership or which creatures had activated; it’s much harder to remember what the Star Wars Armada ‘Rebel’ token means when you don’t have a properly designed to represent one of the Wizard’s counters on the activity track!

What’s next? More moving parts

Having made a good start with this first test build, the next one will address lots of the issues discovered here, like the need for a well-thought-out ranged combat system. I also want to run with some new concepts. So, for example, I want to start testing with different flavours of wizards, such as witches; I want to try out different flavours of magic (say, necromancy) and combine them with some environmental factors like a day/night cycle.

Stay tuned for details on my next test build, and for some blog posts on methods, process and productivity.