13 Sep, 2011, Baiou wrote in the 1st comment:
Votes: 0
It's been years since I've first heard about muds. Is there any new tech for this scene or am I just missing it? I need that new revolutionary thing!
13 Sep, 2011, Kline wrote in the 2nd comment:
Votes: 0
AFAIK the only things that have changed are under the hood. Higher level languages. Database storage. Full in-browser interfaces.
13 Sep, 2011, David Haley wrote in the 3rd comment:
Votes: 0
So other than all-new implementations and all-new interfaces, nothing much has changed.

:tongue:
14 Sep, 2011, Cratylus wrote in the 4th comment:
Votes: 0
Baiou said:
It's been years since I've first heard about muds. Is there any new tech for this scene or am I just missing it? I need that new revolutionary thing!


i guess i'd want to know what you'd do with new mud technology if you knew about it. did you do anything with the old stuff?
14 Sep, 2011, Baiou wrote in the 5th comment:
Votes: 0
Cratylus said:
Baiou said:
It's been years since I've first heard about muds. Is there any new tech for this scene or am I just missing it? I need that new revolutionary thing!


i guess i'd want to know what you'd do with new mud technology if you knew about it. did you do anything with the old stuff?


I've worked with the existing stuff. Had some successes, some failures. I've been working on the same project for the past 2 years now. Life loves to delay stuff. As far as new things, programming is far more advanced than muds actually utilize, but for muds to actually take advantage of that, I believe they would have to be revamped from the ground up. Maybe it'd have more to do with 'dedicated clients' for certain games. Shrug.
14 Sep, 2011, plamzi wrote in the 6th comment:
Votes: 0
There are quite a few dedicated clients out there. Shrug-shrug. Wink-wink. Nudge-nudge.
14 Sep, 2011, Lyanic wrote in the 7th comment:
Votes: 0
plamzi said:
There are quite a few dedicated clients out there. Shrug-shrug. Wink-wink. Nudge-nudge.

You're remarkably subtle.
14 Sep, 2011, plamzi wrote in the 8th comment:
Votes: 0
Lyanic said:
plamzi said:
There are quite a few dedicated clients out there. Shrug-shrug. Wink-wink. Nudge-nudge.

You're remarkably subtle.


Wasn't going for subtlety. Was going for a Monty Python reference. Oh well.
14 Sep, 2011, Idealiad wrote in the 9th comment:
Votes: 0
I know this has been talked to death over the years but I read an interesting article recently on narrative generation, about this company:

www.narrativescience.com
14 Sep, 2011, Baiou wrote in the 10th comment:
Votes: 0
How do they fair?
14 Sep, 2011, quixadhal wrote in the 11th comment:
Votes: 0
Some of us have hinted, pleaded, bashed-people-over-the-heads, etc., at the idea of abandoning TELNET and using a structured data transfer like JSON or friends to talk between a dedicated client and server. So far, only a few people have even seriously looked into the idea. Most of the dinosaurs here are like "WOT? NO TELNET? LULZ!" or "Yeah, good idea… maybe after a nap!"

I fall into the latter category. :)
14 Sep, 2011, David Haley wrote in the 12th comment:
Votes: 0
I was going to write a reply, but I fell asleep halfway through and forgot. :wink:
14 Sep, 2011, Kline wrote in the 13th comment:
Votes: 0
David Haley said:
So other than all-new implementations and all-new interfaces, nothing much has changed.

:tongue:

From a player perspective not much has changed. A few more custom clients. A handful of places supporting MXP/MSP (which are still fairly old). I took the OP's request to be more in line of asking about any new great/unique in-game features either made possible or made feasible via technology advances. As excited as I may get that I was able to move <x> data into a database to query it/work offline with it easier, there's no perceptible difference to players, so why should they care that my game runs on the latest high level language / database / etc?
14 Sep, 2011, Runter wrote in the 14th comment:
Votes: 0
Interface changes are most certain to change things from the players perspective. New technology can allow you to do amazing things on this front.
14 Sep, 2011, KaVir wrote in the 15th comment:
Votes: 0
quixadhal said:
Some of us have hinted, pleaded, bashed-people-over-the-heads, etc., at the idea of abandoning TELNET and using a structured data transfer like JSON or friends to talk between a dedicated client and server. So far, only a few people have even seriously looked into the idea. Most of the dinosaurs here are like "WOT? NO TELNET? LULZ!" or "Yeah, good idea… maybe after a nap!"

Or "You can already do that with telnet". Seriously, as I told you last time, if you want people to rewrite their connection code and discard two decades of client development, you need to offer them at least one useful benefit they can't already do. Arguing solely on the basis of "it's old" just isn't going to cut it with the people who actually have to do all the work.

