• команда талантливых, опытных, преданных и коммуникабельных дизайнеров и художников (и понимающая супруга в нагрузку);
• время и деньги, чтобы в случае чего безболезненно облажаться разок-другой
• первоклассный дизайн-документ.
 |
| Цви Фриман (Tzvi Freeman), автор статьи и ex-преподаватель в Digipen, ныне профессиональный раввин (!) и редактор сайта Chabad.org |
В те стародавние времена, когда программированием игры занимался один человек (порой, он же и художник), бюджет игры составлял три копейки, а дедлайн был весьма условным понятием, документацию не нужно было воспринимать всерьёз. Ты знал, что хочешь сделать – и делал это. Если в процессе возникают серьёзные перемены, кроме себя, винить некого. Сегодня же наличие тщательно прописанного документа может обеспечить приятную поездку в рай вместо медленного, но верного сползания в безденежный ад.
Как это работает
Большинство игр проходят через три этапа разработки: концепт, дизайн и продакшен. Можете условно назвать их «озарение», «бумагомарание» и «шлифовка».
На первом этапе документ-концепция служит тебе посланием (чётко расставить задачи и не растерять по ходу) и как инструмент продаж для тех, кто будет продвигать продукт на рынке. Иногда на этом этапе требуется наличие небольшого рабочего прототипа, что даст тебе шанс поэкспериментировать и переосмыслить некоторые идеи.
Второй, промежуточный, этап подразумевает массу обсуждений с художниками, аниматорами, музыкантами и программистами — пробы, ошибки и поиск способов организации и применения твоих идей.
На последнем этапе, управление продакшеном обычно взваливают на плечи какого-нибудь специалиста, который сможет обеспечить плавное движение без крупных коллизий. Изначальный дизайнер может являться ключевой частью команды разработчиков, но зачастую, особенно в больших компаниях, дизайнер служит кем-то вроде внешнего консультанта.
Без сомнения, дизайн-документ является той самой точкой приложения наибольших сил «родителя» проекта, которая определяет будущее детища. Даже если ты, дизайнер, решил выступить ещё и в роли проект-менеджера, не стоит думать, что тебе удастся всё это успешно контролировать. В сложных проектах подразумевается участие множества талантливых людей. У опытных программистов и художников имеют своё мнение. И если дизайнер хочет создать лошадь, художник может захотеть нарисовать единорога, а программист — надёжного верблюда. Хороший дизайн-документ гарантирует, что все трое будут планировать создать одно и то же. А отличный - гарантирует, что все причастные будут одинаково ощущать суть, «душу» вещей. Это как с большим джаз-бэндом — все работают вместе как часы, при этом звездам остаётся время для импровизаций.
Твой дизайн-документ является своеобразным посредником между твоим мозгом и реальным миром. Он гарантирует, что реальный мир поймёт задуманное, и результат будет соответствовать твоему изначальному видению.
Наконец, помните поговорку, с которой согласится даже самый въедливый игрок: «Великое искусство кроется в деталях». Блестящие мелочи столь естественно возникают из общей идеи, будто они были придуманы при первом порыве вдохновения. Но стоит тебе только начать вручную претворять всё в жизнь — вдохновение легко упустить.
Вызов
Частично взять на себя задачу по изготовлению прототипа — хороший вариант. Накидывай столько идей, сколько нужно. Но, опять же, важны детали. Чем больше мелочей ты сможешь удержать в голове, тем большим шедевром будет твоя работа.
Работа на основе документа имеет и оборотную сторону. Разработка захватывающей игры тоже должна быть захватывающей. Лучшие находки во многих проектах — результат поспешных решений, принятых в панике в последний момент. Конечно, временные и денежные рамки не позволяют постоянно менять подходы к концепту игры, но нельзя забывать главное — сухой, предсказуемый рабочий процесс не породит шедевр. Вызов в том, чтобы создать дизайн-документ, который позволит вносить приятные новшества в проект без потери фокуса и масштаба исходной задумки.
 |
