Unsung Post-Mortem

Unsung is a turn-based stealth game where the player must navigate the level without being seen by the Hero or Enemies or tripping any of the alarms within the scene in order for the player to acquire enough motivation to perform a complete musical piece at the end of the game.  It’s development involved overcoming various challenges, some foreseen, some not and it is intended that this post-mortem will improve my abilities for future projects.

Screenshot 2015-03-30 16.33.07

What Went Right?

   Documentation – Right out of the gate Unsung’s documentation was great.  We didn’t even think about beginning the project until all the documentation was finished and finalized.  This allowed us to focus our efforts more directly in development and assisted with the scheduling process.  This also played a part when we had cross-disciplinary’s join our group from the audio and animation department.  The documentation enabled the new comers to quickly understand what look and feel Unsung was trying to achieve providing a dialogue that we could all communicate with so that we could get on with the job more efficiently.  Throughout the development process documentation was updated with any major changes minimizing confusion and wastage.  Despite achieving a high level of competency with documentation I feel that it would be improved with art and diagrams adding a visual communication not present in its current form.  Future practice should require all documentation to be finalized and approved before commencing development including visual aids to better communicate ideas and design.

Screenshot 2015-03-30 16.34.04

What Went Wrong?

Vertical Slice –  Despite a great vision for the game it turned out to be overly ambitious.  Our scope far exceeded what we could achieve within the allotted time and as it turned out also took away from the core experience of the game which was “Sneaking”.  Our attempt of including numerous mechanics not only lowered the quality of each mechanic as we could not properly test and tune its respective gameplay experience but also prevented the project from being fully completed with some mechanics being left broken and others left half completed.  Another issue I recognized was that being overscoped made it more difficult to realize or address the real problems with the game.  When a mechanic wasn’t achieving its intended effect rather than scraping the mechanic and fine tuning existing mechanics until it could be looked at later, it was instead tweaked or retro-fitted until it partially achieved the goal, leading to lowered quality in the gameplay experience.  I believe the problem this project suffered was an inability to accurately recognize what the core experience of the game should be from the very beginning and therefore design for it.   It’s not always straight forward to be able to accurately recognize what can be achieved from the outset when beginning a creative project, because generally it’s always about pushing abilities and design further.  Therefore project planning should always adapt when vertical slice is identified and not be afraid to immediately cut mechanics in order to focus and better implement others.

Member Investment – This is a trickle down effect from vertical slice that created separation between some of the team member’s.  To make it clear there were no internal disputes, grudges or anything like that so don’t misunderstand me it was simply a case of everyone had a specific job to do so we went to our corners and did that by ourselves instead of being a team.  To compound this problem there were elements of the project that were simply beyond the abilities of some of the team members mainly in regards to scripting which further dismantled the team dynamic.  Because of this, communication and feedback suffered which otherwise could have potentially improved the game significantly.  A way to improve this for the future would be to hold more regular meetings to ensure the project is on track and all team members can voice their concerns or clarify any issues.  In relation to this everyone should be open to alternative ideas and criticism so that the best practice or idea can be entertained.

Repository – There’s not much to say with this one as it’s pretty clear-cut.  The problem wasn’t with the software itself but our competence with the software.  Because we didn’t set the project up properly at the start we unknowingly allowed gremlins to sneak in that became a problem mainly towards the end of the project.  As a result of this all team members at some point lost valuable work time due to failed or corrupted syncs and had to redo all the work plus the remainder to finish.  Members simultaneously working on the project at the same time also led to problems happening from time to time.  Project scheduling should always allow for unforeseen problems arising but the end of our project saw close to 40 hours having to be redone.  To minimize this risk, it’s important to understand your repository software before commencing any project work and allow for potential issues to arise.

Unfortunately Unsung was not completed to its full vision making it my first game ever to not meet its deadline in full which is a bit of a deflating experience.  But despite this, the reasons for its failure are obvious and easy to avoid in the future.  My initiation on the art side of game development taught me many things, not just about development but also about myself and even though Unsung wasn’t fully completed it has been the most educational experience in-game development for me thus far.


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