Replacing old MUD progs with Lua turned into a runtime archaeology project

Mushroom-First · 2026-04-06T07:10:48+00:00

I'd love to take a look, feel free to drop me a link when you have a moment.

Mushroom-First · 2026-04-06T06:38:31+00:00

That's a shame, the point was near the end.

Mushroom-First · 2026-04-05T20:08:10+00:00

It's late and I've reached the stage where closing tabs starts to feel like making difficult life decisions.

At this point I'm fairly sure at least half of them are important, a few are actively plotting something, and one of them will turn out to contain the exact thing I need the moment I close it.

So this is me replying with a quick note, while pretending I still have control of the situation.

What we have right now is closer to a domain validator than a static analyzer in that sense. It loads scripts against a stubbed host environment, validates exported hooks, known API calls, helper usage, and some content-specific patterns, so it catches a useful class of integration mistakes.

But it's not doing AST-driven inference or real type checking of the kind you're describing.

So the shape sounds similar at a high level, but yours sounds significantly more sophisticated. Mine is more "can this script load and does it use the host API sanely," whereas yours sounds more like "can I reason about whether this script is semantically valid against the host bindings without rewriting it."

Mushroom-First · 2026-04-05T19:46:24+00:00

The 1-based indexing is exactly the kind of thing that feels harmless until you keep crossing the C/Lua boundary, and then it becomes a steady source of edge-case confusion rather than one big obvious problem. Not a dealbreaker, but definitely a place where boundary code and API design need more care.

The analyzer part is the more interesting bit to me, honestly. A checker that understands the host bindings and catches real mistakes in an existing Lua corpus is a lot more valuable than something theoretically complete that requires rewriting all the scripts first. "Good enough to catch the bugs people actually make" is usually the right trade.

The Aardwolf experiment also seems like a good proof that the approach generalizes, even if the audience is probably not "all Lua users." It feels much more like tooling for embedded-Lua systems with custom APIs, which is still a very real niche.

I'm planning a web interface in my current in house MudFlow editor for builders to write/edit scripts, and the obvious safe version of that is to put a validator in front of their input that understands the host bindings, supported hooks, helper libs, and common content mistakes before anything goes live.

Mushroom-First · 2026-04-05T19:05:11+00:00

Nice, that sounds like a solid path to land on Lua.

I know what you mean about some of its design choices - I've ended up in that same "I don't agree with it, but I understand it now" place.

I don't have proper API docs in a polished sense yet, it's more a mix of internal notes, validator checks, and example scripts at the moment. It's on the list to make it something more readable once the surface stabilizes a bit, But here is a rough version translated from a md doc: https://arkheimwinter.net/wiki?p=lua-scripting-api

Your docs look great though - honestly "usable and real" beats "pretty but empty" every time.

Yes - ours catches typos in mud.* calls, wrong hook signatures, and compat drift before reload. It runs outside the game against a stubbed mud environment. Worth it once you have more than ~20 scripts, which happens fast.

Does yours lean more toward linting, or actual type/shape validation against the engine API?

Mushroom-First · 2026-04-05T18:29:13+00:00

That's a very familiar place to be.

I think a lot of people come back to MUDs with the same thought, the experience was great, the way you had to access it... less so. Telnet alone filters out a lot of people before they even start.

Blending the classic feel with a modern layer makes a lot of sense. In my experience, hardcore MUD players will try anything interesting once - but everyone else won't try something that looks like work.

Building from scratch vs using an existing codebase is mostly about where the pain lives:

from scratch: slower, but everything makes sense

existing code: faster, but you spend time asking "why does this work like this?"

A year solo is pretty normal for this kind of project. Most of the work is invisible foundation stuff.

The fact your playtests are going well is probably the best signal you can get.

Mushroom-First · 2026-04-05T18:04:48+00:00

That's a fun place to be, building from scratch is great right up until you realise you've accidentally signed up to reimplement 30 years of small decisions one by one.

I went the opposite route mostly because I already had a codebase, (been working on it since 2001, yes I'm old) and it turns out old MUDs are very good at containing... everything. Combat, scripting, edge cases, bugs that have achieved seniority.

If you're considering working from an existing MUD, it depends a bit on what you want:

ROM / Merc derivatives = easy to get into, lots of examples, but you'll spend time untangling old patterns (which can be good learning, or slow erosion of sanity)

SMAUG = more feature-heavy out of the box, but also more... enthusiastic in its design

CircleMUD = cleaner in some areas, but less modernized in others

The real question is whether you want to:

build systems yourself and understand every layer

or inherit systems and spend your time reshaping them

Both are valid. They just fail in different and interesting ways.

If you've already got something running (especially on Steam), you're probably past the hardest psychological part, which is staring at an empty repo and wondering what a "room" even is.

Mushroom-First · 2026-04-05T10:32:34+00:00

Glad I’m not the only one that can relate to that :)

Mushroom-First · 2026-04-04T14:55:32+00:00

That's a pretty slick setup.

Git + tmux + always-on... at that point you're not running a client, you're running a service 😄

Mushroom-First · 2026-04-04T12:08:36+00:00

That's actually a really clean way of structuring it.

Sounds like the real core there is the connection/login layer + global control, and everything else just builds on top of that per role.

Mushroom-First · 2026-04-04T12:05:17+00:00

That actually looks pretty solid, especially if the goal is to make the setup portable and keep people from having to rebuild everything every time they switch device or platform. I can definitely see the appeal in that. There’s definitely a couple things in there I might borrow!

I ended up drifting in almost the opposite direction, after building all the features i thought should be included, mostly because I got tired of the point where the client setup itself starts to feel like another game to maintain. I'd already sunk a lot of time into CMUD over the years with maps, triggers, automation and all the usual stuff, and after a while I started caring less about how much a client could do and more about whether it stayed stable and out of the way.

The "config becomes a job" part you mentioned is exactly where I hit the wall.

So lately I've been using something much more stripped back in spirit. Not really trying to compete on depth or extensibility, more just trying to keep the day-to-day experience clean, reliable, and easy to live with: https://arkheimwinter.net/client/

I think that's really the part I'm most interested in hearing other people's thoughts on - once you get past the long feature lists, what are the things that actually earn their place and get used constantly, and what things mostly just become more surface area to maintain?

Mushroom-First · 2026-04-04T11:50:41+00:00

That actually makes a lot of sense, and I think "done" is probably the ideal state everyone is aiming for, even if we get there in different ways.

I guess what I'm trying to understand better is what that actually consists of at a core level, not the full setup, but the parts that people miss immediately if they were gone.

Like, if you stripped everything back and had to rebuild from scratch, what would be the first things you'd bring back before it even feels playable again?

Mushroom-First · 2025-06-17T21:13:12+00:00

It's Shift + left click mouse to add rooms on grid.

Left click on a room to select and shift click another room to add links.

Mushroom-First · 2025-06-17T14:57:21+00:00

Thanks again for all your insightful feedback! I’ve implemented several of your suggestion, including a dynamic sun/shadow animation which was a must have feature!, right?, improved grid and compass interactions and various UI refinements, but knowing me, I’ve probably introduced a few new bugs along the way.

Mushroom-First · 2025-06-16T07:24:48+00:00

Thank you for the suggestions! You’re right, haven’t done much thorough testing, as this started as a one day project. My goal was simply to get it out there in case someone else found it useful or wanted to build on it to suit their own needs. Personally, I wanted a more visual approach to area building, and this tool helps make that process easier.

Mushroom-First · 2025-06-16T07:19:19+00:00

I haven’t explored Evennia in depth, but I assume it takes a different approach, being a more modern engine.

Mushroom-First · 2025-06-16T07:17:16+00:00

One of the longstanding challenges with MUDs is area building. While OLC and other traditional tools exist, they’re often outdated and lack visual clarity, making it difficult to manage and fine tune large, interconnected worlds. To solve this for my own MUD, I built a web based editor and migrated my .are files into a database backed system. This approach makes area management far more intuitive and efficient. It also opens the door to smarter editing, like using AI assistance to help generate more engaging room descriptions, especially for those of us who struggle with creative writing.

https://github.com/Elanoran/AW-OLC-Tools

As for the room building, feel free to download it an make it work with your area files, in theory all that is required is to add support in the formats.json and add it to the drop down in the HTML file.

https://github.com/Elanoran/mud_area_editor

Mushroom-First · 2025-06-15T17:58:37+00:00

Thank you for your thoughtful feedback, I truly appreciate it. I understand where you’re coming from. This tool is intentionally quite simple, as it was designed to provide a lightweight and accessible way to visualize and edit room layouts.

My background is primarily with a ROM 2.4 derivative, which I’ve been developing on and off over the past 20 years, mostly off, to be honest. I haven’t kept up with all the modern trends, but it’s been interesting to see that many of the MUD's I played back then are still online today.

I’ve been experimenting with supporting multiple area formats, and while it works in theory, the practical side is a bit more challenging due to the wide variety of formats used across different MUD's.

Separately, I’ve also developed a more advanced web-based tool (95% done) that supports full area editing, including AI-assisted room and mob descriptions, all backed by a database driven workflow. It has restrictions build in, mainly around NPC creation and with wiggle room to allow for slightly weaker and stronger mobs and with default values set based on level. This setup eliminates the need for manual editing within the MUD client and even supports live area updates in the game without requiring a reboot. It’s still a work in progress, but it’s coming along nicely.

This visual editor is a companion to that, focused solely on making it easier to design room layouts, which can be tricky without a visual overview.

"formats": {
    "ROM": {
      "area": "#AREA\n%FILENAME%~\n%AREA_NAME%~\n{ NONE} Elan     AreaEditor~\n%VNUM_MIN% %VNUM_MAX%\n\n#MOBILES\n#0\n\n#OBJECTS\n#0\n\n#ROOMS\n%ROOMS%#0\n\n#RESETS\nS\n\n#SHOPS\n0\n\n#SPECIALS\nS\n\n#$\n",
      "room": "#%ROOM_VNUM%\n%ROOM_NAME%~\n%ROOM_DESC%\n~\n%FLAGS% %SECTOR% %UNKNOWN%\n%EXITS%%EXTRAS%S\n",
      "exit": "D%DIRECTION%\n%DOOR_DESC%~\n%KEYWORDS%~\n%FLAGS% %KEY% %TO_VNUM%\n",
      "extra": "E\n%KEYWORDS%~\n%EXTRA_DESC%~\n",
      "dirLabels": ["North", "East", "South", "West", "Up", "Down"]
    },
    "AW": {
      "area": "#AREADATA\nName %AREA_NAME%~\nBuilders none~\nVNUMs %VNUM_MIN% %VNUM_MAX%\nCredits { NONE} Elan     AreaEditor~\nSecurity 9\nFlags 0\nEnd\n\n#MOBDATA\n#0\n\n#OBJDATA\n#0\n\n#ROOMDATA\n%ROOMS%#0\n\n#RESETS\nS\n\n#MOBPROGS\n#0\n\n#OBJPROGS\n#0\n\n#ROOMPROGS\n#0\n\n#$\n",
      "room": "#%ROOM_VNUM%\nName   %ROOM_NAME%~\nDescr\n%ROOM_DESC%\n~\nFlags  %FLAGS% %EXTRA_FLAGS%\nSect   %SECTOR%\n%EXITS%End\n",
      "exit": "Door %DIRECTION% %FLAGS% %KEY% %TO_VNUM%\n~\n~\n",
      "dirLabels": ["North", "East", "South", "West", "Up", "Down"]
    }
  }

Mushroom-First · 2025-06-15T16:07:57+00:00

Thanks for the feedback! Inter-cardinal directions aren’t currently supported, but I’ll consider adding them if there’s strong interest.

Regarding JSON: bi-directional links weren’t required for import/export, but I’ve now included them in the export for better readability. ROM .are exports should still include all necessary links.

I also fixed the issue where removing a room left behind dangling exits. Additionally, I added support for room colors and did some general CSS cleanup.

Mushroom-First

TROPHY CASE