Daniel Newman 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 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.

JV: Had you ever encountered a similar problem before? Why was this one different?

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]

Getting Feedback on your Pitch

Note: This is less essay, more diary, than what I usually do. It’s a very spur of the moment thing and is somehow even less structured than my usual writing.

I submitted With A Smile & A Gun to the Cardboard Edison Awards. It’s a yearly contest where you submit a rulebook and a video overview of a pitch-stage game, and get feedback on it. I LOVE that contest, because you get high-level feedback on your pitch, and can have a better idea of the first impression your game idea has on people. Usually, by then, you know what works mechanically, and its just a question of what to emphasize and what to tune down a bit, whether it’s to pitch to publishers, or to customers when you get to self-publishing.

That kind of feedback is very valuable for me. I can walk away from a playtest without asking questions and still get a pretty good feel for how the systems worked, what mechanisms need to be dug into, and which part people struggled to understand. However, I have more trouble figuring out those first impressions, how much of a tester sitting down is interest in the game idea, in playtesting in general, or just politeness.

I had a LOT of feedback about it at ProtoTO, where there is a presentation of your prototypes, and you set up your game and spend an hour-ish telling people why they should spend their limited con-time testing YOUR game. But that is a very limited thing, it’s pretty hard to reproduce: at design nights, we usually all get a turn, you don’t have to convince anyone. If you bring a new prototype to your regular game night, it’s more about social aspects than your pitch itself–your friends probably want to help you, they know about your other projects, they know who you are and the kind of games you like.

I could probably find a way to ask playtesters about that pitch, but I never do. To truly grasp their first impression, it would probably have to happen before the actual playtest, and I’d worry about what it would do to the session’s pace–hook them, then feedback, then teach, then game, then feedback again? Or just do the pitch, feedback on pitch, and then thank you? Catch-and-release?

I wrote about thinking about your pitch earlier in the process in another article. I still think that is a crucial part of serious game design, and that you should test how excited people get about your concept before you start working on it. That being said, it goes against all of the “get it to the table ASAP” advice that we hear from the greats. Problem is, I haven’t yet mastered how to get feedback on my pitch during the game’s development, and so I either do it all at the end (which is VERY hard), or before (which delays the mechanisms from being tested).

So yeah. As I said, more diary than essay, and probably not that helpful to many of you. I’m hoping maybe we can get a discussion going about it? Do you work on your pitch during the game’s design? If so, how?

Designing “pitch-first”

I am a member of the Game Artisans of Canada, a guild of Canadian game designers, publishers, and artists. My first meeting with other Artisans, one of them said “These days, I don’t work on something I couldn’t pitch.” That, to me, was a sellout attitude: only in it for the money! What about the art? But I was wrong: “something I could pitch” means “a game which can grab people’s attention”, and those could be publishers, but also playtesters, potential customers, other designers. And these days, I also make sure an idea can grab people’s attention before I start working on it.

But I didn’t always: Art Traders, my first solo design, was designed mechanism-first -I wanted to make a mid-weight Euro with the Yatzhee scoring, which I thought was a great, unused tool in modern games-, and so the first pitch went like this:

“Art Traders is a 60-min long Euro about running an art gallery. You alternate between two phases: acquisitions, which is one-way worker placement, where you always have to place further than the last worker you placed; and Exhibition, where you choose one of four criteria by which to evaluate your collection, but you have to choose each criteria once and only once.”

As a mechanism guy, that is very interesting to me, but it has a very niche appeal: it’s very mechanical, and it reads like a “this is A and B mashed together”. A pitch is not to meant explain the game, but to grab people’s attention, whether a potential publisher, a playtester, a customer.

Now, compare this to the pitch I had for SuPR at ProtoTO a few months ago:

“SuPR is a coop game where you play as a PR firm who just signed a superhero for a client. You’ll have to balance the crime fighting and the TV appearances, and fill up the Love-o-meter before the baddies manage to destroy the city. You’d think saving lives would be enough, right? And of course, you want the best for the city, but… the worse the situation gets, the better it looks when you swoop in and save the day. But if you let stuff get too bad…”

The game is still early in its development, but my pitch is already ready, and honestly, probably my best one in my opinion. It contains multiple hooks: ways to grab people’s attention. There is:

  • The theme: Superhero, but we’re just the PR firm. I usually get a chuckle, and people do a double take;
  • Balance crime-fighting and TV appearances: mechanically, it’s the exact same as curing cubes and amassing cards in Pandemic, but the words sound new. By now very few people are uninterested.
  • Catchphrase: “You’d think saving lives would be enough” will probably be the game’s subtitle. It suggests exactly what I want the game to be about: just saving the world would be easy, and just getting liked would be easy. It’s trying to do both that makes it hard. Again, new words to express a pretty standard feeling in coops.
  • “The worse the situation gets…”: That part is where the game becomes different. In standard coop, you usually avoid “on the brink” situations as much as possible: in this one, you actually manipulate them into being. This is what makes this game different.

I’m not saying I’m a master pitcher: holy molly am I not. But I think the main difference is nowadays, the pitch is the first thing I think about. I use the #IsThisSomething to share on Twitter ideas I have for games, and if I can’t write what’s interesting in 280 characters, it’s not refined enough. If I get no traction, it’s not interesting enough. Sometimes I go back and work on it, sometimes I just forget about the idea: I have enough game ideas to forget about most of them and still not have enough time to work on the ones that are left.

Writing that pitch also gives me something to design towards, a vision statement of sorts. SuPR was first a roll-and-write game, but when I realized “coop roll and write” was interesting, but not pitch-worthy, I threw it out. When we ran into trouble with earlier versions of Cybertopia, it was much easier to see what we should focus on. With Art Traders, changing from the Puerto Rico lead-and-follow to the one-way track felt like a much bigger change, because it changed The Pitch.

To be completely transparent, I make it look like I do this purposely and in an organized fashion. In reality, it’s more that I let a game marinate for a bit before I work on it. I post about it on Twitter, I talk about it with friends, and through that, I find the kernel that is interesting to me, and that others respond to. Then, eventually, I put it all down on paper.

How early, and how much, do you consider your pitch in your design process?