 http://bit.ly/2eYvGoD Good Day Internet! Today we’re discussing the importance of designing with the core experience in mind and how properly doing so creates better games. For those who may be unfamiliar with the term “core experience” it’s generally defined as the experience you want your game to provide to players. More specifically, it’s the emotions and feelings you want your game to provoke as determined by its mechanics and the way the theme is presented. It should be noted, however, that games that have the same theme and similar mechanics can still have different core experiences. For instance, Axis & Allies and Memoir ‘44 are both World War II games with dice driven combat, but the experiences and feelings provoked in each are different. Axis & Allies focuses on the stresses of managing a large war machine, and Memoir ‘44 focuses on the tactical combat of historical battles. Because of these and other nuances, there is a deeper ‘connection’ to your pieces in Memoir ‘44 than there is in Axis & Allies and the core experiences are different. We’re going to address a common mistake some designers make when asked about the core experience of their game and then we’ll get into how designing with the core experience in mind helps designers create better games.  http://bit.ly/2e5OiDL Some designers define the core experience or the core of a game as the thematic elements and mechanics that have to stay aka are “must-keeps”. Oftentimes when a designer thinks about the core experience in terms of “must-keeps” they tend to list most of the mechanisms and thematic elements currently in the game. As far as we can tell, this tendency is related to the emotional and psychological connection designers have with their designs and people’s natural aversiveness to change. Designers may be averse to change to avoid feeling like they are losing control over their vision and the game they’ve created. However, by limiting the creative space you have to work in, by creating a long list of “must-keeps”, your game will have a tough time growing and developing. It will also be much more difficult for you to accept outside feedback and apply it to your design. Basically, whatever state your game is after the first external playtest is pretty much where it’s going to stay with this kind of fixed mindset. Of course this won’t apply to every designer, but the amount of creative space you can work in is vastly increased by chasing the experience your game creates for players instead of what you want to keep in the game.  http://bit.ly/2fz5FhG One of the other problems with designing based around keeping certain mechanical and thematic elements is that the goal of any changes you make is unclear. Your only goals will be to make a good game and to keep certain elements in your game. The elements you want to keep are already there, so the only real goal you have is to make a good game. That’s so arbitrary and wide open that it’s a nearly impossible target to hit. On the other hand, designing around the memorable experience your game should create gives a very specific goal on how your game should perform and feel. This does open up the game for a lot of possible changes, but when the game is off you’ll know what needs to be added and can start exploring possible design solutions, and when do find the memorable experience you were chasing after you’ll know it. Designing around a core experience may be a difficult challenge at first. As we’ve mentioned, there’s a natural tendency for us to be averse to change and hold on to the thing we’ve created, and there’s also a lot of creative space to work in that may seem overwhelming at first. However, having all that open creative space allows you to experiment with your design in many ways without losing what you liked about the game (assuming you’ve fully embraced designing based on a core experience). You’ll learn a lot about approaching themes and mechanics from unique perspectives which will ultimately separate your game from others like it in the market. All this experimentation has another positive which is you’ll become a better designer. The more you practice and experiment doing something the better you’ll get at it, and game design is no different. But wait, there’s more! Being flexible with your design and experimenting will alleviate some of the anxiety you may have passing your design onto a publisher who will want to develop and tweak your game to fit their lineup.  http://bit.ly/2flzqxx One last note on designing with the core experience in mind; the experience your game creates is going to be somewhat determined by the heuristics held by your playtesters. Being conscious of this may help you decipher why your game may not be performing the way you want it too. For instance, you may have come up with a really cool bidding mechanic that works like regular poker bidding, but you always have make a bid at least once per round. This solution may have been useful to make players feel like they’re forced to do something they don’t necessarily want to do while also making sure everyone is involved each round, but anyone who has played poker will probably be very averse to this change and not enjoy the game. For those players it will be very difficult to get over those habits which will negatively affect their experience. Going against heuristics like this will be tough at best and so you need to be aware that they may be one of your few limiting factors to how you can manipulate a game to provide the core experience you’re looking for.
