Sense 2.0

3 views
Skip to first unread message

timsim

unread,
Oct 31, 1999, 2:00:00 AM10/31/99
to
There has GOT to be an easier way. All I want to do is allow smell and
listen from adjacent rooms or nested rooms while disallowing all other types
of verbs. As Dr. McCoy would say: "Dammit, Jim, I'm a doctor not a
hemopheliac!" or something like that. This is way too much effort. I now
have to ask myself "Should I spend the next year finishing a 30 room game?".
I still can't believe it can't be made simpler. Couldn't a property be
defined to tell each room which senses can reach to which other rooms?


storage_room: room
sdesc = "storage room"
ldesc = "Shelves of spices and ingredients line three of the walls while a
walk-in
refrigerator takes up the other. Most of the items are out of
your reach.
Through the east doorway you can see the cook's area."
east = cooks_area

smellscope = cooks_area <--- ?
listenscope = cooks_area <--- ?

;

To me, that would say that the player can smell INTO the cooks area FROM the
storage room. Likewise for listen. Now, I await the verbal abuse of all
the people who sweat the small stuff for a living (ie, programmers) to tell
me that this construct is not possible. I like programming, but there has
GOT to be a simpler way. I wondered why "The Plant" didn't implement
'listen' or 'smell'. I guess I know why now.

Anyway, this stuff is like a death spiral. The more you do, the more you
have to do to fix all of the new problems that the last idea generated.
It's no wonder that the Photopia author did what he did. You'd spend a
whole year coding a 20 room game. Not worth it.

THIS is the problem I see with IF. The coding gets in the way of the ideas.

Tim

Lys...@msn.com

unread,
Nov 1, 1999, 3:00:00 AM11/1/99
to
In article <7vi9v4$bl7$1...@news.laserlink.net>,

No, this is certainly possible, and indeed I looked into this approach
early on. But the problem is that as soon as you build this kind of
limitation into the mechanism someone will come along and want senses
to be passed, but only if the player is carrying the magic feather,
etc.

Sense.t attempts to provide maximum flexibility, so that you can
customise its behaviours as much as possible.

>I like programming, but there has
> GOT to be a simpler way. I wondered why "The Plant" didn't implement
> 'listen' or 'smell'. I guess I know why now.
>
> Anyway, this stuff is like a death spiral. The more you do, the more
you
> have to do to fix all of the new problems that the last idea
generated.
> It's no wonder that the Photopia author did what he did. You'd spend
a
> whole year coding a 20 room game. Not worth it.
>
> THIS is the problem I see with IF. The coding gets in the way of the
ideas.

I suppose you could argue that this is why we've also got spell-
checkers and grammar-checkers, because the syntax of language gets in
the way of writing.

Release 2.1 of sense.t is mainly a bug-fix, however, I will endeavor to
implement another file you can #include, a common_sense.t, that will
simplify the behaviours to just what you're discussing.

The seeIn, smellIn and hearIn attributes can either be a game object
(i.e. smellIn = foyer) or they can be a list (i.e. hearIn = [hallway,
kitchen]

Then, all you'll need to do is code the seeIn, smellIn, or hearIn
attributes and you'll have the senses passing along as in the sample.t
game.

--Kevin

Sent via Deja.com http://www.deja.com/
Before you buy.

Kevin Forchione

unread,
Nov 1, 1999, 3:00:00 AM11/1/99
to
timsim <tim...@gateway.net> wrote in message
news:7vi9v4$bl7$1...@news.laserlink.net...

> There has GOT to be an easier way.

I agree with you. Keep in mind that this is an evolving package and will no
doubt improve with time and feedback.

Besides fixing a few bugs, release 2.1 simplifies the scoping mechanism
somewhat. I've eliminating the need for coding the &scope_qVisible,
&scope_qAudible, and &scope_qOlfactory filters that were added with 2.0 in
the passToXxxx methods.

The check for isqVisible, isqAudible, and isqOlfactory has been moved to the
dispcont() function and in the nrmXxAround() and xtndXxAround() methods
themselves. This removes some of the burden of coding up the passToXxxx
methods.

Nope. Changes of this sort are easily done, because the model has been
designed to be as flexible as possible. The coding required to make this
kind of change is no more than a couple dozen lines long.

Based on your suggestion, I'm working on a "common sense" approach, which
will simplify the coding required to do just what is mentioned above. The
attributes are seeInto, smellInto, and hearInto and they can be true, nil, a
room object, or a list of room objects. So you would code sense-passing like
this:

#define USE_COMMON_SENSE
...
// CODE
....


storage_room: room
sdesc = "storage room"
ldesc = "Shelves of spices and ingredients line three of the walls while a
walk-in
refrigerator takes up the other. Most of the items are out of
your reach.
Through the east doorway you can see the cook's area."
east = cooks_area

smellInto = cooks_area
hearInto = [ cooks_area, foyer ]
;

> Anyway, this stuff is like a death spiral. The more you do, the more you
> have to do to fix all of the new problems that the last idea generated.
> It's no wonder that the Photopia author did what he did. You'd spend a
> whole year coding a 20 room game. Not worth it.
>
> THIS is the problem I see with IF. The coding gets in the way of the
ideas.

Yes. It's a combinatorial nightmare, but for any given game it has a finite
limit. Each new attribute or behaviour affects the others to some greater or
lesser degree. An analogy is the complexity of tic-tac-toe to checkers;
checkers to chess. Adding more behaviours means adding more complexity.

There's a trade-off in release 2.1: it assumes that the majority of cases
will be of the kind suggested above: simple, unconditional sense-passing
between rooms.

To accommodate this the contents of all rooms default to accessible; control
is only regulated by the passToLocation() method, which in turn is
determined only by the values of the seeInto, hearInto, and smellInto
attributes. This will work fine for the sense-passing cited above.

The trade-off is this: USE_COMMON_SENSE simplifies room-to-room connections.
If your player is in a nested room and the sense passing is different for
the nestedroom than it is for the room itself; or the conditions of
sense-passing are dependent upon the state of a game object, such as an open
window, you'll still need ot code that limitation somewhere.

But don't despair. It's the trend in programming to make the interfaces
simpler and more user friendly. As this system evolves a balance will be
struck somewhere between allowing an author maximal flexibility as sense.t
strives to do and offering them coding simplicity, as the USE_COMMON_SENSE
#defines strives to do.

Thanks for the feedback. As soon as I've updated the manual and done a
little more testing I'll upload release 2.1.

--Kevin

timsim

unread,
Nov 1, 1999, 3:00:00 AM11/1/99
to
Kevin,

Now, this is what I was hoping to hear. Allow the easy default way and then
the hard (uh, more flexible way) also. Can you put a big blurb in here when
2.1 and the doc is somewhere gettable?

Thanks,
Tim


Kevin Forchione <Lys...@email.msn.com> wrote in message
news:efc6z7KJ$GA.270@cpmsnbbsa03...

Adam J. Thornton

unread,
Nov 1, 1999, 3:00:00 AM11/1/99
to
In article <7vi9v4$bl7$1...@news.laserlink.net>,
timsim <tim...@gateway.net> wrote:
>There has GOT to be an easier way. All I want to do is allow smell and

>listen from adjacent rooms or nested rooms while disallowing all other types
>of verbs. As Dr. McCoy would say: "Dammit, Jim, I'm a doctor not a
>hemopheliac!" or something like that. This is way too much effort. I now

> smellscope = cooks_area <--- ?


> listenscope = cooks_area <--- ?

>THIS is the problem I see with IF. The coding gets in the way of the ideas.

The libraries generally tend to be as flexible as possible, at the cost of
increased complexity.

No one is stopping you from developing a simple sense-passing system, and
putting it up for download, you know.

Adam
--
ad...@princeton.edu
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits

Kevin Forchione

unread,
Nov 2, 1999, 3:00:00 AM11/2/99
to
timsim <tim...@gateway.net> wrote in message
news:7vljt0$ljh$1...@news.laserlink.net...

> Now, this is what I was hoping to hear. Allow the easy default way and
then
> the hard (uh, more flexible way) also. Can you put a big blurb in here
when
> 2.1 and the doc is somewhere gettable?

I have just uploaded Sense.t 2.1 to ftp.gmd.de/incoming/if-archive/sense.zip

With sense 2.1 a couple of bugs were fixed involving the calculation of
scope ceiling and the xtndXxAround() methods. This release makes coding the
more basic kinds of sense-passing relatively easy.

A Small Example
------------------------

For example: You have bread baking in the kitchen and can smell it in the
hallway. To do this you first code:

#define USE_COMMON_SENSE

at the top of your game source. Then simply code your hallway room, as
usual, and add the appropriate sense-passing attributes, such as the
following:

hallway: room
sdesc = "Hallway"
ldesc = "This broad, dimly-lit corridor runs north and south. "

south = startroom
north = kitchen
smellInto = kitchen // actor can "smell into" the kitchen
;

The USE_COMMON_SENSE Attributes
--------------------------------------------------------

If your game #defines USE_COMMON_SENSE, then you can code your sense passing
using seeInto, smellInto, and hearInto attributes (*release 2.2 will add
reachInto as well*). These attributes can be either true, nil, an object, or
a list of objects.

Now we code the kitchen:

kitchen: room
sdesc = "Kitchen"
ldesc = "This is a surprisingly cramped kitchen, equipped with
antiques: the stove is a huge black iron contraption,
and there doesn't even seem to be a refrigerator. A
hallway lies to the south. "
south = hallway
;

Notice that nothing special is needed for the kitchen code. The
USE_COMMON_SENSE option assumes that all rooms allow action/scope to pass
into themselves and their contents, so all the control is handled by the
seeInto, smellInto, and hearInto attributes of the hallway object.

Now we code up the bread:

loaf: fooditem
location = stove
sdesc = "loaf of bread"
ldesc = "It's a fresh loaf with a golden-brown crust. "
noun = 'loaf' 'bread' 'crust'
adjective = 'fresh' 'golden-brown' 'brown'

doEat(actor) =
{
"You tear off a piece and eat it; it's delicious. You tear off
a little more, then a little more, and before long the whole loaf
is gone. ";

/* make the bread vanish by moving it to "nil" */
self.moveInto(nil);
}

isListedOlfactory = true
smelldesc = {
"The faint smell of freshly baked bread wafts to your
nostrils. ";
}
;

The bread requires that its smell description be "listed" in room
descriptions, so we code up the smelldesc, and then give it an
isListedOlfactory = true attribute.

When an actor in the hallway does a <<smell>> any object in the kitchen that
has isListedOlfactory = true and has a smelldesc will be listed in the room
description of the hallway. In addition to using the isListedXxxx properties
to ensure that the object itself is listed in the room description, you can
use the isqXxxxx attributes to make the contents of an object "quiet".

For instance, if we put a window in the kitchen overlooking the backyard, we
wouldn't necessarily want the backyard or its contents to appear in our
kitchen room description, but we would like to be able to look through the
window, and also sense the objects directly (i.e. for a bottle laying in the
grass, <<examine the bottle>>)

To do this, code up the backyard the way you want it. Then add the
appropriate sense-listing control attributes, isListedXxxxx and isqXxxxxx:

backyard: room
sdesc = "Back Yard"
ldesc = {
"The backyard is in a shabby state. The grass is unmown, and
you can just make out an abandonned car hidden in the weeds. ";
if (bottle.isIn(backyard))
"A glass bottle lies in the grass, just beneath the
window. ";
}

isListed = nil
isListedOlfactory = { return (window.isopen); }
isqVisible = true
isqOlfactory = { return (!window.isopen); }
isqAudible = { return (!window.isopen); }
smelldesc = "There is the faintest smell of jasmine from the
backyard."
;

isListed = nil: What happens is that we *never* want to see the
backyard.ldesc displayed from the kitchen, so we set backyard.isListed =
nil.

isqVisible = true: Neither do we want to see the ldescs for the contents
of this room displayed in the kitchen room description, so we set this
attribute to true, making the room "visibly quiet"

isListedOlfactory: Here we get a little fancy. We want the
backyard.smelldesc to appear in the kitchen room description, but *only*
when the window is open. Otherwise we don't want to see the description.

isqOlfactory: Likewise, we don't want the backyard's contents to display
their smelldesc in the kitchen room description unless the window is open,
so we set this to make it "smell quiet" if the window is closed.

isqAudible: And finally, we do the same for the listendesc of the
contents of the backyard.

--------

Now, this will code up a basic sense-passing hallway, kitchen, and backyard.
But there are limitations. For instance: you may not want the player to be
able to <<smell the bottle>> when the window is closed. To make that happen
in your game you will need to add more restriction code, probably through
the use of the passToLocation() / passToContents() methods, although the
code should be much easier to implement than previously.

Relative Sense Descriptions
---------------------------------------
One of the things you want to do is to have your ldesc / smelldesc /
listendesc reflect the relative locations of the actor and the target
object. For example, our bread smelldesc in sample.t looks like this:

smelldesc = {
if (blocksPath(command.plist, &scope_visible) = nil)
"Smells like a fresh loaf of bread! ";
else if (car(command.plist[1])) // This is equivalent to
inPlist(self, PTH_LCC)
"The smell of baked bread is very strong here. ";
else
"The faint smell of freshly baked bread wafts to your
nostrils. ";
}

What this means is that if the bread is visible (i.e.
blocksPath(command.plist, &scope_visible) = nil) then display one message;
otherwise if the bread is not visible, but the actor is in the lowest common
containment as the bread display another message; othewise display our
"faint smell ... " message.

Future releases of Sense will be making this sort of determination easier --
keep your eye out for release 2.2!

--Kevin

timsim

unread,
Nov 2, 1999, 3:00:00 AM11/2/99
to
Alrighty then. Thanks. I'll try this stuff out when I get a chance.
Hopefully, a simple man like me can get it working without any more
questions.


Tim
Kevin Forchione <Lys...@email.msn.com> wrote in message

news:el5copUJ$GA.206@cpmsnbbsa02...

Kevin Forchione

unread,
Nov 3, 1999, 3:00:00 AM11/3/99
to
timsim <tim...@gateway.net> wrote in message
news:7vnaj2$mv9$1...@news.laserlink.net...

> Alrighty then. Thanks. I'll try this stuff out when I get a chance.
> Hopefully, a simple man like me can get it working without any more
> questions.

Oh, there will *always* be questions! Fortunately, with TADS there *are*
answers. With programming the trade-off has always been one of resources:
CPU speed and memory. As the speeds go up and memory prices come down the
world model can become a little more sophisticated ... and the user
interface a little more friendly. But programming, like writing, gains its
value from not being a simple walk in the park.

Expect questions -- hope for answers!

--Kevin

L. Ross Raszewski

unread,
Nov 4, 1999, 3:00:00 AM11/4/99
to
On 1 Nov 1999 16:08:17 GMT, Adam J. Thornton <ad...@princeton.edu> wrote:
>
>No one is stopping you from developing a simple sense-passing system, and
>putting it up for download, you know.
>
<shameless>There is one. I wrote it. senses.h @ gmd Have fun</shameless>


--
"I'm allergic to fire." -- Arthur

TenthStone

unread,
Nov 7, 1999, 3:00:00 AM11/7/99
to
On Mon, 1 Nov 1999 09:16:57 -0000, "Kevin Forchione"
<Lys...@email.msn.com> wrote:
>#define USE_COMMON_SENSE

Just to clarify, Definition Switch No. 151 "USE_COMMON_SENSE" has been
classified into Obsolency Matrix B, meaning that such usage as Mr.
Forchione mentions here will be supported only until the next major
version. To rewrite this statement in accordance with the current
approved standard (R-P 3.1.4a S4 P12 L16), one would have to use a
combination of the two Definition Switches

#define COMPILATION_SYNTAX_INTERPOLATE_COMMON
#define COMPILATION_SYNTAX_LOGIC_GUESS_AT_STRAWS

Actually, it occurs to me that you might want to add

#define COMPILATION_SYNTAX_LOGIC_STAY_BETWEEN_THE_LINES

if you're not absolutely sure of your code.

(If you don't have the slightest clue what the abbreivation R-P might
mean, please disregard this message)

----------------
The Imperturbable TenthStone
mcc...@erols.com tenth...@hotmail.com mcc...@gsgis.k12.va.us

Reply all
Reply to author
Forward
0 new messages