Coastal Gaming was a gaming community my wife Melissa and I built and ran from 2019 to 2022. It spanned four games, a Twitch and YouTube presence, a website, merchandise, a Patreon and a charity fundraiser — and its flagship product was The Coastal Escape, a persistent pirate sandbox on ATLAS that ran for eleven seasons.
We designed the worlds, wrote the systems, ran the events, recruited and managed the staff, and operated the store. Everything below was built inside someone else's game engine on someone else's hosting, and both of them eventually failed us. This is what we built anyway.
Eleven seasons, eleven original maps
Every season was a ground-up world redesign, not a reset. Each map was authored in the ATLAS server grid editor and then hand-finished as a player-facing artifact: island naming, biome labelling, faction territory colouring, freeport markers, trench indicators, and legible wayfinding so players could orient themselves without a wiki.
Worlds ran up to 36 grids, with per-grid population caps between 20 and 50 players. Each season cycle drew between 1,000 and 2,000 unique players, and grids regularly hit their ceilings — players were sometimes unable to enter a region because it was full.
Segmenting the playerbase into four experiences
Balancing PvE and PvP is the hardest problem in this genre. Most servers pick one and lose the other half of the audience. We tried to solve it structurally.
Rather than a single ruleset, we ran four factions with individually tuned server settings, and told players plainly which one suited them — by skill level, by group size, and by what they actually wanted out of the game.
| Faction | Best for | Environment |
|---|---|---|
| Merchants | Beginners, solos, small companies | PvE, boosted XP/gold/blueprints, boosted breeding, players' market |
| Survivors | Amateurs, duos, small companies | Challenging PvE, realistic food and water, stronger wild tames |
| Adventurer | Advanced, ship battles, medium companies | Open-water PvP, small combat windows, minor boosted settings |
| Plunderers | Advanced, land raiding, large companies | Open-water PvP, daily combat timers, high island upkeep costs |
Player-elected warfare: the Pirate Lord system
PvP players chose a faction, then voted monthly on a Pirate Lord to lead it. The role carried real mechanical authority rather than a cosmetic title.
- Exclusive war powers. Only a Pirate Lord could issue a War Declaration, capped at one per week.
- Scheduled conflict. Declarations were restricted to Friday or Saturday, so land raids landed when people were online to defend. Weeknight raids on absent players had been the single biggest driver of churn — this fixed it structurally rather than through rules nobody reads.
- A private diplomatic channel between opposing Pirate Lords and admins, which turned PvP into negotiated, scheduled events rather than ambushes.
- Mutiny. Each faction had a mutiny channel. If members felt badly led they could vote out their Pirate Lord and trigger a fresh election. Leadership was accountable by design.
- Costly defection. Switching factions meant forfeiting all earned and purchased items, so allegiance meant something.
It turned PvP from a griefing problem into a content pipeline. Instead of admins scheduling conflict, players generated it — with elected leaders, a diplomatic layer, a self-correcting removal mechanism, and a weekly rhythm that respected people's real lives.
Other systems shipped
| System | What it did |
|---|---|
| Roaming PvP waves | Timed danger that swept across grids on a schedule, making safe routes temporary and the world map a live thing rather than a static one. |
| The Maw grids | A high-yield central farming zone in both PvE and PvP variants — deliberate risk-and-reward gating for the best drops. |
| VIP grids | Monetisation designed into the map itself rather than bolted on. |
| Published settings cards | Every season's rates, caps and rules were documented and published to players before launch. |
Six things we built were copied by other server communities: the roaming PvP wave, our Discord structure, our online store model, our map designs, our server configuration files, and the hotel workaround below. New server owners regularly asked us for our settings.
A live events programme
Ten recurring event formats, many streamed live on Twitch. Everything was hand-built in-engine — there were no tools for this beyond the game's own building and painting systems.
The best of them was the boat race. I found an island with a river running through it, then placed and painted buoys along a course for players to sail. We ran it in heats and streamed the finals.
Engineering around a broken platform
Mid-run, our host changed the in-game map file format from JPEG to PNG. Player maps stopped rendering. The host never fixed it, and the developer had by then largely stopped supporting the game.
Rather than accept a broken core feature, we built a social workaround: mass player housing in the home grid. We constructed hotels holding close to two hundred beds, and players logged in and out through that grid to repair their maps. It had to be rebuilt from scratch every season, for hundreds of players.
The fix wasn't technical — we had no access to the code. It was a design solution to an engineering failure, delivered under live conditions to a paying player base, and maintained across multiple seasons.
The Bermuda Triangle map
One season's world was built around a single idea: named biome bands arranged in rings around a lethal centre. Tundra, Polar, Desert, Equatorial, Tropical and Temperate, each split into PvE and PvP variants, surrounding The Kraken at dead centre and flanked by two Lawless Battle Grids.
This is the direct ancestor of my current design, Vanishing Tides — biome regions ringing a central danger zone that players deliberately sail into for the best rewards.
The concept isn't speculative. It's been built, shipped and played by thousands of people. I know how it behaves in the wild, where it breaks, and what players do with it.
What people actually came for
Asked what kept players across eleven seasons, the honest answer isn't a feature. It was us — an unwavering commitment to good content, and swift, thorough action on player or admin abuse. We were a stronghold for fairness. We were an open book, we owned our mistakes, and we grew alongside the community.
| Metric | Figure | Note |
|---|---|---|
| Unique players | 1,000–2,000 | Per season cycle, across eleven cycles |
| Grid capacity | 20–50 | Per grid, up to 36 grids; ceilings regularly hit |
| Volunteer staff | ~20 | Across the run; 5–8 at peak |
| Discord peak | 2,000–5,000 | Sustained at Level 3 by voluntary player boosts |
| Discord today | ~810 | Roughly 80% still from the ATLAS community |
Level 3 requires fourteen concurrent server boosts, paid voluntarily and monthly by players for a community they didn't own and couldn't monetise. It's the strongest engagement signal in the dataset — and roughly 650 of those people are still there years after the servers came down.
We also ran Coastal Kids, a separate moderated Discord space where our community's children could hang out and chat safely. Nobody asked us to build it. It existed because the community had become families, not just players.
Play Games for St. Jude's Children
On 6 November 2021 we ran a 24-hour charity livestream for St. Jude Children's Research Hospital, with merch giveaways running all day and proceeds going directly to the hospital. It raised close to $2,000.
We organised it, promoted it, built the in-game content for it and streamed the full twenty-four hours ourselves.
Revenue
| Stream | Figure | Note |
|---|---|---|
| Online store | $1K – $11K / mo | Typically around $5K; lower in early seasons before the store launched |
| Peak month | $11K | Single month, store sales |
| Merchandise | $1K+ | Lifetime |
| Patreon | Active | Recurring supporter tier |
| Sponsorship | Razer | Giveaway prize during a live event, plus a discount code for community members. We simply reached out and they said yes. |
The online store was the inflection point. Once purchasing became frictionless, revenue stepped up substantially — a lesson about conversion that applies directly to any live game's monetisation design.
Why we shut it down
ATLAS deteriorated. Patch after patch broke more than it fixed and delivered features players hadn't asked for. The game eventually lost official support entirely — its Xbox community still can't play. Our host kept renting servers knowing the experience had degraded.
We could have continued. The community was there, the revenue was steady, and we could have shipped the same game in different colours for several more seasons.
I didn't feel right charging players for the same thing over and over while it got worse. As a player myself, I knew there had to be real value in it to justify the investment. So we closed it.
I'd make the same decision again. But it clarified something: everything we built stood on rented land, dependent on two organisations that had both stopped caring. The next thing needs to be ours.
Since then: shipping software
I now build and operate a production Discord application for a Pax Dei clan — 15 feature modules, a SQLite database, automated web scraping, and continuous deployment to a cloud server.
The Pax Dei Raid & Crafters Bot is at version 2.2.0 and runs as a long-lived process under PM2 on a DigitalOcean droplet. It's roughly 64 source files organised into feature modules, shared core plumbing, and a dispatch layer for Discord's slash commands, buttons, modals and select menus.
What it does
| Module | Function |
|---|---|
| Raid planner | Create and cancel raid events, manage signups and dungeon steps. The largest module at ~1,700 lines, with card rendering deliberately split into a separate pure-function view layer to isolate risky layout code from business logic. |
| Market system | Price tracking, watchlists, craft-flip profitability analysis and a top-farm-target calculator, synced from scraped game data. |
| Clan wood tracker | Resource tracking plus a feudal shrine claim system with a verified gold-donation ledger — members pledge via modal, pledges stay pending until the owner verifies, and the donor list persists for reimbursement if a claim is abandoned. |
| Crafters directory | A searchable board of who in the clan can craft what, at what level. |
| Raid Hall of Fame | Live-computed leaderboard that auto-refreshes on raid and MVP events. |
| Game data lookups | Recipes with a shopping-cart system, named enemies, relics and items — all scraped with Playwright and synced into SQLite. |
| Spawn watch | A passive schedule board rendered with Discord timestamp markup so it auto-converts to each viewer's local time. |
Nightly automated database backups using VACUUM INTO, integrity-checked before retention, gzipped, with the environment file copied alongside because a restore needs both — and a documented restore procedure. Config validation that fails fast at boot with a list of missing variables rather than starting half-working. A syntax checker that walks the source tree rather than using a hand-maintained list, written after the old approach silently drifted to miss eleven files. Log rotation, added after log growth once filled a disk.
Every one of those is a lesson recorded from an actual incident.
The project is developed with AI assistance, which is how a great deal of software is now built. What isn't delegated is the part that matters: the architecture, the conventions, the operational decisions, the judgment about when not to change something. The project's own documentation includes the instruction to only modernise a component when there's a real reason to — "not as a blanket modernization pass." That restraint is the difference between someone who directs software and someone who accumulates it.
The same instinct runs through all of it. The Pirate Lord system had a mutiny channel so leadership stayed accountable. The gold ledger keeps pledges pending until they're verified and retains the donor list so people can be repaid. Both are systems designed around trust between real people — which is the thing I actually know how to build.
What this demonstrates
| Capability | Evidence |
|---|---|
| Systems design | Pirate Lords, mutiny mechanics, scheduled warfare, roaming PvP waves, risk-gated farming zones |
| Product & UX design | Four-faction player segmentation with tuned rulesets and explicit player-facing onboarding guidance |
| World & level design | Eleven original maps with documented iteration and player-facing wayfinding |
| Live operations | Eleven seasons of content cadence, patch notes, testing and crisis workarounds under a failing platform |
| Events & content | Ten recurring live event formats, hand-built in-engine, streamed to audience |
| Team leadership | ~20 volunteer admins recruited, trained and managed across four game communities |
| Community management | Thousands of players, a Level 3 Discord funded by its own members, retention past product death |
| Monetisation | Store averaging ~$5K/month peaking at $11K, plus merch, Patreon and a brand sponsorship |
| Player psychology | Structural solutions to griefing, offline raiding and faction churn — learned from live data, not theory |
| Software delivery | A 15-module Node.js Discord application in production — SQLite, Playwright scraping, PM2, automated backups, documented deploys |
| Product judgment | Chose to close a profitable operation rather than sell a declining experience |
Eleven seasons is a longer live-service track record than most credited game designers have. It was earned in someone else's engine, on someone else's servers, alongside a full-time career leading structural ironworking crews — and it is the reason I know exactly what I would build next.