Eventually led to me learning C and running my own ROM MUD. I remember sending some random person $5 or $10 and they hosted my MUD on their server.
I too owe MUD everything.
In early 2001, a junior in a webmastering class I took (I was a sophomore) introduced me to an LPMud, and it's ~recursively changed my life again and again. It was what finally taught me to touch-type in high school. It wasn't where I learned to program, but it was where I really cut my teeth (even though it took 9 years for me to decide to try). It isn't open source, but a related yak-shave did lead me to my first major OSS contribution merged into another project.
I've talked to at least a handful of other people who've worked on our game with similar stories, and at least one who used something he built for the MUD to get his first programming job.
LPmud eventually got developed further and runs under the LDmud label now.
The MUDs based on LPmud/LDmud are quite diverse and are interesting in themselves, if you have access to their core sources. I also remember statically linking MudOS which resulted in a binary of like 500kB back in time, meaning it was possible to use that as a very powerful scripting language in embedded systems.
To give just one example, MOO lets you create and reprogram objects while the game is running. Instead of your normal code-compile-run cycle, you're constantly in game, modifying things one method at a time. As you fix bugs and add features, you can experiment with your shiny new object, or even give it out to friends to play around with.
There's no need to recompile, rebuild, restart, get back into the screen where the bug you're currently fixing was, you just make a change to a verb, try performing it and see if the effects make sense. You can literally go from a bug report to globally fixing your issue in seconds.
In MOO, The distinction between code, which programmers modify and occasionally deploy, and data, which users can modify at runtime, is much more blurry. Everything is an object, including entities like players and rooms, and code is stored in the same database as object instance data. Things are persistent by default, if you edit a method at runtime, that edit is persisted across restarts, just as a simple attribute change would be.
All of this comes with a pretty sophisticated security model, which lets you decide who can see and modify your code and attributes, or even who can call it, and under what permissions. There's also a quota system, with limits on both execution time as well as the number of objects owned. This makes it safe to give out programming rights to untrusted users.
On (some) MOOs, all players have the freedom to make their own rooms and their own objects. You want a clock that chimes every hour? A game of monopoly in your virtual living room? Maybe you want to turn your virtual house into a Harry-Potter-themed world, magical duels and all? You're only limited by your imagination and your coding skills. With modern cores, which give you access to JSON serialization, HTTP requests and other such niceties, you could even build a virtual house where the light switches control real smart lightbulps in your real bedroom.
This way of coding certainly comes with some drawbacks, there's no version control, and usually no testing before you introduce your changes to everybody else. Moving changes between different servers is somewhat difficult, as core game objects reference players and the things they own and quite a bit of code is written and owned by the players themselves, making little sense when other things that those players might have in their inventory don't exist. I also imagine it would be difficult to incorporate modern notions of horizontal scalability, considering that any command you execute can theoretically modify any object anywhere in the world or send text to any other player, and you have no idea what it's actually going to do before you execute the code.
I don't think this paradigm would work well in the modern, corporate and commerce-driven world, but it lets us imagine how programming could have looked like in an alternative world that diverged from ours somewhere in the 80s; it's more like old Smalltalk than like our modern languages.
Oh, and I'm not really one for drama of any sort, but if I have to see drama in a gaming community I really prefer it to be between the programmers that make the game arguing in public chat about ripping off codebases etc.
Now I'm an admin on the game I played back then. Very few players, and I'm a poor C developer so there are terrible bugs, but it's up and running!
Best thing was that you could access it, along with many other things that you probably shouldn't have been able to, from Pipex's freephone sign-up number (0800 056 2110) so it didn't even cost a penny, which was great for 15-year-old me trying not to land my parents with a huge phone bill.
I guess AI Dungeon is attempting something a bit like that. But what I am thinking is keeping the core as the MUD, which will ensure that game state and things stay consistent. Then having the AI generate things based on this core state fed as part of each prompt, to add a bit of variety to descriptions, or allow NPCs to have conversations. But always anchored by the world state tracked by the MUD. Except maybe for some random encounters inserted here and there.
That's the biggest issue with AI Dungeon is that it tends to not quite track whats going on properly from one sentence/paragraph to the next. Although they have improved it recently.
A particularly neat part is generating characters with backstories. Now I'm trying to experiment with giving them some personal perspective and autonomy.
I haven't actually tried to move the data into a running game... I'd like to but I feel like I'm going to put it off indefinitely :-/
The "interface" can vary. For example, you can give it a bunch of SQL DDL definitions with descriptive table and field names and tell it that it can query that database as needed. When it works, it can get really impressive - I've seen it do inner queries and joins, and it routinely uses ORDER BY and LIMIT. But then sometimes it just mixes up fields from different tables even in very simple queries (although if you respond with "ERROR: no such field" etc, it can usually self-correct), and it can sometimes interpret the results in creative ways. The approach where it has to query for stuff one by one in a simple well-defined format is much more reliable.
There are lots of online emulators for old computers https://www.livingcomputers.org/Online-Resources/Online-Emul...
Well the real next best thing is buying and using actual old computers.
(never did save up enough to buy wings, though)
Especially on Windows you'd be better off using PuTTY or TinTin++ to connect, since Microsoft's telnet is pretty much broken:
It's still the game I play the most, and for the hardcore it's easy to run the client in tmux on a VPS and be active constantly, all day, every day, from phone or bigger computer.
MUDs were my first exposure to a C-like language (LPC) and are where I learned to program to a reasonable standard. I still remember a CS major helping me learn recursion when I was still in high school.
Anyway, I loved playing the Dune MUD in 1997-1998 in my first years at university.
