“Don't let the technical stuff frighten you—it's only there to make
everything work. Don't feel you have to be a programmer—you don't, although sometimes, programming
can be most of the fun. Why else would somebody stay up until three o'clock in the morning cursing, and
then claim the next day they had a wonderful time? That's part of what it's about.”
—Jim Butterfield, Commodore 64 Training Video (1983)
Quick shout out to the folks at the Mud Coders Guild. When I revived Covenant MUD in 2016, I was not aware that the MUD community was even alive—in fact, it turns out to be thriving. It's great to see that MUD coders are still pushing the boundaries with new languages, technologies, and game designs.
I've taken a bit of a break from code updates because I really needed to devote some time to updating the website. I've documented the history of the tierceron.com website elsewhere, but the tl;dr version is that the site hadn't seen a real update since 2002. What's worse is that there were entire pages that have been empty for seventeen years. Updating the site has been a laborious process because I'm not only updating the layout, but also filling in the blanks and fleshing out content, which is turning into a significant writing project. I'll get there in the end but it may take some time.
The original version of the MUD website from 1998 optimistically declared, "You may soon find valuable player information located on these pages." It's been twenty years or so; perhaps we can get a little closer to fulfilling that promise.
A short list of release notes this month, and only one item of any real consequence, but it is a big one. Rather than try to describe this new feature, I think I will let the game speak on its own behalf.
Queensgate You have reached the western gates of Tierceron. To the east is Queen Street where you can find shops to resupply or a place to sleep. If you head west out of the city you begin your travels towards what is largely uncharted territory. Above, you see a bridgeway where several guards now patrol, watching all who enter or exit the city. Exits: East West > west Room Number: 10015 Invis. Level: 0> w 0 __ ___________ __/%%\__ / \ Location: 97, 84, 2 __/``\%%/==\__ 300 / \ 60 Terrain: City /""\`1/%%\=9/ \ / \ \"1/""\%1/@@\__/ / \ /``\"1/**\@2/ \ 270 ( * ) 90 Speed: Stopped \`1/##\#2/==\__/ \ / /##\#2/ \=9/ \ \ / Heading: North \#2/ \_3/==\__/ 240 \ / 120 \_3/~~\=9/ \___________/ \~1/ 180 > ne Heading changed to 60 degrees. > jog You start jogging. (time passes) You have arrived at the City of Tierceron's Queensgate, leading into the city via Queen Street West. You enter the city--welcome to Tierceron! Queensgate You have reached the western gates of Tierceron. To the east is Queen Street...
In the example above, the player starts out at the Queensgate, a normal room in a format that should be familiar to anyone who's ever played a Diku MUD. As soon as the player walks out the west exit, they are outside the city, on the RealSpace map, which is a large Cartesian plane segmented into hexagonal map cells. In RealSpace, there are no rooms and no exits; you can be anywhere on the map that the terrain allows (with your position specified to a precision of fifteen decimal places) and you can go in any direction you like.
In our example, the player is shown standing just outside the gate, as indicated by the
symbols on the map display. They decide to head northeast, toward the
@@ symbols that mark the
city entrance, and start jogging. After a short jog, the player arrives at the city gate and is whisked off
the map and back into the zone that is the City of Tierceron—back into the comfort of a normal Diku
This release completes the integration between RealSpace and "normal" MUD space. I'm beginning to realize that adding new features in code is a relatively quick process, but adding content takes a lot of time, and Smaug's online building tools are painful to work with. Next month, I will turn my attention to a project that should ease some of that pain and make building a much more pleasant process.
One strategy for building a setting for a large, open-world game is procedural generation—you define a number of reasonable parameters and devise an algorithm that will create locations, items, and characters on demand. At least one MUD coder out there is working on natural language processing and generated locale descriptions. When done correctly, such alogrithms can conjure up thousands of pieces of content without repeating themselves, creating a world that is both rich in variety and consistent in tone.
Covenant MUD is not a game that can rely on procedural generation. We have always aimed for a setting that conveys its narrative through traditional descriptions provided by a human story-teller. Building our kind of world is labour-intensive, requiring a fair bit of writing and proofreading—processes that cannot be automated. Fortunately, we have a lot of content from the old days—two thousand rooms or so, with a number of objects and mobiles to populate them; unfortunately, the old data format is not 100% compatible with the new codebase. I really didn't feel like writing a data migration script for anything other than the rooms, so I started repopulating the world the old-fashioned way, building via "Online Creation" (OLC) while logged into the MUD. It didn't take long to realize that trying to build in a MUD via a dumb terminal makes for a terrible user experience.
Enter a new suite of online building tools: the Tierceron Construction Set (TCS), available on GitHub (please see this month's release notes), written in Ruby on Rails, and deployed to Heroku, where it is easily accessible to any builder with an internet connection and a web browser. I wasn't terribly surprised to learn that I'm not the first to implement a browser-based building application; the MUD development community even has a name for this kind of app: "webadmin". OLC may have been adequate for the 1990s, but it is unacceptable in 2019. Actually, I'm not even convinced that OLC was adequate in the 1990s. I know that back in the day, Wrathmolten had cooked up his own program in Visual BASIC that allowed him to create content on his desktop and export data files the MUD could consume, so the impulse to have something better is not a new one.
The screenshot above shows a segment of an edit form in TCS. Right now, I've only implemented the ability to edit social commands, but it's a start. You can see the advantages that the form gives us: we can include help text, hints, sensible defaults, and notify the user when their input would cause an error in the MUD. Builders don't have to worry about getting disconnected, crashing the MUD, or accidentally trashing their area files because of some silly mistake. There's also file handling, so we can import datafiles from the MUD into the TCS database, and then export new datafiles to send back to the MUD when we are done editing. Multiple builders can work on different areas at the same time, and we can segment their work so that each builder only has permission to edit their own assigned content regions.
Creating an original world with the size and scope that could rival something procedurally-generated feels a bit like John Henry going up against the steam-powered rock drill, but at least TCS gives us a pretty good hammer to swing.
This month, I continued work on the Tierceron Construction Set (TCS)—please see this month's release notes. I've tried be disciplined and not overdesign TCS with some fancy, enterprise-level architecture. Developers like to play "what if" with their pet projects—what if someday I need this to be both a floor polish and a dessert topping? It's tempting to cram in everything you could ever possibly want, but it's not a smart use of your time. An important principle to keep in mind is, "build for today, design for tomorrow". Think about what you may need in the future, and don't paint yourself into any corners, but only build the features you need today.
I've also tried to be a lot more disciplined about breaking down the work into small chunks, with each pull request representing a discrete segment of the application. I'm supposed to be teaching an "Intro to Rails" workshop later this year, so I've been writing while considering how small segments of code can serve an instructional purpose. With any luck, TCS could serve as a good jumping-off point for a novice coder trying to write their own webadmin application, whether in Rails or Laravel or some other web framework. To that end, TCS and its constituent commits are open source and browsable on GitHub.
The only thing you can do right now in TCS is create and edit social commands, but the process works from start to finish. Right now the workflow is like this:
- Log in with an admin account.
- Upload SMAUG's
socials.datfile via the admin interface.
- Create new socials and make edits with the web forms.
- Export the updated socials into a new
.datfile (again, through the admin interface) to be uploaded to the MUD.
With the MUD data in its database, TCS is capable of useful operations such as searching, sorting, and reporting, giving us powerful tools to look at the state of the entire MUD world through a tidy web interface. What TCS does not do is sync up automatically with the MUD; an admin still has to transfer data files back and forth by hand. In the short term, this is a reasonable approach because it isn't as if we have teams of writers generating new content around the clock. In the long term, I can see questions arising as to which application is the system of record: the MUD and its live data, or the TCS database? Build for today...
Next month, I'll start working on the ability to create and edit SmaugFUSS objects so that TCS can actually start being useful.
I have continued working on the Tierceron Construction Set (TCS) although I think I'll save the release notes for next month's update. TCS is publicly available on GitHub for anyone who wants to take a look at the most recent changes to the source code.
Having wrapped up the work on editing social commands, I wanted to turn my attention to making tools to help our builders create the MUD world. However, I quickly ran into a design question: how do I handle authorizations for multiple builders? If Gladstone is working on a set of rooms, and Wrathmolten is working on another set of rooms at the same time, how do I keep them from accidentally overwriting each other's stuff?
In a Diku MUD, the world is composed of three primary data structures: rooms, objects, and mobiles (NPCs). Every room, object, and mobile has a VNUM that acts as a unique identifier. When we grant a builder access in the MUD, we assign them a range of VNUMs. For example, the City of Tierceron spans the VNUM range of 10000 to 10999; all the VNUMs in the city fall into that range. So the question is not so much how do we keep builders from messing with each other's stuff, but how do we ensure that builders can only work with their own assigned VNUMs?
We could implement some kind of connection between each VNUM and the builder who "owns" it, but that method becomes unwieldy as the MUD grows and also makes it complicated for builders who want to collaborate on a shared set of VNUMs. Fortunately, Diku has a means of organizing VNUMs: the "area" or "zone". A zone is a contiguous set of VNUMs and a bit of metadata, like the zone name and its recommended level for explorers. In TCS, I give each zone an "owner" who must be a user in the system; each owner has the authority to create, edit, and delete anything tied to the VNUMs that they own.
At the moment, each zone can have a single builder assigned to it, but somewhere down the road, I'll add the ability to assign multiple builders to a single VNUM range. For now, my main concern is deploying the Minimum Viable Product version of TCS so that I can get it up and running and actually usable. And now that I can have zones and owners, I can set up the following:
The zones don't actually do anything yet but having them defined makes it feel like TCS is actually going somewhere. I can see the outline of all our old areas and it's as though the MUD is finally experiencing spring after a very long winter. Now that I have zones configured, I've started work on the object editor. It's actually almost ready as of this writing but I'll outline the details (with complete release notes) in July's update.