Create-ivity

It’s been a while since my last update, but that’s because I’ve been busy. Aural Fighter is moving along nicely, even now that school has started I managed to continue development at a steady pace. Behold, the main menu (including flying aircraft for decoration):

I’ve also been working on the collision system a bit - I’m rolling my own routines rather than the standard movieclip hittest functions, because all I need are some basic rectangle-rectangle tests. No real problems here: I’ve done it before and I did it again, everything’s working fine. So, I can now blow up some enemies or blow myself up by crashing into them. Fun!

However, I started running into some performance issues. Nothing bad, it seems it was most troublesome on my own system, but the game just wasn’t playing 100% smooth. After some research I found another approach at rendering the game: using BitmapData objects as surfaces instead of movieclips for everything. It’s a bit more low-level, but much more how I’m used to work with 2D, so I quickly wrote a small rendering framework around it. It works like a charm. Too bad there’s no neat way to compare the performance, but at least it feels a bit smoother now. It runs fine on the other systems I tested it on, too, so I guess it won’t be a problem.

I’ll soon move into the art phase: large parts of the logic are done and dealt with, except for a few menu’s and the weapon selection system, so after that, it’s creating tiles, levels, enemies and scripting enemy waves. Yay! :)

This prototype is getting pretty math- and logic-intensive! But that’s good, because I like the challenge. Currently, I can fire shots at enemy blocks, which adds cracks to them. I already had the basics done, but I ran into trouble when cracks intersected each other. What I usually do, when I can’t figure it out after a while, is writing things down in a logical, illustrated way, and then reworking the code according to my new ‘flow scheme’.

So, with the new code, when a shot hits a block, the intersection point is calculated and it’s used as the starting point for the crack line. This crack line is used for collision checks, and for every collision, the given edge is split up into two edges, and for every two collisions, an edge between the intersection points is created. When another border edge is encountered, the whole process is aborted: you don’t want cracks outside the block itself!

There’s still a few bugs to iron out here, but once I’ve solved those I can work on the next stage: actually breaking up the blocks into smaller blocks.

And after that, it’s mostly adding some new weapon and enemy types, and then it’s playtesting time. :)

Game-development update

After a long blogging silence I’m back into blogging. The past few months I’ve been working on a game-design project, together with 3 fellow students. I was responsible for the programming. I’ve used Python and the Panda 3D engine, and I’m quite surprized by how fast I could get stuff up and running. I’ll surely be using Python more from now on. As for the game, I got a scriptable system up and running within a few weeks, to make life easier for the level-designers. In the end, it turned out to be quite usefull, and adding new game entities was a piece of cake.

Of course, no project goes by without trouble. The collision system was somewhat stubborn to work with at first, and once I found my way around it, it turned out not to be 100% solid: sometimes, objects would fall out of the collision hull, and not even at too high speeds. I also was too optimistic in my planning, as polishing and bugfixing always take more time than you’d like.

Since one of my teammates continues to work on this game, I won’t put up a download. Right now, it only contains 2 levels anyway.

Let the prototyping begin!

I’ve also started prototyping some small game idea’s of mine. My dedication span is too short for projects like Tar!, it seems, so this is how I’m trying to train myself to finish things: taking on small, fun projects and working them out into playable games. If one of these turns out to be really fun, then I’ll take the time to polish it into a fully fledged game.

I’ve got a small list of game idea’s that sound interesting, at least to me, so I can choose which one looks most promising - and doable. Right now, I’m working on something that I call Block Breaker for now. It’s a sort of asteroids top-down shooter, but rather than firing shots at asteroids and decreasing their life, you fire cracks in them to fragment them into smaller pieces. Small pieces become unstable and will eventually vaporize, but you shouldn’t collide with the large blocks, obviously.

Currently, I can fire cracks into blocks, but I haven’t completely figured out how to create fragment pieces when a crack crosses some existing cracks. Test-phace screenshot:

That’s all for now. Seeya! :)

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.