Yes.

"At any time fewer than 80,000 remain in existence because of inactivity, or as a result of deletion due to various rule infractions. Though the specific time has varied greatly over the years on-line, NationStates has a current inactivity limit of 28 days (or 60 days if nation-owners enable "Vacation Mode"), after which the system automatically deletes the quiescent nation."

So we're not talking about 80,000 people online at once (which would be pretty unusual, as it appears to be a very casual game - you make one decision per day), but up to 80,000 people who connected at some point over the last 28-60 days.

Taking a look at their website, they list 54,915 nations and state "Currently online: 1,376 nations." - so around 2.5% of their players are currently online.

As a comparison (of relative percentages), my mud currently has only 20 players online, but 328 connected over the last 30 days - and I only count players who have played for at least 3 hours. A quick grep for all pfiles active in the last 30 days shows 510 users. That means around 3.9% of the users who connected in the last 30 days are currently online.

If you look at other games, you'll see a similar pattern. Even Travian, where you have to be extremely active to do well, shows the following stats on its com servers:

Players total: 62192
Players active: 51614
Players online: 2771

That online figure is therefore 5.4% of their "active" players (not quite sure how they define that) and 4.5% of their "total" players.


And according to their website, "There are currently 829 players logged in" (0.6% of the active players). That seems very low, I wonder how they define "active players"?

By comparison, the largest mud on MudStats is Tapestries MUCK, which currently has 739 players logged in.


And that same page lists "Players active in the last hour: 1068" (5.9% of the active players).

But muds don't need to drop telnet to be playable through a browser - there are already several muds that offer customised browser clients while also being playable through regular mud clients. Sadly these muds don't seem to be doing particularly well, but I believe it's still early days, and that browser clients have a lot of potential for muds.

You know, I think the Mods should sticky this thread. It provides a pretty clear introduction to the posting styles and online personalities of many of the more prolific members of MB. It would be a good education for newbies.

Please do not read this as a jab/complaint/flame of anyone who has posted here. It is not intended as such*. But I think that if everyone re-reads this thread they will find that it does provide a good overview of the major players here.

* While reading this thread, I just found myself saying, 'Yeah, that's XXX'.

My estimate of 100,000 total MUD players appears to be fairly low, then. Assuming that the average number of players connected comprises around 4% of the total playerbase (based on your figures), and assuming that the average number of players connected to MUDs is 10,000 (probably a little high, judging by the mudstats.com graph), that would put the total MUD playerbase at around 250,000 players. I'm having a little trouble believing that figure, but I'll go with it. Even with these revised figures, the NationStates playerbase is about 1/5th the size of the entire MUD playerbase. Urban Dead's playerbase is about 1/13th the size. Kingdom of Loathing… well I think we could do with some more accurate figures in that case. These proportions are still nothing to be sneezed at, because these games are only medium-size when it comes to browser games, and they're very similar to MUDs in many ways.

The games I chose as examples are not the height of popularity when it comes to browser games (though they are obviously popular). Yet all of them - even those on which you can only really play for about 5-30 minutes a day - have more players than all but the #1 most popular MUD. Urban Dead was started in 2005 and has 1,000 players online right now. How many MUDs started 5 years ago have come even remotely close to that figure? Even Tapestries - the most popular game on mudstats.com - hasn't hit 1,000 players in the last 30 days.

