January 2015 archive

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.