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

Knockback3 should have some kind of Knockback2 relationship/constructor/behavior #389

Open
Cokemonkey11 opened this issue Apr 6, 2021 · 2 comments

Comments

@Cokemonkey11
Copy link
Contributor

needs scoping/proposal

@Cokemonkey11
Copy link
Contributor Author

Knockback3's design is to act as a kind of global physics system for units in a map. It behaves well when you use it for everything, and poorly if you mix and match.

The implication is that applying knockback to a unit in motion is an additive effect. setVel can be used when an instantaneous interruption is needed.

As such, scoping 2D knockback opens some questions:

  • How should 2D knockback behave on a unit in 3D motion?
  • How should 3D knockback behave on a unit in 2D motion?
  • What constitutes a unit in 2D or 3D motion for answering the above?
  • Should it be possible to force a 2D knockback with any guarantees?
  • What should the behavior be for 3D knockback with horizontal trajectory? The same as a 2D knockback? What trajectory should act as threshold between the two?

@Cokemonkey11
Copy link
Contributor Author

I propose adding a new:

public static add2d(unit u, real initial_speed, angle groundAngle)
  • When applied to a unit with low velocity (configurable threshold), instantiates a Knockback3 with a 2d flag that behaves differently
  • When any knockback is applied to a flying unit, this codepath is used instead
  • When applied to a unit with 2d flag, behaves as add does
  • When applied to a unit with velocity and no 2d flag, "elevates" to 3d and uses horizontal trajectory
  • When a 3d knockback is applied to a unit with 2d flag, elevates to a 3d knockback, considering current velocity as simply 0 z component

What constitutes a unit in 2D or 3D motion for answering the above?

A unit is in 2d-only motion with the 2d flag.

Should it be possible to force a 2D knockback with any guarantees?

No, out of scope.

What should the behavior be for 3D knockback with horizontal trajectory? The same as a 2D knockback? What trajectory should act as threshold between the two?

Out of scope. Leave 3d knockback with horizontal trajectory unchanged.


Leads to a new question: what special handling should 2d knockback have?

  • Constant friction value (configurable, both air and ground)
  • FX only for ground units
  • setXY instead of setXYZ

Should 2d knockback consider heightmap?

No. Out of scope. Constant friction, no terrain-z consideration initially.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant