Как создать текстовую игру
wikiHow работает по принципу вики, а это значит, что многие наши статьи написаны несколькими авторами. При создании этой статьи над ее редактированием и улучшением работали, в том числе анонимно, 24 человек(а).
Количество источников, использованных в этой статье: 8. Вы найдете их список внизу страницы.
Количество просмотров этой статьи: 40 218.
Текстовая адвенчура или же интерактивная беллетристика (interactive fiction, для краткости – IF) является старейшим жанром компьютерных игр, имеющая в наши дни относительно небольшую, но преданную фанатскую базу. Они, как правило, находятся в свободном доступе, используют незначительный объем вычислительной мощности, а, лучше всего то, что вы можете создать такую игру, без необходимости осваивать навыки программирования.
Опыт разработки текстового квеста под мобайл
В этой статье я расскажу, как разработать и опубликовать игру в жанре текстовый квест. Все изложенное в материале основано на опыте работы над Mr. President — сатирическим симулятором президента Африканской республики.
Расскажу об инструментах, которыми пользовалась наша команда и оставлю ссылки на полезные ресурсы.
Допустим, у вас уже есть интересная задумка. Начните с построения сюжетного дерева. Для этого идеально подойдет программа Microsoft Visio. Переставляя блоки, вы можете менять игровые события местами, не теряя при этом центральную нить повествования.
Рекомендую прочитать книгу, которая лично мне помогла написать сценарий игры. Это «Анатомия истории», Джона Труби.
Я изучил и протестировал наиболее распространенные программы для создания диалогов, и лучшей, на мой взгляд, является Twine. Она позволяет использовать переменные и экспортировать диалоги в JSON.
Twine позволяет создавать простые формулы типа:
set: $shotgun to 1
И проверять условия:
if: $shotgun is 1 go-to: «B50»
Вы можете создать сложный сюжет, в котором учитываются любые предыдущие действия игрока. В начале игры персонаж подобрал дробовик? Будет чем застрелить босса в финальной сцене. Главное не запутаться. Лучше сразу документировать все переменные, описывать, где они применяются и на что влияют.
Каким бы крутым автором вы себя не считали, найдите хорошего редактора. Со временем взгляд замыливается и бывает трудно заметить, что с предложением «Она люибла игарть на роляе и кормлиа голбуей с руки» что-то не так.
Любой текст, который вы пишите, проходит через призму субъективного восприятия. Многое кажется очевидным вам, но совсем не очевидно игроку. Мозг заполняет пустоту в описании своим личным опытом, и когда мы слышим словосочетание «вкусная еда» — у нас возникают разные ассоциации. И если это важно по сюжету, постарайтесь конкретизировать образ.
Редактор — это ключевая фигура на этапе написания сценария, и если вы найдете такого человека, считайте, что вам крупно повезло.
Рекомендую прочитать книгу замечательного литературоведа Норы Галь «Слово живое и мертвое». Это по-настоящему полезная книга, изучить которую должен каждый уважающий себя автор.
При сохранении материалов пользуйтесь системой управления версиями. Абзац, который вы выбросили неделю назад, может внезапно понадобиться вам сегодня.
При работе в одиночку я допускаю некий творческий беспорядок, но в команде с материалами должен быть полный порядок. Приучите себя и других автоматически синхронизировать рабочие файлы в облаке. Для этого подойдет Google Disc с установленным на компьютере Google Sync. Это позволит избежать ситуации, когда макеты накроются медным тазом после того, как дочка дизайнера прольет молоко на ноутбук (да, увы, был такой печальный опыт).
Я писал дизайн-документ, используя Google Docs. Возможно, что для более сложных проектов вы захотите использовать Вики-сервисы. Как вариант: бесплатный движок Dokuwiki, который можно развернуть на собственном Веб-сервере.
На этапе программирования синхронизируйте проект с Git — например, Bitbucket. Опытным разработчикам мои советы покажутся очевидными, но я уверен, многие пилят проекты локально, а потом обмениваются исходниками через файлообменник. Или я ошибаюсь? Напишите в комментариях, кто как работает с файлами проекта.
Самый очевидный вариант: опубликовать объявление на фриланс. Максимально сузив категорию проекта до «Рисунки и иллюстрации», я ждал что мне начнут писать художники, но нет. Откликнулись видеодизайнер, проект-менеджер и даже веб-программист. Я много работаю с фрилансом и без проблем нахожу технических специалистов, но подобрать толкового художника я не смог. И когда я почти отчаялся, то наткнулся на ресурс Artstation. Здесь люди выставляют свои работы и открыты для сотрудничества. Если вы, как и я, столкнетесь с проблемой поиска художника — отправляйтесь на Artstation.
Очень долго я рассматривал в качестве кандидата Corona. Из плюсов: движок кросс-платформенный. Минус: не самая дружелюбная среда разработки. Обсудив вопрос с программистом, мы решили разрабатывать на HTML5, а потом с помощью PhoneGap портировать на мобилки. Спорное решение, но конкретно в нашем случае мы сумели нивелировать недостатки этого фреймворка.
Написанные в Twine диалоги можно экспортировать в JSON. Для этого есть готовые скрипты, но нам пришлось доработать обработчик, чтобы он корректно форматировал формулы и переменные.
При публикации игры в Google Play мы использовали новый формат Android App Bundle (с расширением .aab). С его помощью можно существенно уменьшить размер приложения. При установке игры на телефон загружается только то, что нужно конкретному устройству.
Этап новых фич. Когда игра готова на 90% и вам кажется, что осталось «вот совсем чуть-чуть», возникает неотвратимое желание добавить в игру новую фичу (ведь без нее игроки точно не поймут всей крутизны задумки). В этот момент ответственный за релиз должен проявить себя как супер-адекватный человек. В начале разработки мы закладываем 10-15% на введение нового функционала. Это нормально. Но лучше сто раз подумайте, прежде чем переписать одну из ключевых механик.
Этап отторжения. Затем начинается фаза, когда перестает нравиться абсолютно все — от интерфейса до диалогов. Я начал выбрасывать из игры целые сюжетные ветки и в очередной раз переделывать иконки.
Этап багов. Если после предыдущей стадии от игры еще хоть что-то осталось, то добро пожаловать на этап багов.
И вот вы провели внутреннее тестирование, собрали актуальный билд и решили показать игру небольшой группе тестировщиков. Показали? Ловите новую тонну багов и замечаний по самому святому — геймплею. Вы, как геймдизайнер, можете отмахнуться и сказать — такая задумка, либо прислушаться к замечаниям игроков. И здесь вы столкнетесь с очередной дилеммой: поскорее выпустить игру или сделать все на совесть.
Я считаю, что у инди нет права на ошибку. Инди-разработчик, как сперматозоид, движется в потоке ему подобных. Чтобы достигнуть заветной цели, вы должны быть упорнее и требовательнее к себе. Если вы решитесь и примете замечания, то все пойдет по кругу: правки — баги — тестирование — замечания — правки.
Если вы прошли через все круги производственного ада, то публикация игры в App Store или Google Play покажется вам летней прогулкой в парке. Просто честно отвечайте на вопросы, особенно те, что касаются возрастного рейтинга.
Кстати, вот такая интересная особенность регионального рейтинга:
Если Австралия дала нам 18+ за намеки с сексуальным подтекстом, то для Европы и России это 12+.
Мы могли бы еще полгода переписывать реплики, добавлять шутки и в очередной раз переделывать иконки, но я понимаю, что мы попали в круговорот перфекционизма. Пора остановиться. Что получилось в итоге, вы можете оценить сами, поиграв в нашу игру.
Как написать текстовую игру (для чайников)
Свою. С нуля. То есть, совсем с нуля — лично я на старте не знала ничего, совсем ничего, вообще ничего, а про CSS и джава-скрипт слышала только то, что они существуют где-то там, где я их не вижу и не увижу никогда.
Вот прошла где-то неделя со старта. Писала я, в основном, вечерами (потому что работа и личные дела), пару дней просто разбиралась в документации и наводила красоту, но несмотря на это — у меня уже есть полторы главы где-то на 15к слов (около 3к в одном прохождении, потому что я обожаю вариативность), я знаю что-куда-как делать дальше, и, в общем-то, по самому процессу больше не возникает вопросов. Надеюсь все закончить за месяц-два и, в общем-то, я тогда и собиралась написать этот пост, но мне нужна передышка, да и какие-никакие оправдания к тому, почему я не пишу запланированные повести к «Нано».
Может, и вам захочется написать что-то свое?
Я люблю текстовые игры. Я очень люблю текстовые игры. В основном, играю-читаю новеллы Choice of Games, но видела всякое. И вот причина того, что я решила написать что-то свое как раз была в том, что хотелось «как у чойсов», но на русском и свое. Не в обиду ру-сегменту, но лично мне просто как правило всегда чего-то не хватало в проходимых русскоязычных квестах — то длины, то вариантов, то какой-никакой кастомизации главного героя. Да и тот факт, что главгерой там обычно мужчина, малость поднадоел — я хочу играть за свой пол Т__Т
Поэтому у меня есть небольшая надежда, что чем больше людей узнает о возможности написать собственную текстовую игру, тем больше интересных текстовых игр на русском языке я увижу в будущем.
В общем, что делать.
1. Сначала скачиваем Twine — бесплатно с оффсайта.
Это такая прога, в которой можно легко делать собственные текстовые квесты. Открываем ее, выбираем язык, жмем +История и. в принципе, это все.
Для того, чтобы написать текстовый квест, вам достаточно знать одну вещь — ссылки на новый параграф делаются так:
[[название параграфа<-Какой-то текст]]
Можно и по-другому их написать, но в целом — вот. Обладая этим сакральным знанием, вы уже можете написать простенький квест с разными вариантами прохождения. Да, вероятно, он будет довольно примитивен, но все же.
Если это вас не устраивает и хочется чего-то посложнее, то смотрим дальше.
2. В окне своей истории смотрим вниз, в выпадающий список — и выбираем «сменить формат истории». Там знакомимся с форматами и выбираем подходящий.
Я лично пишу на SugarCube 2, потому что там уже была встроена система сейвов. Возможно, если вы хотите делать не квест, а просто загнать свою историю в программу и побаловаться, то вам больше подойдет другой формат (например, относительно новый Chapbook).
Там же есть ссылки на документации по выбранному формату — очень подробные, поверьте. Проблема может быть в английском языке, но тогда — гугл в помощь. Гайды как минимум по SugarCube и Harlowe я точно видела и на русском.
Далее, третий пункт пишу с прицелом на SugarCube 2, в остальных форматах, возможно, все делается иначе.
3. Создаем параграф StoryInit, куда записываем наши переменные по умолчанию. Например, вы хотите, чтобы в игре главгерой сходил в магаз за хлебом, но на старте он находится дома и хлеба у него нет. Пишем в стори-инит что-то вроде:
Посылаем ГГ в магазин за хлебом, через ссылку из пункта один:
[[magaz<-И я пошел за хлебом]]
Появляется параграф magaz, в котором мы пишем, прежде чем приступить к описанию того, как главгерой купил хлеб:
Переменные $ нельзя называть кириллицей, но значения можно.
Если хотите, чтоб был вариант не купить хлеба, убираем <<set $hleb to ‘есть’>> и пишем новые ссылки на новые параграфы и уже в них ставим <<set $hleb to ‘est’>> — если купил; ничего не ставим, если не купил. Этот момент можно упростить, если следующий параграф у вас планируется одинаковым — тогда можем сразу перейти к нему и привязать хлеб к выборам. Выглядеть это будет как-то так:
[[Я купил хлеба|passage2][$hleb to ‘est’]]
[[Я не купил хлеба|passage2][$hleb to ‘net’]]
или так, чтобы не повторять значение ‘net’, тк оно у нас и так по умолчанию:
[[Я купил хлеба|passage2][$hleb to ‘est’]]
[[passage2<-Я не купил хлеба]]
Тогда мы в любом случае переходим в один и тот же параграф passage2, но в одном варианте переменная меняется, а в другом остается прежней.
А потом на магаз нападают инопланетяне! Герой бежит и скрывается в бункере! Или не бежит и остается в магазе!
Пишем в стори-инит дефолтное значение:
А в своем новом параграфе про нападение инопланетян:
<<set $gde to ‘бункер’>> — если он в бункере; если все еще в магазине, то ничего не пишем, это значение сохранилось с прошлого параграфа.
Ну и так далее: если у ГГ есть хлеб в бункере, то он не умрет от голодной смерти —
<<if $hleb is ‘est’ and $gde is ‘бункер’>>Пишем текст про то, как ГГ выжил в бункере на буханке бородинского.<</if>>
<<if $hleb is ‘net’ and $gde is ‘бункер’>>Пишем текст про то, как ГГ умер с голода в бункере.<</if>>
Пишем варианты для ситуаций, когда ГГ остался в магазине или вообще не пошел за хлебом — и текстовый квест готов.
4. Далее все просто — гуглим, если чего-то не знаем и не нашли ответа в документации. Да, документацию надо бы прочитать. Или ее, или хотя бы найденный где-нибудь гайд. Сложно, понимаю, но на этом закончится вся сложная техническая часть. Для Twine довольно много готовых макросов для облегчения жизни и всех свистелок, которые вам хочется.
Лично у меня до сих пор главная проблема ровно одна — с полом главгероя, так как я решила сделать игру с выбором пола и теперь вынуждена прописывать условие для каждого глагола прошедшего времени, например. Второе лицо и настоящее время тут спасают, очень спасают, но все-таки эти коварные глаголы иногда встречаются. И я не нашла никакого варианта кроме как каждый раз писать что-то вроде —
Я <<if $male is «женщина»>>пошла<<else>>пошел<</if>> в магаз за хлебом.
Как только закончили, жмем «опубликовать историю в файл» — и получаем html-страничку со своей игрой. В процессе ее можно запускать через Twine и смотреть, все ли идет правильно. В итоге, если вы дойдете до конца и сделаете свой квест, — эту страничку можно где-нибудь опубликовать. Например, на itch.io, сайте для инди-разработчиков, где есть отдельный жанр interactive fiction. Или еще где, я пока не думала над этим вопросом.
В общем, подводя итоги, для написания текстового квеста в Twine требуется три умения:
1. Писать (думаю, на писательском сайте с этим проблем нет)
2. Читать (уже сложнее, но, подозреваю, начальные скиллы есть у каждого)
3. Гуглить (эй, это необходимый навык в современном мире!)
И все. Удачи 
Мне пора идти писать про то, как ГГ прячется от монстра в ночном клубе.
Пишем текстовую игру на 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 и ещё более сложный — на чистом питоне.