[MUD-Dev] Girl appeal (was: Boys and Girls)

[Caliban Tiresias Darklock]

From: "Sasha Hart" <Sasha.Hart at directory.reed.edu>

> I was being flip - kind of. I do consider these to be like your
> ACG idea, because of their flexibility and my typical goals in
> playing them, although perhaps with a different sense of words
> like "aesthetic," "simple to learn" and so on.

I'm not saying they don't appeal to girls, I just don't think they
fall into that particular category. There are certainly more
categories that could be defined. There are definitely some things
they represent that are important.

> maybe I am just exploiting the wiggle room in "aesthetic," but so,
> I think, will anyone else reading your definition of ACG. :)

That's the tough part to explain, I think. In an ACG, any virtual
people have to somehow quantify "things I like" with a mathematical
model. That mathematical model is by necessity rather limited, so it
can be abused. When REAL people get involved, however, it's not what
*you* think that matters...  but what OTHER people think. So your
own weird ideas of what constitutes "beautiful" are actually a
liability in an ACG, because neither the real people nor the virtual
people will "get" it. So there are two related problems with this
kind of game when you have virtual people:

  1. Things that are not beautiful by any stretch of the imagination
  are considered the MOST beautiful by the game engine.

  2. Things that are exceptionally beautiful to some players are not
  considered beautiful at ALL by the game engine.

The only "perfect" way to solve this is to remove the virtual
people, making real people the final arbiters of
beauty. Unfortunately, that generally means turning the software
into a toy rather than a game, as Maxis puts it; you can't easily
make "build something pretty" a goal unless someone is judging
whether it's pretty, and you can't really force people to submit
their creations for assessment by a real person.

> Conversely, I consider playing for score in Railroad Tycoon to
> have nothing to do with aesthetics, even if the score ostensibly
> involves the judgements of imaginary people. There is just a lot
> of ambiguity in the word, I suppose.

I don't think there's any ambiguity in it at all. If you are playing
purely for score, you're not investing any effort in aesthetics
except insofar as you can manipulate that mathematical model of
beauty applied by the virtual people. But that's not aesthetics,
it's exploitation of the system.

> I would articulate it as being a huge difference in the size of
> the design space, but also the possibility for multiple very
> distinct goals, nearly any goal you like, and maybe also the
> degree of enforcement of goals

That's where I think RCT shines. Ever played it? Here's how it
works:

First, you are given a scenario and a goal with a time limit. Then
you play.  Time passes. When the time limit expires, the game tells
you whether you succeeded.

Then it gets the hell out of your way.

Time continues to pass. All the rules remain the same. And you can
keep playing in the park you've built for as long as you
like. Whether you succeed or fail, you get to keep playing. You
don't have to accomplish the goal. You don't unlock a new scenario
unless you succeed, but you don't have to drop everything and start
over when you fail. You can expand the game simply by adding new
goals to existing scenarios. Okay, so the game says I have to have
3000 guests in three years, but I'd rather try to get 5000 guests in
four -- and I can go for that, if I want. I don't have to stop at
three years, I can keep going -- even if I don't have the 3000
guests at the end of year three.

>> MUD development fails miserably on rule 1: you have a large
>> number of options, but it's HARD to learn -- there's little to no
>> documentation and nobody who knows what they're doing has any
>> time to help you.

> Well, I don't agree with this assessment, but maybe that's because
> I'm think of how easy it is to learn relative to how many options
> you get.

That's more or less the way I feel about C++. I can't think of a
single reason why anyone who uses a computer as anything more than
an appliance *wouldn't* know C++ and be a reasonably competent
programmer. It seems to me that it's just the obvious thing to do,
since we've all theoretically learned the basics of problem solving
through decomposition in grade school.

I don't think any of us would even begin to argue that this is a
reasonable thing to expect from the public at large. And it's not
because they can't learn it, it's simply that they don't *want* to
and shouldn't *have* to.  People want things to be easy to use. They
want to push the button marked "popcorn" on the microwave, not read
the back of the package and type "2:45" on the front panel.

Some people like to learn lots of complex rules and their equally
complex exceptions and special cases. Those people become
developers. And the single biggest problem developers need to
overcome is the idea that the rest of the world bears any
resemblance whatsoever to themselves.

Case in point: if you've been around long enough, I'm sure you
remember some applications that differentiated between the left and
right "control" keys -- left control did one thing, right control
did another. This hasn't altogether stopped; a recent Rose
Electronics "ServeView Plus" manual gave these instructions: "To
enter the reset computer's mouse command, press and release the left
control key, then the O (alphabetic, not zero) key." This practice
primarily stopped because it did not make any sense whatsoever to
anyone EXCEPT a developer; it persists primarily in applications
that are targeted directly at engineers -- "ServeView Plus" is the
firmware installed on Rose's UltraView Pro KVM switches, which allow
network administrators to control multiple computers from a single
keyboard/video/mouse installation.

>> (It might also be argued that there are NO options in MUD
>> development on most servers -- you can only tell it to type text
>> on a limited number of available events, but no matter what you
>> do it will only ever type text.)

> And most games ever devised just boil down to a bunch of mouse
> clicking or hitting of keyboard buttons anyway.

You're trying to compare "many causes, few effects" to "few causes,
many effects". They don't really compare. I might have fifty
different kinds of hammer, but that's not comparable to one tool
that works as a hammer and screwdriver and power drill and sabre saw
and studfinder and spirit level. I may like hammers better, but it's
just not a sensible comparison. (They're both perfectly valid things
for people to like or dislike, though. I happen to like both of
them, and I'm sure there are people out there who *dislike* both of
them.)


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