напишите игру текстовый квест игрок находится в квартире его задача покинуть ее
Квест
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Текстовый квест на питоне
Напишите небольшой текстовый квест. Пользователю сообщается, что его персонаж находится в комнате.
Текстовый квест
Общая архитектура текстового квеста Не понимаю как её реализовать, нужна система вывода текста на.
Текстовый квест
Подскажите, кто может помочь в написании текстового квест на с++?; В универе задали создать.
Квест от Радмина
Компании «Фаматек» в честь Дня Системного Администратора приглашает принять участие в Квесте.
paimo, нет, то есть да. В питоне отступы нужны и важны. Я скопировал твой код, чтобы запустить у себя, но второй литр пива сказал,- ну нах отступы выставлять- там думать надо. Так что давай код с отступами, пока пиво не кончилось. 
Добавлено через 2 минуты
& перед ответом, нажми на ник кому отвечаешь, чтобы тот кому отвечаешь знал, что ты ему ответила
Добавлено через 6 минут
Если ты мне не поможешь то я не смогу пройти квест!
выведет 4 или ошибку
Добавлено через 3 минуты
Получил код с отсупами, работаю.
Добавлено через 1 минуту
не получил. не работаю..
Вложения
 | квест.docx (14.6 Кб, 2 просмотров) |
