Timeline for Getting Started with Component Architecture: DI?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 18, 2012 at 17:23 | comment | added | Sean Middleditch | The semi-formal definitions of entity systems around the Web essentially ban any "normal" OOP practices, even where you get no benefit from doing so. That's where the academic label comes in: entity systems are pushed as a magic solution with rigid rules. Some components should make heavy use of data-oriented design. Some should be super flexible. Some are just data containers. Some should be nothing but logic and behavior. Some games are best off without components at all, even. Solve problems; don't evangelize specific solutions. | |
| Oct 18, 2012 at 17:07 | comment | added | Sean Middleditch | Entity systems are about much more than just how data is laid out in memory. If that's all it was about, then it would just be a small extension to general component based systems. After all, there's nothing in the world barring "normal" component systems from making fantastic use of data-oriented design (unless you're using dumbed-down high-level languages, but then any kind of data-oriented design, entity system or no, is a pain in the butt with those languages). | |
| Oct 18, 2012 at 15:23 | comment | added | Mart | Second, entity systems are about as far removed from academics as you can get. The two ideas behind entity systems are flexible game objects and high performance code. Entity systems allow for high performance, cache friendly and easily parallelizable code through small and well-contained components that can be executed in succession, aiding cache utilization. This is a far cry from the academic world which still seems to believe computers are some magic entity capable of executing any type of code without any regards to actual CPU architecture. | |
| Oct 18, 2012 at 15:20 | comment | added | Mart | I'm going to have to disagree here on two things. -- First, game object "exist" both the entity system and the game object system. The same data is there, the same logic, the same behavior. The only difference is how the data is layed out in memory. Just because your high-level programming languages lets you describe data in terms of objects and their properties does not mean there is a fundamental difference. An object is just a bunch of data in memory that happens to be grouped together. "Methods" are just functions with some syntax sugar. Game objects are just as real in an entity system. | |
| Oct 16, 2012 at 17:15 | comment | added | Sean Middleditch | "entity systems" just take the general idea to an extreme. they in general remove the idea of a game object existing at all (instead relying on a database of components linked by a common id), generally tend to ban any and all logic in components (even for components whose sole purpose is to attach logic to a game object, like an AI component). it's just academia doing it's usual thing; taking a set of good rough guidelines and unnecessarily turning them into hard rules. | |
| Oct 16, 2012 at 9:20 | comment | added | Mart | I'm sorry, but what is the difference between what you describe and "entity system nonsense"? Especially since you yourself write: "It allows you to entirely remove the concept of hard-coded classes like NPC or Ship or Bullet and instead use a data file to define what components those classes are made up." How is this not an entity system? | |
| Oct 16, 2012 at 3:52 | comment | added | michael.bartnett | +1 Eloquently states what the rest of us failed to communicate. | |
| Oct 15, 2012 at 18:27 | comment | added | ashes999 | I think this is the answer I'm looking for. You seem to address several of my concerns, including my bad examples, and see "through" to what I really want to know. +1 | |
| Oct 15, 2012 at 15:48 | history | answered | Sean Middleditch | CC BY-SA 3.0 |