Post-Mortem

The following blog article references the app ShatterGem, for iOS and Android. If you'd like, try it for free!
Android Play Store https://play.google.com/store/apps/details?id=com.chansu.shattergem
iOS App Store https://itunes.apple.com/us/app/shattergem/id1302936106?mt=8

Another delivery post-mortem discussion! It has been a while, but along the way I've delivered on #1GAM (One Game a Month) ... approximately. The average number of game jam and other games completed is abotu 1.1 games/month which I am quite proud of. Please look forward to the full list of games (some of which are just WIP) for the year-end post to come.

Hope you had a great and Happy Halloween, and soon to come Thanksgiving! This post talks about the recent resurgence of Retro games, many of which have a unique twist, as well as my experience releasing for mobile cross-platform using Unity (android and ios)... here we go.

Recently I've completed ShatterGem during the month of October. The idea hit me while playing many games with a retro feel... so first let's describe what that means at a high level. When I mention "retro" these things come to mind

• Single or dual mechanic reliant gameplay
• modular gameplay - the above mechanic driven game put under conditions (time attack, high score, etc)
• arcade feel (e.g. single life, primarily score based, milestones)
• art and design reminiscent of the late 80s and early 90s

If you are familiar with game development and programming, the concept of a Game Design Document (GDD) should not be unfamiliar to you. The GDD's main purpose is to provide a full-scale description and specifications for a game concept or idea. This kind of document or something like it is crucial for the planning and design phase of game development. Without it, there is no way to solidify a concept and take it from conception to completion.

But it tends to happen that the GDD is written once, abandoned and other documents are used in its stead. I've been a part of teams where a GDD is devised, "completed", and then a similar document with more technical specs is built in its place. It is the recommended practice to keep a GDD as the living document of the project, but this tends to be the case less and less.

And I understand that it's hard, at the conceptual phase to build structure, content and features that make sense for the scope of the game. But just because the GDD is the starting point of most games does not mean it is a stepping stone! It is my belief that the initial GDD should be the system of record, or the most up-to-date source of information regarding a project.

Here is a copy of a GDD provided on google drive. You will find that only around half of the document surrounds gameplay (Sections 1, 2, 4, 6, 7). The rest involve UI, technical specifications, art, content and GTM plan. This document is more than just a starting point, it's main purpose is to take you through the pipeline to near completion. Surely other documents will come into play, but to recreate what is already encapulated in this document would otherwise be a waste of time.

I do not think I can do this concept more justice than is done here on Gamasutra, a post called "The Anatomy of a Design Document" by Tim Ryan. The document serves a multitude of purposes none of which is more important than the other. Some examples being:

• Elimininating the hype* - setting a clear scope and direction for the grandiose ideas
• Detailing things clearly* - making what seems abstract in concept more clear from a development standpoint
• Testing against a rubric - what caused this game's conception?