🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

ECS and entities that do not need updating every loop or even rarely.

Started by
1 comment, last by hplus0603 4 years, 6 months ago

I have been using component based design a lot and I like the idea of implementing a complete ECS for my game. But I have some problems connecting the dots. I am currently playing around with ashly and it seems all entities need to be updated each turn and I guess that is just how a ECS system works. I come to the conclusion that I literally have a ton of objects that do not need to be processed every turn and that would be a waste.

I already combined my tilemap with all the tiles as a single component and a separate tilemap render system to render it out, since updating each tile in a 200x200 map is costly, even if I only draw the ones on screen it needs to iterate the list. In my tilemap render system I just have an 2D array and know exactly which tiles to draw depending on the position and frustum size of my camera.

Now I want to implement items but my game can have many items on the map, many many thousands of raw resources and if the player is a hoarder type of player this can get out of hand if these also are processed. So again I am reverting to my old ways where I would have a basic item with a lot of fields, or a list of components but outside of the ECS. My tiles will have a list of items they hold and only one item needs to be rendered on top of the tile texture. If a character wants access to items on the map it just needs to know the tile coordinate and I can instantly spit out the list in my 2D array.

So am I implementing things incorrectly and do I have a fundamental miss conception about ECS or is ECS just not viable for my game? It seems nice for my pawns which can be a couple hundred and probably also nice for bullets and other effects that need updating every loop but a Tile or a Item that is just sitting somewhere it just seems a waste.


Advertisement

Sounds like you need to have a set (or list) of "entities that need update" that doesn't contain "entities that don't need update."

When it comes time to update, then iterate over the list, updating the entities in the list. Presumably the function "setNeedsUpdate()" on the entity would add itself to the list (if it isn't there already,) when it's true, and remove itself when it's false. Also, remove itself in the destructor, if it's in the list.

For things that need updates only seldom, you could have a separate "one shot update" list, of entities that have been requested to be updated once. On the next update, make a copy of this list, clear the list, and run through the update for those components. If they need more updates, they can re-add themselves to the one-shot list. Similarly, you need the ability to remove entities from this list in their destructor, if needed.

A more mature implementation of entity/component systems actually use a separate "subsystem" per feature, and the "component" is really whatever is native to that subsystem -- a physics body, a particle system instance, a sound mixer, or whatnot. The "entity" is then nothing more than a struct containing the pointers/IDs of the components in each subsystem. At that point, each subsystem can update itself, perhaps in a different thread, and certainly using a data-driven layout where "all particle systems update as one" for implementation / cache efficiency, and fewer pointer dereferences. (See also: Mike Acton's "typical C++ bullshit" slides :-)

enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement