DOTS OFFTOPIC DUMPING GROUND

I am sorry but this entire effort is misdirected.

In this day and age CPUs are fast enough to use polymorphism and classes and the developer doesn't have to think about cache alignment. Now Unity is going back 20 years with the focus on DOTS, where all of that technical stuff is brought front and center.

What should have been done instead is that Unity should have optimised the engine internals instead of creating DOTS. There's such a tremendous amount of low-hanging fruit there which would have benefited every single game.

I know DOTS won't gain any widespread use, as it shouldn't. However, if Unity can use it for optimising the internals of the engine then all will not be for naught. Still, it would have been more cost effective to just do a major traditional optimisation pass on the under-the-hood stuff.

 

I was about to write a mean post, but then I looked at the date

 

I've used both Monobehaviour and DOTS a lot at this point, and what I've found is that Monobehaviour projects tend to necessitate a lot more "technical stuff" from the user than DOTS projects

Performance and ease-of-use can be two sides of the same coin. When a quick & simple 1-day implementation of a feature in DOTS performs 20x better than a Monobehaviour implementation that has greatly grown in complexity after weeks of trying to optimize it, that's an incredible ease-of-use bonus. And no amount of internal optimizations could make traditional OOP code reach the performance levels DoD has

The performance & code structure advantages DOTS gives you by default allows you to spend more time focusing on your game, and less time tackling difficult technical problems

 

Yeah, I have major qualms with how DOTS is run from a project management side, and I have some technical nitpicks, but the actual ECS workflow when it's actually working well is just magical. Just being able to add a component with an entity and everything just works is so nice. I do wish the DOTS team focused a bit more on ergonomics, but hopefully that will come after they have an insanely fast base to work from.

 

Guys It was April 1st and you fell for it.

 

A lot of companies especially in mobile game dev focus on making projects as fast as possible. They often don't have time to fix bugs and performance is a secondary issue. In cases where DOTS increases complexity (more bugs, longer dev time) it's simply not worth it.

Can DoD reach the same simplicity of OOP? Or rather: can DoD implementation in Unity be as simple as current OOP?

What if it's true? Imo Unity is lacking on rendering and gpu side. Are there any stats of Unity games being gpu or cpu bound?

Btw DOTS 0.50 release was so good that:

 

Well, based on our experience (we made successful mobile games before, we made successful PC RTS recently) I will disagree with you (well and that’s completely OK)

Well the problem is who used to OOP think DOD is harder, which in fact - completely opposite. Any complex project becomes a nightmare, despite you follow all dev principles for OOP for making it more…maintainable. DOD approach in that area provides it out of box if you use it as DOD and not by stretching OOP owl on to DOD globe. Current Unity implementation already simple, at least whole our team like it much more than old one

And again - it’s exactly opposite. Dev times, in any more or less serious project in DOD becomes faster. Maintainability, debugging in the end in DOD >much< faster, exactly because of it’s linear nature. Know your data is the best advice here Moreover, again because of nature of DOD, it’s much more modular, which is one of the core pillars of fast development process.
But of course, despite all of this (which is again our team IMO based on our experience) DOD is not silver bullet, and absolutely there is many places where OOP and Unity MB will be just more suitable.

 

The problem is that we live in a real world and not in a theoretical world.

Games are not made by programmers but by teams. Unity managed to democratise game development by pretty much standardising it, meaning game developers can move from one company to the next without much ramping up costs. This means that the editors, standards and workflow are king. DOTS should have been its own project if that was something they felt they had to get out of their system.

Furthermore, if you take a look at the DOTS manual section it pretty much starts with cache alignment and other low level concepts. Do you think that is the primary thing that should be on someone's mind when adopting a new engine or a new technology? Also, you guys are confusing programming paradigms and programming technologies -- entities are a thing even without the DOTS stack.

This is technology porn and misguided, and will end up costing Unity severely. They literally thought "So there's a ton of unnecessary overhead in the engine, what should we do? Optimise the engine internals? Nah... let's revamp everything, bring back the mentality from 20 years ago, throw out all of the work we've done with Unity and limit the language. Sounds good!". If that effort had been spent on optimising engine internals and on the usability and editor tools Unity would be quite fantastic at this point.

 

The facts remain:

1. Single-threaded CPU performance improvements have been decelerating for years.

2. Multi-threaded CPU performance has been improving for years.

3. Reference-based memory layouts cannot physically be as cache-friendly as linear iteration.

Ease of use of OOP vs DOD is a matter of familiarity. I worked at a large studio whose lead programmer learned to think in terms of ESC models when he was young. Later, he found OOP to be confusing and cumbersome at first. It’s a matter of perception, and thinking in one style is not objectively easier than in the other.

