Hello,
What are your thoughts on the best practices for developing UI elements that interact with the world server? I am of course talking about non-client modifications where new packets would be understood or generated by the client.
Is there a preferred way of doing this under TC? I worry to a degree that there might be a impact that I would not see in retail addon development with using chat / channel communication. Though I see people using plenty of raid addons, I am not aware of much server admin communication on what impact that has.
I guess there are three ways of communicating such things:
[ul][li]The on demand polling of the server (via .dotcommands) and similar for communication seems to work fine, like gmgenie and such. And if the user doesn’t have the client ui addon, well there is always manual commands perhaps.[/li]
[li]For character 'realtime-ish elements are added, a chat response (like above) where the client gets a formated chatmessage that the addon intercepts. I saw a server review on youtube where the characters have a quaint sustenance / food requirement, similar to the hunter happiness petui, where the characters have to maintain food or there is some negative effect. I can imagine that the server deploys a required addon that gives the ‘sustenance bar’ and it merely updates when chat messages to the character are made (hunger: $level) and hides that from the player. This is read only, as when the player eats the server likely (hunger: $level) soon after, like hunter pets.[/li]
[li]Use of worldchannel for some server pushes and posting serialized messages into it for the non-on demand / periodic polling. I imagine there that some work could be done to cut out channels and manage on the server side if needed (such as a dynamic guildchannel).[/li]
[/ul]
I seem to be working fine for myself with ~50 players or so, but I am not sure what scaling would look like or if there are any method / tricks in TC that people have developed in the last ~decade that can make this easier.
Thanks
afaik @Rochet2 did such things.
I have been working on a server-client communication system and seems some people have been using it: http://rochet2.github.io/AIO.html
However I have not made any stress testing and people have not reported of issues or their own tests or such.
Below are just some thoughts of mine about this.
If I think about server-client communication, the only way I can think of is through chat messages - this is what commands and such all are.
The recommended/preferred way is probably what works best for you, because in the end they all use the same underlying system for chat.
So you pretty much cannot change this and it doesnt really matter if you use commands or addon messages or whatever.
If chat scales, then the server-client communication system would scale as well. If chat does not scale, then the gameplay would suffer anyways since chat is in use all the time.
If the communication system is the issue then you can try to avoid sending chat messages through design and using caches in the server-client communication system, UI code and server systems of yours.
For example think about a menu that the player can use to spend some points.
If the menu button sends a message to server and the player clicks the button and the delay to server and back is 1 second, then the UI will feel really slow (pressing a button will take a second to take effect) for the user and multiple messages keep being sent back and forth between the server and client if the button is spammed to spend multiple points. A better way would be to let the player spam the button and then click to save the changes. If there were changes, then all the needed info is sent to server. The server then verifies the transaction and either rejects it or accepts it. The save button could be gray while it waits for the confirmation. This way only one message is sent in each direction even if multiple points are spent and when spending the points the player does not need to wait for the communication to happen.
Think about how to avoid communication and what all you can do on client side.
In the cases you listed there is little you can do.
In all of them you seem to just send a chat message to the player or to the server.
All of them also seem to require the communication to take place as it is either a request to the server or an update/sync from server to client.
You could make the periodic updates less frequent through trying to estimate on client side what should happen, but that probably should be done only once the system is an issue.
If you feel that some part is spammy, try to think about how to use client side resources for memory and calculation to your advantage and delay the communication to the last moment as a big chunk.
The best thing would be to leave the optimizations for when they are needed. However there are no good ways I can think of to track the system performance.
Thanks for the advice and commentary, much appreciated.