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.
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 once per month for as long as I can keep deploying updates at a reasonably rapid 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.