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:
1) 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.
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.
2) 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.
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.
3) 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.
I use a component for this
4) 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.
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 :-P
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.
If you want to "manage" something, alarm lights should start blinking, as that is a common starting point for multi-purpose almighty god-classes.
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?
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.
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.
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 ?
Completely agree!
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.
Thanks for the reply!
