Design Occlusion is Killing Your Game Design

June 5th, 2013 by Adriel Calder

Last March, while at the annual Game Developer’s Conference in San Francisco, I attended numerous enlightening talks focusing on the different ways one can approach game design.  The one that stood out to me the most was titled “Design Occlusion is Killing Your Creativity” presented by Dylan Cuthbert of Q-Games.  Cuthbert’s talk focused mainly on his time working for Shigeru Miyamoto on Star Fox for the SNES and the lessons he learned as a young game developer working with an established person in the industry.  In addition to this, Cuthbert was also faced with understanding and appreciating the differences between British and Japanese approaches to design. “We were a very cocky sort of British programmers…sort of taught ourselves everything and we were suddenly thrown into this Japanese environment….and we were kind of in awe and also kind of in shock at the same time about the process.”

However, being placed in a creative environment that differed from his usual way of thinking led to Cuthbert learning valuable new ways to approach game design.  This unfamiliar process essentially boiled down to the following steps: Build->Destroy->Discover->(Resurrect).  Before reaching this conclusion, Cuthbert first introduced to us the following lessons learned from working on Star Fox:

No idea MUST go into a game, not even if the idea is good.

Cuthbert points out that at the time, British games were full of good ideas.  However, the standard approach was to simply stuff in every idea and sell the game – operating under the pretense that if an idea is good, it obviously belongs.  He is quick to point out that these types of games would sell, but what people would find is half of a game that they would then never finish.  What he learned while working on Starfox is that it’s sometimes important to remove things, even if they are good ideas.

Creating a game that takes on too many ideas is an easy trap to fall into.  When the creative juices start flowing, it’s often difficult to cease the torrent of ‘good ideas’ and focus simply on what the core mechanics of what your game should feel like.

Question default assumptions

Star Fox initially started as an all 3D free-roaming game similar to Starglider 2.  After spending months constantly building and removing features, it finally came time to question the basic structure of the game.  After a month long break, Miyamoto approached the developers and suggested removing what everyone thought of as the core technology of the game – the 3D roaming.  Though removing the 3D roaming capability initially felt like a step backwards, by limiting the player movement to a 2D space, multitudes of interesting and fun design options were opened up to the developers.  For example – the developers could now create more refined, well-tuned controls. The game was now easier for players to understand and boss battles could now be more epic and were easier to create.  As an added bonus, they now had a much faster frame-rate!

It’s a very counterintuitive process, especially for programmers.  Miyamoto was constantly pushing developers to add new ideas, remove them, and then examine what was left in the rubble.

Cuthbert states that his approach to building new ideas was to build multiple ideas simultaneously, without allowing any one idea cloud one another. While doing so, he has to constantly be conscious of what is blocked as well as keep an overall idea of what’s going on at all times.  Once all of the ideas are in, he advises for developers to begin looking in the shadows of the new ideas.  If the game isn’t “fun”, then it’s time to destroy the ideas and look in the rubble.  Cuthbert points out that “destroying ideas is fun,” and that during this design process you can’t be attached to any one idea.  By destroying an idea, “suddenly the sunlight will just pour in and suddenly you’ll get all these other ideas just come out from underneath it and the game becomes fun”.

Ultimately, we must remember that occluders aren’t inherently bad.  We don’t have to avoid occluders at all costs, we just merely need to be aware of them.  Removing occluders at stages of development in order to focus on the core mechanics of the game will allow you to make those core decisions more solid.

This approach to game design is becoming more important as it becomes easier for developers to add elements to their game.  It is imperative to take a step back every now and again and examine your game from both from a macro and micro level. If you find that your game isn’t fun or fulfilling, it may be time to examine the possibility that there are occluders overpowering the core values of your game.  Examining each decision made throughout the design phase of the game’s creation and temporarily (or permanently) setting each element aside might be necessary to discover where the true problem lies.  As Cuthbert points out, destroying the ideas the you’ve built is not only fun, but it might also be necessary in order to focus on the core of the game.

, , , , , , ,

Leave a Reply