Evennia: MUD/MU* creation system
evennia.com
evennia.com
Kudos to the author for keeping it alive and updated.
BTW: There's also this: https://www.amazon.com/MUD-Game-Programming-Development/dp/1... - a pretty good book that taught me how to connect compiled and scripting languages. Now that I think about it, while I did start programming before having access to the Internet (QBasic FTW), it was MUDs that made me really interested in coding. Without them, I don't think I'd be a programmer today.
<!--[if !IE]>
<script>fixScale(document);</script>
<![endif]-->
Same. LPC was ridiculously powerful considering how limited it was, and it was easy to learn things just by reading other source files. Not having to worry about graphics--you just described how things looked, can't get any easier--and making a thing that could walk around and act sort of independently was very satisfying.
I wish there was something similar today. LPC and LPMUDs are still around, but the license is somewhat restrictive, and trying to get people to download and use a MUD client is too steep of a barrier for casual gamers. I get motivated every now and then to do it myself, but it's a lot harder than it seems.
Last time I looked at Evennia it wasn't even in alpha, it just started out (and I was a jealous teenager that wanted to do everything himself, too). Since it was so long ago, I only remember (roughly) the basic ideas and some funny interactions on the mailing list, where the creator tried to convince some would-be contributor that no, you don't need money to start such a project... :)
I do remember LPMUD stuff way better. You're right that, at least in the beginning and on the MUD I played and later coded on, the most common way of writing code was... a clone of `ed`. Really, the line-oriented editor, the one just a step before "magnetic needle and a steady hand". You wrote the code in Notepad, then ran `ed` over telnet, pasted the code and observed it being sent, line by line. You quickly learned what \n is and why it's important thanks to that :) Sometimes you missed a semicolon, so you also naturally learned about `s` and regexes, to ease the pain a little. At some point, though, admins figured out the permissions and it became possible to upload code via FTP. Progress!
As for the architecture, the only "hard"-coded part was the "driver", which was just an interpreter/VM for LPC, plus some code to handle network and disk IO. Everything else was written in LPC. LPC was unique in a bunch of ways: it was gradually typed, it was object-oriented but didn't have classes and used prototypal (and multiple!) inheritance on top of providing #include. Imagine a cross between Ruby and JavaScript coupled with object database/object persistence built-in. Everything was an object, and the system was fully reflective - you could manipulate and change parts of the running system from within. Even the source files on disk were objects within the system - as soon as the file got created, it was already an entity you could manipulate with code (that `ed` clone was written in LPC, too).
It was incredibly powerful and fun way of coding. Version control was a problem, of course - since code was a dynamic, run-time construct, versioning just files wouldn't cut it. It's the same problem Smalltalk images suffer from. It's possible to solve, but you'd have to code the version control system into the driver, and guys capable of hacking on the driver were few and far in between. Once again, simpler triumphed - although modern Smalltalks do offer VCSes comparable in features with mainstream ones.
Much, much later I realized that what made it all possible was a version of "become" method from Smalltalk: a way to replace one object with another completely and invisibly. The lack of this primitive operation was what made all my attempts to fully recreate the environment in Python fail (along with problematic object model in Python 2.x, but that's another story). In the end, some ten years later, I learned both Smalltalk and Self, and realized I could get what I wanted by writing a rudimentary telnet server in Pharo. By then, though, MMORPGs ate most of the mindshare that kept MUDs alive, and I got distracted with other projects. I did a few prototypes while learning strange programming languages, but always stopped at ~2-3k loc and never finished any of them. I used these as tools for learning only, believing there's nobody who'd be interested in this way of playing by programming (or programming by playing.)
> I wish there was something similar today.
TL;DR: I researched ~20 programming languages and environments, and got reasonably close to the LPC experience in two of them: Io and Smalltalk. Io is not very actively maintained (last I checked), but there are mature, stable, and free Smalltalk implementations out there. An added bonus is that you get MUD client along with the environment and you don't need to build Web-based admin interface (most Smalltalks provide a GUI).
I have some code I can share if you're interested; I get the same urge to build this thing from time to time, but never really followed through with any of the attempts. Though, I suspect the story would change a little if even just one other person was interested :)
you may also enjoy looking at pike, which evolved out of LPC, turning it into a general purpose programming language. it kept the ability to replace objects at runtime. which makes it one of my favorite programming languages, next to smalltalk. this ability to implement changes in a live running program is just magic. i find it actually disappointing how rare this feature is. it is pretty much the first thing i ask for any new programming language that someone designs.
In general, programming language features take about 20 to 30 years to go from obscure niche implementation into the mainstream. Look at lambdas - anonymous function literals - they're now everywhere, including Java and C++. Ten years ago, though, only some scripting languages had it. The feature itself is as old as the bones of the Earth (LISP, 1960, 63 years old). The same is true for many other "advanced" features. I think this is tied to generational changes - each generation of programmers has a chance to bring one or two lesser known features into mainstream, and then they're content with that. Other features have to wait for the next generation to discover them.
As for Smalltalk - I made a mistake and based the implementation on GNU Smalltalk, which is unmaintained. I should have gone with Smalltalk/X, Visual Works, or (begrudgingly) Pharo (or Cuis). I started the project as yet another attempt at making a MUD, but then changed focus to making a productive command-line-based programming env for Smalltalk. Then I changed my mind again and tried to make it into a usable shell. Here's the project: https://github.com/piotrklibert/stshell/ The screenshots focus on the REPL/shell side, but in the source you'll see things like "server", "player", and "world". There are a few locations IIRC and you can move your character between them still (plus, it's multiplayer, so another person can connect and you can talk to them!). It was an interesting project, but without a clear vision of what it should be it lost focus and I left it to rot after a while :(
Every time I started making an effort to duplicate the LPMUD experience with whatever, I ended up in some kind of inheritance hell, and this explains that as well.
You've given me quite a lot to think about, and I appreciate it.
(I remember the editing nightmare as well. I had to use computer lab computers, so I did a lot of my work with paper and pencil outside of the lab. That probably did a lot to teach me as well, but even so, the editing part was just awful. The LPMUD I was on got a better editor, something a lot closer to vi, at some point, which made things so much nicer.)
There are workarounds, of course - now that I know what I'm missing, it's perfectly possible to implement it in most anything! Though, why bother, if there are existing systems that already implement it :)
(The other important issue is providing prototypal, dynamic inheritance (like in Self, Io, JS, and ofc LPC). Finally, object persistence - that's something that I didn't consider much until now, but other threads here about MOOs also opened my eyes. Not having to worry about server restarts might be a good thing... I think with these 3 things taken care of you'll get pretty close (maybe even a bit better) to the LPMUD environment.)
AI Dungeon is pretty close. Too freeform for my liking though.
> trying to get people to download and use a MUD client is too steep of a barrier for casual gamers.
This one'll let you connect over telnet, ssh or a provided in-browser client.
there is also open-steam, which is actually more like an object storage, but it has a concept of rooms that can be linked to each other with gates, and user objects can enter rooms and pass through gates to other rooms. they can also send messages into the room which are shared with other users in that room. and users have an intentory, so they can carry things. so it could be possible to build a MUD on top of that without having to do a lot of low level work. the main work would be to design a web interface for that, and fill the rooms with content. i have an instance of that server running. if you are interested, feel free to contact me for details.
Evennia was always this kind of weird alternative though. The web client was “just enough” and, honestly, was one of the first things people would customize and expand upon.
That said, writing multi-threaded socket code isn’t for the faint of heart. Abstractions and libraries exist now - but back then it was a labyrinthine mess of segfaults and kernel dumps. BSD had some of the best tcp socket support and so a lot of muds were built upon BSD.
Does this book still hold up today? It's ~20 years old at this point.
It was also very professionally interesting to me - I'm not sure what the situation is for many of the Hackernews FAANG folks, but most of the corporate offices I've been in only require people to glue together Python libraries badly. There's never any scope for writing anything more complex than that, and many people can barely use Git. I've always done much better than that low standard, but there's a huge gap between trying to be good and learning from someone that's actually good. Evennia is the first codebase where, when doing development in my own time, I found it frequently useful to dig into the library's source code to learn about how something has been implemented.
It really raised the bar in my professional life for what I consider acceptable... and it was also very thought-provoking that a free framework for making MUDs blows up what's being done at most shops around the world. We've got a real problem in industry, but Evennia has always been a little Zen garden for me. So thanks to the developers :)
A really curious thing about muds is more people seem to want to make new ones than play them. There is probably about one unique mud per active mud player these days. Most have no one playing them though.
And the established muds have a hard time finding people to work on them, since they are gnarly legacy codebases based on deeply out of favor programming paradigms. Much more fun to roll your own platform, even if it never gets played.
I wish people would just pick one of the dozen or so active muds and play it. Mud client programming is a great outlet for recreational coding imo. The line between my character and the code I've written to manage it is very fuzzy in a good way.
Plus everyone is always talking about how great lua is. Mud scripting is mostly lua, so it's a great way to find out that lua is just as bad as any other language.
On another tangent, I wish I had known Common Lisp back when I cared about MUD implementation enough to actually pour a few hundred hours into it. Of course you'd face the problem of the extension language, at least in the naïve implementation, being entirely too powerful. Still, it could potentially make it easy to script truly interesting custom object behaviors.
If I were to make a pass at it now, I'd try to structure the game system in such a way that it could power a roguelike or a MUD, since roguelikes have considerably more legs these days.
Not to mention that a graphical MMORPG is one of the most expensive online games you can develop. Whereas a MUD (a text-based MMORPG if you will) can be created by a lone dev or small hobby team (not to say it's simple, no multiplayer game is, but it's at least achievable).
I think it makes a lot of sense that the remaining MUD players are those that have the most complete affinity for the system. While MUDs draw a technical distinction between making and playing, I think psychologically the lines are very blurry, because part of playing is making.
One reason Minecraft really took off is that embedded in the choice to "live" in an expansive virtual world is a desire to affect that world. It mirrors the malleability of our world but on a larger scale. Climbing up an RPG power curve is only a pseudo-satisfier of that desire; you're not actually changing the world, just changing your position in it. Actually being able to modify the world you occupy is the base desire. In that respect, Minecraft is really the spiritual successor to MUDs.
In a popular shard, with a prime-time population of 110 people, there existed 60usd 'cosmetic' item for sale in a very modern cash shop.
Unable to wrap my brain around the concept of a MUD cosmetic item, nor a MUD cash shop, I shop-lifted the item.
I now give this , free, to you fine folks on HN : "prismatic crystal"
Wear it with pride; I quit on this whole modern MUD thing until my brain re-solidifies.
And a cosmetics cash shop isn’t more baffling then fortnight or whatever: you basically just took a screenshot, but that still doesn’t let you walk around with it in game on your character.
No, the real problem is that it takes a strong direction for this sort of system to not devolve into selling power, and making the game shitty and grindy for free to play players to push them towards buying skips, and as far as I know, a lot of those Iron Realms muds have failed this hurdle.
Cash shop? Possible and imaginable. There were always people willing to pay others to level their character, for example. Should it be actually (and officially) implemented, though? I have some doubts here...
The TL;DR is that MUDs are freaking hard to staff for free - offering compensation (even if it's just an occasional 100$ gift card in thanks for a month of work) is a huge boon to the community... but given the size of the player base and the demands on staff actually paying a decent wage is pretty much impossible. In your 100 person MUD example the staff is probably somewhere around a dozen people - lets assume you have a staff ratio of 1:8 - that would mean that to afford 15/hr you'd need players (that tend to be logged on 4 hours a day) to pay two dollars an hour or sixty dollars a month. Employed people can shrug off this cost - but people with a full time job can't play MUDs... so you're looking at getting 60/mo out of college students and retirees and that's pretty impossible.
I know the existing LambdaMOO core and server are still being maintained, and web-ified, but even though I am something of a dissenter from the whole Rust trend, I'm very interested in this, which is going about it IMO the right way:
MOO was a good time.
You can (but don't have to) build a MUD in it -- that's what people did -- but in the TinyM* style not usually RPG type games, more social systems.
But it was sitting on some very cool concepts, especially for its time. Predating the web, kind of another "path" that the Internet could have taken. It took the web 15 years to catch up to the idea of synchronous live interaction, and it's still more ... document based... than the kind of object/thing/room/narrative aspect we had going on in MOO.
It's very clearly inspired by Lisp, Self, and Smalltalk. And LambdaMOO itself was, back then, a hub of some pretty nifty people. 'twas my (embarassing mostly) adolescence. And they handed out "programmer" bits easily, so it was full of people's self-programmed creations.
The implementation certainly didn't age well. But the foundational concept is very cool. There were later iterations on the idea (CoolMUD, then ColdMUD/Genesis, a few other things) that refined things somewhat.
Others have alluded to LPmud/LPC which had some similar-ish things going on, but that was less "persistent shared creation environment" styled and more "source code in files in a decent OO language for making MUDs" with transient objects/state between world resets. People built MUDs, games, in LPmud, but as said MOOs (apart from some exceptions) were less about games and more about what we'd these days might consider a form of social networking.
Both were very cool, but MOO encouraged a more participatory programming environment, since you could just log in and start creating (cloning prototypes) and authoring (writing MOO "verbs" etc).
The best part of 30 years ago I started some research (that I dropped out of) that would have built training environments on top of MOO and similar.
I started out by using the facility to open up a port from MOO and serve a webserver from inside it, that a Java applet integrated with. Which you could do, but something about the way it closed connections interfered with POST requests as I recall.
I loved exploring MediaMOO in particular, and I remember wanting to ask Amy Bruckman a bunch of questions about Moose Crossing; I'm not sure if I ever did. That was fascinating work.
One thing was AstroVR, which was an environment for collaborative control over telescopes. That had an advanced client called Jupiter, which PARC researchers IIRC used to develop a protocol (also called Jupiter?) that supported distributed interfaces and provided correct ordering of event messages.
https://www.semanticscholar.org/paper/High-latency%2C-low-ba...
https://dl.acm.org/doi/fullHtml/10.1145/217279.215128
https://www.adass.org/adass/proceedings/adass94/vanburend1.h...
As far as I am aware, that work pretty heavily influenced SubEthaEdit and Google Wave.
And Pavel Curtis's team eventually ended up providing the backbone of the MS Office live meeting stuff.
Unfortunately, I didn't know English back then, and the only choice I had was between Diku and LP. Well, it's not too late, this thread got me intrigued enough to take a closer look at MOOs (and MOOR), I think :)
What really made it special was that it exposed that programming language to its users, encouraging them to build wild and amazing new objects and interactions in a text-based virtual world. To program MOO, you didn’t need wizard/admin powers, you just needed Programner permissions, which were much easier to come by. Just follow a tutorial to get started (such as yduJ’s ever popular Wind-Up Duck) https://lelandra.com/joan/moocode.htm
The object runtime had some basic permissions around both ownership and types of interactions. They weren’t great, and a determined attacker could usually take the system down if they wanted, but they were enough to prevent most basic (and more importantly, accidental) kinds of mischief.
When you give the users of a social space the tools to build and play and extend the world, amazing things happen. With enough users, six ridiculously imaginative things happen before breakfast. There were games, bulletin boards, puppets, creatures, vehicles, and those are just the basics. I remember an IRC client that appeared as a pair of headphones: don them, you’re in a channel.
The wonder of what I'd seen stuck with me for many years afterwards. I ended up working at Linden Lab, the home of Second Life, because of it. SL, while amazing in many ways, was nowhere near as simple and fun as MOO. If you want (say) a goldfish-powered helicopter to crash into your room and transport you away, Second Life demands hours of modeling, coding, and animation. In MOO, a text-based world, you just type an emote.
The MOO programming environment made it wonderfully easy to glue verbs (i.e. object methods) to existing objects. I didn’t do much with it myself, but I did take a “throw” verb from a snowball, which could be thrown at anyone across the MOO, and attach it to a Creature, resulting in Fluff the Throwable Sheep. Others did far more interesting things; I’ll never forget Tabitha the Living Room, who reacted to things being said and done by the players sitting in her.
In 1993, LambdaMOO showed me what the internet would bring. While the World Wide Web took the concept of a shared, user-programmable social system a billion times further than MOO could ever dream of, I've never seen anything else demonstrate the idea as simply, consistently, and playfully.
And there were rooms that functioned like mass transit -- a monorail I think?
Contributions and opinions and musings are welcome.
How are you apportioning time with multiple threads? How do the ticks work?
At its peak under heavy load on the machines we had back in the 90s, there was some really bad lag as we all waited in turn to f'ck up the world together.
In my system each task (command) gets a separate thread (well, tokio async thread, so not always a physical OS thread), which is its own fully snapshot isolated DB transaction. State is isolated MVCC style (eventually including all I/O) until commit. If the commit is not successful because of conflict the transaction is rolled back and retried , and the user is none-the-wiser.
It's all experimental of course, but I've spent the last ... some time ... working in and studying database tech, so I'm confident I can eventually make it scale. Right now it's just hoisted over RocksDB as a shim but I'm ... building my own thing on the side which will eventually perform/scale much better for the heavily concurrent multiple-writers scenario.
There's still VM opcode based ticks, as in MOO, and limits on them, but that's more of a resource control / time management system to prevent infinite loops and resource abuse and so on.
I really think the world is kind of ready for a LambdaMOO/JHM system again so I will try to come back to play with it and I wish you well in the meantime!
These days, I'm not as huge of fan of the OO model MOO embraced. At least not in its pure form. While I'm implementing LambdaMOO slavishly compatible, it's more just to keep myself disciplined. I hope to go beyond it.
The 'fantasy' system I'd construct would be look more like a shared Prolog system than a shared Smalltalk/Self system. It'd be constructed around relations & first order logic. Relational but not crappy like SQL. You can build LambdaMOO on top of such a system, but not really the other way around. I just haven't mentally figured out what a sensible multiuser permissions model looks like in that scenario.
Have you thought about using Logtalk to implement this? The idea (or the parts I think I understood) is very interesting and out of systems environments I saw I think only Logtalk and Mozart/Oz offer features that could help in implementing it. Looking at your other posts, though, it looks like you're more interested in coding the entire system yourself instead of re-purposing something that already exists. :)
There's also the old classic here: https://www.sciencedirect.com/science/article/pii/S074310669...
Finishing it, and getting other people to use it... that's another story. I've started building probably a half dozen or more systems over the last 25 years. Some have gotten further along than others, but none ever completed. And yeah, I played with Erlang for it at one point :-)
That's why I just threw my hands up in the air and said "F* it! I'll just make it fully LambdaMOO compatible." Because believe it or not there's still people using the LambdaMOO server (and "Stunt" and things like that) and various cores on it. I can hopefully get their interest; but also it gives you a suite of (really weird, aged, and sometimes questionable...) code to test against, and something to compare to for compliance.
The other thing is it makes sense to build such a system in a "systems" PL like Rust or C++, because it is actually a virtual machine, language runtime, database, has a garbage collector, etc. If you end up caring about performance (might not need to, to start), getting closer to the metal makes sense.
Per another comment in this thread, it does seem like everyone wants to create a MUD but no one wants to play them. All the people in the Discord seem to have several years long projects to create "their game", but I didn't hear much about anyone actually playing any of these games.
Plus, people like different aspects of MUDs. Creating it from the inside (like in LPMUDs) with others is fun in its own right, even if no player ever logs in. It's like a slow-paced, continuous hackathon, where everyone tries to make "something interesting" to show to the others.
For example:
Arx is supposedly slowing down in its "old age" (it's been around longer than I've been using Evennia) but the last time I looked, there were over 50 players online.
Silent Heaven launched only a couple months ago, but it's consistently had between 15 and 30 players online every time I've checked. I haven't played it since I'm not into horror, but if it weren't for that I would definitely have tried it out. It's got its own Discord server so I figure all the chatter is over there.
Secrets of Aelandris has only had one playtesting window so far, but several of us in the Evennia community played and are looking forward excitedly to the next one. Playing it comes up every now and then in the Evennia community, but mostly we talk about it on the Aelandris discord.
Song of Avaria, which I also helped playtest, posts regular development showcases, and we've got multiple people in the Discord community looking forward to it launching alpha early next year. People ask about playing it every time a new showcase drops. (One should be going up this weekend, btw!)
The Mystavaria builders and testers are also all over on their own discord, so I have no idea where they're at in terms of activity. They aren't payable yet, but several of us are looking forward to trying that game out as well.
Machine Garden opened up a sandbox pre-alpha a while back (a year or two, i think) which got several players and active discussion on its discord, as well, although it's currently down for major code renovation.
And those are just the ones I'm personally familiar with that have names! (Aside from mine, of course, but it doesn't count yet.)
Most people who look into Evennia are looking to make a game, since that's what Evennia is for, so there's of course a bias in that direction in terms of the community discussion. But there's some games out there, and the ones that are playable definitely get players.
A lot of it is just that there's only so much free time, and those of us that really want to create MUDs wind up putting our time into that instead of playing as we find it more enjoyable and rewarding. In fact, for some it is a hobby in and of itself, ballooning into a passion project that may never see the light of day, like restoring a car you have no intention of ever driving.
People who are active in the "meta" community outside a specific game tend to want to create MUDs. It's like how there are billions of people playing board games, but if you join a board game community you are far more likely to find others who want to create them; it's self-selecting for more interest in the guts of the hobby.
The difference is that people merely somewhat interested in MUDs have dwindled over time, leaving the die-hards behind and a small, small sprinkling of new players just discovering them.
If there was a MUD that got all of the coders wanting to build their own MUD to go "this is incredible, let's just work on this instead, everyone we're moving house" -- I think people willing to do that join teams at extant games instead.
It was incredible though; I was big into books like Redwall, Watership Down, etc. So a social game of animals seemed fun.
The language was MUF; Multi User Forth. Stack based, push, pop, etc.
I helped port software into other MUCKs, like FluffMUCK. The people there were so kind and taught me all sorts of things about Linux, programming, building PCs, etc. I wouldn't be who I am today without the early MUCK communities.
As a teenager it was amazing to telnet into a TinyMUCK and then launch a line-based editor and start coding in it. And not needing to compile the program like C.
Remember that editor?
The line editor experience of building a stack and calling a function, I have not really found again. Lisp REPLs are nice but something about using the stack abstraction as the whole language.
So many amazing memories.
It was summer, 1994. I was 12, we had to move houses and my parents let me buy a 50ft phone cord to connect a modem in my room. My mom was a teacher and found me access to our local university's Internet dialup. Dialup terminal programs to connect into their VMS server. VMS had telnet which was enough to connect to all the MUDs I read about on my local BBS. I think I had just upgraded to 14.4, 28.8 wasn't even out yet.
During the summers, I would stay up all night, lay in bed pretending asleep when my dad had to get up for work in the morning, and then get back up to keep at it.
Entire virtual worlds to explore, basically text MMOs, in 1994. I was in Kentucky, felt like the only person who knew. It changed the course of my life forever, just the magic of it all.
Lots of "anthropomorphic Furry" MUCKs and TrekMUSE.
The best of times.
I remember playing a ferengi cadet at trekmuse 1701 and once stole a starship lol. Also fond memories of battletech mud & mtrek.
I feel like people should be running MUDs on Linode $5/month servers... using xterm.js, websockets, and some back-end.
The back-end I'm playing with is .Net Core, and I'm using async/await to make the code seem more like a normal terminal application.
...and I'm just in love with how LambdaMOO natural language parsing and matching works... But I want to use C#... so I'm implementing verb matching using Method Attributes. And I'm trying to layer that on top of how Inform 6 works... Not using Z-Machine. Or the language of Inform 6... but the declarative style of Inform 6 room and object descriptions really appeals to me.
I get that I'm giving up the flexibility of user-created content in a scripting language...
...but if I still allow players access to the GitHub repository for the content... And make it easy for them to stand up test servers... That feels like a decent compromise?
I'm not even sure I want to make a MOO... or just a server with single-player Infocom-like Interactive Fiction games...?
But this is my hobby project right now.
Anyways, have fun :-) You're playing with the fun toys.
Do you have direct experience with other parsers that you can recommend? I like MOO because it feels very understandable. The documentation was great.
(see the thread elsewhere in the comments)
command parser & matcher stuff is partially here: https://github.com/rdaum/moor/blob/main/moor-lib/src/tasks/c...
and
https://github.com/rdaum/moor/blob/main/moor-lib/src/db/matc...
https://github.com/rdaum/moor/blob/main/moor-lib/src/db/matc...
I guess I’ll build a MUD, then.
I remember trying them all back in the early 90s, spending some time on lpmud instances and Amberyl's pennmush mostly, before writing my own.
More recently I played a hellmoo inspired moo for a couple of years back around 2015 before I just stopped playing for some reason. Maybe I should try it again, it seems to still be running (good mud/moo/mush/mucks never seem to truly die)
The original hellmoo is finally dead! Which fork were you referring to?
In all seriousness, this looks like a fabulous project. Congratulations to those behind it, we needed something like this. I have bad memories of leafing through ancient C code to run a MUD. I've just starred it and will roll it out on a Raspi at home, OSA be damned.
Now I want to retire and work on this :)
Text generation is where most people's minds go but as far as players are concerned UX is more important than a million different room descriptions; you can always write rooms yourself.
so many lost months in mud-dom.
thrilled that more people cared enough to do it as well, though!
likely I'll build one for epic as well.