Материал: Реализация компьютерной игры жанра квест

Переносимость: технология доступна очень широко. Вот список (не самый свежий) платформ, где компилятор Inform доступен: Acorn RISC OS, BeOS, Macintosh, Atari ST (версия 5.4), Amiga, MS-DOS (также версия для GO32), Linux, OS/2, UNIX, VMS (DEC VAX или Alpha) и EPOC (Psion 5/Revo/7), Windows. Z-интерпретаторы доступны еще шире. Glulx-интерпретаторы пока распространены меньше, но для Windows, Linux (консольный и X) и MacOS X имеются.

Основные возможности. Inform - полнофункциональный объектно-ориентированный язык программирования, во многом похожий на C и SmallTalk. Есть возможность создавать ИЛ-игры, дополняющие стандартный парсер мощным Legend-подобным многооконным интерфейсом. Более того, уже появились библиотечные пакеты, помогающие это делать (например, GWindows).

.1.4 Hydra- базовая система для написания парсерных IF игр на языке программирования Python. Разработка: (c) Copyright 2001-2002 WildWizard, позже присоединился Стас "Unreal" Старков. Система была доведена до рабочего состояния и позволяет создавать полноценную ИЛ. Доступность - freeware.

Система программирования похожа на Inform и довольно проста и гибка. Известно, что интерпретатор языка Python распространен, например на смартфонах с операционной системой Symbian, и вообще является кросс-платформенным. Однако, тестирование Гидры на данных платформах пока не производилось.

2.1.5 TADS (Text Adventure Development System)

Безусловно, вторая по популярности (после Inform) ИЛ-платформа в мире и первая (среди парсерных платформ) в России. Последняя версия: 2.5.X (TADS 2), 3.0.X (TADS 3).

Разработка и поддержка: TADS - профессиональная система для разработки ИЛ - создана Майклом Робертсом (Michael Roberts) в конце 1980-х годов. Он ее продолжает развивать и поддерживать до настоящего времени (при участии и поддержке множества энтузиастов). Доступность: когда-то система разрабатывалась как shareware-продукт; теперь распространяется свободно вместе с исходными текстами.

Принципы технологии: компилируемый язык программирования. TADS-компилятор обрабатывает исходные файлы (обычно имеющие расширение ’.T’), и генерирует переносимый двоичный файл игры (расширение .GAM), для выполнения которого необходим TADS-интерпретатор.

Переносимость широкая. Система TADS доступна на: Acorn RISC OS (только интерпретатор), AmigaDOS, Atari ST/TT/Falcon, DECStation, Linux, Macintosh, MS-DOS (есть также версия для GO32), NeXT, OS/2, SGI Iris/Indigo, SunOS & Sun 3, все версии Windows. Интерпретаторы TADS предъявляют несколько большие системные требования, чем Z-интерпретаторы, поэтому на очень маломощных системах (старые ПК, наладонники) могут не работать.

Основные возможности. TADS - объектно-ориентированный язык программирования, напоминающий гибрид между C и Паскалем. Относительно новое расширение технологии - HTML-TADS - позволяет лучше управлять выводимым текстом, путем включения в него тегов разметки (подмножество HTML). За счет этого можно управлять шрифтами, размерами, цветом и прочими стилевыми атрибутами текста; можно включать в текст гиперссылки и графику (JPEG, PNG, MNG - анимированный PNG), воспроизводить многие популярные аудиоформаты (MIDI, WAV, MP3, OGG). Программы, ориентированные на HTML-TADS, работают и в более старых TADS-интерпретаторах (хотя, конечно, без перечисленных "излишеств"). Сейчас HTML-TADS интерпретаторы доступны для Windows и MacOS X.

.1.6 URQ (Universal RipSoft Quest)

Простая платформа отечественного происхождения для разработки "консольной" ИЛ (управляемой с помощью меню и кнопок).

Интерпретаторы:

-    URQ 1.4 от RipOs. (Есть версия 2.0 alpha, очень неустойчивая - не применяется) разработка прекращена;

-        Urq_dos 1.35 от 30.11.2004 консольная, работает в ДОС-окне, самая устойчивая в работе, фактический стандарт языка. Разработчик URQ_DOS (с 2000 г. по сей день) - Виктор Корянов;

         AkURQ 1.28 от Акела. На настоящий момент самая продвинутая версия интерпретатора, поддерживает некоторые функции, отсутствующие в "досурке" (математические, строковые, работу с окнами, настройка шрифтов пользователем и т.п.), имеет развитые мультимедийные возможности. Уникальная особенность по сравнению с предыдущими интерпретаторами URQL - поддержка html-кода (через обращение к браузеру).

Разработка и поддержка: можно обращаться на форум #"784961.files/image009.gif">

Рисунок 2.1 - Диаграмма Use Case

Также имеется диаграмма развертывания (рис. 2.2), показывающая, что развертывание предельно просто: на компьютере пользователя должен иметься интерпретатор Quest Soft Player, также туда копируется файл с игрой и по мере необходимости рисунки.

Рисунок 2.2 - Диаграмма развертывания

Первая диаграмма активности (рис. 2.3) показывает то, как будет выглядеть структура типичного задания - структурного элемента квеста. Как было указано в постановке задачи, любое задание должна быть возможность выполнить как минимум тремя путями: путь, где может ошибиться пользователь, путь, где можно проиграть случайным образом, и путь, который доступен всегда.

Рисунок 2.3 - Диаграмма активности общего случая

Примером могут служить первый (рис. 2.4) и второй (рис. 2.5) квесты. В первом главной героине необходимо попасть в избушку, и есть три пути достижения цели: уговорить хозяйку открыть дверь через окно, выбрав все правильные ответы в диалоге, найти ключ под окном и открыть дверь самой, и, пробравшись и крыше, залезть в трубу.

Рисунок 2.4 - Диаграмма активности первого квеста

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

Рисунок 2.5 - Диаграмма активности второго квеста

Общая схема сюжета игры представлена на рисунке 2.6. Сюжет состоит из нелинейной последовательности связанных квестов, от выполнения которых зависят доступные варианты концовки. Только три квеста являются обязательными; для доступности хотя бы одной концовки необходим еще один из необязательных. Максимальное количество концовок при всех выполненных квестах - четыре.

Рисунок 2.6 - Диаграмма активности сюжета игры

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

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

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

Рисунок 2.7 - Локационная структура игры

Сам процесс игры и прохождения квестов реализован тремя разными механиками, которые можно рассмотреть на примере первого квеста - попасть в избушку (рисунок 2.4).

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

Рисунок 2.8 - Диалог первого квеста

Вторая механика (рисунок 2.9) - рискового действия. Здесь дерево вариантов всегда простое и не зависит от игрока. Возможных исходов также всегда два - выигрыш или проигрыш.

Рисунок 2.9 - Рисковое действие

Третья механика - традиционный для квестов сбор предметов. Здесь, как правило, нет разветвлений, и вариант окончания всего один - успех - но необходимо перемещение между локациями и внимательное отслеживание вариантов действий. Если рисковое действие и диалог, как правило, интуитивны, то что нужно делать для прохождения сбором предметов может быть нужно поискать. На рисунке 2.10 изображена подробная последовательность действия для сбора предметов в первом квесте.

Рисунок 2.10 - Сбор предметов первого квеста

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

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

3. Разработка

.1 Ознакомление с платформой разработки и реализация игры

В процессе создания первого пробного квеста происходило ознакомление с интерфейсом набора необходимых программ для разработки под платформу QSP - файла помощи .chm, проигрывателя-интерпретатора файлов, инструмента преобразования текстовых файлов кода в интерпретируемые и интерактивной среды разработки.

Рисунок 3.1 - Интерактивная среда разработки

Были написаны первые локации и реализована последовательность событий первого квеста вместе с тремя базовыми механиками взаимодействия с игрой - диалог, рисковое действие и головоломка.

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

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

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

#Лес0

$FNAME = 'Arial'= 1

Открыто = 0

Ключ_взят = 0

Упала = 0

Разговор = 0

Тропинка_видна = 0

Можно_в_город = 0

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

'<center><img src="img/Wood.jpg" width="100%"/></center>'

' '

'В густых кронах деревьев шелестит листва, откуда-то издалека доносится перекличка птиц. В кустах время от времени слышится шорох какого-то пробегающего мелкого зверька.'

'Теплый июньский день подходит к концу. Тени удлиняются, и между деревьев вьется прохладный ветерок. Луна устала.'

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

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

Важный элемент - оператор DELACT, удаляющий действия меню с экрана. В этой игре он используется для действий, которые можно выполнить только один раз подряд - к примеру, взять уникальный предмет или подойти или заглянуть куда-то.

'<table width="100%"><tr><td bgcolor="#eeeefF">Обойти избушку слева</td></tr></table>': GOTO 'Юг_избушки''<table width="100%"><tr><td bgcolor="#eeeefF">Обойти избушку справа</td></tr></table>': GOTO 'Север_избушки''Заглянуть в окно':

'Изнутри окно занавешено красивой кружевной занавеской.''Заглянуть в окно'Ключ_взят = 0:

'На подоконнике лежит небольшой блестящий ключик.'

'<img src="img/key.png" />'

ACT 'Взять ключик':

'Ключик поблескивает на окне. Луна предполагает, что его здесь просто забыли, подбирает и прячет в сумку.''Небольшой блестящий ключик','img/key_small.png'

Ключ_взят = 1'Взять ключик'

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

Это достигается путем запоминания места разговора в соответствующей переменной и множественного выбора при инициации разговора.

'Постучать в окно':Разговор > -1:

'Занавеска отодвигается. В окне появляется сморщенное, загорелое старушечье лицо с густыми бровями, крючковатым носом и бородавкой на остром подбородке.'Разговор = 0: GOSUB 'Разговор1'Разговор = 1: GOSUB 'Разговор2'Разговор = 2: GOSUB 'Разговор3'Разговор = 3: GOSUB 'РазговорОкончен': GOSUB 'РазговорНеВышел''Постучать в окно'

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