2014-01-08

xuenay: (Default)
2014-01-08 08:32 pm
Entry tags:

Bayesian academy game: A core mechanic

I feel like my progress with my academy game has been frustratingly slow. Lots of natural language, little code. Over Christmas leave I finally put together a simple Bayes net and belief propagation implementation, but when I was about to move on to start actually implementing the game side of things, I realized that some of the things that I had planned didn’t quite work after all. Then I got stuck for a while, trying to decide what would work in the first place. But then I fortunately started having new ideas, and finally came up with a core gameplay mechanic that would seem promising.

For example, suppose that the player wants to persuade an NPC to dance with her. Below is a representation of what the player character knows of the situation, somewhat similar to how it might be shown in the game.

Some of you will recognize this as resembling an influence diagram (but note that it doesn’t follow all the conventions of one, so if you do know influence diagrams, don’t try to read it literally as one). The rectangles, which would ordinarily be called decision nodes, are two possible dialogue options that the player has. She could try to take a flattering approach and say “I heard you’re a good dancer” in an attempt to appeal to the other’s vanity, or she could rather try to focus on his kindness and nurturing instinct by admitting that she herself has never danced before.

The ovals – uncertainty nodes - represent things that influence the way that the NPC will react to the different dialogue options. A character who’s confident of their dancing skills is going to react to flattery differently than someone who’s insecure about his skills.  The ovals form a standard Bayesian network (or several of them), meaning that the player can have differing amounts of knowledge about the different uncertainty nodes. Maybe she knows that the NPC has high self-esteem, and that this makes it more likely that he’s confident about his dancing skills, but she doesn’t know how good he actually is at dancing, which also influences his confidence about his skills.

Finally, the diamonds – usually called value nodes, but I call these reaction nodes - represent the different ways that the NPC might react to the various dialogue options. Depending on the values of the uncertainty nodes, flattery may please him, intimidate him, or make him react in an indifferent manner. In order to get the NPC to dance with her, the player has to elicit some number of positive reactions from the NPC, and avoid causing any bad reactions. A simple counter sums positive reactions minus negative reactions that have been caused while discussing the topic of dance: if it exceeds some threshold, he agrees, and if it falls below another threshold, he’ll refuse to even consider the thought anymore. The thresholds are partially determined by how big of a favor the player is asking for, partially by how much the NPC likes/trusts the player character.

Suppose the player doesn’t know much about this NPC, but she also doesn’t want to risk things by just saying things that might or might not upset him. Now, in addition to picking one of the dialogue options, she can also experiment with the network to see which variables would influence his decision the most. Suppose that she is considering the “appeal to kindness” route, and has determined that he really needs to be kind in order for this strategy to work. Now she can select the kindness node, and bring up a different set of dialogue options which are aimed at revealing how kind he is. But here too she needs to be careful, because another counter also tracks the NPC’s overall interest in the conversation. If she gets too many indifferent or negative reactions while talking about his kindness, he may just end the conversation and wander off, before she has ever had a chance to get back to the topic of dance. So there’s also an element of risk there.

Alternatively, if the player doesn’t think that getting to dance is that important after all, she can just try her luck with one of the original dialogue options. Maybe those will reveal something about the NPC that’s useful for something more important. After the conversation is over, the NPC’s basic liking for the player character may be adjusted depending on the total positive and negative reactions that she got out of him.

It’s also easy to add additional different complications or advanced options: e.g. an option to pressure the NPC into something, which if successful contributes points for the goal counter, but reduces their liking for you afterwards.

So that’s the basic mechanic. Notice that this basic structure is a very flexible one: instead of talking to an NPC, the player character could have broken into his room in order to look for her stolen necklace, for instance. In that case the decision nodes could represent different places where the necklace might be, the chance nodes might offer chances to look for clues of where he might have hidden the necklace, and the “hit point” counters might represent time before someone shows up, or before the player character loses her nerve and decides to get out. So the same mechanic can be recycled for many different situations.

As for the educational content, the fact that you’ll need to read the Bayes network involved with each variable in order to decide what to do should teach a bunch of useful things, like a basic ability to read the network, evaluate the value of information related to each chance node, and notice and understand d-separation. Not to mention coming to understand how many different situations can all be seen through the same probabilistic framework. And it ought to all relate to the game content in a meaningful manner.

(I also have lots of ideas for other core mechanics. I also should really get the first version of this game done eventually. So I’m making a note of all those other ideas, but for now I’ll focus on milking this core mechanic for all that it’s worth.)

One interesting question is: should the results of the decision nodes be deterministic or random? In other words, suppose the player knows the values of every node that influences e.g. the outcome of the flattery dialogue option. Does that mean that they know what the outcome of choosing that option will be? Or do they only know the odds of each outcome?

I’m inclined with going for the deterministic route: if you know everything that influences the outcome, then you know the final result. I’m not sure that having a random factor in there would be all that realistic, and more importantly, if you’ve spent your time and resources on discovering the value of every parent node of an option, then you deserve to know exactly what outcome your choice will have, rather than getting screwed over by a 10% chance for an unexpected result. And if you don’t know the value of each parent, then there will effectively already be a random factor involved in terms of what you don’t know.

This should hopefully be my last post before I actually have a playable prototype done. Even if a very short one.

Originally published at Kaj Sotala. You can comment here or there.