Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Vicious Cycle Software's Dead Head Fred
View All     RSS
July 24, 2014
arrowPress Releases
July 24, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Postmortem: Vicious Cycle Software's Dead Head Fred

November 8, 2007 Article Start Previous Page 4 of 5 Next
 

What Went Wrong?

1. The scope was too big.

When you’re working on your first original IP, you naturally want to make the game as grand and robust as possible. Of course, that leads to the possibility of biting off more than you can chew. Or at least more than you can comfortably chew.

Dead Head Fred is the biggest game that we’ve ever made at VCS. If you complete all of the side-missions and mini-games, you’re looking at a whopping 30-40 hours of game play! You don’t get that on most next-gen games, much less handheld titles.

The game mechanics also increased the scope of development exponentially. We ended up including nine different heads in the game, each of which has its own unique properties. Because you can use any head that you have available at any time, the entire game from start to finish had to be balanced for play with every head. (This diversity also increased the workload for the art department. Every head makes Fred move and act differently, so separate animations had to be created for each. For all intents and purposes, the game essentially has nine separate player characters!)

All of these factors tend to pile up, and it became a lot for a single designer to manage. Luckily, we were able to utilize our other in-house designers to help ease our lead designer’s workload (see 3, below).

2. An ever-evolving design; the mechanics weren’t nailed down early enough.

Despite the fact that the primary game mechanic -- collecting heads and using them in different ways -- was in place before we even started development, there were a lot of changes made along the way. Some of these were a result of the large scope of the game. We ended up having to cut some of the mini-games that we had originally planned, to save development time. Unfortunately, the decision to do so was not made early in the development process, so some development time was lost to sections of the game that were ultimately cut.

Similar problems affected the VO scripts, although to a lesser extent. When sections of the game were cut or changed, story-critical dialog often had to be rewritten to reflect the changes in gameplay. This impacted not only scriptwriting time, but animation time as well.

As mentioned earlier, there were also a number of re-design passes based on the results of our focus groups. Although focus groups are definitely a vital and positive part of the development process, the flaws in gameplay that they reveal need to be addressed -- and this takes time. In some cases, core game play mechanics needed to be changed, and doing that creates a ripple effect that can affect every part of the team, from the artists who have to make new combat animations, to level designers who have to change sections of their levels to accommodate new gameplay mechanics.

Although all of the changes we made along the way made for a better final product, the ever-changing design definitely added to development time and made it more difficult to balance the gameplay experience.

3. Not having a full time designer.

Adam Cogan was one of the founding members of Vicious Cycle, and helped the company launch its first product in Robotech: Battlecry. We knew that we wanted a proven, talented designer to work on Dead Head Fred, but Adam had left Vicious Cycle to pursue his own creative interests in other media. We knew that Adam was our guy, however, so we convinced him to come back to the company to work with us to create this original universe. Due to Adam’s commitments, we worked out an arrangement that we hoped would give him enough time on the project while allowing him to continue his other work. The end result was an arrangement in which Adam would be here for a portion of every week.

At the beginning of the project this situation worked fairly well. As the game progressed, the time that Adam wasn’t at the office became a bigger and bigger issue. This is through no fault of his own, as Adam was very dedicated to the game and made himself available as much as possible. A problem of dependency evolved from the fact that the Lead Designer was not in the office for one fifth of the development cycle. There are only two choices available if you want to make a decision when your designer isn’t there: make a decision without him, or put the issue on hold.

We found that when we put issues on hold they stacked up too quickly and began to impact progress on the game. On the other hand, making a decision without your Lead Designer present introduces confusion for the development staff. To mitigate these issues we used the help of our other designers here at VCS -- Jim Richardson, Dave Ellis, and Jeff Friedlander. They helped to take on some of the large design tasks, like mini-games, the voiceover scripts, and the boss fights (respectively). They also helped to make decisions when Adam wasn’t in the office. Toward the end of the project, design decisions shifted to the project lead group and this helped tremendously. If we were to roll back the clock, we would probably make the same decision because we wanted Adam on the project, but on future projects we will avoid this type of situation.

 


Article Start Previous Page 4 of 5 Next

Related Jobs

Disruptive Games
Disruptive Games — Berkeley, California, United States
[07.23.14]

Disruptive Programmer
Disney Consumer Products
Disney Consumer Products — Glendale, California, United States
[07.23.14]

Contract Game Programmer
Zindagi Games
Zindagi Games — Camarillo, California, United States
[07.23.14]

Software Engineer
Telltale Games
Telltale Games — San Rafael, California, United States
[07.23.14]

Core Technology – Client Network Engineer






Comments



none
 
Comment: