renpy как сделать меню

In-Game Menus link

In many visual novels, the player is asked to make choices that control the outcome of the story. The Ren’Py language contains a menu statement that makes it easy to present choices to the user.

Here’s an example of a menu statement:

Menu Choices. A menu choice is an option the user can select from the in-game menu. A menu choice begins with a string. The string may be followed by an if-clause, which makes the choice conditional. The menu choice ends with a colon, and must be followed by a block of Ren’Py statements.

When the choice is selected, the block of statements is run. If execution reaches the end of the block, it continues with the statement after the end of the menu statement.

The third choice will only be presented if the drank_tea variable is true. (However if, the config.menu_include_disabled variable is set to True, it will be shown as a disabled button.)

Menu Set link

A menu can take a set clause, on a line by itself. If present, only items with captions that are not in the set are displayed as part of the menu. When a choice is selected, the caption of that choice can be added to the set.

As with all menus, if no choices are available it advances to the statement after the menu.

For historical reasons, the set can be either a set object or a list.

Menu Arguments link

It’s possible to pass arguments to the menu itself, and to the individual choices in a menu. To pass arguments to the menu, add them to the menu line, after the optional name, and immediately before the colon. To pass arguments to a menu choice, put them after the menu string and before the if keyword or colon.

© Copyright 2012-2021, Tom Rothamel.
Created using Sphinx 1.6.6.

Источник

Digital Ephemera

Code, Commentary, and Complaining

Working with Ren’Py: Part 4: Menus, Labels, and Jumps

Working with Ren’Py:

Advanced Ren’Py:

Customizing Ren’Py:

Ren’Py + Python:

Ren’Py is a engine for creating visual novels. It comes with a suite of tools for taking code and transforming it into programs that can be run on Windows, Mac, Linux, and even, with a little more work, mobile platforms like Android and iOS.

Menus

In Ren’Py menus are central to how in-game choices are presented. By choosing one option in “The Question” (shown above), the player is moved (jumped) from one section of code to another.

Open the “script.rpy” file from “The Question”.

Lines 43 – 56 demonstrate how a menu is used. Choices are under (indented) the menu and their own code is then under (indented) the text of the choice.

The keyword menu, however, only works in the above example because because it is part of two other keyword functionality: labels and jumps.

Label

Code in the “script.rpy” file of a project in Ren’Py can be divided up into sections. These are called labels.

After characters are created and other initialization tasks are complete, Ren’Py starts a project at the label start. In the “script.rpy” file of “The Question”, this is line 12.

Labels are also be found in other places and with other names.

For example, the label rightaway is found on line 57. It is the beginning of a new section of code and immediately follows the previous menu code. In “The Question”, it is the first of two possible paths from the in-game choices.

It is accessed through another keyword, jump.

The jump keyword is used to move from one label to another. It “jumps” to that new section of code.

In “The Question”, it appears first on lines 50 and 54. Depending on what the player chooses, they are “jumped” to either the label rightaway or the label later.

Removed from any code, Ren’Py would “read” the project start to finish depending on the order of the code in the file. With using the keyword jump, projects in Ren’Py can loop, branch, and create new paths.

Menus, Labels, and Jumps

The menu keyword can be used to create in-choices. Through using existing labels, a player can be moved (jumped) from one section to another.

In “The Question”, this combination is used on lines 43 – 56 —

— and again on lines 100 – 111. Each use the menu keyword is combined with the jump keyword to move the player to different labels.

Источник

Renpy как сделать меню

Screens and screen language: вводная

Всегда приятно понимать, что именно делает та или иная строка кода, а не бездумно повторять их за учебником – поэтому попытаемся разобраться, как устроены экраны в Ren’Py, и как можно с ними работать.

Зачем мне все это, я просто хочу добавить в меню кнопку, которая делает «бип»!

Ну, сегодня вам хочется добавить только одну кнопку, завтра – поменять фон главного меню в зависимости от условий, послезавтра – добавить туда красивую анимированную вставку. Как говорится, дай человеку рыбу, и он будет сыт весь день, научи человека читать простой код создания экранов, и он будет с легкостью кастомизировать под себя любые игры.

Содержимое окна новеллы, написанной на Ren’Py, выводится по слоям. Стандартный набор слоев, который предоставляет Ren’Py: master (самый нижний), transient, screens, overlay (самый верхний). Каждый из них отвечает за определенный набор объектов, которые выводятся только на этом слое. Так, например, на слое master по умолчанию выводится все, что было вызвано с помощью операторов show/hide и scene – то есть, все спрайты, картинки, фоны и т.д.

Порядок слоев определяется внутри переменной config, может быть изменен и задает то, какие элементы будут расположены поверх каких. Так, например, когда вызывается экран внутриигрового меню, ваши фоны, спрайты и диалоги никуда не пропадают. Слой screens, на котором лежит меню, рисуется поверх слоя master, на котором лежат спрайты и прочая.

Вы можете создавать свои собственные слои и вставлять их в любое место в списке стандартных. Можно переопределить список слоев целиком, работая с атрибутом layers переменной config:

Что такое экраны? Зачем они нужны? Как их пощупать?

Объекты, которые мы видим на экране любой renpy-игры, называются общим термином displayables («то-что-можно-показывать»). Текст, статичная картинка, фреймы, кнопки – все это дисплейабл-объекты разных типов. Их можно бросать на слой в голом виде:

. а можно предварительно объединить экраном, если их нужно показывать и прятать сразу группой.

tl;dr: экраны – это контейнеры для объектов.

Где можно найти экран в Ren’Py? Везде. Если вы замечаете объединенные в группу объекты, скорее всего перед вами объект screen. Диалоговая коробка с текстом и портретом? Экран say. Главное меню? Экран main_menu. Маленькая менюшка перемотки и быстрого сохранения? Экран quick_menu внутри экрана say!

