When it comes to organizing scripts and scenes, is there an ideal way to do it?
Yes, there is an ideal way to do it: The one you feel the most at ease with.
This being said, should be avoided the fact to put everything in a single file, and anonymous names ("flag01", "flag02", "kissingScene01", "action02", etc.) for the label, variables, whatever.
What matters is that you (and if it apply the persons working with you) understand the organization and can find relatively easily what you (or they) are looking for.
Making a game, especially as hobby and therefore on your free time, need time, a very long time that will spread over years. During all that time, there will be low moment, when you are over saturated and just want to throw the game to the trash. For this reason, it's important that you don't have to struggle more than necessary.
Let's say that you need to use the variable that tell you if the first kiss between the MC and a girl happened in the park or in the coffee shop.
Ideally, the name of the variable should be explicit enough for you to remember it. But let's be honest, whatever how explicit you named the variable, after not having to used it for months, you'll not remember it. Therefore, you should know in what file you'll have to search for it, as well as, globally, at what place of that file you'll find it. And the name should be explicit enough for you to recognize it when you see it.
Be noted that explicit names also help you to understand your code. You'll look back at something you wrote months ago, see
if whateverVariableName == "42", and the name, as well as the value, should be enough for you to remember what you are testing.
It's why anonymous names are to avoid at all cost. It's what make the difference between:
Python:
label park052:
[...]
if flag07 == 3:
GIRL1 "Do you remember, what happened here two years ago ?"
[...]
and:
Python:
label girl1McParkReminiscent:
[...]
if girl1FirstKiss == "park":
GIRL1 "Do you remember, what happened here two years ago ?"
[...]
In the first case, you know that it's a scene in the park, and will need to read the dialog to find what the condition mean. In the second, you know precisely what scene in the park happen, and just reading the condition tell you what it mean.
It's time saved, and struggling avoided. As insignificant it can seem to save few seconds that way, when it happen 100 times a day, it starts to make sens.
I'd assume there's thinking behind it, like organizing by scene because it might be easier to debug, but does that not increase more work and introduce possible continuity bugs?
There will be bugs anyway. Therefore what matters isn't much, "oh, I should do like this, it should reduce the number of bug", than, "I should do like that, it will be easier to find the bugs".
It's Wednesday afternoon, you just come back from works. You're excited, because you released the new update last night, and want to know what people think about it.
You open your Patreon page, your game thread here, or whatever other media where you can get feedback.
And then you see people saying that "hey, in the coffee scene, after the second girl leaved, there's few time where it's not the right person that say the dialog line". Ideally someone give you the lines and you can just do a search... But we don't live in an ideal world, people will rarely say more that what I put in quotation marks.
Knowing in what label you'll find the said "coffee scene after the second girl leaved" will make life way easier for you, than if you've to browse the whole "update5" label to find when is the scene.
So, yes, as you think it's easier to debug. What is false in your assertion is to believe that it will prevent continuity bugs. Unless you make a Kinetic Novel, you'll have embedded menus, and if structures, possibly up to ten levels. You'll quickly lost track of where you are and where you should go next:
Python:
label whatever:
menu:
"choice 1":
if condition1:
if condition2:
menu:
"choice 1":
if condition3:
else:
"choice 2:"
else:
menu:
"choice 1":
"choice 2":
else:
if condition 4:
menu:
"choice 1":
"choice 2":
else:
if condition5:
else:
"choice 2":
[...]
compared to something more explicit:
Python:
label whatever:
menu:
"choice 1":
jump whateverChoice1
"choice 2":
jump whateverChoice2
label whateverChoice1:
if condition1:
jump whateverChoice1Condition1
[implicit "condition 1 is false"]
jump whateverCommonAfterCondition1
label whateverChoice1Condition1True:
if condition2:
jump whateverChoice1Condition1Then2
[implicit "condition 2 is false"]
jump whateverCommonAfterCondition1Then2
[...]
It also limits the code you have to write, because there's part of the code that will apply to more than one context:
Python:
label whatever:
menu:
"choice 1":
[specific to choice1]
if condition1:
[common part]
else:
[specific to choice 1]
[specific to choice1]
"choice 2":
[specific to choice2]
if condition2 and condition3:
[common part]
else:
[specific to choice 2]
[specific to choice2]
compared to:
Python:
label whatever:
menu:
"choice 1":
$ temporaryValue = "choice 1"
jump whateverChoice1
"choice 2":
$ temporaryValue = "choice 2"
jump whateverChoice2
label whateverChoice1:
[specific to choice1]
if condition1:
jump whateverCommonPar
else:
[specific to choice 1]
jump whateverChoice1Continue
label whateverChoice2:
[specific to choice2]
if condition2 and condition3:
jump whateverCommonPar
else:
[specific to choice 2]
jump whateverChoice2Continue
label whateverCommonPart:
[common part]
if temporaryValue = "choice 1":
jump whateverChoice1Continue
else:
jump whateverChoice2Continue
label whateverChoice1Continue:
[specific to choice1]
jump whateverAfterChoice
label whateverChoice2Continue:
[specific to choice2]
jump whateverAfterChoice
You wrote the common part only once, what mean less works for you, less risk of errors, and less risk for forgot to correct one occurrence of the code because you forgot that it appear twice.
Aside from really basic stuff like "Learn how to write Renpy" or "Watch Daz Tutorials," what are some things I should consider before doing my project?
Firstly you must know the whole story, from starts to stop.
Not all the dialog lines for all the scenes, but all the key points and their order. And by "knowing" I don't mean "in your head", it must be wrote somewhere. That way you know where you're going, even in a far future, what permit you to stay consistent and to anticipate the future.
If a girl is planing a surprise birthday party for the MC, she don't do it when the update containing the party is released. She starts doing it days, if not weeks, before. This have an impact on her attitude, and this should be visible (but not necessarily understandable) for the player.
In
Triple Ex by example, the sister is now pregnant. Two update before we learned it, her behavior started to change. The player didn't noticed it in the first update ; she was eating more and never visible early in the morning. In the second update, the player caught her sick in the morning ; those who thought about it, adding the fact that she eat more, had a strong clue regarding the reason. Then finally appear the update where her pregnancy was announced to the player.
This is only possible if you know beforehand that she'll be pregnant, and that it will be announced in "that scene".
It's why you need to know your whole story, and all the impacting element in it, before you starts writing. Whatever how good your story is, and how good you are at writing, your game will feel better thanks to this. Even if the player don't get the clue, when the situation will finally happen he'll be "oh, so it's why [whatever]... Well played dev, well played".
Secondly, you must code all your game mechanism before you starts your game.
Even if it's something that will not appear before the tenth update, you must have the code before the very first release. You'll struggle to make it works, it's mandatory, even me would struggle. So, it's better to struggle before you have the player pressure on your shoulders.
It also avoid false promises. Whatever game mechanism you promises, you know that you'll be able to do it, because it's already done. This permit to not have a game with a smartphone icon, and a "Will come soon" that appear when you click on it, this while it's obvious that the game will be finished soon.
Thirdly, you must already know what assets you'll use for each elements of the game.
You don't necessarily need to get them right from the starts, but know what you'll use will be time saver ; there's tons of assets, searching for the right one can take full day.
Plus, when you put this in perspective with the first point, it permit you to anticipate. "Hey, you know, my uncle have a beach house. If I ask him nicely, I'm sure that he would let me use it. It's big enough, we could all pass a week-end there". This is great, but only if you don't end using a small hut for the said beach house, something clearly too small for everyone to fit in during a whole week-end.
