ADMIN: Update of stock/scratch analysis

[Greg Munt]

This has now been updated to encompass the comments provided by Matt
Chatterley and Katrina McClelan. Is there any reason why pro-stock people
never commented on this?

I am hoping that this might be a way of presenting arguments from both
sides of the stock/scratch debate, without bias, and without noise.

I *do* want it to be a balanced analysis.

Advantages of stock muds
~~~~~~~~~~~~~~~~~~~~~~~~
* Anyone can setup a stock mud with little or no problems

* People with strong ideas, but lacking coding ability, can create a
richly described and interesting world

* Do not have to spend time conceptualising your own design, before
opening - what is the point of a mud which no-one can play?

* The 'framework' is provided for you; you can concentrate on creating
the mud, rather than worrying about socket code, or TELNET protocol

* Can share ideas, design, implementations, with other stock mud
implementors - where to go to share them is well-known, and possibly
at the same site that you downloaded your mud from

* Can start a mud with a large world, without having to put lots of
work into it, before it opens

* Can open a mud whenever you choose to, and let the eager players pour
in - players are what a mud is all about, after all!

* Provides a working code base from which you can learn from

* Can insert implementations, written by other stock mud implementors,
into your own mud - providing popular features, and thus attracting more
players

* A predefined way of specifying an area, within a predefined building
standard - speeding up world development

Disadvantages of stock muds
~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Unless you want to spend a LOT of time (perhaps more time than would
be required to write the mud from scratch) on mud development, your
vision of the mud must fall within the vision of the implementor of your
codebase

* Anyone can setup and run a stock mud

* Little or no documentation

* Without coding knowledge, maintenance ranges from difficult to impossible

* Development restricted by legacy design

* Rate of learning adversely affected by legacy design

* Legacy design may teach bad skills

* The code is very often an example of how NOT to go about things, and
can be a bad tutor to the unwary

* Often have to hack the code to get it to do what you want it to do -
not easy to rewrite a single section of the code, since many sections
depend on one-another; often new code is layered on top of poor stock
code

* Frequently there is poor (if any) modularisation

* Often, implementors do not have an appreciation/knowledge of the entire
code - they are familiar only with parts that they have changed

* Your advertisements to the mud newsgroups will be ritually flamed by
scratch mud disciples

* Can insert unmodified implementations, written by other stock mud
implementors, into your own mud - decreasing the differences between
your mud, and others

* Can start a mud with a large world, without having to put lots (or
ANY, in fact) of work into it, before it opens - the world can be
'copied' from a public source, decreasing the differences between your
mud, and others

Advantages of scratch muds
~~~~~~~~~~~~~~~~~~~~~~~~~~
* No design baggage

* Do not have to spend time learning someone else's design

* Do have to spend time conceptualising your own design

* Can quickly and easily implement new ideas, or new approaches to old
ideas

* Encourages you to learn a lot of things, fast

* You may be writing your mud for the rest of your life! *rubs hands
with glee*

* Encourages you to learn the entire implementation language, and not
simply a subset of it

* Changes result in old code being redesigned and reworked, with
additions, rather than 'code layering'

* Encourages you to think independently of 'the field'; the wider your
experiences, the higher the chance of this

* Encourages you to consider a variety of (not neccessarily
specific to muds) design techniques; a non-mud background is of great
benefit here

* Additions are 'cleaner' - no hacks - and are part of a long-term
design vision, rather than something hacked into someone else's
design

* Your ideas are so different (and superior) to what is 'accepted', that
they further the evolution of muds in a very real way

Disadvantages of scratch muds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Nothing to work from at all - early versions will perhaps be
inevitably poor

* Takes months (years, more likely) to get a decent mud

* You may be writing your mud for the rest of your life - it may never
open!

* There is so much to learn, that you may give up on creating a mud
altogether

* Have to write the documentation for everything, yourself

* No defined way of specifying an area - increasing development time

* No building standard - increasing development time

* Development is very slow before the 'framework' is designed and
implemented

* Someone on the team (or you) needs to be able to code well

* Stock mud disciples will demand to know what you can add to muds that
a stock mud can't ("There can be no new ideas", etc)

* Your ideas are so far-out that players can't comprehend them

STOCK ADVANTAGES: 10. SCRATCH ADVANTAGES: 12.
STOCK DISADVANTAGES: 14. SCRATCH DISADVANTAGES: 11.

-------------------------------------------------------------------------------
"Scratch muds can only ever be leaves of The Mud Tree."
Discuss, using obscure references.

[Katrina McClelan]

In <5ssi9t$s5i$3...@darla.visi.com> George Reese <bo...@imaginary.com> writes:

>: Disadvantages of stock muds

>: ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>: * Unless you want to spend a LOT of time (perhaps more time than would
>: be required to write the mud from scratch) on mud development, your
>: vision of the mud must fall within the vision of the implementor of your
>: codebase

>This is a limit of bad code bases.

>: * Anyone can setup and run a stock mud

>This is not a bad thing. What is a bad thing is that 'people who have
>put little thought into running a mud can run a stock mud'.

Ok, but you're saying the same thing: Anyone (not just those that
put thought into running a mud) can setup and run a stock mud... then
again, I can argue anyonme based on all the "Help compiling" posts.

>: * Little or no documentation

>Little or no documentation? Huh?

Status Quo, this is true; I suppose the idealist can argue that it
shouldn't be, but it is.

>: * Without coding knowledge, maintenance ranges from difficult to impossible

>Depends on the code base and the goals of the code base.

...and the problems that surface...

>: * Development restricted by legacy design

>Only in a bad code base.

You're crazy. When you write any program of 30k plus lines, a good chunk
of it makes assumptions on other parts of it. Good programming or not,
somewhere you have to write code based on what you want and not what Jim
Bob wants, and when you do this over 30-40k of code cleaning it up to
reuse in another fashion can range from very annoying to not even worth
doing.

>: * Rate of learning adversely affected by legacy design

>: * Legacy design may teach bad skills

>Only in a bad code base.

Again George (of all people) is being the idealist.

>: * The code is very often an example of how NOT to go about things, and

>: can be a bad tutor to the unwary

>Only in a bad code base.

ditto

>: * Often have to hack the code to get it to do what you want it to do -

>: not easy to rewrite a single section of the code, since many sections
>: depend on one-another; often new code is layered on top of poor stock
>: code

>Only in a bad code base.

This is simply not true (see above). There are three ways to make code do
something that the original designers never intended to do (unless your
very lucky and the avenue is left open). You can start over. You can
rewrite so much of the code that you might as well have started over. You
can hack it on top. Obviously the more trivial the addition or change the
less this applies, but to make massive feature adds or (especially)
changes, you very frequently have a major problem.

>: * Your advertisements to the mud newsgroups will be ritually flamed by
>: scratch mud disciples

>Sounds like a personal problem of the scratch mud people.

I can agree with this to some extent... on the other hand once you release
a stock code base you'll get 50 idiots posting "stock mud advertisements"
for every one person that has a clue. That's really more the problem. If
you start with "StockCode Zeta", and lets say you have a clue and do a
decent job. You'll still be associated with all the idiots that decide
that it'd be "kewl" to run a mud and don't have the foggiest how to do it.

>: * Your ideas are so different (and superior) to what is 'accepted', that

>: they further the evolution of muds in a very real way

>This one is ridiculous :) Sounds like elitist bullshit from Katrina.

For starters, I'd agree that the point is mis-worded. It needs to read
"Your ideas can be..." That said, the point above does sound elitist,
until you add the "can be". The truth is that new advances are only made
when people give up on thinking about old ways of doing things and start
over.

>: * Stock mud disciples will demand to know what you can add to muds that

>: a stock mud can't ("There can be no new ideas", etc)

>Again, a personal problem, this time with the stock mud people :)

Well, the ball bounces both ways ;)

>: STOCK ADVANTAGES: 10. SCRATCH ADVANTAGES: 12.

>: STOCK DISADVANTAGES: 14. SCRATCH DISADVANTAGES: 11.

>This ticker is silly.

I agree with that. pro/con can't be enumerated on a 1 to 1
correspondance. Some (dis)advantages wiegh heavier than others.

>Also, scracth disadvatange: you are reinventing the wheel, which is an
>extremely bad programming habit.

I have addressed this before. It's like using a wooden carriage wheel
when you envision Goodyear Radials. Sometimes reinventing the wheel is a
good thing. Imagine if we had decided the eniac was as good a computer as
you can make and never reinvented it. (LP would NEVER have run on
anything with that lack of power (tounge in cheek)). Rewritting identical
code is a waste of time and bad programming. Writting a better program
that does the same (general) thing is not nessecarily bad. If we listened
to George all games would be pacman with different maze maps and
variations off of ghosts and the chomping ball.

-Katrina

[George Reese]

The main problem I see here is using bad code bases as the measurement
of the strengths and weaknesses of stck code. I think you should
assume a decent quality code base before assessing the strengths and
weaknesses of the concept of stock code.

Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: This has now been updated to encompass the comments provided by Matt

: Chatterley and Katrina McClelan. Is there any reason why pro-stock people
: never commented on this?

: I am hoping that this might be a way of presenting arguments from both
: sides of the stock/scratch debate, without bias, and without noise.

: I *do* want it to be a balanced analysis.

: Advantages of stock muds
: ~~~~~~~~~~~~~~~~~~~~~~~~
: * Anyone can setup a stock mud with little or no problems

: * People with strong ideas, but lacking coding ability, can create a
: richly described and interesting world

: * Do not have to spend time conceptualising your own design, before
: opening - what is the point of a mud which no-one can play?

A good stock mud does not support this. Anyone starting a mud should
have spent some time designing their world before hand.

: * The 'framework' is provided for you; you can concentrate on creating

: the mud, rather than worrying about socket code, or TELNET protocol

: * Can share ideas, design, implementations, with other stock mud
: implementors - where to go to share them is well-known, and possibly
: at the same site that you downloaded your mud from

: * Can start a mud with a large world, without having to put lots of
: work into it, before it opens

: * Can open a mud whenever you choose to, and let the eager players pour
: in - players are what a mud is all about, after all!

: * Provides a working code base from which you can learn from

: * Can insert implementations, written by other stock mud implementors,
: into your own mud - providing popular features, and thus attracting more
: players

: * A predefined way of specifying an area, within a predefined building
: standard - speeding up world development

: Disadvantages of stock muds
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~
: * Unless you want to spend a LOT of time (perhaps more time than would
: be required to write the mud from scratch) on mud development, your
: vision of the mud must fall within the vision of the implementor of your
: codebase

This is a limit of bad code bases.

: * Anyone can setup and run a stock mud

This is not a bad thing. What is a bad thing is that 'people who have
put little thought into running a mud can run a stock mud'.

: * Little or no documentation

Little or no documentation? Huh?

: * Without coding knowledge, maintenance ranges from difficult to impossible

Depends on the code base and the goals of the code base.

: * Development restricted by legacy design

Only in a bad code base.

: * Rate of learning adversely affected by legacy design

: * Legacy design may teach bad skills

Only in a bad code base.

: * The code is very often an example of how NOT to go about things, and

: can be a bad tutor to the unwary

Only in a bad code base.

: * Often have to hack the code to get it to do what you want it to do -

: not easy to rewrite a single section of the code, since many sections
: depend on one-another; often new code is layered on top of poor stock
: code

Only in a bad code base.

: * Frequently there is poor (if any) modularisation

Only in a bad code base.

: * Often, implementors do not have an appreciation/knowledge of the entire

: code - they are familiar only with parts that they have changed

: * Your advertisements to the mud newsgroups will be ritually flamed by
: scratch mud disciples

Sounds like a personal problem of the scratch mud people.

: * Can insert unmodified implementations, written by other stock mud

: implementors, into your own mud - decreasing the differences between
: your mud, and others

Very good point.

: * Can start a mud with a large world, without having to put lots (or

: ANY, in fact) of work into it, before it opens - the world can be
: 'copied' from a public source, decreasing the differences between your
: mud, and others

Another EXCELLENT point.

: Advantages of scratch muds

: ~~~~~~~~~~~~~~~~~~~~~~~~~~
: * No design baggage

: * Do not have to spend time learning someone else's design

: * Do have to spend time conceptualising your own design

: * Can quickly and easily implement new ideas, or new approaches to old
: ideas

: * Encourages you to learn a lot of things, fast

: * You may be writing your mud for the rest of your life! *rubs hands
: with glee*

: * Encourages you to learn the entire implementation language, and not
: simply a subset of it

: * Changes result in old code being redesigned and reworked, with
: additions, rather than 'code layering'

: * Encourages you to think independently of 'the field'; the wider your
: experiences, the higher the chance of this

: * Encourages you to consider a variety of (not neccessarily
: specific to muds) design techniques; a non-mud background is of great
: benefit here

: * Additions are 'cleaner' - no hacks - and are part of a long-term
: design vision, rather than something hacked into someone else's
: design

: * Your ideas are so different (and superior) to what is 'accepted', that
: they further the evolution of muds in a very real way

This one is ridiculous :) Sounds like elitist bullshit from Katrina.

: Disadvantages of scratch muds

: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: * Nothing to work from at all - early versions will perhaps be
: inevitably poor

: * Takes months (years, more likely) to get a decent mud

: * You may be writing your mud for the rest of your life - it may never
: open!

: * There is so much to learn, that you may give up on creating a mud
: altogether

: * Have to write the documentation for everything, yourself

: * No defined way of specifying an area - increasing development time

: * No building standard - increasing development time

: * Development is very slow before the 'framework' is designed and
: implemented

: * Someone on the team (or you) needs to be able to code well

: * Stock mud disciples will demand to know what you can add to muds that
: a stock mud can't ("There can be no new ideas", etc)

Again, a personal problem, this time with the stock mud people :)

: * Your ideas are so far-out that players can't comprehend them

: STOCK ADVANTAGES: 10. SCRATCH ADVANTAGES: 12.
: STOCK DISADVANTAGES: 14. SCRATCH DISADVANTAGES: 11.

This ticker is silly.

Also, scracth disadvatange: you are reinventing the wheel, which is an
extremely bad programming habit.

--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
"In our fear, we make an image, and that image we call God."
Antonius Block in The Seventh Seal

[Matt Chatterley]

On 13 Aug 1997, George Reese wrote:

> Katrina McClelan <kit...@directcheck.aries.net> wrote:

> : In <5ssi9t$s5i$3...@darla.visi.com> George Reese <bo...@imaginary.com> writes:
>
> : >: Disadvantages of stock muds
> : >: ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> : >: * Unless you want to spend a LOT of time (perhaps more time than would
> : >: be required to write the mud from scratch) on mud development, your
> : >: vision of the mud must fall within the vision of the implementor of your
> : >: codebase
>
> : >This is a limit of bad code bases.
>
> : >: * Anyone can setup and run a stock mud
>
> : >This is not a bad thing. What is a bad thing is that 'people who have
> : >put little thought into running a mud can run a stock mud'.
>
> : Ok, but you're saying the same thing: Anyone (not just those that
> : put thought into running a mud) can setup and run a stock mud... then
> : again, I can argue anyonme based on all the "Help compiling" posts.
>

> Then clearly not anyone can put up a stock mud base.

Yes. Although saying that anyone can put up a stock base with
(comparitively) little experience/skill/ingelligence is probably fair
enough (as a generalisation though!)

> Those people who ask for help compiling could just as well ask for
> help in coding the thing from scratch.

Asking for help compiling something really shows a complete lack in terms
of desire to learn - is it really that hard to find docs on compilers,
etc? (Semi rhetorical question, I guess).

> : >: * Little or no documentation

>
> : >Little or no documentation? Huh?
>
> : Status Quo, this is true; I suppose the idealist can argue that it
> : shouldn't be, but it is.
>

> There is good documentation out there. Again, this is holding out a
> bad stock base as the measuring stick for judging stock code.

IIRC, NM was fairly well documented, and LIMA is well documented. Many
libs are not though - hence the occasional spew of 'How does X do Y?'
posts. It is totally correct to say that there are well written and
poorly written stock bases in circulation.

> : >: * Without coding knowledge, maintenance ranges from difficult to impossible

>
> : >Depends on the code base and the goals of the code base.
>
> : ...and the problems that surface...
>

> Some code bases are not for beginners and thus are designed to make
> life difficult on beginners. Foundation is an excellent example of
> such a stock base.

Foundation is clearly aimed at more experienced coders, and simply
provides a 'leg up' so that you don't have to write the very very basic
stuff (which is nifty). I think the real issues raised against stock
bases are very solely aimed at those which are playable out of the box.

> : >: * Development restricted by legacy design

>
> : >Only in a bad code base.
>
> : You're crazy. When you write any program of 30k plus lines, a good chunk
> : of it makes assumptions on other parts of it. Good programming or not,
> : somewhere you have to write code based on what you want and not what Jim
> : Bob wants, and when you do this over 30-40k of code cleaning it up to
> : reuse in another fashion can range from very annoying to not even worth
> : doing.
>

> With good OO design, this is not an issue.

I won't profess expertise in this area.

> : >: * Rate of learning adversely affected by legacy design

>
> : >: * Legacy design may teach bad skills
>
> : >Only in a bad code base.
>
> : Again George (of all people) is being the idealist.
>

> No, I think NM did a good job of teaching good programming skills and
> helping people learn mud programming. And it is not an ideal mudlib.
> Just a very good one.

NM taught me most of the LPC I know, or rather, prompted me to learn it.
I spent a lot of time tinkering with NM 3, then ditched huge parts of it,
rewrote them, then threw out the rest when I was able - and started
pretty much over. I wouldn't have gotten as far as I did initially otherwise.

> Lima, while still a bit raw, also teaches good programming habits.

In terms of libs, especially compared to the amount of time NM was 'on
the market', LIMA is still pretty young, isn't it?

> : >: * The code is very often an example of how NOT to go about things, and

> : >: can be a bad tutor to the unwary
>
> : >Only in a bad code base.
>
> : ditto
>

> There is nothing idealistic abouthaving decent stock mud code.

Its hopefully though - many stock bases available (the widely used ones,
apparently) are seemingly poorly written (this assumption put together
from what others have said).

> And it is certainly not valid to judge the concept of stock mud code
> based on the worst possible stock mud code. It is like judging flying
> a bad mode of transportation since some planes crash.

Right.

> : >: * Often have to hack the code to get it to do what you want it to do -

> : >: not easy to rewrite a single section of the code, since many sections
> : >: depend on one-another; often new code is layered on top of poor stock
> : >: code
>
> : >Only in a bad code base.
>
> : This is simply not true (see above). There are three ways to make code do
> : something that the original designers never intended to do (unless your
> : very lucky and the avenue is left open). You can start over. You can
> : rewrite so much of the code that you might as well have started over. You
> : can hack it on top. Obviously the more trivial the addition or change the
> : less this applies, but to make massive feature adds or (especially)
> : changes, you very frequently have a major problem.
>

> What you say is simply not true. A well designed OO system is capable
> of dealing with situations the original designers had not conceived of.
>
> : >: * Your advertisements to the mud newsgroups will be ritually flamed by

> : >: scratch mud disciples
>
> : >Sounds like a personal problem of the scratch mud people.
>
> : I can agree with this to some extent... on the other hand once you release
> : a stock code base you'll get 50 idiots posting "stock mud advertisements"
> : for every one person that has a clue. That's really more the
> : problem.
>

> It's a personal problem.

I'd go as far as to state it is simply elitism. I said in another post -
I have a problem with any very poorly written mud advert that tries to
sell a game/world as a set of features, rather than what it really is.

> : If

> : you start with "StockCode Zeta", and lets say you have a clue and do a
> : decent job. You'll still be associated with all the idiots that decide
> : that it'd be "kewl" to run a mud and don't have the foggiest how to do it.
>

> Then live with it.

Yup.

> : >: * Your ideas are so different (and superior) to what is 'accepted', that

> : >: they further the evolution of muds in a very real way
>
> : >This one is ridiculous :) Sounds like elitist bullshit from Katrina.
>
> : For starters, I'd agree that the point is mis-worded. It needs to read
> : "Your ideas can be..." That said, the point above does sound elitist,
> : until you add the "can be". The truth is that new advances are only made
> : when people give up on thinking about old ways of doing things and start
> : over.
>

> Starting over is not synonymous with writing your code from scratch.
>
> If so, then that implies you need to rewrite your OS.

Heh. True enough, I suppose.

> : >: * Stock mud disciples will demand to know what you can add to muds that

> : >: a stock mud can't ("There can be no new ideas", etc)
>
> : >Again, a personal problem, this time with the stock mud people :)
>
> : Well, the ball bounces both ways ;)
>
> : >: STOCK ADVANTAGES: 10. SCRATCH ADVANTAGES: 12.
> : >: STOCK DISADVANTAGES: 14. SCRATCH DISADVANTAGES: 11.
>
> : >This ticker is silly.
>
> : I agree with that. pro/con can't be enumerated on a 1 to 1
> : correspondance. Some (dis)advantages wiegh heavier than others.
>
> : >Also, scracth disadvatange: you are reinventing the wheel, which is an
> : >extremely bad programming habit.
>
> : I have addressed this before. It's like using a wooden carriage wheel
> : when you envision Goodyear Radials. Sometimes reinventing the wheel is a
> : good thing. Imagine if we had decided the eniac was as good a computer as
> : you can make and never reinvented it. (LP would NEVER have run on
> : anything with that lack of power (tounge in cheek)). Rewritting identical
> : code is a waste of time and bad programming. Writting a better program
> : that does the same (general) thing is not nessecarily bad. If we listened
> : to George all games would be pacman with different maze maps and
> : variations off of ghosts and the chomping ball.
>

> We are not talking about writing good year radials here when you have
> only a wooden carriage. We are talking about people who want a wooden
> carriage wheel when one already exists. If you want a good year
> radial, then you build your good year radial.

Good, as metaphors go. There are some bases out there whose wheels are
probably square, and others who have superb tires. But.. something..
well.. I can't actually continue and expand this analogy. Heh.

Regards,
-Matt Chatterley
http://user.itl.net/~neddy/index.html
"Speak softly and carry a big stick." -Theodore Roosevelt

[George Reese]

Matt Chatterley <ne...@itl.net> wrote:

: On 13 Aug 1997, George Reese wrote:

: > Katrina McClelan <kit...@directcheck.aries.net> wrote:
: > : In <5ssi9t$s5i$3...@darla.visi.com> George Reese <bo...@imaginary.com> writes:
: >
: > : >: Disadvantages of stock muds
: > : >: ~~~~~~~~~~~~~~~~~~~~~~~~~~~
: > : >: * Unless you want to spend a LOT of time (perhaps more time than would
: > : >: be required to write the mud from scratch) on mud development, your
: > : >: vision of the mud must fall within the vision of the implementor of your
: > : >: codebase
: >
: > : >This is a limit of bad code bases.
: >
: > : >: * Anyone can setup and run a stock mud
: >
: > : >This is not a bad thing. What is a bad thing is that 'people who have
: > : >put little thought into running a mud can run a stock mud'.
: >
: > : Ok, but you're saying the same thing: Anyone (not just those that
: > : put thought into running a mud) can setup and run a stock mud... then
: > : again, I can argue anyonme based on all the "Help compiling" posts.
: >
: > Then clearly not anyone can put up a stock mud base.

: Yes. Although saying that anyone can put up a stock base with
: (comparitively) little experience/skill/ingelligence is probably fair
: enough (as a generalisation though!)

And this is a bad thing why? It hurts no one for people with little
experience/skill/intelligence to start a mud.

: > Those people who ask for help compiling could just as well ask for

: > help in coding the thing from scratch.

: Asking for help compiling something really shows a complete lack in terms
: of desire to learn - is it really that hard to find docs on compilers,
: etc? (Semi rhetorical question, I guess).

Stock muds do not make anyone any less capable of learning, they just
change the questions idiots ask.

: > : >: * Little or no documentation

: >
: > : >Little or no documentation? Huh?
: >
: > : Status Quo, this is true; I suppose the idealist can argue that it
: > : shouldn't be, but it is.
: >
: > There is good documentation out there. Again, this is holding out a
: > bad stock base as the measuring stick for judging stock code.

: IIRC, NM was fairly well documented, and LIMA is well documented. Many
: libs are not though - hence the occasional spew of 'How does X do Y?'
: posts. It is totally correct to say that there are well written and
: poorly written stock bases in circulation.

Again, judging the concept of stock muds using bad stock code as your
measuring stick is completely disingenuous.

: > : >: * Without coding knowledge, maintenance ranges from difficult to impossible

: >
: > : >Depends on the code base and the goals of the code base.
: >
: > : ...and the problems that surface...
: >
: > Some code bases are not for beginners and thus are designed to make
: > life difficult on beginners. Foundation is an excellent example of
: > such a stock base.

: Foundation is clearly aimed at more experienced coders, and simply
: provides a 'leg up' so that you don't have to write the very very basic
: stuff (which is nifty). I think the real issues raised against stock
: bases are very solely aimed at those which are playable out of the box.

Like I said, it depends on the code base....

: > : >: * Development restricted by legacy design

: >
: > : >Only in a bad code base.
: >
: > : You're crazy. When you write any program of 30k plus lines, a good chunk
: > : of it makes assumptions on other parts of it. Good programming or not,
: > : somewhere you have to write code based on what you want and not what Jim
: > : Bob wants, and when you do this over 30-40k of code cleaning it up to
: > : reuse in another fashion can range from very annoying to not even worth
: > : doing.
: >
: > With good OO design, this is not an issue.

: I won't profess expertise in this area.
:
: > : >: * Rate of learning adversely affected by legacy design
: >
: > : >: * Legacy design may teach bad skills
: >
: > : >Only in a bad code base.
: >
: > : Again George (of all people) is being the idealist.
: >
: > No, I think NM did a good job of teaching good programming skills and
: > helping people learn mud programming. And it is not an ideal mudlib.
: > Just a very good one.

: NM taught me most of the LPC I know, or rather, prompted me to learn it.
: I spent a lot of time tinkering with NM 3, then ditched huge parts of it,
: rewrote them, then threw out the rest when I was able - and started
: pretty much over. I wouldn't have gotten as far as I did initially otherwise.

I would not hold out NM 3 as a good example either. When I say NM, I
mean NM IV/V. That it helped you decently and that I consider it a
marginal codebase I thinks speaks volumes for the benefits of stock
code.

: > Lima, while still a bit raw, also teaches good programming habits.

: In terms of libs, especially compared to the amount of time NM was 'on
: the market', LIMA is still pretty young, isn't it?

I am not putting down Lima. I said it is still pretty raw. That is
not a bad thing given its spot in its life cycle.

: > : >: * The code is very often an example of how NOT to go about things, and

: > : >: can be a bad tutor to the unwary
: >
: > : >Only in a bad code base.
: >
: > : ditto
: >
: > There is nothing idealistic abouthaving decent stock mud code.

: Its hopefully though - many stock bases available (the widely used ones,
: apparently) are seemingly poorly written (this assumption put together
: from what others have said).

I think the people claiming they are poorly written are mostly
elitists who either did not understand those existing code bases or
who simply wish to justify all the extra work they are doing to the
world.

Now, there are some very bad codebases; but there are some very good
ones as well. But we are not judging individual code bases here.
This thread is about the *concept* of stock code. And, for the 6th
time, judging the concept of stock code against the worse stock code
bases is completely bogus.

: > And it is certainly not valid to judge the concept of stock mud code

: > based on the worst possible stock mud code. It is like judging flying
: > a bad mode of transportation since some planes crash.

: Right.

Then why do you insist on doing it? :)

: > : >: * Often have to hack the code to get it to do what you want it to do -

: > : >: not easy to rewrite a single section of the code, since many sections
: > : >: depend on one-another; often new code is layered on top of poor stock
: > : >: code
: >
: > : >Only in a bad code base.
: >
: > : This is simply not true (see above). There are three ways to make code do
: > : something that the original designers never intended to do (unless your
: > : very lucky and the avenue is left open). You can start over. You can
: > : rewrite so much of the code that you might as well have started over. You
: > : can hack it on top. Obviously the more trivial the addition or change the
: > : less this applies, but to make massive feature adds or (especially)
: > : changes, you very frequently have a major problem.
: >
: > What you say is simply not true. A well designed OO system is capable
: > of dealing with situations the original designers had not conceived of.
: >
: > : >: * Your advertisements to the mud newsgroups will be ritually flamed by
: > : >: scratch mud disciples
: >
: > : >Sounds like a personal problem of the scratch mud people.
: >
: > : I can agree with this to some extent... on the other hand once you release
: > : a stock code base you'll get 50 idiots posting "stock mud advertisements"
: > : for every one person that has a clue. That's really more the
: > : problem.
: >
: > It's a personal problem.

: I'd go as far as to state it is simply elitism. I said in another post -
: I have a problem with any very poorly written mud advert that tries to
: sell a game/world as a set of features, rather than what it really is.

I too have a problem with people advertising junk as some cool feature
or whatever. I don't think that is elitism, I think that is being
annoywed at dishonest people.

What I think is a personal problem is people who get annoyed simply
because people use stock code.

: > : If

[Katrina McClelan]

>> : >: * Development restricted by legacy design
>>
>> : >Only in a bad code base.
>>
>> : You're crazy. When you write any program of 30k plus lines, a good chunk
>> : of it makes assumptions on other parts of it. Good programming or not,
>> : somewhere you have to write code based on what you want and not what Jim
>> : Bob wants, and when you do this over 30-40k of code cleaning it up to
>> : reuse in another fashion can range from very annoying to not even worth
>> : doing.
>>
>> With good OO design, this is not an issue.

>I won't profess expertise in this area.
>

Good OO design only goes so far. We're not talking about adding a new
race or ansi color here. I can take MY code and easily make radical
changes to it. But I know all of the assumptions I made and can take
quick note of when I need to break one and make the appropriate changes
elsewhere. The same can't be said if I was working with someone else's
code. Even if I never break any assumptions, I can never be sure of it,
and often I may choose a method of doing the feature that is not the most
straightforward given the predecessor's design (the definition of a hack).
Or the design may leave no straightforward way of doing it. The end
result is the same, you fuss around trying to turn a car into an airplane.
No matter how well the car is designed, it was never meant to be an
airplane even though both are methods of transportation.

>> And it is certainly not valid to judge the concept of stock mud code
>> based on the worst possible stock mud code. It is like judging flying
>> a bad mode of transportation since some planes crash.

>Right.
>

On the other hand, if a good percentage of planes crashed instead of a
neglegable percentage, it would be a valid conclusion. If 10% of all
planes crashed we'd probably not have many people willing to fly. Well I
think you can see where I'm going since 10% is a generous amount as far as
bad stock bases go.

>> What you say is simply not true. A well designed OO system is capable
>> of dealing with situations the original designers had not conceived of.

>> ^
|
+-- SOME

I'm sorry, no matter how well designed a program is, it ultimately has a
designed function, and somewhere over 30k lines of code you're going to
find blocks of code that support that designed function, and not much
else. It is good programming practice to leave avenues open for
expansion, but when you're talking in terms of ideas that aren't dreamed
up, a computer program is somewhere over the course of 30k lines make it
difficult do put radical ideas into place. Usually any overhaul to the
game system is going to be alot of effort. Any radically new concept to
the game system may require more. Particularly integral parts of the game
system. You just can't allow for infinite possibilities.

>> : >: * Your advertisements to the mud newsgroups will be ritually flamed by
>> : >: scratch mud disciples

>> : If you start with "StockCode Zeta", and lets say you have a clue and
>> : do a decent job. You'll still be associated with all the idiots that
>> : decide that it'd be "kewl" to run a mud and don't have the foggiest
>> : how to do it.
>>
>> Then live with it.

>Yup.

Fine, live with it; it's still a disadvantage that you don't have if you
choose NOT to live with it and start from scratch.

>> Starting over is not synonymous with writing your code from scratch.
>>
>> If so, then that implies you need to rewrite your OS.

We're not improving the tools, just the product. If we were out to
improve the tools, we'd have to rewrite the OS and compiler. But we're
reinventing the wheel, not the hammer.

>> We are not talking about writing good year radials here when you have
>> only a wooden carriage. We are talking about people who want a wooden
>> carriage wheel when one already exists. If you want a good year
>> radial, then you build your good year radial.

>Good, as metaphors go. There are some bases out there whose wheels are
>probably square, and others who have superb tires. But.. something..
>well.. I can't actually continue and expand this analogy. Heh.

Some muds out there are square tires, some are wooden, some may even be
radials. But the point of the metaphor is that the ccode you write from
scratch need not be any of those. There IS nothing to compare it to.
That's the whole point. When someone designed the wooden tires there was
nothing like it before. Eventually when someone made the first modern
tires, they were very definately the first. When you reinvent the wheel
it might be the first wheel to get perfect traction even on ice with a
steep incline. But you'll never get there is all you ever make are
radials. An advantage of starting over is very definately that you might
have the first jet plane when everyone else uses propellers. A
disadvantage of stock is that you'll not have that.

-Katrina

[Matt Chatterley]

On 13 Aug 1997, Katrina McClelan wrote:

> In <5ssi9t$s5i$3...@darla.visi.com> George Reese <bo...@imaginary.com> writes:
>
> >: Disadvantages of stock muds
> >: ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >: * Unless you want to spend a LOT of time (perhaps more time than would
> >: be required to write the mud from scratch) on mud development, your
> >: vision of the mud must fall within the vision of the implementor of your
> >: codebase
>
> >This is a limit of bad code bases.
>
> >: * Anyone can setup and run a stock mud
>
> >This is not a bad thing. What is a bad thing is that 'people who have
> >put little thought into running a mud can run a stock mud'.
>
> Ok, but you're saying the same thing: Anyone (not just those that
> put thought into running a mud) can setup and run a stock mud... then
> again, I can argue anyonme based on all the "Help compiling" posts.

He's saying something slightly different (and slightly more correct). It
is not necessarily bad that anyone can set up a stock mud - if anything
this is potentially good, but it IS bad that doing so requires little to
no thought and preparation.

> >: * Little or no documentation
>
> >Little or no documentation? Huh?
>
> Status Quo, this is true; I suppose the idealist can argue that it
> shouldn't be, but it is.

I suppose amount of documentation has little to do with being stock -
although 'operational and available with no documentation' is the same
thing. My mud has practically no uptodate docs. :)

> >: * Without coding knowledge, maintenance ranges from difficult to impossible
>
> >Depends on the code base and the goals of the code base.
>
> ...and the problems that surface...

Yes, to both.

> >: * Development restricted by legacy design
>
> >Only in a bad code base.
>
> You're crazy. When you write any program of 30k plus lines, a good chunk
> of it makes assumptions on other parts of it. Good programming or not,
> somewhere you have to write code based on what you want and not what Jim
> Bob wants, and when you do this over 30-40k of code cleaning it up to
> reuse in another fashion can range from very annoying to not even worth
> doing.

True. You get some design legacy (variable amounts) from ANY code of
ANYONE elses that you use.

> >: * Rate of learning adversely affected by legacy design
>
> >: * Legacy design may teach bad skills
>
> >Only in a bad code base.
>
> Again George (of all people) is being the idealist.

He is correct. Sadly many, even most of the stock bases have what are now
considered 'design flaws'. Hence all the beggings for stock improvements.

> >: * The code is very often an example of how NOT to go about things, and
> >: can be a bad tutor to the unwary
>
> >Only in a bad code base.
>
> ditto

Equally true, but also somewhat idealistic, yes.

> >: * Often have to hack the code to get it to do what you want it to do -
> >: not easy to rewrite a single section of the code, since many sections
> >: depend on one-another; often new code is layered on top of poor stock
> >: code
>
> >Only in a bad code base.
>
> This is simply not true (see above). There are three ways to make code do
> something that the original designers never intended to do (unless your
> very lucky and the avenue is left open). You can start over. You can
> rewrite so much of the code that you might as well have started over. You
> can hack it on top. Obviously the more trivial the addition or change the
> less this applies, but to make massive feature adds or (especially)
> changes, you very frequently have a major problem.

Here I do agree that GR is wrong - you may want some sort of feature
which is simply not possible by adjusting simple configurable elements.

> >: * Your advertisements to the mud newsgroups will be ritually flamed by
> >: scratch mud disciples
>
> >Sounds like a personal problem of the scratch mud people.
>
> I can agree with this to some extent... on the other hand once you release
> a stock code base you'll get 50 idiots posting "stock mud advertisements"
> for every one person that has a clue. That's really more the problem. If
> you start with "StockCode Zeta", and lets say you have a clue and do a
> decent job. You'll still be associated with all the idiots that decide
> that it'd be "kewl" to run a mud and don't have the foggiest how to do it.

Its absolutely true that its a personal problem - but I have it with all
mud adverts, NOT for being stock, but for their terrible format. Rephrase
- not all mud adverts, all the 'same same' mud adverts.

> >: * Your ideas are so different (and superior) to what is 'accepted', that
> >: they further the evolution of muds in a very real way
>
> >This one is ridiculous :) Sounds like elitist bullshit from Katrina.
>
> For starters, I'd agree that the point is mis-worded. It needs to read
> "Your ideas can be..." That said, the point above does sound elitist,
> until you add the "can be". The truth is that new advances are only made
> when people give up on thinking about old ways of doing things and start
> over.

Hey, we can be elitist if we want. I admit to it openly.

> >: * Stock mud disciples will demand to know what you can add to muds that
> >: a stock mud can't ("There can be no new ideas", etc)
>
> >Again, a personal problem, this time with the stock mud people :)
>
> Well, the ball bounces both ways ;)

Heh. :)

> >: STOCK ADVANTAGES: 10. SCRATCH ADVANTAGES: 12.
> >: STOCK DISADVANTAGES: 14. SCRATCH DISADVANTAGES: 11.
>
> >This ticker is silly.
>
> I agree with that. pro/con can't be enumerated on a 1 to 1
> correspondance. Some (dis)advantages wiegh heavier than others.

Yuppers.

> >Also, scracth disadvatange: you are reinventing the wheel, which is an
> >extremely bad programming habit.
>
> I have addressed this before. It's like using a wooden carriage wheel
> when you envision Goodyear Radials. Sometimes reinventing the wheel is a
> good thing. Imagine if we had decided the eniac was as good a computer as
> you can make and never reinvented it. (LP would NEVER have run on
> anything with that lack of power (tounge in cheek)). Rewritting identical
> code is a waste of time and bad programming. Writting a better program
> that does the same (general) thing is not nessecarily bad. If we listened
> to George all games would be pacman with different maze maps and
> variations off of ghosts and the chomping ball.

True, to degrees.

[Nathan F. Yospe]

kc...@vnet.net (Kevin J. Chen) wrote:

:Greg Munt <gr...@uni-corn.demon.co.uk> wrote:

:>This has now been updated to encompass the comments provided by Matt

:>Chatterley and Katrina McClelan. Is there any reason why pro-stock people
:>never commented on this?

:Because it's not a thread which is really worth following?

:(Asbestos: I'm not pro-stock, I'm just not anti-stock)

*grin* Most of us are more pro-controversy than anything else. High
class trolls, one might say. Of course, that's telling.

:>I am hoping that this might be a way of presenting arguments from both

:>sides of the stock/scratch debate, without bias, and without noise.
:>I *do* want it to be a balanced analysis.

:[deletia]

:And, it seems to have covered all of the bases on both sides (although
:IMO, that was done months ago). Now what exactly was the point? This
:isn't a facetious question; I really fail to see how this discussion
:is relevant. Those folks who tend to blindly download code and
:stumble through the process of setting up a MUD are likely not those
:who are following the various design discussions in rgm. Nor does it
:seem that there are any parties on either side of the argument who are
:even remotely close to thinking about the possibility of perhaps
:approaching the fence so they might sit upon it.

But we got such a _nice_ set of wheel metaphors! ;) Personally, I
kept thinking to myself "But _I'm_ trying to invent a wormhole
based teleporter, not a car!"

:I'd much rather see these boards generate ideas rather than denigrate
:them. Challenging de facto game standards can be useful, if you've an
:alternative in mind. Otherwise, you're just tilting at windmills,
:because gosh darn it, I hate windmills.

Or love tilting.

:To get the ball rolling: I'm fascinated by Nathan Yospe's intelligent
:area generation system. I think it offers the possibility of truly
:realistic worlds, where character/world interaction is limited only by
:the world model, and not by the builder, as is often the case in
:room/zone-type approaches (and from what he's presented, it appears
:that the world model is a rich one indeed). However, this raises some
:issues as well:

Of course, its got a lot of sticky problems, as many design issues as
code issues, left to resolve. I'm working on it, honest... And to think,
Physmud++ v.1 was a Diku-on-steroids written from scratch in C++, and I
was _proud_ of that thing. Six versions later, its metamorphed into a
monster, and taken control of my life... but its gotten me a couple of
jobs, so that's not so bad.

:1) Reproducibility/identifiability. One of the keys to navigating a
:virtual world is to be able to identify patterns and locales by the
:cues presented to the user. For statically-described worlds, this is
:generally based on the description text for a particular room
:(although some players reduce this even further to the room's exit
:components). However, in a virtual world, it seems likely that a
:particular position/vector facing may not necessarily produce the same
:textual output[1], making the identification of a particular locale
:difficult to the player trying to get his bearings[2]. This could be
:potentially useful in giving the world a sense of grand scale, but it
:may necessitate visual aids (i.e. overhead views) to prevent
:navigational frustration on the part of the player.

I was talking with my roommate, the guy that introduced me to muds years
ago, and he was drooling over the current test version of the game... I
cautioned him that I had put very little effort into making it _playable_
so far. This comes to the fore with your concern here. Of course, you can
ID landmarks (I use a locational seed for generation, so things are never
changed just by leaving and coming back, at least not that way.) Of course,
if your landmark is a tree, and it gets cut down, or your blaze heals, it
may become hard to find your way. Many of my planets have GPS satelites,
and GPS compases can be purchased... this is a concession to the problems
in finding where you are. If you use a jet pack, an overhead view is an
option, and will show some of the world... landmarks, on the whole, are
the best bet, aside from remembering GPS coordinates.

:2. World detail ("The Daggerfall Effect"). A PC RPG called
:Daggerfall advertised a huge, sprawling world with dozens of
:full-fledged cities and miles of wilderness in-between. A frequent
:complaint about the game was that the cities, though large, were
:virtually indistinguishable from each other save by layout, and that
:the bulk of the city was game-sparse (i.e. most of the locations had
:little or no effect on gameplay, and were therefore mostly a waste of
:time to visit). The implication is that insuring that large expanses
:of virtual facades don't occur is the job of the builder, but at what
:level does the builder specify "things" (and using those things,
:"places") in the world, and in what ways can the builder override the
:default behaviors of the world model? On the player side of things,
:is all of this attention to detail a good thing? A free-form world is
:obviously of great benefit to a fully RP environment, but I wonder if
:a very high level of detail presented to the user might yield an
:overload effect.

The best I can say for differentiating cities is that builders MUST
design the components for them to be assembled, at least to a degree.
Of course, as they can be inherited from other cities, a city may look
a great deal like its parent... but there is another factor against
this in my game: its a galactic (and ultimately intergalactic) scale,
and every world has its own species, its own culture(s), and everything
is assembled, to a degree, from these. A world cannot be designed in
a handful of descs, which is a downside, but the upside is, entire
worlds, space stations, ecosystems, can be designed and _look_ uniform.
All the mammals on a given world inherit from the world.mammal prototype,
and this means that they _will_ resemble each other, because the set
of differences between them is going to remain as low as possible, if
only to reduce work. They all have, say, ductlike scales, six limbs,
and paired eyes... the carnivores all derive from the archetype of
carnivores... the avian mammals from one prototype. This reduces work,
and simultaniously adds a 'flavor' to a world. Likewise with flora...
cities get the same treatment. Angular steel, or glass, or crystal...
organic bubbles or underground hives... lots of slums, or perfect
middle class uniformity (or the racial equiv)... these are the set
of attributes that set two cities apart. I did the Bazaar on Deva,
for fun. It was remarkably easy. Lots of tents, all sales, the
occasional restraunt (I made five types, and set variable levels
of sophistication for each type, which affects decor and the type
of furniture, as well as prices), hotel (Three kinds, and again, a
variable for sophistication on each), and whatnot. Of course, there
was no dragon booth... I would have had to code that specifically.
I created about fifty magical item types, and set them for style...
this created a seemingly endless variety of shops. That, and I
made the people (1 in 5) randomly selected from every sentient yet
in my library. This meant a huge crowd of Deveels, and occasional
others. Of course, nothing actually instantiates until you get close.

The builder specifies detail, takes control, wherever they feel they
need to to create their vision. If that means every single creature
in the planet, I say they are insane, but whatever. If this means
adding a single new plant to the default scrubland, I tell them
"Hell, no! This is worthless!" and let them moan if they want.

As for detail, the other side of the coin is my (still under very
critical development) information filters. These try to screen the
information for significance, and maintain a user specified level
of information... this means a faster reader might get a LOT more
detail.

:3. Focus. Even in non-computer RPGs, the GM/DM often distills the
:layout of a scene to its essentials. How is significance assigned to
:things in how they are presented to a player? Does graphic detail
:create "examine paralysis" in players, as they attempt to discern the
:minute details of all of the things around them, ignoring the forest
:for the trees?

Thus the filters, which I HOPE will solve this particular problem...

:My train of thought was nastily derailed. I'll come back to this
:later if anyone actually responds to this.

*grin*

:[1] I think this mainly because a bit of nondeterminism would avoid
:the "text-generation template" appearance, assuming that similar
:patterns of terrain/landfill recur across the landscape. If the user
:is to be presented the same text each time he visited the same
:location, however, a deterministic algorithm might be more appropriate
:(otherwise, description storage for locations visited by a particular
:player might become significant).

This is true... however, if a tree is nearby, it will always be there,
unless cut down or otherwise removed. A mountain makes a good, visable
landmark. It should always be visable and recognizable. The algorithm I
use _is_ deterministic, but is also _very_ dangerously... sensitive. The
result is a different description if you are facing a different direction
by ten degrees... or if you are paying attention to something else, for
example, if you have been attacked recently, potential hiding places for
an ambusher have much heavier weight on the filter algorithm.

:[2] Of course, this could be of game use, particularly if there is
:some sort of tracking/pathfinding skill.

*grin*

--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
UH Manoa Physics | Write poetry. Be an artist. Plot world domination.
Biomedical Phys. | Panthers make great pets. Muhahahahahahahahahaha!!

[George Reese]

Katrina McClelan <kit...@directcheck.aries.net> wrote:

: In <5ssi9t$s5i$3...@darla.visi.com> George Reese <bo...@imaginary.com> writes:

: >: Disadvantages of stock muds
: >: ~~~~~~~~~~~~~~~~~~~~~~~~~~~
: >: * Unless you want to spend a LOT of time (perhaps more time than would
: >: be required to write the mud from scratch) on mud development, your
: >: vision of the mud must fall within the vision of the implementor of your
: >: codebase

: >This is a limit of bad code bases.

: >: * Anyone can setup and run a stock mud

: >This is not a bad thing. What is a bad thing is that 'people who have
: >put little thought into running a mud can run a stock mud'.

: Ok, but you're saying the same thing: Anyone (not just those that
: put thought into running a mud) can setup and run a stock mud... then
: again, I can argue anyonme based on all the "Help compiling" posts.

Then clearly not anyone can put up a stock mud base.

Those people who ask for help compiling could just as well ask for

help in coding the thing from scratch.

: >: * Little or no documentation

: >Little or no documentation? Huh?

: Status Quo, this is true; I suppose the idealist can argue that it
: shouldn't be, but it is.

There is good documentation out there. Again, this is holding out a

bad stock base as the measuring stick for judging stock code.

: >: * Without coding knowledge, maintenance ranges from difficult to impossible

: >Depends on the code base and the goals of the code base.

: ...and the problems that surface...

Some code bases are not for beginners and thus are designed to make

life difficult on beginners. Foundation is an excellent example of
such a stock base.

: >: * Development restricted by legacy design

: >Only in a bad code base.

: You're crazy. When you write any program of 30k plus lines, a good chunk
: of it makes assumptions on other parts of it. Good programming or not,
: somewhere you have to write code based on what you want and not what Jim
: Bob wants, and when you do this over 30-40k of code cleaning it up to
: reuse in another fashion can range from very annoying to not even worth
: doing.

With good OO design, this is not an issue.

: >: * Rate of learning adversely affected by legacy design

: >: * Legacy design may teach bad skills

: >Only in a bad code base.

: Again George (of all people) is being the idealist.

No, I think NM did a good job of teaching good programming skills and

helping people learn mud programming. And it is not an ideal mudlib.
Just a very good one.

Lima, while still a bit raw, also teaches good programming habits.

: >: * The code is very often an example of how NOT to go about things, and

: >: can be a bad tutor to the unwary

: >Only in a bad code base.

: ditto

There is nothing idealistic abouthaving decent stock mud code.

And it is certainly not valid to judge the concept of stock mud code

based on the worst possible stock mud code. It is like judging flying
a bad mode of transportation since some planes crash.

: >: * Often have to hack the code to get it to do what you want it to do -

: >: not easy to rewrite a single section of the code, since many sections
: >: depend on one-another; often new code is layered on top of poor stock
: >: code

: >Only in a bad code base.

: This is simply not true (see above). There are three ways to make code do
: something that the original designers never intended to do (unless your
: very lucky and the avenue is left open). You can start over. You can
: rewrite so much of the code that you might as well have started over. You
: can hack it on top. Obviously the more trivial the addition or change the
: less this applies, but to make massive feature adds or (especially)
: changes, you very frequently have a major problem.

What you say is simply not true. A well designed OO system is capable

of dealing with situations the original designers had not conceived of.

: >: * Your advertisements to the mud newsgroups will be ritually flamed by
: >: scratch mud disciples

: >Sounds like a personal problem of the scratch mud people.

: I can agree with this to some extent... on the other hand once you release
: a stock code base you'll get 50 idiots posting "stock mud advertisements"
: for every one person that has a clue. That's really more the
: problem.

It's a personal problem.

: If
: you start with "StockCode Zeta", and lets say you have a clue and do a
: decent job. You'll still be associated with all the idiots that decide
: that it'd be "kewl" to run a mud and don't have the foggiest how to do it.

Then live with it.

: >: * Your ideas are so different (and superior) to what is 'accepted', that
: >: they further the evolution of muds in a very real way

: >This one is ridiculous :) Sounds like elitist bullshit from Katrina.

: For starters, I'd agree that the point is mis-worded. It needs to read
: "Your ideas can be..." That said, the point above does sound elitist,
: until you add the "can be". The truth is that new advances are only made
: when people give up on thinking about old ways of doing things and start
: over.

Starting over is not synonymous with writing your code from scratch.

If so, then that implies you need to rewrite your OS.

: >: * Stock mud disciples will demand to know what you can add to muds that

: >: a stock mud can't ("There can be no new ideas", etc)

: >Again, a personal problem, this time with the stock mud people :)

: Well, the ball bounces both ways ;)

: >: STOCK ADVANTAGES: 10. SCRATCH ADVANTAGES: 12.
: >: STOCK DISADVANTAGES: 14. SCRATCH DISADVANTAGES: 11.

: >This ticker is silly.

: I agree with that. pro/con can't be enumerated on a 1 to 1
: correspondance. Some (dis)advantages wiegh heavier than others.

: >Also, scracth disadvatange: you are reinventing the wheel, which is an
: >extremely bad programming habit.

: I have addressed this before. It's like using a wooden carriage wheel
: when you envision Goodyear Radials. Sometimes reinventing the wheel is a
: good thing. Imagine if we had decided the eniac was as good a computer as
: you can make and never reinvented it. (LP would NEVER have run on
: anything with that lack of power (tounge in cheek)). Rewritting identical
: code is a waste of time and bad programming. Writting a better program
: that does the same (general) thing is not nessecarily bad. If we listened
: to George all games would be pacman with different maze maps and
: variations off of ghosts and the chomping ball.

We are not talking about writing good year radials here when you have

only a wooden carriage. We are talking about people who want a wooden
carriage wheel when one already exists. If you want a good year
radial, then you build your good year radial.

--

[Kevin J. Chen]

Greg Munt <gr...@uni-corn.demon.co.uk> wrote:

>This has now been updated to encompass the comments provided by Matt
>Chatterley and Katrina McClelan. Is there any reason why pro-stock people
>never commented on this?

Because it's not a thread which is really worth following?

(Asbestos: I'm not pro-stock, I'm just not anti-stock)

>I am hoping that this might be a way of presenting arguments from both

>sides of the stock/scratch debate, without bias, and without noise.
>I *do* want it to be a balanced analysis.

[deletia]

And, it seems to have covered all of the bases on both sides (although
IMO, that was done months ago). Now what exactly was the point? This
isn't a facetious question; I really fail to see how this discussion
is relevant. Those folks who tend to blindly download code and
stumble through the process of setting up a MUD are likely not those
who are following the various design discussions in rgm. Nor does it
seem that there are any parties on either side of the argument who are
even remotely close to thinking about the possibility of perhaps
approaching the fence so they might sit upon it.

I'd much rather see these boards generate ideas rather than denigrate

them. Challenging de facto game standards can be useful, if you've an
alternative in mind. Otherwise, you're just tilting at windmills,
because gosh darn it, I hate windmills.

To get the ball rolling: I'm fascinated by Nathan Yospe's intelligent

area generation system. I think it offers the possibility of truly
realistic worlds, where character/world interaction is limited only by
the world model, and not by the builder, as is often the case in
room/zone-type approaches (and from what he's presented, it appears
that the world model is a rich one indeed). However, this raises some
issues as well:

1) Reproducibility/identifiability. One of the keys to navigating a

virtual world is to be able to identify patterns and locales by the
cues presented to the user. For statically-described worlds, this is
generally based on the description text for a particular room
(although some players reduce this even further to the room's exit
components). However, in a virtual world, it seems likely that a
particular position/vector facing may not necessarily produce the same
textual output[1], making the identification of a particular locale
difficult to the player trying to get his bearings[2]. This could be
potentially useful in giving the world a sense of grand scale, but it
may necessitate visual aids (i.e. overhead views) to prevent
navigational frustration on the part of the player.

2. World detail ("The Daggerfall Effect"). A PC RPG called

Daggerfall advertised a huge, sprawling world with dozens of
full-fledged cities and miles of wilderness in-between. A frequent
complaint about the game was that the cities, though large, were
virtually indistinguishable from each other save by layout, and that
the bulk of the city was game-sparse (i.e. most of the locations had
little or no effect on gameplay, and were therefore mostly a waste of
time to visit). The implication is that insuring that large expanses
of virtual facades don't occur is the job of the builder, but at what
level does the builder specify "things" (and using those things,
"places") in the world, and in what ways can the builder override the
default behaviors of the world model? On the player side of things,
is all of this attention to detail a good thing? A free-form world is
obviously of great benefit to a fully RP environment, but I wonder if
a very high level of detail presented to the user might yield an
overload effect.

3. Focus. Even in non-computer RPGs, the GM/DM often distills the

layout of a scene to its essentials. How is significance assigned to
things in how they are presented to a player? Does graphic detail
create "examine paralysis" in players, as they attempt to discern the
minute details of all of the things around them, ignoring the forest
for the trees?

My train of thought was nastily derailed. I'll come back to this

later if anyone actually responds to this.

[1] I think this mainly because a bit of nondeterminism would avoid

the "text-generation template" appearance, assuming that similar
patterns of terrain/landfill recur across the landscape. If the user
is to be presented the same text each time he visited the same
location, however, a deterministic algorithm might be more appropriate
(otherwise, description storage for locations visited by a particular
player might become significant).

[2] Of course, this could be of game use, particularly if there is

some sort of tracking/pathfinding skill.

Kevin.
NoAd...@due.to.spam

[George Reese]

You talk about an object oriented system as if the system as a whole
is some monolithic thing that has a single purpose. This is, in fact,
not the way OO works. The example you use is making a car into a
plane. If, programmatically, you had a car and wanted to get to a
plane, it make sense to use the code you have from the car to get to
the plane. That is because the system is *not* a big monolithic car.
It is a wheel, an engine, a sterring mechanism, and many other little
things. Some of these things can be plugged into a plane without
modification. Some need modification; but since their scope is
limited and well-encapsulated, making those changes is not difficult.
And finally, in other cases you add new objects. The bottom line is
that what you present below is not in fact OO design.

Katrina McClelan <kit...@directcheck.aries.net> wrote:

[massive editing]

: Some muds out there are square tires, some are wooden, some may even be

: radials. But the point of the metaphor is that the ccode you write from
: scratch need not be any of those. There IS nothing to compare it to.
: That's the whole point. When someone designed the wooden tires there was
: nothing like it before. Eventually when someone made the first modern
: tires, they were very definately the first. When you reinvent the wheel
: it might be the first wheel to get perfect traction even on ice with a
: steep incline. But you'll never get there is all you ever make are
: radials. An advantage of starting over is very definately that you might
: have the first jet plane when everyone else uses propellers. A
: disadvantage of stock is that you'll not have that.

Wherte do you get the idea that stock mud users cannot create a jet
airplane? Just because you use a stock base does not mean you are
stuck with it as is in any way. There is nothing so inherently
inventive about writing a mud from scratch.

[Matt Chatterley]

On 14 Aug 1997, George Reese wrote:

> Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
> : On 14 Aug 1997, George Reese wrote:
>
> : > The bottom line is that what you present below is not in fact OO design.
>
> : Which of The Big Three use OOD?
>
> The big three what?

Munt knows. Presumably be means Diku / Tiny / LP.

> : [snip]
>
> : > There is nothing so inherently inventive about writing a mud from scratch.
>
> : This is indeed correct. However, constraints of legacy design certainly
> : restrict effective inventiveness.
>
> Depending on the system, the stock code can either free the admin to
> be inventive or tie the admin to legacy decisions. There is nothing
> about the concept of stock code that inherently constrains
> inventiveness any more that building from scratch inherently
> faciliates it.
>
> Imaginative people with a good stock base will be more inventive than
> dullards writing from scratch.

This last point is true - and rightly so, and some bases are good in that
they allow people to easily create a good game world and open it to the
public - the problems arise when they want to do something which
transcends the capabilities of the server.

No matter how good your server is, if it doesnt do X (and X may be an
obscure feature which you really require for your game), you will have to
add X, and that is where (IMHO) trouble starts.

[Nathan F. Yospe]

George Reese <bo...@imaginary.com> wrote:

:Matt Chatterley <ne...@itl.net> wrote:

:: No matter how good your server is, if it doesnt do X (and X may be an

:: obscure feature which you really require for your game), you will have to
:: add X, and that is where (IMHO) trouble starts.

:People are trying to use this fact as if it is damning to the concept
:of stock code. If you can't add X in a stock code base, there is no
:way in hell you are going to be able to do it starting from scratch.

The key is, you may have to HACK X into the stock base. I mean, do
you really think you could have made a distributed client/server
database with runtime behavior prediction in the client, and a set
of partial correction protocols, running on merge/split threads
centered on users, out of your NM libs? Or out of a diku, or a MOO?
Hell... you can't even do it in LPC, without essentially rewriting
the driver. But I can (and did, though my clients need a LOT of
work, and there are some serious design issues still unresolved)
do it starting with an empty buffer and a huge pile of notepads for
my design futzing...

[Greg Munt]

On 14 Aug 1997, George Reese wrote:

> The bottom line is that what you present below is not in fact OO design.

Which of The Big Three use OOD?

[snip]

> There is nothing so inherently inventive about writing a mud from scratch.

This is indeed correct. However, constraints of legacy design certainly
restrict effective inventiveness.

-------------------------------------------------------------------------------
"I want to be imp on a MU*!!! Where do I get the code for CircleMUD???"
"I have great ideas for a new mud, but if I use stock code I'll be flamed."
These are the two extremes. Can the pro-scratchers go too far?

[George Reese]

Greg Munt <gr...@uni-corn.demon.co.uk> wrote:

: On 14 Aug 1997, George Reese wrote:

: > The bottom line is that what you present below is not in fact OO design.

: Which of The Big Three use OOD?

The big three what?

: [snip]

: > There is nothing so inherently inventive about writing a mud from scratch.

: This is indeed correct. However, constraints of legacy design certainly
: restrict effective inventiveness.

Depending on the system, the stock code can either free the admin to

be inventive or tie the admin to legacy decisions. There is nothing
about the concept of stock code that inherently constrains
inventiveness any more that building from scratch inherently
faciliates it.

Imaginative people with a good stock base will be more inventive than
dullards writing from scratch.

--

[George Reese]

Matt Chatterley <ne...@itl.net> wrote:
: On 14 Aug 1997, George Reese wrote:

: > Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: > : On 14 Aug 1997, George Reese wrote:
: >
: > : > The bottom line is that what you present below is not in fact OO design.
: >
: > : Which of The Big Three use OOD?
: >
: > The big three what?

: Munt knows. Presumably be means Diku / Tiny / LP.

I can only speak to LP. And that depends on the mudlib. Lima and NM
IV/V are OO. NM 3 is marginally OO. LPMud 2.4.5 is not OO. TMI-2 is
a wreck.

: > : [snip]

: >
: > : > There is nothing so inherently inventive about writing a mud from scratch.
: >
: > : This is indeed correct. However, constraints of legacy design certainly
: > : restrict effective inventiveness.
: >
: > Depending on the system, the stock code can either free the admin to
: > be inventive or tie the admin to legacy decisions. There is nothing
: > about the concept of stock code that inherently constrains
: > inventiveness any more that building from scratch inherently
: > faciliates it.
: >
: > Imaginative people with a good stock base will be more inventive than
: > dullards writing from scratch.

: This last point is true - and rightly so, and some bases are good in that

: they allow people to easily create a good game world and open it to the
: public - the problems arise when they want to do something which
: transcends the capabilities of the server.

: No matter how good your server is, if it doesnt do X (and X may be an

: obscure feature which you really require for your game), you will have to
: add X, and that is where (IMHO) trouble starts.

People are trying to use this fact as if it is damning to the concept
of stock code. If you can't add X in a stock code base, there is no

way in hell you are going to be able to do it starting from scratch.

[Nathan F. Yospe]

kc...@vnet.net (Kevin J. Chen) wrote:

:I hate to mutate threads, but I don't feel like propagating the
:stock/scratch debate.

*Nod* I'm just a stinker for flame wars, myself.

:yo...@hawaii.remove.this.edu (Nathan F. Yospe) wrote:

:>Of course, its got a lot of sticky problems, as many design issues as

:>code issues, left to resolve. I'm working on it, honest... And to think,
:>Physmud++ v.1 was a Diku-on-steroids written from scratch in C++, and I
:>was _proud_ of that thing. Six versions later, its metamorphed into a
:>monster, and taken control of my life... but its gotten me a couple of
:>jobs, so that's not so bad.

:This may be a bit too personal, but what sort of jobs? I can see
:where the results of this project could be applicable in a number of
:fields (research and entertainment paramount among them). Is your
:work on this project part of your current job?

Unfortunately, no. I have hopes... the jobs it got me were not in any
such "fun" industries... it was simply an example of a massive app to
shove in front of potential employers and wow their socks off.

:>I was talking with my roommate, the guy that introduced me to muds years

:>ago, and he was drooling over the current test version of the game... I
:>cautioned him that I had put very little effort into making it _playable_
:>so far. This comes to the fore with your concern here. Of course, you can
:>ID landmarks (I use a locational seed for generation, so things are never
:>changed just by leaving and coming back, at least not that way.) Of course,
:>if your landmark is a tree, and it gets cut down, or your blaze heals, it
:>may become hard to find your way. Many of my planets have GPS satelites,

:Or indeed, player modifications to the terrain may become more
:significant landmarks in themselves. This also implies that all
:things have associated state which I assume is demand-loaded to avoid
:massive RAM-suckage. I also assume you've got some sort of LRU
:algorithm to determine which items are "out of sight, out of mind" for
:a player. How do you avoid thrashing as objects are loaded into the
:game engine from the disk (database? interpreted text file?
:proprietary binary format?) as the user sprints through the world?

Shutdown of local threads when inactive and relegation of contents to
a time based memory shuffle/swap file... mods to the original generation
are still not persistant across reboots. I'm working on it. Sprinting
gets you package objects, they never resolve into details. This is a
major plus for the system as well. Many details in the world will
never have to resolve.

:>and GPS compases can be purchased... this is a concession to the problems

:>in finding where you are. If you use a jet pack, an overhead view is an
:>option, and will show some of the world... landmarks, on the whole, are
:>the best bet, aside from remembering GPS coordinates.

:I suppose it's a question of scale and focus again. Coming from a
:fantasy AberMUD background, I find it convenient as a player to know
:that a road is long and winding, but not to have to actually navigate
:the long, winding road. Of course, that sort of approach makes other
:modes of transportation where geography is relevant, such as flight,
:more or less impossible without cheesy kludges.

This is a major design decision. I decided that I prefered a mud that
could handle complex physical simulation over one that was a good
medium for writers. I already have a medium for writing, you see. I
can't, on the other hand, simulate an entire galaxy in my head.

:>The best I can say for differentiating cities is that builders MUST

:>design the components for them to be assembled, at least to a degree.
:>Of course, as they can be inherited from other cities, a city may look
:>a great deal like its parent... but there is another factor against
:>this in my game: its a galactic (and ultimately intergalactic) scale,
:>and every world has its own species, its own culture(s), and everything
:>is assembled, to a degree, from these. A world cannot be designed in
:>a handful of descs, which is a downside, but the upside is, entire
:>worlds, space stations, ecosystems, can be designed and _look_ uniform.

:[deletia]

:In a separate post, you included a sample specification for a portion
:of your world, in which things like walls appeared to be specified
:precisely in sizes and Cartesian coordinates. You also indicate above
:that your system uses replicable archetypes to quickly generate
:consistent regions. How does the computer determine the placement of
:these templates in a three-dimensional world, accounting for factors
:such as terrain? I ask mainly because the fundamental level of detail
:in the world threatens to place a heavy burden on the builder to
:completely specify his world. For example, if you're a somewhat
:haphazard builder (as admittedly, I am) it's easy to cram "extra"
:rooms into, say, a street that didn't have much detail using a
:room/zone approach, but to do that with buildings with a specified
:physical size requires that things get shifted around, possibly
:impacting entire blocks of city (unless your engine can also resolve
:space conflicts, too).

The room in the other post (the transport room in yet another post)
is a fixed part of the world. The forest under it, on the other hand,
was completely generated. As for factors such as terrain... um? Isn't
terrain just another part of that generated landscape? Or do you mean
the use of a template room? I don't usually build the rooms in a city,
but if I were to make a set of generic city rooms by hand and use them
over a stretch, I would hardly try to set one down on a mountain... I
think the engine might do something funky, like having the whole house
go down when runtime started in that region (dated back to the moment
the house was initialized, even)... as for cramming rooms... are they
of defined size? The online engine would choke on such a request...
doing it in a file... well, rooms are defined relative to each other,
so the inconsistancy would report an error on load and add some padding
around the rest of the place... not a good thing. There would be a
lot of rather large alleys or streets, as those are variable size
in the load defs (defined as stretching from bounds of this to that)

:>As for detail, the other side of the coin is my (still under very

:>critical development) information filters. These try to screen the
:>information for significance, and maintain a user specified level
:>of information... this means a faster reader might get a LOT more
:>detail.

:Yow -- that is fantastic. Could you sketch out how your
:perception/presentation engine works? The most obvious solution that
:springs to mind is some black box which takes a series of relevant
:objects in the environment, distills the sensory input from each
:object, does an importance filter sort, and then spits out whatever's
:left over. The part I'm trying to figure out is how to avoid the
:"scanning loop" method of generating text (i.e. pick an object in
:front of you, describe it, pick the next object, describe it -- which
:would inevitably lead to a description like "Slightly in front of you
:and to your left is a door. It is about six feet tall and made of
:wood. Slightly in front of you and to your right is a table. It is
:four feet tall and made of wood. On the table is a piece of
:paper...")

Well, if you read the area sample I posted (Lifetrees) a couple days
ago, you will see that I _do_ do exactly that... assembled scans. I
just bury it in other parts of the desc. In any case, the thing that
I have neglected to clarify is that most of this work is handled not
by the game proper (the simulator) but by either an online parser or
a client, depending on whether a client is present. This means that
a lot of the description information makes it to the client, but not
to the screen, as the screen can only take so much... I am still at
work on a lot of this. My perception engine is still based on a bit
of markup and a lot of assembly, and the presentation is haphazard
assembly. It is NOT done, far from it. It still barfs up stuff that
makes no sense all the time.

:>This is true... however, if a tree is nearby, it will always be there,

:>unless cut down or otherwise removed. A mountain makes a good, visable
:>landmark. It should always be visable and recognizable. The algorithm I
:>use _is_ deterministic, but is also _very_ dangerously... sensitive. The
:>result is a different description if you are facing a different direction
:>by ten degrees... or if you are paying attention to something else, for
:>example, if you have been attacked recently, potential hiding places for
:>an ambusher have much heavier weight on the filter algorithm.

:As per above, yow. Very, very cool. I can imagine playing lots of
:entertaining perceptual games with filtering mechanisms, which would
:allow for alien perception, drug effects, perceptual hardware such as
:IR or night-vision glasses, etc.

That's the idea.

:I think the true power of the sort of system you've described (and
:implemented!) is the ability of the system itself to handle a wide
:range of player actions, which removes problems of world consistency
:from the builder's hands. Continuity (geography, world physics, etc.)
:becomes trivial in such a system, because the system generates these
:effects, rather than relying on a world-builder to enumerate them.

That's pretty much the heart of it. I am still working on the "ed"
of "implemented" - it is still an "ing" for now... but what it comes
down to is, I've designed a simulation engine, not a text display
machine.

:I also see this as a potential weakness for precisely the same reason,
:because of the inability to limit the player's actions in situations
:where the builder may desire it. For example, a builder creates an
:area where a much-coveted treasure is kept within a cave guarded by a
:fierce dragon. The intent is that a player should combat the dragon
:and defeat it to gain the treasure. However, the player could simply
:dig through the back of the cavern, circumventing the carefully
:laid-out trap (yes, the dragon might notice someone blasting through
:the back wall of the cave and go to investigate -- the point is that
:it becomes more difficult to create directed puzzle areas a la Zork in
:a fully interactive environment).

I consider this a good thing. The turning point was back with
Physmud++ v.3,I think. I had a friend, a game buff and cop in training,
play a scenario in the game involving a jailbreak rescue mission. He
complained that he couldn't shoot a hole in wall and throw grenades
through it. I stared at him, goggle eyed, for a few seconds. I've been
lost ever since. And that scenario was SUCH a good puzzle. Now, it
would not be, unless I took care to prevent most sneaky tricks... there
are a hundred ways to solve any puzzle, and a good puzzle is hard to
solve by brute force... but that's all.

[George Reese]

Matt Chatterley <ne...@itl.net> wrote:
: > People are trying to use this fact as if it is damning to the concept

: > of stock code. If you can't add X in a stock code base, there is no
: > way in hell you are going to be able to do it starting from scratch.

: But there is, at least, *theoretically*, given the advantage that you
: would at least understand the code in its entirity (as a working mud, and
: as subsets of systems and mechanisms). If you were writing it from the
: word go, all yourself, you could have planned feature X from the offset,
: and made allowances for it.

And, following the theoretical bent, given the advantage that you
understand your stock code's object model, you do not have to rewrite
80% of the stuff that is common to all muds and can instead spend your
time worrying about feature X.

You need to judge both concepts using the same measuring sticks.

: This isn't what most people point out as 'damning' to stock code - but it
: is more of a disadvantage there than when you have your own code written
: from nil upwards. The best stock muds in my opinion are those which are
: well documented, with minimised features (minimised game features at any
: rate).

I disagree about the features thing. Well-written features are there
if you want them an trashable if you do not.

[Greg Munt]

On 14 Aug 1997, George Reese wrote:

> Matt Chatterley <ne...@itl.net> wrote:
>
> : No matter how good your server is, if it doesnt do X (and X may be an
> : obscure feature which you really require for your game), you will have to
> : add X, and that is where (IMHO) trouble starts.
>

> People are trying to use this fact as if it is damning to the concept
> of stock code. If you can't add X in a stock code base, there is no
> way in hell you are going to be able to do it starting from scratch.

Incorrect. It is not being proposed that adding X to a stock base is
*impossible* - simply that it will be more difficult, and mean more work
(depending on the legacy design).

An example is converting CircleMUD to use an object orientated, event-driven,
multi-threaded model. This is certainly *possible*...

[George Reese]

Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: On 13 Aug 1997, George Reese wrote:

: > The main problem I see here is using bad code bases as the measurement

: > of the strengths and weaknesses of stck code. I think you should
: > assume a decent quality code base before assessing the strengths and

: > weaknesses of the concept of stock code.

: Point taken. But... Which of the muds listed on the latest version of The
: Mud Tree would you consider 'a decent quality code base'? What proportion
: of the Tree do they make up? 90%? 50%? 10%?

Again, I cannot speak to anything but LP. And the main mudlib being
used today, Lima, I would consider very good quality.

: IMHO the stock/scratch debate is to an extent concerned with what people
: do with the code. It is primarily concerned with the tendency towards
: sameness. Bad code bases contribute to this heavily - DIKU and its
: derivatives are mentioned most of all (it is rare for any other mud type
: to be mentioned, in actual fact) in these debates.

I question the sanity of people who use Diku in the face of LPMud,
because the LPMud architecture is a lot more sound. So, bottom line,
Diku mud people would not make good muds in any universe, so why worry
about them?

: Are there certain stock codebases that encourage variety and diversification,
: and certain others that positively discourage it?

LPMud encourages it, especially with the trend away from releasing
areas. I do not know of any Nightmare, Discworld, TMI-2, or Lima
'areas' in public release.

: Might we be able to draw up lists of implementation and/or design
: features that encourage, and discourage, mud evolution? Are there feature
: groups which discourage/encourage it, more than others? Can these be
: identified?

Who actually gives a damn about mud evolution? The goal is to make a
good game. Evolution is not designed.

[George Reese]

Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
: George Reese <bo...@imaginary.com> wrote:

: :Matt Chatterley <ne...@itl.net> wrote:

: :: No matter how good your server is, if it doesnt do X (and X may be an
: :: obscure feature which you really require for your game), you will have to
: :: add X, and that is where (IMHO) trouble starts.

: :People are trying to use this fact as if it is damning to the concept
: :of stock code. If you can't add X in a stock code base, there is no

: :way in hell you are going to be able to do it starting from scratch.

: The key is, you may have to HACK X into the stock base.

That is completely untrue. You don't have to hack it into a code
stock base.

: I mean, do
: you really think you could have made a distributed client/server
: database with runtime behavior prediction in the client, and a set
: of partial correction protocols, running on merge/split threads
: centered on users, out of your NM libs? Or out of a diku, or a MOO?

No, but that has nothing to do with anything. Nightmare is not a good
code base for writing that kind of mud. Does that mean stock code is
bad? Only if all muds should have the features you list above. If
your vision looks nothing like the object model of a given stock base,
then *that* stock base is not right for you. You and several other
people try to make the leap that because stock mud X is not good for
task Y, that stock muds as a concept are bad! That is seriously
defective logic.

[Richard Woolcock]

George Reese wrote:
>
> Greg Munt <gr...@uni-corn.demon.co.uk> wrote:[snip]

> : IMHO the stock/scratch debate is to an extent concerned with what people
> : do with the code. It is primarily concerned with the tendency towards
> : sameness. Bad code bases contribute to this heavily - DIKU and its
> : derivatives are mentioned most of all (it is rare for any other mud type
> : to be mentioned, in actual fact) in these debates.
>
> I question the sanity of people who use Diku in the face of LPMud,
> because the LPMud architecture is a lot more sound. So, bottom line,
> Diku mud people would not make good muds in any universe, so why worry
> about them?

I find this generalisation most unsatisfying. Please back up your opinion
that "Diku mud people would not make good muds in any universe". I assume
also that 'good muds' actually means 'good muds in your opinion', in which
case I could argue "LPmuds suck because I don't personally like them".

