 http://bit.ly/1RHttpu Good Day Internet! Today we’re going to discuss how to know when your game is ready for blind playtesting. We’ll go over the changes your game goes through to indicate it has completed external playtesting. Before we can do that though, we need to discuss what blind playtesting is. Blind playtesting is the process of playtesting your game without designers’ direction or input. Playtesters will be given the game with a set of rules and must figure out how to play the game on their own. One of the main goals of blind playtesting is to determine how strong and comprehensive your rulebook is. Therefore, you’re going to need a solid and unquestionable rulebook before you start blind playtesting (we’ll discuss how to do that next week). Your game is also going to need to be otherwise complete, but what does that mean? How do you know your game is complete? #1. External feedback is narrowed in on the superficial. You should notice that feedback has changed from mechanics and theme overhauls to working on slight art changes and/or wording of text. If your bigger, game breaking comments haven’t been around for awhile that’s a good sign your game is running smoothly and nearing its completion. #2. Feedback is generally positive and playtesters are having fun. A game that isn’t fun, or that playtesters can’t find a lot of positive things to say about means you have a problem. Either you; a) haven’t found your target audience, or; b) your theme and mechanics aren’t working very well together. If you plan to publish your game, these issues are going to be barriers to selling your game and will most likely prevent you from publishing/funding at all. On the other hand, having both positive feedback and fun playtests are good indications that you’ve found the market for your game. Unfortunately, we know the pain of having a game that works smoothly, but didn’t get glowing feedback. “Rariora” was the first game I worked on. It was a themeless card game until Allysha came aboard to help me out. After close to a year of development, the game was running smoothly, but we didn’t have anyone saying they wanted to buy it/back it. Despite our best efforts the theme and mechanics were not working together. Feedback indicated the theme was grander than the mechanics and players were confused how the winner actually won the game (definitely not good). As individual pieces they worked fine, but when together something just didn’t click.  http://bit.ly/1TU4VPN At that point, we put that project aside until we decide we can rehaul the game entirely to make theme and mechanics work seamlessly. It really sucked that it looked like we were making good progress over the year, but ended up with a game that was inherently flawed and had no market. However, if you find yourself in the same spot, you’ve got to make the effort to rehaul the game. A game that isn’t fun and won’t sell is no good to anyone. Step back and rethink the game so theme and mechanics work well together and players have fun playing. Don’t worry though, it happens, but it’s an experience to learn and grow from!
#3. You’re satisfied with your game. When it comes down to it, the designer(s) gets the final say on whether or not their game is complete. So you need to ask yourself: Are you happy with your game? Does it fit the vision you had? And are all the parts there? If something feels off, try to narrow down what the game might be lacking, figure out what aspect of the game that relates to, and try something new. Worse comes to worse, you revert back to what you had (you may find out in the end that it was exactly what you wanted). However you come about it, you need to be confident and satisfied with your game. Without it, you’ll struggle in putting in the extra work to get your game published. That’s it for this week. Next week we’ll take a look at writing clear and concise rulebooks (as long as Allysha isn’t too busy!). We hope you had a great Taco de Mayo! Don’t know what we’re talking about? Check it out. 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
5 Comments
 http://bit.ly/1YU0HHW Good Day Internet! Today we’re going to discuss Lewis Pulsipher’s "Designer Effect" and how it relates to your external playtesting. We’ll go over both his thoughts and our own about what affects it has on the external development of your game. The "Designer Effect" is a term coined by Lewis Pulsipher to describe the effect a designer has on playtesters by participating in the playtest (you can check out his video on it here). Pulsipher says that when playing with the designer playtesters tend to fall into one of two categories. They either: a) think they have to gang up on the designer (“he knows the game best and is going to win if we don’t do something”) or; b) they don’t think they can beat the designer at their own game and don’t play as hard. In either case, Pulsipher’s view is that your game (assuming you plan to publish) is not going to be played with you there all the time and therefore these effects you have on the playtests are negatively impacting your results. Put simply: you should not playtest your own game. We, on the other hand, think that the "Designer Effect" is a good reason you should playtest your own game. When external playtesting, as with all playtesting, you want to test your game under as many different circumstances as possible. You want edge cases to come up whether it be in the game or because of a particular gameplay style. It helps to find out how your game operates under those situations and if your game breaks. The “Designer Effect” is one of those edge cases we’ve experienced when playing games without the designer and therefore want to playtest with our own games.  http://bit.ly/1YU1KHT Do you have one player in your group that seems to win every time they play “their game”? Have you ever had the rest of the group try to gang up on that player when “their game” comes out? I know we have (shout out to our amazing friends :D). Sometimes it can be because that player has already won a few games in a row that night and we need to end the winning streak. Or maybe it’s just because they got the first points of the game by backstabbing. Regardless the situation, ganging up on a player in game does happen. Occasionally, the opposite happens and everyone gives up because they “know” who is going to win (usually denoted by the: “I knew you were going to win, you always win” comments after the game). Again, this is a replication of playtesters not trying their best against the designer because how could they possible beat them? Therefore, if these are situations in which your game may be played, you should be playtesting them. If at the end of your playtest you think it fell into one of the categories described by the "Designer Effect", try to get answers to the below questions and any other pertinent questions for your game under those circumstances.  http://bit.ly/1OKeNpC If everyone ganged up on you, did you still win? Was it is easy to win? Does that mean there’s a steep learning curve to your game? Is there supposed to be a steep learning curve? If you think the other situation happened where everyone else kind of just gave up; Did everyone else still have fun? Was it fun for you? Was the game still close? If it was, is there too much of a catch up mechanism?
