08 Oct, 2010, Scandum wrote in the 21st comment:
Votes: 0
I created a few protocol pages on Mudpedia with the idea of linking them back to the small collection of specifications I got going on my sourceforge webspace.

http://www.mudpedia.org/wiki/MCCP

It's not a community effort as I control the specifications, but with back linking to Mudpedia people can update client and codebase support, not sure if people would be interested in a server support table.
08 Oct, 2010, David Haley wrote in the 22nd comment:
Votes: 0
Kaz said:
Is it worth creating a new site, getting the attention of codebase and client implementers and creating a proper standards collation and creation effort?

I've thought about it several times. I started coming to the conclusion that there just isn't a lot of motivation other than idealism to get everybody agreeing on new standards. For starters, many of the standards are very nebulous and game-dependent in the first place. Take KaVir's plugins, for example. How could you standardize all of that when so much is only relevant to GW2? If there was a standard that supposed his MUD and some other MUD, would they both be forced to implement the features of the other MUD? What about a standard that supports every MB poster's MUD?

I think a data transport protocol with support for rich structure would be the most practical and have the highest chances of success. But it wouldn't get you anything more than a way of sending structured data; you'd still have to decide what to actually do with that data.

If you think about it, the problem of having an arbitrary MUD server send this structured data to an arbitrary (standards-compliant) client and having a full GUI rendered is a very hard problem, arguably harder than it's worth for standardization. It's much easier to write your own plugins for an open client and be done with it.

And this is just my personal feeling now, but I'm a little unsure there's that much value in having shared standards in this field in the first place. In the end of the day this is about making games, and if you can provide a good client that people use to play your (good?) game, that's all you need. Past are the days of only using telnet from a relatively dumb terminal to connect and therefore there being value in standardized connection. How many of the successful games (not just MUDs) out there support more than one client?
08 Oct, 2010, Runter wrote in the 23rd comment:
Votes: 0
David just summed up what my feelings have been for some time.
09 Oct, 2010, Rudha wrote in the 24th comment:
Votes: 0
I don't think there's a real appreciation for how much easier it would be on all involved to motivate major players in that whole thing to implement them. We have so many redundant protocol standards that wading through them is kind of headache inducing, and some of them are quite unused and dead. Collating standards wouldn't be a bad thing, but adoption is the hard thing. No one is motivated to cooperate to that regard - or rather, not enough people in the proper position to affect change are motivated to cooperate.

Rationalising the familiar is an easy thing to do, but that doesn't mean it's the proper thing to do.

As an aside, David: I have several, several years experience dealing with the people behind IRE that makes me skeptical at best of their motivations about that. Now that's not to say that they were trying to pull some evil empire thing or something, or that they were being malicious, but I think that their aim was getting the public to adopt their own standard more than listening to what anyone else had to say. And the proof's in the pudding - they didn't really stick around long after they got that result.

I can't really comment on the others involved; I don't know Lasher, my interactions with Nick are limited to a few questions about MC's plugin support, and I avoid Z/CMud like the bubonic plague.

Maya/Rudha
09 Oct, 2010, Runter wrote in the 25th comment:
Votes: 0
Its clear business models were the driving force behind the whole thing in regards to ATCP. It was clear major changes to the protocol were off the table and fairly determined by the needs of IRE in the first place. Furthermore, IREs actual developers weren't involved on the site. It was more of an announcement of what was to be rubberstamped rather than a discussion.
09 Oct, 2010, David Haley wrote in the 26th comment:
Votes: 0
Rudha said:
I don't think there's a real appreciation for how much easier it would be on all involved to motivate major players in that whole thing to implement them.

If you don't think it's hard to motivate players, what are your suggestions? Everybody understands the general idea, enough to say, "yeah, it would be nice", but when it comes to actually doing the hard (and unpleasant) work, it's not worth it anymore.

Rudha said:
As an aside, David: I have several, several years experience dealing with the people behind IRE that makes me skeptical at best of their motivations about that. Now that's not to say that they were trying to pull some evil empire thing or something, or that they were being malicious, but I think that their aim was getting the public to adopt their own standard more than listening to what anyone else had to say. And the proof's in the pudding - they didn't really stick around long after they got that result.

