27 Jun, 2010, 3squire wrote in the 21st comment:
Votes: 0
KaVir , Runter and others,

You are missing the more fundamental point being made here, which is that MUDs as they are conceived today are not fundamentally like other games. They are usually single developer, hobby-driven, and they bend over backwards to support the dumbest possible clients. Ebooks have more advanced functionality than most muds today. It's just, you're arguing across paradigms and so your bound to be unable to comprehend each others points.

The fundamental point, is that you think of your game as something more fundamentally "game" like and less fundamentally "mud" like, than writing a custom client becomes a no-brainer. "MUD" as a genre seems to have a certain manifesto of things, however, which often involves a taken-for-granted belief that the important part of a mud is the size, game features, etc. even while many "games" have taught us that crappy stories and crappy elements can be absolutely overridden when a game is beautiful, or just damn fun to play.

What that means for this discussion is simply that MUD developers put their time toward one and not the other, but it would not be inconceivable for them to consider that, in fact, they are mis-allocating their efforts.

Also, read this about incentives in developing for one or many clients, protocols, standards, etc: http://www.joelonsoftware.com/items/2008...
27 Jun, 2010, KaVir wrote in the 22nd comment:
Votes: 0
3squire said:
The fundamental point, is that you think of your game as something more fundamentally "game" like and less fundamentally "mud" like, than writing a custom client becomes a no-brainer.

Except that what we're talking about here are fundementally muds, with an established audience of players. Creating a custom client is fine, but dropping support for other clients will drive away a large portion of the existing market.

You can talk all you want about new audiences, etc, but if you're creating a game that looks and feels exactly like a mud, then from the perspective of the players it is stilla mud. People who like muds may take a look (and decide its not worth bothering with if they can't use their favourite client) while those who don't like muds won't like your game either.

I know we had the same disagreement before, over your Google Crome client as the sole means of connecting to your mud, so I don't think we're going to see eye-to-eye on this.

In terms of features and functionality, I've yet to see anything I couldn't do with a telnet client (within the context of a primarily text-based mud-style game).

3squire said:
Also, read this about incentives in developing for one or many clients, protocols, standards, etc: http://www.joelonsoftware.com/items/2008...

That's an interesting article regarding browser vs website compatibility issues. However this scenario is on a far smaller scale, and I'm a server developer - the equivalent of a website developer - while the article is from the perspective of a client (browser) developer. At no point does the author suggest that websites should only support a single browser.
27 Jun, 2010, quixadhal wrote in the 23rd comment:
Votes: 0
I guess it's an accident that some of the most popular muds out there also distribute their own custom client, which is tailored specifically to work with their game, including having graphics and sound files preloaded in the distribution?

Yes, they still let you connect with POT, and I'll even bet more of their players use nothing more than ANSI color support. But that doesn't support the idea that it's still the best way to do things.

Downloading a client is NOT some onerous task that people out there can't do anymore. The majority of games available online require custom clients, graphical or not. Today's gamers are used to going to the web site, clicking download, install, and running the app to start playing. It's only us fossilized dinosaurs that expect a single client to work everywhere, and to have to type in arcane ip addresses and port numbers.

KaVir said:
In terms of features and functionality, I've yet to see anything I couldn't do with a telnet client (within the context of a primarily text-based mud-style game).


That's probably because most mud-style games out there cling to the existing model like a rat clings to a chunk of wood that's floating in a pond. It could probably swim to shore, but the chunk of wood is a sure thing, until it starves to death.

I'm looking back at the recent discussion on mudstandards.org. At that time, I also tried to convince people that life would be much simpler for both client and server developers, if we abandoned the TELNET stream protocol and adopted a new message-based system that actually worked the way our games tended to work.

One tiny example. Room descriptions. Right now, the server has to bug the client for information about terminal size, does it support ANSI/VT100/XTERM256/MXP, does the client want word wrapping enabled, does the player have their map enabled and will that fit in the given display width, etc… It has to fudge all that up and then send out a text stream with all the right codes embedded in it to (hopefully!) come out legible on the other end.

If we had a proper message protocol, the server would just send the room description with display neutral tagging for color/font/whatever markup, and the client would deal with putting it in the right window, with the right width and wrapping settings, and using whatever color the actual end-user wanted or supported. Color-blind folks could have it display as greyscale so they still get light-and-dark. Blind users could have it emphasize things with "bright" colors by speaking louder. But the point is, the server doesn't have to waste CPU and overly complex formatting code to do it.

The map could get sent in a separate message which might be formatted differently, so instead of embedding the markup for colors and such, it might just send an NxM grid of terrain with another NxM grid of objects/npcs/players, and so on. Again, let the client do whatever it wants to do with that.

*COULD* you do all that in plain TELNET? Yeah, of course you can. But it's a lot of extra coding and processing, and if the client isn't 100% on the money, or if the user has flubbed their settings, you end up with a mess. Even assuming you do have it all working, it still falls to the user of this generic telnet client to setup all the right triggers and somehow match tags to windows on their own. See MUSHClient. Nice client, pain in the rear to get setup and working for a new MUD. I'd much rather spend 30 seconds downloading a custom client for FooMUD, than an hour setting up all the triggers and stuff I need to make a generic client understand what the uncategorized stuff coming over the telnet pipe actually is.

Just as an aside… I find it highly amusing that *I* am arguing so hard for custom clients, considering that I normally use one of the oldest warhorses out there, tinyfugue. Why? Because I know how it works… I know how the triggers and macros and stuff works, so setting up a new game is only a minor pain instead of an ordeal. But, in the end, why should I need to know all that? If you dropped a custom client on me that I could run and it'd connect and correctly know what ALL the content is, ALL the time, so I could easily direct it, recolor it, ignore it, from drop-down menus, why would I need to know all the arcane regexp methods to capture and respond to text patterns? I wouldn't. I'd just start typing commands and play, adjusting things as I went. Message-based protocols make that fairly easy. Embedded tokens don't.
27 Jun, 2010, KaVir wrote in the 24th comment:
Votes: 0
KaVir said:
There's a lot you can do with a feature-rich mud client - not just more colours, but also proper graphics and sound. However that doesn't mean you have to actively remove support for older clients.


quixadhal said:
I guess it's an accident that some of the most popular muds out there also distribute their own custom client, which is tailored specifically to work with their game, including having graphics and sound files preloaded in the distribution?


No, there's a lot you can do with a feature-rich mud client - not just more colours, but also proper graphics and sound. However that doesn't mean you have to actively remove support for older clients.

As you pointed out, the most popular muds support older clients as well.

KaVir said:
In terms of features and functionality, I've yet to see anything I couldn't do with a telnet client (within the context of a primarily text-based mud-style game).


quixadhal said:


*COULD* you do all that in plain TELNET? Yeah, of course you can.

I guess that answers my question then.

quixadhal said:
But it's a lot of extra coding and processing, and if the client isn't 100% on the money, or if the user has flubbed their settings, you end up with a mess.

It's actually a pretty insignificant amount of effort compared to the rest of the mud. You don't need to actively support every client though, just make sure you follow the protocols.

quixadhal said:
Just as an aside… I find it highly amusing that *I* am arguing so hard for custom clients, considering that I normally use one of the oldest warhorses out there, tinyfugue. Why? Because I know how it works…

Exactly. If a custom client offered any sort of customisable functionality, you would run into the same problem - not knowing how it worked.
27 Jun, 2010, quixadhal wrote in the 25th comment:
Votes: 0
KaVir said:
It's actually a pretty insignificant amount of effort compared to the rest of the mud. You don't need to actively support every client though, just make sure you follow the protocols.


If you keep support for dumb clients, then you still have to do all the formatting and processing which a proper client would do on their end. That is, to put it mildly, insane. Why should the game *server* ever have to care what the game *client* does with data sent to it? More importantly, why should the server have to have code to do all that formatting?

MUD's violate one of the basic rules of development, by not keeping presentation separate from data. Most of the MUD's I've worked with spend a lot of effort building up strings with presentation data embedded in them, and then turn around and strip them back out so they can process the data later on (such as for NPC interaction).

KaVir said:
If a custom client offered any sort of customisable functionality, you would run into the same problem - not knowing how it worked.


I dunno about you KaVir, but *I* would rather spend my time playing the game I'm connected to, rather than pouring back over log files to figure out what pattern matches most of the messages of a given type so I can color it properly.

Picking "enter/exit class messages" and then "white", seems simpler than:

/def -i -aCwhite -t" enters "
/def -i -aCwhite -t" leaves "
/def -i -aCwhite -t" has arrived from "
/def -i -aCwhite -t" left the game\.$"


and it's also not going to accidently trigger on things like "You watch as the dragon enters the nest."

This thread was originally about complexity in server code. Breaking that dependency on mixing presentation and content is one of the first ways you could simplify your server, but you have to be willing to step out of the 1970's and give up protocols designed to work with things as old as 75-baud teletypes. Don't forget to hit ctrl-s when the paper runs out so you can put a new box in and hit ctrl-q again!

I certainly don't expect everyone (anyone) to agree with me, but I'm not convinced that continuing to support TELNET is done because it's a good idea, as much as because it's the way it's always been done and change is scary.
27 Jun, 2010, David Haley wrote in the 26th comment:
Votes: 0
Fizban said:
Runter said:
Then the question becomes: does a hot new client pull more players to your MUD from other MUDs? How many players like to play on their own clients versus custom clients provided by the MUD ?


Can't speak for everyone, but I personally at least would much rather play a MUD where I use my own client than one that they provide for me to use and restrict me to using.

This is why catering to existing players is difficult: they have very strong prejudices about how things should work, and are not often open to change. The notion that a custom client that might provide all kinds of extra features and display is considered a form of "restriction" is very revealing.

KaVir said:
I agree that targeting players outside of the mud community is a good idea. What I have strong doubts about is that it's necessary to exclude existing clients in order to do so.

I think the idea is that it's much easier to expand your base by dropping "dumb telnet" support, and you lose a few to gain many, many more. Is it "necessary"? Well, no, but that's not often the important question, is it?
27 Jun, 2010, Idealiad wrote in the 27th comment:
Votes: 0
quixadhal said:
MUD's violate one of the basic rules of development, by not keeping presentation separate from data. Most of the MUD's I've worked with spend a lot of effort building up strings with presentation data embedded in them, and then turn around and strip them back out so they can process the data later on (such as for NPC interaction).


But you have to build these strings anyway, with neutral markup, regardless of client. You have to write your Telnet module once essentially to interpret this markup, and while of course that's extra work, it's work that in large part has been done by others.

From looking at servers lately that handle Telnet and websockets, I'm not as convinced as I used to be that Telnet is a dinosaur that needs to be extinct. It's simply an existing protocol that can be ably supported as a mud moves forward with new technology.
27 Jun, 2010, Tonitrus wrote in the 28th comment:
Votes: 0
quixadhal said:
KaVir said:
If a custom client offered any sort of customisable functionality, you would run into the same problem - not knowing how it worked.


I dunno about you KaVir, but *I* would rather spend my time playing the game I'm connected to, rather than pouring back over log files to figure out what pattern matches most of the messages of a given type so I can color it properly.

Picking "enter/exit class messages" and then "white", seems simpler than:

/def -i -aCwhite -t" enters "
/def -i -aCwhite -t" leaves "
/def -i -aCwhite -t" has arrived from "
/def -i -aCwhite -t" left the game\.$"


and it's also not going to accidently trigger on things like "You watch as the dragon enters the nest."

Doesn't MXP handle stuff like this already? It also wouldn't be difficult to add that functionality to the server itself.

If you want the most players to try your game, you have to reduce the barriers to entry for everyone. For non-mudders that may mean trying to set up a client that's easy to use. For mudders that means "don't screw with their clients". I don't think I'd have ever tried KaVir's mud if I had to use his custom client to play. It looks neat, but MUSHclient and I don't get along.

Now, you could say "screw the established mud players, let's go for the new guys," but I consider it pretty unwise to snub an established audience in the hope of gaining a new one, when you can support both.
27 Jun, 2010, David Haley wrote in the 29th comment:
Votes: 0
Tonitrus said:
Now, you could say "screw the established mud players, let's go for the new guys," but I consider it pretty unwise to snub an established audience in the hope of gaining a new one, when you can support both.

Snub an "established audience" that has already snubbed all the efforts you're making to move things forward? Snub an "established audience" that's realistically quite small compared to what's out there?

