Vigilance Post Mortem

This post-mortem will be a reflection on my development of Vigilance, what went wrong, what went right and how to further my development skills for my next project.  Vigilance is a Sci-Fi, Top Down Goalkeeper game where the player must balance out power resources of a spaceships defense grid in order to destroy asteroids before they collide with the ship.  This was the first complete game I have ever developed that included a core loop which provided many challenges and insights that would further my skillset as a game developer.

What Went Right?

Vertical Slice – I had a deadline of one week to design, build and finish Vigilance which didn’t leave much room for error.  Knowing this, one of the first checklists I did involved all the ideas I had that I knew would make up the core loop of the game and were mandatory.  The remaining ideas went to the ‘Desirables’ list and I deliberately ceased to acknowledge their existence until all the mandatory features were implemented and working.  This allowed me to focus on the core loop of the game and develop it as best as possible whilst also providing more room for movement in project scheduling.  By implementing a checklist  of mandatory or ‘In Scope’ features I was able to inject more quality into the project whilst also minimizing stress and short-cuts due to feature creep effecting the deadline.

Scheduling –  Being such a short deadline given my experience in game projects, I knew scheduling would play a vital part in seeing the project through to completion.  Once I established the mandatory features of the game, I created a Gantt Chart that displayed a visual representation of my week.  I then compartmentalized a list of prioritized jobs on each day detailing the Critical Path.  This part was very important as it gave me insight on whether the project was on schedule or falling behind on a day to day basis.   By scheduling the project not only did it keep me on track but it also provided me with extra time as the last day of the project ended up taking much longer than anticipated.  The last day of the build was implementing final audio assets and then play testing the game to improve balance and overall game-play.  I deliberately scheduled extra time for balancing as i had never done it before therefore didn’t know what to expect.  Balancing ended up taking over double the time i had originally thought and was only finished due to the scheduling process.  This process is absolutely vital for any project as not only was it easy to use and understand but gave very clear indicators as to the projects progress.  My advice for future projects is to take into account skills and abilities of all developers involved, because only by scheduling extra time due to my lack of experience was i able to attain the quality out of my project that i did.

What Went Wrong?

Personal Skills – Ofcourse most developers will say I wish I knew how to do ‘this’ as I would’ve been able to do ‘this’ so much better and for the most part these skills will come with time and experience.  But given that the deadline was so short a minor mistake I made was having the core experience of my game essentially revolve around features i was unfamiliar with.  Whilst all projects should push the boundaries of ability and innovation as much as possible, doing so on such a short deadline and also on core features, not so much.  Due to my in-experience with non-linear equations i was unable to implement my resource based core mechanics effectively.  This then led to the ‘Indicative Experience’ of my game suffering.  I would highly recommend that for projects on a shorter deadline to scope core features respective of abilities and skills of the developers.

Documentation – Whilst this was only a small one week project, my underestimation of an informative high concept document(HCD) inevitably came back to haunt me.  Even though I did have a HCD, my haste in writing it came at a cost of specific information that ultimately led to its abandonment.  At no point throughout Vigilance’s development did i come back to the HCD, either the information wasn’t in-depth enough or wasn’t there entirely leading me to develop the game out of my own head.  This caused inefficiencies in development time and became a barrier to creating a better experience for the user.  Fortunately, this particular project only required one individual to develop but in a larger game this would undoubtedly sink the project.  Underestimating the power of documentation is unwise and should always be a priority when beginning a project and to add to this, any confusion in regards to project documentation should always be addressed immediately.

Despite in-experience posing a significant challenge, development on Vigilance was completed and on time delivering an indicative experience whilst adhering to the projects brief.  Even though the project wasn’t large, the deadline posed obstacles that I hadn’t experienced before and provided invaluable experience and lessons that I can take with me to my next big idea.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s