Dec 11 2007

Between designs

Filed under Game development by Jussi Lepistö

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: , ,

2 responses so far

2 Responses to “Between designs”

  1. Oliver Charles says:
    December 12, 2007 at 3:04

    Can you roll the two together? Python is a beuty for being so dynamic, so could you do something like:

    class EntityContainerThingy:
    def __setattr__(self, attr, val):
    self.features['attr'] = val

    def addFeature(self, feature):
    self.features[feature.__class__.name] = feature

    Now I know that doesn’t compile, and I can’t remember the exact python syntax off by heart – but maybe that would provide a pretty cool solution?

  2. Jussi Lepistö says:
    December 12, 2007 at 11:18

    Actually that’s a lot like the first solution I talked about, with the addition of the addFeature method. But yea, that could work. Too many options for the design, and no clear flaws in any of them, at least that I can see yet. :)