State of DOTS

Hello, I was wondering when the new DOTS system will finally get out of previews? I also wonder what Unity means by preview instead of beta?

Does that mean that if I make a project with the DOTS system, any update could potentially break them significantly? Or is it that it still lacks keys feature to be considered complete?

Also, is the DOTS system is meant to be the new normal by default, or it is only useful for AAA projects, like an RTS that has thousand of AI agents or HDRP project that needs every bit of optimization.

 

Bump. I saw that they recently removed some of the packages from "preview" status, which means that DOTS / ECS is probably not going to be released this year. But right now we're all in the dark, guessing and speculating so an update from the Unity team would help shed some light on it.

 

Oh man, I understand your confusion. Unity has sent very mixed messages around DOTS and ECS. Their marketing team pushing it as the greatest thing since sliced bread, and the dev team agreeing with them but at the same time saying "but don't actually use it - it's still not ready and super experimental - but totally use it because it's awesome - but don't use it, but please do..." It's all very confusing.

Ultimately, if you're starting a new project today - I would steer clear of ECS. I've been using it for about a year now, and it's been quite the s**t show. When it works, it's awesome. But yes it changes all the time, and yes those changes WILL break your code. Some of the bigger changes have definitely caused significant rework. It's genuinely not ready for prime-time production yet.

The bigger issue is that the surrounding tooling doesn't support DOTS and ECS workflows properly yet. Even with all of their latest improvements, it's really convoluted to actually get content into and out of ECS. If you're doing everything in code this might not be an issue... but if you're following a more traditional unity gamedev pipeline and workflow... you're in for a lot of pain with ECS.

With that said, if you're doing something small and experimental that isn't a financial risk, go for it! It is really cool tech despite it's current state and is fun to play with. The performance boost is very real (7,000 gameobjects vs 7,000,000 entities) and is very exciting. Eventually it WILL become the new normal for unity... but not yet.

Experiment with it, play with it, but don't hang your future on it. It's just not ready.

 

I mean it sounds super cool, but when I look at it on a superficial level, it looks like something that is out of Unreal architecture. Why I use Unity over Unreal is because of the simplicity of monobehaviour architecture. Sure it's not as performant as C++ and the architecture of Unreal (every entity has a native type, like a pawn, an AIController, etc., that you need to learn), but you can switch on a dime way more quickly, code wise. If you don't aim at AAA quality and scope, there is no reason to use Unreal over Unity.

DOTS and HDRP was for me a way to make Unity like Unreal, if needed. DOTS could be easier than the Unreal architecture (with the use of the Job System for instance) and the engine is more programmer-friendly than it competitor, so I was intrigued to learn about it.

Anyway thanks for feedback!

 

Meh. I'm not an Unreal vs Unity guy. In the same way that I wouldn't bet the farm on Unity DOTS & ECS stuff, I wouldn't bet everything on Unreal 5 tech either. It will likely be a few years before that stuff is properly stable and friendly to use too.

 

Well, the graphics pipeline in Unreal is overall better. Light Baking in Unreal is easier than in Unity, for instance. Don't know if Nanite and Lumens will live up to the hype in Unreal 5, but who knows. Doesn't change anything for me though, because games are about features, and Unity has a more friendly environment to develop those. Also, it can still create decent graphics, if you aim at aesthetic rather than a large number of details.

 

