Examples submitted for Harlowe 2.0 and SugarCube 2.18. (https://github.com/iftechfoundation/twine-cookbook/tree/master/timedpassages_videlais)

from twine-cookbook.

I wonder if the initialisation of the timer variable should be done within a startup tagged special passage in the Halowe example and a StoryInit special passage in the SugarCube example, instead on the story's main passage.

In the Harlowe case you will need to use some CSS targeting the relevant tw-include to suppress the visual output of the startup tagged passage.

tw-include[type="startup"]{
	display: none;
}

... I wonder if the hiding of the visual output of a startup tagged special passage should be it's own recipe?

from twine-cookbook.

That's a good point, @greyelf. I've just updated the Harlowe and SugarCube examples to use the startup tag and StoryInit passage as per your suggestions. I also added --

tw-sidebar { display:none; }

-- to the Harlowe example and --

<<script>> UIBar.destroy(); <</script>>

-- to the SuagrCube one to bring it more closely aligned with Anna Anthropy's original ideas of not being able to 'undo' or 'go back' once the timer runs out.

As for hiding the visual output of the startup tagged special passage being a recipe, I'm not sure. I can see it being useful, but I can also imagine, in the words of another, that it might be a "toy" too. Maybe we highlight it as part of examples like this to make sure it is covered somewhere?

from twine-cookbook.

The Startup passage in the Harlowe example doesn't need the Collapsing Whitespace Markup because it's visual output is suppressed by the related CSS rule.

from twine-cookbook.

True, @greyelf. Now fixed in both example and twee notation files.

from twine-cookbook.

Commentary on the SugarCube example

I'd strongly suggest placing special passages at the top (e.g. place StoryInit near StoryTitle) in the Twee examples. If they're exports from Twine 2 and you don't want to manually clean them up, I'd suggest Tweego or one of the other Twee compilers which are interoperable with Twine 2. (aside: Since Tweego is interoperable with both Twine 2 & 1, save for .tws files (because pickles), and it's a single static binary, it's not a bad idea to have it in your toolbox, period)

Please, do not place <<script>> macros in StoryInit unless somehow absolutely necessary. The proper place for initial JavaScript is the Story JavaScript or a script-tagged passage (when compiling to Twine 2 or Twine 1 story formats, respectively). This is largely true for any story format.

I'm not thrilled about the use of <<display>>, as it's been replaced by <<include>>. At this time, however, its use may be for the best. Preferably, I'd prefer to see <<include>> used with a note that <<display>> may be needed for older versions, but I'm not super adamant about that.

Calling UIbar.destroy() removes the UI bar for no good purpose here. Removing it neither hinders nor reduces the history and removes the other UI elements and controls provided by it. If you want to limit the history, then you should do that via the Config.history.maxStates. For example: (goes in Story JavaScript or a script-tagged passage)

/* Limit the history to a single state (no do overs). */
Config.history.maxStates = 1;

See Also

You can do something very similar to this, and much more simply, with the time() function (on point example at the link), though it does require additional player interaction.

[Edit] Commentary on the Harlowe example

Similar to the complaint about removing SugarCube's UI bar, you don't need to remove Harlowe's entire sidebar to remove its history controls. For example, the following style should do so:

tw-sidebar .undo, tw-sidebar .redo {
	display: none;
}

There are other ways to do that, but being specific is better I think.

from twine-cookbook.

I'd strongly suggest placing special passages at the top (e.g. place StoryInit near StoryTitle) in the Twee examples. If they're exports from Twine 2 and you don't want to manually clean them up, I'd suggest Tweego or one of the other Twee compilers which are interoperable with Twine 2. (aside: Since Tweego is interoperable with both Twine 2 & 1, save for .tws files (because pickles), and it's a single static binary, it's not a bad idea to have it in your toolbox, period)

I played with Tweego some just now and found it more work than I wanted to take on to simply export passages in a slightly different order than how Twine 1's export or the Entweedle story format for Twine 2 does. If this becomes an issue depending on how and what other people submit to this project, it might be worth adding it to the workflow for filling out each recipe.

If you feel it would improve readability, I encourage you to change the ordering. We are still settling into a standard way to do things on this. If this helps other people, I'd be happy to adjust things or step aside in order to improve future readability.

Please, do not place <<script>> macros in StoryInit unless somehow absolutely necessary. The proper place for initial JavaScript is the Story JavaScript or a script-tagged passage (when compiling to Twine 2 or Twine 1 story formats, respectively). This is largely true for any story format.

I'm not thrilled about the use of <>, as it's been replaced by <>. At this time, however, its use may be for the best. Preferably, I'd prefer to see <> used with a note that <> may be needed for older versions, but I'm not super adamant about that.

I made these two changes just now and updated the HTML and Twee versions for SugarCube.

Calling UIbar.destroy() removes the UI bar for no good purpose here. Removing it neither hinders nor reduces the history and removes the other UI elements and controls provided by it. If you want to limit the history, then you should do that via the Config.history.maxStates. For example: (goes in Story JavaScript or a script-tagged passage)

I agree about the functionality approach. Calling UIBar.destory() doesn't stop any of the other functionality from being used. However, it does bring the SuagrCube example in-line with the original game and the Harlowe example. They all look the same now.

You can do something very similar to this, and much more simply, with the time() function (on point example at the link), though it does require additional player interaction.

Does the time() function work for tracking time across passages easily? Without adding the difference after each passage transition?

Unless it doens't changes the code substantially, I'd say to leave it as it is. Looking between the Harlowe and SugarCube examples, a user can see how, for example, the (live:) and the <<repeat>> macro work in similar ways and how the code mirrors each other.

Similar to the complaint about removing SugarCube's UI bar, you don't need to remove Harlowe's entire sidebar to remove its history controls.

I don't need to, no. However, as I mentioned above, removing it brings the examples closer to the aesthetics of the original example that doesn't use any UI at all.

However, if we agree that the point is to keep the story format branding, then both what you wrote for this and the above use of UiBar.destory() does need to be changed. It's an issue, I'd say, of wanting to match the example or demonstrating examples while retaining the branding. I'm fine with both, but, and I agree with you here, it does need to be consistent.

from twine-cookbook.

As far as aping the style of Queers in Love at the End of the World. Perhaps I misunderstood him, however, Chris' original prompt was:

The player has a certain amount of time to click a link in a passage, or else they're automatically taken to another one. (c.f. Queers in Love at the End of the World).

Based on the prompt alone, it seemed to me that the example was meant to show how to do link with a timed failover goto. It mentions nothing about making the example exactly like Queers in Love at the End of the World. I assumed that he meant something along the lines of as is done there, rather than exactly like that.

Even if aping it exactly was the idea he had in mind, I'd suggest against that as a general rule. I think that it would behoove the eventual users of the cookbook to limit the examples to as few concepts at one time as possible. In other words, if the idea behind an example is "show how to do X" then that's what the example should show, not X and a bit of Y (unless you really cannot do X without a bit of Y).

/shrug

Tweego

I played with Tweego some just now and found it more work than I wanted to take on to simply export passages in a slightly different order than how Twine 1's export or the Entweedle story format for Twine 2 does.

Mea culpa. I think I've caused a misunderstanding here. The basic idea behind by original comment was that I think it would be better if the Twee examples had a bit of order to them, simply for the sake of reading by users (obviously, a compiler won't care about it).

