The Letter Circle

Leave a comment

A thought that has been stewing for a while is “What is a form of social media I’d be willing to use?” So here is one app design that attempts to answer the question. It helps folks create and manage small social groups focused on thoughtful writings and conversation. 

The joy of letter writing

At one point, there were long form letters exchanged between experts in their field. Artists and writers would write to one another and share their latest struggles. Scientists would exchange notes on problems and theories. Many transformative intellectual works of the 18th and 19th centuries were at least in some manner influenced by letter writing. It was how specialists found peers in a geographically dispersed world. 

Having participated in versions of this, particularly during the early blogging era, there’s something uniquely generative about being forced to explain yourself in long form text. And there’s something healing and inspiring when peers respond with care and understanding. 

This practice has fallen away. In its place is the corrosive deluge of social media that trades contemplation for ad-friendly junk food. Or equally capitalist newsletters that turn the writer’s inner life into a never-ending grind to produce sufficient content in the hope of reducing subscriber churn. Even the historically important world of academic journals devolved into an incestuous bureaucracy of sclerotic noise. Current systems exhibit poorly aligned incentives to encourage interesting writing. 

Can we design a modern social system that encourages deep writing? I’m particularly interested in using some of the lessons of social systems design I’ve been exploring in the games to create planned social architecture that drive long lived communities. 

Basic structure of a letter circle

Imagine we build a website that guides people through the following:

  • Someone starts a group in a topic area of interest. 
  • They invite up to 50 people with domain expertise to the group. 
  • Each member must post at least 1 long form letter on the topic each year. This is sent to all members of the group via email. There may also be a web interface.
  • They must also post at least 2 responses to someone else’s letter. 
  • If a member does not fulfill the requirements, they are kicked out automatically at the end of the year.  
  • There is a recruitment phase where any member may recommend new members who then go through the automated invitation process. 

This covers the basic mechanical operation of the social system. We start with group formation and then onboarding new members. Next we establish social reciprocation loops. There’s also a simple measurement of participation. And ultimately a feedback loop for encouraging homeostasis. This takes the form of culling of inactive members and replenishing the group back to the ideal social density. 

What is a letter?

The central social action at the heart of this system is the letter. A letter is a thoughtful piece of writing, one to six-ish pages in length on a shared topic of interest. It is sent to people you respect and hope to correspond with. 

What letter might contain

Letters can take many forms.

  • An observation that starts a conversation
  • A problem that you are trying to solve that may be of interest to others. 
  • A cognitive tool, model or perspective you’ve stumbled across that has been helpful in a specific context you’ve encountered.
  • A description of events in your life this year. Either relevant to the group topic or your personal life. Sharing builds intimacy and trust.
  • A well-considered response to a previous letter.  

The whole point of a letter is that it contains thoughtful writing. Every writer should aim to create something that is meaningful to other members of the circle and prompts useful and interesting responses. 

What a letter is not

  • It is not a full research or white paper. Most people don’t have time to either write or read laboriously formatted texts.  Sticking within the page limit will help writers communicate more clearly and it will ensure exhausted readers don’t bail on page 23. 
  • It is not a short tweet. Complex thoughts need space to build and reveal their finer points. 
  • It is not a blast intended for everyone on the planet. You know the audience! It is your peers in the letter circle. Letters are about collaborative communication, not clout. 

Motivations of letter writing

Western society promotes the propaganda that nothing is worth doing unless you are being paid for it. This is a lie. I think folks will write letters to their circle due to the following intrinsic motivations. 

  • It feels good to stretch your mind and organize your thoughts through writing. This is a delicious form of mastery that many clever folks crave yet have no structured outlet. 
  • It is wonderful to connect with an audience of peers who respect and respond to your thoughts. 
  • We bond with one another when we share our innermost thoughts. And these social bonds can last a lifetime. These relationships become as important long term as eating and breathing. 

If you don’t like to write, read, think or connect, a letter circle probably isn’t the hobby for you. That’s fine! Twitter and Facebook have you covered. But there’s at least single digit percentages of humanity that would be thrilled to engage. 

What is a response?

A response is a shorter discussion of the letter’s finer points. Ideally it is respectful and collaborative in nature. It tries to be on topic. A response successfully closes the social reciprocation loop and builds social capital in the community. By requiring responses as part of the letter circle’s social contract, we sidestep the current issue with blog posts where people just end up shouting into the void. Writers will know someone is actually listening. A good response might contain:

  • An alternative perspective on the letter’s topic. 
  • An example that supports or provides nuance. 
  • A riff that builds off the letter’s topic. 

A good response is additive. You are playing creative tennis, lobbing ideas back and forth to make something grander. 

What a response is not

  • It is not a pithy, short comment. “Great!” “Love it!” “Wrong!” None of these are useful responses since they add nothing to conversation. 
  • It is not off topic. If you want to write something on a different topic, split it off into a new letter. 

New member onboarding

To start off a new group, you need to invite participants.  


There is a web interface that lets you invite someone to the group as long as the active population is under 50 members. 

  • Enter the new member’s email. 
  • Send a templatized invitation. Each group can customize their invitation text as desired. 
  • Press send. The invitee will get an email with the invitation text and standard instructions on what they need to do next. 

Onboarding for a new member

Once someone is invited, they must submit a letter on the group topic within a three month window. This gives them access to the group. If they do not write that first letter, the invitation is withdrawn. 

To help them make this important step, there’s a guidance page included in their invitation with the following:

  • A description of the group’s focus and higher values.  This helps create a shared higher purpose for the group.
  • Advice on formatting, length and topics. 
  • Samples of past letters the group deems to be high quality work. 
  • The rules around participation and removal from the group. This is the upfront social contract; critical to establish early in a crisp, clear fashion.

New users do not lurk. They must post. The goal here is to encourage new members to perform and contribute immediately. Their first letter is their debut. Even if they write nothing else in future years, they’ll have added value to the group with that first letter. 

Who gets to invite members? 

There are several options and which one works likely depends on the culture of the group. Some options are more complex and require additional work to implement. 

  • Anyone can invite: Anyone in the group can invite someone.
  • Group owner can invite: Whoever is the leader of the group can invite. 
  • Group moderators can invite: There’s a small group of people who are allowed to invite. 
  • Voting: Anyone can submit an invitee, but the group as a whole must vote on who gets to actually be invited. There are multiple voting mechanisms such as anyone being allowed to veto, or at least three people must vote affirmative. There’s lots of fruitful exploration here to be done to create systems of mediated shared leadership.

In general, smaller groups need less complicated official management structures. A 20 person group can easily get by with the group owner doing the inviting. A 50 person group may benefit from multiple moderators sharing the duty. If it is a particularly contentious group, voting may be the best option. 

Why the limit of 50 people?

Hyperscaling human networks are another lie technologists tell people with money. 50 seems to be about the limit at which a functional, self-managing group can form meaningful relationships and have useful conversations. Beyond this number, people tend to shut up. They don’t know who is in the group, so they become wary and stop sharing. Or there’s so much chatter people start to tune out the group as pure noise. 

Smaller groups can also work, but they risk not having enough volume of interactions to avoid stall conditions. Maybe no one responds in a timely fashion. Maybe you forget the group exists. 

So think of 50 as a number that is likely to work, but the service may need to tune it to find the actual sweet spot to maximize engagement. 

Requirements for membership

There are two main requirements to stay a member of a group

  • You post a high quality letter once a year. This ensures that the group provides value to its membership. A healthy group will be providing 30 to 50 high quality letters a year. That’s not an overwhelming amount of things to read each week, but still a useful source of information on a specialized topic. It also doesn’t put a huge burden on each member. Most of us can write a couple pages once a year. 
  • You write a high quality response to a letter at least twice a year. This ensures that people who write feel listened to. It creates a reciprocation loop that turns the group into a supportive community. One of the worst things about the modern media landscape is that we are all shouting into the void. A meaningful response from trusted peers closes the loop. 

What is an active member?

If a member fulfills both requirements they are determined to be an active member. This comes into play for reminders and automated pruning of the membership list.

There’s a big design goal behind this concept. It turns out that one of the most important things you can do for a social system is maintain a desired density of active users. You need a certain number of people performing social actions and bumping into one another 

Unfortunately most social media user facing metrics are vanity metrics, not functional metrics that reflect the pragmatic operation of the social engine. It doesn’t matter how many followers you have if none of them are active. It doesn’t matter how many friends on your friendlist you have if none of them have logged on in ages. 

What is high quality?

Quality is determined by the group. This is likely to be an ongoing discussion and there is unlikely to be one correct answer. Two implicit tools for managing quality

  • Define the group’s expectation of quality in the posting guidance page. As the group learns what quality means to them, they can update this text. 
  • Manually kicking people out. Groups may want to cull members who have broken some group norm or simply not performed up to expectations. There’s an admin option to remove someone from the group. 

Automated group management

Most naturally forming groups like mailing lists or group blogs are kept alive by the energy and attention put into the group by a leader. But leadership is rare and unreliable. One solution is to automate as much of the basic nuts and bolts of running a successful group. This ensures that even people who are not amazing leaders can still participate in a well managed and maintained group. 

Automated reminder emails

Several times a year reminder emails go out. 

  • People who haven’t posted a letter are encouraged to post. With the note they will be removed if they do not. 
  • People who haven’t responded to existing letters. 
  • People who have posted get a celebratory list of existing letters. Often people miss an email or two so it is good to showcase what’s available. 

Ideally, the reminders are edited initially by the owner of the group and signed by them. Users are more likely to react when nagged by a human with whom they have a relationship.

Automated culling

Kicking people from a group is a drama prone act. We seek to reduce drama while still maintaining the health of the community by automating this process. 

  • A final reminder email goes out one month before a member is removed from the group encouraging them to fulfill their requirements. 
  • If they still do not submit a letter, a very gentle letter is sent saying that they are being removed in order to make room for a more active member. 
  • Removed members can still be reinvited at a later point. Of course they’ll have to submit a letter to be accepted. 

Manual recruitment

If at the end of the year, there are less than 50 people in the group, an automated reminder is sent out to all members to use the chosen invitee flow. 

  • Unfortunately we can’t automate this step. 
  • We can however establish this in our onboarding materials as a sacred duty. Every new member should be told repeatedly that the group will die if people are not invited. And they are responsible for supplying emails. 
  • If not enough invites are sent out, an escalating series of automated reminders are sent to all members. 

Miscellaneous notes

Optional publishing

The system works fine as a private group. However, some groups may wish to publish either the original letters or the letters and comment more publicly. Some options in escalating cost. 

  • Publish to an existing blog. There’s lots of great blogs out there so no need to reinvent the wheel. This gives folks a lot of flexibility if they want to have a special domain for their group. This comes at the cost of maintaining an interface or plugin with a third party. 
  • The service is also a blog: This service could have a blog-like function that turns letters into web pages. This has the benefit of being self-contained. But now you have to also write blogging software. 


The letter circle system is ultimately a service. Admittedly not a very complicated service since it mostly sends emails to a small group alongside a relatively minimalist web admin UI. Still servers cost money, as does initial programming and ongoing maintenance. There are several options

  • Volunteers: If the service is small enough, a volunteer could fund most of the hosting costs of a global service. I suspect you could serve a lot of groups for even $1000 or so a year. Getting someone to devote programming time is always more problematic. 
  • Crowdfunding: Members of successful groups could donate year fees to keep the group or the service active. 
  • Self-hosted open source: The service could be released open source. 

Note: There’s absolutely no need for this to be a scalable profit-driven VC-backed entity. Business models often poison honest relationships between trusted peers. You could shoehorn in an ad-driven business model. You could slap on a subscription service. But, you know, none of these are required to support the core intrinsically motivated reciprocation loop. 

Expected Dynamics

There’s a life cycle to a letter circle. I don’t fully know what it might be having only experienced analogues, but I have some guesses. 

  • An initial burst of invites. However, this will result in only a handful of letters. Getting anyone to commit to anything these days is difficult. A new circle would need to send out many dozens, maybe even hundreds of invites to get enough participants at first. 
  • Sticky joiners come from high trust connections: High trust, high respect invites between friends are the most likely to get a response. But people only have a limited number of these relationships that they can draw upon to seed a circle. 
  • A slow start: Most circles will start with 2 to 5 active members. If they fail to invite more, activity will eventually fade away and the circle will die. 
  • Community in 2 to 5 years: If a circle can last several years, there’s an opportunity to build up bonds between members. At this point, the circle is far more likely to survive. At this point you may want to start in person meetups to convert those bonds into life long friendships.

One of the implementation tasks is watching how circles behave over time and creating support mechanisms at critical phases. 

  • Maybe there needs to be looser requirements and more reminders to invite people in the early stages. 
  • Maybe extra work needs to happen to encourage responses from members to ensure friendships begin to blossom.


This post could have been a letter. True, it is longer than hoped, but it almost fulfills the goal of being a thoughtful bit of long form writing. Unfortunately I have no circle of social systems designers to share it with. What a pity. 

Take care, 

Closed social affordances / Open social affordances in social systems design

Leave a comment


In social systems design, we often need to control how different players interact with one another. We want to heavily mediate griefing and toxicity between strangers. And we want to open up more intimate channels of communication between trusted friends so they can offer nuanced sympathy and support.

“Closed” and “open” affordances are useful concepts for talking about this challenge. Here’s a brief introduction. 

What is an affordance?

An affordance is the possibility of an interaction between a user and an object. For example, a doorknob is an affordance in the sense that it lets the user know that they can open the door and helps facilitate the opening of the door. 

Affordances are designed! 

  • Utility: Someone decided that it was more useful to put that doorknob on the door at approximately hand level. 
  • Symbolism: They also decided to make it a symbolic ‘doorknob’ shape that culturally we understand as a method of opening a door. 

Designers have almost complete control over which affordances show up in their digital world. In the real world there’s not a lot a designer can do about how ‘kickable’ their door might be. It isn’t like we have control over the users legs, kicking skills or the physical structure of the door. But in the digital realm, we can simply not create a kickable affordance. If you don’t put kicking in your game, players can’t kick the door. 

What is a social affordance?

A social affordance in a digital game is some UX element of the game that creates the possibility of an interaction between a user and another user. Again, since this is a digital space, we have complete control over what we allow. 

Closed social affordances 

There is a spectrum of social affordances ranging from closed to open. 

A closed affordance is an absolute limit on an interaction. It defines the interaction concisely and cuts out unexpected edge cases. 

For example, In Journey, they designed a closed affordance where players can only make a beeping noise if they wish to communicate. There is really no other method of symbolic communication. 

Closed affordances are useful in that they remove large swaths of problematic behavior. It is difficult, if not impossible, to insult another player in Journey. When you examine many multiplayer mobile titles, they’ve simply eliminated most social affordances. There’s no open text chat. You can’t gesture. You can’t voice chat. In many cases, you won’t even see the same people repeatedly. These limits cut down on griefing and subsequent moderation costs. 

The downside of closed affordances is that they reduce player agency and expressiveness. In Journey, the lack of persistent open communication channels means that you can never form deep friendships. By eliminating the bad aspects of humans interacting, you often also remove many of the good parts. 

Open affordances

An open affordance creates social opportunities with multiple degrees of freedom and then allows users to play socially with one another in the resulting space. They can gently encourage certain behavior, but since they impose only loose constraints, you are still likely to see a very broad range of outcomes. 

For example, you add free form chat to your game, which at a surface level only adds the ability to type letters. But sending letters lets people send language. Inevitably, you’ll witness friendship formation, personal disclosure, griefing, memes, in-groups, out-groups and a general explosion of culture. 

The more freedom you give players, the more they will abuse it. And the more robust after-the-fact moderation systems will need to be shoehorned into your game. 

However, open affordances are also the beating heart of a vibrant community. You want intimacy through safe disclosure. You want local language and practices to emerge. You want groups to form identities and boundaries. This is how humans build lasting societies. 

The inherent openness of social affordances

Social behavior is a complex emergent phenomena that blossoms when given even the most limited channels of communication. There’s the infamous story of a safe chat function in an early children’s MMO where despite incredibly limited word choices a child immediately came up with the sentence “I want to stick my long-necked giraffe up your fluffy white bunny.”

Social affordances are naturally open because humans crave social connection and will pry open channels that designers tried to close off. Given time, your community will redefine existing symbols to fit their communication needs. Or go around the social structure by moving chat outside of the game. 

If you want to remove edge cases, harshly limit communication with a small sample of canned, contextual responses and disallow freeform composition of those responses. For example, Apex Legends allows a very limited set of contextual pings that are difficult to compose into complex sentences. 

Easing players towards openness

There’s a time and a place for both open and closed social affordances. Low trust players benefit from closed affordances. It gives them time to learn the rules of the game in a relatively safe space. One where they are not easily harmed, but also one where they cannot harm others. 

As trust grows, you should design a series of opt-in gates that increase freedom for how players interact with others. You end up building a progression system that slowly unlocks more open social actions as player trust grows. 


The Workshopping Skill

comment 1

How do you cultivate a wildly productive generative engine of design creativity. Especially one detached from your ego?

Design in this case means coming up with plans and specs for the thing you are making that fits the resource constraints. And the process of workshopping designs is where a designer coming up with multiple design solutions for the same problem and iterates upon them to better fit the constraints.

Steps in the workshopping process

  • Step 0: Soak in the space. Play the game. Talk to folks in art, engineering, qa and production. Try to understand their concerns and issues.
  • Step 1: Write down your list of constraints and goals
  • Step 2: Come up with an idea that you believe in absolutely. That solves all the constraints. And delivers wonderful value. You’ve done it!
  • Step 3: Now put that intense passion aside! Socialize the design. Listen to misunderstandings. Come to terms with its flaws. What resonates? What do people start automatically building off?
  • Step 4: Do it all over again! Pick a new SEED, something out of all those chats that resonated with people. Build an entirely new solution around it.
  • Step N: Do this many more times! Until you’ve got a robust, doable idea that excites folks.

Easy, eh?


Some tips I’ve found that help do this well.

  • Be bold: Early on each new design can be wildly different. Cover a broad design space so you are working from a plentiful space.
  • Be safe: Cultivate a group of people you can share crazy ideas with in a safe fashion. If you don’t feel safe, you’ll struggle to be bold.
  • Be sure to fall in love: You need to sell this idea and provide design leadership around it. This could be the idea you ship! You should feel the Thrill when you describe it.
  • Take each idea two to three steps past obvious: First, think of the obvious thing. Now think of the next step beyond that.
  • Learn to fall out of love: Be comfortable putting your passion to the side. You can always make more beautiful ideas. You are infinite generative fire. No need to be precious. No need to get defensive.
  • When ideas start to converge, don’t settle for Frankenstein’s monster; a series of random parts stuck together by consensus. You want synthesis, not composition. A good idea’s elements supports the whole. A good idea generates more solutions, not more problems.
  • Make space: This process takes time. Give yourself the space to iterate.

Practicing the process

There are also things to practice. This is a skill you get better at over years.

  • Being faster: How quickly can you solve the constraints, fall in love, get feedback and do it all over again?
  • Being broader: Are your ideas crazy enough? Are you letting your brain be unhinged?
  • Listening: Does your listener’s face light up? What prompted them? Write that down! Can you riff off it? It could be a new seed.
  • Elegance: Solving more constraints with fewer pieces. Can you quickly come up with tight solutions to big problems? Learn to draw the goldfish with single stroke of your pen.
  • Converging: Knowing when to stop. Knowing when you’ve found the unifying thread.
  • Collaborating: The best ideas often involve a game of tennis where you bounce ideas off key collaborators. And you learn with each pass until something clicks.

Who created the final result? It doesn’t matter. Game design is a team sport and we are in this together.

– Danc.

(This was originally a Twitter thread:

The trap of adding combat to your game

Leave a comment

A thing I’ve realized making non-combat focused games is how expensive combat mechanics often end up being in the end.

If you add combat…

“The basics” to get you in the door take immense effort. Enemy design, encounter design, player design, attack/defense systems, game feel, all the art and fx.

Then once you’ve got your combat system stood up, you are still competing again thousands of games that are roughly equivalent. It is the indie puzzle platformer swamp writ large. Lotsa substitute products. Trivial switching costs away from your game.

And of those 1000s, a handful of dominant titles are beloved hobbies. Players are fans of specific game feel often tuned over decades. The tiniest aesthetic deviation invalidates all your labor.

Balance your game for 12 months, still get comments like “feels floaty. sux.”

What experience do you really want to design towards?

And the amusing part is most of the clever differentiators that I care about exploring as a designer have nothing to do with combat. Story, progression, building, discovery, social systems, emergence?

You only really get to work on those after you overcome the Olympic-level challenge to ‘make combat perfect’. Often your inclusion of ‘a little combat’ ends up starving your actual design dreams of precious development resources.

So combat becomes this trap for many types of games.

  • You have to have it. Because that’s the expected core mechanic.
  • But it is going to be overly expensive.
  • And no one will like it.
  • And it will prevent you from making the systems you wanted to make in the first place.

– Danc.

(This was originally a Twitter thread:

Don’t Solve the Hard Problem

Leave a comment

I have a design tool I call “Don’t Solve the Hard Problem”

It consists of three steps

  1. Identify: What is the expensive, difficult aspect of delivering on a highly desired user promise?
  2. Clarify: What is the actual root of the promise?
  3. Cheat: What is the the cheapest way possible to actually deliver on the root promise?

Example 1: Meaningful NPC interactions

  • Identify: Rich, Turing-testable AI is hard. Even in this era of deep learning, the results somehow feel empty. “Maybe in another 10 years…” <- The classic sign of a hard problem.
  • Clarify: But do all user actually want some weird chatty humanoid? When I talk to my players, what they really want is an emotional connection. A relationship. Someone to help and support and support them in return.
  • Cheat: In Cozy Grove, we didn’t solve NPC AI. We added an option to hug NPCs. They can refuse. But when they accept, it plays an animation. People feel an emotional connection. They feel support. That little hug is a meaningful addition to many of our player’s lives. It took less than a week to build.

Now, people working on the hard problem of NPC AI may be upset right now. The example I just gave is SO trivial. And isn’t the problem they are pouring their lives into solving.

But I didn’t have 10 years. So pivot. Solve an adjacent easier problem. It worked for our users.

(BTW, I’m constantly cheering on folks who ARE trying to solve the hard problems. It is the foundational work that moves the horizon of cheap solutions forward. Our ‘hug’ is built on digital animation tech that was a ‘hard problem’ of its own 40 year ago.)

Example 2: Massively multiplayer games

  • Identify: It is hard getting lots of players online at once. To this day I hear attempts at putting 1M concurrent players in the same space. Ugly bandwidth, CPU, replication, base costs and more result.
  • Clarify: What if player just want to be with friends? Sometimes lots of people, sometimes a few. What if “lots” and “few” and “friends” was a feeling that we could design for instead of a numerically large concurrency number?
  • Cheat: We’ve done experiments. Many times more than 30-50 people in a space feels like “lots”. Past 100, feel free to use bots or popular samples. No one can tell. Most successful multiplayer games deal primarily with smaller groups. What is the 4-12 player version of your game?

I remember old 1v100s discussions where 1M concurrent players was bandied about. Massive tech expenses resulted.

Yet most people played in 4-player matches. I’m always curious how the host wrapper could have been faked and that core 4-player feeling of being together enhanced.

Example 3: AR glasses

This one is more fanciful because the current discussion irritates me.

  • Identify: There’s a hard problem with a high FoV, high contrast, low latency, stable image that overlays the real world, works with the human eye and fits in glasses.
  • Clarify: The user fantasy I hear over and over again is “I want to remember the names of people I see”. There are others, but 8 out of 10 times this is the first use case real people can imagine for the tech.
  • Cheat: Why are we even focusing on the visual display for this problem? Seems totally secondary. One solve: You need a camera, a list of friends, face recognition, activation UI (voice? button?) and some headphones for feedback. All these things exist right now.

Ok, maybe the TRUE user fantasy is that this process is unobtrusive. Maybe we need to add a secret ring you can click and fiddle with to active the camera. Maybe we need the camera mounted on your head or eye tracking software to clarify intent.

Harder, but not the original hard problem

And what can you do with that boring platform? Translate text you look at. Identify objects. What the broad category of ‘finding out stuff about the world’ where the world is your affordance and looking is the pointer?

To me, this is still a hard problem. But at least it puts energy into something very solvable. And it isn’t some BS derived from fictional movies or tech executive wankery.

Imagine if this design thinking was applied to web3 or the metaverse. 😉

Look for the bodies

As a final note, when identifying hard problem, look for the bodies. Is there a history of smart people spending money and blood in this area with poor results?

Is there a slightly different problem to solve? One delivers what folks need, not what you’ve been told they want?

– Danc.

(This was originally a Twitter thread:

Why are game designers wrong 80% of the time?

comments 2

The joke goes: An expert game designer is 20x more effective than a newbie. They are correct 20% of the time instead of 1%.

Why are game designers wrong 80% of the time?

Sometimes they are wrong by a little. Sometimes by a lot. Is it poor planning? Are they morons? An expert painter does not produce a completely broken picture 80% of the time. Why is this so hard?

The feedback loop for creating other media is fast

I lay a lot of blame on the much larger gap between authoring a thing, experiencing the thing and revising.

  • Many types of media (like drawing or painting) allow for real-time ‘self-playtesting’ with the author as the playtester.
  • Game design does not.

When I draw, I am constantly engaged in a tight real-time iteration loop of authoring marks, viewing the marks, reacting to the experience as a viewer and adjusting the next steps. There are 1000s (often tens of 1000s) of feedback iterations.

Same goes for writing. There are larger editing passes that occur at lower frequencies, but even within those passes, I’m in a real-time create-experience-revise loop. The first draft is really the 5000th draft of the ‘self-playtesting’ process.

Now, when writing and drawing, I can’t predict exactly how someone-who-is-not-me will react. Death of the Author and all that. But an experienced artist and writer can often get within the ballpark for a familiar target audience. Sad scenes are sad. Happy pictures are happy.

The feedback loop for creating games is slow

Contrast that with games. 🙂 Some issues where the create-experience-revise loop breaks down.

  1. Much longer iteration times. If I’m lucky it takes minutes to make localized changes and test them out. More typically it takes longer.
  2. Due to interdependencies some changes can’t be fully experienced by the player until months later when all systems are fully in place. I just worked on a game where it took 1.5 years before we were able to test the basic flow and balance. This is common. Imagine having to paint a picture blind and wait a year before you can look at it and see if you painted it correctly.
  3. Game developers often are corrupted playtesters. Many games involve mastery and knowledge. The designer, due to knowing what they know, becomes blind to issues new players will face. Empathy only goes so far, even when designers roleplay the ‘new player’.
  4. Other systems (social systems, emergent complexity, proc gen, randomness, exponentials) are just hard to mentally visualize. We can plan them out, but the experience of playing them is often (deliberately) a surprise. There is no accurate ‘self-playtesting’ for these systems. A game designer’s has limited ability ‘play the game in their head’ and so real (slow) playtesting is required.


I don’t know of a perfect fix for any of this, but we have some tools.

  • Sketches: Movie makers (who also have extended pipelines) create low fidelity animatics that get to viewing the experience faster and cheaper. Game developers create prototypes that serve a similar role. It doesn’t work perfectly for all systems, but better is than nothing.
  • Genre expertise: Teams keep rebuilding games in the same genre over and over again. It might take years, but eventually you get to those 10,000 iterations. In large part, this is how expert designers even get up to that not-so-respectable 20% rate.
  • Community playtests: A large population of players + live development (early access, games-as-service) maximizes playtest feedback. Richer feedback can help counterbalance the slow iteration.
  • Content systems friendly to late-stage fixes: If you know that you are almost always going to be making big changes due to late feedback, you can build flexible pipelines that are easy to refactor. A proc gen system that creates 1000 levels constructed from modular components and centralized formulas is easier to tweak than 1000 handmade levels. Neither change is safe right before release, but at least the former is feasible.
  • Planning up front. There’s room for more waterfall style approaches. Particularly if you are reusing code, tools and have an experienced team. It works for things you know that you know. But this is surprisingly limited in other areas that comprise the bulk of game design.

So unlike writing or painting, the meta of game design is painstakingly building a process where you can iterate as quickly as possible, while making as few changes as possible, while still enabling big change to be feasible late in the process.


(This was originally a Twitter thread:

Value chains – A method for creating and balancing faucet-and-drain game economies

comments 5


The problem with picking up sticks

Recently I was designing the harvesting and crafting system for our Animal Crossing-like game Cozy Grove when I ran into a problem: picking up a stick is not that fun. 

The core activities in a life sim are generally not full of mastery and depth. You chop trees. You dig holes. You pick up sticks. In isolation, each of these is dull. Our playtesters would harvest a leaf pile, get some sticks, and then put down the controller. They’d turn to me and ask “Uh, okay, where is the game?” 

If we were following the standard advice on prototyping core mechanics, we might as well stop development right there. Clearly the core was not fun. We tried extending the loops out from 5-seconds (gathering), to 30 seconds (wandering), to 5-minutes (selling). No luck. My playtesting group hated the game. 

Yet life-sims do exist! And they are delightful. Clearly there’s more to establishing value in a game than just perfecting a ‘fun’ core mechanic. 

Discovering value chains

It wasn’t until we spent 12-months building out the rest of the game – the crafting, the decorating, the daily pacing structures – that players finally began to value picking up sticks. Because it turns out the value of sticks was entirely driven by their utility in reaching future goals. And if those future goals don’t exist, the sticks have no value. 

You tend to see this scenario in high retention, progression focused games

  • The core mechanic is not the sole or even the primary driver of player value. 
  • Value for a particular action comes from how it facilitates subsequent activities.
  • Often players engage in long chains of rote economic activity in order to reach their actual final goal.

Why you should care

Understanding how to generate meaning with sticks is not an idle concern! High retention, progression focused economic systems are at the heart of most games as a service (GaaS). There’s a huge demand for economy designers who know how to build and balance robust game economies that provide rich value to players. 

Getting your economy design wrong costs time and money. Very often, it can kill the game. Yet game economies are also a rarely discussed black art. So it is hard to know where to start. And hard to hold constructive conversations with your team. There’s an inherent complexity to the topic that makes matters even worse.

So let’s try to improve the situation. 

What this essay covers

We’ll cover the following. 

  • Chapter 1: What is a value chain?
  • Chapter 2: Balancing value chains
  • Chapter 3: Architecture of multiple value chains
  • Chapter 4: Establishing endogenous meaning in games

The whole essay is around 30+ pages and can be a bit technical. Feel free to take it slowly. But if you are interested in game economy design, this is a good crash course.


We’ll model game economies and associated activities as endogenous (self-contained) value networks. These networks are composed of value chains. The value chains combine to form a full faucet-and-drain economy. 

Basic structure of a value chain

This is the shorthand I use when jotting these out on paper. 

  • You get a stick!
  • Which lets you make a lamp
  • Which lets you decorate your house
  • Which satisfies your need for self expression, the ultimate motivational anchor for wanting the stick in the first place. 

Notice the structure

  • Each node contains an output of some (currently unspecified) action. 
  • The nodes are connected to one another in a linear fashion that’s easy to read. No strange loops or spaghetti-like diagrams. 
  • The chain terminates with an anchor node representing player motivations. 

There’s a lot that’s not specified here in the shorthand version. We’ll get into more verbose versions below.  

But you can see some useful traits

  • By jotting this down, you are forced to consider the direct purpose of each resource. 
  • And how it relates to ultimate player motivations. 
  • If the chain is broken, imbalanced or obfuscated in some way, players will stop finding value in the early steps of the chain. 

Inputs and outputs

Now let’s look at a more verbose description of a value chain. In practice each node is composed of three elements:

  • Action: What the player (or the game) is doing to cause a change in the world. 
  • Inputs: Resources that the action requires. These can be tangible resources or abstract concepts like time. 
  • Outputs: Resources that are the result of the action. Again, they can be concrete or abstract in nature. The anchor node is always abstract since it represents an internal psychological state. 

The diagram above is pretty, but hard to quickly put together. In practice, I use a text-based format that can be typed out in any basic text editor. Feel free to adapt the formatting to your project; it is the ideas that matter. 

In purely text format, we get something like:

  1. ChopTree (-treeHealth & -player time) -> +stick 
  2. Craft ( recipe & -stick & -rag ) -> +lamp 
  3. Decorate ( lamp, other decorations ) -> Decorated Space 
  4. Decorated Space -> Self-expression anchor

What this says is: 

Step 1: “ChopTree (-treeHealth & -player time) -> +stick”

Player chops a tree and gets a stick. 

  • The symbol means that the action consumes treeHealth (a variable on the tree) and player time. This makes the action a sink in economic terms.
  • The & symbol means that this action takes both health AND player time. If one is missing, the action can’t be performed.  
  • The + symbol means that this activity is a source for sticks. 
  • The -> symbol splits up input activities from output resources. 
  • The action is italicized for clarity. 

Step 2 “Craft (recipe -stick -rag) -> +lamp”

Then the player crafts with a recipe, stick resource and rag resource. 

  • The stick and rag have the symbol next to them indicating this action is a sink for those resources and they are removed from the game economy.
  • The recipe is not consumed. It has no next to it. 
  • The output of this action is a lamp. Notice the + symbol signalling a source. 

Step 3: “Decorate ( lamp, other decorations ) -> Decorated Space”

Then the player decorates with the torch

  • The , symbol represents options that are valid inputs. Decoration can occur with the torch OR any other decoration. 
  • There’s no concrete new resource here that is produced but we do get a decorated space as an output. 

Step 4: “Decorated Space -> Self-expression anchor”

Finally, the player serves their goal, which is to express themselves. Self-expression is a strong intrinsic motivation for some players and acts as the anchor for the entire chain.

Key concepts when working with value chains

Now that you have a definition of value chains, let’s look at how they tie into some other important game design concepts. 

Value chains are one way of structuring your game’s internal economy

Internal economies refers to the practice of modeling economies as a network of the following basic operations

  • Tokens: Resource tokens that flow between various nodes in the network of player or system operations. 
  • Sources: A node that creates new tokens and add them to the flow.  
  • Pools: Nodes that accumulate or hold some number of tokens
  • Transforms: Nodes that transform of tokens into other tokens
  • Sink: Nodes that destroy those tokens. 

For a rich description of how internal economies work, read Joris Doman’s book Game Mechanics: Advanced Game Design. He goes into common design patterns and explains the ideas in more detail. 

You can describe almost any economic system in a game using these basic elements. But that flexibility also can be overwhelming and hard to communicate. 

Value chains are a specific sub-case of an internal economy. They make use of all the basic operations but in a far more restrictive manner that makes both the construction of economies and more importantly, their subsequent analysis easier. 

Value chains are a form of “Faucet-and-Drain” economy

In a typical real-world economy, tokens circulate in enormous pools that slosh back and forth due to feedback loops and emergent market dynamics. These are enormously complicated and difficult to visualize. 

However, value chains focus on a simplified cartoon economy known as a faucet-and-drain economy, defined by strong sources and strong sinks, limited object lifespans and limited circulation of goods. 

Example of a ‘faucet-and-drain’ economy from Ultima Online, The In-game Economics of Ultima Online, Zachary Booth Simpson, 1999. 

A faucet and drain economy (like the one visualized for Ultima) might seem complicated at first glance, but it has some greatly simplified attributes

  • Faucets: Resources in the game are generated from nothing as needed. They are virtual so we can make as many as we want (or as few)
  • Transforms: The resources flow mostly one way into a series of transforms to produce various other elements players desire. These are all designed game activities. 
  • Drains: We get rid of excess materials. Again, they are digital so there’s no unexpected externalities like pollution or landfills. We press a button and boop, they are erased from existence. 

These faucets and drains map directly onto the various portions of the value chain. 

  • Early stage of the value chain has sources: Players perform actions (the core gameplay!) and generate a steady flow of base resources. 
  • Mid stage of the value chain transforms resources: Those resources are transformed into a very small number of intermediate resources. 
  • End stage of the value chain has sinks: Finally players pay resources into sinks that help them gain access to whatever their anchor motivations might be. As a result, there is a steady stream of goods being destroyed. 

Faucet-and-drain economies have some really useful attributes for economy designers.  

  • Constant demand: There’s a nice velocity of goods flowing through the economy and out via the sinks. This means we can easily incentivize players to continue engaging in gameplay actions that generate resources. 
  • Limited feedback loops: There’s limited pooling of excess resources. This leads to simpler dynamics and fewer unexpected feedback loops. 
  • Easier explanation: Real economies are complex and hard to talk about. A faucet-and-drain economy is much easier to explain to players. This lets them form models of cause-and-effect and helps with their long term planning and engagement. 
  • Easier balancing: You can usually trivially balance sources and sinks against one another.  If there isn’t enough of a resource being created, the designer can tweak some number so player actions generate more. Or decrease the cost of sinks. If there is too much of a resource being generated, the designer can increase the cost sinks or reduce the sources. 

Game economies as cartoon economies

Note: You don’t see many pure faucet-and-drain economies in the real world. All real-world economists need to deal with the messy reality that real-world extraction of resources and making of objects is incredibly expensive. You can’t wave a magic wand to increase some source of scarce goods. So instead, we see more circular economies where limited rival goods are created infrequently and then circulate within a competitive market for a long period of time. Your modeling must include supply chains, warehousing, environmental externalities, transaction costs and more. 

Games economies are special since there is zero cost to creating, transforming and destroying new digital resources. If we want every person in the game to get a puppy, we snap our digital fingers and it is done.

This means every economic feature associated with supply chains, transaction costs and various externalities is a design choice; we include them if they make the game better. As digital economy designers, we can use these special powers to make our job as game economy designers easier and the experience of playing the game better for our players. 

Value chains are structures for creating demand 

A node creates demand and value for players to engage with earlier nodes in the chain. You can say that a node ‘pulls’ resources up from those early nodes. 

The powerful sinks at the end of each value chain acts to maximize flow of resources through the chain. Because we usually want clear systems of cause and effect so players can easily plan ahead, building murky pools of inscrutable assets can hurt gameplay if not done with care. 

Big pools reduce pull. However, see “The emotions of scarcity and abundance” below for more detail on how planned scarcity and abundance (within a narrow band of outcomes) can drive desired player emotions. 

Value chains connect to real world motivations through Anchors

Traditionally, when we think of value, we often think of valuable goods as those that serve a physical need like food or shelter. However, in games, there is no actual need for food or shelter to satisfy. A game will not feed you if you are hungry. Instead valuable digital goods are those that serve a player’s psychological needs. Game food in a game like Valhiem fulfills a player fantasy of survival (mastery over the environment), not actual hunger.  

When designing value chains, anchors are how we define and represent these psychological needs. And by inserting them at the end of each value chain, we call out how meaning is carried through the earlier stage economic nodes. A powerful anchor can be a big reason why earlier nodes have value. If you don’t identify how each node serves your psychological anchors, you’ll very likely end up with disconnected nodes of isolated atomic meaning. 

Other sources of meaning: Each node can always generate meaning. It can contain a beautiful interaction. Or a delightful puzzle. Or moment of insight. By no means am I saying that only economic value networks provide meaning or value! However, if you can connect these small moments of value together by a self-reinforcing value network, you build a self-consistent space for players to form and pursue meaningful goals. 

Possible anchors: There are lots of motivations that act as anchors. For example SDT (Self Determination Theory) lists

  • Autonomy: Do you accept the decisions you have made?
  • Competence: Do you feel like you are gaining mastery or competence in your actions 
  • Relatedness: Are you supported and do you support others in a pursuit of self determination?

Or you could reference work by Quantic Foundry, who has tried to map out some of the player motivations from popular games. 

  • Destruction
  • Excitement
  • Competition
  • Community
  • Challenge
  • Strategy
  • Completion
  • Power
  • Fantasy
  • Story
  • Design
  • Discovery

Player interviews: Ultimately, these models are only a starting place for finding your game’s anchors. You’ll discover that needs are nuanced and perhaps best uncovered by talking to your players and finding what resonates with them. When you hear that your game changed someone’s life for the better, don’t roll your eyes. You are likely observing an anchor for a value chain.

I remember once someone told me that my cooperative factory building game helped restore his faith that people can be good. And how he made lifelong friends just through playing the game. Those shared goals, trust and long-term friendship are powerful anchors that made the atomic actions of placing road tiles and cranes very meaningful. 

The deep meaning behind value chains is this: By understanding anchors you start to understand how your game provides tangible value to your player. Games are never ‘just games.’ People play them (and keep playing them) because games add real value to their lives. You need to design with that goal in mind. 

Can economic systems serve intrinsic motivation?

At the most basic level, extrinsic motivations are when you feel forced to do an action in order to attain some other purpose. Intrinsic motivations are when you want to do an action for the sake of the action itself. 

It is around this point that folks trained in the pop-psychology pits of YouTube game design start worrying that economic systems of this sort promote coercive extrinsic motivators. The actual answer is complicated. 

Some things to keep in mind that are usually not discussed in a typical like-share-subscribe rant. 

  • Extrinsic vs Intrinsic motivation is a spectrum: It is not a binary. A lot of things we do are a little extrinsically motivated and a little intrinsically motivated. So if you are desperate for black and white morality, be aware this is a topic that is mostly shades of gray in practice. 
  • Individual perception matters: People often move from being extrinsically motivated to being intrinsically motivated for the same exact action and reward as they incorporate the action into their personal feelings of self-determination. For example, at one point I made a french press coffee each morning to wake up and get my caffeine. It was extrinsically motivated, rote behavior. But then I started thinking of myself as a coffee drinker and over time the rote activity turned into a ritual that I truly enjoy. People shift and change. Perception is often more important than the exact mechanics or numbers involved. 
  • Intrinsic motivation is often a journey: The story about coffee suggests another truth. Players don’t start out intrinsically motivated. Often they are just playing around, following once bright sparkly to the next bright sparkly. Overtime they discover how a set of rote actions serves one of their unmet deeper human needs. This can take time and learning! But by the end of their personal journey, the previously rote actions are transformed. They become time spent with purpose and intention. 

Why you choose to perform a rote action as well as your level of personal buy-in to this choice have a huge impact on whether or not an activity is seen as intrinsically or extrinsically motivated. If you are interested in this topic, I highly recommend doing a deep dive into SDT since it is one of the few experimentally verified models of key factors involved in shaping motivation. 

Some tips

  • Design each action node to support feelings of autonomy, competence and relatedness. The more each moment in the game supports feelings of self-determination, the more likely players feel intrinsically motivated. 
  • Ensure each anchor supports feelings of autonomy, competence and relatedness. If your ultimate anchors are tied to materialistic numbers going up like “Make as much money as possible”, you really aren’t supporting any of the key factors related to intrinsic motivation. 
  • “Mastery” is often a short term motivator: Historically games have focused on helping players feel competence by teaching them novel skills. For example, you learn to double jump for the first time or beat a new boss puzzle. But eventually players learn the skill and chunk it into a rotely executed tool. True evergreen mastery mechanics are rare and expensive to invent. But ‘infinite mastery’ doesn’t need to be the goal of every mechanic in your game! Because it turns out that rote competence in service of other unmet needs still triggers feelings of competence! Think of mastery in terms of the player creating cognitive tools they can then apply to serving higher order needs. 

Things to listen for in playtests 

  • Coercion: Do players say they feel coerced into doing something? If you hear this, you are leaning too heavily towards extrinsic motivators. 
  • Changes in perception: Do players say “This didn’t meet my initial expectations, but now I really enjoy it.” That suggests players are transitioning from extrinsic motivation to intrinsic motivation. Ask them why they enjoy it. There’s a very good chance you’ll discover some powerful anchors in your design (that you can then amplify or reveal sooner!) 

The big picture: There’s a fun study that suggests games that lean heavily on intrinsic motivation tend to improve player’s well-being. And they tend to have longer term retention and improved monetization. While games that lean heavily on extrinsic motivations tend to harm player’s well-being. 

So even though the topic is messier than suggested by internet moralizing, it is still worth building in the factors of intrinsic motivation into every step of each value chain.


Why you balance your economy

One of the critical jobs you’ll perform as an economy designer is making sure your economy is balanced. As game developers, we are selling amazing experiences and a poorly balanced economy leads to a crappy player experience. 

From the player perspective, an imbalanced economy produces complaints that look like the following: 

  • X activity or resource seems pointless. 
  • X is boring
  • I didn’t even notice X
  • I don’t understand why I’m playing. 

These mundane phrases are some of the most important pieces of player feedback a designer can hear. Your players are not being stupid. They are giving you incredibly valuable signals on what is wrong with your game. 

Role of value chains in economy balance

There are many potential root issues that drive this sort of feedback. The trick is finding them. For example, an abundance in one location might be driven by a lack of sinks further down the chain. If you don’t know the structural dependencies of your economy, you’ll struggle to pinpoint the root cause of a player’s report. 

Value chains provide an analytical framework that helps you do the following:

  • Define each resource in the game and why each is valuable. 
  • Define structures for how resources are relate to one another in a meaningful way. 
  • Analyze, pinpoint and fix issues where resources or activities are not valuable. 

Every prototype you make starts out poorly balanced. And then you iterate on the balance to make it better. Value chains speed up iteration by simplifying the underlying problems and helping you identify and classify observed problems faster. They help you reduce the cost of fixes by targeting specific problems while limiting ripple effects.

Balance from the technical perspective

From a technical perspective, we can define a balanced value chain as one where there is a strong enough set of anchors and associated sinks to consistently pull resources up from all nodes along the chain. 

  • The player is motivated at each node to perform game activities in order to reach subsequent nodes (and ultimately the anchor)  
  • The player doesn’t face an overabundance of a particular resource that swamps sink or makes exercising an earlier node’s activity meaningless. 
  • The player doesn’t face extreme scarcity of a much needed resource that makes grinding an earlier node laborious or irritating. This can lead to pacing delays or grinding burnout. 

There are a few key steps to balancing a value chain.  Each of these is a major topic we’ll cover in detail. 

  1. Step 1: The structure of the value chain must have clear links of cause and effect carrying over from each node all the way to the anchor. 
  2. Step 2: You need to identify the types of sources and sinks used in your value chain.
  3. Step 3: You need to match the power of your sinks with the power of your sources. For example exponentially increasing sources should be matched by exponentially increasing costs on sinks. Mismatches here result in nearly impossible to balance economies. 

Step 1: Debug the structure of the value chain

At the most fundamental level, a value chain is a connected series of economic actions. If the links in the chain don’t connect to one another at a structural level, the chain fails. This is super useful! 

  • We can look at the structure of any specific chain and quickly identify structural errors without taking into account the massive complexity of the whole economy. 
  • We can often further focus on a single node in a single chain to identify the issue with great specificity. 

Errors at the structure level are great to catch early since they often result in economies that are impossible to balance. Defining and debugging the structure of your chains is a wonderful pass on any economy design task. 

Issue: Break in the value chain

The most common root issue is that there is no subsequent link in the value chain! Most actions in games quickly get mastered, chunked up and turned into a rote task. If there isn’t a reason to do the action, it becomes as meaningless as a disconnected doorbell. 


  • Write out the value chain for this action. 
  • Make sure there’s a consistent chain of nodes all the way to an anchor. 

Issue: Lack of sufficiently compelling anchor

Identifying compelling anchors is a rarer skill. So many designers just leave out this step entirely. However, the game then falls flat and they don’t know why. 


  • Your intrinsically rewarding anchors are often very related to your game’s core pillars or promises. 
  • Do the exercise of asking what players really want out of your game in terms of need fulfillment or core motivations. 
  • See if you can have your value chains directly contribute to these ideas. Your game will become stronger. You’ll also gain a culling device for eliminating features that don’t serve the pillars of your game. 

Issue: Visibility on the chain of cause and effect necessary to reach the anchor

In games, players engage in interaction loops that teach skills on how to manipulate the world. Interaction loops and arcs (also known as skill atoms or learning loops) are the fundamental iterative sequence of modeling, deciding, acting, processing and responding that occurs within any computer mediated interaction. It is the heart of any interaction design. 

Here’s how interaction loops map onto value chains

  • Each interaction loop directly corresponds to the action element inside node of the value chain. For example, there is an interaction loop about learning to harvest leaves. And that maps onto the value chain node about harvest leaves and getting sticks. 
  • Exercising an interaction loop yields emotional reactions. There’s evocative stimuli (ooh, pretty jewels go pop!), mastery, autonomy and more. 
  • A player exercises an interaction and learns cause and effect. A chunked skill always results in a lesson, or cognitive tool for how an interaction can manipulate the game. For example, players learn that if they harvest a leaf pile, they’ll get sticks. 
  • The player can then use their new acquired tool to pursue goals. This corresponds to a subsequent node in the value chain. For example, if a player wants to build a decoration, they now know they need a stick.

Interaction loops are recursive in nature and occur at pretty much every level of gameplay. I’ve written a lot about them over the years and they are essential to almost every part of my design practice. But that’s far too much to cover in this relatively small essay that I’m desperately trying to keep focused on game economies. If you want more information on interaction loops, check out this presentation: Interaction Loops – Public

The important part is there are many ways a specific interaction loop can go wrong. The interaction loop may have the wrong affordances. The game could provide poor feedback to the player. The player might not have learned foundational skills. Etc, etc. 

This is also a deep topic. For more information on how to diagnose issues with interaction loops and skill chains see: Building Tight Game Systems of Cause and Effect 

From the perspective of analyzing value chains, you should know that a failure inside a single node of the chain can destroy the value of all subsequent nodes along the chain. Knowing these dependencies can help you backtrack and find the root causes. If you can track a big economic issue down to a single interaction inside a single node, you can make far more targeted changes. 

Issue: Visibility of the anchor

You may have a strong anchor for a value chain, but only long term players end up figuring it out. And new players, because they don’t see how the game fulfills their needs, decide to leave early. 


  • Identify your value anchors and tell them to the player at the very start of the game. This is your player promise
  • They won’t be able to experience the satisfaction of the anchor immediately, but they’ll know what they are working towards. And this should give them a long term goals and perspective on the long term payoff of current tasks. 
  • The player promise can be couched using a narrative frame. For example, a need for completion and accomplishment is often couched as ‘beat the game’.  A need for dominance and mastery is often couched as ‘beat the final boss’. These simple frames help contextualize the abstract psychology of an anchor as a familiar concept. This can provide enough visibility on an anchor to justify earlier actions. 

Issue: Weak player motivation associated with the anchor

Motivation and their associated narrative frames are not universal! Many players don’t care about dominance or mastery. In our life-sim, Cozy Grove, players were actively repulsed when mastery elements were experimentally added. If you present the wrong audience a game about beating the final boss, they will leave immediately because their true needs are not being met.  


  • Talk to target players. Tell them your player promises. See if they are excited! If you are a new developer pound into your head that there is no universal gamer profile. Nor is there a game that is perfect for everyone. (You’ve been lied to if you believe this) 
  • If they aren’t excited, you need to either find a different set of player promises or a different target audience. 
  • Don’t be afraid to workshop your player promises until you find a strong audience fit. A mismatch here can cause your game to fail before you even start. 

Step 2: Identify types of sources and sinks

In more freeform descriptions of internal economies, there are innumerable ways of adding resources and extracting resources from the economy. Once you start including feedback loops, pools, conditionals on actions and other attributes of an internal economy, you might as well have written a full Turing complete simulation. Such a system is difficult to explain, difficult to reason about, and difficult to balance. (Check out if you are interested in exploring what these simulations can look like. It is a wonderful tool.) 

In my personal practice building game economies, I’ve hit upon a relatively robust simplification where I categorize source and sinks into a few common categories. There are certainly edge cases that these types will not cover. However, by restricting your economy design to well-defined and easily manipulated components, you make balancing far easier. 

In this section we’ll talk about how to approximate complex economic structures with various curves. 

  • The 5 major types of sources: Capped, Trickle, Grind, Investment and Random
  • The 4 major types of sinks: Fixed, Repeatable, Exponential, Competitive
  • The 3 big balancing challenges: Scarcity, Abundance, Variability

Source Type: Capped (Constant) 

Capped Example A: At first interaction, the player gains 10 resources. And no more afterwards

In this type of source, there’s a fixed amount of the resource that comes into the game via some action node (or nodes). 

  • Player completes an action. I sometimes use the metaphor of ‘turning a crank’ where the player needs to execute a full interaction loop of: mental model -> decision -> action -> rules processing -> feedback -> updated mental model and resources. 
  • The total amount that comes from the action is fixed
  • Executing the action again (if even possible) does not provide more of the resource. 

Some variations on capped sources include:

Capped Example B: You can perform the action multiple times, but you get a capped amount of resource
Capped Example C: You perform the action multiple times and get diminishing returns that rapidly converge on a value that is equivalent to a capped number.

Capped sources are one of the most common sources, especially in single player games with a fixed completion point. They tend to be used in easy to control systems, but can be a little brittle. We’ll get into that more when we discuss numerical balancing. 

Source Type: Trickle (Linear) 

In this type of source, there’s a fixed rate of a given resource coming into the world during a given time period. 

Trickle Example A: Every time period (t), we gain 2 resources. This is a linear equation where TotalResources = 2*t
  • Again, like with capped sources, a trickle resource delivers resources whenever an action node is completed. 
  • However, unlike capped sources, you tend to get a consistent amount every single time the action is repeated. Forever. 

Accumulation challenge with trickle sources: On larger time scales, you can accumulate an infinite amount of that resource. Say you earn 10 gold every day for signing into the game. After 10 days, you have 100 gold. After 100 days, you have 1000 gold. After 2 years, you have 7300 gold. 

When players have an excess of a resource, they are less economically motivated to engage with the production nodes of its value chain. Though they may still perform related actions for the intrinsic joy of it, the marginal value of gaining an additional resource is low. 

We’ll keep seeing excess accumulations show up as one of the failings of an imbalanced economy. 

Variation: Limited actions per time period: In Animal Crossing, there are 6 rocks that spawn in the world and can be mined once a day. This is still a rate limited source, but the limit is placed on the actions the player can perform, not the amount of resources produced. 

Variation: Capped pools fed by a trickle source: A common type of trickle resource is energy in a F2P mobile title. Energy recharges each day and can then be spent on a limited number of actions. Some elements of this patterns

  • The action of the energy production node is simply ‘waiting’. Time passes and you automatically get more energy. (You can pay, but that turns this into an investment source, which we’ll cover in detail below) 
  • There’s a capped pool, which is a pool that holds the energy resource. It is capped in that it only holds some maximum amount. After reaching the cap, any additional energy is lost. 

Capped pools are one partial solution to the accumulation challenge. In our gold example above, imagine that gold feeds into a treasure chest that can only handle 100 gold. If you wait 10 days, you’ll have 100 gold. If you wait two years, you’ll still have 100 gold. 

Capped pools are unfortunately not a complete solution. Someone who diligently empties the pool every day still will be able to spend all 7300 gold over two years. So you still need a mechanism for dealing with excess. 

Source Type: Grind (Linear) 

A grind source is one where players can spend near unlimited external resources such as time or money to increase the amount of a given resource. Again, you’ve got an action the player performs on a node that generates resources. But they can grind that action by performing it as many times as they desire. 

Though on the surface this looks a lot like a trickle or capped source, from a balancing perspective it is very different. 

  • The total amount is mostly uncapped. It is limited only by how much a player wants to grind overall.
  • The rate is also mostly uncapped. It is limited by how much a player wants to grind in a day. 
Grind Example A: Player 1 plays 4 times as much as Player 2. And extra on the weekend. They earn a huge surplus relative to player 2. 

The most common example is that the player invests more time by repetitively performing an action again and again. Though time is limited in reality, in practice we often balance our games by assuming a certain moderate level of engagement. And someone who plays 14 hours a day, 7 days a week can grind out surprising amounts of a resource. 

Variability Challenge: The big problem with this source is that it is highly variable, which makes it hard to balance. A player could not grind at all. Or they could grind 18 hours a day for 300 days. In one case, you’ve got scarcity. In another case, you’ve got overabundance. Both players will complain that the economy is poorly balanced. 

The pattern of play varies how much a grind source produces. In the chart above, we see a bump for player 1 during the weekend. They may experience a huge glut of resources as a result. 

It is often good to convert this into a capped or trickle source. Or pair it with an exponential sink. 

Source type: Investment (Exponential) 

A common structure in internal economies is the positive feedback loop

  • Player does an action
  • This gives them resources. 
  • But these resources ‘feed back’ into the original action. They can invest the resources to do more of the action. 
  • Which in turn gives them even more sources that lets them to the action even more. 

Positive feedback loops result in hard to balance economies. 

  • Early on in the investment cycle, these sources produce small quantities of a resource.  
  • Later on, positive feedback produces exponential growth of a resource. 
  • But this exponential growth oly happens if the feedback loop is being actively exploited by a smart player. 
  • So we end up with scarcity early on and then are hit with abundance and variability later. It can be a huge pain. 

An example of an investment resource might be fruit trees in Animal Crossing. When you start out, you feel great harvesting a single fruit tree. 

Simplification: Treat Positive Feedback Loops as Exponential Sources: For years, I’ve been relying on a straightforward simplification: I treat positive feedback loops as exponential sources. I design defensively and assume the worst case scenario where feedback loops are going to get out of control for some players. 

Investment Example A: Player earns a little resource early on. Which they invest to produce more of that resource. Later. This is approximated by an exponential curve.

This cartoon model of a positive feedback loop has several benefits

  • Instead of dealing with complex, tricky to communicate diagrams that chart out the exact structure of a feedback loop, we can just say a particular node is an investment source. This lets us continue to deal with the economy using targeted value chains. 
  • When we get to balancing sources and sinks, it unlocks clear numerical tactics for sopping up abundant resources. Instead of some mysterious dynamic system of emergence, the source becomes just another common type of math curve. 

Variation – Increasing the starting baseline: We can help eliminate scarcity during early stages of an investment source by adding a trickle source to fall back on. 

Animal Crossing’s fruit is not a pure investment source. Instead, they start you out with a set of ‘wild trees’ that let you harvest at least some baseline quantity of fruit each day even if you haven’t engaged with the investment loops.  

Investment Example B: Player earn 50 resources each tick from a trickle source. They then invest that to gain exponential growth in their access to that resource. 

Source Type: Random (Noise function) 

Some sources come with high variability. The most common of these in video games is a loot drop table, but almost any game that uses dice to determine resource rewards is using a random source. 

  • Random sources have a distribution of outputs: They can be a normal curve, exponential distribution, pure random noise or some other histogram. These will usually have some sort of central tendency where on average you can have a typical result. 
  • Random sources are really just a noise function applied on top of one of the other source types. So you can have capped, trickle, grind or investment sources with randomness. 

Simplification: Use the mean of normal distributions and convert to a less random source type: I tend to work with average outcomes when looking at how random sources contribute to the economy long term. This turns a random source into one of the other sources (capped, trickle, grind, investment). 

This simplification doesn’t work for very short term variability balancing, but can be highly effective for understanding scarcity and abundance in longer lasting games. 

Variation: Constrained randomness: You almost never want pure randomness in an economy. In your million of players, there will be that one person who rolls 1s for most of their game and attains 1% of the progress of the typical player. The system isn’t broken. Sometimes true randomness results in crap outcomes. 

If possible, use systems like ‘drawing-without-replacement’ (decks of cards with a discard pile work this way) or various pity systems that guarantee a drop after X draws. These ensure that the outlying experiences aren’t substantially different from the average experience. 

Again, we aren’t interested in techniques that allow you to balance any system. We are interested in building systems that are easy to balance. 

Sink Type: Fixed (Constant) 

Now we get into sinks. These extract resources from the game and thus limit accumulation and pooling.  You’ll see that these fit into categories very similar to sources (constant, linear, exponential)

The simplest sink is the fixed sink. When an action on a node in the value chain occurs, a fixed amount of resource is removed from the game. This is not repeatable. This is the mirror of a capped source. 

There are lots of examples of fixed sinks

  • A powerup you can purchase once. This takes a fixed amount of currency out of the economy. 
  • The one time cost in XP to earn the next level in an RPG. This takes a fixed amount of XP out of the economy. 
  • A boss you can beat a single time and in the process it uses up healing or mana potions. 

Most fixed-length games make heavy use of fixed sinks. You put them all in a spreadsheet and tally them up. This tells you how much you can give out from capped sources. 

Sink Type: Repeatable (Linear) 

The mirror of a trickle source is a repeatable sink. Every time the action for a node is performed, a fixed amount is removed. However, unlike a fixed sink, the action can be repeated multiple times. 

Some common examples of repeatable sinks

  • Damage being done to someone’s health bar. Each time the attack repeats, the same amount of health is lost. 
  • The crafting cost for a crafting recipe that can be crafted multiple times. 
  • A lamp in Valheim you need to regularly refuel or else it goes out. 
  • The cost to buy a consumable item in the store that replenishes each day. 
  • The cost to purchase a tree in animal crossing. 

Why not distinguish trickle sinks and grind sinks? You’ll notice that there’s no mirror sink to the grind source. You can absolutely have a trickle sink that only allows a certain amount of some resource to be destroyed in a given time period. Or a grind sink where players must grind to remove more of a resource. 

In practice however, these distinctions tend not to matter too much. Repeatable sinks are naturally limited by the supply of a resource. So we don’t get the specific runaway cases like ‘grinding’ that need special attention like we do with sources.

Sink Type: Exponential (Exponential) 

The mirror of the investment source is the exponential sink. In this sink, to get the next incremental (linear) increase in output, we logarithmically or geometrically increase the input quantity. This means there’s always room to sop up more. 

Some examples of exponential sinks

  • Each additional level for an RPG character costs exponentially more than the last level. 
  • In an idle game, each upgrade to an idle resource generator costs exponentially more than the previous upgrade. 

Sink Type: Competitive (Adaptive) 

There’s a specific type of sink that doesn’t have a clear mirror source. A competitive sink is a form of adaptive sink. In a competition between multiple players, whoever puts in the largest amount of a resource gets the largest prize. 

  • Pro: The nice thing about this sort of sink is there’s no top end so it can suck up lots of resources. 
  • Con: However, it can only be paired with competitive motivational anchors. And only a tiny percentage of the population is motivated by competition (mostly young males). So there are limited types of games you can use this. 

Examples of competitive sinks

  • Guild vs Guild competition in a game like Clash of Clans
  • Armies battling in an RTS game. 

There are lots of variations of this type of sink

  • Races: Players try to reach a specific goal. Whoever reaches it first, wins. There can be vast and expensive chains around training and other improvements to enhance your ability to get ahead of others. 
  • Leaderboards: There are more than two players competing and the positions are ranked relative to one another. So someone comes in 1st place, 2nd place, 3rd place, etc. Often the rank is measured within a league or session window. 

Mixing and matching sinks

All these types can also be mixed and matched. Idle games use leveling as a repeatable sink whose cost increments exponentially each time you level. Leveling can be fixed at a fixed number of levels.  So short term, a sink is exponential, but long term it is fixed. 

Like sources, it helps to classify a sink within a given time window. 

Step 3: Match power of sources and sink

You can essentially classify these sources and sinks according to their power

  • Constant: These are your capped sources and fixed sinks. This is the lowest power. (x^0) 
  • Linear: Trickle sources, Grind sources, Repeatable sinks. (x^1) 
  • Exponential: Investment sources, Exponential sinks. This is the highest power. (x^1+)
  • Adaptive: Competitive sinks (A>B). These are special cases. 

When balancing a value chain, it is immensely helpful to have lower power sources feed into equal or higher power sinks.

The challenge of overabundance

A slight amount of periodic scarcity or feelings of abundance can provide necessarily emotional variation to your experience. However, if you don’t balance your sink types, then as time goes on, a resource starts to accumulate in a pool somewhere and can’t be spent. This creates overabundance

When there is no chance of scarcity or  when there’s no use for those pooled resources, people stop caring. 

  • It may be trivial to satisfy or even exhaust their motivational anchors. If you are motivated by status and you can instantly buy all the high status clothing, why bother continuing to exercise that value chain? 
  • There is no longer a pull on the earlier nodes in your value chain that produce that resource. If you have all the sticks you’ll ever need, why bother ever harvesting another dirt pile?

For example

  • In CRPGs where you can sell things to vendors, you end up with millions of gold. But you have max level equipment. So what is the point?
  • In MMOs, players eventually have access to a 1000 useless +10 swords. This is known as mudflation and creeps up on games over the course of years. Why keep killing rats?

Of course not all value chains need to last forever. 

  • If you’ve created a fixed sink for a given value chain and thus have planned its eventual obsolescence, then it may be fine to let resources accumulate.
  • Or the player may enjoy messing about with a large amount of resources in a creative mode. They find this intrinsically rewarding and don’t need the careful scaffolding of motivations that a taut value chain provides. 

But intrinsic motivation is something that most people need to slowly work their way towards. They benefit from practicing an activity for long enough to know they enjoy it and eventually understanding how it serves their needs. This onboarding via explicit affordances and feedback seems particularly important when a player is operating within the artificial cartoon value structure of a video game. 

So reducing overabundance, at least in the early portion of a game and especially in games without creative anchors, is usually a good starting point for balancing your economy. 

The good news here is that big desirable sinks make it trivial to balance most faucet and drain economies. They create a need for resources which in turn causes the players to engage in actions all the way down the value chain. 

Balancing a fixed-length game

The easiest example is the fixed-length game. These are ones where you can map out the economy for the entire play experience, from start to some finite completion. These are good learning projects for new economy designers. 

  • List your sources in a spreadsheet for each node of the chain: If you have a fixed-length game composed of a series of capped sources, make a spreadsheet and add up those resources the players will encounter over the course of the game. You can also sum up trickle sources since you know when the game will end. 
  • List your sink for each node of the chain: Now make sure you have a set of fixed sinks that consume those resources. Include repeated sinks as well. Again, add them up!  
  • Golden path modeling: For trickle source and repeatable sinks you’ll need to decide how many times an ideal player interacts with each. This ‘golden path’ won’t be followed by every player, but it helps you approximate how much they’ll earn and spend. 

When picking which sources and sinks to pair, I use the general rules of thumb

  • Capped sources can be paired with fixed sinks. 
  • Trickle sources can be paired with repeatable sinks. 
  • For a fixed length game, investment sources always turn into capped or trickle sources. So you can use the previous two rules. You can be paired with exponential or competitive sinks. These are higher power and will sop up your sources. However they can be overkill, introducing mechanical complexity you may not need. 

Balancing an ongoing game

For an ongoing game, you again set up your per chain spreadsheet of sources and sinks. 

  • Since time keeps going, you don’t know how long a player will play. 
  • One trick is to think in terms of balancing within a period of time. How do flows add up within a week or a month or season of play? If you can find that repeatable ‘long session’, you can model that out and find how sources and sinks balance. 

When picking which sources and sinks to pair, I use the general rules of thumb

  • Capped sources can be paired with fixed sinks. These usually show up only during fixed-length sub-games within the live game. Examples include tutorials and limited-time events. You may want to avoid fixed sinks outside of these situations. Time is infinite and long-term players will overwhelm fixed sinks. 
  • Trickle sources should be paired with strong repeatable, exponential or competitive sink. 
  • A grind or investment source will always swamp a fixed or repeatable sink. Instead pair them with exponential or competitive sinks. 

You almost never want a true exponential source. Long term, these make your life painful. They are hard to model mentally and small mistakes result in extreme resources pooling. 

  • Try capping your investment sources. Any exponential power upgrades in an RPG are usually controlled with a hard level cap. Another common technique is to limit the number of investment slots you can use. Both these options turn an investment source into a more manageable trickle source. 
  • Idle games pairing an exponential source with a slightly higher power exponential sink. Even these structures don’t last forever since exponential investment waits start becoming boring. So they rely on hard resets via ascension mechanism to escape the trap of their exponential sources. 

Lean towards taut chains

When balancing sources and sinks, you typically want the sinks to be a little larger than the sources. 

  • Not too much or that results in dead points in the spend where players suffer from painful scarcity. 
  • Not too little because then you get pooling of resources and lack of pull on activity nodes within your value chain. The chain should always be pulled somewhat taut. 

If you’ve done your work matching source and sink power and you’ve isolated your value chains (see multi-chain architecture below), the exact balance numbers are less important than you might imagine. 

The emotions of scarcity and abundance

Once you get your general economy balance under control, there’s a huge amount of emotion you can extract from relatively minor variations in tautness. 

  • Scarcity: When players feel scarcity, they’ll be highly motivated to search out and harvest scarce resources. They’ll experience anxiety and a tendency to horde. 
  • Variability: When players feel high variation in availability, they experience similar emotions. 
  • Abundance: However if you give them abundance, they’ll momentarily feel a sense of freedom and can invest in non-scarcity driven behaviors. Note this is different from the extreme overabundance mentioned above when we discussed imbalance economies.
  • Hedonic adaptation: However, if they experience abundance for too long, your value chains grow slack. Players stop finding meaning in earlier nodes and just rely on their pooled resources. The joy of abundance returns to a baseline. 

The best games create an ebb and flow between scarcity and abundance within a narrowly controlled band of economic outcomes. A well balanced economy is a tool for driving rich player experiences. 

You can play with these much like playing notes or pacing on a music instrument. For example, in Cozy Grove, we made harvesting very reliable. Most sources were capped daily so they acted as slow trickle sources. And in general, we leaned towards abundance. Not always. Various events or quests would suck up resources from the player’s hoarded supplies so abundance wasn’t 100% reliable. This helped combat hedonic adaptation. The result is a very low stress, cozy economic game pacing. 

Note: Mimicking sink power by increasing sink magnitude

In a fixed length game, you can always approximate a higher power sink with a large magnitude low power sink. 

For example, I have a game that lasts 10 turns. It has a trickle source of gold that produces 5 gold per turn. 

  • Option A: I could pair the trickle source with a repeated gold sink that lets me buy 1 victory for every 10 gold. By the end of the game I’ll be able to purchase 5 victory points with no left over gold. 
  • Option B: However, I could also create a single fixed sink that lets me purchase 5 victory points for 50 gold. I’ve taken a simple fixed sink and just increased the magnitude enough that it sops up my gold income. 

On the surface, these look like the same end result. But they aren’t the same experience. 

  • Large sinks can feel grindy since players have to put in a lot of effort before they can spend. There’s a music-like pacing to how players interact with economies. Beware of large gaps where players lose track of the tune. 
  • If you end up changing the length of your game, you need to immediately go back in and rebalance all your sinks (or sources if you want to approach it from earlier in the chain.) In general, perfectly pairing sources and sinks of the same power that are balanced only by magnitude adds brittleness to your economic architecture. 
  • In a long-term ongoing game, you cannot mimic a higher power sink with a much higher magnitude sink. In the long run, a higher power source will always swamp a lower power, yet high magnitude sink. Just the way the math works (feel free to graph it!) 

In general, I try to avoid replacing sink power with sink magnitude. It is a bad habit to get into. 

Issue: Content treadmills

Long term, heavy use of capped sources and sinks lead to content treadmills. A content treadmill is when you need repeated injections of new content to keep your Game-as-a-service (GaaS) running. 

From an economic perspective, In order to extend the game, you need to add more sources and more matching sinks. Each of these requires a fixed amount of content. It can be better to invest in repeatable sinks. 

Issue: Marginal value erodes over time with repeated actions

Even trickle sources with strong sinks can wear out. Imagine you get one apple a day and you eat one apple a day. Trickle source, repeatable sink. What is the value of the apple to the player on the second day? 

In a simple model, the player has zero memory for the previous day. So they should look at the apple on the second day, realize they are hungry and be absolutely delighted to get a new apple. 

Burnout: In practice, each new apple provides a decreasing psychological benefit. Players slowly get bored with yet another apple. Repetition matters in experiential goods. More of the same, even though it provides the same functional benefit will provide less novelty or mastery benefit. 

Leverage: High leverage content are actions within your value chain that can be repeated many times without burnout. Most actions can only be repeated a small number of times before players get bored. The term ‘leverage’ comes from content that results in high ratio of gameplay relative to the cost of producing that content. 

For example, the classic leverage on exploiting a weak point in a Nintendo boss is ‘three’. The first time you learn their weakness. The second time you practice exploiting the weakness. And the last time you demonstrate your mastery. But that action starts to get boring if you are asked to repeat it the fourth time because it is usually just rote pattern execution. 

For more information on how to build high leverage content architectures see Designing Game Content Architectures

Solution – content recharging: The good news is that humans forget. An apple every single day might be low value. But if you let people forget about apples, and then give them an apple two months from now, that apple might again have high value. You can recharge content and regain some degree of leverage at the rate it takes for players to forget about that content. 


Most games have multiple value chains. If you were to lay out all the value chains on a single piece of paper, you’d find that certain nodes are present in multiple chains. This creates a crisscrossing spaghetti of resource flows that is the complete value network for your game.  

It is helpful to organize this ball of spaghetti in a fashion that is easy to understand and manipulate. Patterns for organizing your value network are your value architecture

There are an infinite number of value architectures out there. But we want to focus on sorting our chains in ways that best satisfy the following goals

  • Independence: Each individual chain is easy to independently balance so that it doesn’t accidentally unbalance other chains. 
  • Modularity: In GaaS, you want the option to easily retire old chains and add new ones as the game ages. 

The most common architecture: Parallel value chains 

The safest structure is to keep your value chains parallel to one another so they don’t overlap. Each set of action nodes is served by a set of unique resources and the player doesn’t need to make trade off between each chain. You can still feed multiple chains into the same motivational anchor as long as the anchor is multi-dimensional enough to be better satisfying by a little variety. 


This mostly satisfies our goals

  • This lets you balance each chain in isolation. 
  • It is easy to add a new value chain for an event and then remove it when the event is over. Or if there’s a piece content that players are burning out on, we can retire it without upsetting the balance of the rest of the game


  • Lots of bespoke resources. Each value chain needs its own resources that are not used in other value chains. As parallel chains multiply, so do resources and you’ll need a reasonable inventory system to track them all. This can add a lot of cognitive load for new players. 
  • Fewer emergent interactions between systems: Since economic systems are isolated, you get fewer ‘interesting’ feedback loops. This is an intended outcome of the architecture, but worth acknowledging what you give up by adopting it. 

Most long term GaaS evolve towards some flavor of architecture that contains multiple parallel value chains. It shows up again and again in various MMOs and F2P games. Players may not enjoy the explosion of currencies and resources that result, but they serve a real architectural need. 

Architecture for applying buffs

Chain B creates a buff that enhances the efficiency of the gathering action in Chain A

A very common architectural structure folks build with value chains is to create a buff or boost that increases the efficiency or effectiveness of some other node in a different action chain. 

In Jesse Schell’s terminology, these often take the form of ‘virtual skill’. A player purchases a +10 sword of smiting that boosts the amount of damage they can do to an enemy, thus allowing them to kill it faster. 

Efficiency anchor: New designers often think that this virtual skill primarily serves a skill mastery anchor, like getting better at fighting in real life. 

In practice, it serves as an efficiency motivation. (Or a power fantasy. The exact anchor depends in large part upon theming and audience) It has little to do with player learning and everything to do with a number being modified. The action in the economic node becomes cheaper to perform. 

There are lots of possible efficiency boosts you can trivially build into your value chains. Basically any form of cost (time, money, resources, complexity) can be reduced by a boost. 

Adding sinks to boosts: And you can add additional sinks into the Apply Boost node. For example, you might get a spell that increases damage output. But it requires mana to cast. Remember, every node is an opportunity to add another sink if you need one. 

This is a very flexible and useful pattern that once you understand it, you’ll start seeing it everywhere. 

Issue: Multiple undifferentiated inputs to node

Sometimes however, you have to cross value chains. There are helpful and unhelpful ways of doing this. 

Consider the following unhelpful scenario that is unfortunately baked into most RPG systems. Here we have multiple nodes producing an undifferentiated resource. 

In this example, we have two value chains that merge into one. 

  • Value chain A: You can spend time and health killing Monster A
  • Value chain B: Or you spend those same resources killing Monster B. 
  • In both cases, you get XP that you spend on leveling up. The value chain continues on after that, but we’ll just look at this snippet of the whole. 

We see two things happen in this design pattern when a long term player groks the full value chain topology

  • First they realize they can make a choice. They can invest their time in killing either monster A or monster B. 
  • Next they realize that if both monster A and monster B are plentiful, their time is always limited. So for efficient play, they should focus on killing the monster that gives the most XP for time spent. Let’s assume that’s Monster A. 
  • As the player gains expertise, they’ll start to completely ignore Monster B. Even though it has book value, the marginal value comparison means that it is in practice valueless to the player. 

This pattern has major implications on your economic design. In MMOs you may create 100s of enemies. Or hundreds of raids or quests. Yet, players will insist on playing only one or two. All that content you spend so much time and money developing is essentially wasted. 

This structure is very difficult to balance since players only care if the two sources are perfectly equal. And it never is. Even in cases of mathematical equality, there are cultural, habitual or aesthetic factors that cause players to prefer one path over another. This architectural decision ends up invalidating big swathes of content. 


  • Cap each source: If there are a limited number of times you can exercise Source A and also a cap on Source B and you need to to engage with both in order to satisfy the subsequent node. This is the most common answer for single player games. Here you have a fixed budget of content and can plan out exactly how much players should consume before they unlock the next elements. 
  • Multiple currencies: For more complex economies, it can be far more robust to use multiple differentiated input resources. The next section goes into more detail. 

Pattern: Multiple differentiated inputs to node

Now let’s consider an alternative topology

Same as before you spend time and health killing Monster A. But this time, you get a unique resource, horns. And monster B gives gems. And in order to level up, you need both Horns AND Gems. 

This setup has a very different set of player choices

  • The player must engage with both Monster A and Monster B to level up. If they only kill Monster A, they’ll lack Gems. If they only kill Monster B, they’ll lack Horns. 
  • The level up node creates a strong pull on the subsequent action nodes, giving these actions clear value.  

Players can choose the order that they engage with Monster A or Monster B, but they cannot ignore them. If there’s substantial content associated with those earlier nodes, you guarantee that it will be seen as valuable and that players are incentivized to exercise it. 

Pattern: Overflow from one chain to another

Suppose you want a player to pursue one value chain for a while and then switch over to a different value chain later in the game’s progression. 

In this example

  • Killing a monster gives gems
  • Players can spend gems to level up.
  • However leveling up is capped at level 10
  • Once players finish leveling, they can pour excess gems into crafting decorations. 

This overflow pattern is useful when you have fixed sinks. You set up cascading pools so that when one is filled, the excess can flow into others. 

This can be a useful pattern as well if your game is serving multiple player motivations. Which is almost always the case since any sufficiently large player population will contain multiple playstyles driven by multiple motivation. 

  • Say you have some players who love to decorate and others who like to progress. 
  • You want both to keep performing the core loop of killing monsters. 
  • So you use this structure to pull gems from the core activity, but then give them a choice on how they want to spend their hard won resources. Each path is anchored on a different motivation. 

Pattern: Lock-and-key choices

You train a fixed number of key resources. Player makes a choice on how to spend those resources. In this case, we are mimicking a worker placement pattern and producing consumable buffs of different types.

Earlier we covered how a single currency can lead to choices where players pick the most efficient path and ignore the rest. In a large, loosely controlled economy, this can cause major balance issues. However, there are more controlled variants where the player’s choice of how to spend esources are the most interesting part of the game. 

The common elements of this pattern include

  • Key resource: There’s a capped source producing a resource. This is the metaphorical ‘key’ in a ‘lock-and-key’ node-resource pair. 
  • Lock node: Gated nodes are unlocked with key resources. 
  • Choice: There are always more available lock nodes than key resources, so players need to make clear choices about which option to invest in.
  • Opportunity costs: By selecting a node to invest in, you lose the option of gaining resources from the other lock nodes. 

Common examples of this

  • Worker placement: The player gains access to a very limited number of workers. Those workers may be assigned to limited jobs to produce other resources or buffs. Or other workers! Sometimes there is a cost to place the worker. Or a cost to remove the worker. But critically, there are never enough workers to fill all the possible production stations so choices must be made. 
  • Skill trees: The player gains access to a very limited number of skill points. Those points are assigned to unlock skills in a predictable skill tree. This creates both a buff for the player and opens up the chance to unlock future skills further down the tree. 

Designers have a lot of control using this value chain pattern. They can change the benefits of each lock node and balance them against one another. They can control how many choices are valid by altering the amount of key resources. Content is invalidated when players make a choice, but the amount and impact of that is up to the designer.

New designers often mistake multiple undifferentiated inputs as the serving the same role as lock-and-key choices, but once you know the structure of the value chains, you can see they are quite different.  Lock-and-key choices always ensure a strong pull (and a taut chain) while multiple undifferentiated inputs result in dangling chains that are left unexercised.


“According to the dictionary, one definition of endogenous is “caused by factors inside the organism or system.” Just so. A game’s structure creates its own meanings. The meaning grows out of the structure; it is caused by the structure; it is endogenous to the structure.”

Greg Costykian, “I Have No Words & I Must Design

This quote has stayed with me for almost two decades. Value chains are a method of formalizing this fundamental truth into a useful design tool. They start to get at the heart of how meaning is constructed within a game. 

Value modeled as value networks

“Meaning” and “Value”are vague terms that we need to define more clearly in order to design . Value chains model “value” in terms of common elements of a game (actions, resources) arranged in a network topology. This allows us to get far more explicit about what value we are designing into our game. We gain visible levers and knobs we can manipulate. 

Value networks are internally self-supporting

Most elements in a game have value due to their relative relationships with other elements in the game. 

  • If you take away the other elements earlier or later in the value chain, the game loses meaning
  • Change the balance or nature of the relationship between elements, the game loses its meaning. 

Games as artificial spaces

Most game value networks are artificial. They are arbitrary and cut off from reality. This artificial space is often called the ‘magic circle’ within which gameplay exists. This artificiality provides such creative freedom! We are building cartoon worlds that don’t need to mimic the difficult-to-work-with structures found in natural economies. 

For example, when designing a giraffe refuge in the natural world. 

  • Does anyone even want a giraffe refuge? How are you going to pay for it? 
  • Then designers need to take into account years of law, history, logistical issues associated with limited physical space, connections to adjacent spaces, and whether or not your neighbor is allergic to giraffes. 
  • There are an immensity of constraints and unexpected feedback loops that are impossible to fully capture in any simplified model. 

None of those rules apply in a game about building a giraffe refuge. 

  • We can set up artificial rules where giraffes are plentiful, land is plentiful and everyone loves giraffes. 
  • We can create grokkable linear value chains and eliminate undesired feedback loops. 
  • We can intentionally design an artificial world where it is easier to build playful giraffe-centric activities within. 

Ultimately a game’s magic circle is anchored in reality

The “magic circle” is the conceptual boundary where a player opts into the value structure inside a game. Players opt into the magic circle of a game by saying “You know what? I know this virtual stick isn’t real. But I’m going to play along and act as if it has meaning.” 

But in the end, we should never forget that the reason why the player participates in the game’s value network is because they are seeking real-world value. This is why every value chain ends with a motivational anchor. Personal needs fulfillment always pierces the boundary of the magical circle. 

  • Unmet player needs: Play is a seeking behavior. You have unmet needs, but you don’t know how to fill them. So you experiment in a safe fashion to understand your options. This last step is the definition of play. 
  • Game makes player promise: A new game makes a promise to the player, usually rooted in the meeting of some need. Diablo promises power and mastery. Animal Crossing promises a relaxing respite. World of Warcraft promises mastery and friendship. This is the hook that gets you sucked into a game. 
  • Onboarding: And there’s a grace period. Because the point of play is to wander about for a bit and figure out how to meet your needs. Even players know that need fulfillment can’t happen immediately. Mastery can take many hours. Social bonding can take weeks. Players need to build up the tools. They need to understand the path forward. So players willingly run through tutorials. They willingly follow the chain of quests. Onboarding runs on goodwill that their needs will be eventually met. This step is introducing players to the early stages of the value chain. 
  • Understanding the path towards: That goodwill runs out. As soon as the promise is made, a timer is ticking and the player is thinking in the back of their mind “How is this game going to fulfill its promise?”  The job of the game is to paint that path. And demonstrate real progression towards it. If the game doesn’t help the player understand how all this (expensive) playful activity will ultimately fulfill a key motivational drive, they will stop playing. The game must connect the dots. This is making the value chain visible to the player. 
  • Demonstrating need fulfillment: In as short a timeframe as possible, the game should provide player experiences that fulfill the needs as they were promised. This is the end anchor of the value chain. 

So all of our elaborate value scaffolding does need to serve the player’s needs in the end. Every cartoon, hyper-designed endogenous game system contains a connection to the real world. Because games are played by real humans with real human needs. 


Value chains should give you a strong framework for planning and balancing your game economy. You’ll be able pinpoint issues and communicate targeted balance fixes using a common language. The technique targets faucet-and-drain economy designs, but since this remains the dominant method used across most popular genres, you should be well equipped. 

Next steps

Game economy design is a much richer topic of technique and practice than I could possibly cover in this paper. Many modern designers find they devote years of their career to learning the nuances specific to their genre and their community’s needs. If you are interested further in this topic, I highly recommend the following: 

  • Breakdowns: Take one of your favorite games. Identify the individual value chains. Be sure to include the anchors! Make notes on the architectural elements such as branching or choice built into the chains. Ask yourself what you could have done differently to serve your unmet needs better. Also do this exercise with one of your least favorite games. 
  • Game jams: Very few large teams will give an unproven designer the responsibility to design an economy from scratch. However, many of the fundamentals can be practiced on smaller game jam-sized projects. Limit the number of length of your value chains. But try them out! Try out strange new architectures. Playtest! Balance these tiny games. The lessons you learn scale to larger projects. 

Open questions

There are also many further areas of investigation for those interested in extending value chains as a design tool. 

  • Trade: How do value chains map to more open economies with features like player-to-player trade? 
  • Visualization: Is there value in reconstituting value chains into a more traditional spaghetti diagram? Such visualization tools don’t yet exist. But you should be able to composite value chains together automatically and perhaps even summarize them. 
  • Ethics: Can we use economy design for good? The use of value anchors deliberately centers human needs as the primary driver of value. Yet the world is rife with reductive, selfish ideologies that flatten the richness of humanity to mere numbers (homo economicus, libertarianism, much of current crypto.) Economy design is an amoral tool. It requires ethics, compassion and a keen eye for spotting externalities in order to avoid causing immense systemic harm.


The Chemistry of Game Design

comments 5

(Note: This essay was originally published on in 2007. To help prevent link rot, I’m reposting it here with minor edits and fixed links. I’ve also included a workshop presentation on the topic if folks want to teach these ideas in their classes.)

1. Moving Beyond Alchemy

“…it was clear to the alchemists that “something” was generally being conserved in chemical processes, even in the most dramatic changes of physical state and appearance; that is, that substances contained some “principles” that could be hidden under many outer forms, and revealed by proper manipulation.”

I recently happened across a description of alchemy, that delightful pseudo-science of the last millennium that evolved into modern chemistry. For a moment I thought the authors were describing the current state of the art in game design.

Every time I sit down with a finely crafted title such as Tetris or Super Mario Brothers, I catch hints of a concise and clearly defined structure behind the gameplay. It is my belief that a highly mechanical and predictable heart, built on the foundation of basic human psychology, beats at the core of every single successful game.

What would happen if we codified those systems and turned them into a practical technique for designing games?

In a Time Before Science

“Throughout the history of the discipline, alchemists struggled to understand the nature of these principles, and find some order and sense in the results of their chemical experiments—which were often undermined by impure or poorly characterized reagents, the lack of quantitative measurements, and confusing and inconsistent nomenclature.”

Historically, the process of understanding games has been limited by numerous factors ranging from messy experimental practices, spiritual reliance on untested theories of play, and confused terminology. We are still alchemists of our trade, mixing two-parts impure story with one-part polluted game play with three-parts market voodoo.

As an industry, we need to go beyond the mystical hand waving that defines modern game design. It is now possible to craft, test and refine practical models of game design built from observable patterns of play. We can describe what the player does and how the game reacts. Recently, we’ve begun to crack open why players react to certain stimuli and are able to create models that predict pleasure and frustration.

This essay will describe one such model.

Fundamental Science Forms The Future

Diagram 2: Condensation polymerization of Nylon, (a substance not available to alchemists)

The bigger hope is to move our alchemical craft towards the founding of a science of game design. We currently build games through habit, guesswork and slavish devotion to pre-existing form. Building a testable model of game mechanics opens up new opportunities for game balancing, original game design and the broader application of game design to other fields.

The advent of basic chemistry gave us tools to build a new world of technologies far beyond that imagined by our alchemist forefathers. Plastics, engines, fabrics, power sources revolutionized our lives. It is a worthy effort to crack the fundamental scientific principles behind the creation of games.

2. The Foundations Of A Model Of Game Design

Where chemistry separated itself from alchemy by building testable models of physical atoms, a science of game design concerns itself with testable models of human psychology.

Many of the attempts to define games have focused on the mechanistic elements of the game, such as the primitive actions that the system allows the player to perform or the tokens that the player manipulates. The approach has been to treat games as self contained logical systems.

Mechanics and aesthetics are certainly important pieces of any model of game design, but in the end, such analysis provides little insight into what makes a game enjoyable. You end up with a set of fragmented pieces that tell you almost nothing about the meaningful interactions between the game as a simulation and the player as an active and evolving participant. Games are not mathematical systems.They are systems that always have a human being, full of desires, excitement and immense cleverness, sitting smack dab in the center. To accurately describe games, we need a working psychological model of the player.

Player Model

Our player model is simple: The player is an entity that is driven, consciously or subconsciously, to learn new skills high in perceived value. They gain pleasure from successfully acquiring skills.

Diagram 3: The player follows clues to the acquisition of a new skill

Let’s dig into three key concepts in our player model.

  • Skills
  • Driven to learn
  • Perceived value


A skill is a behavior that the player uses to manipulate the world. Some skills are conceptual, such as navigating a map while others are quite physical, such as pounding in a nail with a hammer. This ties into an intrinsic motivation towards self-determination. “I want to do what I want to do. And skills help me get there.” 

Driven To Learn

Play is instinctual. In low stimulation environments where we are not actively pursuing activities related to food and shelter, people will begin playing by default. Strong feedback mechanisms in the form boredom or frustration prod us into action. Given a spare moment, we throw ourselves into playing with blocks or dolls as children and more intricate hobbies as adults. It is a sign of our need for meaningful stimulation that solitary confinement remains a vicious punishment for the most hardened criminals.

The flip side is that we are rewarded for learning. The sensation that gamers term ‘fun’ is derived from the act of mastering knowledge, skills and tools. When you learn something new, when you understand it so fully you can use that knowledge to manipulate your environment for the better, you experience joy.

There is a reasonable amount of neuroscience available to support this claim. Edward A Vessel, a cognitive neuroscientist at the NYU Center for Neural Science writes:

“These “aha” moments, when a concept or message is fully interpreted and understood, lead to a flood of chemicals in the brain and body that we experience as pleasurable. It feels good to “get” it. The deeper the concept is, the better it feels when we are finally able to wrap our head around it.”

Upon the click of comprehension, a natural opiate called endomorphin, a messaging chemical in the brain similar in structure to morphine, is released. As humans, we are wired to crave new information constantly. In some sense, what you and I term curiosity can be interpreted as our brain looking for its next fix of deliciously fascinating information.

As game designers, we deal with the fun, boredom and frustration on a regular basis. It is good to recognize that these are biological phenomena, not some mystical or mysterious sensation. For more thoughts on the topic, I encourage you to have a quick read through Raph Koster’s book “A Theory of Fun for Game Design

Perceived Value

Players pursue skills with high perceived value over skills with low perceived value

Play is, perhaps counter intuitively, a deeply pragmatic activity. Our impulses to engage in play are instinctual, selected for by evolution because it provides us with the safe opportunity to learn behaviors that improve our lot in life without the threat of life threatening failure. We play because we are built to expect the eventual harvesting of utility from our apparently useless actions. We stop playing when we fail to find that utility.

The perception of value is more important than an objective measurement value. Humans are not creatures of pure logic. We know people exhibit consistent biases in how they weigh their actions. For example, they’ll often undertake bizarre risks because they are unable to properly evaluate statistical odds. We’ve also realized that people have substantial limits on how much information they can take into account when making any one decision. Many decisions are made based on highly predictable ‘gut’ reactions that have their own subconscious rules.

3: Interaction Loops

With our player model in hand, we can describe how the player interacts with the game.

The basic ingredients of a game are, if not standardized, at least well described in a variety of books and rambling by designers across the past decade or two. I’ve taken the basic ingredients of tokens, verbs, rules, aesthetics, etc and remixed them into a self contained atomic feedback loop called an interaction loop. Each unit describes how the player gains a new skill.

Diagram 4: The player follows clues to the acquisition of a new skill

An interaction loop feedback loop is composed of five main elements:

  • Decision: The player observes any known affordances and weighs possible outcomes. 
  • Action:The player performs an action. For an interaction loop encounter by a new player, the action might involve pressing a button. More advanced atoms might instead require the player execute a batched set of actions such as navigating a complex maze.
  • Simulation: Based off the action, an ongoing simulation is updated. A door might open.
  • Feedback:The game provides some form of feedback to the player to let them know how the simulation has changed state. This feedback can be auditory, visual, or tactile. It can be visceral in the form of an exploding corpse or it can be symbolic in the form of a block of text.
  • Modeling: As the final step, the player absorbs the feedback and updates their mental models on the success of their action. If they feel that they have made progress, they feel pleasure. If they master a new skill or other tool, they experience an even greater burst of joy. If they feel that their action has been in vain, they feel boredom or frustration.

A shorthand diagram that I find useful for recording atoms is as follows:

Diagram 5: Our canonical interaction loop

For example, let’s dissect the act of jumping in Mario

Diagram 6: The interaction loop of the player learning how to make Mario jump

  • Decision: A player notices a button on the controller. They know from past experience, it is pressable. 
  • Action: An inexperienced player pushes a button.
  • Simulation: The simulation notes the action and starts the avatar of Mario on the screen moving in an arc.
  • Feedback: The screen shows the user an animation of Mario jumping.
  • Modeling: The user forms a causal mental model that pressing the button results in jumping.

Implicit in this model is that the atom is often looped through multiple times before the user understands what it teaches. The first pass may only clue the user that something vaguely interesting happened. The user then presses the button again to test their theory and Mario once again bounces up into the air. At this point, the player smiles since they realize they’ve acquired an interesting skill that may be of use later on.

This Thing We Call Play

“Man is a Tool-using Animal … Nowhere do you find him without Tools; without Tools he is nothing, with Tools he is all.” – 19th century essayist Thomas Carlyle

Upon the acquisition of a shiny new skill from a skill atom, players experiment with it. They try it out in different environments and see if it does anything useful. This semi-random exploration is the classic ‘play’ activity that we see children perform. For example, when a new player masters how to jump, you’ll notice they’ll almost immediately start happily hopping about the level. On the surface, it is a silly frivolous activity. In reality, we are observing humanity’s instinctual process of learning in action.

In the course of experimenting, the player will occasionally stumble across something in the environment that gives them interesting information that might lead to the mastery of a new skill. At this point, you’ll see the behavior of the player become more deliberate. A mental model begins coalescing in their minds. In our jumping example, the player starts bumping against a platform. They may even reach the top of a platform. It is very common that skills acquisition requires multiple passes through the new skill atom before mastery is achieved.

Eventually, the player uses an existing skill to grok another skill. They experience a wash of pleasure and start the process all over again.

Chaining Of Game Mechanics

We can visually represent how players learn by linking our basic interaction loops together to create a directed graph of atoms called a skill chain.

Diagram 7: Two linked atoms

The skill from one atom feeds into the actions of another atom further down the chain. By linking more and more atoms in, you build a network that describes the entire game. Every expected skill, every successful action, every predicted outcome of a simulation, every bit of required feedback can be included in a simple, yet functional fashion.

Diagram 8: Sample skill chain for Tetris

A skill chain is a general notation that can be used to model pretty much any game imaginable. Your design can be broken down into dozens of simple atoms that link together to form a clear and easily readable map of how the game plays. The skill chain, with its ability to describe the player experience instead of the mere mechanics of the game, provides a far richer description of the meaningful moments that occur during gameplay.

How Players Interact With A Skill Chain

Players will travel from atom to atom like Pac-Man following a trail of dots towards the power pellet. They move from one skill to the next even when they have only a vague concept of the ultimate destination.Chomping up those dots is good.

One of our peculiarly human limitations comes into play at this point. Players are unable to predict the value of a new skill more than a couple atoms down the chain. As long as there is a new skill with potential value within our prediction horizon, players will pursue it. There may be no actual long term payoff other than the pleasure of the experience, but we don’t care. As long as there is a promise of a long term payoff and the short term rewards keep coming, we assume that there will be some final benefit from our efforts.

Diagram 9: Players have limited foresight

If you look at this from an evolutionary perspective, our behavior makes quite a bit of sense. Many useful skills take upwards of five to 10 years to master. During those early days of our education, the basic playful activities such as gossiping about which kids have cooties seem rather silly. Later on however, our mastery of politics, science, or in the case of the cooties, mating rituals, yields a hugely positive impact on our well being.

The just-so story here is that playful folks that instinctually engaged in long term learning with no immediate benefit were the ones that mastered agriculture, hunting and language. These folks thrived. Those that did not died off.

However, our brains never evolved to deal with modern games. The existence of a set of interaction loops that are tuned just to entertain us and that never actually lead up to a real world skill is something new to the world. At their most puerile, games are a grand hack. The minute by minute experience fits all our biological heuristics and sounds all the right bells. So we keep on playing. And we wonder why so many games have such horrible endings.

4. Status Of Atoms In The Skill Chain

A skill chain provides some rather useful information about the state of the player as they engage the game. Imagine that the skill chain is the instrumented dashboard that lights up with the player’s progress. At any point in time you can tell the following information

  • Mastered skills: Skills that have been recently mastered.
  • Partially mastered skills: Skills that the player is toying with, but has not yet mastered.
  • Unexercised skills: Skills the player has yet to attempt.
  • Active skills: Skills that the player is actively using. (aka the Grind)
  • Burned out skills: interaction loops that the player has lost interest in exercising.

Diagram 10: Icons for skill status

We’ve talked a little bit about mastered and partially mastered skills. Unexercised skills are pretty self explanatory. If a player can’t perform the actions necessary to understand a skill, that atom will never be exercised or mastered. Mastery flows down the chain and if players are blocked early on, they’ll never reach the further atoms.

The two states that are worth a bit more explanation are active skills and burned out skills.

Active Skills

The player only experiences the joy of mastery for an atom only once. After the moment of mastery, a biological feedback system kicks in that dampens the pleasure response to exercising those same pathways again. What was once exciting becomes boring.

However, players will continue exercising an already mastered atom as a new tool for manipulating their world. A mastered atom is as good as a shiny new hammer hanging from a workman’s belt. When a new opportunity comes up, typically in the form of an atom further down the skill chain, the player makes use of their new skill to advance their knowledge.

Players have enormous patience. They are willing to exercise a basic interaction loop thousands of times in order to achieve mastery of a higher order atom. Players jump innumerable times in Super Mario Brothers in order to reach more powerful skill sets further down the chain.

A skill that has been mastered and is now simply being used to activate other icons is represented by the lit light icon.

Diagram 11: Active Icon


Players don’t always bridge the gap between one atom and the next. They master a new skill, they play with it but fail to find any interesting use for it. This is known as burnout.

Diagram 12: Burned out icon

For example, suppose our player pressed the jump button. They performed the jump and we recorded their mastery of the skill. However, this particular player never figured out how the jump might be useful. Perhaps they didn’t jump near the platform and receive interesting feedback on the next atom.After a short period of experimentation with no interesting results, the player stopped pressing the jump button entirely.

When a player burns out on a particular atom, the consequences ripples up and down the chain.

Early Stage Burnout

In the example above, the Reach Platform atom will never be mastered. The foundational skills are not in place. In a deeply linked skill chain, a burnout early on can chop off huge sections of the player’s potential experience. You can think of learning curves in terms of managing early stage burnout.

Later Stage Burnout

On the other hand, a burnout later on down the chain can devalue active skills.

For example, assume we have a single platform in our jumping game and there is really nothing on it. The player jumps on the platform, discovers no interesting new activities and so stops jumping on platforms. This, in turn, atrophies the Jump skill, because if the player doesn’t need to jump on platforms, why would he bother jumping?

Burnout Is Our Gateway To Testability

Burnout is a very clear signal that our game design is failing to keep the players attention. As you watch burnout creep across a game’s skill chain, it is a signal that players will soon stop playing the game.They are becoming bored, frustrated and perhaps even angry.

Perhaps most importantly, we can measure when burnout occurs for an individual atom. This gives us, as game designers, unprecedented qualitative insight into how a particular design is performing with play testers. When you start tracking burnout along with the other skill states, you can visualize the problematic areas with great clarity and accuracy. The entire topic of measuring performance of a game through instrumentation of its skill chain is a rich topic for further exploration.

Diagram 13: Skill atrophy due to later stage burnout

5. Advanced Elements Of A Skill Chain

We’ve covered the basic elements of a skill chain and how to record that status of the player’s progress.There are only a few more pieces we need so that you can start building your own skill chains.

  • Pre-existing skills: How the skill chain is jump started.
  • Evocative Stimuli: How we represent story and other aesthetic aspects of modern game design.

Pre-existing Skills

Players bring an initial set of skills to a game. These skills always form the starting nodes of a skill chain. Accurately predicting the player’s existing skill set has a big impact on the player’s enjoyment of the rest of the game.

Diagram 14: How pre-existing skill feed into initial interaction loops

Lack Of The Correct Initial Skills

If the player lacks expected skills, they will be unable to engage the initial atoms in the game. In our example about jumping, imagine a player that didn’t realize that you need to push the button on the joystick in order to do something. Such an example may seem ludicrous, but it is one faced by many non-gamers whenever they are faced with a freakishly complex modern controller. Many game designs automatically assume the ability to navigate a 3D space using two fiddly little analog stick and a plethora of obscure buttons. Users without this skill give up in frustration without ever seeing the vast majority of the content.

It is very important to realize that such users aren’t stupid. They merely have a different initial skill set. One of our jobs as designers is to ensure that the people who play our game are able to master the game’s early interaction loops. Ultimately this means making an accurate list of pre-existing skills for the target demographic and building our early experience around those skills. Don’t assume skills that may not be there.

Pre-mastery Of Skills Taught In The Game

The flip side of all this is that if players have already mastered existing skills, the process of mastering early atoms is likely to be quite boring. When a player, who has completed a dozen hardcore titles, plays a game sporting a 10-minutes navigational tutorial they become bored. All the reward notes are sour because their jaded brain doesn’t react at the appropriate points. If a game doesn’t teach the player anything new, the player is very likely to experience burnout on the early atoms.

Targeting the correct set pre-existing skills is a balancing act. If you choose correctly, you’ll end up with an ‘intuitive’ game that players enjoy. If you choose incorrectly, you risk frustration, boredom and inevitable burnout.

Evocative Stimuli using Arcs

Games are laden with story, setting, and imagery intended to evoke a particular mood and other intriguing but mostly non-functional elements. Gamers derive great pleasure from this feedback. We can represent much of this mélange of artistry with the use of a special type of atom known as an arc.

Arcs are atoms that the designer knows will never result in a useful in-game skill, but that still evokes the past experiences or mental schema. When the player experiences the information cues, existing player memories are activated and the brain greedily sucks up the clues. For example, many players have pre-existing associations with mushrooms. If you are of a certain age and a certain liberal background, you may even own a rainbow colored T-shirt that sports a mushroom or two. When such a person plays Super Mario Brothers for the first time, they are quite likely to perk up at the sight of magic mushrooms. An interaction loop in their brain is activated, they start activating ideas about mushrooms, and begin free associating why might dear Miyamoto have placed such a counter culture reference in the game.

Of course, the reality is that for the psychedelically minded, the mushroom imagery is flavor only. 

Now these evocative arcs can be useful! If the player had read Alice in Wonderland, they might associate mushrooms with changing in size. In this case, the fact the mushroom makes you bigger already has a pre-existing mental pathway and when the player experiences it again, they are essentially reinforcing that path. So evocative arcs can influence what mental schema (existing skills) players tap into when forming models of cause and effect. 

The downside of evocative stimuli is that most players rapidly burnout on such sleights of hand. The first time you see the mushroom, you might think it’s ‘mushroom-y-ness’ interesting. The second time, you see it as its utilitarian nature: An icon representing access to a tool (growing larger) that helps you navigate the world more efficiently. 

6. Conclusion

We’ve covered a lot of ground in this essay. Hopefully, the diagrams give you a good understanding of how to describe a game using skill chains.

Using Skill Chains

As a tool, I’ve found that skill chain diagrams dramatically improve my understanding of how a game works, where it fails and where there are clear opportunities for improvement.

Creating a skill chain provides you with the following information:

  • Clearly identify the pre-existing skills that the player needs to begin the game
  • Clearly identify the skills that the player needs to complete the game
  • Identify which skills need feedback mechanisms.
  • Identify where the player experiences pleasure in your game
  • Alert the team when and where players are experiencing burnout during play
  • Provide a conceptual framework for analyzing why players are experiencing burnout.

Though it takes a little practice, interaction loops aren’t all that complicated to define and are really no more of a burden than writing unit tests for a chunk of code.

Future Topics

Skill chains are a deep topic and we’ve described only the most basics aspects of how they function.Further topics of inquire include:

  • Breaking apart a game into interaction loops
  • Using interaction loops to identify root causes

If you are interested in more on interaction loops and skill chains, here’s a workshop I’ve given on the topic with exercises:

From Alchemy To Chemistry

I like to imagine that models like skill chains will help raise the level of intent and predictability in modern game design. With the concepts in this essay, you can start integrating this model into your current games and collecting your own data. We’ve got some immensely bright people in our little market and it is almost certain that they can improve upon this foundational starting point. By sharing what you’ve learned, we can begin to improve our models of design. What happens if game designers embrace the scientific process and start to build a science of game design?

The alchemists of ages past dreamt of turning lead into gold. They performed mad experiments with imprecise equipment and questionable theories of how the universe worked. Modern game designers are not really so different. Those not simply here for the sake of profit instead rally around equally fantastical dreams such as creating a game that makes the user cry or enlightening the world with games of politics or hunger. We crib cryptic notes from past successes and chortle merrily when our haphazard experiments manage to mildly entertain our audience. We are on the leading cusp of deep human / software interaction and yet we know so little.

It is only by gaining a deeper understanding of the fundamental building blocks of design that game designers will gain the power to break free from the accidental successes of the past. With practical techniques gained from controlled experiments, we will create radically effective new applications. When we have our basic chemistry, our basic systems of measurement and our basic atomic theory, perhaps then we can consistently build games that tap into the heart of human psychology.

The reproducible application of psychological manipulation of individuals and groups using software is big heady stuff. In the short term, I would hope that a deep understanding of models like skill chains help us crack open the rigid craftsmanship of existing genres so that we can build better, more potent games. Long term, it will be interesting to see what world changing uses we can find for our ever improving psychological technology.

References And Notes

Workshop on using interaction loops and skill chains

The original essay on interaction loops

Effects of solitary confinement on prisoners

Perceptual pleasure and the Brain

Irving Biederman and Edward Vessel, American Scientist, May-June 2006

Abstract: “From hand-held DVD players to hundred-inch plasma screens, much of today’s technology is driven by the human appetite for pleasure through visual and auditory stimulation. What creates this appetite? Neuropsychologists have found that visual input activates receptors in the parts of the brain associated with pleasure and reward, and that the brain associates new images with old while also responding strongly to new ones. Using functional MRI imaging and other findings, they are exploring how human beings are “infovores” whose brains love to learn. Children may enjoy Sesame Street’s fast pace because they get a “click of comprehension” from each brief scene.” 

Press release:

Six sinister things about Super Mario

An example of game chemistry in action

Here is a rough draft of a skill chain for Tetris. It is interesting to note that a game that is mechanically quite simple can possess an expansive skill chain.

Relationship of Skill Chains to MDA (Mechanics, Dynamics, Aesthetics)

This is a question that has been posed on occasion. MDA is a game analysis framework put forth by Robin Hunicke, Marc LeBlanc and Robert Zubek. It is one of many descriptive techniques that categorize  the elements of a game. MDA is particularly useful to new design students because it has the key insight that the player experience (what they call Aesthetics) is a second order effect derived from playing the rules of the game. 

The major difference between the two approaches is that MDA stops there. There is little attempt to model how rules and feedback produce the actual player experience with the game. There’s just these fluffy, conceptual categorical buckets. Since there’s no casualty, MDA analysis also fails to provide any objectively testable structure. With skill chains, you can always hook up logging software and observe where atoms light up and where they burn out.

You can read more on MDA here.

A quick overview of alchemy, from a reliably alchemical web 2.0 source

Oddly enough there are research papers referencing skill chains

Designing game content architectures

comment 1

As game budgets expand once more, the success of a title often depends on producing large amounts of high quality content. This is not a trivial task. Mistakes setting up your content plans can easily result in panic, shipping delays, scope cuts, rework and crunch. Modern developers live on the content treadmill so we might as well embrace it. 

For a long time I’ve been interested in content architectures, the tooling and data structures behind what content we make. This somewhat obscure topic drives much of the production efficiencies available to a team. A poor content architecture can easily result in an equivalent player experience costing 10 times as much time and labor. That’s the difference in output between a 30 person team and a 300 person team; a lot of money and human life to naively misspend.

Who this is for

  • Producers: Anyone above level of associate producer should know this topic down cold. To paraphrase the words of designer Crystin Cox, “I want to be able to ask a producer whether I should use a placeholder or a vertical slice when building an experience.” To a large degree this is your job since these early decisions drive much the team’s ability to deliver on a schedule and adapt to unexpected changes. 
  • Designers: If you decide what the team makes, you owe it to them to also understand the best possible methods of building the desired outcome. Design leaders maximize the impact of the experience they deliver while working within a fixed budget. 
  • Engineers: You’ll be building many of these tools and pipelines. Wouldn’t it be nice if they were useful? Wouldn’t it be nice if other disciplines could communicate their needs? Knowing how to think about serving content authors improves the game, your work and results in happier cross team relationships. 

What we’ll cover

Content architectures are a broad topic best approached holistically. Existing content architecture experts are usually veteran developers who have multiple games and dozens of failures under their belt. Unfortunately that means this essay needs to spend time intro-ing the basics before we get to the more advanced considerations. Apologies for the slow build! 

  1. Terminology: Basic definitions of what we are manipulating in a content archichitecture.
  2. Concepts: Key concepts that help us think about our content.
  3. Constraints: What are the specific content choices for a given project that shape our architecture?
  4. Basic architectural patterns: How might we organize our content?
  5. Advanced patterns – Manual composition: How do we manage rigidities in the content pipeline?
  6. Advanced patterns – Automated composition: How do we reduce rigidities with automation?
  7. Meta – Tool authoring: How do we build tools that multiply our authoring efforts?


Let’s start off with some basic definitions that work for most forms of content you’ll run into. I’m abstracting the discussion away from specific content (levels, character, textures) so we have the building blocks to think conceptually about any content in our game. We want to get to “content algebra”, instead of always asking “how many apples does Bob have?” 

Content: Content is an authored set of data intended to be displayed in some broader game system and consumed by the player to create a meaningful experience. More traditional forms of content include things like a chapter of a book, or a painting in a museum. 

We often think of game content as generic media like 3D models or text. And that’s definitely where we spend a lot of effort. However each game also contains data files like a loot table, level progression or powerup. These need to be designed with care. 

Chunks: Traditionally content comes in the form of  content chunks. This is a piece of the player experience that is standardized and reproducible. Examples of chunks include

  • Level: A game like Super Mario Bros has discrete levels. Each module is self contained and consists of a set of platforms, enemies and win conditions. A game is then composed of multiple levels. 
  • Player character skin: A bundle composed of 3D model, UVs, textures, shaders, animation rigs and state machines. The player has a choice between multiple skins. 
  • Weapon: A set of properties for weapon damage, rate, cooldown. As well as associated art, economics costs, etc. 
  • Player buff: A set of modifications that occur to an external set of properties. Along with constraints on when and how the buff is triggered. 

The contents of each chunk differ. Weapon A has different data than Weapon B. But the data structure and how that data feeds into other systems is shared. 

Standards: Standards are rules and constraints that define a content chunk. They help reduce risk by removing unexpected variability and associated thrash. They help improve quality by focusing an author on excelling at a particular well-defined space. They help improve efficiency by eliminating common blockers and streamlining workflow. They help teams scale, by allowing multiple authors to work coherently on the same project. 

Sets: These chunks are organized into sets. You might have 20 levels in a game. That’s your game’s set of levels. Or 500 barks. That’s your game’s set of barks.

Composition: Chunks can be assembled together into new composite chunks. A level chunk is a composite of enemies, level tilesets, powerups and other modular elements. The level designer likely did not create any of these sub-components, but they put them together to form a unique player experience. 

Composition is a creative act of authoring. Someone needs to make deliberate choices on what is included and its relations with the other elements. Even a writer composes words they did not create on the page. A painter composes color they did not create on a canvas. 

Dependencies: When you split content up into chunks and string them together in a content architecture, we create dependencies. In order for content to work or have meaning, it requires that other content or systems are functioning exactly as expected. The act of creating chunks always creates dependencies since there’s a fuzzy line for where content wants to reside. Standards help catalog and isolate dependencies. Later on, we’ll see many of the tools for managing content architectures are about structuring dependencies in a useful manner. 

Questions worth asking about your game: But we often don’t take the time to think of ‘words’ or ‘color’ as standardized chunks. They are just the invisible air we breathe. Eliminating our blindness to the ‘intentionality of the default’ is the first step one must take. As a content architect you need to expand your perspective and see these elements as explicit design choices.

  • What are your chunks?
  • What are their standards?
  • What are their sets?
  • How are they composed?
  • What are their dependencies?


In order to design a content system, it helps to have a mental model of how content ‘works’. Here are some of the big picture rules of content authoring.

Content delivers value: We author and deliver works of art to players in order to provide them with meaningful experiences. We can build content that harms or wastes a player’s life. Or we can build content that enriches their life. 

Content is consumed: Content can be experienced a certain number of times before players feel like they understand the experience and are ready for something different. Some content becomes a touchstone for an ongoing socio-economic player ritual, but most is used and then put aside. The player exhausts their motivation to return to the content. 

Consumption is iterative. Players experience a chunk of content 1 to N times before they move on. Chunks that are experienced once and then discards are seen as Highly Consumable. Ones that can be experienced many times without being discarded are seen as Evergreen

Authoring is iterative. How does an author deal with the uncertainty inherent in a diverse audience’s consumption of the content?  You iterate. You deploy the content and observe the reaction of those consuming it. Then you revise the content and test once again. 

At the most basic level, authors do this with themselves in a process called ‘self playtesting’. They switch between a creation state and a consumption state. With writing and painting this happens moment-by-moment in a tight iterative loop. For example when writing, the following happens thousands over times:

  • I write a word
  • Then immediately read what I wrote and react. 
  • Then I revise. 

Games have longer feedback loops than many forms of media. As we author, we can imagine in our minds how it might play out, but our existing skills and understanding of the game systems pollute our empathy. Some systems like multiplayer, economic or long term progressions yield surprising results or large play surfaces. Self-playtesting ends up being unreliable. So we need to rely on much less frequent cycles of playtesting with others. 

Authored content exhibits varying degrees of leverage: Leverage is a measure of efficiency, how much value the content delivers relative to its cost. 

  • Leverage = Meaningful contribution to the player experience / Sum of total authoring and tooling costs
  • High leverage: An evergreen piece of content (such as a National Anthem that that took hours to write and is used millions of times over hundreds of years) is high leverage. 
  • Low leverage: A comic in a book that took days to draw, but is viewed only once and then forgotten is considered low leverage. 
  • Other factors: The full cost/benefit structure includes the cost of set up the toolchain, the amount of content you make and the content pipeline everything needs to flow through. We’ll talk about these more in the Constraints section below. 

Leverage is a useful concept used in planning, but understand that it is inexact. Once content hits an audience, they may choose to elevate what the author thought of as a minor element to evergreen status. There are scenes from a comic like Calvin and Hobbes that were just as expensive to create as any other scene, but their resonance with the audience turns them into a much greater experience. 

Building content architectures involve an upfront cost: You need to pay for tooling. And learning the tools. And iterate on standards for your content. This is all before the team as author any shippable content chunks. 

Traditional marginal media content costs are mostly linear. Once you’ve standardized on a chunk of writing, video or imagery, there are few meaningful economies of scale. The cost to create one comic panel is roughly the same as the cost to create a similar panel 100 pages later. Most efficiencies occur by descoping standard chunks and cleverly interweaving low cost chunks with high cost chunks. 

In games, we can create non-linear content architectures: Content architectures can introduce non-linear leverage into the process of content creation. Such that for each additional hour of author labor, we get some more rich player experience out than if we had naively been making traditional content. 

Diagram 1: Stages and costs of content chunk creation

This graph helps visualize trade offs. 

  • A – Tooling Complete
  • B – Initial learning and prototyping cost paid, first content chunk created. 
  • C – Break even on your fancy content pipeline. This is the first time all your work has a net benefit relative to just manually creating stuff from piecemeal. 
  • D – Exhaustion sets in. Additional meaningful content is expensive because the player gains less value from each additional chunk of this type of experience. 


Let’s say your goal is to create a high leverage content architecture. The first place to start is by understanding your constraints. I couch these primarily as questions a team needs to answer, since the answer will vary substantially based on the project. You’ll need to consider both sides of the leverage equation: 

  • What is the cost of designing, building and testing the content?
  • What is the effectiveness of the content?

Cost – Prototyping: The goal here is answering the question “Would this imagined content deliver the experience we desire and how?” 

  • What are your goals for this type of content?
  • How long will it take you to establish and explore the playspace limits for a particular class of content chunk? 
  • What is the risk that this prototyping effort won’t pay off?
  • What are lower risk fallbacks if the prototyping fails to pay off? 

Cost – Standardization: You need to create standards that eliminate edge cases and prevent the creation of weak content. This step is not free and often ignored.

  • How long will it take to create easy-to-communicate standards for the prototyped content? 
  • How does the content fit into the content pipeline? 
  • What tools are required to achieve desired efficiencies? 

Cost – Iteration count on each chunk during production: Iteration is also not free and is commonly ignored. 

  • How many implementation->playtesting->feedback iterations are required before the content chunk is polished and ready for the player?

Cost – Iteration speed: The speed of iteration typically determines how many you can fit. In my experience, the quality of content is directly correlated with the number and frequency of polishing iteration. 

  • How long does it take to iterate on a chunk? Consider author iterations, where the author is testing based off their own playtesting perceptions. And also consider external iterations. 
  • How can tooling be improved to speed up iteration?

Cost – Human resources: Each iteration heavy process needs to be designed, tested, optimized and mastered by living human beings operating at human-speed not computer-speed. 

  • How many people across various disciplines does this chunk cost to make?
  • How long does it take people to master the creation of a chunk?

Cost – Technology: All that data only works because it hooks up into code. 

  • What is the cost of the tech that supports the content?
  • Can you reuse or extend existing code when you add a new content use case?
  • What sort of dependencies and rigidities do certain tech choices create?

Cost – Game systems: Game play is a complex interlocking system of game mechanics and associated feedback loops. The content expresses and explores the playspace created by these systems. 

  • What is the base cost of the game mechanics the content feeds?
  • How much content and of what types do game systems need to be fun?
  • How many game systems need to be in place before you can test the validity of the content?
  • How long does it take to balance the content across the various systems in order to test it?

Cost – Communication: As you add more people, their interdependence often increases the need to talk through design intent and issues. Hand-offs can be expensive or sources of blockage. 

  • What are the hand-offs?
  • How do you make the hand-offs as efficient as possible? Where are blockage, delays or backlogs occurring?

Cost – Risk of failure: No creative undertaking as a certain outcome. Risk is converted directly into a cost in the form of rework or needing to implement an alternative design. For any specific class of content, you might not pay the cost, but over time the project as a whole will pay a higher cost for higher risk content. 

What is higher risk content? Time and resources are two factors that have a giant impact. But the factor I’ve found most predictive is the past experience of the individual or the team. An experienced team will often know how much time and resources they need. An inexperienced team will be too busy exploring what they don’t know to budget effectively. 

In order from lowest risk to highest risk

  1. Content you’ve successfully made many times. 
  2. Content you’ve made 1 to 2 times. 
  3. Content similar to something you’ve made before.  
  4. Content that has clear playable examples in another game and you seek to copy the identical functionality. 
  5. Content inspired by something someone has made, but has not been demonstrated. 
  6. New content that has no direct analogue. 

Note that there is both individual risk and team risk when talking about experience. If a task involves lots of people and they have not worked together before, they have a much higher risk of failure even if an individual contributor successfully worked on a similar project in the past. 

One might think this sort of risk spectrum results in cookie cutter content. But that is not necessarily so, especially with smaller teams. A style of content produced by someone who has spent years working on an uncommon set of skills will often be lower risk than that same person trying to copy a popular style of content. Always consider the fit between creative skills and content, not just popularity or examples. 

  • What is your team good at? What are they experienced at?
  • What content standards can you borrow from other projects?
  • What is the risk of failure for this chunk? Does it fit in a portfolio of risk?
  • Are your fallbacks if a prototype fails lower risk?

Cost – Late Revision: Only at the end of the project does the team start getting high volumes of quality player feedback. With live games, the bulk of the critical feedback will happen long after launch. So now you’ll need to update key load bearing chunks of content. What was ‘finished’ needs to be opened up, rebalanced, revised or completely redone. 

Late revision is particularly problematic for games-as-a-service. If your initial launch is even slightly successful, the title will spend the majority of its life undergoing constant revision. The rigidity that you bake into content becomes a major constraint on the cost of future updates and whether or not your team can sustain the project. You live with it forever. Teams who only know single player games struggle here and need to reevaluate most of their assumptions. 

  • What does it cost to change a chunk of content after it is finished and tied into all other dependencies? What does it cost to replace it?
  • What does it cost to change a set of content? What does it cost to replace it?

Diagram 2: Design insights happen throughout the schedule not just at the beginning. 

Diagram 3: If your content pipeline is not amenable to late state changes, you’ll fail to capitalize on most of your design insights. 

Total marginal chunk cost: So there are lots of costs that go into making a chunk of content. Be sure to honestly measure and summarize these. Blindly insisting on an optimistic fantasy helps no one. 

  • After paying prototyping and standardization, what does it really take to call one additional chunk of content ‘finished’? Include iteration cost, human resource cost, communication cost. 
  • In the cursed wail of every team edging like Zeno towards the finish line, what is the true cost of calling content “done”? 

Effectiveness – Load bearing: We now can talk about the other side of the leverage equation. Let’s start with how some content is more important than other content. A game has pillars made of key experiences that it needs to deliver in order for it to be successful. This is the heavy weight of player, publisher and market expectations. Various mechanical systems and content support those pillars. Those that bear the most weight and would hurt the game most if they failed are considered “load bearing”. 

It is also worth identifying content that is “non-load bearing”. These are places where you can use lower cost content. You might reuse existing content or apply generic purchased assets. Alternatively, you can use the fact that non-load bearing content is low risk in order to experiment and be playful. I often find some non-load bearing chunks like item descriptions and inject them with my quirkiest writing. Or give authoring of this content to someone who is learning. If this content fails, the game won’t fail.  

  • What are the pillars of your game? 
  • What content is critical to supporting those pillars? 
  • Is a particular type of content load bearing? Or is it non-load bearing?
  • What is the fallback if this content doesn’t deliver on its promise?

Effectiveness – Optimal set size: No practical system is scale free. On one hand, you want this number to be as high as possible in order to maximize the prototyping investment. However, standardized content chunks also fade in effectiveness over time as well. There is often less marginal utility to a player as they experience the 200th level compared to the 1st level. And if you are crazy enough to make a 5000th level, the utility can turn negative. Some players start to see the patterns behind your standardization and will ignore or resent non-meaningful variation.

  • What is the size of the playspace this content addresses? Is it small? Is it large?
  • What is the sweet spot for set size where each chunk of content remains distinct and meaningful to the player? 

Effectiveness – Resonance with real player motivation: This should fall out of the exercise of determining if content is loadbear, but it is worth treating as its own thing. The best content helps players fulfill their deepest intrinsic motivations. When content and system support support the various factors of self-determination theory, we see increased retention, engagement and player satisfaction. 

  • Does the content facilitate competence? Does it help the player learn skills? Or feel a sense of growth?
  • Does the content facilitate autonomy? Does it help the player feel like they’ve chosen their path? Does it help them express their identity?
  • Does the content facilitate relatedness? Does the content connect the player with others who support them? Does it enable reciprocation loops that deepen relationships?

Basic Architectural Patterns

Now that you’ve got a bunch of knowledge about what type of content you need to make, you need to build the system that helps you make that content. Here are some techniques I think about when building high leverage content architectures. 

Take these with a grain of salt. I find that as a team gains experience in a domain, they develop new tools and vocabulary custom tailored to the tasks at hand. So I encourage you to set strong constraints and then deliberately grow your team’s ability to experiment with and iterate on more efficient tools. 

Each of the following tools will likely take your team a full game or two to start to understand and master.

Lego blocks: Embrace composition by building player facing experiences out of highly reusable standardized content chunks. Consider a non-lego block design like early graphical adventure games. Every pixel on the screen was hand placed. Every interactive puzzle was hand-scripted. Deep in the code there were common structures, but there was very little modularity or reuse. 

Consider a game like Super Mario Bros. The world is composed out of standard block types, standard enemy types and standard player moves. Tiles are placed on a grid so their relationship to one another is highly predictable. The cost to create a screen of a Mario game is much less than the cost to create a screen of an adventure game. (Thankfully, no one measures gameplays by screen any longer!)

Modular blocks intended to be composed together are not limited to tiles. In the puzzle game Road Not Taken, each object was built out of a stack of standardized behaviors. A block might have the ability to be pushed. Or it might have another ability to slide if pushed. Or it could break. Or duplicate itself. Or move on its own. And by mixing and matching a relatively small number of these lego-like behaviors, we built out dozens of distinct objects. 

  • What are the legos of your game?
  • What pieces of your games are not standardized building blocks? How might you turn them into reusable legos?
  • How do your legos snap together to build interesting compositions?

References: Lego blocks usually use referencing where this is a master object stored in some central location and then an instance of that content is used in the composition. 

You may store instance specific properties. There’s a trade off here. In general you want to specify the minimum number of instanced properties as possible since global late revision that touch a 1000 instances are expensive. It is better to store the bulk of the behavior on the master so that if you can make a change in one central location, the change happens everywhere. However, some instanced properties let you adapt the instance to the current context. 

  • What properties should be on the master?
  • What should be on the instances?

Templates: As you compose structures using your reusable chunks, you discover that there are some patterns you repeat again and again. Certain sub-elements might shift around, but there’s a recognizable boilerplate structure you keep needing to rebuild. To minimize work use templates, reusable structures that have blanks the author can fill in details. 

Consider rooms in a Diablo-like game. There was a set of templates that defined each room. During level generation instances of the rooms would be plunked down and connected with hallways. However, inside each room a subset of different objects or enemies might appear. So even though there were standardized, reusable templates, each instance of the room felt different. 

  • What are your common reusable patterns? Can you turn those into templates?
  • Which elements in those patterns can be varied in order to provide players with meaningfully different experiences?

Decoupling: As we’ve discussed, splitting content into chunks and assembling them into compositions creates dependencies. Dependencies aren’t always bad. References are a form of dependency where instances depend on the existence of their master. However there are many dependencies that increase both initial content creation cost and future iteration costs. 

For example, recently we built a quest that required you to purchase an ingredient (onions!) from the store. The contents of the store were defined in chunks of data. While the quest asking for store items was defined in a totally different chunk. If the store didn’t have onions, the quest was not completable. Which just so happened to break the entire game. 

This showcases some common issues with dependencies. 

  • Difficult to spot: It wasn’t obvious looking at the quest that there was a dependency on the store. The quest config said nothing at all about where you get an onion and it was only by sorting through the entire config system we found the connection. I call this content pattern “Chunnel Design” after the famous tunnel that goes under the English channel. They dug the tunnel from both the French side and the English side with plans to meet up blinding in the middle. If either effort had been off, the tunnel wouldn’t have connected. 
  • Expensive to fix: Instead of making a change in one location, we needed to make a change in multiple locations. With tangled dependencies, this can get quite expensive. In one project, we had to update 5 separate locations to get an item to show up in the store. A five tunnel chunnel. 🙂 
  • Ambiguous ownership: The quest wasn’t able to specify anything about how a player gets the onion. And the store had no idea that someone might want the onion. Neither piece of content was responsible for making sure that the desired experience was delivered to the player. Even if we did fix the issue, it wasn’t clear we fixed it in the right spot. And the next time we fixed a similar issue, we might make a different decision. Which leads to edge cases and more unexpected problems later on. 

Decoupling at the most basic level is the process of eliminating unnecessary problematic dependencies. 

  • What dependencies are helping speed up authoring?
  • What dependencies are slowing down iteration?
  • Can you remove these costly dependencies?
  • Can you explicitly state dependencies in your data so they are obvious upon inspection?
  • Can you give ownership of the experience to fewer chunks, instead of spreading it across multiple chunks?
  • Can you add automated validation so you are instantly alerted when dependencies break?

Content pipelines: As you start to engage with both composition and decoupling, we start splitting complex content into stages of work. Early stages of work, composed of templates and referenced masters feed into later stages of composed instances. Each stage has its own required tools, processes for ingesting data from previous stages and processes for exporting data to subsequence stages. Put it all together and you’ve got a directed graph called a content pipeline. 

Diagram 4: Sample content pipeline

A content pipeline might involve the following three sub-pipelines of character art, terrain art and behavior code feeding into a finished level. Notice that various content chunks pass through multiple stages in a fixed order across many tools in order to create the final output. 

Directed pipelines have some interesting properties

  • Stages are composed in a fixed order: This ensures reproducibility of results. Selecting the right order is a big design choice that impacts your content production schedule. I often think of this as “up pipeline” and “down pipeline”. Changes at base stages cause ripple effect down pipeline. Changes down pipeline have fewer later stage dependencies, but have a linear cost to make change. Which can be a very expensive number if that surface area of content at the end of the pipeline is large. 
  • Manual composition: Order matters so much because often the earliest pipeline stages are created and locked down. Then subsequent stages are built on top and the earlier stage is never changed. In platformers, designers build a chunk of player movement with locked jump distances. And then the layer of level design is built on top of this. Manual composition creates strong dependencies. Changing or replacing a locked stage invalidates the later stages. If those stages (such as hand crafted level) took time to build, naive changes to earlier stages can cause immense project thrash. Managing scheduling of locked stages is one big reason why we have producers and those miserable gantt charts. There are tricks to get around this issue, such as using stubbed in dummy data or placeholders. We’ll talk more about that below. 
  • Automated composition. One way of reducing these dependencies is to automate the composition process. Procedural generation is one form of this. The rooms in a rogue-like are placed via an algorithm. If the rooms get bigger, that constraint is passed up to the next layer and the hallways connecting the rooms adapt accordingly. Unlike manual composition, the author can then make a change on almost any stage and the end content is rebuilt automatically. (Photoshop was so transformative because it pioneered automated layer composition in the visual arts) 
  • Content at each stage can be referenced: Each layer is defined in a master chunk and instanced. 

Automated composition + referenced chunks offers immense leverage by reducing the cost of authoring iteration. A content author can compose multiple layered compositions. And if late changes need to be made to ever base layers, it is less of an issue. 

Observation – Non-linear leverage appears in how you build the pipeline: What we are seeing here is a key truth. Non-linear leverage in your content architecture rarely comes from how you structure your base chunks. Instead it appears in how you build the composition of those chunks. In my experience, the more you can move into hierarchies of composition, more leverage is available. This introduces its own complexity and cost so it isn’t a silver bullet. 

Advanced Patterns – Manual composition

Sadly, it is rare that we can apply automated composition to every composition process in the pipeline. Anywhere there is manual composition, the order that elements are created matters. This presents some challenges: 

  • How do you schedule work so the right stuff is complete before the next stage needs it? 
  • How do you reduce the cost of making mistakes?

There are some common strategies. Any or all of these can be mixed and matched. 

Vertical Slice: Build out a representative segment of the final content at full fidelity, test it to verify validity. Then meticulously lock down standards for each pipeline stage. In production, build content to these standards and trust that the end result will deliver on the promise of the vertical slice. 

Issue – Slow iteration: However, building the vertical slice is expensive and leads to slow iterations. Imagine building out a whole level with complete mechanics and final art, discovering it doesn’t work and then throwing that away. I think of it as “Building the game five times” More often than not, teams get into the second or third iteration and are canceled. 

Issue – Bureaucracy: Another issue with vertical slices is that it puts immense pressure on the standards. They must be perfect and they rarely are. The answer is often more documentation. This acts as an organizational tendency for large bureaucracies and large teams where waste is common. Due to rigidities in the system, change — when it does occur — is often a destructive coup or pogrom. Vertical slices are very common in AAA. 

Bottoms up design: Identify most core “up pipeline” stages. Prototype them. Test them. Ensure they are fun. Polish them to a high degree of fidelity. 

Now lock down that element of the design. Then move onto the next stage of the pipeline that builds on the locked down stage and repeat.

For example, if you are building a platformer, build, polish and lock down the most perfect jumping you can create. Then build a small level with blocks based off jumping so your game grows like an onion from the innermost layers. When you hear the advice “Focus on a fun core mechanic” it is usually a sign of bottoms up design. 

Issue – Highly systemic games: An issue here is many games require multiple interlocking systems to be in place before you know the game is fun. Consider a game like Animal Crossing. It certainly has central mechanics like chopping trees and running around. But (having just worked on a game in this genre) until economy, narrative, pacing, affordances, inventory, other minigames are all in place, the game is desperately unfun. 

Issue – Late stage changes: The other issue is again one of managing late stage changes. If you discover that you screwed up an aspect of the core gameplay early on, it can be expensive to pay the cost of that change rippling out across all the dependent layers of the content pipeline. An MMO (Age of Conan) baked the timing of their attacks into their female character animations. When community playtesting suggested they needed to speed these up, it was an expensive fix. The early assumptions baked into the content architecture bit them. 

Placeholders: Build a vertical slice of your game, but fill it with low fidelity placeholder content. This lets you test the game quickly and identify issues. And since the placeholder content is relatively cheap to make, throwing it away doesn’t destroy your budget. As you become more confident of the validity of the work, you start refining and polishing. 

This pattern shows up in all sorts of areas

  • Paper prototyping: Mechanical content
  • Grayboxing: Spatial content
  • Wireframes / Storyboards / Animatics: Sequential content
  • Concept Art: Visual content

Placeholders can be used with either vertical slices or bottoms up design and they inherit most of the same issues. Bottoms up design often results in piecemeal prototypes that don’t really tell you how the final game will play. Vertical slices still result in a lot of throw away work, but since you are using placeholders, iteration is much less expensive. 

A version of the vertical slice + placeholder that I’m intrigued by is the “playable skeleton”. With this strategy, you create a full version of the game that is playable end-to-end as inexpensively as possible. And then you perform subsequent polishing passes until the game reaches a shippable state. Thimbleweed Park was built using a similar technique with a full playable version of all game rooms complete and iterated on before final art was added. 

Issue – ignorant stakeholders: A common issue with placeholders is that stakeholders do not have the critical sophistication to understand what is placeholder and what is final. Games have been canceled when an executive looked at a graybox level and wondered why this game they are spending millions on is so obviously ugly. Many teams end up with a secret rule to only show their publishers near final art and claim it is placeholder. The risk of getting that one ignorant person is too high for honesty. And education can be an impossible lift. 

Issue – weak player affordances and feedback: Players also don’t always understand placeholders. There’s an art to picking comprehensible placeholders that work well in a placetest; abstract boxes and colors are almost never the right answer. Instead go for lower fidelity content that is still thematically and symbolically representative. If you are supposed to be petting a dog, use a picture of a dog. You’ll learn important lessons iterating on the right affordances and feedback even in a prototype. 

Scaffolding systems via value anchors: The challenge of cheaply validating systemic designs is unsolved. It is common, even when using vertical slices or playable skeletons to spend months (or years!) in the dark valley of faith as various systems slowly come online. 

For example, in order to test a crafting system, you need to build the crafting system, a UI, add the crafting content, add sources for that content, balance the sources, balance the crafting costs and finally anchor the crafted items to a functional purpose within the broader game. Even if you build the base crafting functionality quickly, the other elements take a lot of time and effort to coalesce. 

One approach is to stub in value anchors early in production. This is usually a large sink that’s easy to build but still gives purpose to the various content systems. By building the anchor first, you have something to judge the activities against. Later you can still add secondary activities and more nuanced anchors.

Some examples: 

  • When you prototype an RPG, you can create a player level that is fed with XP. Then you can have various activities like combat feed into XP. Player levels feedback into power which in turn allows tackling of harder monsters. Later you can add additional skills, enemies and resources that expand the system. But you’ll always have something playable from early one. 
  • Animal Crossing has a large sink in the form of paying bells to upgrade your house. Whatever activity you do results in items that can be sold to generate bells. This creates a simple skeleton to slowly add more activities, more resources and ultimately more player goals. 

Anchors are a bit tricky to get right because they aren’t purely mechanical. They are about setting up systems of value and tie into deep player motivations. The reason upgrading the house in Animal Crossing is interesting is not because of the mechanics of upgrading! It is because the house holds your decoration and items, which in turn act as a signal of identity, progress and status. In our Animal Crossing-like Cozy Grove, we’ve built a prototype that had upgrading your ‘house’ without the decorating aspects. It didn’t anchor player value at all. 

Advanced Patterns – Automated Composition

There are also content architectures that open up when you enable automated composition. This is an exciting open area ripe for additional experimentation and research. I expect over the next decade or two, we’ll see a steady adoption of content architectures with various forms of automated composition. Here are a few ideas that I’ve found helpful to get you started. 

Thinking of procedural generation as an authoring helper: Broadly, many of our existing tools in this space are termed “procedural generation”. But this field has problematic roots. 

Researchers and new proc gen developers look for magical algorithms that provide fountains of surprising new content. Like old cranks searching for perpetual motion machines, they hope to one day crack the problem of an infinite experience generator. It is very much the perspective of an engineer who is not an artist but still wants to magically create without learning art. Though certain machine-learning efforts show promise, I personally have no interest in this particularly philosophical approach. 

Instead, I look at procedural generation entirely as a tool for high leverage content

  • How does it make the content creator more efficient? 
  • Does your content author understand the tool?
  • How can they create richer content that resonates with players? 
  • How can they reduce iteration time?
  • How can they decrease the pain of late changes?

It is these last two area where procedural generation techniques shine. A good automated composition pipeline allows designers to make changes at most stages and have those changes flow through into the end experience with little to no manual rework. 

However, procedural generation has a very real upfront cost. You need to abstractly design about your content and how it is assembled. And build all the tooling for those specialized chunks. And then build the automation that assembles them. This can cost many multiples of just building a single content chunk manually. Long term, you accumulate benefits in terms of cheaper iterations, but it is rarely clear that the initial investment was worth it. 

Technique – Combinatorics: Do you need 1000 chunks of content in a set? If so, the cost of making that content is often high. And the post-release cost of changing that set is likely high as well. 

One technique is to split your desired content into sub-chunks that are arranged in orthogonal sets. And then use combinatorics to generate an expanded set of final content that covers a wider surface.

For example, in our game Cozy Grove, we have shells on the beach. This is split up as follows

  • Shell type: This is a small set of 6 basic types like clam, conch, whelk, starfish, cowrie, coral. Each of these chunks contains a set of properties for image, price, chance of spawning. 
  • Shell season: This set contains 4 seasons and color variations across those seasons. It also contains filtering information so shells don’t spawn in the wrong season. 
  • Shell rarity: A set of five rarities. Each contains modifications to chance of spawning and price. Additional information about which bitmap to use. 
  • Master shell definition: This tells how these 3 orthogonal sets are to be combined. It also contains any properties shared across all shells, like behaviors or dusting value. 

Once each of those is defined, there’s an automated composition step that combines them all together to generate 120 (6 * 4 * 5) expanded variants. This also provides us with non-linear leverage where adding one new shell type adds 20 new shells to collect. 

Issue – Bowl of Oatmeal: Combinatorics make it trivial to create what Kate Compton calls Bowls of Oatmeal, vast amount of content that is neither perceptually unique or differentiated. Players will tend to latch onto patterns shared across your spread of content and filter out non-meaningful variation. The infinite yet weakly differentiated worlds of No Man’s Sky are one example. 

There are a few techniques I’ve found useful here. 

  • Choose smaller set sizes that don’t trigger player exhaustion. Small, highly differentiated sets are often much better than large undifferentiated sets. If you split your placespace up too finely, you get oatmeal. 
  • Use cheaper content like names to obscure the rote nature of combinatorial expansion. One thing we do for shells is give every combination of season and type a unique name. That’s only 24 names and took very little time. And concatenating “rarity + 24 unique names” results in strings that feel unique. 

Technique – Chocolate Chips Cookies: Another composition pattern is to mix high fidelity setpieces in a low cost substrate. You can think of your templated setpieces as chocolate chips. Players love them, but if they repeat them too often, they burnout on consuming them. So they must be used sparingly. And the substrate they are embedded in is the cookie dough. Pleasant, filling, endlessly edible. But not very unique or interesting. 

Individually, these two types of content have flaws. The dough is low cost, but also results in bland experiences. The chocolate chips are high cost and overly consumable. But they provide great peak moments. By creating a pacing structure so that just as players are getting bored of the dough, they encounter a chip, the value of both can be extended. 

In rogue-likes, you author setpieces in the form of rooms and boss encounters. And then you embed those in levels composed of randomly generated hallways and generic rooms. Just when you are getting tired of slogging through endless corridors, you see a magical unique room that changes the rest of your run. 

  • Imagining the final experience, what aspects deserve to be meticulously authored? What aspects are filler?
  • What are your set pieces? Prototyping, standards, production processes and costs. How often can each one be used before players consume them?
  • What is your substrate? 
  • What is the ratio of set pieces to substrate?
  • What is the pacing of setpieces? 

Advanced Patterns – User content

There’s also a set of more volatile patterns that involve leveraging your players. You give up control and risk quality, but sometimes gain new sources of content far beyond the resources of your team. 

Player sourced testing: If you have a strong pre-release community, you can ask them to test the game. This is perhaps obvious, but in the language of the model we’ve been discussing, it facilitates getting back rapid and rich feedback on your iterations. This path also includes analytics. 

Player sourced game content: You can go further and source actual content chunks. The most common example of this is crowdsourced localization, but it can be extended to other types of content. 

In Realm of the Mad God, we crowdsourced much of the pixel art. Some important lessons from this and crowdsourcing localization: 

  • User friendly tools: Players don’t have the patience to learn typical developer tools. 
  • Robust standards: You need explicit, heavily validated standards. Developers need a path creating the content right. Players need to be prevented from creating the content wrong. These sound similar, but the latter is a much harder requirement.
  • Credit: Acknowledge their contributions. This goes a long way towards encouraging them to help out. We held contests that were very effective. 

Mods: Post launch you can open your game up to mods. It is quite common for long lived popular games to source entire expansion packs or members of the ongoing dev team from the mod community. It is a gift that keeps giving. 

In-game social content: You can also build tools inside of your game and incentivize players to create content for other players. There are many variations of this, but the main thing to note is that good UGC systems require you to design your game around them. Not a simple add-on, but something at the heart of the core loop. Examples: 

  • PvP: Players act as enemies for other players. Counterstrike, Chess. 
  • Base builders: Players create bases for other players to destroy. Clash of Clans
  • Building games: Players cooperatively build in a space together. Minecraft, Factorio
  • Design games: Players create levels for other players to play. Super Mario Maker, Dreams

Meta: Designing tools

So far we’ve been mostly talking about how you design your data and the structure it lives within. But don’t forget that authoring this content is a human process; someone needs to create by hand the work feeding these magnificent pipelines. And for that you need great tools.

The goal of tools: Tools multiply the efforts of content authors. They help create:

  • Richer content: Tool unlock the ability to make types of content that were otherwise impossible or too time intensive to consider. 
  • Cheaper content: Tools enable an author to create a chunk of content of a desired quality level more quickly.  
  • More polished content: By reducing iteration time and improving feedback, an author is able to quickly polish their poor rough drafts into something that delivers 

Unless you get into generative systems, they tend not to be used to create large quantities of new content from some base seeds. That’s more the role of combinatorics or other proc gen techniques. 

All game tools are custom designed: The first and most critical lesson you should learn is there are no standard tools. Every tool needs to be custom tailored to best fit the following constraints

  • Skills of author: What level of abstraction does the author work best in? What affordances help them do their job? Game tools generally target intermediate and experts. 
  • Requirements of the content chunks: What is the minimal set of data that should be hand authored to make an effective chunk?
  • Ingestion of the content: What is the efficient process by which authored content is connected up with the rest of the game?
  • Iteration requirements: How do the tools enable the author to make and see changes rapidly?

I suspect some of you are thinking, “But I have Photoshop! I have Maya! I have Unreal! Those are standard tools.” Sweet summer child. 

Modern commercial tools are powerful enough to do almost anything. Without identifying and serving the previous constraints, you will flail. So like it or not, you still need to establish standard practices, procedures, naming conventions and automation scripts in order to use even something as ‘standard’ as Photoshop to efficiently build your specific game. There will always be a tool design process for each game, even if it is built on top of an existing tool chain. 

A process for designing your tools

  1. Constraints: Identify the four constraints for a particular type of content: Author Skills, Content requirements, Ingestion Pipeline, and Iteration requirements. 
  2. Initial Sample: Create an example of the type of content you are making. Get feedback from stakeholders if this is what you want to build. 
  3. Brainstorm building the sample: Talk to a real author. Not an imaginary one, but an actual person who is going to be creating these things. How would they build this? Is there anything that exists that could be leveraged? What are problems and workflows they imagine will come up? Small, cross functional strike teams are very effective if multiple people are involved. 
  4. Build a first version: Try for the 20% of features that gets you 80% of the functionality. Test the pipeline of creating and ingesting and seeing the content in the game end to end. 
  5. Get an author to use the first version as soon as possible: Have them make real content that is expected to be in the game. Listen to their complaints and dreams. 
  6. Fix issues: Fix as many easy issues immediately. Prioritize one or two big asks for the next rev. Repeat these last two steps until the tool converges on something ‘good enough’; it will never be perfect. 

Mistake – Not basing the tool features off real content needs: The most common pitfall that plagues tool creation is that feedback and iteration steps (2, 3, 5 and 6) simply never happen. An engineer makes a tool. They (or antsy producers) declare the tool finished and the rest of the team is told to use it. 

  • Often this first pass contains the wrong features. 
  • Or weeks are wasted over engineering aspects that are unimportant. 
  • Or they’ll have built in major workflow problems that are invisible to them because they don’t understand that X is an operation you need to do 300 times in an hour, not once per week. 

In the best case, content authors don’t even use the tool and find cheaper workarounds that get the job done. You just lose the engineering effort. In the worst case, content authors use the tool but they spend truly enormous amounts of wasted time jumping through avoidable hoops. The result is typically bad, hacky content that was expensive to create. And often needs to be thrown away. 

Mistake – Delays building real content: The next most common pitfall is that there is a large time gap between the first version being built and an author uses it to create real content. In addition to general problems of skipping iteration, waiting too long has the following negative effects. 

  • Change becomes expensive. Code and processes petrify over time. When an engineer still has the code in their brain, feedback from the author is much easier to implement. Small tweaks happen quickly. 
  • Authors are never taught how the tool works. An immediate dialogue between the creator of a tool and the content author inevitable results in knowledge transfer. So many times I’ve realized that there was a keyboard shortcut already implemented for a laborious task. But the conversation happened a month after the tool was built and the engineer had forgotten. 

Tip – Shadowing: Content authors infest old tools like fungus in a moist fecund jungle. Strange content will seep out of every crevice in the toolchain. Wait long enough and you’ll see workarounds built off hacks forming the foundation huge swaths of your content. Authors learn, adapt and push tools in ways many find horrifying.  In the process, inefficiencies creep in as the tool ends up being used in ways it was never intended. 

This is normal. And it is a good thing. Clever content creators are discovering new opportunities and new requirements that couldn’t be predicted until they put a few hundred (or thousand) hours into actually building the desired content. 

The first step in supporting your fungal creators is to understand how the tool is used in the real world. Shadowing is when a toolmaker watches a content creator build something. It is like playtesting for your tools. 

  • Share a screen as a content creator builds something. If they start doing something strange, ask them why. The answers are delightful. 
  • Record how long things take. Is anything surprising? A fun exercise is predicting how long you think things will take, and then compare it to reality. 
  • Brainstorm ways of reducing iteration time. Can steps be removed or automated? Can automated steps be sped up? How would you make this process 10X faster?
  • Review standards: Do they need updating? Can edge cases or expensive exceptions be avoided going forward?

Final notes

We’ve only managed to cover the most basic aspects of game content architectures. I hope you find enough here of interest to explore further. Observe your own projects with a critical eye, experiment when possible and share notes with others. For deep skills that cross multiple disciplines, a document alone will never be enough. 

Be humble. Content architectures are not a magical silver bullet for making more meaningful content with less effort. They can be a huge pain in the ass that introduces immense complexity, costs and risk into your game. Because of the effort it takes to build and tune them, they often delay your ability to start playing the game. 

Diagram 5: When each incremental chunk is expensive and you need a lot of them, a higher leverage content pipeline might be worth your time. 

Learning curve: Any content architecture and toolset has a substantial learning cost. The specific team using the system needs to understand and practice building great content with the tools. I don’t mean to frighten anyone, but this can take years. A level designer who has been using Unreal for 3 years will generally be a lot more effective than one who has been using it for 6 months. A team that has been building content for a specific genre on a specific engine will be much the same. 

Often the best tools and processes are the tools you know: I’m regularly amazed at how simple tools and simple content in the hands of experienced, talented teams results in world-class experiences. The content architecture of a novel isn’t complicated. Just a series of chapters composed of a few hundred pages. Authored using bog-standard text editors. Yet we give that to writers with years of experience under their belts and amazing work emerges. 

A lot of times, you can just throw talent at a problem. And if you need to scale up, throw more bodies into the pipeline. This path is always an option as long as you’ve kept your content modular and highly decoupled. 

The final constraint: Hand-authoring is our ultimate pinch point. Humans can only work as fast as humans work. They need to dream, experiment, clumsily and slowly make mistakes. It takes  “human time” to have moments of insight and creative breakthroughs. 

Naturally, as beancounters and producers, we want to multiply those efforts. To stretch out that costly thing and increase efficiency. 

But this hand-authored content is also the soul of our games. Dilute it too much and you destroy the very thing that provides value. “More, Faster” is not better if you are churning out garbage. 

Your content architecture is a delicate balance act. Where do you put all your limited, beautiful,  messy, human effort in order to provide the highest quality experience for the player? A worthy design challeng e.