Handling lots of objects?

5 views
Skip to first unread message

The Grim Reaper

unread,
Oct 1, 1994, 10:06:48 PM10/1/94
to
I'm working on my game, and I've realized I'm planning on having lots and
lots of objects purely for decorative purpose. This is good, since it adds
realism and whatnot to the setting. However, common sense suggests that
the player should be able to take most of these. This is not good. For
instance, let's say I had a room that was really cold, with icicles hanging
from the ceiling (unncessary to the game, but mentioned in the room desc to
help suggest how cold it is). As I see it, I have a couple options for
handling the icicles:
* Ignore them. Leave them mentioned in the room description, but don't allow
the player to touch them or manipulate them in any way, by not making an
object that responds to 'icicle'. Maybe this approach is okay, but I really
don't like it, because I hate when games don't know basic room nouns, and
also if I needed the player to be able to take one icicle, then I'd have to
put them in, and it's silly to be able to take one icicle and then have there
be no more.
* Put one icicle in. Okay, there's one icicle that can be fiddled with, and if
that's moved, we're back in the first case. Unsatisfactory, as above.
* Don't allow the players to fiddle with the icicles, but have an object
that responds to icicle, with a description and such. Okay, this is the
standard approach. Put the object in, but with a funny message (usually)
saying why the player can't take the icicle (or pick the grass, or buy one
of the lottery tickets, or whatever). I was thinking about doing it this
way, but I don't really care for it. Mostly because my game isn't really
supposed to be funny (it's not about a serious subject, like Trinity is,
but it's not a comedy either), and I don't know how to handle this without
straining disbelief too much. I'm trying to maintain the illusion of
reality, and the sense of being in a story, as much as possible, while
making the game still accessable and playable. For instance, there's
several times when I'll say what verbs are acceptable in a situation, like
this:
"There are seven spheres arranged on the board. They look like they can
be moved around easily.
[To move a sphere, type 'slide clear sphere to the north']"
But i'm going to put in a command to turn off the bracketed information.
That way, someone playing the game not for the first time, who knows the
commands, doesn't have to leave the story to get information, but the
first-time player doesn't need to play guess the parser as much.

But to return to my original point, anyone have a better suggestion?
(I'm even considering just asking the player not to stretch the parser
in certain areas, because it's just inadequate.)
+----------------------------------------------------------+
| One .sig to rule them all, one .sig to find them... |
| One .sig to bring them all and in the darkness bind them |
+----------------------------------------------------------+
| The Grim Reaper (Reaper of Souls, Stealer of .sigs) |
| scy...@u.washington.edu |
+----------------------------------------------------------+


S.P.Harvey

unread,
Oct 1, 1994, 10:23:57 PM10/1/94
to
The Grim Reaper (scy...@u.washington.edu) wrote:
: I'm working on my game, and I've realized I'm planning on having lots and

: lots of objects purely for decorative purpose. This is good, since it adds
: realism and whatnot to the setting. However, common sense suggests that
: the player should be able to take most of these. This is not good. For
: instance, let's say I had a room that was really cold, with icicles hanging
: from the ceiling (unncessary to the game, but mentioned in the room desc to
: help suggest how cold it is). As I see it, I have a couple options for
: handling the icicles:

Many interesting theories about how to properly handle the scenery
icicles mentioned above, all deleted to save bandwith.

My suggestion is this: you can tag the description of a room to simply
repeat itself when a player types <examine some_obj>. I'm currently
coding a game in Inform and the parser handles this very cleanly and
easily. Hence...

Cold Room
This room is very very cold. Your breath appears in cloudy puffs before
your face, and your nose tingles, but not unpleasantly. It's so cold, in
fact, that icicles hang from the ceiling.

> examine breath
Before you can look, it's gone. Breath's like that, you know.

> examine icicles
This room is very very cold. Your breath appears in cloudy puffs before
your face, and your nose tingles, but not unpleasantly. It's so cold, in
fact, that icicles hang from the ceiling.

--- end simulation ---

This doesn't strike me as unreasonable. The player will then understand
that the designer realised the interest inherent in the icicles (hence
the response), but also has not intended for them to be manipulated.

Due to its nature, Inform works with a finite number of objects, so the
frivolous object count must be kept low. I consider this to be a healty
restriction on my creativity, lest I clutter the world with tons of
interesting but useless objects. I've already coded a few decorative
objects that will probably have to go simply due to space restrictions.

My last bit of advice is this: concentrate on the foreground action
before you get too wrapped up in the background scenery. Don't tie
yourself up in knots over something that, after all is said and done,
really has no part to play in your game.

Your playtesters will happily provide you with list after list of items
they'd like to be able to fool with. However, you can't get to this
stage until you create a working, finished product. Add the set dressing
later, not sooner.

Scott

--
----------------------| S.P. Harvey |--------------------------
"Most of the world was mad. And the part that wasn't mad was angry.
And the part that wasn't mad or angry was just stupid.
I had no chance. I had no choice." - Charles Bukowski, 'Pulp'
----------------------| sha...@interaccess.com |--------------------------

Jamieson Norrish

unread,
Oct 3, 1994, 7:37:23 AM10/3/94
to
In article <36l5jt$g...@nntp.interaccess.com> sharvey@interaccess (
S.P.Harvey) writes:

My suggestion is this: you can tag the description of a room to
simply repeat itself when a player types <examine some_obj>. I'm
currently coding a game in Inform and the parser handles this very
cleanly and easily. Hence...

> examine icicles


This room is very very cold. Your breath appears in cloudy puffs
before your face, and your nose tingles, but not unpleasantly. It's
so cold, in fact, that icicles hang from the ceiling.

Ugh! Never ever ever do this. If you're going to repeat part of the
description, make sure it's only that part which specifically concerns
the object. Otherwise, it really sounds like you're just resending the
old information in klunky way.

In some instances it should be possible to avoid having the character
able to interact with the object except through look/smell/hear. The
icicles could be out of reach, or close enough so that if you try to
get one, you knock it off onto the ground and it shatters. That's not
a humourous solution, but effective in some situations. However, where
you're not able to manage something like that, I think this approach
is not the best one to take.

Your playtesters will happily provide you with list after list of
items they'd like to be able to fool with. However, you can't get
to this stage until you create a working, finished product. Add
the set dressing later, not sooner.

On the other hand, this is very sound advice - at least assuming that
the game is not meant to be a simulation first and foremost. Once the
playtesters have given you their lists, you either try as hard as
possible to make each item on the lists as interactive as possible, or
scrub it. Of course, the disadvantage with leaving this step to the
end is that you'll never have enough enthusiasm to do it, and just
realease the game after the bugs are fixed. :)

Jamie

russell wallace

unread,
Oct 3, 1994, 1:32:50 PM10/3/94
to
In <36l4jo$9...@nntp1.u.washington.edu> scy...@u.washington.edu (The Grim Reaper) writes:

>I'm working on my game, and I've realized I'm planning on having lots and
>lots of objects purely for decorative purpose. This is good, since it adds
>realism and whatnot to the setting. However, common sense suggests that
>the player should be able to take most of these. This is not good. For
>instance, let's say I had a room that was really cold, with icicles hanging
>from the ceiling (unncessary to the game, but mentioned in the room desc to
>help suggest how cold it is). As I see it, I have a couple options for

I can see two good ways to handle this:

1. Implement an engine that correctly handles collections of objects,
'common nouns' as well as 'proper nouns'. An engine that would start
off with 50 icicles on the ceiling and correctly handle a request by the
player to take 12 of them and drop 5 of those 12 in the next room. This
would involve writing your own game engine, probably in C or some other
general purpose programming language.

2. Simply respond to 'get icicle' with 'You don't need to take the
icicles'.

Now, as a matter of principle the first option might be preferred; as a
practical solution, most people would probably agree that the second
option is better :)

