Audio System Migration & Architecture Overhaul

• Migrated the entire audio system to be compatible with my friend's project
• Implemented Addressables integration for optimized sound loading and memory management
• Redesigned the architecture to be more data-driven and maintainable
• Ditched enum-based approach in favor of a flexible, scalable system

Bug Fixes & Code Quality

• Fixed a null reference exception that was previously resolved in the 🐶 doggo game and imported the fix into this project
• Maintained singleton pattern integrity with static readonly list implementation

Performance Optimizations

• Optimized texture memory usage
• Implemented interrupt protection system with 0.3seconds interruptProtectionTime parameter to prevent audio excesive overlap

Technical Improvements

• Enhanced system maintainability through better separation of concerns
• Improved asset management workflow with Addressables
• Strengthened error handling and defensive programming practices

Another productive day of refactoring and optimization! The new audio architecture should make future development easier, and maintainable systems i can reuse among different projects . 🎵

a match3 game!

can't really say much about it unfortunately.

learning how to use And leverage the excelent Feel Asset. 🤔
it looks like for some of its features i have rebuilt them without knowing i could have leveraged them...

Quick refactor now that it works well for the player depending on the damage moved it to the base class for actors

short breakdown

• Moved death sounds up to ActorBase
• Moved hurt sound system into DamageableActorBase
• Now ANY actor gets both systems automatically
• Added skeleton/bone sounds for future enemies

other stuff:

• Installed new audacity version
• learned how to use the interface properly
• learned a bit about effects and now to normalize them and apply effects on them without breakin' em

Even added a specific sound for the death of the dog but im not really satisfied with that. tomorrow probably going to work on the other feedbacks and actual gameplay stuff - a single day on sounds was enough for this month, otherwise might work on a the side project i got a match3 game I've been making w/ a friend 🔧

The time reality:
Finding dog-specific sounds... That's days of work, not hours. also I find it not hard to stay on this specific type of task for some reason they just don't flow for me, I'd almost even say they kinda break momentum but since they were part of the feedback i got on it rather than delay it further 🤔

Built complete contextual hurt sound system with weighted randomization

• [X] Complete HurtSoundDatabaseSO system with weighted random selection
• [X] Refactor DamageInfo to thread context through all actors
• [X] organized files and namespaces
• [X] protagonist hurt sound integrated
• [ ] Need more sound effects for more variance to make it less repetitive its not enough to just pitch them differntly tho it works for now.

Went full on the hurt sound system today!

What started as "just add a dog hurt sound" turned into architecting a complete audio feedback infrastructure. Dependencies man. 🫠

1. Started with basic hurt sound module concept
2. Added doggo hurt sound for testing
3. Built the weighted database system
4. Integrated everything through the damage pipeline
5. Cleaned up architecture and file organization

• Context-based selection ("light" vs "heavy" damage sounds)
• Extensible to any actor type without code changes

Planning feature for pooling on actors and corpse removal from the enemies. Just thought up stuff and made some small modifications and removed unused code and todo comments no longer relevant. Game development is a marathon not a race, it is important to have time to rest to continue .

Some bug fixing, refactoring, and some rest and healing for today!

Last night I had a migraine and it kinda messed with my sleep schedule and cascaded into lower productivity today.

Got some proper rest and when I finally got to work I did actually manage to get some proper progress done for the day!

Preamble to today's task ✅!

The previous version of the game had walls and enclosed rooms and as such it was impossible for a projectile to never return to the pool or so i thought.

As it turns out

When I reload the scene any projectile from player or enemies still in the world would become untethered to the global pooling system of projectiles which is a big nono. I was creating memory leaks!

What got fixed today:

• Projectile memory leak squashed - projectiles now properly return to pools when scenes reload instead of becoming ghost references
• Added Lifetime.cs component - automatic cleanup system for projectiles with configurable duration (10s default)
• Fixed pool initialization order - moved ProjectilePoolsManager to Start() so dependencies actually work
• Enhanced weapon system while I was in there - better frame timing, charged shot handling, visual feedback improvements
• Cleaned up audio system lifecycle and added new ricochet hit sounds

The reality of the work:

Started as what I thought was a simple 3-effort bug fix but ended up touching like 6 different interconnected systems. Classic case of "oh while I'm here let me also fix this other thing" 🤔

About 4-5 hours total (curse you tension headache), but totally worth it for proper memory management. No more projectile ghosts floating around when I reload scenes!

Nearly ready for more playtesting without worrying about mysterious null refs 👻!

took a bit but it worked out

had a slow day today but managed to get the healthbars properly updating when an actor takes damage, and so that the healthbars are only present if an actor takes damage or is healed and the healthbars return to their pool the moment the actor dies!

💪

• Rebalanced all 4 actors types
  • Health to 3 hits and 6 for the big guy
  • Incremented damage of projectiles to make them more threatening
  • Lowered giant damage output considerably
• Lowered I-frame after getting hurt to .75 for the player
• cleaned up some unused methods from the child class of enemy actor base
• Started with enemy health bars
  • found some trouble along the way mainly with how exaclty to keep the active actors in a single collection while keeping things as decoupled as possible
  • healthbar created and made simple stylization prototype
  • healthbar can now be filled and match a specific actor’s health
  • healthbar is now capable of being placed at a specific position screen pos
  • the is now set to a anchor on world space not necessarily dependent of the actor
  • Pending figuring out a way to only make them appear when an actor has taken damage
• Realized that i must pool my actors
• Must make the corpses disappear after a while
• need sound effects when actors get hit BUT independent of the hitInfo SFX pipeline to keep things decoupled and easy to iterate without breaking working systems. this applies for the protagonist and things that could be damaged later. consider abstracting damageable interface such that it can also call these generic systems
• Created more prefabs so that i can quickly create other testable scenes, and actual playable levels without ahving to duplicate the scene entirely.
  • perhaps it would be nice if i could make some object that spawns whatever is needed for specific types of gameplay in the future 🤔

Pretty productive albeit only two major featuresets!

organized some of the feedback i got yesterday into notes today getting ready for this coming week sprint ! Looking forward to iterating as fast as possible😎

Things i noticed turns out computers without a dedicated GPU struggle with the game ONLY if. The game is Fullscreen but particularly if the game has got various post processing effects. The enemies damage is too low, playing and aiming with a track pad appears to be quite difficult but people remain engag d in the game for an avg of 15 minutes and despite them dying and failing they still want to keep on trying .yet another good sign ! I think i can bring back the proc gen now but actually make it work with room arena layouts rather than room dungeon layouts as much 🧐 ... Gotta make some more changes and playtest to get an idea!. Looks like the settings menu will need some options now to toggle the post global post processing or figure out a way to get it to work on low end devices. I even got the recommendation to make it into a mobile game which makes me wonder ... Why not? 👀

Productive day but not productive enough!

Stuff that gone done today!

• Resolve more animation issues
• Created a new a scriptable object to keep all the alive actors and remove them when Relevant
• Modified the player actor so that it adds itself to that list at the correct time
• Created and used specific event channels for each type of actor, tried using a parent class for both the actors with events but realized quickly that doing that was overgeneralizing the logic
• Created and then split the kill box that managed actors into the said list and was capable of checking only those actors with respect to a Y bound instead of using trigger entry or a bound check its fine for this case since we're on a plane if i need more specific things i can worry about that later 🤔
• Split the kill box script into two parts for SRP compliance
  • Bounds-KillBox
  • AliveActorsManager
• Drew up some plans to create authorable logic for these lists via decoupling using the enemyKilledEvents I could create some sort of dynamic authorable rules that checks for what actor died compare it against arbitrary rule sets that change and that way i could create a simple quest system!
• Reorganized a bunch of files stuff from the entire project to keep things as tidy as possible
• Removed old prototype of old iteration stuff from the Giant actor
  • Removed grass spawner for old iteration
  • disconnected events that were no longer being used
  • commented out most stuff to improve even a ms of processing when reloading domain

created test bed for resolving animation issues on all the characters, tweaked and balanced health damage, hitboxes speed. quickly and brainstormed next steps!

It no longer uses event architecture to follow but rather polls from a shared scriptableObject that contains a neat little no memory struct for the hit pos & the direction relative to the palyer ... could be used to have multiplayer like in the throne that happens to be nuclear ⚛️

related task !

Spent part of the day organizing tasks for the morning and visited my grandparents had a great time in family and even managed to show them the game!

only managed to do one task related to my game, however did manage to improve my notetaking, adopted iso format for daily note taking , modified all obsidian plugins to work with that and even started using timewarrior to track tasks as well and plan out some rust cli app to automate tracking things as a redundancy within timewarrior

Got some work done in getting the rooms to generate their own nav mesh after the proc gen runs!

Green represents the bound of said space to be sectioned selectively

fidxed a long existing bug with the sword tween in an unexpected way honestly lol
just removed a callback and commented out a line and i was surprised to see it be fixed

been experimenting with layered feedback!

Got a few days done today!

• fixed a bug with the color of the color tint fade!
• Maintained Decoupled Architecture
• Tested and Verified Implementation
• it feels nice to me as i play it!