Move interact verb/action to HUD

[wjt]

Instead of showing text over the object in the world, show it on the HUD
at the bottom of the screen, in place of the "Interact" label.

Show a bouncing red arrow above the currently-targetted interactable
entity. Show nothing above interactable entities that are not currently
targetted, but define an "idle" animation for this case so that we could
in theory change this later just by adjusting the animation.

Define the arrow position with a Marker2D attached to the InteractArea.
Migrate all existing interact_label_position values to a new Marker2D
node on each - these will not all be correct, but some of them might be.
Manually adjust some, including the tricky case of the Stella tortoise.
(Doing this by moving a Marker2D around in the editor is so much easier
than when I did it by editing Vector2 values by hand!) For some cases
where the default position - 64px above the InteractArea - is good
enough, I removed the Marker2D for a simpler scene & smaller diff.

Make all InteractArea nodes visible. (In a number of cases we previously
hid them to reduce the visual clutter, but this would hide the arrow.) I
may have missed some but we can fix them as we find them.

At runtime, if no Marker2D is provided, place one 64px
above the InteractArea node - better than nothing.

Adjust the logic in character_sight.gd to only emit
interact_area_changed if it actually does change, rather than just
because the player moved so that a second object is in range without
changing the "best" object. (This has no visible effect but was
necessary to add a sound effect on change, which I tried then removed.)

Resolves #2114

[github-actions]

Play this branch at https://play.threadbare.game/branches/endlessm/wjt/move-interact-verb-action-to-hud/.

(This launches the game from the start, not directly at the change(s) in this pull request.)

[wjt]

This is a draft for a number of reasons, not least that interact_label_position is not a good property name for the arrow position, and because there is a bug where the arrows appear much higher for the rocks in situ than the arrow does when editing the rock scene itself and I don't know why.

But another thing I realised while testing this… I had really hoped that we could avoid needing the ScreenOverlay CanvasLayer, on the basis that we seem to get away OK with the grapple direction arrow on the player being smaller when the view zooms out, and because we could then just WONTFIX #725.

However while testing this I happened to look at res://scenes/quests/story_quests/stella/3_stella_sequence_puzzle/stella_sequence_puzzle.tscn and discovered that the Guardian NPC in that scene is scaled to 1.5×1.5, and so due to the way I have implemented this feature, so is the arrow above her head. It looks really bad.

When I first prototyped this I put a static, dimmed/semitransparent arrow above all interactable objects, with the currently-targetted one (if any) bouncing and fully opaque. This looked really busy in areas with many interactable objects, such as sequence puzzles. If we are happy to only show a single arrow at a time (not sure!) then we could instead have the PlayerInteraction node get the position to show the arrow from the InteractArea it is targeting, and have a single arrow that gets moved around the screen as a child of the player node. A bit weird but it would mean the arrow follows the player scale (i.e. hopefully 1×, but if someone does scale the player for some reason it would also scale the grapple arrow...), leaving only the camera zoom problem.

Otherwise... maybe we are stuck with the ScreenOverlay (but could we use the InputHud autoload which is guaranteed always to be present?) and then we'll have to solve the dizzying effect still.

[wjt]

Some scenes to look at:

• https://play.threadbare.game/branches/endlessm/wjt/move-interact-verb-action-to-hud/#res://scenes/world_map/frays_end.tscn
• https://play.threadbare.game/branches/endlessm/wjt/move-interact-verb-action-to-hud/#scenes/quests/lore_quests/quest_001/1_music_puzzle/music_puzzle.tscn
• https://play.threadbare.game/branches/endlessm/wjt/move-interact-verb-action-to-hud/#scenes/quests/story_quests/stella/3_stella_sequence_puzzle/stella_sequence_puzzle.tscn

[manuq]

This is a draft for a number of reasons, not least that interact_label_position is not a good property name for the arrow position, and because there is a bug where the arrows appear much higher for the rocks in situ than the arrow does when editing the rock scene itself and I don't know why.

I see that in code you create a Marker2D and then instantiate the interact_indicator.tscn . Can we just remove the interact_label_position offset add a Marker2D directly as child of InteractArea in the scenes using it? Similar to @export var anchor_point: Marker2D in HookableArea. Or just instantiate the arrow directly in scenes, and make it an export of the InteractArea? Something like:

## Node2D used to display to indicate that this area can be interacted.
@export var indicator: Node2D

But another thing I realised while testing this… I had really hoped that we could avoid needing the ScreenOverlay CanvasLayer, on the basis that we seem to get away OK with the grapple direction arrow on the player being smaller when the view zooms out, and because we could then just WONTFIX #725.

However while testing this I happened to look at res://scenes/quests/story_quests/stella/3_stella_sequence_puzzle/stella_sequence_puzzle.tscn and discovered that the Guardian NPC in that scene is scaled to 1.5×1.5, and so due to the way I have implemented this feature, so is the arrow above her head. It looks really bad.

This is what I see:

In my opinion it doesn't look that bad. This Guardian is an instance of Talker. Maybe it can just be a StaticBody2D with the AnimatedSprite2D (scaled at 1.5), plus the TalkBehavior, plus the InteractArea as children. Like a one-off node for this particular scene.

I also would like to say goodbye to ScreenOverlay :)

When I first prototyped this I put a static, dimmed/semitransparent arrow above all interactable objects, with the currently-targetted one (if any) bouncing and fully opaque. This looked really busy in areas with many interactable objects, such as sequence puzzles. If we are happy to only show a single arrow at a time (not sure!) then we could instead have the PlayerInteraction node get the position to show the arrow from the InteractArea it is targeting, and have a single arrow that gets moved around the screen as a child of the player node. A bit weird but it would mean the arrow follows the player scale (i.e. hopefully 1×, but if someone does scale the player for some reason it would also scale the grapple arrow...), leaving only the camera zoom problem.

I remember watching a screenshare with the multiple semi-transparent arrows and yes, my first impression was that it was a bit busy. I like it one at the time, like in this draft.

When you say you would like to reuse a single arrow, is it for consistency? For optimization? I wouldn't mind having each InteractArea with their own arrow that gets disabled/enabled, at least as a first step.

Otherwise... maybe we are stuck with the ScreenOverlay (but could we use the InputHud autoload which is guaranteed always to be present?) and then we'll have to solve the dizzying effect still.

[manuq]

After playing some more... I really like where this is going. Maybe the "[Space] Talk to..." in the HUD can have a visual/audio clue when it changes (for later). Also I wonder if the arrow is too tiny for the Eternal Loom or other big things to interact, but I guess it's fine!

[wjt]

I see that in code you create a Marker2D and then instantiate the interact_indicator.tscn . Can we just remove the interact_label_position offset add a Marker2D directly as child of InteractArea in the scenes using it? Similar to @export var anchor_point: Marker2D in HookableArea.

That's what I plan to do. (And in fact you're on the right track that this was the cause of the misalignment bug - in one code path I set the position on the marker, and in the other I set the position on the indicator.)

I was hoping to have a clever tool script migrate all the scenes that set interact_label_position to instead add a marker at that position. Even if we have to (gradually!) go through and fix all their positions later.

Or just instantiate the arrow directly in scenes, and make it an export of the InteractArea? Something like:

## Node2D used to display to indicate that this area can be interacted.
@export var indicator: Node2D

The reason I didn't do this is that we want (I think?) the indicator to be consistent between every interactable thing, so it would be manual work each time to put the indicator in place, and then a nightmare if we want to change how it works later!

In my opinion it doesn't look that bad.

OK!

This Guardian is an instance of Talker. Maybe it can just be a StaticBody2D with the AnimatedSprite2D (scaled at 1.5), plus the TalkBehavior, plus the InteractArea as children. Like a one-off node for this particular scene.

True!

I remember watching a screenshare with the multiple semi-transparent arrows and yes, my first impression was that it was a bit busy. I like it one at the time, like in this draft.

👍🏻

When you say you would like to reuse a single arrow, is it for consistency? For optimization? I wouldn't mind having each InteractArea with their own arrow that gets disabled/enabled, at least as a first step.

It was for showing a single arrow in ScreenOverlay/InputHud, moved around to the current target. I don't think there is likely to be a performance issue with one arrow per target but all bar one being invisible.

OK, I will continue down this path.

[wjt]

I finished migrating all existing interact_label_position values to Marker2Ds. To do this I took advantage of the power of @tool scripts: in InteractArea._ready, if running in the editor, I would:

1. Add a Marker2D child, assigning it the correct owner to be saved to the scene
2. If interact_label_position was non-zero, I assigned its position to the Marker2D then cleared its value
3. Now I just opened every scene that uses interact_area.gd and saved all scenes.

I tweaked the Stella tortoise by hand.

I also tried adding a little sound effect whenever the interact target changes. I think it's good? I wondered about making the "(A) Talk to Sigurd" label emit particles in this case too but decided that's too much, and visual design is not my forté.

[wjt]

One more problem I noticed: the arrow is in the world layer so is affected by weather.

[manuq]

At first read I though that you were trying to say either "the entity" or "the player", not both. But after a second read, I got it!

[wjt]

Good point, it's a tricky sentence...

[manuq]

👍

[manuq]

👍

[manuq]

👍 as you say in the PR description, is better than nothing.

[manuq]

I like that the bounce is done through AnimationPlayer!

[manuq]

👍