Ship Shooter - Case Study

Overview

A casual, pick-up-and-play game about the sea, ships, and tales — the curiosity of the first people who sailed past the horizon without knowing what was beyond it. Built in SpriteKit with a single shared game core driving both iOS and macOS.

Mechanically it is a pseudo-3D perspective sea you sail toward a horizon, built on one verb: steering. You dodge, take hull damage, and salvage. Shooting, despite the name, is deliberately deferred to a much later upgrade — the core loop is dodge-first.

The part I would actually point at in a review is the process. Every feature must pass a written four-question Soul Filter before it gets built, and ideas that fail are parked in their own document rather than argued about twice.

Swift SpriteKit iOS macOS Xcode Game Design

Problem & Solution

The Problem

Solo side projects die from unbounded feature creep
Every good idea feels worth building in the moment
Casual games drift into progression-system bloat
Two platforms usually means two diverging codebases
Past reasoning gets lost, so decisions get relitigated

The Solution

A written vision document every feature answers to
A four-gate filter applied before any work starts
Good ideas that fail the filter are parked, not argued
One shared game core; platform folders are thin shells
An append-only decision log recording the why

The Soul Filter

Four Gates Every Feature Must Pass

Does it serve the soul — the sea, ships, tales, the horizon, the fool who sails on anyway?
Is it casual and pick-up-and-play, or does it demand a session the game was not built for?
Does it add meaning without saturation, avoiding the busywork bloat that buries casual games?
Would it be painful to remove later — and if not, why build it at all?
A good idea that fails any gate is an idea for a different game, and goes to the parked-ideas document intact
Three non-negotiables sit above the filter: iOS stays primary and nothing dilutes it, offline play works and progress syncs across devices, and feel comes before systems

Key Highlights

Perspective Sea
A pseudo-3D sea rendered in 2D SpriteKit, sailed toward a receding horizon, carrying the full dodge, hull-damage, and salvage loop

One Verb
The entire mechanical vocabulary is built on steering alone — whirlpools are a pull you fight by steering, with currents, wind, and creature encounters designed against the same single input

Escalating Pressure
Waves damage and slow the ship, and stiffen the further out you sail, tying difficulty to distance and creating the seam that a future upgrade system plugs into

The Pull
A thing on the horizon revealed only after some progress, giving the player a reason to keep sailing that comes from curiosity rather than a score counter

Shared Core
Roughly 1,100 lines of Swift across a sea model and scene, shared by both platform targets, with the iOS and macOS folders kept as thin app shells

Docs as Code
Nine living documents covering vision, design, concepts, roadmap, decisions, architecture, references, and parked ideas — a disagreement between code and docs is treated as a bug

Technical & Process Approach

Built a pseudo-3D perspective projection on top of a 2D sprite framework, getting depth and horizon motion without the cost and complexity of a real 3D engine
Kept all game logic in a single shared source folder consumed by both platform targets, so the macOS build cannot drift into a second implementation
Sequenced milestones feel-first: sailing, then stakes, then the sea itself, then a reason to sail on, and only afterwards the mechanical vocabulary — materials and upgrades come after the verbs feel right, not before
Wrote a vision document explicitly designated as the highest authority in the project, so feature arguments resolve against a written standard instead of whoever argued last
Maintained an append-only decision log recording not just what was chosen but why, letting a renumbered milestone plan stay navigable rather than becoming misleading
Set an explicit tuning policy of one balance pass before the art milestone, with a rule to fix only the obviously broken mid-milestone — a guard against tuning paralysis
Deferred atmosphere work to a later day-night and weather milestone rather than letting visual polish creep into a mechanics milestone
Left shooting out of the core loop despite the project's own name, because the filter said the game is about the sea rather than combat

What This Demonstrates

Scope Discipline: Built an explicit mechanism for saying no, and honoured it even against the feature the project is named after
Design Before Code: Established the intended feeling first and made every technical decision answerable to it, rather than discovering the game by accident
Decision Documentation: Recorded reasoning as it happened, so past choices can be revisited on their merits instead of from memory
Cross-Platform Architecture: Structured iOS and macOS targets around one shared core, making divergence a deliberate act rather than a default drift
Graphics Pragmatism: Achieved a sense of depth and distance within a 2D framework by choosing the projection carefully instead of reaching for a heavier engine
Working Outside the Comfort Zone: A Swift and SpriteKit game built by a backend engineer, with the process rigour carried across from production work

A Game About the Sea, Built Behind a Design Filter