Tidewater is a fishing game with its own WebGPU renderer
Cast a line, keep its tension under control, and sell the catch to buy better gear. That's the playable loop described in Tidewater's README. Around it sits an island you can explore on foot or by boat. For an open-source reader, the interesting choice is underneath: the project draws its world directly through WebGPU and WGSL shaders using its own rendering engine. A fork means taking responsibility for that engine as well as the game.
Our checkout occupied 58.8 MB and contained 430 files, with roughly 86,362 source lines. That's a fair amount of code to inherit if you only want a fishing mechanic for another project. The folder map separates game logic from the ocean, sky, and renderer, which gives an experienced graphics developer a sensible reading route. Start with the subsystem you intend to change before treating the island as a general-purpose game template.
What happened when we ran it
Our sandbox installed Tidewater commit 4811ba4 in 23 seconds, adding 24 packages and using 152 MB on disk. The build succeeded in 15 seconds. The test command failed after 6 seconds with exit code 1. We cloned it on October 12, 2026, into lab-node:22 with 3 CPUs and 8 GB of RAM, without secrets or elevated privileges. The source-to-build path worked, while the complete test step did not.
The supplied log tail contains passing checks for fish records, released catches, older saves, blocked storage, gear purchases, fuel, and the fish finder. It ends with an ok line for the fish finder. None of those lines identifies the failing assertion or error. The exit status still matters. We can't call the suite green, calculate a pass total, or diagnose a GPU or system-package problem from this excerpt.
Npm audit reported 0 known vulnerabilities in our run. The scan found 1 CI workflow file, a tests directory, and no Dockerfile. Those are useful repository facts, but they don't establish browser compatibility or validate the game's visuals. In particular, a successful static build doesn't show that a user's browser can obtain a WebGPU adapter and display the scene. That needs a separate check on the devices you intend to support.
WebGPU support is a condition of playing
The README requires a recent WebGPU-capable browser and a capable GPU. Issue 17, titled about a missing WebGPU adapter, asks for WebGL2 support. That is directly relevant to someone sharing a browser game with a mixed audience. A browser requirement in the README is not a promise that every machine running that browser can render this island. Tidewater offers no documented WebGL fallback in its requirements.
The 15-second build result doesn't settle the first-load experience either. The README warns that initial shader compilation can delay entry and says cached later visits are quicker. We did not measure that delay or a gameplay frame rate. The settings and URL switches can disable clouds, haze, vegetation, or other effects, but reducing work after a supported renderer starts is different from supporting a machine with no usable adapter.
Progress stays in the browser that saved it
Tidewater stores the player's money, catches, and upgrades in localStorage. The GameState source guards storage access and lets play continue when it is unavailable. That's a considerate failure path, although continuing to play won't create durable progress if saving is blocked. Someone expecting an account-backed save that follows them to another computer should choose a different arrangement or build that capability themselves.
The 6-second failed test step included passing log lines for older save data and blocked storage. Those are encouraging checks within the supplied excerpt, without resolving the overall failure. If you fork the game, think through what happens when site data is cleared or the hosting origin changes. A locally saved collection of fish should not be advertised as recoverable across browsers unless your fork actually provides a recovery path.
Static hosting is simple; adapting the game takes source work
The local instructions use npm and Vite, and the build produces a static dist/ directory. The README describes GitHub Pages deployment from the main branch. Basic play doesn't require a hosted model credential or a database. The documented controls rely on a keyboard and captured mouse, so the README is a poor basis for promising a touch-first game. An open iOS-wrapper proposal also shouldn't be confused with released mobile support.
Installation used 152 MB in our sandbox. That modest development footprint leaves the larger ownership question untouched: a custom ocean, renderer, and game systems have to be understood when they break. The credits file helps with reuse by separating MIT code from third-party asset licenses. It also says interface fonts load from Google Fonts at runtime. A self-contained offline fork would need to account for those requests.
September source activity and October proposals show an unfinished queue
The repository's last push was September 25, 2026. GitHub listed 1,248 stars and 13 open issues and PRs on October 13, with recent discussion on proposed island additions. Pull request 18 proposes changes for constrained WebGPU adapters and remained open. Those proposals show contributor interest, not merged fixes. GitHub returned no latest published release, which alone says little about a project distributed through its main branch.
I'd use Tidewater to study a complete custom graphics project or to make a deliberately targeted fishing-game fork. For a new browser game aimed at varied hardware, compare three.js or Babylon.js, both broader rendering foundations rather than replacement fishing games. Before committing to Tidewater, require a working run on your intended browser and preserve the full failing test log. The build we've measured is ready to inspect; the missing failure detail is still work you'll need to resolve.