"At the simplest level a game designer needs to ask himself, 'how many different decisions am I offering to my players at any time?' In other words, how many different options make up the decision set which a player is faced with at any one time? The answer to that question affects the complexity of its game and also its playability". Designing Strategy: Decision Sets [via As Above] covers decision trees in games, and how to prune them back at the design stage to not overwhelm the gamer.
Conversational User Interfaces have been occupying me again recently. One problem specifically, which is how to design and model them. This is hard because a conversation (with an IM bot, for example) isn't a series of stateless request/response pairs, not if you're designing according to Grice's Cooperative Principle: "Participants assume that a speaker is being cooperative, and thus they make conversational implicatures about what is said". What this means is that the bot must make maximum use of all that the user [interviewer?] has said, or at least make conversationally clear what's understood and not.
So, the tree of possible answers grows massively at every question. How to model/design this? Various plans, two of which can be seen (together with the indescribably ugly code itself) in this month's notes folder. A couple of early ideas: hoping only recent steps in the conversation would be important for a maximally cooperative answer; hoping that the tree would fold into major channels, conversational watercourses. The metaphor I'm happiest with is that the internal state of the bot is representated by a position (which may be discrete or smeared) in a dataspace. The conversation is represented by the trail of this cursor. An answer by the bot is an expression of this location on the map; how exactly it's expressed is governed by how the trail is shaped, how the current position was approached. The code is terrible, the CUI almost as bad -- but it's a framework to operate in, which is better than the last iteration.
"At the simplest level a game designer needs to ask himself, 'how many different decisions am I offering to my players at any time?' In other words, how many different options make up the decision set which a player is faced with at any one time? The answer to that question affects the complexity of its game and also its playability". Designing Strategy: Decision Sets [via As Above] covers decision trees in games, and how to prune them back at the design stage to not overwhelm the gamer.
Conversational User Interfaces have been occupying me again recently. One problem specifically, which is how to design and model them. This is hard because a conversation (with an IM bot, for example) isn't a series of stateless request/response pairs, not if you're designing according to Grice's Cooperative Principle: "Participants assume that a speaker is being cooperative, and thus they make conversational implicatures about what is said". What this means is that the bot must make maximum use of all that the user [interviewer?] has said, or at least make conversationally clear what's understood and not.
So, the tree of possible answers grows massively at every question. How to model/design this? Various plans, two of which can be seen (together with the indescribably ugly code itself) in this month's notes folder. A couple of early ideas: hoping only recent steps in the conversation would be important for a maximally cooperative answer; hoping that the tree would fold into major channels, conversational watercourses. The metaphor I'm happiest with is that the internal state of the bot is representated by a position (which may be discrete or smeared) in a dataspace. The conversation is represented by the trail of this cursor. An answer by the bot is an expression of this location on the map; how exactly it's expressed is governed by how the trail is shaped, how the current position was approached. The code is terrible, the CUI almost as bad -- but it's a framework to operate in, which is better than the last iteration.