| Три стадии документирования разработки |
Десять рекомендаций по созданию успешного дизайн-документа
1. Описывай не внешнюю оболочку, а суть
Будь разработка игры лишь проблемой автоматизации проблем ввода-вывода (вроде как написать код и предсказать, как он будет работать) — тогда можно было бы обойтись сухим, наглядным документом. Но в реальной жизни разработкой занимаются живые люди, в большинстве своём люди творческие, со своим видением. И большинство из них захотят оставить свой след на том, что они делают.
Как это бывает: ты даёшь инструкции художникам и обсуждаешь, что хочешь от них получить. Затем ты идёшь к программистам и объясняешь их задачи. Все кивают, все всё поняли.
А ночью, часика в 2, когда созвездие C++ встаёт на западе, программиста настигает кризис среднего возраста и мысли вроде: «Как так, неужто быть мне задротом-программистом до конца жизни? Разве этого от меня ожидали мои родители? Да я и сам могу сделать игру, не хуже других!» И пальцы его начинают лихорадочно печатать код.
Примерно в это же время, художник просыпается за своим рабочим местом. Он впал в ступор, пока ждал завершения сложного 3D-рендера. И вот художник, до конца не понимающий, где сон, а где работа, погрузился в дикий мир художественного гения, где реальность и фантазия сливаются воедино, и рождают образы, ранее невиданные и неожиданные. Ты, по крайней мере, их точно не ожидаешь.
В итоге, к следующему утру твоя лошадь превращается в единорога с двумя горбами. С творческими людьми инструкций недостаточно. Нужно вдохновение.
В дизайн-документе не стоит останавливаться на детальном описании каждой мелочи. Нужно уделить время ещё и тем чувствам, которые должна вызывать игра, цели каждого элемента, переживаемому игроком опыту и всем остальным аспектам сути игры, которые вы можете вообразить и описать.
Допустим, ты делаешь стрелялку. Тебе нужно научить игрока справляться с определенными задачами, поэтому ты решаешь сначала поместить несколько несложных мини-задач. Это нужно донести до каждого в команде разработчиков, чтобы они понимали, почему определенные задачи размещены именно там, а не где-то ещё, и почему они работают именно так, а не иначе. Таким образом, даже если (читай: когда) твоя команда поиграется и исковеркает твои изложенные на бумаге идеи, ты можешь надеяться на (в целом) похожий результат. А может, даже лучше.
2. Документ должен быть читаемым
Попробуй всучить своим подопечным талмуд, написанный 10 кеглем, 80 знаков на строчку, и потребовать прочитать его. Можно в нагрузку дать обезболивающее — тем мазохистам, которые любят подчиняться приказам.
Рекомендую придерживаться следующим принципам при написании хорошего документа:
• достаточно свободного пространства;
• шрифт Serif для основного текста;
• ЖИРНЫЕ заголовки;
• пробелы между абзацами;
• короткие предложения;
• глаз должен цепляться за самое важное;
• использовать иерархический «2D»-формат.
Часто бывает необходимо вставить таблицу или график. Старайся делать их хотя бы минимально приличными.
3. Расставляй приоритеты
Раз уж ты понял, что приходится работать с коллективом себе на уме, надо понимать и необходимость отмечать некоторые «неприкосновенные» элементы игры. Конечно, никто не даёт гарантий, но есть вероятность, что, если не перебарщивать, к тебе прислушаются. Главное, не останавливайся: раз уж начал отмечать идеи, следует отделять те, которые ты точно планируешь сделать и те, которые можно реализовать при наличии времени, денег, навыков и техсредств.
Кроме того, от чего-то придётся отказаться. Всегда есть вещи, которые здорово смотрятся на бумаге, но есть серьезные причины, чтобы выбросить их в мусорку. Если этого не сделать, я гарантирую, что они всплывут и начнут тормозить процесс.
Как промаркивать идеи:
• Необходимо
• Важно
• Если возможно
• Отклонено
Можно обозначить их графическими символами для наглядности. Не полагайся на цвет, не всегда документы распечатывают на цветном принтере!
4. Разъясняй всё подробно
Документ без подробностей бесполезен. Общие вещи любой может интерпретировать как угодно. «Не убий» для Моисея значило одно, а для испанского конкистадора совершенно другое. Неплохо было бы получить подробное описание, кого и при каких обстоятельствах не следует убивать. То же самое касается и твоего документа: как только ты расписал кое-какие реальные идеи и привели примеры, твоя идея стала более конкретной. Теперь от неё не так-то просто отмахнуться.
Например, не стоит писать вещи вроде «Бронзовая птица неуязвима». Нужно описать, что именно происходит с этим существом, когда ему пытаются нанести урон, и как оно восстанавливает здоровье. Будь уверен, если у аниматора есть хоть какая-то творческая жилка и профессиональная гордость, он не последует твоим инструкциям. Но, по крайней мере, у него будет чёткое понимание, чего ты хочешь достичь, и поэтому его нововведения не исковеркают соответствующие области игры.
Не надо говорить: «Теперь игроку нужно нажать кнопку прыжка стрелкой вверх, чтобы забраться на стену». Опиши, что произойдёт, если нажать что-нибудь другое. Опиши, почему описанная вами последовательность должна быть ясна игроку. Поясни, что в игровом окружении указывает на возможность забраться именно на эту стену.
Опять же, художник придумает что-то своё, возможно, лучше, чем придуманное тобой изначально. Когда результаты твоих разработчиков ближе к вашей изначальной идее, чем изложенные тобой идеи на бумаге — это и есть успех. Однако, его не будет, пока ты чётко и ясно не распишешь концепцию.
Не надо писать: «Бонго Мужик сильнее Бонго Парня, зато у Бонга Парня быстрее реакция». Используй таблицы и графики, чтобы оценить реальные значения скорости персонажей, их выносливости, здоровья, количества кадров анимации удара и так далее. Такие данные неоценимы на стадиях отладки и тестирования.
Не надо писать: «Большинство людей разберутся в игре через пару дней». Сделай таблицу примерной продолжительности игры для разных категорий населения, отметь то время, которое займёт обнаружение каждой особенности («фичи») игры. Позднее тестирование даст ценные отклики, которые пригодятся при разработке следующей игры.
5. Некоторые аспекты нужно продемонстрировать
Иногда нескольких грубых набросков бывает достаточно. Однако, если идея действительно важна для всей концепции проекта, тебе может понадобиться самому нарисовать грубую анимацию. Когда описание поведения элементов на бумаге становится слишком сложным и пространным — имеет смысл сделать прототип. Важный плюс прототипа: практика часто ведёт к более простым и элегантным решениям проблем.
Если же ты сделал анимацию и прототипы — всё равно распиши концепцию на словах. Конечно, анимация заменяет гигабайты слов, но иногда слова помогают достичь такого уровня коммуникации, какого не достигает никакая анимация. Слова также ясно обозначают важнейшие нюансы, которые могут быть упущены при её просмотре.
6. Не просто «что», но «как»
В реальном мире «как» определяет «что». К примеру, ты решил делать игру в стиле claymation (пластилиновая анимация). Продумай процесс захвата изображений и распиши все детали. Какой материал использовать и какого цвета будет фон? Какую камеру нужно использовать и почему? Как обрабатывать отснятые кадры? И т. д. и т. п. Если хоть раз попробуешь заняться подобным, ты будешь знать, что любой фактор может серьёзно повлиять на конечный результат.
Или, предположим, ты работаешь над гонками на мотоциклах. Твоя идея в том, что баланс между моделями мотоциклов обусловлен их плюсами и минусами. Затем ты делаешь таблицу, демонстрирующую этот баланс. После чего нужно заняться тонкой настройкой и решить, каким образом она организована.
Допустим, главный герой в твоей игре — Призрак оперы. Опиши, что клавиши на клавиатуре соответствуют оным на органе. Распиши конкретный список клавиш. Укажи, сколько каналов звука будет использоваться в игре. Обговори этот вопрос с программистом и учтите каждое «как». И запиши в документ. Учти, что два разных «как» дают очень разные результаты.
7. Предоставляй выбор
Проект-менеджеры тратят кучу времени на работу с Gantt и PERT диаграммами [диаграммы для создания плана работ и оценки и анализа программ]. Не могу сказать, что они подходят для разработки игр в силу огромного количества неизвестных. Чем более сильная и новаторская у тебя технология, тем менее предсказуемым будет процесс разработки. Лучший способ гарантировать выполнение вашей командой поставленных задач в срок — предоставлять разные способы достижения цели.
Вернёмся к примеру с клавиатурой в качестве органа. Твой программист описывает исчерпывающий вариант: получить классный результат, который произведёт неизгладимое впечатление на игрока - ценой примерно 50 человеко-часов разработки. Как и всё остальное, ты записываешь этот вариант в дизайн-документ.
На этом нельзя останавливаться. Нужно спросить: «А что если сделать урезанный, восьмиканальный орган? Что нам нужно, чтобы сделать суровый минимум? И можно ли эту задачу делегировать кому-нибудь ещё?» Это ты тоже записываешь. И затем, в случае чего, ты сможешь спасти свою шкуру, просто выбрав подходящий запасной вариант.
Когда я занимался дизайном проектов, я допускал одну из грубейших ошибок — справлялся у программистов: «А возможно ли сделать вот так?» Если только ты не говоришь с первоклассным программистом – это бесполезно. Потому что можно услышать только три варианта ответа:
Скверный программист: «Конечно, без проблем».
Средненький программист: «Нет, это сделать нельзя».
Первоклассный программист: «Я могу это сделать, это займёт две недели. Или я могу сделать немного по-другому, и это займёт пять часов».
Всегда ищи несколько вариантов и оценивай временные затраты. Затем укажи приоритеты: следовать одному варианту, если будет время, или другому — если нет.
8. Дай проекту жить своей жизнью
Я уже предостерёг тебя от подавления вдохновения и вспышек креативности, которые идут рука об руку с волнением и радостью от осознания того, как оживают твои идеи. Дизайн-документ должен допускать изменения, тобой или (будем надеяться, разумными) другими людьми.
Впервые я осознал это, когда учился на композитора в Университете Британской Колумбии. Потратив кучу сил, я написал брасс-квинтет в стиле Неоренессанс, которым очень гордился. Моему профессору он тоже понравился. Однако когда я принёс работу нашему брасс-квинтету, мне за несколько мгновений пришлось испытать несколько стадий ужаса, отрицания, негодования и клинической депрессии. Квинтет начал играть, затем остановился по сигналу трубача. Он взял карандаш и начал вносить правки в ноты. Это повторилось несколько раз.
Профессор, заметив мои эмоции, повернулся ко мне и сказал: «Не волнуйся, они и в Моцарта правки вносят. И обычно все они к месту».
Дело в том, что, как бы хорошо идея не смотрелась на бумаге, гуру своего дела вносят что-то своё, когда доходит до её воплощения в объективной реальности. Как бы то ни было, вряд ли тебе хочется быть свидетелем жестокого насилия над твоим замыслом. Скорее, ты надеешься на органичный рост: идеи должны самостоятельно прорастать из посеянного тобой, безо всяких посторонних подпорок и костылей.
Приведу несколько советов, как создать документ, который терпит внесение изменений, не портя исходную идею и не саботируя процесс разработки.
• Убедись, что критически важные для целостности игровой концепции вещи высечены в граните.
• Убедись, что все чувствуют атмосферу игры и понимают смысл каждой детали.
• Если информация повторяется, нужно делать перекрёстные ссылки. Иначе, в случае изменений, могут возникнуть противоречивые инструкции.
А вот несколько рекомендаций для стадии практической реализации проекта:
• Когда предлагается внести изменения, сверься с дизайн-документом на предмет того, соответствуют ли они «духу» вашей игры
• Проверь, частное это изменение или крупное, меняющее ситуацию в корне. Если крупное, лучше прибереги эту идею для следующего проекта.
• Обновляй дизайн-документ и вноси причины для изменений. А если изменения не были внесены, укажи, как и почему от них отказались.
• Правки и забракованные идеи должны быть перечислены в чистовой редакции дизайн-документа, чтобы избежать их повторного обсуждения в будущем.
• Все сотрудники должны работать с единой редакцией документа. Старые версии необходимо уничтожить.
• ЖИЗНЕННО ВАЖНО: Контроль за дизайн-документом должен осуществлять только 1 (один) человек.
9. Делай так, чтобы никто не смог заявить: «Я сделал так, потому что не смог найти информацию об этом в дизайн-документе»
Я видел дизайн-документы с непронумерованными страницами. При этом их авторы жаловались, что их инструкции не соблюдаются! Любой хороший текстовый редактор может пронумеровать вам страницы, указать дату и название документа на каждой странице. Некоторые даже позволяют изменять заголовки в новой главе. Используй полужирный шрифт, чтобы привлечь внимание к важным деталям. Можешь повторять материал столько раз, сколько угодно, главное – не забывай перекрёстные ссылки, чтобы в случае чего обновлять всё вместе. Сделай подробную страницу с содержанием.
Возможно, ты захочешь сделать документ в html формате и снабдить его ссылками. Некоторые текстовые процессоры позволяют делать ссылки без использования html. Но нужно помнить, что чаще всего люди предпочитают бумажный текст (в таком случае, им есть, что почитать во время перезагрузки после очередного крэша системы).
10. Презентуй дизайн-документ в хорошем состоянии
После всех затраченных усилий на написание документа, нужно ещё и постараться заставить всех его прочитать, и применять на практике. Стопку листков никто читать не будет – выглядит непрезентабельно. Презентабельно выглядит чтиво в твёрдом переплёте.
Напиши список тех, кому понадобится копия дизайн-документа. Храни его. Распечатай документ с датой печати в заголовке каждой страницы. Сделай отверстия, переплёт. Делай отметки на каждом переплёте. Иногда может понадобиться изготовить ещё пару копий (и избавиться от старых).
Подводя итог.
В киноиндустрии используют сценарии. В архитектуре – чертежи. В музыке – партитуры. По слухам, даже Всевышний создал дизайн-документ, в который дал заглянуть паре пророков, прежде чем изречь: «Да будет свет!» Ну а разработчики игр, следуя своей сверхъестественной ролевой модели, просто обязаны сделать то же самое. Сделай документ по правилам, и всё остальное пройдёт как по маслу.
Как написать отличный дизайн-документ, Цви Фриман
12 сентября 1997 года
Оригинал статьи: ссылка
Комментариев нет:
Отправить комментарий