I realized that my previous posts were elaborating on stuff I already knew and dodging the questions I had yet to answer, so I’ve been focusing on those harder questions in the past week.
First, my advisers said that I needed “an underlying metaphor” to tie my story together. I raged against this a while. Was this a metaphor for what I was going to build, or what the author was going to be building? Why did I even need one anyway? And what kind of metaphor could possibly work without over-simplifying the process? What did having a metaphor provide me that I didn’t already have?
I realized that the metaphor was for what I was going to be building, since that’s what the advancement document is all about, so that question got answered. And after spinning my wheels and coming up with absolutely nothing, I decided to just pick a metaphor and go with it — the storyboard metaphor. James Skorupski used it for wide ruled/story canvas, and he had cited others (Pizzi, Jhala, McDermott, Goldman, and Ronfard to name a few) who had successfully used it. Of course, it works best for visual and spacial concepts: cinematography, game movies, scenes, machinima, or even comic stills. The more I read James’ advancement proposal and some of his papers, however, the more I realized the benefit that storyboards had to offer me.
James had a structure very similar to mine: branching stories. Instead of a player choosing to take the high road or the low road, the character chooses whether to speak or take a drink. Character behaviors are like microscopic mini-stories with little plot structure. I can use stills of character action instead of story action, and the user can still read the interpolation in the gutters of the panels. Movies even have punchy emotional or internal conflict/choices that they must show through storyboards, so it’s not like it’s a character-unique problem that some choices would not be easily visible. Michael’s first concern was the real-time aspect of the interaction, but once you cut up real-time action into infinitesimally small time steps, it’s still time steps. There are still decision points. We just have to account for more of them than most branching story structures.
So I guess it wasn’t the storyboard metaphor that really got me excited, but the research of all the people using it really made me believe that I could use it too. It helped me come upon the comparison of interactive story structure and character behavior-making mechanisms. James even had a zoomable, collapsable, hierarchical tree of story points that showed various information by its structure AND content — EXACTLY what I had planned to do. James also used ABL to handle the tree. I don’t know how I should feel about him skipping off to Ebay and not finishing his PhD, though >.> <.<
~~~ ***** ~~~
Then I talked in pod with Noah and Michael to iron out some more details on what the actual implementation would look like. I let myself go and had some pie in the sky dreams, which they had to ground me out in… Turns out that even though I ignore the method of input/output, it is still very important to be able to see the behaviors I’m trying to visualize. Procedural stick figures/procedural South Park would be a PhD in themselves, and I don’t want to get bogged down in thinking about the super low-level fundamentals. But at the same time, they feel necessary in order to work on a higher level that makes use of them! The further I get away from how people might actually want to use my authoring tool, the less likely that gap will ever get filled in by anyone, and the chance that my work might actually be relevant shrinks to near nothing. 2D or 3D is a huge question in and of itself, let alone all the troubles that each would provide. ARGH! I KNOW that I do not want just text, that much is certain.
I’ve previously focused on specific authoring bottlenecks to solve, both for IMMERSE (fighting with unity) and ABL (flat language: no classes, no built-in hierarchy) in general, and recently I’ve been doing some iteration on imaging cool authoring visualizations and structures. Now I need to tie them together. Something like… adding some code hierarchy as built-in idioms (with patching capabilities for when people want to make their own) and allowing the author to see the generally invisible strings that tie behaviors together would help code reuse (libraries!) and organization immensely. Even people who have written behaviors forget how they work later! I need to make the tool such that authors are given a “box” where their behavior must function within, and that can act as the library’s boundaries, rather than just hoping authors conform to those standards. Giving authors idioms and patterns to work with. “Reifying idioms” is Michael’s phrase for it.
Noah thinks that would be an interesting cut-off point for me to define. You have to go back to Eclipse to define new idioms. But if you want to work with the ones the tool understands, you work in the tool. And have some kind of mark-up for new idioms that allows the tool to hook into them.
Another angle of possibilities is the blank page problem: what motivates my character and why? You can author a character to perform some specific tasks in a specific domain, but you feel as if you’re reaching into the dark. There is nothing about ABL that encourages long-term motivation or emotional responses (for example), you just kind of have to feel it out and add it adhoc as you’re writing behaviors. Michael suggested Borrow Egri as a metaphor to have the tool guide you to fill in those missing pieces similar to Dramatica. Operationalizing the blank fields that authors would plug in within the tool.
Can we ignore unanticipated interactions/take it as a given? Aim instead for describing higher-level stuff? The “picking up coffee cup” problem is not on the ABL side, but more on the engine side. It’s Unity and those kinds of engines that have trouble doing anything other than running and shooting. They simply aren’t made to, for example, hold a coffee cup such that the liquid inside wouldn’t spill everywhere while the character moves. There is no gesturing, there is little object attachment, there is no sitting in chairs. It’s all fudged. Docking is hard (Assassin’s Creed team is focused on making the tech to do it. Years and tons of people to make free running look good. And they aren’t in engines by default. What would happen if that amount of tech was put into dramatic performance? There isn’t gameplay around dramatic performance as an industry standard.). Another team spent 6 months trying to get characters to sit in a chair/stand up without it looking horrible.
The weird animations is not an authoring problem in terms of ABL, it’s an authoring problem in terms of the engine, which was never built to afford anything other than FPSes. It just becomes an ABL problem when we try to baby and bandaid the shortcomings and edge cases of the engine. AAA games have horrible leer-y rubber masks or put helmets on everyone.
But storyboards means that you don’t necessarily need to animate it. Maybe just show it in Unity and not worry about it not looking too good (IT HURTS!)? Maybe simplify it like Storyteller? Noah’s suggestion: Start with the authoring stuff. By the time I’m getting along with the authoring stuff, there may be some project that I want people to author for. And then worry about the visualization of the actual output by then. But I NEED to have behaviors to test them… Argh!
Lots of stream of consciousness stuff there as I listened to my recording of Michael/Noah’s feedback. The best part of having Michael recordings is listening to him do raspberries as he thinks :).