ECS Concerns?

Had a few discussions with developers from my uMMORPG community and some people at Unite about ECS. Someone at Unite mentioned that all internal Unity teams have plans to move to ECS, so we are trying to understand the big picture here.

Unity became the #1 game engine in the world, because it was the first one that was actually easy to use.
ECS will be arguably more powerful, but Unity will not be easy to use anymore. Regular developers just won't want to deal with ECS's complexity. They want simple components like a Health.cs script. I could teach a 10 year old how to make a Pong game with MonoBehaviours right now, but I won't be able to do that for ECS anymore. And I am not even sure that many professional devs want to deal with all that complexity either, seeing how F# support is one of the most requested Unity features right now. It's that famous Evolution of a Programmer concept.

So my question is, are you guys going to take that risk internally and just force ECS? ECS will absolutely put you above Unreal for AAA+ / high performance games, no doubt. But with MonoBehaviour gone, this will get rid of all the 'average' and 'hobbyist' developers, the people who made Unity what it is today. You guys must be aware that this will open up the doors for the competition and the majority of people will probably move to a more simple engine again eventually, or not?

In fact, almost everyone here prefers simplicity over performance, this is why we are all here and why Unity is swimming in cash. If we would prefer performance over simplicity, we would be having this discussion over at the Unreal forums.

• I remember when I switched from C++ to Unity after reading a story over at the old MemoryHacking forums where LSpiro was invited by David Helgason and they sat him down and demostrated how to make a simple first person shooter in just a few minutes of time. That's just crazy.
  
• I remember when I took a game engine course in university and everyone picked Unreal for their game projects because 'muh graphics' and 'muh performance'. We picked Unity. I don't even have to tell you how the story ends, because you all know it. It took us 8 hours and they never even finished.

Don't get me wrong, I am an asset store publisher and everything that's good for Unity is good for me. This would certainly help my own MMORPG project a lot too, especially with the Multiplayer by default. But in the long run won't this put Unity where Unreal is, and open the doors for another easy to use Engine again? Is no one else really worried about this? Or am I(we) missing something obvious here?

TL,DR: will ECS replace MonoBehaviour eventually? Will MonoBehaviour code be legacy or remain the main system for users? Will ECS only be for internal components and for those cases where we need threads? What's @Joachim_Ante 's position on that?

Thanks

 

unity will get visual state machines that will be easy to connect complex components.

thats just one of the ways unity will be able to expose complex scripts to end users.

There will be other simpler ways to use ecs too, if your more into c#. you can also have state machine scripts in c# that you connect with code.

Or you can choose to use it for your own scripts, that just requires a bit of learning. I think the performance benefits are very welcome. at the same time im sure the complexity will be adressed.

 

After studying ECS in last few days I actually think that it IS easy to use and understand. It is just a lack of editor support at this moment that makes it hard. Give it some time.

 

It's not easier than MonoBehaviour though. If you compare a MonoBehaviour Pong project with a ECS pong project, that's a big difference. Then extrapolate this to a big project.

 

I believe the answers from Joachim in this thread may be helpful here:

 

Thanks, very interesting.
But if they already plan on moving all internal components to ECS then the decisions was probably already made, or not?

 

I am not sure what pong project you mean, but every ECS tutorial out there is full of hacks at the moment, not even mentioning pure ECS examples. Your concerns come too soon.

 

ECS at a higher level is not inherently more difficult to reason about IMO. Current api's are not anywhere near where they could be, and both Unity and most on these forums have primarily focused on the performance aspects.

If you back out a bit and just look at entities/components and systems, it gets simpler. You have some nice scriptable object type thing to define archetypes. You have the same for defining entities, being able to create them and fill in the components. And then you have systems which are your code.

In some ways it becomes simpler to make that easier due to the entire architecture being more opinionated and structured. Once you create one system the next is going to be easier, and everything kind of looks similar.

