Brandon the Game Dev

Board game development is a very individual process. Every single developer has different methods for creating their games. This article is the fourth of a 19-part suite on board game design and development.

This suite is based on the Five Levels of Communication through Game Development, my own personal board game development philosophy. However, I’ve brought in Jesse Bergman, the lead designer of Battle for Sularia so that you can get two viewpoints instead of just one. We’re picking up where we left off last week with How to Design the Mechanics of Your Board Game, so read that if you haven’t had the chance yet. Today, we’ll be focusing on testing game mechanics after you design them.

A quick recap: game mechanics are how we bring the core engine of a game to life. Jesse and I will explain further. What follows is a lightly edited transcript of our direct messages on Discord.

This guide comes in three parts:

1. How do you test game mechanics?
2. When do you focus on one mechanic?
3. When do you drop, refine, or keep a mechanic?

How do you test game mechanics?

Brandon: How do you test game mechanics?

Jesse: I think it depends on various stages of the development process. When I first complete my rapid prototype, I call this Phase 1. Inside of Phase 1 I test the core gameplay loop. I do this solo with no one else around. I want to make sure that the game is working first before I share it with others. At this point, I do very little to tweak emerging behavior. I’m mainly interested in if the game can reach a victory condition and how long it takes.

Jesse: During Phase 2 I begin showing the game to other players that are interested. In this phase, I’m watching for dominant strategies and emerging player behavior. This is where I start to dive into balancing mechanical choices with regards to elements of the game, like spaces on the board for worker placement or card abilities in a card game.

Jesse: Phase 3 is where I really fine tune a game. During Phase 2, I try to get the game closer to about 90% complete from a development standpoint. Then during Phase 3 I do any final adjustments to the game based on additional tests that may show new or different imbalance issues.

Jesse: Ultimately, I ensure that each play-test session has a very specific purpose. If I’m worried about a particular player strategy I will ask one of the play-testers to focus their strategy on that. The goal being to see if the strategy is actually dominant or if my hypothesis is unfounded.

Jesse: During Phase 3 I also begin looking for blind play-testers. This process is arguably the most difficult as there are simply not that many blind testers out there and available to give you adequate feedback.

Jesse: We want to use blind feedback to gauge interest in the game because it’s more true to how the public will likely respond. In my experience, it’s just not enough people to really know.

Jesse: After Phase 3, the game goes to Phase 4 where we begin putting final illustrations and game elements into it. At this stage we are no longer testing but now demoing the product anywhere and everywhere.

Jesse: How much do we differ from your process?

Brandon: This is actually really close to my process.

Brandon: With Highways & Byways, my stages were called State Route, Highway, and Interstate. So my versioning would go State Route 1, 2, 3… then Highway 1, 2, 3… then Interstate 1, 2, 3…

State Route: Left
Highway: Middle
Interstate: Right

Brandon: State Route is a mix of your Phase 1 and Phase 2. During the earliest stages, I self-tested just to make sure the core engine functioned. Then I picked mechanics, trying each one – one at a time – to see if they worked. I tested with my immediate family at this stage.

Brandon: Highway was equivalent to Phase 3. Start fine tuning mechanics (once I figured out what the main ones are).

Brandon: I started doing what I call “single-blind testing” in the Discord server. I’d find people, have them read the rules, and teach me how to play. By actively participating but not revealing everything, I got some of the benefits of blind play-testing before I was ready for blind play-testing.

Brandon: Interstate is equivalent to Phase 4 – illustrations, refinements, and tweaking. The only difference is I blind play-test while waiting on art.

Jesse: The single blind play-testing model is interesting to me. So if a player teaches you incorrectly does that mean the rules are problematic or the game?

Brandon: Single-blind testing lets you catch confusing stuff on the rules, fiddly components, unclear wording, etc. I spend half my time taking notes in those sorts of tests because they help you catch far more details than a full blind tester would capture on a survey form. Plus you can get a feel for their raw emotions and not just how they frame their raw emotions afterward.

Brandon: You can do all this by observing from the background, yes. But when you’re not quite ready for fully blind play-testing, I don’t think it hurts any and people really like playing with the creator of the game.

When do you focus on one mechanic?

Brandon: What do you do when you need to focus on one mechanic?

Jesse: When we were developing the upcoming Reign of Terror expansion for Sularia this last year we introduced a brand new ability in the game. This ability was, in my mind, being underutilized by the core test groups in favor of their more familiar paths to victory.

Jesse: This mechanic was called Anarchy. It would destroy sites once you had created enough anarchy at the site in the game. Destroying sites deals damage and gets the player closer to victory. Players’ perceptions were that this was simply not as fast as attacking and dealing damage the normal way.

