Tag early design

WHEN to add variability to your design

Subsurface Games Leave a comment

Last week, I talked about going from idea to prototype. Today, I want to talk about one of the pitfalls many of us fall into when prototyping.

I’m a huge proponent of variable setups, missions, objectives, factions, and characters. I feel like it’s the one thing all of my games will have in common: “20 different powers, only use 3 each game!”

But variability should be the last step when designing your game. To start, you need to make sure your game structure is solid; then, when your game is strong enough to handle it, you can start adding variables to it.

Believe me, I know all about the temptation of adding that variability early. My first game idea was a game about breeding monsters: I had probably 30 monster cards, and I wanted to have a card for a unique offspring for each of those pairs. And, of course, I wanted to have multiple of each, so you never quite knew, when mixing a dragon and a unicorn, which kind of dragicorn you’d be getting!

Yeah, it was the weirdest idea.

But it never saw the light of day. I worked on it for months, never got close to having it ready for a playtest, and I didn’t want to playtest it without finishing it. I was figuring stuff out, making dozens of cards, making diagrams; I felt like I was making progress. In a way, I was, but in a much truer way… I really wasn’t.

Why is adding variability too soon a bad idea?

There are 3 main reasons why it’s a bad idea to start with your game’s content, rather than its structure.

First, any change in the game’s structure will require changes in the elements built upon that structure. Imagine changing the structure of a game like Dominion. After a few playtests, you decide to remove the limit of actions per turn. Without even entering into the issue of game balance, how many cards suddenly don’t even make sense with the new ruleset? All of the Village cards, or the “cantrip” cards that give +1 Card and +1 Action ⁠— these cards were specifically designed  to overcome that limit, and would no longer have a real purpose.

Picture by iSlaytheDragon

The second reason is that creating content is a time-consuming task which does not really have an end state. Creating content is fun, it’s easy, and it feels like progress, but too much can be a trap. Even if all of your ideas would make it into the final product, you will always have more ideas for new cards, new tiles, new characters, new missions. With a Smile & a Gun is being printed right now, and I still come up with a Shadow card idea every week. If you wait until all of your ideas are in the game before you start testing, you will simply never start testing; each idea you write down will give you another one, and then another.

Finally, content becomes much easier to create after you’ve played the game a few times: you have a better feel for what would be interesting, you can poll your testers for their opinions, and you probably have a pile of mechanisms which did not fit… but maybe could become a card!

But don’t I need content?

Of course! I’m not saying “playtest your card game with blank pieces of cardboard”. Although… if you have a specific mechanism for, say, acquiring or discarding cards, it’s always a good idea to take a standard deck of cards, and try it out.

You can’t playtest your deckbuilder without actually having any cards. Here is a rule of thumb: determine the minimum amount of different elements you need to have to be able to play a single game. If you were making your own version of Dominion, you wouldn’t need to have 25 different action cards designed before you start playtesting; every game only uses 10.

Once you’ve identified that minimum number, make half of it.

No, I’m not kidding. For a first test, you want to have as few variables as you can. If during your test, the game doesn’t click for some reason, you need to be able to identify what causes those issues: it might be the structure itself, or it might be one of the cards that’s throwing the entire game off kilter. Worse yet, it could be an interaction between two cards. Having 5 cards instead of 10 means that not only do you reduce the number of variables which could be affecting the game structure, you’re also reducing the number of possible card interactions from 100 combinations to 25. Sure, 5 is too few for a full game experience, but you’re not aiming for a full game: you are testing whether or not your core idea is fun.

Maybe you can’t actually divide the number by two, but you can just cut down on how different you make these elements. Working on SuPR, a cooperative dice drafting game, I wanted players to roll a pool of dice and determine who would use what. Therefore, I needed players to have different abilities, or else the central conceit would break down. However, for the first playtest, I just changed which action was paired with which: it was very minor asymmetry, and a lot less than what I needed to make the dice selection shine, but at least it made me able to work on the bigger picture.

But I like making content!

Creating content for your game is not only important, it is also fun. It is perfectly okay for you to indulge yourself and create some of that content early. My goal with this article is not to take away your candy, but to make sure you understand that (1) you should not wait for the content to go ahead and playtest; and (2) all the early content you create is unlikely to make it through the game’s development unscathed. 

How early do you usually add this variability to your designs? Have you gotten caught in this pit before? If so, how did you get out of it?

From Idea to First Playtest

Subsurface Games 1 Comment

The first game I designed was actually a co-design, and Louis onboarded me after a few playtests of his own. For a while, I was an active game designer without any idea how to start a design: I had gotten in right after that part. I’d go around and ask established designers at conventions, or on panels and Q&As: Every time, the answer would be something along the lines of “you just do it”, which is… well, not that useful.

I’ve seen a few people around the Twitterverse asking these questions recently. Remembering my own questions from back then, here is MY method for going from an idea to a first prototype.

Disclaimer: This is a method that works for me. If you have a different method, awesome! If this one doesn’t work for you, I’m sorry! This is just meant as an example: you can try it out and see what sticks.

Step 1: Define your core

Whether I’m inspired by a mechanism, a theme, an experience, my first step is always to define what I want the game to be. This takes the form of a pitch, a short, 2 or 3 line paragraph about what I want the game to be. I want it to be snappy and dramatic to begin with (it will get longer as the concept solidifies) because (a) it’s easier to grab attention that way, and (b) it helps me identify what is the core I’m aiming for, and what is just brainstorming around that idea.

Usually, I’ll try and get some feedback on this pitch. I’ll talk about it with friends, other designers, or just in general on social media. This is useful both to gauge interest, but also to help me smooth out any rough edges: in a way, I’m playtesting the pitch!

Step 2: Deconstruct that core

Once I’ve identified this core, I need to figure out how the game will fulfill that promise. Where marketers often try to represent their target audience with an imaginary character, I try to represent my central idea with a target moment that represents the experience I want the game to offer.

From then, I identify what building blocks I need to make that work.

A few examples:

  • For Off the Record, the core was the growing-pile mechanism, exemplified by that decision between a huge, 6-card pile, or that one card you really need. I needed a reason for you to need a specific card, but a way for any card to be useful for you, which led me to turning in Poker hands for points.
  • For Cybertopia, the juice was that free-flowing roster of workers, where you’d get a different group of options every time you’d gather. That means I needed workers which were different enough for that to matter, and a way for them to be grouped in the actions where they were sent. I also needed those “groups” to be unrelated to the workers’ unique traits, so that they wouldn’t all be piled up in the same groups: instead of workers, we started looking at them as multi-use cards, which made a lot more sense design-wise.
  • For SuPR, the pitch is a large thematic thing, but the core is “you have to save the town, but the more dire the situation, the better it looks”. I knew that the central mechanism needed that risk-reward, where you were not completely able to control your actions, nor perfectly plan them ahead of time, or else, there would be no luck for you to push! This made dice drafting feel like such a good idea!
    Then, coop dice drafting suggested the idea of a “love draft”: instead of “what can’t I leave my opponent?”, I loved the idea of “OH! I NEED THAT DICE! PLEASE LEAVE IT FOR ME!”, which meant, like with Off the Record, I needed a way to have something that was just *perfect* for a player, but for every player to be able to use it, leading me to the idea of a dice you used for both the number and colour.
  • For my untitled coop roll-and-write, I wanted to merge that moment at the end of a game of Pandemic or Spirit Island, where you look at the map and go “this is what’s left of the world”, and the permanence of a roll-and-write sheet. Because of that, the gameplay must be centered around a map, which players are building up while the game is doing its best to tear it down.

Step 3: Good artists borrow…

Even with that central idea fleshed out some, you’re still far away from a playable prototype. This is where I follow the famous saying, and outright steal another game’s frame.

Sometimes my inspiration starts from a game in particular: as I mentioned previously, the coop roll-and-write idea came up right after a game of Troyes Dice, and the first prototype was, more or less, a cooperative version of it.

If not, I try to find a game that would fit my building blocks: with SuPR, I started from Pandemic: the Cure, another coop dice game, and added the “scoring” system I wanted; with Cartographia, we started with Blue Moon City, but with players getting bonuses when others would map the same space as they previously did; Cybertopia started from Imhotep, with the worker cards replacing the boats; With a Smile & a Gun started out as Cat Lady, with the dice-drafting rondel to go with it.

