В моём исследовании IFComp, (я выбирал по 20-30 игр конкурсов каждого года) я выделил некоторые общие моменты, которые необходимы игрокам и судьям, и хотел бы поделиться ими здесь.

Я заметил некоторую «иерархию потребностей», которую обобщил в виде списка. Идея заключается в том, что вещи в начале списка настолько бросаются в глаза, что игроки не заботятся о дальнейших. Это, конечно, грубое переупрощение, но оно может оказаться полезным.

Итак, иерархия.

Вынул текст из старого черновика одной игры и сделал бота для Mastodon: https://botsin.space/@forestbot

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

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

15 мая 2017 года в рамках «Паровозика 3« вышла игра «Ученик мага» под авторством Алика Гаджимурадова (Alkor), являющаяся его дебютом. Это довольно компактная парсерная игра, однако имеющая один примечательный момент, а именно нетипичный способ прохождения, который пренебрегает традициями и жанровыми условностями большинства квестов, смещая фокус с комбинирования предметов на соблюдение моральных норм. Тем не менее, в общем и целом это вполне классическое текстовое приключение, специфичность которого станет понятна лишь к концу игры.

Ещё «Ученик мага», насколько я понимаю, первая полноценная игра, написанная с большим объёмом кодогенерации посредством «Конструктора» от Антона Ласточкина. Не стоит тешить себя надеждой, что при его помощи любой желающий сможет написать похожую игру без прямого программирования на языке TADS, но вот облегчить желающим процесс создания комнат и предметов в них данный инструмент вполне может. Это ещё не ЯРИЛ с его мышкокликальным процессом написания парсерной игры, но частичное движение в этом направлении, позволяющем облегчить процесс создания парсерных игр для неопытных или просто ленивых людей. Впрочем, давайте вернёмся к игре как таковой.

Зачитал тут интереснейший пост Oreolek’а. Где (наверняка не впервые в сообществе, но впервые на моей скромной памяти) поднимался вопрос об обратной связи с читателями. Осознавая, что я тут в общем-то никто, но питая при этом теплейшие чувства и к жанру interactive fiction и к людям, в нем творящим – осмелюсь заявить, что проблема гораздо шире.

Это перевод статьи Эмили Шорт от 12 мая 2009 года

В прошлом году Брент Эллисон опубликовал статью о системах построения диалогов на сайте Gamasutra. Чуть позже Джонатан Блоу открыл в своем блоге дискуссию о создании диалогов между персонажами в играх. Затем в феврале Кристиан Мажевски написал о диалогах в Emerald City Confidential, размышляя о трудностях представления казуальным игрокам диалогов со множеством решений.

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

В частности, большинство существующих анализов объединяют в одно пользовательский интерфейс (как представлены пункты диалога? как они появляются на экране? предлагается ли игроку полный текст его реплики или же ее обрезанная версия?) и лежащую в его основе модель (как игра решает, какие реплики будут доступны в следующий момент? как ограничить варианты для игрока или наоборот сделать их доступными? что влияет на то, когда и что NPC [неигровые персонажи] говорят сами по себе?)

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

Однако лежащая в основе модель значит очень много.

Интерпретатор INSTEAD (Simple Text Adventure, The Interpreter) позволяет играть в игры, которые по жанру являются смесью визуальной новеллы, текстового квеста и классических квестов 90-х. Такие игры условно можно назвать “текстографическими”.

Некоторое представление о жанре можно получить, если вы играли в квесты на ZX-Spectrum, игры с текстовым вводом или классические квесты от Lucas Arts. Жанр игр под INSTEAD включает в себя некоторые идеи из упомянутых игр, но делает их более доступными для современных игроков.

Кроме того, для INSTEAD существуют модули:

• проигрыватель квестов из КР
• проигрыватель квестов URQ
• модуль «метапарсер» (для разработки парсерных игр)

Особенности движка INSTEAD:

• высокая переносимость (Unix, Windows, Android, OS X …);
• простота разработки игр (используется Lua);
• гибкость;
• полностью открыт и абсолютно свободен;

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

Игры: http://instead-games.ru
Форум: http://instead.syscall.ru/talk