AJAX Mud Forums - All Forums

Disecting Similar Projects?

Thu, 19 Aug 2010 03:13:21 -0400

Has anyone taken a look at, for example, AjaxChat or something similar and begun disecting it? I started an ajaxMud on my own last year, but my server went down and ... Well, just a lot of things kinda piled up against me (and now it's not working so I can't show it, but I think I might get it back up here soon).

But to start, I did dissect ajaxChat and went from there - a mud room is really no different than a chat room, etc. I did nothing on the side of AI, but movement was working, and you could see a box with the "characters" in said room, and tehre was an expandable/collapsable "room description" - all based off of AjaxChat really (though I wrote the code from scratch, I used ajaxchat as a sort of example).

The problem I ran into was trying to come up with a good way to automate AI.

Dojo

Wed, 23 Jun 2010 22:33:43 -0400

Have you checked out dojo.io.bind?
Its basically a wrapper around a bunch of different AJAX techniques. It might save you some time, instead of reinventing the wheel

Server-Side JavaScript engines?

Mon, 14 Jun 2010 21:31:14 -0400

I recently came across a powerpoint talking about HTML/JavaScript engine called Aves. During that, I saw a mention of NodeJS which then led me to the V8 JavaScript Engine from Google.

It piqued my interest into thinking that a MUD engine might be able to run via JavaScript on the server. The question that first comes to any sane person's mind is "why"? Well, I find JavaScript to be extremely robust. It's Prototype Object Oriented structure makes objects very flexible. Once could add methods to existing objects quite easily, extending them and enhancing them.

I can imagine a MUD where all development is done through the web (via a Web-Based IDE). The MUD Lib developers create the base library. The creators can then extend them quite easily. You could even incorporate event based handling to abstract it even more.

The possibilities are very intriguing for me...

MAAS: MUD As A Service

Sun, 13 Jun 2010 14:24:00 -0400

In my line of business (I'm a Web Development Manager), I deal with a whole host of new technologies coming (and going). One that I always found intriguing was the Web Service/Service Oriented Architecture (SOA) development model. In fact, one of my more important, and very visible to Upper Management, projects is a site that runs completely on Web Services to communicate and interact with legacy web apps. While the network traffic is higher for SOA style app, it's very scalable and easy to extend.

The other day I was thinking about this: MUD As A Service. What if the way MUDs are developed going into the future were not monolithic game engines/drivers with custom game libraries on them, but rather a core set of services that could interact with each-other. Of course, some standards would need to be written to provide a common communication, but it wouldn't be difficult to get together.

It's something that I need to think more about, but I thought it was intriguing...

Adobe AIR

Thu, 10 Jun 2010 18:31:25 -0400

Has anyone considered a default website that is used for browsing while the actual game-client is launched from AIR? (through a badge-installer if the client doesn't already have it installed)

Using Adobe AIR would standardize the use of web technologies such as javascript, css, and AJAX. More importantly XHR would be functional for all clients. Time-critical updates could be done through sockets, and data with higher priority could be cached client-side.

Unnamed Engine

Thu, 03 Jun 2010 03:52:46 -0400

This post is basically here to announce my relatively new [unnamed] mud engine. I've been working on the server back-end for the last two months (not including a month I spent handling basic design work).

I suppose because this is an announcement I should provide more information, but I hate to give away things before the appropriate time.

Once the engine is stable and complete it will be turned into a web service not unlike MudMaker.com but clean, responsive, and much more flexible.

The server is done in C and Erlang utilizing best practices for scalability and efficiency. The web-based client [and tools] are in the design phase but will have rudimentary skinning, layout, windowing, and eventing support.

The scripting language, which is also unnamed, took a lot of effort. I wanted it to be simple, but powerful, concise, yet readable. Most importantly it was designed to facilitate solo work and work in small teams, leaving off excess features that would just increase the learning curve. The scripting language has been designed with security in mind, to prevent exploits and endless loops by any wiz with the intention of making servers unresponsive. Right now all scripts are interpreted, and limited to a very small subset of the language.

There is a lot of non-technical features that could actually be called exciting. I hope when I make the project available a few months from now, others will agree with the aforementioned sentiment.

In the meantime stay tuned for infrequent updates every week from now on.

Edit:
...well...the engine is unnamed as far as any official titles go, unless you count the project's folder name (waffles) as being official. Don't ask me why I named the folder "waffles". I was hungry and it was 2AM at the time. No. Really.

Disk-based data

Mon, 24 May 2010 18:39:07 -0400

I recently encountered the notion of not storing any game-data in memory and instead using a completely disk-based system. I mean wouldn't this ensure, in the event of some catastrophe, that all player data is secure?

Yes and no. What about the *integrity* of the data. How do you detected if a DB is uncorrupted after a crash? What would happen if the server or game crashed while in the middle of a write operation? You could store multiple copies, caches that are then merged with the regular database at a later date but this sort of defeats the purpose.

It's easier to just do regular backups and only access the disk when needed. Disk-based access is slow. Even with fast hardware disk-access will be slower compared to volatile memory.

That and many systems today use portions of the HD as a simulated form of RAM, so in the event of a crash, you could potentially recover some of the lost data.

Tick (System updates)

Mon, 24 May 2010 12:21:26 -0400

I've played around with the idea of writing a PHP/AJAX mud for several years now. At one point, I had something that resembled a workable prototype, but ultimately gave up on it due to time restrictions. I picked up a few tricks along the way, one of which I will share in this post.

If you are using a Unix/Linux based system and want to dictate system events using CRON you'll find that the minimum interval you can have is 1 minute. The specifications for my prototype called for a tick at intervals of 30 seconds, so I found a work around.

First, you setup CRON to call your update script (/home/cron/update.php for simplicity),

Cron

Code:

## Updates on the minute, every minute

* * * * * /path/to/phpcli /home/cron/update.php

Then, in your update.php script, you call PHP's built in sleep function. Sleep delays the execution of code by N seconds.

update.php

PHP Code:

// Execute update function
updateWorld();

// Sleep for 30 seconds
sleep(30);

// Execute update function again
updateWorld(); 

AJAX Mud Client

Sun, 23 May 2010 22:36:38 -0400

Javascript is one of the most widely used programming languages in the world owing to the number of installed browsers that support it. Therefore it only makes sense that an environment (HTML, CSS, XML, JS) designed roughly to support interfaces (documents if you want to be technical) should be used to develop network-enabled applications-- Which is what brought me to ajaxmud.net recently.

At anyrate check out this link for an ajax-based mud client.

We're one step closer to a web-enabled mud

Email Notification has been fixed

Tue, 04 May 2010 14:04:51 -0400

Unfortunately, there was a problem with the email process and no emails were being sent. This has been resolved.

Server-Sent Events

Tue, 27 Apr 2010 19:56:15 -0400

So the past few weeks I've spent some time playing around with different techniques and reading up-coming standards. WebSockets looks promising. However, right now it's limited in support (Chrome is the only one to support it as of right now, but FireFox isn't far behind).

While doing all this reading, I started to put together a test server and playing around with a few different options. One that I'm working with and have had several good test runs is using a dual-channel method.

The way I have implemented this is by having one channel always streaming data back to client. I came across a draft on W3 for Server-Side events and loved how it laid things out. You can read the technical details here: http://www.w3.org/TR/eventsource/

What it basically comes down to is a stream of text content in which each block of data follows this format:

Code:

event: [event name]

id: [an event ID]

data: [the data in the event message]

If the data: line is repeated multiple times, then all the data is appended together.

It also includes an additional header: Last-Event-ID. This HTTP header is sent to the server to indicate what the last event ID that the client received. This is useful when a connection is re-established, which is suppose to happen if the server closes the connection.

A nice clean format and might eventually become a standard. However, even if it doesn't, implementing it via JavaScript is very simple. First I need to create a channel that would allow for streaming. Since all my tests are done in FireFox, I chose the XMLHttpRequest object. In the future, I'll use XDomainRequest object because IE's implementation of the XHR is a bit quirky (i.e. onreadystatechange not firing right for readyState == 3).

So I have an EventSource.js file that determines whether to use XHR HTTP Streaming or XDomainRequest object. It them uses that to open a ge channel to the server and start the streaming. Works great if your server is setup properly. I have a custom MUD Server that deals with that (and all the cross-domain permissions). Also, the Server gracefully closes the connection to the client every minute and the client re-establishes the connection.

However, there are some issues if this ever is implemented in the browser. The W3 standard doesn't make mention of the ability to set the request headers in the request or the ability to get the response headers. This is going to be a problem because right now I set a response header called MUD-SessionID so that when a client connects/reestablishes a connection, I know who they are. There are ways around that (i.e. use a query string), but I really like the HTTP Header method as it hides this information from the client unless they really want to see it.

As always, feel free to comment.

Fate: A Pike-based AJAX MUD Engine

Tue, 29 Sep 2009 08:51:51 -0400

I am currently developing a new MUD Engine called Fate (no, it's not an acronym). This is an engine that is written from scratching using Pike as the development language and Pike as the MUD Language as well.

I started with some proof-of-concepts seeing if Pike can be used to host a MUD environment. Given Pike's powerful features and access to the host-computer's resources, it was very important to me that I have a MUD Engine that hosts the MUD environment inside a sandbox. A sandbox is a virtual environment that prevents code inside the sandbox from accessing anything outside of the sandbox. All LP MUDs have this built-in because the MudOS/FluffOS drivers do this very thing. After playing around with all the features Pike has available, I got a sandbox running inside the Fate MUD Engine.

The next step was to develop the server component to allow for AJAX communications. The whole purpose of this MUD Engine is to be an AJAX MUD and if I couldn't properly handle AJAX communications, then it would be a waste. Also, and almost equally, important was the ability to hide the actual server behind a firewall/proxy server, but still allow communications with the MUD Engine and the web. I did this by using Apache's Proxy Module to forward all requests sent to a very specific resource (i.e.: http:///webclient) to the internal MUD Server listening on a specific port. This worked great and allows for multiple MUDs running on the same server or even a different server elsewhere internally. Also, it allows all the other HTML files to be hosted by an optimized and up-to-date Web Server, such as Apache, instead of the MUD Engine's poorly implemented version of a Web Server.

So here is where the Fate MUD Engine stands. These features have been developed but not yet completed and still need work:

Sandbox for virtual environment to protect host server
Loading and compiling MUD Library code (written in Pike/LPC-ish)
Simple Server to handle AJAX/Comet requests and tie it to a User object in the MUD
Implement a virtual file system which will allow for any backing of the files (i.e. local FS or Database).

These are the features that I want to work on next (as well as wrap up the above list)

A standardized API for Engine < - > Library communication (commonly referred to as applies and efuns in the LPC MUD world)
Object Management
A base MUD Library for other MUDs to build on instead of starting from scratch. This would be like DGD's Kernel Library.

Feel free to comment or ask questions.

HTTP Streaming testing results

Tue, 11 Aug 2009 13:49:35 -0400

In a few of my tests, I found that:

The HTTP Response should include the HTTP header Transfer-Encoding: chunked
When the HTTP 1.1 standard was released, Transfer-Encoding was expanded to allow for 'chunked' responses. Normally, when a client (i.e. your browser) requests a resource (such as an HTML page or an image), the server sends the complete content back to the client. The size of this resource (which is defined through the HTTP header Content-Length) is already known to the server. However, it became apparent during the first few years of HTTP 1.0 that the size of a resource may not always be known and the server needs a way of sending blocks of data to the client as they are received. This is where Transfer-Encoding: chunked comes into play. The way I do HTTP Streaming is by sending all my HTTP Headers first and then sending the Transfer-Encoding: chunked header next. At this point, I store the client connection object somewhere and exit out of my response method.

As data comes in that needs to be sent to the client, I grab the connection that I stored and send a string in the following format:
----------

----------

Please note that the first line is an empty line on purpose and that every line must end with a CRLF combination.

When the server wants to let the client know there is no data left to send, it simply sends the following string:
----------

0

----------
Again, the lines are left blank on purpose and must end with CRLF.
XMLHTTPRequest works with streaming, sometimes...
In Firefox, XMLHTTPRequest works perfectly fine because whenever new data is sent, the onreadystatechange event is always fired. However, in IE7, this is not the case. Also, certain versions of IE have ActiveX versions instead of native browser versions so if the browser has disabled ActiveX, then XMLHTTPRequest won't work in this case either. But fear not, there is another solution that I actually find works better than XMLHTTPRequest for most of my Streaming tests

Let's just say, though, that XMLHTTPRequest did work consistently among the main browsers. There is another annoyances to using XMLHTTPRequest: You have to poll/parse the data every time new data is sent down. Unlike the hidden IFRAME method (which will be described below), when new data is received, you'll have to find it yourself as there is no built-in mechanism to do it for already. While it's a fairly simple chunk of code to do this, it's just something else you'll need to implement.

However, XMLHTTPRequest isn't without it's merits. Native support for being able to set HTTP headers and to get the HTTP headers for the response as well as the status code of a request is a big plus. While there are work-arounds in the hidden IFRAME method, it's something you'll need to implement yourself.
The hidden IFRAME works all the time
Funny, but probably the oldest way of streaming HTTP also works the best. It is supported in all browsers with fairly consistent behaviors. Don't needs to poll the data as it comes in if you use messages sent to the client in a chunked transfer-encoding stream.

Ok, so we are getting these JS snippets executed. How exactly do we incorporate that into our page? What is generally done is that the JS code that is sent is actually a method call to a function defined at either the Window level or the parent document level. It would normally be structured like this:

Code:

This is the most common approach, but there are other ways of doing the same thing. Feel free to test them out.

So after doing a few different tests, I came to the conclusion that my HTTP Streaming should be implemented as such:
1) A hidden IFRAME is added dynamically to the page with an event handler on the OnLoad event to signal when the server closed the connection so that we can start it back up again.
2) The HTTP request that is sent via the IFRAME is a GET method with query string that lets the server know what the method is in the parent document that we will be calling.
3) Whenever data is to be sent to the server (as a POST) we will use XMLHTTPRequest to post the data and since we don't care what the response is (other than a non 200 HTTP response code), there isn't anything else we'll need to do.

There are a few things that needs to be reviewed further:
1) How long can the hidden IFRAME remain open for streaming before we start hitting performance and memory issues? 1 minute? 10MBs? These are all settings that can be modified at the server level or possibly be sent by the client in the request from the IFRAME.

2) Since there can be a delay in when data gets to the client from the server and anything can happen between the time the server sent the data versus when the client received and processed it (i.e. the user clicked a button that aborted the stream unexpectedly), the server should maintain a rolling history of past messages. Each message would be index and as they are sent to the client, those indexes are included. This way, a client can request a stream to start at a message by index to avoid losing any messages along the way when it restarts a stream.

Feel free to comment and/or add your thoughts to this.

Welcome

Thu, 23 Jul 2009 14:31:34 -0400

Welcome to the new AJAX Mud website and forums. Our goal here is to provide a place where MUD developers can discuss all aspects of developing a browser based MUD using AJAX or other asynchronous HTTP communications method.

Feel free to read and contribute to any of the topics posted. The only rules that we care about are:
- Keep it clean
- Keep it on topic
- Keep it civil

Enjoy