WHAT WENT RIGHT
-
Team Management and Multitasking. When we set out to make Damnation, the team could be counted on one hand and, in fact, all sat in one room. By the time the Phase 4 submission date rolled around, the mod team consisted of more than 20 people around the globe. What was really great was that, as the gradual transition was made from web design to game development, our team was flexible enough to allocate the necessary resources to the places they were needed most.
Of those initial 4 guys, 2 soon found that they were reviewing assets and implementing design full-time. Multi-tasking became key. I have often seen discussions of whether team members should have specialized skills or whether it is better to employ people who can “wear many hats.” Our team was a veritable haberdashery and we couldn’t have accomplished our goals otherwise. Certainly we had people whose only jobs were modeling or programming, but we also had a modeler who got called away to do level design and even scripting. At least one core member ended up doing game design, texturing, modeling, scripting, level design, and even management at the same time.
On a project as complex in design and as sweeping in scope as Damnation, management and proper allocation of resources was absolutely key. We put in place review sessions almost from the very start and wrote up design docs as we went along. As the project slowly became an all-consuming juggernaut with everything from 3rd-person navigational abilities to extensive cinematics, we were able to scale production relatively smoothly. Because members of the core team had so many different skills, we were able to allocate resources where they were necessary, when they were necessary, without first having to find new people to bring into the team. While the core members were filling the gaps, we were then able to recruit more people from the mod community and elsewhere to take over those positions and free up the core members until another gap needed to be filled. This turned out to be absolutely invaluable for structuring development of the final game in respect to outsourcing. Because we had such a flexible and organic mod development process, we now know exactly where out-of-house production can be utilized efficiently and what must remain in-house.
-
Shared Vision. Damnation is a very unique game. When we came up with the concept for it back in December of 2003, nothing like it had ever been done before. Since then there have been several games which bear some similarities to it, but Damnation’s balance of puzzle-solving, platforming, FPS combat, and Spirit Powers, not to mention its reimagining of the Western genre, remains extremely unique. It was very important for the team that the vision of this game and its world remain strong and consistent. The way we accomplished this was twofold:
First, we all answered to one conceptual designer. Everything went through him, the “Keeper of the Vision” as I have heard some designers refer to the position. The core group began to understand the vision as the project went on, and, as a result, some of the burden of keeping the vision consistent fell to them. The key though is that visually and conceptually, everything comes from, and goes through, one person.
Second, we invested an extreme amount of time and resources into concept art. We had more concept art for our mod than many studios have for a full game. This ensured that everyone on the team, from level designers to modelers, had a strong understanding of the visual feel of the game. Whenever there was a question like, “Would something with so many smooth contours exist in our world?” all one had to do was refer to the library of concept art.
-
Programmers. We were extremely lucky to find talented programmers who were capable of thinking “outside the box.” That was actually one of our criteria for bringing them into the team. We gave everyone a set of short tests to see if they could think of ways to implement certain effects that couldn’t easily be made to work via UnrealScript.
The hardest test was as follows: “Make an effect that blurs the screen and creates light-trails.” Motion blur is very easy to implement through UnrealScript, but there is no way to implement light trails, i.e. selective blurring, in a conventional manner. The most clever response to this test was to spawn particle emitters at every light source and then to vary their direction and velocity in amounts inversely proportional and proportional to the movement of the camera respectively.
We knew that we were going to be asking our programmers to jump through some insane hoops with what we wanted to be able to accomplish in Damnation. UnrealScript is a powerful tool, but it still forces you to work within the framework of the Unreal native code. Considering how much we were changing about the game, we knew we needed people who could come up with clever solutions to complex problems. As I said, we were extremely lucky to find the people that we did.
-
Wiki. Keeping track of bugs, level geometry and collision holes, and even new features was originally handled via email. By around the middle of the project, this system proved not to be viable. There was no way to check if a bug had already been reported, whether a programmer thought it had been fixed, or even who was supposed to fix it. In response to this, we quickly set up a wiki for bug and feature tracking.
The wiki was set up to allow any member of the team to report a bug or feature request and not only tag its priority but also assign it to the person or group they felt should be looking into it. Anyone within a given group (animators, programmers, level designers, etc) got email notifications when something was assigned to them or to their group and from there they could figure out who specifically should deal with each item. Everything from critical errors to feature requests went into it. By the end of the project, bugs were being fixed quickly and smoothly because everyone knew exactly what the status of each one was and to whom they were assigned.
-
Quality Over Quantity. The original vision for the Damnation mod called for the player to enter the prison, fight Barboza, meet Professor Babbage, blow up the cisterns ringing the Prison Quarry, and escape into the sewers below as the water from the cisterns flooded the Prison. It even included friendly NPCs as well as multiplayer and co-op functionality. Needless to say, many of these features were cut as production progressed.
Our philosophy is to shoot for the stars with our initial design. Then, we cut back as necessary. Fun and quality is the primary goal. If an extra feature is going to get in the way of that goal, it gets cut. In respect to Damnation, we were still planning to enter the Prison as late in development as just after our Phase 4 submission. We sat down after that deadline and talked about all the stuff we still wanted to put into the game. After a lot of discussion, we finally came to the decision to cut the whole prison sequence, which was already in production. We felt that it would be better to have a 2-hour-long demo that played well rather than a 3+ hour buggy piece of crap. We turned our attention to adding new abilities and building out areas to use them. We revamped the AI and re-balanced the combat. We extended our cinematics and added more sound, and we plugged tons of holes in level design.
One week before the Grand Finals submission we still had a complex scripted scene at the far end of the Prison Wall where a bunch of guards and Automen would be shooting at prisoners escaping the Quarry and then the Automen would turn on them. The scripts kept breaking though. Either the Automen wouldn’t kill the guards, or they would get stuck in corners, or who knows what else. It was a real wrench to trash it at the last minute, but we decided that it was more important for the player to be able to get through the area and not worry about bugs than for them to watch a neat cinematic. All this cutting paid off, as our Grand Finals submission was WAY more fun and polished than our Phase 4 entry. There is no question that this jump in quality is largely due to our willingness to make painful cuts when necessary.
Next: What Went Wrong...