Rework how projectiles are customised by wjt · Pull Request #1890 · endlessm/threadbare

wjt · 2026-02-06T17:34:49Z

Rework how projectiles are customised

Previously, all instances of the "fill game" used the same Projectile
scene. To customise its appearance, the ThrowingEnemy scene had a whole
series of properties that would be assigned each instantiated
projectile, in addition to assigning a label & optional modulate color
based on the target barrel.

This is not a very "Godot-ish" way to do it. Conceptually,
different projectiles should be different scenes that have similar
structures and reuse common scripts. Instead, we have had to manually
re-export properties from deep inside the projectile scene, and
propagate their values from the ThrowingEnemy scene.

Since commit 402f2ab
("ThrowingEnemy: Export the projectile scene") it has been possible to
customise which projectile scene is instantiated by any specific enemy,
but this isn't enough either for Stella or for Champ. In Stella, we
wanted the invisible enemies to throw, each time, a random choice
between a starfish (which matches the ship "barrel") or one of three
fish (which don't). But this wasn't possible. Similarly in Champ we want
the three different colours of fish to potentially be different sprites;
they currently happen to be recoloured versions of the same asset that
could be done with the projectile modulate logic but we don't want to
limit contestants to this.

So:

For each StoryQuest that previously reused the generic projectile
scene, create one (or more!) scenes specific to the quest. This does
introduce some duplication but I decided that the scenes are small
enough that using inherited scenes is more trouble than it's worth.
Similarly, make a dedicated ink blob projectile scene for the core
game.
Move the generic projectile scene to the NO_EDIT template, so that it
will be duplicated when creating a new StoryQuest.
Remove the sprite_frames and hit_sound_stream properties from
projectile.gd: these can be set by modifying the scene.
Remove the projectile_sprite_frames, projectile_hit_sound_stream,
projectile_small_fx_scene, projectile_big_fx_scene, and
projectile_trail_fx_scene properties from throwing_enemy.gd: these
can be set by modifying the projectile scene that it spawns.
Add the ability to spawn different projectile scenes based on the
target label. This is adapted from similar code in the Champ quest to
use different sprite frames per label. Use this in Champ and Stella.
In both cases define a custom throwing enemy scene, this time as an
inherited scene: there are huge animations in the enemy scene so in
this case I thought this was worth it.
Break the projectile-spawning code up a little. Having done this,
simplify some of the StoryQuest-specific projectile customisations.

Resolves #1873
Resolves #1874

Previously it had the NO_EDIT sprite frames assigned on the root node, but the ink blob one on the AnimatedSprite2D. At runtime, the former overwrote the latter. This is confusing. Set the same on both. Previously, it had a sound effect assigned on the AudioStreamPlayer2D but not on the root node, and again the root node's null stream would be set on the AudioStreamPlayer2D at runtime. Clear it.

We have found that this pattern can cause code to run in an unexpected order. We now prefer to early-return from the setter, and call it again explicitly from `_ready()`.

github-actions · 2026-02-06T17:39:28Z

Play this branch at https://play.threadbare.game/branches/endlessm/wjt/customise-projectile-via-scene-only.

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

Previously, all instances of the "fill game" used the same Projectile scene. To customise its appearance, the ThrowingEnemy scene had a whole series of properties that would be assigned each instantiated projectile, in addition to assigning a label & optional modulate color based on the target barrel. This is not a very "Godot-ish" way to do it. Conceptually, different projectiles should be different scenes that have similar structures and reuse common scripts. Instead, we have had to manually re-export properties from deep inside the projectile scene, and propagate their values from the ThrowingEnemy scene. Since commit 402f2ab ("ThrowingEnemy: Export the projectile scene") it has been possible to customise which projectile scene is instantiated by any specific enemy, but this isn't enough either for Stella or for Champ. In Stella, we wanted the invisible enemies to throw, each time, a random choice between a starfish (which matches the ship "barrel") or one of three fish (which don't). But this wasn't possible. Similarly in Champ we want the three different colours of fish to potentially be different sprites; they currently happen to be recoloured versions of the same asset that could be done with the projectile modulate logic but we don't want to limit contestants to this. So: 1. For each StoryQuest that previously reused the generic projectile scene, create one (or more!) scenes specific to the quest. This does introduce some duplication but I decided that the scenes are small enough that using inherited scenes is more trouble than it's worth. 2. Similarly, make a dedicated ink blob projectile scene for the core game. 3. Move the generic projectile scene to the NO_EDIT template, so that it will be duplicated when creating a new StoryQuest. 4. Remove the sprite_frames and hit_sound_stream properties from projectile.gd: these can be set by modifying the scene. 5. Remove the projectile_sprite_frames, projectile_hit_sound_stream, projectile_small_fx_scene, projectile_big_fx_scene, and projectile_trail_fx_scene properties from throwing_enemy.gd: these can be set by modifying the projectile scene that it spawns. 6. Add the ability to spawn different projectile scenes based on the target label. This is adapted from similar code in the Champ quest to use different sprite frames per label. Use this in Champ and Stella. In both cases define a custom throwing enemy scene, this time as an inherited scene: there are huge animations in the enemy scene so in this case I thought this was worth it. 7. Break the projectile-spawning code up a little. Having done this, simplify some of the StoryQuest-specific projectile customisations. Resolves #1873 Resolves #1874

