Mohammed

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.

Finished the app! Here we are sitting on a server it made. Since the last devlog, we also added a visual UI. Nothing fancy, but I personally think it looks kinda like other wizard installer type apps. We tested it on both Windows and Ubuntu.

Made the logo. I think it's okay overall. I tried using a fellow SOM participant's Adobe WakaTime but it didn't work for me.

Organized the entire script and added string to int version parsing (i.e., turning 1.16.2 into a list with contents 1, 16, 2). Older versions of Minecraft do not require agreeing to a EULA, and I needed to parse the string to check the version.
The app will also now access and tell you your local IP, not just your public IP. Big oversight from me, because you need that to join your own server. User input is now complete, and I ironed out some more edge cases, like allocating too little memory or including spaces in the version number.
I wish JetBrains live share tracked my time properly... or that GitHub worked well when multiple people are working on one file at the same time. Or some third solution. Can someone make that for SOM?

Working on Linux and Mac support. I converted my old PC into an Ubuntu Minecraft Java server and have used it on and off for the last several years, which is what got us the idea for this app. It only makes sense that we let it run on Linux.

More specifically, we are making the app:
1. create both a run.bat and run.sh file
2. detect your system's OS to know which one to run (.bat or .sh)

User interface is complete besides a couple lines I want to change and one small step in the process missing. Didn't have many issues with edge cases. The main goal of this app is for it to be super easy to use (get a server up and running in <1 minute with no prior experience) and that seems to be coming along nicely.

Working on setting up ram allocation and autogenerating a bat file with java launch flags, courtesy of https://flags.sh/ . Also... you now get softlocked if you don't accept the Minecraft EULA. In other words, you are bullied into accepting it.

Currently working on user input. My teammate worked on networking and getting the server files from the internet. I'm making sure to provide useful but not overbearing instructions and verifying all user input before accepting it. We're splitting things up by our skillset.

My reported time will always be much shorter than it really is because I'm working in his IntelliJ liveshare (git isn't being nice to us)

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.