This post is meant for the Unity devs looking for user feedback, but if anyone else has feedback or notes on the problems discussed feel free. I have about 9 years of programming experience with Unity now. I have shipped titles small and large. I would rate my programmer skill as above average (not amazing, but definitely not the worst). One of the perks my company does is a week game jam of sorts. This year I decided was the year to take a stab into the latest ECS APIs (preview 0.0.12-preview30) to see if I could get a handle on the concept and become an advocate for it in the future. My game was a 2D isometric ant simulator (something I felt would be well suited for ECS) where each ant would be an entity and we would have basic pathfinding to find food and return to the ant hill. Luckily one of my co-workers was willing to take the deep plunge with me and helped me with the project. We had no other Unity resources or mechanics other than what we were able to find online and the sample repository. First the good! When ECS works, it REALLY works. I can definitely see the future in this regard for game logic iterating over multiple entities. Creating systems that managed the death mechanics of all of the entities in the world so that we could do cool things like fade out or other behavior was really powerful. Splitting the data away from behavior. This was a wonderful change of pace from the OOP world we live in. I really appreciated the way that ECS helped really isolate behavior in a new way. The samples have a lot of good fundamental data in them to get up and running. They were often a big resource for us, especially as we were getting started. Having the C# code is really handy. Searching the Mathematics library or doing a deeper dive into the renderer system was a huge help for us. Please continue to keep sharing the backing code as much as possible! Burst + Mathematics + Jobs is a beast given form. When we could use the system fully, it tore through anything we could throw at it with ease. So here are some pain points that we suffered when we were trying to develop this project. I fully realize that these pain points likely have easy solutions, but we weren't able to figure them out with our week with the system. I just want to give you an idea of maybe where the current experience might be lacking. I know that a lot of this has already been mentioned on various forum posts and there have been a lot of "we're working on it" posted from Unity. The rendering is completely barebones. This was probably the biggest surprise for me, with 2 years of API, demos, and work that has been made in the DOTS system. We were trying to render transparent sprites with correct sorting. I knew we would likely need to write a sprite switching system. However, when we found out that the basic renderer doesn't support MaterialBlock data easily, I almost threw in the towel right then and there. Luckily my partner was willing to tackle the challenge of going through the hybrid renderer and writing one that suited our needs better. If you're going to basically enforce GPU instanced meshes by default, you'd figure you'd have a better way to apply material block data. There are only so many demos you can use instanced opaque geometry. There is still a lot of magic. Systems automatically being added to the simulation, readonly data dependencies, system component execute queries. I really appreciate the more recent pass on the API to try to clean it up a bit by adding ForEach/ForEachWithEntity/RemovingInject. However, at the end of the week my co-worker ended up preferring using the underlying ChunkJobSystem because it didn't hide much behavior. My problem was that I found the chunk system very verbose so I tried to use the IJobForEach systems. What I found was situations where I would write an EntityQuery (GetEntityQuery()) to feed into the job, but the System would think *that* was the query it needed to have in order to operate the system. I had already defined the filtering criteria on the job template. This was just a minor confusion point for a bit while I tried to figure out why my system stopped updating. My recommendation is there is magic happening still, and it is fine to hide the IJobParallelFor and the Chunk iteration, it is not ok to suddenly stop working because I added another entity query to the system and it didn't know what entities it needed to operate on. I realize that this is a very fine line to walk, but the magic that is happening when you throw component types around and "it just works" can be really confusing and problematic. I don't want the verbosity of chunk jobs, but I also want slightly more explicit behavior. Sharing multi-threaded data efficiently is hard. I realize that this is a topic that could fill books, but sharing data with the job system created some fundamentally difficult problems with a lot of hidden costs. For example, we have a relatively large path finding data buffer objects (probably about 256KB of data per layer stored in NativeArray<float> collections). I struggled a lot to figure out a good way to send this data to jobs in a way that was efficient that played nicely with Burst and the job system. I didn't want to create an entity per path node when all it really needed was a float. Also it would then become difficult for me to do fast positional data lookups into the array using a position. I didn't want to create copies of this data every frame for every job. I also wanted to wrap this data in some nice convenience methods. I ended up having a static class that has static buffers/methods to manage and maintain/query this data (not very DOTS of me, I realize). However, it was global data that couldn't be bursted, and I didn't have a great solution for. Burstable command buffers. Nothings quite disappointed me more than removing the BurstCompile off a burstable job because I needed to execute a CommandBuffer request. If commands buffers are meant to be the primary communication structure to execute data changes on entities not included in the system query, it seems weird to me that they would throw the work into the trash. I'm not sure what the answer is, but I thought I'd mention it. Syncing work can be very difficult. We had food entities in the world that when they ran out of food would be destroyed. However, we struggled for a long while to figure out how we could enforce the hard limit on distributed food in a good way. It was easy to write a job that would query the food entities for the ants and if they were within range reduce the ant by 1 via a command buffer. However, it seemed difficult to enforce the ability to enforce that the data would not go below 0 food for other entities that might also share that sync point data. I ended up letting the simulation go negative if it needed, but I could see this being a problem in a more rigid environment. Is there a good way to enforce that data on other entities is correct? I'm still not really sure. Maybe this was fixed in a new package, but we needed to still manually add the hybrid renderer to a link.xml in order to prevent the IL2CPP from stripping the Hybrid renderer. Clearer separation between simulation and rendering worlds. I found out about this VERY late, but the idea of having separate worlds, one for rendering and one for the simulation would have been really helpful for us. Although we didn't have time to split the work. I'm a little confused still about how queries from one world would be allowed in another? Maybe an opportunity for an advanced sample? At the end of the day, I'm really happy that I spent a week with the DOTS system. It certainly gave me an interesting experience. I know you're still working on it, and I appreciate you taking your time to get it right. I also fully admit that a lot (if not all) of my problems may already have solutions in the current API. I mainly wanted to give you a user story of two OOP programmers doing a deeper dive into the waters of DOTS independently for a week. Thanks for your time!