Dean
Sorcerer
Group: Moderators
Posts: 385
Joined: Sep 25, 2008
|
#76 Posted Oct 17, 2009, 6:59 am
|
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! 
|
......................... Dragonball AT
address: 208.43.220.232
port: 1280
|
|
Scandum
Wizard
Group: Members
Posts: 1,105
Joined: Aug 8, 2006
|
#77 Posted Oct 17, 2009, 10:13 am
|
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.
|
|
|
bbailey
Magician
Group: Members
Posts: 91
Joined: Jun 7, 2006
|
#78 Posted Oct 17, 2009, 10:22 am
|
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.
|
......................... Bobby Bailey
Wynn@ Tir na nOg
Chilalin/Chil/Alecksy@ElseMU*
|
|
Cratylus
Wizard
Group: Members
Posts: 1,224
Joined: May 22, 2006
|
#79 Posted Oct 17, 2009, 10:37 am
|
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
|
|
|
KaVir
Wizard
Group: Members
Posts: 1,114
Joined: Jun 19, 2006
|
#80 Posted Oct 17, 2009, 10:50 am
|
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.  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.
|
......................... KaVir at God Wars II: godwars2.org 3000 Roomless world. Manual combat. Endless possibilities.
|
|
Silenus
Conjurer
Group: Members
Posts: 248
Joined: Feb 26, 2008
|
#81 Posted Oct 17, 2009, 12:00 pm
|
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.
|
|
|
flumpy
Sorcerer
Group: Members
Posts: 385
Joined: Mar 27, 2009
|
#82 Posted Oct 17, 2009, 12:33 pm
|
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]
|
Last edited Oct 17, 2009, 1:16 pm by flumpy
|
|
KaVir
Wizard
Group: Members
Posts: 1,114
Joined: Jun 19, 2006
|
#83 Posted Oct 17, 2009, 1:13 pm
|
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).
|
......................... KaVir at God Wars II: godwars2.org 3000 Roomless world. Manual combat. Endless possibilities.
|
|
Scandum
Wizard
Group: Members
Posts: 1,105
Joined: Aug 8, 2006
|
#84 Posted Oct 17, 2009, 4:25 pm
|
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.
|
|
|
Tyche
Wizard
Group: Members
Posts: 1,059
Joined: May 23, 2006
|
#85 Posted Oct 17, 2009, 4:26 pm
|
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.
|
.........................   
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, 4:34 pm by Tyche
|
|
Tyche
Wizard
Group: Members
Posts: 1,059
Joined: May 23, 2006
|
#86 Posted Oct 17, 2009, 4:33 pm
|
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.
|
.........................
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.
|
|
bbailey
Magician
Group: Members
Posts: 91
Joined: Jun 7, 2006
|
#87 Posted Oct 17, 2009, 4:51 pm
|
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?
|
......................... Bobby Bailey
Wynn@ Tir na nOg
Chilalin/Chil/Alecksy@ElseMU*
Last edited Oct 17, 2009, 4:51 pm by bbailey
|
|
KaVir
Wizard
Group: Members
Posts: 1,114
Joined: Jun 19, 2006
|
#88 Posted Oct 17, 2009, 5:03 pm
|
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?
|
......................... KaVir at God Wars II: godwars2.org 3000 Roomless world. Manual combat. Endless possibilities.
|
|
bbailey
Magician
Group: Members
Posts: 91
Joined: Jun 7, 2006
|
#89 Posted Oct 17, 2009, 5:07 pm
|
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.
|
......................... Bobby Bailey
Wynn@ Tir na nOg
Chilalin/Chil/Alecksy@ElseMU*
|
|
Scandum
Wizard
Group: Members
Posts: 1,105
Joined: Aug 8, 2006
|
#90 Posted Oct 17, 2009, 5:43 pm
|
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.
|
|
|