Если порядок отображения для экрана не задан в стилях, то выводятся они порядке очереди вызова – то, что вызвано последним, кладется на самый верх стопки.

Как вызывать/прятать экраны?

Для файла скрипта проще всего будет использовать оператор show с ключевым словом screen:

label start:
# показывает и прячет экран my_new_screen
show screen my_new_screen
hide screen my_new_screen

# показывает и прячет экран another_one с анимацией dissolve
show screen another_one
with dissolve
hide screen another_one
with dissolve

# показывает экран parametrized на слое my_layer вместо слоя screens, передавая в вызов параметры param_one и param_two
show screen parametrized(_layer = «my_layer», param_one = «test», param_two = False)

Из примера выше видно, что экраны можно вызывать с параметрами (которые потом используются внутри самого экрана, но об этом позже). Кроме того, есть набор т.н. ключевых слов – параметров, предусмотренных самим Ren’Py. Они начинаются с символа «_», и параметр _layer, который принимает имя слоя, на котором нужно отображать экран – один из таких.

Другой способ вызвать/прятать экран – с помощью питоновской функции renpy_show/renpy_hide.

# показывает и прячет экран my_screen
renpy.show_screen(«my_screen»)
renpy.hide_screen(«my_screen»)

# показывает экран another_one с анимацией dissolve
renpy.show_screen(«another_one»)
renpy.with_statement(dissolve)

# показывает экран parametrized на слое my_layer вместо слоя screens, передавая в вызов параметры param_one и param_two
renpy.show_screen(«parametrized», _layer = «my_layer», param_one = «test», param_two = False)

Третий способ – вызов/скрытие экрана через экшены Show/Hide. Использовать его следует строго в комбинации с кнопками любых видов (imagebutton, textbutton, button). Экшены выполняются по нажатию, наведению фокуса на кнопку и потере фокуса кнопкой.

В примере выше мы показываем экран my_screen по нажатию кнопки «Кнопка», используя анимацию dissolve и с параметром my_param. В отличие от предыдущих случаев для указания анимации нам не нужна дополнительная команда – за это отвечает встроенный в экшен Show параметр transition. При наведении курсора на кнопку мы показываем экран hover_screen, при отведении курсора – прячем его с анимацией dissolve.

Есть еще один способ напрямую вызывать экран. Оператор call – это два в одном, он отвечает и за вызов, и за скрытие экрана. Его поведение отличается от поведения пары show-hide. Экран, вызванный с помощью show (если он не модальный), не будет мешать прочим действиям игрока, и будет висеть в окне до тех пор, пока не встретится команда hide. Экран, вызванный с помощью call, приостановит смену слайдов, будет ждать взаимодействия с пользователем, и только тогда скроется. За взаимодействие считается, например, возвращение результата с помощью экшена Return(), или прыжок на метку с помощью Jump().

screen notification_screen:
frame:
vbox:
textbutton «Кнопка раз» action Jump(«sublabel»)
textbutton «Кнопка два» action Return()

label start:
call screen notification_screen
«Если ты видишь этот текст, то ты нажал кнопку два, чтобы скрыть окно.»

label sublabel:
«Если ты видишь этот текст, то ты нажал кнопку раз, чтобы прыгнуть на метку. Как побочный эффект, скрылось окно.»

От поведения модального окна, вызванного show, поведение окна, вызванного с помощью call, отличается тем же – модальное окно исчезнет только после прямой команды hide, тогда как called-окну достаточно конца взаимодействия.

У оператора call тоже есть python-аналог: renpy.call_screen()
Несмотря на то, что пишется в документации, with с call не работает (на момент написания тестировалось в версии 6.99.9).

Объявляют новый экран с помощью оператора screen.

Лирическое отступление: то, каким будет любой созданный объект, задается с помощью параметров и свойств.

Параметры – это то, без чего объект не может быть объектом (стул будет стулом, если у него есть ножки, сиденье и спинка). Свойства – это то, что отличает объект от других (стул может быть деревянный или пластиковый, сиденье – мягким или жестким. )

Отступление от лирического отступления: «Объект не может существовать без параметров? Но как же, ведь есть необязательные параметры!» Да, пользователю не обязательно их задавать (потому что у них есть некоторое значение по умолчанию), но для существования объекта они все еще обязательны.

Чтобы еще больше вас запутать контекстами: пользователь может приказать screen-объекту принимать свои собственные параметры!

Ладно, вернемся на рельсы, хватит лирических отступлений.

Для экрана my_screen, объявленного выше, my_screen (имя) – это значение параметра. Оператор screen принимает единственный параметр: имя экрана. Свойств у оператора screen пять:

modal: если это свойство установлено в True, экран будет модальным. Модальный экран блокирует действия пользователя с элементами вне этого экрана (за исключением стандартных хоткеев). Как пример – встроенный экран да/нет при сохранении, загрузке и выходе из игры у Ren’Py является модальным.

tag: задает экрану тег. Несколько разных экранов могут делить один и тот же тег на всех, и тогда при вызове любого из них по имени, закрываются все остальные, имеющие тот же тег. На примере внутриигрового меню: экраны настроек, сохранения, загрузки – это три разных экрана, имеющие один и тот же тег. Если мы вызовем экран настроек, потом из него вызовем экран сохранения, экран настроек спрячется автоматически.

zorder: отвечает за порядок расположения экранов на слое. Принимает числовые значения, чем больше число, тем выше положение экрана относительно других. По умолчанию у всех экранов zorder – 0.

variant: если кратко, то эта переменная указывает на тип устройства, к которому будет привязан этот экран (пк, планшеты, и т.д.) Подробнее можно почитать в мануале. https://www.renpy.org/doc/html/screens.html#screen-variants

style_prefix: задает префикс стилям всех дочерних объектов экрана, если у них не задан стиль на более глубоком уровне.

Работу с префиксами и суффиксами и стилизацию объектов в деталях разберем позже, это тема отдельного гайда.

Стоит помнить, что совсем не обязательно перечислять сразу все свойства при объявлении объекта. Можно ни одного, можно часть.

Язык работы с экранами включает в себя набор операторов, которые помогают управлять содержимым экрана.

Условный оператор if работает абсолютно так же, как if в прочих блоках. Если условие выполняется, заключенный в него блок тоже выполняется. Если нет – блок будет проигнорирован.

Условный оператор showif похож на оператор if: если условие соблюдено, то пользователь видит заключенный в это условие блок. Однако работает showif несколько иначе.

Во-первых, блок в ложном условии оператора showif полностью отработает и отрендерится, но будет скрыт, тогда как блок в ложном условии оператора if будет проигнорирован компилятором.

Вторая большая польза – и большое отличие showif в том, что как только условие выполнится, для блоков внутри этого условия сработает событие show (и, соответственно, когда условие станет ложным, для них сработает событие hide). Это удобно использовать в связке с ATL (трансформациями), которые умеют запускать анимацию по каждому триггеру событий show и hide.

Оператор showif триггерит три вида событий:

appear: срабатывает, если при первом вызове экрана условие истинно, сразу отображая дочерний блок.
show: срабатывает при каждом обращении условия из ложного в истинное
hide: срабатывает при каждом обращении условия из истинного в ложное

Оператор if при изменении истинности условий события не триггерит.

transform cd_transform:
xalign 0.5 yalign 0.5 alpha 0.0

screen countdown():
default n = 3

vbox:
textbutton «3» action SetScreenVariable(«n», 3)
textbutton «2» action SetScreenVariable(«n», 2)
textbutton «1» action SetScreenVariable(«n», 1)
textbutton «0» action SetScreenVariable(«n», 0)

showif n == 3:
text «Three» size 100 at cd_transform
elif n == 2:
text «Two» size 100 at cd_transform
elif n == 1:
text «One» size 100 at cd_transform
else:
text «Liftoff!» size 100 at cd_transform

label start:
call screen countdown

Оператор for – это итератор. С его помощью можно заставить определенный блок кода отработать несколько раз или последовательно пройти по массиву или словарю данных. Захотели мы, например, анимировать падающий снег, и для этого нам нужно вывести на экран сотню изображений снежинок. Оператор for в этом поможет.

Кроме повторения блоков, цикл for можно использовать для прохода по массивам и/или словарям с данными. Скажем, для создания экрана инвентаря – вывода списка того, что завалялось у героя в карманах:

screen inventory_screen:
frame:
has vbox

# в переменную i будет помещен элемент массива, соответствующий текущему шагу, начиная с самого первого элемента массива, заканчивая последним.
for i in inv_array:
text «[i]»

# в переменную id будет помещаться ключ текущего шага, в item – соответствующий этому ключу элемент
for id, item in inv_dict.items():
text «Объект [id]: [item]»

В примере выше inv_array – массив, inv_dict – словарь, их структура и работа с ними отличается. Словарь позволяет сделать привязку элементов к ключу. Перед тем, как запускать цикл по словарю, нужно превратить его в итерабельный объект, для этого используется метод .items(). Он возвращает массив пар (ключ, элемент), т.е., для нашего примера – массив: [ («001», «корзина»), («002», «картина»). ]. На каждом шаге цикл будет получать кортеж из двух переменных (tuple), соответственно, для хранения тоже нужно две переменных: id, item.

В отличие от массивов, словари – неупорядоченная структура. Элементы в словаре не будут держаться в том порядке, в каком вы их туда внесли. Если для вас это важно, придется дополнительно использовать сортировку.

Оператор default задает значение переменной по умолчанию. Это удобно, если внутри экрана мы используем некоторую переменную, которую можем не передать в качестве аргумента, или не объявить заранее. Если не использовать оператор default, и попытаться вызвать экран с несуществующей переменной, это вызовет ошибку.

screen my_screen:
default some_var = 42

frame:
text «Значение переменной: [some_var]. Переменная будет всегда определена, даже если ее не передали в качестве параметра и не объявили внутри экрана.»

Оператор on позволяет отслеживать срабатывание событий и при срабатывании выполнять заданные вами действия. В качестве параметра on принимает имя отслеживаемого события, одного из четырех допустимых:

show: срабатывает при каждом вызове экрана с помощью show или call, если этот или все экраны с таким же тегом до этого были скрыты.
hide: срабатывает при каждом скрытии экрана с помощью hide, если до этого был вызван этот или любой экран с таким же тегом.
replace: срабатывает если текущий экран подменяет экран с таким же тегом.
replaced: срабатывает, если текущий экран подменяется новым экраном с таким же тегом.

screen test_screen:
default text = «»
frame:
text «[text]»

on «show» action SetVariable(«text», «Сработало событие show»)
on «replace» action SetVariable(«text», «Сработало событие replace»)

Оператор use позволяет включать один экран внутрь другого. В качестве параметра принимает имя включаемого экрана. Включаемый экран унаследует все параметры, переданные родительскому.

Один и тот же экран можно включить в другой в нескольких экземплярах.

screen main_scr:
frame:
has vbox

for i in xrange(1,4):
use child_scr(i)

screen child_scr(i):
text «Экран [i]»

label start:
show screen main_scr
pause

У оператора use есть единственное свойство, id. Оно работает в том случае, если два экрана с одинаковым тегом включают в себя один и тот же дочерний экран. Если родительские экраны сменяют друг друга, то на дочернем это не сказывается, и он сохраняется в том состоянии, в котором был до подмены.

В примере ниже у дочернего экрана common есть анимированный элемент. Если подменить один родительский экран (s1) на другой (s2) до завершения анимации, анимация не будет прервана.

transform trf:
xpos 500
linear 5.0 xpos 0

screen common:
text «Test» at trf

screen s1:
tag s
use common id «common»
text «s1» ypos 100

screen s2:
tag s
use common id «common»
text «s2» ypos 100

label start:
show screen s1
pause
show screen s2
pause
return

Связка use и transclude: сквозное включение.

Оператор use можно использовать так:

Источник

GUI Customization Guide link

Ren’Py features a GUI system that (we hope) looks attractive out of the box, can be customized somewhat, and can be replaced entirely if necessary. This page explains how to do simple and intermediate levels of GUI customization.

For more advanced customization, please take a look at the documentation for styles (including the list of style properties ) and screens (including screen actions and special screens ).

This assumes that you’re using a new-style Ren’Py GUI (contained in the gui.rpy file). Older GUIs (that use the screens.rpy file) should be treated as advanced GUI customization for the purposes of this guide.

Simple GUI Customization link

There are a few simple pieces of GUI customization that make sense for all but the simplest visual novels. What these customizations have in common is that they do not require editing gui.rpy. These customizations change the GUI somewhat, but do not drastically change the look of the GUI.

Change Size and Colors link

The easiest thing to change about the GUI is to change the size and color of the GUI. Ren’Py will prompt you to make these choices when you first create a project, but choosing «Change/Update GUI» in the launcher will let you change your choice.

When changing the GUI through the launcher, Ren’Py will prompt if you want to simply change the launcher, or update gui.rpy. Both choices will overwrite most image files, and overwriting gui.rpy will get rid of changes to that file.

As a result, you probably want to do this before any other customization.

Ren’Py will prompt for the default resolution of the project, and then also for the color scheme to use. Once you select those, it will update the GUI to match your choices.

Options.rpy link

There are a couple of variables in options.rpy that are used by the GUI.

config.name A string giving a human-readable name for the game. This is used as the window title, and throughout the GUI wherever the title of the game is needed. gui.show_name This should be set to False to hide the title and version number from the main menu. (Say, because the title is «baked into» the main menu image.) config.version A string giving the version of the game. This is presented to the user in various places. gui.about Additional text that is added to the about screen. If you want multiple paragraphs of credits, \n\n can be used to separate the paragraphs.

Here’s an example of these defines:

For convenience, it might make sense to define gui.about using a triple-quoted string, in which case line endings are respected.

Game and Main Menu Background Images link

The images used by the GUI can be found in the game/gui directory, which can be opened by choosing «Open Directory: gui» from the launcher. The relevant files are:

gui/main_menu.png A file that contains an image that is used in the background of all screens of the main menu. gui/game_menu.png A file that contains an image that is used in the background of all screens of the game menu.

The main menu, with only gui/main_menu.png replaced.

The about screen can be part of the game menu (using gui/game_menu.png as the background) or the main menu (using gui/main_menu.png as the background). Both can be set to the same image.

Window Icon link

The window icon is the icon that is displayed (in places like the Windows task bar and Macintosh dock) by a running application.

The window icon can be changed by replacing gui/window_icon.png.

Intermediate GUI Customization link

Next, we will demonstrate the intermediate level of GUI customization. At the intermediate level, it’s possible to change the colors, fonts, and images used by the game. In general, intermediate customization keeps the screens mostly the same, with buttons and bars in the same places, although modifying the screens to add new functionality is certainly possible.

Many of these changes involve editing variables in gui.rpy. For example, to increase the dialogue font size, find the line that reads:

and increase or decrease it, for example, to:

Note that the default values are often different than what’s found in this documentation. The default values can changed based on size and colors selected for the game, and the values in this file are an example of extensive GUI customization. It’s best to search gui.rpy for define and the variable in question – for example, «define gui.text_size».

Some of the adjustments below either partially or completely effect image files. As a result, the changes only take effect when the image files themselves are updated, which can be done by choosing «Change GUI» in the launcher, and telling it to regenerate image files. (But note that doing so will overwrite any image files you have already modified.)

You may want to consider waiting until your game is nearly complete before customizing gui.rpy in this way. While old gui.rpys will work in newer Ren’Py versions, newer gui.rpys may have features and fixes that older versions lack. Customizing the GUI early may make it harder to take advantage of such improvements.

Dialogue link

There are a number of relatively easy customizations that can be performed to change how dialogue is displayed to the player. The first is changing the textbox.

gui/textbox.png This file contains the background of the text window, displayed as part of the say screen. While this should be the full width of the game, text is only displayed in the central 60% of the screen, with a 20% border on either side.

In addition, there are a number of variables that can be customized to change dialogue.

define gui.text_color = «#402000» link

This sets the color of the dialogue text.

define gui.text_font = «ArchitectsDaughter.ttf» link

This sets the font that is used for dialogue text, menus, inputs, and other in-game text. The font file should exist in the game directory.

define gui.text_size = 33 link

Sets the size of the dialogue text. This may need to be increased or decreased to fit the selected font in the space allotted.

define gui.name_text_size = 45 link

Sets the size of character names.

define gui.textbox_height = 278 link

The height of the textbox. This should be the same height as the height of gui/textbox.png.

By default, the character name label uses the accent color. The color can be easily changed when defining a character:

An example textbox image.

Dialogue customized using the textbox image and the variable settings given above.

Choice Menus link

The choice screen is used by the menu statement to display choices to the player. Again, there are some relatively easy customizations that can be performed on the choice screen. The first are the two image files:

gui/button/choice_idle_background.png This image is used as the background of choice buttons that are not focused. gui/button/choice_hover_background.png This image is used as the background of choice buttons that are focused.

By default, text is placed in the central 75% of these images. There are also a couple of variables that control the color of the text in choice buttons.

define gui.choice_button_text_idle_color = ‘#888888’ link

