Would you recommend avoiding ECS for new games?

So I've been trying ECS on a new game that I intend to publish probably end of 2019 or 2020. Realistically speaking, do you think I should drop ECS (Hybrid and Pure) completely until it's more stable or should I keep going? I've been having a great experience working with it so far and I'm aware of the limitations at the moment and the fact that it's just a preview and that it will take time until this systems mature since everything will have to rewritten.

 

It depends what is your reason to use ECS. If you would use it just to learn I would not use it for production. But if your game can benefit greatly from using ECS, for example unlocking performance, I would use ECS. @eizenhorn uses ECS in production and he wrote a post about it https://forum.unity.com/threads/unity-ecs-and-job-system-in-production.561229/

 

You should use ECS! Well it's hard to get in there if you never worked with a Data Oriented Design. But you will benefit from it!

+ performance / battery consumtion
+ maintanance
+ networking
and more...

Take a look at the new FPS sample form Unity. It uses the hybrid mode.
https://github.com/Unity-Technologies/FPSSample

https://unity3d.com/fps-sample

 

The sample is not a good start point to learn for the beginners. 18GB repository + not the best networking stack.

 

If I'm starting a new project, I would definitely use ECS. It depends on the genre of course. I prefer strategy or simulation games with lots of units. ECS would be a good fit for such games.

 

The ECS API keeps being changed so I personally wouldn't start active development using it until it's finalised, but developing with data oriented design principles in mind still seems like a good idea and should make it easier to switch over to ECS later.

The FPS sample honestly isn't very useful as a learning tool, it's a mature project with massive complexity and it's quite difficult to dig into it and find out how any specific part of it works. The types of samples people learn best from are minimum viable cases. The ones in the stickied Samples repository are much easier to learn from and are less than 80mb while the FPS sample is 18gb.

 

FPS sample is an ongoing project so YMMV.

 

They did mention that component groups and chunk iteration would be the base line API. I would focus my learning on those things.

 

Use it. Low-level API will be subject to changes to a very lesser extent, more changes will be in the high-level API

 

Right, but there's a ton of boilerplate code involved in that right now and one of their goals is to minimise that. I would imagine there's a better high-level abstraction coming that will be easier and faster to work with, and that'll also be much easier for new devs coming onto a project later to understand. If I started learning and using the low level API now on a production basis I'd probably have to rewrite everything later anyway.

 

As long as the system concept is not going away, the eventual "rewrite" will cost little since they are already self contained. For example if a less verbose system that was presented in Unite comes, you just edit that one file. If you do the classic way, you have to potentially rewire many classes and data to a system, undoing a lot more work.

I spent 2 months moving to ECS and most of it was to system-ize the logic and move data out, encountering tons of bugs along the way where previously my game works fine in OOP. You are in the best position to use ECS while you still have nothing to move.

 

That makes sense, though I'm also concerned with speed of development and speed with which the new system can be learned. We have a young student with us with limited programming experience who realistically won't be able to work with the current API but he understands gameobjects and monobehaviour. To help him transition to data-driven design paradigm I was considering not using ECS yet but still separating data from logic in a similar manner.

I could create manager objects that collect or maintain arrays of objects and iterate over them in its update method. That might be easier for the student to grasp and the manager classes should be easily converted into ECS Systems when a more user-friendly API is released. Does that sound like a reasonable approach or do you think I should just bite the bullet?

 

I think you should bite the bullet. The thing is, learning Data Oriented Design is much harder if you are coming from an Object Oriented Design because you literally have to unlearn most of the things that OOD teaches you in order to understand DOD. So teach DOD to your junior dev while their mind is still empty, they will benefit greatly from it. If you wait, they may have a hard time transitioning from OOP to DOD. Another thing to consider is that DOD is a lot more forgiving then OOD.This is because it's so loosely coupled and a LOT easier to refactor. So if you junior dev makes a naive mistake, it's not a big deal in DOD, but it can be a big deal in OOD.

 

I'm in similar shoes, although I'm a loner hobbyist, so not the same situation. I just was able to postpone to put down the first brick of the project's code this long, I had some time to work on other stuff in the project.

I think, having the student is great. You can create a developer who is naturally understands DOD and this whole ECS paradigm. I would go for it if you can afford the slower start in terms of coding. Your velocity will raise after a while, when Unity starts to cement the API and start to work on other processes to wire in the low level APIs.

On the other hand, if you're like me, who came from the OOD world and maybe even earlier, getting a giant whiteboard and draw the structure on the board is priceless (although I'm visual and motor person - which means I learn/understand most when I see it and/or when I'm actually doing it). Just don't let the cleaning crew erase the board.

Edit: if it's not clear, I think starting with ECS now is a good idea. You can go hybrid and replace subsystems as Unity (or 3rd-party) develops new ECS-compatible systems if you don't want to develop your own.
Also when I was talking about whiteboard, I tried to refer to draw the data-flow, not the command-flow, obviously.

 

I say any new projects should just use ECS. Your code will be so much cleaner and run faster. You can still use Hybrid and gain some performance and still use all the great features Unity Legacy has.

 

After reading several times folks stating that moving from OOD to DOD was harder than just learning DOD from the start, i decided to bite the bullet as you say earlier rather than later, my hope was that as i had only been learning programming of any kind for a relatively short time, i might have an easier time getting my brain thinking in DOD terms.

I have at times been told that i am trying to learn stuff that is too advanced for a beginner like me, so reading this comment and others like it is nice, as it confirms to me that my decision was not wrong.

Thanks