Cursed: Postmortem
by Michael Mandel and Eric Leese
 

Overview:
Our game is titled Cursed.  It takes place in a graveyard setting and you take control of a hero who must banish an evil curse that has converted a town into zombies.  In the specified time limit (5 minutes), you must eliminate the zombie threat.  Afterward, the sorcerer who cast the curse meets you for a battle in a central arena.  He has the capability of teleporting and sports a stronger range of moves than the zombies.  Upon his defeat, you win the game.
 

The game has the following features:

·        Motion Captured Animation System

·        Quake3 Level Loading / Rendering

·        3DS Character Model Importing

·        Collision Detection (against the BSP tree, character / character, character / sword, camera)

·        Third-Person Detached Camera

·        Data-Driven Design (both in animation setup and level design)

·        Debugging Console Featuring Tab Complete, Command History, Serialization, Custom Commands, as well as Exposing Most Any Program Variable

·        Light-mapping and Texture Animation

·        Support for Analog Joystick Control and the P5 Tracking Glove

·        Event-Driven Triggering System for Scripting Game Events

·        Music / Sound Effects

·        Unique Animation System Featuring Automatic Transition Graph Technology (plus an assortment of blending techniques)
 

The user controls the main character from a third person perspective in a camera relative fashion.  An analog joystick may be used to have better control over his movement speeds and turning capabilities.  Left, Forward, and Right attacks are supported through the use of buttons on the joystick or a unique gesture recognition system in combination with the P5 tracker glove.  Simple combos are also possible (left-forward, right-forward).  Keyboard is the default if no devices are present.

 

Development Summary
Debugging console and simple game framework built beforehand in combination with a research project.  Initial Quake3 rendering code created with help of tutorial at http://www.gametutorials.com/.  The L3DS library was used to help load 3DS models.  FMOD was used as a sound library.

Code follows an object oriented design in terms of its game objects.  The most primitive being an Entity supporting many common features the engine assumes.  The animation system has many layers of code to ease development and reduce potential bugs.  The use of templated Singletons and Factory patterns have also helped solve some common problems during development.
 

Content was mostly found on the web.  The quake 3 level was downloaded from http://www.planetquake.com/.  The zombie model was found on a website as well and edited by us (so it may be fitted to our skeleton) in MilkShape 3D.  The sword model was downloaded from www.turbosquid.com.  The motion capture animation was captured and cleaned by Mike Mandel last semester in the CMU Mocap lab.  The sound effects came from the search engine at http://www.findsounds.com/.   The UI design was done by us in Photoshop.  The background music is number of Mp3s including a remixed Castlevania theme, Omnibus, Equador by Sash, and music from Sonic CD.

Key technical challenges involved managing such a large project (currently around 25,000 lines of code) among two people and identifying/prioritizing critical bugs and finding quick solutions.  The animation system posed many technical challenges because of the limited amount of motion we had and the difficulties in generating realistic interactions with the environment and the player.  We had limited experience with art tools such as Maya and 3DSMax, so we had to rely on code to fix a number of problems (resampling the data, fitting a model to our skeleton, and creating correct looking blends and transitions). 
 

Camera and collision in an arbitrary 3D world posed a number of technical hurdles.  Among the problems is that Quake3 collision brushes are not well documented and we had to figure out by brute force which brushes were relevant.  Simply getting the camera to behave in a reasonable way when the character must navigate through tight areas, go through doors, or around corners posed many challenges.  Finding the right theme and feasible gameplay that might actually be fun was another source of debate in the project.  Time and technical limitations contributed to the decisions made about the type of interactions found in the game.

 

PostMortem

Much of the focus of this project for us was trying to get the best looking, technically capable game possible – in the short constraints of the 4 week available time.  We realized we needed to be smart in the technologies we used and the sources of content we utilized.  The decision to go with Quake3 levels was well worth the effort since it afforded us the option of thousands of free fan-developed levels over almost every theme imaginable.  Though the format is in many ways undocumented, it has a solid base of documentation for the most important features and eases many of the troublesome details (such as BSP tree construction and collision detection).
 

The debugging console we used became one of the most invaluable tools in our development.  It afforded immediate exposure of variables so we could fine-tune parameters such as camera-control without recompilation (and it has permanent effects on the values of these variables so we don’t have to write a line of extra code).  It also exposed a method of creating custom functions that we could execute at runtime to information about the world or to process files in a convenient setting.
 

We were able to divide the labor of the project to suit our capabilities.  Mike managed the animation system, gameplay, and scripting system while Eric took most of the rendering, collision, and camera tasks.  In addition to working on separate tasks, the use of WinCVS helped us manage the control of our source to the point that we had no significant merging issues.

However, the project was overly ambitious.  We underestimated the amount of work it would take to polish the gameplay system as well as some other key components.  We often had to make compromises or sacrifices from what would make the best game in order to have any game at all (such as the use of very “unintelligent” zombies as our primary enemy and having to leave in the sphere man as our main character).  It often seemed like there was more work to do than was possible in the time we had left.  Sometimes we went for the flashier stuff to hide the weaker parts of the gameplay.  In the end, we managed to make enough compromises to come out with something we are satisfied with, but not necessarily what we originally envisioned.
 

The idea that we could use the automatic transition graph approach to mocap animation for EVERYTHING was a very bad idea.  These techniques are very new and unproven.  A lot of wasted effort went in to trying to make the full interactive experience synthesized automatically with no use of standard video game hacks.  In the end, code that has a significant time investment has to be put aside to have something we could work with.  A combination of standard video game hacks and the motion synthesis were combined to get our final product - in some cases we had to make some sacrifices in quality for the time constraints we were under.  The best solution probably mixes the transition graph techniques with some of the standard blending techniques first introduced in the Verbs and Adverbs paper.
 

Many systems we wished to develop were dependant on having a playable game, and that happened much later than planned.  This left less time to tune the gameplay and more time trying to just get code support in for everything we needed to have a game run from start to win.  We should have pushed for an early playable prototype much sooner.  The fact that we didn’t have a clear vision from the start of exactly what the theme of our game would be (other than the fact it used martial arts mocap animation), didn’t help us toward this goal.  We often used the limitations of ourselves as artists and the limitations of our system to drive our ideas of what we could do and thus found an appropriate theme.