Crankin's Time Travel Adventure is a quirky, perplexing, and downright brilliant dating game for the Playdate that sprung from the mind of Uvula, the studio co-founded by Katamari Damacy creator Keita Takahashi and veteran animator Ryan Mohler.
Uvula was assisted with development by Panic engineer Shaun Inman -- who also masterminded Playdate's in-browser game engine, Pulp -- and sound designer Matthew Grim.
Given the secretive nature of Playdate development -- Panic wants to keep most of its Season One releases a surprise -- Crankin' has become something of a poster child for the equilateral console, and has been featured heavily in trailers and promotional shots due to its emphasis on placing the iconic crank front and centre.
In-game, players can rotate the Playdate's attached crank forwards and backwards to advance or rewind Crankin's timeline, helping our drowsy protagonist avoid obstacles as he attempts to meet his darling Crankette for a series of very important dates.
It's a simple premise but one that's elevated thanks to some delightfully expressive animation and novel design elements that makes the most of the title's unique control scheme and Playdate's modest screen real estate.
Speaking to Game Developer last year about the journey from design doc to download, Takahashi, Mohler, and Inman broke down some of the more unique aspects of developing for Playdate with a view to helping other creators follow in their footsteps.
Like many Playdate maestros, Uvula began production on Crankin' before they had access to hardware. While that in itself wasn't a huge concern due to the Playdate SDK being pretty robust, it did mean the team had no way to preview crank inputs in the real-world.
Some developers I've spoken with ultimately decided against making the crank do heavy lifting for that reason, but in the case of Crankin' that simply wasn't an option. To find a workaround, the dev team managed to use the right analog stick of a gamepad to simulate the crank in tandem with the SDK, which captured the variable speed metrics needed to fine-tune the control scheme. Inman recalls how the team spent that much time testing the feature, the rubber eventually completely wore off the thumbstick.
Still, with no hardware in sight and work underway, Takahasi wanted to ensure production ran smoothly by pulling together a crystal clear plan. To that end, the veteran designer rustled up a comprehensive design document (dated November 2015!) littered with details explaining everything from how the core cranking mechanic works -- "this game’s mechanic is like an old type film projector, all his animation and behaviour are present" -- to early enemy concepts that were eventually tweaked to make the title more family friendly.
For instance, at one stage Crankin would've needed to dodge knives being flung at him by some off-screen murderer. In the final game, these take the form of butterflies that, while equally deadly due to their poisonous powder, feel decidedly more wholesome when on-screen.
The design document also reveals that Takahashi flirted with the notion of other hazards including but not limited to the police, vehicles, and "flying poop." How many of these made it into the final product remains to be seen.
Are you having a wind up?
Chatting about how time manipulation works in the 2D space, Inman explains how there are two timelines in the game. "You have one timeline that enemies are on. It's always moving forwards and time is constantly elapsing. Then you have the timeline that Crankin and Crankette are on, which is powered by the crank," he says.
"[On this timeline], you only advance it as you crank, and that's dependent on the speed of the crank. So reconciling those two timelines broke my brain for a week, but we eventually figured it out."
Inman also recalls how another big issue the team ran into concerned memory management. He says that, early on in development, there were "a lot of issues" with bandwidth and actually accessing the files needed to ensure the game could stream frames of animation as quickly as players could crank them out.
"The initial look-up to locate the file on disk took a really long time. So we couldn't load each frame at a time, which meant we had to create these big, individual images that I had just packed into a single file," says Inman, explaining how each of those files are essentially film strips.
"I would allocate a huge chunk of memory for that, and then in order to avoid memory fragmentation, I would just load the files into that chunk. So I wasn't actually using the SDK to load the files, I was doing it all myself to get around those problems. That was challenging for me, because I'd never done anything that low-level before."
Blending animations with Crankin's filmstrip-style levels was another challenge that Inman struggled for resolve. He explains how all the actions in-game are fixed animations that cover (or don't) a fixed distance along one or more axis, which means that describing the layout of levels in an easy-to-parse, easy-to-edit way proved difficult.
To tackle the issue, Inman wound up creating a custom level editor where the team could sequence together actions and lay them out visually based on the unique attributes of each individual action.
"For instance, when you choose the 'run' action, it will render the correct amount of ground beneath Crankin for one run cycle in the direction he’s currently facing, same for stairs and all the other props," said Inman, who also shared an image of the editor (pictured below).
Allowing players to manipulate the speed at which Crankin's timeline elapses also required Mohler, who was tasked with animating the project, to create "hundreds of frames" for the basic run cycle. He recalls how the interactions between Crankin' and Crankette took a lot of work to animate, especially when it came to conveying emotions with clarity on such a small screen.
Certain expressions, for instance, are accentuated to help players track the moods of Crankin and Crankette. "That was happening a lot initially. We scaled the characters' eyes, for example, so if the head turned a little bit I had to scale up the eyes to make sure you could still see them -- or having them squash as they blink. It only ends up being around three pixels tall, so you don't get a lot out of it, but it's just enough that you see some expression there," continues Mohler.
Despite those limitations, Mohler was full of praise for sprite-based animations and suggested that some of their inherent constraints actually delivered more unique results.
"Sprite based animation is pretty standard. It's been around for a long time. Having that be a constraint in the way you have to layer these sprites on top of each other in Atlas and play them back, it gives you a lot of freedom to pick and choose which frames you're showing," says Mohler.
"I think talking about constraints in game development often results in us chatting about them as limiting factors, but they actually ease you up to worry about the right things. Yes, you hit a hard wall and you say, 'well, I have to work around this.' Part of the problem when we were working on Wattam was the number of variables that we had to try to control -- and the fewer variables, the more constraints, and the easier it is to solve problems."
Rules? What rules?
As our conversation draws to a close, I ask the Crankin' trio what lessons they'd pass on to developers eagerly sizing up the Playdate. Mohler reiterates his previous advice: remember that constraints aren't limitations, so analyze whatever barriers are ahead of you and use them to create something unique.
For Inman, it's all about the Playdate SDK and the flexibility it provides. He notes the SDK comes in two flavors -- Lua and C -- so developers should remember that switching between them is always an option if they get stuck in a rut.
"If you're using Lua and run into performance problems you can always jump over to C -- either as an extension that your Lua game can use, or as just a standalone C game. That's what we ended up doing for Crankin," he says. "It started in Lua and then we moved to C in order to accommodate the bandwidth, and overcome the memory problems we were having. There are usually multiple ways to attack the problem."
As for Takahashi? His advice is more universal. For the Wattam and Noby Noby Boy creator, the rule for any developer -- whether they're working on a Playdate project or otherwise -- should be to remember there are no rules.
"Maybe there is no definition for what a video game is. You don't need to make a rule. There is no rule. You need to entertain people, not only yourself -- so it shouldn't be masturbation -- but you don't need to care about what other people say. Trust yourself, and if you think it's fun, then you should do it."