Should TAKE ALL identify STATIC or SCENERY objects?
David A. Cornelson
A friend was playing my Town Dragon game and began typing 'take all' all
over the place to locate 'programmed' objects. This never ocurred to me
since I'm not the 'abuse the parser' type of game player.
My question is stated in the header. Shouldn't scenery and static objects
be skipped in the 'take all' code? And/Or maybe there should be an
attribute that the code automatically checks to see if it should make the
attempt, such as 'portable'. Then I began thinking that the point is to
force the player to examine things before he can use them, so maybe there
should be an 'examined' attribute which the parser sets to TRUE when that
particular object is examined.
Obviously I can do this in my own games, but this seems central to all
games, doesn't it?
Any comments?
David A. Cornelson, Chicago
PS: Unofficially, 'Babel' was awesome. Thanks Ian...contest or not...it
was a wonderful game...I haven't played Savannah....sounds
interesting...Tempest seemed out of place, maybe a 10 in a different
contest...the rest, including my own were average. It's funny how
everyone has vastly differing opinions about the 'correct' genre of an IF
game. Has the fantasy game been done too much? Hmmm...no more dragons I
suppose...that's okay because the villian in my next game, (first real
one), is a little black cat named Taschelle. She's very evil.
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
VanTil
David A. Cornelson wrote:
>
> A friend was playing my Town Dragon game and began typing 'take all' all
> over the place to locate 'programmed' objects. This never ocurred to me
> since I'm not the 'abuse the parser' type of game player.
>
> My question is stated in the header. Shouldn't scenery and static objects
> be skipped in the 'take all' code? And/Or maybe there should be an
> attribute that the code automatically checks to see if it should make the
> attempt, such as 'portable'. Then I began thinking that the point is to
> force the player to examine things before he can use them, so maybe there
> should be an 'examined' attribute which the parser sets to TRUE when that
> particular object is examined.
>
> Obviously I can do this in my own games, but this seems central to all
> games, doesn't it?
>
> Any comments?
This raises an interesting point. I found (what I thought to be) some
strange anomolies in the new Zork text adventure (ZTUU). It seems that
when your back stage and you type 'take all' you see 'ropes' and
'sandbags.' There is NO way to find that these objects are there (except
by guessing) by reading any preceeding descriptions (or, obviously,
doing a 'take all'). However in another area I found that a 'take all'
didn't even attempt to take everything that was there. I believe that
this was in the concession stand. I dont know much about the parser
(yet) but I thought that was strange.
Jim
Alan Conroy
>My question is stated in the header. Shouldn't scenery and static objects
>be skipped in the 'take all' code? And/Or maybe there should be an
>attribute that the code automatically checks to see if it should make the
>attempt, such as 'portable'. Then I began thinking that the point is to
>force the player to examine things before he can use them, so maybe there
>should be an 'examined' attribute which the parser sets to TRUE when that
>particular object is examined.
My two cents:
Scenery should be skipped to avoid annoying the player (the more
scenery you define, the worse it gets). Having some flag which
prevents "all" from working in the context of items which obviously
should not be included is a good idea. Personally, I don't like the
idea of forcing the player to examine something before he takes it (at
least, I wouldn't like it if I were a player).
- Alan Conroy
I wanna be a firetruck when I grow up...
Julian Arnold
In article <883861764...@dejanews.com>, David A. Cornelson
<URL:mailto:dcorn...@placet.com> wrote:
> A friend was playing my Town Dragon game and began typing 'take all' all
> over the place to locate 'programmed' objects. This never ocurred to me
> since I'm not the 'abuse the parser' type of game player.
>
> be skipped in the 'take all' code? And/Or maybe there should be an
> attribute that the code automatically checks to see if it should make the
> attempt, such as 'portable'. Then I began thinking that the point is to
> force the player to examine things before he can use them, so maybe there
> should be an 'examined' attribute which the parser sets to TRUE when that
> particular object is examined.
>
> games, doesn't it?
>
> Any comments?
Conventional wisdom says that scenery objects (to use a catch-all term)
should be included as part of "all": both Hugo and Inform do it this way
by default. Frequently someone complains about it though. In Inform you
get around this with the ChooseObjects routine, IIRC, but I couldn't
tell you how this works. In Hugo you would use the ExcludeFromAll
routine to do so on a "global" level:
replace ExcludeFromAll(obj)
{
if obj is static or obj is hidden: return true
else : return false
}
Returning true means "obj *is* excluded from all." Returning false means
"obj *is not* excluded from all."
You can also give objects an exclude_from_all property to override this
behaviour on a "local" level:
exclude_from_all {
return 2
}
Here, if exclude_from_all returns 0 then ExcludeFromAll gets the final
say on the matter. If exclude_from_all returns 1 then the object is
excluded no matter what. If exclude_from_all returns 2 then
ExcludeFromAll is never called, and the object is included no matter
what.
As for the examined attribute, Inform has no such thing, and Hugo has
the known attribute, which is similar. Again, people are divided over
whether such an attribute is good or not (and again the default
behaviour in Hugo is easily overridable, via the ObjectIsKnown routine).
It does add an extra layer of intelligence (or an unnecessary hurdle,
depending on your point of view) to a game's representation of its
world. OTOH it differs from all (I think[*]) other attributes in that it
says something about the object purely from the POV of the player
character. Other attributes (light, container, open, etc.) specify
details inherent to the object itself, regardless of context. IOW,
known/examined is player-centric, and player-centrism, while the
established norm in both Inform's and Hugo's libraries, is not, IMO,
good. Not good at all.
Jools
[*] This isn't true, I've just remembered. There are similar attributes,
such as visited and moved.
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me from
ever completing anything." -- Herman Melville, "Moby Dick"
Chris Renshaw
VanTil <NOS...@NOSPAM.COM> wrote:
>David A. Cornelson wrote:
>>
>> A friend was playing my Town Dragon game and began typing 'take all' all
>> over the place to locate 'programmed' objects. This never ocurred to me
>> since I'm not the 'abuse the parser' type of game player.
>>
>> My question is stated in the header. Shouldn't scenery and static objects
>> be skipped in the 'take all' code? And/Or maybe there should be an
>> attribute that the code automatically checks to see if it should make the
>> attempt, such as 'portable'. Then I began thinking that the point is to
>> force the player to examine things before he can use them, so maybe there
>> should be an 'examined' attribute which the parser sets to TRUE when that
>> particular object is examined.
>>
>> Obviously I can do this in my own games, but this seems central to all
>> games, doesn't it?
>>
>> Any comments?
>This raises an interesting point. I found (what I thought to be) some
>strange anomolies in the new Zork text adventure (ZTUU). It seems that
>when your back stage and you type 'take all' you see 'ropes' and
>'sandbags.' There is NO way to find that these objects are there (except
>by guessing) by reading any preceeding descriptions (or, obviously,
>doing a 'take all'). However in another area I found that a 'take all'
>didn't even attempt to take everything that was there. I believe that
>this was in the concession stand. I dont know much about the parser
>(yet) but I thought that was strange.
I believe that the take all didn't work because the items in that room
(being the concession stand or the place with the costumed grue
(whatever!)) was because the items weren't actually in that room, they
were on the table.
-Chris