Skip to content

SequencePuzzleObject: Add sprite_modulate property#2147

Merged
manuq merged 1 commit intomainfrom
wjt/sequencepuzzleobject-add-sprite-modulate-property
Apr 28, 2026
Merged

SequencePuzzleObject: Add sprite_modulate property#2147
manuq merged 1 commit intomainfrom
wjt/sequencepuzzleobject-add-sprite-modulate-property

Conversation

@wjt
Copy link
Copy Markdown
Member

@wjt wjt commented Apr 28, 2026

Most instances of the sequence puzzle use the same sprite for all the
objects, with their colour adjusted using modulate. But we modulate
the entire tree of nodes (rooted at a StaticBody2D) rather than just the
AnimatedSprite2D.

Back when the puzzle was first prototyped, modulate was applied just to
the AnimatedSprite2D, based on the pitch of the note. I removed this in
commit ffd20d0
("MusicalRock: Remove automatic modulation by note") which has this note:

This looks a bit weird in the editor because the rock's collision shapes
and "kick" interaction label also get modulated. But at runtime the
collision shapes are invisible, and the label is not actually used – it
just sets the position where the label belonging to the player will be
positioned. And I consider modulating the sprite to be a temporary
measure; it would be better to recolour the rocks.

The great thing about temporary measures is they tend not to be temporary!

I am working on replacing the interaction label (not used at runtime)
with an indicator floating above each interactable object, which is
visible at runtime, and so modulating the whole scene will no longer
suffice.

Add a sprite_modulate property which proxies through to the
AnimatedSprite2D within. Update every scene to use it. (Not all
sequence puzzles use this approach: special mention to After the Tremor
which has per-object sprites.)

In effect, this is a manual version of the approach I rejected in commit
ffd20d0:

(I tried using PropertyUtils to export the modulate property of the
AnimatedSprite2D. It solved this problem but in my opinion the cure was
worse than the disease: it added more complexity to what is otherwise a
very simple scene, and the resulting "Sprite Modulate" property in the
inspector had no documentation.)

If only Godot had a built-in way for a scene to expose properties of its
children without going all the way to editable children!

Most instances of the sequence puzzle use the same sprite for all the
objects, with their colour adjusted using `modulate`. But we modulate
the entire tree of nodes (rooted at a StaticBody2D) rather than just the
AnimatedSprite2D.

Back when the puzzle was first prototyped, modulate was applied just to
the AnimatedSprite2D, based on the pitch of the note. I removed this in
commit ffd20d0
("MusicalRock: Remove automatic modulation by note") which has this note:

> This looks a bit weird in the editor because the rock's collision shapes
> and "kick" interaction label also get modulated. But at runtime the
> collision shapes are invisible, and the label is not actually used – it
> just sets the position where the label belonging to the player will be
> positioned. And I consider modulating the sprite to be a temporary
> measure; it would be better to recolour the rocks.

The great thing about temporary measures is they tend not to be temporary!

I am working on replacing the interaction label (not used at runtime)
with an indicator floating above each interactable object, which *is*
visible at runtime, and so modulating the whole scene will no longer
suffice.

Add a `sprite_modulate` property which proxies through to the
`AnimatedSprite2D` within. Update every scene to use it. (Not all
sequence puzzles use this approach: special mention to After the Tremor
which has per-object sprites.)

In effect, this is a manual version of the approach I rejected in commit
ffd20d0:

> (I tried using PropertyUtils to export the modulate property of the
> AnimatedSprite2D. It solved this problem but in my opinion the cure was
> worse than the disease: it added more complexity to what is otherwise a
> very simple scene, and the resulting "Sprite Modulate" property in the
> inspector had no documentation.)

If only Godot had a built-in way for a scene to expose properties of its
children without going all the way to editable children!
@wjt wjt requested review from a team as code owners April 28, 2026 14:08
@github-actions
Copy link
Copy Markdown

Play this branch at https://play.threadbare.game/branches/endlessm/wjt/sequencepuzzleobject-add-sprite-modulate-property/.

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

Copy link
Copy Markdown
Collaborator

@manuq manuq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to use a proxy in this case. Ugh you had to do it in all StoryQuests!

@manuq manuq merged commit f4785b5 into main Apr 28, 2026
6 checks passed
@manuq manuq deleted the wjt/sequencepuzzleobject-add-sprite-modulate-property branch April 28, 2026 14:47
@wjt
Copy link
Copy Markdown
Member Author

wjt commented Apr 28, 2026

It was quite an easy search-and-replace across the StoryQuests!

@wjt
Copy link
Copy Markdown
Member Author

wjt commented Apr 28, 2026

@jgbourque I presume that in at least 1 guide about the sequence puzzle, you show people how to adjust modulate to change the object's appearance. It is better now to use this new sprite_modulate property. modulate will still work for now, but assuming #2150 is completed it will also apply to the "interact with this" arrow in an ugly way. sprite_modulate does not have this property.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants