A prototype project for third person combat. Contains basics for player movement, camera, animations, combat, enemy AI, user interface, sound effects, and background music.
this codebase is just spaghetti in an unconvincing composition mask
What's bad?
why does a crosshair need access to a backstab and dizzy component? IT SHOULD JUST BE A CROSSHAIR with a toggle specifying if it should be shown or not!
when making the spellcaster enemy, why is the enemy script so tightly coupled that I need an attack component? And so many other dependencies.
Importing animation libraries requires certain animations scripts. For example, importing combat_animations_1 requires HitAndDeathAnimations, DizzyVictimAnimations, DizzyFinisherAnimations, BlockAnimations, ParryAnimations, and probs more. What if i only need the hit, death, and dizzy victim animations? Not sure how to deal with this hmmm.
TODO
decouple crosshair
clean up enemy script
create component managers?
actually utilise composition
actually utilise the observer pattern, signals
man i have no idea what im doing. I just spent hours removing everything from the enemy script, then spent hours putting it back bruh. Also the swordsman's movement is broken now. like how does that even happen.
OKAY here is my new plan. turns out a base enemy requires a lot of components to get started. But i realised that attack, block, parry, spell components are the ones that need to be able to swapped in or out. So i just need to make it so that doing this swapping is done nicely in a modular way. The base enemy shouldn't have declared references to these components.
I might just be going crazy now but handling weapon impact in the enemies should be more modular right? If those components shouldn't be referenced, ill need new handlers for when an enemy gets hit, blocks the player or parries the player. So essentially make the _on_hitbox_weapon_hit method modular. So nodes for backstab, dizzy finisher, hit, block, parry? Maybe doing it this way can allow for new/other types of behaviour when handling an incoming weapon.
I also feel the same for the character animations script. There really shouldn't be much exported variables. I also think setting and getting parameters in the animation tree should be done similar to how beehave handles the blackboard. Basically use a custom getter and setter for flexibility.
Also probably should be done for function calls in the animation tracks. Instead of accessing the animations script directly, just send a message to the parent animations script which will handle all the dispatching. OH MY GOD THIS IS THE MEDIATOR PATTERN. Edit: this is actually the command pattern. Bro all these design patterns are like the same thing lmao. no but i get it. i think...
[x] decouple crosshair
[x] dont reference ability components
[x] weapon impact handlers
[x] clean up and decouple character animations
[x] custom setter and getter for animation tree
[x] make character animations the mediator handle commands from animation tracks for the scripts
this codebase is just spaghetti in an unconvincing composition mask
What's bad?
TODO
decouple crosshairclean up enemy scriptcreate component managers?actually utilise compositionactually utilise the observer pattern, signalsman i have no idea what im doing. I just spent hours removing everything from the enemy script, then spent hours putting it back bruh. Also the swordsman's movement is broken now. like how does that even happen.
OKAY here is my new plan. turns out a base enemy requires a lot of components to get started. But i realised that attack, block, parry, spell components are the ones that need to be able to swapped in or out. So i just need to make it so that doing this swapping is done nicely in a modular way. The base enemy shouldn't have declared references to these components.
I might just be going crazy now but handling weapon impact in the enemies should be more modular right? If those components shouldn't be referenced, ill need new handlers for when an enemy gets hit, blocks the player or parries the player. So essentially make the _on_hitbox_weapon_hit method modular. So nodes for backstab, dizzy finisher, hit, block, parry? Maybe doing it this way can allow for new/other types of behaviour when handling an incoming weapon.
I also feel the same for the character animations script. There really shouldn't be much exported variables. I also think setting and getting parameters in the animation tree should be done similar to how beehave handles the blackboard. Basically use a custom getter and setter for flexibility.
Also probably should be done for function calls in the animation tracks. Instead of accessing the animations script directly, just send a message to the parent animations script which will handle all the dispatching. OH MY GOD THIS IS THE MEDIATOR PATTERN. Edit: this is actually the command pattern. Bro all these design patterns are like the same thing lmao. no but i get it. i think...
the mediatorhandle commands from animation tracks for the scripts