Board game development is a very individual process. Every single developer has different methods for creating their games. This article is the sixth 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 Sean Fallon, the mastermind behind Rift Shifters and Paths so that you can get two viewpoints instead of just one.

Rules provide directions on how to execute activities within a game. They explain, limit, and clarify. Game rules are how we regulate the mechanics of our games so that they are consistent with the messages we want to send to players. Sean and I will explain further. What follows is a lightly edited transcript of our direct messages on Discord.

This guide comes in four parts:

1. What are some guidelines for writing good rules?
2. How do you test your rules?
3. Rules testing in action
4. Advice from Sean

What are some guidelines for writing good rules?

Brandon: Once you get through the drafting stage of rules, it comes time to get very serious. Rule writing can be business-like, resembling technicial writing in a lot of ways.

Brandon: What are some guidelines for writing good rules?

Sean: Guidelines for writing good rules really boils down to learning the art of instruction and communication. I’d say the main tool set for understanding and wielding that art form is empathy. When writing rules, you need to clearly understand and feel how that player may be feeling in the situation you’re writing for. In some cases you may want to invoke a specific reaction, hopefully not extremely negative, but a reaction that helps propel that player forward so they can strategically use other opportunities that may come their way in order to continue playing the game.

Sean: The last thing you want to do is isolate the player so much that the game is no longer playable. Isolation and making a game difficult are two very different things, which is why writing good rules are very important so misinterpretation doesn’t creep in during game play.

Brandon: I agree with what you’re saying. Never write a rule you wouldn’t want to read. For that matter, never write a rule you wouldn’t want to read to a table of people who are halfway listening!

Brandon: When people feel isolated from a game because of its rules, there’s usually one a few things going on. The rules could be way too wordy or vague. They could be framed in a negative manner.

Brandon: For an example of framing: there’s a huge difference between “lose 50% of your movement this turn” and “move 50% of normal speed this turn” even though they’re functionally the exact same. The latter just sounds better.

Brandon: To flip this, I’d say you need to make sure rules are concise, clear, and framed in an nonthreatening manner. For rules that explain, it’s really important not to make them too wordy. When rules clarify, it’s really important not to make them too vague. For rules that limit, it’s really important to frame them as neutrally as possible.

How do you test your rules?

Brandon: With all this in mind, how do you make sure your rules are actually any good? How do you test them?

Sean: It’s all about how others perceive the rule. This is why it’s very important to test with as many people as possible that are brand new to the game. Granted, it’s also important to have repeat testers, too, in order to make sure the flow of the game rules feel spot-on. Still, it’s even more critical to consistently play with new people. The reason for this is because the first impression means everything. If someone can read your rule and execute the action on the activity flawlessly, that is a fantastic rule. If it takes them longer, this may be due to a couple of different reasons.

1. The game itself is very complex, which has been known to happen as some games are specifically designed this way.
2. The game itself is very complex, and that wasn’t the intention at all, which is a larger problem.
3. The written rule and/or visual aid is poorly done and needs to be revised.

Sean: I personally have three different levels of testing.

1. Short-term mechanic testing. This type of testing goes back to coming up with ideas and tweaking them, testing each one individually based on what has been written down.
2. Private testing. This is where I will invite a specific group of game testers to test my game assuming they have the time to do so.
3. Public blind play tests. This is where most of the rules have been ironed out and are acceptable enough to use during a prototype either in person or online through something like Tabletopia or Tabletop simulator. This phase is supposed to help catch and inconsistencies, as well as document any unforeseen questions that players may have with any of the rules.

Brandon: It’s interesting that you split your rules testing into three levels. Number 1 is the most interesting since that’s where you make rules that fill objective needs.

Brandon: At the short-term mechanic testing stages, you’re really just using rules to help underlying mechanics manifest themselves! This is to make sure the game is – on some fundamental level – balanced.

Brandon: Later, once you start doing private testing, a lot of balance issues start coming out of the rules. You have to tweak them over and over until the game actually plays well, allowing for different strategies and styles.

Brandon: The blind play-test stage is where clarity and framing become serious issues. If your rules aren’t clear, blind play-testers will struggle because they’re trying to learn without your help! If your rules are framed poorly, they’ll feel like they’re getting screwed over by the game when, from a strictly mathematical viewpoint, they’re not.

Rules Testing in Action

Brandon: You have laid out a really good framework for different types of rules testing so far. Yet this is all very abstract, so let’s tie it together by swapping stories.

Brandon: Can you provide an example each kind of rules testing from your own game design experiences?

Sean: Sure! Let’s start with a simple mechanic such as dealing damage. The thing to keep in mind here is that the majority of the time, we will always start to design something based on our own experiences, but once you’ve laid out the foundation, you must start bringing other experiences into it.

Sean: I started off with a very simple D20 type of system for Paths: World of Adia. This went very well with my short-term mechanic testing, but unfortunately, a lot of this had already been done. There was nothing new here, so I really had to dig deep into this one and start putting my own spin on things. This gets strange simply because the only way to put a true new spin on something is through the eyes of others.

Sean: I ended up resorting to a concept of taking MMORPG concepts and placing them into this D20 world. This completely altered the game and even broke some mechanics like dealing damage. The way something like the D20 system played was very slow, and very much meant for “theater of the mind” style of game play. By introducing this new MMORPG concept into a tabletop RPG world it dramatically changed everything.

Sean: Many times I had gone through how damage was dealt, and how it was taken. Where in an MMORPG world, that concept is very straightforward. Run toward the unit and attack or cast your spell. This was similar in the tabletop world, however there aren’t any beautifully rendered 3D visual models in animated focus. Here in a tabletop RPG, I had to seamlessly give both a “fast” feeling of gameplay while painting a picture for the player.

Sean: This was super rough until I realized that I wanted to create a way where the game controls most of the combat and the story can still be told by the players playing. This really was the best of both worlds. This lead to any damage mechanics being almost automated inside of a tabletop RPG – which is a very strange concept to think about.

Brandon:  It sounds like what you needed to test early on was how much you could minimize human interface, such as from a game master, in combat. At the time you were creating rules, you needed a proof of concept. To get into the meticulous work would have been silly. You just need to make sure it worked.

Sean: When running through the private testing phase we initially ran into some snags. Questions of “how do I know when a monster is attacking me?” and “who’s telling the story?”

Sean: I initially solved these with a sub-par “threat mechanic” that gives each player a “threat meter,” and the minion or boss would attack the player with the highest threat. I also made it to where each player would take a turn telling the story.

Brandon: With your threat mechanic, it sounds like you needed a way to resolve combat. Easy to execute and remember were your first priorities. What you initially tried worked okay for private testing in the sense that the game was functional, but it didn’t quite “vibe” right with your players.

Brandon: I had a lot of problems like this with War Co., too. I needed to make sure cards had written and executable effects – phrasing wasn’t a worry just yet. That fine-tuning – the efforts toward perfect balance, framing, and clarity – come later.

Sean:  Then we did some public play tests. Unfortunately, it didn’t go well at all. Many people were confused.

Sean: In the end, I had to go back to the drawing board. I was pretty much stuck, but I knew my concepts were great. People loved the idea but I failed to execute it. This is when I realized I seriously needed some help and another set of eyes. I started to scout out someone who could really help me put things in motion and help solidify some of these concepts I had.

Sean: Sure enough, I joined your discord server, Brandon, and that’s where I met Howl Philinish. He has helped me execute all of these mechanics, and then some, and really set-up a great backbone for mechanics like damage, who’s telling the story, and the threat generation system.

Sean: With that said, this means that we are now back in short-term mechanic testing and are slowly shifting into private testing.

Brandon: Public testing is so often where ideas fall apart. It’s often true that we need others to help us write clear rules since we tend to understand our own work better than anyone else ever could. We see our intentions and can never decouple them from our words. I remember you finding Howl through Discord, and I’m glad that happened the way it did!

Brandon: I’ve had so many rules go out the window through public play-testing. Nearly every Event Card in Byways got changed. I ended up implementing a light action point system to increase number of player choices. I’ve simplified Construction rules. I’ve reframed negative Events into more neutral ones. Public play-testing has dramatically improved the game’s rule quality simply because it’s not just me and, every once in a while, my brother.

Advice from Sean

Brandon: If you could go back in time and give yourself one piece of game design advice, what would it be?

Sean: I would specifically tell myself four things.

1. Don’t be afraid to share your work and don’t be afraid to ask people to look at ideas. Understand that even if it’s just 1 person who enjoys what you are creating, you are impacting someone else’s life by your creation and design – and there is nothing that will be more valuable than that.
2. People will only support your dream of game design if you talk about what you’re doing. You can’t expect to post a single image, never share it again, and expect that magically everyone will look at your stuff. You need to be absolutely consistent, and sometimes repeating your same post 1 – 5 times before receiving some kind of feedback or response.
3. Don’t be afraid to learn and change your game design. People will always give feedback, but you as the creator need to understand that you need to keep some old and bring in some new in order to have an awesome game. This doesn’t mean go and change everything because some guy told you he doesn’t like your game. Look for a consistent pattern that is brought up by multiple people and then possibly pivot and change your game design accordingly.
4. Understand your audience for your game. This is so critical as this changes everything you’re doing. From rules, to theme, to game type and concept, you must be absolutely sure that what you’re doing is targeting the right people for what you’re trying to execute. These two things must become a beautiful marriage. A marriage between audience and game. If that marriage does not happen, you will most definitely be forced to pivot. I learned this the hard way.

Brandon: Wow, I couldn’t have said it better myself! Those are some of the core messages of my blog. Share your work, don’t be afraid to self-promote, be ready to change, and try to  understand people.

Brandon: Thank you very much for your insight. Looking forward to sharing this!

Sean: It was a ton of fun! I really enjoyed this and hope we can do it again soon. 😀

---

Creating and refining rules can be a complex process! By publishing our conversation here, Sean and I hope to be able to help you create rules that make your game balanced, clear, and tons of fun.

In next week’s article, I’ll talk about the storytelling aspect of game development – the internal narrative. For now, please leave your questions and comments about designing and testing rules below 🙂