Ren'Py Routine question

[coffeeaddicted]

I am wondering if there is a more elegant solution to have a code somewhere else, perhaps another file, where it just checks if a condition is met.
It seems silly to have to add that code ever time an instance is present like a situation or a question.

In my case, i want to show several different images that are layered above the render.

So i have something like this.

label dontcare:
show scene12 with dissolve
a "I got to have it. From your uncle to me? Give it to me."
$ gullible +=1
$ bimbo +=1
if bimbo ==10:
    show bimbo with dissolve
    $ renpy.pause (5)
    if gullible ==10:
        show journeytodumb with dissolve
        $ renpy.pause (5)
        if sex ==10:
            show experience with dissolve
            $ renpry.pause (5)

So essentially it will check if value 10 is reached and put an image on top of the other and disappears after 5 seconds.
But i am wondering if i can just put that routine in a file and forget about it. Is that possible?
No? Shit.
Because i need to add more conditions and then the code really looks like something.
I think i would like to have it more organized in a way but i am not sure if RenPy allows that.
Does this make sense?

 

[79flavors]

Yes... But...

It depends on your game.

A lot of story driven games are quite linear and therefore the number of places where something like bimbo or gullible or sex might reach 10 would be quite limited. Limited enough to be worth repeating the same code without being too worried about that repetition.

A more sandbox style game would usually have a hub (a label) or set of hubs around which the core gameplay loop of the game is arranged. A check like this could be placed there, and despite the fact that the game might execute that code a lot of times, it's only located once within the game.

But... to also offer a solution...

I dislike mentioning it... but there is a command called call (not to be confused with call screen which is completely different). Most new developers, especially RenPy developers are best to avoid call completely and only use jump. However it might be a good fit here.

call is similar to jump except it stores where the call is used and puts the details on something called the call stack. Each new entry is added to the end of the call stack. When the game encounters a return command, the details are retrieved from the end of the call stack and the game jumps back to that point and carries on.