Look at what you're saying: you essentially said that no matter how neat some custom client is, you wouldn't even bother trying just because it's not your client. It seems like you want to use your client more than you want to play a game, and if I wear a game admin's hat, I have relatively little reason to cater to such players when there are so many more fish in the sea.
27 Jun, 2010, quixadhal wrote in the 30th comment:
Votes: 0
Idealiad said:
quixadhal said:
MUD's violate one of the basic rules of development, by not keeping presentation separate from data. Most of the MUD's I've worked with spend a lot of effort building up strings with presentation data embedded in them, and then turn around and strip them back out so they can process the data later on (such as for NPC interaction).


But you have to build these strings anyway, with neutral markup, regardless of client. You have to write your Telnet module once essentially to interpret this markup, and while of course that's extra work, it's work that in large part has been done by others.


Hmmm, how to word this. It's true you have to build neutral markup strings, but the difference is that if you *know* your audience is using a client that understands them, you don't have to then re-translate them into a terminal-specific presentation.

Consider: You see a <color:red>red apple</color> and a <color:green>green apple</color>.

Using telnet, that might get translate by the server to: You see a ESC

Hmmm, how to word this. It's true you have to build neutral markup strings, but the difference is that if you *know* your audience is using a client that understands them, you don't have to then re-translate them into a terminal-specific presentation.

Consider: You see a <color:red>red apple</color> and a <color:green>green apple</color>.

Using telnet, that might get translate by the server to: You see a ESC[31mred appleESC[0m and a ESC[32mgreen appleESC[0m.

Now, on the client end, what do I do with that? Currently, I splat it to the screen and hope for the best. If I'm color blind, I'm SOL… I can either turn color off entirely as my only option. If I got the actual tags sent to me, my client could be told "Hey, instead of actually making that red, make it bold, or italic, or make the font bigger".

Now, MXP already does some of this, but it's only dealing with embedded tags that are part of the presentation. That isn't the main issue I was talking about.

With telnet, you have a single stream of data that has no context. Bytes come in, you either splat them to the screen and let it handle things, or you can try to filter them via triggers and such, but you still don't get much control over what happens. The server is building you the presentation and shoving it out the door with the idea that you CAN'T do much to it beyond watch it go by.

If we used a real message-based protocol, data would come in properly classified and the client would be able to choose how to format or display it without any hints from the server, beyond that classification.

Instead of getting a chunk of text that says:

[code]/secure/room/arch
Arch Room
| | | |
5 # #-# #-# #
| | | |
4 -# # # # # #
| | | | |
3 #-# # #-#-#-
| | | |
2 -#-# # [color=red]@[/color] # #
| | |
1 -# # #-#-#-#-
| | | |

-5-4-3-2-1 0

This is a polished antiseptic room composed of some white gleaming material. There is a viewscreen on a wall here, with a
control panel alongside it. A long printout hangs from the panel.
The network troubleshooting room is down from here.
A sign on the wall reads: "I3 connection: ONLINE, IMC2: ONLINE"
Obvious exits: north, down
[color=skyblue]You can faintly hear a low hum coming from the walls.[/color]
[color=deeppink]The Arch Board is here.[/color][/code]

Maybe you'd get a set of messages:

<room-location:/secure/room/arch>
<room-title:Arch Room>
<map:<grid:5x5><0,0:<terrain:#><exits:NS>>> (etc…)
<room-description:This is a polished antiseptic room composed of some white gleaming material. There is a viewscreen on a wall here, with a control panel alongside it. A long printout hangs from the panel.>
<room-detail:A sign on the wall reads: "I3 connection: ONLINE, IMC2: ONLINE">
<exits:<list:north,down>>
<room-sound:You can faintly hear a low hum coming from the walls.>
<object:The Arch Board is here.>

Again, not a finished protocol or anything, but the idea is the client can know what to do with all those things. If you have a separate map window, the map can easily be put there. If not, it can be merged into the description, or placed above it, because the client can better know how to do things than the server.

Not just simple things either. Right now, if someone says something on I3 or IMC, my screen will scroll. The dumb client doesn't know that the lines of text I just got are a broadcast message, it might be part of combat, it might be the game shutting down. All it knows is data came in, plop to screen.

I could make it smarter… I can build up lots of triggers to match well-known things like "<intergossip>" and assume the message was just one line. But why? Why can't the server just send out a message packet of type INTERMUD, with details like channel=intergossip, sender=quixadhal, timestamp=15:21? Less work on the server end, more flexibility on the client end.

What telnet can't really do for you is provide this asynchronos handling of data. You can kludge it with OOB stuff and all kinds of extended negotiation that's really hard to debug. But you still end up back at the same place… you can't KNOW the player will be able to make use of it. With a custom protocol, you can ensure it's really easy to build support for things. With a custom client requirement, you CAN know exactly what's possible. You can stop having to build for the lowest common denominator.

EDIT: Heh, looks like the color tags are broken… oh well, imagine it has a red @ and the bottom two lines are cyan and magenta.
27 Jun, 2010, KaVir wrote in the 31st comment:
Votes: 0
quixadhal said:
If you keep support for dumb clients, then you still have to do all the formatting and processing which a proper client would do on their end.

You'll always need to do that to some degree, regardless of client - for example things like the enter/exit messages you mentioned will need to be uniquely identified at the server end if you want to ensure that they're handled consistently.

quixadhal said:
It's true you have to build neutral markup strings, but the difference is that if you *know* your audience is using a client that understands them, you don't have to then re-translate them into a terminal-specific presentation.

Okay, but you can still do this with telnet simply by gearing your mud towards a specific set of protocols. This is basically what I do - I offer MXP links, extended colour, sound and graphics, all geared towards a particular client. But other clients can also make use of some or all of those features, and you can play with even the most basic telnet client if you really want to.

I'm all in favour of enhancing the experience with custom clients, I just fail to see how dropping support for existing telnet clients would help. As far as I can see, all it would do is raise the entry barrier.
27 Jun, 2010, Tonitrus wrote in the 32nd comment:
Votes: 0
David Haley said:
Tonitrus said:
Now, you could say "screw the established mud players, let's go for the new guys," but I consider it pretty unwise to snub an established audience in the hope of gaining a new one, when you can support both.

Snub an "established audience" that has already snubbed all the efforts you're making to move things forward? Snub an "established audience" that's realistically quite small compared to what's out there?

Look at what you're saying: you essentially said that no matter how neat some custom client is, you wouldn't even bother trying just because it's not your client. It seems like you want to use your client more than you want to play a game, and if I wear a game admin's hat, I have relatively little reason to cater to such players when there are so many more fish in the sea.

I think that you're inadvertently taking this issue out of meaningful context, resulting in a straw man. Let's say that I would rather use my client than play X mud. Does that seem like an odd preference to you? I didn't wake up one day and decide to be a client snob. I logged into my first mud using windows telnet. I had no desire for any sort of client until I needed one to play the game. I needed to filter combat spam, to notify me of important things that scrolled by too quickly for me to read/perceive, and to set up triggers to cope with some particularly player-hostile game mechanics. So I switched from telnet to a client. After a while, I tried PK, which my client couldn't handle, then I switched clients again. Then I tried to set up something else to deal with a dealbreaking aspect of another game I wanted to play, and it couldn't handle it, so I switched again. I currently play God Wars II, which is the most well-designed game I've ever played, and I still have 116 lines of script that I'm not willing to play the game without (probably only 65 of those should count, though). I don't use my client because I like my client, I find its scripting syntax to be utterly nauseating. I use it because I know of its capabilities (which are the best of any client I've tried), and because I need it to cope with issues of poor design or genre issues of muds in general, like too much spam.

I have no reason to believe that X mud will not be full of issues that ruin the game for me, and telling me I have to use X client to try X mud leaves me with no confidence at being able to fix any issues that arise. The last mud I played, I had to sit down and write something like 300 color triggers in order to play it at all. I spent the first few weeks on the mud just trying to script it into a playable shape. I have no reason to believe that any other mud will be any different, and I'd rather not have the start up effort required to start playing game X increased by having to learn a new client as well.

Now, your position could be "get over it", which is fine, but many people just aren't going to bother. You could also assume that a larger target audience exists, which may or may not be the case, but there is an existing audience already, and I'm not sure its wise to ignore their preferences, whether you agree with them or not. If there weren't so many crappy muds and mud servers offered more configuration options, I don't think we'd even need clients. For example, I vastly prefer GW2's 'alias' command to my client's.
27 Jun, 2010, quixadhal wrote in the 33rd comment:
Votes: 0
Tonitrus said:
I have no reason to believe that X mud will not be full of issues that ruin the game for me, and telling me I have to use X client to try X mud leaves me with no confidence at being able to fix any issues that arise. The last mud I played, I had to sit down and write something like 300 color triggers in order to play it at all. I spent the first few weeks on the mud just trying to script it into a playable shape. I have no reason to believe that any other mud will be any different, and I'd rather not have the start up effort required to start playing game X increased by having to learn a new client as well.


The thing is, the effort you put into that probably wasn't spent deciding what to do with various classes of output from the game. It was probably mostly spent trying to IDENTIFY what specific patterns of text should go into categories. A MUD which used messages instead of just a stream of text would have all that done for you. You'd still want/need to decide where the messages went, but that's a whole lot easier than writing regexps to match patterns as you come across them.

If every incoming-damage message was classified as it came from the server (by having the message packet be of type incoming-damage), you could make them all end up as Lucidia-console 14, bright red, in the combat window. The server doesn't have to care how you want things to look. The client doesn't have to pick thing apart to see what they are. YOU don't have to either.

If it turns out you wanted PVP damage to be blinking, it's a matter of identifying that the actor who did the damage was another player. The server could include that easily as another field in the packet. It could just send the name (in which case the client could ask if it's a player or NPC), or it could also include the pc/npc status.

Doing that with plain telnet would be an unhappy experience. Unless you fully support OOB communication on both sides (client AND server), there's no way to ask that question without having stuff show up on the screen, even if it could be automated.
—-
The thing is, (IMO) you guys aren't arguing the case that MUD's are better served by sticking with TELNET. You're arguing the case that existing players who are familiar with a particular client are better served by sticking with TELNET. I don't believe that new players really enjoy learning how to setup triggers and aliai within any of the existing generic MUD clients. I don't think the "average" player who doesn't make heavy use of such triggers and aliai would care much, one way or the other, as long as it still worked for them.

Let's say you play World of Warcraft and decide to start playing Everquest II. Is it reasonable to expect to use your existing WoW client to connect to EQ2? If the guys making those games had decided to stick with a generic graphical client that works with any graphical MUD out there, you'd be playing stick-figure games with horrible lag, because the developers would have to cater to people using clients from 1998 that didn't support shadows or more than 8-bit texture mapping, because they can't code translations for all those variables.

If TELNET can get around all these issues, why are there so few MUD's out there which support character-mode, let alone have full screen editors or HUD's that make use of it? Why don't we have hotkeys built-in? Why not have menu-driven dialog systems? Clearly the protocol can handle it, since using telnet to a bash prompt works as you'd expect…

You can't say it's because nobody wants them. Yet try to write your server to allow such things and see how far you get. This player can't use it because his foofoo+ client won't do it. Microsoft telnet screws this other thing up and needs a bunch of workaround code. Lots of reasons, but it boils down to TELNET being the limiting factor. Maybe not the protocol, but the sea of broken implementations that have to be supported, results in our technology being stuck in 1990.

I've often wondered why MUD servers don't fully support termcap. When you log into a unix machine with a shell, you get a pseudo tty allocated and termcap support gives you full screen capabilities. I've never seen any MUD server do this. Why not? Even that would be a huge leap forward from the status quo.
28 Jun, 2010, David Haley wrote in the 34th comment:
Votes: 0
Tonitrus said:
Let's say that I would rather use my client than play X mud. Does that seem like an odd preference to you?

Well, I don't really care if it's odd or not; you are free to prefer whatever you like. But the point of my post is: if you are behaving this way, why should I care about you as a target player? You want me to add extra work just to attract people with extremely particular tastes. Why should I bother? I have bigger fish to fry.

Tonitrus said:
You could also assume that a larger target audience exists, which may or may not be the case, but there is an existing audience already, and I'm not sure its wise to ignore their preferences, whether you agree with them or not.

I'm pretty sure that the number of potential players who don't behave like you is pretty large… You have some of the strongest, most particular preferences of anybody I've ever spoken to. So while it might not suit you to have your preferences ignored, I can get vastly superior returns by catering to more common preferences.

Tonitrus said:
If there weren't so many crappy muds and mud servers offered more configuration options, I don't think we'd even need clients.

Somehow the rest of the gaming world manages without this problem, and, uh, there are just a few more players out there than in the MUD niche.

Honestly I read posts like yours and I wonder why people think it's any surprise the target audience for MUDs as you want them to be is so small. People are worrying about leaves on a tree, not the tree, let alone the forest.
28 Jun, 2010, Runter wrote in the 35th comment:
Votes: 0
The bottom line is that backwards compatibility is difficult to maintain. Furthermore, if you want your game fully playable from basic telnet clients it's going to ultimately caste itself upon the design decisions you make. Name any successful MMOlike and then inject the concept of building the game with compatibility with telnet. It doesn't work. Yes, I know. A lot of you are against the game being nontext in any part of the whole. In this case it may work for you..however, I don't think you're the people I'm talking to when I suggest that there are thousands of players out there to be had. I'm talking to the people who haven't lost the ability to imagine what a new game could be like without basing it on text based gaming as we know it. Indeed, I'm not against working outside of the box at this point. In fact, I lean towards using text when it's the best solution only. Like describing things in detail. I would not prefer to use it for spacial representations, ranged combat, etc etc. That's not even talking about the GUI component, yet.

Ultimately I wouldn't be against using a 3d engine for some graphical presentation and shading. I'm specifically interested in 2d top down engines based on 3d engines for shading and particles.
28 Jun, 2010, KaVir wrote in the 36th comment:
Votes: 0
Runter said:
Yes, I know. A lot of you are against the game being nontext in any part of the whole. In this case it may work for you..however, I don't think you're the people I'm talking to when I suggest that there are thousands of players out there to be had. I'm talking to the people who haven't lost the ability to imagine what a new game could be like without basing it on text based gaming as we know it.

Quixadhal's original comment was about "making text games for a wider audience", that's what I quoted and responded to, and you even quoted it again when you said you agreed with him.

I am definitely not "against the game being nontext in any part of the whole" - as should be apparently to anyone who's seen the MUSHclient plugin I'm working o..., but when I talk about "text games" I envision a game that is still primarily text-based, not some 3d graphical engine with a handful of textual elements.

Finally, I feel I should mention that - in my experience - Tonitrus's unwillingness to download a special client is far from uncommon, particularly among veteran mudders. However it is my belief that catering to other clients doesn't limit what you can do, at worst it increases your workload. But that's a price I personally consider worthwhile. If you don't, that's fine by me - I'll pick up those players who refuse to give your game a chance because they can't be bothered to download your client, and then I'll gradually woo them over to my client* with screenshots and recommendations.

* Or more accurately "MUSHclient with my plugin". But you know what I mean.
28 Jun, 2010, Littlehorn wrote in the 37th comment:
Votes: 0
Runter said:
In this case it may work for you..however, I don't think you're the people I'm talking to when I suggest that there are thousands of players out there to be had. I'm talking to the people who haven't lost the ability to imagine what a new game could be like without basing it on text based gaming as we know it. Indeed, I'm not against working outside of the box at this point. In fact, I lean towards using text when it's the best solution only. Like describing things in detail. I would not prefer to use it for spacial representations, ranged combat, etc etc. That's not even talking about the GUI component, yet.


Then we are not talking about MUDs then.

Runter said:
Ultimately I wouldn't be against using a 3d engine for some graphical presentation and shading. I'm specifically interested in 2d top down engines based on 3d engines for shading and particles.


2D top down engine? what?
28 Jun, 2010, 3squire wrote in the 38th comment:
Votes: 0
Yes, but KaVir, the point being made is that at some point, the degree of complexity involved in catering to every client in the world becomes greater than the complexity to actually elevate the game to a superior genre (if one considers, say, a 2D topdown game a superior genre). There is also the small matter that even a primarily text based game, if the developer wrote the client, could and should be far superior to a telnet-supporting text game primarily for the windowing possibilities alone. If I can have two players play chess against each other with their in-game chess board but with graphical chess tokens I think that is a huge step up. You know why, too – it allows for the persistent board to maintin a visual showing of the game state instead of scrolling out of view, the game can be played while other chatting is occurring. Characters you "look" at could be tokenized into 2D portraits, and with a 2D representation of each object in the game you could even up that and show their inventory visually.

You see, I think the primacy of text games is in the depth that written materials can offer. I do not think that there is a supreme advantage in having a merely or purely textual representation of everything in the game. I also think the brain interpolates 2D image map data with far superior acuity to messages about how many feet, meters, cubits, whatever away something is standing and in what direction.

What's being advocated here isn't necessarily client lock-in anyway. What's being advocated is a move to either an XML or a JSON standard that allows for data to be properly classified in a true protocol that could then be implemented in a 1:1 way across a number of individual clients and servers. If there were even one game that was good enough, with one client that was good enough, and the protocol was known and available, more clients could be written for the game and more servers could be written for the client.

A win-win.
28 Jun, 2010, KaVir wrote in the 39th comment:
Votes: 0
3squire said:
Yes, but KaVir, the point being made is that at some point, the degree of complexity involved in catering to every client in the world becomes greater than the complexity to actually elevate the game to a superior genre

I'm not suggesting "catering to every client in the world". I'm just disagreeing with the idea of actively dropping support for all clients but one. To use your earlier comparison, that would be like designing a website that refuses to display anything to all but one web browser, and then arguing that if people want to view your website, they should download your custom browser.

It is pretty simple to support basic telnet functionality. From there, you can add support for multiple protocols, and any client that correctly supports those protocols will be able to take advantage of whatever extra features you offer. You can then go ahead and create your custom client/plugin, taking full advantage of all the protocols to produce your "recommend" interface, while still allowing other clients to use whichever features they support.

Example:

Among other things, I support MXP links, MSDP, MSP and 256 colours, and I offer a MUSHclient plugin that combines all of these elements into a graphical GUI. Around a quarter of my players already use the plugin, even though it's not complete. Most of these players started out using different clients, and gradually moved to MUSHclient after seeing screenshots and hearing comments from other players.

Tonitrus doesn't want to use MUSHclient, because he prefers TinTin++, but he can still download the soundpack and play sounds, and use MSDP for his triggers. He can also use the extended colours. I've quite a few other TinTin++ users, as well, including two who are using MSDP data for their own custom interfaces with maps and status bars.

Quite a few of my players use MUSHclient but don't want to use my GUI. But they still benefit from the MXP links and the extended colours, and some of them also use the soundpack. One of these players has even designed his own plugin, taking full advantage of the same features my own plugin uses, but with a completely different graphical layout.

Around 12.5% of my players use zMUD - many of them have used it for years, they like it, and they don't want to change. However they can still use the MXP links and the soundpack, and in theory they could use MSDP to create their own graphical interface. A further 6% of my players use CMUD, and they have the same options, but can also use the 256 colours.

Approximately 18.2% of my players are blind, so they don't care about the graphics, and usually prefer sticking with a client they already know - but many of them enjoy the soundpack.

Currently only 2.3% of my players use Mudlet. But Mudlet is more portable than MUSHclient, and not all of my players use Windows. Although Mudlet doesn't support MXP (yet at least) or MSP, it does support the extended colours, and a user could create their own graphical interface if they wished. Perhaps when I've got more time I'll even do it myself.

Several of my players connect from school or work, where they are unable to install their own software. Their basic telnet clients usually support colour, but that's about it. However they can still fully play the mud.

This doesn't really require much additional effort on my part - I already need those protocols for my own plugin, after all. All I've done is split the functionality up, so that other client can still use a subset of the features I offer if they don't support them all. Or to put it another way, I activately support one client, but I passively support many. I see absolutely no reason to block other clients from connecting, all it would do is cost me players.
28 Jun, 2010, Runter wrote in the 40th comment:
Votes: 0
I disagree that it's no longer a text based game just because you use graphics where graphics make sense. If a large part of the experience is reading and using text to explore then it is indeed a text based game. There's a lot of people in this community that will not tolerate any type of graphical enhancements. I understand that, but overall the community is so small that it actually doesn't matter in the grand scheme of things unless the only people you specifically care about are these 'veterans'. If a mud ever was to breakout into mainstream success it wouldn't be by catering to old interests. Perhaps they could do it at the same time. But if it were me the game plan wouldn't be try to attract existing mudders but to cater completely to non-mudders. The to-graphical-or-not-to-graphical question is rather irrelevant, I suppose.
20.0/64