🔒 Locked

Component based objects

Started by trs79 Jun 19, 2007 at 11:27 PM 0 replies 650+ views

Original Post

Jun 19, 2007 at 11:27 PM

Hi, I'm trying to implement a component based system in my game. I have a human object, that will have components like location, visualization, skeleton, etc.. However, I also have ragdoll physics setup, such that there is a physics actor (typically with a capsule shape) for each bone in the skeleton. Now I could be wrong, but it seems that each physics actor should be an object. My question is, how should I setup the human object to work with the ragdoll physics? It seems that objects can't have other objects define them, only components can define an object, hence I understand this would work:


Object: Human
Component1: location
Component2: visualization
...

But I don't think I can do this (have objects within the object):


Object: Human
Component1: location
Component2: visualization
ObjectList: physicsActor1, physicsActor2, physicsActor3, etc.

The thing that is confusing me is each physicsActor in theory could be it's own game object, each with a position, visualization, etc. But maybe I shouldn't treat each physicsActor as an object, this has been driving me crazy. Thanks for any help. [Edited by - trs79 on June 20, 2007 10:07:41 AM]

Captain P

106

Captain P

Jun 20, 2007 at 6:56 PM

I'd probably create a managing class around these PhysicsActors, RagDollComponent or whatever name fits best. This manages a list of PhysicsActors inside. Comparable to why people use particle engines rather than manually managing a list of particles: it allows you to work on a higher level, and you can avoid code duplication - after all, Humans aren't the only objects with ragdoll physics, right? ;)

Anyway, I ran into the same issue, more or less: many game entities can be composed of more atomic entities, so where should you draw the line? I think there is a balance to be found there: you don't want only atomic entities, with absolutely no overlapping, since that means you'll have to do a lot more (repetetive) scripting. You don't want a specific entity for every situation either, since then you're hard-coding your game, totally missing the flexibility of a scripting system.

One thing you certainly don't want is to get stuck at such design issues. At some point, just choose what seems to be best, even though you're not happy with any of the options. If it's horribly flawed, you'll find out, and you'll probably see ways to improve it. At least you'll see what things you need to avoid. And if it works, well, be happy. :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.