Show area name when moving between areas

[renato-sy]

Add an area name banner that appears when the player enters a new area. The banner is shown for a few seconds when moving between areas such as Fray's End and Song Sanctuary.
Resolves #2340

[github-actions]

Play this branch at https://play.threadbare.game/branches/renato-sy/main/.

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

[manuq]

@renato-sy I see you continue pushing changes, so please let us know when you are ready to receive a review. Thanks!

[renato-sy]

Okay, I think that's it; the pulls I was doing were just little things Git required to perform the merge.

[manuq]

@renato-sy sorry for the delay. I wil have to review this on Monday. For the moment, please consider that there are other entry points to Fray's End:

• From the east.
• From the north (from Song Sanctuaries)
• From the west (from Fray's End West, after completing the Void quest)
• And another from the south (from Dev Archipelago, see image below)

I think entering from any of those should display the area name.

In fact all those have areas to block the exit, so maybe the entry areas should be next to them.

[renato-sy]

Hey there! I've already mapped out the routes for Frays End, Frays End West, and Song Sanctuary, but I'm not sure where we could put the entrance to the area in Linenville—I don't see any villages or anything like that.

And I'm not sure if it's appropriate to also include the area alert when leaving a quest.

[wjt]

Linenville doesn't exist yet as an area you can walk to on the map - the upwards route in that screenshots is blocked even once you complete the void quest and push back that patch of void.

I personally wouldn't include the area name when leaving (i.e. abandoning?) a quest. At the end of a normal quest, when you're teleported back to the middle of Fray's End, I don't think the banner is needed. But I would include it when you first reach Fray's End at the end of the tutorial, i.e. at the spawn point circled at the bottom-left here:

[renato-sy]

Okay, so Linenville isn't there. On the other hand—I don't know what you think about this—regarding the names that appear when entering an area, I placed it on the bridge, as if you were just arriving.

Just like in Song Sanctuary, I placed it on the bridge to indicate that the green section belongs to Routes or Fray's End, while the red part is a different area.

However, if you'd like, I could set it up so that a notification showing the zone's name appears at the spawn points when the first move is made. And if so, would the animation be only once (the animation is instantiated and then destroyed; we would have to go to another area and re-enter the area to see the name) or many times (like it is now but in the spawn points)

reentry

first entry

[wjt]

Yes, the different-coloured grass on the two sides of the bridge is meant to mark the boundary to the Song Sanctuary, so I agree that the trigger should be crossing that bridge from bottom to top!

[renato-sy]

Okay, so are we all set, or do I need to make any changes?

[wjt]

Sorry, I have not tested or reviewed the code changes yet!

[wjt]

I confess that I haven't read the implementation in detail but I don't think the behaviour is correct. Walking around Fray's End I can trigger the banner repeatedly even though I've never left Fray's End!

Screencast.From.2026-09-09.13-22-21.mp4

I would approach it something like this:

• In the game state, store the current area name, and a set of areas we have seen before
• Place area name triggers (Area2D with name property) in roughly the places you have done
• When a trigger detects the player:
  • If the current area name in the game state matches the trigger's name, do nothing
  • Else:
    • Set the current area name in the game state to the trigger's name
    • If the current area has not been seen before:
      • Show the "big" notification
      • Add it to the set of seen areas
    • Else, show the "small" notification.

With this approach, I don't think you need the "directions" property on the triggers.

[renato-sy]

I’ve fixed the issue you mentioned and switched the comments to English; you can check if the project.godot file has been reverted.

[wjt]

This signal's second parameter is never false so personally I would change this to:

Suggested change

	## Emitted when an area's unlock status changes.
	signal area_changed(area_name: String, is_unlocked: bool)
	## Emitted when an area is unlocked (i.e. first encountered)
	signal area_unlocked(area_name: String)

[wjt]

This signal is not actually used anywhere...

I think a better design would be:

• Change this signal to signal area_changed(area_name: String, first_visit: bool)
• Have the HUD scene connect to this signal and, when it is emitted, show the appropriate balloon - this keeps the UI responsibility in one place
• Then make the triggers be an Area2D (which can have multiple shapes in different parts of the scene if desired - or a huge polygon that covers the relevant area) which only adjust the state (and don't contain a new CanvasLayer)

[renato-sy]

So, would I move both of them to the HUD (first_unlock and re_entry)? The first one self-destructs, so I don't think there would be a problem—or I don't know, what do you think?

[renato-sy]

I don't think that question was necessary, haha, since when I copied and pasted the instance, it instantiates right into the HUD

[wjt]

I don't like how this looks with the heavy drop shadow. Personally I think we could use the same presentation as the dialogue balloons.

[renato-sy]

Okay, I've applied the "Balloons" one. Take a look—how does the color look? Should I change it?

[renato-sy]

I can review what you mentioned.