I don't think that it's improper, or a criticism, to say that they had their own business interests and acted accordingly. It's also not really surprising that Zugg acted the way he did, and in line with IRE, considering that they were the two commercial entities. There is nothing wrong with being a company with business purposes, as long as you're up front about it. But if indeed their goal was just to get their stuff rubberstamped by the community, as Runter said (I suspect it to be the case to some extent, but I'm not sure) then I would criticize the somewhat underhanded way of presenting it as an open standards collaboration. If somebody tells me, "hey, we're going to do this, what do you think?" my expectations are set remarkably differently than if somebody tells me "hey, let's work together, you and I, on this thing".

Incidentally, they didn't really get "the public" to approve or adopt their standard. The people who were already on board with IRE – Zugg and Mudlet – were the ones who adopted it. Perhaps the main person they convinced who wasn't already on-board was Lasher. Nick is unimpressed by ATCP2 and believes that they missed most of the point. This is in fact evident when you consider that for a very long time they persisted in having their own string-list format rather than actually using the list structure that JSON gave them.

Well, anyhow, a lot of this is water under the bridge. As I said earlier, I think that a lot of this faith in all-encompassing standards is idealism that doesn't serve much practical value in this particular instance. People can make extremely fun games by writing plugins for clients without any kind of grand unified standard. In the end of the day, aren't we here to make fun games?
09 Oct, 2010, KaVir wrote in the 27th comment:
Votes: 0
Rudha said:
We have so many redundant protocol standards that wading through them is kind of headache inducing, and some of them are quite unused and dead.

The only ones I can really think of that could be classified as redundant are the many out-of-band protocols - ATCP, GMCP, MSDP, 102, ZMP, etc, all of which could technically serve the same purpose.

ATCP is being replaced by GMCP - but I know of at least one non-IRE mud that's using ATCP, and I don't know if they're updated to GMCP. Dying? Yes I think so.

102 was only used by Aardwolf AFAIK, and Aardwolf is moving to GMCP. I think we can write this one off as dead?

ZMP is pretty much dead I believe. The developer has vanished, a lot of the documentation is dead links, and I don't know of any muds that support it (other than mine - but nobody uses it because they've got MSDP).

It looks to me like both GMCP and MSDP will pick up popularity, which I think is a good thing. Although both protocols can technically be used for the same purpose, they approach it with a different philosophy.

What about the in-band equivalents, like MCP? I think that's popular with MOOs - but anyone know for sure?

For hyperlinks we've got Pueblo and MXP, but does anyone still use the former?

MXP also allows you to include MSP sounds, but many more clients support the latter protocol (which is also far easier to implement) than the former, so I think it's fine to keep the two separate. MXP can be used for transmiting in-band data and even (in the case of CMUD) out-of-band data, but with the latter being supported by only one client I can't see many muds bothering - and I doubt many people would use in-band when they could instead of out-of-band.

We already covered MCCP1/2.

It would be really useful to put together some sort of document about this though. Perhaps it's a bit too opinionated for anything official? Could be turned into an article though, I suppose.

Rudha said:
I have several, several years experience dealing with the people behind IRE that makes me skeptical at best of their motivations about that. Now that's not to say that they were trying to pull some evil empire thing or something, or that they were being malicious, but I think that their aim was getting the public to adopt their own standard more than listening to what anyone else had to say. And the proof's in the pudding - they didn't really stick around long after they got that result.

My problem with that view is:

1) What benefit would they get from having their standard adopted by other muds? The client developers are already bending over backwards to support the IRE games, and I suspect the only reason they even got on board MudStandards was because that's what IRE wanted.

2) They didn't actually get public support - they didn't even get support from the majority of posters on MudStandards. In fact, the public weren't even allowed to join the discussions.

My personal opinion? I think their motivation was honest, but that they weren't expecting such a critical reception from other developers. They also needed to push ahead and implement something, and there were many people with strong opinions who simply wouldn't shift their views.

However IMO they should have addressed the design flaws first (because those are more than just a matter of opinion), and continued to develop the protocol openly. I don't know why they didn't do that, but I get the impression they're not used to dealing with other developers as equals.

