Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Each Attack ANGLE To Have Different Properties #21

Open
TheYellowArchitect opened this issue Aug 11, 2022 · 0 comments
Open

Each Attack ANGLE To Have Different Properties #21

TheYellowArchitect opened this issue Aug 11, 2022 · 0 comments
Labels
enemy ai Anything related to the logic and behaviour of monsters input Anything related to controller or keyboard input low priority Not important or to be focused new feature New feature or request player movement Anything related to the core movement of the player (e.g. velocity or acceleration or animationcanc)

Comments

@TheYellowArchitect
Copy link
Owner

TheYellowArchitect commented Aug 11, 2022

Currently, whether you attack diagonally down or diagonally up or plain horizontal, it is irrelevant - except the hitbox of course.
spearhitboxes
The above monster requiring a diagonal down attack to be hit in equal elevation, is a good example of hitbox importance.

Ideally, dash attacks would have more horizontal knockback depending on the velocity/influenceX
As for angles?

Diagonal down should "dig" an enemy, hence, more knockbackY, less knockbackX.
Diagonal up should either have more knockbackX than plain horizontal attack (1.0,0.0)
Or simply push enemies diagonally upwards.

With the above, each attack input would matter. The only difference right now is the hitbox, which is dead obvious to attack an enemy.

CODING
I would have to refactor TakeDamage() on enemies, as they make absolutely no use of knockbackPowerX and knockbackPowerY...
Hence, it fits with the general planned enemy refactoring, whose main goals are:

  • Each attack to have seperated AI detect hitbox, and damage hitbox
  • Splitting flying and ground units
  • Decouple state machine from physics.velocity
  • Remove the IDamageable inheritance (interfaces in Unity were a mistake, as you cannot override them without spagghetti)
  • Fix the sidewalled bug

Changing the movement, health/damage and monster attacks? Its easier to remake enemies, than refactor 70% of the code.
So, as you understand, simply "attackInput changes enemy push" would take a full month or so - most of the time spent on debugging.
This is a huge undertaking for such little results. Huge backend change, for almost no front-end difference, hence it is delayed forever.

P.S. Related to this issue is how spellword "Push" works, and could be expanded upon.

@TheYellowArchitect TheYellowArchitect added new feature New feature or request enemy ai Anything related to the logic and behaviour of monsters player movement Anything related to the core movement of the player (e.g. velocity or acceleration or animationcanc) low priority Not important or to be focused input Anything related to controller or keyboard input labels Aug 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enemy ai Anything related to the logic and behaviour of monsters input Anything related to controller or keyboard input low priority Not important or to be focused new feature New feature or request player movement Anything related to the core movement of the player (e.g. velocity or acceleration or animationcanc)
Projects
None yet
Development

No branches or pull requests

1 participant