How We Got Here

The Cygnus Rift is a multiplayer space combat game. The shortest, most direct pitch I have is: Feels like X-Wing, but it's really Guild Wars 2 in X-Wing clothing. Classic flight-assist starfighter combat — planes in space, not 6DOF — inside a persistent world of zones, events, and a world story that has a "front line" of conflict that moves based on what players actually do in game.

This first DevLog entry covers everything up to the date is was published. This is where the idea came from, what the game is, and the six weeks of design that this game now stands on.

It all started as a search for a game to play

I have this really bad habit: when I start looking for a game, I usually can't find it and I end up designing one. I have GDDs for several games detailing the shape, construction, design, and build paths. This is the first one I thought was really worth actually building.

I wasn't looking to make anything. I was looking for something to play.

I play Guild Wars 2. It's my go-to game, and I've had a lot of time in the last 12+ years to think about how it was built. That being said, I was in a drifty phase, probably on-set by the announcement of GW3 and the wrap on new development of GW2. I've done my stint with Overwatch and Fortnite. I cannot play 4X games. 4X games are crack to me; I can't put them down. Dawn comes up and bites me. I won't touch 'em. Cold turkey stays cold. What I wanted was a space flight sim — and nothing had scratched that itch since the original X-Wing. Elite Dangerous felt samey. EVE Online is a lifestyle married to a spreadsheet more than a game. X-Wing from EA? My mother told me that if I have nothing polite to say, say nothing. I tried various recommendations. None of them was the game I was looking for. I came to the conclusion that was because the game I was looking for didn't exist.

So the question changed shape from Where is that mythical space-sim? to Why can't the original X-Wing be made multiplayer?

So I began to research. History says it was tried: X-Wing vs. TIE Fighter, 1997. Failed on execution — it shipped without a campaign — not on premise. There have been others, all with clear and catalogued failure, but this isn't a history lesson. One thing that stood out as a key component was story, and campaign. And in the intervening time GW2 quietly solved that problem: Who's the protagonist in a multiplayer story? Answer: Everyone! Every player is The Commander, or The Wayfinder or, in our case, Captain.

This brought me to the larger picture, especially since space is naturally located, and not a continuous streaming world: If GW2 has solved the STORY issues, can we leverage the instanced model of zones, metas, and a progressing story, both personal and global? Everyone has their own story. Yet everyone comes together at the briefing. Everyone launches from the fighter bay in a heap. Everyone forms up to meet the threat. Commanders, with docking space in their personal carrier, organising the fight. Multiple simultaneous goals to defeat that threat. Shields to take down. Armoured modules to crack. Fighters to deal with. Bombers to intercept and knock off their attack run.

I kept asking "Why not this?" and "Why not that?" The answer kept coming back "There's no good reason no to." The bad habit had struck again, but this one was really good.

What the game is

The core loop, as it stands on paper:

• Zones with living events. Each zone has story related content; both for the individual pilot, and for the zone in general. Each zone outside of the starting zones runs population-weighted metas with stages and multiple simultaneous objectives. Players self-distribute rather than stack on one marker. Individual objectives can be structures, capital ships, and escorts with shared health pools. Diegetic "chatter" will help guide players to the next goal, or identify when a goal is at risk of failing. The enemy fighter screen is the texture you must deal with to reach the objective, and this screen becomes one of the goals. Players can choose different ship chassis to build custom loadouts for specific roles and play styles. Are you in gold squadron starting your bombing run? Or red squadron providing cover?
• Failure is content. Events don't reset to a checkpoint when they fail — the world state accepts the outcome, moves on and the next meta deals with the current state. Fail to repel the pirate incursion? The pirates have control of the station. Does your secret affiliations allow you to dock anyway?
• A seasonal front line is authored from the aggregate outcomes of all players in all zones over a specific period. What players collectively do shapes where the story goes.
• Cockpit flight, X-Wing handling. Pitch and yaw do the work, roll is how you orient, mass is live, and as a stat, you feel it every second. The depth comes from your ship's loadout, not from six-axis gymnastics. There may (will?) be drift abilities, but these are special cases, not the standard 6DoF from other games. 6DoF doesn't fit this world. Mass and Power do.

And some early rulings that shape everything downstream:

• The power plateau. There won't be the ever-bigger-ship treadmill. That kills this kind of design. Progression is horizontal. You get different, not endlessly bigger. Which leads directly to:
• Your pilot is never a stake. In EVE, losing a ship means losing time-denominated value — that's why it's a lifestyle. Here, the plateau plus salvaging a destroyed ship means defeat costs you the fight, not your progress. Consequence lives at the collective level, in the seasonal front, at the story progression, not in personal ruin. Pilot progression is a question of versatility as much as power.
• Capital ships are a population, not characters. They're weather systems you fly around and against. Both enemy and player factions will have large capital ship — including fun variants such as the shield frigate, an advancing umbrella that paces an assault on an enemy capital ship and gets small fighters in range.
• Carriers and other multi-ship platforms come in the mid-game.
• Personal Living Space will start early but small. A place to stash your trophies.
• One pilot, one ship (at a time!) No crew management. You fly. That being said, a Pilot will have access to several hulls, and mid-game there are scenarios for multiple players sharing a single hull.
• As an instanced game there will be special scenarios where the standard pattern shifts completely.

