logoalt Hacker News

mjevanstoday at 2:24 PM1 replyview on HN

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.


Replies

klibertptoday at 4:01 PM

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