Learning Curve – Documentation

12 Jun

Let’s talk about documentation.

Am I right? Not entirely. Maybe not even at all. But what I know is that I’m definitely a doer type of person, I learn much better by actually doing things or having some form of visual representation to interpret from, rather than reading a giant block of text.

Doer Image

Look at how some of my previous games have turned out, Explosive Pinball, Infinity’s Edge Tower Defense or Hill Climb Havoc. They might not be perfect but they’re games! 2/3 of these actually had zero documentation. What’s the problem with that? Nothing really, considering the size of these games. I knew I was going to make a game that was “Pinball” with explosions, and a Tower Defense that was systematically close to a Warcraft III – Wintermaul Tower Defense. But on a much, much less complicated or of such a beautiful scale.

I had a reference point and went ahead and made my own tower defense, learning the things that I needed to along the way. The rest of the creative process had no structure or clear things that had dependencies. I was just going about this willy nilly. When I stumbled across something that needed something else in order to work, I would have to set my focus on that and then return. But what if there was a way to partly figure out the majority or even all of the systems and things before I even opened Unity?


Like through documentation such as a Game Design Document, Technical Design Document, Level Design Document, Asset List or the hundreds of others that I’m not even aware of yet. So instead of going to make things willy nilly, defining what systems should be in place, how things interact or what they look like would be a much better start than just “Things can do stuff”. I’m no expert on writing this stuff and at the start it can sometimes be difficult because of the lack of knowledge of what goes into these particular documents. It can be frustrating, and that’s why I wasn’t overly enthused about writing documentation for game design. I definitely didn’t think it was useless and pointless, but I certainly didn’t know how much of a difference this can actually make.

A small project is underway called “Ball Ball”. It’s a 2D ball slinging game. Even just writing those four words, without describing anything else leaves so many questions unanswered. How many questions are being raised in your head?  The game that you’re thinking of and the one I intend to design are most likely completely different. A GDD is in order then yes? That should clear things up. I’ve currently got one that is 16 pages long with a large amount of questions being raised on almost every page. Thanks to my classmates and facilitators, they help question what they don’t understand. I might have a good understanding of what needs to be created and how they should interact, but the people who read these documents might not. By people having to ask questions it reveals that the design hasn’t been clearly detailed or thoroughly flushed out. But that’s fine because through iteration after iteration of elaborating more on these documents the design foundation becomes more solid and clear.

So some design is in place that states this game will have TNT, and this TNT will explode on impact with the ball. In a TDD this should detail specifically how it will interact with the ball and the reprocusions to it’s explosion.

  • Ball collides with TNT.
  • TNT explodes.
  • TNT explosion makes things move.

Does the TNT’s explosion move the ball? Does it move any other movable objects in the game? Does a TNT explosion trigger other TNT to explode? Can anything else other than the ball trigger a TNT explosion?

Has any of this been defined in the GDD? In the process of writing exactly how the TNT should work and systems that would need to be in place in order for it to work I’ve suddenly realized that only a small portion of this TNT has actually been figured out. Switching back and forth between all of the design concepts and trying to detail specifically how they interact and the systems they need helps reveal and figure out some of the problems before the game is even started.

I might have not been very enthusiastic about writing documentation before, but thats a learning curve I’m happy to take on board. It serves a purpose and it’s there to help carve a clear path to the destination while saving time doing it.


{ Lose() }     else     { Win() }

Knowledge comes from experience, and practice makes perfect. While my documentation may be far from perfect, the more and more that I do it, the better and easier it will be. It will benefit myself and others, because eventually I won’t be working on games that only require a single person to make.

Here’s a handy forum post that I find helps to describe some of the things that make up and go into game development:

The Eifel Tower wasn’t made without a plan, and I bet World of Warcraft wasn’t either.


Until next time –






1 Comment

Posted by on June 12, 2016 in Uncategorized


One response to “Learning Curve – Documentation

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: