Create grapple gym for dev archipelago

[felixwalberg]

Design two scenes, grapple_gym_1.tscn and grapple_gym_2.tscn to show off features of the grapple mechanic.

The highlights are:

Gym 1:

• Simple grappling of pins
• Traversing gaps/areas with collisions
• Chaining needles to reach further
• HookableObjects must be positioned at angles of multiples of 45 degrees
• Some grappling is asymmetric
• String asset can be changed

Gym 2:

• Range of default grapple in the up, down, and left/right directions
• Grappling from a hookable_needle.tscn has a longer range than default grapple
• Chaining needles using the all_hooked.gd script can be used to trigger events in the game
• Range of "longer thread" ability

Gym 2 uses a regular Camera2D and adjusts zoom because the PhantomCamera2D was inconsistent in having the player centered. Since I was working max distances, the targets often were out of frame. I avoided chaining together enough needles that the target would be out of frame as well.

Gym 2 also has text labels to notate distance. Is there an accessibility standard in terms of font size?

Gym 2 is accessible from the end of Gym 1. I think it makes sense to be able to use both, but I thought Gym 2 should also exist as its own quest.tres so that a user in Dev Archipelago can go directly to experimenting with range rather than having to play through additional scenes.

In designing the visual examples of the reach, it made me wish there was an easier way to see the "reachable" area of a hookable_pin.tscn. Since hookable_needle.tscn has its own HookControl node, there is a visual indicator (at least in the positive x direction) of how much further you can reach from it. If it would be possible to have an inverse indicator (something like a marker 200px away from the edge of the HookableArea in each direction (and maybe one for the longer thread as well), then that might help with designing grapple levels with the pins in reach. For finding how far away I had placed the pins, I was printing the global_position of the Player to see how far out I would need to go.

I would love to get some feedback on whether these scenes do enough to get across supportive structure (either through signs or other visual clues) while also still encouraging users to be creative/diverge from the basics.

Resolves #2536, #1788

[github-actions]

Test build no longer available.

[manuq]

This is great!

The position of this pin is so clever, I tried hard but wasn't able to hook it with keyboard:

One recommendation I would add is to debug collision shapes when doing level design:

Grabacion.de.pantalla.desde.2026-08-02.22-11-58.mp4

Is better to see the ray and the rectangle areas than explaining. In fact what I usually do for level design is, I change the pins/needles positions while the game is running:

Grabacion.de.pantalla.desde.2026-08-02.22-26-07.mp4

[manuq]

This variable is not needed, as all happens inside the body_entered signal callback.

[manuq]

This check is not needed. The interest is in knowing if the body has a node %PlayerHook that is of class PlayerHook. In the future, we probably need a more solid way of obtaining a character features/capabilities.

[manuq]

Please add unique names to these nodes and use them here. Check: https://github.com/endlessm/threadbare/wiki/Contributing#use-unique-names-to-reference-nodes-in-scripts

[felixwalberg]

Is better to see the ray and the rectangle areas than explaining. In fact what I usually do for level design is, I change the pins/needles positions while the game is running:

I didn't even think about this! I had been toggling between playing in debug and editing the game but never at the same time. I forgot that you can actively see changes you make in the current game instance.

[manuq]

This if conditional now checks only for the node path, but you dropped the class check. I think is better to do:

Suggested change

	if body.get_node("%PlayerHook"):
	var hook: PlayerHook = body.get_node("%PlayerHook")
	var hook := body.get_node("%PlayerHook") as PlayerHook
	if hook:

This way:

• body.get_node("%PlayerHook") will return null if not found.
• X as PlayerHook (being X the result of the above) will return null if X is not a PlayerHook
• if hook: will be false in the 2 cases above because null is falsy (evaluates to false).

[felixwalberg]

Thank you! This makes sense.