documentation index ◦ reference manual ◦ function index

Contents 1 Customizing the Interface 1.1 Order of Customizations 2 Layouts 2.1 main_menu layouts 2.2 navigation layouts 2.3 load_save layouts 2.4 yesno_prompt layouts 2.5 preferences layouts 2.6 joystick_preferences layouts 2.7 standalone layouts 3 Defining New Layouts 3.1 main_menu layouts 3.2 navigation layouts 3.3 load_save layouts 3.4 yesno_prompt layouts 3.5 preferences layouts 3.6 joystick_preferences layouts 3.7 Example 4 Themes 4.1 Theme Functions 4.1.1 Component functions 4.1.2 Component functions 4.2 Theme Modifiers 4.3 Custom Theme 5 Main and Game Menus 5.1 Main Menu 5.2 Game Menu 5.3 Entering the Game Menu 6 Compatibility Mode

Customizing the Interface

In Ren'Py, there are four ways that one can customize the out-of-game menus:

• Layouts control the feel of the various screens that make up the game menu. They control the placement of components on those screen, and what those components do if they interact.
• Themes control the look of buttons, bars, frames, labels, and prompts.
• One can customize the main and game menus to add additional choices to those menus, over and above the ones provided by the layouts.
• Finally, one can use the style system to further customize the look and layout of the various out-of-game menu screens.

Of these, the only mandatory customization is the selection of a theme.

Order of Customizations

We expect customization of the game to occur in the following order:

1. If necessary, setting the script version (config.script_version), screen width (config.screen_width). and screen height (config.screen_height).
2. If necessary, selecting one or more layouts.
3. Selecting a master theme.
4. If necessary, selecting one or more theme components that override portions of the master theme.
5. If necessary, customize the main and game menus, and using the style system to further customize the interface.

Layouts

Layouts control the feel of the out-of-game menus. There are five main kinds of layouts:

• main_menu layouts control the feel of the main menu.
• navigation layouts control the feel of the game menu navigation.
• load_save layouts control the feel of the load and save screens.
• yesno_prompt layouts control the feel of asking the user a yes or no question.
• preferences layouts control the feel of the preference screens.
• joystick_preferences layouts control the feel of the joystick preference screens.

There are also standalone layouts which do not fall into any of these categories. While a game needs exactly one of each of the five main kinds of layouts to function properly, it can have as many standalone layouts as it needs.

Each kind of layout provides certain functionality to the interface. The functionality provided by each kind of layout is described below. The selection of layouts is expected to occur before the selection of a theme. If no layout of a given kind is selected, then the classic variant is used. For example, if no yesno_prompt layout has been selected, then layout.classic_yesno_prompt is used.

Note that there are combinations of layouts and themes that will not look reasonable together. This is not a bug... it's impossible to have every layout work with every other layout and every theme, and still have an unlimited range of layouts and themes. Caveat factor.

main_menu layouts

The main_menu layouts are responsible for defining the look of the main menu. This includes the background of the main menu, and the buttons that are used to go to the game menu or start a game.

Function:

layout.classic_main_menu

():

Function:

layout.grouped_main_menu

():

Function:

layout.imagemap_main_menu

(ground, selected, hotspots, idle=None, variant=None):

navigation layouts

The navigation layouts are responsible for defining the navigation through the game menu. This includes the background of the game menus and the buttons that are used to go between game menu screens.

Function:

layout.classic_navigation

():

Function:

layout.grouped_navigation

():

Function:

layout.imagemap_navigation

(ground, idle, hover, selected_idle, selected_hover, hotspots):

load_save layouts

The load_save layouts are responsible for defining the load and save screens.

Function:

layout.classic_load_save

():

Function:

layout.scrolling_load_save

():

Function:

layout.imagemap_load_save

(ground, idle, hover, selected_idle, selected_hover, hotspots, variant=None):

yesno_prompt layouts

The yesno_prompt layouts are responsible for defining yes/no prompt screens.

Function:

layout.classic_yesno_prompt

():

Function:

layout.imagemap_yesno_prompt

(ground, idle, hover, hotspots, prompt_images={}):

preferences layouts

The preferences layouts are used to define the preferences screen.

Function:

layout.classic_preferences

():

Function:

layout.two_column_preferences

():

Function:

layout.one_column_preferences

():

Function:

layout.imagemap_preferences

(ground, idle, hover, selected_idle, selected_hover, hotspots):

joystick_preferences layouts

The joystick_preferences layout are used to define the joystick preferences screen.

Function:

layout.classic_joystick_preferences

