Create "secret path" tool for semi-hidden access to dev island

[felixwalberg]

Add a tool to disable collisions when the player enters the area. Modulates trees within the area to simulate a secret passage within the forest. A possible way for us to style the entry point to Dev Island somewhere in Fray's End (video in comments).

Questions/Concerns/Ideas

• Could we add class_name to the tree scene, or does that introduce too much complexity? My current check if a node is a tree is pretty hacky
• Where all of these should exist filesystem-wise:
  • Where should dev_island.tscn be stored? Among the LoreQuests?
  • Where should (if they are even added) the tree_parter.tscn, tree_parter.gd, and tree_parter_test.tscn be stored?
    • On this thought, should all test scenes be stored somewhere close to dev island?
• Depending on how far the CollisionShape sticks out from the forest border, there is a chance the player gets confused by an invisible border they can't cross (this could be solved by either moving the borders back, rounding out the side so they can walk along more smoothly, etc.)
• The (Quest)Teleporter could exist as a child node of the tree_parter.tscn and could be toggled off when not needed. This would avoid having to drag the teleporter shape into the correct spot, and it would dynamically resize with the tree_parter itself
• We could generalize this to other collision objects (not just trees), but I'm not sure if there is much application there
• This PR should probably not contain the dev island scene itself, but rather just the tree_parter and its testing scene in terms of keeping the scope down

Idea: the entry to the hub can be hidden in Fray's End, but still marked with a sign post for discoverability. Walk across the trees?

Addresses one component of #2108

[felixwalberg]

Screen.Recording.2026-07-07.at.4.50.54.PM.mov

[github-actions]

Play this branch at https://play.threadbare.game/branches/endlessm/dev-island-access/.

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

[manuq]

In general I think this is a bit overengineered for what is possibly a one-off. I would:

• Setup an array of CanvasItems to disable / modulate
• Add an Area2D to detect the player and a callback for body_entered / body_exited
• When the player enters/exits, flip the collision shapes used in the forest StaticBody2D. That is, enable different CollisionPolygon2Ds that have the access, disable the one that doesn't have the access.
• Also, when the player enters/exits, change processing mode on the array of CanvasItems that was setup.
• Maybe even do all this with AnimationPlayer, so a smooth animation of the modulate value is possible.

[manuq]

Why constrain this to a single class? What this script does for opening the access is:

• Set the tree in PROCESS_MODE_DISABLED
• Change the tree modulate to make it semi-transparent.

And since modulate is a property of CanvasItem, this could work with any CanvasItem.

Also the "WalkableTrees" Area2D is used for 2 things:

• For detecting the player and opening the access.
• For setup of the items to disable and modulate.

I think that this coupling is a bit constraining, and is a bit tricky to setup the items at run-time, using the body_entered signal. If you leave the Area2D just for detecting the player, you could do the setup of items just by exporting an Array of CanvasItems. Something like:

## Items you want to walk past
@export var items: Array[CanvasItem]

Although it will be hard to setup, and has to be done each time AreaFiller "Refill" is pressed. For that a @export_tool_button could be added. Or alternatively, export the parent node and traverse all immediate children, matching CanvasItems.

## Parent of items you want to walk past. Each CanvasItem immediate children 
@export var parent_of_items: Node2D

[manuq]

This is limiting, because the Area2D and its collision shape are inside the tree_parter scene. So:

• It constrains to a rectangle shape.
• And the rectangle shape can't be modified in the 2D viewport, only by these width, height sliders in the Inspector.

Instead, you can remove the Area2D from tree_parter and add an @export for it. You could check how other "behavior" scripts do it.

Oh, but I see now that this also has to adjust the borders according to the width and height! Looks a bit overengineered (I'll explain in a few).

[manuq]

I'm pretty sure that setting process_mode = Node.PROCESS_MODE_DISABLED on the tree will also set it on all its child nodes like the collider (if they are setup with Node.PROCESS_MODE_INHERIT). So I wonder if you need the extra colliders array at all.

[manuq]

This relies on doing the setup of trees and colliders at run-time when the scene is started and body_entered is called with them.

[manuq]

There are y-sort issues in this test scene!