From: a3619@mindlink.bc.ca (Chris Harwood-Jones)
Newsgroups: rec.games.design
Subject: Re: Generic Object Description
Date: 8 Apr 92 17:12:23 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

> Darrell Ulm writes:
> 
> Msg-ID: <1992Apr8.122118.18936@mcs.kent.edu>
> Posted: Wed, 8 Apr 1992 12:21:18
> 
> Org.  : Kent State University
> 
> In article <1992Apr7.220904.14807@oceania.com> steve@oceania.com writes:
> >
> >Regarding Chris Harwood-Jones ideas about a generic object description and
> >Darrell Ulm's retorts, I'd just like to say that judging by what I read,
> Chris
> >would have a chance at actually designing, writing and finishing a game
> using
> >his ideas, Darrell would not.  It's helpful to occasionally explore the
> 
>         Oh, really mister smarty pants...want to take me up on this?
>         Gee whiz, you dont even know me and you jump to such broad concl.
> 
> >theoretical world, but if you want to actually complete a project, it's more
> >critical to keep one foot on the ground.
> 
>         Where else would my feet be?  I don't see what you are getting at.
>         Ive looked at various ai methods and think that some of them should
>         be applied.  Application of known methods is no big deal is it?
>         Anyway, I cant start on this until I finish this compiler optimiser
>         I am working on.
> 
> >
> >Happy designing,
> 
>         OK, ill be happy...Thanks for the vote of confidence...chump
> 
> >Steve
> 
>         Brilliant!
> 
> dulm


Now, gentlemen....

Rather than rag on each other, let's go back to the question.  We're looking
for a "generic object description" for use in an adventure game. I proposed
some ideas for data structures which involved a few basic object "types", and
Darrell commented that I was being too specific.

I fully agree with the idea of defining objects by function.  However, in an
adventure game, there is a very small set of possible functions that can affect
the game.  Characters can be affected by (1) altering their character sheet, or
by (2) altering their capacity to perform various game actions (e.g. "your arms
are paralyzed" means that you can't use the functions 'get', 'drop' or 'put
away').

That is how I came up with my four subclasses:  Every adventure game that I
have ever seen has objects function in at least four ways (in addition to just
being bought, sold and carried):  as armour, weapons, containers or
spellcasters.  Furthermore, these functions make up a relatively large subset
of all possible "interactions" in a computer adventure game.

Of course in reality, any object could have any or all of those functions:  a
brick can hold a ping-pong ball, be worn on top of the head to prevent damage,
be used to hit someone and maybe even cast a spell. However, restricting type
crossover saves disk space and doesn't significantly restrict the game.  It
also makes it much easier on the user creating his or her own objects:  can you
imagine requiring a game user to enter ALL of those stats just to create a
bloody brick?  No-one would ever play the thing!

It seems, and please correct me if I am wrong, that Darrell's approach has
defined the problem too broadly:  he asks "how do I build a reality simulator"
as opposed to "how do I build an adventure-genre game?"  I would argue,
therefore, that having defined the problem as having infinite bounds, Darrell
has prevented himself from coming up with any solution from the outset - unless
of course he is actually God and is just toying with us through the net. :)

So I would like to see Darrell's comments as to how his approach "cashes out"
in an adventure-game context.

Cheers,
Chris H-J

--
----------------------------------------------------------------------
/ Chris Harwood-Jones        ************       a3619@mindlink.bc.ca /
/                                                                    /
/   "It means nothing; and it seems, so far as I can observe,        /
/ useless to others."                                                /
/                                                                    /
----------------------------------------------------------------------