Kline said:
From a player perspective not much has changed. A few more custom clients. A handful of places supporting MXP/MSP (which are still fairly old).

MXP and MSP are old, and not very well thought-out. What's more interesting (and relatively new) are the advances in modern clients in terms of graphical support, and the out-of-band mud protocols that utilise them. ZMP has been around for a while, but I think it was before its time, and it never drew much interest.

On the other hand, I know of 8 muds that support GMCP, at least another 24 that support MSDP, and the numbers are growing every month.
14 Sep, 2011, Rarva.Riendf wrote in the 16th comment:
Votes: 0
Quote
at least another 24 that support MSDP, and the numbers are growing every month.

And I bet most of them because of your great work :) It is so easy to plug it in ith your snippet that only utter lazyness prevents it to be plug everywhere it can.
14 Sep, 2011, quixadhal wrote in the 17th comment:
Votes: 0
KaVir said:
Or "You can already do that with telnet". Seriously, as I told you last time, if you want people to rewrite their connection code and discard two decades of client development, you need to offer them at least one useful benefit they can't already do. Arguing solely on the basis of "it's old" just isn't going to cut it with the people who actually have to do all the work.


Quote
> look
A precarious perch
You are standing on a platform, high above the forest floor. The wood seems rotten and you can see small gaps giving a view to your future plummet into the not-so-soft debris, far below. You can see a thin rope bridge leading off into the undergrowth to the north, and a ramshackle shelter that seems more like a lean-to than a permanent home balances on the western edge, near the slim safety of the large tree trunk that anchors the platform.
There is a statue of a rabid squirrel here.
A sparrow hops along the edge of the platform.
> look north
It looks like a very tenuous rope bridge that MIGHT hold your weight.
> look west
The shelter is just big enough for perhaps two human-sized people, if they're friends.


Now, if the server dished that up as a structured data packet, it might look something like:

Quote
{ "room" : {
"title" : "A precarious perch",
"desc" : "You are standing on a platform, high above the forest floor. The wood seems rotten and you can see small gaps giving a view to your future plummet into the not-so-soft debris, far below. You can see a thin rope bridge leading off into the undergrowth to the north, and a ramshackle shelter that seems more like a lean-to than a permanent home balances on the western edge, near the slim safety of the large tree trunk that anchors the platform.",
"objects" : { "squirrel" : "There is a statue of a rabid squirrel here." },
"npcs" : { "sparrow" : "A sparrow hops along the edge of the platform." },
"exits" : {
"north" : "It looks like a very tenuous rope bridge that MIGHT hold your weight.",
"west" : "The shelter is just big enough for perhaps two human-sized people, if they're friends."
}
}


Given a structured format like that, the client knows exactly what every part is, and how to display each according to the player's wishes (or the client's defaults, or perhaps even the server's suggestions). The client knows the sparrow is an NPC, and thus commands that interact with NPC's can be pre-parsed and sent already validated (as structured command packets). The client knows the squirrel is an object and thus can validate using different rules if the user types "kill squirrel". Even if your game doesn't have such strict rules, at least the server doesn't have to process and respond to "kill squrrl", since the client knows no such thing exists in the room, and doesn't need to send the useless command which will just result in a generic error message anyways.

How would you do the same thing using MXP/MSP/ZMP/MSDP? How would you present the data over TELNET in such a way that each element is distinct and clear, allowing the client to present it AND parse it properly without making the server do all the work? Remember, the way the first text-only thing looks was determined by the server. Current clients have to pick it apart with complicated regular expression rulesets to try and figure out what each chunk of text is, and thus where to put it.
14 Sep, 2011, KaVir wrote in the 18th comment:
Votes: 0
quixadhal said:
Now, if the server dished that up as a structured data packet, it might look something like:

Like GMCP? Yes, you can already do that. MSDP has its own format, but can achieve the same results. ZMP doesn't have a defined data format, but you could use the same style as your example if you wished. There's also MMP, which is specifically designed to send area and room data.
14 Sep, 2011, quixadhal wrote in the 19th comment:
Votes: 0
Ok, so… now what's the advantage of continuing to use TELNET while using GMCP/MMP/MSDP as opposed to an industry standard like JSON? Assuming you're sending structured data, there isn't any such thing as Out-of-Band data, nor is there any need for negotiations of options, since the client is handling all the formatting, meaning the server has no need to know about screen sizes or color capabilities.

Or, more clearly, what is the advantage OTHER than allowing people to continue using TELNET? Why is using TELNET better?
14 Sep, 2011, Rarva.Riendf wrote in the 20th comment:
Votes: 0
Quote
Or, more clearly, what is the advantage OTHER than allowing people to continue using TELNET? Why is using TELNET better?

I think it is both a client and server problem, kind of a egg and hen problem.
0.0/128