Built as Designed
The real game ran on three machines this week. We also built our first tools for checking the game against its design.
This week the game project itself was packaged for the first time and flown over the local network, with two players seeing each other. Around that, the build was checked against the design, the flight model moved to a fixed step, and the controls gained an in-game profile switcher. Placeholder asteroids arrived in the engine. The lighting work took on distance, and a design document for partners was written and red-penned from end to end. The radar was designed, and the concept art kept coming: a light cruiser, an asteroid station, a family of free-floating stations, and explosions.
Mood plate for the rift: dust-fire amber and starbirth teal on near-black; early test.
The game on three machines
For the first time, the server and the client were packaged from the real game project rather than the test project. The first test ran on one machine. Two clients joined and flew together, one left without disturbing the game, and two more joined, so three players flew at once. Everyone joined and left cleanly.
The LAN (local area network) test followed: the server on one machine, a client on each of two others, each pilot seeing and flying alongside the other ship. That meets the first slice's done-condition, on the real game, across three machines.
As momentous as this is, it worked, so there's not much to say about it other than that it worked!
Built as designed
As the game grows, so do the tools that check it. This week we built our first three. An independent read-through checks the code against its rules. A full audit compares the whole project with the whole design set. A verification script checks the game's data on every build.
Most of the first slice passed. The client sends only its controls, the server checks every value it receives, and the flight formulas match the design. The tools also did their job and found places where the build and the design had drifted apart. Building them was its own loop: we made a test tool, found problems with the test tool, and continued to fix the tool until it caught the errors it was there to catch. Then we fixed those errors.
Two rules sit behind every build. The first is that data is never code: every value the game uses lives in a data file, not in the code. In my words: "Always data… Data is data. Data is never code." The second is that nothing gets built twice. In my words: "We always start building the stub of a system before we use it so nothing gets thrown out." When we were testing, we needed to compare controls for HOTAS (hands on throttle and stick), KBM (keyboard and mouse), and controller. We could have thrown in some quick, down and dirty, temporary inputs, but instead we took the time to initiate the actual input-switching code that will be used in the final game. Slower to test, but nothing is wasted.
The flight model is also using a fixed step. The flight calculation runs 60 times a second of game time, whatever the machine's frame rate, the same idea as Unity's Time.fixedDeltaTime. This matters for networking. The packaged server runs at 30 frames a second, while the editor runs at its own rate. Once each player's machine predicts its own ship, both sides must calculate identically, or the ship visibly jumps when the server corrects it.
We also prepared the stat calculation. A ship's stats are the numbers that decide how it flies and fights, such as its mass and its power. These stats change when anything is fitted to, or removed from, the ship. The stat calculation is the one piece of code that turns a ship's chassis and its fitted parts into those numbers. The Bench, where a pilot plans a fit, and the live server both use it, so what a pilot plans is exactly what they fly.
Controls
All four shipped control profiles are now packaged into the game so every machine in the test could fly whatever controls it had. The four are HOTAS, joystick and keyboard, controller, and keyboard and mouse. Currently the P key opens a picker. A click switches the profile at once on the player's own machine. For now, this is "P for Player Config" or "P for Profile", but — not only will this be remappable — it may not survive as the method in the final game. We've barely scratched the surface of the UI (user interface) and UX (user experience). Switching is allowed at any time, in flight included, and the choice survives a restart.
The default stick mapping is now roll on the stick's sideways movement and yaw on its twist. Every profile carries its own switch to swap the two. For testing, the HOTAS is the default device; in public testing, the controller and the HOTAS are equal primary devices. On keyboard and mouse, the mouse's forward and back movement drives pitch, and its side-to-side movement drives roll or yaw through the same switch. Combined steering, in the style of X-Wing, may be an input option if players want it, but it's not currently part of the flight model. We will have to wait for feedback on this one, and it opens the need — as X-Wing had — for an "alt" button to enable roll.
The design also gained input modes: Free Flight, Combat Flight, Cruise, Docked, Map, and a remote-vehicle view. Only one is on at a time, which lets the same keys do different jobs in different modes.
Rocks
Twenty-one placeholder asteroids are now in the engine for the server tests. They were made in an image-to-3D service, as we needed rough shapes fast. I suspect they won't last into the final build. All material like this, and our test levels, sit in a Dev folder in the Unreal project, so we can easily identify and cull them before shipping. They share one master material, and each has a simple collision shell. At full detail, each rock carries between about 300,000 and almost a million triangles, drawn by Nanite, the engine's system for very dense meshes. In my words: "if they hold up, they may be used in the early builds." For now, ships fly straight through them; ship collision is being handled separately.
The asteroids are needed for a number of tests: the distance view test, the density content tests (procedural asteroid fields and the like), and the tuning rig. The tuning rig is the test ground where the flight model gets tuned. The rig needs a field of rocks and a camera that watches the ship from outside. The tool that scatters the rocks will be built as the first slice of the zone's density field, the system that will shape every zone. This follows our "no wasted work" rule from above.
Lighting a zone at distance
A zone is huge, and the question this week was what happens to things far away. In the end, I was probably too paranoid, and over-optimising prematurely. I was worried about the infinite-horizon problem, and was looking into "black fog" and fades… but in the end, the size rule answers most of it. At 1,920 pixels across and a 90° field of view, a 15-metre fighter is about eight pixels tall at 1.8 km. Our largest ship, currently at 650 metres, is a single pixel at 500 km. Our tallest station, at 1,250 metres, is two pixels at the same distance.
We tried to fade far objects into the background, and it failed at any range before it became irrelevant. Black fog turns objects into black silhouettes against the bright galactic band, until they become so small it's irrelevant (see a pattern here?). I should have known this from all the time I spent running a .30 calibre machine gun in Day of Defeat, picking people out of the fog. At their distance, they were a clear silhouette of fog against the background, not hidden in it. Very quickly it became clear that we just need to fade off content when it becomes one or two pixels in view, and that I was over-optimising, and optimising way, way too early.
Research backed the outcome. No shipped space game we found hides distance with fog. EVE Online shows only what shares the player's grid, 8,000 km across. Elite Dangerous players are told a 20-metre ship is about a pixel at 3 km, and the HUD (head-up display) brackets do the work. Fighter-scale games fight at about half a kilometre to three. So the decision is lighting only. Right now, no fade is built; content too far away to see will simply not be spawned on the player's machine, and we'll see how that works in playtesting.
A read of the engine's own source code checked how its lighting and shadows behave at distance. In several places, its defaults differ from what Epic's documentation says, including how far ray-traced lighting reaches.
Exposure stays fixed and manual. I don't want to use dynamic eye adaptation and auto-exposure. The contrast is too high in space between brightly sunlit objects and deep shadow. I feel that a fixed exposure will be more stable and easier to light against. The start point for the next test is the setting I use for cinematics: a 32,000 lux sun with the camera at ISO 400.
Our target look is set by five reference images that we created for the GDD (game design document). What they share is the target. The galactic band is bright and textured, and it acts as the light source for the soft, almost ambient, fill. Shadow sides are lifted and never dead. Warm orange engine glows sit against a neutral world, and highlights roll off rather than clip.
One of the five look targets: arriving in a new zone.
Another look target: the broken galactic band behind dark dust lanes.
A design document for partners
A design document for partners and vendors was finished this week. It was written new, from the game, rather than copied from our internal design set. It runs in three parts: the game; how we build it; and where we are and where we are going. A glossary of about 190 terms closes it. It was then read end to end against itself, and the red pen began on the opening sections. I would really like to polish this and make it much more readable, but I just can't justify the time. I'll keep polishing it in "spare time" (hah!), but for now it will have to ship as is. It's just too long to cover everything in a polished manner, and the game has to win over a public design doc.
The document settles the game's four design pillars, in rank order: Dogfighting, Story, Diegetic, and Shared living world. Diegetic is a term from storytelling. According to the Cambridge Dictionary, the term describes elements like music or sound that are part of the action and audible to the characters within that narrative world. We are using it here to mean that everything we do in the game is described in the fictional world we are flying in, and nothing is arbitrary. Every reason, cost, and spectacle happens in front of the pilot, inside the fiction, explained by the fiction… so no arbitrary levels, no arbitrary caps, no arbitrary stats.
The new document also settles six unique selling points:
- Fifty pilots, one fight, no raid leader required.
- X-Wing hands, not Newtonian drift.
- A story that teaches you to fly, then hands you the world.
- No levels, not now, not in the expansion.
- You, and your real life, your time, are never the stake.
- One pilot, one seat, always.
The ship classes, for now, are Scout, Fighter, Bomber, and Support. "Why Support?" I've been asked. I admit that it does resonate too much with a space game that just didn't work (Overwatch in Space, anyone?), and I DO NOT want to resonate with that game. I don't intend to make Support analogous to a "healer"; this is space combat. The Support ship is going to extend your sensor range and provide shield and energy boosts, but it isn't going to be doling out healing potions or piles of missiles out of nowhere… It's just not diegetic or plausible. (How DID that wolf swallow a full set of plate armour?) The Support chassis can "fight its weight, but your best friend when you need it".
A pilot is never locked into a class: dock, change ship, change role. A ship's sockets have no fixed place on the hull. They are what the ship carries and can do, and the look comes from the skin. For now, candidates for the starting ships are all from the same family.
Concepts for the four starting ships: Fighter, Bomber, Scout, and Support.
Mass models of all four starting ships were made this week. A mass model is a rough block that stands in for the ship until the real hull is built. The mass model will also be used as a template to help build the final hull (see DevLog 05).
The mass models standing in Unreal.
The flight section was rewritten to describe the flight model as it is built. The engine pushes the ship along its nose, and thrusters turn it on all three axes. The zone's medium — the gas and dust of the zone that the ship flies through — works like a keel: it bends the flight path round towards the nose, and sliding sideways costs speed. We know that this is fiction, but so are "planes in space". This makes the flight model work as a simple system based on forces. A ship standing still can point anywhere, but it cannot run from anything.
We have not discussed story much here. Currently the story is very sketchy, but we know where we are going with it. Story is a clear pillar of the game, probably the most important one. That being said, the systems that carry the story must be built first: flight, zones, server, voice generation, the sharded and instanced architecture, and more. Story arrives when there is a place to keep it. Like so many things in this devlog, we need to keep laser-focused on the task at hand. I could happily spend my next twelve weeks writing the story! But then I'd have one week to make the game! Better the other way around, as the story can grow with the game later.
The radar
The cockpit radar was designed this week. Three designs were considered. Design A is two round scopes, front and rear, as in X-Wing. Design B is a flat disc with stalks showing height, as in Elite Dangerous. Design C is one scope covering the whole sphere, centre ahead and edge behind, as in Wing Commander.
We will start with Design A. We will keep Design C as a candidate, but right now its only advantage is that it takes only one scope, and it is harder to read. Design B leaves the cockpit. My reasoning: it is either fixed in the axes in space, and the pilot must interpret their current ship's relationship to the local spatial plane… Or it is fixed to the ship, in which case the "bubble" will wheel and careen around as the player madly reorients in a dogfight. Its idea lives on as a full-screen 3D map on a key, the way M brings up the map in an MMO (massively multiplayer online game).
The radar shows every contact. The windscreen shows only the pilot's own picks, the missile lock, and the aiming aids. Each contact's dot is coloured by what it is: green friendly, yellow neutral, amber not identified, red hostile, blue for objectives, and white for ambient objects such as asteroids. A second shape around the dot is proposed to show tracking: yellow for the pilot's current target, red for anything targeting the pilot.
A proposal for the missile lock went into the design notes too. The lock marker starts large, faded, and red. As the lock firms up it shrinks, rotates, and runs through orange and yellow to green, then flashes twice with a tone at a full lock. A missile fired early is not a dumb fire; its accuracy follows the lock. If the target drifts out of the sight, the lock slips, and the circle grows and spins back the other way. It was one of about 140 design notes captured this week for a later integration pass, none of them ruled yet.
Ships, stations, and explosions
DevLog 08 covered how we make concept art. This week the same pipeline turned out a light cruiser, given the same studio-miniature treatment as the hero fighter.
The light cruiser as a concept image from my sketch.
The Federation Light Cruiser mass model standing in Unreal.
Stations came next. The asteroid station is a hollowed asteroid with its shell, exposed towers, docking bays, and observation galleries. The free-floating stations started as twelve completely different forms, from a torus ring to a branching tree of trusses. Finding one that worked was not easy, and I've fallen back on "The Mushroom". I've made them before and they feel nicely stable. I want to be more creative, but it's going to take more design time. The asteroid station is more for the starting zone, whose name is tentatively "Roark's Drift". The others are for the second zone, which represents the Principality. The Principality is a little higher on the tech scale. The "city" version has a force bubble around promenades of trees and good views. (Fun if we ever implement first- or third-person action… not this year, though.)
The asteroid station: a hollowed rock with the station built into it.
The Principality stations are my own design.
The Principality station design.
I did generate contact sheets of explosions for the concept art pages. It's a real cheat, but so many of the ones I could find online were either generated anyway, or had very dodgy provenance. I have some explosions of my own, but I'm not comfortable using them, for the very same provenance issues. To composite them, fire is added as light, while smoke is solid and needs a real matte. An image shot on black carries no transparency for dark smoke, so we built a script that makes it for a whole sheet at once. It worked "mostly well", but there were still holes in the final mattes. No matter how you do it, it's hard to find the difference between black smoke and a black background. Where the mattes failed, I had to fix them by hand.
Sixteen fireballs with their transparency built by script.
Not everything worked smoothly. An attempt to turn a finished battle image into painted concept art failed with every tool tried except "by hand". My verdict: "Time to give up." Not because I can't do it, but (one more time) it's not the right place to be spending my time. The concept art and starting assets took a real share of the week, and the battle scene below is where a lot of that time went.
The capital-ship meta, assembled from separate layers.
Week two of fifteen weeks (about 100 days). The real game runs on three machines, and the first tools for checking it against its design are in place. The flight model runs on a fixed step, the lighting has a target, and the radar has a design. The art pipeline is producing ships and stations faster than they can be modelled.
Next: one brief carrying every remaining fix, then the tuning rig and its asteroid field, and a scale layout level to light a zone against.