[Proposal] Add signals to many nodes as extension points for new mechanics

[JuanFdS]

As a contributor, I think it'd be useful to connect to certain behaviors of the game elements that already exist in threadbare to add new mechanics in new story quests without needing to modify the game elements that already exists.

For example, I think signals could be added when:

• doors open and close.
• collectible items are collected.
• an npc was talked to.
• ...etc.

What do you think?

[Arebuayon]

I have a group of students who want to trigger an event at each step of a melody, but the HintSign node doesn’t emit any signals. Is it possible to add a signal to it? In the meantime, I thought of two possible alternatives:

1- Use multiple SequencePuzzle nodes, each with just one SequenceStep, since SequencePuzzle does have an is_solved signal.

2- Tell them to create a subclass of HintSign and simply add a custom signal that gets emitted when is_solved is called so it can be used more flexibly.

[manuq]

@JuanFdS just to clarify, this is a good thing to do for the next iteration. It will be confusing for all teams if such thing is implemented in the middle of the current program.

[JuanFdS]

@JuanFdS just to clarify, this is a good thing to do for the next iteration. It will be confusing for all teams if such thing is implemented in the middle of the current program.

Yes!, sorry if it wasn't clear @manuq , the question is:

What should we do in the meantime if a learner wants to implement a mechanic that isn't possible to be implemented with the current game elements?, should we guide them to:

• work around with the current nodes? (like making multiple SequencePuzzles?)
• extend the current scripts to add the needed logic so that can later be replaced? (like extending HintSign to add that signal to their own script)
• duplicate all the scripts and scenes they want to extend and change them?
• just don't try to implement that mechanic
• other...?

Edit: since all of these options don't need modifying the rest of the project's code, I guess any option could work, I'm asking in case any of those options make it easier to mantain the project later on.

[wjt]

I think any option which does not go outside the storyquest directory is fine. extends probably involves the least additional typing, but duplicating the script (and changing its class_name) is probably easier.

A stretch goal would be that a learner could open a self-contained pull request that proposes adding new API. This could happen in parallel to implementing the mechanic in the storyquest directory. Personally I think this would be better done after the storyquest is complete – we might find that several teams need similar changes, or tried different approaches to the same problem, and if so we can choose the best option to implement.

[JuanFdS]

I think any option which does not go outside the storyquest directory is fine. extends probably involves the least additional typing, but duplicating the script (and changing its class_name) is probably easier.

A stretch goal would be that a learner could open a self-contained pull request that proposes adding new API. This could happen in parallel to implementing the mechanic in the storyquest directory. Personally I think this would be better done after the storyquest is complete – we might find that several teams need similar changes, or tried different approaches to the same problem, and if so we can choose the best option to implement.

Thanks a lot!

[wjt]

I filed #783 for this