What Went Wrong

  1. Not Enough Playtesting. In order to create all the levels, assets, code, and other elements necessary to bring Damnation to fruition, the whole team was occupied with content creation 100% of the time. Towards the end of the Phase 4 submission, the core team was working 80+ hour weeks to meet the deadline. Features were still being implemented right up to release. As a result, there was no time for playtesting. This was somewhat remedied for the Grand Final release, but there still wasn’t enough time to test. Our AI was only finalized just days before the release of Damnation 2.0. The final product behaves well most of the time, but there are still lingering bugs and holes since playtesting consisted of a few guys at 2:00am running through levels they already knew by heart. We realized that this would be problematic but, considering the features we wanted to implement and the extreme time restrictions, it worked out better than it could have.

  2. Engine Rules. We started designing our levels and gameplay long before we actually started building them. The core team didn’t have any real experience with the Unreal Engine and so we made certain assumptions about its capabilities. We designed huge, expansive levels, assuming that the LOD system would take care of the view distance. We modeled foliage with tons of overlapping alphas. We built huge levels out of Lego-block style instanced geometry, assuming that backfaces would be culled and that it would light correctly even though many edge vertices were embedded in level geometry.

    Ultimately, as any seasoned Unreal vet can tell you, our game ran and looked like crap. The first release of Damnation ran at a speedy 13fps most of the time. The UT2k4 build of the Unreal Engine 2 is heavily optimized for low-detail, wide-open areas with blazing-fast multiplayer gameplay. Limited to UnrealScript, with no access to the source, having limited time, and with our beginners’ knowledge of the engine, we broke almost every rule about building a game in it.

    Had we realized these issues ahead of time, we could have worked around them. The Unreal Engine is the best licensed engine on the market today, especially with UE3 coming out; but with no access to the source code and a poor understanding of the UT2k4 build’s restrictions, we ended up making many costly mistakes. Now that we know all of these issues, we could make a great-looking and fast-running game with UE2 just by making simple pipeline changes. For instance, we could export the Lego-block geometry and build a shell around it, then re-import the low-poly shell and delete the Legos, thus drastically reducing poly and actor count. We simply didn’t have time to make these changes by the time we came up with the solutions.

  3. AI. We knew that AI would be an issue, but we did not anticipate how difficult it would be to get it to do what we wanted. We were making an FPS as a mod for the Unreal Engine. The Unreal Engine already had FPS AI, right? By all accounts, Unreal bot AI is pretty darn good to play against. All we had to do was re-skin the bots and drop them into our game, right? Wrong.

    The instant that we started trying to get bots to do things that the normal Unreal bots don’t do, we realized that we were in for a major battle. The enemy AI in Damnation needs to stand still, patrol areas, engage in scripted behaviors, have conversations with each-other, holster and unholster their weapons, shift its focus between two or more enemy and allied teams (guards, prisoners, player), etc, etc, ad nauseum. In addition, the Unreal AI is best at navigating extremely flat or smooth surfaces and wide-open areas. Damnation has many thin cliff-ledges, bumpy rock surfaces, and quite a lot of lush detail for the bots to navigate around. It was yet another instance of us not designing within the boundaries of the engine. Again, it functions fantastically under the auspices of the game for which it was intended, but getting it to do what we wanted without access to the source turned out to be a nightmare.

    The best moment was our final run-through at 10:00pm the night of the Phase 4 submission deadline. Suddenly half our AI scenarios were broken and, to boot, certain puzzles were no longer working. If we hadn’t been able to revert to an earlier build by using our source control software, we would have all probably dropped dead of heart attacks right there. It ultimately turned out that one of our programmers had set the variable bCanCrouch to false since the AI was crouching too often and that had caused cascading errors, which broke tons of seemingly unrelated scripts throughout the level. At the time, we had no idea that such a thing could occur.

  4. No Preproduction. When we started talking about making Damnation, we expected to spend at least a couple of months planning it out. We knew we were going to make a proof-of-concept prototype, but we expected it to be pretty ugly and slap-dash. Just enough to test out the game design. Once we found out about the MSUC, however, all bets were off. We jumped right into development so that we could have something good-looking, stable, and playable by the time Phase 4 rolled around. With no team assembled and much of our time still spent designing websites, we had a heck of a time getting up and running. Once we did, there was no time to look back.

    As a result of this decision to jump right in and the manic pace that ensued, our programmers were under constant and painful duress during the whole length of the project. There was no detailed player ability design doc initially, so they had no idea what to expect. We would ask them for a feature and they would come back with it. We would use it extensively throughout a level and then we’d say something like, “Hey, it’s great that he can grab onto a crane, but wouldn’t it be cool if the crane swung while he was hanging?!” Then the poor programmer would have to trash the code he had made and rebuild it with whatever arcane triangulation math was necessary to get the grab-points on the crane to move, and the player character with it. The best part was that they would have to do it in such a way that all the already-placed grab-points would still function properly. Wash. Rinse. Repeat. This lack of a clear design doc ultimately resulted in a profoundly idiosyncratic system that the programmers had to keep updating and the level designers had to somehow remember how to use. As a result, we now have a few hundred pages of detailed design docs, but the mod programmers did not have the advantage of these.

  5. Asset Management Pipeline. At the start of the project, everyone was keeping their work on their own computer. There were no naming conventions or standard directory structures. Team members were just doing whatever worked for them at the time. This obviously resulted in an asset library completely unnavigable by any one member of the team.

    We switched over to a check-out-style content management system about halfway through. This alleviated the issue immensely, but the pipeline still hadn’t been fully thought out. It grew up organically on the server and, mostly because the artists on the team didn’t really understand how it worked, the server became bloated with duplicated file names and tons of garbage data. It didn’t help that maps were constantly flinging back and forth through the ether from level designer, to sound designer, to scripter, to cinematic artist, and back again. Because the pipeline was not planned out well and given rules from the start, assets disappeared, became inexplicably modified, or were lost on a regular basis.

Next: End of Line...