Variety without Headache #2 – Debts and Bones!

A large amount of game ideas I get revolve around a cool action selection mechanism (CASM, for short), which is a pretty popular subset of Euro games. However, when it comes to building out the actions for your CASM, there’s a pretty difficult line to toe: if they’re too similar, the CASM’s interesting decision space becomes a non-decision, but if they’re too different, you have too many subsystems to teach. Too simple, and the game becomes rote, but too complex, and they take the focus away from your CASM. You need to add variety without adding headaches. It’s quite a tricky tightrope, and it can quickly lead you astray.

This is the second installment in a series about CASM-focused games with an original system that gives you actions to add meaning to your core CASM and opens up the design space for more content, without adding too much rules overhead. It’s sort of a sub-series of SISIGIP (Stuff I’d Steal in Games I Play).

As a disclaimer, I want to point out that a game is not just a pile of mechanisms of systems. A game tells a story out of interesting moments, which come out of interwoven mechanisms. You can’t just take your CASM, plug in all these actions and call it a game. This is meant to be praising and analyzing excellent design, which can hopefully serve as inspiration.

Debts!

Garphill Games’ West Kingdoms trilogy is tied by its setting of medieval France, by its recurring characters, but also by its interesting Debt mechanism. While every game has its own twist on how they work and how they interact with the rest of the game, they all have a similar starting point: some actions, whether because they are too powerful or as a way of bypassing their cost, give you a Debt card. Debt cards cost you a handful points at the end of the game, because debts are bad, you see… or are they?

Each game also includes an action to Flip a Debt, which is much rarer than gaining Debts. Flipping a Debt not only rids you of the negative points, but also gives you a small immediate bonus, because paying off your debt increases your credit rating or whatever its equivalent is in medieval France.

One of the game, Viscounts, even went further, giving us Deed cards, a positive equivalent which you can spend a Flip action on to make it go from 1 to 3 VPs.

Picture by me!

I find this mechanism interesting because not only is it incredibly simple and fitting in the series’ focus on corruption and virtue, but also because gaining a Debt card is both a cost (-2 VPs), but also an opportunity (using a flip for a resource). Gaining a Debt card is an unvertain value: you can’t know whether you’ll have time to flip it or not, nor how much you’ll need the bonus. That Uncertainty means you can’t perfectly math out the result, which makes the decision more interesting.

It also opens up so much design room. It adds three actions (Gain a Debt, Gain a Deed, Flip a card) with a single rules, and those actions are of different value, which opens up the possibilities of combinations to interesting places by offering a way to balance outlier actions. Maybe getting 1 Gold per worker is too strong, but what if we give you a Debt for it? It adds an interesting dimension to your design space.

Now, what if you built a whole game out of this mechanism?

Bones!

You’d get Good Puppers (also known as One-Deck Puppies after the publisher’s more popular game series), one of my favourite little card games in existence. Now I know this is a stretch for this series: this isn’t a “filler” action, it’s literally the entire game. However, counter-argument: it’s my blog and I do what I want!

In One-Deck Puppies, you play doggo cards to piles of other doggos of that race. Card backs have a Bone value on each side: 1 – 2 – 5 – 10, to say how many points they’re worth.

Another picture by me!

The game revolves around 3 actions: Bury a bone (place a facedown card from the deck behind this column, showing the 1-value bone), Flip a bone (increase it to its next value), and Move a bone (send it to a different column). The first two are conceptually equivalent to the Debts and Deeds we discussed above, although the Flip has the extra boost of having 4 values per card, instead of 2. The Movement, however, adds a LOT.

You see, a bone’s location can come up in a lot of different ways. It’s never just Flip a bone, it’s Flip a bone here, or Flip a bone under each column with X amount of doggos, or Flip half the bone in a specific column. It’s never just Bury a bone, it’s Bury a bone in every column without a Bone, or Bury as many bones here as you have doggos. Moving the bones to the right place can set up combos in a very, very satisfying way.


