15 Nov, 2010, Lyanic wrote in the 21st comment:
Votes: 0
I've experienced a lot of display issues with Blowtorch, as well - very similar to the ones mentioned by ATT_Turan.
15 Nov, 2010, plamzi wrote in the 22nd comment:
Votes: 0
As someone who has developed two MUD clients for a mobile platform, I can assure you that there are many challenges. Multitasking issues and random crashes while connected could very well be OS and network-related–things over which the app developer doesn't have any control.

For a brand new app, it sounds like Blowtorch is off to a very good start and from the dev's posts on mudconnect it also sounds like it has more advanced UI options than AndroMUD. My advice is to share your feedback with the Blowtorch dev and be supportive of his efforts. I'm sure he'll come through if given some positive reinforcement and specifics on how to reproduce any issues you can manage to reproduce.
15 Nov, 2010, KaVir wrote in the 23rd comment:
Votes: 0
jurdendurden said:
That is a really slick iphone mud adaptation. Very intriguing, but have you run into any sort of limitations thus far. For example, the screen real estate limitations on descriptions? Roleplayability? Large scale mud ideas like kingdom wars and things of that nature? How have you overcome these and limitations like them if you have run into them? Can playing the game the 'regular' or 'old' way be a different experience (beyond the graphics/click and point atmosphere; more along the lines of reducing functionality/game play elements)?

His Bedlam client only works for his mud, using a closed protocol - so it doesn't have to worry about compatibility with other muds, nor can other clients use the data from his mud to create their own GUIs.

I'm increasingly tempted to have a go at throwing together a simple mobile phone client (and then expand on it if it works out), but if I do I'll use MSDP.
15 Nov, 2010, Scandum wrote in the 24th comment:
Votes: 0
It's tricky to debug a client with a small user base as only a small percentage of the users bother to report bugs.

I'm curious, what are the main differences between mudding on a mobile and a desktop, and how can a client accommodate to that?
15 Nov, 2010, Kline wrote in the 25th comment:
Votes: 0
Scandum said:
It's tricky to debug a client with a small user base as only a small percentage of the users bother to report bugs.

I'm curious, what are the main differences between mudding on a mobile and a desktop, and how can a client accommodate to that?


Software keyboards, for one. Some programs play nicely when I rotate my phone (myTouch 4G) and others not so much. Some will re-orient the soft keyboard, others will just swallow it into the void leaving me no way to bring it back and therefore no input method :(. Most (all?) phones I've used will preempt any other task when a call comes in, too, so you'd need to handle that gracefully if you were mid-script or something.
15 Nov, 2010, plamzi wrote in the 26th comment:
Votes: 0
jurdendurden said:
That is a really slick iphone mud adaptation. Very intriguing, but have you run into any sort of limitations thus far. For example, the screen real estate limitations on descriptions? Roleplayability? Large scale mud ideas like kingdom wars and things of that nature? How have you overcome these and limitations like them if you have run into them? Can playing the game the 'regular' or 'old' way be a different experience (beyond the graphics/click and point atmosphere; more along the lines of reducing functionality/game play elements)?


Thanks for your interest. Some responses:

* Device limitations: There's a great number of limitations to be overcome, literally hundreds. But after a year of grueling development, I believe I've achieved a client that allows mobile power players to keep up with desktop ones without needing to ever type a command.

* Room descriptions example: I resolved the room description issue by making it so that certain events from the server cause the text up until the next user prompt to be captured in a text dialog. The window is semi-transparent so that they can still see room movements while they read the text. Users can 2tap a room name to trigger a sequence for capturing the room's description. The same text dialog logic is used to capture contents of written notes (2tap note), results from reciting an identify scroll (2tap scroll, 2tap target), and a good number of other events producing large amounts of information. A config file specifies which lines (e. g. "You look closer.") will trigger a text dialog.

* Roleplayability: my MUD is roleplay-tolerated, so people are free to say they need to go linkless to take a call. I guess if you have an RP mud with primarily mobile users, you could come up with some broad in-world explanation about why they frequently have to pop in and out. But overall, I haven't had to make GUI design decisions with RP in mind.

* Large-scale MUD ideas like Kingdom Wars: The GUI does a good job of visually representing generic room changes and capturing mob behaviors. But if you're writing with high usability in mind, you may need to improve or change its handling of certain events unique to your MUD. One example from Bedlam is the PvP arena. While in normal circumstances the GUI separates mobs and players on two different rows, I made it so that while in the PvP arena, the player sees her adversary as if he/she is a mobile. It is possible to further train the GUI to show the members of an opposing team all lined up at the top, where you can easily target them.

I can take more technical questions about how the GUI works in a separate thread, if anyone is interested.

Scandum said:
It's tricky to debug a client with a small user base as only a small percentage of the users bother to report bugs. I'm curious, what are the main differences between mudding on a mobile and a desktop, and how can a client accommodate to that?


First, make it really really easy for your players to contact you. Even then, most of them won't – most will find an issue, real or imaginary, app issue or OS issue, that will frustrate them to no end, and they will find time to leave you a negative review, but no feedback. That's just the way it is :( But some users will eventually write to you, and they make good picks for beta testers. Even with beta testers, expect to do most of the testing yourself. If you're developing a generic MUD client, expect to connect to Chinese MUDs, or to divine which MUD a user is having problems with (they complained at length but forgot to specify).

A modern touch screen smartphone is unlike any desktop so it's easier to list similarities (they both have RAM and a CPU) than differences. For some of the differences between mobile and desktop mudding, the OS will try to help. Things like receiving a call during gameplay are (at least in the iPhone world) taken care of mostly by the OS. User input libraries allow you to make the best of an onscreen keyboard or an external keyboard (in the iPad's case). In my experience, even older people without texting skills quickly get used to typing on the iPhone keyboard – where the app developer comes in is in making sure it retracts and reacts properly, and also, as far as MUD clients go, in making certain common or recent actions easy to send without having to bring up the keyboard.

KaVir said:
His Bedlam client only works for his mud, using a closed protocol - so it doesn't have to worry about compatibility with other muds, nor can other clients use the data from his mud to create their own GUIs. I'm increasingly tempted to have a go at throwing together a simple mobile phone client (and then expand on it if it works out), but if I do I'll use MSDP.


As I've tried to explain here, there is no protocol for the Bedlam app. It is using a combination of trigger events and custom regexes to process the human-readable output. I did not utilize protocols in any way because it was never my intention to build a generic mobile MUD GUI – for this project I wanted to build the best mobile MUD GUI possible, going well beyond a hub with status bars, and buttons sending actions. As I've stated before, I firmly believe that as soon as you want your GUI to support user input like drag and drop, swipe, 3tap, 2tap this and then 2tap that, you're entering uncharted territory, where no existing MUD protocol helps. You'd have to come up with your own protocol, or protocol extension, which can be done, but not easily. To me, protocolizing looked like unnecessary red tape, because I'd already made the decision to sync the app with one specific MUD server. However, now that the app is in production, it is possible to abstract a protocol from it that, in theory, other MUDs can support.

KaVir, in my experience, there is no such thing as a simple mobile phone client. But then again, you're probably a better coder than I am. Keep me posted if you embark on that journey.
15 Nov, 2010, ATT_Turan wrote in the 27th comment:
Votes: 0
plamzi said:
* Roleplayability: my MUD is roleplay-tolerated, so people are free to say they need to go linkless to take a call. I guess if you have an RP mud with primarily mobile users, you could come up with some broad in-world explanation about why they frequently have to pop in and out. But overall, I haven't had to make GUI design decisions with RP in mind.


I'm curious as to why that's necessary - I'm given to understand that with AT&T's GSM network you can have data transceiving during a phone call, and with the newer iOS you can have background processes running, so can't you maintain their link during a call?
15 Nov, 2010, plamzi wrote in the 28th comment:
Votes: 0
ATT_Turan said:
plamzi said:
* Roleplayability: my MUD is roleplay-tolerated, so people are free to say they need to go linkless to take a call. I guess if you have an RP mud with primarily mobile users, you could come up with some broad in-world explanation about why they frequently have to pop in and out. But overall, I haven't had to make GUI design decisions with RP in mind.


I'm curious as to why that's necessary - I'm given to understand that with AT&T's GSM network you can have data transceiving during a phone call, and with the newer iOS you can have background processes running, so can't you maintain their link during a call?


Since iOS4, people can stay connected up to 10 min while doing other stuff on their phone. But still it is true that mobile users are more often idle/afk and linkless than desktop players. It's also true that they log in and out a lot more often (if only to preserve battery life, or because something irl requires their immediate attention). My point was that it's not something I need to explain away as Bedlam is not RPI.
15 Nov, 2010, KaVir wrote in the 29th comment:
Votes: 0
plamzi said:
As I've tried to explain here, there is no protocol for the Bedlam app.

Ah, then I misunderstood - I thought we were discussing an open established protocol vs a closed custom one, I didn't realise you weren't using any protocol (although one could argue that even your custom regexes are a type of in-band protocol).

plamzi said:
I did not utilize protocols in any way because it was never my intention to build a generic mobile MUD GUI – for this project I wanted to build the best mobile MUD GUI possible, going well beyond a hub with status bars, and buttons sending actions.

An out-of-band protocol would still have made it easier to do that, because your mud is also playable through a regular telnet client. You could gag data sent to your own client, but not to a regular telnet client - so (for example) if you had an energy bar showing your health, and it updated from your prompt every second, the poor telnet user would get spammed to death with prompt refreshes. But if you didn't send it every second, the iPhone user wouldn't see their energy bar increase until they tapped the screen, which isn't very nice from a GUI perspective. I suppose you could get the iPhone client to send an empty command to the mud every second, but that's pretty ugly, and it's going to get worse the more data you want your GUI to display.

plamzi said:
As I've stated before, I firmly believe that as soon as you want your GUI to support user input like drag and drop, swipe, 3tap, 2tap this and then 2tap that, you're entering uncharted territory, where no existing MUD protocol helps. You'd have to come up with your own protocol, or protocol extension, which can be done, but not easily.

It's actually very easy, and can be used to send whatever data you wish. The only valid reason I can think of for not using an out-of-band protocol would be if you're targeting muds that don't support it.

plamzi said:
KaVir, in my experience, there is no such thing as a simple mobile phone client.

Well "simple" is a relative term, and admittedly it's been quite a few years since I developed mobile phone applications - but it shouldn't be hard to whip up a basic telnet client, and MSDP is pretty easy to add. The Android SDK offers a range of graphical components, so if I just wanted to draw an energy bar as proof-of-concept I can't imagine it being too difficult. After that it's more of a design problem, trying to come up with a user-friendly interface - that's the part that took a long time with MUSHclient, and I imagine it'll be the same here, but at least my mud is already sending most of the data I'd need.
15 Nov, 2010, plamzi wrote in the 30th comment:
Votes: 0
Quote
An out-of-band protocol would still have made it easier to do that, because your mud is also playable through a regular telnet client. You could gag data sent to your own client, but not to a regular telnet client - so (for example) if you had an energy bar showing your health, and it updated from your prompt every second, the poor telnet user would get spammed to death with prompt refreshes. But if you didn't send it every second, the iPhone user wouldn't see their energy bar increase until they tapped the screen, which isn't very nice from a GUI perspective. I suppose you could get the iPhone client to send an empty command to the mud every second, but that's pretty ugly, and it's going to get worse the more data you want your GUI to display.


On several occasions, I considered sending out-of-band data for some things and each time decided against it. In most cases, I decided that if the info is useful to app users, it should also be shown to text users and interpreted by the app. I believe the end result is less bandwidth, not more. The app reads player status from the prompt, and only redraws hub elements if anything in the status has changed, so the performance is optimal. As for idle regen, no-one has ever complained, but if they do, it would be easy to send out a prompt string every five or ten seconds if the user is idling and if their status has changed. In that case I'd once again be thinking, 'Why send that out-of-band when text users may also want to get an update without sending a line feed'?

On a related note, I would not even consider sending autorefresh info every second to a mobile app, be it out-of-band or not.

Quote
It's actually very easy, and can be used to send whatever data you wish.


I meant it doesn't seem easy to me. Once again, I'm talking about a mobile GUI that *replaces* a text window, not surrounds it. I have built both kinds and I can say it wasn't easy, for me. Based on prior experience, I think it would not be easy (for me) to send all the data that a touch-enabled mobile client will need to determine how UI elements can and should interact.

Quote
The Android SDK offers a range of graphical components, so if I just wanted to draw an energy bar as proof-of-concept I can't imagine it being too difficult.


Energy bars are easy. Almost nothing else is. I encourage you to give it a shot. If the Android development experience is anything like the iDevice one, I think you'll find yourself spending a lot more time fretting over why a text window doesn't scroll to the bottom when the documentation says it should. And scrolling, one can argue, is a lot more important in a MUD client than energy bars.
15 Nov, 2010, KaVir wrote in the 31st comment:
Votes: 0
plamzi said:
On several occasions, I considered sending out-of-band data for some things and each time decided against it. In most cases, I decided that if the info is useful to app users, it should also be shown to text users and interpreted by the app.

My MUSHclient plugin utilises 40 MSDP variables, and none of them are necessarily useful for other users, while some of them are always useless for many clients (such as map data, avatar names or icon IDs). However because they're done through MSDP, if other users do want some of that data (or indeed other MSDP variables that my plugin doesn't use) they can easily access it. Likewise, those who want specific data in their prompt can add it without it impacting their GUI in any way - their health bar doesn't stop updating just because they removed health from their prompt. In fact they can switch off the prompt completely if they wish.

plamzi said:
I believe the end result is less bandwidth, not more. The app reads player status from the prompt, and only redraws hub elements if anything in the status has changed, so the performance is optimal.

My approach uses less bandwidth, because I only send the data that the user has requested, and only if that data has changed since the last time it was sent. You send a full prompt every time the user hits return, but I only send the data that has changed - and I do so regardless of whether or not they've hit return, so their energy bars will update in real-time.

plamzi said:
As for idle regen, no-one has ever complained, but if they do, it would be easy to send out a prompt string every five or ten seconds if the user is idling and if their status has changed. In that case I'd once again be thinking, 'Why send that out-of-band when text users may also want to get an update without sending a line feed'?

I think it's more likely that most users wouldn't want to be spammed with a new prompt every 5-10 seconds.

But the energy bars were just one example. I also use MSDP for maps that update in real-time, so you can watch other creatures moving towards you or running away. If I were to create an Android client I would definitely want the maps (probably with a way to toggle between them due to the limited screen size), but updating them every 5-10 seconds would make them pretty worthless.

plamzi said:
I meant it doesn't seem easy to me. Once again, I'm talking about a mobile GUI that *replaces* a text window, not surrounds it.

That was a reply to your comment about implementing the OOB protocol - the protocol is just a means of transmitting data, it doesn't matter what you do with that data. Just as there's nothing forcing you to use your regexes for drawing a GUI.

plamzi said:
Based on prior experience, I think it would not be easy (for me) to send all the data that a touch-enabled mobile client will need to determine how UI elements can and should interact.

Anything you can send in-band you can send out-of-band, the only difference is that it's easier to identify data sent out-of-band, and you won't send it to people who don't want it.

plamzi said:
Energy bars are easy. Almost nothing else is. I encourage you to give it a shot. If the Android development experience is anything like the iDevice one, I think you'll find yourself spending a lot more time fretting over why a text window doesn't scroll to the bottom when the documentation says it should. And scrolling, one can argue, is a lot more important in a MUD client than energy bars.

Actually if I do decide to work on one (I have to buy an Android first), I may not even bother with scrolling text, due to the limited screen space. I was thinking of just having a map, avatars, bars, buttons and icons, perhaps even have something that looks a little like Gauntlet.
15 Nov, 2010, plamzi wrote in the 32nd comment:
Votes: 0
Quote
Actually if I do decide to work on one (I have to buy an Android first), I may not even bother with scrolling text, due to the limited screen space. I was thinking of just having a map, avatars, bars, buttons and icons, perhaps even have something that looks a little like Gauntlet.


A 2D scroller UI is great because many players are instantly familiar with it. But doesn't it only work with MUDs that have a chessboard layout like your GodWars2? Even if they do have a chessboard layout, I'm pretty sure most of them would allow multiple mobs to "sit on the same tile". This is a perfect example of how, right off the bat, you have to sacrifice universality for your GUI.

Now, maybe you won't go as far as I did in integrating client and server, and maybe you'd be better off with a server supporting MSDP for power players with clients that support it. That's, of course, your prerogative, and of course having multiple protocol support on a server won't interfere with any dedicated GUI's operation. All I'm saying is that once you start thinking about ways to substitute the text window entirely with a GUI, you're entering a different paradigm, and there's yet another paradigm shift when you move from desktop clients to a mobile one–you may find that you need a lot more detail out of your server than you're currently outputting.

Since there's only one of me, I decided to focus on syncing GUI and server rather than adding protocol support in case someone who swears by mudlet or mushclient wanted it and just couldn't live with text-only. Believe it or not, to come out with functional clients, I have spent a great deal of thought on bandwidth, and I think you don't know enough about my framework if you assume that a protocol is inherently more efficient.

Even if there is a way to make everything more efficient via a protocol or via improving regex matching, there is such a thing as getting lost in inconsequential optimizing. I like starting projects but not as much as I like finishing them.

Minor points of difference aside, I'd be very interested to see a mobile MUD GUI that takes a 2D scroller approach. I believe there have been some in Java in the past?
16 Nov, 2010, KaVir wrote in the 33rd comment:
Votes: 0
plamzi said:
A 2D scroller UI is great because many players are instantly familiar with it. But doesn't it only work with MUDs that have a chessboard layout like your GodWars2?

It wouldn't work for most muds, but I'm not too fussed about that - I'd be creating a GUI for my own mud rather than a generic one. Only if I pulled that off would I consider creating something for other muds (basically the same situation as my MUSHclient GUI).

plamzi said:
Now, maybe you won't go as far as I did in integrating client and server, and maybe you'd be better off with a server supporting MSDP for power players with clients that support it. That's, of course, your prerogative, and of course having multiple protocol support on a server won't interfere with any dedicated GUI's operation. All I'm saying is that once you start thinking about ways to substitute the text window entirely with a GUI, you're entering a different paradigm, and there's yet another paradigm shift when you move from desktop clients to a mobile one–you may find that you need a lot more detail out of your server than you're currently outputting.

I've already substituted a lot of text information with GUI elements, and if I need to retrieve more data from the server it's incredibly easy to do so through MSDP. My shift from text to graphics has been a gradual one, but it would only take a little more effort to reach the point where the game could be played without the text window, using only the mouse. I'm not sure if I really want to do that for MUSHclient, but I think it would make a lot of sense for a mobile client.

plamzi said:
Believe it or not, to come out with functional clients, I have spent a great deal of thought on bandwidth, and I think you don't know enough about my framework if you assume that a protocol is inherently more efficient.

Then explain it to me. You've said that your client reads the player status from the prompt. If I recall correctly, when I checked your mud the only telnet option it used was ECHO. That means you can't identify the client, and are therefore presumably sending the prompt every time the client sends other data (i.e., standard mud prompt behaviour). Is that correct? If I'm fighting, you'd send me a full prompt every couple of seconds - every time I enter a command or receive a new combat message?

With MSDP, I don't need to do that. I only send values that have changed, and I only send them when they change. If you're in a fight for 30 seconds without getting hit, the mud won't send you any status information, and when you do finally get hit it'll only send you your new current health value, not a full prompt of status data. I can't see how you could use less bandwidth than that, unless you also compress the data (which I do as well, and which you don't, because you also don't support MCCP).

plamzi said:
Even if there is a way to make everything more efficient via a protocol or via improving regex matching, there is such a thing as getting lost in inconsequential optimizing.

I originally added MSDP because one of my players had written a TinTin++ script that created a fancy status bar by pummelling the server with complex data requests multiple times per second - he distributed his script to other players and it started rapidly gaining popularity.

The player who created the script has 3825 hours of playing time, and the others who used it were also well-established players. They could literally rack up hundreds of thousands of unnecessary data requests per day each, even if they were just idling on their home plane.

With MSDP, users are now able to send their request just once, telling the mud what data they want to track - and the mud only sends back data when it changes. If the player idles on their home plane for the entire day, they won't receive any status updates. I don't consider that an inconsequential optimisation.
16 Nov, 2010, plamzi wrote in the 34th comment:
Votes: 0
KaVir said:
With MSDP, I don't need to do that. I only send values that have changed, and I only send them when they change.


I'm surprised that someone who has implemented MSDP confuses a feature of their implementation with a feature of the protocol itself, which you are well aware is just a format for data. One could just as easily implement MSDP in a way that sends all status data on every main loop cycle and invite everyone to a LAN MUD party.

If the problem is prompt spam during battle, I believe there are more efficient ways to tackle it than implementing a protocol which would only take care of those who use one of few advanced mud clients (and only if they elect to switch their actual prompt off). For one, I'd cut down on or group together battle messages, especially if they don't signify landed hits. Then, I could think about sending the prompt out only when it changes – why should regular telnet users get it if you consider it excessive for those using advanced clients? And if you are over-optimizing, you could go further and only send the value that has changed, just like your MSDP implementation does. Why should simple telnet users have to process the entire prompt in their brains just to find out nothing has changed?

In my current implementation, I've cut down on battle messages, but I've elected to always send out the prompt for reasons I'll share further down. On the client side, I keep a record of the last processed prompt, and skip processing if it's the same as the new one I've gotten. The performance penalty from making that check is minimal because at the time when the app sees a prompt, it also uses this knowledge to close off a 'data block'. That is, the prompt performs the dual duty of a universal protocol message closing string. It's much longer than it needs to be, sure, but it's a 0-implementation-effort 'protocol' that works well enough and lets me focus on other things.

I do share some of your excitement about protocols, and I do think that the more people implement them, the better off the MUD community will be. I just caution against thinking of a protocol as a panacea for every challenge, especially when the end goal is a mobile GUI. There are far, far, greater challenges than choosing the best format to send your data in.
16 Nov, 2010, KaVir wrote in the 35th comment:
Votes: 0
plamzi said:
KaVir said:
With MSDP, I don't need to do that. I only send values that have changed, and I only send them when they change.


I'm surprised that someone who has implemented MSDP confuses a feature of their implementation with a feature of the protocol itself, which you are well aware is just a format for data. One could just as easily implement MSDP in a way that sends all status data on every main loop cycle and invite everyone to a LAN MUD party.