The color used for the text of unfocused choice buttons.

define gui.choice_text_hover_color = ‘#0066cc’ link

The color used for the text of focused choice buttons.

These should suffice for simple customization, where the size of the images does not need to be changed. For more complex customizations, check out the section on buttons, below.

An example gui/button/idle_background.png image.

An example gui/button/choice_hover_background.png image.

An example of the choice screen, as customized using the images and variable settings given above.

Overlay Images link

There are also a pair of overlay images. These are used to darken or lighten the background image to make buttons and other user interface components more readable. These images are in the overlay directory:

gui/overlay/main_menu.png The overlay used by the main menu screen. gui/overlay/game_menu.png The overlay used by game-menu-like screens, including load, save, preferences, about, help, etc. This overlay is selected by the screen in question, and is used even when at the main menu. gui/overlay/confirm.png The overlay used in the confirm screen to darken the background.

Here are a pair of example overlay images, and what the game looks like with the overlay images added.

An example gui/overlay/main_menu.png image.

An example gui/overlay/game_menu.png image.

The main menu after changing the overlays.

The game menu after changing the overlays.

Colors, Fonts, and Font Sizes link

There are a number of GUI variables that can be used to change the color, font, and size of text.

These variables should generally be set to hexadecimal color codes, which are are strings of the form «#rrggbb» (or «#rrggbbaa» to specify an alpha component), similar to color codes used by web browsers. For example, «#663399» is the code for a shade of purple. There are many tools online that let you create HTML color codes, such as this one.

define gui.accent_color = ‘#000060’ link

The accent color is used in many places in the GUI, including titles and labels.

define gui.idle_color = ‘#606060’ link

The color used for most buttons when not focused or selected.

define gui.idle_small_color = ‘#404040’ link

The color used for small text (like the date and name of a save slot, and quick menu buttons) when not hovered. This color often needs to be a bit lighter or darker than idle_color to compensate for the smaller size of the font.

define gui.hover_color = ‘#3284d6’ link

The color used by focused items in the GUI, including the text of of buttons and the thumbs (movable areas) of sliders and scrollbars.

define gui.selected_color = ‘#555555’ link

The color used by the text of selected buttons. (This takes priority over the hover and idle colors.)

define gui.insensitive_color = ‘#8888887f’ link

The color used by the text of buttons that are insensitive to user input. (For example, the rollback button when no rollback is possible.)

define gui.interface_text_color = ‘#404040’ link

The color used by static text in the game interface, such as text on the help and about screens.

define gui.muted_color = ‘#6080d0’ link define gui.hover_muted_color = ‘#8080f0’ link

Muted colors, used for the sections of bars, scrollbars, and sliders that do not represent the value or visible area. (These are only used when generating images, and will not take effect until images are regenerated in the launcher.)

define gui.interface_text_font = «ArchitectsDaughter.ttf» link

The font used for text for user interface elements, like the main and game menus, buttons, and so on.

define gui.glyph_font = «DejaVuSans.ttf» link

A font used for certain glyphs, such as the arrow glyphs used by the skip indicator. DejaVuSans is a reasonable default for these glyphs, and is automatically included with every Ren’Py game.

define gui.interface_text_size = 36 link

The size of static text in the game’s user interface, and the default size of button text in the game’s interface.

define gui.label_text_size = 45 link

The size of section labels in the game’s user interface.

define gui.notify_text_size = 24 link

The size of notification text.

define gui.title_text_size = 75 link

The size of the game’s title.

The game menu after customizing text colors, fonts, and sizes.

Borders link

There are a number of GUI components – such as buttons and bars – that use scalable backgrounds configured using Border objects. Before discussing, how to customize buttons and bars, we’ll first describe how this works.

Borders are given to the Frame() displayable. A Frame takes an image, and divides it into nine parts – the four corners, the four sides, and the center. The corners always remain the same size, the left and right sides are stretched vertically, the top and bottom sides are stretched horizontally, and the center is stretched in both directions.

A Borders object gives the size of each of the borders, in left, top, right, bottom order. So if the following border image is used:

along with the following borders:

one possible result is this:

As the child changes size, so will the background.

A Border object can also be given padding, including negative padding that causes the child to overlap the borders. For example, these borders:

allow the child to overlap the sides. Note that due to this overlap, the result is smaller, since the borders themselves now take up less space.

Borders can also be tiled, rather than scaled. This is invoked by variables, and produces this result.

These example images are a bit ugly, since we need to show what’s going on. In practice, this system can produce quite pleasing results. This is the case when a Frame displayable is used as the background of a frame window holding user interface components.

These frame windows can be customized in two ways. The first is by changing the background image file:

gui/frame.png The image used as the background of frames windows.

And the second is by customizing variables.

define gui.frame_borders = Borders(15, 15, 15, 15) link

The borders applied to frame windows.

define gui.confirm_frame_borders = Borders(60, 60, 60, 60) link

The borders applied to the fame used in the confirm screen.

define gui.frame_tile = True link

If true, the sides and center of the confirm screen are tiled. If false, they are scaled.

An example gui/frame.png image.

The confirm screen after applying the customizations given above.

Buttons link

The Ren’Py user interface includes a large number of buttons, buttons that come in different sizes and that are used for different purposes. The various kinds of buttons are:

button A basic button. Used for navigation within the user interface. choice_button A button used for choices in the in-game menu. quick_button A button, displayed in-game, that is intended to allow quick access to the game menu. navigation_button A button used in main and game menu for navigation between screens, and to start the game. page_button A button used to switch between pages on the load and save screens. slot_button Buttons that represent file slots, and contain a thumbnail, the save time, and an optional save name. These are described in more detail below. radio_button A button used for multiple-choice preferences on the preferences screen. check_button A button used for toggleable preferences on the preferences screen. test_button A button used to test audio playback on the preferences screen. This should be the same height as a horizontal slider. help_button A button used to select what kind of help the player wants. confirm_button A button used on the confirm screen to select yes or no. nvl_button A button used for an NVL-mode menu choice.

The following image files are used to customize button backgrounds, if they exist.

gui/button/idle_background.png The background image used by buttons that are not focused. gui/button/hover_background.png The background image used by buttons that are focused. gui/button/selected_idle_background.png The background image used by buttons that are selected but not focused. This is optional, and is used in preference to idle_background.png if it exists. gui/button/selected_hover_background.png The background image used by buttons that are selected but not focused. This is optional, and is used in preference to hover_background.png if it exists.

More specific backgrounds can be given for each kind of button, by prefixing it with the kind. For example, gui/button/check_idle_background.png is used as the background of check buttons that are not focused.

Four image files are used as foreground decorations on radio and check buttons, to indicate if the option is chosen or not.

gui/button/check_foreground.png, gui/button/radio_foreground.png These images are used when a check or radio button is not selected. gui/button/check_selected_foreground.png, gui/button/radio_selected_foreground.png These images are used when a check or radio button is selected.

The following variables set various properties of buttons:

define gui.button_width = None link define gui.button_height = 64 link

The width and height of a button, in pixels. If None, the size is automatically determined based on the size of the text inside a button, and the borders given below.

define gui.button_borders = Borders(10, 10, 10, 10) link

The borders surrounding a button, in left, top, right, bottom order.

define gui.button_tile = True link

If true, the sides and center of the button background are tiled to increase or decrease their size. If false, the sides and center are scaled.

define gui.button_text_font = gui.interface_font link define gui.button_text_size = gui.interface_text_size link

The font and size of the button text.

define gui.button_text_idle_color = gui.idle_color link define gui.button_text_hover_color = gui.hover_color link define gui.button_text_selected_color = gui.accent_color link define gui.button_text_insensitive_color = gui.insensitive_color link

The color of the button text in various states.

define gui.button_text_xalign = 0.0 link

The horizontal alignment of the button text. 0.0 is left-aligned, 0.5 is centered, and 1.0 is right-aligned.

define gui.button_image_extension = «.png» link

These variables can be prefixed with the button kind to configure a property for a particular kind of button. For example, gui.choice_button_text_idle_color configures the color of an idle choice button.

For example, we customize these variables in our sample game.

define gui.navigation_button_width = 290 link

Increases the width of navigation buttons.

define gui.radio_button_borders = Borders(40, 10, 10, 10) link define gui.check_button_borders = Borders(40, 10, 10, 10) link

Increases the width of radio and check button borders, leaving extra space on the left for the check mark.

Here’s an example of how the play screen can be customized.

An example gui/button/idle_background.png image.

An example gui/button/hover_background.png image.

An image that can be used as gui/button/check_foreground.png and gui/button/radio_foreground.png.

An image that can be used as gui/button/check_selected_foreground.png and gui/button/radio_selected_foreground.png.

The preferences screen with the customizations described in this section applied.

Save Slot Buttons link

The load and save screens use slot buttons, which are buttons that present a thumbnail and information about when the file was saved. The following variables are quite useful when it comes to customizing the size of the save slots.

define gui.slot_button_width = 414 link define gui.slot_button_height = 309 link

The width and height of the save slot button.

define gui.slot_button_borders = Borders(15, 15, 15, 15) link

The borders applied to each save slot.

define config.thumbnail_width = 384 link define config.thumbnail_height = 216 link

The width and height of the save thumbnails. Note that these live in the config namespace, not the gui namespace. These do not take effect until the file is saved and loaded.

define gui.file_slot_cols = 3 link define gui.file_slot_rows = 2 link

The number of columns and rows in the grid of save slots.

There are the background images used for save slots.

gui/button/slot_idle_background.png The image used for the background of save slots that are not focused. gui/button/slot_hover_background.png The image used for the background of save slots that are focused.

Putting those to use, we get:

An example gui/button/slot_idle_background.png image.

An example gui/button/slot/slot_hover_background.png image.

The save screen after applying the customizations given in this section.

Sliders link

Sliders are a type of bar that is used in the preferences screen to allow the player to adjust preference with a large number of values. By default, the GUI only uses horizontal sliders, but a game may also use vertical sliders.

Sliders are customized with the following images:

gui/slider/horizontal_idle_bar.png, gui/slider/horizontal_hover_bar.png, gui/slider/vertical_idle_bar.png, gui/slider/vertical_hover_bar.png Images used for vertical and idle bar backgrounds in idle and hover states. gui/slider/horizontal_idle_thumb.png, gui/slider/horizontal_hover_thumb.png, gui/slider/vertical_idle_thumb.png, gui/slider/vertical_hover_thumb.png Images used for the thumb – the movable part of the bar.

The following variables are also used:

define gui.slider_size = 64 link

The height of horizontal sliders, and width of vertical sliders.

define gui.slider_tile = True link

If true, the frame containing the bar of a slider is tiled. If False, if it scaled.

define gui.slider_borders = Borders(6, 6, 6, 6) link define gui.vslider_borders = Borders(6, 6, 6, 6) link

The borders that are used with the Frame containing the bar image.

Here’s an example of how we customize the horizontal slider.

An example gui/slider/horizontal_idle_bar.png image.

An example gui/slider/horizontal_hover_bar.png image.

An example gui/slider/horizontal_idle_thumb.png image.

An example gui/slider/horizontal_hover_thumb.png image.

The preferences screen after applying the customizations given in this section.

Scrollbars link

Scrollbars are bars that are used to scroll viewports. In the GUI, the most obvious place a scrollbar is used is the history screen, but vertical scrollbars can be used on other screens as well.

Sliders are customized with the following images:

