Different MUD engines
snooze
av...@netvision.net.il (Alex Oren) wrote:
>
>Hello.
>
>Specifically, I'd like to know what are the most flexible MUD engines in
>terms of world customization and adding commands without recompiling the
>MUD source.
These days, this is true of most of the MUD engines out there. The big
difference comes in HOW they do it and the level of flexiblity. Things like
NetCI, LP, MOO, coolMUD and coldMUD are probably the most flexible. They tend
to consist of a server and then the mudlib/db runs on top of it and defines
the world rules. The other possibility is something like TinyMUCK or
TinyMUSH. Both have programming languages that can be used to add commands to
the world. (Though these days everyone seems to feel the best way to add
something in is to code it in it seems). I personally see TinyMUCK and
TinyMUSH as being best if you are adding smaller things into the world then
making big broad changes to it. Whereas when you want to do something really
different you go with one of the more programmable worlds. But in the end,
most of it boils down to what you are comfortable with :)
snooze
>
>Thanxalot!
>
>
>Have fun,
>Alex
George Reese
: Hello.
: Can someone tell me the differences between the different MUD engines?
: (I've read the FAQ but there are lot's of systems that are not mentioned
: there)
: Specifically, I'd like to know what are the most flexible MUD engines in
: terms of world customization and adding commands without recompiling the
: MUD source.
With your goals in mind, there is LP and there is nothing else. For
more on LPMuds see http://www.imaginary.com/LPMud/lpmud_faq.html
--
George Reese (bo...@imaginary.com) | "What the world needs now is
http://www.imaginary.com/~borg/ | some true words of wisdom,
phone/fax: (612) 829-5495 | like la la la la la..."
| -Cracker
Alex Oren
Hello.
Can someone tell me the differences between the different MUD engines?
(I've read the FAQ but there are lot's of systems that are not mentioned
there)
Specifically, I'd like to know what are the most flexible MUD engines in
terms of world customization and adding commands without recompiling the
MUD source.
Thanxalot!
Have fun,
Alex
Halcyon
>to consist of a server and then the mudlib/db runs on top of it and defines
>the world rules. The other possibility is something like TinyMUCK or
>TinyMUSH. Both have programming languages that can be used to add commands to
>the world. (Though these days everyone seems to feel the best way to add
>something in is to code it in it seems). I personally see TinyMUCK and
>TinyMUSH as being best if you are adding smaller things into the world then
>making big broad changes to it. Whereas when you want to do something really
>different you go with one of the more programmable worlds. But in the end,
>most of it boils down to what you are comfortable with :)
>
>snooze
I've read a few posts by this person and all I can conclude is that
he/she is just INCREDIBLY incompetent or a total idiot. I have to requote
this one line in particular->
>the world. (Though these days everyone seems to feel the best way to add
>something in is to code it in it seems). I personally see TinyMUCK and
Gee??? Code it in? Laugh. Yeah, the best way to add something to the
game is to program it in. Any other way is ridiculously silly and lazy.
>making big broad changes to it. Whereas when you want to do something really
>different you go with one of the more programmable worlds.
Really different? Yeah, if you want to actually BE CREATIVE and have a game
that is different that a couple hundred other clones, maybe you should
use an engine that is designed to allow flexibility. Apparently, this
person's definition of "really different" includes just about anything that
differs from default by anything more than a text description.
-Halcyon
Holly Sommer
>
>(I've read the FAQ but there are lot's of systems that are not mentioned
>there)
The FAQ for which newsgroup? I got this post from rec.games.mud.diku, but
there are numerous other newsgroups to which you crossposted.
>Specifically, I'd like to know what are the most flexible MUD engines in
>terms of world customization and adding commands without recompiling the
>MUD source.
There are two schools of world building, basically. Online and offline.
The online goes under the auspice of OLC. The most flexible OLC I have
used (in about a year and a half of building) is the one which is part of
NiMUD v1.5 (a diku-family-tree server).
As for adding commands, any time you change the source code for a server,
you will HAVE to recompile it in order to implement the change. That's
the nature of programming/coding. I can't speak for the folks in Lp-land,
but all diku-based MUDs are written in C. There's one in development
called MUD++ written in C++, but you still have to recompile for any
changes to code.
Good luck with getting answers to your questions.
-Holly J. Sommer
--
Right here, right now: there is no other place I wanna be som...@main.com
Right here, right now: watching the world wake up from history 1.713.376.6311
George Reese
: In article <4e33vr$7...@news.nu.edu>, sno...@nunic.nu.edu (snooze) wrote:
: >snooze
: I've read a few posts by this person and all I can conclude is that
: he/she is just INCREDIBLY incompetent or a total idiot. I have to requote
: this one line in particular->
: >the world. (Though these days everyone seems to feel the best way to add
: >something in is to code it in it seems). I personally see TinyMUCK and
: Gee??? Code it in? Laugh. Yeah, the best way to add something to the
: game is to program it in. Any other way is ridiculously silly and lazy.
What an ignorant statement.
First, programming is a waste of time.
Anything which can help you avoid programming is a good thing.
Second Snooze is hardly incompetant nor a total idiot in my
experience. His flaw in this thread is simply that his LPMud
experience dates back to 1991.
: >making big broad changes to it. Whereas when you want to do something really
: >different you go with one of the more programmable worlds.
: Really different? Yeah, if you want to actually BE CREATIVE and have a game
: that is different that a couple hundred other clones, maybe you should
: use an engine that is designed to allow flexibility. Apparently, this
: person's definition of "really different" includes just about anything that
: differs from default by anything more than a text description.
A well designed set of objects in LPC can allow you to put together
unique worlds iwith virtually no programming n a much more evocative
and creative fashion than any other server type. A good GUI front end
on top of that can completely eliminate the need for programming.
So though you may be right in arguing against his conclusions, you
see, your reasoning is wrong.
KRSNA CONSCIOUSNESS NOW
>
> Gee??? Code it in? Laugh. Yeah, the best way to add something to the
>game is to program it in. Any other way is ridiculously silly and lazy.
>
>>different you go with one of the more programmable worlds.
>
I am curious about something - do all of these servers execute the user-written
programs in interpretation? That would seem to be a major performance loss. I
think I read something once about mudOs compiling its objects...?
I'm working on a prototype of a compile-and-dynamically-load-style MUD right
now, so any pointers to extant implementations would be vastly appreciated.
James
James R Cantrell
: I am curious about something - do all of these servers execute the user-written
: programs in interpretation? That would seem to be a major performance loss. I
: think I read something once about mudOs compiling its objects...?
I am fairly certain that MudOS always interprets it's code. If it has any
compilation, then it's from compressing the given text into a smaller,
more efficient form. I'm not quite sure how you would get a program to
recompile itself dynamically without having to partly shut itself down,
but I'm sure it is possible (at least in non-protected mode, which most
UNIXs don't run under). If you find a good book that suggestes how it
might be done, I'd be very interested in looking at it and buying it,
because otherwise I think interpreters are probably the only way to
easily change things dynamically without restarting the program.
Joshua Cantrell
s...@crl.com
j...@cory.berkeley.edu
Caliban Tiresias Darklock
> I've read a few posts by this person and all I can conclude is that
>he/she is just INCREDIBLY incompetent or a total idiot.
It is my considered opinion that the author of the posts to which you refer
does not state things quite as clearly as you would prefer. But that doesn't
make him incompetent or an idiot.
You have made some statements here that indicate a total lack of
understanding. When he said 'code it in' he meant hard-code. As opposed to
extending the MU* via the internal programming language.
Furthermore, softcode is far more flexible than you give it credit for. I
would suggest you spend a couple months writing softcode in a MU* environment
before you start calling people idiots... and besides, I don't see you
offering any help to anyone.
I think he deserves a little slack, and a little credit, for even trying to
help someone - even if he's totally wrong, and doesn't have any idea what he's
talking about. But obviously, he does have some idea what he's talking
about... more so than the person he's helping, anyway.
Now shut up until you can say something nice for a change.
Caliban Tiresias Darklock the Hellespontine DiSCORD : Hail Eris
, ___
,----. | /' ) Master of the darkness, I fear nothing but the sun,
--+----' ;/' /^\/' ) I am the only one; the devil's only son;
`.______,/' /'`\___/ I am the dark centurion.
Paul Brinkley
>George Reese (bo...@winternet.com) wrote:
>
>> First, programming is a waste of time.
>> Anything which can help you avoid programming is a good thing.
>
Not necessarily. Sloth has been said to be one of a hacker's best
virtues. Programming should perhaps not be avoided in general;
what you want to do is program in such a way that it saves you
work later. And, if code has been written before, why write it
again, if it was written well?
>> A well designed set of objects in LPC can allow you to put together
>> unique worlds iwith virtually no programming n a much more evocative
>> and creative fashion than any other server type. A good GUI front end
>> on top of that can completely eliminate the need for programming.
>
>*pat* I'm sure _you_ believe that. Personally, I'd rank it dead last
>in both categories -- moving items in the right order may have been
>state of the art back when Zork was a hot item, but I think you'll
>find CRPG's have moved a bit beyond that now.
A set of LPC objects that enables uniqueness without programming is
indeed a tall order, but I must say I don't know what you're talking
about in this last paragraph. What are you ranking dead last, and
in what two categories??
Paul Brinkley
brin...@cs.utexas.edu
Ian A. McCloghrie
>I am curious about something - do all of these servers execute the user-written
>programs in interpretation? That would seem to be a major performance loss. I
>think I read something once about mudOs compiling its objects...?
My understanding is that most extensible muds compile the source code
into some intermediate p-code, which they then interpret. They
usually do not compile into native assembly code for the machine
architecture on which the mud server is running.
>I'm working on a prototype of a compile-and-dynamically-load-style MUD right
>now, so any pointers to extant implementations would be vastly appreciated.
Compile-and-dynamically-load is an interesting idea, but there are a
*lot* of major security issues involved in it. Just something to
think about :)
--
Ian McCloghrie <*> work: ia...@qualcomm.com home: i...@egbt.org
____ GCS 3.0 d- s+:+ a-- C++++$ UL++++ P+ L+++ E+ W- N+ K
\bi/ w--- O- M-- V-- PS++ PE+ Y+ PGP+ t+ 5+++ !X R tv- b+++
\/ DI++++ D--- G+ e++ h- r y+**
The above represents my personal opinions and not necessarily those
of my employer, Qualcomm Inc.
Pei-Te Yu
: > First, programming is a waste of time.
: > Anything which can help you avoid programming is a good thing.
: Spoken like a truly incompetent programmer...
: > A well designed set of objects in LPC can allow you to put together
: > unique worlds iwith virtually no programming n a much more evocative
: > and creative fashion than any other server type. A good GUI front end
: > on top of that can completely eliminate the need for programming.
: *pat* I'm sure _you_ believe that. Personally, I'd rank it dead last
: in both categories -- moving items in the right order may have been
: state of the art back when Zork was a hot item, but I think you'll
: find CRPG's have moved a bit beyond that now.
Hmmm.. actually, George does have a point on saying that the less
programming need be done, the better it is... not that it's good to have
every single thing look the same, with nothing different but the text
descriptions.. however, _every_ object of a certain type does have
similar characteristics.. and those characteristics are best done if one
doesn't have to code them, and can just set them by typing in the
description. Only things that need be coded, then, is the
characteristics which are different. Saves a lot of unecessary and
repetitive develepment time, no? =)
Of course, the idea that GUIs eliminates the need for programming is
false.. GUIs tends to make programming more complicated.. just look at
all the graphical OSes out today.. or try programming a graphical game. =)
KRSNA CONSCIOUSNESS NOW
>more efficient form. I'm not quite sure how you would get a program to
>recompile itself dynamically without having to partly shut itself down,
>but I'm sure it is possible (at least in non-protected mode, which most
>UNIXs don't run under). If you find a good book that suggestes how it
>might be done, I'd be very interested in looking at it and buying it,
>because otherwise I think interpreters are probably the only way to
>easily change things dynamically without restarting the program.
>
Well, the way I'm trying to do it uses dynamic loading; the current scheme
involves a module manager which is responsible for startup and loading all
modules (as well as providing a nice library of module-management facilities
for general use); these loaded modules take care of creating the database and
doing all the interesting MUD things. Since it's all dynamically loaded, you
can load stuff as you need it, unload it when it's no longer useful,
modify/recompile individual modules and load them in (to alter its routines),
etc.
I have determined that you can seamlessly replace implementations dynamically.
For instance, suppose I have a module M1 which defines an implementation of a
function F, and a module U which calls F; suppose there's another module M2
which defines a different implementation of F. So it looks something like
M1.cc--------------
void popper (void)
{
cout << "popper" << endl;
}
M2.cc-------------
void popper (void)
{
cout << "different popper" << endl;
}
U.cc-------------
extern void popper (void);
class Uinitializer
{
public:
Uinitializer () { popper (); }
~Uinitializer () { popper (); }
} myUinitializer;
main.cc-----------
#include <dlfcn.h>
int main (void)
{
void *handleM = dlopen ("./M1.so", RTLD_LAZY | RTLD_GLOBAL);
void *handleU = dlopen ("./U.so", RTLD_LAZY);
dlclose (handleM);
handleM = dlopen ("./M2.so", RTLD_LAZY | RTLD_GLOBAL);
dlclose (handleU);
dlclose (handleM);
}
when I run this, the output is
popper
different popper
i.e. you can arbitrarily alter the actual code which a function executes;
another thing illustrated by this example is that a loaded module's global
constructors are called when it's loaded, and its destructors when it's
unloaded, which is convenient in terms of my above scheme (the database modules
can set up their own states, without anything more than a dlopen on the part of
the loader).
I've determined that dynamically altering the definition of objects is a Bad
Thing; functions that were compiled under the assumption that class X had Y
fields had better not be passed an instance of X with Z fields! There might be
ways around this; Irix has some sort of protocol for this sort of thing, but
I'm working under Linux.
Anyways, this is an idea of what Could Be Done with a MUD; these modules would
of course be native code and run many times faster than interpreted code (tho I
think a tokenized interpreter like Perl or MudOs (?) would do pretty well).
James Wilson
>
>Joshua Cantrell
>s...@crl.com
>j...@cory.berkeley.edu
>
Travis S Casey
>: programs in interpretation? That would seem to be a major performance loss. I
>: think I read something once about mudOs compiling its objects...?
>
>compilation, then it's from compressing the given text into a smaller,
>recompile itself dynamically without having to partly shut itself down,
>but I'm sure it is possible (at least in non-protected mode, which most
>UNIXs don't run under). If you find a good book that suggestes how it
>might be done, I'd be very interested in looking at it and buying it,
>because otherwise I think interpreters are probably the only way to
>easily change things dynamically without restarting the program.
Recent versions of MudOS allow for LPC->C conversion; that is, you
can write your code in LPC, then call an efun which will convert it
into C and write the results to a file. This file can then be
compiled in with the driver.
It's usually not as efficient as hand-coded C code, but it does
provide a huge speed boost to the functions in question.
Looking at the MudOS web page
(http://www.imaginary.com/LPMud/LPC/MudOS/)
yesterday, I came across this when reading the docs for
the generate_source() efun:
If one file is given, the C source for that file is compiled, and
the driver attempts to link it into the running executable using
the RUNTIME_LOADING option.
This sounds as if the driver is modified while the game is still
up. Perhaps Beek can clarify?
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ System Manager, FSU CS department
|,4- ) )-,_..;\ ( `'-' (904) 644-4290; Room 101C Carothers
'---''(_/--' `-'\_) No one agrees with me. Not even me.
rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html
Russell Taylor
> First, programming is a waste of time.
> Anything which can help you avoid programming is a good thing.
Spoken like a truly incompetent programmer...
> A well designed set of objects in LPC can allow you to put together
> unique worlds iwith virtually no programming n a much more evocative
> and creative fashion than any other server type. A good GUI front end
> on top of that can completely eliminate the need for programming.
*pat* I'm sure _you_ believe that. Personally, I'd rank it dead last
in both categories -- moving items in the right order may have been
state of the art back when Zork was a hot item, but I think you'll
find CRPG's have moved a bit beyond that now.
--
Russ Taylor
<A HREF="http://www.pacinfo.com/~rtaylor/">PacInfo</A>
Systems Administrator and Consultant, PacInfo
"Hell is a big cookie and no milk"
Tim Hollebeek
: Recent versions of MudOS allow for LPC->C conversion; that is, you
: can write your code in LPC, then call an efun which will convert it
: into C and write the results to a file. This file can then be
: compiled in with the driver.
: It's usually not as efficient as hand-coded C code, but it does
: provide a huge speed boost to the functions in question.
: Looking at the MudOS web page
: (http://www.imaginary.com/LPMud/LPC/MudOS/)
: yesterday, I came across this when reading the docs for
: the generate_source() efun:
: If one file is given, the C source for that file is compiled, and
: the driver attempts to link it into the running executable using
: the RUNTIME_LOADING option.
: This sounds as if the driver is modified while the game is still
: up. Perhaps Beek can clarify?
Yes, that's right. The only downside is that the loading is currently
synchronous instead of asynchronous, which means a good minute or so
pause for the compilation. It wouldn't be that hard to modify it to
be async, but nobody has been hounding me to get that done, while they
have been on my back to get other things done, so it hasn't gotten
done :-)
--
Tim Hollebeek | Everything above is a true statement, for sufficiently
PChem Grad Student | false values of true.
Princeton Univ. | t...@wfn-shop.princeton.edu
-------------------| http://wfn-shop.princeton.edu/~tim
Tim Hollebeek
>KRSNA CONSCIOUSNESS NOW (jwi...@center.colgate.edu) wrote:
>
>: I am curious about something - do all of these servers execute the user-written
>: programs in interpretation? That would seem to be a major performance loss. I
>: think I read something once about mudOs compiling its objects...?
>
> I am fairly certain that MudOS always interprets it's code. If it has any
>compilation, then it's from compressing the given text into a smaller,
>more efficient form.
I'm fairly certain MudOS _never_ interprets it's code. Given that I
maintain it, I have to assume I'm correct, and you're making up facts
about subjects of which you are ignorant and posting bullshit.
Please desist.
MudOS compiles to bytecode by default, like all LP servers have for
nearly a decade now. It can also produce C code which can be
dynamically loaded or linked with the driver.
>I'm not quite sure how you would get a program to
>recompile itself dynamically without having to partly shut itself down,
>but I'm sure it is possible (at least in non-protected mode, which most
>UNIXs don't run under).
It's called dynamic linking/loading, and is possible on most operating
systems with shared libraries. Check out the man pages for dlopen()
and/or nlist() to get the basic flavor of how this can be done,
although unfortunately it isn't very standardized across different systems.
-Beek
Tim Hollebeek
: George Reese (bo...@winternet.com) wrote:
: > First, programming is a waste of time.
: > Anything which can help you avoid programming is a good thing.
: Spoken like a truly incompetent programmer...
No, actually, only masochists want to spend more time programming in
order to accomplish the same task. One of the reasons compentent
programmers think reusable code is a Good Thing is because it
_reduces_ the need to program.
Wanting to program is a sign of valuing the process more than the
results. Not that that's a bad thing, but it certainly reduces your
productivity. The worst symptom of this is the large number of people
who feel compelled to write things from scratch (and end up doing
things more or less exactly the same way), instead of building
on available tools.
: > A well designed set of objects in LPC can allow you to put together
: > unique worlds iwith virtually no programming n a much more evocative
: > and creative fashion than any other server type. A good GUI front end
: > on top of that can completely eliminate the need for programming.
: *pat* I'm sure _you_ believe that. Personally, I'd rank it dead last
: in both categories -- moving items in the right order may have been
: state of the art back when Zork was a hot item, but I think you'll
: find CRPG's have moved a bit beyond that now.
Eh? What are you babbling about? What two categories? What does any
of this have to do with moving items and Zork? (which, by the way,
is still far more advanced than many muds ... how many muds have you
been on which know of relations other than 'in'?)
What is your point, anyway, other than you don't think much of his
programming skills (have you actually bothered to look at anything
he's written?) and feel like contradicting him without offering
any contrary evidence?
Tim Hollebeek
: I've determined that dynamically altering the definition of objects is a Bad
: Thing; functions that were compiled under the assumption that class X had Y
: fields had better not be passed an instance of X with Z fields! There might be
: ways around this; Irix has some sort of protocol for this sort of thing, but
: I'm working under Linux.
Yes, this is going to be a problem especially since you are using C++,
which relies heavily on static information. You can't really solve
this without using some common OO object format, but those tend to
still be a bit nonstandard and state of the art. (Heck, dlopen()
isn't even widely available yet, although it's getting there. non-ELF
Linux systems don't have it, for example). Another more serious
concern with native code is the ability to access native system calls;
some of them (system, for e.g.) can be quite nasty. This means you
have to restrict the number of people who can 'program' as opposed to
simply using and configuring existing code pretty small.
Actually, though, as far as portable object formats go, probably the
most interesting new one is targetting the Java VM ... most of the
portability and security worries are handled automatically for you.
It's also probably a bit young to do any serious work with, though.
KRSNA CONSCIOUSNESS NOW
>>I'm working on a prototype of a compile-and-dynamically-load-style MUD right
>>now, so any pointers to extant implementations would be vastly appreciated.
>
>Compile-and-dynamically-load is an interesting idea, but there are a
>*lot* of major security issues involved in it. Just something to
>think about :)
How do you mean? I suppose if one lets an anonymous login extend the executable
they could eat the world (or whatever part of it the mud has access to), but it
seems this could be prevented by only allowing trusted users to program
directly (in C++ in my case), and giving generic users some safe alternative (a
scripting language that produces C++ objects?) if you want everyone to be able
to program.
>
>--
>Ian McCloghrie <*> work: ia...@qualcomm.com home: i...@egbt.org
> ____ GCS 3.0 d- s+:+ a-- C++++$ UL++++ P+ L+++ E+ W- N+ K
> \bi/ w--- O- M-- V-- PS++ PE+ Y+ PGP+ t+ 5+++ !X R tv- b+++
> \/ DI++++ D--- G+ e++ h- r y+**
>
>The above represents my personal opinions and not necessarily those
>of my employer, Qualcomm Inc.
James
Gregory Fullsome
bo...@winternet.com (George Reese) wrote:
>So though you may be right in arguing against his conclusions, you
>see, your reasoning is wrong.
Not nearly as poor as yours however. I'd go through it piece by
piece, but from reading this group, all I ever see you do is engage
in flame war after flame war, in which you find ONE tiny little thing
that is correct and cling to it. You'd probably do the same thing here,
thus its pointless. I hope Halcyon decides on the same method in regards
to you.
Gregory Fullsome
>Russell Taylor (rta...@pacinfo.com) wrote:
>What is your point, anyway, other than you don't think much of his
>programming skills (have you actually bothered to look at anything
>he's written?) and feel like contradicting him without offering
>any contrary evidence?
>
Good lord Beek. Are you and Descartes the same person or do you two
just enjoy patting each other on the back and kissing up to each other.
Gregory Fullsome
>What is your point, anyway, other than you don't think much of his
>programming skills (have you actually bothered to look at anything
>he's written?) and feel like contradicting him without offering
>any contrary evidence?
Of course. you must be the same person! You both exhibit that
same "build on someone elses code, then call it all mine" attitude. Wheeeee
Travis S Casey
>In article <4ee0db$s...@cnn.Princeton.EDU>, tim@franck (Tim Hollebeek) wrote:
>>What is your point, anyway, other than you don't think much of his
>>programming skills (have you actually bothered to look at anything
>>he's written?) and feel like contradicting him without offering
>>any contrary evidence?
>
>just enjoy patting each other on the back and kissing up to each other.
Do you just have no idea who Beek and Descartes are, or are you
just having fun flaming?
While I've had my own arguments with Descartes (anyone remember
the discussion on linking muds?), I have to agree with Beek that
anyone who would imply that Descartes is a poor programmer has
never looked at any of his code. Since it appears that you
don't know, Descartes is one of the founders of Nightmare, and
one of the primary (if not *the* primary) coder of the Nightmare
and Foundation mudlibs. He also maintains the FAQ for
rec.games.mud.lp.
Beek is now the primary developer of MudOS and one of the
main developers of the Lima mudlib; if I remember right, he
also had a large hand in developing the TMI-2 mudlib.
If Beek and Descartes are the same person, then that person must
either (a) have more spare time than anyone I've ever met, or
(b) be an incredibly fast coder. :-)
As for them "patting each other on the back and kissing up
to each other", they both have accomplishments in the Mud
world which are worthy of respect; even if I don't always
agree with them, I still respect their coding abilities,
and the work that they've done for the mud community.
George Reese
: Russell Taylor <rta...@pacinfo.com> wrote:
: >George Reese (bo...@winternet.com) wrote:
: >
: >> First, programming is a waste of time.
: >> Anything which can help you avoid programming is a good thing.
: >
: >Spoken like a truly incompetent programmer...
: Not necessarily. Sloth has been said to be one of a hacker's best
: virtues. Programming should perhaps not be avoided in general;
: what you want to do is program in such a way that it saves you
: work later. And, if code has been written before, why write it
: again, if it was written well?
: >> A well designed set of objects in LPC can allow you to put together
: >> unique worlds iwith virtually no programming n a much more evocative
: >> and creative fashion than any other server type. A good GUI front end
: >> on top of that can completely eliminate the need for programming.
: >
: >*pat* I'm sure _you_ believe that. Personally, I'd rank it dead last
: >in both categories -- moving items in the right order may have been
: >state of the art back when Zork was a hot item, but I think you'll
: >find CRPG's have moved a bit beyond that now.
: A set of LPC objects that enables uniqueness without programming is
: indeed a tall order, but I must say I don't know what you're talking
: about in this last paragraph. What are you ranking dead last, and
: in what two categories??
One thing you need to learn to do if you are going to post to the mud
newsgroups is learn how to completely ignore Russ' posts. He never
knows what the hell he is talking about, and he talks about it in the
only the rudest and most insulting terms he can think of.
George Reese
: In article <4e8a02$i...@blackice.winternet.com>,
: bo...@winternet.com (George Reese) wrote:
Nit picking? Halcyon called Snooze an idiot for no reason
whatsoever. And you back up Halcyon with unwarranted personal attacks
on me? I guess you made your point!
KRSNA CONSCIOUSNESS NOW
>Actually, though, as far as portable object formats go, probably the
>most interesting new one is targetting the Java VM ... most of the
>portability and security worries are handled automatically for you.
>It's also probably a bit young to do any serious work with, though.
I've been following this a little bit out of the corner of my eye (there is at
least one group I know about working on a java mud)... my impression has been
(correct me if I'm wrong) that Java's fairly slow and sort of over-hyped.
>
>--
>Tim Hollebeek | Everything above is a true statement, for sufficiently
>PChem Grad Student | false values of true.
>Princeton Univ. | t...@wfn-shop.princeton.edu
>-------------------| http://wfn-shop.princeton.edu/~tim
James
Tim Hollebeek
: In article <4ee0db$s...@cnn.Princeton.EDU>, tim@franck (Tim Hollebeek) wrote:
: >What is your point, anyway, other than you don't think much of his
: >programming skills (have you actually bothered to look at anything
: >he's written?) and feel like contradicting him without offering
: >any contrary evidence?
: Of course. you must be the same person! You both exhibit that
: same "build on someone elses code, then call it all mine" attitude. Wheeeee
Please cite a case where I have done so, or shut up. Unfounded
accusations are extremely rude. What have I ever done to you, anyway?
Why do you feel compeled to follow up to the same 4 lines with 2 lines
of abuse in two separate posts?
Tim Hollebeek
: f I remember right, he
: also had a large hand in developing the TMI-2 mudlib.
This is actually untrue; I was very active as an admin of the mud
itself and helping people there, but development of the lib had
ceased at that point. There is some of my code in the current TMI
lib (the dbx commands, for example), but that's mostly things that I
donated to Leto.
Tim Hollebeek
: In article <4ee0db$s...@cnn.Princeton.EDU>, tim@franck (Tim Hollebeek) wrote:
: >What is your point, anyway, other than you don't think much of his
: >programming skills (have you actually bothered to look at anything
: >he's written?) and feel like contradicting him without offering
: >any contrary evidence?
: >
: Good lord Beek. Are you and Descartes the same person or do you two
: just enjoy patting each other on the back and kissing up to each other.
I think about four other people agreed that Russ was dead wrong about
the necessity for programming, and several other people commented that his
other (Zork) paragraph made no sense. However, you choose to single
me out for abuse.
If you must know, I just happen to talk to Descartes fairly often,
since we share some common projects. Because of that, I happen to
know him a bit better than those of you who just enjoy using him as
a target for abuse. I certainly feel I should have the right to
defend him when he is flamed despite being correct without being
accused of being partisan. Grow up. The fact that is was Descartes
that Russ was flaming wasn't particularly relevant; I flamed him
because he was rather brutally wrong. Of course, I doubt Russ would
have been quite so rude to a different target, so it might be relevant
in that sense. Who knows.
Go reread that paragraph you quoted again. There are no wild claims.
There are no false statements. There aren't even any personal
attacks. (Well, ok, except for the implication he is talking about
things he doesn't know about, but I stand by that accusation)
The rest of the article which you snipped suggested Russ was wrong,
and offered reasons to back up that claim.
Descartes' biggest flaw is that he has a habit of arguing with idiots
(Brandon, Aedil), and doing so tends to cause people to loose sight of
who the idiot is.
Tim Hollebeek
: >Actually, though, as far as portable object formats go, probably the
: >most interesting new one is targetting the Java VM ... most of the
: >portability and security worries are handled automatically for you.
: >It's also probably a bit young to do any serious work with, though.
: I've been following this a little bit out of the corner of my eye (there is at
: least one group I know about working on a java mud)... my impression has been
: (correct me if I'm wrong) that Java's fairly slow and sort of over-hyped.
I'll give you overhyped. However, after reading the VM specification,
I was rather encouraged. The Java language itself is rather
unimpressive. It adds few useful things which aren't already common
in various other languages. Here is why I think the Java VM is an
important advance, though:
(1) The bytecode interpreter will be widely distributed. No MUD
developer can hope to achieve as wide distribution.
(2) The bytecode is fairly simple to convert to native code, since
it is pretty low level (btw, this is one of the reasons Java is slow;
interpreting such low level opcodes is very slow). Given the demand
for Java and the number of large companies throwing their weight
behind it, I think it's very likely we will see Java VM -> native code
translators within a year or so.
(3) The bytecode is _very_ language neutral, making it easy to target
it with other languages (though the lack of multiple inheritance
is worrisome)
(4) As stated above, the portable object format and security
guarantees are _ideal_ for mud applications
My impressions from the Java mud mailing list (which I no longer
read), though, was that it was mostly people doing it for the sake of
making a mud in Java, not for any sane reason :-)
James R Cantrell
: In article <4e9qsa$2...@crl12.crl.com>, James R Cantrell <s...@crl.com> wrote:
: >
: > I am fairly certain that MudOS always interprets it's code. If it has any
: >compilation, then it's from compressing the given text into a smaller,
: >more efficient form.
: I'm fairly certain MudOS _never_ interprets it's code. Given that I
: maintain it, I have to assume I'm correct, and you're making up facts
: about subjects of which you are ignorant and posting bullshit.
: Please desist.
Tim, you came on fairly strong with the comment I made. Albeit I
probably don't know much about MudOS source code, but I spoke from my
ignorance and observation with working with MudOS as a Wizard. When I
create an object, I type 'update <object>' and it seems to load it into
memory and interpret the commands.
Time Hollebeek (t...@franck.Princeton.EDU) also wrote:
: Gregory Fullsome (gful...@stormbringer.net) wrote:
: > In article <4ee0db$s...@cnn.Princeton.EDU>, tim@franck (Tim Hollebeek)
wrote:
: > >What is your point, anyway, other than you don't think much of his
: > >programming skills (have you actually bothered to look at anything
: > >he's written?) and feel like contradicting him without offering
: > >any contrary evidence?
: > Of course. you must be the same person! You both exhibit that
: > same "build on someone elses code, then call it all mine" attitude.
Wheeeee
: Please cite a case where I have done so, or shut up. Unfounded
: accusations are extremely rude. What have I ever done to you, anyway?
: Why do you feel compeled to follow up to the same 4 lines with 2 lines
: of abuse in two separate posts?
I don't like your attitude either Tim. You seem to take offense
quite easily. Just as you told Gregory, "What have I ever done to you,
anyway?" I feel the same toward you because I didn't mean to harm
MudOS's reputation my spreading incorrect information (I never said I was
"certain"), yet you treated me as though I was an enemy.
Joshua Cantrell
s...@crl.com
j...@cory.berkeley.edu
Tim Hollebeek
: Tim Hollebeek (t...@franck.Princeton.EDU) wrote:
: : In article <4e9qsa$2...@crl12.crl.com>, James R Cantrell <s...@crl.com> wrote:
: : >
: : > I am fairly certain that MudOS always interprets it's code. If it has any
: : >compilation, then it's from compressing the given text into a smaller,
: : >more efficient form.
: : I'm fairly certain MudOS _never_ interprets it's code. Given that I
: : maintain it, I have to assume I'm correct, and you're making up facts
: : about subjects of which you are ignorant and posting bullshit.
: : Please desist.
: Tim, you came on fairly strong with the comment I made. Albeit I
: probably don't know much about MudOS source code, but I spoke from my
Sorry about that; you ran directly into about 3 of my pet peeves. It
really annoys me when people are 'relatively certain' of things about
which they are quite ignorant. I probably would be much more tolerant
of this, except that the error you made is extremely common, and
perpetuating the myth isn't helpful, especially when stated with
such authority. It's like posting "I'm relatively certain that i=i++
is valid, since i is incremented after it is assigned" to comp.lang.c.
No matter how good the intentions, such common myths do a considerable
amount of damage, especially when you don't make it clear that have
no evidence that you are right.
The truth is that the vast majority of MUD users are quite ignorant
about such subjects; that actually makes such statements more
dangerous. Who are such people to believe, since they obviously can't
evaluate the claims for themselves?
: ignorance and observation with working with MudOS as a Wizard. When I
: create an object, I type 'update <object>' and it seems to load it into
: memory and interpret the commands.
Yes, but from context, it is obvious you mean direct interpretation of
the text. You are 'fairly certain it _never_' [emphasis yours] does
anything else. That is simply false, and you have absolutely no
evidence to support that. I'm sorry if I could have done a better
job of pointing that out.
Re: taking offense quite easily, here is some excerpts from a recent
email by me to the I3 mailing list; hopefully it will shed some light
on why people who support public domain packages tend to be a bit
touchy.
--------------------------
> It seems the attitude with
> the current popular libs and drivers is this: We made it, so we will be as
> big of assholes as we want.. True, you [the creators] have this option.. But I
> (being an average nice guy) am growing sick and tired of the holier-than-thou
> atitudes displayed by a choice few..
I think if you actually talk to the people in question, you'll
find out that most of the people you are refering to are 'average nice guys'
as well. Actually, I know they are, because I know most of them :-)
Anyway, here are a couple of small points from the other side
that might help you get a bit more insight into what is going on:
(1) days and months is an underestimate. These things are the result of
years of work.
(2) We are heavily outnumbered. There are 100s of people using these
drivers/mudlibs. Spending about 5 minutes of my time every time
someone wants to talk to me literally adds up to an hour or two a
day. That's a significant fraction of my life.
...
(4) About ~20% or more of the people are unappreciative, rude, or downright
jerks. Given the shear number of people that adds up to, and the fact
that the nice people tend to be alot less vocal, meaning that the only
people you ever see are the jerks, this gets on your nerves very fast
and can cause you to snap at people who appear to be jerks, but really
aren't.
(5) Personally, I never wanted to be the maintainer of MudOS :-) I just
wanted to make the driver better, and as long as I was doing so thought
it would be good if other people benefited as well. The fact that some
people think I am obligated to help them (seek 4,3,2) does get to me
quite often, though. Not that I'm not willing to help people; I just
resent those who take my time for granted.
--------------------------
Russell Taylor
[re: another person's comments on sloth]
"Sloth" is the virtue that's led to LP muds requiring 8-32 megs (and more)
to run a fairly small world. Why rewrite code? To do it better, faster,
in less memory, and/or more flexibly, perhaps?
> One thing you need to learn to do if you are going to post to the mud
> newsgroups is learn how to completely ignore Russ' posts. He never
> knows what the hell he is talking about, and he talks about it in the
> only the rudest and most insulting terms he can think of.
Gosh, you're good at following your own advice.
As for not knowing what I'm talking about, keep in mind the ROM code base
is one of the most succesfuly Diku variants, with over 1400 downloads
since the last release last October. It's recieved high praise from
the users for being exceptionally stable, expandable, and detailed,
without significantly increasing the resource requirements of the game
You see, some programmers actually care about being able to run code with
limited CPU and RAM resources.
FWIW, lots of code is reused in ROM, but I have no fear of rewriting major
potions of the game driver to get increased performance and stability.
I'm also curious, oh trek addict, why you rail against the Diku tendency
to declare object properties in code, then reuse them, but then proclaim
that the ideal LP would involve no coding to make new objects?
With a hearty "fuck you" to the "programming revolution" that cuts performance
in half, doubles disk consumption, and quadruples RAM consumption in most
"modern" software packages, this is Alander signing off.
Russell Taylor
> Wanting to program is a sign of valuing the process more than the
> results. Not that that's a bad thing, but it certainly reduces your
> productivity. The worst symptom of this is the large number of people
> who feel compelled to write things from scratch (and end up doing
> things more or less exactly the same way), instead of building
> on available tools.
...except that current trends in using tools and resable code and libraries
have bloated code to the point that what once could be done in 64k now
requires in excess of 16 megs to run gracefully.
The "state of the art" in programming is far less efficient owing to the
the attitudes of the johnny-come-latelies who fear programing so much that
they'd rather triple the resource requirements of a program than do it right.
(lest you think LpC doesn't have this problem, take a look at Batmud some
time)
> Eh? What are you babbling about? What two categories? What does any
> of this have to do with moving items and Zork? (which, by the way,
> is still far more advanced than many muds ... how many muds have you
> been on which know of relations other than 'in'?)
"evocative" and "creative", just like he said. And I was referring to
the Lp quest, which is effectively a less advanced version of the Zork
tradition of moving object A to location B to do somethjing.
BTW, Zork doesn't really handle anything more sophisticated than "in",
since "on" is really the same thing.
> What is your point, anyway, other than you don't think much of his
> programming skills (have you actually bothered to look at anything
> he's written?) and feel like contradicting him without offering
> any contrary evidence?
My point is, any programmer who tries to avoid all programming should
think about getting into something harmless like marketing instead.
And just because you're too dim to parse a setence doesn't mean I didn't
offer contrary evidence.
Taro S. Ogawa
> As for not knowing what I'm talking about, keep in mind the ROM code base
> is one of the most succesfuly Diku variants, with over 1400 downloads
> since the last release last October. It's recieved high praise from
How many were used to launch Yet Another Merc Clone? How many were used
to produce something truly good? How many are still up? Are IBM PC Compatibles
the best computer? Is Windoze 3.1 the best GUI?
> the users for being exceptionally stable, expandable, and detailed,
> without significantly increasing the resource requirements of the game
than Rom2?
> You see, some programmers actually care about being able to run code with
> limited CPU and RAM resources.
by so much. "LPs: You don't need a Cray anymore". 'Sides, last time I
looked, we were using about .5% cpu on a 486. And if you're really worried
about RAM, there's always DGD (But I feel the onset of deja vu here..)
> FWIW, lots of code is reused in ROM, but I have no fear of rewriting major
> potions of the game driver to get increased performance and stability.
> I'm also curious, oh trek addict, why you rail against the Diku tendency
slothful ex-trek-addict who never got round to changing his email, or else a
trek-non-addict-who-just-liked-the-construct-"Blah of Borg", or even, ghod
forbhid, he is a trek addict. There are many worse things to be - Russell.
> that the ideal LP would involve no coding to make new objects?
rhetoric, please. Given that NMIV is, I believe, basically written from
scratch, perhaps at this point in its development, he's tired of recoding
everything, hence his "ideal" LP. Then again, my current "ideal" LP
involves almost every object being basically unique (inheriting standard
properties, of course, but having significantly new and interesting
properties and behaviour on top of that)....
> With a hearty "fuck you" to the "programming revolution" that cuts performance
> in half, doubles disk consumption, and quadruples RAM consumption in most
> "modern" software packages, this is Alander signing off.
#include <my standard disclaimer>
--OH.
--
"He's down on our list," said Clovis; "after all, we've got men we can trust to
do our job, so we shan't have to rely on local assistance. And we've got some
Boy Scouts helping us as auxiliaries." "Boy Scouts!" "Yes; when they understood
there was real killing to be done they were even keener than the men" (Saki)
--
"He's down on our list," said Clovis; "after all, we've got men we can trust to
do our job, so we shan't have to rely on local assistance. And we've got some
Boy Scouts helping us as auxiliaries." "Boy Scouts!" "Yes; when they understoo
there was real killing to be done they were even keener than the men" (Saki)
Taro S. Ogawa
Petri Virkkula
Russell> The "state of the art" in programming is far less efficient
Russell> owing to the the attitudes of the johnny-come-latelies who
Russell> fear programing so much that they'd rather triple the
Russell> resource requirements of a program than do it right.
Russell> (lest you think LpC doesn't have this problem, take a look at
Russell> Batmud some time)
If Batmud has huge memory requirements, it doesn't mean that
LPC is bad language. Batmud just happens to be big, and it
contains lots of bad code. Most parts of it have been
rewritten many times and always the new code has supported old
code (which means lots of wrappers and kludges.
For example, I believe (haven't checked lately) that there is
still areas that has been made when there weren't inheritance
(made with ONE_EXIT(), TWO_EXIT() etc. macros) and they have
same functionality as the newer rooms.
Petri
--
Petri Virkkula - PGP public key available
George Reese
: > One thing you need to learn to do if you are going to post to the mud
: > newsgroups is learn how to completely ignore Russ' posts. He never
: > knows what the hell he is talking about, and he talks about it in the
: > only the rudest and most insulting terms he can think of.
: Gosh, you're good at following your own advice.
You are the one who entered into this thread (in which I was
defending a non-LP person against some wrong comments by an LP person)
by saying I was an incompetant programmer. You have not even seen
what I have coded.
: As for not knowing what I'm talking about, keep in mind the ROM code base
: is one of the most succesfuly Diku variants, with over 1400 downloads
: since the last release last October. It's recieved high praise from
: the users for being exceptionally stable, expandable, and detailed,
: without significantly increasing the resource requirements of the game
I don't know anything about it, so I will not comment on it. Let's
assume you are rightm and ROM is wonderful and does all you say it
does. That does not make LPMuds good or bad.
: You see, some programmers actually care about being able to run code with
: limited CPU and RAM resources.
Please show any post where I suggested I don't care about that.
: FWIW, lots of code is reused in ROM, but I have no fear of rewriting major
: potions of the game driver to get increased performance and stability.
I am sure everyone on USENET is applauding now.
: I'm also curious, oh trek addict, why you rail against the Diku tendency
: to declare object properties in code, then reuse them, but then proclaim
: that the ideal LP would involve no coding to make new objects?
To end builders, it makes no difference. To people maintaining the
system, it makes a world of difference. Flexible object systems are
infinitely easier to maintain and modify. Modification menaing
something more than declaring object properties.
: With a hearty "fuck you" to the "programming revolution" that cuts performance
: in half, doubles disk consumption, and quadruples RAM consumption in most
: "modern" software packages, this is Alander signing off.
Your need to attribute beliefs to me I do not have, and then express
them in hyperbole underlines the overall weakness in your entire mode
of thinking.
George Reese
: Tim Hollebeek (tim@franck) wrote:
: > Wanting to program is a sign of valuing the process more than the
: > results. Not that that's a bad thing, but it certainly reduces your
: > productivity. The worst symptom of this is the large number of people
: > who feel compelled to write things from scratch (and end up doing
: > things more or less exactly the same way), instead of building
: > on available tools.
: ...except that current trends in using tools and resable code and libraries
: have bloated code to the point that what once could be done in 64k now
: requires in excess of 16 megs to run gracefully.
Except #1 that 64k machine code is not reusable or easy to maintain or
debug, and it takes much longer to develop.
#2 The only time taking 16 MB to run bothers you is if you do not have
16 MB.
Of course, being the type of person who likes to bend facts way out of
shape, the numbers 64k and 16 MB are not actually reflective of the
efficiency loss.
In real terms, on real machines, the difference is necessary in
negligible. Why it is necessary I describe below.
: The "state of the art" in programming is far less efficient owing to the
: the attitudes of the johnny-come-latelies who fear programing so much that
: they'd rather triple the resource requirements of a program than do it right.
: (lest you think LpC doesn't have this problem, take a look at Batmud some
: time)
You have seen one LPMud and you think that is the way they are all
coded? Have a problem with rational thinking Russ?
: > Eh? What are you babbling about? What two categories? What does any
: > of this have to do with moving items and Zork? (which, by the way,
: > is still far more advanced than many muds ... how many muds have you
: > been on which know of relations other than 'in'?)
: "evocative" and "creative", just like he said. And I was referring to
: the Lp quest, which is effectively a less advanced version of the Zork
: tradition of moving object A to location B to do somethjing.
: BTW, Zork doesn't really handle anything more sophisticated than "in",
: since "on" is really the same thing.
Blah, blah blah, you don;t know what the fuck an LPMud is, much less
what the hell you are talking about in even the vaguest sense.
: > What is your point, anyway, other than you don't think much of his
: > programming skills (have you actually bothered to look at anything
: > he's written?) and feel like contradicting him without offering
: > any contrary evidence?
: My point is, any programmer who tries to avoid all programming should
: think about getting into something harmless like marketing instead.
Because you can name that tune in 64k? The only people who care are
people holding contests. The people paying programmers to spend 2
years on a project that could have taken 2 months with reusable
objects definitely think differently.
: And just because you're too dim to parse a setence doesn't mean I didn't
: offer contrary evidence.
A litany of insults does not equal contrary evidence.
Ben Greear
George Reese <bo...@winternet.com> wrote:
>
>: ...except that current trends in using tools and resable code and libraries
>: have bloated code to the point that what once could be done in 64k now
>: requires in excess of 16 megs to run gracefully.
>
>Except #1 that 64k machine code is not reusable or easy to maintain or
>debug, and it takes much longer to develop.
>
>#2 The only time taking 16 MB to run bothers you is if you do not have
>16 MB.
If you do take the time to program well though, you have a much nicer
piece of code to manage. And that attitude about memory is the precise
reason why people are spending big money for extra memory.... Think about
all the adds you see for ppl wanting 32meg to run their mud on, at 35$
a meg, that is a lot of money. Especially when a well written program
can probably store the same size world, and run faster because of it,
in much MUCH less memory.
>
>In real terms, on real machines, the difference is necessary in
>negligible. Why it is necessary I describe below.
This is bullshit, plain and simple. if you don't believe me, try
having to run something in swap space because some jackoff just used a
fixed array w/linear searching instead of a decent tree to store info.
RUSS:
>: My point is, any programmer who tries to avoid all programming should
>: think about getting into something harmless like marketing instead.
I agree.
>
>Because you can name that tune in 64k? The only people who care are
>people holding contests. The people paying programmers to spend 2
>years on a project that could have taken 2 months with reusable
>objects definitely think differently.
Reusing objects does not necessarily make them large and cumbersome,
lazy, incompetent coding does that.
> George Reese (bo...@imaginary.com) | "What the world needs now is
Ben Greear
gre...@pollux.cs.uga.edu | "More weight." -- The Crucible
| "Son, you got a pantie on yer head."
--Raising Arizona
George Reese
: >Because you can name that tune in 64k? The only people who care are
: >people holding contests. The people paying programmers to spend 2
: >years on a project that could have taken 2 months with reusable
: >objects definitely think differently.
: Reusing objects does not necessarily make them large and cumbersome,
: lazy, incompetent coding does that.
That is NOT was I am arguing, nor what this thread is about. The
thread is about what the most efficient way in terms of development
time and quality product to create an easy to modify mud. Mr. "I want
a flamewar" Russ thinks it can only be done by self-important computer
programmers who specialize in compressing what used to run in 100k
down to 98k.
I, on the other hand, believe that good programmers can make it
possible for non-programmers to do all the building, and that in fact
in the end people should not be expected to sit down and program in
order to get a computer to do what they want.
Russ implied that efficiency is incompatable with my belief. In
fact, he stated outright that I was incompetant for wanting things to
be that way.
Sounds a bit like a gunsmith before the industrial revolution, don't he?
--
George Reese (bo...@imaginary.com) | "What the world needs now is
Jacob Hallen
Petri Virkkula <Petri.V...@tky.hut.fi> wrote:
> For example, I believe (haven't checked lately) that there is
> still areas that has been made when there weren't inheritance
> (made with ONE_EXIT(), TWO_EXIT() etc. macros) and they have
> same functionality as the newer rooms.
Now, that is what I call _gross_. Don't you ever service old code?
Getting rid of anacronisms like that would probably take a day or two,
and it would be worth every bit of that time.
Rooms written with the old macros lack the flexibility and code support
that modern mudders have come to expect.
Jacob Hallen
Russell Taylor
> You are the one who entered into this thread (in which I was
> defending a non-LP person against some wrong comments by an LP person)
> by saying I was an incompetant programmer. You have not even seen
> what I have coded.
Technically, I didn't. I said "spoken like a truly incompetent programmer".
If you wish to conclude from that that you _are_ a truly incompetent
programmer, be my guest :)
> Please show any post where I suggested I don't care about that.
You support the same sorts of "innovations" in programming that have
resulted in the current epidemic of code bloat.
> To end builders, it makes no difference. To people maintaining the
> system, it makes a world of difference. Flexible object systems are
> infinitely easier to maintain and modify. Modification menaing
> something more than declaring object properties.
It still takes programming to add a new object property, and most
likely about the same amount no matter how you do it. I'm referring
to the apparent contradiction that you dislike server-based programming
because it "makes it hard to change things" but recommend the same
approach (basing objects off common features) to people building Lps.
> Your need to attribute beliefs to me I do not have, and then express
> them in hyperbole underlines the overall weakness in your entire mode
> of thinking.
So do you a) believe that modern programs aren't (for the most part, as
I said) inefficient or b) believe that the program practices you
espouse are somehow unconnected to those problems?
Charles W. Hooks
Interesting topic that has been around forever. Neither side ever
wins, I believe that is becuase the truth lies some where in the middle.
However I've found it interesting that on most muds, memory could be saved
by useing objects differently. I would argue usign them correctly, but that
is merely my view on the matter.
To get the point, objects are always built thru inheritance, even if
the object is truly just an isntance of an object. I've rarely seen people
just clone the master sword object to make thier own sword that really only
contains a name, descriptions, value, and class. Instead programmers are
taught to inherit the main object, thsu creating a new master object.
I've only programmed mudlibs, and never really fived into engines,
but from what I've seen. Drivers seem to be designed, or at least operate
close to 'proper' object oriented methods and techniques. Yet few mudlibs
that I've played with seem to operate that way.
I've heard lots of arguements about what coudl basically be considered
overhead. Though in different manners and ways. People complain about data
structures being used impoperly. Yet would not a well design object oriented
system have a library of acceptable data type objects to use?
Perhaps if more complete libraries for data structures, inheritance,
instance, and other object oriented methods were mroe available, adn easily
used muds would become faster and leaner in operation.
Maybe some of the newer languages will provide that, things like TCL
or Java. It might be nice if people start creatign lists of engines AND
mudlibs with features along these lines.
Anyways... Jsut museing from a coder who runs a mud on 16 megs, and
is constantly designing and redesign ways to run effiecently...
If curious feel free to stop by nexus at sauron.ecst.csuchico.edu 4000.
Battleaxe
--
Charles W. Hooks aka Tribbles _ /|
aka Moonshae \'o.O'
aka (sh...@ecst.csuchico.edu) =(___)=
California State University, Chico U
company account
>In article <31049e79...@news.netvision.net.il>,
> av...@netvision.net.il (Alex Oren) wrote:
>>
>>Hello.
>>
>>Specifically, I'd like to know what are the most flexible MUD engines in
>>terms of world customization and adding commands without recompiling the
>>MUD source.
>These days, this is true of most of the MUD engines out there. The big
>difference comes in HOW they do it and the level of flexiblity. Things like
>NetCI, LP, MOO, coolMUD and coldMUD are probably the most flexible. They tend
>to consist of a server and then the mudlib/db runs on top of it and defines
>the world rules. The other possibility is something like TinyMUCK or
>TinyMUSH. Both have programming languages that can be used to add commands to
>the world. (Though these days everyone seems to feel the best way to add
>something in is to code it in it seems). I personally see TinyMUCK and
>TinyMUSH as being best if you are adding smaller things into the world then
>making big broad changes to it. Whereas when you want to do something really
>different you go with one of the more programmable worlds. But in the end,
>most of it boils down to what you are comfortable with :)
Hmm. I coded my own MUD entirely from scratch. I started out
wanting to make something infinetly flexible.. but one has
to balance fleibility on the universe scale with actual cost
and benefits. Depending on the method by which a given MUD
runs the in-game code, it may make quite a bit of sense to have the
basic player commands hard coed (probably makes the best
sense in any system really.)
My personal opinion, is that those who are incapable of making
changes to the MUD source, shouldn't really be trying to operate
a public game. Many admin seem to get all hung-up with
the process of building a game, and wish to do everything to
make online building easier - but what if your goal is to present
a *built* game (the majority of items)? Then it makes less sense
in the long run to gear everything towards ease of real time
experimentation at the expense of runtime speed.
Which isn't to say that my own game doesn't have some fat here and
there ;)
-McDaniel -- speaking for himself.
Russell Taylor
> Except #1 that 64k machine code is not reusable or easy to maintain or
> debug, and it takes much longer to develop.
Consider EMACS :)
> #2 The only time taking 16 MB to run bothers you is if you do not have
> 16 MB.
No, actually it bothers me when I run multiple applications, which can
easily push your RAM needs to and beyond 64 megs for a server.
Of course, some people might think nothing of spending $4000 on RAM,
but then I'd rather spend it on other hardware.
It's not that all large-RAM programs are bad, it's the collective effect
that gets annoying -- kind of like in school, where every class assumed
you had 6 hours a night to work on their assignments, except now every
program thinks you have 2, 4, or even 16 megs of RAM to throw at it.
> Of course, being the type of person who likes to bend facts way out of
> shape, the numbers 64k and 16 MB are not actually reflective of the
> efficiency loss.
It's certainly more than doubling. It's questionable whether it's
more than quadrupling.
> In real terms, on real machines, the difference is necessary in
> negligible. Why it is necessary I describe below.
On "real machines, running 10 EMACS processes can throw you into swap
nightmares.
I won't even mention what can happen with Xterms.
> You have seen one LPMud and you think that is the way they are all
> coded? Have a problem with rational thinking Russ?
I've seen resouce requirements posted for many Lp muds. Batmud is most
likely the worst offender.
> Blah, blah blah, you don;t know what the fuck an LPMud is, much less
> what the hell you are talking about in even the vaguest sense.
*pat*
> Because you can name that tune in 64k? The only people who care are
> people holding contests. The people paying programmers to spend 2
> years on a project that could have taken 2 months with reusable
> objects definitely think differently.
Meanwhile, the latest release of Microsoft office weighs in at 60-odd
megs of disk space and requires more than 16 megs of RAM to operate
gracefully. If this is the result of "more rapid development", don't
you pity the people who need to throw a $5000 machine at it just to
process text? Don't you think the world might be better served by
doubling development time and halving resource requirements?
There's two basic attitudes to this escalating problem: the first is to
say "throw more resources at the program", the second to say "make the
program run more efficiently".
All of your postings suggest you'd rather throw an extra $500 at a machine
than try to program efficiently.
> A litany of insults does not equal contrary evidence.
Nope, but neither does frenzied rationalizations about programming speed.
If fast progamming was all that mattered, we'd all be using visual basic
and perl.
Sometimes you have to think about the poor saps who will actually have to
use your programs.
--
Russ Taylor
<A HREF="http://www.pacinfo.com/~rtaylor/">PacInfo</A>
Systems Administrator and Consultant, PacInfo
"That's who you remind me of -- an evil Mr. Rogers!"
Petri Virkkula
Jacob> In article <ndfn377...@arioch.tky.hut.fi>,
Jacob> Petri Virkkula <Petri.V...@tky.hut.fi> wrote:
>> For example, I believe (haven't checked lately) that there is
>> still areas that has been made when there weren't inheritance
>> (made with ONE_EXIT(), TWO_EXIT() etc. macros) and they have
>> same functionality as the newer rooms.
Jacob> Now, that is what I call _gross_. Don't you ever service old code?
Jacob> Getting rid of anacronisms like that would probably take a day or two,
Jacob> and it would be worth every bit of that time.
I have to take my words back, none of the old rooms that I found
were loaded into game. But they are still there waiting for
old wizards to come back or to a new wizard to take over the
area (which can happen only if the old wizard hasn't been on
for 6 months, and we have many such wizards).
Jacob> Rooms written with the old macros lack the flexibility and code support
Jacob> that modern mudders have come to expect.
I think it didn't say it clearly that the macros have been
rewritten too. The rooms written with macros can have all
features as the new ones. You need just to use EXTRA_RESET,
EXTRA_INIT and EXTRA_LONG as the code snippet below from
/room/room.h shows.:
--- cut here ---
inherit "nroom/room";
#define EXTRA_RESET
#define EXTRA_INIT
#define EXTRA_LONG
#define ONE_EXIT(DEST, DIR, SH, LO, LIGHT)\
reset(arg) { ::reset(arg); set_outdoors(4); \
EXTRA_RESET if (arg) return; set_light(LIGHT);\
set_short(SH); set_long(LO);\
add_exit(DIR,DEST);\
set_weather_obj("obj/weather"); }\
init(object from) { ::init(from); EXTRA_INIT }\
long(str) { EXTRA_LONG ::long(str); }
--- cut here ---
/nroom/room.c is total rewrite of old /room/room.c.
Gregory Fullsome
>Please cite a case where I have done so, or shut up. Unfounded
>accusations are extremely rude. What have I ever done to you, anyway?
>Why do you feel compeled to follow up to the same 4 lines with 2 lines
>of abuse in two separate posts?
>
LAUGH! I LOVE IT! Beek and Descartes are so easy to bait!
Gregory Fullsome is bogus. I don't exist! Can't you spot a troll?
MAHAHAHAHAHAHA!
Joern Rennecke
>I'll give you overhyped. However, after reading the VM specification,
>I was rather encouraged. The Java language itself is rather
>unimpressive. It adds few useful things which aren't already common
>in various other languages. Here is why I think the Java VM is an
>important advance, though:
>(1) The bytecode interpreter will be widely distributed. No MUD
> developer can hope to achieve as wide distribution.
So what? As long as it compiles with gcc, it works on quite a large set
of platforms. Besides, not every player needs to run his own MUD.
>(2) The bytecode is fairly simple to convert to native code, since
> it is pretty low level (btw, this is one of the reasons Java is slow;
> interpreting such low level opcodes is very slow). Given the demand
> for Java and the number of large companies throwing their weight
> behind it, I think it's very likely we will see Java VM -> native code
> translators within a year or so.
This is a only relevant if all you have is the bytecode. When you set up a
MUD server, you better have the source code anyways.
>(3) The bytecode is _very_ language neutral, making it easy to target
> it with other languages (though the lack of multiple inheritance
> is worrisome)
So what? You eventually target machine code. You can have this now, with
multiple source languages :-)
>(4) As stated above, the portable object format and security
> guarantees are _ideal_ for mud applications
I don't see any benefits for a centralized MUD server.
Even for a distributed MUD, you are probably better off transferring real
source files, since they tend to include more information the compiler
optimizer can use.
This leaves clients. This could be quite interesting: every mud could supply
its own client or own set of clients as java applets.
When some game situation requires some special functionality, you just get
a new applet to handle this.
Amylaar
Tim Hollebeek
sense ...
Joern Rennecke (amy...@meolyon.hanse.de) wrote:
: I don't see any benefits for a centralized MUD server.
This is very true, and IMO, the biggest thing the JavaMUD mailing list
has yet to grasp. If you are writing a traditional style mud,
Java blows.
[ Reasons why Java/JavaVM is really inappropriate for a monolithic
server snipped; I agree completely and that wasn't really what I had
in mind ]
: Even for a distributed MUD, you are probably better off transferring real
: source files, since they tend to include more information the compiler
: optimizer can use.
This depends; hopefully by distributing the MUD, CPU is less of a
problem. It also depends on the scale with which it is distributed.
For example, if you have 100 nodes, then keeping them all up to date
software-wise would be a real pain. It would be much nicer if code
can simply be transfered around easily and automatically in a secure,
language neutral way. Note that 100 nodes isn't unreasonable; the
WWW has proved that large interconnected networks of 'home spaces'
are very attractive for social reasons, especially if anyone can
set up their own 'space' very easily. Forcing them to constantly
upgrade their software, etc, would make this much harder. If all
they need is a Java aware browser and a minimal knowledge of HTML,
it's a big win.
: This leaves clients. This could be quite interesting: every mud could supply
: its own client or own set of clients as java applets.
: When some game situation requires some special functionality, you just get
: a new applet to handle this.
This is another thing that would be nice; I'm not sure that its as big
a draw, though. Certainly the traditional problem with requiring a
client is that people don't bother to take the time to download it;
sending them a Java applet allows the mud to have a more GUI front end
without having to write one for every client platform, etc, so it does
solve that problem.
: tim@franck (Tim Hollebeek) writes:
: >I'll give you overhyped. However, after reading the VM specification,
: >I was rather encouraged. The Java language itself is rather
: >unimpressive. It adds few useful things which aren't already common
: >in various other languages. Here is why I think the Java VM is an
: >important advance, though:
: >(1) The bytecode interpreter will be widely distributed. No MUD
: > developer can hope to achieve as wide distribution.
: So what? As long as it compiles with gcc, it works on quite a large set
: of platforms. Besides, not every player needs to run his own MUD.
Yes, but there are some interesting advantages _if_ every player _can_
run his own MUD. You end up with something more along the lines of a
MUSH than a traditional MUD, but that doesn't make it uninteresting.
In fact, a quick glance at the MUD world today will show that everyone
does want to run their own MUD :-) That isn't necessarily a bad
thing, but it certainly doesn't work very well under the traditional
monolithic server model.
Tim Hollebeek
: LAUGH! I LOVE IT! Beek and Descartes are so easy to bait!
: Gregory Fullsome is bogus. I don't exist! Can't you spot a troll?
: MAHAHAHAHAHAHA!
Hmm, you exist, regardless of whether you hide behind a bogus account
or not. We _wish_ you didn't exist, but unfortunately you do. Feel
free to rectify the situation.
Aedil CLah Afaros
: While I've had my own arguments with Descartes (anyone remember
: the discussion on linking muds?), I have to agree with Beek that
: anyone who would imply that Descartes is a poor programmer has
: never looked at any of his code. Since it appears that you
: don't know, Descartes is one of the founders of Nightmare, and
: one of the primary (if not *the* primary) coder of the Nightmare
: and Foundation mudlibs. He also maintains the FAQ for
: rec.games.mud.lp.
This does not however point out he is a good programmer. Still, I agree
that the Nightmare mudlib is a nice piece of work for running on MudOS.
I don't like it for several design reasons which also have connections
to the MudOS basics, but that is besides the point, the code looks pretty
decent. I don't make statements about how much was coded by any of the
people working on it either, since I don't have any clue about that.
Anyhow, I *did* look at his code during his active time at Igor... I'm
sorry, but anyone who remembers the headaches of the famous horses will
have to agree that it didn't show a good coder. It did show a coder with
initiative, and a creative mind. Just not good code.
However, I assume he learned alot after that time (which, I think was
in the early stage of his LPC programming - correct me if I'm wrong).
Aedil
PS: Those who like flaming, look for another note of mine concerning
concurrency in LPC :) Coming up very soon in a newsgroup near you.
Alex Oren
Uhmmm... guys?
As the one who originally posted the question I ask you, please don't
turn it into a flame war!
Most of the (helpful) comments were about LP.
How do other systems compare?
I've seen mention of ColdMud and CoolMud, what about them?
bo...@winternet.com (George Reese) wrote:
: Gregory Fullsome (gful...@stormbringer.net) wrote:
: : In article <4e8a02$i...@blackice.winternet.com>,
: : bo...@winternet.com (George Reese) wrote:
:
: : >So though you may be right in arguing against his conclusions, you
: : >see, your reasoning is wrong.
:
:
: : Not nearly as poor as yours however. I'd go through it piece by
: : piece, but from reading this group, all I ever see you do is engage
: : in flame war after flame war, in which you find ONE tiny little thing
: : that is correct and cling to it. You'd probably do the same thing here,
: : thus its pointless. I hope Halcyon decides on the same method in regards
: : to you.
:
: Nit picking? Halcyon called Snooze an idiot for no reason
: whatsoever. And you back up Halcyon with unwarranted personal attacks
: on me? I guess you made your point!
Have fun,
Alex
George Reese
: > thread is about what the most efficient way in terms of development
: > time and quality product to create an easy to modify mud. Mr. "I want
: > a flamewar" Russ thinks it can only be done by self-important computer
: > programmers who specialize in compressing what used to run in 100k
: > down to 98k.
: Oh? I'm curious where I said that.
:
: The issues I've been attacking is making programs that should run in
: 4-8 megs run in 16-64 megs, actually.
What programs might that be? You have been attacking LPMuds, and my
LPMud runs in 10 MB (ok, 2 MB outside your precious 4-8 range, but
nowhere near your 16 MB, much less that 64 MB figure). And everyone
in LPMuds will admit there is room for optimization, but that does not
mean the design itself is flawed.
: > I, on the other hand, believe that good programmers can make it
: > possible for non-programmers to do all the building, and that in fact
: > in the end people should not be expected to sit down and program in
: > order to get a computer to do what they want.
:
: > Russ implied that efficiency is incompatable with my belief. In
: > fact, he stated outright that I was incompetant for wanting things to
: > be that way.
:
: Nope, I think that efficient programming is incompatibility with reusing
: all your code in later projects -- look up "optimize" sometime in
: the dictionary.
I would suggest you take your own advice. Optimize means make run
faster in only the narrowest sense of the word. In fact optimize
making the most efficient use of the resources at hand. Those
resources also happen to include the time and effort involved in
creating them.
: You might note that my own game doesn't require any code knowledge whatsoever
: to design an area, on-line or off.
And your point is? No one is flaming your mud, don't be getting
defensive. I certainly don't have any knowledge of your system. Thus
note, I don't go making ignorant references about it like you do about
LP's.
:
: > Sounds a bit like a gunsmith before the industrial revolution, don't he?
:
: I don't know, I'd say the better analogy might be NASA's insistence that
: the Shuttle is superior technology, and therefore should be used.
:
: You in the position of NASA, of course.
:
: (for those who didn't know: the Shuttle is inefficient beyond all belief,
: and could be easily replaced with other designs that would use less than
: 1% of the resources involved in a Shuttle launch)
:
: But of course, if you follow Mr. Borg's line of reasoning, the shuttle
: is a newer, advanced model, and therefore should be used no matter
: what the cost.
:
My name is not Mr. Borg.
And, if you interpret my reasoning that way, you must be more
rationally challenged than I first imagined. Where did I say object
technology should be used just because it is new? Nowhere. I said
and maintain that object technology saves time and money in
development and maintainence. This leads to solving people's problems
faster, and it also raises the pathetic quality of code. Of course,
this assumes you know what an object is. Bandying about Microsoft
Office, as you seem to like to do, as some sort of example of objects
only belies your ignorance on the subject.
George Reese
: Anyhow, I *did* look at his code during his active time at Igor... I'm
: sorry, but anyone who remembers the headaches of the famous horses will
: have to agree that it didn't show a good coder. It did show a coder with
: initiative, and a creative mind. Just not good code.
:
: However, I assume he learned alot after that time (which, I think was
: in the early stage of his LPC programming - correct me if I'm wrong).
Actually, that was my first bit of computer programming ever.
Yes, that horse code did suck big time. But people liked it :)
Russell Taylor
> That is NOT was I am arguing, nor what this thread is about. The
> thread is about what the most efficient way in terms of development
> time and quality product to create an easy to modify mud. Mr. "I want
> a flamewar" Russ thinks it can only be done by self-important computer
> programmers who specialize in compressing what used to run in 100k
> down to 98k.
Oh? I'm curious where I said that.
The issues I've been attacking is making programs that should run in
4-8 megs run in 16-64 megs, actually.
> I, on the other hand, believe that good programmers can make it
> possible for non-programmers to do all the building, and that in fact
> in the end people should not be expected to sit down and program in
> order to get a computer to do what they want.
> Russ implied that efficiency is incompatable with my belief. In
> fact, he stated outright that I was incompetant for wanting things to
> be that way.
Nope, I think that efficient programming is incompatibility with reusing
all your code in later projects -- look up "optimize" sometime in
the dictionary.
You might note that my own game doesn't require any code knowledge whatsoever
to design an area, on-line or off.
> Sounds a bit like a gunsmith before the industrial revolution, don't he?
I don't know, I'd say the better analogy might be NASA's insistence that
the Shuttle is superior technology, and therefore should be used.
You in the position of NASA, of course.
(for those who didn't know: the Shuttle is inefficient beyond all belief,
and could be easily replaced with other designs that would use less than
1% of the resources involved in a Shuttle launch)
But of course, if you follow Mr. Borg's line of reasoning, the shuttle
is a newer, advanced model, and therefore should be used no matter
what the cost.
--
Aedil CLah Afaros
: : Nope, I think that efficient programming is incompatibility with reusing
: : all your code in later projects -- look up "optimize" sometime in
: : the dictionary.
: I would suggest you take your own advice. Optimize means make run
: faster in only the narrowest sense of the word. In fact optimize
: making the most efficient use of the resources at hand. Those
: resources also happen to include the time and effort involved in
: creating them.
Erm, you may have followed different classes on computer science or read
different books and articles, but optimization hardly ever has anything to
do with the time and effort in creation of software. It may help, but the
concept of optimizing time and effort in creation is not usually taken as
optimization at all. More like common sense, here and there. And almost
always in the sense of "we have to spend less time on creating this since
the compiler will optimize it properly anyway" as such taking away alot of
the waste of time of trying to find the most efficient way of programming
something. (That does not invalidate the search for the best algorithm.)
Aedil
Schultz, Russell
rta...@pacinfo.com (Russell Taylor) writes:
> (for those who didn't know: the Shuttle is inefficient beyond all belief,
> and could be easily replaced with other designs that would use less than
> 1% of the resources involved in a Shuttle launch)
Thank you "Oh-Great-One-Of-Much-Knowledge".
Any facts/sources to back that one up? :)
The shuttle launches are so utterly expensive (imho and experience)
because there's a LOT of govt red tape in launching one and assuring
the quality and safety. Also, the original shuttle was designed in
1976 and has only had major components redesigned since(not the entire
system)--hence larger/less capable/less efficient design that currently
possible. In addition, many of the systems are specially
designed/built and are pains in the butt to change without major
impacts elsewhere.
If you'd really like an analogy, its like using non-OOP code in a MUD
server and having to redesign every stinking interface when you want
new functionality.
I'm not claiming its the best technology...but your claim is just way
out in left field.
Russ/Poo...@ronin.bchs.uh.edu 5000
Russell Taylor
> What programs might that be? You have been attacking LPMuds, and my
> LPMud runs in 10 MB (ok, 2 MB outside your precious 4-8 range, but
> nowhere near your 16 MB, much less that 64 MB figure). And everyone
> in LPMuds will admit there is room for optimization, but that does not
> mean the design itself is flawed.
Check out how much BatMud runs in some time.
If you want examples, go to a software shelf and start pulling titles.
Compare them with similar titles from 3-5 years ago.
Obligatory (if loaded) example: any Microsoft product will have at
minimum doubled it's RAM requirement, in some cases much more than
doubled (i.e. MS Word from < 1 meg to > 6 megs).
> I would suggest you take your own advice. Optimize means make run
> faster in only the narrowest sense of the word. In fact optimize
> making the most efficient use of the resources at hand. Those
> resources also happen to include the time and effort involved in
> creating them.
Code optimized for one use is almost by definition not fully optimized for
another, unless the set of all possible optimizations for purpose A is
a superset of the set of all possible optimizations for purpose B.
Optimizing from a coding perspective refers purely to performance issues,
not coding issues. You know that, I know that, everyone reading this group
knows that. Claiming that programming fast and loose is an "optimization" is
hardly valid.
Optimizing does not, however, imply running faster -- you know, I know,
everyone who reads this group knows that. For example, optimizing for
speed often means increasing memory requirements, and virtually always
increases the size of the code (i.e. inlining functions). Optimizing
for memory usage can often slow down the program (i.e. disk-basing,
string sharing (in some implementations), eliminating large memory
structures). And optimizing for executable size similarly will slow
performance in most programs.
> And your point is? No one is flaming your mud, don't be getting
> defensive. I certainly don't have any knowledge of your system. Thus
> note, I don't go making ignorant references about it like you do about
> LP's.
You implied that people designing for my game would need to know how
to code, I illustrated that that was not the case. That's the point.
In this case, I knew it, the rest of the group knew it, but you must
have suffered momentary amnesia.
> My name is not Mr. Borg.
One of your names is. Your user name, that is. Maybe you should
get it changed if it bothers you?
(I admit, I put that in just to tweak Mr. Borg)
> And, if you interpret my reasoning that way, you must be more
> rationally challenged than I first imagined. Where did I say object
> technology should be used just because it is new? Nowhere. I said
> and maintain that object technology saves time and money in
> development and maintainence. This leads to solving people's problems
And hurts performance.
> faster, and it also raises the pathetic quality of code. Of course,
> this assumes you know what an object is. Bandying about Microsoft
> Office, as you seem to like to do, as some sort of example of objects
> only belies your ignorance on the subject.
You were bandying about reusable code. Mickeysoft products are the
ultimate example of what that can do to a program.
If you need an example of the problems with OO, at least with C++,
compare the performance of a C++ program with a C program some time.
Of course, there _are_ better OO languages than C++ out there, but
none in common use, and none that correct the performance problems
one finds with any use of objects.
(note: there's certainly things that OO programming is well-suited for.
However, there are equally certainly things it is not suited for.
Kinda like trying to use C for an AI project, or LISP for a number-cruncher)
George Reese
: George Reese (bo...@winternet.com) wrote:
: > What programs might that be? You have been attacking LPMuds, and my
: > LPMud runs in 10 MB (ok, 2 MB outside your precious 4-8 range, but
: > nowhere near your 16 MB, much less that 64 MB figure). And everyone
: > in LPMuds will admit there is room for optimization, but that does not
: > mean the design itself is flawed.
:
: Check out how much BatMud runs in some time.
Oh, BatMud does, so the design is flawed? Isn't that a bit of a leap?
BatMud does a lot of things I disagree with in mud design. And that
is not from looking at the code even, that is simply from reading
Anipa's posts (overuse of shadows being the number 1 thing to come to
mind).
: If you want examples, go to a software shelf and start pulling titles.
: Compare them with similar titles from 3-5 years ago.
:
: Obligatory (if loaded) example: any Microsoft product will have at
: minimum doubled it's RAM requirement, in some cases much more than
: doubled (i.e. MS Word from < 1 meg to > 6 megs).
I tell you that oranges are a good thing, and you hold up rotten
apples and say "ha! oranges are not good things!" Get a clue.
Microsoft is not a pioneer in object technology, nor would they have a
clue of how to use it if it bit them on the ass. Instead ask
companies like Xerox and Citicorp and General Motors what objects have
meant to them.
: > I would suggest you take your own advice. Optimize means make run
: > faster in only the narrowest sense of the word. In fact optimize
: > making the most efficient use of the resources at hand. Those
: > resources also happen to include the time and effort involved in
: > creating them.
:
: Code optimized for one use is almost by definition not fully optimized for
: another, unless the set of all possible optimizations for purpose A is
: a superset of the set of all possible optimizations for purpose B.
:
: Optimizing from a coding perspective refers purely to performance issues,
: not coding issues. You know that, I know that, everyone reading this group
: knows that. Claiming that programming fast and loose is an "optimization" is
: hardly valid.
:
: Optimizing does not, however, imply running faster -- you know, I know,
: everyone who reads this group knows that. For example, optimizing for
: speed often means increasing memory requirements, and virtually always
: increases the size of the code (i.e. inlining functions). Optimizing
: for memory usage can often slow down the program (i.e. disk-basing,
: string sharing (in some implementations), eliminating large memory
: structures). And optimizing for executable size similarly will slow
: performance in most programs.
Optimizing means making optimal use of ALL your resources. Even if
you want to limit your resources to computer related resources like
RAM and CPU, that does not get rid of the fact that it takes time to
design, develop, and maintain a program. The costs of all that
factored in together overwhelmingly make object techniques the optimal
way to do a large number of projects, especially muds.
This is not to say that objects are bloated. They are not totally
optimized in your sense of optimized. But that is not a bad thing
just so long as they are not overburdened on the other end. Again, I
will ask a question, given two applications wich do exactly the same
thing for the end user, would you choose:
#1 an easily modifiable, easy to maintain program that runs in 8 MB
RAM on a 486-33 that took 2 months to build
#2 a hard to modify, hard to maintain program that runs in 4 MB RAM on
a 386 that took a year to build
And that there is the bottom line of objects.
: > And your point is? No one is flaming your mud, don't be getting
: > defensive. I certainly don't have any knowledge of your system. Thus
: > note, I don't go making ignorant references about it like you do about
: > LP's.
:
: You implied that people designing for my game would need to know how
: to code, I illustrated that that was not the case. That's the point.
: In this case, I knew it, the rest of the group knew it, but you must
: have suffered momentary amnesia.
Sorry, you must have been reading another thread. I never said a damn
thing about your mud. I was simply defending Snooze's assertion that
you should not need to code to build a good mud.
: > My name is not Mr. Borg.
:
: One of your names is. Your user name, that is. Maybe you should
: get it changed if it bothers you?
:
: (I admit, I put that in just to tweak Mr. Borg)
My, how grown-up of you.
: > And, if you interpret my reasoning that way, you must be more
: > rationally challenged than I first imagined. Where did I say object
: > technology should be used just because it is new? Nowhere. I said
: > and maintain that object technology saves time and money in
: > development and maintainence. This leads to solving people's problems
:
: And hurts performance.
Not significantly. And certainly the benefits outweight the minor
performance loss.
: > faster, and it also raises the pathetic quality of code. Of course,
: > this assumes you know what an object is. Bandying about Microsoft
: > Office, as you seem to like to do, as some sort of example of objects
: > only belies your ignorance on the subject.
:
: You were bandying about reusable code. Mickeysoft products are the
: ultimate example of what that can do to a program.
Like I said, this belief shows just how ignorant you are on the entire
subject.
: If you need an example of the problems with OO, at least with C++,
: compare the performance of a C++ program with a C program some time.
:
: Of course, there _are_ better OO languages than C++ out there, but
: none in common use, and none that correct the performance problems
: one finds with any use of objects.
If you are concerned about performance problems of C versus C++, may I
suggest you code in machine language? because you have way too much
time to worry about trivialities.
And certainly, given the overwhelming number of companiues choosing to
develop using atrocities such as Visual Basic and PowerBuilder, both
of which give new meaning to the expression 'poor performance', end
users really can't be caring that much about the difference between C
and C++.
By the way, just because it is C++ does not make it object-oriented.
Similarly, I can code an object-oriented application in C.
Object-orientation is a methodology, not a tool.
Paul Speed
: By the way, just because it is C++ does not make it object-oriented.
: Similarly, I can code an object-oriented application in C.
: Object-orientation is a methodology, not a tool.
Amen! I am so glad someone finally stated this. I've met sooo
many C++ programmers who think they are writing object oriented
programs. Then they look at my C code and say, "Wow, that's really
cool. Hey, you know I think there are some constructs that allow me to
do that in C++." I just shake my head.
If object oriented C code is written well it is not bloated. In
fact just the opposite is true because sometimes the design becomes
simplified when looked at differently.
-Keys
: --
Travis S Casey
shown up on my server yet, so I'm replying to a reply.]
>Russell Taylor (rta...@cheetah.pacinfo.com) wrote:
>: George Reese (bo...@winternet.com) wrote:
>
>: If you want examples, go to a software shelf and start pulling titles.
>: Compare them with similar titles from 3-5 years ago.
>:
>: Obligatory (if loaded) example: any Microsoft product will have at
>: minimum doubled it's RAM requirement, in some cases much more than
>: doubled (i.e. MS Word from < 1 meg to > 6 megs).
Code reuse is not the source of this sort of program bloat.
The primary sources are:
- Feature creep & backwards compatibility
Commerical programs tend to add new features with each
release, while keeping all the old features to maintain
backwards compatibility. Obviously, this causes the
programs to expand over time.
Often the "new" features can substitute for old ones,
but the old ones are kept anyways. For example,
WordPerfect provides calculations in tables, which allows
you to create simple (and even some not-so-simple)
spreadsheets in it. This was a genuine feature back when
switching from one program to another on a PC was a pain...
but now you can do the same thing by starting up a
spreadsheet in another window and using OLE to put the
worksheet into WP. Nevertheless, the tables remain, to
support all the old documents that use them.
Other examples in WP (I'm using WP for examples, mainly
because I've never used Word) are the included drawing
program, the clip art, the database-like capabilities of
mail merge, the reconfigurable interface (together with
settings to make the interface more like the old one),
etc.
Most of these features could be chunked now, if it
weren't for backwards compatibility.
- Poor library structure
Code libraries these days are often very granular; DLL's
in Windows are an example; if I want to use just one
routine from a DLL in my program, I have to ship the
whole DLL with it... and the whole DLL gets loaded into
memory when that one procedure is called.
A great example is QuickBASIC. The libraries MS shipped
with it are highly granular, and produce vastly bloated
code--an empty program is over 10K! A third-party
company, however, produced a set of libraries for QB called
PDQ; a comparison in Dr. Dobb's Journal showed that a
"Hello, World" produced with QB and PDQ was considerably
smaller than one created with any of the leading C
compilers, and only slightly larger than one created in
assembly!
Code reuse, IMHO, is not a problem; it is the *indiscriminate*
reuse of code, and methods of reuse that cause more to be
included than is needed (like the libraries given above) that
can cause bloated code.
>: Code optimized for one use is almost by definition not fully optimized for
>: another, unless the set of all possible optimizations for purpose A is
>: a superset of the set of all possible optimizations for purpose B.
>:
>: Optimizing does not, however, imply running faster -- you know, I know,
>: everyone who reads this group knows that. For example, optimizing for
>: speed often means increasing memory requirements, and virtually always
>: increases the size of the code (i.e. inlining functions). Optimizing
>: for memory usage can often slow down the program (i.e. disk-basing,
>: string sharing (in some implementations), eliminating large memory
>: structures). And optimizing for executable size similarly will slow
>: performance in most programs.
This is all true. However, there is no reason that a code
library can't include code optimized for different circumstances;
the problem of choosing which code to link in can then be left
up to the compiler, and it can choose based on flags passed to it.
(E.g., an "optimize for size" flag).
>: > And, if you interpret my reasoning that way, you must be more
>: > rationally challenged than I first imagined. Where did I say object
>: > technology should be used just because it is new? Nowhere. I said
>: > and maintain that object technology saves time and money in
>: > development and maintainence. This leads to solving people's problems
>:
>: And hurts performance.
Performance is not always the important issue, however. For
example, I have an address book program written in Visual Basic.
If I were planning on selling it, I'd have written it in something
more efficient; however, I'm not planning on selling it. I just
wanted something to keep addresses in, and I didn't want to spend
a lot of time getting it to work.
There is a point of diminishing returns in optimization; I could
have coded my address book in hand-optimized assembly, but I'd
probably have spent months of my spare time tweaking it. I
made the VB version in an afternoon.
>: You were bandying about reusable code. Mickeysoft products are the
>: ultimate example of what that can do to a program.
>:
>: If you need an example of the problems with OO, at least with C++,
>: compare the performance of a C++ program with a C program some time.
>:
>: Of course, there _are_ better OO languages than C++ out there, but
>: none in common use, and none that correct the performance problems
>: one finds with any use of objects.
What does being object-oriented have to do with code reuse?
OO can make it easier to reuse code, but code reuse existed
long before OOP, through such methods as libraries and cut-and-
paste.
Indeed, depending on one's definition of "code reuse", it's
possible to say that you can't write a program that does anything
useful in Unix or on a PC *without* reusing code. On a PC, the
processor is executing microcode--and thus you are reusing
someone else's code. In Unix, your program can't even load
without making a system call--which is yet another form of
code reuse.
In summary, code reuse is a good thing, but like many good things,
it can be bad if used improperly. But I guess that's probably
too reasonable a view to attract much attention on Usenet. :-)
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ System Manager, FSU CS department
|,4- ) )-,_..;\ ( `'-' (904) 644-4290; Room 101C Carothers
'---''(_/--' `-'\_) No one agrees with me. Not even me.
rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html
malte_tancred
> Russell Taylor (rta...@pacinfo.com) wrote:
> :Nope, I think that efficient programming is incompatibility with reusing
> :all your code in later projects -- look up "optimize" sometime in
> :the dictionary.
>
> faster in only the narrowest sense of the word. In fact optimize
> making the most efficient use of the resources at hand. Those
> resources also happen to include the time and effort involved in
> creating them.
op·ti·mize -mized; -miz·ing
(1857)
:to make as perfect, effective, or functional as possible
Đ op·ti·miz·er
Just looked it up in my online dicitonary, the Webster's Ninth Collegiate
Dictionary and Webster's Collegiate Thesaurus - First Digital Edition. 8-)
Regards,
Malte
--
Malte Tancred
OOPS art, HB
Member of Swedish Object Guild
ma...@oops.se NeXTMail, Mime welcome
Russell Taylor
> In article <4eop9c$8...@cheetah.pacinfo.com>
> rta...@pacinfo.com (Russell Taylor) writes:
> > (for those who didn't know: the Shuttle is inefficient beyond all belief,
> > and could be easily replaced with other designs that would use less than
> > 1% of the resources involved in a Shuttle launch)
> Thank you "Oh-Great-One-Of-Much-Knowledge".
> Any facts/sources to back that one up? :)
Yep, but not on me. If you want an easily available list, check out
the references at the back of "Falling Angles". I'll post a summary
when I get home.
Also see Feynman's comments on the problems with the O-ring technology
used, above and beyond the fact that they blew one shuttle up.
You _did_ know that NASA knew better than to use them in cold
conditions, right?
> The shuttle launches are so utterly expensive (imho and experience)
> because there's a LOT of govt red tape in launching one and assuring
> the quality and safety. Also, the original shuttle was designed in
> 1976 and has only had major components redesigned since(not the entire
> system)--hence larger/less capable/less efficient design that currently
> possible. In addition, many of the systems are specially
> designed/built and are pains in the butt to change without major
> impacts elsewhere.
And also because it's designed in such a way that it _can't_ be launched
without a lengthy startup procedure.
Also, how do you explain the fact that the shuttle was more expensive
to use for it's primary purpose than the rockets it replaced, and that
it doesn't have much of the functionality that the _more_ expensive
NASA toys did?
(i.e. no capability to reach lunar orbit)
> If you'd really like an analogy, its like using non-OOP code in a MUD
> server and having to redesign every stinking interface when you want
> new functionality.
*pat* whatever you say. However 1) that's not a problem with any
well-coded source and 2) poorly coded OOP programs have the same
problem, only more so.
> I'm not claiming its the best technology...but your claim is just way
> out in left field.
If you want some more efficient (and cheaper) designs, look at the
old missile technology, as well as "new" (60s-70s) ideas like
Orion (problematic due to radiation problems) and Phoenix.
I'm not faulting the idea of getting into space, since the space program
has been overwhelmingly profitable for mankind and technology in general,
but I'd shed no tears if NASA got nuked and replaced with something
with half an ounce of common sense.
Tim Hollebeek
: In article <4eop9c$8...@cheetah.pacinfo.com>
: rta...@pacinfo.com (Russell Taylor) writes:
: > (for those who didn't know: the Shuttle is inefficient beyond all belief,
: > and could be easily replaced with other designs that would use less than
: > 1% of the resources involved in a Shuttle launch)
: Thank you "Oh-Great-One-Of-Much-Knowledge".
: Any facts/sources to back that one up? :)
: ... defense of shuttle program ...
: If you'd really like an analogy, its like using non-OOP code in a MUD
: server and having to redesign every stinking interface when you want
: new functionality.
It's actually interesting to read typical Diku source; despite all the
emphasis on 'efficiency' you hear, an actual look at the source code
will reveal that much of it is written considerably less efficiently
than the obvious way to do write it in C.
For example, in my first few minutes of browsing, I stumbled across
the following stunning example (from the CircleMUD src):
/* read and allocate space for a '~'-terminated string from a given file */
char *fread_string(FILE *fl, char *error)
{
char buf[MAX_STRING_LENGTH], tmp[500];
char *rslt;
register char *point;
int flag;
/* Um, buf is only strlen()'ed and strcat()'ed, so *buf = 0 is
sufficient; this is overkill */
bzero(buf, MAX_STRING_LENGTH);
do {
if (!fgets(tmp, MAX_STRING_LENGTH, fl)) {
fprintf(stderr, "fread_string: format error at or near %s\n", error);
exit(0);
}
/* strlen(buf) is the number of chars read so far, which could be kept
easily in an int; or a pointer could be kept to how far we are, in
which case this check is simply (bufp + nbytes >= buf +
MAX_STRING_LENGTH) ... */
if (strlen(tmp) + strlen(buf) > MAX_STRING_LENGTH) {
log("SYSERR: fread_string: string too large (db.c)");
exit(0);
} else
strcat(buf, tmp);
/* here we call strlen() on buf again. */
for (point = buf + strlen(buf) - 2; point >= buf && isspace(*point);
point--)
;
if ((flag = (*point == '~')))
/* and again */
if (*(buf + strlen(buf) - 3) == '\n') {
/* and again */
*(buf + strlen(buf) - 2) = '\r';
/* and again */
*(buf + strlen(buf) - 1) = '\0';
}
else
/* and again */
*(buf + strlen(buf) - 2) = '\0';
else {
/* and again */
*(buf + strlen(buf) + 1) = '\0';
/* and again. Note that the string we are building might be a room
description, which might have a decent length to it */
*(buf + strlen(buf)) = '\r';
}
} while (!flag);
/* do the allocate boogie */
/* twice more for good measure; also (strlen(buf) > 0) is equivalent
to *buf, but much slower ... */
if (strlen(buf) > 0) {
CREATE(rslt, char, strlen(buf) + 1);
strcpy(rslt, buf);
} else
rslt = 0;
return(rslt);
}
This routine, as far as I can tell, is used everywhere a string is
read from a database file. Ouch ... There are tons of other places
where long strings are built out of small parts using strcat(), and
other similar things.
--
Tim Hollebeek | Everything above is a true statement, for sufficiently
<space for rent> | false values of true.
Tim Hollebeek
: Schultz, Russell (schultz...@semail.jsc.nasa.gov) wrote:
: > In article <4eop9c$8...@cheetah.pacinfo.com>
: > rta...@pacinfo.com (Russell Taylor) writes:
: > > (for those who didn't know: the Shuttle is inefficient beyond all belief,
: > > and could be easily replaced with other designs that would use less than
: > > 1% of the resources involved in a Shuttle launch)
[etc]
Um, guys, this has nothing to do with any of the groups it's posted
to. Take it to a relevant group.
Petri Virkkula
Russell> Check out how much BatMud runs in some time.
Batmud just happens to use all available resources that are
available on the machine. A main design goal has been to make
the game faster even if the RAM usage grows. As the machine
has bought with money donated by the players it is justified
to make to them use all of the resources.
For example, there were (and still is) quite much of logging
to prevent all sort of cheating. We noticed that there were
lots of I/O-wait but not all of the physical memory was in
use. So we added buffering to log_file() efun. After that
memory usage was higher but I/O wait time disappeared almost
entirely.
Another example is object list. The list used to be
single-linked. To make object destruction faster it was made
double-linked. Result: 4 more bytes per more than 40000
objects = more than 160k memory used and noticeable speedup
gained.
There are lots of other examples where speed&space tradeoffs
has been solved in favour of speed. Ofcourse there are lots of
bad code, bad design flaws too, I'm first to admit them, but
the memory usage is not high solely because of them.
Jacob Hallen
Russell Taylor <rta...@cheetah.pacinfo.com> wrote:
[A lot of stuff about efficiency]
What you write about efficiency is true, but efficiency is not everything.
The highest performance audio system for your home is built into the house.
It doesn't let you play your favourite music on the beach.
The most efficient form of government is dictatorship, but more often than
not dictators use that efficiency for their own benefit.
The golf clubs that allow for the longest shots take extreme precision and
skill to handle. They don't fit the sunday golfer.
A swiss army knife is not much when it comes to being a knife, it is a
half-baked corkscrew and it serves as a rather lousy screwdriver.
However, it is one tool, not the 20 that it inefficiently replaces.
In the same way an LPMud is not the most efficient way of simulating
monsterbashing or virtual screwing.
It has other merits that I, and many with me think outweigh the fact that
an LPMud eats 10 times as much memory as an efficient solution would, and that
it is fairly heavy CPU-wise.
Flexibility, the relative ease with which you can code truly novel stuff,
the iterative development process that it supports etc makes efficiency a
minor matter.
You are welcome to speed down the infobahn in your sportscar mud. I'll
quietly plod along in my portable home. Every man to his own.
Jacob Hallen
Caliban Tiresias Darklock
>op·ti·mize -mized; -miz·ing
>(1857)
>:to make as perfect, effective, or functional as possible
>Đ op·ti·miz·er
>
>Just looked it up in my online dicitonary, the Webster's Ninth Collegiate
>Dictionary and Webster's Collegiate Thesaurus - First Digital Edition. 8-)
Just out of curiosity, do any of those list the word 'format' as a
verb? If not, then I wouldn't consider it authoritative in the realm of
computer terminology.
Caliban Tiresias Darklock the Hellespontine DiSCORD : Hail Eris
, ___
,----. | /' ) Master of the darkness, I fear nothing but the sun,
--+----' ;/' /^\/' ) I am the only one; the devil's only son;
`.______,/' /'`\___/ I am the dark centurion.
Matthew R. Sheahan
> Optimizing from a coding perspective refers purely to performance issues,
> not coding issues. You know that, I know that, everyone reading this group
> knows that.
well, um, no.
take a look at the "optimization" section of _Programming Perl_.
it contains various sections such as "Programmer Optimization" and
"Maintainer Optimization", in addition to the kind of thing you're
talking about.
now tell us that you know more about optimization than Larry Wall and
Randal Schwartz.
> Claiming that programming fast and loose is an "optimization" is
> hardly valid.
it is "programmer optimization". it is a perspective based on the
idea that my time is more valuable than the machine's. this is not
an insupportible idea.
anyway, you're arguing a position that has been dead for some time.
if you'll take a look at the field of application development, you'll
see that solutions that consider the productivity level of the humans
involved to be irrelevant have been most thoroughly outmoded.
chiaroscuro
George Reese
:
: For *my* purposes, maximum flexibility is a must. A clean design comes
: close second. Of course I'd like an efficient implementaion but that's
: ranked third.
:
: I'm not trying to make a general statement. Those are my particular
: needs for given circumstances.
:
Given all the requirements you have stated, IMHO, MudOS with the
Foundation II mudlib i the best fit. It is a bare bones object lib
that is designed with heavy customization in mind, and it comes with
absolutely no gaming features.
Martin Fuller
>-----------------------------------------------------------
> I'd like to know what are the most flexible MUD engines in
> terms of world customization and adding commands without
> recompiling the MUD source.
>-----------------------------------------------------------
>For *my* purposes, maximum flexibility is a must. A clean design comes
>close second. Of course I'd like an efficient implementaion but that's
>ranked third.
>I'm not trying to make a general statement. Those are my particular
>needs for given circumstances.
>sno...@nunic.nu.edu (snooze) writes:
>: These days, this is true of most of the MUD engines out there. The big
>: difference comes in HOW they do it and the level of flexiblity. Things like
>: NetCI, LP, MOO, coolMUD and coldMUD are probably the most flexible. They tend
>: to consist of a server and then the mudlib/db runs on top of it and defines
>: the world rules. The other possibility is something like TinyMUCK or
>: TinyMUSH. Both have programming languages that can be used to add commands to
>: the world. (Though these days everyone seems to feel the best way to add
>: something in is to code it in it seems). I personally see TinyMUCK and
>: TinyMUSH as being best if you are adding smaller things into the world then
>: making big broad changes to it. Whereas when you want to do something really
>: different you go with one of the more programmable worlds. But in the end,
>: most of it boils down to what you are comfortable with :)
>I need a driver that will allow me "to do something really different".
>As I'm not familiar with the above architectures, can anyone sum up the
>differences and the strong and weak sides of those drivers, bearing in
>mind my needs (please!)?
>* NetCI
>* LP
>* MOO
>* coolMUD
>* coldMUD
>* TinyMUCK
>* TinyMUSH
>If there are any other implementations that rival those that snooze
>mentioned, please mention them!
>A MUD driver can have many uses, not just for gaming.
>For example, If I only implement a conference room simulation, I have no
>need for commands like "go west", "kill troll" or "cast fireball".
>On the other hand, commands like "agree with speaker", "write statement"
>or "point to 3rd statement on the blackboard" will be used alot.
An LP can be made to do almost anything without ever recompiling the
source. It is much more powerful in terms of calculating power than a MUSH
(the only other type of mud I have had coding experience on) but this is
not always useful. Its problem is that the mudlib language (a derivative of
C) is primarily number based and is poor at string parsing. Writing a
command to accept all sensible instructions requires a lot of thought.
Actually carrying out the task is much easier. Thankfully many commands are
included in standard mudlibs.
Taking your example commands, "agree with person" already exists in most
mudlibs (person can be a name or description) and "agree with speaker" would
not be too difficult to add. There are also bulletin boards and mail
systems which would provide the functionality for "write statement". "Point
to 3rd statement on the blackboard" would be very difficult to do. A
general emote system ("emote points at the 3rd statement on the blackboard")
might suffice evn though it no longer accepts real language.
If you are intending to do things that need a lot of record keeping then an
LP mud is a very good bet, especially if you already know a number based (as
opposed to string or list based) object-oriented programming language. I
have written a sailing system which allows players, and mud controlled ferry
captains, to sail around the ocean, land at islands, even sail up large
rivers. Because of the object approach the code for an individual boat is
quite small; some descriptions and a few numbers for the size and speed. (
mw.cs.washington.edu 3000 and head down the muddy river!) My most graphic
demonstration of the flexibility of LPC are the ascii charts that always
centre on your current position. Several charts, using the same code, can
return completely different pictures in the same room; for instance an ocean
map, an island map, a city map. Trying to keep track and debug all of this
without strict variable types, proper functions, ... would have been
horrible.
Martin
Alex Oren
It sure is difficult to ask a question on Usenet without starting a
magor flamewar!
However, since the subject really interests me, I'll try again.
In article <31049e79...@news.netvision.net.il>, I wrote:
:-----------------------------------------------------------
sno...@nunic.nu.edu (snooze) writes:
hm...@eskimo.com (company account) wrote:
: Hmm. I coded my own MUD entirely from scratch. I started out
: wanting to make something infinetly flexible.. but one has
: to balance flexibility on the universe scale with actual cost
: and benefits.
Right. I want to know the costs but I consider maximum flexibility a
*must* (again, this is for *my* needs!).
: Depending on the method by which a given MUD
: runs the in-game code, it may make quite a bit of sense to have the
: basic player commands hard coded (probably makes the best
: sense in any system really.)
I disagree.
A MUD driver can have many uses, not just for gaming.
For example, If I only implement a conference room simulation, I have no
need for commands like "go west", "kill troll" or "cast fireball".
On the other hand, commands like "agree with speaker", "write statement"
or "point to 3rd statement on the blackboard" will be used alot.
: My personal opinion, is that those who are incapable of making
: changes to the MUD source, shouldn't really be trying to operate
: a public game.
Again, in my case, this does not have to be a game
And certainly not a public one.
: Many admin seem to get all hung-up with
: the process of building a game, and wish to do everything to
: make online building easier - but what if your goal is to present
: a *built* game (the majority of items)? Then it makes less sense
: in the long run to gear everything towards ease of real time
: experimentation at the expense of runtime speed.
Yes, runtime speed is important to me too.
But it is considered "nice to have" whereas flexibility is a must.
Have fun,
Alex
Mical
Hum.. I've been playing with ROM 2.4. Seems to come close to your needs.
I also like TinyMUSH. If your looking for something with out
killing/etc, I would lean to TinyMUSH, as it has less overhead in that
area. If you want socials/stock commands, ROM might be better.... Humm..
I'd get two or three base codes and play with them, see what works best
for you. I'd but ROM 2.4 and the current version of TinyMUSH near the
top of that list to test though. :>
--
Donald M. Bell (Mical, Builder of Boxes.)
Director of Operations
FYI Online
db...@fyionline.com
GCS/J/MD d !H s+:++ g+(-) p2+ au++ a w+ v C++
UL/HPUX/S++++ P+++ L+++ 3 N+++ E--- K
W++(+) M- V- -po+ Y++ t+ 5 j- R+ G? tv+ b+++
D B- e++(+) -u h* f? r- n---- y++++
Miroslav Silovic
> Uhmmm... guys?
>
> As the one who originally posted the question I ask you, please don't
> turn it into a flame war!
>
> Most of the (helpful) comments were about LP.
> How do other systems compare?
> I've seen mention of ColdMud and CoolMud, what about them?
>
I got into this thread a bit late, but here's the answer, for all
it's worth. :)
ColdMUD is still being developped, the main site is cold.org Check
www.cold.org for info, or telnet cold.org 1138 for the
ColdDark. Server/core are currently very near release, the only
missing part being documentation. As for coding and stuff, it's pretty
much like very expanded MOO with builtin multiple ports, file
operations, HTML daemon and external scripts, but it spends
neglectable ammount of CPU and so far we couldn't put it on a db large
enough to make it spend more than 3.5 MB RAM.
Miro / Jenner @ cold
David Bennett
>George Reese (bo...@winternet.com) wrote:
>Check out how much BatMud runs in some time.
Oh, so we take the worst case and generalise from that?
Wonderful argueing tactic.
>If you want examples, go to a software shelf and start pulling titles.
>Compare them with similar titles from 3-5 years ago.
Yes, they do far more than they used to, they cost less, they come in
cuter boxes... Gosh, more functionality. More code.
>Obligatory (if loaded) example: any Microsoft product will have at
>minimum doubled it's RAM requirement, in some cases much more than
>doubled (i.e. MS Word from < 1 meg to > 6 megs).
Another example of taking the worst case and generalising. Microsoft's
problem is not code reuse, rather the opposite. Because of the size of
it's programming team there is a lot of code duplication and code is
written to accept a far greator tollerant level of inputs. This is
what kills it. Code reuse actually creates smaller code, let me
give an example. Do you use function? Do you use procedures?
Oh no! Code reuse in action.
>Optimizing from a coding perspective refers purely to performance issues,
>not coding issues. You know that, I know that, everyone reading this group
>knows that. Claiming that programming fast and loose is an "optimization" is
>hardly valid.
Does it? Optimisation should also take into account such things as
maintainability and ease of modification. Speed of writing is also an
issues, unlessyou happen to have an infinite amount of time. As you
so rightly point out, looking at any one factor blinds you to the
rest. YOu need to look at all the factors together.
>Optimizing does not, however, imply running faster -- you know, I know,
>everyone who reads this group knows that. For example, optimizing for
>speed often means increasing memory requirements, and virtually always
>increases the size of the code (i.e. inlining functions). Optimizing
>for memory usage can often slow down the program (i.e. disk-basing,
>string sharing (in some implementations), eliminating large memory
>structures). And optimizing for executable size similarly will slow
>performance in most programs.
Doesn't this just point to the fact you can also optimise for progrom
maintainability and optimise for programming speed? You seem to have
conviently argued that these factors are not optimisations whilst
actually showing that they can be though of as such. They are all
features of the code, so why can't that feature be optimised? You
could optimise for pretty code too. Code which draws pictures of
frogs, who cares. You can optimise any feature...
>You implied that people designing for my game would need to know how
>to code, I illustrated that that was not the case. That's the point.
>In this case, I knew it, the rest of the group knew it, but you must
>have suffered momentary amnesia.
Ahhh. QUick to abuse, fast with the flick knife. The sign of a
wonderful arguer. This combined with your wonderful skill at pointing
out worst cases should add many arguments to your flame belt.
>You were bandying about reusable code. Mickeysoft products are the
>ultimate example of what that can do to a program.
This is complete rubbish. An operating system is a wonderful
example of reusable code. ALmost any c program is also a wonderful
example. In fact, you would be hard pressed not to have a program
of a decent size that does not resuse code. This reusability
arguement is just stupid, you are argueing non-case.
>If you need an example of the problems with OO, at least with C++,
>compare the performance of a C++ program with a C program some time.
And this shows that c++ is stupid. Very good.
>Of course, there _are_ better OO languages than C++ out there, but
>none in common use, and none that correct the performance problems
>one finds with any use of objects.
>(note: there's certainly things that OO programming is well-suited for.
>However, there are equally certainly things it is not suited for.
>Kinda like trying to use C for an AI project, or LISP for a number-cruncher)
Oh well, very kind. The object paradime is very useful for a lot
of things, it does make maintainabilty of code and the gathering together
of like minded code easier for less experience programmer. I don't
know about you. But i Have seen shockingly wasteful examples of
c code, and I have seen wonderful examples of c++ code. The thing
with a object paradime is it is easier to write reusable, portable
and easier to maintain code.
Lost in a snow storm, without a helmet,
David.
[DDT] Pink fish forever.
--
d...@iinet.com.au - The ends and the means are the same --- Gandhi
- May your Pinkfish never swim backwards.
http://www.iinet.com.au/~ddt
Russell Taylor
> anyway, you're arguing a position that has been dead for some time.
> if you'll take a look at the field of application development, you'll
> see that solutions that consider the productivity level of the humans
> involved to be irrelevant have been most thoroughly outmoded.
Thanks for backing my point -- that current application development
models are responsible for the backwards slide in application quality.
These days, all that matters is getting it on the shelf 6 months to a
year before it should have.
Never mind the fact that most shipping programs are bloated, inefficient
slugs.
Matthew R. Sheahan
> It sure is difficult to ask a question on Usenet without starting a
> magor flamewar!
this is because flame wars are actually the secret purpose for which the
Illuminati created Usenet. things like FAQs are designed to cut down on
the incidence of questions that can be answered without a flame war. this
creates an environment highly hostile to just about any idea, resulting
through Darwinian selection in strong, robust ideas. well, that, and
people getting fed up with the whole mess and going back to TV, where
the continuous insults to your intelligence are merely implicit.
> For *my* purposes, maximum flexibility is a must. A clean design comes
> close second. Of course I'd like an efficient implementaion but that's
> ranked third.
if, as it somewhat implied by your post, you're going to be setting
up a communication space for business applications, you probably want
one of the Tiny family. i think MOO would have the best body of work
in the area behind it -- it's the only one i hear much about people
using in business applications.
of course, i can't bloody stand coding in Tinys. you can expand them,
but either it has to be done in an annoying patchwork fashion or hardly
anyone is intelligent enough to do it any other way. for raw flexibility,
you might want to try something in the LP family... MudOS for its lovely
function pointer syntax or or DGD for its bare-bonedness. i use and enjoy
the Amylaar driver, but if i were starting up a project i'd probably
base it on one of these.
chiaroscuro
Aedil Clah Afaros
: >Erm, you may have followed different classes on computer science or read
: >different books and articles, but optimization hardly ever has anything to
: >do with the time and effort in creation of software. It may help, but the
: >concept of optimizing time and effort in creation is not usually taken as
: >optimization at all. More like common sense, here and there. And almost
: >always in the sense of "we have to spend less time on creating this since
: >the compiler will optimize it properly anyway" as such taking away alot of
: >something. (That does not invalidate the search for the best algorithm.)
: Where as this might be true in Computer Science literature, I can assure
: you out there programming for a company. It does count.
: Companies don't say: Here ius a 'Hello world' program to write,
: take three weeks. Write it as fast as you can.
: They usualy don't give you enough time to properly optimise code. You
: have to write in a way that is understanable and is fast.
Guessing from the .com in my hostname you might realize I am working for a
company and of course in the computer/programming branch of work. It is
true that this implies fast coding and often understandable code is less
of an issue. But still what you say doesn't mean that there is a real
optimization of coding speed and design time, it usually simply means that
less good code is written.
This can hardly be considered "optimization". It is simply a matter of
being pushed into producing code in a fast way. And guess what? The effects
of so-called code-reuse in companies is extremely low compared to what you
might expect from theoretical investigation on the topic. Rather depressing.
Aedil
George Reese
: Matthew R. Sheahan (ch...@crystal.palace.net) wrote:
:
: > anyway, you're arguing a position that has been dead for some time.
: > if you'll take a look at the field of application development, you'll
: > see that solutions that consider the productivity level of the humans
: > involved to be irrelevant have been most thoroughly outmoded.
:
: Thanks for backing my point -- that current application development
: models are responsible for the backwards slide in application quality.
:
: These days, all that matters is getting it on the shelf 6 months to a
: year before it should have.
:
: Never mind the fact that most shipping programs are bloated, inefficient
: slugs.
An how many institutions doing development are CMM level 5 certified?
Last I knew, only 2 were, and they were not companies. The bottom
line is that people are nbot doing what I am preaching, so you can't
point to the problem out there and claim the fault is my solution.
Of course, unless you are using WordStar and Lotus 1-2-3 for DOS, just
shut the fuck up. I love people using Windows 95, Word 7, Excel 7
pining for good old software.
Shawn L. Baird
> jwi...@center.colgate.edu (KRSNA CONSCIOUSNESS NOW) writes:
> >I'm working on a prototype of a compile-and-dynamically-load-style MUD right
> >now, so any pointers to extant implementations would be vastly appreciated.
>
> Compile-and-dynamically-load is an interesting idea, but there are a
> *lot* of major security issues involved in it. Just something to
> think about :)
Hmmm, a lot of major security issues? I tend to disagree. I think
that a small set of things are needed, however:
1. Memory protection so that when the context of the dynamic
code runs, the dynamic code can only write to sections it
owns.
2. Its own thread of execution, with a stack which is both
protected from other stacks and whose stacks are protected
from it.
3. Protected global variables with access permitted only
through access routines, routines which modify the global
variables must be fairly bullet proof.
4. The inability to issue any system calls, making it neccesary
to go through the mud mechanisms in order to do anything.
What should this get you? Well, the ability to write fairly efficient
code (as opposed to any interpreted form), to add code dynamically and
protection from ill-behaved code. In addition, the threads/stack
protection can be extended to cover users and the main code, thus
making it difficult for an individual user to crash the entire mud as
well, since that user maintains a seperate context and the other contexts
are protected from it. More power to Mr. Wilson if he can implement some
of this. I've played around with it enough to know that the idea has
merit. Despite all this, I would suggest that only competent programmers
of some familiarity to you be allowed to work with it, but this is more
because I think you will tend to get a lot of annoying crap than any
serious or effective attempts at breaking your security. For example, I
would not allow direct modification of object/player structures through
this method of coding. Any effects which need this can probably be done
by appropriate means which are better protected (i.e., damage effects,
spell effects, etc.).
Shawn L. Baird
> Hmm. I coded my own MUD entirely from scratch. I started out
> wanting to make something infinetly flexible.. but one has
> and benefits. Depending on the method by which a given MUD
> runs the in-game code, it may make quite a bit of sense to have the
> sense in any system really.)
What I have spent some time contemplating is that the basic rules of
physics are what I believe should be hard coded into the system. For
example, what happens when a rock falls down a well and there are
people around to see it, etc. Build a foundation which applies
reasonable defaults to take some of the effort of constructing them
away from your builders (and yes, take away some of their flexibility
in deference to making sure they don't get too crazy, they can ask if
they need more).
> My personal opinion, is that those who are incapable of making
> changes to the MUD source, shouldn't really be trying to operate
> a public game. Many admin seem to get all hung-up with
> the process of building a game, and wish to do everything to
> make online building easier - but what if your goal is to present
> a *built* game (the majority of items)? Then it makes less sense
> in the long run to gear everything towards ease of real time
> experimentation at the expense of runtime speed.
Well, while I agree that the operation of a serious mud should not be
performed by someone who has no ability to understand the code he or
she works with, I think that your goal should be to both present a
built game and make things as flexible as possible. In addition, I
think enough mechanisms exist to remove the runtime speed barriers of
which you speak (see the articles about designing a compiled language
for a mud).
> -McDaniel -- speaking for himself.
Heya, long time no see.
Scarrow
Matthew R. Sheahan
> These days, all that matters is getting it on the shelf 6 months to a
> year before it should have.
>
> Never mind the fact that most shipping programs are bloated, inefficient
> slugs.
this is a trivial observation. i recommend that if you have such
a problem with it, you stop whining, fire up the assembler (certainly
anything written in a higher-level language would be insufficiently
optimized), and put something better on the shelf.
see you in the twenty-first.
chiaroscuro
Russell Taylor
[RE: bloated code]
> this is a trivial observation. i recommend that if you have such
> a problem with it, you stop whining, fire up the assembler (certainly
> anything written in a higher-level language would be insufficiently
> optimized), and put something better on the shelf.
Actually, a good C compiler optimizes better than most programmers, and
in lower-order time. BTW, spoken like a truly inadequate programmer --
"WHINE, I CAN'T CODE WORTH CRAP, BUT YOU SHOULD USE MY 24 MEG TEXT
EDITOR ANYWAY"
Pity so few computer programmers know how to actually program these days --
most of them would rather babble about concepts that they learned last
week that were actually in use 20 years ago (i.e. almost all of OO programming)
Tim Hollebeek
: Matthew R. Sheahan (ch...@crystal.palace.net) wrote:
: [RE: bloated code]
: > this is a trivial observation. i recommend that if you have such
: > a problem with it, you stop whining, fire up the assembler (certainly
: > anything written in a higher-level language would be insufficiently
: > optimized), and put something better on the shelf.
: Actually, a good C compiler optimizes better than most programmers, and
: in lower-order time. BTW, spoken like a truly inadequate programmer (*)
: "WHINE, I CAN'T CODE WORTH CRAP, BUT YOU SHOULD USE MY 24 MEG TEXT
: EDITOR ANYWAY"
Hmm, I sense a distinct difference between your misquoting of him and
what he actually said. No wonder you think he is an inadequate programmer.
: Pity so few computer programmers know how to actually program these days --
: most of them would rather babble about concepts that they learned last
: week that were actually in use 20 years ago (i.e. almost all of OO programming)
Pity so few MUD programmers can make a point without insulting people
they (as far as I know) don't know [Re: (*) and previous posts of
yours] -- most of them would rather propound at length about the state
of the world without actually saying anything concrete.
BTW, I'd rather hold a discussion with someone who learned a concept
last week, than someone who is too arrogant to admit the concept has
some merit.
---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
<space for rent> | for sufficiently false values of true.
Princeton Univ. | email: t...@wfn-shop.princeton.edu
-------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
Ben Greear
Russell Taylor <rta...@pacinfo.com> wrote:
>
>Pity so few computer programmers know how to actually program these days --
>most of them would rather babble about concepts that they learned last
>week that were actually in use 20 years ago (i.e. almost all of OO programming)
>
>Russ Taylor
Speaking of which, I just learned of heaps and those nice little priority
queues... They seem like the perfect structure to implement an event-
driven MUD, but now I wonder if I would really like an event driven MUD
better than a regularly scheduled game..
Just so we can say this thread deserves to live... Anyone wanna throw
out some pro's and cons and ideas of what you would like an event server
to do? I was thinking of maybe a hybrid system with a heap of events that
would be emptied whenever the MUD goes through the big "while run game"
loop. The big problem seems to be that the processes on the stack can
become outdated by another process...ie a SEGV just waiting to happen
when a future process looks at a player who just logged out.
Any and all comments welcome,
Ben Greear | "More weight." -- The Crucible
gre...@pollux.cs.uga.edu | "Son, you got a pantie on yer head."
Junior at UGA --Raising Arizona
Jonathan Day
>
> Alex Oren (av...@netvision.net.il) wrote:
> > It sure is difficult to ask a question on Usenet without starting a
> > magor flamewar!
>
> this is because flame wars are actually the secret purpose for which the
> Illuminati created Usenet. things like FAQs are designed to cut down on
> the incidence of questions that can be answered without a flame war. this
> creates an environment highly hostile to just about any idea, resulting
> through Darwinian selection in strong, robust ideas. well, that, and
> people getting fed up with the whole mess and going back to TV, where
> the continuous insults to your intelligence are merely implicit.
Almost. You forgot to mention the Illuminati's plan to secretly take over all
the TV stations, thus controlling a captive market and wiping out the opposition
in one go. The Illuminati also secretly run several key Internet providors, thus
allowing them to introduce net lag, for much the same purpose. :)
> > For *my* purposes, maximum flexibility is a must. A clean design comes
> > close second. Of course I'd like an efficient implementaion but that's
> > ranked third.
>
> if, as it somewhat implied by your post, you're going to be setting
> up a communication space for business applications, you probably want
> one of the Tiny family. i think MOO would have the best body of work
> in the area behind it -- it's the only one i hear much about people
> using in business applications.
For /dynamic/ structures, I think that you are almost completely restricted to the
Tiny family. Certainly, I'd not care to write a variant of d-space for an LP-mud.
It also depends on the type of system you want to create. It's possible to set up
videoconferencing reflectors, web servers and FTP servers on a MOO or LP, but I'd
hate to try and use a MUSH. Dunno about using Ubers for this.
For quick construction, though, a MUSH or an Uber is the best bet. The power of MOO
and LP is at the cost of construction time. It's an order of magnitude slower to
develop on MOOs and LPs.
For distributed environments, which is very useful if you're expecting heavy usage
of the complete system, but comparitively light usage of any given section, then you
are almost forced into using an Uber. Cyberportals exist for the other systems, but
they are comparitively primitive and are almost universally client-side, not server-
side.
> of course, i can't bloody stand coding in Tinys. you can expand them,
> but either it has to be done in an annoying patchwork fashion or hardly
> anyone is intelligent enough to do it any other way. for raw flexibility,
> you might want to try something in the LP family... MudOS for its lovely
> function pointer syntax or or DGD for its bare-bonedness. i use and enjoy
> the Amylaar driver, but if i were starting up a project i'd probably
> base it on one of these.
Horses for courses. I like coding in Tiny and consider some of its oddities as quite
nice. Mind you, none of these systems are particularly well-designed. That's no
reflection on the coders, many of whom are no doubt excellent, but mu* design, on the
whole, seems to work on a 'that would be nice' basis, with much redundancy and more
than a litle wooly coding.
The first thing on any project, though, is to work out what it is that you actually
want to do. (Yes, I know I'll probably be lynched for that, but no-one'll notice the
difference. :) Each driver has strengths and weaknesses and none (not even the very
old drivers!) are perfect. Others will no doubt rip to shreds my summary above, but
that's the nature of the net. But on no accounts pick a system /before/ you specify
the project in some more formal way, or you risk finding that the one thing you need
most is the one thing that you can't do on that system.
Jonathan
Jonathan
Ben Greear
>Ben Greear (gre...@pollux.cs.uga.edu) wrote:
>
>: Just so we can say this thread deserves to live... Anyone wanna throw
>: out some pro's and cons and ideas of what you would like an event server
>: to do? I was thinking of maybe a hybrid system with a heap of events that
>: would be emptied whenever the MUD goes through the big "while run game"
>: loop. The big problem seems to be that the processes on the stack can
>: become outdated by another process...ie a SEGV just waiting to happen
>: when a future process looks at a player who just logged out.
>
>however if you do things like that on a regular basis you are going to
>run into problems whether your server is event driven or not. There
>are a number of trivial fixes to the problem, probably the least error
>prone of which is using something like a unique player id instead of a
>pointer, along with an appropriate lookup scheme, instead of a raw
>pointer. Or your can just reference count your players, but then you
>have to make sure you always keep the counts right.
>
>---------------------------------------------------------------------------
>Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
This would fix the problem with pc's, but mobs and objects and even rooms
remain a more complicated problem.... And not just when they are logically
deleted from the game. Even if they just move from room to room, it could
make for some really complicated error checking in EVERY function, or at
least it seems so to me.
Even supposing you got the event driver working just right... what would
be some novel uses of it? Like uses that are hard/impossible to
mimic w/a regular implementation (ie like circle).
I wouldn't mind doing the extra work if I could find a good reason :)
Tim Hollebeek
: Just so we can say this thread deserves to live... Anyone wanna throw
: out some pro's and cons and ideas of what you would like an event server
: to do? I was thinking of maybe a hybrid system with a heap of events that
: would be emptied whenever the MUD goes through the big "while run game"
: loop. The big problem seems to be that the processes on the stack can
: become outdated by another process...ie a SEGV just waiting to happen
: when a future process looks at a player who just logged out.
If you're carrying around pointers to data that might be freed, sure;
however if you do things like that on a regular basis you are going to
run into problems whether your server is event driven or not. There
are a number of trivial fixes to the problem, probably the least error
prone of which is using something like a unique player id instead of a
pointer, along with an appropriate lookup scheme, instead of a raw
pointer. Or your can just reference count your players, but then you
have to make sure you always keep the counts right.
---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Matthew R. Sheahan
> Matthew R. Sheahan (ch...@crystal.palace.net) wrote:
> > this is a trivial observation. i recommend that if you have such
> > a problem with it, you stop whining, fire up the assembler (certainly
> > anything written in a higher-level language would be insufficiently
> > optimized), and put something better on the shelf.
> Actually, a good C compiler optimizes better than most programmers, and
> in lower-order time.
christ on a bike. is it my imagination, or were Descartes and i just
arguing in favor of tools which HANDLE THINGS FOR YOU and increase coder
productivity? is there any internal consistency to your arguments, or
are you just posturing for the sake of posturing?
> BTW, spoken like a truly inadequate programmer (*)
> "WHINE, I CAN'T CODE WORTH CRAP, BUT YOU SHOULD USE MY 24 MEG TEXT
> EDITOR ANYWAY"
oh, i'm sorry. i mistook you for someone with basic reading comprehension
skills. don't worry, it won't happen again.
chiaroscuro
Tim Hollebeek
: For quick construction, though, a MUSH or an Uber is the best bet. The power of MOO
: and LP is at the cost of construction time. It's an order of magnitude slower to
: develop on MOOs and LPs.
I think the characterization of development time is unfair. The main
reasons LPs tend to spend more time in development are:
(1) something unique is being created, which takes a while (and would
take as long or longer to hack into a MUSH server)
(2) the people just like coding, and are rewriting the wheel for fun.
(3) MUSHs tend to open small and grow, which LPs tend to have to
acquire a critical mass of areas before being able to open. This
really has less to do with the server than with traditional uses
for each, though (social vs game).
I won't say much more about #2, but it is very common :-) Anyway,
with the arrival of 'ready to run' (more or less) mudlibs lately, some
LPs have gone through rather (IMO extremely) short development cycles.
Your original comparison is really between apples and oranges. The
two things you are comparing are:
(1) a MUSH where the behavior you want exists, and the database just
needs to be built
vs.
(2) a LP or MOO with no code
Which isn't fair. A fairer comparison is either:
[first the case where your application isn't like most other MUSHs/MOOs/MUDs]
(1) a MUSH server which will have to be modified in C to do what you
want
(2) an LP/MOO server which needs no editing in C, but needs LP/MOO
code that does what you want.
In this case, LP/MOO will take less time to construct simply because
you are using a higher level language that lets you worry about MUD
construction issues instead of debugging C code. [assuming equally
skilled programmers; if you don't know LP/MOO, but know C, obviously
the learning curve factors into only one side of the eqn, which might
tip the balance]
[second the case where your application is close to most other
MUSHs/MOOs/MUDs]
(1) build the rooms, etc for a MUSH server
(2) build the rooms, etc for a LP/MOO server with prepackaged code
that does what you want.
Here, it really comes down to comparing what is available to start
with, although the LP/MOO approach has the advantage that if what
exists is close, but not exactly what you want, it is easier to
tweak/modify it (using essentially the same arguments as above).
Of course, this entire discussion assumes that flexibility is the
primary goal. If you have other needs, other things might fit better.
: Cyberportals exist for the other systems, but
: they are comparitively primitive and are almost universally client-side, not server-
: side.
... which can be argued to be a good thing, but that's a topic for
another thread.
Chris Lawrence (Contra)
...
: For distributed environments, which is very useful if you're expecting heavy usage
: of the complete system, but comparatively light usage of any given section, then you
: are almost forced into using an Uber. Cyberportals exist for the other systems, but
: they are comparatively primitive and are almost universally client-side, not server-
: side.
You might also like to look at CoolMud and I think ColdMud. They do a server-side
pass-thru which allows a remote object heriarchy to operate on a local system.
Quite simply done really, tho it can be net bandwidth expensive between the
distributed nodes.
I suspect (have not checked) that the ColdX project does something similar.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
Chris Lawrence (Contra)
...
: Just so we can say this thread deserves to live... Anyone wanna throw
: out some pro's and cons and ideas of what you would like an event server
: to do? I was thinking of maybe a hybrid system with a heap of events that
: would be emptied whenever the MUD goes through the big "while run game"
: loop. The big problem seems to be that the processes on the stack can
: become outdated by another process...ie a SEGV just waiting to happen
: when a future process looks at a player who just logged out.
I've been working partially along this line. The concept I've sort of
settled about currently is reliant on a light-overhead threading model
(mostly because that what I work on).
Essentially a dispatcher thread monitors a list of potential processes.
New process candidates may be added to the list by any currently
existant process (eg when a player types a command the player thread
puts a new process entry on the list to do the command). Each process
list entry has a very simplistic condition which must be met before it
is invoked (eg time >= X, or random value within range Y). When the
condition is met the dispatcher hands the proces specifics off to an
executor thread which launches the process in its own thread.
The executor is responsible for monitoring its child thread states,
terminating any process which becomes blocked, crashes, takes too long
etc.
Database consistancy is maintained using a rip-off of the system Deimos
proposes for the DOME project: Each action modifies local copies of all
state variables only, and buffers all IO. At process compleation the
current DB values of all state variables are compared to their values
at process start. If they are (all) the same, then the new values are
copied to the DB from the process store and all IO is released. If they
are not all the same, then the process is terminated and re-invoked for
a second attempt. Endless attempt loops are (partially) prevented by
scheduling and local process/thread priorities.
Data dating and race condition problems, such as the one you mention
with the target user being logged off by the time the process is
invoked are handled by using a strictly message based system for DB
object communication. There is no direct manipulation of DB records
by a process (thread). Instead messages are sent to the target
object requesting the requisite change. It is up to the recipient
object to determine how it wishes to respond.
Actually the database correctness checks are not done on a per state
variable basis, but rather a local copy of the entire object is
compared to the master DB copy.
Patrick Bennett
>Even supposing you got the event driver working just right... what would
>be some novel uses of it? Like uses that are hard/impossible to
>mimic w/a regular implementation (ie like circle).
>
>I wouldn't mind doing the extra work if I could find a good reason :)
>
>Ben Greear | "More weight." -- The Crucible
>gre...@pollux.cs.uga.edu | "Son, you got a pantie on yer head."
>Junior at UGA --Raising Arizona
The main benefit would be the multi-threaded benefits you could apply
w/ an event-driven system. If you design it well, it would scale
extremely well, but given the exceptions that would have to be dealt
with in an entirely even-driven system, the overhead might be too high
to make it worthwhile.
In my C++ mud, I use the Poet Object-Database for all objects, thus
all persistent objects are already reference-counted, and the only
objects that are 'in memory' at any given time are: all npcs,
user-characters, the objects they're carrying (w/ associated
triggers,scripts,etc. [which are just part of an objects container]),
the rooms they're in, and the objects w/in the rooms. If there were
200 users ACTIVE w/ maybe 500 npc's, the in-memory overhead would
still be extremely low, yet given the nature of the database, the
'world' could be absolutely enormous with no significant speed
problems (indexes, etc.)
Right now, all I/O for user's and the game 'heartbeat' are run as
separate threads for efficiency. Each user has their own separate i/o
thread w/ an input queue and an output queue so the game 'engine' is
never waiting/handling input or output for any character. The ONLY
time the game engine is busy is when a mobile or user actually >DOES<
something. Given that the mobiles are all fed off the separate
'heartbeat' thread, and that users all have separate i/o queues w/in
separate threads, it's still quite efficient without having to deal w/
the nightmare issues that having a 100% event-driven system would
entail.
-------------------------------------------
Patrick Bennett
Acraline Products, Inc.
pben...@acraline.com / CIS: 74103,2115
Chris Lawrence (Contra)
: Well, I find it hard to comprehend why someone would go to all the trouble
: to make a perfectly capable event-handling mud base not only OS specific,
: but multi-processed.
Factually I don't care about OS and platform portability for my MUD code.
I realise this is heretical in the MUD world, but I'm not doing this for
some vaunted "for the greater MUD good" reason. I'm doing it as a proof
of concept, and a decent exercising of my prefered platform. 'Nuf said.
: It's quite easy to write an efficient events handler
: in a single threaded program. Ideas like doing a database save in the back-
: ground can be done easily in one thread, especially with the constant loop that
: most muds focus around. As for objects that pass an event to another object,
: this can be done efficiently with an events structure, or even better, a
: hashed list of events/times/etc...
If implementation coding ease is one of your design goals, this is true.
I would much rather invest effort and difficulty into the server design
and implementation for the sake of simplifying and abstracting the
MUD-side implementation. I really don't want the user-programmers to
have to worry about race conditions, resource locks, task completion
time etc. Let the server worry about that and do its darndest to get the
user-code executed in some semblance of order.
Moving the MUD implementation to a fairly rigorous message based OO design
makes a whole heap of things easier (I leave arguments on details like
single vs multiple inheritance out of this). Once you are working with a
message based design, abstracting the server implemention to a multi-
threaded or multi-processing base becomes very inviting. Further, going
this route allows (slightly elegant) opportunities to try and escape many
of the classic problems of user-written MUD code (resource locks, race
conditions, hangs, timeouts, piggy user code hogging the server etc).
I really really don't see any reason why the user-programmers should
be concerned with writing what is essentially cooperative multi-tasking
code. Again, the server should take care of all of that.
None of this is to say that it _can't_ be done with a classical single-
threaded polled-loop event driver, its just easier and more maintainable
(IMO) to provide a simple system to the user if you move away from there.
: It just seems like going to all of this
: work to do something that can already be done efficiently, retain multi-
: operating system compatibility, and use less resources is moderately
: pointless (although I must admit, it sounds like a fun challenge).
Point taken. You'll note that I'm mostly doing this for me. The resource
consumption angle is arguable. It really depends on the model your
platform follows. Occam/Hermes for instance would likely require very
minor overhead for the added gain.
: As a
: comparison, doing a quick passthrough of the events list to terminate all
: events using that object or player is quite speedy, while checking at every
: step of the way if the object exists (inter-process) is excrutiatingly painful.
Whoa! Ugly!
Consider the following:
User A starts an action which will affect user B directly, but is
not currently being executed (it is on the list to be processed).
User B is an indirect target of the action (ie he isn't named in the
action definition). eg User A pulls trigger on gun which is magically
charmed to only shoot User B.
The action and indirect result of the action are defined in the MUD
code as one event. eg The "pull trigger" verb also inline executes
the "shoot User B" action without placing another event on the list.
(No arguments about badly written code please).
User B logs out.
User A's action is now scheduled for execution.
The system is now supposed to resolve all references in all the MUD code
for all pending events to see if any would have affected User B? You
can't just scan the direct event references -- User B isn't mentioned
in the "pull trigger" event. Its only implicit in the state of the
"pull trigger" internals...
Yech. You have to account for implicit state information and that is a mess.
Yup, scattering your code at every reference with "Does this object still
exist?" calls is ugly. However move to message passing, let the target
object resolve its own existance and availability, and provide a simple
message based exception processor and the user-level code cleans up
quite a bit.
: For instance, if you have a function deallocate_character(CHAR_INFO *chr),
: it's a lot easier scanning through the linked list of events, checking if
: any involve the info stored at &chr than it is to check later on something
: like char_exists_y_n(CHAR_INFO *chr) (which is hard to do in itself).
Ignoring the arguments about language formation and syntax, how about:
objectXXX::methodYYY (args) // Object XXX no longer exists at this instant
// and as such returns, say, an E_NOOBJ exception
.
. // more MUD code
.
exception E_NOOBJ { // Unhandled exception unfolds the stack until it
... // finds an exception handler or the action is exited.
}
or if certain exceptions are non-fatal:
accept (E_NOOBJ | E_BURP | E_FART, objectXXX::methodYYY (args))
Owen Emlen
Chris Lawrence (Contra) <claw...@xsvr1.cup.hp.com> wrote:
>Whoa! Ugly!
>
>Consider the following:
>
> User A starts an action which will affect user B directly, but is
> not currently being executed (it is on the list to be processed).
>
> User B is an indirect target of the action (ie he isn't named in the
> action definition). eg User A pulls trigger on gun which is magically
> charmed to only shoot User B.
>
>
> User B logs out.
---> A simple, single passthrough of the events list takes place when the
logout procedure is called. The way this is handled on my mud is that the
every "object" (player/object/room/etc) is contained in a structure
containing a union and a type sh_int identifier (stating the typedef the
pointer to this memory location is). The event stores a linked list of
these used "objects". For instance:
structure obj with typedef OBJ
------------------------------
sh_int type 1 <-- in my case, this is used for PLAYER_OR_MOB
void * object
OBJ * next_obj_involved_with_the_event
------------------------------
This is 10 bytes.. a hell of a lot smaller than doing it using an OO
language like C++. My logout call simply contains the function to scan
through the list, and look for any type ONE (player_or_mob) "objects".
When done, void * object points to the location (and I know it's of type
char_structure). I check the name to see if this event involves the
character who is quitting, and if it does, I remove the event from the
linked list. Please see after the below quoted text for a comparison...
>
> User A's action is now scheduled for execution.
----> Not any more.. the event was removed when B quit out!
> The system is now supposed to resolve all references in all the MUD code
> for all pending events to see if any would have affected User B? You
> can't just scan the direct event references -- User B isn't mentioned
> in the "pull trigger" event. Its only implicit in the state of the
> "pull trigger" internals...
----> Pull trigger doesn't get an event.. it's a user command. It looks
at the object, and the object sets up all events at that time. Every
event involving player B and the object has a list that contains 3 of my
ten-byte object structures... one that points to the object that
triggered the event, one that points to the person who performed the
event, and one that points to the person that the action involves. Going
more in depth than that is like buying McDonalds so you can have a slice
of swiss cheese on your hamburger!
>
>Ignoring the arguments about language formation and syntax, how about:
>
> objectXXX::methodYYY (args) // Object XXX no longer exists at this instant
> // and as such returns, say, an E_NOOBJ exception
> .
> . // more MUD code
> .
> exception E_NOOBJ { // Unhandled exception unfolds the stack until it
> ... // finds an exception handler or the action is exited.
> }
>
>or if certain exceptions are non-fatal:
>
> accept (E_NOOBJ | E_BURP | E_FART, objectXXX::methodYYY (args))
UGH! This is *EXACTLY* what I am trying to avoid... exception checking
has to be done somewhere, and having C++ do the exhaustive flag-sending
huge, bloated object OOP thing to check is just plain insane! It could
be done, but I figure it would take up 3-5 times the memory and 2-3 times
the cpu, at least. Not to mention that the structures are larger, which
is *very* critical when you commonly have 7000-10,000 objects in the world
at once. I see your point, although this is a case, IMO, where OOP would
be so rediculously inefficient, simply to add a human-based concept, that
it just wouldn't be worth it.
Owen Emlen
Owen Emlen
to make a perfectly capable event-handling mud base not only OS specific,
in a single threaded program. Ideas like doing a database save in the back-
ground can be done easily in one thread, especially with the constant loop that
most muds focus around. As for objects that pass an event to another object,
this can be done efficiently with an events structure, or even better, a
work to do something that can already be done efficiently, retain multi-
operating system compatibility, and use less resources is moderately
comparison, doing a quick passthrough of the events list to terminate all
events using that object or player is quite speedy, while checking at every
step of the way if the object exists (inter-process) is excrutiatingly painful.
it's a lot easier scanning through the linked list of events, checking if
any involve the info stored at &chr than it is to check later on something
like char_exists_y_n(CHAR_INFO *chr) (which is hard to do in itself).
Owen Emlen (aka Orin)
Russell Taylor
> Speaking of which, I just learned of heaps and those nice little priority
> queues... They seem like the perfect structure to implement an event-
> driven MUD, but now I wonder if I would really like an event driven MUD
> better than a regularly scheduled game..
I've thought about this issue myself. Current Dikus are pseudo-event
driven (pulses), but true event-driving allows some nice flexibility
in terms of delayed command execution and game response.
> Just so we can say this thread deserves to live... Anyone wanna throw
> out some pro's and cons and ideas of what you would like an event server
> to do? I was thinking of maybe a hybrid system with a heap of events that
> would be emptied whenever the MUD goes through the big "while run game"
> loop. The big problem seems to be that the processes on the stack can
> become outdated by another process...ie a SEGV just waiting to happen
> when a future process looks at a player who just logged out.
* pros: no need to have mass-processing of all game objects
allows delayed response more gracefully
allows for a better simulation of falling (acceleration :)
* cons: higher processing overhead per event
sanity checking
Probably more on both than I'm thinking of right now.
I'd probably add a "purge" event that will purge all pending events for
that object from the event queue (or heap).
Russell Taylor
Distribution: inet
X-Newsreader: TIN [version 1.2 PL2]
Matthew R. Sheahan (ch...@crystal.palace.net) wrote:
> christ on a bike. is it my imagination, or were Descartes and i just
> arguing in favor of tools which HANDLE THINGS FOR YOU and increase coder
> productivity? is there any internal consistency to your arguments, or
> are you just posturing for the sake of posturing?
No, you were arguing for tools that would increasing program speed but
decrease program efficiency. I'm arguing for tools that increase program
efficiency. Hand-coding assembler just happens to not be one of those
things.
Got logic problems?
> oh, i'm sorry. i mistook you for someone with basic reading comprehension
> skills. don't worry, it won't happen again.
I think I'm getting your point just fine: you think anything that lets you
program faster is good. I disagree.
After all, if writing speed were all that mattered, we'd all be using
Visual Basic and Hypercard.