Timeline for "The Game Object" - and component-based design
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 23, 2012 at 20:20 | comment | added | Michael | It does move the problem around but to a place that is more tenable. Systems have their relevant components hard wired. Systems can communicate to one another through Components (StateMachine can set a component value that Animation reads in to know what to do (or it could fire an Event). The dictionary approach sounds like the Properties Pattern which can also work. The nice thing about Components is that related properties are grouped together and they can be statically checked. No bizarre errors because you added "Dammage" in one place but tried to retrieve it using "Damage" in another. | |
| Jan 23, 2012 at 18:14 | comment | added | ADB | This just moves the problem around. How does a system knows which components to use? A system could need other systems as well (the StateMachine system might want to call for an animation for example). However, it does solve the problem of WHO owns the data. In fact, a simpler implementation would be to have a dictionary in the game object and each system creates his variables in there. | |
| Jan 20, 2012 at 5:08 | comment | added | Jake Woods | As far as I understand it all entities do not share the same component, each entity can have N component instances attached to them. A System then queries the game for a list of all entities that have component instances they care about attached to them and then does whatever processing on those | |
| Jan 20, 2012 at 1:27 | comment | added | hayer | Okey, now I'm really lost.. "By contrast, in an ES, if you have 100 units on a battlefield, each represented by an Entity, then you have zero copies of each method that can be invoked on a unit – because Entities do not contain methods. Nor do Components contain methods. Instead, you have an external system for each aspect, and that external system contains all the methods that can be invoked on any Entity that possess the Component that marks it as being compatible with this system." Well, where is data in a GunComponent stored? Like rounds, etc. If all entities share the same component. | |
| Jan 19, 2012 at 21:04 | comment | added | Patrick Hughes | This ends up being a nice way to handle the problem: Components represent properties while Systems tie together disparate properties and use those to do work. It's a huge shift away from traditional OOP thinking and makes some people's heads hurt =) | |
| Jan 19, 2012 at 18:04 | history | answered | Michael | CC BY-SA 3.0 |