Simple physics using Unity’s ECS – Part 1: Introduction

Simple game physics using Unity ECS

In this series of articles I will present a way to achieve simple – yet efficient and powerful – physics system using Unity’s ECS. The physics system we will be developping in this example will be especially designed for a “grid-based” game but could be easily adapted to any other kind of game.

Thus, let’s start by briefly introducing our grid-based game physics and ECS.

Our “grid-based” physics

Our sample game will be a top-down game with “grid-based” physics.

Classic grid-based game

By “grid-based”, we mean that our levels will essentially consist of a grid filled with elements, with the following restrictions:

  • A level consists of a rectangular grid
  • Each grid cell is a square and all have the same size
  • Colliders are also squares
  • Objects all stay at the same height (we will not implement jumps or stairs, which is left as an exercise for the reader)

A typical example of a game using similar grid-based physics is Bomberman.

Our “grid-based” game

However, our “grid-based” physics will have significant differences with a classical grid-based game:

  • Objects can have a collision size smaller but not bigger than the size of a cell (but remember, they are all squares)
  • Moving objects are not constrained to be inside a specific grid cell: they can overlap multiple cells at the same time
  • All objects coordinates are continuous (i.e. float values). Thus they are not integer grid coordinates

These differences allow a much responsive gameplay and control for the players, while keeping things simple.

Another major difference with common physics systems used for video games is that our system will be speed-based and not force-based, meaning that most logic will deal with the speed of objects, rather than the forces that apply to them. It will probably not cover all your needs, but can be easily extended.


Our physics system will have multiple features, all described in the following articles:

  • Building our sample level: this is covered in Part 2
  • Basic movement: this is covered in Part 3
  • Collision detection: this is covered in Part 4
  • Sliding collisions for players to improve maneuverability: this will be covered in Part 5
  • Conveyor belts and exterior “forces”: this will be covered in Part 6
  • Timestep-independant friction: this will be covered in Part 7
  • Dispatching collision events: this will be covered in Part 8

Entity-Component-System (ECS)

ECS stands for Entity-Component-System. ECS is an architectural pattern, different than classical object-oriented pattern or even classic Unity’s component pattern. When using ECS, every object in the game scene is an entity, consisting of one or more components than can be added, removed or modified by the systems at runtime.


The entity itself is nothing more than an ID and a components container. Thus, we usually not work directly on entities, but rather on their components.


The components are basically raw data defining one aspect of the object, for instance a collider component defining the collision properties of an object, or a health component representing the remaining life of a player, etc. Empty components can also be used to tag entities, for instance to mark an entity as being destroyed at the end of a loop, etc.


The systems implement actual behavior or functionality by modifying the data of components. They can also modify the behaviour of an object by adding or removing components to entities. The systems do not operate on all entities having the same group of components. Thus, a physics system could operate on all entities having both a Collider and a RigidBody component, including entities that have some other components. It is also possible to exclude entities having specific components.

At first, learning ECS might be destabilizing, but it is actually very powerful when used correctly, both in terms of performance – components are only data – and flexibility – no deep and wide inheritance hierarchies that are difficult to understand. I also believe that ECS has some advantages for networking games, but we will discuss that another time…


If you never used Unity’s ECS, I strongly advice to read about it first, for instance on unity’s ECS documentation page. In the following I will assume that you are familiar with the basics of Unity’s ECS and understand its concepts. Please also note that we will not be using the Jobs system of Unity in these articles for the sake of simplicity.

In this tutorial, we will use Pure ECS rather than Hybrid ECS since we won’t need any fancy stuff that is unavailable in Pure ECS for now like particle systems, etc.

You won’t require strong physics knowledge, as the physics system that we will describe here will be relatively simple. If you are looking for impact resolution, or a force-based system with fast objects lookup, this is not what you will find here. Instead, we will develop a simple yet flexible speed-based physics system – and I will show you that we can still achieve great things with it.

Source code

The whole source code and project files of this article series, including all systems and components, will be available for download once it is finished. Please come back later or subscribe to our newsletter below to be noticed of its availability:

Do you want to receive cool news about game development?

Subscribe to our newsletter by providing your email address:

* Personal data will be encrypted

What’s next?

The next chapter of this article series is already available: Part 2 – Building the level

Related Posts

Comments (4)

[…] Part 1 – Introduction: Information about what we will be building and what we will not. […]

[…] Part 1 – Introduction: Information about what we will be building and what we will not. […]

Part 2 of this tutorial redirects to Part 1, please fix the link.

Done! Thank you for pointing that out

Leave a comment