Rescue Harbor

The RH03 helicopter responds to a fire on the offshore oil rig.
Rescue Harbor at a glance: build the harbor, answer emergencies, and bring survivors home.
A tsunami evacuation with the threatened island highlighted and rescue capacity in view.
A developed harbor with homes, services, upgraded craft, and rescued residents.

Inspiration

Rescue Harbor started as a boat rescue prototype, but the idea became much more interesting when I stopped treating the boats as vehicles and started treating them as resources.

I wanted the core loop to be about making rescue decisions: read an emergency, choose the right response, bring survivors home, invest the funding you earn, and prepare the harbor for a larger emergency.

That naturally developed into a Simulation & Management game where every successful rescue changes what the player is capable of handling next.

What it does

The player begins with a small raft, a basic harbor, and limited rescue capacity. Emergency calls appear across a procedural island chain, and the player must decide which rescue asset is appropriate for each situation.

The starter raft only carries two survivors. A flooded home with six people can still be rescued, but it may take several trips. Investing in larger boats, specialized craft, or the RH03 rescue helicopter makes increasingly difficult incidents manageable.

Rescues provide funding that can be reinvested into new craft, harbor buildings, workers, housing, and upgrades. As the harbor grows, the emergencies escalate from flooded homes and capsized boats to aircraft crashes, offshore oil rig fires, and a tsunami evacuation.

Rescued people also become part of the system instead of disappearing into a score counter. They return to the harbor as residents, walk through the town, take jobs, and create demand for housing and services. The result is visible growth tied directly to how successfully the player manages rescues.

The first campaign is designed as a complete session with a clear objective and a COAST SAVED ending. From there, Continue Harbor opens the larger archipelago and persistent management systems.

How I built it

Rescue Harbor is a single-player portrait web game built with JavaScript, Three.js, WebGL, HTML, CSS, and the Web Audio API.

The entire game runs offline from a readable index.html. Three.js, models, fonts, sounds, and game data are packaged locally so the build makes no external network requests.

I created the 20 selectable rescue boats, the RH03 helicopter, harbor buildings, homes, civic facilities, hospital, airport, offshore oil rig, aircraft variants, rescue props, residents, workers, and vegetation sets.

The source assets began as Blender, FBX, and GLB files. I built a conversion pipeline that turns them into compact runtime models while preserving their silhouettes and material color slots. Kenney CC0 assets are also used for parts of the interface and a small number of environmental props.

One of the most important technical systems is the procedural island contour. The same seeded island shape drives terrain, beaches, cliffs, shallow water, shoreline foam, collision, object picking, and dock placement.

Boats also use those island contours when planning routes, allowing them to navigate around land instead of simply moving in a straight line toward an incident.

Construction uses its own readable interaction loop with placement previews, scaffolding, tap boosts, and a visible completion stage so harbor growth happens directly in the world.

I used OpenAI Codex throughout development and maintained a session-by-session Markdown build log. Development was broken into small, testable passes: scene setup, asset conversion, procedural islands, dispatch, survivors, construction, progression, disasters, touch controls, performance, accessibility, and finally offline packaging.

Challenges

The hardest technical problem was keeping every system in agreement about where an island actually exists.

A shoreline can look correct visually while a boat drives through it, a dock floats away from it, or a touch selects the wrong location. Rather than letting each system approximate the coastline independently, I made them all derive their information from the same procedural contour.

That single decision removed an entire class of inconsistencies and made the procedural world much easier to reason about.

The second challenge was readability.

Rescue Harbor has to communicate an emergency's location, danger, survivor count, rescue requirements, travel time, and reward on a portrait phone screen without hiding the world the player is managing.

I repeatedly adjusted camera framing, scale, touch targets, information hierarchy, and feedback until the player could understand the situation and make a decision quickly.

What I learned

The biggest improvement came from narrowing the interaction.

Originally, direct vehicle control seemed like the obvious direction for a rescue game. Removing it made the game stronger because it put the focus on the decisions that actually mattered: rescue capacity, response time, asset selection, funding, and harbor growth.

I also learned how valuable it is for procedural systems to share one authoritative source of data. Once terrain, navigation, collision, docks, selection, and shoreline visuals all understood the same island contour, the world became dramatically more reliable.

Most importantly, I learned that additional systems are most useful when they reinforce the same loop instead of competing with it.

Read the emergency. Choose the response. Rescue people. Reinvest. Prepare for something worse.

That became the center of Rescue Harbor.

What is next

The next step is to deepen the persistent harbor without changing that core loop.

Rescued residents could take on more specialized jobs. New islands could introduce different navigation and construction constraints. Aircraft could search beyond the currently visible area, and larger disasters could affect several communities simultaneously.

Those systems would all serve the same idea: each rescue should make the harbor a little more capable of surviving the next one.