Real-time games?
Daniel Yu
I'm toying with the idea of writing a real-time
piece of IF (no, I'm not talking about Freefall),
but I can't decide if this sort of thing
detracts from a game more than it could contribute.
The only example of this I know of is Infocom's
"BorderZone", which, admittedly, I've never played.
Any thoughts?
--
=======================================
Daniel Yu
email: dani...@autodesk.com
ds...@holonet.net
=======================================
Zachery Tigger Bir
Daniel Yu <dani...@autodesk.com> writes:
>
> I'm toying with the idea of writing a real-time
> piece of IF (no, I'm not talking about Freefall),
> but I can't decide if this sort of thing
> detracts from a game more than it could contribute.
>
> The only example of this I know of is Infocom's
> "BorderZone", which, admittedly, I've never played.
>
> Any thoughts?
>
If you do, make sure you follow Infocom's footsteps and include the
"turn off" feature, or at least a "pause". I really liked BorderZone
(I dig espionage), but without these features, I thik I'd be
frustrated really quickly. I'd just be certain that your story
requires it. It's a cool feature, but I don't think it would do much
for Zork I, for example.
> --
> =======================================
> Daniel Yu
> email: dani...@autodesk.com
> ds...@holonet.net
> =======================================
--
Zachery J. Bir - zb...@indiana.edu
http://seven.ucs.indiana.edu/~zbir/index.html
Fredrik Ekman
Daniel Yu <dani...@autodesk.com> writes:
> I'm toying with the idea of writing a real-time
> piece of IF (no, I'm not talking about Freefall),
> but I can't decide if this sort of thing
> detracts from a game more than it could contribute.
The only real-time IF I have seen is an Eamon game, the title of which
I think is Sands of Mars or some-such. The whole thing is absolutely
horrible (I am tempted to use stronger language here, but someone's
Cyber-Patrol might object (hmm... maybe I should use stronger language
just to mess with people's Cyber-Patrol)).
One problem I see with this approach is that fast typists have a
decided advantage. I also don't quite see the point of forcing the
player to think quickly in a kind of game which relies on in-depth
problem solving.
On the other hand, it just struck me that if MUDs are considered IF,
then you have a whole bunch of them just around the virtual corner.
/F
Peter Larsson
>I'm toying with the idea of writing a real-time
>piece of IF (no, I'm not talking about Freefall),
>but I can't decide if this sort of thing
>detracts from a game more than it could contribute.
>
>The only example of this I know of is Infocom's
>"BorderZone", which, admittedly, I've never played.
>
>Any thoughts?
Yes, I've thought about it once or twice. I have a long-running project in
progress with the intend to examine the problem.
My idea is that things should run in an even pace in the program, as opposed
to in discrete time-steps equal to the number of returns entered in the
prompt, or sub-problems solved (ie like in Christminster). That's
real-time, right?
Since the player sees and learns things in another pace than he actually
does things, there's a need of two windows; an input window where commands
are entered, and an output window where feedback are presented. The idea
is that the output window not only presents the player with feedback to
his own actions, but also tells what else happens, what he sees, etc.
Depending of the time scale, there might also be of interest to simplify the way
commands are given to the game. If for instance you are hunted by a
terrific monster of some kind, you might be easily caught up if you are
forced to enter "run through the door" each time. So, a command palette of
some kind with command buttons might be desireble. The game I have in mind
is a game like that. Games with a larger timescale are likely to loose
against the regular if-games. The gain is less than the cost, especially
as the difference to ordinary i-f is not that big. So, as I see it, we'll
end up with some kind of arcade-adventure breed, wich may or may not be a
good thing.
What I like to do is to examine this by writing a game just like that (I
mentioned it in my "RingQuest" post recently). Will it be playable at all?
Will it be fun? I think those questions can't be answered before trying.
What is utterly important though, is not to loose the classic i-f feeling.
A good vocabulary as well as a rich world to explore, and a good storyline
with a clear goal to achieve is absolutely necessary. Otherwise, there's a
good chance playing Doom will be better spent time.
I haven't seen any game like that. Please enlighten me if there is one.
Also I'm very interested in You r.a.i-f reader's thoughts on the idea.
Hopefully I have some results to share some day, if only time permitted me
to complete my project!
On the bottom line, I think that i-f can gain a lot from a successful
marriage with time. After all, thats how the world works! The sence of
reality, "being there"-feeling will be stronger.
Waiting to hear about your thoughts,
Peter
--------------------------------------------------------------------------
Peter Larsson Phone: +46 920 75216
Arctic Software AB Fax: +46 920 75299
email: Peter....@lule.frontec.se
--------------------------------------------------------------------------
Jason B Dyer
Daniel Yu (dani...@autodesk.com) wrote:
: I'm toying with the idea of writing a real-time
: piece of IF (no, I'm not talking about Freefall),
: but I can't decide if this sort of thing
: detracts from a game more than it could contribute.
You might be able to have the player choose between real-time
and turn-based play from the start. That way slow typists
don't have to panic.
There would need to be some sort of conversion, like x secs=1 turn.
Remember that the game must be appropriate for real-time play.
So Far in real time just doesn't seem like a good idea. :)
Jason Dyer
jd...@u.arizona.edu
Julian Arnold
In article <32B075...@autodesk.com>, Daniel Yu
<URL:mailto:dani...@autodesk.com> wrote:
>
> I'm toying with the idea of writing a real-time
> piece of IF (no, I'm not talking about Freefall),
> but I can't decide if this sort of thing
> detracts from a game more than it could contribute.
>
> "BorderZone", which, admittedly, I've never played.
>
> Any thoughts?
I enjoyed "BZ" a great deal. Of course, mostly real-time just penalizes
slower typers and/or readers (I took several attempts to complete the
final sequence of moves of "BZ" in fast mode). As somebody else says,
real-time wouldn't do a lot for "Zork."
It does enhance gameplay for certain types of puzzles. For example, the
second part of "BZ" works very well, particularly the patrolling guards
(BTW, you have just read a spoiler). I imagine some (many?) people
don't like the concept of a real-time game because obviously you can't
sit back and consider your next move. Unless you pause the game ("BZ"
had a PAUSE command, and I suggest you do to), but it's easy to forget
to do this at the time.
If you choose real-time, it dictates, to some extent, the type of game,
and the content (type of puzzles). I don't see it working for
"puzzle-less" games.
Finally, I think there are now interpreters on the major IF platforms
which support timed input (Frotz for DOS and UNIX(?), MaxZip for Mac,
Zip 2000 for Acorn), so it's feasible from that point of view.
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me
from ever completing anything." -- Herman Melville, "Moby Dick"
Bill Hoggett
On 13-Dec-96 Daniel Yu <dani...@autodesk.com> wrote:
>I'm toying with the idea of writing a real-time
>piece of IF (no, I'm not talking about Freefall),
>but I can't decide if this sort of thing
>detracts from a game more than it could contribute.
>The only example of this I know of is Infocom's
>"BorderZone", which, admittedly, I've never played.
>Any thoughts?
You'll need to be *very* careful how you handle this, since
people read at different speeds and some react faster than
others, both mentally and physically. You don't want to
turn your story into a hand-eye coordination test. I can't
think of any game that has used this really well, even
counting BorderZone. You might also want to have a look at
Melbourne House's 8-bit Middle-Earth trilogy (The Hobbit,
Fellowship of the Ring and Shadows of Mordor) although
thse are mediocre at best. (I'm being generous today!)
Bill Hoggett (aka BeeJay) <mas.su...@easynet.co.uk>
IF GOD IS LIFE'S SERVICE PROVIDER WHY HAVEN'T I GOT HIS I.P. NUMBER ?
Matthew Russotto
In article <peter.larsson-1...@modem4.lule.frontec.se> peter....@lule.frontec.se (Peter Larsson) writes:
}My idea is that things should run in an even pace in the program, as opposed
}to in discrete time-steps equal to the number of returns entered in the
}prompt, or sub-problems solved (ie like in Christminster). That's
}real-time, right?
}
}Since the player sees and learns things in another pace than he actually
}does things, there's a need of two windows; an input window where commands
}are entered, and an output window where feedback are presented. The idea
}is that the output window not only presents the player with feedback to
}his own actions, but also tells what else happens, what he sees, etc.
Border Zone does it without splitting windows like that, but I think two
windows IS a good idea.
}Depending of the time scale, there might also be of interest to simplify the way
}commands are given to the game. If for instance you are hunted by a
}terrific monster of some kind, you might be easily caught up if you are
}forced to enter "run through the door" each time. So, a command palette of
}some kind with command buttons might be desireble. The game I have in mind
}is a game like that. Games with a larger timescale are likely to loose
}against the regular if-games.
I don't know about that -- games with an effective "turn" cycle of 30-45
seconds during the fastest parts won't require a command button, but could
raise tension quite a bit.
Dan Dalton
In message <58s3ma$14...@news.ccit.arizona.edu>,
jd...@nevis.u.arizona.edu (Jason B Dyer) wrote:
> Daniel Yu (dani...@autodesk.com) wrote:
> : I'm toying with the idea of writing a real-time
> : piece of IF (no, I'm not talking about Freefall),
> : but I can't decide if this sort of thing
> : detracts from a game more than it could contribute.
>
> You might be able to have the player choose between real-time
> and turn-based play from the start. That way slow typists
> don't have to panic.
>
> There would need to be some sort of conversion, like x secs=1 turn.
>
> Remember that the game must be appropriate for real-time play.
> So Far in real time just doesn't seem like a good idea. :)
>
> Jason Dyer
> jd...@u.arizona.edu
Borderzone is probably the only readily available realtime game (it
really isn't a very
good game the only neat thing about it is the realtime engine) it runs
off an internal
clock which (usually) isn't hidden and is displayed in the upper right
corner (with
your score) all npcs make an action every minute.
the stories in the game (three in all I believe) relied heavily on the
time engine
giving you less time to thing and not many puzzles to solve ( there in a
sniper in
one of the buildings and he is going to shoot the mayor in five minutes
you have to
find him and protect the mayor) neat until it starts to get in your way.
Muds have a similar engine but muds also don't have plots, or atmosphere
they have poorly written room discriptions and are loaded with rude and
inconsiderate
individuals who would like nothing more than to find a way to kill your
character
even when it's not allowed. they are as the jargon dictionary says:
"Glorified chat rooms with little or no puzzles" and a parser thats only
slightly
better then the original collossal cave adventure.
But Muds succesfuly seporate your actions with the rest of the game "the
world goes
on whether you live or die"
I say an I-F game with a real-time engine could be fun as long as the
main Idea of the game was void of the clock. for example in zork having
the thief (and only the thief) run on a real time engine may be fun (but
not in the other games whose baddies would get too annoying)having one
aspect of the game fall under the clock (like above example)
might work.
I posted something like this a month or so ago about which language
could support a real-time engine like the one in borderzone, and from
what I remember inform was
the only one mentioned in return.
I assume that this is because it runs on the Z-Machine.
Dan Dalton
<rim...@shadetree.com>
Gasp!...huff..huff..pant..WHEW!
I talk too much
Rimfire
<rim...@shadetree.com>
ummm....yeah
Ad...@beachyhd.demon.co.uk
Hi Fredrik!
FE> Daniel Yu <dani...@autodesk.com> writes:I'm toying with the idea of
FE> writing a real-timepiece of IF (no, I'm not talking about Freefall),but
FE> I can't decide if this sort of thing detracts from a game more than it
FE> could contribute.
FE> The only real-time IF I have seen is an Eamon game, the title of which I
FE> think is Sands of Mars or some-such.
[...]
The classic old text/graphics adventure The Hobbit (everyone remember that?)
was real-time in a very loose way.. What it basically meant was that if you
didn't enter anything for a few seconds, it'd perform a "wait" action for you,
which allowed the other characters to move about.
Primitive, but by just making it a little less obvious how the game was
behaving it'd look as real-time as any other adventure...
.\dam. [Team AMIGA] //\ Ad...@beachyhd.demon.co.uk \//
> Homepage at http://www.rdainfotec.demon.co.uk/adam
Daniel Yu
Matthew Russotto wrote:
>
> In article <peter.larsson-1...@modem4.lule.frontec.se> peter....@lule.frontec.se (Peter Larsson) writes:
>
> }My idea is that things should run in an even pace in the program, as opposed
> }to in discrete time-steps equal to the number of returns entered in the
> }prompt, or sub-problems solved (ie like in Christminster). That's
> }real-time, right?
> }
> }Since the player sees and learns things in another pace than he actually
> }does things, there's a need of two windows; an input window where commands
> }are entered, and an output window where feedback are presented. The idea
> }is that the output window not only presents the player with feedback to
> }his own actions, but also tells what else happens, what he sees, etc.
>
> Border Zone does it without splitting windows like that, but I think two
> windows IS a good idea.
Two windows is an interesting idea. I'll have to experiment with
this...
>
> }Depending of the time scale, there might also be of interest to simplify the way
> }commands are given to the game. If for instance you are hunted by a
> }terrific monster of some kind, you might be easily caught up if you are
> }forced to enter "run through the door" each time. So, a command palette of
> }some kind with command buttons might be desireble. The game I have in mind
> }is a game like that. Games with a larger timescale are likely to loose
> }against the regular if-games.
>
> I don't know about that -- games with an effective "turn" cycle of 30-45
> seconds during the fastest parts won't require a command button, but could
> raise tension quite a bit.
How long was a "turn" in Borderzone? ~One minute? The goal of "raising
the
tension" is what essentially drives my whole interest in this idea, but
I'm
wondering if it isn't just a bit too much of a gimmick.
Peter Larsson
In article <5903pk$h...@exodus.shadetree.com>, rim...@shadetree.com (Dan
Dalton) wrote:
>Borderzone is probably the only readily available realtime game (it
>really isn't a very good game the only neat thing about it is the realtime
>engine) it runs off an internal clock which (usually) isn't hidden and is
>displayed in the upper right corner (with your score) all npcs make an action
>every minute.
[ ... ]
So, what are you saying? Is the real-time idea a bad one?
>Muds have a similar engine but muds also don't have plots, or atmosphere
>they have poorly written room discriptions and are loaded with rude and
>inconsiderate individuals who would like nothing more than to find a way to
>kill your character even when it's not allowed. they are as the jargon
>dictionary says: "Glorified chat rooms with little or no puzzles" and a
>parser thats only slightly better then the original collossal cave adventure.
Agreed. As I said in my previous post, the i-f aura and feeling is a must,
otherwise your shoot'em-up game of choice is a better one. That's not
the future game my mind sees.
>I say an I-F game with a real-time engine could be fun as long as the
>main Idea of the game was void of the clock. for example in zork having
>the thief (and only the thief) run on a real time engine may be fun (but
>not in the other games whose baddies would get too annoying)having one
>aspect of the game fall under the clock (like above example)
>might work.
As I see it, the purpose of such a game is to be able to do stuff before
NPC characters would. That way there will always be a battle for time.
I imagine a game in a rather limited world, populated by a number of NPCs
with individual goals that either obstructs the goals of the protagonist
(was that sp right!?), or makes it totally unachievable. In that way, time
is
something to really take into account.
In article <58s70q$h...@news.multiverse.com>, russ...@ariel.ct.picker.com
(Matthew Russotto) wrote:
>In article <peter.larsson-1...@modem4.lule.frontec.se>
>peter....@lule.frontec.se (Peter Larsson) writes:
> ...
>}Depending of the time scale, there might also be of interest to simplify
>the way
>}commands are given to the game. If for instance you are hunted by a
>}terrific monster of some kind, you might be easily caught up if you are
>}forced to enter "run through the door" each time. So, a command palette of
>}some kind with command buttons might be desireble. The game I have in mind
>}is a game like that. Games with a larger timescale are likely to loose
>}against the regular if-games.
>
>I don't know about that -- games with an effective "turn" cycle of 30-45
>seconds during the fastest parts won't require a command button, but could
>raise tension quite a bit.
I think you might have a point there. One of the things to try out is, of
cource, the fastest acceptable pace. I hope to be able to do such tests,
maybe at the xmas hollidays. But I still like the idea of a "command palette";
Things that takes some time to do in reality, will in a game often requrie
some typing, wich is fair. Things that just takes an instant in real-life
requres the palette, if the conditions for real-time at that scale should
be fair as well.
The number of commands in the palette is reduced to moving about.
Unfortunataly, I haven't played BZ or any other game featuring a realtime
engine.
Phil Goetz
In article <peter.larsson-1...@modem5.lule.frontec.se>,
Peter Larsson <peter....@lule.frontec.se> wrote:
>In article <5903pk$h...@exodus.shadetree.com>, rim...@shadetree.com (Dan
>Dalton) wrote:
>
>>Muds have a similar engine but muds also don't have plots, or atmosphere
>>they have poorly written room discriptions and are loaded with rude and
>>inconsiderate individuals who would like nothing more than to find a way to
>>kill your character even when it's not allowed. they are as the jargon
>>dictionary says: "Glorified chat rooms with little or no puzzles" and a
>>parser thats only slightly better then the original collossal cave adventure.
>
>Agreed. As I said in my previous post, the i-f aura and feeling is a must,
>otherwise your shoot'em-up game of choice is a better one. That's not
>the future game my mind sees.
Disagreed. This is one future game I see. As I've said before, to really
enjoy one-player interactive fiction, of the type where the player is
co-author, you don't need just a computer smart enough to tell you a story
you enjoy. You would need a computer smart enough that you enjoy telling
it a story. Not likely anytime soon.
Remember that the best MUDs are 1) MUSHes, not MUDs, and
2) require an application before you may play. If you can log in and play
on a MUD/MUSH without going through a screening process, it's probably
not going to be a very good one.
It's true they don't have ready-made puzzles. You have to generate them
for yourselves, and they don't take the form of "puzzles", but of problems
with no known solution. It's a different paradigm, but a good one.
Phil Go...@cs.buffalo.edu
Dan Dalton
About dividing the screen,
here are a few to this tou could make it tintin++(split 21) style
or Scott Adams style (Both easy to do in inform)
you could also rig it up to where you don't need to split the screen
maybe have the screen renew itself as well as what your typing
(tintin also has a feature like this) when something wonders your area
(it would need to do this real fast so the player wouldn't notice)
Rimfire
<rim...@shadetree.com>
ummm....yeah
James Cole
Daniel Yu <dani...@autodesk.com> wrote:
>I'm toying with the idea of writing a real-time
>piece of IF (no, I'm not talking about Freefall),
>but I can't decide if this sort of thing
>detracts from a game more than it could contribute.
>The only example of this I know of is Infocom's
>"BorderZone", which, admittedly, I've never played.
>Any thoughts?
I definitely feel that a game which is not restricted to the turn based world of
'contemporary IF' could be quite good, removing the restrictions that turns
place on gameplay, such as a loss in realism and the immersement of the player
in the game. I also realise that there are many problems with real time games,
both in implementation and playing. Aside from the technical difficulties, I
believe the greatest inherent difficulty in realtime IF is actually in playing
the games. The most prominent problems beings (as mentioned by others); not
everyone types or thinks at the same speeds. (I also find that I get anxious
when playing real time IF games - knowing that the clock is always ticking)
Thus for many people playing becomes an exercise in trying to type fast. I
feel that these problems themselves are reasons enough for realtime IF, in its
current form, not to be viable.
But I think there is a solution - a middle ground. A mixture of turn based and
real time game play. The advantages of real time play are more realism and
therefore a deeper sense of involvement in the game. The advantages of turn
based play are that the player can take their time to think and type (if
necessary), and the game is simpler to both play and code (I assume it is). The
downside to turn based games it that (usually) everything that occurs in the
game 'world' takes the same amount of time: looking at a sign, walking across a
bridge, a bird flying down to eat a bit of bread, etc. This has always made IF
games feel somewhat artificial to me. What if actions and events were allotted
different (but descrete) lengths? The game could still be turn based - and thus
would give you as much time as you needed to type, think, etc. - but at the same
time represent a richer more realistic and natural view of your world.
To illustrate, here is an example: Say you are trying to sneak into the main
building of a computer research center. There is a security guard who patrols
around the building. In a standard game, the guard might patrol around each of
the building's 4 sides, staying at each one for 3 turns. Each action you take,
whether it be reading the password for the safe that you have, looking around,
cutting through the fence with wire cutters, etc., takes the same period of
time. After each turn, the results of your action, and the changes of things in
your environment, are displayed on the screen. (Something I've always felt was
really artificial feeling, especially for NPCs) Like what the birds nesting near
be are doing, etc. A sample transcript might be as such:
> look
In front of you is the building, there seems to be a door at the front. In
between you and the building lies a fence. Near the edge of the roof of the
building lies a group of nesting birds.
The guard patrols in front of the building.
The birds do nothing.
> read piece of paper
The piece of paper has the string 'Beln8o#' scrawled on it.
The guard leaves around the left corner of the front of the building.
A bird flys in to the group of nests, quickly settling in.
> cut wire with wire cutters
You manage to cut through the fence with the cutters, leaving a nice hole in the
fence large enough for you to crawl through.
A bird gets out of the nest and flys out into the darkness.
Now consider a real time/turn based hybrid version of this. The guard might
patrol around, moving to the next side, every 8 time units. It might take you
only 1 time unit to read the safe's password and 2 time units to look around,
whilst taking 10 time units to cut through the wire fence. Each of these
actions would count as a turn. In each 'turn' all daemons and fuses (in TADS
lingo), i.e. the security guard and the birds, would have their turn counters
decremented by the length of the action. That is, an amount of time (the length
of your action) will have occurred in the game world.
A sample transcript might be as such:
> look
In front of you is the building, there seems to be a door at the front. In
between you and the building lies a fence. Near the edge of the roof of the
building lies a group of nesting birds.
The guard patrols in front of the building.
The birds do nothing.
> read piece of paper
The piece of paper has the string 'Beln8o#' scrawled on it.
As you're reading the peice of paper, a bird flys in to the group of nests,
quickly settling in.
The guard patrols in front of the building.
> cut wire with wire cutters
You manage to cut through the fence with the cutters, leaving a nice hole in the
fence large enough for you to crawl through.
As you cut the wire with the cutters: some of the birds cause a bit of
comotion in the nest. A bird gets out of the nest and flys out into the
darkness. The guard leaves around the left corner of the front of the building.
(I know this is a terrible example, but I couldn't think of anything better.
But think of the possiblities. I would be particularly interested if people can
come up with transcripts which could 'prove' or 'disprove' the viablity of real
time/turn based system)
This system causes some complications. Another object may do something `part of
the way through' one of your actions, or do something multiple times in the
timespace of one of your actions. These might cause some problems (That I'm
sure could be overcome), and the (a standard) parser might need some
modifications to make sure these messages are worded correctly. But they would
also make the game feel much more natural.
I've also tried to think (I admit not really hard - brain to lazy) of situations
that would not work, or would do 'funny things', using this system. One
interesting result of using a hyrbrid real time/ turn based system would be that
you couldn't just type Z, or wait, you would have to say how long (or time
units) you want to wait. Or maybe 'Z' would just wait the smallest time period.
This could introduce some special circumstances that would need to be handled by
the game system accordingly: if a 'critical' event (such as an explosion, or
someone going up to you and saying something to you) occured whilst you were in
the middle of a 'wait', the same goes for in the middle of a command (such as
whilst in the middle of searching through a haystack). I can't think of any
more. (This is left as an exercise for the reader :-) )
For this to work I think that it would have to be kept simple. This simplicity
is a big advantage in coding turn based games - and I guess, the reason why
games were originally done this way. If too many specific times were used, say
1.5 seconds for reading one note, but 2.5 seconds to read a slightly longer one,
etc., it would become to complex and hard to manage. The game should not try to
be too much of a simulation. Therefore I would recommend that only a small set
of action time lengths be used (except for exceptional circumstances), for
example things that occurr in the game world could range in length from 1 time
unit for small tasks like looking at a password you have, to twenty for quite
long tasks, like searching through a haystack. Of course these are only
examples, and guidelines - I think it would be good if every one in the IF
community could agree on a standard for time lengths to be used in games of this
type.
Assuming that the system would work, an important question arises - how would
this be implemented? I guess that you should (I'm having trouble thinking at
the moment, could it?) be able to, without too much trouble (modification of
parser and libraries), implement a system such as this in a 'standard' language
such as Tads or Inform.
Obviously this would introduce more complexity into designing and coding a game,
But I think, correctly done, this would not have much effect.
( As a side issue, I think the notion of real time IF games (in there current
form) aren't really 'true' real time games. For example, I don't actually
consider BorderZone to be true 'real time', this is because of the inclusion of
a pause feature. (This goes for any real time IF game which includes a pause
feature) A pause feature is something which a real-time IF game needs; you
might need to leave the computer for a period of time - but it also allows you
to stop the game to think - thus destroying the real-time effect. Depending on
the will (or want) of the player, if he/she takes advantage of this - as I admit
I do - then they are turning the game into a tedious pause/unpause task of
trying to type fast to beat the clock.)
-------------
Copyright (C) James Cole
jrc...@ozemail.com.au
Will Grzanich
In article <32B8F7E9.51E0@-.->, -@-.- says...
>
>With a real-time IF game, it would be annoying to be half way through
>typing something, and then have a whole lot of text appear, cutting what
>you were writing in half. I've had a look at a MUD recently, and this
>happened once or twice.
>
>Possibly (with Inform) you could have commands typed in a seperate
>window at the bottom of the screen, and then printed into the game text
>when you press enter.
>
>Nicholas Daley
><mailto:dal...@ihug.co.nz>
Yep...that's why a decent MUD client is essential for MUDding (if anyone
here cares, I recommend AVPlay). But, back to the thread...
I also think it'd be annoying to be, say, cutting through a
fence, and to be told that, while I was busy snipping and clipping, an
evil werebear had sneaked up behind me and calmly devoured me (assuming I
wasn't given fair warning, of course).
Take care.
-Will
--
"All you need is love."
-John Lennon
Jonathan D Blask
I'd just like to defend Border Zone, the real-time game that some
have criticized. I DID find the game near-impossible; I had to use the
hint system often (maybe keener minds didn't), but I was still impressed
by the thinking that went into the plot and the puzzles. If a sequel
ever came out (like I think the game might have said), I probably
wouldn't pay too much for it, but I'd get it, if it were cheap enough.
Speaking of sequels, though, does anyone know if Activision will
ever release a sequel to Journey (like they did to the Zork series and
are doing to the Planetfall series)? Journey was supposed to be the
first part of a trilogy and I had SO much fun playing it...
jon
-
Kenneth Albanowski
In article <59b2ga$q...@reader1.reader.news.ozemail.net>,
James Cole <jrc...@ozemail.com.au> wrote:
>
>Now consider a real time/turn based hybrid version of this. The guard might
>patrol around, moving to the next side, every 8 time units. It might take you
>only 1 time unit to read the safe's password and 2 time units to look around,
>whilst taking 10 time units to cut through the wire fence.
Interesting. The other side of this occurred to me the other day playing
through Tapestry. The prologue is purely dialogue, but with you getting a
turn after anyone says something.
After a while, you just start hitting "z" after someone says something to
move the conversation along. The problem is that in standard Inform fashion,
the response to "wait" is "Time passes.". The result is extremely disjointed:
> examine woman
She is a woman.
The woman says "And so, as I was telling you, you are on a noble quest".
> wait
Time passes.
The woman says "and once you have gotten the mystic kumquat, bla bla bla".
The question here is how much time actually passes. It's not necessarily
inaccurate, as seconds or hours could equally have been passed. But
semantically it really means "wait till someone says something", and at the
least the response for wait should have been "You wait for someone to say
something" instead of "Time passes".
So if you allow player actions to take variable amounts of time (which seems
emminently sensible, if non-traditional) then you need to decide what sort
of units "wait" works in. Simplest would be to allow a number, so that
"wait" is the equivalent of "wait one turn", while also allowing "wait 25
turns".
The next level would be to integrate "wait" with the player interaction, so
that things like "wait till something makes a noise" become possible,
although obviously the game engine needs very high levels of information
about what is actually going on so as to distinguish a guard moving from a
bird twittering to a woman speaking.
>( As a side issue, I think the notion of real time IF games (in there current
>form) aren't really 'true' real time games. For example, I don't actually
>consider BorderZone to be true 'real time', this is because of the inclusion of
>a pause feature. (This goes for any real time IF game which includes a pause
>feature) A pause feature is something which a real-time IF game needs; you
>might need to leave the computer for a period of time - but it also allows you
>to stop the game to think - thus destroying the real-time effect. Depending on
>the will (or want) of the player, if he/she takes advantage of this - as I admit
>I do - then they are turning the game into a tedious pause/unpause task of
>trying to type fast to beat the clock.)
And thus the game becomes a typing tutor instead of IF. Definitely not a
wise approach.
--
Kenneth Albanowski (kja...@kjahds.com)
Dan Dalton
In message <32B8F7E9.51E0@-.->, - <-@-.-> wrote:
> With a real-time IF game, it would be annoying to be half way through
> typing something, and then have a whole lot of text appear, cutting what
> you were writing in half. I've had a look at a MUD recently, and this
> happened once or twice.
>
> Possibly (with Inform) you could have commands typed in a separate
> window at the bottom of the screen, and then printed into the game text
> when you press enter.
>
> Nicholas Daley
> <mailto:dal...@ihug.co.nz>
Actually there is a program called tintin
for playing muds with (a telnet program) and it has two ways to handle this
one is split 21 which splits the screen in two the bottom screen is for
typing in
commands the top part of the screen is for viewing the content.
second is the redraw command which doesn't split the screen but redraws
it (even what
your typing) when something new appears on screen so you don't have to
worry about
your commands getting cut in two.
either would work in IF
Rimfire
<rim...@shadetree.com>
ummm....yeah
Chuan-Tze Teo
Kenneth Albanowski wrote:
> After a while, you just start hitting "z" after someone says something to
> move the conversation along. The problem is that in standard Inform fashion,
> the response to "wait" is "Time passes.". The result is extremely
> disjointed:
It would be nice if in a situation where the player is sitting around being
lectured at or watching events unfold with nothing constructive to do, the
command WAIT could quietly make a turn go by each turn without printing any
"time passes" messages until the NPC finishes its spiel. An advantage to this
is that less screen space is taken up with irrelevant clutter, and the player
isn't typing Z all the time.
> The next level would be to integrate "wait" with the player interaction, so
> that things like "wait till something makes a noise" become possible,
> although obviously the game engine needs very high levels of information
> about what is actually going on so as to distinguish a guard moving from a
> bird twittering to a woman speaking.
WAIT UNTIL SOMETHING MAKES A NOISE seems unreasonable in terms of programming
effort required. WAIT UNTIL SOMETHING INTERESTING HAPPENS (i.e. a daemon
generates a message) could be more feasible. If nothing interesting happened
after 10 turns then control would be returned to the player with "A long time
passes." WAIT UNTIL A CERTAIN TIME has been done usefully.
- Chuan
Francis Irving
On 20 Dec 1996 14:01:41 -0500, kja...@kjahds.com (Kenneth Albanowski)
wrote:
>
>The next level would be to integrate "wait" with the player interaction, so
>that things like "wait till something makes a noise" become possible,
>although obviously the game engine needs very high levels of information
>about what is actually going on so as to distinguish a guard moving from a
>bird twittering to a woman speaking.
>
A semi-MUD like IF game that I wrote once allowed "wait for" which
would wait for anything to happen, or "wait for Austin" which would
hang around until Austin showed up.
(A running turn count, and an escape key, stopped you waiting forever)
Francis.