Sponsored By

Postmortem: Cyborg Ninjas On Fire 2: Reloaded

Postmortem for Cyborg Ninjas on Fire 2: Reloaded, a UDK mod created at Guildhall SMU program. This post explains what went wrong/right in relation to Steve McConnell's Rapid Development: Taming Wild Software Schedules.

Navin Supphapholsiri, Blogger

September 18, 2012

3 Min Read
Game Developer logo in a gray background | Game Developer

CNOF2R Poster
Cyborg Ninjas on Fire 2: Reloaded (CNOF2R) is a fast-paced, over-the-top, first person-shooter mod for UDK. The players take on the role of futuristic cyborg ninjas fighting over control of a legendary suit of armor called the Yoroi. The total development time for CNOF2R was ten weeks (thirty person-hours per week), and was developed for both the Xbox 360 and PC platforms. This postmortem analyzes the obstacles and challengers our team encountered during the production phase.

What Went Well

1.) Functional Working Environment

At our workplace, other development teams have already occupied all of the breakout rooms in the building. Fortunately, we found a small pit area downstairs and decided to make it our group’s working space. We had all seven of us sitting merely a few feet away from each other, which made comments and critiques communicated easier. This process drew us closer together creating a work culture that was very enjoyable to work in.

2.) Motivation

From the beginning of the preproduction phase, the one thing that remained constant throughout the whole development cycle was the high level of morale. Every member of the team had a huge buy-in for the game which created a positive working environment with highly motivated developers. This environment encouraged all team members to bring up their thoughts, ideas, and opinions regarding the game.
 

What Went Wrong

1.) Lack of user input

One particular thing that didn’t go as well was the lack of play testing during each sprint. This was primarily due to the time constraint given for the whole project. The amount of content that was created during each milestone created almost no opportunity for play-testing. As a result of this, we had to spend valuable time during the later stages of development to resolve issues that we had.

2.) Omitting Necessary Tasks from Estimates

This classic mistake has happened to me on every game development project. Management, research, technical, or unrelated development tasks were unaccounted for during each sprint. These tasks are as simple as having short one hour meetings to importing assets into the engine. The process of getting an asset to look the way it should in the engine consumes enough time for it to go up on the backlogs. These additional tasks pushed back initial tasks, forcing us to cut certain aesthetic features initially planned for the game.

3.) Feature Creep

As we progressed through each milestone, the team became more and more excited about the game we were creating. Mid-project changes started to occur because the team obtained a better understanding of the game created. The team went through about a 40% feature change in ten week period during the production phase.

It seemed like a great idea at the time because the majority of the team had buy-in for the game. However, towards the final phases of development, many of the developers had to pull several heroics to reach sprint goals.

Conclusion
 

Overall, CNOF2R was a fun and great learning experience for the team. This opportunity has given the team valuable learning lessons in game development, and we will carry these lessons forward throughout all of our development careers. Overall, we felt that by creating a positive working environment accompanied by highly motivated developers, we were able to create a game that our team was extremely proud of.

Development Team

Alejandro Daza

Mike Direnzo

Sara Fillman

Elizabeth Labelle

Ravish Nair

Navin Supphapholsiri

Matthew Wingler

Game Download

Read more about:

Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like