This is most likely of interest to people here: Inkle has released and opensourced their in-house authoring system Ink that they used to write 80 Days. The announcement, the code repository, the official tutorial, and a podcast where they discuss the system.
Hey, that’s awesome news! Thanks!
What he said. I was just coming to do an announcement post, but suffice to say, bump.
Note, the engine is a language+plug-in for Unity so [right now] it’s not an end-to-end system; you can’t “make a game in it”. That said, we hope someone (and it might be us) will knock up a bare-bones player app, or at least a template project, to open that out a bit.
I ran into the Inkle people at GDC last night, and I asked them about this stuff…
Once there’s a JS engine, I’ll try plugging it into GlkOte. That should be easy, and then Lectrote can be a standalone player app for Ink games.
Running Ink games in Lectrote would be awesome, zarf, looking forward to that in the future once their JS engine comes out.
Wow, that sounds like an amazing idea!
That’s how it works, and, sounds awesome. We’re really keen for JS interpreter too; I tend to prototype in JS these days so it’d be directly useful to us.
My gamebookformat tool (see other thread) also parses a simple text-file to JSON (and a bunch of other formats). I have a JSON-player as a work-in-progress (not yet on github). But I think my JSON is different enough from what Ink has to not really make it possible to share any code between them. Otherwise it would have been elegant to have a more universal JSON format generated from different tools that could all be played in the same interpreters, much like how you can take the output game from Inform and run in many different z-machine interpreters. Not that I can argue for many practical or commercial reasons to do that, but from a technological pov it soulds like a fun (and elegant) thing to have.
I thought briefly about adding support for generating Ink-files (or Ink JSON-files) from gamebookformat, but I am not sure if either format can handle links in the text (as opposed to just a list of choices at the end of the text)? If it can handle that I could probably export to Ink quite easily much as I already export to Twine, even if in both cases some features are likely to be lost in translation.
EDIT: gamebook input example:
github.com/lifelike/gamebookfor … s.gamebook
generates this JSON:
github.com/lifelike/gamebookfor … items.json
(Exact format not set in stone and will probably change when the player-code is more complete. The old player-code uses an unholy mess of HTML and JS generated to make the book playable.)
I can mention that I have implemented a Java-based parser/player for Ink scripts, which is also open-source:
It reads Ink files and returns text, choices, etc. It’s not a full implementation of the Ink specs yet, though in time I plan to make it so. I have not implemented a JSON parser/writer; not sure if I will bother, as I really don’t need it (though if anyone feels like implementing it, I’m happy to accept pull requests). It’s fully functional as a script engine, though - I plan to release an Android game with this engine into “early-access” later this month.
I’ll probably implement a stand-alone story player sometime soon (I’ve already done so once, for my Markdown inspired syntax, so this would be a fairly straight port).
There is now also an app for Android that can be used to play simple ink scripts (it’s based on jInk, which is not fully-featured yet, but it handles all the basic constructs).
Also, quill is an on-line scratchpad that can be used to write and test ink scripts.