Really you almost have to judge the current ECS system by having seen how it has worked elsewhere. Which if you haven't used ECS before is kind of hard to do. But there are a lot of use cases of ECS in the wild and they are much easier to use then what we have now. With most of that difference just being Unity ECS is unfinished.

 

I think they are on the right track, to be judged when it reaches a release state.

The ingredients seem to make sense:
ECS - seems like a good pattern to modularize + leverage hardware support
Jobs - seems like a good way to simplify parallel processing
Burst - seems like a good way to optimize critical code (bypass regular complier)

I have the feeling that this is likely required for the engine to be future proof + it allows more engine code to be exposed in c# without performance loss.

I have not reached the conclusion that things will get more complex / difficult with ECS. They are at the moment...but that is expected.

 

Maybe this is offtopic here and sounds somewhat naive:

I use Unity for archviz and when it comes to performance the bottleneck is vertexcount, shaders, drawcalls - but never the scripting part.

Can someone confirm that?

 

I think ComponentSystem is missing only few pieces. The first one being that it cannot be seen and somehow it magically runs, being based on static bootstrap code. MonoBehaviour does not have this concern as you yourself dragged that to things in the scene and you feel that you are in control. But for newcomers to Unity which does not know that the script must be on an object to run I think they might find auto-running ComponentSystem equally approachable.

Even if you got that the second one (and very important) is you cannot declare fields and drag-and-drop connect data. Also it is not based on scene. The first question from my friend asked if the World could be used to make a scene-like approach. The answer is yes but you need to create destroy register player loop etc. ... it should be automatic in some ways.

MonoBehaviour also has its own magic : Why the Update runs? Why the name is "Mono"? Make empty GO just to host a script? That I remembered I as a newbie getting very confused. But its main strength is that you see them and the code links to the UI visually via public fields make it intuitive.

To fix this we might have :

- Scene-bound system, where it has an extra start or stop running criteria if you are in a scene or not. The first step to making it more visual without any visual representation of the script. We might have a new section in the scene hierarchy view where we drag the system file and something looks like GameObject (but it is not) appears there. You can click to view scene's internal state at any time. You can highlight and press delete and expect OnUpdate to stop running immediately. When scene change all of the system are removed from the default world and excluded from player loop automatically. The list of available system is serialized together with a scene. If you dragged a system with [Inject] to other system it appears together.

- After that you could extend to have what SharedComponentDataWrapper did at the moment attached to that thing (SystemObject?) in the hierarchy. And extend the interface in the code to be easier than having to inject ISharedComponentDataArray and ask for index [0] when you know there is actually only one intended for the system. This should be equivalent to public-expose approach.

 

I guess that's the answer you want to know.

 

Definitely cant confirm that. There is an amazing example with a navmesh where i managed to get 77.000 entities accessing the navmesh and have behaviors and run at 60fps. if you do anywhere near that with gameobjects then I would say that the gpu is the bottleneck. but it is not that given the profiler.

 

I think it's very early days for ECS and it lacks a lot of the bells and whistles that come with Monobehaviour e.g. Editor Integration, Physics, Audio, Particle Systems.

I concur that most people prefer easy to use over performance and an object based approach fits well with how people think about things as opposed to a systems/component approach.

Maybe the best approach to Unity will be a hybrid that follows the 80:20 rule where 80% of a games systems can be written using an object based approach and the 20% that boosts performance and battery life can be ECS.

With regard to PONG:

In classic Unity I would just:

1. Drag in and scale two cubes for the walls.
2. Drag in and scale two cubes for the bats.
3. A sphere for the ball with a rigidbody.
4. Add Trigger scoring zones.
5. Then a few lines of code and a scoring UI and hey presto PONG in Unity.

90% of the work would be done in the editor with just a few lines of code for player input, starting the ball and scoring.

ECS I would need:

1. Two seperate player input systems for the bats.
2. Two bat Archetypes and a ball Archetype.
3. Prototype the Balls, Bats and Walls and Bootstrap System to set them up.
4. A Ball Collision system to bounce the ball of bats and Walls.
5. A Ball Scoring System.

90% of the work done in coding systems mainly wrapping the same or inherent events/inputs the classic version uses. And probably way more time lining things up right for the camera view.

Now if ECS had trigger volumes, physics, audio, particles with templated systems that only need to have their filters configured and their internal function written it would be nearly as easy as classic.

 

I'd like to ammend this quote:

 

you dont need 2 systems. you need one component with an integer to identify players.
you need 1 bat archetype with the correct data ^. and 1 ball

it is a ridiculously small amount of code. The collision is not hard for simple physics either, as long as you can add/subtract direction vectors.
bootstraping is a bit of an inconviniene. but for pong it would be a "new game button" that just starts the first entities to start the ball rolling. You dont work with events, i mean you can, but that is talking the long way and yes, trying to do OOP pattern in ECS wiill be a headache and will take longer and require a lot more systems and interactions.

If you catch yourself thinking OOP while designing for ECS, you should pause and think in terms of data and not objects. then it becomes simple.

I definitely sympathise with the sentiment. The more used i became to thinking in data oriented development the simpler it looked to me. But i think i can do a lot more in less time in ECS rather than monobehavior. If i know before hand what i am building.

Although i am mainly experimenting with pure ecs. I would do hybrid if objects make sense, kind of "dont bring a knife to a gunfight", ie at the moment i wouldnt even begin to do UI with ECS.

 

I thought their plan was to eventually go full ECS but it is so far off that we didn't really need to worry about it.

Like in 6 years maybe it's the standard and we'll be whining about how monobehavior is still not removed?

I took a look at it the last couple days and it wasn't particularly my cup of tea since I'm so used to the classic approach but I understand how it can work and I'm happy to adopt when it's time. Since it's insanely early in development I figured by the time it's stable and ready to adopt there will be enough support to understand how to onboard it easily and move forward without needing any classic stuff.

There's also the hybrid approach, which is actually not hard to do.

 

What could be interesting is how well ECS could lend itself to be represented by visual coding, most of it is setting up the data types needed then the systems that act on them with only a few lines of code or visual nodes for specific systems.

 

@vis2k

I struggled immensely with ECS. It made no sense, and the examples were strange, and seemed verbose. ECS is a totally different paradigm. However, with time, and study, I started to understand it. Now, I think it's much more intuitive than Monobehavior. My code flows much better, and is far easier to read.

The trick for me was the erase everything I knew about Unity, and start over fresh.

A pong game is very easy to teach with ECS (Bootstrap, temp GOs for visuals, and a few systems), if you teach them how to think like ECS. It will also instill better coding practices, and performance. It's more intuitive, because each part of the game is a system, that flows into the next.

 

For me, when first time read and looking about ECS - looks hard.
when i trying cooding etc. - easy

but pure ECS isn't finished yet - many thinks still lacks... but it is in the creation and testing phase

 

I think it was Joachim that said many times that there is no plan of dropping GOs. Correct me if i am mistaken

 

Thanks for the replies guys. Lots of insights. Not to worry yet then.

 

Also, you need to keep in mind that when then say: "performance by default" it means there is no trade-off over simplicity. When ECS is ready (which is far from it, at least one year until they remove the "beta from it" - IMO) you'll use it like you use MonoBehaviours, with all tools that exists nowdays with MonoBehaviours (but you'll need to think a little different).

I also think that with ECS is easier to have a tool like Blueprints where you can develop script without writing a single line of code, just drag'n'drop, like they are doing with ShaderGraph.

 

Please take care and thoroughly assess the use cases of ECS, Unity! (before you go into the future and are at a dead end) I applaud you for recognizing the "cpu cache importance" with regards to performance.

Despite that, I have the impression ECS and Jobs are only usable for academic "space invaders" type of "gameplay" (replace ships by rupees or other simple models) and not for many, diverse applications.

