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

Sasha Hart Sasha.Hart at directory.reed.edu
Fri Feb 8 15:20:25 CET 2002


[Caliban]
> [Sasha]
>> [Caliban]

>>>   1. Construction is simple to learn but provides a large number
>>>   of options.  2. A major purpose of construction is to produce
>>>   aesthetically pleasing objects, whether according to peer
>>>   reaction or a series of contextual metrics applied by the game
>>>   engine.  3. Constructed objects can be further modified at a
>>>   later date, and there is normally a method of saving
>>>   individual objects for later reuse or sharing with others.

>> That old game Simlife comes to mind. So does mud development :)

> Have to disagree on both counts.

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.

Aesthetic: There are people who think algorithms are beautiful.  I
believe that they literally do think so. Music can be aesthetic.  I
think games can be, too. That is my exclusive investment in my MUD
projects, using the freedom of a large design space to make
something which is my own and is also aesthetically pleasing. My
interest in other people's games is aesthetic, too. So perhaps this
is atypical, but to me mud development exactly meets your criteria;
maybe I am just exploiting the wiggle room in "aesthetic," but so, I
think, will anyone else reading your definition of ACG. :)
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.

> There are a lot of games that provide flexible and robust
> construction with upgrade and modify options later, but if it
> doesn't give you the tools to make that construction look the way
> *you* want it to look it's not an ACG.

I think we both have a feel for what the difference between "build a
barracks (or farm or whatever) and optionally upgrade it later" and
"build your house" is.

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 (Simlife does this only weakly: because the
game gets so boring if you play it for score, the people I used to
swap orgots with mostly ignored it.)

> 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.  Teach me sockets once and I have access to an enormous
number of variations, of course limited by the basic function of
sockets. ;) I think a basic version of this tradeoff is going to
exist any time you provide a big design space.

> (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. But somehow, I don't
feel like I'm particularly missing out? Although the design space
for text games has limits, it is still vastly flexible. Novels are
hardly dead, even if most of them written in the English language
only use about 26 letters and a handful of punctuation marks. :)
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list