How knitting inspired the clone-based gameplay of The Last Clockwinder

The Last Clockwinder sees players creating clones of themselves, steadily creating a clockwork of robots executing their exact last action in order to solve massive puzzles. It challenges you to think about how you would turn yourself into every step of a complex machine to solve the challenges at hand.

Game Developer spoke with John Austin of Pontoco, the development team behind the title, on how they created an experience that would involve dozens of clones of the player and what problems that might cause, the thoughts behind making a hopeful world to solve puzzles in, and about how the process of knitting would lead to the cloning ideas in the game.

Game Developer: In The Last Clockwinder, players use clones of their actions to slowly build up mechanisms to solve puzzles. What inspired this idea?

Pontoco: The idea actually goes back quite far to about 2016. At that time, we were in-between projects and had been discussing ideas for prototypes in the meantime. One of us in the group was an avid knitter, so we had been thinking about knitting games. Knitting is essentially the process of repeating simple actions over and over again, and what better way to do that than with copies of your own actions!

The knitting idea eventually dropped away, but the cloning idea stuck. We spent a few months making a prototype of The Last Clockwinder for the original HTC Vive, but unfortunately, the time wasn’t right for us to pursue the project then. It wasn’t until 2019 that we picked the project back up full-time and began to develop something closer to the final game today.

One day I still want to tackle that knitting game though…imagine slinging around giant noodles to make a scarf [laughs]!

An early 2016 prototype. The cloning back then was a bit chaotic…

What interested you in doing this in VR? What do you feel added to the experience?

Interestingly, we were never explicitly looking to make a VR game. Rather, it was just that, from the beginning, it was abundantly clear that VR was the best embodiment of this mechanic. There’s something so authentic about seeing a clone of yourself, with all of the messiness that entails. And of course, it naturally leads to a lot more creativity. So, when we hit on this mechanic, we knew we had to do it in VR.

VR is also inherently “sloppy”. It’s an imprecise control mechanism! You’d have clones that started to pile up boxes and just never stop. Or clones that bumped into each other or stole objects from each other's hands. This can be both hilarious and sometimes extremely frustrating [laughs]. So, we spent a lot of time trying to find a balance between embracing this sloppiness and building a tight puzzle-solving experience.

In the end, I’m very nostalgic for some of the wilder, chaotic versions of the mechanic. But of course, the game has to ship!

What challenges came from creating copies of player actions? In programming the clone mechanic so that it could copy what the player did?

One major challenge we faced was keeping the clones ‘deterministic’, aka “clones must do exactly the same thing every time.” Every single bounced ball or tossed knife must follow the exact same arc, down to the exact decimal place. Otherwise, imprecision will begin to build up.

You can think of it a bit like a snowball rolling down a hill. A small difference in the first push can send it on a wildly different trajectory. Our clone machines are like that. A missed throw can snowball into an entire machine breaking down.

Unity, as it turns out, is not very deterministic out of the box. So, solving this problem required a long, multi-pronged effort to make the Unity Engine more deterministic. I’ve personally spent many months in the guts of the engine, working to diagnose these ‘determinism’ issues and building out a suite of tools to catch bugs.

Input recording was also quite the challenge: rather than recording the high-level player actions (i.e. positions of hands, grabbing interactions), we record the raw input buffers of data coming from the controllers. When playing back a recording, we create ‘fake’ input devices for each clone and attach them to the game like normal. So, with 25 clones running, the game sees 25 separate VR devices connected all at once! Every clone is simulated as if it were a real player.

Approaching it from this angle is incredibly freeing: no custom logic is necessary to integrate a VR mechanic with cloning. It ‘just works’, so to speak, because all of the cloning is happening under the hood.

What thoughts went into designing the puzzles/activities that inspired players to be creative with their actions? That would work with a clockwork mechanism made from human actions?

We spent a long time prototyping different mechanics! Grabbing and manipulation are some of the fundamental building blocks of good VR, so we were always drawn to mechanics that played with those interactions. What if you can’t grab the fruit (Dewshots)? What if the gravity was reversed (Luftapples)?

For creativity, we always knew we wanted a ‘construction’ system which players could use to combine multiple fruit types together. Unlike most puzzle games, we wanted there to be many different solutions--and when you allow players to combine these fruits with different physical properties, that makes for a really interesting design space.

This turned into the ‘toothpick’ or ‘bonding’ mechanic. It went through 5 or 6 different iterations before we settled on the final design!

(One of my favorite player-built machines is the person who made a giant shovel!)

What unique difficulties came from coming up with puzzles/activities that would work in VR? How did you resolve these?

There are lots of great, weird interactions in VR, but not all of them make for interesting clockwork machines. Many of our prototypes were fun in isolation, but not necessarily good building blocks for creativity.

For example, a satisfying machine needs to have elements of repetition. It feels much more clockwork to see 20 clones passing a fruit down a long chain than a single clone doing one task. So, we ended up focusing on simpler mechanics that could be composed together, rather than multi-staged complex ones.

How did you make those puzzles feel like a part of a lived-in space?

This was always a challenge! An early goal of our world design was consistency: that the world of the game could exist as a plausible place, even if it was nothing like our own.

To that end, we imagined three layers of technology in the Clocktower. First, ancient technology that was thousands of years old. This is the stuff that the Clocktower was built from, and powers all the level selection/room movement mechanics.

The second layer was “Constructed Technology.” These are hand-made objects that were built over the years by the people inhabiting the space: a reclaimed space between pipes turned into a workshop or a kitchen built into the hollowed-out portion of the trunk. This sense of reclamation was a big part of how we designed for the lived-in feel.

The last layer was “Modern Technology”: laptops and displays that have been jury-rigged into the space. You can see this in Edea’s laptop, which is strapped onto the ancient technology of the room selection machine. These are all devices that have been brought to the Clocktower, and in many ways, we wanted them to feel a bit profane. These digital devices are not really of this world!

Concept art during our iteration on the clone arm design.

What drew you to the visual style for the game?

One of my personal goals with this game was to make something in opposition to existing automation tropes of factories, industry, and harsh technology. It’s just all a bit thematically dry. We have the ability as game makers to make anything we can imagine--why is it that all we can imagine is what already exists? I want to make games that are visions of the types of worlds I want to see: hopeful, messy worlds that hold some hint for how we can better shape our own.

Maybe these are lofty goals, but if we’re going to dedicate a large portion of our life to building games, I feel like it’s worth it to try. So, we aimed towards the opposite extreme of a factory: a soft, organic, natural style, and a narrative focused on how engineering interacts with the world and people around you.

But of course, I can’t take any credit for the visuals themselves: we brought on Anita Tung early on as art director. Her art has a warmth and authenticity to it that really shaped the way the game developed. She’s always been one of my favorite artists, so I was delighted when she accepted the spot. Anita did a fantastic breakdown of the visual style here!

What ideas went into creating the looks of the robots that would be acting out player actions? Were there any feelings you wanted to evoke with their appearance?

We wanted them to feel a bit inscrutable. Here are these robots that might spend years repeating the exact same things over and over again. There’s a sort of wisdom or reverence there, like an old writing desk. Throughout those years, what has that robot seen [laughs]?

We also explicitly designed them to feel non-sentient. If you think of these robots as too intelligent, it starts to be a bit sad to be tasking them with these endless looping tasks for the rest of their lives. There’s some tough themes to unpack there [laughs]. So, we worked to make them more intentionally constructed rather than seeming like artificial life forms.

This also informed our focus on the narrative being about the human characters. We intentionally avoided the subject of machine intelligence. Although, with the way the world is moving, perhaps we’ll have to come back to that theme at some point in the future. No promises!