# Movement & Physics in an entity-component system

I'm currently playing around with entity-components systems and got started on the movement/collision/physics parts and would like to have some pointers!

It's a basic 2D sidescrolling game, with the goal being something in the style of Terraria. My first goal was to have a character that could run left/right & jump on blocks/tiles and when clicking tiles they'd disappear.

At the moment, each tile/block on the screen is an entity with a Transform(Position) component, a "Renderable component and a Collision component (boundaries)

My player has a Player component(tagging class), a Transform, Renderable, and Physics (velocity, acceleration, mass) and Collision component.

Currently a bit stuck on how to fit in the physics and movement. I read the threads I could find about it here on Stack but left with some questions:

1. What would be a good approach to let my character move? Should I have a player system that updates the Player's position or velocity? Or should I let it set a state & let another system update the movements of entities based on their velocities and their current state? Leaving the option open that I could move a character by clicking somewhere?
2. If I were to add gravity, should these affect your acceleration/velocity? I have problems with figuring out how to implement acceleration & which systems could/should be responsible for that..

And unrelated to the questions above, when I was starting on the collision I ran into the issue that it would try to check every single tile against the player & since on a large resolution already 1000ish entities fill the screen it quickly sent performance down the drain. I implemented a quad tree to select the entities only around the player, which seems to work. (Based on http://www.mikechambers.com/blog/2011/03/21/javascript-quadtree-implementation/ but made it from scratch in Python).

But since it takes the current window size as dimensions once the player would move off screen, the entities wouldn't add correctly anymore. Should I let the Quad Tree grow/shrink in certain directions? (If anyone has experience with using this?)

What would be a good approach to let my character move? Should I have a player system that updates the Player's position or velocity? Or should I let it set a state & let another system update the movements of entities based on their velocities and their current state? Leaving the option open that I could move a character by clicking somewhere?

I would create an input component and various other action components, like walk, jump, crawl, weapon, etc. The input component would have fields that describe how the entity wants to move, such as: walk left, jump, and attack. This can be supplied by the keyboard, by an AI, or over the network, which is implemented as a control component.

This three-tiered system allows for easily customizable abilities and swapping input sources. Want an entity to not be allowed to jump? Remove its jump component. Want to allow an entity to do a charge dash? Give it a component that does that, and acts on the attack+run signal. Want to allow the player to mind-control an enemy, like the Ghost ability in Kirby Squeak Squad? Just swap out the AI component for the keyboard component.

If I were to add gravity, should these affect your acceleration/velocity? I have problems with figuring out how to implement acceleration & which systems could/should be responsible for that..

I'd leave that up to the physics system. When it's integrating the acceleration and velocity, it can also add gravity. Something like this could work (don't actually use Euler integration, this is just for simplicity's sake):

acceleration += 9.8 * time;
velocity += acceleration * time;
position += velocity * time;


Alternatively, if you were doing a more complex physics system you could implement gravity as a generic, persistent force. This would make it easier to do things like different gravities in different regions of space.

But since it takes the current window size as dimensions once the player would move off screen, the entities wouldn't add correctly anymore. Should I let the Quad Tree grow/shrink in certain directions? (If anyone has experience with using this?)

The quad-tree should encapsulate the whole world, not just the visible area. Aside from that, it's overkill to represent ground tiles as entities. It's rare that you'll need to have modular functionality for the ground.

How would the systems interact with your approach of components? Would you have a system that sets state & let the physics update the position based on those states?

Basically, there are three "sets" of systems involved.

1. The control systems - there is one for each control component type (keyboard, gamepad, network, AI, etc.); they set fields of the input component

2. The action systems - there is one for each action component type (walk, jump, attack, interact, etc.); they look at the fields of the input component and modify the physics state, weapon component, etc.

3. The physics system - looks at the physics data and simulates a step

For the quad tree & all the tiles, I want it to be possible that each tile can be removed individually, how can I avoid treating it as an individual tile?

I'm not saying you can't treat each tile individually. Just don't make them entities. It's better to have a single Tile class in a large 2D array. This array can be part of the quad-tree.

• How would the systems interact with your approach of components? Would you have a system that sets state & let the physics update the position based on those states? I understand what you're getting at but I don't see the interaction clearly. For the quad tree & all the tiles, I want it to be possible that each tile can be removed individually, how can I avoid treating it as an individual tile? May 31 '13 at 6:22
• I've answered these in an edit. May 31 '13 at 16:06
• It's been quite long since the last update, but I'll ask anyways: does your mention of "network" in the control systems mean input coming from, say, a remote server? For instance, your opponent presses <space> and the server sends their input to you so your dumb client can draw their sprite in the air? Apr 7 at 21:25