The Meta-Game

Some game design decisions are hard boundaries — if you jump off a cliff you die, if you try to walk from A to C you will be blocked by a wall, and so forth. Just as often, though, design decisions are more like nudges to the player — fire is effective against ice enemies, turret emplacements are effective against attacking groups, climbing gear is useful for steep terrain, etc. These are the design decisions that don’t define hard boundaries, but that establish an expected approach for the player to take, pushes them to try new things and to experience the world in a particular way. Some of these, like the above examples, are very obvious. Some, such as a tough enemy placed to divert the player towards an interesting side passage, can be quite subtle.

This is all fairly well-understood by most designers. What I’ve found very interesting to think about recently is considering, in addition to how design elements shape the behavior of players, how they shape the behavior of the designer downstream. Whatever design precepts are established early on, these shape the design behavior further on in the project — even if these precepts are later reconsidered and reworked, the impact they’ve left will be noticeable. Sometimes, as in gameplay, these boundaries are hard — deciding a game will have no combat, or that there’s no dialogue system, or that all equipment is purchasable from the start, any decision like this will determine what the narrative or gameplay possibilities are for the future. Sometimes, though, these decisions are like nudges to the future designer — a character’s appearance might suggest an upgrade, methods of acquiring and spending currency or ammo affect how equipment gets balanced, an unusual art style might afford opportunities to conceal or reveal information in a surprising way. 

The fact is, we’re not just designing the game for the player, we’re also designing it for ourselves — not just in the sense that we’re building towards a game that we’re (hopefully) interested in and passionate about, but also in that we’re going to be spending most of our days for a significant amount of time working within the confines we’ve set. How much we enjoy the task of building the game, and what direction it ultimately develops in, it all stems from these first crucial decisions. My intent in bringing this up is not to impart decision paralysis — that’s easy enough to come by in starting a new project without me helping it along. My intent is instead to encourage the consideration of two questions when it comes to these preceptive design decisions.

First: Will this decision make for interesting or tedious work in the future? It’s a given that for every design element, there’s an associated downstream labor cost, and it’s vital to consider what that cost will be. However, it’s also important to consider not just the quantity of work the decision will create, but also the kind of work it will create. Is it the kind of work you find easy to start? Easy to finish? Is it the kind of work you can figure out before putting in physical labor or does it require experimentation? Does it need to be figured out in relation to other things or is it mostly independent? These are the sorts of questions I ask — for you, the things that make a given task harder or easier are probably different. On a team it may depend on the team’s specific composition, might depend on who’s allocating tasks as well as who performs them.

Second: Will this decision lead to more or less interesting decisions in the future? In my current project, I decided to have just a few special weapons, have them all share ammo, and have the ammo be rechargeable (but not easily so) during combat. Part of the reason for these decisions was that it would force me to ask whether these weapons were all useful, whether there were situations that demanded one or another, whether they were worth the player remembering to use rather than always using the primary weapon — all-too-often I see games include hypothetically interesting items that lay unused because they’re not significantly differentiated from default abilities. Many decisions can lead to future interesting decisions. While every game ultimately comes down to numbers behind the scenes, one way or another, decisions about what numbers ought to represent can build towards later decisions. What should a luck stat do? What is the impact of a reputation system? What does an injury mean and how is it recovered from? Deciding any one of these can lead to interesting decisions downstream — which is both wonderful, because it expands the possibility of what a game can be, and terrible, because it means you’ll inevitably have to put more work and consideration into actually making the damn game.

These interrelate, of course. All too often we see designs that cut back on decisions that lead to interesting future decisions (because these are risky, they are seldom embraced in high-budget development), but that means the remaining work is more rote and tedious, less interesting, even if there’s not as much of it. We make these decisions and they shape how entertaining and challenging the rest of the project will be to work on — and thus one of the first tasks of game design is designing the game that is making the game.  While, of course, I do not subscribe to the belief that work that is fun doesn’t count as work, I do believe that making work fun makes it go significantly faster and smoother, enables developers to focus their efforts more effectively. This might sound like productivity-pilled business brain, but I’m coming at it from the context of a solo developer: If I’m going to be working on this shit every day for a year or three, if I’m going to be building something I’m proud of and investing myself into, what is the version of this that is enjoyable for me to work on and that I’ll genuinely be able to put my best effort into?

These questions are impossible to know all the answers to, naturally. What seemed like a fun creative exercise might become a stressful design constraint, and what seemed like a system full of interesting possibilities may in the end just require a lot of extra effort to reproduce standard results. There are, as always, no hard and fast answers in art — everything is a moving target. It is at least worth wondering, though, as you craft an experience for a distant and unknown other, what experience you’re crafting for yourself.

If you enjoyed this essay, please consider supporting me on Patreon.

• Art
• Game Design
• Game Development
• Game Production
• Problem Machine
• Video Game
• Video Games