Mud standards – telnet options – not a standard yet. Lasher, July 12, 2010 It has been a couple of years now since we worked on handling data exchange between the MUD and client using telnet option negotiation. With hindsight, using telnet option 102 for this was probably a mistake as we have since learned that ATCP could have done the same thing, so could ZMP, and a number of other options. The existing support for ‘102’ in the Aardwolf code will remain in place, but no further work will be done on it. Fast forward to the beginning of 2010. The mud community realizes we need better interfaces and an important part of that is new standards for client/server exchange. I was excited to be invited to mudstandards.org earlier this year to take part in discussions to design exactly that. Authors of several clients were already on board including Mushclient, Zmud/Cmud, Mudlet, Tintin++ and possibly others. Admins of several large MUDs were involved and authors of a number of MUD codebases. I really thought we’d come up with something useful. Trying to avoid laying blame anywhere in particular, what we ended up with was (100% in my opinion only): A failed attempt at standards. Two major client authors in disagreement to the point that each declares they are leaving the forum. Many other community members left with the impression that mudstandards.org was only ever created to “rubber stamp IRE ideas”. As this is an opinion piece anyway, I think it’s ok to state that I do think IRE and everyone else involved started out with a good faith attempt to have open discussions leading to a widely adopted standard. It quickly became obvious that agreement was not going to be reached anytime soon if ever. IRE just had to move forward with something, much the same way as we now are. A draft protocol called GMCP, or ATCP2, depending who you ask. There is even argument over the name. No built-in support for ATCP2 in Mushclient, basic support in Cmud and full support in Mudlet. All come with lots of disclaimers that the standard is still very subject to change. Protocol itself is “kind of” JSON. “Kind of JSON” to me is a waste of time. I don’t like the bloat of JSON but it does have the advantage of being a standard. The Facebook API uses JSON, a number of other large services use JSON. There is value in sucking up the bloat and going with a JSON based protocol, if we stick to the standard strictly. If we don’t, I might as well do what I always do and go-it-alone with a streamlined but completely proprietary approach. So here I am, wanting to work on a new version of our Mushclient, wanting to work on some Flex stuff, and with no clearer picture of which protocol to use. This is one of those situations where being a smaller MUD would be better, we’d just choose what we choose and nobody would care. Our experience with the “102” protocol has shown that whatever we pick people are going to request that client authors support it and it will become something of a rogue “standard” even if that was never the intent. One thing I have seen that looks very promising is MSDP which very nicely covers everything we wanted to do with the “102” protocol originally, is very expandable, does not have the JSON overhead of ATCP2/GMCP and will be both easy to implement and easy to modify our existing scripts for. The downside of this protocol is very limited support in most clients and MUDs and if we wanted to use the protocol to exchange binary data, the values ‘1’ and ‘2’ need to be wrapped or escaped somehow. Even MSDP has issues (for us). If I’m going to avoid JSON to avoid overhead then I’m going to avoid overhead. I’m not going to use variables like “EXPERIENCE_TNL” when just “TNL” will do. If another MUD has other meanings for TNL so what? Does it matter with compression? Possibly not, but if we’re forsaking a standard for efficiency then we might as well optimize the efficiency on day 1 when it’s easiest. The MSDP protocol does support this though, and the variables listed are suggestions and guidelines only. So far I’m leaning towards using MSDP for all the work I do myself and for the client/server communication with the new Mushclient package then implementing ATCP2/GMCP longer term for the more general client support. Maybe MSDP will gain more traction and this won’t be necessary, or maybe future discussions will be more successful and the two protocols will merge. I wouldn’t count on it. In the meantime, we need to move ahead with something, knowing it isn’t perfect but is better than what we have today and is a whole lot better than nothing. I wrote this because of many queries about what we plan to do. Most of these queries come from Aardwolf players, but a good number of them come from client authors and other, hmmm, “interested third parties”. Some people a very passionate about this stuff – there is no intent to offend anyone here, only to pick what I believe is the best approach for us right now and to explain the reasoning behind it in one place that we can refer people to. Nothing written here is set in stone, feedback appreciated… MUD News
Aardwolf MUD Update – September 8th 2009. September 8, 2009 Four new goals again in this update: New Goal in Dungeon of Doom: A tremor shakes the ground, revealing a cavern below you. As you descend into the darkness, you realize that you have found it, the fabled Dungeon of Doom… the location of an ancient golem army. The ancient… Read More
Cleric and Paladin spell upgrades, other changes. July 9, 2013 General Game Changes: The web cap when casting on others has been increased from 90% to 95%. Still learning as we go here, might change again, might not. The duration of the Petrify spell is now slightly longer and the recovery will be lower when used against a mob. The… Read More
Auctioneer Wish, Sense Age spell, Exp changes. March 12, 2014 New Wish – Auctioneer: There is new wish called ‘auctioneer’ will allow you to auction 3 items at once. It costs 5k so is definitely a luxury, but has no adjustment cost. Max total items that can be on auction at once has been increased to 50. Experience change for… Read More