Timeline for Component communication in Component-based design
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 12 at 4:23 | comment | added | Dustin Weitkunat | Well it sounds like you've achieved having separate components, but it's the new entity being spawned that's causing the issue. You won't get around having some kind of communication here. What you can do instead of ScriptableObject communication is a singleton event channel that any component can call to fire events. Have your unit invoke a UnitDied event that takes an argument for itself, and have other things subscribe to this unit. You keep a layer between everything this way. Basically the message bus, as you were saying. | |
| Mar 11 at 19:21 | comment | added | Black Dice | so, essentially, the problem is that from one perspective this behavior must be "atomic", but from the other perspective I would like to split this functionality in pieces and maybe reuse them in other places, as they don't exactly need to know about each other. I think that I miss some concepts here. | |
| Mar 11 at 19:19 | comment | added | Black Dice | correct, 'zombie' will spawn on top of the corpse, and I expect physics/vision/other components to be unregistered before it happens. to be precise, I have a unit object that has a health component, a physics component, and a vision component. I'm trying to make it so they don't know about each other. when health is depleted, I need to disable these components before any other reactions (e.g. zombie). and I have two ways here - to make it through message bus (which leads to my "ordering" problem) or to make these components explicitly know about each other to react before other reactions. | |
| Mar 11 at 18:56 | comment | added | Dustin Weitkunat | If I understand, you need to spawn a zombie on top of a 'corpse', but you don't want this happening until the physics for that 'corpse' is disabled, so that multiple colliders don't occupy the same space? Perhaps a tighter coupling on the unit with its physics is warranted, then. Have the unit handle disabling its own physics. There won't be direct dependency, since each component is only concerned with itself, but the unit will be able to disable the physics on itself. Let me know if I've understood you. | |
| Mar 11 at 18:49 | comment | added | Black Dice | I really like this approach. However, I have one concern with it. For example, I have a health component, a physics component, and a vision component on my unit object. Also, there is another unit, that has a passive ability - each time when someone dies - he spawns a zombie on the place of the victim. how can I ensure the right order of handlers here? if the physics will not be disabled at the moment when the zombie will try to spawn, I will not allow that, because this place on the map is still occupied | |
| Mar 11 at 17:58 | vote | accept | Black Dice | ||
| Mar 11 at 3:47 | history | edited | Pikalek | CC BY-SA 4.0 | added markdown to code in text |
| S Mar 10 at 23:51 | review | First answers | |||
| Mar 11 at 3:47 | |||||
| S Mar 10 at 23:51 | history | answered | Dustin Weitkunat | CC BY-SA 4.0 |