Ever tried logging on to various muds and chatting with the owner or other staff? It's quite interesting to see what sort of responses you get to questions, suggestions and criticism, and compare that with their presence (or lack thereof) on forums where they're no longer the big fish in a little pond.
09 Oct, 2010, Scandum wrote in the 28th comment:
Votes: 0
The whole package setup of GMCP is a bit of a joke as they need to resend all room data every time a user changes rooms because they embedded exit data in the room data. The only alternative would be to nil the exit data, then overwrite it, which adds another layer of complexity to the protocol.

The main advantage of community feedback is to find and deal with issues like these, but without anyone directing the effort mudstandards was just an explosion of noise, and then nothing.

TinTin++ only has a basic GMCP handler that converts JSON tables to TINTIN tables and raises an event, so I won't have to deal with the whole package mess myself.

Last time I checked Aardwolf unlinked the IRE draft and duplicated the package definition, converting some custom comma separated strings to JSON data, so I guess the compatibility drama has already started.
09 Oct, 2010, Scandum wrote in the 29th comment:
Votes: 0
KaVir said:
It would be really useful to put together some sort of document about this though. Perhaps it's a bit too opinionated for anything official? Could be turned into an article though, I suppose.

Mudpedia's mud client comparison chart could be used for this to some degree, with encyclopedic pages for the various protocols, using as many primary sources as possible.

It'd be possible to try this on Wikipedia, but the protocol articles would get deleted for lacking secondary sources as soon as a group of admins would get wind of it.
09 Oct, 2010, David Haley wrote in the 30th comment:
Votes: 0
ATCP2 should not have tried to mix the semantics protocol with the data transport protocol. They should have kept clear the separation of the structured data protocol and commands related to data (like how caching might work) and then left packages like rooms, exits, etc. more open-ended, or for separate specifications.

KaVir said:
The client developers are already bending over backwards to support the IRE games, and I suspect the only reason they even got on board MudStandards was because that's what IRE wanted.

Not all clients depend on IRE – Zugg is the only one who has a true business interest in doing so. Nick doesn't go out of his way to work with IRE, for instance, and neither does Scandum. The Mudlet guys seem to be IRE players, though.
12 Oct, 2010, Kaz wrote in the 31st comment:
Votes: 0
KaVir said:
Kaz said:
Is it worth creating a new site, getting the attention of codebase and client implementers and creating a proper standards collation and creation effort?

If you could get the attention of server and client developers, sure. But I think the chances of that are extremely slim.



If you want to get the attention of the client developers, you need to wave some really big muds in front of their noses. But to get the big muds on board, you generally need to wave the major clients in front of their noses. Chicken and egg. Someone has to take the first step, and it really needs to be either one of the major client developers, or the owner of one of the really big muds…


I remember thinking about this at the time, and there are two more: 1) a lot of the really small muds. This would be done by providing source code snippets and patches to affix a particular feature into stock. 2) a new client effort based around the public open standards instead of ad-hoc protocols and plug-ins.

But that aside, I think you're probably right all in all. How depressing :(
12 Oct, 2010, KaVir wrote in the 32nd comment:
Votes: 0
Kaz said:
I remember thinking about this at the time, and there are two more: 1) a lot of the really small muds. This would be done by providing source code snippets and patches to affix a particular feature into stock.

Well that's actually part of my incentive for creating the MSDP snippet ;) However I think the client developers are more likely to count users rather than muds, so getting a bunch of empty muds to add the snippet probably isn't going to cut the mustard.

On the other hand, if those muds can create some sexy plugins it may give them the edge they need to start building up a playerbase. Other muds could of course pinch the plugins, but to do that they'd need to add the MSDP snippet as well - so the number of users (from a client perspective) isn't going to decrease even if the players jump ship.

However there's also been some interest from the owners of established muds, so my hopes are pretty high for MSDP. I just need to force myself to finish that snippet.

Kaz said:
2) a new client effort based around the public open standards instead of ad-hoc protocols and plug-ins.

I'm not sure about that one. It's actually pretty difficult to persuade mudders to change client, and personally I would think twice before spending a lot of time adding support for a client that very few players use.
12 Oct, 2010, Rudha wrote in the 33rd comment:
Votes: 0
I think a more open and free (as in beer) MUD client with built in scripting and GUI capabilities would be a good thing, but Im not convinced there'd be enough people willing to adopt it to expend too much effort on it. I mean, Mudlet has enough trouble getting support outside of their development circle, though theres other factors at play thewre as well.

Maya/Rudha
12 Oct, 2010, David Haley wrote in the 34th comment:
Votes: 0
MUSHclient is free and open source, and has a framework for developing GUIs. What would a new client bring to the table after taking into account the cost of developing one?
12 Oct, 2010, Rudha wrote in the 35th comment:
Votes: 0
What's the cost? Honestly. A terminal is not hard to develop. It does not take large segments of time. It is not technically challenging. The most difficult thing is probably developing TELOPT support that accounts for the eccentricities of varying mud servers (MXP comes to mind), and encapsulating the GUI to allow the end user to modify it, which in my experience is pretty easy with libglade, and I'm sure it's not the only fish in the sea.

The thing that makes it not worthwhile is that there would likely not be very many people which would adopt it. Yes, you're probably correct that it's not worth the trouble; but not for the reasons you seem to imply (that it would somehow be difficult).

I could get into a digression about what I don't like about MushClient, but it's not terribly relevant to the topic at hand.

What I don't understand, on the topic of duplicated efforts, why there are so many out of band protocols. Well, I kind of do: they're the result of personality conflicts between developers; but honestly, I don't see much difference between what they technically achieve. ATCP/ATCP2 does offer the module system, but being purpose build for IRE muds they are of limited usefulness to others.

