r/MUD • u/MalifaxLax • 5d ago
Promotion I wrote a MOO engine with Python as its in-game scripting language, and am building a virtual world on top of it
MegaMOO is a comprehensive pure Python world-building engine modeled on the LambdaMOO paradigm: data and behavior living on objects in-game; live creation and hot world editing--no reload and no restart; an auth and permission system that lets you give builders true authoring power, sandboxed by ownership; a suite of authoring commands that lets you build right out of the box without writing a single line of code, but also puts the power of in-game, on the fly Python scripting in your hands.
A few highlights: There's a SQLite object database under the hood, with WAL crash recovery, telnet and browser players in the same process, MXP links, GMCP, MSSP, MCCP2, and a JSON API that reads and writes from the outside: what an MCP server or AI agent talks to. Spin up multiple worlds and run them simultaneously, just copy and start. A built-in browser client with auto-mapper, triggers, aliases, timers and panels, served from the game itself; and my favorite, a '/'-aliased eval command that parses ordinals and adjective-object strings to run statements and blocks, not just expressions.
Try it out:
https://malifaxlax.github.io/megamoo/getting-started.html
https://malifaxlax.github.io/megamoo/
pip install megamoo
megamoo init mygame
cd mygame && megamoo --dev
Your account name is "wizard." The init string prints your initial password and the last command prints a URL. Opening it puts you in the world. The browser client ships with the server so there's nothing else to install.
I'm building a MegaMOO-based game myself, old-school hack 'n' slash with an emphasis on role-play and mechanics built to encourage and reward player cooperation and collaboration. Swords, Sorcery and Cybernetics in a mutating post-apocalyptic world.
9
u/Early_Rooster7579 5d ago
so evennia but vibecoded
1
u/MalifaxLax 4d ago
Fair questions, both, so Evennia first:
I spent 13 years writing MOO code before a decade developing in Evennia, building a full MOO platform on top of Griatch's amazing engine: the object model, the verb dispatch, in-world programming. And it worked. And I learned a ton doing it. But what I kept running into was that I was fighting the paradigm I loved. I wanted objects parented to other objects, editable live from inside the game, and Evennia's inheritance lives in typeclasses--Python classes on disk. Which isn't a flaw. It's deliberate and sensible design. It just isn't the MOO way, and I wanted the MOO way badly enough that I quit working around it.
To be clear about what MegaMOO isn't, it isn't Evennia and isn't trying to be. Evennia is much more capable and much better supported, and it's not close. If you want the web integration, the batteries, the contribs, the community, that's Evennia. This is something different and more narrow, for people who like the MOO model and would rather write in Python than MOO code. I gave up the infrastructure of Django and Twisted because I wanted a simple install with zero third-party dependencies, and copy-world-and-run ability so I can run multiple instances of my game side by side.
On the AI: Yes, and it's on the tin in the README. I'm a trained software engineer who also happens to be a quadriplegic who uses a head pointer for a mouse and clicks the keys on an on-screen keyboard at 30 words a minute, so if I didn't want to spend five years writing my engine I was going to need some help. I write the design, make all the calls and review everything that lands. The commit log is public if you'd like to see what that looks like in practice. I'm happy to talk through any part of it you're curious about.
If you're interested in my setup, I use a headset called HeadMaster originally developed by Personics and then bought by Prentke Romich. I've been using the headset since my accident 40+ years ago and they quit making it a long time ago. There's nothing else like it out there so I guard it with my life. :)
1
u/Early_Rooster7579 4d ago
All good! I’m also a swe who heavily uses AI. My comment definitely came off more critical than it was meant to.
AI is a great tool in devs hands.
2
u/bscross32 4d ago
I can't even write a coherent thought about this, I guess curiosity will get the better of me and I'll check it out. But my thoughts flit back and forth between hmm, and why the hell.........? But also, I already know MOO code, what benefit would there be of me coding in Python besides not being bound to a fixed set of MOO builtins?
I'm blind, I use a screen reader. Do I need to have a web server going to use this thing? It's of no use to me, at least in the developmental period. If I actually shipped a game with it, yeah, I'd have to spin it up for sighted players, but if the web server is the only way to connect, that's me out.
1
u/MalifaxLax 4d ago
Taking the important one first: no, you do not need a web server.
Telnet is the main listener and it's always on, default port 6770. The browser client is opt-in, off by default. It only exists if you pass --web at startup. Don't pass it and no web server starts at all. Point any MUD client at the port and you're in.
The browser client leading in almost everything I've written is my bad in the pitch, not a description of the architecture. I guess it's the splashy part so I talk about it, and you aren't the first person that it has misled. The comment in my own config source says the plain port has to keep working because telnet is how most people actually reach a world, and that's the design.
The screen reader... There's a screenreader command, per-player and persistent. It strips ANSI at the output layer, and individual verbs check it too and change the way they emit. The room header comes out as plain labeled text, "Room: The Kitchen" instead of a color-coded name. You can also set WRAP_WIDTH = 0 to switch off server-side wrapping entirely and let your client handle it. I would love your input on how I can make MegaMOO better for blind players and developers. Please, fire away. I'm all ears.
I'm not going to pretend any of that is the same as you actually trying it. If you do and something reads badly, please let me know and I'll fix it. I mean that literally. It's the bug report I want most and get least often.
Why I'll take it seriously... I'm a quadriplegic, using a head pointer and an on-screen keyboard at 30 words a minute. Accessibility isn't a feature I bolted on, it's why a lot of the engine looks the way it does. Different disability, same fight with software that makes a lot of assumptions.
Python vs. MOO code... Honestly, if you know MOO and like it, that's a real reason to stay put. I'm not trying to sell this as a strict upgrade, but here's what you'd actually get...
• The standard library, not a longer list of builtins: re, json, itertools, datetime, native string handling, things you'd have to build yourself or borrow off $string_utils.
• Real dicts, sets, comprehensions.
• Exceptions with tracebacks instead of error values you check by hand.
• Verb files are ordinary .py files on disk. So your editor, your formatter, your navigation all work on them normally. One caveat I should mention: the engine injects the verb's context (player, this, dobj, db, call_verb...), so a linter flags those as undefined untl you add them to its builtins list. That's a config line but it's a config line I don't ship, and I should.
• The skill transfers out. Python you learn writing verbs is just Python.
The last one is the real answer for me, though "I already know MOO and really like it" is a valid place to land and I'd rather say so than oversell.
2
u/bscross32 4d ago
Yeah I did get it going today and did a little looking around the verb code. I think a big detractor for me is the documentation is entirely written by AI, and the verb code is shot through with tons of AI comments. I'm not faulting you for it because I did see your other comment about your head tracker and what you've put here, so that wouldn't be fair, and you could just tell me to grow a new optic nerve lol.
It's also not just that it's AI, it's that I just can't retain AI written documentation, it just bounces off. I do need to do some more poking around.
1
u/MalifaxLax 4d ago
Would it help if I thinned out the comments?
1
u/bscross32 3d ago
Maybe, but it might be detrimental to your own efforts so it might not be worth it. I've noticed in my own projects that LLMs tend to use comments quite liberally to explain why things are done a certain way, so removing them might cause issues later. I kind of wish they didn't, because they're annoying, but then again, I did hit the 150k char limit fr claude.md on one of my projects so I had to break it up over several files.
1
u/MalifaxLax 3d ago
I could add a version with comments removed, or leave the docstrings and take the comments out of the body. It doesn't have to be either/or. I would like to make MM a friendly platform for you and other blind players/developers. Tell me what you need and I'll do my best to make it happen.
1
u/bscross32 3d ago
I wouldn't say it'd be worth it. What I might do is have ChatGPT take the documentation and feed it the ToastStunt manual and whip me up a side by side type thing. I think ChatGPT / Codex is better at documentation than Claude, even though it's still not what I'd call great.
1
u/MalifaxLax 1d ago
MegaMOO 0.10.0-beta22
• 2839 lines of restated commentary cut from stock verbs.
• Screen reader now reachable before character creation.
• Building and introspection commands: one labelled fact per line instead of padded columns (sighted output unchanged)
• Verb files now lint clean. Injected names made a linter report 4683 undefined names across the starter. The install now includes a ruff.toml.
Existing worlds don't receive any of this yet. Fixing that next.
2
u/NoProgram1720 4d ago
Interesting project!
I'm working on a similar concept, but in Common Lisp (https://github.com/sovelten/apeiron-mud). I also wanted to have the same language for driver and scripting, and Common Lisp has some interesting runtime characteristics that makes it suitable for running a live environment.
I'm not using a SQL DB but an Object Persistence model.
I'm interested in knowing what kind of problems you face. I think using a language with full power gives a lot of freedom, it's great for creating and modifying objects on the fly with pre-existing mechanics, but for writing new objects and functions I would like to have better version control (meaning git or similar). The only system I ever used that got close to merge source code and a live experience was the Smalltalk environment. Lisp comes close (Smalltalk was inspired by it), but code is still file based. Because Smalltalk is not file based it looks really awkward on file-based source control. You are supposed to edit the code within the live image.
2
u/MalifaxLax 3d ago
That sounds really cool. I've never used Lisp but it seems like it would be a great game-scripting language. Using a programming language as the scripting language for world-building puts a lot of power at your fingertips that a proprietary language can't match. The Python stdlib replaces bunches of MOO builtins and utilities, does them more efficiently, and offers native data structures and stuff. I've encountered relatively few hurdles in building my engine. The MOO paradigm is well-documented. I just built it from the ground-up in Python with Python as its in-game scripting language. Good luck to you. I hope you succed.
1
u/NoProgram1720 3d ago
Have you seen Moor (https://github.com/timbran-project/moor)? It's a rewrite of LambdaMoo in Rust. Do you intend to keep some compatibility with LambdaMoo or write it all from scratch?
1
u/MalifaxLax 2d ago
I'm not sure if you're asking me, but...
Yeah, I've looked at mooR, and it's a great piece of work: full 1.8.x database compatibility and it kept and extended the MOO launguage. If you have a LambdaMOO running that you want to keep running with the code intact, mooR is the way to go.
I went the other way with MegaMOO, on purpose.
What carries over... The model, entirely: single-parent inheritance, props living on objects, etc. `@import` reads LambdaMOO database formats 1-4, so anything up to 1.8, and brings objects, hierarchy and props across, remapping object references as it goes. LambdaCore's utility objects are ported as real, in-world objects: `$string_utils`, `$object_utils`, `$list_utils`, `$match_utils`, `$code_utils`. Errors are first-class values the way they are in MOO and E_PERM and friends carry LambdaMOO's own numbers so error values round-trip through an import.
What doesn't... The language. Verbs are Python in MegaMOO, so MOO code doesn't run. It still comes across on import, inert but defined verbatim under a docstring recording where it came from, hidden and without the execute bit, sitting on the correct object under the right name instead of in a tarball somewhere. `@grep` 'UNPORTED MOO SOURCE' tells you what's left and `@port` translates a verb at a time. There are shims for those expressions you type without thinking, tell(), pass_(), so ported code reads roughly the way it was written.
So... From scratch as a server, compatible at the object and library level, and a migration path instead of a compatibility layer for the code itself.
Which makes us complementary, I think. mooR is for people who have a MOO and want to keep it. MegaMOO is for people who like the MOO model but would rather write Python than MOO code.
I actually ported a MOO core we wrote back in the day by hand to the MOO layer I built on top of Evennia, then ported that massive suite of verbs to MegaMOO. I used the db, a game called Inferno, to test `@import`. 61000 objects and 3300 verbs. And it worked. But it would've taken a lot of porting and rewiring to make the game playable, so it was possible but I had other goals.
2
u/revfried 4d ago
I was thinking of building a rust based engine using Meta’s starlark module to fake python. Its python light and runtime types would be a great game scripting language if your engine is rust. But its very performant and is sandboxed
1
u/MalifaxLax 3d ago
Rust seems like a great platform for writing a game engine. Check out mooR: https://github.com/timbran-project/moor
1
u/TemperatureFast9764 3d ago
can I download megamoo on to google chromebook linux?
1
u/MalifaxLax 3d ago
I've never tried it but MegaMOO is pure Python with no dependencies. pip install megamoo pulls about 1.1 MB, and that's everything. If your machine runs Python 3.10+, I don't see why you couldn't.
1
u/MalifaxLax 3d ago
MegaMOO's lineage...
The server is a ground-up reimplementation of LambdaMOO in Python using asyncio and SQLite. No Django. No Twisted. No third-party dependencies at all. One file. One process. It uses prototypal inheritance and provides tools for creating objects and adding behavior in-game instead of in Python classes. +decompile, `@adverb and u/code` let you view and program verbs live in-game. Compose in a text editor and copy/paste, and your verb is live a second later, written to a <objnum>/<verb_name>.py file on disk. So you can write verbs in-world on the fly, but they exist as Python files and if you'd prefer to write in an IDE, you can do that too and your verb will be hot loaded almost instantly into the db. If you'd rather not give access to code online, just `@verbauth #3.\@adverb, \@program, \@port` and eval up to 5, and you're all set.
The builtins are mostly ports from Lambda, but a vast majority of the creation, coding and administrative verbs were ported from a db we wrote in the early 90's. We liked the MOO model and chose LambdaMOO because of its stability. But our backgrounds were in playing games like Gemstone III and Legends of Futures Past, so unlike LambdaCore, which focused on building by players, our db was designed for building by a team of gamemasters and playing by patrons without access to those tools.
MegaMOO includes all the typical building and other infrastructure and staff commands, but also all the MUD protocols and OOB scaffolding that LambdaMOO did not. I added a ticker system (thanks, Griatch), reusable effects and stuff like verb types for adding customized parsers, and settings in globals.py that let you customize articles and prepositions. Non-staff verbs are defined on room parents instead of characters or individual objects, one "get", one "tap", one "look" verb, each with a call to an obj.<verb>_ hook on a matched object for adding per-object behavior. MasterVerb is the default verb type. It parses a natural language <verb> <dobj> <prep> <iobj> string that splits at the first preposition so shapes like "look in/on/under/behind" also work. Objects are constructed as <article> <adjectives> <noun> <trailer>, and parsed with ordinal checks: look under 3 gray rock.
1
u/Griatch Evennia 1d ago
Good luck! Python-based Moo- like coding is something we've often discussed in Evennia, but, as you yourself acknowledge, sandboxing is simply not what Python was built for. Relying on this being a mod/admin power is a good move - IMO it's the only way to be safe.
(Long before AI was a thing, I tried to make my own AST- reduced inline Python solution using both white- and blacklisting; I abandoned it because it just gave a false sense of security. Not sure if one could do a better job today).
This does raise the classic requesr we've always gotten in Evennia-land: Moo players expect to be able to customize themselves in small ways, make small helpers, customize objects etc. In Moo, that customization can then grow to make the whole game (all is Moocode/softcode whereas Python is, in our case, hardcode). In Evennia, we recommend supporting that user case with custom, player-facing build commands.
How are you handling (or planning to handle) that use case for your engine?
2
u/MalifaxLax 1d ago
Hi, Griatch! Thanks for the reply!
Yeah, the MOO model requires a certain amount of trust, and that's a lot easier in a day where most text games are developed by one or two people. I grew up writing MOO code and love the paradigm: prototypal hierarchy and in-game world editing. I hacked the LambdaMOO source for over a decade, but I'm not a great C coder, and when I discovered Evennia in...2015, my fire for building a game I'd been designing for years was rekindled, and I spent the next 10 years learning the Evennia API and Python, until I couldn't build around class-based hierarchy anymore, and took the advice of some guys on Discord and built a MOO engine instead. I had fallen in love with Python, though, thanks to you, and the rest is history. I couldn't have done it without you and your excellent piece of work, so I owe you a huge THANK YOU.
I type really slow so I built an MCP server into the game server, which has made engine construction a conversation. I know I get dinged for that, but so be it. The designs are all mine. I just don't write all the code. I think it's a pretty good world-building platform if you like the MOO way.
But that's what it is, a world-building platform, not a self-building platform for players. We chose MOO back in the day because it was stable and we liked the idea of building from inside, so we made a character object hierarchy from guest to god and doled out access on different levels to our staff. None of us had actually ever played a MOO, so we wrote our own core and did our own thing.
If people come to my game expecting to be a builder out of the box they're gonna be disappointed. That's not what my game is. Anyone who wants that just hos to `@auth <player> = gm2` and they have a builder, or go gm3 and let them code. That will never happen in my world though. Builders build and players play. But we gill have craft systems where tailors, armorsmiths, etc, can learn stock adjectives and trailers as well as submitting custom descriptors via the submit command for staff approval. Characters come out of character creation with descriptions constructed from menu choices, and then we'll do events where characters sit with GM-played NPC's and customize their appearances. And I've thought about adding verbs that do little appearance tweaks, hairstyle and whatnot, but I'm in the midst of implementing combat and other skills, so apparance verbs are gonna have to wait.
Anyway, I owe you a ton for your incredible generosity, knowledge and patiience, and hope you will accept my gratitude.
-Shan
1
u/Griatch Evennia 16h ago
Glad Evennia was useful to you, it's great that you got inspired to take off on your own direction! 😄
My first foray into Mu* coding was actually trying to pick up an abandoned PyMoo project, and realizing I wanted to use Python outright rather than moocode running on Python.
As long as you are clear with not wanting the full player-coding-facing LambdaMoo experience, bit ask to clearly separate builders from coders, I think there are indeed no security concerns. If you haven't already, I recommend writing a little FAQ specifically addressing this (at l it's indeed the natural first question).
As for AI, use what you are helped by; professional developers use AI to code today, that's a necessity already to keep up. I'd only be wary of using AI to generate player facing text/descriptions (a text game's equivalent to artwork), because that is usually quite noticeable. Doesn't sound like you use AI for that, just pointing it out.
Anyway, good luck again! 🙂
1
u/MalifaxLax 15h ago
Yeah, I don't type fast enough to produce code on a decent timeline, so I write the designs and the content and let Claude write most of the plumbing.
Thanks!
1
u/MalifaxLax 14h ago
I looked at Cold and PyMOO, but neither was documented at all and I couldn't hack it without some help. Which is what makes Evennia so fantastic as a learning platform.
I don't advertise my game as a MOO because as a game it's not. The auth system I use lets me give whatever access I want to whomever I want to, I can definitely separate builders from coders. I think I may move '@auth` from a gm5 verb on the bas char obj to myself.
A FAQ is a great idea..
9
u/AdmiralMcNugget 5d ago
Why live in-game scripting with Python, out of curiosity? Instead of something more traditional for scripting, like Lua? Your own notes say that your Python can't realistically be safely sandboxed. Right now, as written, anyone given builder permissions in your MOO has the capability to import arbitrary modules, open files, access builtins, and effectively do anything the server process can do.
In other words, anyone who runs this is giving the public access to their server. Which may be a fun experiment, but probably isn't what you intended.