Every decision costs someone something.

I designed and built a disaster simulation game that helps the American Red Cross train volunteers for high-intensity scenarios, in collaboration with ARC and the AI Institute for Societal Decision Making (AI-SDM) at CMU.

Why it exists

What is this

The American Red Cross runs close to 70,000 relief operations a year, and about nine in ten of the people running them are volunteers. They are trained with tabletop exercises: collaborative and flexible, but the scenario never changes once it starts, nobody tracks the decisions being made, and feedback only arrives at the debrief.

This game turns that exercise into a living simulation. Over eight days after a disaster, players run shelters, kitchens, volunteers and vehicles while roads collapse and needs shift. AI teammates brief you and push back, and a reinforcement learning model scores every decision, so instructors finally see how a strategy played out.

Built with
My roleSole product designer. I designed the game goal, mechanics, flows and interface, ran the playtests, and took it from a blank page to a playable prototype.
Team
Product designerGame engineerML engineer
1

Real scenarios, random events

Demand and emergencies are driven by terrain, weather and population, then hit at random. Roads collapse, vehicles fail and storms roll in, so no two runs play out the same way.

2

The tension of resource management

Money, time, volunteers, vehicles and food are never enough at once. Every event forces at least two into conflict, and the cost of today's shortcut lands tomorrow.

3

Human collaboration, with agents

AI teammates with distinct personalities and partial information brief you, argue, and suggest a first move. You decide, and they explain what changed.

The playable game: a map with shelters, kitchens, roads and a disaster info panel

Play what I built

The working prototype. Prep for landfall, run the rounds, and see how your decisions score.

Open the demo
Annotated interface design showing information, assessment, map controls, agents and daily tasks

Check how I designed

The design thinking behind it: goals, mechanics, interface decisions and playtests.

Open the deck
Reflection

Designing an AI-powered interactive game

Design rules and logic, because the flow is non-linear

Players act in any order and events interrupt them, so a screen flow could never hold the design. I designed the systems first: what triggers an event, how resources trade off, how agents behave. The interface followed from those rules.

Translate data-driven goals into actions

The training goal is measurable: satisfaction, response time, resources per resolved case. Each metric had to map to something a player can actually do on the map, or the score would be noise nobody could learn from.

Build and test, instead of think

Paper playtests and rough prototypes answered questions that debate never could. Every mechanic was played before it was polished, and most of them changed after the first session.