entt

CautionEnTT has been a dream so far, we haven't found a single bug to date and it's super easy to work with. -- Every EnTT User Ever EnTT is a header-only, tiny and easy to use library for game programming and much more written in modern C++. Among others, it's used in Minecraft by Mojang, the ArcGIS Runtime SDKs by Esri and the amazing Ragdoll. If you don't see your project in the list, please open an issue, submit a PR or add the #entt tag to your topics! 👍 Do you want to keep up with changes or do you have a question that doesn't require you to open an issue? Join the gitter channel and the discord server, meet other users like you. The more we are, the better for everyone. Don't forget to check the FAQs and the wiki too. Your answers may already be there. Do you want to support EnTT? Consider becoming a sponsor or making a donation via PayPal. Many thanks to these people and special thanks to: WarningWe apologize to our kind users for not posting updates every three days saying that we are faster than three days ago and better than everyone else, but consider it done. In the meantime, enjoy a library that just works without having to constantly remind ourselves. Table of Contents Introduction Code Example Motivation Benchmark Integration Requirements CMake Natvis support Packaging Tools pkg-config Documentation Tests EnTT in Action Extensions Contributors License Introduction The entity-component-system (also known as ECS) is an architectural pattern used mostly in game development. For further details: Entity Systems Wiki Evolve Your Hierarchy ECS on Wikipedia This project started off as a pure entity-component system. Over time the codebase has grown as more and more classes and functionalities were added. Here is a brief, yet incomplete list of what it offers today: Support for user implementations of the Standard Template Library. Built-in RTTI system mostly similar to the standard one. Incredibly fast entity-component system with its own pay for what you use policy, unconstrained component types with optional pointer stability and hooks for storage customization. General purpose execution graph builder for optimal scheduling. A built-in, non-intrusive and macro-free runtime reflection system. Static polymorphism made simple and within everyone's reach. A few homemade containers, like a sparse set based hash map. All that is needed for resource management (cache, loaders, handles). Delegates, signal handlers and a tiny event dispatcher. And much more! Check out the wiki. This list as well as the project are a work in progress. The whole API is fully documented for those who are brave enough to read it. Please, do note that all tools are also DLL-friendly now and run smoothly across boundaries. NoteA lot of stuff was invented here, but we remain humble and let people copy it without giving us credit. The good and the bad of open source, but bragging is for others. Feel free to get inspired. One thing known to most is that EnTT is also used in Minecraft. Given that the game is available literally everywhere, I can confidently say that the library has been sufficiently tested on every platform that can come to mind. Code Example #include <entt/entt.hpp> struct position { float x; float y; }; struct velocity { float dx; float dy; }; void update(entt::registry &registry) { auto view = registry.view<const position, velocity>(); // use a callback view.each([](const auto &pos, auto &vel) { /* ... */ }); // use an extended callback view.each([](const auto entity, const auto &pos, auto &vel) { /* ... */ }); // use a range-for for(auto [entity, pos, vel]: view.each()) { // ... } // use forward iterators and get only the components of interest for(auto entity: view) { auto &vel = view.get<velocity>(entity); // ... } } int main() { entt::registry registry; for(auto i = 0u; i < 10u; ++i) { const auto entity = registry.create(); registry.emplace<position>(entity, i * 1.f, i * 1.f); if(i % 2 == 0) { registry.emplace<velocity>(entity, i * .1f, i * .1f); } } update(registry); } Motivation I started developing EnTT for the wrong reason: my goal was to design an entity-component system to beat another well known open source library both in terms of performance and possibly memory usage. In the end, I did it, but it wasn't very satisfying. Actually it wasn't satisfying at all. The fastest and nothing more, fairly little indeed. When I realized it, I tried hard to keep intact the great performance of EnTT and to add all the features I wanted to see in my own library at the same time. Nowadays, EnTT is finally what I was looking for: still faster than its competitors, lower memory usage in the average case, a really good API and an amazing set of features. And even more, of course. NoteIf the EnTT API looks familiar, it's probably because it's been copied a lot elsewhere (often without much ado). Credit where credit is due though, the initial design was heavily inspired by EntityX, another popular C++ library. Benchmark For what it's worth, you'll never see me trying to make other projects look bad or offer dubious comparisons just to make this library seem cooler. I leave this activity to others, if they enjoy it (and it seems that some people actually like it). I prefer to make better use of my time. If you are interested, you can compile the benchmark test in release mode (to enable compiler optimizations, otherwise it would make little sense) by setting the ENTT_BUILD_BENCHMARK option of CMake to ON, then evaluate yourself whether you're satisfied with the results or not. There are also a lot of projects out there that use EnTT as a basis for comparison (this should already tell you a lot). Many of these benchmarks are completely wrong, many others are simply incomplete, good at omitting some information and using the wrong function to