Dysnomia Games Game design, problem solving, graphics and audio


Object Models in Component Entity Systems

The main approach I'm currently playing with in Component Entity Systems (CES) is Components systems (ComponentType) handle functionality and instantiation.  Components themselves wrap functionality around data in the ComponentType pool.

The question I'm often asking myself:

are there any advantages to storing all Entity data in one place? (effectively building a custom dynamic object model on top of C++)

So currently each ComponentType has a pool of Component data which it hands out appropriately (the Component class merely points to this data).

eg. the PhysicsComponentType contains a pool of { vec3 pos; vec3 vel } structs which are doled out when its create() method is called

However another approach I've been mulling over would be to extend the system so that EntityTemplate objects handled the pooling and blocks were created containing that template's component order.

This would create contiguous blocks per Entity so all component data was within the same area of memory, but causes hits when you need to change the Entity in question (say, removing one AI component and placing another which contains a different amount of data).  These 'hot-swaps' would require moving the whole Entity block out of the pool and into a new pool based on the destination template.

All of this is only necessary if you'd prefer having constant size block pools, which are mostly good for cacheing and a few other speed concerns, so the tradeoff may not be worth it.

Only profiling in a live environment will really answer this one though..

Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

Terrible Turing Test *

No trackbacks yet.