16 Feb, 2012, Deimos wrote in the 41st comment:
Votes: 0
@Runter: No, I'm not wrong; I just chose to not use nested markup in my example. The same point holds true for the markup you provided - you'll still need a state machinerather than just string transformations. Assuming your game uses an internal styling format similar to the Dikurivitive one, anyway. If your game already uses some nested tag-like representation, then this point is moot.

@quix: I think you misunderstand the point of my suggestion. The styling being controlled by the server is the point. As much as I'd love to see games send out structured data and allow the client to style it however they want to, I don't find this method practical for cross-compatibility, since it would be highly unlikely that any two games could agree on a structure for their data itself, let alone a community or portion thereof. Of course, some games have custom clients that do just this, and it provides a great selling point to have a customizable client like that, but it would be impractical for an arbitrary 3rd party client to be able to connect and play without a plugin type architecture brought up previously.
16 Feb, 2012, Runter wrote in the 42nd comment:
Votes: 0
Look, you clearly said this:
Quote
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:

Code (text):
{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.


I used the same exact data structure, you challenged me to do it in the first place, I did it, then you told me it didn't work. It clearly does work, you were wrong, and it's rather small just to not admit it.
16 Feb, 2012, Deimos wrote in the 43rd comment:
Votes: 0
@David: The tags are styled by CSS, which overrides previous declarations. In other words, a parent span with color: blue will be overridden by a child span that sets color: red. I was relying on that behavior in my example. It works how I said it works. Whether or not people agree that markup should or shouldn't be syntactically correct just because it's The Right Way is irrelevant to my point, though. As I said before, the actual markup doesn't have to be standardized. The only important part is that the client knows it's HTML and knows how to handle the set of standard CSS classes.
16 Feb, 2012, Deimos wrote in the 44th comment:
Votes: 0
@Runter: You can go the ad hominem route and ignore my point if you'd like. It doesn't bother me, and I won't be reciprocating.
16 Feb, 2012, Runter wrote in the 45th comment:
Votes: 0
Okay, well, if you're going to just be totally dishonest on this thread then there's no reason for anyone to take you seriously that you want actual discussion.
16 Feb, 2012, Deimos wrote in the 46th comment:
Votes: 0
@Runter: I made it pretty clear that my point was that syntactically valid markup being generated from a Dikurivitive style representation would A) require a state machine, and B) much more bloated markup. You've disproven neither, but you're grand-standing like you have and I just won't admit it. So, keep fighting your straw friend, and I'll be waiting if you want to come back and have a civil discussion without acting rude and condescending.
16 Feb, 2012, Runter wrote in the 47th comment:
Votes: 0
Nah, I think you've soured the discussion for me. I'll leave it up to other people to explain why you're both misguided in your venture and the suggested implementation of said venture. Well, at their own risk of being declared a debate fallacist.
16 Feb, 2012, quixadhal wrote in the 48th comment:
Votes: 0
I guess I fail to see the point of your endeavor.

The advantage of sending structured data is EXACTLY that the server doesn't control presentation. There is zero gain in having the server tightly control data presentation AND requiring a custom client that makes little use of the structure. You'd be better off just using MXP and making up tags as needed.

The plus side of using a data-only model is YOU control both content and presentation. YOU write the client to work with YOUR server, and so you know exactly what capabilities both sides have. If the user wants to modify the client (either via code or via configuration), that's fine… but your server doesn't need to know anything about it.

Literally, you should be able to take a room object and feed it directly to a JSON stream function, sending the result out the socket to the client. The client can then pick it apart and place the room title in the title bar, or the exit list in some cutesy graphical compass thing, or whatever IT wants to do. If you make your protocol open and well documented, others can (if they choose) write their own clients to work with your game.

Writing a generic client is silly, because there will always be data elements you don't account for, and have to treat as "generic text" or something. I'm sure you can dream up a thousand examples… here's one.

Quote
{ "npc" : { "name" : "Fred", "body" : "biped", "class" : "Paladin", "active auras" : [ "blessed aim", "ward evil", "sanctify" ] } }


BAM! Right out the gate… what if your game doesn't have different body types? What if you don't have Paladins? What if you aren't class based? What if your Paladins don't use auras, and what if you don't recognize those auras?

If MY game had such things, MY client would know what all that meant, and know how to present it to the player. Maybe it would show something Dikuish like:
Quote
Fred stands here. (blessed aim)(ward evil)(sanctify)


Then again, maybe my client would choose to draw ovals around Fred's name in the right colors… or maybe it would show a little avatar picture with the auras around it.

My point is, your generic client won't know what to do with any of that data, because it wasn't designed for it.

OTOH, if you are NOT going to use the data to control presentation, but instead plan to fall back to the 1990's and embed markup, I see no reason to bother with structured data at all. If the server is doing all the work anyways, you may as well stick to a raw tcp text stream and use good old ANSI sequences, since you're spending a lot of effort to make something you aren't really making use of.
16 Feb, 2012, Deimos wrote in the 49th comment:
Votes: 0
@quix: As I replied to you before, I understand fully the benefits of letting the client control presentation and simply sending structured data from the server. I don't see any room for cross-compatibility using this approach, though, for exactly the reasons you outlined in your example.

I guess the problem I was trying to resolve may not even be a problem if most/all games that support web clients use this approach. That was one reason why I was polling to see how games currently handled this.

If said games are still letting the server dictate presentation, though, (as antiquated an idea as that may be) I do still see benefit in at least doing it in such a way that any number of web clients could connect and play your game (even if that means playing without the cool features the custom clients that understand your non-output communication frames), instead of just one.

I don't really have a horse in the race, so to speak, but I have the beginnings of a custom web client that connects to my game and receives and sends data, so I was at this point where I thought, "wouldn't it be cool if I could create my own client that was compatible with as many different games as possible, instead of just my own?"

If I'm the only one who sees any value in that, then I'll concede defeat. :-p
16 Feb, 2012, quixadhal wrote in the 50th comment:
Votes: 0
The current state of affairs is simple. Web clients attempt to mimic a vt100/ANSI glass terminal from the late 1980's and the MUD has no idea the player is NOT using such an antique terminal.

That's the status quo, mostly because nobody is willing to code a server to use structured data and ONLY structured data, therefore there's no MUD such a client could connect to. If you were going to create such a system, you would have to support both the client and server.

Now, chicken and egg issue, if such a system were created, and it were shown that it had advantages for the players (in terms of the ability to customize things) and also on the server (in terms of simpler output routines, lower CPU cost, and perhaps other gains), it's possible others might follow the example.

It is NOT likely that an existing MUD with a substantial player base would convert to this, because it's really a design decision.

Now, you could go to the effort of making a server which understood BOTH, however it would not really benefit anyone. The JSON side would be limited in functionality by the lowest-common-denominator of the ANSI side, and the server would both perform worse (having to handle both sets of input/output) and the builders would have to continue to design for ANSI-style, since most players would continue using it.

I should also note that a great deal of the savings you'd get from using JSON isn't in the output routines, but is in the parsing/input routines. Instead of having to pick apart the player's input string, the client itself does that and sends a valid command structure.

Quote
"kill the blue troll with the rusty sword" -> { "command" : { "verb" : "kill", "target" : { "name" : "troll", "adjective" : "blue", "id" : 12345 }, "weapon" : { "type" : "sword", "adjective" : "rusty", "id" : 7361 }, "raw input" : "kill the blue troll with the rusty sword" }


The server doesn't have to pick stuff apart unless the client screwed up. The server sees command=kill target id=12345 weapon id=7361. If both id's are valid, it doesn't need to do anything else, just call the kill function. If the id's were wrong (like maybe the target left the room, or the weapon is an attempt to cheat), it could then try to find a target or weapon by their names/adjectives… if all else failed, you COULD try to parse the string in the server… or simply return an error to the client and let it do it again.
16 Feb, 2012, David Haley wrote in the 51st comment:
Votes: 0
Deimos said:
In other words, a parent span with color: blue will be overridden by a child span that sets color: red. I was relying on that behavior in my example.

That's fine as long as the properties you're setting are exclusive. E.g., color – setting a new color, obviously, replaces the old color. But it doesn't work for other properties, e.g. one span that sets color and another span that sets font. If you don't close, you'll end up with both font and color sent, which might be surprising.

I guess I'm just not sure why we need to insist on this point. If it's HTML, you should close tags. If you want to make something that doesn't close tags, it needs to be well-defined (honestly I do not think it is well-defined right now) and should, IMHO at least, not look like HTML because that sets expectations that do not hold.
16 Feb, 2012, Deimos wrote in the 52nd comment:
Votes: 0
@David: Yeah, I see what you're getting at, but that's the way ANSI codes work as well. If you send ESC@David: Yeah, I see what you're getting at, but that's the way ANSI codes work as well. If you send ESC[1;34mfooESC[4mbar, the blue will bleed from foo into bar (and from there until it's explicitly reset). I was trying to model the HTML equivalent of this behavior in the easiest way possible. It turns out that this method is obviously wildly unpopular, but c'est la vie. I guess I underestimated the perfectionism around here. ;-)

@quix: I agree completely, though, I wonder sometimes whether MUDding fans actually prefer the status quo. It's obvious that the community is dwindling over time, and to draw "new blood", it's probably best to start mixing in more modern technologies, interfaces, etc. But, part of me resists that, because it almost feels like trying to force a square peg into a round hole.

Don't get me wrong; I love me some minimap. But, I also love me some ASCII art, plain ole creative text, and 80s/90s technologies, too. I grew up on it, and I think there will always be a place for it.
17 Feb, 2012, David Haley wrote in the 53rd comment:
Votes: 0
I think it's just an expectations issue. ANSI is expected to be a sequence of tags that toggle client-side state. (Note that this implies that if you want to know what the client's state is, you need to be keeping track of the sequences you've sent.) HTML is expected to describe clearly delineated units; if you close your tags, then you always know 100% of the time with 100% accuracy what state the client is in: they're either in default mode or they're rendering the tags you're sending and closing.

The real question IMO is what you're gaining by treating HTML like ANSI. You're saving on the few characters of closing the tag, but you're breaking expectations. It's also introducing some pretty funny semantics to HTML; how do you explicitly reset? Does one </span> close all outstanding spans? Does </span> close just the most recent span? See here we're getting into expectations again: in ANSI I have a single "reset everything" command I can issue. There is no such notion in HTML because the expectation is to have things opened and closed explicitly. So using </span> to close all tags will be confusing and surprising; using </span> to close only the most recent tag means that you should be using proper open/close in the first place.

So again, the real question is: what are we gaining, after having identified some things that are going to be troublesome? Not saying we're gaining nothing, I'm just trying to answer your original question of should this be standardized. If you want people to have interest in this you need to motivate why the trouble is worth it. Otherwise you should just do your own thing, demonstrate value, and then get other people to work with you. (In the MUD world in particular, I think there's really no other viable approach.)
17 Feb, 2012, Twisol wrote in the 54th comment:
Votes: 0
I think David hit the nail on the head here, about how the actual concepts behind ANSI and HTML differ. At this point, I may as well opine that I don't see anything wrong with continuing to use ANSI color codes as part of the text payload. They're well-suited to what they're meant for (i.e. multiplexing multiple channels of style). I agree with Quix that structured data with client-side styling is optimal, but - just like CSS stylesheets vs. inline style="" attribute - there's a time and place for both. (How else would our beloved DBZ MUDs paint our screens with rainbow vomit? :redface:)*

*no offense
17 Feb, 2012, Deimos wrote in the 55th comment:
Votes: 0
@David: A reset-everything in HTML is easy:

<span class="ansi-reset">


Where:

.ansi-reset { color: #ccc; background-color: #000; text-decorations: none; font-style: normal; }


But I agree with your breakdown of expectations between the two. I guess my point was just that breaking those expectations has no real consequences if the client just dumps the markup into the DOM. We all know it's "bad" not to close tags. You definitely won't find me arguing that, but the markup we're talking about here is transient. It likely will only exist for brief periods of time, and will never be looked at or maintained like a normal websites pages would be. But, again, the structure of the markup itself is irrelevant to the topic of discussion.

@Twisol: Yeah, I actually opted to go with that route for now. I don't see any benefit in using JSON anymore, either. OOB data could ne negotiated and communicated with a proper Telnet layer on the client. Couple that with using plain ole ANSI color codes, and I won't have to change the game's output at all for WebSockets (aside from the packet encoding, of course).
17 Feb, 2012, Twisol wrote in the 56th comment:
Votes: 0
Well. JSON has a big benefit over Telnet in one area: Telnet is control-stuff-within-text, whereas JSON is text-within-control-stuff. But if your goal is just to hook up a web interface to a traditional MUD, that'll work.
17 Feb, 2012, David Haley wrote in the 57th comment:
Votes: 0
Deimos said:
It likely will only exist for brief periods of time, and will never be looked at or maintained like a normal websites pages would be.

Well I think that's a great question to be honest. If you have a MUD that's outputting very many lines of text – like MUDs tend to do – how do you know when to stop?

If, as a client, I receive an unterminated sequence, do I keep applying the formatting? Do I stop it at a newline? Most MUD clients stop ANSI formatting info at a newline; would you expect the "HTML" (approximation thereof, at least) to behave the same way? Anyhow it just introduces complexities – or at the least, complexities in the form of differences.

I agree that if you define the rules, very clearly, as being that HTML is like ANSI codes, then fine. I would argue that the HTML-like syntax is very confusing because of the expectations we discussed, but you could find alternate syntaxes.

I don't think that the structure is completely irrelevant – don't underestimate expectation IMO – but yes, I agree that syntax and semantics are to be kept separate.
17 Feb, 2012, Deimos wrote in the 58th comment:
Votes: 0
@David: In my experiences, typical clients don't reset styles at the end of a line. MUDs I used to play would occasionally get bitten by that when a builder forgot to reset. In any case, they aren't supposed to do that, even if some do. Normal terminals won't (echo -e "\e to do that, even if some do. Normal terminals won't (echo -e "\e[1;34mfoo\nbar" will color both lines blue… and your prompt and everything after that unitl you reset it, in fact).

As a web client receiving HTML output, you would do nothing except dump the HTML to the DOM and let the browser figure it out. It does an amazing job already, so processing the markup is unnecessary.
17 Feb, 2012, quixadhal wrote in the 59th comment:
Votes: 0
Deimos said:
@David: A reset-everything in HTML is easy:
<span class="ansi-reset">

Where:
.ansi-reset { color: #ccc; background-color: #000; text-decorations: none; font-style: normal; }


That's not what MY terminal does. My genuine vt100 would have been color: #00FF00.

*smile*

Also, while *YOU* might be fine just letting <span> tags build up forever, *I* don't appreciate you leaking memory for me. My web browser does maintain a state machine of open tags, and if I stay idle on my MUD for three weeks, watching the I3 traffic scroll by, that's potentially a LOT of open <span> tags it's trying to keep track of, because you are too lazy to properly close them.
17 Feb, 2012, Deimos wrote in the 60th comment:
Votes: 0
@quix: I get what you're saying, but 3 weeks worth of markup in a buffer is going to nom nom your memory, closed tags or not ;-) I've never benchmarked it, but I'd be willing to bet that the performance of nested tags isn't appreciably lower than sibling tags. Nothing to back that up other than a hunch, though. I don't see why it would be any more memory intensive. I might run some tests when I get home, since you've got me curious now…
40.0/66