Typescript/Svelte IF Framework

[tsanderdev (Tarek Sander)]

@sandbags

Yeah, but it’s another thing to learn and… given that Rez is a superset of a subset of Javascript I felt it might actually turn out a little complex.

I think you can just forward the requests to the VSCode JS language server if the location is within a JS attribute.

[tsanderdev (Tarek Sander)]

@sandbags

But a downside is that JSON isn’t a great format for supporting functions. That was important to me as Rez makes a lot of use of JS functions for dynamic properties and behaviours (both in objects and in systems which are akin to the ECS type of cross-cutting system).

Since my users will be working with Typescript, complex logic will be defined by the user as a typescript function. And looking at Rez code: The barrier to just full-blown JS/TS isn’t that high. That’s my reason to sticking with TS instead of making my own declarative format: If you want the format to be sufficiently capable, you might as well let the user use JS directly, because the complexity of learning it is similar.

[sandbags (Matt)]

@tsanderdev

If you want the format to be sufficiently capable, you might as well let the user use JS directly, because the complexity of learning it is similar.

It’s an interesting question. I feel like I have attempted to let JS be useful but keep it “in a box”. That probably reflects my own bias here which is that I use JS out of necessity (browser) rather than any desire for the language itself.

[tsanderdev (Tarek Sander)]

@sandbags

@tsanderdev

If you want the format to be sufficiently capable, you might as well let the user use JS directly, because the complexity of learning it is similar.

It’s an interesting question. I feel like I have attempted to let JS be useful but keep it “in a box”. That probably reflects my own bias here which is that I use JS out of necessity (browser) rather than any desire for the language itself.

Don’t get me wrong, I also don’t like plain JS, but with TS you can get the illusion of static typing, which is enough for me.

Have you heard about WebAssembly by any chance? You don’t have to stick to JS. Rust has great support for WASM, and the dioxius library for rendering in the browser that is React-like. Dart also had good web support I think, for C/C++ there’s Emscripten.

[tsanderdev (Tarek Sander)]

I had a look around to see what DSLs are currently in use and popular, and I think I’ve settled on ChoiceScript as an additional format I want to support and Adventuron code for my parser world model implementation.

That of course requires open-source re-implementations in Typescript for both of these, let’s hope I don’t get sued lol. But since I’m not naming my product after theirs and don’t use their code, they shouldn’t have a legal standing anyways.

[sandbags (Matt)]

@tsanderdev

Have you heard about WebAssembly by any chance? You don’t have to stick to JS. Rust has great support for WASM, and the dioxius library for rendering in the browser that is React-like. Dart also had good web support I think, for C/C++ there’s Emscripten.

In a different universe I might have targeted WA but while I am familiar with it at a conceptual level, I’ve never used it. I did ponder rewriting the whole shebang in Rust a year ago (while Elixir is a language I love, it’s not the best fit for distributable command-line tools) but decided it wasn’t worth the effort.

[sandbags (Matt)]

IIRC the Choicescript guys are pretty open and approachable. If it were me, I’d confirm they don’t have a problem with it rather than risk annoying them later. It’s not that I think they would sue you,… but they seem to have a good rep in the community, why risk getting on the wrong side of them?

[HAL9000]

Dan Fabulich @dfabulich is a very approachable guy. He’s the man to talk to about ChoiceScript/CoG and frequents here quite often. Here’s an interesting thread, mostly surface level discussion… How difficult is choicescript to duplicate?

The Adventuron fellow, Chris Ainsley @adventuron , is easily found on his Discord channel.

I could see a huge benefit of both those engines working more seamlessly with JS/CSS. However, the CoG format is a pretty specific with their publishing standards. You might have the functionality of ChoiceScript, but not a valid format for their storefront. Anyway, I’m talking out of my ass about this now. Those two are who you want to talk to.

[dfabulich (Dan Fabulich)]

Can you help me understand what you’d hope to accomplish by interpreting other IF languages as “formats” in IF Framework? It seems like it would allow people to write games in ChoiceScript/Adventuron/etc. that run in the IF Framework.

But isn’t the point of IF Framework that authors would develop IF in TypeScript/Svelte and not to write in a DSL like ChoiceScript…?

As a word of encouragement, I think the world needs a modern IF framework that lots of people use that relies on a modern, popular programming language, and I hope your framework is the one to make that happen.

But, as a word of warning…

From time to time, IF enthusiasts come to the table with alternate IF authoring systems in which authors can develop IF in a “real” programming language, typically one of the top 20 languages on StackOverflow’s “most loved languages” list. Stack Overflow Developer Survey 2023

