I use some generic struct FDataStruct to keep track of all character data: name, HP, inventory, and so forth. I’d like to curate the data for every character in the game in a single, centralized TArray, and only give characters spawned in the world an int ID they can use to find their character’s data in the list.
The easiest way to manage IDs seems to be to make the index of the array in which a character’s data is held their ID, so you could access it from anywhere in the game by calling LogicActor->CharacterList[ID].
What I’m wondering is, is there any reason not to do it this way? Assuming I stored a copy of the index inside the data struct (so I could rebuild the list if an index accidentally gets deleted), I’m not seeing a downside to this method, but as I’m self-taught and still a very basic programmer, incredibly obvious stuff has a habit of not occurring to me.
Hmm, are data tables really appropriate for runtime data though? This isn’t something that will be consistent, characters are constantly being added, referenced, and/or futzed with as gameplay proceeds.
There’s no reason to do that, which means you probably shouldn’t do that. See KISS principle and YAGNI .
You’re are adding unnecessary layer of indirection, and you’ll need to use it everywhere, at any point where you’re trying to do anything with your character’s data.
Frankly, I don’t see the point. You haven’t listed any requirement that would require this kind of design.
Im interested in this question as well, what you guys can say about datatable and structs in it.
Lets say i need to handle data table 300 rows, each with 5 structs and each struct is a struct
The main reason I’m doing it this way is because I need to simulate interactions between NPCs even when they’re not instantiated on the map. I basically have a high- and low-detail behavior system, the high detail is a fully-fledged behavior tree that only runs on characters spawned in the world and visible to the player, and produces behavior that can withstand player scrutiny. When they’re not nearby they shift into a kind of dumb mode, where the only things that get calculated are stuff relevant to gameplay.
Since aspects of my game require pretty granular simulation even in low-detail mode, maintaining a consistent, centralized register of character data seemed like a much simpler solution than separately maintaining a list of characters in low-detail mode and a component/local data reference specific to characters spawned in the world.
looking forward for solution about first part of your message, i want to make exact same thing, runtime simulation for a LOT of objects based on some of their parameters and easiest way what i can see for it, is data table driven solution instead of array of object, which would make a lot harder to find exact object in the array.
Something that tiny can be simply loaded entirely into RAM as TMap, TArray, set or anything else.
Even in that case I wouldn’t make every npc access table by its id. Mostly because global npc record generally will need less information than spawned actor, “table” design can change later and if actor is closely tied to it, it may lead to mess.
Make them pull data from the table on spawn, and make them sync relevant data to the table occasionally. There’s no real need to make every change to through global table.
Your proposition makes sense in one scenario: when multiple actors have same “ID”.