Maya/Rudha
12 Oct, 2010, David Haley wrote in the 36th comment:
Votes: 0
Are you seriously saying that developing a client that would allow all of this stuff is in fact not so hard? Well, the only thing I have to say to that is that I will wait for you to produce such a thing and then I will gladly eat my hat. :smile: In the meantime I believe that you underestimate the amount of work. (Obviously it is not the hardest software project in the world. But it's not something you get done in a weekend or ten.) How much of this kind of software have you written, out of curiosity? The problem isn't just letting the end user modify it, but exposing the GUI interface to a scripting environment to allow programmatic modification. I guess I'm a little surprised at how casually you dismiss the work involved when just the other day you were asking for tutorials on using Nick's miniwindows despite there being full examples available – isn't that alone a sign that it's not as easy as you are saying? (And that's just the usage part, never mind developing it all.)

The point here is not to criticize anybody's coding abilities but quite simply that (1) people keep asking why this stuff doesn't get done more often, and (2) the answer is straightforward: it involves very real amounts of work, or in any case more than people think when they ask the question.

This is all in addition to the fact that people are unlikely to adopt it unless it offered a very compelling reason to change.

Rudha said:
What I don't understand, on the topic of duplicated efforts, why there are so many out of band protocols. Well, I kind of do: they're the result of personality conflicts between developers; but honestly, I don't see much difference between what they technically achieve. ATCP/ATCP2 does offer the module system, but being purpose build for IRE muds they are of limited usefulness to others.

I think you more or less answered your own question. If I want to use something like ATCP2, I need to add the stuff that makes it useful to me. In doing so, I'm no longer really using ATCP2, and a new protocol fork is born. Furthermore, I wouldn't use ATCP2 in the first place, because I think it suffers from some very major flaws as a data transport protocol (such as the utter silliness around having to add brackets client-side to make messages parseable).

The other reason is that there isn't a lot of point in making them all the same. Let's say that people like KaVir used ATCP2 to send his data instead of MSDP. OK, great; that doesn't really change anything with respect to still needing to implement all of the further graphical elements.

Finally, I think that the whole notion is relatively new to many MUDs, and so things are still evolving.
12 Oct, 2010, Rudha wrote in the 37th comment:
Votes: 0
David Haley said:
Are you seriously saying that developing a client that would allow all of this stuff is in fact not so hard?


As opposed to the alternatives in game design, MUDs and MUD clients are exceedingly easy to make. My previous project I worked on was a 3d first-person hack-and-slasher sort of game and if you think adding support for different TELOPT protocols is difficult (or any other example of problematic MUD coding) you've obviously never had to account for the eccentricities between different graphical chipsets and drivers, writing algorithms to watch for network manipulation, as they call it, and so on. This is, granted, much easier than it used to be prior to DirectX and OpenGL gaining popularity, however it's still a pain.

I'm not saying MUD development is a walk in the park, my own posts asking for help should be evidence it that it sometimes is not, but the problems encountered are relatively trivial compared to those of other projects.

But, sooner or later (probably later because managing a retail store during peak Christmas season devours most of the waking hours of my life right now), Elvenblade will have it's own client, so you can judge for yourself then, when I release it.

David Haley said:
The point here is not to criticize anybody's coding abilities but quite simply that (1) people keep asking why this stuff doesn't get done more often, and (2) the answer is straightforward: it involves very real amounts of work, or in any case more than people think when they ask the question.


If after re-reading your post you don't think you're being critical then you probably need to consider how you're wording things. That said, people like to be backseat drivers. We have things we like. It would be great if the things we use did the things we like. But very few people have the proficiency to A: know what is feasible to implement in that setting and B: be technically competent enough to implement it.

David Haley said:
This is all in addition to the fact that people are unlikely to adopt it unless it offered a very compelling reason to change.


This, here, is the actual "issue".

David Haley said:
I think you more or less answered your own question. If I want to use something like ATCP2, I need to add the stuff that makes it useful to me. In doing so, I'm no longer really using ATCP2, and a new protocol fork is born. Furthermore, I wouldn't use ATCP2 in the first place, because I think it suffers from some very major flaws as a data transport protocol (such as the utter silliness around having to add brackets client-side to make messages parseable.

The other reason is that there isn't a lot of point in making them all the same. Let's say that people like KaVir used ATCP2 to send his data instead of MSDP. OK, great; that doesn't really change anything with respect to still needing to implement all of the further graphical elements.

Finally, I think that the whole notion is relatively new to many MUDs, and so things are still evolving.


I did and I didn't. How are they different? What new do the different protocols add? Ironically, that's the same question you would ask about developing a new MUD client; it's relevant in that context, and it's relevant here as well. From the specs I see very little difference between them except for finer points of implementation. Personally I think it only serves as a barrier to adoption when there are various duplicated protocols out there which do the same things; in that light while I do no like the decision personally, I can see the rationale behind zugg going with ATCP2, as it is where a great amount of MUD players are going to be (Aetolia, Imperian, Achaea, et al., and I heard Aardwolf as well).

MUDs have always been fairly slow to adopt new things, a lot of this I think stems from the fact that the average MUD admin is not proficient with coding. I'm not sure I entirely understand why this is the case, though I'd hypothesise that the open availability of open-sourced codebases appeals to people who want to feel they've created a game, and it is certainly easier than creating 3d games. God, I hate the Direct3D SDK. Just saying.

Anyways, I'm tired, so I'm not sure how coherent this is coming out; I think I'll stop the train of thought here while it's at least logically organised.

Maya/Rudha
12 Oct, 2010, David Haley wrote in the 38th comment:
Votes: 0
Saying that A is easier than B does not say that A is easy. Yes, a 3d client is hard. So?
I suppose I will just wait and see how your client turns out. I simply gave my answer to this question that keeps coming up. I would be delighted if somebody proved me wrong with the MUD client of the future…
12 Oct, 2010, KaVir wrote in the 39th comment:
Votes: 0
Rudha said:
As opposed to the alternatives in game design, MUDs and MUD clients are exceedingly easy to make.

They can be. They can also be exceedingly difficult to make. Or they can fall somewhere in between. As with any other software, it depends entirely on what you're trying to do.
13 Oct, 2010, Scandum wrote in the 40th comment:
Votes: 0
For a MUD client all you need is a terminal emulator, PCRE to handle triggers, a scrollback buffer and logging, a scripting language, an input handler, session manager, telopt parser, configuration manager, and an event handler. For many of those libraries or snippets are available.
20.0/62