Perhaps because I didn’t explain much but only bring up topics. I assume the post is going to follow a common way of storing data using Unreal Engine’s DataTable.
Unreal will typically bake all your little files into one bigger file when it packs up the game
As jwatte said, Unreal Engine already bake things in build. Files would already be condensed for you. You wouldn’t want to put every data in a single DataTable would you?
I was wondering whether it is more optimal to store all categories of things in one large file, or would it be quicker to load the stats from multiple, smaller files in a folder?
If DataTable is implemented so that a single structure would hold all the possible variables like stats/asset_filepath/texture/material/mesh/icon… It would not be good. Would a weapon use variables from armor structure?
It is bad to pass around for all the copying structure do. When an array/map/list of these unpredictable structures are in memory, that’s why I bring up the topic of “CPU memory cache” and “memory alignment.”(hope you understand where I am coming from)
Back to the post.
I am currently starting off making a game, with large amounts of things that can be attached the player character, split into a small number of categories
I’d say split your data structure as how you’d categories them. And separate assets from data. Like you have Weapon/Armor data with their own structure. But have GearAsset data with common variables like Mesh/Material/Texture in the structure. Add an assetID to your Weapon/Armor structure so that they can find it in GearAsset. Load these assets separately and asynchronously if possible.
Should I be using data tables or data structs? Does it even make a difference performance difference?
DataTable is a kind of data structure. It has more going on as it supports/follows UPROPERTY(). Like if you have a DataTable with references to some texture assets, the assets would be loaded into memory every time you use that DataTable. That would be a performance hit unless you use a soft reference.