In business programming, this is where dependency injection / service location comes into the picture.
Gameplay ability systems generally give you a service location mechanism to help with this, for finding "abilities". Which is why there's such a pressure in those contexts to Ability-ify All The Things. Which I also don't super like.
It moves you from coding against the problem to mapping your problem into The Model.
Godot (and a lot of Godot developers' advice) really seem to want you to rely on the design-gui-driven composition. But this is punishes you for small components, because of all the "hookup" you need to do. E.g., if I have a velocity component, the number of other components that need a handle on that is large, and setting those all in the UI is beyond tedious. Especially when moving things around causes the settings to get lost.
I've been thrashing a lot lately with the architecture for my game.
Started writing in GDScript, but didn't really like how the dynamic/gradual typing was encouraging a lack of discipline in my code. So I've been moving to C#. That's part of the churn.
Another part is I'm trying to figure out how to move code out of my root scene scripts for enemies, npcs, and players. They are too big and complicated. I'm struggling with finding the right patterns for that.
