> This brings up an interesting point --- the smarter the client is, the > less packet traffic is required. i.e. if the client knows a good deal about > the mud, it can do a lot of the work that the mud does now. This is not without > risk. If the client knows a lot about the mud, then it can be hacked > and that information used to the players advantage. This was a common > problem when I used to write netrek code. You wouldn't believe the hoops > we used to jump through to verify that the user was using a clean client. > The other problem with a client is that it forces your users to get > (and keep the most current version of) the client, something lots of mudders > may be unwilling to do. Well, enough babbling... the whole point is that > making a useful client involves more than you might think... and a simpler > client turns out to be a fancy text editor, perhaps not worth the trouble. This is one of the reasons why I would love to write a diku-smart client. One that can act as a 'slave' in a sense for certain functions that a mud would normally process and then output to the character. Examples: * for muds that have an actual color parser that will take a string such as "`b my string" and actually fill in the appropriate escape characters (`b signifies a paticular character) locally, instead of having the mud do it every time send_to_char, write_to_q, etc etc are called. * client handles things like gethostbyname() upon start, then sends it to the mud. yeh, i know a glaring problem can happen by someone packet spoofing what ever address they want. * have all editing functions handled locally and then sent to the mud. user can use their local editor to format, spell check, and edit a string (would be great for olc). * client handle things such as arrow keys, larger command histories, control sequences (clear screen, erase word, etc etc). this is a minor thing and something a lot of pc/mac/x telnets or mud clients can handle. also be easy to setup better display bars using something like curses and have the mud only send update information. * client maintains small list of frequenlty visited room descriptions in memory and the mud sends something "RoomDesc|3001" instead of the entire description. and the client displays. Sketchy idea, but interesting. * text in/out compression. i believe mume has integrated this with their 'multiple server' setup. a very quicky compression algorithm would have to be used. Just minor thoughts about the subject, despite _serious_ loopholes and questionable practicality.
This archive was generated by hypermail 2b30 : 12/07/00 PST