Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Entire forum ➜ MUDs ➜ MUD Design Concepts ➜ Why no Ncurses MUD servers?

Why no Ncurses MUD servers?

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Jasonius (12 posts) Bio

Date

Thu 07 Oct 2010 06:01 PM (UTC)

Message

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.

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #1 on Thu 07 Oct 2010 06:26 PM (UTC)

Message

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.

Posted by

LezChap (36 posts) Bio

Date

Reply #2 on Thu 07 Oct 2010 06:28 PM (UTC)

Message

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.

Posted by

Jasonius (12 posts) Bio

Date

Reply #3 on Thu 07 Oct 2010 07:04 PM (UTC)

Message

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.

Posted by Nick Gammon Australia (23,122 posts) Bio Forum Administrator

Date

Reply #4 on Fri 08 Oct 2010 04:15 AM (UTC)

Amended on Fri 08 Oct 2010 04:18 AM (UTC) by Nick Gammon

Message

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:


<white>The guard walks east.</white>
<blue>John chats, hi there</blue>
<yellow>HP: 400</yellow><blue>Mana: 60</blue><green>XP: 4000</green>

... you do this:


<move>The <what>guard</what> walks <where>east</where>.</move>
<chat><who>John</who> chats, hi there</chat>
<health>400</health><mana>60</mana><xp>4000</xp>

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:


open bag
get sword
sell sword to vendor for 500 gold
close bag

... 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>

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Jasonius (12 posts) Bio

Date

Reply #5 on Fri 08 Oct 2010 01:17 PM (UTC)

Message

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.

Posted by

Mudder (7 posts) Bio

Date

Reply #6 on Fri 08 Oct 2010 01:48 PM (UTC)

Message

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

Mostly the click and drag approach?

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #7 on Fri 08 Oct 2010 03:00 PM (UTC)

Message

Jasonius said:
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.

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.

Jasonius said:
If I do the work to make it playable on the server side

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

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

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Jasonius (12 posts) Bio

Date

Reply #8 on Fri 08 Oct 2010 03:22 PM (UTC)

Message

David Haley said:

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

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...

Quote:

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

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.

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #9 on Fri 08 Oct 2010 07:35 PM (UTC)

Message

Jasonius said:

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?

Posted by

Jasonius (12 posts) Bio

Date

Reply #10 on Fri 08 Oct 2010 08:28 PM (UTC)

Message

Worstje said:

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.

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #11 on Fri 08 Oct 2010 09:11 PM (UTC)

Amended on Fri 08 Oct 2010 09:13 PM (UTC) by Twisol

Message

Jasonius said:
(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.

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.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Jasonius (12 posts) Bio

Date

Reply #12 on Fri 08 Oct 2010 09:38 PM (UTC)

Message

Twisol said:

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.

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #13 on Fri 08 Oct 2010 09:39 PM (UTC)

Message

Jasonius said:
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.

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?

Jasonius said:
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.

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (23,122 posts) Bio Forum Administrator

Date

Reply #14 on Fri 08 Oct 2010 09:50 PM (UTC)

Amended on Fri 08 Oct 2010 09:52 PM (UTC) by Nick Gammon

Message

Jasonius said:

Don't get me wrong - MUSHclient and the stuff Nick does with it is cool - as cool as anything I've seen in MUDding.

Thank you! Appreciate it.

Jasonius said:

But assuming MUDs have to be played with a MUD client just doesn't seem like the right way to look at design.

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

85,962 views.

This is page 1, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.