So, there we go. I started a new project and so write a new article here.

It’s something interesting again, and something on the same tracks as before in some ways. I love MUSH’S, and I somewhat dislike the language used with them (known as MUSHCode).

I tried to work around this by making me a nice IDE to work with the code but honestly I didn’t had much luck with that. It worked but it didn’t really helped as much as I hoped.

Well what to do? I figured if I can’t make writing MUSHCode less unpleasant I just find a way to minimize the need for it. So I started to write a own MUSH server. Of cause in Ruby. I plan it to be highly modular, and based (beside a very basic core) based on plugins.

Don’t get me wrong, there is a place for MUSHCode, it is the best language I ever found to do the so very important ANSI/ASCII interfaces that make MUSH’s what they are. So there will of cause be the option to use MUSHCode.

Actually I went a step further and made languages a plugin. Sounds nice doesn’t it? But more interesting is what it means. But later more to that.

General Layout

Lets start out with what Ruby MUSH is designed. It features 3 layers of code. Each layer has it’s own reason for existence and it’s separated tasks to handle.

The Core (layer 1)

From first, the core code that is very generalized to make sure the upper layers are not restricted by it. The Core itself handles the whole network mess, aka connecting players, keeping track of connections, closing them, database handling.

Also and perhaps most important it gives the interface for the second layer, it manages the plugins and gives them the interfaces and access to all the data they need to do their jobs. Beyond that it doesn’t do anything, no commands, no functions, no languages.

The Plugins (layer 2)

The second layer are the plugins. They are written in ruby, and on the server so they are pretty close to the core due to that, they have full access to all data they need.

I will go into details about the different types of plugins in a bit but first some general things. There will ship plugins with the Ruby MUSH core, those plugins are either essential for the server to work or I like them so much that I included them and think they are worthwile for every place to have around.

People may now ask, why won’t I want to include all plugins in the server that one can find? There are three answers:

There may be conflicts between two plugins. Coder a) might have written their supper cool board plugins and coder b) might have written a plugin too that handles boards both use the same commands -> Kaboom.

Every plugin may have a security hole, the more plugins that are loaded the more possible security risks are there so if you know you won’t need space code in your medieval themed MUSH don’t use a space code plugin.

Finally each plugin has a memory footprint and as an impact on speed – so keep plugins out that you don’t need it will keep your server faster.

Command Plugins

Command pluins are plugins that offer commands for the users of the MUSH, an example here are the login commands that are commands offered to the user prior to logging in. A board system would be a command plugin, a chargen would be a command plugin …

Function Plugins

Function plugins are plugins that bring functions, they are either used in the third layer or within the other plugins they are automatically offered within other plugin code. An example for a simple function would be math functions as sqrt that shall be usable in the 3rd layer for softcoding.

Class Plugins

Class plugins are data types used mostly withinthe second layer, the List class is a class plugin, as is the string, an error, a player, a thing, a exit and so on.

Language Plugins

This is perhaps the most interesting part, layer three languages are nothing but plugins. They are mainly compilers that compile the code into a meta lange that can be interpreted by the VM that the layer one brings along.

The big advantage about this is a) you can have any language you wish to as a layer three language. Currently a MUSHCode compiler and a Math compiler that allows interpreting mathematical terms. also b) the code is pre-compiled and the execution of it is faster after it was compiled the first time. Also they are interchangeable, meaning, due to the meta code in the end is the same I easily can call functions written in language A out of language B.

The Softcode (layer three)

Due to what softcode is, just a plugin it is very flexible, Softcode can be (theoretically) everyting from brainfluck over MUSHCode to mathematical term.

It can be written within the server as parts of attributes or (at one point) as commands and so on.

Last words

So I thought about what would make people use this server, and what not so – and this are only guesses – I made up some pro’s and cons compared to other servers. I could not check any of this really so they are theoretical and what I expect.

Pro:

• adds another layer between hardcode (core) and softcode (layer 3)
• Plugin based so easily expendable

Cons:

• More memory footprint
• Slower core (I’m not sure how plugins are a gain over softcode but I assume so)
• Slower softcode (I don’t know if the metacode speeds thigns up enough to make it a match for pure C code but I doubt it)