читы для renpy игр
Читы для renpy игр
95)Как сделать так что бы музыка играла в определенное время.
Пишем в сценарии например:
play music » music/410.mp3″ fadein 2
Но тут возник вопрос, а как определить точное время?
Нашел 1 код который позволяет нам определить точное время которое возникло с момента клика
init python:
. import time
. x = 0
label start:
. «Нажмите левую кнопку»
. while x Нравится Показать список оценивших
98) Как прописать кнопке варианты нажатий(правая и левая кнопка мыши)
Возьмем такой пример:
«textbutton _(«Skip») action Skip() alternate Skip(fast=True, confirm=True)»
99) Оптимизация видео для Android (режим максимальной производительности)
Дополнительные программы: ffmpeg
Для начала на уровне Ren’Py прописываем параметр «config.hw_video = True» в options.rpy, включающий режим аппаратного рендеринга видео.
И разбираем всё содержимое:
-i — входящее видео
-vcodec libvpx — видеокодек. Так как у нас андроид, то наиболее производительным будет vp8, то есть libvpx.
-b:v 3000k — битрейт или относительная скорость потока. Для повышения производительности ставим либо как в youtube (720p = 4000k, 1080p = 8000k), либо меньше.
-deadline realtime — ставим режим обработки видео. В режиме реального времени результаты очень сильно разнятся от устройства к устройству, но производительность увеличивается.
-cpu-used 2 — сложность cpu-декодирования видео. Может быть в диапазоне значений от 0 до 5. Уже с 1-ого начинается прирост производительности и вплоть до 5-ти за счёт ущерба качеству.
-vf scale=iw/1.5:-1 — это аргумент для масштабирования 1920×1080 в 1280×720 и далее в том же духе. Разрешение играет большую роль для декодирования, так что если у вас новелла в FULL HD, то подумайте двадцать раз, а не сделать ли вам отдельную версию для android, чтобы телефоны не тратили ресурсы на даунскейлинг (уменьшение картинки видео)
-acodec libopus — аудиокодек. Можно вместо libopus использовать libvorbis, но libopus почти наверняка будет меньше весить, и он обеспечит меньшую задержку воспроизведения.
Ну и последним пишем выходной файл — «video2.webm»
Обязательно иметь в наличии: Python 2.7 или выше, но не Python 3
Гайд по установке (от и до):
>Устанавливаем Python.
>Переходим по ссылке на github, (при необходимости выбираем другой branch), нажимаем на «clone or download» и «Download ZIP».
>Весь zip деархивируем в папку python и оставляем как есть.
>При необходимости пишем батники, я привожу примеры только на Windows
Превосходная простая программа для декомпиляции *.rpyc файлов. Разработчик обещает поддержку всех Renpy 6, но так как после 6.99.9 утилита не была особо тестирована, то при возникновении ошибок не поленитесь написать ему на гит.
Пример кода: python unrpyc.py script1
Также Unrpyc часто подвергается мелким изменениям, так что проверяйте ветку (branch) dev.
Пример батника: for %%a IN (*.rpyc) DO python unrpyc.py %%a
Проверенная временем утилита для разархивирования *.rpa файлов. Лично я рекомендую использовать следующую утилиту.
102) Добавляем внутриигровые покупки в игру под Android
Решил сделать альтернативу монетизации через рекламу (AdMob). Устанавливается даже проще АдМоба.
На iOS делается аналогично, только не нужно копипастить ключ приложения. Подробнее не напишу, ибо айфона нет.
1) Приобретаем аккаунт разработчика Google Play, если его еще нет.
2) В Google Play Developer Console на вкладке «Все приложения» нажимаем «Новое приложение».
3) Вводим название игры и нажимаем «Создать».
4) Нас перебрасывает на окно заполнения данных о будущей игре, но нам интересна только вкладка «Службы и API» в левой части экрана.
5) Копируем ключ приложения из раздела «Лицензирование и продажа контента».
6) Открываем свой options.rpy и раскомментируем строку define build.google_play_key = » » и между кавычек вставляем скопированный ключ. ПРОВЕРЯЕМ ЧТОБЫ В СКОПИРОВАННОМ КЛЮЧЕ НЕ БЫЛО ПРОБЕЛОВ!
7) Теперь можно вставлять код в script.rpy. Перед запуском регистрируем покупку следующим образом:
init:
define unlock_lvl = iap.register(
product = «unlock_lvl»,
identifier = «ru.chislov.mygame»,
google = «Моя игра»,
)
unlock_lvl это идентификатор покупки, имя придумываете сами
В identifier, соответственно, ваше имя пакета
google это название игры, если поставить None, то именем игры будет имя пакета.
screen billing:
imagebutton xalign 0.2 yalign 0.3:
idle («images/idle_billing.png»)
hover («images/hover_billing.png»)
action Jump(«label_billing»)
screen restore:
imagebutton xalign 0.2 yalign 0.4:
idle («images/idle_restore.png»)
hover («images/hover_restore.png»)
action Jump(«label_restore»)
9) Далее проверяем, куплена игра ранее или нет. В том месте, где необходимо открыть новый левел, прописываем:
if iap.has_purchased(«unlock_lvl»):
jump continue_game
else:
show screen billing
show screen restore
«Для дальнейшей игры необходимо купить уровень или восстановить покупку»
$ renpy.pause(hard=True)
10) Если игра не куплена, то перекидываем юзера на label_billing или label_restore, если он покупал ранее левел:
label label_billing:
$ iap.purchase(«unlock_lvl»)
«Если оплата произведена успешно, игра продолжится. Нажмите для продолжения»
if iap.has_purchased(«unlock_lvl»):
«Спасибо за покупку уровня! Продолжаем игру»
jump continue_game
else:
«Оплата отменена»
label label_restore:
$ iap.restore(«unlock_lvl»)
«Если восстановление покупки прошло, то игра продолжится. Нажмите для продолжения.»
if iap.has_purchased(«unlock_lvl»):
«Покупка была восстановлена! Продолжаем играть»
jump continue_game
else:
«Покупка не была восстановлена.»
Читы для renpy игр
44) Эффекты переходов ImageDissolve.
Сдесь собранной около 200 картин преходов
Для получения эффекта вам потребуется создать через init переменную. Будет выглядеть так(пример)
Init:
$ pic = ImageDissolve(«images/pic.png», 1.0.8) # открыли
$ pic2 = ImageDissolve(«images/pic.png», 1.0.8, reverse=True) #закрыли
И в игре прописать картинке эффект
scene negr with pic (можно просто with pic)
Все картинки являются бесплатными и не имеют лицензии
45) Игры рпг в стиле меча и магии написанные на RenPy
49)Таймер со шкалой времени в виде бара, так же прописан куда пойдет персонаж если не успеет уложиться во времени
В версии 2.1 был добавлен qte код
51) ссылки на все клавиши которые прописываются на питоне
http://www.pygame.org/docs/ref/key.html
pygame.key
pygame module to work with the keyboard
pygame.key.get_focused — true if the display is receiving keyboard input from the system
pygame.key.get_pressed — get the state of all keyboard buttons
pygame.key.get_mods — determine which modifier keys are being held
pygame.key.set_mods — temporarily set which modifier keys are pressed
pygame.key.set_repeat — control how held keys are repeated
pygame.key.get_repeat — see how held keys are repeated
pygame.key.name — get the name of a key identifier
This module contains functions for dealing with the keyboard.
The event queue gets pygame.KEYDOWN and pygame.KEYUP events when the keyboard buttons are pressed and released. Both events have a key attribute that is a integer id representing every key on the keyboard.
The pygame.KEYDOWN event has an additional attributes unicode, and scancode. unicode represents a single character string that is the fully translated character entered. This takes into account the shift and composition keys. scancode represents the platform specific key code. This could be different from keyboard to keyboard, but is useful for key selection of weird keys like the multimedia keys.
There are many keyboard constants, they are used to represent keys on the keyboard. The following is a list of all keyboard constants
Читы для renpy игр
Плюшка #30) Отключение скрола назад и вызова меню (кнопки ESC и правой мышиной).
Очень не хотелось оставлять возможность игроку в любой момент вернуться назад и сохраниться в любом, даже ключевом, месте +))) Поэтому нарыл эти решения, надеюсь они пригодятся кому нибудь еще.
Для отключения меню сохранения же пишем:
$_game_menu_screen = None
Для его повторного включения:
$_game_menu_screen = «save_screen»
31) Переключатели и переменные
Вот не большой скрипт для новичков, это способ проверки переменных, который позволяет отключать строки в диалогах и задавать проверки в ваших не линейных новела. Где от вашего выбора зависит судьба персонажа.
label start:
menu:
«-Включить скрытую кнопку.-«:
$ quest1 = True # включает переменную quest1
jump test1
«-Выключить скрытую кнопку-«:
$ quest1 = False # выключает переменную quest1
jump test1
label test1:
menu:
«-Вернутся-«:
jump start
«-Вернутся-«:
jump start
«-Скрытая кнопка-» if quest1: # проверяем включёна ли переменная quest1 если да, то кнопка появится на эране.Если нет, кнопки на экране не будет.
jump start
Если диалог должен появится при нескольких условиях то дописываем после if quest1 and и ещё одно условие, если вместо включить или выключить у вас параметр в виде цифр, скажем отношение с персонажем то делаем следующим образом.
Тот же самый код но не много изменённый:
label test1:
menu:
«-Вернутся-«:
jump start
«-Вернутся-«:
jump start
«-Скрытая кнопка-» if relations >= 2: # проверяем количество поинтов отношений, если их меньше 2 то кнопка будет скрыта.
jump start
Что бы не допустили распространенную ошибку, выставляем при новой игре default параметры
label start:
$ relations = 0
$ quest1 = False
То есть при каждой новой игре эти параметры будут скидываться (отношения на 0 а квест 1 будет отключён)
Вот собственно и всё.
Пишем текстовую игру на Python/Ren’Py
Как сделать текстовую игру? Да как угодно. Как сделать кроссплатформенную текстовую игру на русском с иллюстрациями, звуком, работающими сохранениями, без проблем с кириллицей, и с каким-никаким геймплеем? Да ещё и в свободное время, не отрываясь от основной работы? Вот это уже интересней и на самом деле — довольно несложно. Заинтересовавшихся прошу под кат.
Примерно год назад мы с товарищем задумали сделать небольшую текстовую игру приблизительно в духе Sunless Sea и 80 days: про мореплавание, торговлю, исследование странных поселений и общение со странными личностями. Там должна была фигурировать религия, а лучше несколько, главного героя хотелось видеть не спасителем, героем страны и прославленным мореходом, а умеренно неудачливым предпринимателем/авантюристом, до которого и дела никому нет, а модный выбор между меньшим и большим злом заменить на выбор между добром и добром: никакого набившего оскомину гримдарка ради гримдарка. Довольно быстро придумались основные фракции и персонажи, крупные порты, политическая обстановка и куча симпатичных мелочей вроде подводной охоты на осьминогов (изображена на КДПВ) и гениальной идеи дать почти всем персонажам венгерские имена, которые звучат экзотичней привычных европейских и вызывают некоторую неявную симпатию. В общем, деревянных домиков понабигало немало.
В команде у нас на тот момент был один писатель и один программист (то есть я). Требования в предыдущем абзаце относятся скорее к сетингу и духу игры, так что исполнять их должен был мой товарищ, а передо мной встали вопросы геймдизайна и функциональности движка. Во-первых, большую часть времени игрок будет тратить, читая текст и выбирая действия главного героя. Для этого нужна только сносная типографика и возможность писать сценарий с меню, опциями и переменными. Вскоре подключилась художница, так что надо было думать ещё и об иллюстрациях. Во-вторых, игра про исследования и торговлю, поэтому нужно где-то в доступном игроку виде хранить информацию о собранных слухах и купленных товарах (а также всячески её обрабатывать). И, наконец, в игре про мореходство нужна карта и возможность по ней перемещаться; просто команда “поплыть к тартарам и послушать сказки морских лошадей” явно не соответствует духу проекта. Значит, движок должен ещё и поддерживать хотя бы несложные мини-игры, а не ограничиваться только показом текста и обсчётом игровых переменных.
Почему Ren’Py
Сразу скажу, что писать движок с нуля мы даже не пытались: велосипедостроение увлекательно само по себе, но малоэффективно, если стоит цель всё-таки выпустить игру до выхода на пенсию. Также мы не рассматривали парсерную Interactive Fiction: у неё и на английском языке очень небольшая аудитория, а на русском наш проект, будь он парсерным, мог бы заинтересовать в лучшем случае несколько сот человек. А хочется если не заработать денег, то хотя бы пройти гринлайт и набрать какую-никакую репутацию. К счастью, большинство нынешних англоязычных разработчиков текстовых игр перешло от некоммерческих хобби-проектов к профессиональному геймдеву буквально несколько лет назад. Поэтому основные движки либо опенсорсны, либо, во всяком случае, бесплатны. Давайте посмотрим, что нам предлагают.
Первый вариант, пришедший мне в голову – Storynexus от Failbetter games, разработчиков Fallen London и Sunless Sea. Проекты на нём редактируются через браузер, хостятся Failbetter и через браузер же доступны игрокам. Возможности для монетизации с прошлого года удалили. Главный минус, однако, не в этом, а в том, что в Fallen London большая часть событий представлена картами, выпадающими из колоды, и сделать на Storynexus игру, не использующую эту метафору – задача нетривиальная. Да и вообще намертво привязывать свой проект к стороннему серверу с закрытым кодом, который теоретически может вообще прекратить работу в любой момент, довольно рискованно.
Есть ещё два хороших проприетарных движка для Choose Your Own Adventure, то есть игр примерно нашего типа: ChoiceScript и Inklewriter. Оба обещают прекрасную типографику, простоту разработки (браузерный редактор у Inklewriter, скриптовый язык у ChoiceScript) и возможность коммерческой публикации. К сожалению, оба позволяют делать только чистое CYOA: нет никакой возможности добавлять в игру что-то помимо собственно текста, меню и иллюстрациий. Внимательный читатель воскликнет: “Но как же так? В 80 days ведь был довольно сложный инвентарь и интерфейс путешествий, верно? А в Sorcery! я точно видел боёвку!” Увы, эти системы разрабатывались Inkle Studios под конкретные игры и в редакторе нет ни их, ни хоть какой-нибудь возможности сделать себе такие же. По той же причине (а также потому что он, эм, своеобразный) мы отказались от Twine.
Единственным устраивающим нас вариантом оказался Ren’Py. Это бесплатный опенсорсный движок для визуальных новелл (например, именно на нём сделаны “Бесконечное лето” и “Katawa shoujo”), который довольно легко настраивается для наших задач. Игры получаются кроссплатформенные: сборка дистрибутива под Win/Mac/Linux – вопрос нажатия одной кнопки, причём даже не надо иметь под рукой целевую ОС. Android и iOS также заявлены и Ren’Py-релизы под мобильные оси существуют, но мы сами пока на мобильный рынок не целимся и о разработке для него рассказать не можем. К тому же у Ren’Py очень дружелюбное и живое сообщество на русском и английском.
Простейший сценарий на Ren’Py
Ren’Py написан на Python 2.7 + Pygame и имеет собственный DSL. На этом языке, во-первых, за счёт команд типа “Показать bg_city_night_53.png в качестве фона без анимации” или “Произнести реплику «Cем… СЕМПАЙ. » от имени персонажа nyasha1” в императивном стиле пишется собственно сценарий. Во-вторых, подмножеством этого языка является Screen Language, на котором можно в декларативном стиле собирать из ограниченного набора Displayables (то есть виджетов: кнопок, изображений, текстовых полей и тому подобного) экраны и настраивать их функциональность. Если встроенных возможностей недостаточно, то с помощью Python можно добавлять собственные. Этим мы займёмся в следующей статье, а пока разберёмся со сценарием.
Сценарий в Ren’Py состоит из последовательности реплик, действий с экранами и ввода игрока. Про экраны и ввод чуть ниже, а для начала мы разберёмся с персонажами. В визуальной новелле они создаются так (код из официального туториала, с незначительными правками):
Создано два персонажа: протагонист и Сильви, оба пишут бледно-синим цветом в стандартное окошко внизу экрана. У Сильви к тому же есть портрет, который появится на экране перед тем, как она начнёт говорить. Выглядит это вот так:
Если бы мы создавали визуальную новеллу, то продолжали бы в том же духе, но мы-то не собираемся показывать портреты персонажей, да и иллюстраций пара десятков на всю игру. Большая часть текста вдобавок не является прямой речью персонажей, так что нелогично было бы привязывать её к кому-то из них. Лучше создадим виртуального персонажа-рассказчика:
Его зовут narrator; это специальное имя, которое отдаёт ему весь текст, явно не аттрибутированный другим персонажам (строго говоря, его зовут None, а narrator, как и m и s в предыдущем примере – переменная, в которую помещается объект персонажа и из которой вызываются его методы, например, say) Аргумент kind принимает два значения: adv и nvl. Первое – это дефолтное поведение, описанное выше, а второе включает nvl-режим, в котором портреты не показываются, а текстовое поле занимает большую часть экрана. Как раз то, что нам было нужно. Этот режим описывается экраном nvl_screen в файле screens.rpy и группой стилей styles.nvl* (файлы screens.rpy и options.rpy соответственно), в которых мы зададим шрифт, фон текстового поля, цвет меню и всё остальное.
Разберём построчно: сперва объявляется ярлык start, с которого начнётся игра. Это название зарезервировано и движок всегда будет переходить на него после нажатия кнопки “Новая игра”, где бы в сценарии он ни находился. Всё, что следует за ярлыком, логически находится “внутри” этого ярлыка, поэтому выделяется индентацией: она в Ren’Py работает так же, как и в чистом питоне. Инициализация картинки достаточно очевидна, а вот следующая строчка делает важную вещь: убирает весь текст с экрана nvl_screen. Автоматически это не делается, поэтому, если не расставлять nvl clear в конце каждой страницы, текст спокойно уползёт за пределы экрана и будет выводиться туда, пока экран не будет наконец очищен. Вроде бы мелочь, но на отладку пропущенных nvl clear я потратил намного больше времени, чем готов признать. Свежевымытый экран мы временно уберём, чтобы позволить игроку полюбоваться фоном, покажем фон, включим бесконечную паузу (то есть дождёмся клика) и начнём историю. Как только на nvl_screen начнёт выводиться текст, экран сам вернётся на место.
Строка с паузой, кстати, уже на питоне: для включения единичной строки её достаточно начать с ‘$’, а более длинные куски кода нужно писать внутри блока ‘python:’. Любой код, исполняемый игрой, видит модули самого Ren’Py и явно импортировать их уже не нужно.
Добавляем ветвление и переменные
К этому моменту игра представляет собой читалку, которая показывает текст, меняя при необходимости фоны. Сохранение, перемотка, главное меню и настройки уже работают из коробки. Однако если бы мы хотели написать иллюстрированную повесть, то мы бы её и написали, верно? Добавим перед текстом небольшое меню:
Теперь после включения игры пользователь (или, скорее, разработчик) сможет при желании войти в режим дебага или пропустить уже готовый кусок вступления и начать тестировать сразу кусок из последнего коммита. Строка show screen nvl закомменчена за ненадобностью – как я уже упоминал выше, экран покажется сам собой, когда на нём обновится текст. Комменты, как видите, работают абсолютно очевидным образом.
Ярлыки, меню и другие индентированные блоки могут быть вложены до произвольной глубины, но на практике мы стараемся дробить текст на эпизоды в десяток страниц. Каждый такой эпизод описан внутри отдельного ярлыка с нулевой индентацией (он уже не обязан быть внутри ярлыка start или даже в одном с ним файле), а переходы из одного эпизода в другой осуществляются прыжками. Так мы не только боремся с десятками уровней индентации, но и обеспечиваем модульность кода: каждый эпизод может тестироваться отдельно и довольно несложно проверить, какие переменные он читает, в какие пишет и куда позволяет перейти.
Внутриигровые меню и переменные устроены абсолютно так же. Поскольку и переменных, и ярлыков даже в небольшом эпизоде на десять минут игры разводится невероятное количество, мы приняли несложный вариант венгерской нотации: имя ярлыка ‘the_very_start_lazlo_nooptions’ состоит из трёх частей: названия локации the_very_start (то есть период от начала игры до первого выхода в море), названия эпизода lazlo (то есть пьянка у Лазло, на которой можно нанять молодых бездельников в матросы) и имени собственно ярлыка. При таком подходе имена получаются достаточно громоздкими, но лучше так, чем обнаружить при тестировании, что три месяца назад кто-то уже создал переменную ship_listing, выставил True бог весть где и теперь крен из одного случайного события влияет на исход другого случайного события на другом конце моря.
Вместо заключения
К этому моменту мы уже воспроизвели на Ren’Py функционал упоминавшихся выше Choicescript и inklewriter. Вроде бы наш кораблик готов к отплытию. В следующей статье я покажу, как можно создавать более сложный интерфейс с использованием экранного языка RenPy и ещё более сложный — на чистом питоне.
Читы для renpy игр
а) чтобы присвоить переменной случайное целое число из заданного диапазона (например, от 1 до 101):
$ r1 = renpy.random.randint(1, 101)
б) чтобы случайным образом сделать выбор элемента из заданного списка:
случайный выбор можно делать и среди объявленных ранее переменных:
$ r3 = renpy.random.choice([r1, r2])
случайно можно вытащить также сразу несколько значений:
$ r4 = renpy.random.sample([1, 2, ‘яблоко’, 4, ‘7’], 3)
# создаст список, включающий три случайных элемента из заданного списка.
в) для генерации дробного числа от 0 до 1 (т.е. 0.35, 0.271 и т.д.) применяется renpy.random.random()
(может пригодится для задания случайного положения чего-либо в долях экрана)
например, xpos = renpy.random.random()
или в скрине:
yalign renpy.random.random()
50+) дополнение к рандому
г) перемешивание элементов списка
$ playlist = [«song1.mp3», «song2.mp3», «song3.mp3», «song4.mp3», «song5.mp3»]
$ renpy.random.shuffle(playlist)
play music playlist fadeout 1.0 fadein 1.0
52) КАК СЛЕДУЕТ ЗАДАВАТЬ ВОПРОСЫ В ГРУППЕ RENPY: