28 Jan, 2011, Sorressean wrote in the 1st comment:
Votes: 0
Hello all,

This is sort of an announcement on an upcoming engine, as well as to seek those who would be willing to help out with it.

Aspen is a mud written in c++, leveraging Lua as its scripting language, because of its light-weight footprint. (Ive considered adding support for python and letting the user choose, but Im really not sure at this point). The goal of Aspen is to provide a light-weight barebones engine that can be used to create any sort of mud, without requiring the user to rip out massive chunks of code (Smawg, Im staring at you), in order to get the systems you want. The advantages to this are two-fold; first, you can create the systems like you want them, without having to work around pre-existing systems, and you also do not end up having to rip out systems, patch the systems that depended on them, then patch your own in if thats the way you chose to go.

Beyond providing a good starting point, Aspen has many good features that will prove invaluable in creating the mud youve always wanted.

A modular system allows for you to create your code in modules, and then plug them into the mud. This promotes the idea of exposing a good API for the modules that will need to be interacted with, so that if any changes need to take place, it can be done from within the module. It also makes adding and removing systems a much easier process.

A components system allows for components to be attached to Entities (which are just game objects, inherited by living (npc and players), rooms, and anything else). Each component can access a set of properties on the object that they are attached to, so that exposing information to other components is very easy.

An easily-extendable command system allows for classes to inherit the basic Command class and build upon that. This makes for much cleaner code, because it means that you do not have multiple function pointers to functions, but everything is wrapped up in a class, which provides an interface that can be used to work with each separate command. This also makes commands easily extendable, as something can be added to the base class and then added to the classes that need it.

A full channel system allows for channels which can be changed to fit your needs, based on what you want. (still needs some work).

Aspen also provides an easy to use serialization setup, where all entities and associated variables can be serialized.

Aspen still needs a lot of work on many of the following:

Namespace-like properties: I want to change properties around so that there will not be naming conflicts for components, but every component will have its own namespace persey, which will contain the properties for components.

Aspen also needs the following:
1) Serialization needs to be converted from binary to XML (using Tinyxml, which is already included, or possibly something else).
2) Variable lists need to be finalized.
A good help system needs to be written, which will leverage the OLC to allow addition of see also, (which will be dynamically updated, if a help file is removed), a sort of markdown language to allow for formatting, etc.
3) Scripting needs lots of work, as its not anywhere near completion.
4) Rooms need a lot more work: mainly building commands just need to be written, possibly changing of exits.

These are just the quick things I can think of, though of course lots of work still needs to go into this.

Now, Ill answer the usual question that comes up when Aspen is mentioned: that of why I dont just use Nakedmud. And before anyone gets angry, these are just my opinions, and why I branched off to make my own base; I tend to hang out a lot in the NM irc channel and talk to everyone there.

1) Documentation is lacking quite a lot, and the code is not really clean, nor is it easy to read a lot of times.
2) Nakedmud isnt really naked, as I found out when I started to use it for the second time; the body system is a real hindrance to production when you start getting into clothing and armor and the like.
3) Nakedmud really hasnt had much in the way of updates; we hear about a patch from time to time, but its not there, and there is a lot of things that needs fixing.

While I cant promise Ill not fall into the trap of 3, 1 and 2 are already kind of solved; no assumptions are made about the mud, and no extra systems that would affect game play are built into Aspen. I am also not the worlds best coder, but I like to take time to do things right and make them clean before I release. While Aspen may be rough around the edges, Im planning on using any input and advice I get to make it better.

So, if you would like to contribute, or just check out Aspen you may do so; I moved it to googlecode:
If you wish to get in contact with me, you may do so through the following:
e-mail and msn: tyler (at) tysdomain (dot) com
As always, comments, ideas, suggestions, (and of course contributions) are welcome!

Edit by kiasyn: corrected link
28 Jan, 2011, Twisol wrote in the 2nd comment:
Votes: 0
The link is broken, first because of the period at the end, and secondly because it doesn't go anywhere. I found AspenMUD here though: https://code.google.com/p/aspenmud/

Will you be rolling your own telnet stack, or using a preexisting library? I'd really recommend using a preexisting library (like elanthis' libtelnet).
28 Jan, 2011, Sorressean wrote in the 3rd comment:
Votes: 0
I'll probably be rolling my own (that's on the to complete list); I know some people who can help out with it to make sure I"m doing it right, and not breaking things along the way, and it will also give me the chance to set things up the way I want.
30 Jan, 2011, Twisol wrote in the 4th comment:
Votes: 0
Can I ask why? Are you doing it just for the sake of learning to write a Telnet stack, or is there something about the offerings that you aren't happy with?
31 Jan, 2011, Sorressean wrote in the 5th comment:
Votes: 0
Both really, I don't want to include a bunch of third-party code in my lib, and I want to learn as well, so it kind of meets both requirements. :)