Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Broad Questions on Twine Language for School Assignment
Hello. I will be doing a short presentation on TWINE for school next week. Specifically, my segment will be on the language. I've made some simple programs and looked at the API so I believe that I have a handle on how it works. However, because I don't have time to get really in-depth with it I would appreciate it if I could have some conclusions I have reached confirmed or disputed.
1.It is not possible to create custom functions (or "macros" as they are called here). If there is a hackey way to get around this I would like to know about that as well.
2.In order to run a loop you would need to increment a value defining that loop, run the code, move to another blank passage, move back to the original passage, increment the value again and carry on doing this until the value exceeds a target (in this example I'm describing a for loop). I have also seen the "live" macro, but I'm not clear that this can be used for more traditional computational loops.
3.It is not possible to view the state of a variable while testing the game without including a line of code in the active passage which prints that variable.
4.It is not possible to run Javascript after the initial program load.
5.A question: What is the javascript typically used for?
I do understand that these things are not critical to Twine's goals, but I would like to be sure before I make claims about the language's capabilities. In particular, I want to be able to say for sure whether or not it is Turing complete.
Thanks!
1.It is not possible to create custom functions (or "macros" as they are called here). If there is a hackey way to get around this I would like to know about that as well.
2.In order to run a loop you would need to increment a value defining that loop, run the code, move to another blank passage, move back to the original passage, increment the value again and carry on doing this until the value exceeds a target (in this example I'm describing a for loop). I have also seen the "live" macro, but I'm not clear that this can be used for more traditional computational loops.
3.It is not possible to view the state of a variable while testing the game without including a line of code in the active passage which prints that variable.
4.It is not possible to run Javascript after the initial program load.
5.A question: What is the javascript typically used for?
I do understand that these things are not critical to Twine's goals, but I would like to be sure before I make claims about the language's capabilities. In particular, I want to be able to say for sure whether or not it is Turing complete.
Thanks!
Comments
For Twine 1.4.2 plus SugarCube:
1. They are called Widgets. Vanilla lets you use a passage as a macro.
2. Sugarcube adds a <for> macro to make loops simpler. It also has a working <goto>
3. You can put it in the page header or footer - in which case it shows on every page. You can add a debug widget, in which case you just need to set or clear a variable to turn your games debug on or off. You can display it in the storymenu so it'll be shown for every page.
4. Yes you can. Sugarcube has a whole API for manipulating it from Javascript. Think it's done through a set call <<Set fullscreen(true)>> where fullscreen is a javascript rotuine.
5. Things you can't do from the base macros. I've used it for things like forcing the browser to fullscreen or saving and restoring persistent variables. It can also be used for remote http calls etc...
EDIT: Oh, I see now. In some places on the wbesite sugarcane is referred to as sugarcube, so I thought it was simply an update of the old API. This makes much more sense now.
That may not technically be twine's language, but worth mentioning.
Also, sugarcube is not the same thing as sugarcane. Sugarcube is basically a more feature-rich fork of sugarcane.
Commonly available story formats: (not an exhaustive list)
Only the Twine 1 vanilla story formats could be said to share a reasonably common syntax—their differences lie largely within their structure and styling. That said, SugarCube—more v1, less v2—does share some commonality with the Twine 1 vanilla story formats, but there are significant differences as well—more v2, less v1.
Now, on to specific replies.
NOTE: Any mistakes made when talking about story formats are just that, mistakes. I'm not attempting to slight anyone's favorite tool.
Harlowe: v1 offers no API to add custom macros. I'm unsure about the upcoming v2.
Snowman: Neither v1 nor v2 offer macros per se, however, that's because they're intended as lightweight formats where you primarily use JavaScript directly for extra functionality.
SugarCube: Both v1 and v2 offer macro APIs.
Twine 1 vanilla story formats: All offer a macro API.
All of the mentioned story formats allow and can use custom JavaScript functions, which depending on what your needs are might be just as good.
You may use passage recursion as a loop stand in, however, that has the same drawbacks that function recursion does and several more besides.
Harlowe: v1 does not offer native loops. It does, however, offer the (live:) macro, which can be used as a loop stand in—it's a timed event series, however, so there are a few caveats. v2 does offer native loops.
Snowman: Neither v1 nor v2 offer native loops, however, it's simple enough to use JavaScript's loops.
SugarCube: Both v1 and v2 offer native loops.
Twine 1 vanilla story formats: None offer native loops.
No story format that I know of offers the ability to lookup the state of the story variables as a built-in. Frankly, having it as something built into the story formats would be odd—that's typically more a feature of the development environment, not the runtime.
Harlowe: Both v1 and v2 offer debug sections which allow you to gate access to your debugging code based on whether its running in Test mode or not. Using those, it would be possible to leverage JavaScript to open some kind of dialog showing the state of the story variables—I don't know if anyone has already written something like that.
SugarCube: v2 offers a debug flag which allows you to gate access to your debugging code based on whether its running in Test mode or not. Both v1 and v2 offer macro add-ons for debugging purposes, one of which (<<checkvars>>) opens a dialog showing the state of the story variables.
The other story formats would require completely custom solutions.
All story formats allow this.
Harlowe: Use the <script> tag.
Snowman: Use its <% … %> syntax.
SugarCube: Use the <<script>> or <<run>> macros.
Twine 1 vanilla story formats: Abuse the <<set>> macro.
Extending the story format's native capabilities.
If calling out to JavaScript is allowed, then all story formats would have to be considered computationally universal—because JavaScript is.
If calling out to JavaScript is disallowed, so that only the story format's native syntax is allowed, then the computationally universal story formats are: Harlowe, SugarCube, and probably the Twine 1 vanilla story formats. Snowman does not make the grade in this case, since it doesn't have much of a syntax if you exclude JavaScript.
No. Sugarcane and SugarCube are indeed separate story formats.
Not so much. Save for the fact that both use a modified version of the classic TiddlyWiki core as their parser/render and share some APIs, Sugarcane and SugarCube v1 are not very much alike internally—the differences are more stark if we compare Sugarcane to SugarCube v2.