but one style of coding is objectively more performant than the other, in many common use cases.

Unity pitches itself to developers as “your engine department”. At the end of the day, I want my engine team to be pursuing the objectively fastest way to do things. And I want my gameplay programmers to adapt, to learn to write the more performant style of code.

There can be a steep learning curve to learn DOD and ECS patterns. But that happens once. The performance and organization benefits your company gains will help all of your future DoD projects.

What others here have said about project scale and debugging is true. The standardizes rules about how ECS patterns work makes problems much simpler to track down than in a free-form, OOP project. You can save time and production headaches at the end of large project. I have experienced this personally, before DOTS was announced, at a studio that had written its own, threaded ECS engine. The debugging process compared to larger OOP studios was amazing. It allowed us to make games more common of a much larger studio. It made me a believer in DoD for gameplay code.

Also, there will likely be performance gains that mean your product can run well on more platforms, without you needing to spend more time, money, and QA to optimize it for the Switch, etc.

There’s many negative things that can be said how Unity has chosen to roll this out and to market it. But ultimately, I am very glad they are working on it. As long as they don’t stop, it’s likely to make a big difference for many developers in the future.

I haven’t mentioned the benefits you get from having a standardized, usually bug-free approach to multithreaded gameplay programming. That is absolutely huge. Most companies don’t even attempt to multi-thread gameplay code, since it’s too difficult to figure out and debug (and to train people on). Having one of the world’s leaded engine developers investing in making sure that’s a predictable, bug-free experience? Massive. We should not take that for granted.

Fwiw, I’ve been lucky enough to ship AAA and indie projects on custom OOP, licensed OOP, and custom ECS engines. My comments are based on those experiences.

 

Obviously RTS games are naturally fitted for DOTS as they are CPU bound because of a lot of entities doing the same and much simpler top-down rendering.

I agree that DoD may be simpler than OOP. I often avoid using inheritance and go for DoD approaches (systems for MonoBehaviours) but current implementation in Unity isn't. A project with a lot of systems for single objects may be a nightmare in DOTS.

I wonder what happened with this sample battle-royale shooter project announced in 2020.

Haven't heard a single word about it after that roadmap. The "new environment system" also isn't in 3d World Building roadmap so I'm guessing Unity faced so many rendering/streaming issues that the whole idea was trashed. For me it seems that DOTS is very complex from Unity's side of improving/adding features to the engine. Another example is DOTS Netcode that was planned to be production ready in 2020.

I hope I'm wrong. Possibly only the core of DOTS is complex and it's going to be smooth sailing after 1.0 release.

My experience with DOTS so far is that I had to remove it and replace with MBs to be able to use Unity 2021 to get il2cpp crash fixes.

 

100%.

It seems clear that Unity greatly underestimated the scope of their work. I don’t think it would be smart for most people to use ECS in production until at least 1.0. We only use it for internal test projects, to stay informed for the future. But since Unity’s gotten so far off schedule with this work, we’re not going to try shipping anything with it until it’s feature rich, and very well proven.

But! But - There’s a difference between something being a bad idea, and a company making planning mistakes. Unity’s reasons behind pursuing DOTS were smart, and they’re still smart.

…and they’ll probably still be smart in 2 years when it’s (hopefully) safer to use it!

 

First, Most of the frame time is consumed by "your" code. Not the engine's code. When "your" code reaches for objects all around the memory, it's going to be slow. Unity cannot do anything about that.
Second, You have no idea what "optimizing engine internals" even means. What engine internal could Unity optimize that they didn't do? Please provide examples of modules that can be optimized. (Don't forget to mention HOW they can be optimized).

 

I think both sides have very valid points since obviously, every technology has good and bad points.

Objectively speaking (and in retrospect) I think the mistakes were to PR dots as the panacea, one solution to rule them all when obviously it is not, and to relegate/delay other engine optimizations for a couple years (mostly 2018/2019).

If DOTS had been sold from day 1 as what it is, just another cool tool in the engine that does wonders for certain games, safe to ignore by others, I think nobody would be bitching about it. It doesn't help either that general editor performance was really bad though 2020/2021 and that it missed the .net5 milestone (work on that front started too late. Fortunately there are good chances we get .net6 this year).

 

Completely fruitless conversation, but what did I expect by delving to a post about DOTS. Does it hurt your very person that someone criticises something you clearly have swallowed without any critical thought? I could bet pretty much anything on the fact that Unity deeply regrets the path it took, and I'd bet as much on it not catching on (as it shouldn't).

