Всем привет!
В данном посте мне хотелось бы рассказать немного о разработке текстового приключения, которое постепенно переросло в создание платформы и редактора, а также сформулировать свои мысли о жанре в целом.
Об интерактивной литературе (IF)
Интерактивная литература (IF) стала одним из основополагающих столпов компьютерных игр. Еще в 1975-ом была создана Colossal Cave Adventure, благодаря которой жанр быстро захватил умы и сердца людей, которые в те времена имели доступ к ПК. Дальнейшее бурное развитие жанра я описывать подробно не буду: об этом и так много уже написано. Достаточно лишь сказать, что с развитием графических интерфейсов о полностью текстовых играх постепенно стали забывать, а в конце концов, уже к началу 90-ых, основные разработчики приключенческих игр и, в частности, point-n-click adventure (у нас известные как «квесты») перешли полностью на графический интерфейс (тот самый point-and-click). Интерактивная литература стала более нишевой, игры продолжали выходить, но даже тем, кто пристально следил и следит за развитием компьютерных игр о данном жанре известно мало. Исключением стала разве что Legend Entertainment. В целом, хотя и я за жанром следил мало, мне кажется, что наметились две ветки развития: максимальное упрощение, когда нужно просто выбрать дальнейшее развитие сюжета, как компьютерная вариация игр-книг choose your own adventure. Такие игры обычно называются «менюшные», как правило, в них нужно просто кликать на варианты или на подсвеченные слова, чтобы продвинуться по сюжету. Текстовый парсер в них вообще отсутствует за ненадобностью. Вторая ветка пошла по пути усложнения, при этом, наоборот, максимальное внимание было уделено развитию парсера, чтобы командная строка понимала как можно лучше введенные игроком фразы. Здесь стоит отметить системы TADS и Inform.
На мой взгляд, оба подхода очень интересны, но при этом, как мне кажется, на второй план отходит суть компьютерной игры: взаимодействие игрока с игровым миром. Ведь в игре наибольший интерес возникает, когда игрок может в принципе оказывать влияние на мир и персонажей, может проходить игру различными способами. Ролевые игры в этом плане продвинулись значительно дальше, но, к сожалению, небольшой период возрождения конца 90-ых, который подтолкнули гении из Black Isle Studios, быстро закончился, уступив место action-RPG и опять же скатился к упрощению с точки зрения глобальности игрового мира и нелинейности прохождения. Но даже в Fallout проработка скриптов оставляла желать лучшего… Одним из лучших примеров проработанности и отлаженности игрового мира и скриптов, на мой взгляд, до сих пор остается игра Maniac Mansion, на днях, кстати, усилиями нашего олдгеймерского Бюро переводов наконец-то переведенная на русский язык. Пройти игру можно различными способами, семейство Эдисонов всячески вмешивается в происходящее, многие события завязаны на таймер — в результате погружение в игру оказывается невероятным! Первая игра Lucas Arts, к сожалению, так и осталась во многом непревзойденной, так как развитие квестов пошло по пути упрощения для игрока (сначала уменьшилось число глаголов или команд, с помощью которых можно взаимодействовать с игровым миром, а потом и вообще упрощено до одного клика) и количественного увеличения контента (больше сцен, больше диалогов). Тут стоит отметить, что в MM вообще диалогов не было, персонажи разговаривали без вашего участия.
Выбираем концепцию
Заканчивая это несколько затянутое вступление, я хотел бы сказать, что мне захотелось вернуться в прошлое, ко временам Zork и Maniac Mansion, и сделать игру полностью на причинно-следственных связях, без какого-либо random'а, с упором на взаимодействие с игровым миром, а не на проработанность парсера или что-то еще. Основные тезисы:
0) никакого random'а;
1) игра должна быть понятна и проста для игрока и для создателя;
2) должен быть удобный современный редактор;
3) олдскульный интерфейс (только текст, в каноническом текстовом режиме 80 на 25);
4) разумеется, поддержка русского языка, в том числе — падежей (т.е. не «взять книга», а «взять книгу»).
Из существующих современных систем по разработке ИЛ наиболее близок ADRIFT, но он значительно более наворочен (там даже делают RPG!) и у него несколько неясна ситуация с поддержкой русского языка (насколько мне удалось выяснить, она есть только у старой третьей версии (вышла еще в 1997 году, перестала разрабатываться в 2001-ом).
Из первого пункта следует, что количество глаголов (команд) должно быть ограничено и изначально известно игроку. Все объекты, с которыми можно взаимодействовать, также должны быть известны, что достигается их выделением в описаниях предметов и сцен. Что касается простоты для создателя, то, в первую очередь, это означает, что ему не нужно знать программирования, и создание квеста должно быть «из кирпичиков», а не на собственном объектно-ориентированном языке.
Второй пункт означает, что человек должен создавать игру с помощью удобного GUI, а не в текстовом редакторе (заполняя циферки-действия по памяти).
Третий пункт определил движок, на котором написан TDZ. Им стал pdcurses, идейное развитие Curses, который берет свое начало еще с UNIX-систем. Одно время, у меня была мысль использовать расширение, которое позволяет не ограничивать себя в цветах, но оно только для Windows и быстро мне разонравилось.
Программируем движок
В программном плане хотелось изначально строго зафиксировать игровую схему, сделать ее как можно проще. Поэтому было решено сделать только три класса — «сцена», «объект», «действие». Сцена — это область применения команд, то есть пока вы находитесь на одной сцене, объекты из другой сцены для взаимодействия вас с ними недоступны. Единственное исключение — «глобальная сцена», которая позволяет вам взаимодействовать с объектами в любое время и в любом месте (например, если объекты у вас в инвентаре). Но, здесь важно заметить, что взаимодействие с объектами на текущей сцене может изменить объекты или действия на другой сцене (например, вы нажали на кнопку, а где-то внизу открылась дверь). Но самый интересный класс — это действие. Действие — это то, что вы можете совершить в игре с помощью команды (например, «взять яблоко»). Все причинно-следственные связи в игре можно описать «условиями», «результатами», а также «состояниями» самих действий. Условия — это какие действия должны быть совершены (или — не совершены) до того, как может быть совершено данное действие. Результаты — это изменение состояний других действий. Состояние — совершено или нет данное действие (могут быть и другие состояния, если есть необходимость, движок не ограничен только двумя). Ну и, конечно, должен быть ответ, который дает игра на совершение данного действия, а также изменение счета игры (как это было в старых Сиерровских квестах).
Кажется, что это просто и удобно, но на деле оказывается, что даже просто для того, чтобы достать из холодильника (который можно открывать и закрывать) всего два предмета и при этом отслеживать правильное описание холодильника («холодильник закрыт», «в холодильнике лежат оба предмета», «в холодильнике лежит только первый предмет», «в холодильнике лежит только второй предмет», «холодильник пустой») потребуется очень серьезно подумать:) Именно поэтому, как мне кажется, движки текстовых приключений пошли по пути объектно-ориентированного программирования, когда нужно создавать классы контейнеров и т.д., а движок уже сам будет знать, какое описание подставить в нужный момент. Этот подход мне не нравится тем, что в игре теряется индивидуальность: шаблонные описания читать гораздо менее интересно, чем написанные человеком.
Интерфейс
О вопросе удобства интерфейса я никогда не задумывался: мне интересна концепция и общие игровые идеи, — но после того, как я выложил первую версию игры в 2008 году, люди сразу начали говорить про интерфейс. Кому-то не хотелось вводить руками фразы полностью, так что я сократил необходимую для ввода длину объекта или глагола до 3 символом, кому-то не хотелось вообще ничего вводить, а только выбирать из списка. Тогда я ввел интерфейс «Casual», где глаголы можно выбирать с помощью стрелок на клавиатуре и пробела. Кому-то не понравились цвета, захотелось настроить их самим под себя. Разумеется, возможности эти должны быть дополнительными, поэтому их можно отключить или настроить с помощью редактирования файла настроек (tdz.cfg).
Поле для деятельности в этом смысле — просто огромное. Например, можно добавить возможность проигрывать музыку и многое другое. Надеюсь, я не заброшу проект и смогу всё это добавить и сделать кастомизируемым.
Программируем редактор
Сначала я делал саму игру (описание сцен, объектов, действий) просто в текстовом редакторе, но потом подумал, что гораздо полезнее было бы сделать удобный графический интерфейс. Благо, что по второй работе я занимаюсь разработкой на Python/Turbogears, о приложении которого ко всяким веселым вещам я уже писал здесь. Интерфейс позволяет просматривать и редактировать описания и параметры сцен, объектов, а главное — добавлять и изменять действия со всеми их многочисленными нюансами. Игровые ресурсы я всё же решил оставить в изначальном текстовом виде, а не в виде sqlite БД, так как, мне кажется, пользователям стоит давать возможность взглянуть во «внутренности» игры. Поэтому из редактора сделана возможность экспорта-импорта ресурсных файлов.
Результаты
На данный момент сделано две игры, одна посвящена игре Simon the Sorcerer, которую я очень люблю и когда-то даже перевел:
Вторая игра поменьше и называется Cosmic Madness:
В видео показано прохождение, так что, если вам хочется поиграть самостоятельно и не хочется портить впечатления, лучше их смотреть, когда где-то будет непонятно, что делать и т.д.
Ну и недавно я записал видео, объясняющее, как работать в редакторе (смотреть в HD, иначе всё размазано):
Страничка о TDZ на моем сайта — dimouse.ru/norka/computers/tdz.html
Редактор я пока не выкладываю, но если кто-то хочет посмотреть-попробовать — пишите, вышлю.
Буду рад конструктивным мнениям об этой разработке и советам по улучшению!
Автор: Dimouse
