Guest Post: Luke Dicken on Redshirt AI

As I (Mitu) get on with UI improvements, content, and other functionality, I enlisted the help of Game AI consultant extraordinaire Luke Dicken to make the Spacebook within Redshirt seem more believable. He very kindly blogged his thoughts on the experience, and its outcomes, below:

In this Dev Blog I’m going to talk briefly about some of the things that are happening under the bonnet of Redshirt. For those of you who don’t know me, my name is Luke Dicken and among a few other things I’m an artificial intelligence (AI) contractor with Robot Overlord Games. When Mitu needed a hand to create realistic characters inside Redshirt, she asked me to help out.

So to recap, Redshirt is a sci-fi parody sim based around “Spacebook” in which the player’s actions affect their relationships with the members of crew who their character works alongside. This poses a really interesting challenge from an AI point of view – actually more than one. Firstly we need to create characters that are socially aware and able to react to events within Spacebook, as well as interact with each other. Creating a simulation like this would be tough enough, but then we need to expose this to the player through a pretty limited interface – how can we express the kinds of complex social interactions that need to be represented back to the player? We can spend as much time as we want making the best AI systems in the world, but if the player can’t see that then there’s very little point. It’s also been shown that the player will make their own inferences about what the AI system is doing. In the same way we look at animals and anthropomorphise their behaviours and intentions, we also do this with the enemies we face in battle in game (or on social networks). We construct our own narratives about what an NPC is up to based on the cues we perceive, without necessarily having any idea as to the internals of the system or whether our assumptions and speculations are correct.

For Redshirt, the cues that the player experiences are limited to seeing the NPCs interact with Spacebook and attending events with the NPCs; the AI system we create has got to be sufficiently capable of using these to allow the player to fill in the blanks in the each NPCs life-story. To make that happen, we need to ensure that the NPC “stays in character” – when they step outside of the bounds of how the player might reasonably expect them to act, we’re breaking the player immersion. However, that’s not to say that the “nice” NPC always has to be act nicely – people have bad days and act out on Social Networking, so we can work within these constraints to add variety, but in a controlled manner.

We’re using a model very similar to the representation of the player we expose through the UI, partly as this keeps the code streamlined and partly as this helps the players to relate to the AI by using the same core value system, so each NPC is tracking their current attributes across the 6-dimension axis previously defined.


Coupled with that we’re also adding in a concept of personality, which will affect the starting values for those attributes and the range they can take. We’re doing this because ultimately, everyone wants to be happy. If we let the AI system run off and do its thing, we’d quite possibly end up in a situation where over time all the characters stabilised by maxing out all their attributes. Personality allows us to avoid this and also allows us to define a set of tendencies for each character, which allows us to bring diversity to the behaviour of the NPCs, which again reinforces this concept of player immersion that we’re driving towards – nothing would break immersion more than feeling like the space station was filled with a bunch of beige clones all stepping through the same flowchart each time they need to make a decision.

At the same time though, we also want to have a codebase that’s really easy to write and maintain – we don’t want to be having to hard-code each NPC’s behaviour system, so as much as possible we’re looking for reusability. What we’ve settled on is an approach known as a Behaviour Tree, which allows us to define the behaviours and actions in a hierarchical and sequential manner. As an additional factor, it’s worth pointing out that Redshirt is being created in Unity, which allows us to make use of the “Behave” framework developed by Emil “AngryAnt” Johansen. For a great introduction to Behaviour Trees, I highly recommend Bjoern Knafla’s #AltDevBlogADay post on the topic. What’s great about BTs for us is that we can use a component known as a priority selector to determine which action gets triggered at a time point, and this means in turn that we can tie our notion of action priority back in to the system of attributes and personalities that we are using to model the NPCs. This allows us to create characters that don’t just react to events, but react within the context of their own state and personality. Doing this relies on some aspects of Utility Theory to make work, and in particular was inspired in part by a great session at the AI Summit at GDC titled “Embracing the Dark Art of Mathematical Modeling in AI” by Game AI gurus Kevin Dill and Dave Mark. Essentially what we do is use our knowledge of an action to create a function for that action that calculates its utility to the character, that is to say, how valuable doing this action would be within a fixed 0-100 range. We work out this value with reference to the attributes mentioned above, so two different NPCs when confronted with the same situation will act different, but use the same code to do this. We also draw in some semi-random actions, such as breaking ties randomly, so even the same NPC may react differently if confronted with the same situation twice.

I’m personally really pleased with how the AI in Redshirt is shaping up, I think we’re on to something great with this – and that’s important because with a game like Redshirt, the entire player experience hinges on immersion and creating a vibrant world for them to interact with. Any wrong step by the NPCs can snap them out of the spell and we really don’t want that!

Luke Dicken is the founder of Robot Overlord Games ( ) where he develops games and adds AI special-sauce to make other people’s games awesome. You can see everything that Luke is up to at or follow him on Twitter: @LukeD