2 Ways to use UI with Unity ECS 1.0 - Unity DOTS Tutorial 2023 

I am a full-time Unity development engineer.I like to watch your videos and learn from them.Although my English is not good, sometimes I use bullet screen translation. Thank you.

Thanks for your video. I'd love to see some (up to date) video about physics simulations in dots with collisions, raycast etc. Great work, keep it up.

+1 for the "new" input system integration. A quick unrelated side rant, I really think unity needs to take a hard line on what its next gen vision of the tool is. Making a modern unity project is about knowing what extra packages to install and what features to not use.

I'm here just to learn about UI but your project has taught me more than that. Awesome! Thank you very much. Can't wait to watch your new Input system with ECS tutorial.

Great timing, I currently need to make a UI with these elements for my project. I was going to make some kind of UI system from scratch, but I realise I was over engineering the problem. Thanks for this.

This was super helpful as always! I'm trying to work on a game like Risk of Rain 2, though a topdown 2d game, and I'm learning DOTS for the first time. It's actually going to be very functionally similar to your vampire survivors clone from the game jam, though with lots more enemies of course. I know you had mentioned more content on that later, so no rush of course, but what sort of content can we expect soon? I'd love to learn more about some of the content from this video expanded to jobs and fore higher entity and projectile counts, since things like single damage components might not suffice when an enemy gets blasted 20 times a frame. Similarly, I'm very excited to see how you implement the new Input system. I was gonna take a crack at it myself, but if you've got it in the works :). Thanks again for everything, you really produce high level, clear, concise, and helpful videos.

Cool video! I like to connect both approaches by making a class in UI/View that wraps around a component and checks if it changed since the last time the view was updated or the previous tick in simulation (by calculating a hash code for example). And if it changed, it can invoke an event. If implemented well, you don't need to manually invoke events in simulation just because UI needs them and you can still have an event-based approach with less boilerplate code, though not without flaws. Photon Fusion uses it with "OnChanged" for their networked properties.

tnx for covering dots

I am currently porting my MonoBehaviour game from Unity 2021 to Unity 2022 to take advantage of DOTs, and this video is really useful for me to modify my existing code to provide Monobehavior/ECS interactions. The game is a multi-choice Adventure using INK book scripts - like an illustrated interactive book except that the illustrations are in the 3D. Most of the game doesn't need to be fast - my menu loop just waits for the player to make decisions, reads the Game Book then animates the 3D world accordingly and provides more book text and player choices. In short I want to use DOT's for animation and character controllers, but retain all the XML UI and MonoBehavior stuff that spends most of its time in a 100mS sleep, polling loop anyway. I am finding your Videos really useful, watching them repeatedly as I get my aged ObjectOriented brain used to thinking in the ECS way and start to understand the code as you describe it. I really appreciate that you updated the code for your Zombie Video to keep pace with the latest versions of DOTS. What I would like to see is efficient code templates for DOTS and the interaction between the new Unity MonoBehavior XML UI and DOTs - so I can still use my existing XML menu overlays, but take advantage of DOTS under the hood.

very cool video i didn't see any .schedule or .complete for the entities during the process does it effect threading and the memory allocation automatically when combining Mono with ECS?

This is very timely as I am currently trying to optimize our management game. I am currently doing something similar to how you made the Read Value implementation - having a reference to an entity in the MonoBehaviour. Although, I did it such that an agent's entity is created when the agent's MB prefab is created. I understand that in your case, the player entity is a singleton entity, so it makes sense too, to do it the way you did. Curious, what are your thoughts on a Syncing system? I have something similar where a MB implements an interface that a syncing system is using so that if an IComponentData is changed, the data will be reflected in the MB's copy. I'm currently using an isChanged boolean in the IComponentData and a job collects all changed components, then a non-job method calls the MB's sync interface. I'm planning on using ECS 1.0's IEnableableComponent so that I don't have to go through a component that I know is not changed. In context, we are handling thousands of entities for pathfinding and AI. I made it a "restriction" to still keep a MB workflow to make debugging easier, and also so that designers and artists are still happy.

Thanks, this is a good solution. I think this implementation can be applied to create Particle System prefabs.

The online game made by my company crashed due to the UI. What you shared effectively solved the problem. Thank you for sharing.

Great Vid! Hi Turbo, I wish to know is it possible or is it good approach to put C# event in Aspect? Is it systembase the only place where C# event could be placed in ?

Do you by chance have a good tutorial on how to export android apks? I keep getting a debuginformation file instead of the apk when i build and buildmethod errors in unity. :(

I foresee issues with the DamageToPlayer approach. In other games it would be feasible that the same character could receive damage twice in the same frame. And you can't add the same component type twice to an entity, so an error would be produced

I would highly recommend a Animation overview with MonoBehaviours and DOTS.

Good video and the old one! But I would also like to share my experience: 1) At first, I've used the SharedStatic Messages approach to queue the received chat messages in the ECS system and then TryDequeue them in the Update() of the Mono UI element. This way is described in the official ECS chat sample, but if I remember correctly they use a slightly different type, which didn't work for me in the latest version of the ECS package, but the concept is the same. 2) Then I switched to a hybrid MVP\MVVM UI architecture with DI (Zenject) where the View cannot have any logic including the Update() method and everything is based on reactivity (models with reactive properties). So I just manually inject the model using the method's [Inject] attribute into the ECS system (given that we cannot use the ctor for it since it's used by the ECS container itself) and enable that system at the end of the method. And then change the model value to trigger the events Feel free to ask any questions. With love from Ukraine!

What are you thoughts on handling things like UI through managed components, similar to what you did in your earlier UI tutorial? Is it not practical anymore with Entities 1.0?

I've tried ECS Physics on mobile android device. Just 150 cubes falling dawn, and I get 20 fps. It's even worse than monobehaviour. Is this something expected? Or just happening on android? Would love to hear your thoughts or new video on it!

Note: An Action or Action is just a _delegate_ ... it's not an "event". An actual event is an event, and we make an action into an event by marking it with the `event` keyword. You may be tempted to simply make it a public "field style" event, but don't. Use full event accessors like the Microsoft C# documentation for best practices recommends, especially when code on multiple threads could potentially (or even _someday might_ end up) touching the event at the same time. That results in *undefined behavior* ... there is a misunderstanding people in the Unity community seem to have about this and the nature of events, and some people claimed Roslyn generates the same code and does all the work for you. As I have confirmed with ILDasm and inspecting the IL code generated for each, Roslyn does a _small part_ of the equation and generates a public accessor, but it doesn't implement the *lock* pattern or any "real" thread safety. So inside the add/remove accessors you need to wrap things in: lock( _objLock ) { // Handle things in here ... // You can log or set breakpoints too to debug registration/removal of subscriber pattern myPrivateEventField += _whatever_ ; }

Hey, beautiful video! I have a question: you brought two examples where, in the end, it is always the ui that receives the data, but, what if I wanted the UI to send the data to a system? e.g. upon pressing a button an entity is spawned?

What's the best way of detecting collisions in ECS 1.0? I notice it's been a while since your last video on it, have things changed much with release?

I have two issues with the event approach, and one minor issue with both. Event Approach Issue 1: You can only trip UI events from the main thread without burst. If there is some CPU intensive code that might every now and then trip an event, it would need to be converted to the main thread with burst disabled. There are event paradigms that can be sent from multiple threads, but they are more difficult to use than Unity events. Event Approach Issue 2: Fetching a system is generally not a good data orientated development practice. I think that's why Unity started adding a singleton to every system. In a "Data is King" approach, everything is tied together via the data and the various systems are ignored. So for example, if the UI was ported to a different game, that new game might have totally different systems transforming the data and the UI would still work because all it cares about is that the proper data is there - not a specific system. It contributes to modularity. That said - the whole point of this video is to hack around the fact that Unity UI is not DOTS enabled, so perhaps that could serve as an adequate excuse for an exception to this principle. Minor Issue With Both: It should be mentioned that DefaultGameObjectInjectionWorld could introduce problems in a game with more than one world. To be honest, I still use it in my monobehaviours because it's so convenient, but hopefully I'll find a better solution someday if I ever want to make the game multiplayer or use different worlds for game-saving or other things. Other Comments: 1) Unity events are around 20x slower than C# events (probably not a big deal for UI things). 2) Setting the target entity to the projectile is probably not a great idea unless you can guarantee that enemies won't move around - otherwise a projectile might hit enemy A and enemy B will die if the two switched positions as the projectile was traveling (not a problem for this simple example though). 3) By using a single damage component, there would be a problem if multiple players were blasting weapons at the same enemy - sometimes the bullets might hit on the same frame and only one bullet would get counted (again, not a problem since it's just a simple example). 4) It's worth mentioning that if it's anticipated that you might have thousands of events updating a counter or something at a rate faster than a couple of times per second, it would be more efficient to use the second approach with a timer - the human eye won't notice if something is updating faster than a few times per second so it would just be wasted CPU.

Is ECS officially ready for production now or still in prerelease? We are finally almost in the middle of the year and last year (after so many years of development) it was said at the beginning of 2023 with Unity 2022 LTS. Well, you can't say they are lying at Unity as the 2022 LTS version hasn't been released yet. However, it should already be outside.

hi! awesome video! thanks for your help to the developers community. I'm trying the read data solution, but i'm facing to on problem. You said "is a solution when you want to constantly read of changing data" but the system throws me an error, because i'm tryng to read data on entity wich is going to be use in a job (at least, it is what i understoob by reading the error in the unity docs) "NullReferenceException: Object reference not set to an instance of an object Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle.CheckWriteAndThrow (Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle handle) " Any idea? :D

Hi Turbo. Do you try 1.0.8?

Best way is to use mvvm pattern with ui tollkit where M -> ecs component data

Ecs the one thing that may be useful but never had the time or Courage to learn how it's work To be fer the are way more important stuff i needed to learn, like for example networking and inderfece Unlike ECS , inderfece and netcode it's essential for the game I'm working Im mean the ECS it may save a little bit performance or whatever But both inderfece and netcode the open i big potential and possibilities

You could just remove "actually" and "go ahead and" from all your sentences to save time on the video ;)

Thank you! Now I can go back to a project that I putted on standby because I didn't know how to deal with UI and ECS :). Especially, how to get the Entity from a Monobehaviour.