():

standalone layouts

These provide interesting functionality to Ren'Py games, and they stand alone, so it's possible to call as many of them as you want.

Function:

layout.button_menu

():

Defining New Layouts

This section contains some notes on how to define your own layouts. If you're not interested in defining your own labels, then you can safely ignore this section.

When it comes to defining layouts, there are two important principles you should follow:

1. layout.provides must be called with the type of layout being defined, and it must be called before any theme function is called. For example, if a navigation layout is being defined, then layout.provides("navigation") should be called.
2. The layout needs to implement the contract of it's layout kind. These contracts are described below.

While the default layouts are enable through the use of functions on the layout object, this is by no means the only way to supply a layout. For a user-defined layout, it should be enough to place the call to layout.provides in an init -2 python block, with the rest of the code residing in init blocks or labels as appropriate.

If your layout defines new configuration variables, you should set config.locked to False before creating them, and then back to True when you're done creating them. We suggest that configuration variables should be prefixed with the type of layout they're used by. Load/save variables should be prefixed by config.load_save_, navigation variables with config.navigation_ and so on. (For compatibility reasons, the default layouts do not conform to this standard.)

main_menu layouts

Main_menu layouts need to call:

    layout.provides('main_menu')

Main menu layouts are expected to define a main_menu_screen label. This label is expected to:

• Show a fullscreen window of type mm_root. The code to do this is:

    python:
        ui.window(style='mm_root')
        ui.null()

• Create a keymap that disables the game_menu binding. (This is optional, but it can prevent transitions from the main menu to itself.)

    python:
        ui.keymap(game_menu=ui.returns(None))

• Displays the main menu on the screen. How this is done is generally up to the layout itself, but we strongly recommend you use config.main_menu to control the generation of the menu. Note that the documentation for config.main_menu says that bare strings cause a jump out of context to occur; use ui.jumpsoutofcontext to implement this properly. Using config.main_menu ensures that your layout will work even with extensions (like image galleries) that add options to the main menu.

navigation layouts

Navigation layouts need to call:

    layout.provides('navigation')

Navigation layouts are expected to redefine the layout.navigation function. The way to do this is to first define a function in an init python block, and then assign that function to layout.navigation.

Function:

layout.navigation

(screen):

It's suggested that your navigation function use config.game_menu to determine the game menu buttons to show to the user. (But note that the game menu is less often extended then the main menu, so this is correspondingly less important.)

load_save layouts

Load/save layouts need to call:

    layout.provides('load_save')

Load/save layouts are expected to provide two labels: load_screen and save_screen, which are used to load and save, respectively. These screens should call layout.navigation with "load" or "save" as an argument, and are otherwise unconstrained in how they provide loading and saving functionality.

Please see the section on load/save functions for the functions that would be used to actually implement these screens.

yesno_prompt layouts

Yes/no prompt layouts need to call:

    layout.provides('yesno_prompt')

Navigation layouts are expected to redefine the layout.yesno_prompt function. The way to do this is to first define a function in an init python block, and then assign that function to layout.yesno_prompt.

Function:

layout.yesno_prompt

(screen, message):

preferences layouts

Preferences layouts need to call:

    layout.provides('preferences')

The preferences layout should define a preferences_screen label, which contains code to set the preferences. This screen should call layout.navigation("preferences"). It then needs to allow the user to alter the preferences, using the variables and functions defined in the preferences section. Finally, it should:

• Allow the user to begin skipping, by jumping to the _begin_skipping label.
• Allow the user to go to the joystick preferences, by jumping to the joystick_preferences_screen label.

joystick_preferences layouts

Joystick preferences layouts need to call:

    layout.provides('joystick_preferences')

The preferences layout should define a joystick_preferences_screen label, which contains code to set the joystick preferences. This screen should call layout.navigation("joystick_preferences"). Unfortunately, the joystick preferences are undocumented at this time.

Example

An example of a new main_menu layout:

init -2 python:
    layout.provides('main_menu')

    style.mm_button = Style(style.button, help="main menu button")
    style.mm_button_text = Style(style.button_text, help="main menu button (text)")
    style.mm_button.size_group = "mm"

label main_menu_screen:
    python:
        layout.button(u"Start Game", "mm", clicked=ui.jumpsoutofcontext('start'), xpos=400, ypos=400)
        layout.button(u"Continue Game", "mm", clicked=_intra_jumps("load_screen", "main_game_transition"), xpos=450, ypos=430)
        layout.button(u"Preferences", "mm", clicked=_intra_jumps("preferences_screen", "main_game_transition"), xpos=500, ypos=460),
        layout.button(u"Quit", "mm", clicked=ui.jumps("_quit"), xpos=550, ypos=490)

        ui.interact()

