How significantly is the API likely to change going forwards?

First of all let me say I appreciate the effort that has gone into creating the DOT stack, and I fully appreciate the intention behind it.

I understand that it is currently in preview.

However, I consider the current iteration (0.8) of the tech stack to be:

• Poorly and incoherently documented (often referring to depreciated components like JobComponentSystem). The examples repository is the only meaningful place to find out how to actually do anything.

• Deeply developer hostile (see for example this thread about introspecting over the data assigned to an Entity, https://forum.unity.com/threads/ser...over-all-components-of-a-given-entity.524553/), where performance is prioritised over developer workflow.

• Requires manual memory management (eg. with even the most trivial of operations like `foreach (var e in
  query.ToEntityArray())` cause memory leaks because the API fails to make explicit when memory is allocated.

• Has had major API overhauls several times.

• Is openly acknowledged (https://forum.unity.com/threads/api-usability.550450/) to be difficult to learn and use.

• Has an incoherent packaging strategy (see for example https://forum.unity.com/threads/dot...0-8-0-missing-class-propertyattribute.847255/).

• Several components, eg. animation, nav are either not available or extremely primitive in their implementations. Other (eg. native containers?) seem only just to be rolling out.

In summary, things are mess right now.

I consider this to be unacceptable; I cannot possibly imagine that the Unity QA will allow a 1.0 release with DOTS in its current state.

So, long story short, it seems to me like we're still very far away from any kind of stable DOTS release.

...and yet, looking at https://unity.com/dots/packages, you would be forgiven for thinking that this was all already a production ready system.

So what's actually going on?

Is this "DOTS", like, this API we have right now is it, and if you want to use it, then off you go?

Or is this something which is still in flux, and the marketing people are just spinning out of control?

For someone who's only just looking at this, it's super scary, like, it feels like it's shifting sand, and any investment in this tech stack is utterly a tech-demo-only kind of effort, because it's going to change significantly going forwards.

For those who have been around longer; is the rate of change slowing? Is the API actually converging towards some kind of end state?

Or is this just a tech demo?

 

This is still preview tech and so you can probably get expect the API to still change drastically. Heck they only just deprecated the ForEach job interfaces which were only released a few versions ago and up till now pushed as the way to do things. Even their own packages use this now deprecated API all over the place.

If you want to stay up to date and anticipate using new physics, animation, audio, etc as it gets released then this is not ready for you unless you are happy to work with those packages as they undergo huge flux.

If you are building something that can benefit from the existing feature set then I’m sure you could pick a recent release and run with it, you don’t need to update the package for new features and changes if you are able to achieve what you want with the existing tech.

 

Not few versions ago. IJobForEach was from the beginning, before it was IJobProcessComponentData and 2019-04-05 was just renamed.

 

It's one of its pain points. We are using DOTS since [Inject]. We have libraries of code already that we use in a game in early access. Just imagine if there's a drastic change in the API or some things were renamed or removed (which happened a bunch). We have to fix a lot of code.

So far, we are able to keep up. I guess that's the price you pay for using a tech in 'preview'. However, we are very thankful for DOTS. It optimized our game a lot that it's probably one of the reasons why we get positive reviews.

 

Yeah, this one. Although, it's not everything. Rendering and path finding and some game logic are implemented with DOTS.

 

I'm also attempting to learn DOTS. I was proud to have completed a pretty thorough roadmap for a new project. I was wrapping up a little bit of final research on the state of the art, from which any additional tasks might emerge. Unfortunately I've been stuck on what I thought was the last of these for days. It started as "Research ECS/DOTS," then "Implement some ECS," but now I've been watching through the DOTS playlist from Unite Copenhagen 2019 at 2x speed trying to get through it all and have some idea of what the hell is going on.

Since my first intro to C++ class, 14 years ago, object oriented programming has been the one paradigm that felt immutable. Suddenly Unity is saying, "About that... Not so fast." I fully understand the reasoning, and I am eager to embrace the new and see the light. I am not going to be one of the haters just saying this is a terrible direction to move in. I am trying to get on board now as I am gearing up for a new project. It's a good time for me to establish new paradigms. I'm going to get on 2019.3 , then transition to LTS ASAP. I want to understand and incorporate DOTS, I've been convinced, but connecting all the... dots is an ongoing and difficult thing to wrap my head around.

When I try to explain to the rest of my team why I even want to try, or how it all works, their eyes glaze over more than usual. The only thing that rings any bells are seeing the boids swarms or talking about mobile battery life. For me though, I know this is a positive direction to move in to get as-of-yet unimaginable performance by default in all areas of development. That's the goal anyway. The struggle for me is in first understanding all of this new information that seems very much in flux, with fragmented documentation and examples all over the place that may or may not have just become deprecated, and then bridging the gap between DOTS and the type of Unity development that everyone knows and loves. I have a strong, sneaking suspicion that escaping "hybrid" development in favor of "pure DOTS" may never really take hold, for almost any team. But that doesn't mean that DOTS and ECS are bad initiatives. I just think the work now, and for years to come will be refining and polishing this new paradigm to improve onboarding and workflow, while allowing people to stay as high level, or go as low level as is appropriate for them. My personal goal is to develop some kind of in-house API that enables other team members to understand development in a more traditional way, perhaps with additional compilation/conversion steps, and still ensure under the hood that we take advantage of and integrate with DOTS as much as is realistically possible.

Wish me luck, and I'll do the same. Here's to keeping up with the times. Cheers!

 

If you are working in a team, I highly recommend using MonoBehaviours, but also using Burst and jobs. Whether that means using camera-frustum based pooling like Vegetation Studio (I also have a small demo of this) or a custom heavy simulation like the water in the Boat Attack demo, you can get a good chunk of the full DOTS performance without jumping into the deep water that is ECS. If you do this well, you may find yourself writing manager MonoBehaviours that look a lot like ECS systems. Consequently, ECS will be the natural progression of the ideas and patterns you pick up. But sometimes you have to let those basic ideas (Burst, C# Job System, Unity.Mathematics, and maybe Unity.Collections if the team starts feeling comfortable) sink in first. Definitely prototype with ECS on the side so that when your team is ready to make the next step it isn't totally blind.

 

Well, when I reference my team it's not a traditional game development team. I'm essentially the sole programmer. I'm the Unity guy. However, I work on a team with other programmers who are my supervisors, and I'd like for my style to not seem completely foreign to them or anyone else who may some day work the project.

For even more context, I'm re-building an existing project from the ground up with the intention of improving code structure, performance, maintainability, extensibility, and improving and simplifying workflow for adding new content quickly and easily. I know everything (and I mean everything) I want to do, but suddenly contemplating DOTS has thrown me a curveball that has me in a bit of a mental tailspin.

I consider Unity my specialization as a programmer, and I don't see any other engine on the field or horizon that makes me want to change. So, I want to stay up to date with Unity best practices. I can see how much work is going into DOTS in every aspect of the engine and I don't want to let it pass me by.

That being said, I am struggling to wrap my head quickly around every aspect of this new system, but more importantly how to integrate it into a more traditional setup. I was just about to begin on my own dependency injection framework to help establish the concept of a composition root for my application(s) and move away from singletons. I was already planning on having more of my "game objects" (models, entities, whatever) live outside of the scene hierarchy, while using game objects in the scene hierarchy more as representations and views. My intuition tells me that this line of thinking might align with ECS and DOTS in some useful and interesting ways. But that's the problem, now I suddenly feel like I need to really grok DOTS in a deep sense before I start rebuilding the bones of my project, for fear that I might want to just come back and rebuild again later. At the very least I want to make sure everything is somewhat future proof for onboarding all the new DOTS systems and methodology on the horizon. I don't necessarily NEED DOTS, but I also don't want to box myself out with a counterproductive architecture. If I want to incorporate some DOTS later I don't want to have painted myself into a corner.

I agree that reading through the example projects will probably be the most helpful thing for me right now.

Anyway, I'm not trying to complain. When I close my eyes I can sort of imagine a future where I'm developing with DOTS as confidently as I do without it today, and where the performance of my games is a complete paradigm shift. I just wanted to share my experience for whatever it's worth. Thanks for the tips.

 

I've just upgraded all of ECS related packages on a project I've started more than 6 months ago. I took a break from it about 5 months ago to focus on other non ECS projects, so I'm back in the ECS land today and to my surprise, nothing broke in my code, except for one EntityQuery. The code has over 30 systems and quite a few more jobs just for reference. It did take me half a day to work through all the package dependency nightmare that came with it, but other than that I was pleasantly surprised.

However I learned that Unity is going to deprecate IJobForEach. Since I've never really run into any problem that wasn't my fault with ECS, I'm not going to upgrade the packages anymore. There's just too much code to change, among other reasons posted in that other thread about this topic. I'll be sticking with this version until I'm forced to update, either due to some internal ECS game breaking bug, a new project or some feature that I just can't live without.