Newsgroups: rec.games.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!howland.erols.net!portc.blue.aol.com.MISMATCH!portc01.blue.aol.com!uunet!dca.uu.net!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: Walkthrough comp: reviews/critiques (long)
Message-ID: <GDw9C0.8H2@world.std.com>
Date: Fri, 25 May 2001 13:55:12 GMT
References: <GDv88M.GI@world.std.com> <9elhot$v8q$1@newsg4.svr.pol.co.uk>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 52
Xref: news.duke.edu rec.games.int-fiction:63307

Gunther Schmidl <gschmidl@gmx.at> wrote:
>That said, I'd be interested to see how a game with split narrative[*] would
>be accepted by the audience.
>
>[*] For lack of a better term. What I mean here is:
>
>| You can make out something glittering coming at you full speed--
>|
>| >DUCK
>| -- and duck just in time to avoid being cut to pieces.

Reading it, it has a really nice sense of continuous motion,
which gives a sense of being "real time" despite being turn-based.
However, it relies an awful lot on leading; I think a real play-through
would result in it being too split:

| You can make out something glittering coming at you full speed--
|
| >X GLITTERING
| -- hard for you make out in the gloom, but the dimness seems no
| problem for it to slice your head off.
|
|    *** You have died ***
|
| Do you want to RESTORE, QUIT, UNDO, or GRIPE at the author?
| >UNDO
|
| Smooth passage
|
| >DUCK
| -- and duck just in time to avoid being cut to pieces.

Of course, with work you could make that "Smooth passage" reprint
"You can make out something glittering coming at you full speed--"
[this is one of those sections where a transcript cheats by
leaving out room descriptions so it's hard to say what's going on].

But in the general case--if such an event were on a fuse or daemon
in an existing room--you'd be pretty stuck by the fact that 'UNDO'
doesn't replay the previous turn, so timed messages would not get
reprinted. If a terp supports multiple undo, you could actually
change this, by saving undo's after the command runs but before fuses;
but then you're missing narrative in response to the player command,
which suggests making undo jump all the way back to just *after* the
last command; but that would be tedious after cutscenes etc. The best
solution might be to print messages-that-should-be-redisplayed-after-undo
through a special function that saves them away somewhere, and change
the UNDO code to just go print that little queue.

But that all seems like an awful lot of work.

SeanB
