The Bluecadet Blog Takeover Series: Powering the Magic of a Choice-Driven Comedy
Hi!
We’re Bluecadet and we’re taking over the eko Engineering blog to talk about our work on Wizard School Dropout.
Wizard School Dropout is a choice-driven comedy about Andy, a young witch who defies her parents, quits Glimdrang Academy, and has to figure life out in non-magical Los Angeles. But since Glimdrang doesn’t really prepare you for things like getting a job or paying rent, Andy needs viewers’ help navigating work, friendships, spells, and preventing a little bro-pocalypse — all before losing a piece of her soul to her creepy landlord.
Wizard School Dropout is a collaboration among eko, Walmart, and EffinFunny. The Bluecadet team was tasked with the design, game mechanics, user flow, motion design, and development of the show.
What do game mechanics and user flow have to do with creating a comedy?
Wizard School Dropout is not your average TV show. It’s a choice-driven video series on the web. Viewers have to decide Andy’s next moves, help her cast spells by playing mini-games, and collect magical artifacts. How well they do this determines what powers Andy develops, how much money she makes, and the nature of her relationships. Wizard School Dropout is part live-action show, part game, and the users are part viewer, part player.
Creating this sort of complex yet immersive entertainment experience was not easy. There’s practically an infinite number of Wizard School Dropout versions one can play through.
Beyond storylines we also had to tackle some significant technological and logistical challenges to pull everything off.
This article is a quick overview of the technology. We’ll go in depth into logistics, game design, visual effect rendering and other cool stuff in our next posts, so stay tuned.
Is this technology, or is this magic?
Wizard School Dropout is a complex web experience. To build the Wizard School Dropout world we had to use a bunch of different tools in tandem.
The eko platform is the technological backbone powering the interactive video playback and seamless decision making. Eko gave us the ability to plan out and implement all of the show’s branches; the choices you make, places you go, people you meet — all these different narratives are organized and tracked on the platform. It also stores information and helps track your progress and stats throughout the series. Without eko, we could create all the mini-games we wanted, but the results wouldn’t matter to the story.
We used React for most of the UI, including graphics, animated buttons, and the various progress and energy meters in the show.
We also used a library called Pixi, which enabled us to do some more advanced visual effects and graphics. These include the more complex interactions in the show. For example, it is Pixi, combined with some custom shaders we wrote, that allows you to draw a rune and have it sizzle and flare up underneath your finger.
To sequence out complex animations, we used GreenSock.
From a tech point of view, the fact that everything is timeline-based was a big deal. One of our challenges was that both Pixi and GreenSock have their own timelines, but we needed the eko video player to be our ultimate timekeeper. Part of our work was wrapping up Pixi and Greensock to obey eko’s timeline.
We realized very quickly that we were making a game, and that’s how we needed to approach the work. Building software and games, there’s a particular flow for thinking about logic working and dealing with questions like, do animations pause at the same time you pause the video? Or, what happens to your app state when rewinding to a previous choice moment?
Really, this was even more unique than a game since it’s fundamentally first a passive and then an active product. We had to think about how these different elements, like game mechanics, could build on each other.
From the coding standpoint, all the potential choices that a person can make have an effect on what state the code is in and what might happen, which is why one of our biggest challenges was QA and debugging.
Testing in progress
Testing a layered game experience that built up over the episodes made testing and debugging an interesting task. Let’s say you want to test one particular animation, you can’t always watch those first 10 minutes until you get to that point. So, how do you test something you just quickly want to iterate on over and over? Similarly, how do you test all the different narrative options?
The hardest bugs were when there was a sequence of decisions, game results, or a bunch of interactions built over many episodes. We might find a bug and then have to trace back the viewer’s actions across five episodes to determine the root cause.
An excellent example is the money meter, which could suddenly revert to zero. Now, this isn’t real life; you can’t suddenly be out of money on episode 5. We had to ask ourselves questions like “Did they work in this episode?”, “Did they not work in this episode?” “What did you play before?” “Where was the money supposed to be at?” Trying to track these down was extremely difficult.
Our senior developer, Nick, built a Swiss army knife to preview and test features. Those were essentially layers that we added on top of eko’s platform. We used a library called dat.GUI, a convenient control panel that you hook up to the software and expose its internals. Eventually, it evolved into two layers, one where we could add something to the URL and it would pop up, and the advanced dev-only layer where we kept all our secrets.
It was great for design tweaking, which can be such a time sink. Our team would just sit down next to each other and tell Nick, “Can you make it more like this?” And he’d be like, “Let me just turn up the dial.”
It allowed our team to link directly to specific moments in the show and fast forward until right before a decision. But it also gave people a place to fine-tune and adjust the difficulty of a game, the speed or color of an animated part of the UI, sound behavior, and the visual effects on screen.
Every aspect, from the core logic to game behavior, interaction, and visual effects, was exposed for multiple rounds of fine-tuning thanks to Nick’s tool.
Magic moments
Bringing a choice-driven show like Wizard School Dropout to life was no easy task. Still, our team brought all our water, air, earth, and fire elements together to create magical moments, like movers being punched by a table on episode 1 or a grand reveal at the end of episode 12 (we won’t spoil it for you).
In the meanwhile, you can play Wizard School Dropout here :)
