I think that to try to force fit a categorization which has a two tier structure for LPMuds might be a bit problematic since they have fundamentally three tiers (though I do not know of a completed driver written in anything other than C). Admittedly the game code is usually only written in LPC and a potential developer for the most part doesn't have to fiddle in the around in the C language.
It's easy. A library is considered a library when you require it to use as part of something else; to look up the things you need to get your job done.
The MUD OS/ Driver thing:
An OS is just that, an operating system. It "operates" or "drives" the system. Funny that. Whatever it contains (drivers, libs, connection stuff, whatever) it's purpose is to run the mud. It will have hooks that the codebase can use such as an event model. If it requires network libs, or shell implementations, libraries can be referenced to get those things the driver needs (but might no be necessary). And no, an OS is not a programming language. [edit to clarify] An OS may contain a framework for interpreting a programming language, but would not be considered a language in its self.
The code base / mudlib thing:
A code base would be the game code that the OS will run. I'm assuming it contains everything to get the game going; room data, game objects, mob scripts etc etc. This could also be a "library" (something the OS would look at to run the mud).
As for the "From Scratch" thing:
Well, I think there are two things here: OS "from scratch" as coding a driver without any previous mud driver code (but could use existing non-mud libs and it could potentially be written to run existing mud libraries), and MudLib "from scratch" might use an existing driver (possibly modded) but an entirely fresh code base that bears no resemblance to the one shipped with the OS. If one was using snippets or existing mud libs (such as a combat system) as part of a "from scratch" project, it might become murky to say it's from scratch, but if the mudlib is mostly written fresh then I would think its ok.
As an interesting aside, by your (as in, most people here's) categorization of "inspired by", GroovyMud could be considered inspired by Nanvaent (an LP mud) because I used a mental recollection of how it worked to reverse engineer my mudos and codebase. But the code bears absolutely no resemblance to LP in any way.
As an interesting aside, by your (as in, most people here's) categorization of "inspired by", GroovyMud could be considered inspired by Nanvaent (an LP mud) because I used a mental recollection of how it worked to reverse engineer my mudos and codebase. But the code bears absolutely no resemblance to LP in any way.
Yes, I'd agree with that. Likewise, God Wars II drew a lot of inspiration (but no code) from God Wars, which would connect it to the appropriate part of the Diku family tree with a dotted line (at least, if it were a public codebase - adding individual muds to the tree would get excessive).
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.
There's an argument to be made that a language is more than just its definition. So in that regard MudOS and FluffOS would be interpreters for two distinct scripting languages and hence define two different languages. If I recall what Tyche said correctly he indicated that Ruby isn't all that different from an LP driver.
Can MudOS be considered as a programming language of sorts? And could Nightmare be considered as a codebase?
That would simplify categorization somewhat.
Sure, and you could classify Circle as a programming language of sorts and its collective DGscripts/areas as a codebase. It depends on the purpose of the categorization. The nice thing about wikis is you can classify things under multiple categories.
For example "LPMud" or "LP" could mean a family of mud drivers, a family of muds, a particular driver, a particular mud can self-identify as an LPMud, the original LPMud mudlib, the inspiration for a otherwise unrelated server, the source for a family tree of talkers, or the initials of the person who wrote LPMud.
There's an argument to be made that a language is more than just its definition.
The argument can be made, but I just plain don't see it as offering much utility to those who are interested in the categorization of lpmuds. Or, would you also propose categorizing traditional C codebases (Diku, e.g.) by whether or not they are ANSI C vs GNU GCC C? Would you seriously argue that the gnu extensions result in gcc compiling a distinct language and thus it is a distinct language from C? Would that offer any utility in the categorization of the Diku tree?
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.
Uh oh, too late!
bbailey said:
The argument can be made, but I just plain don't see it as offering much utility to those who are interested in the categorization of lpmuds. Or, would you also propose categorizing traditional C codebases (Diku, e.g.) by whether or not they are ANSI C vs GNU GCC C?
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.
Uh oh, too late!
bbailey said:
The argument can be made, but I just plain don't see it as offering much utility to those who are interested in the categorization of lpmuds. Or, would you also propose categorizing traditional C codebases (Diku, e.g.) by whether or not they are ANSI C vs GNU GCC C?
Yeah, way too late.
Scandum said:
If I recall what Tyche said correctly he indicated that Ruby isn't all that different from an LP driver.
The nice thing about wikis is you can classify things under multiple categories.
For example "LPMud" or "LP" could mean a family of mud drivers, a family of muds, a particular driver, a particular mud can self-identify as an LPMud, the original LPMud mudlib, the inspiration for a otherwise unrelated server, the source for a family tree of talkers, or the initials of the person who wrote LPMud.
There can only be one category named LPMud however.
I think I'll split it up as driver, library, and language. The codebase field would be omitted for LPMuds, but I guess technically it doesn't apply to either lib or driver.
The nice thing about wikis is you can classify things under multiple categories.
For example "LPMud" or "LP" could mean a family of mud drivers, a family of muds, a particular driver, a particular mud can self-identify as an LPMud, the original LPMud mudlib, the inspiration for a otherwise unrelated server, the source for a family tree of talkers, or the initials of the person who wrote LPMud.
There can only be one category named LPMud however.
I think I'll split it up as driver, library, and language. The codebase field would be omitted for LPMuds, but I guess technically it doesn't apply to either lib or driver.
There are in fact multiple ontologies in the mud community which is why a heirarchical classification based on a single definition doesn't make sense, or rather only makes sense for a given subsection of mudders. I think we had analogous discussions on MSSP, MediaWiki categories versus Delicio.us tags, class-based versus object-based systems, Plato versus Wittgenstein, etc. ;-)
17 Oct, 2009, quixadhal wrote in the 92nd comment:
Votes: 0
Just as an aside that somewhat relates to what Tyche said…
In the last "big" project I was employed to work on, we (the engineers) fought tooth-and-nail to convince them (the management) that news articles needed to have multiple category tags. IE: This article was about "science", "politics", AND "evil". We lost, and guess where about 40% of our news sources (and about 60% of articles) ended up? The "Miscellaneous" category.
All LP muds share a few things in common. They all use some variation of LPC as the language in which the game systems operate. They all allow code to be added or updated on the fly, although some systems are more flexible than others. Some might require a reboot if you modify a core system, others can handle updating those as well.
Beyond that, they are distinct much like cars are distinct by brand. Two mudlibs which evolved under the same driver will have some things in common, and can swap parts to some degree… but the odds of things working between mudlibs from different drivers gets smaller, the farther away you go.
Huh. Well I don't want to get into a debate of what words mean and stuff, and it's your wiki, so there's that on top. I will mention, though, that insisting on the idea that different drivers' implementations of LPC qualify as separate languages is probably not 100% incorrect, but not a terribly useful way of categorizing, as the separate driver categories already de facto break this out.
Making a further distinction between the driver and its LPC definition seems to imply that someone would be inclined to implement, say, FluffOS LPC function-for-function, feature-for-feature, which is not only unlikely but not the case between versions of FluffOS itself.
Whoa, I just looked at that wiki. no offense Scandum, I seriously do not mean this as an insult, but you are Not Getting It.
Here's the 411.
Categorize by driver. Period.
You're getting distracted by arcane distinctions that don't mean anything to anyone except in some theoretical sense.
Set up categories like this:
LPMud
A) MudOS/FluffOS 1) custom 2) TMI-2 3) Nightmare a) Nightmare 3 b) Nightmare IV c) Nightmare V 4) Dead Souls a) Dead Souls 1/I b) Dead Souls 2/II 5) Discworld a) Discworld b) Final Realms
etc.
B) DGD 1) custom 2) Gurba
etc
and so on.
The way you have it set up now, you've got Nightmare II (!) under a "TMI" category, which is correct in some obscure way, yes, but it's a correctness useful only in a kind of archaelogical sense. In a practical, useful sense, it's weird and just looks wrong, because functionally "TMI" has ceased to represent the name of a family of libs primarily. It now primarily represents a specific member of that family of libs, in general parlance.
You're overthinking it. Just categorize by driver, it's how people think of this stuff.
Crat I think you are right that the tree as it stands now is somewhat problematic- but aren't family trees meant to be archaelogical? The problem at present is there are a mix of items in the tree which are not comparable as a simple ancestry graph/tree. DGD denotes a driver not a mudlib and obviously none of the libraries under DGD are either derived or inspired by DGD.
My understanding though is that NMII was not all original code so I think to imply that it was might be a bit misleading as well.
I still have a problem with the suggestion that Lima somehow falls under the TMI branch. At one point it was a pretty big project and if you compare Lima's internals with TMI It is in fact is quite different(at a very low infrastructure level). I suspect it was created to some extent as counterpoint to TMI-2(and really is a from the ground up effort unlike NM 2.x). I would suggest the following (FWIW)-
1) Create a driver family tree and categorize mublibs as Crat suggested by driver. 2) Rather than just being trees also structure things as a time line. So even if projects are independent efforts some sense is given as to when a project was initiated in the scheme of things.
Obviously no matter what you do the whole setup will be somewhat approximate since there is a certain amount of concept and code sharing between mudlibs. For example certain ideas which originated I believe in Lima did find their way into NM 3.3 and NMIV.
Crat I think you are right that the tree as it stands now is somewhat problematic- but aren't family trees meant to be archaelogical? The problem at present is there are a mix of items in the tree which are not comparable as a simple ancestry graph/tree. DGD denotes a driver not a mudlib and obviously none of the libraries under DGD are either derived or inspired by DGD.
Note I didn't have a problem with his actual tree chart. What I'm talking about is his wiki organization of information. The family tree chart of libs is a place where it makes sense to outline these peculiar relationships. In a wiki, where the structure is meant to facilitate practical information finding, it's weird and confusing. His separate charts of driver and lib relationships made sense. His mixture of that abstruse information into a single mass in his wiki is less clear, and does not seem to me to achieve the objective of being informational to a lay person. You have to understand the relationships in the first place to navigate to the item you want.
I'm currently categorizing both by mudlib and by driver.
18 Oct, 2009, David Haley wrote in the 99th comment:
Votes: 0
Scandum said:
So in that regard MudOS and FluffOS would be interpreters for two distinct scripting languages and hence define two different languages.
Back before the Sun JVM became dominant, MS had their own JVM with slightly different features and functionality, enough so that you couldn't necessarily run a program meant for MS JVM on Sun JVM. Would you say nonetheless that the two VMs aren't implementing Java? Well, yes, technically the languages are different, but also overwhelmingly similar and they certainly belong in the same category for the purposes of establishing lineage. This isn't to say that the differences don't mean anything (categorizing them can be interesting for historical reasons, seeing in which ways MS deviated from the standard) but I'm not sure it matters for the question at hand.