[MUD-Dev] Re: Thoughts
Caliban Tiresias Darklock
caliban at darklock.com
Wed Jan 20 13:49:42 CET 1999
-----Original Message-----
From: Hal Black <hal at moos.ml.org>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Wednesday, January 20, 1999 1:04 PM
Subject: [MUD-Dev] Re: Thoughts
>On Wed, Jan 13, 1999 at 04:32:16PM -0800, Caliban Tiresias Darklock wrote:
>
>> The power of two:
>
>I'll argue against this one. I believe there is something from psychology
>that says something different. [...] For some reason, psychology tests
tell us
>that partial reinforcement is a better training tool than total
reinforcement!
>So, not only do people not find fault with somewhat inconsistent results,
they
>are more likely to try it more often given that it works some of the time!
Perhaps it would be more correct to say that this applies more strongly to
negative results than positive ones. If you win the lottery sometimes, then
people will be okay with it. If you die horribly for no real reason
sometimes, people will scream and gripe and complain forever. Then again,
maybe this rule is completely fallacious.
>> How benchmarks are built:
>
>This certainly is true of the computer industry. 8')
Sun committed the unforgivable sin of benchmarks with Java. They waited till
someone built an independent benchmark, and then hardcoded their VM to
perform incredibly well on it. Remember when they were advertising several
times the performance of Microsoft? The benchmark creator quite rightly
recognised that this was not accurate -- because from real-world
observation, he could see that Sun's JVM was NOT that much faster than
Microsoft's -- and delved into it. When they switched the order of two
comparisons in a test, Sun's score on that test -- and only that test --
dropped by a factor of two hundred. Further investigation turned up Sun's
trickery, which was reported in the media slightly before Sun wagged the dog
and started making a lot of noise about the Microsoft VM being incompatible.
I, for one, still remember this. There was a time when that serious an
ethical breach would bankrupt most companies as people migrated en masse to
other products in disgust. Sun still survives.
Has anyone else noticed how closely the timeline in Cyberpunk:2020 matches
the real world? Am I the only one disturbed by that?
>> It's the thought that counts:
>
>So here's my attempt to hijack 2 minutes of your fame: Players
>and Builders who feel a sense of ownership are more apt to accept
shortcomings
>(in simulation or otherwise) in a game than those with no sense of
ownership.
> 8')
True. However, *specifying* those shortcomings will prevent any sense of
ownership at all, which is sort of what I was getting at.
>Otherwise, seems like a nice list of laws. I always like to hear the
>anecdotes that people tell that taught them some of their lessons in game
>design. Do you have any to share that spawned your list of laws?
Mostly my own reactions to things, really. Sometimes it's applications of
real world musings: the "twice is always" law came from leaving the toilet
seat up twice shortly before I was married, following which I "always" left
the toilet seat up. I had been very conscientious about this for over two
years of prior cohabitation, and just happened to forget a couple times over
the course of about a month. I believe Erma Bombeck also wrote something
similar about this, because it seems to me that I *remembered* the phrase
"twice is always" instead of just finding it appropriate.
I do a lot of reading on marketing and psychology, as well. Most developers
don't understand it to any great degree, which exasperates sales and
marketing, who in turn annoy the hell out of developers because the two
groups don't speak the same language. This was originally an effort to
become the Indispensable Employee, but I actually started to *like* these
fields... and I also discovered that an employee became even MORE
indispensable if he simply bought donuts for the office twice a week.
>Here's another attempt at a law I'll throw in:
> The more responsive an admin is to user feedback of a given type, the
more
>the admin will get. Specifically, as an admin implements features from
user
>suggestions, more ideas for features will be submitted. Likewise, as an
>admin coddles whining players, more whining ensues.
My mother has this problem. She's in senior technical IS management at a
major aerospace company. You would not BELIEVE some of the trivial crap her
employees go around whinging about.
| Caliban Tiresias Darklock caliban at darklock.com
| Darklock Communications http://www.darklock.com/
| U L T I M A T E U N I V E R S E I S N O T D E A D
| 774577496C6C6E457645727355626D4974H -=CABAL::3146=-
More information about the mud-dev-archive
mailing list