BablBrain

Worlds that Speak

Interrogative 3.0: Why the Conversation Focus?

NPCs have to talk…

Some time has passed since I first wrote Interrogative 2.0, and I’ve learned some things since then. The first is that people might be interested in such a thing as a product. The second is that it’s capable of so much more than what I had originally made it do. Another thing I’ve learned about is semantic data, which involves triples that allow me to work with data with more flexibility, but that sort of thing will be displayed in future blogs. Something that you might want to know about is why I focus so much on conversation, when that’s obviously just a feature being driven by personality traits that are driving AI.

The fact is, just our brains alone don’t make us human- it really is in how we interact with the world, and interaction in all of its forms is communication. For those of you with kids, you know this intimately, as you teach a child to communicate in increasingly sophisticated ways. Their first form of communication is simple and unvarying: crying. Then movement and different cries, gestures, pantomime, grunting, gibberish, badly pronounced words, single words, simple phrases, sentences, and then you wish they’d just shut up about that band they like. My son is still in the badly pronounced words phase himself, but he communicates pretty well with the dog, who herself has a range of communication from physical to biological (that last usually translates to “Maybe I shouldn’t have eaten that.”). All of this is to get data from them to us, the providers, about their current needs, wants, and states. Hungry, dirty, tired, pain, joy, disagreement, anger, etc. That is all a range of states given to us to (hopefully) modify their environment in their favor. Hungry? Cry for attention to get fed, or just ask for food. Sick? Whine, as dogs might, or say you feel like crap. Disagreements? State your opinion, call the other an idiot, or wage a war (that last option is limited in who it’s available to).

Interrogative is not so much about pushing a communication feature that mimics AI and more about a communication-centric AI. And by communication, I mean communication with the game world, not just players- and not just words. We can make an NPC speak to a player not just using Interrogative, but with many different solutions both proprietary and commercial. If the NPC cannot wander the world and interact with it when needed, then the NPC cannot fully communicate with it. And when the player wanders that same world, even with better AI, its shortcomings will eventually become glaringly apparent. Talk to an NPC in the kitchen, but they won’t offer you the food at their table. They don’t sit. Can’t tell you about a painting on their own wall. Don’t know about themselves. In some games, this isn’t a problem. But in others- this is where gaming absolutely needs to go.

The (fairly vague) feature list for Interrogative 3.0:

Some of what I want from Interrogative 3.0 to satisfy that deeper communication from NPCs is as follows:

  • It needs to generate dialog for the NPC on the fly to be able to describe objects in the game world, to answer queries regarding information that updates and generally to reduce the custom writing needed for dialog that could be handled by generation instead of writing.
  • It needs to handle game world information in a way that allows the other systems in access to it as well, otherwise it’s not really connected to the game world.
  • It needs to handle story generation and dialog in a more general way than just templates, although templates will likely still be a thing used in version 3.
  • The personality traits used in version 2 were an improvement over those used in version 1, but could not account for personality types that were absolutely needed by many game types and scenarios, and so need to be replaced with something more accurate.
  • It needs to be customizable and extensible by developers.
  • It needs to be written in a faster language than TorqueScript (the previous versions were scripted in the Torque2D and 3D engines), and more generally made into assemblies that could make itself available to many engines.
  • It needs to support statements from the player to the NPC. This is basically almost bringing back the “Tell” category from version 1.
  • It needs to remain data-driven, so that database queries could drive much of the labor, though the data need to support access to live game information.
  • The data that drove version 2 became a more complex than was needed, and moving towards a simpler set of data would make things easier on everyone.

There’s a lot in that list of generic wants, but what I’m looking to do is to level Interrogative up in every area. Since development has started in September, many of the older features have been successfully re-implemented, as well as some new features. Now we’re going to take a walk through Interrogative 3.0 as it gets ready for prime time.

Next blog: We’re going to talk about data and how little changes to format go a long way…

Interrogative: The Need for Better Characters

A New Focus

BablBrain represents a focus on AI, gameplay, and procedural content for online gaming. I’ll be doing a lot of blogging about the newest version of an AI technology I call Interrogative, as well as taking some tangents to talk about things like procedural content generation and some subjects to do with game mechanics.

There’s a lot to talk about regarding Interrogative 3 and its possibilities- but first, a trip down memory lane…

The Need for Better AI

The work on this kind of AI had started years ago, when working on a demo for an MMORPG that I had wanted to create titled Epic Frontiers. It was a hugely ambitious project in the scope of its features and aimed to improve upon every facet of MMORPG game mechanics, and do it in a consistent manner. Combat would be more like fighting games, with combos, user-created macros, and co-op gameplay via “skill-linking” (something I’ll blog about another time). Crafting was material-based and offered a mind-boggling variety of material qualities and properties, and was completely unsuited for an object system that was not based on voxels or something along those lines. As for the NPC AI, well…

The problem with NPCs up to that point (and very much for the most part today) is that they’re scripted to deliver walls of text for players to get information on simple quests, and then dispense loot and XP once those quests were completed. Anarchy Online smartly turned those NPCs into ATM-like machines that dispensed procedurally generated missions. But beyond functions such as giving out quests, acting as a store, or skill training, NPCs didn’t do much of anything. They certainly did not react to the player in any meaningful way, and in large online worlds, wouldn’t you want characters you could interact more with?

With that simple desire, NPC AI pretty much took center stage among the features for Epic Frontiers, but also took a long time between the wanting of the features, and the actual implementation of them. It’s a tough nut to crack, AI- especially the “general” variety. NPCs needed to have “personality” and act accordingly, yet move along with storylines. But wait! Stories needed to be flexible as well! What’s the point of NPCs having flexible and interactive personalities if they simply wound up shoe-horned into quests that were still statically scripted? So, stories needed to be dynamic as well, and the NPCs were expected to roll with that, and that meant that their dialog also had to roll with it. Simple, right?

We wound up with the following needs:

  • The system could not rely on Natural Language Processing. While it is powerful, it is also CPU-intensive for a multi-player game, and also it relies on correct grammar and spelling. For a game we wanted to support internationally, that meant that we would have issues with incorrect grammar and spelling, and localization would mean code changes to the system to support different languages. That’s way too much work, but also forces some constraints onto the system.
  • Due to the above, players would have to use menus to select dialog. Menus were used to great effect in Disney’s Toon Town MMO, which featured dialog menus to talk with other players using canned dialog and emotes. While that system was partially implemented with an eye towards keeping children safe from predators, it also demonstrated that dialog menus worked, as it was also partially implemented to deal with young children who don’t necessarily have the best grammar and spelling skills.
  • The NPCs would need to be able to converse more or less naturally, so the player needed to be able to change the subject without severely interrupting gameplay. Having to restart a conversation every time you wanted to talk about something else with the same NPC was a no-no.
  • NPCs would also need to have some semblance of “expertise”, so that the NPC by the forge knew more about sword-making than the bard down the block, but not as much about baking as the baker next door.
  • Because we weren’t using NLP to parse dialog, we needed another way to assemble text, and it needed to be relatively fast.

The first version of Interrogative addressed these issues to varying degrees.

Dialog was canned, and written much like dialog trees, which were then tagged with category names and numbers representing the  “Context” and “Knowledge Level”. NPCs could then be assigned this dialog by giving them the corresponding tag and a number, which represented a subject and the NPC’s level of knowledge in that subject. When combined, the NPC could access dialog that reflected differing levels of knowledge, which went a huge way towards giving NPCs a believably variable amount of intelligence.

What was better was that the dialog trees were explorable and a bit less tree-like, in that the player was able to select previous statements of an NPC and ask the NPC questions or make statements relative to that dialog and take the conversation in another direction. NPCs could also ask and await answers to simple questions as part of these dialog trees. And on top of all of that, the player could switch the subject they were talking to the NPC about, and continue on without restarting the conversation.

Along with a menu of dialog options, it was a nifty version 1.0:

Above: Interrogative 1.0 test in the Torque 2D Engine. Sprites were NPCs to be selected for interaction.

Above: Interrogative 1.0 test in the Torque 2D Engine. Sprites were NPCs to be selected for interaction.

Addressing the last need in the list, I implemented the dialog choices to be selected via SQL queries. There was some grooming in code to get the SQL statements assembled and to get dialog out of the database, but in the end, SQL did most of the heavy lifting for us, with code picking up the slack with sorting through which exact dialog of some close choices to display.

Interrogative 2.0

The above made for interesting dialog but it was, I felt, missing large chunks of true interactivity, not to mention issues it brought up with logistics:

  • Writers had to write all of the dialog for both the NPC and the player, and then tag that dialog for the appropriate availability. Much of the dialog- especially on behalf of the player- was repetitive and quickly became too much tedious work.
  • Players could easily be turned off by navigating too many menus to make their choices. It needed to be a simpler, more graphical GUI, rather than the menus shown above.
  • The dialog was far too specific to the dialog tree, and needed to be generalized in order to lighten the load. This pretty much went for the entire feature.
  • Since the dialog referenced objects in the game, the player needed to be able to easily reference those objects when talking to the NPC.
  • It still needed to rely on the database for most of the work, as that was a clear win.
  • Because we wanted to dynamically create missions, the system had to allow for procedurally generated content, and in a way that flowed through the conversation system.
  • NPCs would probably also like to be able to ask the player questions that would need to be answered, so that would be nice as well.

To support all of this, I needed to find a way to better differentiate between the kinds of dialog that were being used. As you can see above, the four “Categories” of Greeting, Query, Tell, and Farewell were kind of broad in scope.

Around this time, I had been watching the HBO miniseries Generation Kill, and found an interesting tidbit in the dialog of the Marines being portrayed: When about to ask a question over the radio, to clarify that they were asking a question and expected information, they would preface their dialog with the word “Interrogative”. I had never heard that word (don’t ask me if I paid attention in English class), and so I looked it up and found a good bit of dissection of conversation and dialog, including the use of interrogative words. Interrogatives were the answer! More to the point, interrogatives were the question, which is the most common reason a player approaches an NPC (aside from beating the NPC about the head and neck with weapons until it drops loot and XP like a walking piñata).

Instead of writing out repetitive or useless player-side dialog (who reads that?), make the act of asking the NPC for information an “Interrogative Action”, which is a generic way of classifying what the player was trying to say to the NPC. Things like who, what, when, how, where, and why were not just dialog or text, but actions. Not only were they actions, but they also lent themselves towards reuse and reduced the overhead for that part of the writing by almost 99%. A handful of phrases took the place of all custom player-side dialog, and while it was not as pretty as that custom dialog, it served its purpose very well (especially since the player cared more about what the NPC had to say, which was still written by a writer). This was a direct improvement over the four action categories from 1.0.

With issue resolved, the NPC dialog became less of a tree-like model of static conversation, and more of a set of dialog “snippets” that the NPC would respond with if the player had referenced the proper subject, clicked a certain button representing an interrogative action, and the NPC was assigned the appropriate tag and Knowledge Level to give the information. Added to it was monitoring for previous input so that additional features could be implemented, such as the Elaborate action, which asked an NPC to delve deeper into information, which was no longer doled out in great big walls of text, and to allow the NPC to know when it was being asked something by a player repeatedly, or if a certain chain of conversation was being followed.

Also added were pre- and post-condition processing, which allowed the NPC’s AI to examine properties such as personality traits, inventory, and even execute actions such as initiating combat if the player said the wrong thing. That also lead to the Insult and Compliment buttons. Other actions were created, and the Q&A feature from 1.0 also received updates that allowed for trivia-games to be played almost solely through the dialog system.

And with the generic actions and selectable dialog, the player had the ability to “Log” dialog to an inventory of “snippets” and then use those dialog snippets as actions themselves on other NPCs, in situations where the player needed to try and find an NPC that knew more of a subject than the NPC whose dialog was Logged. That was a very happy accident indeed!

The GUI for this system also got a much more compact makeover and the name Interrogative 2.0. You’ll notice that there are still text inputs, because you had the option of typing in the name of the subject (context) you wanted to talk about as well as selecting it, and the second text input was for answering questions:

Epic Frontiers with the Interrogative dialog system in action.

Epic Frontiers with the Interrogative dialog system in action.

Interrogative 2.0 was great! Not only did I address some of the issues with 1.0 by reducing the amount of player-side dialog that had to be written, but the new system was much more flexible and allowed for the addition of more Dialog Actions. In addition, it was set up to allow for dynamically generated missions that were presented by NPCs through their dialog, which were assigned to the player on the fly and tracked for completion. The dialog itself was based on templates for various mission types, much like those Mad Libs that many of us played with in the back of the car while our parents drove us somewhere on a long trip. But the Mad Libs approach works, and works well enough to be applied to the NPC responses too!

A simple markup system was introduced for the NPC dialog that allowed us to replace markers with things like the names of NPCs, player names, attributes, etc. The mission generation system made it a necessity, but it also pointed at the need for more flexible dialog, which was still a weakness.

With this, Epic Frontiers was demoed to some publishers, and while the project itself ultimately did not get any backing, the feature did raise some eyebrows. Raised eyebrows aren’t enough though, and without money the team disbanded and Epic Frontiers gathered dust. But over the years, the NPC AI and conversation features stuck with me, and a few months ago I began to write Interrogative 3.0 with an eye towards addressing issues, adding features, and releasing it for use by other developers.

Next, I’ll talk about the need for Interrogative 3.0, and a new take on NPC dialog…stay tuned…

© 2014 BablBrain

Theme by Anders NorenUp ↑