WIP: Store which threads have been collected

[wjt]

Stacked on:

• Store InventoryItems as separate resource files #2689

Helps #2280

[wjt]

How to test:

1. New game.
2. Skip tutorial.
3. Go to Dev Archipelago
4. Talk to the first elder. i've patched him to show the level design quests
5. Chose the "Optional Threads" quest
6. On your first playthrough, collect only the green thread on the right. Don't try to avoid the guards.
7. Go back to Fray's End. Deposit the threads at the Loom. Watch the animation.
8. Quit to title then continue (works around a bug in this branch)
9. Go to Dev Archipelago again, and play the quest again. You should see that the green thread has a dither effect on it.
10. This time, avoid the guards and collect the red thread. Then deliberately allow the guards to catch you.
11. When you respawn, the red thread should still be gone.
12. Go back past the guards and collect the (dithered) green thread.
13. Take the 1 new thread you have collected to the loom.
14. Repeat step 8
15. Repeat step 9. You should see that the red thread is missing, and the green thread is stippled.

[github-actions]

Play this branch at https://play.threadbare.game/branches/endlessm/wjt/store-collected-threads/.

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

[wjt]

This is a work in progress. I am more interested in review of the gameplay than of the code. The incompatible requirements I am trying to square are:

1. We want quests to be replayable
2. We want to be able to have optional threads in quests
3. You shouldn't be able to collect the same thread more than once (because you'll be able to spend your threads on powerups and otherwise you could just grind an easy quest and unlock the whole tech tree)...
4. ...but collectible threads are how we link scenes together.

In this branch, the behaviour of a previously-collected thread depends on whether the thread has a "next scene" configured:

• If it does, then it is shown in-world, but stippled, and collecting it again does not readd it to the inventory
• If it does not, then it is deleted immediately

The intuition is that optional threads should not link to another scene, while mandatory threads always do. (However I can already imagine cases where we might want to teleport the player after an optional thread...)

[felixwalberg]

This is cool! I like your distinction of dithering the previously collected threads to indicate it won't be contributing to threads used in the skill tree!

I know that this is more of a collection of what threads you are bringing back to Fray's End than a "progress bar", but when there are optional threads, it might be nice if there is a way to indicate that. If you are not able to collect optional threads more than once, there is only one attempt where this could be completely full.

If you play it again and only collect the green thread, you then go back to Fray's End and have to deposit threads even though none are visible in the collection in the top right.

I was wondering... would it be worth experimenting with a different visual for threads that are optional and previously collected? Something that shows up but is not interactive like the green thread. But then I was questioning (and maybe I am missing a key point) why we need to make that distinction? If the green thread doesn't contribute to the skill tree and doesn't show in the progress bar, is there any problem with doing the same with the optional red thread?

[manuq]

All works as expected:

I played without reading your requirements first. I would have expected the green spool to dither and also have collisions removed (like the powerups). But then I realized that there wouldn't be an exit, because collecting the green spool does the level progression (what you call mandatory threads that link scenes together). Also I would have expected the red thread to be dithered and without collider, instead of gone (to indicate that I grabbed it at one point in gameplay).

This is a work in progress. I am more interested in review of the gameplay than of the code. The incompatible requirements I am trying to square are:

1. We want quests to be replayable
2. We want to be able to have optional threads in quests
3. You shouldn't be able to collect the same thread more than once (because you'll be able to spend your threads on powerups and otherwise you could just grind an easy quest and unlock the whole tech tree)...
4. ...but collectible threads are how we link scenes together.

In this branch, the behaviour of a previously-collected thread depends on whether the thread has a "next scene" configured:

• If it does, then it is shown in-world, but stippled, and collecting it again does not readd it to the inventory
• If it does not, then it is deleted immediately

The intuition is that optional threads should not link to another scene, while mandatory threads always do. (However I can already imagine cases where we might want to teleport the player after an optional thread...)

The level explains very well the problem. I think that to avoid any issues we shoulds make all threads the same, optional. And use a separate toggleable object with a teleporter inside to link scenes together. A closed/opened door, for example. That is, remove requirement 4. We'll have to update all the quests, though.

Alternatively, the dithered spools should link to the next scene but not count as collected. That is, don't go to the inventory.

[manuq]

One reference of optional collectible: the 10-flower coins in Mario Wonder. These are big purple flower-shaped collectibles. There are 3 per level. Once you collect them, they dissapear. The next time you play the same level, they appear stippled. If you re-collect them stippled, they dissapear again.

[JoniCeceri]

Noting here the convo from the meeting: removing requirement 4 by having the teleporter interactable threads be "legacy" and new threads going forward just be collectables (with existing levels reworked to accommodate changes)

Also noting, have collected threads on replaying level be replaced with bonus buttons to "mark" their collection and also give a slight bonus to players who backtrack to them.

[wjt]

We discussed this in the build review. In summary:

• Either stipple previously-collected collectibles when you re-play the quest, or replace them with collectibles of lower value. TBC.
• The consensus was that yes, we should split the "collectible" and the "teleport to next scene" functionality (and I think we should split the "play dialogue" functionality at the same time!). One idea to avoid having to redesign every quest in the game is that we could implement a new object; leave the existing one but mark it as deprecated, and then quests would continue to work.

Actually I think we could do the refactoring mechanically:

1. Add a collected signal to collectible_item.gd
2. Write a script to go through every scene in the game that instances collectible_item.tscn (I already did this!). For each one:
   • If the thread has dialogue as well as a next_scene, add a Cinematic node. Configure it with the same dialogue and next_scene. Connect the collectible's collected signal to the start signal on the Cinematic.
   • Otherwise, add a SceneLink node. Configure it with the same link. Connect the collectible's collected signal to its switch method.

There are some edge cases to deal with here though:

• Collectibles update the challenge_start_scene (used by the lives functionality which we have effectively disabled...), nothing else does.
• We need to take control of the player character while the cinematic is playing and/or the scene switch is occurring.