18 Oct, 2010, Runter wrote in the 101st comment:
Votes: 0
Careful there quix. Trolling is against the rules.
18 Oct, 2010, Bobo the bee wrote in the 102nd comment:
Votes: 0
quixadhal said:
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.


They also expect one thing that MUDs will never offer: fancy graphics. In my mind, any way to NOT strictly compete with the larger games that will always draw a majority of the market is something most MUDs really need to look into: they do this by finding their niches which, right now, mostly constitutes appeasing the population that doesn't want to have multiple clients to play the games they play. Most people I talk to on MUDs have played many different games, and asking them to download a new client for each game will restrict the interaction between the community and will, I think, lead to more direct competition between those games in which you "download a game client, click install, click run, and be in the game," in which, to most audiences, text-based games do not and will not compare favorably most of the time. Further, requiring a specific client means you need to develop for multiple OSes, keep that client updated, and for games that generally only have one or two coders that really isn't applicable.

While I won't say that it doesn't make sense for some games, to develop more complex protocols that restrict people to using 'my' client, I can say that I don't think this is the case for most situations, and in any case a protocol does not a game make. I find myself able to do everything I want to be able to do in my code with the protocols that you consider "old" methods that have been around for awhile, so why should I start from scratch, especially when I can use a highly customizable, free client like MUSH that is widely known and used to promote a specific layout of the MUD, like what KaVir has done with such good documentation?
18 Oct, 2010, KaVir wrote in the 103rd comment:
Votes: 0
quixadhal said:
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.

What do you consider to be the advantages of a downloaded custom client compared to a downloaded custom plugin for an existing mud client?
18 Oct, 2010, Dean wrote in the 104th comment:
Votes: 0
*One less thing for the user to download.
*Better game specific support.
18 Oct, 2010, KaVir wrote in the 105th comment:
Votes: 0
Dean said:
*One less thing for the user to download.

Nothing (other than laziness) is stopping me from distributing MUSHclient with my plugin preinstalled.

Dean said:
*Better game specific support.

Can you give an example?
18 Oct, 2010, David Haley wrote in the 106th comment:
Votes: 0
Bobo said:
They also expect one thing that MUDs will never offer: fancy graphics.

Well, yes, except that that's not always the case. Just take a look at Minecraft; very primitive graphics, yet a massively huge success by indie standards.

Bobo said:
Further, requiring a specific client means you need to develop for multiple OSes

That is true. But it's also true that if you want to use terminal features or any kind of MUD protocol, you need to develop for multiple clients.

Bobo said:
I find myself able to do everything I want to be able to do in my code with the protocols that you consider "old" methods that have been around for awhile, so why should I start from scratch, especially when I can use a highly customizable, free client like MUSH that is widely known and used to promote a specific layout of the MUD, like what KaVir has done with such good documentation?

I don't think people are saying that you must start from scratch. However, if you say that you'd be using MUSHclient with a particular plugin to implement a particular vision without which your game does not behave the way you want, then you have essentially adopted the single-purpose client approach. (Since there was some confusion about this earlier, this is specifically single-purpose. Clearly you could write some other client to speak the same protocol and render stuff.) If you took the MUSHclient-with-plugin application and tried to connect to another game, you'd lose all of the customization.

KaVir said:
Nothing (other than laziness) is stopping me from distributing MUSHclient with my plugin preinstalled.

Yes. But now you're shipping what is a basically a customized client, albeit only a lightly customized one.

Regarding better game-specific support: you can tailor the whole client interface around a game, and not just the miniwindows. The entire menu framework can be adapted, for example.
18 Oct, 2010, Tyche wrote in the 107th comment:
Votes: 0
KaVir said:
Dean said:
*Better game specific support.

Can you give an example?


You have given a few examples concerning key definitions and input echoing in this post:
http://www.mudbytes.net/index.php?a=topi...

