In a recent post, I made the case for MUDs in modern times which explored the niche that MUDs occupy on the internet. As a longtime player of MUDs, some of my early coding experience was with downloaded MUD codebases, tinkering endlessly to run ancient makefiles and compile spaghetti code hobbled together by lots of strangers on SourceForge. It was fun (kinda!), but hardly effective!
As a professional now working in technology, my “tinkering” has morphed into a practical skillset that I apply at my job. However, while I was completing my recent Udacity course, it felt like everything I was coding was just for the degree program and not because it was fun or interesting to me. Once I turned in my last project, I realized it was time to work on something totally different and new. I decided to revisit MUD coding.
Something totally different and new
Earlier this year, I started working on a Vue app codenamed Ophion. This was my first foray into Vue and was envisioned as a browser experience. The “game” has many loose concepts that I’ve been playing with for a while, and I envisioned it working as an idle clicking game. The game was built as a resource management idle game in which you played the role of a robot dropped on an alien planet, tasked with harvesting the natural resources and erecting monuments to your strange overlords. It was funky and weird! A lot of time was dedicated to making strange, alien-like SVG gradients for the UI.
Along the way, I realized the heavy mathematic skills that go into building a good idle game. I’m not much of a mathematician or statistician, so the game balance quickly became wonky. I knew how to make it work and how to make it pretty, but not how to balance it. I didn’t know enough about normalizing results to create a steady difficulty curve to the game, and that was when my newfound coding skills hit a brick wall of daunting math. In the end, I threw those cares to the wind and kept building the game just as thematic inspiration, strapping on as many lore-filled appendages as I could in an effort to pile ornamentation atop the broken calculations. In the end, there was a lot of visual work completed that I’ve since used elsewhere. After making some headway with that, the final portion of my Udacity course began and I was torn away from the project, which has sat on the shelf ever since.
Flash forward to now, and I’m applying some of what I learned with Vue to create our first ever React web app at my company. the process has been both rewarding and exciting. However, I don’t want to want to write a React app for work and then come home and write a Vue app for fun! So I’m packing up the ideas and moving them over to my next project: a JavaScript MUD.
From Ranvier to Pinwheel
I recently found a JavaScript MUD engine called Ranvier that was built by Shawn Biddle and it immediately piqued my interest. As a JavaScript junkie and long-time MUD enthusiast, finding this was a golden opportunity to apply all of those ideas spinning around in my head without having to start from scratch. While the repository has undergone only a little work recently, the labor of love has been in development for several years and offers a great starting point for this type of server.
Being able to sift through the structure of the server and examine how it all ties together has really opened my eyes about creating these types of programs in Node. Because the language is so modular, Ranvier is similarly extensible via a module system that can allow any kind of alteration atop the existing source code. With a few lines of code in a module, the server supports WebSocket right out of the box. Just as Node is an event-driven language, Ranvier is an event-driven framework. Ranvier works with the benefits of JavaScript instead of fighting to pretend it's C, which is a fun concept to embrace as a JavaScript developer. 2021 update: it's also since been converted to TypeScript!
However, the codebase itself comes very bare without any content. This isn’t a turnkey codebase like ROM, which comes with prebuilt stock material. But this is great, because I don’t have to spend any time gutting canned content. In fact, I’ve gone straight to the source code to start finding any missing concepts for me to implement. There also aren’t any mainstream released Ranvier MUDs yet at this point. The closest thing is probably Sean O’Donohue’s Mnemosyne (formerly Myelin), which I encourage you to check out!
To adapt the code into something different, I forked Ranvier into my own version called Pinwheel. The name is inspired by something cyclical yet fun, which is the mantra I’m keeping in mind as I design the game. So far, I’ve expanded how character attributes work to create a stat-based auto combat system, similar to DIKU. I’ve also expanded upon skills to create something akin to a discipline system with mastery levels. Because Ranvier is agnostic about how these properties apply, any character in the game (including an NPC) can learn from their actions and increase their masteries like a player. This is exciting for me as I start shaping the starting areas as an agent-based simulation.
I have been writing a lot of lore and ideas for this new MUD world, but right now the theme is low fantasy with a splash of cosmic horror. Another cool thing about making a MUD in JavaScript is that it can be easily hooked into any kind of user interface. At the end of the day, the server is just executing logic on a loop and outputting the content however the server modules dictate. It comes with bundles for telnet and WebSocket, but I also created a bundle that spins an Express web server alongside the game. My server binds the game state to a public web directory and a backend API, and uses ES6 template literals to render the server views. Since I’m writing the HTML in template literals, I can reference anything from state directly in the page to create dynamic server pages. By binding state to an API, I can also serve a RESTful API for a future Vue or React app to use directly from the MUD. Just as through telnet or WebSocket, the game could be playable from any device using this type of API.
Right now, the idea is to use the web server for server management and use the browser for content creation, but I also want to implement some type of gameplay for players. MUDs suffer from a rather low playerbase overall, and finding ways to attract new players would go a long way towards making the project worthwhile to me.
Like-minded MUD developers, unite!
To that end, I went out in search of like minds… and I found them at The MUD Coders Guild! We have a Slack with several active users, and we all have different projects. There's also a Discord server from the MUD subreddit that has many active text-based enthusiasts and developers.
Eric Oestrich has created ExVenture, a MUD server in Elixir. On top of that, though, he also runs our inter-MUD Grapevine chat network which establishes a protocol for MUDs to exchange messages. This is in the same vein as LP MUDs, which all share a protocol that allows them to chat between their instances. This is a pretty cool concept, when you consider the represented entities who are chatting between the servers are from completely different codebases! Once my server is stable and I’ve finished area permanence (so state is always preserved), I’m planning to put the server on a DigitalOcean Droplet and I’ll be adding Grapevine support. Eric has even already created a bundle for Ranvier. From here, I’m really looking forward to charging forward on my MUD project!
Further Reading
Ranvier, a MUD engine in JavaScript
Ranvier-TS, an offshoot of Ranvier using TypeScript
The MUD Coders Guild and their Slack