Unity at GDC - ECS for Small Things

[Music] wait okay now from the beginning cool already hello everybody welcome to ECS for small things thank you all for coming here at 4 p.m. on a Friday I know everybody's energy level is probably kind of dipping you're all kind of ready to go home but I see a full house so thank you all for being interested in this topic I'm gonna try to keep it interesting keep the energy level up but I'm also not gonna make you jump up and do jumping jacks or that kind of stuff so no you're welcome so ECS for small things I'm glad we key to each I'm the lead engineer runtime solutions what this basically means is my team is looking at figuring out how to bring unity into new areas that might have been a challenge for unity to go to before you've heard a lot today about this notion of performance by default where we have a lot of new techniques and approaches where the goal is to enable us developers to bring performance into your game by default that tools such as the ECS architecture the new job system the burst compiler all of these things will work together or will work together to enable you to create games in one way and to get performance by default out of this and that's really what we want to enable that one way to design content and to write code but along with performance by default we want to add another piece in there which is scalability by default your content needs to run not just on massive high-end pcs with you know millions of things happening at once but you also want to reach different use cases things where a load time is important things where small size is important maybe you want to reach areas where your users are bandwidth constrained limited data caps slow mobile networks in all of these cases the smaller package that your end result can be in the more reach you'll have to your users and basically the more games that they will play so scalability by default we want to make sure that we let you scale up to high performance but also scale down to these instant light experiences how do we do that well we start with the same concepts we start with this concept of data oriented design that you've heard a lot about if you've been in previous talks here today we leverage this entity component system architecture which again helps you design games and design content in a certain way that both gets you high performance so again the performance by default piece but also helps you scale down and helps us optimize for the size of the resulting content thus giving you scalability by default as well so with a lot of the the talks you've heard today the focus has really been on performance how do you get a million things happening on the screen at once how do you get a million animations happening but instead for this talk we're gonna focus on size because what we've realized is that there's a lot of areas where small is really the new big where the ability to go down tiny is really where you want to get to so once you realize that we were trying to figure out how do we take unity unity concepts and how do we actually bring them down to this very tiny runtime size very tiny final content size there's a couple of key pieces of this the first is that we use a pure ECS system so there are no classic components you don't get access and fortunately two unities current kind of powerful capabilities but instead we have a highly optimized tailored feature set that will be growing over time that is focused on enabling these small and use cases the pure ECS architecture gives us a clean separation between data and code it lets us optimize for size and performance the parts of our engine well giving you flexibility and building up complex interactions and and in your gang code and this is kind of the the main architectural piece that lets us actually scale both up and down the next aspect is that it is highly modular we really want you to pay for only what you use if you don't need physics you shouldn't have to pay the cost for physics either in code size or runtime performance if all you need is simple ray casts we should give you the ability to include the capability to do just simple ray casts and nothing else if you don't need a particle system you shouldn't have to pay any of the cost for including a particle system and likewise we want to break everything down into its highly modular components in the future we even hope to break this down even further so instead of having physics be a binary on or off thing we might give you the option to say well I want physics with some simple colliders only but if I want to add support for 2d chains or something like that that would then be another optional module with its own costs and its own features and then finally we also do a lot of work to optimize for delivery building the small runtime is really not enough because the code is only a tiny fraction of the final delivered content the assets actually take up the biggest chunk when we talk about some of these use cases that we're looking at right now such as playable ads and messenger games the assets take up a bulk of the download size 80% or more and what we can do there is we can apply a lot of the best practices because we're still using you know D asset pipeline through the unity editor to do a lot of compression and transformations that would be either expensive or just difficult to do on your own because all the assets flow through the unity editor and then into the small runtime we can then use things that have those two things work together to for example split out alpha channels and compress them separately we use alpha masks between different sprites all these things that again it is possible to do on your own but these are not the things that you want to be focused on doing you want to be focused on the actual content that that you're delivering so when you put all these things together you end up with unity for all things small when we talk about small things already mentioned two of our current target use cases soap label ads is a big one but also games and messenger type apps there's been a lot of announces this week about certain platform opening up and we know that a lot of you are probably interested in figuring out how can you actually use high quality engine high quality editor experience to actually deliver content to those apps these are kind of the use cases that we had in mind but these aren't the only use cases there are a lot of other places we're having a small run time is important so for example the automotive industry might be interested in having a small run time for dashboards and things like that so we're really looking for these capabilities to go very broad into a wide range of use cases and industries the components of this unity for small things there's a lightweight ECS core this is actually implemented natively for web deployment we go to web assembly and azzam j/s and this is promoted what provides the core optimized memory management and ECS functionality we take that easiest core and then we provide you with a set of modules this is what I mentioned before we really want to have a fine-grained separation of the various capabilities when you turn these things on and off this is by the way not the final feature set by any means this is a snapshot of our current editor UI considerate programmer UI for now but when you turn these things on and off the actual capabilities then just don't become available when you're building your content if you turn physics off you can't actually go and add a Collider because otherwise you can accidentally add some component and all of a sudden pull in something very expensive without really knowing about it but at the same time if you've built your content with for example physics you've got a bunch of colliders and things all over the place and you turn off physics we don't lose that data something the other just pops up and says hey this thing needs physics so you can even experiment with turning off different features like what does my game look like if I just turn off particle without actually going back and changing the data or Daschle content each of these modules again is tied into the ACS system so each module provides a set of components these components can be defined either in c-sharp which is compatible with big unity ECS that you might have heard about in previous talks here or it can be defined or they can be defined directly in the editor through a UI that is created just for creating components adding fields to them along with components these modules provide systems these are the things that actually operate on the data and those components some of these systems are provided by the runtime itself and but the bulk of them are probably going to be provided by you because this is really going to implement your own game logic and then finally we provide the editor experience where you can assemble entities from all of these things in the same way that you're accustomed to today with unity so a similar view you have your components on the side but in this case they're just data and you're manipulating things in the scene view just as you would today so this is a short video of what the editor experience looks like today a colleague of ours on the editor team built flappy bird from scratch and recorded it so the original video is about an hour and just over an hour long and this was shrunk down into about a minute and a half and so you can see it's a very familiar experience but with some added pieces to really interact with this ECS system one thing you might notice here is that the preview as soon as whenever he hits play next it'll actually open up a browser window so you can preview directly in the browser we also have a nice capability where there is a live link to that browser connection so if you open up that same URL on a variety of mobile phones you actually get all those refresh every single time you hit play so you have the ability then to connect iPhone your Android phone maybe a tablet for a different scale factor and maybe your PC browser make some changes in the game head play and they will all reload and refresh simultaneously so you can go and see what your changes actually did I think he's just about to start playing up and up he's doing doing pipe spawning I think this is a much harder game when it's sped up like that so to give you kind of some more concrete examples so this is an ad let's turn off the low quality filter on this this is an ad for a game called fast lane the original ad for this ran on the unity ad network built with another html5 technology and it was about 1.5 megabytes in size engine plus runtime assets we had a third-party studio student by name of working man built this out using an alpha preview of this version of unity for these small things and within about 2 weeks they had from not really knowing about the project at all they had something that was playable and looking pretty similar to what you see today this end result is less than 800 kilobytes in size compared to 1.5 megabytes of the original some of that is the runtime a good chunk of that is the advanced asset optimization that we can do because we have the editor pieces in place okay so let's dive into a little bit more of the underlying technology so I've mentioned this easiest thing some of you that were here in the talks before we might have a good understanding of it but ECS is an architecture for separating out your game logic from your game data it's based around the concept of entities and an entity is just an index it is just a number is a convenient way to refer to a particular set of components components are data they are value types structs in c-sharp for example you might have a component that is a health component you would put this on an entity that has health it would you know might have a value that is its current health and its maximum health there might be a component that is a position you would have your XYZ position values may be of a component that is a powerup component where which participates in your game logic where it has the power of type and may be the strength of that powerup and you can build up these components on entities to really define what they do without really considering too much about what the interactions the components are but are really focusing on the individual pieces and how they interact with the systems and the systems are the things that actually make the change systems operate on sets of components and transform data some set of components goes in and the system then modifies the data and either those same components or in other components that are related to it let's look at some more oh sorry so for pure ECS like I mentioned with unity you have access to a bunch of classic kind of unity mana behaviors and such in a pure ECS world all data lives in components there is nothing and objects there's nothing in Global's or anything like that some of these components are have u8 so for example you might have a component that as part of its data contains a bunch of texture data but most components are fairly lightweight there'll be a couple of floating point values in size position health may be an integer that says what faction or teams the particular entity or enemy is on all code lives in a system again these systems take data and transform data that lives in these components some of these systems are heavyweight for example some of the ones that are provided by the runtime will do things like load assets off of disk or off the network they will interact with rendering of native platform but most are lightweight especially the ones that are related to game logic are lightweight they're gonna be doing some math they're gonna be figuring out well when you know this particular bullet or this thing that can do damage touches something that has a health I'm gonna subtract that damage from itself and this really lets us get to both scale because most of these are kind of well understood chunks of code or well optimizable chunks of code I should say but it can also do advanced things like parallelism and really kind of get as much performance as we can even out of these kind of small devices the other thing that comes from a pure ECS system is that the game loop is now defined entirely by systems so you end up with a simple and easy to understand an observable game loop for every frame in this example game loop there's a system that will handle acid loading we'll see are there any assets that still need to be loaded and if so when I go through and load those system that will deal with player input did the user press a button or move excuse me repressor an arrow key and if so move the position of that particular entity shooting system was the button pressed do I need to spawn a bullet and so on but that also includes systems that come from the runtime so for example things that have animation components on them will be manipulated by an animation system or perhaps a set of animation systems that all interact to actually do animation particle systems will have maybe some systems and manage the emission of the particles some systems and manage the actual individual features like changing the Alpha of a particle or moving a particle around and then rendering which actually take all the things in the scene that can be rendered and will actually put them on the screen the nice thing about this is that there's like I mentioned there's no magic here you can observe this entire set of things happening and because for each of these things the data always comes from and goes back out to components if you don't like the way that we do something you can replace it if you want to do particles a different way because you have some particular knowledge about your game that you can do some optimization or maybe you want to spawn particles in a different way you can do that you can turn off our particle system write your own you know the types of components that that particle system is going to work with so you can just take that same data do whatever manipulation you like and as long as the end result is something that the rendering system understands as long as you feed things back into the normal kind of sprite rendering then you'll get things on the screen so it gives you a really nice way of understanding exactly what is going on in your game and your content and can also help with debugging like if you think particles are causing a problem just turn off the particle system everything else will still continue to run if you're having issues with bullets colliding turn off the bullet collision or decline checking system and just see what happens see you know try to track down where the bug is or the performance drop or something but just having kind of a very nice way to see exactly what is going on in your content per frame so let's look at some more examples of this pure ECS concept so like I mentioned some things are heavyweight because everything lives in components that are on our entity there's no such thing as a resource there's no texture 2d there's no this kind of magic object that lives off that provides us kind of heavy data instead all of that lives on particular components that you can attach to really any entity you wish but it it can be helpful to treat some of those entities as resource entities because that's where you can have some of these heavyweight things like textures and image data and you can share them amongst anything that needs to render a texture by just referring back to it so for example I might have a resource entity number one that just has a texture on it this is just a container for texture data later on I can create a hundred entities that have a sprite renderer that will then reference that entity in order to actually draw something to the screen but because these are still full entities with any number of components on them you can start building more things up so for example you can build a second resource entity that has both a texture 2d or sprite on it that's an audio clip it maybe has a Collider shape on it and this you can then be your bullet prototype basically whenever you need to spawn a bullet you can just clone this set its position and now you have a bullet in the scene so you can start to build up things like prefabs from a number of these kind of features but everything still lives in this ECS world which lets you do some nice powerful things so for example during runtime if you want to see if you want to have a system look at every single loaded texture that is trivial to do and you do it in the exact same way but you would iterate over anything else in your world if you want to look at every single audio clip that is playing at any point in time again you can do that because it's all within the same system you're not trying to get something from an audio manager somewhere and get some lists or anything like that if you can combine those things like if you want to get a set of every audio clip that's playing that also it's something that can do damage again those are all handled through the exact same framework so it gives you a lot of flexibility to both build up complex interactions but also to debug things in your content one of the common issues that comes up when we talk about pure ECS is that trying to figure out how to do things that are event-driven in nature becomes a challenge and this is something that we're still figuring out a lot of this is us still experimenting and figuring out some of the best practices in this architecture so this is kind of an example of a of how you and will you might build a drag and drop system when you have these components you have the option of treating some of them just like tags to not actually have any data associated with them but instead use them to tag other entities based on what happens to be happening right now so if you wanted to make something on the screen draggable you would tag it with draggable and you would attach a drag rectangle to it to indicate where the actual drag source is this would then be read by a drag start system along with input and it would do the checks to say hey did the user touch within that drag rect and if so then that system would attach this dragging tag to that entity now in your game code you can then look at you know are any of my power-ups being dragged right now and if so you can then do things to drag power-ups maybe you want to spawn a particle system at that point to give it you know some nice sparkles or something or behind it the drag move system would then look at is anything being dragged and then the position of the touch changed as the last frame if it did it would update the position of that thing and then your other systems if you set up that particle system it would follow along with it because it's all on the same entity there and then finally the dragon system would look at you know was touch released and if so was that over something that has a drop target tag on it and if it was then maybe all of the dragging and dropped excuse me all the dragging all those tags go away but instead you get a dropped tag on the thing so that then you could handle and yet another system things that were dropped so I showed that that simple kind of game loop here but you can see that the individual systems really tend to do fairly self-contained things and that's really the idea so you can easily consider a game loop that's running dozens of systems at a time and that's okay because that then lets us do the work of paralyzing and performance optimization amongst all the different pieces veteran flight and then finally kind of to put it all together let's look at bullets again so you might have an entity that you're treating as a resource that is your bullet it only has a sprite on earth it's got the audio clip I should probably also have the Collider on it actually no sorry no collider on there you've got another entity that is your bullet prototype this is the thing you're going to clone every single time you make a bullet so it's going to transform for the position it's going to have a renderer which is going to refer back to the resource it's gonna have an audio source because you want to play that audio clip and then it will have things that are related to the bullet that'll have some components for velocity some components for damage maybe a tag component that just says hey this is a boy and then maybe it'll also well should also have a Collider so that it participates in physics and in collision and then with that there's now a number of systems that will interact with all of this to actually get the effect of being able to shoot and have the bullet hit things so to start things off you'll have a shooting system this is a thing that will check for input and if there was input it's going to cloned that bullet prototype and just kind of let it go in the world you'll have a collision system that collision system doesn't need to care about bullets at all all it cares about is it looks at all the things that can collide and it checks is there a collision amongst any of these things they can collide doesn't matter if it's a bullet or if it's a wall or if it's the player it just looks for things that can collide you have a damaged system this damaged system is going to look at collisions and then for things that do damage it's gonna look for collisions between things that do damage and have life so if there is something that does damage and it collided with something that does life you would apply that damage again none of this damage or any of these really care about that it's a bullet at all other than the initial system that kind of that set that up and this lets you build up really powerful interactions in your games do you want to have a platform that does damage to the player when they jump on it you attach a damaged component to it and as long as it's something that the player can collide with as it would then the same set of systems for collision and damage would then apply damage without you needing to do any kind of special logic to say hey this is now this magic platform it is just a thing that happens to do damage and participates and everything else and then you've got a number of other systems that'll do things like clean up when things are out of bounds audio for playing the audio and then finally rendering for getting everything to the screen so let's talk about a writing code for a bit because I've talked about the data portions on the component side and I've talked about the system side which is this new way excuse me this new approach to writing code that interacts with these components the first thing that you do obviously is you're going to design the components and I showed an example earlier of being able to write components in c-sharp you can also design them directly in the editor and this is actually a live connection between the components in the inspector and the components that you're editing so unlike what happens in unity today when you go an editor c-sharp file things have to recompile and then you're going to see things in the editor here if you add a new field to this destructible component it appears instantly in everything that has a destructible component in the editor it makes it possible to really quickly iterate on behavior as an experiment with getting the exact right design when you're trying to figure out what data to apply to your game currently for unity for small things because we are targeting playable ads and we're targeting these messenger games use cases all those are on the web and on the web the default language is JavaScript in order to get to these very small sizes we use JavaScript as our current language for writing systems code but this is not a JavaScript game engine like I said the engine is native code that has applicability even outside of the web environment but in order to get the really tiny size for web deployment we currently use javascript for the system's language let JavaScript though you're not interacting with the whole bunch of web api's you're instead still interacting with that core ECS system so you're still manipulating components creating and destroying entities setting and and getting data so you're still doing things in a very kind of ECS way even though it is running in JavaScript in the future though we plan to introduce the ability to use high performance c-sharp which is this dialect of c-sharp that I believe andreas introduced at earlier today that is really optimized for writing this type of systems code very highly data-driven and also very highly optimizable the burst compiler technology that we're developing along with getting us the massive performance wins because it goes straight to native it can also let us go straight to web assembly and straight to as MJS so in the future you'll be able to take the exact same systems code that you might use on a large unity project and reuse some of that code in a small unity project without any changes using the exact same c-sharp code so our goal is to let you define components and systems in c-sharp and then really to choose what your deployment model is do you want all the features of unity do you want to make massive triple-a titles or even you know the next awesome mobile game you can use big unity get all the features there are you looking for something that has a more optimized feature set for actually going small like if you need to deliver content and less than a megabyte if you download times to be ordered measured in seconds instead of in minutes then you would choose a small runtime but the way that you develop that content and the code that you write should be the same and we want to enable you to share assets the data and code regardless of what you choose for deployment to really give you that ability to scale regardless of what type of content you are developing all right so let's talk about deploying content for a bit initially again for playable ads and messenger games we are targeting the web as our deployment model so currently when you build one of these projects you get the core engine runtime and your content all packaged together ready to be deployed either as an ad or potentially in you know some kind of web container for a full game that's our initial target that's how we're using to prove out a lot of this technology and kind of figure out what the missing pieces are as we go beyond but because the runtime is native it enables a lot of deployment flexibility so the same runtime can be built for the web like we just talked about you can also build it natively for Android and iOS you can build it for other platforms desktops embedded systems or wherever you may be but the content that runs on there is exactly the same the content is portable between the different different runtimes and we go even one step beyond this the runtime can even be embedded inside other native apps or even inside other web apps so you might have the ability to take this small unity runtime embedded in a native Android app and be able to dynamically push content to it again the same content that you were running before whether it was all packaged together deployment or natively push this to an embedded runtime running within a totally different app in order to deliver dynamic content to your users and that even beyond that the content itself can neither be static it can be bundled with the run tera bundle with your app or it can be streamed I give the separation between the data and the very clean-cut code and in the system's lets us actually stream additional systems and additional content we're targeting JavaScript initially so we can then leverage the JavaScript runtimes that are already present on all of our mobile devices in order to get new code running in a web-like environment but still targeting this native code underneath so all of this actually gets us to some pretty interesting deployment flexibility I picked up a SmartWatch last week and last Friday I wanted to see how this would look running on a fairly constrained environment this is actually running within a webview on this watch this is not actually running natively but with no changes the performance is actually decent it's maybe not something you'd want to ship and that's why it's only kind of a short shaky clip here but at the same time if this was actually the runtime running natively the exact same content would then just run faster because all of those pieces would then be native already so where are we at with all of this we announced this project first at our keynote on Monday we've been developing this for about eight to nine months now and our current focus is these playable ads and messenger games use cases we're currently figuring out what is the feature set that we actually need in order to deliver a compelling product for messenger games and we're in closed tests with a few teams I mentioned some of the teams that built for example that fast lane ad earlier and we're really doing this to prove out to all the technology pieces we want to prove out the small runtime we want to prove out our rendering animation all those modules that that were splitting out but we also want to prove out the CS approach to make sure that we can build things like for example drag and drop in a way that makes sense and that is also both understandable and scalable we're looking to do broader availability of this this year so towards the end of this year for these initial focus areas so again for playable ads and for messenger games delivered in a web content that'll be sometime this year the other use cases will be sometime beyond but we have a lot of interesting opportunities on our roadmap DeWine so that in a nutshell and I realized I was probably speaking a little bit too fast I apologize for that that in a nutshell is unity for small things we've got a bunch of time for questions here I'm actually going to bring up a TN here who is my counterpart on the editor side of things he's the lead for the editor portion of unity for small things good job questions hi yeah there's a couple challenges that arise from using ECS I was wondering how you're tackling them so one of the things is on web you've got to retrieve some stuff from the from the browser like your window dimensions or handle inputs which is well this event space so I was wondering how do you tackle that do you have systems I set up for that and the second question is what does the application routes look like and do you have different stages for bigger state changes and those kind of things enabling this or disabling systems that's right okay so the first question was how does ecs deal with interacting with the browser's environment how do you handle getting input getting loading images and things like that and like I mentioned some of these systems are provided by the runtime and they're what I refer to as heavyweight like they'll actually go and interact with the platform so for example for getting the current window size there is a system that is running on the HTML platform only that will read the current width the height of the window and it'll put it into a component that the game can then access in later systems input and things are handled in a similar way for the second question I believe it was how do you handle state changes for longer running content can you disable enable systems and so on you want to take that one talk about the scene sure sure so basically this is a new data format for us so it's something that the editor doesn't support natively yet and we're working on integrating it so you can think of entity tables as prefab system essentially so we have this application flow module that lives within that system that can schedule load and unload scenes and prefabs so you can basically just create your state machine transition from level to level using the same system the same core framework that you're kind of used to in unity but can also leverage with unity for small things because this is a modular system are you doing a full rewrite of the rendering engine we're optimizing a lot of the pieces for small and so to do that we're trying to use as much as possible the workflows that unity already provides because a lot of the tooling is really in the editor the actual runtime rendering portion is relatively small so for some of those things we're rewriting them for some of those things we're collaborating with the other unity teams to make sure that their code can actually run on this other platform and does it support 3d 3 is not on our in our plans initially for the messenger game stuff but obviously it's something that will we plan on doing yeah kind of related to that like is accuracy pure ECS seems really useful is the plan to kind of start with this tiny unity thing and then expand it like is this how we're gonna be writing unity games in 5 years or 10 years or whatever like well you'll be writing unity games using ECS I mean of the the focus of most of the talks today was really about introducing this ECS data-driven architecture so right now these are separate streams because we have a particular use case all these small things here that is slightly different from the use cases that VCS work going on in unity itself is where they're really focusing on high performance but the plan with things like burst and actually getting back to c-sharp code is that these two things would unify in the really not too distant future we need to do some additional technology development in order to get there but this is definitely our plan we want there to be one way to write and design content and then be able to choose do you want to go small or do you want to go big some things no more okay cool well thank you very much thank you for coming [Applause] [Music]

Channel: Unity

Views: 49,274

Keywords: Unity3d, Unity, Unity Technologies, Games, Game Development, Game Dev, Game Engine, ECS, Entity Component System

Id: EWVU6cFdmr0

Length: 38min 48sec (2328 seconds)

Published: Fri Mar 30 2018

Reddit Comments

[u/davenirline]

Is the whole ECS editor thing gonna be ready on Unity 2018's release? I've tried to code pure ECS in the beta. It's so hard if you can't inspect entities in the editor. You're like imagining things while coding and hope that it will be correct.

[u/Soraphis]

i hope they don't release the ECS without C# support system in the systems. we don't want to get the unityscript <> javascript debate on again.

the point about reusable systems he made (damage, health, collider - components) is clearly wrong. i NEED to know what kind of entity it was, or at least something i can invoke: a bullet will get destroyed on the collision, an arrow might spawn a visual shaft object, an damaging platform will stay there.
so these are 3 systems or 1 monolythic system (or a listener structure, calling methods that are defined elsewhere, which is exactly the problem you encounter in an ECS).