Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Inform] Some questions

5 views
Skip to first unread message

Edan Harel

unread,
Sep 23, 1997, 3:00:00 AM9/23/97
to

Heres a bunch of questions:

How would someone make a camera that could take pictures?
ie:

Room

This is an unusual room, but I'm too tired to describe it.

There are a bunch of stuff in this room and a collection of things here.

John Smith is here.

>Take picture with camera

You pull out your neat-o polaroid(tm) camera and take a picture. A picture
comes out.

>Take picture from camera

You take out the picture.

>Examine it

It's blank.

>wave it.

You wave it.

>Examine it.

Still blank.

>z, z, z. look at it.
You wait.
You wait.
You Wait.
It's still blank.

>pull out hair.

Ouch!

>Look at picture.

You see a picture. In it, you see:

Room

This is an unusual room, but I'm too tired to describe it.

There are a bunch of stuff in this room and a collection of things here.

John Smith is here.

[end of example]

I'm interested (more like curious, though) in seeing how this is done:
Also, I'd like to be able to take a picture of something, and also examining
objects in the picture (and having the computer deferentiate between objects
in the picture and outside, prefering the outside if an object is in both).
I'd figure this should be easy in OOP, but it's got me stumped :-/.

Also, how about making a recording of something, like a tape recorder.

Next, I'm interested in knowing how to create a simple programming language
in the game. One, for example, that I could use to program a robot or
computer in the game. It would be simple, with perhaps some if statements,
some for loops and while loops and some basic actions.

Finally, I was wondering how (if it's possible) to make (a) boxes placed on
the terminal stay in the same location, and (b) allow user input into
those boxes. (a'la Beyond Zork, EGA Trek, Kobayashi Alternative or
Guardians of Infinity).

Or is my curiousity too much for me? :-)
--
"I have yet to see any problem, however complicated, which, when you looked
at it the right way, did not become still more complicated." -Poul Anderson
"For every problem, there is one solution which is simple, neat and wrong."
-H. L. Mencken

Magnus Olsson

unread,
Sep 24, 1997, 3:00:00 AM9/24/97
to

In article <60bq1n$a...@agate.berkeley.edu>,
Erik George Hetzner <egh@.berkeley.edu> wrote:
>Andrew Plotkin <erky...@netcom.com> wrote:
>
>: Reserve a big memory buffer, and use @output_stream 3 to print to it, and
>: then do <Look>.
>
>Wouldn't it be easier simply to have the photograph point to the room,
>or to a specific object, and then use library routines to print the
>description of that object each time you examine the photograph?

In that case, you get a magic photo that changes when the room changes :-).
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.

Erik George Hetzner

unread,
Sep 24, 1997, 3:00:00 AM9/24/97
to

Andrew Plotkin <erky...@netcom.com> wrote:

: Reserve a big memory buffer, and use @output_stream 3 to print to it, and
: then do <Look>.

Wouldn't it be easier simply to have the photograph point to the room,
or to a specific object, and then use library routines to print the
description of that object each time you examine the photograph?

All that one is going to want to photograph would be objects and rooms
(same thing).

Okay, fine. You'd have to make pointers to all the objects in the room
at the time the photograph was taken, to. Okay. Fine. :) It's easier
to have a long array, and print to it. But not as elegant. :)

Anyhow, it's a very neat trick. Very neat. Wish I could thing of a neat
puzzle that would use it. Perhaps showing photographs to people? Hmm.
--
Erik Hetzner <e...@uclink4.berkeley.edu>


Andrew Plotkin

unread,
Sep 24, 1997, 3:00:00 AM9/24/97
to

Erik George Hetzner (egh@.berkeley.edu) wrote:
> Andrew Plotkin <erky...@netcom.com> wrote:

> : Reserve a big memory buffer, and use @output_stream 3 to print to it, and
> : then do <Look>.

> Wouldn't it be easier simply to have the photograph point to the room,
> or to a specific object, and then use library routines to print the
> description of that object each time you examine the photograph?
>

> Okay, fine. You'd have to make pointers to all the objects in the room
> at the time the photograph was taken, to. Okay. Fine. :) It's easier
> to have a long array, and print to it. But not as elegant. :)

