Изменения

Перейти к навигации Перейти к поиску
Нет описания правки
'''Разработка ''Blue Lacuna'': 12 уроков, выученных Аароном Ридом'''
 
 
 
Если бы осенью 2005 года, когда я только начал набрасывать маленькую карту тропического острова и задумываться о квесте, вы сказали мне, что в 2009 я все еще буду работать над ней, я бы ударил кого-нибудь по лицу.
Однако, если вы уже отправились или еще только планируете купить билет на путешествие по длинной дороге разработки полноразмерной IF, вас могут заинтересовать некоторые вещи, которые я узнал за месяцы (читай: годы) создания ''Blue Lacuna''. Вы заметите, что многие эти вещи можно применить к любому большому проекту, связанному с программированием, потому что, чем больше становится ваша игра, тем меньше это похоже на баловство с текстовыми квестами и больше похоже на серьезное программирование, в независимости от того, сколько очаровательных естественно-языковых конструкций Грэхем добавит в Inform 7. Кстати, вы также заметите, что некоторые из советов специфичны для этого языка, но, надеюсь, честолюбивый человек сможет сделать нужные выводы в независимости работает ли он на Inform 6 или TADS, или жаждет создать первый квест в миллион слов на SUDS.
 '''== №1 Разработайте стратегию сохранений.'''==
Примерно через три месяца разработки ''Blue Lacuna'', когда я построил большую часть карты, добавил большое количество описаний локаций, запрограммировал базовые паззлы и даже начал работать над вычурными ответами на взаимодействие с животными, я случайно потерял весь мастер-файл.
Автосохранение отличается от контроля версий, который тоже неплохо было бы иметь, но его настройка куда сложнее для не-гиков. Контроль версий отслеживает все изменения, внесенные в файл, и позволяет сравнить нынешнюю копию с любой предыдущей. К сожалению, хороших утилит для легкого контроля версий не так уж и много (честно, я ни одной не нашел), да и информовский IDE-формат не способствует легкой интеграции с подобными программами. (Встроенная система версий была бы замечательным дополнением к Inform 7, особенно с расширениями, которые вы используете).
 '''== №2 Не меняйте дизайн.'''==''Blue Lacuna'' развивалась. И как развивалась. Она должна была начаться в Tomahna (вы, фанаты ''Myst'', знаете, о чем я говорю) и быть интерактивной фан-фикшн. Семь сцен сновидений были закончены прежде, чем я изменил внутреннюю механику, и мне пришлось полностью их переписать. В окончательной версии было три эпилога, но за время разработки я написал как минимум в два раза больше концовок. Диалоговая система постоянно нуждалась в новых функциях, патчилась и патчилась пока не превратилась в почти некотролируемый бардак. Я продолжал придумывать новые действия, которые, как я думал, должен был делать Progue, и нырял в этот !spaghetti-like! запутанный код, чтобы добавить их; в результате он вел себя не только необычным, но и невозможным, как я думал, образом.
В результате всего этого я проводил значительную часть своей жизни, в крайнем разочаровании и глубоком отчаянии уставившись на сообщения вида: "Progue, похрапывая, проплывает мимо вас по пустыне." Большую часть этого можно было избежать, если бы я с самого начала определился с тем, что он должен и чего не должен был делать, а потом придерживался разработанного дизайна вместо слепого программирования.
Итак: как можно раньше, до самого процесса программирования, проработайте дизайн вашей игры. Запланируйте работу всех паззлов. Если у вас несколько концовок, в деталях продумайте какие условия к какой приводят. Если в вашей игре появились новые захватывающие особенности, разработайте их в виде отдельных расширений или сделайте небольшие демо-игры, чтобы протестировать их.
Как только у вас появился дизайн, еще раз продумайте его. Есть ли в нем сценарные ветки или паззлы, или диалоги, или комнаты, которые вы не очень хотите программировать в ближайшем будущем? Это может знаком того, что они скучны или многословны, или !illпроходятся как-thought out! то странно и вы должны изменить их прямо сейчас. Есть ли области, которые вы мысленно избегаете, думая: "Я разберусь с этим, как только сяду программировать." "Опасность!" Разберитесь с ними ''сейчас''.
Также для того, чтобы выявить недостатки в дизайне, вы можете пригласить друзей и пробежать с ними по сценарию, как если бы это была ролевая игра: "Что ты будешь делать дальше?" Если ваш игрок сбивается с толку или скучает в некоторых секциях, или вы понимаете, что неудобно или сложно пройти через данную сцену, это знак того, что требуется еще одна переработка.
Весь смысл в том, чтобы как можно больше перепробовать и развить до того, как вы начнете программировать.
 '''== №3 Как можно раньше обзаведитесь поддержкой.'''==