Themes

Themes provide a simple way of changing the look of the main and game menus. A single function call applies styles to many of the elements of the main and game menus, giving a consistent look to the interface.

Theme functions should be called after the config.screen_width, config.screen_height, and library.script_version variables have been set, and after any layout functions have been called. They should be called before any style is changed by hand.

Theme Functions

These theme functions are

Function:

theme.roundrect

(widget="#003c78", widget_hover="#0050a0", widget_text="#c8e1ff", widget_selected="#ffffc8", disabled="#404040", disabled_text="#c8c8c8", label=,"#ffffff" frame="#6496c8", window="#000000c0", text_size=None, small_text_size=None, mm_root=..., gm_root=..., less_rounded=False):

Function:

theme.outline

(inside="#fff", idle="#e66", hover="#48f", selected="#84f", insensitive="#ccc", label="#484", prompt="#484", background="#fee", large_button="#fff8f8", text_size=22, small_text_size=16):

Function:

theme.ancient

():

Theme Modifiers

These are functions that can be called after a theme function, allowing you to change a portion of a theme.

Function:

theme.image_buttons

(d):

Function:

theme.image_labels

(d):

Custom Theme

It's also possible to define your own Ren'Py theme. A custom theme consists of Ren'Py code that does the following.

• Calls layout.defaults() to initialize the layouts. Calling this function is the responsibility of the theme, and custom themes must also do it.
• Set up the base styles to reflect the requirements of the theme.

Often, the base styles come in name/name_text pairs. In these cases, name represents a Button or Window with style name, in which a Text with style name_text lives.

The base styles are:

style.frame (inherits from style.default)

Used for frames on top of which the rest of the interface can comfortably sit.

style.button (inherits from style.default)

style.button_text (inherits from style.default)

Used for buttons, especially buttons whose primary purpose is navigating through the interface. (Like the main menu and the game menu navigation buttons.)

style.small_button (inherits from style.button)

style.small_button_text (inherits from style.button_text)

Used for smaller navigation buttons. It might make sense to set a minimum width on buttons, but small_buttons should be allowed to shrink as small as possible.

style.radio_button (inherits from style.button)

style.radio_button_text (inherits from style.button_text)

Used for buttons that are arranged in a group, such that only one of the buttons in the group can be selected at a time.

style.check_button (inherits from style.button)

style.check_button_text (inherits from style.button_text)