The mistake new RenPy developers make is not strictly following the rule that for every call there must be a return executed too. It get worse in sandbox games, where there might be buttons or something on screen which the player can click on and jump to somewhere else within the code (and thereby end up jumping out of the called section of code without executing the return. Anyway, despite this warning...

I'm imagining something like this:

# ... somewhere in the middle of your game

call increase_bimbo_score

# ... and your game just continues...

# ...
# ...
# ...
# somewhere else in your code...

label increase_bimbo_score:

    $ bimbo += 1
    if bimbo == 10:
        $ renpy.notify("Bimbo has reached 10")

    return

label increase_gullible_score:

    $ gullible += 1
    if gullible == 10:
        $ renpy.notify("Gullible has reached 10")

    return

label increase_sex_score:

    $ sex += 1
    if sex == 10:
        $ renpy.notify("Sex has reached 10")

    return

$renpy.notify() uses screen notify(): and so it's possible for you to do something similar where the code invokes a show screen {screenname}() that shows your image and then removes the shown screen after a short amount of time.

This is RenPy... there are lots of other ways too.

 

[anne O'nymous]

[snip the answer I was starting to write]

I'm imagining something like this:

call increase_bimbo_score
[...]
label increase_bimbo_score:

    $ bimbo += 1
    if bimbo == 10:
        $ renpy.notify("Bimbo has reached 10")

    return
[...]

A bit more versatile, increase and decrease with only one label:

label whatever:
    call bimbo_score( 1 )
    [...]

label whateverelse:
    call bimbo_score( -1 )

label bimbo_score( step ):

    $ bimbo += step
    if bimbo == 10:
        $ renpy.notify("Bimbo has reached 10")

    return

Second advantage, you can increase and decrease by more than one unit when it's needed.



Now, there's something odd with what Yester64 said...

[...]
if bimbo ==10:
    show bimbo with dissolve
    $ renpy.pause (5)
    if gullible ==10:
        show journeytodumb with dissolve
        $ renpy.pause (5)
        if sex ==10:
            show experience with dissolve
            $ renpry.pause (5)

So essentially it will check if value 10 is reached and put an image on top of the other and disappears after 5 seconds.

How is it that it "disappears after 5 seconds" ? There's no hide to... well, hide, the image. So, does this mean that you use show when you should use scene ? 79flavors have a post somewhere explaining why it's bad, but I don't remember where


This being said, if it's effectively show for 5 seconds, then replace by something else, there's probably something doable with a mix of

You must be registered to see the links

and

You must be registered to see the links

displayable.

My diner is cooking, so I don't have the time to test it, but I guess that something like this could do it:

image bimboGullibleSex:
    "bimbo"
    pause 5
    "journeytodumb"
    pause 5
    "experience"
    pause 5

image bimboGullible:
    "bimbo"
    pause 5
    "journeytodumb"
    pause 5

image bimboSolo:
    "bimbo"
    pause 5

image change = ConditionSwitch(
    "bimbo == 10 and gullible == 10 and sex == 10", "bimboGullibleSex",
    "bimbo == 10 and gullible == 10", "bimboGullible",
    "bimbo == 10", "bimboSolo",
    "True", Solid( "#00000000" ) )

label whatever:
    [...]
    $ gullible +=1
    $ bimbo +=1
    show change with dissolve

Side note, == is not really the good condition here. >= would be better, since it wouldn't limit to the sole case where the three are strictly equal to 10.

 

[coffeeaddicted]

I will try that out.

It just seems, at least in my mind, that in other language this is more common and not to reinvent the wheel several times.
And the code gets also more unreadable plus the errors that will happen.

Essentially for this game, each stage of a reached value should trigger a notification in form of an image that will be displayed. But only once.
In my run yesterday, not thinking about the consequences, it surely called it several times but i did use ">" instead of "==". So that makes a difference as well.

The game itself has a stat system that i took from Zeil. Simple but all i need really. I will probably also include a quest system (basic) plus a choice where to go or not to go. Perhaps a map, though i am not sure if that will be an overkill. All it should do is, ask the player where do you want to go?

So bad returning to the code. This seems more efficient indeed and can be done with the long code.
I had planned to do several of these slides, kind of like an achievement.
Though i haven't ruled out where the end point is. Yet.

I really need to print out the RenPy documentation. Online reading is not really my thing. I usually miss things.

 

[coffeeaddicted]

[snip the answer I was starting to write]



A bit more versatile, increase and decrease with only one label:

label whatever:
    call bimbo_score( 1 )
    [...]

label whateverelse:
    call bimbo_score( -1 )

label bimbo_score( step ):

    $ bimbo += step
    if bimbo == 10:
        $ renpy.notify("Bimbo has reached 10")

    return

Second advantage, you can increase and decrease by more than one unit when it's needed.



Now, there's something odd with what Yester64 said...


How is it that it "disappears after 5 seconds" ? There's no hide to... well, hide, the image. So, does this mean that you use show when you should use scene ? 79flavors have a post somewhere explaining why it's bad, but I don't remember where


This being said, if it's effectively show for 5 seconds, then replace by something else, there's probably something doable with a mix of

You must be registered to see the links

and

You must be registered to see the links

displayable.

My diner is cooking, so I don't have the time to test it, but I guess that something like this could do it:

image bimboGullibleSex:
    "bimbo"
    pause 5
    "journeytodumb"
    pause 5
    "experience"
    pause 5

image bimboGullible:
    "bimbo"
    pause 5
    "journeytodumb"
    pause 5

image bimboSolo:
    "bimbo"
    pause 5

image change = ConditionSwitch(
    "bimbo == 10 and gullible == 10 and sex == 10", "bimboGullibleSex",
    "bimbo == 10 and gullible == 10", "bimboGullible",
    "bimbo == 10", "bimboSolo",
    "True", Solid( "#00000000" ) )

label whatever:
    [...]
    $ gullible +=1
    $ bimbo +=1
    show change with dissolve

Side note, == is not really the good condition here. >= would be better, since it wouldn't limit to the sole case where the three are strictly equal to 10.

Oh my bad.
Yes, this true. I used the show command to blast the image over the other. It waited 5 sec and moved on. I take the better solution.

The condition was what i used before but it let do some strange behavior. Like there was a delay for any other follow up situation which i assumed was the condition formula but it could also been the not hide command. Not sure really. Probably because i used "show" instead of "Scene".
I have to check if RenPy actually has a dev log where you can analys a run.

Oh, the image is just really a splash screen. So it won't need to be replaced by anything. Until of course the condition changes.

 

[79flavors]

If you know other programming languages, then call is likely familiar to you... along with the potential pitfalls.
RenPy throws in the non-linear spanner into the mix though, with triggerable events breaking you out of controlled areas of your code when you didn't think it through.

Meanwhile, I did assume that your "bimbo", "gullible" and "sex" popups were smaller images rather than full screen images - and therefore show was probably the right choice over scene. I also assumed you were handling the hide, even if you didn't include it in your example. Either by doing an explicit hide or just letting the next scene statement clean things up for you.

For completeness sake though, I will add that you can include an effective alias for your shown image to make hiding it easier.
It becomes the displayable's identifier and RenPy will only show one version of that named identifier at time.

So

    show "bimbo.png" with dissolve as tempimage
    pause 1.0
    show "gullible.png" with dissolve as tempimage
    pause 1.0
    show "sex.png" with dissolve as tempimage
    pause 1.0
    hide tempimage with dissolve

Will only show one picture at a time, with each new picture replacing the previous one (only one displayable tempimage onscreen at a time).

Anyway... it's a way to handle hide that may or may not help you.

Personally, I prefer the notify style solution of show screen - where you have a custom screen that controls showing whatever it is you want to show, where you want to show, using your chosen transitions, etc and then removes itself afterward.

Alternatively, you could just have a simple image shown on to the screen... and leave it there.
show bimbo with dissolve
(until you do a hide or scene).

 

[anne O'nymous]

Oh, the image is just really a splash screen. So it won't need to be replaced by anything. Until of course the condition changes.

Then you could be interested by this. It's a full notification system that pill up the notifications, make them disappear after some time, and can be an image, a text, or both.

In your case, you could use it like this by example:

label whatever:

    call bimbo_change( 1 )
    call gullible_change( 1 )
    call sex_change( 0 )
    [...]


label bimbo_change( step ):
    $ bimbo += step

    if bimbo > 10:
        $ notifyEx( msg="Welcome to Bimboland", img="bimbo.jpg" )
    return

label gullible_change( step ):
    $ gullible += step

    if gullible > 10:
        $ notifyEx( msg="The sharpest tool, or not", img="journeytodumb.jpg" )
    return

label sex_change( step ):
    $ sex += step

    if sex > 10:
        $ notifyEx( msg="Stay on the scene", img="experience.jpg" )
    return

You don't need to care about the pause, it will be handled automatically. What would be a better way than your approach, because the player can continue to play while the notifications are shown.

 

[coffeeaddicted]

If you know other programming languages, then call is likely familiar to you... along with the potential pitfalls.
RenPy throws in the non-linear spanner into the mix though, with triggerable events breaking you out of controlled areas of your code when you didn't think it through.

Meanwhile, I did assume that your "bimbo", "gullible" and "sex" popups were smaller images rather than full screen images - and therefore show was probably the right choice over scene. I also assumed you were handling the hide, even if you didn't include it in your example. Either by doing an explicit hide or just letting the next scene statement clean things up for you.

For completeness sake though, I will add that you can include an effective alias for your shown image to make hiding it easier.
It becomes the displayable's identifier and RenPy will only show one version of that named identifier at time.

So

    show "bimbo.png" with dissolve as tempimage
    pause 1.0
    show "gullible.png" with dissolve as tempimage
    pause 1.0
    show "sex.png" with dissolve as tempimage
    pause 1.0
    hide tempimage with dissolve

Will only show one picture at a time, with each new picture replacing the previous one (only one displayable tempimage onscreen at a time).

Anyway... it's a way to handle hide that may or may not help you.

Personally, I prefer the notify style solution of show screen - where you have a custom screen that controls showing whatever it is you want to show, where you want to show, using your chosen transitions, etc and then removes itself afterward.

Alternatively, you could just have a simple image shown on to the screen... and leave it there.
show bimbo with dissolve
(until you do a hide or scene).

The way i did the images, they are full screen images but transparent with writing on it.
So the idea was, to lay that over the main image and remove it once done. But yes, the hide seems to be what i had missed.

This is a lot to take in so i will work on that and see which solution works best.

icode is new to me so if that is a better way to do it, i am all in.

Sadly, i am not a coder but from my past, i knew someone who coded in C. I never did it myself. I think i should have done it.
Anyway, i was just puzzled that even though this is an interpreter language, is that what it is called?, it will essentially run down line by line and i would make the code unnecessary large by inserting the same over and over again. So that is what i thought i ask because my knowledge is, well, limited.

Thank you so much

 

[coffeeaddicted]

Then you could be interested by this. It's a full notification system that pill up the notifications, make them disappear after some time, and can be an image, a text, or both.

In your case, you could use it like this by example:

label whatever:

    call bimbo_change( 1 )
    call gullible_change( 1 )
    call sex_change( 0 )
    [...]


label bimbo_change( step ):
    $ bimbo += step

    if bimbo > 10:
        $ notifyEx( msg="Welcome to Bimboland", img="bimbo.jpg" )
    return

label gullible_change( step ):
    $ gullible += step

    if gullible > 10:
        $ notifyEx( msg="The sharpest tool, or not", img="journeytodumb.jpg" )
    return

label sex_change( step ):
    $ sex += step

    if sex > 10:
        $ notifyEx( msg="Stay on the scene", img="experience.jpg" )
    return

You don't need to care about the pause, it will be handled automatically. What would be a better way than your approach, because the player can continue to play while the notifications are shown.

So many things to try out.

Yes, this sounds even more interesting. Both suggestions are what i hoped for. Less repetitive code.

Currently, i have 6 values i am tracking. 2 of them are money related and the rest essentially person values.
Bimbo will refer to commonly airhead but i needed gullibility to make it work. Sex was more or less from a mod and i thought sexexperience is a nice touch. Not sure what to do with it yet and last addiction refers to cum, also from a mod.

So this system seems to work well. I am always glad for things that make it easier and are organized.

I need some time to process that all. Bimbo curse. lol
But i have to rework my idea and learn the code and it's functions.

label whatever steps are before the game starts, or? So that is only once written and then called by the function in the game script.
I hope i understand it correctly.

As always, thank you so much

 

[anne O'nymous]

label whatever steps are before the game starts, or? So that is only once written and then called by the function in the game script.

As 79flavors implied above, they are independent. A label is only processed when jumped to or, in this case, called. Therefore they'll be processed each time you'll call them because you need them.

This said, if you've really so many values, perhaps a more generic approach would be better:

label whatever:
    # Add 1 to /gullible/, and only that
    call statChange( gullibleStep=1 )
    [...]

    # Add 1 to /bimbo/ and to /gullible/
    call statChange( bimboStep=1, gullibleStep=1 )
    [...]

# Declare one argument by value you have to deal with.
# By default the step will be 0, what will mean "no change for this value"
label statChaneg( bimboStep=0, gullibleStep=0, sexStep=0, [...] ):

    # If you provided a value for /bimbo/
    if bimboStep:
        # Add this value. Like before, the value can be negative ; 10 + (-1) = 9
        $ bimbo += bimboStep
        # If the value reach the notification threshold, notify the player.
        if bimbo == 10:
            $ notifyEx( msg="Welcome to Bimboland", img="bimbo.jpg" )

    if gullibleStep:
        $ gullible += step
        if gullible == 10:
            $ notifyEx( msg="The sharpest tool, or not", img="journeytodumb.jpg" )

    if sexStep:
        $ sex += step
        if sex == 10:
            $ notifyEx( msg="Stay on the scene", img="experience.jpg" )

   # Process the other values in the same way.

    return

That way one call is enough to change many values at once, and the notification will still only appear if the value have been changed during this call.

 

[coffeeaddicted]

Yes... But...

It depends on your game.

A lot of story driven games are quite linear and therefore the number of places where something like bimbo or gullible or sex might reach 10 would be quite limited. Limited enough to be worth repeating the same code without being too worried about that repetition.

A more sandbox style game would usually have a hub (a label) or set of hubs around which the core gameplay loop of the game is arranged. A check like this could be placed there, and despite the fact that the game might execute that code a lot of times, it's only located once within the game.

But... to also offer a solution...

I dislike mentioning it... but there is a command called call (not to be confused with call screen which is completely different). Most new developers, especially RenPy developers are best to avoid call completely and only use jump. However it might be a good fit here.

call is similar to jump except it stores where the call is used and puts the details on something called the call stack. Each new entry is added to the end of the call stack. When the game encounters a return command, the details are retrieved from the end of the call stack and the game jumps back to that point and carries on.

The mistake new RenPy developers make is not strictly following the rule that for every call there must be a return executed too. It get worse in sandbox games, where there might be buttons or something on screen which the player can click on and jump to somewhere else within the code (and thereby end up jumping out of the called section of code without executing the return. Anyway, despite this warning...

I'm imagining something like this:

# ... somewhere in the middle of your game

call increase_bimbo_score

# ... and your game just continues...

# ...
# ...
# ...
# somewhere else in your code...

label increase_bimbo_score:

    $ bimbo += 1
    if bimbo == 10:
        $ renpy.notify("Bimbo has reached 10")

    return

label increase_gullible_score:

    $ gullible += 1
    if gullible == 10:
        $ renpy.notify("Gullible has reached 10")

    return

label increase_sex_score:

    $ sex += 1
    if sex == 10:
        $ renpy.notify("Sex has reached 10")

    return

$renpy.notify() uses screen notify(): and so it's possible for you to do something similar where the code invokes a show screen {screenname}() that shows your image and then removes the shown screen after a short amount of time.

This is RenPy... there are lots of other ways too.

Ok, so the important lesson here is, when call is used, follow up with a return.
I don't want to break the game.

I think it looks cleaner than if you check several condition every time. It's getting quiet larger of a code.
The main issue is, the message should only appear once, when player reaches for example value of 10. There will be more so it will end up with more code i suppose.

I find it overall very interesting what is possible and what not. Or what makes sense.
But even as i separate the code file into several pieces, it will get larger and therefore confusion over time.

I have to test all this.

label_increase_score_bimbo: only appears once, if i understand it correctly. Versus call increase_bimbo_score appears any time when an action is called by me.

It maybe silly but i still don't think like a coder.
So i hope that it doesn't sound to stupid.

Anyway, i will test it out and go with it.

 

[Sancho1969]

Ok, so the important lesson here is, when call is used, follow up with a return.
I don't want to break the game.

Well, yes and no. This depends on things. Not to complicate it but think of a "return" as simply removing the top call off the call stack and giving that top call control again. So, you'll keep in mind your call stack as things develop as you don't always return after every single call statement, they are allowed to stack.

 

[coffeeaddicted]

Well, yes and no. This depends on things. Not to complicate it but think of a "return" as simply removing the top call off the call stack and giving that top call control again. So, you'll keep in mind your call stack as things develop as you don't always return after every single call statement, they are allowed to stack.

Oh my, this got me confused.
I do get it that you don't necessarily have to use return every time but i don't understand when you really should. Like when to many are stacked or when?
So i need to get a grip on that still.

 

[Sancho1969]

Oh my, this got me confused.
I do get it that you don't necessarily have to use return every time but i don't understand when you really should. Like when to many are stacked or when?
So i need to get a grip on that still.

Then please disregard. Just know it's a thing. There's simple processes that can quickly get complex. Welcome to the world of coding languages and advanced logic. It's a wild journey but you are getting advice from a man who I've always considered one of my mentors being anne O'nymous. This man actually got me thinking outside the box on a massive hurdle I'd spent weeks trying to overcome at the beginning of SanchoMod that to this day I use the concepts to push boundaries and my knowledge further. He's extremely gratuitous with his time and extremely savvy. So, listen to him before you even look my direction

 

[coffeeaddicted]

Then please disregard. Just know it's a thing. There's simple processes that can quickly get complex. Welcome to the world of coding languages and advanced logic. It's a wild journey but you are getting advice from a man who I've always considered one of my mentors being anne O'nymous. This man actually got me thinking outside the box on a massive hurdle I'd spent weeks trying to overcome at the beginning of SanchoMod that to this day I use the concepts to push boundaries and my knowledge further. He's extremely gratuitous with his time and extremely savvy. So, listen to him before you even look my direction

Oh yes, you are absolutely right. All i learn comes from him and 79flavors.
I wish i had in my youth when playing with my C64 actually learned coding. It was then right in front off me than spending time playing a game. Oh well.
I think i can sometimes not wrap my mind around certain coding ideas.
Though i learn every day.
On the basics, RenPy is actually not hard to understand. Where it gets more complicated is when you want to do more than just to show an image like a stats menu or trigger an action by using values. This is actually the fun part for me. What if, when or why.
So now, as i write a game (several attempts already) where i came around the realization that i have passive stats and active ones.
The main goal is to have a system where the character is formed by things that are not in the characters control.

And thus was the question specifically with RenPy, if certain routines need to be repeated over and over which bloat the code and seem silly to me.
So the idea to me was, to have code that would check before the start label and a line that would trigger a check. It looks to me that you have to insert it in the flow no matter what but reduce the scale of it.

I hope i got that right.

Through anne O'nymous i got my coding at the minimum more structured. So i have several files for different things like room or location. This at least avoids to have one larger file.

 

[JustXThings]

In my game I do everything with dictionaries and functions. The methods also have a parameter to show or ignore the notification.

Then for instance if I want to set the stat of a particular character I do...

$ var_update('submission', 5, True, 'paula')

{
This is => data['paula']['submission] = 5
The 'True' => renpy.notify('Paula submission increased -or- decreased)
}

Then I can do things like...

$ var_increment('submission', var_get('submission') > 10, 'paula')

{
The var_increment is a syntax sugar method which does var_update('submission', var_get('submission', 'paula') + 1, notify, 'Paula')
notify = var_get('submission') > 10
}

If I wanted to show a picture, or do whatever, depending on certain conditions I would have a secondary dictionary.

data_effects['Paula', 'submission', 10, picture_location]

Or if I wanted something more general to happen at particular stats that I don't know right now, be it show a picture or some particular flashback or whatever...

data_effects['Paula', 'submission', 10, function_ref_or_renpy_label]

Which I register at the beginning of the story.

And then when I write $ var_update('submission', 5, True, 'paula'), I just do the update and check whether there is something to do in the data_effects (they have the same keys) and execute it.

 

[anne O'nymous]

I do get it that you don't necessarily have to use return every time but i don't understand when you really should. Like when to many are stacked or when?

Hmm, how to explain this ?

You're a postman, and you've your usual postal tour, that is streetA, streetB and streetF.
Like you have a small backbag (well, perhaps also back, I don't know) , you can only carry the letters for one street, therefore at the end of each street you've to go back to the post office, to take the next letters.

Usually your tour is :

• Get letters for streetA
• jump streetA
• Distribute the letters
• call Post office
  • Get letters for streetB
  • return to your tour
• jump streetB
• Distribute the letters
• call Post office
  • Get letters for streetF
  • return to your tour
• jump streetF
• Distribute the letters

One day, your coworker in charge of streetC, streetD and streetE is sick, and you have to do his tour in top of yours.
This day, your tour will be:

• Get letters for streetA
• jump streetA
• Distribute the letters
• call Post office
  • Get letters for streetB
  • return to your tour
• jump streetB
• Distribute the letters
• call diversion tour
  • call Post office
    • Get letters for streetC
    • return to the diversion tour
  • jump streetC
  • Distribute the letters
  • call Post office
    • Get letters for streetD
    • return to the diversion tour
  • jump streetD
  • Distribute the letters
  • call Post office
    • Get letters for streetE
    • return to the diversion tour
  • jump streetE
  • Distribute the letters
  • return to your normal tour
• call Post office
  • Get letters for streetF
  • return to your tour
• jump streetF
• Distribute the letters

In terms of code, it would looks like this:

label start:
    "Time for the postal tour"
    jump yourTour

label yourTour:
    if not haveLetters:
        call postOffice
    jump streetA

label streetA:
   $ distributeLetters()
   call postOffice
   jump streetB

label streetB:
   $ distributeLetters()
   if coworker == isSick:
       call coworkerTour
   call postOffice
   jump streetF

label streetF:
    $ distributeLetters()
    "Congratulation, you finished"

label postOffice:
    $ getLetters()
    return

label coworkerTour:
    if not haveLetters:
        call postOffice
    jump streetC

label streetC:
   $ distributeLetters()
   call postOffice
   jump streetD

label streetD:
   $ distributeLetters()
   call postOffice
   jump streetE

label streetE:
   $ distributeLetters()
   if coworker == isSick:
       return
   else:
        "Congratulation, you finished"

But the list presentation show more clearly that it's before anything else a question of level.
As long as you have to stay at a given level, you can jump from a label to another. What matters is that, when you're done with what you had to do at this level, you return to the previous level.


Edit: An obvious typo not obvious enough for me to notice it before I validate.

 

[coffeeaddicted]

Hmm, how to explain this ?

You're a postman, and you've your usual postal tour, that is streetA, streetB and streetF.
Like you have a small backbag (well, perhaps also back, I don't know) , you can only carry the letters for one street, therefore at the end of each street you've to go back to the post office, to take the next letters.

Usually your tour is :

• Get letters for streetA
• jump streetA
• Distribute the letters
• call Post office
  • Get letters for streetB
  • return to your tour
• jump streetB
• Distribute the letters
• call Post office
  • Get letters for streetF
  • return to your tour
• jump streetF
• Distribute the letters

One day, your coworker in charge of streetC, streetD and streetE is sick, and you have to do his tour in top of yours.
This day, your tour will be:

• Get letters for streetA
• jump streetA
• Distribute the letters
• call Post office
  • Get letters for streetB
  • return to your tour
• jump streetB
• Distribute the letters
• call diversion tour
  • call Post office
    • Get letters for streetC
    • return to the diversion tour
  • jump streetC
  • Distribute the letters
  • call Post office
    • Get letters for streetD
    • return to the diversion tour
  • jump streetD
  • Distribute the letters
  • call Post office
    • Get letters for streetE
    • return to the diversion tour
  • jump streetE
  • Distribute the letters
  • return to your normal tour
• call Post office
  • Get letters for streetF
  • return to your tour
• jump streetF
• Distribute the letters

In terms of code, it would looks like this:

label start:
    "Time for the postal tour"
    jump yourTour

label yourTour:
    if not haveLetters:
        call postOffice
    jump streetA

label streetA:
   $ distributeLetters()
   call postOffice
   jump streetB

label streetB:
   $ distributeLetters()
   if coworker == isSick:
       call coworkerTour
   call postOffice
   jump streetF

label streetF:
    $ distributeLetters()
    "Congratulation, you finished"

label postOffice:
    $ getLetters()
    return

label coworkerTour:
    if not haveLetters:
        call postOffice
    jump streetC

label streetC:
   $ distributeLetters()
   call postOffice
   jump streetD

label streetD:
   $ distributeLetters()
   call postOffice
   jump streetE

label streetE:
   $ distributeLetters()
   if coworker == isSick:
       return
   else:
        "Congratulation, you finished"

But the list presentation show more clearly that it's before anything else a question of level.
As long as you have to stay at a given level, you can jump from a label to another. What matters is that, when you're done with what you had to do at this level, you return to the previous level.


Edit: An obvious typo not obvious enough for me to notice it before I validate.

This makes sense. Ok, levels.

It is sometimes harder to comprehend if you don't have that thinking. Like a coder.
But this example makes sense.

Thank you again for explaining.

 

[anne O'nymous]

This man actually got me thinking outside the box [...]

I'm a big cat lover, and it happen that boxes are for cats to play, not for humans to think.

More seriously, it's something that tend to annoy my coworkers when I started working, years ago, and would have also annoyed my teachers if they knew: I don't face a problem starting by how can I code it.

I starts by defining the whole problem, then how it should be done, independently of the effective feasibility. What mean that I force the code to do what I want, instead of forcing my idea to works with what the code is supposed to let me do.
But please, readers, don't take this as an advice. There's a reason why many (the majority ?) see this as a bad practice. It works for me because I started really young, and already had more than a decade of practice when I started working ; and probably also because I'm a bit crazy
Yet, it's something that you should keep in mind. It's not because it seem that the code can't let you do this or that, that it's effectively impossible to do it. Therefore, don't hesitate to ask Google or you favorite search engine.

Through anne O'nymous i got my coding at the minimum more structured.

I'm hearing my actual boss voice right now ; "always do as he say, but please, pretty please, never do as he do".

It is sometimes harder to comprehend if you don't have that thinking. Like a coder.

When you read what I wrote regarding coding, you should never forgot that I'm 51yo and, my memory is a mess but I should have been 11yo when I started. It looks easy when I do/explain it, but it's because it's those 40 years of experience that are talking.
Take the time to do some experiments on a side project, and never worry if you fail. It don't works ? Take the time to think about it again, and like Sancho1969 implied, don't hesitate to try even what can possibly seem stupid.
The more you fail, the more you learn. And, cherry on the cake, you'll remember more surely the good way to do if you previously hit the wall, than if it worked smoothly right from the starts.

Thank you again for explaining.

You're welcome.

 

[coffeeaddicted]

I'm a big cat lover, and it happen that boxes are for cats to play, not for humans to think.

Oh, yes. I can relate. I have cats. Boxes and anything but a sheet of paper or carpet.
We should have a vision and act upon that. Not on the constraints.

I'm hearing my actual boss voice right now ; "always do as he say, but please, pretty please, never do as he do".

When i asked the question that let to this realization, i didn't really know how RenPy actually works. More specific, how it handles and threads files or anything really. If you know that, you know that you can do that. If you don't, you follow the path of cramping everything in one file.

This was a big help because i like things to be tidy in a sense and orderly. Because if you really have a large code/game, it will be more difficult to change anything because you have to find it first.

When you read what I wrote regarding coding, you should never forgot that I'm 51yo and, my memory is a mess but I should have been 11yo when I started. It looks easy when I do/explain it, but it's because it's those 40 years of experience that are talking.
Take the time to do some experiments on a side project, and never worry if you fail. It don't works ? Take the time to think about it again, and like Sancho1969 implied, don't hesitate to try even what can possibly seem stupid.
The more you fail, the more you learn. And, cherry on the cake, you'll remember more surely the good way to do if you previously hit the wall, than if it worked smoothly right from the starts.

You're welcome.

Yeah, the younger years. Reminds me of everything i did wrong.
I think at age it becomes more difficult to learn abstract things. Not that you can't do it, but it's not as easy as when you are young.
So i have often times the "Doh" reaction. Why did i not think about that. Fail i do. There are many things i don't realize and just later when i actually play that something isn't right.
Why that did not happen or this doesn't add up.
Well, so i go back into the code. Try to find the cause and it takes me some time to find it. Sometimes i don't.

Still, i find it quiet amusing sometimes how little i know but you can only learn.

But i mostly enjoy talking to all of you. It's a great experience and even though we may never know one another, the community is through that so much richer.

What i have is a vision. If i can ever realize it, dunno. Just doing it.