Design Documents

Design documents are a pain to create but are the best references that designers can create for the team. I’d recommend to take at least a month and write down every little design aspect. The best documents are hundreds of pages long!

During this phase you should be able to tell whether or not your game is too ambitious for your team. If it is try to cut out gameplay features. There’s always room to add those in for a sequel. 😉

With The Divine, we built the engine before the game itself was fully designed. We knew that we wanted a space shooting game but we didn’t plan to put in special effects and the sort. Inadvertantly the coding is a little messy and locating a bug is becoming rather difficult. Now if we knew ahead of time every little aspect that we would need in-game we would have been able to write a more efficient engine that would suit our needs. But oh well we’ve learned from our mistake. Make sure that you do too.

Perfecting Games aka Testing

When it all comes down to it playing the game is when you can make it perfect. While the design documents are well thought out it’s near impossible that they programmers won’t have to go in and tweak every aspect of the design.  

Figuring out why a game is either not fun or bad is a difficult process. You must be able to dissect the game. Look past all of the eye candy and figure out what is going on behind the scenes.  

This is one of the reasons why I suggest everyone should work in the QA department at least once in their career. If most games are clones and nock-offs of each other, why do some flop while others are AAA? It’s all because the team either did or did not spend the time tweaking the game.  

In The Divine we’re are currently tweaking the gameplay. When we originally began the project we knew which games we were going to base our game off of, but we never deeply went into what makes each of these games fun. We skimmed them saying well it has to be an epic in-space dogfight. What the hell does that mean?! Exactly my point.Â