This whole blog is informal, but this is more of an aside than anything.
I left my notes on campus last week when I got sick and didn’t bus up to campus again, so the stuff I wanted to talk about is both very delayed and not with me at the moment. Instead, I’m going to brainstorm and jot down ideas for my meeting with Larry tomorrow to talk about a short-term design tool idea for IMMERSE. It’s like a pincer attack, coming at the problem from two ends: an immediate, actionable piece of software we can build to make authoring better, and a highly theoretical discussion of what makes up an effective authoring tool for interactive characters.
Last week, Larry presented what I thought was my work cut-out for me! A rough design of pie-in-the-sky authoring help for the immediate future. While Andrew tried to tear the thing to shreds — repeatedly saying that it would take too much time and that it would never be used because it wasn’t doing anything useful that programmers didn’t already have a back-door for — Larry was making an effort to do what I’m going to be trying to very soon. Larry didn’t share the google doc with me, and I still left my notes on campus, but I remember it roughly. It was made of three main pieces:
- Checkbox control for various behaviors to allow them to trigger or not trigger: mainly for demo purposes (“Compare the behavior here … with this happy wrap-on enabled here …”)
- Configurable pre-launch states to not only get the author to the point at which their behavior matters/will trigger (which should be covered with Rich’s save states coming in some undetermined far-fetched future), but to specify some kind of path to test various conditions quickly
- Able to execute behaviors on command with various arguments
What I don’t think Larry knew much about was that 3 already existed in a very primitive form that Mike put together. The problem was that it took just about as much time to set up as it did to get to that behavior in running the program (so it was only really useful for multiple tests), and the noise/situation of the surrounding behaviors was so complex that it was very rarely ever used because the behaviors you’d trigger either a. would never happen naturally in that scenario anyway and b. wouldn’t work because of improper set-up. So I guess I can see why Andrew was poo-pooing the idea of these tools: the one tool we tried to make was time-consuming, insanely buggy, and was never really used because of all that. Really, all we’ve determined is that 3 is going to take much more time and effort than our initial prototype to be really useful, and even then only questionably so since we’ve gotten along without it.
Ew, okay, that’s a bad response. “Gotten along without it.” Yeah, well Narratoria halved the production time of ICT’s authoring efforts. Over months, that saves a LOT of time for upfront investment. Authoring tools are very useful, but they are precision shots: they need to be like an acupuncture needle, sliding in harmlessly and seamlessly among the other production tasks to strike at a problem point and relieve pressure throughout the whole system. I need to outlaw that “gotten along without it” excuse as a dismissive and not helpful line of thinking compared to more helpful lines of critique:
- Upfront investment
- Disruption of other tasks
- Solving a crucial problem.
Aside aside, the check boxes idea is simple and easy to implement, but doesn’t help authoring so much as demoing. It could be seen as a simple way to start toward part 2 too. A worthwhile investment, but a bit shallow. So we have two radical ends of the spectrum with propositions that chip away at the problem rather than strike true.
Time to talk to Larry to hear these ideas in more detail, figure out which ones are going to get implemented, and where to go from here.