Entity Framework

[Spacebeans]

I’m working on my game engine, and I need a way to add entities. There needs to be a way to attach one to another, (Like a light, and a gun to a character). I was thinking of maybe just having two different types of entities, World, and UI. World entities are lit, and rendered before UI entities. UI entities cannot be lit, and can be attached to world entities for health bars and such.

I was also thinking of maybe having a “root” entity that all of the entities can attach to. Then, you can specify rotation, scaling, and translation for the root. Without having to deal with pesky screen shake caused problems.

But basically what I’m asking is that if you were to make a entity framework with a nice working and learning curve, how would you do it?

[wessles]

Artemis 8)

[Spacebeans]

Not exactly what I was looking for. I need something to work closely with JBox2D, lighting (material framework), and possibly some kind of level editor and saving through XML.

Edit: I mean something to implement myself, and how should I do it?

[wessles]

I don’t know if you’ll find anything that specific.

[Spacebeans]

Yeah, that’s why I was going to design my own. I was looking for tips on how it should play out.

[wessles]

Oh crap >:(. I completely read that wrong.

If I were to go about entity frameworks, I would keep the following in mind:

• All entities should be able to hold an infinite amount of other entities.
• All entities should have a shape, and location relative to a parent.
• All entities should be able to access all other entities, relative to itself or root.
• All entities should have an entry on a ‘pecking order.’ Rendering and updating should NOT be done with a tree structure. For example, a particle emitter that has a parent entity should render below the parent. Thus, it cannot be rendered with a tree format, as that would render it after the parent.

Which brings me to the pecking order. You need a floating point value for each entity on where it is to be rendered and where it is to be updated. The parent to the emitter would be 0, and would be the first to be rendered/updated, while the emitter is 100 and will be after.

If you follow these rules as a bare minimum, it could work out just fine.

-wes

[PandaMoniumHUN]

Rolling your own entity framework can vary from being trivial to being extremely complex depending on your needs.
One thing that you should think about is whether or not you want to reuse that entity framework that you make. In case if you just want to make it for a specific game with specific use cases you can pretty much custom tailor your entities so they can all have the properties you need for your current project (box2D shape, material, etc.) with direct XML loading/saving.
If you want to reuse it then obviously you’re going to have to make it a bit more generic than that. I’m not gonna give advices for that since wessles already included most of the important points. Take a look at already existing entity frameworks’ source code and get “inspiration” from there.

[junkdog]

@Spacebeans

I was also thinking of maybe having a “root” entity that all of the entities can attach to. Then, you can specify rotation, scaling, and translation for the root. Without having to deal with pesky screen shake caused problems.

But basically what I’m asking is that if you were to make a entity framework with a nice working and learning curve, how would you do it?

Entity system frameworks typically don’t have different kinds of entity types, only different component compositions making up the entities. The seminal series of articles on entity systems is still Adam Martin’s Entity Systems are the future of MMOG development.

@wessles

Artemis 8)

Vanilla artemis shouldn’t be used anymore - it hasn’t been in development for a long time and has plenty of bugs. Use one of the many forks floating around, if you like artemis’ API - such as mine or gdx-artemis.

[Spacebeans]

@wessles

If I were to go about entity frameworks, I would keep the following in mind:
Which brings me to the pecking order. You need a floating point value for each entity on where it is to be rendered and where it is to be updated. The parent to the emitter would be 0, and would be the first to be rendered/updated, while the emitter is 100 and will be after.[/li][/list]

-wes

… Like an ID system? (Keep in mind, this is in 2D with the depth buffer, so I could have things rendered in layers)

[wessles]

Don’t do layer-rendering, kids.

By pecking order, I could also mean what order you update things in. But the Z-Depth can be used as well, just set it to the pecking order number 8).

[BurntPizza]

Coincidentally, artemis-odb just had it’s 0.6.0 release today : http://www.reddit.com/r/gamedev/comments/27mwnw/artemisodb_060_released_entity_system_framework/

If you wind up rolling your own (not really recommended IMHO), then you might like this pseudo article/tutorial: http://gamedev.stackexchange.com/a/31491

[ags1]

@wessles

Oh crap >:(. I completely read that wrong.

All entities should have an entry on a ‘pecking order.’ Rendering and updating should NOT be done with a tree structure. For example, a particle emitter that has a parent entity should render below the parent. Thus, it cannot be rendered with a tree format, as that would render it after the parent.

Which brings me to the pecking order. You need a floating point value for each entity on where it is to be rendered and where it is to be updated. The parent to the emitter would be 0, and would be the first to be rendered/updated, while the emitter is 100 and will be after.

A float pecking order feels wrong layered on a tree (and very fragile), and I don’t think your statement that a specific rendering order is implied by a tree is true. You can after all choose to do breadth-first or depth-first traversals of the tree, and you can have properties defined on the nodes that influence the rendering order.

But also, why have the rendering tree be the same as the entity model? The entities should “just work” regardless of how (or if) you render them.