Both Debts and Bones are examples of resources which are also opportunities, which can make a game’s decision space richer and more nuanced without adding much rule overhead. It’s a simple system, but one rich enough to literally build an entire game around!

Can you think of another game that features a similar resource that is also an opportunity for a better result?

Variety without Headache #1 – Bracelets!

A large amount of game ideas I get revolve around a cool action selection mechanism (CASM, for short), which is a pretty popular subset of Euro games. However, when it comes to building out the actions for your CASM, there’s a pretty difficult line to toe: if they’re too similar, the CASM’s interesting decision space becomes a non-decision, but if they’re too different, you have too many subsystems to teach. Too simple, and the game becomes rote, but too complex, and they take the focus away from your CASM. You need to add variety without adding headaches. It’s quite a tricky tightrope, and it can quickly lead you astray.

This series looks at CASM-focused games with an original system that gives you actions to add meaning to your core CASM and opens up the design space for more content, without adding too much rules overhead. It’s sort of a sub-series of SISIGIP (Stuff I’d Steal in Games I Play).

As a disclaimer, I want to point out that a game is not just a pile of mechanisms of systems. A game tells a story out of interesting moments, which come out of interwoven mechanisms. You can’t just take your CASM, plug in all these actions and call it a game. This is meant to be praising and analyzing excellent design, which can hopefully serve as inspiration.

Knarr’s Bracelets

Knarr is centered around a really cool card play mechanism, where Viking cards have a colour and an action. When you play a Viking card, you activate its action, and that of all Vikings of that colour in your tableau. There are also Exploration cards, which give you a bunch of stuff, but to get those, you spend cards from your tableau. It leads to this push and pull where you want to keep your Vikings in your tableau for super turns, but you also want to spend them for the Exploration cards. Great central tension. First to 40 points wins. Simple, clean, elegant.

The actions you get are pretty straightforward: getting one VP, going up on a track (which eventually will give you VPs), gaining helmets (which are spent for Exploration cards)… and finally, bracelets. Thematically, bracelets are a sort of currency, and exploring opens up new trade routes. Mechanically, they do something quite interesting.

Picture by me

Each Exploration card has those three lines at the bottom, with some of them associated with effects. Bracelets are used to activate these: spend one bracelet to activate the leftmost column; spend two to activate the first two; spend three to activate all three.

At first sight, you could say this is just a second level of engine building in an engine building game, which it is. However, that simple mechanism (it can be taught in one sentence) opens up a tremendous amount of design space. Not only does it give you a fourth action at very little complexity cost, but adding that third variable on Exploration cards increases the variety of those cards exponentially, and makes the decision of when to explore much more interesting. Two birds with one mechanism!

Some CASM-focused games have a “travel” action as a filler, which usually has you move around a board to gain resources. They’ll give you 3 actions, and a fourth, which will be “move around to gain one of the other actions”. I, by en large, find those lazy and uninspired. Knarr takes this same concept and makes an action out of giving you stuff, but it feels so much more interesting. By combining it with the Exploration cards, which are an existing part of the CASM, it feels less like “gain a bunch of stuff”, and more like “activate these things I’ve fought for”. And then, the three columns give you an interesting decision: do I wait for a third, or send these 2 right now? Should I spend all 3, or spend 1 at a time for three turns?

So I have a few ideas for subsequent posts in this series, but let me know in the comments if you think of other mechanisms that fill this concept you’d like me to talk about!

Game Designer Organization

I’m a strong believer in “work on more than one game at a time”, because it prevents tunnel vision, helps give you distance from the project, and maintains momentum when you hit a roadblock with one project. But that requires a lot of organization. I also have ADHD, which requires a lot of organization. I developed a method, and I thought, hey, that would definitely be useful, why not share it?

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.

