The Burden of Building Commands

Building commands are my least favourite thing to code, by a long shot. They take a long time to do, and they are invariably messy – they are the part of the code that deals with what the humans (that is the players) are doing after all, so they are never as “elegant” as the boilerplate code. In a codebase that is otherwise extremely object oriented, the building commands stand out as something necessarily quite procedural, and you just can’t avoid it.

I ran a tool over the source code that counts lines of code in different directories and files, and unsurprisingly the building commands make up as much as 40% of the entire lines of code in the project – just one building command, the “clan” command for editing clans – is half the number of executable lines of code as the entire prog system. I remember it took me nearly 2 solid 8 hour days of work to implement the clan command alone, and let me tell you, it is boring stuff. The actual clan system and functionality itself took me less time than that, and was much more fun.

In the early days of development though, I was definitely guilty of avoiding work on building commands – they were the last thing I would do for any new system I made. In fact, many of the systems that were completed the earliest still don’t even have building commands (and therefore have to be built in the database). I never needed the building commands to test things, because as the developer I would just hack something straight into the database. I knew the datastructures, and that was easier than writing a few thousands lines of building commands and doing it like a builder would.

However, I think that approach was harmful. That’s not how most people will use FutureMUD (at least it’s not how I want them to use it). When I have gone to make some of these missing building commands, I’ve found that the complexity is astounding – often because I never designed the system with how builders would interact with it in mind. Some of the systems will probably never have building commands and others might only be feasible with a GUI tool (it is actually surprising how some data types are stunningly easy to visualise in a GUI but staggeringly hard in a command line tool, but the reverse is also true too).

Lately I have been thinking about building commands from the very beginning with my systems. I’ve found that it has influenced the complexity of some of my systems – I have opted towards certain ways of doing things that might be different than how I would have approached it before simply because I anticipate how builders will interact with it. At some stage I actually implemented a few very good polymorphic structures that handle a lot of the common stuff like saving, revisions/statuses, and even a generic way of approaching the builders commands – for example, items, item components and npcs are all handled by the same commands but polymorphically respond to the types they are working with. This saves on a lot of code for sure.

Another thing I noticed was that I was using different terms to mean different things in different commands. In one command someone would SET a property whereas in another they would EDIT it. Sometimes you would create a NEW item other times you would CREATE a new item. Where possible, I have tried to standardise this terminology although there is a persistent incompatibility between a couple of core systems – for a few of the more complex commands you actually “open” an item for editing with the EDIT command, then the SET command acts on the item you have open without having to specify it. Many other commands however don’t allow you to keep a single thing open for editing and instead you must specify the thing every time.

Compare the following examples:

comp edit new food
comp set name food_baconsandwich
comp set calories 750
comp set water 10ml
comp set bites 5
comp set taste It tastes as crunchy, salted and greasy as a bacon sandwich should.
comp set description Food component for Bacon sandwich
comp edit submit
comp review mine
accept
item edit new
item set attach holdable
item set attach food_baconsandwich
item set name sandwich
item set sdesc a bacon sandwich
item set desc
It is a bacon sandwich: several rashers of crispy bacon sandwiched between two slices of soft, fluffy white bread.
@
item set weight 300g
item set size "Very Small"
item set material flesh
item edit submit
item review mine
accept

hedit new hedit Commands Building Help on the helpfile editing command
The #3hedit#0 command is an administrator command used to edit help files. It can be used to view information about helpfiles, create new helpfiles, delete existing helpfiles, and edit existing ones.

Syntax:

To view helpfiles:
#3hedit show <helpfile>#0

To create new helpfiles:
#3hedit new <name> <category> <subcategory> [<tagline>]
e.g. #3hedit new hedit Commands Admin The Hedit command for editing helpfiles#0

To delete helpfiles:
#3hedit delete <name>#0

To edit existing helpfiles:

