Converting your game to DOTS - Unite Copenhagen
ฝัง
- เผยแพร่เมื่อ 1 ก.ค. 2024
- In this video, learn about what's involved in migrating existing game code to the new Data-Oriented Technology Stack (DOTS), which comprises the C# Job System, the Entity Component System (ECS), and the Burst Compiler. You'll also gain an understanding of the performance benefits you can expect from these systems. Finally, you'll learn when it makes sense to use them, and when to stick with the regular components you've used in the past.
Speaker: Mike Geig - Unity
Learn more about DOTS: on.unity.com/2mPaVBV
Slides available here: www.slideshare.net/unity3d/co... - เกม
This guy's mouth works faster than the burst compiler.
Awesome presentation, thanks.
That's my new tagline!
And even so, I watched the presentation at 1.75 speed... It's amazing.
I remember Mike Gerg from old Unity tutorial, such a wonderful tutor.
Thanks!
Wow I tough this was just another good cheesy way to introduce ecs bit it's actually teaching how to use the new stuff, really good ty ty
One of the best and cleanest to understand talks :D
It's just a great time for games, I learned OOP at school and turning into DOD and DOTS makes my life easier.
This is a game changer to all the industry, too bad that many senior programmers are complaining with the changes
I, for one, have (unknowingly) always been a more data-oriented guy, but, since I am programming-wise not too experienced yet invested, I didn't know how to implement such concept; and this really helps quite a heckin lot!
Thank you for this amazing practical demo, great job Mr. Geig!
This guy figured out how to show/teach the new features such makes it super easy to do ecs. That's his main merit looking back..
Thank you for the presentation Mike Geig, i'm hearing to talk about the job system and ECS for a while, and just now i wanted to start to using.
I feel your pain
Mike Geig - This is the clearest explanation and clearest set of examples I have seen. Great speaker, a dash of humor, with a very matter-of-fact perspective and he knows his stuff. @Unity - Pay this man more.
Mike is a great tutor. I remember watchin hours of his tutorials back in the day, and I just now realised I never knew what he looked like lol.
I hope my face lives up to imagination, though I know that it does not :)
Even years later this is the best video I found on practical DOTS usage. Converting a small part of an existing project to DOTS which is exactly what I need.
Mike Geig is a genuine, intelligent, well-spoken, and I suspect very kind person. The type who makes me proud of humanity and to be a tiny part of the Unity community. He is also a fantastic presenter. Thank you for sharing this valuable information in such an easily digestible way. The whole community is better for having you in it, Mike.
Great presentation. I don't even use Unity but can appreciate how good Mike is at speaking.
what a wonderful presentation :3 can't wait for the upcoming dots updates :)
Im so intrigued by all this.
Really clear speech - beautifully presented, thank you!
This is really impressive!
Mike Geig is the man!
Mike , the best Unity Evangelist !
I see Mike Geig
I hit like button
Mike, please give a talk on how to give talks. I mean it. There are really smart developers out there (and in Unity) that can't present and are painful to follow through an entire presentation. These skills are real, are needed, and you have them.
Wow, a lot of work was done :)
best teacher ever.
Thank you!
My eyes have been opened!
Seems easier than expected. Time to build a true city sim now...
amazing presentation!
Great presentation. Ty!
this guy is great. easy to understand talk!
Thanks
Finished watching the video, it's super awesome!!
I have a similar problem, when you instantiated the bullets i was like `: [______] totally agape
Love this guy! He's so funny lol
Wakka Wakka
Very clear 👌🏻
Finally, I can scrap all my over tinkered and complicated buggy pooling systems in my games. And as a bonus, it really goes with my style of programming. Heavily array based! :V
This is amazing, i love it.,
Spectacular.
WOW a few years back all I needed was using UnityEngine; and I have access to the entire runtime API.
Now there is like a different namespace for each different few classes, you need to load a scene and you have to use SceneManagement, create a Translation? use Transforms, float3? Mathematics, wanna try an optimization attribute? UnityEngine.Burst ...
At least group the DOTS stuff into a single namespace or something.
This is an important change for a couple reasons. 1) If using UnityEngine gives you everything, it gives you *everything* whether you need it or don't. 2) by separating it, we have the ability to release updates at different time intervals from the core engine. This way, you don't need to wait for the next dot release to get a bug fix to an auxiliary feature
Love it !
good explanation, thanks
Thanks!
this is GREAT!!!!!!!!
I hope Unity will focus on this DOTS package, its really like the way we coding with OOP than the pure ECS
Mike Geig
Junaid Malik
Awesome presentation, but I got confused a bit, what I know about ECS is that you have to define Archetypes with Components, and then write Systems for those Archetypes, here the ProjectileBehaviour script has been converted to ECS with the interface method (if I understood it right), the additional structs were created almost as boilerplate to run the Conversion method, the bullet behaviour remained in the Update() and was not implemented as a System, isn't this against the principles of ECS? Also, if it can be easily done this way, like it has always been, with no performance hits, why should one use the new harder "counterintuitive" way described in the documentation?
I'm just trying to understand what the best practices are and the right way to implement ECS, thank you!
9:20 this far in and tbh what you just described sounds like nothing more than OOP but enforcing the "one reason to change" rule.
great talk
Thanks!
2 questions :
1 - Where should we attach the System script? in a dummy gameobject or on all enemy objects or where?
2 - What if we query unwanted entities that match the archetype but are not 'Enemy', how we know we got the right entities?
3 - Why doesn't Unity automatically handle the query for us?
I mean let's do things the old way : we attach components/systems to entities (gameobjects) or prefabs, Unity gathers all entities that we attached the script to, and then run a single system on all of their data and handle dependencies and job structs under the hood?
It would be PERFECT! So why NOT?! Did you guys thought of it?
Howdy, 1) You don't "attach" systems. If things match the query, then they run on the data. 2) If your query is pulling entities that you don't want, then you need to refine your query. The entity debugger will show you all the entities that match the queries of your systems so you can tell if it is grabbing the right things. 3) How would the engine know what entities you want to filter for? Granted, there will be more UX iteration and less boilerplate code in the future, but you will always need to determine what entities to query for
in respect to differentiate between Entities that have the same components but aren't the same "type" you use a tag component
it's a component like any other, that you attach to an entity, but it contains no data (so it doesn't weigh in memory) and you use this tag to refine your search
for instance, both players and enemies may have a healthComponent, and maybe you want a system for the players health only
You would add a playerTag
and filter with both components
there are another talks at unite 2019 that answer this questions, just take a look at the ones that talk about ECS and DOTS
I recommend one that's about creating a third person zombie shooter with DOTS
I've literally shivered at the lack of using 'using' @23:55.
Ya, I thought about doing it that way, but I wanted it to be very obvious that I have created it and then needed to dispose it. "Using" doesn't make that completely obvious to a casual observer
ECS implementation starts at 14:06.
Everything before that is, "Should you use ECS?"
If you are here for the thumbnail, you'll want 6:29
Someone can tell me if there's a training related to the job system? or that DOTS thing, i love it, and i want to learn more about.
Jobs is part of DOTS. You should focus on tutorials like this one that teach you how to use all three pillars of DOTS (ECS, Jobs, and Burst Compiler) together. But many tutorials just use Jobs and Burst Compiler, OR ECS, instead of all 3.
This is bizarre, I've just started to try learn coding and this is what I thought everything had always been structured like? When I talked to other programmers about design choices centred around things being defined by the various combinations of shared data like this they just couldn't comprehend it. Maybe I still don't get it but this sounds like such a greater intuitive approach. This is the approach I always had in mind.
In any case, are entities able to be built in an editor like prefabs? What about animation clips and all that? Can gameobject components be used as regular on entities? All of them?
For better or for worse, we've spent a lot of time trying to make code act more like the real world.
Amazing performance. Will these performance benefits carry over to networking / multiplayer? I'd be scared to see what happens if I send 60,000 bullets around in a networked game :-) But it would be amazing.
7:08 :D Free your mind the rest will follow... Einstein? or was it Ein vogue. (I know you know)
@Unity could you maybe put the project in the asset store for us to review the example in this video.
This is great, but where is the repo you promised! You tease!
Team sameline; also team var :D Still enjoyed the video a lot, thank you!
Poppycock!
I also use 2 space indentation :P
@@Bossti AAAAAAHHHHH. You're the type of person my mom warned me about.
The type of person who grew up in the K&R ghetto of C style coding (sameline { and stuff) :D Hey, at least I‘m not using m_ or *gasp* _ as member prefixes. Anymore. :P Also, I can see the appeal of still not using var but then again I try to limit my line width to 120 characters and some type names can get really really in the way of readability. But I don’t mind it when I read other peoples code. It‘s like just because I like Conan Doyle I can also enjoy some Shakespeare
@@Bossti Fair enough. I can get behind that common ground.
World.Active is deprecated already, great tutorials unity!
Can somebody explain to me why we can't use the ConvertToEntity component on the prefab (17:55)?
Any chance we could get an updated version of this thst works?
OK so if I understood it, you would want to put the collision detection system in a separate Job, right?
It is already -running in its own job (edit: I haven't seen the source, so I don't know if thats the only thing the job it is in does, although it is a fair assumption)- jobified , that's why this demo was possible. What he meant is that it is not efficient to run all those collisions as, for example, some are guaranteed to never collide, such as bullets going the same way an enemy is or bullets higher than the enemy height. There are lot of ways to go about optimising this, some already implemented in the physics engine, some more project specific. Wikipedia has a nice overview under the optimization section of the collision detection article.
@@ChrisDaramouskasGiannikou So the job is not the problem but the implementation?
@@masterneme Exactly, it's an overkill to run collision checks between every target/bullet.
@@ChrisDaramouskasGiannikou I see, thank you.
Yes, what was said is correct. Also, even once an enemy or bullet dies is a collision, all other enemies / bullets still check against them for collision so it is wasteful
from where does he get the "translation" for the manager.SetComponentData ? - in the project there is no translate component, but my intelisense does not pick up on translation... ?!
try "using Unity.Transforms;"
@@mikegeig4297 thanks for you answer :)
How should I handle animations? I've been searching for days but couldn't find any applicable way to do it!
Is there another way of getting the enemies instead of using the empty struct? I'm working on a new project and I'm adopting pure ECS and want to make sure there isn't a better way.
You could query for any data component they had. In this case though, there wasn't any data that was specific to enemies that no one entity had, so I created an empty one. I could have put data in there, but it would be wasteful since I didn't need any data
@@mikegeig4297 That makes sense. I'll have some more specific data that I could check against. Thanks for the help
Isn't this a repost? I feel like I've seen this demo before.
Lots being done at unity (roll eyes)
It's an updated version - hoping to see NEW Code
I've done the talk before. I was asked to deliver it again.
@@mikegeig4297 Thanks for clarifying!
@@mikegeig4297 Great talk, but I would love to see an ECS demo that wasn't just a fancy particle system demo. Rarely do most game entities simply rotate and move forward. It'd be nice to see how ECS can be used for other gameplay tasks such as driving animation, more useful AI/target selection/decision making, event handling such as handling events from triggers, etc. You know, things most people need for a game :).
Added all the scripts along with ConvertToEntity on the player. After installing Hybrid Renderer the bullets do render but they do not move. I even tried installing Unity Physics. On the other hand just adding a prefab into the scene does move it. Not sure what I am doing wrong. The object is also not destroyed after 2 seconds. Please help @Mike Geig.
There is a system that moves things forward. Check out the repo to see all of the code. I only had time to show a small example
So why was instantiating a bunch of bullets so slow in the first place and then suddenly so fast in ECS? I'm pretty sure its not related to CPU cache misses =)
Well maybe the reason was allocating a bunch of managed objects but I didn't quite get that from the talk.
Otherwise a pretty good demonstration on how to get started.
There are quite a few factors. Part of it is needing to load much more info into the CPU and traversing memory when dealing with Monobehaviors and Game Objects.
Mike Geig I see, thank you Mike! Actually we are about to start implementing ECS into some parts of our project. I’m expecting it’ll be of great help!
@@lama89625 Let me know how it goes! Definitely plan your data out on paper first. Can help a ton!
Where is the link of this Project?
This is just another implementation of microservices and data logic separation. This is the way of the future of programming.
If BurstCompiler is "always good" except for very specific scenarios, why isn't that the default and you have to type [NoBurstCompile] or something instead?
I assume it's because it's still in development ?
Not all code works with burst. If it was on by default for each method or job, you'd be flooded with "this code doesn't work with burst" messages
AND GOD SAID LET THERE BE LIGHT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
hm, I fail right after minute 21. I create some spheres from a prefab with rigidbodies and collider attached. (I do no custom moving just plain physics). All the entity conversion works, entities are displayed in the inspector with the right coordinates, but they do not show up in the scene.
I cannot see any renderer or rigidbody attached to the entities though. Am I missing something?
Do you have the Hybrid Renderer package enabled?
@@alessandrocolombo4192 thanks, I installed the hybrid renderer and now it get´s rendererd. great. but physics do not work. rigidbody and collider are ignored. I also tried to install "unity Physics" but that does not help.
rigidbody works (I had set iskinematic to true). though I wonder why setting it to false via script does not work. Anyhow - colliders do not interact with terrain or other "normal" monobehavior objects. But they work for entiy colliders.
The demo that was sent out Is shomehow confusing since because you can spawn either go and entities you have also normal monobehaviours but entities interactions as far as I understood and got have to be managed via specific jobs
(I'm not native so in order to avoid misinterpretation I just want to quickly point out that I found this video very clear and useful (I was at Unite too) I used the world confusing as in ambiguous in some points :))
What does he use to zoom in like that?
Windows built in magnifier now supports hotkey + mouse wheel zooming
I'm generating less mobile battery heat..
Well that's good
Have anyone tried this with a real game? With Entitas, the code is not that easy to maintain when you have about a hundred components and systems
@Keeper Holderson Well, first of all, class connections are easier to track. Also classes are easier to group into libraries, refactor or change. I don't know what's possible with ECS, I know only what our team did, and it was not really manageable
There are several titles being developed with this tech. I totally understand about maintenance concerns but have come to feel like it really isn't that bad and in a lot of places can be much easier to extend, maintain, and track. It does require some workflow and design changes though, which can be a large investment depending on your team size and skill set.
We use it for a multiplayer mobile game. Can't imagine doing it without ECS, would a pain due to specific requirements of the game that leverage the performance benefits of ECS. Also writing logic in systems separate from data makes game mechanics more scalable.
40:32 Like )
How does "saving" entities work vs "saving" game objects in a game?
Not sure I get what you mean? It's all data either way. Do you mean serializing to a file?
@@mikegeig4297 I suppose? Say you have a game where your carrier space ship is making millions of drones - how would you save that entity data to a file so when they restart the game, those drones reload into play. I'm assuming some similar fashion of calling / creating the entity, but I don't honestly fully understand that either...
@@nicholaswillcox Same as you would with any data. You would run a system on the main thread that queried for all the data you wanted, and then use IO to write it to a file / database / whatever. Loading would work much the same way
Why don't you finish dots so we can use it? ECS is 0.1
Why i am getting this terrible results from Dots. At Mono behavior i can do 80K Cubes about 10FPS (Static, Mobile Diffuse Shader) while using DOTS i can only do
Are you using a material that supports GPU instancing? It really makes the hybrid renderer run more smoothly. May also be something to do with system timing or something.
This is not a fair comparison, you shouldn't compare just the number of lines.
manager.SetComponentData(bullet, new Translation {Value = gunBarel.position});
is way more verbose than simple :
bullet.transform.position = gunBarel.position;
Why can't we ditch managers and access dots component with simple dot notation? (pun intended)
I don't think this is good enough progress for me, I hope you continue to hone it down more.
Entities don't "contain" anything, which is why dot notation won't work. They aren't pointers, they don't contain data. They are simply indexes of a memory collection. So manager.SetData(entity...); is more akin to saying myArray[entitiesAreIndexes];
@@mikegeig4297 Hi Mike, thanks for all your replies.
Believe me I do know what DoD is, and its differences from OOP.
But I was talking hopefully of another layer of abstraction that could potentially let us keep using SOME of the workflow/UI OOP principles we used to have should we choose to (for good reasons).
Mainly the [option] to attach data/system combos (a single script that contains both) just to tag our target entities.
Then the ability to automatically query those entities and their data.
We'd implement a function like OnSetup() to get any extra data and references like Time.deltaTime then work as we're used to on maybe OnUpdateForEach() (we'd not even need dot access - everything is set from OnSetup())
Unity behind the scene schedules the system on all components that are tagged with the "script" so to speak.
That way we can have the best of both worlds without the entity manager and query headache.
This is also practical: think if we have identical entities and want to only randomly select some of them to run.
All this could be just an option of course, we also could use query system without attaching scripts as well.
This is all just a thin layer of abstraction and creativity to make things a bit more terse, I'm not arguing about the data philosophy here and nobody says we can't improvise.
Those enemies, are they entities or gameobjects?
Entities
Is that mean that now game so-called "garbage" like dead enemy bodies, bullets marks on the wall, small derbies of the cracked wall, fallen small parts of the vehicle body after the collision - actually can be left on the map without the need to destroy them for the sake of saving memory space?
Or what?
hmmm didn't unreal engine 4 already this did 9 years ago? or at least they told us they did lol
I must be an idiot because I seem to be the only person confused on this...
Why are we creating a new MoveSpeed and TimeToLive component and how are these ComponentData's being used when the movement is still handled in Update using the speed local variable and lifetime is being handled by an invoke using the lifeTime local variable.
These two components seem entirely pointless to me in this context and I don't understand what I'm missing. Is it purely for the sake of 3:15-4:50? if so why are we even bothering to have any data when the implementation doesn't use it.
Can somebody tell me how in the C# hell implementing a generic interface in a struct somehow get you all the objects that contain those generic parameters?
If it's under-the-hood magic then Unity might as well hide this nonsense under the hood and find a better way to find out which objects we run our systems on.
It's probably reflection, or more likely an extension method for an interface. Can't go far in C# w/o both of those, highly recommend you learn about them.
@@phobos2077_ isn't that bad for performance?
@@thomasanderson1416 not bad if it's done only once during initialization phase. Irrelevant cost for a lot of ease of use benefits.
@@phobos2077_ In that case they could use some sort of FindObjectsOfType internally and it would be even more easy to use.
That was my point all along.
@@thomasanderson1416 there is such an option as well via EntityQuery. Not sure if it's possible to process these queries via Jobs though (using multiple threads)
i just want to read/write from specific entities. Like in my IJobForEach, I want the current entity to compare its data with each and every entity. How?
there is a Unite Talk called Interaction between Entities where they explain this precisely
it's not as direct as an oop approach
but it's a way better code structure that can save a lot of time, memory, and problems
but I'm curious, in which case would I need to compare an entity data with every other entity?? please give me some examples
EnemyTag component?? Really??
God I hope it won't make it into production like that.
Do you still attach scripts to enemies or not? if so it should be a piece of cake to query all the data to be processed without us writing a single line of code besides logic?
So why all this verbosity?
because it's in early development stages and this is just a demo
(I hope)
why "NativeArray"? why not "System.Collections.Concurrent"?
Does it mean that you need to do BlowJobs while doing an expolosion system?
2019.1 ????? 2019.3 is what Unity is pushing out .. Oh NO'ess
It works on either version. The packages update independent of the editor version
@@mikegeig4297 Brillant! My DATA will be happy
@@snaecooceans8744 that's what it's all about!
job's got too much boilerplate, make it better
(good presentation)
half of the code is scaffolding... this is one verbose framework
Just love how every single ECS video manages to leave out important details and be out-of-date one month after it's released.
1. You need to ALSO have the Hybrid renderer package or entities will be invisible
2. The github repo already doesn't work on 2019.3, **ONE MONTH** after the talk.
Lloyd Vincent it’s almost like the packages are marked prerelease for a reason
Good catch on the hybrid renderer part. I forgot to mention it in the talk. To be fair though, it is extremely difficult to mention *every* single aspect of something in a talk. Regarding the repo, I have an updated version that will go live when 2019.3 does. Remember that 2019.3 is beta and isn't out yet.
Thanks for the reply. I don’t expect all the details, just enough that it’s possible to follow along.
Great talk otherwise though, between this and some tinkering around I was finally able to get ECS working on my own from a blank project, something which has eluded since late 2018.
@@LloydVincent11 I'm glad you got it working. Let me ask your honest opinion (so I can do better in the future). Obviously, you were frustrated because the talk didn't fully equip you to try this out yourself. I assumed that having the repo would be good enough support to enable that, but as you pointed out the repo doesn't work with the latest beta. If the repo had worked with the latest beta, would that have been good enough, or should I have been more thorough in my presentation explanation?
that "technical hurdle" that you used to convince people into using DOTS is really bad
Why pretend I have to use DOTS for this and that the particle system doesn't exist
if in real production we would use the particle system
you need to give real world examples
The performance gain is not worth the amount of trouble implementing this into a full fledged game. This looks like a nightmare. Unity is unity because it's simple
Really liked Unity at first ... then after a few years of development I find myself stuck in an older version with no hope of making it current.
Unity don't seem to care much for your past work as they push forward obsoleting everything you created for the pass year.
Examples at ~12 minutes are bullshit... He tries to compare a poorly designed MonoBehaviours to a full-fledged ECS.. Completely misleading. No one stops you from splitting your MonoBehaviors into small pieces of data+logic that each solve one task without any code duplication at all. The real issue of MBs would be the logic "spreading" across multiple components, which is really not ideal. There are ways you can work around it using self-emposed guidelines but going full ECS at this point will make your code much more manageable. ECS works great when a lot of stuff interacts in complex ways. For simple UI stuff like controllers and views I would still go with MB's for simplicity. There's a room for both OOP and Data-Driven Design in games, you shouldn't go crazy and resort to just one programming paradigm. Each is a tool for the job it was invented for.
Totally agree. I even try to point out that this situation is ridiculous and I am only using it because it is an easy to understand example.