Part 4
A board game design process: A game is a system
Finally! It’s time to get our hands dirty with some good ol’ conceptualizing. We have passed the planning chasm and now we’ve landed in execution land.
What we’re going to do now is to take all the knowledge, information and ideas that have come up during the planning phase and start to put it together in the shape of a game that other people can experience.
The fundamentals of Board game design
Board games are built upon three core elements: Mechanics, Theme and Components.
Mechanics are the rules and interactions, the inner workings of the game as a system. Theme is how the game is understood, felt and perceived mostly through aesthetics and storytelling, it’s what creates an emotional connection with the player. All of this is manifested through the components, the physical manifestation of the game, cards, dice, boards and everything that comes in the box (and including the box too!).
Designing a board game involves designing these three aspects and their interactions with the players.
Board game design is all about creating interesting choices for the players.
This a fundamental principle in game design. If there’s just one optimal way of playing or if the player is drowned in little bookkeeping activities then the game is going to be absolutely boring. Choices, actions, during the game have to be meaningful.
There are many ways to approach a game design and each designer will have their own philosophy. Personally I like to work with simple rules, a tight core experience but then allow players to bend or even break the rules in different ways.
Actions the player can take vary from game to game but the most common ones are about resource management, positioning, risk mitigation, diplomacy/negotiation, procureing, control and combat.
Conceptualization
At the beginning of the conceptualization phase what we want to do is to take all the thematic elements we’ve identified previously and translate them to mechanics.
The idea is to work through abstraction, we can’t do a 1:1 simulation, not only because it’s a fictional setting but also because it would drive the complexity through the roof and we have limited cognitive capacity and technological support for that.
So we operate on a scale between total abstraction and pure simulation.
Designers operate somewhere in this space, and the choice depends on what the designer intends to do with the game. The closer to pure simulation the more complex the game will become. The closer to pure abstraction the less relationship to the real world it will have.
Since I wanted to lean closer to simplicity my game involved a lot more abstraction than simulation but not so far down that it had no relationship with the subject I was trying to reference.
This abstraction/simulation layer applies to different parts of the game. Aesthetics can vary on its level of abstraction independently of the gameplay abstraction level.
Being aware of this tension is important to maintain coherence in the translation of thematic elements into game mechanics.
From information to game concept
My process involves choosing from the information gathered all the elements that are more relevant to the experience I’m trying to emulate. I picture what the game experience would be, what actions the player should take and how should the players interact between them. This is important because I have a particular outcome in mind: the feeling of commanding a ship in a sci-fi setting.
While I begin with a list of all I want to include in the game I actually start designing the “core” of the experience. The most basic version of the game, an MVP for all intents and purposes.
From the research I identified three basic actions, movement, attack and defense, and while I was interested in including more elements, like fighters, communications and more I had to make sure that a game featuring those three elements was fun before introducing more complexity to the system.
To translate an idea into mechanics it’s important to understand what the idea means and feels like and what elements are in the mechanics toolbox. There are many mechanics list, but the best way to know them is to play lots of games (or at least read about them). Once you are familiar with different mechanics you can see correlations between reality and the mechanical abstraction of rulemaking.
As an example of mechanics translation I knew that I wanted those three elements in the game and a pattern that emerged during research was that energy management was a characteristic element of the genre (The captain screaming for more power to the shields is a staple of science fiction). It made a lot of sense to marry those things together as the foundations of the game.
So I started with the idea of a board with energy as a resource that players could use and assign to perform different actions during their turn.
It’s important to mention that while we’re going to be working on both rules and components, what we are actually designing is a system and thus we are designing behaviour (both of the players and the system). So even the individual rules and actions are the artifacts we are going to design, the most important thing we have to take into account is the interactions and interdependencies between themselves and with the players.
So, for example, the idea about power setup was also tied to the principle of incentivizing strategic thinking. By making players think about the energy first I would put them in a forward thinking mindset (or at least that was the intention, we’ll see how well it turned out in the article covering playtesting).
And the same process of translation goes on for every element of the experience taking great care in how they interact with each other.
Getting it ready
Basically the process is composing an experience out of its characteristic elements, defining the core experience, develop it and then slowly adding new elements whenever appropriate for the experience.
But before incorporating more elements to the design of the core experience we have to make sure that it’s actually working as expected and -more importantly- that it’s actually enjoyable to play.
And that’s why the next article is going to be all about playtesting.
Entries in the series:
- Part 1: Learn your stuff
- Part 2: Synthesizing information
- Part 3: Defining the game and its scope
- Part 4: A game is a system (You are here)
- Part 5: Test early, test a lot
- Part 6: Lessons learned
