Разработка Blue Lacuna: 12 уроков, выученных Аароном Ридом
Разработка 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, и нырял в этот spaghetti-like код, чтобы добавить их; в результате он вел себя не только необычным, но и невозможным, как я думал, образом.
В результате всего этого я проводил значительную часть своей жизни, в крайнем разочаровании и глубоком отчаянии уставившись на сообщения вида: "Progue, похрапывая, проплывает мимо вас по пустыне." Большую часть этого можно было избежать, если бы я с самого начала определился с тем, что он должен и чего не должен был делать, а потом придерживался разработанного дизайна вместо слепого программирования.
Какое-то количество проб, вычищений и переработки всегда сопровождает любой творческий проект. Для вашего дизайна и игровых идей естественно развиваться со временем. И Inform 7 поддерживает использование вами подхода повторений, "проб и ошибок".
Но развитие идей для интерактивного проекта занимает больше времени, чем для романа или сценария, и еще больше для воплощения их в жизнь: вы не просто меняете слова, но создаете полностью новое вариантное облако. В большом проекте по мере появления все новых и новых правил, объектов, систем и сцен, внесенное изменение начинает ломать больше вещей, чем улучшать: тонкая настройка здесь ломает что-нибудь там. Вы еще можете и не знать, но самые небольшие изменения уже стоят вам многих часов работы и делают напрасным все предыдущее тестирование.
Итак: как можно раньше, до самого процесса программирования, проработайте дизайн вашей игры. Запланируйте работу всех паззлов. Если у вас несколько концовок, в деталях продумайте какие условия к какой приводят. Если в вашей игре появились новые захватывающие особенности, разработайте их в виде отдельных расширений или сделайте небольшие демо-игры, чтобы протестировать их.
Как только у вас появился дизайн, еще раз продумайте его. Есть ли в нем сценарные ветки или паззлы, или диалоги, или комнаты, которые вы не очень хотите программировать в ближайшем будущем? Это может знаком того, что они скучны или многословны, или ill-thought out и вы должны изменить их прямо сейчас. Есть ли области, которые вы мысленно избегаете, думая: "Я разберусь с этим, как только сяду программировать." "Опасность!" Разберитесь с ними сейчас.
Также для того, чтобы выявить недостатки в дизайне, вы можете пригласить друзей и пробежать с ними по сценарию, как если бы это была ролевая игра: "Что ты будешь делать дальше?" Если ваш игрок сбивается с толку или скучает в некоторых секциях, или вы понимаете, что неудобно или сложно пройти через данную сцену, это знак того, что требуется еще одна переработка.
Весь смысл в том, чтобы как можно больше перепробовать и развить до того, как вы начнете программировать.
№3 Как можно раньше обзаведитесь поддержкой.
Все мы слышали совет о том, чтобы дать бета-тестерам пройти вашу игру после ее завершения. К сожалению, я начинаю думать, что этот совет неправилен. Если ваша игра уже закончена, тестеры несильно помогут.
Конечно, они незаменимы при нахождении опечаток, неработающих паззлов, объектов, нуждающихся в лучшем исполнении и для общей полировки. Но есть довольно четкий лимит на объем изменений, который вы сможете внести на финальных стадиях своего проекта (смотри предыдущий пункт). Если у ваших тестеров проблемы с общей структурой, с персонажами, стилем, диалоговой системой, передвижением или механикой -- ну, вы поняли, с самой игрой -- все, что вы можете надеятся сделать, это прилепить несколько патчей на основные проблемы (которые скорее всего введут новые баги и будут не самым идеальным решением).
В наши дни профессиональные компьютерные игры тестируются годами перед релизом. Как только появляется что-то, что компилируется, не важно насколько неустойчивое, разрозненное и неопределенное, тестеры начинают в это играть и делать замечания. Такой подход искореняет проблемы с базовой механикой игры: это не весело, занимает слишком много времени и these things will suck как хорошо бы ни выглядел конечный результат.
Очевидно, что средний автор IF не обладает ресурсами большой игровой студии, но это еще не значит, что подобная модель бесполезна для нас. Неплохим подходом к тестированию IF, которым и я надеюсь воспользоваться в моей следующей игре, может стать организование основной группы тестеров не когда вы уже закончили, но когда вы еще и не начинали, они будут с вами на всем протяжении создания игры. Когда вы программируете новые паззлы и системы, вы можете дать вашим тестерам поиграться с ними и получить отзывы; когда игра начинает
