16 Oct, 2009, Scandum wrote in the 61st comment:
Votes: 0
I prefer to have a global overview of a subject before doing specific research so I can fit things together properly.

Would it make sense to classify MudOS as a programming language, and Nightmare III as a codebase? Or would it be better to make a specific MUD driver and MUD library category?
16 Oct, 2009, David Haley wrote in the 62nd comment:
Votes: 0
Drivers are more akin to virtual machines implementing a language than the languages themselves, AFAIK. You might argue that for your purposes the distinction is or isn't relevant, I'm not sure.
16 Oct, 2009, KaVir wrote in the 63rd comment:
Votes: 0
David Haley said:
Anyhow, I still think it's unclear why exactly the "from scratch" bit matters.

Because there are certain LPMud owners who consider their games "from scratch", and as soon as you put their muds on the LPMud tree they're going to start ranting about how an LPMud tree is no different to a C++ tree or Ruby tree, etc. I think it could save future arguments if some clear definitions were made in advance.

David Haley said:
Either something was inspired/derived from something else or it wasn't. If something uses an LPMud driver, then it uses the LPMud driver and that's that.

That's the definition I would use as well, and I think it helps that the driver and mudlib are clearly separated into different trees.

David Haley said:
It's also still unclear what the purpose of the categorization is. What criteria are we using for derivatives? What if I think the whole LP approach is cool and emulate it, but without using any of the same code – surely that counts for at least some relation in the family tree?

The tree uses dotted lines for "inspired by". DGD is an example of what you describe. Likewise, LPMud itself has dotted lines connecting it to AberMUD and TinyMUD.

David Haley said:
Finally, I'm not sure to what extent it makes sense to detail the history of individual MUDs, except for particularly large and influential ones, or ones that release their code publicly. This can weed out some of the more esoteric or otherwise unclear family origins.

Mudpedia describes itself as "a safe haven for everything MUD related", so I don't see why it couldn't include individual muds as well as codebases. That would be a good way to get other people interested in contributing, and it could be useful to have information on defunct muds.

EDIT: I just noticed that there are already several individual muds listed, although I'm not sure if there are any specific criteria.
16 Oct, 2009, Tyche wrote in the 64th comment:
Votes: 0
KaVir said:
David Haley said:
Anyhow, I still think it's unclear why exactly the "from scratch" bit matters.

Because there are certain LPMud owners who consider their games "from scratch", and as soon as you put their muds on the LPMud tree they're going to start ranting about how an LPMud tree is no different to a C++ tree or Ruby tree, etc. I think it could save future arguments if some clear definitions were made in advance.


If someone wants to self identify as a MURPE or whatever the hell it's currently called, and there is no proof otherwise, then so be it.
Changing the perception of the mud world just to accommodate Aristotle is about as fruitful as accommodating the views of Locke or Vryce.
And I'm not sure which of the latter two is the better analogy. :devil:
16 Oct, 2009, quixadhal wrote in the 65th comment:
Votes: 0
I think the biggest reason Pike has never really seen use for MUD programming, is simply that it doesn't provide a sandbox. You could write a DikuMUD style game in Pike with little effort, as you'd just be using LPC as your language instead of C, however you'd end up with the same kind of static enviornment.

So, I suppose one could say that the LP driver is both the dialect of the LPC language, and the sandbox environment in which LPC programs can run.

A while back, I posted the idea of building a game system that utilized the actual OS for all the services we typically have to replicate in our drivers. The OS already handles sockets, login, authentication, command loading and execution, task scheduling, and memory management. Rather than re-invent these, why not use them?

