![]() Good Day Internet! Today we’re going to discuss what to keep in mind when creating your own Print and Play (PnP) for blind playtesting. For those who have never heard this term, a Print and Play is a set of electronic files that allow willing playtesters to print off (almost) everything they need to play your game at home. This would include the rule set, and files to create paper copies of all components. Many PnPs are available online on various forums and websites, but you also have the option to email your files or grant access to them on platforms like Google Docs to select personnel. Through creating our own Print and Play for Pulled into Darkness and playing multiple Print and Plays from other creators we’ve learned a lot of tips and tricks on how to make a Print and Play more playtester friendly! 1) Provide a Theme and Mechanics Overview in Your Post You need to be able to catch potential playtesters’ attention before they even open any of your files. Therefore, it’s important to have a short, well-rounded overview of what your game is in your post. That way potential playtesters can get an idea of if your game is for them and worth looking into more. Furthermore, most playtesters aren’t going to click through to your PnP files unless you give them a reason to; they’ll most likely skim the overview and decide whether or not to from there. So only cover the basic theme and mechanics, and keep it short. As an example, take a look at our original post for Pulled into Darkness on boardgamegeek. ![]() 2) Provide the Basic Board Game Stats Number of players, play time, and type of game should be prominently shown near the top of your post. Some of these should also be included in your post title if posting your PnP on a forum. These stats let your potential playtesters know at a glance if they can play your game or want to. However, don’t deceive your playtesters. If your game doesn’t play 2 players and takes 2 hours, don’t say it plays 2 players and only takes an hour just to get more interest. It’s hard enough to get people to play Print and Plays, don’t chase them away with lies. 3) Be Upfront About Required Additional Components Whether you post your PnP on your own site or on a forum like the boardgamegeek Works in Progress forum, part of your original post needs to tell players if they will require any additional components not provided in your files. There is nothing more frustrating than committing to printing off a PnP only to find that you don’t have all the components you need to play the game. Let your players know upfront in the post (not just in the rules) if they will require extra components. Additionally, you need to be practical about how many extra components you can reasonably expect your playtesters to have on hand. If your game requires 150 tokens in 10 different colours and shapes you’re probably going to want to provide files for those in the PnP. Even if it’s not that many, you could still provide them on their own sheets in the PnP and then if a playtester happens to already have those components they simply don’t print off those sheets. Again, if you do such a thing, remember to explain that in your original post. ![]() 4) Avoid Round Components if Possible For your first PnP, you want to make it as easy as possible for players to get up and running with your game. Round components are more time consuming to cut out than triangle, square, or rectangle components, so you should eliminate round components wherever possible. Also, when it comes to cards most playtesters won’t cut rounded corners, so don’t waste your time putting those in. When you have a game that has proven to be good, and art that brings out the theme and looks aesthetically pleasing your playtesters will be more willing to spend the time cutting out components. 5) Provide a Black and White Version Not everyone wants to spend the money or has the option to print in colour, but there can be information loss printing a coloured version of a PnP in black and white (the amount of information loss depends on the number of similar tones and how they’re combined). Therefore, you should provide a black and white version of your game for those people, but remember to keep colour variants where it matters. For instance, unless your game is strictly solo or 2-player, you should keep colour in player pieces. You could also use symbols instead which is more friendly to colour blind players. Although you may not have any colour blind playtesters for your game, it’s always a good idea to keep them in mind and be inclusive when choosing player colours or by utilizing symbols for player pieces instead. ![]() 6) Appropriate Access If you’re granting access to your documents online be careful to make sure your playtesters don’t have full access to edit your entire documents. Chances are they won’t destroy everything you’ve worked so hard on, but they might (even if only accidentally). If sharing access on a PDF or Google Docs use ‘Can View’ on your share settings to make sure your playtesters can’t do anything to your document. You may also want to use a watermark on your documents to prevent any fraud or theft (although I’ve been told removing a permanent watermark is easy if you know what you’re doing). The other option on Google Docs is to use the ‘Can Comment’ share setting to allow your playtesters to put their feedback directly into your rules without finalizing any changes. This is extremely helpful for applying your playtester feedback afterwards, but it will make your rules messy and harder to navigate for later playtesters. If you looked at our PnP you may have noticed that we didn’t follow all of these tips and tricks. All of our spaceships are circles, we didn’t put a mechanics description on our website, and we didn’t provide a black and white version (although that would have required some creativity on our behalf). In retrospect, we probably could have made the spaceships triangles, and it would have been easy to include a mechanics description on our website. The reality is that you’ll probably never create an initial PnP for a game that everyone loves, but there are ways to make it stand out a little better. We’ll definitely be trying to improve our PnP for the next version and apply what we’ve learned so far. After we return from GenCon we’ll be working hard to get that up and running so check back soon for updates! That’s it for this week. Next week we’ll put out a last minute, scrambled blog post after a week of packing in preparation for moving! Perhaps the packing will inspire us to write about organization of mechanics and making a working ‘turn order’ in game. We’ll see. 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
4 Comments
![]() 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 ![]() Good Day Internet! Today we’re going to take a look on how I went through all the design steps we’ve talked about up to this point (Game Basics: Theme, Game Basics: Mechanics, Where to Start: Mechanics or Theme?, Designing Your Core: The First Prototype, and Designing Your Core: Solo Playtesting) for our current project: Pulled into Darkness. The inspiration for Pulled into Darkness originally came from reading a review on the abstract board game Circular Reasoning. How I came about that part of the internet, I’m not sure (can’t figure out how to get back there either). The important part though is how the game is played. In Circular Reasoning the objective is to get your three pieces to the centre of the board. There are also three gates, one for each level, that rotate around the board. In order to get to a lower level, your piece has to move through that level’s gate. I liked the idea that the only goal of the game was to get your pieces to the centre of the board and I also liked that the board was circular. I started thinking of how I could create a game like that. Maybe the goal would be to go from the centre out? That just seemed like the reverse of the same game. What if you were trying to avoid your pieces moving to the outside? Or to the centre? That had some potential, but I needed a reason why you would want to do that--what would really drive the gameplay. In other words, I knew I needed a theme. Knowing so was mostly from my own personal experiences: The first game that I really worked at never had a solid theme until months into the design. I was only ever concerned with making a game for fun, and for me, making mechanics was fun. I hardly ever care about the theme of any game I play, so why would it be necessary that I come up with one for my game? Once Allysha got involved in the project, she said that there HAD to be a theme and started working on a strong one immediately--I reluctantly agreed. A year later, I have a game that works, but no one wants to play. Despite our best efforts (Allysha and I), the theme seems pasted on and the game isn’t fun. It’s not that the theme or mechanics are bad (in fact, we’ve had plenty of compliments on the theme and mechanics), but they are better separate then they are together. So for now, that game is shelfed. Beyond not wanting to make that same mistake again, I had seen how much easier it is to design a board game when you focused on developing theme first for other projects. So, I didn’t act quite yet on that initial inspiration. I just kept it in mind over the next few weeks and thought a lot about it lying in bed at night (frankly, I think about games every night and probably should always be wearing this shirt). ![]() The next inspiration came from a prototype of the soon to be released J’Accuse! by Jonathan Lavallee. We played J’Accuse! back in December 2015 at the Snakes & Lattes Designers Night and Allysha loved it! She is waiting patiently (not really) for its Gen Con release so she can buy a copy as soon as it comes out! The game was really simple, but fun. Each turn you only had 4 choices on what to do. You were either moving evidence around or locking it in (J’Accuse!) on a player. I liked the limitation in play and wanted to utilize that somehow in a game. For some reason I didn’t really think about that until almost a month after playing J’Accuse! At this point, I wasn’t exactly sure that I wanted to combine the avoiding your pieces moving to the centre of the board and limited moves system. Besides, I still didn’t have a theme for either (which was what I was supposed to be focusing on). So once again I stored those ideas away and kept thinking about them as I laid in bed at night. Then, one fateful Thursday night in January, I figured out my theme. A whirlpool! No…wait…a black hole! No…whirlpool was right… Okay, maybe I wasn’t too sure at that point which one to choose, but I knew one of them would work. The idea was you were being pulled into a whirlpool (or black hole) and had to do your best to keep your ships alive as long as possible. However, due to the dire circumstances, there was only so much you could do and therefore limited moves available. Now that I had the theme figured out I could finally start getting into the details. I immediately started scribbling down notes on gameplay…or at least that’s what I should have done. Instead I kept developing in my head that night, which caused issues later for public playtesting. More on that another time. The first problem to solve was to find a way that the ships would be pulled in at different times so that it wasn’t just everyone getting pulled down every turn (that would suck as a game). This lead to the whirlpool/black hole being divided into quadrants, and the development of what later became Gravity Cards to determine which quadrant would get “pulled down” at the end of each turn. Once a quadrant was pulled down, the corresponding card would be turned over. This worked great because I also wanted each player to only have 4 possible movements. I could now design the game that each player could give out only a single command to all their ships in a quadrant each turn. But what were those 4 movement actions going to be? I chose a LEFT, RIGHT, and STAY as my first three and decided DOWN would be the last one. The reason I chose DOWN came back to the theme of you being pulled into a whirlpool/black hole and there’s only so much you can do. Therefore, unfortunately one quadrant has to be sacrificed each turn. I woke up the next morning still very excited and began creating my game. I grabbed some blank poker cards, chits, and a square card “mat” that we had grabbed at our last Protospiel (thanks again to The Game Crafter) and started designing. Cards and chits were easy. I used different coloured markers to design and colour them and I was done. The board was the tricky part. I sort of knew I wanted there to be less space to move as you got closer to the centre of the whirlpool (it’s only a whirlpool at this point because I drew it in blue), but didn’t know how to do this. So I started with what I knew: there were four quadrants. From there, I drew the centre of the whirlpool and coloured it in. Then I took one of my chits and figured out how many I could fit in each quadrant directly around the centre of the whirlpool and drew that in. Then I figured how many I could fit above that level, and so on until I used up all the space. Side note: People have since commented about how well I’ve mathematically modeled the black hole out. I have no problem telling them afterwards that it was pure dumb luck. When Allysha tried to recreate it for our PnP, she had a very rough time because it was dumb luck (you're welcome Allysha). The first prototype was now ready to play! So I played about 10 games by myself on that Friday and Saturday. Two main problems were resolved through that solo playtesting. The first problem solved was having the game end prematurely. With the rules I had come up with (and yet to have written down. Bad Kevin!), a player who found a way to have a ship avoid being pulled down by the “Gravity Cards” the first four turns (otherwise known as a round) would ensure themselves at least a draw. This was because the victory condition was to be the last player with a ship surviving. This meant you only had to focus on one ship. To solve this, the outermost available ring is now pulled down after each round. I was worried this would feel like it was punishing players who used a “superior strategy” or outsmarted their opponents. However, because of the impending doom feel to the theme, this has yet to be a problem. The second problem was briefly shown in our last post which was the game always resulting in a draw situation. Surprisingly, I didn’t realize this until about the tenth playtest. This occurred again because of the victory condition and the nature of the board. Once you got down to the lowest ring, any ships there could find a way to survive to the end and therefore resulting in a draw. The solution was to change the victory condition so that the last player with multiple ships surviving (instead of just one) would be the winner. I chose this because there was no clear way to make it so that the “last one standing” victory condition work. I also knew I could find something in the theme for that (now that it’s a black hole game, the way to explain it is that you need two surviving spaceships to send back the recorded research data--the initial purpose of the mission). One bonus from this rule change that I didn’t consider was that changing the victory condition to multiple ships not only shortens gameplay, but also shortens the time of which eliminated players have to wait until the end of the game. It also gives players who can no longer win (only have one ship) that option of messing around (in a small way) with those players still jostling for victory. I must say, it’s very satisfying.
I would love to tell you more about how not writing down the rules caused problems on the first playtest with Allysha, but this has been a long post and we haven’t discussed internal playtesting yet, or how to write a useful set of rules. So we’ll leave it at this for now. I hope us putting together our experience with making the first prototype helps you understand why we blog about the things we do! We hope you found this real life example useful. If you did (or didn't) let us know below. 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 ![]() Good Day Internet! Today we’re going to start talking about how to design a workable core for your game, which means we also need to talk about making your first prototype! First off, what’s the core of a game? We’ve discussed the basics previously in Game Basics: Mechanics, but for time’s sake we’ll recap and get a little bit more in depth this time. The core of your game is the essential mechanics (the ones that without you couldn’t play your game from start to finish), and the basic theme to tie the mechanics together (which should be mostly complete at this point). That’s it. There should be some consideration given to the design of cards, but no need to worry about art quite yet. So how do we find the core of your game? Well, you could try to come up with that through developing your idea on paper (which for some works), but most likely you need to playtest your game to find this out. That means you need a playable, understandable prototype, which means you need to actually make one. Before we do though, let's consider what we’re creating a prototype for. We’re creating a prototype to find the core of your game. Which means we’re trying to find out: What drives your action? What is the essence of the story of your game? What makes your game a game (something that can be played all the way through)? This is just the basics of your design and is not your final product. Therefore, your first prototype does not have to be all that fancy. We just need components that will allow us to play your game using the given essential mechanics and have space for the required text and some simple drawn art (at most) to convey some sort of theme. However, most of your theme is the backstory you’ve created, and in how the mechanics actually work. With that said, in making your first prototype you want to keep it simple. So go ahead and grab (or borrow) components from other games and/or make your own components (For example, 7 Wonders is great for borrowing tokens and Axis & Allies is great for war units). Usually, the thing that will take you the longest is making or finding components for cards. If you have some sort of art skill (I personally do not) or technical skills with Photoshop or other software (I do not) then you could create simple cards there, print them off and sleeve them. Again, don’t worry too much (or at all) about the art. If you need some templates you can find them here on our drive. You can also cut your own cards from old cereal boxes, bristol board, or just print off the blank templates we provided above and then write on them, cut them, and sleeve them. You’re not alone if you choose this path, and there are a surprising number of articles, blogs, and videos about making your own cards. Unfortunately, most of those are for high quality printed cards (including this one from BoardGameGeek). So what if you don’t have any of those skills or would prefer to not spend an afternoon cutting and sleeving cards? Well, you could always use blank cue cards, blank business cards (or just look for one-sided ones), or if you’re lucky blank card stock. You can also purchase blank playing cards from places like The Game Crafter or MakePlayingCards.com and if you make it to a Protospiel or Spielbany event you can grab a bunch for free courtesy of The Game Crafter (that’s what we did, and we love them for it). Whatever path you choose, just remember you only need the essential information on your cards for your prototype. For our prototype of “Pulled into Darkness” (seen above) our cards have a simple symbol and basic text to indicate what the card does. If you really like creating art though, go ahead. Just make it barebones and realize there’s almost a 100% chance it will change. But we think you should probably still do it because it will look cool and you’ll enjoy doing it.
Alright, so we’ve got our basic prototype ready, now what? Well hopefully you’ve been writing down a framework of rules or have them all memorized (although we highly recommend writing them down) so you know how the game should play. If not, get that done as soon as possible. I like to think I have a good memory, but I’m always surprised by how many rules I forget if I don't write them down (it’s also a big reason why our editor Allysha is part of our team). Once that’s done, we’re ready to playtest, and the first playtest we’re going to do is a solo playtest. Which will be next week’s topic (sorry amigos, you’ll have to wait until then). 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 |
Kevin CarmichaelBoard game designer and developer discussing the ins and outs of game design. Archives
June 2018
Categories
All
|