gui/scrollbar/horizontal_idle_bar.png, gui/scrollbar/horizontal_hover_bar.png, gui/scrollbar/vertical_idle_bar.png, gui/scrollbar/vertical_hover_bar.png Images used for vertical and idle bar backgrounds in idle and hover states. gui/scrollbar/horizontal_idle_thumb.png, gui/scrollbar/horizontal_hover_thumb.png, gui/scrollbar/vertical_idle_thumb.png, gui/scrollbar/vertical_hover_thumb.png Images used for the thumb – the movable part of the bar.

The following variables are also used:

define gui.scrollbar_size = 24 link

The height of horizontal scrollbars, and width of vertical scrollbars.

define gui.scrollbar_tile = True link

If true, the frame containing the bar of a scrollbar is tiled. If False, if it scaled.

define gui.scrollbar_borders = Borders(10, 6, 10, 6) link define gui.vscrollbar_borders = Borders(6, 10, 6, 10) link

The borders that are used with the Frame containing the bar image.

define gui.unscrollable = «hide» link

This controls what to do if the bar is unscrollable. «hide» hides the bar, while None keeps it shown.

Here’s an example of how we customize the vertical scrollbar.

An example gui/scrollbar/vertical_idle_bar.png image.

An example gui/scrollbar/vertical_hover_bar.png image.

An example gui/scrollbar/vertical_idle_thumb.png image.

An example gui/scrollbar/vertical_hover_thumb.png image.

The history screen after applying the customizations given in this section.

Bars link

Plain old bars are used to display a number to the player. They’re not used in the GUI, but can be used in creator-defined screens.

A bar can customized by editing the following images:

gui/bar/left.png, gui/bar/bottom.png Images that are used for the filled section of horizontal and vertical bars. gui/bar/right.pbg, gui/bar/top.png Images that are used for the filled section of horizontal and vertical bars.

There are also the usual variables that control bars:

define gui.bar_size = 64 link

The height of horizontal bars, and width of vertical bars.

define gui.bar_tile = False link

If true, the bar images are tiled. If false, the images are linearly scaled.

define gui.bar_borders = Borders(10, 10, 10, 10) link define gui.vbar_borders = Borders(10, 10, 10, 10) link

The borders that are used with the Frames containing the bar images.

Here’s an example of how we customize horizontal bars.

An example gui/bar/left.png image.

An example gui/bar/right.png image.

A screen we defined to give an example of a bar.

Skip and Notify link

The skip and notify screens both display frames with messages in them. Both use custom frame background images:

gui/skip.png The background of the skip indicator. gui/notify.png The background of the notify screen.

The variables that control these are:

define gui.skip_frame_borders = Borders(24, 8, 75, 8) link

The borders of the frame that is used by the skip screen.

define gui.notify_frame_borders = Borders(24, 8, 60, 8) link

The borders of the frame that is used by the notify screen.

define gui.skip_ypos = 15 link

The vertical position of the skip indicator, in pixels from the top of the window.

define gui.notify_ypos = 68 link

The vertical position of the notify message, in pixels from the top of the window.

Here is an example of customizing the skip and notify screens.

An example gui/skip.png image.

An example gui/notify.png image.

These skip and notify screens in action.

Dialogue, Continued link

In addition to the simple customizations given above, there are a number of ways to control how dialogue is presented to the player.

Textbox link

The textbox (or window) is the window the dialogue is displayed in. In addition to changing gui/textbox.png, the following variables control how the textbox is displayed.

Name and Namebox link

The character’s name is placed inside a frame that uses gui/namebox.png as its background. In addition, there are a number of variables that control the presentation of the name. The namebox is only show if the speaking character has a name (an empty name, like » «, counts).

define gui.name_xpos = 360 link define gui.name_ypos = 0 link

define gui.name_xalign = 0.0 link

The horizontal alignment of the character’s name. This can be 0.0 for left- aligned, 0.5 for centered, and 1.0 for right-aligned. (It’s almost always 0.0 or 0.5.) This is used for both the position of the namebox relative to gui.name_xpos, and to select the side of of the namebox that is aligned with xpos.

define gui.namebox_width = None link define gui.namebox_height = None link define gui.namebox_borders = Borders(5, 5, 5, 5) link define gui.namebox_tile = False link

These variables control the display of the frame containing the namebox.

Dialogue link

The horizontal and vertical positions of the actual dialogue. These are usually a number of pixels from the left or top side of the textbox. Setting a variable to 0.5 centers the dialogue in the textbox (see below).

define gui.dialogue_width = 1116 link

This variable gives the maximum width of a line of dialogue, in pixels. When dialogue reaches this width, it will be wrapped by Ren’Py.

define gui.dialogue_text_xalign = 0.0 link

The horizontal alignment of dialogue text. 0.0 is left aligned, 0.5 is centered, and 1.0 is right-aligned.

Examples link

To center the character’s name, use:

To center dialogue text, use:

Our example game uses these statements to customize the centered namebox:

An example gui/namebox.png image.

The example game, customized with the settings above.

History link

There are a few variables that control the way the history screen is displayed.

define config.history_length = 250 link

The number of blocks of dialogue Ren’Py will keep at history.

define gui.history_height = 210 link

The height of a history entry, in pixels. This can be None to allow the height of a history entry to vary at the cost of performance – config.history_length may need to be lowered significantly when this is None.

define gui.history_name_xpos = 0.5 link define gui.history_text_xpos = 0.5 link

The horizontal positions of the name label and dialogue text. These can be a number of pixels from the left side of the history entry, or 0.5 to center.

define gui.history_name_ypos = 0 link define gui.history_text_ypos = 60 link

The vertical positions of the name label and dialogue text, relative to the top of a history entry, in pixels.

define gui.history_name_width = 225 link define gui.history_text_width = 1110 link

The width of the name label and dialogue text, in pixels.

define gui.history_name_xalign = 0.5 link define gui.history_text_xalign = 0.5 link

This controls the alignment of text and the side of the text that is aligned with xpos. 0.0 is left-aligned, 0.5 is center-aligned, 1.0 is right-aligned.

The history screen customized with the settings given above.

NVL link

The nvl screen displays NVL-mode dialogue. There are a number of ways it can be customized. The first is to customize the NVL-mode background image:

gui/nvl.png The background image used in NVL-mode. This should be the same size as the game window.

There are also a number of variables that are used to customize the way NVL-mode text is displayed.

define gui.nvl_borders = Borders(0, 15, 0, 30) link

The borders around the background of the NVL-mode. Since the background is not a frame, this is only used to pad out the NVL-mode to prevent it from pressing up against the sides of the screen.

define gui.nvl_height = 173 link

The height of a single NVL-mode entry. Setting this to a fixed height makes it possible to have NVL-mode without paging, showing a fixed number of entries at once. Setting this to None allows entries to be of a variable size.

define gui.nvl_spacing = 15 link

The spacing between entries when gui.nvl_height is None, and the spacing between NVL-mode menu buttons.

define gui.nvl_name_xpos = 0.5 link define gui.nvl_text_xpos = 0.5 link define gui.nvl_thought_xpos = 0.5 link

The positioning of character names, dialogue text, and thought/narration text, relative to the left side of the entry. This can be a number of pixels, or 0.5 to represent the center of the entry.

define gui.nvl_name_xalign = 0.5 link define gui.nvl_text_xalign = 0.5 link define gui.nvl_thought_xalign = 0.5 link

The alignment of the text. This controls both the alignment of the text, and the side of the text that is placed at xpos. This can be 0.0 for left, 0.5 for center, and 1.0 for right.

define gui.nvl_name_ypos = 0 link define gui.nvl_text_ypos = 60 link define gui.nvl_thought_ypos = 0 link

The position of character names, dialogue text, and thought/narration text, relative to the top of the entry. This should be a number of pixels from the top.

define gui.nvl_name_width = 740 link define gui.nvl_text_width = 740 link define gui.nvl_thought_width = 740 link

The width of each kind of text, in pixels.

define gui.nvl_button_xpos = 0.5 link define gui.nvl_button_xalign = 0.5 link

The position and alignment of NVL-mode menu buttons.

Ren’Py does not use NVL-mode by default. It must be invoked using NVL-mode characters, and by defining a few variables in script.rpy.

Here’s an example of the NVL screen as customized with the settings above.

An example gui/nvl.png image.

The example game, customized with the settings above.

Text link

Most text can be customized using GUI variables. The variables used are of the form:

If present, the font used for the text.

If present, the size of the text.

If present, the color of the text.

Other text style properties cam also be set in the same way. For example, gui.kind_text_outlines sets the outlines property.

The kind prefix can be omitted, in which case it customizes the default look of text. Otherwise, it may be one of the button kinds above, or one of:

interface For default text in the out-of-game interface. input For text in a text input widget. input_prompt For the prompt portion of a text input. label For decorative labels. prompt For confirmation prompts asking the player a question. name For character names. dialogue For dialogue. notify For notification text.

puts a drop shadow to the right of and below dialogue text.

Translation and GUI Variables link

The gui namespace is special, in that it is saved after the init phase, but before any translate python blocks are run. This makes it possible to change any GUI variable in a translate python block to accommodate a second language. For example, the following code changes the default text font and size.

There is one issue that translators need to be aware of, and that is that in some places in gui.rpy, one variable is assigned the value of another. For example, the default gui.rpy has:

Since both of these statements run before any translate block runs, both variables need to be changed.

If the second statement was missing, DejaVuSans would still be used.

Advanced Customization link

More advanced customization is possible by customizing screens.rpy, up to and including deleting the entire contents of the file and replacing it with something of your own. Here are a few places to get started.

Styles link

Styles and style properties control how displayables are displayed. To find out what style a displayable is using, put the mouse over it and type Shift+I. This invokes the style inspector, which shows style names. Once the style name is known, a style statement can be used to customize it.

For example, say we’ve lost our minds writing GUI documentation, and want to add a bright red outline to the dialogue text. We can hover the text and press Shift+I to find out the style used is named say_dialogue. We can then add (to the end of screens.rpy, or somewhere in options.rpy) the style statement:

A huge number of customizations are possible using style statements.

The next level of customization is to modify the screens. The most important documentation about screens is located in the Screens and Screen Language and Screen Actions, Values, and Functions sections.

One of the most important screens is the navigation screen, which serves both as the main menu, and to provide navigation for the game menu. This screen can be edited to add more buttons to one or both of those. For example, by changing the navigation screen to:

We add access to a prologue screen from the main menu, a codex screen from the game menu, and an extras screen from both menus.

Custom game menu screens can also be created. These screens can use the game_menu screen to provide a title and scrollable viewport. An minimal custom game menu screen is:

Clearly, a functional codex would need to be more elaborate than this.

Note the «tag menu» line. This line is important, as it hides other menu screens when the codex is shown. Without it, it would be hard to switch to and from the other menu screens.

A screen we expect to be commonly added is the click to continue screen. This is a screen that is shown when text finishes displaying. Here’s a simple example:

This particular ctc screen uses a transform to show the frame after 5 seconds. It’s a good idea to delay CTC animations for several seconds, to give Ren’Py time to predict and load images.

Total GUI Replacement link

See Also link

For more information about the GUI, see the Advanced GUI section.

Incompatible GUI Changes link

As the GUI is changed, occasionally some of the variables change name. These changes only take effect when the GUI is regenerated – until then, the game will continue to use the old variable names in the new Ren’Py.

6.99.12.3 link

© Copyright 2012-2021, Tom Rothamel.
Created using Sphinx 1.6.6.

Источник