Now if you said "Most dikumuds suck", then I would be inclined to agree
with you. In fact if you said "Most muds suck", then I would also have to
agree. If you said "LPmuds are better designed and thus easier to make
good muds from" then I would also - reluctantly - agree with you. However,
a good mud can be made from any code base, despite the fact that some might
require a lot more work than others.

KaVir.

[Katrina McClelan]

>: :: No matter how good your server is, if it doesnt do X (and X may be an
>: :: obscure feature which you really require for your game), you will have to
>: :: add X, and that is where (IMHO) trouble starts.

>: :People are trying to use this fact as if it is damning to the concept
>: :of stock code. If you can't add X in a stock code base, there is no
>: :way in hell you are going to be able to do it starting from scratch.

>: The key is, you may have to HACK X into the stock base.

>That is completely untrue. You don't have to hack it into a code
>stock base.

I wanna know where George got from "may have to" to "have to". You are
right. You don't HAVE to hack it into stock code. You could always start
from scratch.

>: I mean, do
>: you really think you could have made a distributed client/server
>: database with runtime behavior prediction in the client, and a set
>: of partial correction protocols, running on merge/split threads
>: centered on users, out of your NM libs? Or out of a diku, or a MOO?

>No, but that has nothing to do with anything. Nightmare is not a good
>code base for writing that kind of mud. Does that mean stock code is
>bad?

In terms of doing "X", yes it does.

>Only if all muds should have the features you list above. If
>your vision looks nothing like the object model of a given stock base,
>then *that* stock base is not right for you. You and several other
>people try to make the leap that because stock mud X is not good for
>task Y, that stock muds as a concept are bad! That is seriously
>defective logic.

I can go along with this, but on the other hand your sumarization of the
logic leaves out a point.

Any code base you start with is going to have some set of "X's" that it is
not good for. A stock base is also going to have some set of "Y's" that
is is good for, and some set of "Z's" that it already does. Let's assume
the base is good, and that all the "Z's" included are not what would be
considered "bulk", and well coded. Let's also assume that good coding and
documentation makes the set of "Y's" rather large. The set "X's" which is
everything that is not in the set of "Y's" or the set of "Z's" is going to
be substantially large. What cripples most stock bases is the one or two
things that a new implementor wants out of the set of "X's". These are
what have to be basically hacked in. I know what argument is going to be
thrown back - that you should stay out of the "X's" if you use this
codebase. Well then you end up with a gaggle of muds that just do the
same old set of "Y's" and ignore the vast set of "X's" that are out there.
This is also a bad thing, that we've also mentioned as being a
disadvantage of starting from stock. You either hack in your innovative
dreams, or you do the same old stuff that everyone else is doing.
Granted, very occasionally a new idea surfaces that ends up coincidentally
being in the set of "Y's" instead of the set of "X's". But the chance of
your ideas hitting the set of "X's" is rather high as well. The next
thing you'll say is that you should find a codebase that has all of your
ideas in the set of "Y's". You know how you do that? You write it
yourself.

Stock bases are like strainers that take an infinite set of ideas and
possibilities and filter out either the ideas themselves, or the proper
implementation of them. This is going to be true of any stock base. If I
released my code I'd argue against people using it (which is why I don't
have plans to release it). Why? Because you can run my code and run a
mud that does what *I* wanted it to do, or you can write one that does
what *you* want it to do. Why limit yourself from the start by using
someone else's baggage?

-Katrina

[Greg Munt]

On 15 Aug 1997, George Reese wrote:

> Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
> : On 13 Aug 1997, George Reese wrote:
>
> : > The main problem I see here is using bad code bases as the measurement
> : > of the strengths and weaknesses of stck code. I think you should
> : > assume a decent quality code base before assessing the strengths and
> : > weaknesses of the concept of stock code.
>
> : Point taken. But... Which of the muds listed on the latest version of The
> : Mud Tree would you consider 'a decent quality code base'? What proportion
> : of the Tree do they make up? 90%? 50%? 10%?
>
> Again, I cannot speak to anything but LP. And the main mudlib being
> used today, Lima, I would consider very good quality.

Perhaps Martin might be able to give a more general answer to this
question... If the majority of stock code is not 'a decent quality code
base', why is this?

> : IMHO the stock/scratch debate is to an extent concerned with what people
> : do with the code. It is primarily concerned with the tendency towards
> : sameness. Bad code bases contribute to this heavily - DIKU and its
> : derivatives are mentioned most of all (it is rare for any other mud type
> : to be mentioned, in actual fact) in these debates.
>
> I question the sanity of people who use Diku in the face of LPMud,
> because the LPMud architecture is a lot more sound. So, bottom line,
> Diku mud people would not make good muds in any universe, so why worry
> about them?

This sounds like elitism to me, George! (*chuckle*)

> : Are there certain stock codebases that encourage variety and diversification,
> : and certain others that positively discourage it?
>
> LPMud encourages it,

If you speak of LPMud generally, it might be argued that you are speaking
of LPC, in actuality. If this *is* the case, you might equally
argue that C encourages it, too.

> especially with the trend away from releasing
> areas. I do not know of any Nightmare, Discworld, TMI-2, or Lima
> 'areas' in public release.

So, is it just the DIKU bases that have stock areas? Why? What is it
about DIKU that encourages this?

> : Might we be able to draw up lists of implementation and/or design
> : features that encourage, and discourage, mud evolution? Are there feature
> : groups which discourage/encourage it, more than others? Can these be
> : identified?
>
> Who actually gives a damn about mud evolution? The goal is to make a
> good game. Evolution is not designed.

Desiring to make a 'better' mud than those currently available is
indirectly a concern with mud evolution.

In fact, the stock/scratch threads are *entirely* concerned with mud
evolution.

The point of the questions was to identify features in a mud that
encourage similarity. Knowing about them allows people to avoid them.
(Assuming that they *want* to avoid them... Grumble.)

[Kevin J. Chen]

I hate to mutate threads, but I don't feel like propagating the
stock/scratch debate.

yo...@hawaii.remove.this.edu (Nathan F. Yospe) wrote:

>Of course, its got a lot of sticky problems, as many design issues as
>code issues, left to resolve. I'm working on it, honest... And to think,
>Physmud++ v.1 was a Diku-on-steroids written from scratch in C++, and I
>was _proud_ of that thing. Six versions later, its metamorphed into a
>monster, and taken control of my life... but its gotten me a couple of
>jobs, so that's not so bad.

This may be a bit too personal, but what sort of jobs? I can see

where the results of this project could be applicable in a number of
fields (research and entertainment paramount among them). Is your
work on this project part of your current job?

>I was talking with my roommate, the guy that introduced me to muds years

>ago, and he was drooling over the current test version of the game... I
>cautioned him that I had put very little effort into making it _playable_
>so far. This comes to the fore with your concern here. Of course, you can
>ID landmarks (I use a locational seed for generation, so things are never
>changed just by leaving and coming back, at least not that way.) Of course,
>if your landmark is a tree, and it gets cut down, or your blaze heals, it
>may become hard to find your way. Many of my planets have GPS satelites,

Or indeed, player modifications to the terrain may become more

significant landmarks in themselves. This also implies that all
things have associated state which I assume is demand-loaded to avoid
massive RAM-suckage. I also assume you've got some sort of LRU
algorithm to determine which items are "out of sight, out of mind" for
a player. How do you avoid thrashing as objects are loaded into the
game engine from the disk (database? interpreted text file?
proprietary binary format?) as the user sprints through the world?

>and GPS compases can be purchased... this is a concession to the problems

>in finding where you are. If you use a jet pack, an overhead view is an
>option, and will show some of the world... landmarks, on the whole, are
>the best bet, aside from remembering GPS coordinates.

I suppose it's a question of scale and focus again. Coming from a

fantasy AberMUD background, I find it convenient as a player to know
that a road is long and winding, but not to have to actually navigate
the long, winding road. Of course, that sort of approach makes other
modes of transportation where geography is relevant, such as flight,
more or less impossible without cheesy kludges.

>The best I can say for differentiating cities is that builders MUST

>design the components for them to be assembled, at least to a degree.
>Of course, as they can be inherited from other cities, a city may look
>a great deal like its parent... but there is another factor against
>this in my game: its a galactic (and ultimately intergalactic) scale,
>and every world has its own species, its own culture(s), and everything
>is assembled, to a degree, from these. A world cannot be designed in
>a handful of descs, which is a downside, but the upside is, entire
>worlds, space stations, ecosystems, can be designed and _look_ uniform.

[deletia]

In a separate post, you included a sample specification for a portion
of your world, in which things like walls appeared to be specified
precisely in sizes and Cartesian coordinates. You also indicate above
that your system uses replicable archetypes to quickly generate
consistent regions. How does the computer determine the placement of
these templates in a three-dimensional world, accounting for factors
such as terrain? I ask mainly because the fundamental level of detail
in the world threatens to place a heavy burden on the builder to
completely specify his world. For example, if you're a somewhat
haphazard builder (as admittedly, I am) it's easy to cram "extra"
rooms into, say, a street that didn't have much detail using a
room/zone approach, but to do that with buildings with a specified
physical size requires that things get shifted around, possibly
impacting entire blocks of city (unless your engine can also resolve
space conflicts, too).

>As for detail, the other side of the coin is my (still under very

>critical development) information filters. These try to screen the
>information for significance, and maintain a user specified level
>of information... this means a faster reader might get a LOT more
>detail.

Yow -- that is fantastic. Could you sketch out how your

perception/presentation engine works? The most obvious solution that
springs to mind is some black box which takes a series of relevant
objects in the environment, distills the sensory input from each
object, does an importance filter sort, and then spits out whatever's
left over. The part I'm trying to figure out is how to avoid the
"scanning loop" method of generating text (i.e. pick an object in
front of you, describe it, pick the next object, describe it -- which
would inevitably lead to a description like "Slightly in front of you
and to your left is a door. It is about six feet tall and made of
wood. Slightly in front of you and to your right is a table. It is
four feet tall and made of wood. On the table is a piece of
paper...")

>This is true... however, if a tree is nearby, it will always be there,

>unless cut down or otherwise removed. A mountain makes a good, visable
>landmark. It should always be visable and recognizable. The algorithm I
>use _is_ deterministic, but is also _very_ dangerously... sensitive. The
>result is a different description if you are facing a different direction
>by ten degrees... or if you are paying attention to something else, for
>example, if you have been attacked recently, potential hiding places for
>an ambusher have much heavier weight on the filter algorithm.

As per above, yow. Very, very cool. I can imagine playing lots of

entertaining perceptual games with filtering mechanisms, which would
allow for alien perception, drug effects, perceptual hardware such as
IR or night-vision glasses, etc.

I think the true power of the sort of system you've described (and

implemented!) is the ability of the system itself to handle a wide
range of player actions, which removes problems of world consistency
from the builder's hands. Continuity (geography, world physics, etc.)
becomes trivial in such a system, because the system generates these
effects, rather than relying on a world-builder to enumerate them.

I also see this as a potential weakness for precisely the same reason,

because of the inability to limit the player's actions in situations
where the builder may desire it. For example, a builder creates an
area where a much-coveted treasure is kept within a cave guarded by a

fierce dragon. The intent is that a player should combat the dragon
and defeat it to gain the treasure. However, the player could simply
dig through the back of the cavern, circumventing the carefully
laid-out trap (yes, the dragon might notice someone blasting through
the back wall of the cave and go to investigate -- the point is that
it becomes more difficult to create directed puzzle areas a la Zork in
a fully interactive environment).

Kevin.
NoAd...@due.to.spam

[Greg Munt]

On 13 Aug 1997, George Reese wrote:

> The main problem I see here is using bad code bases as the measurement
> of the strengths and weaknesses of stck code. I think you should
> assume a decent quality code base before assessing the strengths and
> weaknesses of the concept of stock code.

Point taken. But... Which of the muds listed on the latest version of The
Mud Tree would you consider 'a decent quality code base'? What proportion
of the Tree do they make up? 90%? 50%? 10%?

IMHO the stock/scratch debate is to an extent concerned with what people

do with the code. It is primarily concerned with the tendency towards
sameness. Bad code bases contribute to this heavily - DIKU and its
derivatives are mentioned most of all (it is rare for any other mud type
to be mentioned, in actual fact) in these debates.

Are there certain stock codebases that encourage variety and diversification,

and certain others that positively discourage it?

Might we be able to draw up lists of implementation and/or design

features that encourage, and discourage, mud evolution? Are there feature
groups which discourage/encourage it, more than others? Can these be
identified?

-------------------------------------------------------------------------------

[Matt Chatterley]

On 14 Aug 1997, George Reese wrote:

> Matt Chatterley <ne...@itl.net> wrote:
> : On 14 Aug 1997, George Reese wrote:
>
> : > Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
> : > : On 14 Aug 1997, George Reese wrote:
> : >
> : > : > The bottom line is that what you present below is not in fact OO design.
> : >
> : > : Which of The Big Three use OOD?
> : >
> : > The big three what?
>
> : Munt knows. Presumably be means Diku / Tiny / LP.
>
> I can only speak to LP. And that depends on the mudlib. Lima and NM
> IV/V are OO. NM 3 is marginally OO. LPMud 2.4.5 is not OO. TMI-2 is
> a wreck.

Yup. From what I have seen of Diku relatives, they are not particularly
OO (perhaps notionally). Tiny (Tinymush/pennmush) softcode is fairly OO,
although objects do not tend to reference each other very often - it
really does depend. They have some similar concepts to LP, and some very
different ones.

LP is not terribly hard to built an OO mudlib for, IMHO, compared to
other situations, and I agree with the list you give above.

> : > : [snip]
> : >
> : > : > There is nothing so inherently inventive about writing a mud from scratch.
> : >
> : > : This is indeed correct. However, constraints of legacy design certainly
> : > : restrict effective inventiveness.
> : >
> : > Depending on the system, the stock code can either free the admin to
> : > be inventive or tie the admin to legacy decisions. There is nothing
> : > about the concept of stock code that inherently constrains
> : > inventiveness any more that building from scratch inherently
> : > faciliates it.
> : >
> : > Imaginative people with a good stock base will be more inventive than
> : > dullards writing from scratch.
>
> : This last point is true - and rightly so, and some bases are good in that
> : they allow people to easily create a good game world and open it to the
> : public - the problems arise when they want to do something which
> : transcends the capabilities of the server.
>

> : No matter how good your server is, if it doesnt do X (and X may be an
> : obscure feature which you really require for your game), you will have to
> : add X, and that is where (IMHO) trouble starts.
>

> People are trying to use this fact as if it is damning to the concept

> of stock code. If you can't add X in a stock code base, there is no
> way in hell you are going to be able to do it starting from scratch.

But there is, at least, *theoretically*, given the advantage that you

would at least understand the code in its entirity (as a working mud, and
as subsets of systems and mechanisms). If you were writing it from the
word go, all yourself, you could have planned feature X from the offset,
and made allowances for it.

This isn't what most people point out as 'damning' to stock code - but it

is more of a disadvantage there than when you have your own code written
from nil upwards. The best stock muds in my opinion are those which are
well documented, with minimised features (minimised game features at any
rate).

Regards,

[Greg Munt]

On Fri, 15 Aug 1997, Richard Woolcock wrote:

> George Reese wrote:
>
> > I question the sanity of people who use Diku in the face of LPMud,
> > because the LPMud architecture is a lot more sound. So, bottom line,
> > Diku mud people would not make good muds in any universe, so why worry
> > about them?
>

> I find this generalisation most unsatisfying. Please back up your opinion
> that "Diku mud people would not make good muds in any universe". I assume
> also that 'good muds' actually means 'good muds in your opinion', in which
> case I could argue "LPmuds suck because I don't personally like them".

To me, LPMUD == LPC. Therefore, I don't see how anyone can say 'LPMUDs
suck'... An LPMUD library, sure.

> Now if you said "Most dikumuds suck", then I would be inclined to agree
> with you. In fact if you said "Most muds suck", then I would also have to
> agree. If you said "LPmuds are better designed and thus easier to make
> good muds from" then I would also - reluctantly - agree with you. However,
> a good mud can be made from any code base, despite the fact that some might
> require a lot more work than others.

What makes a good mud? <Insert highly subjective comments here.>

[George Reese]

Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: On 14 Aug 1997, George Reese wrote:

: > Matt Chatterley <ne...@itl.net> wrote:
: >
: > : No matter how good your server is, if it doesnt do X (and X may be an

: > : obscure feature which you really require for your game), you will have to
: > : add X, and that is where (IMHO) trouble starts.
: >
: > People are trying to use this fact as if it is damning to the concept
: > of stock code. If you can't add X in a stock code base, there is no
: > way in hell you are going to be able to do it starting from scratch.

: Incorrect. It is not being proposed that adding X to a stock base is

: *impossible* - simply that it will be more difficult, and mean more work
: (depending on the legacy design).

And this is only true *of certain code bases*. This is not true for a
well-designed OO system.

: An example is converting CircleMUD to use an object orientated, event-driven,

: multi-threaded model. This is certainly *possible*...

I think this is an irrelevant point. First off, I would argue that
being OO is a pre-requisite of being judged well-designed.

Given that, the value of a stock base is the object model it offers
you. The features you mention have nothing to do with that.

[George Reese]

Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: On 15 Aug 1997, George Reese wrote:

: > Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: > : On 13 Aug 1997, George Reese wrote:
: >
: > : > The main problem I see here is using bad code bases as the measurement

: > : > of the strengths and weaknesses of stck code. I think you should
: > : > assume a decent quality code base before assessing the strengths and

: > : > weaknesses of the concept of stock code.
: >
: > : Point taken. But... Which of the muds listed on the latest version of The

: > : Mud Tree would you consider 'a decent quality code base'? What proportion
: > : of the Tree do they make up? 90%? 50%? 10%?

: >
: > Again, I cannot speak to anything but LP. And the main mudlib being

: > used today, Lima, I would consider very good quality.

: Perhaps Martin might be able to give a more general answer to this

: question... If the majority of stock code is not 'a decent quality code
: base', why is this?

: > : IMHO the stock/scratch debate is to an extent concerned with what people

: > : do with the code. It is primarily concerned with the tendency towards
: > : sameness. Bad code bases contribute to this heavily - DIKU and its
: > : derivatives are mentioned most of all (it is rare for any other mud type
: > : to be mentioned, in actual fact) in these debates.

: >
: > I question the sanity of people who use Diku in the face of LPMud,

: > because the LPMud architecture is a lot more sound. So, bottom line,
: > Diku mud people would not make good muds in any universe, so why worry
: > about them?

: This sounds like elitism to me, George! (*chuckle*)

The last sentence, yes. The sentiment, no. I challenge anyone to
offer up something that can be done in Diku that cannot be done
better, in a shorter time frame, and easier in LPMud.

: > : Are there certain stock codebases that encourage variety and diversification,

: > : and certain others that positively discourage it?

: >
: > LPMud encourages it,

: If you speak of LPMud generally, it might be argued that you are speaking
: of LPC, in actuality. If this *is* the case, you might equally
: argue that C encourages it, too.

No, LPMud = LPC + the mudlib.

: > especially with the trend away from releasing

: > areas. I do not know of any Nightmare, Discworld, TMI-2, or Lima
: > 'areas' in public release.

: So, is it just the DIKU bases that have stock areas? Why? What is it
: about DIKU that encourages this?

It is a good question. I have no answer for it.

: > : Might we be able to draw up lists of implementation and/or design

: > : features that encourage, and discourage, mud evolution? Are there feature
: > : groups which discourage/encourage it, more than others? Can these be
: > : identified?

: >
: > Who actually gives a damn about mud evolution? The goal is to make a

: > good game. Evolution is not designed.

: Desiring to make a 'better' mud than those currently available is
: indirectly a concern with mud evolution.

: In fact, the stock/scratch threads are *entirely* concerned with mud
: evolution.

I am concerned about people who judge themselves superior to those who
use stock code bases simply because they have managed to do in 2 years
what the people using stock code can do in 2 months.

I give a damn if muds themselves actually advance any.

: The point of the questions was to identify features in a mud that

: encourage similarity. Knowing about them allows people to avoid them.
: (Assuming that they *want* to avoid them... Grumble.)

Stock muds have nothing to do with this. People liking feature X is
what causes that feature to appear all over the place. This is not
rocket science.

[George Reese]

Katrina McClelan <kit...@directcheck.aries.net> wrote:
: >: :: No matter how good your server is, if it doesnt do X (and X may be an
: >: :: obscure feature which you really require for your game), you will have to
: >: :: add X, and that is where (IMHO) trouble starts.

: >: :People are trying to use this fact as if it is damning to the concept
: >: :of stock code. If you can't add X in a stock code base, there is no

: >: :way in hell you are going to be able to do it starting from scratch.

: >: The key is, you may have to HACK X into the stock base.

: >That is completely untrue. You don't have to hack it into a code
: >stock base.

: I wanna know where George got from "may have to" to "have to". You are
: right. You don't HAVE to hack it into stock code. You could always start
: from scratch.

I did not make that leap. In order for the argument against stock
muds to hold *any* water, however, that assertion must be made. And,
as I pointed out, it cannot be made.

: >: I mean, do

: >: you really think you could have made a distributed client/server
: >: database with runtime behavior prediction in the client, and a set
: >: of partial correction protocols, running on merge/split threads
: >: centered on users, out of your NM libs? Or out of a diku, or a MOO?

: >No, but that has nothing to do with anything. Nightmare is not a good
: >code base for writing that kind of mud. Does that mean stock code is
: >bad?

: In terms of doing "X", yes it does.

No, it means NIGHTMARE is bad for doing X. It does not mean stock
code is bad for doing X, and it does not mean that X is the way things
should be. One of those must be the case for your conclusion to be valid.

: >Only if all muds should have the features you list above. If

: >your vision looks nothing like the object model of a given stock base,
: >then *that* stock base is not right for you. You and several other
: >people try to make the leap that because stock mud X is not good for
: >task Y, that stock muds as a concept are bad! That is seriously
: >defective logic.

: I can go along with this, but on the other hand your sumarization of the
: logic leaves out a point.

: Any code base you start with is going to have some set of "X's" that it is
: not good for. A stock base is also going to have some set of "Y's" that

: is is good for, and some set of "Z's" that it already does. Let's assume

: the base is good, and that all the "Z's" included are not what would be
: considered "bulk", and well coded. Let's also assume that good coding and
: documentation makes the set of "Y's" rather large. The set "X's" which is
: everything that is not in the set of "Y's" or the set of "Z's" is going to
: be substantially large. What cripples most stock bases is the one or two
: things that a new implementor wants out of the set of "X's".
: These are
: what have to be basically hacked in. I know what argument is going to be
: thrown back - that you should stay out of the "X's" if you use this
: codebase. Well then you end up with a gaggle of muds that just do the
: same old set of "Y's" and ignore the vast set of "X's" that are out
: there.

You don't need the X's to make your mud unique or interesting.

: This is also a bad thing, that we've also mentioned as being a

: disadvantage of starting from stock. You either hack in your innovative
: dreams, or you do the same old stuff that everyone else is doing.

Where do you get from not being able to do certain things that are
limited *for technical reasons* to 'hacking in your innovative dreams'
or 'doing the same old stuff everyone else is doing'.

Let's take Nightmare for example. It is designed in a very
well-structed, OO fashion exactly because I do not want to be limited
in what I can do as my imagination grows.

Since NM was built, I have been able to easily extend it by adding
support for things like:

* flying
* swimming
* permanent death and the undead
* a spell system in complete opposition to my original one
* from add_action() to NLP

These are off the top of my head. These are all innovative
X's... things NM was not designed to do that NM now has that no other
NM mud on earth has. This is because NM was well-designed.

The things that Nathan mentions are pure technical limitations of the
language in which I am programming.

: Granted, very occasionally a new idea surfaces that ends up coincidentally

: being in the set of "Y's" instead of the set of "X's". But the chance of
: your ideas hitting the set of "X's" is rather high as well. The next
: thing you'll say is that you should find a codebase that has all of your
: ideas in the set of "Y's". You know how you do that? You write it
: yourself.

No, I am not suggesting that. I am suggesting you think a bit about
what you want to do *before* chosing a codebase. Then you examine
existing ones and compare theior object models to your ideas. Find
the best fit and work from there. Again, the issue with Nathan's
ideas and Nightmare are that his ideas are COMPLETELY different from
what Nightmare was designed for.

Back to the wheel analogy, Nathan using Nightmare would be like trying
to build a ship from a wheel. I am talking about people who just
might want to make radials from a carriage wheel...

: Stock bases are like strainers that take an infinite set of ideas and

: possibilities and filter out either the ideas themselves, or the proper
: implementation of them. This is going to be true of any stock base. If I
: released my code I'd argue against people using it (which is why I don't

: have plans to release it). Why? Because you can run my code and run a

: mud that does what *I* wanted it to do, or you can write one that does
: what *you* want it to do. Why limit yourself from the start by using
: someone else's baggage?

Because you are way too unimaginative to see how liberating a stock
base is.

[Richard Woolcock]

Matt Chatterley wrote:

>
> On Fri, 15 Aug 1997, Greg Munt wrote:
>
> > On Fri, 15 Aug 1997, Richard Woolcock wrote:
> >
> > > George Reese wrote:
> > >

> > > > I question the sanity of people who use Diku in the face of LPMud,
> > > > because the LPMud architecture is a lot more sound. So, bottom line,
> > > > Diku mud people would not make good muds in any universe, so why worry
> > > > about them?
> > >

> > > I find this generalisation most unsatisfying. Please back up your opinion
> > > that "Diku mud people would not make good muds in any universe". I assume
> > > also that 'good muds' actually means 'good muds in your opinion', in which
> > > case I could argue "LPmuds suck because I don't personally like them".
> >
> > To me, LPMUD == LPC. Therefore, I don't see how anyone can say 'LPMUDs
> > suck'... An LPMUD library, sure.
>

> Hmm. You could categorise them all as sucking, if you disliked LPC
> immensely, I suppose. I also dislike the Diku code(s), although Smaug is
> a lot better if you look at it - but the world file format in many Diku
> derivatives is simply too limiting (not that world files are a bad thing
> in all cases, just that they are too restrictive here).

Smaug *is* a lot better, but it doesn't encourage much of a rewrite, just
adding extra bits on the top. I would be surprised if I ever saw a smaug
based mud that didn't look like every other stock smaug.

I agree about the world files too, which is why mine are coming out.

> > > Now if you said "Most dikumuds suck", then I would be inclined to agree
> > > with you. In fact if you said "Most muds suck", then I would also have to
> > > agree. If you said "LPmuds are better designed and thus easier to make
> > > good muds from" then I would also - reluctantly - agree with you. However,
> > > a good mud can be made from any code base, despite the fact that some might
> > > require a lot more work than others.
> >
> > What makes a good mud? <Insert highly subjective comments here.>
>

> Heh. Okay, I'll bite, reel me in on this one:
>
> "A good, solid, and above all else, well thought out theme."

I disagree. A good mud requires what you say, however a good theme does not
necessarily result in a good mud. It is also very subjective of course - if
everyone had the same opinion about 'what was good' then there would be one
very popular mud and all the rest would be empty...

KaVir.

[Richard Woolcock]

George Reese wrote:
> [huge post snipped, I only want to reply to this bit]

> The last sentence, yes. The sentiment, no. I challenge anyone to
> offer up something that can be done in Diku that cannot be done
> better, in a shorter time frame, and easier in LPMud.

The most obvious answer is "Get something up and running" which is,
unfortunately, why there are so many diku-based stock muds around.
People don't want to spend years working on something before they
see results, they want something *NOW*.

Note also that if people have played diku-muds all their lives, they
will want to keep playing them - and when they decide its time to
open up their own mud, chances are they will open up one of the same
type. I started with a merc because I liked that type of mud,
however I never intended to really run it - just teach myself to
code C so I could help out on another mud i was co-imping. It was
only by accident that I put it on a friends university account and
found that everyone liked playing it, and thus it went on from
there...thinking back, yes, it might well have been better to use a
different code base, but as the muds stands now it would take a lot
more work to do that than to just change what I already have.

KaVir.

[George Reese]

Richard Woolcock <Ka...@dial.pipex.com> wrote:

: George Reese wrote:
: > [huge post snipped, I only want to reply to this bit]
: > The last sentence, yes. The sentiment, no. I challenge anyone to
: > offer up something that can be done in Diku that cannot be done
: > better, in a shorter time frame, and easier in LPMud.

: The most obvious answer is "Get something up and running" which is,
: unfortunately, why there are so many diku-based stock muds around.
: People don't want to spend years working on something before they
: see results, they want something *NOW*.

Never seen LPMud 2.4.5 then?

[George Reese]

Matt Chatterley <ne...@itl.net> wrote:
: On Fri, 15 Aug 1997, Greg Munt wrote:

: > On 15 Aug 1997, George Reese wrote:
: >
: > > Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: > > : On 13 Aug 1997, George Reese wrote:
: > >
: > > : > The main problem I see here is using bad code bases as the measurement
: > > : > of the strengths and weaknesses of stck code. I think you should
: > > : > assume a decent quality code base before assessing the strengths and
: > > : > weaknesses of the concept of stock code.
: > >
: > > : Point taken. But... Which of the muds listed on the latest version of The
: > > : Mud Tree would you consider 'a decent quality code base'? What proportion
: > > : of the Tree do they make up? 90%? 50%? 10%?
: > >
: > > Again, I cannot speak to anything but LP. And the main mudlib being
: > > used today, Lima, I would consider very good quality.
: >
: > Perhaps Martin might be able to give a more general answer to this
: > question... If the majority of stock code is not 'a decent quality code
: > base', why is this?

: Firstly, I agree with Georges point that in many aspects Lima is very
: good quality - some of the other LP libs available are quite good, but
: others are simply terrible. The ratio is probably about 2:8 good to
: bad(in varying states).

That ratio does not matter. What matters is usage. And I would
venture most people starting an LPMud today are using Lima.

: > The point of the questions was to identify features in a mud that
: > encourage similarity. Knowing about them allows people to avoid them.
: > (Assuming that they *want* to avoid them... Grumble.)

: Many of the Stock muds are bad in my eyes because they have no theme. If
: you have a theme, it encourages change indirectly.

Building a mud from scratch does not make a theme.

[Jacob Hallen]

In article <Pine.SOL.3.91.970816074531.14050C-100000@hades>,
Matt Chatterley <ne...@itl.net> wrote:

>> This sounds like elitism to me, George! (*chuckle*)
>

>Egad. Someone in this group being an elitist? *paranoid gaze around*

Being elitist is the recipe for quality and uniqueness. Being egalitarian
in the world of mud development is the recipe for low quality or even
disaster.

>> > : Are there certain stock codebases that encourage variety and diversification,
>> > : and certain others that positively discourage it?
>> >
>> > LPMud encourages it,

Well, I tend to disagree with this statement. LPMud _allows_ you to produce
variety and diversification. However, by the way stock code provides a
complete set of functions to produce stock stuff, it passively dicourages
the production of new and unique stuff.
If we should encourage the production of nifty things, we should produce
a base which forces the user to complete the design of every object.

>Why does Diku encourage it? Because it is very easy to 'plug in' a set of
>world files?

And fairly difficult to make your own... Also, the culture and tradition
of DIKUs is to provide a killing ground, while the tradition of LPMuds is
to provide a design space, where players get to use the code.

>> In fact, the stock/scratch threads are *entirely* concerned with mud
>> evolution.

I care about Mud evolution, but only as far as the evolution of my Mud goes.
There are only so many really talented people available at one time. It's
such a bloody waste that some of them plow their efforts into muds that are
destined for obscurity or the scap heap.

Anyway, if you feel you have a talent that is not used to its full potential,
you are always welcome to check out Genesis (spica3.cs.chalmers.se 3011).
We are starting a big revision project shortly, and there will be plenty
of opportunity to show brilliance.

[Matt Chatterley]

On Fri, 15 Aug 1997, Greg Munt wrote:

> On Fri, 15 Aug 1997, Richard Woolcock wrote:
>
> > George Reese wrote:
> >
> > > I question the sanity of people who use Diku in the face of LPMud,
> > > because the LPMud architecture is a lot more sound. So, bottom line,
> > > Diku mud people would not make good muds in any universe, so why worry
> > > about them?
> >
> > I find this generalisation most unsatisfying. Please back up your opinion
> > that "Diku mud people would not make good muds in any universe". I assume
> > also that 'good muds' actually means 'good muds in your opinion', in which
> > case I could argue "LPmuds suck because I don't personally like them".
>
> To me, LPMUD == LPC. Therefore, I don't see how anyone can say 'LPMUDs
> suck'... An LPMUD library, sure.

Hmm. You could categorise them all as sucking, if you disliked LPC
immensely, I suppose. I also dislike the Diku code(s), although Smaug is
a lot better if you look at it - but the world file format in many Diku
derivatives is simply too limiting (not that world files are a bad thing
in all cases, just that they are too restrictive here).

> > Now if you said "Most dikumuds suck", then I would be inclined to agree
> > with you. In fact if you said "Most muds suck", then I would also have to
> > agree. If you said "LPmuds are better designed and thus easier to make
> > good muds from" then I would also - reluctantly - agree with you. However,
> > a good mud can be made from any code base, despite the fact that some might
> > require a lot more work than others.
>
> What makes a good mud? <Insert highly subjective comments here.>

Heh. Okay, I'll bite, reel me in on this one:

"A good, solid, and above all else, well thought out theme."

Regards,

[Matt Chatterley]

On Fri, 15 Aug 1997, Greg Munt wrote:

> On 15 Aug 1997, George Reese wrote:
>
> > Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
> > : On 13 Aug 1997, George Reese wrote:
> >
> > : > The main problem I see here is using bad code bases as the measurement
> > : > of the strengths and weaknesses of stck code. I think you should
> > : > assume a decent quality code base before assessing the strengths and
> > : > weaknesses of the concept of stock code.
> >
> > : Point taken. But... Which of the muds listed on the latest version of The
> > : Mud Tree would you consider 'a decent quality code base'? What proportion
> > : of the Tree do they make up? 90%? 50%? 10%?
> >
> > Again, I cannot speak to anything but LP. And the main mudlib being
> > used today, Lima, I would consider very good quality.
>
> Perhaps Martin might be able to give a more general answer to this
> question... If the majority of stock code is not 'a decent quality code
> base', why is this?

Firstly, I agree with Georges point that in many aspects Lima is very
good quality - some of the other LP libs available are quite good, but
others are simply terrible. The ratio is probably about 2:8 good to
bad(in varying states).

In terms of Diku derivs, I dislike Diku/Circle/Rom/Merc(to a lesser
degree), but Smaug is a definite improvement in some ways, so we have a
1:4 ratio of good to bad.

PennMUSH and TinyMUSH do not have such things as stock 'bases' (Because
there is no world of any sort supplied - only the basic commands, which
are extended by the world you build in them), although there is a growing
trend to globally release code. This has less impact on these games,
which are used for purist (usually!) roleplay.

> > : IMHO the stock/scratch debate is to an extent concerned with what people
> > : do with the code. It is primarily concerned with the tendency towards
> > : sameness. Bad code bases contribute to this heavily - DIKU and its
> > : derivatives are mentioned most of all (it is rare for any other mud type
> > : to be mentioned, in actual fact) in these debates.
> >

> > I question the sanity of people who use Diku in the face of LPMud,
> > because the LPMud architecture is a lot more sound. So, bottom line,
> > Diku mud people would not make good muds in any universe, so why worry
> > about them?
>

> This sounds like elitism to me, George! (*chuckle*)

Egad. Someone in this group being an elitist? *paranoid gaze around*

> > : Are there certain stock codebases that encourage variety and diversification,
> > : and certain others that positively discourage it?
> >
> > LPMud encourages it,
>

> If you speak of LPMud generally, it might be argued that you are speaking
> of LPC, in actuality. If this *is* the case, you might equally
> argue that C encourages it, too.

I think its a little silly to argue that a language in particular
encourages this; although of course language is critical in terms of a
design consideration.

> > especially with the trend away from releasing
> > areas. I do not know of any Nightmare, Discworld, TMI-2, or Lima
> > 'areas' in public release.
>
> So, is it just the DIKU bases that have stock areas? Why? What is it
> about DIKU that encourages this?

Probably. Tiny/Penn/LP bases do not typically have 'stock areas'
available - certainly not released without the lib, and the NM libs only
came with a few example rooms from the main town, IIRC.

Why does Diku encourage it? Because it is very easy to 'plug in' a set of
world files?

> > : Might we be able to draw up lists of implementation and/or design
> > : features that encourage, and discourage, mud evolution? Are there feature
> > : groups which discourage/encourage it, more than others? Can these be
> > : identified?
> >
> > Who actually gives a damn about mud evolution? The goal is to make a
> > good game. Evolution is not designed.
>
> Desiring to make a 'better' mud than those currently available is
> indirectly a concern with mud evolution.

It is the same phenomenon that has left us with enough armament to
happily kill ourselves off if someone should do the wrong thing at the
wrong time. The 'build a better bomb' phenomenon, combined with the
wonderful gift of science has left us with atomic weaponry. Oh that
'build a better mud' could leave us with something as remarkably more
powerful than our slings and pebbles.

> In fact, the stock/scratch threads are *entirely* concerned with mud
> evolution.

And a chance for bloody good whinge!

> The point of the questions was to identify features in a mud that
> encourage similarity. Knowing about them allows people to avoid them.
> (Assuming that they *want* to avoid them... Grumble.)

Many of the Stock muds are bad in my eyes because they have no theme. If
you have a theme, it encourages change indirectly.

Regards,

[Broly]

[mammoth snip]
> > : >scratch disadvatange: you are reinventing the wheel, which is an
> > : >extremely bad programming habit.
> >
> > : I have addressed this before. It's like using a wooden carriage wheel
> > : when you envision Goodyear Radials. Sometimes reinventing the wheel is a
> > : good thing. Imagine if we had decided the eniac was as good a computer as
> > : you can make and never reinvented it. (LP would NEVER have run on
> > : anything with that lack of power (tounge in cheek)). Rewritting identical
> > : code is a waste of time and bad programming. Writting a better program
> > : that does the same (general) thing is not nessecarily bad. If we listened
> > : to George all games would be pacman with different maze maps and
> > : variations off of ghosts and the chomping ball.
> >
> > We are not talking about writing good year radials here when you have
> > only a wooden carriage. We are talking about people who want a wooden
> > carriage wheel when one already exists. If you want a good year
> > radial, then you build your good year radial.
>
> Good, as metaphors go. There are some bases out there whose wheels are
> probably square, and others who have superb tires. But.. something..
> well.. I can't actually continue and expand this analogy. Heh.
>
You are still thinking in terms of what has come before. Who says a
carriage needs wheels. I was thinking of creating an air-cushion under
the vehicle using some of the same principles as the bullet train. Now
there's a real problem using the radial as a guide in doing this. Or any
tire for that matter. Hell, old roads even gotta be replaced. Not sure
where this analogy is going anymore...

Gunther

[Matt Chatterley]

On 16 Aug 1997, Jacob Hallen wrote:

> In article <Pine.SOL.3.91.970816074531.14050C-100000@hades>,
> Matt Chatterley <ne...@itl.net> wrote:
>

> >> This sounds like elitism to me, George! (*chuckle*)
> >
> >Egad. Someone in this group being an elitist? *paranoid gaze around*
>

> Being elitist is the recipe for quality and uniqueness. Being egalitarian
> in the world of mud development is the recipe for low quality or even
> disaster.

Couldn't be said better.

> >> > : Are there certain stock codebases that encourage variety and diversification,
> >> > : and certain others that positively discourage it?
> >> >
> >> > LPMud encourages it,
>

> Well, I tend to disagree with this statement. LPMud _allows_ you to produce
> variety and diversification. However, by the way stock code provides a
> complete set of functions to produce stock stuff, it passively dicourages
> the production of new and unique stuff.

Yeah. The main effect here is probably on the novice who is using stock
code to learn, and is thus being influenced by its design legacy - what
it can and cannot do.

> If we should encourage the production of nifty things, we should produce
> a base which forces the user to complete the design of every object.

Not an easy task.

> >Why does Diku encourage it? Because it is very easy to 'plug in' a set of
> >world files?
>

> And fairly difficult to make your own... Also, the culture and tradition
> of DIKUs is to provide a killing ground, while the tradition of LPMuds is
> to provide a design space, where players get to use the code.

This is probably quite good reasoning. I won't comment further on world
files - a good thread on that sprang off recently, and covered most of
the bases.

[Snip]

[Katrina McClelan]

>: No matter how good your server is, if it doesnt do X (and X may be an
>: obscure feature which you really require for your game), you will have to
>: add X, and that is where (IMHO) trouble starts.

>People are trying to use this fact as if it is damning to the concept

>of stock code. If you can't add X in a stock code base, there is no
>way in hell you are going to be able to do it starting from scratch.

It's not you CAN'T do X in stock code, it's you can't do X EASILY in stock
code. It's you'd have to rewrite of stock code to get it to do X.
It's you'd have to expend more time and effort to do X as part of stock
code than you would to just scrap it and start over and plan for X in the
first place.

The argument has deterioated to "scratch muds are good so stock muds
suck", and "stock muds don't suck, so scratch muds must". This is really
not the main points of either side. The concept of stock code is not
inherently so flawed to be dismissed. That said, even with the PERFECT
stock base there are still reasons to start over. Additionally, a good
majority of the stock mud code out there has additional disadvantages. If
the world were ideal George may have more ground to stand on, however as
things are now there is not much in the line of OO stock code out there
that can miraculously do anything you'd ever want it to with minor
alterations. If one airplane crashes out of a million than you can't
judge all airplanes by the one that crashed. If a good percentage of them
crashed then you can make a much more valid generalization. Does this
mean that the ideal of airplanes not crashing gets swept over? No, but it
does mean that until they get airplanes to that point I'll stay off them
thank you very much. The flip side, starting from scratch has it's
advantages, and it's disadvantages. Time seems to be the main down side.
This is true, however there are alot of headaches and hassles to be
avoided by using your own code.

-Kat

[Katrina McClelan]

In <5td77m$amg$1...@darla.visi.com> George Reese <bo...@imaginary.com> writes:

>: It's not you CAN'T do X in stock code, it's you can't do X EASILY in stock

>: code. It's you'd have to rewrite of stock code to get it to do X.
>: It's you'd have to expend more time and effort to do X as part of stock
>: code than you would to just scrap it and start over and plan for X in the
>: first place.

>Again, this is only true of bad stock code. And using bad stock code
>is a very bad measuring stick when addressing the concept of stock
>muds.

>With a good stock base, you can do X many, many times faster *and
>better* than you could from scratch.

Hogwash! Perhaps faster (if you've spent the overhead time to totally
understand the codebase that no one advocating stock seems to mention),
but not better. You're going to be able to write a better set of routines
to do X when the main engine directly supports it than when it doesn't.
Not saying that a set of routines written by programmer X on top of stock
won't beat routines by programmer Y from scratch... such is possible if
programmer X is alot better than programmer Y. BUT the same programmer
giving full effort to both tasks will be able to do it better if he
designs for it from the start. Unless you want to rewrite the engine too,
but by the time you do that to a stock base why bother?

>In fact, people who write a mud from scratch *that uses largely
>similar feature sets to existing good stock bases* are bad
>programmers. Their muds may or may not suck.

And I suppose the person who wrote quick sort is a bad programmer since
his algorithm did exactly the same thing that bubble sort did? I mean
there are not any extra features. It does identically the same thing.

>: The concept of stock code is not

>: inherently so flawed to be dismissed. That said, even with the PERFECT
>: stock base there are still reasons to start over. Additionally, a good
>: majority of the stock mud code out there has additional
>: disadvantages.

>Those reasons are few and far between.

1) You use someone else's code and get their baggage. Even if they wrote
good code you may not be comfortable with their style and design methods.
2) You gain a much more intrecate understanding of the code if you wrote
all of it than you do if you use someone elses. It can take much more
time to fully understand how a codebase gels together than it would have
to write one yourself.
3) Stock codebases usually have licenses and such attached to them that
may or may not be acceptable to someone. This may not apply to all of
them, but it does to enough not to be "few and far between".
4) There's a certain sense of accomplishment when you tie the loose ends
and get your own code to work. You get this in small doses when you hack
things on top of stock. It's nothing compared to seeing your own world
and program take shape.
5) You learn alot more starting over than fooling around with stock code.
Granted it's the throw a baby in the water kind of thing, but you do learn
more.
6) Writing from scratch can be fun compared to hacking over stock. Sure,
you get to see more immediate results when using stock, but watching low
level features form, and debugging them can be alot more fun. Actually,
oddly enough, some of my bugs were hillarious... then I fixed them.
7) speaking of debugging, when you do screw up your own code it's alot
more straight-forward to find the problem since you put the parts together
and know how they intermingle.

BTW: The above all assume a "perfect" codebase for your needs. In truth
the only "perfect" codebase for your needs is the one you write yourself.

>Lima and Nightmare are pretty damn close. You don't need a perfect
>world.

No, but it's still disadvantageous to use an imperfect model when you can
write one better suited to your needs yourself. You don't NEED to run a
mud either, may I remind you, so what you "need" is not the issue here.

And I'd still be using someone else's code, that I would not nessecarily
understand 100%, even if Nightmare was the best thing since sliced bread.

>: If one airplane crashes out of a million than you can't

>: judge all airplanes by the one that crashed. If a good percentage of them
>: crashed then you can make a much more valid generalization. Does this
>: mean that the ideal of airplanes not crashing gets swept over? No, but it
>: does mean that until they get airplanes to that point I'll stay off them
>: thank you very much. The flip side, starting from scratch has it's
>: advantages, and it's disadvantages. Time seems to be the main down
>: side.

>Time and bad programming habits.

I guess it's bad programming habits to rewrite code better. What a sad
state of affairs. I notice Apple is rewritting their OS. I guess their
all really stupid. Imagine starting over when what you have isn't
exactly what you want. What nerve!

>: This is true, however there are alot of headaches and hassles to be

>: avoided by using your own code.

>Only if you choose your stock base poorly.

Licenses and learning the new code written by someone else that does not
use the same conventions in programming are two headaches that will follow
you no matter what base you use. Given a set of goals and a specific
bunch of code there are going to be other problems. These can range from
vast to few, but they'll still be there unless you literally want mud in
the box which isn't a good thing either.

-Kat

[Nathan F. Yospe]

George Reese <bo...@imaginary.com> wrote:

:Katrina McClelan <kit...@directcheck.aries.net> wrote:

:: >: No matter how good your server is, if it doesnt do X (and X may be an

:: >: obscure feature which you really require for your game), you will have to
:: >: add X, and that is where (IMHO) trouble starts.

:: >People are trying to use this fact as if it is damning to the concept
:: >of stock code. If you can't add X in a stock code base, there is no

:: >way in hell you are going to be able to do it starting from scratch.

:: It's not you CAN'T do X in stock code, it's you can't do X EASILY in stock

:: code. It's you'd have to rewrite of stock code to get it to do X.
:: It's you'd have to expend more time and effort to do X as part of stock
:: code than you would to just scrap it and start over and plan for X in the
:: first place.

:Again, this is only true of bad stock code. And using bad stock code
:is a very bad measuring stick when addressing the concept of stock
:muds.

:With a good stock base, you can do X many, many times faster *and
:better* than you could from scratch.

George, you already said that MY X's were not suited to stock... are
you claiming you were wrong now? And I don't think I could have done
them faster OR better in ANY existing stock base, or theoretical one
for that matter, than I did going from scratch. Of course, the
internal language might have been easier if someone else had written
it... except that it is VERY highly geared to the mud... and that is
how it OUGHT to be, for my case. Sooo... your above statement is not
true in my case, and probably not in Chris L's case, or John G's, or
a number of others who post here frequently.

:: The argument has deterioated to "scratch muds are good so stock muds

:: suck", and "stock muds don't suck, so scratch muds must". This is really
:: not the main points of either side.

:I am not sure what newsgroup you are posting in, but I have not heard
:anyone suggest scratch muds inherently suck. It seems to be the
:hubris of stock mud bashers, however, that believes thairs is the one
:true way.

No... most of us simply hate clones.

:In fact, people who write a mud from scratch *that uses largely

:similar feature sets to existing good stock bases* are bad
:programmers. Their muds may or may not suck.

Not if it is better implemented, cleaner, easier to work with, more OO,
etc, etc, etc.

:And the only person I have heard doing anything that an existing stock
:base would not support is Nathan.

Whoops... made an exception in my case. Well, John G, Chris L, The Cold
crew, and several others should be included with me. (Chris L should be
familiar... he's the one using the transactional database with rollback
and a single commit thread (I think that's right) for his mud.)

:: The concept of stock code is not

:: inherently so flawed to be dismissed. That said, even with the PERFECT
:: stock base there are still reasons to start over. Additionally, a good
:: majority of the stock mud code out there has additional
:: disadvantages.

:Those reasons are few and far between.

Debateable. Experience is a pretty good reason, for example.

:: If

:: the world were ideal George may have more ground to stand on, however as
:: things are now there is not much in the line of OO stock code out there
:: that can miraculously do anything you'd ever want it to with minor
:: alterations.

:Lima and Nightmare are pretty damn close. You don't need a perfect
:world.

Nightmare (3) did not impress me... 4 and 5 would have to have been MANY
orders of magnitude better... and Lima, frankly, is more a testiment to
LPC than to itself. Its OK, I suppose. A hell of a lot better than Diku,
or LPMud3.x, or the MOOs I've seen, but still...

:: If one airplane crashes out of a million than you can't

:: judge all airplanes by the one that crashed. If a good percentage of them
:: crashed then you can make a much more valid generalization. Does this
:: mean that the ideal of airplanes not crashing gets swept over? No, but it
:: does mean that until they get airplanes to that point I'll stay off them
:: thank you very much. The flip side, starting from scratch has it's
:: advantages, and it's disadvantages. Time seems to be the main down
:: side.

:Time and bad programming habits.

Uhhh... justify this. Without the code reuse argument, its stale and
inaccurate. I've been programming professionally for four years, and
I've never seen a situation where prolonged code reuse wasn't a falacy.
^^^^^^^^^
A lot of muds have prolonged it, Lima included.

:: This is true, however there are alot of headaches and hassles to be

:: avoided by using your own code.

:Only if you choose your stock base poorly.

Or if there is no codebase that does what you want AND is clean available.

--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
UH Manoa Physics | Write poetry. Be an artist. Plot world domination.
Biomedical Phys. | Panthers make great pets. Muhahahahahahahahahaha!!

[John G.]

Nathan Yospe: and Kevin Chen::
::I suppose it's a question of scale and focus again. Coming from

::a fantasy AberMUD background, I find it convenient as a player to
::know that a road is long and winding, but not to have to actually
::navigate the long, winding road.

dunno if this applies at all to your comment, but in addition to
the regular navigation methods (n,e,s,w,etc.) you can implement
the [tedious if over-used] turn-right-15degrees-walk-stop. but of
course it's the "walk to" command that solves most travel needs
in a coord-based mud. just as people don't bother to calculate
their approach vector or absolute direction, so i'd rather let the
mud take care of figuring the exact path.

::Of course, that sort of approach makes other modes of

::transportation where geography is relevant, such as flight,
::more or less impossible without cheesy kludges.

ayup. in fact I think I'm encouraging kludgy flight (turn,stop,
forward,turn some more) just so that flying will be a much more
prized skill since it's harder to do. the victor in aerial combat
will indeed be the one with the best grasp of 3-d-spatial events.

: That's pretty much the heart of it. I am still working on the "ed"
: of "implemented" - it is still an "ing" for now... but what it comes
: down to is, I've designed a simulation engine, not a text display
: machine.

aren't we all? :)
Cheers,
--
John Greenawalt (as...@pixi.com)
"In my mind and in my car, we can't rewind - we've
gone too far. Pictures came and broke your heart."
(TheBuggles,"VideoKilledTheRadioStar")

[George Reese]

Katrina McClelan <kit...@directcheck.aries.net> wrote:
: >: No matter how good your server is, if it doesnt do X (and X may be an
: >: obscure feature which you really require for your game), you will have to
: >: add X, and that is where (IMHO) trouble starts.

: >People are trying to use this fact as if it is damning to the concept
: >of stock code. If you can't add X in a stock code base, there is no
: >way in hell you are going to be able to do it starting from scratch.

: It's not you CAN'T do X in stock code, it's you can't do X EASILY in stock
: code. It's you'd have to rewrite of stock code to get it to do X.
: It's you'd have to expend more time and effort to do X as part of stock
: code than you would to just scrap it and start over and plan for X in the
: first place.

Again, this is only true of bad stock code. And using bad stock code
is a very bad measuring stick when addressing the concept of stock
muds.

With a good stock base, you can do X many, many times faster *and
better* than you could from scratch.

: The argument has deterioated to "scratch muds are good so stock muds

: suck", and "stock muds don't suck, so scratch muds must". This is really
: not the main points of either side.

I am not sure what newsgroup you are posting in, but I have not heard
anyone suggest scratch muds inherently suck. It seems to be the
hubris of stock mud bashers, however, that believes thairs is the one
true way.

In fact, people who write a mud from scratch *that uses largely

similar feature sets to existing good stock bases* are bad
programmers. Their muds may or may not suck.

And the only person I have heard doing anything that an existing stock

base would not support is Nathan.

: The concept of stock code is not

: inherently so flawed to be dismissed. That said, even with the PERFECT
: stock base there are still reasons to start over. Additionally, a good
: majority of the stock mud code out there has additional
: disadvantages.

Those reasons are few and far between.

: If

: the world were ideal George may have more ground to stand on, however as
: things are now there is not much in the line of OO stock code out there
: that can miraculously do anything you'd ever want it to with minor
: alterations.

Lima and Nightmare are pretty damn close. You don't need a perfect
world.

: If one airplane crashes out of a million than you can't

: judge all airplanes by the one that crashed. If a good percentage of them
: crashed then you can make a much more valid generalization. Does this
: mean that the ideal of airplanes not crashing gets swept over? No, but it
: does mean that until they get airplanes to that point I'll stay off them
: thank you very much. The flip side, starting from scratch has it's
: advantages, and it's disadvantages. Time seems to be the main down
: side.

Time and bad programming habits.

: This is true, however there are alot of headaches and hassles to be

: avoided by using your own code.

Only if you choose your stock base poorly.

--

[George Reese]

Katrina McClelan <kit...@directcheck.aries.net> wrote:

: In <5td77m$amg$1...@darla.visi.com> George Reese <bo...@imaginary.com> writes:

: >: It's not you CAN'T do X in stock code, it's you can't do X EASILY in stock
: >: code. It's you'd have to rewrite of stock code to get it to do X.
: >: It's you'd have to expend more time and effort to do X as part of stock
: >: code than you would to just scrap it and start over and plan for X in the
: >: first place.

: >Again, this is only true of bad stock code. And using bad stock code
: >is a very bad measuring stick when addressing the concept of stock
: >muds.

: >With a good stock base, you can do X many, many times faster *and
: >better* than you could from scratch.

: Hogwash! Perhaps faster (if you've spent the overhead time to totally
: understand the codebase that no one advocating stock seems to mention),
: but not better. You're going to be able to write a better set of routines
: to do X when the main engine directly supports it than when it doesn't.
: Not saying that a set of routines written by programmer X on top of stock
: won't beat routines by programmer Y from scratch... such is possible if
: programmer X is alot better than programmer Y. BUT the same programmer
: giving full effort to both tasks will be able to do it better if he
: designs for it from the start. Unless you want to rewrite the engine too,
: but by the time you do that to a stock base why bother?

The stock mud has proven, tested code. Proven, tested code is always
better than stuff done from scratch unless there was already a flaw in
the proven code.. then it is not very proven.

: >In fact, people who write a mud from scratch *that uses largely

: >similar feature sets to existing good stock bases* are bad
: >programmers. Their muds may or may not suck.

: And I suppose the person who wrote quick sort is a bad programmer since
: his algorithm did exactly the same thing that bubble sort did? I mean
: there are not any extra features. It does identically the same thing.

This is entirely a speed issue done for reasons of speed. It is not
done just for the sake of doing a different sort. If they were
exactly the same, then it would have been a waste of time.

: >: The concept of stock code is not

: >: inherently so flawed to be dismissed. That said, even with the PERFECT
: >: stock base there are still reasons to start over. Additionally, a good
: >: majority of the stock mud code out there has additional
: >: disadvantages.

: >Those reasons are few and far between.

Before going over the list below, I would also like to state you
demonstrate a terrible misunderstanding of the way things work in a
well-run OO environment. Most of the stuff you say just simply is not
true.

: 1) You use someone else's code and get their baggage. Even if they wrote

: good code you may not be comfortable with their style and design
: methods.

There are two points here:
* You get someone else's baggage
That is simply untrue with a good code base.

* You may not be comfortable with their style and design methods.
A good programmer can deal with multiple good programming styles.
Similarly, if the original design methods are sound, a good programmer
should be able to deal with those as well. Only a bad programmer
begins something from scratch because they have a preferred
programming or design style.

: 2) You gain a much more intrecate understanding of the code if you wrote

: all of it than you do if you use someone elses. It can take much more
: time to fully understand how a codebase gels together than it would have
: to write one yourself.

Again, you are making two separate points:
* You gain a better understanding of the code.
Yes, you do. No one understands code better than the person who wrote
it. However, you lose any so-called benefits of this if there is
anyone other than yourself developing for the mud.

* It can take more time to understand a stock codebase than to write yourself.
Complete bullshit. There are 3-5 person/years in writing a
sufficiently developed code base and mud. Understanding a stock code
base is about 6 months.

: 3) Stock codebases usually have licenses and such attached to them that

: may or may not be acceptable to someone. This may not apply to all of
: them, but it does to enough not to be "few and far between".

It is an issue, but it is not something inherent to stock code bases.
I don't see this as a relevant to the point of whether the concept of
stock muds is problematic.

: 4) There's a certain sense of accomplishment when you tie the loose ends

: and get your own code to work. You get this in small doses when you hack
: things on top of stock. It's nothing compared to seeing your own world
: and program take shape.

True, but it is still bad programming practice and prone to errors.

: 5) You learn alot more starting over than fooling around with stock code.

: Granted it's the throw a baby in the water kind of thing, but you do learn
: more.

Depends on your skill level. Some will learn more from a
well-designed stock system, some will learn more from doing it from
scratch.

: 6) Writing from scratch can be fun compared to hacking over stock. Sure,

: you get to see more immediate results when using stock, but watching low
: level features form, and debugging them can be alot more fun. Actually,
: oddly enough, some of my bugs were hillarious... then I fixed them.

If your goal is to sit and write code... sure, it is a barrel of
laughs. If your goal is to create a mud, then no.

: 7) speaking of debugging, when you do screw up your own code it's alot

: more straight-forward to find the problem since you put the parts together
: and know how they intermingle.

It depends on how the code base is written.

: BTW: The above all assume a "perfect" codebase for your needs. In truth

: the only "perfect" codebase for your needs is the one you write yourself.

This is complete crap. Everything I have stated is an underlying
premise of object-oriented software engineering.

: >Lima and Nightmare are pretty damn close. You don't need a perfect
: >world.

: No, but it's still disadvantageous to use an imperfect model when you can
: write one better suited to your needs yourself. You don't NEED to run a
: mud either, may I remind you, so what you "need" is not the issue here.

No matter what model you use, even if you write it yourself, it will
be imperfect.

: And I'd still be using someone else's code, that I would not nessecarily

: understand 100%, even if Nightmare was the best thing since sliced bread.

That is not a bad thing, and eventually you would understand it 100%.

: >: If one airplane crashes out of a million than you can't

: >: judge all airplanes by the one that crashed. If a good percentage of them
: >: crashed then you can make a much more valid generalization. Does this
: >: mean that the ideal of airplanes not crashing gets swept over? No, but it
: >: does mean that until they get airplanes to that point I'll stay off them
: >: thank you very much. The flip side, starting from scratch has it's
: >: advantages, and it's disadvantages. Time seems to be the main down
: >: side.

: >Time and bad programming habits.

: I guess it's bad programming habits to rewrite code better. What a sad
: state of affairs. I notice Apple is rewritting their OS. I guess their
: all really stupid. Imagine starting over when what you have isn't
: exactly what you want. What nerve!

You just don't get it, do you?

There is a difference between tuning existing objects to be better and
simply rewriting them because you want to write them from scratch.
And Apple is not rewriting their OS.

: >: This is true, however there are alot of headaches and hassles to be

: >: avoided by using your own code.

: >Only if you choose your stock base poorly.

: Licenses and learning the new code written by someone else that does not
: use the same conventions in programming are two headaches that will follow
: you no matter what base you use.

Only for the first few months. After that, you should understand the
base well, be done with licensing issues, and still ahead of scratch
types.

: Given a set of goals and a specific

: bunch of code there are going to be other problems. These can range from
: vast to few, but they'll still be there unless you literally want mud in
: the box which isn't a good thing either.

And scratch mud creation is without problems?

[George Reese]

Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
: George Reese <bo...@imaginary.com> wrote:

: :Katrina McClelan <kit...@directcheck.aries.net> wrote:

You are taking X too literally. In most cases, you can get a good,
uniquye mud up faster and better with good stock code. Your system is
very very different *on every level* from the way the stock bases I
know of model muds. I have no reason why Chris L's or John G's would
be different. I have nothing to suggest to me they are doing
soemthing so completely foreign.

: :: The argument has deterioated to "scratch muds are good so stock muds

: :: suck", and "stock muds don't suck, so scratch muds must". This is really
: :: not the main points of either side.

: :I am not sure what newsgroup you are posting in, but I have not heard
: :anyone suggest scratch muds inherently suck. It seems to be the
: :hubris of stock mud bashers, however, that believes thairs is the one
: :true way.

: No... most of us simply hate clones.

Nothing about stock code bases suggest they are necessarily clones.

: :In fact, people who write a mud from scratch *that uses largely
: :similar feature sets to existing good stock bases* are bad
: :programmers. Their muds may or may not suck.

: Not if it is better implemented, cleaner, easier to work with, more OO,
: etc, etc, etc.

They are still bad programmers. Thay could have made it better
implemented, cleaner, easier to work with (not more OO) assuming there
was somethign decent to work with to begin with.

: :And the only person I have heard doing anything that an existing stock

: :base would not support is Nathan.

: Whoops... made an exception in my case. Well, John G, Chris L, The Cold
: crew, and several others should be included with me. (Chris L should be
: familiar... he's the one using the transactional database with rollback
: and a single commit thread (I think that's right) for his mud.)

No, that is not significantly different. Just a different
implementation of a common design pattern in muds. Yours uses
different design patterns; that is why it does not fit.

I toyed with the idea of a transactional database once... it is kinda
silly in a mud world.

: :: The concept of stock code is not

: :: inherently so flawed to be dismissed. That said, even with the PERFECT
: :: stock base there are still reasons to start over. Additionally, a good
: :: majority of the stock mud code out there has additional
: :: disadvantages.

: :Those reasons are few and far between.

: Debateable. Experience is a pretty good reason, for example.

Experience tells me otherwise.

: :: If

: :: the world were ideal George may have more ground to stand on, however as
: :: things are now there is not much in the line of OO stock code out there
: :: that can miraculously do anything you'd ever want it to with minor
: :: alterations.

: :Lima and Nightmare are pretty damn close. You don't need a perfect
: :world.

: Nightmare (3) did not impress me... 4 and 5 would have to have been MANY
: orders of magnitude better... and Lima, frankly, is more a testiment to
: LPC than to itself. Its OK, I suppose. A hell of a lot better than Diku,
: or LPMud3.x, or the MOOs I've seen, but still...

Nightmare IV was a rewrite from scratch, becuase 3 was not written in
an OO fashion; in fact it was not designed at all, it was thrown
together haphazardly.

Nightmare IV was built using an object design.

: :: If one airplane crashes out of a million than you can't

: :: judge all airplanes by the one that crashed. If a good percentage of them
: :: crashed then you can make a much more valid generalization. Does this
: :: mean that the ideal of airplanes not crashing gets swept over? No, but it
: :: does mean that until they get airplanes to that point I'll stay off them
: :: thank you very much. The flip side, starting from scratch has it's
: :: advantages, and it's disadvantages. Time seems to be the main down
: :: side.

: :Time and bad programming habits.

: Uhhh... justify this. Without the code reuse argument, its stale and
: inaccurate. I've been programming professionally for four years, and
: I've never seen a situation where prolonged code reuse wasn't a falacy.
: ^^^^^^^^^
: A lot of muds have prolonged it, Lima included.

Because you probably have not done it right. True code reuse is
a discipline issue. I have been consistently successful in code reuse
and I have seen others fail. And the failures inevitably come down to
people with the 'not invented here' disease.

: :: This is true, however there are alot of headaches and hassles to be

: :: avoided by using your own code.

: :Only if you choose your stock base poorly.

: Or if there is no codebase that does what you want AND is clean available.

That goes without saying.

[H. McDaniel]

George Reese wrote:
>
> Greg Munt <gr...@uni-corn.demon.co.uk> wrote:

> : On 15 Aug 1997, George Reese wrote:
>
> : > Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
> : > : On 13 Aug 1997, George Reese wrote:
> : >

[...]
> : > Diku mud people would not make good muds in any universe, so why worry
> : > about them?
>
> : This sounds like elitism to me, George! (*chuckle*)

>
> The last sentence, yes. The sentiment, no. I challenge anyone to
> offer up something that can be done in Diku that cannot be done
> better, in a shorter time frame, and easier in LPMud.
>

Actually this is purely a matter of perspective. I've coded on
and imp'd both DIKU and MudOS based MUDs. If you were an admin
who didn't *want* to learn/use LPC then DIKU is prefectly fine.
Yes, yes. I know all the arguments concerning development turnover
time. I think it all depends on the project goals/requirements.

For example (but this is not the limit to possible reasons):
If I were trying to build a stable game and wouldn't need to
modify it often once it is completed.. a DIKU type is fine. OTOH
if I wanted to have a team of several coders it would be easier
to go the LPC (or TinyMUD type) route.

BTW, "LPMud architecture is a lot more sound" -- NO. Absolutely
not. Only LP was written in a different style with different
goals in mind. Saying what you said is like looking at a 100 year
old Inn and comparing it to a high rise Hotel. Both structures
are sound. But both were *intended* to serve different goals.

And depending on your resources/project plans one IS going to
be better suited than the other.

[...]
> : Desiring to make a 'better' mud than those currently available is

> : indirectly a concern with mud evolution.
>

> : In fact, the stock/scratch threads are *entirely* concerned with mud
> : evolution.
>

> I am concerned about people who judge themselves superior to those who
> use stock code bases simply because they have managed to do in 2 years
> what the people using stock code can do in 2 months.

> I give a damn if muds themselves actually advance any.

Stock MUD*s actually make it harder for innovations to occur. They
compete for market share and squeeze everybody else to the margins.
This will account for some of the resenment between scratch builders
and those who use stock games without ever even trying to contribute
something to muddom.

> : The point of the questions was to identify features in a mud that

> : encourage similarity. Knowing about them allows people to avoid them.
> : (Assuming that they *want* to avoid them... Grumble.)
>

> Stock muds have nothing to do with this. People liking feature X is
> what causes that feature to appear all over the place. This is not
> rocket science.

Hmm. I have to disagree with you there, George. When I first
started mudding I was presented with the features of what would
later become a major stock MUD (DIKU.) I had no choice in the
matter. Shortly after that I visited some other MUD types
and found things unlike what the stock MUD conditioned me to
regard as "normal" and "user friendly" (in much the same way,
I suppose that many of us coders find UNIX to be user friendly
while people who never have used it.. could hardly imagine anything
more complicated.)

The people "liking feature X" you mention are none other than the
people who coded a particular game! Unless you know of stock MUD
developers doing market surveys...

I'm not saying their basis was wrong, mind you. Just that you
are off base on this point.

-McDaniel

[Martin Keegan]

Matt Chatterley wrote:

> > Perhaps Martin might be able to give a more general answer to this
> > question... If the majority of stock code is not 'a decent quality code
> > base', why is this?

Erm, perhaps George could ask the guy who said this, since I don't
believe it. (Greg, I think it was - obviously it wasn't Katrina,
it'd have been "all stock code is not a de ..." :) )

> Firstly, I agree with Georges point that in many aspects Lima is very
> good quality - some of the other LP libs available are quite good, but
> others are simply terrible. The ratio is probably about 2:8 good to
> bad(in varying states).

Yes, I recommend Lima when someone (usually from AOL, and probably
the same guy each time from different accounts) asks me what to start
with. So much for my anti-Stock credentials. :)

> In terms of Diku derivs, I dislike Diku/Circle/Rom/Merc(to a lesser
> degree), but Smaug is a definite improvement in some ways, so we have a
> 1:4 ratio of good to bad.

Erm, these ratios are likely to get you into trouble. That's like
saying 50% of the world's languages have feature P (*). How do you
count? Number of speakers? By families? subfamilies? dialects?
Superfamilies? What weighting does one give to each langauge, if
any? Should English carry more weight than the 1000 languages spoken
in PNG?

There are loads of other Diku clones. How do you propose to weight them?

(*) actually, it's more like 64%!

> PennMUSH and TinyMUSH do not have such things as stock 'bases' (Because
> there is no world of any sort supplied - only the basic commands, which
> are extended by the world you build in them), although there is a growing
> trend to globally release code. This has less impact on these games,
> which are used for purist (usually!) roleplay.

They have purist computer roleplay?

> > > : IMHO the stock/scratch debate is to an extent concerned with what people
> > > : do with the code. It is primarily concerned with the tendency towards
> > > : sameness. Bad code bases contribute to this heavily - DIKU and its
> > > : derivatives are mentioned most of all (it is rare for any other mud type
> > > : to be mentioned, in actual fact) in these debates.
> > >
> > > I question the sanity of people who use Diku in the face of LPMud,

> > > because the LPMud architecture is a lot more sound. So, bottom line,

> > > Diku mud people would not make good muds in any universe, so why worry
> > > about them?
> >
> > This sounds like elitism to me, George! (*chuckle*)
>

> Egad. Someone in this group being an elitist? *paranoid gaze around*

That'd be me! :)

> > So, is it just the DIKU bases that have stock areas? Why? What is it
> > about DIKU that encourages this?
>
> Probably. Tiny/Penn/LP bases do not typically have 'stock areas'
> available - certainly not released without the lib, and the NM libs only
> came with a few example rooms from the main town, IIRC.
>

> Why does Diku encourage it? Because it is very easy to 'plug in' a set of
> world files?

I think it's inevitable that there would evolve a lowest common
denominator mud codebase, which made it as easy as possible to set
up a mud.

> > > Who actually gives a damn about mud evolution? The goal is to make a
> > > good game. Evolution is not designed.
> >

> > Desiring to make a 'better' mud than those currently available is
> > indirectly a concern with mud evolution.
>

> It is the same phenomenon that has left us with enough armament to
> happily kill ourselves off if someone should do the wrong thing at the
> wrong time. The 'build a better bomb' phenomenon, combined with the
> wonderful gift of science has left us with atomic weaponry. Oh that

For shame, Matt! Hand back your Tory Party membership gasmask.

> 'build a better mud' could leave us with something as remarkably more
> powerful than our slings and pebbles.

I don't think evolution is a goal in itself. I agree with George.

My only reservation is that (at the risk of sounding like a broken
record - not an uncommon noise in this group):

Stock Muds Impede Innovation

> > In fact, the stock/scratch threads are *entirely* concerned with mud
> > evolution.
>

> And a chance for bloody good whinge!

I've had mine. Now, to work!

> > The point of the questions was to identify features in a mud that
> > encourage similarity. Knowing about them allows people to avoid them.
> > (Assuming that they *want* to avoid them... Grumble.)
>

> Many of the Stock muds are bad in my eyes because they have no theme. If
> you have a theme, it encourages change indirectly.

Bollocks. What about multi-themed muds (which is what you're criticising
above, I think)?

Mk

-- "A Rock feels no pain ... and an Island never cries." - some song
http://cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi

[George Reese]

Martin Keegan <mar...@cam.sri.com> wrote:
: My only reservation is that (at the risk of sounding like a broken

: record - not an uncommon noise in this group):

: Stock Muds Impede Innovation

No, stock muds encourage innovation.

Why? because as a stock mud admin, you are free to worry about the
ways in which you can make your mud different instead of focusing on
coding all the things that any mud needs in order to run.

Scratch mud developers spend way too much time worrying about things
that have already been done; and done better than they could ever do
those things themselves.

[George Reese]

Chris, Matt, Katrina, Greg: John agrees with you!

John Adelsberger <j...@umr.edu> wrote:
: Distribution: world

: George Reese <bo...@imaginary.com> wrote:
: : You are taking X too literally. In most cases, you can get a good,

: : uniquye mud up faster and better with good stock code. Your system is
: : very very different *on every level* from the way the stock bases I
: : know of model muds. I have no reason why Chris L's or John G's would
: : be different. I have nothing to suggest to me they are doing
: : soemthing so completely foreign.

: You must not be reading Chris's postings.

You are right. I have not read every single posting he has made. I
am sure you think this is supposed to mean something, but I have no
idea what that is.

: If you can do what he's doing
: on your lib using MudOS without rewriting it as opposed to just adding
: features to the lib, I promise never to post here again. I don't think
: what he's doing is important enough to the game aspect of a mud to be
: worthwhile to me, but you certainly won't do it on Nightmare - that's
: right, I'm saying it CAN'T be done, not it'd be hard.

Your trying to start arguments where none exist. I am not saying that
it is inconceivable that Chris is doing something that a stock base is
not right for. I just have not personally seen what it is.

: : Nothing about stock code bases suggest they are necessarily clones.

: Go read Smaug and say that again with a straight face.

Are you too dense to understand the difference between stock muds as a
concept and individual implementations? That there are bad stock
bases is completely irrelevant to anything.

: : They are still bad programmers. Thay could have made it better

: : implemented, cleaner, easier to work with (not more OO) assuming there
: : was somethign decent to work with to begin with.

: If doing it yourself instead of using something you don't like means
: being a bad programmer, then most of the worthwhile programs in the
: world were written by bad programmers. Of course, reality is that
: Reese is being overly dramatic and making generalizations the
: implications of which he probably doesn't comprehend.

I clearly understand the implications since I have been doing this
with an extremely high degree of success for some time. Doing
something you don't like does in fact mean being a bad programmer if
you are doing it over in virtue of the fact you simply don't like it.

: : : Whoops... made an exception in my case. Well, John G, Chris L, The Cold

: : : crew, and several others should be included with me. (Chris L should be
: : : familiar... he's the one using the transactional database with rollback
: : : and a single commit thread (I think that's right) for his mud.)

: : No, that is not significantly different. Just a different
: : implementation of a common design pattern in muds. Yours uses
: : different design patterns; that is why it does not fit.

: What is common in muds about logging every event for eternity? Nightmare
: will never do this.

I have no idea what you mean and no idea why you think Nightmare won't
support whatever it is.

: : I toyed with the idea of a transactional database once... it is kinda

: : silly in a mud world.

: Reese has spoken.

Yes, I have. So have many others.

: : : Debateable. Experience is a pretty good reason, for example.

: : Experience tells me otherwise.

: Your experience in muds consists of some work on MudOS and a bad stock
: base that nobody else can use. Who cares?:)

You have no clue what my experience is. I guarantee I have more
experience in muds with more environments than you.

You keep saying that about Nightmare, but to date you have not
offered one honest criticism of the lib. So until you do that, your
entire judgment of the lib is suspect.

Plus, I also have another decent, but outdated stock base that people
can still use, plus Java libraries that people still use. What I do
for a living is write reusable objects.

: : : :: If

: : : :: the world were ideal George may have more ground to stand on, however as
: : : :: things are now there is not much in the line of OO stock code out there
: : : :: that can miraculously do anything you'd ever want it to with minor
: : : :: alterations.

: : : :Lima and Nightmare are pretty damn close. You don't need a perfect
: : : :world.

: Nightmare, the last one that was publicly available, is a joke. Lima is
: better, but still shows design choices made to reflect what the designers
: wanted in a game.

Please, back up that statement. Also, what made Lima better?

: : Nightmare IV was a rewrite from scratch, becuase 3 was not written in

: : an OO fashion; in fact it was not designed at all, it was thrown
: : together haphazardly.
: : Nightmare IV was built using an object design.

: Wow, so was my first semester CS project. Do you have a point?

Yes, I am sorry it is so hard for you to read. My point was Nightmare
IV was OO, Nightmare 3 was not; you therefore cannot judge NM IV based
on NM 3.

: : Because you probably have not done it right. True code reuse is

: : a discipline issue. I have been consistently successful in code reuse
: : and I have seen others fail. And the failures inevitably come down to
: : people with the 'not invented here' disease.

: Refusing to use anything you didn't write yourself can be a disadvantage,
: but saying that you must reuse anything that is even close to what you
: want is a bigger one.

If you believe that, then you are probably a bad programmer.

: : : Or if there is no codebase that does what you want AND is clean available.

: : That goes without saying.

: Then why are you arguing?

What, I am not allowed to agree with any statements he makes while
disagreeing with others?

[Matt Chatterley]

On Sat, 23 Aug 1997, Martin Keegan wrote:

> Matt Chatterley wrote:
>
> > > Erm, perhaps George could ask the guy who said this, since I don't
> > > believe it. (Greg, I think it was - obviously it wasn't Katrina,
> > > it'd have been "all stock code is not a de ..." :) )
> >

> > Was the quote you actually refer to said by me or not? My memory is such
> > that I don't recally. ;)
>
> Dunno .... think the headers are a bit scwewy.

You wascally wabbit. I don't think it was me, will the real poster please
step forwards?

> > > Yes, I recommend Lima when someone (usually from AOL, and probably
> > > the same guy each time from different accounts) asks me what to start
> > > with. So much for my anti-Stock credentials. :)
> >

> > Heh. My first recommendation is usually "You don't want to start a mud..
> > but if.." ;)
>
> Yeah. :)

I typically go on to advocate the way I sucessfully got into running a
mud (discounting the 2-3 flops of varying degrees). That being to work in
various levels of design/coding/administration (particularly those which
you will be involved in if you start a game, eg: all of them) on a game
that you have experienced from the blunt (player) end for some time.

> > > > PennMUSH and TinyMUSH do not have such things as stock 'bases' (Because
> > > > there is no world of any sort supplied - only the basic commands, which
> > > > are extended by the world you build in them), although there is a growing
> > > > trend to globally release code. This has less impact on these games,
> > > > which are used for purist (usually!) roleplay.
> > >
> > > They have purist computer roleplay?
> >

> > Well, they are typically used for social and/or roleplay games. Whether
> > "purist computer roleplay" is simply an urban myth or not, is another
> > matter altogether.
>
> I was speaking to someone last weekend who refused to play muds because
> he believed that computer mediated roleplaying was basically heresy,
> and would of necessity be crap.

Hmm. RP on some games (eg: Riverworld, which is currently down) is not
'computer mediated' in any way - a computer generated forum, and some
simple tools are provided, but the rest is left to players. The end
result is either very good or very bad (hit and miss thing, really), it
worked for Riverworld - but many games find more degrees of limitation on
players necessary.

> > > > Egad. Someone in this group being an elitist? *paranoid gaze around*
> > >
> > > That'd be me! :)
> >

> > Bah! I'm far above elitism!
>
> Of course, when one's as brilliant as I, one doesn't need such things
> as modesty. Modern English: never a language one has spoken oneself.

This is not the end. It is not even the beginning of the end. But it is,
perhaps, the end of the beginning.

> > > I think it's inevitable that there would evolve a lowest common
> > > denominator mud codebase, which made it as easy as possible to set
> > > up a mud.
> >

> > Diku probably fits best into this category, yes.
>
> And will compete eternally for the crown.

It has to compete?

> > > > It is the same phenomenon that has left us with enough armament to
> > > > happily kill ourselves off if someone should do the wrong thing at the
> > > > wrong time. The 'build a better bomb' phenomenon, combined with the
> > > > wonderful gift of science has left us with atomic weaponry. Oh that
> > >
> > > For shame, Matt! Hand back your Tory Party membership gasmask.
> >

> > What about the commemorative Tory boxer shorts?
>
> What? The Union Jack ones? [*] or the frilly black lace numbers worn
> at the Bristol constituency subbranch meetings?

Red/White/Blue is far too gaudy.

> [*] A True Tory would point out that The Flag is only properly the
> Union Jack when flown at sea, and is otherwise the "British Union Flag"

We have our own flags here in Jersey. A pathetically stupid number of
them, infact.

> > > > 'build a better mud' could leave us with something as remarkably more
> > > > powerful than our slings and pebbles.
> > >
> > > I don't think evolution is a goal in itself. I agree with George.
> >

> > Evolution cannot, CANNOT be a goal - but it can be a means to a goal, or
> > perhaps better put as a causitive side effect of those means which lead
> > to a goal. *gibber*
>
> I prefer the causative bit. Evolution as a goal is bollocks. It's
> saying: we're going to do this just to be different, not because it's
> any good or anything.

Whereas being different is something that will likely occur if you
achieve something new and interesting.

> > > My only reservation is that (at the risk of sounding like a broken
> > > record - not an uncommon noise in this group):
> > >
> > > Stock Muds Impede Innovation
> >

> > Their presence as well as their use.
>
> Their omnipresence.

The Stockmuds are watching you!

> > > > you have a theme, it encourages change indirectly.
> > >
> > > Bollocks. What about multi-themed muds (which is what you're criticising
> > > above, I think)?
> >

> > A mud with multiple themes is a themed mud. Although multiple themes can
> > get very messy, they are not an inherently bad thing (a game set over
> > several worlds, eg: the 'Sliders' tv show scenario, could be fine). What
>
> Island was multithemed, though never joked about it, which was
> uncharacteristic. Tragically, the TMBG area never got implemented,
> though there were allusions in other parts of the game. The phrase
> 'There might be giants' actually appears on the last line of the
> 'last' room.

Heh. I suppose the thing I'm aiming at is more design targets and intentions
than just theme - I would assume Island set out to do something along
the lines of what it did. Rather than doing something very vague ("I want
to build a Star Wreck MU***#*(&($*&)(&)(*#$S!"), or something with no
aim/goal/direction/clear intent.

> > IS bad IMHO is the situation whereby you have "Lets build a
mud."
> > followed by "I'll make an area involving X, because it rocks."
>
> Oh, that. Well, that sort of mud is going to be crap anyway, not
> just because it's multithemed.
>
> ObRocks: A big ftp archive in Sweden contained a file called
>
> you're_site_rocks_with_power
>
> It's probably still there.

Heh.

> > You rapidly end up with a baseball stadium, a roman colluseum (featuring
> > real romans), and some dinosaurs roaming freely around.
>
> Hallo TinyMUD.

Be afraid.

[John Adelsberger]

Corey Brenner (bre...@umr.edu) wrote:
: George Reese <bo...@imaginary.com> wrote:

: : Complete bullshit. There are 3-5 person/years in writing a

: : sufficiently developed code base and mud. Understanding a stock code
: : base is about 6 months.

So since you claim to have written Nightmare IV in the last two years,
it must be garbage, right?:) Get real. Many projects come together
in an amazingly short time, and person/years is about as sensible a
concept as man/years. If you think the latter is defensible, go read
a book with that word in the title:)

: : True, but it is still bad programming practice and prone to errors.

Programming is prone to errors. As Dennis Leary once said,

"Life sucks. Get a fucking helmet."

: : If your goal is to sit and write code... sure, it is a barrel of

: : laughs. If your goal is to create a mud, then no.

What if both of those are your goals? Does this contradict your vision
of reality? Does it violate the truths of your religion? What is your
problem anyway, and will laxatives solve it?

: : This is complete crap. Everything I have stated is an underlying

: : premise of object-oriented software engineering.

This is rich. Have you ever taken a course in software engineering?
Can you name _ONE_ software engineering tool? Can you give the
meaning of the acronym CASE, Georgy? I thought not. You are a moron
using words you cannot comprehend in the hope of appearing sophisticated.

For all concerned, George is not a software engineer. He is a mostly
uneducated Java programmer with pretensions to the title of consultant
who wrote a book and thinks that makes him a god. His major in school
was philosophy, but he spends more time promoting a mudlib he won't
let anyone use than thinking. He thinks Win95 is a good platform for
running a network service. What else do you need to know?

--
John J. Adelsberger III
j...@umr.edu

"There are none so blind as those who will not see." - Kansas

[Martin Keegan]

Matt Chatterley wrote:

> > > > I think it's inevitable that there would evolve a lowest common
> > > > denominator mud codebase, which made it as easy as possible to set
> > > > up a mud.
> > >
> > > Diku probably fits best into this category, yes.
> >
> > And will compete eternally for the crown.
>
> It has to compete?

that should have read 'internally' - i.e., intra-Diku

Mk

-- "Just because you CAN doesn't mean you MAY." - some song
No wait - it was ME. "some song" is from a previous .sig
http://cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi

[Thomas Kilburn III]

On Thu, 28 Aug 1997 00:18:08 +0100, Martin Keegan <mar...@cam.sri.com>
wrote:

>> running a network service. What else do you need to know?
>

>What I need to know is why you delight in wasting people's time,
>making outrageous unsupported statements, denigrating people and
>generally being a complete pain in the arse. You seem to have some
>notion that the truth is something you can redefine at will,
>the way you treat the words in the English language.
>
>John, please go away. You're not impressing anyone. You're not becoming
>MegaTroll or gaining much notoriety. You're just wasting our time
>and oxygen.
>
>Mk

I don't know. Ever since the New OS idea flame thread that
cross-posted into rec.games.programmer a while back, I began to wonder
if Mr. Adelsberger and Scott Nudds were the same person? Similar
grammar, both as argumentative. Perhaps he is a Mega-troll, not just
a disciple . . . Nudds could have decided to change to a new identity
to insult once anew. ;)

Too much X-files . . . hazardous to your sanity.

>
>-- "Just because you CAN doesn't mean you MAY." - some song
> No wait - it was ME. "some song" is from a previous .sig
>http://cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi

Thomas Kilburn -- pala...@airmail.net
--------------------------------------
Programming Language Athiest
Will Code fo Food.

[Martin Keegan]

John Adelsberger wrote:

> This is rich. Have you ever taken a course in software engineering?
> Can you name _ONE_ software engineering tool? Can you give the
> meaning of the acronym CASE, Georgy? I thought not. You are a moron
> using words you cannot comprehend in the hope of appearing sophisticated.
>
> For all concerned, George is not a software engineer. He is a mostly
> uneducated Java programmer with pretensions to the title of consultant
> who wrote a book and thinks that makes him a god. His major in school
> was philosophy, but he spends more time promoting a mudlib he won't
> let anyone use than thinking. He thinks Win95 is a good platform for

> running a network service. What else do you need to know?

What I need to know is why you delight in wasting people's time,
making outrageous unsupported statements, denigrating people and
generally being a complete pain in the arse. You seem to have some
notion that the truth is something you can redefine at will,
the way you treat the words in the English language.

John, please go away. You're not impressing anyone. You're not becoming
MegaTroll or gaining much notoriety. You're just wasting our time
and oxygen.

Mk

-- "Just because you CAN doesn't mean you MAY." - some song

[George Reese]

John Adelsberger <j...@ultra3.cc.umr.edu> wrote:
: George Reese (bo...@imaginary.com) wrote:
: : Chris, Matt, Katrina, Greg: John agrees with you!

: Yes, George, sometimes people agree on something. Neat, isn't it?

It should scare the hell out of them that you agree with them.

: : John Adelsberger <j...@umr.edu> wrote:

: : : You must not be reading Chris's postings.

: : You are right. I have not read every single posting he has made. I
: : am sure you think this is supposed to mean something, but I have no
: : idea what that is.

: You criticize his work based on your assumption that he's doing nothing
: that can't be done on stock bases, but readily admit you don't even know
: what he's said about his work, much less anything about the work itself?
: I'll just assume any reader, even you, can find the error there.

Where did I criticize his work?

: : Your trying to start arguments where none exist. I am not saying that

: : it is inconceivable that Chris is doing something that a stock base is
: : not right for. I just have not personally seen what it is.

: If he wants to tell you, I'm happy for him. You probably wouldn't
: understand if he did, and if you did, you'd be telling him he's an
: idiot for not doing it on top of Microsloth Access or something
: equally stupid to promote code reuse, but if he wants to tell you,
: it is his story to tell.

Is there a point in here? It sounds like 100% jibberish to me.

: : Are you too dense to understand the difference between stock muds as a

: : concept and individual implementations? That there are bad stock
: : bases is completely irrelevant to anything.

: So what you're saying is, 'If stock bases were in fact all they're
: cracked up to be, which they never have been and likely never will be...'
: Whee. Who cares?

Who says there are no good stock bases? You?

: : I clearly understand the implications since I have been doing this

: : with an extremely high degree of success for some time. Doing
: : something you don't like does in fact mean being a bad programmer if
: : you are doing it over in virtue of the fact you simply don't like it.

: What if it is something you _do_ like? Not everyone dislikes systems
: programming.

More meaningless nonsense.

: : : Reese has spoken.

: : Yes, I have. So have many others.

: "Yet it moves." -- Galileo

: : Plus, I also have another decent, but outdated stock base that people

: : can still use, plus Java libraries that people still use. What I do
: : for a living is write reusable objects.

: No wonder you're a reuse fanatic. Me personally, I like reuse of code
: that does what you want, but hacks on top of hacks to try to reuse
: something that wasn't designed for what you're doing are bad ideas,
: and when you defend stock mudbases, that is what you're going to be
: forced to defend.

Hacks on top of hacks IS NOT CODE REUSE.

: : : Nightmare, the last one that was publicly available, is a joke. Lima is

: : : better, but still shows design choices made to reflect what the designers
: : : wanted in a game.

: : Please, back up that statement. Also, what made Lima better?

: Lima? Oh, documentation, poor though it is, and their input system,
: ugly hack on top of input_to though it is, and their security, slow ass
: pig though it is... need I go on?

Then you are a buffoon. Nightmare was always better documented, uses
the same damn input system, and uses the same damn security model.

That Nightmare was better documented is not just my opinion; I am sure
the Lima folks would agree on that as well.

And the input system is not a hack on input_to().

: : Yes, I am sorry it is so hard for you to read. My point was Nightmare

: : IV was OO, Nightmare 3 was not; you therefore cannot judge NM IV based
: : on NM 3.

: Fine. According to you, I can't judge any version of it that was ever
: publicly released, because you've improved it so much since; the one
: I last saw was a bit over a year ago(it'll hurt you I know, but I didn't
: spend my life downloading the latest version of Nightmare every day:) and
: that one sucked balls compared to DW, much less Lima.

First, NM IV is not another version of Nightmare. IT IS A DIFFERENT
MUDLIB.

Second, in your comparison of NM and Lima, you just showed you don't
know jack about Nightmare.

: : : Refusing to use anything you didn't write yourself can be a disadvantage,

: : : but saying that you must reuse anything that is even close to what you
: : : want is a bigger one.

: : If you believe that, then you are probably a bad programmer.

: Yeah, it's horrible to design software instead of throwing it together
: out of components that don't fit together right and using hacks as glue.
: I'm sorry, but the reuse religion is just another misguided version of
: a fallacy that's been going around in programming circles since the days
: of Fortrash. Reuse when the components are what you need is intelligent;
: reuse when they are not quite right prevents coherent design, or at least
: adherence to one.

You don't have the first clue of what reuse is.

[John Viega]

John Adelsberger <j...@umr.edu> wrote:
>
> : Please, back up that statement. Also, what made Lima better?

>
> Lima? Oh, documentation, poor though it is, and their input system,
> ugly hack on top of input_to though it is, and their security, slow ass
> pig though it is... need I go on?

Euh? Lima was never well documented, especially compared to
Nightmare. As far as I remember, Nightmare borrowed our ideas on
input and security.
The Lima input system is *not* an ugly hack, or even a hack. It was
well thought out and the implementation is very good, considering the
primitives that MudOS provides. There's a well defined API, that is
pretty easy to use, and the implementation is straigtforward. It has
changed incredibly little in the years since it was first written. If
you want people to take stock in what you say, try supporting it with
evidence.

And security is pretty much only used for file operations. File
operations are already going to be slow. Might as well make a
function call for each object on the stack when the language is
keeping the whole stack around anyway. It's not a huge ammount of
overhead, especially since the call stack is usually very small. The
advantages to checking the call stack are quite great. You can easily
restrict the oportunities for adding security holes to those places
where you explictly forego the stack check. This is a big improvement
over pretty much every other security system I've ever seen, where you
had to explicitly check previous_object() at every level to get the
same kind of garuntees that someone is not forging an arbitrary object
somewhere in the call stack. Either don't have security, and you
won't have the performance hit, or implement security where it's
fairly easy to convince yourself that it works, and pay the price in
cycles. I'm sure the mud world would be quite thankful if you would
propose some other much more efficient system that provides the same
sort of garuntees (most importantly provability... I've seen tons of
claims that "my system is secure" based on the programmer's belief in
his own ability, and no theory. I've seen few if any such claims that
were substantiated. Heck, we don't even claim that we've plugged all
the holes, just that if there is one, it's almost definitely going to
be in an unguarded() call. Well, if you know what you're doing, you
can convince yourself of the safeness of each such call on a case by
case basis).

[Jon Lambert]

In article <5tvrqv$7fr$1...@news.cc.umr.edu>, j...@ultra3.cc.umr.edu says...
>: : This is complete crap. Everything I have stated is an underlying

>: : premise of object-oriented software engineering.
>

>This is rich. Have you ever taken a course in software engineering?
>Can you name _ONE_ software engineering tool? Can you give the
>meaning of the acronym CASE, Georgy? I thought not. You are a moron
>using words you cannot comprehend in the hope of appearing sophisticated.
>
>For all concerned, George is not a software engineer. He is a mostly
>uneducated Java programmer with pretensions to the title of consultant
>who wrote a book and thinks that makes him a god. His major in school
>was philosophy, but he spends more time promoting a mudlib he won't
>let anyone use than thinking. He thinks Win95 is a good platform for
>running a network service. What else do you need to know?
>

For nobody concerned, Mr. Adelsberger appears to be yet another 1st year
CS student whose primary recreation is regurgitating course syllabi,
dropping big words, getting drunk and posting.
You too can have the equivalent of John's wisdom. Six-pack is optional.

<begin post>
Polymorphism sucks! Braap!
<end post>

[John Adelsberger]

Martin Keegan (mar...@cam.sri.com) wrote:
: John Adelsberger wrote:

: What I need to know is why you delight in wasting people's time,

You choose to read.

: making outrageous unsupported statements, denigrating people and

What was unsupported about what I said? He has admitted most of it,
albeit covered in more positive connotation.

: generally being a complete pain in the arse. You seem to have some

A truly personal viewpoint.

: notion that the truth is something you can redefine at will,

: the way you treat the words in the English language.

On the contrary, I am precise in my use of English, and when I slip up in
matters of use, I admit it upon discovery. The truth is that George Reese
uses terms like 'software engineering' to make himself appear more
knowledgable than he is, and the evidence is his own admitted lack of
education on the subject: software engineering is a specific term with
specific _formal_ meaning, which Reese wants to generalize to mean 'good
design practices.'

: John, please go away. You're not impressing anyone. You're not becoming

: MegaTroll or gaining much notoriety. You're just wasting our time
: and oxygen.

If any of these, including any concern one way or the other for your
oxygen, was my concern, I'd never have started. In particular, if
impressing the likes of you ever concerns me, I will acquire a shotgun
directly and use it upon my cranium before its too late.

[George Reese]

John Adelsberger <j...@ultra5.cc.umr.edu> wrote:
: Martin Keegan (mar...@cam.sri.com) wrote:
: : notion that the truth is something you can redefine at will,

: : the way you treat the words in the English language.

: On the contrary, I am precise in my use of English, and when I slip up in
: matters of use, I admit it upon discovery. The truth is that George Reese
: uses terms like 'software engineering' to make himself appear more
: knowledgable than he is, and the evidence is his own admitted lack of
: education on the subject: software engineering is a specific term with
: specific _formal_ meaning, which Reese wants to generalize to mean 'good
: design practices.'

Ok, John, you win. I am a complete incompetent; I don't know what I
am doing. Can we go now?

[Roger Christie]

John Adelsberger wrote:
>
> Martin Keegan (mar...@cam.sri.com) wrote:

> : John Adelsberger wrote:
>
> : What I need to know is why you delight in wasting people's time,
>
> You choose to read.
>
> : making outrageous unsupported statements, denigrating people and
>
> What was unsupported about what I said? He has admitted most of it,
> albeit covered in more positive connotation.
>
> : generally being a complete pain in the arse. You seem to have some
>
> A truly personal viewpoint.
>

> : notion that the truth is something you can redefine at will,
> : the way you treat the words in the English language.
>
> On the contrary, I am precise in my use of English, and when I slip up in
> matters of use, I admit it upon discovery. The truth is that George Reese
> uses terms like 'software engineering' to make himself appear more
> knowledgable than he is, and the evidence is his own admitted lack of
> education on the subject: software engineering is a specific term with
> specific _formal_ meaning, which Reese wants to generalize to mean 'good
> design practices.'

I'd wager George has made more money in this business than you.

>
> : John, please go away. You're not impressing anyone. You're not becoming
> : MegaTroll or gaining much notoriety. You're just wasting our time
> : and oxygen.
>
> If any of these, including any concern one way or the other for your
> oxygen, was my concern, I'd never have started. In particular, if
> impressing the likes of you ever concerns me, I will acquire a shotgun
> directly and use it upon my cranium before its too late.

Now theres a thought.

[Martin Keegan]

John Adelsberger wrote:
>
> Martin Keegan (mar...@cam.sri.com) wrote:
> : John Adelsberger wrote:
>
> : What I need to know is why you delight in wasting people's time,
>
> You choose to read.

Because everyone, even you, occasionally has something interesting to
say.

> : making outrageous unsupported statements, denigrating people and
>
> What was unsupported about what I said? He has admitted most of it,
> albeit covered in more positive connotation.

I was talking more generally. See in particular your bullshitartistry
over NoCeM. Not available for Unix, indeed! Proprietary, indeed!

I don't want to have to search DejaNews for specific examples of your
unsupported bollocks.

> : generally being a complete pain in the arse. You seem to have some
>
> A truly personal viewpoint.

One doubtless shared by many of the other readers of this group whose
intelligences you choose to insult.

> : notion that the truth is something you can redefine at will,
> : the way you treat the words in the English language.
>
> On the contrary, I am precise in my use of English, and when I slip up in
> matters of use, I admit it upon discovery. The truth is that George
Reese

Nonsense. You seem opposed to the very notion of someone being able to
define what a word means. Taken to its logical conclusion, everyone
would be speaking his own language, just for the 'freedom' of
definition.

> uses terms like 'software engineering' to make himself appear more
> knowledgable than he is, and the evidence is his own admitted lack of
> education on the subject: software engineering is a specific term with
> specific _formal_ meaning, which Reese wants to generalize to mean 'good
> design practices.'

That you have chosen to take on one of the most respected and
intelligent contributors to the mud community who is also known to
defend himself vociferously against idiotic flamage is further
proof of your stupidity.

> : John, please go away. You're not impressing anyone. You're not becoming
> : MegaTroll or gaining much notoriety. You're just wasting our time
> : and oxygen.
>
> If any of these, including any concern one way or the other for your
> oxygen, was my concern, I'd never have started. In particular, if
> impressing the likes of you ever concerns me, I will acquire a shotgun
> directly and use it upon my cranium before its too late.

It's [sic] probably too late.

Mk

-- "Just because you CAN doesn't mean you MAY.

The Internet isn't above the Law"
http://cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi

[John Adelsberger]

Jon Lambert (jlsy...@nospam.ix.netcom.com) wrote:

: For nobody concerned, Mr. Adelsberger appears to be yet another 1st year

: CS student whose primary recreation is regurgitating course syllabi,
: dropping big words, getting drunk and posting.

Yeah, that's it. Oh, wait, it isn't. I've been regurgitating and dropping
for 4 years now, and I post sober...

: <begin post>

: Polymorphism sucks! Braap!
: <end post>

Operator overloading is one thing, and polymorphism as a concept is a
different thing. One is a special case of the other. If the difference
between, and potential for differing evaluation of these things is beyond
you, it is no wonder you resort to belittling my social status.

[Curiosity]

In the referenced article, (John Adelsberger) writes:

>Everyone should keep in mind that George is paid to sell the reuse
>religion. Reuse is a good thing, but religious adherence to any
>principle without reference to reality is not. Simplistic arguments
>such as the above ignore issues such as clean design of features the
>author of a given stock base never anticipated, the utter dearth of
>truly flexible and stable/debugged/decently documented codebases in
>the real world, and a horde of other factors.

*doh* I presume that George is _actually_ paid to write code, bearing
(sp?) in mind that he's a programmer and designer. SOftware reuse is
not a religion it's a way of life ;)

>Preach it, brutha Reese!

I am _so_ sick of this religion crap. Every time anyone talks about
anything for more than a week they are accused of being an 'advocate
of that religion' Scott Nudds was famous for this on the C newsgroups.

Why can't people just accept that, just because someone has an opinion
doesn't mean they subscribew to some phoney religion.

This a newsgroup about muds for Christ's sake. If you want to advocate
something take it to the advocacy groups.

Cheers, Curiosity
(who's wondering how much on-topic stuff he'll find today)
--
Curiosity (ccs...@bath.ac.uk) of Bath Information & Data Services (BIDS)
Telephone: +44 1225 826038 * Web: http://www.bath.ac.uk/~ccsjwg/home.html
"The internet is a fad." Bill Gates 1993 * Purity 100=28% 500=43% Afp=51%

[John Adelsberger]

George Reese (bo...@imaginary.com) wrote:
: John Adelsberger <j...@ultra3.cc.umr.edu> wrote:

: Where did I criticize his work?

As usual, you ask after the related matter has been deleted. Anyone reading
the thread backward can find it for himself.

: : So what you're saying is, 'If stock bases were in fact all they're

: : cracked up to be, which they never have been and likely never will be...'
: : Whee. Who cares?

: Who says there are no good stock bases? You?

No, but the ones that exist are mostly highly specialized to the point of
near uselessness for anything but exactly what they are meant for. NM
and Lima don't count b/c the one is unavailable and the other has yet
to be released as production code(or even a beta.) DW is nice, but its
strengths don't make up for all the bad coding practices in use in it.
TMI, last I heard, performs like molasses. Diku anything sucks balls.
Tiny, Cold, Cool, and the other similar systems assume you want an
implicitly persistant world, which isn't true of most muds. Aber is
ancient and the design shows it, even though its workable enough. Have
I missed anyone of any real note who has a stock base in production?

: : : I clearly understand the implications since I have been doing this

: : : with an extremely high degree of success for some time. Doing
: : : something you don't like does in fact mean being a bad programmer if
: : : you are doing it over in virtue of the fact you simply don't like it.

: : What if it is something you _do_ like? Not everyone dislikes systems
: : programming.

: More meaningless nonsense.

Not at all. If a person _does_ like doing something, say, writing a
codebase from scratch, what then? You talk like writing a codebase
is pulling teeth, but many people enjoy it.

: Hacks on top of hacks IS NOT CODE REUSE.

What you mean is that it is bad reuse. It is code, and it is being reused.
Learn to think, even when dealing with the subject of your religion.

: : Yeah, it's horrible to design software instead of throwing it together

: : out of components that don't fit together right and using hacks as glue.
: : I'm sorry, but the reuse religion is just another misguided version of
: : a fallacy that's been going around in programming circles since the days
: : of Fortrash. Reuse when the components are what you need is intelligent;
: : reuse when they are not quite right prevents coherent design, or at least
: : adherence to one.

: You don't have the first clue of what reuse is.

As usual, your claim uses no evidence, no argument, and no anything else.
You just make a claim, and expect that someone besides yourself will give
a shit. And you do it in reply to something that at least gives its
reasons. You've been doing this for weeks now. You have until 9-14-97
to actually say something well argued, logical in nature, and/or
supported by evidence, and then I'll just give up on you as a hopeless
moron who wrote a book and whose ego is in need very seriously of
deflation, and killfile you for good, as I should have weeks ago. You're
not exactly showing any signs of intellect by these blanket statements
utterly lacking in support.

[George Reese]

John Adelsberger <j...@ultra3.cc.umr.edu> wrote:
: John Viega (jt...@adder.cs.virginia.edu) wrote:

: : Euh? Lima was never well documented, especially compared to

: : Nightmare. As far as I remember, Nightmare borrowed our ideas on
: : input and security.

: I could only speak to the version I saw, which admittedly was ancient.
: If he's adopted Lima's ways since then, I'm happy for his Lima-cloning
: self.

Actually, you almost certainly have not seen a different security
system. NM has not had a non-stack security system since 1993; well
before Lima was around. The parser system was a great idea that
originated on Lima; and I implemented it in Nightmare as soon as MudOS
supported it.

That makes Nightmare a bad mudlib how? Remember, this is your
original point here.

: : The Lima input system is *not* an ugly hack, or even a hack. It was

: : well thought out and the implementation is very good, considering the
: : primitives that MudOS provides. There's a well defined API, that is
: : pretty easy to use, and the implementation is straigtforward. It has
: : changed incredibly little in the years since it was first written. If
: : you want people to take stock in what you say, try supporting it with
: : evidence.

: Ok, hows this:

: 1) I didn't say anything that contradicted any of your points.
: 2) I didn't make that too clear, so hows what follows?

: The Lima input system is a fairly decent approach to hiding MudOS's
: butt ugly input mechanism(input_to.) It _is_ in fact a hack, because
: a proper fix would be to make the driver's input stuff tolerable. This
: does not mean that its interface(the Lima input setup) is bad or that
: it itself is in any way bad functionally.

You have spent a paragraph saying nothing. You say it is 'hiding
MudOS's butt ugly input mechanism(input_to.)' and does not 'make the
driver's input stuff tolerable'.

Why is this a butt ugly system? I think if you knew jack about the
MudOS system, you will find it works quite well for anything you might
want to do.

And furthermore, assuming you were right (huge assumption), if the
Lima and Nightmare interfaces are functionally solid and well
designed, who cares what is under the covers?

And, getting to the point (cause you like this slight of hand game),
only goes to contradict what you were saying about Nightmare.

: : And security is pretty much only used for file operations. File

: : operations are already going to be slow. Might as well make a
: : function call for each object on the stack when the language is
: : keeping the whole stack around anyway. It's not a huge ammount of

: For commonly accessed files, it will be a significant hit b/c those
: files will be sitting in memory anyway unless you're a winloser with
: a bad configuration.

What files on a mud are commonly accessed?

There is no single file in a mud realm other than the logs which are
commonly accessed.

: Moreover, there's no need for it if you just make
: sure the _true_ command giver has the priv to do what is being
: asked;

So what if I want certain objects to enhance the 'true' command
giver's permissions?

: if you execute some newbie cre's code w/o reading it, you're a moron,
: file access problems or no. And if you can't trust your old-timers,
: what the hell are you doing keeping them around?

Why should you have to worry?

: : where you explictly forego the stack check. This is a big improvement
: : over pretty much every other security system I've ever seen, where you

: : had to explicitly check previous_object() at every level to get the

: As I said, I don't bother. Read before you execute; unless code has
: been QC'ed by someone of admin or better rank, you shouldn't trust it,
: even if you _do_ have Lima style security, b/c it can still do stuff
: that will wreak havoc on an open to players mud.

That has never really been the issue on muds. Go to a mud like EoTL
where the game is to write new code on the fly and trick people with
admin positions into executing it.

: : same kind of garuntees that someone is not forging an arbitrary object

: : somewhere in the call stack. Either don't have security, and you
: : won't have the performance hit, or implement security where it's
: : fairly easy to convince yourself that it works, and pay the price in

: My model has security, but it is based on who starts an execution
: sequence. It doesn't do as much, but its a lot faster, and what it
: doesn't do is provide you with a false sense of security about code
: you haven't read and shouldn't be executing anyway.

You are under the mistaken assumption that stack security's sense of
security is false.

: : cycles. I'm sure the mud world would be quite thankful if you would

: : propose some other much more efficient system that provides the same
: : sort of garuntees (most importantly provability... I've seen tons of
: : claims that "my system is secure" based on the programmer's belief in
: : his own ability, and no theory. I've seen few if any such claims that

: My model is as provable as the Lima one, within its constraints.

Stack security has a mathematic proof done by Ellery. Check out the
document on Lima Bean, and then followup with your own proof.

: : were substantiated. Heck, we don't even claim that we've plugged all

: : the holes, just that if there is one, it's almost definitely going to
: : be in an unguarded() call. Well, if you know what you're doing, you
: : can convince yourself of the safeness of each such call on a case by
: : case basis).

: I know how the Lima model works, and I agree: it does what it claims to
: do, barring undiscovered bugs. Nevertheless, I claim that part of what
: it does is worse than a needless slowdown; it _will_ create a false sense
: of security, in which it is true that Mr. Hack can't hack privileges,
: but he can surely piss off all your players, make them all level 0 again,
: etc, etc, etc, b/c you didn't read his code before executing it. If you
: _do_ read his code, you don't _need_ all the overhead.

If it does what it is designed to do, then it is not providing a false
anything. And setting levels has nothing to do with it.

[John Adelsberger]

John Viega (jt...@adder.cs.virginia.edu) wrote:

: Euh? Lima was never well documented, especially compared to
: Nightmare. As far as I remember, Nightmare borrowed our ideas on
: input and security.

I could only speak to the version I saw, which admittedly was ancient.
If he's adopted Lima's ways since then, I'm happy for his Lima-cloning
self.

: The Lima input system is *not* an ugly hack, or even a hack. It was

: well thought out and the implementation is very good, considering the
: primitives that MudOS provides. There's a well defined API, that is
: pretty easy to use, and the implementation is straigtforward. It has
: changed incredibly little in the years since it was first written. If
: you want people to take stock in what you say, try supporting it with
: evidence.

Ok, hows this:

1) I didn't say anything that contradicted any of your points.
2) I didn't make that too clear, so hows what follows?

The Lima input system is a fairly decent approach to hiding MudOS's
butt ugly input mechanism(input_to.) It _is_ in fact a hack, because
a proper fix would be to make the driver's input stuff tolerable. This
does not mean that its interface(the Lima input setup) is bad or that
it itself is in any way bad functionally.

: And security is pretty much only used for file operations. File

: operations are already going to be slow. Might as well make a
: function call for each object on the stack when the language is
: keeping the whole stack around anyway. It's not a huge ammount of

For commonly accessed files, it will be a significant hit b/c those
files will be sitting in memory anyway unless you're a winloser with

a bad configuration. Moreover, there's no need for it if you just make

sure the _true_ command giver has the priv to do what is being asked;

if you execute some newbie cre's code w/o reading it, you're a moron,
file access problems or no. And if you can't trust your old-timers,
what the hell are you doing keeping them around?

: where you explictly forego the stack check. This is a big improvement

: over pretty much every other security system I've ever seen, where you
: had to explicitly check previous_object() at every level to get the

As I said, I don't bother. Read before you execute; unless code has
been QC'ed by someone of admin or better rank, you shouldn't trust it,
even if you _do_ have Lima style security, b/c it can still do stuff
that will wreak havoc on an open to players mud.

: same kind of garuntees that someone is not forging an arbitrary object

: somewhere in the call stack. Either don't have security, and you
: won't have the performance hit, or implement security where it's
: fairly easy to convince yourself that it works, and pay the price in

My model has security, but it is based on who starts an execution
sequence. It doesn't do as much, but its a lot faster, and what it
doesn't do is provide you with a false sense of security about code
you haven't read and shouldn't be executing anyway.

: cycles. I'm sure the mud world would be quite thankful if you would

: propose some other much more efficient system that provides the same
: sort of garuntees (most importantly provability... I've seen tons of
: claims that "my system is secure" based on the programmer's belief in
: his own ability, and no theory. I've seen few if any such claims that

My model is as provable as the Lima one, within its constraints.

: were substantiated. Heck, we don't even claim that we've plugged all

: the holes, just that if there is one, it's almost definitely going to
: be in an unguarded() call. Well, if you know what you're doing, you
: can convince yourself of the safeness of each such call on a case by
: case basis).

I know how the Lima model works, and I agree: it does what it claims to
do, barring undiscovered bugs. Nevertheless, I claim that part of what
it does is worse than a needless slowdown; it _will_ create a false sense
of security, in which it is true that Mr. Hack can't hack privileges,
but he can surely piss off all your players, make them all level 0 again,
etc, etc, etc, b/c you didn't read his code before executing it. If you
_do_ read his code, you don't _need_ all the overhead.

--

John J. Adelsberger III
j...@umr.edu

"If any man cometh to me, and hate not his father, and mother, and wife, and
children, and brethren, and sisters, yea, and his own life also, he cannot
be my disciple." -- Jesus Christ (Luke 14:26)

[Serhat Sakarya]

: : if you execute some newbie cre's code w/o reading it, you're a moron,

: : file access problems or no. And if you can't trust your old-timers,
: : what the hell are you doing keeping them around?

Just out of curiosity: what if a person makes an object that catches
all verbs, e.g. add_action("hack_func","",1); and puts it into an admin's
inventory (or environment for that matter) This object will then get admin
access without the admin itself knowing about it...

This may of course not apply to your case, but if there is any way people
can let their own code be executed with admin rights, you'd be facing
rather large loopholes.

Regards,

Serhat Sakarya

[John Viega]

In article <5v45k0$i1j$1...@news.cc.umr.edu> j...@ultra3.cc.umr.edu (John Adelsberger) writes:

I was actually going to refrain from responding, since George Reese
did a good job of responding to the original post. However, I have a
little bit to add, just to make sure everything was perfectly lucid.

> : where you explictly forego the stack check. This is a big improvement
> : over pretty much every other security system I've ever seen, where you
> : had to explicitly check previous_object() at every level to get the
>
> As I said, I don't bother. Read before you execute; unless code has
> been QC'ed by someone of admin or better rank, you shouldn't trust it,
> even if you _do_ have Lima style security, b/c it can still do stuff
> that will wreak havoc on an open to players mud.

No, it can not do anything special just because an admin is running
it, sorry. The security system Lima uses frees you from the burden of
having to worry about running code in a wizards directory, etc...

> My model has security, but it is based on who starts an execution
> sequence. It doesn't do as much, but its a lot faster, and what it
> doesn't do is provide you with a false sense of security about code
> you haven't read and shouldn't be executing anyway.

You seem to be implying that Lima is not secure if you execute random
code you've never read before, especially a command in a wizards
directory or whatever. If you believe that Lima security suffers from
the problem, then you know nothing about the security system.

> I know how the Lima model works, and I agree: it does what it claims to
> do, barring undiscovered bugs. Nevertheless, I claim that part of what
> it does is worse than a needless slowdown; it _will_ create a false sense
> of security, in which it is true that Mr. Hack can't hack privileges,
> but he can surely piss off all your players, make them all level 0 again,
> etc, etc, etc, b/c you didn't read his code before executing it. If you
> _do_ read his code, you don't _need_ all the overhead.

Ah, you show your ignorance of the system despite your claim that you
know how the model works. If a call is protected by the security
system, then Mr. Hack can't do anything about it, even if he gets the
admin to run code in his directory.

Besides, under your security model, which seems to be "make sure you
read the code before executing it", consider the following failure
states:

1) You read the code, it looks fine, so you start using it. 5 minutes
or 5 days later, the wizard replaces the code you used to use w/ code
to hack your mud.

2) You read his code, and it looks good so you run it. Unfortunately,
the loaded version of the code isn't the same as the source you read.

[John Viega]

In article <5vb53o$2kh$2...@elektron.et.tudelft.nl> ser...@freud.et.tudelft.nl (Serhat Sakarya) writes:
>
> : : if you execute some newbie cre's code w/o reading it, you're a moron,

> : : file access problems or no. And if you can't trust your old-timers,
> : : what the hell are you doing keeping them around?
>

> Just out of curiosity: what if a person makes an object that catches
> all verbs, e.g. add_action("hack_func","",1); and puts it into an admin's
> inventory (or environment for that matter) This object will then get admin
> access without the admin itself knowing about it...
>
> This may of course not apply to your case, but if there is any way people
> can let their own code be executed with admin rights, you'd be facing
> rather large loopholes.

This doesn't apply in the model we're talking about (it wouldn't
apply, even if Lima allowed add_action). Basically, the permissons of
the object containing the add_action *will* be checked before
something "insecure" can happen, which will fail if it belongs to Joe
Wiz.

[John Viega]

In article <5v4nnm$7b8$1...@darla.visi.com> George Reese <bo...@imaginary.com> writes:

> John Adelsberger <j...@ultra3.cc.umr.edu> wrote:
> : John Viega (jt...@adder.cs.virginia.edu) wrote:

> Actually, you almost certainly have not seen a different security
> system. NM has not had a non-stack security system since 1993; well
> before Lima was around. The parser system was a great idea that
> originated on Lima; and I implemented it in Nightmare as soon as MudOS
> supported it.

Lima was around, it was just called GUELib at the time ;-) Basically,
MudOS supporting stack security fell out of us proting from Amylaar to
MudOS... All the credit belongs to Ellery, though. He did the
theory, and he wrote the system we (still) use.

> That makes Nightmare a bad mudlib how? Remember, this is your
> original point here.

It isn't. John Adelsberger just has a big grudge.

> You have spent a paragraph saying nothing. You say it is 'hiding
> MudOS's butt ugly input mechanism(input_to.)' and does not 'make the
> driver's input stuff tolerable'.
>
> Why is this a butt ugly system? I think if you knew jack about the
> MudOS system, you will find it works quite well for anything you might
> want to do.

Except character based input, which is admittedly broken, and has been
since the age of the dinosaurs.

>
> And furthermore, assuming you were right (huge assumption), if the
> Lima and Nightmare interfaces are functionally solid and well
> designed, who cares what is under the covers?

Yeah, I don't believe the systems would be any different if MudOS had
a different interface. I don't see what John Adelsberger is talking
about. Once again, I would encourage him to back his assertations up
with some specifics. However, I'm getting used to such requests being
completely ignored.

> : My model is as provable as the Lima one, within its constraints.
>
> Stack security has a mathematic proof done by Ellery. Check out the
> document on Lima Bean, and then followup with your own proof.

Want to bet he does not do so? =)

[John Adelsberger]

Roger Christie (rchr...@spinach.xylogics.com) wrote:
: John Adelsberger wrote:

: > On the contrary, I am precise in my use of English, and when I slip up in

: > matters of use, I admit it upon discovery. The truth is that George Reese

: > uses terms like 'software engineering' to make himself appear more

: > knowledgable than he is, and the evidence is his own admitted lack of
: > education on the subject: software engineering is a specific term with
: > specific _formal_ meaning, which Reese wants to generalize to mean 'good
: > design practices.'

: I'd wager George has made more money in this business than you.

So has Bill Gates, but the last project I know of him working on actively
as opposed to managing was his BASIC interpreter, and judging from his
grad date from college, he probably knows zip about software engineering.
As I said, the term does not mean 'good design practices,' but rather
refers to a set of formal methods and analytical techniques.

[George Reese]

John Adelsberger <j...@ultra5.cc.umr.edu> wrote:

And you have shown that I am ignorant of these things how?

And you have shown yourself a master of these things how?

By the way, good design practices boil down to using a formal,
well-established methodology.

[John Adelsberger]

John Viega (jt...@adder.cs.virginia.edu) wrote:
: In article <5v45k0$i1j$1...@news.cc.umr.edu> j...@ultra3.cc.umr.edu (John Adelsberger) writes:

: > As I said, I don't bother. Read before you execute; unless code has

: > been QC'ed by someone of admin or better rank, you shouldn't trust it,
: > even if you _do_ have Lima style security, b/c it can still do stuff
: > that will wreak havoc on an open to players mud.

: No, it can not do anything special just because an admin is running
: it, sorry. The security system Lima uses frees you from the burden of
: having to worry about running code in a wizards directory, etc...

I don't know the exact code on Lima, but something like this would really
torque off your playerbase:

users()->set_level(0);
users()->save();

Now, an ordinary punkass wiz can run that as easily as an admin, but if
the admin does it and doesn't realize it right away, and the wiz is
clever and quick, he can hide his tracks completely and maybe even let
his friends blame it on the admin.

: Ah, you show your ignorance of the system despite your claim that you

: know how the model works. If a call is protected by the security
: system, then Mr. Hack can't do anything about it, even if he gets the
: admin to run code in his directory.

Surely every alteration of a player stat isn't protected? I shudder to
think of the slowness...

: 1) You read the code, it looks fine, so you start using it. 5 minutes

: or 5 days later, the wizard replaces the code you used to use w/ code
: to hack your mud.

If I use it, I make a copy somewhere or QC it into an 'official' dir.

: 2) You read his code, and it looks good so you run it. Unfortunately,

: the loaded version of the code isn't the same as the source you read.

Actually, this won't be possible on my setup when I'm finished with it
unless the perpetrator has shell access, because the mud will track
what has been updated since its been loaded, and there'll be a cmd
for checking it. Anyone who doesn't do so after taking the trouble
to read the code is stupider than if he'd never even bothered.

Both good points, but neither applies to me:)

--
John J. Adelsberger III
j...@umr.edu

"If any man cometh to me, and hate not his father, and mother, and wife, and

[John Viega]

[Courtesy CC mailed to quoted author]

In article <606ofg$gqj$2...@news.cc.umr.edu> j...@ultra6.cc.umr.edu (John Adelsberger) writes:

> I don't know the exact code on Lima, but something like this would really
> torque off your playerbase:
>
> users()->set_level(0);
> users()->save();

Perhaps if Lima came with levels by default P-)
Don't confuse security with being annoying. Here is a design descision
document from Lima called "Wizzes Can Dest Admins":

"""
Wizzes are quite capable of desting admins. And we allow it. In
fact, there are MANY things that are allowed by the mudlib that
might otherwise be viewed as bothersome, annoying, or just plain
downright problematic.

Our general view is this: if a wiz is intent on being a pest, then
there is no amount of coding and protection that you can put into
a mudlib to prevent that situation. Nothing.

Given that, we simply opted not to bulk up the lib with a zillion
checks and protections and safeguards when their only end result is
to stump some dumb wizards, but slow down the whole lib to the
detriment of who you're really there for: the players.

So what's the answer to these bothersome wizards? Heh. Grow up
and ban them. Quite simple. First time they're a pest, just tell
them "Don't do that." Second time, ban them. Our view is that
people can be adults and work together.
"""

>
> Now, an ordinary punkass wiz can run that as easily as an admin, but if
> the admin does it and doesn't realize it right away, and the wiz is
> clever and quick, he can hide his tracks completely and maybe even let
> his friends blame it on the admin.

If you have problems like this, keep logs for a while, and find out
who your troublemakers are.

> : 1) You read the code, it looks fine, so you start using it. 5 minutes
> : or 5 days later, the wizard replaces the code you used to use w/ code
> : to hack your mud.
>
> If I use it, I make a copy somewhere or QC it into an 'official' dir.

For me, an unacceptable solution. Getting a change made to your area
once it is in an official directory would be more trouble than it is
worth prettymuch anywhere.

>
> : 2) You read his code, and it looks good so you run it. Unfortunately,
> : the loaded version of the code isn't the same as the source you read.
>
> Actually, this won't be possible on my setup when I'm finished with it
> unless the perpetrator has shell access, because the mud will track
> what has been updated since its been loaded, and there'll be a cmd
> for checking it. Anyone who doesn't do so after taking the trouble
> to read the code is stupider than if he'd never even bothered.

I'd prefer not to require the admin to remember the 290 little things
(s)he would have to juggle in his head just to avoid being stupid by your
definitions. =) Even if by some miracle the admin always looked at
the file, and checked to see if the file has been updated wrt to the
disk copy every time, depending on the circumstances, the wizard could
still have a 2 second window, use a macro and change stuff. Plus you
not only have to check the file you're looking at, but everything in a
wizard dir anywhere that it uses, including those include files with
dumb macros that you've checked 1000 times. After a while, anyone
would get sick of doing that, and build trust for people they
shouldn't always be trusting.

[Chris Lawrence (Contra)]

John Adelsberger (j...@ultra6.cc.umr.edu) wrote:
: John Viega (jt...@adder.cs.virginia.edu) wrote:

: I don't know the exact code on Lima, but something like this would really
: torque off your playerbase:

: users()->set_level(0);
: users()->save();

: Now, an ordinary punkass wiz can run that as easily as an admin, but if

: the admin does it and doesn't realize it right away, and the wiz is
: clever and quick, he can hide his tracks completely and maybe even let
: his friends blame it on the admin.

Fairly trivial for me:

Search the transaction record for all transactions that called that code.

Generate a list of all player objects that were so affected.

Roll those objects back to prior to that transaction along with all other affected objects (to maintain logical consistency).

Voila! problem undone. Minimal side-effects. Of course this isn't on LIMA...

: Surely every alteration of a player stat isn't protected? I shudder to
: think of the slowness...

Protections can take multiple forms, from very basic authorisation of access
type to checking individual accesses. Me? I short circuit. First access to
an object determines what rights of access that transaction has to that
object. All subsequent accesses either fail or succeed on that matrix as
a very simple binary check. This saves rechecking the permissions each time.

--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...

[John Adelsberger]

Chris Lawrence (Contra) (claw...@cup.hp.com) wrote:

:Fairly trivial for me:

[snip prodecure]

:Voila! problem undone. Minimal side-effects. Of course this isn't on LIMA...

More generally, this isn't on MudOS. That said, yes, your setup is nice.

:John Adelsberger (j...@ultra6.cc.umr.edu) wrote:
:: Surely every alteration of a player stat isn't protected? I shudder to
:: think of the slowness...

:Protections can take multiple forms, from very basic authorisation of access
:type to checking individual accesses. Me? I short circuit. First access to
:an object determines what rights of access that transaction has to that
:object. All subsequent accesses either fail or succeed on that matrix as
:a very simple binary check. This saves rechecking the permissions each time.

Right, but unfortunately, in any MudOS system, it isn't just one object that
determines the privilege level of the current execution frame(on the stack.)
Otherwise, if you can forge a call to said object, you hose the security.
You'd have to be able to do matching against the call stack, and there's
no way that's faster to do that than just implementing a heavier security
mechanism in the first place, short of driver mods.(Not to mention the fact
that you'd only occasionally get exact stack matches, really.)