#include <my_blog_name.h>

Today serves as a dual celebration, because not only is it π-day, but 1 year ago today, I made my first post (appropriately named "First Post".) My how time has changed... back then, I was employed, was in school, and had a whopping 0 readers of this blog. Now look at me, with all these readers. (2 tops.) Wow, awesome! ;)

So, in celebration of both π and my blog, uh... well, I don't really have anything of crazy value to give you, unfortunately. I do, however, have a significantly cleaned-up version of that TunnelTanks game. It's in no way advanced enough to be called a game, but it does feature randomized levels, shooting (without weird glitching bugs), and a completely rewritten core that allows the game to be run at nearly any resolution, while still remaining the correct aspect ratio. (Plus, all of the scaling is done with integer math, so that the game can eventually be ported to embedded devices with ease.)

So tinker around with it, and do tell me how it works. :) Arrow keys move your tank, and the left control shoots. Plus, you can press 'x' to spawn a huge explosion wherever your tank is. (Those explosions usually only happen when you die, but you can't die yet...)

Next up: organizing some of the main.c code better, and finally adding some more tanks. Then, I can start coding the AI. :)

Source Code (tar.bz2)

Here's another small update, because I feel like it.

The graphics part of the code has been abstracted, so that we can now have multiple viewing panes in a single window, and it will always center on a single tank object. Also, digging through dirt now takes longer than driving in the open, collision detection works great, and you can also fire bullets. Those bullets will hit dirt/other obstacles, and generate a neat little explosion effect at the point where the bullets hit.

However, it's time for some code cleanup, specifically with the window code. Currently, I have it so that the window will detect which parts of the visual has changed, and will only copy those pixels over. That's awesome, and I want to keep that, but I need to improve the way that the bullets/particle effects are drawn. Currently, they are viewed the same as other updates (like when the tank digs) but since effects are so small and so numerous, it leads to some pretty horrific inefficiencies...

Plus, I need to abstract the Tank's controlling mechanism away from the raw inputs, since I'm hoping that network or AI controllers can be all be treated identically by the game's logic... Big things planned... :)

Next update will probably include source code... you know... after the code cleanup... ;)

Next up: Collision detection, and then shooting.

Oh, and I'm thinking of naming the project "Tunnel Tanks" because I don't see a project out there named that. (Well, there is one, but it was only mentioned on 1 forum, and the website is 404-ing...)

Just a quick update:

Ok, so the C code now generates 1000x500 sized maps, instead of the 600x500 that I was using earlier. (The original game generated 1000x500 maps...) Plus, the C code now generates color graphics, and can save those graphics to file, all thanks to SDL. (Plus, it only takes .37 sec to generate that huge map, which is good, but I think that it could be better... :) )

The code allows for zooming in, and drawing specific parts of the map, so I just need to start catching keyboard events, and throw a tank in there for this thing to be sort-of playable. :)

I rewrote the random cave thing in C, and... wow. I sometimes forget just how quick C is sometimes. I wrote this with painfully simple algorithms, that don't take advantage of some of the logical speedups used in the Python version, and it finishes in only 0.34 seconds. I'm pretty happy with that, but I may still fiddle with it later.

The code uses (hopefully) portable C89, so you should be able to compile it with no arguments. (However, adding -O2 is needed to get you the 0.34 completion time... else it takes around a second and a half...) Also, this program doesn't produce pretty output like the last. Instead, it takes the zero-dependency approach by printing its output in ASCII art.

Source Code (GPLv3)