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, 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 Twisol   USA  (2,257 posts)  Bio
Date Reply #60 on Sat 24 Jul 2010 02:23 AM (UTC)

Amended on Sat 24 Jul 2010 02:28 AM (UTC) by Twisol

Message

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


David Haley said:
Quote:
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!

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.

Bolded.

David Haley said:
Quote:
HTML is just a serialized DOM. It's the structure of that DOM, and the usage of the data therein, that has the restrictions.

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.

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.


David Haley said:
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.

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

David Haley said:
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.


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

'Soludra' on Achaea

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

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #61 on Sat 24 Jul 2010 02:54 AM (UTC)
Message
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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

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

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #62 on Sat 24 Jul 2010 03:06 AM (UTC)

Amended on Sat 24 Jul 2010 03:08 AM (UTC) by Twisol

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

This is what I said when I got into the discussion:
Twisol said:
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.


And this was your response:

David Haley said:
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.


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!

'Soludra' on Achaea

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

Posted by Cyberthrope   USA  (17 posts)  Bio
Date Reply #63 on Sat 24 Jul 2010 11:20 AM (UTC)
Message
Nick Gammon said:

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

You mud, I mud, we all mud together.
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #64 on Mon 26 Jul 2010 05:39 AM (UTC)
Message
Quote:
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.

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

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

Posted by Cyberthrope   USA  (17 posts)  Bio
Date Reply #65 on Mon 26 Jul 2010 11:40 AM (UTC)
Message
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.

You mud, I mud, we all mud together.
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #66 on Mon 26 Jul 2010 08:20 PM (UTC)
Message
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.

- Nick Gammon

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

Posted by Gesslar   (24 posts)  Bio
Date Reply #67 on Tue 14 Feb 2012 06:33 AM (UTC)
Message
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.
Top

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #68 on Tue 14 Feb 2012 06:51 AM (UTC)
Message
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!

'Soludra' on Achaea

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

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #69 on Tue 14 Feb 2012 09:34 AM (UTC)
Message
Gesslar said:

I apologize if there's some rule against thread necromancy ...


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

Gesslar said:

Also, my post was too huge, so I blogged it and decided to share the link in that manner.


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

- Nick Gammon

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

Posted by Gesslar   (24 posts)  Bio
Date Reply #70 on Tue 14 Feb 2012 11:29 AM (UTC)

Amended on Wed 15 Feb 2012 04:25 AM (UTC) by Nick Gammon

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

INTRO


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.

PRESENTATION


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.

USABILITY


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


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

CLIENTS


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.


ADDENDUM


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

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #71 on Wed 15 Feb 2012 04:38 AM (UTC)

Amended on Wed 15 Feb 2012 04:40 AM (UTC) by Nick Gammon

Message
Very interesting, thanks.

Gesslar said:

Help files are HUGELY important.


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:


help ranged
There is no help with that keyword.

help melee
There is no help with that keyword.

help talents
There is no help with that keyword.

help crafting
There is no help with that keyword.


Tried another well-known MUD:


help melee
No match found for "melee", trying a search...
Search results for "melee":
   No matches found.

help ranged
No match found for "ranged", trying a search...
(some search results then displayed about using RANGED weapons)

help talents
No match found for "talents", trying a search...

help crafting
(got some results)


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.

- Nick Gammon

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

Posted by Gesslar   (24 posts)  Bio
Date Reply #72 on Wed 15 Feb 2012 04:43 AM (UTC)
Message
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.
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #73 on Wed 15 Feb 2012 05:13 AM (UTC)
Message
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.

- Nick Gammon

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

Posted by KaVir   Germany  (117 posts)  Bio
Date Reply #74 on Wed 15 Feb 2012 09:41 AM (UTC)

Amended on Thu 16 Feb 2012 08:10 AM (UTC) by KaVir

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

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

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

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.

Gesslar said:
Ok the "is standing here" I have to address, I've seen this so many times and, well, quite frankly that stuff should go.

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.

Gesslar said:
Colour should be used for SPECIAL things (spells, command feedback, magic items)

I heartily agree with that statement, however:

Gesslar said:
People will take a weapon that is coloured their favourite colour OVER a BETTER item that is without colour.

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


295,639 views.

This is page 5, subject is 7 pages long:  [Previous page]  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.