Feedback Why should I use Unity's approach to data oriented programming? (unity DOTS) over other systems

So i'm ready to start Unity's DOTS to explore data-oriented programming however I want to justify using Unity's implementation over other systems that may or may not be out there. So my first question would be is anyone aware of other systems out there, as I struggled to find any other data-oriented systems for games.

My next question is why should I use Unity's approach over another, the only reason I can currently find is i'm experienced with Unity however that isn't a real justification more than it is a preference.

 

What is your use case?
What are your goals?
What do you want to learn?
What are your requirements?

There's plenty of alternatives out there. It is all about choosing the right tool for the job. One thing that is very unique about Unity's approach is that it uses C# and has a specialized safety system to avoid race conditions, all that on top of authoring, asset management, and build tools that have been with Unity for a long time now.

 

• My use case is using data-oriented techniques in the context of video games. Aiming to create a application with a large amount of entities to prove the performance gains from data-oriented principles. My ultimate goal is to prove that a data-oriented approach is better than a OOP approach.
  
• My goal is to compare the performance of OOP techniques agaisnt data-oriented techniques.
• I want to learn how to use utilize data programming patterns in a games context and learn specifically what's happening at a machine level, (cpu usage, fetch/execute etc.) to really understand how data programming can assist game development. I also want to learn how ECS systems are utilized in games to create higher performance over traditional systems.
  
• All that I require from a system is a framework I can use to test data-oriented techniques in practice and in the context of video games, entities, animation, physics etc. I also require benchmarking tools within the system so I can analyse and evaluate performance.

And to add on to this, would you be able to refer me to some alternatives for research purposes as i'll need to look over other similar systems and see how they approach data oriented design.

 

This goal might be a little flawed. First, DOD vs OOP isn't as black and white as people make it out to be. It is really a spectrum. Right now in Unity's ECS, systems are class types designed in a very typical OOP fashion. They cooperate to process a database of entities and components. In a more OOP-like engine, odds are particle systems are probably more DOD than OOP when handling the individual particles. And then there's approaches where archetypes are objects and interact with other archetypes in OOP-style but internally store the instances in SoA.

You might want to use C++ for this if you want a proper apples-to-apples comparison.

And this is where you will find a lot of value from Unity's ECS. It really highlights the strengths of DOD because it provides a lot of tooling for profiling and inspection.

You can find a few of them just by searching for ECS libraries in C++. I've used a few of them in the past, but it has been a while since I used them and those projects are on an old backup drive so I don't remember which ones. I ended up making my own little framework that wasn't quite an ECS, it was more like an ES, where Entities were strongly typed but stored in SoA. Systems executed fully synchronously (no jobs), but some of the algorithms could go wide on all threads.
Then I switched to Unity because of collaboration and VR opportunities. And then DOTS happened.

I also recommend reading Richard Fabian's DOD book if you haven't yet.

 

Currently working my way through the online version of this book, i've found it really helpful explaining DOD and has been great so far.

So are you saying if I were to compare classic Unity with Unity ECS/DOTS it wouldn't be a fair comparison? And if that is the case could I potentially bend my goal a little to compare an application in normal Unity agaisnt a Unity DOTS application to see which areas of each are better or worse. Apologies if my goal is a little foggy i'm still trying to refine exactly what I want to get out of this. However ultimately I want to uncover the advantages and disadvantages of DOD in the context of games.

Also I see you mentioned the Unity's Burst which handles jobs. Could this be a selling point of Unity's DOTS implementation?

Thanks for all the information thus far, it has been really helpful.

 

It will only be fair in the context of Unity. Once Unity's old Mono runtime gets replaced, it might be fair in the context of C#. It will never be fair when generalizing to other languages like C++.

I didn't actually mention Burst. But the job system with built-in thread-safety is a huge selling point. The Burst compiler is a totally separate beast. If your goal is to understand things at the low-level, the Burst compiler is an incredible tool as it lets you look at the generated assembly for a single job.

 

That makes sense ideally I just want to explore advantages and disadvantages so it wouldn't matter what language i'd be using however I think i'll be setting my eyes on Unity DOTS once I can confidently justify it. That being said what would you recommend to prove my goal as I think i'll go with comparing traditional Unity with Unity DOTS. Just want to make sure there's enough for me to make evaluations about DOD as a pattern/technique.

