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 
Give me long detailed opinions! Thank you 
My entity system even varies between projects 
I usually don’t even get that far. xd I’m using Artemis for one of my projects and that’s working really well for me. Its site seems to be down though…
I use this one: http://bitbucket.org/mludwig/entreri
It has a little more overhead as far as defining components, but it scales better and is more performant.
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
I mostly use component systems these days.
Could you please explain, what that is? 
I’m intrested…
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.
Component based is one composition design model of which there are as many as you’re brain can come up which has become a fad.
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.