Best practice for placement of long code following menu choices?

[BBN_VN]

Hi all. New user here. I think I got the right sub-forum for this question but many apologies if not.

I'm working on a set of menu choices, each of which trigger mutually exclusive but lengthy sequences of dialogue and scenes. I'm wondering whether there is a best practice or general recommendation for keeping all of that code within the menu choice, or if the choice should include a jump instruction to a particular label with the code beneath the label.

I hope that makes sense. It may just come down to personal preference but, even if so, I'm interested in hearing what folks' preferences are and why.

Thanks!

[zmook]

Usually it's most readable if you can have all the menu choices visible at once on your screen. So I'd put in jumps in the choice blocks get too long for that. Use descriptive labels so you can tell just by looking at the name what happens in that section.

[_ticlock_]

I agree with zmook.

There is also an option to use the collapse/expand function of the code editor to show/hide the indented region of the code. It can be handy in many cases and if after-choice lines are reasonably long (0.5-2 screens) you may prefer to use it instead.

[BBN_VN]

Thanks both! Much appreciated!

[ISAWHIM]

I try to keep pseudo-code and real code together. Only isolating dialogue from those elements, where possible. Though, for a complex structure, within a "choice", I would attempt to use a label, as if using python code for a "function" or a "subroutine". I like to keep that formal structure as clean as possible, as some of my "choices" can get complex at times, or code-full. (Altering many things in code, at once, like stats.) It's best to not clutter an indentation nightmare with more indentation nightmares, if possible.

When I write, I isolate things into, "dialogue-runs". I try to never mix "dialogue" with "code" or "pseudo-code", like a, "choices block". It helps to keep things organized and easy to translate.

When I make a new "run", it simply gets a new Label_ID, and "returns", back to where it jumped from, once it is done. It stops the confusion of nested choices and code, from mixing with the text dialogue. That can become a nightmare when trying to locate things.

Keep dialogue jumps in another file, and have that file open at the same time as you edit the code-structure of choices and game values. You can help make things structured, if needed, by adding small tags to your labels. "Choice_4_sel_3" (Choice #4, Selection #3)... etc... But I simply label them as they are created. "Run_0123", "Run_0124"... A quick search, in either file, will locate the origin of the jumps and labels, if needed.

This also makes updates easy and continuing easy too. When I make an update, it is in a new file and the old one never changes. Both for the pseudo-code-parts, code-parts and for the dialogue-runs.

You can also see if your "runs" are getting too long, or not long enough. (Some people don't like things to be long-winded, like a normal book. Especially when made on a platform designed for interactions. It's easy to split-up the monotony of "click to continue reading more", and add some kind of pause to a dialogue-run. Even if it's just a non-essential choice or visual change-up.)