Gammon Forum : MUDs : MUD Design Concepts : Suggestions for improving MUD game retention rates

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

Suggestions for improving MUD game retention rates

Posting of new messages is disabled at present.

Refresh page

Pages: 1 2 3 4 5 6 7

Posted by

KaVir Germany (117 posts) Bio

Date

Reply #45 on Fri 23 Jul 2010 03:13 PM (UTC)

Message

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

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

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

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

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

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

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #46 on Fri 23 Jul 2010 03:34 PM (UTC)

Message

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

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

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

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

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

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

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

Quote:
plus it would be hard work coming up with all those icons.

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

Quote:
But all of these are client-side concerns - obviously the mud needs to provide the necessary data, but that's not a huge task, and (on its own) is not enough to make the mud graphical.

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

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

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

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

KaVir Germany (117 posts) Bio

Date

Reply #47 on Fri 23 Jul 2010 09:07 PM (UTC)

Message

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

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

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

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

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

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

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

David Haley said:
For the data to be used in a way that's out of your control, you still need to be sending it in the first place. And interestingly enough, you weren't sending it until you had graphics in mind...

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

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

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #48 on Fri 23 Jul 2010 09:14 PM (UTC)

Message

Quote:
No, I envisioned someone drawing a huge number of scenes, [...] It would require a huge amount of work, and the solution would be far from optimal, [...] I'm not proposing doing this, I mention it only as an example of why I prefer not to define something as being a "mud" based on whether or not it's graphical.

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

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

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

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

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

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

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

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 #49 on Fri 23 Jul 2010 09:19 PM (UTC)

Amended on Fri 23 Jul 2010 09:20 PM (UTC) by Twisol

Message

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

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

'Soludra' on Achaea

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

Top

Posted by

Nick Gammon Australia (23,122 posts) Bio Forum Administrator

Date

Reply #50 on Fri 23 Jul 2010 09:52 PM (UTC)

Message

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

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

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

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

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

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

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

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

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

- Nick Gammon

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

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #51 on Fri 23 Jul 2010 10:03 PM (UTC)

Message

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.

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

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.

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

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

Nick Gammon said:
I stick to my original view that, for newbie players, those who perhaps you are trying to attract, improving the user interface would help them to understand what is going on.

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

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

KaVir Germany (117 posts) Bio

Date

Reply #52 on Fri 23 Jul 2010 10:28 PM (UTC)

Message

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

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

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #53 on Fri 23 Jul 2010 10:30 PM (UTC)

Message

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

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

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 #54 on Fri 23 Jul 2010 10:45 PM (UTC)

Amended on Fri 23 Jul 2010 10:49 PM (UTC) by Twisol

Message

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

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

'Soludra' on Achaea

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

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #55 on Fri 23 Jul 2010 10:52 PM (UTC)

Amended on Fri 23 Jul 2010 10:53 PM (UTC) by David Haley

Message

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

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

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

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

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

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

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 #56 on Fri 23 Jul 2010 11:11 PM (UTC)

Amended on Fri 23 Jul 2010 11:12 PM (UTC) by Twisol

Message

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

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

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

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

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

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

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

'Soludra' on Achaea

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

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #57 on Fri 23 Jul 2010 11:20 PM (UTC)

Message

Quote:
Look at Lynx, the textual web browser. A web server sends the HTML data, which may indeed include referenced images, but Lynx only renders what it wants to render, and the web server doesn't (or shouldn't) care that the browser used is Lynx.

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

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

--

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

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

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 #58 on Fri 23 Jul 2010 11:40 PM (UTC)

Message

David Haley said:

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

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

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

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

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

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

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

'Soludra' on Achaea

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

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #59 on Sat 24 Jul 2010 01:46 AM (UTC)

Message

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.

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.

Quote:
You may have an idea for how the data will be used - if you didn't, you probably wouldn't send it - but it could be used beyond how you expected, so expectations for presentation shouldn't be inherent in the sending of the data itself.

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

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

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

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

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

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

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

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

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

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.

302,314 views.

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

Posting of new messages is disabled at present.

Refresh page

Go to topic: Search the forum

top