Fate: A Pike-based AJAX MUD Engine

[krem]

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://<base URL>/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.

[krem]

Things have been moving slow on this project. The latest item I was working on is something very important: Object Management.

All instances of MUD objects have an Engine side class (called MUDObjectInfo) that is used to store information about a MUD object. Information such as who the 'container' of the mud object is, what other mud objects this instance 'contains', if the object is bound to a connection, etc. Container/contains refers to the results of the LPC equivalent of environment() and all_inventory().

Doing proper Object Management in the Engine is vital to the performance of any MUD. Being able to quickly reference and/or find objects is key to quick responses to commands and events. The method of implementation that I'm trying right now is simple:

When an object in instantiated, I instantiate an instance of MUDObjectInfo and add it to an internal mapping variable based on the unique hash value of MUD object. Since the only way to access a MUDObjectInfo (although it's indirectly and never actually returned at any point) is through the API and usually the object in question is passed, it's easy to get the hash value, look up the MUD object's MUDObjectInfo in the mapping and then quickly get the information needed.

[York]

From what I understand Pike is inspired by LPC. I used to mess around on MudOS before support withered. Overall it was pleasant to work with.

So is this project still active?

[krem]

(05-29-2010 12:13 AM)York Wrote:  From what I understand Pike is inspired by LPC. I used to mess around on MudOS before support withered. Overall it was pleasant to work with.

So is this project still active?

Both Pike and my attempt at a paradigm shift in MUD Engines are active.

Pike's user mailing list is active and quite helpful.

[arthur]

Hi there!

I along with a few friends are looking into doing a Pike-based text et al MUD-style virtual reality server... I would like for it to support both AJAX, telnet, and other network protocols, including a future OpenGL rendering layer (probably not in Pike but unknown).

Thus looking for related projects to ease my transition into Pike. I have a good deal of LDMud and MudOS experience, as well as some Java, and bits of others. We are currently running a startup MUD-corelibrary project with LDMud but considering moving to a more industry-grade language and framework.

This Pike FateMUD seems very interesting from your present descriptions! I would love to know more. Also, do you offer the Fate source code? Thank you.

[krem]

I'm guessing you are the same person who posted this question on LPMUD. I played around with pike for a while trying to get a good sandbox model going. The problem was that there was always something small that caused a less than ideal situation. The last item I was dealing with is coming up with a base system object that was hidden from the MUD library so that the kernel could interact with it and get attributes from it.

Pike is very flexible, like LPC. But that flexibility and years of flux has taken a toll on the easy of use when it comes to Pike. I abandoned it to look into using Google's V8 JavaScript engine, NodeJS, and Socket.IO for my kernel. It's looking very promising, especially with Socket.IO which makes abstracts the AJAX push implementing technology from NodeJS. So if you have WebSocket support, it uses that, otherwise it falls back to Long Polling, Forever Frame, or FLASH, depending what fits you best.

I would recommend looking into that instead of continuing down Pike.