more and more i see UObjects being used for simple tasks and i love it for the modularity but i’m curious about the costs.
for a simple example look at payloads? these could be getting created/destroyed often is this not potentially expensive?
same with Tasks like AIMoveTo or maybe even behaviour tree, are these created/destroyed constantly or somehow reused? i assume StateTree and Mover 2.0 tasks are all UObjects as well?
finally looking at GAS they use ASyncTasks/UObjects just to create clean bindings.
ie ListenForAttributeChange, seems this is just an encapsulated Event Dispatcher, i love it because its modular and clean but is it worth the cost?
why not just make the whole attribute a UObject and then you can bind directly to the Ref, one Object instead of many.
in short this is exactly what i’m thinking to do, why not just make common functions UObjects so i can reuse them (essentially what a GameplayAbility is) why use crappy broken blueprint structs when i can just use a dynamic UObject?
Open the SizeMap utility for blueprint. An empty UObject will take 1.6kb of RAM…
I created a replication system for widgets that created a separate actor for each text block, image, widget switcher and other basic widget elements so that parameters would be replicated through these actors.
For my test I had about 5000 actors and there were no issues with frame rate drops or network throughput (unless you change ALL widgets at once, which in reality doesn’t happen (usually)).
Based on this, I can say that the overhead costs are quite modest compared to the convenience and speed of development. At least for most tasks.
thanks i’m aware of SizeMap and i know they’re as cheap as they come but
most importantly im curious about the cost of constantly creating/destroying them say with the payload system
also say using a UObject to listen for events rather than binding manually.
i should add replication, is having 20 Objects replicating as subobjects much more overhead than using say 1 Object/Component with structs (relevant for advanced inventories and attributes)
You can record a profile for this. If you do not create thousands of objects in one frame - then it be costs picoseconds.
I did something similar. An actor component with a delegate and a special node that waited for execution, or could report that the event had been called earlier, and it worked (and works now) great.
If this starts to create problems, you can use the PushModel to manually control the sending of network packets.
But as I mentioned above - even with a standard system running on a timer - I have never had any problems with this in my tasks.
Im inclined to agree with you since Epic uses this system themselves, i just didnt want to get 500,000 UObjects deep and find the system breaks down and have to start again ha
but on the flipside, if this is the case i’m surprised its not used more