Transitioning from a tightly crafted 2D Metroidvania in the Ori series to a systemic, multiplayer-driven action RPG with No Rest for the Wicked is more than your typical genre switch. That kind of adjustment requires a fundamental shift in technology, pipeline, and design philosophy.

Under the hood, that shift required more than simply scaling up existing tools. The team built on its heavily modified version of Unity (internally dubbed “Moonity”) while introducing deterministic multiplayer via Photon Quantum, a custom chunk-based world streaming system, and a wide range of internal tools designed to accelerate iteration across a fully remote team.

In this interview, Patrick Williams, at Moon Studios, walks through the studio’s work process, covering everything from networking architecture and performance challenges to level streaming, debugging tools, and the in-house timeline system that powers both combat and cinematics. We also heard from the art team about their approach when designing the look and feel in No Rest for the Wicked.

Plus, the team is celebrating two years of ongoing Early Access development, leveraging significant input from the community.

Can you walk us through the transition from working on Ori to No Rest for the Wicked and what that process was like for the studio?

Patrick Williams, Gameplay Tech Lead: Going from Ori, the second game, I’ve been with Moon for eight years, so I did work on that. The transition into this new game was actually what made me want to join Moon in the first place. When I applied, they said they were also working on this project in the background, trying to get it funded, and I thought, “Well, that’s the game I want to make.” They told me I had to make Ori first, so I had this background on my computer that said “do it for Forsaken,” which was the internal name for No Rest for the Wicked, with concept art and everything.

For me, the transition wasn’t hard, but for a lot of people moving from 2D level design in a Metroidvania to this game, it was difficult. Even the design philosophy changed. Just because something worked in Ori doesn’t mean it works here. We still have a fixed camera, but the game is fully 3D in gameplay. Everything from level design to combat to enemy navigation had to change.

A lot of 2D artists learned 3D workflows, and many designers were excited to try something new. We didn’t lose too many people, but some did move on because it was such a different kind of game.

On the tech side, we still use Unity, but it’s completely different under the hood. Ori 2 was built in a heavily modified version of Unity that we call “Moonity.” We have source code access, so we build a lot of our own render pipelines, timeline systems, input, audio, just whatever we need.

The biggest change for this project was multiplayer. Ori didn’t really have multiplayer. For this game, we use Quantum from Photon. We worked closely with them early on to evolve it into a more 3D-capable system. It’s deterministic, so instead of sending positions over the network, you send inputs, and everything simulates the same on each machine.

That meant we couldn’t just reuse the Ori codebase; it was a completely new foundation. So overall, it was a big transition both technically and creatively.

What were the biggest challenges when transitioning the game from single-player to multiplayer recently?

Patrick Williams: Luckily, multiplayer was always the intention. We just couldn’t get it to a place we liked in time for the Early Access release. Even a year before launch, we were still testing multiplayer across machines.

The biggest challenge was performance. Quantum simulates everything at the same time across all players. That’s fine for one player, but when you have four players doing different things across the map, it becomes much more demanding.

We had to solve issues like simulating off-screen players and maintaining performance. It wasn’t just visual concerns; it was also simulation-side challenges. Design also became more complex. A space that works well for one player can feel cramped with four. If you scale difficulty by adding enemies, performance drops, and the camera struggles to show everything clearly.

So it was a lot of small challenges adding up. But the good news is we didn’t have to rebuild the entire tech stack—the foundation was already there.

Was the addition of multiplayer expected to act as a kind of relaunch moment for the game?

Patrick Williams: Yeah, exactly. It was a bit of a bummer not shipping with multiplayer initially, because it’s such a big marketing beat. People want to play with friends.

But in the end, it worked out better because we could tune the core game first. We did expect it to pick up again once multiplayer was added. That’s just the nature of these kinds of games.

We’re not purely a Dark Souls-style game, since we also have elements from games like Valheim and Animal Crossing, which are more multiplayer-driven. Those systems naturally encourage playing together.