I have attempted to use Jobs on a "real-world example" and at best performance is on par or even only a fifth to a third of my Coroutined initial code. Nowhere near the > x10 performance gains demonstrations watchable on YouTube.

And if it's not ready, don't talk about it this much, you are/were also writing about it on your 2018.x features page.

In particular animating transform hierarchies (a transform and afterwards its children) yields performance on par, attempting to use Jobs for a collection of "helper" classes yields worse performance (and an abundance of errors despite having used the flag mentioned in the error message). I attach this file in question: when attached to a GameObject, it makes that one "swing". For performance reason, it only does so when the GameObject is in view. And this is where the trouble porting it to Jobs arises. Initial code(s) is(/are) contained out-commented. (Framerate for original code is 60 fps when having 40 swingable GameObjects (the application in question is CPU limited due to heavy shadow setup (according to the Profiler), the swingable GameObjects themselves don't add much), Framerate when using Jobs is 20 fps).

If pure ECS improves the situation, this would be nice. Like mentioned on my A <-> B thread though: the "information content" in ECS and GO code appears to be the same. Thus I don't see why "everything" cannot be relegated to a clever compiler (and or linker etc).

Ease of use and excellent documentation (if it is documented) (and satisfyingly good performance) is my reason to use Unity. Keep this up!

 

Pretty much this, yeah.

Since optimizing for performance is essentially "hardening" code (making it more brittle, harder to modify without introducing bugs), we follow the philosophy of optimizing for performance in my team:

A system can be optimized when at passes at least the following criteria:
- All its feature-requirements are well known, prototyped and pretty much set in stone
- The optimized version of the system can be built quickly so that its not a huge loss if it turns out that there are changes that require a complete rethinking of the problem (and thus throwing out all that optimized code)
- It has actually been identified as a bottleneck.
- The proposed optimizations will not make future improvements or smaller features impossible.


My (and most of my teams) view on this situation and why we have no intention of converting a majority of our project to ECS:

1) Time
We're pretty far into development of our game. We simply don't have the time to completely rewrite everything in ECS. We've successfully converted a few small isolated systems to ECS for testing.
One system will probably permanently handle spell-missiles for us now, as that seems to fit perfectly.
Any more than this (and maybe a few other small-scale / isolated systems) will probably not be possible.


2) Interaction with existing code
This point pertains especially to the new "networking by default" stuff and serialization.
History has taught us that Unity can not be trusted to completely develop and maintain a networking system.
Bugs that don't get fixed, an architecture that might not even make sense for our game...
In the case of UNet that meant being forced to have the same type of component on the server as there is on the client for one GameObject; instead of being able to have MyClientMonster on the client, and MyServerMonster on the server (both sharing MyCommonMonster as a base class)

Now it's not too far fetched to imagine the new "entity networking system" having similar problems and/or limitations. We can't have that.

As for serialization:
Unity has been very "closed" when it comes to any sort of serialization in the past.
- No way for surrogates or custom formatters in the Json serializer.
- Serializing references to GameObjects is very brittle and requires jumping through quite some hoops.
- UNet HLAPI serialization was practically not all that customizable either.
- ...


3) Making things "easier"
Everyone on my team is used to OOP, and while ECS is not that complicated, it still is a different workflow.
The Entity Component System infrastructure is currently still in preview(!) and there's barely any production-ready tooling available (which is totally fine and expected from a project still that early in development).

Maybe in a few years there will be the needed infrastructure like for example full integration with the UI system, maybe a full rewrite of the UI in ECS made by Unity, this time with actual updates and support instead of it being semi-abandoned like UNet.

Anyway, if you're building some small game, pong or whatever; or you're doing this as a hobby / for fun, then sure go crazy with ECS and try to start your new game today using nothing but ECS. But trying to make a game fully in ECS with no MonoBehaviours at the current time is just insanity imho.


4) Many things simply not being a good fit for ECS.
I get it, people are hyped by the promises of benchmarks orders of magnitudes better than before.
But they keep forgetting that this can only work for a very narrow set of problems.
It has been stated time and time again that linear data layout AND linear traversal through the data is a hard-requirement. There are many things that force you to deviate from those rules, and when you do, suddenly the performance benefits are not all that high anymore.

For example: any sort of tree/hierarchy is (simply by definition) not linear already.
So things like UI will definitely not get the full speed boost, any code that has to traverse entities in a sorted or otherwise pre-defined order has the same issue. Sure you can somewhat mitigate those issues by investing even more work to figure out clever tricks, lots of testing, ...


5) Prototyping / Fast iteration
For now, ECS is much harder to setup and control. With the MonoBehaviour system even a designer can add a script to some object, or changing some object reference in the inspector, ...
Doing the same thing, which is modifying and recombining existing elements and components in new ways, is just not possible in ECS right now. Also creating all the components and systems to get something going takes quite a bit more work, thought and careful planning (assuming you actually want to built on top of that later, and not just scrap it and start again)

I know it sounds like I'm bashing ECS, but in fact I'm actually really happy that it's becoming a thing! It will be great once it matures more. And if the editor tools will be improved as much as people saying they'll be, then it might even start a new era for the unity editor.

 

i agree with his summary

 

Does the inflexibility of an ECS system happen in the between the process links?

If you build up an ECS system to do more complex tasks you will need separate systems to be triggered in different orders these behavioural paths could entail hard links between systems for low complexity projects e.g. prototypes, simple games/apps.

However when you need to build up more complex behaviours would that require a different architecture to the simple examples I have seen so far.

Systems A B C D E F G

Default Behaviours
A->B->C->D
A->B->E->F->G

New Behaviour
A -> (B or C) then B -> (E or F), C -> (G or D)

Or what is the most complex behavioural ECS example currently available and how do they get around the hard links problem inherent in basic ECS examples?

 

I've been using hybrid ECS the last few days and I love it. I've been converting all my game managers and combining them with the new addressable system and it works like a charm. no need to worry about pulling in all my managers to test something because the addressable system handles that for me, any scene I'm in instantiates my manager(which is now just data) then the system handles the rest. Its making my scenes a lot more cleaner.
I think it just comes down to preference weather you want to stick to MonoBehaviours or convert to hybrid ECS or pure ECS. I've read in another post that they are not going to get rid of MonoBehaviours, ECS is just another option.

 

It looks like the reactive ECS pattern could address the issues I have with system order and event or reactive behaviour with ECS.

 

There is no point in comparing the complexity of creating pong with current ECS version to standard unity. It is a preview and it lacks a lot of features and there is almost no integration with the editor. That said for me, it is easier to write game mechanics, it is more flexible and straightforward. Sure, you need to get used to this style of coding, but it is well worth it not only because of performance. About your 80/20 argument, you can do that using a hybrid approach.

 

Unity itself is a preview.

 

What if DOTS was incorporated into Monobehaviour?

Sounds stupid right, why mash the two together, think about it Mono is just OOP where Objects are just data and code combined. DOTS is just data and code refined to be performant.

What if you could take Mono code and convert all the functions to use structs or entities and all of those functions to work as DOTS systems.

Then developers could write Mono code and Unity would with a nice [DOTS] and [Burst] set of prompts convert the code to be performant.

Or why can't OOP developers tap into the performance of DOTS/Burst developers auto-magically. We might have to write OOP code that is more along the lines of Manger objects but wouldn't that be easier to work with than Pure DOTS Systems and Entities?

After all the DOTS/ECS framework is just that an artificial construct for programmers to take advantage of memory and multi-threading.

And arguably one of the largest issues with DOTS is having a nice generic multi-system control mechanism that is inherent in OOP.

 

People keep posting in my 2 year old thread

