EnTT: Gaming meets Modern C++
I was looking at EnTT's API when building a little toy ECS of my own in JavaScript. Since I'm working in JS, I haven't really tried to copy its internal architecture since it doesn't quite make sense for a higher-level GC'd runtime, but I think the public API was a really handy reference for the kinds of things a practical ECS needs to have. It's a really impressive and robust project, and the documentation is super thorough and worth a peek if you have any interest in game architecture.(slightly off-topic, but I'm excited to have a venue to ramble a bit about this:) ECS is really cool, and I'm excited about using it more for my games. The "cheap" (de)serialization by moving all state into pure, data-only components is really fascinating - I've been playing around with building networked multiplayer games for a while now, and I'm currently experimenting with rollback netcode.A key part of rollback is saving your state every frame so you can load it if you need to roll back, and ECS makes saving/loading easier to reason about, since you can "just" grab the components and their associated entity IDs and load if needed (EnTT, for the record, has an API for this[1], though they leave the actual (de)serialization up to you). Of course, JS's lack of a memcpy equivalent makes this much harder than what you could do in C++, which has lead me to experiment with immer[2] in my ECS, which uses structural sharing to avoid mutation, so you can get a "copy" of your state by just keeping a reference to it, as future updates will make new objects. This, of course, theoretically could make a ton of garbage (e.g. updating your position every frame would create a new Position object every frame), which is not great for high performance games. I'm not sure how bad this will be in practice - JS GC is relatively smart and fast these days, but I haven't tried doing much beyond little pong or platformer demos yet. I'd also imagine that, like, doing a deep clone of my state tree every frame (or doing the whole JSON.stringify/parse dance if I stick to primitive values) probably generates just as much garbage. Maybe if I could integrate immer with some kind of object pool it'd avoid these issues, but I have no idea how useful object pooling is in practice in JS...[1] https://github.com/skypjack/entt/wiki/Crash-Course:-entity-c...
[2] https://github.com/immerjs/immer