IFReviewed by
Emily Short on 2006-08-01 04:46

[Side comment not actually about the game: I wish T3 weren't such a moving
target. I already had a couple of different HyperTADS versions on my machine to
handle older T3 games, but still had to ask Iain Merrick to compile me a new
version (thanks again, Iain!). It's a pity: this kind of thing makes players
less likely to play T3 games at all because they get tired of downloading new
versions of the interpreter. I look forward to the time when there are more T3
games out there and the platform is stabilized. For now, kudos to the authors
brave enough to experiment with it anyway.]
It's obvious that a lot of work went into "The Battle of Walcot Keep": it lists
three authors and an illustrator, and one of the first commands I tried was
"show map", which brought up a nice professionally-drawn schematic with little
sketches of the buildings in question. Pretty classy.
Another point in its favor (from my point of view, anyway) is that it's taking
place in a specific historical setting, a battle between the forces of Stephen
and Matilda.
Then I wander into the midst of the battle itself. Good golly. It takes a long
time to process a command -- sometimes fifteen to twenty seconds by my count,
sometimes so long that I think the interpreter's hung. It may be that this runs
faster under Windows than under HyperTADS 1.3.8 in Classic mode on a Mac, but
it's obvious that a lot of processing is going on in the background, and not
very efficiently. If it's this slow on my machine, I hate to think what it'll
look like on older OSes.
When the game does continue, there's a page of output: it appears that every
archer and swordsman has his own daemon, and they're all busily doing their own
thing. Each action is described on its own line. It's impressive, in a way; it's
also totally bewildering. So much is going on that it's hard to get a good sense
of the action in total: which side is winning? who's going where? Much of the
time I have no idea. And sometimes the actions described are very repetitive and
seemingly insignificant. For instance, a page of output includes a paragraph of
this:
"A sturdy rebel man-at-arms cannot reach a thin royalist man-at-arms. A sturdy
rebel man-at-arms cannot reach a thin royalist man-at-arms. A ruddy-faced rebel
man-at-arms cannot reach a thin royalist man-at-arms. A pale rebel archer cannot
reach a thin royalist man-at-arms."
This kind of thing, in my opinion, is a tipoff that you need to consolidate your
prose generation ("A group of rebels shake their fists angrily at the royalists,
who are out of their reach.") or else that you should give up on IF and write a
real-time game with graphics.
To make matters worse, important bits of conversation by major NPCs are mingled
indifferently with all the lines about archers, arrows, and swords. These are
more critical parts of the narrative, so they really ought to be presented in a
way that draws attention.
Meanwhile, attempts to interfere in the action prompt responses like this:
> take sword Which sword do you mean, the sword, the sword, the sword, the
sword, the sword, the sword, the sword, the sword, the sword, the sword, or the
sword?
It quickly becomes obvious that, since I'm dead, I'm not allowed to touch
anything or do anything other than watch. Very well. I proceed into some of the
other areas of the game, where there is less turmoil, and things go a bit
better. In a lot of respects this still doesn't feel like an art show piece to
me: there's a fair amount of unimplemented scenery. There's some interesting
stuff there, but this is an Event piece, and I have the strong impression that
the authors want me to hang out and watch the battle.
Then it ends with no warning. I assume something happened with the NPCs that
caused this, or that we were on a timer, or something, but there was no
conclusion to the narrative. I was wandering around and then suddenly I was
offered the RESTART/RESTORE/CREDITS/QUIT prompt. (It doesn't even say "*** The
battle is over ***" or "*** The keep has fallen ***" or anything like that.)
My impression (given what is said in the credits) is that this piece uses the
Reactive Agent Planner -- the best AI module currently available to IF authors
-- to create dozens of NPCs who are constantly choosing new paths of action each
turn: opening and closing doors, wielding weapons, moving around, attacking each
other, dying and becoming deactivated. No wonder it takes so long to process a
command.
But this isn't the best demo of the possibilities. What's great about RAP is
that the NPCs reassess their situation each turn: if you move an object they
need, say, they'll adjust their plans to include a step to go get it. If the
player isn't allowed to introduce any variation in the scenario, then the author
might as well have hard-coded the whole action sequence from the outset: all the
planning is going to happen according to a predetermined chain. (Maybe there's a
randomizing element in the combat module such that individual NPCs might succeed
or fail in their attacks differently at different times, but it really doesn't
matter: from the player's point of view the intelligence of all these creations
is not really appreciable.)
RAP-driven combative NPCs are a cool idea as long as the player can interact
with them and there are only a few around at a time. Once you get this kind of
mass action going on, it may be a better idea to model the simulation at a
higher level, planning and describing the actions of whole groups of soldiers at
once.
I've played around with RAP a fair amount myself; one reason that I've never
released a game using it is that I ran into trouble with the exact things that
are issues in "Battle": slow processing and the generation of dull, repetitive,
or unidiomatic prose. The former problem can be a little alleviated by being
less ambitious about the number of NPCs, but the latter problem is hard. I think
the solution probably involves representing all the actions that are going to
occur in a given turn as data, then running some algorithms on that data to
discard anything too ineffective to be worth reporting, cluster related actions
together into compound sentences and related sentences into paragraphs,
introduce variations of phrasing, etc. Which would be a massive undertaking to
write, frankly, even after you have a fully functional set of RAP routines for
your NPCs. I don't want to sound discouraging because I think that, if this were
done *successfully*, the results would be mindblowing, and I hope the authors of
"Battle" will continue to work on this problem.
"Battle of Walcot Keep" is also probably the first major effort at IF drama
where all the action is done by the NPCs and the player's main job is to choose
a point of view -- like those experimental plays that take place in multiple
locations and the audience members can wander around following whatever
storyline they like. It's an interesting idea, but I don't think "Battle" makes
the experiment work: there's too much focus on simulation and too little on
narrative structure and dramatic tension. Case in point: the totally unexpected
ending.
So my verdict is that this is inventive, ambitious, and shows a great deal of
work with some promising tools, but that it doesn't really gel.
Still, I appreciated the Latin and the cheddar.
Honorable Mention on the 2004 IF Art Show.