19 Jul, 2011, Kaz wrote in the 21st comment:
Votes: 0
plamzi said:
Slight correction: The Android client is called "Blowtorch" and I've heard good things about it. My mobile clients are for iOS (see sig).


My apologies, and thanks for the correction.
19 Jul, 2011, quixadhal wrote in the 22nd comment:
Votes: 0
Yep, this gets back to the text vs. structured data issue.

Right now, all text muds (that I know of) do all the formatting at the server end and spew out text with (optionally) some markup embedded within it. A client then had to catch the text stream and pick it back apart (usually using regular expressions which have to be tailored to each specific MUD) to re-discover the structure of the elements present, and thus present them the way the user wants to see them.

If you're writing a client from scratch, you will be reinventing the same wheels that every other custom client has already had to use, from handling connections, to parsing text as it comes back, to fiddling with windows and widgets and whatever.

Personally, if I were to feel like writing a fancy MUD client, I'd probably download a popular server (Diku, LpMUD, whatever) and modify that to emit structured data (possibly when a setting is toggled), and then write my client to use that structured data stream. When you can show how much easier it is to then adjust the client or modify how it handles displaying things, it might be the thorn that finally convinces all the server dinosaurs that TELNET isn't the way it has to be.

But, that's me. Have fun doing your own thing! :)
19 Jul, 2011, Tonitrus wrote in the 23rd comment:
Votes: 0
quixadhal said:
Personally, if I were to feel like writing a fancy MUD client, I'd probably download a popular server (Diku, LpMUD, whatever) and modify that to emit structured data (possibly when a setting is toggled), and then write my client to use that structured data stream. When you can show how much easier it is to then adjust the client or modify how it handles displaying things, it might be the thorn that finally convinces all the server dinosaurs that TELNET isn't the way it has to be.


Why don't you? Or script/hack an existing client?

Maybe other servers and clients would consider your approach if they saw it in action.
20 Jul, 2011, KaVir wrote in the 24th comment:
Votes: 0
Littlehorn said:
A good portion of the best MUD's out there do the same thing with custom clients. Then those that don't, rely on players to sink time and money into clients (zMUD, Mudlet etc) that are powerful enough to support from-scratch interfaces. Why not have one that has a nice tool that customizes a pre-defined GUI for you out the box that actually looks sexy as hell. :D

Actually Mudlet already lets you offer a predefined GUI. It'll automatically download and install it when the player connects, and Mudlet is free, so there's no need for players to sink either time or money into it.
20 Jul, 2011, Littlehorn wrote in the 25th comment:
Votes: 0
KaVir said:
Littlehorn said:
A good portion of the best MUD's out there do the same thing with custom clients. Then those that don't, rely on players to sink time and money into clients (zMUD, Mudlet etc) that are powerful enough to support from-scratch interfaces. Why not have one that has a nice tool that customizes a pre-defined GUI for you out the box that actually looks sexy as hell. :D

Actually Mudlet already lets you offer a predefined GUI. It'll automatically download and install it when the player connects, and Mudlet is free, so there's no need for players to sink either time or money into it.


I didn't know it actually downloaded it for you when connecting to the MUD itself. That's pretty nifty! I did however see the power of the customization, and of course, the Godwars II pictures of what you've done with the client. Then again, that's something you have to rely on the MUD admins to make. It would still be awesome to have a client that was actually offered it by default for MUD's like mine, who do not sink any time into custom GUI creation for some of the worlds top MUD clients.
20 Jul, 2011, KaVir wrote in the 26th comment:
Votes: 0
Littlehorn said:
I didn't know it actually downloaded it for you when connecting to the MUD itself. That's pretty nifty! I did however see the power of the customization, and of course, the Godwars II pictures of what you've done with the client. Then again, that's something you have to rely on the MUD admins to make. It would still be awesome to have a client that was actually offered it by default for MUD's like mine, who do not sink any time into custom GUI creation for some of the worlds top MUD clients.

Well whichever way you swing it, someone has to invest time. The Mudlet autoinstaller means it's not the players, which is a big plus when it comes to lowering the entry barrier. And for those using my protocol snippet, I've already invested most of the time for you - it took me quite a while to develop, not to mention the design and research required, but now that it's finished it can be installed in about 10-15 minutes.

In theory someone could create a generic GUI and other muds could just link to it. But in practice, I imagine most mud owners would at least want to do some customisation - that GUI is going to represent the way you present your game to every newbie who connects through Mudlet, and it's going to be used in screenshots that promote your mud. At the very least you'll probably want to add your own background and title images.

You could even hold a competition for your players to see who can produce the coolest GUI, if you don't want to take a few hours away from server development to create one yourself.
20 Jul, 2011, Scandum wrote in the 27th comment:
Votes: 0
quixadhal said:
Personally, if I were to feel like writing a fancy MUD client, I'd probably download a popular server (Diku, LpMUD, whatever) and modify that to emit structured data (possibly when a setting is toggled), and then write my client to use that structured data stream. When you can show how much easier it is to then adjust the client or modify how it handles displaying things, it might be the thorn that finally convinces all the server dinosaurs that TELNET isn't the way it has to be.

How is this different from MSDP? TELNET is just a mechanism to flip the structured data switch. There's nothing that stops a MUD from negotiating MSDP and only sending structured data from that point onward.

From what I've seen mapping is gonna be primarily handled by data protocols because it's too much of a kludge to sift through the text stream and figure out what's going on. I doubt we'll ever get rid of the text stream as it's too convenient to have a general purpose 'dump to screen with color codes' mode.
20 Jul, 2011, Runter wrote in the 28th comment:
Votes: 0
Scandum said:
quixadhal said:
Personally, if I were to feel like writing a fancy MUD client, I'd probably download a popular server (Diku, LpMUD, whatever) and modify that to emit structured data […]

How is this different from MSDP? TELNET is just a mechanism to flip the structured data switch. There's nothing that stops a MUD from negotiating MSDP and only sending structured data from that point onward.


If all structured data were created equal it would be the same. However, is MSDP available in 100 implementations across 50 different languages? Does it deliver serializations of all basic types or is it some pseudo-command-language? I don't know if you could do what he wants with MSDP or not, but why would he consider MSDP when the wheel has already been invented... Maybe you mean that MSDP can "flip the switch" and get out of the way. Well, at least that would be closer to the right path. :)
20 Jul, 2011, plamzi wrote in the 29th comment:
Votes: 0
Runter said:
Scandum said:
quixadhal said:
Personally, if I were to feel like writing a fancy MUD client, I'd probably download a popular server (Diku, LpMUD, whatever) and modify that to emit structured data […]

How is this different from MSDP? TELNET is just a mechanism to flip the structured data switch. There's nothing that stops a MUD from negotiating MSDP and only sending structured data from that point onward.


If all structured data were created equal it would be the same. However, is MSDP available in 100 implementations across 50 different languages? Does it deliver serializations of all basic types or is it some pseudo-command-language? I don't know if you could do what he wants with MSDP or not, but why would he consider MSDP when the wheel has already been invented... Maybe you mean that MSDP can "flip the switch" and get out of the way. Well, at least that would be closer to the right path. :)


Ya. Where is our universal third-party-configurable JSON MUD GUI client? I'd be happy to support it.
20 Jul, 2011, Littlehorn wrote in the 30th comment:
Votes: 0
KaVir said:
Littlehorn said:
I didn't know it actually downloaded it for you when connecting to the MUD itself. That's pretty nifty! I did however see the power of the customization, and of course, the Godwars II pictures of what you've done with the client. Then again, that's something you have to rely on the MUD admins to make. It would still be awesome to have a client that was actually offered it by default for MUD's like mine, who do not sink any time into custom GUI creation for some of the worlds top MUD clients.

Well whichever way you swing it, someone has to invest time. The Mudlet autoinstaller means it's not the players, which is a big plus when it comes to lowering the entry barrier. And for those using my protocol snippet, I've already invested most of the time for you - it took me quite a while to develop, not to mention the design and research required, but now that it's finished it can be installed in about 10-15 minutes.

In theory someone could create a generic GUI and other muds could just link to it. But in practice, I imagine most mud owners would at least want to do some customisation - that GUI is going to represent the way you present your game to every newbie who connects through Mudlet, and it's going to be used in screenshots that promote your mud. At the very least you'll probably want to add your own background and title images.

You could even hold a competition for your players to see who can produce the coolest GUI, if you don't want to take a few hours away from server development to create one yourself.


I personally do not care if my name is on it, but I guess some people would for some ungodly reason. I don't suspect the amount of people screenshotting a MUD client warrants me caring enough to have my name on the client. I mean, if they are playing your game, who cares :P

Anyways, lowing the entry barrier is key. I think having a client that provides an epic GUI to what I was mentioning would be cool if it could come standard and customizable for the players needs. :)
20 Jul, 2011, KaVir wrote in the 31st comment:
Votes: 0
Littlehorn said:
I personally do not care if my name is on it, but I guess some people would for some ungodly reason.

Not your name, but your mud's name, and appropriate background images and icons to fit your theme. Exactly like you've already done with your banners and website, and for much for the same reason.

Littlehorn said:
I don't suspect the amount of people screenshotting a MUD client warrants me caring enough to have my name on the client. I mean, if they are playing your game, who cares :P

Just because they connect and autoinstall the GUI, it doesn't mean they're going to stay. If you log on to a mud and the GUI is exactly the same as the last twenty muds you've tried, what would be your first reaction? Now if I logged on to Devil's Silence and I get some gore-drenched background image, with energy bars shaped like rusty blades and a series of stylised skull buttons across the top, it immediately makes a statement about the mud. Presentation is always important, but particularly so when it comes to graphics.

Littlehorn said:
Anyways, lowing the entry barrier is key. I think having a client that provides an epic GUI to what I was mentioning would be cool if it could come standard and customizable for the players needs. :)

My point is that we've already got exactly that, everything you need is already available. It wouldn't require more than a few hours to customise a GUI for a particular mud. But the sad truth is that most mud owners simply aren't interested.
20 Jul, 2011, plamzi wrote in the 32nd comment:
Votes: 0
KaVir said:
My point is that we've already got exactly that, everything you need is already available. It wouldn't require more than a few hours to customise a GUI for a particular mud. But the sad truth is that most mud owners simply aren't interested.


That's very true. It's also true (and we tend to forget) that the field is populated with hobbyists. Not only does their level of expertise vary greatly, but for many of them having fun is almost more important than having players. I think that explains why many MUDs don't have even the most basic GUI just as it explains why every other person is writing their own codebase or their own MUD client. People generally do what they consider fun.
20 Jul, 2011, Littlehorn wrote in the 33rd comment:
Votes: 0
KaVir said:
Not your name, but your mud's name, and appropriate background images and icons to fit your theme. Exactly like you've already done with your banners and website, and for much for the same reason.


I know what you mean, but a game client is not the same as banners on a website or the website that's seen by potential players at a lower entry barrier. The game client is only seen by the player already playing your game or those who actually take the time to download a custom client, or log in the game to see your custom GUI.

Having your MUD name there is not as important as say, having advertisement for something in-game that you want to pull your existing players to experience (or buy if you do F2P models). Other than that, unless your client is being screenshotted or youtubed alot, it's not as important. On the other hand, if you're worried about others stealing your stuff, then a name would help identify that your client belongs to you mud. But then again, if it's a custom GUI, it's not like they can't change it! :D

KaVir said:
Just because they connect and autoinstall the GUI, it doesn't mean they're going to stay. If you log on to a mud and the GUI is exactly the same as the last twenty muds you've tried, what would be your first reaction? Now if I logged on to Devil's Silence and I get some gore-drenched background image, with energy bars shaped like rusty blades and a series of stylised skull buttons across the top, it immediately makes a statement about the mud. Presentation is always important, but particularly so when it comes to graphics.


Had a response here, but I realized your commenting on those who made custom GUI's for Mudlet and those who didn't. That's an entirely different process where the client pulls files per MUD where I'm talking about a client that has it installed before connecting to the MUD. Because sure, you could say the first impression is bad simply because our MUD didn't take the time to make a custom GUI for Mudlet as opposed to say, your MUD. But, we are talking about a different client altogether. We're talking about a client that gives you a tight looking GUI out the box and the end user has tools to customize it the way they see fit. It's going to be basically the same for every MUD they play on from that point on, and our MUD wouldn't be held accountable for the reaction as we have no control over that client as opposed to what you have control with Mudlet's GUI.

KaVir said:
My point is that we've already got exactly that, everything you need is already available. It wouldn't require more than a few hours to customise a GUI for a particular mud. But the sad truth is that most mud owners simply aren't interested.


I could see myself spending a few days if not a month customizing something that I feel is worth it. I actually hate the idea just because I know my players enjoy using clients they want to use. Some love JMC, others love Mudlet, and then for me, I love zMUD/CMUD. Overall, trying to appeal to all of those players plus making the GUI worth the effort can be a pain. I rather have something that's default out the box (like a default GUI with nice buttons, sexy images etc) and allows the end user to customize it without having myself spending hours of time trying to make it happen.
20 Jul, 2011, quixadhal wrote in the 34th comment:
Votes: 0
Scandum said:
How is this different from MSDP? TELNET is just a mechanism to flip the structured data switch. There's nothing that stops a MUD from negotiating MSDP and only sending structured data from that point onward.

From what I've seen mapping is gonna be primarily handled by data protocols because it's too much of a kludge to sift through the text stream and figure out what's going on. I doubt we'll ever get rid of the text stream as it's too convenient to have a general purpose 'dump to screen with color codes' mode.


It's different because you aren't having to make assumptions, on the server side, about what the client might or might not be able to do. If you have a structured data language, what purpose does TELNET serve? TCP already guarentees data delivery. There isn't any concept of "in-band" or "out-of-band" when you're working with data packets. You don't need to try to interrogate the client to decide if you can use ANSI sequences, or XTERM sequences, or if it's 127 characters wide, or if it can handle scrolling regions… none of that matters to the server.

You won't get out of the text stream, as long as you continue to cling to technologies that were designed for environments that no longer exist. If the MUD server emits JSON packets, the client could be a simple as receive packet, print contents to screen, wrap user-input in a packet and send to MUD. I think most MUD's would want to have a bit tighter integration, so the client does much of the sanity checking and input parsing for them.

In modern MMO's, the client does much of the work, taking the user's input and determining if it's potentially valid before sending a packet to the server at all. If you type cast lightning bolt at bob, and no spell lightning bolt exists, or you aren't a mage who knows that spell, or you don't have to right spell components, or you're out of mana… there's no need to even involve the server. If those things all check out, you can send something preparsed like { "cast" : { "name" : "lightning bolt", "target" : "bob" } }. Now the server doesn't need to pick apart your arguments and waste time parsing and validating that stuff. It can just look at the data, decide if bob is there and in range, double-check that you can indeed cast the spell (in case conditions changed), and do whatever "lightning bolt" should do to bob, sending the appropriate formatted message packets to you, bob, and anyone else in the room.

Why is that better? You might have a semi-graphical client where you had an isometric display of the room and you clicked on Bob's icon and picked 'cast' from a right-click menu, selecting lightning bolt. Guess what? The server doesn't need to CARE. As long as the pretty graphical client sends the same data packet, it doesn't even need to know.

Why can't you do all that with TELNET and MSDP? You can. Nobody wants to. Given the choice between using an industry standard library that I can just call a couple of API routines and send the result over the socket, vs. having to hand-code some fiddly IAC sequences I copied from your C implementation to use in my web-based Flash client… JSON wins.

I'm not proposing any kind of "universal JSON standard". I don't think it's appropriate, because MUD's vary too much to have that much in common. You found that out trying to pigeon hole them into having just a single genre category. I could say the majority of games out there would likely implement things like "room_description", or "exits", or "incoming-damage" messages… but how about a mud which doesn't use rooms? How about a game that doesn't have combat?

But, using JSON, you could make the case for it being a universal carrier, much like TELNET has been. If a given MUD emits JSON packets, you know a JSON client can talk to it. If the default behavior is to dump unrecognized packet types into the main display window, and to send unrecognized user input as a generic "data" packet, it wouldn't be hard to say you're in almost the same place we are right now with TELNET, minus the IAC state machine requirement.

Will we get rid of color markup? Nah, doubt it. While having each bit of data seperated into a proper packet type (which the client can display as it likes) takes care of what many of us really use color for, there are always gonna be people who want to have a RED apple in their room description. But color codes can certainly co-exist, as they do now. The only suggestion I have is that anyone making a data-driven game that is intended for non-TELNET clients might wish to select a color markup system that's already popular and widely used, such as HTML, rather than some cryptic one that has to be converted to equally cryptic escape sequences. Again, escape sequences are for YOU to control a terminal. Ideally, the client is the one in control of display, so a markup should remain that… a markup, which the client can decipher and implement (or ignore) as it sees fit. HTML is ugly, but it's well established and understood.
20 Jul, 2011, Runter wrote in the 35th comment:
Votes: 0
Quote
HTML is ugly, but it's well established and understood.
I agreed with you up until this point. I think good html/css is great and can be quite nice to read.
20 Jul, 2011, KaVir wrote in the 36th comment:
Votes: 0
Littlehorn said:
I know what you mean, but a game client is not the same as banners on a website or the website that's seen by potential players at a lower entry barrier. The game client is only seen by the player already playing your game or those who actually take the time to download a custom client, or log in the game to see your custom GUI.

I consider them very much the same thing. If a prospective player clicks on a link that leads to your website, the presentation of that website will have a big impact on whether or not they decide to play. Likewise, if a prospective player clicks on a link that leads directly to your mud, the presentation of your mud will also have a big impact on whether or not they decide to hang around.

Presentation is very important whether you're using graphics or not - there's a good reason why many muds put extra effort into the newbie experience for example. But graphics can take it a step further, and a plain text website is not going to attract as much interest as one that makes good use of fonts, textures, images, etc. The same is true when connecting to the mud.

This is also one of the big advantages of browser-based clients - the prospective player only has to click on a link, and you can immediately present them with a custom interface containing graphical elements. But compare the presentation of the generic FMud client with the customised version used by Maiden Desmodus or SlothMUD, and there really is a world of difference.

Of course many mudders already have a favourite client, and will use that to connect directly to whichever mud they wish to check out. If that favourite client happens to be (the latest version of) Mudlet, and they connect to my mud, they'll immediately be presented with a custom GUI.

I don't see how the OP could top that to be honest - particularly as his client only runs on Windows. Mudlet runs on a range of platforms, it's open source, feature-rich, and it already has a dedicated following. If you wanted to create something with an even lower entry barrier, I think your only choice would be a browser client like I mentioned earlier.

Littlehorn said:
What I mean is basically, why would their first reaction be bad because of the GUI that our MUD has no control over?

Because they'll be comparing it with GUIs that other muds do have control over. They won't care why you've got a "stock" interface, only that you have got one.

Littlehorn said:
I could see myself spending a few days if not a month customizing something that I feel is worth it.

You can spend as much or as little time working on it as you feel appropriate, but a basic GUI can be thrown together in a few hours.

I've heard the argument before, that it's not worth creating a GUI unless you do something amazing - some even argue that unless it's comparable with a modern MMO, it's not worth it. But I strongly disagree with that sentiment. Even a simple GUI is a worthwhile improvement over a plain terminal window.

This is the direction many of the bigger muds are going. Personally I think it's pretty cool, and I've jumped on the bandwagon and tried to encourage others to do the same. But I think it's going to take years yet before it becomes mainstream - as plamzi says, for many mud owners it's just not something they consider fun.
21 Jul, 2011, Ssolvarain wrote in the 37th comment:
Votes: 0
The only thing I want to see, client-wise, is something as clean, intuitive and simple as GMUD.

