Дмитрий Воронов
Старейший и опытнейший дизайнер питерской студии CREAT, принимавший участие в разработке множества игровых проектов. Объектом изучения в данной статье станет инструмент организации, коммуникации и координации игрового проекта, далее называемый Game Focus (далее "гейм-фокус"). Обладая таким инструментом и правильно используя его, все участники процесса разработки - от геймдизайнера до руководителя проекта - четко знают, что за игру они делают, представляют себе спектр задач и приоритеты работ на проекте и, в конечном итоге, могут рассчитывать на релиз "цельной игры" (англ. solid game), где все элементы находятся в прочной и логичной взаимосвязи друг с другом, а главное - все они служат единой цели: делать конечный продукт увлекательным и интересным. Хочется отметить, что чем больше участников проекта понимают, что такое гейм-фокус и как с ним работать, тем значительней эффект от его применения. В связи с этим материал может представлять интерес для представителей всех специальностей геймдевелоперской индустрии.
Очевидная неочевидность или постановка проблемы
Бывает так, что от частого употребления некоторые тезисы, утверждения и изречения переходят в разряд вещей "само собой разумеющихся", в категорию того, о чем уже и говорить бессмысленно - настолько все кажется очевидным и не требующим дополнительных разъяснений.
Например, всем прекрасно известно, что при разработке "собственной" игры зона прямой ответственности геймдизайнеров - раскрыть, структуририровать и донести до всех остальных участников проекта идею игры, ее фичи, описать и продумать ее основные элементы и их взаимосвязь. Итогом такой работы является диздок. В идеале, любой член команды, прочитавший этот документ, должен иметь четкое представление о том, "что за игру он делает".
При этом часто встречаются ситуации, когда в одно прекрасное утро на пятом месяце производства вдруг выясняется, что программисты делают игру А, дизайнеры думают об игре С, а арт-отдел кропотливо трудится над игрой B. Ужас ситуации в том, что через три месяца продюсер ждет выхода игры D.
Первое, что приходит на ум при анализе этой ситуации - в компании плохие геймдизайнеры. Второе - геймдизайнеры-то, может, и неплохие, а вот процесс коммуникации на проекте поставлен отвратительно. Ну ведь твердили, рассказывали всем участникам проекта "про игру", писали разъяснительные записки и даже давали почитать диздок. И вроде все всё поняли. Может быть, проблема в том, что нужно чаще напоминать? И начинается: пишутся письма, организуются рассылки, собираются совещания и т.д. и т.п. Во всей этой суматохе никто уже не в силах остановиться и подумать: а что же такое "коммуникация" в своем изначальном значении? Какой она должна быть? Само по себе это слово означает просто процесс передачи данных. И какими бы совершенными ни были используемые в ней механизмы, ничто не поможет, если данные обладают такими дефектами, как неясность, отсутствие четкой структуры, неточность и многозначность прочтений.
Ситуация зачастую усугубляется тем, что дизайнеры, чья непосредственная обязанность, как было сказано - доносить до коллектива контент игры, сами не могут четко и внятно ответить на вопросы вроде "что за игру мы делаем?" или "какие элементы игры наиболее важны или даже абсолютно необходимы, а какими, в условиях жестких временных рамок, можно пожертвовать?"
Жертвовать в той или иной степени приходится всегда. Вряд ли кто-нибудь будет спорить с тем, что в настоящий момент геймдевелопмент - это больше бизнес, чем искусство. Основные параметры коммерческих проектов - бюджет и сроки. Дилемма "качество - сроки" крайне актуальна для сегодняшней индустрии, и если вы хотите делать качественные игры в срок, вам придется эту дилемму решать.
Сеанс разоблачения черной магии
Хочешь научиться что-то делать - посмотри, как это что-то делают другие. Эта старая, как мир, аксиома, спасающая мир от бесконечного изобретения одних и тех же велосипедов, в полной мере применима и к разработке игр.
Ни для кого не секрет, что в процессе производства игр разработчики, прежде чем приступать к реализации какой-либо из фич, просматривают "референсные" игры, которые по содержанию в той или иной степени напоминают разрабатываемый проект.
Рассматривая многие топ-игры категории ААА, автор обратил внимание, что как только они становятся объектом исследования с точки зрения производства тех или иных элементов - текстур, моделей, анимаций или спецэффектов, "магия игры" (другими словами тут не сказать) полностью рассеивается. Приведу несколько примеров.
В одном из предыдущих проектов нашей студии нам понадобился референс для sword-combat. Под руку попался свежий (на тот момент) Jedi Knight 2: Jedi Outcast. Мы записали видео, а потом воспроизвели его на медленной скорости, чтобы повнимательнее рассмотреть анимацию персонажей. Мягко говоря, мы ужаснулись, насколько похабно выглядели руки, "протыкающие" тело, голову, друг друга, и насколько "негладкой" и дерганой была анимация. Весь фокус заключался в том, что сверкание светового меча и скорость проигрывания анимаций оттягивали на себя внимание игрока и полностью скрывали все огрехи.
В одном из следующих наших проектов, суть которого заключалась в быстрой езде на мотоцикле в городском окружении, мы в качестве референса взял вторую часть Midnight Club, чтобы понять технологию LOD-ов игровой геометрии. Для этого мы медленно подкатывали к зданиям. И увидели, как "нулевой" (наиболее тщательно текстурированный) LOD появляется на расстоянии... полуметра от стены здания, то есть прямо на глазах. Ужасающая халтура, да еще и сама текстура была откровенно некачественной. Фокус заключался в том, что сама суть игры - а именно быстрые гонки по городу - сводила вероятность увидеть эту халтуру практически к нулю.
Можно привести массу примеров подобного рода, но все они свидетельствуют об одном: все, что находится вне фокуса внимания игрока, не стоит значительных усилий разработчиков, а значит, на этом можно сэкономить бюджетные средства и направить ресурсы на улучшение качества того, что в игре является главным.
В принципе, все то, что сказано выше, может показаться очевидным. Неочевидным остается только один момент: почему при кажущейся простоте решения проблемы "как сделать качественную (хорошую) игру в срок" на рынок выбрасывается (не будем кривить душой, выбрасывается и отечественными производителями) столько некачественных игр, да еще и с просроченными сроками производства? Почему так происходит?
Причин здесь, разумеется, великое множество, и одна из них такова: знающих, что такое фокус (в цирковом смысле) - много, но при этом далеко не все являются фокусниками, и еще меньше людей владеет техникой создания гейм-фокуса и его использования в качестве инструмента, организующего весь процесс производства игры - от замысла до релиза.
Не изобретая велосипед (методика создания гейм-фокуса)
Не желая изобретать велосипед, автор материала попытался найти подтверждение своим мыслям в источниках геймдевелоперской мудрости. В оглавлении первой же попавшейся под руку работы - Richard Rouse. Game design theory & Practice. Worldware 2001 - значился раздел с названием Game Focus. Многое из нижеследующего является изложением этой главы с ремарками автора материала.
По мысли Ричарда Роуза, гейм-фокус - это ясный и краткий текст, описывающий абсолютно приоритетные элементы будущей игры. Своего рода скелет, спинной хребет игры. В концептуальном же плане, гейм-фокус - это направляющий вектор усилий всей команды разработчиков, своего рода mission statement (то есть миссия команды разработчиков).
Создателями гейм-фокуса проекта (в случае, если проект является "самостоятельной" разработкой команды) чаще всего выступают геймдизайнеры.
Процесс создания гейм-фокуса начинает процесс разработки игры. Работа эта крайне незатратная - один (или несколько) геймдизайнеров, ручка (клавиатура) и листок бумаги (чистый game-focus.doc). Однако ошибки, допущенные на этой стадии, могут стоить многих человеко-месяцев и тысяч и тысяч условных единиц бюджета, поэтому подходить к ней стоит максимально ответственно и времени на полировку и оттачивание текста гейм-фокуса не жалеть.
В большинстве случаев игра на этапе замысла находится "в голове" создателя в виде образа, картинки, или неформализованного ощущения. Первым шагом к созданию гейм-фокуса в этом случае будут ответы на вопросы, касающиеся сути будущего проекта.
Вот эти вопросы:
1. Что в игре является наиболее притягательным для игрока?
2. Какие ощущения игра должна вызывать у игрока?
3. Что игрок получает от игры?
4. Что в игре уникального, отличающего ее от других игр?
5. Каков основной способ взаимодействия игрока с окружающим его миром (environment)?
Если вы затрудняетесь ответить хотя бы на один из вышеприведенных вопросов, фокус требует доработки. Иначе как вы будете доносить его до коллектива?
Сформулировав ответы на вышеприведенные вопросы в какой угодно форме, приступайте к сжатию и полировке фокуса. Обратите внимание - гейм-фокус - это ни в коем случае не перечисление фич игры, скорее, это список самых ключевых игровых моментов и взаимодействия между ними. Например, если базис вашей игры - исследование отношений между персонажами в стрессовых ситуациях, незачем писать о декорациях, в которых оно происходит - будь то Средневековье, времена великой депрессии в Штатах или Смутное время в России. Сеттинг вашей игры в данном случае не так важен. Главный принцип при полировке фокуса - не стесняться выкидывать из него то, что не является по-настоящему ключевым элементом проекта. Тут хорошо помогают эксперименты по замене одних элементов на другие.
Например, вы делаете шутер. Попытайтесь представить, что будет, если ваш шутер перенести в палеолит, в XVI век или в магический мир фэнтэзи. Не оперируйте понятиями реализма - смотрите глазами игрока. Изменится ли в данном случае фокус игры? Если ответ - нет, значит, вы делаете что-то подобное Serious Sam, и упоминание сеттинга совершенно неважно. А вот если в вашем видении имеется в виду исторический шутер, например, времен Второй мировой войны, значит, при перенесении его в 16 век ваше видение игры исчезнет - ведь фюрер еще не родился. Это автоматически означает, что в фокусе должно быть сказано: шутер времен Второй Мировой.
Ужимайте текст фокуса до тех пор, пока не поймете, что избавившись от любого из оставшихся слов, вы потеряете в игре то, что, собственно, и является ее базовым элементом. Например, замысливая шутер от первого лица, нельзя выкидывать слово "шутер". В идеале фокус должен занимать абзац в три-четыре строки: его легко выучить, легко рассказать и процитировать на память коллегам.
Как уже отмечалось выше, именно в то время, когда никто еще не приступил к работе над проектом, пока не начал "гореть" бюджет, а маркетинговый департамент не начал пытаться влиять на содержание игры, нужно приложить максимальные усилия для создания "крепкого" гейм-фокуса.
Не распыляйтесь, пытаясь на данной стадии работ продумать весь набор фич, это можно сделать позднее, ведь сам по себе набор красивых элементов не так уж важен - он скорее будет развивать и дополнять в вашей игре самое главное.
Для того, чтобы понять, почему фичи строятся из гейм-фокуса, а не наоборот, попробуем проиллюстрировать это процесс.
Возьмем, например, игру Burnout 3. Составим список уже известных нам фич игры (здесь под фичами подразумевается не то, что пишут на коробках, а элементы для разработки), который будет выглядеть примерно так:
1. Езда в траффике
2. Ультраскоростная динамика
3. Агрессивно настроенные соперники
4. Разные режимы игры, практически всегда подразумевающие гонки (со временем, с соперником)
5. Система вознаграждений, построенная по принципу "рискни и получи... или потеряй"
6. Система повреждений и связанные с ней спецэффекты
7. Специальный "кинематографический" режим работы камеры (crash mode)
8. Уникальный игровой режим- катастрофа
Проанализировав контент игры, можно свести ее содержание к следующему гейм-фокусу: "Ультраскоростная рискованная езда на автомобилях".
Теперь, когда у нас есть фокус игры, для наглядности можно показать обратный процесс, от имеющегося гейм-фокуса к указанным ранее фичам.
Ультраскоростная езда предполагает решение основной задачи: воссоздание ощущения бешеной скорости. Это ощущение складывается из: а) Относительной скорости объектов статической и динамической геометрии, от насыщенности игры такими элементами, и б) От алгоритма работы основной камеры. Это означает, что трассы должны проходить там, где насыщенность объектами достаточно высока, например, на достаточно оживленных шоссе, а в идеале - в городах. Трассы в городах предполагают некие правила, которые создаются для того, чтобы уменьшить риск на дорогах. А ведь риск на дорогах - это как раз то, что нам нужно. Как известно, наибольшую опасность на дороге представляют собой динамические, а не статические объекты. Например, встречный или поперечный траффик. Значит, он должен присутствовать в игре. Чем еще можно увеличить риск на дороге? Присутствием агрессивно настроенных оппонентов.
Если разработчик хочет дать игроку азарт, он должен заставить игрока рисковать. Значит, нужно обеспечить соответствующий стимул. Обычно на риск на дороге идут в ситуациях ограниченного времени. Значит, нужно стимулировать игрока тем, что может сократить время, затрачиваемое на достижение цели (например, для взятия нового рекорда прохождения). Что сокращает время? Время сокращает скорость. Значит, надо вознаграждать чем-то, что дает больше скорости - а ведь мы помним, что наша игра "ультраскоростная".
Что является итогом риска на трассе? Авария. Но получается дилемма: если у игрока есть задача рисковать и выигрывать, авария является своего рода обломом. Как его избежать? Показать ее максимально красиво и завораживающе, чтобы зрелище само по себе было некоей сатисфакцией за провал. Плюс, если на трассе есть агрессивно настроенные соперники, игрок обязан иметь возможность воздействовать на ситуацию, а именно - бортовать, скидывать их с трассы и так далее. Тут зрелищный показ еще более желателен; это своего рода дополнительная награда игроку за произведенные действия. Но здесь возникает конфликт с ультра-скоростями: каким образом показывать аварии, организованные игроком, если наибольшее желание игрока - остаться невредимым и устроить аварию сопернику? Дело в том, что при аварии скорость игрока резко снижается, меняется траектория движения и так далее. Видеть свою аварию со стороны и сохранять управление своим болидом - это вещи прямо противоположные и малосовместимые. Значит, во время показа надо отбирать управление и каким-то образом сделать так, чтобы во время аварии он не чувствовал тревоги за то, что в этот момент происходит с его автомобилем. Решение: надо замедлить время, получив попутно замечательный кинематографический эффект катастрофы - slow-mo.
Чтобы катастрофы выглядели красиво, надо сделать их более или менее реалистичными - значит, нужно озаботиться системой повреждений и спецэффектов, потому что постоянный риск предполагает, что зрелище аварии будет довольно частым. Фактически, столь частым, что стоит подумать: а не давать ли игроку вознаграждение за особенно зрелищные и красивые катастрофы? А не сделать ли в конце концов вообще специальный и уникальный режим, в котором задача игрока - организовать наиболее эффектную катастрофу?
Как видим, все фичи игры логически вытекают из одной строчки гейм-фокуса.
Рассмотрим пример создания гейм-фокуса из замысла игры.
Итак, предположим, вас осенила идея проекта, в котором герой ездит на крутых снегоходах и сражается (не слезая со своего транспортного средства) с такими же, как он, гонщиками. Задайте себе вопрос: что конкретно кажется вам интересным в этой идее? Возможно, это приключения и путешествие по великим пустошам Северной Канады с воссозданием реализма трассы и управления? Не совсем.
В конце концов, вы понимаете, что просто-напросто сам по себе снегоход кажется вам (а значит, и игрокам) довольно любопытным и оригинальным средством передвижения; в вашем воображении снегоходы совершают головокружительные прыжки, умопомрачительные трюки, и все это без риска покалечиться, ибо безопасность - неотъемлемая характеристика игрового мира. Если это именно то, что вам нравится - реализм управления немедленно отходит на задний план: игрок получает удовольствие от передвижения и трюков на снегоходе.
Так как неотъемлемой частью вашей игры является управление именно снегоходом (попробуйте заменить его на мотоцикл и пропадет фан от управления "необычным" устройством), ваш фокус может начинаться фразой: "Базовый геймплей игры - управление скоростным снегоходом. Игрок может выполнять головокружительные прыжки и трюки, управление сбалансировано в сторону аркадности и увлекательности, а не реализма".
Предположим, в вашем видении также присутствует элемент боев на снегоходах. Вы представляете себе столкновения, кульбиты сбитых со своих транспортных средств гонщиков, уклоняющихся от пинков соседей, врезающиеся в деревья и взрывающиеся снегоходы. Вы можете задать себе вопрос: а почему гонщики сражаются друг с другом? Ответ: это совершенно неважно, потому что азарт битвы вам представляется значительно более важным, чем логическое объяснение происходящего. А значит, не нужно описывать в тексте гейм-фокуса причину происходящего.
Вы совершенно одержимы видением танцующих в смертельной схватке снегоходов и опасных гонок по снегу, однако вы прекрасно понимаете, что у игры, в которой много насилия, могут быть проблемы с издателями, которые не заинтересованы в сужении потребительской аудитории. Перед вами дилемма: "комбат" из песни не выкинешь, но издатель прав. Решение - ввести в текст фокуса положение о том, что насилие в игре будет подаваться в абсурдно-комическому манере. В итоге описание боевых элементов будет выглядеть так: "Азартные бои с соперниками на трассе; насилие представлено в максимально комедийном свете".
Что еще будет важным в описании вашего гейм-фокуса? Захотите ли вы реалистично передать поломки или расход топлива? Вряд ли. Захотите включить починку снегоходов в игру, и если да, то является ли она неотъемлемым элементом вашего видения игры? Тоже вряд ли. Причем "вряд ли" в данном случае совсем не означает, что в игре не будет починки снегоходов - напомню, что в гейм-фокусе перечисляются только те вещи, без которых игра перестает быть той игрой, которую вы себе представляете.
Будет ли игра трехмерной или двухмерной? Вообще-то, она может быть как 3D, так и в 2D, с точки зрения гейм-фокуса это не принципиально, так как этот момент скорее относится к области маркетинга. О соображениях коммерции можно подумать потом, потому что если на этом этапе вы будете думать обо всех осложнениях, вы никогда не сделаете того, что вы намереваетесь сделать.
Итак, пришло время объединить в одно целое езду на снегоходах и бои на снегоходах в коротком абзаце, которая и будет вашим гейм-фокусом. Примерно так:
"Базовый геймплей игры - управление снегоходами и зрелищные бои на них с возможностью исполнения головокружительных трюков и прыжков. Управление и битвы сделаны максимально аркадно и увлекательно, а не реалистично. Насилие в игре представлено в максимально комедийном свете".
Финальный шаг в закреплении гейм-фокуса - именование игры. Это очень важный момент. Помните, что ваш фокус будет предметом обсуждения - вы же не предполагаете, что люди будут называть вашу игру "идея, которая есть у Антона Петровича"? Помимо банального удобства, название игры несет в себе важную образную нагрузку. По самому большому секрету - в самом наиидеальнейшем варианте название игры может быть ее главным фокусом. Более того, одно только точное именование проекта может магическим образом построить весь процесс производства.
Так, например, было с культовой игрой "Thief: The Dark Project", которая по признаниям многих авторитетных специалистов была в свое время совершенно уникальным прорывом в индустрии. В постмортеме проекта главный дизайнер рассказывал о том, что в самом начале разработки - игра в то время именовалась Dark Project - команду носило из конца в конец, велись бесконечные эксперименты, но у всех при этом было неоформленное ощущение, что не хватает чего-то главного, чего-то стержневого, того самого core игры. Пока кто-то (видимо, в курилке) не сказал слово "thief". Ведущий дизайнер проекта, автор постмортема, восторженно пишет, что это был магический момент, когда весь фронт работ, все то, что нужно было сделать, на чем заострить внимание, вообще все, из чего должна была состоять игра, сложилось в цельную, логичную и внутренне непротиворечивую структуру.
Ваше рабочее название игры должно быть "цепляющим", но не стоит, заботясь о "запоминаемости", давать игре намеренно абсурдное имя.
Поэтому название "Snow Carnage Derby" будет верным для вашего проекта о снегоходах, а название Egyptian Rumba - нет.
Теперь, когда понятие фокуса разобрано на примерах, пора рассмотреть его функциональность и еще раз перечислить его качественные характеристики.
Основные функции гейм-фокуса - это:
1. Целеполагание - "что именно мы хотим сделать"
2. Координация и коммуникация - "мы все одинаково понимаем, что именно мы хотим сделать"; "любой из нас может передать гейм-фокус" кому угодно
3. Коррекция приоритетов - "мы знаем, что мы делаем в первую очередь, что во вторую, и знаем, чем можно пожертвовать, а чем нельзя"
Основные качественные характеристики текста гейм-фокуса:
1. Краткость. В процессе производства никто, кроме дизайнеров, не читает диздоки - это, увы, данность. Изменения в диздоках происходят едва ли не каждый день - зачем человеку, занятому на производстве, перелопачивать объемистый талмуд, если завтра он изменится? Одно выяснение, последняя ли это версия документа, может отнять кучу времени. Всем членам команды необходимо знать, что гейм-фокус - это первые пять-десять строчек диздока, а все остальное - это всего лишь более детальное и развернутое его описание.
2. Ясность и однозначность прочтения. Специфика восприятия любого текста заключается в том, что понимание рождается из взаимодействия текста и того, кто этот текст читает. Иными словами, то, что может быть понято не так, обязательно будет понято не так. Одна из основных функций гейм-фокуса - обеспечить полное и абсолютное согласие в вопросе "что за игру мы делаем", поэтому следует избегать двусмысленностей и недомолвок; текст должен быть однозначным. Например, нельзя писать: "действие игры разворачивается в красивом мире" - у всех очень разное понятие о красоте. Не допускайте разночтений, многократно проверяйте каждое, абсолютно каждое слово в тексте. Любая осложняющая понимание конструкция должна быть предана безжалостному редактированию. Никаких "возможно", "старается", "может быть", "примерно" и других неясностей.
Пример 1 (неудовлетворительный текст гейм-фокуса):
"Одним из важнейших элементов игры является история героя, намеревающегося спасти мир путем интерактивных взаимодействий с многочисленными врагами".
Почему "одним из элементов"? А где другие? Слово "является" кажется лишним, может, от него можно избавиться? Вы уверены, что "история" - это именно то, что заслуживает упоминания в вашем фокусе, или вам просто нравятся драки? Спасти мир? Или все-таки родную деревню? Или родных - так ли принципиально, что или кого именно спасает герой с точки зрения главных элементов игры? А может быть, он завоевывает планету? А есть ли в игре эти загадочные "интерактивные взаимодействия"? Не слишком ли сложно для описания драк?
В результате, возможно, фраза, приведенная выше, превратится в Пример 2, удовлетворительный текст гейм-фокуса:
"Центральный элемент игры - зрелищный и динамичный файтинг с врагами".
Как сказано в предисловии, этот материал может оказаться полезным не только для геймдизайнера. Я уже заметил выше, что понимание вашего гейм-фокуса рождается при взаимодействии текста и, например, арт-директора. Возможно, вам повезло, и ваш арт-дир на интуитивном уровне знает, как правильно "читать" и "разворачивать" гейм-фокус, и ему сразу становится понятно, какой именно должна быть стилистика и визуальное представление проекта. А что если это не так?
Сейчас мы попробуем для примера прочитать, развернуть и трансформировать гейм-фокус в конкретные задачи для конкретных участников проекта. Представим себе, что это первое заседание, на котором вы представляете свой фокус. Для краткости положим, что идея игры и ваш текст вдохновили участников команды, и все они согласились участвовать в проекте. Осталось выяснить только, с чего начать и во что конкретно ваш замечательный гейм-фокус будет воплощаться.
Для начала попытайтесь визуализировать, отталкиваясь от текста, что конкретно происходит на экране. А там, если вы помните наши снегоходы, происходит скоростная езда на этих замечательных машинах и зрелищные бои между гонщиками. Отсюда логически вытекает масса совершенно конкретных вещей. Например:
* Основная камера игры - от третьего лица (сверху-сзади) - скоростная езда автоматически подразумевает хороший угол обзора пространства впереди. Бои должны быть зрелищными, а потому сложно представить их себе от первого лица - иначе игрок не увидит противников сбоку (задача для программистов)
* Основной упор в производстве игровых моделей и анимаций ложится на снегоход и гонщика - это то, что игрок видит 90% игрового времени. Снегоход должен быть привлекательным, он должен блестеть и вообще производить впечатление очень дорогой игрушки. Первичный приоритет в анимации делается на гонщике - нужно, чтобы он выполнял зрелищные трюки и умел вести "бой" (задача для моделлеров, арт-директоров, аниматоров)
* Снегоходов должно быть несколько - игроки любят разнообразие, значит, нужно дать им возможность выбора из нескольких моделей (задача для моделлеров, арт-директоров)
* В игре используется природный ландшафт - точнее, зимний ландшафт. Тут все очевидно, однако не стоит забывать, что элементы "очеловечивания" на трассах должны присутствовать, иначе где же веселье от проезжания насквозь маленьких туристских домиков, где забавные "срезки" через расставленные на снегу шезлонги для зимнего загара? Иными словами, внесение элементов цивилизации в девственные канадские, например, горы даст вам больший инструментарий для того, чтобы езда на снегоходах на самом деле превратилась в захватывающую гонку. Большое внимание следует придать эффектам снега, в особенности снежным шлейфам и завихрениям, которые передают скорость (задача для левел-дизайнеров, разработчикам спецэффектов, арт-директора)
* Снегоход должен быть скоростным - время подумать об окружающих объектах, о звуке двигателей, работающих на пределе, об эффекте motion blur на предельных скоростях, об алгоритме камеры, передающей ускорение и торможение. А раз все происходит на огромной скорости, значит, можно обсуждать технологию моделирования и рендеринга трасс (ответственные - программисты, левел-дизайнеры)
* Бои должен быть зрелищными - значит, действия AI оппонентов будут разнообразными - они должны, во-первых, пинаться, подрезать, толкаться, а во-вторых, опрокидываться, смешно повисать на ветках деревьев и врезаться в деревья. Снегоходы должны эффектно взрываться, переворачиваться, биться об камни, высекая тучи искр... Зрелище может акцентировать камера - стоит подумать, как подать действо в наиболее выгодном свете (ответственные - геймдизайнеры, камера-дизайнеры)
Подобная процедура, как вы уже догадались, весьма скоро приводит к созданию скелета диздока. Что гораздо более важно, процедура "конкретизации" гейм-фокуса позволяет создавать этот документ структурированно, то есть, сначала - главное, а потом - второстепенное.
И еще я забыл отметить, что на вашем первом заседании должен присутствовать руководитель проекта, важная обязанность которого - планировать будущий проект по ресурсам и человекочасам. Когда руководитель еще до старта работ знает, что в его игре важно, а что нет, он никогда не поставит студента на написание искусственного интеллекта, в то время как самому гениальному AI-программисту конторы будет поручено изобретение технологии колышущейся травы. А ведь как легко представить случай, когда программист не прочитал дизайн-документа и поэтому не знает, что дело в игре происходит преимущественно зимой, а еще он перепутал траву с кустарником, который появился из-за желания паблишера, который, в свою очередь, в глаза не видел текста гейм-фокуса, но захотел большего визуального разнообразия. А руководитель проекта не попер против воли паблишера и подписался под его требованием, выделив на эту работу того, кто может заниматься вещами куда более важными (с точки зрения гейм-фокуса).
Фокусировка, рефиксация и изменение фокуса
Создание гейм-фокуса - это только первая часть работы. Вторая, и, возможно, гораздо более сложная часть - его поддержание, неизбежные "рефиксации", а иногда и установка нового гейм-фокуса. Поддерживать фокус - это значит постоянно следить за тем, чтобы все работы на проекте велись в соответствии с ним, и все приоритеты расставлялись в соответствии с ним же. Это рутинная и не очень благодарная работа должна вестись геймдизайнерами постоянно - напоминать и отсылать к гейм-фокусу нужно настолько часто, насколько это кажется вам необходимым. Причем лучше делать это не после замеченных отклонений от избранного курса, а регулярно - чтобы постараться свести к минимуму саму возможность их появления.
Обычно в процессе разработки первоначальный замысел игры постоянно трансформируется под влияниям разнообразных факторов - начиная с технологических затыков и заканчивая паранойей издателей. Основная задача в этом случае заключается в анализе того, каким образом изменения затрагивают гейм-фокус. Если изменения его не касаются - все в порядке. В противном случае надо проводить работу по "рефиксированию". И какой бы занудной она ни казалась, это лучше, чем попытки бессистемного перепахивания всего диздока. Кроме того, лучше сменить фокус, чем допустить фатальные ошибки на стадии производства, когда вся команда продолжает работать в русле установленного видения и в один прекрасный момент выясняет, что изменения, внесенные в дизайн месяц назад, реально конфликтуют с ним.
На одном из последних проектов нашей студии произошел классический случай "потери фокусировки" со всеми вытекающими из него последствиями - технологическими проблемами на финальной стадии производства и неудовлетворенностью паблишера конкретными аспектами игры. Впрочем, говорить о "потере" фокуса в данном случае не совсем корректно, так как мы не использовали описываемую здесь методику. Речь скорее о том, что ошибок можно было бы избежать, если бы мы следовали простым рекомендациям, которыми я сейчас с вами делюсь.
Суть игры, находившейся у нас в производстве, состояла в езде на мотоциклах по городу и в выполнении разнообразных заданий (практически все они предполагают езду на скорость). Платформа - PS2. На этапе производства "от демо к игре" паблишер решил, что нам недостает визуального разнообразия - "части города одинаковы, а требуются разные по стилистике районы". Так как требование исходило отчасти от Sony, спорить с ним было довольно глупо. Поэтому мы начали бороться за разнообразный вижуал. Боролись, в основном, с помощью улучшенного текстурирования геометрии и увеличения количества объектов в кадре.
Надо сказать, что при невеликой памяти PS2 моделирование города автоматически подразумевало динамическую подгрузку локаций. Город был поделен на загружаемые сектора, и была выработана схема, загружающая/выгружающая из памяти сегменты в зависимости от траектории движения игрока по уровню. При этом понятно, что чем быстрее едет игрок, тем быстрее должна производится подгрузка, а значит тем "легче" по памяти должны быть сегменты.
Понятно-то понятно, только вот в борьбе за визуальные красоты мы как-то упустили этот фактор. Внешний вид города, конечно, значительно улучшился и стал более разнообразным, да вот только скорость игрока пришлось серьезно ограничить (иначе сегменты просто не успевали загружаться), а рендеринг большого количества объектов в кадре сильно повлиял на fps, который также напрямую влияет на динамику езды.
В результате вместо одной проблемы мы получили две: во-первых, издатель был крайне недоволен потерянным "ощущением скорости", а во-вторых, программисты провели немало бессонных ночей, воюя с fps - количество объектов в кадре серьезно калечило рендеринг. Не говоря уж о том, что расчудесные виды города с великим множеством тщательно смоделированных объектов в игре, где одно из главных условий - ехать как можно быстрее и не совершать на дороге ошибок, фактически остаются вне поля зрения.
Всего этого можно было бы избежать, если бы в тексте гейм-фокуса была бы фраза "скоростная езда на мотоциклах по городу". И анализ требуемых издателем изменений был бы проведен с учетом влияния изменений фокуса. Принимая во внимание все факторы, мы вряд ли бы избрали экстенсивный метод улучшения "вижуала".
Случается и так, что в процессе разработки игры по каким-либо причинам приходится менять гейм-фокус. В этом случае простым изменением текста не отделаться, надо тщательно проанализировать все разделы диздока и произвести соответствующие правки.
Дополнительные функции гейм-фокуса
В рассмотренном нами примере речь шла о ситуации, в которой игра является собственной разработкой девелоперов. В жестоком мире, где правят лицензии (особенно это касается разработки игр для консолей) и "симсы", очень часто бывает так, что "заказ на игру" спускает паблишер. Если кто-либо из сотрудничающих сторон не очень понимает, что собственно хочется сделать - да-да, на самом банальном уровне отсутствие гейм-фокуса чаще всего обозначает, что люди, разрабатывающие игру, сами не понимают, чего они собственно хотят - это еще полбеды. Хуже всего, когда ни заказчик игры, ни ее разработчик не понимают, чего они хотят от конечного продукта. Тогда начинаются долгие обмены материалами по сценарию: "сделайте что-нибудь, только сделайте, а там мы посмотрим". Вот как это происходит:
Заказчик: Нарисуйте нам скетчи, разработайте стилистику... или несколько...
Разработчик: Интересно, чего они хотят... а что там у нас типа в стилистике лицензии - мультфильм? Ну давайте нарисуем им что-нибудь мультипликационное (рисуют, отправляют заказчику).
Заказчик: Все вроде нормально, но что-то не нравится...
Разработчик: А что конкретно не нравится?
Заказчик: Ну, так просто не объяснить, но вы постарайтесь еще подумать.
Проходит две недели...
Разработчик: Вот, еще нарисовали. Отсылаем.
Заказчик: Все хорошо, но все-таки что-то не так...
И так далее, причем это касается не только стилистики, но и всех, абсолютно всех аспектов игры.
Описанная ситуация абсолютно реальна. В итоге получается "какая-нибудь" стилистика для "какой-нибудь" игры, возникают бесчисленные сложности с запихиванием геймплея в это стилевое решение, и в лучшем случае проект получается весьма средним, то есть, как говорится, ни о чем.
Если же хотя бы одна из сторон придерживается концепции гейм-фокуса, она может хотя бы попробовать объяснить свою позицию; кроме того, обладая закрепленным гейм-фокусом, паблишер или девелопер может выстраивать коммуникацию, используя аргументы, отсылающие к тексту фокуса.
Понимание того, что гейм-фокус является осью и инструментом для выбора производственных приоритетов, может быть использовано, например, при отсмотре так называемых референсных материалов. Потому что очень часто бывает так:
Фокус проекта - скоростные гонки на мотоциклах по городу.
Lead-game designer: Программистам нужен визуальный референс для создания дыма из глушителя мотоцикла. Какие идеи будут, где видели?
Дизайнер: В GTA есть дым от глушителя в мотоцикле, давайте его дадим как референс.
После этого программисты смотрят на референс и делают дым. Когда вы видите его на экране, то понимаете, что он какой-то, мягко говоря, некачественный, хотя визуально точно соответствует тому, что ваши сотрудники видели в GTA.
Весь материал взят с сайта: http://www.dtf.ru/