Unity at GDC - Evolving Unity

[Music] wait okay now from the beginning so I'm gonna talk to you today about evolving unity in the in the core team of unity we're working on basically rebuilding the foundation rebuilding the foundation of off of everything that unit is based on and today we're going to give a lot of talks about how to do how to write high-performance code how to write high-performance simulation code they trying to design these kind of things and I want to talk a little bit about the principles and goals for what we're trying to achieve so that you have a better context for what it is for trying to do so I'm gonna start with a couple of concepts so first concept we have we call performance by default so performance by default the first question is what what do we mean by performance so when we when we say performance I mean if I take if I asked Mike Acton to write some highly optimized code for a specific target platform he knows exactly which hardware he's targeting he's laying out his data optimally and he uses the the the most optimal instructions for the hardware that is what we define as performance and our goal with performance by default is to make it so that by default when you write unity code you will get a close approximation to somewhere that so today you are putting your code into a mono behavior that's what we described on the documentation and we would like to be in a place where the default for writing code in unity becomes something where your data is not laid out perfectly simile code is used and everything is multi-threaded so let's go through these these things so the first one if you want to have great performance you need to have great memory layout and game objects and components are organized pretty much randomly in memory in the anti component system on the other hand we layout the data in a way so that when you're writing your code and you are you have a system that updates some positions or does any kind of game logic we can make a hard guarantee about that the memory that you're accessing is linearly laid out one after the other and that's really a super important concept to get great performance once we have really good memory layout we can do a lot of good things the second concept is multi-threading so the Moore's Law is basically dead the CPU clock speeds haven't been increasing for a while and what is happening is that more and more cores are being added to your to your computers and so I think if you want to stay competitive with making really really high-end games and putting a lot of interesting things into your game then you need to take take advantage of multi-core multi-core hardware so at unity we're trying to enable that and so for that reason we in 18.1 we shipped the C shop job system and the c-sharp job system makes it very easy to do that's what it's all about making it really easy because the concept is performance by default we can only make something by default if it's easy enough right because otherwise you will probably not end up doing it because we want things to be easy the next part of performance is is the burst compiler so unity today you're writing your code in c-sharp and then you're either compiling it with il-2 cpp or with mono and what the burst compiler is all about is that it is a specialized compiler that is made specifically for c-sharp jobs so in c-sharp jobs there's a lot of rules about how you have to write code as an example there is no garbage-collected memory in a c-sharp job all the memory is its buffers that are allocated from sort of like a a c++ a locator and so there's a lot of rules we can establish about a c-sharp job and the burst compiler is a specialized compiler that takes advantage of that it's a math aware compiler so it can do a lot of optimizations that you can't otherwise do and so we're getting some very very big speed ups from that on the order of 5 to 20 X speed ups over c-sharp code and were also faster than C++ code with again very simple code because at the end of the day it's not simple then we can't make it a default so let's take an example of that so when we when we're building the entity component system in unity we we have a certain approach to that and our approach is that we always measure against ourselves against a theoretical limit of what you can achieve and then we try as hard as we can to be within a within a very close margin fifteen to twenty percent of what is theoretically possible so instantiation is a is a very common performance problem in game engines I'm sure you have at some point in your lives if you cared about performance probably created a spawning pool and the reason you create a spawning pool is because instantiation is slow and there are some very specific numbers about how that's slow so we made a stress test and in a stress test we spawn a lot of entities this is like really a lot of things to spawn one frame you probably wouldn't do that but acts as a good stress test so we have a hundred thousand entities three hundred twenty bytes over five components so when we measure ourselves we measure ourselves against what is optimal so what is optimal is simply copying memory right like there is a mem copy and that is always the fastest thing you can do because it literally doesn't do anything but moving some memory around so gameobjects takes seven thousand milliseconds so that's currently an 800 X Factor compared to instantiation and in fact this is why you create spawning pools and I would also say nobody gets up in the morning to make spawning pools we want to make games right so when we are when we're optimizing instantiation and we're making it fast then we're basically making it so that you have one less problem to worry about and this problem instantiation is in every engine because nobody really cares too much about it but we do so what we did so we made it nine milliseconds so we are within that 10 to 20 percent margin and that of course requires some changes on your end to take advantage of it but at the end of the day these kind of performance gains is something we can do and now you just don't have to worry about instantiating things so in the Nadia steamer that we showed that unites Austin for example this big battle simulation we just have we have like 10,000 arrows which is spawn them all in the same frame and we just you know which is instantiate and because why not so also another way to to look at this is when we're combining single threaded code multi threaded code and multi threaded code with first we're seeing on the order of 100 X speed ups and that's it is not that's not sort of like a crazy outlier when you combine all these pieces together they turn to design single thread it's multi threaded code and to burst compiler you will get these level of speed ups I mean that doesn't mean your game as a whole will run faster because maybe you're rendering bound and you know if you make a simulation code faster that will not help you much but if you have a simulation code from you can get these speed ups and there's one one more thing to point out about about performance so or particularly multi-threading multi-threading on mobile is actually very important because the best way to preserve Patrick battery consumption and and prevent the devices from heating up is to simply make your game run incredibly fast go wide on multiple cores make a game run 200 frames per second but then you just get your frame done in form in Formula Singh in ten milliseconds whatever and then you just wait for 20 so basically just getting your game look done get everything done and then it just let the Machine sleep and that is how you can preserve battery consumption that's how it can reduce heat on the device so multi-threading is actually exceptionally useful when you try to make mobile games that really scale and that run really well on phones another concept that I care a lot about this is a concept I think we've always been really good at in unity unity we think of as a sandbox and to me that means unity is simple and safe so I care a lot about this principle and it means you know like if you use a game object and you call getcomponent you don't just get like null reference exception you get a nice message telling you hey a a component is missing and the game object is named this and that and you probably could look at adding that component or maybe you check against now so it's like really always bringing our bringing bringing our users to sort of like a place where they have actual feedback that that they can act on so that you know when you make a mistake it's quick to fix it and you're not just wondering like what what's going on so this this principle applies to multi-threading because when you multi-threading is inherently hard it's a hard problem and so our principle is basically we need to make it simple and safe it needs to be a sandbox and that means it must be impossible to create race conditions because if you can create race conditions it's super easy to shoot yourself in the foot and have a mistake that stays in your game and you notice the day before shipping and then everyone cries and we don't want that we want to be happy while developing so why don't we just make it so that when you create a race condition accidentally somewhere in your code you get an error message right away as soon as you enter play mode that's what we have and these error messages I spent four days of my life on those like on the wording it's important like really getting that kind of thing exactly right so that you know like even if you are a junior programmer you have never done multi-threading before we can convey these principles by having this sandbox where it's safe and simple to write multi-threaded code and always keeping you on the right path another really important principle I think in unity we've been also doing relatively well on debt but I think we can get it really to the next level so one way of writing code what we have done in the past is making editor code and runtime code be pretty much the same and that's useful because you learn one thing you know how to create a game object add components if you write editor code which is to the same now you have you already know a lot of the API that you need in the editor so that's that's useful but what what if we could write engine code exactly the same way we write game code today we create a barrier between how we write code which is in C++ and how you guys write code which is in c-sharp what if we could write most of our engine code actually in c-sharp and there wouldn't really be a difference between engine code and game code what if you could just go into every piece of engine code and modify it what if all of it was what's available with the pro license with source code and you could just take each part and modify it I think that would be great and I think would create a much closer connection between the productions using unity and the engineers working on the under on the code another concept about one way of writing code is we want to scale all the way from tiny to high end so all the way from a we have a small runtime tip that we are developing using the entity component system and that can fit into 74 kilobytes of executable so this is super useful when you're making games that have to run in the browser messenger games [Music] games that are running in an ad those kind of formats are super important and there's there's more and more kinds of devices that want to support it so we want to really support that well and we want to also all the way support these super high performance workloads where you're just putting a lot of stuff into your game and we want to make that in a single way of writing code so you learn one one way of doing it and it actually scales that's a goal then there's this this other thing acid pipelines what to essa' pipe ends do they choose cash some some states like revenue FBX importer it produces essentially a scene and then that scat gets cached but what if we could cash anywhere and what if all the code we write could be written the same way because for example if I'm making a multiple game wouldn't it be nice if I could use the FBX importer at runtime that should be your choice right I mean most of the time that doesn't make sense you want nicely packed data that you can load at runtime in a super efficient way so having an FBX imported it doesn't really help us but yeah I use cases where you do want to load an FBX file at runtime because you want your your modding community to put those models into your game so that's super useful so writing code in a unified way I think will will help us with that and all of this we're building on this new new component system concept because it allows us to do all of these things in a really good way okay then we have the concept of iteration time so iteration time is super important nobody likes to wait and when when I have to wait for something to happen compiled times changing an FBX file it makes me angry and it's it's it's not a good feeling and I I want everyone to be happy when making games so we need to make sure that iteration time is amazing for everything and we have a very specific metric on that that we want to measure ourselves against and that's 500 milliseconds 500 milliseconds is a number where you don't feel like you're waiting you can see that if you if you open if you search something with Google you will see it will always give you a result back in less than 500 milliseconds and that's why it feels good so we want to have that principle inside unity so we have a we have a we have a prototype of a new C sharp compiler for example and this new C sharp compiler it's an incremental compiler and we have a 14 X speed-up on C sharp compilation time on it and we're going to keep working on that and we're gonna drive this number until we get to this and we have we have that for scripting but we want to do that for everything of course if you're making a game these days you want to see it on device you want to be able to change an FBX file and it shows up on device and we want to do that in 500 milliseconds that's the goal now I mean all of this talk is about it's about principles and goals like if you download the anti component system preview today it's not what you get this is our this is our ambitions and this is what we measure ourselves our success against so over the next couple years you will see these things really taking shape everything we develop in the anti component system has full test coverage when we develop unity in the beginning we didn't have test coverage and we developed things in a way that was let's say we made it not testable by default over time we added a lot of test coverage but with with with the new system every developer writes the test coverage as we write the code and we make it very easy and that's just how we roll and since we're writing most of this code in c-sharp it's also much better tools to do it and that is just how we roll in the engine because you know there's a lot of people relying on that stuff being rock-solid networking so I believe is that network games is probably the most important thing that that we can do to make you successful I think most games into the in the future will have some sort of networking component whether that's a synchronous or synchronous I think synchronous networking is paying a much more important part but the basics is we need to be great at networking just has to be true we want to be the absolute best game engine for writing Network code so we're also saying another thing we're saying we really want to invest in hosted games so we bought a company called multi play and they have a they have a service where you can scale servers so you can make your your server executable and they will take care of scaling it in the cloud and on bare metal hardware and they can help you reduce the cost of hosted games and it can help you scale with with with a player base that you maybe can't predict so that's what we're saying you know when we acquire a company it's a statement and the statement is we think hosted games is the right way to do it things it's more secure it provides a better experience for players and so on but for networking there's a couple listen there's a really important point here and that's usually in almost any game engine the way we approach networking I think is fundamentally flawed and the reason for it is because we always think like oh we just take like this one networking architecture and then we're going to fit every possible game that exists we're gonna try to fit that into it and the reality is if you look at this there is no it's clearly no one networking architecture that can support all games different games require different networking architectures a first-person shooter the simulation on the server sending state to the clients and events to the server a real-time strategy game does the whole simulation on each machine in lockstep with a deterministic simulation so they are just different and the way we are architecting unit is to really admit that that is true and then building around it making it sort of like three modular packages that you can plug into your game and we want to do that with a single way of writing code so we want to make it so that you can write RTS game if you write your game code you shouldn't have to think about networking we want networking by default in these three different ways of doing it and at the core of it sits determinism all all three networking architectures in one form or another require require great networking support sorry they require great determinism support if you're making a real-time strategy game you need to have determinism you can't do it any other way right like the two computers have to actually simulate the same thing if you're making a first-person shooter you probably won't replay I mean a lot of the really high-end first-person shooters these days they do these really cool had short moments and so on and for that you need determinism so we want to make sure that determinism is been built as a core principle into the engine so that you don't have to worry about it so how so what if I if I told you that you could write floating point math code and we could run it the same way on an iPhone and a Linux box and that is something that that that we can do that's what we're working on and I think it will enable a lot more types of games that require determinism then a super important concept that we have is as packages so today we ship unity as one big monolithic product and what we really want to do is we want to be better at collaborating with our users really closely so we have done in that when we worked on the entity component system for example we worked with a company called Nadia's and that was a really great collaboration because we could sit next to them and we could make a change to the engine we could see it hot reload in the editor and we could deliver changes really quickly and just work almost on the same code base while working actually on the engine and I think today that is difficult to do because of this if you have a monolithic engine today it takes us because our release cycle it takes us four months to get production feedback of course we can make a change and put it in an alpha but the reality is that there is no big production with like really like 20 people hammering on some code giving us real actual feedback on it in an alpha built because of course if you're in a production you want something stable so that means the time to actually get the real feedback is four months but what if all this all this engine code you could just get it in a package and you could just get the part you want like what if what if I'm just interested in in in the latest things for AI all the other code rendering I don't break it I just want to get the latest stuff in AI I can see what has changed exactly in that area and I just pull that and I can do that while the editor is running I think that would really fundamentally transform how we can work with our users and would make it much easier to collaborate so really the team working on a feature owns owns it and they can collaborate with customers directly so that within five minutes of me having done a change and of course I have to do the change first but I committed and you could try it out like if we can do that I think it will be pretty amazing so all of what we're doing is about evolving unity and the key part here is that it's super important that we bring everyone along on this on this journey and I think the fact is that this is a this is a new way of writing code and it has a lot of advantages and we're talking a lot about those but at the end of the day the only one who can convince yourself that who can convince you that this is actually a good idea it's yourself so that's why we're saying we want to make it so that within 30 minutes you can try out unity with the entity component system take an existing project with mono behaviors and switch out a single mono behavior to the entity component system and just get a feeling for how things work and if it makes sense for you and if you actually see some of these gains that we're talking about so that's the experience we want to achieve I I don't think we have that today that's what we're working towards but we're putting a lot of effort into making this really happen and in some of the like when you use it I think you can see some of the principles of that reflected in the code so really making it easy so that you can prove to yourself that this different way of writing code actually makes sense and that you can try it on one piece so that then you can decide okay cool maybe now I'll make a whole game like that that's the idea so we want you to convince yourself that this is a good idea all right so we have a public preview available you can go to this you can go to this link you can download it you can play with it this is a preview it's not it's not production ready but we'd like to invite everyone to give it a shot try it out see how it works for you there's a forum where we are really active supporting anyone who wants to try it out and yeah you can try it out have some fun and I'm sure some of you will want to ship a game on it that's that's okay we're not preventing you but we're also not committing to that this is production ready the code itself is relatively stable but I would say it's missing a lot of features that we would really want what it works for you then why not so that's a lot of talk and I want to show you a little bit of code so that you can understand what that means in a very very very simple example so so this is not a fancy demo this is the very simple example of here we have a I'm gonna skip that demo I'm gonna I'm gonna show you the code instead I've been I should have probably run the demo before instead of changing some code last night the code you write today looks like this so we're just doing this very simple thing we're just rotating a cube around itself that's all we're doing so we have a speed value where we define in an inspector you attach it to a game object with a component it's still the same concept you attach a component with a speed value then you have update method this is your behavior right your data is the speed your update method is the behavior you have a delta time that you take take a rotation you multiply it you rotate the thing around the up axis by that speed so it just rotates with the speed okay the simplest way to transform this type of code select this the key part to think about here is you want to separate the data from the behavior and that's exactly what this step is about so you're saying here's a Mona behavior so you can interact with existing Mona behaviors you don't have to work in all this new data aren't I design style beautiful memory layouts you can do simple stuff with existing with existing Mona behavior as rigid bodies transforms whatever you want to use so we just have two data that's it that's the component you can attach it you can change the values same thing the behavior moves into the component system and this component system is responsible for updating all of the rotation speed hybrid game objects so we're basically saying here okay I would like to iterate right here we're saying we're iterating over these two component types so iterating over something that has a transform and rotation speed so for this system to do anything you need to have both of those so it will just ignore entities that don't have both of those and then we simply iterate over each one we take the rotation multiply it same code as before take the angle axis and that's it simple code and the first thing that you can see here is that simple optimization opportunities simply show up just because of how your structure is code so for example in the first example if you have like 20 of these hundreds of these or many more every time you call update you fetch the Delta time but you know there's a cost to that here we know the delta time doesn't change between this loop so we can just move it out of the loop and that makes it really easy to get these kind of speed ups so just by looking at it in a little bit different way you can get you can get performance gains and that's really cool but now the memory is still laid out pretty much as mono behaviors were kind of like randomly you avoid virtual update call overhead fat I mean there is a cost to this function being called in mono behaviors and here everything is in one function so there's a good speed up just from this so sometimes if you get started this is a good way to start I mean you will get some speed up you'll not get the hundred ex we're talking about but you know like a maybe a 1 to 2x speed-up that's something and you're structuring your code in a way that is I think actually simpler to to work with when you have a lot of a lot of game code because the mana behavior structure can be a bit hard to reason about but the next step this is how the code looks if you're trying to write really the optimal code so first we're gonna use the job component system so the job component system what we're saying is we're just on the main thread really what we're doing is we're just scheduling jobs and we're scheduling these jobs with dependencies between each other so that they can run a synchronously to the main thread and we make we use this thing called the i job process component data so that's basically the same as this for loop except the for loop is done for you so you get this method execute we get the parameters you want to work with so we want to work with the rotation of this entity right we want to rotate it and we have an input value called the rotation speed right like we have these two components they are on the same entity based on that on a run this code and this this value we're only reading like we're not writing to it so we have two rotation value we multiply it with a quaternion we take the Delta time multiply it by the speed value rotate around it the literally the same code as as in the previous example so that's what a job looks like now important note the Delta time you can't just access that on a job because you know the job might run now or sometime in the future and Delta time might change between that so generally when you're adding when you write multi-threaded code you can't access global variables and time love Delta time you might not see that it's a global variable because it's just you know a property but internally there's a global variable somewhere global access to something and so you you can't do that what you can do so you can put the Delta time into the job and on the main threat you just get the book Delta time put it into the job and then you schedule it and then you're guaranteed that the stealth time is going to be no matter when it runs it will be that value and that's how you can make sure that well your code still runs deterministically even though it's Java fide so we create this job struct and then reaches schedule it and we fit in the dependencies that the system gives us so there's a very important point here so maybe the rotation speed is it's being written to by something else and maybe that happens in a job so we want to write modular code so the system that runs the job component system it takes care of off off generating the right dependencies for you so it knows if there's another system that is writing to rotation speed that the job dependency that should give you should have a dependency to those so you don't need to worry about it you just write the simple code using HR process component data and other patterns and job dependencies are taken care for you so that's super important that you don't have to take care of dependency management because that's actually quite quite hard to get right and then lastly we have this attribute here this attribute is how you enable burst so basically this is how you make your code fifteen times faster that's yeah that's actually really the the extent of this example it's a pretty simple transformation from this to something running on the main thread going over the entities following this idea that's iterate over everything that has this set of components let's think in sets of data to fully multi-threaded code going wide using bursts having great memory layout like actually maybe I'll show you like one thing what is this rotation speed actually so the rotation speed is a I component data so it's a struct and it's laid out linearly in memory the entity manager lays them out for you and so there's one float packed after another like that and that's a lot that's where a lot of the performance comes from so that's that's the overview for me so I think now we have time for questions [Applause] [Music] [Applause] so hey thanks great talk so how do you deal with if you have like causality in there in those dependencies so say I have one component dropped or a component drop that adjusts my position just by a velocity and then another one that snaps me to RTS map critter so which would then take okay I'm reading a position and when the position is beyond a certain value I'm snapping it back board off to map something like that but then you have two components that bows right into position but one component that reads position and writes position so how do you resolve those dependencies so the the basic the basic concept that we're trying to establish is that the behavior should be the same as if you execute it on the main third functionality it should work the same so basically the first thing that's important to note is the important part is actually how is the order on the main threat of these systems so if the system that writes to the one that snaps to the to the map right so if that comes first stupid example if that one comes first and then on the main threat it would do it first all the values have been changed cool then the second one runs and it reads that data and writes to another one that's fine so that's the behavior we want and in fact the safety system that we have makes a hard guarantee that when you schedule jobs and you work that way it will do exactly the same it is actually impossible without getting an error message in the editor it's impossible to not write that code so basically what will happen is that this these two systems the first one will schedule a job it will store that job handle in our internal system in the it's called the entity manager and the second system will repeat will receive an input dependency on that job that you scheduled in the previous system and so there's a dependency between them and a dependency means there's a hard guarantee that all when the first job is done the second job will run so now the thing is you know if you have too many dependencies then you get very little parallelism but the thing is you might have other systems that work on other sets of data in parallel to each other and on top of that these these jobs go wide right so the i job prescript process component data goes wide over many cores so because the two entities don't affect each other in this case in this different cases sometimes you can't go wide that's okay then you just have a job that goes on a single core while other systems can put their jobs in but you express everything as dependencies and then all of these things you can do make sort of things how does this look in the editor inspector if before how does this look in the editor inspector if before I had a hundred game objects each with the rotator component and I'm trying to move over to the system what does it look like in the inspector so the idea is we change nothing I mean I think the concept of game objects components and you adding components removing components that's absolutely there right now you can put an AI component data onto a game object there's a little bit of an awkward setup because you have to also create this wrapper component for like you basically create a wrapper monobehaviour component that holds the data and then create something into the entity manager and that's just today that's because all of this code is actually written in c-sharp and we haven't done full engine integration but we will get rid of that so that it's really like everything that you create as a game object is also visible to the entity world automatically without any work at all that's where I want to be but the constant the basic concept of entities or game objects that's the same same concept and components on it that really stays the same we don't want to change it but in our mind that works really well so the basic concept of this unity the Whale unity doing the optimization is that you starting to take advantage of the like as I am the approach so I was also wondering because at East and West SMD optimization myself before it's scale where and like PC play for my PC but how is this kind of optimization in terms of a mobile platform right so I gotta make it on mobile there is there's neon which is semi architecture it's for white so you can get very big performance gains by taking advantage of that that's really the same and the the burst compiler helps you do that and makes it easy and alignment playful right so the question was the question was do I have to take care of aligning my memory to stay with with integrity for party my suite rights yes exactly and the answer is no the entity component systems purpose is to take care of those kind of details for you there's actually later today andreas Frederickson is giving a talk specifically about burst and we're actually going to show assembly for a generated code and really dig into sort of like the details of how this generated code looks like because it's really it's quite quite amazing what we can do with this compiler okay thanks a the version of c-sharp that unity has doesn't allow you to hold refs as locals or have them as a return value is it is this system gonna be primetime ready without that yeah so that that's a really great question so ref support in c-sharp six is you know not having it when you do something like this sucks so we have a we have this new incremental compiler which supports c-sharp 7 and we have that available in a package we have prototypes of the entity component system using it and that's definitely the D direction I mean the whole the whole concept here for this for this whole entity component system this is the very beginning of that journey so we will pretty soon make it so that it requires C shop 7 because it allows for for this whole thing to work a lot better if we can rely on reference for sure are the number of threads based on the number of jobs that are scheduled or is there like a limit based on the number of cores and is the thread prioritization from the OS or from like unity or CLR right so the way so we're using our our job scheduler that we wrote for C++ several years ago right so for our C++ code we've been using a job scheduler for way for a while and the way it works is that it looks at how many worker threads there are on that sorry how many how many cores how many logical cores there on the machine we reserved one for the main thread and then the remaining ones we allocate to be work of that and then both C++ code and the c-sharp job system allocates into doors and sometimes different platforms make different choices about how to allocate the worker threads optimally but basically which is scheduled as jobs and then whoever picks it up first on the worker threats will will get to do the work so with this new injection stuff that's going on will there be a way to like inject values like specifically from like a scriptable object you like if we were to do tuning stuff values for the job scheduling instead of having it hard-coded could we have like a editor setup where we can profile and just see what happens if we change the number of number of batch sizes for stuff like the process component data up there um right so the question is are we going to take this I guess the question is really are we going to take this injection approach a lot further yeah wider because I was looking at the samples and I didn't see any way to inject anything other than stuff like the components themselves into groups but I haven't looked at all the samples yet right what I would like to do is I would like to make the injection code more flexible so it can be extended so something more like Jenn's injector no strange well I don't think I don't think we would make something like Sen jacked just because my personal opinion is that it goes a bit too far and it's too much and too complicated but what I would like to allow is to have a single attribute in unity where other people can plug in so if something like like sends it like if somebody wants to do Sen check you can pluck yourself in and do those things but I think the like at least what took the way we have been writing game code there's a couple of really important use cases like injecting other systems into yourself injecting component groups and they work really well we just want to make it pluggable because because I think that's that has real value but I don't think we would go as far so like a real big injection API ok thank you very much and another nerdy question so let's take that example with like a rotation speed and and say okay we have a we have another thing that influences the rotation rotations to raster or something something that results from game mechanics like pressing a button or a buffer system or whatever kind of complexity you can make up so at some point I have to declare okay component scanner for rotational speed and rotations raster and blah blah at this point do I also have to tell them that the system that those two are probably appearing as shop inputs together I mean because if you want to reduce cache misses then you probably want to lay out those together or do I always have to hold do you have a component dump of the game objects in one big array right so that the entity component system takes care of the memory layout for you and it groups entities and chunks based on how they are similar to each other in terms of memory layout so by doing that we can actually make this hard guarantee about linear linear memory layout so when you're the inner loop for this thing this is executed inside some outer loop which you don't see but this outer loop literally is a loop that increments a pointer by the fixed size of that component size that's the inner loop and so the like you know if you had like a piece of code where you just had one float and another float and you would copy them you would get mem copy speed for it because it would artifact rise across the entities that did I answer something else or did that no thanks hi for example is there any way to use multi-threaded operations in the editor mode yes the job can I execute for example for some tool that generates for example terrain can I use jobs to make it faster absolutely so the C sharp job system so that there's an entity component system which you could also use that editor time but the C sharp job system those are two separate systems like I mean clearly they're really made to work closely together but the job system is a low-level system you can use to just schedule a job and do work there's rules about it like you have to use native array hash tag native hash map all these new container types that we're providing but you can do everything like I mean particularly your example of generating a terrain I mean it's a great use case for using both bursts and for using a sous chef job system to go wide I mean it's it's it's made for that would this also be available for our editor scripting their entity component system yeah I mean that is really the principle of one way of writing code for sure we want to make it really easy to to have data transformations that you do in the editor I think that's super important to make that nice okay great well thank you so much [Applause] [Music]

Channel: Unity

Views: 24,150

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

Id: aFFLEiDr3T0

Length: 57min 42sec (3462 seconds)

Published: Fri Mar 30 2018