Howdy,
this week we will be diving deep into the workings of cargo pods and their seamless flight animations. Most of you playing the expansion have probably already seen them in game. The positive reception makes us very happy.
Ascending to platform in orbit above Nauvis.
The initial draft of a pod being released from a set of claws came from Earendel. You can see that the essence of it has remained relatively unchanged throughout development. In the very first version, the player needed to insert a capsule item into the rocket to travel. It got scrapped, because it was just pointless busywork. However that item was one of the ingredients of mech armor, hence the visual similarity. Following the draft, Jerzy modeled a 3D version of the claw rocket and pod.
Then the branch lay dormant for a long time until core gameplay coding was finished and work resumed on less critical features such as fancy flight animations. I recruited the help of Jaroslaw, who had just finished his modeling work on hub, pad and landing hatches. Together with his modeling and volumetric cloud simulation and my coding and shader work and Ian's audio, we polished everything for the main release.
Earendel's concept art of the pod and rocket separation.
Before any graphic work could begin, it was necessary to develop a backbone of how the items would move from one surface to another. At that point in time, the logistic requests functioned fine, but they just teleported the items instantly.
Taking inspiration from the rocket, which had an inventory and could carry items, I decided to make the CargoPod its own new entity. While the rocket would take care of flying out of a silo, it would be shed on the original surface and the pod would have the functionality of going to another surface.
The second (and trickier) part of the equation were destinations. Even in the "vanilla?"/"stracciatella?" Space Age the pods travel from silos to hubs and from hubs to landing pads. Two of those may be further extended with cargo bays which add more hatches, but aren't destinations themselves.
The solution was to introduce stations, a layer of abstraction where all the buildings involved in orbital logistics register with their force and receive a unique ID. Any hatch on a cargo bay just joins the existing station.
Then, to address items to another surface all we need is: Surface, Force, Station and Hatch. Depending on the usage some of these are optional. A starter pack rocket does not need any destination. Traveling player can launch towards a planet and only resolve whether the target is ground or pad at the apex. A logistic order will know its station beforehands.
The nice effect of having generic logic is that technically the shipment can go between any two surfaces in the game and with any amount of stations. It even became useful in base game when rocket silos could target their own landing pad with space science and it would just work out of the box. I didn't want to restrict the potential by hardcoding everything to just planets and platforms.
My notes from when I was trying to carry the station concept one step further and combine the GUI for silo, hub and pad into one. The needs ended up being too different though.
Just like with the station system, I did not want to hardcode animations either. Custom planets would be one of the first things to mod in, so my priority has been to allow as much customization as possible.
Every detail of the flight animation is provided by the fully moddable procession system. Each space location provides its own set of departure and arrival animations to planet itself and to any space platform in orbit.
For instance, when a pod gets issued to fly from platform around Vulcanus down to the surface of Vulcanus, it would take the "vulcanus-platform-departure" and "vulcanus-planet-arrival" animations that match in style and stitch them together. Sometimes the pod has to wait in transit for a hatch to open up. In those cases "vulcanus-style-intermezzo" looping animation can be inserted in between to pass time.
Zooming in further, each procession has a timeline comprised of a variable number of layers. These layers control various aspects of the animation or draw graphics. Many aspects of them are driven by 1D, 2D and 4D Bézier curves and their normalized variants.
Planet landing curve open in the Factorio Spline Editor.
For modder convenience, I have published my custom Factorio Spline Editor online. It is fairly difficult to get the shapes right without it. As a bonus it also exports the curves directly in the desired format.
Descending to Nauvis from a platform in orbit.
A simplified timeline of flying down from a platform to surface highlighting when each procession layer is active to make up the final look.
Now, what allows the animation to appear seamless is the cover layer. At some point, the whole screen needs to be covered up to maintain the illusion when the pod teleports from one surface to another. Just swiping a flat image across the screen would have been serviceable. In fact, Albert favored leaning into a more stylized aesthetic.
My opinion was that we could get a very impressive looking animated edge with very little work. All I did was ask Jaroslaw to generate a depth texture for the clouds. When the edge fades, instead of being multiplied by a flat value, it cuts the clouds off at a certain depth. This way they come onto the screen in clumps and bleed naturally instead of forming a thick wall.
Manually demonstrating the soft masking shader of cover layers.
While all this functionality sounds extremely powerful already, as I started making the final cutscene for Space Age, it became evident to me, that mods wouldn't be able to live in harmony like this. If every aspect of the animation lives inside these timelines then any new pod, planet or station would have to do unbearable amounts of work to integrate itself into all existing processions, creating countless duplicates that only differ in several sprites.
Thankfully, we have one more trick up our sleeve. In the current version the planets in fact all use the same flight animation prototype. The way we introduce appropriate variants is through the use of catalogues. A catalogue is basically a list of images or sounds that the procession animation can refer to. Instead of having a predefined asset, the procession will refer to a CatalogueID and specify where to look for it.
Any missing graphic or sound will just be skipped. New planets will play at least some animation even if they forget to define clouds. New pods can provide their own flame sprites that still play at the right times. New cargo bays or hubs can just say their illumination looks different and not touch any of the procession data.
And if you are feeling fancy, you can give your planet an entirely new timeline, but still utilize pod animations and planet sprites from the default Space Age catalogue IDs. For a simple example, a parachute sprite could be added to pod catalogue and the flight speed slowed down significantly. Any third party mod adding a new pod type would have the option to support your planet by just defining a parachute graphic and nothing else.
As always, orbitally deliver your thoughts to the usual places.
