Project folder structure

[lpmathiasendk]

Is your feature request related to a problem? Please describe.

It Works

Desktop Twine for Mac is working very nice, but as a programmer I think the lack of a project folder structure is something it really need to have corrected. Just like all other game design systems folders like assets, scripts and so on will enhance the developer experience. Also it should be here the preview server point to for internal links. The twee export will also refer to this.

My Case

In my workflow I would have the Twine story as a module to my Kotlin project so I can write my Twine content and work on my UI at the same time. If the preview server points at the project root it is possible to work in a iterative manner adding pictures, external javascripts and the like.

Describe the solution you'd like.

A Solution

I suggest an implementation could be as simple as having a Twine project point to a project root folder of the developers choosing and as mentioned above have all internal links point to the project root.

Describe alternatives you've considered.

Simpler

I think my suggestion is a very simple one, so I haven’t any alternatives except as a simpler solution have a new Twine project make a project root folder in the Stories folder and have everything point at that. It will be a improvement but I think the freedom of choosing where to save a project is a huge improvement making it easier to include Twine in other kinds of projects.

Additional context on this suggestion.

It Will Help

This solution will make a lot of work after publishing redundant and fiddeling with links and routes as well. A whole lot easier workflow as an effect.

Presubmission checklist

• I am interested in working on code that would implement this feature request. (This is not required to submit a suggestion.)
• I have done a search and believe that an issue does not already exist for this idea in the GitHub repository.
• I have read and agree to abide by this project's Code of Conduct.

[klembot]

You can change where Twine looks for stories, and where preview stories are created, using command-line switches. I think that might help with your use case?

[lpmathiasendk]

Thanks Chris, but that was not my intention. I did have the intention it should be in the desktop app menu. 😃VenligstLars MathiasenDen 23. mar. 2024 kl. 18.43 skrev Chris Klimas ***@***.***>: You can change where Twine looks for stories, and where preview stories are created, using command-line switches. I think that might help with your use case? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[klembot]

Sorry, could you clarify more what you mean by:

I did have the intention it should be in the desktop app menu.

Do you mean that this functionality covers your needs, but you'd prefer it to be something you wouldn't need to use CLI switches for--or that what's there right now doesn't cover your needs?

[greyelf]

@lpmathiasendk
note: Just to be clear, the Desktop release of the Twine 2.x application automatically creates three different category of HTML file, each in a different location:

• the Project HTML files that store the Passage & meta data of a Project, these are found by default in the Twine\Stories folder.
• the Backup HTML files, which are snapshot copies of the Project HTML files, and these are found by default in the Twine\Backups folder.
• the temporary Story HTML files generated by the Play and "Test" related options, which are either found in the Operating System's Temporary file area (pre v2.8.0); or the Twine\scratch folder (v2.8.0 and later).

a Twine project point to a project root folder of the developers choosing

Do you mean:

• That all Twine Projects point to the same root folder, of the developer's choosing. In which case, the command-line switches mentioned by klembot can be used to control where each of the three different category of HTML file are stored.
• That the developer can configure each individual Twine project to point to its own custom root folder, if so which of the three different category of HTML file should be stored in that root folder & where in that root folder?

[lpmathiasendk]

That might be more that I know about, but yes and no. I am just talking about the project HTML and all assets like images and so on and the temporary story in the same project folder maybe in another subfolder, but again yes it would make sense to have the backups at hand also, like a versioning system. I would normally save the project files in one subfolder like “src” and any generated code in another like “target” or “bin” in Twines case it might be better to use a more intuitive syntax like story and published. Anyway it’s all about having a known and by the author chosen project library and a sub structure that is intuitive and easy to integrate into other projects like in my case Kotlin but also React, JS or NodeJS projects. For project initiation I use Gradle - and if Twine came with its own project structure I would add that to “IntelliJ add module to project” option that use Gradle to add the structure to automatic creation.  Then I would start up Twine and open the new empty story and have it saved to my project structure. See below. I hope I explained clear enough? It is my hope to get the selfhosted version of Twine up and running on my Mac to be used on my iPad over wifi to work on the same story there as on my Mac. Right now i use JumpDesktop on iPad to edit my Twine content on my Mac, but a on-device UI is way better. BUT - Imagine if the Electron version of Twine could start a node server and then it was only a matter of writing mymac.local in my iPad browser and I could continue my work in my big soft chair using my iPad. I have that setup for other systems and I use CloudFlare tunnels to work away from my Mac on my iPad. This is an example of how I imagine my project folder tree with Twine as a module:Here is the isolated Twine structuere:Here is a more functional example:Sorry for the MyStory.twine files. I had ChatGPT drawing up the ASCII trees and it insisted on that this was the format. :-)I hope this was not too confusing. I know I sometimes come over somewhat nerdy. VenligstLars MathiasenDen 23. mar. 2024 kl. 22.06 skrev Greyelf ***@***.***>: @lpmathiasendk note: Just to be clear, the Desktop release of the Twine 2.x application automatically creates three different category of HTML file, each in a different location: the Project HTML files that store the Passage & meta data of a Project, these are found by default in the Twine\Stories folder. the Backup HTML files, which are snapshot copies of the Project HTML files, and these are found by default in the Twine\Backups folder. the temporary Story HTML files generated by the Play and "Test" related options, which are either found in the Operating System's Temporary file area (pre v2.8.0); or the Twine\scratch folder (v2.8.0 and later). a Twine project point to a project root folder of the developers choosing Do you mean: That all Twine Projects point to the same root folder, of the developer's choosing. In which case, the command-line switches mentioned by klembot can be used to control where each of the three different category of HTML file are stored. That the developer can configure each individual Twine project to point to its own custom root folder, if so which of the three different category of HTML file should be stored in that root folder & where in that root folder? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[greyelf]

