DOTS (near) future

Unity Engine
, ,
1

I am new to Unity.

Soon after several 3D tutorials, blog posts, Unites and documentation pages, I felt I have acknowledged the Unity core concepts and decided to go directly full DOTS and grow with it. DOTS is still young and growing day by day, so, today there is no such approach to Unity as “full DOTS”, I am aware of this.

I see that the Hybrid Renderer V2 should be compatible with every pipeline soon in 2020 and the feature list is growing rapidly, the audio system is following and everything else moves in DOTS direction.

I wonder which path should I take to start diving gradually deeper in DOTS and be sure I don’t miss anything and don’t spend time learning things that will, maybe, become obsolete in a couple of months. I would like to give priority to things that are more stable, like ECS, Jobs and Burst, and be more cautious with “patches” more prone to melt down in relatively near future (is Hybrid Renderer one of those?), given the expected learning curve.

I found blog posts and instructions about converting existing projects to DOTS, but I am starting from zero and I don’t see a clear path to follow, any suggestion would be highly appreciated.

2

I suggest do not touch anything secondary-level to Entities such as GameObject, transform system, conversion workflow/live link, rendering, audio, physics, serialization, networking etc. just yet. Just pure calculation within SystemBase, treat it as an efficient table processor like Excel. You will still have a lot to play with and then you can watch those secondary systems from a far without risking increased tech debt to move along with them. Your only goal is to see Worker Thread rows in the Profiler coming alive with your game-specific logic living in them. This way, your technical debt is only half in the currently in preview Entities package, the other half is already riding on C# Jobs + Burst that is already out of preview.

Resist temptation to dive deep to those secondary area until everything came out of Preview and instead master the main Entities package. Only read code in the package if your are really interested. Rider is good on following code into UPM packages and really helps with learning.

Write tests to check resulting calculation so you have some defense against major changes in Entities package. (This is very valuable especially when they change things about dependencies and disposing, without tests it is disheartening on every upgrade because you can’t afford to not upgrade either in preview phase) Copy out the resulting calculation to use in normal Unity no matter how inefficient that may sounds. Even if it completely counters performance gain from your logic you have moved to SystemBase on multiple threads. I think that way it is more comfortable to learn ECS (right now) for new comers.

8 Likes
3

I’d argue the opposite – Entities package was hidden for a reason. Any large-scale game with ECS is going to require lots of tooling and work from you. Many features simply don’t work with it (and good luck with anything from the asset store or getting decent rendering performance in its current state). Most of my experiences doing something nontrivial with entities came down to “still working on it” or “it’ll be fine in the next version”.

Learn Unity by making a real, working game. Use jobs, burst, and native collections where appropriate for performance. These features are very useful and powerful, fairly stable, and mostly bug-free. They’re also the “basis” of ECS, so if you start working with entities, you’ll understand how job handles, etc, work. Come back to Entities when it’s more mature.

The 3 reasons I’d say to use ECS right now are…

  • You have a specific project in mind where it would be needed (eg giant battle simulator with 100k units)
  • You are a major studio with the time to invest in building tooling for it
  • You would rather spend your time learning it instead of making something (and have a computer engineering background/day job)
4 Likes
4

I’m making the assumption that you are a solo dev (or collab-ing with people of similar mindset) looking to learn and grow with future tech. That’s what I am too (albeit I have a C++ day job so this is just a hobby), and I’ve been exploring DOTS for over a year now.

With the exceptions of Jobs, Burst, and Mathematics, everything is preview. It will change. And those changes will break your project. Usually the fixes to those breakages result in cleaner application code (I’ve only encountered one incidence related to ComponentSystemGroups where this was not the case).

However, most of the learning curve is working with the concepts, such as jobs, Burst, NativeContainers, the ECS data structure, systems, DOD practices, ect. Once you get this stuff down, it becomes a lot easier to keep up with the changes.

I highly suggest starting out with very small DOTS games that you can put together in a short amount of time. Think game jams. It will force you to learn the basics quickly without having to upgrade a project. Bullet hells, space shooters, and similar genres are good places to start.

You’ll not only get a solid understanding of the concepts, you’ll also find specific pieces of DOTS that you will agree or disagree with. Typically, if you disagree with it, that means it is going to be a few years until it gets better. For example, I quickly learned that the DOTS Physics solution is insufficient for spatially-aware soft animations and trigger-heavy gameplay. So I decided to implement my own physics solution. Similarly, I realized that Entities does not have a good way of handling NativeContainers shared between systems, so I built a mechanism on top of the Entities package for handling that.

By doing small scope games in DOTS now, I am building up a library of custom tech that will rocket-start larger projects as DOTS matures.

3 Likes
5

Yes, this is actually the case :smile:

I am a C++ and C# programmer for 10+ years, I am not the best one around for sure, but I don’t get scared facing the possibility of having to play a lot with game/engine code. I played with almost every aspect of DirectX and OpenGL myself since DirectX 7.x and then, less than one year ago, decided to learn Unity and maybe become an Indie developer in the future, or maybe not. Let’s say I didn’t know how to spend my free time :wink:

Since DOTS looks like a lot to learn and I do not have a real world project or a job in the game industry, I decided to take my time and start learning the “future Unity” in advance. Of course writing little games to train myself is part of the plan.

ECS is in preview, true, but I honestly didn’t believe it’s still so broken as you guys point out. I am very curious about the solution you suggested: use Job and Burst without ECS first. I will take a closer look starting from them, and then find out what means to integrate ECS in the workflow.

Do you think is a reasonable approach?

6

Yep, I started that way too. Initially I used only Jobs, Collections, Burst and Mathematics, and ported parts of my planet generation system. That’s worked great. And when I became familiar with that stuff, I tried ECS. It was fantastic. Entities has some bugs (I am on 0.11) but nothing too crtical. I am constantly looking into changlogs, to always know, what will change and how costly it will be to move into new ecs version.
I am not touching Phyiscs, Networking and other packages. They look too unstable for me.

3 Likes
7

Well, I ain’t gonna stop ya.

ECS is good for “code-mostly” games, where things are procedurally generated and there are very few assets/little reason to open the Unity editor. The editor workflow requires you to know the old systems (MonoBhevaiour/GameObject) and converting it to entities. In particular, if you need any sort of custom editor/editor logic, you’re going to start running into major gaps IME.

1 Like
8

“Broken” isn’t the correct word here. Sure, there are a few bugs in the core ECS, but nothing you can’t work around usually. There are buggier parts of Unity not in preview. Really what preview means is that things are actively being developed and API may go through a deprecation cycle of 6 months rather than 6 years. Jobs and Burst without ECS is difficult to properly apply to small games. It works better to just program with MonoBehaviours and add jobs and Burst where you need it.

Really, I suggest trying both and seeing what feels more comfortable to you. DOTS is still early, and there’s a lot of missing features and higher level abstractions, but it lets you get close to the metal and implement what is missing (or replace parts you don’t like) yourself. Classical MonoBehaviours are the exact opposite in this regard.

I strongly disagree with this. I have found ECS easier to get proper tooling and intuitive workflows set up for artists while maintaining much more direct control over the runtime data. This is because the conversion process lets me clean up and analyze the data at large to make better decisions.

4 Likes
9

This I can agree with.

I’m a software developer working with Unity as part of what we offer for our clients (AR/VR, but mostly cloud-based from Azure). I know that DOTS/ECS is extremely beneficial for absolutely everything and unavoidable going forward, but sadly legacy and lack of time has kept me from going all in. So far it’s been the job system (it’s easy enough to integrate with Monobehaviours) and some repurposing of existing DOTS-tests. However, time will tell how DOTS will work with other external functionality like Azure functionality.

10

I’d say Hybrid Entities is great already. Using MonoBehaviours as a communication tool to the ECS world is quite easy now. Same tools that work with MB will work for Entities, because you’re operating on MBs;

Logic runs in ECS world, and MonoBehaviours only receive results / update state before running ECS simulation.
Major nuisance is actually making MonoBehaviours run this way.

If you’ve got a custom update manager its pretty simple to make it a SystemBase and run UpdateManager as system after ECS simulation.

I’ve been using ECS like this for some time (both in home projects and production) and its awesome. Logic that was previously impossible to multithread is now can be easily jobified. And what isn’t - most of the times can be bursted.

This actually really benefits mobile devices. So even without pure approach ECS is more than “production” ready, if you’re willing to run your logic / code in a specific order.

Yeah, new projects are easiest to push into ECS, but legacy ones can also benefit from performance improvements and cleaner code once you start moving things.

TL;DR: Go hybrid, its awesome even in current state.

11

This might be true in the simple case, or as long as you stay within the confines of Unity’s predefined tooling. But trying to extend the editor (or use entities at all at edit time) has been one frustration after another.

For a very basic example, the transform components (position, rotation, or just LocalToWorld/WorldToLocal) expect a transform system to be running. The editor only ticks this when it feels like it (eg when adding/removing GameObjects). Meaning that every entity you spawn in the editor sits at (0,0,0) unless you manually force an update (or they’ll randomly jump around when editing other things).

The intended workflow seems to be that entities are are a runtime-only thing. So if you have a semi-procedural world that you want to see in both the editor and gameplay, you need to make 2 copies of the logic: one using MonoBehaviours for editor, and one using Entities for ingame (and if you do that, and have fun managing play mode states…)

1 Like
12

Thank you all, really, all your precious insights and different opinions from different point of views make this thread great!

Ideas about DOTS starts slowly to take shape in front of me:

  • There is no turnkey solution about how to approach it and how deep to go
  • Background experience with Unity, type of application and global effort/budget have a great impact over the approach to ECS
  • Other packages like Hybrid Renderer, Physics and so forth can make a great difference but are clockwork bombs ready to rip your project apart. Use them if the effort is small and a modular approach can be taken
  • Jobs and Burst are mostly appreciated by everyone, so it’s maybe not a bad idea to focus on them first and drag ECS along in the experience
  • It’s the right time to learn, but it’s not yet the right time to look for details. Some things must be taken “as is” being aware that they will eventually disappear - recognizing those “things” could be not trivial though
6 Likes
13

This isn’t specific to DOTS. The same issue occurs for animated shaders too. There’s a way to regain some control over that.

I believe there’s a live-link mode that lets you preview an open subscene as entities. You can also manually tick a world to ensure it updates on changes. But yes, that workflow is a little rough yet. The DOTS team has been making changes in this area trying to stabilize it for the last 7 or so releases of Entities.

1 Like
14

I was using DOTS in GMTK game jam and I liked it. It was very straight forward. Of course there was some road blocks to overcome but all in all I think it was worth it.

1 Like