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.
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.
➔ if you're an artist and need a bit of help coding your game, feel free to send me a PM
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.
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.)
Users browsing this forum: No registered users