The entire point with DOTS is to allow for a more efficient architecture. But the problem is that instead of optimising their engine they added a new (very flawed) technology stack. If they had spent the time they spent on DOTS on optimising the engine internals we wouldn't be in this situation. They could have optimised IL2CPP, they could even have introduced a more efficient compiler, but kept most of it under the hood. There is absolutely no reason to make all of that user (developer) facing while inventing a new language.

They are throwing out everything that makes Unity Unity (tools, .NET ecosystem etc.). It is a very immature decision.

By your logic, I quote, "Second, You have no idea what "optimizing engine internals" even means. What engine internal could Unity optimize that they didn't do? Please provide examples of modules that can be optimized. (Don't forget to mention HOW they can be optimized)" the entire DOTS stack is unnecessary. If you have so many objects that cache alignment becomes an ACTUAL bottleneck then we are talking about such a scale that how the objects are handled (i.e. the engine side) becomes very important. This is not a fruitful conversation at all.

But as I said I have said my piece on this and your attitude isn't conductive for any further conversations.

Thank you.

 

That's definitely an April fools by the way.

 

I recognize that you don't like DOTS. There are completely valid reasons for not liking it. Some people will never be able to successfully reason about its paradigm due to the larger base context DOTS requires you to work with. I can provide a lot more insight as to why different individuals and teams may have drastically different views of and success with the technology, but there is a deeper misunderstanding I want to address.

Let's imagine you are making a game, and you get to decide what 10% of your developers work on. Which would you rather have them do? Make a couple new levels with a couple new mechanics? Or make a level editor that players can use to build and share their own levels? I can tell you that unless I lack all faith in the game, I would choose the latter any day.

Now let's look at things from Unity's perspective. Which would they rather do with that 10% of the team, optimize a couple more features? Or build a new API that let's developers create custom implementations of features without any performance penalty? Unity picked the latter, especially since they already have other teams within the other 90% which are modernizing the runtime and making their existing features faster. How effective those teams are is a different matter.

Did you know that you are paying a .NET performance tax, even with IL2CPP? Managed memory fundamentally prevents the runtime from performing those optimizations, even if you have so few objects that your entire simulation fits in cache. By having all your simulation data in unmanaged memory, the Burst compiler can bypass those .NET restrictions and make your simulation faster. If you have a CPU bottleneck, that means your CPU is doing too much of something. Whether or not DOTS solves that depends on what is doing. But just because it is unnecessary for you doesn't mean it is unnecessary for others.

 

Or maybe doing data oriented programming with C# was not a great idea.

Also, I'm super tired of this argument

It's so convenient and you can apply it to anything and it means nothing at all. You can flip unnecessary to necessary and have it be a counter argument to all requests as well.

So here:

Just because it is necessary for you doesn't mean it is necessary for others.

 

Why not? It seems like the performance numbers are on DOTS’s side, no?

 

Overhead of the language really isn't a bottleneck so it doesn't matter at all. This is 2022 but the conversations here make it sound like 1995. Very few games are CPU bound to the degree that it becomes a bottleneck. A very very very small faction of those games are further limited by cache alignment or language overhead or any such thing. DOTS is almost akin to recommending assembly because it's faster, when in reality it has a detrimental impact on productivity and in the real world it wouldn't even tackle the actual bottleneck.

The entire discussion is weird to me when even the public Unity APIs are riddled with low hanging fruit that could easily be addressed first. I'll give you a concrete example -- I'm just now writing some editors tools that analyse tremendous amounts of content that get executed at build time and manually through some editors, so they have a direct impact on iteration time for the game developers. Yet the Unity APIs, such as AssetDatabase.GetDependencies, accept arrays and not ICollections or IEnumerables. This means that when you dynamically construct the data (that can be tens or even hundreds of thousands of entries long) you have to convert them to arrays for no reason. That right there is illustrative of how misguided it is to think that language overhead or cache alignments would be a bottleneck, when there's tons of things in the engine internally and in its public APIs that should be fixed, and that may actually even have a small impact on performance. Data structure choices and similar have a far larger impact on performance than using actual assembly language or a silly new language could ever have. This really is tech porn at this stage.

Thank you.

 

I'm holding final judgement until 1.0, but the amount of boilerplate and syntax convenience are much worse than in languages that are more suited to DOD patterns.

 

That's only true because there are very few HDRP games.

 

Apples and oranges, is it not? This sounds like a tools-based production issue. DOTS targets runtime performance.

 

Personally, I hope that user-authored SourceGenerators can end up helping with this. Not sure when that’s be supported for DOTS code, though. Probably only when the Entities package supports at least Unity 2021.2.

 

