10 Feb, 2010, Tlanuwa wrote in the 1st comment:
Votes: 0
Alrighty, I'm back. I'm unkempt and underfed, but I've got more of my blood to spill for you fine folks. :) I'm also going to post this in a couple of places, so sorry for the copy-paste routine.

As I pondered how to go about implementing the WebSocket protocol inside existing codebases, it occurred to me – why?

So I took PHudBase – the naked PHP-based MUD library I released yesterday – and converted the server code as was necessary, rebuilt the client, and BAM – MUD owners can customize an open-source, no-plugin, browser-based game client without having to TOUCH their own code (though they can to enhance the experience).

PHudBase-WebMud is broken into two pieces (much like the game engine is) – a client and a server.

The server is installed alongside your game's server on a free port. It acts strictly as a proxy – your players connect to PHudBase-WM, it connects to your game on their behalf and handles the nastiness of WebSockets for you. It also translates and strips out Telnet codes, to include translating ANSI color codes to simple CSS classes.

The client is almost identical to the game engine client I released yesterday. The demo version (which is live) allows you to connect to any MUD, but you can specify your own in custom installations.

The only time a game imp needs to even LOOK at the game's code is if you want to include custom features in the game client. Their are a couple of things to note here:

- You'll need some mechanism of tracking which clients are using the WebMud client. You can either have the client specify it, or you can have the PHudBase server send a message that you trap and use to flag the character automatically upon connection to your game.

- Any custom messages will have to be sent IN ADDITION to whatever you're already sending (so if you want to update the map when the player moves, that's a separate message to generate and send).

- The format for messages sent to the client is JSON. So if you want to write a message directly to the output window, you would send a string formatted like:
{"message":"John kicks a wily gnome's ass!"}

This is where things get fun. You can generate and send ANY kind of message that JSON can encode/decode and then handle it in the browser.

So if you want to send the client a map of the area he's in to render, you'd build a simple HTML table, encode it as JSON, and send it as {"mapdata":"the table"}.

Then, in the client, you'd check incoming data for the "mapdata" identifier and write the table to the appropriate area in your client. No big!

In this fashion you could do just about anything – friend lists, IM windows (tells), maps, click-to-play buttons (like the directional buttons in the client now) – just about anything.

And now I'm tired. This is just a beginning, and I'm not even sure how great a start it is. The whole damned thing is open-source (I'll get around to adding the license, but my website will clear you in the meantime), so at least there's a jumping off point for doing this right.

Checkout the PHudBase-WebMud page at http://www.phudbase.com/webmud.php, which has a screenshot and link to the demo (Google Chrome is and will remain required until the other browsers catch up, so this isn't really a "production ready" setup). There are some known issues, like not catching when the game server disconnects and a few stray telnet control characters (and probably some unknown problems), but the demo functions.

Then head over to the Google Code page and download it, then to the Google Group to tell me it doesn't work like I say it will. I'm going to go take a shower, find some food and cigarettes, and then, if I had to guess, get right back on this stuff.

Let me know what you think! I'm also still planning to write up the specifications for WebSockets, so if you just WANT to build it into your existing engine, you'll have that as a starting point.

- John

Edit for a new thought
I'm gonna make it even easier on you guys (and I'll add some detail in a bit on how this will work).

If you don't want to go through setting up the PHudBase platform on your server, I'll host it for you.

That's right – for the low, low price of FREE (for now), I'll run the middle man and you can customize the client to be whatever you want. Just put the client somewhere on your website and you're good to go.

Like I said, I'll talk a bit more about how this will work in a little bit (got everything done on my list except find cigarettes), and I'll probably have to charge for this service (like $5 a month or something) to offset my cost, but I can do it, so why not?

- John
10 Feb, 2010, Kline wrote in the 2nd comment:
Votes: 0
Very nice work sir, and now with this proxy option I will certainly play with it when I get home today (where I have Chrome, not avail here at work). Get a good writeup on the WebSockets for the game side of things and I'll probably add it to my base; why not, it can only help, right?
10 Feb, 2010, Tlanuwa wrote in the 3rd comment:
Votes: 0
Yep, and if you don't wanna do that, you can just point the client (designed however you want to) at my PHudBase server with no mods required. :)

- John
10 Feb, 2010, Scandum wrote in the 4th comment:
Votes: 0
Looks like it has some problems with a couple of background colors:

