Why no Ncurses MUD servers?

Something that just occurred to me... Curses has been around forever for text screen management, and works on the server side over telnet. Sure, there are MUD *clients* that use curses, but no servers as far as I can tell.

I've seen the cool stuff MUSHclient can do, but a lot of that (including multiple 'window' widgets and mouse interaction) can be easily done with curses through almost any modern terminal program running on any modern OS (which was NOT the case in 1990, of course).

Programmatically, it should be very little work for a server coder to simply draw battle info in the combat window, for example, rather than relying on an external client to do it.

Aside from the problem of retrofitting a production MUD, what am I missing here? It seems like an it would be a fairly obvious design choice for a new deployment that wasn't already familiar with a snazzy client.

I think the reason for that is that ncurses is far more than just displaying stuff - it is a totally different way to visualize things. Additionally, it takes flexibility away from the clients, and requires them to implement ncurses themselves.

Commonly, MU*s are considered to be text waterfalls. Stuff keeps on coming at the bottom, previously sent stuff is pretty much immutable. MUSHclient is the perfect example of it - Nick has not implemented the VT100 standard just to give an example. Zuggsoft's clients do support it, and have broadened their feature sets to be a SSH client as well, but it brings a huge amount of complexity at the same time. Why? It basically invalidates every 'certainty' a traditional client can depend on.

How would you implement triggers for something using ncurses? Plain triggers is tricky enough to get working, but it gets worse once one wants to recolour, omit or even adjust the text to suit ones tastes.

I will not deny ncurses does not have its advantages, but you also must remember ncurses was meant as an end-user interface. We have an extra layer of interface - MUSHclient, tinyfugue, cmud, take your pick.

This is why modern mu* servers and clients are implementing OOB communication such at ATCP/GMCP. It discusses information that a player cannot directly deal with, and offers it to the client so it may be displayed in a form suitable for the players playing environment.

Summary: if you intend to play a mud on a terminal, ncurses is probably a great choice. If you intend to play it with a dedicated mu* client, it becomes a hindrance, since playing a text-based game is so much more than simply using an application on a terminal.

Backwards compatibility? All MUDs are designed to work on the barebones telnet, with no extra protocols, hidden commands, etc. Each client is designed to draw all received text in the main window, unless it's scripts/triggers/whatever tell it to do otherwise.

I doubt it'd be that hard to implement a "this window <text>" type of protocol in addition to the dozen we already have...then each client would have to either implement it into their code, or someone would have to script a plugin for it. If the user's client DIDN'T support this new protocol, you'd have to output that text to the main window for backwards compatibility.

Yeah, I'd thought of MU* client issue, and how they're not usually capable as terminals. Terminal backward-compatibility is MUCH less of an issue nowadays. A curses MUD could point users to a dozen suitable free terminal programs.

So then the design decision becomes whether to provide the high-level features in-game via curses or go with plain text and leave them to the client...

Hardcore MUDders might have a pet client that they know inside and out and can easily tailor to any new MUD, but personally, I *hate* switching to new muds because of exactly that. I think this is why when I start to get bored with one, I tend to quit playing altogether for a while. It's just too much work to make a new one playable. It's worth it when I'm really in a MUD kind of mood, but not when I have 30 minutes to kill and 51% feel like MUDding vs 49% watching TV.

Besides, how hard could possibly it be to offer triggers in-game, or to let the user decide which window widget shows their inventory?

I'm feeling inspired... ProcedurallyGeneratedCursesMud is officially an embryo in my head.

The problem I have with curses is that is is somewhat of an old technology. The whole idea of having smart servers and dumb terminals takes us back to late 1970s, when information was presented to users on low-sophistication terminals by more sophisticated servers. In those days the terminals were basically a screen with the text on it stored and manipulated by a handful of chips, while the server would take up floor of a bank or insurance company, be operated by a round-the-clock team of operators and protected by armed guards.

However nowadays the client PCs are just as likely to be as powerful as the MUD servers, so it makes less sense for (say) the server to be formatting text for a hundred players, when the individual clients could do just as good a job.

There are also fundamental limitations in server-formatted output. For a start, the server needs to know the screen size (and yes I know about NAWS) but even so, the menus and options are going to be limited in the way they can be displayed and the ability to have lots of different colours, fonts, borders, icons etc. is severely restricted.

Compare the sort of result you are likely to get with pure text using curses, to something like the screen shots on this page:

http://www.gammon.com.au/forum/?id=10346

The miniwindows shown there can be moved around the screen at the player's whim, you can customize things at the client end, and you can show or hide stuff like inventory instantly, rather than having to send requests backwards and forwards to the server.

I know this is just one client, but it is freely available, runs on Windows and Linux (under Wine) and can be run on a Mac if you install VMware or similar, and then load up an old copy of Windows you have lying around, or install Ubuntu or similar.

My personal view is that the server should restrict itself to content, and let the client do presentation. For example, instead of this:



... you do this:



The first example colours the text, but doesn't provide any useful information to the client, which then has to muck around setting up triggers to try to detect the player's health.

