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

Watched some videos on level design and started reading jesse schels the art of game design

Today's playtest revealed. Firs that a player remains entretained with the loop as is with the new enemies and animation tweaks for a whopping 20 minutes and two playthroughs so arena survival feels interesting .
Started implementing a killbox under the world . And the feedbacks i got is that the game needs more sfxs

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!

A security guard that discovers he has the ability to stop time tries to put it into good use by beating up his enemies and dodging their bullets and things they throw . The only downside is that he can only do it for 3 seconds tops so he has to react extremely quickly.the game would be a beat em up in which the player can jump and crouch to dodge things the fame could be made for cellphones. The game will also have some mechanic in which the player will have to swipe at the right time so he can beat up bosses. The game would end after the player reaches level 16. And will be a 2d side scroller. The game will also have an upgrade system every time a level is cleared until he reaches lvl 8. The level up system will let him choose whether to increase his hitpoints by one, more strength or more time when he freezes time. The game would heavily implement the use of the time stop so that the player has to remember where the objects and attacks are coming from picture from the movie unbreakable.

P.s. watch a cool movie.

You're a fisherman who enjoys fighting, all sorts of people. Must attempt to fish while fist fighting his enemies in an ever changing map. The world would work similar to those in which the arena is circular and at the edges there will be water, The player must lower the enemies health enough to be able to throw him into the water and use it as bait to catch a gigantic mega shark. The game could have many different characters at least 8. And attacks that will use the fishing rods in different ways, some characters could have laser fishing rods and alln sort of crazy things to make them unique. Over all the main mechanic of the game would be the fighting and the fishing would happen automatically after the fight. It would be there as a way to present the player with the score system of how he did in the match, the better his performance, the better the fish will be. Could be made for pc and console but only playable comfortably with a controller .:/ Side note the whole map is constantly shaking and taking different shapes changing the way the player's can interact with the stage.

https://en.wikipedia.org/wiki/Fishing_rod

A simple puzzle game about a man that unlocks rooms by setting objects in motion. The objects make sound and the player must find a way to a few of them and make them Open passageway. The passageways are opened when some objects are getting the desired frequency. The Game would use a simplified version of the effect demonstrated in less space. The game will also give the ability to toggle and listen each one separately or de-activate it at will. The Game will have moving objects the player will have to evade so that he can reach the end. Some objects in the game will be invisible but will also have the effect being demonstrated by a low volume horn becoming louder and such. Like this adding a little more into the game. The game would be in a Top-down, view. The game could have a mod for people with trouble listening and will be given a physical representation of what is happening shown in changes of frequency.

http://giphy.com/gifs/11YknPj08BIsh2

In a futuristic world magic was re-discovered, extremist groups attempt to destroy it and you must escape the city that has been overrun with them. They are exterminating all magic users and so on. All till now had been dying without much of a fight, but you're a brilliant scientist and will not be brought to your knees by no one. Main char Codename: Circe, The first witch.

The game would start by displaying the story and all of those to give players an understanding of the story. It would be a Third person 3d adventure Open world. The game's starting ability will be the ability to push, set fire, pull objects towards her and morph people into other things. Which would be the reason why she would be known as Circe. The player will have a spell progression system that will be about getting abilities during the story and other side quests, Magic will be replenishable over time but the game will also have guns reason to why pulling is important. It could be made for consoles and Pc.

/*For future Reference

Honestly i'd love making an amazing in depth story of this /:. The game wouldn't have a multiplayer.

I wouldn't even mind if the mechanics are to be changed*/

http://mythology.wikia.com/wiki/Circe