I was born in 1995. I love reading stories like this about the early days of software. My heart yearns for that time. Wish I was there, but accounts like these are the next best thing.
I'm curious, what about the early days of software or computing appeal to you? And what do you think today's software or tech culture lacks that those days had?
The minimalism of necessity that previous years had can’t be imitated. Of course, one can intentionally limit their art now, but it’s not the same. That minimalism necessitates creativity.
Well the next best thing is actually emulators or just directly trying the software. For example someone has WolfMUD online here http://bbs.kd3.us/htmlterm4000.ssjs telnet://bbs.kd3.us:4001
It would be really interesting to see what's possible taking one of the more advanced/featureful MUD engines and combining them somehow with LLM text generation (especially text-davinci-003 from OpenAI since its so human-like).
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.
I've been playing around with this idea a bit from a world building direction: https://www.youtube.com/watch?v=YUEXo3wrf70 – it generates cities in a top-down way using GPT. From city to neighborhood to buildings with individual rooms and items, though having implemented it I think anything smaller than buildings is the wrong approach.
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 :-/
I experimented with something similar at the conceptual stage. I used XML and a basic GPT2 model. The focus was on NPCs and quest items. Throw away invalid XML and prompt for NPCs to produce or consume quest items. Looking at reworking it, but ultimately it is something which has to be semi-supervised.
You don't actually need to feed the entire core state as part of each prompt. You just need to tell it that X is one of the things that are known, and if it needs to know X to produce output, it should ask by outputting some F(X) - few-shot learning is usually the most reliable. Then you intercept those in the output and replace them with actual values before feeding it back into LLM for the next prediction.
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.
I was playing with chatgpt in running a d&d game. It knew a lot of the rules but also needed to be prompted to follow some rules. Like it could do rolling for hits and damage, spells, hit points, healing. Sometimes is assumed things like you had a key when you didn't. When you asked where it came from it realized it's mistake.
Now I'm wondering if anyone has checked whether chat gpt can actually generate iid random numbers, or if it has the same sorts of bias as a human, or something else entirely.
Year was 1995. I was a 15 year old kid who discovered Diku muds. CircleMUD to be specific. My life revolved around building MUDs and PC gaming. My family bought a Pentium 133, it cost my family a fortune and we were not well off. I got good at C and Linux, went off to work in 1999 after almost not graduating high school. The rest is history. I owe so much to MUDs, which lit my brain on fire and led me to a life I never could have dreamed of. MUDs still exist, you can still build them and they are as much fun now as they ever were. Give it a shot :)
Around the same time, middle school I think, I was in the SF Public library playing MUD on the little terminal they reserved for searching books. We couldn't afford a computer, or internet, at home. The librarians tolerated us.
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.
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.
The LPmud driver is quite some insane piece of work, considering it was done in 1990/91 initially. It is a VM, OOP C dialect featuring lists and hashtables (LPC), has lambda-closures (and things like map() + filter() with that), and allowed reloading of most parts of the game without having to restart the entire MUD for that, a big issue Diku and others suffered from. There were a number of spawn-offs from that like MudOS and there was something called LPC4 which eventually morphed into Pike, the language the Roxen webserver was/is written in. I actually used that on my local machine over Apache, because configuring latter back in the early days was a nightmare while Roxen had a pretty simple and straightforward webinterface for that already.
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.
Indeed. I'm using LP as a shorthand; ours is currently LDmud, but it predates LDmud and changed over from LP before I started playing.
It took a long time, but LDmud finally got 3.5.0 released in 2017 and has been releasing a lot, since. Includes union types, and I think either 3.5 or 3.6 added a python module with the ability to define efuns.
fluffos is also actively carrying the mudos banner.
MUDS have some really unique and interesting programming concepts which you won't find anywhere else. This is particularly true about MOOs and somewhat true about LPs, not so much when Diku derivatives are concerned.
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.
I had a similar story though it sounds like I'm a little younger, so shift the dates up a bit and instead of CircleMud, Vampire Wars then Godwars II. Being a few years in the future, even our modest computer could play Starcraft etc, and yet I still gravitated towards MUDs. I still haven't experienced something like that again, something that felt somehow antique but also light years ahead of any other gaming experience I was having at the time. Sure, no sprites or models, but I could write descriptions for my spells. Combat was engaging and fun and you could get into ridiculous detail. The world felt enormous, I could actually get lost and have to scrutinize inputs and room descriptions to get my bearings. I remember feeling actual relief at one point reading the familiar room description of the fountain outside of town or something.
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.
Pretty much the same story for me, even down to CircleMUD :). I created a widely used MCCP (zlib compression for telnet streams) patch for it and also added lua scripting support. I was better at C programming than most of my university professors after spending countless hours coding MUDs! And it grew my love for programming. Of course many hours wasted playing them too.
I only ever used one MUD but I remember it well, it was hosted on Pipex Dial (UUNET), I think as a personal project of one of the employees. It was called Neverholm. There was rarely anyone else on there, I would spend hours roaming around exploring. Loved it.
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 didn't find the playerbase very hostile at all -- although I wasn't involved in most PVP combat activities, which IIRC is also where most of the "pay to win" is focused.
Man I miss MUDs. Anyone here ever play RockyMUD? I had literally over a year of actual pay time in that one. My accrued hours of play surpassed a year. That is with like a decade of playing though. But still lol
No, but my main on discworld.atuin.net has a couple of years of playtime logged since 2014. Since 2002 it's probably a couple of years more on tens of characters.
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.
This is great, I discovered MUDs around 1995 and even tried to write my own in Perl. The real-time interaction with other characters that we take for granted now seemed revolutionary back then.
Is it possible to play it on-line? I downloaded the sever and it works fine and I can telnet it locally but looks like I can't telnet to wolfmud.org (tried the default port).
I have been playing a MUD sporadically for almost 25 years. It's desolate now which is sad. However, someone occassionaly logs on from years ago and it's great fun.
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.
I love these class of games, especially the MUSHes. It's weird how there's not really an equivalent to 'shared world that's user-scriptable by its players' in the modern gaming ecosystem. Closest would probably be something like Roblox but even that's really just a pale echo of what a lot of these text games would let you do as a player-creator.
43 comments
[ 2.0 ms ] story [ 115 ms ] threadThere 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.
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.
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.
It took a long time, but LDmud finally got 3.5.0 released in 2017 and has been releasing a lot, since. Includes union types, and I think either 3.5 or 3.6 added a python module with the ability to define efuns.
fluffos is also actively carrying the mudos banner.
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.
(never did save up enough to buy wings, though)
I would never have the time for it now that I'm a bit older, but I had a great time and probably played for 6 or 7 years in total.
It's 100% where I learned to code and to coherently structure ideas and arguments.
Quite a lot of PvP, city scale and 1v1. Loved it.
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.
https://mudhalla.net/mudlist/
Especially on Windows you'd be better off using PuTTY or TinTin++ to connect, since Microsoft's telnet is pretty much broken:
https://tintin.mudhalla.net/download.php
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.