On-screen control hints assume keyboard

[cassidyjames]

This threw my kid off a bit when we were playtesting with a controller—they assumed they had to use the keyboard but I reassured them the controller indeed worked. We should probably swap to controller-style hints when a controller is detected. We could also dynamically swap the hints based on whether a controller or keyboard was last used, e.g. in case someone has a controller passively connected but is using their keyboard.

XP Summary (total 300)

Subdomain	Skill	XP
Engineering: Gameplay & Systems Programming	Problem Solving	75
Engineering: Gameplay & Systems Programming	Creativity & Design Thinking	75
Engineering: Gameplay & Systems Programming	Technical Literacy	150

[wjt]

I added some code recently which tracks whether the last input device was a controller or a keyboard:

threadbare/scenes/game_elements/fx/shaker/components/shaker.gd

Lines 45 to 47 in c5b84f4

	## The device ID for the last controller we saw input from, or -1 if we have never seen input from a
	## controller or if the last input was on a keyboard.
	var _last_controller_id: int = -1

threadbare/scenes/game_elements/fx/shaker/components/shaker.gd

Lines 89 to 93 in c5b84f4

	func _input(event: InputEvent) -> void:
	if event is InputEventJoypadButton or event is InputEventJoypadMotion:
	_last_controller_id = event.device
	elif event is InputEventKey:
	_last_controller_id = -1

I imagine we could move this to a different global, with a signal for when the input method changes, and a property to get the current controller device id (-1 for "it's not a joypad"). Then the HUD scenes would gain a second property, the image to use for the joypad input hint, and swap in response to the signal.

Then we have the fun of showing A, × or B for the "interact" action depending on whether the controller uses xbox, sony, or nintendo labels. https://github.com/nathanhoad/godot_input_helper looks like an appealingly small addon, by the same person as Dialogue Manager, which could save writing out a lot of code of our own.

[manuq]

https://github.com/nathanhoad/godot_input_helper looks like an appealingly small addon, by the same person as Dialogue Manager, which could save writing out a lot of code of our own.

It also does input mapping, nice!

[wjt]

Here's my suggestion for an implementation plan:

1. Add the https://github.com/nathanhoad/godot_input_helper addon to the project.
2. Replace the logic in shaker.gd with this addon: check InputHelper.device_index rather than _last_controller_id and remove _last_controller_id and all code to update it.
3. Add the necessary assets from https://thoseawesomeguys.com/prompts/ for the 5 top-level device types exposed by that library.

https://github.com/nathanhoad/godot_input_helper/blob/ccfad58f7eea997e3d4f0903dcac9212da2b2208/addons/input_helper/input_helper.gd#L11-L15

4. Now adjust the various input hint scenes to monitor InputHelper.device_changed, and switch to an appropriate joypad image if it's a joypad (and back to the configured keyboard image if it's a keyboard)
5. For bonus points, use its mapping API to find which keyboard key/joypad event(s) corresponds to an input action name; and then look up the right asset to show in a generic way.

[wjt]

I found this other addon https://github.com/KoBeWi/Godot-Action-Icon which might be easier to integrate.

[AlealarcViva]

Hi. Pierina and I want to work on this issue.

[nico-noodle]

I plan to work with Ale on this issue.

[AlealarcViva]

https://docs.google.com/document/d/14kJY4PpXYxQOQlhgwJglndD7oyQH8r1JgUv_iWuJlzA/edit?usp=sharing