I'll have to read up more on the job system and the Burst compiler, are there any sources you'd recommend for finding our more about these?

 

For the alternatives the first one that comes to mind is Entitas. Also there is Svelto.ECS being developed by @sebas77.

As for picking the Unity DOTS, probably the most important reason is the official support. Hopefully they will integrate the system into the engine deeply, so developers will experience less friction.

Another good reason is performance. They are going pretty hardcore on optimization, and they are still yet to finish.

 

What specifically do you mean by official support do you mean things like the Unity forums and documentation? (Sorry if i'm misunderstanding)

Would you be able to elaborate a little more on what kind of optimisation and performance gains Unity has compared to other systems. Are there any good sources or anything you know from personal experience to help me solidfy optimisation/performance as a reason to use Unity over other systems? (Thanks for naming a few alternative systems, I will get to researching them.)

 

I can't recommend anything. There's no silver bullet, and modern game dev is all about choosing the right tools for the problem. You are trying to pick a problem for the tool, and that will only prove or disprove your goal for that specific problem.
The best I can do is share my itch page. All but one of those games (LSSS) were made in weekend game jams, and of those, all but one were made in DOTS. (LSSS is also made in DOTS and is open-source, but it uses my custom framework so make of it what you will)

There's a ton of resources. The problem is that they are all scattered about with varying up-to-date-ness. I've unfortunately been around this space so long that I am out-of-touch with what the best beginner resources are. However, if you have more specific questions, feel free to ask me and I can probably point you to something if not just straight up answer it.
Also, if your goal is to learn DOTS, you might be interested in this: https://itch.io/jam/the-dots-challenge
I'm not the host. It was just something I stumbled across. I've always used game jams for learning and evaluating new technologies.

 

I suppose it's "support" in the sense that while it's entirely possible to make an ECS and job system that rivals DOTS by yourself, if you use DOTS you can work on just making your game while an army of Unity engineers works on the core tech. DOTS will also be deeply integrated in the engine, contrary to third party solutions.

Moreover, I wouldn't feel super safe about using a third-party ECS for Unity right now, because I have no idea if the authors will keep supporting it now that DOTS has the spotlight

I'm not sure if you're talking of performance gains of DOTS unity versus OOP unity, but in general it often happens that a quick straightforward implementation of something in DOTS performs easily 10x better than something you spent a lot of time optimizing in OOP unity. (Gross oversimplication, I know, but in practice that has consistently been my experience with it)

The main reasons for this are:

• Easy to multithread
• Easy to do linear data access
• SIMD

If you're talking about comparing to other ECS solutions though, I'm not sure there is a lot of data about this. "ECS" is kind of a vague concept. You can have an ECS with GameObjects and Monobehaviours if you want, you can have an ECS with or without multithreading/SIMD, you can have an ECS with or without linear data access, etc.... so I don't think anything that is called an "ECS" will necessarily be something that can be compared to what DOTS does

But I think the general opinion is that DOTS is a very solid ECS that does a lot of things right, both for performance and safety/ease of use. It's difficult to compare it to other techs, because you would have to build an entire complex game in both tech stacks in order to have a comparison that really means something. The only comparisons we have are performance benchmarks on relatively straightforward operations like computing a mandlebrot, n-bodies, etc... these tests really don't show the full picture, and they only focus on Burst which is only one part of DOTS

You'd also have to quantify how much work was needed to make the game in both tech stacks. If the game in TechA runs at 60 fps and took 2 months to make, while the game in TechB runs at 70 fps and took 1 year to make, TechA is arguably much better in my eyes

 

I think if you want to explore and compare, you just need to dive in and try it. Pick a thing or two that you setup in a typical OOP MonoBehavior + GameObject approach. Now try that with Jobs. Now add the Burst Compiler. Now try Unity's ECS approach. If you do that with a few things, you will learn a lot. That may be enough to answer your questions, but if not, it will give you the experience to know how to ask the specific questions you really want to know.

I do think, when you do comparisons of a single task, like say n-bodies, you won't see that many benefits of Unity's ECS (which includes bursted jobs) compared to MonoBehavior with bursted jobs. It is when you start to layer multiple systems that ECS really starts to shine.