Как сделать свой текстовый квест

Ink: инструмент для создания текстовых квестов как из лучших воспоминаний детства

Наверное, текстовые квесты одни из самых простых видов игр. Хоть там и требуется принимать решения, в них нет стратегических задач, а выбор заранее предопределен. Тем не менее, простые не значит плохие. Возможность влиять на сюжет книги выглядит очень привлекательно. Читатели практически всегда вступают в диалог с книгами, особенно если они хорошо написаны, переживают за героев, ругают их за нелогичные поступки, спорят с автором о сюжете. Текстовые квесты позволяют чувствовать себя полноправным участником происходящего и влиять на читаемую историю, чего так долго не хватало поклонникам обычных книг.

В сравнении с историей литературы этот жанр совсем молодой, зародился в середине прошлого века в виде экспериментов, их даже пробовали использовать для геймификации образования. Расцвет жанра пришелся на 70-е годы. Поначалу интерактивность была довольно условной, с простым ветвлением; читатель всего лишь выбирал варианты развития сюжета в духе: «А что если. ». Тем не менее, некоторые серии были чрезвычайно популярны. Одна из них, под названием «Выбери себе приключение», издавалась почти 10 лет (с 1979 по 1988). Книги серии переводились на множество языков, включая и русский.

Следующей ступенью эволюции жанра были сольные ролевые игры, копирующие жанр «Подземелья и драконы», но без гейм-мастера и других участников. К некоторым даже прилагалось игровое поле с фишками, но чаще всего можно было обойтись листом бумаги, куда заносились характеристики персонажа, или вообще одной только книгой. Тем не менее, в сложных ситуациях читатель-игрок записывал ходы, если не удавалось решить какую-то задачу с первого раза. Небольшая «пасхалка» из КДПВ ссылается как раз на одну из таких книг.

Игра запущенная на DPD-10

Компьютер дал подобным играм второе рождение. Первый текстовый квест Colossal Cave Adventure был написан на фортране в 1975 году и работал на мейнфрейме PDP-10. Уже тогда рабочие компьютеры использовались как средство развлечения за счет начальства. Создатель игры, Уильям Краудер, был не только программистом, но и спелеологом, потому сюжет был о поиске сокровищ в пещере, у которой был реальный прототип — Мамонтова пещера в американском штате Кентукки. Она знаменита тем, что является самой длинной в мире (общая длина исследованных проходов больше 500 километров); есть где спрятать сокровища!

Уйльям очень ответственно подошел к разработке: локации соответствуют помещениям в настоящей пещере и описаны очень точно, а в игре Уильям использует реальный спелеологический жаргон. Домик с ручьем снаружи, другие детали, типа решеток, перегораживающих отдельные ходы пещеры, вырубленные ступени тоже существовали в реальности на тот момент, но некоторые были переделаны или снесены.

Одно из реальных мест в пещере, описываемое в игре.

Программа выступала в роли гейм-мастера, описывая окружение локации, куда попал игрок, с юмором комментируя его действия и храня список предметов, которые находятся в инвентаре. Текст, который писала программа, выводился большими буквами, действия игрока — маленькими. Игра относится к тому типу, в котором для управления требуется вводить короткие команды из двух-трех слов.

ВЫ СТОИТЕ В КОНЦЕ ДОРОГИ ПЕРЕД НЕБОЛЬШИМ КИРПИЧНЫМ ЗДАНИЕМ.

ВОКРУГ ВАС ЛЕС. НЕБОЛЬШОЙ РУЧЕЙ ВЫХОДИТ ИЗ ЗДАНИЯ И СПУСКАЕТСЯ В ОВРАГ.

ВЫ НАХОДИТЕСЬ В ДОЛИНЕ В ЛЕСНОЙ ДОЛИНЕ, РЯДОМ С РУЧЬЕМ, КОТОРЫЙ СТРУИТСЯ ПО КАМЕННОМУ ДНУ.

Формального сюжета и конкретной цели не существует. У игрока есть три жизни, которых ему должно хватить, чтобы набрать 350 очков, необходимых для выигрыша. Очки выдавались за исследования пещеры и найденные сокровища. Первоначально в игре было 66 локаций, количество которых увеличивалось с каждой следующей версией. Позже развитием игры занялся Дон Вудс, который тогда был аспирантом в Стэнфордском университете. Под его началом в следующей версии количество локаций расширилось до 140. Однако Дон никогда не был в Мамонтовой пещере, и добавленные им локации уже не совпадают с реальностью.

В 1977 году James Gillogly впервые портировал игру на другую систему, а именно на Unix. Что любопытно, этот порт до сих пор входит в состав некоторых дистрибутивов, а если его нет, то можно установить в составе репозитория bsdgames (или отдельно) и играть даже на VPS через SSH.

Так как Дон активно распространял исходный код своей версии, то это способствовало росту ее популярности и тому, что она портировалась на каждую новую платформу: Apple, Commodore и, конечно же, MS-DOS.

Версия для MS-DOS была уже с простейшей графикой, содержала 130 локаций, 15 видов сокровищ, 40 предметов для инвентаря и 12 задач, которые требовалось решить по мере прохождения.

В 1985 году Дэйв Платт выпустил свою версию игры, где надо было набрать уже 550 очков, но которая кардинально отличалась подходом к программированию таких игр. Он создал универсальный язык написания сценариев «A-code», который обрабатывался движком написанным на FORTRAN 77. Это позволило очень легко делать модификации игры и создавать другие текстовые приключения. Практически все современные игры создаются подобным образом, на специальном языке разметки, который интерпретируется движком, как универсальным, в который можно загружать самые разные игры, так и проприетарным, выдающим исполняемый файл, который можно продавать в онлайн-магазинах.

Приключение Colossal Cave Adventure было родоначальником жанра и надолго сформировало каноны подобных квестов, а так же очень сильно повлияло развитие ролевых игр, в том числе и многопользовательских. Жанр MUD создавался по образу и подобию CCA. Даже Дональд Кнут не обошел вниманием эту игру и написал небольшую книгу, посвященную анализу кода игры в обучающих целях.

CCA является настоящим долгожителем. Дон Вудс продолжал выпускать обновления вплоть до середины 90-х, а в 2017 году Эрик Реймонд взял версию игры Дона от 1995 года, отладил ее, чтобы она запускалась на современных компьютерах, и выложил код на своей странице. Существует порт игры на Андроид и переводы ее на русский язык. Поиграть в один из приведенных вариантов можно на сайте Русский Информ, платформе для создания подобных текстовых игр. Можно играть как онлайн, так и скачав файл для движка Windows Frotz.

CCA на Windows Frotz

Наверняка, поиграв в AAC, кто-то вдохновится на создание собственного текстового квеста, тем более, что они все еще очень популярны. Современные возможности компьютеров позволяют дополнять их яркой графикой и анимацией, музыкой и звуками окружения, создавая увлекательные и современные игры, но не выходя за границы жанра. Для подобного творчества существует множество инструментов. Я хочу познакомиться вас с одним из них. Его отличает то, что это не просто программа написанная для развлечения, а реальный инструмент, используемый коллективом разработчиков для создания красивых и популярных игр, высоко оцененных любителями жанра и хорошо продающихся на всех современных платформах.

В 2011 году пара разработчиков из Кембриджа занялась производством интерактивных текстовых квестов и придумала средство для упрощения своей работы — Inklewriter. Год спустя они представили его в виде сайта, который позиционировался как простое средство для обучения программированию и создания интерактивной литературы. Его даже использовали в школах и удостоили награды «Best Website for Teaching and Learning» от Американской ассоциации школьных библиотек. Спустя несколько лет разработчики были вынуждены закрыть его по причине нехватки времени на его поддержку, но открыли код своего инструмента для работы (позже они его перезапустили). Ink получил возможность интеграции с Unity, и с его помощью стало возможно с легкостью создавать интерактивные истории, сочетающие в себе не только текст с рисунками, но и музыку с анимацией. Он был взят на вооружение и другими крупными инди-студиями разработки игр, а сама Inklestudios выпустила несколько успешных игр для разных платформ: ссылка. Игры очень милые, другого слова не подобрать. Им удалось заполучить в команду талантливого художника Anastasia Wyatt, что замечательно рисует.

Хоть создатели не считают Ink языком программирования, а только средством для разметки, интерактивные скрипты умеют не только обрабатывать ветвления, но и работать с переменными, использовать логические и математические операции и даже простейшие функции. Повествование может включать несколько потоков, чтобы автор мог более полно охватить возможные действия игрока и последствия его выбора.

Проект Inkle состоит из двух частей: руководство по языку разметки ink; IDE для работы с ним — Inky. Начать писать интерактивную историю очень просто. В Inky два окна: слева текст сценария, справа его интерпретация

Начнем новый сценарий: File → New Project. Вставим в редактор следующий пример и сохраним в отдельную директорию: File → Save Project.

На приведенном фрагменте очень простая структура:

Картинка должна лежать там же, где файлы экспортированные для интернета. После внесения изменений экспортировать достаточно один файл: File → Export story.js only, остальные содержат шаблона, в который помещается история.

