kliffy/timemachine.xml
2011-03-03 22:42:38 -08:00

174 lines
8.6 KiB
XML

<story title="Richard and Larry Build A Time Machine" author="Jeremy Penner">
<loadmodule url="retrochronal.js" />
<section name="start">
<nev name="start">
<p>"I still can't believe you actually used a [DeLorean]," says Larry.</p>
<p>"Hey, if you're going to do a thing, you ought to do it right," says [Richard].</p>
</nev>
<word name="DeLorean">
<verb name="Examine">
Larry looks at the [DeLorean] with astonishment. [Richard] has done it up to look <i>exactly</i> like the car from
<i>Back to the Future</i>.
</verb>
<verb name="Drive">
<p>Larry eyes the [DeLorean car]. "Give me the keys," he says. "I want to take this baby to 88."</p>
<p>"Oh, it doesn't drive anymore," says [Richard]. "I had to use the engine to power the time machine."</p>
</verb>
</word>
<word name="Richard">
<verb name="how" display='Ask to explain'>
<p>"So, run it by me again," says Larry.</p>
<p>"I modified this [DeLorean] to send information backwards through time," says [Richard].</p>
<p>"Just information. Not matter."</p>
<p>"Right."</p>
<p>Larry ponders this for a moment. "How... how does that even work?"</p>
<p>[Richard] waves his hands around. "Spooky action at a distance," he says.</p>
<p>"No, I mean, augh. I mean, what can you practically change about the past with this machine?" says Larry.</p>
<p>
"Well, so far I've gotten my computer to crash five minutes before I push this [button]," says [Richard],
gesturing at one of the controls inside the [DeLorean].
</p>
</verb>
</word>
<word name="button">
<verb name="Push" nextsection="next">
<p>Larry reaches for the button and gives it a push.</p>
<p>"Nothing happened", says Larry, looking at the [computer].</p>
<p>"I <i>told</i> you you were going to push it," says [Richard].</p>
<p>Larry opens his mouth to say something, then seems to think better of it.</p>
</verb>
</word>
<pastresponse after="start" future_cause="button.Push" name="crash">
<p>There is a beep as [Richard Richard's] [computer] spontaneously and inexplicably reboots.</p>
<p>"Aw, geez, you're going to push the button, aren't you?", whines [Richard].</p>
<p>"What? What button?" asks Larry, puzzled.</p>
<p>"Never mind," says [Richard].</p>
</pastresponse>
</section>
<section name="next">
<nev name="start">
<set var="number">null</set>
<set var="fInRoom">false</set>
<set var="fBeenInRoom">false</set>
<donext nev="realstart"/>
</nev>
<nev name="realstart">
<p>"So I just write down the number I see on the screen?" says Larry.</p>
<p>"Yep," says Richard.</p>
<p>"And what does this tell us, exactly?" says Larry.</p>
<p>"Well, when you come out of the [room], I'm going to type the number you give me into the computer, which
will make it show up on the screen before you wrote it down," says Richard.</p>
<p>"And what does this tell us, exactly?" says Larry again, exasperated.</p>
<p>"A number that neither of us picked," says Richard.</p>
</nev>
<word name="room">
<verb name="Enter">
<cond>!fInRoom</cond>
<cond>!fBeenInRoom</cond>
<set var="fInRoom">true</set>
<set var="fBeenInRoom">true</set>
<p>Larry sighs and opens the door. Inside the [room] is a computer [screen].</p>
</verb>
<verb name="Leave">
<cond>fInRoom</cond>
<set var="fInRoom">false</set>
Larry goes back into the lab. [Richard] looks at him expectantly. "Well?" he asks.
</verb>
</word>
<word name="screen">
<verb name="Read">
<cond>fInRoom</cond>
$[if (number === null) {]
<p>
Larry looks at the screen. It's blank. "Well, hell," he says, feebly scanning the [room]
for another, hidden screen that might have a number on it. He doesn't find one.
</p>
$[} else {]
<p>
Larry looks at the screen. The number $(number) is displayed on it.
</p>
$[}]
<p>He looks down at his piece of [paper] for a moment.</p>
</verb>
</word>
<pastresponse after="start" future_cause="paper.write">
<set var="number">6</set>
</pastresponse>
<word name="paper">
<verb name="write" display="Write down number">
<cond>fInRoom</cond>
$[if (false) {]
<p>
Larry is at a loss for a moment, but then decides that the thing to do is to just write down a number.
He chooses six.
</p>
$[} else {]
<p>"Huh," says Larry, scrawling down a large number $(number) on his paper. "Wonder what that means."</p>
$[}]
<donext nev="room.Leave"/>
</verb>
</word>
<word name="Richard">
<verb name="give" display="Give paper" nextsection="notes">
<cond>fBeenInRoom</cond>
$[if (number === null) {]
<p>Larry shows Richard the blank piece of paper. "Nothing on the screen," he says.</p>
<p>
Richard slaps himself on the forehead. "Of course! I can't believe I didn't think of that. If you
don't show me a number, I won't type it in, which means you won't see a number, which means no paradox.
Duh. How stupid of me. Forget I even asked."
</p>
$[} else {]
<p>Larry holds up the piece of paper. "It said $(number)".</p>
<p>Richard looks quizzically at the paper. "$(number)? Are you sure?"</p>
<p>A look of alarm crosses Larry's face. "Is... is $(number) bad?"</p>
<p>"No, no, it's just I would have expected something, I don't know, more random, or meaningful, I guess,"
says Richard. "You didn't just make up some number?"</p>
<p>"Of course not!" says Larry, offended. "Go ahead and look for yourself. The screen says $(number)."</p>
<p>"No, no, I believe you," says Richard, and types a $(number) into his computer.</p>
$[}]
</verb>
</word>
</section>
<section name="notes">
<nev name="start">
<h2>Author's Notes</h2>
<p>
Hi there. That's all I've got for now. Here's some thoughts about what I'm trying to accomplish.
</p>
<p>
There are two ideas at play in this prototype. The first is that it might be interesting to see what
happens when we get rid of the parser, and simply give the player the ability to know what she is capable of
doing at any particular moment in the game. I don't see any reason why we can't create rich and interesting
worlds by doing so. What appeals to me about this idea is not just the simpler interaction from the user's
perspective, but the ability to have greater control of what the author has to model -- if something is not
important to your game, you simply don't present the option to the player. Conversely, if an interaction is
subtle or non-standard, you don't need to worry about teaching the player what the parser understands -- the
verb is there. Your job is to make it interesting.
</p>
<p>
The second is to allow the player to interact with the story at any point that he has uncovered. Quite
frankly, I am really uncomfortable making big decisions in most games. But a game should be the perfect
place to make big decisions and explore the consequences!
What bothers me is not that the consequences are unknown, but that my actions are irrevocable; that if I do
something that I later understand was foolish, I am unlikely to be given a chance to redeem myself without
playing through the game again. Always showing the player the entire story and allowing him to make changes
at any point is a promise that he will never be punished for trying something, even if his character
is; that he can learn from mistakes and move on. In this way, I can construct much harsher situations than may
ordinarily be considered "fair"; I can do away with repetition of description and dialogue "just in case" the
player forgets the vital information contained within; I can allow the player to dig himself into a hole, because
I can give him the tools to quickly dig himself out.
</p>
<p>
I guess there's the time travel bit, too. I don't advise trying it, personally; building a model of the world
in code where causality can occasionally be violated turned out to be much more difficult and time-consuming
than I expected. I have no explaination for why I would have thought coding time travel paradoxes would be easy.
</p>
<p>
I would love to hear any and all feedback about your experience playing this game. I can be reached
at jeremy dot penner at gmail dot com. Thanks for playing.
</p>
</nev>
</section>
</story>