[Release] Entitas ECS Automatic Synchronization framework

https://github.com/RomanZhu/Entitas-Sync-Framework

Features

• Automatic ECS world synchronization
• Client-server networking model
• Command messaging system
• Code generator based on T4 templating to create neat API, serializers, deserializers and compressors
• State buffering on the client
• Uses ENet for networking
• Native memory allocations
• Networking is handled by a separate thread, lockless communication with that thread
• Simple logger

Overview
The framework is targeted at slow-paced genres. Gameplay should be delay-tolerant, as clients use state buffering to smoothly display ECS world changes. All packets are sent reliably using a single channel. It means you should not set tickrate too high. Otherwise single dropped packet will block all other already received packets from being executed and in extreme cases state queue will fail to smooth those pauses, producing visible stutter.

 

I've worked in a project that used Entitas but i would not recommend it. The ECS concept is fine, but the API is not good. Every entity contains access methods/properties (exists, add, update, get) to any component you ever made by making partial classes from the base entity class. I personally think that makes it kind of dirty to work with, since in a complex game you could have a lot of components, and most of the times you know exactly what kind of component you are expecting from an entity, so i dont really want to have the option to access all components that may be contained, which most of them will be null. Also, and not less important, is harder to debug.
Another thing is multithreading. Unity ECS supports it, but as far as i know, Entitas does not (i may be wrong though). You mentioned that, in this case, networking works on a different thread, thats cool, but probably not the in-game systems right? So why would you use it if you have an official solution that is more performant?
As i was a member of a team, every time we had to add/remove components, we had to regenerate the code. That makes changes in some files that were constantly in conflicts in our version control system.
Talking about this framework, its hard to think that a real-time game is entirely made over tcp, since udp is much more performant and there are techniques to solve udp main problems, like packet sorting and drops.

 

1) I used Entitas for ~3 years and Unity ECS for like a year. They have different purposes.
Unity ECS does not provide the same features as Entitas, for example finding an entity by component value. Which is very handy.

Currently "Performance by default" means you don't have important usability features. For example, most mobile games have ~100 entities on screen. Why do you need multithreading there? Scheduling jobs and allocating/deallocating native arrays is not free. But it will make it harder to write gameplay in that case.

Debugging Unity ECS is straight pain - unreliable entity debugger, can't add/remove components on an entity in the debugger. Sometimes after selecting entity - you will get a bunch of errors in the console and no information about existing components. I'm not even speaking about viewing manually created systems.

In Entitas visual debugger works as it should.

I have built another networking framework on top of Unity ECS anyway.

2) In-game systems not multithreaded. Offloading networking to other thread serves a different (not only performance) purpose.

3) I don't understand where you did find TCP. The framework uses ENet's RUDP.

 

Depends really on the type of game. In cases where multi-threading is not needed and you dont want to mess with the complexity of it, you can always make things in MonoBehaviours and avoid a whole architecture or a whole framework (which may external dependencies) you might not need.

I dont really know ENet, i assumed it was tcp since you said: "All packets are sent reliably using a single channel". My bad.

 

With monoBehaviours, you will have spaghetti in your codebase.

The reason why Entitas is widely used in production is usability and extensibility. That's what matters in the end - the speed of adding new features. The bigger the project - the easier it is to add features to it, compared to monoBehaviours.

 

Thats actually not true. You can have event dispatchers that triggers certain game events from MonoBehaviours and have any other MonoBehaviour be listening, so you solve inter-dependency and scalability.
However ECS has its own benefits, depends on the type of game you are making and the performance you are trying to achieve. Still, if i would choose ECS as my game arch, having an official solution and knowing that i experienced the problems i mentioned, i would rather use Unity ECS than import Entitas framework.

 

using Entitas for 1 year of production, we use it 100% for the Core Loop, the other parts of the game use standard oop stuff.
1) I own the execution cycle, which is very handy and helps debugging stuff easily, i can follow the flow of an entity from it's creation to it's disposal.
2) Roselyn is such an amazing gift, more code generation stuff on jenny like abstract Photon/Forge/YouNameIt integrations. it made gameplay code clean.
3) even with "too many components", Contexts helps separating their purpose.

I'll be very scared to use Unity ECS in a production project as it is still new and subject to A LOT of changes.