[INFORM] Timed input games
Patrick Kellum
Has anyone besides Infocom used timed input in a text adventure? If so,
how dificult is it? I think it would only require a modification of the
Keyboard routine, but thats as far as I got.
Patrick
---
"Every weekday morning the school bell cast its glamour over the
surounding hills, calling the young to classes. They came running
down the slopes and leaping over the streams, out from caves and the
hollows of trees and suburban tract homes, impelled by powers greater
then their own to gain an education."
"The Iron Dragon's Daughter" by Michael Swanwick
Russ Bryan
In article <5eq6mm$iu5$2...@neko.syix.com>, pat...@syix.com (Patrick Kellum)
wrote:
> Has anyone besides Infocom used timed input in a text adventure? If so,
> how dificult is it? I think it would only require a modification of the
> Keyboard routine, but thats as far as I got.
I think Andrew Plotkin's "Freefall" makes use of timed input. The source
is available on ftp.gmd.de and might warrant a look-see.
ЛЛ Russ
--
"Forever caught in desert lands, one has to learn to disbelieve the sea."
Russ Bryan (cle...@javanet.com) Л Genesis
Patrick Kellum
For some reason, Russ Bryan was chatting and out came these words of greatness:
<did I also respond in email, can't remember>
>I think Andrew Plotkin's "Freefall" makes use of timed input. The source
>is available on ftp.gmd.de and might warrant a look-see.
Freefall uses read_char, which is rather easy to use, what I want to use
is aread, but what I want is for it to call the routine every second but
not trash the players typing. As it is, if the command isn't typed in
under a second, it is lost :-(
Andrew Plotkin
Patrick Kellum (pat...@syix.com) wrote:
> For some reason, Russ Bryan was chatting and out came these words of greatness:
> <did I also respond in email, can't remember>
> >I think Andrew Plotkin's "Freefall" makes use of timed input. The source
> >is available on ftp.gmd.de and might warrant a look-see.
> Freefall uses read_char, which is rather easy to use, what I want to use
> is aread, but what I want is for it to call the routine every second but
> not trash the players typing. As it is, if the command isn't typed in
> under a second, it is lost :-(
What interpreter are you using? I don't remember this being a problem in
_Border Zone_, either under Infocom's interpreter or MaxZip. The input
buffer should remain there across calls to the interrupt routine.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Adam Dawes
Hi Patrick!
PK> Has anyone besides Infocom used timed input in a text adventure? If
PK> so, how dificult is it? I think it would only require a modification of
PK> the Keyboard routine, but thats as far as I got.
As in, whilst you're sitting at the prompt wondering what to do, other
characters are wandering around and events are taking place in semi-real-time?
I've no idea what would be involved in this, though I think you are probably
right with your assumptions. At the very easiest level, you could get the
keyboard routine to count up to some value, and then perform a <<wait>>
command; this would allow the other elements of the game to get on with their
work. If no screen display is required, the player needn't even know that any
time has passed. (Incidentally, this is the way The Hobbit managed to be
semi-real-time).
To make things more realistic, you might want to keep a continuous timer
running, counting up at a reasonable rate all the time the prompt is displayed.
Each NPC or event could have a timer position at which it will activate (ie, if
the game timer has a greater value than the NCP value, the NPC gets to take a
move). After each move, the NPC's speed is added to the current timer value,
and the value written back to it. This would allow you to write NPCs of
variable speeds; the rabbit NPC would have a much lower speed value (= smaller
time period) than the tortoise.
If you do any work with this sort of thing, please let us know how you get on!
I for one would be very interested to know; as far as I know, nothing like this
has been done with the ZMachine (apart from Free Fall, of course, but that's
rather less than serious. And no I'm not bitter because Andrew beat me to it.
;)
.\dam. [Team AMIGA] //\ Ad...@darkside.demon.co.uk \//
> http://www.rdainfotec.demon.co.uk/adam/
> http://www.geocities.com/TimesSquare/1225/
Patrick Kellum
For some reason, Andrew Plotkin was chatting and out came these words of greatness:
>What interpreter are you using? I don't remember this being a problem in
>_Border Zone_, either under Infocom's interpreter or MaxZip. The input
>buffer should remain there across calls to the interrupt routine.
I'm using AmigaFrotz. Has anyone else had this prob? I'll try one of the
Infocom ones and see how it works.
David Kinder
Patrick Kellum (pat...@syix.com) wrote:
: >What interpreter are you using? I don't remember this being a problem in
: >buffer should remain there across calls to the interrupt routine.
: I'm using AmigaFrotz. Has anyone else had this prob? I'll try one of the
: Infocom ones and see how it works.
AmigaFrotz doesn't zap the input buffer in Border Zone (at least, it didn't
the last time I checked). What is the code you're using?
David
Patrick Kellum
For some reason, David Kinder was chatting and out came these words of greatness:
>AmigaFrotz doesn't zap the input buffer in Border Zone (at least, it didn't
>the last time I checked). What is the code you're using?
It was just a patch on the keyboard routine, I changed the 'read' to
'@aread' and added a timeout to it. I'm sure this is how it's not suposed
to be done, but I havn't found any example code showing the proper way so
I'm unsure how to peocede. I've considered decompiling Borderzone and
seeing how Infocom handled it, but I havn't had the time to lately.
Adam Dawes
Hi Patrick!
PK> Freefall uses read_char, which is rather easy to use, what I want to
PK> use is aread, but what I want is for it to call the routine every second
PK> but not trash the players typing. As it is, if the command isn't typed
PK> in under a second, it is lost :-(
You need to read the keyboard characters in to a buffer, so that you can
restore the prompt. If the player is halfway through typing "examine clock"
when the clock chimes, it should look something like this:
> exami
***
Quite unexpectedly, the clock chimes the hour.
> exami
(With the cursor now after the "i" in the new prompt). It's nice to give some
indication that the prompt was interrupted (the "***", or whatever you prefer).
I've no idea how tricky it would be to do any of this...