Timeline for Component / Entity-based design => no inheritance at all?
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Jan 6, 2013 at 16:44 | history | suggested | Gustavo Maciel | CC BY-SA 3.0 | Fixed broken link |
| Jan 6, 2013 at 16:12 | review | Suggested edits | |||
| S Jan 6, 2013 at 16:44 | |||||
| Jan 6, 2013 at 13:46 | comment | added | Philip Allgaier | I feel that we are still on topic, but accept that this is growing into a lengthy discussion which is not desired on SE. | |
| Jan 6, 2013 at 13:12 | comment | added | Engineer | @PhilipAllgaier. We are now drifting way off topic. I have long since answered your architectural question, yes? Do you want me to write all your code for you? Your implementation specifics are not our concern here; if you had posted a question asking for help with implementation specifics, it would have been voted on for closure by the mods, as such questions are not a good fit for the Q&A/knowledgebase format of this site. I'm sorry, but you're going to have to either accept this answer, or wait for other respondents. Asking question after question is for chat, or a discussion forum. | |
| Jan 6, 2013 at 13:10 | history | edited | Engineer | CC BY-SA 3.0 | added 24 characters in body |
| Jan 6, 2013 at 13:00 | comment | added | Philip Allgaier | I am doing that ATM, so when I testwise create a worker it gets both components: person and employee. So upon runtime, I can access one from another via some generic helper function [code]template<typename T>T* getSiblingComponent() { return m_pEntity->getComponent<T>(); }[/code] But soon those entities will be created in a data-driven approach = read from XML files, so I cannot guarantee that worker always has both components. | |
| Jan 6, 2013 at 12:55 | comment | added | Engineer | @PhilipAllgaier As I said in my earlier comment (which I since removed). You need to do depenency injection in your factory methods / classes, post-construction of your entity instances and all their required component instances, but before initialisation of key data values required at runtime. | |
| Jan 6, 2013 at 12:49 | comment | added | Philip Allgaier | I am not talking about updating another/reading from another entity, but another component within the same entity. For example Entity A represents a simple Worker and has the components Person and Employee. When updating its 'Employee' component, we realize that as a result we need to change a value in its 'Person' as well. There won't be any Entity in the project that has component 'Employee' but not 'Person' because one requires the other (added new note for that in the question). If there was this inheritance connection, we would manifest that at compile-time. | |
| Jan 6, 2013 at 12:36 | comment | added | Engineer | @PhilipAllgaier The point I was getting at in my editions to this answer -- particularly the final paragraph, was ultimately that no -- you don't have to check to see if anything exists. You should never be doing that. You should have received a direct reference to some other entity, back from some mechanism such as a faction list scan or a collision operation. | |
| Jan 6, 2013 at 12:31 | history | edited | Engineer | CC BY-SA 3.0 | added 53 characters in body |
| Jan 6, 2013 at 12:30 | comment | added | Philip Allgaier | Additionally: I agree that with those classical "technical" components such as Physics, Rendering, etc. there should not be any inheritance. The inheritance I am considering would only evolve around "data" components in terms of archetypes, much like your health and mana example. | |
| Jan 6, 2013 at 12:29 | comment | added | Engineer | @PhilipAllgaier Indeed. But I wanted to warn you about synchronisation issues. Question has now been edited. Let me know if that addresses your concerns. | |
| Jan 6, 2013 at 12:28 | comment | added | Philip Allgaier | So you are proposing that I create some sort of DeltaManager that during an update run caches all requested property changes that a component A (that is currently processed) wants to make to component B. Once all components have been updated, go through the DeltaManager and actually carry out the changes? If so, I see the issue that perhaps a subsequent change made by component C to component B might still be queued in although it doesn't make sens after the first update anymore. So my DeltaManager would also need to be able to handle conditions -> lots of extra complexity. | |
| Jan 6, 2013 at 12:25 | history | edited | Engineer | CC BY-SA 3.0 | added 845 characters in body |
| Jan 6, 2013 at 12:18 | comment | added | Engineer | @PhilipAllgaier I am editing my answer, as I feel we are talking at odds. | |
| Jan 6, 2013 at 12:13 | comment | added | Engineer | @PhilipAllgaier Are you sure you want be accessing other entities' components directly during an update? In my experience that leads to potential synchronisation issues. If anything it is safer to update a global model of some sort, and apply changes to other entities at the end of the tick, or on the next tick, by inspecting those cached deltas. | |
| Jan 6, 2013 at 12:08 | comment | added | Philip Allgaier | I was aware of that article, as I read pretty much everything I could find on that topic so far :) . So basically you are saying that I should stick with my current approach as described in my question (which basically is what Mike preaches), that if I need to get/set data in another component than the one processed right now, I have to check whether this sibling exists and if it does, then do the change. | |
| Jan 6, 2013 at 12:03 | history | edited | Engineer | CC BY-SA 3.0 | added 49 characters in body |
| Jan 6, 2013 at 11:57 | history | edited | Engineer | CC BY-SA 3.0 | added 11 characters in body |
| Jan 6, 2013 at 11:52 | history | edited | Engineer | CC BY-SA 3.0 | added 3 characters in body |
| Jan 6, 2013 at 11:46 | history | answered | Engineer | CC BY-SA 3.0 |