Ink to graph based nodes

[joaobsneto]

Hi guys,

I'm making an adventure game and our team has written the whole script in ink. My idea is to import all the text, diverts, choices from the ink into a FSM (Playmaker). I was able to make it work in simple cases, but when I have more complex structures, the generation leads to very bad results. I think most of the problems is how I implement glue left/right ("<G" or ">G" in JSON) and conditional divert. Do you have any tips on how to iterate over the Story content?
I'm recursively iterating over containers, but when comes to glue, it brakes the code if you have more than one step. Is there some part of the documentation for that?

Thanks!

[joethephish]

Hmm - my first question is really - why not use the standard ink engine rather than attempting to convert it into a Playmaker? To ask a dumb question - you know about story.Continue() for iterating over the content, right?

While the very basics of ink can be straightforward, as a whole it's a pretty complex language, and the intermediate JSON-based format (and the runtime loaded version of it) is much more machine-centric and less human friendly.

I imagine converting it into a Playmaker would also make it a lot slower. That's a bit like compiling C to Playmaker 😱

If you really want Playmaker integration, I'd suggest doing it on a scene-by-scene basis or something? I don't know Playmaker at all, but could you make a hook which tells ink to run a knot?

[joaobsneto]

Thanks for replying. I saw your GDC talk about ink whichs made me use this amazing tecnology.

I'm not making a text-based game, it's a modern adventure game like Telltale's games or Life is Strange. There are commands to be sent to game actors. We use ink because is very easy to write and test. It's a pain to create diagrams of conversations by hand.

Using ink as an engine in runtime might be a good idea, but I would have to store a lot of the game logic in it. Besides, the game would need to process the ink file in runtime and send the messages to the actors and I think this is more demanding, because it is a lot of text-processing. The idea is to pre-process and store only the needed information with IDs, enums and int variables.

We are using a sublanguage of ink to make a conversation system. All we need are texts, diverts, choices and variable's test and assignment. Basically, there is a format for speech:
SOURCE_ACTOR (TARGET_ACTOR) : "MESSAGE".
A text string with that will correspond a node with an action (Playmaker custom action SaySpeech) to make the SOURCE_ACTOR says the MESSAGE to TARGET_ACTOR. We create an ID for the MESSAGE so we can store it in a multilanguage system and relate with an audio file. The Playmaker action send to the ActorController the data it needs to say the MESSAGE.
The same is applied to the other features that are interessing to us.

I have implemented this, and it works in some cases, but when it has nested choices, diverts and glues, the links between nodes are placed wrong.
I'm really familiar with story.Continue(), trying to reverse engineer it's code, but the glue part gets me confussed.

Thanks again!

[joethephish]

This is basically exactly what we're doing on Heaven's Vault. Which talk of mine did you see? My first one (2016) is when we introduced ink, but my talk from this year (2017) is all about exactly what you're talking about - treating the ink script effectively as an interactive film script, which gives instructions to the actors on the virtual stage.

We do look at the output text line by line and use them as instructions. But the line-by-line instructions by this stage are in a really simple format to parse - e.g. CharacterName: Dialogue line or FACE CharacterName Target.

I'm afraid I'd strongly recommend that don't attempt to step through the internal containers by hand - you'll definitely get into a pickle!

[joaobsneto]

I saw your first talk. So sad that your talk from 2017 is not on GDC Vault. Wow, I just saw some posts of Heaven's Vault tumblr, amazing, I didn't know about this game, seems a must buy. I'm in the middle of this now... it is very hard for me to say to my team: "guys, we have to change everything...".

But, if we adopt ink as the engine of game's logic, how do you handle multiple "conversations" happening at the same time and using/changing the variables from ink scope?

[joningold]

The question "how do you handle multiple "conversations" happing in the same time" seems to come up a lot; I guess it must be a Playmaker way of thinking about things - parallel state machines running at once. Ink is pretty different as an underlying model. You could, for instance, associate an ink knot with each character/object in the world. In each knot, do nothing but provide a list of choices, all the things that the player can do with/say to that character/object, using ink conditionals to turn things on and off. Then on each turn, run each knot in scope and collect up all the choices being offered to the player, and present them in the game. Whatever the player actually does, pick that choice using ChoosePathString, run the ink that results, and then end, and poll the hub knots again. NPCs could act independently too, just make their actions into choices with a markup that tells the game "this happens after 3 idle seconds", or whatever you condition might be. (Note this loses the ability to be in the "middle" of a weave of ink with any given character; instead you have to keep going back to the hub. Depending on what you're doing that could be a fail, or it might turn out to be no big deal - it's no big deal for us, because if you're mid-conversation you're talking to someone, and if you go talk to someone else, then that first conversation is dead anyway because you wandered off. Depends what you're trying to do.) cheers jon

…

On Wed, Oct 11, 2017 at 7:28 PM joaobsneto ***@***.***> wrote: I saw your first talk. So sad that your talk from 2017 is not on GDC Vault. Wow, I just saw some posts of Heaven's Vault tumblr, amazing, I didn't know about this game, seems a must buy. I'm in the middle of this now... it is very hard for me to say to my team: "guys, we have to change everything...". But, if we adopt ink as the engine of game's logic, how do you handle multiple "conversations" happing in the same time and using/changing the variables from ink scope? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA40o_QtzbcgyzwqUuGXYd17uRSid1M3ks5srQjogaJpZM4Pxbr7> .

[joaobsneto]

Thanks Jon!

We are making the failing case... 😧

Actually, we are doing a prototype version of our game that uses that logic. We made every place, every interactable object and every conversation as an option that becomes available by the time and game state variables. It's good, but it does not translate into the 3D game very well. We use it as a text-based version of the game to test the script and game's flow.

In our game, there are many characters doing their own thing, not related with player action or presence. So, if player at minute 2 enters in a conversation and then leaves at minute 3, but there is other ongoing conversation that started at minute 2 and player attempt to enter or hear that conversation, he can not hear characters lines from minute 2 to 3, that is, player can enter/hear a conversation at any time. By the knot logic, you will always get the data from the start of it (at least from what I know). Even if player is not in conversation, the interaction group might be in his field of view. So, the game must run independly of player presence.

My model in mind, like you said, is a state machine for each character and every conversation is one state machine that takes control of characters inside the conversation.

I make every conversation a sepated ink file. The same file that we use in prototype is used to build the FSM.

The file "ArchitectureAndDevOverview.md" is very helpful resource for me. Do you have any plans to update it?