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