Here’s my second article, it’s on managing game entities!
http://www.gameprogb…aging-entities/
Thanks for any input!
Your link is broken.
Ah, thanks!
Nice tutorial. Nice ideas. Basically the same as my implementation, so I have nothing to add.
The problem is that managing entities is a trivial task that depends on basic programming skills. If you can’t do it, you either shouldn’t be programming, or you should learn things in the correct order.
So writing a tutorial attracts n00bs of which some may even fail to follow this and start complaining.
It shouldn’t matter though. Do what you feel like.
Hence why I include source code and an applet ;D
Thanks for the input.
Some thoughts:
Less and more common colors would make the code more readable.
To me, class responsibilities are not clearly defined but mixed up a bit:
EntityLayer should not inherit from EntityList, but use one
Describe the benefit of classes EntityLayer and EntityLayers, why can’t single entities be invisible or disabled ?
Why does EntityList has methods like draw and update, instead of just iterating through the list and calling those methods on entities ?
EntityLayers looks pretty well-designed where it’s using an enum type parameter as an ordering trait. Making it an Entity itself however, does seem rather off.
Thanks!
What don’t you like about this?
They can, it’s up to the Entity implementations whether they have a visible/enabled flag. I used to have setters/getters in Entity for those properties but realized not every entity needs these.
That’s exactly what it does.
What don’t you like about that?
Old story of inheritance vs. composition.
Single responsibility principle.
It is inflexible, exposes implementation details (stuff is always stored in a list). List is rather, or should be, a collection class, layer is part of the entity domain. To me, looking further to Entitylayers (an entity itself) makes it quiet confusing.
Furthermore, EntityList has a dependency to Graphics2D, all in all making it homeless child of three application responsibilities / tasks:
- utilities, collection classes
- model (the game entities)
- visualization (hard bound to Java2d graphics stuff)
I guess it depends on what you define as a responsibility, I consider “managing entities” the responsibility of EntityList, I think breaking it up just to break it up is silly and a more separated design uses more memory and is less efficient.
Having said that, I would remove EntityLayer and have EntityLayers just maintain an array of EntityLists directly. EntityLayer is a pointless class.
Also, this is a code example and not a game engine. In my game engine I don’t have dependencies on specific graphics libraries and everything is well decoupled compared to the article’s code.
Perhaps I don’t understand how you would structure your game, how would you do it and what parts of your structure do you feel are superior? I have always had this sort of design, and I haven’t seen anything else, so I’m having problems thinking of alternative architectures.
Thanks again for your input, I enjoy the back and forth - I am always up for learning new things.
Like with game-loops (and everything else) there is no one-design-that-fits-all scenarios. I won’t attempt to address 65K’s views, but all toss out a small subset of issues:
- composition can lead to cleaner and/or more flexiable design…given certain game design requirements and how the principle programmers brains work. For instance some folks like the prototype based notion of “component-based” (one method of data-oriented) and I’m a fan of the hybrid prototype/open-class based notions that I poorly & half heartedly attempt to explain here: ArchTypes, composition and code is data. A combination of the game-design and how the main programmer’s “see” code should partially dictate how the entity-system is constructed. And this is somewhat ignoring using a DSL and/or an actor/continuation model.
- Multi-threading: depending on how task are segregated between threads (should) effect how the entities are composed. Basically data that is manipulated together ideally should live together.
- Queries: The raw number of “active” entities and how they are distributed through-out the game world should heavy impact how the runtime entity database in constructed…some linear list like, spatial partitioning, etc.
- Memory accesses: Similar to the multi-threading issue & coupled with queries - if the number of active entities is high enough, it can be important to segregate data into (say) a flattened list inside some spatial partitioning for instance.
If you want to “manage” something, alarm lights should start blinking, as that is a common starting point for multi-purpose almighty god-classes.
Let’s say you implement a super-clever highly efficient entity list class. One day, you decide to develop a little game for Android. As the dalvik engine is not as good as a real Java VM, you think that the entity list stuff comes in handy… too bad only, that Android has no Java2d package.
Who cares, you say, lets hack together a multiplayer client/server game instead. But that entity list has a dependency to the graphics sub system, does it make sense for the server backend ?
You break things up to develop more efficiently, to reuse stuff, to ease testing, to get more stable programs. There is no (relevant) impact on memory usage just from doing so.
My game engine is designed this way, I have simple state data in my entities and I have several components that can be used for an entity… one for attaching particle effects, one for steering behaviors, one for pathfinding, one for spatial databases, etc.
I don’t think the design of the tutorial’s code is anti-multi-threading whatsoever, it all depends on how you use multi-threading in games. The most I’ve personally used is a thread to load data in the background. Even if I used threading in games, it would be a simple “pop request on queue” and the thread would listen to the queue, solve the problem, and put a response on a queue for the main game thread to pick up.
I use a component for this
Not quite sure exactly what your talking about.
If you want to provide code examples if you still disagree with me, it’s far easier to understand code examples then read someones explanation… words have too many meanings, code is the best means of communication 
I have no idea how else I would structure entities other than a list or linked structure, maybe a code example on how you do this?
The code is easy enough in the tutorial for you to break out Graphics2D yourself, my game engine follows with what your saying, I have no dependencies on anything in Java, and no dependencies on graphcis libraries, I’ve pulled out the dependency by creating a simple MVC framework.
Completely agree!
Thanks for the reply!
My commentary was a generalized play on 65K’s comment and not directed at your tutorial.
Ah okay, thank you.
My point was that problems could start if “manage” gets a too broad definition.