Ink to graph based nodes about ink-unity-integration HOT 6 CLOSED

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?

from ink-unity-integration.

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!

from ink-unity-integration.

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!

from ink-unity-integration.

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?

from ink-unity-integration.

from ink-unity-integration.

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?

from ink-unity-integration.