5 ms·

I gather this happens a lot, relatively speaking. In early 2001, a junior in a webmastering class I took (I was a sophomore) introduced me to an LPMud, and it'

I gather this happens a lot, relatively speaking. 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.

pixelfarmer 4y ago
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.
- abathur 4y ago
  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.
miki123211 4y ago
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.

pixelfarmer 4y ago

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.

abathur 4y ago
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.

miki123211 4y ago

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.