The Devil in the Details

Several years ago I took a class called ‘Game Design Workshop’ as part of my degree program. It was without a doubt my favorite class of my entire college career. During the class we had to create several game concepts based on specific criteria. One particular assignment was fairly simple. We just had to write up a one page description for a game concept of our choice. (There may have been some other restrictions, I just don’t remember for sure.)

My idea involved a game in which the classic slime drop monsters seen in so many games of all types were the protagonists. It was a going to be a side-scrolling puzzle adventure featuring several different slimes of differing colors, each with their own unique ability. I felt like I covered all the areas I needed to cover having explained the story, the protagonist and antagonist, the overall gameplay and level structure, as well as the various mechanics in the game. I was proud of my creation and quickly fired it off to the assignment submission box.

A few days later I was surprised when I got the graded version back to find I had gotten a score quite a bit lower than expected. It wasn’t a bad grade at all…just not as high as I thought it deserved.

Then, I read my instructor’s comments and questions.

Regarding a mechanic in which the player character must grow to progress…
What if the player grows too big for an area? Can they shrink somehow to go back if they missed something? Or are they just stuck?

Regarding the inclusion of multiple player characters…
Does the player control a different one on each level? Can they choose which one to use? If so, is the choice made before the level or can the player switch on the fly?

Regarding the progression of levels and the mentioned map screen…
Are levels independent of each other or is the whole game one big ‘Metroidvania’ type level in which the player has to acquire new characters/abilities to unlock new areas?

And it went on like that. For quite a bit considering it was only meant to be a one page document. The thing is, when I was writing this assignment I thought the answers to those questions were obvious. In fact, for a short time I was considerably upset that my instructor actually deducted points just because he didn’t understand what I wrote. But as I read through my assignment again, I began to realize that he was right.

Even though this wasn’t meant to be an in-depth design document, I had still failed to effectively communicate my vision for the game. It occurred to me that these little details were actually extremely significant in explaining how the game worked. If I presented this to the team today, I would probably be getting all these same questions and more. I had given a great overall explanation of my game, but in assuming that some aspects of gameplay were obvious (they weren’t), I made the mistake of not revealing what really made the game tick. The devil, as they say, is in the details.

Even now, a degree to my name and part of a small indie team, I find myself doing this. As designers, it’s easy to forget that we have been working with an idea since it was just a small seedling in our minds. By the time we have begun to flesh it out a little more, some of the most important details become ‘obvious’ to us.

Remember, if you are presenting an idea to your team for the first time, they don’t have the same intimate knowledge of it as you do. This is even important to remember when it comes time to write the design document where even more detail will be necessary. If you’re just pitching an idea, then obviously you don’t need every little scrap of information. (Not in writing anyway. But you should be able to readily answer any questions that pop up.) However, you should be able to concisely cover the major gameplay mechanics.

Do yourself a favor. The next time you create any kind of documentation for a game, ask yourself if you are assuming any knowledge on the part of the reader.  Trust me, it will be worth it later.