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
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.
: 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>
> : 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..."
> 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_.
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
> 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 /_/ \__/
: 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 |
+--------------------------------------------------------------------+
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
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 |
+-------------------------------------------------------+
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.
[ 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.
--
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 +
+----------------------------+------------------------------------------+
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.
> 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.
>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