object-oriented adventure games
C.J. Appelo
Hi there,
This is my second message to this delightful medium, which I have only
recently discovered. The first one was about the report I am writing
about the possibilities of using object-oriented programming in game
design. I got some very useful replies to that one (thank you very
much), so I'll try another one.
My report should be finished near the end of November. After that I will
choose a subject to finish my studies with and this will probably be the
design of a new object-oriented system for adventure games. Now I can
hear you say "Aren't there already several systems around?", to which I
can reply "Hey, count the number of wordprocessors and desktop
publishers". But this is not the point. The important thing is: this
could be the first official study project on a university, dealing with
adventure games (Well, at least the first at my university, that is).
I already have some ideas of the different possibilities that I could
come across:
1. The system should be as general as possible, of course, to allow the
development of a multitude of adventure games (which will not be my
job). Trivial.
2. Repeating descriptions of area's/objects/actions and answers of NPC's
should be variable according to all possible systems: linear, circular,
random, whatever. This should also be the case for the results of
actions, position of objects, storyline, etc.
3. There should be virtually no difference between NPC's and the players
character. NPC's should be able to communicate with each other (like in
Lure of the Temptress), perform actions on objects, carry them,
etcetera.
4. It would be nice to introduce a state of mind for all the NPC's. The
number of games that make the NPC's forget that I kicked or insulted
them within seconds are innumerable. The storyline could depend on how
you treat other characters. Changing feelings of NPC's towards other
characters could make the game very enjoyable.
5. NPC's should be able to know things of other characters. This could
be only the face, also the name and job or even their actions up to a
certain degree. Then it would be very interesting communicating with all
of them.
6. I believe many game makers make the mistake of dividing the world in
characters, objects and area's. This could make several situations
almost impossible, like carrying dwarfs (a character could only carry
objects), putting them in a box (an object could only hold other
objects) or entering a new world that's inside a suitcase (area's hold
objects, not vice versa). Everything should be possible. After all,
that's what many adventure games are all about.
7. Maybe I will use aspects of RPG's like character statistics and
combat issues, for RPG's and adventure games are very related to each
other. (Well, that's what I think!)
8. The possibility of playing the game with several players controlling
different characters should be left open.
9. I will have to deal with things like interpreters, multi-tasking,
garbage-collection, etcetera, etcetera...
10. The most important thing about it is that I want everything to feel
like "real". Like characters should not stay on one position during the
entire game, as in many Sierra-like games, 'cause "normal" creatures
don't do that. I just look around here and find that many object have
their own characteristics. Some objects can be connected to each other,
forming one new object, others perform actions periodically (at certain
intervals or at random), and some objects change form when certain
actions are performed on it. This could all be modelled in an object-
oriented design.
Now, finally, here's my question to the readers of this newsgroup. I am
expected to find people that can assist me in my quest for information
about this matter. My teachers know all about OOP but nothing about
computergames. If I find people who have experience in
designing/implementing adventure games/rpg's they could take a look at
my results every now and then and comment on it. I will be open to any
criticism and ideas that could lead to some nice results in this
project. When I do not find enough help from outside this university,
I'm afraid I'll be forced to find another subject to finish my studies
with.
=== ARE THERE PROGRAMMERS OUT THERE WHO HAVE SOME EXPERIENCE ===
=== IN MAKING ADVENTURE GAMES WHO WANT TO DEAL WITH THIS? ===
Several remarks:
- My project will start in december and the final report should be
finished in july 1993.
- The primary focus will be on object-oriented design. The
implementation could be carried out when there's any time left, or in my
spare time after I'm graduated.
- Some previously mentioned ideas may seem too ambitious for a one-
person project, but that's just what I want to find out. Like a child
before Xmas, I put anything on my wishlist not expecting it all to come
true.
- I love to get similar ideas from other people. Don't hesitate.
- Of course, anyone who has given me useful information during this
project, is entitled to receive a copy of my report next year. (So I'll
have to write it in English, oh-ooh...)
- I have some quite clear ideas on what I want to do, but it all depends
on my teachers who may want to move this project into another direction
or even replace it with another. So, don't say I promised you anything.
Hope to read some nice replies, bye,
Jurgen.
===================================================================
| Jurgen Appelo | Delft University of Technology |
| Hooikade 28 | Faculty of Technical Informatics |
| 2627 AB Delft | Julianalaan 132 |
| The Netherlands | 2628 BL Delft |
| +3115-618668 | The Netherlands |
| app...@dutiag.twi.tudelft.nl | |
===================================================================
David Baggett
>The first one was about the report I am writing
>about the possibilities of using object-oriented programming in game
>design.
Object-oriented programming is very suitable for adventure games,
because the gameplay in them tends to revolve around objects anyway.
At least for pure interactive fiction (i.e., text only), there are
several existing languages. You should have a thorough look at TADS,
Advsys, Alan, ADL, etc. before totally reinventing the wheel. Most of
the things you mentioned (at least the things that are applicable to
text adventures) are either already straightforward or could be made
straightforward with a bit of extra coding with many of the existing
systems. (I personally favor TADS, so most of my experience is with
that package.)
The major problem to be solved that is of academic interest (IMHO) is
actor planning. A well-designed and reasonably powerful actor planning
system that could be added to TADS, Alan, etc. would be a major
contribution to the IF world, as it's something that hasn't really been
done well yet. It would also be a reasonable achievement as an AI
project in general if you did a good job.
Actors with goals, feelings, memory, and generally "smart" but
unpredictable behavior would add a great deal to any adventure game.
You could easily write an entire masters thesis just on that. I think
if you try to do all of what you described you'll be biting off more
than you can chew.
Also be sure to look at the work of the CMU Oz Project. While I
haven't been *terribly* impressed with what I've seen come out of that
(and I'm not sure that it's still ongoing), it's worth checking out.
David Graves (sp?) used to post a FAQ here with a list of references
you should pursue. Perhaps someone who's saved a copy could repost it.
As a general administrative note, it would also be really helpful if
someone would volunteer to make a FAQ about all the IF development
systems. I know people have started this, but I don't recall seeing
anything FAQ-like get posted. If someone has a lot of info but doesn't
feel like writing it up, mail it to me and I'll make a FAQ. (In other
words, I volunteer to do it but don't really want to have to duplicate
others' work of hunting all over the world for all the different
systems.)
Dave Baggett
--
d...@ai.mit.edu MIT Artificial Intelligence Laboratory
ADVENTIONS: interactive fiction (text adventures) for the 90's!
d...@ai.mit.edu *** Compu$erve: 76440,2671 *** GEnie: ADVENTIONS
Phil Goetz
A. Ontology: Objects vs. Objects + Locations + People + ...
In Jurgen Appelo's recent post (app...@dutiag.twi.tudelft.nl), he said:
>6. I believe many game makers make the mistake of dividing the world in
>characters, objects and area's. This could make several situations
>almost impossible, like carrying dwarfs (a character could only carry
>objects), putting them in a box (an object could only hold other
>objects) or entering a new world that's inside a suitcase (area's hold
>objects, not vice versa). Everything should be possible. After all,
>that's what many adventure games are all about.
Similarly, in a letter from Erik Francis (m...@west.darkside.com):
>GOOGOL is heavily object-oriented. In fact, there is no distinction
>between an "item," "creature," or "room" -- they're all generalized
>objects, called _symbols_. The one and only property that symbols have
>is that they can point to one other symbol. This can be interpreted (and
>is in the standard implementation) as the first symbol being _inside_ the
>second one. For instance, if I pick up a pen, then the pen-symbol is
>pointing to my symbol.
I think that object-oriented code is the way to go for adventures, and I agree
wholeheartedly with making every location, object, player, non-player, etc.,
the same type of object. I would even claim that the game manager should
respond to non-player actions the same way as to player actions, except for
printing to the screen. (Jurgen also mentioned this.) This forbids you from
having the nonplayers do impossible things for the sake of the plot, but you
can generally stick in any such "impossible action" side-effects elsewhere.
I'd like to point additional reasons why you don't want to
distinguish between objects and locations, etc. In my adventure, objects
can have the property of being transparent and/or openable. Glass bottles,
for instance, are both. If the player is outside a transparent or open object
looking in, he can see inside. If the object is open, he can reach inside.
This takes place regardless of whether the object is used in the game as an
object (glass bottle) or a location (locked car with windows which you can
eventually drive away). Vehicles in general are MUCH easier when objects can
be locations.
You don't want to write the reach-accessibility or sight-accessibility routines
twice, once for objects and once for locations. For one thing, they are
necessarily recursive (A is reachable if A is in B and B is reachable).
Deciding whether the player's location is light or dark is a bit tricky.
If the player is inside object A, the object is treated as his location,
and when the game prints the display of what he can see, it checks to see if
there is light in location A. If not, it first checks for a light source
(i.e. a lamp) in A, then checks to see if A inherits light from the object B
that it is in. This occurs if A is open or transparent, and B is light, i.e.
light(A) if
lit(A) (e.g. a field)
or there exists C in A such that lit(C) (e.g. a lamp)
or {[open(A) or transparent(A)] and in(A,B) and light(B)}
(Yes, it's recursive.) Because this routine works on objects and not just
locations, it provides you with much greater versatility. For instance, your
player can drink the potion labelled "drink me" and run around in objects that
have not been defined as locations (e.g. glass bottles) with logical effects,
these new "locations" being permitted simply by virtue of the fact that the
now smaller player can fit into them. Furthermore, if you have undeveloped
film in a camera, you can have a demon attached to the film which asks at each
turn, "Am I in a lit container?", without writing separate light-inheritance
routines for objects.
B. Command Handlers (Verbs)
The Alan language has a nice feature: each verb can be defined globally,
in a location, or for an object. When the verb is used, the conditions
required (& side-effects) are checked first for the global definition,
then for the location, then the specific object.
I'm just throwing that out as something neat, because I really want to talk
about consistency maintainers. (I'd like to come up with a snappy name,
but...) Most adventures take the approach of writing a bunch of different
verbs, and letting each verb do as it pleases.
Much better, in my opinion, is to have a small set of primitive relations,
and a small set of ways of modifying them. In my adventure, all data was
represented in a semantic network, where nodes represent objects and links,
relations. So the link (ball in box) means the ball is in the box;
(ball on table) means the ball is on the table. (An interesting problem -
because of the bidirectional nature of my network links, my program could
not distinguish between "The key is under the rug" and "The rug is on the
key", with the result that if you typed PUT KEY UNDER RUG it would say
"There isn't room!", meaning there isn't room for the rug on the key.
I don't know of a good solution.)
The key point is that, any time something changes the network, it has to
send a request to make a specific change to the network (add a link,
remove a link, "change" a link (i.e. (ball in X) => (ball in box)).
A very small set of complicated routines would check that this change
was allowable, and implement all side-effects. For instance, if the camera
is on the notebook and the flashbulb is part of the camera, and you carry
the notebook into the next room, the movement verb sends a request to
accomplish (player in roomB). The consistency-maintainer must first
check that there is room in the next room for yourself, the notebook, the
camera, and the flashbulb; if there is, all these items must be relocated
into the next room without affecting their relationships to each. Maintaining
consistency just for "in" and "on" turns out to be tricky, and I think the
reason most adventures don't allow more relations than "in" is because they
don't use this method, but must have each verb maintain consistency
independently, and the complexity of doing this for more than just "in" is
prohibitive.