Presumably the driver also implements a lot of support functionality, like a standard library for the MUD. I don't know how much Pike provides in terms of things like that.

But that would then seem to suggest that the driver is much more than just language support.

I recall someone licencing the IRE engine a while back (they later lost the licence), and they kept insisting that they were writing their mud from scratch - that the engine only came with three simple commands. But the fact was it still provided them with a large amount of built-in mud functionality which strongly influenced the style of game they developed.

I've admittedly little experience with LPMuds, but of those I've seen, they all have the same general look and feel as each other. Is that purely due to the mudlibs drawing code and/or inspiration from each other, or is it also due to the influence of the built-in driver functionality?

Basically I'm trying to work out just how much of a role the driver plays. The fact that drivers and mudlibs tend to be tied together suggests that role may be much larger than I'd originally thought.

I think that's exactly what people have been saying here, though. For example, post #3:


I think that there is confusion (deliberate or not) around the term "from scratch". If you take a graphics engine like OGRE, along with a Java virtual machine, and write a game on top of all that, have you written it "from scratch"? What if you take one of those game engine kits, with built-in support for sound, networking, graphics, blablabla, and write a game on top – is it still "from scratch"?
On some level, you have written all of the game logic, all of the game world, etc., from scratch. That's not to say that you wrote the whole tool chain form scratch, but the game itself was not derived from other games and therefore is built "from scratch".

So, well, sure, if you took a game engine implementing a basic framework, and wrote something completely original on top of it, I think you'd have a decent claim to having made something from scratch, to the same extent that a 3d game could make that claim even if they used toolkits like OGRE3d, OpenAL, etc.

I believe that drivers and libs are tied together simply because each driver implements enough subtle differences that the libs use such that the lib cannot easily be ported to other drivers.

In other words, if you compare to Java, you could think of drivers as the Sun JVM vs. Microsoft's, except that there are even more differences in terms of what the two support. Perhaps it would be more like web browser differences about a decade ago, where you take each browser to be an "HTML driver". It all looks like the same old HTML, but IE was doing stuff that other browsers simply weren't doing.

From what I gathered the FluffOS driver provides telnet handling, so I guess that's one thing a FluffOS Mudlib doesn't need to deal with.

Taking an existing game engine and building your own game on top of it is typically referred to as a 'mod'. Counter-Strike could be considered a total conversion, but it's still not written "from scratch" - it's a Half-Life mod.

Among muds I think the term is fairly commonly accepted as referring to a game which isn't built upon another codebase. If you downloaded a copy of SMAUG and created your own world, configured your own classes, wrote your own help files, etc, I wouldn't consider that "from scratch". If you downloaded a copy of MOO and created your own rooms and internal game mechanics, I still wouldn't consider it to be from scratch. Even building on something like SocketMUD I wouldn't consider to be from scratch, although at that point I think the distinction is mostly symantics.

But what I'm curious about is where the LPMud drivers fall on this scale. The price of DGD and licence restrictions of other drivers, combined with the relative ease of running another language in a sandbox (eg NakedMUD), suggests to me that the drivers obviously have something going for them - otherwise surely we'd see more drivers popping up?

I wasn't referring to a game engine like Quake2, Half-Life or the Unreal Engine. I was referring to a framework in which to make games. Some examples are DarkBasic, SFML (sort of), the XNA framework, the Torque Game Engine, etc. Presumably, making a game on top of Torque isn't "modding" Torque, but working in the framework.

Frankly, though, I don't agree that just because you used, say, the Unreal Engine to develop an entire game, you have merely "modded" (or made a TC) of Unreal. Many things are based on the Unreal Engine, such as Lineage II, Gears of War, and some others I'm forgetting.

Basically the question is at which point a library stops being a library and becomes a framework, and then at which point a framework stops being a framework and starts being a game.

Very few people write anything big from scratch under a strict interpretation. People tend to accept that you can use libraries for various things, such a zlib for compression. I personally don't see a huge conceptual difference between using zlib for compression, and then OpenAL for sound, or even Ogre3d for graphics rendering. Things like the Unreal Engine add in stuff like scripting etc. – it's just implementing a language in which to work. Is this terribly different from a framework that provides sound, graphics and networking in C++, along with embedded Lua to work in the framework?

I think the real problem is that people are placing too much emphasis on the term "from scratch". They should just say what they've done and what they've haven't; typically people are interested in original game play and world content, not the fact that the developers did or didn't use such-and-such library to handle their networking etc.


I think this question is relatively easy. It's hard to write an entire virtual machine for a language, and even harder if you want it to be efficient. Just look at all the threads Silenus has posted about designing a VM for LPC. :wink:

