Simplifying the way we think about game design

Games are very complicated pieces of art. Let's just get that out of the way. Obviously, there are many layers to a game. Most basic of these are the coding, visual art, audio art, and environment (level) design. However, just because something is complex, does not mean that creating them has to be.

I've listened to some analyze the various designs of various games to the most tiny details, and it's my opinion that these people are missing the point. Even though creating games is a very complicated exercise, playing them is not. What the user sees at the end of the process, when the game is spilling out onto his or her living room through the TV set or PC monitor, is simple.

The user only experiences what is happening in the game. And from this experience, the user creates an emotion. It is this experience that creates the emotion that should be the focus of the game's designers. By focusing in on this one word, and ignoring all others, the game creator has avoided many pitfalls that other game creators fall into.

These pitfalls exist for various reasons, and not all of them affect the game negatively in the long run. But they are pitfalls, and thus they cannot be positive, and thus they should be avoided.

An example of one of these pitfalls can be found on the recent EGM podcast on 1up.com. The guest was Dennis Dyack, the lead creator of the Xbox 360 game "Too Human". On the podcast, he talks on an E3 2006 demo of Too Human that received negative reviews. According to insiders in the industry, Too Human's flop at E3 was due to the fact that right before the E3 2006 demo, Dyack and his team dumped their old engine, and applied the Unreal engine to their game. Unfortunately, the game's code wasn't optimized for the Unreal engine, and the game's frame-rate dropped to unbearable levels. Thus, when the media played the game at E3, the game was broken.

This is a pitfall. Dennis shouldn't have wasted time preparing a demo for the game if the game wasn't going to be shown properly. Dennis didn't get any usable feedback on the experience his game provided because the demo didn't represent the work the team had done on the game. Because this demo did not help Dennis improve the quality of his game's experience, it was a waste of time.

Frankly, to make a game as good as possible, all time dedicated to the creation of a game must be applied to improving the quality of experience provided by the game. Now, granted, the example mentioned above was probably (hopefully) a temporary pitfall that didn't affect the game in the long term. The bigger, deeper pitfalls, may not be as evident to a game creator, and in some cases, not evident at all.

These pitfalls, are harder to avoid, and sometimes, are unavoidable. Many game developers on the Xbox 360 and PS3 need to rely on Sony and Microsoft for money to make their games (an example would be a publisher demanding better graphics in a game that probably doesn't need better graphics). Because these companies are putting up money for development, they're probably going to want a say in how the game is designed. This may or may not be a pitfall, but generally, it probably is a pitfall. After all, how can a CEO with degrees in business and management possibly know anything about game design when he or she has no experience (in most cases) in designing games?

Therefore, these pitfalls must be overcome by simplifying the thought that goes into the process of game design.

I am currently in the process of designing my own game, Angel Wings, a side scrolling aircraft shooter. When I began the process of game development, I decided to simplify the game's desired experience to one sentence:

"Angel Wings is a side scrolling shooter that challenges the user, and makes that challenge more tolerable through comedy similar to television cartoon humor"

And from that point on, all development in the game is focused on that point. Any time I add a new element to the game, I ask myself "does this fit with that sentence I based the game around?". If it does, the element is added to the game. If it doesn't fit with that sentence, the element is not created.

This, in effect, focuses all those complicated elements of game design that I mentioned above, (coding, visual art, audio art, and environment design) around that once sentence. Thus, when I begin creating a sprite for my game, I ask myself "does this sprite provide a comedic experience for the user?". And when I begin writing code for the object the sprite represents, I ask myself "does this code provide enough challenge for the user?". And after that, when the sprite and code are finished, I ask myself, "does this sprite provide enough comic relief for the user to defer the challenge to make the game enjoyable?".

If the answer to that final question is yes, then the object is finished. And when that question is applied to an entire level of the game, and the answer is yes, that level is finished. And then the question's answer is yes for the entire game, the game is finished.

It is of course, possible to have varying levels of "yes" (one could have "yes" and "oh YES!"), and how high a "yes" you want is often dependent on how hard you're willing to work on a game. And as in any field... often, the harder you work, the better your results will be.

~Alexander