As of UE 5.6, SmartObjects are not well supported for Client-side use in a Networked game. The subsystem only runs on the Server, and much of the data that the client would be interested in is contained within the subsystem itself (i.e. FSmartObjectRuntime). This makes it impossible to, out of the box, use SmartObjects for Players in a reasonable way without doing a lot of custom networking to send object state to the client.
I was curious if there were any plans in the near future to add better feature support of SmartObjects for client side use in a networked game?
I ran into this as well. My immediate reaction was “why the f”, but there is so much state that would need to be networked if the entire system were also available client side that I’m now of the opinion that it’s better that it isn’t client side.
To account for this I just have our server side interaction code query the Smart Object subsystem for usable slots and replicate that to the owner of the pawn, and they can interleave that amongst the rest of the client side interaction code where appropriate.
Consider that networking it would introduce race conditions where a client can either claim slots that the server will reject, or any client side claims would have to be async to ensure server agreement. This would cause significant downstream API effects. When the alternative is such an easy workaround of performing the query server side and replicating the results, I can understand why they made it the system a server only system. It allows them to avoid a lot of complexity in the system for what should ultimately be a server authoritative system. You also have to keep in mind that the smart object queries uses features like the navmesh, which most often simply isn’t available client side.
We do not have plans for adding more support for client-side Smart Objects at this time. I have checked with our FNBR and Lego FN teams which both use Smart Objects for how they are handling this. They use an approach very similar to what has already been described here. FN uses a custom component derived from the USmartObjectUserComponent as well as various custom structs for slot data, SO client data, and SO server data that is replicated.
Additionally, we have been working on adding some more support for Smart Object player interaction via the GameplayInteractions plugin. Work on that has paused to tackle some higher priority issues, but we do intend to return to that work. I do not know when that will be added, but it is not currently in the plan for 5.7.
-James
Yes, I was able to do something similar, but I have concerns about how well this scales as number of objects and number of players increase. It seems like it would be much better from a performance standpoint to allow the individual client to make queries against potential SmartObjects in a scene, over the server making those queries as well as networking bandwidth of having to replicate the data from that query every update
Remember it won’t be every update. It’s only going to replicate when it changes state on the server side, so when you first step into(or leave) a valid query radius or whatever, or as you move around and it flips state from one result to another being a better candidate or whatever if there is a distance based prioritization to the query. Certainly nothing that changes every frame. I think it would be difficult to implement this in way that is problematic for bandwidth unless you do something crazy like send RPCs every frame. Small data, infrequently updates, owner only, amounts to a very small replication overhead.