Coredump Final Report

Lawrence Chang

David Lien

/*Overview*/

//Concept

Coredump is a fast-paced, 3D two-player robot fighting game. Each player assumes the position of a robot in either 1^st or 3^rd person view, and attacks the opponent by firing energy bolts. The game emphasize on control: the better you pilot your robot, the more likely you can coredump your opponent.

//Features

GamePlay

- Data Driven Level

- 3D Deformable Landscape with Buildings

- Switch Between 1^st and 3^rd Person Mode

- Control Variety, including walking, flying, turning, and side striding

- Background soundtrack and sound effects

- Status Panel with life and missile bars, and a radar display

- Auto Height Aiming

Technical

- Quadtree with Frustum Culling

- Vertex Array Rendering

- Bounding Box Collision detection for robot, buildings, and projectiles

- Height Interpolation

- 3DS Model Import with KeyFrame animation (lib3ds)

- wav and mp3 sound import (fmod)

- Camera Model with Slerp

- Quaternion Class

- Multitexturing with transparency

//Controls

	Player 1	Player 2
Run(Fly) Forward	UP	T
Run(Fly) Backward	DOWN	G
Turn Left	LEFT	F
Turn Right	RIGHT	H
Strafe Left	[	Q
Strafe Right	]	W
Fire Missile 1	\	E
Fire Missile 2	=	S
Jump (Fly)	‘	A
1^st Person Mode	F9	F1
3^rd Person Mode	F10	F2
Reset Life	F5	F5

/* Development */

//Code

main

player class – include position, life status, movement functions

projectile class – location, status of a player’s missiles, as well as billboard animation

camera class – positions, view, and slerp movements

skybox class – draws skybox

quadtree class – contains the terrain heightfield, texture, and building information inside obstruction class

utilities

billboard class – draws transparent/solid billboards relative to the world or screen.

Boundingbox class – creates bounding boxes for all world objects as well as their movement rays

drawstring class – paints a string to screen

obj3ds class – loads robot and handles appropriate animations

obstruction class – checks for ray-bounding box collision

quat class – quaterion functions

texturemap class – loads textures

//Content

/* Key Technical Challenge */

Keyframe animation – we had a ton of problems trying to import animation into our game. First is trying to figure the right way to make the 3D Studio Max model to make it importable. We spent 3 days trying out various ways of modeling and exporting (such as using biped, and bones), then finally figure out the best way is to use simple cylinders to make “fake” bones so we can export the whole model to .3ds format without having to keyframe every frame. Then we ran into problem with materials property, where the entire model became white. When trying to create the jetpack flames for flying and strafing, we find that Max has serious bugs when exporting non-uniform scaling animation. In short, although we got around all the problems and successfully animate our robot, the process was hideous, and ended up taking away from our time to make extra models.

Collision Detection – At first we did a simple point inside box test algorithm to see if points in or on the box were inside the 6 lines that defined the box. However, this was not a good enough check because of the high speed of the projectile movement. Projectiles were skipping past bounding boxes when changing from 1 frame to another. Thus, we decided to use the ray-box intersection test to see if our ray had hit the box between two specific time intervals. However, this test proved to be challenging in a different way however in that the algorithm for a ray-box intersection was highly confusing. Fortunately though, we were able to parse through the algorithm and determine where our bugs lay, and fixed them.

Vertex Array – The vector arrays were chosen because of the need to have a list of vertices that could be dynamically changed to accommodate a deformable landscape. With vector arrays, we were not only able to keep vertices in an easily accessible, organized manner, but gained the advantage of fast rendering. The main problem with vector arrays was deciding to have the entire course be one big vector array or have each tile on the course be a vector array. In the end, we decided for each tile to be a vector array so that the quadtree could draw only desired tiles and so that individual tiles could be accessed easily. The other main problem arose from trying to enable multi-texturing through vertex arrays because we were unfamiliar with the process. But in the end, we were able to figure out the right implementation of it.

/* Postmortem */

What Went Right:

In the end, our code proved to be very flexible in their functionality. For example, the camera class is simply the same as the player class, except that it points the camera with gluLookAt in the render function instead of rendering an object. Furthermore, the projectile class is the same as the player class without a camera following them and the obstruction class is the same as the player class without a camera and is always stationary.

Furthermore, another thing that went right was the deformable landscape which was one of our main goals. Because of the way we systematic manner in which tiles on the course corresponded to indexes on the vertex arrays, we were able to lower the y-value of the specific tile a specified amount every time a collision occurred.

Lastly, though it was tough, the 3d models and animations that we did have time to create were successful in the end. There was smooth interpolation between different animations and they were a highly integral part to making our game better not simply visually, but in quality as well.

Though the 3d models were an example of what went right, they can also be used as an example of what went wrong. In using 3d models, we were treading in unfamiliar territory, especially with the importation process through the lib3ds library from sourceforge.net. We basically went through a tedious trial-by-error process to figure out what importation methods and animation techniques from 3D Studio Max did and did not work. This time would have been definitely been more valuable spent elsewhere if things had simply gone right with the lib3ds library from the start.

Another thing that went wrong was that we weren’t able to take care of obstacles that get in the way of the camera. Thus, for example, if a building comes between our player and the camera, the user is effectively unable to see their player until the player moves more away from the building. We would have liked to take care of this but we were unable to because of the lack of time.

The last thing that went wrong was the lack of time for any AI or networking code and instead we had to settle for split-screen 2 player. While AI or networking would have been nice, the lack of experience and severe lack of time due to problems in other program goals hampered our ability to research AI or networking possibilities. Thus, this led to another problem in our game, which was key jamming because of the limitations of OpenGL to recognize more than a certain number of keys being pressed at once.

The main lesson we’ve learned from this project is to be more realistic when setting your goals. Though we feel that we were able to achieve many of our goals, it was not easy and required many, many hours of programming and trial-by-error to get to the point that we are at now. Of course, starting early is invaluable and remembering the problems that we had this time around for the future is very key to improving ourselves as programmers. In the end however, we were very satisfied with our game and the results that we were able to produce.