by Michael Mandel and
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.
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.
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
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.