Remote Orbit Retrospective

Retrospective

This is intended as a review of concepts, scope, and how the process of making the idea — changed it.

I am writing this several years (and several projects) after the fact, partly because I still have this domain, and partly because I feel a great fondness for this project. Even though I now know it was quite beyond my capacity, and in many ways severely misguided, I learned a lot about games, art, and myself in the process.

Please forgive the long-windedness of this, but anything less, would be insufficient to explain what this project meant for me, or how much work I put into it. I want to explain what I was trying to make, and why it wasn’t possible. If you happen to be in a similar position, I hope this will be useful to you.

The original inspiring concept came from sources like Magnetic Rose, Titan A.E., various books of science-fiction, and one specific episode of Cowboy Bebop. In this episode the protagonists have tracked a criminal mastermind back to a derelict space station. The plot of the episode was incidental. I wanted to see more of the derelict station. It’d been jury-rigged by several generations of people who wanted to escape from the rules of organized society.

It was a mess. Null gravity. Random chunks of ships welded on, over many years. Mazes of pipes and tubes. Cats and dogs, running (floating) wild. Tomato vines growing on the walls of corridors. No organization structure to be seen. I wanted more of that. So I started with the basics. ‘Is there a game in there?’

You can spin that any number of ways. You can make it in as a first-person, third-person, or isometric, and the outcome will be drastically different in each case. Gamedev is incredibly fiddly. What you choose to add, or omit, will dramatically change the player experience.

I didn’t have a budget to speak of, so characters were out of the question — and it was just me working on it, so I wanted something fairly contained, and within my experience as much as possible.

Initially I concepted (pencil sketch, it’s a great way to get an idea out) a small level, intended to be explored in first person, zero-G, with six-degrees-of-freedom. I’d wanted it to be a series of puzzles, where you explore abandoned rooms, and unlocked secrets. Eventually you find out why you are trapped, alone, on a space station. I didn’t have a reason yet, but I was sure I would come up with one in time.

Hovercraft

The only feature that was passed over from this prototype was the basis for the Zero-G flight mechanics.

If you dig deep enough into the history of RO, you’ll find a different game. One I never got around to naming, in which you piloted a hovercraft armed with moddable weapons, and fought robot ships in tunnels.

I’m fairly sure I still have some form of game files on a drive, but I have no idea if it would still run, and I absolutely failed to record gameplay beyond this very early prototype that shows nothing of the art design.

As far as I can tell I worked on this hovercraft game for 2-3 months in early 2017.

Addendum: The project still runs (bless Unreal). I’ve expanded on this in a Special Page dedicated to what that game might have been. You may start to see a pattern here. No one should ever accuse me of dreaming too small.

First Recorded Gameplay — June 20, 2017

The controls were 'WASD' to control movement on a horizontal plane, with 'C' and 'Space' for up and down. 'Mouse' for two axes of rotation, and 'Q' and 'E' for the third. I built movement on physics because I wanted to bounce around a bit. This was the basis for a majority of the mechanics, and also the problems during development.

On July 7th 2017, I uploaded this video of the current state of the game.

The rough concept here was that you were on your station, and you could send out your drones to pick up supplies from neighboring asteroids as they passed within your range.

The drones had a docking port to return to and carried a cylindrical container for holding ore. I figured it worked like ice core drilling, but with lasers. They'd disappear from your view and then come later back with resources.

Some of these shots are my favorite from the whole project.

This was a prototype of a base building tool I was considering using to generate new rooms on the station.

You load it with resources and plug it on a door connector. Then it would enter building mode, you'd select the module you wanted, and it'd build it.

I figured it would have a construction timer and a visual effect of a form-shaped curtain over the in-progress build.

I didn't really like this for bigger constructions, and was thinking of adding a 'large construction' module. I hadn't worked out how you got it yet. I didn't want to put that much responsibility on the drones, since they were not very smart and could easily get stuck.

The constructor tool didn't work out in the longer term because the loading of resources was fairly cumbersome and had to be repeated for each material type. I didn't come up with a good solution to that. Much later, I considered pneumatic tubes as a resource transfer option.

Things were going really well at this stage. I hadn't hit any real roadblocks yet.

Drone garage and trash collection — September 1st, 2017

I'd expand the drone to be modular. I gave it magnetic grabber arms and made a garage module to store it, with an internal airlock and a rotating stand. The concept was: rather than the drone bringing back 'ore' in an ore tube, it would bring back scrap metal, you'd compact it, and it would be processed for resources.

Honestly, this mechanic already felt overly complex. The number of steps needed to make progress would have been tedious. I didn't really have a game to test yet, so it was hard to really see that. I tended towards getting investing in the models before the gameplay and then moving on before solving that issue.

I thought that if I liked the visuals it would inspire me to make it work. Sometimes this was helpful, but often I had to deal with art assets designed prior to a number of core features, that either had to be remade or, let go.

The Second Misstep

So, I can tell you exactly where the project really started going off the rails.

I tried to put a camera on the drones, so I could see what they were doing when they were away.

Look, it's an engaging concept, but it causes so many issues with scope, and scope will only cascade outwards. I didn't know how to properly evaluate an idea's feasibility, and my success thus far was making me over-confident. I should have kept refining what I had before I tried any new features.

So what are the problems with putting a camera on a drone?

Well, before I did that, the places the drones were going weren't real. I didn't need to make them. For some reason I thought I'd make physical asteroids anyway, soooo... I should add a camera so I can get a closer look. Now I had to make all of that content.

If you can help it, never pass up the chance to not show something. Let them imagine. You'll save yourself a lot of headaches, time, and money. Just don't show it.

I stopped focusing on the drones at this point in development. I always intended to bring back more of those, but I never got around to it. A great deal of content stopped functioning as I worked towards completing the other features I wanted.

My excuse for adding all these features was that I believed they all needed to be present for the game to function. I wanted fidelity of vision, and I didn't want to settle for less than the whole concept. I know. It's a mistake I continue to make.

It wasn't long after this that the player station concept was scrapped in favor of a personal ship. Why construct a station, when you can scavenge components from derelicts?

This was both closer to the desired concept and further from achievable.

Abandoned Stations — Oct 23rd, 2018

We're jumping ahead over a year now. A lot of things changed in that time, and I was not great at documenting this. I think it was partially because I had thrown out a lot of work, to improve on the concept, and it'd been mostly broken for a while.

World Building

A story was growing in my head to explain how I could have an unlimited supply of space station debris to explore and harvest from. Suppose they were building something like a dyson sphere, around a water planet (typically dyson spheres go around a sun, not a planet) that had extremely deep oceans. Say they build the sphere around that planet because they needed access to large quantities of water, for cooling maybe? Doesn't matter. It needs to be a water planet though.

They are building this massive structure in orbit, but disaster strikes. The sphere breaks up, and spreads an impenetrable field of metal chunks all around the planet. Nothing can take off, nothing can land, no radio waves can breach the cloud. This spacefaring society cannot launch a rescue mission, and naturally assumes that no one will survive long on the surface installations. So they abandon the planet.

Meanwhile a group of workers manning a floating platform are cut off and doing their best to survive. They form a new society from what little they have, and a culture of fishing the non-terrestrial oceans.

They have no means of acquiring new materials to use, so for a long time anything you can build with is precious. They use advanced 3D printing, so nothing goes to waste.

Over time the debris field starts to organize itself into a ring, as most do, and this opens up a clear path at the planet's poles.

The best way for them to get building materials is to use a limited amount of what they have, make a rocket, and send someone up to get it.

Initially I thought the player might be the first to go up, but overtime I figured that would be excessive pressure, and annoying. it would be better if they were part of an organized operation that had to work somewhat independently. A small fleet of solo scavengers, with a central hub they send resources to.

As the concept of their society grew, I started imagining them more as an extremist militarized dictatorship. They had formed in a period of disaster, which would lead to intense rationing and aggressive laws. After so many years in isolation I figured they would have their own mythology and warped history.

I started making props with fish and water motifs. The player ship and the survivor technology became angular, printed, shapes in whites and blues.

The stations in the debris field were from another civilization, utterly different. So I chose an opposing theme of smooth, rounded forms in dark green and brown.

I decided the floating city on the surface was divided up by levels, the top most section being the ruling class, admirals, the wealthy, high command. In the middle were the working class, people with just enough to feel ok. And on the bottom was the Gutters, a place half flooded with salt water that houses hot, loud and dangerous machinery, water processing, fisheries, sewage treatment. A large portion of the population lived there. I had yet to overtly state this anywhere in the game, but if I'd had time it would have been delivered to the player in a slow drip of clues.

Attachments, Hardpoints, and Adhesive Patches

Initially I just had square, item-sized, adhesive patches on the walls. These were one of the earliest additions to the game, though could only hold one size of item at the start. I figured it was all physics-based, and I didn't want to add an inventory system (unrealistic storage of mass. Illogical), so I would want a way to organize and hold stuff in place.

From there, I expanded on the idea with hardpoints. Basically, grids of various sizes that could hold items of various sizes. It also was designed to accept adhesive patch sections, which would alter the state of the grid to accept a different type of item.

The setup and functionality of these grids was a bit of a headache. The 2x2 grid items fit in the middle of 4 hardpoints, 1x3 items, center on a hardpoint, but there has to be a point on either side (not against the edge). The 1x2 items fit in the middle of two hardpoints but it depends on which way is 'player up'.

I was manually placing rectangles as reference points and plugging in the values and indexes of every single size to a corresponding node. To be fair, I probably could have done a bit of math and saved myself a headache, but I was pretty rusty there too.

A good deal of my methods were excessively crude and hacked together in the worst possible way.

Emails, Quests, and Currency

I wanted the survivor city to have some influence over your choices, and to expand on the larger world in a way I felt was a relatively effective use of my time.

I thought I might give the player a quota of material resources to send back, this would be rewarded with tokens that could be exchanged for specialty resources which weren't available for the player to find. This would have been tied to the drones, but I had never reintegrated those into this version of the game, so I never got around to this.

Part of that issue was I hadn't figured out where the drones would go since the different derelicts would be unloaded from the game engine each time you moved to a new one. Saving and loaded ended up be a difficult issue that I didn't tackle until much later, at which point I had other issues on my mind.

Player Ship

With the player station gone, I now had to have a mode of transport between different derelicts. Based on the drone system I made an autopilot ship you could take between different procedurally generated stations. It had a door on the front that allowed it to dock with common door sizes, and I made sure there was at least one open lane (a sort of spawn exclusion zone) to reach that door when I generated a new station.

The ship went through several iterations throughout development. From the initial 'Command Module' in the earliest video (technically still a station module), to the earliest version, which still had the construction points for the blue, 3D printer sized 'addons', used in on the player station, and a pilot seat/computer screen that faced backwards for easy access to the door. The ship had multiple attach points along the inside for gear, lights, resources and batteries.

Pretty soon I removed the addons (no more construction tool), and changed out the old chair for a more integrated seat with more controls surfaces. I figured batteries would play a role in a number of tools and systems until a permanent power source could be found. So I added a charge port right on the front of the main console.

It also had a 3D printer installed above the pilot seat. I wanted to have a level of progression attached to the printer. I imagined as part of the intro, their ship would have a power surge and fry a row of chips. They would have to go find rare outposts constructed by other scavengers for the city. Which would each have a single chip. This would unlock blueprints.

We're not even at the new ship (or the new-new ship), yet! I am entirely sure I would have made yet another at some point.

Reminder: Always make the function before the form. If you have to make the form, make as little of it as you can. Once it works, you can wrap it in whatever you want.*

*to be fair to past me, I was hoping to generate some attention on social media to get people excited for this and maybe get the project funded. It's a real chicken and egg problem.

Procedural Generation

It was a mistake! Many have died on the hill of procgen, and many have seen them fall, and said: “I’ll be different. I can make it work.” Don’t. Infinite content is an amusing idea, but the outcome is random weirdness 50% of the time. Anything unique, rare, or special will paradoxically be found in every single room and not exist at all. It won’t work well, and you’ll spend at least 10x as long trying to make it work at all.

I think the generation system was probably the most bleak aspect of this. It was basically a brute force loop over all the possible nodes, trying to spawn and force random modules into available spaces between other modules. For a good deal of time I was fixing bugs that would cause it to completely fail to generate because it reached a dead end and quit.

Prototype Procgen 09/08/17

Beyond that, the thing I wasn’t thinking about is how insanely boring infinite sameyness is. I thought I could take modular components and stick them together in consistent ways and that would be enough, but no amount of maths can make a generated space as unique or interesting as a well-crafted level. Make it modular, sure, but when it comes down to it, someone should be deciding where every piece goes. Do not trust the random number generator. You will spend all your time working on it to try to make it look good enough, and it will fight you every step of the way.

In the end I was trying to make it generate at least one of a number of rooms that were necessary to gameplay, just so I could make the system work. The end result was every single station felt like the same one, and sometimes it still didn’t work.

Procedural Generation

I think the generation system was probably the most bleak aspect of this. It was basically a brute force loop over all the possible nodes, trying to spawn and force random modules into available spaces between other modules. For a good deal of time I was fixing bugs that would cause it to completely fail to generate because it reached a dead end and quit.

The resources within each compacted cube are equivalent to what goes in. I never got around to making different models for the cube. I liked the idea of various sizes and types based on the properties. I would have made a slice of each type, a quarter of the current size, and stacked them in a row.

Only crush a few small objects? Small cube. Crush a cube again, add more stuff with it? Bigger cube. I would have needed a maximum compact point though, because the current system can essentially accept infinite resources. Infinite mass cube.

I never brought back the resource shredder though, and the reason was that the printed compactor did not work great.

In the end the new compactor suffered from being difficult to set up, a high resource cost, and a massive physics object. Big physics objects in a small space caused issues.

Held Objects

I’d been noticing that my method of controlling objects was not working so well. I didn’t see this at first because I started with small objects, as I added content I started wanting to manipulate bigger things.

Initially the pickups were fully attached to the player and would just pop to you, or from you to a wall. It didn’t feel great.

At this point in development it was a physics object that would try to follow a set point on your right side. Because they each were different shapes I had to make offsets for each item. If you held down the placement button it would move that point forward and center, until you traced a compatible attachment point. Being able to shift the item this way allowed a bit more control.

When placing an object, it would quickly lerp into position and align with the destination’s rotation angle. It also had a confirmation state, and required you to release the mouse button before it was actually placed. At this point you could drag the crosshair away, and it would return to you, or onto another that was nearby and it would swap to that.

This was fine for directional movement, but I wasn’t using rotational physics (angular velocity), I was just updating the transform rotations to match the player.

The player character also didn’t use angular velocity, because it was nearly impossible to control that way. Once you started spinning you couldn’t stop. No fun. So setting the rotations worked better for that, and I had no issue at first because the player capsule was a sphere. But items weren’t. I noticed that if I spun around fast enough while holding a large object, it would quickly clip into walls.

Ejection force is basically the main cause of most ‘funny’ physics related bugs you will ever see in games. It is extremely aggressive and wildly unpredictable.

Once it’s in the wall it will apply high velocity impulses to work itself back out. It doesn’t really know where it’s supposed to be, other than ‘out’, so often enough, items would pop themselves outside of the walls into space. Can’t ship that game.

I don’t think I ever completely solved that issue, but I iterated on it a few times to the point where it was workable. Items had a maximum rotation speed so they couldn’t spin that fast anymore,

and I added a detection radius, so if it wanted to rotate, it first needed to make sure there was space to do so.

There was a bonus effect to this: Whenever it had just been picked up, or attached, it would hold that rotation for a while. This felt more intentional and controlled.

Items also had mass. Small mass objects would move quickly, as usual, but big ones would slow you down, make you feel sluggish. Large mass, high inertia. That helped solve a lot of those physics issues, but it also — it felt really cool to try to drag around a heavy space fridge.

Held Objects

This was roughly when I noticed that doors can punch items (and the player) clear through walls. They were moving objects, with collision volumes, so they collided with physics objects, but couldn’t be pushed back by them. The result was remarkably similar to crushing household items with a hydraulic press.

Eventually, I ended up designing the doors to run a thin boxtrace in their path as they moved, and if they encountered something, they would return to their previous state. Most of the time this worked, but ever so often the reverse path would catch something. It was a fixable problem, and low on my priorities.

I had given them a number of indicator lights for various situations. Unpowered, locked, broken, depressurized, and so forth. I never did get around to keys (What happens if you spawn the key behind the door? Could happen. It’s all random), but I did eventually get them to run on power.

I figured it was easy to get lost and turned around, so I had it swap an accent color and label when it generated a branch. It kinda helped.

For a time they had a panel on each door, and required 3 internal components to be installed and in working order (on each door of a door set), or the door didn’t move. I quickly ran into an issue where I would dock at a new station, and the door wouldn’t open. So I installed a release lever on the exterior (under a panel).

Eventually I got rid of the three components design, because it felt repetitive, and not a real barrier. It mainly meant that you would leave doors open behind you, and steal their working components to repair the ones in front. It wasn’t quite what I had in mind. They were small too, hard to pick up when you wanted to, but in front of you often enough that it was easy to accidentally pull them out if the panel was off (Same problem with the panel).

Update — Mar 21st, 2019

A lot of this is not new content, but I was trying to pitch this as a whole concept at this point, and that meant including as much as possible of the good things.

I’d been trying to make a relatively bug-free proof of concept. You can see the solar arrays and a number of new UIs. The computer terminals were more or less non-functionless until this point. Now, I had working programs.

Computer Terminals

The computers were one of the best features. I really liked them, though I will admit it was a scope issue, and needed more time baking. It hit at the core of what I wanted the game to be though. A fiddly little system of repurposing, and repairing found resources.

It was designed so that each terminal frame could spawn with a screen/interface and randomized hard drives containing randomized files. The files were mostly corrupted ‘filler’ files meant to take up space, but once in a while you could find a program that was useful. Though I had yet to add all of what I imagined.

It had:

• An operating system file, which would only work if uncorrupted, and the first file on the first drive (drive A).

• UI/controls for moving, deleting, duplicating files.

• settings that locked some files from certain actions.

• An interface for recovering corrupted files by comparing two corrupted files of the same type (merging the good data).

• A program for managing all powered objects connected to that network.

• various warning messages when something was installed incorrectly.

• a labeling tool (tape) to renaming the drives for visibility.

It was far from a complete feature. I hoped I could eventually add things like viruses, consumable hacking programs, a note taking program, an atmosphere manager, A door lock/security program, passwords in files, keys that could be uploaded to physical keycards, maybe solitaire.

I was using UI widgets, on a plane, set slapped on the side of the mesh. Last time I looked, this was an experimental feature of unreal, but it was the only way I could get the level of complexity I needed.

I was considering having all computerized objects run on a ‘drive’, that’d be plugged in somewhere, so for example, a trash compactor is found, but has a corrupted program. Pull out the drive, plug it into a terminal. If you have a copy of the uncorrupted file, you can use that to fix the bad file. This would mean that as you progress through the game, you start collecting files and drives to help you advance. But your limited storage forces you to decide which to keep and which to abandon.

This gets even more interesting if I had core systems, like in your ship, also hard-drive based. What happens if you take them out? What happens if you put them in something else? What if you don’t like what a program is doing in your ship? Can you change it? Can you delete it?

I often think this concept could have been its own game, though I’m fairly sure even just that would still be too large for one person.

Spline-based dynamic Conduits

You’ll note the previous station environments are gone.

I started fresh because this new conduit system was complicated, and needed to be fleshed out in isolation before I tried to bring back the previous modules.

Had some vague plan to bring the satellite form stations back eventually, but I had a lot of design changes in mind, and was finally learning not to do rework for every new feature.

This… was the feature that broke me. I would not recommend attempting real-time, spline-based mechanics unless you are absolutely sure you know how. When it doesn’t work, it does so in extremely interesting ways.

Initially conduits were just an item that could be used on wall areas of some modules. This would toggle on the visuals for conduit mesh on the wall, which I had manually author per module. Naturally I felt this did not work very well with the concept I was aiming for and decided to tackle a different method.

Ok, I think I need bullet points to properly explain what I was doing, and why it went wrong.

• It needed to procedurally generate conduits between powered objects, and a power source, which required pathing across multiple modules.
  

• ‘Pathing’ was a convoluted, multi-step process.
  

• Starting at the unpowered target, it walked up the parent tree until it reached the room (module) and moved sideways along the module connections, until it got from the module with the ‘powered object’, to the module with the ‘power source’.
  

• Because it didn’t just need to know which module to find next, but also which point on which wall to find, I had to make a second layer to this: conduit pathing.
  

• Conduit pathing had to be built on a network of points, and the best way I could figure out how was to add dozens of spheres to the blueprint of each module. The points were parented to each other in sections, but I couldn’t do that at branching points (So many branching points).
  

• So, they would perform a one-time trace for overlapping spheres, and save a reference to them. That was the node network.
  

• Thankfully I only did that one time, but it created a significant hitch.
  

• To get an unbroken line from a power generator to a powered object, it first searched through the modules until it found one with a power source, and then through the previously generated conduit node network to build a conduit path.
  

• If it found the desired next module it would make a major checkpoint, and keep going forward.
  

• If it found a branch point in the node network it made a minor checkpoint and tried one of the branches.

• If it found a dead end, it would walk back to the last checkpoint and try again. If all options at a given checkpoint were exhausted it would step back further, and try THAT checkpoint.
  

• This was done for every powered item.
  

