Tyche
Wizard


Group: Members
Posts: 1,343
Joined: May 23, 2006
|
#91 id:36455 Posted Oct 17, 2009, 6:26 pm
|
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
|
.........................  
For now we see through a glass, darkly; but then face to face: now I know in part; but then shall I know even as also I am known.
Last edited Oct 17, 2009, 7:04 pm by Tyche
|
|
quixadhal
Wizard


Group: Members
Posts: 1,472
Joined: Oct 17, 2007
|
#92 id:36458 Posted Oct 17, 2009, 7:23 pm
|
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.
|
......................... 
|
|
Cratylus
Wizard


Group: Members
Posts: 1,477
Joined: May 22, 2006
|
#93 id:36469 Posted Oct 17, 2009, 11:57 pm
|
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
|
|
|
|
|
Cratylus
Wizard


Group: Members
Posts: 1,477
Joined: May 22, 2006
|
#95 id:36472 Posted Oct 18, 2009, 1:01 am
|
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:
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | 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.
Code (text): 1
2
3
4
5
6
7 |
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
|
|
|
Silenus
Sorcerer

Group: Members
Posts: 253
Joined: Feb 26, 2008
|
#96 id:36478 Posted Oct 18, 2009, 6:40 am
|
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.
|
|
|
Cratylus
Wizard


Group: Members
Posts: 1,477
Joined: May 22, 2006
|
#97 id:36488 Posted Oct 18, 2009, 9:59 am
|
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
|
|
|
|
|
David Haley
Wizard


Group: Members
Posts: 6,874
Joined: Jun 30, 2007
|
#99 id:36502 Posted Oct 18, 2009, 3:01 pm
|
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.
|
|
|