Oh no! I’m about to start learning and developing in Twine. Problem is, I’m terrible at learning new things, and I apologize in advance to this board.
I have 4 questions :
Is there an article anywhere that points out the differences between the various flavors of Twine (Sugarcube, Harlowe, Snowman…etc) and can guide me in the right direction to choose the right one for my WIP? Are there any other templates I should be aware of that are non-standard?
Where is the best place to go for 101 type tutorials? I’m looking on the Twinery site and seeing a bunch of recipes, but, you know, eek.
Are there any good free articles on styling and UI in Twine - specifically as it relates to the container (i.e. the menu and all the other non-story elements of the page)
Is it possible, in Twine, to edit the game files directly? I’ve looked for an answer on this - so can I go into some form of index.html (or game.js or whatever) and edit the code for the game in situ without editing in the Twine editor.
I’ve looked for answers for these on this board, but am struggling! Thanks in advance for any help!
There’s the (very brief) Twine wiki page. If in doubt, use SugarCube? My impression is that Harlowe disallows custom JavaScript and has no way to add custom extensions, and that it doesn’t have any particular advantages. Snowman is a minimal format for using raw JavaScript (with jQuery, underscore, and Marked) so if you’re a web developer it may be the most convenient but otherwise it’s probably not what you’re looking for.
Styling (as most other things) is specific to the story format. I’m not aware of any good articles, though they may be out there. I usually poke around in the browser’s inspection tools (Ctrl-Shift-I or maybe right-click and inspect element). SugarCube has a StoryInterface special passage where you can put raw HTML to replace the whole interface, and functions to hide or completely remove the sidebar (you can still call the save/load and history functions from code). If you have specific questions you can often get answers here in a matter of hours.
The Twine editor is pretty unfriendly to external editing, but you can write text files in the Twee format (as shown in the Twine Cookbook examples), and there are several compilers: Tweego, Twee2, Extwee. They’re all slightly different in which options they take and how you pass your input files and so on. I’m not super happy with any of them, but I’ve been using Tweego. Extwee looks promising, but I haven’t gotten around to actually trying it yet.
Chapel’s “Twine Resources” page has a bunch of useful information, including a section which briefly discusses most of the Twine story formats.
That said, I really don’t see much reason to use anything other than the SugarCube story format. It’s able to do anything any of the other story formats can do, it has a bunch of useful built-in tools, some of which aren’t found in any other story format, and it’s usable by beginners and advanced developers alike. It really should be the default Twine format, especially since Harlowe has a bit of a complexity ceiling, and then you have to either learn SugarCube or work around Harlowe’s limitations.
Furthermore, you’ll find more sample code for SugarCube than any other story format, though Harlowe isn’t far behind. Any other story formats have very little in the way of tutorials or sample code.
I second Josh’s suggestion of Allison Parrish’s article for beginning Twine users. Additionally, I’d recommend importing Twine games into Twine so you can see how they work. If there’s something neat you see in a Twine game, you can usually just import it into Twine to see how that was done, and then you can do something like that in your own code. (Though, for Twine 1 stories you’ll need to convert them to the Twine 2 format before you can import them into Twine 2. You can find a “Twine 1 compiled HTML to Twine 2 archive converter” in the Utilities section on the SugarCube 2 page.)
Really, the pages are all CSS and HTML. If you want to figure out how to style that, you can look up tutorials on styling using CSS and HTML. As Josh mentioned, right-clicking on things on the page and then doing “Inspect Element” to look at and play with the CSS and HTML will teach you a lot. Just copy any CSS changes you make in the inspector into your game’s Stylesheet section, and then your game will have that styling.
Yes, but it generally adds needless complications. Twine outputs a single HTML file, so everything is contained in that one file. Any edits you do to that HTML file would have to be done every time you exported your story from Twine, so it makes more sense to simply make those edits within Twine itself.
That said, for things like JavaScript code, I do use VSCode (Visual Studio Code) to edit that, and then I simply paste it all into the JavaScript section of the Twine story.
Based on the project notes on GitHub, it looks like they’re finally going to be getting around to updating the rather horrible text editor soon, so hopefully that will help.
As to editing the text externally, the best thing that works for me is indeed using a plain text editor. I write everything into its own individual file using NotePad++ and organize it all into folders and such. Then, it’s just a matter of copying and pasting into Twine’s editor whenever you make changes. I do this for everything: the Story JavaScript, the CSS, and each individual passage. You end up with a lot of different files, but it’s both a lot easier to work with and safer (Twine’s “undo” feature doesn’t really seem to work, so if you accidentally delete an entire passage or something like that, it’s gone).
I’m glad to hear they are planning to improve the in-program text editor. I hope it’s more accessible, too: my screen-reader thinks the entire box is blank when I try to navigate around in the current one, so using an external text editor is actually required for me, not just more effective.
I’ve been prodding the developer to work more on accessibility, so there should be a few improvements in that area in the next version, though it will still need more work beyond that.
Hi, @McTavish. I’m the managing editor of the Twine Cookbook. What changes would best help you with learning more about Twine? We are very open to feedback on how best to help people navigate the large collection of examples and informational pages.
It was mentioned by @JoshGrams, but Extwee might be a good fit if you are used to VSCode and writing JavaScript. It has an API of all of its major objects in its README and also on its NPMJS page. (But, you know, I’m also a little bias as its author.)
The cookbook is an awesome resource! But I guess, like all cookbooks, it’s expects me to have some knowledge of what I’m doing. What would be massively useful (for me) is a full on tutorial of an example game - which, basically, creates a game and during the tutorial links to each section of the cookbook to show the context of each section.
When I started out, I found a series of videos on YouTube that were helpful. You might want to try searching for Twine SugarCube tutorials on there. Some of the stuff might be a bit outdated, as I believe was mentioned above, but enough of it is still relevant to get you thinking in the right context. There are even a couple where the individual will actually create a simple game and walk you through the steps.
That’s good feedback. I’ve added that to our Issues and assigned myself. I’ll play around with the idea and see if I can add something for the next update in January 2020.
So, probably a really stupid question, but I’m looking at the Twee section in the cookbook. It says :
" In Twine 1, stories could be exported into its source, changed, and imported again. Twine 2 has moved away from this functionality, but has been heavily influenced through having sections (passages in Twine 1) where the user can add…"
But then in the next section, it goes on to say :
“Starting with Twee 3, there is a standard for reading and writing Twee when working with Twine 2 passages.”
What’s the difference between a Section and a Passage? Does T2 work with Sections? How do I define a ‘section’?
I think the rest of that sentence is crucial, “having sections (passages in Twine 1) where the user can add CSS (Story Stylesheet) and JavaScript (Story JavaScript).” I’m pretty sure that “sections” just refers to those two things. In the Twine editor they’re not accessed as passages, but through the menu in the bottom left of the story view.
In Twee, the way you define custom JavaScript and CSS is (or at least used to be) different between the different compilers. It looks like Twee 3 defines passage tags stylesheet and script. And…apparently the latest version of Tweego does support them but it will automatically bundle any .js and .css files that it finds, so you probably don’t need them for Tweego.
I imagine @videlais will chime in if I’m misinterpreting the Cookbook, and give the info about Extwee that I was too lazy to look up…
Right, so, I’m at fault for the wording there. What I was trying to explain, poorly, is the connection between how Twine 2 thinks about parts of a story and how Twee (3) does.
Within the Story Menu of Twine 2 there are options like Story JavaScript and Story Stylesheet. These are what I meant by “sections.”
In Twee, however, everything is a passage. There are some special reserved passage and tag names, but everything is in one passage or another.
What would be editing the Story JavaScript in Twine 2 would be writing a passage with the script tag in Twee. That’s the difference.
The specification lists all of the reserved passage and tag names. When working with TweeGo or Extwee, you will need at least Start and StoryData passages to begin. You should have a StoryTitle passage, but it is not required by the specification. (I don’t know, off the top of my head, if TweeGo will give you a warning if you don’t have a StoryTitle passage, but Extwee will just make it undefined.)
The specification is aimed much more at those developing compilers than users. One of us (maybe me) will get around to writing a guide to using Twee 3 for beginners or less technical users at some point.
I’ve tried to make Extwee as similar to TweeGo as I can. It will also look for JS, CSS, and even Twee files and attempt to read and prepare them all.
TweeGo is more user-friendly as a tool than Extwee is, but I’ve tried to design parts so that they could be broken apart and integrated into others projects that wanted to, say, just produce Twee from some other source or be able to read Twine 2 HTML files and then do something with the object that is created from that process.
The hope was that people could use it as part of a toolchain process or larger workflow using JavaScript.
That said, Chapbook is in its infancy, so I wouldn’t recommend it unless you have some very specific needs that it satisfies.
For those experienced with Twine story formats, SugarCube is the hands-down winner. It’s no harder to use than Harlowe, but has more flexibility and built-in tools than Harlowe. It’s also either tied or slightly ahead of Harlowe in terms of sample code and documentation.
Anyways, if you still have Chapbook questions, I’d recommend starting a new thread for them, rather than necroposting in a thread that’s been dead for 9+ months.
My impression is that Harlowe disallows custom JavaScript and has no way to add custom extensions, and that it doesn’t have any particular advantages. Snowman is a minimal format for using raw JavaScript (with jQuery, underscore, and Marked) so if you’re a web developer it may be the most convenient but otherwise it’s probably not what you’re looking for.
