![]() Good Day Internet! Today, we’re going to continue our journey in board game design with how to explain your prototype to playtesters. This is the next step in the playtesting process. You’ve already solo playtested your game multiple times and should have the basic rules and theme written down, so we’ve got a good start. Most of what you’ll have to do now is organizing those notes and gameplay into a brief and concise explanation of your game. Your explanation should follow the below structure:
The first thing you should talk about is the overview of the theme, otherwise known as the Thematic Overview, and the objective. This way players get a quick idea of what to expect and what they are trying to accomplish. It allows players to get into the role they are taking on and get into the game. Your description of the theme should be approximately 45 seconds or less (depending on the game), and your objective (the main objective, not all the side objectives) should be a one or two liner. The theme will give an idea of the general backstory (not detailed backstories for each character, faction, or whatever else) and what situation the players are currently in. The objective is what you are trying to do in that current situation described by the theme. For example: “in Friday you take on the role of Friday (based off of Daniel Defoe’s novel ‘Robinson Crusoe’), who lives on an otherwise deserted island. One day, a nearby ship capsizes and a man named Robinson washes ashore. Robinson’s presence disturbs the peace you had enjoyed prior to his arrival. To give Robinson a chance to leave the island, you have taken on the task of helping to improve his survival skills against the hazards of the island. Your objective is to help Robinson fend off two pirates so he can leave your island. This will allow you to finally get your beloved peace back.” (adapted from the Basic Theme section of Friedemann Friese’s game Friday) In the above summary, you can see how theme and objective can sometimes blend together in your Thematic Overview. This is what you should be striving for because your theme, objective, and mechanics all need to be cohesive. Starting off with an objective that isn’t aligned with the theme can cause confusion before players know how to play your game; not a great start to any playtest. The next part of your explanation should focus on the flow of what happens during the game. If possible, it’s always good to start with describing how your game is divided (rounds, turns, phases, actions etc.) and briefly describe what happens at each of those stages. Your goal is to give players a brief understanding of the flow of the game and what options are available to them. For example, my description of gameplay flow for Pandemic sounds something like: “On your turn you have 4 actions. You can do any of the actions listed on your reference card, and you can do an individual action multiple times. Once you’ve completed your 4 actions, you draw two Player cards and two cards from the Infection deck. Whatever city is listed on the Infection cards gets a cube of that colour. Then the player on the left takes their turn”.
Obviously, there’s more to the game than that, but that is the main gameplay flow and gives players an overview of what they do on their turn and how play progresses. Once that is done, now you go into how each part of gameplay (the actions, phases, turns, rounds, and so on) works, starting with the first thing players do and going in chronological order. If there are multiple things players can do (multiple actions to choose from), start with ones players usually do on their first turn. When explaining all these parts, you don’t want to go over every edge case that could possible happen in game. Basically, anything that happens only twice of fewer times a game that isn’t ingrained into the gameplay (for example, end of round play) probably shouldn’t be explained before playing. If you see that one of the edge cases you didn’t explain fully in your pre-game explanation could possibly happen in game, then make sure you explain it before it happens. In general, going too far into all the edge cases can blur what actually happens during gameplay (depending on how far they stray from regular gameplay). After you’ve gone through all these steps, you should be ready to go. When actually explaining your game, try to show examples of gameplay instead of just describing it. Always make sure to do your best to pause and answer any questions during your explanation. At the end of your explanation it’s always good to ask if there are any questions before you start playing. Common courtesy and patience are key here. If a player doesn’t understand something you thought was apparent from your explanation, you may need to describe it to them in a different manner. Lastly, just as a FYI, this guide isn’t just for the first time you present your game to someone else. It’s useful for every time you explain your game to a new player. So through every iteration of your game try to stick to this format. If you do, you should have a clear and concise explanation of your game that will get you and your playtesters up and running quickly. Next week, we’re going to discuss internal playtesting where you can put these skills to use. Thanks for dropping by! If you have any questions or comments, please leave them below. You can also find us on Facebook and Twitter. Take Care! Kevin
0 Comments
Leave a Reply. |
Kevin CarmichaelBoard game designer and developer discussing the ins and outs of game design. Archives
June 2018
Categories
All
|