Tower Defense school project

Published April 08, 2010
Advertisement
In a class at school we're doing a Tower Defense game now, and I've been trying to stay focused this time instead of getting carried away with all the fun stuff.

The class i seperated into two projects, each counting 50% of the final grading. In the first project, which is running now, we will focus on the fixed-pipeline of opengl and on gameplay. We have to have a completely functional Tower Defense game. In the second project, we'll add programmable pipeline to the project, with GLSL shaders and some GPGPU stuff (cuda/opencl). First project is due 25.april!

My plans for the first project is a complete Tower Defense game with menu system, multiple levels, a heightmapped terrain, A* pathfinding for mobs, quadtree partitioning for collision, scenegraph, component-based gameobject/entity system, textured HUD, color/depth picking, mesh loading and quite balanced gameplay. Quite optimistic goals for a one month project :P We'll see how far I'll get!

So, I started out 22.march to write the engine and game. Quite early I got a grid set up and got color picking going. It was all brute force though, so I made a silent note to myself I had to optimize this later.



I then started on implementing towers and mobiles, because with picking in place I thought it'd be cool to start placing towers early. Towers are modular, built in 3 parts: Base, tower and head.



So now I could place towers and mobiles (no AI yet). Cool, so I thought I'd get some action going early through collision testing. I quite quickly added a bruteforce collision test on the perimeter circle of the towers with the bounding circle of the mobs and made the perimeter turn red when a collision was detected.



From here it was very easy to add a gun component to the tower object to get some more visual and gameplay action going. I added a health component, a railgun component and a new scenegraph node called RailgunFire.



So now I had my first stage of gameplay going. Towers would detect mobs in their perimiter and would fire upon them until they died. Now I wanted the mobs to move. I added a quick waypoint system and predefined a path over the grid.



This gave the game a bit more "game feel". So I thought I'd turn my attention to the HUD system for just a bit, to get that in early as well. Using orthographic camera and glut's font rendering I started displaying FPS and deltatime to my 1337 HUD!



Ooops! Up until now I hadn't paied any time to fps or perfomance, I had just thrown features in there to get the game up and running quickly! I figured it was time to optimize a bit. I wrote a scenegraph manager interface that I overloaded with a VBOManager class. The idea here was that all scenegraph nodes would only define data in arrays for rendering, and the scenegraph manager would handle the rendering. This way it would be simple to add backstepping for older hardware, and add upgrades when the next project with shaders start.

I first concentrated on the Grid, which I rewrote to be displayed in a single VBO using degenerated triangles technique on one triangle strip.



The fps flew up immediately, but now the color picking didn't work anymore. I had been displaying "cells" before using GL_QUADS, where each cell held 4 vertices. Now I had a optimized grid where each vertex only had one color defined with it. After some struggeling I found that switching to depth picking using gluUnProject was my best bet for the time being. I didn't have too much time to invest on this after all, I had already spent a lot of time refactoring my code for the scenegraph manager implementation.



I then started refactoring the towers and minion graphics to work with the new VBO manager. The FPS stayed quite stable around 60 fps still!



I reenabled my collision system and saw an immediate drop in fps. Doing some quick profiling showed that it was time to add something slightly more sophisticated than my bruteforce O(n^2) collision testing! I started implementing a quadtree structure.



Here I draw the entire quadtree using VBO quads. I didn't bother on optimizing the rendering of it, as I did with the grid, because it's only for debug displaying anyway...



Evidently the quadtree implementation helped quite a bit on the collision checks though, lessening the checks to something around O(log n)! I also added collision object filtering and stopped objects who had already collided from testing collisions against each other in the opposite direction :P Quite obvious optimizations all of them, but they all had to be implemented!

So this is where I'm at now. Philop aka Guybrush has done some placeholder 3d meshes for me which I'm looking forward to get in there, but first I think I need to concentrate on some more HUD implementation and getting that A* pathfinding in there. Once that's in it's a short path to a working, basic tower defense game!



Lessons learned so far: Profile from the very start! Mind the FPS from the early start! Refactoring large systems and changing direction at the core takes a lot of time to implement! Wow, I was cruising before I did the optimization steps, but now time is getting short here! And I who had hoped to get time for pollishing gameplay and stuff at the end there... Oh well :D

I'll continue to report progress up until deadline!
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement