The last two blogs have focused quite heavily on my implementation of Dialog Templates, and for good reason: We’re working with live data and need fast, relatively easy ways to put that data into a format that fits conversations with players. Generally speaking, a lot of what we say can be broken down into templates. The majority of conversation tends to consist of agreements: “Okay.”, “Yeah”, “uh huh”, head-nodding, etc. The rest breaks down into a finite number of categories, which then break down into a finite number of ways you can get that information across to the other person. Granted, that finite number is incredibly large, but sentences aren’t just a permutation of words. Grammar, and the need to address certain topics, limits what you say in any given sentence dramatically, and being creatures of habit, people tend to talk in a certain “way”, and that “way” is just the format of words that they use. In short, Dialog Templates are built partially on how people use words.
Now, in the past two blogs, I’ve talked about how I’ve been using dialog with markup to “mad-lib” data into conversations between players and characters. Lately, I’ve been looking at the limits of that system from a technical perspective. A line of text is doable, for sure, and you can go as deeply as you need to using strings- all the way to defining file formats like xml and so on to define Dialog Templates. I’ve actually considered something along those lines! Mainly because Dialog Templates need to be resilient when data is lacking, and you need to be able to “transform” words when working with certain kinds of other words.
What I really need to do is just make Dialog Templates into their own class.
Lacking time lately (I’m working on a contract in addition to the “day job”), I haven’t gotten to sit down and put my thoughts to a post before now, but I’ve been wanting to finish up my thoughts on where Dialog Templates were going to wind up in regards to Interrogative. And, basically, they’re going to be a class that you can work with like any other data object in the toolset. It’s much more important than just a string we fiddle with to get text that the player can read. As the need for markup- and then the expansion of that markup- showed, Dialog Templates are a system of working with words to provide localized, dynamic text. So storing it as a string is no longer beneficial.
So that’s it! I need to get that last bit about Dialog Templates out of my system as I worked on it, and in a month or two I’ll be blogging a lot more regularly as my time frees up a little bit and I throw more of it at Interrogative and the tool for creating content with it. Oh, and speaking of which…
Deciding on tool development…
So, I also talked a while back about the need for cross-platform tools, and having done quite a bit of cross-platform work lately, I feel like I’m coming full-circle on AS3, which I stopped working with a couple of years ago. The reasons are actually pretty simple: With AIR, you write one codebase and then just compile for (and on) your targets, and you’re done. Using C#, I need Mono to launch it, which is an automatic non-starter. For C++, it’s doable, but then I get sucked into the Lovecraftian hell that is dylib install paths on the Mac. Objective-C: Pfft. I like the flexibility of HTML5, but you get sandboxed, so that’s a non-starter.
But looking back at AIR and AS3, the issue that turned me away from it has been addressed in Captured Runtimes, so I can package an app and never worry about AIR version changes breaking the app. And I get the functionality I need for the tool with a bit more flexibility than the above languages (except for HTML5) for the GUI, with automatic cross-platform support and the knowledge that it will look the same pretty much every where.
Adobe, you had me at everything I wrote above this sentence…
Next blog: Bagels? I like bagels… Maybe we should talk about bagels. Or maybe AI is a more appropriate subject…
