HTML When writing a story in Twine, what character(s) do you prefer to use for macros / coded functionality?

[valkron]

Hi all,

Bit of an odd first post I'm sure, but I am looking for feedback regarding a project I am looking into involving a possible unified macro system across the Twine 2 interfaces (Harlowe, SugarCube etc). While it is definitely possible to do many things using the inbuild macros, I believe that it could be helpful to integrate libraries across the board instead of developing them for only one flavour. There are technical challenges to this of course, but that comes with the territory. Probably even already exists on some corner of the internet, who knows.

For now at least, the question at hand. What character(s) do you prefer to use for macros? I have included the currently existing options and a few others, but feel free to comment and suggest others or thoughts in general. I will attempt to keep the poll up to date and see where it goes.

Valkron

Edit: Probably best not to pick the */ option now that I think about it due to the JS usage of that for comments.

 

[HiEv]

(…), */…/*, ..….. and especially […] would be really confusing with they way that that they're used in Twine/JavaScript code already. The Twine editor itself would rebel against square brackets, since it uses double-square brackets to recognize links.

<%…%> is used in

You must be registered to see the links

(JSP), so if your page is on a server which uses that, it could break your game.

That just leaves @…@ and <<…>>, both of which are used by SugarCube.

That said, I'm not sure I see a reason to combine different story formats like that. It would make more sense to just use SugarCube and create some widgets and/or macros to add anything it's missing from Harlowe that you might need.

 

[valkron]

(…), */…/*, ..….. and especially […] would be really confusing with they way that that they're used in Twine/JavaScript code already. The Twine editor itself would rebel against square brackets, since it uses double-square brackets to recognize links.

<%…%> is used in

You must be registered to see the links

(JSP), so if your page is on a server which uses that, it could break your game.

That just leaves @…@ and <<…>>, both of which are used by SugarCube.

That said, I'm not sure I see a reason to combine different story formats like that. It would make more sense to just use SugarCube and create some widgets and/or macros to add anything it's missing from Harlowe that you might need.

You do make several good points regarding the delimiters, that in itself is what I am finding quite challenging to determine. Many of the characters which make the most sense for such a task, such as "*", "/", "%", etc all have direct underlying meanings in JS or other languages used across the web, hence the request for suggestions.

Regarding your second point about why, while I have found a few resources for the creation of larger blocks of code for specific formats, the lack of any unified access to both JS / macro systems and the JS objects themselves just did not really make sense to me. While I understand each formats is developed separately from a singular front end, I would have expected the macros methodology at least to be mirrored in either a set of core libraries, or accessibility to write your own, which would allow for the extension of functionality to benefit all the formats. The lack of uniformity here, in my opinion at least, detracts from the desire to script a library for the platform, considering that while many will use SugarCube, there have been other projects using Harlowe which could likely benefit from similar library / macro support.

 

[HiEv]

Regarding your second point about why, while I have found a few resources for the creation of larger blocks of code for specific formats, the lack of any unified access to both JS / macro systems and the JS objects themselves just did not really make sense to me.

I'm a bit unclear about what you mean by that, but if I'm understanding you correctly, I don't see how adding another system makes things more unified, instead of less.

While I understand each formats is developed separately from a singular front end, I would have expected the macros methodology at least to be mirrored in either a set of core libraries, or accessibility to write your own, which would allow for the extension of functionality to benefit all the formats. The lack of uniformity here, in my opinion at least, detracts from the desire to script a library for the platform, considering that while many will use SugarCube, there have been other projects using Harlowe which could likely benefit from similar library / macro support.

But if you use different delimiters, then you're just causing even less uniformity by adding yet another story format with its own system for coding things.

And while SugarCube and Harlowe are the big two story formats in Twine, there are also a

You must be registered to see the links

. For example, the

You must be registered to see the links

story format, which is already included with Twine, and the creator of Twine has been working on the upcoming

You must be registered to see the links

story format as well.

Honestly speaking though, Harlowe is kind of a dead-end story format. You can pick it up quickly, but it's very shallow, and you quickly hit its limitations. Unless there's something specifically appealing about one of the other story formats for your game, your best bet is to go with SugarCube, due to all of its built-in tools and its flexibility.

The best solution at this point is for everyone to move to SugarCube, and thus the other story formats will eventually die out. I'm not sure if that will happen as long as Harlowe remains the default story format, but that's why I recommend SugarCube to new Twine authors.

 

[valkron]

I'm a bit unclear about what you mean by that, but if I'm understanding you correctly, I don't see how adding another system makes things more unified, instead of less.


But if you use different delimiters, then you're just causing even less uniformity by adding yet another story format with its own system for coding things.

And while SugarCube and Harlowe are the big two story formats in Twine, there are also a

You must be registered to see the links

. For example, the

You must be registered to see the links

story format, which is already included with Twine, and the creator of Twine has been working on the upcoming

You must be registered to see the links

story format as well.

Honestly speaking though, Harlowe is kind of a dead-end story format. You can pick it up quickly, but it's very shallow, and you quickly hit its limitations. Unless there's something specifically appealing about one of the other story formats for your game, your best bet is to go with SugarCube, due to all of its built-in tools and its flexibility.

The best solution at this point is for everyone to move to SugarCube, and thus the other story formats will eventually die out. I'm not sure if that will happen as long as Harlowe remains the default story format, but that's why I recommend SugarCube to new Twine authors.

You do make several compelling points regarding the different formats, however what I had intended was more aimed to be a library which you could include in the story JS section. Something which could almost act as a plugin loader of sorts which could roughly at least plug and play libraries designed for it, hence its own delimiter to prevent the confusion with the original story formats, whichever that may be.

A new system would in itself be a difference from the existing systems for each format, and that could cause confusion certainly, but I think I will have to wait and see how it feels once I have tinkered with it before giving a verdict.

 

[HiEv]

By the way, I think this article, "

You must be registered to see the links

" written by Chris Klimas, author of Twine, the Snowman story format, and the Chapbook story format, might help explain a bit about why the formats are so different.