Написав историю, можно экспортировать ее в интернет: File → Export for web. В директории проекта появятся несколько файлов: HTML-страница; стилевое оформление в CSS; файл движка ink.js; наш сценарий 80d.js (не редактируйте его напрямую); main.js, где описывается поведение сценария. Если вы знаете CSS, то вам не составит труда отредактировать внешнее оформление истории.

Закончив оформление, историю можно выложить в интернет. Авторы Ink рекомендуют воспользоваться порталом itch.io. Это бесплатный портал с простой регистрацией. При создании проекта для Ink выберите «Kind of project» HTML, загрузите архив с файлами проекта и отметьте опцию «This file will be played in the browser». Можно посмотреть, что получилось: ruvds.itch.io/inky-test.

Если вам в свое время тоже хотелось дополнить текстовые квесты «Рейнджеров» или написать свой текстовый квест, то не стоит сдерживать свою фантазию — дерзайте вместе с Inky!

Источник

Пишем текстовую игру на 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 и ещё более сложный — на чистом питоне.

Источник

Как написать квестовую RPG

Чистый лист — челлендж не только для художников, но и для геймдизайнеров. Здорово просто следовать за вдохновением в разработке игр, но иногда его нет и спасает методология. Перевели статью, где автор по шагам разбирает процесс создания квестовой RPG — с чего начать, как не отвлечься от основной идеи и что поможет в работе.

Я написал простую текстовую RPG в типичном фэнтезийном сеттинге. Можете поиграть в браузере. В проекте есть основной квест и семь дополнительных, а на финальном экране будет видно, какие из них вы прошли и пропустили. Сейчас расскажу, как именно создавался этот мини-проект.

Скриншот одного из сайд-квестов игры

Подготовка

Ресерч и брейншторм

Я понимал, что такое сайд-квест, и был готов сразу записать несколько идей. Но у меня был довольно небольшой опыт с RPG, при этом бывалые игроки и разработчики наверняка уже выдали тонны прекрасных концептов для сайдов. Мне оставалось только прочитать и бессовестно позаимствовать некоторые из них.

Пару лет назад Nerdarchy опубликовал список дополнительных квестов для RPG, и у Boccob в блоге есть несколько таких списков.

Я их прочитал и стащил идеи сделал кое-какие заметки. Вот тут пришла пора взяться за ручку и бумагу. Через пару брейнштормов в моем блокнотике появился примерно такой список:

заточение в поместье: сбежать от садиста-хозяина;

спасти ребенка из логова огра;

выиграть схватку в Долине Зеркал;

найти компонент заклинания для волшебника;

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

Выбор главного квеста и дополнительных

Стащив идею из Moonrunner Стивена Хэнда, я решил, что в основном квесте нужно выслеживать преступников и передавать их властям. Для сайдов уже был готов список, но не все ответвления я взял из него — многие пришли в голову, когда я начал структурировать тайтл.

Написание

Платформа Arcweave — отличный инструмент для создания интерактивных историй. Можно быстро набросать ключевые точки сюжета, а затем прописать отдельные сцены, не отрываясь от общей картины.

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

Структура превыше всего

Первая схема отражала сюжет в общих чертах. Методом тыка я решил, что история будет состоять из пяти-шести основных шагов и назвал их MQ1, MQ2 и так далее (от Main Quest — Основной квест). Конечно, смысла почти не прибавилось, но так было уже лучше, чем пялиться в пустое окно платформы.

И снова почти произвольно я добавил кое-где сайд-квесты, назвав из SQ1, SQ2 и так далее. Понятия не имел, какими они будут, просто хотелось получить общее видение по размерам проекта и его структуры..

На этом этапе было решено, что некоторые дополнительные истории будут взаимосвязаны. Например, SQ5 откроется, только если пройти SQ2. Хотя в итоге от этой идеи пришлось отказаться.

Первые наметки сюжета выглядели вот так. Это не функциональная блок-схема, в ней нет двусторонних взаимосвязей, то есть нельзя вернуться к основному сюжету из сайд-квеста. Да и контента тут еще тоже нет. Но такая визуализация вдохновляет куда больше, чем пустое рабочее пространство.

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

Написание квестов

Я решил, что сделать город стартовой локацией — хорошая идея. Только прошел Sorcery! 2 с ее незабываемым Кхэрэ, да и в Moonrunner действие происходит в городе. Оба тайтла отличились хорошо прописанными вдохновляющими сюжетами.

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

Блок-схема квеста с карманником

Arcweave позволяет разбивать сюжет на несколько схем — так называемые «борды». Для каждой сцены или сайд-квеста можно создать свою борду, не загромождая основную блок-схему.

