Re: [kidsgames] Generic adventure game engine

[Terry Hancock <hancock@earthlink.net>]

Hi,
Most of your questions were answered by _analogy_ earlier in
the thread, but I'll try to make it more specific -- with
reference to our "The Light Princess" concept.  I'll let Doug
Loss and jm expound on "Aida Sanfernando".

Horst H Lindner Jr wrote:
> I came into this discussion fairly late, who is trying to organize the
> generic game engine?  I used to love the old text based adventures and still
> have a copy of the Infocom treasury somwhere in the house.  If you just want
> a way to create a generic way of creating new adventures the program should
> be fairly easy, the hardest part of the whole program would be a graphical
> interface for creation of the adventure.  But if you want to do somthing
> like this you need a template of what you are creating to tell how complex
> you want it to be.  Example:
> 
> 1) How complex should the text parser be?  Natural language such as "Take
> the hammer and hit the door with it" or the old simple version such as "hit
> door with hammer"?

I liked the old Infocom games too, but, as impressive as the language
parsing was, it was still very simple and brittle:

*  It only understood simple NV and NVN sentences (with some *very*
   specific examples that apparently had to be hand coded in).

*  It had a small vocabulary of words.  Worse, most of the words were
   actually synonyms.  There were very limited possible actions in the
   game, and the player had to do a lot of guessing to figure out how
   to say what they wanted to do (this could be very frustrating,
   and, as we are targeting a fairly young audience, that's bad).

Various solutions have been implemented, right up to the "Myst" (and
Humongous Entertainment) system of "just click on anything".

Sierra's solution was to implement a small set of "tools" or "actions"
indicated by the shape of the mouse cursor.  For example, to talk to
a character, you would select a "Talk" icon "!" and click on the
character.
Similarly, to "Ask" the character, you'd use "?", etc.  This is good.

LucasArts (the only one I've played is Monkey Island), used an
interesting
combination of the two.  It was more like the text parser, but in
constructing
the sentence, you picked the words from a small menu of available words.
Even though the actual number of word choices was small (<12 or so),
this
wasn't so important, because the number of _significant_ choices was
probably about on par with the Infocom system.  Also, this probably made
it easier to design (?).  This seems even better than the Sierra
solution (though it might be nice to have both kinds of options?).

If you spoke to a character in Monkey Island, you would get a multiple-
choice set of sentences to choose from.  Obviously the game designers
established various choices of outcome from the different choices.

One thing we would LIKE to have is what I call "emotions" and
"affinities"
to drive agent-based non-player characters.  But let me come back to
that after answering your specific questions.

> 2) How do you create a adventure?  Trying to create an engine that was ALL
> in text would be hard on the people creating the adventure, a graphics
> interface where you could create items (hammer, locked door 1, tree, gem
> etc.) and interactions such as "hit tree with hammer" "hit nail with hammer"
> "hit chest with hammer" would be good.  You would also be able to use the
> interface to create scenes, connections between scenes and the initial items
> in each scene.

This sounds like the above should answer it.  You seem to be describing
the Sierra model, more or less.

> 3) Do you need conversion routines for other game engines (for example
> adventure is a game engine that loads various different text adventures for
> unix systems) so it can use older games that are free?

Well, I don't see why. The Infocom games can be interpreted with xzip,
so there's no real reason why a new engine should support them as well.
You could always just call xzip if you wanted to.

> 4) What kind of storage structure are you storing the games in?

Well, obviously from a hardware perspective, we're talking about a
CD-ROM or directly on the harddrive (which might mean a big download).
The file format would probably be some kind of archived resource file,
compiled from something like HTML and images.  This is up to the
engine designer, though.

What we want to be able to create is something like an HTML file
(example only) that defines the game "rooms" and their connections.

There needs also to be a way to define agent character behavior,
and sprite animations.

Graphical tools are needed to create the sprite animations, backgrounds
(GIMP and other general graphics tools probably cover this). We may
need to do some format-fu in order to make sure we can have 
backgrounds and forgrounds, so that characters can move behind 
foreground objects.  

There's also problems that we haven't thought about that the engine
designer will have to come up with -- for example, how do we control
the character's walking around the screen? How do we define the
"map" of each room (i.e. where the character can walk and not walk).
Certain actions should probably be triggerable by simply standing
in the right place in the room.  (These are all properties exhibited
by the Sierra games we've played).

> 5) Do you want it extensible into a more complex game like the old nethack
> under unix systems perhaps with better graphics?  This would add lots more
> complexity to the system.

I see "nethack" is on my system -- but after taking a quick peek,
it appears to be *way* too sophisticated for this task.

> Just saying I want to build a generic adventure engine is easy but WHAT KIND
> and HOW COMPLEX and adventure engine do you want?  If it is only the size of
> the old "hit tree with hammer" type and if you can figure out how to input
> the adventure in text format instead of a graphical one it shouldn't be that
> hard to create but will be harder to create the adventures themselves, if it
> is more natural language and has a spiffy graphical interface to create the
> graphic adventure it could get more complex.  If you want it extensible to
> somthing like nethack it will be very complex and quite interesting to
> create.

Obviously, the easier the game authoring is, the more people will
do it.  But let's think in evolutionary terms here -- where can
we get to quickly?  If we have something accessible to early-
adopters like us (unhampered by technophobia), then we can
leave CASE tools to the next generation of the engine.  Our threshhold
(based more on our interest level than our ability) is something
like creating a largish website with HTML (without a WYSIWYG editor).

In "The Light Princess," many actions, and the clues you get to
solving the puzzles, will depend on character interactions. So,
I'd like to have fairly nice agent behaviors in the characters,
including:

"emotion"
The emotion register tells the agent how it should behave. It
can be altered by player statements and also by environment
conditions the player might be able to change, and also by
the passing of game time.

"affinity"
This is basically emotion with respect to another character.
Actually, I realize that this could be the same as "emotion"
if there's only the one player (which is true for "The Light
Princess"). You'd only need this if you were going to program
with agent-agent interactions, or if you were designing a
more complex, multi-player game. (I don't think we want to
do either of these).

I'm visualizing these characters as something like the
"Augmented finite-state machines," such as are implemented
in the "MIT Behavior Language" which I'm familiar from
(at least on paper) from my study of robotics and AI.

The means of programming them (i.e. the language), is
a little vague as yet.  Of course, I am planning on learning
the "Behavior Language" anyway (for work reasons), but
that may not be true for others (and there may be much
better systems).

> If you every want this to get off the ground DEFINE IT.

Of course, what I want is for someone else to actually define this
concept finely (i.e. create a specification), and just help us
to learn how to use it.  The point is, we have some kind of goal
for an overall game appearance (largely driven by games we've
seen before) and play.  

The truth is, we don't really know the proper way the authoring
should be set up -- we're happy to let you figure something out
and let us learn it.

ALSO, this may ALREADY EXIST.  We just don't know about it. So,
if you think you might've seen this sort of thing (or something
close that could be modified), that's okay too.  This may be
as much a request for a good recommendation and support from
experienced game programmers as for actual development.

-- 
Terry Hancock
hancock@earthlink.net
http://home.earthlink.net/~hancock/index.html

-
kidsgames@smluc.org  -- To get off this list send "unsubscribe kidsgames"
in the body of a message to majordomo@smluc.org