This devlog covers my work on the agent behaviour for Chekhov’s Gone! Broadly speaking, the emergent behaviour that occurs in Chekhov’s Gone! comes out of Actors performing Actions in pursuit of their Objectives.
Research
Procedural Storytelling in Video Games (2019) was of particular use in approaching this area, especially Tarn Adams’ chapter on Emergent Narrative in Dwarf Fortress. I made particular note of his provocation to procedural designers: ‘produce an example output and ask “what’s the least I can do to generate more of these?”‘ I don’t for a minute think I’d be able to procedurally generate dialogue on par with Chekhov, but one thing that has always struck me about his stage work are the specificity of his stage directions (many are often cut from the original Russian, and indeed many of those were incorporated from Stanislavski’s directorial notes).
So, an initial gesture might be to generate something like this:
Konstantin squeezes [Dorn’s] hand hard and embraces him.
Chekhov, A., trans. Frayn, M. (1986)
Or:
[Dorn] takes the snuffbox from [Masha] and flings it into the bushes.
Chekhov, A., trans. Frayn, M. (1986)
I followed Adams’ exercise of breaking down these examples on the hunt for design implications:
- Konstantin / Dorn – characters in the play, but what do they need beyond that? Is it as complex as the thoughts and preferences of Adams’ own dwarves, as referenced [link to DF case study]?
- Squeezes / takes / flings / embraces – verbs of physical interaction are probably the chief means of communicating meaning in this simulation, so I should have a wide variety. But perhaps they could be grouped under simpler actions, and have a more superficial modelling? I am not making a fighting game set in the world of Russian theatre. (But maybe that’s next…)
- Hand – do I need to concern myself with modelling bodyparts? This can probably be achieved more quickly if ‘hand’ is one of the abstract linguistic components of the action ‘squeeze’ or ‘take’.
- Snuffbox – items will need to exist in the game; do they need to have functions themselves?
- From – characters will need to be able to carry items, and other characters must be able to take them from their person; but do they need to observe them having them in order to know that they have them?
- The bushes – again, I probably don’t need to model environments in their totality; rather these could be tied to action verbs in the abstract.
Performing this exercise gave me some clarity on the depth of simulation I would need to achieve – though still nervous about attempting this challenge, I had some direction on how to start assembling the ingredients for my agent behaviour.
Objectives
As a nod to Stanislavski, who produced and directed the second, most famous production of The Seagull, I would construct the agent behaviour around concepts from his acting theory (Stanislavski, 1937). Rounds would be called units, turns would be called beats – but the real meat of his work is in objectives. Any agent in the game would need to be able to differentiate between Actions that would further their character’s objectives and those of less importance.
So, I created an Objective class. This I conceived as a broad umbrella for many sub-objectives – one might term this Objective class Stanislavski’s ‘super-objective,’ and the sub-objectives his ‘objectives,’ but I won’t be that picky. Each is named around the general ‘thing’ an Actor wants to get done – Masha confessing her love to Konstantin, Sorin convalescing – but contains a number of tasks that need accomplishing in pursuit of that larger affect. These I defined as sub-classes:
- RoomContains – a class referencing an Area and an Item. The Item needs to be in the Area (this was mostly a test of my Agent’s ability to follow through with tasks, but does map to more servile Actors like Masha bringing the samovar to the drawing room etc.)
- ActorsIn – a class containing an Area and a list of Actors who need to all be in the Area at once for the objective step to mark complete. This was the most complex objective step to code, as it required a new (and pretty tricky) Action to be created: the Influence Action (more on that later).
- AloneWith – a class referencing a partner Actor. If the Actor is in a room alone with the partner, the objective step is complete.
- TalkTo – this is a slightly more dynamic class, as it can reference either an Actor, a Topic or both an Actor and a Topic, and has a dangling bool for whether or not the conversation needs to happen without other Actors in the room.
Already I was finding myself pressed for time, so I banked these as functional and resolved to diversify them further if I found a few extra days on the project.
Agent Interactions
From the above Objectives (and my own early experiments) I had identified a number of Actions that the Agents would need to be able to perform: Move (including Stay), Pick Up, Place, Talk To, and Influence. I defined subclasses of Action for all of these, and wrote a method inside the Action class which would search them up depending on the player’s string ‘tasktype’ (pulled from their currentObjective’s currentStep). Each of these needed a bespoke if-tree to define an Actor’s behaviour, and I was happy to see that once I had written one, the rest were relatively easy to extend. I found the time to write classes and methods for Listen, Ignore, Give and Take as well – many others are obviously needed for Chekhov’s Gone! to move out of prototype phase, but these were enough to start observing behaviour.
Priorities
Trying to create an if-tree that contained all of the different Actions would have been a combinatorial nightmare, so I decided on a system of weighting based on character motivation, predisposition and objective. Basically, the game processes all possible Actions an Agent can legally take on that turn (it can’t move to Areas that aren’t adjacent, it can’t talk to characters not sharing its location etc.), then assigns a small, random initial integer weight to it. Then, depending on the type and step of the Actor’s current Objective, it selects an ‘immediately salient’ Action and weights it more heavily. Once this is done, the list of valid actions gets ordered by weight, and (if the game is proceeding automatically) the top three are returned. A number is generated between 0 and the sum of their combined weights, and this decides for the Actor which of the top three Actions it will choose.
Testing
I had had success with this kind of system during my Critical Play project, but I was torn between the randomness of this system and the clarity of the one that automatically selected the highest weighted Action. In pursuit of answers I set up a test environment that would loop through 100 ‘beats’, output the text from each cycle as a string, and save it as a .txt file – then repeat that five times. This way I could gather a large(ish) sample size and perform comparative analysis – I wasn’t confident that, on showing the game to players at this stage, they would be able to discern the difference between the two approaches. Upon comparing the output logs, it was clear that, while in the short term the automatic selection seemed to create a more cohesive ‘story’, once the characters had completed their objectives (which they did in fairly short order) the game devolved to randomness. The consistent mixture between objective-driven behaviour and random – or ‘incidental’ – Actions present in the weighted system yielded more satisfying results across the board, so I committed to that.
Adding Player Interaction
After burning a whole three days failing to implement a slider-driven rewind system for the game, I resolved to press on with a simpler method of player interaction. By clicking on a character portrait, I imagined the player or director ‘giving notes’, which would either directly select one of the top three Actions or add at least a significant weight to one of them. To achieve this, I placed a boolean stop in the middle of the normal ‘beat’ cycle, which would check to see if the player was ‘focusing’ or not – if not, it would proceed with weighting as normal; if so, it would zoom in on the character in question and display three buttons above the sprite’s ‘head.’ Again, by breaking the behaviour into discrete static functions I was able to add this functionality very quickly.
I have some questions about the level of UI detail here – whether a player need explicit detail about the actions they are choosing, and whether the continued presence of the Action log is useful – but I will pack that up into some playtesting later on in development.
The Final Loop
The finished prototype behaviour loop looks like this:
Compromises
This project in particular has proved difficult to achieve in the time period – I have invested a lot of time in setting up systems for efficiency and expansion, but this has come at the cost of implementing more complex mechanics and deeper content.
For example, to save on pathfinding, I also decided that every Agent would know (or be able to check) the location of every other Agent, and path to it simply through a list of directional neighbouringAreas attached to each Area. The drawing room, for example, leads left to the kitchen, but also left to the upstairs, garden and stage. If an Agent wants to map to the stage from the drawing room, it finds the stage within the list of leftward Areas and proceeds to the Area first on the list, then repeats the process.
Conversation at the moment is also quite a flat system, with Actors sharing a pool of common Topics and loading in with a pool of bespoke Topics, some of which are secret and all of which have a tension threshold, or ‘cost’ – i.e. Actors won’t talk about personally sensitive information unless in a high state of tension. I’d like to deepen this with an attitude and a memory system, but time is too precious.
My modular behaviour loop does enable me to insert or abandon functionality as I go, however, so I have left commented steps for mechanics I have yet to find the time to implement: extra weighting with regards to character traits and attitude, other Actors ‘observing’ actions, Actors refusing a directorial note, and the aforementioned deeper conversational systems. If I get to these mechanics, I should be able to implement them quickly; if not, the behavioural loop will still work.
References
Stanislavski, C. (1937) An Actor Prepares. Translated by Hapgood, E. London: Methuen Drama.
Tarn, A. (2019) ‘Emergent Narrative in Dwarf Fortress‘, in Adams, T. & Short, T.X. (ed.) Procedural Storytelling in Game Design. London: CRC Press, pp. 23-36.