Corsairs: rebuilding a pirate world for Mac
I wanted to play Corsairs on my Mac. That modest ambition became a project about keeping an old game alive: a native Apple Silicon engine, a direct Metal renderer, reworked materials, and new rules for the captain, crew, and world around them.
Corsairs is a seafaring RPG in which the same character sails, fights, trades, explores towns, and manages a crew. That continuity is its appeal. It also makes modernization difficult: a rendering change can break a map icon; a new punishment can strand an entire squadron; a camera improvement can interfere with an existing save.
My role was to set the direction, design the new systems, and drive implementation and investigation with coding agents. The original game, engine, and world remain the foundation. This independent modernization project is still being prepared for release.
Getting it to launch was only the beginning
Early work explored Windows compatibility and a native engine with a graphics translation layer. Those experiments established useful baselines, but left several runtimes competing for attention. I made the direct Metal version the sole active target and preserved the others as historical references.
The direction was specific: keep the simulation, content, and existing saves, while giving rendering a native path on the Mac. The candidate has its own application bundle, settings, saves, and logs. A failed experiment should not consume the only playable copy of a character's history.
Source patches now apply in a defined order, builds consume known inputs, and staging prepares one identifiable candidate for a game replay. That repeatability matters when the next change reaches deep into an old engine.
A sea that belongs to the weather
Water was an early test of whether the port was doing the right work. An initial prototype drew ships, land, and interface elements while the sea itself was missing. A running process clearly was not enough.
The renderer grew to cover the original shader families and a new water treatment: angle-dependent reflections, finer surface detail, depth-based absorption and refraction, and foam and water color driven by the game's weather. Dynamic sky work follows the same principle. Time, wind, rain, and fog must agree across the horizon rather than drift through unrelated visual timers.
The work also reaches shadows, window light shafts, vegetation, particles, world-map elements, interface text, and animated geometry. Moving character skinning to the GPU, for example, must preserve the CPU geometry used for collisions and attachments.
The latest connected renderer consumers have been built and staged. Visual parity across real scenes remains an open acceptance step; a successful compilation does not settle how the world looks in motion.
Preserve the world while replacing its surfaces
Material work focused on things a player spends time looking at: dock timber, deck planks, ground, rocks, and tropical vegetation. The challenge was keeping the old assets' role and layout recognizable while improving their surface detail.
These comparisons come from the project's original and replacement texture files. In the pier texture, the vertical and horizontal plank regions retain their arrangement. An attractive wood image alone would not preserve the way existing geometry reads that texture.
Reviewed materials are delivered through an explicit allowlist, keeping a texture experiment from replacing unrelated content. These samples show asset work; final lighting and appearance still depend on the game scene.
A crime needs someone who can tell the story
I wanted the world to react more coherently to the player's choices. The crime model separates an incident from a public reputation change. Attacking a ship makes the target hostile immediately, but wider consequences depend on a report reaching the world.
A surviving target, another ship, a fort, an escaping survivor, or the captain's own crew can carry the story. Seeing a flag and recognizing the captain are different facts. That distinction lets secrecy matter without making aggression consequence-free.
Crew loyalty connects this system to the rest of the game. Morale, leadership, stealth, and unpaid wages affect the risk of a crew report; direct witnesses remain independent. A debt is attached to a creditor when that person is known, rather than disappearing into an anonymous payment counter.
Dialogue aggression adds another entry into this model, while protecting quest characters and scripted situations. The model is implemented; secret incidents, witnessed crimes, and the dialogue-to-combat transition still need their complete Metal replay.
Losing a fight can lead to another chapter
Voluntary surrender creates an alternative to fighting to the death. Eligible guards or bounty hunters can take the captain into custody. A sentence includes time, a fine, confiscated equipment, and cellmate interactions that affect standing.
The interesting design problem was the return journey. If arrest sends the player to another island, their ships must follow. Confiscated equipment must be returned exactly. If the nation remains at war with the player, release must avoid dropping them among hostile guards.
The implemented custody path accounts for the squadron, equipment escrow, save/load, and a safe release destination. A journal entry carries the sentence and fleet location. Full acceptance of that loop on the active Metal runtime remains part of the release work.
Spend less time servicing the crew
Officer auto-supply addresses a quieter source of friction: repeatedly distributing ammunition, medicine, and equipment. It draws from the real chest in the captain's cabin, tops up each enabled officer's deficits, and preserves valid manually equipped items.
Quest equipment and money stay untouched. Officers do not gain remote access to arbitrary containers. Refills wait for a safe cabin state rather than rearranging inventories during combat or dialogue.
Progression work follows a similar approach. Early skill growth requires less repetition, while high mastery retains its cost and existing difficulty and character attributes still matter. Hostile-port overlays add a navigation aid: danger follows the flag currently raised, so changing flags can change the warning.
These systems began in earlier runtimes and now form part of the reviewed Metal gameplay package. The current delivery check reports no pending script files. Each still needs its own gameplay replay before the package can be treated as a tested feature set.
Walk the deck without pausing the sea
The captain can walk around a moving ship while the sea simulation continues. Walking, running, first- and third-person views, and the equipped spyglass belong to the same live encounter. Steering and firing remain available.
An early player replay confirmed walking and spyglass use. It also exposed a problem: the captain could pass through ship structures and sailors.
A protagonist collision gate addresses solid ship geometry. Crew avoidance was explored, then removed from the active build after profiling showed its cost in the sea scene. That was a deliberate tradeoff: retain the useful walking mode and protect the simulation's frame budget. The final protagonist-only collision candidate still needs its sea replay.
Follow the broken state, not the first explanation
The work repeatedly crossed the boundary between what the screen suggested and what the game stored. A colony capture that appeared unfinished was a useful example.
Inspection showed the colony already belonged to the player. A battle marker was waiting for defenders that could not spawn. A repaired copy of the save cleared that stale battle state while preserving ownership, the capture date, and the original save. The subsequent shop and loot interaction still needs an in-game check.
Other investigations traced crashes to dead attribute parents and character targets that no longer existed. These are less photogenic than new water, but essential to making a long-running RPG session trustworthy.
Turning the candidate into an application someone else can use
A staged macOS app already exists. The next milestone is making installation, play, updates, and recovery work without the development environment. My release preparation plan has five gates:
- Freeze a playable candidate. Close the remaining renderer and gameplay replays: menu, land, interiors, sea, world map, combat, surrender, officer supply, and save/load. Exercise unaffected actions beside each changed feature and profile representative scenes under comparable conditions.
- Make first launch self-contained. Package runtime dependencies, provide a clear path for locating the player's game data, and keep saves and settings separate from replaceable application files. Test installation on a clean Mac.
- Make failure recoverable. Preserve saves across updates, make a previous build recoverable, and provide useful local diagnostics. An update must not require the player to understand the patch stack.
- Prepare a distributable build. Complete the engine and asset provenance inventory, choose the distribution scope, and validate signing, notarization, and packaging for that channel. A release could carry the engine and changes while importing the player's existing game data.
- Run a small external playtest. Give testers a complete install-to-play journey, gather reproducible failures, and use the results to decide when a public build is ready.
The result so far is a native rendering and gameplay foundation, a reproducible build, and an evolving playable candidate. The release still has to earn its reliability in the game. What makes it worth pursuing is the continuity: the same old world, with technology and rules that give me new reasons to return.