For instance - just so you can see by example what I mean. Suppose
the player has been attacked (but he got away from the immediate
danger). Further suppose the game is written "loosely" enough so the
player has a number of options at this point (just like in real life).
Without attempting to be exhaustive, he can (1) just thank his (or
her) stars and go back home or (2) he could go to a friend's (npc)
house to inlist his aid or (3) he could attempt to turn the pursuit
around on his would be assailents or (4) he could go to the police and
report the attempted mugging.
Now, in the 4th instance (just to pick on this case) he might (after
reporting to the police) go to his friend's house. We all know that
any investigation the police might perform will (1) take time and (2)
be performed outside the cognitive awareness of the player. Their
investigation will take longer logically than going to his friend's
house (for instance). At some later time, the police might then visit
the player to request his attendance at a line-up.
So, how does one interject the passage of time to allow the police to
do their thing - and yet allow the player to continue on in a move by
move basis with other events of the game? Simply setting a timer for
10 moves (for instance) doesn't seem to have the logical consistancy I
am looking for since 10 games moves could amount to only 10 minutes in
game time which would logically NOT be enough time for the police to
do their thing.
I thank you in advance for any ideas you might have
Dana Clarke wrote:
I think INFORM can be told to show time on the status bar instead of the
number of moves. I don't know if that's possible on programming languages
like AGT. TADS could also, but you would need to reprogram it's databases
My favorite way to do this is to tie player accomplishments to the time.
In other words, have time pass as a result of the player passing a
'benchmark', to steal Emily's term--this could be anything from solving a
puzzle to entering a new room.
This is used explicitly in 'Christminster', with the one drawback that the
player is told something will happen at a certain time, and it's
impossible to just sit around and wait until that time.
Also, watch the pacing in 'The Plant' (from the '98 comp) for good
examples of events driving the plot forward in response to player actions,
but not obviously so. This game also didn't suffer from the Christminster
problem of the player wanting to wait for something but being unable to.
In a more loose plot like you describe, this takes more work, but can
still be done. I.e. at the friend's house, they can get a key piece of
information from the friend. This triggers a call from the police with
an update to the investigation, but only if they player started one
earlier. If not, maybe something else gets triggered, like else (or
nothing) happens, like the police call having conducted their own
You don't have to have the response be immediate, either--the benchmark
can trigger a daemon on its own that waits another 5 turns to trigger the
next event (used both in Christminster and The Plant, I think).
I guess from your earlier post you are looking at using HUGO.
Firstly, may I suggest that getting a hold of the source code for 'Spur'
written by Kent Tessman and keeping a copy to hand (I have mine printed and
stored in a folder), it will aid you a lot with regard to how to do most
things within HUGO.
Okay, now HUGO uses a counter and reading from the manual it says that the
counter starts at 0 (or 12:00am in time); therefore setting the counter at
540 would be the equivalent of 9:00am. Obviously, each move the player makes
is classed as one minute in time.
So at its most simplest the game should check the "time" that the player
went to the police, and then decide how long it should take the police
before reporting back to the player. For instance, if the player went to
them at 9:00am and the police were going to contact him/her at 9:00pm, the
game should check to see when the counter gets to 1260 and runs the police
Hope that helps.
[I have a feeling Kent Tessman will also answer this and may give a better
explanation or example than mine, but then he wrote HUGO and has helped me
out a lot in the past. I am more than happy to see that authors of software
Basically, there are two schools of thought on this. The traditional
approach says that things happen when it is "right" for them to doso.
Even if the game is fairly alinear, you have some idea of ordering.
If the player goes to the police, then they will contact him again
after he finds the "mug me" sticker on his backpack, etc. This has
the advantage of being more apropriate for storytelling; things happen
when the story requirwes that they happen. It is more work in an
alinear game, however, and has the disadvantage that the player cannot
let events unfold by simply "waiting around".
The simulationist approach is to construct some sense of game-time,
and have the event set to occur at some established clock-time. If the
player goes to the police at 9:00, they will contact him again at
midnight. This can be as simple as a turn-based counter, or can
involve a complex sense of time.
In Moments out of Time, though I'm not generally all that interested
in complex simulationism, I implemented a very complex timekeeper
system; events were programmed to occur at certain exact times, and
each action was assigned a duration which was used to advance the
game's chronometer. A typical action would take about 1.39 minutes,
"go" and "take", twice that, and a complex action such as "search"
would take about five and a half minutes.
> So, how does one interject the passage of time to allow the police to
> do their thing - and yet allow the player to continue on in a move by
> move basis with other events of the game? Simply setting a timer for
> 10 moves (for instance) doesn't seem to have the logical consistancy I
> am looking for since 10 games moves could amount to only 10 minutes in
> game time which would logically NOT be enough time for the police to
> do their thing.
The simplest way, I suspect, is to fake the passage of time by scripting
it into some appropriate print statement.
In your example, the player arrives at the friend's house. You then do this:
Harvey's Living Room
You greet your old friend Harvey and tell him about your harrowing
escape. "Wow, dude!" Harvey exclaims sympathetically. "I think you need
some good videos to mellow out!" He pops a tape in the VCR and the two
of you spend the next five hours immersed in Harvey's amazing collection
of old "Dobie Gillis" episodes.
If you're running a game timer, you need to crank it up to match the
fake passage of time, but that's trivial. It's a little trickier to make
sure this happens only once, no matter where the player goes after the
mugging -- but not much. All you need to do is set a global
been_mugged_delta_T variable to 1 the first time such a print statement
runs, and then test it everyplace such a print statement needs to be an
Now all you're left with is the combinatorial explosion ... you need to
do this type of scene no matter which direction the player goes after
Hope this helps!
The problem with this version is that what if the player goes to the police,
then straight to the friend's house and gets the information, which triggers
the call from the police?
Depending on how the game has been written and how a person plays it, this
sort of "event trigger" could be very short indeed, which is exactly what
Dana is trying to avoid.
HUGO (which I assume is the IF system she is writing her game on) uses a
counter for each move and is a sort of clock in that each move is a "minute"
in time. (See my previous post on this subject).
I think this is probably the only 'realistic' solution if one let's
the game run on the real clock (rather than any of the plot driven
methods described in this thread).
I've been toying with the idea myself, and I definitely want to use
the real clock and allow the player to wait for things to happen if
he's stumped (of course that won't be ideal for him, but at least the
game will continue).
I was wondering how you did go about implementing this? Is there a way
I can group actions and assign times for them in Inform? Also, what do
I do about the other time element: the turn. As I understand it, in
Inform, turns are used to measure the passage of time for both the
player and all other objects independant of the clock (which can also
set to different increments per turn, standard is one minute I
So, for example, NPC's might get to move once per turn, or a daemon
might do several things each turn. If I advance the clock several
minutes for the player in just one turn (say 'go north' 5 minutes
pass), for all the other objects only one turn has passed and they get
to act only once, regardless of what they do can be done 10 times in
those 5 minutes.
Now, I'm not sure whether that is going to be a problem, but I just
wanted to put it on the table :)
So, could you please explain how you implemented your action times in
Inform? I would love to see how that is done!
: "Lucian P. Smith" <lps...@rice.edu> wrote in message
:> In a more loose plot like you describe, this takes more work, but can
:> still be done. I.e. at the friend's house, they can get a key piece of
:> information from the friend. This triggers a call from the police with
:> an update to the investigation, but only if they player started one
:> earlier. If not, maybe something else gets triggered, like else (or
:> nothing) happens, like the police call having conducted their own
:> You don't have to have the response be immediate, either--the benchmark
:> can trigger a daemon on its own that waits another 5 turns to trigger the
:> next event (used both in Christminster and The Plant, I think).
: Hi Lucian
: The problem with this version is that what if the player goes to the police,
: then straight to the friend's house and gets the information, which triggers
: the call from the police?
: Depending on how the game has been written and how a person plays it, this
: sort of "event trigger" could be very short indeed, which is exactly what
: Dana is trying to avoid.
All I can say is that event timing works much better than 'raw' timing in
the majority of IF that I've played. The pacing just flows better. In
the above situation, I would argue that the first time through, the player
is *not* going to rush through from the police to the friend to the
information, and it's going to feel pretty natural, depending on how
involved getting from one to the next is and how much 'extra' stuff there
is to do along the way. The second time through, the player may indeed
speed through this bit, but that's *also* desirable--the player is
'speed-reading' and shouldn't have to >Z. Z. Z. Z. Z. Z. Z. Z. Z. while
the plot catches up with them.
Here, I'll go out on a limb and make a rather bold statement: Any game
whose optimal walkthrough includes >Z. has a fundamental flaw. (This does
not count situations where 'WAIT' is a meaningful choice between standing
still vs. doing something, say, while answering the interrogator in
'Spider and Web'.) It's not a *serious* flaw, but it does indicate missed
potential. And I left myself some wiggle room with 'optimal' ;-)
(I note here that my own game has a few 'Z's in its walkthrough, so.)
If you haven't, play 'Christminster' and 'The Plant' a couple times and
pay attention to how the pacing works. Compare it to, say, the earthquake
in Zork 3. Then decide which works better for the type of game you're
writing (which could, admittedly, be either one).
> Here, I'll go out on a limb and make a rather bold statement: Any game
> whose optimal walkthrough includes >Z. has a fundamental flaw. (This does
> not count situations where 'WAIT' is a meaningful choice between standing
> still vs. doing something, say, while answering the interrogator in
> 'Spider and Web'.) It's not a *serious* flaw, but it does indicate missed
> potential. And I left myself some wiggle room with 'optimal' ;-)
What about situations where some event is recurring, say every five or
six turns, and the player has to wait for the window of opportunity to
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
* Make your vote count. Get your vote counted.
:> Here, I'll go out on a limb and make a rather bold statement: Any game
:> whose optimal walkthrough includes >Z. has a fundamental flaw. (This does
:> not count situations where 'WAIT' is a meaningful choice between standing
:> still vs. doing something, say, while answering the interrogator in
:> 'Spider and Web'.) It's not a *serious* flaw, but it does indicate missed
:> potential. And I left myself some wiggle room with 'optimal' ;-)
: What about situations where some event is recurring, say every five or
: six turns, and the player has to wait for the window of opportunity to
: come around?
Thinking of anything in particular? ;-)
[Spoilers for 'So Far' and 'Edifice' below]
What sprang to mind was the bit in 'So Far' where you have to wait around
for a cleaning-type person to show up at a gate, unlock it, and go in, and
the player can slip through the gate while they're in there cleaning.
This situation was, as I recall, one of the more frustrating ones for me
in the game. This was probably caused by the fact that the event in
question was somewhat obscure and easy to miss--a lot of activity (the
animals leaving the rink) was followed by a 4-5 turn lull before he
suddenly showed up, and if you were there to watch the activity, you
probably got bored and left before seeing him. Also, the complete cycle
was a lot longer than 4-5 turns; perhaps 20 or so, so if you knew what you
needed to do, there was a long waiting time before it might happen.
That being said, waiting outside the rink for the cleaning staff to arrive
was an actual in-character decision on part of the protagonist--they knew
he'd come, and were hanging out on purpose, waiting for the door to open.
Also, there were plenty of other things to do in the meantime, like mess
with the two animals in the area, or even leave and visit half the game
before coming back and accomplishing this particular task.
What I was objecting more to was having to >Z. either to wait for the plot
to catch up, or to watch the plot flow by. Those types of waits just
serve to distance me from the game. I can't think of particular examples
in the first category right now, but examples in the latter camp abound,
from the opening and closing of 'Lock and Key' to the more extreme 'A
Moment of Hope'.
(The end of 'Lock and Key' is a unique situation, of course, and one could
argue that waiting was an in-character decision, but, I dunno--it still
was uninvolving. Trying frantically to fix up the next trap as you
watched Boldo escape the previous one could have had much more potential
for player investment in the game.)
In my game Dwenodon a certain spell effect lasts for a certain number of
turns to give the player time to get something done that must be done before
the spell wears off. If the player gets the task done more quickly he may
have to wait one or two turns with a z until the spell wears off so that he
Mind you, that's just the translation between turns and minutes (which is
the default for the library if the statusline is set to display time instead
of turns). This is how games like Spur and Guilty Bastards do it. (And the
source code for Down shows how to modify the system so that a single turn
can take less than one minute of game time.)
A somewhat more complex approach to handling time is in Gilles Duchesne's
excellent Scavenger Hunt tutorial, where the amount of time taken by various
actions is tweaked. The source for the tutorial is at:
(ScavHunt5.htm is the step with the timing additions, I believe.)
Keep in mind, also, that you don't necessarily have to tell the player what
time it is, or have the game time reflect the internal counter. It's
sometimes desirable not to give an explicit time and yet still have events
occur on some sort of turn-counter-based schedule (which may or may not be
invisible to the player).
Really? Those times seem far too long. I can walk a fair distance
in 2.78 minutes, and I can drop my backpack, open it, get something,
rearrange the stuff in it, close it, and put it back on in under
two minutes. If you start actually timing how long it takes to
perform actions, I think you'll be surprised.
Stock answer A: Yes, walkign around your own house, dropping your own
backpack, etc. But wanderign around someone else's house with an eye
toward investigation, that takes longer.
Stock answer B: I wouldn't be surprised at all. But if things took as
long in the game as they do in real life, I'd need to add another
decimal place to the time counter, and you'd *never* get to the end.
(1.00 minutes pass...)
You take the bag of potato chips.
(1.40 minutes pass...)
The bag is already open!
>LOOK IN BAG
(5.48 minutes pass...)
The bag is empty.
"Oh, you can get anything...."
Arlo glares at you. "It hasn't come around on the gi-tar yet. We're
not at the chorus. I'm still talking about the Massacree."
Arlo continues a story about eight by ten color glossy photos with
circles and arrows and a paragraph on the back of each one explaining
what it was to be used as evidence in a court of law.
"Oh, you can...."
Without breaking his flow, Arlo backhands you. Ow.
Arlo talks about the draft.
You remain silent.
Arlo talks about the Alice's Restaurant Anti-Massacree movement.
Finally, the chorus *does* come around again on the gi-tar. Arlo nods
and points at you.
You gleefully join in the Alice's Restaurant chorus.
[Your score has gone up by ten points.]
>Stock answer B: I wouldn't be surprised at all. But if things took as
>long in the game as they do in real life, I'd need to add another
>decimal place to the time counter, and you'd *never* get to the end.
It may well be just me, but if I'm given a detailed model of something
I'm going to expect it to be fairly accurate, and if it isn't
I'm going to be jarred. Put detail in or leave it out as you see
fit, but if you put in grossly wrong detail I'm going to have
problems with it.