Create-ivity

Ah! Yesterday I finished the animation system for Tar!. Basically, the engine loads a text file for each sprite, and based on the information contained in these files it loads a specific image file and sets the animation data as defined in this text file.

The content of such a file looks like this:

$sprite player.bmp
$size 128 64
$framesize 32 32
$animation “default”
{
$frames 0 1 2 2 3 2 4 2
$frametime 50
}

For now, it suffices, and it’s pretty fun to play around with some test images and animation settings. I might want to write a tool for generating these files and managing my images later on, or refine the system as it’s probably not going to be too manageable with large amounts of sprites. But at this stage, it’s pretty cool to have it up and running. :)

I also added text rendering support (based the same animation system) and I’m working on some primitive drawing functions, like lines and rectangles. Woo, feels good to make progress!

Just a quick update – it’s late here, and I’m late with updates anyway. I reworked the level file format last week, so I can now load various tile layers as well as loosely placed sprites, and there’s a seperate data chunk for the collision data. Since I wrote support for triangles, boxes and circles, Tar levels are not going to be as boxy as most tile-based games.

That is, once I get this collision system to work properly. I tested it outside the game code, which showed correct results, but some tests in-game obviously showed that something was wrong. The tar balls I’m spitting out hit invisible barriers and then fly off at incredible speeds. Probably something with the coordinate system or the way these objects are loaded. Or something entirely elsewhere…

Debugging. Ideally it’s pointless…

As for my internship, which takes most of my time these days, it’s finally speeding up. We’re getting close to the end of the QA phase now, which is a great relief: that first game will finally get published. Never expected this stage would take so long. That’s probably why first-hand experience is so important. You won’t really understand it otherwise.

Turned out collision handling was a bit more difficult than I thought. It didn’t came as a big surprize, as it’s not one of the easiest subjects anyway, but after I had finished the boolean collision checks (it collides, or it doesn’t), I started to think the rest wouldn’t be too hard anymore either.

My current approach is to look for the smallest intersection after moving an object, so to correct it’s movement. No problem with that, it’s just another few hundred lines of code. Then comes a problem: what if the corrected movement would cause the shape to intersect another object? No big deal, just check all other relevant shapes. But what if, after a few corrections, it would intersect one of the earlier shapes? That’s an issue I still don’t have an answer to.

Another issue is movement constraints. Certain shapes need to be constrainted to move only on a certain axis. Correcting movement becomes quite more difficult there – or at least, I haven’t found a way to correctly handle it yet. Currently I think doing multiple tests, at various points across the movement vector, might just suffice… hopefully.

Well, lot’s of stuff to test there. I hope I can get some substantial progress the coming time, as my internship takes quite some time and energy as well. It’s fun, though, and again encourages me to program in C++ at home. “Build once, debug everywhere” is the new latest motto at my job, and while I’m getting used to the don’t-worry-about-the-low-level approach, I still miss it at points. Sometimes it’s downright frustrating. Oh well, that’s probably the case with everything, so I’ll live with it. :)