When Ships Collide
When Ships Collide!
This week the game learned what happens when two ships meet, and the week's goal passed across three machines, and passed early.
It wasn't just flight testing and collisions; we did a huge amount of work this week. We worked the flight model hard and used all of the hardware sets: HOTAS (hands on throttle and stick), Controller, KBM (keyboard and mouse), and JKB (joystick and keyboard). We're still fine tuning the flight model and the collision system for maximum simplicity and maximum efficiency. We've worked through our spawning code, and every arrival in a new zone is now guaranteed to find clear space. We have also built the rollover code for Navigation Beacons that are closed, contested, or horribly congested.
We built the first slice of the asteroid field "density" tool and the cockpit radar (so you can see where they are around you). We put the lighting through its paces as well, balancing the look of the level between the local sun's light and the ambient fill from the surrounding rift, using the usual four reference balls (black, grey, white, chrome) as a lighting gauge.
New concept art arrived for beacons, race gates, a target drone, fighters, and a freighter. From concept art like this come massing models: as rough stand-ins and rebuild guides. Twenty-five designs, and sixty-six new models if we include the variants. The website gained a Gallery. We also had a long session that explored how computer-controlled pilots should fly. Lastly, we compiled a reference list of real and fictional aircraft and ship classes, for both inspiration and (attempted) accuracy.
Massing models of our ships and stations, side by side in the engine for scale. They are stand-ins, not the final ships.
Ships collide
Until this week, a ship flew straight through anything in its way. Now, picking a collision system seems fairly obvious, as Epic has built one into the engine, but we have to look at how this replicates over the network and find the best and most efficient solution. From one point of view, this may be over optimising, but we are testing a number of solutions, including hybrids of using Epic's physics for detection and calculating our own result.
Part of this worry comes from simply wanting to make sure that the experience is as best as possible, but also worry comes from reading Epic's source code, which lists a lot of the current physics over a network connection as "Experimental", with developer's notes alongside the code mentioning things like "USE WITH CAUTION! MAY NOT WORK AS EXPECTED!" Oh dear. Now — we trust Epic for a lot of things, but as collision and physics is such a core feature to this game, we are testing this to an extent we've tested nothing else before.
One key worry is that when the local client and the server diverge beyond a trigger point, the player's client might be forced to recalculate all the physics objects on the level. There are limiters (a "bubble" recalculate) that can avoid this, but it adds another layer of uncertainty due to this limiter being "Experimental", with additional developer's warnings on top of the base system itself. (>_<)!
This is not all wasted work, however. To test the physics we will need to do tests that we have on the plan already. They will just have to be in a different order with a different emphasis at first. This includes the 300 simulated fighter test and more. We feel we need to do this even if it threatens to push any deliveries or make our lives that much harder, because we do not want to build anything on a shaky or unknown foundation.
Then came the tests. I wanted scripted ships flying at each other like crash-test dummies, so we built a crash-test course. Scripted pilots, using only the controls a player has, fly set courses into each other. A witness camera watches from outside, and every contact goes into a log. Six runs cover the cases, from two fighters head-on to a blast detonated between two ships.
The crash-test course: scripted pilots fly set courses into each other.
I watched the course and flew the test myself. Every run did what the design says, and my readings matched the logs to the decimal. It was a bit boring, but nothing was wrong.
On Friday, the LAN (local area network) test passed on the packaged game: the server on its own machine, and a player on each of two others. That met the week's goal, collision and the LAN test.
So far so good with the basic, local physics set-up, but now we need to test this on a much larger scale, and adding physics materials, friction, low speed contact, and more.
Into a spin, and out again
On Sunday I tried to spin a stationary fighter by crashing into it. I struck it deliberately at the very tip of its nose, and then on its engines. There was no visible rotation.
We measured before fixing anything. The measurement found two things. Our test fighter's collision didn't reach its nose. The course's scripted pilots also steer against any spin, so no struck ship was ever free to tumble.
The deeper cause was in the code that turns the ship. A ship resists being spun, and that resistance grew without limit as the spin grew. This came from code designed to help settle the ship on "an even keel" when the pilot let go of the stick, but it didn't take into consideration any possible outside forces against the ship.
The fix caps that resistance at the most the stick itself can deliver, a figure the flight model already works out from the ship's power. Below the top turn rate, nothing changes. Above it, a hit's spin settles over time, and settles faster if the pilot fights it. The pilot's hand matters in a tumble. A ship with no power has nothing to resist with, so a dead ship keeps its spin and can tumble off into the deep black. This is the equivalent of being "downed", and the pilot can try to recover, or a wingmate could come to their aid.
How hard a ship is to spin is one number on its chassis, the frame beneath its look, so every skin on the same chassis tumbles the same way. This follows our design that chassis are roles, and that models and skins are just looks.
The strike test also caught a bug in our import script. We then investigated and tested every possible way we could add colliders to content in the game: static meshes such as asteroids and mobile meshes such as ships, and completely updated the import script for the best coverage and most efficiency.
We built all of it on Sunday night, and two strike runs were added to the crash-test course: a stationary fighter, free to tumble, struck on the nose and on the engines. Each run was flown three times before the change and three times after, and every repeat matched to the last digit. Before, a strike on the nose barely turned the fighter. After, the same strike sends it tumbling several times over before it settles. A fighter flown into a rock now spins off it, instead of scraping along it. The numbers worked out by hand from the physics match the logs closely.
There was one surprise. Two fighters meeting head-on now spin as they part, because their noses meet at a very slight slant, as the collider now matches the hull better. This is both a good thing, and something we need to watch and make sure is balanced, so no skin out-performs any other. Differences like this are fine, but they cannot impact the gameplay.
Flying it
The mouse is now a virtual stick, with the mouse wheel as the throttle. The mouse's distance from the centre of the screen is the stick's deflection, the same at any frame rate. Auto Centre, on the middle mouse button by default, snaps the stick back to the middle.
Flying that way showed that rolling or yawing on the mouse, but not both together, is hard work. A mix of yaw and roll on the mouse, in the classic style, may be needed. A keyboard-and-mouse tuning session will decide.
Every control number is the player's own. The stick's sensitivity and dead zone (the small movement around the centre that the game ignores) are set and saved per control profile, as the mouse's values already were. Every player can tune them to their own hardware.
We added two small movement changes to the plans: Stationkeeping and Reverse. Physically, when the power is off, drag takes a while to completely stop the ship. That last little bit of drift can be annoying to wait out, so we added "stationkeeping", which pretty much is a full stop. I don't want to monkey with the actual physics of the flight model, so this is a way to simply tell the ship to stop. Stationkeeping does not work when the throttle is open, and using stationkeeping at full flight speeds will slow the ship… just not very fast. Reverse will. This will be a key that the player can switch between being a toggle or a hold, and it will turn the thruster into the control of powering a reverse thrust. Stock, it won't be much different from stationkeeping; more for backing out of a dock or low speed location. As a fitted item, applied later in the game, this can become a full reverse thrust, but we will need to test and game balance this.
We also built the tools for tuning the flight. One key records a flight to a file. Another opens a tuning panel, with every flight value as a live row. Its second page, the envelope predictor, works out the ship's limits (top speed, turn rate, throttle response, and slip) from the design's own formulas, separately from the flight code. A flight can now be checked against the intended design and compared with what was actually flown, statistically. The predictor matched the design and the recorded flight closely.
On Saturday I checked the packaged game. Ships arrived in clear space. A second ship arrived clear of the first, and each saw the other. A change on the tuning panel reached the server and changed how every ship turned, live. One check failed: in the cockpit view, your own hull doesn't yet cast its shadow. The engine can do it, so this one is ours to fix.
The asteroid field and the radar
The first slice of the density field is in the test zone. The density field is the system that will shape every zone: where its rocks, dust, and gas sit, and how thick they are. Every rock is worked out from the zone's own numbers, so every player sees the same field without a single rock being sent over the network. A fingerprint of the field, printed on any machine, proves that the server and every player hold the same rocks. The hand-placed rocks are gone.
The rocks' collision was chosen by measurement. Three kinds of collision were flown against each other on a server, three hundred fighters per kind: one simple shell, twelve pieces, and the rock's own surface. The rock's own surface stopped ships closest to what the pilot sees, at the lowest cost, so the rocks now collide on their own triangles. Ships keep their simpler collision, because a ship is the body that moves.
The radar went in with the field. Ships, field rocks, and placed objects all feed one contact list, each tagged by what it is. The radar shows that list on two round scopes, front and rear, drawn on the cockpit's own surfaces: the design we chose last week. A ship's faction, friend or foe, comes from a tag set when it spawns, with placeholder factions for now. Our working rule is that no code can be throw-away. This code has to build towards the finished radar in the HUD (head-up display). That means we need to include asteroids and other contacts that fade in as they get close, and contact channels the pilot can turn off, such as every environmental contact. This allows the pilot to control what's on their scopes. The pilot can switch any family of contacts on or off from the cockpit, such as asteroids in combat, or whatever combination they need; perhaps objectives only.
A sky beyond everything
A game's sky is a huge sphere drawn around the player, and anything farther away than its edge disappears behind it. Our first sky was a quick one, put in for the lighting tests. Now it is set for the real distances the game needs. A moon as far from its planet as Titan is from Saturn, about 1.2 million kilometres, has to stay in front of the sky. The sky has to render at infinity, and it must never hide anything that is in play.
The engine's source code gave the limits. The world reaches about 44 million kilometres from its centre, and the game camera clips nothing by distance. So the sky now sits 250 million kilometres out, beyond the worst case the world allows: a camera in one corner and an object in the opposite one. Nothing that can exist in a zone can ever be behind the sky, and drawing it costs no more.
The ships in the zone test level rendered very dark, and a brighter ship of unknown paint would not tell us whether the paint or the light was at fault. So we built four reference balls of known brightness as a gauge: grey, at the photographer's standard 18% grey card; white; black; and chrome. The first measurement settled it. The fighter read the same as the black ball, so its paint was, in effect, black. It now wears a temporary light paint for the lighting work; its real colour belongs to the art.
The reference balls (chrome, white, grey, and black) beside a fighter, a station, and two rocks in the zone test level.
Then came the balance. The key light looked a bit dull to me, but I was afraid that more light would just make the ship read flat. Looking at our reference target images, we could see that the glints, or specular highlights, were about one stop (a doubling of light) brighter than the lit faces. Essentially, the problem here was dull paint, not the level of the light.
To adjust this shininess, we went into the material (or really material instance) for the ships we were testing, and made them much more glossy. With the sun raking across the ship, the hull now grades from dark lower sides to bright top faces, with crests that reach to almost full white. That is the pattern we see in the references.
Close on a fighter's hull in its temporary light paint, with the reference balls beyond.
There is one important caveat we have to have with this, and that is complete lack of control of where the camera will be, and complete lack of control of the relationship between the light sources, subjects, and the camera. We may have to rebalance off of this as we go through gameplay, as it's one thing to set up a great shot for the demo reel, but if this means the world is "realistic" but unreadable in flight, then we have failed.
The sky itself has to hold up on a large screen. The current skies (and you will see this in a lot of the examples we have been posting) are a very low resolution test from when we first got started experimenting with look, about the time we decided on the name and location of the game.
We desperately need to rebuild our skies at a resolution needed to ship at AAA quality, the top tier of big-budget games. The sky will be NASA's 8K star map of the Milky Way, as opposed to the 2K version in the temps, with dust and clouds on top, sharp enough to match a 4K screen pixel for pixel. A sharper sky costs us memory, not frame rate, and won't improve the look at all for most people. We will be adding local stars on top of the background sky procedurally, so they stay crisp and sharp regardless of the background — and yes, the background is so far away in real terms that entire stellar systems rest between the player, their zone, and the backdrop.
The plan is to use the 8K sky in Blender (a 3D application) and then set the clouds by hand in 3D, around a camera at the star map's centre, so the seam and the poles come out correctly.
Concept art and massing models
The concept art keeps coming. I know I can't really stop or slow down. The art side of things, which I know has to get done, happens either when I've had enough technical banter and need a break, or when something is compiling or cooking.
One of the key models I needed was the target drone. In upcoming flight tests, we need something to shoot at, and something that will eventually shoot back. I did toy with a large sphere, but the reference, as amusing as it is, to other test drones was a little too obvious to be either amusing or a good homage. With that idea abandoned, I looked at some of the background "runabout" ships that I had on the drawing board.
Below are two versions I worked on. The softer, rounder one I was working towards an almost spider-like drone with lots of lenses that look like eyes… but it was becoming too pointlessly anthropomorphic for me, and I settled on the one-seater runabout with the cockpit removed and the detailing changed.
Proposed, but abandoned, target drone. The orange dots were marking where the cameras might go.
Current target drone concept.
The massing model for the target drone concept.
Navigation beacons and race gates came from my sketches, and were rendered in the style of studio miniatures.
There are two styles of navigation beacons, cylindrical and tapered. I wanted them to have a real industrial feeling to match the style of the first zone. I wanted them all to be slightly different, but clearly built from the same schematic, so I have five slightly different versions of the stand-in models for each style of beacon. I'll be putting the "older" cylindrical styles closer to the station, and the "newer" tapered style further out.
Navigation Beacons.
The race gates were more of a necessity. We will be testing the flight model, and we need to do this along a "course" while we record telemetry. In our "never make a throwaway when you can make the real thing" philosophy, we designed a complete slalom race course "mini-game" that will also serve as a flight tuning and telemetry test. Thus: race gates. Big enough for the ships to navigate through at speed, and with lighting that will change depending on state: completed, next, final. These will also show up in the HUD and radar as special symbols and colours.
A race gate.
A lot of my sketches are fast and loose, defining shape, intent, and silhouette. I would love to spend more time on them, but as we know, that's just not possible right now. I'm finding myself increasingly resorting to "paint bashing", where I first work out a sketch, get back something that is almost, but not quite, completely unlike what I wanted, and instead of beating a dead horse (or a silicon brick of an agent), I take what works into Photoshop or Blender, bash it there, and try again with something closer to what I wanted.
When it comes to making the massing model, I'm taking full advantage of the generation step (for a full description of the pipelines we are using, please read Designed and Built by Hand and Making Concept Art). The service allows me to have up to five redos per generation. I use them all, unless I abandon the attempt altogether. This helps me in two ways. As I'm leaving a lot of the fine detail up to the Blender stage, where I add them by hand, having multiple renders gives me more differences to use as guides in the final step. This is just another streamlining tool, and I'll only use what works. The second advantage is more standing variety. With the final builds, we will be able to design additional skins, paint-jobs, and variants in shape and detail. With five variations, all subtly different, we can use these stand-ins in our development builds and get that variety for "free", now, until they are replaced.
There are sixty-six models imported into the game now. The sixty-six are variants of 25 different designs, from the five-metre long strike drone to stations 1.66 km wide. Late on Sunday I also worked on a bomber with the working name Mosquito, after the de Havilland Mosquito of the Second World War. The concept is still very rough. The model generated from the initial sketches had lots of faults. I had several rounds of bashing in both Photoshop and Blender, and each iteration gets better. I'm not done with it yet, but here is the current state of it. Like the Light Carrier, I may do a separate log on just this one ship.
The Mosquito: Massing Model being Bashed in Blender (WIP)
The Gallery
The website gained a Gallery. The home page keeps its full-screen splash, with one addition: a Gallery link, ahead of the DevLog. Pretty pictures first, then the question: how did they make these? The devlog answers that. Each design has its own page, with its concept art and its massing model, which turns on its own and can be turned with a mouse or a finger. As we know, the massing model is just a stand-in for rebuilding, not the final ship. Nearly all of the models now have a stub of an entry. These will continue to be updated as and when.
The freighter is a design of mine from school. A spherical bridge leads a line of identical cargo containers, coupled end to end, then an engineering container and the engines. Every joint uses the same coupling, so the train can be as long as it needs to be.
The freighter: my sketch from memory, and the rendered concept used to build its massing model.
On our community server, a Design channel holds one post per design, and anyone can reply.
On paper: NPC pilots and ship classes
NPCs (non-player characters) will fly against players, beside them, and around them as traffic. The question was: How should they fly? I don't want players watching a ship and thinking: wait for it to telegraph its second phase, then it will fly straight for three seconds, long enough to get a lock and fire two missiles.
Nothing here is decided yet. The proposal is that every NPC flies the same ship and the same flight model as a player, with a computer pilot on the server sending the same controls a player sends. Physics does the rest: a heavy bomber cannot turn with a scout, because its mass says so. Each pilot would weigh its options against the moment and pick among the good ones at random, so there is no fixed sequence to learn. Pilots would be individuals: they would react to a lock, remember what last hurt them, lose track of you in dust, and cover each other. The aim: players learn what kind of pilot they face, never its timetable.
We also built a reference list of real and fictional ship and aircraft classes, from fighter to flagship, each checked against current sources. Science fiction and the navy often disagree: the Star Wars wiki itself classes a Star Destroyer as a cruiser. One surprise: Star Trek's Constitution class is a heavy cruiser, but the real USS Constitution is a frigate. No ship in the game has been named from the list yet, and probably won't ever be. The main reason was to understand the historical use of terms like Frigate, Corvette, Cruiser and to know when they came into use, and why. As our ships go from small aircraft up to huge capital navy ships, we looked at both. Things we discovered while doing this were like this:
Destroyer. A fast, manoeuvrable, long-endurance warship that escorts larger ships. It began in the late 19th century as the "torpedo boat destroyer".
Historical examples:
- USS The Sullivans (Fletcher-class)
- HMS Cavalier
- HMS Havock (1893) (the first destroyer delivered to the Royal Navy)
Week three of fifteen weeks (about 100 days). Ships collide as physical bodies, they tumble when they are hit, and the week's goal passed across three machines. The asteroid field and the radar are in, and the sky sits beyond anything a zone can hold. The Gallery shows the ships as they are made.
Next: absolutely proving by excruciating levels of testing what exact flight model, collision system, and replication scheme we will use, then giving each ship its mass and power in the systems that will run its weapons and abilities, then the first tests with hundreds of ships on one server.