Maybe it's fair if I give an update. After seeing the zombie shooter ECS presentation at Unite Copenhagen, I actually ended up making an ECS networking library: DOTSNET.

So after using ECS full time for the last 6 months:

• + Performance is absolutely insane. DOTSNET can send 75k networked entities to 1 connection. It could simulate millions of networked entities similar to WoW/EvE online. On my 2015 laptop. It's so fast it doesn't even make sense.
  
• + Writing code split into data & systems is very different. It requires a new way of thinking. It's not so much about one particular MonoBehaviour anymore. It's about transforming large data sets into different large data sets. For example, DOTSNET doesn't try to handle every single position update. Instead it batches them in a NativeList, then applies the whole list of updates with Burst, which is significantly faster. It's a cleaner way of thinking.
  
• + ECS packages are open source. We can now fix critical bugs ourselves. The risk of having unfixable critical bugs in production was significantly reduced.
  
• +- 2x technologies == 2x maintenance. Both Unity and the community now need to maintain two version of every package: one for MonoBehaviour, one for ECS. It's a significant overhead that will ultimately force everyone to worry about ECS instead of worrying about their games. If Unity settles for either MonoBehaviour or ECS then this won't matter in the long run. I guess it's a chance to learn.
  
• - The future of MonoBehaviour / ECS is unclear. I have several MonoBehaviour projects, and working on them feels like a waste of time now, since Unity is moving to ECS. I now also have an ECS project, and working on it feels just as strange, since Unity recently removed ECS from the package manager. We are in a state of limbo where nobody knows what to focus on, and everything is unstable.
• - ECS is still unstable. Well, obviously. The good news is that ECS packages are way easier to test, with way higher code coverage. The ECS packages could ship with maximum stability from day one. The bad news is that this doesn't seem to be the case for the Unity packages.

ECS is insanely fast but hard to use.
MonoBehaviour is slow but easy to use.
Everyone is a bit confused

We'll see if Unity can lead us to a performant, stable, productive & fun future of game development.

 

I wish we knew what's Unity planning for the future in regards to ECS and MonoBehaviours. It currently feels Unity plans to deprecate MB one day and replace it with ECS(evident by how new core packages like visual scripting/networking/physics are ECS only).

The thing is if ECS is meant to replace MB it should also be as easy to use as MB, and currently it's not like that and doesn't seem like it will be like that. It makes me wonder if ECS is supposed to take over or they'll both be maintained at the same time.

The lack of uncertainty about this makes it seem like Unity is committing to ECS, but hasn't figured out how to deal with the consequences maintaining 2 technologies/deprecating MB without offering another easy to use alternative.

 

I think the future will probably be that many things will work internally with ECS (where it makes sense), but MonoBehavior in the editor as authoring component.

 

Something to consider:

Nearly all of what makes DOTS more difficult than monobehaviour is the jobs/multithreading aspect. We should remember that main thread DOTS code is something that's possible, and it'll be bursted in the future.

I can definitely see main thread DOTS code being something reasonably accessible, and it'll still be faster than monobehaviour in most cases. For someone who doesn't have an OOP bias in their learning experience, I'm pretty sure both paradigms are at an equal level of difficulty

---------

It's also starting to get pretty easy to mix ECS and monobehaviour together now, with the "Convert and Inject GameObject" option of ConvertToEntity component. That means a lot of heavy-lifting can be done by DOTS, while users can add monobehaviour things to make gameplay logic

 

Wait, "Main thread DOTS code... in the future"? Is that not just a normal Entities.Foreach(()).Run(); that we have now? Or what do you mean?

 

I think he was referring to main thread ECS code being bursted one the future.

One of the DOTS features currently in development is Bursted Systems, which would could run significantly faster on the main thread.

 

The main tricky piece for newbie programmers is dealing with value types/structs at all, and the difficulty of referencing between entities/components. MonoBehaviours are based on standard C# practices with object references, so you can easily access them from one another, and there aren't any unexpected copy semantics or the awkwardness of "ref"s.

