CppCon 2015: Vittorio Romeo “Implementation of a component-based entity system in modern C++”
Вставка
- Опубліковано 6 жов 2015
- www.Cppcon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/cppcon/cppcon2015
-
An alternative to deep inheritance trees for game and application architecture design is "composition". Separating data (in independent components) from logic (in independent systems) allows the code to be more reusable and more efficient, alongside additional benefits. Using modern C++11 and C++14 features, it is possible to design an efficient and user-friendly component-based entity system library, with intuitive syntax and convenient cost-free abstractions.
-
Vittorio Romeo is an Italian 20 year old Computer Science student at "Università degli Studi di Messina". He began programming at a very young age and soon became a C++ enthusiast. While following the evolution of the C++ standard and embracing the newest features, he worked on several open-source projects, including modern general-purpose libraries and free cross-platform indie games.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
Oh wow two years ago I was searching the internet like mad to get any info regarding ECSs, expecting to find a ton of simple C++ implementations just for fun, but was surprised to find only a couple blog posts.
I'm very glad you were the one to fill this niche! Wish I had checked your website sooner.
+Daggawaggaboof Very glad you liked the talk! I've made a new ECS library (supporting multithreading) and gave a talk about it at C++Now 2016. Be sure to check that out as well, when the videos are released :)
So much C++ feature-use.
You may be interested in my newest C++Now 2016 talk:
"Implementation of a multithreaded compile-time ECS in C++14"
The video is available here:
ua-cam.com/video/3N1pLtTV2Uc/v-deo.html
The design and implementation are vastly superior :)
Great job. Thank you! :)
The sound quality is killing me. :(
Same here!!! Really annoying
Yeah what a damn shame too.. Great content in this talk!
Great lecture. Took me a few reviews to get it right.
This is a great talk. It actually gave me an idea how an ECS really could work and the only problem I'm stucking is creating an MPL. I don't want to use boost only for that and I want to learn how to implement a typelist with a variadic template but I can't find much of information on the web. It would be so cool if you made a brief video explaning your MPL implementation.
pdimov.com/cpp2/simple_cxx11_metaprogramming.html [ 25.07.2016 ] If you scroll down to the bottom, there is a part II aswell.
Thanks for the link I'll look into it
im new to design, thank you for the charts. im visual
Really interesting talk, thanks for giving it. I wondered though, what does having this much TMP do to your compile times? Doing this much in the compiler feels like it might slow the build down quite a bit. Have you noticed any problems like that?
+Laurie Hedge Glad you liked it. I haven't benchmarked the compile-time overhead, but it's definitely there - it's a price you unfortunately have to pay. A reasonable guess is that it mostly depends on the compile-time tuple/list manipulation: using a mature metaprogramming library optimized for compilation times, like boost::hana, is the best choice to reduce the overhead as much as possible in a real project.
What I mean is the part you move from OO virtual calls. into your core decisions. To be honest you don't need to explain (you already did a great job on the video), but if there is any codebase online and documentation if possible, that would be of great help.
Sorry about that! Is there any specific part you'd like me to explain? (Not sure what you mean with "the shift".)
+athrac This is not an easy problem, but, on the spot, I'd say I would probably implement several components for performance-intensive AI (pathfinding, targeting, raycasting, etc), and a script component that would allow me to use LUA/Python/whatever to interact with hardcoded components and build game object AI.
std::remove seems to be a good way to partition live and dead entities.
How would you implement multiple variations of the same component? E.g. a game with lots of different enemy types, each with its own AI. You can't make each AI a separate component if there's too many variations. You have to have one AI system that handles all of them, so it has to check the type of the enemy (switch statement?) and use the correct AI, but that seems like a bad solution. And it's the exact problem that virtual functions were meant to solve, so we've come a full circle..
I'm quite late here; but I think you missed where this was explained (though quickly, still understandably). You use the signatures to say what components you system (AI in your case) needs. And it's automatically passed for you. You would only need one AI System (he calls it a Manager FYI) this way. Actually seems like it would work great for your example above.
Is there any example of a large, AAA-level ECS engine? ( something like Unreal Engine 4 )
Unity is transitioning to this style with their ECS (talks available online). There are serious problems with this idea in a general case on the user side. Accessing any reference type will break cache frienliness. It is also very non-OOP, particularly violating encapsulation since everything can access everything.
Do I understand correctly that this system assumes "If an entity has these three components, then it is a skeleton and I can update it"? You can have many types of entities that have the same component types but are completely different things.
That is what the tags are for. When you have multiple entities with the same components that need to be distinguished, you add a tag to distinguish them.
"Thrive" is an open source gaming using this design! Altough the components are still allocated on the heap and less template programming.
Very briefly looked into it - seems like their components and entities are "heavy" and that they aren't trying of exploiting cache-friendliness for performance benefits. Which can be fine, depending on the scope of the game. It also looks like that their approach is "data-driven", using Lua. The flexibility/decoupling is there, but I think it could be vastly improved in terms of performance
***** Yeah there's some optimization to do for sure
There was this weird noise and clicks on the mic and I could not listen between minute 7 and 24, and then it seems I missed the important part, the shift...
Hey, I saw you ask a question at Mike Acton's talk at CppCon 2014 (here: ua-cam.com/video/rX0ItVEVjHc/v-deo.html&t=1h14m33s), and then went on to develop this data-oriented entity system. Fun stuff! Insightful work overall. It would pack more punch without so much C++ cruft, nevertheless enjoyable!
The particle system example isn't very good for showing performance, because the time the rendering operations take is gonna vastly overshadow the updating performance. If you had an array of vertices you were updating and then shoving into the GPU, that'd be a better example. From what I can tell, your example is limited by the number of draw calls and API overhead.
This compile time programming in c++ seems to be more complicated than needed.
I'll try to reimplement this in Scopes. That's probably going to be much simpler.
This talk needs *massive* reduction of content and considerable addition of examples and real explanations. Only the core idea should be presented and explained as clearly as possible. Some excellent talks come in mind - the ones of S. Parent, A Alexandrescu and recently Fedor Pikus about Lock-free.
Slides are invented for a reason - bite-sized chunks of information, only the most important one. If I want to look at a wall of code, I can aways look up the implementation myself.
The topic is interesting and important for c++, very similar to last (last) year's Mike Acton "Data-Oriented Design and C++", but the presentation must be completely reworked. No one needs a complete implementation for a presentation, just some cool simple example to show off.
+Михаил Найденов Thank you for the feedback. I agree with you - there was way too much content for a "live coding" presentation. My idea was to show the step-by-step implementation of an ECS, with a format I've used in the past. While the format was fine for talks with less content, a more "traditional" slide-based approach would have been better here. I apologize if the talk is difficult to follow and hope that something useful can still be learned from it. I will definitely avoid the same mistake in the future.
+Vittorio Romeo I found it overwhelming too but still very helpful. Thanks.
I do not disagree with Михаил Найденов comment and find your response to be very professional. I realize this is almost a year old but come across this tonight. There is a lot of information one can search for on this topic so I personally found your talk to be unique in the same way one may pair program with an associate at work, mentoring, etc. I did not find it overwhelming myself and actually had some concepts cement better on this topic due to your talk. Very useful information you have provided. I have also subscribed to your youtube channel as well. Thank you for sharing your experience and knowledge on this subject along with other videos on your channel. Like curtsher11 commented; very helpful. Thanks.
Normally I would agree. However, most videos or blog posts about ECS are very general and high level, so I found it very helpful to get a closer look at (one possible) actual implementation.
Unfortunately the presented code is not even close to a cache-friendly and data-oriented code. It's almost pointless to store the entities tightly packed when you have to constantly jump in the memory to get the actual component data.
His idea same as artemis, but artemis is not a good implementation
This is false and inaccurate. The components are not stored inside the entities. They are stored inside contiguous memory blocks. Components are just 'flagged' as having the components. In reality, you do not get the entity. It just kind of exists as a handle. When components are updated, they are updated in mass. The entities are not iterated over; the components are.
This is practically useless - do your own research
I really dislike posts like these; please post actual concrete information. Explain *why* it is useless, provide research links so those of us who don't have infinite free time at our disposal can quickly go find things that support your point.
After all, what can be asserted without evidence can be dismissed without evidence. You provided none, so I will wait until you post concrete information.
@@orangestapler8729 try this www.gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/ (most of the points refer to this video as well, though it is not guilty of claiming composition is not oop) to sum it up "Frameworkless composition (AKA using the features of the #*@!ing programming language)"
In general 1) ECS is an approach, not a silver bullet, you don't need to adhere to it strictly like this. Sure, iterate over a bunch of components but why do "all" entities need to be devoid of logic? Feel free to put some logic in them where it makes more sense. 2) most of what ECS relies on is functional oriented and relational programming which is older than object oriented, so it is definitely not new, if anything it is older. Object oriented gives you that you know your working scope. Here you are clueless, but flow of data is clearer. It's good to keep flow of data clear (oop is all for it) etc etc.
"Do your research" is a worthy cry, it's not like faults of ECS are hard to find. Mostly older programmers I've interacted with have called it a fad. That it has some tricks up the sleeve, sure, but generally, it's hard to present something that undermines 70 years of computation research and ECS often presents itself as ooh this the new way (for starters ECS truly is irrelevant, its name is DOD and ECS is just the implementation), while OOP presents itself as yeah look you got this 70 years of history.
To sum it up again, ECS is OOP with a slighter step back to functional programming. Look for DOD (Data Oriented Design) and study SOLID principles of OOP (that's where ideas like ECS come from) (and yeah SOLID is an acronym, look it up).