The challenges of laying worlds upon worlds in puzzle game COCOON

The IGF (Independent Games Festival) aims to encourage innovation in game development and to recognize independent game developers advancing the medium. Every year, Game Developer sits down with the finalists for the IGF ahead of GDC to explore the themes, design decisions, and tools behind each entry. Game Developer and GDC are sibling organizations under Informa Tech.

COCOON sees players carrying worlds within worlds, capturing whole puzzling realms in orbs that can be combined into one another to solve ever-more complex mysteries and traverse alien worlds.

Game Developer sat down with Jeppe Carlsen, Erwin Kho, and Jakob Schmid of Geometric Interactive, the game’s developer, to discuss the development challenges that came from having so many worlds layered on top of one another, the ideas behind some of the unique worlds that didn’t make the cut into the game, and how the idea of creating “fun toys” helped create interesting boss battles.

Who are you, and what was your role in developing COCOON?

Jeppe Carlsen, director and designer: My name is Jeppe Carlsen and I am the game director and game designer on COCOON.

What's your background in making games?

Carlsen: I have a master’s degree in Computer Science, and during my studies I got particularly interested in discrete mathematics—the branch of mathematics that focuses on foundational mathematical concepts such as graphs and formalized logic. When I started working with games, I think this interest in discrete mathematics made it very intuitive for me to go into puzzle design; I started to practice at Playdead during the development of LIMBO.

Images via Annapurna Interactive

How did you come up with the concept for COCOON?

Carlsen: I often daydream about mechanics for games and one day this idea popped up: What if the different levels of a game were also objects which you could pick up, and then you had to bring these levels into each other to solve puzzles? And what if the levels were not simply small rooms, but entire worlds each with their own biome and mechanics? The idea of carrying entire worlds (within worlds) in your backpack was too fascinating to me and a game had to be made.

What development tools were used to build your game?

Carlsen: Unity.

COCOON involves switching between worlds to solve many of its puzzles, steadily stacking whole realities into orbs. What development challenges came from creating a system of compartmentalizing whole game worlds?

Carlsen: This idea of having worlds within worlds affected the production in many ways. Linear games have a lot of advantages when it comes to dynamically loading and unloading scenes and content, but even though COCOON is technically a linear game, our loading systems had to be a lot more complex since we need the game to be ready to jump between completely separate worlds in a matter of seconds.

I think the bigger challenge, however, was design-wise and how to structure the adventure through the worlds with[in] worlds so the player would never feel lost. In COCOON, each puzzle room has more context than simply the room that comes before and after it. In this game, I also needed to think about the available rooms in all the other worlds which turned the entire level design into a giant layered puzzle in itself and I constantly needed to “zoom out” and consider the bigger picture.

Another development challenge was when you needed to test a specific puzzle that you were working on, since you can’t simply place the player character inside the puzzle and press play. You need to prepare all the relevant rooms in the other worlds, too, and you need to place the orbs inside each other so everything is in the correct state. This was a massive hassle and for a long time it was probably only me who was really able to do this. So there was a lot of “Hey Jeppe, I need to test this room I made art for.. (Sigh).. what do I do?” going on [laughs]. Late in production we, of course, had a save system that made it a lot more convenient to jump around in the game, but it was not feasible for us to make and maintain such a system until the levels had started to settle into place.

Can you tell us a bit about the process of designing puzzles around this system? About how you designed one of the puzzles you're particularly proud of, from start to finish?

Carlsen: The puzzle I am the most proud of is a late game one that introduces a paradoxical twist to the core rules. I really like how the entire game leads up to this moment, and how the puzzle logic is just complicated enough for most players to not fully grasp the consequences of their actions. It usually goes a bit like: “So I guess I am going to place this one here, and then go here, and do this, and now.. WAIT a minute, what have I done!?” I love when a puzzle has a bigger payoff than simply the satisfaction of figuring it out, and this one makes some players burst out laughing, and some players even stop moving the character for a little while because their brain is trying to catch up. Seeing these strong reactions to what is, essentially, just a surprising consequence of logical rules is hugely satisfying to me.

Designing this puzzle and making sense of its paradoxical consequences was a fun mental exercise for me during development. I came up with the idea fairly early on, but interestingly enough, I did not actually prototype it for several years, but instead simply kept thinking about it. Almost as if it was a game design “joker” which I kept on my hand, and which I knew had the potential to elevate the entire game to a fascinating logical climax. When I finally one day (at home during Covid) decided it was time, I prototyped the entire thing on a single day and it translated perfectly from idea to execution.

Images via Annapurna Interactive

In a previous interview with Game Developer, you mentioned that a kind of 'mental staircase' was created to gently teach players the increasingly complex rules and capabilities of the worlds-within-worlds puzzles. Can you talk a bit about how you developed this process for the players? How you found ways to teach this mind-bending puzzle concept in steps?

Carlsen: Initially, the game simply asks the player to become familiar with the world-jumping mechanics without there being any puzzles to be solved. The game never explicitly explains anything to the player—instead I design each room for it to be as accessible as possible for the player to make their own discoveries about how things work and what is possible. Everything from how to jump in and out of worlds and where you land within a world, to the fact that you can bring orbs containing worlds into other worlds is all left for the player to discover by themself.

When I start to introduce worlds-within-worlds logic puzzles, I order them so that each one is always only slightly more complex than the previous, slowly giving you a deeper understanding of how to use these mechanics. I observed that if I did not teach these concepts very carefully, then the player would often get overwhelmed and frustrated. The linear nature of the game means that if you get stuck at a puzzle, then the game comes to a halt, and you can rightfully start to wonder not only if you are looking at the right problem, but furthermore if you are looking at the right problem in the right world. It’s never fun to get really stuck in a linear puzzle game, but in COCOON, I felt that it got even more frustrating than in most games.

Likewise, can you tell us a bit about how the team taught themselves to think around this complex puzzle mechanic? How they steadily immersed themselves in its capabilities in order to create interesting elements around it?

Carlsen: I think the team members wrapped their heads around the mechanic much like how the player does in the final game—simply by playing the puzzle sequences I was stitching together. Even before we had a team in place, there was a fairly long 2D prototype and the first team members played this prototype to get an understanding for what we were making and how to think within a worlds-within-worlds structure.

Were there some puzzle ideas that you designed that did not fit into the game? Can you share some of those ideas with us, as well as why you felt they didn't fit?

Carlsen: We had a “rhythm orb” in the game for a long time which would rhythmically toggle on and off. If this orb was placed on an orb switch connected to a door or a lift, that door or lift would move rhythmically back and forth. Within the rhythm orb world, I planned to design a room in which you could alter the rhythm, and this could create some really interesting puzzle possibilities. However, each orb ability in the game is only used occasionally in the level design, and I did not find a way for it to not feel distracting to have this one orb turn on and off constantly in rooms where the rhythm was irrelevant. The rhythm idea also had a slight “digital” feel to it that ended up clashing with the organic visuals in the game.

We also experimented with some stealth sequences where the player needed to get passed patrolling “guards.” Conceptually I really liked how if you got caught, you simply got thrown out of the world, but I struggled a lot with getting the gameplay right. Ultimately, I concluded that it was a bad fit—probably due to the controls of the game being so simple. The basics of using only the left stick to dodge the guards was just too simple for its own good. The stealth concept was ultimately replaced with boss fights where we retained the idea of throwing the player out of the world as a fail-state.

What ideas went into the various abilities that are contained in each orb? How did you design these useful abilities, and how did you make them fit in with the greater world-shifting puzzle whole?

Carlsen: The first orb ability you unlock allows you to manifest invisible bridges, and this was also the very first ability I prototyped. It works well as the first one since it is visually appealing and also very simple. My partner Jakob and I discussed that it would be best if the rest of the orb abilities were more interactive in contrast to this first one, and this became a focus for me going forward.

In COCOON, you cannot jump and simply running around can get a bit monotonous, which is why the game features jumping pads and other mechanics that enables the player character to get off the ground. The traversal however remains a bit “flat” which led to the design of the second orb ability where you can toggle the state of specific vertical towers and then ride these towers up and down.

In COCOON, it can also be a bit tedious when you are forced to fetch an orb at a previous location, and this observation led to the third orb ability: what if a specific orb cloned itself into all these hatch-able eggs, and suddenly the orb was available everywhere? The final orb ability is the ability to fire a projectile which can not only hit a target in front of you but can furthermore travel into other orb worlds and hit targets within. This ability was from my very first 2D prototype, and throughout the production it remained my vision for a late game culmination of the worlds-within-worlds mechanics.

Images via Annapurna Interactive

You also work bosses into the puzzling experience. What thoughts went into creating some of the boss battles in COCOON?

Carlsen: COCOON is a very chill game, which I love, but having an element of occasional danger and stress felt like a nice contrast. This contrast was my first motivation to pursue bosses (and the stealth sequences I attempted before the bosses), but later on, they ended up strengthening our narrative ideas and even inspired the ending. I designed and built the first boss by myself as a proof of concept for what a boss fight could be in this game, and after that I teamed up with game designer Asger Strandby who took the lead on the next three bosses.

The first boss is very simple and only involves running around while dodging attacks and then attempting to catch a bomb which you can detonate to damage the boss. Asger and I discussed that it would be good if all the remaining bosses somehow introduced a new take on player movement, again as a contrast to all the time spent simply running around in the game. We focused on designing “fun toys” for the player to play with and built the boss designs around these toys: a water jetpack-like orb in the second boss, a mirror-teleportation orb in the third boss, and finally a dash orb in the fourth boss.

What thoughts went into creating the various worlds so they could easily be told apart, visually? Likewise, what ideas went into creating so many alien worlds so that they felt different, yet cohesive to the whole of COCOON?

Erwin Kho, art director & lead artist: The color coding of the worlds was actually something that was already established in the prototype that Jeppe and Jakob made. It made sense to have the worlds' colors stay close to the color of the orb so that you don't get too confused. But then the fun part in the visual design was to make each world have their own distinct personality.

I quickly decided that the orange world should be filled with tall spires and canyons, since that orb’s ability would manifest bridges and that would make a lot of sense if you included height, cliffs, etc. Therefore, images of the Grand Canyon came to mind. The green world was conceived to be the opposite of that—a place that’s much more flat and lush, so I looked into wetlands, mangrove forests, beaches, etc. The industrial world was, at first, conceived to function like a hub world that would link all of the other worlds together, so I thought a gray color scheme would be fitting. That way, any other orb would stand out as a bright colorful gem against a neutral color background.

It’s these decisions of biomes that helped us pick recognizable shapes to help distinguish the worlds, which, together with their color scheme, help the player orient themselves within the world hierarchy.

The elements that make COCOON feel cohesive very much comes down to the visual style & the designs: In terms of style, the game uses a certain way of low-poly modeling and stylization that is very consistent throughout the game. The same is true for the rendering & lighting model, implemented by our colleague Mikkel Svendsen. Even though the vibe and atmospherics are very different per world, they all still very much look like they belong to the same universe. And, in the case of the designs, there’s the same alien technology spread across the worlds, so that also helps you to understand it’s all connected.

Can you also tell us a bit about the sound design of the game? What thoughts went into creating alien soundscapes for the various worlds players would explore?

Jakob Schmid, programmer and composer: Early on during development, I was experimenting with writing software synthesizers that would run in the game and generate the music in real time. COCOON is a puzzle game where players could have long 'thinking breaks' and that’s where it’s extra important that the music doesn’t call attention to itself with obvious loops. I also liked the idea that generative music could give players an experience that was unique to them, even if they never realized it.

Based on those ideas, I started thinking about sound design aesthetics and what would fit the synthesized soundtrack, ending up with the idea that sound effects generated with synthesizers should work perfectly. In my mind, these synthetic sounds also fit Erwin’s visual aesthetics quite well—artificial, yet vivid. Drawing from my earlier experience with creating the sounds for Jeppe’s and my earlier game 140, I convinced myself that it was possible to make sound effects for the entire game only using synthesized sound without using any recordings. Later on, we would hire our amazing sound designers Julian Lentz and Mikkel Anttila who took this strict concept and elevated it to great heights. They synthesized wind, rain, thunder, footsteps, mechanisms, otherworldly devices, and the voices of alien lifeforms out of thin air. Our worlds ended up being brought to life by synthetic sounds, creating a unique atmosphere for a unique game.