Разработка Blue Lacuna: 12 уроков, выученных Аароном Ридом

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

Это могли быть вы, за такую несмешную шутку, или Эндрю Плоткин, чей Hunter, In Darkness можно винить за открытие для меня современной IF. Это мог быть даже Грэхем Нельсон, !tiring swim across the Atlantic or no!, за создание серии все более правополушарных языков, которые позволяют все более никудышным программистам (читай: мне) писать игры.

Так или иначе, человеком, которого нужно было тогда бить, скорее всего был я. Я сделал много ошибок, разрабатывая Blue Lacuna, ошибок, которые можно было избежать, если бы другие авторы больших IF выступили со своими советами и рекомендациями.

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

Однако, если вы уже отправились или еще только планируете купить билет на путешествие по длинной дороге разработки полноразмерной IF, вас могут заинтересовать некоторые вещи, которые я узнал за месяцы (читай: годы) создания Blue Lacuna. Вы заметите, что многие эти вещи можно применить к любому большому проекту, связанному с программированием, потому что, чем больше становится ваша игра, тем меньше это похоже на баловство с текстовыми квестами и больше похоже на серьезное программирование, в независимости от того, сколько очаровательных естественно-языковых конструкций Грэхем добавит в Inform 7. Кстати, вы также заметите, что некоторые из советов специфичны для этого языка, но, надеюсь, честолюбивый человек сможет сделать нужные выводы в независимости работает ли он на Inform 6 или TADS, или жаждет создать первый квест в миллион слов на SUDS.

№1 Разработайте стратегию сохранений.

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

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

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

За прошедшие два года появилось много хороших утилит для автоматического сохранения, так что лень больше не служит оправданием для отсутствия бэкапа. Маки с 2007 года снабжены Time Machine, которая каждый час сохраняет все ваши данные на внешний носитель; бесплатный сервис Mozy, доступный для Маков и PC, автоматически сохраняет до 2 Гб данных на защищенном сервере. Многие FTP-программы имеют функцию автосинхронизации, которая может быть настроена на сохранение папки с вашего компьютера в папку на вашем веб-сайте. Есть много и других решений, но ключевые слова здесь автоматически и ежедневно; все, что требует от вас каких-то усилий, например, запись болванки, обречено на забытие в самый неподходящий для этого момент.

Автосохранение отличается от контроля версий, который тоже неплохо было бы иметь, но его настройка куда сложнее для не-гиков. Контроль версий отслеживает все изменения, внесенные в файл, и позволяет сравнить нынешнюю копию с любой предыдущей. К сожалению, хороших утилит для легкого контроля версий не так уж и много (честно, я ни одной не нашел), да и информовский IDE-формат не способствует легкой интеграции с подобными программами. (Встроенная система версий была бы замечательным дополнением к Inform 7, особенно с расширениями, которые вы используете).

№2 Не меняйте дизайн.

Blue Lacuna развивалась. И как развивалась. Она должна была начаться в Tomahna (вы, фанаты Myst, знаете, о чем я говорю) и быть интерактивной фан-фикшн. Семь сцен сновидений были закончены прежде, чем я изменил внутреннюю механику, и мне пришлось полностью их переписать. В окончательной версии было три эпилога, но за время разработки я написал как минимум в два раза больше концовок. Диалоговая система постоянно нуждалась в новых функциях, патчилась и патчилась пока не превратилась в почти некотролируемый бардак. Я продолжал придумывать новые действия, которые, как я думал, должен был делать Progue, и нырял в этот запутанный код, чтобы добавить их; в результате он вел себя не только необычным, но и невозможным, как я думал, образом.

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

Какое-то количество проб, вычищений и переработки всегда сопровождает любой творческий проект. Для вашего дизайна и игровых идей естественно развиваться со временем. И Inform 7 поддерживает использование вами подхода повторений, "проб и ошибок".

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

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

Как только у вас появился дизайн, еще раз продумайте его. Есть ли в нем сценарные ветки или паззлы, или диалоги, или комнаты, которые вы не очень хотите программировать в ближайшем будущем? Это может знаком того, что они скучны или многословны, или проходятся как-то странно и вы должны изменить их прямо сейчас. Есть ли области, которые вы мысленно избегаете, думая: "Я разберусь с этим, как только сяду программировать." "Опасность!" Разберитесь с ними сейчас.

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

Весь смысл в том, чтобы как можно больше перепробовать и развить до того, как вы начнете программировать.

№3 Как можно раньше обзаведитесь поддержкой.

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

Конечно, они незаменимы при нахождении опечаток, неработающих паззлов, объектов, нуждающихся в лучшем исполнении и для общей полировки. Но есть довольно четкий лимит на объем изменений, который вы сможете внести на финальных стадиях своего проекта (смотри предыдущий пункт). Если у ваших тестеров проблемы с общей структурой, с персонажами, стилем, диалоговой системой, передвижением или механикой -- ну, вы поняли, с самой игрой -- все, что вы можете надеятся сделать, это прилепить несколько патчей на основные проблемы (которые скорее всего введут новые баги и будут не самым идеальным решением).

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

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

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

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

№4 Проводите свои эксперименты сначала на маленьких играх.

В Blue Lacuna не меньше дюжины странных и экспериментальных элементов. Через несколько лет разработки, я решил, что мне нужно знать чужое мнение о них: подсвечиваемых ключевых словах, диалоговой системе, некомпасной навигации. Я решил отправить предварительную версию на Spring Thing 2008 с готовыми основными системами, но лишь с первой половиной сценария. Я надеялся, что участие в конкурсе послужит толчком к публичному обсуждению и отзывам, и так я увижу, что люди думают о моих экспериментах.

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

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

В качестве альтернативы я мог анонсировать "открытую бету" (как недавно и с успехом поступила Эмили Шорт для Alabaster) или выпустить игру вне конкурса, где нет жестких рамок правил о природе содержания и допустимых темах для обсуждения.

Дело в том, что, во-первых, конкурсы IF-сообщества не место для незавершенных работ (не считая IntroComp). Во-вторых, мест для незавершенных работ в IF-сообществе явно не достаточно. Если хотите, можете создать несколько.

№5 Пишите, помня об отладке.

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

Так как в I7 отсутствуют функции, присущие универсальным языкам, такие как пошаговое отслеживание или !profiling tools to help optimize for speed!, отладка становится проблематичной. Нет консоли для сообщений об ошибках, и вы не сможете проверить или изменить значения переменных на лету.

И при этом, вдвойне важно задумываться о предстоящей отладке, пока вы создаете дизайн и программируете. Напишите себе побольше вспомогательных глаголов, которые позволят изменять важные игровые переменные, быстро перемещаться во времени и пространстве, начинать и останавливать специальные события, менять внтуреннюю работу NPC. Воспользуйтесь существующими отладочными расширениями, такими как великолепный "Simple Debugger" от Майкла Хилборна, который позволяет вам создавать внутриигровые объекты в качестве !debugging foci!, а потом просто включать и выключать вывод отладочной информации, связанной с этими объектами.

Для Glulx-игр вы можете использовать расширение "Flexible Windows" от Йона Ингольда для создания тестирующих команд, которые открывают окна с беспрерывно выводящейся отладочной информацией. В Blue Lacuna у меня была команда для отслеживания главного NPC, которая открывала пятистрочное окно вверху экрана, показывающие несколько дюжин переменных, связанных с его состоянием, местонахождением, внутренними переменными, с участием в диалогах и со всем остальным, что мне могло понадобиться. Позже я создал "god mode", в котором через внутриигровое меню мог менять большинство из этих переменных.

Наконец, познакомьтесь поближе с уже существующими отладочными элементами. Они не очень хорошо задокументированы: на сайте I7 посмотрите документ "Appendix B", главу "Test Template" для полной информации. Бывают полезными ABSTRACT, ACTIONS, GONEAR, PURLOIN, RANDOM, RELATIONS, RULES и RULES ALL, SCENES, SCOPE, SHOWME и SHOWVERB. Используйте TEST и/или Skein, чтобы быстро проверять работоспособность частей вашей игры.