Unnamed Engine

[York]

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.

[krem]

So why did you opt for your own scripting language instead of another pre-written and well-established one? Not being critical, just seeing how your thinking.

[York]

(06-05-2010 05:42 AM)krem Wrote:  So why did you opt for your own scripting language instead of another pre-written and well-established one? Not being critical, just seeing how your thinking.

I spent a significant amount of the planning phase in the investigation of various scripting languages--something, in retrospect, I regret because I could have got much more planning done in other areas that now seem lacking.

The key issues were *relative* efficiency, both in performance and translation to Erlang VM code (BEAM), flexibility, and security. Certain concepts in candidate languages, including both Lua and Pawn, though efficient, did not map well to the task, namely scalability.

I don't want to force any future developers to have to resort to kludges, or the purchase of extra hardware in order to scale a game...even if I don't reasonably foresee such a situation. It is better to be prepared than caught off guard, and I can't assume future developers using the system are only going to stick to designing MUDs with little content, and small player bases.

Another key issue was security. For example, if you look at Second Life it is easy to see the kind of abuse involved. Way too many people spam objects that are specifically scripted to slow the system down, and hog bandwidth. While these problems can be mitigated to a degree with proper moderation and restrictions upon the scripting environment, it is far easier to design a language from the beginning with these issues in mind instead of resorting to solutions created for a different set of problems.

Finally it was important to create a system that would be flexible. Namely the learning curve could not be too steep, and the language had to be usable both by a sole developer, and teams large and small. If the learning curve was too steep only experienced developers would consider using the system and area creators would be put off from creating highly dynamic rooms. If the learning curve was too shallow large teams or serious developers might consider the system a toy, while the language would lack facilities for quick and time-efficient prototyping.

I knew also that I couldn't afford to ignore any particular programming paradigm just because it may be unpopular or because I'm unfamiliar with it. What we know today about current paradigms is thanks to the efforts of researchers in the past who recognized some useful property inherent in each language model. I've struggled to incorporate concurrency-oriented , functional, object-oriented, and actor-oriented programming features, taking what is good, and leaving the dross wherever possible.

I'm paying careful attention to efforts made in the past (and ongoing) to integrate the aforementioned paradigms. I noted a lot of interesting language features, that, by themselves, look like great ideas, but when placed in the context of a whole, don't mesh well.

An example of ideas that don't mesh would be fine-grained concurrency between actor objects built on top of Erlang (light-weight communicating processes). Normally this would be impossible. However I'm in the process of incorporating linear types into the Erlang VM which allow an actor-object to create a "thread" and communicate with another such thread (currently atop the VM) without encountering race conditions. When linear types are fully implemented I'll work on allowing Erlang processes to act as references to threads created through an external C library for efficiency allowing true, fine-grained concurrency in Erlang.

[krem]

Sounds like you did your research. I would only caution against doing a custom scripting language because there are many existing projects out there that will do much of what you are looking for without having to do the work yourself. Heck, even Pike would be good.

[York]

Believe me there is nothing more I would like then to *not* reinvent the wheel. Which is part of the reason I resorted to Erlang. Not only did my performance tests indicate it was the ideal candidate platform for the task at hand, many other similar tests posted online indicated likewise.

I chose erlang, and by extension, the erlang VM, as a platform, not only for the server, but for the custom scripting language, because of the libraries already available (OTP) and Erlang's excellent architecture.

There are many critical factors to consider when deciding which software to incorporate into a project. To name a few: software license (not just free, but the restrictions upon modification), community size, community involvement, active software contributers, software stability, software portability, library interoperability, software age (if it is too new, or too outdated), whether or not support is fading, speed of response for support requests, whether or not commercial support is an option, available documentation, completeness of documentation thereof, etc.

There was one candidate I did strongly consider based on portability, flexibility, efficiency, and feature-completeness but it did not fulfill most of the above requirements so I decided to create my own scripting language. Yeah a new scripting language doesn't fit most of the above requirements but at the very least I have control over that fact.

For a good example of software (albeit a *library*, not a *language*) check out POCO, which is a portable C++ library that I am madly in love with.

[York]

A quick update: Linear types are working with no obvious bugs
I'm sure it won't stay that way for long.

In the meantime I'm implementing the C threading library.

[York]

I suppose now that I'm making progress on "Waffles" the mud engine, I can go into further detail.

For starters Waffles (yes I know the name is ridiculous) is a web-based engine, formally known as a SAAS (software as a service).

Developers can signup for the service and begin to create a MUD utilizing a multipurpose scripting language. Developers will also have access to a wide-array of prebuilt and community-created components.

Components, scripts, and other developer-centric data are stored in a disk-based cache that looks like a desktop. This is called the "dock" to distinguish it from client-side terminology that refers to the virtual desktop of the actual OS versus the server-side desktop that the clients web-browser interfaces with.

Developers create new MUDs and worlds by utilizing a hierarchy modeled after theater. All objects in a new MUD are represented by Entities or objects derived from Entities. The three inheriting objects are: Actors, Scenes, and Props. Each has certain innate functions, apart from the update() function inherited from Entity.

Actors are subdivided into Avatars, and Mobs. Avatars have functionality to handle player connections, security, and other client-oriented issues, while Mobs have self-contained behaviors-trees amongst other components.

Scenes may be nested and subclassed as necessary, creating metaclasses such as "area" "room" "zone" and so forth, instead of restricting the developer to a rigid room structure. Additionally scenes may have fixed attributes that may react or change according to certain conditions. These attributes may change in *value* but cannot themselves be changed.

Finally Props represent objects that are reusable, have functionality not directly related to the scene, can be spawned, and can be potentially carried or interacted with through verbs or "actions". What is interesting is that despite the fixed and limited nature of scene attributes, a prop may itself be used as an attribute thus allowing a developer to greatly extend and supplement scene dynamism.

An example would be the difference between scenery, perhaps a river (facade attributes) versus a prop lever. The facade could change based on rainfall, lowering or raising the river depth, however you couldn't remove the river such that not only is the water gone but the river bed as well.

A lever (which is a prop with a switch attribute) could be turned "on" or "off", or even removed if the developer provided the lever with an attribute that specified subcomponents providing a whole new level of interactivity as compared to the facade attribute.

On to more interesting things: Developers can create tools for developing a MUD and share them as a list of linked components with config files. Additionally certain prebuilt tools will be provided, such as an interface builder and scene mapper.

Clients will be able to utilize a limited browser-based client that communicates through a number of methods, including AJAX, or flash-proxy as fallback. Clients that are interested in storing hotkeys, utilizing client modifications, or enjoying a more consistent, media-rich experience will have the option of installing an Adobe AIR client.

Finally developers will pay for hosting based on the number of active and stored entities, much like the popular NFHost, where you only pay for what you use. Developers that choose to purchase membership in addition to having money in their account for hosting expenses, will also have the option of selling in-game items or exclusive services to their players to support the upkeep of the game. Sales will be made through one of many possible web-based micro-transaction systems such as mochi-coins.

Now that I've revealed a portion of what is in progress I hope whoever is reading this is at leats half as excited as I am about the project.