Rooftop Relay: Denver 2050

Inspiration

What would a hopeful climate game look like if it focused on people helping each other through a crisis?

That question became Rooftop Relay: Denver 2050. In a solarpunk neighborhood facing a severe heatwave, rooftops generate power and neighbors share what they have. You operate their microgrid, deciding where a limited supply of stored solar energy can do the most good.

I wanted the setting to shape the decisions. A clinic needs power, a market keeps the neighborhood running, and a cooling hub can stretch tomorrow’s possibilities. Hope comes from making those connections work.

What it does

Rooftop Relay is a portrait strategy game built around one commitment at a time. Each wave presents two or three neighborhood requests. You can power only one.

Homes use little Battery. Markets earn more Score. Clinics restore Trust. The Cooling Hub sacrifices immediate points to reduce nearby route costs by 2 Battery. Choosing a rooftop safely closes the other requests, but letting the entire wave expire costs Trust.

To win, meet each night’s Score target while keeping Trust above zero through three escalating nights. Between nights, install upgrades that expand your Battery, make Homes free and more valuable, or boost Market scoring.

A single tap sends power across the neighborhood. Windows light up, cooled roofs turn teal, and park lights reflect the community’s Trust. The challenge is deciding what the neighborhood needs now and what you must save for the next wave.

## How I built it

I built Rooftop Relay: Denver 2050 as a portrait-oriented HTML5 game using JavaScript and Three.js. The neighborhood is constructed entirely with code, including its buildings, rooftop infrastructure, lighting, power effects, and responsive interface. Sound cues are synthesized locally through the Web Audio API.

OpenAI Codex supported development throughout, helping me write code, diagnose bugs, test gameplay, and iterate on the design. I directed the creative decisions and evaluated builds through playtesting and screenshots. That process involved repeatedly revising features that worked technically but failed to communicate clearly or create interesting choices.

The final prototype includes a locally vendored Three.js runtime and makes no external network requests during play.

## Challenges

The hardest challenge was making a single tap carry a meaningful decision.

Early builds presented many simultaneous requests, rewarding players for tapping everything quickly. Instructions encouraged prioritization, but the mechanics encouraged speed. I changed the rules so each wave allows exactly one route. Choosing a rooftop safely closes the remaining requests; letting the entire wave expire costs Trust. That made prioritization part of the interaction itself.

Readability required similar restraint. Early interfaces competed with the neighborhood through too many panels, labels, and meters. I moved requests directly onto rooftops and focused the display on Battery, Trust, time, and the next decision. The final feedback pass made Night Score more prominent and clarified route outcomes, upgrade installation, and failure.

Cooling was especially difficult to explain visually because its reward arrives later. The implemented effect leaves eligible roofs teal and reduces their route costs by 2 Battery, allowing a Market to drop from 3 Battery to 1. The neighborhood now shows where that earlier investment creates an opportunity.

I also resolved mobile overflow, a missing Three.js dependency that stopped the opening button from working, and an upgrade screen that asked players to plan before they understood the game. Moving the first upgrade choice until after Night 1 gave players experience to base that decision on.

## What I learned

Clear instructions cannot compensate for unclear rules. If every marker can be tapped, players naturally assume they should tap every marker.

The best improvements came from removing contradictions and letting the interaction teach itself. Restricting each wave to one choice created more strategy while requiring less interface.

I also learned that a distinctive game does not come from adding more visual decoration. It comes from consistent art direction, meaningful consequences, and being willing to replace systems that do not produce the intended experience.

## What's next

I want to continue testing the first-time experience, expand the authored night events, add more visible neighborhood transformation, and explore additional upgrades without losing the simple one-choice-at-a-time foundation.

Built With

• codex
• css
• html5
• javascript
• three.js
• vercel
• web-audio-api