While I was in school for animation, I was inspired by Quill and the early artists and engineers at Lucasfilm and Pixar. The idea of building technology that pushed the boundaries of animation was extremely compelling to me— you’re not just enabling artists to create better work, you’re building the future of the medium. After interning with the Quill team and seeing how passionate they were about the same things, I knew— these are the kinds of people I want to work with, and this is the space I want to dedicate myself to.
When I got back to school, I felt the urge to dive into the creative tools space myself. What does it take to build an animation tool? How will we know if it works? From there, the goal was pretty straightforward: build a VR animation tool for beginners and make a short film with it to showcase what it could do. After eight months of work, my team and I would premiere the film in May and ship the tool the following summer. Here, I want to talk about the tool.
Knowing that there’s only so much we could do in eight months— since we were all full-time students— we had to limit our scope if we wanted to launch both products on time. That meant intentionally de-prioritizing a lot of things that make traditional animation tools useful for trained animators. As much as I wanted to import custom models, edit animation curves, and export animation data to another program, it didn’t make sense for us to build if our target audience didn’t care. The kids who used Ollie— who were brutally honest with their feedback— just wanted more models to play with and a way to animate objects by moving them around. That’s what we decided to build instead, and that’s what we shipped with.
To get a sense of what kids who tried Ollie cared about, check out Infinite Retina’s video below (Ryan starts animating about eleven minutes in).
I didn’t fully understand the importance of ignoring bad feedback until we started running out of time. Early on, I agreed with my peers and animation professors who gave us notes on Ollie— of course we should be able to animate opacity! Of course we need shortcuts mapped to the controllers! Though these bits of feedback came from a good place, they didn’t align with what our users wanted. These features didn’t make Ollie any more fun— in fact, they introduced layers of complexity that made the tool more difficult to use. As our deadline creeped closer, we knew we couldn’t afford the distractions if we wanted to ship on time.
I wanted to build Ollie and Trailblazer because I wanted skin in the game. I wanted to understand what it took to build a creative tool from the ground up and make something with it. In the end, because we did a pretty good job of defining our target audience early, we accomplished more than what we set out to do— aside from shipping on time, we ran demos in schools around LA, met others working on similar problems, and made a lot of kids happy. Personally, I learned how to use a new game engine, how to manage a team of students, how to prioritize well, and what I would do differently next time.
Dilution of effort crushes great teams. There are countless ideas that we could have spent time on, but if we tried to do everything that seemed interesting to us, we’d have a handful of half-baked features that wouldn’t fit nicely together. To build something worth releasing, we had to limit our attention and effort to what mattered most to our users, and that’s what got us to the finish line.