Brainfold

My work with the entity system is pretty much finished for now. Everything seems to be finally working and the code is reasonably clean. I don’t want to get stuck polishing the code while it’s still missing most of the planned features. I didn’t get to gameplay / user interface stuff yet, but I hope to do so next week. Time to get something concrete done for a change.

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.

Tags: Artillery Brawl, Box2d, entity system, physics, pymunk

Yet more entities

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.

Tags: Artillery Brawl, entity system, issue tracker

Entity system

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…

Read more »

Tags: Artillery Brawl, code, entity system, GUI, issue tracker, setuptools, tools

Today, I got back from Sweden, Arty got a new name, and I continued a tiny bit on my entity system. Rather than keeping the name of my old game, I’m making a tribute to Artillery Duel and naming it Artillery Brawl. Also, I already have some cool ideas for a possible sequel. Of course, that will be far in the future if it ever becomes reality, but at least I can store ideas in its brainstorming wiki instead of throwing them away if they don’t fit in Artillery Brawl.

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.

Tags: Artillery Brawl, entity system, setuptools

This week, I’ve done more groundwork with entities, and just started on unit placement. Unfortunately, I don’t expect to finish it this week, since today I’ve got other things to do, and tomorrow I’m leaving for Sweden for a couple of days. The entity system is starting to look really nice though, and I’ve got lots of ideas to make it even better. After unit placement, I think I’ll concentrate on those ideas and some cleanup to pave the way for gameplay stuff and particles I was talking about earlier. At some point, I’m also going to write a whole post about the entity system, its design and development, and my experiences with it. But that will have to wait until the entity system is more complete. So, until next week!

Tags: Artillery Brawl, entity system

Every programmer knows that sometimes you have to spend time to work on code that no one will ever see. Background work for new features, cleaning up, restructuring or refactoring old code etc. etc. This week I have been doing exactly that. In preparation for implementing unit placement, which requires a bit more interaction with terrain than I have currently (ie. any at all), I have been working on the entity/component system and the terrain entity to make them ready for that. I have also cleaned up some code here and there, but nothing that will show in screenshots. Expect that next week, when I’m going to finally implement unit placement for real. I’m also thinking of capturing my first ever game recording video of the results.

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.

Tags: Artillery Brawl, entity system

As I suspected, most of yesterday was spent snowboarding and playing board games, but today I have been working quite a lot on the game again. Specifically, I’ve been working on component-based entities. It was quite a big a change and it essentially had to be done all at once, so the game didn’t even start for the whole day. And now all I got is a black screen with the HUD (GUI) drawn on it, so something’s obviously wrong, but the hard part should be behind.

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.

Tags: Artillery Brawl, entity system

Got more stuff done today. I started on entity types with a type database, added a simple texture manager and again structured and consolidated lots of code. Entities are all the visual and/or physical objects in the world: at the moment the terrain, units and shells. Entity types define properties for entities, and entities can be created from entity types. Two different tanks would be two different entity types, two tanks of the same type would be different entities but the same entity type.

Before I can get this done though, I think I need to formalize entity components a bit. At the moment I’m just adding arbitrary attributes to entities, but I’ll need to keep track of them somehow. Physics- and gameplay-related attributes could be collected to their own components. With the flow I’ve been in for a good part of the week though, I don’t expect this to be a serious problem. Tomorrow will again be a bit busier in the real life department and on Saturday I’m probably going snowboarding with a few friends, but I’m still expecting at least some progress.

As a small statistics, the project has exceeded 1000 lines of code (including comments and empty lines).

Tags: Artillery Brawl, entity system

Ok, I’m all ready to start development for today. Today I’m going to focus on gameplay and playing around with physics assisted by Chipmunk. But first I’m going to write a bit about my plans for the game.

There are two major gameplay features and one programming technique I want to emphasize. Let’s get the dull technical one out of the way first. I wrote about component-based entities back in December but never got far enough with my “main project” to get anything actually implemented. I’m going to remedy that with this game and experiment with component-based entities. It’ll be a very useful experience for future projects and hopefully some readers. But more on that later as I start implementing that stuff.

And now the interesting stuff. The feature I most liked about my old artillery game was its modular weapon system I wrote about in my memoirs. I want to create something similar, but of course better this time. Maybe I could even let the players customize their weapons, we’ll see… The other feature is not really a feature, but a kind of a fixation of mine. In addition to sci-fi, I’ve always liked “pseudorealism”. Not simulation-level realism, but I’ve always liked stories and games that are not pure fantasy. In the artillery game, this was manifested as separate kinetic and explosive damage, drag for the artillery shells and other features more complex than usual for the genre. I have also always dreamt of writing a pseudorealistic shmup (shoot’em’up), so maybe that will be my next project…

And now, back to work!

Tags: Artillery Brawl, entity system, gameplay, pymunk

As I was finishing high level design of scene management, I realized it was starting to resemble the Model-view-controller pattern. The (hopefully) more or less final design is sort of a hybrid of the alternatives I already presented:

• Entities contain arbitrary data in attributes. These compose the Model.
• Entities can contain any amount of features; these are the controllers.
• Subsystems (for lack of a better name) link entity attributes to lower-level systems - such as the renderer, audio mixer and physics simulation - and thus represent views into the scene.

Features are normal tasks in the engine, based on cooperative multitasking. They can read from and write to attributes and create, trigger and listen to signals (an implementation of the observer pattern), which is how they communicate with each other. Subsystems also listen to signals to get notified of attribute changes. Attributes can be shared between features; for example transform is a common attribute probably used by almost all features and subsystems. Sharing of attributes is based purely on their names, there’s no actual cooperation between features and subsystems except for signals and of course documentation.

I think a rough example is in order again:

1. A ship gets hit, triggering the hit signal.
2. The damage controller feature is listening to this signal and gets notified.
3. Damage controller decreases ship health accordingly and notices it’s below zero: it adds a destruction sequence feature to the ship entity and stops listening to hit events.
4. Destruction sequence adds an audio source attribute to the ship entity (if it doesn’t already exist), spawns particle effects for a while and finally marks the ship entity for removal.
5. The audio subsystem notices the new audio source and adds it to the low level audio mixer.

What do you think? Input is still welcome, I haven’t actually started implementing this yet. And I still have at least a couple of open questions:

1. How should signals be triggered externally, for example by features in other entities? Should they just trigger the signals directly, or should there be an “external API” consisting of callable attributes?
2. Should features occupy named slots like attributes, or should they just reside in a generic list? I’m currently leaning towards the latter approach and reserving names just for attributes, since feature don’t have to directly know about each other.

I still have to design the rendering pipeline; I already have a general idea of what I want, but details are kind of blurry. But that’s the topic of another post.

Tags: cooperative multitasking, entity system, scene management