# How can I position sprites in a Component-Entity engine?

I'm building my first component/entity engine and I'm not so sure about some of my choices. I'm here asking suggestions on my first doubt.

I draw objects with 2 different behaviours:

1. Position driven by Physics.

2. Position defined by other logics.

At the moment I've only built the first kind of object adding to some entities a Render component (which contains information about the sprite to draw) and a Physic component which contains body information. The Rendering system just attaches Render components sprites to the main view and the Physic System takes each entity that owns a Physic component and defines the sprite position for each entity.

Question 1)

Is it a valid choice to access (and modify) Sprites positions directly through the Physic System?

Question 2)

For the second type of object, should I manage the sprite position using a third component which is responsible only for that?

Is it a valid solution or I'm totally wrong?

I'm a bit confused about how to manage logic and positions with this kind of system... It seems a bit overwhelming to create a component for every behaviour that I need to define.

• You're worrying a little too much. Implement what makes the most sense to you, don't worry about following the Entity/Component system so closely (it's pretty loosely defined anyway!). If all objects that will have a position will also have physics, combine them, that's fine. – MichaelHouse Jul 11 '13 at 14:26
• I have RenderComponent (sprite), PhysicsComponent and PositionComponent, and render uses position to know where to draw, and physics sets position according to physics simulation. So Renderer doesnt know about physics, and physics doesnt know about renderer, but they both know about position (which is logical since you need position for rendering and physics). You dont need component for everything, but having component for position is a good thing (look at the unity for example, they have much higher level components then other ES, but they have TransformComponent) – Kikaimaru Jul 11 '13 at 14:35
• Great! This is a really neat way to create the architecture. Simple and loosely coupled. I suppose that you can add it as an answer. – MatterGoal Jul 11 '13 at 14:49