feat: locomotion settings

[nearnshaw]

new avatar locomotion settings component

[github-actions]

Test this pull request

• The @dcl/protocol package can be tested in scenes by running

  npm install "https://sdk-team-cdn.decentraland.org/@dcl/protocol/branch//dcl-protocol-1.0.0-20921108763.commit-a89d156.tgz"

[robtfm]

my thoughts from the original implementation and from now. we discussed some of these at the time, just reiterating now since i don't fully remember the conclusions.

• InputModifier - contains related settings, the split is unclear

• area vs player component
  + player component Is more natural for powerups
  + player component is less ambiguous: area component has ambiguity for overlapping areas (like AvatarModifierArea does today)
  = player component would be preferable if it could be applied to other avatars. The target is never ambiguous, always the primary player, so there is no benefit to attaching it to the player
  - area component allows for changes based on location, like ice/swamp surfaces etc. these can also be done by the scene by modifying the component
  - area component could potentially be used to determine appropriate animations for other avatars as well

general comment which applies to a lot of the rest: I think we are putting too much constraining specificity. The experience should be managed more by the scene and less by specific engine implementations

3 speeds:

• not clear how this should be managed by implementations which use analog directional inputs
• suggest one speed, let the client determine the walk ratio
• suggest using this disables sprinting? sprinting can be managed by the scene using the IA_MODIFIER key; If held -> max speed changes (also jump height etc can be changed)

jump height / run jump height:

• what determines the cutoff? Is it based on the walk input not being pressed? The avatar speed?
• suggest let the scene manage it by modifying the jump height based on avatar velocity

hard_landing_cooldown

• this is a very specific behaviour which may not be desirable for all scenes. The scene can manage it directly (and play an appropriate emote) by tracking avatar position and using InputModifer.
• if we keep it, we should answer
  • does it trigger by fall height or by fall speed?
  • can creator modify the drop height or fall speed which triggers it
  • can creator disable it for some surfaces (e.g. trampoline or some thing)

suggest additions:

• friction. Used to determine how quickly input translates into motion, and how quickly player comes to rest after releasing. Possibly separate air / ground values?
  • matching clients requires a pseudocode implementation, happy to provide
• control method (maybe better for InputModifier) - we support tank controls (like resident evil) as well as camera-based controls. Requires adding "turn speed"
• gravity
• max fall speed