Books for Game Designers

Some cool news in Playtank-land: I’ve signed on with CRC Press to write a game design book!

It’s a book I feel is currently missing and that will fill a critical gap in the knowledge sharing around game design. But to clearly state where I’m coming from, this post will be dedicated to some fantastic books on game design that already exist and that you should read and keep around for future reference.

These are far from all the great game design books out there, but they’re the ones I most often come back to.

Advanced Game Design A Systems Approach

By Michael Sellers

This is one of my personal favorites. I picked this up after the Frostpunk team recommended it greatly in an article on their procedural systems. Systemic games are growing in importance and relevance. Partly because content-driven games have a limited lifetime and are expensive to make.

My biggest takeaways are the practical ways to look at systems as Economies, Ecologies, or Engines, and what this means for your game.

The Deck of Lenses

By Jesse Schell

Not technically a book at all, but a deck of cards serving as a companion to Schell’s The Art of Game Design: A Book of Lenses. The book does a great job of holistically describing games, but the deck turns an interesting read into a practically useful tool.

Each card is a “lens,” with a set of questions you can ask yourself in order to more deeply inform your design. Even questions that may not seem immediately relevant will always make you think.

Challenges for Game Designers

By Brenda Brathwaite (now Romero) and Ian Schreiber

Another favorite and one that I often quote. Not about game design as much as how game design is something you must practice and turn into a practical skill. It’s not about winning armchair duels or playing reference tennis.

Or in the words of the text, “A painter gets better by making lots of paintings; sculptors hone their craft by making sculptures; and game designers improve their skills by designing lots of games.”

Game Programming Patterns

By Robert Nystrom

I know. Your instinct is to say, “but I’m a designer, I don’t need to know programming!”

Yes you do. If you want to make digital games, knowing how games get made and some of the tricks that enable them is extremely helpful. At minimum, it lets you talk to programmers in a more constructive way.

Besides, you can take a peek at Nystrom’s book online for free and not just take my word for it.

Uncertainty in Games

By Greg Costikyan

This small book opened my mind. Its examples aren’t exhaustive and many I’ve talked to have argued that it doesn’t have much content. But it doesn’t need to.

It talks about uncertainty as a key element in what make games so compelling to play. You may know it as randomness, competition, hidden information, or in one of the many other forms that the book brings up. The book makes a compelling case for why you should make sure to consider which uncertainties you are employing for your own designs.

Game Feel

By Steve Swink

This book is a very hands-on take on how games feel to play and what makes it that way. It brings things up that you simply must know if you are serious about digital game design. Its many informative diagrams and illustrations serve to make it clear what makes things work, what may be the causes of player frustration, and many other interesting tangible things about game feel.

Designing Games

By Tynan Sylvester

This book, which I read more recently than the others, does an amazing job of summing up game development and design in a holistic and pragmatic fashion. Its examples are somewhat dated for contemporary players, owing to the fact that it was first released in 2013, but the language and focus is definitely not.

Since Sylvester’s focus is similar to my own, working heavily with systemic games, I find myself agreeing with much of what he writes, and the concept of designing an experience more than “just” a game appeals greatly to me.

Probably the best generic book on game design that I’ve read.

The Pyramid of Game Design

By Nicholas Lovell

Games as a Service (known as GaaS) are here to stay. The Free-to-Play business model is compelling for a variety of reasons, all of which Lovell mentions in this book.

Among gamers, these practices are often lamented. But Lovell comes from a different perspective and talks about how turning a game into more than a game – a hobby – is the path to success. Not just introducing mechanics designed to optimize monetization, but rather to hook the player and make them want to come back for more.

Even if you don’t like GaaS, Free-to-Play, or any other of these models, it helps to understand what makes them work.

The Missing Book

Books that focus on specific topics will usually be my favorites. This is why I don’t list Schell’s The Art of Game Design, even if it’s a great book. Because what it does is done by many many books out there: it explains the theory of game design.

For various reasons, I’ve felt that a practical guide to how you do game design is still missing, formatted as accessible tools that game designers use in their everyday work. This is what I’m trying to write and have been trying to write for the past couple of years, even before I was contacted by CRC Press.

But they’ve given me a reason to finish it!

Wish me luck.

EDIT: you can now buy my game design book, The Game Design Toolbox, in stores, such as here! It was released on December 6th, 2023.

It’s (Not) an Iterative Process

“Game design, like most forms of design, is an iterative process. That means that the game is quickly prototyped, played, and refined again and again before it is finalized.”

Brathwaite and Schreiber; “Challenges for Game Designers”

Iteration is a word game developers use to describe the magic that makes games happen. But what we actually do when we iterate, and what we iterate on, isn’t exactly consistent. Rather, “it’s an iterative process” is a dismissive and handwavy equivalent to “God works in mysterious ways.” 

There are dangers to iteration as a solution rather than a process and some may even seem like they’re good things when they’re not.

The Dangers of “It’s an Iterative Process”

One common problem comes from iterating on late-stage production content. Say, a character that took twelve weeks to make and has to be remade because someone wants some large changes; or an in-engine cinematic that’s already been put together and turns out to be too long, too short, or uses the character that needs large changes.

Editing on late-stage content isn’t easy since in-game assets and engine tools are used. Redoing a cinematic can be a painful process. Redoing a character may require revisiting every moment in the game where that character is used, making sure the sword on its back doesn’t cut through its leg while moving or making sure that the colors match what the art director wants.

It may seem trivial to “just” rotate a thing or change a color value, but sometimes it’s not. Sometimes it snowballs into disaster faster than you can spell overtime. If you need a specific card from a house of cards, just pulling it out collapses the whole thing. Same with late-stage iteration.

At one point, this once went so far that a director said “if this is still a problem closer to launch, let’s revisit it.” But, as everyone knows, anything that gets pushed “closer to launch” will be put way down on the list of priorities and the problem will persist into the finished game. In that specific unnamed case, the problem did persist and is in fact in the finished game.

This place is where we often end up when we say, “it’ll be better later,” or some variation of the same. When we hide behind the iterative process itself without thinking too closely on the hows or whats of iteration.

The Dangers of Cheap Iteration

Some things are much faster and cheaper to iterate on than others and can therefore be iterated on for too long during a project’s lifetime. Sometimes because we have people hired to do the iterative job. (Sorry, but game designers are often the baddies here.)

Three specific things stand out:

  • Theoretical design. “Wouldn’t it be cool if” is another theoretical design iteration that doesn’t necessarily have any practical meaning for your project but can still be pushed through at late stages. Designers without practical skills tend to be the worst culprits here.
  • Writing. Writing is rewriting, as they say. A writer can come up with literally anything at a moment’s notice. When writers drive the content, this is what often happens. Five minutes putting words in a document and suddenly there’s another six months of work.
  • Sketch art. Good sketch artists can draw things faster than you can blink, and can similarly introduce new coolness and greatness with very short notice. Of course, they rarely do this spontaneously but because a director/designer/writer-person asks for it.

These three are so cheap to iterate on that it often causes another kind of problem: you never stop iterating on them and by extension the features or content they affect. Especially if you have many meetings of the sort where you talk about your project in abstract high level terms.

Even deep into production of your game, you can still backpedal on some story element, introduce a new character that the creative director came up with for some reason, or change fundamental designs because “wouldn’t it be cool if?”

This is where much of the bad type of iteration comes from, and trickles down through production like acid rain. If you want to know where game development delays come from, this is often it. You probably know it by the name “feature creep,” or “creative vision.”

You should do less of these three once you reach production. Preferably none at all. Do spend a lot of time in preproduction iterating on these three cheap things, and prototype them to your heart’s content while they remain cheap. But once you hit production, you must stop.

The Dangers of Deliverables and Iteration

Deadlines are like Terminators. They can’t be bargained or reasoned with, and they won’t stop until you are dead. This makes them completely incompatible with the loose approach to iteration, where we’ll “fix it later.”

Once you hit the deadline, what you have is what you have – if the iteration didn’t work out, you have nothing, or you are forced to fall back on the bare minimum. Or, worst case, what you have simply isn’t very good.

There’s an idea that things can only be known to be good at the end of a project, when all things come together. But this is only because we often spend our whole project time iterating on production content and don’t force ourselves to iterate early and cheaply.

How Nintendo works on their controls for a very long time, and how art direction can be constructed carefully around communicating your gameplay, are examples of good iteration. Once you hit your deadline, you must know what you have, and you must have already finished all the iteration you needed to do.

If not, whether your game is good or bad will basically be a coin toss. A coin toss based on professional experience, surely, but still a coin toss.

The Dangers of Third-Party Game Engine Iteration

There’s a natural inclination to jump straight into the scripting or programming tools and churn out a playable demo. You open up a third-party engine, throw some ready-made templates into a project, and voila: you can move and shoot stuff! 

This is often great, because it lets you answer hard questions and push your design forward. But chances are that you create a kind of illusion of progress, where making the bare essentials work feels like good progress because you didn’t have it before. But once you try to take the next step, you get bogged down in minutiae that are entirely irrelevant for the iterative work you aimed for. Especially if your engine of choice relies on ready-made packets of logic that can become black boxes for your implementation team. Say, a ready-made AI feature packed with extraneous functionality or a system for handling input that causes high latency.

What happens is that you spend more time fixing the ready-made solutions than you do iterating on your game. There’s also a great risk that you start skipping features you wanted to make because the engine doesn’t have good support for them, or they are too hard to make without extensive refactoring or source code additions.

Or the opposite happens and you start building features based on cool stuff in the engine rather than the game you had in mind. All of it is problematic.

The Dangers of Stakeholder Iteration

For most of us, some kind of external stakeholder pays our salaries. Bless them for that. But they can also be hard to please or not really know what they want. There can also be multiple tiers of stakeholders that are equally hard to please and may have their whole employment hinged on making your life difficult.

There are three specific situations where an external stakeholder will typically ask you to “iterate,” except it’s usually in a visual way and doesn’t necessarily help the game itself move forward.

Best case, you can allocate specialised resources or even use the stakeholder’s own resources to do this iteration. Worst case, you have to reallocate parts of your team from production onto the request.

The following are three situations where stakeholder iteration risks sidelining your project:

  1. In advance of announcements, marketing events, and so on. It’s not unusual to be asked to make a video for E3 or some similar event. Some stakeholders – like game publishers – have marketing departments that do this for you; others will require you to do it yourself. Sometimes it’s planned for way in advance; sometimes you learn about it two weeks before the fact and you have to work overtime or pay expensive outsourcing to do the overtime for you.
  2. When you pitch, game publishers can be especially awful to work with. Sorry, game publishers, but it’s true. They want to see a video, you make a video; now they want gameplay. You make gameplay; now they want to see more, or they invent a buzzword they need you to realise. All for the sum total of $0. Pitching can be desperately frustrating, or as Guillermo del Toro phrased it for movie-making; “it takes Hollywood two fucking years to say no.” Game publishers are the same. This can change to some extent if you have other kinds of stakeholders, but convincing people that you can in fact do what they are paying you to do is an incredibly frustrating process.
  3. Scrambling against competition. Some stakeholder requests are complete shots in the dark. On one project, we were asked to add a train level because Uncharted 2 had just come out to some fanfare, and it had a train level. If you fail to see the correlations in that sentence, you understand how we felt. If you have a good relationship with your stakeholders, you can push back against these types of requests. If not, it’s something you simply have to do. I call these “spot requests,” and they run the gamut between useful fixes and complete waste of time.

Should We Not Iterate?

Yes we should! In fact, we should do a lot more of it. In the past year (2021), I spent a lot of time working on prototyping and finding out where the boundaries are. What is it you need to iterate on? What tools are there to use? How can you iterate faster and in a more focused manner?

I’ll be sharing my findings in a series of posts on prototyping frameworks, in the coming months.

Stages of a Game’s Design

Projects I’ve worked on, large and small, have often demonstrated similar issues with game design in their later stages. Beyond having me in common – which is hard to do anything about when you’re me – one issue has been that the role of game designer changes throughout the project but not all game designers adapt to this change.

When they don’t, they can be part of the cause for delays, miscommunication, and overtime.

To illustrate why, let’s sort a whole game’s creation from idea to launch from the perspective of what a game designer should do. (In my opinion that is – remember subjectivity!)

Ideation

Many designers thrive on ideation. Coming up with crazy mechanics and clever solutions to theoretical problems. Having ideas and working through them at breakneck speed. But ideation has a time and a place, and it’s not a full-on brainstorming meeting three weeks from launch.

Keep it short, sweet, and early.

Exploration

With all those ideas done ideated you take them to your media of choice and you explore them. In-engine rapid prototyping, storyboards, one-pagers, session prototypes, role-playing game prototypes – there are countless ways to explore the fruits of your team’s ideation. This is where you do it.

What needs to come out of this is a means to communicate what your ideas are actually about. Not just material for more ideation.

Commitment

This headline looks scary. Maybe it is. But the thing is that you need to commit to the things that work during exploration and abandon the rest. This is where you do that. In the best of worlds, you can commit gradually through a revised exploration process. More realistically, whatever you have time to explore will also have to be what you commit to. The sad truth is that most games have very little budgeted time for design exploration.

STOP!

The word ‘commitment’ in the previous section is no joke. When you’re done committing you’re committed. What you have by now is some final form for your game. On paper, in prototypes – something. You absolutely cannot go back to exploration or ideation once you pass this line:

If you read this, you’re on the other side of the line. Just remember you chose to cross, wipe the whiteboard clean, and get to it. If you’re caught ideating or exploring on this side of the line, you should be (humanely) punished for it.

Problem Solving

Design is still needed. Ideation and exploration isn’t needed, but figuring out what to do when a button combination doesn’t work or focus testers can’t figure out where to go next is needed. Solving real problems demonstrated by the playable game.

As a game designer, you play your game every day at this point. Focus on finding problems with the design – don’t report bugs and glitches. You can do that too, but it’s a bit too easy to put your tester goggles on and lose the holistic perspective. Instead, make up personas and play like they would. Do dumb things and see what happens. Make checklists of which steps you have to go through to make standard tasks like changing the resolution or looking up which button to press – then try to remove as many steps as possible and filter the game’s information in an understandable way.

Balancing

After solving problems for a while you’ll know all the sliders and variables and spreadsheet details you have to work with. This is a more fine-grained process than problem solving and assumes that you’ve mostly moved on from that stage.

You’re still playing and watching others play but you do so to observe the results of your balancing. Look at this as a polishing phase. By this point the game fundamentally works but it’s not quite ready for mass market. But it’s ready for your fans, if you have them. This is where you can do an open beta or something like it. Discuss the project openly in forums, if you have the luxury of an existing community.

The state of the game outside of the designer’s responsibilities may still be lacking content or features, but you’ll have to be able to look past the most glaring faults and focus on the balancing. It’s getting there, but it’s still mostly for the “true” fans.

Tuning

There comes a point where you need to commit to your project and start going from balancing to tuning. You can no longer listen to fans of your work, but must now start making the game for the market.

Once a game gets out in the wild, you’ll realise how wrong your balancing assumptions were, and the more of that you can do before launch the better.

Consider the 10,000 hours from a different perspective. Your game will be subjected to people’s first hour 10,000 times or more. There’s just no conceivable way that you can predict how thousands of people will try and succeed in breaking your game. Some don’t like the genre, the gameplay, the graphics, or they think it’s a different game than it is because it behaves similarly enough. You must figure as many of these cases out as you humanly can.

Most test players will probably do just as you thought they would, or correspond to one of the personas you devised during problem solving, but some will get stuck, misunderstand something, or just plain dislike everything you’ve tried to do and think you’re a moron. Sometimes loudly.

You may be forced to go back to problem solving at this stage, but it should only be in extreme cases and isolated problems. For the most part, designing at this stage is an effort to rebalance things so they fit with practical mainstream reality. Tuning them just so. The biggest problem in this whole stage is that you may end up having to alienate some of your “true” fans who helped you balance the game. But shifting from balancing with fans to tuning for the market is absolutely essential for your project.

Endnotes

It’s relevant to note a few things:

  • Not all game designers are as comfortable at each stage, or even as good at the work at each stage. Some are fantastic at having or communicating ideas, while others may be better at problem solving.
  • Not all design disciplines have equal need for all of the stages. If you’re a systems designer you probably need less pure ideation than a narrative designer but you need a lot more balancing.
  • How much time you focus at each stage will depend on preferences, budgeting, staff availability, and many more things.

The only takeaway you need to have from this is that you should know where your design currently is and what that means for the work you need to put in as a game designer.

During ideation, you don’t need to balance anything. During problem solving, you shouldn’t explore new crazy mechanics. If you respect that line you chose to cross before, your game design work will become a lot more predictable and you won’t encounter as much eye-rolling from your colleagues.

Courtroom Intrigue

One of the best games ever designed, in my opinion, is Diplomacy. It originally saw the light of day in 1959, making it much older than myself. It’s also a game I rarely get to play because of its idiosyncracies – it takes a long time to play, it requires seven players, and it has player elimination. There’s a good reason it’s sometimes half-jokingly referred to as “the game that breaks friendships.”

With this background, and what’s been previously written about player v player conflicts in TTRPGs, let’s just say that I really enjoy roleplaying where the characters are at each others’ throats.

Enter Carrion for the Carrion Crows – a mini-campaign (3-4 sessions) built around an imminent war and the nobles who were left behind to govern in their betters’ stead while they were off winning another war.

Have some fun backstabbing your friends!

Subjectivity in Game Design

Is Candy Crush good? Is Dark Souls hard? Is ARMA 3 complicated? Is Battlefield V fast-paced? Is Hearts of Iron IV accessible?

Unlike the academic theories of gravity or evolution, game design is entertainment. This means there’s no such thing as an objective truth. For every player who thinks Dark Souls is hard or Hearts of Iron IV inaccessible, there’s at least one player who disagrees. Loudly.

Metacritic grades and sales figures can tell you something about what reviewers think or how the market is voting with its wallets, but when it comes to a game design’s inherent qualities nothing can ever be objective. We sometimes forget that a game’s financial merits doesn’t necessarily mirror its creative ones.

This often makes the conversation on game design problematic, since two creatives may have widely different opinions on what the right way forward should be, and there’s no unbiased way to make a decision.

Worst case, the decision is made from executive fiat – the boss decides – but what tends to happen is that we start discussing from the only common ground we do have: the design of other games.

Yes, our game should have a Stamina meter, because this works well in Dark Souls.

No, we shouldn’t have a power that lets you fly, because Call of Duty doesn’t have one.

Our game must have a quick-melee button, because Overwatch has one and it’s a lot of fun in Overwatch.

You’d think I’m exaggerating. I’m not. All three are examples from design processes I’ve been involved in.

The Problems of Subjectivity

At a high level, subjectivity makes it impossible to make simple theoretical decisions. Especially when you combine it with the nature of game design as something everyone on a team can have opinions about. If the CEO played a cool game last night, or saw a cool trailer, chances are they’ll swing by someone’s desk the next day and talk about how our game should do the same thing.

Casual banter and brainstorming can become the same conversation as the one about practical implementation and personal tastes will often coexist with other kinds of arguments in a way that makes it hard to consider which is which.

What’s Fun

The first issue is when we talk about what we think is fun. Partly because fun isn’t always a goal and partly because fun is completely subjective. Many players enjoy competition, for example, and play hours upon hours of player versus player games. Personally, I don’t enjoy this, even if I do try many digital PvP games because I like to stay current with what’s released and what’s trending. In my tiny subjective world of single-player games, PvP isn’t “fun.”

But more importantly, pursuing fun can sometimes be detrimental to what you are making. Games like the inimitable QWOP deliberately makes the control scheme frustrating to create a very different kind of fun from almost every other game where running is a feature. And of course, the Resident Evil series thrived for years on having you decide between shooting or moving, building a more intense zombie survival horror experience by doing so.

Basically, arguing on the basis of what’s “fun” is a completely useless argument. Not because someone is wrong, necessarily, but because everyone will be right.

Good and Bad

The mainstream knowledgebase on what’s commonly seen as ‘good’ or ‘bad’ can often be discerned from the more vocal voices in YouTube comment sections or trends in user scores on various platforms. At least that’s how it feels when you observe it.

But picking features or ideas from a good game doesn’t mean your game will gain the same benefits, nor does picking ideas from a bad game mean your game will be bad either. Pretty much every game will have merits of some kind. Technical, aesthetic, mechanical. Dismissing or approving of games based on the common notion of their merits will make you miss interesting and clever ideas.

Just as with fun, using a game’s perceived goodness or badness as an argument makes for a useless argument. Especially if you are using it to evaluate a tiny part of the game.

Feature Prejudice

You’re talking about the player needing a solution to a problem, and you’re looking at games who have solutions to said problem. In most conversations, you’re more likely to use examples from games you think are fun or good, and you will then pick mechanics from those games to solve your problem – even if the problem is completely unrelated.

I was working on a first-person shooter once, where the player moved very fast. It felt nice and supernatural, and we had a lot of fun with it in development. At some point, a long empty segment of hallway was added to the test level. The immediate response was, “let’s add a sprint feature!”

My argument against this had always been that you moved at sprint speed all the time, more or less, and that sprinting would be a very artificial feature. In Call of Duty, as a good example of a sprinting mechanic, the sprinting serves a much more important purpose than giving you a slight boost in speed in empty hallways. You move slower in Call of Duty, partly because sideways movement tracking on a controller is trickier and a slower pace therefore fits the PvP matches, and partly because it’s supposed to emulate more regular soldiers and not superhumans. The sprinting then allows you to cover distances, for example to reach cover, faster, but also robs you of your ability to shoot without first stopping. This exposes you to danger if you didn’t already reach your cover.

Sprinting, in Call of Duty, isn’t just a convenient mechanic – it serves a wider dynamic.

In our case, the sprinting feature was added anyway, “because it’s expected from a first-person shooter.”

This is feature prejudice, where you make the mistake of equating a dynamic with one of its mechanics, and as we’ll get into soon, it’s a direct consequence of our lack of respect for subjectivity.

As with fun, good, and bad, you shouldn’t wantonly borrow mechanics like this.

Game Design Language

We say what’s fun, we say what’s good or bad, and we mistake mechanics for their dynamics. Subjective reality is already wreaking havoc with game design. But there’s another thing that makes it an even bigger issue: there’s no established way to talk about game design objectively.

Most game design books (that I’ve read) go through game design, not in practical terms, but in abstracts. In high level terms. You will learn how to pitch, how to write documents, and possibly read a few paragraphs about what a game is or isn’t. None of it helps you all that much in your day to day work as a designer.

Moreover, few professional game designers have actually read any of these books. Instead, you will often find yourself working in different ways as a designer depending on which company you work at, what kind of games you make, and how senior your position is. You may use a certain technique to solve a problem, and your company will have a name for that technique that you won’t find anywhere else.

One place calls the trail of enemies that leads you to the next door in the linear story “breadcrumbing,” while another calls it “leading,” or “leashing.” You’ll quickly learn the new terms at a new place, of course, but this lack of a proper lingua franca for game design pushes much of the conversation back towards using other games as reference points… and then you’re back at square one – in subjectivity land!

Handling the Subjectivity

Subjectivity is bad, then? No! We just have to remember that it exists and work around it. Understand that our own ideas are not worth more than anyone else’s and define our game on its own terms so that we don’t get bogged down in preference discussions or stuck in designing by reference.

The best part of subjectivity is that we can take ideas that may seem completely disparate, combine them, and our game will be much better for it. But only if we can do it in an informed way.

If anything, we should embrace subjectivity. Take as many perspectives as we possibly can and run them through the gauntlet of discussion and prototyping.

But we must first set the terms for our project, or our design discussions will soon boil down into matches of reference tennis.

Respecting Design as a Craft

One very important step is to give game designers the power to actually control the game design. Just like concept artists, game designers are often the subjects of uninvited scrutiny. Game design, like art, is something everyone can have opinions about. But the fact that people can have opinions doesn’t validate those opinions. A concept artist or game designer is no less of an expert than a rendering programmer or technical artist. The only difference is that the crafts of the former are not as esoteric as those of the latter.

Understand that your opinions are just that – opinions. Also, whatever you do, don’t push things through using clout derived from title or seniority. Even if you’re the CEO, you hired that game designer to be the game designer.

The point being made is: let game designers be the ones to design your game. Let them have the say in the matter and make sure that everyone respects it.

Postpone Your Piggybacking

“Piggybacking” is what you engage in when you borrow wholesale from other games. When you grab that sprint mechanic from Call of Duty, you’re piggybacking on Call of Duty.

But with all these issues of subjectivity now fresh in memory, you can see how piggybacking can actually be a bad thing. If one superfan of Soulsborne games suggests a difficulty level for your game project based on the most recent From Software title, difficulty will be very different from when the Nintendo fan dips into their experiences to do the same.

Because of this, piggyback as little as possible early in a game’s life cycle. Learn to talk about your game using the game’s own terms. Establish pillars and facts and use them as memes in your design conversations. Only engage in piggybacking when you feel that you have a clear identity for your game project.

Using Pillars

The trickiest part of game development is to solidify what your particular game is about. This can be self-explanatory for someone who is simply plugging away at the task on their screen. They just need to finish this task and move on to the next one. But that’s the work, it’s not the product.

Using design pillars is one way to communicate what your game is about. Broad but relevant pillars that can be used as practical expressions in conversations, becoming natural staples in how you define your game. The trick is to communicate what each pillar means, and to communicate it clearly and succintly enough that everyone on the team can make good use of it. It’s something close to what genres are used for among music lovers.

The only danger here is to make pillars that are so generic that they say nothing at all, or so specific that they require too much explaining.

“Fun Gameplay” is a terrible pillar, for example. But “Quirky and Fun” could be a good one, given the right context. It’s fine if a game’s pillars change a few times through the course of a game’s development, but the more solid they are, the better they do their job: to get you away from the subjective conversation and squarely into the objective reality of your particular game.

Stating Facts

From your pillars, you can derive facts. A fact is something you can state as true and can be related to narrative, to gameplay, to the art direction, or pretty much anything else. The trick with facts is to make them extremely specific. Facts should each verify a thing that is true about your game.

Do not use facts based on falsification. I.e., things that are explicitly not true. It can sometimes be necessary, if you have tropes to rule out for example, but shouldn’t be made the norm. Mostly to keep the tone positive. This may sound weird, but believe me – it does have value.

Some sample facts could be:

  • The game has three resources: Blood, Sweat, and Tears.
  • Our main character’s name is G.
  • The main character carries a gun.
  • Guns are rare.

The more succinct and specific each fact can be made, the easier they are to remember and communicate. Filling a wiki or similar with long lists of facts will often end up having the opposite effect, however, which leads us to the next thing.

Writing One-Pagers

The way one-pagers can be used is to put pillars and facts, as they relate to a specific subject, into one single document. Say, the Gunplay One-Pager, or the Grunt Attack One-pager. This can then serve as the basis for any conversation on this topic or related topics.

This works especially well if you organise your teams in a cross-disciplinary way, since it eschews any need for discipline-specific information and gives each discipline ownership of its own respective crafts. The one-pager’s job isn’t to tell everyone what to do – it’s to lay the groundwork of what the goal is for this part of the game.

The traditional Game Design Document, often expected to provide information and detail on everything, will often waste most people’s time because the details in there are simply not relevant to them. A one-pager can keep things succinct and allow people to apply their own specific knowledge to the subject through their own planning rather than as the uninformed details of a game designer on a writing spree.

What’s important with one-pagers is to keep them short, keep them up do date, and to name everyone who is responsible for implementation so that communication can be facilitated.

Demonstrating the Game Iteratively

Facts and pillars summed up in one-pagers for cross-disciplinary teams. There’s your game design. Now go build your game.

One strength of working from a high level where everyone can ultimately understand what the game is about before they set to making it is that everyone can be part of the whole. In a very large project, this may only include the leads and directors, but the best possible situation is where this information is project-wide.

Of course, someone whose specialisation is making shruberry or shoe laces may not even want to know what the game is about, but they may still have cool ideas that can feed back into the larger conversation.

What’s most important of all once you start building things, however, is that a one-pager can be wrong. Once that feature is implemented, reevaluate it. Does it actually fit with the pillars? Should one of these facts be removed, or tweaked?

The more you do this work, the more informed your iteration, and the better your game.

Investigate Your Own Murder

Experimentation in tabletop roleplaying is a ton of fun, and sometimes an idea comes up that’s nothing more than a “what if?”

In the case of Death and Police Tape, which you can download on itch.io, the whole idea was to make a gritty (and gory) freeform horror scenario where you first died a gruesome death and then investigated that same death, having to explain it in a press release. With a new set of characters.

It turns the common GM/player dynamic somewhat on its head and lets the players drive the interesting decisions to be made.

We had a ton of fun with it, and it can be safely played in a single evening. Perfect for Halloween.

Tigers, Horses, and Weird Danish Rock Songs

When you only have a week to write a whole scenario, you often have to stick with the first thing that comes to mind. After a couple of weekends of role-playing this way, there was also many of us. The pandemic made digital hobbies a good way to do social things from the quarantined safety of our homes.

Seven players wanted to play, and the idea was to put them into two distinct groups of characters. Other things that coincided to create the splatstick survival horror scenario The Mustang Sallys was a purchase of the old Swedish OOP Splatter role-playing game. But most of all, it was the random discovery of a weird Danish rock song.

The name and lyrics of the song are NSFW, but let’s just say that I laughed out loud when I heard some of it. Combining it with some of the colorful characters of The Tiger King on Netflix, the story of the scenario basically wrote itself.

You can die from acne, you can die from scabies
You can die tomorrow, you can die tonight
You can die of cholera and you can die of plague
But you can also die of Horse

Quote from the rock song, Google translated from Danish

Credit for the cover image goes to the fantastic Joakim Hellstedt.

Cyberpunk + Heist = Grand Slam

In 2020, with the COVID pandemic in full swing, our regular role-playing group took to Roll20. Before then we used to meet once every week to play around a physical table. Something that sounds strangely exotic when you say it out loud today.

Initially, no one knew how long the pandemic would last. There were of course suspicions (that turned out right), but the idea for these online sessions became to play single-evening sessions and have a bit of fun with whatever we could come up with. We’d then resume our previous campaign once the pandemic was over.

The first of these improvised sessions was based on a poll on the gaming group’s Facebook page.

What do you want to play?

Two things came out of that poll. Cyberpunk and Heist. These were the two things that scored highest out of whatever alternatives that were provided and they became the only real foundation for what would be written.

The following week, Grand Slam saw the light of day. Five prewritten characters and a story that hinges on a gold heist. Some custom rules for hacking were added, custom-made mostly to fit the Roll20 chat we used, and we set off.

It would be three game sessions before we had finished the scenario. It ended with a bang – total party wipe. But we still talk about it fondly, having had a ton of fun.

This scenario is now available at pay what you want pricing, from Itch.io, if you feel like stealing some gold from organized crime.

Hopefully, someone out there can have as much fun with this as we had!

Ways to Not Have Cooldowns

Cooldowns are not features. They were primarily invented to solve problems in the days of latency-riddled networking and limited bandwidth. By setting a server-side cooldown, the server can ignore specified input from a client and make sure that the clock behind the scenes isn’t choked.

Cooldowns have since stayed with games, probably because many of today’s game designers grew up on a diet of World of Warcraft, but also because they’re an effective and immediately recognizable tool for balancing complex features against each other.

But the thing is: all they really do is slap an arbitrary duration on your features. They make something that could be made intuitive and skill-based live entirely in the UI space.

Traditionally, action games never used them, at least not in the ubiquitous HUD progress bars we see today.

So just for the sake of argument, here are some ways you can not have cooldowns.

Buildup

To use the feature you need to hold the button for a duration, for visible buildup, or chain inputs together. The difference from a cooldown is that it’s visible and interactive. Even if it’s still arbitrary, it moves the interaction into the game’s world space and won’t have you looking at the UI all the time.

  • Charging. Hold the button for just the right amount of time, then release. The charged shot in the Metroid games.
  • Chaining. Multiple quick interactions building up to a more massive one. Yoshimitsu’s sword thrust in Tekken.

Tradeoff

Making the feature truly interactive, but with a crucial tradeoff, puts all the power in the player’s hands and once again removes it from the UI space. Rewarding the player for learning to use a repetitive mechanic at the right time will get them closer to the coveted Flow state.

  • Combined Timing. Pull it off for a boost, fail to get penalized. Consider the reloading mechanic in Gears of War.
  • Anticipation. Time it right to avoid a negative effect, time it wrongly to get punished. The self-healing in Oddworld: Stranger’s Wrath is a good example; use it in the midst of combat, and you get killed.

Economy

The most obvious way to limit an interaction is to tie it directly to a resource. This can be something you collect all the time as you play, like ammunition in a survival horror game, or it can be something that accumulates over time automatically.

  • Hard Restrictions. Spells per day in D&D. Number of ammo rounds available in almost every game with guns. If you have the resource, you can use the feature.
  • Durability features. Weapons in Diablo or Zelda: Breath of the Wild. A different theme on hard restrictions, but the same thing in effect.
  • Accumulation and cost. Accumulating a resource along the way, enabling use by removing the accumulated value. Consider the “supers” of many popular multiplayer games, like Destiny 2 or Overwatch; and the resource accumulation and building progress bars in a strategy game.
  • Self-Regenerating Resource. Use the resource while you have it; wait for it to recharge. Stamina in Dark Souls, force powers in Dark Forces 2: Jedi Knight. But also of course health in the Call of Duty games.
  • Powerups. Temporary boosts that enhance specific features or make strong technical exceptions. When you find the Quad Damage in Quake, or the Active Camouflage in Halo, it’s the game’s invitation to make the best of it while you have it.

Context Sensitivity

Communicating a feature in a consistent way and letting the player adopt it systemically is my personal favorite when it comes to restrictions. Climb any surface in Conan Exiles; hide in the bushes of Ghost of Tsushima.

  • Activation Requirements. Web jumping in Spider-Man; web slinging in Spider-Man. It requires certain prerequisites that become fairly obvious with experience. The aforementioned dabs of paint are also like this.
  • World Requirements. Rope arrows in Thief: The Dark Project only attach to wooden surfaces. Requires that you pay close attention to the world you’re in, and invites experimentation. But also puts more demand on the level design.

Duration

Rather than having the arbitrary cooldown timer to wait for, you can have duration as something that happens because of activation. The time will still be arbitrary, but again it’s something that happens in the game world and not in UI space.

  • Activation Duration. Sprinting in Call of Duty. Many hack effects in Cyberpunk 2077. Activate the thing, use it for the duration, then you can (usually) activate it again.
  • Player-Activated Duration. You know it’ll take a certain amount of time, but you can decide when to do it. Reloading works this way in most first-person shooters. Repairing in Hawken.

Diminishing Returns

Let the player use the feature however much they want, but make it a little less effective every time. Use it too much and it loses its effect entirely.

  • Boost. Morphine in Call of Cthulhu: Dark Corners of the Earth automatically heals you to full health and sanity, but lasts a limited time. Each successive use makes it last shorter.
  • Power Loss. Attacking in Secret of Mana effectively starts a cooldown timer, but you can still attack–doing much less damage–while you wait for it to complete.

Endnotes

The pattern you should recognise is that there are many ways you can move the information you need into the game space, away from UI space, without taking away the arbitrary restriction that a cooldown really is.

You’ll still have that cooldown in practice, but it will be represented in a way that at best makes more intuitive sense, and at worst makes the player focus on the game world instead of the frontend. This is always a good thing.

By all means, use cooldowns. Just think of the alternatives before you do.

Player vs. Player in TTRPGs

In other kinds of games, PvP often means pure competition. Kill, invade, outbid, defeat. The opposition is defeated and you win, or you didn’t perform at your best today and you lose. It’s straightforward either way.

But in the land of pens, papers, dungeons, and dragons, it’s not straightforward at all. Competing player against player easily becomes personal, or invites unwelcome meta conflicts. Conflicts from the real world bleeding over into the game, or vice versa, disrupting or even ruining a game entirely.

Maybe this is why many roleplayers are adamant against intraparty conflict. It’s anathema to what roleplaying is considered to be. The elf and dwarf may bicker a bit, but at the end of the day they’re still friends. They can grow in their relationship and learn to trust each other to the point where the dwarf can be reluctantly tossed. Their differences can be safely ignored in the interest of player friendship and group dynamics.

Things like class protection, combat balancing, archetypes, and skill specialisation attempts to smooth over character differences by using the system as a context. It tells you to stay within your own personal boundaries. Many, if not most, roleplayers want it this way.

But there are ways to make intraparty conflict interesting and rewarding. Ways to make it enhance your experience.

To get to what this can look like, we’ll dive into a number of different kinds of intraparty conflict. After reading about them, maybe you’ll want to try some of them out, or you may know what warning signs to look for when it’s going sour.

Player or Character?

It’s important to note that it’s very rarely player versus player we’re actually talking about. It’s character versus character. It’s actually bad form to refer to characters as players, but it’s words that are often used interchangeably to mean the same things.

The player is the person around your table. The character is their alter ego in play, or whatever setup you may have. There are games where everyone shares a single character, games where each player plays multiple characters, and a long range of other variants that break from the one character per player norm.

But anyway, remember this difference. Your character is having a conflict with the other player’s character. You shouldn’t make things personal. It’s not actually player versus player.

Talk About It

For many players, roleplaying is a safe space, and it’s extremely important that real life conflicts don’t bleed over into the game or vice versa. Characters are heroes who delve into dungeons to fight monsters and collect treasure. They don’t glance behind their back to make sure the other heroes aren’t sneaking in to stab them when they’re not looking.

For this reason, the first step in any intraparty conflict is to explain that it exists, and that it’s fine. It’s also good to establish rules that the table can accept. General things like “avoid killing other characters,” or specific things like “Player X isn’t comfortable with raised voices.”

If you establish these things beforehand, everyone can expect the unexpected in a way that make players more comfortable.

Playing to Lose

If you play boardgames or long role-playing campaigns, playing to lose may not come naturally. You may always enter scenes intent on killing the enemy and taking the treasure, whatever the metaphorical context may be.

But if you want potentially more interesting stories, it’s a good idea to think more about what your character would do. Not just as an exercise in thinking as your character, but also as a kind of director’s or author’s perspective of what would be interesting for the character to pursue. If you play the father who is betrayed by his son, would you betray the son right back, or would you let yourself be betrayed so that your legacy lives on?

Failure and losing are natural parts of good stories, and allowing yourself to fail can often push things forward in ways you’d never think of if you always succeeded. So step down sometimes and don’t make everything about winning.

This is directly related to a human (predominantly male) instinct to say “no” to other people’s suggestions, without hesitation. Don’t say no. Say yes, but; or yes, and. Extrapolate on suggestions, don’t shoot them down. Let other players have fun without having to fight you tooth and nail. It will make the role-playing a lot more interesting.

If you can adopt a mindset of playing to lose, the rest of this gibberish will make a lot more sense.

Rivalry

This is probably the most common form of intraparty conflict and one that tends to exist in one form or another in every group, regardless of the group’s ideas on the matter.

It’s the kind of conflict that can spring up from wanting the same rewards, or planning different routes to the next stage in the adventure. No, we can’t go through the goblin caves. Yes, I deserve the shining jewel-encrusted sword.

You may not consider some of these things rivalry, in any real sense, but they are. Small inconsequential victories for the most part, but they’re also excellent opportunities for roleplaying. But they also have the same problems that you’ll see are quite consistent between different forms of intraparty conflict.

Bad Rivalry

Things will break down if the rivalry becomes petty. If you close the door in a character’s face, steal their coins, or sabotage minor actions constantly, the table will be annoyed and not entertained. Rivalry is not an excuse to behave badly or to bully one player.

Also avoid meta conflict. Someone’s rivalry against you may cause you to lose once—that doesn’t require that they lose in the future. Vendettas can escalate to absurd levels sometimes, and simply letting someone have their win causes less friction than forcing them to lose later.

Good Rivalry

Interesting rivalry should affect play when it fits and feels fair. If it goes too much against what everyone around the table believes it’ll risk becoming bad rivalry.

In a way, this goes hand in hand with the Hollywood concept of “foiling,” where you provide characters with contrasting traits to help carry each other narratively. If it fits and makes sense, everyone can enjoy it.

Mutiny

If a group has a natural leader, mutiny is the process of replacing that leader with yourself. This can be a sudden armed revolt or it can be a gradual remonstration of the leader’s actions culminating in a fair democratic dethroning. It doesn’t have to be violent, but since many role-playing games come packed with cool combat moves, it often is.

Bad Mutiny

A mutiny risks derailing a campaign, and for the wrong reasons. It easily becomes personal since it targets a specific individual. It’s not uncommon for the sum total result of a mutiny to be that one character dies, and that the player who lost that character returns with a new character purpose-built for vengeance. This is just dumb, and doesn’t make the game more fun for anyone.

Focusing on the disruptiveness and personal enmity of mutiny is almost always bad, and has ended many otherwise excellent campaigns prematurely.

Good Mutiny

Establishing the conflict in the common space, and giving it time to reach fruition, is the only practical way to do mutiny justice. Allow it to shrink and grow to the extent required, and let players veto its existence in-character if they find it necessary. Let it take time before it culminates.

A change of leadership may even happen amicably if it’s discussed by the table and not only by the parties involved. Also avoid violence to the extent possible. Violence escalates the conflict unnecessarily and tends to limit the potential outcomes to death or survival, making it suddenly more important to shoot first (like Han) than to actually roleplay a resolution. Use the threat of violence, but avoid resorting to actual violence.

Treason

A single player’s treason against the rest of the group can be a shocking reveal that takes a campaign in an entirely new direction, or it can be an eye-roll-inducing catastrophe. It can also be any of the things in-between.

In a way, it’s the thematic opposite of mutiny.

Bad Treason

If it’s too unexpected, treason is bad. If it’s too obvious, treason is bad. It has a poorly strung tightrope you must walk or it won’t work. Bad treason is also lethal or absolute in some other way. When the stranded team of adventurers realize that their plane has been sabotaged by another player, when it’s already obvious that the traitor has won, it merely becomes punctuation to a confused sentence. It doesn’t add anything. If the group got to play that event, they’d feel a lot more invested, and the sabotage can feel fair.

Good Treason

In the moment, the group needs you to push down on that red button. They also know that you have your own reasons not to. Can they trust you to do what you need to do for them, or will you side with the enemy?

