Day and Night
Space, in its usual form, is nothing. That is the problem we spent most of this week on: how do you make a volume of empty sky feel like somewhere you have been, somewhere worth going back to?
Alongside that, two other threads ran their course. We worked out what a bomb means when there is no such thing as down, and settled the names for every major weapon we intend to build. We also settled how you will fly your ships — which turned into a week's worth of hardware research and a firm position: we build against the cheap gear, so that everyone can play, and we will make keyboard and mouse as playable as possible.
Monday — the log learns to move
The site itself got a small upgrade: entries can now carry video, which is what made the next day's post possible.
The rest of the day closed out the first engineering phase. The build ladder — the ordered list of what gets built and in what order — was audited end to end for missing steps, steps in the wrong order, and lines that had gone stale. A load of tiny, niggling, but critical issues came out of that, all fixed.
It was clear that one of the items we need to test is not only hitting something, but being HIT by something, so we've armed the target drones. We will now have something that shoots back, built from the same fighters the phase already produces, so that the first combat test is a real one.
Tuesday — the sky that moves
Here is the thing we keep circling. On land, you can change the colour of the leaves, or the grass, or the weather, and a place you have walked through a hundred times is new and possibly beautiful. The reference case I keep coming back to is a waterfall you find on a walk — admired first, and only later do you find the passage hidden behind it. Space does not hand you that for free.
So we went looking for the parts of real orbit mechanics and celestial events that could do the same job.
The sky can move. A zone sits at a real celestial body, on a real orbit, so the stars wheel round once per orbit and the sun goes with them. The anchor planet stays put. Most of that is far too subtle to notice — but light is not. A moving sun, and the planet's shadow sweeping across the zone, give you an orbital day and night. That is a time of day, in space, and it costs us almost nothing: a few sums from the clock everyone already shares. Under our lighting, a place at dawn and the same place at midnight are two different places.
Things can be hidden in the light. Which leads straight to the next idea: finds that only show at one angle of the sun, or glow only in orbital night. Nothing spawns, nothing unlocks. It was always there, and you came back at the right hour.
Rings shear. A ring is not a solid disc; every particle is on its own orbit, and the inner material laps the outer, so a ring is permanently sliding past itself. We looked hard at simulating the shear and set it aside. At true rates, material a hundred metres from a parked ship moves at about two centimetres a second, so nobody would ever see it. The joke that didn't survive the discussion is the chance for you to find out you can't park in the ring and go and make tea, and expect to come back and find your ship… at least in one piece.
One thing does move, though. Give a moonlet the same orbital period as everything around it, but a slightly oval orbit, and it traces a slow closed loop through the neighbourhood once per orbit, at walking pace; or if it's varying by tilt, it will appear to bob up and down. That is not a special effect; it is what the standard equations give you for a nearby orbit, and it might be genuinely fun. Better still, its position is exact from the shared clock, so every player will have the exact same content. One other option, for more eccentric but similar orbits, is the moon or orbiting asteroid that comes smashing through the zone at real speed that would be regular and periodic. That path would be marked on your map and the ship's navigation computer can warn you about it like a train coming down a track. Danger zone: orbit conflict HIGH.
Weather. Moving matter gives us a reason for "weather" that actually belongs in the game and is plausibly correct. The gentle version is a sheet of sparkling dust drifting through a volume for a while. The sharp version is micro-meteors that make trouble wherever they arrive. The nice trick in the gentle version is that a passing glitter sheet reveals shapes you could not otherwise see, the way fog shows you where the light is. All of it needs a cause — a moon pulling a streamer out of a ring, a venting moon throwing out ice, or lanes of debris, where wreckage keeps the speed from when it died, travelling until it settles, years later.
And a proposal for solo pilots. We want to give players a reason to stay because they want to, and for solo players, it's a chance to explore and fly, not because a timer told them it was time for an event and to go fight. Some pilots want to be in the world without being one of a hundred in a fleet battle. For anyone who wants to cruise and explore, solo, or with mates, there will be things to find and experience. One idea, a tiny bit like homestead instances, would be an area of dust thick enough to be a nuisance and opaque enough to reduce visibility, but where what you find inside is yours. Only you and your navigation computer hold the record for it. For anyone else who wants to see it, they will have to fly in your wing, with you leading. We already materialise resources per pilot, so this follows a pattern the design already has.
The honest state of all this: the engine, the grammar of a reveal, and the rules are designed. The content that fills them is still growing, and that gap is the open question, but one that is fun to solve.
Wednesday — drudgery and then fun
The day went to document upkeep, which is dull but necessary and does not deserve a paragraph.
Underneath all of this, the ship work carried on. Monday through Wednesday went to the heavy fighter. The foundation assets get built as they are needed, and that is the one that is needed first. I am getting faster. The modelling rust is slowly flaking off and the joints are loosening up.
Thursday — there is no down
A long session on bombs, and it starts with a problem. You cannot drop a bomb in space. Nothing falls. There is no down. A bomb you release keeps your ship's velocity and carries on exactly as it was going, which means bombing is something you do along your own flight path, up close.
So the player has essentially two choices: become a dive bomber, or give the bombs a small push when you launch them, and strafe a bit. As a dive bomber, you line up, you release, and you pull away. Your own speed becomes part of the maths — speed against launch force gives the impact point, and the display works it out and shows you. This will make sense when you switch on your targeting computer… and don't expect your bombs to make a right angle turn at the last moment. The flight behaviour was more dumb than I had been imagining, and better for it.
What a bomb buys you is everything a guided weapon gives away. There is no seeker, so countermeasures have nothing to confuse. There is no lock, so the target gets no warning. Most of its mass is warhead and it has no engines, so it emits almost nothing on the way in. What it costs you is the run itself: close, committed, and only worth it against something big or slow.
That sits inside a bigger picture we settled the same day. When a capital ship encounter happens, there will be jobs to go round: suppress the fighter screen, protect your bombers, jam the enemy's tracking, take out, suppress, or confuse the capital ship's defences, and then hammer it hard to repel, disable, or destroy it.
The rest of the day went to long-term planning — the shape of the road to a playable release, and the funding work that goes with it. We also changed how we schedule: out go abstract units of effort, in come real calendar days, with two days a week held back for overrun and for the subjects that turn out to need a proper look. This week's weapons discussion is exactly that kind of subject.
Friday — naming the arsenal
Our weapon vocabulary had grown up piecemeal, with "hard" and "energy" bays and names that leaned on every space game you have ever played, or the movies they were copying.
We fixed this from first principles.
Real-world ordnance is named by how it moves and whether it steers, not by what it is made of. There is no real term for a guided energy weapon, and science fiction pretty much just reuses "torpedo" for everything.
We are not doing that.
The definitions now are:
- Missiles are guided, seeking weapons.
- Torpedoes are mostly unguided, potentially powered weapons; correcting more than guided or seeking.
- Bombs are, by definition, unpowered and dumb.
Those cut across both kinds of damage, so missiles are missiles because they seek their target and need a target lock to be effective. The big physical ship-killer keeps the name torpedo, and these have rudimentary correcting engines but are not agile.
Underneath that sit the two damage families — kinetic and energy — with kinetic doing more damage to armour and energy more damage to shields, and within energy, ion to disable and proton to hurt. It is not really a triangle yet; it is more of a bi-angle. There is more to come.
Narratively, I'm breaking things into days, but in reality, a lot of the jobs are mixed across several days like building in Blender. Blender is a great thing to do when I'm waiting for something to finish, or when I just need a break from thinking.
One other job that was spread across a few days this week was the first real piece of the ship's data, and it was a slog. The session started late on Thursday and ran on into Friday. The job sounds trivial: define what a chassis, a skin, an item, and a ship actually are, both the content and the shape of the data, before anything uses it.
In the end we settled that an item that holds things is just an item with a potential capacity. A hardpoint on a hull is just an item marked as fixed. What can go where is decided by tags, and nothing else. One ship class, one spawn path, and a player ship and an enemy ship differ only by who is steering.
It is written, it compiles clean. A test walks nine cases through the placement rules. Any gaps that turned up were fixed on the spot. This needed to get done as everything you ever fit to your ship sits on top of it — and because it is the real thing, not a stand-in for testing.
Friday also took a turn on the art side. I paused the heavy fighter and went back to the light carrier to sort out a few things about it that had been nagging at me.
Cutting the Meshy model.
Rearranging the pieces to match the design.
Adjustments in perspective.
Saturday — every stick we could find
Half of Saturday went to family.
The first half went to a question that had been sitting unanswered: what are people actually flying with?
The goal is making sure the game accepts the majority of the most common devices used in this genre. With that in mind, we went looking properly, and the first finding is that nobody knows. There is no public figure for how many people own a flight stick the way we can track GPUs (graphics cards) and other pieces of hardware. What exists is reviewers' picks, the tested-device list a big space combat title published six years ago, retail search data, and the platform's own controller figures — which tell us plenty about game pads and nothing about sticks. After launch we will be able to see what our own players plug in. Until then it is triangulation.
What came out of it is three tiers, in my own words: beginner, new user, interested party; strong gamers with a solid stick-and-throttle set; and the hardcore, running four monitors, a chair with the throttle built into it, pedals, two processors, and a top-end graphics card. Between those tiers the kit changes shape entirely — at the top end the stick, the throttle, the pedals, and the panels are often four separate products from four different makers.
That last part is not trivia, it is an engineering requirement. At the middle and top tiers the stick and the throttle are two separate devices as far as the computer is concerned, and the game has to understand that they belong to one pilot. One of the key issues we want to avoid is over-engineering. I have an expensive HOTAS (hands on throttle and stick) and pedals, but if our game can't fly on an entry-level stick and keyboard, or HOTAS with fewer buttons, we've locked our game behind expensive third-party hardware.
Sunday — so that everyone can play
Family time all day, so this was a late one.
Here is the position, and I want to be plain about it. The reference device for this game is the entry-level one. We deliberately bought an entry-level stick-and-throttle — the kind that turns up in a sale for less than a night out — and that is the machine the flying gets tuned against. Not the four-figure rig. If the game feels right on the entry-level stick, it will feel right on everything above it. Building it the other way round produces a game that is only good if you have already spent a fortune, and that is not the game we are making.
The same applies, with more force, to keyboard and mouse. It is the setup everyone already owns. Developing to this target is going to get as much of our effort as any stick does. I want it to be a first-class way to fly rather than a fallback. If it can't be, it needs to be solid when it comes to gameplay. Nobody should have to buy hardware to play this game.
With that settled, the architecture. Four layers, each knowing only the one beneath it: the device turns into keys, keys into actions, actions into requests to the server, and requests into what the ship does. Your device never touches the ship's abilities, and the server never knows what you are flying with. It means adding support for a new kind of controller never reaches down into the game itself.
To read the sticks, we use support that comes with the engine and was made for flight gear. Plug in a stick and the game sees the hardware buttons and axes; you then assign them to whatever you like in the game's own controls screen.
Three details from that day that will matter more than they sound.
Profiles are yours and they travel. At least four bindings will ship with the game — keyboard and mouse, joystick and keyboard, controller, and full stick-and-throttle. You can clone them, reorder them, favourite them, reset them to as-shipped, and export one to a file to send to a friend. They save to your account rather than to one machine, with a local copy so your controls are there the moment the game launches.
You name your own buttons. On some sticks the buttons are numbered or lettered on the hardware, and then numbered by the engine in a completely different order, which means flying with a cheat sheet on the desk. So the engine's name for a control is only ever an anchor underneath. What you read in-game is a label stored in your profile that you can edit. You tell the game what your stick calls that button, and every screen uses your choice.
Button combinations, done honestly. Holding one button to change what another does is standard, and it has a nasty edge: if a button is both an action on its own and part of a combination, the game has to decide whether to act the moment you press it or wait to see if you press the other one. Acting instantly can fire the wrong thing; waiting costs you the travel time of the button. Both behaviours are built, switchable per binding, and it is flagged as something to settle with real pilots rather than by argument. It may be dangerous either way.
The bindings that ship as defaults are deliberately not designed yet. Designing a control layout for abilities we have not finished designing is backwards, so those stay as placeholders until the actions exist.
This week produced a set of decisions that will not have to be taken again, and a first piece of real code with tests around it rather than a demo that would have to be thrown away.
Next: we continue to climb the ladder of tasks that make up the second engineering phase, including the ship's stat calculation — the machinery that turns everything fitted to a ship into what that ship actually does. This is also the basis for the offline "Bench" ship calculator that I want to have available on our offline devices, so pilots can experiment with their ships when away from the computer.