Still on Paper
This week the game got its geography: where a zone stops, what fills it, how you cross it, and what it looks like when a ship dies.
The first engineering phase is not a flight demo. It is a server, a heap of fake clients and a bandwidth graph — and it is only worth building once the numbers going into it are real rather than made up on the day. You cannot put a hundred robot pilots in a zone before you have decided what a zone is.
So that is what this week was: zones, cruise, effects, and one clean, clear audit of where the whole project actually stands.
Monday — where does a zone stop?
A zone is one contiguous volume with a population cap, sited at a real celestial body. The problem is the edge. Hard walls are ugly and everybody knows they are there.
The first line of investigation was Unreal's total scope, and that turns out to be about an AU. Yes, and astronomical unit. Cool! The edge of the zone is reachable... in about 50 years of solid and constant gameplay. Go for it!
Currently we are working with three radii. A working core where content lives; a field envelope of a few hundred kilometres beyond it where the same dust and gas continues, unauthored, generated free; and then open volume. Nothing announces itself. The medium thins, the reasons to be out here run out, and eventually the navigation stops being able to tell you anything useful, and then stops working at all — no beacons in range. Players can jump back to the last known beacon at any time.
What makes this work are keeping several ideas separate: how much stuff is in a zone, and how much medium is in a zone, and how big is a zone. Once they are separate, a zone sitting at a gas giant can have its content stop long before the ring does, which is what actually happens in a real system.
This led straight to rings and planets. A ring is a density field spanning the true annulus — real world sizes — so it reads as a ring location rather than as an invisible sheet you fly through. The planet will be a real sphere at true scale and true distance as well, so it is never a skybox cheat you can catch out by flying at it. Your NaviComp may prevent you from harming yourself when you reach gravitational forces of any magnitude, but you can try to fly there... again, if you have the patience. Real Saturn numbers went in as reference. The one honest piece of science is that a real ring is thin enough to be nearly invisible edge-on and at flight speeds, crossed in a flash of sparkle and then gone. I will have the play-style of exploring a ring of ice… art over science; but I am also going to have a point where the ring is honest and only about ten metres thin. Two different planets, tho'. (Spoiler alert… oops… too late.)
Then cruise got reworked, and this is the change I am happiest with. Cruise now happens in a second coordinate layer that maps to the real one. That layer holds volumes, not entities. No other ships (formations excepted, see below) — only exclusion volumes: planetoids, dense fields, colonies, and any firefight big enough to matter. That turns cruise from a destination you set and then go make tea, into a route you fly with things to fly around. You won't be able to cruise through a battle. Arrive out of cruise and your weapons and shields are down, restoring once the ship recovers from cruise. Appearing from cruise is a legitimate surprise, with the locals slow to react — which is precisely the window that makes turning up under-charged into somebody else's fight a viable thing to do rather than suicide, and a good reason to have kinetic weapons and warheads. This also makes "stage diving" or "photo-bombing" a battle possible; aim at the battle and the NaviComp will drop cruise when you come too close and the player arrives at the battle — understanding that crashing out of Cruise makes the power floor lower and there is less control of the ship while it recovers from the crash-out. It could make a splashy entrance however, when we get the crash-out vfx sorted.
Formation flight extended to cover cruise, because you cannot fly somewhere together if the formation drops the moment you engage cruise. Formations break on a number of situations: strong attitude changes, obstacles and crashing out, etc.. A break at cruise throws your wing a long way apart. Everyone tumbles on cruise exit, always — which quietly kills the idea of being ferried around while making a sandwich. I'll post a more dedicated "Formation" post as there is a lot more detail to formations, "commanders" and other cinematic and diegetic gameplay choices.
Also on Monday: the site finished its rename, and DevLog 01 went up.
Tuesday — a short day
Household and family, and a stretch of web work on the new domain and the Discord server. Not much to show. I did work, and work a lot, but not much to show. I hate web-dev; but we have a website landing page, the devlog, and a Discord server.
Wednesday — glossary, cubes, and a fist
Another sweep through the design set, and the start of a glossary — an alphabetical index of every term the design uses, with a pointer to the section that owns it. That sounds like bureaucracy. It is actually a leak detector: writing the entries is what exposes two words being used for the same thing, or one word being used for two.
The one genuinely productive piece of design was architectural: the shape of a point of interest. A zone is not a smooth field of activity, it is eight to twelve places where content lives, joined by short cruise hops. Working name for the volume itself is a "cube of interest." This is not about how big the zone is; it is how big the box around content is, and what fills the space between boxes.
First pass at a logo or the first local faction emblem: a raised fist with a lightning bolt through it, in a winged frame, dark red on white.
Thursday — the plan gets taken apart
A full day on the production plan.
The plan's own vocabulary was the first casualty. Now there is one ladder of numbered phases, each with a single Goal it either meets or does not.
Then a verification pass against the engine documentation, which cost the plan a system. The modern replication layer — Iris — is production-ready and is what the game will run on. The mass-simulation system, which was in the plan for enemy fighter populations, had its core overhauled but its replication is still experimental and the bridge between the two did not land in this version. So it is out. Enemy fighters will be ordinary replicated actors, and the plan is simpler for it.
DevLog 00 said the stack was "Unreal Engine 5 with its modern networking and mass-simulation systems." Half of that sentence is now wrong. Mass is out. That is what a prepped paper plan is for.
We investigated UE6, and the changes the new version will bring, but the release timing and changes at release are small and faraway, so we can just safely stick with a data driven 5.8 model.
Other important decisions from the day: Rendering stays on the modern path — the virtualised geometry, the dynamic global illumination, and the many-lights system — with the client floor set at a 2060-class card, which is the machine I have to actually hold sixty frames on. Version control settled: a local, version-pinned repository with simple cloud backup underneath.
One thing the day finally exposed, a point I knew was coming: weapons. The design has been treating "weapon" as one thing. However, a launcher and the ordnance it fires are two different objects with two different definitions. That needs its own session before it gets written down. Known issue, good to see it surface.
Friday — the schedule, and how things blow up
Morning on the schedule, task by task, hunting for the places it will drift rather than the places it looks tidy. Every task now carries the condition it has to pass to be called done. The estimate is frozen as a baseline before the clock starts, so that when the actual numbers come in I can measure how wrong I was and by what ratio, rather than quietly editing the plan to match reality.
The public roadmap got rewritten to match: it talks, it walks, it flies, it fights, it persists, it's alive, it belongs, it has people in it. That is the whole build in eight words and it is a more honest description than any date.
The rest of the day went to effects, which had been a stub in the design set and is now a proper section.
Four budget axes, because "can we afford this effect" is four questions, not one: what it costs the graphics card, what it costs the network, how those change with distance, and — the one people forget — what it costs me to author it. A one-person project can be sunk by an effect that runs at four hundred frames and takes three days to build.
Every effect in the game gets a row in one table, with a column per quality tier, so the low tier is a designed thing rather than the high tier with bits switched off.
Then four recipes written properly:
Projectile impact. Shield hits and hull hits are two different systems, because they are two different events. Every ship carries an invisible egg around it that only reveals where and when it is struck — and as the shield weakens, the reveal starts to flicker. That means shield strength is readable from outside the ship, by looking at it, with no interface element at all.
Fighter destruction. The fireball engulfs the ship at every quality tier, so the moment reads the same for everyone. At the upper tiers, what emerges from the fireball about half a second later is the broken ship, still burning, still carrying its momentum. The reference is the Rebel fighters at the Battle of Yavin, and it is the reference for a reason: the shape coming out of the fire is what sells it. There is a structural-failure variant for ships that come apart rather than detonate. This is the "Hero" destruction effect. Old school style. I didn't do this for the Battle of Yavin, but I did do it on DS9 and I believe that for the "feel" of this game, we need that cinematic destruction on hero ships.
Being hit. Canopy overlay only, deliberately provisional until there is something to fly and something shooting at it. Anything else is guessing. Being hit will be sold mostly by audio, and the ship's console.
Weapon travel. A bolt needs a bright head and a body, because you have to be able to read it coming straight at you and crossing in front of you, and those are different pictures.
The shield frigate's umbrella effect from a fortnight ago is the first of these recipes.
Saturday — the audit
I stopped and read the entire design set end to end, along with everything from the last two weeks, and wrote down where the project actually is in plain language.
Design is deep. Engineering is zero. Everything is on paper. But we know that.
The risk that matters is one sentence: the entire technical stack — the replication layer, the ability system, the rendering path, the version control, the tooling — exists only as a plan until the first three phases measure it. Nothing about it has been proven on this project by running it. That is not a comfortable thing to write in public, and it is the truest thing in this entry. The reward side survives the same scrutiny, which is why I am still here.
The valuable output of the day was a list of holes — the paper decisions the first week of building would have tripped straight over:
- Network tick rate and update rates, per replication ring.
- A combat geometry sheet, in kilometres: engagement range, the ring radii, sensor range, how far away you can still see a fighter.
- How another ship's shots reach your client at all — replicated projectiles, or fire events your client draws for itself.
- What an enemy fighter actually computes every tick.
- The prediction specification.
- Whether ships are kinematic or physics-driven.
- Which operating system the dedicated server runs on.
Alongside that, two design questions got pulled forward. The enemy manoeuvre playbook — the set of committed moves a fighter picks from, instead of continuous pursuit — moves to a proper session before the scale test, so that when I measure a hundred fighters I am measuring real behaviour and not a placeholder that flies in circles. And I reopened the question of which enemy ships carry the full ability system. I am inclined to put everything on all system-controlled craft and let the measurement decide. If the tests fall over, then we rethink.
There was also a bug hunt, which is the sort of thing that never appears in a trailer and matters enormously. Two defects at the junction between the ability system and the new replication layer, both chased to the public tracker. One is fixed in the version we are on. The other, from May this year, is still open — but with a known safe configuration as a work-around.
Ship work ran alongside all of it. There is one hull being taken end to end — sketch, concept, model, and eventually blowing it up — deliberately as a single complete pass rather than five partial ones. Most of the individual tests could have been done with a bought asset, but a bought asset teaches you nothing about your own pipeline. This one also establishes the third manufacturer dialect: the one that greebles. The design aesthetic is deliberately 1970s kit-bash.
Two research findings from the same day that pull in opposite directions, and are going to matter: the virtualised geometry system wants dense triangles and does not want you to retopologise, or at least doesn't care. The destruction system wants meshes that are watertight, and does not much care how clean the topology is. Neither of those is what twenty years of habit tells you to do. By the nature of the design, the ship will be fairly simple in its base shape, but time will be spent on detailed greebling and hand-cut scribe lines, trenches, and other geometry, rather than relying on simple geo and normal maps.
Sunday — pipeline, and what to call things
The ship asset pipeline got settled, at least in shape: hand-drawn art pass, converted to a rendered concept, converted to a reference mesh, then rebuilt by hand in the modelling package. The rebuild is the point. The middle steps get me a solid, correctly-proportioned thing to build against in a fraction of the time, and the design intent from the initial sketches gets carried all the way through because it started as a drawing I made. One hull is half built and going well.
There will be a proper post about that pipeline, because it deserves one and because a still image cannot show it. That will have to wait until the model is finished (next weekend??)
The other Sunday job was naming things. Ship anatomy: fuselage, thrust frame, engines, bridge. Boring, and it stops three documents from calling the same part three different names in six months.
And a first look at accounts and login — how a player's identity gets from the storefront's account system into ours, and what happens the first time someone logs in. Barely scratched. Plenty more to come.
Lots of good work this week. A tall building needs a strong foundation.
Next: two design sessions to close out the numbers on zones and effects, and the art pipeline post once the ship is far enough along to show.
(Such a tease!)