Author: by Dave Ellis

Originally, Vicious Cycle's PSP-exclusive action title Dead Head Fred was intended to be a GameCube title for a younger audience. Yes, that’s definitely quite a one-eighty. But when the concept first took shape, the idea was to make a game with a light Rayman-esque feel to it -- colorful and fun. The player would have guided a character called Geo around the world of Prime in search of four different heads, each of which had unique powers.

While gathering these heads, he would also be stopping his world’s nemesis from destroying his home. The four heads were basic geometric objects (a cube, a sphere, a pyramid and a cylinder). The cube made Geo heavy and slow, and acted as a weight in certain puzzles. The sphere rolled like a marble and traveled fast. The pyramid moved like a tornado on its point and allowed Geo to maneuver along high wires.

Finally, the cylinder had a spring/rubber-like quality, and allowed Geo to bounce to higher areas on the map. Although teaching geometric concepts was never the intention of the game, most publishers who read the concept got that impression.

They said, “this is too edutainment”. (There's a word you probably haven’t heard in a while.) The upside was that they all really liked the mechanic behind the concept. So we went back to the drawing board to make the game appealing to an older audience.

We started by changing the tone of the story to something a bit darker and off-the-wall. We maintained the mechanic of head-gathering and -switching, but set the game in twisted version a '40s film noir detective film. Despite the rather dark story and characters and the premise of ripping off heads, the original pre-production visuals that came back from our contract artists were still playful and cartoony. We didn’t feel this was too much of a problem -- we aren’t the targeted demographic.

The initial test groups thought that the look still skewed too young. Also, apparently the youth today want guns, guns, guns. One of the most common questions asked at those focus groups were, “Where are the guns?” “When do I get to pick up a weapon?” Ah... game development in the post-GTA world...

So, after further testing, we came back to the drawing board yet again (literally this time) and created an art style with the cool cats at Massive Black. (Those guys rock, by the way.) The new look was much darker—like “40s gumshoe meets Dirty Harry meets The Matrix.” Apparently, what the players these days want is a badass character that looks pissed off and unique. Fred turned out to be just that. A brain in a jar filled with liquid where his noggin’ used to be. A detective with a sarcastic edge and vengeance on his mind.

Anyway, that’s how it all came together. We got a publisher for the title, we took our robust technology and got it running on the PSP as fast as lightning, and we dove head first into creating our first original intellectual property from the ground up. Little did we know what challenges were awaiting us, what stumbling blocks we would encounter, and the sheer amount of work we’d have to endure. As with any project, there were good times and bad times. Let’s start with the good.

What went right?

1. Designing and concepting the characters.

As mentioned previously, we got started on the right foot. While the programmers were refining our technology, we began designing the game and concepting the characters. This process took quite a while. For example, it took about four months or so to get all of the Massive Black character concepts exactly the way we wanted them. One of the cornerstones of art direction is knowing what you want. You have to review and critique the art quickly or you will eat through your budget in no time -- especially if you are outsourcing the work. Indecisiveness can ruin you.

The characters went through numerous revisions. This was especially true for Fred, who was the very first concept that we completed. He was the cornerstone of our game, so his look dictated the look of the entire product. Our publisher, D3, suggested that we focus test the main character and see how people liked the design. The first group that looked at the work only had a page of information to go on with regards to the story and eight concept paintings of Fred to examine. This first focus group was made up of people of all ages, and they all said that the look was too young. We took their comments on the concept drawings

We pushed the envelope and went edgier and more mature with the next round. This time, the focus test results were very positive. What we ended up with was a darker Fred, a character that painted with a Norman Rockwell style, but exhibiting a demented film noir look. With the look established, we completed the concept work on the remaining cast of characters in the same vein.

2. Scriptwriting and VO recording.

When creating an entirely new world populated with unique and twisted characters, you have to make sure that everybody “gets” what that world and those people are all about. We set out knowing exactly who Fred Neuman, Ulysses Pitt, and their fellow residents of Hope Falls were, but we realized that in order to convey the characters and settings -- not to mention the twisted humor that was one of the cornerstones of the game -- to the player, we would need cinematics. A lot of cinematics.

While Fred’s lead designer, Adam Cogan, concentrated on the game play, one of our other designers, Dave Ellis, dedicated more than a month to writing the dialog for the cutscenes. Starting with Adam’s character bios and location descriptions in the design document, Dave fleshed out the personalities of Fred and the other characters in the game and presented them in cinematics that would convey all of their quirkiness and give players a glimpse of what life in the twisted noir world of Hope Falls was like. Adam then went through and wrote the in-game dialog for the characters based on the style established in the cut scenes. Both designers then worked with art director Ben Lichius to trim down and edit some of the longer scenes so that the animators had time to finish everything before we went gold.

When everything was down on paper, there ended up being thousands of lines of dialog in the game. This made the VO recording sessions among the most ambitious (and grueling) that we had ever dealt with. Fortunately, we managed to cast some of the best voice talent in the industry. Aside from a glitch with one actor (who shall remain nameless) who walked out on a recording session and set production back several weeks, everyone who had a part in Fred was a consummate professional. We got some great performances from everyone -- especially from our two leading men, John C. McGinley (Fred) and Jon Polito (Pitt).

The hard work and dedication of everyone involved in creating the cutscenes and in-game dialog really shows in the final product.

3. Focus testing the gameplay.

In addition to setting up focus tests for the look of the game, D3 put together two extensive focus groups to test the gameplay. This was an extremely valuable experience, and is something that every development team should do as a standard part of the development process.

One of the first things we learned was that our set of combos for combat was too shallow. Originally, we wanted the gameplay split evenly between combat, adventure, platforming, and puzzles. The focus test showed that we were too light on the action, even though we thought we were providing enough to the player.

With this feedback in hand, we had a mini-design summit focusing on Fred’s attacks. We set out to create a different set of combos for each of the heads. Some combos were strictly offensive, while others were used as counter moves. We wanted a mix of melee attacks and ranged attacks, a variety of special moves, and beheadings and rage attacks. In revisiting the combat design, we nearly tripled the number of available attacks. We also increased the complexity of the combos in the game to appeal to make the combat less simplistic. The focus group also had trouble with the game controls and didn’t always know what they were supposed to do. In response, we added a tutorial in the beginning of the game and planned how we would introduce new mechanics throughout the game. We made it a point to go over the game with a fine-toothed comb, documenting where we introduced a new mechanic and providing the player with an on-screen tutorial and some VO to explain the new mechanics. We also added an on screen graphic that showed the player what head to use in certain situations. Although it always seems to be overkill to tell the player too much, our testing revealed that players needed an extra nudge from time to time.

We cannot overstate the necessity of thorough focus testing. It was an eye opening experience and we will definitely do it again.

4. Getting more development time.

Time... if only we had more time. Isn’t that what we all say? Well, for the first time in many years, we actually got more time. There was a certain point in the project when things just weren’t coming together fast enough, and we needed more time to make the changes suggested by our focus groups.

We went to D3 and asked (very nicely) for them to give us more time to get the game right! It was a new intellectual property, one that we wanted to be successful and one that we eventually wanted to turn into a brand with future games. The choice was to ship it with problems and get poor reviews, or to take the time to make the necessary changes and hopefully get great reviews.

The experience that most teams have had in this industry is, “release the game and take your lumps.” Luckily for us, D3 had the foresight to give us the extra time we needed. We actually had time to fix some of the problems and make the game we really wanted to make! After an additional six or so months, we were able to re-unveil the game -- and, at its second E3 showing, Dead Head Fred received a nomination for Best Handheld Game from the Game Critics Awards: Best of E3 2007.

This acknowledgement from our peers was huge, especially considering the tough competition -- not to mention the fact that Fred was the only new intellectual property in the bunch.

5. Utilizing our technology, the Vicious Engine.

We actively license our game development technology -- the Vicious Engine -- to the games industry. Over the past five years we’ve developed all of our internal products across multiple platforms using the engine. Dead Head Fred allowed us to utilize our technology to make another great game, and it provided us the perfect opportunity to update the technology and further enhance our support for the PSP platform.

The Vicious Engine has turned into a stable environment for making games on current and next-gen consoles, the PSP and the PC. Given its highly data driven architecture, we were able to devote many more team members on the game content development while the engineers continued expanding engine support for the PSP. All game features in Dead Head Fred were implemented through the interface of the Vicious Editor, requiring no game-specific C++ code.

Most of the game-level features required for Fred were already in place, but significant updates had to be made to the low level platform code. We were able to quickly modify the base engine to work well on the PSP. While the PSP is similar to the PS2, it has less memory and is able to handle fewer visuals. However, with time and effort we were able to generate a truly robust and fully optimized implementation of the Vicious Engine on this portable console.

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.

4. Getting used to the differences between the PSP and PS2.

When we first got wind of the upcoming PSP we became incredibly excited. A portable with the power of a PlayStation 2! Our initial assessment wasn’t quite accurate. The PSP is truly a remarkable device, but developing on it does come with a price.

First, never underestimate the value of a second thumbstick. Making 3D games in a third-person environment is very challenging if your ability to control the camera is limited. Many of us in console development don’t realize the effort that is required to implement a truly independent camera that doesn’t frustrate the player. We worked on this camera for months and came up with a system that works. There are definitely some areas that could have been better, but all in all it works quite well.

Another challenge when developing for the PSP is the slower-than-advertised CPU speed. Sony has finally unleashed the full power of the CPU in a recent update, but up until the last week of development on this game we were developing on the slower mode. A device that can render almost as much as a PS2, but doesn’t have the CPU power to back it up, is truly a nightmare. In the end, we were able to optimize the engine to great effect, but there were one or two slow areas we were still concerned about. Luckily the Sony update solved those problems for us! If only we had known about the CPU upgrade sooner, we could have populated the game even more than it is now.

The lack of hardware clipping is another issue that caused us numerous headaches over the course of development. While the PSP can really throw out a lot of polygons, we had to tessellate the world to a higher degree to solve clipping issues. This caused us to have more polygons than typically needed in many simple surfaces like floors and walls. We experimented with some software clipping solutions, but they took up too much processor time. On the plus side, the additional tessellation did help make our environments look great after being processed by our lighting solution.

5. Making the PSP our sole console for the game.

One of the main reasons we decided to make Fred exclusive to the PSP was that we were about to launch ourselves into the middleware market, including support for the PSP. It was also a strategic move to get our company over the hurdle that occurs every five years or so -- the changing console marketplace. For developers, bridging the gap from old consoles to new consoles is a very dangerous time. We thought it would help our company if we focused on the PSP since it was a new platform. We were right. It helped a lot. We promoted the tech at GDC that year and it got a lot of attention. We figured we were making the right choice.

Fred was to be our flagship title for the PSP -- proof of what our engine could do on the platform. This would have made a positive impact on our PSP engine sales if we would have launched Fred in a timely manner. We were supposed to ship the game in early Q1 of 2007, and of course that didn’t happen. (Actually, Fred’s delayed release could help its sales. We now have the potential to sell to the new PSP owners who have bought systems due to the price reduction, and those who are planning to buy the new PSP Slim & Lite.)

We also firmly believed in supporting the PSP market with a new intellectual property. Many of the PSP games on the market were ports from other systems, and they didn’t show off the system to its full potential. If more publishers took a chance early on, then the PSP software lineup would have been deeper and more impactful. Of course, it turned out that PSP didn’t make as big of an impact as everyone had hoped. It’s doing well... but the DS is doing better.

Looking back on it, it probably would have been a good idea to go multi-platform just for more exposure, sales potential and retail penetration. However, we ultimately don’t regret the decision. We have created a great, original game for the PSP and there aren’t too many developers that can say that. And, of course, thanks to our cross-platform technology, with a few months of work, Fred can make the jump to PS2 or even Xbox Live Arcade if D3 decides to go that route.

Conclusion

When all is said and done, our experiences with Fred were all good ones because we can learn from our mistakes and turn them into positives the next time around. There is a lot we can improve on when we start a new intellectual property -- procedures, attention to scope, nailing down the design early, and so on. Fred was a daunting task for us. It was a big game, an ambitious design, a new property and a new platform.

Even when things went wrong, we refused to give up on an idea that we firmly believed in. Game developers don’t get too many opportunities to develop a dream. Dead Head Fred was a blast to make. We just hope everyone enjoys playing it as much as we enjoyed creating it.

Game Stats

Developer: Vicious Cycle Software, Inc.

Publisher: D3Publisher of America

Release Date: August 28, 2007

Development time: 22 months

Number of full time developers at peak: 45

Software Used: Vicious Engine Editor, Photoshop, 3DS Max, Collaborate (internal bug tracking software), Pro Tools, Sound Forge, Infinity, Waves, GRM Tools, TL Space, Premiere, Visual Studio 2005, Perforce, SNSystems ProDG

Technology: Vicious Engine

Lines of code: 300,000 lines of code

Lines of script: 669,837 lines of script