#3hedit name <helpfile> <newname>#0 - to change the name
#3hedit keywords <helpfile> <new keywords>#0 - to set the keywords
#3hedit tagline <helpfile> <new tagline>#0 - to change the tagline
#3hedit category <helpfile> <new category>#0 - to change the category
#3hedit subcategory <helpfile> <new subcategory>#0 - to change the subcategory
#3hedit prog <helpfile> clear#0 - to clear the access prog
#3hedit prog <helpfile> <prog id/name>#0 - to set the access prog
#3hedit text#0 - to edit the text of a helpfile
#3hedit extra add <helpfile> <prog id/name>#0 - to add a new extra text
#3hedit extra remove <##extra>#0 - to remove an extra text
#3hedit extra move <##extra> <##newpos>#0 - to re order an extra text
#3hedit extra text#0 - to edit the text of an extra text
#3hedit extra prog <prog id/name>#0 - to edit the prog of an extra text
@
hedit prog hedit isadmin

You can see how in the first example of editing items and components you first open an item or component for editing, and then set properties. This is the way most items that have revisions and approvals built in to them work. On the other side, helpfiles (which do not have revisions or approvals) require you to specify which helpfile you are referring to in each building command.

In summary, building commands aren’t going away. I still find them to be thankless slogs and they are still my least favourite thing to make. However I have at least been able to make my life a bit easier when it comes to implementing them, which helps a lot. Sometimes I just have to suck it up and power through them – so that your builders can get to work.

.NET Core Open Source

I’ve been very excited by the direction the .NET Framework has been taking in general lately. From the new from-scratch reimplementation of their compiler Roslyn to the announcement of .NET Native and now the open source, cross-platform .NET Core. As ever, it seems the web and mobile developers get all the love because these things have been started in that sphere only. Meanwhile, us desktop developers get left twiddling our thumbs from the outside wondering when we’ll be let in.

However I was reading through the comments section of the article announcing .NET Core (http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx), and I found this official response to one of the questions:

@Jeremiah GowdyWill we be able to write console applications using .NET core / .NET native?

That’s something we’re working on. We’ll absolutely have the Console APIs available in .NET Core. In fact, I believe this one is coming online on GitHub in a couple of weeks.

The other part that you’ll need for running console apps is an application model that allows you to start & run your code. Currently, the only runner we have is ASP.NET’s console application template which is mostly geared for web workers.

As far as .NET Native goes: it’s on the list but we’re currently focused on scenarios that are relevant for touch based clients.

This is really exciting news for FutureMUD. FutureMUD really is just a pure console application that as far as I can tell, wouldn’t depend on anything at all outside of the .NET Core stack. I really hope that they follow through and create an application model for Console Applications because then FutureMUD would run quite neatly in the .NET Core stack.

Either way, as the Mono project is drawing heavily from the new .NET Core, it means that basically everything in Mono will sooner rather than later be brought up to the “First Class Citizen” level of support, which is good news all around for Linux compatibility!

FutureMUD Linux Compatible

Hi everyone, I am very happy to announce that FutureMUD now officially supports Linux as well as Windows. There’s no reason to believe it also wouldn’t run on MacOS now that I have fixed the Linux issues but I have no MacOS machines to test it on. This has been a very long road getting here – firstly the switch over to MySQL from SQL Server, with all its challenges and differences, as well as getting FutureMUD to work properly under Mono.

As it turned out, there must be some sort of bug and/or change between Mono 3.2.3 and Mono 3.10 which was causing the problems I was having. Mono 3.2.3 was the highest version that I could get working on both Windows and Fedora (which is what the server for this website runs on). This is because the Mono team made a breaking change in one of their mono updates that required a core kernel component to be updated to a later version, something that Fedora officially doesn’t support. Having FINALLY isolated that this was in fact the problem, I created a new droplet running Ubuntu and installed the latest version of Mono, and am happy to report that FutureMUD now runs on Linux! I was able to get it to boot, connect to it remotely and play around a little, although I did find out that one of the settings controlling email addresses in FutureMUD causes a problem on Mono because it is not properly implemented, so I’ve had to disable support for international email addresses (i.e. email addresses with unicode characters in them).

This was a relatively recent support change in .NET and has not come across to Mono as yet, so I can’t use it if I want emails to work on Linux. It shouldn’t affect most users, and if it does, they will simply need to sign up for a different email. I am running a FutureMUD dev server now on my DigitalOcean droplet, currently just on the $5 a month version. I suspect that this would be enough for most MUDs to host a website and the MUD while in the development / early stages, but if you get popular enough to get more than a few users, you’d probably need to go to the $10 a month one.

I think this is a fairly good outcome, FutureMUD should be cheap and easy to host. In fact there were only four things I needed to do to get FutureMUD running on the droplet (assuming you’ve already got your files there):

  1. Install Mono – I did this on Ubuntu with apt-get install mono-complete
  2. Set up your firewall to allow connections through the port you want to use. This was a relatively simple command in UFW which comes with Ubuntu by default – e.g. ufw allow 4000/tcp
  3. Edit the file Connection.config in your FutureMUD folder to the IP address of your server (can be found with ifconfig) and the port you want to use
  4. Set up a script to launch FutureMUD with your database details as command line arguments (I will ship a script with FutureMUD, you’ll just have to insert yours in there)

There is the distinct possibility that there are additional bugs added now by the reliance on Mono. Mono is not always a complete implementation of .NET, and there’s a possibility that some obscure piece of code calls upon something that isn’t supported in Mono. I won’t know about it until we run into it, so I’ll just have to test test test – but they should be MOSTLY easy to fix once found as I’m not really using anything fancy at all in FutureMUD library wise other than the Entity Framework (which is where I’ve found most of the Mono compatibility problems so far). We march ever closer to an inevitable Alpha. I’m very excited by it all.

Server Problems Resolved

As it turns out the server (in particular the Wiki) had come under a pretty heavy attack from bots. I disabled account creation on the wiki for now but in trying to install an extension to allow myself to mass-remove all of the bot accounts and their posts, I broke the wiki. However, I’ve decided to leave it down for now as it’s fairly empty and nobody is relying on it yet. I will tackle it again when I find the time.

Server Problems

As some of you may have noticed, I’ve been having some server problems. It seems the database keeps going down for some reason. I haven’t really had time to get to the root of the problem, I’ve simply restarted it when I’ve found it down.

Aren’t computers fun?

Why Not Open Source?

Some people may wonder why the FutureMUD project is not open source; indeed, this is something I have wondered from time to time myself. I thought I would offer my reasons as to why FutureMUD is closed source, and take the opportunity to reflect on the future.

Making Money

Clearly in most cases, if you were intending to make money off of something, it would make sense that you weren’t going to give it away for free. While for large companies it can actually be in their interests to make their products open source (see this article if you’re interested), in most cases for smaller developers it would not make a lot of sense.

That being said, I don’t intend to ever sell FutureMUD to anyone. I originally kept the option open because you never know, but the more I think about it these days, the more unlikely it seems. There just isn’t that much money to be made in the RPI community, and any income I did derive from it would be a drop in the ocean compared to my actual job. So unless some Oil Baron with money to blow and a deep abiding love of RPI MUDs comes along, FutureMUD will likely only ever be given away for free.

Does this include commercial MUDs? I don’t see why not. If you can convince players that your RPI is worth paying for in some way, well then, you have probably made a pretty damned good RPI and I don’t see why you shouldn’t be able to keep whatever profits you make. Thinking about it lately, instead of asking for a royalty (e.g. percentage) or some flat fee, I would probably just ask that each MUD that gets “successful enough” agrees to host at least one of the hard working free ones.

Why Make It At All?

I started FutureMUD to make the “RPI Engine of the Future”. As some of you no doubt know, I was the owner of Shadows of Isildur for a short while between Traithe and Kite. During my time, I was a big advocate of the RPI Engine and the code was freely available at the time (subject to the terms of the Diku, Harshlands and SOI licenses of course). I knew of, was loosely involved with, and even pondered several new RPI MUDs that were to be based off of the RPI Engine. Many of these had bright, motivated people with a great idea behind them.

Almost all of them failed to get off of the ground because they could not get enough coding support to make things happen, or, due to the inherent instability of the RPI Engine, never really took off. I ended up leaving SOI mostly for personal reasons, as I was no longer enjoying myself there and felt the need to work on something that was truly my own (rather than trying to keep alive something that was almost wholly someone else’s).

