When is it a good idea to use ECS over the traditional MonoBehavior system?

I'm fairly new to ECS but I am wondering when it's a good idea to write new code in or port old code over to ECS. Most video's seem to suggest that ECS is only used for situations where there are many things doing the same or similar action. For example creating hundreds of bullets or rendering many objects. Is there any reason to use ECS for something like player controls instead of MonoBehaviors or are MonoBehaviors better for something like that? What about networking?

 

Previously I could indeed feel the friction of ECS when you try to do manager object and is forced to use the many-things API in order to just use a single entity from the query. Currently ECS has singleton pattern methods which is suitable for managers. Make a system to represent a manager instead of MonoBehaviour, execpt that the data storage is not in the system but in a singleton entity.

It may feel like an extra step over MonoBehaviour even with Get/SetSingleton to help, but remember that in mono you will have to let user of the manager know about it via either singleton static pattern, or exposed variable anyways. The ability to use GetSingleton to get the manager to appear instantly could become more convenient than mono if you could get used to it. (plus it is compatible with the rest of many-things in ECS that may come later, it could appear in a job thread, etc.)

For networking ECS looks like an even more suitable solution than mono that networking is composed of many of small commands/packets. See FPS samples or https://forum.unity.com/threads/showcase-enet-unity-ecs-5000-real-time-player-simulation.605656/

 

There are several benefits to data-oriented design that go beyond pure performance. In no particular order:

• It is easy to add new systems and replace existing ones.
• Composition over inheritance by default.
• Built-in event system.
• Multiple worlds by default.
• No need for singletons and/or managers.

I recently wrote about this in more detail here.

 

@thedrok_ when you rather new to Unity, you better use default tools provided by Engine. It will saves you frustration, and will provide sense of going forward.
While typically most tutorials are in Object Oriented Programming paradigm, nothing stops you from implementing Data Oriented Design. When you will feel comfortable with working in either domain, then you can try jobify parts of your game. And eventually moving into ECS.

Starting game dev from ECS at current state, may be rather intimidating. Specially if there is plenty to learn on C# itself.

Either way, if watched early Unite talks on ECS, there was highlighted, that not only high number of objects are beneficial for ECS, or multithreaded complex, or frequent logics. But also battery savings on mobile devices, even for simple games.

 

@5argon
So if I'm understanding this correctly something like game settings or other single sets of data that many things need to access become simpler to create and work with.

@gamevanilla
Thank you, the post you wrote is very helpful. What i'm getting from you're post is that instead of one component or class that stores and processes, for example, health, shield, and status effects i should have an IComponentData for each of those and systems that work on each of them. Is this correct?

@Antypodish
I'm not exactly new to unity or c# just the DOTS and ECS. Would you recommend starting my new project/s using DOTS/ECS instead of MonoBehaviors? Also would ECS give performance/power savings for small projects for desktop?

 

Yes, but I wouldn't be really concerned about power saving on desktops. On mobiles devices sure.
However, yes, performance gain can be massive, if executed right.

Yep. If you hop on on ECS from start, that can be easier, than converting later. But two things need be considered.
One is that Unity DOTS is not for production ready.
Two, DOTS is evolving very dynamically. So you should be ready for refactoring often, with new updates that you decide to commit.

But gains can be massive otherwise. Now and for future projects.

 

Ok thank you I think i will start porting the few scripts I have for my project and then writing any new ones for ECS as well. Just to clarify even if I don't have a massive number of enemies for example ECS will still allow my program to run faster? Specifically I'm concerned about lower-end desktops.

 

Yes; I believe data-oriented design lends itself very well to having many different, specific and smaller components and systems.

 

Should do. Unless overkilling with graphics, or something else.