Say I have, for example, a component InputMovement that describes an entity's movement speed in reaction to movement instructions from a player or AI. But now I want to add a removable, perhaps temporary, effect, like a status effect, which maybe slows down the movement speed or stops it entirely for a short time. Would it be better to put this effect data inside the InputMovement component, or have another component entirely to store the effect?
Also, I'm using Box2D in my ECS, where a component is reserved specifically to hold the Body information, and it performs well for Entities that have physical characteristics. But what about Entities that, say, don't need collision detection or kinematics, but still need position information to draw them? Is it better to create a separate Position component and have separate systems for handling rendering with Position and rendering with Box2D? Or should I use Box2D for all situations where I need position data, except that some data regarding fixtures and such is left out?
Entity component system designing
Not sure about
handling rendering with Position and rendering with Box2D?
Everything thats drawn needs to know where it should be drawn, typically a physics engine feeds its transform (pos/rot/scale) data to the object being drawn (I imagine box2d is similar although i admit ive never used it). Assuming this, then an object that gets drawn has position/rot/scale data, and an optional "physics" component which would update that objects data each frame based on the simulation.
If it doesnt have physics component it may be animated in some way (animation component?) or simply driven by a player, or by animation and physics components which talk to each other, or by all.
Specific components would be maintained by the systems they logically belong to, rendering, physics, animation. The trick is getting components to talk.
With entity systems Ive read lots of different ways it can be done, so I wouldnt say there is a hard rule, but from what you said, this is how I see it.
Say I have, for example, a component InputMovement that describes an entity's movement speed in reaction to movement instructions from a player or AI. But now I want to add a removable, perhaps temporary, effect, like a status effect, which maybe slows down the movement speed or stops it entirely for a short time. Would it be better to put this effect data inside the InputMovement component, or have another component entirely to store the effect?
There isn't a strong "better" here. Do whatever you think works most easily and logically for your game. One option is to have InputMovement query an Effects component to see if anything is modifying movement. A second option is for InputMovement to keep all the local effect state relevant to it and to have the Effects component apply modifications to the InputMovement component. Yet another option is to construct a MoveParams object, send out a PreMove message with a reference to it, let any other components interested in that message modify the struct as they desire, and then after the message is handled the InputMovement component does what it needs. Still yet another way is to decouple InputMovement from Movement (you'll have AI controlling movement too, for instance) and to let both player input, AI, physics, and effects all interact with the single Movement component.
No one approach is better than the others. They all depend on your game and architecture.
Remember, ECS is not the be-all/end-all of game architectures. It's just one approach to using game object components which itself is just one way of structuring your game objects. Don't try to shove all of your thinking and all of your module design into the ECS mold if it doesn't seem to fit naturally in your head.
Also, I'm using Box2D in my ECS, where a component is reserved specifically to hold the Body information, and it performs well for Entities that have physical characteristics. But what about Entities that, say, don't need collision detection or kinematics, but still need position information to draw them? Is it better to create a separate Position component and have separate systems for handling rendering with Position and rendering with Box2D? Or should I use Box2D for all situations where I need position data, except that some data regarding fixtures and such is left out?
A Transform component (position, orientation, scale, etc.) is a fairly common approach. More complicated engines may need even more intricate approaches to deal with threading. Updating positions can seem like it'd be one of the bigger bottlenecks in game engines, but it's highly unlikely to be one (especially in an indie/hobby game). Again, do whatever you find easiest. When you start running into performance issues, proper investigation will likely reveal that it's due to non-optimal graphics code or thread code (or a lack of threading), not how you manage position updates.
Also, I'm using Box2D in my ECS, where a component is reserved specifically to hold the Body information, and it performs well for Entities that have physical characteristics. But what about Entities that, say, don't need collision detection or kinematics, but still need position information to draw them? Is it better to create a separate Position component and have separate systems for handling rendering with Position and rendering with Box2D? Or should I use Box2D for all situations where I need position data, except that some data regarding fixtures and such is left out?
I would make your Components independent of your physics library for this reason. Just have a Position (or Transform) component. And then entities that are involved in physics calculations will also have a Physics component that describes how they behave wrt to physics (e.g. collision category, mass, collision shape, etc...). It should be the job of one of your systems to step your physics world, and then update the values in the Position components from the results of the physics simulation.
Rendering code should be completely ignorant of whether an entity has a Physics component.
