Top Mud Sites Forum - View Single Post

KaVir · 09-15-2010, 04:53 PM

See here:

If you're developing a custom client rather than customising an established one, then that means missing out on the decades of development and testing that have gone into those established clients.

Things like aliases, hotkeys, triggers, command-execution timing, variables, multi-session support, cross-platform support, ansi/256/24-bit colour, speed-walking, extensive scripting in multiple languages, macros, regex, toolbars, smooth scrolling, scrollback, logging, customisable fonts and colours, compression, chat, built-in text editor, configurable output buffer and text wrapping, debugging tools, text hyperlinks, spell checker, tab completion, configurable command window and input options, mapper, autosay, open protocol support, configurable sounds, NAWS, TTYPE, ECHO, fully customisable graphical skins (including buttons, energy bars, avatars, icons, mouse hotspots, etc), and so on and so forth. Not to mention the years of extensive testing by many, many users.

Of course it wouldn't, why would you think that? My comment was a direct reply to this statement:

If people decide that "the best use of [their] time is certainly not trying to write plugins / scripts for the various clients out there", but is instead to develop their own custom clients from scratch, then they're losing out on decades of development and testing. That is what I consider a step backwards.

I can understand people wanting to create their own client for legal reasons, or because they want it to run from a browser (not much available to reuse in terms of browser-based mud clients), or even just because they enjoy the challenge. But reinventing the wheel just for the sake of it? I can think of better things to do with my time.

Of course I'd prefer it if my plugin worked on multiple clients, but I can't realistically see that happening. What you could do is what I mentioned previously - design a standard for skinning, and create plugins for multiple clients that support the standard. Then any server that added support for the standard could indeed offer the same interface to multiple clients without the need to create any further plugins. No doubt some people would still prefer to design their own plugins, adding things that aren't covered by the generic plugin, but perhaps it would be useful as a backup option for clients you didn't explicitly support, or for muds that lack the skill or desire to do any work outside of the server itself.

Yes, getting client and server developers to agree on implementing a standard is very hard. However the plugin approach sidesteps the client developers entirely (anyone can create the plugins), and if you're already a server developer then you could use your own mud as the prototype for the standard, and/or release a snippet for other server developers to use.

Actually I suspect hubris may be one of the reasons. Others include those I mentioned earlier - legal concerns (particularly for commercial muds), wanting it to run from a browser, or simply for the challenge. Or perhaps just an unawareness of what modern clients are capable of?

09-15-2010, 04:53 PM	#95
KaVir Legend Join Date: Apr 2002 Name: Richard Home MUD: God Wars II Posts: 2,052	Re: The mud client poll See here: If you're developing a custom client rather than customising an established one, then that means missing out on the decades of development and testing that have gone into those established clients. Things like aliases, hotkeys, triggers, command-execution timing, variables, multi-session support, cross-platform support, ansi/256/24-bit colour, speed-walking, extensive scripting in multiple languages, macros, regex, toolbars, smooth scrolling, scrollback, logging, customisable fonts and colours, compression, chat, built-in text editor, configurable output buffer and text wrapping, debugging tools, text hyperlinks, spell checker, tab completion, configurable command window and input options, mapper, autosay, open protocol support, configurable sounds, NAWS, TTYPE, ECHO, fully customisable graphical skins (including buttons, energy bars, avatars, icons, mouse hotspots, etc), and so on and so forth. Not to mention the years of extensive testing by many, many users. Of course it wouldn't, why would you think that? My comment was a direct reply to this statement: If people decide that "the best use of [their] time is certainly not trying to write plugins / scripts for the various clients out there", but is instead to develop their own custom clients from scratch, then they're losing out on decades of development and testing. That is what I consider a step backwards. I can understand people wanting to create their own client for legal reasons, or because they want it to run from a browser (not much available to reuse in terms of browser-based mud clients), or even just because they enjoy the challenge. But reinventing the wheel just for the sake of it? I can think of better things to do with my time. Of course I'd prefer it if my plugin worked on multiple clients, but I can't realistically see that happening. What you could do is what I mentioned previously - design a standard for skinning, and create plugins for multiple clients that support the standard. Then any server that added support for the standard could indeed offer the same interface to multiple clients without the need to create any further plugins. No doubt some people would still prefer to design their own plugins, adding things that aren't covered by the generic plugin, but perhaps it would be useful as a backup option for clients you didn't explicitly support, or for muds that lack the skill or desire to do any work outside of the server itself. Yes, getting client and server developers to agree on implementing a standard is very hard. However the plugin approach sidesteps the client developers entirely (anyone can create the plugins), and if you're already a server developer then you could use your own mud as the prototype for the standard, and/or release a snippet for other server developers to use. Actually I suspect hubris may be one of the reasons. Others include those I mentioned earlier - legal concerns (particularly for commercial muds), wanting it to run from a browser, or simply for the challenge. Or perhaps just an unawareness of what modern clients are capable of?