Timeline for Designing a component based game
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 17, 2011 at 19:38 | comment | added | void | While I agree that it's possible to implement it this way, I don't think it's a good idea. You designers cannot compose objects themselves, unless you have one über class which inherits all possible components. And while you can call update on just one component, it will not have good in-memory layout, in a composed model all component instances of the same type can be kept close in memory and iterated over without any cache misses. You are also relying on RTTI, which is something that is usually turned off in games due to performance reasons. A good sorted object layout fixes that mostly. | |
| May 17, 2011 at 19:07 | comment | added | Ali1S232 | and i agree there will still be a problem when he wants to have component which can share data but considering what he asked for i guess there won't be a problem for that, and again there are some tricks for that problem too that if you want i can explain. | |
| May 17, 2011 at 19:03 | comment | added | Ali1S232 | first of all the question asks for structure that every component instance is only related to one entity, and you can activate and deactivate components by only adding a bool isActive to base commponent class. there is still need for introduction of usable components when you are defining enteties but i don't consider that as a problem, and still you have seprate componnent updates(remember somthing like dynamic_cast<componnet*>(entity)->update(). | |
| May 15, 2011 at 15:37 | comment | added | void | Your solution is not really a component based solution as components are not separated from your game classes. Your instances all relies on the IS A relation (inheritance) instead of a HAS A relation (composition). Doing it the composition way (entities addresses several components) gives you a lot of advantages over an inheritance model (which is usually why you use components). Your solution gives none of the benefits of a component based solution and introduces some quirks (multiple inheritance etc). No data locality, no separate component update. No runtime modification of components. | |
| May 15, 2011 at 15:26 | comment | added | Ali1S232 | why did i get the down vote? what was wrong with my solution? | |
| May 13, 2011 at 17:50 | history | answered | Ali1S232 | CC BY-SA 3.0 |