"We always tried to keep the terrain intact through worlds, and only putting different elements on top to create gameplay."
The multiverse is in vogue. Everyone from Hollywood producers to game developers big and small have become fascinated with the notion of parallel worlds and the variations within. As a result, turning the increasingly well-worn concept into something that feels genuinely novel has become something of a challenge, but it's a task the developers behind What Lies in the Multiverse have risen to with aplomb.
A narrative puzzler about worlds turned inside out, What Lies in the Multiverse utilizes a dimension-shifting mechanic to great effect, letting players blink between existences to unravel a mystery that extends beyond one reality.
It's a testament to the development team that, in motion, flitting between worlds appears almost rudimentary, with one universe giving way to another in a matter seconds. Of course, working that magic behind the scenes was anything but, so we caught up with What Lies in the Multiverse creative director Vicente Aguiló -- one half of development team Studio Voyager -- to learn how the mechanic was wrestled into existence.
Game Developer: How did you conceive of the multiversal mechanic and what did it look like during the early stages of production?
Vicente Aguiló: The idea came to me after playing Pocket Mortys. It was just a silly little mobile game to make fans of the show happy (and it worked for me!), but I still felt a bit disappointed by how they used the whole concept of parallel universes. In that game, you just used portals to travel to different worlds, but they'd only differ in colors and minor stuff that had no real meaning. It made sense though since it was a small game and that wasn't the core of its gameplay, but I wanted to try something more meaningful with the idea.
I tried some concepts at first, but they were all just a big mess. The first fleshed out concept was more like a point and click game, where you could switch between universes with very small differences, so you had to investigate them by yourself and take notes that would help you understand them and progress through the story. A silly example from the beginning was to go to a universe where your dad passed away (something you had to find out by yourself), so you could take his car keys to your normal universe where he wouldn't let you use his car (yup, some stuff didn't change much). Except for the fact that I never got to implement that mechanic in the game, it was fun!
How did you iterate on the mechanic to shape it into what players see in-game? What were some of the most challenging parts of that process, and how did you find solutions?
Vicente: It was a pixel art point-and-click game back then, and because of that it had a much larger resolution, like three or four times what it is now. Considering I was just learning how to draw pixel art, not only was the result really ugly, but drawing trivial stuff like furniture consumed a lot of time, so I had to scratch that if I wanted to actually finish something. I then tried to study some simpler art styles I liked, like FEZ, but the lack of detail made it kind of impossible to continue with a point-and-click, so I thought that making a platformer where you switch universes on the go was the best fit for what I could do.
The challenge was, of course, learning how to make a platformer with its rules and design, and since I was just learning how to code, that took a very, very long time. Allowing the player to float in water correctly took a month at least! But by the time Oscar (our lead programmer) joined the project and basically saved our lives, I was fluent enough with GML that I could help from time to time with minor stuff. The technical development was a lot smoother from then on.
Did you manage to execute on your original vision, or did the mechanic morph into something different along the way?
Vicente: The biggest difference from the original idea is the number of universes you can go to at any moment. At first, the idea was to add a universe to your arsenal every chapter or so, having around five different universes at your disposal at the end of the game. The system for that is in the game too. We just never ended up using it. By the time I was making Chapter 1, I learned how difficult it was to make two versions of every single place you could go to, while also having different mechanics and narrative changing at any point. It took too much time, and imagining it escalating to three, four or five different versions for every place only fuelled my anxiety.
Not only that, but I noticed how hard it was for some people to get used to switching between two worlds. Back then it was more related to the level design (which sucked) but imagining people new to the game switching between more than three or more universes when two were already complicated. It was a sad decision to make, but it was for the best. We could focus more on quality over quantity and make more interesting worlds for the player to explore! And it also made our lives a bit more bearable. That was nice.
The numbers were supposed to increase as you got access to more worlds! You had a button to go to the next universe, and a separate button for going to the previous one. It got messy really quickly.
It's easy to talk about what went wrong during development, but what went right? What was one of the biggest success stories of designing the dimension-hopping ability? Something you absolutely nailed as a team.
Vicente: What I really loved about the development was our team, and I don't say that lightly. More than six people joined when the concept was already set in stone and the script was almost finished, so I was really scared by the idea of us having different visions for the game that would clash and make everything messier. But turns out we all complemented each other's ideas in amazing ways.
As a mostly narrative-driven game, one of the more delicate parts of the development was to communicate the story and world building correctly to the player, and that was affected by the art, animation, music, gameplay, everything, and everyone just nailed it. The art expressed every universe without the need for words, the animations made every character feel incredibly alive, the music fit the mood of every moment while switching perfectly between parallel versions of every place, and the gameplay communicated the exact feeling we wanted to the players' hands. It was lovely!
How did you ensure that jumping between different universes wouldn't be too disorienting for players? Did you utilize any specific techniques to make those situations more readable?
Vicente: That was probably one of the most fun topics to study, but it was hard, and it required a lot of trial and error at the beginning. The most important rule was to not break the level's terrain in arbitrary ways (although I had to break that rule a couple of times, mainly in the prologue). If the player didn't have a prior idea of how the level would behave in the other world, then the game would end up having the player endlessly switching worlds just to memorize the terrain, and although that was part of the gameplay, we wanted to at least make it more intuitive to reduce the frustration as much as we could. We always tried to keep the terrain intact through worlds, and only putting different elements on top to create gameplay -- like boxes, ice, vines, and so on.
There are some other minor visual cues that the player wouldn't normally notice, too. For example, in Chapter 2, where everything is frozen, all the terrain in the light world is composed of either gravel or grass, and those translate to snow or ice in the dark world, respectively. Ice cubes were always frozen NPCs, too. In Chapter 5, where everything is toxic, there are vines to climb on in the dark world and in the light one you can actually see sprouts where those vines would touch the terrain, letting you know where those vines grew from. In the same chapter, solid blocks of grass would always shift into thorns you could walk through. It was really fun to think of details like those, and we feel they helped to make the gameplay a lot smoother and more fun in general.
Could you break down your approach to multiversal puzzle design? Did you create a specific framework or set of rules you had to follow? Talk us through that.
Vicente: I'm not an experienced game designer, so a consistent framework was one of the last things I got used to during development. I really wanted to make a narrative-focused game, and that meant that puzzles could never be too hard because they could get the player stuck in progressing the story and leave out of frustration. I wanted to focus more on exploring fun mechanics and diverse worlds, and for that I followed Portal's principle, which is basically making everything a tutorial. Puzzles could be created in a vacuum for easier design, but they should always answer three questions:
What is this puzzle teaching to the player?
What does the player already have to know how to solve this puzzle?
Which mechanic do I want the player to improve on in this puzzle?
Making puzzles like that allowed us to organize them in a way that would create a smoother pace for the game while also slowly increasing the difficulty. It was important to never expect the player to use mechanics in ways they don't already know to solve puzzles and have at least one instance where a mechanic could just be used again so the player could improve their skills or knowledge of it. We also included some parts just for fun, like an optional puzzle that Everett jokes about, a couple of interferences put in sequence just to make you travel faster, or Nash's silly persecution, for example.
You May Also Like