Nope, please read the MSDP specification: http://tintin.sourceforge.net/msdp/

"When receiving a REPORT request the server should send the requested variables to the client, and re-send each individual variable whenever it changes."

While you could in theory do the same in-band, that would be disruptive for someone using a basic telnet client, and our discussion has been in the context of muds that can also be played through other clients. You would also effectively be creating your own custom protocol - a sort of in-band version of MSDP, just as much effort to implement but without the full benefits.

plamzi said:
If the problem is prompt spam during battle, I believe there are more efficient ways to tackle it than implementing a protocol which would only take care of those who use one of few advanced mud clients (and only if they elect to switch their actual prompt off). For one, I'd cut down on or group together battle messages, especially if they don't signify landed hits.

Worth offering as a feature (as I already do), but it's removing information that some may wish to see. It should be optional. It's also a separate issue.

plamzi said:
Then, I could think about sending the prompt out only when it changes – why should regular telnet users get it if you consider it excessive for those using advanced clients?

I consider it excessive to send a regular user a new prompt every few seconds when their screen wouldn't otherwise update (which was your suggestion for the bar refresh problem). Allowing users to only see the prompt when it changes might be suitable as a configurable option, but I think you'd find most users would hate it.

On the other hand, those using a client with graphical energy bars may not want to see the prompt at all. Or they may wish to use a reduced prompt, for covering things that their GUI doesn't.

plamzi said:
And if you are over-optimizing, you could go further and only send the value that has changed, just like your MSDP implementation does.

You could, but as I mentioned earlier, at that point you've just created a poor man's MSDP.

As I pointed out in my previous post, by implementing this approach I prevented literally hundreds of thousands of unnecessary data requests per day. For someone who claims to have "spent a great deal of thought on bandwidth", I find it surprising that you'd dismiss such savings as "over-optimizing".

I was equally surprised at you dismissing MCCP as "highly insufficient" on TMC. Back in 2001 Aardwolf posted MCCP stats showing a bandwidth reduction of 230mb down to 42mb for 234 users - MCCP had reduced their bandwidth usage by five and a half times, down to 18.3% of its original amount.

plamzi said:
Why should simple telnet users have to process the entire prompt in their brains just to find out nothing has changed?

Because a human doesn't read the entire prompt each time, they notice changes. When the data is being processed by the client, however, it's faster (and uses less bandwidth) if you only send the data that's changed.

plamzi said:
In my current implementation, I've cut down on battle messages, but I've elected to always send out the prompt for reasons I'll share further down. On the client side, I keep a record of the last processed prompt, and skip processing if it's the same as the new one I've gotten. The performance penalty from making that check is minimal because at the time when the app sees a prompt, it also uses this knowledge to close off a 'data block'. That is, the prompt performs the dual duty of a universal protocol message closing string. It's much longer than it needs to be, sure, but it's a 0-implementation-effort 'protocol' that works well enough and lets me focus on other things.

But you're still sending the prompt, so it's still eating up bandwidth, and therefore increasing the cost for your iPhone users. Furthermore, because you're sending a full prompt each time, you have to process the entire thing even if just one element changes. All for the sake of saving a couple of hours implementing an out-of-band protocol.

plamzi said:
I do share some of your excitement about protocols, and I do think that the more people implement them, the better off the MUD community will be. I just caution against thinking of a protocol as a panacea for every challenge, especially when the end goal is a mobile GUI. There are far, far, greater challenges than choosing the best format to send your data in.

It's just a tool - but it's one that's simple to implement, and offers clear benefits for the kind of GUIs we're discussing here.
16 Nov, 2010, Scandum wrote in the 36th comment:
Votes: 0
The most efficient alternative that has wide 'out of the box' support (telnet clients and tt++/zmud/cmud) is a server side VT100 interface.

Here's an example of a server side VT100 interface: http://tintin.sourceforge.net/download/p... (for the record, in this implementation only the parts of the blue (non scrolling) areas that change are updated, so if your hp goes from 1000 to 1020 only the y coord (if needed), x coord, and a '2' is transmitted, making VT100 more efficient than MSDP.)

It'll obviously work for vt100 capable mobile telnet clients, and vt100 capable ssh clients running TinTin++ on a remote server (TF mangles server side VT100, but it can do some VT100 client side). Then of course there's the option of a mobile mud client utilizing vt100 (rather than a more graphical library) itself for a basic interface, in which case MSDP once again becomes one of the preferred ways to transmit the data for the interface. I'm not too sure how suitable vt100 is for mobile mudding.

When it comes to data formats it pretty much boils down to GMCP or MSDP, with MSDP being far more compact and customizable for a specific MUD's needs, while GMCP has the advantage of promoting 'out of the box' support when using cmud or mudlet. Especially when dealing with auto mapping, OOB protocols are extremely useful. Using OOB you can create flawless automapping in tt++ using 50 lines of script, and I believe the same goes for cmud, while otherwise you're pretty much fumbling around in the dark, never quite sure if the client and server world is synchronized.

So the main advantage of using OOB over plain text data extraction is that it's a lot less tedious and 100% reliable, while having more or less the same bandwidth when prompts are omitted.
16 Nov, 2010, plamzi wrote in the 37th comment:
Votes: 0
KaVir said:
"When receiving a REPORT request the server should send the requested variables to the client, and re-send each individual variable whenever it changes."


Hmm, this supports my point, not yours. Namely, it's a matter of how well *you* implement the protocol and how much time *you* decide to invest in making the implementation optimal. A sentence in the guidelines doesn't stop anyone from responding to 'REPORT' by dumping the entire contents of the player status object, does it?

What's more important than protocol specifications is do the creators of the protocol provide tools & parsers to help various servers and clients implement it easily and well and in a realistic time frame? I mean, I could hypothetically specify that all data is rar-compressed at maximum rate and that all clients require CPU of 2GHZ+ and embed on-the-fly decompression for maximum bandwidth savings. But does this specification pass the sanity test, and is that a protocol feature per se as opposed to an overly ambitious implementation guideline?

Maybe it took you only a few hours to implement player status sending only on change, but player status is only the tip of the iceberg in mobile GUIs, as I've tried to share with you, unsuccessfully it seems. If you ignore someone who speaks from experience, you do so at your own risk. But who knows, maybe what took me a year will only take you a few days, powered by the magic of MSDP that I've somehow overlooked. It's entirely possible–I'm just a hobbyist.

On the other hand, and with all due respect, I have two mobile MUD clients more than you do, and one of them is a GUI unlike any other. I believe that what I've shared so far on this and other forums are practical solutions to practical challenges. And while I've sacrificed optimization for expedience many times, I believe I have solved the most important challenge – how to do all this by myself.
16 Nov, 2010, KaVir wrote in the 38th comment:
Votes: 0
Scandum said:
So the main advantage of using OOB over plain text data extraction is that it's a lot less tedious and 100% reliable, while having more or less the same bandwidth when prompts are omitted.

I think it really depends on which OOB protocol you're using, and how you're using it. If the prompt is frequently resending the same data, then there are clear benefits in the MSDP REPORT approach (if bandwidth is a real problem you could also use shorter variable names).

The OOB approach also makes it easier to identify which users want specific data - eg if MSP had been OOB, you wouldn't have had to worry about people chatting or emoting sound triggers.

plamzi said:
Hmm, this supports my point, not yours.

No, it really doesn't. The possibility that someone could ignore the specification and create a broken implementation is hardly reasonable grounds for discarding protocols that - when correctly implemented - would provide significant benefits for very little effort.

It's clear you're not interested in those benefits, for whatever reason I can only speculate, but to insist that you've "spent a great deal of thought on bandwidth" and then turn around and dismiss MCCP - which has been proven to lower your bandwidth by several times - leaves me fairly gobsmacked.

plamzi said:
If you ignore someone who speaks from experience, you do so at your own risk … On the other hand, and with all due respect, I have two mobile MUD clients more than you do, and one of them is a GUI unlike any other.

With all due respect, before I moved into the medical industry to develop surgical navigation software, I used to develop mobile phone applications for Sony Ericsson. So please stop waving around your e-peen and put it back in your virtual pants.

I've developed mobile phone applications, I've implemented mud protocols, and I've designed mud GUIs. I understand what's involved, and I think you're missing out on some useful tools.

However at the end of the day it's your client and your decision. There are other mud clients out there (such as GMud) that don't support any mud protocols, so it's not like you'll be the only one.
16 Nov, 2010, ATT_Turan wrote in the 39th comment:
Votes: 0
plamzi, I have not gotten the impression in any of KaVir's posts that he is trying to demean your efforts or the quality of your application - personally, I think it's quite handsome and I watched a bit of your demo video and think it works quite well for a touchscreen interface.

However, (and please understand that I mean no malice or insult here) his comments to you about the advantages of using an out-of-band protocol to receive data necessary to your GUI seem, frankly, obvious. Now if your intent was to create an application to interact with your MUD with minimal-to-no coding changes necessary on your MUD's side, that's fine! If you didn't think of or didn't want to learn how to use an OOB, that's fine! If you felt that using regexes to extract data for your application out of existing text sent by your MUD seemed like the most efficient approach to you, that's fine! If you wanted to keep your application proprietary and not let people easily make their own GUI's for your MUD, that's fine! But don't lower yourself to making up contrived arguments to contest the point.

When you say that you don't want to use MSDP because some other MUD coder could intentionally use the protocol in ways not included in its specification…that doesn't make sense. When you say that KaVir doesn't understand what data is needed for a GUI when the one he wrote for MUSHClient appears at brief glance to display all of the information yours does, that doesn't make sense. When you consider all the major cellular carriers moving to tiered and more restrictive data plans and call nearly any reduction in bandwidth over-optimizing…that almost doesn't make sense :wink:

Perhaps you've gotten so caught up in defending your application that you lost track of what was originally said to you:

KaVir said:
This isn't intended as criticism of your client, but goes back to my point in the other thread: if you were using an established protocol then other clients could offer a custom GUI for your game as well.
16 Nov, 2010, plamzi wrote in the 40th comment:
Votes: 0
KaVir said:
With all due respect, before I moved into the medical industry to develop surgical navigation software, I used to develop mobile phone applications for Sony Ericsson.


There's experience, and then there's experience relevant to the topic at hand, which happens to be MUD clients for contemporary smartphones. I'll grant that you've had more experience in developing when you grant that I have more relevant experience in the particular kind of development being discussed here. There's only one e-peen out and it's preventing you from listening to others. No big deal – I'm sure you're an excellent learner when you make your own mistakes, and I'm sorry if I offended you by implying that I can teach you something. Obviously, I can't.

ATT_Turan said:
plamzi, I have not gotten the impression in any of KaVir's posts that he is trying to demean your efforts or the quality of your application - personally, I think it's quite handsome and I watched a bit of your demo video and think it works quite well for a touchscreen interface.

However, (and please understand that I mean no malice or insult here) his comments to you about the advantages of using an out-of-band protocol to receive data necessary to your GUI seem, frankly, obvious. Now if your intent was to create an application to interact with your MUD with minimal-to-no coding changes necessary on your MUD's side, that's fine! If you didn't think of or didn't want to learn how to use an OOB, that's fine! If you felt that using regexes to extract data for your application out of existing text sent by your MUD seemed like the most efficient approach to you, that's fine! If you wanted to keep your application proprietary and not let people easily make their own GUI's for your MUD, that's fine! But don't lower yourself to making up contrived arguments to contest the point.

When you say that you don't want to use MSDP because some other MUD coder could intentionally use the protocol in ways not included in its specification…that doesn't make sense. When you say that KaVir doesn't understand what data is needed for a GUI when the one he wrote for MUSHClient appears at brief glance to display all of the information yours does, that doesn't make sense. When you consider all the major cellular carriers moving to tiered and more restrictive data plans and call nearly any reduction in bandwidth over-optimizing…that almost doesn't make sense :wink:


In this thread, I try to explain how and why the Bedlam GUI is very different from a MUSHClient hub surrounding a text window. The difference comes after all info is displayed. Users can interact with all the GUI elements by dropping them one into the other, swiping, and thereby triggering all necessary commands without typing. This is the difference between a hub and a full GUI.

It's not at all obvious to me that an out-of-band protocol has advantages apart from making it easier to parse received data. Think of it this way–in tweaking the normal human-readable output of my MUD, I found that with minimal effort I can make it serve a dual function: it is a protocol for the GUI as well as a protocol for the human player. This means one command interpreter on the server end–much easier to debug and maintain as I add features. While I'm aware that a protocol can shave off bandwidth (all those extra words between the data you need), my players have reported under 100MB of monthly data usage for heavy play so I don't see a clear cost-to-benefit incentive to add out-of-band data. I have made many optimizations in terms of sending the app abbreviated output and output on demand, which amount to more bandwidth savings quicker, and which one may argue are a kind of protocol.

You misunderstood the point I was trying to make about MSDP. The logical fallacy in KaVir's argument was that the protocol itself saves bandwidth. In my example of optimizing the human-readable prompt, I try to show that it is the implementation that does. KaVir cited a specific issue of certain power players spamming the server in order to get updates on certain status params changing. By supplying this data out-of-band for clients he knew they were using, he resolved this specific issue. I don't have his issue because 80% of my players use the app and very few of the others use an advanced MUD client. It is incorrect to infer from KaVir's experience that MSDP is an obvious choice for a mobile MUD app. That's all.

I'm sure KaVir is not trying to demean my work. What I think is he has a recent fascination with protocols stemming from his work on the Godwars2 MUSHClient hub and he is naturally excited to carry over that knowledge to mobile app making. I just wanted to point out that there's a lot more to it than a protocol.
20.0/98