Uh huh :P

But as I said before, the GMud client manages to fill a niche without any protocol support, so I guess there's no reason why your client couldn't be the iPhone equivalent of GMud.

However modern clients (and muds) are increasing using mud protocols for GUI development, so that's definitely the direction I'll be going if I decide to create a mini version of my GUI for a mobile platform.

One can quite easily identify a custom client from other clients without implementing any Telnet. i.e. Pueblo and MCP.
From there you can send the client anything you want, when you want, and in any format you want.
Presumably you adhere to some "protocol". Whether it's custom or standardized isn't really relevant if you control both client and server.
If one thinks it's useful and generic enough maybe you publish it. :-)

You could, but then you'd be using some sort of protocol, and his post seemed to suggest that he's not using anything beyond the standard in-band stream (although he does use ECHO and ANSI colour, but I think those came as stock in his codebase).


I'd agree, except that his server can also be played with other clients, and apparently his iPhone client just uses regexes to capture the data it needs from the in-band stream. As a result, any data his mud sends will go to all clients, whether they want it or not.

Automapping - Now that's an interesting topic. I've been researching ways to add that to my app, but I'm not ready to share any findings or make any decisions yet. One unique aspect of my situation is I'd have to be writing both the server piece and the renderer, and I'd love to have a renderer that all my players can "tune into" (not just those on TinTin or the Bedlam app). Who knows, maybe I'll end up using an out-of-band protocol. Or not :)

I don't know whether he is or isn't. I was pointing out that from "…when I checked your mud the only telnet option it used was ECHO. That means you can't identify the client…" isn't a correct conclusion. Pueblo and MCP being examples of protocols self identifying on connect via in band messages. The user self-identifying via setting options and answering question like ANSI color support is also another common mechanism. Telnet support is orthogonal to client identification, protocol implementation, and in handling both custom clients and generic clients at the same time.



I'd call that a "screen scraper" application. There are advantages and disadvantages to that. First, the protocol is probably more brittle. The protocol being the standard stream. If one changes the format of the score sheet or prompt or whatever messages the client relies on, then one need modify the client, and likely, more frequently than if one is sending the data in another format. OTOH, with screen scraping it ensures that the custom client doesn't get any advantage from access to any more data than what is available to other clients.



The inverse is the scripted client can always be automated to get the updates it wants, suppress the output, and still not interfere with the operation of other clients using the server.

Tyche is correct on all counts. The server can identify app users (so, over time, I can optimize the info that goes out to them and let it evolve into a protocol). Screen-scraping is indeed more brittle. The client can be, and is, smart enough to only request and display data triggered by user actions (like a protocol, except for the extra words between the essential info).

One advantage of screen-scraping that hasn't been mentioned yet is that the app can theoretically be trained to visualize any MUD roughly similar to the fantasy CircleMUD it currently connects to, regardless of whether they support any protocols at all. It won't be as streamlined, but just changing the regexes and the main config file will get about 70% of the functionality going.

Would you really want to do that for a mobile client though, where bandwidth is a high concern? Assuming you're using the standard command interface (as he's said he's not interested in a custom protocol), that could potentially mean sending the entire score layout to the client just to extract one value - a value that might not even have changed.

I don't understand the preoccupation with bandwidth, especially since we're talking about MUD servers. In the mobile gaming world, a MUD GUI would be competing against shallow 3D slashers and browser-based MMOs (now fading from view) and MUD transfer rates are much closer to the latter than the former. Because most MUDs don't send coordinate data for entities, they are natural-born servers for mobile gaming, offering real-time experience and great depth to boot. We played them on dial-up modems which were slower than any modern smartphone, and for the most part we suffered no lag.

As for total data transfer, up until iPhone4 100% of Americans had an iPhone with an unlimited data plan. The average limited data plan in Canada is 200MB per month for around $30. Monthly transfer for playing Bedlam intensively on the phone is about half that. In my very rough estimates, loading the New York Times homepage in a mobile browser (something I do about 5 times a day) is roughly equivalent to playing a MUD for 4-5 hrs.

Is the concern about server costs, then? Unlimited cable costs $40 a month in my area, and a great Ubuntu box can be put together for about $200. Incidentally, it's what I have in my feet right now. Problem solved.

When I said I put a great deal of thought into bandwidth, I meant specifically in terms of app responsiveness. Mobile CPUs are weak, routinely underclocked to save battery life, and they're further bogged down by maintaining more essential processes than a third-party app. Also, mobile APIs will sometimes require you to load super-heavy multi-purpose libraries just to perform a simple task. The perfect example in iDevices is that you need to instantiate an entire browser to be able to display multicolored text (no kidding). So you definitely need to optimize the parser to a reasonable degree, and you definitely need to worry about how many GUI elements the RAM can hold and animate.

While I totally agree that a protocol is the most efficient means of communication, I believe my 'quick' solution is almost as optimal on the client side and does the job. To me, talking about a protocol is a bit like refusing to walk until you have hand-crafted curved-sole running shoes on. I don't have a team of shoemakers, so here I am walking in my sandals and loving it. Figure I can always put on running shoes later, if I come across any that fit.

Sorry to go off-topic, but that's bs :P Anyway, back on topic!

MCCP allowed Aardwolf to reduced its outgoing bandwidth to 18.3%. If Bedlam gained that same compression rate, the 100mb would be reduced to 18.3mb - and if you're assigning a dollar value to that bandwidth, that would mean $2.75 per month instead of $15 per month to play Bedlam.

And that's even without looking at other protocols for filtering unused data at the server end.

But we've been over this, and it's not going anywhere. You've made it clear you're not interested in implementing any protocols, so don't - it's not as if I'm going to egg your house just because I disagree with your solution.


To me, it's more like running a marathon in your socks because you don't want to waste 30 seconds putting on your shoes at the start - and then when another runner suggests putting your shoes on, telling them that you've run two marathons before, and don't see why shoes are so important anyway.

I don't really know. I had thought latency was more of an annoyance with cell-phone technology.



The interesting thing about a lot of DikuMuds is every 40 seconds you get a prompt, and you get one every time you get a state change message.
So you could just make all the data one needs for the client interface available in the prompt and have the client set the prompt up after logging in.
That's close enough to implementing MSDP.

That was the common approach before OOB protocols started becoming popular, and many people still use it, but it suffers from a number of problems such as:

1) You only get an update when the prompt changes, so things like energy bars and tactical maps won't refresh unless you keep hitting enter.

2) It relies on a specific prompt pattern, so you can't customise your prompt, or switch it off.

3) The prompt is resent in full, regardless of whether anything has changed, so you'll receive a lot of redundant data.

4) If you want a lot of information in your GUI, it may not be appropriate to include it all in the prompt - for example a list of all your skills or spell affects, or a tactical map showing the position of other players and mobs, or a set of inventory icons.

I've seen 6 line prompts to generate a tactical interface, typically including unneeded color codes, that's at least 500 bytes. Imagine a large MUD, lots of chatter, lots of stuff going on, combined with combat, might result in 1 prompt per second on average, so that's 0.5 KB/s per player, say 200 players, that's 100 KB/s for the entire server. With MSDP, if done right, you'd use a fraction of that.

Now few people screen scrape to generate tactical interfaces, but as a good tactical interface gives a large advantage it's a matter of time till someone writes a good script and spreads it around. I've seen at least a dozen scripts like that for tt++, and I wouldn't be surprised if in a couple of years it's the norm rather than the exception.

As I mentioned earlier, when my players first started using tactical interfaces, they were sending data requests multiple times per second to ensure that their interfaces were always up to date - I would be surprised if nobody did the same on any other muds.

And because the client is doing it automatically, the updates aren't just during combat - they're constant, even if the player idles for hours on end.

However if you only ever have a handful of players online at any one time, and most of those are using a custom client that doesn't allow scripting, the issue may never come up.


Yes, that's exactly what happened on my mud.

You can make anything look like bs if you quote selectively. Lag is never going away. What I meant was that dialup has enough throughput for normal MUD playing. With a solid provider, I could play a MUD connected at as little as 11K. If your dialup experience was much worse than mine, I'm sure the reasons for that lie elsewhere. It goes without saying that data compression and optimization do not dispel lag caused by various router issues along the way - they lower total transfer rates only.



Again, Tyche is right. I did not see much use for current protocols beyond sending hub info, and it was info I could grab from a custom prompt almost as easily. Call it a 0-effort protocol. But, like I've said repeatedly, the hub is trivial compared to the complexities involved in the rest of the GUI. Maybe you have to build one to believe me.



I won both my marathons. Are you sure that my socks are not as good as your running shoes?

Of course, this is a false comparison. In my experience, code related to transferring data that current MUD protocols could have carried forms about 0.5% of the work in my Bedlam app. I imagine a marathon runner's shoes are a lot more important than that.

I have built a GUI (well a few, really, but only one serious one), and while the protocol work is not exactly trivial, it is certainly straightforward, and well worth the returns for such a small investment of time. That's why your attitude towards protocols like MSDP and MCCP confuses me. Maybe you have to implement one to believe me.


You completed your marathons, you didn't win them. I've run both with and without shoes, and my intent wasn't to criticise your socks, only to point out the advantages of shoes.

Well, no, actually, it's more like saying that, while you haven't run this particular marathon yourself, it seems to you that the proper way to do it is to have Nike's on and not Reeboks, and that real marathon runners make their own shoes. As Tyche has correctly pointed out, the advantages of a protocol over a smartly handled user-readable output are not radical. You can even call what I've already done a protocol. By tweaking and evolving it, I can achieve a performance similar to any official protocol.

Again, I'd like to point out that we're splitting hairs over technicalities. There are a lot more interesting and significant things to talk about in mobile MUD GUIs than what kind of stamp you put on your form 1029.

I see.

Anyway, for anyone else who might be considering creating a mobile client, I would strongly urge them to at least have a quick read over this: http://mccp.smaugmuds.org/notes.html

Is it worth investing a few hours to implement a protocol that you don't find interesting if by doing so you'll reduce the bandwidth of your users to less than a fifth of its original amount? That's up to each reader to decide for themselves. But I would urge people to at least make themselves aware of the available options before making a decision, and take a look at what major muds and clients are doing.


As far as the GUI side is concerned, one thing I've found with MUSHclient is that I'm gradually building up a library of specialised components, and it's fairly quick to adapt them to other muds - I created a simple GUI for SlothMUD in around 2-3 hours, then created a GUI for another mud in about an hour. Tavish was also able to create a custom GUI in a few hours, and I'm hoping more mud developers will follow (because I'm interested to see what sort of designs other people can come up with). In theory there's no reason why the same couldn't be done for a mobile platform, providing an infrastructure that developers could use to rapidly produce custom interfaces for their games - and it looks like DecafMUD may eventually offer a similar option for browsers. I think these are all interesting ways to pull fresh blood into the mud community, and it'll be interesting to see what happens in the next couple of years.

Regarding the running metaphor, people might want to check out the book "Born to Run" – you might find that we generally have several misconceptions about running, this whole shoe business being an interesting one.

In other news, I'll need to bookmark this thread to refer to the next time a certain poster gets snippy again about other people not having some very particular development experience and therefore any argument they provide must be wrong. It would seem that it suffices in fact to show one's other experience to end that particular attack. (Well, that's what I would have thought in the first place, but apparently this person didn't think so until they were told themselves that they're missing experience…)

Plamzi, you should take the good points out of KaVir's posts (there are several) and ignore his sophistry, such as his fast switching of MCCP and MSDP, or his disingenuous selective quoting in order to win some argument. You should consider MCCP, for example, but of course MCCP is not what you were talking about when you said you didn't have a protocol and weren't at present interested in one. Don't let his attitude turn you off from the things he's saying, basically.

Also, FWIW, I agree that developing on mobile clients poses a number of very interesting challenges that you don't see on the desktop, although I think that's been more or less agreed on by now finally (I am traveling and so am late to the party). That said, experience from several years ago is not necessarily terribly relevant anymore, or at least needs to be adjusted, especially when you look at new phones like the Android phones. With the iPhone at least you have some certainty that all devices behave the same and only have to worry about version numbers. Androids are a whole other story, with many devices all having different capabilities, memory capacities, etc., which can make development confusing sometimes. In some sense, by targeting the iPhone, you have it easy. :wink:

I was miffed not at the verbal sophistry so much as at several attempts to explain to other people what my GUI was doing, and several instances of false comparisons between my GUI and a custom MUSHClient hub. I readily admit that KaVir's core competence and experience in MUD development far exceeds mine, and I'm aware he has established rapport in forums where I'm just a newcomer. That said, it was difficult for me to stand by and watch my work being talked down, however subtly, on the basis of a technicality (protocols). It was also difficult for me not to raise a hand when certain comments amounting to "but this is sooo easy" came from a person who has not really done this exact thing and were directed and someone who has. Perhaps I overreacted but, having never developed a MUSHClient UI, I would not presume to tell anyone how easy it is.

Believe it or not, I have taken some good points from the discussion of protocols and already shared with KaVir in another thread that GMCP's similarity to JSON makes me consider it for a future date. Now, we can just hope that we've had at least some two-way communication on this.