shollen1@icloud.com

[Shan Hollen]

MegaMOO - If anyone's here and interested in a modern re-imagining of the  MOO engine, please check out my pure Python rewrite: https://malifaxlax.github.io/megamoo/index.html

[KJ]

Hi Shan
Is there some reason for not making this engine compatible with the  existing MOO programming language?
There is a sh*t ton of good MOO code out there that could be used in new MOOs with out having to start from the scratch.
Ciao
KJ

[Shan Hollen]

Hey, KJ! Thanks for the reply!

You ask a fair question, and my README invites it — I call it a reimplementation of the server, which oversells the compatibility. It reimplements the model (single-parent inheritance, properties and verbs on objects, live in-world programming, wizard/programmer/owner permissions), not the language. I should say that more clearly.

The reason is that language compatibility alone wouldn't get you what it looks like it would. Getting existing code to actually run means matching the builtin suite, the permission semantics, pass(), verb arg specs, property clear, and the tick/quota model closely enough that subtle things don't silently misbehave. Partial compatibility is the worst outcome — code that looks like it works.

What I think is genuinely worth doing is a database importer: bring an existing MOO's objects, properties and hierarchy across, and archive the verb bodies as source to port. Most of what's accumulated out there is worlds, and that's the part that's painful to rebuild. Verb code is the part I'd rather people rewrite in a language they already know.

Not built yet. If that's the thing that would make MegaMOO useful to you and others in the MOO community, say so and it moves up the list. MM really is in active dev and my suggestion box is wide open.

Thanks again for replying!

-Shan

[Ty Littlefield]

This actually looks really cool, I'll check it out.

Out of curiosity, I see a bunch of the extension protocols, but why did you choose to leave off MCCP? Or was that just a choice.

I'm also curious if you've considered other network connection tyipes. For example, SSL.

Thanks,

On 8/3/2026 6:05 PM, Shan Hollen wrote:

Hey, KJ! Thanks for the reply!

And that's a good question. The answer is, I spent decades wrestling with C and hacking the LambdaMOO server. It was like pulling teeth adding features to such an antiquated architecture in a language I didn't know well. I wanted to be able to add features, bring a MOO engine into the 21st century and actively develop the engine as I built my own game, and there was no way I could do any of that by clinging to C and the MOO language. And since I know Python that's the route I went. I love the MOO paradigm, but the LambdaMOO engine was an anchor around my neck. Porting the MOO language on top of a Python server made zero sense when writing.verbs in Python gives you almost all the functionality of the MOO language, all the speed and power of a modern scripting language and all the modern amenities that come with Python, and whatever MOO functionality doesn't come in the Python stdlib you can write yourself in minutes. The truth is, if there's existing LambaMOO code you want to use in MegaMOO, feed it to your AI of choice and have it port the MOO code to Python. We built a custom core back in the early 90's and I ported most of it to MegaMOO and the base db in a couple days. If you have a game you'd like to run in MegaMOO, you could probably move it over in a week or two of lazy work. I'm a Python coder but a coupli of the cool things about MM, at least to me, is that it's a drop and go install with a heck of lot more to start with than LambaCore and minimal.db gave you, including a full world-building suite and extensive documentation in the published guide and well-code comments. I actually built a whole MOO platform on top of Evennia but it lacked prototypal inheritance and stuff at the guts of a real MOO, so I built my own. MM has a built-in MCP server, so with an  AI assistant you don't even need to know much Python to develop a full-blown game in MM. I get why you ask the question, but dragging the MOO language along with my Python server made zero sense, especially when porting MOO code is so trivial. "Installing" MegaMOO costs nothing, and I'm not talking about money. Download the engine, type a couple of lines into your machine's CLI and you're ready to log in. The Getting Started section of the guide walks you through it, and I'm more than willing to help. Please give it a look and leaf through the guide on GitHub. It'll take ya maybe an hour. :)

On Monday, August 3, 2026 at 6:51:02 PM UTC-4 KJ wrote:

--
You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/MOO-talk/6686b9bb-bd5e-496f-b6aa-c94639de8ba9n%40googlegroups.com.

--

Ty Littlefield (he/him/his)

• My Website|
• Linkedin|
• Github

[Shan Hollen]

Thanks, Ty! I'd love your input and any criticisms/suggestions you and anyone else has to offer. I would love to see MM flourish and develop a little community of MUD builders. That means making the engine more friendly to old MOO coders and old MOO code. 

 I deleted my original post to KJ. Not constructive. My second post is more in the spirit of what I meant to say, forgetting that this is a mailing list. Oops! Anyway, I took the point about the framing. The README and the guide now say plainly that MegaMOO reimplements MOO's model and not the MOO language, and there's a short "Porting from LambdaMOO" section with the substitution table — player:tell → pobj.msg, $string_utils → the standard library, pass() → call_verb, and so on. The database importer is on the roadmap now too.

Thanks for the push, KJ — it was a fair reading of what I'd written.

"Out of curiosity, I see a bunch of the extension protocols, but why did you choose to leave off MCCP? Or was that just a choice."

At the time I think I thought we'd come a long way with bandwidth since the 90's and conserving it wasn't a priority, but if you think it's useful I'll add it.

"I'm also curious if you've considered other network connection tyipes. For example, SSL"

I haven't. Would you like to see others?

I have a MewaMOO channel up on Discord, if anyone's interested in talking there.

[Ty Littlefield]

Sorry, one other question from reading the github. also just some quick notes:

If I use help after creating a new character, I have a ton of commands but some of them don't register as commands (@s) for example.

There's also stuff like _hits as commands. If I use that, I get this bug:

Error: Permission denied: cannot create 'tickers' on #1

I'm also confused by the example verbs on the README. This looks heavily vibecoded, specifically because AI loves to write getattr on everything. So the example uses getattr on player to get roundtime, then getattr on position. Is there a reason player wouldn't have a roundtime prop or a position prop? Getattr can be kind of slow, but this also just makes for really difficult code to read if it's for every property on player.

Thanks,

On 8/3/2026 6:05 PM, Shan Hollen wrote:

Hey, KJ! Thanks for the reply!

And that's a good question. The answer is, I spent decades wrestling with C and hacking the LambdaMOO server. It was like pulling teeth adding features to such an antiquated architecture in a language I didn't know well. I wanted to be able to add features, bring a MOO engine into the 21st century and actively develop the engine as I built my own game, and there was no way I could do any of that by clinging to C and the MOO language. And since I know Python that's the route I went. I love the MOO paradigm, but the LambdaMOO engine was an anchor around my neck. Porting the MOO language on top of a Python server made zero sense when writing.verbs in Python gives you almost all the functionality of the MOO language, all the speed and power of a modern scripting language and all the modern amenities that come with Python, and whatever MOO functionality doesn't come in the Python stdlib you can write yourself in minutes. The truth is, if there's existing LambaMOO code you want to use in MegaMOO, feed it to your AI of choice and have it port the MOO code to Python. We built a custom core back in the early 90's and I ported most of it to MegaMOO and the base db in a couple days. If you have a game you'd like to run in MegaMOO, you could probably move it over in a week or two of lazy work. I'm a Python coder but a coupli of the cool things about MM, at least to me, is that it's a drop and go install with a heck of lot more to start with than LambaCore and minimal.db gave you, including a full world-building suite and extensive documentation in the published guide and well-code comments. I actually built a whole MOO platform on top of Evennia but it lacked prototypal inheritance and stuff at the guts of a real MOO, so I built my own. MM has a built-in MCP server, so with an  AI assistant you don't even need to know much Python to develop a full-blown game in MM. I get why you ask the question, but dragging the MOO language along with my Python server made zero sense, especially when porting MOO code is so trivial. "Installing" MegaMOO costs nothing, and I'm not talking about money. Download the engine, type a couple of lines into your machine's CLI and you're ready to log in. The Getting Started section of the guide walks you through it, and I'm more than willing to help. Please give it a look and leaf through the guide on GitHub. It'll take ya maybe an hour. :)

On Monday, August 3, 2026 at 6:51:02 PM UTC-4 KJ wrote:

--

You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/MOO-talk/6686b9bb-bd5e-496f-b6aa-c94639de8ba9n%40googlegroups.com.

[Shan Hollen]

This is my first public repo and you are the first person to use MegaMOO other than me. I really appreciate your patience and your feedback. I pushed a fix for the verb bug/s and started adding some MOO compatibility logic. The fixed vrsion is available for download.

[Jo Jaquinta]

I did the same sort of thing with Java a few years ago. I hit exactly this dilemma. The MOO language is kind of clunky and unfamiliar to modern programmers. (Not to mention AI generators.) But, on the other hand, trying to replicate all that baseline MOO code in Java... well that's where thing bogged down. The project didn't get far enough fast enough before Alexa imploded. (This was primarily to create a self authoring environment for voice apps.)

I'd like to get back at this at some point. But I need a good accessible front end. I'm not sure there is a lot of value making yet another telnet accessed MUD. LLMs have come a long way since I tried, and, if I remember right, the MOO source code isn't that large. I could probably do a straight port, including the parser. It might be possible at that point to support multiple languages. 

My knowledge of the MOO source code base is pretty antiquated. I'm not sure what MCPP is and how that might factor in.

I've only mentioned it briefly here once, as I didn't think there was much demand outside my very niche needs.

Cheers,

Jo

--

You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/MOO-talk/a6f0e08e-8789-43bb-b337-c229175002ean%40googlegroups.com.

[Shan Hollen]

Hi, Jo!

Yeah, I get what you're saying. It's probably a pipe dream to hope that we could inspire a MOO revival, but i'm gonna try. I know graphics and instant gratification dominate gaming these days, but there has to be a thirst for virtual life and real roleplay in a sandboxed virtual world. The problem is reaching that small niche of game players. I'm building an old-style hack and slash MUD with modified Rolemaster combat and an emphasis on player-driven storytelling. I know the possibility of anyone ever playing it is remote but I'm having fun building it and am learning a lot.

If you haven't looked into writing your engine with AI help, I would encourage you to do so. The dev cycle is quick and it makes coding fun. Claude has allowed me to do stuff in months that it would take me years to write on my own. And I totally get Tyler's observation about defensive AI coding and readability. So I'm working on a refactor.

Anyway, I hope you'll consider resuming work on your engine. It's great to hear from someone with similar goals and experiences.

-Shan

[Derek Roberts]

Hi,

There's also moor, a moo rewrite in rust. If you specificly want lambda compatibility with extras, it may be worth a look for you.

on Llms and moo code, they do better reading it than writing it. I've been working on helping an AI understand and be able to code in it, but even so I still have to play AI therapist when it chokes on some features, and very stubbornly refuses to budge. LOL. I've had the best success with Claude Opus 4.8, its better reasoning over longer contexts is directly helpful, and I think it absorbed moo better in its training. When I have had to correct it, it handles that correction better than Sonnet, any of the OpenAI models I've tested, and don't get me started on the others, that's a whole different discussion. Happy to have it, if anyone's interested.

I'd be happy to help bang on the Python MOO, though it may be a couple weeks before I can get to it. I'll look forward to playing with it!

Thanks,

Derek 

To view this discussion visit https://groups.google.com/d/msgid/MOO-talk/239c236b-dc3b-4321-a02d-a12a0a219d40n%40googlegroups.com.

[Shan Hollen]

Hey, Derek! Thanks for the reply. I look forward to your input.

[Shan Hollen]

0.8.0-beta pushed. It includes bug fixes, a bunch of legacy LambdaMOO verbs, a module with MOO compatibility add-ons like tell:(), to remove some obstacles from porting MOO code to Python, and a .db importer. Check out the Coming From LambdaMOO chapter in the guide: https://malifaxlax.github.io/megamoo/moo-compat.html

[Todd Sundsted]

I'm super-thrilled to see people still pushing LambdaMOO forward in new directions! This whole thread made my week!

Todd

[Jo Jaquinta]

Hey Ty,

    Given the age of the MOO code, and the speed of modern processors, I wouldn't expect parsing to be a bottleneck. And, yes, Pavel knew what he was doing; his code is an inspiration even after all these years. It was my go-to choice when I wanted to take my audio games up a notch. At least for architecture. I wanted something that would natively support SSML, and was easier for downstream programming with audio tools. In the end my conclusion was there was a lot of real value locked up in LambdaCore. It was all well and good me re-writing LambdaMOO in Java with Javascript as the scripting language. But unless I ported all of LambdaCore to Javascript, I wasn't going to get the real value. If I ever got back at it, I'd stick to being MOOScript compatible.

Shan, to your points... 

My bitter experience is that text adventure games are not going to go mainstream. I was on the Alexa bandwagon for several years (wrote three books, spoke internationally, blah, blah, blah) and took major inspiration from text adventure games. An audio app is, essentially, the same sort of non-pictorial linear interfaces. I did the first MMO there, and a pretty deep implementation of an open source version of D&D. Some of these were deeply engaged. I had some players playing for ten hours a day. I was flabbergasted. Our business model just need a couple hundred people equally engaged and we figured we could monetize it. But come hell or high water we could not get our numbers up. Some of that was Amazon's fault, and I'm happy to rant for a long time about how working with them was like being in an abusive relationship. But I'll try to stay on-point for this forum. Part of trying to work out how to increase our user acquisition I ended up talking to a lot of our engaged players. They were visually impaired. Every single last one of them. I did not find a single player who played the games to any degree who was not. The end lesson for us is that no matter how deep or richly enabled the game is, that if people have the choice of spending time with fancy graphics, or a non-graphical interface, they will always choose the graphical interface. These guys keep begging me to do more stuff for them. No one else is making deeply enriching stuff for blind kids. I have no business case for it, so I kind of mess around with it as a hobby. It's a niche you might consider if you want a built in audience.

And, yeah, I'm quite familiar with using AI for coding. My day job is with IBM and I'm my product's "AI Champion". Derek pointed out that there are limitations on using AI for MOOCode because of the lack of a trained corpus.

But beyond programming, AI also offers a lot for games themselves. It was one of the first things I integrated into my own MOO clone. There was, essentially, a base object you could clone, and set properties for context, sample exchanges, AI settings, etc, etc. You would then have an AI driven NPC bot players could chat with in game. 

One of the big lacks we hit in audio development was that there was no standard library widgets. No buttons, list boxes, etc, etc. We eventually came up with our own set, and I could imagine those being useful in LambdaMOO. I'm happy to share the design of our set. I'm also happy to learn if this has been done already!

Cheers,

Jo

On 8/4/2026 11:18 AM, Ty Littlefield wrote:

Honestly, I don't find the server all that hard to work in. I added a lot of stuff to toaststunt, some (most) experimental. Overall though, it's not all that slow in comparison to most interpreted languages. There are some things I wish it did better, like store the bytecode in memory and just recompile the changes rather than unparse and reparse the compiled code.

I would also argue that telnet isn't the factor or the issue. You could very easily create a JSON-driven listening point over MOO if you wanted. Put that behind an ssl proxy and you now have yourself JSON over ssl feeding into a moo.

As old as it is, it's aged rather well and would do amazingly in a lot of projects. I think also with a bit of rethinking, some of the more frustrating features could be rewritten. This is something you'll struggle with in a 1:1 port to Java, Lisp, Rust, or whatever else language someone thinks MOO's recoding will be best in.

Ty Littlefield (he/him/his)

• From Bytes to Bites|
• Linkedin|
• Github

To view this discussion visit https://groups.google.com/d/msgid/MOO-talk/d1ad93a5-c3c2-4e34-9877-e3b7e531e2a6%40111george.com.