Why aren't we using the LegacyArm codebase?
LegacyArm Codebase
The LegacyArm codebase was a Diku at its core (C) with SpiderMonkey integrated for small stuff that didn't require a reboot (Javascript), with decades of web facing tools for management (PHP, Perl, Javascript, shtml, and shell scripts), CLI for doing backups/reboots/cleanup/archiving. The content was stored in SQL, proprietary text files, original Diku flatfiles, JSON, and XML.
The original codebase had decades of wisdom gained from painful lessons. It had a lot of seasoning by way of flair added to meet staff and player needs and addressing emergent behavior from both. Every round of hiring found new bugs both in staff commands and in how players interacted with the content they added.
All of that code and technology getting added, sometimes slowly sometimes quickly, had consequences. Engineering is about managing tradeoffs and software engineering is no exception. Over time smaller changes took longer to implement and onboarding new devs took longer (if even possible). It was a constant struggle to balance the time of adding new features against the overall drag they would add to managing old features.
It also took, year after year, more time to manually manage bugs to keep the game up. Both known and new. It wasn't uncommon for the game to require twenty hours a week of someone's time to stay up and running.
Evennia
https://www.evennia.com/
https://discord.com/invite/AJJpcRUhtF
In contrast Evennia is Python, one of the most popular and still growing languages, all the way down. The game, the website, everything about it is Python. Evennia is also an engine that is still supported and seeing updates from its team. Evennia manages data persistence freeing us up to focus on working on features that directly impact the players and staff. It comes with a built in web client and is aware that non-telnet clients exist.
The Evennia team has made their engine very, very adaptable. For us this results in seeing how they approached problems differently from us as well as seeing the solutions to problems we didn't know we even had.
This all makes it accessible to hobbyist developers. Not only can we onboard people to Python faster than C, we can onboard new devs to Evennia faster than something we built ourselves. Evennia has a great, active discord server, as well.
Python
There's some give-and-take between Python and C, but at the end of the day we can now use Python for, essentially, everything. This requires less context switching when going from one language to the other, depending on what was being worked on. There's no juggling when passing data from one language or technology to the other.
There's also the whole issue of Strings being easier to create and manipulate while in C they are represented...with difficulty. Given that MUDs are text games, this was always a struggle for us in C and so far in Python I think we've all felt a weight lifted.
Django ORM
This is what Evennia uses to talk to the database. Because developers don't have to write custom DB code they end up writing less code (which generally means fewer bugs). It also means the type of database can be switched around between SQLLite for developers and Postgres for production.
Where this really comes through is providing global persistence. In other words, the entire game is a giant save zone, in LegacyArm terms. Every room, every item, every NPC saves its location, state, and contents all the time. This was a long sought after feature on LegacyArm that comes built in.
With relatively painless access to the DB we can toss everything we want there through properties on Objects or using Script Objects. In the rare instance we want something in a text file we can store the data as Python objects making them easier to interact with than anything we had on LegacyArm.
Built In Tests
With LegacyArm writing tests wasn't something we started with and when added (very late in the game) wasn't widely adopted. Testing was brought in early in the process, is a part of Evennia itself, and is providing a valuable safety net. On LegacyArm a developer would write some code, make sure it compiled, then log in to do a very basic smoke test before pushing it live (which is where the real testing was performed).
With how things are done in the new system, tests can be run by the developer locally and are always run as part of the git workflow. This has increased our confidence in our own (and sometimes others') work, letting us work faster because we fail faster. Fixing a bug in code you just wrote is much easier than in code you wrote three weeks ago.
AI Assistance
While AI is well trained on both C and Python, it is not well trained on LegacyArm's codebase. Conversely it is very well trained on Evennia, given the amount of documentation the team maintains online as well as the Evennia projects exposed on the internet. Claude and ChatGPT both do a fairly good job of understanding, explaining, and writing code for Evennia projects. (usual caveats apply about verifying anything an AI tells you, continue doing code reviews to spot regressions in behavior, and so on).
Closing
Ultimately it isn't about Evennia being magically better than LegacyArm. Rather it is about what kind of team will be working on the game in both the immediate and (hopefully) long term future. A narrow tech stack, a higher level (more human-like) language, wider access to language specific development tools all make life easier for hobbyists and new developers to onboard and enjoy working on the game.
We aren't turning our back on craftsmanship and expertise, instead we're choosing where to apply it that most benefits the game and the community.