You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In most games, game state that is not handled by Ink itself can change after an ink knot has already been rendered.
This can render Ink's story state stale.
For example, imagine I can pick up an item on the story scene told by the current knot. This could happen via an external function call from Ink into your game. However, if one of the choices in the current knot is itself dependent on the player owning that particular item (e.g. via conditional diverts), the current scene state is now stale and needs to be refreshed.
I have not found a clean way to do that with inkgd. The primary issue is that inkgd forgets the current path as soon as it has finished playing the current knot (i.e. it current_path always returns null so you cannot remember it). I have to work around this by capturing this state manually in a data structure StorySegment by capturing internal inkgd state such as path pointers before allowing the story to continue:
I use the same mechanism to provide a scene refresh function, which "rewinds" inkgd's state to the current knot by replaying the captured pathname onto InkPlayer#choose_path and then call InkPlayer#continue_story:
However, this is clearly a workaround, and it has some unintended side effects such as incrementing the visit count, when the player really only visited this scene once.
I think it would be helpful to:
provide a getter that returns the current path string from InkPlayer even after the continued signal fired, so that we can feed it back to the player
provide a refresh or reload method that reloads the current knot without affecting visit counts, so that Ink variables and conditionals get re-evaluated.
The text was updated successfully, but these errors were encountered:
In most games, game state that is not handled by Ink itself can change after an ink knot has already been rendered.
This can render Ink's story state stale.
For example, imagine I can pick up an item on the story scene told by the current knot. This could happen via an
external
function call from Ink into your game. However, if one of the choices in the current knot is itself dependent on the player owning that particular item (e.g. via conditional diverts), the current scene state is now stale and needs to be refreshed.I have not found a clean way to do that with
inkgd
. The primary issue is that inkgd forgets the current path as soon as it has finished playing the current knot (i.e. itcurrent_path
always returnsnull
so you cannot remember it). I have to work around this by capturing this state manually in a data structureStorySegment
by capturing internal inkgd state such as path pointers before allowing the story to continue:I use the same mechanism to provide a scene refresh function, which "rewinds" inkgd's state to the current knot by replaying the captured pathname onto
InkPlayer#choose_path
and then callInkPlayer#continue_story
:However, this is clearly a workaround, and it has some unintended side effects such as incrementing the visit count, when the player really only visited this scene once.
I think it would be helpful to:
InkPlayer
even after thecontinued
signal fired, so that we can feed it back to the playerrefresh
orreload
method that reloads the current knot without affecting visit counts, so that Ink variables and conditionals get re-evaluated.The text was updated successfully, but these errors were encountered: