I have each client running its own UI, because obviously every client wouldn't need or want to see if some user brings up their options menu to change their volume or something. But I'm not sure how to handle the case when the UI depends on game state information stored on the server. For example, I want a user to be able to bring up their inventory and equip gear. But the user's inventory is on the server, so I can't figure out a way to do this without the client having some degree of authority.
How To Handle User Interface That Needs To Read/Write Server-side Data
Operations should be asynchronous and hidden behind UI animations that can mask typical network latency.
e.g., opening the inventory requires sending a request for inventory and receiving the list of data. The animation that includes the button reacting to the click, the inventory opening, etc. should cover up to that latency.
You also of course can cache this data on the client. The client only needs to ask for the full inventory once. Possibly just when logging in. All inventory changes there on out can be sent as notifications to the client.
Lastly, the UI needs a clear way to handle rejection. e.g., if the user sends a request to consume an inventory item but the server decides that the item does not exist, communicate this to the player. Again, animations can be key. If the "consuem potion" animation entails a few moments of the potion tipping over, the successful consumption animation can play after the first one is over and the client has received confirmation, or a different animation (illustrating the potion disappearing, returning to original state, etc.) can be played on rejection.
Key part is to be asynchronous. The client asks the server to do something on its behalf and the server verifies and then confirms or rejects. The client has to wait during that time. Just pausing is lame, so hide the pause with animations.
e.g., opening the inventory requires sending a request for inventory and receiving the list of data. The animation that includes the button reacting to the click, the inventory opening, etc. should cover up to that latency.
You also of course can cache this data on the client. The client only needs to ask for the full inventory once. Possibly just when logging in. All inventory changes there on out can be sent as notifications to the client.
Lastly, the UI needs a clear way to handle rejection. e.g., if the user sends a request to consume an inventory item but the server decides that the item does not exist, communicate this to the player. Again, animations can be key. If the "consuem potion" animation entails a few moments of the potion tipping over, the successful consumption animation can play after the first one is over and the client has received confirmation, or a different animation (illustrating the potion disappearing, returning to original state, etc.) can be played on rejection.
Key part is to be asynchronous. The client asks the server to do something on its behalf and the server verifies and then confirms or rejects. The client has to wait during that time. Just pausing is lame, so hide the pause with animations.
There's a difference between "authority" and "knowledge."
The client can know the entire inventory of the player.
The client can display the entire inventory, and let the player add/remove items; it can even show the user which things happen in response (can't hold both a shield and two-handed sword at the same time.)
When the player says "commit," the client sends a message to the server, saying "this is what I want to change about my equipment."
This is not quthoritative -- it's a request.
The server then verifies whether that request is valid (the objects requested are in fact owned, the player class is right, there's no mis-match between the objects, etc.)
Then the server applies the requeted changes, and sends new information to the clients that need to know.
So, it's totally okay to perform and show the result of rules on the client. If the client agrees with the server (no bugs, no hacking) then the end result from the server will be the same. If the client is hacked, or i there is a bug, what's shown on the client will not match the server outcome, and the server's state update will tell the client what it should show, instead.
The client can know the entire inventory of the player.
The client can display the entire inventory, and let the player add/remove items; it can even show the user which things happen in response (can't hold both a shield and two-handed sword at the same time.)
When the player says "commit," the client sends a message to the server, saying "this is what I want to change about my equipment."
This is not quthoritative -- it's a request.
The server then verifies whether that request is valid (the objects requested are in fact owned, the player class is right, there's no mis-match between the objects, etc.)
Then the server applies the requeted changes, and sends new information to the clients that need to know.
So, it's totally okay to perform and show the result of rules on the client. If the client agrees with the server (no bugs, no hacking) then the end result from the server will be the same. If the client is hacked, or i there is a bug, what's shown on the client will not match the server outcome, and the server's state update will tell the client what it should show, instead.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
