Calling Screens and ui.interact with Sanbox elements

[kde]

Howdy,
I am looking to make a sandbox game and am looking for some best practices in renpy concerning screens, calling, and best practices for returns and controlling flow.

Functionally I want to move around from room to room and interact with characters. Once in a room, the game pauses and waits for users to select from one of 3 possible screens:

• Navigation - navigate away from the room

• Room-specific interaction - things that are relevant to the room

• Character interaction - things that are relevant to characters in that room

I do this with 3 screens, dynamically generated based on the location, room, and occupants. Doing a standard menu isn't really an option as the intent is to use image buttons for everything.
Below is an example of the basic setup all the rooms use. Occupants and such are dynamic and are set up through the initializer, parsed, and used to populate the relevant screens.

Code: Select all

label _theroom:
    $ initialize_room(WHAT_ROOM, "room_navigator", "room_options")
    $ room_interact = False
    "You are in a room" 
    jump this_room_screen

label this_room_screen:
    #Shows the relevant screens generated from initializer, for room and character-specific options
    $ show_screens()
    #Blocks the continued flow of the game until an interaction event (I think...)
    $ ui.interact()
    # Reloop on return, with new states
    jump this_room_screen

The control and movement are fine but I am after clarity on the call stack/ui.interact.

From what I could find ui.interact is the "best" way to pause the game while waiting for screen input of some kind. I considered using a modal=True "blocking" screen but ui.interact seemed to be the common way to do this (and solves having to have a blocking dialog statement). However, a side effect is some interactions can be generated that move away from the room without coming back to the ui.interact. This results in the call stack incrementing with no real way to reduce it (e.g. a character or event may move to a different location and advance time, so we never return, or the player abandons a conversation and navigates away)

So my question is how much does renpy care about call stack size? Is it worth popping these ui.interact returns manually? Or am I just on the wrong track entirely and there is a better way to pause/hold the game state for screen interaction?

I am aware I could call a screen whose purpose is interaction, but having separate screens for each makes more sense to me. I also don't think this really solves the problem of moving away from the room, having the game state advance, and leaving the hanging ui.interact. Is this the wrong approach and should I just use a framed single screen? Or am I just completely turned around on this and approaching the whole thing backward.

Any insight or advice is appreciated

[Ocelot]

You cannot start an interaction from within another interaction. If interaction have started then previous interaction had ended (aside from call_in_ new_context family of functions, but if you are using that, you really should know what you are doing). So in reality all those calls to ui.interact did return. Fun fact: technically call screen is show screen + ui.interact + some bookkeeping

[kde]

Hmm yea, I have already had some run-ins with call interaction from current context errors.
I show my screens and call functions from within them (text buttons are making renpy.call statements), it is part of what is making me query if I am fundamentally misunderstanding how to manage the screen system and if I should be using a single screen call instead of 3 different screens, and handling the visibility through booleans or similar, as by my understanding calling the single screen would basically do what I want and manage itself if navigated away. I am interested if it is considered bad practice to have multiple flow control screens in renpy and if the preferred operation is a singular screen for flow control, and non-called "show" screens for detail

[Ocelot]

called screens are different from shown screens in that they (1) force an interaction (can be replicated by calling ui.interact) and (2) hide themselves after an interaction (can be replicated by either passing _transient=True to show_screen function or showing it on transient layer). Technically there is (3) called screens set a specific mode, but that can be replicated too if you care about modes.

Doing multiple screens is fine if this is easier to implement and support for you. If you are doing a non-standard game you will find yourself using non-standard solutions anyways.

[GeraldineRushing]

Hello, I am new here, can I ask a question?