DOTS and ECS are different. DOTS refers to the whole stack around it - the job scheduling, native containers, and Burst, for example, can be used with MonoBehaviours and work very well. Those things are all production ready. You can also make limited use of DOTS physics without the full ECS integration (eg I'm using it for raycasting on a dynamic mesh where MeshCollider would be too slow).

ECS specifically seems to be in a lot of flux. In addition to jankiness/bugs, I've found it's bifrucated hybrid/conversion workflow to be a challenge.

 

I tried to make a simple low poly starship troopers fps with it and I can tell you its not ready to make any actual games right now.
Things that I could get to work:
- Walk around
- Shoot a gun
- Cube launching gun
- Spawn a bunch of cubes
- The new inputsystem (amazingly)
- URP rendering (with bugs)

Things that would've required using legacy gameobjects:
- Audio
- Particles
- Animation !!!!!

Things that will probably get a full API overhaul:
- Physics (particularly Collision handling)

Things that will probably NEVER get implemented in a timely manner
- XR/VR/AR Rig support
- Any addons that you current use from the asset store.

Overall -- pretty disappointing. I hope Unity uses DOTS as an opportunity to spruce up the backend performance of Unity before overhauling the entire friggin engine. DOTS from an engineering perspective makes sense, but from a business perspective, its quite possibly the dumbest decision possible as the strength of Unity comes from it large user network.
There are better, more performant engines out there, but they aren't as easy to use (or even freely accessible) as Unity.
Pure DOTS could wind up being easier to program in than monobehavior Unity, but is the company really committing to rewrite every single piece of software written over the past 15 years? By the time this is completed, hardware will have advanced by another order of magnitude.

Perhaps DOTS may have made sense for mobile devices or something like the Oculus Quest, but those platforms barely work with DOTS.

 

@burningmime Thanks a lot for the feedback, I never noticed that you could use the job system without importing the package. The package in the package manager was written preview, so I never really paid attention to it. It always felt strange that the burst compiler who need Job to work is not in preview, but the job package is. I should have just read that the package was just to extend the Job system, not to actually use it. Thanks a lot, learned a lot

@larrydu88 thank you for sharing your experience. Ok, well look like ECS is really not a go in the short term. It's good to know that burst and Job work though, will definitely check it out.

 

This is always amusing...

- HDRP isn't ready for prime-time...
-- Oddworld Soulstorm
-- Hardspace: Shipbreaker

- DOTS isn't ready... impossible
-- Hardspace: Shipbreaker
-- Diplomacy is not an option: https://forum.unity.com/threads/unity-ecs-and-job-system-in-production.561229/

I guess it is if you have the expertise. If not, then it doesn't matter.

(Disclaimer: obviously this doesn't mean there is no room for improvement or it is fully done and capable...)

 

Interested for the answer on the future of ECS. Will ECS eventually replace MonoBehaviours or will they live together side-by-side, as an alternative for scripting high-quantity simpler objects?

At the current state it's really hard (although doable) to make a game purely with 100% ECS, even with the conversion system. However even in it's current state, it is ready to replace some parts of your game that isn't relying on other built-in Unity features, while leaving everything else in MonoBehaviours. I'm using this hybrid approach in my current project, all players (which are using a lot of Unity's built-in features such as animation) are coded in MonoBehaviours while the projectiles and environment are in ECS and they're communicating through an event system. So far this hybrid approach is really great for gaining performance without needing a lot of effort.

I personally prefer ECS to be just like that while keeping MonoBehaviour as the main standard of scripting, as I see little benefit of using ECS for small-quantity complex objects/entities such as player characters. I tried before and were having a worse performance than MonoBehaviours (both are using Jobs & Burst) because querying 1-3 entities every frame which are never in the same chunk due to of their dynamic complexity is such an overhead and doesn't make any sense. Of course this is in the current state of DOTS packages, things might've change in the future.

Jobs, Native Containers, and Burst however are pretty much production ready, is really awesome, probably the best thing ever added to Unity scripting, and I see no reason not to use them today.

 

I don't think this is a meaningful question. Just think it through. If (!) it replaces, then it does in ~10 years or something. Does it matter for you right now? I don't think so.

Besides, and Unity always says the same, so I guess they haven't discovered any magic bullet for this. ECS is not the answer for every single problem. When ECS will be fully equipped and has the same support and maybe more than MBs, there will be a ton of things it could do. But what do you want to ECS on a title screen? Or on a Main Menu? Unless you put something in-game dynamic stuff in the scene, nothing.
GameObjects will stay with us indefinitely, that's my prediction. Unless Unity finds a way to replace them with something similar but more efficient something. Like Entities without the explicit conversion system horror. But I highly doubt it. I mean there is not enough reason to remove them. The arrival of a fully fledged ECS isn't enough because of the previous 10 years of GO ruling. Backward compatibility is more important than that and it doesn't disturb the ECS performance and pipeline in any way.

This is the reason why it is not a dumb decision. Unity doesn't take away anything from the current base, they are developing something to offer to those people who up until this were/is looking down on Unity, that it is a toy. Well, it is not anymore. It is becoming quite capable. So from a real business standpoint it is a very good decision because speaks to those who otherwise wouldn't risk using the engine for anything serious.

 

DOTS has issues, but...I fail to see how anything you say supports your thesis statement that it somehow contradicts Unity's strength. It doesn't hurt the business and offers even users like me (hardly power users) a lot to work with *right now*.

Also: What is *wrong* with using some legacy systems alongside ECS? I really don't see the issue with that approach. It's the very approach that plays to the very strength you notice Unity to have...

 

It probably doesn't matter right now but the information about where the direction Unity's DOTS is heading would be an indicator on what changes within those 10 years that we users could expect and prepare for. It is a good information to have and will matter in user's decision on planning, designing, and building tooling around Unity's workflow that would last for years.

Especially since there are other packages built on top of ECS that will probably replace the classic version. Such as Unity Physics, Unity Animation, and others.

 

Please show me one company which can tell you their plans for 10 years with reasonable precision. It is nonsense. Seriously. I don't think such plans even exist in their planners' brain. Not to mention written down somewhere and planning toward execution.
I would seriously surprised if they would have a vague plan more than a year (or really vague for two) ahead (except that they're planning to support the LTSs for two years, but that's not a plan, that's a promise).

 

This is such a silly reply. A few developers jumped through the endless hoops to release:

A simple platformer where art is key ( and still manages to look worse than stuff built on some of the competition ).
The other two: classic cases of ECS use, where animation is either tweens or non-existent ( or in hybrid ) and generally using non-organic objects. Both, heavy simulation-based games, with code making up a large part of the overall development ( entirely unusual in the business we're in ).

This is not what production-ready means, at all, in any industry. You implying so is detrimental to Unity, not a benefit.

You failed to mention those that did drop out of ECS ( or HDRP ) after making a big marketing splash for unity ( I'm certainly not going to ). AKA, the other big developers that do your usual minimal swot and risk analyses before diving into a terrible development scenario.

On the other side, you have a few thousand releases ( on both mobile and Desktop ) done by many other devs, many of them having enormously more "expertise". Most on builtIn still, some in URP.

DOTS is a great idea, announced with too much fanfare about 5 years too soon. There's a reason even Unity hid the packages.

I am glad some people are using it in more than entirely hobbyist scenarios as this means Unity gets some actual real-world use-case complaints and bugs. I'm also glad they did release it when they did ( although much over-hyped and over-marketed). DOTS production-ready though? Not even close. We can agree to call it usable in a few particular edge-cases.

 

Have you read the context? They are whining about the state of a package which isn't even released yet AND still people released or will be releasing soon full games with it. What's so silly about it?

Ah I see. You're one of those people who makes me think about the abysmal state of software development in the entire industry. Using tools is "jumping through hoops" if you need to make something yourself. Well, my friend, good luck waiting for everything.

Ahhhaaa.... lol. Seems legit.

WTF? Neither of those games are members of a niche, rare genre.

You could, because I have no idea whom you're talking about.

There is no "other side". It is not a MB vs ECS or builtin vs HDRP war. They said it is impossible to make anything with these tools in their current state and how disappointing it is. I merely pointed out that it is not even in beta and games are on the way with this tech. From people who are capable of software development. Period.

Yeah, because people whining 0-24 everywhere that the engine is unstable when they happily clicking the "preview", "alpha", "beta" stuff and wondering why is it not working easily. Expertise... LOL.

 

I'm one of those people that have to build a successful game, while minimizing risk and development time. More than that, choosing technology is not like changing a pair of socks. We'll be doing an rpg the next three years, a 4x the next and some racing game the other two. You build expertise around it ( at great costs ) and expect a minimal level of stability from it. More importantly you expect flexibility. Not even mentioning supporting toolsets and such for what actually makes up 80% of games today -- content.

Some of us released games on internal ECS engines a decade ago, we use unity professionally, we use unreal professionally and internal engines as well. Each choice is one that pivots a large team ( of which programmers are only a small part ) for the next half decade or more. At this point, I doubt anyone will choose Unity for its graphics prowess. Even if it was the best at it, the workflows are still convoluted and ultimately will drag on your timelines for no real gain. If your team only has Unity experience, you'll try and make the best of it, for sure, but that's about it.

You can argue all day. DOTS is nowhere near production-ready and using it in anything other than something that fits it perfectly is a huge risk. Hardspace fits it perfectly and it was, probably, the right choice. Diplomacy does not, other than for their unit counts and it's them I'm grateful to for pointing out actual issues outside of the dots comfort-zone.

The comparison between DOTS/ no dots was to underscore exactly how far away from production-ready it is. One can be used for anything, the other, currently, only caters well to a few particular cases.

The fact that games that use no or very simple animation and super small indie outfit games making it out into the wild with DOTS does not prove it is so either.

"You could, because I have no idea whom you're talking about."
System Shock comes to mind.

 

I should add that DOTS is nowhere near complete, but at the end of your game's development cycle, the Jobs system is basically good to go (although quite hard to figure out how to use). If you run into performance issues from having too many of a particular type of gameObject that needs to be updated frequently, the jobs system would be a reasonable stopgap until DOTS is completed.

 

The job system is production-ready and awesome to use, indeed. We do so frequently.

 

That's good. But it actually isn't an answer to the implied question: why are you labeling DIY coding "jumping through hoops"?

BTW, I didn't say (and I actually do not think) that ECS would be "production ready". Whatever it means in Unity's case.
Again, I merely pointed out that people are using it, no matter what, and with serious results.

And? Why are you trying to inject this nonsense into the conversation at the first place and as a byproduct trying to put words in my mouth what I haven't said?

Oh come on, that was in 2017. And the developers (I don't necessarily mean the software people, I mean the whole project) were completely clueless. They even restarted the entire project in 2018. Great example.

 

The topic is "state of dots". The discussion is when it will come out of preview ( aka be production ready ). None of my points are off-topic.

I did not mean to put words in your mouth. Your reply over-simplified the state of ECS in my opinion and implies it's a failure of devs. not that ECS is, in fact, very far from production-ready. If it sounded that way, I apologize.

DIY coding is fine. For a professional team, what Diplomacy is doing, for example, is exactly that though: jumping through endless hoops and constant rewrites to both keep up with an ever-changing API and bypassing the total lack of content-supporting tools in the DOTS pipeline.

BTW, we have regular DOTS training days at work, in the hope that we will be using it at some point. I trust Unity to eventually deliver. Although, in my couple of years of Unity, I have been wrong on that a few times.

System shock is made by NightDive btw. They have been around the block a few times, individually as engineers especially, but as a company too. Dismissing them easily is not something I'd do.

 

Did anyone actually say that?

All I saw was several posts saying it's not really production ready, ...and it's not.

I'm not sure whether to laugh at it or be offended.

The problem here is, categorically, not that people can't do their jobs. The DOTS ecosystem just isn't really in a great place right now, even if, yes, technically, you can use it for some things if you're prepared to invest enough time and effort in doing so.

Why does this have to be a fight to the death about he-said she-said?

It's not ready. It's not close to being ready. Don't use it.

Is that unfair advice, for someone who randomly drops in to ask the state of DOTS? I don't think it is.

I think the changes in the 2020 package manager make it pretty clear this is the line of communication coming from Unity itself.

 

Well, a couple of points here, not for arguing or something, just facts and our experience. DOTS as a full solid solution, not production-ready, parts of it (Jobs System, Burst Compiler) ready and can be successfully used for the regular production pipeline, ECS part not production-ready in regular meaning, but can be used for production with really good benefits if you ready to spend some time for developing, an important point - does not fall into an expectation that it's a silver bullet which magically solves everything and suitable for everything, it's not and Unity told this (devs, not marketing).

There are not many rewrites honestly, usually with huge (rare) API core changes we spend ~1 day(±) to restore full stability of a project (rewrites with tests), that's all, API is stable enough, in Diplomacy is Not an Option, we don't rely on Unity things, as we have own physics, own navigation, own animation, own rendering.

 

Glad to hear API changes did not impact you that much. I agree with most of your points. I suspect our definition of production differs a bit.

Your last phrase is what I would define as not production-ready ( at least in the unity ecosystem ):
"As we have own physics, own navigation, own animation, own rendering."

We moved away from internal engines on some projects ( mid-sized scoped ones ) for this reason alone. After a while writing our own libs (or adapting 3rd party) for each project stopped making sense.

Since you are here, you did not mention the lack of content-oriented tooling. How did that impact Diplomacy?

 

In our case reason was not fact that DOTS haven't anything when we started (we started rewrite to DOTS at 2018 when was no physics, animation etc.) but the fact that even when they released their tools they weren't suitable for our case and what we want to achieve, because their target (in the first place) is a general solution which everyone can use for most popular cases. In our case, we implemented simplified "2.5D" physics and reduced unnecessary cost of some things as we don't need them, we implemented our navigation, because built-in wouldn't cover our case as a regular A* for this amount of units which live as an independent thing and not a group (like in Total War series for example) and we decided to implement our hybrid of HA* + Potential Fields. etc.

We trying to highly reduce the amount of unnecessary tooling, most of the workflows still the same, we just added pre\post processors behind the scene and non-programmers still continue to work as in pre-DOTS ages. For all our own solutions we have our own implicit or explicit tooling, like for animation - a pipeline for artist absolutely the same as with regular GO - he modelling, rig, animate things, put it in unity, build vfx etc. and just put it into regular prefabs. And this prefabs used with Addressables for bundles as any other regular GO, and then, underhood, we do all conversions etc. for this to be a pure DOTS things. For that, we implemented our own unique ID system which not rely on Unity GUID and persistent across Editor and Runtime and our own prefab references which use that and you can link other prefabs\go in the editor before conversion and it will know what to use after conversion etc. For a game designer, we always implementing our own much more convenient tooling. One important note is that we don't build levels in Editor, we build presets for procedural generation, and for this legacy Unity also wouldn't have any tools as we did them for our solution (like below)

 

Thanks for the exhaustive comment. This will be useful for a lot of people for sure.