Murder in the Alps

A hidden-object F2P narrative game at Nordcurrent. Top 5 Google Play Casual Games of 2018, 8 years live and counting. I joined at soft launch and stayed across the game’s life — the last two of those years as Lead Game Designer.

The structural problem

By the time I joined at soft launch, Murder in the Alps carried the shape of a classic single-player hidden-object game running on an F2P energy economy. Every player action carried an energy cost, but the narrative itself hadn’t been reshaped for the model — long, uninterrupted sessions were divided into five-minute fragments stitched together with energy walls: wait, pay, or watch ads.

The trouble is that the core of the game was still a long single-player narrative — a careful story you sit down to enjoy. There was nothing in between sessions for an F2P player to come back to. The game became popular despite that structure, not thanks to it. Players stayed because the story was good and they wanted the next chapter.

The instructive thing happened later. When we shipped side activities — carnivals, themed events, the standard LiveOps menu — they didn’t move the needle much. Players didn’t want side activities. They wanted core. The core wasn’t built to live in F2P; making it work would have meant rebuilding it.

I can’t share what we planned about that. What I can say is that we had a multi-step change plan, and the first experiment was introducing timers inside the hidden-object scenes themselves. Metrics went the wrong way. We rolled back and stayed on the previous version rather than push to the next steps. That’s the LiveOps version of getting a hard “no” from your audience, and respecting it was the right call.

Designing chapters at scale

I wrote and designed 10 of the game’s 13 chapters. The pipeline kept evolving while I was on the project — partly because I kept proposing changes to it.

Word → Excel. The first two chapters had been designed in Word documents. They were difficult to navigate, hard to track changes against, and hard for scripters to consume. I’d come from Frogwares hidden-object work where we’d already worked out the prescript-spreadsheet pattern — every event, every dialogue line, every state change as a row in order. We adopted that on Murder in the Alps. I designed the chapters; other designers implemented from my docs in Lua.

Adding a prototype pass. I started prototyping each chapter in Lua myself before handing off to scripters, because I wanted to see my own design playing back as soon as possible — catching pacing problems and dead air at the design stage rather than at QA. The prototypes worked well enough that they became part of the standard pipeline; later, other designers prototyped from my chapter documents.

Waterfall → group iteration. In the final years we restructured chapter production from a waterfall (design → art → animation → script) to small parallel groups. A chapter was broken into chunks; each chunk got a designer, an artist, and an animator iterating together on the piece before it entered full production. The win: we made our mistakes on sketches, not on finished art. The production-time savings were significant.

LiveOps as a school

Eight years on a live product is its own education. I learned LiveOps from the inside out — analytics, A/B testing, the standard F2P metric set, the difference between metrics that look like signal and metrics that are signal. The timer experiment above is one example: a clear hypothesis, a real test, the discipline to roll back when the numbers said no.

Voice direction

A different kind of work that happened to be one of the more pleasant surprises of long-tenure design: directing voice-over recording sessions with actors. Reading takes, calling adjustments, picking between performances — entirely different from spreadsheet design and entirely fun. One of the small lessons of staying with a single product for years is the breadth of disciplines you end up touching.

What I took from it

The structural problem — F2P-converted-from-paid — taught me to see business model and design as the same conversation, not separate concerns. The pipeline changes (Excel, prototypes, group iteration) taught me that pipeline is itself a design surface and worth designing deliberately. And the LiveOps run taught me to read metrics with real skin in the game — and to know when the right thing to do with a planned change is unwind it.