Roadblock is a series of articles where I interview other designers, developpers, and others involved in the industry, to do a deep dive into a specific issue they’ve dealt with in a project. The goal is to add concrete examples to the mass of game design advice out there.

JV: Today I’m sharing with you folks a discussion with Chris Anderson, designer of the Tempus series of solo games and host of The Board Game Workshop podcast. Today, Chris will tell us about an issue he ran into in designing the latest Tempus game, Tempus Infinitum.

Can you give us a bit of background on what the game is like, so readers better understand?

CA: All of the Tempus games are similar. They work like a roll and write, but instead of rolling dice you write down the day and time you start playing and use those numbers to populate the map with resources and obstacles, and also to determine your actions for the game.

Tempus Infinitum specifically has unique maps generated based on a player’s email address.

JV: That random seeding through the date and time is interesting to me. Why not simply go with cards or dice?

CA: The original game design idea that eventually spawned the Tempus system was to make a diceless roll and write. I wanted a game that required minimal materials to play, in this case just a single sheet per player and a pen. The Tempus idea came up as an option for solo play but worked so well I abandoned the multiplayer idea.

Now, the Tempus system is what makes the games stand out from other roll and write games.

JV: The number distribution in dates and times is skewed: no numbers over 3, 2, and 5 for the first digit of date, hour, minute, respectively, for example. How did you consider that in your designs?

CA: That’s the best part of the system. It’s like designing around weighted dice and gives a lot of opportunity that uniformly random dice don’t have. The numbers affect two things in the game: the setup of the map and the player’s actions.

The map is a 10 by 10 square grid. Since we only use day, hour, and minute we have 6 numbers to assign. Each of those is assigned to one column and one row. During setup, each of those columns and rows has an item that will be drawn on the map in the space dictated by the number. So if the first digit of the day is 2, the item in that column will be drawn in the second box down. Zero is always at the end.

Since, like you said, the first digits in day, hour, and minute are limited, this creates empty spaces that won’t get drawn in items. These empty spaces are what make the unique maps.

With 10 columns and 10 rows but only 6 numbers, there are also completely empty ones. The digits always go in order, but that still gives 210 possible arrangements for columns or rows. When you combine the possible columns with the possible rows you have 44,100 possible map layouts.

Each of these maps has a different arrangement of empty spaces. In previous Tempus games with only a single map I would choose the layout I wanted and add static items to the empty spaces. They could be obstacles, enemies, resources, or goals. With Tempus Infinitum, though, we are potentially using all 44,100 layouts. So the static spaces and the column and row write in items are arranged by each map’s random seed from a pool of 37 items with some restrictions. The arrangement of these items combined with the different map layouts is what gives us millions of possible layouts. Not infinite, but Tempus Very Large Number doesn’t sound as nice.

The other thing the numbers control is the player’s actions. Again, the unique aspect allows for some control. Each of the 4 actions is assigned a number range. Make a Road 1-2, Dig a Lake 3-4, Build a building 5-8, and use a building 9 & 0. Based on the statistical occurrence of each number in all possible day/times, each action is approximately equal in potential occurrence. But the first digit can only be 0, 1, 2, or 3 and 3 is pretty rare. So almost two thirds of the time your first action will be building a road. Building a road is the most critical action early on, because it’s the foundation to performing other actions. And again with the first digits for hours and minutes we have a restriction on potential actions that skews towards lower numbers and the more important actions of building a road and digging a lake.

So it’s specifically the missing numbers that create the setup and makes each minute a unique puzzle to solve.

JV: Very cool! So getting back to the whole point of this interview: What is the roadblock you ran into? How did you identify it?

CA: The issue with Tempus Infinitum is the variety of possible maps. In previous Tempus games I had a lot of control of how maps were laid out and could balance difficulty by adjusting the layout. Since Tempus Infinitum has to work with millions of potential layouts it’s much harder to control difficulty.

JV: Why is variability of setup particularly important to the game?

CA: Variability of setup is the unique twist that sets Tempus Imperium apart from the other Tempus games. The system has been refined through previous games, but offering every player a unique map makes it much more personal.

JV: Could you expand on that? Why is that worth the extra balancing issues?

CA: I’ve been working on Tempus games for years now and what continues to surprise me is just how much design space they have. Tempus Quest is 13 unique maps in a campaign, where what you do in previous episodes helps you in the future. It was designing those different maps that made me realize how many possibilities there are for the setup, even if you keep the exact same rules.

Tempus Infinitum is my attempt to use all of that potential in one game. It’s definitely an ambitious design challenge. And, at best, each uniquely generated map is no better than an individually designed map.

But, I think the ability to offer players a unique map that is theirs alone, that they can try and master and share with their friends, adds a level of community and metagame that solo games don’t often have.

JV: You coded a tool to help you for the setup: what did you use for that? What do you see as the pros and cons of the tool?

