Download

Question: Is it bad to network visual UI interactions?

I’ve heard:

1.) It makes the UI feel unresponsive - Every drag and drop would need server communication → lag
2.) Bandwidth | Why network VISUALS?!
3.) Vulnerbility for bugs. It would require some piece of code to keep track of a dragged item. Now when for example the user crashes or closes the game in any other way, on every exit point we would need to handle if the user was dragging something or the item will be lost in nirvana forever…

Any insight guys?

IMO Responsiveness is paramount for UIs. So, yea, adding a network delay to all your UI seems like a non-starter. Can you go into any detail on why you are thinking of doing networked UI?

@PixelPefectPolygons - The only way I could see this being needed, would be for network loaded images. E.g., customizable images. Nevertheless, they should be loaded before the UI is built, and I mean, fully loaded. Hence you shouldn’t expect performance drops in this case, assuming que code was properly built.

You can direct UI behaviour by using RPC to trigger events, nevertheless, the UI itself should be processed at the client.

Our team was having a debate about how to go about incorporating some functionality. They’ve managed to come a resolution with your help so thank you ExtraLifeMatt and Horus very much for your insight. :slight_smile:

I will be more specific… because thats my idea…

So we have an inventory system in OGW… Multi sized, grid inventory, subitems are stored etc…

i did whole inventory lightweight as f**k, our inventory struct only store ItemIDhandler, quantity, isreserved, isdisabled.
Because of multi sized inventory, inventory operations are handled by server… Simple 1D array are “visually” converted to 2d Grid.

Every else item data like icons, item sizes, dropping mesh etc. are stored in datatable…

When player start drag in inventory (we saving from slot to payload), actually we dont do anything just temporaly hide item icon…
When onDrop happens on other inventory slot, we requesting an item move… with lightweight data… (from slot, to slot)

Server do inventory operation (move) and inventory array (with lightweight struct) gets replicated, then inventory widgets/icons will be updated with onrep functions.

Actually that system are good either, im fine with that, but i got a new idea…
What if we do forward “removing”

Explain:

If player start dragging, we sending a server request (with from slot value) to remove that item from character inventory array and also ask server to save removed lightweight item data temporaly (itemid, quantity etc.)
After player finishing dragndrop, so he actually dropped visual on some slot in inventory, we sending a server request to add item to that slot…

At this point server validate saved item data and adding item back to character inventory. Array gets replicated and visuals are updated…

I think in this case we always getting correct array data, items are correctly removed…
Bad part what i know yes, instead of using one RPC to handle moving for example we using two rpc and array get replicated twice…

At least dragndrop widget on destruct can send a request to readd that item what we saved before their original slot…

I know bandwith cost of this, but for me dont seems so bad idea in a game.
other possible “bugs” like what happens when inventory filled in this time can be handled i think (drop item to ground or something)

and never ever i wanted to replicate visuals and dragndrop communications…

Someone told this is a bad idea, bad design.
What do you think?

Is it really overhead networking and are a big resource of bugs?