Alchemist

Created with Sketch.

Alchemist

It’s that time of year again. The time after IGF where I have about zero stress and get to indulge my more esoteric wants and needs. So I thought I would put down, in some kind of concrete fashion, my thoughts on the basic tenets of Game Design.
You see, my basic field of reference is not that a Designer is a storyteller. They are not cinematic artists and they are certainly not doing anything that I would ever constitute as “art.” I’m firmly in the “Games are Not Art” group, small and zealous as we may be.
No, the closest comparison that I can find for what a Game Designer should be, is a Systems Engineer. When the best games ever are boiled down to their most basic constituents, the things that make them intrinsically unique are the rules and systems at play. Think about it, take a game, any game really. Get rid of any story elements first, they’re just candy. BioShock is known for having it’s award winning story finalized at almost the last minute. Clearly it’s a great story, but the game existed as a game before it was ever added. So we can throw that onto the heap. Next, graphics, dump them down the memory hole. Leave only the visual cues that are absolutely needed – the shapes of Chess pieces, the numbers and colors on a jersey, everything else is so much fluff. Textures, shaders, shadow maps gone. Sounds too (although I do love me some sounds) except for the ones that have to be there. Guitar Hero music gets to stay because it’s an inherit part of the game – the gameplay falls apart without it. Acoustic GH sucks.
Still with me? Good. now what do we have left? All the glass and candy has been ripped out and I’ll bet the game looks a lot different now. But, what we have left is a system. Input of some kind goes in, results are calculated. There’s a black box at work in the middle and the Master and Commander of that black box is the Designer. So when a button, or key is pressed or dice rolled or an action taken, that is a certain kind of input. With a limited number of inputs the results can then be consistently processed through. So in The Thief’s Tale there is an Action Key. When the player pushes it (the input) it activates a system that considers whether or not the player is in fighting or exploration mode and then does something and provides an output. Where it gets complicated, and this is the part people never think about, is when the systems cascade together. So push the action key, while armed, against the AI system of an enemy and there are traps in play. Those are systems that all overlap in some way and changing some part creates a ripple effect.
For example, let’s give the player a gun. Let them shoot it with the Action Key. That allows them to dispatch enemies from afar and those same enemies are all designed for close range dueling. Now we’ve broken the system. It is unbalanced and no fun. Another example, let’s make enemies do more damage. Simple change really. However, the player has no way in game to gain health back during levels. So we have to consider, how many enemies are in a level? Can the player avoid them? Does changing that one variable break anything else? Is there a “dizzy” state (there’s not – I cut it) that triggers once so much damage is dealt? Is that easier to have happen now?
Needing to understand the deep inner workings of a game is what the Designer needs to do. Consider the game system to be a kind of model, and it’s very fragile. They need to add things slowly, and consider how things will interact and effect each other at every step of the way. There is simply no other logical way to do it.
From my description it would seem that I don’t think games are any fun, and making them seems like a detail hell. In fact, it’s quite the opposite. I demand that games be fun. Yes, I even used the word “fun,” not “enjoyable” not “effective” simply fun. That is the point of them in my eyes, and this is where being a Game Designer is far more difficult than being an Engineer. The latter doesn’t need to care about enjoyment, their product simply has to work efficiently. A Designer has an whole other thing to worry about, and worse, it’s not something that is fully understood.
Which brings me to the title. The search for this mythical “fun” is something that I do not think we can hammer down. I’ve read articles that try to define what this “fun” is and what to be able to describe it in a scientific way. The results, they argue, would be great. It would take away all that messy guesswork involved with the Iterative Method and allow games to be consistent and time frames locked in. It could provide a kind of built in language to express the concepts that are unique to games, instead of starting every design oriented statement with, “It’s kind of like…”
That’s the problem though, and arguably the greatest liability and greatest asset of games as a form. I use the term “mythical” when I say fun almost in a kind of sarcastic way, but it really is. I assert that it can’t be locked down. Once “fun” is defined as anything it fails to be fun anymore. It’s like the boy that’s invisible only if nobody is looking.
Instead, we use tenets, basic guidelines that define what a game should be. Hard won little nuggets of truth. The reason is that no good game is summoned up from nothing. They take work, lots and lots (250+ posts worth) of work. The initial inspiration that hit is a distant memory and the urge for newness will sometimes be detrimental to the overall game system (remember the fragile model analogy). These guidelines are what we use to combat that, but they are hardly a formalized system.
It’s Alchemy. We know that things work, and we have examples of them clearly working, but due to the big black box nature of a game system it is difficult if not impossible to know the deeper why of it. We don’t know enough about why, and we can’t nail down the elusive fun that we’re striving for. The Fun that we keep looking for is a Philosopher’s Stone.
But that’s the beauty of it. The trying for it. The pursuit of the fun. So we iterate, over and over making small changes and additions to our given system to try to understand the outcomes better. It’s the only method that has ever proven consistently useful to us.
So I say that Game Design is not, and should never be a science. It is a new way to do things, the hard core of systems engineering with the soft outer shell of ethereal fun. We don’t need a new way to describe it though, we already have one. Game Design is pseudo-science. It’s a set of unprovable tenets wrapped in ritual performed inside of a temple of the finest engineering.
At least, that’s how I see it.

Let us pray…