Performance UObject vs AActor in Multiplayer Survival of Items (Food/Weapons)


I’m implementing a Survival Game. My idea is a 100+ player multiplayer large map with multiple hundreds of items. I’m implementing an inventory right now. I’m not new to programming, but to UE4.
I watched/read some tutorials online about inventory systems and came across someone who suggests uobject based items instead of aactors due to performance reasons. As I dont want to run early in performance issues and want to do a proper start I wanted to ask if this is still an suggested way of implementing it. My idea is that items can later on be stored in boxes aswell. So items per server can easily rise to maybe multiple thousands.

One thing i realized is that UObject needs self implemented replication. And items cannot be drag’n’drop spawned in the editor.
I think this shouldn’t be the problem.
But when i think of weapons, which a player carries in hands, drops on ground and so on, should this be AActors? Is there any advantage using actors? Physics, Collision…

Are there any other performance advices regarding items/inventories for such a game?
Thanks for your help!

Kind regards!

If a large number of objects are supposed to be in the camera, then, probably, the best idea for visualizing them would be to use Instanced Static Mesh components, and to interact with them - their invisible actors-collisions. And it is ISM, not Hierarchical version. Because HISMs do not work correctly if they are deleted / changed due to the organization of their LOD groups. But this is a fairly complex approach, requiring serious tracking of the ISM ids for their interacting actors. Otherwise, of course, a simpler method is just actors each with their own mesh. But this is all about draw calls count question.

I’m confused … AActor is a subclass of UObject. AFAIK you cannot place a UObject in a world. It must be an AActor. UObject has no visuals or transforms?

UObject Hierarchy | Unreal Engine Documentation

I think he meant storing data of inventory items as UObject. Although, in my opinion, UStructs are better for this.

Thanks for all answers!

May you explain why you think UStructs are better or how exactly you mean that?

I saw examples in which people use UStructs in the Inventory for saving a TArray of Items (UObjects)…

My thoughts so far: My Items are of UObjects (with implemented replication), the Inventory is basically a TArray of UStructs consisting in a simplified version of UObjects Item and int number.
But if a player drops an Item frrom the inventory to the ground, this Item, for example a weapon, needs to be with an mesh and maybe with a collision. So far I know, the item needs to be an AActor then. Correct me if I’m wrong?! If so, my biggest concerns now is how to solve that… Create an AActor out of the UObject if he decides to drop it and place it in the world?
If he picks it up again, then I delete the AActor and just add the UObject to the inventory list again? Same way if he decides to put the weapon in his hands.

Any thoughts?


Weapons should be from AActors This is from the Actor.h file > class ENGINE_API AActor : public UObject all AActors extend UObject.

Because structs is meant to be a simple data holder. They are the fastest and more stable. UObject is subsystem for some more complex objects like Actors, but all depends on what you want.
You may not separate such concepts as inventory cells and items at all, but simply fill or clear cells structs - this will be the simplest solution.
For the world items, yes, the simplest way is the actors. Although there may be other solutions here - again, it all depends on what you want. You can implement a virtual grid-array with items data and render their mesh instances, if you don’t need physics, there may be different way how to do it.