CA: I’m only an amateur when it comes to coding. I use Processing (https://processing.org) to create the individual maps. It’s based on Java and the main benefit is that I know how to use it. I’m pretty sure it’s not the most efficient method for what I’m doing though.

JV: How do you imagine it working in a final product, or will it just always keep that computer generated aspect?

CA: Currently I have to manually run the program to generate the maps. Ideally the tool would be integrated into a website so players can instantly get their unique map.

JV: So this will always stay a PnP? What pushed you in that direction, versus trying to publish a physical copy with 100 different setups in a block of paper?

CA: Yes, the plan is for it to always be a PnP. Since the main goal is offering each player an individual, unique map, it’s the easiest way to get those to them. When testing is done, I’ll set it up as a “pay what you want”. So if anyone would like to support the work, they can. But the biggest reward for me is having people play my game. So I much rather see a picture of a completed game on Twitter than make a few cents selling a pad of paper.

But, with millions of possible maps, most of which will never be generated for individual players, if people would find some benefit from having a printed pad, I’m not opposed to the idea.

CA: A lot of my game designs use combinatorics to generate a variety of states, but this is the first to use that in the design instead of just in the play.

JV: And how do they differ?

CA: When combinatorics is in the play, for example having a card game that works with multi card combos, an individual play will work out a certain way, but the next play will be different. So there can be some forgiveness in edge cases that are less than ideal.

When combinatorics is in the design, the generated game is all there is for that player. So a less than ideal edge case will always be less than ideal for the player that got it.

CA: I’m still in the process of solving the issue of balance.

In early versions I had a lot of variability which led to a huge variance in difficulty between maps. Some players would have 5 enemies to deal with and others would have 10. As I’ve gotten playtester feedback, I’ve restricted some of the variability so that maps have a similar difficulty. The trouble is getting the difficulty balanced while still having a huge variety of unique maps.

JV: And how do you contain the difficulty behind the scenes? Do you define more closely how much of each thing will appear, or do you go with a point system to evaluate how “positive” a setup is? (or anything else of course)

CA: In the first version, the item in each space was chosen independently, similar to a die roll, so my only control was adjusting the statistical chance of an item being chosen. This caused the huge variance. Now all the items are selected from the same list of 37 items, similar to a deck of cards, so only the arrangement differs between maps.

I’ve also added restrictions on where certain items can appear. Currently the restrictions I have in place limit only certain items to being in the write in spots or static spots. When it places items on the map it will always place an enemy after a farm. This increases the likelihood that enemies will be next to farms to start, increasing the difficulty. But still has potential to leave a space between them depending on the map layout.

A player request was to have a target score scale so players could tell how well they did. So a potential addition is to have a unique scale for each map based on its difficulty. So on an easy map, 150 is a great score. But on a hard map, 60 is great. This would be a great way to make all maps comparable. But it requires being able to accurately judge the difficulty of each setup automatically during creation.

JV: It feels to me like a variable setup is particularly important in a solo game, where you can’t rely on player interaction to make games play differently. What do you think of that statement?

CA: I think it is important for replayability. A solo game with a single setup is fine for a single play, like a puzzle or choose your own adventure. And could potentially get a few more plays if you want to fix mistakes and get a better score. But the interest to play drops off sharply. Variable setup makes each setup its own puzzle to solve while still rewarding skills and strategies learned from previous plays.

JV: Where else do you want to take the Tempus series?

CA: Once I get the map generation figured out for Tempus Infinitum, I’d like to make new ages for it. Currently it’s set in a vaguely medieval age with castles and farms. I can see making slight adjustments to actions and setting, like I did in Tempus Quest, and getting millions of new maps to play.

But my greatest hope for the Tempus system is that other designers will use it. So far I’ve heard of one designer trying to make a game with it, but I’d love to see what others can do.

JV: Is there a game that you think does this variable setup particularly well? One that you could point designers to so they can learn from it?

CA: Friday by Friedemann Friese. It’s a solo game where you work your way through a shuffled deck of benefits and threats. So each game will be a different order but the things you learn from each play about how to deal with threats will inform your future plays.

JV: Well thanks a bunch Chris! I’ve been thinking about trying and making a solo game during the confinement, and I’m sure I’m not alone in that situation: surely this discussion will be helpful to many a designer!

If you are interested in designing your own Tempus game, you can submit it to the Tempus Design Contest by May 4, 2020. https://www.venntikgames.com/contests/tempus-design-contest

You can listen to The Board Game Workshop and get more info on its annual design contest and design day at www.theboardgameworkshop.com

Peter C. Hayward on his Roadblock

Roadblock is a series of articles where I interview other designers, developpers, and others involved in the industry, to do a deep dive into a specific issue they’ve dealt with in a project. The goal is to add concrete examples to the mass of game design advice out there.

JV: Today I’m sharing with you folks a discussion with the bluest beard in board games, Peter C. Hayward! Peter is the president of Jellybeans Games, and the designer of awesome games such as Bugs on Rugs, Ninjitsu!, and Village Pillage. Peter and I talked about issues he ran into while working on his latest party game.

PCH: Hey JV! So I’ve been developing a party game called French Toast, and I kept running into this weirdly specific issue: the game only works when people go FAST, and as soon as I started blind testing it, people would go veeeery slowly and have a bad time.

JV: And can you tell us about the game? How does it play?

PCH: OK, so I am the Toastmaster. I draw a noun card and you have to guess what it is. You say a word, for example Car, and I will say whether the word is closer to French Toast or to a Car. Then you say another word, and I’ll compare the two, and on we go until someone finds it. You get closer and closer and closer.

The game works best when you quickly guess a noun, just rapid fire, guess-word guess-word guess-word, but people would just go “do I want to guess train? Oh, we’ve already guessed car, maybe it’s too close, maybe we should try and guess cabinet to open up so and so” and then the game just dies. People for some reason just start valuing their guess, acting as if they were limited (which they aren’t!), and then it gets boring. If I’m around the table, I can manage that, but learning from the rules people couldn’t get to that point.

Which also means that I wouldn’t have spotted that problem without playtesting. I blind playtest waaaaaaaaaaaay earlier than most people would, and way more often, so I got my rules out and tried to get as many people to learn it from the rules, because that’s how you learn the game when it gets to you!

JV: Does the game include a scoring system or is it just Win/Lose?

PCH: There wasn’t one originally, it was just whoever would get it would go for the next round. Eventually, I added a hint system to avoid situations when the Toastmaster would just get stuck over and over on just one word, and then there was this scoring system which was just however many hints you did not use are how many points you’d get.

JV: So there’s no limit to how many guesses you can take? There are no incentives to use fewer, they truly don’t have any real value, but for some reason players assumed there was? If it takes you those 30 seconds to think of one word, you could have just blurted out 10 words during that times and gotten a lot more information.

PCH: Exactly. You have to treat your guesses as disposable. It progresses the game so much faster.

JV: And so why do you think players assumed that those guesses should be used sparingly?

PCH: Part of it is that the game would go around the table with players taking guesses, so after your turn, in a 5 player game, three people will go between every one of your guesses, which makes you not want to waste that shot.

That being said, if everyone goes fast, your turn will come back in 15 seconds, and so you don’t care about “wasting” it. However, it’s a vicious circle where if one player slows down, everyone starts cherishing their chances more, and takes more time, and so gaps between turns increase, and so on.

JV: That makes a lot of sense. Once you realized that problem, if we were to go step-by-step, what did you try?

PCH: So the first impulse of any game designer is of course to blame the players. “These players are dumb, other people will get it!” But the thing is, especially with a party game, it needs to be accessible. If anyone plays it wrong now, it means someone WILL play it wrong. And I say “wrong”, but the game is at fault here, not the players.

So my first attempt at a fix was to brute force it: I literally wrote in the rule “Go fast”, “Guess quickly”, “Don’t think about it too much”, “Don’t value your guesses”, but no matter how many times you write it, it doesn’t mean people will do it, as nice as that would be.

The next thing I tried was grouping people. If you play with 9 players, that’s 8 guessers, and so you have to wait for 7 people to go before you would, and that’s way too long. So I just made pairs, thinking it would just half the time between guesses. The problem is, suddenly, instead of being a problem some of the time, it became a problem ALL of the time. People now HAD to discuss their guesses with their partner: “should we say this?”, “what do you want to say?”, which dragged it out even longer. I tried the opposite, splitting them into 2 teams instead of teams of 2. It was the same problem, but you would now discuss by committee, and a team of 4 takes a lot longer than 2 teams of 2 as it turns out!

I went back to individuals, and I put a timer in, and you could take as many guesses as you wanted in that 30 seconds. That meant that you never were waiting more than 30 seconds times the number of other players, and you were incentivized to go as quickly as you can: perfect! However, people would never use the second half of their timers, because as you get closer, you’re helping your opponents, and then it won’t get back to you. They’d literally just wait for their time to run out, and you don’t ever want people who deliberately DO NOT play your game.

At that point, I went back to teams, but with that 30 second-timer for the team as a whole. People would then get cranky at their teammate if they took any amount of time, or, if they shared that time anyway they wanted, one person would often end up hogging the spotlight and take all of the guesses themselves, both of which were pretty terrible.

Then I also had another problem I wanted to solve: you know how in Codenames, you play a game, and then go again with the same teams, changing the Spymaster? Well I never did that! I always played every game as separate, switching up the teams, and I planned on French Toast being like that, with the Toastmaster a neutral referee in the affair. However, most players would play round after round with the same group, and so the Toastmaster felt an obligation to “their” team. The shared Toastmaster caused this unforeseen social problem, because players were thinking of it as a team game.

The next move was just making it a pure coop. Anyone can guess, as long as you don’t guess twice in a row. People responded very positively, I was really surprised. Some people are like me, they just want to spit out answers, but some people like to sit back and think about it, but when they jump in it’s something that really saves the day.

That really worked, and actually the coop version will be in the box as one of the modes, but I found myself missing the competitive nature of it. I also found that as everyone was working on the same time, people would get stuck more often, and what you get stuck the game just stops being fun. There was something about taking those 30 seconds off to let the other team go that would give you some distance and un-stick you.

Recently I was at a con, I sat down and said “I want a team vs team mode, you folks are designers, make this work for me”. And it was very simple, they just had two Toastmasters, one for each team, shared word, and I was CERTAIN it wouldn’t work-if I think Radio is closer to Car than Train, doesn’t mean that you do, and so we’d just be fighting for direction. For some reason, that didn’t ever happen. I kept the same rule from the coop where you can guess in any order, as long as no one guesses twice in a row. So far, that’s the version of the game that will go in the box.

JV: What about the Toastmaster? Did you have to push them to go faster at all? I feel like I’d take forever on those, plus with the stress of everyone staring at you.

PCH: So interestingly, them hesitating is interesting. When they’re stuck, when they’re thinking, it becomes fascinating for those who are watching, because that hesitation is telling you something. Maybe those are two very good guesses, or two equally poor ones, but it’s information. It’s only a problem when the guesses are slow, because that is not progress.

Also, people tend to give answers faster than they take the guesses, making those hesitations even more interesting.

JV: If another game designer reading this was struggling with players who aren’t playing the game in the most fun way, what would you suggest?

PCH: So that’s something that can happen in a party game or in a heavier strategy game, but it’s really about figuring out what the fun part is (in my game, play it fast), and then “Game design is incentive design”. In the old system, players were incentivized to value their guess, because they personally only got one of every 4 or 5 or 10. To incentivize going fast, I added that timer, and removed the rigid turn structure, and suddenly you don’t have a reason to go against the fun.

In a party game especially, it’s less about throwing points at them, it’s really about the social dynamics that come up, like pressure and attention and politeness. Incentive becomes a more nuanced concept then.

I had a similar problem in Scuttle!, my first released game, where players would forego special ability cards and just focus on big point cards and win. When I worked on Ninjutsu!, which is the second game in the series, you win by having big cards in front of you at the start of your next turn—meaning that now, it’s not just about playing those cards, but timing it accordingly.

JV: Well Peter, this was amazing. I’m in awe of every that goes in this process of designing a party game. It seems to me like you’ve perfected mind control, and have decided to use your powers for good!

French Toast will make its way to Kickstarter soon, but Peter does have another party game on it right now: Night of the Mummy!

Roadblock is a series of articles where I interview other designers, developpers, and others involved in the industry, to do a deep dive into a specific issue they’ve dealt with in a project. The goal is to add concrete examples to the mass of game design advice out there.

JV: Today I’m sharing with you folks a discussion with Jay Cormier, half of the design team behind Belfort, Junk Art, and In the Hall of the Mountain King, and now founder of Off the Page Games! Remember when Sen-Foong Lim talked about designing MIND MGMT? This time, we’re switching it up a bit as Jay will describe issues he ran into as a first-time publisher while working on that very same game!

First, can you give us a bit of background on the game at the stage where you ran into the issue?

The game is a one vs. many game, in which one player will secretly move around on their own hidden map, while the rest are moving around on the big board, asking questions to deduce the one’s whereabouts. The problem came up as soon as I became a publisher of this game. When we were the designers we actually said, “Oh that’s the publisher’s job to figure that out!” Little did I know that I would be that publisher!

JV: What was the problem, and when did you first encounter it?

In the game, when the rogue agents ask a question to the one recruiter, the recruiter answers if they’ve been to any location with the requested feature (each feature appears 5 times on the board). If the recruiter HAS been on a location with that feature, then they place a Step token on one of those locations. But if the recruiter has not been on a location with that feature, they say no….aaaaand….that’s it. Or so we thought. While playtesting the game we realized that players wanted some way to keep track of this information. In a deduction game, not getting a success can sometimes give you more information than getting a hit!

Example: If an agent asked the recruiter if they have ever been to a location with a Subliminal Billboard and the recruiter says they have NOT, then that’s a lot of information! This means that the agents know 5 spaces on the board that the recruiter has NOT visited up until this turn number (there is a time track off to the side to know exactly which turn it is).

So we started coming up with some ideas. Maybe one of the agents gets a notebook and that player can write notes down on a restricted size of paper. This didn’t really work because it wasn’t intuitive and players would forget — either to write it down, or to refer back to it later. Then we thought, what if the players also had a secret map? A duplicate of the board that was also dry erasable, so they could make notes on it. This was maybe a bit better, but still, only one player could really look at it at a time, and so it would be forgotten.

So then around this point is when I became the publisher of the game, and now I had to figure out how to do this! For awhile I was thinking I would have numbered tokens that would be placed on the board, possibly fitting into grooves or holes in the board. This proved to be costly as well as fiddly since there would need to be so many tokens. Also, it wasn’t versatile enough since it couldn’t say exactly what a player would want to say.

And that was probably the ‘a ha’ moment. If we want players to ‘say’ whatever they want on these tokens, then maybe these tokens need to be dry erase. We tried giving players dry erase tokens to use, and wow — what a difference! The game really came alive. Now all players could ALWAYS see the information that they have collected. No longer was the game about remembering information about where the recruiter had been or had not been to. Now players could see the hits and the ‘misses’ on the board, and this really helped the agents narrow in on the recruiter’s path!

To clarify, when the recruiter now says that they have NOT been on a Subliminal Billboard, the agents then write out “1-8 X” (where 8 would be whatever the current turn number is) onto 5 different dry erase tokens (which we humourously call, Mental Note Tokens), and place on on each location that has a Subliminal Billboard. For the rest of the game, the agents can now easily see that the recruiter hasn’t been on those 5 spaces up to turn 8!

There was another similar issue about components. It was with our Step tokens. Originally we had 16 different Step tokens – each with a number from 1 to 16. When the Recruiter placed a Step token onto a location, they had find the Step token with the correct number (the number that matched the turn that they visited that location) on the bottom and then place it in that location that they have visited. I tried a bunch of different ideas, and used some Facebook groups to brainstorm how to solve this (maybe it was a plastic token that had a hinge that folded out to reveal the number inside it). Once we came up with the Mental Note tokens we realized we could use these for our revealed Step tokens as well.

So now we just needed generic Step tokens that didn’t have a number below it at all. Then when that Step token was revealed during play, the recruiter would announce which turn they were on that location, and the agents would use a Mental Note token and write that number on it. Worked perfectly and was way less fiddly!

JV: For a designer who does not intend on self-publishing, how do you think a publisher would react to a game requiring dry erase tokens or boards? We’ve seen a few of them recently –Silver & Gold, QE, Just One… As a publisher, would you see it as a plus or as a pain?

There is a pain side to dry erase (finding markers that don’t dry out too quickly, responding to numerous customer issues about dried out markers!), but I think the idea is — whatever is the best way to make the game work in the most functional and unique way possible. The game needs to be functional first and foremost. If the dry erase isn’t necessary and is only a nice-to-have, then I’d question it too. But if the dry erase is 100% needed to make the game work in the most efficient way, then it makes sense. It’s more cost effective and more environmentally friendly to use dry erase instead of tear-away pads that you’d use and then discard.

JV:We often talk about components in terms of table presence, but here those tokens are really mostly about making the players’ lives easier, taking a process that was annoying and forgettable and making it simple and straightforward. What would be your favorite component that just makes players’ lives easier in another game?

Great question. Can I say Game Trayz? Any time they’re involved in a project I get excited because they have such an amazing eye for functionality and improving the playing experience. The setup time is always reduced as you don’t have to open numerous baggies and dump out resources or tokens, and the functionality is often improved, while table space is preserved. For In the Hall of the Mountain King, Game Trayz make setting up the game super easy! All the tunnels are in this tray, all the resources are in this other tray! The Great Halls are stored in the bottom tray – but then they actually stand up in the tray so you can see which ones have been taken and which ones haven’t. Clever!

JV: Before stepping into the shoes of the publisher, how much would you try to tackle those kinds of component-based issues, whether before a pitch or working with a publisher on solving it?

If we could come up with some sort of component that was eye catching and helped get publishers excited, we’d do it. For Junk Art, we had to make all the unique pieces, so it had to be impressive and work immediately. For Akrotiri, we made little boats that held the resources as you moved them around. Our goal is to make the components and the prototype functional to ensure the game can be played as easy as possible. If the Akrotiri boats couldn’t carry the resources, then that would have negatively impacted the experience as you would either have to place them next to your boat or come up with some other solution.

JV: Well thank you very much Jay for this. It’s a very different perspective when we tackle those issues from the perspective of a designer of your pedigree who self-publishes. You brought up many good points for me to reflect on. Thank you and best of luck with the MIND MGMT Kickstarter!

In addition to the MIND MGMT Kickstarter, Jay runs a series of videos about self-publishing which are fascinating, and great insight about what it’s like to launch a business in this industry.

Roadblock is a series of articles where I interview other designers, developpers, and others involved in the industry, to do a deep dive into a specific issue they’ve dealt with in a project. The goal is to add concrete examples to the mass of game design advice out there.

JV: Today I’m sharing with you folks a discussion with Daniel Newman, designer of Dead Man’s Cabal, Rolled West, and Ahead in the Clouds.

JV: So Daniel, what game are we talking about today?

One of the games I spent a good portion of 2019 on was called Nebula, and then later The Well. It started with an idea for an action selection mechanism that I came up with while driving to Granite Game Summit. It involved a tray for 8 action tokens with a slider to select which actions you can do that turn, but depending on what ring of the board you were in you were limited to 4, 3, or 2 actions. I thought it would be cool to have a game where your position on the board would determine your effectiveness, with the fewer actions gaining you higher value rewards.

The first thought I had thematically was mining an undeveloped Nebula. I came up with a couple of generic resources (gas and minerals) and structures needed to harvest those, and actions revolving around moving through the nebula, building structures, and using those structures. It was…fine. I had a couple of people in my playtest group who said they enjoyed it but it didn’t really feel like it was doing anything special. I put it away for a bit and then had an idea to rework it, using the same general idea but with a hand of cards that cycled similarly to Concordia, and rethemed as spelunking in a cave system called The Well (because it was 3 layers of concentric circles). I thought it was more interesting and definitely had a better table presence. I generally got a better response with this reworking in the group as well, so was feeling pretty good about it by convention season.

JV: What was the problem, and when did you first encounter it?

I thought things were going along nicely, that it was pretty much ready to pitch. I showed it to a publisher at BGG.con and it was a disaster. It didn’t play anything like I thought it should. Things I thought were super clear were not. The publisher I was showing it to seemed angry and agitated for the entire game.

I realized that so much of how I wanted it to be played had been internalized by my regular playtest group – they had all played it a bunch and were just ignoring the obvious problems with it because they were familiar enough with the systems. It felt like it was smooth because of familiarity not because it actually was.

Because it’s so easy to bring things to this group twice a week, i don’t usually seek testing outside of the group.

JV: How did you handle the situation with the publisher?

We wound up finishing the game, as it was, and then I apologized for the experience being so bad. This is someone I show games to regularly so I was a little surprised at his reaction, but it just had a number of things in it that he really doesn’t like in games. He assured me that it wasn’t me personally that he was upset with. He’s someone whose opinion I very much respect, so seeing that reaction really convinced me it was time to shelve this one.

Not really. I tend to have a pretty good sense of whether or not a game is working, despite what feedback I’m getting from testers. I think I just really wanted this one to work even though it was never really feeling like it was coming together. This was also an unusual one because I tend to use an existing game as a starting structure and base my design on that – obviously things change pretty dramatically pretty quickly, but that tends to get me going much quicker and makes it so I don’t have to reinvent the gaming wheel every time. When I did the ground-up reworking as The Well, I used a couple of games as models for the systems I wanted to use, but it still never came together properly.

JV: Can you talk about the process of solving it? What worked? What didn’t?

Honestly, I never really solved it. I’ve shelved it indefinitely. Sometimes it’s the right thing to just put it aside. Maybe I’ll come back to it, I probably won’t. I have at least half a dozen games on my prototype shelf that I just decided wasn’t worth working on. There are a couple of nuggets of goodness in them, but I had another idea I wanted to work on and just didn’t want to devote more attention to this design that wasn’t working out.

JV: When did you decide to let it die? Did you try some stuff before then, or did that one pitch taint it so badly it turned you off the project entirely?

I’d been trying lots of different things over the life of it and nothing was really feeling right. The bad pitch was the nail in the coffin. I had scheduled a pitch meeting for it with another publisher later in the week and cancelled it because I just no longer had confidence in it as a game.

JV: And how do you avoid that problem with other projects? Have you changed your way since or was it just the exception?

This was actually very recent, just a few months ago, and one of the last games I pitched. I’m still mulling over exactly what went wrong in the process, as I had never had this happen before. I think I’m just going to be more aware of how many different people play my games before I bring them to publishers to show.

JV: In general, what do you think are the Pros and Cons of having a small but regular pool of testers?

Obviously it’s great to be able to get your design on the table super frequently. You can make a lot of progress in a short period of time, especially in that early stage when you’re constantly iterating and making big changes. If it’s a group that meets twice a week, like mine does, you can also not feel terrible about skipping one or two now and again because you know there’s another in just a couple of days (unlike groups that only meet once a month, in which case you’re going much longer between tests).

On the down side, you wind up testing with the same people over and over again and you can develop a meta where people generally understand the game and only slightly adjust to the new tweaks every time and are playing generally the same way. You just don’t get as much variation in approaches to the play and can miss huge problems because people get too comfortable with the game.

JV: How did you develop that “small but regular” pool?

I happened upon it kind of by accident, actually. This was a group that already existed and was meeting about once a month before I joined and started meeting once a week around the time I started attending. There were some fairly well known designers as part of the group, who I didn’t know when I joined, but later found out they had put out some fairly popular games. The group really started to flourish when Gil Hova (one of the aforementioned designers) took the reigns and started spreading the word a bit more. A lot of it was just due to better organization and finding a better, more reliable place to meet – the open seating at a Whole Foods, as a matter of fact, one of the few large semi-public spaces in NYC.

JV: You talked about usually starting from an established game: how does that usually happen? I have this list on my phone of games I want to “fix”, to design a different game based on the same central mechanism. I usually love half of the game, and hate the other half with a passion. How do you handle that?

It’s a bit different for each game but lately it’s either “I really like this game but I don’t like how ‘x’ works, so what if I take this mechanism and do something else with it” or “I have this theme that’d be fun to make a game around and I really like how ‘x’ does it, so I’ll just borrow that and change it up and use that as a starting point.” Usually it’s some sort of combination that happens simultaneously. How much I borrow or start with really varies depending on what I need and what else I have in mind. For example, the game I’m currently working on ostensibly borrows the upgrading of tiles from The Taverns of Tiefenthal but now that I’m a few iterations in it doesn’t really feel that similar. The rest of the game is pretty remarkably different.

JV: Well thank you for your time Daniel! You made a few very good points about varying testers, saving face after a bad pitch, and starting a design from an established game. Aside from being a bit of a bummer, I think you also brought up an interesting, under discussed aspect of game design: sometimes, you just have to admit defeat.

In addition to game design, Daniel Newman is sometimes on Twitter. [/sarcasm]

Roadblock is a series of articles where I interview other designers, developpers, and others involved in the industry, to do a deep dive into a specific issue they’ve dealt with in a project. The goal is add concrete examples to the mass of game design advice out there.

JV: Today I’m sharing with you folks a discussion with Carla Kopp, owner of Weird Giraffe Games and publisher of Dreams of Tomorrow, Fire in the Library, Big Easy Busking, and the project she wants to talk to us about today, Tumble Town!

JV: First, can you give us a bit of background on the game at that stage?

I had just recently signed Tumble Town from the designer, Kevin Russ. He’d only been working on the game for a few weeks, but I could immediately see the potential of the game. Tumble Town was always a town building game set in the Old West, but initially, it didn’t have any engine building or spatial puzzle aspects. Just simply building a town out of dice in the West.

JV: What was the problem, and when did you first encounter it?

The end game of Tumble Town was an issue at the start of the design process. Kevin had made the game a specific number of turns and I had never liked that in games. I really enjoy when I don’t exactly know when the game will end and when my choices in the game can make it go on longer or end it early.

Every game has to end in some way, but each game is different and has different actions and components that can lead to the end game happening. Tumble Town needed to go on long enough that players could build up an engine and feel successful in doing so, but I didn’t want the engines to get too out of hand where it meant that you had only one real path to victory.

JV: Can you talk about the process of solving it? What worked? What didn’t?

The first idea was supposed to be a fix of two problems; adding in dice mines. For the dice mines, there would be dice that you didn’t have to roll that you could take if you took a building plan from that specific row. Having dice that you didn’t need to roll meant you could plan your turn a little more and the game would be a bit less random. When two dice mines run out, then the game would be over.

The dice mines worked to solve those two problems, but they introduced a new problem; players were confused on what dice to roll and what dice not to roll and would often forget or do the actions backward. I try to make games as intuitive as possible, so this definitely was something I wanted to solve.

JV: So did you go back completely on the non-rolled dice?

Yep! There’s no dice that you gain that you don’t roll. I found that it’s so much easier to get players to roll the dice, if all the dice have the same rules and are treated the same. Making things easy is definitely something I prioritize.

JV: What else did you try?

The next solution was to use Plan End cards. These cards would be placed under a specific amount of building plan cards based on the player count and the game would end if two of the plan end cards were visible. This worked better in that players weren’t confused on how things worked, especially since the Plan End cards had the game end trigger written on them. However, the problem with the Plan End cards was that the game end was very variable. If players all took from the first row, then went to the second row, no one ever got to the third row of cards. I like when games can end early, but not when players haven’t experienced a third of the game. That’s a bit too early.

The solution that actually got a good end game was having the dice supplies run out. There’s four different kinds of dice, with gold associated mainly with level three building plans, brown with level one, and gray and black both with level two. With two colors for the level two building plans, it meant that even if most of the players did focus on level one and level two buildings, the game would only end early if the players someone only went for black OR gray buildings. As most players tend to base what building they want on other factors, usually the gray and black dice are taken at about the same rate and the end game is triggered when the gold and brown dice run out.

JV: So both of those last two options give players some control over game length, but an unusually short game is now something that skilled players do on purpose, rather than new ones doing by mistake?

Yep, that’s exactly right. I think it’s more interesting as I always like for things to happen when players deliberately choose to do something, instead of when they don’t realize that they’ve done something. If I want to try to rush the game, if I succeed, I’m more happy with the experience, even if I don’t end up winning, as the plan I had worked out. I also like when there’s several different strategies in games, as you now have a strategy based on a long game, average game, and a short game. Players will have to play a number of times to see what works best for each game length.

JV: When working on end game conditions, what do you set as a goal? Do you aim for a specific length of time? Do you aim for a specific moment in-game? Do you base it on the game arc?

I usually try to make the game less than an hour and also for the game to end before players want it to end. If players are still really engaged when the game ends, they’re way more likely to play again than if the games ends a turn or two after a player is bored of it.

For Tumble Town in particular, I wanted the game to end after a new player can build a level three building (the level with scoring conditions based on the other buildings in your town) and still get a chance to build another building or two which will gain extra points based on the level three building they built.

JV: How do you feel about “play one final turn” in games? Do you default one way or the other when you design?

I’ve done both! In the past, I’ve usually done equal amounts of turns and finishing out the round. Recently, I’ve tried where all other players but the player who triggered the game end gets another turn and I really like that for games that are based on player count. It means that you have to be in the lead to trigger the game end, but you might not end up the leader after everyone takes their last turn and any hidden scoring is added.

For Tumble Town, I went with finishing out the round, as having two colors of dice run out means that half the buildings most likely can’t be built and the other colors of dice might also be close to running out so even having an extra round might mean that no one can do anything, unless they have stored dice.

JV: Personally, I usually push off designing an end game trigger: I’m not planning on finishing the first few tests anyway, so why bother? Are you the same way? If so, do your testers also complain about not finishing the game?

I usually have a non ideal end game trigger in the beginning; either a number of rounds, point value, or a deck running out. Sometimes the end game stays, sometimes it doesn’t. For the very first test, I might even not tell players what the end game trigger is until we play a few rounds and I can kind of see where the game is going.

JV: Can you think of a published game with a particularly well-designed end game trigger?

Rajas of the Ganges has a really great and unique end game trigger that I love. There’s two tracks in the game, money and points. When one player’s markers cross, it triggers the end game, so you can focus in one aspect, the other, or try to do both simultaneously.

JV: Well thank you for your time Carla! I think that knowing how to end a game is a difficult skill that is much about nuance, and I’m sure sharing your experience will help many others!

Tumble Town is currently on Kickstarter! If that sounded interesting, go back it here!

So this is the first post in what will hopefully become a weekly series of interviews with more established designers. In each episode, an established designer will come and talk about a Roadblock they’ve run into with one of their designs, how it showed up, how they identified it, and the process of fixing it. The goal is to give you specific examples of the process of designing a game, and ideas of what you can do when faced with similar situations.

Today I’m sharing with you folks a discussion with Sen-Foong Lim, designer of so many games, such as Junk Art, Belfort and Akrotiri, just to name a few, and fellow Canadian! Sen is also the first ever recipient of the James Mathe Mentorship Award!

SFL: Hey there, thanks for having me! Jay and I have designed a ton of games together and we’ve got another one coming out soon!

JV: Awesome! And this one I’m really excited about! First, can you give us a bit of background on the game you want to tell us about today?

SFL: The game that’s been on my mind (no pun intended) recently is MIND MGMT. I co-designed the game with my long-time partner in crime, Jay Cormier, and the creator of the comic book of the same name. Matt Kindt is a New York Times’ bestselling author, comic book writer, and artist. He’s a force to be reckoned with!

The comic that the game is based on tells the tale of secret agents who work under the assumption that they are saving the world. They quickly find out that their organization, MIND MGMT, may not be everything it seems to be on the surface. A group of agents go rogue and try to bring down the organization from the outside. The game tells the take of these agents trying to stop MIND MGMT from recruiting enough agents to follow through on their diabolical plans. It’s a one-vs-many hidden movement game with a system that allows the game to adapt and change over repeated plays. Did I mention that these secret agents have psychic powers?

MIND MGMT is going to Kickstarter in early March 2020. This is the first game that Jay will be self-publishing under his “Off The Page Games” imprint, so we really needed to get it right!

JV: Secret agents with psychic powers sound like an incredible game right there! Now, what was the issue you ran into, and when did you first encounter it?

SFL: The real problem was how we had tested the game – we had primarily used the same 2 groups for multiple playtests. As they got better at the game, they wanted more challenges and so we complied!

And this was a huge problem.

We poured our hearts and souls into this game which resulted in it being overdesigned. There were so many player powers and extra bits and stuff that we had built into the game that players who had never played it before felt overwhelmed by the sheer volume of options they had. They were paralyzed by all of the options.

We actually broke Matt Leacock’s brain during one of the playtests. He was just overwhelmed by all of the possibilities in the game. To have a designer the calibre of Matt give us that feedback was really powerful. That told us that we had swung too far in one direction, and made us take a step back to reflect upon what had happened to the game as we developed it.

JV: Was there something about the game that pushed you towards testing with the same group all over again? Or just happenstance?

SFL: We just got comfortable in our groove, with our testers, and we (looking back) probably didn’t want to teach the game to new players again and again. We were also likely in the brainspace of “more is better!” without realizing the detrimental effect too much content would have on new players who were just trying to grasp the basics.

Jay and I live in different provinces and we both have playtest groups. We thought that would be enough diversity but we failed to recognize that skill creep is a thing. To go along with this, we can turn to the psychology of meaningful engagement as demonstrated by Mihaly Csikszentmihalyi’s concept of flow.  Csikszentmihalyi states that as a persons’ skill in an area improves, they require the challenge to rise accordingly or they may disengage from the task. Applying this to game design, what was happening was that our players were getting more skilled in the logic and deduction part of the game and so they needed more moving pieces to keep the game interesting for them. You can see this in many games – the constant influx of new cards in Magic: The Gathering is a great example where it is phenomenally difficult to understand ALL of the cards EVER as a new player, but experienced players clamour for more because they like the game and new cards maintain their engagement level.

JV: Is there something about the game that made it more susceptible to that overdesign?

SFL: In this particular case, logic and deduction games require skills that you can learn and improve upon with repeated plays, especially if you play with the same group. So as the Agents learn how to use their psychic powers to improve their chances of capturing the Recruiter, the Recruiter feels like they need more tools to combat them.
We didn’t think about the product in terms of a long-term thing over many plays. We just kind of “thought vomited” all of the ideas we had into the box and that was what was overwhelming.

JV: Did that overdesign lead to anything useful? Were you able to keep some of that content?

SFL: Oh yeah, we scrapped nothing. The overdesign wasn’t in the content, it was in the content delivery. In fact, the way we changed content delivery allowed us to develop even more content because it would have less risk of being overwhelming.

JV: Can you talk about the steps that you took between figuring out the problem and finding the right way? What did you try that didn’t work?

SFL: There was a lot of gnashing of teeth and lamentation. A few tears may have been shed. After we had our pity party, we stepped back and took a good hard look at the game. The game was awesome. It was just too much all at once. We really wanted to keep everything we had spent so much time working on, but knew that we couldn’t expose players to it all at once. We thought about expansions, but didn’t like the idea of people having to buy more things to experience the game as we had fully conceived it. We wanted to give people all of the content, but not all at the same time. It had to be doled out in the right amount, each time.

The massive amounts of content went from being a design bug to being a design feature once we figured out how to deliver it all in a way that made sense.

JV: What was the right way to deliver that content then?

SFL: Rob Daviau had just shown us the power of Legacy games with Risk: Legacy and Pandemic Legacy (co-designed with the aforementioned Matt Leacock). We didn’t want to make a Legacy game, so instead we took a different tact by asking a different question:
“What if the game changed between games based on who won or lost the last game but in a non-permanent and customizable way?”

We wanted players to be able to reset the game should they be playing with a new group. We also wanted players to have some control of their choices in terms of what to add to the game the next time they played.

So we came up with the Shift System!

The Shift System is a little bit like Rob’s Legacy System in that there are things that you unlock over the course of the game. It’s a system in which the team that lost the last game gets to pick advantages for them and disadvantages for their opponent. Players track their victories and losses, so the more losses a team has, the more advantages they can give themselves / disadvantages they can give their opponent in future games against an opponent that trounces them regularly. In that way, it can help balance games for players with differences in skill due to age or ability.

JV: What advice would you have for designers to identify these overdesigns before they go too far?

SFL: In general, it’s all about testing and finding the fat.

Test your game widely. Test it with people who’ve never played it. Have a new team learn your game without any input from you except the rulebook. What you’re testing for if you think you’ve overdesigned your game is looking to see if people can’t make a good decision because there is too much to process (though, sometimes, that is intrinsic in a design – see Space Alert).

Things that need to be cut often appear to me in these forms:

– Rules that are forgotten or played incorrectly by players

– Rules that take longer to explain than they’re worth

– Rules that drive the game procedurally but are not a decision point

– Conditions that are passively triggered versus actively engaged

– Components or rules that are underutilized or have low impact.

JV: And once the overdesign is identified, how would you advise a designer to deal with the problem?

SFL: Some of this is preparation, some of this is mindset, some of this is testing

In terms of preparation, keep versions of your past games as well as documentation about your changes. The changes themselves are important – the rationale as to why you initially made the change may be more important, though. Your rationale for change will guide you in how you might tackle the problem from a different angle – the problem likely still exists, it just needs a different solution. You may also, as you alluded to above, have to roll back to a simpler version because it was, in fact, better!

In terms of mindset, the old adage of “kill your darlings” is echoed by many because it’s true – you need to be flexible enough to see your way around problems to find new solutions and sometimes that means removing something entirely. To ease the pain of that loss, remember that you can often keep things you discard for later use!  If something does not support the primary hook of the game or the overall experience… cut it.

Remember: less is often more.

In terms of testing, you not only need to go back to the drawing board, but you’ll need to test your changes again. You cannot assume that things will work. You need to put the new implementation through its paces. Often times, you’ll also find that players are naturally efficient and will make new sense out of your game that will streamline some of the processes for you. If players almost always do B before A because it makes sense to them in practice, go with it!

JV: Well thank you Sen! I do feel like overdesign and designing in closed groups are a kind of problem new designers face a lot, and it’s interesting to see that it doesn’t seem to go away with experience!

And that was the first episode of Roadblock! Hopefully you found in it something that was helpful to you and your design process. Now imagine we had a cool 90’s out-tro with weird punk music: ROADBLOCK! ROADBLOCK! ROOOOOOOOOOAD BLOCK!