I haven't sent out a newsletter since the first one in 2016, but that doesn't mean there isn't any news.

I thought it would be worth addressing the question: "Why upgrade to SmaugFUSS"? There was no getting around the fact that some sort of upgrade from our old Smaug 1.4a was inevitable, because that old codebase, although fairly solid, is showing its age. By moving from Smaug 1.4a to SmaugFUSS (the "FUSS" stands for "Fixed Up Smaug Source"), we inherit almost 20 years of bug fixes and optimizations while maintaining a (mostly) familiar architecture.

There were some alternative code bases to consider: Smaug 1.8 and Smaug 2.0. Smaug 1.8 is the official release and represents a significant improvement over 1.4a, but its last release was in 2007, so the code itself is rather stale. Smaug 2.0 is much newer—the latest commit was January 2017—and it is packed with features like web client support and I18n (internationalization). However, 2.0 is not an official Smaug release, and has integrated a lot of snippets from the MUD development community—resulting in a crazy feature list that we simply don't need. Covenant MUD is different enough from stock that I'd have to devote a substantial amount of time to trimming out code bloat before implementing any of our own features.

SmaugFUSS is relatively lean. I'll still be trimming it down as I reimplement all of our old features from our 1.4a codebase, but SmaugFUSS gives me a better starting point. Better still, SmaugFUSS is partially written in C++ and takes advantage of improved memory allocation and smarter string handling, nicely addressing two of the biggest pain points of the old codebases. Because it is 2017, and not 1997, we have some modern tools to aid development, including a ticketing system (Mantis), and version control (Git, of course)—the MUD is even publicly available on GitHub now. I can't begin to describe what a game-changer GitHub is: I can keep code updates in individual branches until they are ready to be merged into the master branch, which is the branch run by the live version of the MUD. As a result, I am less likely to introduce unstable elements into the game as it runs.

By packaging up changesets into pull requests, I can look over code changes in isolation before merging them in, checking for my own mistakes and making sure everything is just right. Truth be told, I have saved myself from introducing more than a few bugs already! The pull requests also give me a coherent history so that I can look back and see exactly what lines changed with each new feature or bug fix. Re-implementing features from our previous codebase is an exercise in reverse-engineering my original code written a long time ago. While it would be helpful to be able to recreate my old thought processes from the turn of the millennium, my old emacs changelogs seem to be lost forever. (I'm not convinced these logs would be terribly informative anyway.) It's next to impossible to read your own code after 20 years if there's no documentation, so it's almost as if I am starting from scratch. I think in 2037, I should be able to look at changes from 2017 and understand the reasons behind them.

It is because I care about this history tracking that I have discarded my previous attempts to retrofit SmaugFUSS. The new Covenant MUD represents a fresh start. My old ticketing system had exactly 41 items in the queue, so the new MUD starts with Ticket #42. I would have preferred to start with #1, but landing on 42 was such an amusing coincidence that I decided to run with it. So we begin with Ticket COV-0042, pictured at the top left, entitled "Initial set up", which is the MUD equivalent of "Hello, world!" And, yes, the MUD compiled first time and there were no issues logging in. Time to get to work.

– Shamus

November 2017

The "MU" in "MUD" stands for multi-user, but it's just me at the moment as a solitary user, so I guess that makes this project "Covenant SUD" right now. Our first-ever server was named "soap" so SUD is strangely appropriate. Actually, it's probably for the best that I work alone during this initial phase of development, because stock SmaugFUSS bears very little resemblance to the old Covenant MUD, and anyone who logs in right now is in for a disappointing experience. This is not a knock against stock SmaugFUSS; I am not disappointed with the new codebase—I'm just forced to acknowledge that it is not an accurate representation of what Covenant used to be. However, while SmaugFUSS is not Covenant, it is still enough like Smaug 1.4a that I can work to port our old changes with reasonable efficiency.

To help keep track of what I've done, and for the sake of being 'accountable', I've started publishing periodic release notes. I plan to publish release notes periodically for as long as I can keep deploying updates at a reasonable pace. During this initial implementation phase, there are still many development tasks to keep me occupied, but I do expect at some point in the (possibly distant) future that the MUD will be fully-featured and stable and new work will consist mostly of maintenance and minor upgrades. There are quite a few line items in November's release notes, although many of these items are minor cosmetic fixes so some of the associated code change sets are quite small. I expect the next release list to be a bit shorter, because my plan is to implement some major features such as intelligent furniture objects by the beginning of December 2017.

I've restored the Harrington-Lefcourt Tower, which is a small zone that happens to contain my office, so at least that makes the MUD feel a little more like home. The tower is also a good place to start rebuilding because it should have a number of amenties when finished: a coffee shop, a post office, a bank, a bulletin board, and several rooms with furniture. Reconstructing the tower will allow me to visit a number of features, check over the existing implementations, and write code to fill any holes. I've also restored many of our old help files, and set up our standard races, object types, liquid types, and terrain types. I've made some cosmetic fixes to colours and formatting to begin restoring elements of our previous "look and feel" although there is still a lot of work to be done in that domain.

Working with the new codebase has led me to reflect on how some of our decisions about game mechanics have been influenced in unexpected ways by our previous codebases. When we first designed our new character classes, we were inexperienced and didn't have a clear vision of how we wanted to shape the world. We initially came up with a set of ten classes because stock DaleMUD came with ten classes of its own, and it just seemed easier to adapt what we already had. We ended up mapping our own classes to existing classes in the code: Ranger became Naturalist, Druid became Shaman, and so on (Warrior remained Warrior). The Inventor class overwrote the Barbarian class, and consequently inherited the Barbarian's distaste for magic. This detail was never part of the original conception, but given the Inventor's love of technology, we decided to keep the anti-magic feature as part of the class design. With the subsequent move to Smaug 1.4a, the Inventor ended up replacing Smaug's stock Vampire class. By an amusing coincidence, I had also replaced the old liquid type for blood with Cuendar dark roast coffee. The surprising result is that in place of Vampires needing blood to survive, I had inadvertently created Inventors who thrive on coffee. (The tech jokes pretty much write themselves from this point.) We were then inspired to create a player condition called "wired" that replaces Smaug's "bloodthirst". We never quite decided what to do with this condition, but I can envision Inventors gaining skill bonuses when working with technology by getting wired upon drinking highly caffeinated beverages.

December 2017

A month has passed, and as predicted, the latest release list has fewer items on it, but the items themselves are tied to substantially bigger features. A number of the recently-completed tickets have to do with interactivity and in-game objects. (In this context, 'objects' refer to discrete items in the game world, and have nothing to do with object-oriented programming.) Way back in the heydey of the rec.games.mud.* newsgroups and the MUD-Dev mailing list, someone prominent in the MUD Development community (I'm pretty sure it was J C Lawrence) said something along the lines of, "If I can throw a ball, I should be able to try to throw a bridge." One way to understand that comment is to recognize that if you can do something to one type of object, you ought to be able to try doing similar things to other types of objects, even if your actions defy common sense. The interface needs to respond in a way that is internally consistent and provides meaningful feedback.

I was looking through archives of our old discussions, and found Duithal's observation that your typical player didn't make any real effort to interact with the objects in their environment. He was right, and I think part of the reason players wouldn't make that effort was because they had been trained not to—they knew nothing interesting was going to happen so they simply didn't bother. We can encourage playful experimentation by making items that actually respond to arbitrary actions. When I re-implemented the 'sip' and 'taste' commands, I gave some thought to the consistency of the interface and how it can give players an incentive to explore the mechanics of the game by trying weird things. You should now be able to taste your sword or sip from a potted plant. Of course, you aren't likely to learn anything useful if you do, but at the very least the MUD will respond with something more meaningful than, "You can't do that" or the ubiquitous "Huh?" you see in so many contexts. We've also made social commands accept objects as targets. If you want to stare longingly at a comfortable armchair or peer suspiciously at a stale muffin from the cafeteria you can do those things. Naturally, you've always been free to use emotes to do whatever you want but having social verbs work on all objects brings vitality to even the most mundane items.

The big project in this release was implementing furniture. Our original furniture project started because Blaine put benches in a public space and got annoyed that he couldn't sit on them; he really pushed hard for furniture objects that the players could interact with. At the time, other Diku MUDs had rather weak implementations of furniture and we knew we could do better. We came up with smart furniture objects that work with the commands stand, sit, rest, and sleep, and four prepositions: at, in, on, and under. You can configure objects to accept multiple actions and prepositions, so for example you could specify that you want to sit at a table, on a table, or under a table. The table should be smart enough to understand that if you type sit table, you're more likely to sit at it than under it. If you're sleeping on a bed, and type sit, you will wake up and move to a sitting position on the bed rather than getting up and sitting on the floor. If a room description says there's furniture in a room, then we put furniture in the room. However, we weren't happy with the clutter that resulted from dropping several items in a furnished room so we came up with a way of hiding the implementation of furniture objects. If a room description says something like, "A round canopy bed rests on a raised pedestal at the center of the room and a small nightstand and matching dresser are against the far wall. A small table and two chairs sit near the entrance of the room across from the dresser," then you can reasonably expect to be able to interact with a bed, a nightstand, a dresser, a table, and two chairs even though you can't actually see these objects in the room's inventory. The room's description—by convention a static wall of text—comes alive with dynamic interactive details.

I've restored all the rooms in both the Harrington-Lefcourt Tower and the City of Tierceron—over a thousand rooms in all. It's been fun walking around reading descriptions; after 20 years I've forgotten enough that much of it seems new to me. One thing I notice in my explorations is that we added a lot of atmospheric colour to our rooms in the form of statuary, murals, and paintings, hinting at a rich arts tradition in the Covenant. I did come across one painting whose description gave me pause, and it is this one: "Kilgahari cherubim frolick happily through a field of daffodils, while scantily-clad females of several diverse races lounge about eating grapes and bananas. Those familiar with the world of art may recognize this as The Pastoral painted by Dathan Coulter." I don't know who wrote this one (and it doesn't really matter) and I can see that they were invoking a sort of Renaissance fresco with chubby angels and revellers celebrating something bacchanalian—not atypical subject material for the period. However, I did find myself cringing at the phrase, "scantily clad females" ('females'? Really?) and the cultural attitudes it strongly implies. I changed it to "scantily clad youths", which preserves the original intent, uses more inclusive language, and has the side benefit of improving the flow of the text. I think that as we rebuild the world, we should be mindful of our word choices. We must hold ourselves to a higher standard.