The day after...

So it's been 2 months of hard work on this beast, and now it's over. Over 2000 views on my journal since I first posted about this project, thanks a lot guys!

In the early retrospect, I think I did a lot of things right on this project, but also an aweful lot of things wrong. I started out with a sound plan, I was going to get in a fully working tower defense game before I started doing anything graphics related.

In the first month of this project, which was titled Part 1, we were to base the game on the OpenGL fixed function, which was a blessing. No need to think about shaders or doing anything fancy graphically, I could consentrate on the core elements of the engine and on the gameplay.

Unfortunately I spent way too much time on the engine :P I already had my component system, which was the core of the engine. I was very comfortable with how to structure objects and communication between them and gameplay logic using that system, which saved me a lot of time on that part. But I also set out with a goal to make everything as generic as I could.

I ended up with a IRenderer class, which had a BasicRenderer and a VBORenderer on top. With this approach I forced upon myself to enclose all VBO handling in that single class, for every single scenegraph node. Fair enough, I had to build data structures around it that the nodes could use to declair their data lists, for then to let the VBORenderer convert this into vbos. It worked pretty good, but when I had to work in new things into the system, like shaders down the line, it required quite extensive rewriting of this class. Also, when a bug would occure in the vbo related data, I would always track the bug down in this class, making it a little bit more difficult to pinpoint which node it came from, etc.

In the end, I think it would've been a good approach had I only started the OpenGL 3.1 implementation from the get-go. I spent well over a week, maybe two, of the second project (Part 2), just to rewrite the engine to OpenGL 3.1 with programmable pipeline!

In the end I was pretty satisfied with Part1, but I started crunching too late. The last day of development, I had to run overtime to get in the final gameplay pieces, going over the deadline by some 30 minutes or so. When I started Part 2, I told myself this should NOT happen again!

The first week of Part 2, I fixed some bugs and shortcomings in the engine I had found during the last couple days of Part 1. Texture Manager wouldn't load the same texture twice, Mesh loader wouldn't load the same mesh twice and the RenderInfo object, that held the data for a node (vertices, normals, texcoords, etc) was also handled this same way on the C++ side, so that nodes of the same type would share the same render data, unless explicitly told to have their own unique copy.

I also started rewriting for 3.1 this week, but that rewrite lasted a lot longer than I had anticipated. One week left until the initial deadline, I got post-processing in via FBOs and shaders. I didn't make an API for the post-processing steps, so it was all hardcoded into the SceneManager class. Of course, I intended to write the post-processing into some form of PostProcess API, but there was never time for it. At least I got time to build such APIs for shaders, uniforms and attributes. I should probably also have done the same thing with VBOs.

I hacked in the GUI. It was just simple fullscreen textures for each element. I detected mouse-hover and button presses by accessing the alpha of the textures in C++ and see if the mouse position indexed an alpha texel that gave a specific value I associated with a button. No "real" GUI handling in other words. This didn't take much time to implement though, and I doubt I would've had time to do it the "right" way. So all in all, I think it was a right decision, though it prevented me from supporting any other viewport size than the 1024x1024 I had been running with.

My biggest mistake for this project was to start on the Cuda integration so late. We got one week extension on the project to get time for Cuda, because I wasn't the only one who started late. I found out that my computer didn't support Cuda 3.0, and that Cuda 2.3 installed one year old drivers that crashed my game. So I had to do the water simulation in GLSL. Unfortunately, I spent probably three days fully coming to this conclusion, and by that time I was on the last day of development (yesterday) and had only few hours left until the deadline. I had to make the choice to let it go in favor of making the total package feel more complete.

I thus got time for doing some last minute details. In the end I got in a lot of gameplay details, even though I failed to get time for moster upgrades. I did get in tower upgrades however.

In the end, I'm quite satisfied. As an individual project done from the ground up in C++, OpenGL and GLSL, it ended up alright. It's fairly playable, though not closed to balanced of course :P It looks ok, though not close to AAA of course. There's a ton of things I'd love to get time for on this game, but with a hard deadline there just wasn't enough of the time...

I will probably continue this project though, just to make it feel more like a pollished game demo than it is right now, but at a much slower pace. Now, summer vacation starts!

Share this comment

Link to comment

Share this comment

Link to comment

Thanks guys! Yes, I've learned a lot! Hopefully something that we can put to good use on Apoc too ;) I'm really glad to hear that some of you guys have had fun following my development, puts the whole development blogging into a different perspective for me!