New way of CODING in Unity! ECS Tutorial

lately unity has been making some huge improvements in terms of performance and writing optimized multi-threaded code and at the center of these changes is the new entity component system but before we get into what ECS is we need to know why it's useful also this video is sponsored by unity so using ECS has a lot of benefits it allows us to write extremely performing code we can code in a way that is easier to read it makes it easier to reuse code and with ECS we can take advantage of the new burst compiler for high performance c-sharp plus it's integrated nicely with the c-sharp job system so using easy s not only allows us to write extremely performing code but it's also a much better way to structure our data now that sounds great but what is easy s easy s is basically a new way of writing code in unity with easy as we are moving from traditional object-oriented programming to something called data oriented design so far when using unity pretty much everything has been based around game objects and mono behaviors say for example we wanted to create a player we would make a game object and name it player and on this object we would place monobehaviour components to give the player functionality these components would take care of stuff like rendering physics and movement with ECS we are taking a different approach by splitting our game into three parts entities components and systems entities are used to group together components they're much like traditional game objects but way lighter components are just containers for data unlike traditional amount of behaviors these components don't have any logic in them instead we use systems systems define component based behavior what this means is that a system is responsible for operating on all entities with a specific set of components these are the only objects that actually contain any logic so now if we wanted to create a player we would make an entity and on this entity we would place components however the only job of these components is to store data about a player so currently it wouldn't do anything to change this we create systems we could for example create a render system to render all in with the render component and a physics system to apply physics to all entities with the physics component of course the ECS package already has several of these basic systems ready to use so that is the general explanation let's see how we can apply this in praxis first we need to install EC s ec s is currently available as a preview package to get it we first need to install you in the 2018 point 1 or later we can then create a new project once it's up and running we can go to edit project settings player open up the other settings tab and under configuration will change the scripting runtime version to.net for X this will require a quick restart after that we can open our project folder navigate to packages and open the manifest.json file here we need to add a few lines I'll make sure to include a link to a text file in the description that you can copy from we can then save the file and unity should start loading in the ECS package when it's done we can go to window and open up the package manager and we should now see the entities package installed here now say we want to rotate an object over time first let's create a cube and let's create a new script on this cube called rotator if we open up the script we can see that as expected this automatically creates a rotated class that derives from monobehaviour with the old system we could then use an update method to change the rotation of the transform component and maybe create a variable to control the speed by running this code all objects with this script attached will rotate according to our speed variable and if we take a second to analyze the code we can actually see that the monobehaviour contains both the data which in this case is our speed variable and the behavior where we update the rotation now this might look fine on the surface but it's actually not a very performant way of doing things and it also makes it a bit hard to distinguish what is going on to avoid this with ECS we separate the data from the behavior and there are currently two ways to do this the first is using pure ECS this system is completely separate from the old way of coding with pure yes we stopped using game objects and mana behaviors all together the second way is using hybrid ecs to make it easier to transition from the old system to ecs unity has created a way to combine the two now this won't unlock the full performance benefits of pure ECS but it's great way to start converting your scripts to easy s and learning this new way of thinking the cool thing is that by using hybrid ecs we can continue using mana behaviors for storing data so currently we have some scripts sitting on different objects each script has some data and some behavior now with hybrid ECS we still keep a script on each object that has the data we need but we use a system to handle the behavior in other words we can use a class called the component system to update the rotation of all our objects now if this all sounds a bit overwhelming that's totally fine but let's try to take it from the top like before we first create a class deriving from monobehaviour but this time we only put our variable here then for our behavior we create a new class and derive it from component system we can name this class anything we want here we'll just name it rotator system also whenever we're working with ECS we need to include the unity entities namespace so now we've separated our behavior and data into two different classes but our behavior class is currently empty the next step is to tell our component system what components it should operate on here we're filtering all of our objects to look for those with a certain set of components in our case that is our rotator because we need the speed variable as well as the transform component so that we can change its rotation to do this we create a struct let's name it components and in here we create two public variables one for the rotator and one for the transform and now we're ready to make the object rotate for that we'll need an update method note that when using update inside of a component system we use the override and protected keywords and the name of the function must be on update instead of just update just like the regular update function on update will run on the component system every frame now we need to search for all the objects that we want to rotate to do this we use the get entities function and at this point you might be thinking I thought entities and game objects with two different things and they are but unity has made a handy component that can be used to convert a game object into an entity if we go to the editor and open up the entity debugger window we can see that the entity manager currently has no entities however if we then add a game object entity component to our cube it immediately shows up in our update method we can then use get entities to search for all entities with a matching set of components in our case we want to search for entities that have both a rotator and transform component we've already defined this with a struct and so we can simply feed that in we can then iterate over all the entities using a for each loop we'll call each entity efore short and now inside our loop we can update the rotation to access the transform of each entity we use edit transform and to access the rotator we use a rotator and that should actually work just fine if we run the game our objects rotate accordingly and we can easily adjust the rotation speed just like before and that's already an optimization that we can make because our Delta time variable is the same for all the objects we can move this out of our for each loop and keep it in a local variable to get better performance if you run the game once more everything is still working and if we go to the entity debugger we can actually see our rotators system and even cooler we can see the components it operates on as well as the entities in it awesome so that is how you can get started using ECS in unity again what we're using here is hybrid ECS if you want to learn more about pure ACS and the performance benefits that come with it I'll make sure to include a link for that in the description on that thanks for watching and I will see you in the next video thanks to all the awesome patreon supporters who donated in May and a special thanks to Michael Neely twins infants giver token ed Murphy Oh infinity PPR cheetah 3d Alex and the player Sybok mummy dark Eames Kirk Fresnel Murphy Daniel Sullivan thanks a long Superman great John Burkhart Lila set tennis sullivan jayson the Tito car Jackson for Brizzy Alex akatsuki Bruins cat Matthew Knight cool sweater ski James P Gregory Pierce James Rogers Naoki Misaki Robert pond now a tweet Tim of Hoda Park Jimin Adrienne has Nina and Erasmus you guys Rock

