15 Feb, 2012, Kline wrote in the 21st comment:
Votes: 0
Deimos said:
Kline said:
Deimos said:
Is there any interest in standardizing this at all? I'd really like to see browser clients that are able to connect to multiple different games in the way normal clients have been doing for decades. Of course, game-specific clients could maintain their customized niceities.


MSDP to the rescue!

MSDP is a standard for exchanging non-visible/OOB data. It's not really relevant to what I'm talking about.

We really need a facetious tag here.
15 Feb, 2012, Deimos wrote in the 22nd comment:
Votes: 0
@Runter: Just because a client understands "JSON" doesn't mean it understands the structure of those JSON frame, and it's highly likely, bordering on certain, that if your client connects to my game, the client won't know what to do with my game's JSON output, because it's most likely structured differently than your client is expecting. That structure (if JSON really is the desired format) would still need to be standard to have cross-compatibility like I'm interested in seeing.

@plamzi: Was that a sarcastic/facetious question? :-p For the same reason I think cross-compatible desktop clients are so great.

@aelyah: Thanks, I'm going to give that a look/try.

@quixadhal: I'm really only talking about having a standard data structure, such that client X can connect to muds A, B, or C and be able to interact with those muds. As of right now, no web client that I'm aware of can connect to and work with more than a single game, and it seemed like a cool idea to have a client that could connect to and function with multiple games, in the same way that this van be done with a typical desktop client.
15 Feb, 2012, Quarlash wrote in the 23rd comment:
Votes: 0
Deimos said:
@quixadhal: I'm really only talking about having a standard data structure, such that client X can connect to muds A, B, or C and be able to interact with those muds. As of right now, no web client that I'm aware of can connect to and work with more than a single game, and it seemed like a cool idea to have a client that could connect to and function with multiple games, in the same way that this van be done with a typical desktop client.


While I realize this suggestion is somewhat unconventional, you may find acceptance in (and even external growth of the project from) writing a 'reasonable' (subjective) bareboned client that implements a specific data structure. Ensure that extending / customizing the client is extremely easy (possibly even go out of your way to allow easily installed plugins for the client to allow both a player or mud to customize it), and then begin writing the code needed to integrate the client into some popular stock codebases. You could even write code to implement it into early derivative bases, most later derivative muds have an idea of how to manually patch. Once completed, rebundle the codebases with both the client and supportive code with a very simple and short way of activating the client / mud support (bonus points for generating patches for these codebases and releasing them independently).

If you standardized the plugin format, and allowed a client to negotiate with the mud regarding what plugins work / do not work (resulting in the client enabling / disabling plugins depending on the mud you're connecting to), your result would be both player and mud customizable, work across many different muds, and have the potential for a community to form around it where (if you played your role in such a way) you no longer become independently responsible for maintaining and improving the code.

Obvious pros / cons with this idea is that you're doing a (potentially) large amount of extra work that doesn't really benefit you directly (however, I'd argue advocating for a standard in and of itself is a large amount of extra work) and while we all hope for the best result possible, it may entirely be a flop regardless of the amount of time you put in.

I personally wouldn't be writing this if I didn't see value in the project. I'd install something like this and write some custom plugins if it were available, no question, and I'm imagine there'd be dozens more who would as well. In fact, I have future plans to write a web-information-client down the road for my mud. The best way to explain what my intentions are is that it would be the lazy man's way of combining telnet and web support for a mud independently. I'd love to have the option of using a prebuilt web-client instead (or even in addition to).

Hope this post does more than just muddy the waters.
15 Feb, 2012, David Haley wrote in the 24th comment:
Votes: 0
Deimos said:
@Runter: Just because a client understands "JSON" doesn't mean it understands the structure of those JSON frame, and it's highly likely, bordering on certain, that if your client connects to my game, the client won't know what to do with my game's JSON output, because it's most likely structured differently than your client is expecting. That structure (if JSON really is the desired format) would still need to be standard to have cross-compatibility like I'm interested in seeing.

You've just identified exactly why standardizing this is incredibly difficult.

How are you going to standardize this in the first place if my game speaks different data than your game? Do I have to conform my JSON output, with the structured output that I want and I like, to some other person's notion of their data? If I'm already writing my own JSON-speaking client, I'll just make a tight, richly integrated experience.

So for example, describe for us what exactly you're standardizing and how you envision that actually working. We don't need a full proposal at this point, but really, it's unclear to me how you'd even start wrangling this problem, let alone get buy-in.

The question isn't whether this is a good thing in principle. Of course it would be nice if all clients could connect to all games. But there's a big difference between a MUD outputting unstructured text to a client that thinks in terms of lines, vs. a MUD outputting structured data that has meaning that must be interpreted client-side for rendering. As soon as you introduce meaning, you run into the immediate problem of different MUDs having different meaning for their data, different fields, etc.

I'd go with what Twisol said, frankly: preemptive standardization is all but doomed to failure. :sad:
15 Feb, 2012, Deimos wrote in the 25th comment:
Votes: 0
@David: I'm not concerned with structuring data beyond a certain point. To give an example, just look at standard MUD output to desktop clients. The vast majority of games use ANSI color codes. The structure of this data is standardized. In other words, (almost) any client can connect and render the output from (almost) any game, because they all know how to speak ANSI and translate that to colors on the screen and such.

I envision the same thing for web clients. Now, there's no reason a web client couldn't parse standard MUD output, ANSI and all. I was just curious how existing games were already doing it, and if there were a popular alternate format (e.g. JSON), whether there was interest in standardizing the structure enough to allow cross-compatibility.

So, to summarize, I'm only looking to talk about basic output standardization. If your game wants to send special JSON formatted messages for updating your awesome minimap or stat gauges in your game-specific client, that could be done *in addition* to this, and such that it could even be negotiated on connect. Then my client and yours could both connect and function with your game, even though a richer experience could be had if I used your custom client.

@Quarlash: That's actually a very good idea, and I may look into doing that if there is no interest in standardizing basic output structure.
15 Feb, 2012, Runter wrote in the 26th comment:
Votes: 0
Deimos said:
[…]The vast majority of games use ANSI color codes. The structure of this data is standardized. In other words, (almost) any client can connect and render the output from (almost) any game, because they all know how to speak ANSI and translate that to colors on the screen and such.

I envision the same thing for web clients.


That's the point of HTML. It has been standardized, just get people to use it. (Good luck.)

The reason ANSI color codes was used wasn't because there was a conscious effort by mud developers and mud client developers to bring a fractured community all sending color data differently into line. It's because [some] terminals already understood it. Your web browser already understands html. But therein lies the crux of the matter. Most muds aren't designed to be played in a web browser, and most are going to purposefully alienate such play because of perceived inadequacies of web browser technology. Regardless of the reason, the situation simply isn't analogous to the use of a standard like ANSI color codes.
15 Feb, 2012, David Haley wrote in the 27th comment:
Votes: 0
But as soon as you start sending around JSON, you're sending around structured data, whether you want it or not. JSON isn't a great format for sending straight linear text that has color markups and so forth. It's a great format for structured data. If the goal here is to send text with color codes and other such formatting markups, then Runter is absolutely correct and HTML is the way to go – it already does that.

I think what you're running into is that a lot of people developing web clients are not interested in creating Yet Another Generic Terminal Client – they want to add special, rich functionality that leverages the power of browsers and so on and so forth. It's boring to create a plain terminal in a browser; it serves a purpose of course but that's missing the point and most people are going for more than that.
Therefore it doesn't make much sense, from a standardization perspective, to approach this as "let's all agree on a way to send basic text to web clients", because that's just not what a lot of these projects are about.

Now if you really wanted to say something like:
- a MUD server sends out a JSON packet that has a 'type' field of 'text' and a value of ANSI-color-coded MUD text
- web clients accept JSON packets, see the 'text' type, and render from there

then great, but I'm not seeing the audience, either on the server end or the client end.

Server: Why should I adapt my server to support some JSON protocol just to send data that I'm already sending as text?
Client: Why should I bother dealing with this extra stuff, if I'm not already working with a server that supports truly rich structured data – at which point, why am I bothering with this linear text thing because I'm not even using it?
16 Feb, 2012, Deimos wrote in the 28th comment:
Votes: 0
@Runter: HTML is fine for marking up the actual data, but as David pointed out, most of these games need to retain the ability to send their enhanced stuff as well. If we wrap the HTML in a JSON frame, e.g.:

{"type": "output", "data": "<span class=\"ansi-red\">This is red."}


Then these games can send non-output frames for the enhanced stuff (maps, gauges, etc.), while the clients get the ability to display the game's output for any game that uses this same structure.

Obviously the structure is what I was curious about standardizing, though it becomes a minimal standard at best if we use HTML for styling (which is a good thing IMO).

@David: See above for an explanation, which hopefully clarifies what I'm talking about.
16 Feb, 2012, Twisol wrote in the 29th comment:
Votes: 0
Deimos said:
{"type": "output", "data": "<span class=\"ansi-red\">This is red."}

Like I said earlier, this kind of message framing is what I'm putting my (Monopoly) money on.

(EDIT: Though that should have a </span>, y'know.)
16 Feb, 2012, Deimos wrote in the 30th comment:
Votes: 0
@Twisol: As much as the perfectionist in me cringes at the thought of not closing tags, it makes for infinitely easier implementation and works as intended in all major browsers. Example:

{RThis is red {Uunderlined text.{X


If we just replace the styles with spans:

<span class="ansi-hi-red">This is red <span class="ansi-underline">underlined text.<span class="ansi-reset">


If we try to end the tags, the formatting code becomes much more complex than simple string replacements, since we have to deal with nested styles, style overrides, etc. Not to mention that not ending the tags essentially duplicates ANSI behavior (styles don't stop unless explicitly reset or they get overridden, and will bleed to future output).
16 Feb, 2012, plamzi wrote in the 31st comment:
Votes: 0
Deimos said:
@Twisol: As much as the perfectionist in me cringes at the thought of not closing tags, it makes for infinitely easier implementation and works as intended in all major browsers. Example:

{RThis is red {Uunderlined text.{X


If we just replace the styles with spans:

<span class="ansi-hi-red">This is red <span class="ansi-underline">underlined text.<span class="ansi-reset">


I came up with a few of those when I was writing the output from the server to our custom client. But, like others here, I have no interest in following a standard. I get your point that a JSON frame format has to be known by the client. But let's back up a bit to the "why" question, which I don't think has been answered. I can't think of a receptive audience for such a standard. What's in it for game admins? What's in it for other people developing generic web-based clients? The only people that may potentially benefit are experienced mudders who hop games a lot (few such souls) and want to play on the go (foregoing the power of their favorite desktop client?). I bet that's a cross-section of people that can fit in a communist apartment. And, they don't code. So why should we.
16 Feb, 2012, quixadhal wrote in the 32nd comment:
Votes: 0
Deimos said:
@Twisol: As much as the perfectionist in me cringes at the thought of not closing tags, it makes for infinitely easier implementation and works as intended in all major browsers. Example:

{RThis is red {Uunderlined text.{X


If we just replace the styles with spans:

<span class="ansi-hi-red">This is red <span class="ansi-underline">underlined text.<span class="ansi-reset">


If we try to end the tags, the formatting code becomes much more complex than simple string replacements, since we have to deal with nested styles, style overrides, etc. Not to mention that not ending the tags essentially duplicates ANSI behavior (styles don't stop unless explicitly reset or they get overridden, and will bleed to future output).


Are you trying to design something new, or are you designing some crippleware to shoehorn into existing games?

It matters.

If you're trying to make something new, do it Right(TM) and don't worry about the pathetic way existing games do things, because they were developed 20 years ago for a totally different environment which is gradually going away. If you're attempting to shoehorn old data into some new protocol, I don't see the point. The game wasn't designed to work with structured data, and thus the amount of effort involved to undo all the formatting done because of a lack of a structured transport is more than you're gonna spend writing a whole new game.

If you want to import old data INTO your new system, who cares how complex or slow the import process is? You're only going to run it once. So, you write a perl script that takes an hour to run and tracks ANSI states from the old clunky {R {U {Z silliness and converts it to properly nested HTML. Big whoop. Do it, be done, never look back.

PS: The reason for closing tags should be obvious.

Quote
This text is normal, but this is red except for a green word in the middle before going back to normal.


If you don't use closing tags, you're requiring the client to either track state (which defeats the purpose of using structure to simplify things), or you're making it impossible to have properly nested styles (and are back to 1990 again).
16 Feb, 2012, Runter wrote in the 33rd comment:
Votes: 0
Yeah, upon further review this code doesn't even make sense to me:

<span class="ansi-hi-red">This is red <span class="ansi-underline">underlined text.<span class="ansi-reset">

It may look like html, but what you're proposing definitely isn't html. Like the last span there in html just wouldn't make sense, even discounting the fact it has no closing tag. Styles in html are applied to children, not to siblings. That appears to be what you want, but that's just not what html is for.
16 Feb, 2012, Deimos wrote in the 34th comment:
Votes: 0
@Tyche: Not using closing tags does not require the client to keep state. It can simply dump the MUD output to the screen and the browser handles everything properly, as I pointed out earlier. I don't like it either, but it's easier to implement server-side, and drastically reduces the amount of needed markup overhead/bloat. Yes, bandwidth is cheap these days, but bloating data by like 2000% just to have markup which validates is a little silly, no? I just don't see any benefit, and plenty of drawbacks. Shrug. I also have no idea what you're talking about with respect to an import. The game needs to maintain a technology-agnostic styling (e.g. "{Rfoo{Ubar") as this needs to be converted on the fly to either ANSI for desktop clients, or HTML for web clients. We can't just import once and forget it…

@Runter: It does make sense if you understand how browsers parse it:

<span>foo <span>bar <span>


These are nested child elements as far as the browser is concerned, with or without ending tags, and this will be treated the same as:

<span>foo <span>bar <span></span></span></span>


Again, I dislike it as much as any of you, but it's the most practical method. Try representing this in HTML for an example of how using end tags would be rather bloated and unwieldy:

{Rfoo{Ubar{Gbaz{X


If you end the first second span, how do you then determine which styles/classes should be applied to the third? Suddenly you need to keep state, and the conversion becomes a state machine rather than a bunch of string transformations. I'm not necessarily against doing it this way, but as I said earlier, this is a lot of added complexity - for what? So it makes more sense to someone viewing the source? Seems pointless to me.
16 Feb, 2012, Runter wrote in the 35th comment:
Votes: 0
Quote
Try representing this in HTML for an example of how using end tags would be rather bloated and unwieldy


Ok.

<span>foo<span>bar<span>baz</span></span></span>


span "foo" do
span "bar" do
span "baz"
end
end


Frankly, I don't know why you think that's less clean or more bloated. First of all, it's actually proper html and second… you have control over the nested level and don't have to rely on the kindness of strangers. (Browser devs to accept your malformed html and straighten it out for you at some point.)

In the grand scheme of things the html content is relatively small potatoes. More importantly, even if also negligible, is that the dom is less bloated. So one could make the argument that needing reset spans, and stuff like that, is more bloated…and it's certainly less flexible or clear to someone who knows how to write html in the first place.

Furthermore, the devs wouldn't likely be typing html out. If you're serving dynamic HTML there's absolutely no reason to type it out in your server. You should have robust helpers to do it for you:

Like the markaby template engine for ruby:
h1 "Boats.com has great deals"
ul do
li "$49 for a canoe"
li "$39 for a raft"
li "$29 for a huge boot that floats and can fit 5 people"
end

span "foo" do
span "bar"
end


But if we're rolling our own pseudo html format, I guess we couldn't rely on any of the libraries already written for us to generate the html. Since we don't want that useless extra markup that tells the tags where the nesting levels end…
16 Feb, 2012, Jimorie wrote in the 36th comment:
Votes: 0
Deimos said:
Again, I dislike it as much as any of you, but it's the most practical method.


I don't think you do dislike it as much as some others, seeing how you actually argue for this being a good idea. ;)

I understand your point, certainly, but since you are posting it as a suggestion, I am going to assume you are interested in feedback, and I for one would recommend against using broken HTML in your standard to-be. Simply because it is broken.

The options that in my opinion are worth considering are to either send, 1) valid HTML markup that can be parsed and inserted into the page DOM directly by the browser, or 2) ANSI codes that can be parsed by the Javascript client to DOM nodes and inserted into the browser's page DOM. Of course, option 2 could just as well use some other markup codes than ANSI, if that is what you have server-side. (E.g. {Rfoo{Ubar{Gbaz{X.)

Like I said in a previous post, I use option 1 myself, but am interested in implementing option 2 and compare the results.
16 Feb, 2012, Deimos wrote in the 37th comment:
Votes: 0
@Runter: I meant actually try to style the data properly, not mark it up. Your markup, of course, is correct. There should be 3 separate spans (for foo, bar, and baz, respectively). But the representation:

{Rfoo{Ubar{Gbaz{X


…represents continual styles that span (heh) multiple span tags. The "{U" (underline) style should apply to both bar and baz elements. Ditto for "{R" (red) applying to both foo and bar. Now, instead of doing simple string transformations, you must create a state machine capable of taking that representation and creating this markup:

<span class="ansi-hi-red">foo</span><span class="ansi-hi-red ansi-underline">bar</span><span class="ansi-underline ansi-hi-green">baz</span>


…which is both, bloated and comparatively inefficient. But, yes, it's now syntactically valid.

I agree that this isn't really pertinent, though, as they're implementation details irrelevant to the standard, which in and of itself would consist only of:

- Send a JSON frame with a "type" param of "output" and a "data" param containing the output.
- Format the output as HTML
- Use standardized CSS class names for the styles (e.g. "ansi-hi-red" and such)

The actual structure and naming are all up for discussion, but as you can see, it's very simplistic, and would only benefit games. I can't see any drawback to a game implementing this. You already have to structure your data somehow; why not use a structure that could potentially increase the compatibility?

@Jimorie: As pointed out to Runter, if HTML were used, the actual markup would not have to be standardized, so this point is rather moot. It's enough to simply say that it's HTML and the CSS classes for styling are blah blah blah. Anything beyond that is at the implementor's discretion, and shouldn't hurt the cross-compatibility that we're aiming for. The client is likely just going to dump the markup to the DOM as-is, and not care whether it's syntactically correct or not.
16 Feb, 2012, Runter wrote in the 38th comment:
Votes: 0
It does apply to multiple spans.

http://jsfiddle.net/66cJB/1/

<span class="red">lol<span class="ul">foo<span class="blue">bar</span></span></span>


.ul {
text-decoration:underline;
}

.red {
color: red;
}
.blue {
color: blue;
}


In other words, you're just wrong. The styles are applied differently than you think.

result:
lolfoobar
16 Feb, 2012, David Haley wrote in the 39th comment:
Votes: 0
If a tag means "cancel all other previous tags", then sure, it's less important to close it. But spans are additive, not exclusive, as Runter showed pretty clearly.
16 Feb, 2012, quixadhal wrote in the 40th comment:
Votes: 0
First of all, why are you using obscure and arcane markup (which is specific to ONE type of Dikurivative only)? If you're designing your system from scratch, for God's sake, make it easy to read and debug.

Secondly, if you omit closing tags, you *DO* need to make a state machine if you care about client and server having the same worldview of the data. Assuming the browser will "take care of it" is just asking for obscure bugs where one player reports something you can't reproduce because your environment doesn't work the same way.

Thirdly, as Runter has shown, I don't think you get how HTML styles and properties work, nor how ANSI actually works with respect to various terminal types. If I send the ANSI codes which YOU think of as "bright red", the terminal on the other end might agree and set the color to bright red. OTOH, it may use regular red with the BOLD being applied to the font rendering, which will be the same color but thicker lines. More importantly, if you send red – some text – underline – some more text – green some text – reset – a bit more, you get

Quote
some text some more textsome text a bit more


The tail end can't restore the "red", because there is no nesting… any changes to the color apply and wipe out any previous colors. In particular, color data is one channel, bold/not-bold is another, underline, italics, blink, are all seperate channels. You can turn any channel on or off, but the actual colors are not seperate.

So, here's the thing:

If you are allowing markup inside a data element, you need to choose a markup language. You can roll your own easily enough. You can use one of the Dikurivative ones and live with the limitations. You can use HTML and have easily available libraries to parse it for you.

If you are NOT allowing markup, then there's zero point in talking about colors or anything else. You send the data as data, the client decides how to display it, end of story.

Quote
{ "room" : { "title" : "A dusty cellar", "desc" : "This is a dank and dusty cellar. You see cobwebs along the rafters, and something moved in the shadows behind an old workbench.", "extra" : { "cobwebs" : "The cobwebs are intricate and have dust adorning them. Obviously the builder is long gone.", "workbench" : "An old wooden framework with rusty tools and plenty of places to anchor things.", "shadows" : "You could have sworn something moved back there, maybe it was just a mouse." } } }


Now, you could have markup in there to specifically colorize a few words, if you had some specific reason to want them to be an exact color or style, however… it's probably better to simply let the client add their own visual cues. In that example, you might want to underline or change the color of the keywords which can be examined for more detail. You could use markup, but you could also just let the client be smart enough to take the keys of the "extra" descriptions and apply the color to them itself.

In either case, your protocol doesn't need to know about it. If you use markup, it just has to be escaped for JSON and the client will spit it out blindly to the rendering layer. If you don't use markup, the client will do the transforms needed itself.

On the client end, if you choose a rendering layer that is standardized already (HTML), you know how to maniuplate things to add markup before rendering. The server doesn't need to care. The builder might, if they are expected to add the markup instead of letting the client do it based on the data structure, but that's what documentation is for.
20.0/66