Ren'Py A Couple of Ren'Py Questions

[badcock]

I've been digging through tutorials and what example code I can find as I build a skeleton for a game (surprise, surprise, right?) I've come across a couple of questions either I've overlooked the answer or can't find the answer.

1. What is the best approach for waiting on interaction from the player. I don't want to use the built-in menu system. Eventually I'm going to add imagemaps to navigate between rooms. It seems like that will work. In the meantime is there something else I can use while I work out the mechanics of the game using textbuttons?

2. In a couple of places I have labels that take parameters. How do I jump to these labels and pass the correct parameter? I've tried multiple variations of the line below, to no avail.

jump my_label( "parameter" )

 

[SLDR]

Jumping with parameters isn't supported by Renpy. Jump operates in the global scope, so jumping with a parameter would be the same thing as assigning global variable x in Label A, jumping to Label B, then using x in Label B - so I recommend doing that instead. I think call my_label("parameter") works though.

 

[anne O'nymous]

1. What is the best approach for waiting on interaction from the player. I don't want to use the built-in menu system.

Without writing your own waiting function, you have really few options :

• Using the menu statement, but you don't want (why ?) ;
• Calling a screen (call screen screenName), and obviously returning from him (see below) ;
• Showing a screen with a
  You must be registered to see the links
  defined in it, and waiting in a while loop
  

  screen myKeyScreen:
      key "c" action SetVariable ( "waitingHere", False)
  
  label blablabla:
     $ waitingHere = True
     show myKeyScreen
     while waitingHere
        $ renpy.pause( 1 )

  The player while have to wait until he hit the "c" key. It's a minimal example, you can assign more things to the action property and even use the
  You must be registered to see the links
  screen action or the
  You must be registered to see the links
  screen action to branch somewhere.

Eventually I'm going to add imagemaps to navigate between rooms. It seems like that will work. In the meantime is there something else I can use while I work out the mechanics of the game using textbuttons?

You mean, like

You must be registered to see the links

and

You must be registered to see the links

?

2. In a couple of places I have labels that take parameters. How do I jump to these labels and pass the correct parameter? I've tried multiple variations of the line below, to no avail.

Two possibilities :

• You
  You must be registered to see the links
  them ;
• You simulate the parameters by assigning them to a variables.

For the last possibility, I recommend you to use the _args list and _kwargs dict, attributes for this. They are used by Ren'py to store the arguments sent by the call statement, so it will not interfere nor add other variables.

 

[Rich]

@anne O'nymous pretty well recited the options.

To extend just slightly, the most common paradigm I've seen for what you're trying to do is to create a screen and then call the screen. (The other methods mentioned work, but they're probably sub-optimal for navigation.)

Calling a screen (as opposed to just showing it) creates an interaction for the player. (i.e. waits for player input) You can easily prototype the screen using just text buttons inside a vbox until later when you have your actual graphics, etc.

From within the screen, you have essentially two choices to leave:

1. When you click on a button (to go somewhere), the screen can Return("some string"). (In other words, the "action" for the button is Return("some string") This will return control back to just after your "call screen" statement, and "some string" will be assigned to the "_return" variable. At that point, you can test the value in the _return variable and do whatever you need to do.
2. Instead, you can have the "action" for the button be Jump("someLabel"), in which case control will be directly transferred to the label in question instead of returning back to where the "call screen" was.

Note that in the latter case, you cannot pass parameters to the label. However, what you can do is something like

action [SetVariable("variableName","value"),Jump("someLabel")]

In other words, the action for the button can be an array of actions, which will be executed in sequence. This allows you to set a variable (or do something else) before you jump, and then the code on the other end of the jump can use the value in the variable (as @anne O'nymous said).

Again, at least IMHO, the "Jump" option is probably the superior one if you're doing in-game navigation across multiple rooms or whatever. Basically, you have a screen for each room, the room-to-room buttons jump to labels where you call the correct screen for the room you're in, and then the "oh, I can do something other just go to another room" buttons jump to the appropriate portion of the dialog. (Or, when you jump to a room label, the first thing you do is check "is there any dialog to be shown" and once that's been handled, you call the screen to find out where the player wants to go next.)

That approach makes for a pretty modular game, which should be reasonably easy to maintain.

Finally, as a side note, you should probably look at imagebutton's before you look at imagemap's. In other words, create a background for the scene, and then overlay imagebuttons at the appropriate (x,y) points. Imagemap's certainly work, and for some people they're a bit more "obvious," but imagebuttons are somewhat more flexible, and tend to require less graphics rework if you decide to add a new button as your game evolves.

Again, just my $0.02. The paradigms that make sense to one person may be foreign to another, and vice versa, so your mileage may vary.

 

[badcock]

Thanks for the replies @SLDR, @anne O'nymous, and @Rich. I was going to clarify my post a bit, but @Rich you nailed what I was looking for in your second paragraph.

Calling a screen (as opposed to just showing it) creates an interaction for the player. (i.e. waits for player input) You can easily prototype the screen using just text buttons inside a vbox until later when you have your actual graphics, etc.​

You've been very helpful.

 

[Domiek]

+1 on image button vs image mapping. I ended up replacing my maps with buttons because they are much more flexible and you can use them for a lot more than just navigation (such as interacting with objects and characters).