Register forum user name Search FAQ

Gammon Forum

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

Suggestions for improving MUD game retention rates

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


Pages: 1 2  3  4  5  6  7  

Posted by Nick Gammon   Australia  (23,102 posts)  Bio   Forum Administrator
Date Mon 15 Mar 2010 08:32 AM (UTC)

Amended on Tue 26 Nov 2013 03:28 AM (UTC) by Nick Gammon

Message
How can we keep our players?


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):


Ominous Tapestries
You appear somehow within an arcane chamber.  Huge hanging tapestries,
each intricately detailed in vibrant colors, cover the featureless walls
of your octagonal surroundings.  Wide square bands of white marble serve
to blur the sharp edges of the walls, giving the room an almost circular
appearance.  Gazing about your surroundings, your eye is drawn upward by
a much larger round tapestry hanging directly overhead, and you struggle
with your balance as you examine the fabric's images.  The growing sense
of wonder which pulls at you is tinged with a dose of trepidation.  The
views about you, while wondrous, are nevertheless quite ominous; these
images are of a truly darkened land.
Exits: down.
A spiral staircase leads down from center of the room.
You do not have that item.
A burlap sack is delivered into your hands, type LOOK SACK to use.
Familiar, yet somehow different, your being has changed...

<Type HELP START>
help start
If you are new to the Realms, here are a few help files that will help you
get acquainted with our world. Please remember that during peak times
we host upwards of 300 players online, so we have tried to make the help
system as detailed as possible for everyone's benefit:
 
GUIDE -       Will help you learn to use your Adventurers Guide Book.
RULES -       Will lead you through the laws of the land.
SPAM -        Will explain what spam is, and why you should not do it.
CONFIG -      Will teach you about our configuration menu.
SCORE -       Will tell you about your character's personal score sheet.
MOVEMENT -    Will teach you various commands for moving about the Realms.
OBJECTS -     Will teach you various commands to use your equipment.
CONTAINER -   Will teach you about using containers to hold belongings.
CHANNELS -    Will teach you about communication with other players.
GROUP -       Will help you with grouping with other adventurers.
COMBAT -      Will teach you how to choose, start and stop a fight.
DEATH -       Will tell you about the death experience in the Realms.
PRACTICE -    Will teach you about training spells, skills, and weapons.
INFORMATION - Will cover ways to find certain types of information.
 
To use these files, type HELP <topic>.  Type 'help' for general commands.

<26hp 94m 100mv> 
l
Ominous Tapestries
You appear somehow within an arcane chamber.  Huge hanging tapestries,
each intricately detailed in vibrant colors, cover the featureless walls
of your octagonal surroundings.  Wide square bands of white marble serve
to blur the sharp edges of the walls, giving the room an almost circular
appearance.  Gazing about your surroundings, your eye is drawn upward by
a much larger round tapestry hanging directly overhead, and you struggle
with your balance as you examine the fabric's images.  The growing sense
of wonder which pulls at you is tinged with a dose of trepidation.  The
views about you, while wondrous, are nevertheless quite ominous; these
images are of a truly darkened land.
Exits: down.
A spiral staircase leads down from center of the room.

<26hp 94m 100mv> 
down
Ok.
An Unsettling Reception
Muted sounds and the scent of cedar assail your senses as you enter this
stately chamber.  Thick carpeting competes with leathered chairs in a bid
for your comfort, and a huge painting of a barren desert occupies the wall
behind a large desk of oak.  Four small luminescent globes float aimlessly
about the room, and you notice that though seemingly free floating these
globes always manage to remain equidistant from one another.  The huge
bust of a fantastical lizard has been set upon the wall, an amazing
hunting trophy of some sort.
Exits: north up.
The Realms of Despair hostess is here to greet you.
Samylla is shrouded in flowing shadow and light.
Samylla smiles at you.
Samylla says 'Welcome to the Realms of Despair reception chamber, Nick.'
Samylla says 'You have yet to enter the actual game, but will soon...'
Please take the time to read everything you see along the way.
- use Newbiechat to speak to the Immortals for assistance:
- type "new <message>" to use the channel.
Please, look around -- just type 'look <object>'.  (look bust)

<26hp 94m 99mv> 
l bust
Your mind clicks!  You know what this is, though your mind takes a moment
to digest the information.  You are staring at a bust of a dragon, closer
to such a thing than you have ever been before.  Its eyes seem to glare
menacingly at you, but a shiver courses the length of your spine as a
sigh of relief passes your lips.  It is thankfully dead, and you are safe.

<26hp 94m 99mv> 
n
Ok.
The Path of Knowledge
You travel upon an open pathway beyond the confines of the reception area
to the south, heading toward your future.  After a time, you see a stocky
man leaning casually against a large tree to the side of road.  Your path
leads on to the north, or you can return to the structure to the south.
Exits: north south somewhere.
Towering beside the pathway is an enormous tree, a large opening at its base.
The statistics teacher sits here, guiding you towards your future.
Xouwasi is shrouded in flowing shadow and light.
Xouwasi bows before you.
Xouwasi says 'You appear to be a visitor, Nick.'
- Type "look <item>" or "look <name>" to see things here.
- Type 'eq' to check your equipment (items you are wearing).
... to see your unused belongings, type 'inventory' or 'i'
... to display your statistics sheet, type 'score' or 'ol'
Xouwasi says 'Type 'look tree'...'

<26hp 94m 98mv> 
l tree
This tree is huge! On the southern face you see a large opening, it
appears big enough for you to enter. You wonder what is inside.
HINT: Type OPENING or LEAVE OPENING to enter and leave the tree.

