IF devtool wanted for Roguelike game
Sean T Barrett
Nathan Jerpe <nathan...@ncr.com> wrote:
>I am looking for some sort of tool or utility to assist in managing the
>development of a nonlinear plot. I would like to be able to organize
>events, citizens, and locations in such a manner that I don't inadvertently
>build paradoxes into the story. I want to be sure that I haven't assumed
>the player knows too much when they encounter a new puzzle. I'm sure these
>are typical considerations that IF authors worry about.
When I spent a few days in Boston interviewing at LookingGlass
Technologies, sometime after the release of Ultima Underworld II,
I posed basically this question to one of the programmers there
(one who, in fact, reads r.g.i-f and r.a.i-f these days).
How, I asked, do you keep track of all of these events and the
interdependencies, so that you can make sure you won't have plot
bugs where if you do something out of order, the plot sequence
gets blocked? Do you have some sort of visual tool or scripting
system where you code in the description of the events, and the
program searches exhaustively for plot paths that get stuck? Or
do you better yet read it out of the actual game itself--the level
data and the conversation scripts?
He replied that, while that might make sense and be a good idea,
they did not in fact do anything like that at all; they just did
it all by hand and tried not to mess things up.
As far as I know, no IF authoring systems provide any facility
to do something like this either--at least for 'something like
this' being automatic detection of unwinnable/blocked paths.
Part of this is because it's hard--if the IF scripting language
(or the conversation scripting language in the case of UW) is
Turing-complete, you have a sort-of halting-problem kind of
scenario, although in general you can probably sneak past that.
In the case of something like UW, you'd have to hand-input the
physical-geography restrictions since it would be too hard to
infer from the map (what jumps can you make? what jumps can you
make if you've found the ring of leaping?), and anything you
hand-input would be susceptible to bugginess.
But part of this is just because the perceived gain isn't that
great; just drawing the event chains out on a graph on paper is
usually sufficient for most games, as far as I understand it.
The problem/danger here is the interaction between events that
are chartable as paths on a graph, and state changes which happen
"independently" of that path; tracking those interrelations and
making sure things behave consistently. I think with most IF
so much of the problem is represented as state instead of as
a graph that there's little applicability for a graph-oriented
tool, and proving stuff about state is more the realm of those
code-proving tools that result in productivity of 2 lines of code
a day.
SeanB
Dan Schmidt
| When I spent a few days in Boston interviewing at LookingGlass
| Technologies, sometime after the release of Ultima Underworld II,
| I posed basically this question to one of the programmers there
| (one who, in fact, reads r.g.i-f and r.a.i-f these days).
|
| How, I asked, do you keep track of all of these events and the
| interdependencies, so that you can make sure you won't have plot
| bugs where if you do something out of order, the plot sequence
| gets blocked? Do you have some sort of visual tool or scripting
| system where you code in the description of the events, and the
| program searches exhaustively for plot paths that get stuck? Or
| do you better yet read it out of the actual game itself--the level
| data and the conversation scripts?
|
| He replied that, while that might make sense and be a good idea,
| they did not in fact do anything like that at all; they just did
| it all by hand and tried not to mess things up.
And in fact, as I'm sure Sean remembers, we did mess things up; there
was a nasty plot bug in Ultima Underworld II (the 'servant strike bug'
that could prevent you from winning the game. So if there had been
some sort of automated system, it would have been useful.
I don't remember at this point whether the servant strike bug was due
to bad logic (i.e., a problem that could have been detected through
some independent 'plot sketching' tool) or just to a bug in the
implementation (in which case we really would have needed something
that automatically took our conversation code and some knowledge about
the rest of the game and could detect problems with it, which is
nigh-impossible).
Andrew Plotkin
> (Followups redirected from r.g.i-f to r.a.i-f)
> As far as I know, no IF authoring systems provide any facility
> to do something like this either--at least for 'something like
> this' being automatic detection of unwinnable/blocked paths.
> Part of this is because it's hard--if the IF scripting language
> (or the conversation scripting language in the case of UW) is
> Turing-complete, you have a sort-of halting-problem kind of
> scenario, although in general you can probably sneak past that.
> In the case of something like UW, you'd have to hand-input the
> physical-geography restrictions since it would be too hard to
> infer from the map (what jumps can you make? what jumps can you
> make if you've found the ring of leaping?), and anything you
> hand-input would be susceptible to bugginess.
> But part of this is just because the perceived gain isn't that
> great; just drawing the event chains out on a graph on paper is
> usually sufficient for most games, as far as I understand it.
And in cases where the event chains are more complicated, the
hand-input restrictions are practically certain to be buggy, because
if you understood them well enough to hand-code them you wouldn't be
making mistakes in the first place.
It's the same as any other programming correctness task. In theory,
everyone writes formal specifications and then proves their code
correct. In reality, everyone makes some simple assertions, ensures
the high-level assertions are correct, and then is careful not to
violate them in lower levels. Add more levels if you like.
> The problem/danger here is the interaction between events that
> are chartable as paths on a graph, and state changes which happen
> "independently" of that path; tracking those interrelations and
> making sure things behave consistently.
If there are really interactions, you need to square the number of
nodes in the graph -- cover every combination of possibilities. Of
course, this is where you realize that the graph is as confusing as
the original problem.
I *did* draw a graph for _Shade_. Well, a list of nodes with the
preconditions of each. It wasn't very complicated. I found it helpful
to add debugging verbs that actually listed the "completed", "open",
and "unstarted" nodes within the game itself.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Sean T Barrett
>I don't remember at this point whether the servant strike bug was due
>to bad logic (i.e., a problem that could have been detected through
>some independent 'plot sketching' tool) or just to a bug in the
>implementation (in which case we really would have needed something
>that automatically took our conversation code and some knowledge about
>the rest of the game and could detect problems with it, which is
>nigh-impossible).
I was led to understand that the servant strike bug was
actually a bug within a single conversation; UW conversations
generally allowed you to repeat them so you could come back
and get information you'd forgotten, or even come back and
try different avenues. Oftentimes you could do this without
leaving a conversation--just cycle back to the main list of
topics and run through them again.
My recollection was that there was a problem with talking to
Lord British, getting a particular speech from him, then cycling
back around and getting the same speech again (or maybe it
was an alternative choice from the same menu)?
This puts me in a mind to think about dataflow technology for
compilers, which can determine properties of loops like
constants in the loops, variables which are guaranteed to
be set in the loop, detect induction variables, etc. I can
imagine a tool which you feed it some assertions, and it
validates that there is no path through the graph (including
loops) that violates the assertions (or perhaps reports if
it isn't smart enough to determine it). While this wouldn't
have solved the whole problem--and would require people to
write good assertions, and I don't know enough about this
scenario to know whether it was something one might catch
with an assertion--it seems an interesting level to tackle
(although most likely not for the roguelike-with-plot that
began this discussion).
SeanB
Gerry Quinn
Maybe for a Roguelike it would be sufficient to abstract everything as
locks and keys; proof of solvability can then be reduced to a recursive
maze.
A 'key' would be a notional item that can't be dropped, and which is
given as the reward of a quest. It opens a particular door. Several
keys may open one door. A key can be a physical item (good for
debugging?) or not. Likewise, a lock can be a monster who wants a key,
which is an item, or the fact that something has happened.
Just thinking aloud - I haven't implemented this in any serious way.
Gerry Quinn
--
http://bindweed.com
Entertainment software for Windows
Puzzles, Strategy Games, Kaleidoscope Screensaver
Download evaluation versions free - no time limits