Attack Hitbox update #53
Comments
This was referenced Jul 6, 2022
Closed
zicklag
added
audience:user
scope:medium
Merged
2 tasks
bors bot
added a commit
that referenced
this issue
Jul 25, 2022
134: Attack hitbox and startup frame refactor r=odecay a=odecay Closes both #53 #54 Collisions have been refactored to take place in one system only, the filtering we need is already done via `BodyLayers`. There are now two main types of attacks. **1. Melee attacks:** these are spawned as a child of the fighter who starts them, with an `AttackFrames` component which consists of the startup active and recovery frames of the attack. These correspond to the frame window in which a hitbox is spawned, which will collide with other fighters as defined by its collision layers. Melee attacks are not despawned when they collide with something, instead they stay active for the duration of their Active Frames. There are systems which activate the hitbox at the start of the Active Frames and despawn the attack at the end of the Active Frames/Start of the Recovery Frames. These attacks also lock the fighter into the `Attacking` state for the duration of their attack animation. **2. Projectile attacks:** these are spawned un-parented, and with a `ProjectileLifetime` component. They are despawned on collision, or upon reaching the end of their lifetime. Currently only the player has these, and they do not lock the player into an attack animation, although I think ultimately both of these things will change, players and enemies will both want projectile attacks and they will be tied to either character specific special attacks or Ranged Weapon animations. ### Things to consider for this PR: - Currently there may be issues with the exactness of frame timing due to commands being used to activate hitboxes and the need for commands to be separated into stages to apply. This should probably be addressed after #99, but I am confident that these frame based definitions for attacks are the correct design. I tried the approach of changing adding the hitbox component at attack spawn time with a 0 sized shape, and mutating to the correct shape on Active frame start to avoid command application, but this did not behave as expected. - I may think further about the startup, active, and recovery attributes of the `AttackFrames` component. I want to stick with these names but I see the way they are referenced currently could be confusing, currently they are the index relative to the animation on which the startup, active, and recovery portions of the attack **_end_**. I also considered representing them as ranges, but it seemed like an index was simpler. - I have refactored some of the work done in #123 and that lead to some renames from what was added by `@64kramsystem.` I think I will take another pass tomorrow to check but I am quite confident that the conceptual model of Melee and Projectile attacks is cleaner for our purposes here. (Some of what that rework took into account was due to the way flop worked before but it is now unified with other Melee attacks) - I have left some unnecessary comments which I will come back and clean up before merge. ### Further improvements - [ ] Define attack startup frames, hitbox size and placement via transform relative to parent in fighter yaml files. - [ ] Write up further design goals and spec for attacks. (I intend to do both of these) 142: Updates to Github workflows, primarly remove cache building and leave build to release r=zicklag a=64kramsystem - Remove build caches workflow - Minor updates to workflows, mostly cosmetic - Update checkout action version - Remove apt-get --allow-unauthenticated option, which is not relevant in this context - Change apt-get mode from very quiet to quiet, since some messages may be useful (e.g. package already installed) - Made the two dependency installation jobs the same - Make tags pattern consistent across cd and web-dem- - Remove project building from CI (left in CD) Closes #138. Co-authored-by: otis <electricbuck@gmail.com> Co-authored-by: Saverio Miroddi <saverio.pub2@gmail.com> Co-authored-by: Zicklag <zicklag@katharostech.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Collision should be changed so that attacks have hitboxes and fighters have hurtboxes. This will allow us to decide what to do when attacks collide with one another.
Area in red is the active hitbox of the attack, Area in green is the hurtbox of the player during the attack. If the attacks hitbox connects with a players hurtbox the enemy will take damage, if the attack overlaps with an enemies active hitbox, attacks could clash.
The text was updated successfully, but these errors were encountered: