The paper was finished, submitted, and accepted as a full paper at FDG. WOO! I need to do revisions in a couple of days.
But first, I’m working on my advancement introduction! I’ve been struggling with it for the past month or so, getting information, changing details and framing, and overall pummeling my ideas into the dirt. I’ve gotten to a pretty good place so far!
~~~ ***** ~~~
In my paper, I touched on why creating interactive virtual characters are difficult: they have three huge sections (sensors/input, the AI that acts on those sensors, and the actuators/output that enact the AI’s decisions). This is fundamental in any standard AI textbook and is true for any autonomous agent. Understanding real-life inputs (through something like the kinect) is a hard problem on its own, as is procedural animation of arbitrary actions. The focus of my research is not on those areas, but on the gooey center: the AI that determines behavior.
Even ignoring those complicating parts of the process, authoring behavior is very difficult on its own. Working with an example quickly illustrates the difficulties of authoring. The following is one instance of brainstorming how someone might conceptualize the behavior of opening a door.
- Assume we start with a single idea representing our idea of “opening a door”
- Well, obviously if the door is already open, this behavior should do nothing. So the character should only try to do this behavior if the door is closed!
- What if the door is closed, but is locked or blocked in some way? We need to execute a sub-behavior to unlock or unblock the door, which would start going back up to #1 again for a different behavior. The same would have to occur if you are out of range of the door.
- If you get distracted from opening the door, such as a kitty walking by demanding attention or an earthquake shaking the building and destroying the door, when is it appropriate to abort or continue the performance?
- And what if those sub-behaviors fail, if the door is nailed shut or ‘blocked’ by a sign that says “KEEP OUT!” (physical and social barriers)? Should you keep trying at the door? When should the character give up trying to open the door?
- Let’s say the door has a non-physical property that would cause it to be treated differently: such as a locked bathroom door, or a front door to a house that isn’t yours. Now we need to deal with complicated social norms of knocking, waiting, and maybe even conversing with people before we can open the door.
- What if you are in danger, and you see an armed person on the other side of the door? You certainly wouldn’t want to try to open the door any more! ABORT!
- Or, better yet, what if you have the door half-way open before a rabid dog comes barreling down toward the door? You not only want to abort, but reverse, the performance.
- And if you finally get to be able to open the door, certainly not everyone opens the door the same way all the time. If you’re angry or stressed, you’ll swing that door open quickly and tersely. A secretive person, if they suspect someone is on the other side, will crack the door open and guard it. A butler would open the door wide and stand at gracious attention.
What started out as a single idea now contains a huge chain of sub-behaviors gating the performance of opening the door, including possibly deserting the behavior all together, and an overloaded performance of how many different actors could dramatically open the door. And each sub-behavior expands exponentially as this single door behavior has done.
This all assumes you also know how to make all of these behavior cases execute properly in code: such has animating door-opening speed, or keeping track of social norms like bathroom use. And, even if they did execute with flawless logic, that the player/viewer would read these performances as they were intended: what if a fast door-opening instead read as excited rather than angry? The author may have to iterate to make sure facial expressions and other supporting evidence in the scene communicates their proper intention.
My research aims to address and alleviate these authoring problems (of rapidly expanding state space, code-writing, and performance visualization) so that creating detailed, interactive, and dramatic stories is not such a daunting task.
More to come tomorrow.