On the Network
This week the ships moved onto the LAN (local area network), and flew across four machines with nothing out of step. The week's goal was met early, and at the weekend I flew the first race course by hand.
Around that, the server learned to deliver every explosion on time, and to recover cleanly when a player's machine hears of one late. The pilot gained an options window with Quit, and the first key-binding screen. The Gallery gained stations, a new group for zone objects, and new versions of the models for the model viewers that were small enough for mobile devices on the web. Modelling continued on the Light Carrier and the Mosquito. On paper, we researched how wingmen have fought together since the First World War, and the concept art turned to an asteroid mining colony and a torpedo.
A close inspection.
The engine's own physics
The engine's own networked physics is marked as experimental in its source code, so we needed to test it, and we needed something to test it against. We know the engine finds collisions reliably, so we built a hybrid: the engine finds each contact, and our own code works out what happens next. It got ships colliding and tumbling, and it gave us figures we could trust as a benchmark. The main worry was never whether the experimental physics could find the right numbers. It was whether it could hold them consistently, across a network, in a fast-paced game. That is the test. Play testing also showed how much a full contact system has to cover by hand, such as the speed of the touching points on a spinning ship, friction, and several contacts at once.
Before building any more, we set out seven routes, from completing the stable, but manual hybrid method to using the engine's "experimental" physics outright. We researched each one from published sources and from the engine's own source code, to find out what the industry standard was and how the engine could supply that for us. Every route had to pass one test. Whatever handles contacts must work with client prediction, where a pilot's own machine moves their ship at once rather than waiting to hear from the server. A pilot's ship has to respond the instant it touches something, with any server corrections blended in, so the experience is seamless.
On Monday we decided to test the engine's own physics first, set up the way its makers intend. It had to pass the same tests as the hybrid. If it did, there would be no need to finish the hybrid at all. My design for physics is simple. It works, it works reliably, it works believably, and it works over the network from a server that has the final say. It gives players the AAA (big-studio) gameplay they expect.
The first stage put the two side by side on one machine. The engine's physics matched our hand-worked figures for a struck ship's spin, held a resting ship perfectly still on a floor, slid along a wall exactly at the friction limit, and parted a pile-up cleanly. Every flight repeated line for line. On one machine, the "experimental" route did everything the hybrid did, with the engine doing the contact work. The next questions were how it looked on screen, and how it held up over the network.
What the screen showed
When I watched the new course in the editor with two players, it failed by eye. Nothing scales up past a failed test. We needed to settle the physics, and as soon as possible. We put everything on hold, because everything is downstream of our physics testing. We had to find the issue, fix it, and then return to the schedule as soon as possible.
An investigation into the source code found every cause. We had simply implemented it incorrectly. With the correct implementation on the server and every client machine, the system settled into where we hoped it would be, and the corrections for differences between the server and clients fell sharply, and well within tolerance. Scenes were re-staged for a better view of what was happening, and rerun. The results, both visually and in telemetry, were good.
Initially, the collision and contacts were a simple foundation on the way to tuning flight and getting GAS (the Gameplay Ability System, which will run each ship's weapons and abilities) up and running. This set of issues made it clear that we needed to really put physics to bed before moving on. We restructured the next two weeks, so we could just concentrate on physics, which should probably have been the original schedule all along.
Over the network
The network test came next. It added real network delay, and scripted pilots that threw their controls hard over without warning, to see how the network copes when one player does something unpredictable. First, the server and three players ran on one machine, with delay and lost packets added on purpose. Nothing fell out of step between the machines (a desync) in any flight, and the server's results repeated exactly from flight to flight. Then I flew it across our LAN, with the server on its own machine and a player on each of three others. The server's results matched the single-machine test's at full precision, on a different processor. That matters because physics can come out slightly differently on different hardware. The server will one day run on a rented machine, so it has to give the same results wherever it runs.
Explosions were the hardest case. An explosion happens at one moment, and every machine has to apply it at that moment. In the game world, every event happens at its moment, with no delay. Any delay is technical only, kept to the least that keeps the game consistent on every machine, and no one-off event is ever dropped. At the highest delay we tested, that did not yet hold, so it went to the top of the list.
Over the network.
Four machines, three cockpits
The next test put each of the three players in their own ship's cockpit, so the screens could be compared and the cockpit view tested too. Each player can be given any ship for a scene. Sadly, we only have one working cockpit that we are sharing for all the ships right now, so from inside the ship, they all look the same, even though they fly differently.
Of course, there were faults. Players kept sending controls to ships that had been removed. The server wrote every message refusing this control data to its own log window, waiting each time for the line to be drawn. The explosions were late or never showed up. (>_<)! A ship taken from a player is now hidden first, and removed only once that player has their new ship. The server no longer opens that window, so does not need to wait for the redraw. We looked into "booking" events, so explosions are now booked a little ahead, by what each connected player actually needs, so one slow connection never delays everyone. The second four-machine test passed every judged mark: no desyncs, no snaps, every ship at rest on every machine, and the blast at its moment on every machine. The engine's networked physics, the part we were most cautious about, held on four machines.
On screen I saw what still needs work. The measured flights switch v-sync (the screen's frame sync) off on purpose, so the picture tears. Small, distant ships show jagged edges, and the radar scopes smear. The radar is part of the pilot's world inside the ship, attached to the cockpit itself, and the cockpit is steady as a rock, so the scopes should be too; somehow they are being affected by motion blur. These all get listed in the next housekeeping pass.
Three player ships, each on their own machine.
The first race
With the network working, the slalom came next, flown by hand across the network. It is built as a real racing mini-game, but we used it first as a flight test. In the future, this can be used to run individual time trials or a group stampede through the ruins of a wreck.
The course is a series of rings that the pilot flies through in order. Each run starts with the ship at rest inside a start sphere, with the throttle at zero. Flying through the first ring starts the timer, and flying through the last one stops it. The pilot passes a ring by touching the trigger inside it, and the next ring then lights up ahead. In a solo time trial, the pilot's own machine keeps the time, because having the server override your run would be annoying. A group race, however, will run on the server's clock.
The first slalom run.
I flew the course in both the Heavy Fighter and the Kantari Scout, both with raw mass and power values that were guessed rather than planned. I flew both with all three main input profiles: HOTAS (hands on throttle and stick), Controller, and KBM (keyboard and mouse). The entire time, the game was screaming at me to tune the controls and remap the defaults for the devices. The Kantari Scout was easier to control than the Heavy Fighter. The Heavy Fighter didn't feel… heavy. It felt slick, slippery, and then unresponsive, which led to a lot of weaving. We built the base UI to do this as we swapped over from last week to this week, in the middle of Sunday night into Monday morning. The first session this week will be properly implementing them for in-game tuning. Every finished run's clock matched the server's count, with no desync and no snap.
The course is "Gate Agnostic". Even though we currently have rings to fly through, in the future we will be able to use any object we want. All a gate needs is a trigger collider, and preferably something to light up or change, so the pilot knows what's going on. To that end, we have it so the gates show up on the radar when racing, and in colour, so the pilot can see the next gate on the scopes as well as outside the canopy.
Coming to a stop
One thing that I noticed while playtesting was that every time a ship came to rest from a slow turn, or rotation, it popped. The data, and then the engine's source, showed why. The engine's physics puts a body that has been nearly still for a few steps to sleep, and at that moment sets its remaining speed and spin to zero. A ship still turning slowly stopped dead between one step and the next. My guess, before the source was read: if the ship's velocity is zero and it's rotating, it might get slept immediately. The data agreed.
This pop raised a design question.
We already had in the design plans to create a "stationkeeping" action. This would be a "quick stop" using the steering thrusters to bring the ship's motion and rotation to zero; essentially a parking brake. Now, to be clear, this is a separate item from a fitted brake module, which would act like a flywheel or capacitor, absorbing and cancelling forward speed, and perhaps even recovering energy. What this need for a "stationkeeping" action came from is the rather slow process of finally having a drift stop on its own. The flight model begged for a "Stop! Stop now! Throttle's at zero! Stop drifting!" I like it because it's real, and I chose to keep it. Stationkeeping allows the player, diegetically, to come to a full stop, and as the zone could technically be moving (all things are relative, you know) this is "stationkeeping", not a stop.
Our flight model relies on drag to reduce the speed of the ship, but it's tied to the speed: more speed, more drag; less speed, less drag. Our drag is not exactly friction, so on its own drag never quite reaches zero, and neither does velocity, rotational or directional. The ship may appear to drift a little and then stop, but under the hood it's drifting forever, like a badly implemented lerp (linear interpolation). What actually stops the ship right now is the physics sleep threshold, and when that happens, the server and the client don't always agree. When they don't, there is a pop.
The first thing we did was set the sleep threshold lower, so the engine's "sleep now" command starts late and the freeze is below what the eye can perceive. Annoyingly, we are still seeing a pop every now and then. This pop is a correction that comes from the server, showing how far the pilot's copy of the ship had drifted from the server's. More annoying is that as we set sleep very low, and keep the drift threshold fairly high to prevent pointless small corrections, when the sleep does kick in, it seems that the server double checks everything. If the server doesn't like what it sees, it wakes the client's ship, moves it, and puts it back to sleep, with a very obvious pop. Fixing this is now its own piece of work, pushed off into its own investigation cycle, to be fixed later.
Built for the final game
Everything we build, we build in some form of the final game. We won't build things backwards, and we won't waste any time on making temporary code or systems that simply get thrown out or, worse, get stuck in the system and get expanded into something real, but badly implemented on a shaky foundation. The slalom course fits this rule perfectly. We will be using timed trials in the game. We need to run flight tests. The same system works with both.
The same rule shaped the rest of the week. The controls a pilot touches were built as game features, not test switches. Esc opens an options window, for now holding Quit and Resume. Open windows sit in focus order, Esc closes the top one, and Esc with nothing open opens the options. Quit ends everything a session made, in order, whether the pilot quits, closes the window, or leaves the server. The first key-binding screen gives each flight action one row, with an axis column that drives both directions and a buttons column with one entry per direction. It also carries dead zone, sensitivity, a stick response curve, and invert, saved for each control profile. A changed tuning number now reaches every machine at the same step, so tuning never needs a restart. All of it is tested and packaged.
The rule also applies to the scripted pilot that flies our test ships. Before it could become the start of the ships that players do not fly, it was reviewed. What I want is good code for moving non-player ships. The review proposes keeping its steering at the core and replacing the rest. That is on hold for a proper discussion.
The Gallery
We have added more models to the Gallery. We now have stations, under their own heading below the ships. We also added a new group, Zone Objects: things that we find in a zone that are not ships or stations. So far this contains the navigation beacons and the race rings. The navigation beacons and race rings have one entry each, but within that there are many slight variations. The beacons are from the first zone, which is less technically advanced than the Principality "next door". The Principality is where the stations are from. Bigger, sleeker, higher tech. To compare the two, the Heavy Fighter is from Zone 1 (name to be decided) and the Heavy Racer is the Principality's build of the same ship, made as a runabout and racer, not a warship.
Principality Outpost Station
Every 3D model in the Gallery is a massing model: a stand-in, the shape and base for the real model to be rebuilt with, and not final in any way. Even so, they were far too big for the web, especially for mobile devices. Some of them were hundreds of megabytes. Cutting their detail the quick way made flat panels look swollen. Each model was rebuilt with fresh textures baked from the full model onto the simpler one. Panel lines and shading survived, and each model now comes in at a few megabytes. Not only good enough for the web, but good enough for mobile.
The Gallery now runs group by group, ships, then stations, then zone objects, and A to Z within each group. The DevLog's pages were updated at the same time, so they could show the same turning models as the Gallery.
On paper
We researched how wingmen fly together and fight together. Most weight went on the Second World War, but every era of flight was covered, from Boelcke's rules in the First World War to the Thach Weave, Vietnam, and today's two-ship doctrine. The goal is inspiration and historical accuracy in designing a playbook for a companion in the game, or for two opponents trained in this style. The sources repeat the same lessons in every era. The wingman stays with the leader and watches behind. Spacing makes the pair work. Losing the wingman is the worst failure. Roles follow the situation, not rank. Some of it does not carry into space: there is no diving from height for speed in a vacuum. Attacking out of the sun does carry over, since our zones have one, but this is primarily for visual interest, as the radar and HUD (head-up display) will pick up the enemy even with the sun behind them. With that in mind, ECM (electronic countermeasures) and ECCM (electronic counter-countermeasures) will come into play. Perhaps the support ships can create a blinding electronic sun… we'll see. None of this is design yet. It is research, and the plan built on it is a proposal.
Three ideas joined the design notes. One is a station in a hollowed-out asteroid, reached by shipping lanes through a field too dense to fly fast in. Another is an ice field of huge blocks with scattered minor fields. The third is a jink or dodge button, a preprogrammed motion that works in conjunction with chaff or other distractors to throw off an attack. Tap it and the ship rolls to the left or right, and if timed correctly, it can avoid fire and missiles. It consumes energy, and may need a cooldown to prevent "bunny hopping" in space. We are also considering how this could affect radar and other measures in combat; an ECM or EMP (electromagnetic pulse) burst that blinds radar and breaks target locking… All of these notes are in development. If they get settled and agreed, they will become part of the design document. We do want to keep the game focused on dogfighting, but at the same time we want to have a balance of power and agency and want to bring space dogfighting into a real world space of its own.
Based on original concept drawings, but in the end, very prompt driven, unfortunately. I'll fix this by hand when making the model.
The concept art turned to look at asteroid mining colonies, as the first zone will be lower tech and working class. Unlike the ships I've sketched, it was very difficult to get a clean image of what I wanted. The colony, based on a large body of rock, needed to be a mix of homes, workplaces, and industry, built to fit its workforce but built organically as the needs of the colony grew. I wanted "organic" but the structures had to feel like they are made by humans. My imagination was a colony that was like looking at a massive coral reef. The model just couldn't understand what I had drawn as it was too far out of its training zone. I had to move much more heavily into prompting, which really makes me uncomfortable. Early images did grow the buildings over the large asteroids like coral grows on a reef, but they were too organic; not built; too much variation in size, and style, and shape. Once the overall design felt correct-ish (see images above), we moved on to designing the individual buildings so we could hand place them on the base asteroids in a believable manner.
Kit parts to the colonies.
We had designed a "torpedo sled" for one of the planned instanced missions, so to accompany it, we needed torpedoes. Two general types were considered, one more of a torpedo, and the other more of a dive bomb.
A paint-bashed concept for the Torpedo Sled.
Torpedo (Left) and Bomb (Right), both for the sled.
The last bit of research for the week was how to reach out to people for feedback and playtesting. We are aware that right now we are shouting into the void and only a few people, mostly friends and family, are listening right now, but we want to change that. It begins with looking at the website and Discord as a newcomer would and making sure it's ready for attention.
Week four of fifteen weeks (about 100 days). The ships fly the engine's own physics across four machines, with every event and explosion landing as expected and nothing out of step. The first race has been flown by hand with two different chassis and three different controllers, and the game is gaining the parts a pilot touches.
Next: measuring the drift between the pilot's copy of a ship and the server's, the radar scopes fixed to the cockpit, Turbo Boost, Stationkeeping, and Reverse Gear, then the first test with hundreds of ships on one server.