[MUD-Dev] Re: Bad Game Designer, No Twinkie! -- By Ernest Adams
John Bertoglio
alexb at internetcds.com
Tue May 19 10:18:41 CEST 1998
-----Original Message-----
From: Caliban Tiresias Darklock <caliban at darklock.com>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Tuesday, May 19, 1998 2:18 AM
Subject: [MUD-Dev] Re: Bad Game Designer, No Twinkie! -- By Ernest Adams
>On 11:06 PM 5/18/98 -0700, I personally witnessed John Bertoglio jumping
up
>to say:
>>
>>I added a mapping element to AR because I have such a bad sense of
>>direction, I get lost in areas I designed. The teleport spell was the
first
>>one added so I could get somewhere when I got lost.
>
>Hmmmm. This disturbs me slightly, actually.
>
>The way I see it, you came across a difficulty in your game (hard to get
>around and keep track of your location), and you solved it by sticking in
a
>way to ignore it completely. Now, I assume you went back and addressed the
>issue later (or that you still have it on your to-do list), but I think
>this sort of design decision often makes it far too easy for someone to
>leave bad design in place because they forgot all about it.
Not guilty (on this one, anyway). I am sorry I failed to make my point more
clearly. I was agreeing with the point on mapping being important in an
adventure/rpg type game, especially for people like ME. Many people
(perhaps, most people) would not get lost in my game world, but I do. I do
not like RPG games which do not offer auto mapping because I hate mapping
my progress on paper. Many people like mapping as they explore. Lewis and
Clark did, I don't.
>As a result, new players log on, say "this sucks", and the designer goes
>"oh, you just haven't given it a chance, it's not that hard". So the new
>player thinks either that he's an idiot, or that you're an idiot
(depending
>on how arrogant or insecure the player in question is). Since this sort of
>design decision is exactly the sort of thing an inexperienced developer
>might make, this could very well contribute to the battle lines of
>'developer v. player'. When the developer does become experienced, he's
>nevertheless been trained by his experiences with players to think that
>players are unreasonable and lazy.
Here, you are absolutly correct. Doing commercial development aimed at
lowest common denominater has taught me a lot about the importance of
making things easy. "It's not that hard" just doesn't cut it the real
world. To a certain degree, real world customers can be said to be
"unreasonable and lazy". This is a reasonable attitude since it is their
dollars (or yen) which pay the freight on commercial projects.
>Hypothetical situation, no accusations leveled, but I think from a
>philosophical standpoint it might be something to think about. I know I've
>often created some sort of 'quick fix' and then never gotten around to
>implementing the real one.
>
Critique accepted with appreciation. In commercial development we call
quick fixes, "features". Bugs are "program quirks". (Just kidding, we try
to ship a perfect product.)
>>>You Have 30 Seconds to Figure Out This Level Before You Die
>>
>><Anyone remember any examples of something so stupid? >
>
>An arcade game by the name of "Skate or Die". Not a MUD, but you had to
run
>around on a skateboard collecting tickets and money, earning points by
>executing stunt moves, and after about fifteen or twenty seconds a voice
>would yell "SKATE OR DIE" and you had to try like hell to avoid some cloud
>of what looked like bees or wasps while you headed directly for the
nearest
>skateboard competition. The problem was that you didn't really have enough
>time to go and do anything while the clock was ticking.
Remember it. Arcade games often had these kind of "feature" since their
ultimate goal was quarter eating. Not cool, but a least understandable. I
basically questioned the orginal point, since I have played hundreds of
computer games and don't recall seeing this happen quite the way he
mentioned it.
>Quake 2 gave some great examples of providing a sense of urgency without
>ever actually placing you in danger. The room shakes, the countdown
starts,
>and you race like hell for the exit. Try just standing there. What
happens?
>Nothing. But until you think to do that, you're convinced that you have to
>get out NOW when the room starts shaking. It's still hard to avoid the
>sudden mad dash for the exit, even when you know nothing will happen if
you
>don't make it.
I love game with an "OOPS" in them. Especially if there was fair warning
not to do something. Pull the lever and you hear a gurgling sound of water
rushing. Stay where you are for to long and you find yourself
underwater...or somthing similar. Good design feature. (Once again, this
group has messed me up. Have to add delayed action triggers to the system.
It was so clean before...sigh. I guess this is the price of excellence.)
>>Bullets are messy. Blades even more so. Carnage is brutal and always
>>glossed over in games. Again, this is more of a problem in visual games.
>
>I *like* brutal carnage that makes people queasy. I explicitly look for it
>in games. Harvester did okay at this, although it definitely fell prey to
>bad acting. I've heard "Flesh Feast" is a good game for this, but I have
>yet to see it in stores. (It's probably old now by game-industry time.
>Internet time, pooh. Game-industry time moves at the speed of light...
>squared.)
>
BTW, the "problem" is was refering to was the sanitizing of carnage in
visual computer games. Nothing wrong with a little blood and gore. The
newish game Myth is quite graphic (no pun intended).
>
>--
>MUD-Dev: Advancing an unrealised future.
>
--
MUD-Dev: Advancing an unrealised future.
More information about the mud-dev-archive
mailing list