-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timed passages #3
Comments
Examples submitted for Harlowe 2.0 and SugarCube 2.18. (https://github.com/iftechfoundation/twine-cookbook/tree/master/timedpassages_videlais) |
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.
... I wonder if the hiding of the visual output of a startup tagged special passage should be it's own recipe? |
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 --
-- to the Harlowe example and --
-- 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? |
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. |
True, @greyelf. Now fixed in both example and twee notation files. |
Commentary on the SugarCube exampleI'd strongly suggest placing special passages at the top (e.g. place Please, do not place I'm not thrilled about the use of Calling
See AlsoYou can do something very similar to this, and much more simply, with the [Edit] Commentary on the Harlowe exampleSimilar 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:
There are other ways to do that, but being specific is better I think. |
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.
I made these two changes just now and updated the HTML and Twee versions for SugarCube.
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.
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
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. |
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:
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
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:
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. |
About SugarCube's
|
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
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 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 |
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).
The text was updated successfully, but these errors were encountered: