Early Prototyping - Completing the Systems

Early Prototyping – Completing the Systems

The fourth post in a short series on quick and dirty board prototypes.

Quick jump to all posts in the series:

In my last post, I talked about creating a system for determining the order in which players would act.

Before I could run a test build, I needed to bring it all together so that players could cast spells, activate creatures, move their wizards and move their creatures. This post looks at some of the systems that still required some development.

Wizard power and casting spells

As a game progresses, I want players to get a feeling of progression and a feeling of increase in power as time goes on. I also want there to be some constraints and mechanisms that limit players getting too powerful too quickly, and an effective power ‘ceiling’ that pushes back on their power should they get near it. While it will take lots of play testing and balance to get these things nailed down, it would be easy to make a stab at a system and evolve it over time.

Wizard power and casting spells

I had to start somewhere, so I decided upon:

By default, players receive 2 ‘power’ tokens per turn
Spells would cost a variable amount of power tokens to cast, with the cost being based on the spell’s effectiveness
Wizards could store up power from turn to turn to allow the bigger spells to be cast
Power could also be spent on buying creature activity tokens for the activity track

I hadn’t decided upon:

Whether power could be spent to transition creatures from ‘tired’ to ‘rested’
Whether wizards should have a cap on how much power they could store (I suspected they should have a cap). In the end, indecision resulted in their being no power cap.

Spell flavours and schools

Going forward, I want to introduce a number of complexities to the world of spell casting; for example, I want environmental factors to influence a wizard’s power (so necromancers do better at night or when it’s cold outside, for example). However, for this first version that would be too much to try and fit in and get right. There would be ‘spell power’ and that’s all.

Resting creatures

In my previous post I mention the concept of creatures getting tired and having to be rested. I decided upon a simple mechanic where each wizard could ‘rest’ a single creature per turn. I thought I’d see how this worked in practice before worrying about it further; this is another example of only solving problems you know you actually have.

Summoning and creature activity

As a place to start, I decided to give wizards 2 ‘actions’ per activation. When it was a wizard’s turn to activate, they could do two things from the following list: they could move, cast a spell (including creature summoning spells), they could attack an adjacent enemy creature and they could ‘buy’ creature activity by spending power.

Concurrency vs thinking in isolation

One thing to note was that none of the design problems were solved in isolation. While I might focus for one lunch hour on pondering a particular problem, it would be in the context of everything else I’d considered recently. After many years of designing software systems, you get a certain confidence and ability to play around with ideas and get an intuitive feel for how they sit with previous decisions and other concepts. I guess another helpful factor is having played quite a few board games and loads of computer games. Your intuition gets trained in the background without you knowing!

Gaps – things not yet designed or decided upon

There were a bunch of minor game mechanics that I hadn’t come up with solutions for, but these were all ‘micro’ design problems and could be easily improvised. For example, I created a range ruler that had a short, medium and long range on it. I’d use this for spell casting and for moving creatures.

I was now ready for trying out a test build, which is the subject of my final blog post in this short series.