But none of the most popular IF systems require authors to use a “real” programming language. Instead, since most IF authors see themselves as writers first and coders second (if at all), all of the most popular systems use a domain-specific language for IF, ideally one that makes it easy to write extensions in another “real” programming language (typically JavaScript).

I think that this is because authors who know JS/TS tend not to use other people’s engines… instead, they write their own engine, like you did. But maybe your framework will be the one that finally breaks through!

In my experience, the language of your IF system is arguably the least important factor in making it popular. The most important factor is to implement an entire complete “admirable” game. Most people decide to use an IF system because they see a game that they admire, and they say, “I want to make a game just like that! Whatever system the author used to make it, I’ll use that system, too!” Admirers don’t seem to directly care about any of the details of the system, except that if it’s too hard for them to learn the system and finish a game, that’s a major factor in achieving true popularity.

And that’s a great opportunity for you, because it means that you don’t actually have to persuade anyone to adopt your framework except yourself. Make a great game (a few great games) and others will follow.

(Having said that, there is something to be gained from looking at other open-source games and porting them to your framework, to ensure that you’ve covered all the functionality that those other games might need. But that’s very different from just interpreting those other games, unmodified, in my experience.)

Good luck!

[sandbags (Matt)]

@dfabulich

The most important factor is to implement an entire complete “admirable” game.

This was good advice when you gave it to me, and it remains good advice today!

[tsanderdev (Tarek Sander)]

@dfabulich

Can you help me understand what you’d hope to accomplish by interpreting other IF languages as “formats” in IF Framework? It seems like it would allow people to write games in ChoiceScript/Adventuron/etc. that run in the IF Framework.

The problem is that Svelte and Typescript can be very verbose for some things, and ChoiceScript concise syntax for many common things in choice-based games. I would implement a subset of ChoiceScript (the one that describes a single scene since that corresponds roughly to a passage in my system), so you can use ChoiceScript for the parts of your game that neatly fit that model, and fall back to Svelte when you have something complex or layout-heavy that’s not supported. That’s the model I currently have already with Markdown passages, but markdown is too limited for most things and only really usable for plain prose. ChoiceScript would serve as more of a layer in the middle. I’ll decide between ChoiceScript and Ink as an additional format for now, I have to read up on Ink a bit so see which is more versatile. That said Ink already gets a bonus because it has an existing JS library. But ChoiceScript has a bonus of being more popular, so more people are likely to already know it.

@dfabulich

But none of the most popular IF systems require authors to use a “real” programming language. Instead, since most IF authors see themselves as writers first and coders second (if at all), all of the most popular systems use a domain-specific language for IF, ideally one that makes it easy to write extensions in another “real” programming language (typically JavaScript).

Ideally I would also support a no-code style with ChoiceScript: Just create a project from the template and create passages in ChoiceScript, no additional coding needed. Can you write JS plugins for CoG’s Hosted Games by the way? Or would that interfere with the packaging as native apps? I also want to include a way of creating native apps instead of just websites, and I’ll do that with Tauri probably.

@dfabulich

I think that this is because authors who know JS/TS tend not to use other people’s engines… instead, they write their own engine, like you did. But maybe your framework will be the one that finally breaks through!

That’s why I’m not making an engine in the strict definition, it’s more of a collection of modules that you can use that also happen to fit neatly together as an engine. Don’t like the UI? You can replace that. Don’t like the concept of passages for your game? Set the history size to 0 and simply use a “passage” as a distinct screen in you game. Or even just have one “passage” and do everything with Svelte’s dynamic UI if you want.

I would like to make things even more modular, but the communication between the modules becomes difficult if you don’t have one central singleton to refer to. I do plan on having the parser game module usable in the choice model though, so you’d be free to mix and match both if needed. Display a choice-based UI that can also be interacted with via a parser? completely doable.

@dfabulich

In my experience, the language of your IF system is arguably the least important factor in making it popular. The most important factor is to implement an entire complete “admirable” game. Most people decide to use an IF system because they see a game that they admire, and they say, “I want to make a game just like that! Whatever system the author used to make it, I’ll use that system, too!” Admirers don’t seem to directly care about any of the details of the system, except that if it’s too hard for them to learn the system and finish a game, that’s a major factor in achieving true popularity.

And that’s a great opportunity for you, because it means that you don’t actually have to persuade anyone to adopt your framework except yourself. Make a great game (a few great games) and others will follow.

Maybe that’s the reason the current systems aren’t appealing for someone with a programming background: The ones created by programmers just never got anywhere and died, because most programmers are (if the notorious “programmer art” is anything to go by) probably bad writers.

