Entt: EnTT v3

[skypjack]

The time has come for the next big change.
EnTT is ready to embrace C++17. This would mean breaking changes to the API by itself, but I want to go further.

This issue should help to talk about some ideas already discussed in part on gitter (I invite everybody to join the chat for live discussions).

Here is a brief, yet incomplete list of _facts_ (I'm going to integrate it in future):

• C++17 will be required to use EnTT (well, quite obvious).

• A branch cpp14 will be created from v2.7.3 for bug fixing.

• All the new features will be released only on master and therefore developed using what C++17 has to offer. Examples of upcoming features that I'll continue to develop in C++17 are meta system and built-in job system. PRs to port them in C++14 will be welcome, if any.

• I won't introduce nested namespaces. I'm not a fan of them and I don't think EnTT reached a point where something like this is required actually.

• Uniform style. Currently, we have Registry and HashedString but also Registry::size_type and HashedString::hash_type. Pretty good a mix. EnTT v3 will adhere to the conventions of the standard library (ie lowercase class name and underscores). Therefore be prepared for entt::registry and the others.

• No more tag dispatching to disambiguate calls unless strictly required (ie in case of constructors). Names of member functions will be reviewed so as to _help_ completion tools (ie no more get<C>(entity) and get<T>(tag_t{}, entity), replaced by get_component<C>(entity) and get_tag<T>(entity)).

• Supported tools: GCC 7+, clang 6+ (maybe, at least 7+), vs2017.

Let's discuss these changes, other proposals and whatever for a while.

[dbacchet]

Terrific plan!

any ideas/design for the job system? I hope it will be decoupled enough that can be used independently from EnTT :)

Also, any reason why clang 6.01 (latest at time of writing) will likely not be enough?

[skypjack]

@dbacchet Yeah, terrific plan indeed. Do you like it? :-)
Feel free to leave me all your suggestions, comments and criticisms. I highly appreciate them, you know.

The idea is to design the job system the way I did for almost everything else: as much decoupled as possible from all the other parts of the library, of course. This way users can just get what they are interested in from EnTT and forget about the rest. The meta system will follow the same pattern as far as possible.

No reasons to get rid of clang 6 at the moment and my plan is to make it the _supported version_ if possible. It has some problems yet with C++17 but I'm confident they'll solve everything in the meantime.

[DJuego]

Amazing. @skypjack. The open-source community should feel very, very lucky with you and your terrific ambition. 🥇

[Kerndog73]

The future is bright

[OvermindDL1]

For note, if you want a restricted reversible packed string feel free to use my atom type:
https://github.com/OvermindDL1/OverECS/blob/master/StringAtom.hpp

It could use some cleaning perhaps and the ASCII set I chose was useful for my use case, it could be changed, but essentially you just do "BLAH"_tightatom32 or "Bloop"_atom64 or so. It is constexpr ran at compile-time to output either a 32-bit or 64-bit integer. tightatom32 I think was restricted to 5 or 6 chars and atom64 returns a 64 bit integer with 10 chars, though I think you can get 12 chars if you make a 'tight' version of atom64 (basically treats upper and lower case the same), see the table in the source. They are quite useful to use in simple Event handlers (I used it in a scripting event system in my old ECS-based engine), especially as you can do things like:

switch(event.type) {
    case "UPDATE"_atom64: ...
}

Or things like:

if(event.payload["BUTTON"_atom64].as<unsigned short>() == 1) ...

And so forth, it is like a constexpr string hasher, but it is limited in length, in character set, but it is entirely reversible like in:

deatomize64(event.type)
// returns an std::string of the event name, but honestly I probably should have
// let it take in a character array of length 11+ to fill in as an option, there
// are many ways this could be fleshed out

Feel free to use under whatever license you want, I think I left it as MIT or BSD or something by default. Using it instead of strings in the event system gave me quite a noticeable speed bump for obvious reason. But these are useful for length limited useful things like event types or looking up in a variant payload or something, and they are always the same value regardless of system, no flyweight string issues like synchronizing across a network or saves or anything like that, they 'just work'. I don't really see this pattern being used anywhere, and I did the conversions via the C preprocessor before C++11(14?) came out and I converted to constexpr (wow what a code reduction...) after that. No point letting it die after existing in some form or another for 15+ years. :-)

