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.

▲

em-bee 4 hours ago | parent | next [-]

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.

▲

mjevans 10 hours ago | parent | prev [-]

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 8 hours ago | parent [-]

> 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/1...

▲

em-bee 4 hours ago | parent | next [-]

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 3 hours ago | parent [-]

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 an hour ago \| parent [-]
		reloading objects from a (changed) source at runtime while keeping their identity and updating clones) the functionality is still there, but hidden. roxen can reload modules but the reload creates a new object instance which new http requests will get, whereas old requests keep the old instance until the request completes. however open-sTeam, a collaboration platform developed by a university in germany built a system of proxy objects such that your code always only interacts with the proxy allowing the actual object in the background to be replaced by new instances. in your own code you don't realize you are dealing with a proxy. it's completely transparent. it also stores the object state in a database creating full object persistence. the architecture is very similar to a MUD. they even wrote an object protocol allowing you to access the object from remote, so you can write remote clients that interact with objects with implementations in pike, php and java. the university is no longer working on that platform, but since they released it as GPL i am able to continue using it as a base for all my websites and web-apps. persistence and runtime reloading of objects are my favorite features in any language. i just love to be able to change code at runtime without having to restart the server. it works just like i am used to from my LPmud time.

▲

hackingonempty 6 hours ago | parent | prev [-]

> 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 5 hours ago \| parent [-]
		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.