As you may have guessed from the title, today’s post is about why we are making LabMUD. We’ve already established that LabMUD is a “flagship” for the FutureMUD engine, but what does that really mean? I am sure that there are many questions as to how the MUD will be run and what you can expect as a player, and I will try to answer them here.
The story starts with FutureMUD, the engine that LabMUD runs on. I am the primary developer of FutureMUD, and that remains my main role. I won’t dwell too long on FutureMUD here, but in essence I have reached a point in the development of the engine where I need some hardcore real world testing – not just to find bugs, but to actually test the look, feel and balance of the engine itself. There is a limit to how much of this testing I as a developer can do, and I also know the engine intimately – so things that seem obvious and easy to me may not necessarily be so to someone else. So, I realised that I needed at least someone running an real live FutureMUD server to provide me with this feedback.
Once people start using the engine, they will have feedback – bugs found, issues raised, changes requested. That will drive development for a while, and that’s all good stuff! If that was the extent of it, I’d be looking at releasing a general Alpha right now. What has actually emerged though is that this is a new engine – and that means nobody is familiar with it. On the player side, it is very similar to existing Diku-style MUDs, and few RPI players should have any difficulty figuring out what to do, even intuitively. Unfortunately for admins, that is not the case from the admin side – it is very, very different. Additionally, I have not really documented a lot of this stuff and even I forget it half the time (and have to go looking in the code). Up to this point, I also wasn’t 100% sure what was absolutely necessary for the MUD to run – the bare minimum world file I could ship for instance.
As such, I figured it would be easier to have a Flagship MUD for the first few months. This would be like a limited sandbox for the engine – I could get the feedback and testing I needed without being TOTALLY overwhelmed by supporting a dozen people setting up a MUD in a brand new engine from scratch. It would also buy me some time to write documentation, and also to polish the admin/builder experience before the community got its hands on it. So, I started thinking about who should make the flagship – certainly I didn’t want to do it myself, because I couldn’t commit the kind of time and energy that the MUD needs without sacrificing development of the engine. Long ago when I first started thinking about this my idea was either to have Kithrater build something or Methuselah (probably the longest-serving and most active follower of the FutureMUD project). Kithrater however isn’t interested in MUDs anymore and Methuselah is now fully committed to SOI. SOI itself was also a candidate, and while I would one day love to see FutureMUD edge out the RPI Engine even for existing MUDs, it is most definitely not there yet.
So I asked Wolfsong (my wife) whether she would be willing to make a MUD. She had some conditions of the readiness of the engine, but we eventually got there and so it came time to select which MUD to make. Both Wolfsong and I have several MUD ideas for MUDs that may eventually get made. We mulled over making a few of them, but what we realised was that they weren’t good matches for this kind of project. I really didn’t want the pressure of the flagship being someone’s “dream”. If things didn’t go perfectly, if core systems weren’t in place, if there were bugs and instability…I might ruin someone’s shot (or even my own shot) at making that MUD they’ve always dreamed of.
We realised that the flagship MUD had to be nobody’s dream MUD. It should be a MUD that is easy to make, easy to document, easy for players to get into, and easy for everyone to shrug off or let go if it becomes necessary. It still would need to be gripping and engaging, but it didn’t need to be our Magnum Opus of world building and setting, a MUD that would stand the test of time. It just needed to be a place where players could go and explore the engine and tell a story.
LabMUD is just that – it’s a Lab. You all are the test subjects, and the engine is the test. The theme is designed so that we can introduce new engine features and have it be remotely in-character. It’s also designed to require very little day-to-day admin intervention (something I am a big believer in). Of course, we will run RPTs and events and such, but hopefully most of the game’s events will be player driven. In future posts, I will comment on what you as a player can expect (our promise to you) and also some thoughts on fairness in testing outcomes.
Just to clarify, Wolfsong is the Head Admin for LabMUD. She has the ultimate responsibility for decision making, building, plots and the like. I am also an admin here, but mostly to teach her about the engine and get a perspective on how people are using the engine. Krelm may be doing some building for us, but won’t be an admin once we open (his choice – he’d rather be a player).
Towards the end of the LabMUD project (which might be months or years – who knows), I will probably also invite other people who are serious about using FutureMUD for their own projects to the staff for the purposes of training them. I won’t be doing this at first though because I want to give the MUD a chance to be a real MUD before it is a training ground. Wolfsong and I will probably be the sole admins for the MUD for now.