Все мы слышали совет о том, чтобы дать бета-тестерам пройти вашу игру после ее завершения. К сожалению, я начинаю думать, что этот совет неправилен. Если ваша игра уже закончена, тестеры несильно помогут.
Конечно, они незаменимы при нахождении опечаток, неработающих паззлов, объектов, нуждающихся в лучшем исполнении и для общей полировки. Но есть довольно четкий лимит на объем изменений, который вы сможете внести на финальных стадиях своего проекта (смотри предыдущий пункт). Если у ваших тестеров проблемы с общей структурой, с персонажами, стилем, диалоговой системой, передвижением или механикой -- ну, вы поняли, с самой игрой -- все, что вы можете надеятся сделать, это прилепить несколько патчей на основные проблемы (которые скорее всего введут новые баги и будут не самым идеальным решением).
В наши дни профессиональные компьютерные игры тестируются ''годами'' перед релизом. Как только появляется что-то, что компилируется, не важно насколько неустойчивое, разрозненное и неопределенное, тестеры начинают в это играть и делать замечания. Такой подход искореняет Они выявляют проблемы с базовой механикой игры: это не весело, занимает слишком много времени и !these things will suck! вещи, которые будут отстоем, не важно как хорошо бы ни выглядел конечный результат.
Очевидно, что средний автор IF не обладает ресурсами большой игровой студии, но это еще не значит, что подобная модель бесполезна для нас. Неплохим подходом к тестированию IF, которым и я надеюсь воспользоваться в моей следующей игре, может стать организование основной группы тестеров не когда вы уже ''закончили'', но когда вы еще и не ''начинали'', они будут с вами на всем протяжении создания игры. Когда вы программируете новые паззлы и системы, вы можете дать вашим тестерам поиграться с ними и получить отзывы; когда игра начинает собираться в одно целое, вы можете дать им ее потестировать на плавность, передвижение и логические проблемы даже еще до того, как создать все описания локаций и погрузиться с головой в детали.
(Заметка: вы должно быть думаете, что не у каждого есть своя маленькая армия тестеров, выстраивающихся в очередь, чтобы потестить еще не законченную игру, как например у Дэвида Уилда. Без проблем. Найдите трех других людей, которые не Дэвид Уилд, и договоритесь быть тестерами в игровых проектах друг друга.)
 '''== №4 Испытывайте свои эксперименты сначала на маленьких играх'''==
В ''Blue Lacuna'' не меньше дюжины странных и экспериментальных элементов. Через несколько лет разработки, я решил, что мне нужно знать чужое мнение о них: подсвечиваемых ключевых словах, диалоговой системе, некомпасной навигации. Я решил отправить предварительную версию на Spring Thing 2008 с готовыми основными системами, но лишь с первой половиной сценария. Я надеялся, что участие в конкурсе послужит толчком к публичному обсуждению и отзывам, и так я увижу, что люди думают о моих экспериментах.
И вместо этого, все, что я получил, это серию спопров споров о том, должна ли игра быть дисквалифицирована ввиду своей незавершенности; некоторые люди похоже восприняли этот релиз как личное оскорбление. Не было никаких публичных обсуждений ни по одному из нововведений, на которые я надеялся. Игра заняла последнее место в конкурсе. Конец истории.
После обдумывания я понял, что если бы я выбрал ''одно'' из этих нововведений, использовал его в одной, более короткой игре и уже с ''ней'' участвовал в Spring Thing, то я, возможно, получил бы более сконцентрированное на плюсах и минусах эксперимента обсуждение. Затем я бы принял во внимание все советы и встроил этот кусочек в свою эпопею, или настроил и исправил его, если нужно.

Навигация