Wow, the game pulls from very different inspirations. How does that influence the design?

Patrick Williams: It’s a mix of perspectives. Everyone at Moon is passionate about games and comes from different backgrounds. Some people love combat, others prefer stealth or social gameplay.

We pull elements from different genres rather than copying one. It creates something unique, like a Souls-like game with town building or housing. That also makes it harder to tune, because there’s no direct reference point, but it’s fun to figure out.

What does your asset pipeline look like from concept to in-game implementation?

Patrick Williams: Most of my work is gameplay tech and design, but from what I’ve seen, it’s similar to most games, where concept artists create designs, then there are discussions about how to bring them into 3D.

We have a rigging department, and assets are modeled and prepared before we get them. Once assets are ready, they come to us, and we integrate them into the game.

Daniel van Leeuwen, Lead Environment Artist, Lead Tech Artist, Art Director: Because everyone in the team works remotely, we also have a very liberal way of doing software, in that everyone is free to use whatever they want.

Most of our artists actually work in Blender, especially the environment team, which is exclusively on Blender. Some of the other artists still work in Maya and 3DSMax. We made some simple tools in Blender to help with the flow with Unity and automate some things, like our interactive vegetation or collider generation. In general, we have a very traditional way of doing things, and we value handcrafted and painted assets.

Daniel van Leeuwen: Some artists will start with a sculpt, others might start with texture generation as a base. Some prefer to project a concept or paint from scratch. There is not one given workflow that we force upon our artists. The artists we hire have shown that they can produce quality, and everyone has their favourite workflow to get there.

One thing we also do is that concept artists will directly aid in the creation of assets and textures or asset artists in the creation of concepts; these are not strictly separated. 3DCoat is pretty much the go-to software for painting textures. In the end, the custom rendering and lighting we do in Unity mostly tie the assets together to produce the look we are after.

Can you talk at all about the inspirations for the visual style of the game?

Mikhail Rakhmatullin, Principal Artist, Art Director: When Thomas Mahler (Moon Studios CEO) reached out to me 10 years ago, suggesting we start developing the style of the new title, he already knew exactly what he wanted: “painting comes to life” as the core principle. He wanted the game to feel as artistic as possible.

So we looked to the Old Masters for inspiration. Caravaggio was our main reference, with his strong use of light and shadow and very focused compositions.

Mikhail Rakhmatullin: For environment art, we also drew a lot of inspiration from late 19th-century artists like Ivan Shishkin, Arkhip Kuindzhi, and Isaac Levitan.

Mikhail Rakhmatullin: Apart from that, when it came to character design, Thomas wanted strong stylization rather than realistic proportions: larger hands so movements would read clearly from a distance, and emphasized facial features for a more distinctive look.

That’s actually why he reached out to me. I already had similar work in my portfolio and had been experimenting with character proportions even back then.

Mikhail Rakhmatullin: From the very beginning, Thomas also believed we should move in the opposite direction of PBR realistic graphics and instead focus on artistic expression and dramatic lighting.

He often referenced the cutscenes from Vagrant Story, which still hold up beautifully despite their age. Notice the pronounced rim lighting; we use a similar technique quite extensively in No Rest for the Wicked.

Mikhail Rakhmatullin: We started from these foundations, but over the years, we introduced additional elements. New artists and technical specialists joined the team, each contributing something of their own to the overall style.

And of course, Ori and the Will of the Wisps was being developed in parallel with the NRftW pitch, so Ori’s visual style had a significant influence on the look of No Rest for the Wicked.

Can you walk through the entire life cycle of something like a new enemy design from concepting to being put into the game for players? What is that process like?

Mikhail Rakhmatullin: In the early stages of development, we worked from concept art based on very general descriptions from the design team. Over time, however, design and lore requirements became much more specific, so now work on, say, a new boss begins with a detailed design document.

Next comes concept art. This is quite a meticulous process, since every nuance, including texture and silhouette details, will be carried over into the model.

