4 ms·

But now comes the real question - will the MUDs be programmed in something sane? The last MUD/MUCK I was on was done in RPN-style code. That was a headache to c

But now comes the real question - will the MUDs be programmed in something sane? The last MUD/MUCK I was on was done in RPN-style code. That was a headache to code various plugins and options.

mjevans 3mo ago
The worst part of that is, at least the only MUD/MUCK engine I ever glanced at the source code for; those primitives were actually still script calls to blocks of C functions. Modern MUDs and similar will just include a mature script language, like LUA and let that directly access the background resources from within some sandbox. No point in re-inventing the wheel with a custom scripting language. For any legacy data (E.G. running some old world on a new system) it'd probably make more sense to write a transpiler / converter anyway.
- klibertp 3mo ago
  > Modern MUDs and similar will just include a mature script language, like LUA Not necessarily. The persistent, live nature of some types of MUD programming (LPMUDs, MOOs) is unique enough that many typical scripting languages are not a good fit. The only general-purpose languages that come close to the required execution model are Common Lisp and Smalltalk (and Prolog, if you squint hard enough), which are so unpopular that you don't really get much out of choosing them over a custom language. That's one of the reasons so many MUDs developed their own execution models and language dialects. Writing a transpiler for a large MOO code or LPC codebase would require generating tons of boilerplate to emulate the unique semantics of the languages, as well as providing a runtime with support for those features. It's not that easy. For some MUDs, scripting with Lua is more than enough. There's a book on writing MUD engines[1], and the second half shows exactly this setup (I think C++ for the engine and Lua for scripting). It will work in many cases, but it'll break down if you try to make the MUD easily programmable by users. It can still be done, but at some point, it might be easier to start from scratch rather than trying to make a stock Lua or Python interpreter work in that environment. [1] https://www.amazon.com/MUD-Game-Programming-Development/dp/1592000908 https://www.amazon.com/MUD-Game-Programming-Development/dp/1...
  - hackingonempty 3mo ago
    > It will work in many cases, but it'll break down if you try to make the MUD easily programmable by users. It can still be done, but at some point, it might be easier to start from scratch rather than trying to make a stock Lua or Python interpreter work in that environment. I am curious as to why not Lua or JavaScript? Lua is what Roblox uses and JS needs no introducton.
    - klibertp 3mo ago
      Almost no languages are built for the environment where all code and values must be live and persistent and accessible to many people at once. Sandboxing and permissions need to be much more granular than what you get in most implementations, and persisting complex state (nothing in-world can disappear or break just because a server is restarted) is hard if that state is not first-class in a language (imagine a half-consumed generator in JS). There's more, but in short: the requirements this environment enforces on the "mudlib" language are unique enough that no mainstream language is a good fit out of the box.
  - em-bee 3mo ago
    The only general-purpose languages that come close to the required execution model are Common Lisp and Smalltalk well, and pike, which itself is based on LPC so it has the required execution model by design. the point is that LPC and pike are the kind of sane language being asked for.
    - klibertp 3mo ago
      I might be wrong - I investigated Pike just once, a long time ago - but I think Pike dropped a lot of the "liveness" that LPC provided (ie. reloading objects from a (changed) source at runtime while keeping their identity and updating clones). It's still probably a good fit for a lot of more advanced MUDs, but it's even more niche than CL and Smalltalk, so again, not much of an advantage over a home-grown solution. Plus, I've been recently looking more closely at MOOs, and for that, even LPC would not be enough (too much of a separation between code and data) - LPC/LPMUDs weren't really built for persistence as much as MOOs were. Still, I can't disagree that, out of the box, LPC and Pike are probably a (much) better fit for a mudlib language compared to Lua, Python, or JavaScript :)
em-bee 3mo ago
you are looking for LPmuds. LPC is a language that looks like C (the C in LPC) and there is even a general purpose language called pike that is a rewrite of LPC. in an LPmud, the engine and the world itself including user contributed part are all written in LPC. unlike other MUDs that have a core written in C and an obscure custom language to define the world inside. this made LPmuds very approachable, and i believe the language and architecture is what enabled LPmuds to have built-in ftp and later webservers too, all written in LPC.
- abathur 3mo ago
  One thing I obliquely enjoyed about cutting my teeth on LPC was occasionally having to write things from scratch where we'd just be reusing well-trod FOSS in other languages. Growth opportunities :)

