[MUD-Dev] MMORPG/MMOG Server design

[Caliban Tiresias Darklock]

From: "J C Lawrence" <claw at kanga.nu>
> On Sun, 23 Feb 2003 03:49:41 +0000
> ceo  <ceo at grexengine.com> wrote:
>> J C Lawrence wrote:
>>> On Sat, 22 Feb 2003 08:56:59 -0500 Derek Licciardi
>>> <kressilac at insightbb.com> wrote:

>> I've seen at least a couple of academics, and even practising
>> software engineers, give the advice:

>>   "Never leave a piece of code alone until its as generic as you
>>   can> possibly make it."

> I've been given the same advice, and to an extent recommend and
> follow it.  To an extent.

Total agreement over here... I've been doing a lot of work with
audio synthesis lately, and while I *can* deconstruct everything
down to the three dimensions of amplitude, phase, and frequency --
it is not always a good idea. I may need to bound my phase to
between 0 and 1, my amplitude to between -1 and 1, and my frequency
to a nonzero positive value < Nyquist, but if I verify or enforce
these conditions at *every* stage of generating *every* sample the
performance of the algorithms rapidly degrades to an unusable
level. So while it disturbs me to leave the dependency checking out
of the processing, it is simply more practical to expect the
developer to apply these checks at an earlier choke point... even
though a developer oversight may then allow the engine to suffer
catastrophic failure at runtime.

The single biggest obstacle I face when writing code is my own
prejudices. I commonly view the next guy -- whether it's the end
user or another developer -- as a sadistic bastard who will not only
completely misinterpret the purpose of the system, but actively
attempt to break it in some misguided attempt to prove his
superiority. In cases where the operations are not time-critical,
this approach tends to result in well-documented, robust code that
simply doesn't break. In time-critical operations, however, it just
bumps up the hardware requirements. A lot. In cases where your goal
is to provide as many parallel operations as possible, you also
reduce the capabilities of the software.

Effectively, these represent two extremes of the developer mindset,
and if either extreme is unbalanced in your team then Bad Things
start to happen.

> Much of our personal understanding of each of those steps is
> strobed.

On this point, I just wanted to say that "strobed" is the single
most elegant way I've ever heard this phenomenon described.

The way I generally put it is that the human brain is very good at
deleting things that don't matter, and constantly attempts to
improve its recognition of what matters -- essentially, everything
is to some degree important, and there is a threshold above which
experiential data are considered necessary.  Whenever the brain
encounters a situation where it has too much irrelevant data, it
responds by raising the threshold; whenever it encounters one where
it does not have the relevant data, it responds by more precisely
calculating the importance. The problem with this algorithm is that
over time, the threshold is so high that very little data is
actually stored, and simultaneously the amount of time necessary to
determine a datum's importance rises -- so with age, reactions slow
(a complex-cause effect, actually, related also to the perception of
time and the condition of the body) and memory deteriorates.

This may or may not be useful to someone. I'm just sort of throwing
it out there for public consumption, because it seems like very few
people recognise this phenomenon -- and I'm not sure whether they
just haven't seen it, or it really isn't there.


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev