Create smaller project bundle for StoryQuest creation

[wjt]

Our learning team would like a smaller Godot project for learners creating StoryQuests, both to reduce the mental burden of navigating the full project, and to improve performance with Backstitch (and reduce the burden on the server).

Here is my suggestion:

1. Delete all StoryQuests. We know that this can be done without breaking the surrounding game because I did this for the LoreJam a few months ago.
2. Delete large unused assets – for example, we have a full copy of the non-CC0 Tiny Swords free pack in the repo (so that we can record the special permission we have been given to redistribute it) but it is not used (except for 4 rocks in champ).
3. Delete the world map (i.e. Fray's End and connected scenes) and all LoreQuests. Keep Dev Archipelago.
4. Change the title screen to launch the NO_EDIT template quest rather than the now-deleted tutorial. Change the "Abandon Quest" and end-of-quest target scene to be the Dev Archipelago hub scene.
5. Rename "NO_EDIT" to "PLEASE_EDIT" (name tbd!).
6. Add the backstitch launcher.
7. Put this in a .zip file

Now learners would use this as the basis for their quest. They use backstitch not git. They don't duplicate the template, they just edit it in place. The quest is a standalone game. Later we tackle how to launch them dynamically; but more likely, we just import the good ones back into the git tree (changing the UIDs in the quest scenes/resources when we do so because they will be the same as the NO_EDIT quest).

We would not prepare this bundle for every commit. Instead we would generate it for each release and attach it to the release. Learners would be pointed to this. This would avoid the current problem of learners getting a random snapshot of whatever happens to be on git main at the time their fork is created.

[jgbourque]

@hydrolet @wjt This sounds great. The one thing we want to be OK with here is that the learners making quests from here on is that the learners will be working separately from the full game. They can of course still access, play, and download the full game but their quest designs happen separately.

Is the intention to try and keep character functionality, scripts, and game systems used in the LoreQuests preserved inside the Dev Islands or at least in the smaller SQ bundle so that learners will not be without them? Is that possible?

[wjt]

Is the intention to try and keep character functionality, scripts, and game systems used in the LoreQuests preserved inside the Dev Islands or at least in the smaller SQ bundle so that learners will not be without them?

Yes. Without these the game would not work. These already live outside the quests & world map.

[wjt]

One thing that makes this a little harder is that at the end of each quest (including the template) we link directly to Fray's End (by UID). This can't work if Fray's End is deleted from the StoryQuest kit!

My best idea here is to add a special mode to SceneLink to mean "Go back to the home scene", with the home scene configured in the project settings to be Fray's End in normal versions and something else in the SQ kit.

To this end I am doing a series of preliminary fixes/refactors:

• ThreadbareProjectSettings: Fix hint_string misuse #2565
• Sokoban: Use SceneLink #2566
• Cinematic: Chain up to SceneLink._validate_property() #2567
• Store initial quest & home scene in project settings #2568
• SceneLink: Add a special case for "go home" #2569
• Update keyboard bindings for DEVICE_ID_KEYBOARD #2572
• Update Dialogue Manager to v3.10.5 #2573

[manuq]

My best idea here is to add a special mode to SceneLink to mean "Go back to the home scene", with the home scene configured in the project settings to be Fray's End in normal versions and something else in the SQ kit.

Aha, yes I see now. This could be a new boolean export, and in _validate_property() we can disable the "next_scene" property with the read-only flag: property.usage |= PROPERTY_USAGE_READ_ONLY.