Repository navigation
Allow quests to contain 0, 1, or 2 collectibles rather than 3 #1234
Description
Currently, all quests have the player collect exactly three threads – memory, imagination, and spirit – which they take back to the Eternal Loom in Fray's End.
We would like to change this to allow quests to have fewer threads, for 2 reasons:
- Storytelling: A tale about a grandparent in WWI might invoke only Memory an Spirit, while a tale about the Cailleach might invoke Imagination only.
- Contributing: We want people to be able to contribute shorter quests, to reduce the workload & further increase the quality.
It should be possible to collect 2 or more of the same kind of thread (e.g. two or three Memory). In principle it should be possible to have a 4- or more-thread quest, though I don't think this is so high a priority
Right now we hardcode the 3-thread requirement in a few places:
- The HUD assumes that exactly three items will be collected (of any type)
- The Eternal Loom only allows you to drop off threads if you have collected at least 3 threads (of any type)
- The game's saved state does not save which threads (M, I, S) have been collected, only the number of threads collected. When restoring the state, if you have (say) 2 threads, it restores Memory & Imagination
- Make Eternal Loom animation dynamic based on collected threads #1861
- The Sokoban puzzle sets are a progression with 1, then 2, then 3 threads
XP Summary (total 500)
| Subdomain | Skill | XP |
|---|---|---|
| Engineering: Gameplay & Systems Programming | Problem Solving | 75 |
| Engineering: Gameplay & Systems Programming | Creativity & Design Thinking | 75 |
| Engineering: Gameplay & Systems Programming | Technical Literacy | 150 |
| Game Design: Game Feel & UX | Problem Solving | 50 |
| Game Design: Game Feel & UX | Creativity & Design Thinking | 75 |
| Game Design: Game Feel & UX | Technical Literacy | 75 |
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
wjt commentedon Sep 23, 2025
Some ideas:
Right now each instance of CollectibleItem has its own InventoryItem resource defined locally. I think we should instead define a
memory.tres,imagination.tres, andspirit.tres, and reuse those.(Maybe we should rename these to be more specific. Also the spelling "collectible" gets redlined by my spell checker: I agree, I think it should be "collectable".)
Then in the Quest resource type, add:
Or perhaps this is overkill and we should instead add:
Now, adjust the HUD and loom to react to the
collectiblesproperty of the current quest.If the number of collectibles is 1 or 2, perhaps only play 1 or 2 rounds of Sokoban? (But see also #1205.)
Another facet we might think about is: in quests that don't match the base game's visual style, people have wanted to change the appearance of the items in the level. Currently we don't support that, leading to workarounds like placing some other object over the CollectibleItem. We might want to consider relaxing that requirement in future. We don't have to do it as part of this change but I think we should bear it in mind in case it affects the design of the Quest API.
wjt commentedon Sep 24, 2025
@PlayMatters @hydrolet @jgbourque how should this request interact with the request in #1214 that the template duplication tool should duplicate all 3 minigames?
hydrolet commentedon Sep 24, 2025
We feel that the collectible (spelling with an i for us silly Americans) should always be thread. That is the link back to the lore of Threadbare.
About the number of collectibles required... We care mostly that the StoryQuest is published, regardless of whether it includes 1, 2, or 3 mini-games. And, regardless of what combination of mini-games they include (eg, three stealth games should be okay).
I think we like this scenario for a group who only had time to create one mini-game: the user would play a mini-game, collect 1 thread, go back to loom and play first sokoban level. The other mini-game templates, that they didn't have time to complete or mod, would be deleted / unused in their StoryQuest.
wjt commentedon Sep 25, 2025
According to the guide here #828 the idea was that:
We should clarify what we mean here: this is actually 3 submission points, 3a, 3b, 3c, one for each challenge.
So it's already the case that a group that only had time to create one mini-game can submit that. (In fact they can submit earlier than that.) We should really heavily encourage submission little and often at as many milestones as are reached. It's easier to review smaller submissions, and we can find problems (like assets we can't use) earlier in the process rather than after the whole programme has finished.
Separately, back to the point of this ticket, I think we should change the game code to support a 1- or 2-thread quest. I just want to highlight that our documented workflow already has incomplete quests being accepted and published.
wjt commentedon Sep 26, 2025
I have documented how a quest can work around this limitation. It's 1 line of code in a dialogue file:
wjt commentedon Oct 15, 2025
I tried to do this and weirdly it didn't work: when I
preload()ed the resources back, they did not have type InventoryItem. But I didn't investigate this much further, perhaps it's still worth trying.Another, simpler approach might be to change
CollectibleItemto not have anInventoryItemresource parameter, but instead to have:One more thing: in the game state we currently only save the number of threads that have been collected, not which ones. We will also need to change this to save the type of each thread. So rather than storing:
amount_of_items_collected = 2Instead store:
threads_collected = [IMAGINATION, SPIRIT]since there is a desire to relax the requirement that the order must always be M, I, S. It should be possible to have a story where you collect 2 MEMORY.
wjt commentedon Jan 23, 2026
There is an additional complication here. If you press F6 in a scene of a quest, or if you use a deep link to a scene in the web build,
GameState.current_questis not set. In this case we do not know how many threads need to be collected.And an existing problem: if you deep-link to the second minigame of a 3-collectible quest, then you can only collect 2 threads, not 3. Right now the way we deal with this is: when you get back to Fray's End, if you don't have enough threads to offer to the Loom, we just pretend you have no threads.
I actually think the latter behaviour is fine. For the former, I think we could arrange for the
GameStatecode to try to guess the quest if you deep-link to a scene (not hard: walk up the folder hierarchy until you find aquest.tresfile, or run out of folders).Allow quests to contain 0-6 threads, not always 3
Allow quests to contain 0-6 threads, not always 3
Allow quests to contain 0-6 threads, not always 3
Allow quests to contain 0-6 threads, not always 3
wjt commentedon Jan 25, 2026
#1861 addresses the core 3 points here.
For the loom animation, it's not the end of the world if the colours don't match. I filed #1861 for this.
For the sokobans - we have a separate discussion in #1205 about detaching the sokobans from the quests.
Allow quests to contain 0-6 threads, not always 3 (endlessm#1860)