Fate is being kind to me. Fate doesn't want me to be too famous too young.
Duke Ellington

Login | Register


Who is Online

We have 703 registered Members.

There are no Members online.

There is 1 Guest online.

0 Stars IFReview Rating The Battle of Walcot Keep

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

Game Profile

Eric Eve, Lindsey Hair, Michael Bechard and Steve Breslin


Authoring System

Release Year

[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.

The Battle of Walcot Keep Awards

    Honorable Mention on the 2004 IF Art Show.

Emily Short Profile

IFReviewer Rating
10 Stars IFReviewer Overall Rating

Name Emily Short
Gender Female