If taken then I'd recommend adding more error checking (I only ever used it for personal things, wasn't intended for distribution, hence why it is a bit ugly) to enforce length or whatever else (I just truncate it currently) via a(n) (static_)assert or so.

[AquariusPower]

do you think it will still work with UE4? found this project from: https://forums.unrealengine.com/development-discussion/c-gameplay-programming/1449913-implementing-ecs-architecture-in-ue4-giant-space-battle

[vblanco20-1]

@AquariusPower i made that. The "working on ue4" part is not a thing this library does by itself. I just wrote a way to bridge beetween ue4 blueprints/actors and pure Entt simulation. Should work by just updating the syntax until it compiles.

[skypjack]

@AquariusPower I confirm that it should work with UE4. I don't see any reason because it shouldn't actually.

[AquariusPower]

@skypjack cool thx! I just wanted to be sure what version I should use because I was away from cpp for a long time, now I came back and getting accustomed again to it, and will start a project in UE4 and wanted a good independent "internal data base" (ECS), as I could even wrap it and run thru jmonkeyengine3D (java) or even in text mode just to stress test my ECS logic xD

[vblanco20-1]

@AquariusPower Doing what i did is a very bad idea unless your game just fits the "simulation" mindset extremelly well.
If you are making a strategy game, or a simulation game (think sim-cities), then doing it would work great. But the main issue is that communicating from unreal into the ECS and back is a massive pain, and can be error prone, so its not recomended. Also you completely lose basically every single ue4 editor tool, and just using ue4 to display your simulation.

Ive used it for a music game, but becouse it was a very good fit. https://www.youtube.com/watch?v=6-cei4Itsvo
In here, the music note simulation is done enterely in the ECS, and i just use UE4 for display purposes.

[skypjack]

@vblanco20-1 that installation uses EnTT under the hood?

[vblanco20-1]

@skypjack It does. Im using the ECS to drive the note logic. In the video its showing only basic stuff, but i have several other note types and mechanics.

The collision is done in normal unreal engine collisions, and it sends a "entity event" into the ECS (creates a new entity with the collision information, and then several systems look at it).

For the display part, i have a component that links a UE4 blueprint to an ECS entity (same as in the space battle), but im not creating the blueprints for the notes until they get closer to the player. I have a system that looks at the "time" of a note, and if its below 5 seconds the note spawns its correct display blueprint and starts doing the positional logic.

To handle the song beatmaps, i wrote an editor that can edit what note type to use, and some values. This gets written into a JSON file, and then i load it into unreal. The loading just creates the new entities and initializes the components according to the json, and its loading every single note on the song at once. Im not doing any kind of streaming, i just create the ~500 notes at the same time and let the ECS perform the simulation for their movement and logic.

[skypjack]

Wow!! These are the kind of things that we should put in the EnTT in Action part!! :rage:

[AquariusPower]

@vblanco20-1 To me, the feedback of physics engine is essential, so I cant control the positioning too much from within the ECS logic. I dont intend to use too many entities, despite I would like to tho (far away non visible ones can be positioned, visible ones not). But.. ECS will always be the base, if UE4 is not good for it, I will still use ECS and some other randering engine if I have no choice. UE4 is the current cheapest best quality choice I found nowadays in CPP for indie development, PC, android etc, and I am on linux. :)

[skypjack]

Time to close the issue. It seems that the few users of EnTT are both excited about the new version and willing to use it, so... :-)
Branch v3 contains the work in progress for the new release. Feel free to use it, test it and eventually open issues to fix bugs before to release the new version.

Thank you all.

[DJuego]

Hi! Currenty the 'published version' of EnTT (GitHub version) is 2.7.3. Maybe the time has come to promote it to 3.0? :-)

DJuego

[skypjack]

Good point @DJuego I'm working to allow users to push the registry and the other classes across boundaries, so that dlls won't be a problem anymore on Windows. Then it could be the time to cut a new release actually.