![]() 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. 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
2 Comments
![]() 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 ![]() Good Day Internet! Now that we’ve gone through the importance of both mechanics and theme it’s time to discuss which one you’ll want to focus on when beginning to develop your game. Before we do though, I want to be clear that in order to make a great game you need to have a great theme and great mechanics that work well together. For that to happen you’re going to need to be developing both mechanics and theme simultaneously as soon as possible. When you’re at that initial idea phase and early development, theme and mechanics will probably be developed separately (and therefore the existence of this blog post). However, shortly thereafter you need to be constantly looking at them together (for example, does this mechanic match the theme? Does the theme make sense for what mechanics I’ve implemented?) throughout development. Furthermore, you shouldn’t rely on the fact that there are a small number of games where a fantastic/popular theme, without much consideration of mechanics, was highly successful (Cards Against Humanity, Exploding Kittens) or vice-versa (Dominion): it’s almost guaranteed that your game isn’t going to be one of those lucky ones. Unless you’re making an abstract game (in which case, you don’t have to focus so much on theme), you need to be putting in substantial effort into both mechanics and theme. So, without further ado, in the early stages of game development you should focus on developing your theme first. The reason for this is that theme gives your game direction, whereas mechanics are just how the game is played. Like we said in “Game Basics: Theme” your theme is your ‘why’ and it ties together the actions, game terminology, components, and what you do in game. You’re going to want to know what that is before you start developing your mechanics further (assuming you have any). Remember how we also said that most of your theme comes through the actual gameplay? So, if you start developing a bunch of mechanics and have no theme, that could cause some problems. Namely, how can your mechanics bring out the theme if there is none or it’s not clear what it is exactly? Additionally, in the absence of theme, mechanics are just a ‘beginning’, a set of actions, and an ‘end goal’ (ie. points scored, player elimination, etc). Those mechanics should be tying together (beyond being the way to play a game from start to finish) and they probably don’t because there’s no theme to direct them. That's why you need to have that theme (at least the backstory part) first, and then make your game. It’s where your players start in game, it's the start of an explanation of a game, and it should be where you start to develop your game. ![]() Let’s say, perhaps, you go the other way and develop mechanics before theme. What happens then? Well, developing mechanics before theme in game design is like creating a machine without a purpose. In the end you’ll have a machine that has all the parts it needs to work, but it won’t have any use. There’s also a possibility of a lack of a logical order of operations. In most cases, you could find a use or problem for the machine to solve, but most likely it won’t be very efficient at solving that problem. There’s a high probability that in order for it to be useful you’ll need to rearrange and swap out a lot of the parts. The same thing happens when you don’t develop your theme or ‘why’ (aka problem) before creating a game. You’ll have something that works, but it won’t be useful nor efficient. You’re going to want to develop your theme first so you don’t end up with a ‘machine’ that you’ll have to paste a theme onto (aka create a problem for it to solve). It’s not going to work out well for you. Lastly, I’d like to point out that this blog post isn’t about inspiration for game ideas, but rather it is more about the initial stages of game development. Your game idea can come from a cool theme, interesting mechanics, component restrictions, or whatever else; it doesn’t really matter in the long run. Besides, who am I to tell you where your inspiration should come from? The part that really matters is what happens after that. That’s the part where you spend your time trying to transform this idea into a physical game that someone can play. There’s a lot of work required to make that happen and, in the long run, making your theme your initial focus will make the design process focused and easier for everyone. That’s it for this week. Next week, we’ll take a closer look at the core of your game. 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! As promised, today we’ll take a look at the importance of mechanics in board game design. To start off, I’m going to give a more technical definition of mechanics for those who are that way inclined. The technical definition of a game mechanic is a set of actions that form a rule. It should be clear that game mechanics should also progress gameplay in some way. For example, the rule 'roll a die' entails the actions of picking up a die, shaking it up in your hand. and tossing it on the table. The 'roll a die' rule sums up of all those actions into a single game mechanic and the result will equate to a further action/forwardness in gameplay. 'Taking turns' is also technically a game mechanic. It’s the action of ending your turn and letting someone else go as defined by a rule (progressing gameplay by allowing it to continue). If you think about it, there are many different ways to 'take turns'. Play could pass to the left, the winner of the last round could go next, players could take simultaneous turns, or play could pass to the next player by some other rule. As you can see, there is a lot of variety in even the most simple game mechanics. If you want to dive further into simple game mechanics I highly recommend Rym DeCoster's "Mastering Game Mechanics" on Youtube (I may have slightly adapted their definition of mechanics for the purpose of this blog post). Personally though, I think that's enough of that, so let's move on to the more general definition and discussion. Put simply, game mechanics are your 'how'. It’s what you are allowed/required to do and when. It is also the restrictions you will put on the players as they try to achieve their goal. Those restrictions are defining what players may do and the paths they may take. In other words, it tells players what options are available to them and it's up to them to determine how to use those mechanics to achieve victory. Based on that, It should be pretty clear to see that your mechanics are going to determine whether or not your game is playable (can you play from start to finish in a reasonable amount of time?). It's also going to determine if you've made a game, or a set script because your mechanics are too restrictive or lead to one clear best path (making all other paths not worth exploring). When starting to design your game, start with only the main mechanics, or core mechanics, required to play the game. For instance, if you were designing King of Tokyo, your core mechanic would be the press your luck dice mechanism. If you think about it, that only allows you to do 4 things: gain victory points, gain energy, gain health, or attack. In the very beginning of designing, you'd probably only have attacking and gaining victory points because that's all you need to ensure the game can be played from start to finish in a reasonable amount of time (aka playable). If we apply the same principles to your first design, you're going to have to cut down on some of the more "creative" mechanics you want to include in your game. Chances are those mechanics are too complicated, too much of a hassle, or won't work anyway (sorry amigos). This will ensure that your game is playable and will allow you to be able to work out a lot of the kinks that would be too hidden if you had everything else you wanted to include in your game. It will also give your game direction, which is very important, and allows you to build out from a solid, working base. The last thing I want to talk about in some detail is the intricacies of simple mechanics, since their importance doesn't get as much attention as they should. They are called simple, so it's easy to assume you know how they work (I thought the same). The way I'm going to go about this is by going through an example of a basic game mechanic decision for a simple card game and then show how that would effect gameplay. The game mechanic decision we'll look at is 'play one draw one' versus 'draw one play one'. In 'play one draw one', players already know what they want to do when it comes to their turn. They also have ample time after drawing a card at the end of their turn to determine what to do next. In 'draw one play one', that new card drawn at the start of the turn may change what they want to do and slow down gameplay. This causes actual and perceived play time to really suffer and may have a huge effect on players' enjoyment of your game. However, 'draw one play one' usually works nicely in take that games because it gives a player who has been attacked the ability to do something, anything on their turn (and perhaps even retaliate). This example is pretty simple, but it's also something that casual playtesters (which is the majority of playtesters you'll originally play your game with) are probably not going to be able to identify and point out to you. So take it easy and take the time to figure out how to get simple mechanics to work, as well as work together, in a game before going crazy with everything else. It will help you to recognize what will work and what won't without having to play it a bunch times. This will save you time, headaches and make you a better designer. That's it for this time. Next post, we’ll take a look at theme and mechanics together and which one you need to focus on most when you start to design your game. 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! Now that we've talked about what you can expect, we're going to get into the basics of game design: theme and mechanics. Before we do though, I'd like to point out that League of Gamemakers published a blog discussing "The False Dichotomy" of Theme vs. Mechanics. It is a much more thorough analysis of the elements of a game and is definitely worth the read if you are inclined to do so. Despite this, we're going to stick with explaining the basics of game design using theme and mechanics because it simplifies the explanation without losing the essential content. Today we'll talk about the importance of theme and our next post will discuss the importance of mechanics. After that, we’ll look at them together and tell you which one you need to focus on when you first begin to design your game. Let's get down to business and discuss the importance of theme in game design. The easiest way to explain theme in board games is: it's the 'why'. The theme is the background story, the motivation and provides the context to what the players need to accomplish. It's how players understand the relationship between the components, mechanics and how they should act in game. For these reasons, you usually have to describe the theme of a game to new players before you even say one word on how it’s played (there are some people who will say otherwise). Therefore, it’s very important to think about this early on when designing in order to have an easy way of presenting your game to new and unfamiliar players (which is basically everyone). Theme is also important in the respect that you should always keep your theme in mind when designing a game. You should be constantly going back to what players are trying to accomplish and why as you design your game. When we say what players are trying to accomplish, we don't just mean the final goal. We also mean all those small actions that come from the theme and lead to victory. In Jason C. Hill/Flying Frog's 'Last Night on Earth', it's the scrambling to acquire weapons and equipment, running from zombies, and killing zombies. All those small accomplishments in game flow naturally from the zombie theme of the game. If instead you had to acquire different hats in order to ensure the circus show can go on, which will then chase away the zombies, no one is going to have a clue what's going on. Players won't understand what they are supposed to do, when, or understand what a component actually represents. ![]() Even in an abstract game, you’re going to want to come up with a light theme to provide direction to what you’re doing. For instance, Go (which quite frankly I’m surprised has a theme) is about life and death (yeah, Go figure). Every placing of a stone goes back to that life and death theme (in a very abstract way). The point is, if players don’t know why they’re playing your game or what they’re trying to accomplish, you probably don’t know either. You may think you do, but you probably just created a mess. The last thing I want to mention about theme is that your theme needs to come across mostly from gameplay, not by how much backstory you can squeeze into a rulebook or components. Look at the rulebooks for some of your favourite board games; chances are the theme/backstory takes up a couple paragraphs or less. This is because that’s all you really need in order to understand and "get into" a game if it’s designed with theme in mind. In Matt Leacock's 'Pandemic', you’re a disease fighting team trying to find cures to 4 diseases spreading wildly across the globe. With that, players are set. Sure, they’ll ask questions about what they can do, but what they can do all flows pretty naturally from the theme. The other reason most games have a small backstory is because gaming is about creating a unique playing experience that allows players to manipulate their environment within a set of rules. Gaming is not about limiting players to a set script. Players want choice, so don't write a two page backstory for your 10 minute filler game's rulebook because you'll limit your players and yourself in what you can include in your game. That's it for this time. Next post we’ll take a look at the importance of mechanics. 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
|