Suggestions for improving MUD game retention rates

How can we make text-based MUD games have a better player retention rate?

Compare what happens when you first make a new character with a modern graphical MMO game such as World of Warcraft (WoW), Runes of Magic, Warhammer Online, to what happens on most MUD games.

On the MMO, after a brief introductory cinematic, which you can skip, you are usually thrown into the game at some small outpost or encampment. Nearby is a quest-giver who says something like "Welcome Nick. We have a problem with the wolves you see nearby, please kill 10 of them for me and report back". And even if you don't notice the quest-giver you can see the wolves a few yards away, and can just start killing them anyway, for a similar amount of experience.

As you do that you gain experience, will probably level after 10 minutes, and get some useful drops as loot from your first kills. Immediately you are sucked into the game as you are doing things, achieving things, gaining things.

Now compare to what happens when you start a new character on a MUD (and this is only part of the usual stuff):




In other words you are hit with a "wall of text". You spend the first 20 or 30 minutes reading, reading, reading. Learning how to "get", "drop", "inventory", "wear", "wield", "equip", "chat", "say", "tell", "consider", "kill", "flee", "look", "examine" and so on. Boring.

B.o.r.i.n.g.

As my son said, when I tried to get him interested in Smaug: "why do I have to do all this?". Why indeed.

Compare to graphical MMOs, you basically don't have to type anything for quite a while. Or read anything to speak of. Maybe a bit of quest text, enough to get the gist of "kill 10 wolves".

But it isn't because graphical MMOs have 3D engines - that is only used for showing your current "view". The rest is done by design, and use of buttons, minimaps, health bars and icons. And buttons and icons are exactly what you can do with recent generations of text MUD clients (MUSHclient being one example, there are others).

We can make things much easier for the player, like this:

• Instead of typing "inventory" - click on a bag icon which shows what you are carrying.
  
• Instead of typing "equip" - click on a character icon which shows what you are wearing.
  
• Instead of typing "score" or watching prompt lines scroll by, show a health bar window.
  
• Instead of having room descriptions fly by, capture them and put then in a separate window.
  
• Instead of having to "get all corpse" or "take sword" just click on a description of it (or an icon of it) in a "room contents" windows.
  
• Instead of typing "kill minotaur" just click on the minotaur icon or description to start attacking it.
  
• Instead of typing "consider all" or "consider minotaur" have the mob's appear in a list, colour and level coded. For example, coded in green - easy to kill, coded in red - hard to kill. Plus with their level number shown, you can directly compare to your level number.
  
• Instead of having to learn different attack methods (e.g. "kick", "punch", "cast fireball") just have icons on the bottom of the screen with an attack method "bound" to each one.
  
• Instead of typing "quest list" have a quest button that brings up a quest log window.
  
• Have a scrolling window that shows your current location, and where nearby things are, like shops, trainers, healers etc.
  
• Instead of typing "practice" to see what abilities you know, click on an "abilities" button that shows your current skills, and your level of knowledge.
  
• Instead of typing "spell list" to see what spells or skills you can use, click on a button that lists them all.
  
• Instead of giving the player a lengthy rigmarole to go through to get some low-level gear like some simple armour and a beginner's weapon, just start them off with them already equipped.

All these things are reasonably easily implemented - I have already demonstrated a number of them in an earlier post, supported by client-to-server protocols that hide this extra information from appearing in the normal text stream.

For an example of some of this see:




That shows health bars, a "current room" window, a automatically-updating map, an XP bar, and more.

Another example is here:

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

That shows quests in their own windows, and an inventory window with "mouse-over" for details about the item you are looking at.

This page shows a "big map" (world map) with mouse-over info of areas you might want to visit:

http://www.gammon.com.au/forum/?id=9622&page=2

This page shows "action buttons" which you click on:

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




The other important thing to do to make MUD games easier for new players is to start them off in a better place than the usual one, which in most MUDs I have seen is the middle of the main city (or one of the main cities). Immediately the player is hit with a confusing mess of shops, players, and a large town with lots of streets to find their way around. On top of that is a lot of city-based chat which can be confusing for beginners. Things like "LF2M HoT DPS pref" or "WTS 20 blue shards PST".

In fact a major problem with starting in a city is that it is hard to know where to find low-level mods to start your career as an adventurer with.

Contrast that to starting in a small outpost (like you do in WoW). Now you only have a small building or couple of tents nearby, a low-level trainer, a vendor, and a quest-giver or two. Oh, and right nearby, some level 1 or level 2 mobs just waiting to be slaughtered.

In fact, to make it easy you want a minimal amount of things to worry about for the first few levels:

• Leave choosing optional skills for a little while, until the player has some idea why they might be required
  
• Leave choosing optional professions (like mining, smithing) until the player has a chance to decide which would be best
  
• Initially only offer one or two quests to the player - otherwise they start wondering which one to do first
  
• When you want them to move on from the starting area, give them a quest to "deliver a package" to a nearby larger town
  
• Minimize the number of things on offer at the starting area (like banks, mailboxes, auction houses, exotic vendors). This also gives players an incentive to move on when they want to use them.
  
• Design the starting area so it is hard to stumble out of without realising it. For example, have a single "choke point" which leads to harder mobs, and station an NPC there to warn players if they are trying to leave too soon for their own good.

From what I have seen when visiting a few well-known MUDs recently, they have good help files, and energetic, friendly and helpful people on the "newbie chat" channels, and a lengthy "beginners tutorial". But the thing is, they shouldn't need them! If you go onto WoW, they don't have a newbie channel. Why not? Because they don't need one. They don't have lengthy help files with lots of cross-indexing. Why not? Everything is obvious. You equip items by dragging them from your inventory window to your character window. Or reverse that to unequip them. To see what something does you simply hover the mouse over it and an information window pops up to tell you what the item does. Items are colour-coded to indicate which ones are, overall, better than others (for their level range). To use something you RH click it (e.g. RH click a potion to drink it, RH click a bandage to apply it, RH click a piece of equipment to wear it).

This simple model of user-friendliness can be replicated on text-based MUDs with a bit of work at the client end, to make the little windows, and some work at the server end to make communication unambiguous and easy to decode. For example, the server can identify every item with a globally unique ID (GUID), so that if the player wants to equip an item there is no dispute about which item it is. When the player changes rooms the server can send down the new room description, and what its exits are, as a special message that won't be confused with other messages, like player chat.



You could also consider losing some of the more annoying requirements that just make life tedious, like having to eat and drink all the time or you lose health. Why bother? If you are going to do that, why not make the player visit the toilet, fill in his tax return, babysit his little brother, and take out the garbage as well? You are there to have fun, not micromanage your avatar's life.

Also consider losing annoying things like:

• Rooms with no exits
  
• Rooms that "impossibly" get you lost (e.g. leaving west from a room and coming back into the same room from the east door).
  
• If you die while you are still learning the game you lose all your gear and have to "run back" to get it, thus probably dying again from the same high-level mob that killed you the first time.
  
• Losing all your gear and not even realising it until you wonder, three days later, why you are having trouble killing stuff, meanwhile your corpse has decomposed and you can't get it back.
  
• Losing most of your experience when you die, so you have trouble getting up a level, which is the very thing you need to do to avoid dying.
  
• Losing control of your character during tutorial sessions, with messages like "You can't move right now, wait until you get more instructions."
  
• Ridiculous messages about room contents, like "You are in a oasis with a large rock here". You type "look rock". It says "There is no rock here".
  
• Mobs with hard-to-guess names, like "You see a dwarf miner here". You type "kill miner". It says "There is no miner here".
  
• Not being able to leave the town (and therefore quest) because it is "night" and "the gates are closed". Hey, your players may only have a 30-minute window of time to play your game, and you are not letting them out of town?
  
• Making it impossible to see things at "night", so players have to muck around buying lanterns. I can understand maybe limiting visibility a bit, but not seeing anything? Again, some players in some parts of the world will be playing during your MUD's "day" and others during its "night". Why should you be disadvantaged just because of where you live in the real world?
  
• Letting other players kill you while you are level one and probably immersed in reading the help files. Save that for when you are level 10 or so, or make PvP be consensual.
  
• A backpack that is so small you can only carry about 3 or 4 things.

Some of these issues could be fixed by having clickable room contents, and clickable mobs. If the rooms contents are "important" you can click on them. Ditto for mobs. Then you don't have to guess what names the designers gave them.



In summary, I suggest:

• Client interfaces that simplify most of the things you commonly do, like:
  
  
  • quest log
  • what you are carrying, and your gold
  • equipped items
  • known skills and spells
  • friends list
  • ignore list
  • maps (minimap, area map, city map)
  • health/mana status
  • what your target is and its health
  • action buttons for things like attack, heal, stealth, spells
  • if you are grouped, who with and the status of group members
  • FAQ or help information
  • showing what is on sale at shops
  • showing what trainers can teach you
  • interface with banks and auction houses
  • interface with quest-givers
  • what room you are in, what its exits are
  • who and what is here in the room with you (players, NPCs, objects)
  • a path-finder or way of locating important things, like shops, nearby towns, cities
  
  
• Start players off in a "starter zone" with lots of low-level mobs nearby and some quests to encourage them to kill them
  
• Quests that teach things, e.g. a gathering quest to encourage them to pick things from the ground, and a loot quest to encourage them to get loot from mobs
  
• Get rid of annoying things like needing to eat and drink all the time, or losing all your gear when you die
  
• Give players some "get me out of here" ability (like the Hearthstone in WoW, or "recall" ability) which can recall them to their home town or some friendly place if they get hopelessly lost (with something like a one-hour cooldown so it doesn't get abused)
  
• For early quests, or indeed, all quests, show on their map the general area where the quest is to be done (e.g. by colouring the relevant rooms in a different way)
  
• Make it easy to find important things, e.g. by marking or colouring map squares to show shops, repairers, trainers, quest-gives, portals etc.
  
• If possible add to the game immersion by having some sounds that play automatically, e.g. sword hits, combat music, rustling sounds when your bag opens, drinking sound when you quaff a potion, and so on.

I think we have to get away from trying to support every possible client. I have no vested interest in saying this, because although I am a client developer, the client is Freeware, and the source code is available to anyone that wants to download it.

There is still a lot of scope for text-based games, because they have a lower development overhead than 3D games. As my existing experimentation has shown, you can take the basic data that existing game servers work with (the "room" model, text descriptions) and automatically generate fancy maps, health bars, button bars, and generally a lot of the sort of client interactivity that the graphical MMOs already have.

I completely agree with you here. The learning curve can be pretty steep for the new player, and there's a lot you have to learn even after you've adjusted. In comparison, most MMOs have very simple interfaces.

In regards to providing a user-friendly GUI, I've been tinkering with my own web-based client (which I mentioned before). It's still mostly in the concept stage, but I've written a basic browser-to-client interface, and I'm working on the client-to-server interface. The big thing about my client concept is that the GUI can be represented with HTML, CSS, and JavaScript, which (as has been shown over and over again on the Internet) can produce extremely functional results.

This is something I take very seriously, and I hope that my client (if it gets off the ground) will advance that cause.

Excellent post, Nick. Player retention is an issue that I think most muds struggle with, and I've spent quite a bit of time trying to think of ways to make my game more newbie-friendly.

I've avoided all of the "annoying things" you listed, and have done everything mentioned in your summary except for the client features (although that's something I keep meaning to get around to - which is why I browse these forums).

The only thing I've done differently to your suggestions is to start new players in the main village. I did this originally to avoid the newbies feeling isolated from the rest of the playerbase, but I've since had a few players tell me the thing that really "hooked" them within the first few minutes of joining the mud was seeing clouds of bats fly past, or dragons swooping down from the sky, and realising that those were other players. You really need to impress newbies within the first few minutes, and putting everyone in the same starting location lets me showcase some of the cooler aspects of the mud. The downside is that it can sometimes get a bit spammy, even with relatively few players, so I may need to change it at some point.

In regard to tutorials, an idea I've been playing with recently is a 'what' command. Your prompt initially tells you to type 'what' (much like Smaug does with 'help start'), but the difference is that you can keep typing it throughout the game, and the advice takes into account what you've done so far, where you are, what you're currently doing and what abilities you have. In the newbie phase it takes you through the basics one step at a time, giving you a series of clear objectives and suggestions. In the later game it gives you multiple recommendations, as the gameplay at that point is much less linear.

But its optional, it's advice that you can heed or ignore as you see fit, not a tutorial that locks you in until you've completed it. The idea is that if you're ever stuck, and don't know what to do next, you can just type 'what' for some pointers.

I do still get occasional complaints from new players about the complexity and learning curve, but these complaints mostly seem to be made by experienced mudders, so I suspect its mainly down to a lack of familiarity. In particular, I've identified a certain breed of experienced mudder that tends to switch off the hints and ignore the help files, then gets frustrated when they can't work out how to play. But I don't really know if there's anything I can do about them - to cite an old proverb: you can lead a horse to water, but you can't make it drink.

Your comment about newbies asking questions on the newbie channel is also something I'm very familiar with, but I think it's too ingrained into the hobby as a whole to change completely. Many muds have poor and/or outdated help files, so players from such muds tend to get into the habbit of asking first. Some newbies also prefer talking to people rather than reading help files, or use the excuse to find out how active and helpful the community is.

I have to ask; what clients should we support if we shouldn't try to support them all? I may have misunderstood you, but only supporting next-gen clients or a single specific client seems like a step backwards to me.

As part of the Unix philosophy, using text streams because they are a universal format, why not supply a possible config for a specific client or two and simply handling things as-is? I won't say things couldn't be improved server-side, but trying to supply data for a single client or a small group of clients seems like a limiting factor and, in my opinion as a player at least, like a good reason to NOT play a MUD if the client I've had for a decade (hopefully with updates), have learned all the ins and outs of, and have a ton of scripts for won't work. For a new player this may not be an issue but this seems to alienate older players some, or people who prefer non-GUI clients (tintin++ for an example).

