14 Nov, 2011, arholly wrote in the 1st comment:
Votes: 0
OK, not sure which forum this really belongs in, but I'll ask my two questions:

What is MSDP? I looked in the other forum for a "description" or definition, but I must have missed it (entirely likely).
Is there a way to incorporate it into a ROM mud?

Thanks,
Arholly
14 Nov, 2011, KaVir wrote in the 2nd comment:
Votes: 0
arholly said:
OK, not sure which forum this really belongs in, but I'll ask my two questions:

There is actually an MSDP forum, but as you're asking about adding it to ROM, I guess this one is fine too.

arholly said:
What is MSDP?

It stands for Mud Server Data Protocol. It's a way of transparently transmitting data between the mud and the client.

arholly said:
Is there a way to incorporate it into a ROM mud?

Yes, using my snippet (use the Merc instructions) or Scandum's.

However I have to ask…why do you want to add it if you don't even know what it is?
14 Nov, 2011, arholly wrote in the 3rd comment:
Votes: 0
I don't want to add it, I'm curious what it is. I've seen plenty of people talk about it and was wondering about it. Again, none of the discussions in the MSDP forum really seem to say what it is, but talk about it from a technical standpoint, but doesn't help anyone new to it understand what it is. So, I guess it would better belong in the other forum, but since I started it here…

I noticed (I believe) that with MSDP you can do interesting things with some of the different clients, which is interesting, but outside of that, what is the value of using one of the different protocols?
14 Nov, 2011, KaVir wrote in the 4th comment:
Votes: 0
arholly said:
Again, none of the discussions in the MSDP forum really seem to say what it is, but talk about it from a technical standpoint, but doesn't help anyone new to it understand what it is.

I posted some of my experiences with it here: MUSHclient GUI (lots of screenshots), Cu...

arholly said:
I noticed (I believe) that with MSDP you can do interesting things with some of the different clients, which is interesting, but outside of that, what is the value of using one of the different protocols?

