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.
Printable Compactor
The printable compactor was built on the original compactor. It was functionally the same, put stuff in, it made a cube of resources. I need it to be printable because it was going to be the first step in the resource collection process.
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.