I then make my first prototype as close to that game as I can. But…

Step 4: Start with the second prototype

“Your second try is always better than your first.”
“So how do I start with my second one?”

My first prototype never actually touches the table.

The simple act of building a prototype, to me, is a first round of testing: I ask myself how things will interact, I write cards and get cool ideas, I find a cooler way to present a decision, I imagine myself playing a round and cursing my friends out.

You can argue it’s semantics (and you’d be right), but it highlights one of the biggest problems I have with creative endeavours: I can’t start creative without knowing what I’m making, but I need to start making it to figure out what I’ll be making. Therefore, I have to trick myself, and start making something I know I won’t ever be using, just to get the gears in motion.

Sometimes this “first prototype” is writing a bullet-point rulebook, sometimes it’s taking pieces from the seed game and moving them around, sometimes it’s opening up PowerPoint and making cards. The zeitgeist says “get it to the table ASAP”, but you can use a metaphorical table: in a way, a spreadsheet is a table, right?

Step 5: Schedule a playtest

If you are gifted with the ability to solo playtest your game, go ahead and do that.

Otherwise, if you’ve read last week’s post, you know that the best way to finish a prototype is to schedule a playtest and give yourself a deadline.

Oh, it’s not finished? Of course it isn’t: that’s WHY you playtest.

You can keep on changing and tweaking and editing and adding, but a 30-minute playtest will help your design more than another 30 hours of modifying your prototype.

Identical vs Equivalent

Subsurface Games Leave a comment

I often say that board games are the combination of psychology and mathematics. More exactly, they use mathematics to induce specific psychological reactions: tension, angst, euphoria, excitement, satisfaction, all just because your number will be lower than your opponents’. Fascinating, isn’t it?

Now let’s take that vision of games and look at them through a game design lense. A game’s elements (be they components, theme, or mechanisms) are not the point: they are tools to create a specific experience. Sure, all of these elements are important pieces, but the sum of the parts are what’s important.

This sheds light on one easy pitfall of design: to look for identical alternatives rather than equivalent: too often, I hear playtesters suggest alternatives, and designers turn them down because of some minor mathematical differences. This is especially true when we talk about streamlining, about suggestions that could simplify an entire system but are turned down because that one action would now give 4 rocks instead of 3. Is that a meaningful difference?

I talked about one similar situation in this blog’s very first post, when we had included 5 different ways for tokens to score, and 4 different mini-games, which were technically different, but did not affect the game’s experience or the players’ decisions at all.

Another example is from the roleplaying games side: in 13th Age, players roll obscene amounts of dice for damage. The designers strongly suggests to instead either (a) take the average damage, (b) roll one die and multiply it by the number of dice, or (c) roll two or three dice and take the average for the rest.

These are all mathematically different: the static number obviously stands out, but even multiplying one die leads to much swingier results than the standard die roll, which itself is swingier than just rolling a few and averaging the rest. However, while all are mathematically different in how extreme the results will tend to be, the game does not change much between the two. You could have a group where each player chooses a different way of calculating damage, and it wouldn’t make much of a difference: while not identical methods, they are by and large equivalent.

When designing, every design element should be there for a reason. During your process, it’s important to look for equivalent alternatives, which could fill the same role in the design, without being identical.

For example, High Rise, Lords of Waterdeep, London, and Cleopatra and the Society of Architects all have a Corruption mechanism: some things you do are stronger, but come with this negative token you then have to manage, and try not to have the most of. They all have a different associated mechanism, but they all have the same impact: give some actions a delayed, and uncertain cost. If you took any two and switched the Corruption mechanisms, they would mostly still feel the same. There would be differences, but I’m not sure they would be that meaningful.

Of course, the difference between identical and equivalent is very subjective, and highly context-dependent: you might disagree with my example above. Yet, I would still suggest you err on the side of openness, especially early in your design process: it’s so easy to try something, and, if it doesn’t work, to just CTRL+Z the change.

Daniel Newman on his Roadblock

Subsurface Games Leave a comment

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

Subsurface Games 1 Comment

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”

Subsurface Games 3 Comments

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?