I realise the above question was addressed at Nick, but I hope you won't mind if I chip in with a response as well.

Obviously there are advantages in supporting lots of clients, because (as you point out) some mudders can't or won't change what they're using. But on the other hand, not every client offers the same features, and trying to provide the same playing experience to all of them can require a lot of work and/or compromises, and sometimes just isn't possible.

Here are a couple of real examples I've dealt with:

1) If you try to negotiate with the windows telnet client (at all) it switches off echo, which makes the mud considerably less pleasant to play. But if you don't negotiate with the client, you can't take advantage of protocols like MXP, MCCP, ATCP, etc. My workaround was to perform negotiation after login, with the option to switch it off beforehand, but this means I can't use links, graphics or extended colours on the login screen, even if your client supports them. At some point I may bind the mud to a second port to get around this issue, but even that is really just another workaround.

2) I've recently been playing around with MUSHclient, trying my hand at creating a custom plugin for my players - it's still a work-in-progress, but I'm pretty pleased with the results so far (screenshot: http://www.godwars2.org/images/plugin_screenshot11.png). However my plugin is written in Lua, uses graphical tiles, and requires the MSDP protocol. I know of only 3 other clients that support MSDP - the first doesn't support graphics, the second doesn't support Lua, and the third costs $30 (and is used by less than 6% of my active playerbase - compared with the 46% using MUSHclient).

It's not a matter of blocking certain clients; I try to keep my mud playable with all telnet clients, but I don't go out of my way to actively support them all, other than through network protocols. The more of those protocols your client uses, the better your playing experience - which means you won't get the full experience unless you're using a client that supports them all. There's no real way of avoiding that while offering the features I want to offer.

Anyone playing from a telnet client is generally going to be limited in what they can or can not do with their 'client'. To handle the echo issue, it would seem somewhat trivial to have the MUD echo the command to the player given a config option, though I'm sure there are other issues not listed.



The part in bold was something that I was afraid he ment. If a client doesn't support a protocol (MSDP, as you mentioned), then there is little you can do other than maybe offering a workaround for it and simulating the protocol (here I have no real clue what MSDP does, just using the name at this point). The idea of blocking a client (or whitelisting only select client(s)) seemed wrong to me, not just because some users won't switch clients (I used Gmud back in the day well after support for it ended), but that seems to be limiting the player's choice in clients (maybe with such effects as eliminating an OS due to (lack of) support issue) and possibly killing off an up and coming client that may well develop into something that makes today's Client To Have resemble a very basic telnet client that only writes in sandskrit for as usuable as it is in comparison.

Your image:

There was a pretty lengthy discussion about this a little while back on the mudstandards.org forum.

[EDIT] (April 2015) Warning: Domain name abandoned. That site is now an adult products shop.

There are two basic schools of thought, one being that backwards compatibility is very important (eg. "don't leave my favourite client X out"), and the other one being that we will never be able to support fancier things (like the screenshot above) unless we accept that some clients won't be able to handle it.

My view (and one that wasn't shared to an enormous extent I have to say) is that there are plenty of purely text MUDs around, which most clients can connect to.

But if we want to implement the things I mentioned in my first post (like graphical inventories, health bars, quest logs etc.) then we just can't hope to support every client. Even making things optional adds a huge burden to the server. For example, something like a quest log would have to have a text equivalent, if you were going to support every client, which basically means doing everything twice.

If I was going to develop another server I would just use a custom protocol from the start, effectively forcing the use of a special client. Not necessarily a closed client and indeed the protocol could be made public. In fact, MUSHclient could be used as demonstrated in the YouTube videos I did recently.

I would move the emphasis from "mainly text with a bit of extra stuff which can be shown in health bars" to "practically all specially-formatted messages with little or no straight text".

This moves the burden of markup from the server to the client. For example, rather than the server choosing to show chat messages in yellow (say), it simply identifies a message as a chat message, and lets the client colour it however they like, knowing it is chat. eg.



This also simplifies the client. Rather than having to have complex triggers to try to detect chat, status lines, combat etc., you have well-defined messages that very explicitly state what is happening.

Nick.karma += 10;

I completely agree with everything you just said.

This seems contrary to your first post, since you are effectivly saying 'Either use a special client, or play something else', which as I stated in a previous post has some more problematic issues, such as limiting the OS one can play from.



At this point I will argue if you are even still developing a MUD at all. This is more of the sort of thing for a run of the mill MMO than something one (at least I) expect from a MUD, given your ideas of using alot of graphic features to issue data to a player instead of the traditional text-based system.



Here I'm wondering if the idea you are proposing isn't already doable and still remain backwards compatable (or compatable with other clients at all). Using your example, you have provided a bunch of information which seems overly verbose, since 'Nick chats "hi there everyone"' is alot shorter.

I'm also concerned about whether or not, if this path were to be taken, the added effort required by client developers to support X number of protocols would mean the death of many and end up with only a select client (or few clients) that can play a specific game, much like the current system in place by MMOs. If a client were to be written to interface with a specific MUD then there is not only the support issues regarding the MUD to deal with but also the development and support issues of the client on top of the server, doubling or tripling the work load of developers and may (should things progress too far down this dark road) prevent other games from opening up simply due to the enormous workload a probably lone hobbist dev will have to face.

I am trying not to be too dogmatic here. Some of my earlier suggestions could be made to any existing MUD, and some could be added on without too much trouble. Indeed Aardwolf is an example of addding on mappers, status bars etc. (and it isn't the only one, looking at the screen shot above).

You make an interesting point about the OS, but in the case of MUSHclient, I am actually using it on Mac OS/X (inside a Windows XP VMware virtual machine). So it is certainly usable on a Mac (provided you have an old copy of Windows lying around, and don't mind paying $99 or so for VMware). An alternative is Linux and indeed I also run MUSHclient on Linux inside a VMware virtual machine on my Mac. So (since Linux is free) you could do that for no expense (there is also the Sun Virtual Box which is free I believe, as an alternative virtual platform).



Well I suppose it is a matter of definition. MUD is technically a Multi User Dungeon (or that is one definition), and an MMO is a Massively Multiplayer Online game, so the point at which you say "this is not a MUD" must be slighly blurred. After all, a MMO often has dungeons, and a MUD could have lots of players, and is definitely online.



It is doable, providing backwards compatibility restricts you to an extent.



Well I was suggesting a single protocol, where you have a well-defined way of sending information from server to client. Once you start talking about backwards compatibility you have at least two - the new interface (eg. which provides mapping information) and the old interface for older clients.



You may be right. Some of the talk on Mudstandards.org was along those lines. However my response is partly that an open source client (MUSHclient) already exists, and can already handle out-of-band telnet messages. So really you don't have to write a client, all the connecting to the MUD stuff is already there. It is more a case of writing plugins that can handle the proposed protocol.

And indeed with a bit of agreement (which was sadly lacking unfortunately) a standardized protocol for exchanging room information, combat information, etc. could be developed. So, far from being locked into one proprietary client/server solution you could have lots of servers providing standard messages, which then any interested clients could interpret.

As an example, the mapper plugin I originally wrote for Smaug, and then adapted to run under Achaea, was easily used, virtually without modification, by Aardwolf - just by telling them how to present room information to the client.

So already we have two mainstream MUDs sharing a common mapper plugin. And since the protocol is no secret, other clients can choose to use it in any way they wish.

I see flexibility here, and an improved player experience. I am not sure about the "dark road" you allude to.

But don't get too worried. My experience on the Mudstandards forum has shown that we are unlikely to get any agreement, and therefore nothing is likely to happen to cause "the death of many".

And, hey I agree that whatever this new client/server thing is, perhaps it can't be called a MUD and therefore is not competing with existing MUDs (at least, not in name).


[EDIT] (April 2015) Warning: Domain name mudstandards.org has been abandoned. That site is now an adult products shop.

VMWare Player and at least one version of VMWare Server are free, and I use/used both in the past for my forays into Linux. The limiting factor is mainly the OS virtual machines you have access to (i.e. that old copy of Windows you have lying around).



My current opinion is that standards should follow widespread adoption, not the other way around. If someone has an idea and other people start implementing it, those people can get together and define a standard implementation of this previously nebulous "thing". MUDStandards is/was full of bright ideas, but it is/was trying to create rather than define. I no longer think that's a good way to do things.

EDIT: On the local level, bright ideas are priceless. My point is that standards can't just come out of thin air.

I'll reply more later, but I just wanted to comment on this:


And at this point, I'd ask one thing: is the point to develop a fun game, or to develop something else?

These seem to me to be contradictory objections. If some proposed changed required "added effort", "doubling or tripling the work load of developers" with an "enormous workload" then surely the idea will fail, and the existing MUDs will not in any way suffer any harm.

The idea behind my original suggestions was to make things very easy for the hobbyist developer. Easy to produce a game that meets the expectations of players in 2010 rather than the way we played then in 1980.

So you still have text descriptions (which a small team can invent and key in), and thus no need to use 3D engines, and have teams of artists making 3D models, and 3D terrain and so on.

However the key idea is to improve the user interface - after all we have drag and drop now, we didn't have it in 1970-1980. We have GUI interfaces. We have more memory and faster machines. We have faster network connections. We can render a map or minimap on the corner of our nice large monitors, and have health bars, and experience bars. That simply wasn't possible 30 years ago.

Remember, the game designers of the original MUD games pushed the technology (of the day) to the limits. Why should we stop doing that?

The issues with a virtual machine (btw, Virtualbox is a decent, free virtual machine that works on most OS afaik) are not only overhead but complexity. Your first post mentioned trying to simplify things (no more eating/drinking, loss of equip), and having to install, maintain and keep a virtual machine updated has added alot of work for a simple MUD client. This may not affect Linux users as much as other OS (we're kinda used to Wine and virtual machines), but there are other OS out there (haiku, the BSDs, minix, and several other lesser known OS) that some of these things won't/don't work with and may never be able to (minix here is a great example. It is such a minimal system the use of telnet would probably be required to play a MUD, since I am unaware of any graphic enviroment for it).



Quite so. I see MUDs as mostly text-based games played over a network, whereas MMOs are generally graphic, and generally simpler.



This would mean convincing people to use a single protocol, which some may choose not to, or they may choose to extend. This is where problems could arise between client/server communications and would increase workload somewhere (depending on who decides to try and support this addition).



I can see a few possible problems here. One issue could end up being 'Which format do we use to send information?'. There is XML which might work, already has libs that will handle it, and is a widely supported 'standard' (it almos makes me gag anytime I look at it). There is also SLang or Lua which could be used (providing the client with code to execute for some fancy effects, otherwise using a simple variable=value notation for info), or maybe some other concoction someone cooked up for their own MUD (which may totally lack some features another would need). Another issue is 'How do we handle extensions of this protocol?'. Not all MUDs have or need to provide the same info, and if someone decides that they wish to provide something extra then the client needs to handle this, else Bad Things could happen (wasting time coding something cool for no one to see it is one thing I count as a Bad Thing). Then there is still the issue of those who don't like the standard for reason X (If using XML, they feel it is a crap system and want something else), which then means that, if plugins are used to support protocols, the dev has to support their own MUD, and effectivly a client as well.

Standards are fine, but getting people to support them (or finding something everyone supports) is a PITA (except for some of the more obviously advantageous ones, like MCCP), and with a growing number of standards there is the issue of which ones to support and which not to support.

[EDIT] (April 2015) Warning: Domain name mudstandards.org has been abandoned. That site is now an adult products shop.

This ground has been gone over at some length a month or two ago on the Mudstandards.org forum.

One problem is getting client developers to agree on a format (eg. XML, Lua, JSON, bencoding) for sending data to/from the server.

The next problem is convincing server developers to agree on the same thing (harder than it sounds).

Then we hit the issue (which you raised) about supporting, ah, less frequently-used systems (eg. minix, bsd) or ones such as Internet Cafes. So either you write something that the lowest-common denominator can handle (and I mean that in a nice way), or some users get left out.

Then we hit the issue of some games having non-standard (if I may use that expression without getting attacked) designs. For example, if you build into the protocol a message when you change rooms, some developers said "but we don't have rooms".

Or if you have coordinates, some MUDs don't have coordinates. But if you leave them out, then the ones that *do* have them need them to be sent.

Then we have the issue of "oh but you are forcing me to use a standard", or "I don't want to change things, don't make me". Or "who the heck are you telling me what to do?".

My proposal at the time was to have a simple protocol that just sent keyword/data pairs, where the keyword/data was basically what was relevant to the MUD (eg. room_number=12345). At least that is extensible, since any MUD that needs to can add keywords (eg. coordinates).

However if it is *too* general, well we haven't really defined anything much, and if it is much more specific, well we can't reach agreement about what the keywords should be, what the data should be, how often it is sent, whether frequently-sent data should be cached, and so on.

I read an interesting post elsewhere today about MMO development. In that the poster basically suggested designing to a specific subset, otherwise you will be there all year trying to accommodate everything.

I think this is fair advice. Perhaps a subset would be "Muds that have rooms, but not coordinates", and then take it from there (just an example mind you).

It is interesting BTW that when you look at a game like WoW, they actually simplify some things quite a bit, but in a subtle way. For example, you can't drop things on the ground. Also, players can walk through each other and through mobs. Now you might argue "but I *should* be able to drop things on the ground", or "I should *not* be able to walk through people" on the grounds of realism. But by limiting their design in this way they greatly simplify the design of the client and the server.


[EDIT] (April 2015) Warning: Domain name mudstandards.org has been abandoned. That site is now an adult products shop.

My concerns of workload is mainly directed at new devs. For a skilled programmer who can get a computer to compute the value of 1/0 (let's not start on this example), then things aren't quite as bad. My concerns are more for those who see a MUD and think "I can change this as I want and it will work" who may end up seeing it as "I'll need to change this server, then change the client to handle what the server says".



Given the current trends of games these days a text-based MUD doesn't meet a 'modern gamer''s expectations, since players seem to want flashy graphics and cool explosions. Either we are looking at a diffrent demographic than the 'modern gamer', or we are climbing a mountain no one cares about anymore.



The lack of these can be a good thing, but there are free 3D engines availible, as well as programs to make 3d models and such. Skins are harder to make, but then again writing a good room desc takes skill as well.



I've seen stories where people did things on older hardware (30+ years old) that people couldn't do on a modern machine, or the older hardware simply did better. Screen space is the only thing you have listed that would make a huge diffrence, and that is something that really doesn't exist (try opening 3 xterms on a widescreen and see how quickly things get crowded).



They may have pushed it to its limits, but how many computers back then were running half a dozen diffrent apps at once? With current trends in CPU, memory, and disk usage the supposed power of your current desktop isn't that impressive. I will actually say trying to push modern system's limits is a Bad Thing since
A) A MUD client will likely be one of many programs running, along side a browser, chat client, email client, and possible other programs
B) Some players play MUDs because they can't handle newer games like WoW, Guild Wars, or <insert game here>. Rural areas sometimes are still stuck with dial-up, or a kid is playing off his parent's old system (bought brand new with a top-of-the-line i486).

We have no clue what resources are avalible, if any, for the game which we develop, nor what kind of system the player is coming from (or, for that matter, what kind of network they are on).

In the case of the server, there are still other issues. What hardware are we running on? Are we on a p2 shoved into some closet or running on a 64 core dedicated server with more memory than a herd of elephants and a network pipe you can run a subway through? Are we transmitting enough data to flood a user's connection so they can see a goblin's brain splatter on their screen?

Something I had thought about while posting was the possibility of a basic system, probably like some of the legacy systems (ch says "sentence") which provides the needed data for a simpe chat (who, the channel, and the content) but still works with older clients. For content that would be required for a more complex interface (automapping), then I was thinking 2 standards:
1) The 'Don't Print This' standard. Simply put, content that the client doesn't support at this point is dropped from the input, never seen by the player
2) A generic macro/alias/trigger system to handle key=value pairs, or some other method of handling info.

This way older clients could simply ignore the content after a point (or a client that handles input modification could have a script written to delete the content), or do something with it (hopefully something other than telling the server to interface with itself).

Beyond this leave it up to MUDs to handle their own things. If a group of MUDs wants to work with a specific set of scripts then let them. If they want to modify(given no license issues), then they can.

The MUD will then still have the issue of 'how to we support people who don't use a standard-compliant client?', but they could also say 'Screw it. They will get the info, let them do with it what they please'. If these values are transmitted through a single function, then adding a single config to the game could eliminate the output and no one is left out (even telnet users!) unless the MUD does something really screwy, like just using this data to tell the client things.

I see it more as an extension than a replacement for traditional output, but might could satisfy everyone with some work.

For what it's worth, a while back when I was playing WoW, and my cable connection went down, I dropped back to dial-up.

Whilst it was a bit sluggish, it certainly ran OK. They have quite cleverly designed it to heavily cache things (and the drawing of the brains splattering is a client thing), and use predictive movement algorithms etc.

In any case, any future developments aren't going to replace what we currently have. There will always be a place for text MUDs, and low-bandwidth connections which could be used by rural communities and those that don't want to, or can't, use broadband.

In fact, I have quite a few people on this forum who ask about screen readers, as I presume they have limited or no vision. A text game is ideal for such situations. Ditto if you can't move your hands quickly enough to play a "twitchy" graphical game.



That's true for major changes. But once you have the infrastructure in place, most changes will work within it. For example, you could add new rooms, new mobs, new quests, new towns, new chat channels. You can change combat algorithms, damage messages etc (provided there is some mechanism for "display a general message").

So I don't think developers would be paralyzed into not being able to make any change without having to also change the client. It's a bit like web browsers, web page developers can make many many changes without having to get the browser changed. But occasionally browser changes do add new functionality (eg. playing inline movies).

I played Guild Wars years ago on a dial-up. The loading was the problem, not the game play. However the desire to feed more and more data to a client may become more of an issue, same as using CPU and RAM.



The easy of extension is definatly an issue related to the design of the game and client, but some poor design choices (done either out of ignorance, spite, or no better way) can still be an issue. imo, vnums are a great example of such a choice.


That is true today, but it hasn't always been. During the early days some websites required (some still do, mind you) special tweaking to work with a specific browser or a browser had to emulate bugs in another to work properly. Even today there are still browser-specific webpages (requiring IE-specific plugins to function, for example) and content that browsers can't handle (flash, quicktime movies which the browser simply places on the screen).

actually, why not use web browsers as clients anyway?

A web browser is available everywhere, so you don't have to program the client and the communication will pass any firewall. You could add some SVG elemens for some status bars, buttons, minimap, ... (SVG = Scalable Vector Graphics; It's a text format that rowsers can render into a graphics of any size/percentage of the window. Internet Explorer needs a free plugin, (most) others can do it without plugins).

