30 Sep, 2010, Sorressean wrote in the 1st comment:
Hello all, For quite some time, I have been working on a mud engine, (Aspen). This engine is built to serve a few purposes. First, I want it to be a light-weight, easily extendable system for someone to design a mud on. While I have tried many engines (Nakedmud, smaug, circle), I have noticed among many things a lack of documentation, or that I would need to go about ripping out code for one system or another to get the sort of setup I want.
Aspens purpose is to avoid making the coder(s) using it do this. The goal is to provide an easily extendable engine that can be added to without having to rip out systems such as combat, limbs and others to write in your own or make changes. Aspen will provide utilities such as an extendable OLC, and a component-based system that will allow for someone to quickly start adding in their own modules.
I have been a bit worried about releasing this so far, because it has so much work that needs to be done on it, but I have decided to take the dive and go for it. This isnt an official release, but a request for anyone with c++ and/or lua experience to help out wherever they are able. Currently it is just me working on the base, which tends to make development go a lot slower. So I am looking for someone with any sort of experience to contribute, so that this might be opened up for the public and stable use sooner, rather than later.
If you wish to look at the code so far, you can check it out from subversion with: Svn checkout svn://tds-solutions.net/aspen/branches/unstabl.... Because we use openssl, I have not worried about getting Aspen to compile on Windows currently. However, this is a goal I would like to meet so that those developing on windows can use it as well.
Along with the source is a todo list located in docs. Any contributions will be noted, and credit will be given in a credits file, as well as on the website when that gets updated (which will be before the first public release). I would like to avoid long-winded comments cluttered throughout the source noting that x contributed code here, so I will just confine those to the credits file.
If you have any questions, comments, or suggestions please feel free to post them here, or you can contact me: Irc: irc.freenode.net #aspen-mud msn: email@example.com email: firstname.lastname@example.org aim: st8amnd2005
Without meaning to be offensive or rude, do we really need another codebase? What does this codebase offer that others don't, and can't be fixed by properly documenting other MUD codebases, or by patching them?
I guess what I'm asking is, what do you hope to accomplish with this, which hasn't been done before?
30 Sep, 2010, Sorressean wrote in the 3rd comment:
I thought I had mentioned that in my post. I have yet to see a nice easily-customizable barebones base. Smaug is possible to work with, though it's setup is kind of messy, and I haven't found anything that really fits what I want in a base in terms of barebones.
I've looked at numerous bases, but I really don't relish the idea of say, ripping out magic from smaug. I can hack and slash it out, but in the end that's just going to make things way messier.
.. No, I'm not. You said "I havent seen a good barebones codebase". I pointed out a barebones codebase that in my opinion is good, and asked: What does your codebase offer that these other ones do not? How is it different?
It's a valid question. We already have a very saturated world with several codebases: DikuMUD, ROM, RaM, the (much-maligned) NiMUD, Smaug, Godwars, TinyMUD, LPMud, PennMUSH, NakedMud, CircleMUD, TBAMud, etc etc etc. So … how do you stand out? How do you differentiate yourself from those codebases?
: Okay, the last bit was probably more abrasive than was neccessary. What I'm basically trying to understand, is what you're trying to accomplish, that hasn't been done before.
Rudha: His answer is valid. The level of documentation and 'cleanliness' of the code in your aforementioned codebases doesn't meet the standard of quality Sorressean is desiring. You didn't really list a bunch of different codebases, you listed a bunch of development forks of early codebases that all 'suffer' the same fundamental flaws. Licensing, hit-and-miss documentation, contribution from a large number of developers who employ different coding styles, methods, and standards of code.
Sorressean: If you can't clearly distinguish what your goals are and how they are unique to the many other projects already being developed, it's going to be difficult to attract support for your project.
Saying, "Don't code something because there are other similar projects" doesn't make sense. Saying, "Don't solicit aid on your project if you can't clearly identify why your project should attract help and support over other projects" isn't unreasonable.
Best of luck.
P.S. My two cents: Stick with linux development. Maintaining concurrent linux/windows ports of the same codebase is a lot of extra work with, in my opinion, little draw. Most developers will be using a nix system. It's a little wishy-washy to simply state, "I'd also like to make it available to developers on windows." without having thoroughly assessed what's required to make it compatible, and moreover, to maintain compatibility as the project matures.
It's just that if you don't like the level of documentation in a given MUD codebase, then why not rectify that problem, by writing documentation, or prodding people until they write that documentation? While writing an entire codebase from scratch isn't the biggest programming project out there, it's nothing to shake a stick at and it is not easy to pull off.
But yes, LockeWarrior said it better than I can: it would be beneficial to clearly define your objectives and goals. Saying "I dont like this codebase" makes me wonder, as I said above, why you don't just address that issue directly, whereas if you instead give a clear design outline of what you want to do, it kills two birds with one stone: it generates interest in that codebase with a clear vision, and secondly, it tells us what you think the codebase would offer.
30 Sep, 2010, Sorressean wrote in the 9th comment:
As I said, I want my mudbase to be barebones. As far as I know (And I havent used all of those bases), the only one that comes close to that is Nakedmud. So lets talk about nakedmud a bit.
About three years ago, Nakedmud was c and you had the option of going c or python. About a year and a half ago, maybe more Hollis seems to have decided to jump for Python, and Nakedmuds core isnt being developed much, with everything being made in Python. This sort of defeats the purpose of it for me, as I wanted the engine and its core in a language like c or c++, with all the cosmetics being done in a scripting language such as Python or Lua. The documentation currently in existence last I peeked at Nakedmud was pretty minimal, and the comments in the source are lacking quite a lot. I have also found the code kind of messy and hard to extend, if I wanted to do something like add commands to objects. It could be done with a bit of copy-paste work and some tweaks, but I would be essentially expanding on code that already needs some cleaning up.
While Nakedmud may be good for some, I personally dont like the way it is set up, thus Aspen. I will be the first to admit; Aspen does need a lot of work. But with help or on my own, I hope that it will be able to be in a working state, and be something that people are able to use.
I hope you realise too, that even if you didn't like NakedMud (or any other codebase), being specific about what you didn't like can also help that codebase too, because it tells the developers where they can improve :) So thank you for specifying.
The naturally following question is, how do you plan to approach things differently in your own MUD to address that?
I'm not trying to come off as aggressive and I apologise if I do; I'm just trying to get a better idea of what you're going to do and how you plan to do it, and perhaps encourage you to think about it some; as LockeWarrior said, most existing MUDs are fairly dated and suffer from a labyrinthine amount of licensing and differing development styles and approaches, so a new, sleek MUD codebase wouldn't be a bad thing, it is the appeal of NakedMud to me, that and it's public domain. I'm not trying to shoot you down here, I'm trying to (in my own way) help you be successful by thinking out your methodology and objectives some.
01 Oct, 2010, Sorressean wrote in the 16th comment:
Rudha: I understand, I just wasn't sure of your motivation behind the questions. I was initially worried about releasing this because I didn't want it to be seen as "just another base." So, I'll try to explain. Feel free to ask more questions and give me a kick in the right direction. ;)
First, I started trying to work with smaug as I really like working with c/c++. Part of my motivation was due to the dificulty to modify something and do it cleanly without having to hack-and-slash and make it look like the rest of the code. I'm a bit pedantic about my code, and try to code to the best of my abilities. This means that I really can't justify the usage of lots of "reserved" variables as you'll see in some of the structures because even though it is just a few more bytes of memory, I don't like to see it wasted due to bad design.
So, here's what I hope to accomplish with Aspen: First, I have created components as a way to add functionality to objects, without having to add code to each object. For example, if you wanted a container to be clothing, you would have to make all clothing inherit containers, or just put container or clothing functionality in the main object. With a has-a setup, as opposed to an is-a setup, it allows the developer to make a weapon and make it be a container if they so chose, without having to mess with a huge inheritance structure. I also want to keep it barebones, and just provide utilities for building and creating the mud. I don't even plan to add bodies, races, or limbs; what if the coder doesn't want any of this? Of course components can be created and distributed, I just don't want people to have to remove things they don't like.
The goal so far is just for a barebones base; I never liked the idea of magic, and tended to run screaming from any base (like smaug) that has magic imbedded so deeply into the internals.
So, in answer: I'm hoping to provide a nice, clean, well-documented easy to extend base, with Lua for scripting. I chose Lua because of it's small footprint, and ease of use. Please feel free to ask more questions/give more input, I would like to be a bit more defined if it means I'll get more people looking at this; I'm just not sure what is wanted at the moment.
Here's my take on the subject. Obviously as someone who wrote yet another codebase I cheer you on to that end.
What I really am perplexed by is why you would want as much of the codebase as possible written in C. This seems to be at odds with your design goal of wanting something modular and compartmentalized. If you indeed want it written in as much C as possible just write it all in C.
Something people often don't understand is the trade off for using multiple languages in one project. You often get simplicity for rapid development at the cost of complexity to the uneducated end user. How many new mud devs know C and Python both?
So in my opinion the solution that LP muds use somewhat solve this. That is pushing so much away from C that you don't need to know C for most things.
So my question to you is why do you prefer nakedmud doing most things in C? What advantages is there when compared to doing most things in python?