Official DOTS Development Status And Next Milestones - December 2021

That was my original dream and hope, that for the most part it can be auto, with the developer only really worrying about behaviour. It's a pretty tough nut to crack by the looks of it!

 

That is not an answer to my question. 0.17 is robust and does not absolutely need patches and fixes. 0.50 brings up new features / breaking changes. Should we expect 0.50 to be stable and to work on all platforms the day it is released? It packs a year of improvements so nobody here knows that answer except Unity.

 

More importantly, what in 0.5 do you need to ship? If stability really is your goal, do not upgrade - especially as you have indicated it really is stable for you in 0.17. I do not see how Unity can ever guarantee stability in an unreleased version.

Also don't forget 0.5 will contain breaking changes with 1.0.

Not trying to be an arse, but your question is very self solving.

 

0.50

 

How big is your playerbase to back up that statement?

Yep and even if Unity said here that 0.50 will be more stable than 0.17 would you really risk believing that?

 

Not guy you replied to but we launched early access 6 months ago (and going full launch soon) and have a large enough sized player base to consider the stability of the product.

We have absolutely no issue with 0.17. Rock solid.

We will probably not upgrade to 0.50 due to pending full release and concerns about stability (will look at doing it post release.)

 

Early access on all "PC, PS4/PS5, XB1/S and Switch"?

 

Only early access on PC but to be full release on PC, PS4/5, XB1/S/X (no switch)

 

Are WebGL builds a part of the future of DOTS (Hybrid in my project)

 

So that's not "large enough sized player base" but good to know it's stable on PC. Is it mono or il2cpp?

 

il2cpp (because of console requirements)

 

The game is in production, but considering there's is nothing in our build that do not comply to first party technical requirements, I believe we can say 0.17 is robust. Furthermore, the game passes the same tests we did with our last non-DOTS released title played by half a million players. Does that sound like enough signs of robustness? I think so.

 

This is the kind of new functionality that will get me excited to use dots. Hope to see it!

 

v.17 Doesn't work with IL2CPP on Linux, but v.16 does. So I am really hoping on the fixes, maybe a .18 version? I don't need .5, just need regular fixes. WebGL only works on 2020 and not 2021 with entities, last time I checked as well. It would be easier if entities was up to date due to all the other packages being updated and incompatible.
Edit: Now I must choose between a working Pause Button and IL2CPP builds lol.

 

It's 0.50 not 0.5

 

Any news about DOTS navigation system??? OR is it planned after final release DOTS 1.0??

 