You also lose access to many of Unity and C#s tools (eg coroutines). And then there's the lack of a true hierarchy (TransformSystem is not anywhere close to as easy to work with), and the bifrucation between edit-time and runtime game.

I'm not saying ECS doesn't have its advantages -- it definitely does -- but ease of use is not one of them.

 

My day job is rewriting massively complex object-oriented Java code to run on a SQL database, and I can tell you from that experience that "data oriented design" does not lead to high quality code. It's much, much easier to write, test, and reason about large systems in object-oriented or functional paradigms. "Data oriented design" (whether in SQL or ECS) is basically writing procedural code without a lot of the abstractions we've become used to in modern programming. It's trading programmer time for runtime performance (which is a perfectly fine tradeoff if that's what you want to do, but it is a trade).

ECS, and data-first design in general, is performant. That's the point. And it might look good in small examples. But you're sacrificing a great deal of ability to abstract out common logic or infrastructure, testability, and modularity for larger teams. You're essentially tying your data format and algorithms together.

(EDIT: I haven't gotten too deep into ECS because of some showstopper bugs/limitations, so this is mostly conjecture. I use MonoBehaviour+jobs only. There are some ECS evangelists on here who have done large games in it and might have a better perspective)

 

The problem is HOW the mono code is written. You find a gameobject, retrive its renderer, assign a new material and call it a day. So the gist of monobehavior code is to do things on OTHER objects. This is completely different from processing an array of the same structs in a system and do something TO THEM. And in OOP code are lots of if's (null checks, conditions). Branches should be avoided in systems to really speed them up. The best method is to get only the entities (or even better chunks) so a good aproach to filtering and laying out your data in the first place is essential.
So I think this aproach of "automatically" converting normal monobehaviors into ECS is not viable and possible. If it would be, they probably would have advertized it by now .

 

Oh, he means the system code that does the Entities.Foreach(()).Run(); call?

Edit, yeah "Bursted Systems", I see now. Did not really realize you meant the actual ECS systems, not just the generic term "system". There is some indication of this in the source code, right? Are there anywhere else one can read about this?

 

I have a question. Can the preview state of the dots somehow affect cross-platform compatibility or raise any kind of cross-platform issues?

 

Reply definitly, some package are not ready for some platform and in general if you want web support you'll need to work with project Tiny.

I suggested in the package manager forum to add a section to tell wihch platform are compatible with each package (full support / partial support / no support), I really think it would simplify the choice of packages...

 

Scrolled thread, found this. Was not disappointed/10

The EntityConversion-workflow seems to be the best intermediator for now. However, give it a generational change and ECS will be where Mono is now.

 

Since this thread got reanimated anyway and Pong has been mentioned several times there is an official Unity video on how to create Pong in ECS. Just incase someone is still interested. Haven't watched it myself yet.

 

I do not agree with you. ECS code is easily testable. It is more testable then OO. Usually you do not need to mock anything. ECS is also very flexible. One of biggest drawbacks of OOD is that when your requirements change you can end up in situation where it is hard to do what you want becaus of architecture. You say that ECS ties data format to algorithms in OOP you tie data to behaviour. Usually algorithm is tied to some data format, expect some generic algorithms like sorting etc.

 

Mocking is not a "need" for testing. You can always test without mocks. Mocks allow you to isolate part of your system to unit test in isolation, while other teams work on other parts of the system. That's much harder when your system consists of a big, globally accessible database.

Not at all. You want to tie yourself to as little of the data representation as possible. I'm not saying OO is some holy grail here, functional programming, dynamic/duck type systems, and generic programming (eg C++ templates) are approaches to abstracting away these pieces in a big system. The point is that you write code that's testable, reusable and isolated from the rest of the system.

 

If you can easily build all dependencies. But sometimes it is hard.
Problem of functional programming is performance.