lpmud drivers are more than just a compiler or interpreter for lpc. They provide networking capabilities and hooks (called applies) in specially designated objects which can be used to customize the behavior for things like security (restricting access to files and data depending on the class of user) and so on. It probably would take a good coder doing it full time quite a few months to put together (even with the plethora of libraries out there nowadays). To do it one needs to understand things like building parsers and compilers how to construct a runtime system (usually a byte code VM with support for things like objects) and memory management and networking. Few remaining people in the mud community these days have this particular skill set(perhaps that makes it hard I dont know) and given that there are existing servers out there, there isnt really a need for it unless you are concerned about licensing issues.

Pike though it still retains some mud like features has eschewed much of it's roots and is more like a general purpose scripting language now. Also getting an existing library to run on it(building a library might be even more time consuming than building a driver though more people probably have the proper mix of skills to do this) is quite time consuming as the person in the I3 community Crat is refering to currently hacking away at it can attest to. It really doesn't have the same semantics as most other LPC dialects anymore.

Redesigning the driver trying deliberately not to recycle the existing designs is of course even harder ;-).

I think it'd be accurate to suggest most LP drivers implement a framework in addition to the LPC language. That framework includes networking, file access, security code, and an online compile/editing environment. There's also an inversion of control or dispatching mechanism. CD-Genesis, MudOS, and LDMud drivers are the most like each other, and the demarcation between driver and mudlib is not so clear. That is there is some conceptual game code in these drivers, like commands, room, inventory concepts. DGD has a more strict separation.

If thought about this way I'd come up with an increasing list of "degree of separation" as compared to other mud types:

MercMud to Mobprogs = 99% "game" code in driver - MobProgs an afterthought really

Mush to Mushcode = 60% "game" code in driver - many assumptions about object relationships, commands and flags in hardcode (rooms/exits/things)

LPMud to Mudlib/MOO to moocore = 15-20% "game" code in driver - a roughish guess - the degree of driver/mudlib separation between LP and MOO is real similar though.

DGD to Mudlib/Cold to Coldcore = 5% or less "game" code in driver - very generic

What it means to write something from "scratch" is somewhat ephemeral and POVish.

Should we consider starting from scratch to mean writing a BIOS for our machine first?
Starting at an operating system? (BTW, wasn't Avios a mud that was bootable just like an operating system?)
Starting at a language compiler/VM/libraries?

When you make a meal from scratch, that means you make it from basic ingredients - but it doesn't mean you need to raise and slaughter your own animals, plant and grow your own vegetables, etc. And it certainly doesn't mean you need to forge your own knives, build your own kitchen, and so on.

I would use the idiom the same way for muds. If you make it from scratch, to me that means you make it from the "basic ingredients" - the compiler and libraries. If you download source code that can be compiled and executed, and you've immediately got a mud (no matter how basic) that you can log in to, then IMO you've not started from scratch. It gets fuzzy when you start talking about specialised mud libraries though.

The smallest core lib for the Cold server is 23K of ColdC code, most of it just setup code. And at that point you can log in to what is nothing more than a chat server. No concept of rooms, exits, things, mobiles nothing, just a User object connected to a network socket that has access to a bunch of programming commands.
I wrote a mud in 15 lines of Ruby that had rooms, exits, objects, inventory, online creation, and about a dozen commands. The 18 line version had a primitive combat system.

Which one is really from "scratch"?

I mean in terms of effort, writing a minimal ColdC core takes about as much effort as it was to write SocketMud. Ruby required very little effort. So "scratch" as a measurement of how much work someone did isn't very useful.

I wonder, did anyone ever implement a mud client in LPC?

In a manner of speaking. The codebase I maintain has a telnet command so that
you can connect to another mud while still inside your mud. It's not meant to be
particularly competitive with, say, MUSHclient, it's more a convenience thing.

-Crat
http://lpmuds.net

By this reasoning, downloading the Unreal Engine just without a game attached to it would be "from scratch" – it's basically a giant library – because you can't just connect to it and play. (When does a library stop being a library?)

Also, by this reasoning, somebody who uses a telnet framework that implements client/server has no longer started from scratch, even if they wrote 200,000 lines of code otherwise to implement all kinds of fancy stuff.

Even the kitchen analogy is rather murky. If you use tomato paste instead of making it from tomatoes, are you no longer making it from scratch? What about if you buy pre-prepared pasta or bread, instead of making it from basic ingredients? Perhaps you cannot claim to have made the pasta itself from scratch, but arguably you have still made the meal "from scratch".
That is the point: merely saying "basic ingredients" is not enough. You need to define how basic "basic" is. The basic ingredients in a trivial spaghetti bolognese can be thought to be pasta and tomato sauce on the one hand, or, flour, eggs, tomatoes, etc. on the other.

People coming from different frames of reference and different contexts will have entirely different answers to the question of what is sufficiently "basic". The assembly programmer might sing a rather different tune than the Python programmer when it comes to establishing "basic components".

This is why I think the real question is: why does it matter? The answer to that question will determine the criteria that should be used. Is this a legal question? A bragging rights question? An originality question? Without any context in which to frame the question, it really doesn't mean anything, because depending on how you look at it, the same definition can yield different answers!

Definitely agreed - I've seen Diku derivatives that involved huge amounts of work. But that's really a separate issue.


I readded the part of my quote you omitted, as it answers your question.


It matters for the purposes of codebase categorisation (the subject of this thread). If a mud uses a LPMud driver but writes their own mudlib, do they get categorised as an LPMud?

If Scandum continues expanding his wiki then this issue is going to apply to other codebases as well. Will Cold even have a family tree, if it's as basic as Tyche suggests?

Well, for starters, LPC isn't just "a programming language" it's a rather specialised programming language specifically designed for coding MUDs. MUDs represent some rather unusual challenges from a programming perspective. There have been discussions about this on TMC and on mudlab, I think. 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. The behaviour of an object in a MUD is so dynamic that, in OO terms, an individual instancehas to be able to change the classes that it inherits from on a dynamicbasis. In traditional OO, an object is an instance of only a single class for its whole lifespan; and, while its class may inherit from many others, that list of inherited classes is static. Here, inheritance needs to change dynamically, and be controlled object-by-object rather than class-by-class. There are programming languages that work like this - Self is an obvious example - but they're generally rather rare and obscure. If you're going to learn a new one, then it might as well be LPC.

There are other aspects to programming MUDs which might make LPC an excellent choice of language.

On top of that, as already discussed, there are significant "library" elements to an LP MUD - one might perhaps make an analogy with .NET, in that you get not only the CLR virtual machine, but also the .NET framework classes. The division between what goes in the driver and what goes in the mudlib is not all that well defined - it varies from one driver to another. (In fact, some drivers have the ability to translate LPC code into C so that it can then become part of the compiled driver and gain a performance boost). But the driver will likely, at the very least, contain some functions for handling sockets. It may well also have some built-in mud-object concepts; for example one driver I worked with had a function "environment()" which returned the location of an object (e.g. if the object is in a room it returns the room; if it's in a player's inventory, the function returns the player). In other drivers that might be implemented at the mudlib level, or not at all.

More specialised concepts like races, classes, spells, and a combat system could be found in one of the richer mudlibs (like Nightmare) but not necessarily in one of the more stripped-down ones. Again, the division between what is "game" and what is "mudlib" isn't all that sharp; the lib provides classes that your game objects can inherit from, but the lib classes are customisable (unlike .NET framework classes) and don't necessarily have to be used if you don't want to.

Scandum, are any of your questions answered in the old rec.games.mud.lp FAQ, maybe…?

http://www.faqs.org/faqs/games/mud-faq/l...

I'm not sure how saying it's "fuzzy" is an answer to the question. :wink:

But since you have reframed the discussion only in terms of family trees, then, well, yes, I think that if you use an LPMud driver, then you belong in the family tree, if anything as a derivative member. I think that this is fair because of LP's history of being rather MUD-specific. In other words, you'd most likely only be in this situation (of using a driver but rewriting the entire mudlib) in the first place if you've already been immersed in the culture. I find it hard to believe that a total newcomer to the LP scene would say "hey, let's throw out the entire mudlib and start one from scratch".

It is a funny situation though because it doesn't really apply at all to entire family trees like Dikurivatives.


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

I'd suggest that categorizing based on some concept of "from scratch" just wouldn't make sense with the LP or Tiny family of muds. And by that I mean it wouldn't be useful to anyone involved in LP or Tiny muds. It just so happens that like the LP drivers, some LP mudlibs do have a family history.

Because the question "When does a library stop being a library?" isn't one that's easily answered. But it's one that Scandum may have to tackle as his wiki grows bigger, particularly if he starts including individual muds.


You do realise that this thread is about the LPMud family tree, right?


There are Diku derivatives that claim to be custom, and there are custom muds that were inspired by Diku. Diku doesn't have the driver/mudlib separation of LPMud though - I guess its closest equivalent to a mudlib would be the data files (areas, mobprogs/scripts, help files, config files, etc).

We got down this tangent because you mentioned somebody claiming they wrote an IRE MUD "from scratch", so actually no, it wasn't really clear to me that we were only talking about LPMud family trees. :smile:

Anyhow, I still think it's unclear why exactly the "from scratch" bit matters. 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.
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?

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.