It looks like you're new here. If you want to get involved, click one of these buttons!
<% %>
as Javascript, and uses <%= %>
as a shortcut for printing the result of some JavaScript. Some examples:<<set $candies = 2>>
<% state.candies = 2 %><br /> </li><br /><li><code>You have <<print $candies>> in your pocket.
You have <%= state.candies %> in your pocket.
<<if $candies gt 1>><br /> <<set $candies-->><br /> You gobble a candy down. <<print $candies>> left!<br /><<endif>>
<%<br />if (state.candies > 1)<br />{<br /> state.candies--;<br /> passage.write('You gobble a candy down. ' + state.candies + ' left!');<br />};<br />%><br />
showpassage
and hidepassage
as the user takes actions, so that you can add your own behavior.<% story.checkpoint() %>
to add a history entry, and <% story.save() %>
to put a permalink to the current story state in the user's address bar. (I shamelessly stole how to do this from Leon's Harlowe source code, e.g. the Twine 2 runtime.)[[Displayed text->destination]]
link syntax.
Comments
In that spirit, I set up a page like this: ... and it said "Hello undefined". The alert had the value right, and it was right on the second page too, but not here. Does it evaluate scripts in a funny order? I am using Twine 1.4.2 on Firefox/Win7 by the way.
Edited to add:
I also had a go at converting a game I have on the go. It has a character creation page, and I was wondering how to do text boxes and radio buttons. I tried doing that in raw HTML, but it just displays the HTML code, not the controls.
Also, it does not seem to support setting values in links: It tries to find a link to a passage with the name Begin][state.fullname = document.getElementById("fullname");state.sex = document.getElementById("sex");state.charclass = document.getElementById("charclass").
Perhaps I am assuming this is a fully working system, when it is a work in progress?
The HTML and the "Hello undefined" things are both bugs -- I logged them at https://bitbucket.org/klembot/snowman-1.4/issues. Feel free to add more!
There's isn't exactly functionality for adding links that just execute JavaScript -- though in this scenario, wouldn't you want to run some JS and then go to a different passage? But I can see that it would be useful regardless. You could in theory write: But that's kind of a mess to read, with all the code stuck together on one line. I considered some alternatives -- I'm not sure which syntax I like better yet. or I lean towards the latter because it's a lot more flexible -- e.g. it's easy to add custom CSS classes or other kinds of event handlers besides just click.
(In both cases I rewrote your code a little bit to take advantage of jQuery.)
The five languages Leon identified are:
TiddlyWiki text formatting
HTML tags
CSS inside HTML tags and stylesheets
macro tags
Javascript functions and data types inside macro tags
Snowman takes a step in the right direction by eliminating macro tags, but still leaves four languages on the stack, replacing TiddlyWiki with a Markdown variant. Markdown is probably an improvement upon TiddlyWiki, but if the plan was to reduce the number of languages, Markdown is not the way to do it.
In his statement of the philosophy of Markdown, Gruber wrote, "The idea is not to create a syntax that makes it easier to insert HTML tags. In my opinion, HTML tags are already easy to insert. The idea for Markdown is to make it easy to read, write, and edit prose. HTML is a publishing format; Markdown is a writing format. Thus, Markdowns formatting syntax only addresses issues that can be conveyed in plain text."
But stories in Twine are more hypertext than prose, and Markdown's weakest point is how painful it is to create hyperlinks. Hence the need to add the [[Displayed text->destination]] syntax.
Why not use raw HTML as the language? IMO, there are two core problems with raw HTML.
1) Raw HTML strips whitespace, forcing the user to use hideous <p> tags. But a dash of <style>body { white-space: pre; }</style> will clear that up. If the user doesn't want that effect, a little CSS will clear it up.
2) HTML links can be verbose. But they're not that bad if you omit quotes, which is now specified behavior in HTML5. <a href=destination>Displayed text</a> is really not that bad.
And HTML already includes a <script> convention for including inline JS, which is only a little longer than <% %> and has the benefit of being totally standard. Don't want to run the script right away? Set the type to something non-standard and switch it back in JS as the user navigates to the node. <script type=x></script>
Upcoming features of HTML+JS include a templating language, which can make this type of development even easier. And Traceur can be used to backport those features to today's browsers.
WDYT?
Then you just call it with the name you've given the widget, which can be as short and/or mnemonically easy as you can think of. I don't think I can give a terribly good explanation here, so I suggest reading about it here. Something of a extended version of this is what I'd like to see most in the user-friendliness direction.
What I'd add to it would be a point and click style sheet constructor (so I just picked what I wanted in the stylesheet from some tabbed menus and never had to edit the CSS at all). Mostly what I'm going to want is the ability to change text color and size and background colour - and maybe supply an image.
Yes, you can do heaps of flash tricks with it, but most of us just want something simple that works - which 1.4.1 is. Please don't break it in the name of fitting a few more tricks into the box.
IMHO, making the standard anything more complicated that to current is a move in the wrong direction. If you want a better editor, make it WYSIWIG, not cryptic html or CSS or javascript or anything else. It's job is to hide the complexity, not to expose it.
Hadn't considered that -- I think though that if we did that, we'd lose word-wrapping. Here's a fiddle I used to check.
For a decent number of cases, though, you'd be writing
<a href=Open the door>Open the door</a>
which seems like busywork for an author.Using
<script>...</script>
seems like a reasonable idea assuming the runtime would be able to change the script type before the browser tried to execute it. Only downside is that it seems useful to be able to writeYou have <%= state.candies %>
instead ofYou have <script>passage.write(state.candies)</script>
.I haven't seen anything about HTML5 templating-- could you point me to some reading?
I think overall a lot of this comes down to what Larry Wall means by Huffman encoding... things you need to write a lot should take as few characters as possible without becoming unreadable. (Whether Perl passes that second test is a whole other story...) The point of using Markdown for me is conciseness. That said, you can write HTML in Markdown and it just works, is my understanding, so it's there as an option.
The Snowman idiom for the SugarCube example I found in the docs would be: Which to me is a tossup in terms of readability -- fewer pairs of <<>>s, at least.
Yep, I see this always existing as an alternate to the usual way of doing things.
Use white-space: pre-wrap instead.
Well, some JS is required regardless to avoid navigating to another page, so I'd be fine with <a>Open the door</a> automatically doing the right thing.
Yeah, that's really the sweet spot for templating.
http://www.html5rocks.com/en/tutorials/webcomponents/template/
http://tc39wiki.calculist.org/es6/template-strings/
https://github.com/google/traceur-compiler