Sloop in Open Water: Sailing Systems in a Browser

Dalrymple Ramos
Sloop in Open Water product preview

Project overview

Sloop in Open Water is a browser-based sailing simulator built for players who want an open tropical archipelago to explore, with a ten-boat fleet to sail rather than a single vessel.

I modeled wave-driven buoyancy and heel for the ten boats, then used spray, wakes, and a procedural seabed to make their motion visible. Live weather, a day/night cycle, AI harbor traffic, autopilot, and touch controls extend the simulation across desktop and offline play.

Built with

table of contents

Sloop in Open Water is a browser sailing simulation set in a tropical archipelago. Its portfolio preview combines a fleet of boats, wave-driven motion, weather, navigation instruments, and touch controls.

Implementation focus and constraints#

My focus is the relationship between boat behavior, visible feedback, and the cost of rendering the surrounding world. The source separates sailing calculations from scene construction so navigation instruments can agree without each interpreting the wind independently.

The implementation uses Three.js, TypeScript, Vite, WebGL, and GLSL. Source evidence for this study includes the sailing module and quality configuration in the repository's sailing-boat application.

One definition of wind relative to the boat#

The sailing module computes a wind angle relative to the bow and starboard direction. It handles the difference between the direction wind travels toward and the direction it comes from.

A single point-of-sail boundary table classifies running, broad reach, beam reach, close-hauled, and in-irons states. Keeping that table together lets the HUD and wind rose use the same interpretation. Depth under the keel is another explicit calculation: available water depth minus the boat's draft, clamped at zero.

A rendering budget with visible tradeoffs#

Low, medium, and high presets configure pixel ratio, shadow resolution, ocean geometry, and scenery counts. Pixel ratios of 1, 1.4, and 2 express different rendering budgets rather than a universal quality setting.

Scene builders read the active preset at construction time. Changing quality therefore needs a rebuild or reload; a menu alone cannot update already-built geometry.

Demonstrable result and limits#

The source provides a reviewable simulation architecture and a playable web preview. It does not establish measured frame rates on every phone or suitability for navigation training. The next useful evidence would be device-specific performance measurements and observations of touch handling.

The companion article explains pure sailing calculations and coordinate conventions.