Question Whom is DOTS for?

It looks like an idiosyncratic set of patterns, pretending to be decoupled, that disguise a strongly coupled networked first person shooter engine built out of a collection of names that are near zero value independently. So if I am not developing a networked first person shooter, why am I better served by DOTS than the existing workflows in Unity?

 

1) Performance
2) Execution Order Control
3) Write code with a god-like perspective rather than a bunch of defensive self-centered reactions to an abstract spaghetti.

Not everyone cares about those three things. If you don't, then don't worry about DOTS and just do things the way you like to do them.

As for the different packages, I personally don't use Unity's Physics or NetCode. I mostly use Entities and Graphics which are both powerful not so much in features as much as how much they let me get away with while staying within frame budget.

 

Apart from what @DreamingImLatios mentioned Dots provides you with the following:

1) High performance, close to the metal performance, and very simple multithreaded execution
2) One of the best and feature-rich stateless physics engines currently available
3) One of the best and highly performant networking solutions currently available which can handle networked physics, prediction, and rollback.

High performance is not only important if you want "lots of things", high-quality multiplayer experiences will slice through your framerate easily if you want to have predicted user input for responsive gameplay. In addition, high performance is crucial for mobile and XR devices to reduce battery drain.

 

Does it have Continuous Collision Detection already ?

 

Yes according to @steveeHavok:
https://forum.unity.com/threads/how...through-a-thin-collider.1125368/#post-7235777

 

One doesn't simply judge code by its looks.

 

One of the less...nuanced applications is creating a game with a ludicrous number of entities. You can simulate hundreds of thousands of things with excellent frame times!

 

There are two main qualities, as mentioned previously:
1. Performance;
2. Code quality;

Its way faster to stack features & make adjustments for the code with DOD & Entities.

Simpler to maintain, and in a more readable format.
If something breaks, you'll know it before actual playtesters run builds. Gamebreaking bugs usually mess around with multiple systems, so you'd see when something isn't right.

So its less time spent on QA as well. Plus, there's test coverage.

And as a bonus, you can make code multithreaded with ease.

What was our recent commertical uses of DOTS:
- Multithreaded vertex manupulation for simulation games
(there's a great asset for writing custom mesh manupulation jobs called Deform);
- Custom physics & rendering for 2.5d games using Entities, Jobs, and Burst which allowed to squeeze extra performance for some mobile hypercasual games;
- Simulation logic for hypercasual games (Entities, Jobs, Burst);

As for my personal project:
A singleplayer FPS, but rather on Serious Sam / Path of Exale scale of game logic.
Which involves running lots of mixed AI, such as boids, default AI behaviour trees, projectiles, weapons & their interactions, game logic and much much more.

I find it easier to optimize based around systems, rather than MonoBehaviour Updates or custom update methods.
Uses Entities, Jobs, Burst.

DOTS itself is really versitile, and I'd dare to say you should probably use at least something of it for any game.
Jobs can be used separately from Entities, Burst can be called from managed code for extra optimizations. Its worth learning overall.

 

Why do you say this? FPS games are very few in the showcase thread or in games that are in production or released.

 

OP probably need to see this thread
https://forum.unity.com/threads/share-our-dots-showcases.1010215/

And the thread of one DOTS released game
Diplomacy Is Not An Option
https://forum.unity.com/threads/unity-dots-case-study-in-production.561229/

 

Having shipped a Unity ECS powered game over 3 years ago and next moving to a more traditional OO approach in a different studio, I can say that I miss the performance, code design, scalability and the perfect sense that ECS codebase makes

 

Do you not just try using OO in a DOTS manner in that case. I know I would, I would at least keep the data and the transforms of the data separate, as much as I could.

 

Yep, we're obviously separating the view from simulation as much as possible we also have most of the logic in MVVM, so a middle ground is possible. It all depends on the scale of the game, codebase, the performance targets etc. In my after hours project, I'm experimenting with merging some DOD/ECS concepts with OO. I'd prefer it to be fully written in ECS but as this is something I'd like to ship I don't have time to write everything from scratch, more so when I'm writing my own networking solution for the project. It's all a balance of resources. In the RPG I'm working on, we're at a point where perf benefits from dots would guarantee our vision and simplify a lot of the complex systems and online sync. over 4 years of production stack up in the code a lot

 

@mmankt When I dabbled in DOTS years ago, I thought it's definitely the future while also being a different paradigm. I didn't spend enough time to get it at the time. Tried the new 1.0 temporarily, and still yes love the different paradigm but not sinking in unless I focused on fully getting it. How long did it take you to make it feel natural? I'm sure if I got it, I wouldn't look back!

 

It was pretty fast, actually. We took 2 weeks for research, 2 weeks for prototyping in Entitas and Unity ECS (it' was one of the very first versions with almost no documentation ) to get a hang of how and if we could use it to develop a game. Then we started with implementing basic functionalities. What helped was a good base technology design (basically an RTS engine where everything except rendering was custom-made), so we moved feature by feature, discussing how each thing should be designed in ECS, what data we need, what each system should actually do. After 1 month of dev when the base of the engine was working, it started to feel completely natural. However, I had a team member that was really frustrated with how we had to do things, always talking how it would be better in OOP xD So it may not be for all.