Is there any thought to exploring determinism outside of Burst? Or evaluating how deterministic cross platform floats currently are, and across what platforms? I've seen tools like Rapier physics for Rust that guarantee cross platform determinism (though I'd imagine compiling through LLVM makes it a lot easier), and Normcore is using float determinism for their game Nock (it's Quest only I think? But one of their devs mentioned getting deterministic results between x86-64 and arm64). I wrote a big ol' post here about some research I did into the subject.

 

Deterministic simulations across processor architectures is usually done with fixed point maths, it works but is generally slower than floating point these days. Even across the same architecture but different platforms it can be hard, as you really need the code to be compiled with the exact same compiler and version etc. I did work on a game which achieved crossplay between xbox and PC as it was possible to compile the simulation to a static library which was then linked by both the PC and xbox builds. I don't know if that sort of thing is possible between PC/Mac/Linux, but perhaps now we're in a world where LLVM runs everywhere it could work? Not really my area hehe

 

Great point, and some simd instructions aren't fully deterministic across different processors IIRC

 

The reality is network games are not CPU limited they are bandwidth limited. It is not even close we are talking by several orders of magnitude this holds true. Then everyone has 1000/1000 Mb connections this may change. But honestly I feel like until 10,000/10,000 you will still have to be careful.

Honestly just having determinism on Haswell/Bulldozer SSE 4.2+ Windows 64 bit. would be fine for 97.5%+ of gamers according to the Steam survey.

 

Any chance deterministic compilation could be an option? (I was under the impression this was already the case with [BurstCompile] params)

When needed, it would be entirely worth it despite the performance loss. But when not needed, we could enjoy full performance

 

Yeah, in the post I linked above I note that the Rapier physics engine for Rust, which uses LLVM, advertises cross platform determinism.

Re: Fixed point, this is a solution, but aside from performance you run into issues with precision when using setups like 48.16. Other setups like 32.32 do not have this issue, but have much larger performance implications.

There are definite performance impacts to losing access to intrinsics/SIMD, but can be a really worthwhile tradeoff for the benefits of determinism (TheOtherMonarch touches on bandwidth being one, the other being you can run an authoritative server without needing to run the simulation). Definitely would be something that should be in an option though, like Phil notes.

 

Is this something that would be available outside of Burst compiled code? Thinking of hybrid projects that have both ECS and MB logic.

 

Alot of SSE2+ is proven deterministic. FMA is not deterministic and is fairly new. I think FMA3 is fixed now with a microcode update for AMD, but AMD dropped FMA4 support. I think it is a big mess that will end up getting fixed but not for a long time.

---------------------------------------------------------------------------------------------------------------

Since our project requires determinism, our plan is to do the following. First require SSE4.2 maybe AVX just so we don’t have to check everything on decades old CPUs.

Stage 1: Get everything burst compiled and use SSE4.2 CRC32C sum checks and see how deterministic everything is. I get the impression that even Unity does not even know how deterministic Burst really is right now and I realize that this has no guarantees.

Stage 2:
Option 2: If this fails, we switch to Rapier physics. I honestly don’t know how deterministic this is either I will need to talk to the developer first. If this fails hopeful, we can work with the developer to fix determinism if it is broken.

Option 3: is c++. It should be easier than in the old days because I know for a fact that most of SSE2+ is deterministic. It still is going to end up with some very arcane c++.

If option 2 or 3 ends up happening, we will reinterpret the bits from the floats as an int and store in ECS. Rust docs says that from_bits will get the correct NaN back if your CPU supports IEEE-754 2008. I honestly don’t know what that means as far as CPU support. We will probably end up being careful with NaN.

If they get Burst working you can just use the same strategy I outlined above to make a deterministic math library wrapper.

Also remember not everything needs to be synced. We will not sync particle effects or animations and just make bigger hit boxes without lower arms or legs.

 

I know the developers of the VR game Nock (Normcore), use determinism along with ECS/Unity physics for their netcode. The game looks like it's only announced for Quest, but one of the devs mentioned in Discord they had no determinism issues between x86-64 and arm64.

I've talked to the dev of Rapier, and they've tested fairly extensively. Don't have the platforms off the top of my head they tested but the conversation is in their discord somewhere.

I had some issue with NaN bits being reversed, think that was between IL2CPP C# and Rust. But I realized it doesn't really matter much, since NaN in general can be a serious error anyways. Can always just check for NaN and set the bits to one or the other if you want a checksum to match.

Not sure entirely what you mean here, just a having an external native lib to make math calls to? I have done that, but I don't follow why Burst being deterministic is required here. There is also a pretty huge overhead for external calls, iirc.

Can always bake animations to LUTs for hitboxes...but this depends a lot on your game.

 

Yea, I defs wasn't implying to use the existing MonoBehaviour lifecycle (Update, FixedUpdate, Destroy()...) to achieve determinism. It'd be done similar to things like Photon TrueSync or Fusion, where you build a tool that manages the callbacks and lifecycle manually, and make sure to allocate your simulation state somewhere you can blit/checksum it (I've made a toy deterministic engine in MonoBehaviour that does this with fixed point).

Main reason I ask is that I'm exploring ECS as an avenue for a future project with determinism, but looking to see how flexible I could get with it with hybrid workflows. I wouldn't expect Unity to be refactoring MonoB to be a deterministic games framework if float determinism was available. It's pretty great to hear float determinism is on your mind, was wondering why Unity Physics was built to be deterministic haha (it's a really excellent package, so great work to you all on it!).

 

I think being able to only enable determinism on certain methods or components would be better than some project-wide configuration. Like @PhilSA suggested a parameter for [BurstCompile] just like we have for floating point precision currently, or perhaps even a deterministic float data type like dfloat (though I would much prefer an attribute, I think we could all agree on that). Sometimes determinism isn't important; some objects that don't provide any gameplay value might prefer speed over reproducibility. If I fire a projectile in a multiplayer game, I want that projectile to be simulated deterministically. The impact effects that don't affect gameplay (like bullet hole decals & impact VFX or responsive environments) I don't particularly care about. So I can definitely see the use in having more control over determinism beyond a project-wide toggle if the impact on performance really is significant.

That being said, I must admit it is pretty disappointing to hear that cross-platform determinism isn't planned for the 1.0 release though. I'm personally not working on a multiplayer game currently but IIRC determinism was a huge selling point for using DOTS with multiplayer code for simplified rollback functionality, so I imagine the people who are working on multiplayer projects right now are very sad to hear this. I can somewhat understand if the reason is the complexity or difficulty of pulling this off; obviously, we all want the 1.0 release to come as soon as possible, and we know that difficult choices must be made if you ever want your product to ship (I think many devs here can relate to that feeling). However, if there is already a solution that is suboptimal but stable I really think people should have that option of taking a performance hit to achieve cross-architecture determinism as soon as possible; especially since DOD and multithreading already take your game beyond what is currently possible with MonoBehaviours, many of us will consider that "good enough" even if determinism has a huge impact on performance.

Maybe I'm overestimating how big this problem is in the first place as I haven't seen many people complain about it yet, but if two people with PCs both running windows can't play a multiplayer game together, I do really see that as a huge problem. If DOTS is to be taken seriously as a product for professional game developers, I think having this restriction be present in a version you call "1.0" is a very bad idea. Especially after convincing us of the importance of this feature in a 2019 presentation where IIRC, it was referred to as one of the "core design features" of Unity Physics or Mathematics (The page for Unity Physics still says in the first sentence that "Unity Physics is a complete deterministic rigid body dynamics and spatial query system"), you can't release a full "1.0" version in 2022 with this feature completely missing when you've already told us the 1.0 release keeps getting delayed because you want it to feel "feature complete" without needing hacky workarounds. As someone with limited knowledge about how floats and different software architectures work in the first place, it would be pretty much an impossible task for me to personally implement my own deterministic float math systems. My only option would be to, once again, wait for some theoretical future Entities release, for a feature that doesn't even have an estimated time frame yet so could possibly even take years for all I know.

Running into this kind of stuff when you use a pre-release package could at least somewhat be blamed on the user for "using an experimental package for production work", and that they should be expected to run into complications when working with new tech, but once you call it 1.0 you no longer have that excuse. People will be rightfully upset when they find out the game they just spent a year on is out of sync on some users' devices because you didn't think to test the determinism on another Windows device with slightly different hardware. And you could again blame the user because they had the audacity to believe Unity's sales pitches about determinism from the 2019 presentations without actually testing it on every single type of architecture 3 years later, only to find out apparently it wasn't as deterministic as they made it sound in 2019. But I think blaming the user and expecting them to just be aware of every single restriction even though the opposite was advertised is very much not valid for something we refer to as "1.0". Good luck finding out why things are out of sync without knowing determinism isn't working correctly in the first place, by the way. Most likely people will be digging through their code pulling their hair out for weeks not knowing what is causing the issue because nothing is actually wrong with their code, but the framework they're using just isn't working as advertised. Imagine the frustration when you find that out.

New developers will assume it's a part of DOTS until it is too late and they have this big problem to solve now which in your own words, would require a completely custom implementation of Unity Physics or some other workaround which would be an enormous time investment. If this is the experience with something you call a "1.0" release; that would immediately give DOTS a bad reputation. Frustrated users that weren't aware of this restriction, who have already put large amounts of time into trying to learn this new system, will be rightfully upset at the fact that a feature that has been so widely advertised for several years as a large part of the design philosophy of the package is essentially missing (because it's not really determinism if it's not deterministic across different platforms, is it?). Us forum users run into stuff that's missing or not optimal all the time, but most of us know that's what we should expect from packages that are experimental or pre-release. This kind of stuff is still somewhat acceptable now, but it really won't be acceptable in 1.0. when gen pop starts to use it and expects basically everything you've promised (or at least the things you've emphasized to be very important and one of the core design philosophies during Unite 2019) to be working as intended.

If my assumptions about the consequences like splitting the player base by architecture etc are correct, I'd ask you to please reconsider at least giving us a worse-performing version of cross-architecture determinism for the 1.0 release. If I were working on a multiplayer game currently, I'd probably choose to take a 30% fps hit if that meant my game can be played on all architectures on the same server, rather than having a game where everything is hyper-optimized but you can't play with your friends who happen to have different hardware despite running the same OS. For me personally, it doesn't really matter as I'm not developing a multiplayer game in the near future. But I do really fear what this kind of thing will do to the reputation of DOTS. I'm afraid that even with the delays of 1.0 we're still going to see a 1.0 version that feels very lacking and needs hacky workarounds to function as expected, so I'd prefer whatever you're planning for 1.0 right now to be another pre-release version like .51 or .60 or something. I'm a huge advocate for using DOTS and very enthusiastic about its potential but if this is the kind of stuff that's missing for what's planned to become 1.0, I wouldn't blame anyone for writing off DOTS as buggy, incomplete or experimental once 1.0 drops. And once you've got that reputation; it is pretty hard to get rid of it. (Unity should know that better than I do... but I guess if that were really the case they would have gotten rid of the splash screen by now. But that's a topic for another thread, I guess.)

 

I couldn't agree more.

Especially since a bug introduced either by Unity or Android totally broke 2D Physics determinism, 3 years ago, and nobody is willing to fix that.

We were fine in splitting our userbase in different cohorts like PC/Android/iOS and so on, but now on Android only you have 4 different cohorts that cannot play one with the others.

This is crippling our game since 3 years, and we put a lot of faith into DOTS to allow us to address this issue... But looks like there will be no solution for at least another couple of years.

Please consider introducing cross-platform deterministic physics earlier.
Especially on 2D engine, you wouldn't have dramatic performance hits - they're way more acceptable than having the problem mentioned above.
(I know 2D engine is not officially advertised, but I remember it being discussed on these forums by Unity staff, including @Joachim_Ante IIRC)

 

Hello!

Will the release of DOTS 0.5 also mark the release (or an update) of Hybrid Renderer? More specifically, will it have the ability to render multiple lights? As of right now, it is one of the biggest deal-breakers for using DOTS.

 

It's 0.50 with 50, not 5

 

This post has been made 3 now times on this page alone.
Is it really THAT important?

 

He's probably trying to make a point that two different version numbers, which are equal mathematically are bad idea.
Version 0.5 should me more like 0.05, but it's too late for that and since Unity wanted 1.0 to be first stable version, they needed to "squeeze in" more numbers.

When I see version numbers with two sections, I somehow expect them to be mathematically unique. For example version 1.05 - it probably seems normal to most people.

This does not seem to apply to version numbers with 3 or 4 sections.

EDIT:
It turns out Unity is using SemVer, in which case leading zeros are forbidden.
SemVer requires patch version, which makes it look more like version and less like a number.
So the version is really 0.50.0. I have no problem with that.

It would be more clear if people started using SemVer (MAJOR.MINOR.PATCH) in written text.

 

Desist from this bullshit(0.05, 0.5, 50 etc), it's polluting the thread without adding anything meaningful. Start asking Unity about DOTS, as it's the focus of this thread conversation. Exploit the presence of Unity; Educate yourselves by asking them questions and doing something useful, instead of staring at these pointless punctuational numbers pondering poor life choices.

 

Right.

So is the release going to be called 1.0 or 1.00?

 

I hope you're not being sarcastic. The final release is clearly 1.0. If they're going to release a version after 1.0, then it's gonna be (1.01 or 1.10 or whatever). You should take a look at how the Input System evolved out of preview to become 1.0, then 1.0x etc. What is the problem you're having trouble understanding?

 

Personally I vote for 001.000

I think the 3 zeroes after the dot give it more oomph while the 2 in front make the whole thing symmetrical.

 

I wouldn't call it "presence".

People did, and received no answers yet.

Like waiting for UT to start talking again?

Who introduced that "malicious" and confusing versioning scheme? And who has to suffer from it? People complaing about it are the victims here.

 

How in the world are people "suffering" from "confusing" versioning schemes? What is the hard thing you can't understand/having trouble understanding? Without elaboration, we will never know what you are "suffering" from.

I find it pretty convenient and easier to understand: Preview releases are not finalized, thus naming convention is 0.x. Once out of preview, it's 1.0. This is how most dev versioning schemes/naming convention releases work, and it's the way Unity is following since dawn.

 

Then your eyes must be deceiving you, their replies are in every page and in this page as well, if you look closely.

 

A reminder that this post is the closest thing we've seen to a Roadmap and the most info to come out of Unity about DOTS in a year. Consequently people regularly check this post and 'watch' the thread. Currently this thread has over 61k views. Before you post please consider that hundreds of people may be emailed what you've written or be notified that this thread has more content.

 

I mean currently, there isn't any point to getting more news. They've told us their plans for the next releases, I don't know what else there is to discuss.

For now all we can do is more or less wait until .5 is released.

 

That's exactly what I'm talking about; Being useful instead of wasting your and others' people time.

You can see how this thread alone even had an impact on google search:

 

I'm not just talking about me. "Some" people had to be corrected when they asked about version 0.5 vs 0.50. That's what triggered your first post here. So if you want to enable people to pick the right version you would use a versioning scheme that allows this. That's all I'm saying. If you want to confuse and annoy people you pick one that makes 0.5 and 0.50 (which are mathematically identical) two VERY differrent versions.

If you intend (or it has even an unlikely probability) to produce more than 10 versions it would help adding a leading zero. So not start with x.1 but with x.01. Then when you reach the 10th version (which would be 0.1) your users would have no issues distinguishing both versions. This way you have 99 distinct version numbers to distribute.

Anyway. UT created an unfortunate situation here. People are pointing this out so maybe it gets corrected the next time. It's not wrong to make mistakes, as long as you learn from them. And one way to learn is collecting feedback. This is what some people are giving here. And this is what I assumed a "betas-forum" to be about. So when someone says "This versioning sucks" what arguments speak against giving this feddback (beside it annoys you)?

This whole thread is a mockery and comedy. "We are starting communications again after almost one year silencce". People are asking specific questions but most of them remain unanswered. Not even a "we can't currently tell" but just silence again. I'm no expert in public relations. But from my PoV UT is doing it wrong, again.

 

A nice guy above noted something that should basically clear things up. Don't think of it as a decimal number.
Edit: the following are also good reads on this.
https://docs.unity3d.com/Manual/upm-semver.html
https://semver.org/

 

Lets adopt semver and stop this pointless quarrel, please. Unity has been using semver for a very long time and for almost everything I know of. I don't know about you all but I think in semver whenever I join a dev forum.

 

You, Unity guys, should start working on DOTS' documentation once 0.5 is released. And, making it as efficient, simple and understandable as possible, with a Lot of most practical and best practices examples for each function.

Choosing 0.5 as a start point, so:

• Saving up time on documenting going forward to 1.0
• Documenting only functions that'll stay the same/having no breaking changes till 1.0