So first, this method is going to be digital. Look, I work in IT, and I am usually an advocate for people using physical tools over digital ones, but for this purpose, I gotta have something that holds all of my info in one place and… well, organizes it. I need to be able to look at the data how I want to, without having to make a brand new table. I need one source of truth, which is hard to maintain on physical media. I can’t have stuff fall between the cracks, with multiple versions and having to remember whether final_final or final_for_real is the latest one.

The method works on paper or on any other software, but it will be optimal when using the platform it was designed for.

Speaking of platform, I used to organize stuff in Excel, then OneNote, and now I swear by Notion. I use Notion because of its different views: I have a view for individual games, a high level overview table, a timeline, a to-do list. It’s quite handy. I also will point out this isn’t sponsored in any way and all that jazz. I just like Notion.

For each project, I have seven fields: Project Title, Stage, Excitement, Pitch (“A game with…”), Description (“What’s this again?”), Next steps (“So what now?”), and time requirement of those steps (“How long”?).

Project Title is a working title, just so I can identify what project this is about. Obviously, I’m not going to publish a game named “Kaiju Emotional Growth”, but until I figure out what that title will be, I still need a way to refer to the game. Obviously.

Stage is how I can keep track of where I’m at with each of these. As of right now, there’s about 20 projects on the list. I don’t write every throwaway idea in there, but I do once I start doodling about it, talking about it with my wife, with my friends. These are the stages I use, because they’re (almost) the ones I use in my day job, and they’re obvious to me:

  • SHELF are games I used to work on, haven’t actively thought about in a while, but still would like to get back to;
  • BLUeprints is for when it’s in doodle mode: I haven’t really nailed down what the pitch is (I design pitch-first, and you should too!), or the central mechanism.
  • SandBoX is when I’m filling out that experience into something playtestable and working on a first prototype. Best practice is to get the game to the table as quick as possible, but I often consider building my first prototype to be a first playtest.
  • DEVelopment is the early discovery stages of testing. Those tests are usually with other game designers, or with my wife. There’s a very common advice in playtesting not to test your game with your wife, but people who say that haven’t met *my* wife, who will happily destroy my little baby project.
  • QuALity is when I have figured out the shape of the game. The quality stage is where I fine-tune systems, create and test out content, and balance the game. Ha, just kidding, I don’t balance games.
  • PRoDuction is when what’s in the box is figured out, and all that’s left to do is get the game out there. It’s either being pitched, or waiting to be prepped for a Kickstarter.

Now game design is not just forward process. Sometimes, while making my first prototype (Sandbox), I realize the pitch doesn’t actually interest me, and the game goes back to Blueprints. Sometimes, a Quality-stage playtest breaks down a side system, and we go down to Development. It happens oh so often, and there’s no shame in it. There’s also no shame in fighting it before accepting that you’re not as close to the finish line as you thought. As long as you end up accepting it, it’s all good.

Second property is Excitement level. I track my projects’ excitement level for two reasons. First, because every now and again, I just need to get excited again, and that field helps identify which project can help. Second, when I lose excitement for a game, it often is evidence that something about the game doesn’t work.

Then comes “A game with…” As I said above, I design pitch-first. My goal is to have a compelling pitch before I start working on a game. When the pitch is determined, I find design a lot easier, because you just… work towards delivering on your pitch. And if you can’t find a compelling pitch for your game… then maybe the game isn’t worth spending time on?

The name of that field is mostly a suggestion. I often write my pitch as “A game with X, but Y”, and having the first bit written helps me avoid blank page syndrome. Works for me, might not work for others.

“What’s this again?” is where I write my high-level idea of what the game is. Titles change all. the. time. Early, the pitch might not be established yet. What’s this again is how I keep my ideas straight. This mostly came after a period where I had a cool theme idea (Dream Weavers Inc, a corporation that steals dreams from the population to build tailormade dreams for the highest bidder), and tried to apply it to every. single. game. I worked on. It got very hard to track what was actually in the Dream Weaver folder on my laptop, so I instead went with a high-level description of the mechanic.

