Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case for MUDs in modern times (2018)

andrewzigler.com

Post reply on HN
Print view View original

51–60 of 83 posts

Re: The case for MUDs in modern times (2018)

#51

Post by klibertp »

charcircuit wrote: post #4

Can't you have multiple users in a dungeon in non text based games? See WoW and RuneScape. Roguelikes have evolved from being text based long ago, so I don't see why MUDs have to be.

Roguelikes have had 2D UIs since the start (just rendered with characters), while a MUD with a 2D interface is not a MUD but an MMORPG. There's a bit of a middle ground in rich MUD clients that can reorganize the 1D stream of words visually into a dashboard, but that's as far as you can go while still calling it a MUD.

MUDs (and closely related single-user text adventure games) are a well-defined genre; you can improve various aspects of the presentation, add rich formatting, images, background music even, but the moment you stop using text as a main medium for gameplay, you're simply not doing a MUD anymore.

Re: The case for MUDs in modern times (2018)

#52

Post by hackingonempty »

klibertp wrote: post #50
mjevans wrote: post #44

Earlier quoted context omitted.

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 dat…

> 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 unpopu…

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

Re: The case for MUDs in modern times (2018)

#53

Post by charcircuit »

bovermyer wrote: post #11
charcircuit wrote: post #4

Can't you have multiple users in a dungeon in non text based games? See WoW and RuneScape. Roguelikes have evolved from being text based long ago, so I don't see why MUDs have to be.

You seem to be suffering from the misconception that text-only is a _bad_ thing.

There is a difference between thinking a game being text-only is bad and thinking that a genre being text-only is bad.

Re: The case for MUDs in modern times (2018)

#54

Post by klibertp »

hackingonempty wrote: post #52
klibertp wrote: post #50

Earlier quoted context omitted.

> 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 unpopu…

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

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.

Re: The case for MUDs in modern times (2018)

#55

Post by em-bee »

imzadi wrote: post #39

I learned to code on an LP MUD back in the late 90s. It was a fun experience. I did all my work in the MUD interface using ED. I didn't realize other people wrote their code offline and sh'd in to upload it. I got very good at writing and editing code on the command line.

i remember using ED in LPmuds. fun times. i had learned coding already so i can't claim that much, but when it came to web development i discovered the spinner webserver, written in uLPC, a GPL licensed rewrite of LPC (later renamed to roxen and pike). i could not believe my luck to discover a webserver written in a language that i was already familiar with from MUD coding.

nowadays i am using a web-platform for my websites that is not only written in pike but also implements a MUD like architecture.

Re: The case for MUDs in modern times (2018)

#56

Post by jghn »

klibertp wrote: post #51
charcircuit wrote: post #4

Can't you have multiple users in a dungeon in non text based games? See WoW and RuneScape. Roguelikes have evolved from being text based long ago, so I don't see why MUDs have to be.

Roguelikes have had 2D UIs since the start (just rendered with characters), while a MUD with a 2D interface is not a MUD but an MMORPG. There's a bit of a middle ground in rich MUD clients that can reorganize the 1D stream of words visually into a dashboard, but that's as far as you can go while still calling it a MUD. MUDs (and closely related single-user text adventure games) are a well-defined genre; you can impro…

I definitely saw MU* games with graphics schemes in the 90s, although most of the moment to moment activity happened in standard trulytext base "rooms". For instance there were a series of Battletech MU* games that would replicate cockpit HUDs, the hex maps, and related via ASCII art for you while piloting a mech.

Re: The case for MUDs in modern times (2018)

#57

Post by em-bee »

lightedman wrote: post #36

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.

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.

Re: The case for MUDs in modern times (2018)

#58

Post by em-bee »

klibertp wrote: post #50
mjevans wrote: post #44

Earlier quoted context omitted.

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 dat…

> 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 unpopu…

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.

Re: The case for MUDs in modern times (2018)

#59

Post by klibertp »

em-bee wrote: post #58
klibertp wrote: post #50

Earlier quoted context omitted.

> 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 unpopu…

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.

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 :)

Post reply on HN