I have never been able to find one, which is why I continue to refer to it as a 'protocol' in quotes.
We have implemented most of what is described in http://www.aardwolf.com/wiki/index.php/C... and it's been a good primer. We also had to send "spies" to play Aardwolf and snoop their output.
However, given the lack of proper documentation, we're finding that GMCP messages are processed differently by different desktop clients (merge vs. refresh), and that's making it hard for us to extend our server implementation beyond what is described on the Aardwolf wiki.
04 Jan, 2013, Rarva.Riendf wrote in the 3rd comment:
There are a few differences, but both can do the same things. I consider MSDP a superior choice, but Mudlet doesn't support it, which is actually the reason why I added ATCP as a fallback option.
05 Jan, 2013, Rarva.Riendf wrote in the 5th comment:
Votes: 0
Ok..and since since AArdwolf has been mentioned, anyone turned its client to support MSDP ? (I started but got lazy, I dont like langage that do not 'compile') so I got back to coding my engine instead.
It's officially supported by Mudlet and CMUD, and semi-officially supported by MUSHClient. So I guess MUDs will feel forced to implement GMCP. CMUD won't implement MSDP because it's main sponsor, IRE, wouldn't like that. Mudlet has close ties to IRE, and quite possibly (future) financial ties as well. IRE is known to have put pressure on its sponsors in the past, there are posts on TMC where the IRE owner threatens to cut its sponsorship if TMC was to add a pay for perks field to its mud listing for example.
Another problem is that the MSDP plugin available for MUSHClient doesn't properly support tables or arrays, though this may have changed since the last time I checked, which definitely cripples MSDP support in MUSHClient.
GMCP is a lot bulkier than MSDP, though this isn't a big problem with MCCP enabled. MSDP is much more granular as the intention of GMCP was to have standardized packages.
Other than that MSDP suffers from the same limitations as GMCP, no standard way to directly write inside tables, no standard way to indicate whether to merge or overwrite data, no standard way to delete data. Ideally an MSDP enabled client supports the option to let the user define whether data merges or overwrites, which differs from the GMCP approach where the client automatically stores all data.
I'm not opposed to adding a ROOM.VNUM or ROOM[VNUM], or ROOM\007VNUM notation for variables to MSDP, which seems like a useful extension if tables ever become popular. This wouldn't be a bad thing for GMCP to support either, but the way things went down GMCP is no longer up for discussion, with clients (that is Mudlet and CMUD) being expected to follow IREs lead, or lack there of?
I think everyone is slightly confused about what is going on, this is just my take on things.
Ok..and since since AArdwolf has been mentioned, anyone turned its client to support MSDP ? (I started but got lazy, I dont like langage that do not 'compile') so I got back to coding my engine instead.
To get the MUSHClient Aardwolf GUI working all that's needed is to replace the JSON parser with an MSDP parser, that's the most difficult part as this appears to be above the skill level of the average programmer. You could look at how TinTin++ handles this for inspiration, though this will be confusing if you're unfamiliar with tt++'s typeless variable system. a = { b = { c = "d" } } would be #variable {a} {b}{{c}{d}}
Once that is accomplished you'll need to write an MSDP command handler, which is fairly easy. Next you would either use GMCP compatible variables which would make the Aardwolf GUI work without further modification, or use the MSDP standard.
One interesting detail is that the Aardwolf and IRE variable sets are not fully compatible. Capitalization is inconsistent (MSDP is case sensitive while GMCP leaves this undefined), and some variables have been given different names.
05 Jan, 2013, Rarva.Riendf wrote in the 8th comment:
Votes: 0
Ok, I have no players that use much of what I added already so it was more for a technical standpoint. I may rip of Aardwolf interface and turn it to be msdp compliant in the future though. If I ever get motivated enough.
My goal being my mud stay a game that can be played even in plain telnet with minimal disadvantages to someone with a more 'graphical' interface, I guess there is no difference between MSDP and GMCP for my use.
My goal being my mud stay a game that can be played even in plain telnet with minimal disadvantages to someone with a more 'graphical' interface
I think you can only apply a policy of client non-discrimination on the server side. The fact is that some clients will always have advantages over others that you have no control over. Usually, different clients have strengths in one aspect, and weaknesses in another. For instance, a group status module in a GUI makes group support easier, but GUI's tend to be less responsive than simple telnet and can make other things more difficult. So, the fact that a group status module offers an advantage over simple telnet should not deter you from wanting one.
In general, multiple interfaces improve your reach, so you should want that no matter what the implications are (unless you prefer to have less players rather than more).
Does anyone have a copy of the draft specification archived that they can share? The official link is down.
As noted, there was never a formal specification or RFC. There should be two relatively reliable components of GMCP, though: the format itself and the Core module. Additional modules, like Char and Room from the original ATCP, were planned to be standardized, but the whole thing kind of went down the tubes. That's probably where all the incompatibility comes from.
The syntax is really easy:
message = name whitespace+ payload name = module ("." module)* "." type module, type = /[A-Za-z_]+/i payload = <JSON document> | <JSON primitive> whitespace = /[\t\s]/
Message names are case-insensitive. We never agreed on whether to use ASCII or UTF-8 encoding, but it ought to be UTF-8: that's the IETF recommendation for network communication of textual data.
The syntax was hammered down relatively early, so it's pretty solid. The Core module has some glaring idiosyncrasies (at least to me), but it should likewise be pretty stable. IRE's GMCP documentation is an acceptable reference for that particular module, though I frankly can't remember if KeepAlive, Ping, and Goodbye were discussed at MudStandards. They're probably just hold-overs from ATCP.
GMCP lets you send tagged JSON documents between the client and the server. MDSP is structurally identical, with the exception that the tag is part of the payload itself. (It doesn't use JSON documents, but something essentially isomorphic, so it's not really a difference.) It doesn't have a module system, but then that's just a convenience anyway.
It's officially supported by Mudlet and CMUD, and semi-officially supported by MUSHClient. So I guess MUDs will feel forced to implement GMCP
Why would any MUD ever feel "forced" to implement a protocol meant to enhance the player's experience of that MUD?
I've noticed the rather distrubing trend, lately, of MUD server admins thinking they *MUST* do this, that, or the other thing to satisfy some arbitrary whim of a group of players. While there's some validity in that approach if your only goal is to make money, the majority of text MUDs are still free of charge, and so the concept of suckering people into buying it and then changing to entice more newcomers to buy the box, doesn't seem very smart.
Build your game. If *YOU* feel that you need some enhanced protocol to make your game more enjoyable, then select one of the existing client protocols (or roll your own), and inform your players that they'll need to use a client that supports THAT ONE PROTOCOL to get the full experience. Trying to satisfy everyone means you'll spend a lot of time and effort maintaining code, and that time is better spent on content.
I've noticed the rather distrubing trend, lately, of MUD server admins thinking they *MUST* do this, that, or the other thing to satisfy some arbitrary whim of a group of players.
Hasn't it always been like that? The current focus on graphical interfaces is somewhat silly as it doesn't improve the game. So I agree that it's not that relevant, except for MUDs where scripting is part of the gaming experience, like on IRE.
I've noticed the rather distrubing trend, lately, of MUD server admins thinking they *MUST* do this, that, or the other thing to satisfy some arbitrary whim of a group of players.
Hasn't it always been like that? The current focus on graphical interfaces is somewhat silly as it doesn't improve the game. So I agree that it's not that relevant, except for MUDs where scripting is part of the gaming experience, like on IRE.
It's only silly if you accept an extreme statement as your starting point for discussion: that graphical interfaces cannot improve games. This is going to vastly swing from person to person, and implementation to implementation. Most people don't like to read for hours, but of those who are left that do like to read for hours, even fewer of us like to type all day. Interfaces are important tools, and its rare CLI beats other interfaces even for technical purposes when you factor in the debt of learning, but certainly more so in leisure. Good interfaces are hard to design, and seldom does the skill of designing a good interface align with talented programmers.
08 Jan, 2013, quixadhal wrote in the 17th comment:
Votes: 0
Making an interface contain graphical elements does not mean it's either better OR easier to learn. In fact, in most cases I've seen WRT text muds, it makes it harder to learn.
Consider: in a real graphical game (one that was DESIGNED that way), you expect to be able to do everything possible with the GUI. When you're playing WoW, the only time you ever type anything is when chatting with others. Every game-related action is done with a GUI interaction. MUD's, OTOH, were designed to parse text input. Because they weren't designed with a limit on the number of "commands" allowed, nor with the idea that the same "command" can be used for different things depending on context and modifiers (shift-click to drop something, right-click to either attack or talk depending on hostility of the target), what you end up with is a handful of common-use buttons, and then a command line that you STILL have to learn to work the rest of the game.
IMHO, that's considerably worse.
You now have a semi-intuitive graphical interface which has to be learned *AND* a non-intuitive text interface, and if the client setup was designed for a particular gameplay style (IE: fighter charging into combat every 3 seconds), and you want to play in some other fashion (IE: healer, or explorer), now you can't just learn the commands to type…. you now ALSO have to learn how to modify the client layout to put the commands *YOU* use into place.
So, while I certainly don't say graphical interfaces CANNOT improve non-graphical games… I'd say that they usually DO not.
Making an interface contain graphical elements does not mean it's either better OR easier to learn. In fact, in most cases I've seen WRT text muds, it makes it harder to learn.
I've been offering an interface with graphical elements for about 2.5 years now, and have quizzed the users extensively for feedback and suggestions, and the response has been exactly the opposite of what you describe - everyone I've asked has said the interface makes the game easier to play, particularly the graphical maps (which are considerably easier to understand than the ASCII ones). A few people have said they don't like graphics, and some have returned to their old clients out of habit, but nobody has ever said it makes the mud harder.
I've noticed the rather disturbing trend, lately, of MUD server admins thinking they *MUST* do this, that, or the other thing to satisfy some arbitrary whim of a group of players.
Or a group of fellow devs :) But really, it has always been like that. Insecure admins are too impressionable and secure ones are too arrogant. In other words, welcome to mudbytes.
Hasn't it always been like that? The current focus on graphical interfaces is somewhat silly as it doesn't improve the game. So I agree that it's not that relevant, except for MUDs where scripting is part of the gaming experience, like on IRE.
While it is unwise to leap into anything for the wrong reasons, you can clearly do a lot worse than invest time in a GUI. I don't know of any server feature that actually brings players to the game. It is advertising / promotion that brings players. And I think we can all agree that a promo post about a sleek custom GUI is much more likely to get people to try a new game than a post about a unique feature. Even among mudders, the visual tug is pretty strong.
Consider: in a real graphical game (one that was DESIGNED that way), you expect to be able to do everything possible with the GUI. When you're playing WoW, the only time you ever type anything is when chatting with others. Every game-related action is done with a GUI interaction. MUD's, OTOH, were designed to parse text input. Because they weren't designed with a limit on the number of "commands" allowed, nor with the idea that the same "command" can be used for different things depending on context and modifiers (shift-click to drop something, right-click to either attack or talk depending on hostility of the target), what you end up with is a handful of common-use buttons, and then a command line that you STILL have to learn to work the rest of the game.
IMHO, that's considerably worse.
But that's all a symptom of a bad UI design. That goes back to my point that most programmers, even good ones, aren't often equipped to properly design UIs. Just adding a button to do a command macro isn't a proper interface, and I think good GUIs take as much effort and thought to develop as your game. So a lot of people aren't going to invest the time and write it off as not making a game better.
Thanks,
Barnabus