Mikhail Rakhmatullin: The model itself is built with a focus on hand-painted textures. Texturing typically starts by projecting the concept onto the model, followed by polishing both the model and textures with the in-game camera angle in mind.

Mikhail Rakhmatullin: After that, the finished model is handed off for rigging and integrated into the engine.

Animators then create an animation set, while combat designers implement and fine-tune all movements. VFX and SFX wizards do their passes, and tech guys make sure everything holds together. This is a highly intricate and iterative process.

On top of that, some characters like this boss, for example, require intro cinematic shots. This adds additional work for the narrative and cinematic animation teams, including more complex rigs, extra model and texture polish, and dedicated lighting setups, among other things, but it’s worth the effort.

What does your workflow look like when implementing gameplay features into the game?

Patrick Williams: Gameplay is kind of like the department that grants wishes. Design comes to us with ideas, art provides assets, and we hook everything together.

Then there’s a lot of iteration. Sometimes we handle tuning ourselves, which is nice because the gameplay team is kind of half programmer, half designer. We’re not just coding—we’re actively shaping how things feel in-game.

It’s very iterative. We build something, test it, improve it, and keep going until it feels right.

Can you explain how your level streaming system works?

Patrick Williams: We split the world into smaller chunks, internally we call them “nuggets” and “chunks.” Instead of loading entire levels, we load these smaller pieces dynamically.

For example, in the hub area, vendors can change states as you upgrade them. Instead of reloading the whole scene, we swap out just that specific chunk. This system also handles quest states. Designers can load specific versions of an area depending on progression, which makes iteration much faster.

How does the system determine what to load and when?

Patrick Williams: It’s based on visibility and distance. If something is off-screen or far enough away, we can unload or swap it.

If a state changes, we can preload the new version before the player arrives. Each chunk tracks its own conditions, like quest completion, and updates accordingly. It also affects enemy spawns, destructibles, and even cinematics.

How does the fixed camera influence development?

Patrick Williams: It helps a lot. Since the camera isn’t freely rotating, we can predict what the player sees and optimize accordingly.

It also helps with lighting and art direction. If we allowed full camera control, some areas wouldn’t look as polished because they weren’t designed to be viewed from every angle.

What kind of internal tools have you built to support development?

Patrick Williams: We have a lot of tools. One big one is our in-game debug system. It lets us spawn players, enemies, items, and simulate different conditions instantly.

For example, we can test PvP by spawning another player, or simulate lag conditions without connecting to a real server.

We also have tools for loading specific game states, teleporting around the world, and testing builds quickly. The goal is to reduce iteration time as much as possible.

Are there any key systems that support combat and boss design?

Patrick Williams: One big thing is VFX pooling. Instead of spawning effects every time, we pre-load them and reuse them. That helps avoid performance spikes.

We also have a system called “ArmaMan” that lets us simulate attacks in context. Instead of testing animations in a blank space, we can see them in an actual environment with proper physics and audio.

Can you talk about your in-house timeline system?

Patrick Williams: We built our own timeline system to handle animations, audio, and events. It’s not Unity’s default timeline—it’s something we developed ourselves.

It lets us line up everything, like animations, effects, and sound, and preview it in context. We use it for combat, cinematics, and more. It’s basically like a video editor for gameplay systems. You can scrub through, tweak timing, and see everything play out in real time.

What’s your overall philosophy when it comes to development at Moon Studios?

Patrick Williams: It’s very iterative. We don’t always start with a fully defined design document. We learn by building and playing. We try to make tools that speed up iteration and let people experiment. The faster we can test ideas, the better the game becomes.

Moon Studios, Game Developer of No Rest for the Wicked

Interview conducted by David Jagneaux

Don't forget to subscribe to our Newsletter, join our 80 Level Talent platform, follow us on Twitter, LinkedIn, Telegram, and Instagram, where we share breakdowns, the latest news, awesome artworks, and more.

Are you a fan of what we do here at 80 Level? Then make sure to set us as a Preferred Source on Google to see more of our content in your feed.