The Ship Flies
The ship flies… on a server, with two clients. Both of those are milestones this log has pointed at since the first entry, and they landed in the same week. Our target goal is a playable, fundable build, in one hundred days counting from the first of October. This is what the first week of that looks like.
The server came up on Wednesday. By Thursday it was running on one machine with clients on two others. By Friday there was a ship on it, flown from a stick, from inside the player's cockpit. By Sunday the flight model had been thrown out and rebuilt twice, and tuned until it felt right. Around that, the week also lit its first zone, built motion dust, settled what a bomber carries, pushed the ships forward in Blender, rebuilt the long-term schedule, and started measuring where the hours go.
This entry is also the first in a new shape. The weekly log used to run day by day. My days are too tangled for that now, so from here the logs are written by what got done, not when it got done.
The ship flies
A dedicated server is the headless build that runs a zone on a remote computer with no screen and no player attached. On Wednesday ours booted as a packaged build with two packaged clients joined, all on the same machine. This was just an empty test level with the engine's new replication system keeping both clients' copies of the game in step. The done-condition was two lines in the server log saying a client had joined. We got those two lines… and we could get the players in both clients moving and interacting with each other… proof in both log and live.
On Thursday that moved off one machine and on to our dedicated server test machine. The server ran on one box and the clients on two others across the local network. Same result. Along the way, a packaging trap was found and logged: the editor's default setting in the project silently builds the wrong target. Oops. Each time we build, we have to choose the target by name instead of relying on saving them in settings.
Then the real project was created. This is the project that will take the game to completion. Unlike "ARK: Survival Evolved", which got stuck with "First Person Shooter Template" for years, we have actually used a completely blank template and we have used our name: CygnusRift; and with that, the "server probe" project was retired.
The first slice of the actual game is just one ship class that every later ship will extend. The established game mode hands each joining player a ship. In our first slice, the controller sends only four things to the server: pitch, yaw, roll, and throttle. Everything about how the ship moves is decided on the server, and the outcome is sent back to the client as "game play". Our flight model has always been planned to be as simple as possible, driven by forces and physics, but tuned to feel like "planes in space". Acceleration is power over mass. With that, drag sets the top speed. Every number lives in a data file, never in code. The first ship had a top speed of 175 metres a second and turned at 85 degrees a second at cruising speed. How it turns changed twice before the week was out. That story is below.
The actual, real project is now under version control. It feels so official! (Version control is where we can save our work incrementally, with one commit per piece of work, so each and any piece can be rolled back on its own. But we won't need to do that, right? We never make mistakes, right? Fingers crossed…)
The stick
The reference stick for this game is a Thrustmaster T.Flight HOTAS X. (HOTAS means hands on throttle and stick.) It is a solid entry-level HOTAS, the kind that turns up in a sale for less than a night out, and it is the one the flying gets tuned on. I got mine on sale just this week! If the game feels right on this stick, it should feel right on anything equal or more expensive.
We plugged the stick in and read every axis and button from inside the engine. That took a raw-data debug view to confirm because a stick sends its input data as numbered axes and buttons, not as pitch and throttle, and each manufacturer can have a different scheme. In the finished game that job will belong to a controls screen. You will be able to assign any axis or button to any control and name it in your own words. We would like to have a simple tool box that can help with that, something I've always wanted in a game, where there is an "axis identifier" page in the settings and you can click any button or use any axis and then name it so when later you set up your controls, you know what this is, not just Axis 7. We will also handle "buttons" such as the "Hat Switch" on the stick which is not a button, but an axis with set values. Within the settings we will enable switches that allow you to flip any axis so that it works the way you want it to. Roll and Yaw are the main candidates as some players prefer to put Roll on the stick's L/R axis and others prefer Yaw. No debates. Everyone can fly the way they prefer.
The first slice of the control profile library was built the same day. Four profiles ship with the game: keyboard and mouse, joystick and keyboard, game controller, and full stick and throttle. Keyboard and mouse is the one (almost?) everyone already owns, and it is going to get as much effort as any stick. Nobody should have to buy hardware to play this game. We also have plans to ship support for additional devices, such as a USB numpad to supplement input and reduce the need for a bulky keyboard close at hand. We also have plans to support extra screens, and not just "I want three screens for width, please!" but we would really like to support USB displays or tablets connected to the computer that can carry cockpit instruments and other interface panels on their own, with touch or mouse input taken straight from it. Anything to prevent swapping to the keyboard and mouse to activate more complicated actions.
The cockpit
The main view is first person, from inside the ship. We also have a third person chase view as a toggle.
Every ship now has two models. The exterior is the hull everyone else sees. The cockpit is a separate model only its own pilot sees, carrying the camera position. Other players see your hull. You see your cockpit and only what parts of your hull that you'd see out the cockpit window. Currently this is just the main model, but I suspect we will make the cockpit and exterior content a custom model for the pilot so it feels right.
A placeholder cockpit from a marketplace pack went in so the view could be judged. The field of view starts at 90 degrees across the screen, as a player setting. That's fairly standard. It may get tuned later on. Mouse-look went in as well: hold a key, the mouse turns your head within limits, release it and the view eases back to centre. It only moves the view. It never touches aim or flight. Binding the hot-key to the spare button on my mouse allowed me to reach out, look around, and get back to flying without a hitch.
Two things did not survive first contact. The cockpit's bright edges trailed into the background on every turn. That was traced to the engine's newer anti-aliasing method, and switching to the older one removed it. A rendering trick meant for first-person games that was drawing the cockpit at its own scale and field of view was researched, found wanting, and removed, so the cockpit now draws at true size and is just content in the real world. If this needs to change, we may revisit it.
A plain on-screen readout went in as well: speed, throttle, turn rates, mass, and power, on a key. Numbers can be compared run against run so they are a must. These will translate into UI controls eventually. Even though we used a number of sphere objects for direction and scale, their identical shapes in an empty level didn't give enough information about flight feel, so the hard numbers were good. As we continue to develop the zone's topography, or fly with multiple players, this will become easier to judge by the seat of the pants.
The flight model, three times
The first version flew on Friday. My original plan was to base the model on the mass of the ship and use the thrust as the main factor driving flight in all aspects. It flew, but it did not feel right, and tuning could not get it to where I wanted it to be. It went. (It rolled over and sank into the swamp…)
The second version tried a different approach, also built from the ship's own mass and thrust but with more control factors, and it was worse. It went too. (It burned down, rolled over, and sank into the swamp…)
The third version stayed. This model still used mass and thrust, but it's based on the engines for forward thrust only. Then we have literal "thrusters" adjusting the attitude along all three axes. This turns the nose of the ship, pointing it in a new direction. Then, like an aeroplane, the medium adds force to the ship and pulls it round behind the nose. The ship slips a little in a hard turn and pays for it in speed. It is not six degrees of freedom and it is not strafing. It is a plane in space that can get a little sideways when you throw it round a corner; think of a jet banking hard and at the top of the turn there is some movement along the vector of the belly until the wings and thrust equalise this along a new vector. The maths is also much simpler. This means replication and prediction are less of a problem. Essentially, what I've added, rather than trying to control the flight with guardrails and caps, is "air" and therefore air resistance and that gives a "keel" effect in the flight model. Diegetically we can pretend that this is the density of the dust and gas in the zone. In reality, the Cygnus Rift is as much a vacuum as the empty space in our star system… but hey. Our laser bolts will make sound in space…
Flown on Sunday night, it feels right. Whether the turning circle is right cannot be judged in a mostly empty level. That waits for content. In our data driven model, tho', this is just value tweaks in settings files, not revisiting any code.
Three flight models in four days, each one flown before it was judged. That is the pace, and it is the method.
Lighting a zone
The test level was black on one side and blown out on the other, so lighting got its first real pass.
The exposure is locked. There is no automatic adjustment as you look from light to dark. The camera is set to real-world values for sunlight above an atmosphere, and everything is lit to match that. The sun is a directional light at its real brightness. The real figure may not even hold in space, and as I put it in the session, we are not in space, we are in a space game. Real-world units are a reference scale, not a fact to honour. Each zone's star is a dial, set by its distance, and it lives on the zone's data.
The sky and all its glorious nebulae lights the scene. The recorded position had been that the starfield was a backdrop and nothing more. Why not have it light the scene? One image does both jobs: a sphere round the level shows it, and a sky light reads it, with the same brightness on both so the light the sky gives equals the sky you see. This doesn't take into consideration the soft light from a planet, but we'll deal with that when we get the chance.
One more piece landed on paper. Orbital night. Where the planet's shadow sweeps across the zone, the lighting cannot be done with ordinary shadows at planetary scale. The method, borrowed from solar-system renderers I researched, is to treat the planet as a mathematical sphere and test each pixel against it directly. The sun moves, so its shadows run uncached, which the engine supports. The whole lighting setup is written up as a guide so the next zone starts from it.
Dust
Motion dust is the drift of specks past the cockpit that tells you the ship is moving. It belongs to the zone, it is the same for everyone in the zone, and it is drawn on each pilot's own machine and only around their own camera. The server never sees it.
It fought back. The design's first recipe used a lightweight particle type that, in this engine version, is forced to travel with the camera, which is the one thing world dust must not do. A standard emitter fixed that. Then the field thinned out ahead of the ship at speed, about thirty-five times thinner at cruising speed, so the specks had to wrap around the ship instead of spawning in a box. Two different ways of wrapping were built and compared. One was custom built using a custom material and custom code in the emitter… and then due to a typo we saw a completely undocumented module in Niagara… which essentially does exactly what we built, just supplied by the engine. Both modules are in the emitter and we are testing them side by side for efficiency and look. The system was parked on Saturday at the stage of "works, not pretty". Fading it out below walking pace is queued for a future tuning session.
What a bomber carries
The weapons discussion picked up where it left off. The open question was what the Bomber's big bay holds. The proposal on the table is that it holds a torpedo launcher or a bomb launcher, one at a time, chosen at dock. That makes the torpedo bomber and the dive bomber two builds of one chassis rather than two ships. Essentially, this will be the custom bay for a bomber, the "siege bay", and only bombers can carry it.
The same bay could take a belly-mounted energy weapon fired on a strafing pass. The kinetic bomber would then answer armour and the energy bomber shields. That fits the design's rule that a weapon family is a build outcome, never a class. This is very much a work in progress.
Ships
Blender ran underneath the week as it always does. The light carrier was the ship in the dry dock. All of the main surfaces are done, the engines designed and built, and the landing bays are in place. The main details still owing are joining the docking bays to the hull and sealing their seams. After that, it's greeble details.
The styrene question got its answer. At least in theory… practice is this next week ahead. The 1970s studio-model look is not separate parts glued on with booleans and welded with a bevel at each seam. It is one continuous softened surface. The route I want to try is to build the greebles, simply drop them by eye, don't join them in any way, and then fuse them into a single solid using a voxel remesh pass. This remesh pass should make every seam a soft bevelled fillet, as if glued and painted. It will lose some detail, but that's not inappropriate. The engine confirms the approach: its geometry system wants dense real detail, not baked fakes with normal maps, so the remeshed ship is the deliverable and there is no bake step into normal maps. To keep the clean parts of the ship, the trenches will be removed, greebled, and then remeshed as separate units only to be returned and fused into the hull.
Light Carrier in progress.
Light Carrier testing scale.
The plan, and the clock
The long-term schedule is being rebuilt from the ground up on the basis we actually work to. Real calendar days, seven a week as worked, with the holidays marked. No padding and no overrun factor. Estimates stand as written until measured pace replaces them. It carries the plan past the first build to a release and past that again. The figures stay in the plan, not here.
To that end, two tooling changes support this. Automated time tracking now records which window has the focus and for how long, so the pace claimed in this entry is measured rather than felt. This way we can say where the hours went instead of guessing. Frankly, my dear, I don't give a damn about where my time went, but I do care how much time I need for the future. By tracking where my time actually was spent, I can use that to more accurately schedule the future and clearly identify problem areas to address. The other change is that the document work is moving to a tool that reads and writes our files directly instead of me having to pass them back and forth, which removes a step from every delivery I do. All of this is just tool streamlining, even if it means (annoyingly) paying for tools to help.
Two more things started and did not finish. A version of the design document for someone outside the project is under way, rewritten rather than redacted, one section at a time. This will be the basis of an updated internal GDD as well, as the current one is rickety and stale. The next piece of the ship's data, the calculation that turns everything fitted to a ship into what the ship actually does, was planned and its first tests drawn up. Neither needed to finish this week. Next week here we come!
Seven days. The server runs. The ship flies. The flight model is the third one and it is the one we keep. Ninety-odd days to go.
Next: the build gets packaged and flown on three machines again. Then the second slice of the game!