Mushclient with its plugin support, necessarily puts limits and restrictions on what you can do.
The trade-off being that a ton of functionality/work has already been done that you would have to create for a custom client.
18 Oct, 2010, Bobo the bee wrote in the 108th comment:
Votes: 0
David said:
I don't think people are saying that you must start from scratch. However, if you say that you'd be using MUSHclient with a particular plugin to implement a particular vision without which your game does not behave the way you want, then you have essentially adopted the single-purpose client approach. (Since there was some confusion about this earlier, this is specifically single-purpose. Clearly you could write some other client to speak the same protocol and render stuff.) If you took the MUSHclient-with-plugin application and tried to connect to another game, you'd lose all of the customization.


Quixadhal said:
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.


I speaking specifically about writing up new protocols for the client and game interaction, not using existing ones that clients have support for (like MXP with MUSH or z/CMUD). Also, Quix did stress the point that he didn't see configuring MUSH to be enough, in his mind, to really draw people in – or, rather, that he thought rewriting custom Client/Server protocols that were specific for your game was a necessity, and therefor making it so your game had to be used with a specific, custom client was necessary. I'm re-asserting that I don't think that is necessary to encourage expansion for the player-pool.

And yeah, Minecraft doesn't have fancy graphics but they are still substantially more than what I'd see a MUD using anytime soon, and if they were any weaker then I think a fair number of the 400,000 who have bought it would be turned off by 'em.
18 Oct, 2010, Ssolvarain wrote in the 109th comment:
Votes: 0
Is telnet even installed/enabled in win7? I know it was a downright bitch getting it to work on Vista at all.
19 Oct, 2010, Rudha wrote in the 110th comment:
Votes: 0
donky said:
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.


I doubt we will see people making these suggestions willing to take the scientific approach and test their thoughts by experiment, though I personally would like to see the heady idealism put to some realistic tests.

Maya/Rudha
19 Oct, 2010, David Haley wrote in the 111th comment:
Votes: 0
Rudha said:
I doubt we will see people making these suggestions willing to take the scientific approach and test their thoughts by experiment, though I personally would like to see the heady idealism put to some realistic tests.

You just can't help yourself, can you? Haven't you had enough fun yet? :sad:
19 Oct, 2010, Rudha wrote in the 112th comment:
Votes: 0
David Haley said:
You just can't help yourself, can you? Haven't you had enough fun yet? :sad:


We can speculate until the world ends, that doesn't accomplish anything; what accomplishes something is putting those thoughts to the test.

Maya/Rudha
19 Oct, 2010, quixadhal wrote in the 113th comment:
Votes: 0
KaVir said:
quixadhal said:
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.

What do you consider to be the advantages of a downloaded custom client compared to a downloaded custom plugin for an existing mud client?


As I've tried to say several times now, the main advantage is that the game developer KNOWS what the client is capable of, and can extend that capability on their own terms to handle any future needs or ideas. Because the client is doing the rendering (text, graphics, hieroglyphs, whatever), the server doesn't have to do the work of (a) formatting and processing output for a client which may or may not correctly display it, and (b) track output state in case the user wants to pause (pagers) or redraw the screen.

A custom plug-in over TELNET can work, but it requires a lot of extra effort (the server still has to format and track everything), and if you extend things beyond cosmetics, your players will be required to use the custom plugin anyways – negating any advantage to sticking with TELNET.
19 Oct, 2010, David Haley wrote in the 114th comment:
Votes: 0
quixadhal said:
A custom plug-in over TELNET can work, but it requires a lot of extra effort (the server still has to format and track everything)

I don't really understand why you say this. If a server happens to be talking to a client over telnet, it doesn't have to format/track anything beyond what it actually wants to send. It can send all of its data using OOB protocols and nothing over the main channel. This would require the same amount of work (gather data, package data, send data) as using AwesomeNewProtocol. It's still telnet, technically, although clearly it will be useless to a plain old telnet client.

When you say "telnet" here, do you really mean something that sends data such that a plain telnet client will be able to render it?
19 Oct, 2010, chrisd wrote in the 115th comment:
Votes: 0
Rudha said:
I doubt we will see people making these suggestions willing to take the scientific approach and test their thoughts by experiment, though I personally would like to see the heady idealism put to some realistic tests.

Rudha said:
We can speculate until the world ends, that doesn't accomplish anything; what accomplishes something is putting those thoughts to the test.

Yes, it's a pity no-one's managed to knock together a successful MUD with an innovative single-purpose client in the week since this thread was started.
19 Oct, 2010, jurdendurden wrote in the 116th comment:
Votes: 0
Ssolvarain said:
Is telnet even installed/enabled in win7? I know it was a downright bitch getting it to work on Vista at all.


No, but it's pretty easy to enable in 7 (Not sure what you had to do in Vista… I ditched that O/S like a rotten apple), you just go to programs/features and enable it there.
19 Oct, 2010, Davion wrote in the 117th comment:
Votes: 0
jurdendurden said:
Ssolvarain said:
Is telnet even installed/enabled in win7? I know it was a downright bitch getting it to work on Vista at all.


No, but it's pretty easy to enable in 7 (Not sure what you had to do in Vista… I ditched that O/S like a rotten apple), you just go to programs/features and enable it there.


It's the same for Vista! There's some cool stuff in that enable programs/features! ;). Anyways, the specific way is Control Panel -> Programs And Features -> (left column) Turn Windows features on or off
19 Oct, 2010, KaVir wrote in the 118th comment:
Votes: 0
quixadhal said:
As I've tried to say several times now, the main advantage is that the game developer KNOWS what the client is capable of, and can extend that capability on their own terms to handle any future needs or ideas.

I could download the source code for MUSHclient, Mudlet or TinTin++ and extend their capability on my own terms as well.

quixadhal said:
Because the client is doing the rendering (text, graphics, hieroglyphs, whatever), the server doesn't have to do the work of (a) formatting and processing output for a client which may or may not correctly display it, and (b) track output state in case the user wants to pause (pagers) or redraw the screen.

That's exactly how my plugin works as well.

quixadhal said:
A custom plug-in over TELNET can work, but it requires a lot of extra effort (the server still has to format and track everything),

The server doesn't need to format anything, the plugin does that. The server still needs to track data, but that would be exactly the same for a custom client. Having actually spent several months developing a custom plugin, I'm just not seeing where this extra effort comes in.

quixadhal said:
and if you extend things beyond cosmetics, your players will be required to use the custom plugin anyways – negating any advantage to sticking with TELNET.

Personally I've found the cosmetics and presentation of data are the real advantages of the GUI - the players find it convenient, and nice to look at, but it's not "necessary". However even if it were, the data is all available through MSDP, so people could create their own plugins if they wished - and that's exactly what several of them have done. I've seen at least three other MUSHclient plugins (I believe one is even for screen reader users but I'm not sure - I can only see the PLUGIN_ID names they send to the mud), two TinTin++ scripts and a CMUD package.

But even if I were to create a custom client, I would probably use telnet anyway. I find it does everything I need, and I've yet to see a better alternative.
19 Oct, 2010, Tyche wrote in the 119th comment:
Votes: 0
Rudha said:
donky said:
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.


I doubt we will see people making these suggestions willing to take the scientific approach and test their thoughts by experiment, though I personally would like to see the heady idealism put to some realistic tests.


An experiment: [link=post]44703[/link]
Then I developed a little protocol called MUDP to handle all communications.
But I don't like to argue about it.
19 Oct, 2010, KaVir wrote in the 120th comment:
Votes: 0
Tyche said:
An experiment: [link=post]44703[/link]
Then I developed a little protocol called MUDP to handle all communications.
But I don't like to argue about it.

Interesting stuff. But I have to say, I was rather amused to note that the exact same posters who are criticising "old" protocols on this thread are also slamming and mocking UDP on that thread :P
100.0/126