These kinds of situations are hard to construct, but they’re incredibly rewarding. They shouldn’t be absolute (see Bad Treason), and they should always provide a window for the traitor’s redemption. Maybe not the fifth time it happens, but at least as a basic assumption. If you don’t press the button and a million innocents die that doesn’t leave much room, but if you don’t press the button, and someone breaks a leg, that can be redeemable.

It’s hard to balance on the edge of meaningful but redeemable, and simply criminal, and different groups will have different tolerances. But if this is hard to achieve, treason is probably not your cup of tea to begin with.

Conspiracy

Information asymmetry is one of those staples of storytelling that work for some roleplaying groups and completely ruins the experience for others. Once it’s established that things aren’t necessarily true, or that some players may be less or more than they seem, it can cause a snowballing effect of related paranoia.

Some groups thrive on this, while other groups find the integrity of the party to be a pillar that can’t be allowed to collapse.

Bad Conspiracy

When death becomes the only outcome to a conspiratorial misunderstanding, it ruins the suspense. It also escalates the meaning of information asymmetry from implicative narrative tool to death sentence.

Once more, it can become grounds for a meta vendetta that spreads across characters, time, and space, and ruins the experience for everyone around the table.

Good Conspiracy

Having to second-guess what other players say, dig deeper into unrelated statements, and attempt to connect dots where there may be no dots to connect—this makes for some great roleplaying opportunities.

You need to know more, but you also need to protect your own secrets. Paranoid inquiries, veiled interrogations, false flag actions against other characters, and all the fun staples of espionage thrillers are fantastic tools to use in intraparty conflicts and may alone warrant the whole idea of intraparty conflict in roleplaying games. Because if you pull these things off, they are some of the coolest things that can happen around a gaming table.

Revelation

In most written campaigns, big plot reveals and central developments are the GM’s to hand out. Players are the main cast, but they don’t drive the story. This is not always the case, however, and sometimes it can be great to parcel out information to the group without turning it into a conspiracy.

It can be as simple as a piece of knowledge that’s unique to a character’s background, or as complex as you want to make it. One player may be the only one who knows, same as their character, or the secret can be public knowledge among the players even before the characters are supposed to know.

Bad Revelation

“What?! Have you known this whole time, and said nothing? I’ll kill you…”

You don’t want that. You also don’t want a reveal to change known facts, at least not too much. If the archvillain of archvillainy turns out to be a nice chap who likes flowered tea, this is maybe something that should’ve been established earlier.

The timing is also important. Just as the group stands on the threshold of the new dungeon maybe isn’t the time to reveal that you’ve always known that this dungeon is home to a red dragon, when the rest of the group thinks it’s just a goblin cave. It could be an excellent opportunity for roleplaying however.

Good Revelation

Information that is allowed to be secret until it matters the most can make for powerful reveals. Of course, the danger here is that it becomes a deus ex machina; something a bit all too convenient.

A revelation can also be a good way for a player to get some more space. Especially for players who may have a hard time getting attention in a group full of very vocal players.

Survival

I need to eat and you need to eat, but there’s just the one Snickers bar. Do we share it, fight over it, or hand it to the person bleeding out in the corner?

Survival scenarios step way back down Mazlow’s Hierarchy of Needs into the personal demand for food and security. Lofty goals like saving the world seem less relevant when you’re freezing to death or being chased by the livid dead.

Bad Survival

Like few other things, survival can become truly tedious. If you need to bicker over every single thing you come across, or one character becomes too dominant or too dominated, the fun is quickly bled out of the experience.

Decisions should be important, but not all decisions can be life or death, or invite group argumentation. If you resolve one “who should get to eat today?” argument, then maybe avoid having them for a while. Let players reinforce the mood through conflicts, but don’t make it a chore. Especially not if you have the very same arguments over and over and over and over, and for several hours. Campaigns have ended under such circumstances.

Good Survival

Conflicts around survival are interesting if there are relevant choices to make. If you come across some batteries, plugging them into the flashlight or the radio provides very different options. One player is likely to represent each choice, and the conflict that grows out of it will feel natural and manageable.

Encourage players to come up with their own conflicts like this. What they need and why they need it more than someone else, then let them all take some space as it fits.

Competition

Roleplaying tends to be an activity where there is no winner. This is deeply ingrained in the whole hobby. It’s something we often write in forewords and how-to-plays. But even if the activity doesn’t generally have winners, the story may, and it can sometimes be quite interesting to explore outright competition.

We can’t all get the cool new title, or score the same in the archery competition, after all. Besides, there are games who are completely written with competition in mind. For example the excellent old Dallas role-playing game, and the ninja-powered Shinobigami.

Bad Competition

Gloating opportunities are bad. Unfair advantages are bad. All of the game design adages concerning victory apply the same to adventures or roleplaying games featuring victory.

It’s also bad if a victory is final and doesn’t leave any opportunities for continued competition. Maybe not under the very same circumstances, but in a roleplaying context it’s perfectly fine to hand out consolation prizes.

At the same time, it can be bad to devalue a prize too much. If it matters too little it can make the competition uninteresting.

Good Competition

Let everyone feel like they could’ve won, even when they didn’t. A sense of fairness goes a long way. You rarely want an outright winner-takes-all situation, but a few more layers of nuance that allows the roleplaying to take the front seat rather than the will to win. Give players some space to leave themselves out and keep the character in control.

In Dallas, the setup is strictly defined when a scenario starts. Each player wants to take control over a certain number of assets. Which assets a specific player needs to collect is only known to that player. What this setup means is that multiple players can win at the same time, and may even figure out ways to cooperate to win mutually. This makes for good roleplaying opportunities.

Endnotes

Intraparty conflict can be fun. Maybe not fun in the tickly giggly sense, but definitely fun in an entertainment sense. Some players will never like it and shouldn’t have to endure it. Other players can accept some forms, not others.

The last kind of player, where yours truly is coming from, enjoys it maybe more than any other conflicts around the table. By moving the central dilemmas of the group and their story to the players and their characters, and not to external threats presented by a GM, you open up for very different kinds of experiences.

No matter what kind of player or GM you are, there should be something for you to explore in the space of intraparty conflict.

Please, do so; and in doing so, explore more ways to have fun with roleplaying as a hobby.