Brainfold

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

Yesterday and this morning I’ve read a lot of material on various topics related to scene management, rendering and a host of other subjects. TomF’s Tech Blog was especially useful with rendering. I think I now have a relatively good idea about what I need in scene management and what features it should have. However, at the moment I’m torn between two designs, which are roughly equal to the first and third alternatives in my last post. I wrote small and rough examples on both to illustrate, and input would be really welcome at this point. The example is a space ship with an AI, a rigid body for physics, an audio source for positional sound, a particle effect for the engine and a turret, which in turn contain its own AI.

1. Data container entities with single-instance subsystems handling all the logic

ship = Entity()
ship.visual = ship_mesh
ship.rigid_body = ship_body
ship.logic = ShipAI()
ship.audio_source = AudioSource()
 
effect = Entity()
effect.visual = ParticleEffect()
effect.parent = ship
effect.transform = engine_transform
 
turret = Entity()
turret.visual = turret_mesh
turret.logic = TurretAI()
turret.parent = ship
turret.transform = turret_slot_transform

2. Feature (aka component) container entities, with all the logic and data contained in the features

ship = Entity()
ship.add_feature(ShipAI())
ship.add_feature(ship_mesh)
ship.add_feature(ship_body)
ship.add_feature(AudioSource())
 
effect = Entity()
effect.add_feature(Link(ship))
effect.add_feature(ParticleEffect())
effect.transform = engine_transform
 
turret = Entity()
turret.add_feature(turret_mesh)
turret.add_feature(TurretAI())
turret.add_feature(Link(ship))
turret.transform = turret_slot_transform

Which do you like more? In my opinion, the first option has the advantage of being perhaps more intuitive and clearer to use: you just assign features to attributes, whose name tells what they are for. On the other hand, the second interface depends less on magic and is perhaps easier to extend with new feature types, as there are no predetermined names for feature “slots” (in the first option, the names are defined by the subsystems that handle the logic of entities). Of course you could also use subsystems in the second option and “intelligent components” in the first option, but these two interfaces seem to fit those two underlying designs best, at least in my opinion.

If you have any questions or general comments about either of the designs, feel free to post them, all input is welcome.

Tags: code, entity system, scene management

Yesterday I stumbled upon my archives of old projects, and I felt a sudden breeze of nostalgy. Today I will take you along for a trip to my game developing past. My oldest games (or “gamelets”, as they were never really finished) haven’t survived. I remember a Mad Max -esque, text-based cab driving game and a space shooter similar to Star Control, but I don’t even remember their names.

Arty (1999) is my oldest surviving game, if you can call it surviving. Arty was an Artillery Duel clone written for DOS with the Watcom compiler; anyone remember the joys of DOS4GW? The code was horrible, since I had just learned C++, having programmed in C before that. I couldn’t get it to run (DOSBox might have helped, but I couldn’t be bothered) and couldn’t find any pictures, but here’s a peek at the jumbled mess of code, from particle system code (”smoke.h”):

void UpdateSmoke(long SmokeIndex)
{
Smokes[SmokeIndex].XSpeed/=(1+Options.Friction/2000.0);
 
Smokes[SmokeIndex].X+=Smokes[SmokeIndex].XSpeed
+Wind/500.0+((rand()%21)-10)/20.0;
Smokes[SmokeIndex].Y-=Smokes[SmokeIndex].YSpeed*(rand()%10)/10.0;
 
if(Smokes[SmokeIndex].X<0||Smokes[SmokeIndex].X>=SCENE_XSIZE
||Smokes[SmokeIndex].Y<0)
DeleteSmoke(SmokeIndex);
 
if(TypeBuffer[(short)Smokes[SmokeIndex].Y]
[(short)Smokes[SmokeIndex].X][0]==TYPE_GUN)
GunDamage(TypeBuffer[(short)Smokes[SmokeIndex].Y]
[(short)Smokes[SmokeIndex].X][1],
Smokes[SmokeIndex].Damage);
 
Smokes[SmokeIndex].Life-=(1+abs(Wind)/100.0);
if(Smokes[SmokeIndex].Life<=0) DeleteSmoke(SmokeIndex);
}

Despite being a huge mess, the game actually had some very nice features. Aside from cool-looking explosions, fire and smoke generated using “smoke.h”, it also had a fully flexible weapon system, where I could assign payload (”bombs”) to artillery shells. Bombs in the payload could have triggers (eg. impact or “I’m above a gun”), and explode generating new bombs etc. There was also separate concussion and kinetic damage; kinetic damage was based on the velocity of the projectile. Two of my favorite weapons were napalm, which burned a huge area for a while, and nuke, which was based on a series of different bombs, with the only piece of custom code being a screen flash when it exploded. Arty of course had fully destructable, random terrain.

As a curious detail, I had already started creating a game engine called Solid (revealed by a file called “solid.h”), though at the time only used for Arty. As soon as I realized Solid is quite common a name for absolutely everything, I changed the name to Spineless. Spineless was released as open source at the beginning of 2003.

The project Spineless was really meant for was mproject (2000-2004), a doomed, long-time sci-fi game project by a group of friends (yea, I have a thing for sci-fi). The M in the name stands for Master of Orion, which basically explains what the game was about. Btw, what actually prompted me to write this journal entry was that I had forgotten how far we actually got with it. Frankly, it wasn’t far at all, but I didn’t remember us getting even that much done. Here are some screenshots of the prototype. It’s actually much nicer looking in motion, since it’s exceptionally smooth.

sbproject (2004) was kind of a spin-off of mproject, focusing only on combat, á la Homeworld. In some far-fetched plans, it was to be the tactical combat part of mproject, but this project never really got off the ground either. A single image remains:

After that, I haven’t really worked on any games. I want to change that now, and it’s one of the reasons I killed Spineless; I want to try and concentrate on actual game programming for a change, instead of trying to make a game engine usable by other developers. That might be a side product of my endeavors, but not a major goal.

If you are interested in more details, prototypes or source code for any of the projects, please drop a comment!

Tags: Artillery Brawl, code, screenshots, Spineless