Первым дополнительным квестом стал сюжет с карманником. Закончив его, я понял, что мне нужен план. Пришлось отвлечься от схемы, открыть текстовый файл и заполнить кое-какие пробелы:

РЫНОК ГОРОДА ЛАМ’ИА (MQ1)

Добраться до Хаотичной нейтральной таверны.

* помочь торговцу донести пшеницу. НАГРАДА: сила + голда.

* карманник украл ваш кошелек. Преследовать?

ХАОТИЧНАЯ НЕЙТРАЛЬНАЯ ТАВЕРНА (MQ2)

Поговорить с человеком по имени Тень.

* победить местного чемпиона по выпивке. НАГРАДА: деньги.

* тихонько выпить свой эль, ничего не делая.

Пользователь должен понимать свою цель в каждой сцене. Причем, все сюжеты должны вести к достижению общей цели по поиску и поимке преступника.

Чтобы не отходить от заданного вектора, решил заполнять эту скучную таблицу (см. выше). Получился отчет в строгом формате: ЛОКАЦИЯ, ОСНОВНАЯ ЦЕЛЬ, ДОПОЛНИТЕЛЬНЫЕ ЦЕЛИ. Он помог придерживаться строгих правил, которые я установил:

Ввести одну цель для одной ступени основного квеста, которая продвигает игрока по сюжету.

Разбить основной сюжет на несколько локаций.

Прикрутить сайд-квесты к основной сюжетной линии.

Заполнив отчет, я вернулся к блок-схемам и перешел к самому интересному — начал прописывать сцены игры.

Разбиение на борды

Очень круто, что Arcweave позволяет разбить историю. Слева формируется список, через который можно попасть на любую борду. Получается классическая структура папок.

Размещая каждый сайд-квест на собственной борде, проще переключаться между ними в процессе написания игры. А значит, можно создать в истории сколько угодно глав, при этом их удобно читать и редактировать. Когда дополнительный квест обрастает различными элементами, я перемещаю его на отдельную борду. Джамперы позволяют переходить к сайду из основной сюжетной линии.

Чтобы история переходила от одной борды к другой, расставляйте джамперы. На скриншоте два разных джампера ведут к сцене «Разговор с друидом».

Заключительные штрихи

Финальный экран

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

Складывая значения всех integer по модулю, получаем количество квестов, которые открыл игрок: quest_sum = abs(quest_1) + abs(quest_2) + …

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

Проверяя переменную каждого квеста, игра выводит надпись «УСПЕХ» или «ПОРАЖЕНИЕ».

Вот так это выглядит для пользователя:

Пожалуй, на основании этих результатов можно присваивать пользователю характеристики типа «поверхостный игрок» или «перфекционист». «Выслеживая преступника вы взялись всего за два дополнительных квеста. Вас можно назвать поверхностным, не так ли?» 🙂

Визуал

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

Изображение от upklyak (найдено на Freepik)

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

Итоги

Процесс написания

Написание игры длилось около недели, при этом проект занял лишь часть рабочего времени. Было здорово, хотя он нужен только, чтобы немного развлечь читателей. Я протестировал инструменты и процесс создания таких игр. Конечно, все истории разные, но когда так долго смотришь на пустой экран, что глазам требуется отдых, понимаешь, что немного методологии не помешает.

Что касается инструментов: старые-добрые карандаш и бумага все еще хороши для черновой работы, шлифовка и тестирование шли в Arcweave.

Тайминг

Стоит признать, что для учебного тайтла игровой процесс длится дольше, чем планировалось. Если браться за все сайд-квесты, потратишь далеко не пять минут. Я немного подредактировал сюжет, но не урезал его слишком сильно.

Не хотелось убирать дополнительные квесты. Ведь вся фишка такой игры — предложить варианты развития событий, которые пользователь может принять или отклонить.

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

Вы на пути в таверну, кто-то украл ваш кошелек. Преследовать (кликнуть сюда) или проигнорировать (кликнуть сюда)?

Вы проигнорировали происшествие и пришли в таверну. Тут драка. Примите в ней участие (кликнуть сюда) или проигнорируете (кликнуть сюда)?

Вы втянулись в драку, но недостаточно сильны, и вас вытолкнули. Идет соревнование, кто больше выпьет. Примите в нем участие (кликнуть сюда) или проигнорируете (кликнуть сюда)?

Уныло, не правда ли? В оригинале все совсем не так, но не стоит верить мне на слово. Переходите по ссылке и поиграйте сами, буду рад фидбеку.

Источник