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

Joystick part #1825

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

keithclark
Copy link
Contributor

[WIP] Prototype Joystick Part

This PR is a first stab at creating a Joystick input part for the Kano Code editor. It provides authors with a means to interact with their creations using a universal joystick input that responds to touch, mouse and keyboard.

Features

  • Sticks have a dead zone to prevent input noise when used with a mouse or touch. Once the handle has moved outside the dead zone the input is considered valid.

  • Sticks are dual axis (X/Y) but can be locked to a single axis, allowing authors to limit inputs to up/down or left/right.

  • Sticks expose boolean properties for up, down, left and right so authors can check state.

  • Sticks expose a direction property. This is useful when used with Sticker parts (used as sprites) as authors can orientate and move them based on the position of a stick. For keyboards, this is limited to 45 degree steps for dual axis configuration, or opposing 180 degree steps for single axis. For touch and mouse inputs there are 360 degrees of movement.

  • Sticks expose a force property. The value represents how far outside the dead zone a stick has moved. It ranges from 0 (stick is at rest) to 1 (full movement). For keyboard input, force can only be 0 or 1. For touch / mouse, force will vary with distance.

  • Sticks can be positioned using the moveTo method, exposed by TransformAPI.

  • Multiple sticks can be added to a creation. This works well for touch devices and for keyboards with the two inputs are locked to different axis. It doesn't yet work with two 8-way sticks as they both respond to the same set of keys.

  • Sticks listen for touch, mouse and keyboard events. Touch and mouse wait for the user to trigger a touchstart/mousedown event on a stick. For keyboard, I originally added tabIndex to the preview/player and listened for key events on that. However, this meant authors had to give focus to the player before the sticks would work, which became frustrating to work with. To resolve this, I now listen for key events on the body element. To prevent unintended input while editing code, events are ignored if the author is focused on a form control while inside the block editor. This allows creation authors and viewers to control sticks without having to have the creation player capture input first.

Screenshots

Toolbox additions

toolbox

Add Part menu

add-part

Part List item

part

Editor

editor

Examples:

This PR contains two examples to play with:

  • /examples/joystick/index.html - A simple game. Control the ladybird and eat the food before it disappears.
  • /examples/joystick/dual-stick.html - Use two sticks to control a ship. (Needs a tablet or a keyboard.)

Todo:

  • Explore using different keys for different joystick instances (could use the inline part for this?)
  • Graphics - For the stick (dynamic CSS gradients are slow!) and icons for the part.
  • Size joystick based on real world dimensions (e.g cm) so the control is the same physical size regardless of screen resolution or scaling.
  • Investigate replacing getBoundingClientRect with methods in "parts/dom/dom.js"

Future refactoring notes

  • The inline part is based on the weather. In fact 90% of it is identical. This should be converted into something reusable.

@TeamKano
Copy link

TeamKano commented Jan 22, 2020

Coverage summary
Statements 28.93% 2018/6976
Branches 20.19% 211/1045
Functions 28.96% 651/2248
Lines 28.82% 1951/6770

From Jenkins: kano-code/PR-1825

@pazdera
Copy link
Contributor

pazdera commented Feb 19, 2020

Hey Keith! This looks great, and we would be happy to accept this. At this point, we'd probably want to put it behind a communityParts flag until we're sure its ready to be included in the parts library on Kano World.

@keithclark
Copy link
Contributor Author

How does the communityParts flag work? Would the part be accessible in the editor on Kano World once the flag is toggled on?

Is there anything extra you need from me to progress this?

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

Successfully merging this pull request may close these issues.

3 participants