This month I ended up going back to exploration and working more of the awkwardness and bugs out of it. To begin, I devised a tiny text adventure game that Acuitas (or just the simulator running the game engine part of him) can play. Like my text-based Zoombinis games, this is a separate Python program Acuitas can launch and interact with; it outputs descriptions of the player's character and environment, accepts statements about what the player wants to do, and parses those statements (in a very simple way) to choose appropriate reactions.
The game defines six locations: "foyer," "parlor," "kitchen," "bedroom," "mudroom," and "outdoors." The first time Acuitas visits any location, the game will provide him with a description of the room, its contents, and its doors. As in my very first game demo, the player character is assigned a Problem - they are hungry - and wins the game if they pick up and eat an apple. But this time the apple is not immediately accessible; the character starts in the foyer, and the apple is in the kitchen. Since the game does not provide any info about the location of a food source up front, the player needs to explore until one is found.
Exploration, as I detailed in my last post, has three key actions (Examine, Experiment, and Exit) which need to work together. After beginning the game in the foyer, Acuitas will spend some time selecting objects at random to examine (the game responds with a more detailed description of the object) or experiment with (Acuitas chooses an appropriate action to do to the object, and the game responds with what happens). Acuitas' notion of "appropriate" comes from relationships between verbs and their possible objects stored in his semantic memory database. So he will, for example, attempt to open, close, slam, lock, and unlock doors. The game usually just responds with "you cannot do that," since most things Acuitas might try are not at all relevant to the game goal of eating an apple. The pressure to Exit increases with each of these other actions, until finally Acuitas selects a door at random and leaves the room. The game spits out a description of the new room entered, and the cycle repeats.
I've got things to the point where Acuitas will wander through the available locations and look at, or try to mess with, objects on the way. This was more complicated to set up than you might think, given that I'm trying to do it in a generalized way and not have Acuitas make too many limiting assumptions. There are lots of doors in the game - when a door is mentioned, is it the same as a previously mentioned door, or is it different? Which of all the objects described so far are available to be interacted with? I had the worst time getting him to keep track of his own location and not think he was in two rooms at once ... the problem turned out to be that some of the exploration code was inadvertently modifying records on the game's narrative scratchboard when it was supposed to be only reading them. Then a scratchboard input saying "You are not in <location>" wouldn't match the "You are in <location>" record and switch it off, because the original record had extra attributes larded on. Uuuuuggghh. The whole exploration loop works pretty well now, though.
The final necessity that I have just started working on is a way for the exploration procedure to notice when something goal-relevant has been discovered, so it can halt and let Acuitas fulfill the goal. Right now he'll find the apple but stroll right past it, because continued exploration takes precedence over solving his hunger problem.
Maybe I'll get a proper demo of all this made by the end of the year?
Until the next cycle,
Jenny
No comments:
Post a Comment