<26hp 94m 98mv> 
opening
Inside the Tree
This is a small house, sparsely decorated.  It looks as if the dwarf who
resides here prefers to spend all his time outside rather then indoors.
The table is covered with a few dishes and the bed is unmade, though the
rest of the place is relatively clean.  Against the north wall you see a
large chest.  Upon closer inspection you see the chest is open, and you
wonder what it might contain.  The opening is back to the south.
Exits: somewhere.
An opening in the tree, leading back to the path.
A weapons chest rests against the northern wall.

<26hp 94m 99mv> 
l chest
This chest is made from a thick carved oak, it is sturdy but not locked.
You feel you must examine it closer to see what it might contain.
You get a heavy, iron-forged broadsword from a weapon's chest
You wield a heavy, iron-forged broadsword.

<26hp 94m 99mv> 
examine chest
This chest is made from a thick carved oak, it is sturdy but not locked.
You feel you must examine it closer to see what it might contain.
When you look inside, you see:
A weapon's chest contains:
     A finely honed weapon lies here, waiting to be carried into battle.
You get a heavy, iron-forged broadsword from a weapon's chest
You stop using a heavy, iron-forged broadsword.
You wield a heavy, iron-forged broadsword.

<26hp 94m 99mv> <26hp 94m 99mv> 



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:

Icons and views



  • 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


Starting location


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.

Get rid of annoying things


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.

Summary


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.

- Nick Gammon

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

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #1 on Mon 15 Mar 2010 08:59 AM (UTC)
Message
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.

'Soludra' on Achaea

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

Posted by KaVir   Germany  (117 posts)  Bio
Date Reply #2 on Wed 17 Mar 2010 10:50 AM (UTC)
Message
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.
Top

Posted by Dralnu   USA  (277 posts)  Bio
Date Reply #3 on Tue 25 May 2010 06:16 AM (UTC)

Amended on Tue 25 May 2010 07:02 AM (UTC) by Dralnu

Message
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).
Top

Posted by KaVir   Germany  (117 posts)  Bio
Date Reply #4 on Tue 25 May 2010 09:56 AM (UTC)

Amended on Tue 25 May 2010 10:05 AM (UTC) by KaVir

Message
Dralnu said:
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.


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

Posted by Dralnu   USA  (277 posts)  Bio
Date Reply #5 on Tue 25 May 2010 04:11 PM (UTC)
Message
KaVir said:
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.


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.

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


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

Posted by Nick Gammon   Australia  (23,102 posts)  Bio   Forum Administrator
Date Reply #6 on Tue 25 May 2010 10:04 PM (UTC)
Message

Your image:


- Nick Gammon

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

Posted by Nick Gammon   Australia  (23,102 posts)  Bio   Forum Administrator
Date Reply #7 on Tue 25 May 2010 10:17 PM (UTC)

Amended on Tue 07 Apr 2015 01:32 AM (UTC) by Nick Gammon

Message
Dralnu said:

I have to ask; what clients should we support if we shouldn't try to support them all?


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.


type="chat",from="Nick",message="hi there everyone"


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 Gammon

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

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #8 on Tue 25 May 2010 10:42 PM (UTC)
Message
Nick.karma += 10;

I completely agree with everything you just said.

'Soludra' on Achaea

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

Posted by Dralnu   USA  (277 posts)  Bio
Date Reply #9 on Wed 26 May 2010 12:59 AM (UTC)
Message
Nick Gammon said:
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.


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.

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


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.

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


type="chat",from="Nick",message="hi there everyone"


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.


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

Posted by Nick Gammon   Australia  (23,102 posts)  Bio   Forum Administrator
Date Reply #10 on Wed 26 May 2010 03:01 AM (UTC)

Amended on Tue 07 Apr 2015 01:33 AM (UTC) by Nick Gammon

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


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

Dralnu said:

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.


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.

Dralnu said:

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.


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

Dralnu said:

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.


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.

Dralnu said:

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.


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.

- Nick Gammon

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

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #11 on Wed 26 May 2010 03:14 AM (UTC)

Amended on Wed 26 May 2010 03:15 AM (UTC) by Twisol

Message
Nick Gammon said:
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).


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

Nick Gammon said:
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".


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.

'Soludra' on Achaea

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

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #12 on Wed 26 May 2010 04:38 AM (UTC)
Message
I'll reply more later, but I just wanted to comment on this:

Quote:
At this point I will argue if you are even still developing a MUD at all.

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

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Nick Gammon   Australia  (23,102 posts)  Bio   Forum Administrator
Date Reply #13 on Wed 26 May 2010 05:07 AM (UTC)

Amended on Wed 26 May 2010 05:08 AM (UTC) by Nick Gammon

Message
Dralnu said:

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.



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?

- Nick Gammon

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

Posted by Dralnu   USA  (277 posts)  Bio
Date Reply #14 on Thu 27 May 2010 02:26 AM (UTC)

Amended on Tue 07 Apr 2015 01:34 AM (UTC) by Nick Gammon

Message
Nick Gammon said:
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).


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

Quote:
Dralnu said:

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.


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.


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

Quote:
Dralnu said:

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.


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.


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

Quote:
Dralnu said:

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.


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.
<snipped due to length>


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

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

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


298,650 views.

This is page 1, subject is 7 pages long: 1 2  3  4  5  6  7  [Next page]

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

Go to topic:           Search the forum


[Go to top] top

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