geneotech
Joined 3 years ago
Karma
101
Submissions
11
Member since
Jun 25
Recent submissions
Comment · 3 years ago
Comment · 3 years ago
Love to hear it! Sorry about the MacOS incident, I haven't launched it in ages as we play on Windows and Linux pretty much 100% of the time, I'll see what I can do to fix it :)
Comment · 3 years ago
Oh, thanks a lot for the catch! Fixed it immediately.
Comment · 3 years ago
Indeed, such a rigid struct-based "ECS" is basically how most non-ECS games do it, but using components to compose game objects, if you say put them into std::tuple, makes it easy to to later call e.g. a generic lambda only on vectors of objects that contain given components. This makes for an excellent statically polymorphic code that doesn't care about what particular type the game object might have (is it a character? is it a tree?) as long as it has e.g. physics + health. In my 2013 article I also describe how to apply the same concept if we don't hardcode a specific collection of "structs of components", but add/remove components to entities at runtime.
Comment · 3 years ago
Thank you! The approach you describe is indeed the "final form" of a brutally data-oriented ECS, but my method is a bit simpler - e.g. if the game has:
struct player { components::transform transform; components::health health; };
struct box { components::transform transform; components::physics physics; };
Then my ECS simply holds a std::vector<player> and a std::vector<box> rather than having a vector per each type of component. I also use the integer identifiers like you describe but with a twist - there is one more indirection involved so that deleting from the vectors does not invalidate existing indices pointing to vector elements. It's still exactly O(1). See the section on the Memory pool in the game repo's README.
Comment · 3 years ago
Hey there, a little clarification - I don't claim that I came up with ECS itself, only a particular implementation of it that is very memory efficient, and Unity's patent concerns a specific implementation as well - sorry if that was a bit misleading. As for the title, I just couldn't resist making the pun, maybe you're right though that the packer should be talked about separately.
Comment · 3 years ago
Thank you! That's interesting, I did write an article on SE about ECS back in 2013, but I think it's the first I ever published a proper piece on networking - I do link to an important Glenn Fiedler's blogpost when describing my deterministic architecture in README but just in case I'm not him, I hope I wasn't too misleading :)
- I have done various gamedev jobs over the years, the most recent being gameplay programming for this minigame in PUBG: https://www.youtube.com/watch?v=tSP5P0QGWa4 I managed to successfully invest my savings too which let me focus entirely on Hypersomnia.
- Yes, I'd love to release on Steam before 2024.
- For now there is no persistent world at all, I just mentioned it as a teaser for where the game might be heading if it becomes successful.
- Rebuilding the physics should not at all shift positions. What is rebuilt is merely the "hot state" like contacts and trees - the only moment where hot state matters is during the process of advancing the simulation from one state to the next, it does not influence how state is later rendered etc. The only impact on the existing players could be a single framerate drop in case the physics world to be rebuilt is massive, but in practice all our maps are still rather small, best suited for 3v3 matches.