Ren'Py Quick syntax question

[baloneysammich]

I'm not a dev, I just occasionally look at renpy code.

One game I'm looking at seems very well coded in many ways, but the dev frequently has one-or-the-other choices like:

menu:
    "Yes"
        ...
        if said_no == True:
            $ said_no = False
        ...
    "No"
        ...
        if said_no == False:
            $ said_no = True
        ...
...

What purpose do the if clauses serve? Wouldn't the outcome be the same with just the assignment statements?

 

[79flavors]

What purpose do the if clauses serve? Wouldn't the outcome be the same with just the assignment statements?

Your example looks like you've re-written the code to be an example. You may have removed the important bits of code that might explain why they've done it that way.
Maybe name the game...? so those of us with programming skills can go check ourselves?

Meanwhile... If I had to guess, I'd say it's to stop the player picking the same choice twice. I'd expect to see the game looping back around to that same menu: somewhere and a bit of extra code you haven't included.

Failing that... I will point out that a lot of developers of games aren't always perfect. Even knowledgeable programmers can sometimes have a clever idea that in hindsight looks like dog shit. And that's presuming that the code wasn't cut and paste from somewhere else and adapted very late at night when the programmer should have been asleep 5 hours ago.

My personal facepalm is code that looks like:

menu:
    "Yes"
        $ said_no = False
        "I say yes."
        pass

    "No"
        $ said_no = True
        "I say no."
        pass

# ...

Because at sometime in the past, the author found out that pass exists and didn't really understand WHY it exists.

If it works... it's fine. Sometimes it's best not to look under the hood.

 

[baloneysammich]

Your example looks like you've re-written the code to be an example. You may have removed the important bits of code that might explain why they've done it that way.
Maybe name the game...? so those of us with programming skills can go check ourselves?

I removed code and withheld details because it IMO would be uncouth to identify the developer in a case like this.

I assure you the only flow control I left out was that each choice block ended with a jump to the same label, which in retrospect I shouldn't have excluded.

So to simplify, would you agree that these two would result in the same outcome?

menu:
    "Yes":
        if said_no == True:
            $ said_no = False
        "Yes"
        jump scene1
    "No":
        if said_no == False:
            $ said_no = True
        "No"
        jump scene1
label scene1:
    ...

menu:
    "Yes":
        $ said_no = False
        "Yes"
        jump scene1
    "No":
        $ said_no = True
        "No"
        jump scene1
label scene1:
    ...

It seems self-evident to me that they would, but I'm only familiar with native python scripting, not renpy.

 

[Rich]

Yes, those two blocks would have the same effect.

 

[79flavors]

Okay. I've looked at the original game... and yeah, it's completely bonkers.

It's not an isolated case either... they've coded almost everything in the game like this.
There's no logical reason I can see behind the choice.
I was thinking perhaps some obscure way of dealing with incompatible save files or something odd... but nope. Or perhaps some sort of "New Game+" mechanic where the player can start again, retaining some unlocks from the previous play through.... Nope... not that either.

It's not the only odd pattern to the code either. They tend to jump to labels immediately below the current code... as if things wouldn't end up there anyway. They also tend to avoiding using else: and repeat 90% of the same code whether they're checking for True or False.

The gameplay is linear so far and the times when the values are set to False are mutually exclusive with the times they are set to True. Default values are loaded in an init: block rather than using default, but that's just programming style I guess, albeit a bit dated imo.

On the whole, the game works as intended. Nothing in the code actually breaks the game, the engine or even causes any direct or indirect issues... it's just bonkers when you look at the source code. It's like someone decided to think of the hardest way they could think of to code stuff and said "yup... let's do it that way".

 

[anne O'nymous]

They tend to jump to labels immediately below the current code... as if things wouldn't end up there anyway.

This isn't an odd practice, at least from the point of view of a modder. config.label_overrides works only if the overwrote label is jumped to or called, jumping to the following label, even if Ren'py would naturally continue with it, offer a better control to the modder.

It's like someone decided to think of the hardest way they could think of to code stuff and said "yup... let's do it that way".

I haven't looked at the code, in fact I don't even found the game (I haven't the time to play lately, so it must be one that are waiting) but from what you say, it looks more like pure academical code :

• Do not perform useless manipulation.
  

  if the_value_isnt_already_correct:
      assign_the_correct_value

• Initialize all your variables before the program start.
  Which explain the init blocks in place of the default statements that are more obscure.
• Never do something implicit, always be explicit.
  Which explain the jump to the following label.