Everything is done by the server, which can build this information by description files for rooms (or for cards in my case).

That's -my- project. ;)

@Twisol: Is there any project page? Or even a prototype? Are you going to provide sources? Which licence? It would be really interresting to here some details of your concepts (somewhere).



On the subject in general:

I think there are two key points:
- one is about game design
- the other is user interface design


Game design:
I must admit that I was playing MUDs only for an hour or two about 1998 - a friend was very enthusiastic about it, so I tried it. However, I can still remember what happened:
I started somewhere, did not really know what to do, just went to the south a couple of time (if you don't know where to go any direction will do), and finally encountered a thief there stealing some coins or something. I decided to defend my self and was killed in a couple of seconds (2nd hit, I think). Now the game wantet me, as a ghost, to float around and find some altar or temple of something. Without telling me where to go or giving any other options.
I asked my friend what to do and he said that I'm not supposed to fight thiefs for the next 100 hours or so. I'm supposed to start fighting flies, later advance to mice and on level 10 or so we can talk about rats.
That's about the point I decided that I've better things to do (and Baldurs Gate came out a couple of days later, followed by several Infinity Engine games that I still play once in a while).
I assisted some people that wanted to build their own MUD, but I never played one again myself (now I prefer to programm card games which use similar programming techniques.)

=> Now, I think such things could easily be avoided.
You HAVE TO fascinate the user instead of frustrating him or her in the beginning. You MUST give the user a feeling of success in the first five minutes, or you are going to loose him before you really got him.

Of course, once you 'have' the user, keeping the game attrative on the long term is another issue.


Interface Design:
A computer which does not have a graphics mode does not exist anymore. There is plenty of space on the screen (unless you programm for a mobile phone which would also ba an interesting idea). Use it for status bars and icons that allow the user to see lots of info without actually reading lots of text.


You could use an existing engine as well, e.g., do a MOD of an existing (commercial) game. Some games even provide graphical level editors for that purpose. However, doing so you will allways keep something of the nature of the original game. E.g., if you got a very combat oriented end time adventure you probably won't make it a story focused fantasy game. But you can get nice 3D graphics this way without development overhead - at the cost of not heaving a standalone game.
Anyhow, it does not need to be "full" 3D with unlimited zoom and rotation. You certainly can generate some 2D or even isometric (3D) graphics on a client if you have a small set of object models and coordinates from the server.



If you dont want to change the server, automatically generating the graphics from the info that is already there will be your only chance.

Thank you, you have described rather eloquently what I think causes people to switch off a MUD shortly after trying it. And this sort of thing could be so easily avoided with a bit of code.

For example, just don't allow combat in cities where you put beginner players, or at least not below level 10 or so. Another thing might be to have an "easy death" option, where it says something like "you died, but the gods resurrect you on the spot, as they realize you are a beginner".

By contrast, popular games like WoW only put level 1 or 2 mobs near beginner players, and they are non-agressive. And if you do manage to die, it is a short walk back from the graveyard to your corpse, with the location of both being shown on the minimap.

Answers in bold.




It's a web-based client to connect to any MUD, a lot like Mibbit (mibbit.com) is for IRC networks. I call it Aspect. It doesn't use any plugins (no Java, no Flash, no Silverlight), relying solely on Javascript. It does not directly speak with the MUD; instead it talks to the Aspect server, which itself talks to the MUD. This will let me do a lot of cool things.

I want Aspect to be as full-featured as possible. Most of the web-based clients right now are kind of... lame, in my opinion. Aspect should be just as powerful as MUSHclient (except it runs on my server instead of the user's computer). One of the things I really want to do with Aspect is let MUD owners custom-craft the interface a user will see when they play their game. Things like this should be very enticing to MUD admins.

Aspect is currently in the early concept stage, with under 100 lines of code yet written. It's written in Ruby, though, and takes advantage of EventMachine (an evented (reactor-based) library), Thin (web server based on EventMachine), and Cramp (an evented web framework) for its foundation. Users communicate with the server via Ajax long polling (which any client that supports Ajax can do), which means the server keeps the connection open until it has data to send. This keeps things real-time (or as close as you can get). I also use Rails, primarily for its excellent URL router, but also for managing the non-client part of the website.




Expanding on my point before about custom interfaces, I really really want to support user plugins. I don't yet know what exact form they will take, but I have a few ideas rolling around. I definitely want to have an API to take advantage of HTML 5's <canvas> element, though. In fact, thinking about the similarities between <canvas> and MUSHclient's miniwindows is what got me started on Aspect!

Thinking a bit more about your question from the marketing point of view (instead of the technical one), I think it needs to be analyzed and defined more clearly:
"What can be done to improve the retention rate of MUD games?"

You need to define "retention rate" (long or short term; stay at a particular mud or just within the game family), and most importantly "MUD" (where would you put the border between a "MUD" and something else). Furthermore, you did not define any constraints on "what to do" (by whoom, up to which time/money effort, commercial or hobby project, what can you change that it is still a MUD and not something else).

"How can the one and only game desinger of an existing, free online text-only adventure reduce the entry barrier for new players?" is a different question than "How can I build a game commercial game from scratch

that the players will play and, thus, pay for for years (instead of going hiking or something)?".

Market strategy textbooks say: If you do not have the resources to built and run something state-of-the-art/close to the market leader, you have to find a proper niche.
What precicely would you think that "the market" is here?

Yet another question: "What would you be NOT willing to sell for a higher retention rate (or something) in order to still call your game a MUD?"

These are very good questions.



One simple measure would be "how many players are on at peak times" - that is, is this figure rising or falling? However that doesn't distinguish between lots of new players, all who leave a week later, or a hard core of existing players.

I would suggest measuring (from time a character was made, plus played time) two things:

• How much play time they have put in (eg. 100 hours)
• How long this character has been active (eg. 2 weeks)

You would need to define "active", but I guess if a player logs in at least once a week and plays for 30 minutes you could call them active.

I read somewhere that Iron Realms found that new players tended to leave "once they had to move around" which I take to mean within 15 minutes or so. So obviously a retention time of 15 minutes is not too good. That would tend to indicate confusion with the basic interface (or the need for maps, or more understandable controls, or something).

If a player lasts a few days, then they have probably grasped the basics of moving, but maybe haven't yet done much combat.

If they last a few weeks, then we can assume they are into combat, communication, etc.

So I guess my answer is, if the average time a new player "keeps playing" increases, for a given MUD, you have improved your retention rate.



It would be difficult to know whether a player leaves one MUD and starts at another, so I suppose the easiest to measure is per MUD. Also they may make one character, delete it and start a new one. If you tracked IP addresses (or accounts) you may be able to treat that as a single player still playing rather than two players, one who stayed and one who didn't.



I suppose I mean a primarily text-based multi-player game, where room descriptions, mob descriptions, character and object descriptions are in words and not 3D graphics.



In this case I mean something that can be reasonably achieved by the person or people who are currently maintaining the MUD. For example, my videos showing status bars, room descriptions in a box in the corner, a mapper, and so on were done by a single person (me) over a couple of weeks.



Indeed. And if time is tight then even a subset of my suggestions could be implemented. For example, bearing in mind the recent post, simply tweaking game parameters so that newbies don't get killed by high level mobs in the first 10 minutes, could be a reasonable first thing to change.

Another simple change might be to start newbies off with more equipment so they can start doing things rather than spending the first day just getting good enough gear to leave the city walls.

A game with more resources (like Achaea for example) might be able to go further, and have graphical mappers, and party member icons. However if this is still around the framework of their existing levels and descriptions, I think it is fair to say it is "still a MUD".



I think that there is still scope for more individual "indie" games - ones that the big players wouldn't dare touch. Niches could be:

• People on low-bandwidth connections (eg. country areas)
• People with low or no vision, who appreciate the fact that screen readers can read out the descriptions
• People who are less able to use "twitchy" interfaces like mice, due to older age, or disabilities.
• An edgier level of content (eg. adult content) which big companies wouldn't touch
• Games with player-developed areas (MUSH games tend to be like this)
• Games that can add content much faster than graphical games because they don't need to make 3D models of everything.
• Games aimed at smaller devices (eg. mobile phones)

I can't answer that one. Short of a complete rewrite, existing MUD servers can probably still call themselves MUDs.

Certainly, as already discussed, step 1 would be to avoid needlessly scaring of the users.
About the potential niches:



Do you think there are still a lot of such people? In europe certainly not - even mobile internet with about 1 MBit/s is available almost everywhere. The time I only head a modem conection at home (15 years ago) I was not playing online, because it hat a price per minute online (not per MB), equivalent to the price of a phone call. I mainly used the internet in the university that time.



OK. It may work well for such people.



There are programs to substitute mouse input with keyboard. The keyboard is not an easy to use interface either. Having no realtime requirements in the game might be the key here.



Adult content: I don't think comercial games have problems with erotic or extremly violent content - maybe those are not the games displayed in the window, but they are available. Political and religios content (the extreme-frankincensing-MUD?) might not have too much interested people.

However, I think the commercial games focus almost exclusively on the high fantasy genre (the - lord of the rings/dungeon & dragons - stuff). And if it's not high fantasy its high science fiction (star trek / star wars). What about western? Eastern? Steam punk? Victorian era? So it does not need to be adult content, just not within the narrow mainstream.



Both things may be done by MODs (modifications/additions to commercial games). Some games offer editors for players with no or little programming abilities (e.g., Neverwinter Nights (NwN)). In fact those abilities are one of NwNs key featurs.



You might have some problem whit the limited amout of text you can show on the screen of a mobile phone. If you get this managed, right.



Once I was not allowed to completly rewrite some piece of software that was full of flaws. So I recycled one } from the original code ...

So I think the quest/room/creature/item description texts and their connections should be conserved. Would you "allow" to completly rewrite the engine? Replace it with a new one that REQUIRES to add additional contents like icons?

With the question I ment somewhat more general: What are the MUST HAVE key concepts of a MUD?
e.g., "has to be online (or bigger LAN)", but a more critical ones is "must have ONLY text", ...

The iPad has 1024 x 768 screen real-estate. For quite a while this was considered normal. Also you can plug it into a proper keyboard (for around $US 69).

So playing a MUD on a mobile device is quite achievable these days. Even the built-in keyboard (onscreen one) is quite nice to use, although it obscures some of the screen when it is "up".



Well personally I wouldn't say "only text" but that text is the medium for providing descriptions. Quite a few people these days are using health bars, XP bars, mappers and so on to supplement their MUD experience.

So my description might be "a multi-player online fantasy game, where the core content is described in words, rather than shown in graphics". Of course, this description includes most current MUDs (if not all of them), but does not exclude the provision of things like user-interface aids like health bars, XP bars, quest windows, buff (spellup) windows, action buttons, and various things to make the experience more enjoyable.

The only "MUST HAVE" I can think of is that it must be multi-player, with some form of interaction between characters within a persistent virtual world. I consider EQ, WoW, DDO, etc to be MUDs as well.

Graphics and sound are part of the client, not the MUD itself. However I would define a "text-based MUD" as one that is designed to be fully playable through a text interface.

So your key features for a MUD are:
- it is a game (played for fun)
- multiple user play in a network and may interact with each other
- the users play it is a virtual world with one (or more) avatars

Additionaly for a "text-based MUD":
- it is fully playable on a text console (a GUI is allowed, but players without should also be able to access the entire content, maybe less comfortable but nevertheless complete)

Everything else could be changed, right?

Personally I wouldn't make that restriction, but I acknowledge that a lot of my fellow MUD developers would. I said in my earlier post "text is the medium for providing descriptions" and that was what I meant.

In other words, if you want to have your hero ride forth on a black charger, heading west into the golden setting sun, with flecks of sunlight peeking over the mountain tops, and a sinister, evil-smelling river gurgling alongside the road, you just say that, rather than trying to find a graphic artist who can draw it.

However I think that to insist (as others do) that your game be playable on every conceivable client, on every conceivable operating system, is just tying your hands behind your back.

The vast majority of players play on just two or three "mainstream" clients (and I use the word simply in the sense that these are the clients that most people use - a sort of circular definition if you like).

My point is that if around 90% of players currently use clients that could easily support a more graphical interface, and we double that number by making the games more fun, then that is a big increase. For example, a MUD with 100 players, 90 of whom could use the graphical interface could double to 180 players if you doubled your player-base. However if you try to keep all 100 happy with pure text interfaces, you may only increase your player-base to 120.

Of course, of the 1000+ MUD games already in existence, people who want a text-only interface have a lot to choose from.

My proposal is to have a pure message-based communication from server to client (and vice-versa) so that each type of message is clearly marked (eg. chat, combat, room description, inventory and so on). This lets you identify with a GUID (global unique ID) things like inventory items, so you don't need to do stuff like this:



All those numbers break the illusion, but are a necessarily evil if you insist on using text to describe everything.

With messages you can implement stuff like this:




Now in that particular demo there was a fallback to straight text, but it would simplify the server a great deal if it only had to send the information once (in messages) rather than having to support straight text, messages, and then negotiate about which one to use.

So it seems to be controversial whether or not any innovation is allowed, that adds anything that is not accessible using a text only (standard telnet) client. In case one answers the fundermental question with yes (it as allowed), it's still the question how far to go. I mean there are even "graphical games" that present most of their contents as text (anyone played Planescape Torment? The areas/rooms are drawn, but you spend most of the time talking and, thus, reading text). So something as "Wyvern" (a 2D graphical MUD) could already be too far.


My suggestions if you do not want to draw areas:

- provide icons for every person/creature and interactive object in the room. Let the user access every reasonable actions on/with them by clicking on them. Provide icons/portraits for yourself and your party members (in that order) at a special place. Use them to cast spells on them, exchange objects, etc.

- provide icons for inventory, maps and travelling. So in total you might need something like 100, 200 icons.

- use some sound effects (exposing the user to a steady stream of music is not required)

- provide a semi-realtime combat mode the player (or party) can activate (or not to stay in a strictly turn based mode). A diverting combat system is a MAJOR, M-A-J-O-R plus.

- include a screen reader and do not call it a "feature for the blind ... reading/seeing ... limites/disabled .." or something. Call it something like "interactive audio book" - so the majoity of people (without reading difficulties) will consider it as a feature for them (sometimes I'm just to tired to reed). Best: Let it read different characters with different voices.

- use instances of areas that you don't want to be crowded (the secluded shrine in the redwood swamps is NOT a party location for adventurers) - right, that's a server thing

- Provide a beginer zone (see above), where you dont frustrate beginners. There must not be anything that is way to dangerous for them in there - e.g., you might have the guards (NPCs) help the newbie if he gets himself to deep into troubles.

- Avoid distracting, unnecessary dead weight in the game, even someone considers it as "realistic". An example is having the hero to eat and drink by explicit commands. You dont tell him to brush teeth and tie shoelace. It's not "realistic" anyway, because someone who drinks a liter of water (ale, soup, ..) will gain about 1 kilogram of weight unless he gets rid of it later - no, noone is interested in simulating the digestion of heros in detail. The purpose of a hero is to slay monsters, save maidens and such stuff.

- But most important: Avoid all unnecessary frustration of the players (see above).

Well, really, it eventually comes down to a question: are you trying to:
(a) make a game that fits an apparently unclear genre definition?
or
(b) make a game that's fun to play?

I'm all for making games that meet a certain genre, but really, if your target platform is text-only telnet, you are limiting yourself considerably. This doesn't mean that you can't make a fun text-only game, but there's a reason why the rest of the gaming world has moved on.

Think of making music. Sure, you could work on an 8-bit synthesizer and make nice music within that niche. Or you could use more tools, bend the rules slightly and introduce some more complex samples into your otherwise 8-bit synthesizer output. Which you do depends on what you're trying to achieve, really.

There's nothing wrong with choosing a genre with clear boundaries and trying to make a good game in that genre. But it is important to remember that the boundaries are not necessarily there to optimize fun; the boundaries exist (in this case) mainly for historical reasons...

I'm not disagreeing in the least (and I know you didn't say it couldn't be great), but I have to say that there is some -awesome- 8-bit music out there. (http://www.youtube.com/watch?v=Ov52hrn9n88)


More on-topic, my opinion is that I'd rather make something fun than something that tries to strictly follow the nebulous boundaries of a genre.

I know that this subject is a couple months old, but I just ran across it and I thought that I would put my two bits (not from a horses bridle) worth into it. I skimmed and read most of what was here.

First, a mud is not an mmo. An mmo is a graphical game (intentially graphical) where as a mud is not (by limited design back in the days before graphics). If a mud were to become more graphical in nature then it would not be the, per se, mud from which it was derived. Instead, it would be a graphics mud (maybe, GxMUD?). Which would make it an advanced mud with a graphics intensive nature.

Second, in comparing an mmo to a mud is like comparing a horse drawn cart (the mud) to a model T (the mmo). You get the same results only with a fancier mode for traveling. You can either read the words (whip the straps, ie; type west, or such) or look at the pictures (press the gas pedal, ie; click a direction, or such).

Third, a mud is text and not graphic. A person is not going to play a mud if they do not, or cannot, type (very well). And, if they don't like reading they sure will not sit and want to read stuff on a screen. Muds are not for everyone, new people will not be drawn into a mud unless it offers: 1) easy ability to join (no complex and rigorous junk to choose from when first joining), 2) understandable and ease of use of equipment (basic eq to start), 3) a start area that is easy to mitigate and will not get you killed if you venture out of the noob area, and 4) a progressive learning cycle as one advances in levels to understand the gaming environment.

Fourth, instead of trying to add bling (graphics) to a mud, why not make a mud more newbie friendly? Why not have a whole area (or areas) for low levels, then have higher levels expanding outwards from there?

Fifth, is your game even friendly towards those who cannot see. (ie, An mmo: shows an angry guard heading towards your toon - are you seeing this? -- A mud tells of an angry guard heading towards your character - are you hearing this?)

Sixth, nostalgia: Who wants to play a game from the past? Who wants a game based on passed technology to reflect something from now? Can we actually get the interest up in those who play the graphics intensive games of today to play one of the simpler (but more advanced than that of yore) text based mud games that have been ongoing, or that have spawned up, of which are available now?

Just some thoughts.

I would, however, since I am here posting, like to thank Nick for his Mushclient and AreaEditor. Without these programs I would not have been able to grasp alot of what the mud community is all about. And, may not have gotten myself involved with muds at all.

These are not at all the "same results" because it's not just "fancier"; it's faster, more efficient, you can transport more, and so forth. Automotive transport revolutionized commercial activity because more goods could be moved along longer distances more quickly. Saying they are the "same" is kind of like saying that needles and looms are the "same" in that they turn thread into fabric.

Similarly the difference between a graphical game and a MUD is far more profound than merely clicking vs. typing. As you can see in the automotive case, that reductive comparison is a little too simplistic.

A very easy example is that people can read a graphical map of where things are far more quickly than a text description of the same spatial layout. In fact, so much more quickly that a text description is basically not useful for real-time applications. Can you imagine playing a MMO where spatial information actually mattered but you had to read every change of location as a line of text?

Thanks! I appreciate it.




I think here we have a matter of definition. You can certainly define a MUD game as a "text-only multi-player RPG game" in which case you are 100% correct.

Another definition might be "A multi-player RPG game which uses the latest available technology". In that case, the early MUD games certainly fit that definition, while more recently graphical MMO games can simply be said to be the same thing, with better presentation of the RPG element.

I'm not sure there is a "right" answer. David Haley and I discussed, a while back, how we might make a newer MUD game, which was in fact basically text, but had elements of things like positional combat (eg. backstabbing, ranged weapons, etc.)

The trouble is, with pure text it is hard to represent "the kobold is on your right side and moving behind you". Certainly you can write that, but with three kobolds in the room, moving in various ways, it becomes impossible to represent the positional information fast enough.

So at the very least, if you want to do something like that (and maybe you don't) then at least a simple "room map" with X's and Y's in it (or something) is required to show who is in front of what. And then if you are going to use ASCII characters to make a map you may as well use raw pixels. And then it starts becoming graphical. And maybe it stops becoming a MUD. I don't know for sure.

Here is an example. For years I have read books, where I understand a book to be words printed on paper. Now I have an iPad with iBooks application on it. I can read my old favourites (eg. the Sherlock Holmes stories) by sitting in a chair, reading my "book", flicking the pages, and generally having a similar experience to the old days. But is the iPad really a book? In one sense it is, and in another sense it isn't.

It's the closest you can get to hands-on evolution! Every iteration of a technology changes and improves things, and often even takes a step back: iPhone 4 antenna, anyone? Certainly an iPad and a paperback are different, and a modern smart phone and an old blocky mobile phone are different. But it's just a natural evolution of the practical use of these items.

Etymologists can't really just point to somewhere on the tree of life and say "This is where lungfish stopped being lungfish." Indeed, if we had found a fossil in that lineage a little earlier or a little later in the fossil record, we might have used that as our basis for what a lungfish is! (I realize my example is a bit abstracted, but I'm not an etymologist.)

At any rate, maybe it is no longer a "MUD". But honestly, that's just a name. A label. And lately I'm really beginning to dislike labels that are primarily used to define boundaries... (not limited to MUDs, I had like three discussions on it today already)

EDIT: I'm not arguing against Nick, it just happened to be a good quote to start a reply with.

As I said in an earlier post, graphics are part of the client, not the mud itself*. As most mud development is purely server side, this raises an interesting problem with your definition - if you define a mud as being non-graphical, what happens when some client developer creates a generic graphical mud client? Do all muds suddenly cease to be muds, without their owners necessarily even knowing about it? And what about people who are still using older clients - can the same game be a "mud" for some players, but not for others?

Raph Koster wrote an interesting article on the subject a few years back, entitled "Are MUDs and MMORPGs the same thing?". His opening paragraph, which mirrors my observations as well, mentioned "I've usually found that those who have worked on the implementation side of both tend to feel that they are the same thing, but that thsoe who haven't see them as somehow categorically different."

You can read the full article here: http://www.raphkoster.com/2006/03/31/are-muds-and-mmorpgs-the-same-thing/

* If you're developing a server that is specifically intended to work with a graphical client then this will of course effect your design decisions - but the graphics themselves will still be handled by the client, and it's certainly possible to have a single game that can be played as either pure text or pure graphics, depending on your choice of client.


More like comparing a horse-drawn cart without a horse to a horse-drawn cart with a horse. They're both carts (servers), but one requires you to find your own draught animal (client).

Of course if you only look at the animals, and never pay attention to the carts, you might consider them to be completely different. But if you're building the carts, you're soon going to realise that they're basically the same thing.

I think you just nailed it. That was the perfect analogy.

That was an extremely interesting article (I note that he starts of by saying "I think both are really the same thing").

He goes on to suggest that in the case of both text MUDs and graphical MMOs, that the server sends to the client some sort of representation of what the server considers to be the authoritative simulation situation. In other words, on the one hand, clients don't change the simulation. So no matter what I do in MUSHclient, I don't alter whether or not a mob is in certain room, as seen by other players. I can make the mob invisible to myself, or maybe describe it differently, but this is merely representing the core data differently at my end.

On the other hand, clients are converting some sort of token at the server end (ie. a mob number 34322 in room 68433) to be some sort of description or image a human can interpret. Done textually, you might see "a kobold is standing in the Ancient Grove". Done visually you might see a 2D or 3D representation of the same thing.

So theoretically at least, the data at the core of a graphical MMO could be converted to text (lookup a mob description, lookup a room description, and state that the mob is 30.42 feet from you at an angle of 54.34 degrees).

I put a considerable amount of work earlier this year into a proposal for caching server-to-client information. Interestingly, Raph Koster says "A client install is nothing more than an elaborate caching scheme. Tokens are used to minimize bandwidth during play, ...".

So really, my earlier proposal to cache things like mob descriptions was really just a method of making more efficient something it already does ... exchange information known to the server with the client. Interestingly, my proposal received a considerable amount of opposition, or at least, indifference.

So I suppose what you could take out of this is that, first a graphical and text MUD are attempting to achieve a similar thing: represent a fantasy virtual world shared between multiple players simultaneously. And second, by adding graphics you arguably simply do this more efficiently.

The thing that people miss when they say that text and graphics are the "same" is that while this might be true from an abstract notion of what kind of information may be encoded, it misses the point that as human beings we process certain kinds of information much more quickly than others. Furthermore, certain kinds of display logistics simply are not amenable to real-time updates (if you keep printing out the map, how does the main text get read?).

When you start talking about fancy cursor control to "draw" (umm... wait for it) on the terminal screen, you're already talking about graphics, you're just doing it over a different medium.

Anyhow, calling these things the "same" is kind of like saying that Turing Machines are the "same" as the modern well-used Turing-complete languages. Yes, the same information can be encoded. But then again, there's a people write C/Lua/Ruby/Python/etc. rather than code up a Turing state diagram.

Put another way, this is the kind of theoretical equivalence that, while interesting, is not hugely useful in practice. It's somewhat misleading to add caveats only in passing about how some decision will merely "affect design decisions" -- those effects are hardly trivial!

I wouldn't argue that text and graphics are the same. Rather, my argument is that text muds and graphical muds are fundementally the same at the server end, because the "text" and "graphics" are displayed by the client, not by the mud itself.

This distinction is important from a mud development perspective, because most muds don't have their own client - and therefore cannot directly control whether the user sees text or graphics. A graphical MMO such as WoW or EQ doesn't just provide its own graphical client, it forces you to use it. But for most muds, the output is outside of their control. Sure they can preformat it, and choose what data to send (and in what format), and even send recommended tags for things like colour and MXP links, etc. But whether the game is graphical or completely text-based isn't something the mud can directly control.

There was a discussion on TMS not long ago where one particular mud owner voiced his dislike of all graphical elements, insisting that his game would always remain pure text. So I pointed out to him some posts on this forum, where one of his players was developing plugins to draw energy bars, an avatar, a graphical map, etc.

It would certainly be possible to create a fully graphical MUSHclient plugin, offering an MMO style interface - yet still allow players to connect through simple text clients. With the recent enhancements to MUSHclient (particularly the miniwindows and protocol support) perhaps we may see some muds exploring such options over the next few years. Personally I'm pretty excited about the possibilities.

Well, yes. But I think it's a rather safe bet that you are unlikely to see a full graphics-generating text parsing engine that transforms plain text into rich 3D graphics. There have been some attempts at turning automaps into a simple 3d "labyrinth" style of view, but that's really more of a curiosity, not something that would be truly useful.

Besides, if you know that you must target plain text, certain things simply don't work. You won't pass information along several times a second telling the player where things are in the room and how they are moving; it just wouldn't work.

I agree that nothing stops players from intercepting some text elements and rendering them in some other fashion; when you add in out-of-band data this becomes all the more feasible. But I think that's already showing that the server does in fact control output, if only indirectly via what is made easy and what is made too hard. The point of protocols like 102, MSDP, ATCP1/2, etc., is to make the data readily available so that writing those plugins is relatively easy. If you had to extract it all yourself, it would be a mess. Look at the work you did KaVir, for example; would all that have been worth your trouble if you had to parse it from in-band text data? Probably not.


Definitely. :-)

Most muds are room-based, with no real concept of space, so if they were converted to a fully graphical game I doubt it would be something like Unreal or Quake - but you could create something more like The Secret of Monkey Island, for example, where each room was a scenic image of a particular location, and you could interact with it via mouse clicks.

Even in a roomless game like mine, I'd rather have an overhead or isometric display than a 3D one. Something like the old Ultima games, perhaps, or maybe even something more like Diablo.

I may have posted this before, but: http://www.godwars2.org/images/maps2.png

If the bottom maps were enlarged by perhaps 2.5 to 3 times, there would be enough space to add recognisable creature icons. However that would seriously eat into the space for the text window, plus it would be hard work coming up with all those icons. On the other hand, if the map was isometric you could get away with bigger creature icons, because overlap wouldn't be a problem. But all of these are client-side concerns - obviously the mud needs to provide the necessary data, but that's not a huge task, and (on its own) is not enough to make the mud graphical.

The mud controls what data is sent, but the client decides what to do with it. Obviously you can achieve far better results when the two are developed with each other in mind, and I find MSDP helps a lot in that respect (because the plugin/script writer can control what data they're being sent). But from a mud perspective, once I've sent that data I can no longer control what is done with it. Someone might use it to create a fully graphical interface, while another might display it as raw text - but that's up to them, it's outside of my control.

That's why I prefer not to define something as being a "mud" based on whether or not it's graphical.

This is possible in some abstract sense, but surely such a thing would not be automatically generated from a textual description.

In fact, I posit the following: a textual description of scenes from Monkey Island would contain many fewer details than the actual picture, if anything because a picture can contain small artistic details whereas a paragraph is likely to remain relatively short. Text is also likely to leave out positional information of objects in the scene, unless it is actually relevant. For instance,
"There is a table with four chairs around it."
Is the table four-sided, round? Are the chairs around it evenly, or two on one side and two on the other, etc.?

You can take liberties and just decide one way or the other, assuming that you've already solved the problem of parsing all the semantics of the textual description.

I guess I just don't really see the point of talking of converting text to graphics because, if you want graphics, you should just use graphics in the first place, not go through all these very, very difficult contortions that involve unsolved academic research problems. (!!)


I'm assuming that by 3D you mean first-person, not three-dimensional rendering (you can still have an isometric perspective over a 3D scene, and allow rotation etc.).


I think that that right there -- beyond the condition sine quae non of clients not being able to render pictures in the first place -- is why you don't see a lot of MUDs with icons and so forth.


Well, sure, it's a client-side concern. Sort of. The data the MUD sends will be different depending on whether it's going to a "dumb" client or one that knows how to render graphically. When you added your maps to your game with a MUSHclient plugin, you changed the data your server was sending. So it's not wholly client-side. I realize you say later than the MUD controls what is sent, but the point is that you will send different things depending on what you expect clients to do with it. If you only expect to deal with "dumb" terminals, you won't send anything like out-of-band data. For the data to be used in a way that's out of your control, you still need to be sending it in the first place. And interestingly enough, you weren't sending it until you had graphics in mind...


Well on that we agree. I find the distinction to be rather artificial at best. If anything, it makes sense only on the client-side, although even there I care relatively little for the label one chooses to use.

No, I envisioned someone drawing a huge number of scenes, ideally one for each room, and using the room descriptions as unique identifiers for determining which image should be drawn.

It would require a huge amount of work, and the solution would be far from optimal, but the point is that a MUSHclient plugin developer already has the ability to create a primarily graphical interface for an existing mud, without needing explicit server-side support.

I'm not proposing doing this, I mention it only as an example of why I prefer not to define something as being a "mud" based on whether or not it's graphical.

A more practical and realistic example would be a hybrid text/graphics approach, with the client displaying energy bars, avatars, buttons, icons, background graphics, etc, and using an automapper to map out where you've explored, while still maintaining a text window for the main gameplay. This is the sort of thing people already do with their clients, without explicit support from the mud.


I was thinking of first-person, or third-person with a tracking or interactive camera. I guess third-person with a fixed camera wouldn't be too bad, particularly for room-based muds, but personally I would still prefer overhead or isometric were I to do something like this for my own project. This is a personal preference however, and was mentioned as more of a musing, it's not really important.


I originally added MSDP for a console client that doesn't support graphics. While I later expanded the MSDP variables to include map data, this data was also used by the console client to draw an ASCII map.

While MSDP certainly works well for the graphical plugin, I could also have done much the same thing with in-band data, and gagged the messages.

I'm not sure what exactly you're establishing here. This seems like another one of those theoretical equivalences that has relatively little value in practice. I'm not disagreeing that it's possible, but I'm not sure why it's terribly interesting or useful to be able to do something like this.

I mean, ok, great, we can pair room names and descriptions and map them to pictures. But this is just a thought experiment. You wouldn't do it this way in practice.

After all, in principle you could also run a screen-capture program behind WoW, intercept the pixels, and generate textual descriptions of the scene as it changes. You could even intercept the data stream it sends to the client to render everything in some other way. Presto, text-mode WoW (or something). But this is kind of silly, is it not?


Yes, this is the kind of stuff we're discussing here. But it also is very far from the notion that a full graphical game can be constructed without any explicit server support.


Well, yes, but the point was that this required explicit server support and even cooperation between the server and client. You would not want to send this data in-band to clients who were not consuming or gagging it, for example.

Imagine some kind of intermediate, packaged data sent by the MUD. It's presentation-agnostic, and only denotes what's happened. Maybe it includes descriptive lines, but that's getting into details. Any client can take that data and render it however it wants, whether textually or graphically.

Yes, it is rather hard to take graphical output and transpose it into text, because you're translating something intended for presentation. MUDs tend to assume the presentation is textual, so text is sent. But under an "ideal" situation, the server just sends presentation-agnostic data, and the client renders it as it wishes.

Moving on from whether GodWars is a text MUD turned graphical, or whether we could make WoW a text-MMO, it seems to me that the general agreement here is that a better user-interface for the players is no bad thing.

I think it is possible to get bogged down in arguments about "is it a MUD?". My preliminary attempts to "pretty-up" the user interface for Aardwolf can be seen in part on this page:

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

Amongst other things, I even attempted a 3D-view! Admittedly there were problems (including my own lack of knowledge about 3D rendering) plus probably more importantly, the room-based server design did not totally lend itself to showing 3D rooms where you could walk around turn on the spot, advance half a room, and so on.

However the fact was that it was possible to make a fairly graphical front-end for a text server, conceivably without even the server operator's knowledge.

Some players may choose not to use the extra graphical functionality, and that would be their decision. Similarly, when playing WoW you can turn off the map, or not show chat windows.

I stick to my original view that, for newbie players, those who perhaps you are trying to attract, improving the user interface would help them to understand what is going on. This could be done entirely client-side, or helped along, at least, by some out-of-band information like the ATCP protocol was attempting to do. This out-of-band data is not really changing the nature of the MUD, but providing more computer-friendly information, to help the client render it (eg. room numbers).

Really, MUDs have been doing this for years. Remember the original MUDs? They had monochrome text. More recently we see ANSI colour codes (so text can be in different colours). The ANSI codes are really just out-of-band data too. You don't see "There is a ESC [ 31; monster here" but you see the colour codes (ESC [ 31;) stripped out, and replaced by red-ness in the output window.

Now people didn't say "ah by putting this out-of-band colour stuff in, we don't have text any more". So my argument is that if we add more codes again, for example to say in a big chunk of out-of-band data "this is what is in your inventory" you still haven't changed the core design, you are just making it easier for the client to show the player the same information.

Yes, sending semantic data and letting the client render it isn't a new idea (at least not on this forum). But the point is that what data you send in the first place changes depending on what is supposed to be potentially rendered.

For example, you are unlikely to send real-time positional information unless you have some expectation that the client is going to actually do something with it.

Basically, as soon as you want to send "presentation agnostic data", you cannot in fact be fully agnostic because you need to send the complete set of data needed by all rendering engines.


Well, to be honest, that wasn't really a playable version of the game, either. Also, you were aided by the server sending extra data that is not normally rendered to the text stream.


Completely agreed, and in the end of the day I think that this is what matters. I'd much rather think about how to make better games, not whether or not this or that definition conforms to a somewhat arbitrary definition that somebody else cooked up and nobody really agrees on anyhow.

Nope. Take MSDP for example - it allows the client to request the exact data it wants. If it's not interested in certain variables, it simply doesn't request them.

That's missing the point. Even if you don't actually send it down the wire, you (as a server) need to be aware and be able to send whatever data might be required by any rendering engine.

In other words, you simply cannot be truly agnostic to what is being done with the data and expect that any rendering will be possible. Rendering will only be possible at the granularity you support as a server. (This seems like it should go without saying.)

But you, as a server, have the choice to submit whatever infomation you want to submit. And a client-side renderer can take whatever data you provided and use it. The renderer is subservient to the server, not the other way around. If a renderer can't get some data, it just doesn't render it.

EDIT: What you really want to do is make it easier to provide the data in a way a renderer can make use of it. Direct text output doesn't do a good job of this, because it's effectively already rendered. You can't tell whether a given line came from one stimulus or another without relying heavily on context, and it's usually rather error-prone.

Um, yes, so the server cannot be agnostic when it comes to what clients will be able to render. If the server wants clients to be able to render thing X, the server needs to send data about thing X.

You said earlier (paraphrasing) that the server just sends stuff and clients just render whatever. Well, sure. But you just showed that that's not actually the case, because the client can only render data based on what the server chooses to send.

For example, if the server chooses to not send positional information in some format, the client will not be able to render things' positions unless it makes them up.

I'm not really sure how it's possible to disagree with the statement that clients will only be able to render data to the same granularity as the server sends (unless they just make up data). Therefore as a server author, it should go entirely without saying that if you want clients to render some particular thing, you must give them the data to render it. No?

EDIT: to reply to your edit, this is a separate issue from ease of parsing the data. If the MUD doesn't send some data, you simply don't have it, no matter how hard it might be to parse, end of story...

But my point is that the server doesn't need to care what the data will be used for. It can just send the data like it would any other data, regardless of whether it's rendered graphically or textually. That's what I mean by making the renderer subservient to the server.

At any rate, you're saying the server needs to know how the client is displaying the data (so "the data that is sent" can be changed), where I severely doubt that is true. Look at Lynx, the textual web browser. A web server sends the HTML data, which may indeed include referenced images, but Lynx only renders what it wants to render, and the web server doesn't (or shouldn't) care that the browser used is Lynx. Of course a MUD can implement a data opt-in feature, but that still doesn't require that the MUD know the nature of the client.

Your second paragraph seems to imply that I said a client can render things the server never sent. I think it's pretty reasonable to say that would be dumb.


That's quite correct, but please note that by "render" I mean "present". I can render something textually, for example. So if the server doesn't provide position data, the client can't render it in any way, shape, or form, which limits the impact of a position-based MUD.

Of course the people running the website care a great deal about what the user sees! If the output on Lynx is garbled and unusable, the website is, well, useless. So they tell people to use something other than Lynx if Lynx can't render the page correctly. (In fact, this is why many sites still tell people to use IE rather than X, Y or Z.) Presentation of interface matters immensely and frankly I find it shocking to say that it doesn't.

Note also that HTML+CSS is rather different than the arbitrary data we're talking about here, because HTML and CSS define a very clear set of what can be sent, how it can be formatted, and what rules apply. So, not only do we have the problem above, but also the analogy is not very appropriate in the first place because the nature of the data being sent is quite different.

--

All I'm saying here is that as a server developer, if you want clients to be able to render some form of data, you must provide it at the granularity to which you want it rendered. Therefore you cannot be magically agnostic to what you expect to be rendered, because the data you are able to send will be chosen based on what you want to be presentable. If you want something rendered, you must send it.

In other words, it is as simple as this: the choices the server makes in sending data will determine what can be presented in the first place.

Eaargh, that's a gross misinterpretation of what I was saying. The server sends the exact same thing to every web browser. Even though the primary target is graphical browsing, anything that can understand HTML (and "optionally" CSS and Javascript) can render the data in its own way. If Lynx is a problem because of its textual output, it's precisely a problem with Lynx, not with what the server sends!


It doesn't really matter what's being sent, as long as it's structured in such a manner that it can be presented in different ways. HTML is just a serialized DOM. It's the structure of that DOM, and the usage of the data therein, that has the restrictions. Lynx renders the DOM textually, most browsers render it graphically. The data used between both kinds of browsers remains the same. There's no reason the basic concept here can't be applied to a MUD server.


"what you expect to be rendered" - Sure. No arguments. It goes without saying that if you want the user to see something, you have to send it. It is indeed a corollary that if you don't send it, the user can't see it.


Indeed. But it needn't be treated as "This must be sent to clients that will render graphically." You just provide the data. You may have an idea for how the data will be used - if you didn't, you probably wouldn't send it - but it could be used beyond how you expected, so expectations for presentation shouldn't be inherent in the sending of the data itself.

Umm, right, and therefore the notion that the server is sending generic data suitable for rendering on any platform is somewhat utopian. Clearly, Lynx's rendering mode simply doesn't work for many sites.


No. HTML has restrictions. It's not just a generic format whose restrictions are imposed by "usage" -- HTML has standardized rules and the restrictions come from those very standards. If you leave those standards you are no longer writing HTML. You are writing something that is basically XML. HTML has extremely clear rules about what elements are acceptable and what their meanings are.


Ideas for presentation already are inherent, you just said so yourself.

I'm not saying that clients should somehow be forbidden from doing other things. What I am saying is that it is not the case that you can be completely agnostic to rendering.

Look at it from an interface perspective. If certain information is very important for your game (like, real-time information on your group members' hitpoints, or real-time updates on the position of things around you) then you will not be happy if it is rendered in a substandard fashion.

Does that mean that clients can't render it in a substandard fashion anyhow? No, of course people can do whatever they want, just like they are free, in principle, to intercept WoW messages and turn them into 8-bit color ASCII displays.

The point of this thread is not to come up with theoretical equivalences between information transmission nor is it to come up with grand schemes for ultimate semantic display of all possible data so that any potential client can render it in any number of media.

The point of the thread is to figure out what interfaces work, what methods work, and what data is needed to get those things working in a sane manner. For example, it works to have graphical displays of many status-related data (your HP, mana, stamina, group's HP, etc.). To get that working well, it is useful to use out-of-band data to support it (whether it's actually OOB-telnet or gagged is somewhat irrelevant for now). Similarly if you want positional information, you need to send that.

Talking about whether or not WoW is just "the same" as a MUD except that it intercepts data and turns it into graphics is not hugely useful, just as it would not be hugely useful to discuss MUSHclient capturing WoW output and turning it back into text.
Talking about how Lynx can implement sub-standard presentation of web page data is similarly not terribly interesting because that is exactly what we are trying to avoid: substandard information presentation! We are trying to work out how we can better present information, not how we can shoe-horn rich information into a one-stream-only textual medium.

Let's focus on the pragmatic aspects of interface design, not thought-experiments of interface equivalence.

This'll be my last post here, at least for the given sub-thread.



Bolded.


Bolded. You have the syntax of SGML and the semantics of the HTML DOM to deal with. Swap SGML out with XML and you have XHTML (which is another way to serialize a DOM), however the DOM restrictions are still the same.



Which is possible because I'm fairly sure WoW messages don't include presentational data. The client-side plugins do that. (Of course I've never dug in and used Wireshark to check the WoW message protocol, but it's not an unreasonable assumption.)



All I'm saying is that the server should not have to concern itself directly with presentation. (Presentational data can be sent separately if desired, as with HTML and CSS.) In the end, the server (but of course not the author) doesn't care what's done with the data, so long as what's needed is sent.

EDIT: I think what I'm trying to describe is a separation of concerns [1]. I don't much care if the server can send presentational data, but please, don't couple them together. I honestly like how WoW does it a lot, though if a client has no MUD-supplied plugins and neither party is interested in it, MUD-supplied positioning (sent separately!) does fine.

[1] http://en.wikipedia.org/wiki/Separation_of_concerns

If the extent of your claim is only that the server should send structured data and not presentation, then I have no argument against that and have in fact advocated that position many times myself... But that wasn't what was initially said or stated afterward, hence my objections.

Yes, that's really all I'm saying.

This is what I said when I got into the discussion:


And this was your response:



Which I disagreed with. What bothered me is that you said the data sent changes depending on what's being rendered, and that the server has to send all data required by all rendering engines. All I care about is sending the data I want to send, and perhaps separately supply presentation information if needed. I don't care which specific renderers use it.

Hopefully that clears up things!

It is a representation of a book. Both are still presented in text form and both forms still allow a choice of what you want to read, (ie, your favorites). Only the medium by which it is available to the reader has changed, but the rendering of it in text format remains the same.

When I pick up a book and read it, and I find myself an hour later having felt like I have been watching a movie, (all created within my imagination by the author), I may want to read more books by that author. But, if I find that I'm plodding along through paragraph after paragraph trying to understand what is going on in the story, I may not read any more of that author's books, (nor even finish the current one).

This is also analogous to a mud/mush/etcetera (or any other multi-user text adventure game). One who plays these games does, (I would assume), mostly for its content and how well it is presented to them, (similar to a reader and an author), along with how enjoyable the playing experience is.

Adding pictures and subnotes to a book also helps the reader to understand the story, but it may not be how the reader envisioned how something would look. Viewable maps and separate windows for stats, or such, and clickable mobs or icons may make it easier on a player to play the game, but also gives them a different perspective of it (whether for the good or not is how the player feels about it).

The comparisons, (from posts above), of lynx to ie (or such) and html to xhtml are similar to comparing telnet to mushclient. The first is limited to what it can display and the second has extended display capabilities. They rely upon what the server sends but each renders only what it is capable of.
A webmaster would need to decide how they would like their information presented and what interface it would be compatible with. Whether or not they will have their users click on links, pictures, or either (if the client cannot render pictures). And, then we are back to how to attract people to our website and retain them (as mudmasters {is that a word?} try to attract players and retain them).

From what I have observed here, if going graphics is the next step for a new concept on muds, the capability to create such a game is here. If those here put their heads together and coordinated efforts to such.
It might be something like creating a base server which could be expanded upon by each administrator and having a client that would store graphic information on the players system. Then when a player connected to any game server the server would compare tokens with the client to be sure it had downlaoded all the necessary graphics to render.
But of course this is far from the subject of attracting and retaining players for current games, but may require a new thread for a new game creation concept.

Sure..... but you've missed again all the surrounding improvements, like the fact that you can switch books without anything more than a few clicks, you can buy and obtain new books extremely quickly from online stores, you can bring a single device with you and get access to thousands and thousands of books... and so forth.

You simply can't ignore these factors when comparing two representations of the "same" thing, or two things that perform the "same" function. Being "fancier" can have dramatic effects on how useful a device is.

You know I think adding helpful informational graphics icons or miniwindows would be helpfull, especially with knew players. Just from having the following event occur yesterday.
I had a friend of mine from work connect to my mud (a modified smaug 1.4 with mostly rebuilt and modified stock areas) that I have running on my computer at home. I have a slightly modified newgate.are (some added mob progs and extra info) that one starts out in. I told him some of the basic commands and told him to read everything.
So I made a level one character to join him. One minute he was with me at the receptionist then he was gone. So I go through the area and find him standing by the serpent (dead, unlooted) and find that he hadn't equipped anything (besides a newbie set) and couldn't pick up anything else due to being overencumbered, and he hadn't gotten the sack either. So I had him eqip, gave him my sack, and had him loot the serpent and put items into the sack.
I think if he had seen familiar icons, a minimap, and maybe a helpful miniwindow (or two) he may have not just blundered blindly down the pathway to end up stuck and unable to do anything much.
It was kind of dismaying to see him do that, especially when all the info on what to do is in the descriptions. But, on the other side, it was also kind of funny to see him do that.

Yes, well we all know the phrase RTFM. But people don't. And that is why the default behaviour has to be pretty-much what you want to have happen.

I've noticed a trend recently in more graphical games for the game to auto-do things more experienced players would do anyway. For example, auto-loot. And if you get a new spell, auto-put it on your spell bar. And if you get wearable loot (eg. a chest item) and you don't currently have anything equipped at that location, auto-equip it.

None of this does any particular harm (and you can always un-equip, or drop something). And it does mean that this sort of situation is at least reduced. To be fair to new players, there is a lot happening around them, and expecting them to pick up every last detail in the first 10 minutes is a bit much.

I apologize if there's some rule against thread necromancy, but I felt that I had some things to contribute to this discussion and this topic is still incredibly relevant. I also apologize that I haven't read ALL of the posts, but I have read a LOT of the posts, so here goes my input.

Also, my post was too huge, so I blogged it and decided to share the link in that manner. I hope nobody's offended by that. I wasn't sure if Nick would want me to just put in 5 different posted chunks so i opted for this delivery mechanism.

Blog post here:
http://featurecreeping.blogspot.com/2012/02/on-player-retention.html

I hope I came across as just trying to help without coming off as preachy. In terms of player retention we all suffer against the MMO. So, let's help each other and again, I apologize for raising the dead thread.

Thanks for posting your thoughts, Gesslar! I think you laid out some great server-side design guidelines, which are all really reasonable. I think those are all factors in why I played Achaea for so many years, and it does go to show how a MUD can succeed without a lot of window dressing on the client side.

However, I think some of the greatest gains to the MUD community can be had from client-side presentational improvements, especially as it pertains to attracting new players. Achaea's Nexus client, even as simplistic as it is/was, was a huge draw for me. As you explained even in your blog post, you want to be able to see exits at a glance, without having to mentally parse the blob of text before you. The same thing applies to things like your health and mana. Nexus' client-side improvements really drove that home for me.

It takes a combination of both game design and presentation to really hit the sweet spot, so they're both crucially important. I think the tools are already there for making the game itself welcoming; the client-side tools are either lacking or not widely adopted, though, and that's really a shame.


P.S. I have no problem with thread necros if they're truly on topic. Thanks again for contributing!

That's fine. If I was worried I would make it automatically not let you.



I've relaxed the length limits for you, if you would like to repost here so we can discuss inside this thread.

The topic at hand, if you don't visit the link above, is player retention. My position is that player retention needs to be addressed from the moment a new player logs into your game and the attention paid needs to be done throughout the player's life cycle within your virtual world.



Player retention can be helped a lot by adhering to some pretty fundamental concepts of presentation, usability and support. A person should be able to enter your MUD with little to no experience with MUDs and with but minor nudging from your support staff be able to get on their way to killing/roleplaying/whatevering that your MUD offers. The decision to stay with your MUD, or even continue to try OTHER MUDs will be affected within the first few minutes of their stop at YOUR MUD. However they found your game, they did so because it piqued their interest, if they are new to MUDding, the impression you give in your MUD will either scare them off ALL games (worst case scenario), drive them to try other games (too bad for you, but still good for community), or they will love your game and stay with you for years, bringing friends with them over time.



Ok, so we can all pretend that substance is more important than looks, but quite frankly in almost any environment or situation first impressions are incredibly crucial. I can't tell you how many MUDs I've logged into where everything is all jammed up against the left, there are no lines separating content types (room name, description, people in it, items in it, exits) and it's all WHITE. Now, don't get me wrong, there's probably quite a many who don't mind that, but there's a big difference between "not minding" and "liking/loving" it. But if you have no obvious delineation between content types, a player is forced to read way more than they should have to just to figure out what they're supposed to be interacting with. Separating out content types should be fairly straightforward. A player should be able to, at a glance, identify what it is they're looking for:

-I'm moving around, all I need to know are the exits
-I'm in a room, I just want to know what players are in the room
-I'm in a room and I want to talk to someone, how can I tell which are players and which are NPCs?
-I'm adventuring in the meadows and I'm looking for a specific monster/item by quickly scanning the items in the room as I rush by.

These simple requirements are defeated in a lot of MUDs I've visited because when I type "look" in a room, it is presented as:


a dirty street in the northwest of the city of Sometown
You are standing in the street somewhere in the northwest of the city.
Sometown has gone to seed ever since the tribble invasion in the year
two fourteen. You see beggars and lowlifes supplicating the passersby
for food and coins.
A streetlamp is flickering in the night breeze.
A full moon shines down.
You can go north and south from here.
a male human with butterfly wings is standing here
a loaf of bread
a male beggar is standing here
Lord Stanley the Regent of Someregion is standing here.
a well


I didn't just pull this out of my butt, either. Certain conventions used here I've seen in several places.
Ok, the description sucks, but I tried to show that sometimes the writing isn't exactly the best, and maybe that's something we can all look to when striving to improve what we have to offer.

I could show you how this would look on Threshold, but I'm not here to say "you should all make it look like Threshold". Rather, look to how your information is presented and see if it can't be made more obvious what the information is trying to tell you based on the way in which you choose to display it.

(Ok the "is standing here" I have to address, I've seen this so many times and, well, quite frankly that stuff should go. Ok, I'm judging, I'm sorry, but honestly: "here"- we already know that, cos, we're "here" too. If "standing" is part of a stance/position system maybe offering the information in a different way like a tag after their short (standing/sitting/kneeling/etc) or possibly give that information when you look at them)

On the use of colour everybody has differing opinions. How much? How little? Here's my thought. Colour should be used for SPECIAL things (spells, command feedback, magic items). If something is plain and ordinary, just display it in a plain and ordinary manner: no colour. Everybody loves colour. It's a black and white game, colour stands out. Developers as well as players love colour. It's goodness, except when it's over used. If you type inventory and everything is coloured, how do you, as a player, easily identify magic items from non-magic items. Even most magic items in Threshold aren't coloured. Potions aren't coloured, nor are scrolls. Because we have lots of them in the game and they're pretty easy to acquire. No colour for this stuff. While colour is quite common in Threshold, it's not used to any degree that might be considered over the top, because that was a design decision made in its infancy- colour means special. And you know what? People will take a weapon that is coloured their favourite colour OVER a BETTER item that is without colour. This happens all the time. This is one method you can use to create interest in players and ways in which you can offer "specialness" to them in terms of reward. Obviously, this isn't the case for everyone (minmaxers might not care), but a good portion will care more about coloured items if they are fewer, because who doesn't love colour?

On the topic of busy-spam am I have a pretty firm opinion. On Threshold, "spam" doesn't have an automatic negative association, we use it just to mean "text the game delivers". So, as an example "I just got a spam that my helmet fell off." Every game has its own local dialect, and that's part of ours. Spammy, however, is bad. One thing you might look at when you're developing your game is to make sure that the texts that you display to your players is meaningful. What I mean by that is, the text displayed shouldn't just be looping "environmental/mood" messages. Sure, having messages displayed when a player takes an action is cool, if it relates to what's going on in their environment. But simply, sending text to a player for no other reason than just to keep reinforcing that stuff is happening gets old very fast. People are having conversations by tell and over channels or go potty and come back to pages of "Bees are buzzing around the hive." is not very meaningful. Put that the long desc or make it something they can look at or provide them a way to "listen" and provide that. Players have memory retentions and probably are already aware that bees will buzz around hives, so showing it in a description or providing that information when they -ask- for it is probably something that some might agree would be welcome. Also, things like enter/exit messages, how much of a person's name, surname, title, achievement information needs to be provided in all cases, or even through tells or movement. If you're friends with Jacob TwoTwo, Vanquisher of the Hooded Fang, you probably don't need to constantly be reminded of all of these facts every time you interact with them or they move around near you. His name is Jacob, you could probably do a lot with just his name, but still provide a method for your player to find out this information about Jacob at their own request. Also, "tell moostafa hi there" "You tell a male vampire with giant leathery wings: hi there" *twitch* If that's your thing, fine, but you probably don't need all of that, either, in your feedback to the teller.

Again, presentation. This is important to think about. How can we clean up our games to provide 1) accurate 2) succinct 3) meaningful information to players 1) automatically 2) at their request and 3) in an obvious, delineated, easily visually-parseable manner.

Strive to be as polished as you can. Be professional, look professional and people will be more encouraged to stick around.



A lot of "presentation" could easily fall under the category of "usability" but I wanted to reserve this space for how the player interacts with the game.

Consistency. Players should expect to be able to use the same commands for actions that end with the same result. I currently have a situation that I created myself where in some places you "post items" for sale in a shop and in others you "stock items". This is on MY todo list to fix. But this could also be for things like "look" and "read". If you have an item that is "readable", is there any reason why a player cannot get the same information by looking at it? Like signs. "look sign" and "read sign" could show you the same information, unless you have a specific reason why read is different. In Thresh, we allow "look" to convey what "read" might if it's generic, like signs. Boards require the "read verb", and books offer a physical description with look while reading will show you the contents. At least with books, that is a logical way, to my mind, of presenting the information. Another example is "put" and "insert". Players HATE the syntax meta-game. Trying to remember where to use what verb when they achieve the same thing could easily double-up for the same end-result should be trivial to the developer.

Think about your commands/verbs. Use consistent, logical verbs for interacting with your game that don't require too much thinking and let the players get to playing without requiring a brain augment surgery is another way in which to keep players happy and engaged in your game. 1) Don't be different just for the sake of being different, be different where it's important/logical/meaningful 2) don't force players to think how you think. Instead, try to think how THEY think when implementing new or modifying existing commands. This will make the experience seem more intuitive to your players and you have a better chance of them sticking around.




Support can be help files, chatting with developers, email support, a bug command to log bugs with your game, or it can be a specific channel where players can ask questions and get answers from their peers. Support mechanisms are important, vitally so to the newcomer experience. They should know right away how to get help and they shouldn't have to go through hoops to get it. If you have a channel for help, make sure that channel is automatically tuned in for the new player and make sure that only assistance is on that channel. Newcomers don't want to have to be autotuned to a channel that gets spammy because people are talking about the Olympics or a Batman movie or how long a pot roast should take to cook. Monitor your channels or appoint players you can trust to monitor those channels to ensure that they are used for the prescribed purposes. We have two support channels in Threshold, one specifically for newcomers which they lose after a certain level at which point they gain access to the secondary support channel that everybody has access to. Again, autotuned when they reach that level. Our newcomer channel is staffed and monitored by a specific group of people (we have it as a job, so they receive in game currency for doing this job). These people need to be friendly, helpful and knowledgeable, and you should probably staff it with people in various time zones to get good coverage throughout the hours of the day. This is how we do it, I'm not saying YOU have to do it this way, I'm just presenting one way in which to provide a more polished support mechanism.

Look at your bug reports. Address them.

Help files need to be up to date and they should be vast and cover as much information that a person who wants to learn more about your game can find. When going through a help file, look for keywords that may merit a new help file that you can reference at the bottom for further reading. Link up your docs at the bottom of each help file by pointing players to related material (similar commands, or other information on the same topic). Standardize the look of your documents so they all look the same so players can visually parse the sections of your help files for what they're looking for.

