How many have been already manuals "How to make a game on Unity in 3 hours", "Making Counter-Strike in the evening", etc.? Low entry threshold is undoubtedly the main plus and minus of Unity. Indeed, it is possible to distribute “assets”, add a few simple “scripts”, wrap with blue electrical tape and it will even work somehow. But when the project is cluttered with game mechanics, a complex logic of behavior, the problems with this approach increase like a snowball. For the introduction of new mechanics, rewriting of the code in many places, constant checking and reworking of prefabs due to beaten references to logic components, not to mention optimization and testing of all this, is required. Of course, the architecture can be thought out initially, but in practice this is always an unattainable goal - the design document changes quite often, some parts are thrown away, completely new ones are added and not connected with the old logic of behavior. Components in Unity is a step in the right direction in the form of code decomposition into isolated blocks, but the implementation features do not allow to achieve the necessary flexibility and, most importantly, performance. Developers come up with their own frameworks and bicycles, but most often stop at ECS (Entity Component System). ECS is one of the solutions that continues the idea of ​​the Unity component model, but gives it even more flexibility and greatly simplifies refactoring and further expanding the application with new functionality without major changes in the current code.

What is ECS

ECS is the Entity Component System design pattern (Entity Component System, not to be confused with Elastic Cloud Storage :). If in a very simple way, that is, “ Entities ” (Entity) are container objects that do not have properties, but act as repositories for “Components”. “ Components ” are data blocks that define the various properties of any game objects or events. All this data, grouped in containers, is processed by logic that exists exclusively in the form of “ Systems ” - “pure” classes with certain methods to perform. This pattern is independent of any “engine” and can be implemented in many ways. All “entities”, “systems” and “components” should be stored somewhere and initialized in some way - all of these are implementation features of each ECS solution for a specific “engine”.

Wait, you say, but that’s true of Unity! Indeed, in Unity, “ Entity ” is a GameObject , and “ Component ” and “ System ” are MonoBehaviour's heirs. But this is the main difference between the Unity component system and ECS - the logic in ECS must be separated from the data . This allows you to change the logic very flexibly (even delete / add it) without breaking the data. Another bonus is that the data is processed by the “stream” in each system and regardless of the implementation in the “engine”, in the case of MonoBehaviour there is quite a lot of interaction with the “Native” part, which eats up part of the performance. You can read about the features of the internal method of calling methods from the heirs of MonoBehaviour in the official Unity blog: 10,000 Update () calls

ECS Example

The task of the designer: “it is necessary to make the player move and load the next level, when he reaches the point X”.
We divide the task into several subtasks, one by one into the “system”:

• UserInputSystem - user input.
• MovePlayerSystem - move player based on input.
• CheckPointSystem - check the achievement of a player.
• LoadLevelSystem - load the level at the right time.

Define the components:

• UserInputEvent - event of the presence of user input with data about it. Yes, events are also components!
• Player - storage of the current position of the player and his speed.
• CheckPoint - point of interaction on the map.
• LoadLevelEvent - event about the need to load a new level.

And this is how it all works:

• The scene is loaded and all systems are initialized in the above sequence. Yes, the order of processing systems can be controlled without complex gestures - this is another nice bonus.
• Entities of the player are created (with the addition of the Player component to it) and a checkpoint entity (with the addition of the CheckPoint component to it).
• This is where the main system processing loop starts - essentially an analogue of the MonoBehaviour.Update method.
• UserInputSystem validates user input through standard Unity-api and creates a new entity with a UserInputEvent component and input data (if any).
• MovePlayerSystem checks if there are any entities with a UserInputEvent component and if there are any entities with a Player component. If user input is present, we process all the found “players” (even if it is one) with the received data, and delete the entity with the UserInputEvent component completely. Yes, it works very quickly, does not cause the work of the garbage collector - everything goes into the internal pool for later reuse.
• CheckPointSystem checks if there are entities with the CheckPoint component and if there are entities with the Player component. If there is both that and that - in a cycle checks distances between each player and a point. If one of the “players” is close enough to trigger, it creates a new entity with the LoadLevelEvent component.
• LoadLevelSystem checks if there are any entities with the LoadLevelEvent component and loads the new scene, if any. All entities with such a component are deleted before this.
• Repeat the main loop processing systems.

UPD: josinSbazin made the implementation of this test task.

It looks like an excessive complication of the code compared to one “MonoBehaviour” class in a dozen lines, but initially:

