Twison or Jailbird?

I want to compile my game to JSON. I’ve found two tools that do exactly that. Twison and Jailbird.

Coincidently, the last update for both of them was in 2020. Twison seems straightforward but Jailbird has a custom schema and an npm package (mixed it with Spindle) which are nice touches.

Has anyone used either of these tools? Are there any pitfalls to look out for?

I haven’t used either. However, if you’re looking for a way to convert Twine code into a text file, you might want to consider using Tweego, which allows you to convert a Twine HTML file to a text file using Twee notation, and it can also convert a Twee file into a compiled HTML file. Furthermore, Twee notation is a lot more human-readable than JSON is, if that matters.

Hope that helps! :slight_smile:


Thanks, but I actually already use twee/tweego. I want to compile to JSON because I’m building my own engine (of sorts). The idea is to run the game in a custom component instead of the default html. It’ll make it easier to turn the game into a stand-alone app later.

As converting a Twine based project into a JSON based one generally involves removing all Story Format specific functionality (like Markup based links and all Macro calls), I’m curious to know what exactly is gained by using the Twine 2.x application to create what essentially ends up being a series of Textual content “Passage” instances?

eg. Basically the equivalent of following…

	"Passages": [
		{"id": 1, "name": "Start", "content": "Blah blah"},
		{"id": 2, "name": "Hallway", "content": "Blah blah"},
		{"id": 2, "name": "Library", "content": "Blah blah"}

I’m not using the Twine editor, I’m using VS Code and Twee Notation. It’s just a lot more confortable writing free form than writing straight in json. Besides it’s not entirely true that I loose macros and whatnot. I just have to replicate them in my on engine, pre-parsing the text content before displaying.

I’m already using Snowman which is a terse, barebones Story Format. It’s different to Ink in that I can use plain JS when I need some logic instead of the Ink’s specific syntax, and having to bind a lot of external functions.

I need more flexibility than Twine’s default XML output, which is heavily coupled to the Story Format’s HTML.