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:
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.
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:
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…