12 Oct, 2010, Rudha wrote in the 1st comment:
Votes: 0
David Haley said:
Yes and no. MUSHclient for instance doesn't support it much at all (Nick has some reasons for explicitly choosing to not support it, like how it makes triggers and logging be very difficult or even almost nonsensical). I think that Zugg's clients and tt++ support it to some extent; however as Scandum noted above support is partial in tt++. He would be able to answer much better what the exact caveats are.

In general I think that it's a poor solution for what people are trying to do here, dated back to decades ago when we only had dumb terminals. Nowadays I think it makes far more sense to send the data using some kind of out-of-band method and having the client render it in some appropriate fashion (like what people have been doing with MUSHclient). All of that said, of course, the vt100 method "just works" without client plugins, assuming client support in the first place of course.


There's a lot to be said for "works out of the box", but I don't really know of a smarter way to do some of the things I want to do that wouldn't rely on client rendering. To me, the more I can do on the server end, the better, because that means more of the game interface elements are standardised across different clients, which is a Good Thing(TM)

Maya/Rudha
12 Oct, 2010, David Haley wrote in the 2nd comment:
Votes: 0
Rudha said:
To me, the more I can do on the server end, the better, because that means more of the game interface elements are standardised across different clients, which is a Good Thing(TM)

In that case you are limiting the game interface elements rather drastically, which is of course a decision that is yours to make. Personally I would find that limitation to be quite unacceptable, especially since relatively few clients support the server-aided text-only cursor rendering in the first place.
12 Oct, 2010, Runter wrote in the 3rd comment:
Votes: 0
I suppose the argument is that most muds don't need those game interface elements. I find it a little absurd how much time mud developers are willing to spend working on servers and yet how obtuse they become when presented with relatively light client side work. Client side work that every other facet of gaming has come to expect. I'd toss the need to support any and every client in the trash ideas bin. Maybe that's true if your target audience is the hand full of players left (or ever had been) that still use and must use the dumbest of clients. There is nothing wrong with featuring and even requiring a specific client or plugin.
12 Oct, 2010, Rudha wrote in the 4th comment:
Votes: 0
Runter said:
I'd toss the need to support any and every client in the trash ideas bin. […] There is nothing wrong with featuring and even requiring a specific client or plugin.


When MUDs were in their heyday and had a very large user base, I would probably agree with you, however in a day where a userbase is increasingly smaller, and things are becoming more fragmented between clients and such, this becomes a difficult rationale for me to accept.

I do eventually plan to write my own client for Elvenblade. Even when that comes to pass, I expect many people will stay with whatever client they are currently using (this is one of the initial things which dissuaded me, fairly strongly, from doing it, but at this point I want to do it just to have a base client which I can basically design the server towards.) I can't say I understand why, but people seem to get almost religiously devoted to clients, MushClient and zMud in particular have some fairly zealoty userbases in my experiences. Getting those kinds of people to adopt a new client is challenging, at best. I liken it to getting Linux or Mac zealots to use Windows: they might do it, in circumstances where they need to, but they'll not like it, and if you force them to do it, they'll probably be resentful towards you for it.

David Haley said:
In that case you are limiting the game interface elements rather drastically, which is of course a decision that is yours to make. Personally I would find that limitation to be quite unacceptable, especially since relatively few clients support the server-aided text-only cursor rendering in the first place.


I'm not sure why you seem to think that these two things (client GUIs and server GUIs) are mutually exclusive. Where clients support TERMTYPE, it is fairly trivial to detect if A: they are capable of VT100 emulation and B: if they have better support in place. Some (zMud) have better GUI options. Others (TinyFugue, TinTin++), really don't. Though VT100 may not be an option for TF, since it's support seems sketchy at best.

Maya/Rudha
12 Oct, 2010, Runter wrote in the 5th comment:
Votes: 0
Funny. I think having less players in the community currently makes it the perfect time to not cater to them. I think having 10 players and 0 players is functionally the same thing. The reason muds are less popular is because would be gamers are off playing games that don't support vt100 generic clients to connect.
13 Oct, 2010, David Haley wrote in the 6th comment:
Votes: 0
Runter said:
Funny. I think having less players in the community currently makes it the perfect time to not cater to them.

QFT. Why bother chasing after a demographic that hardly exists in the first place? Other games seem to have success orders of magnitude larger with single-purpose clients…

Rudha said:
I'm not sure why you seem to think that these two things (client GUIs and server GUIs) are mutually exclusive. Where clients support TERMTYPE, it is fairly trivial to detect if A: they are capable of VT100 emulation and B: if they have better support in place. Some (zMud) have better GUI options. Others (TinyFugue, TinTin++), really don't. Though VT100 may not be an option for TF, since it's support seems sketchy at best.

A GUI implemented with modern graphical elements is not at all the same as one implemented using text-only interfaces. I didn't say that they were mutually exclusive. I said that one is superior to the other…
13 Oct, 2010, Rudha wrote in the 7th comment:
Votes: 0
David Haley said:
QFT. Why bother chasing after a demographic that hardly exists in the first place? Other games seem to have success orders of magnitude larger with single-purpose clients…


That they have a single client is not the only variable in this equation, this isn't a simple cause/effect relationship, and many games that part from this still are successful. For example, Ultima Online has the official 2D client, the official 3D client, and an unofficial 3D client (Iris). It remains a large playerbase to this day.

Maya/Rudha
13 Oct, 2010, chrisd wrote in the 8th comment:
Votes: 0
Rudha said:
David Haley said:
QFT. Why bother chasing after a demographic that hardly exists in the first place? Other games seem to have success orders of magnitude larger with single-purpose clients…


That they have a single client is not the only variable in this equation, this isn't a simple cause/effect relationship, and many games that part from this still are successful. For example, Ultima Online has the official 2D client, the official 3D client, and an unofficial 3D client (Iris). It remains a large playerbase to this day.

Maya/Rudha


David said "single-purpose", not "single". Of course, Ultima Online clients are single-purpose.

I note with interest that many of the top MUDs on mudstats.com appear to have custom, single-purpose clients. Then again, many do not, and some that do also allow the player to connect with a standard MUD client.
13 Oct, 2010, KaVir wrote in the 9th comment:
Votes: 0
chrisd said:
David said "single-purpose", not "single". Of course, Ultima Online clients are single-purpose.

He did, but it was in agreement with Runter's suggestion that "…having less players in the community currently makes it the perfect time to not cater to them", which was a followup to his earlier suggestion that "There is nothing wrong with featuring and even requiring a specific client or plugin".

So we appear to be discussing two approaches in this thread:

1) Muds should offer a specific client or plugin, but allow players to use others if they wish.

2) Muds should offer a specific client or plugin, and not allow players to use anything else.

The first approach is one of passive support for all clients - you encourage people to use your client, but allow them to use other clients if they prefer, with the understanding that their experience may not be as good if they don't follow your recommendation.

The second approach is one of intentional non-support for other clients - if players wish to play your mud, they must use your recommend client.