Решение
paimo, метод strip() удаляет начальные и конечные пробелы. Это обычная “очистка” данных, которые пользователь ввел, чтобы из-за лишнего пробела случайного у нас программа не сломалась)
Вложения
| квест2.docx (17.6 Кб, 12 просмотров) |
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Текстовый квест
Привет всем. Нужно переделать текстовый квест с алгоритмического языка на php. С чего начать? Как.
Тестовый квест
Если не сложно, киньте пример текстового квеста на php. Или просто код, в котором с клавиатуры.
Текстовый квест
Хочу написать текстовый квест на подобии тех, что бы ли в Космических рейнджерах, но проще, без.
Текстовый квест
Доброго времени суток господа. Возникла не большая заминка, задали написать текстовую игру на.
ТРУДНЫЙ КВЕСТ
Составили задачу, вопросы в личку или в контактные данные
Текстовый квест
Вечер добрый. Такое дело: я совсем новичок, захотелось написать простенький текстовый КВЕСТ (пока.
Пишем текстовую игру на 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 и ещё более сложный — на чистом питоне.
Я пишу текстовую игру на Python: первый прототип
В новом выпуске блога о программировании я довожу игру LAM-40 (мы начали писать её в позапрошлом выпуске) до элементарного прототипа, который уже можно испытывать.
Предыдущий выпуск
В прошлый раз мы разобрались, как подготовить компьютер к работе с Python, и теперь можем перейти к написанию игры. В создании любой игры чуть ли не самое важное — это как можно скорее начать её прототипировать, чтобы сразу выявить основные уязвимости и устранить их. У нас, конечно, игра довольно простая, да и главное для нас не её качество, а упражнения с кодом. Тем не менее раннее прототипирование — это полезная привычка в разработке чего угодно, поэтому давайте ей следовать.
Для тех, кто успел подзабыть за две недели суть того, что мы делаем, напомню. LAM-40 — это текстовая игра, где вы играете за человека, которому нужно успеть за девять часов получить справку на 40-м этаже загадочного государственного учреждения, переполненного бюрократами. Каждый этаж учреждения генерируется случайным образом: игроку попадаются бюрократы разного уровня, к каждому из которых нужно искать особый подход, чтобы пройти дальше и добраться до последнего этажа.
Примечание: весь код приводится для Python версии 3.0 и старше, а потому может не работать на более старых версиях.
Для начала давайте вспомним, какой код остался у нас с прошлого раза, и разберёмся, чем мы его хотим дополнить.
У нас есть простенький класс бюрократа, умеющего здороваться с игроком и обладающего двумя характеристиками — рангом и настроением. Задача на сегодня — создать простейший, бесконечно повторяющийся цикл «сражений» с бюрократами, что, по сути, и есть основная механика нашей игры. Получившийся у меня в итоге прототип занял 95 строк — начнём его разбирать по порядку (последняя пустая строка должна быть по стандартам PEP 8, но embed’ы её обрубают).
Строка 2: помимо random, в начале программы мы импортируем модуль sys. Из него нам понадобится функция exit() — возможность выйти из игры, пока что не указанная эксплицитно.
Строки 5–13, 16: я добавил списки положительных и отрицательных реакций бюрократов. Обратите внимание, как используются переносы. Дело в том, что, согласно PEP 8, максимальная длина строки должна быть 79 символов, иначе код будет слишком сложно читать. Именно поэтому для удобства каждое новое высказывание находится на новой строке и написано с тем же отступом, что и предыдущее. Ещё я добавил переменную ACTIONS типа данных string с основными действиями игрока (обычным вопросом, подкупом, мольбой, давлением и угрозой), чтобы не делать слишком длинной строку, где мы будем выводить все эти действия.
Строки 25, 34–44: у класса Bureaucrat появилась характеристика negative логического типа данных (то есть истина или ложь) со значением False. Она показывает, был ли ход игрока удачным — если нет, то её значение становится True, и игра предлагает нам совершить новое действие на том же самом бюрократе, а не создаёт нового бюрократа. Для того чтобы отобразить реакцию бюрократа на действие игрока, используются функции с говорящими названиями react_positively() и react_negatively(), которые меняют значение переменной negative и выводят случайную реакцию бюрократа на случившееся.
Строки 46–85: функция act() выводит на экран все возможные действия игрока и предлагает ему выбрать одно из них, введя первую букву слова. Именно для того, чтобы не загружать эту строку, мы вывели string со всеми действиями в отдельную переменную ACTIONS. Следом за этим идёт ветвление, и мы впервые в этом блоге используем ключевое слово elif — сокращение от else if. Оно задаёт условие помимо того, что указано в if, а блок с ним — следующие за выполнением этих условий действия. В нашем случае мы проверяем, что ввёл игрок. Если он ввёл строчную букву Q, выполнение программы завершится из-за упомянутой ранее функции sys.exit(). Если игрок введёт строчную букву W (wait), то ему выпадет новый бюрократ — это тоже пока что незадокументированная возможность. Если же игрок введёт какой-нибудь другой символ, то программа перейдёт в функцию react(), где ветвление выходит на новый уровень. На текущем этапе я сделал так, что для определённых сочетаний ранга и настроения бюрократа срабатывает лишь одно действие. Более того, есть непобедимые сочетания (например, высокий ранг и плохое настроение), в случае с которыми приходится вводить W, чтобы выпал следующий бюрократ.
Самая большая головная боль на первых порах — это использование ключевого слова self, когда вы ссылаетесь на функцию или характеристику класса внутри этого класса, и оператора сравнения == вместо оператора присваивания = рядом с условными операторами. Вероятно, и о том, и о другом вы будете забывать, так что следите за этим. Кстати, обратите внимание на ключевое слово and, которое используется рядом с операторами ветвления — оно обозначает, что должны выполняться оба условия, находящиеся рядом с ним.
Строки 87–94: наконец, в самом низу заканчивается описание класса и начинается логика основной программы. Мы создаём образец класса Bureaucrat, присваиваем его переменной bureaucrat и используем функцию с приветствием бюрократа. После этого запускаем бесконечный цикл, внутри которого запускаем функцию с выводом и вводом действий игрока, а также условное исполнение создания и приветствия нового бюрократа — в зависимости от того, каково текущее значение bureaucrat.negative. Обратите внимание на две вещи: оператор else при желании можно не использовать, а в случае с логическими типами данных в Python вместо оператора == применяют ключевое слово is.
Первый прототип LAM-40 готов. Конечно, он ещё далёк не то что от финальной, а даже от альфа-версии, поэтому нам предстоит порядочно поработать. Сейчас я вижу кучу проблем с этим прототипом, которые собираюсь устранить в следующий раз:
Нужно полностью изменить структуру кода: текстовые данные из верхней части перенести в отдельную базу, функции раскидать по другим классам, основную логику программы направить в отдельный файл и так далее.
Не обойтись без элемента неожиданности в «сражениях» с бюрократами — иначе игра быстро наскучит. Вероятно, это также поможет избежать дикого ветвления, которое есть сейчас в нижней части кода.
Игре требуется больше разнообразия во фразах, характеристиках, действиях и прочем, а также в том, как всё это выводится, чтобы внести разнообразие в повествовательную часть.
Желательно описывать текстом все действия, что возможны в игре, в том числе выход из неё и ожидание.
Из возможных действий желательно сделать список, а не отдельный string, чтобы туда можно было при определённых условиях добавлять новые действия. Кроме того, на ввод нужно применить функцию upper(), чтобы не требовалось каждый раз вводить строчные буквы. Также надо сделать адекватную реакцию на неверно введённые символы.
В основной логике игры есть повторяющиеся две строчки, нарушающие правило DRY. Да и сам цикл не очень красив — пожалуй, стоит над ним подумать, когда он начнёт расширяться.
Куча мелочей вроде описания функции act(), комментариев к некоторым частям кода, использования sys.exit() и характеристики negative, которая тоже не очень изящное решение. Так что поищу ему альтернативу.
Как видите, работы предстоит полно. Надеюсь, к следующему разу игра примет уже более целостный вид. Если вам что-то непонятно, пишите комментарии под материалом и в социальных сетях — буду рад и любым другим отзывам. Если вы более опытный в программировании человек, чем я, то с удовольствием выслушаю содержательную критику. Спасибо, и до следующего раза!
Полные курсы Python на Codeacademy и Treehouse*
* — платные курсы, но есть пробный период
Развитие программистского мышления на Udacity
Как написать хороший текстовый квест: 13 советов
Внимание! Эта статья является переводом. Текст оригинальной статьи.
Речь в статье пойдет о жанре, про который в России и СНГ мало кто слышал. Игровая индустрия пришла к нам довольно поздно. Текстовые квесты на тот момент уже почти потеряли популярность. В последние годы этот жанр снова стал интересен аудитории, и начинающим инди-разработчикам эта статья будет полезна.
Мало кто из «олдов» вспомнит времена, когда видеоигры только-только зарождались. 2D графика была непозволительной роскошью. Тогда многие проходили квесты про подземелья и фантастические миры… в текстовом формате.
Чтобы управлять персонажем или осматривать предметы, приходилось печатать команду в текстовом облаке. Когда игрок, исследуя локации, забредал в логово чудовища, именно текст позволял игроку представить, насколько грозно выглядел монстр.
Одни из самых известных текстовых квестов это Zork и Trinity.
Со временем текстовые квесты стали использовать простейшую графику, чтобы лучше изображать место действия и сеттинг. Но игры этого жанра скоро оказались в меньшинстве на фоне быстрого подъема 2D платформеров и point-and-click квестов. И всё же сообщество интерактивного повествования выжило, развивалось и росло, пусть и за кулисами мейнстримной игровой сцены.
В последнее время некоторые разработчики стали возвращаться к истокам игровой индустрии в поисках вдохновения и идей (автор статьи не исключение), создавать современные, относительно успешные текстовые квесты. Например, Cleansuit и The House Abandon. Причина успеха была не только в хорошем гейм-дизайне: разработчики поняли, как осовременить жанр и при этом сохранить его аутентичность. Именно по этой причине я буду много ссылаться на упомянутые выше игры, как на примеры.
Итак, как же самому создать текстовую игру для современной аудитории? Об этом и поговорим. Ниже я постараюсь дать советы на основе своего опыта разработки текстовых квестов. Давайте начнем!
Самый лёгкий способ привыкнуть к структуре текстовой игры: поиграть хотя бы в одну.
Если вы делаете игру для современной аудитории, а не кучки олдов, то лучше обратить внимание на современные текстовые квесты. Если же ваша целевая аудитория — хардкорщики, которые когда-то уже играли в подобное, лучше всего изучить структуру классических текстовых квестов.
Если вы совсем не знакомы с текстовыми играми или сторителлингом, то стоит сперва прощупать почву, а потом уже окунуться в интерактивное повествование.
Структура разработки текстовых игр целиком и полностью отличается от привычных современному разработчику жанров. Чтобы облегчить себе жизнь, можно использовать движок Twine: в нем даже новичку будет удобно создавать интерактивное приключение, тестировать идеи или собирать скелет истории.
Начните с коротких, линейных историй, в которых игрок может только двигаться из комнаты в комнату. Потом постепенно усложняйте игру элементами: добавляйте предметы и места, где их можно использовать.
Эти простые шаги помогут вам разобраться в логике и почувствовать темп разработки. Тогда вы поймете, действительно ли вам хочется создавать текстовые квесты. Если да, тогда можно поделиться тестовыми работами с людьми, чтобы получить обратную связь и набивать шишки дальше.
Будет ли игра линейной? А концовка одна? Может, несколько? Сколько локаций доступно игроку для исследования? Будут ли враги? Или несколько персонажей? Если так, то как все это изменит геймплей истории?
Начните размышлять об этих вещах с самого начала разработки, чтобы не потеряться в процессе. Тогда вы сможете сразу понять, какие механики понадобятся, чтобы игра работала как надо.
Нужно помнить, что без визуала игроку намного сложнее погрузиться в ситуацию и атмосферу игры. Потому вы должны описать комнату или местность настолько точно, насколько это вообще возможно. Какие объекты находятся в комнате?
Четко и ясно расскажите игроку, как объекты выглядят, где они расположены. Простым языком.
У комнаты одна дверь? Две? Укажите направления, в которых игрок может и не может двигаться. Как называется это место? Лучше всего разместить название над описанием комнаты или местности, чтобы игрок понимал, где он вообще оказался.
Классические текстовые квесты, Zork и Trinity, ориентировали игрока по сторонам света. Например:
«Дверь на севере и ещё одна на востоке»
Это дает возможность напечатать «идти на север» и пройти через одну из двух дверей, если она открыта.
Если ваш квест происходит внутри дома, можно написать, например, так:
«В коридоре вы видите дверь, ведущую в спальню, и ещё одну — в ванную»
Тогда, по аналогии, игрок может напечатать «идти в спальню», чтобы продвинуться дальше.
Оба подхода хороши. Если вы не знаете, какой выбрать, подумайте об этом с точки зрения сторителлинга. Персонаж находится в месте, где никогда не был? Тогда интереснее использовать стороны света: этот прием создает ощущение неизвестности и заставит игрока гадать, что же за дверью. Точно так же, как гадает персонаж. А если протагонист в известной ему локации? Естественно, он в курсе, что за дверью, и тогда логичнее использовать второй способ.
Но есть третий способ: дать игроку карту.
Он был использован в моей игре. Игрок мог напечатать команду, чтобы посмотреть на карту, сверить названия комнат и сориентироваться в пространстве. Белая точка обозначала, где персонаж находится сейчас.
Использовать в игре прямое управление вроде кнопок «x», «space» и «wasd» довольно просто: достаточно нажать и действие совершено.
Но в текстовых квестах нужно ввести словосочетание, чтобы что-либо сделать. Это может стать головной болью разработчика. Вам придется практически предсказывать, что игрок захочет напечатать.
Фокус в том, чтобы внести в код максимум возможных словосочетаний для совершения действия.
Например, если игроку нужно исследовать стол, он может напечатать «осмотреть стол», или «посмотреть на стол» ( прим. переводчика: examine и look соответственно, в английском даже не однокоренные ). Если вы сталкиваетесь с таким кейсом, то для программирования игры нужно остановиться и подумать, сколько способов описать осмотр стола существует в языке.
Сомневаетесь? Старайтесь изъясняться максимально просто, как это сделал бы игрок. Иногда можно упростить сами фразы. В Trinity приходилось печатать «посмотреть в окно», тогда как в Cleansuit структура команд была упрощена до «смотреть окно», а результат был один и тот же.
В случае с командами, которые игрок будет использовать постоянно, например «осмотреться», или «перейти дальше», хорошая идея использовать аббревиатуры. Вторая команда может быть напечатана как «ПД» ( прим. переводчика: для русского языка совет работает не всегда ). В Zork можно было просто напечатать «N», чтобы пойти на север ( от англ. North ). Если помнить это во время программирования команд, можно сделать игру более динамичной и приятной. И менее раздражающей:
Игроку не придется часами подбирать слово, чтобы пройти дальше.
Олдскульные текстовые квесты обзаводились текстовыми руководствами по прохождению игры, чтобы обучить игрока базовым вещам: как установить игру, что происходит в игре, какие команды использовать, чтобы двигаться, как использовать предметы и т.д. Сейчас мануалы — зверь вымерший, и редко кто вообще знаком с таким типом механик. А значит.
Нужно включить в игру обучение базовым вещам.
Например, кнопка в меню или команда, которую игрок может напечатать в любой момент и вспомнить остальное управление. Поверьте, игрокам это понадобится.
В любом случае, вы не обязаны составлять огромный список из всех возможных команд в игре. Скажите о самых базовых вещах вроде перемещения и использования предметов, а потом.
Дайте игроку стимул пробовать другие, не указанные вами команды.
Текстовые игры должны компенсировать отсутствие визуала. Когда в игре происходит что-то важное, текст должен быть художественным и интересным, чтобы подстегнуть воображение игрока и удержать его внимание.
Держите в голове, что текстовые квесты медленные по своей природе. Это важно учитывать при создании саундтрека и звукового дизайна игры. Очень вероятно, что игрок, особенно если он не привык к текстовым играм, проведет кучу времени в локации, исследуя ее и пытаясь понять, что вообще делать. А теперь представьте, каково ему будет это делать под постоянно повторяющуюся фоновую музыку. У вас игрок с ума сойдет!
По этой причине даже современные Cleansuit и The House Abandon практически полностью беззвучны, они используют звуковые эффекты только чтобы обозначить использование предмета, открывшуюся дверь или шаги врага.
Музыка играет, когда что-то происходит, например, в бою или сцене преследования.
В The House Abandon фоновая музыка присутствует, но она едва заметна и играет тихо, не отвлекая игрока от квеста. Кроме того, этот квест очень короткий, так как входит в коллекцию текстовых игр Stories Untold: в любом случае долго музыку не послушаешь.
Делать сложные головоломки в текстовой игре — ужасная идея. Головоломки нужно разработать так, чтобы легко объяснить словами. Но даже если текст простой, не факт, что игрок поймет, что имеется в виду. Только когда головоломка показана визуально, это условие не такое жесткое. И все же.
Помните, что игрок, при всем желании, не сможет залезть к вам в голову.
Текстовые квесты — жанр довольно нишевый, и только креативный концепт привлечет игроков к вашему творению.
Когда пишете свой текстовый квест, не бойтесь дать игре уникальный «голос».
Cleansuit выстрелил из-за подачи: маньяк пытается вломиться в ваш дом, а вам нужно собирать предметы и делать ловушки. Разобраться с убийцей можно разными способами, и так прийти к разным концовкам. Хотя игра считается хоррором, написана она с юмором и пренебрежением к персонажам: так у игры создается особенное послевкусие.
The House Abandon, напротив, использует более традиционную технику повествования и имеет только одну концовку. Это не мешает создать напряженную атмосферу. Концовка довольно неожиданная и оставляет игрока гадать, что произошло на самом деле.
Каждый раз, когда вы что-то воплощаете в своей игре, то сразу тестируйте. Даже если это одна текстовая команда. Представьте, что вы игрок, и протестируйте команду, посмотрите на нее с разных углов. А когда вводите новую механику, которая хотя бы отдаленно может повлиять на поведение первой, тестируйте ещё раз.
Так вы исключите вероятность опечаток и логических ошибок, которые легко просачиваются в код игры.
Как тогда быть с головоломками? Тестировать в два раза больше.
Даже после всех тестов, которые вы проделаете, ошибки останутся. Вы их не заметите, а они — да.
Это основы геймдизайна: найдите команду бета-тестеров перед релизом.
Они могут быть вашими друзьями, вы можете им заплатить, но они вам нужны. Бета-тестеры заметят не только ошибку, например, текстовую команду, которая не работает. Они посмотрят на вашу игру с другой стороны, на ее темп и стиль текста. А ещё расскажут, насколько сложный или лёгкий у вас квест, есть ли несоответствия в сюжете, затянутая или короткая получилась игра, скучная или захватывающая и т.д.
А может, они предложат вам добавить функции, о которых вы до этого не задумывались, но захотите добавить в игру.
Как уже было неоднократно сказано, интерактивное повествование — не самый популярный жанр. Потому большинство игр либо бесплатны, либо стоят меньше
300 рублей ( прим. переводчика: 5$ ).
Когда ставите ценник, подумайте о том, сколько часов уходит на прохождение, о цене производства и реиграбельности. Вспомните, что ваша игра — всего лишь одна из миллиона опций. Так что не стоит отпугивать потенциального игрока завышенной ценой на нишевую игру.