I was recently tasked with creating a Rulebook for the board game being created for Project 2 of Studio 1. The class was split into four groups and were each tasked with creating a different scenario for the same board game. The Rulebook initially consisted of a base Rulebook that would explain the rules that are common amongst all the scenarios, then an additional 4 Rulebooks that would explain the rules that are specific for each scenario.
I started my research into Rulebook layouts by analysing the Battlestar Galactica: The Board Game Rulebook. I decided to start with this Rulebook because it is a game that I have played and am familiar with, plus the theme of the game is somewhat similar with the theme of the project.
This first thing that I noticed about the Battlestar Rulebook was the Component List and Breakdown. I decided to include those same sections in the Rulebook I was making because I find it to be an excellent way for end users to ensure that they have everything that they need to play the game, as well as a convenient way for me to explain some surface elements of the game.
At this point, the Rulebook was filled with descriptions and explanations, but nothing that actually defines gameplay. After a few playtests, it was apparent that a game manager was needed in order to run the game properly. To help remedy this, the ‘Game Setup’ and ‘Gameplay’ sections were given step-by-step instructions that end users could follow.
However, this wasn’t too helpful because of another problem. That problem was delivery. More often than not, whenever a playtest was coming around, the Rulebook wasn’t very accessible and the explanation of rules was delegated to one of the team members that was operating the playtest.
Another issue that occurred was the re-designing of certain gameplay elements, namely the Hazard Cards. The layout of a Hazard Card changed four times and the gameplay of a Hazard Card changed three times. Keeping up with constant rule changes in order to maintain the validity of the Rulebook was vital. To do this, I attended all playtests and created playtest reports with reminders to adjust the Rulebook.
Perhaps the most complicated part of this process is collaboration. I was working with another student on the Rulebook. This means that a document had to be made that outlined what wording and layout was going to be used. The purpose of said document is to make the process of combining my work with the other students’ work smoother.
What I Would Do Next Time
If I were to write another Rulebook, I would follow a more methodic process. There were small things that were overlooked, such as the Spacewalk, that could be implemented much smoother if they were found earlier.
During playtests, I would take notes on how rules were explained as well as where gaps are in the Rulebook. Since there were approximately 5 playtests, that means that there were 5 opportunities to present, and receive feedback for, the Rulebook. When considering how helpful the last playtest was (the only playtest where the Rulebook was used), it would be a great boost in the quality of the Rulebook.
In order to make that happen, I would need to make sure that certain sections are done by certain times. For example, if the ‘Game Setup’ section is completed by the first playtest then I can receive feedback straight away. This allows me to present the Rulebook more often because the Rulebook I just helped make was built by working on every section a bit at a time. This meant that the Rulebook constantly had unfinished sections so I couldn’t show it to anyone, or at least I didn’t want to.
By the making the Rulebook one section at a time, I can show each section to the team as it is finished and receive feedback and implement feedback faster than before.