It's not a trivial task to get it right, but I doubt it would be harder than writing a new driver/mudlib from scratch. The core is a game server that handles the world and everything that happens in it, and a custom shell which connects to it. You *could* use bash and just make sure the game server has write permission to the player's pty, but a custom shell would be able to handle I/O better (no writing while you're paging a document, etc).

On the plus side:
You'd get automatic multi-tasking.
You'd have some level of language independence.
Security would be as good as Linux/BSD/etc… same issues.
REAL support for termcap, meaning full screen editors and whatever else you want.
Sandboxing is automatic. You aren't running IN the server, your commands have to talk TO it.
NPC's could simply be perl programs running just like the player shells do.

On the minus side:
It's a radical change in mindset, and there's nothing out there to borrow from (directly).
There are more security concerns, since players could abuse shell access.
It's not likely you'd be able to use this on a typical game hosting site.

Sorry for the soapboxing… I'm not really trying to hijack the thread, but since I wrote all that I'll leave it as food for thought.
16 Oct, 2009, bbailey wrote in the 66th comment:
Votes: 0
quixadhal said:
A while back, I posted the idea of building a game system that utilized the actual OS for all the services we typically have to replicate in our drivers. The OS already handles sockets, login, authentication, command loading and execution, task scheduling, and memory management. Rather than re-invent these, why not use them?


Isn't this roughly what MUQ did?

Edit: Hrm, maybe not. Seemed like it back when I first found it, though.
16 Oct, 2009, David Haley wrote in the 67th comment:
Votes: 0
KaVir said:
David Haley said:
Anyhow, I still think it's unclear why exactly the "from scratch" bit matters.

Because there are certain LPMud owners who consider their games "from scratch", and as soon as you put their muds on the LPMud tree they're going to start ranting about how an LPMud tree is no different to a C++ tree or Ruby tree, etc. I think it could save future arguments if some clear definitions were made in advance.

For what it's worth, in the interest of clarifying communication, I said the above because I do not think we have made clear – i.e., we have not defined – to what extent being "from scratch" or not affects one's criteria for establishing family trees, and not because I think it makes no difference at all, or was asking what difference it made, or that we shouldn't bother establishing these criteria, etc. It would seem that you and I agree regarding the difference it makes, given your response to my next comment.
16 Oct, 2009, David Haley wrote in the 68th comment:
Votes: 0
bbailey said:
Isn't this roughly what MUQ did?

Hmm…
The MUQ website said:
True contemporary first-class datastructures, including floats

Wowzers! Floats!

I think it's somewhat amusing/interesting/educational to look back in time occasionally (that site was last updated in 1998 apparently) and see how what we now take for granted was claimed as revolutionary.
17 Oct, 2009, Scandum wrote in the 69th comment:
Votes: 0
quixadhal said:
I think the biggest reason Pike has never really seen use for MUD programming, is simply that it doesn't provide a sandbox. You could write a DikuMUD style game in Pike with little effort, as you'd just be using LPC as your language instead of C, however you'd end up with the same kind of static enviornment.

You can update Pike on the fly, though I guess the same holds true for C.
17 Oct, 2009, Cratylus wrote in the 70th comment:
Votes: 0
Scandum said:
quixadhal said:
I think the biggest reason Pike has never really seen use for MUD programming, is simply that it doesn't provide a sandbox. You could write a DikuMUD style game in Pike with little effort, as you'd just be using LPC as your language instead of C, however you'd end up with the same kind of static enviornment.

You can update Pike on the fly, though I guess the same holds true for C.


Quix is correct. The guy I know who has been messing with Pike has had to
modify the interpreter's source and recompile it, to add required functionality.
While it is true you can update a Pike program on the fly, it is less convenient
to update the behavior of Pike on the fly.

-Crat
http://lpmuds.net
17 Oct, 2009, Scandum wrote in the 71st comment:
Votes: 0
What I meant is that it's possible to dynamically link compiled C code.
17 Oct, 2009, shasarak wrote in the 72nd comment:
Votes: 0
Scandum said:
I wonder, did anyone ever implement a mud client in LPC?
That would be a little circular, given that one would require a MUD client to connect to the LP server to use the LPC MUD client. :smile: But you could probably write a web server in LPC if you wanted to.

I did have a colleague at university who wrote a BASIC interpreter in LPC (and this was an early version of LPC, too - LP 2.4.5 mudlib running on an LP 3.1.2 driver). You could enter a particular room in the MUD and enter BASIC code, line by line, then have the room run the programme. (Access to immortals only, naturally!)

So LPC can be used for generic programming. I remember one of the stock areas on that MUD had an NPC that implemented a version of the Eliza conversation simulator….
17 Oct, 2009, shasarak wrote in the 73rd comment:
Votes: 0
David Haley said:
shasarak said:
To summarise, while in many ways the behaviour of MUD "objects" (in the sense of what a player would think of as an object) fits quite well into a traditional OO paradigm, in other ways it doesn't. In particular, the behaviour of objects in MUDs tends to be so fluid that a traditional approach employing classes and instances of those classes is really too inflexible.

Perhaps a different topic for a different thread, but I think that this inflexibility rests on the assumption that you must have a one-to-one mapping of your in-game objects to your code objects, and same for class hierarchy.

You know, David, I'm getting a little tired of your snide insinuations. No: I am neither stupid enough nor inexperienced enough to make such a preposterously elementary error.

DavidHaley said:
(By the way, I'm not sure I can think of an example where an object dynamically changes its entire class tree? Maybe we're coming from different contexts here, though, so we're not quite speaking the same language.)

This thread at mudlab provides some historical context. This one at TMC develops the idea. (My own stance on the question changed somewhat in the time between those threads). There are several other threads at TMC which touch on this (probably a couple more at mudlab too). Do a search for "inheritance" at both sites and see what comes up.
17 Oct, 2009, David Haley wrote in the 74th comment:
Votes: 0
I admit that I'm a little surprised at your reaction, Shasarak. I'm not sure what I insinuated, how I was snide, or how I suggested you were stupid. In fact, the "error" you refer to is hardly preposterously elementary, nor is it really even an error: it is a design choice that has ups and downs, and can be very appropriate in some circumstances and less appropriate in others. In fact, I would say that this is arguably one of the most complex topics in object-oriented design! I'm not sure why you took such offense, but I'm sorry that you did, since absolutely none was intended, directly or via insinuation.

(Now, if you think that that assumption is categorically incorrect and always a stupid, preposterously elementary mistake to make, we can argue about that separately…)

EDIT: also, I thought we were agreeing that the traditional OO approach doesn't always work, because it tends to make the assumption I gave. How did you interpret my statement?
17 Oct, 2009, Chris Bailey wrote in the 75th comment:
Votes: 0
Shasarak said:
Blah blah, I'm a meanie


Can you move a PERSON to the controversial forum? :P
17 Oct, 2009, Dean wrote in the 76th comment:
Votes: 0
Chris Bailey said:
Shasarak said:
Blah blah, I'm a meanie


Can you move a PERSON to the controversial forum? :P


If we could, you'd already be there! :devil:
17 Oct, 2009, Scandum wrote in the 77th comment:
Votes: 0
shasarak said:
Scandum said:
I wonder, did anyone ever implement a mud client in LPC?
That would be a little circular, given that one would require a MUD client to connect to the LP server to use the LPC MUD client.

You'd of course have to modify the LP server to take user input after startup.

Anyways, I still got a couple of unanswered questions:

Can MudOS be considered as a programming language of sorts? And could Nightmare be considered as a codebase?

That would simplify categorization somewhat.
17 Oct, 2009, bbailey wrote in the 78th comment:
Votes: 0
Scandum said:
Anyways, I still got a couple of unanswered questions:

Can MudOS be considered as a programming language of sorts? And could Nightmare be considered as a codebase?

That would simplify categorization somewhat.


No, and yes, respectively.

I really believe this has been answered already in the thread, but I'll reiterate it here:

LPC is a programming language. The various LPC drivers (CD, Lp, Amylaar, DGD, MudOS, FluffOS, LDMUD, others I've likely missed) are an interpreter, VM, and runtime for LPC that are primarily geared towards MUD development. The mudlibs are codebases written in LPC that use the interpreter and runtime to produce a MUD.
17 Oct, 2009, Cratylus wrote in the 79th comment:
Votes: 0
shasarak said:
That would be a little circular, given that one would require a MUD client to connect to the LP server to use the LPC MUD client.


Heh, just-a-client maybe, but a client inside your mud makes sense
for a cupla things. I use my in-mud telnet client to indulge my
laziness, mostly, but it's also the core for a stress-testing
system for loading up test muds with tons of bots.

shasarak said:
But you could probably write a web server in LPC if you wanted to.


Yep, my mud has one of those too ;)

-Crat
http://lpmuds.net
17 Oct, 2009, KaVir wrote in the 80th comment:
Votes: 0
shasarak said:
Scandum said:
I wonder, did anyone ever implement a mud client in LPC?
That would be a little circular, given that one would require a MUD client to connect to the LP server to use the LPC MUD client. :smile: But you could probably write a web server in LPC if you wanted to.

Do you mean so that the mud generates the webpages - and then embed a mud client in one of those webpages (perhaps using Javascript or php)? I've been thinking of doing that myself, I think it's an idea with real potential.
60.0/99