You can spend hours designing a sound that is beautifully layered, perfectly edited and technically flawless. Then you put it in the game and realize it's completely wrong.
That's the uncomfortable truth of game audio. Players never hear a sound file in isolation. They hear it while dodging attacks, tracking enemies, following dialogue, reading animations and trying not to die. The finished product isn't the WAV file. It's the experience of hearing that sound inside the game, with everything else going on.
That idea shaped how we worked with ProbablyMonsters on Crimson Moon, a gothic action-adventure RPG released on September 1, 2026, for PC, PlayStation®5 and Xbox Series X|S. Players are Nephilim, half human and half angel, fighting alone or in co-op to reclaim the fallen city of Gildenarch from demons, vampires and undead gods. Combat is built on precision and timing, which made the bosses, and how they sound, central to the experience.
We owned boss audio from the first creative idea through implementation, testing and iteration. ProbablyMonsters kept the wider audio vision, the technical foundation, priorities and final approval. It sounds simple. Making it work took a lot more than a shared folder and an asset list.
“More and more game development is becoming co-development. Studios are working with smaller internal teams, tighter budgets and faster timelines. We needed trusted partners who could move quickly, manage their own work and scale up as production required.”
Dan Crislip · ProbablyMonsters
Co-development itself isn't new. Art and engineering teams have worked this way for years, with external partners shaping a game from early on rather than delivering to a brief at the end. Audio has been slower to join that conversation. Our argument has usually been about timing, about getting involved earlier, more than about how an outside team actually shares ownership of the work. That second part is what we wanted to get right on Crimson Moon, and it is where audio has the most to borrow from the disciplines that have been co-developing longer.
Why the WAV file was never enough
I've spent much of my career inside and alongside studios like Bungie, Ubisoft and Ready at Dawn. If that taught me one thing, it's that an experienced senior audio team can contribute much more when it's allowed to take part in development. It needs access to the game, an understanding of the vision and systems, and the ability to judge its own work in context.
The alternative is making WAV files, sending them over and leaving the internal team to work out how they should function. That tends to produce revision after revision, until everyone agrees the first version was probably better anyway.
A sound can be impressive in a DAW and fall apart the moment it meets the boss fight. Music, voice, animation, visual effects, camera, combat intensity and player behaviour all change how it's perceived. A sound that works beautifully on its own can leave a completely different impression in the full mix, and we only catch those moments by reviewing in gameplay. You can only really judge a boss sound when you're standing in front of the boss and it's trying to kill you.
Disclaimer: This is one case where the model worked, not a rule for every project. It suited Crimson Moon so well because the bosses are such an integrated part of the experience. For other teams, or for more narrowly defined work, it can make more sense for the studio to direct the work closely without the external team working in the build. And there are often compliance and security reasons why that level of access isn't possible at all.
Three pillars, one job: be readable
ProbablyMonsters gave us three audio pillars: immersion, emotion and information. They set direction without prescribing every creative decision, and gave us a shared language for discussing why a sound existed and what job it had to do.
“Every boss action should have a tell, and every attack should have a follow-through.”
Dan Crislip · ProbablyMonsters
In a game built on timing, boss audio couldn't just sound good. Players had to be able to read it. Attacks needed a rhythm players could gradually learn, and a charge-up, strike or recovery wasn't only there to excite. It was teaching the player what the boss was about to do and when to react.
Every sound had to carry weight, intent, danger and character while still serving the gameplay. The only place to judge that was inside the encounter.
Starting from something real
We didn't start cold. We'd already worked with ProbablyMonsters on Ire: A Prologue, so we knew the team, some of the tools and, most importantly, how they liked to work. That removed much of the uncertainty that usually comes with onboarding an external partner.
“When the need came up on Crimson Moon, Palm Tree was an obvious fit. They already understood us. We could give them room to experiment and iterate without supervising every decision, and they joined the conversation early with questions and suggestions.”
Dan Crislip · ProbablyMonsters
What ownership actually meant
The goal was to give us something meaningful to own: the bosses. That covered their abilities, attacks, movement, projectiles, impacts, finishers and player-facing feedback. Music and parts of voice production sat with other teams.
“Ownership” can be a wonderfully vague production word, so we made it practical. We could work in the build end to end:
- Capture and evaluate gameplay, and inspect the relevant animations
- Create original sound design and build or modify MetaSounds
- Implement within established systems and test in the playable build
- Run our own creative and technical reviews
- Flag missing coverage and implementation problems
- Complete real iteration before anything went to wider review
“Ownership meant taking an assigned area to a finished state before it came to the wider audio team. We'd review it as a group, turn remaining feedback into Jira tasks and assign revision passes. A boss was complete when I approved it and the sound designer was happy with it.”
Dan Crislip · ProbablyMonsters
We had creative ownership at the feature level, but Dan stayed responsible for the complete audio experience: mix weight, perspective and consistency across the game. An external team can own a meaningful area. Someone inside the studio still has to connect the dots.
Build the technical foundation first
One decision shaped the whole relationship: Crimson Moon didn't use middleware like Wwise or FMOD. Its audio was built mainly inside Unreal with MetaSound, supported by Blueprints, gameplay hooks and systems developed by the ProbablyMonsters audio and engineering teams. Technical fluency wasn't separate from the creative work. It was part of it.
“We needed partners who understood Unreal, Blueprints and MetaSound, not only excellent sound designers. A lot of our internal engineering effort went into systems individual sound designers could use, with documentation people could actually follow. Otherwise every implementation task ends up back on the internal team's desk.”
Dan Crislip · ProbablyMonsters
That gave us a clear boundary. ProbablyMonsters built and maintained the foundation, and we used it to take boss audio all the way to the player. When deeper Blueprint, code or project-level changes were needed, Dan, Adam Chase (Technical Sound Designer) and the internal team stepped in.
Protected, but connected
We had access to the build, source control, Unreal, Jira, test maps, console commands, Slack and the project information we needed. That didn't mean sitting in every stand-up. Nobody needs another meeting unless it helps make the game, solves a real problem or unblocks someone.
“I generally prefer to shield external partners from the wider organization, so they can focus on prioritized audio work rather than random requests, unfiltered playtest reactions, design changes and conflicting feedback. We take that feedback seriously, and we love it when people across the team have ideas about audio. My job is to filter them and turn them into clear actions for the audio team.”
Dan Crislip · ProbablyMonsters
At the same time, we could go straight to other disciplines when we needed to: an animator about an animation, or design about a new gameplay hook. Those conversations happened in open Slack channels, so the right people could respond and the wider team could see when a question sparked an idea or exposed a bigger issue.
For us, that protection was extremely valuable. We could focus on the work while Dan navigated the organization, and when our reviews uncovered a problem, we documented it and he got it to the right people.
An external partner doesn't need to be present for everything. It does need to care about the game, be honest about where the work stands and raise issues early. Most of all, it needs a dependable route to the people, decisions and systems that affect its work.
Trust still needs a rhythm
Trust helped a great deal, but trust alone doesn't ship a game. We needed a rhythm that kept questions, reviews and ownership from getting messy.
We met once a week, on Tuesday, for a focused Jira triage. Dan wrote up each task with everything needed to start right away: test maps, recent gameplay changes, console commands, how to reach a creature or encounter, animation references, intended behavior and known technical dependencies.
It sounds small, but it removed a surprising amount of friction. Nobody had to replay half a level, rebuild progression or keep dying just to hear the one animation they were working on.
“Weekly felt right. Often enough to clear questions and blockers, not so often that meetings got in the way of progress. Anything bigger than a quick answer went on the Jira board, so everyone knew what they owned and what came next.”
Dan Crislip · ProbablyMonsters
Plenty still happened in Slack, of course. Game development refuses to fit entirely inside a ticketing system.
On our side, after a strong content week we reviewed every boss with new or revised audio. We documented what worked, what didn't, where we needed implementation help and where we had design questions. We also captured gameplay with notes and reference points, so Dan could see the current state without rediscovering every issue himself. A cycle settled in:
- Create and implement the content.
- Review it inside the game.
- Document findings and capture examples.
- Triage the findings with Dan.
- Assign ownership.
- Iterate or sign off.
Adding external capacity should reduce the internal director's workload, not hand them a bigger pile of unchecked content.
Fresh ears by design
Those reviews worked as well as they did partly because of how we iterate internally. One senior owner still carries each sound from design through to the build, the way we always work. Within that, we deliberately bring in fresh ears during iteration, a second designer who takes a pass and hears what the first had stopped noticing, each bringing a perspective the last one couldn't, all within a short window.
There's a simple reason this helps. When you sit with a sound long enough, your ears fatigue and you slowly lose the distance you need to judge it. You end up forcing that distance, stepping away and coming back later just to hear it honestly again. A fresh perspective builds that distance in by default, without breaking ownership or the line from design to implementation.
The result is that we find the right perspective faster and reach the best version of a sound in a more organic, creatively inspired way, instead of grinding a single pair of ears until they give out. This helped most in the last weeks of polish, when we wanted to make every bit of the time we still had count.
Working while the other team sleeps
The ProbablyMonsters internal team was based in Bellevue, with developers across the United States and partners in Europe. At first, the time difference looked like one of the biggest practical challenges, especially for Dan.
“My days often started very early, but I'd also finish earlier to create more overlap with the partner teams.”
Dan Crislip · ProbablyMonsters
Over time, it became one of the arrangement's strengths. Dan would review the work and leave feedback toward the end of his day. By the time he was back the next morning, we'd already worked through much of it. It came close to a continuous production cycle, with the game moving forward while the other side slept.
That only worked when every handoff carried enough context for the other team to continue without waiting for an answer.
“It slowed us down when files stayed checked out overnight, or when a build problem couldn't be solved until the next day. The best protection was clear communication. Everyone needed to say what they were changing, what they'd finished and whether anything might block someone in another time zone.”
Dan Crislip · ProbablyMonsters
That's why we made it a firm rule in our own workflow: by the end of our day, nothing stayed checked out in Perforce, even if the work wasn't finished. A half-done change could wait until the next morning. Someone in the US sitting blocked for a whole day couldn't.
Distributed development can move fast, but only if handoffs are treated as part of the work.
Scale when the game needs it
Our involvement grew with production. I started at two days a week in early production and moved to four as the project ramped up. Augustin, one of our sound designers, then joined full-time for the final six weeks.
Starting small gave us time to understand the project, explore its sonic identity and record source material before the heaviest stretch. We built a library of original material that belonged to the game's world, rather than trying to create everything at once at the end.
When Augustin joined, we could raise our output, review coverage and polish without changing who led the work creatively. For Dan, it didn't add another relationship to manage, because we still directed and reviewed our own work before it reached his team.
“Budget and production planning need to account for the increase in audio work near the end of a project. Our approach was to keep a strong internal audio group and add trusted external capacity when the project needed more production and review support.”
Dan Crislip · ProbablyMonsters
Continuity matters too. Once a partner is onboarded and proven, bringing them onto the next project makes everything easier. They already know how you communicate, how your systems work and what quality means to your team.
Flexible capacity isn't just more people. It's the right people, added at the point where they can help without fragmenting ownership.
Making room for the final pass
As the game came together, everything became more interconnected. Animations changed, visual effects improved, abilities were refined and gameplay kept evolving through testing. Most of those changes made the game better, and most of them changed what the audio needed to do.
A revised animation needed different audio timing. A stronger visual effect shifted the perceived weight of a sound. A gameplay tweak called for clearer feedback to the player.
Earlier bosses settled down, while newer encounters needed more iteration as everything around them developed. Broad tasks for a whole boss gradually broke into smaller tickets for individual abilities, bugs, mix adjustments and remaining gaps.
“Audio is closely connected to animation, visual effects, gameplay, music and voice. When any of those change, audio may need another implementation, review or mixing pass. That isn't a failure of the process. It's part of finishing a game. The goal isn't to prevent late changes. It's to make sure every discipline, including audio, gets a chance to respond to them, and that producers, leads and partners plan time for that early.”
Dan Crislip · ProbablyMonsters
Some of the hardest pushes produced the best results, because everyone was reacting to what the team was learning. This is where flexible capacity paid off. Because we already knew the project, we could step up support in the closing stretch without spending that time onboarding a new team.
Adding people near the end only helps if they already understand the game, know where everything lives and know which dragons are currently on fire.
Before you try this
Looking back, we'd both say the model worked very well. We'd also say it isn't magic.
“It depends on having a strong center inside the studio. Someone needs to hold the creative pillars, understand the technology, manage scope and budget, filter feedback and make the difficult decisions. The model also changes as the partner team grows. With two or three experienced contributors, a fairly direct reporting line works. Beyond that, the partner may need sub-leads and more internal structure.”
Dan Crislip · ProbablyMonsters
This isn't a model for replacing internal audio teams. It only works because there's a strong one at the center.
Less-experienced contributors can work this way too, but they need more examples, closer direction and extra review. Lean production doesn't make mentorship disappear. And autonomy comes with responsibility: being trusted to own an area means spotting problems, communicating honestly, reviewing your own work and following it all the way into the game.
Five things that made it work
- Keep the vision inside the studio. A partner can own a meaningful area, but someone inside the studio must stay accountable for how it fits the complete experience.
- Make the technical foundation usable. If the partner needs an internal developer for every technical step, responsibility hasn't really been delegated. Systems, builds, documentation and testing paths have to support the autonomy you expect.
- Give the partner something real to own. A defined part of the player experience, carried through implementation, testing, review and iteration. Not a list of disconnected assets.
- Filter the noise, but keep the doors open. Partners don't need every meeting or passing opinion. They do need a reliable path to information, decisions, technical support and the people whose work affects theirs.
- Scale with production. Start with what the project needs today, then add experienced capacity as production and closing intensify, without splitting creative ownership or adding a management burden.
The distance that matters
The difference between an audio vendor and a development partner isn't where they sit. It's the responsibility they're equipped and trusted to carry.
An external team can be thousands of kilometers and nine time zones away and still be part of development. Sometimes that distance even helps. And someone in the same building can still become disconnected if they only close Jira tickets without playing the result.
The distance that matters most is the distance between the work and the player experience. For studios considering co-development, the question isn't only whether an external team can create excellent sound. It's whether the studio has created the conditions that let that partner help make an excellent game.
Additional contributors
Crimson Moon's wider audio production included the internal ProbablyMonsters audio team, Palm Tree Audio, Rev Rooms, BigMouth, composers, musicians and other production partners. This article focuses on the working relationship between ProbablyMonsters and Palm Tree Audio. Every production is different, and this model was shaped around Crimson Moon's team, technology, creative goals and schedule. We hope these lessons are useful to other studios and external teams exploring more integrated ways of working together.