Channel: Brackeys

Views: 537,829

Keywords: brackeys, unity, unity3d, beginner, easy, how, to, howto, learn, course, tutorial, tutorials, fix, tip, game, development, develop, games, programming, coding, basic, basics, C#, ECS, entity, entities, entity component, entity component systemmcomponent, system, systems, approach, new, performance, change, example

Id: _U9wRgQyy6s

Length: 9min 10sec (550 seconds)

Published: Sun Jun 03 2018

Reddit Comments

[u/Kildon]

I feel these comments lack a discussion about how ECS enforces a certain structure to your code.

A trivial project gets no benefit out of ECS. But when you are dealing with large systems in your game that all interact between their own interfaces, ECS enforces the structure of that interface.

When you're only using monobehaviours there's a lot of decision to be made about where the logic of your game lives. Should the player have a reference to the UI to update the healthbar? Or should the UI have a reference to the player? This might be an easy decision when your game only has 5 scripts in it. What about when another developer starts working on their own enemy and enemy health bar? What if they answer these questions differently than you? Before you know it your project has 200+ scripts and the interfaces between how they all interact are inconsistent and a nightmare to maintain, refactor and debug.

Even the best developer will make the wrong decision sometimes. If you're working on a big project, whether by yourself or on a team, ECS gives you a much more structured set of decisions to make:

• What are the core systems my game needs.
• What components do those systems rely on.

Now I can design myself a UIHealthBarSystem that relies on a HealthComponent. Anything with health can have a HealthComponent. My UI doesn't even know that a player exists which is great because it doesn't have to. It only needs to know that there's some entity that has a HealthComponent to it. Now, any health bar I show on my UI uses the same interface and I don't have to ask any questions like when I was using only MonoBehaviours.

ECS absolutely has a learning curve and it adds a layer of overhead to prototyping. IMO the benefits do outweigh the negatives though, and I don't plan to start a new large project without using ECS in some capacity.

[u/[deleted]]

This makes so much more sense. Component based systems are confusing because data and logic are combined, this is much better.

[u/DavoMyan]

This is perfect for massive games honestly

[u/MengKongRui]

I wish he explained how it actually is more efficient than monobehavior. I'm not convinced it is worth the effort without any evidence of better performance or easier scalability.

EDIT: My understanding from the replies is that, basically, there is a greater overhead calling the Update() method for a hundreds of objects with the regular monobehavior practice, versus just using a loop to go through those objects and update them all in one main update method.

[u/sweetbabygames]

The biggest reason to use ECS is that it optimizes really easily with data locality. RAM < L2 cache < L1 cache is the reason modern devs like C# over C++ (because the garbage collector does some of these optimizations for you).

Structure-wise, there’s not really a huge reason to use it over other patterns. Quick optimization is 99% of the reason we do this.

[u/jayd16]

ECS is looking pretty good. I'm sure we've all done this "move similar code into a singleton" type pattern before and have seen it work.

Honestly, anything that helps the overhead of the Unity lifecycle is a welcome change but I can see how the Entity Manager has optimization opportunities. The EM should have an easier time keeping track of entities in a scene than every behavior trying to find and manage all the components on its respective GameObjects.

I'm not sure how code will look in a pure ECS world though. How does UI work?

[u/Terminatr_]

Even from my very fresh perspective in development, I’ve kept finding the monobehavior system just not feeling natural. This actually makes much more sense, and I’m looking forward to using this. I’m ready to go pure ecs right now, regardless if I benefit from the performance efficiencies.

[u/vasinsavin]

Very excited about this. It's still on the very early stage of implementation so essentially it's still not pragmatic. It makes so much more sense writing codes this way imo.

I was often bugged out by the hundreds of monobehaviour updates running. I was always using a similar approach that uses monobehaviour only to store data and feed/register them into a main system that run loops as an alternative. Not much of a perfect solution but it works.

Seeing them to add them into unity natively makes me nothing other than a happy man.

[u/matej_zajacik]

I'd definitely prefer this approach to slapping MonoBehaviors on GameObjects. I've written a few ECS solutions for Unity and I was always happier with them than what you normally do. So, yes, it's great. But right now, it's simply not finished, lacking a lot of features.

You can use the hybrid mode for now, having Monos on GOs, and write systems that operate on groups of Monos, but that's just half-way to the goal.

I'll rather wait until they have a more fleshed-out version and then give it a serious go.