Can a MUD evaluate LLMs? A $99 proof of concept

> I really wish MUDs were still a thing.

About 15 years ago, for a while I ran a MUD over AX.25, because MUDs aren't nerdy enough on their own, and amateur radio - even packet radio - isn't nerdy enough on its own.

All three of us that used it found it pretty entertaining.

Very cool! Why reimplement the "moo code", though? Is it "just" for backward compatibility, or did you determine that none of the existing languages can be easily modified to live in a MOO environment?

I started playing on an LP MUD in the late '90s. Over the past 20 years, I tried a few times to implement a similar environment, only with everyone being a "wizard". LPC was also a prototype-based OO language with multiple inheritance, and it supported live development, with code for objects stored in files and dynamically reloadable. I would always hit some kind of blocker, no matter the language I chose for the implementation. It looks like MOOs did (and do) what I wanted, but I just wasn't aware of their existence. :( Maybe if I used MOOs as a model, I'd get better results... but I'm not sure if I want to go all in on DB. I tried looking up how the code is loaded into the DB in the book (https://timbran.org/book), but couldn't find it. Is there an explanation somewhere of how MOOs are bootstrapped from sources, how you can maintain sources in files on disk, and how new definitions are pulled into the DB at runtime?

There's all sorts of reasons, not sure what level of detail you want me to get into. I've got about 30 years of thoughts on this.

For one, I think MOO is kind of shite in lots of ways. But I and others spent lots of time 20+ years ago building alternatives and nobody used them. There's intrinsic value to just picking up and then improving on something that has established history. It gathers an audience of users, has name recognition, and most importantly keeps you responsible from an engineering dev POV because you are forced to focus on delivering a thing that works and you have a way to prove it. As Linux has shown, incremental improvement on a somewhat flawed but relatively popular and known foundation has value. mooR cakes over a lot of the ugly parts of MOO and honestly, I'm pretty proud of it.

Secondly, existing "mainstream" languages are not appropriate, mostly. None of them or their runtimes are really based on a properly sandboxed persistent model. I poked at WASM, and I could write a screed about that, but wrong system. MOO (and successors to it) were built with the idea of lots of people jamming on one shared world, and it shows.

Finally, I have all sorts of ideas on what I think is "better" than MOO, and did eventually open the floodgate this spring and start building out the "dream system" here: https://github.com/timbran-project/mica -- but as you can see from relative star count of one vs the other.. my first point has relvance.

There should be an explanation in the book on how loading works. If not, I'll need to clarify. Documentation writing sucks. But the TLDR is that one of the arguments you pass to the system at start is basically a source directory of ("objdef") human readable / editable source files, and that gets compiled into a persistent binary database. Once that's done, restarts load directly from that DB/image, not source. (But the system can periodically export or "dump" objdef files as well).

Note this is a bit different from classic LambdaMOO, which had no such process. It had a primitive text database that was not human editable really, and you started from what people passed around of those.

Hope that helps. Come by the discord if you have questions: https://discord.com/invite/Ec94y5983z

Also I just finally put up a new blog post on dev status https://timbran.org/catching-up-with-moor.html

EDIT: I've done some book edits and added a chapter here which I hope helps: https://timbran.org/book/2.0-dev/html/the-system/bootstrappi...

MUDs are still kicking around and if you'd like to play in one you'll find a few solid communities with good engagement that would love to include you. They're in an odd spot though since MUDs existed in two sorts of categories 1. I really want to adventure and text is the only way to do that (these sorts died off to MMOs) and 2. I want to roleplay - those survive but the mechanical portions of those games are becoming more and more irrelevant as new games are constantly supplying better systems and mechanisms than MUDs were able to.

This leaves MUDs in a weird place since things like MUSHes generally have most of the roleplaying tools without as much weird code for attacks and PVP interactions being involved so I've seen those thrive more recently.

There is an ongoing project doing this (that launches this weekend I believe) to revive a MUD called Shadows of Isildur. I think a lot of effort has been put into the new changes to the codebase to bring QoL features that a modern audience would expect while keeping the bones of the game the same. I'm not certain how it will fare as, to be honest, MUDs take an inordinate amount of time to really groove into and immerse yourself in - but I am excited to see efforts like this invested on as we older MUDers find ourselves finally reaching the point of having free time again.