Part 3
A board game design process: Defining the game and its scope
We have the information, insights and lots of possible leads into the design of the game. Now it’s time to decide what is actually the game we are going to make. This is about laying the foundations. While we don’t want to constantly go back and forth on design decisions we still want room to explore and this is a difficult task to balance. A solid understanding of the path and a clear goal is paramount for a clear and tight process and helps us create a coherent game.
From what I’ve seen, this is something a lot of designers struggle with. A lot of people, especially beginners, jump straight to the design phase missing this foundational part of the process. Without this, people tend to stumble around, doing and undoing whole segments of their work. Because of its importance this is going to be a bit of a long article.
To start with, we need to understand what kind of game we want to make, for whom and how.
To make it clearer, in this stage we have to define:
- The purpose of the game
- The player
- Our design principles
- Scope of the game
- Our constraints
This is going to provide the basis we need to define the frame of our design. This is not a linear process. We can start from any point (I’d still recommend starting by the purpose) and then move on to others. We might have to revisit the early ones after defining all of them as they’re all related to each other and a change in one might affect the ideas behind another.
The purpose of the game
The purpose might be to sell thousands of copies (mass market appeal) or to educate players in a specific subject or just to have fun with the process, to name a few. In my case it was an experiment to explore design methodologies and see the overlap with product design. My main objective was learning about game design (and design in general). This is important because I can filter game design decisions by sticking to the purpose.
The purpose of the game should actually be stated at the beginning of the project and revised at this stage. This is because understanding what we want to do with the game is going to drive the research and analysis phases of the process. I briefly mentioned in the first article that my design was first and foremost to learn about the game design process. This is still true at this stage.
Design Principles
These are our guidelines. They will shape how we approach the design of the game and help us make design decisions by narrowing the scope of the game. This is the first set of constraints that we self-impose. This is a common part of the design process that might be informed by our previous research or by personal preferences. This design “rules” are statements of intent and have to define a clear strategy. In order to achieve that, a principle has to be clear, actionable and non-obvious. For example, an obvious principle would be “Has to be enjoyable”.
Since my focus was on learning about the design process I focused on simplicity and openness instead of trying to make a huge game with lots and lots of components and rules. These principles reflect part of that approach.
The player
Players come in all sizes and shapes. More often than not they’re defined by their age but this is not enough. Age might give us an approximation of the cognitive capabilities but it doesn’t tell us much about their interests, habits and motivations. What we need to understand is how gaming fits in their lives, what they know about it and what things they feel are important. Sometimes the audience will be defined beforehand by a publisher or market opportunity, other times we will be able to determine who we want to reach. In any case, who we are designing for will be the source of a lot of design constraints and information. If the audience is a requirement and not a decision then we should set the design principles with them in mind.
Scope of the game and other constraints
Understanding the limits we’re going to operate in is important. Starting a design will imply limitations, requirements or constraints of any form. While the design space could be limitless, the realities of the world pushes us in certain directions. The most common set of limits we’re going to find is those of production and costs. A designer might come up with a great ten thousand cards behemoth of a game, now the cost of that game will be quite restrictive and won’t be very profitable. So, components present lots of limits, amount of cards, miniatures, size of the board and that kind of stuff. That’s related to other types of constraints like shipping (game size) and feasibility (being able to actually manufacture the thing).
Another set of constraints we’re going to find is on the mechanics side of the game. Complexity and the cognitive capacity of the players is a big one. Players are squishy human thingies and often have a limited mental capacity. Throwing dozens of mental calculations and forcing them to remember lots and lots of conditions from one turn to the other probably goes against the Geneva convention.
Every decision we’ve made in this section, from the design principles, to the understanding the player, is about the construction of useful constraints for our design.
I want to make a pretty important distinction. We’re going to have two types of limits: requirements and constraints.
Requirements are hard limits, usually externally imposed either by manufacturing capabilities or by a publisher. These are limits we are bound to or have to be contested in order to be changed (usually with long and arduous arguments).
Constraints are the fun, soft limits. As designers we self-impose some limits in our designs in order to be able to focus on certain aspects of the game, as a challenge or to actually enhance creativity.
Constraints limit the exploration space, while this might seem a bad thing it’s actually a pretty important part of the design process as having unlimited options is daunting and blocks creative progress. If you can do anything you want is pretty hard to choose where to begin and where to go next with your design.
The nice thing about constraints is that they’re soft limits, we can create and discard them whenever we find them to be convenient. Let’s say for example that I want to design a card game (constraint nº1), then as a personal challenge I decide to make a game that consists of only 20 cards (constraint nº2). I set out to work and come up with a pretty good game but there’s something I can’t quite solve until I realize that I could use a dice to enhance the interactions. It goes against the two constraints I set out to use, however the dice takes the game from pretty good to amazingly great. Changing the constraints of the game to allow this one dice is actually a no brainer. It’s not that the initial two constraints were wrong, they were there to take me from zero to the point I realized I needed a dice. They’re an integral part of the process.
In my own game I didn’t have any hard requirements (besides those of physics) but I did have many starting constraints in the form of the principles and the kind of experience I wanted to create.
One of my soft constraints was that I wanted, for thematic reasons, to have a board, similar to the tactical planning tables in many military fantasy works.
I knew that it was important for the feeling of the game to have that tactile experience and overview and that’s probably the only thing that remained almost “as is” from the original design.
One of my hard constraints was that I was working on the project alone and my graphic design skills are limited (and not to mention my absolute lack of artistic skills) so I had to find workarounds for that. More on that on future articles.
Defining the game
Like in any creative endeavour a designer probably has lots and lots of ideas for the game at this point, the importance of defining the concept behind the game is that it can help focus and filter ideas into a cohesive whole and provide a strong starting point for the process of designing the concept, mechanics, components and thematic elements of the game.
The end result of all of this work should be a list of constraints and design decisions that we can then reference during the whole design phase of the process.
Entries in the series:
· Part 2: Synthesizing information
· Part 3: Defining the game and its scope (You are here)
