Charge Control Transition

[azriel91]

In GitLab by @azriel91 on Jul 26, 2019, 09:50

Charge model:

Charging styles:

• Continuous
• Blocky (delay before next bar is charged)

Storage:

• Single bar / block
• Multiple bars / blocks (can be rendered as layered bars, or multiple chunks on a single bar, etc.)

Activation:

• On button press
• On button release
• Delay / time based
• Interaction from another object

Charge usage:

• Everything
• Up to previous partial block stop
• Up to previous complete block stop

Subtraction (depends on object -- can't mix the two variants):

• On sequence transition: Retain existing charge for ammo type charges.
• On button release: Empty out charge for buster type charges.

Data Types:

• ChargeUseEvent: Event indicating ChargePoints have been spent.
• EventChannel<ChargeUseEvent>: Event channel.

Components:

Instead of type parameterizing each of the charge types per action button, we will limit objects to have one charge value, and it is charged usually by holding the attack button (potentially expand to holding multiple buttons in the future, e.g. for dragon ball style charging).

• ChargePoints: Newtype for charge value (u32).

• ChargeTrackerClock: Logic clock that stores ChargePoints.

• ChargeBeginDelayClock: Number of ticks a button must be held before Charging begins.

• ChargeDelayClock: Number of ticks to wait before charge value increments.

• ChargeRetentionClock: Number of ticks to wait before decrementing ChargeTrackerClock.

• ChargeRetention enum: Indicates whether the ChargeTrackerClock should be decremented or reset if there is no transition when the button is released. Enum variants: Never, Immediate, Decrement(ChargeRetentionClock), Reset(ChargeRetentionClock).

• ChargeUseMode enum: Specifies the formula to use when subtracting charge points when they are spent:

  • NearestPartial(ChargePoints): If the object has 21 to 30 ChargePoints, and the move costs 10, it will drop to 20.
  • NearestWhole(ChargePoints): If the object has 20 to 29 ChargePoints, and the move costs 10, it will drop to 10.
  • All: ChargeTrackerClock is reset() to 0.

Systems:

• ChargeInitializeDetectionSystem:
  • Detects the begin / cancellation of the initialization phase of charging..
  • Resets ChargeBeginDelayClock upon charge start / stop (currently control input event release).
• ChargeInitializeDelaySystem:
  • Ticks ChargeBeginDelayClock while Attack is held.
  • Adds ChargeTrackerClock on charge begin if none exists and ChargeBeginDelayClock is_complete()
• ChargeIncrementSystem: Ticks ChargeTrackerClock while button is held and ChargeBeginDelayClock is_complete().
• Update CharacterControlTransitionsTransitionSystem to send a ChargeUseEvent when a transition happens that requires ChargePoints.
• ChargeUsageSystem will decrease ChargeTrackerClock to last charge stop / block based on ChargeUseMode.

Tasks:

• Determine if proc macro attribute order is deterministic.

  Its behaviour is, but it is simply how it was implemented. rust-lang/rust#63336 and rust-lang-nursery/reference#578 confirm that it's not something to be relied on.

• Update logic_clock_derive to implement AsRef<LogicClock> and passthrough constructor.

• Implement type_parameterize proc macro function to newtype wrap with <T>.

• Implement ChargeInitializeDetectionSystem.

• Implement ChargeInitializeDelaySystem.

• Implement ChargeIncrementSystem.

• Update CharacterControlTransitionsTransitionSystem to send ChargeUseEvent.

• Implement ChargeUsageSystem.

• Add CpBar to display charge.

• Add systems to GamePlayBundle.

• Wire through ChargeLimit and ChargeDelay config.

• CpBar entity begin at origin.

• Both Cp and Hp Bar entities remain after ending game.