Any number of triggers and payloads can be attached to entities. For now, they will only be used for projectiles (artillery shells), but later they could be used for many other gameplay applications. Triggers can react to collisions, height from ground, proximity to units, or they could activate after a delay. Almost anything is possible, really, but I'm starting with just collision triggers. Payloads are triggered, well, by triggers; they are the "meat" of the projectile system. Again, I'm starting simple with just kinetic (contact damage based on mass, velocity and an armor piercing multiplier) and explosive (yay, particle effects and shrapnel projectiles) payload, but almost anything would be possible. For example, it would be easy to make a cluster bomb that explodes above ground (height trigger attached to directed explosive payload) into many small bomblets (individual projectiles with contact triggers attached to explosive payloads).

More on the triggers and payloads when I get the system implemented.

One of the biggest changes has been the move of messaging from individual components to the entity itself. I might write about the details later when I've finished my changes and actually used the system for a while, but I can already tell it has reduced dependencies between parts of the code; always a good thing. The biggest test for my entity system will come when I start to implement some more complex gameplay, but so far, so good.

See you next year, happy 2009 everyone!

I have been working on Artillery Brawl, with stuff that was left incomplete when I stopped working on it in July. I haven't started on prototyping shooting yet, because I have some related stuff to do first. I have completely changed the units are represented in the code. Instead of a single entity for a unit, there are now several entities for the different parts of a unit; body, turret, later tracks and wheels. To keep all these together, I made a component (an entity is composed of components) that groups several entities together, so I can still essentially handle the unit as a single entity. At least to me, it's a very clean solution, as all these features are in self-contained components, with the entity only containing components which it doesn't know about. At some point, I'm going to have to write about my final entity system in detail, but first I need to actually finish it...

After this change is complete, I will probably work on fixing shell collisions and then move on to particle systems, camera improvements and other stuff related to trying to make shooting fun.

Happy belated holidays, everyone!

I did run into some problems with collision detection though. Shells that are fired travel relatively fast compared to their size, which leads to the infamous bullet-through-wall effect when they collide with ground. In other words: they go straight through it. I tried fixing this both by making the terrain collision shape consist of polygons instead of line segments, and decreasing the step size so that shells wouldn't jump over the line segments. Both of these were too much for pymunk though, and the game ground to a halt. Note this isn't a problem with Python either, since all the physics number crunching is done in C code.

I now have a couple of options. First, I'll try pyBox2d, based on the Box2D physics library (which chipmunk is based on, which pymunk is based on...) Box2D has continuous collision detection, meaning that objects can't jump through each other between steps, but the pyBox2d bindings are based on SWIG, which is much slower than ctypes, so it might have performance problems of its own... Additionally, I just (literally a minute ago) stumbled on Elements, which is another Python 2D physics library based on Box2D, so I'll take a look at that as well. A backup plan is faking continuous collision detection by making the collision shapes of shells longer than they actually are. Because the action in Artillery Brawl isn't very dynamic, this shouldn't cause any noticable errors in collision detection, but I'll have to see about that if I'm not satisfied with pyBox2d.

EDIT: At least these results look promising for Box2d.

The entity system overhaul is almost finished. Everything looks all right now, but doesn't really behave... there must still be some bugs left in the physics system. I'll concentrate on bug hunting and cleanup tomorrow, and hope to get to gameplay as well, next week if not tomorrow. It's really nice to have some real progress for a change.

Architecture

As every programmer knows, or at least should know, program architecture is a hard subject. Really hard. A lot of my development time during the last couple of days has been spent thinking about the perfect architecture for parts of my entity system. I want to get this at least mostly right this time to avoid having to make huge, sweeping changes again in the future (like I'm doing now, but with a relatively small codebase). I feel I have succeeded quite well, with a couple of minor warts I'm going to remedy at some point in the future.

More issue tracking

Today, I wasted an hour or two trying to install Roundup. To my surprise, it got stuck trying to initialize the database, the same problem I had with Trac yesterday. Digging into the problem a bit deeper, it seems sqlite (or its Python bindings) is to blame! Specifically, it dies, claiming that the database is already locked. That means I might give Trac another chance if I get the sqlite problem sorted out, or maybe I should just try to use Roundup with another database backend. I gave up on issue tracking for now though, so more on that later.

Today I've continued work under the hood, on the entity system. Both components and entity types are now loaded using the plugin / entry point system of setuptools, which means custom components and units will be really easy to create and distribute. And much easier for me to load. I have a habit of making too many sweeping changes to code at once, and this is no exception. On the other hand, this does result in massive improvements to the entity system and especially creation of entity type files, so it's all for the greater good.

No screenshots to show for my efforts, but see the end of the post for examples of what entity type files currently look like. This might change before these changes are completed.

Entity editor

I'll probably have to start working on an entity editor at some point, since I recon unit and other entity creation will get quite complicated when multiple linked entities, collision shapes, etc. etc. get involved. I'm no big fan of GUI programming, especially since Python's GUI libraries all seem kind of shoddy (though that seems to apply to other languages too, at least C# and Java). Anyway, I'll probably use wxPython for it. Making it in-game would be cool, but too much effort at the moment.

Trac

I tried installing Trac (again) today since they just released version 0.11, and couldn't get it working (again). After getting over a few hurdles, I was finally stumped when trac-admin hanged while trying to create the environment. Every time. I really want to like Trac, since it's excellent when it works, but I've had nothing but problems trying to get it working myself. It seems I'll have to let it go and find some other issue tracker when I really start needing one. I'd like it to integrate with Mylyn, but the (free) options there are a bit limited. We'll see...

Entity types files

Here's what a unit type file currently looks like. The interface for this is not fully implemented yet, but I hope I'll get that finished during this weekend.

And an actual unit base on the unit type above.

I'm in the progress of generalizing my entity system a bit. My current step is creating a "component library" so that unit files and other entity type definitions can load and create components by name instead of importing them, which would get really messy, really quick. I'm going to load components using entry points in setuptools, which allows me to trivially support both builtin and modder-provided components. This means it's going to be easy to make and distribute units with new functionality without the need to modify the source code of the game.

After unit placement, I think I'll spend some time on the interface. The current unit is not highlighted in anyway, and artillery shells are impossible to see if you don't zoom in ridiculously close. I'm not too keen about making them bigger since I'm aiming for a semi-realistic look. Besides, that solution won't scale if you want to zoom out even further. That means I'll have to invent some other type of highlighting for shells. After that, I have a couple of option. I could work on hit effects, which means particles, which sound like fun (especially making them fast enough in Python). Or I could work on the actual game, ie. player management, menu structure etc. I haven't decided yet, so we'll see what I'm going to do.

Btw. if anyone can recommend a good program for capturing video from a game, I would be happy. I've found recommendations on FRAPS and Growler Guncam thus far, but both look a bit... amateurish.

Though the code is still a bit of a mess and the transformation to components isn't fully done yet, I can really say they clean up the code structure and responsibilities a lot. Communications also work better than I expected, at least at this point. We'll see what problems I run into when things get a lot more complex. I really like the entity type / entity distinction too. You can already add new units and artillery shell types to the game by placing an appropriate Python script file in the "units" or "shells" directory, respectively. In any case I'm happy to finally get back to "real" progress after this transformation. And you can start expecting screenshots again next week.

Btw, if you want to know more about how some part of my design works, feel free to ask and I'll talk about it in a future post.