Help files are HUGELY important. There's the kind of person who will always ask, never read. There's the person who will look for docs first then ask when they can't find it or don't understand it. There's also the person who rules-lawyer you if your document is unclear or out of date. Try to avoid that last guy by making sure your documentation is well-written, says only what needs to be said, refers to relevant, further-reading material and offer your newcomer an incredible support experience by providing what they need to know by simply typing: help logicaltopic



Let the players use whatever client they want. That means, let them get all they need to if they want to just use Windows telnet. But if they want a richer experience, offer it through more advanced clients such as MUSHclient. But a player should not be hindered because they don't/can't/won't use a cool MUD client. A person may see your listing on www.topmudsites.com and still have GMud (remember GMud?) cos they found it somehow and want to connect to your game. That's cool. Don't force a certain requirement for a certain client. However, by all means, encourage them to use a better client by giving them a real reason to.




Oh gods, this really looks a huge wall of text and I apologize to all eyeballs that are bleeding over it. This is ALL personal opinion gained from working on a MUD where quality of presentation has always been the cornerstone of development. One of the most often praised aspects of our game is that it looks polished and that it's easy to read and get a feel for how things are laid out in terms of rooms, and other people and objects in the game. We like to think it's because of our sparse use of colour and the way in which the information is presented (rooms, looking at people, etc). We have numerous players in Threshold who have been there for over a decade. If you do too, that's fantastic. Even if you do, that doesn't mean there aren't aspects that can't be reviewed and revisited and improved. I constantly am looking for ways to improve the presentation of our game, and all new content is reviewed by at least two admins to make sure that it's logical, follows themes, lore and presentation standards.


[Moderator edit] Added headings.

Very interesting, thanks.



Another thing I think MUD admins could consider is that they may be getting spillover from people who have been playing popular MMORPG games, and who are wondering how to do things they are accustomed to, in your MUD.

As a quick test, I tried this on a popular MUD:



Tried another well-known MUD:



Now, OK, these MUDs may not have ranged weapons. They may not have melee weapons (although that does sound strange).

I suggest to the MUD admins that they should try to get into the minds of potential new players. Players who may be wondering if and how they get or use ranged weapons/spells. Can they get talent points? Can they craft stuff?

Even if the help file briefly pointed out that it wasn't available, and suggested an in-game alternative, that would be better than responding as if the concept doesn't even exist.

An easy way to fix this is to have your "help command" log invalid entries.

Say you have a command called dig but when you type "help digging" nothing comes up. Log that stuff to a file and periodically look through it, sort through all the typos and nonsense and find valid topics that could be addressed, even if it's to say: Sorry, we don't do that, here, but look at these other topics that are related in case you were interested.

I made a suggestion a while back about using an SQLite3 database for help files, with FTS3 support.

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

I can't find a page which demonstrates the FTS3 stuff better, but what you can do is use "snippets" which puts the searched-for word(s) into context (like Google does) to make the help more useful.

There have been many, many lengthy discussions on this subject. Character creation can be a stumbling point if it's poorly designed, but most new players tend to quit within a few minutes of entering the game itself. I posted some thoughts on the subject (and links for further reading) here: http://www.mudbytes.net/index.php?a=topic&t=3256&p=53316#p53316


As with most things, it's a matter of what you're used to. Personally I much prefer white descriptions, as it makes it easier for the coloured text to stand out. When everything is garishly coloured, I find it difficult to pick out important information at a glance.

Of course the ideal solution is to offer the players server-side customisable colours, and many muds do exactly that.


Personally I'm fine with it, it's actually the ones without any further text after their name that read poorly to me - perhaps if the objects were explicitly presented as a list it would be okay, but in your example they're just displayed after the description, and as such I feel they should be proper sentences.

Another option is to integrate everything into the main description, but in practice I find that results in a large block of text that's difficult to skim.


I heartily agree with that statement, however:


That sounds very much like you're using colour for purely cosmetic purposes. That's somewhat futile, as colours are client-specific - for example the GMud client that you mentioned doesn't support background colours, and inverts the white foreground colours. Another well-known client uses green foreground text as the default. Some clients support only 16 foreground colours, others support 256 or even 16.8 million. There are also quite a few players who customise their colours at the client end, either because they're colour blind or due to personal preferences, and they can end up seeing completely different colours to what you're sending.

I colour items to indicate their quality and rarity; rare magic items are cyan, common ones are red, epic items are bold white, etc. Yes, I got the idea from Diablo, but it works very well - the colour provides players with useful information at a glance. And while players can certainly customise their colours at the client end, they can also do it at the server end, so the colour can still provides useful information if they customise their colour scheme. And (to tie this in with the subject of usability) my item names are also clickable links, so players can pick up and use the objects with their mouse if their client supports it.



Here are my thoughts on help files: http://www.mudlab.org/forum/viewtopic.php?p=3580

In brief, some techniques I've found useful are:

* Keep them accurate and up to date.
* Work with the players to rephrase any help files they find vague or ambiguous.
* Provide a clean presentation with a consistent style and format.
* Offer clickable links so that players can browse help files with their mouse.
* Provide dynamic help files that are tailored to the individual viewer.
* Use a soundex parser to recommend similar help files if one isn't found.
* Provide a search facility to locate specific information.
* Offer access to the same help files on the website.
* Provide a wiki for detailed information that would clutter in-game help files.

I wanted to add my thought, possibly from a different viewpoint and important factor.

One thing about player-retention in games today is not all on the games, of course. Fads come and go in the game industry. Within those fads, things could be easy or hard. It's not a straight line to always becoming easier. It's more like a roller-coaster. Some years they'll be hard games and that's what the fad will include, others it will be for ease. So I definitely would take this into consideration when thinking about creating better player retention. One year a player will not want to read anything and things will be difficult for a number of social and skill-based reasons(and more), the next year, he won't stay(lowering player retention) because things are to easy or quick.

A significant amount of unique, individual game-design plays a small, but significant factor. Runes of Magic's tutorial and newbie areas are, in my opinion, ridiculously easy to the point many see it and roll their eyes, before skipping it. Then they approach the game an entirely different way and have problems and successes through that new avenue within the game-design.

I believe there are some vague, easily identifiable shortcuts to streamlining any tutorial or newbie area that universally applies to many games, both MUDs, MMOs and other genres.

To a degree, if a text-based game is a text-based game, that's what it is. MMOs try to appeal to a vastly wide demographic resulting in MMOs like World of Warcraft.

I think there's room for that in the MUD world. I consider Aardwolf to be the "WoW of the MUD world", while Achaea would be much more daunting for many of those players.

For that reason, it's important to me in designing a new area to really hash out what may be universal, without hurting my game in any way. I have a specific plan for it and a range of audience-demographics. If some don't like it, I don't care. I'm not taking a modern-day MMO approach, in that regard. I'm staking a claim on a genre and sticking to it. I'm not creating Mario's Jumping Adventure and then trying to appeal to an audience that also hates jumping.

Basically, I separate:
*general design choices
*game specific design choices

Overlap does occur and many other factors could come into play, but to me you have to start looking at specifics from game to game to start cyphering better design choices.

For instance: and I am only speculating, with no knowledge, that Today's MMOs are waning. I think all these design choices, making auto-loot, auto-follow, making things "easier" are products of changing the heart of the game to the point that features originally fun and exciting that added value, became less and eventually became a nuisance as only a few main features got all the attention.

I would cite Achaea as a great example of introducing new players into the game, for what the game is, how it's designed uniquely and who its intended audiences are.

It reminds me of a Final Fantasy 10 approach, where FFX never really had a start/stop for a tutorial. I remember it being seamless and invisible in the game and even would pop-up help as far as 60+ hours into the game and being in the last area.

Some universal ideas have really already been said in this thread, but I'd reiterate and agree:
*Break the newbie tutorial up into, smaller bite-sized pieces. At each resting, have the option to quickly enter the game, but with the ability to just grab those help files.

I'd start introducing things like a topic speech. In those speeches, people generally make their outline, but for each major topic they categorize and design what they say and when around the idea of an upside-down triangle split into horizontal levels. The top level is broad, the bottom is narrow to a point.

This can be planned out with as many triangles as needed and placed side by side if needed.

When you talk about inventory. Start broad, then break it down into a few "levels", each one being more detailed. then have a resting spot before moving on. Many MUDs already do something very similar, so it really wouldn't take a complete redesign; just tweaking.

Anyway that's my terribly long and boring contribution. :)

I can't say much since I don't know Aardwolf nor the current Achaea, but back when I played IRE muds some years back they were all being made simpler, simpler and simpler for new players. If that trend has continued, they're basically the graphical MMO version of a text game; easy to get started with, and arguably neutered where things used to be challenging long-time players. They might both be at the 'appeal to as many as possible' WoW stage already.

My view on making a game easier isn't set in stone. I'm not a great psychologist or philosopher of humans. Just a joe with a big opinion. :D

There's two avenues with making games "easier" that I see, right away(I'm sure there's more).

*1.Streamlining good game design
*2.Lowering difficulty of gameplay

1. I look at streamlining as something that isn't exclusive to a certain type of player, but(for the most part) all-encompassing for every player.

Newer MMOs aren't just getting "easier" as they are also changing in gameplay and design. I.E. the debate over fast-travel options. Newer MMOs aren't really about a living world to live in, as much as they are levels, like a Mega-Man game nowadays, so I see it as pragmatic that developers are adding fast-travel to quickly get in and out of dungeons, because the real gameplay is becoming quite narrowly focused on dungeons in graphical MMOs. That's good game design in my book, not making the game "easier"

2. As gameplay "is" part of game-desing, it can be hard to always separate, but an example would be handing out more/better armor that allows a player to kill a boss faster or with less worry of dying. This can be tricky, because I think depending on puzzle-based, strategy or skill elements, the gameplay can still be quite fun, thus lowering what initially would look like my idea of making a game easier and placing it more into my first category.

Nothing's ever written in stone.

Take two different ancillary features that might fall into both categories and maybe even both but with more weight in one category than the other: Say, bag space, auto-loot and crafting.

In RIFT, a big graphical MMO, you can not only auto-loot but auto-loot multiple bodies that are near each other. I don't see this as making the game easier, because I see RIFT's game-design as being in-line with a lot of today's newer MMOs(less world-living, more videogame, level-bashing). So in this example, I feel auto-loot is a good design element that adds to the overall gameplay in RIFT. Would that work in Vanguard? Probably not, or not nearly as well, because Vanguard is more about living in a world and that could detract from the specific gameplay experience(s) that Vanguard provides.

I would not have auto-loot in my game of anykind because I want it to be heavy RP and auto-loot goes against that. It doesn't mix, in my book. It's like oil and vinegar. I want to live the character and that means when I perform actions like picking objects up, searching bodies manually or picking my nose, that enhances gameplay. It increases enjoyment of the game for me.

Let's look at an aspect of MUDs: Speedwalks. I like them. To me it's good game design. The way I was inducted into a MUD and because of the basic ways they work, You, 1, get a bit of help from having to do memory recall of all the direction to get from one place to another, and, 2, it doesn't make detract from gameplay at all. It's optional. If I have a quest and can quickly get to the main area the quest is located, I'll speedwalk. If there's an idea that I would be missing something, it's my choice, and I'm the one losing out by not taking the leisurely stroll.

By the way. I'm a slow-travel kind of guy. If I designed a graphical-MMO, I'd make the world much like Vanguard without any fast-travel of any kind, because living in that world, realistically improves my enjoyment of it.

In a MUD, I don't think that same game-design translates. One could say that, but another could easily say, "Pretend you're running or riding a mount" and I could easily buy that.

My ideas on game-desing have many flaws and even though I nitpick them, I tend to be in the same camp as those that think MMOs are getting easier. I do agree with that, I just think we need to be more discerning of exactly how they are becoming easier.

Some nice ideas there. One of the problems of making things easier is you remove the sense of achievement of doing the harder thing.

For example, originally in WoW you had to "discover" a flight point (waypoint) before using it. So upon making a new character you had a sense of achievement when you went to the trouble of running (possibly through quite hostile terrain) to activate it.

Now, a lot of waypoints are pre-activated. Sure, that makes it faster, and easier. And in some ways, more sense. For example, I don't have to swim to London before I can fly there. But the sense of achievement is lessened.

Lowering the entry barrier for newbies strikes me as a Good Thing. It certainly doesn't mean you can't increase the challenge later on, although I think the transition should be smooth (i.e., don't just suddenly switch off a hand-holding tutorial and dump the player into the middle of the city, with no suggestions for what to do next).

I agree with making it simpler for newbies. So the starter area (preferably not a city IMHO, but a town, or outpost) is easy to get around, and find stuff.

But later on, finding a city should be an accomplishment. And finding a second city (say) should be something you are proud you achieved. Not just "click on the portal to reach City B".

When do we shove newbies out of the nest? If we can suspend certain features or consequences for newbies within their own little area and then engage them with progressively more difficult quests in the city once they graduate, when and how do we cut the cord?

To use my own example, I have a short introductory area (think the 'temple of trials' from Interplay's Fallout II) which leads to some quests in a major city. The quests are not only progressively more difficult, but they are a good way to learn the lay of the land. After that, a nearby NPC will offer to take a player to a nearby dungeon (inside the city) for training. What else do you recommend?

I am of the opinion that they should find other players and try to interact at that point, therefore I don't want them to be able to just continue to thrive on NPC guidance.

(Alternatively: at what point do we sacrifice the integrity of the game in an effort to satisfy the lowest common denominator?)

Personally I don't think we should. We're not teaching people to fly, after all - we're providing them with entertainment. If they want to "stay in the nest", does it really matter, as long as they're having fun?

It brings to mind a post I read a couple of years ago, where the reviewer described his experience of leaving mud school: http://www.mudbytes.net/topic-2542

"Now I am put in the game. There are some people standing around. Some use orbs to jump in and out of the room. What is this fantastical orb jumping that seems out of sorts? It makes me picture Aladdin wandering in, dressed in his open chest vest and pantaloons. I have no idea what to do from here. Interest lost, it was great up until this point, but there is no obvious direction to continue. And since my primary interest is learning from the experience, and I have, I have no inclination to fight my way through cluelessness to some understanding.

It does make me wonder if you can make the whole game a tutorial. Perhaps have a tutorial mode. I wouldn't want to dump players out of an experience that is guided, to one that is completely freeform."

This mirrors my own view, and I've actually experimented with an optional tutorial mode (inspired by the above comment). Feedback has been very positive. It's generally not much fun to sit around with no clue what to do next.

I believe it does matter if it means that other people are not having the fun that they could be having as a result. We all market our respective games to appeal to a certain demographic; if yours is looking for a semi-realistic, RP intensive experience then you need to provide that.

I believe that a progressive tutorial for new players is not necessarily mutually exclusive, but it cannot last forever. It has to exist long enough to allow the average new player to get the hang of the game's operations, and then offer tools for the slower ones to get help later on. Are you saying that your tutorial mode could last indefinitely though? What does it entail?

While I can't say I totally feel the same, I have to agree a bit with Kavir.

Maybe there's a middle road?

One thing, I think that becomes common, is that discovery or exploration(learning, basically) quickly becomes half the fun.

Finding that may be so subtle that it may make the differences between MUDs great enough to need a personal touch.

I like Aardwolf's MUD school. It's really great, especially for those totally new to MUDs.

But I think Achaea is that way as well, but it definitely leans more on sweeping you into the regular world.

I prefer sweeps, personally, and trying to lower the distinction between what is "newbie land" and what is "the real world". I'd like it all to be.

I'm a big fan prosumerism in games. That is; a circular nature of players consuming and creating.

Ideally, I'd like to have different experiences for each race for a player starting out, a place to return to and a means to facilitate newbies and high-levels mixing.

It seems as if we are all saying mostly the same thing: I do not disagree that we should ease newbies into the game, but I am just looking for some opinions on how best to do that.

Right now, Forgotten Kingdoms progresses this way for a new player: character creation, optional skill tutorial (semi-OOC), mandatory training temple (IC with notes and optional explanations of game topics), and then progressive, local quests that should familiarize a new player with the major city in game. From there they have some nearby hooks for the major low-level training areas in the city.

A new player has an in-game help system and an ASK channel for OOC help at any time.

What do y'all think? Too much, too little?

I was thinking it'd be nice to have direct help go from GM's to help-files.

This transition seems to be jarring, and can also result in communication errors and ill-feelings.

Many answer questions tersely with "Help <file>", or chastise.

I like the idea of libraries in MUDs, with mentions of where to start reading.

Some NPCs around that inform about how to not only go about doing basic things, but telling players how to go about learning more on their own.

This conversation has indeed taken a terrific turn. I love discussions like this.

I don't see how dumping frustrated, clueless newbies into the main game to fend for themselves would improve the fun of other players (except perhaps as PK fodder). But even if it did, the solution would ultimately be self-defeating, particularly in the context of this thread; if the newbies are no longer having fun, they'll just log off.


You type 'what', and it gives you some suggestions on what to do next. Like this: http://www.godwars2.org/images/plugin_v114_8.png

And yes, it lasts indefinitely, although it gradually evolves from explicit instructions leading you step-by-step through the early game to general hints and suggestions in the later game.

That's an interesting feature. We use something similar with our 'help' command, but it is less intuitive. We augment that by having an 'ask' command that poses a question to members of the player council (helpful veteran player volunteers) or staff who are on-line.

Your 'what' command is based on a few anticipated questions or does it intuit from elements of the question?

The autohelp feature responds to sequences of keywords people ask on the newbie channel and selects an appropriate response if possible.

The 'what' command is more like a dynamic help file, the contents of which is customised based on your current progress, achievements and abilities.

That autohelp feature is awesome!

One thing I developed a while ago, purely client-side was this:



You can expand or collapse the categories.

The idea is that since MUDs tend to be wordy things, it shows common words you might need to type, and explain what they do. The green ones are hyperlinks so all you have to do is click on them. The orange words bring up help on that topic if you click on them.

If you haven't played a particular MUD it can be confusing to know whether you "equip" or "wear" an item. This is supposed to help clear that confusion up.

Being client-side (of course it requires MUSHclient, however that is a free download) you don't need to make any changes to the MUD to implement it.

The plugin itself is largely table-driven, so you simply edit it and alter the tables of words, and descriptions, to suit.


More detail here: