Year of Hue Postmortem

Year of Hue Postmortem

By Jason Paytes

Year of Hue

Year of Hue is a 2D platforming puzzle game designed in the Torque engine by a team of four student developers at the Guildhall at SMU.  Development time took a total of ten weeks, with 48 person-hours per week.  Year of Hue was created for the Xbox 360 console, but runs on both the Xbox 360 and PC platforms.

In this postmortem, I will discuss what went well and what went wrong in relation to the 36 classic mistakes in software development according to Steve McConnell’s Rapid Development: Taming Wild Software Schedules.

What Went Well

 1. Avoiding Classic Mistake #1: Undermined Motivation

One thing in particular that stuck out in the development of Year of Hue was the high level of team motivation and positive work environment.  Each team member had a high degree of respect for one another.  No matter what each person had to say, it was important enough to listen.  Open communication was never discouraged and ideas were free to bring to the table.  Everyone on the team was encouraged to share their thoughts and because of this, we had a wide variety of ideas to sift through to find the best ones for our game.  This particular factor kept the team motivated and committed to the project.

 This quality of communication created an environment where all different types of people were able to express themselves without risk of becoming ostracized or rejected.  Allowing team members to explore their own thoughts and ideas, in their own unique manner, brought many different elements to the team.  Because each of the developers had differing game design styles, this situation could have easily gone the opposite direction.

Year of Hue Screenshot

2. Avoiding Classic Mistake #11: Lack of User Input

At the end of each milestone, our team had a number of Kleenex testers for play testing and providing feedback.  This provided our team with constant user input and the capability of adjusting the game design to improve experience for players.  Without continuous user input throughout the project, we would have spent a lengthier amount of time resolving issues in the later stages of development, where it is most expensive.

What we found throughout many of our tests was that the game was very hard for those outside of the team.  The intention was to create a relaxing experience but we soon learned that is was too challenging, and caused frustration for our players.  From this point, we were able to adjust the game design and learn what players found to be fun about the game.  Once we knew what made our game fun, we were able to exploit that and add a more rewarding experience for players.

3. Avoiding Classic Mistake #29: Feature Creep

From the start of the game, the team understood that we were designing to schedule.  With a restriction to schedule, they knew that managing requirements and features was going to play a major role in developing the game.  Each time someone mentioned the possibility of adding new items that were not necessary for gameplay, there was another person to call them out on it.  We always pointed out feature creep in a well-intentioned manner but the reason behind doing it is critical.

Year of Hue Concept Art

What Went Wrong

 4. Encountering Classic Mistake #22: Shortchanged Quality Assurance

One particular thing that did not go well was following through on sprint reviews.  There was a lack in monitoring the status of action items from each sprint review.  This was primarily due to rushing into development tasks already laid out for the next milestone.  Due to this, many action items from previous sprint reviews would show up once again in later milestones.  Attacking issues later in the project increases the impact of those issues on the schedule.

5. Encountering Classic Mistake #25: Omitting Necessary Tasks from Estimates

Involuntarily omitting necessary tasks from estimates is something that many developers face.  Often management and review tasks are missing from estimates since they do not directly relate toward actual creation of game assets.  Our team was no exception and because of this, we had to make feature cuts during our vertical slice milestone.

We had originally planned to add more alternative jumping platforms for the player to interact.  Tasks not originally taken into account or shorthanded were documentation, internal testing, and sprint and design reviews.  These items cut into our time for development and as a result, cutting features was necessary.  One positive factor for this is that we had a plan what features to cut from the very beginning of the project so that the overall gameplay would not suffer.

Conclusion

By carefully monitoring tasks and schedule, the team was able to deliver a full demo product within schedule with only minor cuts.  We worked to create a friendly and productive atmosphere, focusing on good communication skills.  Without this communication, meeting requirements for each milestone would have been difficult, especially since we shortchanged some management tasks in our schedule. 

Through the development process, we learned the importance of making time to incorporate feedback from sprint reviews.  We also discovered the significant effect that omitting important administration tasks has on the production schedule.  With the knowledge gained from the production of Year of Hue, the entire team learned valuable skills that will carry them forward as game developers.  Despite the setbacks of the project, each team member remained respectful and courteous towards their teammates and strove to maintain the positive work environment. Overall, the development process for Year of Hue was a pleasant experience and each team member made lasting relationships that will persist long past our days at the Guildhall.

Development Team

Jason Paytes – Assistant Producer

Jarrett Hugg – Level Designer

Sharla Colvin – Programmer

Ashleigh Mills – Artist

ashleighmills.com - Special thanks to Ashleigh for providing artwork for this article