I refuse to believe that real-time, text-based gameplay is inherently less appealing to people than turn-based, text-based gameplay (i.e. browser games). I also don't think that it's a problem with casual vs. non-casual games (Travian, from the sounds of it, is not for casual gamers, but it's doing quite well).


No, they don't. But suppose I'm building a single-purpose browser client for my MUD and I don't really care whether users can or can't use a traditional MUD client, what incentive do I have to use Telnet rather than just developing my own packet protocol specifically for use with my game?

Is your argument that I should care whether users can use a traditional MUD client to connect to my game? is it that I should use Telnet rather than rolling my own? Perhaps it's something else?


I don't want to sound like I'm saying that if you build a kick-ass browser client your MUD will get flooded with players, but simply having a browser client significantly lowers the barrier for new players. If your browser client happens to have a particularly good GUI (and I'm talking about good UI, not just good G here), then retaining those new players will probably prove a lot easier. Obviously in order for new players to try out your game and for you to subsequently retain them, you need to attract them in the first place. That's an entirely different matter. Nonetheless, if you do manage to attract a lot of new players (as some MUDs do), but you still have an archaic wall-of-text interface (as most MUDs do), it's probably not going to do you much good.

I think that the majority of MUDs that currently have browser clients are either failing to attract new players in the first place, or their interfaces are unhelpful or even confusing to those new players. An interface along the lines of what quix described in his most recent post may well prove more enjoyable and intuitive to people who've never played a MUD before. This is not to say that existing interfaces are necessarily bad, but rather that they are generally not what new players are expecting and/or are used to, and I think most new players are likely to quit something rather than try to understand it.

It's an annoying tendency that David is particularly prone to, to make grand statements about fields he has zero practical experience with, often inaccurate or misleading, provoking a response, which then is met by buddies who'll happily second guess you for the hell of it.

From a trolling perspective it's brilliant as you can hi-jack any topic, and you never quite know if someone is serious about their position, or if they're just fucking with you.

Forewarning: This post is extended, and it contains cold hard facts with studies and that kind of thing. Trolls be warned.





I was going to post quotations in response to this, until I realised that I would essentially be posting large segments of the thread in whole cloth Suffice it to say, that I am of the opinion that if you think that's not the case, you're either being pointedly obtuse, or naive, or both.

Whether you're doing it because of 'his experiments' or simply doing it in the guise of criticising his attempts, the ad hominen attacks on him (and for that matter, myself) are extremely telling.

Yeah, you're right, I've avoided responding to a lot of your points, because I believe that if I am to keep a discourse on the current thread of discussion, it counterproductive to reply to tangential or irrelevant points. I suppose the trolling of KaVir is also irrelevant to the thread of the discussion, but it drowns helpful arguments when you're just bashing someone.

I would posit Scandum is doing the intelligent thing and not responding to your baiting, as well.



The barrier to entry is that it is a text game. It's an intuitive flaw. You can bandage it with new clients or such, but you are talking about a niche market. You can either try to combat that by attempting to turn it from a niche market into a greater market - which many MUDs have tried to do, and mostly failed. Achaea and the Iron Realms MUDs, I think, are a prominent example of this, and Earth Eternal is another, though in a different context: Matt Mihalay (or however you spell his last name) attempted to take his experience and methodologies from text games to a browser-based game. It didn't work, he floundered, and the game was auctioned off. The website has been offline for a while now.

There are ways you can improve the experience. Browser-based clients are an area of opprotunity, but until browsers gain richer support for different features such as websockets, these entries will be neutered, feature-deficient examples at best. Does that mean we should abandon all hope? By no means, further adoption means further push to improve and extend, which we are also seeing with MSDP. However, expecting them to be the second coming is wishful thinking, I think.

What really would help things is hard - and its good design. Programmers don't make good interface developers, generally speaking. Their approach to problems of that nature is to refine protocols and such, or make their GUIs shinier, and while the latter may appeal to the lowest common demoninator amongst gamers, its not the proper solution.

At this point, to be absolutely clear, since people love to take my comments out of context to make them appear foolish, I am commenting generally, and not specifically to Chrisd.

That said, I am going to reiterate myself here, whilst I hate doing that, because it's really an important point. Well made code should be, by design, and by virtue of being well-made, easy to use. It should be accessible. There really is a lot one could touch upon in the topic of program and interface design. To me there are two relevant ones for me when Im designing code and programs to be easy to use: complexity, and proper design.

People in the computer science field have been aware of the dangers of overly complex systems for a long time. This goes for both the end product, and the code used to make it. "The competent programmer is fully aware of the strictly limited size of his own skill; therefore he approaches the programming task in full humility." - Esdger Dijkstra, 1972. Making programs overly complex makes them more difficult - both more difficult to program, and more difficult to use.

A great example of overly complex programming can sadly be found in a lot of MUD codebases. I'm sure I'm not the only one whose tried to fathom segments of CircleMud code nested tenfold, as I am sure that this is not the only codebase to have undue complexity. Control flow complexity is considered important in the computer science field, because it has been correlated with low reliability and frequent errors (McCabe 1976, Shen et al 1985) [1]

Well-designed code should be modular, extensible, and easy to evolve. A common thread poorly-designed code is that it is difficult to adapt or extend, and is not scalable. This is the entire idea that founded object-oriented programming. MUDs are failing because they have not been designed with this in mind. There are notable exceptions to this, and KaVir's attempts with GodWars 2 are one of them. Many MUDs, however, fail to innovate. They are not adapting to changing circumstances, and changing userbases. They are, in short, stagnating.

The problem with hard-and-fast single client designs is that they are inflexible. They work fine in very controlled circumstances, where the userbase has consistent and well-defined needs. They fall apart, however, when the working environment changes, or the userbase shifts, or you have some sort of unexpected problem that causes you to have to respec the code. [2]

Flexibility that you can provide a customer is an advantage. Before you write a single-purpose client, you cannot reliably determine what your userbase is going to be like, or what their expectations or needs are. And while it certainly is therapeutic in a certain passive-aggressive sociopathic way to piss and moan on an online forum such as this one about users with expectations you don't like, it doesn't solve the problem. [2] By providing a customer with several clients with different functionality, you give them the freedom to choose something that suits their needs. If they find later on that it has a deficiency that prevents them from functionality that they desire, they have the ability to change clients. This allows both you and your userbase to adapt to changing circumstances more gracefully.

Iterative design of server and/or client makes users feel that they are a part of the process. [3] People feel that they have input into the design of the process and this in turn makes them feel validated and satisfied. Evolutionary design also is helpful to the programmer however. The average game development project is often quite late, and over-budget. [4] MUDs often escape the latter, but they rarely do the former. Embracing the fact that the design is an iterative process becomes not only smart, but a matter of survival.

We can spin our wheels on design approaches for quite some time, but it will do no real lasting good and it confuses the issue. The issue is making sure that the people at whom our games are directed receive them favourably. This is the measure of success. If people like our games, then we are successful. If they do not, then we have not succeeded.

I would hypothesise that a protocol change, away from TELNET, would not net you any results positive or negative, as the underlying framework is kept in a black box from the user in most clients, and only a very small segment of MUD users and an even smaller segment of non-MUD users would be interested and proficient enough to be able to use the lower-level transit protocol to their advantage.

If any of the proponents of changing away from TELNET were to prove me wrong, by developing such a thing for a text based game, then I would welcome it. I suspect, however, that these people are not willing to put their money where their mouth is, so to speak, for the same reason KaVir refuses to change from TELNET: It would be alienating a lot of users for no certain, appreciable end.

There are emerging markets, and make no mistake from my former words, browsers are one of them. The proliferation of the world-wide-web has left TELNET, SSH, and other CLI interfaces trailing behind the WWW in traffic and usage. [5][6] There is no data to conjecture that web browser clients attract more or less users than standalone clients, however it stands to reason that a web browser client that was easier to use and openly accessible from a variety of browsers would lower the bar for entry. It is a common remark that I hear, that people were brought to different clients (MushClient, TinTin, et al) after being introduced to MUD games through Nexus, TMC, etc.

So I'll end this as I began it: accessibility is important. If you don't think it is, then you're being niave or foolish. If you think you're gaining something from making things less accessible to your target market to make it more appealing to another market, then you're commiting what we call in the retail industry, "ad suicide".

References
[1] "William T. Ward reported a significant gain in reliability resulting from using McCabe's complexity metric at Hewlitt-Packard (1989b). McCabe's metric was used on one 77,000-line program to identify program errors. The program had a post-release defect rate of 0.31 defects per thousand lines of code. A 125,000-line program had a post-release defect rate of 0.02 defects per thousand lines of code. Ward reported that because of their lower complexity both programs had substantially fewer defects than other programs at Hewlitt-Packard.", Code Complete by Steve McDougall, 1993
[2] "Amundsen planning also inhibits your ability to respond to changes in the consumer environment. If Amundsen had found the Abominable Snowman, he wouldn't have had time to take it's picture. The parallel in software design is especially strong. Rigid planning assumes that when your customer has accepted a requirements document, no more changes are needed.", Code Complete by Steve McDougall, 1993
[3] "Customer satisfaction is built into the process. An important criterion for the success of any project is how well it's received by it's customers. With evolutionary delivery, once the system opens its eyes and blinks a few times, users get excited about having a system that's working. They can see the system early and can start suggesting changes early, when it's most changeable. They have more time to adjust to the working system, and they'll adopt it more readily. In addition, because the software is designed to be delivered in several releases, its architecture assumes that changes will be made, which, again, improves your ability to respond to change requests." Code Complete by Steve McDougall, 1993
[4] "[…] I would estimate that the average large project is a year overdue and 100 percent over budget." Programming Productivity by Capers Jones, 1986
[5] "More resources are put into developing the Web interface than the character-based (telnet) interface because usage data show that the former is more heavily used." http://www.clir.org/pubs/reports/pub105/..., 2002
[6] Table 5, An Empirical Study of Todays Internet Traffic for Differentiated Services IP QoS, by Fulu Li, Nabil Seddigh, et al, 2000

While that's technically true, it's misleading. The GUI of each of the games I've seen that works through the browser is still tied to having the server construct the display, and then the client picks it back apart again to split it up into multiple windows/panes, or to generate graphics to represent certain elements.

Also, because it IS still playable via regular TELNET clients, offering any kind of advanced UI isn't possible without locking out parts of your playerbase. You get nice cosmetic customizations, and a few convenience shortcuts, but no real change. The server still has to do all the work, AND the client now has to do work to undo the server's output.

One thing that occurs to me, in watching this debate, is that it sounds like some people believe that the UI isn't a part of the gameplay. That it is merely a way to enter commands and get output, and has no impact on the game itself. Nothing could be further from the truth. While gameplay and mechanics may drive the UI design, it's also true that the UI will drive game design.

Look at room descriptions. Room descriptions in most MUD's tend to be fairly short and dense, and tend to be written to fit in about 1/3 to 1/2 of an 80x25 terminal window. This leaves room for a line or two of details, a few lines of NPC/object descriptions, and a few lines of messages before it starts to scroll off the screen.

Don't believe me? Log into a MUD which recognizes your terminal size (or allows you to set it) with an 80 column display. Walk around a bit. Now switch your display to 132 columns and do the same. You'll probably notice that the rooms feel "thin" at this point. The text only fills up a line or two, and if there's an inline map, it will look out of place.

Of course, there's also a limit to how much text one wants to read, so expecting a whole novel per room is absurd. Yet, I can't help feel that the reason room descriptions are the average length they are isn't so much because it's a good amount to read, as because it's a good amount to fit on those old terminal screens.

So here's a good question to ask yourselves. How much of your game works the way it does because that's the way it would work best, and how much is because that's the best you can do with the expected terminal display?

That's funny. If it were all over the thread, surely you could come up with just a single tiny instance of me criticizing KaVir's experiments. Your apparent inability to actually justify your increasingly viciously attacks speaks for itself. :sad:

Regarding KaVir's experiments, I have praised them, so I'm not sure how exactly that turns into criticizing. Because I find it useful to actually back up what I say, I will ask you to please refer to post #61 as an example of citing somebody else's pleasure with the experiments' results so far as evidence that I feel that he is making steps in the right direction.

Here's a thought to consider. Maybe, given your propensity to mix up what I'm saying – single-purpose vs. single, client space vs. particular client, need I go on? –, you read positive remarks as negative… it certainly seems to be what you want to do, in any case, no matter what I say. As evidence of that claim, let's proceed to the following:


Now wait a minute. It's baiting to ask an on-topic question about how VT100 interfaces would actually work for blind people, when they have been cited so often in this thread as the reason for having text-only interfaces?

Did I miss a memo somewhere? You yell at me for, supposedly, being off-topic, and when I ask a question that is directly on topic, you yell at me for, supposedly, trolling. Forgive me if I'm feeling slightly incredulous.

Moving along…


Well, not necessarily. You can easily imagine the same server providing two ports, one for telnet and one for the WayCoolBrowserClient, the latter of which requiring no "undoing" of server work.


QFT.

The purpose of my examples above was to illustrate that other text-based games are doing a lot better than even the most popular MUDs. Text-based games are certainly a niche market. At the moment, MUDs are an even smaller niche. I think this is due largely to the fact that - on the whole - BBGs are prettier and easier to start playing than MUDs. Compare the process of registering and logging in to the process of downloading a client, installing it, configuring it, connecting, registering and logging in. Compare staring at a big black window filled with ugly monospaced text to staring at a well designed UI which has useful information collected and represented in the form of pretty graphics.


Earth Eternal was a graphical game - I don't think it really counts as an attempt to turn text-based games from a niche into a mainstream market.


I think this is a misrepresentation of the argument being put forward, though perhaps you're just speaking generally and not in relation to the posts being made in this thread. I agree with the statement.


I briefly touched on this topic in my previous post when I said, "I'm talking about good UI, not just good G here" in relation to GUIs. A well designed interface (and, of course, a well designed game) is very important, though a well designed interface is going to be more immediately obvious to the prospective player. Sadly, I think most MUDs lack well designed interfaces.



None of this rang true to me when I read it. You see, the most successful MMOs all have single-purpose clients. A single-purpose client is a client that is dedicated to your game. It can be changed. It can be improved. There is nothing different in that sense about a single-purpose client and a generic client. The former has been specifically designed for your game, however, and therefore takes the specifics of your game into account (much like KaVir's MUSHClient plugin takes the specifics of his game into account). A well designed single-purpose client should suit your players very well, and if they have any problems with it you can change it - improve the client, and improve their playing experience - in exactly the same way as you change your server. You are painting single-purpose clients as things that - once built - are rigid and unresponsive to change. That is not accurate.

I noticed that you cited your claims here. Code Complete by Steve McDougall. I happen to own Code Complete, Second Edition, by Steve McConnell - I assume your spelling of his surname was a typo, and it's the same book. I couldn't locate either of your quotes in the 800+ page book, and was wondering if you could direct me to the relevant pages.

I happen to think that the quote you cited both times in this particular part of your post has little to no relevance to the topic at hand. A well designed client is a well designed client, regardless of whether it is single-purpose or not. Rigid planning (which is what the citation is concerned with) can obviously affect all types of projects, and so it is something to be wary of when writing a single-purpose client, but I reject the implication that all single-purpose clients are victims of rigid planning, and therefore doomed. Once again I point to basically all major MMO endeavours. There are many successful MMOs with single-purpose clients. There are many successful BBGs with single-purpose clients (i.e. the website through which they are accessed). In fact, I am having trouble thinking of any other type of game with a similar generic client approach to MUDs. I'm sure there are some, perhaps someone could enlighten me?


I suspect you may have moved on from your previous point here, but just to be sure: as with server development, single-purpose client development and design can be iterative and bring players into the process. There's no difference here between users of a generic client engaging with the client's developers and players of a particular game engaging with the game's developers.


The conjecture here is not that players innately find games that do not use the Telnet protocol more attractive than those that dot, but rather that abandoning the Telnet protocol makes it easier to implement certain features which players generally do find attractive. As for your final statement there - the idea is not that you throw a bunch of data at your users, hand them the documentation for your protocol and tell them, "go on, you can use that to your advantage now!" It's that you use your new protocol to your advantage to build a better game interface, and that is what ultimately benefits your players.


What if my target market is "people who have never played a MUD before" and the other market is "people who played a MUD before". Suppose I sacrifice certain things that would have made my custom client more accessible to my target market in the interests of retaining compatibility with existing generic MUD clients. In that instance am I committing "ad suicide" by making my game less accessible to my target market (people who have never played MUDs before) by trying to make it accessible to another market (people who have played MUDs before)?

What if my target market is very small, appears to be dwindling and is generally dismissive of new players in the market? What do they call it in the retail industry if I decide to stick with that market rather than trying to expand my target audience?

EDIT: Also, if a mod's reading, do you think we could split this discussion off from the original, VT100 thread? Perhaps also split off the David Haley-related bickering. Possible names for the latter thread: "David Failey", "Everybody Hates David", "Assorted MUDBytes Members are from Mars, David Haley is from Venus" and possibly even "David Haley Should Be Featured On Keith Olbermann's "Worst Person in the World" Segment", though I think that might be a little long.

Emphasis mine. There appears to be a very large market for casual games with simple gameplay and a low entry barrier - this is the audience targeted by games like Farmville, for example.

Muds on the other hand (both text-based and graphical) tend to be more hardcore. If you only play them for 5-30 minutes per day then it's unlikely you'll get very far - you typically need to invest many hours.

Taking my mud as an example again (because I've got statistics for it), the 329 "activate players" have a total of 35 years, 135 days and 15 hours playing time. That's an average of around 942 hours per player.

A hundred players putting in 5 minutes per day still only comes up to 8 hours and 20 minutes of real activity. I have individual players who regularly put in more time than that, and I know the same is true for many other muds.

So I think it's very difficult to directly compare the two. Having 100 players who only log on for 5 minutes per day isn't really very desirable for most muds (compared to having a smaller number of players putting in the same amount of time), because they're not usually designed to be played that way.


I think the casual games tend to have a much larger audience of players who put in a lot less time each. I suspect the overall amount of time played is probably fairly comparable though.

Browser games may not be as graphical as full video games, but they do tend to make use of graphics and (occasionally) sound. I think this, along with familiarity (most people are familiar with browsers) and no need to download or install anything (most people already have a browser) are pretty big advantages, but it doesn't guarantee a large game.


It's not, but interestingly enough I've noticed most players get burnt out after a game or two, as each game lasts about a year and it can really take over your life.


My argument is that you don't need to drop telnet in order to have people play through the browser. The argument made earlier was that muds are held back by supporting telnet - yet there's absolutely nothing stopping a mud from supporting telnet and also offering a nice browser client.

Of course there are muds like Archons of Avenshar that only allow you to play through their browser client. But there are others, like Maiden Desmodus or Primordiax that can be played through either a custom browser client or any other telnet client (see the links for screenshots).


Absolutely, and I've voiced the same view on several occasions. But take a look at the Primordiax link I provided above and see what sort of reception it received - simply offering a graphical client doesn't change the nature of your game, and if your mud is primarily text-based then players will still perceive it as a text game. Likewise, take a look at Archons of Avenshar and you'll see that dropping support for other clients has hardly improved its playerbase.

Having a browser client isn't enough, you need to design the gameplay around it if you want to appeal to the browser game market, and that means reducing if not removing the text-based element.




I'm afraid I disagree. Having spent several months designing a GUI I've yet to come up with anything that couldn't be handled through both text and graphics - perhaps the GUI is easier on the eye, and lets you view certain things at a glance, but the same information is there. I'm confident I could even create a fully graphical interface while still leaving the game fully playable through other clients (although that could quickly become a lot of work if I start messing around with animations).


No it doesn't - that's where out-of-band protocols come in. MSDP allows clients to ask for the data they want, and it's sent in subnegotiation sequences that the client can easily read and use.


There is a big difference between saying "For best results, use client X" and saying "If you want to play, you must use client X". I agree with the former, but disagree with the latter.

Yes… that is the position that people were really arguing.


You might count bulletin-board games of old as falling under this category. It's something of a stretch, perhaps, but really any browser-based game uses the generic client approach; it's just that the client happens to be highly malleable with the "style sheet" (I mean more than just CSS here) provided by the server. "Here's a bunch of data, and here's how to render it." It would be kind of like the MUD providing you with a MUSHclient plugin on the fly, I guess.

After reading the forum KaVir linked to as Primordiax, I can happily appreciate this forum. Talk about unwarranted hostility! Even when people here disagree, I feel people would rather work out their differences than fight for the sake of it.

Good job people. :biggrin:

I ended up reading through it also, I think therein lies a tiny portion of the problem at hand.

I would love to see a survey or some good hard data to this effect. I know that the IRE muds having pretty graphical web clients didn't change anything, and in fact ended up alienating some of their users whom tried to use it because they lacked the feature richness of downloadable clients. Does that mean that having a web client is suddenly undesirable? No, it doesn't, but the point I'm making here is that one thing (shiny interfaces) doesn't neccesarialy lead to the other (increased player base).



Not in the strict context, however it was a developer who made successful text games (Achaea, specifically) trying to move into the browser game market, and failing, and thus an example of how success in one, doesn't automatically lead to the other.



Yes, as I prefaced my commentary, I was commenting in general. I think there's this feeling amongst some developers that web clients are some sort of gold rush waiting to happen and whilst they can be an effective tool to lower the barrier to entry, most players end up using the web clients as a stepping stones to downloadable clients.



I think we can both agree here, and my point was that the immediate area of opprotunity is in designing better interfaces rather than reinventing the protocol wheel, so to speak. If the latter is neccesary to do the former, then I could better understand



So when was the last time that a major client shifted with changing playerbases? When was the last time that a MMORPG respeced instead of falling into obscurity? The only example I can think of - Ultima Online shifting from 2D graphics to 3D graphics - doesn't apply as an example of single-client design, because it evolved by forking into a second client, and after that by making the server architecture open to end-users, which allowed the development of third-party clients, such as Iris.



I blame being up at 430 am, by you're correct, its by McConnell. The first quote is on p395 in 17.7 Control Structures and Complexity. The second and third quotes are in 27.4 Evolutionary Delivery, pages 665 and 669 respectively. These are from the first edition, its possible the numbers might be a little different in the second.



Doomed? I tend to think they are, but not at the onset, as you seemed to be concerned with, but rather on the longer-term. See my example and rebuke above, re: Ultima Online. It maintains the player-base it does more than a decade after it's inception, because it has evolved out of the single-client design.

Single-client design becomes an example of what McConnell refers to as "Amundsen planning". You define a single set of requirements. These requirements are inflexible and do not change. There are strengths to this approach - when you do not have changing requirements you have the ability to tailor-make a program that will work specifically to these requirements. But the nature of any multiplayer game is that requirements are transitory and changing.



See Ultima Online, which I cited above (and also earlier in this thread), also third-party clients also exist for Arsheon's Call (or however you spell it), and Everquest.



Emphasis mine to show what Im specifically responding to - No, of course not, but you're reaching more players in allowing evolutionary, open design for multiple clients, than a single client. If I reach out to the mudlet and mushclient communities as well as my own client's, then by definition I'm reaching more players than by only accomodating my own client. By the nature of the MUD being TELNET-based, all of these clients can intrinsically support my MUD. This is the strength of TELNET.



What features would you suggest you could not implement using the current TELNET and TELOPT system? Or what features would be difficult to implement that would be so difficult to implement that it would warrant reimplementing all of an existing TELNET-based MUD? I think KaVir's MushClient GUI is an awesome example that making a great-looking, easy-to-use interface without reinventing the wheel.



You're confusing the issue, though it does highlight the area of confusion amongst programmers. What you're not understanding here is that people who play, say first-person shooters, are very different people who play, say, roleplaying games. They have many different wants and needs in a game. They're two very different markets, and two very different sets of requirements. What you're suggesting in change, wouldn't really be a text game anymore. It would involve text, yes, but it would lose the strength of MUDs: highly-interactive story-based text games involving a lot of players in real-time. MUDs are social environments, as well, which you would lose somewhat in the changes.

I guess there are two points Im making is:

MUDs do have strengths over other games, and we should be careful not to lose them.

and

MUDs and more graphical games have very different markets and very different player bases.



I giggled.

I must admit I'm kind of disappointed with David's posts. He's an obviously intelligent person whom I respect on that token, but he's lowered himself to some fairly obvious trolling, and that saddens me. And it saddens me further that it's caused his valid points, to be lost, on myself and others, because we end up emotionally responding to his ad hominen arguments.

It is pretty pathetic when a discussion in good faith takes the turn for the worse and certain characters feel the need to stoop to baseless insults. David, when did you stop beating your wife? Frankly, David is a consistent good actor in this forum. He takes positions with careful thought. I often find myself on the other side of David's opinion but I've never seen him offer it in bad faith. Its a little sad that a relative new comer here feels the need to take this low road on a top contributer. I'm not sure any rational person could come to the conclusion that David is trolling this thread. Unless disagreeing is the new trolling. I would be more disappointed but for that to happen you'd have to expect more out of someone.

On the contrary, when I was regularly playing one of the IRE games and they posted their Flash client on Kongregate, I (and other players) noticed a significant increase in the number of new characters being created. Quite a few (probably not as many as they'd hoped) kept playing after completing the introduction. Having said that, IRE's web client is (or was, the last time I looked at it) not an attempt to replace a robust downloadable client, but more of a gateway to allow people to experience the game before committing time and energy into getting a "proper" client. As you point out, it lacks features - I don't really consider it an excellent example of a single-purpose MUD client.


We can speculate all day on why Earth Eternal failed, but given that it was a graphical game, not a text-based game, I don't think it's entirely relevant to the argument I was making, which was that browser-based text games are doing quite well - often better than the most popular MUDs.

A text game is a browser game if it can be played through a browser. I see no point in making a distinction between the two. In fact, I might even go so far as to argue that a game like Urban Dead is, in fact, a MUD that is only playable through its single-purpose browser client. Take a look at this screenshot.


Once again, we're talking about single-purpose clients here. Ultima Online is a perfect example, because it built a new single-purpose client to deal with its changing playerbase. As for the third-party client… some users felt that the existing client didn't suit their needs, so they built their own client. I assume that it's dedicated to connecting to Ultima Online - if it is, then it is simply another single-purpose client. I'm not saying that, faced with a decision to write a new single-purpose client or let their game die, developers should choose the latter. I'm not saying you should be entirely closed and make it difficult/impossible for users to write their own stuff if they don't like what you've provided. I'm simply arguing the virtues of a single-purpose client (of which UO has three) over a more generic solution. I can't imagine that a client capable of connecting to UO and, say, DAoC that presented the two games in the exact same way would provide an enjoyable experience for either game.

Incidentally, Dark Age of Camelot is an example of a game with a single-purpose client (and I'm not sure that they've changed the client) that has retained a decent playerbase, despite now being 9 years old. EVE Online - 7 years old - continuously improves its client, and it looks (graphically) like it could've been released this year. Once again, it uses a single-purpose client and it's only ever had one.

Finally, all games fall into obscurity eventually. They get replaced by the Next Cool Thing. Companies don't then decide to completely overhaul their existing products in order to compete - they just go ahead and make their own Next Cool Thing and the cycle continues. MMOs and MUDs are unusual in their longevity which is due in no small part to the ongoing nature of their gameplay.


Once again, a single-purpose client (not a single client) is not necessarily the inflexible, unchanging beast that you're painting it as. Ultima Online, again, is a great example of this. Once again, no-one has argued that you should make your single-purpose client and then never change it ever, even if not improving it kills your game.


Quixadhal gave an excellent example in post #89 of this thread. Removing Telnet support from MUDs that already support it is not something I've been advocating, but I have been asking the question (and I've yet to get a response):



Now, it so happens that I do care whether users can use a traditional MUD client or not, but can you see why the question is a valid one? Writing a custom client/server handshake sequence and then using XML, JSON, YAML or something to format your packets is a lot simpler than implementing a full-on Telnet state machine, implementing all the basic stuff that does with it (NAWS, TERMTYPE, etc) and then having to navigate the treacherous waters of things like MXP, MCCP, and other MUD-specific protocols.


No. What I've been trying to say is that I believe there are a large number of people who enjoy text-based games who aren't playing MUDs. I think my belief is backed up by the figures I posted w.r.t. text-based BBGs earlier. A lot of these people probably aren't aware that MUDs exist. I think, however, that some (perhaps many) of them have tried MUDs and have been turned away by the number of hoops you have to jump through to start playing your typical MUD, or they've been discouraged by the archaic wall-of-monospaced-text interface that the typical MUD provides, or they've tried something like the IRE web client (which is really the same wall of text interface with a pretty border) and they simply haven't enjoyed it.


I suspect this post wasn't aimed at me, but I'd like to clarify anyway that my comments regarding Mr. Haley were made in jest. Perhaps I should've added one of those </sarcasm> tags.


Technically true, of course, but given the extent of control the server has over what's displayed in the browser, I'd hyberbolically liken this to suggesting that an operating system is a generic client for playing graphical MMOs.


I wasn't really interested in this thread until it got derailed. Nonetheless, I still think this thread should be split into the VT100 part and the omgwtfbbq-Telnet-sucks part.

Well, the interesting thing here is that while I see that your comment was stated as being hyperbolic/funny, imagine what it would be like if, indeed, you connected to a server and it fed bytecode down the line that allowed you to play its game on your computer which consisted initially of just the host OS that interprets this bytecode and provides an environment in which to operate (network/graphics/sound libraries, etc.). Let's ignore security for a moment here. Isn't this just a natural extension of the browser approach, except that instead of sending data along with a presentation style sheet, that must be rendered according to some standard (HTML+CSS, Flash, whatever), you are sending actual rendering instructions?

I don't think there's much future in this particular idea because it's too pie-in-the-sky, and the security concerns I ignored for a moment are in fact debilitating. Still, as a general comment on software and cloud computing, with browsers becoming very thin clients to richer and richer applications, there's some thinking to be done here. Let's go back to something more realistic, like a MUD sending a Lua plug-in down the line for MUSHclient to install and activate. Wouldn't this be interesting? The client could then become a "generic client" that loaded up specialized clients. As long as you speak "MUSHclientcode" (its scripting environment, its API, etc.) you could produce a customized environment for any player who used this client, without them needing anything other than the client. I view it as somewhat analogous to a web server sending HTML and CSS, although again we'd be sending rendering instructions rather than data+presentation.

There's clearly a reason why generic clients like Flash players and web browsers exist. But there's also, clearly, a reason why people stopped using telnet and BBSs to get information and started using browsers. Genericity in and of itself is not a sufficiently useful goal. It must serve a purpose. A generic client that does a poor job at playing a game will not be as popular as a special-purpose client that does a good job at playing the same game.

I have a more or less blanket agreement with the rest of the post, so instead of adding "+1" to each point I'll just say it this way. :smile:

I cannot remember seeing any actual evidence that the bulk of the posters who derailed this thread actually do any implementation themselves. At least Kavir and myself post screenshots of our efforts, in addition to descriptions of our experiments.

When I started reading this thread, I saw in Kavir's posts what makes MUD development enjoyable for myself. A willingness to explore the possibilities of a particular tool. This was quickly quashed with a barrage of meta-discussion on the same old topics that people have been achieving nothing with for the last decade. What is the future of MUDs? In an ideal world (when neither the poster nor their respondents are actually going to do anything like what they propose others should do) how should it be done and therefore why is it pointless to continue with the productive efforts underway here-to-fore?

If forum administration followed a consistent pattern here, the discussion not related to VT-100 development should have been moved out into a separate thread so that those of us who were actually interested in it and not interested in negative sophistry could share a common interest in making the most of an interesting tool.

It's also a possibility that different things about MUD development are enjoyable for different people. I'm not sure it's entirely fair to say "hey, I don't like it, just me myself and I personally, therefore you all are idiots behaving stupidly".

Perhaps the reason this topic hasn't achieved anything in the last decade is that nobody is willing to actually have the discussion beyond a certain point?

There seem to be two camps here. One camp thinks the old ways are just fine, and simple refinement is all that's needed to keep text gaming alive and well. The other camp thinks the old ways are what is actually holding text gaming back, and relegating it to a lingering death as the rest of the world moves further away. It's probably pretty clear which camp I'm in. :blues:

The addition of a vt100 interface is a step towards the modern era, but it's only a baby step. It does two things. It offers the developer a bit more layout control over their content, and it limits the potential audience from those who have TELNET clients, to those that have TELNET clients which also properly support VT100 terminal formatting.

My own argument is that this is nice, but ultimately not worth the effort. MUD's already have a very tiny audience. Adding additional limitations will only make that audience even smaller, because no NEW customers are enabled by this. Unlike 1990, in 2010 the gaming community expects the go to a web site, download a game client, click install, click run, and be in the game. They do NOT expect one game client to work for multiple games. They do NOT expect to have to spend hours customizing their client so the right things end up in the right places of the UI. Having a new client/server protocol, designed by and for the game using it, makes sense for a game being developed or launched in 2010.

I'm not saying every MUD out there should restart from scratch. If you're happy with what you have, good! I'm not saying everyone needs to roll their own brand-new protocol from scratch either. If someone designs one that works well, and they make it an open spec, others can always start from there and modify it to suit their own needs. Right now, MUD developers are spending time conforming to a standard that was never designed for their games, and frankly is a poor fit in today's internet world. I think it shows.

So, while I applaud KaVir's experiment and think it's cool, I also think a custom client is the way forward for NEW games.