Hour Zero

I know my last devlog was on automatic doors, but I decided to spend some more time on them. Game dev is when you try to make an automatic door, and it takes 10+ hours.

Visually, it's about the same. The main difference is now any type of object can trigger the door, not just the player. To facilitate this, the sensor now keeps track of all objects inside it, which requires occasional validation. I also fixed about a billion edge cases that were in the previous version and made sure everything is neat and organized.
I still have one more change I'd like to make to doors in general (to make them more dynamic) but it involves lerping, and lerps are so annoying and boring to do, so I stopped here.

Automatic doors! Did some small map changes as well (not shown).

Was originally considering building the sensor functionality into my CollisionListener script, but it ended up feeling awkward to configure, so I just created a new single-purpose component. Although, I do kind of like the idea of just having a single component that adds a bunch of functionality, whether specific or general, to colliders.

Begun the item spawning system. Each item spawner is a part of a spawn group (ex: each shelf in a store is a spawn group, composed of many spawn points, like in the picture) and each spawn group can configure which items it can spawn and what chance each spawner has to spawn something. I spent most of my time working on developer utilities to make it easy to set up, modify, and view spawn groups. All that's left is to add restocking, which is a function whose implementation difficulty is based solely on figuring out how to keep it balanced.

A lot has changed since the last devlog. Most visually, I finished the first section of the map (that's models, textures, placement, lighting). There are many placeholders and missing textures in the background of the image, as well as artifacts from improper(?) baking.
Other changes (some are untestable in the ship, because the main map is inaccessible):
- Openables now can auto-close after a fixed time
- Randomized item spawning on start
- Updated collision detection
- Refactored SFX system to allow the library to auto-organize itself. I'm still figuring out how to sort the enum itself
- Added an interaction indicator for all interactables

I learnt a lot about blender during this, but learnt the most about baking lights in Unity. It's the worst thing ever.

I rewrote my pooling system to be more scalable and optimized, especially when the pool is under load and managing many objects at once. I also made it spawn stuff when the game starts, not just during the game, which is much more performant and also standard practice. These are mostly under-the-hood futureproofing things, and all I have to show for it is the weirdest line of code I have ever written.

Made an audio playing system that uses a centralized library of sounds that any script can play. I used a system I made previously in order to pool AudioSources, because each AudioSource can only play one sound, but creating and destroying them over and over again is painful. I'm happy with the sound system's scalability, flexibility, and ease of use. This is the kind of dirty under-the-hood work that goes unnoticed by the player, but it's necessary, and they'd be sad if it was broken. Not that it wasn't fun to design this system, and I learned a lot from the process too.

Created destructible props that break into predetermined pieces when struck, either in physics collisions or when hit by the player. The mechanic is highly configurable, allowing the following to be customized:
- The durability of the prop
- The sensitivity of the prop to impact damage based on impact speed along the horizontal and vertical axes independently (impacts below the set speed deal no damage)
- The explosiveness of the prop's destruction (whether it gently falls apart or forces/torques are applied to the broken pieces to help it break apart in a more visually fun way)
- The percentage of velocity inherited when the prop breaks, although I don't think conservation of momentum applies by default in my implementation

If I were to expand this in the future, I'd apply the explosion force relative to the velocity of the object at the instant of its destruction (faster collision = more explosive). I would also consider giving props multiple broken versions instead of them breaking the same way every time, as they do now. Other than that, I think it's pretty good! The only real issue is sometimes, when I throw things against walls, the pieces clip through the wall. But this is a rare occurrence, and I have no clue how to fix it anyways. My implementation also does not allow for destructible props made up of other destructible props; small bummer, not sure if it's worth the effort to fix.

Also, for those concerned, my time didn't track properly: this took me 3-4 hours.