12 Feb, 2012, Deimos wrote in the 1st comment:
Votes: 0
I have finished implementing WebSocket support on my game, and created the most basic of clients for it, and was wondering: for those of you who have done this, what format do you send your data to the client in? I prefer JSON, myself, but I'm running into a few issues, like how to represent the styles and such. I'm thinking about using the concepy of "runs" (those familiar with MUSHclient scripting might recognize this). Is there any kind of standard either already established or in the works for output structure to web clients? If not, is there any interest in coming up with one, so that clients can be cross-game compatible to some limited extent (insofar as displaying the formatted output is concerned)?
13 Feb, 2012, quixadhal wrote in the 2nd comment:
Votes: 0
Ummm, HTML?
13 Feb, 2012, Twisol wrote in the 3rd comment:
Votes: 0
Personally, I'd stick to a JSON message frame. If HTML is necessary for content, that can be passed as part of the JSON packet, without forcing output to -always- be HTML. That's the exact issue Telnet has, and I'd rather keep the content at a lower level than the control.
13 Feb, 2012, Jimorie wrote in the 4th comment:
Votes: 0
The main concern I had when implementing a Javascript client using WebSockets was speed. In my experience, Javascript is still rather sluggish. I therefore chose to use a simple and perhaps not-so-elegant protocol in order to minimize the complexity of the Javascript client in the common case of receiving output from the MUD:

The first byte of each data frame sent over a WebSocket connection is read as a flag, telling the Javascript client what to do with the rest of the message: Either the message is a HTML formatted string, ready to be displayed as output from the MUD; or it is a JSON formatted data structure that holds special instructions for side effects, such as updating health bars, maps or group frames, et cetera.
13 Feb, 2012, Runter wrote in the 5th comment:
Votes: 0
I wouldn't use html for the data format… If the client used HTML for rendering it should accept the data and then ideally render it using html.
Jimorie said:
The main concern I had when implementing a Javascript client using WebSockets was speed. In my experience, Javascript is still rather sluggish. I therefore chose to use a simple and perhaps not-so-elegant protocol in order to minimize the complexity of the Javascript client in the common case of receiving output from the MUD:

The first byte of each data frame sent over a WebSocket connection is read as a flag, telling the Javascript client what to do with the rest of the message: Either the message is a HTML formatted string, ready to be displayed as output from the MUD; or it is a JSON formatted data structure that holds special instructions for side effects, such as updating health bars, maps or group frames, et cetera.


That hasn't been my experience so I'd love to hear why you think javascript is too slow. There's a variety of things that can make it sluggish feeling. Like having a really poor machine or a poor implementation of javascript. For my common cases, I haven't seen this problem.
13 Feb, 2012, Jimorie wrote in the 6th comment:
Votes: 0
Runter said:
That hasn't been my experience so I'd love to hear why you think javascript is too slow.


Well, I did not say that Javascript is too slow. I believe this type of MUD clients are perfectly viable, and that they represent the future for online, text-based games. However, there is a definite difference in "snappiness" compared to the typical terminal program that I am used to. And I think that snappiness is very important for a MUD client.

Now, I am willing to admit that this lack of snappiness in a Javascript client is probably not much helped by my simplistic protocol design. Sending all data as JSON may very well turn out just as fast – I never did any tests on this. While implementing my Javascript client, I followed my gut feeling towards what I thought would come as close to "snappy" as possible.
13 Feb, 2012, Runter wrote in the 7th comment:
Votes: 0
My point is that it's based on the javascript implementation, and the renderer you're manipulating. There's nothing about javascript itself that would mean it should be insufficient, of less "snappy." Maybe your experience with javascript has been using a crappy implementation. Like anything microsoft related. For something fast using javascript, look at V8.
13 Feb, 2012, Jimorie wrote in the 8th comment:
Votes: 0
Quote
Maybe your experience with javascript has been using a crappy implementation. Like anything microsoft related. For something fast using javascript, look at V8.


No, I use Chromium myself, so that's not it.

But really, this is not a big deal. I mentioned my experience of Javascript being sluggish to explain for the original poster my priorities, that influenced my choice of data format. I realize that sluggish may have been too strong a word, I apologize for that. To put things in perspective, I think many desktop GUI clients feel "sluggish" too.
13 Feb, 2012, aelyah wrote in the 9th comment:
Votes: 0
I had the same questions, here is an example of HTML5/Websockets mud client:

http://www.mudsings.com/easy-to-contribu...

And here is the story around it:

http://blog.halcyon-solutions.com/2011/0...

Java script on IE7 is awfully slow, and a simulated canvas is impractical (direct experience trying to make the html5 client work). Modern browsers have a better JS implementation rendering the HTML5 approach feasible.

I think you can still download a version of the client from mudsings, I need to upload a new one as I fixed a couple of issues to make the DS mudlib work with it :)

Hope it helps,
A.
13 Feb, 2012, Runter wrote in the 10th comment:
Votes: 0
But the gui the renderer uses isn't related to javascript. In fact, it's probably written in C++ and accessed through an API exposed to javascript. Indeed, if you're using javascript for a server side language (like in node) you'll quickly find you don't have access to a dom. It's not part of the javascript language. So javascript doesn't really have anything to do with GUI per se. So when you say it feels sluggish I assumed you meant that running actual javascript code was sluggish (read latency). The GUi for a web browser is going to have differing results based on the browser, the hardware, and the specifics of the configuration of the operating system. And most importantly perhaps your understanding of what the code is doing, but that's the same in almost any language. Efficient code runs efficiently. So I can't speak to your experiences, but a lot of software more advanced than mud-clients is being built as web apps successfully. So I'll skip further truisms.
13 Feb, 2012, aelyah wrote in the 11th comment:
Votes: 0
Runter,

You are right. I read your note as quite valid observations rather then truisms.

1. IE 7 doesn't have native, c++ support for Canvas so it had to be simulated in JS. I found a JS library attempting to do it. So for IE7 the performance is related to JS.

2. The node.js part doesn't use the DOM, it is a simple "adapter" to translate between a telnet connection and websockets messages. The stock mud doesn't have native support for websockets so… Every problem can be solved with an additional layer of indirection :)

3. node.js seemed to me to be easier to set up than the AnyTerm machinery (totally subjective :))

4. You are right, many applications run efficiently and where is a will there is a way (efficient code runs efficiently). I did 't see a lot of value in the context of mudsings to improve/rewrite the code of the canvas library for IE7. I decided to reuse as much as I can of what was available to me: the term package, the node.js, the socket.io library and the native library for canvas offered by the more modern browsers.

5. Loops in IE7 are slower than loops on more modern browers, I am sure you can craft a simple test program: a loop from 1 to 2000 to change the style on a element in a list, e.g. displaying alternate styles in a table.

6. If you (as in you the community) think the client has any value I will be happy to upload it on github so we can optimize it, as Runter rightfully noticed.

If you tried the client you noticed there are still many opportunities for improvement (aka bugs). Any help will be very appreciated.

A.
13 Feb, 2012, Deimos wrote in the 12th comment:
Votes: 0
Not to be rude, but I was hoping for a discussion about a potential standard way of server -> browser client communication, not JavaScript performance.

For those of you who said JSON, what kind of structure were you using? Was each frame a line of output, a style run, or just a normal block of data (which could contain one or more lines - or none at all)? Did you style the text before framing it? Or did you keep it abstracted and let the client interpret it however it wants?

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.
14 Feb, 2012, Kline wrote in the 13th comment:
Votes: 0
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!
14 Feb, 2012, Deimos wrote in the 14th comment:
Votes: 0
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.
14 Feb, 2012, Deimos wrote in the 15th comment:
Votes: 0
I guess if the ANSI codes are parsed client-side, there isn't really a need to structure the server output any differently. In fact, one could also implement a Telnet protocol layer in JS as well. I'm not sure what the performance (hah… now you even got me talking about it!) would be like, but it would certainly be possible, and fun to do. I may just do that instead. I still wonder how that will affect the client's ability to converse with other games, though. If Game X accepts WebSocket connections, but only sends some proprietary output format, it would break.
14 Feb, 2012, quixadhal wrote in the 16th comment:
Votes: 0
The confusion here is probably because you seem to be talking about two different things.

Sending of structured data from the server to the client is probably best done using JSON, as that is the simplest standardized transport for sending data packets quickly and easily. That's done and done.

What it sounded like you were asking (when you mentioned styles and such) was for some standard way of embedding display markup outside of the data type itself. IE: You know a "room description" is a chunk of data, and the client will have some way of displaying that data. However, perhaps you want to make a particular word a particular color? If so, embedding HTML seems simple enough, since it's a well known standard for managing color/typeface/etc.

If you INSTEAD meant some abstract style like "print this room description in baroque style", well… that's something for you to add to your room data structure for the client to pick out. I doubt there's any standard that would be useful for that.

I, personally, would rather stab myself with a fork than push ANSI codes out and have a client have to pick them apart and deal with that trainwreck. At least HTML nests.
14 Feb, 2012, plamzi wrote in the 17th comment:
Votes: 0
Deimos said:
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.


Why?
14 Feb, 2012, aelyah wrote in the 18th comment:
Votes: 0
Deimos,

Agreed.

http://www.mudsings.com/easy-to-contribu...
The link above does exactly this: the JS code parses the telnet protocol and then "draws" the characters on the screen. The mud input/output is packaged "raw" in a JSON message with a basic protocol:

connect
disconnect
message

The "connect" message can carry host and port information. I decided against it for the same reasons Crat mentioned to EzBreezy - sometimes people are too creative. As all the requests are passing through an adapter I host, dealing with a "script kiddie" :) accessing a hm.. "remote resource" through my IP can be way more annoying than just restarting a messed up mud from an Amazon VM :)

For those who would like to provide a generic service, the client/server code can be easily fixed to achieve this. The original version of jsTerm has this ability: jsterm.com

As I said, all the modern browsers provide for a decent performance. IE7 didn't.

Hope this helps,
A.

PS: if you can implement this protocol on your websockets interface, I could try to point the client to your mud and see what incompatibilities we could find.
14 Feb, 2012, Twisol wrote in the 19th comment:
Votes: 0
Deimos said:
Is there any interest in standardizing this at all?

I have zero interest in preemptive standardization. Design by committee doesn't turn out all that excellently even in the "real world", and as far as the MUD community it's been a disaster (see MUDStandards). Come to the table with ideas, but don't expect anyone to agree to use them.

I'm still trying to figure out what I want to do for Aspect, but at one time I just sent the string with color sequences straight to the browser, and had a parser transform it into a style run for the renderer. Later I moved that parser to the server, but I'm still not sure if I'm happy with it. Anyway, the format was basically a JSON frame {"type": "text", "data": …}, with the data part being [{"fg": <0-255>, "bg": <0-255>, "italic": <true/false>, "bold": <true/false>, "conceal": <true/false>, "underline": <true/false>, …}, "text", …].
14 Feb, 2012, Runter wrote in the 20th comment:
Votes: 0
Twisol said:
Deimos said:
Is there any interest in standardizing this at all?

I have zero interest in preemptive standardization. Design by committee doesn't turn out all that excellently even in the "real world", and as far as the MUD community it's been a disaster (see MUDStandards). Come to the table with ideas, but don't expect anyone to agree to use them.


I agree. I don't see a point in this standardization. Mud clients for the most part accept the data as it should be displayed. It's sort of like the server generating an image and sending it to clients. It's a vastly different approach from the client understand what to do with data and only sending data down the line. Which is why people are saying json is great for this. Because it's really all you need. So what kind of standardization is there beyond json, which is a standard to accomplish this in its own right? If muds don't understand json, you can start by standardizing that and telling everyone to start using json. :p
0.0/66