I suggest you take a look at the script.rpy from the beginning [...]
I was struggling with codes on my own, so I thought it could be a good idea to effectively take a look...
[...] how much sense do 3 tracked variables that depend on each other make in both parts.
It would have made sense if he didn't decided, mid process, to change their meaning.
The more the MC is strict, the less she'll like him, and vice versa. And in the same time the
StrictDaddy and
SugarDaddy independent counters can be used to weight her reaction, and eventually Lara's one.
But like I said, mid process he changed his mind, precisely where I pointed out a problem in my own comment. The worse being that this change is blurred, looking more or less like a "with dissolve" on a
scene statement :
script.rpy:4712
Code:
menu AdmonishAngelRoom:
"Admonish Angelica":
$ AngelRelationship = AngelRelationship - 2
$ AngelicaPissed = 1
[...]
jump AngelicasRoom_Strict
"Be Cool About It":
scene Picture265 with dissolve
$ AngelRelationship = AngelRelationship + 2
$ StrictDaddy = 0
$ SugarDaddy = 1
[...]
jump AngelicasRoom_Cool
label AngelicasRoom_Strict:
$ AngelRelationship = SugarDaddy + StrictDaddy
[...]
label AngelicasRoom_Cool:
$ AngelRelationship = SugarDaddy + StrictDaddy
[...]
The second choice follow the new meaning of the values.
AngelRelationship is a counter, and
StrictDaddy/
SugarDaddy are flags expressed with 0 and 1 instead of
False and
True (he already used this for a lot of things previously in the code).
But the first choice follow just half of this meaning, seeing just
AngelRelationship as a counter.
Then the worse happen, right after this he fall back to the previous meaning of those values and perform his
StrictDaddy/
SugarDaddy... Except that he suddenly decided to addition them instead doing a subtraction.
And after this, the code clearly show that he decided to follow the meaning shown by the second choice...
[side note]
It remind be of tremmi and his "Mother Seduction" game where the meaning of the
sub and
dom value was inverted with each update (once even inside the same update), leading to a game with no sense
Please devs, if you aren't sure to remember the meaning of your values, write it in comment when you create them :
Code:
default StrictDaddy = 0 # Number of time the MC have been strict with Angel
default SugarDaddy = 0 # Number of time the MC have been permissive with Angel
default AngelRelationship = 0 # Level of relationship between MC and Angel
# Equivalent to SugarDaddy - StrictDaddy
[/]
Take your time, try to make a sense of it and tell me how wrong or right I was about it:
https://f95zone.to/threads/babysitters-v0-0-2-t4bbo.30446/post-2353910
You were right.
And as you should have understood by what I said above, while finding a "better" way to express is intent (because I really thing that the
SugarDaddy - StrictDaddy is a good idea to weight the reactions), he changed his mind again before the end of the update.
I will be extremely pleasantly surprised if all the problems have actually been solved in the Patreon version or at least the next update of this game and it will work as the script seems to expect from the beginning to the current end of it.
By seeing the blurred way his mind changing is expressed in the code, I doubt alas
No disrespect to T4bbo, but this really needs some serious thinking about where and how these variables are going, how useful they are and what should be triggering these scenes. The game just started, it's not too late yet to redesign it, because it hasn't been working correctly from the start.
I agree. There's no shame to struggle at first with the meaning of the variables and the way the relationship will be expressed and handled ; I mean, I works (time to time) on my own game since almost one year now, and have changed this meaning thousand time at least. Yet I'm supposed to now works as project manager more than just coders ; please, don't tell my boss
But it need more than just a rewriting of the code. It need to pass some days thinking about it and only about it. Weighting the pros and cons of each possibility, trying to figure how each studied approach can works, then deciding which one is the more appropriated for the intend of the game and sticking to it whatever happen.
This said, looking at the code lead to other things... But firstly,
T4bbo, like Penfold I'm not saying this to be hard on you, but to help you, because I think that your game deserve it.
Code:
try: SugarDaddy
except NameError: SugarDaddy = 0
[...]
Would be way better if wrote :
The intend of the
You must be registered to see the links
statement is to do what your
try/
expect couples do, plus some few things like ensuring that the value will be saved. For now you only have literal values, but if one day you try to do the same with object, not going with the
default approach will blow in your face.
Code:
image Disclaimer = "disclaimer/Disclaimer.png"
image Prolog = "backgrounds/Prolog.jpg"
image Picture1 = "backgrounds/Picture1.jpg"
image Picture1 = "backgrounds/Picture1.jpg"
[...]
Put them all directly into the "game/images/" folder, and you'll be able to address them in the exact same way in your game, without the need all those declaration lines.
Code:
label start:
stop music
scene Disclaimer
menu:
"I confirm.":
jump Intro
You are playing with fire here.
You must be registered to see the links
being a statement that can be labeled, they can really be defined at init level. Therefore, it's not anymore a anonymous block of code like when people put all their statement at 0 indent, but creating a block totally independent of the label. It works, should perhaps works in the future, but can also backfire really hard one day.
So, indent your menu at the same level than the others statements :
Code:
label start:
stop music
scene Disclaimer
menu:
"I confirm.":
jump Intro
Code:
label Intro:
scene Prolog
screen input:
window:
style "nvl_window"
text prompt xalign 0.5 yalign 0.5
input id "input" xalign 0.5 yalign 0.55
use quick_menu
This is the opposite,
screens must always be at 0 of indent. They are totally independent block and should also no be placed into a label. It totally break your code which, for Ren'py, looks now more or less like :
- A label with only one statement (the
scene )
- A block of anonymous statements independent of all label that will be played correctly only because Renpy is kind enough to handle those kind of errors.
Code:
scene Picture1 with dissolve
$ Episode = 1
$ WickHorny = 0
$ WickLie = 0
Here it's better, but still for save compatibility purpose, it's better to define the variables with the help of the
default statement instead of doing it inside the "start" label.
Code:
menu HouseLoiter:
"Work on Photos" if WorkOnPhotos == 0:
$ WorkOnPhotos = 1
mik "I'll get some work on the photos done."
The
You must be registered to see the links
statement have a
You must be registered to see the links
property designed for this :
Code:
default HouseLoiter = set()
menu HouseLoiter:
set HouseLoiter
"Work on Photos":
mik "I'll get some work on the photos done."
[...]
"Go to Work" if len( HouseLoiter ) == 3:
mik "Ok time is up... I should get going..."
Because of the change in the meaning of the variables...
Code:
"Don't Fall For It":
$ AngelRelationship = AngelRelationship - 2
if StrictDaddy == 1:
The condition can be reach in one and only one condition : The player have been strict once, and just once,
and he choose to admonish her.
In all the other case,
StrictDaddy can have a lot of value, but it can't be strictly equal to 1.
