Timeline for State changes in entities or components
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 26, 2012 at 0:56 | comment | added | Sean Middleditch | @Byte56: Certainly it's good to be careful about dependencies. :) It's difficult to remove them entirely, though, especially for logic components (components whose sole purpose is to add game behavior). There's also many valid use cases for component based design where tight coupling makes sense; for example, physics vs collision vs triggers vs pathing vs animation etc. even with systems, physics needs to know which objects are colliding and their contact manifolds (not all objects which collide have physics, e.g. trigger zones, AI sensor cones, etc.). | |
| Oct 25, 2012 at 23:26 | comment | added | GriffinHeart | @Byte56 The Component has a pointer to its entity, and the entity allows to fetch its components. The PositionComponent is kind of a bad example, since its used by many components. One could argue it belongs in the PhysicsComponent but static objects don't need Physics. At the moment, with the Components i have there's no coupling besides the PositionComponent. | |
| Oct 25, 2012 at 23:19 | comment | added | House | @GriffinHeart How does the render component get access to the position component? Or the physics component get access to the position component? | |
| Oct 25, 2012 at 23:14 | comment | added | GriffinHeart | @Byte56 i have my entities calling update on my components, but not every component will need update. For example my Physics components does, but its a simple one that only deals with applying velocity and changing the PositionComponent. My RenderComponent doesn't need update it just signals the GameView that it was created and implements a Draw method that the GameView will call. | |
| Oct 25, 2012 at 22:26 | comment | added | House | @ViteFalcon Yes, that could work. It seems the OP is using events to make components talk to each other, so the in the event of adding the Build component the other components the event manager could change the other components as required. | |
| Oct 25, 2012 at 22:23 | comment | added | Vite Falcon | @Byte56: I think your solution is sound. But instead of the editor recognizing the 'Build' component to mean that collisions should be disabled, wouldn't it be easier if the 'Build' component's job includes disabling collisions on the entity if it has a 'Physics' component, like setting the attribute 'CanCollide' to false? | |
| Oct 25, 2012 at 21:43 | comment | added | House | OK, that's just my opinion. I think components knowing about each other is a bad way to go about it. The complexity increases far faster than when using systems to manage entities. However Asakeron raises a valid point and this method could get out of hand if you're managing the states for lots of different types of entities. | |
| Oct 25, 2012 at 21:29 | comment | added | Sean Middleditch | On a different note, your objection to the asker's approach is based on the assumption that all component based design must update components from separate systems (like an entity system design). That is one way to do it, but certainly not the only one, and there's no reason to dissuade such an approach for a game that has no need for cache-optimizing component update loops. | |
| Oct 25, 2012 at 21:26 | comment | added | Asakeron | @Byte56 If you need to handle state for other kind of entities, would you create other State components? | |
| Oct 25, 2012 at 21:25 | comment | added | House | Thanks for responding Sean. It's not really a magic component. It's a component like all the others. I think you mean it may not be used by different systems, but I would say that it would. Just in the answer I provided there are two systems that would utilize this component. | |
| Oct 25, 2012 at 21:21 | comment | added | Sean Middleditch | -1: This suggestion is to add a magic special component to track state (which will grow in complexity over time) that may or may not be used by different components and hence removes half the benefit of using component based design in the first place. | |
| Oct 25, 2012 at 21:19 | comment | added | House | It's polite to provide reasoning for downvotes. Thanks. | |
| Oct 25, 2012 at 20:50 | comment | added | Cypher |
I like the idea of a StateComponent that can be consumed by multiple systems.
|
|
| Oct 25, 2012 at 20:41 | history | edited | House | CC BY-SA 3.0 |
deleted 52 characters in body
|
| Oct 25, 2012 at 20:39 | comment | added | House | I'm saying both. I'm saying they should be unaware and trying to tailor my response to how I think you're handling components. When you say "Entity will call update on its components" it makes me believe that you don't have systems processing entities. I've removed the confusing language and just made it say systems. I was saying components because I was understanding that that is how you were updating. | |
| Oct 25, 2012 at 18:42 | comment | added | GriffinHeart | What you're saying is conflicting, first they should be unaware (which i agree) then you follow by having a component that is accessed by others. Can you clarify? I'm keeping components decoupled by the event system. | |
| Oct 25, 2012 at 18:37 | history | answered | House | CC BY-SA 3.0 |