My Message close
GAME JOBS
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
May 24, 2013
 
DoubleDown Interactive
Software Game Developer
 
Autodesk, Inc
Senior Principal Engineer - 2D Engine
 
Kabam
Backend Game Engineer
 
Gameloft
Senior Programmer
 
LeapFrog
Game Designer
 
YAGER Development
Senior Game Systems Designer (f/m)
spacer
Blogs

  Fat Ninja - Postmortem
by Trevor Hilz on 12/07/12 01:11:00 pm
1 comments Share on Twitter Share on Facebook RSS
 
 
The following blog was, unless otherwise noted, independently written by a member of Gamasutra's game development community. The thoughts and opinions expressed here are not necessarily those of Gamasutra or its parent company.

Want to write your own blog post on Gamasutra? It's easy! Click here to get started. Your post could be featured on Gamasutra's home page, right alongside our award-winning articles and news stories.
 

Fat Ninja Postmortem

 Fat Ninja Image

 

Fat Ninja is a game where players take control of Wei, an incredibly obese ninja who must grapple and hide from his enemies while in search for the stolen pieces of his father’s Legendary Gear; careful not only of the mysterious Suit Men, but also of his own hunger. The development took seven weeks, a total of 333 man-hours. The development team consisted of one programmer, one artist, two level designers, and me, the assistant producer. This was the team’s first development and they did a lot of things right, several problems arose, but most importantly the team learned a great deal to take with them in future developments. This is the postmortem of Fat Ninja

What Went Right:

Scrum 

During the development of a game, organizational management cannot be underestimated. Adherence to this policy was incredibly important for keeping track of tasks and giving the team proper perspective of the current game’s development during the sprint.

Communication 

Communication between team members was crucial to Fat Ninja’s development. Ensuring team members communicated what they were doing and what they needed was important. This was further amplified by the use of daily scrums.


 

Team Dynamic 

Making a game takes a lot of time to develop and even more time to make it well. During development, stress builds and tensions run high, maintaining a good team dynamic was prevalent for the team. Bringing in food, telling jokes and keeping the fun atmosphere helped alleviate tension and relieve stress of meeting milestone deadlines.

 

What Went Wrong:

Obscure path designs

The level design team developed the game with the best of intentions, but unfortunately could not communicate to the player exactly what the player needed to do in the levels. Though this was the team’s first development, more attention communicating level design was the team’s priority but they were unable to implement new designs due to engine limitations.

Not adhering to asset locks

Not adhering to the asset locks really limited the team’s ability to playtest a lot before milestone deadlines. The team realized this problem later in development and made attempts to rectify this situation. In the end they feel adhering to these locks will provide better quality in the game in the future.

Lack of playtesting

Playtesting with the team and with Kleenex testers was really lacking through the development of Fat Ninja. The team put other assignments in priority and thus playtesting was cut as per usual in game development. The team realized this issue that if they playtested more, developers would have found more issues and ways to communicate. In the end, the game would have communicated much better with more playtesting.

Inattention to details

In the beginning of development, the team figured out what mechanics they wanted to use, the setting they wanted to be in, and the art style. Unfortunately, much of the mechanic development ended there. No fine-tune details were formed about how the player will use the grapple ability, the team just figured it out as development continued which slowed progress and created conflicts that could have been avoided.

 


 

What We Learned:

Do not underestimate audio

A large goal for the level designers was to have great audio throughout the game, including voice-overs for the main character and enemies. This proved much more difficult and time consuming than the team previously aniticipated. Due to this, the team ended up cutting voice-overs nearly entirely in the Alpha milestone, after the team spent time developing them slowing progress. The team learned to develop audio quickly, efficiently, and not to underestimate the time it takes to create good audio.

Communicating story is difficult

The team really wanted to tell a cool story for the player to learn, understand, and feel emotionally attached to, this proved very difficult. Developing the story is mildly easy, developing a great story that players can relate to and invest themselves in, is a challenge. With such a short development schedule, this was nearly impossible already, and forced the team to tell a short concentrated version of what they really wanted.

Lack of communication between designers

The level designers goal was to create two levels that offered different styles of play to keep the game fresh during play. This was a good goal but the deviation between each other was so large that players felt out of place and not sure what to do. The level designers realized they need to communicate between each other more often to ensure the levels feel cohesive.

 

Overall, the team had a great time developing Fat Ninja and learned a lot of great things about the video game development process and cannot wait to start preproduction of their next game.

 
 
Comments

Elizabeth Stringer
profile image
Interesting lessons.


none
 
Comment:
 




 
UBM Tech