Jesse: We as developers were wary of one of two things.

1. The mechanic was subpar and, as a bookend to the faction, would have a poor response in the wild.
2. The mechanic was very strong, but misunderstood. That would lead to it emerging in such a way that it would create a negative player experience after it was discovered.

Jesse: Our response was to have a fixed amount of testers find competitive decks with the mechanic. Our findings from those sessions proved that #2 above was confirmed as real. The deck, after a few weeks of tweaking, became so dominant that it forced a rebalance of it and its sister mechanic in another faction.

Jesse: That sort of response isn’t found if, as a developer, we just let our players play and see what happens.

Brandon: What you experienced with the Anarchy mechanic is really important. I find that sometimes you either have to test a mechanic yourself or tell others directly to do it.

Brandon: I’ve flagged mechanics for “potential broken-ness” with intention to test them that way. I usually do this any time I have even the slightest hint that a mechanic could lead to runaway effects OR if I don’t understand what will happen yet.

When do you drop, refine, or keep a mechanic?

 

Brandon: How do you know when a mechanic has been tested well? How do you know when to keep a mechanic as-is, refine it more, or drop it entirely?

Jesse: That really is the $500,000 question. A mechanic can be tweaked to the point that it removes the fun in it. I believe that simple mechanical tweaks can be the difference between your game just being okay or being absolutely awesome.

Jesse: I think you know when a mechanic is done, when the play testers don’t complain about it and even potentially compliment it. When a mechanic is so seamless with the player that it just feels natural, you have a winner. Otherwise, it can be jarring and off-putting.

Jesse: In Sularia, we watched win/loss ratio along with details regarding things such as turn with first meaningful play to determine if the mechanic is contributing to the issue or if some other factor is. Mark Rosewater (head designer of Magic the Gathering) said in one of his drive-to-work podcasts, and I’m paraphrasing here “when a color or deck is acting up, it’s very easy to point the finger at an obvious card or mechanic, when in reality there is something much deeper causing the issue.”

Jesse: That particular line resonated the most for me, because we’ve seen it countless times now as we’ve developed a card game. I know that the advice is good regardless of what type of game a player is working on. In order to purely abandon a mechanic, data from play-test sessions has to substantiate the reason. If you have a mechanic that many players hate, but it’s integral the game, should you abandon the mechanic, the game, or what?

Jesse: I also think it’s very important to not throw the baby out with the bath water and keep a very open mind to how your game can evolve when you get out of the way and let it have its own life.

Brandon: Seamless is really the watch word there. If you need a bunch of rules to regulate mechanics, that’s usually not a good sign – a deeper issue like Mark Rosewater suggests.

Brandon: If it feels seamless and adds depth from the get-go, that’s great. Keep it and refine a bit. If it’s awful from the start, drop it.

Brandon: If you can’t get a mechanic to work after three or four versions, that’s when I think it’s time to let it go. I actually did this with War Co. back when it had a traditional life system like Magic.

Jesse: Yeah we dropped a mechanic from the upcoming Protoan line called Armor. The intention was that when a Protoan with Armor would die it would lose its armor token but remain in play.

Jesse: We could never get the balance on Armor cards quite right. They would either be to underwhelming or insanely powerful. The mechanic was abandoned and the faction redesigned to Virus, which will be found in the final release.

Brandon: Did you find that swapping it out was a lot easier than fooling with refinements over and over?

Jesse: Not necessarily easier, but the faction is way more interesting now.

Jesse: Getting Virus to function and behave properly took refinement but the game is better overall because of it.

Brandon: I find my games often make substantial leaps forward when I drop a mechanic that’s dragging them down.

Brandon: Thank you very much for working with me on this article!

Jesse: Thank you, Brandon! I really enjoyed this, I hope we can work together in the future.

 

---

As you can tell, creating and testing game mechanics is a nonlinear process. By sharing our individual methods, Jesse and I hope to be able to help you create elegant mechanics for your tabletop games.

In next week’s article, I’ll talk about how you make rules for your game to help you regulate the excesses of your mechanics. In the mean time, please leave your questions and comments below 🙂

Board game development is a very individual process. Every single developer has different methods for creating their games. This article is the third of a 19-part suite on board game design and development.

This suite is based on the Five Levels of Communication through Game Development, my own personal board game development philosophy. However, I’ve brought in Jesse Bergman, the lead designer of Battle for Sularia so that you can get two viewpoints instead of just one.

I’ve spoken before about designing and testing the “Core Engine” of a game. The core engine is what’s left when you strip a game of mechanics and obstacles. The core engine is the bare minimum set of mechanics and concepts you need to have a functioning (but not necessarily fun) game.

Game mechanics are how we bring the core engine of a game to life. Jesse and I will explain further. What follows is a lightly edited transcript of our direct messages on Discord.

This guide comes in three parts:

1. Who is Jesse Bergman?
2. What are game mechanics?
3. How do you come up with game mechanics and implement them?

Who is Jesse Bergman?

Brandon: Thank you very much helping me out with this! Tell me a little about yourself and Battle for Sularia.

Jesse: Where to begin? I’m 38 years old and was born and raised in Lincoln, NE. I studied Game Design at UAT in Tempe, AZ and graduated with honors in 2009.

Jesse: I’ve been a gamer for my whole life. While I’ve always played video games, I’ve also always had an interest in various tabletop games, going as far back as the early 90’s.

Jesse: Sularia was an idea I had during college back around 2008. It came to me as a passion for collectible card games and real time strategy video games. I had been very into the original VS. System from Upper Deck and wanted to create a game that required a player defeat the opposition by using two resources, base building, and unit building. Additionally, I loved the VS. System’s threshold cost mechanic and wanted to utilize it in Sularia.

Brandon: I’m definitely fond of CCGs and CCG-like games! Sularia fits in that classification pretty neatly from the sound of it.

Brandon: Not only do you make games, but you’re also formally educated in them. How has that formed your understanding of how games are created?

Jesse: When I went to school for game design, I thought – like most do – that making games is all “fun and games.” What I learned from my education wasn’t just principles of great game design like “risk vs reward” and “narrative storytelling,” but that games are a business like any other. They face real legal issues, intellectual property rights, trademarks, copyrights, etc… Going to school for game design gave me a very well-rounded appreciation of all aspects of game development.

Jesse: One of my biggest takeaways from school was the idea that complex interactions come from simple systems. I have an entire paper on how Mario and Megaman in the 80’s created outstanding gameplay with only three core mechanics – move, jump, shoot.

Jesse: The other big takeaway for me was finding out that design and development are the not the same thing. Many new designers or aspiring designers don’t understand the difference beteen design vs. development. Being a developer for a game is equally as important as being a designer.

Brandon: It sounds like it’s given you the sense that games are bigger than just design. Lots of factors come together into the cohesive games we enjoy.

What are game mechanics?

Brandon: With the basic idea that games are big multifaceted projects in mind, here is a question for you.

Brandon: What are game mechanics?

Jesse: Great question! I believe game mechanics come in a three different forms. The first is purely mechanical. They are functions in the game, typically controlled by the player, but not always. For example, one mechanic in Magic is mana. For other games, it would be resources. Mana in Magic is acquired by the player tapping lands (physical/mechanical manipulation).

Jesse: Other mechanics in a game are derived through player actions. You can do this through narrative, such as a players’ actions during an RPG campaign. They’re bound by their alignment or some other inhibitor. Alternatively, you have something as simple as bluffing about what card you may have in poker.

Jesse: Finally, some mechanics are not controlled by the player, but the game itself: such as timers or rotating dials (found in T’Zolkein). Each of these mechanics influences the players’ choices. This, in turn, impacts the gameplay and outcome of the game.

Jesse: I’m sure there are countless other examples and this answer is drastically oversimplified, but I imagine you can capture a great many through the following three lenses. Mechanical (mechanical function initiated by the player), emotional (metagame initiated), and game state (mechanical function initiated by the game itself.)

Reader note, ripped straight from Wikipedia: Metagaming is any strategy, action or method used in a game which transcends a prescribed ruleset, uses external factors to affect the game, or goes beyond the supposed limits or environment set by the game. Another definition refers to the game universe outside of the game itself.

Brandon: Board Game Geek alone lists 51 distinct mechanics. Not even an exhaustive list!

Brandon: As you put it, mechanics can not only be purposefully created, but that they can also organically arise out of repeated plays. That’s because player interactions can create their own mechanics.

Jesse: Exactly! So what do you think incorporates mechanics? How do we, as designers, recognize when a player finds a certain mechanic to be fun and perhaps even core to the game, even if we as designers didn’t intend for that? I’ve listened to so many designers describe how through play-testing, a game came out dramatically different then their initial concept because the new version was more fun.

Brandon: I see mechanics as an expression of what I call a game’s “core engine.” That’s the unremovable basic ideas behind a game – sometimes an objective, sometimes a feeling, often a mix of both. To me, mechanics are the underlying structure that helps games express the core engine.

Brandon: In the same breath, I believe rules are what we use to regulate that which mechanics alone cannot. For example, moving from point to connected point on a board is a mechanic. Getting to move up to six spaces is a rule.

Brandon: Structure can be both intended and unintended. An office is not merely scaffolding and drywall – intended by architects and construction workers. It is also a place of social interaction, hierarchies, and people influenced by the physical space (who in turn influence the physical space itself).

Brandon: Let’s take a video game example. Smash Bros. Melee – a unique fighting game that got a new lease on life as people exploited glitches and created a new form of completion. Those glitches weren’t intended, nor were characters intended to be sorted into tiers by quality…yet these unintended mechanics made the game feel better for the diehards who play it today. One can argue that this unintended behavior is the game’s core engine now.

How do you come up with and implement game mechanics?

 

Brandon: This brings me to my next question: how do you personally come up with ideas for mechanics and implement them?

Jesse: I approach design in a couple of different ways. Sometimes I get inspired to design a game around a theme that was significant in my life at the time. I can take a lot of influence from the media that I’m consuming and transfer that into a theme. Using this top-down approach, I work to find the best mechanics that will fit the theme. At that point, I’m getting close to a prototype.

Jesse: Other times I get really excited about a potentially unique mechanic that I’ve not seen in another game, and begin designing a game around that mechanic without theme. This bottom-up design approach also works and keeps the game able to be themed into anything that would work for the overall design. I’m still a very big proponent of theme in my games and don’t see myself really deep diving into themeless euros.

Jesse: But I never know where my inspiration comes from.

Jesse: How about you? Do you approach design from a top down or bottom up approach?

Brandon: I’ve done both. I’ve taken mechanics from a childhood game and rebuilt the theme around the mechanics – War Co. I’ve also gone on many road trips and said “this would make a great board game” – Highways & Byways. One came from abstract mechanics and the other came from travel brochures and the other from half-remembered coffee-soaked cross-country trips.

Brandon: When you need to find mechanics for a theme, where do you look? And follow-up question, if you’ve got a mechanic in mind, how do you make the theme?

Jesse: I don’t necessarily go looking when I’m specifically looking for a mechanic to fit a theme. I think in order to be a better designer, you have to play games and a lot of them. I pull inspiration for mechanics from my past experiences as a gamer in both tabletop and digital spaces. The more games I play, the more I see how I want to make changes to the mechanisms to try and “improve” them. Sometimes I fail, sometimes I don’t. I fail a lot more than I succeed in those endeavors.

Jesse: When I have a mechanic in mind and want to attach a theme, that is a much trickier proposition. Particularly because without care, the theme can feel a bit tacked onto the game. In a game I co-designed with Matt Greenleaf, which is currently unpublished, I had come up with a mechanic that was whenever a player made a move, the game state would either go to imbalance or balance.

Jesse: I didn’t know what theme this would land on for quite some time, but we eventually landed on the idea that we were Buddhist monks working on a zen garden. With each patch of grass, rock, or bonsai tree placed in the garden, the world would move to either a more black or white state. As monks we can only win once we are in perfect harmony, which requires strategic placement of garden tiles to balance our own inner state. The game’s greater balance mechanic can enable us to make more powerful moves when the world is aligned to the color of move we are making.

Jesse: I think in the case mentioned above some of that theme comes from play-testing, and some of it was from setting the mechanic aside and returning to it with a new frame of mind. This can be somewhat difficult, especially as designers when we are particularly excited about a mechanic. Have you walked away from a design and returned to it later or are they all abandoned to a closet or notebook?

Brandon: A lot of your process for developing mechanics comes down to experience and perhaps even intuition.

Brandon: However, in lieu of both those things for the new game devs in the world, I’d recommend using BGG’s list of mechanics as a good springboard. Not to mention, there are lots of good games, five of which I’ve specifically pointed out, which contain a wide variety of mechanics that you can use. Mechanics can be used in combinations to make all sorts of different games, but like keys on a piano, the ones that you can clearly distinguish from others are limited in number.

Brandon: I’ve dropped lots of mechanics. I’ve done hard pivots on both War Co. and Highways & Byways at some point. In my recent career, I haven’t shelved a game to return later. I have, however, completely changed the basis of both games, effectively leaving behind the husk of game that used to be.

Brandon: I do have an Evernote list with a bunch of ideas, too. Sometimes I use those ideas, sometimes I leave them for later.

Brandon: Would you say you just take mechanics you’ve seen in other places and try them in a new context, then?

Jesse: I’m always trying to find new innovative ideas. Every time I do so, I inevitably find a player who says, so it’s like this “insert game.” I think there are very few new ideas remaining, many of the mechanics are derivatives of another game. That doesn’t mean their are no new ideas left, but instead that truly innovative mechanics are one in a million. Which is why I believe as a designer, unique twists on familiar mechanics will only take you so far. The final polish of a game from a graphic design, illustration, retail packaging, and community support are imperative to a successful game.

