verygoodopensource / flame_behaviors Goto Github PK

Description

Currently the workflows use an outdated Flutter version, we should bump them to the latest stable.

Description

Right now behaviors can't be composed on top of non-positioned components, but there is no reason that an entity has to be a positioned component.

We should refactor the internal logic to allow for behaviors to be composed onto anything that is a form of entity (and not just a position component).

Description

As noted in VeryGoodOpenSource/flame_steering_behaviors#12 we closed down the flame_steering_behaviors repo in favor of moving that over to this repo. This should allow for one cohesive repo with the needed functionallity.

Requirements

• The functionality from flame_steering_behaviors is fulled moved over to flame_behaviors

• create a new flame_behavior package via very_good_cli
• move implementation into this repo

Description

The documentation is limited in features, this can be expanded upon.

Description

The input behaviors, like DraggableBehavior and TappableBehavior are using the old input system. There is now a (experimental) new API for handing drag and tap events:

• drag events
• tap events

Ones these hit as stable we should refactor these behaviors to work with the new API. This will introduce a breaking change in flame_behaviors.

Requirements

• Refactor input behaviors to the new API
• Test their functionality
• Write migration documentation

Description

As a developer, I want to be able to detect collision with non-entity components as well. This would allow me to use flame_behaviors in any existing game and slowly migrate to the design rules. The CollisionBehavior already supports any type of component as the Collider but the PropagatingCollisionBehavior has an internal method that filters down on Entities only.

And while we do have an explicit test that ensures it shouldn't work for non-entity components, I do consider this a bug in the current implementation because the CollisionBehavior already works under the assumption that any component is allowed.

Requirements

• Update the internal method of PropagatingCollisionBehavior to be less strict towards entities.
• Update the tests to ensure that non-entity components are also able to collide.

In #2 I set the minimal score for pana to 65 because it was failing thanks to the fact that we are depended on Flame main. Once Flame v1.2.0 is released we can update the pana workflow back to using the $TOTAL variable.

Description

@renancaraujo mentioned in #20 (comment) that it would be nice to provide a behavior that simplifies collision interaction with a ScreenHitbox. We should provide an abstract API for that, that people can extend from to implement their own if I hit the screen then do this logic.

Requirements

• An API that allows developers to interact with the ScreenHitbox from a behavior.
• Add tests that ensure this new API works as expected.