 http://bit.ly/2bNy8eO Good Day Internet! Recently we’ve reflected on the journey of designing and developing Pulled into Darkness and we realized that a lot (if not all) of the success we’ve been having is directly related to playtester feedback. That may sound obvious, but in our case the feedback implemented didn’t require any refining. The playtesters told us how they’d like to see the game change, we did it, and it worked basically flawlessly. In retrospect though, it wasn’t just a matter of waiting for the right suggestion to come up to fix our game, as we had received feedback on these subjects many times before. We had tried the suggestions, it didn’t work and we moved on. What was new to us was realizing that every time after trying the first few implementations that didn’t work we no longer took the feedback into consideration as much as we should of. Furthermore, although we may have tried a few implementations of the suggestions we received, we stopped working at it relatively quickly and were complacent in the fact that it could not work nor was it a match for the style of game we were making. This was all despite the fact that we continued to get suggestions regarding these same topics over and over again. So this week we’re going to go over these mistakes in the hopes that they will help designers who may have also fallen into this trap. We’ll also give some information on the results of actually properly implementing playtester ideas, and give credit where credit is due; to the playtesters (who after all are usually right). But before we can give praise and reflect more on what we should have done, we’ll need to go over what we did wrong in implementing playtesters’ ideas/feedback in the categories of Special Powers, and Scoring and End Game Trigger for Pulled into Darkness.  http://bit.ly/2bggNsc Special Powers From the game’s inception and earliest playtests, players wanted special powers. Personally, we didn’t think special powers belonged in the game as we designed it with simplicity in mind. However, playtesters consistently asked for space/sci-fi themed special powers so we decided to give it a try. Our first implementation of unique special powers was the use of a separate card to be played on a single spaceship when it was (hopefully) most beneficial to the player. This implementation made the special powers practically useless and a distraction from the game for a few reasons. To start, each unique power was better at different stages of gameplay; for instance “Lasers”, which allowed you to shoot down a spaceship beside you, was usually best at the start of a round; whereas “Worm Hole”, which allowed you to teleport from one space to another, was much better in the middle of a round. For this reason, we weren’t sure when they should be allowed to be played without restricting player agency too much. To try and solve this problem we restricted the special power to a designated captain ship, doing so lead to a larger problem of once the captain ships were removed from the game (which could happen suddenly and unexpectedly) you could no longer use your special power. This only lead to more player frustration and solidified in our minds that special powers didn’t belong in our game. From that point on, when we received feedback regarding adding special powers we usually responded with we tried it and it didn’t work. Months later after consistently receiving feedback that special powers would be a cool addition, we started to question whether or not there was a way to implement them that wouldn’t ruin the game. After a suggestion from Peter Hayward, we decided to give it another try by adding two one-time use cards that could be used in place of a standard command card. These cards allowed a player to move first (instead of simultaneously with everyone else) and knock down any spaceship they ran into, which was a common special power suggestion. The result was the game gained a new level of strategy and more meaningful choices without a finicky system to resolve those new cards.  http://bit.ly/2bfavd0 Scoring and End Game Trigger Originally, Pulled into Darkness ended when there was one player left with multiple spaceships orbiting the black hole (who was declared the winner). Although this model was somewhat focused around player elimination, we thought we were okay because the game was relatively short (about 30 minutes). However, players (particularly those who were game designers) were not so happy with it. They also didn’t like how near the end of the game when there’s less spaceships that the level of excitement drops off dramatically and that the “Down” card (which forced you closer to the black hole and your ultimate doom) was frustrating and unnecessary. Based on feedback, we decided to try scoring to make it a little more interesting for players who only had one spaceship. Once again though, we implemented this idea poorly. Our first implementation included a scoring system where the further away from the black hole your spaceship was the more points you got, but we kept the same end game trigger of there being only one player with multiple spaceships on the board. It was quickly realized that this type of scoring system only made the problem of players not wanting to play their “Down” card more prominent, so we reversed the scoring so that the closer you were to the black hole the more points you got. However, keeping the end game trigger ensured that the game still fell flat. There still wasn’t enough going on at the end of the game so the scoring system seemed arbitrary and just didn’t feel right. So once again, we reverted back to the previous version and each time the scoring suggestion came up we basically shot it down with, “We tried that and it didn’t work”. Just like the special powers suggestion, the scoring suggestion came up many more times and it wasn’t until months later that we decided we were willing to give it another try. I brought the game to Protospiel Michigan where the scoring suggestion came up and once again I told the playtesters it didn’t work out. The next suggestion was to try it with a new end game trigger, which for some reason we never thought of trying. We then played a game where it ended when a majority of the spaceships had been removed from the board and you scored more points the closer you were to the black hole. Doing so made the gameplay a lot better and this was without the one-time use special power cards (which were actually added later). As I playtested it throughout the rest of the weekend, we started to receive comments that people wanted to buy the game without us even having to ask and were told at the Snakes and Lattes Designers Night to look for a publisher. When we did add the one-time use special power cards, it only made the game that much better and increased the number of playtesters who thought the game was publishable.  http://bit.ly/2bCJGlF Conclusion
We’ve previously discussed listening to playtesters and making sure to apply feedback, especially if it keeps coming up. However, we never really discussed in detail the idea that if you apply that feedback and it didn’t work that maybe it wasn’t because it was bad feedback, but that your implementation was poor. Reflecting on our journey with Pulled into Darkness we realized that we failed to implement feedback properly in the above mentioned areas and then didn’t continue to work on figuring out a way that would work. Our thought was that we applied the feedback the way it was presented to us and it didn’t work so we’ve done our job. We wrongly assumed that anyone who was suggesting the same kind of idea after the fact didn’t understand the logistics of applying the feedback or wanted the game to be something that it is not (which sometimes is the case). The work that we should have been doing to make those suggestions work ended up being done by our playtesters (which we’re very grateful for) despite it not being their responsibility. Looking back, we realize that this reflects poorly on us designers and is something we will be aiming to fix to make our games and our game design knowledge even better. Once again, we are very thankful and grateful to the playtesters who initially tried to tell us to try new things and helped us implement those ideas so that we have a game that is publish ready. We couldn’t have done it without you. 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
 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