Board game design

An overview of the key principles and tools I used when designing board game mechanics.

Design a board game from scratch.

Designed the game concept, conducted play sessions, iterated on the game loop and mechanics, got in some very fierce game duels.

A board game, that was played all over college campus.

War Hands is a board CCG strategy game. It is a 1 vs 1 experience where players play against each other to capture and destroy the opponent’s enemy base. The game features troops management, capturing territories and powerful heroes leading the armies. The game has a potential to be played in different styles with each player creating his own deck.

The design process of this game featured several important principles and tools that, in my opinion, are essential for creating a great product. Each following passage I will dedicate to one of these core principles and will try to explain to the best of my abilities why these concepts worked for me and why I consider them so useful.

Disclaimer: These are my personal views and methods. I do not at all claim to be universally right.

When creating something from scratch it is always hard to understand where to start. When I was starting to work on War Hands, I had a 3 month deadline to present a fully playable board game. At that point I didn’t have anything except for a vague idea of an experience I wanted to end up with. In addition, the game I envisioned was not a casual one. I wanted a unique combination of various hardcore games with potential for deep strategy and multiple play styles. To achieve that I first of all needed a solid design strategy — a system that defined how I would approach and solve problems, a plan that would ensure constant progress and would keep me focused on the important things.

First of all, I have set up 1 week sprints with mandatory playtestings once a week. Obviously, as I was designing the game, I was playtesting it constantly on my own, but at least once a week I needed real people to play with me, preferably a mixture of new players and those, who already played the previous version of the game. This was meant to ensure progress and allow different feedback from people with different perspectives on the game.

Secondly, I broke the big task of designing the whole experience into smaller pieces, like gameplay, story, board design, card design and etc. I then prioritized those smaller tasks, sometimes breaking them into even smaller chunks of work, and took one design problem at a time. It was always tempting to jump from one aspect of the game to another, for example to start thinking about the theme or the board visual design while there were no solid gameplay in place. However, having a prioritized plan and strategy kept me effective — I would not discuss or develop anything, except for what was the number one on the priority list.

Also, it was important that I did not spend time or commit to any theme or visuals from start. My strategy was to stay rough for as long as possible. And this was vital for several reasons. Fist, theme and visuals shape the thought process. If I, for example, was portraying soldiers as humans, I might commit to a specific interpretation of war and thus limit myself to a particular kind of gameplay. On the contrary, if I thought of soldiers as just numbers, I could have ended up with them being action points, or talent points, or something else, opening a whole new world of design possibilities. And secondly, I didn’t want to spend time doing work that would most probably be thrown away later.

Last but not least, the important part of my design strategy was how I handled feedback from testers. I found it important to keep in mind that any feedback, while being exceptionally useful, was by no means a direct manual on how to do things. From the start I was rock-solid about the experience I wanted to achieve, but at the same time completely opened to the way this experience could have been achieved. I treated both good and bad feedback equally — as a subjective opinion, sometimes axing features that people said were good and sometimes leaving features people said were bad. For feedback is a reaction, not the truth.

The probability of me getting a good idea directly depends on how fast am I able to identify a bad idea. Or, if put differently, the more ideas I test, the higher probability of one of them being good. In other words — fail fast.

Failing fast was one of the key principles I incorporated in my design strategy, flying through dozens of ideas and concepts as fast as possible, ruthlessly cutting down anything that didn’t work, no matter how awesome an idea sounded. And just as a proof of concept, most of my seemingly great ideas didn’t work. And ideas that actually worked and made it into the final version of the game were, in most cases, the products of continious testings.

However, some ideas are broader, more conceptual and high-level than the others. And even though they are technically formed, testing them is not that simple. For example, I had an idea that a player could secretly pick territories to own without an opponent knowing. The idea sounded very cool to me as a concept, but was very hard to test fast. In this case, when it is hard or time consuming to prototype, such concepts could be tested through asking questions first. Questions like “How would we identify territories?” or “What will be the process of picking them?” will instantly reveal boring details which, although unpleasant to think through, will bring a designer back to earth and will show the flaws of the concept. And the sooner this will happen, the better.

For a pleasant and meaningful experience it is essential that all the vital information based on which a person needs to make a decision has to be gathered in one, easily accessible place. At each point in time design has to ensure that the task a user is working on is clear and well communicated and the user has all the necessary information to make a decision. Also, design has to help a user concentrate and, ideally, create the flow.

In War Hands, more often than not, fun comes from being able to identify and make a move that would grant you the most possible amount of benefit, whether it is personal gain or damage to opponent. In order for the player to be able to see and make that best possible move, I found that I needed to set a limit to the number of things a player needs to take into account, in other words limit the variety of choice. For example, in the beginning, to make the best move possible a player needed to consider 3 things: cards in hand, troops on the board and perks provided by the territories where those troops were standing. While it may sound simple, that turned out to be a disaster, bringing frustration to the players, who 90% of the time missed to even get close to an optimal move. That, in turn, ruined the motivation to play and broke the game pacing, as a turn that took 8 minutes to complete often resulted in disappointment. My response to that problem was narrowing down the number of things players had to concentrate on when making a descision: totally removing territory perks and decreasing the value of plain troop placement while increasing the value of troop placement in combination with cards. Now players had a clear primary focus on cards and secondary focus on the troops that were now closely tied to cards. These gameplay simplifications may sound like a boring nerfing of the gameplay variety, but in reality it proved totally opposite. These changes had a huge success since players now had a managable amount of information to focus their attention and brain power on, being able to analyze the current state of the game and plan for future.

Once or twice a month I performed consistency checks on everything I had in the game — rules, elements, game steps, stages and etc. During these checks I would go one step at a time through the gameplay, analyzing and asking myself: “Does this type of element behave like elements of a similar type?” or “Does this rule follow a general pattern of how the rules of similar nature work?”. It was hard to do and sometimes inconsistencies were not obvious until someone with a fresh eye helped and pointed them out. Nonetheless, inconsistencies ruin experiences like nothing else and being on a constant watch for them is extremely important.

As I’ve mentioned before, at one point in time, War Hands featured perks from both territories on the board and cards in hand. And among those perks were abilities, like “catapult”, “shield” and etc. Those abilities were self sufficient, meaning they did not require cards to be used. I created them as alternatives, if, for example, a player did not have or did not want to play his cards. That caused confusion among players with me receiving questions like: “So, what card should I play to use a catapult?”. And once I explained that these abilities did not require cards to play, what do you think people did? Exactly, they nodded and continued playing like those territory abilities did not exist, focusing solely on cards in their hands.

Territory abilities did not require using cards, however, since all other abilities came from cards, players naturally assumed those territory abilities, too, required a special card to activate. That was how they perceived the game world and rules. And when I introduced rules that did not fit the mental model they created, rules that were not consistent with what players had come to understand, they rejected those rules. Even though having abilities not tied to cards in the end was more beneficial, when properly calculated, it wasn’t consistent, did not feel right and in the end was rejected.

After several weeks of playtestings I removed all abilities from the board and put them directly on cards alongside other perks and bonuses. This was consistent and thus eliminated dozens of questions, enhanced the game intuitiveness and player satisfaction, also helping to ease an already extremely steep learning curve.

In the process of rapid prototyping I found myself constantly adding and removing rules, game elements, mechanics and etc. And each of those elements, more often than not, was connected to other elements of the experience. Often, to add a feature I needed to add several minor features along with it. Or, to add a rule, I sometimes needed to alter several rules. And sometimes, when I deleted a feature, those minor adjustments I did to implement it remained. And with time such remainders led to severe cluttering and a vast number of rudiment rules, which were dragged behind, adding a thick layer of useless information or meaningless requirements.

To avoid this, along with consistency checks, I tried to perform, as I call them, value checks. Same as during consistency checks, I would go one step at a time through the gameplay, dissecting the experience and asking myself: “Can I get rid of this step/action?” or “Why is this requirement here? Can I play without it?”. And if the answer was even 50% yes — I would delete that element or rule and adjust other elements, if needed.

Naturally I strive for elegance in my designs. And elegance, for me, is a value driven simplicity. So if an element adds complexity, but does not provide enough value to justify it, I try to delete it and rearrange the remaining elements to work without it. Through such value checks I removed a lot of elements, like territory tiers and costs, dice rolls, bonus cards and etc. Without these checks the game would have eventually exploded with meaningless rules, elements and regulations, ruining the experience.

The concept of clear choices can be called differently: meaningful choices, or valuable choices, or something else. All depends on where are you coming from and what are your project specifics. The important thing is — choices should feel good, provide an exciting, evident trade-off and, if possible, sprawl a battle within a player as to which path to take. Once a player starts evaluating his choices, he is immersed in the game.

For example, I wanted War Hands to have depth, wanted the game to incorporate various styles of play. And, logically, I planned to achieve that through giving players the abundance of ways to play. And that approach proved to work up to a certain point. There is a threshold, however, which, if crossed, takes away the fun out of a choice and turns it into an utterly frustrating experience. For example: a player has 2 cards. First one gives her 10 soldiers and 1 catapult hit with damage of 2 and the other card gives her 13 soldiers. This choice is still meaningful and from a strategy point of view can make a lot of difference. However, when players faced a choice similar to this, they felt boredom and frustration. As one of the tester explained: “I need to use too much brain computing power to figure out an advantage so tiny. I don’t care that much…” The choice was unclear, the benefits were hard to calculate and as a result the flow of the game was interrupted and immersion broke.

Finally, everything that I’ve described previously, heavily depended on continues testing. The rule is simple — the more you test your experience or product, the better it is. If I had a work-related genie that could grant me a wish, I would probably ask to always have a budget for testing. ( I would probably ask for something else in reality, but anyways :) )

Testing is the key to a great product. However, truly efficient testing, in my opinion, requires a certain behaviour from a designer. At least that is what I did during my testing sessions. First, I kept a genuinely open mind. Was welcoming people’s thoughts and opinions even if they were completely opposite to mine. Otherwise, I was risking to miss out on some important feedback or a good idea. Another thing I did, I avoided defending my ideas and opinions. I was testing to gain insights, not to prove my right. And, last but not least, I listened, asked questions and did not voice my opinion, unless I was asked to do so.

As I have said before, I consider ideas to be only as good as testing proves them to be. War Hands is shaped out of concepts and ideas that survived numerous daily testings, value and consistency checks and etc. Seeing the progress of what I’ve started and ended up with, I can say with confidence that there is no better tool to polish a product, than continuous testing.

War Hands system still has a lot of problems and a lot of room for improvement. And I still run playtests and gather feedback for the next iteration of the game. However, should I continue designing it based on the principles I’ve described above, I am 100% sure the game has great odds of becoming an outstanding experience and will grant hours of immersive and epic battles to the strategy game fans all around the globe.

Related posts:

It has been just over six months since we first opened our doors at the The Service Course here in Girona, Spain. Things are finally starting to settle into a comfortable pace and I finally have a…

While working with data scientists, I have realized that expert data scientists spend almost 80% of their time doing feature engineering because it’s a time-consuming and difficult process, yet…

This is a simple topic but something I wish I knew prior to some of my school projects. It would have made the styling process much easier… CSS is challenging but it’s something I want to be…