In the first two posts in this series, I have covered the types of solo mode and a lot of my thoughts on them. In this, the final part I’ll cover a bit more of how I go about putting these together and testing them.
Using the brief
By now I should have instilled the importance to my methods of writing a brief. We know what we are trying to achieve now’s the time to work out how. I’ll play the game 2-handed and with another person. During these plays I’ll write lots of notes on all the things we have already covered. With all that information I should be able to start to form my idea of how to make a solo game. I’ll look at our 3 types and work out what style to go for, much of this will be determined already, but it’s always good to look at the overlaps in our Venn diagram. For puzzles I’ll concentrate on variability or story telling, challenges is about the framework, and opponent how to recreate another player.
If you have a restriction on components now’s the time to make sure you can do it. No point in designing a system with custom dice if the publisher won’t pay for them. Always keep the publisher in the loop with component count, going one card over a print sheet, or a token over the current punchboard can be a very expensive choice. My default AI method is cards so I’ll think about what the cards need to do and what information I need on them. Look at what the games comes with anyway, re-using existing stuff can be very helpful, especially if it’s nice stuff to play with. When you’re ready, sketch up a draft and play it. A lot.
Playtesting
It’s a solo game so you have no excuse for not being able to test it. Just keep playing it and making changes as you need to. In the early stages it’s all about the experience, are you fulfilling the brief? Is it working? Are you winning or losing? Don’t worry too much about balance, just get something that does what you want it to.
As you play the game more you can start to refine and balance it. Recording data is essential for this. You need to know how you’re scoring well or exactly where the tides turn within a game. Start to work on balancing and difficulty but be warned: By now you will be good at the game!
I know my solo win rate on the sort of games I play is around 85% on normal settings, once I’ve playtested a solo game enough to think it’s in a good state, I’m probably winning 95% of the time. It is very easy to think at this stage that the game you have designed is too easy. It isn’t. You’ve just got good at. I played Chocolate Factory about 50 times in a 3 week period. I got good at it. I was winning every game. Then we shared the files, almost all the feedback came back that it was too hard.
Get other people to playtest your game. It’s a bit ironic but you can’t playtest solo games without other people. You need lots of new players to make sure it’s going to be great straight out of the box. I’ll often return my draft to the publisher or designer to do this and put pressure on them to get it tested as much as possible. Yes I’ll want general feedback but this mostly about balancing and difficulty.
Difficulty
Once you have difficulty set, look at how that can be varied, what can you do to make it easier and harder. There is merit in both fixed levels and some customisation. Nick Shaw does a great job of this, providing around 3 set levels, say easy, normal, and hard but also a number of small tweaks to tailor the experience. These all need testing but that’s something you can do as you have a baseline to work from. The wider playtesting should give you all you need to build normal, test yourself against normal then build an easier version and a harder version. Don’t be afraid to make hard really hard, perhaps verging on impossible, some people enjoy falling just short over winning easily. Be wary of making easy too easy, if a player plays on easy for their first game and finds it boring or satisfying they may never make the effort to play it again!
Conclusion
There is as much to learn and explore about solo design as there is about game design in general and I love it! There is a unique thrill when you design a solo mode and beats you for the first time in a close and exciting game. I always likened it to Doctor Frankenstein and his monster. In the same way not everyone is a solo gamer, not everyone can design a good solo experience. If you need help, ask, as with all things board games the community is very supportive. Sometimes designing solo play will feedback into your multiplayer game, this happened with the corner shops in Chocolate Factory. Solo gaming is a huge market now so it’s always worth having a look at solo play for your game, but it has to be good, if it isn’t don’t do it. Hopefully these blogs will help you make more good solo modes, or get me to do them for you! 🙂
In part 1 I introduced how I write a design brief for solo modes and provided a couple of quick examples of how that brief shaped the process. I also laid out the start of thinking about 3 types of solo mode. Remember: These are not distinct brackets but rough types that can easily overlap with one another. In this part we’ll look into those types in more detail, but first…
Co-op Games
I’m not keen on co-op games in general. I’m even less keen on them as a solo experience. This is my personal preference. I don’t like getting picked on by games themselves and I don’t like having to run multiple characters with a shared goal. Co-op games are already designed with a lot of solo principles in place. The player/s must beat something to win. They can also lose in certain situations. There are restrictions in place that make it harder for the player to win. Co-op games lend themselves to being played solo simply by 1 player taking on the game with 1 or more characters that would be used by separate players in a multiplayer game. Very little has to be done to make these work and if you like the challenge of co-op games then if its a good co-op game it’ll probably be a good solo game. These fall firmly into the challenge game type and provide us lots of useful information and tips to apply to competitive solo games.
Competitive games
These are the solo games I enjoy the most. That does not mean they need to have an artificial opponent to beat. A Feast for Odin would be considered by many to be a beat your score solo game. It is. However the simple and ingenious twist of using 2 sets of workers on alternating rounds makes it a challenge, as we have defined it. A Feast for Odin is an excellent solo game, Caverna on the other hand is only ok, the difference is the challenge of that alternating worker system, it takes a small element of an AI by having certain spaces blocked each round but it was you that went and blocked them! A lot of competitive games can make great solo games but some don’t. If they are poor 2 player games that just don’t work for some reason or are very spatial then an AI style solo mode will be very hard work, not just for the design team but also for the player. The movement rules in my Concordia solo mode are the biggest barrier and the hardest thing to work out for the player. Spatial awareness requires intelligence and assessing a particular situation. Without an enormous flow chart system for decision making this is hard to replicate and only so many solo gamers are prepared to invest in that effort to run an AI. Don’t write off solo modes because they don’t have an AI system, there are some really smart designs that use puzzles and challenges to great effect. By writing a brief for how a competitive game can be experienced by 1 player we can find new ways to make a solo mode.
Puzzles : A solo gameplay experience that has a single solution, you either win or lose
A lot of story based games are predominantly puzzles, Gloomhaven for example. I only play the solo scenarios solo, as explained above, and there aren’t many different ways to win those, they are very much puzzles to solve and once they are solved you move on. So to make a puzzle based solo mode you need one of 2 things; a lot of different puzzles or a modular puzzle with variable elements. Gloomhaven is the former, Mage Knight is the latter. Both have their own strengths and merits. A variable puzzle framework often needs an element of randomness, but that randomness will need to be very carefully tested. Chocolate Factory has this with the combinations of weekly targets and daily demands. Every iteration of that design I tested 12 times, twice with each weekly target, using all of the daily demands with each target. That’s not every combination but it was enough to make sure nothing was too hard or too easy (mainly too hard, it’s a tough game anyways!). Puzzles are win/loss, you solve it or you don’t. A sense of threat about losing is important, time is a great element to add here as a restriction, you can also use an outside force, which has elements of an opponent or twists and turns during the game taking things from challenges. A puzzle type game gives a solo player a great experience and is perfect for story telling over a period of time with either ever changing puzzles or a huge number of fixed puzzles joined together.
Challenge : A set of restrictions or a framework that sets a target for the player. These have a sliding scale of success
The infamous beat your score systems fall within this category but there’s so much more you can do here. By taking elements from the other types, a challenge solo mode can be as rewarding as any other. There’s a lot here that can also be included in the other two types. Ultimately giving the player something to beat is a key linchpin of solo design. Story elements can again be used to give the challenges progression and randomness can be used to make them variable. The key for me here is only giving the players a framework to play within and giving them a much bigger scope for how to do it than if it were a puzzle. Mage Knight does this through the character progression and deck building. A Feast for Odin through the worker placement system. Gaia Project through all the different races. A challenge framework should be thematic. Challenges are not win/loss like puzzles. There might be scores involved, with ranks applied to certain scores or perhaps there’s consequences for how well you did. Find ways to inject the threat of loss by controlling outside elements that affect the player during the game. Obviously anything passing from game to game needs tying into legacy or story telling within a game but there is so much design space to explore here, it is very much more than beat your score.
Opponents : An artificial opponent that replicated a human player, or an outside force that the player competes against
This is perhaps the best known type of solo mode and it has exploded in recent years. David Turzci and Morten Monrad Pedersen are the most known in this category but it is no coincidence that Nick Shaw works alongside both and is perhaps the hidden wizard behind the curtain in many of their designs. I’ve been very lucky to start working with David and Nick recently on a few projects and I’m continuing to learn a lot from them. I am sure David has a number of blogs you can read on the subject. Much of this section I have learnt from the aforementioned gentlemen.
An opponent type solo game sets out to do something very simple in concept; give you an artificial opponent to play against. This should be like playing against another person. Designing that opponent is a lot harder than you might think. It needs to be competitive and easy to run. These two aims will often oppose one another. Go back to your design brief and your theme, remember these are the biggest things you have to help you make decisions. Here are a few keys points I use:
Interaction – Where do players interact and how can this be replicated? This depends very much on the game itself. Play it 2 players and write good notes of the interaction points. Getting these right is the key to success.
What can be ignored – To cut down on admin the opponent should ignore anything fiddly, make it as simple as possible. In Eternal Palace for example the AI never gets or spends any resources, this cuts down loads of moving components and makes the decision tree much easier.
Randomness vs cheating – This is a key balance. To replicate another player the AI needs to do stuff you don’t expect. This requires randomness. You could just roll a dice. I’ve already mentioned I don’t like dice driven AIs. If it fits within the game and can be used really smartly, I’m all for this (David and Nick do this particularly well). I prefer a card draw based AI as it enables a balance to the randomness. But if a player just acted randomly all the time they’d lose, as we are dealing with games that require some strategy here. So the bot needs to cheat to make up for acting randomly. This can be seen in my Concordia variant where Automus earns maximum money, regardless of when he draws his Senator card.
A player shouldn’t make decisions for the AI but can influence them – Golden rule that works in the majority of cases. This ties into the interaction. If a player has too much control it’s akin to playing the game yourself which is not what we are after. A push/pull here can be a really interesting thing to explore, if I do that then the bot gets that, which is more important to me? Villagers has you drafting cards for the Countess but there’s enough other stuff going on to make that work. This goes hand in hand with making it simple. We will often create a decision tree, this can be complex like trading in Concordia or simple like the 3 tier cards you’ll see in Scrumpy. Basically it boils down to; can it do this? Yes – do that, no – do something else. Balancing and polishing these systems can take some time but it will be the core of any system.
Do players get better? If so, how does the opponent get better? This is my favourite thing to explore. How does a bot improve as the game goes on? I used Concordia as inspiration for Scrumpy as each time the AI deck cycles a new advanced card is added, over the course of the game the combination of these advanced cards sees the bot player evolve to have a particular strategy.
Can the opponent have a strategy – I’ve just spoken about strategy that evolves during a game but this is an element of artificial strategy and is something I handled differently in Reavers of Midgard where it is defined from the very beginning of the game, by going against one of three distinct bot players. I’d love to build an AI system for Lords of Waterdeep one day where each lord plays differently. Not got round to that yet. You’ll need a good grasp of the game to work this one out. My playtesting methods, from another blog, may well help.
More than one AI – Some games don’t play well at 2 players so you might already need some sort of opponent in a 2-player game, that means for solo you’ll need to add a second AI as well! This is a toughie as many players will resist running 2 AIs or using dummy players in a 2 player game. It may be that the game is just not suited to low player counts. It can be done however, in a recent development project I had a game with a dummy player mechanism at 2 players and a full AI. I rebalanced the game so that it appeared these two forces were working together and streamlined some of the admin. Simple changes, but with a good thematic tie in it reduces the barrier for players. Concordia Venus was a different beast as I had to adapt the Automus AI to act as a second AI as part of a team. Even David Turczi reckons a bot as a teammate to a player won’t work but building a subtly different version of Automus to act as his teammate was a good challenge.
This is the first of a series of three blog posts by David Digby, about designing board game solo modes. We will release parts 2 and 3 over the next week or so.
Let me be clear, I am not setting myself up to be any sort of expert, but I have been very lucky to work with a number of well established designers and developers and feel like I have my own spin to impart on the topic. To date I have 1 published solo design; Chocolate Factory, 2 signed up solo designs coming to Kickstarter later this year in Scrumpy: Card Cider and Eternal Palace, and 2 fan-made designs on BGG for Concordia and Reavers of Midgard. There’s a few more in the pipeline that I hope you’ll hear about in time. I have also been a playtester and developer on a few other solo designs including for industry leaders David Turczi and Nick Shaw.
Types of solo mode
I break solo modes down into 3 main types. These are not hard lines, more like categories in a Venn diagram with some overlaps between them but hopefully I’ll explain my thinking well enough to tell you why I do this. My types are puzzles, challenges, and opponents. I’ll go into more detail later but here are my definitions:
Puzzle: A solo gameplay experience that has a single solution, you either win or lose.
Challenge: A set of restrictions or a framework that sets a target for the player. These have a sliding scale of success.
Opponents: An artificial opponent that replicates a human player, or an outside force that the player competes against.
You’ll notice I’ve not used common terms like automa or bot or beat your score. Why I have done that should also become clear during these posts.
What sort of solo experience do you want?
This will be one of my opening questions when talking to a designer or publisher about their game. It is also perhaps the most critical, which is why I start here. There are as many answers as there are games but here’s a few paraphrased answers that should make it clear.
“A solo mode where a single player can feel challenged with variable difficulty and replayability. It should also allow the game to be played cooperatively”
“Accurately replicate a two player game, with a smooth, easy to use AI”
“Create an opponent for any player count that can act as a player would, using only the original game components”
“An AI system which can play the game with various strategies”
“An interesting and variable play mode where one player tries to hit certain goals”
“Two artificial forces that replicate the player interaction in a multiplayer game but allow players freedom to play their own game”
Hopefully from those you can see how many options there are. It’s not just a simple matter of building a bot that does exactly what a player does or a beat your score mode. That’s why I steer away from those terms. Really focus on what sort of solo experience you want players to have, it is as important a question for solo as it is for the whole game in general, if not more so as the game is 100% of what the player interacts with. How often has a game been more enjoyable because of the people you played with? Taking that away means you have to work doubly hard to create the right experience.
Next questions
With an experience in mind we need to ask a few more details to be able to write a design brief. I write a brief for everything I work on, and keep going back to it as I work. This brief and the theme of the game should help answer any questions you have and will really shape the design and development process. There are no right or wrong answers and there’s a bit of variance in these but you should get the jist.
How do players interact within the game?
What are the strengths and weaknesses of a 2 player game?
Which gameplay elements are essential and which can be removed?
How do players win or lose or score?
How important is variable difficulty?
How long should it last?
Will any elements of the solo game be used in multiplayer?
Where should player’s decisions be made?
What restrictions do we need to put in place?
Will it be used by players to learn either the rules or strategies of the game?
What factors may limit components used for solo only?
With all this information in place you should be able to write an accurate design brief. You should also now be able to identify where the solo mode falls within the types we mentioned earlier. Let’s take a look at 2 examples.
Concordia
I love Concordia, it’s an absolute classic, with a superbly smooth gameplay system in the cards. Venus added team play but what was missing was a solo mode. I found one on BGG which was dice based. I am not a fan of completely random dice based solo modes anyway, they have always felt a bit lazy and too random. So I went back to what makes Concordia great, the cards. Surely I could write rules that used the normal cards to form an AI deck? This is an out and out opponent type solo game, your only aim to beat your opponent. The opponent is a replicated player. The design challenge here is building a system that’s easy to use and competitive. As a solo player you don’t want so much admin to do that it feels like you’re playing the game 2-handed. Equally if it’s too simple it will be easy to beat. This balance of ease of use and difficulty is where the art of building an AI comes in and we’ll discuss that later. Lots of testing later, with some help from Dan Regewitz, I’d come up with a set of rules that allowed you to play all versions of the game with one or even 2 AI players.
Chocolate Factory
The main gameplay of Chocolate Factory can be described as multiplayer solitaire. So making a solo mode is going to be easy right? Don’t you just play the game on your own? There are large numbers of solo players who will revolt at the prospect of a beat your score solo mode, and yet there are still lots of them, some of them are very good. For those of you who don’t know the game the points of interaction come from drafting factory tiles and employee cards, and competitive scoring. Matt Dunstan and Brett Gilbert had designed a solo mode that came to me for testing. This involved goals that the solo player had to complete to win the game, a challenge style solo mode. Perfect fit for the game but what I changed was how that was run. What I felt it needed was a sense of an outside force, not an artificial opponent but just something to give it an edge.
We came up with a weekly target and daily demand set up that was designed to put the player in the role of the factory manager who had the owner or sales team telling them what to make in their factory. This creates a puzzle for the player to solve as there is only one right answer, do everything on the cards to win the game, how they go about that is up to them however. By removing some upgrades each round, and the way demands are revealed each day we took a puzzle and made it more into a challenge as the player needed to react and adapt. We combined elements from all 3 of our solo game types to create a quite unique mode that is hopefully enjoyed by a range of solo players.
When I retired from playing club cricket at the end of the 2017 season I made the decision to expand my involvement in my other hobby, board games. I started volunteering for playtesting and it turned out I was reasonably good at it. A few months later I managed to tie some mechanical ideas into a prototype design, it all came together by finding a theme that worked. That game was The Seven Dwarves, which I used as an example in my previous blog about playtesting.
As I became more and more involved in testing and designing I made two significant friendships and working relationships. FIrstly with Caezar Al-Jassar who is the boss at Alley Cat Games and secondly with Paul Grogan from Gaming Rules!. Through working with those two companies my voluntary work has evolved into paid work, I guess that makes me a professional? Working on my own games, or for Alley Cat or Gaming Rules, or helping out other people was a great way to fill a few extra hours a week.
At the end of March, life changed. My full time profession is as Technical Manager for Chelmsford Theatres. On the 23rd March we closed our doors to staff and public, suddenly I had a lot more time on my hands!
Throwing myself into board game work
I’m a workaholic. There are various reasons for this, but this isn’t the place to go over them. Between my proper job, board game design, development, and rulebook work, and running cricket coaching I work 70-90 hours a week. The sudden stop in my full time job (average 40 hours a week plus 7 hours a week commuting) and cricket coaching left me with only board games to do, all day, every day.
At the time that this happened I was already working on 2 solo mode designs (Eternal Palace for ACG and Scrumpy for Paul Frohnsdorff-Harris), developing the Rome and Roll expansion with David Turczi and Nick Shaw, editing or proofreading a handful of rulebooks for GR, and working on a couple of designs of my own. Already sounds like a lot right? Well it wasn’t enough.
Tabletop Simulator
Those that know me know I’m not that smart with computers, and yet one of my first challenges was to take on learning Tabletop Simulator (TTS). With some help, online how to guides, and plenty of swearing I managed to learn how to get my designs uploaded. I started with Space Council, it’s a card drafting game with a central board so it was pretty simple to do. Then I moved onto Magical Deep Sea Octopuses vs Toxic Ocean Plastic; this brought the challenge of polyomino tiles, I got there in the end. The Seven Dwarves is on the back burner and I don’t have updated files for Theatre Land yet so it was time to move onto new designs. Rock Band, as a real time game, is not best suited to online platforms so I shelved that for the time being. Focus shifted to the mysteriously titled Project S.
Project S is a reimplementation of Curse of the 7th Fairy, a tile laying game, but done as a sequel to an existing game, hence shrouding it in a bit of mystery. It’s a great design exercise to try and make a sequel to something, which I strongly recommend trying.
Turns out TTS is an excellent tool for prototyping, you can make changes quite quickly and easily without having to print stuff and make components. Although I am still reliant on my very basic computer skills, I’ve been able to try loads of changes and working alongside David Ellis (who is my co-designer on Project S) it feels like we are making some real progress with this design.
I also came up with a new design, Dreamcatchers, which I hope will do for bag building what Octopuses did for rondels. This game 100% exists on TTS, the first of perhaps a brave new world of online only prototypes.
Playtesting
Designing new games of my own is great, but to this date I have not signed one with a publisher. Perhaps the work I am better at, and becoming more known for, is testing and developing for other people. I’ve done some more work on Rome and Roll, putting the finishing touches to that, but that’s all been solo and in physical form, so no real change from the norm.
A whole new community of online playtesting seemed to spring up overnight. Designers I knew already or people I hadn’t met were keen to test games or get their games tested. ‘Meeting’ people online to test games was a great relief, to focus the mind and actually talk to real people when we were in full lockdown. When other designers are keen to playtest games, take advantage of it! The quality of testing on TTS has been excellent, makes a massive difference to developing a game, with a few hours I was getting more useful feedback than a whole cons worth of demoing.
I’ve also been able to test for some other designers, trying out Daniele Tascini’s latest design with the man himself was not only an honour but also a great learning experience. Of all the things that have changed I hope this is a permanent one, as it changes the way we design and test for the better.
The Unicorn Collective
I’d met Chris Winterburn at Essen. Chris runs Clever Unicorn Games, a small publisher based on the Isle of Man and The Unicorn Collective, a facebook group about games. Somehow I agreed to do a series of playtests with him and another designer, Patrick Wall. The test would be recorded and published for others to watch and learn from. I had to nominate Octopuses, which as a finished design didn’t make much of video.
What we had created however was way more interesting and we thought would be a really good idea to run with. Ian Brocklebank joined the panel and we opened it up to all designers to bring us games to test, record and broadcast.
All the games I’ve played have been pretty light and have ranged from ok to terrible (my personal opinion). I think the videos themselves have been really interesting and provide a great resource to learn from. A few big takeaways for me; there will always be people who just use something like this for publicity, the Kickstarter culture is leading to a lot of self-published, visually pretty, rubbish games to be made, a lot of designers do not listen to advice, I get really grumpy playing crap games.
Chris has also launched an interview series and these have been really interesting to watch. Recording my own was a really difficult thing to do, but I got through it and I guess if people have watched it or have read my blogs there might be some merit in what I bang on about. Do check out all the content; lots to learn from I hope.
Alley Cat Games
My work with ACG has been steadily increasing for the last 18 months, from just helping out at cons and doing some testing, I’m now very proud to be a member of the development team. I’ve been working on Eternal Palace for a while, testing the game in general as well as designing the solo mode. I’ve also started testing Dice Theme Park, an exciting new design from Daryl Andrews, Adrian Adamescu, and Mike Nudd. We have also started a very exciting project, which I can’t go into any details about!
One fascinating part of helping out has been sitting in on pitches to ACG from other designers. It’s a great insight into what publishers want and how pitches come across. Advice for designers from this: focus on what makes your game special, be open to advice and criticism, know your publisher, don’t bullshit. It’s great to get to work with such a good team and sit on both sides of the pitching table, maybe it’ll give me an edge when I next pitch.
Downsides
Few things in life come without downsides. Pushing yourself to work harder and harder takes its toll. I got to a point that I had offered to do so much work I couldn’t cope, I felt like I was failing. Luckily I was able to reset. I made time to exercise every day. I organised my diary to the nth degree to make sure things were getting done when they needed to. I blocked out times to not be working on the computer. I bought a new chair so I can work in the garden. I made sure I spoke to people every day, either over a game or just on the phone. These corrective steps have led me to an incredible period of productivity.
What I’ve achieved
I’ve done some good work on rulebook editing. I’ve made some new contacts and made some new friends. I’ve agreed my first professional contract as a developer. I’ve been offered work on some really exciting projects in the future. I’ve found new ways to work and made the most of them.
Perhaps most importantly I’ve reset my outlook, I’ve got my self-belief back and am motivated and excited to see what’s next. Who knows how long this will go on for and how much I continue to get involved with, but it’s really exciting.
I may only be playing at being a board game professional but its a good game once you get your head around how to play!
You’ll hear the advice everywhere, “playtest your game as much as possible” but what does that actually involve? There’s pretty standard advice out there, “don’t just play with your friends”, “get as many people to test your game as possible”, “playtest with the sort of people who’ll play the game”, “ask the right questions”. All of this advice focuses around playtesting with other people. In my work as a designer, playtester, and developer I spend a lot of time playing games I’m working on, on my own. Yes some of that is solo, but only so much, the rest I’m playing the game as multiple players. I’m lucky to have some close friends who live nearby who are happy to playtest games, but I can’t take over every game night with prototypes and I have no regular access to playtesting specific groups. One friend in particular, David Ellis, is incredibly good for testing games with, and we have a great working relationship, which is pretty much co-design on some projects, but a lot of the testing falls on just me. So how do I do that? How do I make the most of that time? What about that method has helped me develop my own skills? You’re about to find out!
This is not the perfect solution
The methods I will go on to detail will not work with every game. Some games lend themselves to this method of testing better than others. Some mechanisms are impossible to replicate on your own, some require a lot of roleplaying (which I will go on to explain). If you’re reading this you can probably think of what games won’t work, social deduction, hidden roles, real time etc. However it does work for a lot of games you might not think it does. My personal tastes are for medium to heavy euro style games, that’s not all encompassing but it’ll do. These are also the games I’m often asked to work on. That’s about me knowing where my strengths are and getting to know the right people. Anyways, if you think your game design might benefit from this style of testing let’s get on with the how.
Examples
It’s not appropriate for me to quote from projects I’ve been involved in but at times I feel the need to provide examples. I’m going to use one of my own games; The Seven Dwarves, in these examples. It was my first design, and for a number of reasons I don’t think it’ll ever be published. It therefore will serve us well for an example piece of work. It’s a dice placement euro game for 1-7 players, core is Kingsburg like, for those of you familiar with that.
Initial stages – Just play it
Play the game. I’ll often start at 2 players and just play the game a few times to learn it, see what it’s about and get a feel for it. There’s no right number here, sometimes 1 play will be enough sometimes it’ll take a few and at different player counts. The aim to get a good overall understanding of what the game is about, how it plays, and more importantly how to win. If you have the option to play with other folks at this stage do so, but only if the game is playable. If it’s an early prototype don’t inflict it on others yet, but sometimes other people may spot things you didn’t notice. Across these plays just jot down some ‘big picture’ notes, if you think anything like me you’ll need to actively ignore going into too much detail.
So in The Seven Dwarves, I would have notes like this:
7 different player powers, 7 different powers ups, so 49 combinations
1 way to score points but in 3 different types, some in-game, some end-game
Track mechanism that provides upgrades, player order, and end game trigger
Some variable set-up
Dice placement, but there is some mitigation, no dice are ever wasted
7 resource types of varying values
Build the players
The next stage is outlining the strategies you want to test and how you are going to assign them to your dummy players. There are many different ways of doing this and it depends much on the design itself.
In The Seven Dwarves there are player powers, and upgrades so all 49 combinations of those needed testing. Each player has a colour and each upgrade gets a number. From these we get RED 1-7 etc. This list produces 49 players we need to test, the number of tests you need depends on player count in each game.
There are also 3 different types of cards we will be building to score points, so there is another 7 players.
7?! Yes seven. Here is a key part of the process. In our example there are 3 types of cards we will score points from, so that gives us 3 strategies, I call these the “extremes”. The players will do all they possibly can to solely focus on one of those card types. Then there are 3 “50/50” strategies where the player now has 2 things to choose from. Finally an “all balanced” strategy where all the card types are considered equal.
So we now have our players, all 343 of them! Your game may be a lot simpler, it might not have player powers, or ways to upgrade or engine build, there may only be 1 way to score points. Or it may be more complex and less easy to work out. If it’s simpler, great! If it’s more complex we may need to figure out another way to outline our players and that’s why you need to play the game enough first. Write a list of strategies, it doesn’t have to be all-encompassing, but write a decent list of what players might have as a strategy in your game. Think outside the box too. We all have that one gaming friend who manages to come up with something really whacky, emulate or talk to them. One of my known traits when learning games is to ignore something, I’m going to digress briefly on that.
Ignore one thing
Here’s how I’ll often play games for the first time, outside of design work. I’ll listen to the teach, or read the rulebook, or watch a playthrough and pick out one element of the game to ignore. Because of my personal preference this will often be combat, or bidding, but could be a certain worker spot or action, or a mini-game, or a phase. I will then play the game ignoring that thing as much as possible. Sometimes it quickly becomes apparent that I picked the wrong thing and I have to buckle and do it. This is not failure, I have identified that that thing is essential to gameplay, this discovery is really important. A lot of the time it will provide a huge insight into how that thing and all other things play out within a game. Sometimes it will make no difference whatsoever, that is a huge red flag for me. If it made no difference at all to the game experience why on earth is it there at all?!
The Seven Dwarves features a track that represents each Dwarf jostling to try and be Snow White’s favourite. It’s a great example of ignoring something. If ignored it, I’d never get the upgraded player powers, or get an extra dice, or score bonus points at the end of the game. On the flip side I would always be first player and would have 1 less resource to worry about so can focus more of my attention elsewhere. By playing the game ignoring this track I can clearly see how important it is from almost every angle. I find this a lot of fun and very insightful.
WARNING: If you are going to do this in a playtest someone else is running tell them first! It will often look like you are trying to break their game intentionally and that is not well received. Until people understand what you are doing, be polite so they don’t go onto the back foot.
Play the “extremes”
We should now have a list of strategies we categorise as the “extremes”. Ideally these would be within your player count. So if you have a 4 player game with 3 extreme strategies, we are good to go. As soon as the number of “extremes” exceeds your player count you are in for a much longer process. I’ll leave you to work that out, but it should be easy enough.
Play a game in which all the “extremes” play against one another. Here’s a top tip for doing this. Post-it notes. Write the strategy on a post-it note and put that in that player’s area. It may be that players have boards, or hands, or resources, or whatever, put the note with them. It will remind you how that player wants to play the game.
We identified our extremes as the 3 card types which are; armour, weapons, and jewellery. So we need a 3 player game where each player follows one of those extreme strategies, simple.
Record the results and look at the trends. Don’t forget to write about player experience as well as the scores. It is as important to find out if a player is having more fun than the others as well as if they are winning. Even more important, look at how the two relate to one another. What you do with this information, how you look at it, and what you go on to change or work on depends on your design brief.
What do I want my game to be?
I always write myself a design brief for my designs. When working for someone else I get them to tell me what they want. Does the game need to be perfectly balanced? Should player powers be exciting and varied? Should an all balanced strategy be better, worse, or equal to an extreme one? How much strategy do you want players to have? How adaptable can strategies be? How much tactics is there as well as or instead of strategy? Do I want the best player to win? How much scoring is open? How much scoring happens during the game and how much after? What should a winning score be? How much of a final score should each thing be? I could go on and on about this but you need this information in advance to know what you are testing for and why.
Play the “50/50s”
We have looked at the “extremes”, analysed the relationship between them, and probably made some changes to the game. Now we move onto the “50/50s”. This could not be any easier. Remember those post-it notes you put in a player area? Move them half a place around the table so each one sits between 2 players, simple. Now play some games where each player balances 2 extreme strategies, perhaps here you’ll need to add some other type of note to help make decisions, maybe one player wants in-game points and another end game points, for example. This will start to expand your testing into more varied strategies. This phase will take longer as there is more variance. Study these results (don’t forget player experience is of equal if not higher value than the raw data) both against themselves and the extreme tests. Go back to your brief and work out what you want to do with these results. Don’t forget that small changes can have huge knock-ons. “The player with the most cows always wins so lets just make cows worth less VP”. “Oh crap, now no-one wants to buy cows and the supply chain has broken down completely”. If in doubt go back to your brief and your theme. These will inform your decision making.
Play the “all balanced”
If possible add this player into your “extremes” playtest as an additional player, once you feel you’ve ironed out a lot of the wrinkles. This is the best test for this. Now more than ever you need to have a clear idea in mind of what you are trying to achieve in terms of balance. I repeat; player experience is as important, if not more so, than the numbers.
I wanted balance in The Seven Dwarves. You can imagine the time I spent trying all 49 player setups and that’s something specific to this game as it had the 7 player powers and 7 player upgrades. The strategy testing was as important. Specialising in only 1 card type is suboptimal as you end up with too much waste, perfectly balanced is also suboptimal as you’ll be chasing too much. So here’s the key point for me in this design, not everything is balanced but there is no right or wrong answer. Tactics (the decisions you make during the game) outway any strategy, the player who plays the best will win most of the time. However a real strength is that players have a lot of fun having done one thing better than the other, “you may have won but I got way more jewellery than you and that’s cool!”. In this way the game filled the brief perfectly.
The hard work
Be prepared to play the game a lot!
Remember we identified 343 players that needed testing, and yes I tested them all!
Record every playtest and always apply your brief to the results. Make changes when you need to and want to and keep testing. Sometimes you’ll need to go back and test using a player group again, sometimes you can move on and not worry about it.
When you are ready or able to playtest with other people let them play however they want to. You’ve tried every option you can think of already, so give them freedom to do what they want. This testing method should get your game into a really polished state, playing with other real people will get you all sorts of other information.
Yes I spend a lot of time playing games like this but it appears to be working and unsurprisingly has led into designing and developing solo modes for games, which I will cover in the next blog.
Thanks for taking the time to read this and I hope it’s helped in some way. Check out all I’m doing board game wise at www.facebook.com/DavidDigbyBoardGames