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

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

Date

Reply #15 on Thu 27 May 2010 02:52 AM (UTC)

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

Message

This ground has been gone over at some length a month or two ago on the ~~Mudstandards.org~~ forum.

One problem is getting client developers to agree on a format (eg. XML, Lua, JSON, bencoding) for sending data to/from the server.

The next problem is convincing server developers to agree on the same thing (harder than it sounds).

Then we hit the issue (which you raised) about supporting, ah, less frequently-used systems (eg. minix, bsd) or ones such as Internet Cafes. So either you write something that the lowest-common denominator can handle (and I mean that in a nice way), or some users get left out.

Then we hit the issue of some games having non-standard (if I may use that expression without getting attacked) designs. For example, if you build into the protocol a message when you change rooms, some developers said "but we don't have rooms".

Or if you have coordinates, some MUDs don't have coordinates. But if you leave them out, then the ones that *do* have them need them to be sent.

Then we have the issue of "oh but you are forcing me to use a standard", or "I don't want to change things, don't make me". Or "who the heck are you telling me what to do?".

My proposal at the time was to have a simple protocol that just sent keyword/data pairs, where the keyword/data was basically what was relevant to the MUD (eg. room_number=12345). At least that is extensible, since any MUD that needs to can add keywords (eg. coordinates).

However if it is *too* general, well we haven't really defined anything much, and if it is much more specific, well we can't reach agreement about what the keywords should be, what the data should be, how often it is sent, whether frequently-sent data should be cached, and so on.

I read an interesting post elsewhere today about MMO development. In that the poster basically suggested designing to a specific subset, otherwise you will be there all year trying to accommodate everything.

I think this is fair advice. Perhaps a subset would be "Muds that have rooms, but not coordinates", and then take it from there (just an example mind you).

It is interesting BTW that when you look at a game like WoW, they actually simplify some things quite a bit, but in a subtle way. For example, you can't drop things on the ground. Also, players can walk through each other and through mobs. Now you might argue "but I *should* be able to drop things on the ground", or "I should *not* be able to walk through people" on the grounds of realism. But by limiting their design in this way they greatly simplify the design of the client and the server.

[EDIT] (April 2015) Warning: Domain name mudstandards.org has been abandoned. That site is now an adult products shop.

- Nick Gammon

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

Top

Posted by

Dralnu USA (277 posts) Bio

Date

Reply #16 on Thu 27 May 2010 02:59 AM (UTC)

Message

Nick Gammon said:

Dralnu said:

I'm also concerned about whether or not, if this path were to be taken, the added effort required by client developers to support X number of protocols would mean the death of many and end up with only a select client (or few clients) that can play a specific game, much like the current system in place by MMOs. If a client were to be written to interface with a specific MUD then there is not only the support issues regarding the MUD to deal with but also the development and support issues of the client on top of the server, doubling or tripling the work load of developers and may (should things progress too far down this dark road) prevent other games from opening up simply due to the enormous workload a probably lone hobbist dev will have to face.

These seem to me to be contradictory objections. If some proposed changed required "added effort", "doubling or tripling the work load of developers" with an "enormous workload" then surely the idea will fail, and the existing MUDs will not in any way suffer any harm.

My concerns of workload is mainly directed at new devs. For a skilled programmer who can get a computer to compute the value of 1/0 (let's not start on this example), then things aren't quite as bad. My concerns are more for those who see a MUD and think "I can change this as I want and it will work" who may end up seeing it as "I'll need to change this server, then change the client to handle what the server says".

Quote:
The idea behind my original suggestions was to make things very easy for the hobbyist developer. Easy to produce a game that meets the expectations of players in 2010 rather than the way we played then in 1980.

Given the current trends of games these days a text-based MUD doesn't meet a 'modern gamer''s expectations, since players seem to want flashy graphics and cool explosions. Either we are looking at a diffrent demographic than the 'modern gamer', or we are climbing a mountain no one cares about anymore.

Quote:
So you still have text descriptions (which a small team can invent and key in), and thus no need to use 3D engines, and have teams of artists making 3D models, and 3D terrain and so on.

The lack of these can be a good thing, but there are free 3D engines availible, as well as programs to make 3d models and such. Skins are harder to make, but then again writing a good room desc takes skill as well.

Quote:
However the key idea is to improve the user interface - after all we have drag and drop now, we didn't have it in 1970-1980. We have GUI interfaces. We have more memory and faster machines. We have faster network connections. We can render a map or minimap on the corner of our nice large monitors, and have health bars, and experience bars. That simply wasn't possible 30 years ago.

I've seen stories where people did things on older hardware (30+ years old) that people couldn't do on a modern machine, or the older hardware simply did better. Screen space is the only thing you have listed that would make a huge diffrence, and that is something that really doesn't exist (try opening 3 xterms on a widescreen and see how quickly things get crowded).

Quote:
Remember, the game designers of the original MUD games pushed the technology (of the day) to the limits. Why should we stop doing that?

They may have pushed it to its limits, but how many computers back then were running half a dozen diffrent apps at once? With current trends in CPU, memory, and disk usage the supposed power of your current desktop isn't that impressive. I will actually say trying to push modern system's limits is a Bad Thing since
A) A MUD client will likely be one of many programs running, along side a browser, chat client, email client, and possible other programs
B) Some players play MUDs because they can't handle newer games like WoW, Guild Wars, or <insert game here>. Rural areas sometimes are still stuck with dial-up, or a kid is playing off his parent's old system (bought brand new with a top-of-the-line i486).

We have no clue what resources are avalible, if any, for the game which we develop, nor what kind of system the player is coming from (or, for that matter, what kind of network they are on).

In the case of the server, there are still other issues. What hardware are we running on? Are we on a p2 shoved into some closet or running on a 64 core dedicated server with more memory than a herd of elephants and a network pipe you can run a subway through? Are we transmitting enough data to flood a user's connection so they can see a goblin's brain splatter on their screen?

Top

Posted by

Dralnu USA (277 posts) Bio

Date

Reply #17 on Thu 27 May 2010 03:15 AM (UTC)

Message

Nick Gammon said:

This ground has been gone over at some length a month or two ago on the Mudstandards.org forum.

One problem is getting client developers to agree on a format (eg. XML, Lua, JSON, bencoding) for sending data to/from the server.

The next problem is convincing server developers to agree on the same thing (harder than it sounds).

Then we hit the issue (which you raised) about supporting, ah, less frequently-used systems (eg. minix, bsd) or ones such as Internet Cafes. So either you write something that the lowest-common denominator can handle (and I mean that in a nice way), or some users get left out.

Then we hit the issue of some games having non-standard (if I may use that expression without getting attacked) designs. For example, if you build into the protocol a message when you change rooms, some developers said "but we don't have rooms".

Or if you have coordinates, some MUDs don't have coordinates. But if you leave them out, then the ones that *do* have them need them to be sent.

Then we have the issue of "oh but you are forcing me to use a standard", or "I don't want to change things, don't make me". Or "who the heck are you telling me what to do?".

My proposal at the time was to have a simple protocol that just sent keyword/data pairs, where the keyword/data was basically what was relevant to the MUD (eg. room_number=12345). At least that is extensible, since any MUD that needs to can add keywords (eg. coordinates).

However if it is *too* general, well we haven't really defined anything much, and if it is much more specific, well we can't reach agreement about what the keywords should be, what the data should be, how often it is sent, whether frequently-sent data should be cached, and so on.

I read an interesting post elsewhere today about MMO development. In that the poster basically suggested designing to a specific subset, otherwise you will be there all year trying to accommodate everything.

I think this is fair advice. Perhaps a subset would be "Muds that have rooms, but not coordinates", and then take it from there (just an example mind you).

It is interesting BTW that when you look at a game like WoW, they actually simplify some things quite a bit, but in a subtle way. For example, you can't drop things on the ground. Also, players can walk through each other and through mobs. Now you might argue "but I *should* be able to drop things on the ground", or "I should *not* be able to walk through people" on the grounds of realism. But by limiting their design in this way they greatly simplify the design of the client and the server.

Something I had thought about while posting was the possibility of a basic system, probably like some of the legacy systems (ch says "sentence") which provides the needed data for a simpe chat (who, the channel, and the content) but still works with older clients. For content that would be required for a more complex interface (automapping), then I was thinking 2 standards:
1) The 'Don't Print This' standard. Simply put, content that the client doesn't support at this point is dropped from the input, never seen by the player
2) A generic macro/alias/trigger system to handle key=value pairs, or some other method of handling info.

This way older clients could simply ignore the content after a point (or a client that handles input modification could have a script written to delete the content), or do something with it (hopefully something other than telling the server to interface with itself).

Beyond this leave it up to MUDs to handle their own things. If a group of MUDs wants to work with a specific set of scripts then let them. If they want to modify(given no license issues), then they can.

The MUD will then still have the issue of 'how to we support people who don't use a standard-compliant client?', but they could also say 'Screw it. They will get the info, let them do with it what they please'. If these values are transmitted through a single function, then adding a single config to the game could eliminate the output and no one is left out (even telnet users!) unless the MUD does something really screwy, like just using this data to tell the client things.

I see it more as an extension than a replacement for traditional output, but might could satisfy everyone with some work.

Top

Posted by

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

Date

Reply #18 on Thu 27 May 2010 03:15 AM (UTC)

Message

For what it's worth, a while back when I was playing WoW, and my cable connection went down, I dropped back to dial-up.

Whilst it was a bit sluggish, it certainly ran OK. They have quite cleverly designed it to heavily cache things (and the drawing of the brains splattering is a client thing), and use predictive movement algorithms etc.

In any case, any future developments aren't going to replace what we currently have. There will always be a place for text MUDs, and low-bandwidth connections which could be used by rural communities and those that don't want to, or can't, use broadband.

In fact, I have quite a few people on this forum who ask about screen readers, as I presume they have limited or no vision. A text game is ideal for such situations. Ditto if you can't move your hands quickly enough to play a "twitchy" graphical game.

Dralnu said:

My concerns are more for those who see a MUD and think "I can change this as I want and it will work" who may end up seeing it as "I'll need to change this server, then change the client to handle what the server says".

That's true for major changes. But once you have the infrastructure in place, most changes will work within it. For example, you could add new rooms, new mobs, new quests, new towns, new chat channels. You can change combat algorithms, damage messages etc (provided there is some mechanism for "display a general message").

So I don't think developers would be paralyzed into not being able to make any change without having to also change the client. It's a bit like web browsers, web page developers can make many many changes without having to get the browser changed. But occasionally browser changes do add new functionality (eg. playing inline movies).

- Nick Gammon

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

Top

Posted by

Dralnu USA (277 posts) Bio

Date

Reply #19 on Thu 27 May 2010 03:35 AM (UTC)

Message

Nick Gammon said:

For what it's worth, a while back when I was playing WoW, and my cable connection went down, I dropped back to dial-up.

Whilst it was a bit sluggish, it certainly ran OK. They have quite cleverly designed it to heavily cache things (and the drawing of the brains splattering is a client thing), and use predictive movement algorithms etc.

I played Guild Wars years ago on a dial-up. The loading was the problem, not the game play. However the desire to feed more and more data to a client may become more of an issue, same as using CPU and RAM.

Quote:

The easy of extension is definatly an issue related to the design of the game and client, but some poor design choices (done either out of ignorance, spite, or no better way) can still be an issue. imo, vnums are a great example of such a choice.

Quote:
So I don't think developers would be paralyzed into not being able to make any change without having to also change the client. It's a bit like web browsers, web page developers can make many many changes without having to get the browser changed. But occasionally browser changes do add new functionality (eg. playing inline movies).

That is true today, but it hasn't always been. During the early days some websites required (some still do, mind you) special tweaking to work with a specific browser or a browser had to emulate bugs in another to work properly. Even today there are still browser-specific webpages (requiring IE-specific plugins to function, for example) and content that browsers can't handle (flash, quicktime movies which the browser simply places on the screen).

Top

Posted by

Bernhard (18 posts) Bio

Date

Reply #20 on Mon 31 May 2010 09:49 PM (UTC)

Message

actually, why not use web browsers as clients anyway?

A web browser is available everywhere, so you don't have to program the client and the communication will pass any firewall. You could add some SVG elemens for some status bars, buttons, minimap, ... (SVG = Scalable Vector Graphics; It's a text format that rowsers can render into a graphics of any size/percentage of the window. Internet Explorer needs a free plugin, (most) others can do it without plugins).

Everything is done by the server, which can build this information by description files for rooms (or for cards in my case).

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #21 on Mon 31 May 2010 10:03 PM (UTC)

Message

Bernhard said:

actually, why not use web browsers as clients anyway?

A web browser is available everywhere, so you don't have to program the client and the communication will pass any firewall. You could add some SVG elemens for some status bars, buttons, minimap, ... (SVG = Scalable Vector Graphics; It's a text format that rowsers can render into a graphics of any size/percentage of the window. Internet Explorer needs a free plugin, (most) others can do it without plugins).

Everything is done by the server, which can build this information by description files for rooms (or for cards in my case).

That's -my- project. ;)

'Soludra' on Achaea

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

Top

Posted by

Bernhard (18 posts) Bio

Date

Reply #22 on Tue 01 Jun 2010 09:57 PM (UTC)

Message

Twisol said:

That's -my- project. ;)

@Twisol: Is there any project page? Or even a prototype? Are you going to provide sources? Which licence? It would be really interresting to here some details of your concepts (somewhere).

On the subject in general:

I think there are two key points:
- one is about game design
- the other is user interface design

Game design:
I must admit that I was playing MUDs only for an hour or two about 1998 - a friend was very enthusiastic about it, so I tried it. However, I can still remember what happened:
I started somewhere, did not really know what to do, just went to the south a couple of time (if you don't know where to go any direction will do), and finally encountered a thief there stealing some coins or something. I decided to defend my self and was killed in a couple of seconds (2nd hit, I think). Now the game wantet me, as a ghost, to float around and find some altar or temple of something. Without telling me where to go or giving any other options.
I asked my friend what to do and he said that I'm not supposed to fight thiefs for the next 100 hours or so. I'm supposed to start fighting flies, later advance to mice and on level 10 or so we can talk about rats.
That's about the point I decided that I've better things to do (and Baldurs Gate came out a couple of days later, followed by several Infinity Engine games that I still play once in a while).
I assisted some people that wanted to build their own MUD, but I never played one again myself (now I prefer to programm card games which use similar programming techniques.)

=> Now, I think such things could easily be avoided.
You HAVE TO fascinate the user instead of frustrating him or her in the beginning. You MUST give the user a feeling of success in the first five minutes, or you are going to loose him before you really got him.

Of course, once you 'have' the user, keeping the game attrative on the long term is another issue.

Interface Design:
A computer which does not have a graphics mode does not exist anymore. There is plenty of space on the screen (unless you programm for a mobile phone which would also ba an interesting idea). Use it for status bars and icons that allow the user to see lots of info without actually reading lots of text.

Nick Gammon said:

There is still a lot of scope for text-based games, because they have a lower development overhead than 3D games.

You could use an existing engine as well, e.g., do a MOD of an existing (commercial) game. Some games even provide graphical level editors for that purpose. However, doing so you will allways keep something of the nature of the original game. E.g., if you got a very combat oriented end time adventure you probably won't make it a story focused fantasy game. But you can get nice 3D graphics this way without development overhead - at the cost of not heaving a standalone game.
Anyhow, it does not need to be "full" 3D with unlimited zoom and rotation. You certainly can generate some 2D or even isometric (3D) graphics on a client if you have a small set of object models and coordinates from the server.

Nick Gammon said:

As my existing experimentation has shown, you can take the basic data that existing game servers work with (the "room" model, text descriptions) and automatically generate fancy maps, health bars, button bars, and generally a lot of the sort of client interactivity that the graphical MMOs already have.

If you dont want to change the server, automatically generating the graphics from the info that is already there will be your only chance.

Top

Posted by

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

Date

Reply #23 on Tue 01 Jun 2010 10:43 PM (UTC)

Message

Bernhard said:

Now the game wantet me, as a ghost, to float around and find some altar or temple of something. Without telling me where to go or giving any other options.
I asked my friend what to do and he said that I'm not supposed to fight thiefs for the next 100 hours or so.

Thank you, you have described rather eloquently what I think causes people to switch off a MUD shortly after trying it. And this sort of thing could be so easily avoided with a bit of code.

For example, just don't allow combat in cities where you put beginner players, or at least not below level 10 or so. Another thing might be to have an "easy death" option, where it says something like "you died, but the gods resurrect you on the spot, as they realize you are a beginner".

By contrast, popular games like WoW only put level 1 or 2 mobs near beginner players, and they are non-agressive. And if you do manage to die, it is a short walk back from the graveyard to your corpse, with the location of both being shown on the minimap.

- Nick Gammon

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

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #24 on Wed 02 Jun 2010 07:36 AM (UTC)

Amended on Wed 02 Jun 2010 07:43 AM (UTC) by Twisol

Message

Bernhard said:

Twisol said:

That's -my- project. ;)

@Twisol: Is there any project page?
No.

Or even a prototype?
Not yet!

Are you going to provide sources?
Probably not at first. Down the road, there's a good possibility.

Which licence?
It's proprietary right now.

Answers in bold.

Bernhard said:
It would be really interresting to here some details of your concepts (somewhere).

It's a web-based client to connect to any MUD, a lot like Mibbit (mibbit.com) is for IRC networks. I call it Aspect. It doesn't use any plugins (no Java, no Flash, no Silverlight), relying solely on Javascript. It does not directly speak with the MUD; instead it talks to the Aspect server, which itself talks to the MUD. This will let me do a lot of cool things.

I want Aspect to be as full-featured as possible. Most of the web-based clients right now are kind of... lame, in my opinion. Aspect should be just as powerful as MUSHclient (except it runs on my server instead of the user's computer). One of the things I really want to do with Aspect is let MUD owners custom-craft the interface a user will see when they play their game. Things like this should be very enticing to MUD admins.

Aspect is currently in the early concept stage, with under 100 lines of code yet written. It's written in Ruby, though, and takes advantage of EventMachine (an evented (reactor-based) library), Thin (web server based on EventMachine), and Cramp (an evented web framework) for its foundation. Users communicate with the server via Ajax long polling (which any client that supports Ajax can do), which means the server keeps the connection open until it has data to send. This keeps things real-time (or as close as you can get). I also use Rails, primarily for its excellent URL router, but also for managing the non-client part of the website.

Bernhard said:
Interface Design:A computer which does not have a graphics mode does not exist anymore. There is plenty of space on the screen (unless you programm for a mobile phone which would also ba an interesting idea). Use it for status bars and icons that allow the user to see lots of info without actually reading lots of text.

Expanding on my point before about custom interfaces, I really really want to support user plugins. I don't yet know what exact form they will take, but I have a few ideas rolling around. I definitely want to have an API to take advantage of HTML 5's <canvas> element, though. In fact, thinking about the similarities between <canvas> and MUSHclient's miniwindows is what got me started on Aspect!

'Soludra' on Achaea

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

Top

Posted by

Bernhard (18 posts) Bio

Date

Reply #25 on Thu 03 Jun 2010 01:59 PM (UTC)

Message

Thinking a bit more about your question from the marketing point of view (instead of the technical one), I think it needs to be analyzed and defined more clearly:
"What can be done to improve the retention rate of MUD games?"

You need to define "retention rate" (long or short term; stay at a particular mud or just within the game family), and most importantly "MUD" (where would you put the border between a "MUD" and something else). Furthermore, you did not define any constraints on "what to do" (by whoom, up to which time/money effort, commercial or hobby project, what can you change that it is still a MUD and not something else).

"How can the one and only game desinger of an existing, free online text-only adventure reduce the entry barrier for new players?" is a different question than "How can I build a game commercial game from scratch

that the players will play and, thus, pay for for years (instead of going hiking or something)?".

Market strategy textbooks say: If you do not have the resources to built and run something state-of-the-art/close to the market leader, you have to find a proper niche.
What precicely would you think that "the market" is here?

Yet another question: "What would you be NOT willing to sell for a higher retention rate (or something) in order to still call your game a MUD?"

Top

Posted by

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

Date

Reply #26 on Thu 03 Jun 2010 10:12 PM (UTC)

Message

These are very good questions.

Bernhard said:

You need to define "retention rate" ...

One simple measure would be "how many players are on at peak times" - that is, is this figure rising or falling? However that doesn't distinguish between lots of new players, all who leave a week later, or a hard core of existing players.

I would suggest measuring (from time a character was made, plus played time) two things:

How much play time they have put in (eg. 100 hours)
How long this character has been active (eg. 2 weeks)

You would need to define "active", but I guess if a player logs in at least once a week and plays for 30 minutes you could call them active.

I read somewhere that Iron Realms found that new players tended to leave "once they had to move around" which I take to mean within 15 minutes or so. So obviously a retention time of 15 minutes is not too good. That would tend to indicate confusion with the basic interface (or the need for maps, or more understandable controls, or something).

If a player lasts a few days, then they have probably grasped the basics of moving, but maybe haven't yet done much combat.

If they last a few weeks, then we can assume they are into combat, communication, etc.

So I guess my answer is, if the average time a new player "keeps playing" increases, for a given MUD, you have improved your retention rate.

Bernhard said:

... (long or short term; stay at a particular mud or just within the game family) ...

It would be difficult to know whether a player leaves one MUD and starts at another, so I suppose the easiest to measure is per MUD. Also they may make one character, delete it and start a new one. If you tracked IP addresses (or accounts) you may be able to treat that as a single player still playing rather than two players, one who stayed and one who didn't.

Bernhard said:

... and most importantly "MUD" (where would you put the border between a "MUD" and something else).

I suppose I mean a primarily text-based multi-player game, where room descriptions, mob descriptions, character and object descriptions are in words and not 3D graphics.

Bernhard said:

Furthermore, you did not define any constraints on "what to do" (by whoom, up to which time/money effort, commercial or hobby project, what can you change that it is still a MUD and not something else).

In this case I mean something that can be reasonably achieved by the person or people who are currently maintaining the MUD. For example, my videos showing status bars, room descriptions in a box in the corner, a mapper, and so on were done by a single person (me) over a couple of weeks.

Bernhard said:

"How can the one and only game designer of an existing, free online text-only adventure reduce the entry barrier for new players?" is a different question than "How can I build a game commercial game from scratch

Indeed. And if time is tight then even a subset of my suggestions could be implemented. For example, bearing in mind the recent post, simply tweaking game parameters so that newbies don't get killed by high level mobs in the first 10 minutes, could be a reasonable first thing to change.

Another simple change might be to start newbies off with more equipment so they can start doing things rather than spending the first day just getting good enough gear to leave the city walls.

A game with more resources (like Achaea for example) might be able to go further, and have graphical mappers, and party member icons. However if this is still around the framework of their existing levels and descriptions, I think it is fair to say it is "still a MUD".

Bernhard said:

Market strategy textbooks say: If you do not have the resources to built and run something state-of-the-art/close to the market leader, you have to find a proper niche.
What precisely would you think that "the market" is here?

I think that there is still scope for more individual "indie" games - ones that the big players wouldn't dare touch. Niches could be:

People on low-bandwidth connections (eg. country areas)
People with low or no vision, who appreciate the fact that screen readers can read out the descriptions
People who are less able to use "twitchy" interfaces like mice, due to older age, or disabilities.
An edgier level of content (eg. adult content) which big companies wouldn't touch
Games with player-developed areas (MUSH games tend to be like this)
Games that can add content much faster than graphical games because they don't need to make 3D models of everything.
Games aimed at smaller devices (eg. mobile phones)

Bernhard said:

Yet another question: "What would you be NOT willing to sell for a higher retention rate (or something) in order to still call your game a MUD?"

I can't answer that one. Short of a complete rewrite, existing MUD servers can probably still call themselves MUDs.

- Nick Gammon

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

Top

Posted by

Bernhard (18 posts) Bio

Date

Reply #27 on Sat 05 Jun 2010 10:31 PM (UTC)

Message

Certainly, as already discussed, step 1 would be to avoid needlessly scaring of the users.
About the potential niches:

Nick Gammon said:

*People on low-bandwidth connections (eg. country areas)

Do you think there are still a lot of such people? In europe certainly not - even mobile internet with about 1 MBit/s is available almost everywhere. The time I only head a modem conection at home (15 years ago) I was not playing online, because it hat a price per minute online (not per MB), equivalent to the price of a phone call. I mainly used the internet in the university that time.

Nick Gammon said:

*People with low or no vision, who appreciate the fact that screen readers can read out the descriptions

OK. It may work well for such people.

Nick Gammon said:

*People who are less able to use "twitchy" interfaces like mice, due to older age, or disabilities.

There are programs to substitute mouse input with keyboard. The keyboard is not an easy to use interface either. Having no realtime requirements in the game might be the key here.

Nick Gammon said:

*An edgier level of content (eg. adult content) which big companies wouldn't touch

Adult content: I don't think comercial games have problems with erotic or extremly violent content - maybe those are not the games displayed in the window, but they are available. Political and religios content (the extreme-frankincensing-MUD?) might not have too much interested people.

However, I think the commercial games focus almost exclusively on the high fantasy genre (the - lord of the rings/dungeon & dragons - stuff). And if it's not high fantasy its high science fiction (star trek / star wars). What about western? Eastern? Steam punk? Victorian era? So it does not need to be adult content, just not within the narrow mainstream.

Nick Gammon said:

*Games with player-developed areas (MUSH games tend to be like this)
*Games that can add content much faster than graphical games because they don't need to make 3D models of everything.

Both things may be done by MODs (modifications/additions to commercial games). Some games offer editors for players with no or little programming abilities (e.g., Neverwinter Nights (NwN)). In fact those abilities are one of NwNs key featurs.

Nick Gammon said:

*Games aimed at smaller devices (eg. mobile phones)

You might have some problem whit the limited amout of text you can show on the screen of a mobile phone. If you get this managed, right.

Nick Gammon said:

Bernhard said:

Yet another question: "What would you be NOT willing to sell for a higher retention rate (or something) in order to still call your game a MUD?"

I can't answer that one. Short of a complete rewrite, existing MUD servers can probably still call themselves MUDs.

Once I was not allowed to completly rewrite some piece of software that was full of flaws. So I recycled one } from the original code ...

So I think the quest/room/creature/item description texts and their connections should be conserved. Would you "allow" to completly rewrite the engine? Replace it with a new one that REQUIRES to add additional contents like icons?

With the question I ment somewhat more general: What are the MUST HAVE key concepts of a MUD?
e.g., "has to be online (or bigger LAN)", but a more critical ones is "must have ONLY text", ...

Top

Posted by

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

Date

Reply #28 on Sat 05 Jun 2010 11:28 PM (UTC)

Amended on Sat 05 Jun 2010 11:29 PM (UTC) by Nick Gammon

Message

Bernhard said:

You might have some problem whit the limited amout of text you can show on the screen of a mobile phone. If you get this managed, right.

The iPad has 1024 x 768 screen real-estate. For quite a while this was considered normal. Also you can plug it into a proper keyboard (for around $US 69).

So playing a MUD on a mobile device is quite achievable these days. Even the built-in keyboard (onscreen one) is quite nice to use, although it obscures some of the screen when it is "up".

Bernhard said:

e.g., "has to be online (or bigger LAN)", but a more critical ones is "must have ONLY text", ...

Well personally I wouldn't say "only text" but that text is the medium for providing descriptions. Quite a few people these days are using health bars, XP bars, mappers and so on to supplement their MUD experience.

So my description might be "a multi-player online fantasy game, where the core content is described in words, rather than shown in graphics". Of course, this description includes most current MUDs (if not all of them), but does not exclude the provision of things like user-interface aids like health bars, XP bars, quest windows, buff (spellup) windows, action buttons, and various things to make the experience more enjoyable.

- Nick Gammon

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

Top

Posted by

KaVir Germany (117 posts) Bio

Date

Reply #29 on Sat 05 Jun 2010 11:50 PM (UTC)

Message

Bernhard said:
With the question I ment somewhat more general: What are the MUST HAVE key concepts of a MUD? e.g., "has to be online (or bigger LAN)", but a more critical ones is "must have ONLY text", ...

The only "MUST HAVE" I can think of is that it must be multi-player, with some form of interaction between characters within a persistent virtual world. I consider EQ, WoW, DDO, etc to be MUDs as well.

Graphics and sound are part of the client, not the MUD itself. However I would define a "text-based MUD" as one that is designed to be fully playable through a text interface.

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,215 views.

This is page 2, 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