wjt · 2026-02-06T19:07:24Z

scenes/game_elements/characters/enemies/throwing_enemy/components/throwing_enemy.gd

+## When launching a projectile, if the chosen label is found in this dictionary,
+## the associated scene will be used. If not, the default [member projectile_scene]
+## will be used.
+@export var projectile_scene_for_label: Dictionary[String, PackedScene]:


This is a "colo(u)r of bikeshed" situation but maybe this should be projectile_scene_per_label. I want projectile_scene to be at the start of the property name because all properties in the Projectile group must begin with projectile_ for their names to be shortened in the inspector (#1869).

wjt · 2026-02-06T19:09:28Z

scenes/quests/story_quests/champ/2_combat/champ_combat.tscn

-script/source = "class_name ChampFillGameLogic
-extends FillGameLogic
-#
-#@export var lab: String = \"\"
-#
-#func _ready() -> void:
-	#var color_per_label = {\"a\": Color(.3,.5,6), \"b\": Color(.9,.1,6),\"c\": Color(.1,.8,.2)}
-	#for enemy: ThrowingEnemy in get_tree().get_nodes_in_group(\"throwing_enemy\"):
-		#enemy.allowed_labels = allowed_labels
-		#enemy.color_per_label = color_per_label
-"


This embedded script doesn't do anything so I removed it in passing.

wjt · 2026-02-06T19:09:47Z

scenes/quests/story_quests/champ/2_combat/champ_combat.tscn

 editor_draw_limits = true

 [node name="ThrowingEnemies" type="Node2D" parent="OnTheGround" unique_id=1014610845]
-visible = false


I moved this to the AnimatedSprite2D inside the enemy scene.

wjt · 2026-02-06T19:13:05Z

scenes/quests/story_quests/champ/2_combat/combat_components/champ_throwing_enemy.gd

-	else:
-		# Default to original projectile sprite frames
-		projectile.sprite_frames = preload("uid://b00dcfe4dtvkh")
-	if projectile.label in color_per_label:


@felixwalberg I like this design. I moved the spirit of this into throwing_enemy.gd - but selecting a per-label scene not SpriteFrames.

wjt · 2026-02-06T19:16:10Z

...s/template_quests/NO_EDIT/2_NO_EDIT_combat/NO_EDIT_combat_components/NO_EDIT_projectile.tscn

To do:

Resave every scene that references this scene to update the path

Test that this this actually get duplicated & relinked correctly by the tool - I assume so but actually this will be the first PackedScene property.

wjt added 2 commits February 4, 2026 17:09

projectile: Do not await ready in setter

454e251

We have found that this pattern can cause code to run in an unexpected order. We now prefer to early-return from the setter, and call it again explicitly from `_ready()`.

wjt force-pushed the wjt/customise-projectile-via-scene-only branch from a6ef16a to 7550a4f Compare February 6, 2026 19:06

wjt commented Feb 6, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rework how projectiles are customised#1890

Rework how projectiles are customised#1890
wjt wants to merge 3 commits intomainfrom
wjt/customise-projectile-via-scene-only

wjt commented Feb 6, 2026

Uh oh!

github-actions bot commented Feb 6, 2026

Uh oh!

wjt Feb 6, 2026

Uh oh!

wjt Feb 6, 2026

Uh oh!

wjt Feb 6, 2026

Uh oh!

wjt Feb 6, 2026

Uh oh!

wjt Feb 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

wjt commented Feb 6, 2026

Uh oh!

github-actions bot commented Feb 6, 2026

Uh oh!

wjt Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

wjt Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

wjt Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

wjt Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

wjt Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant