Blizzard Unannounced Survival Project

Project Odyssey was Blizzard's take on the survival genre — an AAA, mass-market title built in UE4. I joined as a System Designer, owning the resource economy, crafting systems, tech tree progression, and resource distribution across the open world. The project was cancelled in April 2024.

​

The Challenge

Survival games live or die by their resource economy. My core design problem: players need to spend resources constantly — building bases, crafting gear, restocking consumables — while simultaneously earning them through gathering, combat, and PvP looting. If either side breaks down, the game collapses into a grind or inflates into meaninglessness.

​

Two additional constraints made this harder than it sounds:

Readability first. Early-game resource distribution had to be intuitive enough that new players could navigate it without a tutorial wall — spawn logic had to communicate the rules spatially.

Coordinated intent. Resource placement wasn't mine alone to decide. Spawn patterns needed to funnel players toward specific zones in alignment with the World and Procgen teams' broader map design — the economy couldn't be designed in isolation.

​

Design Philosophy: Legible Worlds

Most survival games treat resource distribution as a random scatter problem. In playtesting and studying other titles in the genre, I noticed a consistent failure: players couldn't build a mental model of where to go because spawn logic felt arbitrary. You found iron because you wandered long enough, not because you understood the world.

​

I set out to design against this with two principles:

1. Resources must exist where they logically belong. 2. Finding a resource requires an obvious intermediate target, not a search.

The mushroom is the clearest example. Mushrooms spawn on rotting wood — ecologically coherent and immediately readable. Rotting wood appears near tree roots, which are found in forest zones. So the search chain becomes: I need mushrooms → I find rotting wood → I look near trees → I go to the forest. Each step has a large, visible target. A new player doesn't need to memorize spawn tables; they just need to understand the world as a place.

This principle extended to how I collaborated with the Procgen and World teams on resource distribution rules in UE4. Spawn logic wasn't just about yield numbers — it was about ensuring that the landscape itself communicated where resources lived. The economy only works if players can actually find the resources they need to participate in it.

​

​

​

​

​

​

The Key Insight: Three Players, One Economy

Playtesting quickly revealed that "the player" doesn't exist. Three distinct archetypes behave fundamentally differently:

​

​

​

​

A single resource curve cannot serve all three without breaking for at least one group. My approach: design around solo pacing as the floor, and treat group efficiency and PvP looting as accelerators — ways to reach the same milestones faster, rather than pathways to a structurally different economy.

The critical design question then became: how do you prevent these accelerators from outpacing the system?

Keeping Accelerators in Check

Rather than imposing hard caps, I designed each accelerator to carry its own counter-pressure:

​

PvP looting is self-regulating. High-value targets mean high-risk engagements — death penalties and gear degradation mean aggressive players are constantly spending back into the economy. The player who loots the most also loses the most when they overextend. Competitive pressure in high-value resource zones creates natural throttling without any designer-imposed limits.

​

Group play has proportionally higher expenditure demands. Group players gather faster, but they're also building and maintaining a shared village — base construction is a resource sink that scales with team size. The acceleration doesn't accumulate; it gets absorbed by collective spending requirements. Groups reach milestones faster not because they're richer, but because they can sustain a higher throughput against a higher cost structure.

​

Validating the Pacing

For the tech tree, I established target unlock times per tier and validated them against playtest data using a combination of signals: time-to-unlock distributions, per-archetype gather rates, and observed player behavior at each progression gate.

When real numbers diverged from targets, I traced the gap back to its specific source — spawn density, recipe cost, or a tier's geographic position — and adjusted at that level rather than broad-tuning the whole economy.

​

Outcome

The tech tree pacing received positive feedback in internal playtests, with evaluators noting that progression felt purposeful without artificial bottlenecks. The three-archetype model held up across test cycles, with each player type progressing at a pace consistent with their playstyle while remaining within the intended economy envelope. Playtest data analysis produced a prioritized optimization list that fed directly into the next iteration cycle.