Post-mortem of a Casual Game

My last post dealt with the issues involved in creating a sequel. The project I was working on was a casual game targeted for both retail and downloadable sales. Although the development time for such games is much shorter that that of AAA titles, the process involved is very similar.

As promised in my last installment, this post will focus on some of the things that hindered the development of my last project. If you have read post-mortems of any games, you will recognize many of these problems since then tend to recur in project after project. You know the saying..."The best laid plans of mice and men..."

So, here goes:

Staffing Issues

The game industry is always a roller-coaster ride when it comes to staffing. There are many factors that can affect staffing including layoffs and reassignment to other projects. Midway through my project, the production team was cut in half. Unfortunately, the deadline for the project could not be moved, so this meant that those who were left on the team were going to have a lot of work ahead of them.

Scheduling Issues

The initial schedule was created by one producer, and then assigned to another. Since different people have different methods, this resulted in the entire project schedule being re-written midway through the project. It was several weeks before we even knew where we stood and what it was going to take to complete the project on schedule.

Design Bottleneck

Unfortunately, the same cutbacks that affected the production team also affected the design team. There was now only one designer, and he was up to his neck working on other projects. Many design decisions were made by the development team, only to be later overridden by the designer when he finally had time to focus on our project. This resulted was time spent on work that either had to be re-done or never even ended up in the game.

Feature Creep

In light of the above problems, it seems like the obvious choice would be to cut features. Alas! Instead, features were added. It was felt that these features were critical in giving the game an edge in a very competitive market. This insured even more overtime for an already taxed development team.

Unmovable Deadline

Like many games, this project was slated for Christmas release. The need to get the product out for the Christmas season was critical, so this deadline could not be changed. To make matters worse, one of the distributers decided they needed the game 2 weeks ahead of our original schedule, effectively cutting two full weeks off of an already tight schedule.

Lack of QA

The QA department had minimal staffing due to the above mentioned cutbacks. This meant that everyone at the company became QA. Although we all did a heroic job, there simply was not enough time and resources to properly test every aspect of the game.

The End Result

No game goes out the door without any bugs. My last project was no exception. We knew we were releasing a product that would have problems, but at the end of the day we all knew that we had done the best possible job we could do under the circumstances. Luckily, there was time after the release to continue fixing bugs and patches were released. However, no one likes to buy a game with obvious bugs, and this definitely did not look good on the company. Regardless of the problems, I was proud to be a part of this project. I can honestly say that everyone involved gave 200%. We were amazed that we could complete the project as well as we did, given all of the difficulties we had.

Next post: Fear, trembling, and harsh reality.