Categories
entity systems MMOG development

Using an Entity System with jMonkeyEngine (mythruna)

If you’re interested in using an ES on indie projects, and you’re craving concrete examples, you might want to look at the comments (page 1 and page 2) on Mythruna:

“Since this is a developers forum, I’ll describe a little bit about what went on behind the scenes.

During the early development for this phase, I read about an architectural pattern called an entity system.

I had (pre Entity Systems) a plan for how I was going to store the placement of objects in the world but this past weekend when I actually got to implementing it, I couldn’t make that original plan work and came to the point where I needed to solve the general problem of world state storage. This is the kind of thing that Entity Systems make relatively straight forward… and by Saturday, Mythruna had an embedded SQL database that autogenerates tables based on the components stored. (HyperSQLdb for the win.)

So at some point I swapped out the in-memory version of the entity system with the SQL version… and suddenly objects were persistent. It was so easy I had to double check a few different ways that it was actually working. :)”

…but of course, also: use the Entity Systems wiki – put your questions there, put your ideas there, and (most of all) if you have an ES project or ES source code you want to share, please add it to the wiki!

10 replies on “Using an Entity System with jMonkeyEngine (mythruna)”

Good to hear things are spreading in the Java world. :) I’m still barreling towards release and look forward to getting my efforts out and continuing the ES saga. ;) Some of the more neat things that will be there on launch with my entity system are replication by prototype, “derezzing” / recycling of components / systems when an entity dies / goes away; new entities even of a different type / mixture of parts reconstitute from recycled components / systems, and dynamic injection / extraction of data into child components / systems of a component manager (an entity is such, but I’ve generalized the concept further and almost everything is a component or system, but attached to application container or activity container for Android). In this case the entity reference is conceivably injected into components / systems that need access to it and extracted when the component / system is removed from the entity. This is for nested components / systems too any level deep. All of this running with no memory allocation overhead and reasonably fast. Still a bit to do with the total framework component architecture, but I’m shooting for a release before the end of summer.

The core part of my efforts (containers, component architecture / interfaces) will actually be released via the GNU Classpath extension and I’ve decided to include the base entity system in this bundle, so it may be used in others work unencumbered. :: clackity clackity ::

Neat. It’s interesting to see what I find when googling myself. :)

I got a lot out of the articles on this site and the discussion in the comments. I went from “This can’t work.” to “Wait, how does this work?” to “OMG, how could I possibly do it any other way?” :)

PSpeed, I see that your approach doesn’t have an entity table, just the referenced id on each component table. Doesn’t this gets messy when you have to delete an entity?

It doesn’t matter, actually. A central entity table doesn’t help with deleting… it’s just another table that needs to have a record removed.

I suppose I could setup foreign key constraints across the component tables but that’s extra overhead for a relatively minor use-case. My entity system already knows about the components so it’s easy to remove them all. And it keeps interdependence to a minimum.

Also, while I do actually have a removeEntity() on my entity system and while I do actually use that in one place, part of me thinks it’s wrong to whole-sale delete an entire entity. After all, which system should have such authority over all of the other ones… and a single system really only cares that the entity no longer has the components that interests it. It’s effectively removed from their perspective when those components go away.

So, when someone gets killed you don’t remove all components from it?

How do you identify entities like monster,player,weapon (do you have a component you use like a tag or define a group, what is the approach)

(First note that Mythruna NPCs are only on paper at this point but I’m going to use your example anyway… I could have also discussed objects and blueprints and it still would work.)

Entities don’t really need a tag like “monster”. That would be like a class in OOP. Entities have components that give them behaviors through systems that are interested in those components.

So if an entity has a model, a position, and an AI that makes it attack things… it is a monster of some kind. If it dies, it probably still has a model and a position until it decays but the AI behavior component can be removed. If it decays then its model component can be removed… and maybe it’s position (though it would be unrendered if there is no model and maybe you want to remember where it died).

At that point, as far as the player is concerned the monster is dead and doesn’t exist anymore… but there is no reason to arbitrarily flush all of its other unrelated components in a “delete” operation because maybe they are still useful to some other system.

If some state puts those other systems in a point where they delete their components too then it is deleted from their perspective. If all systems do that to all components then entity doesn’t exist anywhere anymore.

But a global removeEntity() feels more like an admin function to me… and even then I suspect a real MMO would leave a few components on it. If nothing else they’d probably leave the tag of the admin that deleted it.

Valid points, but there will be cases where you need to distinct entities with the same components(maybe a system that runs on orc warrior and another on orc greatwarrior)

If they have the same components then you don’t need to tell the difference. The same systems will operate on them.

In your example, if there is a difference between an Orc and an Orc Chieftain to some system… then it would be reflected in a component somewhere. Either in the value of the component data or in the type of component being present or absent.

Comments are closed.