• Allows you to separate input from the rest of the logic. We can change the input model from the keyboard to the mouse, the controller, the touchscreen and the rest of the code will not break.
• Allows you to expand the behavior of the player in new ways without breaking the current. For example, we can add slowdown / acceleration zones on the map by adding another one or more systems and changing the speed parameter in the Player component for certain entities.
• Allows you to have any number of control points on the map, and not just one, as requested by the designer.
• Allows you to even have multiple players, controlled in one way. It can also be part of game mechanics, as in BinaryLand:

ECS Features

Based on the example above, you can deduce the main features of ECS with respect to the Unity component model.

pros

• Flexibility and scalability (adding new, removing old systems and components).
• Efficient use of memory (implementation feature, we can reuse instances of “clean” C # -classes somehow, unlike “MonoBehaviour”).
• Simple access to objects (sampling (filtering) of entities with certain components is performed by the ECS core without losing speed and memory allocations - this is exactly what the Unity component system lacks).
• Clear separation of logic and data.
• Easier to test (easy to reproduce the test environment).
• Ability to use logic on a server without Unity (no dependencies on the “engine” itself).

Minuses

• More code
• For the events of Unity itself, it is necessary in some way to forward them to the ECS environment via the “MonoBehaviour” wrapper.

For many who have worked with Unity for a long time and have never used ECS, it will be difficult at first to get used to this approach. But soon, you start “thinking” with components / systems and everything is assembled faster and easier than with strongly connected components based on “MonoBehaviour”.

Embedded ECS Solution in Unity

Now even the Unity developers themselves realized that it was time to change something in their component system in order to improve application performance. Somewhere a year ago it was announced that the development of its own ECS and C # Job system is underway. And now, in the 2018.1 version, we can already roughly imagine what it will be in the future, even in the Preview status .

With regular Unity ECS, nothing is clear yet. Developers do not write anywhere that it is suitable only for a limited range of tasks, but when questions arise as a result of rewriting from other ECS solutions, they respond in the style of “you misuse ECS”. Those. in fact, this is not a “multipurpose” solution, which is rather strange. There was no release, they can still change several times, there are problems with the transfer of reference types (for example, string), so I can not recommend doing something big on a regular ECS in its current state.

Alternative ECS Solutions for Unity

The ECS pattern was not invented yesterday, and on https://github.com you can find many of its implementations, including versions for Unity. Relatively fresh and updated:

• Entitas
• LeoECS
• BrokenBricksECS
• Svelto.ECS

I dealt with only the first two options.

Entitas is the most popular and supported by a large community solution (because it was the first). It is quite fast, there is integration with the Unity-editor for visualizing ECS ​​objects, there is code generation for creating wrappers with a convenient api on top of custom components. Over the past year, the code generator has separated into an independent project and has become paid, so this is rather a minus. Another rather significant disadvantage (especially for mobile platforms) is that memory is allocated for all possible components on each entity, which is not very good. But in general, it is good, well documented and ready for use on real projects. Size: 0.5mb + 3mb support editor.
There are a lot of examples using Entitas , but there is also a project for a long time. From examples with source codes it is possible to look at Match 1 .
Entitas’s overall performance is estimated like this:

With LeoECS, I know better, because I'm doing a new game on it. It is compact, does not contain private code in the form of external assemblies, supports assembly definitions from Unity 2017, is more optimized for memory usage, almost zero GC (only on the primary set of pools), no dependencies, C # v3.5 with optional inline support for FW4.6. From the nice things: DI through markup attributes, integration with the Unity-editor for visualization of ECS-objects and ready binding for uGUI events. Size: 18kb + 16kb editor support.
As a ready-made example with the source code you can see the classic game "Snake" .
Speed ​​comparison of Entitas and LeoECS : the results are quite close with a slight margin on both sides.

Conclusion

I am not an expert in this matter (only recently I started using Unity in conjunction with ECS), so I decided to share my observations and thoughts first of all with those who "collect" games on Unity from assets with a bunch of scripts on each. Yes it works. Himself such was. But if you are not doing a prototype or any one-time game without the need for its support and further development, then think 10 times - then you will have to figure it out and redo it all.

Using ECS, I even get pleasure from the refactoring process :) New features are easily added to the game, old features change - and all this without pain or conflict with the designer, who decided to add a new furious mechanics or remove old ones, playing around with them.