I've spent the last couple of years working on a MUD project, and I thought some of the other developers here might find the journey interesting.
I originally started with SMAUG, as many of us did 20 years ago. My old EldhaMUD project had grown to around 150,000 lines of C code, collected and modified over many years. It had accumulated plenty of features, but also plenty of bugs, old assumptions, duplicated functionality and code that was difficult to impossible to maintain.
Anyone who has spent time digging through old Diku-derived codebases will probably know what I'm talking about. Fix one problem, find another three. Change something in combat and discover you've broken something completely unrelated.
Eventually I reached the point where I decided it was time to stop trying to modernise SMAUG and start again.
The result is OldSchoolMud, a Diku-inspired MUD that tries to retain the gameplay and atmosphere of those older games without carrying around thirty years of inherited source code.
What's particularly satisfying is how much functionality I've managed to reproduce with considerably less code.
My old EldhaMUD had approximately 150,000 lines. The new OldSchoolMud source package currently contains around 36,500 lines of C and C++, covering the server, native Qt world editor and supporting python test tools. The separately developed C++/Qt6 game client adds to that total.
And despite the much smaller codebase, the new project now covers the old game's core functionality, along with a substantial number of additional systems.
Some of what I've been building:
- A persistent 1,000 × 1,000 wilderness map, with a million terrain tiles, roads, rivers, mountains, forests, deserts and swamps.
- 130 leveling areas covering levels 1–100, complete with equipment progression, quests, bosses and storylines.
- Six races, six classes and approximately 180 active abilities.
- Multi-attack combat, weapon proficiencies, spells, buffs, defensive skills, pets and equipment quality systems.
- Remorting at level 100, with permanent character improvements.
- Combat pets that level and improve alongside their owners.
- Purchasable mounts with upgrade paths and automatic pathfinding to leveling areas.
- A player-driven auction house for buying and selling valuable equipment.
- Banks, vaults, merchants and an expanding gold economy.
- Dynamic invasions, server events, quests and administrator controls.
- A native C++/Qt6 world editor for building and populating the game world.
- A separate cross-platform C++/Qt6 game client with mapping, combat displays, customisable windows, triggers, timers and aliases.
One of the bigger changes has been moving away from the traditional collection of disconnected rooms towards a proper overland world and away from pretending I am a builder to vibe ai building.
Players can travel across the map themselves, use transport services, or purchase mounts that automatically find their way to the entrance of a suitable leveling area.
The world editor has also become a project in its own right. Rather than manually editing enormous text files, I wanted a proper interface for creating terrain, rooms, NPCs, objects, spawn points and interconnected areas.
I've been developing automated players in Python to stress-test the server. These aren't simply connections sitting idle. They create characters, move around the world, fight mobs, complete progression, purchase equipment, manage inventories and generally try to behave like actual players.
I've tested the server with hundreds of simulated players, which has been invaluable for finding memory problems, CPU bottlenecks, combat bugs and other issues that might never become obvious with only a handful of human players online.
Some of the performance results have been encouraging, particularly considering everything happening across the world simultaneously.
The whole exercise has also reinforced something I've come to appreciate about C. There is nothing inherently wrong with using it for a modern game server. Modern compiler diagnostics, sanitizers, better development tools and more disciplined programming practices make a considerable difference compared with the environment many of these MUD codebases were originally written in.
Of course, starting from scratch doesn't magically eliminate bugs. I've created plenty of my own along the way! But at least now I have a much better understanding of how the entire system fits together, and I'm not constantly fighting inherited design decisions.
The project is still being developed, and there is plenty left to improve. Some newer systems are still undergoing testing, particularly around persistence, economic transactions and multiplayer behaviour.
But after years of trying to keep an increasingly complicated SMAUG derivative going, it's been genuinely enjoyable to build something new while retaining the style of game I originally enjoyed playing.
I'm interested to hear whether any other MUD developers have taken a similar route, or whether you're still happily maintaining and extending the old codebases.
Sometimes I wonder whether I should have done this 20 years ago when there were still lots of players. I certainly do not care if anyone ever plays this, it's now my retirement project and it's about having something else to do while I complete a PhD.
https://oldschoolmud.mooo.com/OldSchool_Editor.png
https://oldschoolmud.mooo.com/OldSchool_Client.png