03 Jul, 2010, Idealiad wrote in the 41st comment:
Votes: 0
There already are mud servers that can provide telnet, Flash, and websocket interfaces depending on the client. I don't think this is as big a deal as people are making it out to be.

@DH, interfaces are and should be separable from the game. What about blind players? Mobile clients? Testing bots who don't need an interface that most human players would want? What about players that like 'retro' interfaces. I don't use the terminal to play muds but many players like the feel of it.

It's obvious that there are games out there that are deliberately designed for a specific interface – like most AAA titles, for example. But what about the notion that the mud 'interface' – i.e. a generalized protocol that you can pretty much do anything you want with, you could play a mud on a telephone if you wanted to, not that I'm advising it – what about the notion that this is a strengthof muds, rather than a weakness?
03 Jul, 2010, David Haley wrote in the 42nd comment:
Votes: 0
Idealiad said:
@DH, interfaces are and should be separable from the game. What about blind players? Mobile clients? Testing bots who don't need an interface that most human players would want? What about players that like 'retro' interfaces. I don't use the terminal to play muds but many players like the feel of it.

What about them? Are you seriously going to argue that somebody playing any game on a mobile client will have the same experience? How can you possibly say that the interface does not change the game – as you say below, you aren't advising playing with a telephone, and presumably you aren't advising it because you think it would make for a poor play experience.

Quote
But what about the notion that the mud 'interface' – i.e. a generalized protocol that you can pretty much do anything you want with, you could play a mud on a telephone if you wanted to, not that I'm advising it – what about the notion that this is a strength of muds, rather than a weakness?

Again, what about it? Why should we even talk about something you aren't even advising? How is it a "strength" to be playing on an inferior platform that you wouldn't advise using in the first place?

If "strength" means remaining backwards compatible to telnet, then as I told Kaz, whatever conundrum you are in is one of your own making. :sad:
03 Jul, 2010, quixadhal wrote in the 43rd comment:
Votes: 0
KaVir said:
quixadhal said:
The fact that mud developers currently limit themselves because they assume people who are currently using dumb clients, or have invested time into customizing some particular client, is what I'm more concerned about.

Is that really so common though? I'm a pretty staunch advocate for remaining playable with basic telnet clients, but that doesn't prevent me adding support for more advanced features - and I don't see why it would prevent anyone else, either.

Apparently, because you haven't been able to envision a technology that would REQUIRE the use of features that the basic telnet clients can't do. I can imagine quite a few, but to implement them fairly (so that ALL players have access to them), I'd have to put minimum requirements on the kinds of clients that are allowed to connect.

Character mode combat is the obvious first thing that comes to my mind. Like other MMO's, assigning abilities to hotkeys and hitting 1 or 2 to use them against the current target. Expecting telnet users who can't do character mode (for whatever reason) to build their own client-side macro system is unacceptable. So, to be fair I'd have to stick with commands called "1" that require the user to hit enter. Not at all the same feel.

KaVir said:
Few people use them, even in the UK where a black and white TV licence is much cheaper than a colour one - but that doesn't mean they should be blocked from receiving the TV signals (if such a thing were even possible), or that they're holding back advancements in film-making.


Actually, as I said, it *DID* hold back advancements in film-making. Namely, films and television programs continued to be produced in black & white for decades after color television was available, because the expense of converting to color film and production gear was too risky for smaller studios. B&W shows were still being produced as late as 1970.

Had it been a zero cost switchover, I doubt black & white would have survived much past 1955. By comparison, the cost of switching from TELNET to something else is effectively zero. Yes, there is a small amount of manpower involved in re-writing the client and server ends to use something else, but the cost to the consumer remains zero, and the cost to the mud developer who isn't also a server developer remains zero.

KaVir said:
quixadhal said:
THAT is what I see TELNET doing to MUD's. TELNET is keeping us in the black & white era

And yet earlier in the same post you wrote "The fact that it happens to use TELNET, or a packet protocol, or something else entirely doesn't make any diffrence". What makes you think it's telnet that's keeping us back? We've already got telnet muds with graphics and sound, and web clients that can provide a browser-game style interface to any telnet mud. I get the feeling that telnet is being used as a scapegoat.


The part you're using there is referring to it not making any difference to the game being a MUD or not, which I thought was clear from the context of the preceding posts.

As for us already having browser-style interfaces… no, we don't. A telnet shell inside a browser is NOT a browser-style interface. Slapping graphics and sound as fluffy eye-candy additions that are not integral to the experience does NOT make the MUD in question graphical. If it did, the players using plain old telnet would be at a disadvantage, since they would have no way to access part of the content.

I have mentioned character mode TELNET serveral times, and I've also mentioned the lack of full termcap support. I notice these aspects are never brought up by the "everything-is-fine" camp. Perhaps that's because you recognize that features implemented using those things would indeed be incompatible with the current line-based technology, and that they might allow you to do things that cannot be done without either abandoning those line-based clients or creating an unfair disadvantage for them?

How about one more mini-example of something that might be a fun mini-game? A typing test. If your client supports character mode, you could easily implement a mini-game where words are displayed at a set speed and scroll (or fade, or whatever) off beyond a certain limit. Let's say three lines. Now, to be fair, we need to limit the line length so people with 500 character wide terminals don't get an advantage. With a custom client, we'd just open a window/region of the right size…. without one, we have to trust the user told us the right width and go from there. If your terminal has fewer columns than the minimum, you can't play. Let's pick 80.

Ok, now you've gotten the display setup. 3 lines of 80 characters. Now, text entry needs to be done without disturbing the text being displayed. VT100 scroll regions would be sufficient for this, although there are other options. The main importance here is that keystroke entry needs to be measurable per-character, in real-time. Each key hit that adds a correct character gives you points, and the faster you enter them, the more points you get. Each mis-typed character has negative points. Using backspace to correct is free but costs you time, so retyping the missed character fast enough will still give you a positive score.

Now, just to be fair, there is a minimum delay involved. To accomodate that most people will have network latency, let's say scores from 0 to 50ms are the same maximum value, and go from there. Modern gamers have accepted that while lag is not something anyone likes, it's understandable and just part of the online experience.

Now that the basics are down, let's add one more feature to make things interesting. Each correct character will highlight on the line as it's typed (maybe red, maybe reverse-video), and each incorrect character typed will blot out the character it should have matched (with an underscore).

So, with your TELNET based game, which has to support clients that can't do full-screen control or character-mode entry, how would you implement this game? I'm not talking about a similar game which could just use line-mode and divide the total size by the total time spent, that's different and would feel totally different.

Sure, it's a contrived example, but it took me two minutes to think of. How many other clever ideas that might really fit into the structure of a MUD have been imagined and then abandoned because the inventor realized that it wouldn't work with tinymucker++ or whatever? Sure, there are players who can't play it. Maybe they don't touch-type… maybe they are connected via sattelite and have high latency. So, THOSE players avoid the mini-game. If it's important enough to the way the MUD works, maybe they avoid the whole MUD. How is that bad? Isn't that why we have more than 3 MUDs on the internet?
03 Jul, 2010, Runter wrote in the 44th comment:
Votes: 0
Tonitrus said:
KaVir's plugin doesn't offer a competitive advantage to the game, it just helps with presentation. You don't really gain anything in GW2 by having a constantly up-to-date map, it just looks nice. You could turn the map feature off altogether, and it'd only make dungeons a bit of a nuisance. For fighting mobs or players in the main world, you don't even need the in-game map, much less the MSDP map. The only competitive advantage I can see is removing your prompt from the spam, which I do anyway with tintin's #prompt command.


That does seem like it's the case, but what if it did give a solid competitive advantage? One not easily overcome. It was said earlier on the thread and dismissed but perhaps it's true that you can build text based interfaces for any game. Even ones we might lawl at the very idea of. At some point there's not only a clear disadvantage but just not as good. The only way this is a misconception is if you're letting your design being driven by what is doable for text based as well. This leads to an even bigger problem.
03 Jul, 2010, Runter wrote in the 45th comment:
Votes: 0
Quote
Again, what about it? Why should we even talk about something you aren't even advising? How is it a "strength" to be playing on an inferior platform that you wouldn't advise using in the first place?


It's this strength that is the engine for the massive success muds have been experiencing. Don't change a winning formula.
03 Jul, 2010, JohnnyStarr wrote in the 46th comment:
Votes: 0
Question:
I would like to be able to have my 256 color scheme work in regular Vim so that it will also work with Putty on my windows machine at work.
Is this possible? If so, how?
03 Jul, 2010, KaVir wrote in the 47th comment:
Votes: 0
quixadhal said:
Apparently, because you haven't been able to envision a technology that would REQUIRE the use of features that the basic telnet clients can't do. I can imagine quite a few,

More accurately I've yet to come up with anything I've wanted to do that couldn't be done through telnet. But if you can "imagine quite a few" things, I'm all ears. If you could even list one thing I'd be interested.

quixadhal said:
but to implement them fairly (so that ALL players have access to them), I'd have to put minimum requirements on the kinds of clients that are allowed to connect.

And that's where our approaches differ - the carrot vs the stick. I would rather encourage people to use certain clients, while you'd rather block people from using certain clients.

If different people are using different clients then obviously their playing experience will vary. But if someone only has access to a basic client, then I think it should be up to them whether they want to play or not. They might not have the triggers, macros, highlighting, etc, that top-end clients support, but if they're willing to play with that disadvantage then that's their decision, not mine.

I'm a server developer, not a client developer. I cannot realistically produce a client that would match the features of MUSHclient, TinTin++ or CMUD - it would take years of work, in a field I've got little experience. So if I created my own client and forced people to use it, it would be an inferior product to those that are already out there. So what do I do then, block the superior clients as well to maintain a fair playing field?

Or do I support one of the top clients and block the others? But what happens if another client becomes more feature rich - do I then force everyone to change client, or do I continue blocking the now-superior client?

quixadhal said:
Character mode combat is the obvious first thing that comes to my mind. Like other MMO's, assigning abilities to hotkeys and hitting 1 or 2 to use them against the current target.

Quite a few telnet clients already support hotkeys and/or character mode.

quixadhal said:
Expecting telnet users who can't do character mode (for whatever reason) to build their own client-side macro system is unacceptable. So, to be fair I'd have to stick with commands called "1" that require the user to hit enter. Not at all the same feel.

It's a slightly inferior experience, but it's better than not allowing them to play at all. It's also a client issue, not a telnet issue.

quixadhal said:
As for us already having browser-style interfaces… no, we don't. A telnet shell inside a browser is NOT a browser-style interface. Slapping graphics and sound as fluffy eye-candy additions that are not integral to the experience does NOT make the MUD in question graphical.

I strongly disagree - it is for all intents and purposes a browser game, played through a web browser, using standard web technologies. It's still primarily a text game so of course there's a text window, but it can also include maps, buttons, energy bars, etc - exactly the same things offered by my MUSHclient plugin.

quixadhal said:
If it did, the players using plain old telnet would be at a disadvantage, since they would have no way to access part of the content.

Except clearly they would. Perhaps not with a basic telnet client, but with the more advanced mud clients they'd still be able to add maps, buttons and energy bars.

quixadhal said:
I have mentioned character mode TELNET serveral times, and I've also mentioned the lack of full termcap support. I notice these aspects are never brought up by the "everything-is-fine" camp. Perhaps that's because you recognize that features implemented using those things would indeed be incompatible with the current line-based technology, and that they might allow you to do things that cannot be done without either abandoning those line-based clients or creating an unfair disadvantage for them?

No, it's simply because I don't consider them worth adding - it's not something I'm interested in, and there's been no demand for it. Maybe some day I'll decide to add it, but there's certainly no need to drop telnet to do so.

quixadhal said:
How about one more mini-example of something that might be a fun mini-game? A typing test. If your client supports character mode, you could easily implement a mini-game where words are displayed at a set speed and scroll (or fade, or whatever) off beyond a certain limit.

Doesn't sound much fun to me at all. It's also something that would be very easy to cheat using client-side scripting, and I tend to avoid things like that. However if you really wanted to do that, you could easily do it through telnet.

quixadhal said:
So, with your TELNET based game, which has to support clients that can't do full-screen control or character-mode entry, how would you implement this game?

I would add support for full-screen control and character-mode entry. Those that didn't support it wouldn't be able to play that particular mini-"game". However they'd be able to play the rest of the mud, and would see people competing, which would give them an incentive to switch client. The carrot.

Those players would never give your game a chance, because you'd block them at the login screen. The stick.

Established players will put up with a lot more hassle than brand new players.



Runter said:
That does seem like it's the case, but what if it did give a solid competitive advantage? One not easily overcome.

The plugin is available as source code, and retrieves all of its data through MSDP. Any mud client that supports MSDP can therefore retrieve exactly the same data - and I allow clients to use ATCP to access that data as well. So even if it provided a solid advantage, it would be one that could be reproduced by any top-end client…and those clients already provide a solid advantage through their extensive features, so this issue isn't something new, it's one that's been around since TINTIN was first released in 1992.
03 Jul, 2010, quixadhal wrote in the 48th comment:
Votes: 0
KaVir said:
Established players will put up with a lot more hassle than brand new players.

Clearly.
40.0/48