The game ideas I have are mostly someone else’s IP, but I don’t expect them to be big successes, nor commercial. There’s the German saying “Wo kein Kläger, da kein Richter” (“No plaintiff, no judge” according to google translate), and I haven’t heard about fanfiction actually getting sued, the worst that could happen is that I have to take it down again if it catches too much attention.

I have a few big original ideas, but most are a better fit for other game genres, though for one making it a parser game may actually simplify certain things…

@dfabulich

(Having said that, there is something to be gained from looking at other open-source games and porting them to your framework, to ensure that you’ve covered all the functionality that those other games might need. But that’s very different from just interpreting those other games, unmodified, in my experience.)

Yeah, currently I pretty much follow the Twine model, but it’s generic enough you should be able to fit anything else into it, really. Especially when you can just write generic Typescript and Svelte code. The question is then how much of the additional work needed for the game is generic enough to be included in the framework.



Another thing I can see as a cool possibility is becoming something like the GraalVM of IF: Someone created a great character editor in Ink, but you prefer ChoiceScript? No problem! The framework will handle the integration of them. At least for choice-based games that should work, because abstractions like “passages” and “variables” are pretty much universal. From the brief look I had at parser games, the world models used seem to differ, so that would be more of a challenge.

[tsanderdev (Tarek Sander)]

@HAL9000

You might have the functionality of ChoiceScript, but not a valid format for their storefront

Right, and that is not my goal anyways (in contrast to the thread you linked, I really just want to replicate the language). I just think ChoiceScript is a nice language for simple choice-based games, and if I can make a functional VSCode extension for it (which shouldn’t be hard once I have made a parser), it should also be enough for my standards code-completion wise. I also think it’s more concise and readable than Ink.

@dfabulich Does the “Make Your Own Games” pages and the subpages contain all commands and such that are available in the language, or are there some things not detailed there?

[Draconis (Daniel Stelzer)]

ChoiceScript is open source (in the informal sense that the source code is available to look at, not the formal sense that it’s got a license letting you use it for any purpose), so if you’ve got permission to use the language, you can look at the specs and the reference implementation too!

Similarly Ink is MIT-licensed and has bindings for Unity, Unreal, and plain JavaScript.

I don’t know Adventuron’s license off the top of my head.

[tsanderdev (Tarek Sander)]

@Draconis

ChoiceScript is open source (in the informal sense that the source code is available to look at, not the formal sense that it’s got a license letting you use it for any purpose), so if you’ve got permission to use the language, you can look at the specs and the reference implementation too!

Specs yes, reference implementation probably no (I couldn’t make sure I don’t subconsciously use some of the code or patterns in that case). And the only “specs” I could find is the documentation on the website, and that’s not a formal definition, more a tutorial.

@Draconis

Similarly Ink is MIT-licensed and has bindings for Unity, Unreal, and plain JavaScript.

Yep, I found that already. JS bindings are neat, but I probably only need the JSON format specification, since I’ll probably have to build the actual player myself to integrate it better.

@Draconis

I don’t know Adventuron’s license off the top of my head.

I didn’t find anything about Adventuron, really. The website has no license, there’s only a bug tracker repository, and the only way to use it seems to be the online editor.

[HAL9000]

@tsanderdev

I didn’t find anything about Adventuron, really. The website has no license, there’s only a bug tracker repository, and the only way to use it seems to be the online editor.

I think this is the last Adventuron package that was made available…
Adventuron Classroom 1.0.0 beta 68j (March 2021) : Chris Ainsley : Free Download, Borrow, and Streaming : Internet Archive

Adventuron has a few online editor links…
Regular → https://adventuron.io/classroom/
Secret → https://adventuron.io/beta/
Super Secret → https://adventuron.io/betabeta/

Anyway, I really like Adventuron’s syntax. I wish Adventuron had an official offline way of making games.

[tsanderdev (Tarek Sander)]

@HAL9000

Anyway, I really like Adventuron’s syntax.

Yeah, it has the easiest and nicest syntax of all parser engines I looked at so far.

@HAL9000

I wish Adventuron had an official offline way of making games.

If you scratch the “official”, looks like I’m about to make that happen .

I’ll concentrate on choice-based games and polishing first before tackling parser games though.

[tsanderdev (Tarek Sander)]

I made another demo game btw, including the source code.

[tsanderdev (Tarek Sander)]

If anyone gets where I have the name of the spaceship (and the whole story, really) in the game from by the way, I’m seriously impressed.

Here’s one tip:

A German sci-fi book series

I also made an accessibility update: I tweaked the standard color palette a bit to match contrast requirements and the entire UI is now navigable by keyboard. I also added some more hotkeys:

• ctrl + s: Open the save dialog
• Escape: Close the topmost dialog
• ctrl + left/right arrow: Navigate the history
• ctrl + shift + r: Reset the story

[dfabulich (Dan Fabulich)]

@tsanderdev

Does the “Make Your Own Games” pages and the subpages contain all commands and such that are available in the language, or are there some things not detailed there?

No, I’d say that ChoiceScript’s documentation is not complete; it certainly doesn’t have anything like a formal “specification.”

@tsanderdev

But ChoiceScript has a bonus of being more popular, so more people are likely to already know it.

Twine is more popular than ChoiceScript or Ink combined. Here’s a quick SQL query I just ran over the public IFDB database export:

MariaDB [ifdb]> select count(id), system from games
where created > '2023-01-01'
group by system order by count(id) desc limit 10;
+-----------+--------------+
| count(id) | system       |
+-----------+--------------+
|       345 | Twine        |
|       105 | Ink          |
|        95 | ChoiceScript |
|        84 | Inform 7     |
|        68 | NULL         |
|        37 | Custom       |
|        25 | Moiki        |
|        21 | Inform 6     |
|        17 | Adventuron   |
|        16 | Ren'Py       |
+-----------+--------------+

So, if you’re picking formats to interpret or fork from, Twine seems like the slam-dunk winner.

@tsanderdev

The problem is that Svelte and Typescript can be very verbose for some things, and ChoiceScript concise syntax for many common things in choice-based games. I would implement a subset of ChoiceScript (the one that describes a single scene since that corresponds roughly to a passage in my system), so you can use ChoiceScript for the parts of your game that neatly fit that model, and fall back to Svelte when you have something complex or layout-heavy that’s not supported.

This already sounds a lot like how Twine works, where you can use the GUI editor to create and define passages, but you can also add JavaScript to any passage, or to the game as a whole.

I’m not sure I’ve fully wrapped my head around your goal here, but if I said to myself, “I really like Twine/ChoiceScript/Adventuron, but I wish they supported TypeScript and Svelte for the tricky stuff,” here’s how I’d handle it.

• I’d use Twine as my base, which is by far the most popular. Plus, it’s fully open source, and already designed make the easy stuff easy and the hard JS stuff possible.
• I’d start by implementing my own Twine story format in Svelte. https://videlais.com/2020/02/28/creating-your-own-twine-2-story-format-part-1-understanding-twine-2-html-structures/
• I think I’d implement it as a preprocessor for Tweego, or one of the other CLI Twine → HTML tools. https://www.motoslave.net/tweego/
• Then, I’d return to https://github.com/klembot/twinejs/issues/1252 and implement a preprocessor PR, which would make it possible for novices to write TS/Svelte in the Twine Editor GUI. (I see you kinda started there, and then changed tack to implementing IF Framework, but if you wanted to implement “Twine + TypeScript/Svelte”, making that a PR for Twine seems like the way to do it, rather than cooking and popularizing a framework from scratch.)

And, with that, I’d declare victory, and start writing a bunch of great interactive fiction in my new Twine TypeScript/Svelte story format.

[tsanderdev (Tarek Sander)]

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. There seems to be a CodeMirror language server plugin, but that works over WebSockets, not in the same tab, so I’d need to rewrite that a bit, too. And currently the editor plugins in Twine don’t get access to the whole story, just the current passage, which would make things like imports impossible to resolve.

And using Twine as a base has not much benefits except userbase (and many of the Twine users probably aren’t interested in heavy use of Typescript in their stories): The Twine application does almost nothing except provide a graphical editor (which you can also have in VSCode, and the tabs in VSCode are much better than in Twine IMO), the rest is provided by the story format anyways. The passages are provided in the HTML blob the story format gets, but the actual implementation in logic and UI has to be done yourself anyways. I’d rather get the power of a dedicated editor in combination with the standard JS build tooling. Twine also currently doesn’t really have a system for assets, Webpack does.

I can probably make a story format based on IF Framework, but that’s not a priority for me. In the meantime I have however figured out everything that is possible in ChoiceScript (at least with all the commands in the documentation), and I’m a bit surprised negative numbers don’t work and you need parentheses for everything. Since I already have to make a parser, I might as well make a ChoiceScript dialect where that’s supported. I already made a Lua parser, so I can just mostly copy the operator precedence code from that one.

The reason why I favor ChoiceScript over Ink: When I look at a ChoiceScript file, I can immediately read it and see what it does. Ink works much more with special characters than commands. Ultimately, I want to support both though.