Question DOTS scale & Use cases

It's hard to provide a number for this type of question as there isn't really one, but I'll provide some info that hopefully is helpful.

DOTS can be used a la carte -- you don't need to adopt the ECS from Unity.Entities directly for your game, and can instead take pieces of DOTS like jobs, burst, collections, math... but you may want to adopt Entities depending on what problems you need to solve.

The Job System will enable getting computations off of the main thread on to worker threads letting your game's performance scale with your hardware.

To get the most out of your jobs, they can be aggressively optimized using the Burst compiler. This lets you put even more computation into your game.

Now you might run into some problems moving code into jobs or getting your jobs to be Burst compiled. The data need in your jobs might not be easy to access, and/or might not be HPC#/Burst compatible. The data might not provide thread safety guarantees etc... The Unity.Collections package provides containers that make writing HPC# code the default way of writing, and provides thread safety checks when writing job code.

But maybe you need data in your jobs that comes from somewhere where HPC# wasn't available/didn't exist. You end up having to transform and/or copy data from one location into a form that is ready and safe for your Bursted Job code -- it would be nice if the data was already accessible in a way that works well with Jobs and Burst. This is where Entities can help. Entities provides a means to write gameplay code that puts the data required to solve problems at the front of the design process and provides a means to accessing data that is laid out optimally for HPC# jobs to consume. This allows the scaling by design.

If you have 10 NPCs with complex behaviours, you should consider what data those NPCs need to perform their behaviours and how will they access that data. Will their logic be so expensive that it needs to run off the main thread? Will your game change where you might now need 100 NPCs? 1000?

The answer to these questions can help guide you to which DOTS tools you may want to adopt in your project and how much you want. This is of course only a very high level view of DOTS as there are some concrete features like fast streaming that become possible when adopting Entities for more of your game, but if you just want to move some computation off the main thread you can begin your adoption of DOTS with jobs, collections and Burst. The scale of objects you need for when DOTS makes sense is up to you. But if you start with ECS from the beginning, the scaling is possible from the beginning.

Hope this helps!

 

> I haven't fully implemented all the features I want in NPCs so should I switch to DOTS and ECS right now?

It would be good to look at why it's slow right now. Is all the work on the main thread delaying other work from occurring? Is accessing all the data you need for each NPC resulting in random access to memory?

DOTS will help your code be optimizable when you hit performance bottlenecks. For your NPCs it sounds like there would be potentially many of them, being simulated to do various things. I agree, scaling back how complex NPCs are via LOD'ing will be useful (DOTS or no DOTS) as most of the time not all NPCs are visible so you don't care so much if they are animated, or even update their logic state as often as one on screen. Unless core to the update loop, they also end up being good background processing tasks that are rarely waited on to complete, so offloading their logic to jobs tends to be a good performance win.

When in doubt it can be helpful to try a small experiment where you port a small example of what you're doing to DOTS to see how it compares, and to iterate on what is slow and how to improve performance and scaling. I do think DOTS will provide you with a good foundation for allowing your game to run well now and as you add more features, but it may require some changes to how you have written things, so best to experiment on something small first.