Outside of doing "interesting things with some of the different clients"? Not much, I'm afraid. As I said, MSDP is designed for transmitting data between the mud and the client. So if you're not interested in custom interfaces, graphics, sound, improved scripting, cross-mud chat, etc, then it's unlikely the protocol would be of any value to you.
14 Nov, 2011, Runter wrote in the 5th comment:
Votes: 0
Building something with MSDP is much more difficult than having MSDP installed. I'm not sure I would classify it as MSDP allowing you to do interesting things. I'd say if your client is doing interesting things, it will need a way to get state from the game to the client. The most naive implementation of this is triggering on text and capturing variables. MSDP is a step above that. So even with MSDP installed you have a ton of work to do to get those interesting things happening. MSDP doesn't provide those. It provides the data.
14 Nov, 2011, arholly wrote in the 6th comment:
Votes: 0
OK, so let me ask this. Is having MSDP (or one of the other protocol's) a good thing to have in your mud? Wouldn't it allow you to create a better interface, and thus, a better experience for the users?
14 Nov, 2011, KaVir wrote in the 7th comment:
Votes: 0
Runter said:
Building something with MSDP is much more difficult than having MSDP installed.

That's not really saying much when "having MSDP installed" requires downloading a snippet and spending 10 minutes following a set of installation instructions.

Runter said:
So even with MSDP installed you have a ton of work to do to get those interesting things happening.

The amount of work depends on what you want to do, but a typical mud GUI (pretty background image, some icons, buttons, energy bars, an avatar, a map, etc) can be built in a few hours if you know what you're doing.

Obviously it's the client that needs to do the heavy lifting, but that functionality is already available in some of more advanced clients, so all you need is a way to utilise it. MSDP isn't the only way, but it's an effective one.

arholly said:
OK, so let me ask this. Is having MSDP (or one of the other protocol's) a good thing to have in your mud? Wouldn't it allow you to create a better interface, and thus, a better experience for the users?

Yes, that's why people add it.
14 Nov, 2011, arholly wrote in the 8th comment:
Votes: 0
I know, but the snippet will require a bit more than 10 minutes for me since we use a World of Darkness system, not the standard MERC system, but it still looks easy enough to add or remove stuff.

Are their statistics on the number of MUD's which use or customize the clients? I'm sure individual MU* have their statistics, but has anyone ever done an "industry" study of it?
14 Nov, 2011, KaVir wrote in the 9th comment:
Votes: 0
I'm not aware of any statistics, although I've seen quite a few customised interfaces, and the number seems to be growing.
15 Nov, 2011, Scandum wrote in the 10th comment:
Votes: 0
arholly said:
OK, so let me ask this. Is having MSDP (or one of the other protocol's) a good thing to have in your mud? Wouldn't it allow you to create a better interface, and thus, a better experience for the users?

As MSDP is self describing players can retrieve a list of supported variables and build their own interfaces, something which I have laid most of the groundwork for in TinTin++, and KaVir with MUSHclient. FMud (the flash mud client used by TMC) has recently added MSDP support as well.

The theoretical value of MSDP is huge because providing the data requires a minimal investment. Doing something interesting with the data can be time consuming, however, if you let your players build the interfaces the time consumption becomes a good thing, as you can consider MSDP as a mini-game for players.
15 Nov, 2011, Rarva.Riendf wrote in the 11th comment:
Votes: 0
Let say it cost hardly anything to have it, and it gives your players, or yourself a whole lot of options. And the snippet KaVir made also give more than msdp, but also an extended color support.
The real question is, why not have it ?
15 Nov, 2011, David Haley wrote in the 12th comment:
Votes: 0
Quote
The real question is, why not have it ?

You might prefer a data format more suited for structure data, along with a spec that doesn't change apparently arbitrarily. Even KaVir has gotten frustrated about that. :smile:
15 Nov, 2011, KaVir wrote in the 13th comment:
Votes: 0
Rarva.Riendf said:
The real question is, why not have it ?

I've primarily promoted it on its graphical merits, and that's quite a contentious subject in the text mud community. Here are some of the views I've seen people make against graphics:

"I have no interest in a graphical interface for a MUD. If I wanted a graphical experience I would play a graphical game. Maybe I'm missing something here, but I don't see how it would enhance my experience"

"The leaning toward GUI clients and addons and the advent of hybrid MUD/Graphic games is a step away from the beauty that is the book and a vain attempt to become an MMORPS … It is like cheating on the game. Yes, people can use scripts, macros, automapping, image clients, etc. Yes, you can't stop this, but it does pull away from the rp and intensity of the game and in the end these types of players end up quitting for lack of ability to roleplay."

"The problem is the old "slippery slope" argument. Hardcore mudders and mud developers do not generally want to see graphics added by anyone but themselves, because they're afraid that the induction of server-side graphics will eventually move the genre away from text and into the world of graphics… and frankly the very reason many people play is because text allows for so much more depth than graphics for many things. I, for one, am a PvPer. I love that a text-based system allows for combat mechanics that are simply impossible when you have to take graphical display into consideration."

"a mud is text and not graphic … instead of trying to add bling (graphics) to a mud, why not make a mud more newbie friendly?"

"So essentially you are turning into a dumbed down graphics game … When I say "dumbed down graphical game" I'm talking about Text Games that try to incorporate graphic bars and maps, and images, and sound like that of WoW but leave a lot to be desired. What you essentially get is a "dumbed down" graphical game."

"I think this is where the biggest divide is. One group sees MUDs as an imaginative immersive experience. The other group does too (or so I assume?), but believes exclamation marks over mobs, ding sounds, and glowing mailboxes will improve this immersive experience, where as the former group believes it detracts from the experience."

"What attracted me to my first text game, was that I wasn't watching TV. In other words, I started with text, specifically for the purpose of avoiding graphics."

"There are some MUDs with those graphical maps as you travel, and its like playing a 2d game, but not…I don't really like MUDs like that."

"one of the great advantages of MUDs is that they can still be played by people even without the ability to play a graphical game, whether that is because their computer can't handle it, because they cannot see, or whatever else. Any MUD designer needs to realize that when they employ graphics, they are giving up these last real advantages they possess over MMO's and similar games."

"I'm not sure if luring players with pretty graphics is going to work very well. There are several free mmorpgs out there and someone might actually think, wow, this is the suckiest mmorpg I've ever seen!"

"Where I think MUDs have to focus in on is why play a text game over a graphical one? And this is where you should start thinking the whole book/movie difference … A MUD should play like a interactive novel, not like the cloning of single player computer RPGs that you see in MMOGs."

"The players that play GUI Muds are not and never will be looking for roleplay on those games. They are not looking for imagination, they are looking for the bells and whistles of the graphics and sound … I'm looking for the more mature audience that wants an in depth experience different than Gui Muds. I'm looking for those that seek to immerse into imagination and fantasy."
15 Nov, 2011, Runter wrote in the 14th comment:
Votes: 0
Well, it's obvious interfaces matter. It's unfortunate that people take such hard line on frontend development when it comes to muds. There's definitely gains to be had on the interface side while remaining a text based game. For example, I may love reading a book, I may love the imagination. At the same time I may hate marathon typing sessions. The high coupling between CLI and text based gaming is unfortunate.
15 Nov, 2011, KaVir wrote in the 15th comment:
Votes: 0
Well there are pro-graphics people as well, but the question I was answering was "why not". Some people feel threatened, some speak from ignorance, some are literally unable to use graphics, and so on. However I would speculate that the majority of mudders (both developers and players) simply aren't aware of the work that's been done on mud clients and protocols over the last few years, or of the possibilities that are now available to them.

ZMP was ahead of it's time, but it wasn't very well promoted, and until fairly recently the similar mud protocols (102, 94, ATCP) were all private ones. Likewise, while Nick Gammon has showcased some impressive things in MUSHclient, I've only seen him do so on his own forums. When I've gone out of my way to contact mud owners about the possibilities, they've usually been pretty interested, but people aren't really discovering it on their own.

MudStandards had great promise in this respect, which is another reason why I'm sad to see it die. Perhaps we should have a "mud awareness" week to promote the advances that have been made over the last few years.
15 Nov, 2011, arholly wrote in the 16th comment:
Votes: 0
Kavir (and others),
Thanks for the feedback and responses. I can definitely see the draw to using a protocol and creating a more graphical interface. I am kind of on the pro-graphics side, even though I have zero artistic ability. I guess I'm just a bit scared of what to do once it's installed. I use Fmud to connect to my mud, but need to look at other clients and see how to use it with those and see what I can come up with. Being a World of Darkness MUD, we do things differently, so I need to look at how that would look and how to do it.

Arholly
15 Nov, 2011, KaVir wrote in the 17th comment:
Votes: 0
arholly said:
I guess I'm just a bit scared of what to do once it's installed.

Whatever you like really - you could even do nothing, just leave the option for players who might be interested in creating their own. Or you could start simple and see how it goes, gradually adding things like:

* Backgrounds theme (dark or bloody for vampires, flora or spirits for werewolves, etc).

* Energy bars (blood points for vampires, rage for werewolves, wound levels, willpower, humanity, etc).

* Character avatars (could also indicate current form, eg bat, wolf, mist, crinos, glabro, etc).

* Buttons (with cooldown timers when appropriate) for activating/toggling abilities like Celerity, Wolf Claws, etc. Could also be a good place for using sounds.

* Animations indicating day/night cycles and moon phases.

* A full score layout on one side of the screen, designed to look exactly like a WoD character sheet.

* Clan/tribe symbols, maps, customisable buttons, chat window, tabs, icons, etc.

Generally speaking, even a simple GUI is going to look much more appealing than a black terminal window.
15 Nov, 2011, arholly wrote in the 18th comment:
Votes: 0
Dang it, stop trying to encourage me. :biggrin:

I know. Those are all things I've thought about. Maybe I'll just do it and do it slowly. I think I'll look at the code and start commenting things out I know I don't use and start adding things in slowly.

How easy is it to implement with Fmud?
15 Nov, 2011, KaVir wrote in the 19th comment:
Votes: 0
There's two parts here - the server-side part (the snippet) and the client-side part (the plugin or script).

The snippet works as-is and shouldn't take more than 10-15 minutes to add. It'd be faster to add first and then later remove stuff you don't want, although personally I'd consider all of its features useful - which features didn't you want?

The client-side part takes longer, although I've released a generic MUSHclient plugin that several muds have used as a starting point, and it usually takes me an hour or two to customise it for a specific mud.

I've not got around to playing with FMud, so I don't know what is involved, but I do know that it supports MSDP (as well as MXP, although not MXP negotiation, so that would require a little tweaking to get working in the snippet).
15 Nov, 2011, arholly wrote in the 20th comment:
Votes: 0
Well, we don't use Mana or anything like that. We've declared a lot of our own variables (RGB for RageGlamourBlood, max_RGB for the max, etc…) instead of reusing the Diku variables (again, I've inherited it like this), so there are several which we just don't use. Same for things like health. So, I have to rework a lot of those variables (or figure it out) in order to get it to work. Again, not a big deal, just a little bit of work, which is why I'm thinking of going with removing a bunch and then slowly adding.
0.0/59