Entity Component Systems and You: They're Not Just For Game Developers (SAConf NY 2019)

hi everyone welcome so what we expected three microphones we only have two so please excuse as Mars and I awkwardly hand microphones between each other for this tour we didn't expect to have to do that so apologies in advance welcome to entity component systems and you not just for games anymore so if anyone gets the reference - they're not just for games anymore please come and see is at the end we'd like to be your friend it's slightly obscure there is no prize there is no prize well friendship yeah it's true hello everyone my name is Paris this is Tim this is Mars Mars is a proper serious software developer a research assistant and an upcoming author on an O'Reilly book on AI for Swift she's a real serious business person who does serious software for serious causes and serious reasons Tim and I are game developers we spend most of our time doing video games tools video games video game techniques video game teaching and other frivolous so things for those things but we are we kind of know what we're doing in the video game world Mars very much knows what she's doing in the serious actual software world we're from a tiny relatively unknown island at the bottom of Australia called Tasmania so that may explain to you why we might seem like we have stray Jack said sometimes my mate we really apologize in advance there's a lot of Tasmania's that O'Reilly conferences these days I skipped we do lots and lots of things ranging from video games to conferences like this to books to tools video games all sorts of stuff and we feel like we kind of straddle a whole bunch of disciplines so we like to make our talks interdisciplinary when we can we build software ranging from stuff for other people to stuff for giant companies to stuff for ourselves to video games for enormous platforms like the PlayStation 4 and tiny little things that nobody ever sees so we really touch a lot of different things this is just kind of a sampling of the random stuff that we find ourself doing Tim and I've written started like 20 or aly books and Maz is working on her first one we do all sorts of stuff so so what we're here to talk about today is ECS or more technically in this case the entity component system framework or paradigm we're just going to call ECS for the rest of us sorry if ECS is already something else in your head maybe elastic you know etc sorry about that it's just we're not gonna waste all them syllables so what we're going to talk about today is we're gonna talk a little bit about what ECS is how gains have been using it in our currently using it and hopefully how you might want to think about using it now nothing that we're going to present here is particularly new a lot of these principles exist across various different sort of architectures and sort of frameworks we're not here to reinvent the wheel you may know some of this stuff under different terminology our main goal is we hope you kind of leave this going that you know small slice is a neat idea maybe I should consider sort of that all the exact opposite in that you you know want to come be like you're completely wrong you idiot you know nothing about software architecture we'd also be very happy with that because at least then you're thinking and discussing it as it is claimer if you google ECS you probably aren't going to get entity component systems at the moment or if you do it'll be about the Unity game engine we're hoping to change that beginning with this talk but it is typically associated with games it's also a very overloaded acronym so we do want to reinforce that this is not really a games talk we are games people and software people and we're kind of talking about both things but because this is a games centric architecture that has kind of come out of games and the way we see it is it has come out of games we will be using games for almost all their examples we're really sorry about that if we could think of a better way of doing it we would but we're not that clever so not really games talk but most if not all of our examples are going to be game based just a heads up so before we get started I'm just curious is anyone here touched ECS already like one per head so you can leave because you know our lies are lies but are anyone actually making games so it's one of your prize that's real that is really good so we weren't expecting this talk to get accepted at the very serious software architecture conference because we didn't really think anyone be interested but we really gratified you here we assume most of you judging from the steely stares at me are working very serious business software and have no time for video games so if you'd like to know what a video game is we can tell you that later they can google it that one is got one is google but not we just yeah I'm curious to see if anyone is in games it's it's interesting to see the cross-section of people here so don't judge us for a quick roadmap of what we're gonna look at we're gonna begin with a pretty high-level look at what ACS is and then going into a history lesson and the the motivators that made it come about we're going to talk about some suggested implementation details not perfect and not the only way and we're gonna talk about some of the more technical things that ECS could be good for not good for a non game software and then we're gonna summarize and give a bunch of resources so let's get started with a bit of a look through what ECS actually is I just want to point out feel free to tweet at us during the presentation our twitter handles are on the corner down there and because there's three of us that means we can reply the are talking in theory sometimes people take us up on that offer so feel free to so as the brighter sparks amongst you might have figured out ECS is entity component systems and to figure out what that actually means in practice we need to look at a short answer and a long answer and because you know I'm lazy I will start with the short answer the short answer is that eecs is a paradigm or an architecture this is the software architecture conference not the software paradigm conference but it's kind of an architecture and a paradigm in one for writing and organizing code it really likes a strict separation between data and logic so if you're familiar with very strict sensible textbook object-oriented programming terminology it has a lack of encapsulation it emphasizes the prominent role of composition in modeling data sorry that's the short answer the long answer is that ezs is an architecture that video games absolutely love video games simulations things like that it encourages a really strict separation between the data and the logic so it kind of makes sense the way video games work and we'll cover that as we explain how this works are you compose objects to model data rather than through inheritance or polymorphism or other ORP features now it might sound like we kind of bashing our pee throughout this talk and we're not really because we know our appease is like a textbook definition isn't really a thing but it's an easy way to sort of frame how easy s is different okay so realistically why he does ECS exists as with all frameworks it's because it tries and solves some sort of problem it sort of came about games are weird games from a programming perspective not from like an entertainment value perspective actually only care about two things that's performance and flexibility so performance is sort of the first one realistically the current sort of industry standard for games is 60 frames a second that means everything literally everything you have to do has to happen in sixteen point six two six six six two six or six milliseconds if you take more than that it's gonna stutter it's gonna look bad you're gonna get terrible reviews on Steam you're gonna make no money you're gonna find yourself out of a job and you know that's not good if you think your audience for like actual serious software is bad try building a game yeah you have no idea so there are some tricks you can do to get around this sixteen point six milliseconds but as a rule of thumb you've got a very very short amount of time to do literally everything you need to do every single frame the next thing is flexibility so video games are basically Gillian's of little tiny pieces that are all combining into one amazing thing which we call game managing this can get out of hand very very quickly games are also made by relatively large teams compared to most software development games will have hundreds of people working on them and some very large projects do but like large teams are the norm for games whereas in general software development tends to try and keep small teams in my experience so not only there are a lot of moving code and asset pieces there's a lot of moving people pieces so it all gets out of hand now ECS encourages both of these it encourages both performance and flexibility now we really want to stress the key word here is being encouraged because ECS I don't wanna say it's easy to mess up but it is still possible to mess up because it is a little bit different than how most architectures sort of work so it comes like with a fresh whoo a fresh set of foot guns that you've never perhaps seen before that you're like oh I could try this so yeah it does have some risks associated with it it's easy to make mistakes so that's great you say but your software architects and your architectures are probably already holman scalable and everything is fine so why should you care well let's go to this very simple game example let's say you have a base type enemy and then you have a sword enemy and you have a shield enemy but things don't always stay the same I would like an enemy with a sword and a shield so where do you put that guy and that's a bit contrived but in games we have a tendency for this to get very messy fast because there are two ways that you can try to combat this you either try to maintain reasonable inheritance relationships and remember where all your different attributes and behaviors are without duplicating your logical over the place or you make these really powerful all-encompassing base objects and then try to move to a bunch of this stuff as you go down and this also gets out of hand very quickly so this here is this is from Catherine West's excellent Ross Kampf closing keynote about game development Ross this is just a sped-up excerpt of the accessor file for their player class in their game Starbound and it's massive this is just the excesses there's no logic here this is all just the interface into it and this sort of shows how easy it is to make these giant god objects really trivially in games because the functionality that anything may have is effectively determined on the fly by what the players are going to do now it does sound like we're bagging out Starbound and Catherine west we're not it's an amazing game they're amazing developers it's just this thing naturally happens in games because of the nature of games you're constantly being told to add in new features and you're a programmer in this case you're gonna be lazy and just stick it all in one big file it doesn't look like this because they're bad it looks like this because programming doesn't really work the way games do so to give some context to how these sort of problems with video games being basically awful two bills gave rise to things like ECS we're gonna have a really quick history lesson I'm gonna go way way back in ancient deepest darkest history to the long distant past which is the Game Developers Conference the GDC in the distant time of 2002 so in 2002 at the GDC a talk was given from the developers of an RPG called Dungeon Siege it was ahead of his time in a lot of ways because it had a really flexible complicated system in the game and dungeon sees used what they called an entity system which is probably something you've heard of or touched or used it made it easier to create entities in pieces and allow the designers to modify the game objects so one of the really groundbreaking things about Dungeon Siege was the game was built by designers more than most other games worth because it allowed designers to build entities in the game without having to code stuff as much and it made them easy to understand it made trying out new game design ideas much easier because it kind of crosscut traditional object-oriented programming ideas they were very agile they are very fast it was a very successful project in terms of the game design now a little bit later much more recently in 2007 the development team behind operation flashpoint dragon rising thank you Tim which is a sequel to a very successful game started using an entity system inspired by the work of Dungeon Siege one of those developers Adam Martin wrote up his thoughts on their architecture on his blog and he still blogs today he's a very interesting guy to follow but in doing so he popularized the terminology in concepts that are central to the way we talk about ECS in the video game world now so he kind of created the jargon that we use now to talk about this subject so blame him for the name space collisions right so the sort of the cool things the the three main things I guess terminology that he came up with were entities components and systems entities at their core just have IDs that's all they are they're an ID components have the data that are necessary for other things and systems have the logic so one of the kind of interesting things is there's this very clean separation between all three and systems sort of first first-class elements as much as the components and the entities themselves which is a little bit different from most things we sort of get at so let's look at these one by one we'll start with entity and entity is any object in your game it might be a projectile or player and enemy anything it's just a unique identifier no logic attached it's just an ID that allows a collection of components to be associated with it somehow as you'll see later it's the potato of the mr. potato head it's a bit hard to describe because I for one always go to say the object and that's a very loaded term so there are different ways that you can describe them anything but the terrain but sometimes you cooperate if you really want to make it hard somebody proposed the term assemblages anything works the potato but entities are boring because they're just a thing to reference in many of the implementations it's just an integer which hang on isn't this just a primary key well yeah yes it is and that'll probably make more sense as we go along but we get to the components a component has some data that is needed to support a behavior or a feature it's basically a flag for example a bullet projectile might need some position information in order to be drawn on screen or to know if it will hit something and many implementations a component is just a struct a class an array a dictionary the flag definition comes into play when it's none of those things at all such as there might be a playable component that just indicates whether a character entity can be player controls that acts as a boolean about whether a certain entity has that component or not and it holds nothing then we get to the system which is the interesting bit it's where the logic of a behavior lives each one operates on the components relevant to it for example a movement system might iterate over all the entities that have both a position component and a velocity component the system would modify the position based on its velocity I just want to add when I was talking about this to some people they said our microservices and then we got a huge debate if you want to think of those microservices you can personally I don't think they're the same but we can have that debate after the year talk so as this slide kind of alludes to there's a lot of crossover terminology and a lot of these concepts come from other places and although have been used in other places before and after.this so we're not trying to say ECS is the one true way of doing things it's just one way we've done things in games and it might be helpful to you to learn how we're doing that to solve similar problems outside of games on that note you'll see a lot of stuff on the internet if you do Google around for entity component architecture which is even more confusingly sometimes called an entity component system as opposed to entity component systems which is actually two different things but on the surface it sounds similar EC has entities and components but contrary to ECS components in EC often have logic EC you know like a hardcore declare definition sense is really just a layer on top of object-oriented programming we're using encapsulation inheritance polymorphism and so on to compose objects whereas a dictionary had called strict definition of ECS is you're ignoring traditional object-oriented programming principles and composing entities outside of that sort of system so don't be confused don't be alarmed you don't have to be rigid about these things you can just take all the bits that you like and apply them in however you you want to so what's happening with EC is today so who's using it well I mean there's games and that's currently about it we have found a few other examples but you know you're not in games so let's unpack it a little bit more we're not going to talk about games anymore so why would it be useful to you so to do this we're going to talk about games sorry about that again most of the examples are going to be game specific you laugh but we actually are really sorry we sat there sort of crying over the last two weeks turner prepare this talk to remove the game stuff and then we just basically arrived we have to talk about games to explain this properly so the first thing it's sort of games today are extremely dynamic there are lots and lots of moving parts so game worlds are built out of all of these entities these things these mr. potato heads - the the bits many of which are unique they have all these different properties so a tree is going to be different from a human which is gonna be different from an alien which is gonna be different from a car which is gonna be different from or whatever all of these things have to interact in this massive complex world all of which are unique which means it's good it gets complex fast to make matters worse games are in constant development flux right up until when they're released they're constantly changing and if you ever read any like dev blogs from video game developers you'll see literally up until the last day and sometimes after the last day they'll still be working on and they'll just be pushing out patches if you're ever like damn why does my game have a 50 gig patch on day one because they're still working on it it gets even worse these days because so many games are now called live games or games as a service they've got life spans of ten years or expected life spans of ten years and because players expect constant new content constant tweaks constant updating the games effectively never stopped being developed one of our takeaways is kind of that the way ECS works is a product of the way the games industry works and that's kind of for better or for worse like there's some terrible doctors of history who've research medicines that have come about from terrible ways and I'm not saying this is the case here but ECS has kind of come out because the game development industry is very brutal to its workers in some ways kind of has a Hollywood model where it assembles a team and then it dissipates quickly and immediately so lots of different people working on things very quickly and then changing changing teams and this kind of reflects that in some ways so what this means is there's constant flux unending flux new things being added tweaked and changed the whole time which is how you can end up with AI spiders squeezing through doors like vermin this is a one of my favorite Twitter accounts it's called the strange log it tweets out of context patch notes from video games so you get all sorts of amazing sort of things coming out there like for example warm laundry should no longer kill your sims that probably I'm totally guessing here the sims is a well-built game but I'm willing to bet someone probably set a flag saying warm laundry is hot Sims died from hot I reckon that's probably what happened total guess I could be completely wrong there so effectively what I'm getting at is games have a lot of moving parts I know I keep saying it a lot but you've got this swirling void of effectively unique things game for elements being created used then torn down constantly which means each frame you don't actually know what's going to happen like you know there's some things that might happen but you don't actually know what's going to happen despite all that there's actually a bunch of common aspects that most entities will have so most will have position visuals animation sound gameplay data they may not have them but there's a lot of stuff already done so you'll think hang on I don't want to read I don't want to rewrite all this stuff that's you know a tree needs to have position as equally as a person does I shouldn't have to rewrite that so we don't go back to the old issues of this hierarchy because we've already agreed that's bad luckily for us while a game seems like this so what feels like you know you press W will move the stick forward the player walks forward one position and then you know you've got a skeleton and the skeleton Casa array off to the player Paris is now the player apparently and then you know if they can see the play of the skills and on the skeleton can see the player I'll move in if I'm in ranging and swing my sword here hurt Paris sorry Paris but what games actually doing is its receiving user input so you know the W Keys pressed its recasting from the player to the enemy it's an updating everyone's position at once you know why wouldn't you you're then dealing damage if necessary you then update the animation so the Skilton goes like as opposed to that it even be less than that you then render out the frame so it actually gets displayed so effectively behind the scenes they're much more of a series of steps that you follow each and every frame and the series doesn't change even if the data that they're being given does change so ECS basically takes the approach that we massal stick to this model the data is separate from the functionality so we may as well just roll with it why obscure this why why why not stick to the data structures that we've been given so while each entity in a game does have its own existence they all boil down to effectively a process that they follow and ECS basically structures your code to follow this process so back in the distant past when we did distant past like the early 2000s or last week or last week I do it all the time when we used low in games each game was effectively some sort of object superclass generally called game object we're very original in our naming a naturally it followed there was an instantiation which enabled you know extension of Anthony's blah blah blah blah blah blah and we got more and more rigid hierarchies which so even though we're trying to the right thing we decided no we got to go back we have to smash these hierarchies apart which is where ECS sort of comes in so again we might go back to the simple class hierarchy example except solutions to this a varied I'm sure that everyone has come up with their own approach that was born out of the Rage induced by bad hierarchy but the specific vein that's born DCs and approaches like it is the concept that instead of a behavior inheriting its attributes and behaviors adding or overriding some as needed each instead is composed of attributes and behaviors relevant to it from a range of reusable ones there's no hierarchy at all the architecture is completely flat so an entity is instead an aggregation well a composition of components and doing this this way has a range of better benefits primarily that's easy to define or change the behaviour of entities during development but also that while the game is running it's especially performant when it comes to creating changing and destroying large numbers of independent things entities on the fly so taking our earlier example this is how it might look instead and instead of worrying about where the third enemy will go we just define a sword component and a shield component and give each to whoever needs it so let's take a quick look again at each of the parts of ECS through the lens of games in a slightly more detailed fashion and how it might work with a more modern video game so in a game and into me entity is something that has a presence in your game world that doesn't actually mean it has to be visible it could be the camera it could be the player object which is visible it could be a rock which is visible at course would be like a where there effect it could be anything literally anything it's just an ID really it's nothing more than an ID to which components that belong to it say hi I'm also associated with this ID it in a game engine that implements ECS the components that make up an entity will be tagged typically with the idea of the entity to which they belong to so the entity implicitly aggregates the components tagged with the ID in practice that means a bunch of things probably the most interesting one is that you can dynamically add components to an entity or dynamically remove them and as Tim kind of alluded to with his example if you wanted to say cast a spell and something that was moving in a fantasy video game you might cast the free spell and then the free spell might just remove the velocity component from the object that was meant to be frozen now it's frozen without you really having to do any sort of complicated freezing behavior there was a great example actually just recently of a video game where it was like fans a lot of games a fantasy base I don't know why I would had like all these minions running forward and arrows were shooting them and you could also fire a fireball at the enemy and it would hit the enemy it would throw them up in the air and the way they actually did the throwing the up in the air is they just gave them an arrow component and took away their walking component then suddenly they start flying like an arrow and that was how they did it didn't have to write any extra code they just moved which way it was facing and this kind of systems thinking legitimately unlocks new game design potential in games because it unlocks stuff that people didn't even think of before all sorts of emergent behaviors impossible so these are typical examples of an entity you might find in video game you know pretty simple stuff the component doesn't really differ too much in a video game context as compared to non video games a component is just something to store data it doesn't act upon its data it just stores it it's kind of like a struct in programming terms it might even be implemented as a struct in a real world video game implementation of ECS where you'll typically find ECS implemented on top of some sort of object system you might actually find that each component derives from some kind of abstract component type which provides the ability to get the components type and the entity that contains it while the program is running and stuff like that but it's really just a holdover something it has some data that is needed to support a feature or a behavior of something and as we said earlier with the flags an empty component might just be used to say it is something so like player might be a component to tag the player object amongst a bunch of otherwise pretty similar humanoid ish rigs in a video game these are some typical components in a video game positions velocities reference to the sprite files that birds belong to the player or the object in question health values character names a tag to say it to the player object you could probably predict most of these so what's the system that you're destroying the stage Tim maybe yes what's a system do the system is the game logic so it says to operate on related group of components system examples in a video game might be player control rendering gravity movement AR control or much more small specific things like freeze spell or things like that it's pretty straightforward once you start thinking input ECS is massive in games and games are massively into ecs right now as you may or may not be aware the games industry is effectively at this point dominated by a mere handful of engine middleware providers unity and unreal are two of the biggest ones both have always been kind of pseudo entity component-based in that they've recommended composing your work out of pieces components for years and years that's traditionally set on top of a fairly comprehensive object model in the case of unity everything in unity is a game object which is descending from a mono behavior because it's c-sharp and so on and so on unity is slowly migrating their entire recommended stack to actual legitimate ECS system which currently interacts with the traditional model but is theoretically going to phase it out slowly over time unity really encourages people to use the new system as it's a pure data oriented approach so probably the reason they're doing this is because it's fast it's very fast on small relatively embedded devices like phones and tiny things and you can make a real tiny slice of a game just by shipping the entities that you need with the components that you need so you know ads that are games and all sorts of Horrors like that can be made now object oriented based hierarchies are implicitly the past video games but probably never going to actually be the past um they're always gonna stick around a little bit nothing really ever goes away really the bit that video games are going to latch on to big time is that entities are your game objects which are implicitly defined by collections of components the components are data and operated on by systems so if you think about this ECS usually does not actually mean less code it probably means more code actually it probably means better code but more because it makes your code simpler to read and more discreet so now let's have a look at some more concrete things that easiest could be good for outside of games many cell ECS on it's performance potential alone we don't quite buy this as the only strength of ECS is some do but it is nice so here's a great quote I'm not gonna read it out because you've all can read and if you can't read hopefully it will be transcribed you at some point but this is from Mike Acton who is a very prolific game developer he's worked on a whole bunch of really big games primarily in the engine development side of things he's a big believer in this sort of philosophy in that realistically all the program is is something that takes in data spits out data and this sort of boils down into this concept called data oriented design or dodd is anyone here using data oriented design out of curiosity no it is a little bit weird it's yeah so it's the implementation specifics vary quite a lot depending what you're gonna do so what you can talk about the brief principles of it you can't really say here's how you do it or at least I don't think so and data oriented design and ECS specifically takes a view they're never really doing just one thing you're always doing lots and lots of things so if we assume this to be true then operating on a single item at one time can't be the best thing to do because it's all about the cache so let's say here's our cache which from memory is 64 bytes on x86 I'm going from memory there doesn't matter here's our case lovely cache in the CPU just sitting there let's say we want to update the position of our game entities because we do many things at once that's the principle data oriented design we're going to update all of our positions at once so we'll start with the player why not so we grab the player and let's say we've got it doesn't necessarily have to be an object but let's say we've got a traditional built up sort of thing so we've got a player here it has a name a position a rotation and mash that helps you draw it and some other stuff straight into the case you know good job Ram you did your job Katia's got it from here CPU goes hey cache need that position case goes dari boss pass it over apparently in my head all CPU components are alive whatever it moves the position puts it back we're all good now the CPU goes hey I need the the position for the for the skeleton and the case goes ah no mine I'll throw away the the player I'll grabbing the the the enemy here any oh now we've got its name its position its rotation it's mesh it's other stuff and then you know it goes hey can I have that Joe he go sure no worries it handles it all everything's good so we've got a cache miss so this is from Chandler carruth efficiency with algorithms performance with data structures from C++ con 2014 a great conference if you like C++ I find C++ terrifying which is why I also love the conference and he's got some hierarchical speeds there so you can see very quickly this stuff's really bad basically cache misses suck this is true not just for games is it true for everything but remember in a game you got sixteen point sixty sixty six milliseconds so a case is you know proportionally nastier so there's a great description I once heard of a cache miss so reading from location of the CPU is like the CPU taking are you on so yeah that's pretty quick reading from the RAM into the cache is basically the CPU taking a long weekend and you know you'll CPU you paid a lot of money for it you want to take in long weekends so at the the simplest way of sort of getting around this is you replace instead of having position rotation etc all put into the individual component the individual entity itself you make a transform it'll be an array of positions and rotations and there might be some other stuff so then when the CPU goes hey I want to update the player yep here you go oh I want to update the the enemy yep here you go I want to update the next thing oh yeah here you go so basically the cache can be filled as efficiently as possible is the idea now it does depend a lot on what your data is as to how you do that so that's why I'm kind of keeping it vague because you need to know specifically what your data is and how big your caches and so on and so forth so down on design basically is programming for good memory access is at its core what it's about and ECS encourages data oriented design you don't technically have to do it but you'll end up creating something which is like you're doing bad during data oriented design anyway CMS will just do good data oriented design and wrap your ECS around it so one of the probably one of the biggest reasons ECS has taken off in games is because it if you do it properly you get all these nice performance advantages but that's not technically ECS doing that in my mind with ECS is focus on optimal layout and minimal transformation of data in memory parallelization becomes theoretically trivial each system should be able to operate in isolation they can be distributed among different threads and maximize the throughput of the systems from a data perspective ECS is a great fit if you're working on a project that needs to perform a large number of relatively similar but not identical tasks on a large data set so if you structure your program around consuming the daughters-- a stream then ECS is assumption that the data set is non-homogeneous means different systems can consume their own different segments of the same large set of data assuming that they have not very many mutations they won't clash with each other they're leaving each other alone this means that you can make complex interlocking systems like air traffic control which is all about rapid processing of data or from many many different sources where far more analysis because the mutation so in Australia something that looks a lot like ECS is actually part of our air traffic control systems we think that lightweight composability is the biggest advantage of a CCS it makes it easy to compose a new type of entity just like gloaming components together so instead of managing and growing hierarchy of relationships where development development that income becomes about creating useful and reusable components in abstraction even though we just heard rommel trash reusability so this is key in systems whose o my ramaa if you like we can back out rommel for the last 10 minutes it's fine we'll trash rommel trashing reusability but this is key in systems whose data is varied in type and source and has the need to process be processed in many places as quickly as possible and from a team perspective as we said before this can allow for entities to be designed by parties that need not understand how their corresponding components all systems will work on the logic side more specifically we think there are some key domains where this could be great and to take the first example GUI programming is an application where parts of the whole may have complex relationships across proximity structure and semantics but may require many of the same behaviors such as the ability to draw on to the screen hold state or refresh because in theory components and systems are separate from how they used different people can build different bits of your system different teams can build different bits of your system and everything should still in theory work in practice it's not that easy but it's a nice thought truthfully it's probably more that in the video game has a video game industry as a transitive workforce it necessitates these kinds of very discretely segmented practices and architectures that support that locality of reasoning and all that so if your data and procedures remain uniform then EECS is probably not good for you you probably just need a database or something else entirely databases are great databases are still great and we really like you VCS doesn't make sense it doesn't make sense ECS is obviously not very good for anything disk heavy games are not particularly disk heavy they can't a load a bunch of stuff at the beginning and they don't really touch the disk again traditionally ETS is not great for unchanging data and procedures so you have the same you know it's obvious doesn't make sense or heavily hierarchical data again you might want to database or something that's actually designed to store something with the hierarchy so we've been talking all about these how would you actually go about making one of these because I'm a big believer in insane code because you know my operating is a programmer so we're gonna do it the quick and dirty way we're gonna make a game about evil skeletons you know trying to stab us we're not gonna actually make the whole game we're just gonna do it an imaginary pseudo language called Tim code which I made up it looks a lot like every other language that I've ever worked on weird so let's start with our entities because we all love things who doesn't love things so here's our entities we're done sweet entities complete this is actually a little bit silly normally you'd give them some additional metadata such as a name or so on and so forth just simply so like your your human flesh brain can as opposed to your non flesh brain I can handle all this stuff we layer skeletons cameras etc with any components because who doesn't love abilities so here are our components we've got transforms we've got movement we've got health shield etc we've also got two that it just Flags so we've got player and camera so they have no data they just say you now do a thing so how do we connect these together well we have our game object it may not necessarily be an object you know here's our entities from before here's all of our components normally you would have some sort of component manager that way you don't actually have to have a big long list of these things yourself but we're doing it the quick and dirty way and all of these are the exact same length that way we can just use the values of entities as our keys into the components how do we add them in like that easy done again normally you wouldn't do this purely in code you would have some sort of manager we go like hey add a health component to entity zero add a movement component to entity two so on and so forth but the idea is the same regardless of how you actually do it you're just adding elements to an array so what about the system's there we go magic so this is our update frame method I apologize it's a little bit hard to read basically this gets called every single frame of the game so roughly every 16 milliseconds it gets told the time difference between the frames because no is perfectly running at 60 locked so you know we'll get our input we'll then use a system called update player speed it takes in the input all the players makes any modifications necessary then we'll move everything that can be moved so that's all about we'll need our movers of which our player is one and our skeleton is one we'll need our transform so we get the X Y Z etc Z sorry sorry I speak Australian it's like American but with more English and Delta x that way we can actually you know move between them and you know deal damage reduce damage and then finally we render the frame so there is actually a hierarchy here instead a set of processes what would one of them our systems actually look like it it looks something like this you know we just go through all of them we make the we just update the move the position value based on their move velocity pretty simple stuff so while we us human creature things think of our entities like this the game thinks of them like this so we've got all these arrays now there's better ways of doing this this is the quick and dirty way because it's something you can actually set up yourself in like a weekend of fiddling around all you need is some sort of UI system to draw the elements now and it actually works better than you might think it just doesn't scale that well because suddenly you're gonna find yourself with arrays that are like 10 million elements long most of which are nulls so there are obviously better ways and I'm sure you can all think of better ways using maps and so on so forth but it's the best way to get started because it's super easy to understand and who doesn't have a raise I love a raise so that's a very quick and dirty implementation if you want to get experimenting with ECS straightaway and a really good way of doing this we recommend is with like a side project a very small thing you might work on in your spare time so I'm sort of side hustle some sort of hobby project don't necessarily bring this to work and say let's make this ECS there's a lot of great easiest implementations there's one for pretty much every language under the Sun entity NTT is a particular interesting one it's a key component of the remake of Minecraft Microsoft made a couple of years ago like the high-performance one and enter tas is a really interesting one to look at which is the c sharp on there enter tasks is huge and massive but is available in pretty much every language none of this is new in fact you're probably doing this sort of thing already in many ways out of curiosity you think this sounds like an SQL database in memory you're right it kind of is sorry yeah don't don't worry if you just try to figure out what's going on and you can't see how and why this would be a system of its own it's a whole bunch of names for something that existed all over the place so we've given you a quick tour of SES and how it's just a newish kind of data oriented design we've discussed how easy s is an architecture made up of entities which are just an ID and components which hold the raw data for the system for an aspect and systems which operate on these things so ECS encourages a highly composable design in fact that's its main takeaway VM taking everything throw away your hierarchies no hierarchies all composition at its core it looks like just the composition you've been using but it's like composition on steroids in that you don't have hierarchy at all the human mind will put the hierarchy and structure back in that's fine the game doesn't need to care about that ECS is in that respect a very data oriented design paradigm it has a bunch of strengths it's hopefully performant it's hopefully flexible and it hasn't got a hierarchy which is a misspelling of hierarchy to remember it kind of has many of the advantages of microservices or functional programming so don't be alarmed if you're thinking that you're correct it's not either of those things but it kind of resembles them if you squint so it's easy to pick up at a test refactor and so on it has a bunch of weaknesses really enough there is no clear starting point is maybe a strength those games also have no clear starting point but at least with ECS you can pick up a system or pick out a system and go with that but there's a lot of code and ECS implementations to sum up there's a lot of choice and ECS systems but there's a lot of ideas within ecs you can pick and choose the bits you like there's no one right way of doing this hopefully it helps you think about your systems in a different way though so hopefully we've helped in that respect we're gonna put slides on the SA Khan website later and we'll put resources at this URL which i think is actually just the talk on the essay Khan website but if you want to take a photo of it anyway you're welcome to please review us it's in the app and the website please give us a comment of you review us it's really even if you hate it it's really stressful to stare at the review list and go like why did they give us 3 stars what does that mean so you've got time to review us we really appreciate it calm and it really helps everyone here so review all the talks 1 star creatures that make sense but you need to put that you'll need to put that in the comment line 2 stars for each of us so yeah please follow us or talk to us online are we have I meet the experts we're theoretically experts which seems weird but we're not sure what's going on now we're at one of the tables over on the side of this one civilian at 3:05 today we have some ECS systems on our computers we can show you if you'd like to see these things in action we just want to complain or talk literally about anything thank you yep that's cool bring it on yeah I said we got about 5 minutes in theory 7 minutes apparently yes hi so do you think that in unity the fact that unity is somehow built up upon mono and that hierarchical structure that you are talking about earlier resembles the fact that to c-sharp is somehow object-oriented language and it is built upon hierarchy and if so do you think that c-sharp is suited for SES strategy ok so the if I'm honest any question correctly basically asking because it still kind of implemented semi hierarchical in things like unity is that a side effect of like c-sharp No so it's implemented in a semi hierarchical fashion a fashion unity because unities scene editor the thing where you actually you know make the the games in is naturally hierarchical the ECS system actually runs like as a completely separate like mini process inside the whole game that does do it fully ECS the proper way it's just in the UI what you're seeing is them then magically squishing it into the hierarchy so the actual ECS system is separate from the hierarchy it's just they show it hierarchical because unities how old's unit you know 15 years old they don't just want to throw away 15 years of people's experience so this is is still you know properly traditionally ECS it's just it's kind of obscured a little bit oh I'm not unity I ie the questions would unity move away from mana I doubt it I honestly don't know I'm not unity though so okay no according to Paris I would doubt it they've spent a long they know mono pretty well I'd be surprised if they left it hi I'm a lot of the concepts kind of that you guys presented it sounds a lot like like the functional paradigm right like separating code and data and and it's very interesting because that's like exactly what you don't think about when you think of games obviously it's you know kind of more performance oriented and yeah so like is that an intentional thing or have they kind of independently discovered these things so like I'm not one of the inventors of ECS and it sort of grew up over 20 or 30 years of game discipline so I can't quite say I think deep down inside every programmer wants to do things functionally it's just practically a lot of things are hard to do functionally so I think when given the choice to do something functionally I think they took it I don't think it was an intentional design decision I think it sort of grew out of the needs one real huge advantage of ecs that we sort of mentioned is that people who aren't programmers at all people have no technical skills whatsoever beyond the ability to use computers can just be told hey just add the flying component and then they can build games out of it they just click a button in an editor and suddenly they have it and that I think was probably the bigger drive the fact that the way they had to invent that naturally boiled down into functional is I think a happy coincidence for the for the programmers I don't fully know but I would say I think it's a coincidence but a good one hmm Jim's comments about how it's just like microservices and we go yes kind of it's as much like micro-services as it is like functional programming and as much functional programming is like microservices in that when you boil down to the extreme end of performance being really important so like edge devices really low power devices games anything to the extreme end performance they all end up going back to that kind of we need to parallelize everything so we need to make everything as non mutable non classical as possible so that they just kind of end up there that was I'm going to follow up on that because I functional programming thing was in my mind too so and I actually tweeted you and he didn't respond so I guess I left my phone over there I'd say so my watch kept going off from like oh yeah my phone's over there so yeah we're good I just never tweeted anybody during their talk before and I was really excited about the idea sorry hmm anyways what I tweeted or related to what I tweeted was you say composition not to me means like math the results of this function is fed into that function is fed into that function is fed into that from their chains that's the and that's functional programming I don't see any chains in ECS that's just because you gave us really easy decide with all the different how the computer sees it and it was like these are the transforms and these are the movers and everything and that's where you get back to the it's your systems run in a predefined order and you define what the chain of systems executed on each frame are so in our game example it's like well you obviously have to see what moves before you see what hits each other before you see what damage is done and so they're in that way they operate on that data and then they put it back and then the next one takes the same data and in that way it's like they're feeding it to the next one they just put it back in the bucket first one of the real problems with that's why we did a quick and dirty way of showing because I wanted to show an actual ECS implementation but they're generally highly optimized which means the code is hard to read so office gated just it's you can't just pick it up you know Unity's implementation of VCS actually then bolts all the true ICS stuff back onto unity editor which then visualizes if it's objects because otherwise a human trying to build a game in the editor environment is completely incomprehensible so unity is kind of mapped at both both directions in either way so the human can interact with it and the computer interact with think we're out of we got one you know one minute there's a good wine he's like the idiot see it all wrong so I can imagine that you have maybe hundreds of energizing components right how do you sort of manage that without introducing hierarchy or domains like do you have domains for each of these pieces like how does a developer know that this piece exists like I don't want to build the same thing that someone else built so most entity component systems that implement is sort of thing have a grouping called a feature which so the feature that lets you bundle common bits together in like sensible ways and it's still not necessarily an object it's often like a tag on the objects generally just a UI thing so it goes like hey look here's the here's the the collection of these things together a thing that really helped me get get to grips with how this could be structured in a very large project is to read the enter test documentation which is one of those entity component systems and they have a very clear feature implementation which is documented really well and kind of explains how the concept could work and unfortunately we're out of time thank you thank you for coming [Applause]

Channel: Mars Buttfield-Addison

Views: 4,151

Keywords: Game Development, Entity Component Systems, ECS, Software Architecture

Id: SFKR5rZBu-8

Length: 50min 8sec (3008 seconds)

Published: Fri Mar 08 2019