But now comes the real question - will the MUDs be programmed in something sane? The last MUD/MUCK I was on was done in RPN-style code. That was a headache to code various plugins and options.

mjevans 3mo ago

The worst part of that is, at least the only MUD/MUCK engine I ever glanced at the source code for; those primitives were actually still script calls to blocks of C functions. Modern MUDs and similar will just include a mature script language, like LUA and let that directly access the background resources from within some sandbox. No point in re-inventing the wheel with a custom scripting language. For any legacy data (E.G. running some old world on a new system) it'd probably make more sense to write a transpiler / converter anyway.

klibertp 3mo ago
> Modern MUDs and similar will just include a mature script language, like LUA Not necessarily. The persistent, live nature of some types of MUD programming (LPMUDs, MOOs) is unique enough that many typical scripting languages are not a good fit. The only general-purpose languages that come close to the required execution model are Common Lisp and Smalltalk (and Prolog, if you squint hard enough), which are so unpopular that you don't really get much out of choosing them over a custom language. That's one of the reasons so many MUDs developed their own execution models and language dialects. Writing a transpiler for a large MOO code or LPC codebase would require generating tons of boilerplate to emulate the unique semantics of the languages, as well as providing a runtime with support for those features. It's not that easy. For some MUDs, scripting with Lua is more than enough. There's a book on writing MUD engines[1], and the second half shows exactly this setup (I think C++ for the engine and Lua for scripting). It will work in many cases, but it'll break down if you try to make the MUD easily programmable by users. It can still be done, but at some point, it might be easier to start from scratch rather than trying to make a stock Lua or Python interpreter work in that environment. [1] https://www.amazon.com/MUD-Game-Programming-Development/dp/1592000908 https://www.amazon.com/MUD-Game-Programming-Development/dp/1...
- hackingonempty 3mo ago
  > It will work in many cases, but it'll break down if you try to make the MUD easily programmable by users. It can still be done, but at some point, it might be easier to start from scratch rather than trying to make a stock Lua or Python interpreter work in that environment. I am curious as to why not Lua or JavaScript? Lua is what Roblox uses and JS needs no introducton.
  - klibertp 3mo ago
    Almost no languages are built for the environment where all code and values must be live and persistent and accessible to many people at once. Sandboxing and permissions need to be much more granular than what you get in most implementations, and persisting complex state (nothing in-world can disappear or break just because a server is restarted) is hard if that state is not first-class in a language (imagine a half-consumed generator in JS). There's more, but in short: the requirements this environment enforces on the "mudlib" language are unique enough that no mainstream language is a good fit out of the box.
- em-bee 3mo ago
  The only general-purpose languages that come close to the required execution model are Common Lisp and Smalltalk well, and pike, which itself is based on LPC so it has the required execution model by design. the point is that LPC and pike are the kind of sane language being asked for.
  - klibertp 3mo ago
    I might be wrong - I investigated Pike just once, a long time ago - but I think Pike dropped a lot of the "liveness" that LPC provided (ie. reloading objects from a (changed) source at runtime while keeping their identity and updating clones). It's still probably a good fit for a lot of more advanced MUDs, but it's even more niche than CL and Smalltalk, so again, not much of an advantage over a home-grown solution. Plus, I've been recently looking more closely at MOOs, and for that, even LPC would not be enough (too much of a separation between code and data) - LPC/LPMUDs weren't really built for persistence as much as MOOs were. Still, I can't disagree that, out of the box, LPC and Pike are probably a (much) better fit for a mudlib language compared to Lua, Python, or JavaScript :)

em-bee 3mo ago

you are looking for LPmuds. LPC is a language that looks like C (the C in LPC) and there is even a general purpose language called pike that is a rewrite of LPC. in an LPmud, the engine and the world itself including user contributed part are all written in LPC. unlike other MUDs that have a core written in C and an obscure custom language to define the world inside. this made LPmuds very approachable, and i believe the language and architecture is what enabled LPmuds to have built-in ftp and later webservers too, all written in LPC.

abathur 3mo ago
One thing I obliquely enjoyed about cutting my teeth on LPC was occasionally having to write things from scratch where we'd just be reusing well-trod FOSS in other languages. Growth opportunities :)