How nostalgic. It's like 15-20 years old at this point, no? From what I remember, I didn't like the Web-based content creation system back then. I grew up playing and coding LPMUDs - which are basically a text-based Smalltalk environments with vaguely C-like syntax - so the model where objects' features are part of the engine and objects are static data seemed too simplistic. I even tried writing a "real MUD" in Python at the same time Evennia was starting out. Obviously, I quickly realized that Python is not Smalltalk (though I'd only learn about Smalltalk many years later), and that I'm light-years away from being able to hack the interpreter enough to make LPC-like environment. Meanwhile, Evennia got some contributors and the project took off the ground. Evidently, simpler is better :)
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.
>Without them, I don't think I'd be a programmer today.
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.
there is pike, a rewrite of LPC, which is a full gneneral programming language. there have been a few MUDs in the works written in pike, but i don't know if any made it out of the prototyping stage. i think one of them had a web interface too.
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.
(Started replying to Griatch, went on a tangent, it'll fit better here I think. Skip the first paragraph to go straight to LPC advocacy :D)
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 :)
This was a great post. I never really thought that much about why I found LPC so good as a starter language, but the "become" method explains it. I found it so natural--I want this to be this, but different, and wow, there it is, cool.
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.)
i am curious to see what you did with smalltalk there.
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.
It's slowly getting traction - Kotlin on Android has a "live update" feature (in development, only available in alpha release), for example. Multiple less mainstream languages also offer the feature. Nim got it in the last major release, for example. V has it as one of the base features. Erlang and Elixir had it since forever. Common Lisp as well. Racket and Clojure are a little more limited than CL, but also support it. Many interpreted languages offer some degree of this, either by default (JavaScript) or as a library/package (Python, Ruby).
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 :(
Evennia does have a web admin, but main development work is intended to be done in Python code, really; what would be akin to 'hardcode' in LPMUDs, I presume. Evennia's extremely extendable, but not so much over the telnet command line; the choice was made to instead make it easier to develop a game in Evennia using modern dev workflows, using version control and proper code editors. All a matter of taste of course. :)
This fills me with warm fuzzy feelings. MUDs were my jam growing up. So much so that I became a programmer because of it (among others) and like you, have written a few myself. I still maintain old C codebases for modern gcc. Diku, Merc, Smaug, and a few of my own, SWR, exospace.
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.
Evennia is an awesome project, and the community is fantastic. I've been working with a blind friend over the past two years to gradually piece together a MUD (the only kind of game he's really able to play), and while we've been very inconsistent, the community has had infinite patience for fielding our questions.
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 :)
Mudding is such a small niche, the one I've been playing for decades has a few hundred active players still.
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.
> A really curious thing about muds is more people seem to want to make new ones than play them.
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.
Yes, and Minecraft also inspired a generation of new makers to create Minecraft-y games. It's what happens with good genres and the evolution of games.
I think it's fantastic that MUDs inspire people to want to create them. There's something really great about crafts that look approachable enough to not scare people away. Something about text makes people confident that they can do it themselves. So many people are happy to take a shot at writing a book or a screenplay or a text adventure or a MUD that would never try to get into, say, 3D modeling or stained glass. Is it perhaps that everyone has enough intuitive know-how that they can start making something immediately with no study, even if they need just as much practice and study as the other disciplines to make something of quality?
Yes, I think this is very true; following the Evennia discord, there's a lot of newcomers in there - newcomers to game development or even to programming overall, using Evennia/MUDs as a vehicle to learn.
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).
It's kind of the next step up from writing your very own IRC bot.
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.
The roguelike bits are mainly client-side; there are people using Evennia to develop roguelikes (not sure if any are actually released, but it can be done).
Yep. So long as you separate concerns well it’s quite doable. The heavy lifting is deciding how to turn roguelike tiles into MUD rooms, or vice versa. There were some MUDs doing procedural content back in the ‘90s, and others that had a minimap, so there’s plenty of demonstrable overlap.
On the MUD I spent most time on, when the feature of making haircuts (and later tattoos) landed it was a Big Deal. There were very few designs, you had to go to a remote location (through dangerous areas) and pay a lot (in the in-game currency) to get it done. All the effort for literally one short line of text added to the description of your character... It might seem strange, but that's kind of the point of MUDs (for many people).
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...
Funding for MUDs has always been an extremely difficult topic. You've got basically two options - either rely on financially stable retirees with way too much free time or rely on college students with way too much free time. The hosting cost is essentially nothing and setting up a dono button but accepting that you'll probably spend about 1-2 hundred dollars a year of your personal money (as the owner/operator) to maintain the server can cover that cost... but staff is where the real challenge is. MUDs live and die by having a good, fair, engaged staff of RPAs (role-play administrators) or whatever you call them... and those people need to absolutely love the game world because the expectation levied on them is either (with good staffing) 4-6 hours a day or (with thin staffing) 8-12 hours a day of labor to watch player requests, set up events - etc... and while mud player bases skew towards experienced players who appreciate and respect the work an RPA is doing there are always new players that can be abusive and even experienced players have bad days (especially if your game is perma death - then drama will occasionally dial way up). One other thing to keep in mind is that when you accept the mantel of RPA you're losing a lot of your ability to enjoy the game, you have access to privileged information and will either 1) metagame and be a terrible person 2) manage to drive your character in a direction away from plots you're personally managing (only possible with sufficient staffing) or 3) (the most likely) find yourself having difficulty playing because you know the metagame temptation is there and it's hard to compartmentalize information.
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.
Great write up and very very true. The MUD I staff has a running joke (but also not a joke) that the first one of us to win the lottery will just pay everyone to admin it.
I dunno, I have no problem with them using an f2p model to pay for full time ongoing development, moderation for events, etc.
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.
I would much much rather see a reboot of the MOO concepts (persistent object-oriented world, global time).
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:
ToastStunt is an actively developed fork of Stunt which is a fork of LambdaMOO. It's extended a lot of what LambdaMOO offered via patches, as well as adding a lot of new and much needed stuff. Active Discord community as well. And several large MOOs are running it instead of LambdaMOO these days.
It's different than LambdaMOO because it's transactional (or will be). MOO had a global interpreter lock, was single threaded, and each user got a tick based time slice, so there was not really the possibility for state conflict, and there was concurrency but no real parallelism.
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.
Fascinating, thanks for the explanation! Makes me wonder if anyone’s tried building a MOO in Erlang/Elixir or another actor-based system. (Though I’ve probably misunderstood how they’d help with the problem.)
If there's a commonly used (or uncommonly) runtime or language out there, someone has attempted to write a MOO in it. At least I have.
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.
Ooh, all very interesting. I tried a simple experiment about 25 years back with a really, really lightweight green-threads library that I thought might work but I never really understood the synchronisation elements well enough.
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!
Thanks. The core problem with making something like LambdaMOO multi-threaded is that once you introduce real parallelism you just end up with the potential for race conditions and deadlock. So you need some kind of isolation to make it work. And given that MOO is basically a ... database... it makes sense to crib from those notes.
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. :)
LambdaMOO straddled(straddles?) a fine line between being a more "serious" system that looks more like a multiuser Smalltalk & Lisp -- with a persistent shared networked database, a live shared programming / authoring environment with a prototype OO scripting language ... and a "less serious" MUD.
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).
Separate comment for a separate thread maybe: there are also a few interesting things that "fell out" of MOO research.
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.
Now I really regret not encountering MOOs back in the day. It looks like it captures the fun parts even better than the LPMUD I knew. You're right that restarts of the server wiped out some objects (some were persisted, of course, but it wasn't a full-blown object database). You're also right about LP being more game-oriented - though I personally couldn't care less, there were normal players running around killing stuff, leveling, role-playing, and all that.
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 :)
This is a better explanation than I would have managed. MOO's language model was fascinating.
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.
MOOs, like MUSHes, were much more social spaces than games, though some of them had games built on top of them (e.g. LambdaMOO’s RPG). Unlike other systems, MOO was built on a remarkably powerful, multi-user runtime with its own programming language and object database.
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.
One of the things that always tickled me in MediaMOO was the way that you could hook up a computer in your room, then climb in it, navigate through DNS like tunnels, and climb out of someone else's computer.
And there were rooms that functioned like mass transit -- a monorail I think?
Loved the elevator on LambdaMOO. Push the button to go down to 'hell' floor or whatever. Watching my friend work on programming around that kind of stuff taught me the basics of state machines and so on that took me from "played with BASIC & Pascal & Modula-2 as a kid" to "Sure, I'll write your CGI scripts and JavaBeans or whatever" and got me working in the industry eventually...
As someone who has contributed to the Evennia codebase (Hacktober 22), I can say that it's OOP systems are largely well thought out and very flexible. There are hooks for things like when your object gets created/destroyed, picked up/dropped, etc.
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.
There's definitely a bunch of us with long-term projects, but I think that impression that we don't play is mostly because devs split off into their own servers or game communities once their game is playable.
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's entertaining to create a world. It's excruciating, painstaking work to finish it and make it into something others can enjoy.
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.
That's been the rub with all these things since the mid-90s. They're fascinating to build and author in. But it's like a Trotskyist sect or an indie rock band or something: everyone's got one of their own, and nobody wants to join anybody else's. :-)
13 year old me learned to write code on FurryMUCK. No idea at the time what a Furry was, or why strangers in game were trying to "yiff" me.
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.
I thought MUF was magical. Like I was a wizard chanting incantations. It was my first experience with an interpreted language.
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.
Oh wow, this is so great. Thank you for this. I haven't read this in 25+ years.
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.
Haha awesome, I had nearly the same setup in '94-'95, I was in a small rural town for that year but my mom worked for the local college. It was a dialup into a VAX/VMS where the only thing I could do was telnet.
I remember playing a ferengi cadet at trekmuse 1701 and once stole a starship lol. Also fond memories of battletech mud & mtrek.
At the risk of slightly embarrassing the lead dev of Evennia, Griatch, let me say that they are one of the best maintainers of an open source project I've ever seen, guiding the 15+ year old project with skill and grace (and also an amazing artist btw). It's nice to know there are projects like this out there whenever you see the latest open source dumpster fire in the headlines.
Thanks a lot, this is great and very encouraging to hear. :D
That said, Evennia is, of course, a collaborative project, I couldn't do it without the help of the great Evennia community!
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...?
The MOO command parser is pretty meh, TBH, not much there, there (having just recently ported it to Rust, I got to know it a bit...). There were other adventure type systems that had something a bit more involved in terms of (English) natural language parsing.
Anyways, have fun :-) You're playing with the fun toys.
I used to love MUDding (I mostly played _Alter Aeon_). I tried to run my own mud (when I was 11 or so), and I remember learning a lot of C, toolchain stuff, etc, just trying to compile SMAUG.
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)
Fantastic stuff. Now I can integrate an age-verification system so that don't end up in legal hot-water thanks to the Online Safety Act..... /s?
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.
I've just realized that MUDs can become and absurdly incredible experience with the advent of LLMs and diffusion models. You can drawn the most absurd and complex situations. The NPCs can be truly intelligent.
The use of models is fantastic even if only to provide easier ways of handling pre-written text; like taking player input and categorizing it according to sentiment or estimated topic. I'm playing with it in Evennia and dialogue and interactions with the game are somewhat night and day. Just not having to guess for keywords is a wild improvement. However, it's also very slow unless you want to throw money away; running on a cheap droplet using Meta's zero-shot-classification for relatively brief queries... each takes a few seconds.
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.
When I was building them +20 years ago the hardest thing for me was finding people that could build the world. I can see where an LLM would be useful there, too. For a small team it’ll let you scale it up very fast.
I miss building muds. I miss it so much that I've extracted all of the sillymud rooms, objects, and mobiles into json to play with at some future point.
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.