The second example provides tagged data, which the client can then display as required. For example, chats might go in a different windows, in a colour of the player's choosing. And the health information might go into a health bar.

This was what I was suggesting we try to do with the GMCP protocol but unfortunately I was shouted down on a number of grounds - one of which was indeed the requirement for backwards compatibility. But I think we have to move on a bit from supporting every possible client (and indeed, curses is not widely supported on MUD clients).

I would like to try to have transactions that go from client to server, and vice-versa (along the lines of the second example above). And indeed the player input can be converted into player transactions. So instead of having to type:



... they simply drag the sword from an inventory window to a vendor window - and this dragging operation generates a suitable machine-readable transaction. For example:


<sell><item>1234321</item> <price>500</price> <vendor>543</vendor> </sell>


I actually played Aardwolf recently, specifically because of their preconfigured MUSHclient. As MUDs go, it was outstanding.

But the sad fact is that less than 1% of MUDS provide that. So as a developer, I get to choose between trying to help create and sell a standard (thanks, but no thanks) or just making a MUD (or MUD engine) that's playable without such a standard.

If I do the work to make it playable on the server side, though I'm somewhat limited in what I can accomplish, I'm not affected by the changes (or lack thereof) sure to happen to whatever client I've chosen.

If typical MUDs automatically did *most* of what I want them to do (maybe I can't drag windows around or have full graphical maps but all I have to do is 'telnet xxx'), I'd play a lot more of them, and a lot more often.

Nick, does MUSHclient support the things you talked about in your last post?

Mostly the click and drag approach?

Why are these your only options? It seems to me that you've created a false dilemma of sorts here. Why can't you write a plugin for MUSHclient, write your own server-side thing, and there you go -- you have your own personal protocol for communicating information that works with a full (and free, open) client, without having had to go through any form of standardization process. You don't care if other servers adopt your protocol, and it would be nice if other clients did, but in the meantime your game can still be fully playable in a very nice, modern way with one client, and you can construct a rather polished interface using the floating windows etc. that Nick described.


But most MUD clients don't implement ncurses, so the point is kind of moot, right?


MUSHclient supports it all with plugins, yes. You need a plugin to get it working along with server-side cooperation. But the screenshots that Nick showed are actually screenshots, not just mock-ups.

Sure, I *could*. But honestly, creating window Y and drawing X in window Y isn't rocket science. It'd be one thing if doing that were really hard and there was this free client sitting there that saved me a ton of work...

In my experience, learning TechnologyX in order to provide obvious features Y and Z is *more* work than just coding up Y and Z yourself.

What might be a good compromise would be to generate the raw mud output in a simple waterfall of <hp>124</hp> markup and then offer a canned curses interface on top of that that a player could turn off if they wanted to use their pet client...


Mud clients arose specifically to make MUDs more playable. A really playable MUD wouldn't need a MUD client - just a telnet app.

Don't get me wrong - MUSHclient and the stuff Nick does with it is cool - as cool as anything I've seen in MUDding. But assuming MUDs have to be played with a MUD client just doesn't seem like the right way to look at design.

All the extra extensions that MUSHclient enables server and client scripters to use have always been optional, and the game would be fully optional.

Let me turn the tables on you - and I'll admit I have no more than cursory knowledge of ncursus - but isn't what you are doing requiring every player to play on a ncurses compatible terminal? How is that any better?

(N)Curses is just an API to manipulate ascii terminals, such as VT100 (among many others). It tries to be terminal-agnostic. The odds are great that any given computer user in 2010 already has a compatible terminal program installed.

The more modern terminals even handle mouse events.

I can understand this if it's implemented client-side, but how does a normal dumb-terminal like Windows Telnet understand the commands an ncurses server sends? Windows Telnet doesn't support VT100 as far as I know, unless you emulate the display using the Console Functions documented at MSDN.

It does VT100, ANSI, and a couple others. I just telnetted into my Linux box using the 'telnet' command at a command prompt on Windows 7 and ran MUTT just fine. Had to manually set VT100 mode though.

I don't follow your point here. It's not ok to learn MUSHclient miniwindows but it is ok to learn curses, and it is ok to force all these server developers to learn it too?


If you define a MUD as something that should be playable with a dumb terminal that supports full cursor control, then your statement is, more or less, tautologically true. It becomes a question of definitions at this point: the problem has been defined away.

But honestly -- and of course this is just IMHO -- I think you're missing the point here. If you look at what Nick has done, it goes far beyond simply making a nicer text interface. He has added modern graphical interface elements to the game. This is more than even ncurses will give you; for instance, ncurses certainly won't give you icons and other graphics, or dragging graphical elements around the screen. It won't give you rich menu support.

I guess I don't really know what you're trying to argue here. Why aren't there more such servers? Because there's not much point in having them, and because they miss part of the point.

For example, you asked earlier: "how hard could possibly it be <...> to let the user decide which window widget shows their inventory?" Well, in you force ncurses only, then suddenly it becomes very hard to show inventory in a floating window like Nick provided, no?

And if it's not that hard, and you are indeed right about all of this, perhaps you could show a proof of concept where this all actually works, and where plain telnet does in fact provide the same experience as a full MUD client. I'm sure many people would eat their hats if you could offer the entire experience, including scripting, without anything more sophisticated than telnet.

Thank you! Appreciate it.



Well, Web pages are looked at with a web browser are they not? I don't see the real design issue here.

It's an interesting idea, and I can see the advantage of being able to play your MUD on any platform that supports the terminal addressing. However bear in mind that MUD clients have evolved over the years to provide things people find useful. For example:

• Logging - I don't see how you can usefully log a window which is randomly updated with cursor addressing. So your logs are gone.
  
• Speedwalks - how would something like PuTTY let you enter "#5n 3s 2w" and convert that into directions?
  
• Triggers - since you are moving the cursor all around the place how do you make triggers work? And without triggers you can't detect when in combat etc.
  
• Scripting - decision-making like drink a potion when health is low. As far as I know PuTTY and other VT100 clients aren't going to offer that.
  
• Timers - doing something periodically. Again I think you lose that.
  
• Aliases - without a custom client, you basically have to type everything in longhand.

So it can be done, I don't know if it is worth the effort.

My other point is that if you design a server to serve up transactions rather than formatted text, then it isn't too big a reach to make a client for, say, an iPhone or iPad. The "portable client" might take something like a chat transaction and just flash an "incoming message" icon (like an email notification) which you click on to read when you are ready. And the health information might update a small discrete bar at the bottom of the screen.

I don't want to discourage someone who wants to enthusiastically advance MUD development. But I can't help thinking that something targetted at the gadgets available in 2010, rather than those in 1980, is going to be more rewarding.

I dunno, maybe I'm just cranky because I feel like playing MUDs, and there's only a handful that come with a reasonably preconfigured client and I happen to not really like those particular ones.

Besides, for me personally, the only reason I use a MUD client is to do the sorts of things you could easily do in curses. Put tells over here, overhead map up there, useful status bar down here, and go nuts.

If the server does it in all, I don't have to care about clients. Doesn't matter if I'm visiting my mom or sitting in a library, just telnet and play.


I accept your challenge ;)

