Ren'Py Help with Persistence/Loading

[anne O'nymous]

So... took me a little while to catch up to where you both already were.

To be fair, I started by verifying my guess. And it was way easier than trying to find it by looking at the code.

But the problem as I see it is due to the way the game progresses.

Same thought for me. Between the "nesting-like" approach of the screen, and the need of interaction from Ren'py, it will be difficult to maintain the accuracy of the data ; among other things.
Perhaps is it the game mechanism that make me thinks this, but it looks like the code follow Flash logic ; basically, all the actions are linked to their hosting form. But if this works for a engine that rely on events, it's not the case for Ren'py that is naturally event free, and expect a procedural approach.

I think the answer, without rewriting your code from scratch is to exit the screen and then reshow it each time the action is to ONLY set a variable.

Lets say that it's a fix, but as you implied the screen handling a lot of variables by itself, I fear that a rewriting stay the best option. At some point the game will be so complicated that the screen will lost its stability, or it will be impossible to effectively update it.

label reshow_cg_greating:
    call screen Cg_Greating
    jump reshow_cg_greating

This approach is probably better:

label reshow_cg_greating:
    while True:
        call screen Cg_Greating

Normally Ren'py shouldn't trigger its "endless loop" exception because the end of the interaction should reset the detection. But honestly I'm not sure at 100%.

My theory is that by having each action ending in a Return() or a Jump() - the game will do at least one RenPy command (and all it's associated internal logic that updates variables and get things ready in case a save is done) before the screen is reshown.

Ren'py will have two interactions, the jump, then the call screen, what would be enough to solve the variable update problem.



Now, as I said, the whole "one screen to do everything" approach should probably be abandoned. While it's not really mandatory now, it will be at some time in the future.

There should be a screen dedicated to the UI (traits, map, etc), that basically looks like:

screen UI():
    hbox:
        textbutton "traits" action Show( "traitsScreen" )
        textbutton "map" action Show( "mapScreen" )

screen traitsScreen():
    modal True
    [...]
    textbutton "Close" action Hide( "traitsScreen" )

And the rest should rely on the

You must be registered to see the links

, with the help of the

You must be registered to see the links

for the actions embedded in the dialog.

This would make the devel easier and more intuitive, reduce drastically the complexity of the code (and so the screen), offer more flexibility, and solve all possible variable related issue since there would be tons of interactions.

 

[Somatra]

To be fair, I started by verifying my guess. And it was way easier than trying to find it by looking at the code.




Same thought for me. Between the "nesting-like" approach of the screen, and the need of interaction from Ren'py, it will be difficult to maintain the accuracy of the data ; among other things.
Perhaps is it the game mechanism that make me thinks this, but it looks like the code follow Flash logic ; basically, all the actions are linked to their hosting form. But if this works for a engine that rely on events, it's not the case for Ren'py that is naturally event free, and expect a procedural approach.




Lets say that it's a fix, but as you implied the screen handling a lot of variables by itself, I fear that a rewriting stay the best option. At some point the game will be so complicated that the screen will lost its stability, or it will be impossible to effectively update it.




This approach is probably better:

label reshow_cg_greating:
    while True:
        call screen Cg_Greating

Normally Ren'py shouldn't trigger its "endless loop" exception because the end of the interaction should reset the detection. But honestly I'm not sure at 100%.




Ren'py will have two interactions, the jump, then the call screen, what would be enough to solve the variable update problem.



Now, as I said, the whole "one screen to do everything" approach should probably be abandoned. While it's not really mandatory now, it will be at some time in the future.

There should be a screen dedicated to the UI (traits, map, etc), that basically looks like:

screen UI():
    hbox:
        textbutton "traits" action Show( "traitsScreen" )
        textbutton "map" action Show( "mapScreen" )

screen traitsScreen():
    modal True
    [...]
    textbutton "Close" action Hide( "traitsScreen" )

And the rest should rely on the

You must be registered to see the links

, with the help of the

You must be registered to see the links

for the actions embedded in the dialog.

This would make the devel easier and more intuitive, reduce drastically the complexity of the code (and so the screen), offer more flexibility, and solve all possible variable related issue since there would be tons of interactions.

I'll finish the 0.3 and make a huge cod update for 0.4 I'll have more time in this version following the tips that are I received here, but how i can use two screens at the same time since I'll make something like that:

screen UI():
lots of UI things

screen gameplay:
show/add screen Ui

it's something like that?

Thank you

 

[79flavors]

Spoiler: Another way

You don't have permission to view the spoiler content. Log in or register now.

Download my test game here :

You must be registered to see the links

. And maybe play it a bit to see what it looks like before reading the wall of text within the spoiler tag.

 

[Somatra]

i understand your code but it's far more complicated then just show an image. I agree with Anne and you that's I really need to
have separate screens for, UI, text, map, so on

this code has a problem every time that's a red word (actions show) I'll need to break the text like:

a lot things here
 
 text "\
i think i should {b}{a=call:do_test_action_04}Hug Her{/a}{/b}

##The remaing of the text will only show when u click in the red action


do_test_action_04 == True:   
     text "\
     i think i should Hug Her more and more dialogue another pause {b}{a=call:do_test_action_05}red word{/a}{/b}

do_test_action_05 == True:
     text "\
     i think i should Hug Her more and more dialogue another pause red word more more dialogue

something like that, if a have 3~4 red words in the same dialogue the code will be enormous for just one page of dialogue

In my perspective is more practical use images, than code

 

[Somatra]

But I'm really grateful for all time that's u spend helping me. I learned a lot of things from both of you and i'll make the code
looks better in no time <3

 

[anne O'nymous]

but how i can use two screens at the same time since I'll make something like that:

I'm tempted to answer "the way you want".

Screen aren't forms (see my "Ren'py isn't Flash" above), they have near to no limitations. You can perfectly use them in a "show and forget" way ; you show then once with show screen SCREEN_NAME, and the screen will stay displayed as long as you don't hide it.
And there's absolutely nothing preventing you to have more than one screen displayed at one time. Any basic game have at least two screens shown every time, the quick menu and the say window, while most of them add a third screen that represent their UI. I also remember one so badly coded, that he had near to 50 screens shown at anytime.

screen UI():
lots of UI things

screen gameplay:
show/add screen Ui

it's something like that?

It's one of the way, but just "one of". You can also have this :

label start:
    show screen gameplay
    [...]

label endOfIntro:
    show screen UI
    [...]

During the introduction you'll just have the "gameplay" screen displayed. Then when the introduction end, the "UI" screen will be displayed in addition to the already displayed "gameplay" one.

i understand your code but it's far more complicated then just show an image.

I don't really have time, so it's a quick thinking wrote on the fly:

label waitForNext:
    while True:
        call screen waitForNext
        if _return == "continue":
            return

screen waitForNext():
    textbutton "continue":
        xalign 0.9 yalign 0.9
        action [ Hide( "waitForNext" ), Return( "Continue" ) ]


label whatever:
    text "She stand in front of me ( {b}{a=call:lookAtHer}Have a better look{/a}{/b}. I think i should {b}{a=jump:hugHer}Hug Her{/a}{/b}\n{b}{a=jump:KissHer}Kiss Her{/a}{/b}"
    jump waitForNext

label lookAtHer:
    "She's beautiful"
    return

label hugHer:
    hide screen waitForNext
    "I give her a hug"
    "she like it"
    [...]

label kissHer:
    hide screen waitForNext
    "I kiss her."
    "perhaps shouldn't have had, she don't seem happy."
    [...]