Cool to have someone else interested in using Ink in Java. There doesn't seem to be many of us.

I think it is rather unnecessary to have multiple different Java ports of Ink, so ideally, I would like to see the code bases of jink and blade-ink merged so that they end up as just as single library.

Although I'm not a fan of ink's JSON format, the ink architecture is built centrally around it. That could become a problem if it changes too often, though I hope that this will not happen. Assuming inkle is careful about that, your approach of a straight "runtime" port should hopefully prove the better strategy, and I'm willing to abandon most of my code and merge towards your code base.

I'm already using jInk in several apps, though, so before I can merge into the codebase, there are a couple of issues that I need to figure out/look into.

1. Java objects

Basically a must-have requirement for me. For a game that uses lots of in-game state (i.e., every game that I'm interested in doing), the EXTERN FUNCTION syntax creates way too much boilerplate script and java code.

jInk permits the usage of Java objects as variables and allows method calls on Java methods (implemented very simply using reflection). This allows me to insert a "world" object at the start of a script, extract objects as required through that object, and get/change the world state as required by direct method calls.

Need to check if dots are allowed in variables and function names (i.e., is world.getPlayer() a valid function name). If so, it would probably be doable without too huge changes. The ink -> json would just consider objects and methods calls to be regular variables and functions, and all the magic should be possible to do in the runtime in the variable/function evaluation code. If not, then I'm actually not sure how to implement this.

2. Sequence on variable/value

Discussed inkle/ink#57

I use this heavily, and implemented it pretty early in jInk. Would need to have inkle's acceptance of this into the ink language, obviously, but if they accept it, is trivial to implement.

3. Special Instructions

Because jInk runs on ink script files, I've used comments to implement some special functionality into the engine - e.g., to show images, etc.

This will of course not work through Json, as the comments get stripped away. But most of this functionality could probably be moved to methods (especially with 1. above) or a be replaced by the recently proposed tag system: inkle/ink#122

I do have some behavior tree-like behavior that I've implemented using Ink scripts, that might be difficult to do with tags but it should be possible to find some other way to do this functionality.

4. Json Decoding Footprint

Just based off a cursory glance at the Json decoding, it seems like you are not using a streaming parser for the Json decoding. If so, I would be a bit worried about the decoding footprint on Android devices - I do all of my Java game coding for Android, and I've occasionally found decoding of large Json files to be a major issue if they're not streamed, since there are usually other things also requiring lots of memory (images, sound, etc). OOM errors are a pain.

5. Handling changes

One issue I haven't seen discussed yet on Ink's forums is how to handle changes in the game code. Continuous iteration or debugging on game code may often result in game scripts changing after release. This requires some robust save/load functionality to prevent crashes when loading story state from a save file since the knots, stitches and choices saved may no longer exists.

Something to look into - I have issues enough with it today when converting directly from Ink scripts; I can't imagine the problem is much easier in Json.

6. QA/Testing

Always important, of course. I'd want to extend the test set (merging the two test sets would be a good start), and hooking things up to Travis CI or similar should be a must. Ideally combined with mutual code reviews of changes, given how critical the code is to the stability of any game built on top of it.

Your thoughts? I wil probably think of more issues later, but these are the ones that come to mind right away. 1. and 3. are the two points I find a bit worrying; the latter issues are mostly about working out a strategy for a common library, which I think we'll have to do, if this is to make sense for me. Not much point for me to do the work to migrate code to blade-ink's interface if we're going to end up with two forks of the codebase in a year from now.