I'm remodeling my entity engine. My old one was just an ArrayList of entity inheriting objects, but it got real messy, real fast.

How do you guys go about it?

I saw something about hierarchies on the interwebz but I don't know how they work or what they are for :p

Give me long detailed opinions! Thank you

“Life is pretty simple: You do some stuff. Most fails. Some works. You do more of what works. If it works big, others quickly copy it. Then you do something else. The trick is the doing something else.” ~Leonardo da Vinci

cause performance should not matter that much for an entity system I prefer a less verbose and bloated system then entreri.I took a look at the sources and it was just to much of configuration and setup.

One should perhaps write an entity system in an own DSL with scala, because I think one could come up with a lot of syntax sugar and it is then also easily integratable to the other game code in java

As opposed to an entity system which forces you to branch of entities which could have similar properties, a component based entity system allows an entity to implements certain functionality instead of everything above in the hierarchichal ladder.

for example a monster could implement this functionality: attackable, interactable, living. instead of just branching down through: entity>living>attackable>monster etcetera.

There's been a fair bit of discussion of the Component model on these boards, most of it negative. Although I had a lot of initial enthusiasm for them early on, the more I worked with them the less that I had. Although there are many flavors of Component systems most involve a system where you have a GameEntity which has no functionality other than to add/remove components. All Entity behavior resides in Components which can be dynamically added/removed as the game runs.

My main issues are that this provides far, far more flexibility than I need (and that most hobby game devs need I suspect). This flexibility requires more complexity and makes things more difficult to reason about.

An approach I prefer is just have entity behavior within in entity specific classes (FighterJet, Missile, etc) and to use the Strategy Pattern for cases where I have related and/or shared functionality.

You are giving up some of the "dynamicity" of the E/C model (which I don't need any how) while still getting the benefits of a favoring aggregation over inheritance while working with a simpler set of code over all.

It's worth noting the difference between "component-based programming", which is simply composition within in an otherwise static object model, and "component systems" which assemble components at runtime. Unless you're writing some kind of engine, you probably don't need to even consider the latter.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org