Used for buttons that toggle their selected state to indicate if an option is set or not. (These aren't used in any of the pre-defined layouts.)

style.large_button (inherits from style.default)

style.large_button_text (inherits from style.default)

Used for large buttons, such as file picker entries, that can contain a large amount of text and other information.

style.label (inherits from style.default)

style.label_text (inherits from style.default)

Used for labels, which are small text messages that never change.

style.prompt (inherits from style.default)

style.prompt_text (inherits from style.default)

Used for prompts, longer text messages which may change at runtime.

style.bar (inherits from style.default)

style.vbar (inherits from style.default)

Used for horizontal and vertical bars, respectively. Bars are generally intended to indicate a quantity or an amount of progress, but aren't expected to be adjusted by the user.

style.slider (inherits from style.default)

style.vslider (inherits from style.default)

Used for horizontal and vertical sliders, respectively. Sliders are bars that are used to adjust a value.

style.scrollbar (inherits from style.default)

style.vscrollbar (inherits from style.default)

Used for horizontal and vertical scrollbars, respectively.

style.mm_root (inherits from style.default)

style.gm_root (inherits from style.default)

Used for the backgrounds of the main and game menus, respectively.

Generally, themes should not adjust the margins, positioning properties, or maximum sizes of these styles. An exception is that the bars are expected to set a maximum size in a direction perpendicular to the orientation of the bar (ymaximum for bar and scrollbar; xmaximum for vbar and vscrollbar). No limitations apply to the _text styles.

Main and Game Menus

This section describes how the content of the various menus can be customized. If you just want to change the look of the menus (to the extent made possible by the style system), use themes or styles. In particular, if you want to change the image background to the main menu and game menu, use the properties mm_root and gm_root in a theme.

To change just the text of menu items, consider using config.translations. To change the screens on the menus, you'll need to change the contents of the config.main_menu and config.game_menu variables. Otherwise, you'll want to use a layout that changes the look of the menus, or write your own layout.

Main Menu

The main menu can be customized by setting the config.main_menu variable. This variable should be a list of tuples. The first component of each tuple is the name of the button on the main menu. The second component can be one of three things:

• a string, in which case it is a label at which the game execution starts (after a jump out of the menu context).
• a function, in which case the function is called when the button is clicked.
• Finally, it can be None, which causes the button to be insensitive.

The third component must be a string containing a python expression, which determines when the button is enabled. The optional fourth component is a string containing a python expression, that determines if the button is shown at all. (changed in 6.6.2)

To jump from the main menu to one of the screens in the game menu, one should use the _intra_jumps function to specify the appropriate transition.

Function:

_intra_jumps

(label, transition):

The default value of config.main_menu is:

    config.main_menu = [
        (u"Start Game", "start", "True"),
        (u"Continue Game", _intra_jumps("load_screen", "main_game_transition"), "True"),
        (u"Preferences", _intra_jumps("preferences_screen", "main_game_transition"), "True"),
        (u"Quit", ui.jumps("_quit"), "True")
        ]

Game Menu

The first thing one may wish to do when modifying the game menu is to add a screen to it. This is done in two steps. The first is to create the screen, and the second is to add it to the config.game_menu list so that it can be reached from the game menu.

Each screen is represented in the code as a label that is jumped to to display the screen. There are five steps that this label should do in order to display the screen. First, it should call layout.navigation(screen), where screen is the name of the screen (the first component of the tuples in config.game_menu, described below). Second, it should call the ui functions to add components to the the screen. Third, it should call ui.interact to interact with the user. Fourth, it should examine the results of _game_interact, and react appropriately. Finally, it should jump back up to the screen label, showing the screen again after each interaction.

So that the user can see it, the screen should be added to config.game_menu. This is a list of four- or five-component tuples. The first is the name of the screen. It's used to determine if the button used to reach that screen should be indicated as selected. The second component is the text used for that button. The third component is a function that executes when the button is clicked. Normally, an appropriate function is _intra_jumps(label, transition), where label is the name of the label of your screen. The fourth component is a string containing a python expression. If the expression is not true, the button is insensitive. The optional fifth component is also a string containing a python expression. If the expression is not true, the button is not shown. (changed in 6.6.2)

The default value of config.game_menu is:

    config.game_menu = [
        ( None, u"Return", ui.jumps("_return"), 'True'),
        ( "preferences", u"Preferences", _intra_jumps("preferences_screen", "intra_transition"), 'True' ),
        ( "save", u"Save Game", _intra_jumps("save_screen", "intra_transition"), 'not main_menu' ),
        ( "load", u"Load Game", _intra_jumps("load_screen", "intra_transition"), 'True'),
        ( None, u"Main Menu", ui.callsinnewcontext("_main_menu_prompt"), 'not main_menu' ),
        ( None, u"Quit", ui.callsinnewcontext("_quit_prompt"), 'True' ),
        ]

Variable:

_game_menu_screen

= "_load_screen"

Use the layout.yesno_prompt function to ask yes/no questions of the user.

Function:

layout.yesno_prompt

(screen, message):

Pre-defined Screens. Layouts define the load screen, save screen, and preferences screen are define at the load_screen, save_screen, and preferences_screen, respectively.

Please see the page on Saving, Loading, and Rollback for a list of functions that can be used in the load and save screens, and the page on the Preferences for a list of preferences that can be customized.

Jump to _return to return to the game or the main menu, as appropriate. Jump to _noisy_return to play config.exit_sound before returning.

Entering the Game Menu

The game menu can be activated immediately using renpy.game_menu, or ui.gamemenus can be used to enter the game menu when a button is clicked. Both functions take an optional argument, the name of the screen to enter, normally one of "load_screen", "save_screen", or "preferences_screen". This can be omitted to use the default screen.

init python:
    def overlay():
         ui.textbutton("Prefs", clicked=ui.gamemenus("preferences_screen"), xalign=1.0, yalign=0.0)

    config.overlay_functions.append(overlay)

label battle_begin:
    menu:
        "A battle is about to begin! Would you like to save your game?"
        "Yes.":
              $ renpy.game_menu("save_screen")
        "No.":
              pass

Compatibility Mode

Ren'Py also supports a compatibility mode that makes layouts and themes more compatible with how they were used in Ren'Py 6.5.0. This compatibility mode is automatically enabled when config.script_version is set to (6, 5, 0) or less. It can also be enabled explicitly by calling layout.compat().

Function:

layout.compat

():