I’m sure there’s some kind of micro-benchmark where this matters.
Also, if you’re building a massive multiplayer game with a thousand people all firing automatic weapons at the same time, this may matter.
However, it feels to me as if you’re way over-optimizing something that probably doesn’t matter, and doing it way before it’s time to worry about this level of optimization.
This is the kind of optimization that was meant when Knuth said “premature optimization is the root of all evil.”
It’s true that choosing the correct algorithm is important! Scanning through every actor every frame to find something, when you could just have cached a reference to that something, is a bad algorithm, and should probably never be used in the first place. Selecting the right algorithm, is fine design work, that you can and should do early. But, optimizing struct sizes for cache behavior, only matters if you have literally thousands of them, and scan them all every frame.
Optimizing the struct layout for each particle in a particle system? Abso-freaking-lutely!
Optimizing the layout of the inner loop of a DSP function for a procedurally generated sound? Probably a good idea!
Shaving one cache miss off of something that maybe happens five times a second? Nobody will notice the difference, on any machine that is at all capable of running Unreal Engine. Even if you fail to do this optimization ONE HUNDRED DIFFERENT TIMES and it happens EVERY FRAME, you won’t notice one hundred cache misses per frame. The cost of one cache miss is 0.08 microseconds. The cost of one hundred cache misses is 8 microseconds. 8 microseconds at 60 fps is 0.03 fps difference.
As long as you choose a path and stick to it, you’ll be fine. The two paths are:
- You’re a one man band. You will never be able to develop enough content that a modern computer will worry about it. Load it all in RAM and call it good! Ship a game, be happy!
- You’re extremely worried about initial load time, so much so that you change all your asset references (icons, animations, sounds, …) to be soft references, and load them on demand. Your game loads slightly faster! Ship a game, be happy!
Also, the way that sub-classes are done in Unreal is generally by creating blueprints of the subclass. Each blueprint has the customized ammo/fire-rate/sounds/meshes/icons. An actor blueprint is a class, quite physically. Thus, you develop all your guns as blueprints that derive from your “Gun” base class. (Which may also be a blueprint, or a C++ class.)
Then, in inventory, you have a struct that has a soft class reference to the blueprint of the item. The inventory struct should also contain a soft asset reference to the icon to show in inventory, and the user visible name as string. You don’t need to add parameters related to the gun behavior, unless you want to show all of that in the inventory, too.