| Abstract | |
| Game Title: | Roundhouse! |
| Development Team Members: | Grant Watters Eric Foote |
| Game Genre: | Sci-fi / Sports |
| Brief Description: | Roundhouse is about getting huge air and doing tricks. The more tricks you do, the more points you get. You should also attempt to get powerups whenever possible as they will give you bonuses. The control is mostly done through the mouse and the keyboard is used to initiate the various tricks in the game. |
| Overview | |
| Game Story / Objective: | The object of Roundhouse is to do as many tricks and accumulate points in a set amount of time. Each level has a time limit and a goal score. If you reach the goal score, you will win when time runs out, otherwise you will lose. The game is set in the future as you drive around a hovercraft on what appears to be various circuit and electrical parts. |
| Game Mechanics + Controls: | Once the game has loaded, you control a hovercraft by left-clicking the mouse and then dragging it to apply a force to the craft. The greater the magnitude of the vector from where you clicked to where the mouse is brought to the greater the force applied to the hovercraft will be. In addition, you have a limited amount of thrust which can be applied by hitting the spacebar, this will propel you upwards for a short period of time. In order to do tricks, you must be in the air, and the tricks can be initiated by pressing any of the number keys (0-9). The further along the number row (to the right) you are, the longer and more complicated the trick is (and worth more points). Doing the same trick multiple times in a row makes the trick worth fewer points so it is best to mix the different tricks togeather. There are also powerups scattered throughout the world that give you various beneficial boosts such as an increased thruster regen, lessen the effect of gravity on the hovercraft so you can stay in the air longer as well as a bonus score multiplier. Basic Controls: 0-9 Keys: Tricks Spacebar: Thruster Mouse Click/Drag: Hovercraft Control Debug Controls: Enable/Disable Physics Debug: +/- Enable/Disable Fog: k/l Enable/Disable Lighting: o/p Enable/Disable Wireframes: ]/[ Enable/Disable Debug Text: u/i |
| Technology: | The game is build using all original code except for the physics engine, the sound, and the windowing/image libraries. It is written in C++ and uses OpenGL to render and OpenAL for the sound (the ogg vorbis libraries as well). It supports loading for .ma (maya readable format files) as well as .md2 models. It uses SDL for window management as well as SDL_image for the image loading. We also decided to use the Bullet Physics Library for our physics simulation. The base of the game and what each level consists of is a good sized heightmap (512x512 by default but was tested up to 1024x1024) as a base terrain for the hovercar to do tricks on. We used a quadtree with frustum culling to cull unnecessary terrain patches from being rendered. There are some vast improvements that could be made to the terrain rendering, but because we did not require heightmaps larger than 1024x1024 there was really no point (though inefficient time was more important). The player model in animated through a shader that lerps the current and next frame togeather (this was originally added because we thought we would have more animated objects in the scene, we however had to cut this short). |
| Aesthetics: | The terrain was created to be somewhat of a skate park which the player could jump off of just about anything and fly into the air to do cool tricks. The animations were not made to be believable (the hovercar twists itself and bends defying reality). The terrain is textured to look futuristic (kind of like a circuit board with random other electronic parts on it). The music is also technoish to support the future theme. |
| Media | |
| Screenshots: | Screenshot One Screenshot Two |
| Download: | Download Here Source code available upon request. |
| Development Summary | |
| CODE: | The code integrates multiple third party libraries togeather, and for the most part should be interchangable with other libraries that do the same thing (that is the third party libraries are somewhat decoupled from the gameplay). OpenGL is used for rendering OpenAL is used for sound Bullet Physics is used for physics SDL is used for window management SDL_image is used for loading images/heightmaps The interface for meshs was at first abstracted out to allow easy loading of different mesh types in case we decided to go with something other than straight vertex animation (it turns out we didn't) but by the end they were somewhat coupled as we decided we realized that we needed to spend more time implementing the game instead of implementing a good engine design for the game. There is a resource manager which manages all the different types of resources (including models, model instances, textures, lights, sounds etc etc) using a std::map The heightmap and quadtree generation were seperate from normal model loading and were not managed by the ResourceManager class. This is because there is only one heightmap required per level. |
| CONTENT: | All the assests in the game are made by us. This includes the hovercar, the music as well as the terrain for both the released level and test level and their textures. |
| Reflections | |
| Three Greatest Challenges: | 1) Completing the gameplay in a timely fashion (kept getting sidetracked by cool things) 2) Getting the steering to work properly with the somewhat rough terrain 3) Figuring out the intialize design and layout for the game, how to manage resources and load levels, model instancing etc. |
| Three things that went right: | 1) The camera and the car controls 2) The HUD display 3) Physics Integration and Collision Handling |
| Three things that went wrong: | 1) Properly loading the human readable maya formats (this does work mostly, some artifacts) 2) No menus/level select screen 3) Not all the powerups were implemented in time |
| Other final thoughts: | Given the strict time limits imposed on this project and the limited time that we had to commit to the project, it may have made sense to use a premade rendering engine instead of developing our own from scratch. Basically time imposed huge restrictions on what we could get done and polished in time for the final demonstration. It could be nice in the future to introduce the project earlier than was done just to get people to begin thinking about it (no work assigned for it other than finding a group etc). As previously stated, time was a huge limiting factor for our group and we wish that we had more of it in order to polish our final project more than we did. |
