Entity Component Systems and You: They're Not Just For Game Developers (SAConf NY 2019)
Вставка
- Опубліковано 7 бер 2019
- The hot new thing in software architecture for games is entity component systems (ECS). While the rest of the software architecture world is admiring their shiny containers, edge computing, and cloud-native architecture, game developers are off in the corner creating new ECS-based architectures and pushing the boundaries of architecture with this runtime-flexible, highly compatible, safe, and easily composable approach to software.
An entity-component-system involves three components: an entity (a general purpose object); a component (the parameters for one facet of the object); and the system (something that runs continuously and performs actions on every entity that has a component of the same facet the system manages). ECS makes for the safe management of dependencies; the system can check entities for the components and perform logic as needed. Nothing is dependent on anything else in a strongly coupled way.
ECS also makes for easily “composable” software. There’s no complex inheritance tree, since every entity has little more than an ID and a list of the components-its facets. Any object necessary can be created by composing an entity with the needed facets. Features from one type of entity can be added to another by including the necessary components.
In game design, the use is obvious: a physics engine in a game can iterate through all the physics simulation components present, performing any necessary calculations without caring how the entity is drawn. Or health point components can be attached to a play entity but not to other entities in the game world, and the health management system would know how to deduct health from entities that have health point components when a collision that would cause a loss of health occurs.
Intersystem and intercomponent communication can be a problem in this architecture, but there are a number of solutions, including use of the observer pattern.
This architecture is not just for games. Paris Buttfield-Addison, Mars Geldard, and Tim Nugent explain why. You’ll learn how to apply the lessons from decades of ECS use in game development to the wider software development and software architecture world and see how ECS is related to existing similar architectures. (ECS is kind of microservices, combined with functional programming, on some levels, but isn’t quite the same.) ECS isn’t for every software problem, but you can learn a lot from it even if you don’t use it.
This is worth the watch. IDK why a good talk on ESC seems so hard to find.
Enjoyed the presentation. As a fan of ECS architecture, I can tell that y'all had to gloss over a lot of details to tackle this topic in such a short amount of time. I for one applaud the effort. BTW, that outfit just screams Star Fleet...would make for awesome cosplay.
Thanks! With games topics at corporate events we try to keep it high-level, but it was a fun topic for sure. And the outfit’s actually one of my (quite a few) actual Star Trek costumes. Just before the conference in New York we were in Florida having just gotten off a Star Trek cruise, so a I had them all in my suitcase 😛
13:17 - "...its the Potato of the Mr Potato Head"...gold!
Awesome talk, seems like a good fit for software architecture conference, games are software after all. Really enjoyed this and good humor not forced
in web development, we call this Model View Controller or Presentation Abstraction Controller
Thank you for this. Great information. Currently considering the applicability of ECS and game engines in my small corner of the simulation industry. This helped a lot.
enjoyed your presentation. thx
What a fantastic team. I've listened to a lot of ecs and dod talks, but this is one of the few to make me laugh
I think the twitter question about no chains is probably because the systems functions are not pure (mutation of a component that came as a parameter). So while some of ECS aberration of hierarchies and data and code separation sounds like functional it doesn't really seem to care about function purity or even first class functions to be able to work.
I come from video games, now work at a watch company. I build design tools for them and use ECS. Interesting talk.
Several simulation systems use ECS like (in fact Data Driven Design), as many raycasting engines. A lot of AI stuff also uses it in a certain level of the architecture (before semantic mappings)
Really great talk
Are the slides available?
Can an entity be made up of other entities? I find it hard to apply ECS outside of game software. Like in gui domain of a generic app, you can have the properties of a model be either a text box or drop down. To me the entity is the model and its properties are more like other entities than components. If they were components you would end up with the same component multiple times which is awkward. None of the talks on ECS really cover this type of a problem. Any thoughts on this?
I'm not sure I follow your question, but there's a talk about applying this sort of thing to animation systems, those exist outside of games. I can also see it being useful in simulation / scientific computing. Pretty much anytime you have a few instances with the same sort of data in need of the same operation at about the same time, it could be useful, I think
here: ua-cam.com/video/yy8jQgmhbAU/v-deo.html
(the tittle is meant to be provocative, the speaker doesn't really mean it : p )
It's just another fad...
Entity is not a type, it's an abstraction that associates certain instances of components. By "certain" I mean that it associates THE data, not the TYPE of the data.
What you are asking for are templates or presets for certain components composition. Nothing stops you from creating methods "CreateButton", "CreateTextBox" which would result in allocating a certain set of data. You can abstract it into builders, factories etc just as well as you would do it with monolite objects.
@@98luk45 Dismissing the current best paradigm for cache optimization as a fad is a great way to write shit code lol.
She had an awesome shirt! 👍
That question about unity being object oriented because c# is oo irks me.
No language is object oriented, the programming is. A language can support oop, but that doesn't make the language itself oo. In c# you can use simple classes, static methods and as many globals as you want, avoiding every aspect of oop and it would totally work.
In that sense thinking the language limits you into programming that way is also wrong. Everyone starting off with programming will have started another way than object oriented, likely with a so called object oriented language.
That is a good point. Yes, it is true that there is pretty much no general (non-domain-specific) programming language strictly prohibits certain programming paradigms; so you can absolutely write C# without OOP and it will let you. But the conventions of a language--and especially the ideas behind creation of the language in the first place--become a very strong force by way of the documentation and examples available, as well as the stuff you see at events about/well-known users of the language.
So we're not speaking about technical constraints when we say language X is Y, we're saying that for X to not be Y would be unusual so a default user of X will probably want to know how works if they do Y. We speak about Unity and C# tools a lot, and it's pretty accepted that we can assume C# programmers in the audience will be using OOP unless told otherwise. So that's why Tim said that 👍
@CapnTates Literally from Microsoft's C# description of the language: C# (pronounced "See Sharp") is a modern, object-oriented, and type-safe programming language.
But some languages try to push you into it. Others make it nearly impossible on purpose (like Rust)
TIL Tasmanians say "cache" funny
So do Australians