For a single unchanging object, that's going to work. But many objects
change description during a game, and you want the photograph to reflect
their states at the time the photo was taken, not their current states.
Obvious example: the brass lantern (on/off). Or any container
(open/closed.)

This is why I said you'd have to duplicate all the objects, or at least
all their properties and attributes.

(Unless you've got the Camera of Dorian Grey, of course. When you switch
on the lamp, the *photo* of the lamp starts glowing...)

> Anyhow, it's a very neat trick. Very neat. Wish I could thing of a neat
> puzzle that would use it. Perhaps showing photographs to people? Hmm.

The other trick is to make the photograph descriptions very short, and
let the reader fill in the detail.

> x photo
You see a photograph of the living room. Bob and Fred are there.

--Z

--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Andrew Plotkin

unread,
Sep 24, 1997, 3:00:00 AM9/24/97
to

Edan Harel (edh...@romulus.rutgers.edu) wrote:

> How would someone make a camera that could take pictures?

Reserve a big memory buffer, and use @output_stream 3 to print to it, and
then do <Look>.

The big danger is overflowing the buffer. There's no good way to prevent
this, except to make sure the buffer is big enough to hold any possible
room description.

This is the crude and simple technique. The alternative takes a lot more
programming -- you'd pretty much have to duplicate every object in the
game, or at least give it a duplicate set of properties and attributes,
and set up the duplicates in a "model scene" to match the real scene.

> Also, I'd like to be able to take a picture of something, and also examining
> objects in the picture (and having the computer deferentiate between objects
> in the picture and outside, prefering the outside if an object is in both).
> I'd figure this should be easy in OOP, but it's got me stumped :-/.

That's going to take the hard technique. It's not going to be simple
under any circumstances.

> Also, how about making a recording of something, like a tape recorder.

Same thing, only easier. Keep a bunch of variables -- probably an array
-- and store a sequence of values representing what the player hears.
You'll have to put a jigger in every piece of code that generates
"sound", to store the appropriate value in the array.

> Next, I'm interested in knowing how to create a simple programming language
> in the game. One, for example, that I could use to program a robot or
> computer in the game. It would be simple, with perhaps some if statements,
> some for loops and while loops and some basic actions.

The same way you write a programming langauge for any other system.

> Finally, I was wondering how (if it's possible) to make (a) boxes placed on
> the terminal stay in the same location, and (b) allow user input into
> those boxes. (a'la Beyond Zork, EGA Trek, Kobayashi Alternative or
> Guardians of Infinity).

A box in the status window will obviously stay in the same place. User
input there isn't too hard as long as you do it one character at a time.
(Line input in the status window is supposed to work, but it doesn't work
on all interpreters. Er, like mine. Sorry.)

"Mercy" has a good example of this; so does _Bureaucracy_.

Greg Ewing

unread,
Sep 25, 1997, 3:00:00 AM9/25/97
to

Andrew Plotkin wrote:
> (Unless you've got the Camera of Dorian Grey, of course. When you switch
> on the lamp, the *photo* of the lamp starts glowing...)

Hey, what a great idea! Not only easier to implement,
but way cooler than real life!

Of course, you'd have to make really sure that the
player understood that it was NOT a bug...

Greg

BrockBadge

unread,
Sep 25, 1997, 3:00:00 AM9/25/97
to

In article <60bq1n$a...@agate.berkeley.edu>, Erik George Hetzner
<egh@.berkeley.edu> writes:

> Perhaps showing photographs to people?

Such a thing appears in Return to Zork... You can take a picture of
practically anything, and show it to everybody you meet, and they react--

--it gets kind of tedious when you have 4 pages of pictures [with much
more empty space left in the photo book], and you don't wanna miss
everything, so you show everything to everybody and then every time you
take a new picture you rush back to show it to everybody you've ever met--

--but the best innovation is the label "Nothing photogenic here." which
means not everything is photographable. (*whew*)...

>>BKNambo "ducking to avoid the strict text-onlyites"
H newsm...@earthling.net -Spam me, I dare ya ____ __
=@==== http://members.aol.com/brockbadge/index.html /_ \ / /
H H H "World Domination Through Trivia" -S3Kitties / /\ \/ /
H H H Marcher -- Just my imagination -- Nightwatch /_/ \__/

NoJunkMai...@spamfree.enteract.com

unread,
Sep 25, 1997, 3:00:00 AM9/25/97
to

BrockBadge <brock...@aol.com> wrote:
: In article <60bq1n$a...@agate.berkeley.edu>, Erik George Hetzner
: <egh@.berkeley.edu> writes:

: Such a thing appears in Return to Zork... You can take a picture of


: practically anything, and show it to everybody you meet, and they react--


A camera also appears in GTE's TimeLapse, a pretty decent graphic
adventure (IMHO). It was used more as an aid to the interface, however -
allowing the player to photograph strange symbols and things, so that
puzzles could be solved without note-taking or journeying back-and-forth.

Now what would be interesting would be to adopt this camera concept and
extend it to the concept of someone's memory.

> REMEMBER THRONE ROOM

And the player would get some description of said room. The fun would
come in by making the player's memory unreliable and changing the
"memories" as events in the game affect the player. This might be simple
enough to accomplish [in Inform] by giving each room a property called
"memory" which would be a modified description of the room. The beauty
would be in allowing the game to modify such memories.

Hmm, I've hit upon an intriguing idea...


Scott "remember to work while at the office" Harvey


--
+--------------------------------------------------------------------+
| reply-to header hacked | war and slavery, explotation |
| to prevent spam | the common basis of a western nation |
| sharvey at enteract dot com | -KMFDM, Glory |
+--------------------------------------------------------------------+

Marshall T. Vandegrift

unread,
Sep 25, 1997, 3:00:00 AM9/25/97
to

>Now what would be interesting would be to adopt this camera concept and
>extend it to the concept of someone's memory.

No!!!

I'd already come up with something very, very similar for my (non-competition)
game. Now I'd better start coding *real* fast or it will no longer be novel,
original, and that good stuff :-).

BTW, are there any other games, besides Enchanter, etc., in which the player
has some kind of in-game memory?

----------
Marshall T. Vandegrift (mailto:ma...@intrlink.com)
"War spares not the brave, but the cowardly." --Anacreon

Jonathan Fry

unread,
Sep 26, 1997, 3:00:00 AM9/26/97
to

Marshall T. Vandegrift (ma...@intrlink.com) wrote:
: BTW, are there any other games, besides Enchanter, etc., in which the player
: has some kind of in-game memory?

Curses and TATCTAE, for one (though in the latter it's not your own
memory). I don't remember any memory from Enchanter. :)
--Jon

+-------------------------------------------------------+
| Jonathan Fry jf...@skidmore.edu |
+-------------------------------------------------------+

Marshall T. Vandegrift

unread,
Sep 27, 1997, 3:00:00 AM9/27/97
to

In article <60gemt$cre$1...@calvin.skidmore.edu>, jf...@saims.skidmore.edu (Jonathan Fry) wrote:
>Marshall T. Vandegrift (ma...@intrlink.com) wrote:
>: BTW, are there any other games, besides Enchanter, etc., in which the player
>: has some kind of in-game memory?
>
>Curses and TATCTAE, for one (though in the latter it's not your own
>memory). I don't remember any memory from Enchanter. :)

I don't remember anything like that in Curses, though it has been a while
since I played it. As for TATCTAE, sorry but I can't decode that one :-).

By having a "memory" in Enchanter I was refering to where memorized spells
were stored.

Jonathan Fry

unread,
Sep 27, 1997, 3:00:00 AM9/27/97
to


[ Spoilers for "Curses" and "Time: All Things Come to an End" ]

Marshall T. Vandegrift (ma...@intrlink.com) wrote:

: In article <60gemt$cre$1...@calvin.skidmore.edu>, jf...@saims.skidmore.edu (Jonathan Fry) wrote:
: >Curses and TATCTAE, for one (though in the latter it's not your own


: >memory). I don't remember any memory from Enchanter. :)

: I don't remember anything like that in Curses, though it has been a while
: since I played it. As for TATCTAE, sorry but I can't decode that one :-).

: By having a "memory" in Enchanter I was refering to where memorized spells
: were stored.