@lpmathiasendk
It sounds like your work-flow would be better suited to a Twee Notation based project, rather than a Twine application based one.

That way could store the project's Twee (text-based) files where ever you like, and then use a Twee compiler like TweeGo to generate a Story HTML file from those files.

note: If you do decide to switch to a Twee Notation based project and need access to a visual Story Map, and you're using the Visual Studio Code text editor, then checkout the Twee 3 Language Tools extension by cyrusfirheir.

[lpmathiasendk]

I do have that workflow with Textastic on my iPad. I really enjoy using the twee language but the graphic nodes are a huge help in debugging a narrative and that UI require a computer for the desktop app. I have imported my twee code into Twine often on my Mac. I like working with the nodes because they provide another perspective on the storylines. Also Twine provide a nice mockup of the finished product. I have no critique of Twine - only a suggestion to improve its usability. Modern tools adapt to each other a come together as a toolbox of synergetic tools with the least friction possible and fastest workflow. Twine is no exception and it could be so much more just with a few tweaks. Twine is in itself a collection of tools that make up a powerful application - a game-engine - that can be used for many things. I write non-fiction or instructional content. Twine is almost perfect for that use with its graphical view of a large amount of content wowed into a complex path. It’s beautiful. So in conclusion I just request that images and other content are shown in preview with their original links to avoid having to correct links in my final work today images shown in preview has different links than the final product and that a story is a project with its own root folder and folder structure so it easily can be used in other applications directly this is in reality just to add the save to folder functionality and everything end up in that folder and reference to that folder - story, assets, preview and backups. 👍 A typical “book” of mine has 200-300 assets. Often small SVG icons, screenshots, SVG charts and a lot of png images. Anyhow I appreciate that you take the time to give me feedback. I never expected anything. I just wanted to give my input. Venligst/KindlyLars Mathiasen Sendt fra min iPhoneDen 24. mar. 2024 kl. 22.32 skrev Greyelf ***@***.***>: @lpmathiasendk It sounds like your work-flow would be better suited to a Twee Notation based project, rather than a Twine application based one. That way could store the project's Twee (text-based) files where ever you like, and then use a Twee compiler like TweeGo to generate a Story HTML file from those files. note: If you do decide to switch to a Twee Notation based project and need access to a visual Story Map, and you're using the Visual Studio Code text editor, then checkout the Twee 3 Language Tools extension by cyrusfirheir. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[lpmathiasendk]

Helllo again Chris. I have made a Gradle script that use Twine command line switches to use Twine as a Kotlin module. Just experimental right now. The only issue I have now is how to manage project or story root folder so preview “src” links will remain the same in the entire process so no extra link management is needed. VenligstLars Mathiasen Sendt fra min iPhoneDen 25. mar. 2024 kl. 01.40 skrev Lars Mathiasen ***@***.***>:I do have that workflow with Textastic on my iPad. I really enjoy using the twee language but the graphic nodes are a huge help in debugging a narrative and that UI require a computer for the desktop app. I have imported my twee code into Twine often on my Mac. I like working with the nodes because they provide another perspective on the storylines. Also Twine provide a nice mockup of the finished product. I have no critique of Twine - only a suggestion to improve its usability. Modern tools adapt to each other a come together as a toolbox of synergetic tools with the least friction possible and fastest workflow. Twine is no exception and it could be so much more just with a few tweaks. Twine is in itself a collection of tools that make up a powerful application - a game-engine - that can be used for many things. I write non-fiction or instructional content. Twine is almost perfect for that use with its graphical view of a large amount of content wowed into a complex path. It’s beautiful. So in conclusion I just request that images and other content are shown in preview with their original links to avoid having to correct links in my final work today images shown in preview has different links than the final product and that a story is a project with its own root folder and folder structure so it easily can be used in other applications directly this is in reality just to add the save to folder functionality and everything end up in that folder and reference to that folder - story, assets, preview and backups. 👍 A typical “book” of mine has 200-300 assets. Often small SVG icons, screenshots, SVG charts and a lot of png images. Anyhow I appreciate that you take the time to give me feedback. I never expected anything. I just wanted to give my input. Venligst/KindlyLars Mathiasen Sendt fra min iPhoneDen 24. mar. 2024 kl. 22.32 skrev Greyelf ***@***.***>: @lpmathiasendk It sounds like your work-flow would be better suited to a Twee Notation based project, rather than a Twine application based one. That way could store the project's Twee (text-based) files where ever you like, and then use a Twee compiler like TweeGo to generate a Story HTML file from those files. note: If you do decide to switch to a Twee Notation based project and need access to a visual Story Map, and you're using the Visual Studio Code text editor, then checkout the Twee 3 Language Tools extension by cyrusfirheir. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[klembot]

I'll tag this as a "maybe" enhancement for now. The question to me is how this request could be generalized—I don't think many people using Twine are proficient with Gradle etc, so whatever we come up with would need to accommodate that.