I can see arguments for and against both approaches, but personally I favour the first, and it does seem to be the most popular solution among the large muds - with some major exceptions, such as Simutronics and Skotos. Interesting to note that these same muds also use the same philosophy for transactions - required payments, as opposed to the encouraged payments used by most modern commercial muds (but perhaps this is just a coincidence and I'm reading too much into it).
13 Oct, 2010, David Haley wrote in the 10th comment:
Votes: 0
KaVir said:
He did, but it was in agreement with Runter's suggestion that "…having less players in the community currently makes it the perfect time to not cater to them", which was a followup to his earlier suggestion that "There is nothing wrong with featuring and even requiring a specific client or plugin".

Am I beholden to everything Runter has said as soon as I agree with one particular point that I explicitly refer to? :wink:

I happen to agree that there is nothing wrong with featuring a specific client/plugin. I also happen to agree (albeit less strongly) that it's ok to require a specific client/plugin. But thirdly, I also happen to believe that that is a separate question from the one I was specifically referring to, namely that there seems to be a very strong correlation in the gaming world between single-purpose clients and popular games. (And yes, as Chris pointed out, the difference between 'single' and 'single-purpose' should not be ignored.)

In other words, you can still be on the fence regarding the question, "should I require it or not?", while at the same time having an answer to the question, "do I want to provide a single-purpose client or not?".

KaVir said:
Interesting to note that these same muds also use the same philosophy for transactions - required payments, as opposed to the encouraged payments used by most modern commercial muds (but perhaps this is just a coincidence and I'm reading too much into it).

Yes, I think this is just a coincidence. One could easily have optional transactions with a required client or required transactions with an optional client. Of course if your client can handle the transactions for you directly, you might prefer to require that client, but that says nothing about whether or not those transactions are in fact required.
13 Oct, 2010, Rudha wrote in the 11th comment:
Votes: 0
JohnnyStarr said:
VT100 Energy Bar, Mmmmmmmmmmmmmmmmmmmmmmmmmm

YUMMY!


Get thee hence, oh bearer of topics! Thou'rt ne'er welcome here! *

David Haley said:
Am I beholden to everything Runter has said as soon as I agree with one particular point that I explicitly refer to?


It was establishing context beyond the last post, as I read it, more than saying anything of that matter.

KaVir said:
I can see arguments for and against both approaches, but personally I favour the first, and it does seem to be the most popular solution among the large muds - with some major exceptions, such as Simutronics and Skotos.


I'm strongly in agreement. I wouldn't expend too much energy on support beyond things in my own client I intend to develop, but at the same time, expending effort to break compatibility with other clients, as some MUDs have (GemStone comes to mind) seems to me to be as much wasted energy as it is to bend over backwards supporting every TELOPT out there, or something.

Maya/Rudha


(* Disclaimer: I'm obviously being facetious here, in case someone missed that.)
13 Oct, 2010, David Haley wrote in the 12th comment:
Votes: 0
Rudha said:
but at the same time, expending effort to break compatibility with other clients, as some MUDs have (GemStone comes to mind) seems to me to be as much wasted energy as it is to bend over backwards supporting every TELOPT out there, or something.

Yet is this not precisely what the successful games out there – read games, not MUDs – have done? I'm not saying that it is definitely the right thing to do, but it is food for thought at the least…
13 Oct, 2010, Scandum wrote in the 13th comment:
Votes: 0
It's really a result vs effort thing. MSDP is easy to implement, and if you let your players write the interface scripts the potential pay off is quite big. VT100 interfaces are fast and relatively easy to implement and don't require a download. Writing a good client is a ton of work that might be better spend developing the actual game, especially when you're mostly displaying text.

It seems silly to me to compare graphical games with text games. It'd be like trying to compare books and movies, and suggest that bookstores should adopt the netflix approach, or to build special theaters where people can gather and read newly released books at the same time.
14 Oct, 2010, quixadhal wrote in the 14th comment:
Votes: 0
A point I've tried to make repeatedly is that if the game developer controls the client, they have the creative control to ensure the user experiences the game the way it is intended to be experienced. This lets the builders and developers work together towards the goal of making the game, rather than having to impose artificial limits on both their code AND their content to make sure it will still be playable by the guy who refuses to leave his actual 1980's vt220 terminal.

Now, if you want to ALLOW fans to create their own clients, you can use industry standard transports (such as JSON/XML/etc) or roll your own and document it fully. Just make it clear that the game is designed for the intended client, and if you use someone else's, no complaining to the MUD admins if things don't look or work properly.

This community has bent over backwards to cling to TELNET in the hope of somehow retaining its ever-shrinking player base for the glorious day when the magic text faeries will come and bring a resurgence of players to the genre. While we're all puttering around with TELOPTS and ANSI, people out there are making very simple games that reach audiences that are orders of magnitude larger than ours ever was.

As examples, I can point to Farmville – a stupidly simple facebook game which could easily be implemented by a MUD with a custom client to do tile graphics, and Minecraft – a virtual lego game that has sold 400,000 copies while still in ALPHA-testing, at $14 a pop.

So, as 2010 comes to a close, and Windows 7 removes native telnet from the hands of another generation of potential players, will we continue to keep the vacuum tube AM radios humming, or perhaps consider stepping into the 21st century and try something new? I suspect the little old guy who invested in the vacuum tube warehouse is hoping those AM radios will make a comeback too.
14 Oct, 2010, KaVir wrote in the 15th comment:
Votes: 0
quixadhal said:
This community has bent over backwards to cling to TELNET in the hope of somehow retaining its ever-shrinking player base for the glorious day when the magic text faeries will come and bring a resurgence of players to the genre.

As opposed to dropping telnet support and suddenly being inundated by millions of new mudders who were just waiting for you to change to another protocol, despite it having absolutely no impact on their gameplay.

If you think telnet is the problem, just because there are non-telnet games that are more popular, then more power to you. If you think that muds should turn into fully-graphical single-player games, just because some of those games are more popular than muds, then do it. If FarmvilleMUD is so easy to implement and represents the future of mudding, then go ahead and create it.

Where is your mud, quixadhal? If you want to convince me to discard telnet and the years of work that have gone into clients and protocols, I first want to see how many players you've got, so that I can see how well you understand the market.
14 Oct, 2010, Runter wrote in the 16th comment:
Votes: 0
Quix, why do you hate muds so much?
14 Oct, 2010, quixadhal wrote in the 17th comment:
Votes: 0
KaVir said:
quixadhal said:
This community has bent over backwards to cling to TELNET in the hope of somehow retaining its ever-shrinking player base for the glorious day when the magic text faeries will come and bring a resurgence of players to the genre.

As opposed to dropping telnet support and suddenly being inundated by millions of new mudders who were just waiting for you to change to another protocol, despite it having absolutely no impact on their gameplay.


No impact, other than it making those new players not want to bother trying the game, because they don't want to screw around with having to find and setup a client. No impact, other than no MUD out there being willing to use anything more than ANSI graphics, because attempting to move beyond them doesn't work for most existing clients. Yes, I know about MXP, but show me a MUD that actually uses it for more than cosmetic fluff. They can't, because they won't require all their players to have MXP compatible clients.

The fact is, neither of us can cite examples of what text games MIGHT evolve into, because they REFUSE TO EVOLVE.

KaVir said:
Where is your mud, quixadhal? If you want to convince me to discard telnet and the years of work that have gone into clients and protocols, I first want to see how many players you've got, so that I can see how well you understand the market.


"Until I see other tribes making use of this "wheel" thing, I'm gonna say it's a waste of time and stick to dragging stuff on skins. Our ancestors put a lot of time into figuring out how to weave ropes and make frames so those skins would last longer."

Even if I were to put the time into making a new engine that worked more like a modern MMO but was still a text game (never did I say MUD's should become fully graphical), I suspect it would be dismissed by many here as "not a MUD".

Runter said:
Quix, why do you hate muds so much?


It ain't the muds that I hate. It's the deep rut that they've been driven into.
14 Oct, 2010, Bobo the bee wrote in the 18th comment:
Votes: 0
quixadhal said:
No impact, other than it making those new players not want to bother trying the game, because they don't want to screw around with having to find and setup a client. No impact, other than no MUD out there being willing to use anything more than ANSI graphics, because attempting to move beyond them doesn't work for most existing clients. Yes, I know about MXP, but show me a MUD that actually uses it for more than cosmetic fluff. They can't, because they won't require all their players to have MXP compatible clients.


So, to understand 'no MUD out there being willing to use anything more than ANSI graphics (not true: the MUD I've been idly roleplaying on the past two months has something like 60 colors, and I just coded in something into SmaugFUSS that'll allow builders to – potentially, though it won't be the case in reality – use any HTML color they want to in their areas) but then you dismiss those who employ MXP / Pueblo as 'nothing but cosmetic fluff' when, you know, the lack of color you complain about is just 'cosmetic fluff'?

quixadhal said:
The fact is, neither of us can cite examples of what text games MIGHT evolve into, because they REFUSE TO EVOLVE.


They do evolve, though, but not in the leaps and bounds other forms of video games do. Why? Well, for one, they are text-based which puts them at a permanent disadvantage to every other game out there: the general population _does not_ want to "read" in their past-time, and if they do it is generally spent reading books, which are an entirely enjoyable thing to read if you find ones you like, and - y'know what? - there's a lot of books out there. Why, I bet if, whenever I wanted to read a book, I could go find one I hadn't read every single time and not have to repeat!

Secondly: money. MUDs are, and probably mostly always will be, very casual things, coded by people who can only give it the time of a hobby when managing and building a game requires so much more. If we all could conceivably make a living writing a MUD I think you'd see a lot more development out there in an effort to get the leg-up on the competition.

Thirdly: most people out there who honestly have the knowledge and patience to build a MUD have already done so, so they spend their time either tweaking with what they have already found to work for the players that they have and the players that they generally attract, and why change the winning formula? Especially when, as KaVir notes, you're likely to drive away all your supporters just for hoping you'll get more in the new markets. No, I think that innovation needs to come from those who dont have MUDs yet, people like me. I have very, very ambitious goals for my MUD and I hope to draw in things that I love about MUDs I've grown up on and many different elements of popular video games over the past 10 years, too. I think many MUDs fall into the problem of being too much of the same, sure, but if one needs ideas of how to add features people will like they should look no further than the rest of the gaming industry. You don't need fancy graphics to attract players, you need innovative gameplay because that, over anything else, is what will keep people who care about the X's and O's of mudding playing your game.

Quote
Even if I were to put the time into making a new engine that worked more like a modern MMO but was still a text game (never did I say MUD's should become fully graphical), I suspect it would be dismissed by many here as "not a MUD".


Suspicions are such easy things to have that it's nice that most of them are wrong.
14 Oct, 2010, bbailey wrote in the 19th comment:
Votes: 0
quixadhal said:
KaVir said:
quixadhal said:
This community has bent over backwards to cling to TELNET in the hope of somehow retaining its ever-shrinking player base for the glorious day when the magic text faeries will come and bring a resurgence of players to the genre.

As opposed to dropping telnet support and suddenly being inundated by millions of new mudders who were just waiting for you to change to another protocol, despite it having absolutely no impact on their gameplay.


No impact, other than it making those new players not want to bother trying the game, because they don't want to screw around with having to find and setup a client. No impact, other than no MUD out there being willing to use anything more than ANSI graphics, because attempting to move beyond them doesn't work for most existing clients. Yes, I know about MXP, but show me a MUD that actually uses it for more than cosmetic fluff. They can't, because they won't require all their players to have MXP compatible clients.

The fact is, neither of us can cite examples of what text games MIGHT evolve into, because they REFUSE TO EVOLVE.

KaVir said:
Where is your mud, quixadhal? If you want to convince me to discard telnet and the years of work that have gone into clients and protocols, I first want to see how many players you've got, so that I can see how well you understand the market.


"Until I see other tribes making use of this "wheel" thing, I'm gonna say it's a waste of time and stick to dragging stuff on skins. Our ancestors put a lot of time into figuring out how to weave ropes and make frames so those skins would last longer."

Even if I were to put the time into making a new engine that worked more like a modern MMO but was still a text game (never did I say MUD's should become fully graphical), I suspect it would be dismissed by many here as "not a MUD".

Runter said:
Quix, why do you hate muds so much?


It ain't the muds that I hate. It's the deep rut that they've been driven into.


I'm having trouble figuring out just what the fuck you're on about, Quix. You want the muds to evolve. You don't say the games should be fully graphical. You exalt the virtues of "more than ANSI graphics", but dismiss some usage of MXP to achieve this as 'cosmetic fluff'.

So you don't seem to want the status quo, you don't seem to want (or like) middle grounds that are 'cosmetic fluff', and you don't seem to want fully graphical games. Why do you hate MUDs, Quix?
14 Oct, 2010, David Haley wrote in the 20th comment:
Votes: 0
Bobo the bee said:
Quixadhal said:
Even if I were to put the time into making a new engine that worked more like a modern MMO but was still a text game (never did I say MUD's should become fully graphical), I suspect it would be dismissed by many here as "not a MUD".


Suspicions are such easy things to have that it's nice that most of them are wrong.

People on here have, in the past, had rather fixed and narrow ideas of what exactly MUDs are; Quix is probably right, on this point at least. When you start talking about separate windows for things like inventory with dragging and dropping, people always seem to crop up to complain about how it's not a MUD anymore. Heck, the whole debate about MUD clients shows this: some people get antsy when you're not talking about supporting every client out there because a MUD is by definition to these people something that can be played with clients from 20 years ago.
0.0/126