I won’t be able to make the TheoryClub ParserComp discussion, alas, but I wanted to make kind of an advance contribution to it about my entry. It’s not really going to be organized enough to be a post-mortem, but hopefully it’ll be of some interest.
My entry is Terminator, not Terminator Chaser, which brings me to the first lesson:
There is a good chance someone else will think of the same joke as you. Oh well.
This was unapologetically a tech demo entered into a competition, though I did try to make it as much of a playable game as I could. Entering tech demos into competitions is frowned upon, but without the competition I’d never have got the impetus to put this together… and I hope it was worth the tech demo, and also that some people enjoyed playing it.
There were actually two techs being tried out here–the commands to multiple actors and the grid-based movement. When ParserComp was announced, I thought I should try to do something that needed to be done with a parser rather than hyperlinks without requiring too much guess-the-verb, and Daniel Stelzer’s Multiple Actors extension seemed like a good fit–I could keep the verb set under control and use the parser to give lots of ways of specifying the actor. I had envisioned some sort of cooperative heist, but couldn’t really figure out a way to make that go with the sunrise theme. Commanding a team of astronauts to scramble back to a ship from an encroaching sunrise seemed like a match, and also would let me try out the grid-based navigation and movement that I’d been meaning to work on. Plus if I set everything on a relatively featureless planetary surface it would cut down on the amount of text description I’d need to generate.
Before long I switched to robots rather than astronauts as the ones to command, because it would have gotten impossible to control if the actors could do complicated stuff–and it would also have gotten impossible to convey the command syntax to the players. And I wasn’t going to have enough time to come up with descriptions that went much beyond the robotic. I’d have liked to include more ways for systems to interact–the initial plan involved lots of different types of robots, possibly creating rockslides and digging and things like that–but pretty quickly I had to decide only to bite stuff off as I was able to chew it, as it were. So I wound up with a pretty simple gameplay; the astronauts were treasures scattered around the grid, the robots had to find them and bring them back. The division between scouts and haulers stayed, though, because it seemed like it could create a nice two-stage dynamic where first you explored to find the astronauts (most likely with the scouts) and then you brought them back. Also it allowed more different ways to describe robots.
Initially I wanted to have the player unable to address the robots by name, so that she could only say things like “every robot that can see a hauler, move toward the hauler.” So she would have to set up her own logic puzzles–having concluded that these three robots could see a hauler, and these two could see a peak, then this robot was identifiable; etc. Part of the idea was to make it necessary to use phrases like “every scout” rather than “alpha, beta, and gamma.” But my attempt to set up the understand phrases for “robot that can see a hauler” led to infinite loops. This was probably for the best for all concerned.
So, how did it work?
I was really pleased with how the grid navigation and sight worked. Let’s say I was really pleased that it worked. After I had motion set up I was able to leave it in place and not worry about it.
Vision took a fair amount of tweaking. Initially I had planned to take a “ray tracing” approach where the vision for each robot was calculated by spreading a cone out from the robot in each direction and reporting each thing that the robot could see in that cone, while keeping track of which parts of the cone were occluded. But I couldn’t figure out how to make this work, and there were few enough potential objects in the field of vision that it wasn’t too hard or computationally expensive to loop through every object that was close enough to the robot and try to trace a line of sight to the robot. On the other hand this was fussy with the terrain features that were spread across multiple squares (I had to severely tweak the rules for craters, since initially I was measuring from the center of the crater which is always blocked by the walls) and it doesn’t seem like it’d scale well to a less featureless environment. I’d really like to be able to scale it to a more featureless environment.
I also included a fairly elaborate system for figuring out when one terrain feature is partially behind another which is either entirely bugged or never applies because I set up the terrain generation so no terrain feature can ever be partially behind another. Maybe I’ll try tweaking the terrain system and see if it starts applying.
Another thing that worked out pretty nicely was setting everything to be privately-named and including Understand lines that only worked when the robot in question could see the named item. That seems like it might not scale to other projects, though.
It’d definitely be good to come up with more descriptive descriptions. It seems like shuffling things around to produce reports like “To the southeast it can see two scouts and a pointed ridge” shouldn’t be too bad. What I’d really like to do is have something like “To the southeast it can see two scouts in front of a pointed ridge”; and, better yet, instead of “It can no longer see Alpha” to have “Alpha has disappeared behind a rounded peak” or something like that. That’ll be more work.
As for how the multiple actors worked–well, I guess I learned not to try to do anything on top of a complex code base that I don’t understand unless I have a lot of lead testing time to correspond with someone who does understand it. That is, if I’m going to be upset when I wind up with a bug I can’t fix. The “You must supply a direction” bug was particularly cruel–a bug I had no hope of tracing that wouldn’t manifest in the IDE and that happened every turn in the release versions, and that I couldn’t have fixed myself if I’d understood it.
On top of that I wound up with some strange hacks to modify the behavior of the Multiple Actors extension–for instance, in order to get the Every Turn rules to run if a command to multiple robots gives a parser error for the last one (such as “robots, move toward astronaut” when only one robot can see an astronaut), I had to tie the every turn rules to printing the command prompt. This at least had the potential to break a lot of stuff–at least some of the time the code for ending the game was broken such that the game wouldn’t actually end when it was supposed to, but accepted one last command prompt and then ended. (This is why the endings have some odd prose about waiting–if the player encountered that situation I was hoping to get them to type “z” and then get the ending.) There was also some odd behavior with commands to multiple robots on the first turn and the first turn only, which I just avoided by forcing the player into a tutorial in which there was only one robot available on the first turn. Overall I’m lucky it even worked as well as it did.
Still one thing that seemed to work OK was the tutorial and the command syntax. I did the tutorial at the last minute (after the deadline for the first draft submission, in fact) and it’s crude in some ways–if the player goes off script the tutorial will get lost–but it seemed like few players got completely brickwalled by the format in which commands were entered, which is nice because it was nonstandard even for parser games.
As for the game; it was OK, I guess? Some people didn’t like tweedling around the grid looking for all the treasure, er astronauts, which is understandable and it’s a bit unfortunate that the comp format tended to put them under some pressure to play it. Others seemed to like it. I’m not sure if anyone was enthralled enough to want to tweak the settings to make it more challenging or whatever, though one of my goals was to make something in theory replayable. For what it’s worth I didn’t envision it as something that you ought to have to map–just doing a lot of general sweeps across the map should give you a fair idea of which robot is where and where you need to explore.
One thing that really didn’t work very well, I think, was the elaborate system in which higher terrain gets caught in the terminator sooner and sometimes it casts shadows behind it etc. None of this is conveyed to the player at all.
I have some other thoughts about the state of the Inform 7 parser and how easy it is to modify but I have to run now. Thanks to Carolyn, the judges and other participants, and especially my testers and Daniel!