DOTS won't be the reason for AAA developers to start using Unity, if that's what they are hoping for. There's a LOT better engines out there for AAA development.

 

Well that’s certainly a grumpy attitude!

 

It was an example of how the user-facing APIs (in the runtime and editor sides) are riddled with low-hanging fruits and bottlenecks to the degree that talking about the overhead of the language becomes ridiculously moot. I thought it was obvious from the context.

 

I think we should reserve judgement for when DOTS 1.0 is out, but it has to be so good that it was worth Unity abandoning the rest of their feature set in favour of DOTS.

 

But fixing problems with editor script APIs won’t change language overhead.

 

Grumpy attitude? No, I love Unity.

But it wouldn't be my first (or fifth) choice for AAA development. Unity has an incredible market share right now but once again, not in the AAA space and that it will never get (and why would they even aim for it?).

 

You really really don't get the point, do you? The point I am making is that the public facing APIs are riddled with bottlenecks to the degree that even mentioning language execution overhead is somewhat ridiculous (which it would be even if the public facing APIs were "perfect"). I just gave an example that HAPPENED to be on the editor side as I was just writing such code, but these low hanging bottlenecks all over the place.

 

That sounds like saying that it’s ridiculous to fix your car, because your house needs work.

 

I have no idea what you are talking about. As I said all their public facing APIs have such problems, both on the runtime and editor sides. Fixing the public APIs would take a few days and give more performance boost to Unity games than the last five years working on DOTS has yielded. If the public APIs have such glaring performance bottlenecks imagine what the insides look like. If they had spent five years optimising them and gradually introducing more efficient constructs games would perform better. If they had spent the same five years working on lowering iteration time in the editor and better tools people would be more productive.

 

You're off topic for this sticky. People who really appreciate DOTS like me would rather you put your opinion pieces on the direction of Unity in your own thread.

 

You are right and I apologise, this is not the place for it!

 

It’s a good thing to bring up in another thread. Thanks for being cool about it in your comment, above.

 

I also agree with this. And if you thought otherwise, then you missed my point.

I believe this discussion is resolved. Thanks @Shinyclef

But I would like to provide an anecdote for anyone reading and wondering what a real-world problem is that doesn't involve many objects but is impossible without DOTS (at least in Unity).

Back in 2017, I was working on a game in which I needed the ability to raycast skinned meshes in order to obtain UV barycentric coordinates. For just six characters, this cost me 100 milliseconds for only a few raycasts. That was using Unity's mesh baking. So instead I replaced it with a custom C# raycaster that iterated through each triangle in the mesh. Even for a single mesh and a single raycast, doing the minimum amount of work possible, it was slower than the PhysX-based codepath. With DOTS, my custom code takes microseconds. My use case was unique, and it would have been unreasonable for me to expect Unity to change their PhysX code and API specifically for me. If they optimized my use case, they might have also created a regression for a more common use case. These types of situations happen a lot with any game engine, especially if you are trying to do something original.

The most important thing is that we be as concrete and honest with our problems as possible, using the correct channels. The system isn't perfect, nor is Unity, but the more we can help them understand our needs, the better they can prioritize the right people to work on the right issues.

 

Just to answer the questions which haven't been answered,

Check out ".NET Future Development Status". You will find that these changes are in progress, regardless of DOTS - moving Unity to .NET Core is expected to bring performance improvements and integrate Unity better into the modern .NET ecosystem (NuGet, .vsproj, source generators, etc.) in the near future. So that'll be a step towards optimizing the engine and integration with the .NET ecosystem.

The thing about reversing a negative statement is that you're reversing a negative statement and not a boolean. This argument is simply a strawman and flawed. DOTS is being worked on because it is very useful for many people. The fact that the inverse makes it not useful for some people is irrelevant. Games have already been shipped with even the experimental state (see Diplomacy is Not an Option, 1740 positive reviews on Steam), and many of us would like development to go on. Further development will only iron out the issues and make it even more accessible, making the inverse argument even more irrelevant. Either way, it seems Unity will be able to work on other better features regardless of DOTS, so I disagree with the general sentiment of some people that DOTS is harming Unity.

 

And you are basing your use of “many” and “some” here on….

And if I switch places to those two words and say the same thing back to you would be wrong because, what? Because a handful of people used it to make games?

 

From what I see after they iron out DOTS, they can use it to improve engine internals and editor.

 

It's fruitless because you simply are clueless to what are you talking about.

And again, you don't say HOW something can be optimized. Everybody can come and say "optimize X, optimize Y", but when it comes down to what is actually wrong with a system and HOW it can be improved, everybody crawls to their basements.
As far as I'm concerned, Unity is optimizing their entire engine internal by converting it to DOTS. So I'm pretty fine with that.

 