--
"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwal...@vax1.tcd.ie

smeg...@castlebbs.com

unread,
Oct 3, 1994, 2:40:10 PM10/3/94
to


IS>I'm working on my game, and I've realized I'm planning on having lots and
IS>lots of objects purely for decorative purpose. This is good, since it adds
IS>realism and whatnot to the setting. However, common sense suggests that
IS>the player should be able to take most of these. This is not good. For
IS>instance, let's say I had a room that was really cold, with icicles hanging
IS>from the ceiling (unncessary to the game, but mentioned in the room desc to
IS>help suggest how cold it is). As I see it, I have a couple options for
IS>handling the icicles:
IS>* Ignore them. Leave them mentioned in the room description, but don't allo
IS> the player to touch them or manipulate them in any way, by not making an
IS> object that responds to 'icicle'. Maybe this approach is okay, but I real
IS> don't like it, because I hate when games don't know basic room nouns, and
IS> also if I needed the player to be able to take one icicle, then I'd have t
IS> put them in, and it's silly to be able to take one icicle and then have
IS>there
IS> be no more.
IS>* Put one icicle in. Okay, there's one icicle that can be fiddled with, and
IS>if
IS> that's moved, we're back in the first case. Unsatisfactory, as above.
IS>* Don't allow the players to fiddle with the icicles, but have an object
IS> that responds to icicle, with a description and such. Okay, this is the
IS> standard approach. Put the object in, but with a funny message (usually)
IS> saying why the player can't take the icicle (or pick the grass, or buy one
IS> of the lottery tickets, or whatever). I was thinking about doing it this
IS> way, but I don't really care for it. Mostly because my game isn't really
IS> supposed to be funny (it's not about a serious subject, like Trinity is,
IS> but it's not a comedy either), and I don't know how to handle this without
IS> straining disbelief too much. I'm trying to maintain the illusion of
IS> reality, and the sense of being in a story, as much as possible, while
IS> making the game still accessable and playable. For instance, there's
IS> several times when I'll say what verbs are acceptable in a situation, like
IS> this:
IS> "There are seven spheres arranged on the board. They look like they can
IS> be moved around easily.
IS> [To move a sphere, type 'slide clear sphere to the north']"
IS> But i'm going to put in a command to turn off the bracketed information.
IS> That way, someone playing the game not for the first time, who knows the
IS> commands, doesn't have to leave the story to get information, but the
IS> first-time player doesn't need to play guess the parser as much.

IS>But to return to my original point, anyone have a better suggestion?
IS>(I'm even considering just asking the player not to stretch the parser
IS>in certain areas, because it's just inadequate.)
IS>+----------------------------------------------------------+
IS>| One .sig to rule them all, one .sig to find them... |
IS>| One .sig to bring them all and in the darkness bind them |
IS>+----------------------------------------------------------+
IS>| The Grim Reaper (Reaper of Souls, Stealer of .sigs) |
IS>| scy...@u.washington.edu |
IS>+----------------------------------------------------------+

One, synonyms are your friends; that's a given. For some it can be part
of the game, finding out what to do on their own... for others, it's
just annoying. You're on the right track. IMHO, if I were to do this,
I would try coding a crude "help" command for parser information like
this. (HELP and HINTS are actually two different things. :) Then, for
each place that you want to put in a little blurb about the parser, just
put that string into the room (something like 'helpText= ""') and have
the help command call that text from the room.

If you wanted you could modify the room class to set a default for
helpText as well.

-K.C.

--
+----------------------------------------------------------------------+
| THE CASTLE bbs - Los Angeles, CA, USA - 50 Lines! +1 818.985.6075 |
| 36 CD ROMs - 40+ Multi-Player Games Internet: in...@castlebbs.com |
+----------------------------------------------------------------------+

Mathematical Institute, (0865) 2-73525

unread,
Oct 4, 1994, 5:50:13 AM10/4/94
to
In article <36l4jo$9...@nntp1.u.washington.edu>, scy...@u.washington.edu (The Grim Reaper) writes:
> I'm working on my game, and I've realized I'm planning on having lots and
> lots of objects purely for decorative purpose. This is good, since it adds
> realism and whatnot to the setting. However, common sense suggests that
> the player should be able to take most of these. This is not good. For
> instance, let's say I had a room that was really cold, with icicles hanging
> from the ceiling (unncessary to the game, but mentioned in the room desc to
> help suggest how cold it is).

Several people have already said sensible things about this, so I suppose
I'm just going to repeat them.

As a bare minimum, the words "icicle" and "icicles" ought to be understood,
even if it's only to give a reply along the lines of "The icicles aren't
really important.". But I think the icicles should be. They are, after
all, large, unusual and within reach. So (assuming they play no actual
part in the game) I would create a scenery object which responded to
"icicle" and "icicles" with replies like

"The icicles are too cold to grasp."

or "You are unable to break off the icicles, which are frozen solid as
iron."

or something like that. Now, if you allow the player actually to break
off and carry around an icicle, then I think you may be straying over the
line into red-herring territory. But perhaps it might just about be fair,
if (say) it melted away to nothing in two turns anyway.

One pleasing way to bring such an object into the game is to give it an
unnecessary use, i.e., one which will please a player who finds it but
not inconvenience one who doesn't. For instance, you might let the player
fill a bottle with water from droplets from the icicle.

I have relatively few inhibitions, myself, about introducing scenery
objects for plot purposes or to make a point. Newspapers and signs, for
instance, but also more tendentious things. If I had a Hunting Lodge
I'd probably put a moose-head on the wall even if it did nothing.

Graham Nelson
Oxford, UK

Reply all
Reply to author
Forward
0 new messages