It’s important to recognize that just because you play your own game doesn’t mean you’ll always experience the "Designer Effect". You should be aware that it can occur, but you shouldn’t be actively seeking it out when playing your own game (that would most likely negatively affect the playtest). Of course, even if you do experience the "Designer Effect", you’ll be testing an edge case and the feedback you’ll get is still valuable to the development of your game. That's all for this week. Join us next week where we'll discuss when you know your game is ready for blind playtesting. 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  http://bit.ly/1TdpSqo Good Day Internet! Today we’re going to discuss when you should and when you shouldn’t play your own game during external playtesting. We’ll also talk about how it can affect the game and the kind of feedback you’ll get. When first starting out with external playtesting, it’s natural to want to play your own game: it’s what you’ve been doing so far for playtesting, so it feels comfortable. Initially, including yourself in your playtests will help transition you into external playtesting as it can sometimes be a little unnerving first presenting your game in front of strangers. Plus, playing your own game means you don’t need as many playtesters, and don’t have to put yourself out there as much to get your game up and running. Therefore, we personally recommend that for the first few run throughs of external playtesting you play your game with the playtesters to get yourself into the groove. Additionally, by including yourself in the game you also get the personal player experience which is useful for seeing the game in another perspective. Board games are a very social experience, so it’s good to connect with your playtesters on a social level to get a true feeling of the emotions and level of fun. If you experience the same kind of frustration, joy, or other emotion based on a similar game situation as your playtesters, you’ll better understand how that situation needs to be dealt with (if at all). Depending on your learning style, and personal preferences, this may be very beneficial for you in order to understand some of the feedback you receive. Another benefit of including yourself in playtesting is that you can try out different strategies/ways of playing to see how they “work” in game. , By doing so, you have control over when and how a play style is implemented into your game. You don’t have to hope that a playtester will play your game that way eventually. There are limitations to this however--if your game has direct conflict, playing as an aggressive player against new players (your playtesters) is probably not very beneficial to getting good feedback. The whole point of external playtesting is to get external feedback. If you crush your playtesters in game because they don’t know how to respond (or you’ve found out through being aggressive that your game favours aggressive play), that may negatively affect what kind of feedback you get. There are however other potential downsides to playing your game with external playtesters.  http://bit.ly/1sky6kn One thing to take notice of is you may get caught between playing your game and monitoring the playtesters for nonverbal feedback. Signs such as playtesters who seem to be frustrated over a certain situation, or players who are only doing a select few of the available actions all game won’t be as evident when you’re in “game mode”. This is because as a player you’re usually busy reacting to other player tactics and strategies, and trying to create a dominant strategy. This means you usually miss exactly what all other players are doing and their feelings towards your game. If you miss these signs you may have to rely on the playtester naturally bringing this feedback up verbally at the end of the game. Otherwise, you’ve lost out on that feedback and analysis. So what about not playing your game and just watching the action? What’s the benefit of that? If you decide not to play your game with external playtesters, you will be able to better monitor the action more closely and pick up on nonverbal cues. In general, it’s going to be easier to pick up on the smaller things like player tactics and keep track of analytics such as play length and when certain events triggered. This should lead to more game specific and player experience specific questions at the end of the playtest, which hopefully lead to better insights into your game. This is the main benefit of not playing your own game; you get to focus solely on analyzing your game and how it plays. Something else to consider is that removing yourself from playing your game sometimes helps with separating yourself from your game (as mentioned in Preparing For External Playtesting). By not playing your game and focusing on analyzing it, you too are looking at it in a similar way as your playtesters. You are only making judgements on the game, not you as a designer. Your goals are to improve the gameplay and make it fun, just like everyone else.  http://bit.ly/1Yx8z1P Lastly, not playing your game with playtesters helps you to transition into the final stage of playtesting: blind playtesting (which will be discussed further in a future blog post). In blind playtesting, you won’t have any interaction with the game. You’ll hand over the complete game and rules and let the players figure out everything themselves. This will be tough if you haven’t playtested a lot of times without playing your game. Even then, depending on how much control you exert over your playtests that you don’t participate in you may have a difficult time with blind playtesting. However, not playing your game is going to help at least a little in making that transition and “letting go” of your game.
So in general, you’re going to participate a lot more in your external playtests early on than later in external playtesting. In fact, perhaps you’re not playing your game at all near the end of external playtesting. There are, of course, exceptions. One of the main ones is if you don’t have enough players, then you should definitely play your own game (even if you are nearing the end of external playtesting). It’s also usually a good idea to join in if you’re short on the number of players you want to test your game with. In the end, the type of feedback you get may vary, but it will still be valuable. You just need to figure out how important it is to test your game with that many players at that particular moment. That’s it for this week. If you’d like to meetup, we’ll be at Snakes & Lattes on Monday night for the Game Designers Night. We’ve also been signing up for events at Gen Con this week. We’re completely overwhelmed by the number of events, so if there’s any event you think we’d be crazy to miss let us know! Next week in the blog we’re going to look into the Designer Effect and how that can affect playtesting. 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  http://bit.ly/1ZzkHzQ Good Day Internet! Today we’re continuing our preparation for external playtesting with the rulebook. There are two main reasons you should have a basic rulebook prepared for external playtesting: The first reason being if you forget what happens in a specific situation, or forget which version of a rule (or rules) you’re playtesting, you have a reference to go back to. You may think that seems a little silly (me? Forget the rules to my own game?!? Yeah, right), but it does happen. You have to remember that your game is constantly changing and there’s a chance you accidentally use an old obsolete rule (I can attest to this happening to me). The other time this usually happens (or to me at least) is when an edge case comes up. Although you may have written the rule for it long time ago, remembering what it is is difficult because it doesn’t happen every game (it’s an edge case for a reason). So despite how fantastic of a memory you have--or think you may have--having a rulebook so you don’t forget your own rules is important. The second reason is if you have a designer team: the rulebook will help to keep you all on the same page as to what rules are being played with (ask Allysha how many times I’ve caused her agony by not explicitly telling her what rules we’re playtesting with). This will also aid in making your explanation of the rules smoother when you go to playtest as you both will know what needs to be said. Alright, so maybe you’ve never written any sort of rulebook, how-to, or any other kind of instructional before and want to know: What should it look like? Good question. :) To begin this discussion, we need to go over the purposes of a rulebook. The two main purposes are to: 1. teach new players how to play your game and; 2. act as a reference guide to experienced players (for further discussion on this topic checkout this video by Gil Hova from Metatopia 2015 featuring himself and Geoff Engelstein). The below format serves both of those purposes. It presents the game in a way that makes it easy to learn to new players (giving the overview and flow of the game before going into the specifics), while additional subheadings make it easier to navigate for experienced players. This is the format we always use when initially writing out a set of rules.  http://bit.ly/1T88a4H Intro/Overview: Your background story/recap on what situation the players are getting themselves into. It sets the scene (thematically, usually) for the entire game. Components: This isn’t so important for playtesters at this point, but is important for the final rulebook and print and plays (PnP). This way players (including yourself) know whether or not there are missing pieces, or in the case of PnP players, if they have everything they need in order to play. Objective: What the players are trying to accomplish. It should also make it clear how players are competing (free-for-all, teams, cooperative, etc.). This is the more technical/mechanical explanation of the 'Overview'. For example: “To be the last player with multiple spaceships orbiting the black hole”. Setup: How to get the game ready for play. There shouldn’t be anything in here that mentions what components are used for or why they are important--save that for the 'Gameplay' section. Just make sure that in this section everything is laid out clearly--if diagrams are necessary (they almost always are) don’t be afraid to put those in!  http://bit.ly/1Wm3yfl Gameplay: The main gameplay section tells you how the game is broken up (rounds, turns, phases, etc.) and summarizes what players do in each of those stages. This section should explain the flow of the game from start to completion.
Once that’s done, you go into the gameplay specifics, which should be explained in the order in which they occur in game. This is where you explain exactly what happens during each turn, action, round, etc. You also should have sections dedicated to complicated subjects and their edge cases (for instance, our section on Collisions for “Pulled into Darkness”). One game which Allysha feels does a decent job of explaining its different gameplay sections and exceptions is the original Yu-Gi-Oh Trading Card Game (TCG). It lays everything out in a particular order for easy learning, but it can also be navigated easily during gameplay. Game End Conditions: What initiates the end game (ie. once the last card is drawn, at the end of the fourth round etc.), when the game is actually over (ie. each player gets one more turn--including the player who drew the last card), how players tally their points, and restate what the victory requirement is/who wins. Following this guideline should give you a rulebook that is easy to use for new players while not leaving experienced players utterly frustrated. You may have to customize this layout for your game and include additional sections (like a glossary of icons, or card anatomy) for the final rulebook, but this format will serve well for any game. It’s always good to start with the outline first to make sure you have everything covered and know what may need it’s own section. There’s a lot more to rulebooks than this, but now is not the time for that. Hopefully, I can get Allysha to do the next one (on rulebook specifics and editing) as a “guest post”. 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  Credit to: Mark Kolb designer of The Connections Card Game Good Day Internet! Today we’re going to prepare you for external playtesting. We already have gone through how to present your game, so this time we’re going to focus on the feedback aspect. Up to this point, you’ve been playtesting with family, friends, colleagues, and by yourself. Most of the feedback you’ve be given is probably very supportive of your project (regardless if it’s positive or negative). This feedback has hopefully helped you make a lot of progress in your game development. Your game should be functional now (although it may not be fun), and you’re probably feeling pretty proud of it (ie. me with my first project). So it’s pretty natural that your hopes are high that everything is going to go great for external playtesting. The reality is that the majority of the time external/public playtesting is not going to be as supportive or positive. You will get negative feedback, your game may not be as entertaining as you thought, some playtesters will make it clear they don’t like your game, and problems are going to be found (potentially very big ones). For new designers, and some experienced ones, this sometimes hurts more than it should. Now, we’re not saying you shouldn’t go into public playtesting feeling proud of your game in order to avoid this potential pain. Instead we’re going to focus on how to mentally prepare you for public playtesting in a way that you will be ready for what may otherwise be a demoralizing and hard-to-accept experience. We’re also going to go over what you need to do to make your playtests productive and to make sure you don’t put up a wall to criticism of your game. The main thing you can do to prepare is to do your best to separate yourself from your game. Whatever playtesters may say about your game is not a reflection of who you are as a person. It is also not because they want to ruin the thing you’ve worked so hard on. You’ve asked these people to give their feedback and perspective on your game--not you, not how much work you put into it, not what your vision is. The only thing you’re asking them to provide feedback on is the game, and that’s exactly what they’ll give you. Another way you can prepare for external playtesting is to keep in mind that your game is still in development and is not perfect. Being ‘in development’ implies that more work is expected to be done on your game and that you’re still tweaking/fixing parts of the game. Don’t fool yourself into believing that because your game has been working smoothly so far that it will continue to work smoothly forever (as this is rarely the case). Development happens in stages and sometimes you take steps backwards instead of forwards. That’s okay though because in order to develop a great game you need to know what doesn’t work as much as you need to know what does.  http://cf.geekdo-images.com/images/pic2452831_md.png  Accepting criticism and critiques also requires you to understand that there is no perfect game. You can’t reasonably expect to have everyone enjoy and give glowing feedback for your game because there is no game in existence that works flawlessly and pleases everyone. The number 1 game on boardgamegeek.com: Pandemic Legacy, has 3587 10/10 ratings. It also has 278 ratings of 1/10 (certainly not a number to be scoffed at). Not everybody will like your game--and this is just a reality of designing and playtesting. Regardless of what you do, a playtester who doesn’t like social deduction games (for example) is almost guaranteed to not like your social deduction game. So don’t get too worried or upset if they don’t like your game. However, even if the don’t like your game you still need to listen to what they have to say--they may have some advice about how to make your game more interesting to other types of players! Furthermore, when someone says they didn’t like an aspect of your game, you need to do your best to understand this is not out of hatred, but rather to help further develop your game. This isn’t necessarily about them not understanding the game, what your vision is, or how much work you’ve put in. Instead of getting overly defensive when you receive that negative feedback, try to figure out why the playtesters are saying that, and ask how you can fix it so that it works with what you were planning. You need to do your best to be unbiased and neutral in order to avoid influencing playtester feedback and show you are willing and enthusiastic about improving your game (same goes for presenting your game). Alright, we’ve started to make that transition into a productive playtest. So what should you be doing to get the best feedback? The first thing you should make sure you’re doing is recording the feedback you’re getting. This shows that you’re taking the playtesters’ feedback seriously and it will help you remember what was said when you go to apply your feedback. Of course, to apply feedback you need to be able to sort through it. So make sure you keep things neat and in order for your own sake. Part of that is writing down when (including start time) and where the playtest took place (something I’m not very diligent in doing, but Allysha is--see the picture to the left). If there’s an idea that comes up multiple times from different playtests, you should highlight it (use a different colour, put a star, asterisk, rainbow, or whatever else beside it)--this change should be something you consider for your game. There’s a reason multiple people are suggesting it, and there’s a good chance it’s going to improve your game. Just like in internal playtesting, most of your feedback for external playtesting will probably come at the end of the playtest. However, that doesn’t mean you shouldn’t be taking down feedback during the playtest. Just do your best not to interrupt the flow and speed of the game as we mentioned in Designing Your Core: Internal Playtesting. If a playtester mentions a piece of feedback during game that requires additional detail, the best practice is usually to write it down, and ask for further clarification after the game. Don’t delay the game for others by focusing on one person’s feedback during a playtest. The only time you may want to do this is if every playtester is thinking the same thing. If this happens to be something that’s potentially game breaking, ask the playtesters if they’d like to stop at this point. If they do, figure out if you can make a quick fix (with help from your playtesters if you need it) and keep going. If that’s not possible, have a discussion on how to fix it for the next playtest. Stopping your game because of a large flaw is difficult, but you have to be respectful of your playtesters’ time as well as your own. Playing and getting feedback on a game that is not fully functional is not going to be as productive for you or your playtesters. Take the time to figure out how to potentially fix it, and then go from there. When the playtest is done, write down the end time so you know how long the playtest took. This helps you determine whether your game is taking too long (or is too short, how we wish we had that problem) or if your playing time seems to be inconsistent. When you’re asking for feedback, remember that how the game felt is just as important on how the game played. You’re looking for how the experience played out for your playtesters, and feelings is a big portion of that. Don’t discount the fact that someone felt a card was overpowered just because they couldn’t tell you exactly why. Also, always allow players to explain how they’d like to see the game progress or improve after the playtest. You might find something you really like or can fix something you’ve been struggling with.  A board game designer in their natural habitat. Lastly, take the time to review your feedback after a playtest. Think about if the feedback is consistent amongst that playtesting session, consistent among other playtests, and/or if it’s consistent with your own thoughts on the game. Think about what you want to try (or should try based on volume) for future playtests. When you have those figured out, come up with how they’d work in game, apply them when you get the time, and start again. If anything is inconclusive, stick with what you got, and playtest with another group. You can ask them at the end of the playtest if they thought the same as the other playtesters, or if the game would go better with the previously proposed changes.
We’ve focused a lot on converting negative feedback into a positive experience in this blog. However, there will be times when you still get external playtesters who are enthusiastic about your game (even if they didn’t like it in it’s current state). Usually this happens after you’ve done your work and have applied feedback correctly. So don’t think that it’s going to be rough experience all the way through. You will be rewarded for properly playtesting and adjusting your game, and enjoy watching your game grow into something great. 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
April 2017
Categories
All
|
RSS Feed
|
|
Copyright © 2016