Scoping #685
Replies: 1 comment 1 reply
-
Hey! So this is generally a pretty bad idea (despite being the "programming" thing to do). It causes ink to be in a callstack of tunnels all the time - but if you save the game inside a callstack, and edit the source ink in such a way that ink relabels something higher up in that callstack (which isn't always obvious, as a lot of ink's labels are automatic), then when you reload that save it will only crash / go awry when the tunnel is exited: possibly several turns later. (It's a good idea to never save the game inside a tunnel if you can avoid it.) Tunnels aren't really intended as structuring devices - that's not actually useful, if there's a single return point! Instead they're useful when a piece of content can result from lots of different actions in the script. For scoping, I use "hub" knots, for the local scope, by which I just mean a loop point with some actions, that when you do them, the flow loops back to that loop point. (With another option to move along to the next hub, say.) Then any wider scope actions - say conversations you can have with a sidekick anywhere - are threaded in. So the local scope brings in the wider scope, if it wants to. I hope that all makes sense! |
Beta Was this translation helpful? Give feedback.
-
@joningold Hello, I have a question for you regarding scoping (in reference to your heavens vault talk). Do you use tunnels for that? From a high-level overview, I believe I understand how it works but could you provide a short example of an implementation?
I gravitate towards tunnels for scoping, it feels like it makes the most sense to use since it's basically a function call and returns back to play the next piece of content (and then loop back to the top of the thread if necessary) but is that a good idea to do so? What do you think?
Beta Was this translation helpful? Give feedback.
All reactions