Best practice for placement of long code following menu choices?

Discuss how to use the Ren'Py engine to create visual novels and story-based games. New releases are announced in this section.
Forum rules
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
Post Reply
Message
Author
BBN_VN
Newbie
Posts: 9
Joined: Sat Feb 20, 2021 1:33 pm
Contact:

Best practice for placement of long code following menu choices?

#1 Post by BBN_VN » Sat Feb 20, 2021 1:38 pm

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!

User avatar
zmook
Regular
Posts: 170
Joined: Wed Aug 26, 2020 6:44 pm
Contact:

Re: Best practice for placement of long code following menu choices?

#2 Post by zmook » Sat Feb 20, 2021 2:03 pm

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.
colin r
➔ if you're an artist and need a bit of help coding your game, feel free to send me a PM

User avatar
_ticlock_
Veteran
Posts: 323
Joined: Mon Oct 26, 2020 5:41 pm
Contact:

Re: Best practice for placement of long code following menu choices?

#3 Post by _ticlock_ » Mon Feb 22, 2021 11:55 pm

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
Newbie
Posts: 9
Joined: Sat Feb 20, 2021 1:33 pm
Contact:

Re: Best practice for placement of long code following menu choices?

#4 Post by BBN_VN » Tue Feb 23, 2021 9:40 am

Thanks both! Much appreciated!

User avatar
ISAWHIM
Veteran
Posts: 288
Joined: Sun Nov 06, 2016 5:34 pm
Contact:

Re: Best practice for placement of long code following menu choices?

#5 Post by ISAWHIM » Mon Mar 01, 2021 11:07 pm

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.)

Post Reply

Who is online

Users browsing this forum: Google [Bot], Majestic-12 [Bot]