intfiction.org

Looks a lot like an INI file to me. The basic structure of choices and linking scenes to each other by ID is, as others have said, pretty much inherent in the problem that both formats were invented to solve.

One difference between INML and yours is that INML doesn't have blocks consisting of nothing but opaque IDs: the choices are part of the scenes, everything is described in complete words, and IDs are only used to link to scenes. That makes it more readable, in my opinion. For example, I have no idea what "EC", "NJ", "PN", "NC", and "DN" stand for, although I can guess at the others; the INML version is self-explanatory. But maybe that's not a big deal if the NodeScript file is meant to be edited with a customized program (is it?).

Bonus points if the INML interpreter also tells me to disable my antivirus scanner. Or is that another trade secret?

Then ask yourself why it didn't happen to me and maybe you'll find the answer...

_________________
"An idea is like a virus. Resilient. Highly contagious. And the smallest seed of an idea can grow. It can grow to define... or destroy you."
INCEPTION Soundtrack - Dream is Collapsing

Yes, a NodeScript editor is planned. But for now a simple text editor (e.g. Notepad in Windows) should do the job.

_________________
"An idea is like a virus. Resilient. Highly contagious. And the smallest seed of an idea can grow. It can grow to define... or destroy you."
INCEPTION Soundtrack - Dream is Collapsing

Well, technically yes, since it is a text file. But if you expect people to use a text editor, I encourage you to reconsider some of the cryptic syntax. As it is, it seems more like an intermediate format that humans shouldn't view or edit except in an emergency.

Already done. View NodeScript.NINI format.

_________________
"An idea is like a virus. Resilient. Highly contagious. And the smallest seed of an idea can grow. It can grow to define... or destroy you."
INCEPTION Soundtrack - Dream is Collapsing

I have started working on an authoring tool to read and save stories in INML format, and have already come across a few deficiencies in the initial specification (for anyone who is interested in following my progress):

Since a Scene's id attribute is defined as an XML ID in the DTD, it must conform to certain rules (essentially it must be a valid XML node descriptor) which is not very friendly to human authors (more prone to auto-generation by authoring tools). Because of this, I've added a "name" attribute to Scene elements which would be a human-friendly short description of the scene. This value would never actually be displayed to a reader of the story, but would rather be used by authoring tools to allow the author to label scenes.

I've also decided to disallow HTML formatting for Prompt and Choice elements (only for Description elements). My main reasoning behind this is that the Choices are essentially hyperlinks, so allowing the author to place his own conflicting hyperlinks and other HTML elements in the choice option could pose problems when rendering them to a reader.

Another thing I am currently considering is a way to allow the author to specify page breaks within a Scene Description while keeping away from the added complexity of multiple Description elements within a scene. My first thought is some kind of control character or string like \p or \clear, but I don't particularly like that very much either. Anyone have any thoughts on how that could be achieved elegantly?

--edit: I actually came up with an idea I like better, which is to allow a <PageBreakSeq> element in the Meta section, where the author/authoring program could specify its own escape or character sequence that represents page breaks within the Description elements, thus allowing for page breaks while shifting the onus of coming up with a viable system to include them out of the specification itself.

A page break seems pretty fundamental though, wouldn't you want that in the spec?

With regard to styling links -- I guess that raises the question of styling in general, are you allowing authors to write a CSS file or something like that?

Well, the spec now supports page breaks, while leaving implementation details (ie, how to represent a pagebreak in the content) up to the individual story. I think flexibility is better than defining a standard in this situation, since picking some arbitrary universal way to represent a pagebreak (for example "***") could interfere with an author's content (in this example, if they wanted to use the string "***" in their story without representing a pagebreak). This way, they can specify their own pagebreak string and guarantee that there won't be parts of the story that will be incorrectly interpreted.

As for styling, CSS is definitely a possibility for HTML formatted stories (either through inline <style> tags or including an external stylesheet when exporting to HTML format--or any format that inherently supports HTML). In the case of prompts and choices, it would likely be styled as a generic template, as opposed to individually styling each prompt and choice (which is part of my thinking behind disallowing HTML formatting in that content--the other more important part is that wrapping an <a> tag around arbitrary author-generated HTML code will break in a lot of situations, and detecting/managing that could become nightmarish).