Looks like it has some problems with a couple of background colors:

[37;41mDemise 9am[37;41m Sp:Do[37;41m FX:WIHL[37;41m B[37;41m Al:-836[37;41m Lev:99
[37;44m [32;44mFTrTsi the Cat
[37;44m [32;44mF!!Demise
[37;44m [37;40mVoid

And the usual inability to do VT100 cursor handling.
10 Feb, 2010, Tlanuwa wrote in the 5th comment:
Votes: 0
Thanks for pointing that out! It's a quick fix (for the colors), I think, and as I've never (like ever) written a Telnet client before now, I appreciate the help. Which game is that you were testing on?

- John
10 Feb, 2010, Scandum wrote in the 6th comment:
Votes: 0
slackhalla.org:4321

'tac colors' is a useful command to get some background colors. The example was generated by typing: vt on, followed by: vt off.
10 Feb, 2010, Tlanuwa wrote in the 7th comment:
Votes: 0
Did I mention I'm new to telnet?

I've got some revisions to do. What's happening, in a nutshell, is that my server thinks the message is complete and sends it to the client, which is wrapping whatever it gets in an html DIV and spitting it out, whether it cuts off telnet codes in the process or not.

Upping the bytes read from the socket to 4096 (from 2048) helped, but there are still issues in some cases (like a slow response from the game server and a non-waiting socket read).

Thanks for helping me find this little huge problem – back to the trenches!

- John
10 Feb, 2010, Tlanuwa wrote in the 8th comment:
Votes: 0
Got a question – is there a standard "final byte" in the telnet protocol to indicate that a string sent by the server is complete? It seems like I read it somewhere, but it also seems like it varies. I need some guru-style help.

Let me take this moment to point out that this is an early-alpha release of the codebase. :-D

- John
10 Feb, 2010, Kline wrote in the 9th comment:
Votes: 0
Aside from some color mapping (what is dark grey in cMUD/zMUD/Telnet; black in your client) and a few alignment issues…Looking good :) Also, would it be possible to allow the client to send just a CR? I have situations like the MOTD screen and a paging system that require input to continue; any character will suffice but some have if( default == none ) do_stuff(), so people can just hit enter without typing. Oh, and I'm not certain if this is a client issue or Chrome, but after closing the browser tab I stayed fully connected to the game (not even linkdead).

Tested at games.ps.gotr00t.us:1234

f - f - [5mflashing     i - [7minverse[/code]
[code]| Hitroll: 0 Damroll: 0 |
[
0;36m| Alignment: 0. You are neutral. |
| |[/code]
10 Feb, 2010, Tlanuwa wrote in the 10th comment:
Votes: 0
Alright, a whole bunch of these bugs have been fixed and updated on the demo server and in the package download.

I fat fingered the spacebar and was replacing every TWO spaces with ONE, so yeah… the alignment was off…. That should be all better.

I've still got an issue I'm trying to work out with Telnet control characters being split up, but I'll get there.

Keep your issues coming – I appreciate your help tremendously!

- John
11 Feb, 2010, Scandum wrote in the 11th comment:
Votes: 0
IAC GA (character 255 and 249) marks the end of a line that isn't ended by the newline character, often in the following combinations: \n, \r\n, or \n\r. If you receive IAC GA the client should assume that all prompts (lines not ending with a new line) are terminated with IAC GA.

Optionally the mud can negotiate the EOR option, after which it should send IAC EOR to terminate prompts.
11 Feb, 2010, Tlanuwa wrote in the 12th comment:
Votes: 0
Thanks a million! I'll see if I can't figure out a better way to track end-of-transmissions with that info (currently the client – my server – doesn't do ANY kind of negotiation at all).

I've updated the code and demos (for PHudBase and the WebMud proxy derivative) with much, much cleaner WebSocket handling – dropped calls are no more (at least not that I've caught yet). It's also just a tad faster all around.

Also added the Creative Commons 3.0 license to everything, so you can feel safe taking and modifying. :)

- John
20 Feb, 2010, Tlanuwa wrote in the 13th comment:
Votes: 0
Sorry for my absence, folks – life's a bit crazy (we're moving across the country next week).

I have indeed been hard at work on the WebMud engine. I've got CPU load down to 5-ish% (tweakable to 1%, but you'll start noticing speed loss) and much better buffering/processing of data sent via the telnet connection between the proxy server and the MUD (and better handling of telnet codes, in general), so you shouldn't see broken lines or missing color sequences. MXP support is in (though it only actually does anything with <color> and <send> tags, but it's very easy to extend). It's not perfect, but it's a lot closer.

I'm going to re-package all of the source tomorrow and update the packages in the Google Code page.

I'm also going to start working on the details for a hosting package – I'll run the server end for you, you can do whatever you want with the client files (have your designers make a really pretty one that you host on your web server but connect to my proxy server). Even with 1-5% CPU load, however, it's going to quickly expend my resources, so once it stablizes, I'll have to charge to help cover the extra hosting cost on my end (and by that I only mean $5 a month, at the very most, and you won't ever HAVE to connect to my server. It's just easier on you to set up and maintain).

I'm having a blast with this (and I'm also back to actually creating – gasp – a game with it); I hope you'll have fun with it, too.

- John
21 Feb, 2010, Tlanuwa wrote in the 14th comment:
Votes: 0
Alright then, version 1.21 of the WebMud proxy server/client is now posted at Google Code:
http://phudbase.googlecode.com/files/phu...

Release notes for this release:
v1.21 - 20 Feb 2010:
– Marginal MXP support is in
– Correction to buffering in MUD connection, no longer breaks lines
– Correction to telnet color/general code handling – hopefully all fixed
– Many, many various little fixes
27 Feb, 2010, Kline wrote in the 15th comment:
Votes: 0
I must have missed this while I was out of town – I'll give the new version a good battering this weekend and see what I can break for you :)
04 Apr, 2011, Kregor wrote in the 16th comment:
Votes: 0
I'm kind of excited about this project, myself, as I'd love to wrap my someday to be released Mud server into a FaceBook app when the time comes. The problem thus far - and I think Scandum can echo this, because both our projects use a VT100 tactical interface with a mini mapper and etc - the tactical interface gets totally hosed by WebMud. It's nothing new, pretty much any Mud client I've ever tried EXCEPT ZMud or a straight pure telnet connection can't handle the VT. Once it can, you've got a winner, and something that could feasibly replace ZMud with a web-based alternative.
04 Apr, 2011, plamzi wrote in the 17th comment:
Votes: 0
Kregor said:
I'm kind of excited about this project, myself, as I'd love to wrap my someday to be released Mud server into a FaceBook app when the time comes. The problem thus far - and I think Scandum can echo this, because both our projects use a VT100 tactical interface with a mini mapper and etc - the tactical interface gets totally hosed by WebMud. It's nothing new, pretty much any Mud client I've ever tried EXCEPT ZMud or a straight pure telnet connection can't handle the VT. Once it can, you've got a winner, and something that could feasibly replace ZMud with a web-based alternative.


While waiting, why not take something like this or this and write your own HTML/JS renderer for the tactical interface? IMHO, MUDs with tactical interfaces should be especially excited to be able to show 2D graphics in the place of ANSI art.

If you're willing to take the plunge, take a look at my Facebook app, which contains both a minimap and a full automap (two different custom renderers). You can lift the code right off the page if it would help.
04 Apr, 2011, Runter wrote in the 18th comment:
Votes: 0
Quote
MUDs with tactical interfaces should be especially excited to be able to show 2D graphics in the place of ANSI art.


That's my thoughts on the subject, but they might not want to do the extra work to convert/create another system to maintain.
04 Apr, 2011, plamzi wrote in the 19th comment:
Votes: 0
Runter said:
Quote
MUDs with tactical interfaces should be especially excited to be able to show 2D graphics in the place of ANSI art.


That's my thoughts on the subject, but they might not want to do the extra work to convert/create another system to maintain.


True. Just brainstorming here, but it should be possible for the renderer to contain only basic 'wireframe' info and for the server to actually send, dimensions, links to images, etc. That way, most of the time you'd only have to change the server code driving the client. I doubt that the gameplay logic itself would change very often.

But there's no getting around extra work here, really. On the upside, you'd have something nice much sooner than (quite possibly) never. The OP hasn't posted in about 13 months, and there is no indication that they ever intended to support VT100…
04 Apr, 2011, Runter wrote in the 20th comment:
Votes: 0
VT100 is the future of mudding. If only the mudding world would catch up to 1980.
0.0/20