• The first few would typically travel the entire way, however when a new path encountered a successful path, it would split that line into two and spawn a junction point for all three lines to link to.
  

• This all caused considerable delays in world generation.
  

• Because pathing was randomized, it was difficult to diagnose issues. I didn’t know about Seed randomization yet. So when I tried to fix a bug I just had to guess, and if I never saw the bug again, it was fixed.
  

• There is also player interaction with the system. For a long time the spline conduits were made up of a number of points that defined the various bends. A player could pick up either end of a conduit, and it would trail behind them from the last ‘point’ on the line.
  

• Later on I changed this to allow the player to ‘Pull’ on the line and drag it off the wall like a piece of cooked spaghetti.

This feature was extremely satisfying to see, but also extremely annoying to actually use. You didn’t have control over how fast it pulled, so it felt too slow, and too imprecise at the same time.

• The spline meshes were updated from start to end, however you could pick up either end, so the visuals did not organize correctly in the reverse order.

• My solution was to flip the order. Which ‘worked’, but revealed that the curves it generated were not identical in both directions.

• The conduit also kept track of how far each point was from each other, so it could define a maximum length. If that length was reached, the line wouldn’t extend further.

• This feature more or less worked except for a few bugs which managed to extend the maximum length.

• To avoid issues like the conduits passing through walls, I made it trace from the previous placed point, to the end, that you held. if something blocked that trace line it couldn’t go through it and stopped.

• This worked pretty good for a while, but caused considerable issues if confronted with a slight lip or edge.

• To combat this I tried adding a ‘temporary point’ to add that bend. It would attempt to recover being pulled through an edge by tracing along the failure point until it was unblocked, and then creating an extra, ‘temporary’ point that was not tied down, and would get removed, if the trace ever failed to find the edge.

• I quickly found that while one bend helped, it quickly needed a second and third bend.

• It was entirely possible to drag the conduit around a cylinder, or through a maze and would require potentially hundreds of temp points.

• Additionally, sometimes the bend point missed a trace and caused it to pass through a wall.

• Because the ‘pull’ system needed to keep you from dragging lines through walls, once it clipped into something, it was permanently stuck there.

I think I gave up here.

Throughout the lifetime of this feature there were considerable problems in how the links connected and how they visually displayed. Most of the things mentioned here had at least one massive headache at one point or another.

I think I was afraid to throw out bad work and start over, because I figured I’d just end up with the same thing. Probably true. I didn’t have the experience to know a better way.

I know it can be done. I’ve seen some fantastic rope/cord mechanics in games, and though I don’t think it could be remotely easy, it is definitely possible, and clearly fun. I probably wouldn’t attempt it again though.

Atmosphere Visualization — Oct 5th, 2019

This was an experiment using post-processing and custom stencils to visualize atmospheric density and the temperature in the module. This video doesn’t show much of that, because I ultimately scrapped the concept, and didn’t bother to record it!

In its most complete version, I had air in the rooms tinted orange (hot) or blue (cold) that was supposed to be layered against each other and the correct color would be seen through a doorway. As you approached the doorway it would fade into the other, and at some point, swap. I had a really cool prototype for a camera vector/position based wipe effect that lined up with the doorway so you couldn’t see the swap.

The issue I was running into was that I had to index doorways by closest, update them constantly, and feed that information into a limited list of layers in the post-process material. It would inevitably be prone to running out of list space, and it couldn’t determine which doors were actually needed.

The worst part was I couldn’t figure out how to get the doorways seen through a doorway to be the correct color. You can see my attempt at it in the video. Sometimes there’s a second layer color on some of the doorways, but it was limited. I had it setup to set the value of a material collection color tied to an index, so each color had to be a specific line in the post process material. I also couldn’t figure out how to get more than two layers, and I was seeing third, forth, and fifth layers as potentially necessary. This exponentially increased the resource draw on this system to an unusable degree.

Initially I thought it was just an issue of adding indexes, but I found that custom stencils will layer over each other and add their values together (index 1 and 2 is now 3. index 3 and 5 is now 8.) It was a nightmare to debug.

Besides which, the way this post-process material used depth as a factor in the start and end of a doorway. Think of it as thick fog. So a second level door had to be behind the first, and lerp in that order.

Considering that this would only really be used when doors were shut and immediately after opening to equalize pressure, it was both something that couldn’t be fudged, and wasn’t really worth the effort. Not pursuing that concept was one of my saner moments.

Power Drills and Bolted Panels