 http://www.55cards.com/brettspiel/img/1305/130529-Playtest-UK-Games-Expo-Angkor-Thom.jpg Good Day Internet! Today, we’re going to continue our journey in board game design with internal playtesting. We first dove into playtesting about three weeks ago with our discussion on solo playtesting. Internal playtesting is the next step on this long journey. We’ll start by going through the similarities of solo and internal playtesting, which will basically describe what playtesting is. Playtesting is the process of playing through your game (multiple times) from start to finish in order to improve playability and enjoyment. During this time, you should be making notes to adjust your rules and/or components after playtesting (or in a lot of cases in between playtests). You should also take time after the playtest to record any final thoughts from your playtesters, which includes you. (Feedback is VERY important--always take feedback into consideration for future changes!) So what makes internal playtesting different than solo playtesting? With internal playtesting you play your game with family, friends, and/or colleagues instead of just by yourself. You can still play your game with the other playtesters at this point, but the key is that you’re not the only one playing. In terms of feedback, most of your feedback will probably come after the playtest instead of during. In solo playtesting it’s easy to stop the game and make notes. That becomes more difficult when you’re playing with others and it can interfere with the flow and speed of the game. Also, hopefully your playtesters will give your game a fair chance and not just give their first impressions as feedback. Therefore it’s natural that the majority of feedback comes at the end of the game. But why are we just playing with friends, family, and colleagues? You’ve already done solo playtesting to fix up your game, so why aren’t we going to the public next? The easy answer is that playing with your friends, family, and colleagues will be a safe environment to playtest your game with other people. It will allow you to hone your skills of presenting a (keyword) brief explanation of your game. Also, they hopefully won’t mind so much that the game isn’t exactly publish ready or still has flaws. In fact, usually they’ll be very willing to help out with the development. Plus, if you have friends like ours, the amount of friendly teasing you get will prepare you for external playtesting. The other reason is: regardless of how well you believe you solo playtest, your game will not be ready for public playtesting. There will be problems and issues that still need to be fixed, and there will be things that you’ve missed. It’s always better to have another set of eyes to look at your work--because you may easily glaze over large errors. Some, but definitely not all, public/external playtesters want to see that you’ve done the work to improve your game before bringing it out to a public audience. They don’t want to point out simple things you should have seen on your own. So doing these tests with family, friends, and colleagues is useful to help find those problems you may have missed and to get them fixed. Alright, so what are you looking for when you internally playtest? One of the big advantages of playing with other players is you now get an understanding of what the personal experience of each player is like. It’s usually quite difficult when solo playtesting to get a feel of personal experiences. Most of the time you’re looking at your game as a whole and just making sure that it’s able to run start to finish without hiccups. However, your game is rarely experienced as a whole. It’s mostly experienced as individual players, with every detail being taken personally. This is because a regular player can’t just play with someone else’s hand, character, or whatever else it may be. They are stuck with what they are given, what they do, and what happens to them. This is definitely the biggest difference I’ve noticed between solo playtesting and playtesting with others. With that in mind, some of the questions you want to have answered are: What does it feel like when things don’t seem to be going your way? What does it feel like to lose your game? What does it feel like to win? Is it fun regardless if you win or lose? You want to see where players may get frustrated from how the game played out for them. Part of this is finding out if players felt like the winner (this includes the winner) earned the victory. Of course you need to keep in mind what you’ve designed your game to be. If everyone feels like the winner just got lucky, but you designed a game that relies heavily on dice, then don’t be surprised or necessarily discouraged. However, the most important thing to find out is who did and did not enjoy your game and why. Find the things that people didn’t enjoy and fix them or get rid of them. Find the things they did enjoy and focus your game around them. Additionally, you want to get rid of any other major hiccups in your game that you tried to get rid of in solo playtesting (unrealistic victory conditions, actions that give players unfair advantages, actions that prevent the game from progressing and can be done infinitely, etc.).  https://cf.geekdo-images.com/images/pic173153.jpg If you’re lucky, you may even get an idea from internal playtesting on who will enjoy your game. You should have a pretty good idea of who this will be beforehand, so see if those match up. Did your friend who always suggests Power Grid every game night enjoy your bidding game? If they don’t, then you need to find out why and what the differences are between Power Grid and your game that made it not as enjoyable. Then you need to determine if those differences are good things or just poor design, which sometimes is tough. But, if a player that always suggest bidding games every game night doesn’t want to play your bidding game, you probably have a problem you need to fix.
As a reminder, you should be writing all of those discussion points and feedback down so you can remember it, sort through it, and apply it to your game. One last thing on internal playtesting. You need to keep in mind who you are playing with for internal playtesting. Chances are you get a lot of positive feedback for your game. This is because these are people who love and care for you. Don’t get caught thinking that your game is close to done, or you’ve made an awesome game (I’ve done that before). There’s still lots of work to do, and it has yet to be seen if your game is truly great. That’s it for this week. Next week, we get to the scary world of external playtesting. Pro tip: it’s not that scary (though Allysha’s Anxiety thinks it is). 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
1 Comment
 http://cf.geekdo-images.com/images/pic1513328_md.jpg 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:  http://cf.geekdo-images.com/images/pic1535381_md.jpg “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  https://cf.geekdo-images.com/images/pic2590742_md.jpg 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).  https://cf.geekdo-images.com/images/pic2901097_md.jpg 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.  Making a Game Board 101 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).  The draw situation that always happened with the original victory condition. Same photo as last week. 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 |
Kevin CarmichaelBoard game designer and developer discussing the ins and outs of game design. 
Archives
June 2018
Categories
All
|
RSS Feed
|
|
Copyright © 2016