Finally, “So what now?” is where I keep track of what my next steps are. Having this up-to-date means I can peruse it when I have a free half-hour and get a quick win. It also helps me focus on progress when playtesting: WHAT am I actually trying to glean from the playtest? It’s combined with the How long? field, which helps me identify how doable stuff is in a given window of free time. “Update prototype” sometimes is a 10 min affair, and sometimes is a 3-hour chore.

Overall, what I try is to keep this list focused on action: what do I need to know to push these games forward. I also keep it to a minimum: the larger the table, the harder it is to keep up-to-date, and the worse it is when it falls behind.

And let’s be real, it’s not completely filled up all the time. White space is fine. I used to push off making this list because there would be white space, and that led me to be disorganized for a few weeks longer than I needed to. It’s been over a year using this, and it still isn’t completely filled, but it’s usable, and that’s okay.

Reviewing “Go-to Questions to Ask Playtesters”

A few years ago, I wrote this post about my go-to questions to ask playtesters. The last one was this:

What do you think should happen? This is more of a question during games, but it still is one of my favorite tools: if players run into a corner case and ask “so what happens now?”, even if I know what the official answer is, I ask them what seems intuitive to them. If they come to the right conclusion, great! If not, that’s okay… unless it happens all the time. And if you didn’t have an answer yet, it gives you (1) a proposition, and (2) some time to think about it. In that case, you know you’ll have to figure it out, and you just want to make sure it doesn’t break the rest of the test.

It still is my favourite question, and I do believe it should be used more often. That being said, I would like to amend that paragraph in a few ways.

First, I changed the wording from “What do you think should happen?” to “What would you like to have happen?” The former often had testers resist: I think part of it is some people understand it as a quiz of their memory of the rules I taught, also because it suggests there’s a right answer, and with it, a chance they get the wrong answer. It also asks them to think of rules, of why they exist, of interacting systems: not everyone likes to do those things. In a way, it also positions them as an expert, which while some people enjoy, a lot feel intimidated by.

On the other hand, “What would you like to have happen?” is 100% subjective, no wrong answer, no experience required. I have yet to find a playtester who didn’t have an answer to it, although sometimes you get a “oh I would like for this to give me a million dollars”, which forces me to bring out my retail worker face from 2006 when people hit me with a “Oh, it didn’t scan, it must be free”.

Hey, that’s the Cocaine Bear guy!

That switch is also a parallel to the adage “playtesters are great at telling you problems, but poor at giving you solutions”. I trust playtesters to tell me how the game made them feel, but less so to analyze how to make them feel differently. When I ask “What should happen?”, they often start brainstorming: “oh, this could work like in Terraforming Mars” does not solve the problem of “what do I do when I land on my opponent?”, it just opens up a discussion that takes away from the playtest. When I ask “What would you like” and they say “I think I should get a bonus in this case, it’s so hard to do”, it means they feel like the game doesn’t appreciate their achievement enough. That’s a direct screenshot of their emotion.

In other words, once I know how the players want to feel in this situation, I can figure how to get to that result on my own.

The other reason to return to it is that I also want to nuance the reasoning behind that phrase. My design process has changed a lot over the past few years, and now I treat playtests, especially early ones, as much more exploratory. I come to playtests with an incomplete ruleset. I change games on the fly a lot more. I leave rules ambiguous on purpose. I use different icons or terminology to represent the same thing, just to see how players react to them, which ones stick and which ones don’t.

Which means players ask me a lot more questions, and more importantly a lot more questions to which I have no answer. In that post, I said I wanted to see if they’d guess the right rule: I still think that’s a useful way to gauge a rule’s intuitiveness. However, that doesn’t apply to my current design process. When people ask a rules question, it’s often a Schrodinger’s rule: until they guess it, there is no right or wrong. When they guess it, based on how much it messes up everything else (a process I discuss in this post), I can decide whether I say “sure, let’s go with that”, or pretend there was already an existing answer that I make up on the fly.