People often ask how I come up with my ideas for The Eureka Room, so I thought I’d share a little about that. The process can vary program to program but the steps below have been generally successful for me.
1) I brainstorm a lot of ideas. LOADS. I do this over a few days because each day I am in a slightly different place and have slept on the previous ideas. Over many days a few good ideas that appear to be good ones start to surface. I choose one that seems feasible.
2) I ask “what are the main physical mechanics and phrases” that are going to be fun for people to do and say? Again I brainstorm many more options on this. I can’t stress enough how important it is to generate a lot of ideas and not just settle on the first shiny thing that comes along.
3) At this point, depending on the program, I can either have people over to work on the mechanics or I do do a little development of a script. If I feel the idea has pretty good legs I’ll do the latter but only a draft.
4) From here I test with others if I haven’t. Sometimes we aren’t even in the room and it’s just paper and props. Usually the feedback indicates that I gut most of the idea I had and take the few gems we found during testing. That’s OK. That’s the process.
5) From here it is a lot of iteration between development and testing.
6) Music, Script, Lights, Sketches… what comes first? Well at this point, I find I’m better off writing the script. But sometimes I’m struggling with how to deliver the mechanics in the script and I instead jump to garageband to write some music that gives me the feel that I can sort of sense in the ether. Starting the creative process for an interactive film by first writing the music is probably not what most people would do. I doubt many movies have been written this way.
Starting with music really helps me discover what the program is about. It’s often as if I’m not really in charge of deciding what the program is, but instead I’m trying to uncover something that has already been decided by some universal force. I just have to find the right song that will lead the program out of the ether.
7) If I have some music then I will go to the script and see how that writing goes. Having the music inspires and directs the script. I might see that the length of the music doesn’t quite fit or that there’s a few distinct parts of the script that need different music. When I see that, I’ll go back to garageband to make the music fit a little more with the script I’m writing.
8) I should note that I’m also doing a good amount of testing with users in this too. I don’t want the script to get so far along that I’m working on lower level details and the testers haven’t given me feedback on the overall structure of the script yet.
9) As I move along, I’ll make up some visuals, especially the ones I feel are key to the script.
10) The animation can be a real time sink. Once I get into the details I try to repeat the mantra “THIS IS JUST A DRAFT”. I will for sure change a lot still so there’s no sense working on alignments and timing and smaller details until the very end.
11) Once it’s feeling 95% done, I show the almost final program to people who have never seen it before and get their feedback.
12) If that gets a good response, I clean it up a bit (but not too much) and ship it. Otherwise I do some revisions and test again.
13) No matter how much I think I’ve worked out the bugs, I still learn loads as I watch people enjoy the “final” program. Not everything works. But it’s not going to work for everyone. Before I make any updates to the program I try to first see if the person is an outlier or if this is a common problem with many people.