nqnstudios / hank Goto Github PK

I think this was to remember to push builds to haxelib -- but I'm not sure if that's a priority until we're much further along re: stability

hxparse could be a useful tool for writing Hank. If it makes the parser code more elegant, then it could make it easier to add syntactic elements and features.

I'm not sure what it adds, but mo is also built on top of hxparse and provides helpers for lexing and parsing.

This will be useful for devs to keep tabs on which version of their game a playtesting transcript came from.

Additionally, It might be useful for validateAgainstTranscript() to make sure the current running version of Hank is compatible with the version that generated the transcript

Hi, I just wanted to mention that I really like this idea. I actually found Ink because I'm following someone who starred Hank ( thanks @sh-dave 😉 ).

I really like the Ink concept in general and think it would be awesome to be able to use it in Haxe games, particularly Armory3D games.

https://github.com/inkle/ink/blob/master/Documentation/WritingWithInk.md#fallback-choices

Because currently embedded Hank script is parsed lazily, view counts for labels and sections that appear in embedded Hank won't be initialized to 0.

You'd have to be insane to double-embed things like that... or would you? In any case, pre-parsing embedded Hank might be useful for other reasons, too.

I think this is how Ink handles such a case.

I'll fix this by having processLine() return the old Empty frame type, and nextFrame() or will use a do-while loop.

emphasize that Hank implementations can be completely different from Ink internals, and that the goal is not to stay apace with new Ink features.

One thing that would be great is folx writing more examples that test deliberately for edge cases. The current example suite is light on that.

https://github.com/inkle/ink/blob/master/Documentation/WritingWithInk.md#2-threads

It's possible to return different values from {hscript expressions} conditionally, such as {if (pressed_button) "It's activated!" else "It's still turned off"}

However it would also be nice to let an hscript expression guide the Hank flow itself without calling gotoSection directly, which feels inelegant.

It would also be nice if if (condition) value returned empty string by default, and not null (which I assume it does now).

I never implemented this: https://github.com/inkle/ink/blob/master/Documentation/WritingWithInk.md#advanced-diverting-to-options

I think I forgot to implement/test alternatives nested in other alternatives

This haxelib might make it possible to automatically collect transcripts from playertesters' playthroughs: https://github.com/benmerckx/smtpmailer

concerns:

• player/playtester privacy
• dev security -- including mail account passwords in exported code (especially js), etc.

Do we need glue?

In order to allow the following idiom:

{ if (cond) "insert text" } before more text

I programmed expression insertion to ignore null errors and replace all null values with an empty string. However, null errors could be very useful for debugging in contexts such as this:

{ variable_i_expect_to_exist }

Using the new expression transmutation system, I should be able to provide for both cases by transmuting if expressions to include a default else "" clause.

I want to keep all requests for missing Ink features in one place. If there's something Ink can do that you want Hank to do, write it in this thread for discussion.

For example, Hank currently does not support stitches within knots, or sections starting with ===, so you might request one of those too be added here.

Note that features of embedded scripting in Ink will likely never be added, because Hank stories will already have access to the Haxe language & standard library, making implementing Ink's embedded scripting redundant.

i.e. on travis, also build and test with hxcpp, js (if #49 is ever fixed) etc.

Two things aren't possible in insertion expressions right now: multiline logic (as is allowed by using three backticks) and the use of braces inside the expression. Something like

{ if (cond) {
    statement1;
    return value;
} else {
    statement2;
    return value2;
}
}

might be desirable (as it's a syntax commonly used in Ink conditionals.)

Could be implemented by modifying findEnclosure() to have a nested parameter which forces findEnclosure to find the outermost enclosure pair instead of the first two instances of opening and closing. (i.e., use rfind to find closing.)

This might blow apart many things about how Hank works. One example: and a multiline insertion expression appear in a choice declaration?

https://github.com/inkle/ink/blob/master/Documentation/WritingWithInk.md#sequences-cycles-and-other-alternatives

Follow the structure of WritingWithInk.md as closely as possible

I suspect we'll run into edge cases when a lot of INCLUDE statement come at the start of a main script. Some outlandish test to make sure it isn't broken, would be good.

https://github.com/inkle/ink/blob/master/Documentation/WritingWithInk.md#knots-and-stitches-can-take-parameters

I think it would be useful to have some Haxe features that hscript is missing, such as function and enum definitions especially, and the ability to invoke constructors and static methods.

So I'll be looking into forks/extensions/alternatives to hscript. The first one I checked out was ihx, which won't work because it depends on the system's Haxe and Neko binaries (which means it's not fully portable/cross-platform).

Edit: I was wrong. function definitions are allowed in hscript.

To put a finer point on what I meant when I opened this: Name resolution

Subsection names should shadow section names when references from within their sections, etc. (Luckily we don't have to deal with infinite nested scopes, just sections and subsections.) But also, some way to prevent variables from name collisions would be good, too.

Compiled ink is well-suited for Javascript integration in Inkjs because it is Json. Runtime-parsed Hank is not suited for Javascript because we read it from text files using sys.io.File.getContent() and sys is not supported on web targets. Can we work around that, at least by supporting nodejs so shipping an HTML game is possible on sites like itch.io?

Although I kind of want to learn to write VS Code plugins, I'm inclined to declare this out of scope for my personal work on Hank. Anyone is welcome to share ideas and prototypes, though.

For example, should

* Choice 1
\`\`\`
if (cond) {
, * Choice 2
}
else{
, * choice 3
}
\`\`\`
* Choice 4

Collect and present 3 choices?

related to #2

Whether or not Ink-style tags should be a part of Hank is up for discussion. Reasons for not including them:

• Since any Haxe object can be passed to the story interpreter and its functions can be invoked at runtime, processing tags and executing logic based on them in some external game loop might be an anti-pattern. Any such form of logic could be replicated by invoking functions directly in the script.

I've written ugly code in several places because I didn't understand the concept of static extensions. Everywhere that I've written StringTools.method() I can clean up by using using StringTools; instead.

Right now it's not possible to divert to content dynamically. The quick and dirty solution would be to allow specifying a divert target via h-expression, but this would only allow storing a STRING divert target. The 'gotcha' here being that divert targets are scoped, and scope should be preserved, rather than forcing the dev to store fully qualified target strings.

https://github.com/inkle/ink/blob/master/Documentation/WritingWithInk.md#1-tunnels

There must be an easier way to implement this using hscript variables like how I ported TheIntercept's variable referencing functionality

Currently, in a transcript, choices look like this:

* [A] Result of A
* B
* C
>>> 0
Result of A

It would be more readable and less error-prone to have a syntax like this:

> 1: Result of A

All on one line, and 1-indexed.

All issues should come with the simplest possible Hank script that reproduces the problem/feature request, and at least one corresponding hlog transcript that will verify the expected behavior.

FYI, there are no type definitions of any kind in HScript ( see limitations ). I just saw your comment, so I thought I'd mention it.

Lofty thinking about how to make the language translation process easier for storywriters who want to release internationally.

Refactor validateAgainstTranscript() and special assert functions into a subclass of haxe.unit.TestCase, so story projects can use them for their unit tests.

For unit testing stories using transcripts, it is sometimes unforgiving to have to match the transcript text perfectly. Every time you change the story, you have to meticulously update the expected transcript. Sometimes, a fuzzy match is fine.