Typescript/Svelte IF Framework

[tsanderdev (Tarek Sander)]

@dfabulich

@tsanderdev

That is feasible, but the one big problem is the language server support. That’s the main reason for Typescript, and Svelte is also much easier with it. The VSCode Typescript language server and the Svelte extension are open-source, but I’d have to rewrite them to work with CodeMirror.

Why CodeMirror? (Is that what the Twine GUI JS editor uses?)

Yes, Twine uses CodeMirror and allows story formats to provide editor extensions for it. It is used for the passages, and the story JS and CSS.

@dfabulich

A related approach is to just not integrate with the Twine GUI editor at all, and just integrate with Twee. Twee actually has a specification, unlike ChoiceScript. twine-specs/twee-3-specification.md at master · iftechfoundation/twine-specs · GitHub

Again, the Twee format doesn’t really bring much to the table other than the passage system. I actually already made a Rust library and compiler for Twee back when I still thought making a story format was the best idea.

@dfabulich

ChoiceScript doesn’t support negative numbers as literals because, in ChoiceScript, the leading operator is a shorthand for addition and subtraction from the current value.

*comment set foo to 40
*set foo 40
*comment add 40 to foo
*set foo +40
*comment that's equivalent to:
*set foo foo+40

*comment subtract 40 from foo
*set foo -40
*comment which is equivalent to:
*set foo foo-40

As a result, the only way to set foo directly to negative 40 is to *set foo 0-40, which is weird for anyone coming from typical programming languages.

I read through the issue there is for that, and I understand you can’t use it in set command because that’d be ambiguous, but anyone that had high-school math would expect it’s valid to write something like (-2 + 7). It’s just weird that’s not possible. And set would be possible with (-2), that signals it’s the unary minus and not a set-and-subtract, and it gets rid of the confusing extra 0.

@dfabulich

I think you’re going to run into a lot of issues like these trying to re-implement ChoiceScript.

I picked out 3 issues I have: unary minus, operator precedence instead of parenthesizing absolutely everything (also something you’re not used to from regular maths), and a syntax for declaring proper functions that work like the built-in round: They get parameters and return a value, but don’t have choices or print anything. IIUC you can’t use commands in expressions, so you can’t use gosub or something like that for a reusable calculation that isn’t displayed.

With those changes, ChoiceScript is essentially a more beginner-friendly Ink, which is precisely what I want.

By the way, this quote:

@dfabulich

Visual design stems from supporting touchscreens, mouse, and gamepads

If you want to sell your game on iOS, Android, and Steam, you’ll have to ensure that your game works well on touchscreens, mouse, and gamepad controllers, which typically means constraining your visual design.

For example, hyperlinks are hard to select accurately on touch screens, especially if they’re very close together, so IMO most good mobile choice-based IF displays options on a menu as large, tappable buttons.

Gamepads make this even harder. Many popular choice-based IF games designed to operate well on gamepad require the author to limit the number of options in any given choice menu. For example, if you use a “dialogue wheel”, you really can’t have a dozen options on a wheel. Even just pressing “down down down” 8 times to get to the eighth option on a list can be quite unpleasant on gamepads.

I predict that if you start from scratch and aim to support touchscreens, mouse, and gamepads, your visual design will converge on something very much like what ChoiceScript looks like now.

Alternately, you can design different experiences for touchscreen, mouse, and gamepad. That might be better! But it’s way more work for the author/designer/programmer. (“What should the choice at the start of chapter 3 look like on touchscreens? On desktop? On gamepad?”)

Is what motivated me to work on keyboard accessibility yesterday. For touchscreen I’ll probably make an option that does something similar to ChoiceScript: Pulling all inline links out of the text, possible with the sentence they’re in or at least a bit of context and displaying a series of buttons for them after the passage. I’m determined there is a way to make an accessible cross-platform UI that’s at least a bit more pretty than the default ChoiceScript one.