entt is a free, open source gaming project written in C++ and released under MIT. It has 13,139 GitHub stars, 1,117 forks and 12 open issues, and was last pushed 15 hours ago. On this registry it ranks #14 of 26 tracked projects in Gaming, with 5 head-to-head comparisons available.

What is entt?

EnTT is a header-only, MIT-licensed library written in modern C++ that provides a fast entity-component system (ECS) for game programming and more, aimed at game, engine and data-oriented developers who want the ECS architectural pattern without adopting a full framework.

What it is

EnTT lives in the modern C++ ecosystem, tagged for C++17 and C++20, and sits in the game-development space around the entity-component-system architectural pattern. The README describes it as a header-only, tiny and easy to use library for game programming, and states that it is used in Minecraft by Mojang, in the ArcGIS Runtime SDKs by Esri, and in Ragdoll. The project began as a pure entity-component system and grew as more classes and functionalities were added, so the current codebase covers both the ECS core and a set of supporting utilities.

The concrete problem it solves is the cost of building and maintaining an entity-component system in-house. A team that wants the ECS pattern would otherwise have to design its own entity storage, iteration and type machinery, then keep that machinery working as the project scales. EnTT supplies that layer directly: an entity-component system with a pay-for-what-you-use policy, unconstrained component types, optional pointer stability, hooks for storage customization, and views and groups for iterating entities and components. It also bundles smaller facilities that tend to appear in the same codebases, including a built-in RTTI system broadly similar to the standard one, a constexpr utility for human-readable resource names, and a minimal configuration system built using the monostate pattern.

Key capabilities

  • A header-only modern C++ entity-component system, so the library is consumed as source rather than linked as a separate binary.
  • An entity-component system with a pay-for-what-you-use policy, unconstrained component types, optional pointer stability and hooks for storage customization.
  • Views and groups for iterating entities and components, which is the main way game code drives the ECS at runtime.
  • A built-in RTTI system described as mostly similar to the standard one, useful when the standard facilities are unavailable or unwanted.
  • A constexpr utility for human-readable resource names.
  • A minimal configuration system implemented with the monostate pattern.
  • Integration support covering CMake, Natvis support for debugging, pkg-config, a Vcpkg port and a Conan Center recipe.

Who uses it and how

  • Mojang uses EnTT in Minecraft, a block-building game with a very large persistent world.
  • Esri uses it in the ArcGIS Runtime SDKs, where geospatial runtime code depends on efficient entity and component iteration.
  • Ragdoll uses it, showing adoption outside game engines proper in a physics-oriented product.
  • Game and engine developers adopt it as the ECS layer for data-oriented designs, using views and groups to drive systems and storage hooks to fit their own memory strategies.

Getting started

EnTT is header-only, so integration means including it in a C++17 or C++20 project and building. It can be brought in through its Vcpkg port or Conan Center recipe and wired up with CMake or pkg-config, and an online try-it link on Compiler Explorer plus Doxygen documentation at skypjack.github.io/entt/ and the project wiki are provided for evaluation.

How it compares

The facts provided do not list any paid products that EnTT replaces, and they do not name comparable ECS libraries either. Among the projects described in this registry, EnTT therefore stands alone.

When to use it — and when not to

Because it is header-only, adopting EnTT is a source-level dependency rather than an operated service, so there is no database, object storage or mail server to run and the trade-offs are build and integration ones instead. Teams that are not already working in modern C++ (the topics specify C++17 and C++20), or that expect a complete engine rather than a library, should not pick it. The README excerpt available here is truncated mid-list, with Requirements, Tests and Benchmark present only as headings, so anyone evaluating it seriously should consult the Doxygen documentation and the wiki for the full detail behind these claims.

project readme (upstream, from github) — read inline

EnTT: Gaming meets modern C++

Build Status Coverage Try online Documentation Vcpkg port Conan Center Gitter chat Discord channel

EnTT 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! :+1:


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:

mojang imgly

Table of Contents

Introduction

The entity-component-system (also known as ECS) is an architectural pattern used mostly in game development. For further details:

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:

  • Built-in RTTI system mostly similar to the standard one.
  • A constexpr utility for human-readable resource names.
  • Minimal configuration system built using the monostate pattern.
  • 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.
  • Views and groups to iterate entities and components and allow different access patterns, from perfect SoA to fully random.
  • A lot of facilities built on top of the entity-component system to help the users and avoid reinventing the wheel.
  • General purpose execution graph builder for optimal scheduling.
  • The smallest and most basic implementation of a service locator ever seen.
  • 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.
  • A cooperative scheduler for processes of any type.
  • All that is needed for resource management (cache, loaders, handles).
  • Delegates, signal handlers and a tiny event dispatcher.
  • A general purpose event emitter as a CRTP idiom based class template.
  • And much more! Check out the wiki.

Consider this list a work in progress as well as the project. The whole API is fully documented in-code 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.

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.

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 compare a given feature. Certainly there are also good ones but they age quickly if nobody updates them, especially when the library they are dealing with is actively developed.
Out of all of them, this seems like the most up-to-date project and also covers a certain number of libraries. I can't say exactly whether EnTT is used correctly or not. However, even if used poorly, it should still give the reader an idea of where it's going to operate.

Integration

EnTT is a header-only library. This means that including the entt.hpp header is enough to include the library as a whole and use it. For those who are interested only in the entity-component system, consider to include the sole entity/registry.hpp header instead.
It's a matter of adding the following line to the top of a file:

#include <entt/entt.hpp>

Use the line below to include only the entity-component system instead:

#include <entt/entity/registry.hpp>

Then pass the proper -I argument to the compiler to add the src directory to the include paths.

Requirements

To be able to use EnTT, users must provide a full-featured compiler that supports at least C++20.
The requirements below are mandatory to compile the tests and to extract the documentation:

  • CMake version 3.28 or later.
  • Doxygen version 1.14 or later.

Alternatively, Bazel is also supported as a build system (credits to zaucy who offered to maintain it).
In the documentation below I'll still refer to CMake, this being the official build system of the library.

CMake

To use EnTT from a CMake project, just link an existing target to the EnTT::EnTT alias.

The library offers everything you need for locating (as in find_package), embedding (as in add_subdirectory), fetching (as in FetchContent) or using it in many of the ways that you can think of and that involve CMake.
Covering all possible cases would require a treatise and not a simple README file, but I'm confident that anyone reading this section also knows what it's about and can use EnTT from a CMake project without problems.

Note that all install calls are guarded by the ENTT_INSTALL option to allow using EnTT as a submodule without conflicting with user logic.
It is therefore necessary to set the option to true to take advantage of the installation logic provided by this library.

Natvis support

When using CMake, just enable the option ENTT_INCLUDE_NATVIS and enjoy it.
Otherwise, most of the tools are covered via Natvis and all files can be found in the natvis subdirectory, divided by module.
If you spot errors or have suggestions, any contribution is welcome!

Packaging Tools

EnTT is available for some of the most known packaging tools. In particular:

  • Conan, the C/C++ Package Manager for Developers.

  • vcpkg, Microsoft VC++ Packaging Tool.
    You can download and install EnTT in just a few simple steps:

    $ git clone https://github.com/Microsoft/vcpkg.git
    $ cd vcpkg
    $ ./bootstrap-vcpkg.sh
    $ ./vcpkg integrate install
    $ vcpkg install entt
    

    Or you can use the experimental feature to test the latest changes:

    vcpkg install entt[experimental] --head
    

    The EnTT port in vcpkg is kept up to date by Microsoft team members and community contributors.
    If the version is out of date, please create an issue or pull request on the vcpkg repository.

  • Homebrew, the missing package manager for macOS.
    Available as a homebrew formula. Just type the following to install it:

    brew install skypjack/entt/entt
    
  • build2, build toolchain for developing and packaging C and C++ code.
    In order to use the entt package in a build2 project, add the following line or a similar one to the manifest file:

    depends: entt ^3.0.0
    

    Also check that the configuration refers to a valid repository, so that the package can be found by build2:

    Both can be used with bpkg add-repo or added in a project repositories.manifest. See the official documentation for more details.

  • bzlmod, Bazel's external dependency management system.
    To use the entt module in a bazel project, add the following to your MODULE.bazel file:

    bazel_dep(name = "entt", version = "3.16.0")
    

    EnTT will now be available as @entt (short for @entt//:entt) to be used in your cc_* rule deps.

Consider this list a work in progress and help me to make it longer if you like.

pkg-config

EnTT also supports pkg-config (for some definition of supports at least). A suitable file called entt.pc is generated and installed in a proper directory when running CMake.
This should also make it easier to use with tools such as Meson or similar.

Documentation

The documentation is based on doxygen. To build it:

$ cd build
$ cmake .. -DENTT_BUILD_DOCS=ON
$ make

The API reference is created in HTML format in the build/docs/html directory. To navigate it with your favorite browser:

$ cd build
$ your_favorite_browser docs/html/index.html

The same version is also available online for the latest release, that is the last stable tag.
Moreover, there exists a wiki dedicated to the project where users can find all related documentation pages.

Tests

To compile and run the tests, EnTT requires googletest.
cmake downloads and compiles the library before compiling anything else. In order to build the tests, set the CMake option ENTT_BUILD_TESTING to ON.

To build the most basic set of tests:

  • $ cd build
  • $ cmake -DENTT_BUILD_TESTING=ON ..
  • $ make
  • $ make test

Note that benchmarks are not part of this set.

EnTT in Action

EnTT is widely used in private and commercial applications. I cannot even mention most of them because of some signatures I put on some documents time ago. Fortunately, there are also people who took the time to implement open source projects based on EnTT and did not hold back when it came to documenting them.

Here you can find an incomplete list of games, applications and articles that can be used as a reference.

If you know of other resources out there that are about EnTT, feel free to open an issue or a PR and I'll be glad to add them to the list.

Contributors

Requests for features, PRs, suggestions and feedback are highly appreciated.

If you find you can help and want to contribute to the project with your experience or you do want to get part of the project for some other reason, feel free to contact me directly (you can find the mail in the profile).
I can't promise that each and every contribution will be accepted, but I can assure that I'll do my best to take them all as soon as possible.

If you decide to participate, please see the guidelines for contributing before to create issues or pull requests.
Take also a look at the contributors list to know who has participated so far.

License

Code and documentation Copyright (c) 2017-2026 Michele Caini.
Colorful logo Copyright (c) 2018-2021 Richard Caseres.

Code released under the MIT license.
Documentation released under CC BY 4.0.
All logos released under CC BY-SA 4.0.

Frequently asked questions

Is entt free to use?

entt is open source under the MIT licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does entt do?

Gaming meets modern C++ - a fast and reliable entity component system (ECS) and much more

What is entt written in?

entt is primarily written in C++. Its source is publicly available at https://github.com/skypjack/entt, and it has 13,139 GitHub stars.