SugarCube dependency and a Harlowe port

[jeremydouglass]

How deep is the connection between tiny-qbn and SugarCube?

Would you expect that a fork / branch that supported Harlowe could reuse 90% or 75% of the base code, or would it be a complete rewrite?

[JoshuaGrams]

Hrm. I don't know anything about the internals of Harlowe. I think it would be more of a rewrite than a branch or a build that used the same core? Possibly a lot of the code could be the same, but the SugarCube bits are sprinkled all through everywhere. I tried factoring out the core from the SugarCube bits at one point and decided that it probably wasn't worth it for me at that time, since I was mostly interested in factoring it out as an aesthetic thing.

Also porting it to Harlowe is probably not something that I have the time and interest to attempt. But if you're thinking at all seriously about trying it I'd be happy to take a closer survey of the code and write up an analysis of where and how it's entangled with SugarCube.

[jeremydouglass]

Thanks so much for this answer.

I'm thinking about trying to teach with QBN at some point in the future, and gauging roughly what effort it would take for me to make a Harlowe fork before actually reading through the code. Nothing against SugarCube, but right now Twine / Twinery defaults into Harlowe, and every non-default is one more bit of setup to go wrong in a class, so I'm default-centric whenever possible.

....hmm. Looks like (if I'm understanding right) this is all built on sugarcube's widget. Harlowe 3.1 manual in the Syntax comparison with SugarCube appendix clists "custom macros" as "Not offered" when compared to SugarCube's <<widget "myMacro">> <<print $args[0]>> <</widget>> -- so it looks like the whole approach would need to be thought through in a port.

I'll reopen this if it becomes a project in the future.

[JoshuaGrams]

Ah. Well, there is ChapelR's Unofficial Custom Macro Framework for Harlowe, so it is possible to make custom macros. It's just discouraged by Harlowe's author.

And depending on how complex you want to go, you may be able to get away without a library and just write a single "selection-hub" passage? I haven't done much concrete experimentation with that, but I definitely have some thoughts about it if you want to chat sometime.

[jeremydouglass]

Really interesting about the framework, thank you. When you say

a single "selection-hub" passage

...could you say just a bit more about what you mean? I'm assuming you mean in a general seense, not that there is a "(selection-hub)" already in Harlowe or by ChapelR?

[JoshuaGrams]

Yeah, in a general sense.

OK, the core thing you need for a quality-based narrative is a way to find all the storylets that are available (have all of their requirements satisfied), right?

And the requirements are ideally arbitrary expressions, but at the end of the day, they just evaluate to a boolean: is this requirement satisfied by the current story state?

So for simple models, you can can have a passage that hand-computes all of the booleans you need: highAnxiety, extremelyPunctual, etc. and then does something like the following (I don't know Harlowe so there might well be a better way to do this):

(set: _storylets to (passages: _where _highAnxiety is true or "extremelyPunctual" is not in its tags))
(set: _storylets to (find: _p _where _highAnxiety is true or "highAnxiety" is not in _p's tags, ..._storylets))

And then display or link to the matching passages in the resulting array. Doesn't scale well, but might be enough to teach a fair amount of QBN design.

[jeremydouglass]

Good ideas. I will definitely consider this. I think I also need to look at tiny-qbn more closely to better understand some of what is possible in a more complete system.

[JoshuaGrams]

That hits a surprising amount of it. I added StoryNexus's three priority levels: normal, important (floats to the top to the list, gets chosen before normal cards if you ask for a limited selection) and urgent (if an urgent card is available, locks out normal and important cards). And of course, you can declare arbitrary comparison requirements directly.

Oh. Remembering the current contents of the deck is another thing. If you want a single-use storylet that's removed from the deck once you've played it, how do you handle that?

Other than that, I think it's mostly conveniences.

• <> lets you mark ticks on a number line and name the regions, and then reports which region a variable's value falls into.
• <<progress "$name" "state1" "state2" "state3" etc.>> lets you declare a progress variable with named states instead of using a number and having to remember what the different values mean.
• <> lets you build card-like choices inline, so if you have a bunch of small cards that are only available in one place, you don't have to make a separate passage for each one (which is a little clunky in the graphical editor).
• <>cover<>...<> and also-condition tags let you have a single card with two "sides": you can see the cover if the basic requirements are met, but the contents are only available if the also conditions are met, and the card is only removed from the deck once you look at the contents side. It's a bit clunky, but again, sometimes more convenient than using two passages.

And I'm not claiming tiny-qbn is particularly amazing: it was more a case of "I'm a programmer, it seems like there is increasing interest in this design space but there are almost no tools available, so what can I shoehorn into Twine that might let people get started more easily?"

[JoshuaGrams]

Also, if it's only the setup that's a barrier, I just made a blank project generator so you can just give it a name (to work around twine issue 615 and then save the HTML and import into Twine.

[jeremydouglass]

Also relevant: looks like the Macro Framework for Harlowe just added a widget-like macro built-in

https://github.com/ChapelR/harlowe-macro-api/issues/6

in v1.01

https://github.com/ChapelR/harlowe-macro-api/pull/7