[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUDs
. -> [Folder]  MUD Design Concepts
. . -> [Subject]  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] Refresh page


Pages: 1  2  3 4  5  6  7  

Posted by Bernhard   (18 posts)  [Biography] bio
Date Reply #30 on Tue 08 Jun 2010 05:41 PM (UTC)
Message
So your key features for a MUD are:
- it is a game (played for fun)
- multiple user play in a network and may interact with each other
- the users play it is a virtual world with one (or more) avatars

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

Everything else could be changed, right?
[Go to top] top

Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #31 on Tue 08 Jun 2010 10:00 PM (UTC)

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

Message
Bernhard said:

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


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

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

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

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

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

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

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


open crate184706
buy sword46322
wield helmet4324

or:

get 3.sword from 4.bag
loot 2.corpse


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

With messages you can implement stuff like this:




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



- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Bernhard   (18 posts)  [Biography] bio
Date Reply #32 on Sat 12 Jun 2010 08:33 PM (UTC)
Message

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


My suggestions if you do not want to draw areas:

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

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

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

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

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

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

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

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

- But most important: Avoid all unnecessary frustration of the players (see above).
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #33 on Mon 14 Jun 2010 04:46 AM (UTC)
Message
Quote:
So it seems to be controversial whether or not any innovation is allowed, that adds anything that is not accessible using a text only (standard telnet) client. In case one answers the fundermental question with yes (it as allowed), it's still the question how far to go. I mean there are even "graphical games" that present most of their contents as text (anyone played Planescape Torment? The areas/rooms are drawn, but you spend most of the time talking and, thus, reading text). So something as "Wyvern" (a 2D graphical MUD) could already be too far.

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

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

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

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

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #34 on Mon 14 Jun 2010 04:58 AM (UTC)
Message
David Haley said:
Think of making music. Sure, you could work on an 8-bit synthesizer and make nice music within that niche. Or you could use more tools, bend the rules slightly and introduce some more complex samples into your otherwise 8-bit synthesizer output. Which you do depends on what you're trying to achieve, really.


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


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

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Cyberthrope   USA  (17 posts)  [Biography] bio
Date Reply #35 on Thu 22 Jul 2010 09:19 AM (UTC)
Message
I know that this subject is a couple months old, but I just ran across it and I thought that I would put my two bits (not from a horses bridle) worth into it. I skimmed and read most of what was here.

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

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

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

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

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

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

Just some thoughts.

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

You mud, I mud, we all mud together.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #36 on Thu 22 Jul 2010 04:03 PM (UTC)
Message
Quote:
Second, in comparing an mmo to a mud is like comparing a horse drawn cart (the mud) to a model T (the mmo). You get the same results only with a fancier mode for traveling. You can either read the words (whip the straps, ie; type west, or such) or look at the pictures (press the gas pedal, ie; click a direction, or such).

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

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

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

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #37 on Thu 22 Jul 2010 09:21 PM (UTC)
Message
Cyberthrope said:

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


Thanks! I appreciate it.


Cyberthrope said:

... a mud is text and not graphic.


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

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

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

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

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

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #38 on Thu 22 Jul 2010 11:36 PM (UTC)

Amended on Thu 22 Jul 2010 11:37 PM (UTC) by Twisol

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

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

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

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

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by KaVir   Germany  (117 posts)  [Biography] bio
Date Reply #39 on Thu 22 Jul 2010 11:49 PM (UTC)
Message
Cyberthrope said:
First, a mud is not an mmo. An mmo is a graphical game (intentially graphical) where as a mud is not (by limited design back in the days before graphics). If a mud were to become more graphical in nature then it would not be the, per se, mud from which it was derived. Instead, it would be a graphics mud (maybe, GxMUD?). Which would make it an advanced mud with a graphics intensive nature.

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

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

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

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

Cyberthrope said:
Second, in comparing an mmo to a mud is like comparing a horse drawn cart (the mud) to a model T (the mmo).

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

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

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #40 on Fri 23 Jul 2010 01:07 AM (UTC)
Message
KaVir said:
More like comparing a horse-drawn cart without a horse to a horse-drawn cart with a horse. They're both carts (servers), but one requires you to find your own draught animal (client).

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


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

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #41 on Fri 23 Jul 2010 01:51 AM (UTC)

Amended on Fri 23 Jul 2010 01:52 AM (UTC) by Nick Gammon

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

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

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

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

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

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

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #42 on Fri 23 Jul 2010 03:53 AM (UTC)
Message
The thing that people miss when they say that text and graphics are the "same" is that while this might be true from an abstract notion of what kind of information may be encoded, it misses the point that as human beings we process certain kinds of information much more quickly than others. Furthermore, certain kinds of display logistics simply are not amenable to real-time updates (if you keep printing out the map, how does the main text get read?).

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

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

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

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by KaVir   Germany  (117 posts)  [Biography] bio
Date Reply #43 on Fri 23 Jul 2010 10:43 AM (UTC)
Message
I wouldn't argue that text and graphics are the same. Rather, my argument is that text muds and graphical muds are fundementally the same at the server end, because the "text" and "graphics" are displayed by the client, not by the mud itself.

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

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

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

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #44 on Fri 23 Jul 2010 12:10 PM (UTC)
Message
Quote:
But whether the game is graphical or completely text-based isn't something the mud can directly control.

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

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

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

Quote:
Personally I'm pretty excited about the possibilities.

Definitely. :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] 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.


271,130 views.

This is page 3, 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] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]