Building it: the ground rules

At this point, I'm one developer. The plan is to grow into a team. However, the fact of a solo starting point drives every technical decision, and three rules were set before anything else:

1. Networked from day one. The single biggest cause of death for indie multiplayer projects is bolting networking on later. Here, even a single-player game is a server with one client. The very first playable milestone isn't a fun demo — it's one hundred headless clients flying dead-reckoned shapes while I measure tick rate and bandwidth. Prove the skeleton before dressing it.
2. Everything is data. Code as verbs; data as nouns and numbers. Events, enemies, ships, and loadouts are all definitions the systems read — which is what makes a one-person content pipeline survivable. This also makes the game incredibly efficient to manage, run, and update.
3. Plan your Dive and Dive your Plan. Everything is planned on paper before any work is done. No fishing expeditions. There will be no rescues. You will see in the Six weeks on paper that I am trying to predict and design as much as I can before committing any work in any engine with any code; and six weeks is only the beginning.

The stack is Unreal Engine 5 with its modern networking and mass-simulation systems, targeting around a hundred concurrent pilots per zone instance.

Off-the-shelf flight kits were evaluated and rejected — the deciding factor was networking architecture, and that told me the order of operations: networking package first, flight sim fitted into it. Flight kits also did not allow me the mass & power flight mechanic I am looking for. I want a heavy bomber to feel like a heavy bomber due to its mass; and just like a B-17, when the ordinance is 'dropped', the ship will lighten and fly differently — and all based on a flight model that takes mass into account.

I use AI-assisted tooling openly in the programming workflow — that's part of what makes a solo project at this scope thinkable at all, and it will be visible throughout these logs. I plan to have specific posts on exactly how I'm using this, so the transactions will be transparent.

The art side has its own story and deserves its own post. My background includes physical model-building and miniature work for screen. Exactly how that craft translates to a digital pipeline is a topic for a proper workshop entry down the line.

Six weeks on paper — so far: The Dive Plan

Here's what "designing one" actually looks like, dated. Everything below happened before a single line of engine code was written.

Please remember any of the following could change at any time due to fluctuations in game design, or the necessities of engineering.

Early July — Inception

• The game hunt, the question, and one long design run — at that point, just for fun — that produced the core loop: zones, metas, failure-as-content, the seasonal front.
• The foundational rulings above, plus: item rarity converging at the top of the ladder, enemies that read your kit, and players being able to read the enemy's (Is it a fighter? A bomber? What should I expect when taking this ship on?), the dock as a "waypoint" that can be "jumped to".
• 8 July — first design document cut. The feedback pass added the first meta: six-phases building up to a capital-ship conflict, the shields-vs-armour archetype split, regional markets, weapon families.
• The setting frame established alongside the mechanics: a political map of small states and principalities, an antagonist polity, a speculative alien species, and an underworld layer. Oh — and of course, pirates.
• 9 July — design document v2: a phase plan with gates — each phase has a test it can fail and tells us what survives and what dies.

9–14 July — The design consolidation week

• 9–10 July — zone design settled: three-tier travel (combat speed / cruise / micro-jump to discovered beacons), zone boundaries as a gradient with in-fiction feedback ( leaving the populated zone takes the player away from any nav beacons and the computer announces "no nav fix — insufficient beacon triangulation"), seamless zone-jumps as a three-beat sequence. Guild institutions, cosmetics, and ambient discovery drafted.
• 10 July — the death cycle ruled: a four-grade loss gradient from disengage down to riding it in as the final act of sacrifice, with insurance making rebuilds cheap or free and reasonable time the only cost. Transient-content ruling: authored content never gets deleted, it retires into a library; permanent world changes must explain themselves in-fiction.
• 11 July — finalising the diegetic layer for most content and solidifying the core rule that everything is described diegetically.
• 12 July — ship ontology: chassis = class = role (Scout, Fighter, Bomber, Support, Torpedo-boat), not weight classes; role classes. Three limiters with three jobs: typed sockets for identity, energy budget as the build governor, mass for feel. Ships are Hulls that use a stock Chassis, can are equipped with Items & Utilities allowing a large build variety in every chassis. Terrible build choices are possible.
• 13 July — identity architecture: the account owns, the pilot is, hulls are owned biographical objects. The ship is the player's ledger; the pilot is the world's ledger. Carriers, jump rules, and facility services ruled the same day.

15–22 July — Money, pipeline, and infrastructure

• 15 July — sustainability model built: pricing structure, break-even bands, and the rule that the plan is made against the floor case, with anything better treated as upside. (The numbers stay internal; the discipline is the point.)
• 15–18 July — the asset pipeline found its shape the hard way. First approach failed its kill test — mechanically sound, output quality dead on arrival. Four more attempts at the first hull failed the same way. What survived: a reference-driven rebuild approach, hard gates on every pass, and a parts catalogue that grows as residue of real hulls rather than being pre-built. Knowing which road is dead is worth as much as knowing which one is open.
• 17 July — enemy AI architected: manoeuvre playbooks instead of point-and-chase pursuit, proportional navigation for gun-runs and missiles, a stalemate detector as the anti-circling valve — verified against how the classic sims actually did it.
• 18 July — persistence designed: database engine chosen, an event-ledger write model, and the identity spine (accounts → pilots → hulls) as the schema's backbone. Working principle stated: never pour concrete that future versions have to break. Stay clean and fluid if possible. Leave drill-holes in the concrete when things need to be rigid when and where they cost nothing, allowing the future content the access and anchor points it needs. (Plan/Dive)
• 18 July — 90-day production inventory built: every asset and system the first milestone needs, as a flat list plus a dependency map; triggered by the first line of code.
• 22 July — external architecture research (clean-room, no project documents open) to check the plan against sharded-MMO best practice. World-building filed: the first faction, the antagonist species' biology, and the first location concepts.

Late July – early August — Family holiday

• The gap is a gap. Tools down, family time.

10–22 August — System deep-dives

• 10 Aug — flight system ruled: a two-stat model (Mass, Power) with all behaviour derived from global constants. Pitch and yaw at equal authority, roll presentational, top speed as thrust/drag equilibrium. Accessibility ruling: gamepad is first-class; no expensive-hardware lock. KBM is a must as a possibility, tho' admittedly not first class.
• 14 Aug — fitting system ruled: four layers — Chassis, Modules, Infrastructure, Actions — over a shared generation pool feeding three power banks: engines, weapons, shields; at this point sensors, life-support, etc. are automatic. Overflow is wasted by default; infrastructure — if enabled by in game upgrades — can route it, lossily. Ship logistics ruled the same day: ships stay where you leave them. Players can easily move to different ships.
• 19 Aug — extensive due-diligence review: five alternative structural spines for the game assessed against the current direction. Verdict: current direction is the lowest-risk viable path, and the one serious rival is reachable as an evolution later, not a fork now.
• 22 Aug — player identity ruled: pilot names, earned call signs, ship names, friend nicknames — all public strings non-unique, because uniqueness is a database problem and the database has it covered invisibly.

23–24 August — Architecture week

• 23 Aug — the architecture bible: full deployed topology from client through login, orchestration, zone servers, and persistence, with the complete data spine and its invariants. This is the map, not the journey.
• 23 Aug — a narrative session settled the campaign's escalation arc — three tiers, from local squabbles up to something much stranger — and the first-contact mystery that opens it, but not until season 2 (whatever that is).
• 23–24 Aug — networking contract, four rulings: every weapon is a travelling projectile, server-authoritative, no lag-rewind of any kind; your own flight and power banks are fully client-predicted and deterministic; every aimable ship is presented identically regardless of how it's simulated under the hood; replication runs in three rings by combat relevance.
• 26 Aug — documentation reconciliation continues. DevLog opened, and the daily record starts here.

What happens next

Nothing switches over at this line. Design doesn't stop and building doesn't suddenly start — there's a lot of design still to come, and the six weeks above were work as much as anything that follows. What changes is the record: from 26 August the work gets logged day by day, and this is where that log begins.

What the six weeks bought is enough proof of concept and design shape to get started — and enough to say we must get started. The next thing that matters is the first gate, which tells us whether this is a go.

First up is the least glamorous milestone imaginable: a server, a hundred fake clients, and a bandwidth graph. If that holds, flight feel comes next, then the first zone and the first meta event.

Not immediately, though. Before that server is worth building, the design has to be far enough along that it knows what it's serving, and the architecture has to be worked out well enough that what we build is built correctly. That work comes first, and there's a good deal of it. The server is what we're driving at, not what's happening next week.

Posts here should be short, and they arrive when there's a week worth writing about — usually weekly, sometimes not — aligned to what actually got built. If there's a quiet stretch, there'll be a quiet log — I'd rather write "wrestled the build system for a week" than pad. I will admit that I plan to use these devlogs as a bit of an historical record of what has been happening, so … read on if you dare.

Discuss this on Discord