Editor and runtime performances are two different things, with two different teams working on it.
Also, if an editor function causes problems for you, try creating a forum post or filing a bug report. That way you can actually notify the developers instead of being salty and ranting in an inappropriate place.

 

More than 2k now btw (Very Positive btw), and we just a 2 months in early access.

 

just to respond to that: there is almost 0% chance that we get .net 6 this year. if you look back at the thread you'll find a relatively recent official post where i ask someone from unity how long it still takes.
the answer was: a preview of the .net core transition is expected to be close to .net 8.
so that's still approximately 2 years

 

That's what worries me a lot. Asked on the forums a few times, but seems there's no real answer as to why C# is really the best choice here.

If the goal is best possible native performance, maybe it would've been easier to use the best possible language for it. Obviously not easy to start from scratch with a different language, but seeing how hard the DOTS team worked to bend C# into what it's not, it seems they could've pulled this off.

First principles and whatnot.


Atm we have to throw out most of C# language features (classes, standard library, any other existing library needs to be converted to Burst, etc.). But we still have all the downsides of C# (need native compiler, GC, arrays are heap allocated by default, need native arrays, etc.). And an enormous amount of engineering necessary (it's been 4+ years).

@Tommigun1980 's phrase "technology porn" seems not too far off.
Consider IL2CPP for example. It's been years, and it still has way too many bugs.
Where as native language's compiler is virtually bug free. C++/C/Rust compilers just work.

I hope DOTS happens and becomes easy to use.
Would be great for MMO scale projects with our favorite engine.
There are valid concerns though.

 

The boiler plate is not bad if you limit yourself to a very basic design and make all your code static, which is totally possible. Where HPC# falls down for me is working with memory management / pointers it just feels tacked on and foreign. You can limit yourself to ref, in and out and that can mostly work.

If you want to use data structures then the experience is far below a language like C++. ECS itself is also not friendly to persistent data structures. Developers on this forum come up with Rube Goldberg machines when they could simply use a data structure.

 

Can I turn this around and ask you? Because I have the opposite viewpoint, why something else than C#? What would be the best possible language for this? Also, how would "the best possible language" be exposed to us, and would people be happier if they had to constantly switch to an entirely different language with different rules rather than using a subset of the language they use every day? How would you communicate between the languages and re-use code in that situation?

I'm not personally affected by the "downsides" of not being able to use everything from C#, though I understand the annoyance. However, only being able to use a subset of the language hasn't been all negative. Performance is an obvious benefit, but also stuff like leak detection (hunting down memory leaks is way less fun in other languages in my experience) and deterministic race detection.

 

It also applies to other languages, if you want maximum performance then you only use a limited subset of all features because many features may make some things easier, but also produce overhead.
E.g. C++, if you want the maximum performance, you do without smart pointers and use C raw pointers. The overhead may be small, but it's there. That doesn't mean that you should do without smart pointers entirely, only where performance is important.
I use struct in C# where possible. In an experimental .NET6 project I even have my own unsafe allocators and buffers (an attempt to implement my own ECS with .NET6)

 

I don't think its to do with performance, but with the safeguards against programmer error. Allowing everyone to write near-optimal multithreaded code without worrying about race conditions or memory layouts. And being able to still build the game to all different platforms and using all CPU instructions available on that device.

For me getting a huge performance boost without changing IDE or/and language feels nice. I also really rely on unity throwing good errors/warnings after a code change with ECS. There is always something I forget to dispose.

EDIT: looking for a reference to this claim I found Joachim saying it is performance that reduces the need for C++. Guess I mis remembered something.

 

Sure.

C# is great, way easier to use than C/C++/Rust/..
HPC# still seems easier to use than C/C++.

HPC# seems noticeably harder to use than Rust though.
Not a surprise, since it's native to begin with, memory safe, protects against data races, no GC, etc. All the things that Unity is trying to solve so hard here.

Not saying Unity should use Rust.
Was just curious if HPC# + Burst actually becomes easy to use at some point.
Or maybe it's just me

 

I hate to say this to you and I understand your frustration, but you don't completely understand what you are talking about. First of all Unity has been optimizing editor internals. Burst and jobs system is part of the stack and its working.

Ecs which is a relatively "small" part of the stack allows you to do things you can't do with mono behaviours no matter how much you optimize it. Any attempt to try to create a simulation or strategy -game ends up in an optimization hole. Everyone who has had to go through that knows that ECS like this is the best tool for the job. Simply because it can and is designed for that.