When I said, "If they're exports from Twine 2 and you don't want to manually clean them up, I'd suggest Tweego or one of the other Twee compilers which are interoperable with Twine 2.", I meant that since you're exporting the Twee sources for the examples anyway, then you might as well simply do the examples in Twee notation in the first place. At that point, there would be no issues with passage ordering or anything else. You'd simply compile the Twee examples as-is with a Twee compiler to create the compiled HTML versions.

If the use of a graphical IDE is your want, then you could still use Twine 1 or Twine 2 for the basic task. After you do the initial export to Twee, and do any necessary clean up, you could use Tweego to recompile the live HTML examples from the updated Twee sources.

The reasons I suggested Tweego were because:

1. It compiles its sources exactly in the order they were specified, both on a per-file and a per-passage basis.
2. It's interoperable with both Twine 1 and Twine 2 story formats (AFAIK, it's the only Twee compiler that is), by which I mean two things: it can compile to either style of story format and it can use compiled HTML files compiled in either style (also Twine 2 story archives) as input sources.

Finally. Both using Twee, in general, and Tweego, specifically, were only a suggestions. I'm not attempting to dictate what tools you should be using.

from twine-cookbook.

About SugarCube's time()

Let me preface this by saying that I wasn't suggesting the use of time() for this example.

Does the time() function work for tracking time across passages easily? Without adding the difference after each passage transition?

I would have thought that the documentation at the link I provided would have made that clear. The answer is no.

The time() function returns how much time (in milliseconds) has passed since the currently navigated-to passage was displayed. Basically, how many milliseconds have passed since the player was shown the incoming passage.

Something along the lines of what I think you're asking about could be written, however, it wouldn't be absolutely exact in older browsers since they offered no monotonic time APIs (I believe that the time source provided by performance is monotonic, but I haven't read the spec yet; note to self: check on that). That said, the possible skew would only be on the order of a second (as the invocations could fall across a leap second) and would be rare. I'm unsure how useful it would be, however, since it would be the time since the current play session started, which developers can mostly do themselves (the only way I could better it would be to make it part of the session state, so page reloads wouldn't affect it).

Unless it doens't changes the code substantially, I'd say to leave it as it is. Looking between the Harlowe and SugarCube examples, a user can see how, for example, the (live:) and the <<repeat>> macro work in similar ways and how the code mirrors each other.

I was not suggesting converting the SugarCube example to the use of time(), mostly because it's not an active timer, which is kind of the point of this example. My "see also" mention of it was merely meant to note that something very similar, yet also much simpler, could be done with it (again, shown by the "Eaten by a grue" example at the provided link).

from twine-cookbook.

Even if aping it exactly was the idea he had in mind, I'd suggest against that as a general rule. I think that it would behoove the eventual users of the cookbook to limit the examples to as few concepts at one time as possible. In other words, if the idea behind an example is "show how to do X" then that's what the example should show, not X and a bit of Y (unless you really cannot do X without a bit of Y).

I'll wait to see if @klembot wants to weigh in on this, but I agree. If the point is the prompt, your suggestions are better. If it is to mimic the examples, we could probably also scale back to one concept at a time.

Tweego

I meant that since you're exporting the Twee sources for the examples anyway, then you might as well simply do the examples in Twee notation in the first place. At that point, there would be no issues with passage ordering or anything else. You'd simply compile the Twee examples as-is with a Twee compiler to create the compiled HTML versions.

Right. And, in fact, think the Google Fonts recipes I messed around with today would have been a great case for why using Tweego would have been a good idea since the Twee code is the same across all of the story formats and merely needed to be compiled into various examples. (Would have saved me the time in making all those examples, too, so I'll probably be setting up all of the Twine 1 and Twine 2 story formats for command-line use in the near future.)

time()

You have me thinking about including notes on similar functionality like time() to the use of the <<repeat>> macro here.

In looking at how Inform approached their own 'recipe book', it might be worth pointing to other ways to approach a problem and related functionality. If we wanted the same type of 'star' system they use, we could include a time() example and then scale up to the existing, more complex one.

from twine-cookbook.