Specific features I'd like to see and have use for as a non-scripting player and immortal:
-timed triggers
-wider range of color support, with the option to change default colors
-profiles, where I might want alias/macro/trigger set A for Pict, but I would want a different set for End of Time. Included color swaps might also be good…
-multi-window and protocol support. If the mud sends out an overhead map on one specific band, I'd like to be able to set a window to listen specifically to than band.
-little boxes of drag-able size to display things in numeric/graphical form

All that in an interface that looks nice and clean when you turn off most of the tool bars (because I like to have maximum vertical space for obvious reasons).


And as far as large-scale graphics goes… meh. I never cared for rogue-likes ;)
21 Jul, 2011, Littlehorn wrote in the 38th comment:
Votes: 0
KaVir said:
I consider them very much the same thing. If a prospective player clicks on a link that leads to your website, the presentation of that website will have a big impact on whether or not they decide to play. Likewise, if a prospective player clicks on a link that leads directly to your mud, the presentation of your mud will also have a big impact on whether or not they decide to hang around.

Presentation is very important whether you're using graphics or not - there's a good reason why many muds put extra effort into the newbie experience for example. But graphics can take it a step further, and a plain text website is not going to attract as much interest as one that makes good use of fonts, textures, images, etc. The same is true when connecting to the mud.

This is also one of the big advantages of browser-based clients - the prospective player only has to click on a link, and you can immediately present them with a custom interface containing graphical elements. But compare the presentation of the generic FMud client with the customised version used by Maiden Desmodus or SlothMUD, and there really is a world of difference.


Sure, having a custom flash or java client in your browser does help with the presentation. I just don't think it's worth it in the long run because so many mudders use their own custom clients. I think to newer players who never played a MUD before, such a presentation would hook them more than saw you average JMC or zMUD user.

KaVir said:
I don't see how the OP could top that to be honest - particularly as his client only runs on Windows. Mudlet runs on a range of platforms, it's open source, feature-rich, and it already has a dedicated following. If you wanted to create something with an even lower entry barrier, I think your only choice would be a browser client like I mentioned earlier.


That would be awesome too. Technically, I don't see why you couldn't just use Unity or Torque (2D/3D Graphical Engines that port to your web browser) to do that tbh.



KaVir said:
I've heard the argument before, that it's not worth creating a GUI unless you do something amazing - some even argue that unless it's comparable with a modern MMO, it's not worth it. But I strongly disagree with that sentiment. Even a simple GUI is a worthwhile improvement over a plain terminal window.


I guess I would agree too, because it's very important to pull people away from what they've already been doing, playing 2D/3D graphical games. Even offline games have very nice GUI interfaces, but mostly, competing with the MMO genre is as important when it comes to making that transition better.

KaVir said:
This is the direction many of the bigger muds are going. Personally I think it's pretty cool, and I've jumped on the bandwagon and tried to encourage others to do the same. But I think it's going to take years yet before it becomes mainstream - as plamzi says, for many mud owners it's just not something they consider fun.


Well, it's def not bad to do it. I'm just trying to justify the time if it's worth the return.
21 Jul, 2011, Scandum wrote in the 39th comment:
Votes: 0
Runter said:
If all structured data were created equal it would be the same. However, is MSDP available in 100 implementations across 50 different languages?

Parsing JSON is about 100 lines of straight forward code, which is the reason why it's available in 100 implementations across 50 different languages, just like strlen(). I'll admit I'd be annoyed if I had to write my own strlen() function, but I wouldn't call it a deal breaker.
21 Jul, 2011, Runter wrote in the 40th comment:
Votes: 0
Scandum said:
Runter said:
If all structured data were created equal it would be the same. However, is MSDP available in 100 implementations across 50 different languages?

Parsing JSON is about 100 lines of straight forward code, which is the reason why it's available in 100 implementations across 50 different languages, just like strlen(). I'll admit I'd be annoyed if I had to write my own strlen() function, but I wouldn't call it a deal breaker.


Yes, JSOn is easy to implement. Yes, it's the strlen() of data serialization. You're making my point for me. What does that have to do with justification for My Silly Duplicate Protocol?
20.0/50