17 Oct, 2009, Silenus wrote in the 81st comment:
Votes: 0
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.
17 Oct, 2009, flumpy wrote in the 82nd comment:
Votes: 0
Ok I'll bite.

The library thing:

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.

[edit for clarity]
17 Oct, 2009, KaVir wrote in the 83rd comment:
Votes: 0
flumpy said:
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).
17 Oct, 2009, Scandum wrote in the 84th comment:
Votes: 0
bbailey said:
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.
17 Oct, 2009, Tyche wrote in the 85th comment:
Votes: 0
Scandum said:
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.
17 Oct, 2009, Tyche wrote in the 86th 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.


Except in this particular case they are not.
17 Oct, 2009, bbailey wrote in the 87th comment:
Votes: 0
Scandum said:
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?
17 Oct, 2009, KaVir wrote in the 88th comment:
Votes: 0
KaVir said:
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?
17 Oct, 2009, bbailey wrote in the 89th comment:
Votes: 0
KaVir said:
KaVir said:
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.
17 Oct, 2009, Scandum wrote in the 90th comment:
Votes: 0
Tyche said:
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.
17 Oct, 2009, Tyche wrote in the 91st comment:
Votes: 0
Scandum said:
Tyche said:
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. ;-)

See Folksonomy
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.
18 Oct, 2009, Cratylus wrote in the 93rd comment:
Votes: 0
Scandum said:
I think I'll split it up as driver, library,


ok…

Scandum said:
and language.


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.

But whatever, your wiki.

-Crat
http://lpmuds.net
18 Oct, 2009, Scandum wrote in the 94th comment:
Votes: 0
It's not a private wiki, and the programming language would be LPC in most cases given I've added a MUD driver field.
18 Oct, 2009, Cratylus wrote in the 95th comment:
Votes: 0
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
http://lpmuds.net
18 Oct, 2009, Silenus wrote in the 96th comment:
Votes: 0
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.
18 Oct, 2009, Cratylus wrote in the 97th comment:
Votes: 0
Silenus said:
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.

-Crat
http://lpmuds.net
18 Oct, 2009, Scandum wrote in the 98th comment:
Votes: 0
The average user will see this for an lpmud entry: http://www.mudpedia.org/wiki/Shadowgate

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.
80.0/99