Server would do it. Probably could provide downloads.


Server would do it; doesn't Aardwolf have something like this?


Server could conceptually do these things with some kind of text-based interface, though it's unlikely they'd want to expose that sort of functionality.


Server can do it. Achaea has a SETALIAS command that lets you create shorhands. There's no preprocessing - it's just a straight prefix translation - but it works.


Insert random plug for long-shot web-client project here. :D

Other than maybe timers, those are things that *everyone* wants. Why do so many servers make me do it myself? It's the principle, man!

They're also easy to implement in-game. Lots of muds have aliases and speedwalks. Triggers and timers, I suspect, would be fairly trivial to implement. Saying "those belong on the client side" seems arbitrary.


Granted, those are tougher. I guess the question is "does the mud engine have to do everything a client can do, or does it just have to do enough to not chase users away by greeting them with a hideous wall of text?


That's a valid point. On the other hand, a certain amount of nostalgia is sort of the point. I can't say I've ever found myself wanting to play a MUD on my iPhone, or wishing I had a high-res graphical map instead of dashes and pipes.

Many MUDs don't want the user to automate anything, and they would need to be heavily limited anyways in order to keep the server load under control. It's possible, but (a) does the server want it, and (b) can the server handle it?

Oh well, good point! I look forwards to seeing the prototype. :-)

Well, no, your question was: why do people bother with clients that don't support ncurses? The answer is that these clients do things that would be difficult to do server-side (or that the server simply would not want to do).

It would be rather silly/dangerous for a server to give players more or less arbitrary scripting -- even if sandboxed. For starters, it provides a perfect vector for DoS attacks, even if people have accidental infinite loops.

If the question is: can the current situation be improved? The answer is of course yes: I think that's why Nick has been doing all that he's been doing.

Exactly. Distribute the processing power out for the 10/20/100 (however many your chosen mud hosts) players out to the players and their clients, instead of forcing the server to do it all.

Basically, it's what just about every online game I can think of these days does.

And it's generally cheaper to host and maintain.

For anything but a text MUD, I'd agree. Obviously, the server can't be drawing heavy graphics for hundreds of players. But text is easy to process and CPUs have come a long way since 1990.

I just finished compiling tbaMUD, which used to be Circlemud (I'm feeling nostalgic - played a lot of Circlemuds). I'll see if I can staple a Perl Curses front-end onto it this weekend, just for fun.

I think the point people are making that a text-based game does not necessarily have to be text-only. Graphical doodahs can make a game that fully consists out of text a lot more attractive to play by adding the bit of window-dressing that appeals ones pleasant tastes.

If text was _ALL_ that mattered, we would not have programs like word with bolding, underlining, sizing, headers and whatnot. Letters would still be made with a single font on a single size.

A game is more than the text it is composed of. :)

The sheer number of timers and triggers can certainly have an effect. I know people who have used a popular combat system in Achaea, and their system slows down perceptibly. Now imagine just ten players using that system, alongside everything else the game juggles.

Text processing is easy. Managing a game world, regardless of how it looks to the user, is less so.