Engineering has started!
The most basic engineering started on Monday.
By Sunday the project has version control proved under load, a name the .exe will carry to release, the form every object in the game will be written in, and a written method for blowing a ship to pieces.
Here is the week.
Monday — version control, under load
The repository runs on Lore, Epic's own version control. It is admittedly in development, but we have additional backups in place, and with one developer, not investing the time or money in a more complicated system is worth it. The alternatives are running a local server (time and capacity) or running a cloud service (seriously and prohibitively costly at this stage). As the game progresses, this will be reevaluated, but we need lean and mean now.
Then a probe, because version control you have not tested is a mirage made of wishful thinking. Create a repository, commit, push, lock a file, restore from the repository, and commit again from the command line. All passed, first time.
That is the foundation under everything that follows. From here nothing made for this game should get lost, and any build should be rebuildable exactly as it went out.
Tuesday — the solo question
Is there a single-player version of this game and where would it fit? Is it a fallback option if the multiplayer is "too much to do"? Can we use it as a less expensive on-ramp? And if either are true, does it come first? Or when do we pull the 'chute and fall back?
Due diligence.
A full day on it, and the answer is that there is no reason to build one now.
A multiplayer game with one player in it is the single-player game, and it fits both bills.
As the fallback: a solo mode of this same game, with the server running on your own machine and the population weighted to one. It is also what lets this game outlive its own servers. If the hosted game ever stops, we can distribute the server itself and you should be able to stand one up on your own and keep flying rather than watch the thing vanish on a countdown. This is now a deliberate feature of the architecture.
As the on-ramp: the solo mode is the demo. A demo that needs a populated server is a dead demo. A demo you can download and fly alone, on the real code, is the demo.
A separate single-player campaign — its own store page, its own launch — is out. It would be a second game, the size of everything between here and the first playable build, carved out of the schedule of the first. And this project, The Cygnus Rift, gets one launch moment: opening early access is a fraction of the work, arrives sooner, and is the larger funding event.
Making a purely separate solo campaign can come later if players want that, and it could run alongside the open world.
With this in mind, from the second build phase onward, there will be a standalone build of the game — one executable that runs the server on your own machine, with no remote server and no login service to reach — and every phase has to build it and boot it before that phase counts as done. It does not have to be playable yet. Its job is to prove the solo path is still open. If any code has quietly started assuming a server exists somewhere else, the standalone build breaks, and we find out that week rather than later, maybe years later.
Keeping that cheap comes down to three places where the game touches the outside world, each of which goes through one door. Saving goes through one module. Login goes through one call. And a jump destination in another zone is described by what it is, never by where the server for it lives. Swap what is behind any of those doors and nothing on the other side has to know.
The engineering underneath is a straight piece of luck. Epic's documentation states multiplayer logic runs in standalone mode with no extra work, and warns that a project built without networking needs a rewrite to add it. The networking-first decision was taken on day one for entirely different reasons. This is a one-way street, and the project is already headed down it in the cheap direction.
One risk on the record: with one player, enemy behaviour carries one hundred per cent of the content quality, and enemy behaviour is the least proven system in the design. Multiplayer hides a mediocre opponent. Solo does not. A single-player product is a harder bet on the weakest system, not an easier one.
The day also turned up two UK funding routes. One is a grant that pays into a defined block of work, matched against what we put in alongside it. The other is a tax credit on qualifying UK development spend, which is recurring rather than a one-off — it applies year on year for as long as the work does. We are registered on the grant platform. The next round is not open yet. No numbers or dates here until something is signed.
Wednesday — voices
Every voice in this game is synthesised on your machine as you play. There is no library of recorded lines, and for what we want to achieve, there can't be. We want to be able to call out your callsign and ship name. Both are things you type when creating your pilot, and the radio hails will be assembled from parts. This will also allow us a much larger pool of content without overwhelming both the production pipe and the game build. The lines that make the comms feel alive are exactly the lines that cannot exist as prerecorded audio files.
One rule governs the whole system. A voice lasts the lifetime of the character. A throwaway line of chatter, one line. An encounter speaker, the encounter. A named character, the whole game. We will curate the named or recurring characters, but the system will grab and maintain the other voices on the fly, and keep them as needed. A station's traffic control centre could be three or more reserved voices on a rota so it reads more like a control room with shifts rather than one person who never goes home. Event announcements could take a fresh voice every time and be assigned to a character role for the duration of the event.
The quality target is as professional as I can make it, and there is a floor under it: if the on-board text-to-speech cannot be made to sound reasonable, we fall back on recorded, repeated lines, like every space game you have ever played. A target with no floor under it is a wish, not a plan.
A lot of the best open voice software is distributed under the GPL, and the GPL has a condition attached: combine GPL code into your program and the whole combined thing has to be released under the same terms, source included. Epic's engine licence forbids exactly that, and no commercial game is giving away the engine it was built on.
So nothing under the GPL or a Creative Commons ShareAlike licence goes into a shipped build, and our packaging step refuses any component that is not on a licence manifest. That rules out an entire category of voice plugins on Fab, Epic's marketplace. Every one of them depends on the same GPL text front-end, and not one of them says so on its listing. There are ways through, and they are costed and scheduled.
Quality is the design question. The open one is cost, and it gets answered with a stopwatch rather than an opinion — four measured tests sit between the build phases, timing what live synthesis takes out of the frame budget. Frame rate may well matter more than perfectly diegetic voices, and that is a decision to make on numbers.
Thursday — how everything in the game is described
A design session on the data structures behind every object in the game, and the rulings from it that will show up in play.
Everything in the game exists at up to four levels, and each piece of information belongs to exactly one. The field list, in code. The authored record — the definition. The live object in the world, pointing back at it. And the row in the database that remembers it.
One record type for anything you can own. A weapon, a slab of plating, a cargo pod and a licence are the same kind of thing with different optional parts bolted on — fittable, container, launcher, charge pool, consumable. The case that proved it is a cargo pod you fit to a hard point: fittable and a container at once, which a class hierarchy cannot express and a set of parts can.
The chassis stores causes, not answers. No ship record carries a top speed or a turn rate. It carries frame mass, base integrity and a list of containers, and speed and handling are computed from mass and power. That is exactly what makes bolting a heavier gun on slow you down, and it is why there is no cap stat to tune.
Every socket, bay, hold and slot is one shape: the tags it accepts, a capacity in points, a maximum number of items, and optionally a flag marking it required. A four-point mount group takes four light guns, two medium, or one heavy, where a light gun costs one point, a medium two, and a heavy four.
Some fitted modules cannot be removed, only replaced. To get an installed module out of a ship, you have to put something in its place. What comes out carries a condition — used, damaged or broken — and sells on at a loss. Connectors and conduits, the links between a ship's systems, are the first case. A chassis ships with this "infrastructure" built in. You can't remove required infrastructure. You can only replace it, even if it's a downgrade, so your ship will always "work". You can't build a ship that won't fly. The hangar will be able to supply cheap basic parts if you want to remove something of value. That being said, some, if not many, components won't come out without being damaged or destroyed.
A saved build is a Loadout, made on "The Bench". The Bench is a workspace where a pilot can experiment with builds and loadouts without monkeying with their real ship. In our mid- to long-term plans we would like to make an offline, mobile Bench, so a pilot could build a ship on the train and apply it when they get home. Using loadouts, getting the dock's robots to do a quick refit mid-session will be quick. The Bench and loadouts are unlocked while progressing the main story, and later, additional loadout slots can be earned or found in game, or purchased.
A licence is a consumable item. Use it once, it makes a permanent change, and it is gone — a paint scheme unlocked on your account, or an ordnance bay converted to cargo on one particular hull. Conversions and cosmetics become things you can find in game or be awarded, rather than things you must buy from a menu.
Left open on purpose, for playtest rather than argument: two ways of calculating drag. In the first, drag scales with mass, so a heavier ship runs out of thrust sooner and a bomber never catches a scout. In the second, drag is the same for everyone, so a bomber can reach a scout's speed — but it handles like a barge when it gets there, and the skill is knowing when to slow down. Nothing is capped in either; top speed is simply where thrust and drag meet. One constant separates the two, and nothing on any ship changes either way, which is why it waits for something to fly.
Friday — the website, ships, and reaching out
An extensive rework of the website and the Discord channel — the two places this log lives and where the conversation about the game happens.
The ship in progress got a long build session in Blender, and two research threads ran alongside it: kit-bashable parts for stations and structures, and kit-bashable greebles for ships. Greebles are the small surface detail pieces that make a hull read as machinery rather than a shape. Kit-bashing is what the model shops did on the classic films: a library of good parts, combined and recombined, so the effort goes on the silhouette rather than on modelling every rivet by hand.
More teasing! Just filling in time when I can...
Also on Friday: long-term planning moved on a little. The coding conventions were started. And I reached out to artists, and to potential mentors and partners.
Saturday — the engine, and the name the engine knows
Two things settled that will be true for the life of the project.
A persistent world needs a dedicated server, and a dedicated server means building the engine from source. The engine as installed from the launcher can build the game you play, but not the server that runs the world. That build target only exists in a source build. The plan had the source build in the second phase, after the project was created, which would have meant creating the project on one engine and migrating it to another mid-phase. Building the engine from source moves to the first phase, before there is anything to migrate.
The engine's name for the project is CygnusRift. The game has had its name since the first week of this log; what was settled on Saturday was the identifier the engine and the build know it by. The name typed at project creation becomes the code module, the build targets, and the executables that end up on your machine as CygnusRift.exe and its server. Changing it later is a manual find and replace across every file in the codebase. We won't be doing that.
Sunday — mentors, growth, funds, and how a ship comes apart
The day started on a session with business mentors on growth and funding, and a look at government-backed loans. We discussed local hardware vs cloud options, small business expenses, talent acquisition and more. All in the pub and later over ice cream and coffee. One of the hard gripes was over how differently the government and its programmes perceive talented artists, their availability, and how to contract them… the reality being quite the opposite of how many programmes to support them are run.
The rest of the day was spent on what a ship mesh has to be so that it flies well, renders well, and breaks apart convincingly.
Every ship is one mesh. Hull and greebles together, no separate wreck model. It flies as an ordinary static mesh with simple collision shapes, and it is cut once, in the editor, into a destructible collection. Nothing is cut while the game is running — the pieces are decided in advance, and the variation between one death and the next comes from which charges fire and how deep the break goes. If we have the ability, we will probably try to cut the hero ships in several different ways — production time and game size dependent.
The death sequence has a name — the deathcycle, one word for the whole machine from the moment integrity hits zero: destruction, pod, wreck, the window in which the ship can be rebuilt, and the downed branch when it happens. The server decides what happened and hands out the same random seed to everyone, so every client sees the same death. The client throws the fireball, swaps the intact mesh for the broken one carrying the ship's momentum, and fires timed charges through it. What the pilot sees is deliberately still open: the camera may pull back so you witness your own destruction, and your ejection, in third person.
One of the solutions that I've come up with for a cascading destruction is to replicate the way we blow up real models, and have embedded "squibs" within the hull, engines, or other parts of the ship. If, for example, the engine blows off as a unit, a moment or two later the squib goes off and blows up the engine. If the engine was already in pieces due to how the forces destroyed the model, the squib will just go off and add to the overall destruction depending on where it ends up.
Next: the engine source build, the network task, and the first sitting that ends in a compile.