Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Twine 2.0.2 is released
So I think we're ready to begin real testing of Twine 2.0. Obviously, this has been in-progress for some time, but I think we've hit the point where it will be helpful to get a broader base of testers. I would not depend on this release for a big project, but in my testing over the past few months, I have not see any issues that caused data loss. At the same time, I think it would be very prudent to save any work to a file often.
Enough disclaimers, how can I get my hands on this?
You can either download it for offline work here: https://bitbucket.org/klembot/twinejs/downloads (choose twine-2.0p2.zip)
Or you can play with it online here: http://twinery.org/2
Inevitably, there will be tweaks before preview 3. (Right before I wrote this post, a pull request came in to fix a potential bug!) If you want to try the bleeding edge, you will be able to do so here:
Offline: https://bitbucket.org/klembot/twinejs/downloads#tag-downloads (choose the tip version)
Online: http://twinery.org/2test
I will be updating these pretty regularly, so be sure to bring a hard hat! I will be doing my best not to upload broken versions, but you never know.
If you grab the tip version off Bitbucket, you'll need to do some work to get it working -- see the repository readme for details. If you're never used Node.js before, you may just want to use the online version.
So is this replacing Twine 1.4?
I see these two versions co-existing for a while, at the very least. As you will see, not every feature from 1.x has made it into 2.x yet. Some will eventually do so, some won't. If you end up preferring 1.x, I won't be offended!
How do I report a bug or suggest an improvement?
Do that over at the bug tracker. I will be interpreting the number of watchers on a bug as a rough metric as to how much important it is to the community, so that's the best way to influence priorities.
Wait, you said some features aren't going to make it from 1.x to 2. What does that mean?
There are three main reasons that I've been making changes during the 2.0 development process. First is improving what I view as broken or annoying behavior. For example, you can now set a story title through the GUI instead of using a specially-named passage. Secondly, I'm trying to remove unnecessary complexity. An example of this would be zoom settings -- instead of zoom in/zoom out, there are just three zoom settings that correspond to levels of detail.
Finally, I'm also making changes so that Twine 2.0 is usable on a touch-based interface, e.g. tablets. That's why, right now, you can't marquee select passages by dragging, because that's the same interface gesture that a touch-based device would use to scroll around. I totally recognize the need to select more than one passage at a time, but I don't yet have an alternate UI for that. I do see that as a problem that needs to be solved.
Whew, I think that's it! I hope you enjoy trying it out.
Enough disclaimers, how can I get my hands on this?
You can either download it for offline work here: https://bitbucket.org/klembot/twinejs/downloads (choose twine-2.0p2.zip)
Or you can play with it online here: http://twinery.org/2
Inevitably, there will be tweaks before preview 3. (Right before I wrote this post, a pull request came in to fix a potential bug!) If you want to try the bleeding edge, you will be able to do so here:
Offline: https://bitbucket.org/klembot/twinejs/downloads#tag-downloads (choose the tip version)
Online: http://twinery.org/2test
I will be updating these pretty regularly, so be sure to bring a hard hat! I will be doing my best not to upload broken versions, but you never know.
If you grab the tip version off Bitbucket, you'll need to do some work to get it working -- see the repository readme for details. If you're never used Node.js before, you may just want to use the online version.
So is this replacing Twine 1.4?
I see these two versions co-existing for a while, at the very least. As you will see, not every feature from 1.x has made it into 2.x yet. Some will eventually do so, some won't. If you end up preferring 1.x, I won't be offended!
How do I report a bug or suggest an improvement?
Do that over at the bug tracker. I will be interpreting the number of watchers on a bug as a rough metric as to how much important it is to the community, so that's the best way to influence priorities.
Wait, you said some features aren't going to make it from 1.x to 2. What does that mean?
There are three main reasons that I've been making changes during the 2.0 development process. First is improving what I view as broken or annoying behavior. For example, you can now set a story title through the GUI instead of using a specially-named passage. Secondly, I'm trying to remove unnecessary complexity. An example of this would be zoom settings -- instead of zoom in/zoom out, there are just three zoom settings that correspond to levels of detail.
Finally, I'm also making changes so that Twine 2.0 is usable on a touch-based interface, e.g. tablets. That's why, right now, you can't marquee select passages by dragging, because that's the same interface gesture that a touch-based device would use to scroll around. I totally recognize the need to select more than one passage at a time, but I don't yet have an alternate UI for that. I do see that as a problem that needs to be solved.
Whew, I think that's it! I hope you enjoy trying it out.
Comments
I WILL LOVE YOU FOREVER. ;D ;D ;D
If you mean you're not sure how best to do that for touch devices, and presuming pinching won't be used to zoom based on how you describe zoom working, one solution for this would be to place two fingers on the screen and drag them to make a selection box. Obviously this only allows to select in a rectangle. For more freedom, how about one double taps on a blankspace to start multiple selection, a little box pops up saying something like "select passages now, tap here when finished". The user can then tap each passage they want to select, click on the pop-up when they're done, and then move/delete/whatever them at once. This solution could also work with a mouse.
A second possible solution is to copy the method used to highlight text on touch screens. eg. you tap on a word once. then you drag the dot to highlight the rest of the text.
NOTE: In Twine 1.4 the passage frame widgets are not drag resizable, I am assuming that Twine 2 is similar.
You could get the user to select the first passage widget, causing it to be surrounded in 4 (sides only) or 8 (corners as well) 'dots'.
The user could then drag a dot in the related direction which would result in other passages also being selected.
The two upsides are that firstly this is a technique that the touch screen people would already be used to, and secondly it should also work with a mouse.
I'm writing a game in Twine (1.4) that has a lot of dynamic behavior and a problem I'm encountering is that the flow of the code and the flow of the story difficult to follow because of the syntax: the code can't be formatted for optimal readability because that would break the formatting of the story, while the story is hard to read because there is so much code mixed in. Hooks would allow to separate the code from the story.
However, if the code is separate (inside the same passage but not inside the same paragraph), there is no real reason to stick with the slightly awkward macro syntax. For one, it is pretty verbose, with "<<" and ">>" surrounding every macro name and many requiring a close tag as well. Also the existence of shortcuts like "<<click-append>>" is only necessary because there is no convenient way to attach a processing instruction to an event.
Let's take this modified example from Leon's page: (I changed the close tag to read "click-replace" instead of just "replace" and I added the backslash to eat the newline. I don't know if the latter is needed with Harlowe, but with SugarCube having newlines at the end of a passage will lengthen the separation line between the main content and the side bar.)
Ideally I'd like to write code like this: I'm using "--" here as a separator between story and code; it can be any unique string. Since the code is in a separate section now, there is much more freedom to choose a syntax for it. I picked something CSS-like here: selector { event: action }, but maybe with the right convenience functions it could be JavaScript instead: (It probably won't work exactly like that.)
Having inline macros like <<if>> and <<print>> is useful, but for many of the other macros having them inlined in the story is a disadvantage. The hooks mechanism makes it possible to have a reduced set of inline macros and deal with most dynamic behavior in a code section (or multiple) within the passage.
Basically, I'm wondering how you would write a setter link in version 2. In 1.4 you could write it like this: However, this doesn't appear to work in Twine 2.0. The passage is named as 'passage1$variable to "foo"'.
This works for one word links: but this doesn't work: Is this something that will be introduced, or will there be a different way of doing it entirely? I know this is a work in progress, so I'm not expecting all the functionality of 1.4 to appear in 2.0 right now, but I guess most of it would be included eventually?
Also, regarding stylesheets...I've tried using a stylesheet from a 1.4 project, and it seems to work except for using background images - how would you recommend that we use background images in 2.0?
I tried saving the image in the same directory as the index file and calling it via url('background.jpg') but that didn't work.
1) The ability to connect an external server (LDAP based) for user authentication.
2) The ability to set up access controls so I can say who can play, read the source for and edit each story. Note that being able to be played by unregistered users is a separate access to being able to be played by specific registered users. There should be a way to configure it so 'playable by unregistered users' defaults to off (and cannot be turned on) for all users.
3) Multiple editors for each story
4) Multiple concurrent editors for each story (passage level locking, not story level locking), updates being dynamically reflects to all current editors.
5) Reviewer functions? (Ability to add comments/critiques to a story (probably per passage), possibly a level of access between Read and Edit).
6) A story template library? Could be done with read only stories, but a template library sounds better.
7) Ability to download the compiled html for a story so it can be hosted/distributed outside of the Twine Authoring environment. The author should be able to restrict the access level at which this can happen or it should be a separate access right - Download.
8) The ability to Publish a story should be a separate right, typically, but not necessarily, granted to all editors.
9) The ability to put #tags on a story and to sort/filter the stories you can see by #tag. A bit of autotagging by author wouldn't hurt - #sharpe #play would show me all the sharpe stories I can play.
10) Feedback mechanism (not the detailed in story review) allowing readers to leave comments on a story?
I'm not expecting any of these in the near future, but they might help shape your thinking about where Twine on a web server could go...
You are aware that currently the stories you create in Twine 2 are stored on your local machine within your browser's storage and not on the web-server even when running via a remote web-server.
It is currently a stand-alone app similar to Twine 1.4 except instead of being written in Python it is written using HTML and Java-script.
The point of making Twine 2 a browser-based app -- and I'm using that phrase intentionally here instead of server-based -- is that it eliminates many cross-platform issues, and it provides a means for people to use Twine on tablets (and perhaps phones, if you are particularly brave). Maintaining four versions of a Twine app at the least -- Mac, Windows, iOS, and Android -- is infeasible given the number of people working on it, in my opinion. Leon has a hard enough task just keeping up Mac and Windows versions of Twine 1.4. I personally think that browser capabilities have advanced to the point that they can accomplish the things that Twine needs just as much as an app can.
The reason why I posted the app to twinery.org is so that people can try it out for themselves, and to make it accessible to tablet users period.
mykael, I think the vision you are articulating is an interesting one-- it is just one that I don't think is possible right now given the small group of people working on Twine out of the goodness of their hearts. If someone were to appear with a wheelbarrow of money and asked me to assemble a team to work on it fulltime, then the calculation might change. And if someone wanted to assemble a team themselves to work on that project, I would do whatever was reasonable to help them out.
One of my goals working on the single-user-oriented version of Twine is to avoid decisions that would make it hard to adapt to the multi-user scenario you're describing. I think of it almost as a reference implementation in that respect.
Maybe once you've got it running to local storage we could look at the google cloud storage API or some such. See if we can get google to directly charge the user rather than the server host...
I've independently proposed this idea to Chris myself - the idea that the passage editor (and thus the passage data structure) be divided into a "text section" above, and a "silent section" below, where all the code in the silent section behaves like it's in a <<silently>> macro. There isn't yet any implementation, though.
As for different macro syntax inside the "silent section"... I have been contemplating some kind of "block syntax" for macro tags that lets you forgo the "<<" and ">>" and separate them by other means, but I haven't yet thought of anything I'm satisfied with, and that doesn't seem like an unintuitive departure from the normal style of macro tags.
(One advantage to leaving the macro syntax in its verbose form, I guess, is that the silent section could also have comments interleaved in it in the form of plain text. (Not that people comment their Twine code that often, though.))
One suggestion is that you should be able to make the link become a hook by doing [[Link text->Passage name]][a]... but I'm a bit dissatisfied by the fact that the [ ] brackets have multiple different meanings, so close together.
Another suggestion is to make links be "implicit hooks", that can be immediately referred to by a new sigil or something... but there's a lot of possibilities for this. <<click [[Passage name]]>> ? <<click [[Link text]]>> ? <<click link 1>>? (I dislike the idea of referring to hooks by text location rather than their actual features.) <<click link "Link text">> ? <<click "Link text" in links>> ? (I hesitate to add an all-new "in" keyword without thinking how it'd work for any other macro.)
I agree with you there. I've looked into the possibility of saving to Dropbox or Google Drive from the editor, but there would need to be some server-side code to facilitate that-- same-origin policy prevents JS from talking to the Google Drive API directly, and Dropbox's Saver interface wants you to give it a temporary URL to download from. I'm not an expert on either API, however, so there might be a workaround!
If the Author has the Dropbox Application installed on their machine/device of choice (as long as it is not iOS based) then you could implement an Import/Export feature. (like SugarCube's "Save to Disk" / "Load from Disk")
This would allow Authors to load/save the contents of their story to a file in their local dropbox directory/folder.
Regions as tags
It's become clear to me that passage tags ought to come back, due to the variegated benefits that Twine 1.4 has given them. But I've been thinking of a new way to tag passages: draw a rectangle over the Story Map, and give it a colour and a name. Any passage inside that laid-down rectangle is considered to have that rectangle's name as a tag. You can thus tag passages by dragging them off and onto the rectangle, or moving the rectangle around. If you want to tag two very separate passages with the same tag, simply duplicate the rectangle and lay it down over there. What do you think of this idea?
Stylesheet passages
Throughout early development of Twine 2, it was assumed that all of the "special passages" - StoryTitle, StorySettings, the script passages, etc. - would be peeled off the Story Map and placed in separate side-menus, as single text blocks. However, I feel like maybe in the case of certain "scoped assets" - and I'm thinking here of tagged stylesheets - there'd be call for putting them back on the map, so that they can, as in Twine 1, be arranged alongside the passages that use them. This relates to the "regions" idea - the idea of the Story Map as game asset organisation as well as story structure organisation.
I'd love to be able to put, for example, all my "town" passages on one tab, all my "overworld" passages on another, all my "dungeon" passages on another, all my "combat" passages on another, etc.
Not a big deal or anything. Just throwing that out there. I think I've heard it requested before, too.
That sounds really cool!
I like the idea of just having special passages be menu options. That's cool. And, yeah, style sheets could certainly be an exception to that for reasons mentioned.
However, you could also just maybe have a check box or whatever by the style sheet on the menu to go with your regions idea. Either way.
However, could I request an option to make style sheets include the default CSS rather than just appear blank? I request that for a quite number of reasons. "It will scare newbies" is overridden by, "It will make newbies lives hell trying to figure out why the CSS isn't working due to conflicts," IMO. Just saying.
Though this sounds cool, I can see two possible issues:
1. Passages that need multiple tags, would the passage need to be in more than one region.
2. The screen background could become quite messy depending on the number and size of these regions. A region could easily cover multiple viewports worth of screen real estate, or do you plan to add scroll bars to the region?
I think that giving the Authors the ability to "view" the default CSS is a good idea, however making it directly editable could result in a broken default stylesheet. How would the application help them undo a bad change to the defaults?
- No tags
- No find/replace
- Can't copy/paste passages, in particular several at once
- Can't plug in templates, e.g. Sugarcube
... but I bet there are others.Not sure how I feel about regions -- I like the idea of graphically representing things like tags, but I wonder if it has the potential to create monstrous Venn diagram-ish things.
I get why you would want to see the built-in CSS for a template, but there are two somewhat ugly possibilities with the implementation:
- You allow people to mess up the built-in CSS-- then you have to give people a way to restore that.
- Outputted stories contain redundant CSS -- the user-tweaked version and then the original CSS.
I think there definitely need to be mechanisms in Twine to make large-scale stories easier to work with. Here's what I've thought about:[list type=decimal]
Create a new stylesheet and delete the old one, which is how one currently restores default CSS.
I don't see a big problem with this. I do see a big problem with conflicting CSS, and that happens all the time in 1.x.
I don't think tabs in Twine would be any more limited by the user's browser window than they already are, and no one would have to use them. You can put everything on one tab, just like you don't have to make new tabs while browsing the Internet.
Just my opinions!
A small difference between tabs in the browser and ones within a HTML page is that the ones in the the browser are separate DOM's so you dont have to worry about things in one tab effecting other tabs.
Tabs within HTML pages are just a visual effect, so to make sure one tab did not effect the others the existing code would need to be restructured to sandbox each tabs' properties. (tab title, passages list; maybe storage file name; etc)
I have used ER / Class modelers that have implemented this by visually showing an external sub-model file (list of passages) within the current/parent model as a single table/class widget (coloured differently) to represent the whole external sub-model. When you double clicked on the widget it would open the sub-model in a new window.
Moving items between windows was done either via drag-n-drop or by right clicking on the widget (or pre-selected group of widget) and using a "move to sub-model" feature.
Regions I'm not so keen on. Yes, there are regions of contiguously tagged passages - but that's not necessarily so and, as Greyelf said, it gets messy when I want to start adding multiple tags to a passage.
The whole reason I like the concept of tabs is to unclutter and organize the work space and have more room to display passages. With that system, you still wouldn't be able to place passages on top of passages (nor would you want to do so!), so it does nothing to further any of those ends, in my opinion.
I want tabs for more room, so I'm opposed to the argument that it would make less room.
Yeah, on second thought, it sounded cool, but there's just not enough work space to have multiple regions without a bunch of scrolling and the addition of multiple tags makes it a difficult reality to implement. Anyway, 99 of 100 of my passages all have the same tag: "nobr". Those that don't wouldn't need to be placed in a separate area. Not saying the fact that I personally wouldn't use it is a good argument against it, though. I understand that things for which I have no use doesn't mean others wouldn't get a lot of use out of them.
All just my opinion. I like Twine enough how it is now.
What you could do is add an easy way to add/remove tags from selected passages. Then you can use a rectangular selection to tag grouped passages at once.
Using colors to visualize tags is a good idea in my opinion and will become more feasible when there are fewer types of special passages, since that would free up colors for the user to assign.
Thanks, I tried something like this: But it didn't work, the 'a' becomes a separate click able link.
I also tried: This generated a new linked node, but the actual link 'passage name' didn't show up in the screen when testing. Though I think you were just suggesting a way of writing this, rather than giving a working suggestion.
I do like the suggestion of having the window split, one into text and another into the actual 'silent' code. It seems a lot cleaner to me.
A <<render>> macro for extending formatting syntax
@ inline-style syntax - both fairly verbose.
What this macro will do is allow you to select text by defining new markup patterns: (They keywords "text" and "thus." are quite tentative.)
What these do is define new markup syntax extensions, and accompanying CSS attributes to apply to the markup. But, you could also use it to override or extend current markup styles: The author's familiarity with the markup syntax is thus directly transferable to use of this macro.
You may note that one of the above examples only specifies "bold" and "italic" as attributes. I'm thinking, to aid authoring, that for certain property values that the CSS spec ties to a single property (such as "bold" for "font-weight", and "super" for "vertical-align"), the property name can be omitted. These would be a small set of very common values (mostly bold, italic, centering, capitalize, etc.).
You can use this in single passages to apply styles just to this page, or you could put it in, hmm, some kind of "transclusion" passage* to make it apply globally all over the story.
I'm also thinking of a slightly different kind: That is, as a hook/pseudo-hook macro. I feel like this should also be possible, but maybe as a different macro. Maybe this should be called "render" or "present", and the other one "stylise" or "define" ?
*Something that, perhaps, contains only a silent area, which has the same inclusion functionality that Twine 1's stylesheets have - global, or local to a tag if it bears one. Call it an "appendix" or "glossary" passage?
[quote]The whole reason I like the concept of tabs is to unclutter and organize the work space and have more room to display passages. With that system, you still wouldn't be able to place passages on top of passages (nor would you want to do so!), so it does nothing to further any of those ends, in my opinion.
I want tabs for more room, so I'm opposed to the argument that it would make less room.
Well, you might need to add a smarter auto-layout algorithm and a way of defining a set of filter settings and a layout as a view. Either remembering where you've put things for each different filter setting, simply leaving things where they are or auto-packing them in some way. As you say, simply leaving them in place and hiding everything else in the big display isn't going to work so well.
View 1 - everything except macros and style sheets
View 2 - only macros (default layout overridden)
View 3 - only style sheets (default layout overridden)
View 4 - only campsites and inns (default layout, view 1 as a grey scale backdrop)
I know this might be a bit late, and I've probably misunderstood, but there's not really a need for an API when saving to mobile devices/PCs when using Google Drive. I have several PCs I use, including one that I use purely for working away from home. At home I have the ability to save everything onto my file server so it's not an issue, but it means I have to sync the laptop with anything I want to take with me and as I can literally be called out with 2 hours notice I prefer to have clothes over my Twine stories lol.
If you install the Google Drive PC program on your PC it creates a folder that works like a normal folder (so things can be saved to it) except it syncs to the cloud. If you have the app on your phone/tablet as well then they will sync too and it's a doddle to just up it to Drive anyway. I do actually use this system and not just for Twine so it works really well. The only problem I could see with it is the fact that it requires additional software installed on a PC and if you don't have admin rights (work/library PC etc) then it would be a non-starter.
If I've got this wrong and not understood fully, then I apologise, but I've just mentioned it in case anyone didn't know about the PC app.
I'm of two minds on this new idea but I suggest that if you do implement it you don't name the macro render.
As the macro is designed to extending formatting syntax, maybe naming it style or format would be better.
No need to apologize, the process of file syncing you described is a good one and it works well with the desktop application version of Twine because it saves your story content within a TWS file in a location of your choice.
Unfortunately this not the case with the future HTML version of Twine as it uses a feature built into the web-browser to store your story content in the browser's own internal storage area. So this is why a means to copy the story contents from the browser's internal storage to some other location is needed.
I'm guessing using a wrapper like PhoneGap wouldn't simplify things, at least in regards to phones and tablets in order to save to local storage as an actual app. I can also foresee people with Apple devices would have no end of problems installing it as an app unless they were on jailbroken devices, or an account was made with the app store which can be pretty costly. Android devices wouldn't have an issue if they enabled the "Unknown Sources" for app installation.