So, I’m taking a hammer to the current iteration of Dialog Templates for Interrogative…
The current iteration turned out to be a good starting point for a much more flexible and resilient system. It’s slower than I’d like, with less flexibility and too many functions needed to make it work. It leans on too many things, and is not properly encapsulated. What Interrogative needs, in order to match the flexibility and power of its back-end querying and knowledge representation, is a Dialog Template system that is equally flexible, resilient to missing data, able to be localized easier, and much more simplified.
It’s one of the most important systems!
The Dialog Templates are the portion of Interrogative that the user will be looking at. Regardless of whether you choose to use NLP to decompose the users’ text, drop-down menus, or buttons, it’s the text of the conversation that matters most. It’s the end-result of figuring out what the player wants, sending it to the server, having the server create a response, sending the data back, and then formatting that data in a way that looks like dialog.
Internals of how that all happens is lost on the user, and should be, since they’re more concerned about their character’s story. But the internals have been bogging down, as of late.
During GDC, I sat on the second floor of the West Hall and started ripping things out of the editor that had been made obsolete by some minor improvements. Things like string fields for knowledge categories where an int field accomplished the same thing more efficiently, and moving some GUI items around. However, as I played with the conversations, I kept running into issues with missing data, and the failure of the current Dialog Templates to handle it as well as it should.
Bad Dialog Template!
The biggest issue was in describing things, and how that query is due for an overhaul. The core issue is that there was legacy code that relied on categories that were basically relied on from the Epic Frontiers days, and that carried forward with the inertia of not being broken. Then it broke! Attributes allow for hierarchical categories, and that means that describing things no longer gets as neat as it once was. Instead of having a handful of purpose-made description functions that pulled data for describing a tool, vehicle, place, or living entity, the ability to define what an object was more broadly means that the description functions need to be similarly broad. And that presents a few problems.
For an object that is of an arbitrary category, you will need to pull the known data, and use that to describe the object, dump said data into a ResponsePayload object, and then fire that chunk of knowledge off to the client, who will then take it and stuff it into a Dialog Template, assemble it into a string, and then print that out onto the screen of the waiting user. Easy, right?
There’s a few issues to address, and some are sort of arbitrary…
- Given a description of an object, to which you don’t know the attributes (because it could be any object, whatsoever), then in what order do you list said attributes?
- How many attributes do you include in the description? Five? Ten? A hundred? Write a book?
- For custom Attributes being pulled, how do you reference them?
Solving the custom Attribute issue- with more data
Addressing these in reverse order, the fact that Interrogative allows you to add custom Attributes means that the Dialog Templates need to know what kind of text to put around it, or else you get text like “that thingamabob is 8”. “8” what, exactly? And it’s here that small details make dialog fall to pieces, even as the system can do everything else correctly. Attributes need to be able to tell the Dialog Template how to reference them, so that you get proper text like “that thingamabob is 8 credits”. Small change, huge difference in context- especially when you have a conversation where you are talking about multiple subjects. Data in context is important. “2 by 3” is less descriptive than “2 by 3 inches” or “2 inches by 3 inches”.
Attribute overload!
Now that we can get any Attribute and have its context pulled into the Dialog Template correctly, just how many Attributes do we want to do that with? If you ask Scotty to describe the Enterprise, then how much should he tell you? He knows virtually every nook and cranny of that ship. He can describe his quarters on the ship with more accuracy than other locations- should that be included? No, that’s insane. So at what level of detail do you describe an object?
So, there’s more than one way to skin this cat…
One way is that we simply limit the number of Attributes allowed into the description. Set a number arbitrarily as the default, allow it to be customized, and leave it at that. I’m lazy and can’t be bothered!
Or, slightly more complex is to have a preferred set of Attributes to use first, and then include a set number of additional Attributes. I’m less lazy, and have spent more time on this problem. Fist-bump!
Or, maybe let data do the talking… Look, custom Attributes got me into this mess, and custom Attributes will get me out. Creating another Attribute that states what Attributes to look up for a description query is possibly the best route. It allows the developers to quickly say “pick this, this, this, this, and this to describe this category of object”, and if you use that list to order the Attributes, then you kill two birds with one stone. Unless the developers never bother with that- NOW WHAT?? Well, in that case, see the above ideas. I think a stock list of description-friendly Attributes can serve purpose if the custom description Attribute is not present as a decent fallback mechanism.
And what if none of the stock Attributes are present, and nothing else gets returned? Error Dialog Templates are good things to have, and sometimes, just let your NPC exit that predicament gracefully.
Meanwhile, client-side…
This is a lot easier to deal with. Once you know your data, and have your constraints in place, you can make a Dialog Template object that can suffer the vagueness of data that the server responses subject it to. A Template Manager receives the ResponsePayload and picks the correct template, and then gives it the data that it needs to assemble the text and present it to the user.
A lot of this data is going to be numeric, and so the client-side will have a handy little lookup table to know how to translate the numbers into text, according to the Attributes that the data corresponds to. ColorHSL? There’s a function for that. A Float[3] for size? There’s a function for that. What was game-usable data on the server now translates to human-readable text on the client, without the client having too much access to the server, and without the server needing to do needless string and parse operations that it can safely farm out to the client.
Easy, right?
That’s all, folks!
I’m pretty sure the Dialog Template saga is not over. It’s going to continue to evolve, as will the rest of the architecture. The goal is to make the system as flexible as possible for what’s to come (queue thrilling music).
Next Time: Updated screenshots of the editor, screenshots of the new Dialog Templates in action, and even documentation ahead of the release!
