Using pointers to keep track of ents and components aren't great, and using ID's aren't great either.
Pointers:
pro: avoids having to look through a global structure to find the object you want
con: every single little thing MUST BE a pointer. If you don't do that, then you can't shift things around, or else they become invalid. You can't just pass around mem addresses to stack objects.
IDs:
pro: can be smaller than a pointer in size
pro: easier to check if it exists (if it doesn't exist, it ain't there)
con: hashtables "are O(1)", but constantly having to look through hashtables is for a GIVEN more expensive in space or time (load factors, etc; also default c++ map is tree based)
Both:
you have a little bit of both pro's and a lot of both cons
Alternative:
have ID's, but map them directly to a position in a vector (potentially fixed maximum size) of components, ents, etc.
when you delete an ent, add the position to a list of "free positions" or something (use a ring buffer)
once in a while, reshuffle your ents (you can reduce the "maximum position of an ent" or something; a variable that you should be keeping track of, as it's your proxy for "array size")
maybe implement arraylists but not necessary
I think this alternative could be better. Of course, this depends on #3 as well.
VjiaoBlack
commented
6 years ago
Using pointers to keep track of ents and components aren't great, and using ID's aren't great either.
Pointers:
IDs:
Both:
Alternative:
I think this alternative could be better. Of course, this depends on #3 as well.