At that time, I decided that I wanted to make a new engine, from scratch, that while respecting the style of the RPI Engine, was free of its problems. Thus, FutureMUD was born. Actually, it was originally called LukeMUD, which was a working title. Later, when we ported LukeMUD to Windows, it became WinMUD. WinMUD was already an actual thing though, so the sub-title “The RPI Engine of the Future” ended up becoming the actual title.

I first started work on this in 2009. I believe it was late 2012 when we scrapped the C++ engine entirely and started yet-again from scratch in C#. The whole time the mission has been to get this engine out there and for people to be able to use it – not just myself, but anybody who has the time and patience to get a MUD running (you’ll need a lot of both, no matter how good your engine).

My original vision was to make an engine where “Literally everything was customisable without a coder” and “Builders had complete control over every aspect”: I’ve since realised that is a little bit pie-in-the-sky. At the very least, my mission is to make things as customisable as reasonably practical, and make it easy from a coding perspect to add options.

Why Not Open Source Then?

I like Open Source, I do. There are however two main reasons why FutureMUD is not currently Open Source.

  1. Control
  2. Uniformity

The first point is probably the most critical – FutureMUD is a labour of passion, many hundreds if not thousands of hours of my work poured into creating it and creating it a particular way at that. I want things to work a particular way in FutureMUD and I’m pretty uncompromising about it. I have had a hard enough time working with Kithrater and Case, who are close real life friends of mine, let alone a stranger with whom I share no real world connection.

I keep FutureMUD closed source at least for now because I don’t want to have to answer to anyone about how to do things. Case was recently talking about returning to FutureMUD and we were discussing elements of the engine that she could get involved in, and I must admit, every one of them made me defensive and think of the way I would want that done.

At this stage of the project, it would just be pretty hard to take in a new developer (or even an old one), unless they shared the exact same vision for the engine as me (and although I have much platonic love for Kithrater and Case, they do not share the same vision about how things should work in general).

The second point about Uniformity is that I don’t want FutureMUD branching off into a thousand different versions as each MUD gets their hand on it. That would mean that there would be a lot of work that only one MUD would get to benefit from, and it would also make it harder to distribute improvements made from my end. I have always said that if all those limited coding resources pooled their efforts, far more benefit could be felt by more people. I know that seems a little contradictory with my previous point, but I suspect I won’t feel that way FOREVER…

At the end of the day, I think I will eventually open source FutureMUD. There will come a day when I think it is more or less complete, and when someone else might come along with a compelling enough vision of how to develop it into whatever stage comes after the “Japheth Era”. At the very least, if I ever decide I’m no longer interested on working on FutureMUD, I will definitely release it. I’ll never leave the users with an abandoned closed source product, no matter what happens.

So You’re Not Looking For Developers?

Actually, I am still keeping an ear to the ground for people who might be interested. I’m just cautious about how I do it, and I don’t really have the time, energy or skills required to teach an amateur. But there are still things I don’t know how to do very well – in particular, I am not a web developer. I would really love to get a talented person out there who could help get up website tools / integrations for FutureMUD, as that’s outside my area of interest and probably too big of a distraction from the core engine for me to commit to time on at the moment.

As always, I’m also very interested in hearing about ideas from the people who would use the MUD Engine. Even bad ideas can inspire me to think about something I hadn’t considered (though by and large you guys have very good ideas).

But if you are some sort of wizbang .NET coder who has an amazingly similar vision to myself and you’re interested in contributing, well, perhaps hit me up and we’ll talk about it.

FutureMUD website now live

Hi everyone,

After many years of getting by with just the forum as an anchor for the FutureMUD community, we’ve now left the 1990s world of bulletin boards and entered the early 2000s world of websites, with blogs and such (scrolling marquees coming soon). In fact, we still have a forum (and also now have a wiki and a bug-tracker), which you can access in the menu at the top of this page.

I’m no professional website designer so please excuse the kinda stock feeling of this setup. Someday I may get around to hiring a professional graphic artist or something to give it a bit of a makeover, but in the meantime, a functional website will have to suffice.

I have decided not to migrate the old forums across here, and so you will need to re-register. I apologise for any inconvenience. Additionally, please bear with me as I get the new forums set up – I have more control over them now that they’re on this website than I did when they were on freeforums, so please feel free to make suggestions.