Dynamically duplicating a knot ??

[Alex-Sand-0]

Hi, I am looking for some advice on the best way to use ink with some generated content. I have some knot describing a "templated" quest, whose parameters are instantiated from the c# game code. I would like to have several instances of the same templated quest, dynamically generated during the game. The problem: it does not work if they all use the same knot.

Here is a dummy example to better explain the issue:

EXTERNAL hasFoundItem(itemName)
EXTERNAL locateItem(itemName)
-> questSimple( "some magic choucroute" ) 

== questSimple(itemName) == 
    VAR questSimple_itemName = ""
    ~questSimple_itemName = itemName

    {itemfound:-> alreadydone}
    {running: -> running}
    -> start
    = start
        Hello, could you bring me {questSimple_itemName}
        + sure
            Great that you accept!
            ->running
        + Nope
            -> DONE

    = running
        + (itemfound) {hasFoundItem(questSimple_itemName)}  I found it
                Thanks, here is 100 gold
                -> DONE
        + Where can I find it ?
            ~ temp location = locateItem(questSimple_itemName)
            {location}
            -> running
        + bye
            ->DONE

    = alreadydone
        Thanks again for having found {questSimple_itemName}
        ->DONE

// dummy implemetation of external function for testing
=== function locateItem(itemName) ===
    ~ return "{~ somewhere to the west}"
=== function hasFoundItem(itemName) ===
    ~ return RANDOM(1,2)==1        

When the c# code instantiate a new quest, I would call _inkStory.ChoosePathString($"questSimple" , generatedItem); to start the quest. But if the player starts a second quest, the status 'itemfound' would be shared between the quests, resulting in a bug... So my question is, what is the best way to avoid this issue?

... I have been considering several workarounds so far:

• Moving more logic to the C# side. The status "itemfound" of the quest would be managed by the c#, and I could pass it to ink. Problem: the api I would need to communicate between ink and c# could quickly grow and become much more complicated than needed.
• having distinct stories for each quest. But this makes it more difficult to have some shared variables. (maybe the dialogues should be different if a similar quest was already completed)
• Duplicating the quest before compiling, ie having knots questSimple_1, questSimple_2 , ... which would be exact copies of questSimple, with variables questSimple_1_itemName , ... The c# would then call inkStory.ChoosePathString($"questSimple{i}"); where i would be 1 on the quest instance, then 2 ... The main problem of this solution, except for its ugliness, is that it requires to predefine a maximum number of quests during the whole game.
• Finally, I suppose I could duplicate the quest source and recompile the whole ink during the game when a quest is generated. But that looks ugly too, maybe slow, and I do not know how to transfer all the states of the running story to the newly compiled one.

It seems all those potential solutions have significant drawbacks. Is there a better way I am missing?

[GreenCloversGames]

Interesting. You've clearly put a lot of thought into this. Here are some I have.

• You could create a list that is updated in the C# side, but is still a part of ink. Then instead of using the itemfound label, you could check if the item is in the list. You can read more here - https://github.com/inkle/ink/blob/master/Documentation/RunningYourInk.md#working-with-lists The downside is that lists are currently not as documented as they could be, the actual code has plenty of comments, but as I've not used them for this purpose before, I couldn't tell you how easy/hard this would be.
• A quicker, but slightly uglier solution that may be more maintainable, is to have a variable in ink called "founditems" which is a string. Whenever an item is found, add it and a comma. Then you could have the following function:

  ===function hasItemBeenFound(item)
  return founditems ? item

  Then, if the item you are searching for contains the item string, it can return true. I think this might be easiest,

I would probably experiment with the top one first, but then if that didn't work, I would use this.

There may also be a way to use flows, but I don't think visitcounts are independent of each flow.

[Alex-Sand-0]

Hi, thanks for these ideas! They should indeed limit the size of the api between ink and c# compared to what I had in mind. However they still require a bit more specific logic, I still hope to be able to simply use the visitcounts from ink.

Note: I am letting the topic open for now in case someone brings more ideas.