Writing Graceful Parser NPCs

“NPC implementation is crazy difficult, and hard, hard work; most games deal with it by elision and sleight-of-hand, with the need to avoid direct character interaction often shaping a game’s core premise.” – Sam Kabo Ashwell, Best NPCs 2013

IF authors have been struggling with NPC implementation for decades. People are complicated. They take actions and they have reactions. They have opinions and memories. They can hold conversations and have emotional responses. They are spectacularly difficult to emulate in games – especially parser games, where the core conceit is that the player can do anything and the game world will respond appropriately.

It is very difficult to write people that respond appropriately.

…but people are important. (As I’ve mentioned before, one of my core parser design philosophies is: Build problems that can be solved with objects. Build stories that relate to people.)

Full-fledged NPCs can be marvelously rewarding, as Lost Pig and Galatea demonstrate. But designing and implementing a full-fledged NPC is an exhausting process. What’s more, while I always want my stories to be about people, I don’t always want the game to focus on NPC interactions.

How can you gracefully handle NPCs without full NPC implementation? Here are seven techniques.

1. Keep NPCs offstage.

Show evidence that people have been in a space – possessions, letters, decorations, all the touches of civilization and personality – but don’t allow the player to come face-to-face with them.

Variation: NPCs can interact with the player, but the player can’t interact with the NPCs. This can be done with things like intercom announcements – think of GLaDOS in Portal.

Another variation (highly uncommon): Turn NPCs into PCs. Have the player control multiple protagonists in succession, but never allow those protagonists to come face-to-face.

2. Restrict NPC interactions to cutscenes.

As soon as the player comes into contact with an NPC, drop the player into a written cutscene. At the end of the cutscene, the NPC departs the area.

Variation: Many parser languages, including Inform 7, have extensions that allow for choice-based conversations. This allows the player to control interactions with NPCs without opening up the whole parser-syntax worm bucket.

3. Force the protagonist to avoid interacting with NPCs.

Stealth games are the classic example here. If PC/NPC interaction is a failure state, then you don’t need to implement things like conversation mechanics.

4. Design NPCs who don’t want to interact with the protagonist.

There are a lot of situations where people won’t interact with other people – they’re too busy doing other things (like a game dev with a deadline), or they’re under orders not to (like the guards at Buckingham Palace), or the situation is just creepy (like people in the bathrooms at Penn Station).

Variation: Make NPCs who can’t respond to the protagonist, even though the protagonist can interact with them. This requires some very specialized mechanics, but Adam Cadre’s Lock & Key is one example of how it can be done.

Another variation: The NPC has authority over the PC, and is actively offended or archly amused by the PC’s attempts to avoid whatever-it-is that the PC should be doing right now.

5. Give NPCs an overwhelming distraction.

This differs from #4 in that the NPC might want to interact with the protagonist, yet is incapable of doing so effectively. The NPC could be severely wounded, traumatized by grief, or paralyzed with fear, or, alternately, incoherent with happiness or frenzied with excitement – or just hopped up on too much sugar, for a comic twist.

6. Create a communication gulf between NPCs and the player.

The classic way to do this is by making the NPCs inhuman. Interacting with a dog, a kobold, a ghost, an alien, or an AI is very different than interacting with an adult human.

7. Set expectations around NPC interaction through stylized writing.

This isn’t so much a stand-alone technique as a way to enhance the others. The more detailed and “real” your NPC feels, the more players will expect from that NPC. You can turn this around the other way by making your NPC feel less real.

Players will expect less interaction from a nameless character than from a named one, and they will expect less implementation from a character that is mentioned in the room description than from one that has a separate presence described in the room. You can also replace complicated conversation systems such as Inform’s standard “ask about/tell about” with a simple “talk to” verb.

This technique is a two-edged sword. If you lower people’s expectations for a given NPC, then people’s expectations will be justifiably lowered, and the NPCs who appear in your story will elicit less attachment and fewer emotional reactions. This approach deliberately shifts them away from being people and toward being set pieces.

But I want to write fully implemented NPCs!

Good luck!

…no, seriously; it’s hard. I should know, because the Ashwell quote at the beginning of this article is part of a review of my game Ollie Ollie Oxen Free, which won the XYZZY Award for Best NPCs in 2013.

From the same review:

“Ollie doesn’t dodge; it aims unwaveringly at the problem of making functional NPCs, NPCs that are not merely collections of carefully-deployed writing snippets but reactive game entities…. [This game is] a good demonstration of why so many games prefer to dodge wide around this problem. There are so many ways to interact with characters, and so many situations that characters can potentially be in, that buggy responses are routine.”

I wish I could argue, but he has me dead to rights. (That’s why Ollie Ollie Oxen Free doesn’t appear on Sibyl Moon – I’m holding off until it’s fully debugged.)

So where do you start?

First, do some research! The XYZZY awards for Best Individual NPC are a great place to start, both the winners and the nominees. Next, check out the XYZZYs for Best NPCs. This will show you what has worked well in the past.

Second, take a very hard look at the commands built into your language of choice, and consider how they interact with NPCs. In Inform 7, this covers not just “ask NPC about topic” and “tell NPC about topic”, but commands like “yes”, “no”, “sorry”, “kiss”, “attack”, “give object to NPC”, and “show object to NPC”, not to mention the persuasion system for ordering NPCs around. In my experience, the default answers rarely fit my needs, which leads to an awful lot of custom writing.

Third, implement your NPCs. Do the best job you can, while always making sure that your implementation still serves the story you’re telling with your game. Give some thought to the techniques described above – even if you don’t want to sleight-of-hand around NPCs, there may still be logical ways to reduce the pressure.

Then…

Fourth, get a whole lot of feedback. You’ll want people to spend a lot of time with your NPCs, and you’ll want both people who are new to parser games and people who are old hands, so you can see what initial expectations are like versus experienced players’ interactions. After you see what they expect, go back and polish your game. Then send it back for testing. Then polish it some more. You don’t have to implement everything that your playtesters try, but you do have to fix every bug they find – because every time a player triggers a bug related to your NPCs, it will damage the illusion of the game world.

I’m hammering on this point not just because I believe in the importance of playtesting, but because this is the biggest error I made with Ollie Ollie Oxen Free. I finished too close to competition time and skimped on testing, and the game suffered for it.

I’d like my next game to be better. I wish the same for you.

Good luck, and happy coding!