Hacker News Reader

Comment by timmytokyo | Hacker News Reader

Ironically, Unity's ECS development effort has gone radio-silent in the last few months. Their latest versions of the Unity Editor (2021.1+) are no longer compatible with ECS, and Unity's forum reps have not responded to the many game devs left in limbo and begging for info or an update.

Something with ECS development is clearly going haywire, and the silence from the Unity people is troubling.

View on HN

I know what ECS is and why it's needed for some games. But for a large group of game developers that transition was simply too overwhelming I think.

Not just the nomenclature: ECS, DOTS, Burst Compiler, SRP/HDRP/LWRP/URP.... It's an endless list of confusing terms... But moreover those concepts are not so easy to grasp and to use in code by just looking at a few examples.

After doing lots of small 'experiments' in Unity (the old way without ECS) I started to realize, that more and more I was fighting the engine, trying to use or build upon features which were half-baked, buggy or simply not developer friendly. And instead of first fixing those things Unity decided to go all in on ECS.

There came Godot, a breath of fresh air without all the cruft and without all those confusing terms. I think Unity will have a hard time in the future: On one hand there's Unreal which caters the AAA market and there are smaller engines like Godot for the indie crowd. Unity is the odd one in between.

The only problem with Godot is the 3D engine is nowhere near as good as Unity or Unreal . Godot 4 is a lot closer but given Godot’s history , it will take years to arrive . With all of this said , I am rooting for Godot . Long term , an open source game engine will be better .

Is Lumberyard decent as an open source 3D engine? Or did they tie it to AWS in some way?

It's more open now, it was renamed to "Open 3D Engine", and it's maintained by a separate foundation.

Don't know how decent it is. It is definitely full of features and has what seems to be a good editor.

Caveat that this is second hand info based entirely on GameFromScratch (I've avoided playing with it because of his updates) -- he's recorded a new review on afaics every recent Lumberyard release, and currently seems answer is "yes, ish, the actual engine seems reasonable, but the process of actually getting that engine up and running is staggeringly bad, albeit 100× better than it was six months ago"

I can't imagine them to just continue DOTS like normal after going silent for so long. If they don't axe it, then they may choose to do something drastically different than before, like automatic ECS conversion under the hood.

ECS is really good for things that scale. Architecturally, it has both pros and cons to OOP. After working with ECS for a few years, I came to the conclusion that OOP is still the best for behavioral richness.

The current state of DOTS is just sad as it's affecting a lot of developments such as Tiny, unity.physics, dots audio, dots animation, etc...

Burst and Jobs are probably the best things that came out of Unity's initial push for DOTS.

I never understood why they didn't take this approach -- converting under-the-hood "automatically" to their ECS paradigm. The existing data-structures were/are already very similar to their ECS counterparts (though with substantially less boilerplate code); the main "issue" in trying to do an 'automatic conversion', at least that I could foresee, was related to references & non-blittable types. Even then, it seems like you could automatically convert all the data that is a blittable type, and then let the rest work "the old way" (read: sub-optimally, at least insofar as memory access goes -- and ideally/likely with some developer feedback via profiler improvements to demonstrate where [and by roughly how much] any non-blittable type access was actually costing you in performance).

Just my 2c.

I do concur with the above poster, though -- their ECS/DOTS has been basically ignored. At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing. Want to use their physics, or nav-mesh agents, or even their sprite-rendering systems? Once you get 500-1k of any of those objects into a scene (ie, sprites!!), you've already blown way past your CPU/framerate budget. It's mind-boggling; especially when you can, for example with sprite rendering, run your own mesh with a bunch of quads and absolutely obliterate the performance you get from SpriteRenderers.

Very frustrating & somewhat mind boggling TBH. I'd personally guess the vast majority of indie devs that use Unity are simply using it as a [mesh] rendering pipeline & practicing a "roll our own" approach for almost everything else.

> I never understood why they didn't take this approach -- converting under-the-hood "automatically" to their ECS paradigm

I completely agree. I've done compile-time code transformation/generation in C# using Reflection in the past, and while it's not really trivial, it's entirely feasible. I knew some people who did this independently because of things like INotifyPropertyChanged in WPF. They're already doing things that are way more advanced than that with the usage of the [BurstCompile] attribute.

If anything, they could just restrict the usage of fields that don't work with it.

> At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing.

Someone in here said that everything in Unity is either unmaintained or unfinished. I share this sentiment. :(

It could be that they were anticipating filing this patent and they didn't want to publicly disclose the "new" methods they were working on. My understanding is that public disclosure prevents you from being able to patent something. (I am not a lawyer and this is not legal advice).

All sorts of products ship with 'patent pending' written on them. "Trade secret" doesn't mean that you lose it if someone finds out about it

Unity's ECS source code -- including the archetype-based entity-component model described in the patent -- has been completely public for several years now, so I don't think that's it.

Because its such a different way of working I had assumed they would fork the engine and start pitching a different kind of engine with big changes to the work flow and editor. Call it Super Unity and charge twice as much.

I wouldn't be surprised if this is what they end up doing. Trying to shoehorn ECS into an already existing object-oriented engine has probably been an engineering nightmare for them.

The tinfoil hat interpretation would be that this is Unity's Embrace/Extend/Extinguish. First hire Mike Acton to build an ECS feature for Unity. patent it, and ensure that neither him nor anybody else can use this design pattern to beat their engine.

Reply on news.ycombinator.com