Attacking basics

[nfagerlund]

Using canned tutorial assets for now because I don't want to adopt more blockers!!

• [ ] Make new entity type for enemies
  • [ ] States... idle, patrol, aggro, attack, hurt+knockback, dying...?
  • [x] re-use charanimation and various physical properties
    • [x] Need to handle sprites without four directions! oops!!
  • [ ] spawn from placement in ldtk level
  • [ ] has hit points
  • [ ] has ability to die
• [ ] A given enemy can be hit by a given attack once.
• [ ] Fixed amt of damage for whole attack duration.
• [ ] Attack can be interrupted if u get Hit
• [ ] ...?

[nfagerlund]

Ok, about that sprite flipping thing.........

• [x] loaded animations need to know their directionality.
• [x] Need to use textureatlas's flipx / flipy... when tho

ohhhh oh no. anchors and walkboxes. what if they're not perfectly symmetric. ..... well, maybe let's just try it and see?

Looks like flippedness needs to live on the state struct...

[nfagerlund]

Yeah okay,

• [x] Flip anchors and collider boxes when mirroring :|
  • [x] enable debug display for origin and hitbox etc.
• [x] Fix FrameTimeOverride issue when not facing East (!!)
• [x] Biasing toward East is actually not desired when deriving variant+flip from motion.facing; biasing toward whatever you were last is more correct. That is: (-> w) -> (-> n) should keep facing west, not flip you east.
• [x] Gotta sort out sprite Z-sorting soon!!

[nfagerlund]

About that Z-sorting, I think it goes something like,

• everything happens in extract_and_flatten_space_system
• Add an Extract param to get the camera's OrthographicProjection.rect and its GlobalTransform, use those to determine the range of Y values that are actually being displayed.
  • I'm not sure if there's any sprite culling going on, and what would happen to sprites way outside that range if any happen to be extracted already? should I care? they're not visible, by definition.
• ...
• What about stuff that doesn't have TopDownMatter component, like wall tiles? yagni? or sort it out later?

[nfagerlund]

Wow, that actually worked

[nfagerlund]

AND THEN I DECIDED TO REWRITE MY STATE MACHINE AGAIN

With two entities on the field, the flaws in my approach are finally becoming apparent. But, a hybrid seems promising.

• [x] Make some lil behavioral components (SparseSet)
• [x] Refactor state changes system to add and remove behaviors as part of state setup.
• [x] Add an apply_deferred after state changes system. 🌟 (why I couldn't do this approach before 0.10)
• [x] Start deleting branches in plan_move and replacing them with behavioral systems, one by one.
• [x] Replace the push_transition() in queue_bonk system with an emitted Rebound event, and consume it in state changes system on the next frame.

[nfagerlund]

Hey, now that I've rewritten the state machine, actually,

• [x] Make sounds when whacking wall and when landing on ground

[nfagerlund]

Still some stuff to sort out in getting the enemy plausibly interacting:

• [x] Chase behavior
• [ ] Attack!! when close enough.

Then:

• [ ] Attacks cause knockback and interruption.
• [ ] Entities have HP, attacks reduce HP
• [x] Entities have hurtboxes -- I don't think I did that yet?? Hmm.