[MUD-Dev] RP=MUSH/PG=MUD

[Caliban Tiresias Darklock]

clawrenc at cup.hp.com wrote:
> 
> I'd like to see a balance here between from-raw
> development with only passing reference paid to the current
> implementations to full-blown take-what-we've-got and
> piece-it-together-and-make-something-better attempts.

This is exactly what I'd like to see as well, since there *is* a certain
benefit to reusing existing concepts and/or code, but there is also a
certain benefit to implementing entirely new ideas and methods. If you 
peg yourself to just one or the other, you end up doing a lot of things
in a pessimal fashion, if only because you don't have the proper
background
to do one thing or another. I don't have the astronomical background 
necessary to do a feasibly realistic sunrise/sunset code, but I do have
a
desire for something like that, so I've located a piece of code that
handles
the appropriate calculations for earth's orbit and is well-commented
enough
that I could easily replace a few constants and redefine the world's
size,
day length, and year length. I also have a similar function for moon
phases,
which I'm converting to handle multiple moons. On the other hand,
someone
with a strong physics and astronomy background could potentially
implement 
something faster and better from scratch without involving the level of
precision in the function I have; much of that precision is unnecessary,
but
I don't have the appropriate knowledge to isolate what is and isn't
necessary
for the function as I envision it.
 
> I'm hoping (vainly?) for some sort of gestaltic combination to occur
> here where each side feeds off the ideas and developments of the
> others.

Once again, this is what I always figured lists are supposed to be for.
If all
you do is preach your own viewpoint, and you don't consider the opinions
and
ideas of others, why even discuss it?
 
> As one of the members here commented to me privately, this list is in
> danger of assuming an orthodoxy.  For instance most of us dislike
> levels in MUDs, to the point that it has become almost assumed as 'the
> list's view'.  Suffice to say that many players *really* like levels
> for whatever reason.  As happens I also know that more than one member
> here is also a big levels fan.  

I think that something many of us forget is that all views and
structures 
are appropriate for certain things. The level-based system carries with
it
the associated idea that if a person is class X and level Y, that's all
you
need to save -- class and level will determine his abilities just fine.
If
you have (for example) 16 classes and 16 races and 100 levels, you can
pack
a complete description of a player's base abilities and skills into a
16-bit
integer field that you can then index into some tables, which in turn
only
have to be instantiated once. From a server construction and memory
conservation
viewpoint, this is great. However, from a game system point of view, you
can
provide more flexibility by storing a binary array of skills ranging
from 0 to
100; this allows any character to have any combination of skills and
abilities,
and removes the need for classes at all. If you were choosing from these
two
concepts (and there are really an infinite number of them, but I can't
use all
of them as examples), you would probably ask whether you preferred
simplicity or
complexity in the character abilities. You might also ask yourself
whether you 
really like or dislike either idea, or what your specific game system
would best
operate with. In either case, both decisions could be made; neither one
is really
*better*, but if you have existing assumptions, desires, or
requirements, you 
may see either or both as a bad solution. 

In other words, when you design a game, design a *game*, not a way to
use the
latest and greatest server-design paradigms. Sometimes the latest and
greatest
just isn't what you actually need.

> I don't want these sorts of assumed
> orthodoxies.  They're not good and they're not productive.  They need
> to be questioned, and beat upon, and hashed over, and done, and
> redone, and re-interpreted till the cows come home.

Amen, brother... and I'll go out and kill the cows so they don't come
home. ;)