---

There’s more where this came from. Next week, Jesse and I will continue to discuss game mechanics. However, we will focus on testing game mechanics once you have designed them.

Until then, please leave your questions and comments below 🙂

Board game development is a very individual process. Every single developer has different methods for creating their games. This article is the second of a 19-part suite on board game design and development. I am going to teach you my own methods every week for the next four to five months.

My board game design philosophy is stems from the Five Levels model, which I created and explain in depth in Five Levels of Communication through Game Development. The basic idea is that board games are a means of communication that facilitate gameplay. This communication happens on five levels: the core engine of the game, mechanics, rules, the internal narrative or “theme”, and the external narrative or “community and marketing.”

Last week, I talked about How to Design the Core Engine of Your Board Game. This week, I’ll tell you how to test your ideas to make sure they hold up well enough to make a game out of them. If you need a refresher on good play-testing practices, please see The Art of the Play Test: Designing Tests and Keeping Records. When in doubt, keep a spreadsheet with information on how the game went. You can always refer to that data later if you don’t catch something important when you first play.

In order to teach you how to play-test the core engine of your game, I’ve split this article into three sections:

1. Making a Core Engine You Can Test
2. Setting a Definition of Success
3. Testing the Core Engine of Your Game

Making a Core Engine You Can Test

First things first, in order to test the core engine of your game, you need something playable. It doesn’t have to be fun, challenging, or meaningful. Your game, during this very early stage of development, just needs to be an activity which can be completed by following instructions.

If you haven’t made a functioning game yet, you’ll need to make one. The way you go about this differs based on the idea that you are trying to capture.

For War Co., this involved creating about 300 really rough cards that followed extremely simple trade-off calculations. The trade-offs were the engine I needed to test, but in order to test them, I had to make cards. The trade-off calculations behind it were designed to slowly dwindle all players’ resources to make them feel like they’re in a post-apocalyptic situation.

For Highways & Byways, the idea was to make players feel like they were travelling across the United States, exploring all of its hidden roadside treasures. The way I created the core engine was by making a map of interconnecting roads. I needed this in order to be able to move a piece across the map. This was how I built the game to have the constant sense of motion.

Setting a Definition of Success

After you have a testable version of your game’s core engine, you need to define what success looks like. For War Co., I just needed a game that steadily removed cards from players. If after a few simple tests it consistently performed this function, that would be successful. Likewise, with Highways & Byways, as long as I was able to move around the board non-stop, that meant the core engine was working.

Again, I’d like to reiterate that you’re not looking for fun. You’re looking purely for function and coherence. At this stage of development, War Co. was terribly unbalanced and Highways & Byways had no objective – it was just movement.

Testing the Core Engine of Your Game

At the risk of sounding sacrilegious to experienced game designers, I recommend that you test the core engine of your game alone (or with only teammates). Obviously, it’s not acceptable to test your game alone and push it to Walmart shelves without another person laying hands on it. Yet at this stage of game development, you’re not testing for subjective experiences like player enjoyment. You’re not even testing for unexpected strategies. You’re testing purely for functionality. That is something you can test alone.

However, I’m not just saying you can test alone. I’m saying you should. Play-testers can be hard to find and their time is valuable. You don’t want play-testers to get a look at your game too early on. That can make it hard for them to give meaningful feedback later on. It’s a weird psychological issue caused by people knowing where your game came from, how far it’s advanced since it started, and how much they’ve invested in it emotionally.

The other benefit of testing this way is that you can stop the test if anything breaks. You can fix it on the spot and either restart or resume testing as appropriate. I play-tested Highways & Byways alone until I knew I could move freely about the board without getting stuck anywhere. When I did get stuck, I’d draw a new line and drive across it.

How long does it take to get through the core engine testing? There is no clear answer to this question. It could take a few speedy run-throughs or fifty games. It really comes down to the complexity of your game and how you choose to express it. You just have to keep testing until your game is functional on a basic level and it succeeds at expressing the ideas you want to express.

---

To summarize, testing the core engine of your game requires three parts. First, make sure you have something really simple and basic since you’re just testing for functionality. Set a clear definition of success so you know if your play-testing is successful. Test alone or within your team. If at any time during the testing, you are unable to complete a test, stop the test and tweak the game.

In next week’s article, we’ll talk about how you make mechanics for your game. This will help you add some meat to the bones of your game’s core engine. In the mean time, please leave your questions and comments below 🙂