Top Mud Sites Forum - View Single Post

KaVir · 09-14-2010, 11:35 AM

I don't think that's necessary, nor even desirable. Not all muds wish to support links, or sound, or graphics, or data compression, or cursor movement, etc, etc. And while it can certainly be advantageous for a client to support a wide variety of protocols, many client developers simply lack the time or interest to add them all, or don't feel certain protocols are appropriate for their client. Bundling everything together into some "Universal Mud Protocol" won't suddenly cause all the client developers to implement it - it'll just result in a load of partial implementations.

In my opinion it's much easier to deal with a library of useful protocols, each serving a different purpose.

I believe the main advantage of browser clients is that they don't require the user to download, install and configure anything before they can play - i.e., it's a great way of lowering the entry barrier for new players. However for established players I would still prefer to offer a customised version of a well established and feature-rich client with years of development behind it.

You could already do that with some sort of generic plugin, and have it create the layout, maps, bars, buttons, etc, based on commands from the server. However the less generic you want your interface to be, the more complex the plugin (and instructions from the server) would become - you'd reach the point where it would be easier just to create a custom plugin for each game and provide a way for the client to automatically download and install it upon connection.

That's not a bad solution (and it's been discussed before), but I wouldn't want to force players to use my interface - I think they should have the option to create their own if they wish.

MXP has display options, it's just that most implementations don't include those features. ATCP and GMCP include a status sequence that's intended to be used for energy bars, but I'm not sure if any clients use it automatically. I would hope not, as that should really be left up to the user, and automatically adjusting their interface could interfere with other plugins they may have running.

There have been more? I thought MudStandards was the first. It's certainly gone quiet, but perhaps it'll pick up again.

09-14-2010, 11:35 AM	#81
KaVir Legend Join Date: Apr 2002 Name: Richard Home MUD: God Wars II Posts: 2,052	Re: The mud client poll I don't think that's necessary, nor even desirable. Not all muds wish to support links, or sound, or graphics, or data compression, or cursor movement, etc, etc. And while it can certainly be advantageous for a client to support a wide variety of protocols, many client developers simply lack the time or interest to add them all, or don't feel certain protocols are appropriate for their client. Bundling everything together into some "Universal Mud Protocol" won't suddenly cause all the client developers to implement it - it'll just result in a load of partial implementations. In my opinion it's much easier to deal with a library of useful protocols, each serving a different purpose. I believe the main advantage of browser clients is that they don't require the user to download, install and configure anything before they can play - i.e., it's a great way of lowering the entry barrier for new players. However for established players I would still prefer to offer a customised version of a well established and feature-rich client with years of development behind it. You could already do that with some sort of generic plugin, and have it create the layout, maps, bars, buttons, etc, based on commands from the server. However the less generic you want your interface to be, the more complex the plugin (and instructions from the server) would become - you'd reach the point where it would be easier just to create a custom plugin for each game and provide a way for the client to automatically download and install it upon connection. That's not a bad solution (and it's been discussed before), but I wouldn't want to force players to use my interface - I think they should have the option to create their own if they wish. MXP has display options, it's just that most implementations don't include those features. ATCP and GMCP include a status sequence that's intended to be used for energy bars, but I'm not sure if any clients use it automatically. I would hope not, as that should really be left up to the user, and automatically adjusting their interface could interfere with other plugins they may have running. There have been more? I thought MudStandards was the first. It's certainly gone quiet, but perhaps it'll pick up again.