Storm Jar

Gather. Convert. Survive. One truck, one family, three tornadoes - and never enough time.
The tornado picks its own targets. Beat it to yours, or lose them - and the truck - for good.
The storm took the truck - and everyone still in it. Some runs end with an empty jar.

Gather. Convert. Survive.

Inspiration

Storm Jar started as an award winner. An earlier version took Most Innovative in the previous Meta Horizon Creator Competition - an emotional-triage game where you guided three family members and their trauma responses to a storm cellar. It was a clever idea. But when I put that first prototype in front of players, I learned something uncomfortable: the urgency was understood, not felt. You thought about the storm; you never sweated it.

So, I kept the heart - a family racing a tornado to shelter - and rebuilt everything around making that dread physical. Storm Jar is now a real-time, one-thumb drive: you gather people and supplies with a truck that has limited cargo, and the tornado tears away anything you do not get home in time. The choice that used to be a menu is now a white-knuckle scramble - go back for one more, or shelter and live with what you saved. This prototype is that pivot: the same emotional core, rebuilt so you feel the storm instead of reading it.

What it does

You drive the farm truck to gather people and supplies, then convert what you deliver into survival. Lumber and brace kits reinforce the cellar, storm panels cut incoming damage, repair kits fix the truck, and fuel improves performance. Rescued people become GRIT, the currency you spend on lasting upgrades between storms.

The resource-management heart is the shelter-or-risk decision: once your required people are safe, reaching the cellar does not end the storm. You choose to secure the win by sheltering, or spend your scarcest resource "time" on one more risky trip. Nothing is safe until it is in the cellar. A truck caught in the funnel is torn away with everything in its cargo, and anyone left in the open is swept away for good. Three storms escalate with faster timers, heavier debris, a closing tornado, and a cellar that carries its damage forward, building to a final stand.

How it's Built

Storm Jar was prompt-built through GitHub Copilot, using a mix of AI models across sessions - Claude Opus 4.8 for the heaviest architecture and system-design work, Claude Sonnet 4.6 for fast iteration and UI, and GPT 5.6 Terra for focused problem-solving and review. It is a fully offline, self-contained HTML5 Canvas game in portrait orientation. I worked in small, verified passes: lock one decision, prompt the implementation, play the build, then correct against what felt wrong rather than asking for vague polish. The complete session-by-session record is in the submitted build log.

For art, the character, animal, vehicle, and pickup sprites were generated as 3D models with Meshy, rendered to 2D, and given motion to sit flat on the top-down field; the environment, weather, and interface art were generated with Adobe Firefly. Audio was edited and mixed from Adobe Stock source clips in Adobe Premiere Pro. Everything is bundled locally and runs with no external requests.

Challenges I ran into

Keeping the build honest, fully offline, and under 35 MB while packaging every asset locally. Making the required-rescue rules and the shelter-or-risk choice legible at a glance on a phone. And tuning storm fairness so early tornado sweeps felt tense rather than cheap - protecting required survivors for a short opening window, then letting the pressure return.

Accomplishments that I am proud of

A complete, genuinely playable survival loop with real win, loss, retry, and reset states. A resource economy where supplies visibly convert into cellar integrity and truck condition. A signature end-of-storm gamble that turns "should I go back out?" into the core decision. And a clean, offline, single-file build that runs start to finish with no external requests.

What I learned

Naming the player feeling to fix - "I cannot tell who I still need to save" - produced far better results than naming a mechanic. Broad "make it better" prompts created redundant, half-built systems and hurt focus. Depth on one tight loop beats breadth that does not hold together, and verifying every change by actually playing kept the build honest.

What's next for Storm Jar

The tornado farm is a vertical slice of a larger survival series. Next are new rescue missions per disaster - a flood delta, a wildfire, a blizzard - each with its own resources and conversions (sandbags and pumps, firebreaks and water tanks, fuel and heat), its own escalating threat, and its own survivors to reach, all running on the same proven gather, convert, survive loop.

Built With

adobe-firefly
adobe-premiere-pro
adobe-stock
canvas-2d
claude-opus-4.8
claude-sonnet-4.6
css
github-copilot
gpt-5.6-terra
html5
javascript
meshy
mobile
node.js
offline
pointer-events
portrait
survival

Submitted to

Meta Horizon Creator Competition: Game Prototype

Created by

I designed and built Storm Jar solo, using AI heavily throughout as a development partner. It grew out of an earlier version that won Most Innovative in the last competition - a game about emotional triage. That concept was clever, but playtesting showed people understood the urgency without actually feeling it, so I rebuilt the whole thing around driving one truck through escalating tornadoes to make the stakes physical.

I used AI across the entire pipeline. For code, I worked with an AI coding assistant to prototype mechanics, build the game loop, and debug. For art, I used Meshy to create the 3D character and vehicle sprites and the flattened them and animated them, Adobe Firefly for the environment, weather, and interface art. For audio, I built the sound design from Adobe Stock sources edited and mixed in Adobe Premiere Pro. Moving fast on assets let me spend more of my time on the part that actually matters: whether the game is fun.

The shelter-or-risk decision - hunker down or make one more trip - took the most iteration. Early versions were too easy or felt unfair, and I kept testing and tuning until that tension landed. The design decisions, integration, playtesting, and final judgment on what stayed or got cut were mine. AI made me faster; it didn't make the game for me. Taking a concept that already earned recognition and pushing it further, turning understood urgency into felt urgency, is the part I'm most proud of.

Nolan Huber
MHCP partner, Cyber Security Engineer, and Founder of ArcForge. I like to build games where mechanics carry emotional weight, then ship them