Question about turns
Joona I Palaste
puzzles (ie. distract a person so that he/she goes away for x turns,
then do stuff until he/she comes back, that sort of thing). My question
is, is a turn defined as a single sentence on the command line, or the
entire command line?
Suppose we're in a pub, and waving the mouse causes the bartender to
disappear for 3 turns.
Obviously we have:
Pub
> wave mouse
The bartender sees the mouse and disappears.
> drink beer
The beer tastes good.
> drink beer
The beer tastes good.
> drink beer
The beer tastes good.
As if by magic, the bartender reappears.
Do we then have this?
Pub
> wave mouse, drink beer, drink beer, drink beer
The bartender sees the mouse and disappears.
The beer tastes good.
The beer tastes good.
The beer tastes good.
> fetz veeble
Fetzed, the veeble turns into a potzrebie.
> drop potzrebie
Poztrebie dropped.
As if by magic, the bartender reappears.
The bartender picks up the potzrebie on the floor.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #80 D+ ADA N+++ |
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"No, Maggie, not Aztec, Olmec! Ol-mec!"
- Lisa Simpson
Oren Ronen
news:8q2n81$bnc$3...@oravannahka.helsinki.fi...
(snip, bartender should reappear after 3 turns)
> Do we then have this?
>
> Pub
> > wave mouse, drink beer, drink beer, drink beer
> The bartender sees the mouse and disappears.
> The beer tastes good.
> The beer tastes good.
> The beer tastes good.
> > fetz veeble
> Fetzed, the veeble turns into a potzrebie.
> > drop potzrebie
> Poztrebie dropped.
> As if by magic, the bartender reappears.
> The bartender picks up the potzrebie on the floor.
In the regular Infocom/Inform/TADS parser, no. The first input line causes 4
turns to pass. In fact, commands involving multiple objects also take
multiple turns (e.g. drop the veeble and the potzrebie take two turns
instead of one). This is the norm and what most players are used to.
Oren Ronen
or...@isdn.net.il
Campbell Wild
> turns to pass. In fact, commands involving multiple objects also take
> multiple turns (e.g. drop the veeble and the potzrebie take two turns
> instead of one). This is the norm and what most players are used to.
The way I see it, if it involves multiple actions, it should take more than one
turn (one for each), but picking up/dropping multiple objects could be classed
as one action, therefore taking only one turn. At least, that's the way ADRIFT
is set up.
--
____,-.-.--.-.--.--.___
( / ° \ )°< | =´ ¡´ )
¯¯¯`-^-'--^-'·-' -'¯¯¯¯
www.adrift.org.uk
Carl Muckenhoupt
pretty sure that I was able to pick up multiple objects in one turn.
Mind you, the syntax is important:
> get bag and bug
will be parsed as one command and (possibly, depending on the system)
take one turn, whereas
> get bag. get bug.
will almost certainly be parsed as two commands to be executed
sequentially.
(Hmm... "drink beer and beer and beer" as a way to cheat? I suspect
that the standard libraries won't permit that. "I can only use one
direct object with that verb" or somesuch.)
Generally speaking, I expect time to pass with actions performed, not
with command lines received. Consider the flip side of your question:
Suppose the player enters a command line that doesn't cause any actions
at all. Maybe it was a system command (like "save" or "verbose"),
maybe it couldn't be parsed, maybe it was a blank line. In such cases,
no game time should pass. I've seen games that don't follow this, and
it's jarring. Even annoying, at times.
Sent via Deja.com http://www.deja.com/
Before you buy.
Oren Ronen
news:8q3fup$h3e$1...@nnrp1.deja.com...
> I was recently playing a TADS game that had some timed events, and I'm
> pretty sure that I was able to pick up multiple objects in one turn.
You're right. I just tested with two random Inform and TADS games, and
multiple object commands caused one turn to pass.
Curious. I was sure it worked differently. I wonder what gave me the idea.
Oren Ronen
or...@isdn.net.il
Jason Compton
: at all. Maybe it was a system command (like "save" or "verbose"),
: maybe it couldn't be parsed, maybe it was a blank line. In such cases,
: no game time should pass. I've seen games that don't follow this, and
: it's jarring. Even annoying, at times.
I'd like to go one step further. I'm the founder and chairman of the "Free
Verbose For a Free Society Society" and I am continually appalled at how
IF authors have deprived us of the "free-look" verbose.
Please, creative souls. Some of us would like a free look every once in a
while. A free verbose makes it a better place for all of us.
--
Jason Compton jcom...@xnet.com
Mike Sousa
> I'd like to go one step further. I'm the founder and chairman of the "Free
> Verbose For a Free Society Society" and I am continually appalled at how
> IF authors have deprived us of the "free-look" verbose.
>
> Please, creative souls. Some of us would like a free look every once in a
> while. A free verbose makes it a better place for all of us.
>
I have several "time sensitive" daemons in my IF Comp2000 (or is it IF Comp00?
or IFC2K?, but I digress). While unit testing, I found it annoying that
typing LOOK was causing time to pass in these areas.
So, I created a system verb called REVIEW (R, for short) that shows the PC's
current location (room description) without incrementing the turn counter (or
in this case, causing the daemons to tick away). It works just like LOOK
except no time passes.
With a couple of tweaks, it's now available throughout the entire game. I
know it will have at least *one* fan. :)
Cheers,
-- Mike
Ashley Price
"Mike Sousa" <mso...@efortress.com> wrote in message
news:39CD7626...@efortress.com...
> I have several "time sensitive" daemons in my IF Comp2000 (or is it IF
Comp00?
> or IFC2K?, but I digress). While unit testing, I found it annoying that
> typing LOOK was causing time to pass in these areas.
>
> So, I created a system verb called REVIEW (R, for short) that shows the
PC's
> current location (room description) without incrementing the turn counter
(or
> in this case, causing the daemons to tick away). It works just like LOOK
> except no time passes.
>
> With a couple of tweaks, it's now available throughout the entire game. I
> know it will have at least *one* fan. :)
I agree wholeheartedly that commands (such as "save", "verbose", etc.)
should not add a turn, and the same goes for blank lines and commands that
couldn't be parsed. I am happy to say that it appears that games written on
the HUGO system (of which I am a great advocate) take this into account and
game times does not pass. However, it does class "look" as a turn.
Ashley
Andrew Plotkin
>>
>> I'd like to go one step further. I'm the founder and chairman of the "Free
>> Verbose For a Free Society Society" and I am continually appalled at how
>> IF authors have deprived us of the "free-look" verbose.
>>
>> Please, creative souls. Some of us would like a free look every once in a
>> while. A free verbose makes it a better place for all of us.
> I have several "time sensitive" daemons in my IF Comp2000 (or is it IF Comp00?
> or IFC2K?, but I digress). While unit testing, I found it annoying that
> typing LOOK was causing time to pass in these areas.
> So, I created a system verb called REVIEW (R, for short) that shows the PC's
> current location (room description) without incrementing the turn counter (or
> in this case, causing the daemons to tick away). It works just like LOOK
> except no time passes.
My questions are (1) why would anyone ever use LOOK in your game, if
timing is important, and (2) if the answer is "never", why not just call
REVIEW "look"?
It's easier to remember a change in the behavior of a standard command
then the existence of an entirely new command. Normally it's better to
leave standard behaviors alone, but in this case the difference is
small enough that I'd prefer changing LOOK. I rarely use "look"
intentionally as a time-wasting command.
Or, put in an option: "look slowly" and "look instantly" are
(instant!) mode-changing commands that toggle the behavior of "look".
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Mike Sousa
> > So, I created a system verb called REVIEW (R, for short) that shows the PC's
> > current location (room description) without incrementing the turn counter (or
> > in this case, causing the daemons to tick away). It works just like LOOK
> > except no time passes.
>
> My questions are (1) why would anyone ever use LOOK in your game, if
> timing is important, and (2) if the answer is "never", why not just call
> REVIEW "look"?
>
(1) You have to play the scenes to understand. I didn't design it that way per se,
but during testing, I found myself LOOKing to see the state of the room.
>
> It's easier to remember a change in the behavior of a standard command
> then the existence of an entirely new command. Normally it's better to
> leave standard behaviors alone, but in this case the difference is
> small enough that I'd prefer changing LOOK. I rarely use "look"
> intentionally as a time-wasting command.
>
> Or, put in an option: "look slowly" and "look instantly" are
> (instant!) mode-changing commands that toggle the behavior of "look".
> --Z
Good point. I guess I opted for the easy way out. Note that the new system verb is
not
required to solve anything. It's just there to make life easier for players. (I
just tweaked
the VERBOSE command)
We all know that games released in this day and age need to be player friendly, or
they
get scrutinized a bit. I'm just trying to do my part.
-- Mike
Andrew Plotkin
>>
>> > So, I created a system verb called REVIEW (R, for short) that shows the PC's
>> > current location (room description) without incrementing the turn counter (o
> r
>> > in this case, causing the daemons to tick away). It works just like LOOK
>> > except no time passes.
>>
>> My questions are (1) why would anyone ever use LOOK in your game, if
>> timing is important, and (2) if the answer is "never", why not just call
>> REVIEW "look"?
>>
> (1) You have to play the scenes to understand. I didn't design it that way per
> se, but during testing, I found myself LOOKing to see the state of the room.
You misunderstand me. Why would anyone use LOOK instead of REVIEW, if
timing is important?
Carl Muckenhoupt
wrote:
>You misunderstand me. Why would anyone use LOOK instead of REVIEW, if
>timing is important?
Possibly in order to monitor the changing state of the room. LOOK
essentially becomes a synonym for WAIT THEN REVIEW, and I can imagine
situations where you'd want to do that a lot.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Mike Sousa
> Mike Sousa <mso...@efortress.com> wrote:
> >>
> >> > So, I created a system verb called REVIEW (R, for short) that shows the PC's
> >> > current location (room description) without incrementing the turn counter (o
> > r
> >> > in this case, causing the daemons to tick away). It works just like LOOK
> >> > except no time passes.
> >>
> >> My questions are (1) why would anyone ever use LOOK in your game, if
> >> timing is important, and (2) if the answer is "never", why not just call
> >> REVIEW "look"?
> >>
>
> > (1) You have to play the scenes to understand. I didn't design it that way per
> > se, but during testing, I found myself LOOKing to see the state of the room.
>
> You misunderstand me. Why would anyone use LOOK instead of REVIEW, if
> timing is important?
>
> --Z
Oops, my apologies. Good question; maybe they will. As for (2),
modifying LOOK instead, I opted to not change the behavior of one of the
staple commands of IF.
-- Mike
Darius Katz
says...
> Andrew Plotkin wrote:
>
> > Mike Sousa <mso...@efortress.com> wrote:
> > >>
> > >> > So, I created a system verb called REVIEW (R, for short) that shows the PC's
> > >> > current location (room description) without incrementing the turn counter (o
> > > r
> > >> > in this case, causing the daemons to tick away). It works just like LOOK
> > >> > except no time passes.
> > >>
> > >> My questions are (1) why would anyone ever use LOOK in your game, if
> > >> timing is important, and (2) if the answer is "never", why not just call
> > >> REVIEW "look"?
> > >>
> >
> > > (1) You have to play the scenes to understand. I didn't design it that way per
> > > se, but during testing, I found myself LOOKing to see the state of the room.
> >
> > You misunderstand me. Why would anyone use LOOK instead of REVIEW, if
> > timing is important?
> >
> modifying LOOK instead, I opted to not change the behavior of one of the
> staple commands of IF.
>
Oh my. Are we (the IF community) really that conservative, that you don't
want to risk anything by changing that tiny little behavior of the LOOK
command?
(Actually, I think it's a good idea that LOOK doesn't advance the time.
Since I got a very short memory I tend to abuse it.)
-- Darius
Michael Kinyon
This discussion has been quite interesting, and is related
to one of my own concerns (gripes?) about modern text-based
IF. I am a strong - if not, until now, vocal - advocate of
multiple windows, one of which is dedicated to the location
description. (Another dedicated to the inventory would also
be nice, but this is a lesser priority for me.) This is
something that some of the Legend games did right.
(Unfortunately, they went too far and sometimes also included
lists of acceptable commands and terms. For instance, in
_Eric the Unready_, it is possible to solve certain puzzles
by simply reading the list of words the parser will accept
in a given scene.)
Getting back to my point, if I had one, it bothers me that
"in this day and age", we still have to LOOK (or REVIEW or
whatever) to recall the room description. If one takes
seriously the idea of being immersed in the game's player
character, then one's surroundings are always present.
I see no reason they shouldn't be always present before
the real player.
I realize that some authors like to have subtle changes in
the room description indicate something important, such
as magic or a hallucinatory state or what have you. But
this is easily managed by just refreshing the location
window. If the screen flicker gets the player's attention,
is that so terrible? Players with better memories than
mine probably play in BRIEF mode and don't LOOK much, so
they will miss some of the fun.
I understand that the standard one-window-except-
when-we-want-a-pithy-quote-to-flash-on-the-screen
is inherited from our love affair with the z-machine
and its rivals. And yes, I realize that those trying
to play IF on their TI-80 graphing calculators (or
whatever) are going to be left out of a multi-window
environment. Nevertheless, surely it's time to move
on. Can Glk/Glulx, for instance, handle the sort
of thing I am describing? Those of you developing new
game systems: have you considered this issue at all?
I could say more, but I think I'll stop here and see
how the discussion evolves. I suppose this thread
is becoming cross-postable to r.a.i-f, but perhaps
I'll leave it as it is.
Cheers,
MK
--
Michael Kinyon | email: mki...@iusb.edu
Dept of Mathematics & Computer Science | http://www.iusb.edu/~mkinyon
Indiana University South Bend | phone: 219-237-4240
South Bend, IN 46634 USA | fax: 219-237-6589
"Bonvolu alsendi la pordiston? Lausajne estas rano en mia bideo!
And I think we all know what that means." -- Rimmer
David Picton
mki...@iusb.edu (Michael Kinyon) wrote:
> This discussion has been quite interesting, and is related
> to one of my own concerns (gripes?) about modern text-based
> IF. I am a strong - if not, until now, vocal - advocate of
> multiple windows, one of which is dedicated to the location
> description. (Another dedicated to the inventory would also
> be nice, but this is a lesser priority for me.) This is
> something that some of the Legend games did right.
> (Unfortunately, they went too far and sometimes also included
> lists of acceptable commands and terms. For instance, in
> _Eric the Unready_, it is possible to solve certain puzzles
> by simply reading the list of words the parser will accept
> in a given scene.)
> I understand that the standard one-window-except-
> when-we-want-a-pithy-quote-to-flash-on-the-screen
> is inherited from our love affair with the z-machine
> and its rivals. And yes, I realize that those trying
> to play IF on their TI-80 graphing calculators (or
> whatever) are going to be left out of a multi-window
> environment. Nevertheless, surely it's time to move
> on. Can Glk/Glulx, for instance, handle the sort
> of thing I am describing? Those of you developing new
> game systems: have you considered this issue at all?
I'm sure the idea is worth trying out. Glulx would probably be the
ideal system for this kind of thing. However, it would be possible
with even with Z-code - you would simply define an enlarged status
window which would include the room description. I guess that you
could also do something of this type with HTML tads, but probably not
with character-mode TADS.
--
David Picton, University of Birmingham, England
pict...@my-deja.com, da...@aps5.ph.bham.ac.uk
Mike Sousa
Darius Katz wrote:
> > Oops, my apologies. Good question; maybe they will. As for (2),
> > modifying LOOK instead, I opted to not change the behavior of one of the
> > staple commands of IF.
> >
>
> Oh my. Are we (the IF community) really that conservative, that you don't
> want to risk anything by changing that tiny little behavior of the LOOK
> command?
>
> (Actually, I think it's a good idea that LOOK doesn't advance the time.
> Since I got a very short memory I tend to abuse it.)
>
> -- Darius
I obviously can't speak for the IF community, but that's what I was thinking.
-- Mike
Adam Biltcliffe
> I understand that the standard one-window-except-
> when-we-want-a-pithy-quote-to-flash-on-the-screen
> is inherited from our love affair with the z-machine
> and its rivals.
I never played much IF back when the one-window system was the only
alternative. My love for the single-window system comes from the fact
that I find that it's the easiest, most natural way for me to read text.
In an IF game, I find that having multiple windows to keep glancing back
and forth at detracts from the sense of an ongoing narrative which I'm
participating in, and makes it seem more like a simulation. Ok, many
people would argue that an IF game is a simulation and should be
presented like one. I'm just expressing a personal preference for the
'traditional' system.
> And yes, I realize that those trying
> to play IF on their TI-80 graphing calculators (or
> whatever) are going to be left out of a multi-window
> environment. Nevertheless, surely it's time to move
> on.
I can't speak for anyone else here, but personally I disagree with the
term 'moving on' here. Technical progress isn't necessarily advancement
in any other sense.
jw
thedarkjedi
editor and player applet for the web. I've thought about the layout for
a while and believe in using a number of windows. One for the location
description, one to show the inventory, one to show the current time,
one for commands from the player (and responses from the program) and
perhaps another to show the available exits (that aren't concealed).
I was playing Colossal Cave yesterday and kept getting lost in the
Forest because I didn't know where the exits were and had to keep
LOOKing. I'm hoping to create a more realistic feel with my game and so
believe a representation of sight should be persistant so we know where
the exits are, what the room looks like and what we are carrying all the
time without having to ask.
Ian
Michael Kinyon wrote:
>
> d_k...@hotmail.com (Darius Katz) wrote in
> >mso...@efortress.com says...
> >> Andrew Plotkin wrote:
> >> > Mike Sousa <mso...@efortress.com> wrote:
> >> > >>
> >> > >> > So, I created a system verb called REVIEW (R, for short)
> >> > >> > that shows the PC's current location (room description)
> >> > >> > without incrementing the turn counter (or
> >> > >> > in this case, causing the daemons to tick away). It works
> >> > >> > just like LOOK except no time passes.
> >> > >>
> >> > >> My questions are (1) why would anyone ever use LOOK in your
> >> > >> game, if timing is important, and (2) if the answer is
> >> > >> "never", why not just call REVIEW "look"?
> >> >
> >> > > (1) You have to play the scenes to understand. I didn't
> >> > > design it that way per se, but during testing, I found myself
> >> > > LOOKing to see the state of the room.
> >> >
> >> > You misunderstand me. Why would anyone use LOOK instead of
> >> > REVIEW, if timing is important?
> >> >
> >> Oops, my apologies. Good question; maybe they will. As for (2),
> >> modifying LOOK instead, I opted to not change the behavior of one
> >> of the staple commands of IF.
> >
> >Oh my. Are we (the IF community) really that conservative, that you
> >don't want to risk anything by changing that tiny little behavior of
> >the LOOK command?
> >
> >(Actually, I think it's a good idea that LOOK doesn't advance the
> >time. Since I got a very short memory I tend to abuse it.)
>
> This discussion has been quite interesting, and is related
> to one of my own concerns (gripes?) about modern text-based
> IF. I am a strong - if not, until now, vocal - advocate of
> multiple windows, one of which is dedicated to the location
> description. (Another dedicated to the inventory would also
> be nice, but this is a lesser priority for me.) This is
> something that some of the Legend games did right.
> (Unfortunately, they went too far and sometimes also included
> lists of acceptable commands and terms. For instance, in
> _Eric the Unready_, it is possible to solve certain puzzles
> by simply reading the list of words the parser will accept
> in a given scene.)
>
> Getting back to my point, if I had one, it bothers me that
> "in this day and age", we still have to LOOK (or REVIEW or
> whatever) to recall the room description. If one takes
> seriously the idea of being immersed in the game's player
> character, then one's surroundings are always present.
> I see no reason they shouldn't be always present before
> the real player.
>
> I realize that some authors like to have subtle changes in
> the room description indicate something important, such
> as magic or a hallucinatory state or what have you. But
> this is easily managed by just refreshing the location
> window. If the screen flicker gets the player's attention,
> is that so terrible? Players with better memories than
> mine probably play in BRIEF mode and don't LOOK much, so
> they will miss some of the fun.
>
> I understand that the standard one-window-except-
> when-we-want-a-pithy-quote-to-flash-on-the-screen
> is inherited from our love affair with the z-machine
> and its rivals. And yes, I realize that those trying
> to play IF on their TI-80 graphing calculators (or
> whatever) are going to be left out of a multi-window
> environment. Nevertheless, surely it's time to move
> on. Can Glk/Glulx, for instance, handle the sort
> of thing I am describing? Those of you developing new
> game systems: have you considered this issue at all?
>
> I could say more, but I think I'll stop here and see
> how the discussion evolves. I suppose this thread
> is becoming cross-postable to r.a.i-f, but perhaps
> I'll leave it as it is.
>
> Cheers,
> MK
>
> --
> Michael Kinyon | email: mki...@iusb.edu
> Dept of Mathematics & Computer Science | http://www.iusb.edu/~mkinyon
> Indiana University South Bend | phone: 219-237-4240
> South Bend, IN 46634 USA | fax: 219-237-6589
>
> "Bonvolu alsendi la pordiston? Lausajne estas rano en mia bideo!
> And I think we all know what that means." -- Rimmer
--
+------------------------------+
| http://www.thedarkjedi.co.uk |
+------------------------------+
Ashley Price
In my last post on this topic I wrote:
> I agree wholeheartedly that commands (such as "save", "verbose", etc.)
> should not add a turn, and the same goes for blank lines and commands that
> couldn't be parsed. I am happy to say that it appears that games written
on
> the HUGO system (of which I am a great advocate) take this into account
and
> game times does not pass. However, it does class "look" as a turn.
Thanks to advice from Kent Tessman (the man who wrote Hugo) I can now help
those who, like me, use this wonderful system, to stop the "look" command
from "adding a turn".
Add the following just before the #include "verblib.g" line (if you are
unsure about this use the sample program to see where this is.
xverb "look"
* DoLookAround
In Kent's own words "by making 'look' an xverb, [it should] not call the
'main' routine afterward"
I have tried it in my game with a daemon and it does work.
Hope that helps
Ashley
Lucian Paul Smith
: (1) You have to play the scenes to understand. I didn't design it that way per se,
: but during testing, I found myself LOOKing to see the state of the room.
If I was LOOKing and timing was important, I would likely type >LOOK and
then >UNDO. Making LOOK a meta-verb would be nice, and there is
precedent--I believe Varicella made verbs like 'look' at least take a lot
less time than other verbs, if not eliminating the time it took
completely.
There are probably other examples, as well.
-Lucian
Mike Sousa
Lucian Paul Smith wrote:
> Mike Sousa (mso...@efortress.com) wrote:
>
> : (1) You have to play the scenes to understand. I didn't design it that way per se,
> : but during testing, I found myself LOOKing to see the state of the room.
>
> If I was LOOKing and timing was important, I would likely type >LOOK and
> then >UNDO.
Heh. That's what I was doing. A beta-tester was doing the same and read me the riot
act, so to speak, about requiring UNDO to solve a scene. What's that saying about
pleasing all the people some of the time.... :)
> Making LOOK a meta-verb would be nice, and there is
> precedent--I believe Varicella made verbs like 'look' at least take a lot
> less time than other verbs, if not eliminating the time it took
> completely.
>
> There are probably other examples, as well.
>
Point taken. Needless to say, I'm now more educated on this topic.
Cheers,
-- Mike
Michael Kinyon
>In an IF game, I find that having multiple windows to
>keep glancing back and forth at detracts from the sense
>of an ongoing narrative which I'm participating in, and
>makes it seem more like a simulation.
Even when the windows are essentially nonoverlapping?
Again, I'm thinking of some of the old Legend games.
If we were talking about clicking back and forth
between full screen windows, then I would agree with you.
>Ok, many people would argue that an IF game is a
>simulation and should be presented like one.
Well, to allay any concerns up front, I am not a
simulationist. However, I would say that a good chunk
of IF, even that which is mostly puzzle-free, relies
at one time or another on remembering the details of
the present location. Since IF is still "traditional"
as you call it, I am speaking hypothetically here,
but I would find it far more distracting to my
immersion in the narrative to type LOOK repeatedly
than to glance at another window.
>I'm just expressing a personal preference
>for the 'traditional' system.
I understand. You say "to-may-to", I say "to-mah-to".
>I can't speak for anyone else here, but personally
>I disagree with the term 'moving on' here. Technical
>progress isn't necessarily advancement in any other sense.
Touche. You are right to question my diction; I should
have phrased it differently. I didn't mean to imply
abandonment of the one-window system. I meant to imply
that it's time for more options.
11dig...@my-deja.com
different actions are assigned different time intervals (picking up an
object = 5 sec; going into another room: indoors = 15 sec, outdoors = 1
min; etc.).
Alexander Deubelbeiss
11dig...@my-deja.com <11dig...@my-deja.com> schrieb in Nachricht
<8r53b4$17u$1...@nnrp1.deja.com>...
>I don't see what's so hot about turns in a game. I much prefer it if
>different actions are assigned different time intervals (picking up an
>object = 5 sec; going into another room: indoors = 15 sec, outdoors = 1
>min; etc.).
>
>
subdivided games when you don't have strict time limits for each and every
thing. With turns, you can say, "OK, the final puzzle of this scene is
solved, so now it's the Evening scene." If you have a time system, you have
to either make up an excuse to _cut_ to Evening from 3:49.22 PM ("you spend
the rest of the afternoon in the kitchen, peeling potatoes for the crew"),
or you calculate your puzzles so players can't finish them before a certain
time, and lose if they're too slow.