Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUDs
MUD Design Concepts
Suggestions for improving MUD game retention rates

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	Suggestions for improving MUD game retention rates
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Gesslar] 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. [b]INTRO[/b] 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. [b]PRESENTATION[/b] 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: [mono] 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 [/mono] 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. [b]USABILITY[/b] 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. [b]SUPPORT[/b] 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 [b]CLIENTS[/b] 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. [b]ADDENDUM[/b] 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. Added headings. [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3 4 5 6 7

Posted by

Nick Gammon Australia (18,800 posts)

bio Forum Administrator

Date

Tue 30 Oct 2012 08:39 PM (UTC) [ quote ]

Amended on Wed 31 Oct 2012 12:20 AM (UTC) by Nick Gammon

Message

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

You can expand or collapse the categories.

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

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

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

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

More detail here:

Please see the forum thread: http://gammon.com.au/forum/?id=9664.

- Nick Gammon

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