Discussion Using DOTS for casual mobile game dev

Hello everyone!

I'm in a bit of a choice paralysis as I'm researching the best option to create a casual mobile game.

What I'm struggling with is the decision about which work flow to chose (ECS + DOTS physics or GO and Physx).

The game won't be anything complex (1st real project for me) and will contain a small number of moving rigidbodies and the levels on which they move (which might contain moving platforms/walls, exploding traps, areas which slow down or speed up the objects). Think about something similar to a mini-golf game in which you 'shoot' some objects around with the purpose of scoring in a goal.

I don't mind the learning curve of DOTS and why I keep thinking about choosing this flow is the promise of efficient power usage of the mobile devices.

What does the community think? Is DOTS an overkill for a game similar to mini-golf on mobile?

Thank you!

 

I don't really have a strong opinion here. Go with GameObjects if you want mature editor tooling, better 2D graphics/physics support (if you're making a 2D game), and more docs, examples and tutorials. With ECS you will get better performance (but not rendering performance on mobile, currently, I think; see threads here and here; but ECS might still pull ahead because of physics, game code, etc), and better future proofing.

Keep in mind that it's almost impossible to use DOTS without at least some knowledge about the classic parts of the engine, so you might as well learn them first. (The baking workflow, as well as many Entities Graphics features depend on GameObjects and classic components, and attempts to avoid them at any cost are usually misguided.)

DOTS is almost there, but I wouldn't recommend yet unless If you have an engineering mindset and want to prioritize learning and long term growth over getting things done ASAP (and getting things done is extremely important for staying motivated for most people).

 

For a first project, limiting the amount of issues you can walk into is a good thing. If you already know you don't need the CPU performance, just skip ECS for now. Physx is not that bad performance wise (especially since unity made ECS Havok Physics only for Pro/Enterprise subscription).

Should you run into the game not being performant enough, you could still investigate if an ECS version would solve this. By this time you will know how the game feels and if people like to play it. The art/sound/look/ect would be the same anyway.

If you do want to use ECS, that is also fine. I like it a lot. The forum is also pretty active and most people are really nice with their knowledge and time.

 

I would say when working with DOTS, you need to have strong knowledge about c# and Unity API and understanding how to work with source code and docs.

If you got that, sure go ahead with DOTS.
But if you are uncomfortable and don't need massive performance gains, just stick to Go.

However, maybe better option for you is to mix both. Skip ECS part, and focus on using burst and jobs when reasonable. Learn about DOD/DOP. You will be easier to move into DOTS deep diving, in your next project.

 

Is there a resource or guidance for how to use burst and jobs for a typical application? Meaning, if I already have a working/finished game that performs reasonably well, what steps would I take to burstify a few of the more time-consuming parts of the code?

I don't have a game I'm working on currently, but I would imagine the first step is to open the Profiler and identify what are the heavier parts of the game. Typically for my games it would be something in an update function like checking a raycast to something or possibly loading from a database object. Looking through the examples here: About Burst | Burst | 1.8.7 (unity3d.com)
I don't see examples similar to what I usually work with and am having trouble understanding how to get into using Jobs/Burst.

 

Hey @Voronoi,
My DOTS learning is based on years playing with it.
I have used Unity ECS samples and DOTS source code. As well as Unity forum, to learn things about DOTS, that includes Jobs, Burst and ECS.
https://github.com/Unity-Technologies/EntityComponentSystemSamples

With ECS forum you are already familiar.
But Jobs and Burst forums has been separated and moved to Scripting
https://forum.unity.com/forums/scripting.12/

Today we have DOTS best practices, which can help kick-start into DOTS, for your convenience.
https://learn.unity.com/course/dots-best-practices

Since you want to focus on Jobs and Burst, the good starting point as you noted, is to find bottlenecks. Using profiler will help you a lot here.

As second step, is to start converting part of the code from OOP to DOD. Meaning reducing monobehaviour classes, converting classes to structs, reducing managed collection to native collections, like Arrays to Native Arrays for example.
This movement alone may be quite challenging, based on the existing project design.
But if you build brand new project, then it is much easier to follow DOD principles.
Since working on structs, you need to eliminate MB inheritance and nesting classes workflow, for the code you are converting, or building. Saying that, you can still nest structs, but it is more limited than classes.

When you start creating methods, which uses native data, without managed type data, you can start applying Burst.
That will be first significant improvement.

When you considering moving further, you can start using Jobs.
So you want for example pass NativeArray of struct data to job, and iterate it over inside job.
Mind, that multithreading become more performant and useful, if you integrate over 1000s of elements.
While you can iterate over 100 of elements just fine, it is best to either make such jobs single threaded, or use multithreaded jobs, when calculating large computationally intensive iterations. For example A* pathfinding for many units. (Mind, for RTS like, with tons of units and large maps, you would rather use flow filed, but I hope you see my point.) In other case A* may be more than sufficient.

So you can easily work with above, without Entities from ECS.

Additionally, CodeMonkey and Brakcleys tutorials on DOTS are good informative ways, to learn, but please note, they may be out dated, as DOTS evolves rapidly.

Additional links, more focus on ECS however.
https://dots-tutorial.moetsi.com/unity-ecs/intro-to-unity-ecs

 

If you can identify (or fabricate ) a piece of code that only touches unmanaged structs (eg.

float3

/

Vector3

, native collections) and has no side effects, you can extract it to a static function and put

[BurstCompile] 

on it. This is often enough to make hot paths disappear from the profiler, and has much less overhead than the Job System, which isn't always worth getting involved.

See for example: DirectCallTest.cs#L40C21-L40C21

You sometimes need to move code and data around a bit to make it work, eg. by packing data into NativeArrays (or better, creating a NativeArray view of a managed array). You often end up with static functions with a huge number of parameters.

(Note that structs can only be passed to/from the function using

in

/

ref

/

out 

parameters (typically

in

), and the return type needs to be primitive or

void

.)

 

Did they ever fix the ECS crashes on Android?

 

I'm assuming they're treating all crashes as bugs. Have you tried filing a bug report? You get a link to the ticket and can track whether it got fixed and in which Unity versions. It's really quite convenient.

 

Which means they close them with "can't repro" / "won't fix" / "by design"?

Burst used to cause a bunch of issues on mobile, even just having it in the project last time I tried (although... it was a year+ ago, so probably not much has changed on that front).

 

This is helpful!

I don't recall seeing this before, or the last time I checked a DOTS tutorial it was much more complicated and I couldn't follow it.

Seems the best path forward for me is to just try to use Burst and start learning to design with structs and native collections. I tend to just code with what works and only really investigate if there is a problem. I'd love to learn DOTS, but it has not 'clicked' at all. Plus, it keeps changing and so I'm waiting for it to settle down and mature. Burst seems like a good starting point though!

 

They sometimes do, but sometimes they also update you later when it turns out that they've found a repro, or a duplicate issue gets fixed, etc. I think it's worth it. YMMV.

 

I have never found it to be worth it.

 

Burst and none ECS based jobs didn't change much since long time.
Their syntax is closely the same as year ago.
We got however SystemBase and ISystem, where second one is relatively new and allow to all code be bursted inside. But you should be avoiding managed data types to get it working correctly.
While SystemBase allows for manage data type, yet there is limit what can be bursted inside of such systems.