I cooked lunch for my mother yesterday, as a one-day-belated birthday present for her. My mother has been very helpful and supportive recently (and in general) and I'm lucky to be an adult who still gets to see his mom so frequently.

But during lunch I realized that my mom still doesn't understand what the heck I do for a living.

My mother is an editor / writer / poet / teacher. She's in the transition to retirement now, but she's spent significant amounts of time in the magazine & publishing industry. In that industry "design" means layout, graphics, and page aesthetics. I've called myself a designer for 13 years, but apparently I haven't made enough of a distinction between what I do and what a graphical designer does.

To be fair, "designer" is a wildly variable term, even within the video game industry. I've worked at a company where designers who couldn't program and discuss Godel's Theorem of Incompleteness were ridiculed, and I've worked at a company where designers built levels in Maya all day every day. I've even worked a job where designers were expected to write documents in isolation and never speak to the development team directly.

But even when my skills match a position perfectly, I discover over and over again than many of my co-workers don't understand the work of a system designer any better than my mom does. Sometimes even the person who hired me doesn't understand it.

So I thought it might be time to really lay out, clearly, what I do as a systems designer.

Building Along Two Tracks

A systems designer works simultaneously in two fields: Mechanics, and Game-Goals. Game-Goals are tremendously broad objectives regarding the end-user's experience. "The player should think this is hard/not hard/beautiful/scary." or "This should appeal to people who love Starcraft." or "Players should understand the controls after finishing the tutorial." Mechanics are the smallest components of the game such as setting a character's health, specifying the range of a weapon, determining the likelihood of a semi-random event, or adjusting the volume of a sound effect.

These two tracks are related, but do not directly determine one another. In-between these two tracks is what we might call "the game." Players understand the game, and can talk about the game. But nobody can (or should) see the systems under the game, unless they have trained themselves to do so.

Let me use film production as a metaphor. (I haven't done a film metaphor in months, so I think it's past due.) People who watch a film see actors, and hear dialog. They remember a story. People don't see long-cuts, two-shots, wipes fades or dissolves. They don't hear underscoring, main themes, character themes, or ambient sound. A well-made film uses those tools to produce an effect on the audience without the audience being aware of those tools at all.

So it's perhaps reasonable that my mom doesn't understand the specifics of my work.

Defining Planck's Constant

Planck's Constant is often encountered in college physics classes when learning about the photoelectric effect. It helps describe the valid energy states for an electron within an atom. A Physics teacher once told my class an anecdote about a test he took in which the only question was "How would the universe be different if Planck's Constant were greater?" I often recall that anecdote, because that sort of thinking is a huge part of my work.

In Physics there is a rhetorical question which runs like this : "Why should it be that the universe is fundamentally stable? Why are the laws of physics set up such that matter and energy persist long enough and in enough forms for stars, planets, and life to arise?" The answer is : because if the universe were not stable - there wouldn't be anyone around to ask that question.

This question is sort of a joke, but it is also very serious. We can't ever really observe or live in a physical system which is fundamentally unstable (such as one with a large Planck's Constant). We have no idea how much time passed, or how much happened in the universe before the current stable configuration was achieved.

Similarly, games you actually play are stable systems. They don't crash, they make sense, they can be completed, and (hopefully) you even get something out of the experience. But those systems don't just happen on their own - they are carefully shepherded into existence by the system designers who explore dozens or even hundreds of unstable configurations which the players never see.

Iterative Extrapolation

So what is it I do? My most time-consuming task is what I call Iterative Extrapolation - following a train of thought to its logical conclusion, backing up to change the initial conditions slightly, following the new train of thought, and then comparing the differences. This process happens over and over - sometimes with huge changes, sometimes with minuscule minutiae.

Now many people in many professions iterate on their work, but the difference in systems design is that what I am iterating on is not the content that people will see - but the system which allows them to see it. In many cases, I don't even know what the content will be yet when I work to refine the underlying systems. I might tune a projectile combat system, and it's only later that we finally decide that the game is a WWII shooter, or a futuristic prison-escape scenario.

Mostly, this involves math. I'll ask myself a question about the game like "how many evil alien prison guards could I theoretically shoot in 30 seconds?" and come up with an answer. Say 50. Then I appeal to the game-goals and ask "Is 50 reasonable? How could I increase or decrease that value?" I jump around a lot, poking the systems to see where they are easy to adjust, and where they are not. Maybe I'll go find the engineers who wrote the basic system, and ask them about what might be involved in changing it. Maybe I'll find the artists scheduling development work, and ask them about how many alien guards they are prepared to make.

This process is not about locking down decision such that we have a perfect blueprint of the game - it is mostly about avoiding pitfalls, and steering the game in broad strokes. I'll frequently push to speed up development of a system I think needs more attention, or slow down development of some content I think we might cut in favor of something else. I'm also (hopefully) building real content for the game, so I can be sure that the process of content-creation reinforces the game-goals the underlying systems are meant to support.

This puts my fingers in a lot of different pies, and it might seem to some people that a systems designer is masterminding the entire development process - pulling invisible levers to manipulate & guide the team. But in reality there are several other people who have just as wide a reach - the lead engineer is monitoring all of the systems for technical concerns, and reviewing code for optimization and elegance. The art director is adjusting models, textures, effects, and lights to communicate to the audience in visual language. Content creators are building the story that players will actually play. A systems designer has a broad reach, but so do many other people - all swarming around the same complex web in service of the game.

So in a very real sense my mom's problem isn't a problem at all - it is a symptom of the fact that my work is meant to be invisible. If system designers are guilty of inflated egos, it is probably a normal overcompensation to the fact that, unlike other disciplines, our work is hard to see. Great visual art is visible in every frame of the game. Great code is evidenced by the speed & reliability of the product. Great content tells a cohesive & compelling story. Great systems are invisible. We only know they are there because otherwise we wouldn't be able to see past them.