Whoops, sorry about that... I though you meant a flashback, i.e.: the
museum/map scene from Curses and the Hitler scene from TACTCTAE.

Gunther Schmidl

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

> As for TATCTAE, sorry but I can't decode that one :-).
>
> ----------
> Marshall T. Vandegrift (mailto:ma...@intrlink.com)
> "War spares not the brave, but the cowardly." --Anacreon
>

--

It's "Time: All Things Come To An End"

+------------------------+----------------------------------------------+
+ Gunther Schmidl + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 + except temptation" -- Oscar Wilde +
+ A-4040 LINZ +----------------------------------------------+
+ Tel: 0732 25 28 57 + http://oberon.home.ml.org - german homepage! +
+------------------------+---+------------------------------------------+
+ sothoth (at) usa (dot) net + please remove the "xxx." before replying +
+----------------------------+------------------------------------------+


Derf

unread,
Sep 29, 1997, 3:00:00 AM9/29/97
to


Erik George Hetzner wrote in article <60bq1n$a...@agate.berkeley.edu>...

>Andrew Plotkin <erky...@netcom.com> wrote:
>
>: Reserve a big memory buffer, and use @output_stream 3 to print to it, and
>: then do <Look>.
>


>Wouldn't it be easier simply to have the photograph point to the room,
>or to a specific object, and then use library routines to print the
>description of that object each time you examine the photograph?
>

>All that one is going to want to photograph would be objects and rooms
>(same thing).
>

>Okay, fine. You'd have to make pointers to all the objects in the room
>at the time the photograph was taken, to. Okay. Fine. :) It's easier
>to have a long array, and print to it. But not as elegant. :)
>

>Anyhow, it's a very neat trick. Very neat. Wish I could thing of a neat

>puzzle that would use it. Perhaps showing photographs to people? Hmm.


Hey, I know its about six days late, and already been solved probably, but
to satisfy my curiosity, would it be possible to set the photograph's
description to be the same as the object that you are taking a photograph
of? something like foto.description = noun.description ... I dont know the
field name, but its an educated guess...

Although getting objects within objects would be more hairy. you would have
to append the description of each child object if its visible (or a ghost,
or a very ugly and very very mean looking dog ala King)

Testing for a given object in the photograph would be neigh impossible, with
this method.

Tell me if this would work, so if I ever have a need for a camera I can
implement it...

Since this post is way out of date, please respond by email, de...@tamu.edu

Derf, aka Fred... A novice Inform programmer, and an infrequent Usenet
reader.

Andrew Plotkin

unread,
Sep 30, 1997, 3:00:00 AM9/30/97
to

Derf (de...@tamu.edu) wrote:

> Erik George Hetzner wrote in article <60bq1n$a...@agate.berkeley.edu>...

> >Andrew Plotkin <erky...@netcom.com> wrote:
> >
> >: Reserve a big memory buffer, and use @output_stream 3 to print to it, and
> >: then do <Look>.
> >

> Hey, I know its about six days late, and already been solved probably, but


> to satisfy my curiosity, would it be possible to set the photograph's
> description to be the same as the object that you are taking a photograph
> of? something like foto.description = noun.description ... I dont know the
> field name, but its an educated guess...

This isn't any better than just pointing the photo at the object itself.
If the object's description is a string, it works, but that's the easy
case. The hard case is if the description is a routine which prints out
variable text, depending on the object's state.

Bruce Greenwood

unread,
Oct 1, 1997, 3:00:00 AM10/1/97
to

On 26 Sep 1997 13:52:29 GMT, jf...@saims.skidmore.edu (Jonathan Fry) wrote:

>Marshall T. Vandegrift (ma...@intrlink.com) wrote:

>: BTW, are there any other games, besides Enchanter, etc., in which the player
>: has some kind of in-game memory?
>

>Curses and TATCTAE, for one (though in the latter it's not your own
>memory). I don't remember any memory from Enchanter. :)

> --Jon
I'm not sure if this counts, but there was a game (quite a fair while back)
that used a similar interface to Uninvited and Deja Vu (I think) based on
Ray Bradbury's "Fahrenheit 451"*. It was set after the events in the book,
and you could 'remember' bits of it.

---
Bruce Greenwood

0 new messages