Before we go, we’ve got a few things to keep you up to date on. First off, Kevin is currently in New Jersey for Metatopia! It’s the first time either one of us will have attended the convention so if you’ll also be attending and spot him expect him to look a little overwhelmed. If you’d like to see what we’ve been working on, feel free to approach him and ask to play a game. Throughout the weekend he will be running playtests of our party word game Grumble. You can find it on the schedule under codes B188, B308, B566, and B724. Also, we’ve been working on organizing another project for the Toronto area that we hope to make an official announcement about soon. Stay tuned for more details! 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
6 Comments
 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  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  Our standard playtesting notes Good Day Internet! Today, we’re going to start diving into the massive (and massively important) topic of playtesting. We’ll start off with solo playtesting and get into the others another time. Before we get into today’s topic though, a quick recap. Last week, we left off with our first finished prototype. A bare bones, skeleton of a game that probably doesn’t look that appealing to the eye (which is right where we want to be). Let’s start off with the definition of solo playtesting. Solo playtesting is the process of playing through your game (multiple times) from start to finish by yourself. This will usually involve you playing as multiple players at a time throughout gameplay. During this time you will be making notes to adjust your rules and components after the playtest (we’ll discuss that later). So why don’t we grab family and friends who love and support us to play and skip the solo playtesting? The main reason we go through solo playtesting is that the transfer from idea to physical gameplay usually doesn’t go smoothly. There will be kinks that will need to be fixed and the process will also most likely be longer than planned and potentially frustrating. You should be familiar with this if you’ve built anything in your life, say like a piece of Ikea furniture. Solo playtesting is a way to get rid of some of those kinks so you can make your game run smoother and be more enjoyable. Basically, you want to do the prep work: knowing how your game functions (since that hasn’t been tested) and what makes it function, before trying to explain it and play with family and friends. Despite all of that being said, what we’ve told you to do leading up to the post is going to make some of the work easier for you. So don’t get mad that you’ve done all this work to make a prototype that probably won’t function exactly how you originally planned. Alright, so what are some of those kinks you are looking for when solo playtesting? The main things you’re looking for are: easy to understand (basic) gameplay, and reasonable playing time. Easy to understand gameplay ties in a lot with what the rules are for the game. This is part of the reason why we suggested previously you jot down your rules so you know what they are and can revise them. As you go through your playtest study how each mechanic and main actions function. Do they make sense? Are they easy to understand? Could you explain this easily to someone? In general, if you’re forgetting or don’t use a certain mechanic or action you need to reconsider how useful it is and if it should be in your game. When you come up with a solution, make sure you write it down in your notes so the changes are marked. This way you’ll remember what changes have been made when you finally explain your game to a public audience. The other main question you’re trying to answer is: is there any action or mechanic that can be taken advantage of? Which comes down to two things: can a certain mechanic or action be used to give a player an unfair advantage (get them close to victory very quickly, or locks in victory for them), and can a certain mechanic or action be used in a way that is counterproductive (just wasting time/too time consuming)? If you find yourself using the same really effective strategy each playthrough, or realizing the game isn’t progressing as it should, chances are you’re suffering from one of these two problems. This is another reason why it’s important to write down the results of your playtests and what changes you have made; this will help you decipher what went wrong, and what changes affected your game as such. Reasonable playing time will depend on your game, but usually we’re making sure that it doesn’t run well over the game time you were aiming for. Understand that because you are playing for multiple people it will be over your planned playing time. Just make sure it doesn’t take 2 hours to solo playtest your 10 minute filler game. The other parts to reasonable playing time is making sure that when the game ends it makes sense and that your game actually ends. You’re going to want to solo playtest your game multiple times to check this. If your game suddenly ends in 15 minutes for one playthrough, but also took you over 1 hour to play another time, something is probably awry. You need to double-check your victory conditions and mechanics to make sure the ending time is relatively consistent.  Solo playtesting of Pulled into Darkness revealed this draw situation happening every game. Not what I planned. Furthermore, check to see that your game will end. Just because the game ended for your solo playtests, doesn’t mean your game will always end. The way to test this is to look at any mechanic that sends gameplay backwards or does not progress it towards the goal and see if a player (or players) can do this infinitely in theory. Try to do it in a playtest and if you can, that needs to be addressed.
One last point about solo playtesting. In looking for all these things you’re going to need to solo playtest as different players. You can’t just play your game as you would personally for all players every time. You need to experiment a little with different strategies. This will allow you to get rid of more kinks and create a better prototype for others to see. That's it for this week. Next week we're going to show you how we went through all the steps we've talked about so far for my game "Pulled into Darkness". 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  The extent of my arts and crafts skills. 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).  Allysha made this one for us for "Pulled into Darkness" because she's more competent than I with software. 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
April 2017
Categories
All
|
RSS Feed
|
|
Copyright © 2016