Well, it’s certainly been a while! Fifteen months and one successful Kickstarter campaign later, we’re still going strong here at HPG, even if there has been some radio silence in the blog. We’ve now got our next game in the works (though I’m not going to talk about what it is here), and that has had me thinking about the ways in which we design games. Today I’d like to talk about different mindsets that we have as designers and how those mindsets affect the way we design games. I’ll be looking at three different design mindsets and breaking down what methods each one uses, as well as its strengths and weaknesses.
The first mindset we’ll be looking at is what I’ll call modular design. I’m starting with this one as it is the mindset that I personally have when designing games. A designer with this mindset views a game as a set of connected modules, each of which has a few simple components. The beauty of the design comes from how these disparate modules interact with each other to create a unique and complex experience. There are several important strengths to this design mindset: first, it allows a complex design to be broken up into many simple pieces, each of which is on its own much easier to implement. Additionally, designing this way allows a design team to easily split up work between its members, as the modules themselves act as clear divisions of labor. Finally, this mindset is great from a business perspective, as it is arguably the easiest to expand upon in the future, allowing a successful modular game to be a source of profit for its creator long after its initial release.
However, modular design is not without its downsides. Because of the naturally fragmented design process, it is easy for a modular game to feel disconnected and confusing if the various modules do not work together well. Additionally, communication is essential during design, as if the teams working on different modules do not understand what the others are doing, it can lead to difficulties when the modules are being connected in the final stages of design. This mindset also requires discipline in the initial stages of design, as the modules chosen to be in the game must not be so different that they cannot work together, or so similar that they are indistinct. Overall, using modular design requires an organized team that can plan ahead well, communicate during design, and integrate distinct components well, or it will result in a disorganized, incoherent jumble of ideas.
Some examples of modular designs include Red Dragon Inn and most Trading/Collectible Card Games (on a macro-level; individual sets may be modular, or one of the other two types).
The next mindset I’d like to talk about is procedural design. You’re probably familiar with this one, as it’s how humans tend to naturally approach problem solving — when faced with an obstacle, we consider a possible solution, try it, and then improve it based on the result. Fundamentally, procedural design seeks to take a core idea for a game, test it, and then develop it based on the testing. This mindset is most useful because it is so tried-and-true; after all, everyone has heard of the scientific method, and we’ve been using it formally for hundreds of years. Another strength of this method is that it will lead to a game with a very strong central identity since it focuses on developing a core game concept over the whole of the design and development process.
Just as procedural design’s strengths stem from its focus on developing a single core idea, so too do its drawbacks. One such drawback is that procedural design is heavily dependent on the strength of its core idea — if after several iterations of design, it becomes apparent that the game is not going to work as planned, it can be difficult to salvage a procedural design without significant work overhauling it. Speaking of work, it is also more difficult to divide among teams than a modular design, as the components tend to be interwoven and challenging to develop in isolation. Finally, procedural design also has the simple drawback of being traditional. While not impossible, it is certainly more difficult to create something truly new and innovative if you are using old tools.
For examples of procedural design, you shouldn’t need to look far. Most games on the market today were likely designed using a procedural design mindset, or potentially the final mindset we’ll be looking at.
Our final design mindset is a fun one. Sometimes, when you’re out of ideas and need to make something happen, you have to start spitballing; it might not be great, but hey — you never know. This is what I like to call dartboard design. Not every game has to come from a beautiful web of modules working together, or from some grand idea worked to perfection — some games come from a room of tired designers asking “what if we combined deck building and worker placement?” (I checked, by the way. There are 144 games with those two mechanics together on boardgamegeek, and most of them are actually expansions or other non-games). The strength of dartboard design is that it can produce absolutely ridiculous ideas that no one would have thought of otherwise, and sometimes these ideas can be revolutionary. However, sometimes they… aren’t.
Much like procedural design, dartboard design’s greatest strength is also its greatest weakness. As it turns out, there’s a reason a lot of ridiculous combinations of ideas haven’t ever seen the light of day — a lot of them are really, actually terrible. You have to get through a lot of the rough before you find any diamonds. Additionally, remember how I talked about how procedural design can take longer since it’s difficult to divide up the work? Dartboard design is ten times worse, since it basically consists of everyone getting together and just saying stuff until something sticks; as you might imagine, there are more efficient ways to use your designers’ time (unless they are poor college students, of course).
If you want a great example of dartboard design, look no further than the name of our company, Houseplant Games. After an hour or two of trying different sensible names for a gaming company and finding every url already taken, we eventually turned to naming random objects in the room we were sitting in, until eventually someone said “houseplant games”. Everyone laughed, and then we all collectively paused and thought about it, and after a few minutes of discussion, we decided that it would actually work. Did we make the right call? Ultimately, I guess that’s up to all of you.
As far as board game examples, it can be difficult to distinguish dartboard design from the other two design mindsets without knowing how the idea was initially created and developed. If you ever see a particularly crazy game concept though, that might be a sign of a dartboard design.
Each of these three mindsets has its uses, and no one is universally better than the others. While I might personally prefer modular design, I can still acknowledge the usefulness of procedural and dartboard design — sometimes you need to stick to tried-and-true methods, and sometimes you’re just out of other ideas. The true challenge in design comes not from understanding these mindsets, but knowing when to apply each of them, as using one when another would be more appropriate can mean the difference between a bad game and a good game, or between a good game and a great one. The only way to get better at this is through experience, so get out there and make some games!
Hopefully you found this discussion of the ways in which design can be approached beneficial, if not for your own design work, then at least in giving you a better understanding of how the games you love came to be! Over the next three weeks, I’ll be going into more detail about each of these three mindsets with example designs and discussions of how each of these mindsets connects with professions and types of people outside of the gaming world. If that sounds interesting to you, then don’t miss next Thursday when I break down the modular design mindset! Until then, happy gaming!