Tiny Frog Software

Like any art – As we game programmers grow in our skills and abilities more often that not we can look at our past projects and be embarrassed at some of our ideas and implementations.

Most people don’t get to look at your code, unless you’ve released open source software of course. Infact, I’ve heard a good reason to make your project open source is just because other people can look at it, for that reason alone, you are compelled to make it good.

I’ve had a few “what the hell was I thinking?” moments which each of my finished games, and that’s just the finished ones. Some of the unfinished projects that never saw the light of day had horrendous ideas – like that time I tried to implement my own scripting language and parser in VB 6 with a whole lot of select statements and if-then-else trees that ended up wider than the Mississippi.

I would still like to program my own scriping language (or Domain Specific Language or DSL as all the cool kids are calling them these days.) But now at least I know it’s a difficult problem that involves a lot of Hardcore Computer Science™

So here are a few things in my finished projects that I implemented bady

1. Star Cars – My first serious attempt at becoming an independant game developer was a 3D arcade title that I no longer advertise on this site due to vista incompatabilities and requiring a hardware transform and lighting supported video card. It had this had a really long, really complex collision detection algorithm that got to the point where I didn’t actually know how it worked. It got that way by me trying to solve the problem, attempting a solution, where-in the implementation would cover 80% of the cases, then I would just hack it until it worked. There was one edge case that I could never figure out – It turned out that it was easier to change the level mesh, than try to debug that horrible code.
2. Caverns of Underkeep – Most of the design decisions for Caverns of Underkeep turned out very well, infact most of the game engine structure is being ported to my current project, but there is one part of the code thats just downright bad. And that’s how I implemented the modal dialogs – I did this weird thing where I would put the gamestate into a “modal mode” and all events would be routed from the active game state into the modal dialog class and then I would poll an object until its value was non-null which would return the gamestate back into its normal state, passing the newly created object back to the client gamestate – Don’t worry if you didn’t follow that, it’s kinda hard to explain without pictures and flow charts and things, which kind of illustrates my point. Now this method worked, but it was stupidly complex, my new method of rendering modal dialogs is to do a hit detection against GUI elements before they can process events, and simply masking the background so only the dialogs elements are exposed to the hit detection.
3. Attack of the Meeplings – Originally Attack of the Meeplings was going to have powerups and I had this cool idea for a spread gun, unfortunately I couldn’t track down a bug in my code that was not allowing for symmetric vectors for the bullet paths, ie if v is a vector then v mirrored would not have an angle symmetric with v which gave it this lopsided look – I played with this for a day before just giving up and cutting the idea of powerups. I think it had something to do with the location of the centre pixel of the bullet, the spawn location of the bullet relative to the player, and the fact that I was rendering at discrete values (ie pixels) on the screen. Really this problem shouldn’t have been all that hard to solve, but I decided at the time it just wasn’t worth it to fix.