Статья написана на основе доклада, сделанного на КРИ-2005.

Вместо вступления

Большинство начинающих геймдизайнеров совершают множество типичных ошибок при проектировании и разработке проектов, представлении их издателю, сдаче этапов и версий. Некоторые из этих ошибок лежат на стыке креативных областей деятельности и менеджмента, и поэтому лучше видны со стороны компании-издателя.

Цель статьи - рассказать о серьезных ошибках дизайнеров при разработке игр в России, основываясь на своем непосредственном опыте, опыте коллег, общении с разработчиками на форумах и в приватной переписке. В качестве примера используются реальные случаи, без указания конкретных проектов и имен, разумеется.

Надеюсь (если мне придется работать с кем-то из читателей), что вы избежите описанных ниже довольно очевидных ошибок. Статья ориентирована на совсем начинающих и молодых геймдизайнеров, так что не ждите каких-то великих секретов и тонкостей мастерства.

Точка невозвращения

Кто же этот страшный зверь геймдизайнер, нахально занимающий место жизненно необходимого команде аниматора или программиста?

* Геймдизайнер - дитя свободы, мама идеи и папа концепции, страшный бич программистов, покорный раб бюджета и неизвестный герой толпы
* Геймдизайнер создает путь игры от туманной идеи до жестко детализированного списка всех возможностей всех элементов игры
* Геймдизайнер - первый бетатестер проекта, когда тот существует только в его голове
* Геймдизайнер - незримый стержень и душа проекта
* Геймдизайнер - носитель Идеи и ее архивариус

Некоторые могут не согласиться с приведенными определениями, но общая идея совершенно понятна. Времена, когда игры создавались фанатиками-одиночками, прошли. А значит, недостаточно идею придумать, ее надо передать, объяснить, обосновать, расписать (и продать). Родной язык и четкая логика - вот два инструмента геймдизайнера. В принципе это все, что требуется геймдизайнеру. Но не помешают, конечно, богатая фантазия и большой игровой опыт.

Что делает геймдизайнер? Вкратце - он видит, слышит и чувствует игру в своем воображении. Он может "поиграть" в нее еще до написания первой строки кода, без моделей, без интерфейса и вообще без наличия компьютера или консоли. "Поиграв", он оценивает интересность, реализуемость и востребованность идей, витающих в его сознании. Дальше он садится и документирует Идею. Для себя - чтобы не забыть, не упустить чего-то важного, увидеть возможные проблемы и нестыковки с другими идеями. Для команды - чтобы они делали одну и ту же игру, а не каждый свою (и чтобы они вообще делали игру, а не занимались исследованиями или страдали фигней). Для заказчика/издателя - чтобы он не пугался неизвестности, верил в доброе и вечное и не зажимал финансовые средства.

Из документированных идей геймдизайнер строит домик, а хороший геймдизайнер - целую крепость. Желание светлой стороны геймдизайнера - сделать самую крутую игру всех времен и народов, цель темной - сделать игру в полном соответствии с заданной идеей, с заранее определенным геймплеем, без неожиданных проблем и сюрпризов, сделать то, что запланировано, а не то, что хочет светлая сторона.

В широких геймдевелоперских массах популярно мнение вроде "мы все в игрушки с пеленок играли, мы же не идиоты, мы знаем, как игры делать, или уж, по крайней мере, какими их НЕ стоит делать. Зачем нам кормить дармоеда-геймдизайнера, лучше еще одного программиста нанять". Примеры таких игр, единицы из которых доживают до релиза, ищите в любимых журналах, "мегаотстой тысячелетия" - это, скорее всего, оно.

Ошибка номер раз

Анамнез: Отсутствие целостного видения игры, понимания общей идеи и всей вертикали замысла до самых низов.
Отсутствуют: Концепт, Feature list, Vision
Решение: Написать концепт, Feature List и Vision.

Самая распространенная проблема - отсутствие понимания сути происходящего. Делали стелс-шутер - получилась RPG от третьего лица. Делали пошаговый варгейм - вышла RTS. И хорошо, если вообще что-то получилось. А то очень часто бывает, что художники и программисты дружно отчитываются о проделанной работе за истекший период, все идет по плану, сдаются майлстоуны и промежуточные версии - но играбельного ничего нету. А если оно и играбельно, то слабо похоже на конкурентоспособный продукт.

Главная причина - отсутствие согласованного, одобренного и принятого за основу концепта игры, доведенного до каждого члена команды, целиком одобренного издателем и являющегося базисом всего препродакшена и дальнейшего дизайна, когда у каждого участвующего в разработке человека видение игры стараниями ведущего геймдизайнера примерно одинаково.

Более того, в отдельных случаях команда принципиально не хочет делать вижен/концепт, потому что "может получиться совсем не то, что задумывали вначале". О чем они с совершенно спокойным видом и сообщают издателю.

Никогда не поздно написать концепцию. Я знаю проекты, концепция которых и менялась по ходу разработки, и просто отсутствовала. Требовалось сесть и жестко определить рамки проекта раз и навсегда. Через год, через два, через три после начала разработки. В любом случае это надо сделать, чтобы проект завершить.

Ошибка номер два

Анамнез: Дизайн "снизу вверх" убивает время и ресурсы. "Концепция изменилась" - и все детали надо писать заново.
Признаки: Отсутствует спецификация жанра, общего геймплея, аудитории, при этом наличествует около двух мегабайт описания юнитов вплоть до цвета подкладки одежды в разных условиях.
Решение: Принятый порядок в геймдеве - от идеи через концепт к диздоку и детальному описанию.

Это проблема наличия отсутствия леса за тремя соснами, проявляющаяся, к примеру, в виде мегабайтных таблиц характеристик юнитов при невнятно сформулированной цели игры.

Философский вопрос "что лучше - от общего к частному или от частного к общему" оставим в стороне, но сложившийся производственный процесс в индустрии таков, что двигаться необходимо все же сверху вниз. Ваши замечательные описания сеттинга и таблицы юнитов никого не интересуют без четкого понимания жанра игры, ее особенностей, отличий от конкурентов.

Зачастую геймдизайнера увлекает одна часть игры, например, правила расчета боевки. За нее он берется со всей душой, месяцами строит гигантские таблицы, выверяет формулы и добивается полной реалистичности. И иногда даже (о чудо!) может все это донести до программистов. Остальные части игры при этом находятся в подвешенном состоянии, и команда вообще не в курсе, что за проект она делает.

Детализация, несомненно, нужна, но на другом этапе разработки, а не на самой ранней стадии. Ваши многотомники сочинений просто никто не будет читать, как и воспринимать их всерьез без верхушки пирамиды, без идеи игры. Потому что если, как в том анекдоте, "концепция изменилась", месяцы трудов просто пойдут коту под хвост.

Совет простой - дизайните сверху вниз. Особенно если у вас не заказной проект, где фишка именно в аутентичности деталей, и если у вас еще нет издателя и железобетонной уверенности, что ваша игра нужна рынку.

Ошибка номер три

Анамнез: - Мы подумали и решили, что пора сделать фичакат... - Тогда вы останетесь без геймдизайнера!
Признаки: Фишечки к фишечкам, рюшечки к рюшечкам, специальные возможности к специальным юнитам, отдельным картам и так далее. Общее правило и сотня исключений, которые, разумеется, делают игру красивее, реалистичнее, оригинальнее, интереснее.
Решение: Фичакат - друг наш, а не враг. Идеально структурированный дизайн допускает страшное надругательство над собой без потери целостности игры и необходимости полного редизайна.

Обычно предложения "выкинуть и вырезать" встречаются разработчиками в штыки. Как же так, кромсать их любимое детище, мегапроект тысячелетия, надругаться над идеалом и самым прекрасным! Не позволим! Лучше мы по чуть-чуть, но всего сделаем! Иначе получится клон!

Здесь кроется сразу несколько ошибок и заблуждений, попробуем с ними разобраться. Итак, первое - законченная и выпущенная игра лучше незаконченной и закрытой. Надеюсь, это понятно всем и каждому. Проект может быть сколь угодно масштабным, новаторским и революционным, трижды канонизированным толпой ожидающих фанатов и заочно признанным победителем всех грядущих Е3 - но пока он не вышел, все ваши ожидания и надежды не стоят ни-че-го. Ноль. Зеро.

Второе частое заблуждение - лучше больше, но по чуть-чуть. Как же так, резать наши замечательные идеи! Мы их обязательно доделаем, в сиквеле, но без них совершенно никуда, проект просто не будет жить, мы же всем обещали - журналистам, фанатам, мамам и папам! И что о нас подумают люди? Правильный ответ: если в игру будет интересно играть - люди подумают хорошо. И точка.

Третье заблуждение - ах, как же так, если вырезать нашу гениальную фичу, то рухнет все, придется полностью переделывать! Ну, для начала, никто в здравом уме основополагающую фичу вырезать не будет, - например, вряд ли кто-то всерьез решит сделать из трехмерного шутера плоский квест. А вот индикатор здоровья, к примеру, из 3D-экшена выкинуть - запросто. Ну и что, что у всех есть - а в данном проекте какая его функциональная роль? Никакой? Ну и под нож его, вместе с аптечками.

Фичакат помогает:

* Закончить игру
* Сделать это в заданный срок и бюджет
* Уточнить позиционирование игры

В целом - если дизайн проекта построен правильно, пирамидально, то можно отрезать целые ветки фичей без потери общей играбельности. Из RTS убирать воздушные и подводные юниты, из RPG - щиты и скилл воровства, и при этом проект останется играбельным. Если все фичи представляют собой дерево, то отрезание отдельных веток оно переживает хорошо.

Насчет самого процесса выбора фичей и построения фичалиста есть много мнений, которые не раз звучали в лекциях на всех КРИ - это отдельный глубокий вопрос, который мы здесь не рассматриваем.

Ошибка номер четыре

Анамнез: Все знают, что Fallout - это мегакруто. Мы сделаем также.
Признаки: Нездоровый блеск в глазах, послужной список от начала времен и Atari 2600, наличие железобетонного мнения о том, чего хотят игроки. В лице друзей, разумеется.
Решение: Краеугольный камень всего геймдизайна - поиск фана. Фан - единственный критерий оценки геймплея. Игра Нашей Мечты™ - вселенское зло.

Это круто. Это реалистично. Этого еще ни у кого не было. Это так же, как в той клевой игре всех времен и народов. Это похоже на реальную жизнь. Это как в кино. Это было у всех. Наши тестеры считают, что это круто. Так диктуют современные тенденции жанра. Не хватает только "это готично" и "афтар жж0т".

Почему-то большинство дизайнеров вопрос "А чем именно все это будет интересно игроку?" воспринимают как плевок в лицо и личное оскорбление. И не способны внятно и адекватно объяснить, почему вот эта крутейшая фича вызовет интерес и улучшит геймплей. Ну как же так, это же очевидно, что будет мегакруто.

Беда многих геймдизайнеров и команд в целом - они делают игру для себя, Игру Их Мечты™, не задумываясь о предполагаемой аудитории и интересности геймплея. Игнорируя мнения издателя, они куют свою прррелесссть. Часто - с плачевным результатом.

Стандартная ошибка - слепая вера в какой-то принцип. Например, в реализм - якобы "все, что реалистично - хорошо". Не задумываясь, например, что игроку хватает реалистичности в настоящей жизни. Вера в "тех же щей, да побольше" - вот есть успешный продукт икс, а мы возьмем все то же, только побольше, побольше, и загребем миллионы. Много рас, много юнитов, сотни атак, тысячи анимаций. Но почему игроку будет интересно ровно то же самое, только под вашей упаковкой - тайна за семью печатями.

Главный критерий оценки в работе геймдизайнера - удовольствие игрока. Не надо прятаться за фразами "а вот также было в игре икс", не объясняя, почему в вашей конкретной игре будет также интересно, и уж точно не стоит подменять интерес реалистичностью или чем-то другим.

Ошибка номер пять

Анамнез: Дизайнер-программисту: - Нам нужен поиск путей. Сделаешь? - Да, за недельку.
Признаки: Неумение выдавать функциональное ТЗ остальным членам команды.
Решение: Программист всегда дизайнит неправильно. Это аксиома. Дизайном занимается геймдизайнер.

Рассмотрим две чисто теоретических ситуации. Первая: лид-дизайнер сообщает главному программисту: "Нам нужен поиск пути". Вторая: тот же дизайнер говорит: "Нам Нужен асинхронный поиск пути с учетом карты проходимости и разницы высот, с выдачей принципиальной возможности проходимости не более чем за 50мс и поиском пути между любыми точками трех тестовых карт не более чем за 300мс. Учитываются геометрические размеры объекта и коллизии. Учитывается возможность и радиус поворота юнита".

Внимание, вопрос - в каком из этих двух случаев получится более играбельный результат?

Аксиома о программистах: Программист всегда дизайнит неправильно.

Не перекладывайте свою работу на чужие плечи. Функционально задачу ставит геймдизайнер, а программист ее реализует. И это правильное разделение труда. Помните - программист думает абстракциями - алгоритмами, методами, фишками и пальцАми на RSDN. Задача геймдизайнера - поставить ему функционально четкую, определенную, проверяемую задачу.

Да, надо заметить, что и обратное верно - геймдизайнер не всегда знает, как правильно реализовать свои же идеи. Навязывать какие-то алгоритмы или методы - не самое мудрое решение.

Я много раз слышал фразу: "Ну откуда я знаю, как программисты сделают? Как сделают, так и будет работать". Как будет - понятно, см. аксиому. Такое заявление - роспись в собственной некомпетентности. Работа геймдизайнера и состоит в том, что он создает образ игры в голове, образ настолько красочный и звучный, что можно почувствовать все взаимосвязи, задачи и тонкости проекта. И сформулировать в диздоке словами все необходимые компоненты этого пока виртуального шедевра.

Детализация проектной документации должна быть выполнена минимум до такого уровня, как указано в примере. По этим граблям прошлись десятки, а может быть, сотни команд - сэкономленный на дизайне месяц стоит десяти на этапе массового производства.

Ошибка номер шесть

Анамнез: Концепт-документ проекта напоминает рекламную паузу на телевидении.
Признаки: "Великолепная графика и потрясающие воображение звонкой феерией радуги и буйством сладких цветов спецэффекты заставят игрока завороженно смотреть на экран, как кролик на удава".
Решение: Мы не в пустыне, нам вода не нужна. Проблема необходимости функционального, а не художественного описания игры.

Пример немного утрированный, но в каждом втором диздоке я читаю подобную графоманию. Всегда возникает вопрос - для кого это пишется? Нет, я вовсе не против, чтобы дизайнер так сенсорно-конкретно представлял себе игру, это здорово и необходимо для качественного дизайна. Но концепты и диздоки служат совсем иной цели, и не надо заливать их килобайтами описаний зомбимутантов и звуков новейших лазерных винтовок.

Если корабль предназначен для поражения вражеских подлодок, то так и пишите, буквально. Не надо слов "этот бесшумный охотник крадется в глухой ночи тихо переливающегося моря. Опасный и смертоносный призрак-убийца подстерегает свои быстрые, но громоздкие и уязвимые подводные жертвы".

Диздок - не художественный документ, а логически-описательный. Тем более это верно для концепта, предназначенного для широкого круга читателей, обычно деловых и занятых. Не надо заливать их словесной... водой.

Ошибка номер семь

Анамнез: Дома в ящике стола у дизайнера лежит незаконченный роман о вторжении инопланетян, четыре рассказа по мотивам Фоллаута и восемь зарисовок о сражениях с драконами. О своих художественных способностях отзывается скромно: пишу для себя, не публикуюсь.
Признаки: Подмена функционального интереса художественно-описательным.
Решение: Сценарий - обертка функционала. Оркогоблины, мамонт-танки, истребители - это скины для "управляемого юнита". Обертывание голой функциональности игры конкретными сеттингами (или лицензиями) - не проблема, если ключевой геймплей интересный и продаваемый.

Эта ошибка похожа на предыдущую, но на самом деле концептуально другая. Я говорю о подмене функционального интереса геймплея художественно-описательным. Сравните "игрок управляет персонажем-вором, скрытно перемещающимся по трехмерному уровню. Ориентируясь по миникарте и подсказкам игры, он с помощью специальных умений нетривиальным для простого взломщика способом крадет артефакт и незаметно уходит из здания ". И "известный домушник Михалыч вновь пошел на дело. О широко разрекламированной экспозиции бриллиантов он знал давно. Застарелые навыки и верная карта привели его прямо к сияющему как маленькое солнце камушку. Который и был тут же экспроприирован. Тайваньский босс будет доволен. Михалыч достал трубку и набрал номер..."

В чем ошибка? Предполагается, что игроку интересен Михалыч и его тайваньский босс, а не трехмерный шутер с аркадными элементами. Функционал и художественность, диздок и сценарий - вот в чем разница. Это два различных документа, не надо их смешивать.

Концепция может легко измениться. Вот представьте, приносите вы издателю демку, а вам говорят "геймплей клевый, но только орков надо заменить на пехотинцев, слонов на танки, а главным героем сделать не эту ушастую тварь, а Адольфа Гитлера. Такую игру мы продадим". Это если у вас есть интересный геймплей. А если у вас есть только второсортная фантастика про нашествие зомбимутантов из соседней галактики... Увы и ах, но вы самое слабое звено, прощайте.

Рассматривайте геймплей абстрактно. Если игроку может быть интересно манипулировать условными квадратиками, единицами товара, врагами под номером 1, 2 и 3 - то, обернув этот функционал сценарием, можно сделать только лучше. Если вы делаете ставку на сценарий - будьте готовы понять простую истину: игрокам больше нравится геймплей, а не сторилайн. Да, есть исключения, но они лишь подтверждают правила.

Например, по моему личному мнению, Planescape: Torment - геймплейно-заурядная RPG, да еще по нудным D&D-шным правилам. Но сюжет и сценарий - сказка!

Сценарная часть - важна. Играть в белые кубики будут только гики-фрики, да и то немногие. Но на самом-то деле все играют как раз в кубики, залитые словесным и графическим соусом. Наглядный пример - тенденции к падению популярности клонов игр, когда приедается сам геймплей, несмотря на новую обертку.

Ошибка номер восемь

Анамнез: 800-страничный диздок.
Признаки: Проблема планирования дизайна GUI и связанная с ним проблема изготовления ресурсов игры. Интерфейс перерисовывается по пять-десять раз по ходу проекта.
Решение: Некоторые элементы игры, например GUI, трудно задизайнить в финальном качестве до наличия хорошей игровой демо-версии, и это нормально. Просто запланируйте работы по дошлифовке.

Также иногда встречаемая крайность - описание ВСЕГО. Это как физические теории ВСЕГО, пытающиеся охватить и объяснить ВСЕ на свете. В отличие от ошибки номер два, когда дизайн сосредотачивается на одном элементе, такие проекты могут навсегда застрять в стадии препродакшена. В том числе такая ситуация возникает из-за страха перед издателем или точки зрения, что описывать нужно действительно ВСЕ.

Так вот, развенчиваю мифы. Издатель тоже ориентируется по уже упомянутой мною (и неспроста!) пирамидальной структуре разработки игры. Ему не нужно сразу описание ВСЕГО до последней иконки. Более того, издателю оно может не понадобиться вообще. Это вопрос политики, опыта и доверия команде, в которые я лезть не буду, но отмечу другое - концепция может измениться.

Мы все понимаем, что нельзя предсказать абсолютно все. Что возможны ситуации, когда хорошо выглядевшая на бумаге фича оказывается слабенькой и ненужной. Такие случаи бывают даже у хороших геймдизайнеров с мировым именем.

Есть субъективные факторы, требующие экспертной и статистической оценки, и которые сама команда разработчиков часто не в состоянии определить. Часто им не хватает опыта - например, бывает проблемы производительности, которые сложно было предсказать в начале проекта и которые не решаются оптимизацией.

Существует также немаловажный фактор издания игры за рубежом, когда в нее могут вноситься значительные изменения (здесь полезно вспомнить пункт про правильное построение дизайна и дружественный фичакат).

Есть традиционно слабые места - например, интерфейс. Я не знаю ни одного проекта, в котором интерфейс не переделывался бы с нуля менее двух раз. Потому что нет гениальных дизайнеров, все мы люди.

Резюме: Не надо паниковать и впадать в крайность описания ВСЕГО и сразу.

Топик номер девять

Мысль вслух: Что лучше - набросок кучи мегаидей или детальная документация на типичный клон?
Особенности: "Клон или Ррреволюция - holy war go on!"

Ближе к концу статьи я подхожу к философским вопросам, не являющимся такими уж строгими ошибками. Это, скорее, поводы для размышлений. Один из таких вопросов - противопоставление креатива и педантичной детализации. Что лучше - пара звучных, революционных идей с туманными перспективами, или детальное описание опробованных и работающих методов?

Что вообще лучше, Клон или Ррреволюция? Не вдаваясь в разжигание девелоперско-издательской вражды, отмечу - а многие ли из желающих сделать что-то новое действительно могут это сделать? Не авторско-элитарное произведение "для себя", с налетом богемности и немассовости, а действительно интересный миллионам игроков инновационный продукт? А ведь даже у маститых геймдизайнеров вроде Питера Молинье не всегда получается порождать жанры и ломать устои...

Я еще раз хочу обратить внимание на четвертую ошибку, в которой говорилось о поиске фана. Большинство ррреволюций, с которыми сталкивался я, были основаны ровно на одном принципе - "этого еще нигде не было, и поэтому будет круто!" Вот не было еще нигде 50 видов ресурсов - а у нас будет! Вопрос, почему это интересно игроку, вызывает ступор и обиду. Ну как же, это же круто, этого нигде не было, ты что, мальчик, не слышишь очевидного? Увы, это ситуация, близкая к реальности.

Вопрос документированности (безотносительно революционности) всегда волнует издателя. Бесспорно, чем лучше документирована игра, тем меньшие риски она содержит. И чем полнее расписана ваша ррреволюция, тем больше у нее шансов быть понятой. Только понятой, а не принятой, одобренной и оплаченной. Но понимание - это уже шаг вперед.

Топик номер десять

Некоторые субъективные мысли о заблуждениях насчет качества игр, казуальности, отсутствия инноваций и о том, "как тяжело стало жить".

Термин "казуалы" в его общепринятом в узких девелоперских кругах значении придумали бездарные и неопытные геймдизайнеры, для которых интересность прямо пропорциональна сложности. Они не хотят считаться с людьми, проводящими за компьютером или консолью не больше пары часов в неделю, но при этом мнят себя прожженными геймерами и вообще полубожествами. К счастью, это лечится - провальными тиражами и наградами "отстой тысячелетия".

Казуально - не означает "только для идиотов". Казуально - это так просто, что будет понятно всем, в том числе и "идиотам". И сделать сложные вещи простыми, легко управляемыми, элементарно понимаемыми - задачка не для средних умов. Это как написать ознакомительный курс ядерной физики для домохозяек. :-)

Понятно, что раньше и пиво было крепче, и травка зеленее. И игр было меньше, конкуренция слабее, аудитория умнее и бюджеты скромнее. И вообще, в наше время туго живется нашему брату геймдевелоперу. Но можно посмотреть на эту ситуацию как на естественный отбор. Планка качества и востребованности проектов растет, и вместе с ней неизбежно отсеиваются слабые звенья. Можно ведь трезво и честно взглянуть на ситуацию, и попытаться понять - может быть, дело не в глобальном заговоре Electronic Arts дело, а в собственном непрофессионализме, непомерных амбициях, неорганизованности? Даже если вы смотрите на свое дело свысока, с позиции "пипл хавает", все равно же хочется, чтобы хавали вашу игру, а не продукцию конкурентов.

Весь материал взят с сайта: http://www.dtf.ru/

1. Введение

В начале пара слов о коллективной личности автора текста. Нас зовут Яна Боцман и Дмитрий Гордевский. Мы работаем в соавторстве с 1991 года. Написали в общей сложности 20 романов в различных жанрах, много рассказов и повестей, а также 6 сценариев для компьютерных игр. Публикуемся под общим псевдонимом Александр Зорич в российских издательствах с 1997 года, работаем над сценариями для компьютерных игр с конца 2003-го.

Поскольку издавать книги несколько проще, чем выпускать игры, все наши романы успели выйти в свет по 2-3 раза, в то время как три из шести игр по нашим сценариям пока что не дошли до релиза и даже не были анонсированы.

К сему дню по нашим сценариям выпущены:

* 2004 год - "В тылу врага" (BestWay, российский издатель 1С, мировой - Codemasters; жанр - тактическая RTS);
* 2006 год - "В тылу врага 2" (BestWay, российский издатель 1С, мировой - Ubisoft; жанр - тактическая RTS);
* 2006 год - "Завтра война" (Crioland, российский издатель 1С; жанр - авиакосмический симулятор).

"В тылу врага" и "В тылу врага 2" посвящены Второй мировой войне и не имеют в своей основе какого-либо конкретного литературного произведения. В отличие от них, "Завтра война" базируется на нашей одноименной фантастической трилогии и основывается на очень массивном сценарии - 30 авторских листов, то есть 1,2 миллиона знаков с пробелами. Работа была большая, работа была сложная, проект предъявлял к сценарию более серьезные требования, чем обе "В тылу врага". Поэтому в ходе нашей лекции мы будем обращаться за примерами в основном к "Завтра войне".

Сразу предупредим, что данная статья не преследует попытки развернуть перед слушателями какие-либо теоретические конструкты. Мы будем говорить исключительно о личном опыте сценарной работы. Речь пойдет о том как есть, а не о том как должно быть в неком идеальном случае. Но, коль скоро мы свой опыт работы в игровой индустрии можем считать сравнительно удачным, то в конце мы рискнем дать несколько советов не только начинающим сценаристам, но и бывалым продюсерам.

2. Сценарный документ: определение

"Сценарный документ" это вовсе не единый документ, а метадокумент, то есть вся совокупность текстов и сопроводительных материалов, которая передается сценаристом в распоряжение команды разработчиков и других заинтересованных лиц - продюсера со стороны издательства, аутсорсеров и т.д. В дальнейшем этот метадокумент мы будем обычно именовать просто сценарием.

При этом лично мы не смешиваем такие понятия как сценарий игры и дизайн-документ. Само собой, сценарий игры может содержать - и зачастую содержит - некую ценную для геймдизайнера информацию. Но в то же время, в круг обязанностей сценариста не входит точное установление большинства игровых параметров, влияющих на геймплей непосредственно.

Поясним этот тезис на примере "В тылу врага 2". В этой игре от нас, как сценаристов, исходила инициатива по включению в игру ряда новых юнитов, в частности бронепоездов, немецкого посыльного самолета "Шторьх", американского "ракетного джипа" (джип с двумя базуками на поворотном станке), авиадесантного танка "Тетрарх" и др. Но в то же время, все конкретные цифры, которыми описываются эти юниты в игре (живучесть узлов и механизмов, скорость, маневренность, стойкость брони и т.д.), нами никоим образом не контролировались. Подчеркнем: подобные вещи и не должны контролироваться сценаристом при правильно организованном взаимодействии между субъектами производственного процесса.

Вывод: сценарий - это все те собственно литературно-художественные и, если угодно, "атмосферные" компоненты, которые необходимо привнести в игру, плюс в ряде случаев (но не во всех!) - подробное описание событий внутри игры, иногда - вплоть до всех скриптовых, "уникальных", сюжетно значимых перемещений юнитов, состояний объектов и т.д. Понимаемый таким образом сценарий в нашем представлении противопоставлен всей совокупности технологических и геймплейных аспектов игры, за которые отвечает команда-разработчик (а не сценарист).

3. Сценарный документ: структура

Рассмотрим этот вопрос на примере сценария "Завтра войны". См. рис.1, на котором изображена общая структура сценария как метадокумента.

http://www.dtf.ru/articles/image.php?id=21173&publ_id=43245

Рис.1. Структура сценария игры "Завтра война"

В принципе, схема говорит сама за себя. Поясним лишь некоторые моменты.

Синопсис, если кто не знает - это возможно более краткое (желательно 10 страниц максимум, то есть не более 20 тыс.знаков, но лучше 4-5 стр.) и при этом содержательное описание сюжета и его основных особенностей. Синопсисы писать довольно противно, нам это занятие не нравится, но на раннем этапе разработки без них нельзя. Синопсис является любимым чтением руководителя проекта и продюсера, его изучение позволяет им сразу высказать свои наиболее существенные пожелания, а заодно блокировать на ранней стадии те или иные ошибочные финты сценаристского мышления.

В нашей практике был случай, когда синопсис обсуждался 40 дней и переписывался 4 раза, зато полный сценарий игры был получен из четвертой редакции синопсиса за неделю. Не бойтесь, речь идет не о "В тылу врага" и не о "Завтра войне", там все было не так легковесно: после утвержденного "на лету" синопсиса следовали месяцы и даже годы тяжелой работы.

В синопсисе обязательно должен определяться примерный объем игры (в терминах миссий, уровней или каких-либо других логических членений), особенности мира, основные герои, завязка, общий ход и финал сюжета. Подчеркиваем: и финал. Если в синопсисе написано что-то вроде "потом следует множество захватывающих приключений в офигенно красивых локациях, а в конце у нас запланировано 7 разных финалов, которые мы придумаем по ходу дела" - это не синопсис, а оскорбление природы.

В то же время, синопсис это вовсе не бизнес-план. Сценарист не обязан задумываться о бюджете, человеко-часах, майлстоунах, потребных технологиях и т.д. Для этого у проекта есть другие, компетентные и ответственные, люди. Если их нет - проекту сценарист не нужен, ему нужно немедленное закрытие.

Что касается разницы между собственно сценарием и сопроводительными документами (см. тот же рис.1). "Собственно сценарий" - это тексты всего того, что прозвучит из колонок игрока (и/или будет написано на экране). Плюс, в зависимости от игры, более или менее детальное описание сюжета внутри миссий. Почему мы говорим "более или менее детальное", когда, казалось бы, сценарист должен давать предельно детальное описание? А потому что случаи разные бывают.

Скажем, в "Завтра войне" сценарий очень подробно описывает вообще все, что происходит в игре (разумеется, за исключением тех действий, за которые несет ответственность ИИ юнитов). Скажем, в такой-то фазе такой-то миссии из Х-матрицы появляется конкордианский авианосец "Гард" - это прописано в сценарии. На загрузке такой-то миссии на летном поле космодрома Глетчерный стоит линкор "Лотарингия" - это прописано в сценарии. Погиб данный персонаж - этот вариант предусмотрен сценарием. И т.д. (Мы не постулируем подобный подход как единственно возможный или единственно правильный - все знают, что многие игры устроены совершенно иначе, тут мы как раз имеем дело со спецификой "Завтра войны" как проекта с очень развитым и, одновременно, жестким сюжетом, предусматривающим лишь несколько строго очерченных нелинейностей.)

Какую именно структуру имеет текст каждой миссии "Завтра войны", можно увидеть на рис.2.

[img]http://www.dtf.ru/articles/image.php?id=21175&publ_id=43245[/img]

Рис.2. Структура текста миссии игры "Завтра война"

В то же время, "В тылу врага 2", например, разрабатывалась несколько иначе, а потому и "собственно сценарий" там выглядит по-другому. Мы уже знали, что отношение руководства компании BestWay к геймдизайну и плотности геймплея не просто "ответственное" - оно у всех ответственное - а "религиозное" в хорошем смысле слова. По этой причине не имело смысла пытаться во всех мыслимых деталях описать карту, на которой проходит очередная миссия, равно как и саму миссию. Мы знали, что BestWay, стремясь к супердинамичному геймплею, все равно такие вещи сделает лучше, а главное - зачастую совершенно по-другому, чем будет предложено нами. Поэтому "В тылу врага 2" являет нам пример того самого "менее детального" описания сюжета внутри миссии.

Что же касается перечисленных на рис.1 "сопроводительных документов" - тут все совсем прозрачно. Это приватные части сценария, которые адресуются только команде разработчиков, а до игрока если и доходят, то уже в виде собственно юнитов, моделей персонажей, ландшафтов и помещений, но не в виде слов или событий. И когда игрок видит на экране, скажем, бравого космического пилота, ему совершенно необязательно знать, что в документе под названием "Персонажи" по поводу этого пилота было написано: "Такой, что называется, нормальный мужик, похожий то ли на актера Баталова, то ли на молодого Жженова". Тем более, что этот пилот в итоге на Баталова и не похож вовсе, и озвучен по-другому... То есть озвучен-то хорошо, и смотрится молодцом, а потому кому какое дело, что было написано в документе, верно?

Впрочем, о "приватности" сопроводительных документов следует дать одно разъяснение. Часть этих документов может быть переработана в нечто форматное путем добавления необходимых антуражных элементов и удаления всяких отсылок к известным актерам и адресованных дизайнерам ремарок вида "В общем, представьте себе утюг с четырьмя артиллерийскими башнями, это и будет первое приближение к нашему космическому линкору". И вот в форматном виде эти документы могут использоваться для сопровождения проекта, публиковаться на сайте игры в качестве отдельных статей, при желании инкапсулироваться в игру как "Справочники" и "Энциклопедии" и т.д

В качестве примера конверсии сопроводительных документов в публичные статьи рекомендуем посетить официальный сайт "Завтра войны" и ознакомиться с различными справочными разделами:

http://www.zavtravoina.ru/world/united/flug.html
http://www.zavtravoina.ru/world/united/persons/index.html
и далее по ссылкам.
4. Объемы сценария и прочие откровения

Само собой, и конкретный набор документов, составляющих сценарий, и размеры этих документов полностью определяются игрой - ее жанром, особенностями, объемом геймплея и т.д. Также на размеры сценария влияет активность руководителя проекта, геймдизайнера, продюсера, левел-дизайнеров.

Ну например, если продюсер в известный момент вдруг скажет "Миссий будет не 16, а 12", разве кто-то станет ему перечить? Нет, конечно. А сценарий, само собой - уменьшится. Или если левел-дизайнер вместе с художником не нуждаются в точных указаниях по геометрии уровня и по локациям, если они имеют очень четкое самостоятельное видение - зачем писать для них 3 страницы рекомендаций по уровню? Достаточно того, что в сценарии написано: "Действие происходит на сортировочной ж/д станции, подробности могут быть предложены по дополнительному запросу".

Общий объем сценария "Завтра войны" уже был озвучен, это 30 авторских листов. Сценарий состоит примерно из 50 документов (1 синопсис, 37 - собственно сценарий, 12-15 - сопроводительные документы; заметим, что на рис.1. указаны не все они, а только главнейшие).

Сценарий "В тылу врага" занимает 6 авторских листов и состоит всего лишь из 5 документов: по одному документу на каждую кампанию и еще один документ с репликами для АИ-шных бойцов. В настоящее время сценарий игры опубликован, все заинтересованные лица могут ознакомиться с ним у нас на сайте, вот здесь: http://www.zorich.ru/games/index.htm.

Наконец, сценарий "В тылу врага 2" состоит из невероятно большого синопсиса, в котором мы предлагали BestWay на выбор 15 (!) различных кампаний, 3 вступительных документов к утвержденным в итоге кампаниям, 3 собственно описаний кампаний, 33 (по общему числу миссий, если считать вместе с обучающими) документов с текстами для озвучания событий внутри миссий, 5 сопроводительных документов с разными мелочами, а также из достаточно большого количества разъяснительных схем. Общий объем сценария - порядка 8 авторских листов.

При этом надо оговориться, что ряд документов по озвучанию был предоставлен нам командой BestWay и, таким образом, их конечный вид является результатом коллективного соавторства команды со сценаристом. В принципе, это не очень хорошо, потому что желательно во всем соблюдать принцип "одна задача - один ответственный". В частности, за все игровые тексты должен отвечать сценарист и только он. Но в случае с "В тылу врага 2" все получилось достаточно органично, потому что большинство миссий в игре многократно редизайнилось, пополнялось новыми событиями, заданиями и скриптовыми врезками. Так что, в итоге, писать разговоры между бойцами в этих миссиях могли только сами же их непосредственные создатели. Ну а мы потом эти тексты насколько могли "олитературили".

5. Зачем игре нужен профессиональный сценарист?

Тут, между прочим, могут быть самые разные точки зрения. Мы озвучим лично свою.

Профессиональный сценарист привлекается к работе над игрой потому, что он хорошо владеет родным языком (в нашем случае - русским). "Хорошо" тут имеется в виду не обязательно как Иван Тургенев или Владимир Даль, а хотя бы просто лучше, чем остальные участники процесса. Именно благодаря своим хорошим отношениям с языком сценарист может, вложив в уста персонажа 4-5 харизматичных реплик, быстро и эффективно создать рельефный образ. Точно так же сценарист, за счет умелого подбора правильных слов и оборотов, может нагнетать высокий пафос в обращении генерала к своим войскам, спустя десять минут имитировать сбивчивую речь влюбленного, а еще через полчаса писать радиообмен между пилотами в ходе боевого вылета.

Таким образом, основной инструментарий сценариста: широкий словарный запас, чувство языка и стиля, солидный багаж эффектных клише. Ну и общая эрудиция, конечно.

Именно эти вещи и составляют абсолютно необходимый профессиональный минимум, что обычно недостаточно хорошо осознается, поскольку широко бытует такая точка зрения, что сценарист обязательно придумывает "лихо закрученный" или там "увлекательный" сюжет. Так вот, "лихо закрученный" сюжет - это, на самом деле, программа-максимум. Подобную цель не всегда легко достичь, а в ряде ситуаций ее вообще лучше не ставить, чтобы потом сценарист и руководитель проекта не испытывали взаимного разочарования.

Почему? Потому что сюжет, как голая конструкция, может на бумаге смотреться очень даже привлекательно. Но игра, с одной стороны, организм сложный и, скажем так, болезненный, а с другой - всегда ограниченный в выразительных средствах. На одном движке вообще нельзя показывать персонажей крупным планом (полигонов мало), на другом - показывать можно, но губами они все равно шевелить откажутся, на третьем можно и первое, и второе, но всегда есть опасность, что на озвучании решат сэкономить и вся твоя не менее чем шекспировская драматургия пойдет коту под хвост из-за нерадивости актеров. А ведь персонажи это только часть проблемы, есть еще общая ткань игры, которая может сплестись правильно и тогда даже незамысловатый обмен репликами будет звучать кр-руто, а может все сложиться негармонично и тогда в первую очередь пострадает в восприятии геймера именно наш гипотетический "увлекательный" сюжет.

Итого: точно так же как главный программист отвечает за эффективную и стабильную работу движка, так сценарист отвечает за эффективную работу языка.

Что же касается качества и количества сюжета - это вопрос не столь однозначный. Да, сюжет должен быть, да, сюжет должен быть хороший, да, оригинальный, и многая, многая прочая... К этому надо стремиться, но ради этого в ряде игр не стоит расшибаться в лепешку. И если потом геймеры не назовут сюжет и вообще работу сценариста в числе достоинств вашей игры - это не значит, что сценарист трудился напрасно.

6. Сценарии и сеттинги

Все сеттинги по их сюжетно-смысловому содержанию можно разделить на реалистические и фантастические. Но лучше оба этих слова взять в кавычки, так надежнее.

"Реалистические" сеттинги это понятно что: в первую очередь, Вторая мировая война, королева сеттингов отечественного рынка. Далее: все прочие исторические стратегии и симуляторы реальной техники, многие стратегии развития (в том числе и экзотические: "построй тюрягу, корми зэков, зарабатывай на сколачиваннии ящиков"), life-sims, полицейские и спецназовские боевики и квесты и т.д.

"Фантастические" - все остальное. Сюда попадают не только чистая фантастика (грубо понимаемая как футуристический технобоевик или технотриллер) и чистая фэнтези (понимаемая как "мечи, магия, эльфы"), но и различные кунстштюки в жанре хоррор, ряд авторских адвенчур, большинство прочих авторских игр в спектре от "Мор. Утопия" до Spore.

На своем опыте беремся утверждать, что средний реалистический сеттинг требует от сценариста несколько меньших усилий, чем фантастический. Даже в том случае, если собственно сценарные части у "реалистической" и "фантастической" игр по каким-либо причинам будут примерно одинаковыми, пакет сопроводительных документов к фантастическому сеттингу скорее всего окажется заметно толще. При этом, однако, выше требования к точности информации, сообщаемой в сопроводительных документах, именно у "реалистических" сеттингов.

Мы даже не будем ссылаться на такие пиковые случаи как хардкорные симуляторы, ядро аудитории которых очень чутко относится именно к техническим и историческим деталям (мы никогда не занимались хардкорными историческими симуляторами). Но и в такой менее чувствительной к достоверности игре как "В тылу врага 2" пришлось потратить немало времени на сверку различных исторических реалий, пространственно-временных рамок военных операций, номеров частей и соединений. Большую часть этой работы, вероятно, можно было бы и не делать, однако мы считаем, что тут как у математиков. У них вежливость - точность, и вежливостью сценариста должна быть точность. Схалтуришь в номере дивизии, потом начнешь халтурить и в более важных вещах.

Вывод: когда вы работаете над сценарием в фантастическом сеттинге, всегда будьте готовы к тому, что писать придется больше, чем вам кажется; в то же время, при работе в реалистическом сеттинге приготовьтесь к длительным поискам и фильтрации тех или иных узкодисциплинарных сведений.

7. Для начинающего сценариста

Сценарист помогает команде делать игру. Не более - и не менее. Надо понимать, что 15, 20, 50 человек прибегают к услугам сценариста не для того, чтобы сделать ему приятное или поспособствовать реализации его амбициозных замыслов. В рамках проекта у сценариста полномочий не больше, чем у главного художника или ведущего программиста. Обычно их меньше. Решающим в отношении сценария голосом обладает руководитель проекта (и продюсер, если он есть). Если какие-то элементы предлагается из сценария в игру не переносить - значит так тому и быть, это нормальный рабочий момент.

Вообще, руководитель проекта всегда прав. В том числе и во всем, что касается сценария игры. Если руководитель проекта не прав, его мнение должно быть оспорено предельно аргументированно. Если после спора стороны остались каждая при своем мнении, значит руководитель проекта прав.

Если у сценариста возникает очень четкое видение каких-либо элементов дизайна игры и это видение представляется ему важным, оно должно быть донесено до команды всеми возможными средствами. Если требуется нарисовать схему - рисуйте схему. И поаккуратнее. Если требуется нарисовать 10 схем - рисуйте 10 схем. Нужно сопроводить свою мысль заемными фотографиями и иллюстрациями - подбирайте их, пишите сопроводительный текст, объясняйте что к чему. Словесное описание на 7 страниц? Что же, вы заложник своего видения, пишите. Только в том случае, если сценарист сделал все возможное, чтобы его предложения дошли в предельно развернутом виде до руководства команды, он вправе надеяться на то, что увидит в игре нечто такое... похожее... может быть, отдаленно...

http://www.dtf.ru/articles/image.php?id=21177&publ_id=43245

Рис.3. Схема американской кампании игры "В тылу врага 2" (версия сценариста)

http://www.dtf.ru/articles/image.php?id=21179&publ_id=43245

Рис.4. Слева - концептуальные схемы джипса по версии сценариста. Справа вверху - эскиз джипса по версии команды. Справа внизу - джипс в игре "Завтра война".

Этот момент принципиально важен. Все авторские креативы, которые рождает фантазия сценариста, надо сразу разделять на те, которые вообще не будут предлагаться к реализации, и те, которые будут предлагаться в виде подробного описания, желательно с картинками (пусть и достаточно грубыми по исполнению; сценарист, конечно, уметь рисовать не обязан). Если же сценаристу в ходе работы над фантастическим сеттингом привиделся некий невероятно продвинутый и оригинальный летательный аппарат, но в документе для дизайнера он ограничивается раздолбайским "посмотри у Лукаса на X-fighter и сделай примерно так же, только с шестью крыльями", то тут возможны 2 варианта:

1. сценарист отдает себе отчет, что его на самом деле устроит любое решение дизайнера, которое устроит команду и руководителя, а потому экономит время себе и другим, давая лишь самые общие и ни к чему не обязывающие рекомендации; и какого бы шестикрылого серафима он в итоге не увидел, спорить он не будет;
2. сценарист пребывает в уверенности, что все прекрасно объяснил и только идиот не в состоянии перейти от икс-файтера с 4 крыльями к икс-файтеру с 6 крыльями; обнаружив на эскизе/модели лишнюю пару совсем не там, где она ему грезилась, сценарист злится и начинает требовать "все переделать", путано и сбивчиво объясняя - как именно.

Все мы понимаем, что первый вариант - нормальный, второй - абсолютно нездоровый и ведет к нелестной оценке общей профпригодности сценариста.

Приведенный пример, конечно же, легко распространяется на все аспекты дизайна игры, в том числе и на левел-дизайн. Так или иначе, в каждом случае сценарист должен быстро и однозначно определяться для себя: чья ответственность? моя или их? талдычить про то, что без вытянутого озера по правому краю карты миссия много проиграет, рисовать соответствующую пояснительную схему? или - к черту?

Также важно научиться работать с границей невозможного. Дело в том, что эта граница - подвижна. (По крайней мере, у всех достойных проектов.) Тут вот о чем речь: всегда налицо совокупность очевидных возможностей движка ("у нас по кабакам ходят люди, по полю ездят танки, а в космосе летают звездолеты") и очевидных же "невозможностей" ("мы не можем анимировать и адекватно встроить в игру гигантскую водоплавающую сороконожку"). Но, помимо очевидностей, есть внушительная расплывчатая область, населенная различными "надо подумать", "отличная идея, но реализация под вопросом", "кажется, нельзя, но..." и "попробуем сделать". Вот через эту-то область и проходит граница между твердым "можно" и твердым "нельзя" и именно в ней происходит самое многообещающее взаимодействие между сценаристом и командой, потому что иногда эту границу удается сдвинуть в пользу "можно". Так иногда рождаются замечательные фичи, самые неожиданные повороты сюжета и просто симпатичные украшения. В других случаях, конечно, все может закончиться пшиком, а с точки зрения менеджмента - бессмысленной потерей человекодней и человекомесяцев. Поэтому мы и говорим о том, что с этой границей надо уметь работать.

Это умение принадлежит к числу эзотерических искусств, научить ему нельзя. И если только вы когда-нибудь будете создавать большой сценарий для солидной игры - просто помните: граница подвижна.

8. Для продюсеров

(Сразу надо сказать, что здесь под "продюсерами" понимается все звено высшего руководства, а не только куратор проекта со стороны издателя.)

Рассмотрим типовую проблемную (но притом вполне здоровую) ситуацию.

Идет работа над мистическим шутером "Мавзолей-2" про беременную от мумии Ленина инопланетянку, которая сбежала из секретной лаборатории ГРУ. Играем за инопланетянку, задача - убить всех людей. Сценарист написал для вас "пилот": полный текст двух первых уровней. Что касается схемы беготни инопланетянки по супермаркету "Пятерочка" (это первый уровень, обусловлен продакт-плейсментом) и предложенных сценаристом находок, у вас возражений нет, но диалоги между NPC-ментами в четырех кат-сценах вам активно не нравятся. Вы не беретесь сформулировать, почему именно и как должно быть, но - "люди так не говорят". О чем вы и намереваетесь сообщить сценаристу...

И вот здесь, прежде чем стукнуть в аську, тыцнуть в мыло или схватиться за мобилу, надо остановиться и предаться безудержному самокопанию в течение хотя бы ста двадцати секунд. Если вы курите - покурите. Любите сладкое - сгрызите печеньку.

Вам требуется понять для себя, что именно вы намерены написать или сказать сценаристу. Вариантов много:

* "Люди так не говорят, надо все переписывать."
* "Люди так не говорят, посмотри как говорят менты в фильме "Бумер". Надо - так!"
* "Послушай, вот прикольный же фильм "Бумер"... Там все так круто! И даже менты, хотя фильм не про них - как живые! Ты не мог бы попробовать на следующих уровнях попытаться "снять" именно такой стиль?"
* "Я думал ты профессионал, но сколь жестоко разочаровался! Мы отказываемся от твоих услуг, позвоню-ка я лучше Б. и С. Они мне обойдутся раз в десять дороже и скорее всего вообще пошлют нафиг, зато если выгорит - все будет по приколу! А не выгорит - ну их нахрен вообще, эти кат-сцены."

(От себя заметим, что четвертый вариант не так плох, как может показаться.) Наконец, есть и более сложные варианты - можно, например, потратить триста секунд, чтобы точно локализовать проблему, внимательно проанализировать текст диалогов и сообщить сценаристу предельно конкретные соображения: в какой фразе какое именно слово или оборот речи не устраивают и почему.

Так вот, мы не будем говорить - как лучше. Как лучше - решайте сами. Неприемлем только первый вариант ("Люди так не говорят, надо все переписывать"), поскольку это подход чересчур жесткий и предельно неконкретный. Остальные - приемлемы, но разница между ними, надеемся, очевидна: это разные стратегии управления. В зависимости от того, к какой стратегии вы прибегнете, конечный вид сценария будет разным.

И последнее. Как уже было сказано выше, в ряде случаев от сценариста требуется отказаться от попыток навязать свое видение команде, согласиться с тем, что предложенный вариант тоже неплох. Точно так же, хороший продюсер умеет делегировать полномочия команде, и в том числе - сценаристу. Может случиться, что "люди так не говорят" - это личный предрассудок. А в собранной кат-сцене, с полной анимацией и грамотной озвучкой, изначально предложенный сценаристом текст играет богаче, чем сыграло бы то как "говорят люди" по мнению продюсера.

Весь материал взят с сайта: http://www.dtf.ru/

Отношение к компьютерным играм у меня примерно как к наркотикам - все больше теоретический интерес. Хотя иногда я играю (предпочитаю тупоумные шутеры вроде Painkiller или Serious Sam: просто чтобы не тратить много времени на вживание в атмосферу и запоминание правил, что требуется в хорошей RPG). При всем при том игры всегда меня живо интересовали - как новый вид искусства и как относительно молодое направление в индустрии развлечений - я читал специализированные журналы, следил за новинками. И когда киевская студия GSC Game World предложила поработать над сценарием компьютерной игры, немедленно согласился.

http://www.dtf.ru/articles/image.php?id=16223&publ_id=38700

Илья Новак не жалеет, что ввязался в разработку игр

До того я ничем подобным не занимался, хотя успел написать с полдесятка фантастических романов и еще больше рассказов и повестей. В принципе, создание фантастического романа и создание сценария фэнтезийной игры имеют одинаковую суть. И то, и то - придумывание и изложение фантастической истории. Однако при схожей основе форматы изложения истории сильно разнятся. Основных различий, на мой взгляд, три.

К тому моменту, когда я появился в GSC, работа над real-time стратегией с элементами RPG "Heroes of Annihilated Empires" ("Герои уничтоженных империй") велась уже около года. Были созданы некоторые локации, отмоделированы персонажи, примерно известны игровые расы - но отсутствовал окончательный сценарий, то есть сама история. Непонятно было, "об чем, собственно, речь". При написании романа (во всяком случае - развлекательного фантастического романа) такое вряд ли возможно. Автор вовсе необязательно заранее продумывает историю до мельчайших подробностей и делает для себя тщательный синопсис, но он как-то планирует сюжет и примерно знает финал. Вообще, написание романа можно сравнить с ночной ездой по пригородному шоссе в сторону города. Известно, куда в конечном счете ты должен попасть (финал известен); понятно общее направление пути; наконец, по мере езды фары освещают перед тобой некоторый участок дороги (пока пишешь, в уме постоянно выстраивается содержание следующих глав). Но, конечно, всех нюансов того, что лежит в темноте между тобой и городом, ты не знаешь, и куда на пути к финалу может повернуть дорога (сюжет), и кто встретится в пути (какие персонажи добавятся), точно не известно.

Конечно, у GCS были какие-то сценарии, написанные их штатным сотрудником, но по разным причинам они казались неудовлетворительными. А время шло, на игру тратилось все больше времени и средств. Наконец, ведущий дизайнер проекта Дмитрий Зенин решил пригласить человека, который смог бы взглянуть на ситуацию со стороны и предложить что-то свежее. Таким человеком и оказался автор этой статьи; хотя, надо признать, из всего, что я напридумывал, в дело пошло максимум процентов тридцать.

Второе отличие между работой над романом и компьютерной игрой заключается в том, что роман создается в одиночку, а в игре задействована масса народу. Когда пишешь книгу, ты один и никто тебе не указ, а написание сценария - это уже совсем из другой оперы. При том что занят ты, как уже говорилось, вроде бы тем же самым - придумываешь фантастическую историю и пытаешься изложить ее так, чтобы другим интересно было. Но выглядит процесс иначе, ведь после того как сценарий написан, он может сильно меняться в процессе многомесячной (или многолетней) работы других людей: дизайнеров уровней, геймплейщиков и черт знает кого еще.

Наконец, третье, что я понял: в игре содержание, "интересность" каждой отдельной миссии зачастую важнее, чем общий сюжет (во всяком случае, с точки зрения геймплейщиков, разрабатывающих свои миссии). Конечно, в романе "вкусность" и занимательность отдельных эпизодов имеет огромное значение, но важен там и уровень, класс всей истории, так сказать, глобальная интрига, а не только дискретные элементы, из которых интрига состоит. Вообще, как мне кажется, современные девелоперы склонны недооценивать важность сценария именно как общей занимательной истории, не принимать во внимание, так сказать, литературно-художественную сторону создания игры - по крайней мере, склонны приуменьшать ее роль. Над игрой, уже после того как сценарий сделан, работают люди, занимающиеся отдельными миссиями, и им важно, чтобы каждая миссия была захватывающей сама по себе, они могут многое в ней менять исходя из своих нужд, зачастую и не помня даже общего сюжета; его могут знать только главный дизайнер, сценарист... и продюсер.

Продюсер - это отдельная песня. Заунывная и жалобная. В данном случае в его роли выступает директор GSC Сергей Григорович. То есть он выслушивает предложения, отклоняет и принимает их, а потом усиленно вмешивается в те, которые принял.

Так или иначе, после того, как общая концепция игрового мира, главные персонажи и расы были продуманы, создание сценария происходило примерно так.

http://www.dtf.ru/articles/image.php?id=16225&publ_id=38700

Какое-то время я, сидя дома, что-то придумываю и записываю. Затем отправляю это по электронной почте в GSC. Там текст распечатывают в нескольких экземплярах, читают, смеются и приглашают прийти. Не смеется только директор, поскольку он платит мне зарплату. Я прихожу, мы располагаемся в конференц-зале. Мы - это директор, главдизайнер, штатный сценарист, зачастую еще человек, ответственный за геймплей и, бывало, даже режиссер будущих игровых роликов. Я беру листок с распечаткой и начинаю читать. По мере чтения то краснею, то бледнею, потому что чтение происходит в тишине настолько многозначительной, что чувствительный человек, вроде меня, теряется. С определенного момента присутствующие не выдерживают и принимаются высказывать свои предложения и, самое страшное, комментарии по поводу услышанного. Режиссер роликов цитирует "Кино между адом и раем" (библия начинающих киносценаристов и режиссеров) Митты, дизайнер жалуется, что локация, где будет происходить данная миссия, недостаточно красива, геймплейщик бормочет что-то про ботов и чаров, а директор, шевеля губами, подсчитывает убытки, ждущие его, когда игра провалится. Молчит только штатный сценарист: он до меня успел переписать сценарий тринадцать раз, постиг дзэн и теперь ему все пофигу.

Ко всему прочему, директор как раз перед началом этого процесса попал в аварию (он увлекается мотокроссом) и сломал ногу. Соответственно, передвигался он в кресле на колесиках, причем - поскольку он глава крупной коммерческой фирмы, а не кто-нибудь еще - в кресле, очертаниями напоминающем машину марки BMW, с электромотором и джойстиком, которым это кресло управлялось. Во время обсуждения сценария он, периодически выходя из себя, начинал крутить джойстик и выписывать на своем кресле взволнованные круги вокруг длинного стола, стоящего в конференц-зале, при этом делясь с присутствующими своими впечатлениями от происходящего, - а все остальные синхронно поворачивают головы на 180 градусов, следя за ним взглядом.

Итак, в результате все этого от моей истории остается дай бог чтобы десять процентов -остальное меняется. Но поскольку меняется оно усилиями шести (считая меня) человек, и каждый тянет в свою сторону (режиссера интересует саспенс и экшн, сценариста - литературность, дизайнера - красота, геймплейщика - соответственно, геймплей, директора - деньги, а меня - чтоб они все провалились сквозь пол конференц-зала), то получившаяся история ни в какие ворота не лезет: выходит что-то вроде рассказа о Колобке с электропилой, который спасает Лару Крофт от покемонов. С ворохом листков, исписанных торопливым почерком с обеих сторон, я возвращаюсь домой, пытаюсь все это свести в кучу, еще раз переписать, потом опять исправить, затем переставить с головы на ноги и как-то совместить с предыдущей миссией, потом вновь отсылаю в GSC, через пару дней вновь еду туда - и после двух-трех подобных циркуляций миссия в первом приближении готова. Потом ее все равно перепишут, но меня там уже не будет.

http://www.dtf.ru/articles/image.php?id=16228&publ_id=38700

http://www.dtf.ru/articles/image.php?id=16230&publ_id=38700

Так выглядит сама игра

Ситуацию усугубляло то, что "Герои" состоят из трех частей (то есть проект по-своему вполне крутой: игра заранее продумана как трилогия, не новые приключения старых героев, а именно общий связный эпический сюжет), соответственно, работы в три раза больше.

Совсем другое дело - написание книги. Там ты сам себе хозяин, ты - единый бог, творец своего мира, ты командуешь всем и никто тебе не указ... хотя, с другой стороны, если роман в результате получился неинтересным, то и виноват только ты сам. А в компьютерной игре, если тебе скажут, что поступки героя немотивированны, интрига плоская, а основной конфликт какой-то корявый, ты всегда можешь свалить вину на, допустим, режиссера роликов - мол, это он виноват со своим Миттой.

Но несмотря ни на что, я работой с GSC остался доволен. Во-первых, мне заплатили все причитающиеся деньги, что само по себе ценно. Во-вторых, мы таки сделали сценарий первых двух частей (хотя, в конечном счете, моя роль в этом не так уж и значительна). Наконец, в-третьих и в главных, как оказалось, с самого начала хитрый директор подразумевал, что по мотивам игры должны появиться книги. И автор-фантаст интересовал его, насколько я теперь понимаю, больше не как сценарист, а именно как человек, способный писать фантастические романы. Мир книжного цикла называется Аквадор, и два первых тома уже готовы.

Во время работы над сценарием у меня возникло столько материалов для будущего романа, что за самим романом дело не стало. При этом предполагалось, что книг будет три (как и частей в игре), и будут они выходить одновременно с этими частями, то есть с разницей примерно в полгода. Однако, делая сценарий, я разработал и, так сказать, обоснование для него. То есть предысторию, те события, которые привели к завязке игрового сюжета. Я решил, что первая книга трилогии будет состоять из двух половин, вначале - предыстория, потом - собственно сюжет первой части игры. Стал писать... и не смог уместить предысторию даже в первый том. Теперь получается пять книг: первые две - предыстория (и выйдут они, соответственно, за некоторое время до выхода первой части игры), а следующие три - то, что будет в игре.

***

Здесь хотелось бы сказать несколько слов в порядке оправдания. Среди молодых людей хватает тех, кто вообще не читает и в компьютерные игры не играет, но про них мы говорить не будем - какой с них толк? Если же взять другую категорию, то она, в основном, делится на два типа. Есть те, кто прежде всего играет (геймеры), а уж если под рукой нет интересной игрушки, то могут и почитать что-нибудь от нечего делать. А есть те, кто прежде всего читают (читатели), а играют от случая к случаю, когда книги интересной не попалось.

Раньше читателей было больше, чем геймеров, теперь наоборот. Для геймеров выход книги по мотивам игры - нормальная ситуация, ведь для них игры важнее. Но у квалифицированного читателя это может вызвать внутренний протест. В его понимании создание игрушки по книге - вполне законно, но написание книги по игрушке - это когда литература становится чем-то вторичным, даже халтурным. Предполагается, что подобные романы пишутся в основном "литературными неграми" и публикуются в порядке рекламной компании к играм. (Кстати, та же ситуация и с фильмами. Экранизация книги - нормальное дело, к подобным фильмам отношение не лучше и не хуже, чем к тем, что сняты по оригинальным сценариям. А вот новеллизация, то есть книга по фильму - что-то убогое и интересующее в основном только фанатов данного фильма. Ну кто, в самом деле, всерьез относится ко всем этим многочисленным книжицам из серий "Чужой против хищника", "Стартрэк" и "Евангелион"?). Насколько я понимаю, подобное отношение сложилось главным образом потому, что литература - куда более древний вид искусства, в отличие от довольно молодого кинематографа и уж совсем юной комп-игровой индустрии, у литературы куда объемнее багаж накопленных идей, методов и вообще - креатива. Молодые и неопытные обслуживают старых и мудрых, а не наоборот. Хотя геймеры так не считают - они к старушке-литературе почтения не испытывают.

Так вот, в данном случае ситуация иная. "Аквадор" - это не книги по игре (хотя и Heroes of Annihilated Empires - это не игры по "Аквадору"). Тут мы имеем симбиоз, одновременно и игра-по-книге и книга-по-игре - ведь я пишу эти романы сейчас, когда игры еще нет (первая часть должна выйти, кажется, в апреле 2006 года); даже рекламная компания всерьез пока не началась. Книжная и игровая составляющие дополняют друг друга и для наиболее полного погружения в мир Аквадора стоит ознакомиться с обеими. И если для GSC главное - их игра, а уж книги для них постольку поскольку, то для меня-то как раз главное - мои романы, игра же выполняет роль лишь рекламного довеска к ним.

***

Компьютерные игры - конкуренты книг. Пример, иллюстрирующий данный тезис, совсем прост. Молодой человек вечером приходит домой, у него есть выбор: почитать книгу или поиграть в игру. Он выбирает игру - вот вам и вся конкуренция. И становятся игры для многих более привлекательными по двум причинам.

Во-первых, они предполагают большее вовлечение пользователя. Если в книге сюжет движется сам по себе, читателю остается лишь воспринимать, впитывать историю, то в игре эта история развивается от завязки к финалу именно благодаря усилиям игрока. То есть игры больше захватывают. Движок, текстуры и прочее сделаны девелоперами, история в целом придумана тоже ими, но развитие этой истории происходит благодаря игроку, он становится как бы соавтором предложенного ему сюжета (а в играх с многовариантными финалами еще и может двигать его в разных направлениях).

Во-вторых, чтение книг предполагает постоянно начальное усилие по переводу "черных значков на белом фоне" в удобоваримую информацию, игра же - это своеобразное интерактивное кино, то есть уже готовые, синхронизированные визуальный и звуковой потоки, которыми игрок до определенной степени еще и управляет. Грубо говоря, когда в книге написано "Ядовито-зеленого цвета огромный мосластый тролль, нарядом которому служила лишь набедренная повязка, издал..." - то пользователю для начала необходимо проделать некоторую внутреннюю работу, создав в своей голове соответствующий визуальный образ здорового, мосластого, ядовито-зеленого тролля. Далее черные значки на белом фоне складываются в фразу: "...издал низкий протяжный рев, в котором слились первобытная ярость, ненависть ко всему живому и, одновременно, страх. И, тяжело..." - после этого читатель в уме воссоздает еще и звуковой аналог рева, исторгнутого зрительным образом тролля. Ну а затем идет фраза: "И, тяжело шагнув ко мне, ударил длинной кривой саблей." - и образ приходится воссоздавать в динамике, то есть как ядовито-зеленый, мосластый, здоровый тролль шагает к герою, с которым отождествляет себя читатель, ревет, да еще и бьет героя саблей, и не простой, а "длинной и кривой".

В игре вы получите готовое объемное изображение соответствующего тролля, который жутко ревет, прыгает и молотит персонажа по макушке, пользователю же останется убежать или вступить в драку, то есть действовать, а не представлять. Ну а если персонаж не какой-то тролль, а "амазонка с огромным бюстом, в черном кожаном бикини"? - ясное дело, поглядеть на нее куда увлекательнее, чем почитать о ней.

Для большинства действовать интереснее, чем представлять, к тому же, игры дают пищу и для фантазии, додумывания - потому я утверждаю, что геймеров ныне больше, чем читателей. Хотя, все же, еще осталась категория, которой второе интереснее первого - или интересно и то и то. Потому читатели до конца еще не вымерли, как динозавры.

Сочетание книг и игр в этом смысле дает возможность объединить две категории пользователей, тех, кого сейчас называют таргет-группами. Здесь главное, чтобы книги не были облегченным, вторичным придатком к игре - и наоборот. (Видимо, наиболее успешный проект захвата как можно большей таргет-группы в русскоязычном пространстве сейчас "Ночной дозор" Сергея Лукьяненко. Роман популярен, фильм собрал большую кассу - теперь вот еще и подоспела игра от Nival).

***

Игровой и книжный мир Аквадора (о физической структуре этого мира я ничего не говорю, его происхождение и космология - большая зловещая тайна, которая выяснится нескоро) основан на четырех магических Цехах: теплой, холодной, мертвой и механической магии. Магический Цех - это не только структурные различия боевых и мирных заклинаний, но и совершенно разный взгляд на мир, различная культура, философия и подход к решению проблем. Каждый цех управляется аркмастером, вместе эти Цеха составляют магический Универсал: объединение магов, которым повелевает Владыка (Верховный Аркмастер). На противостоянии, вначале - мелких интригах, а затем тотальной магической войне между Цехами и строится цикл.

Кроме того, существуют еще и ведьмы с шаманами, адепты "дикой" природной магии, не входящие в Универсал и воюющие с ним. А еще это игра (и книги) о пришествии Большой Кузькиной Матери - то есть, к миру Аквадора медленно, но неотвратимо приближается некое таинственное внешнее зло, враждебное и дикой магии и четырем цивилизованным Цехам, и вообще всему живому. Цехам остается либо передраться и уничтожить друг друга, либо объединиться против общего врага - хотя этого они сделать не могут из-за слишком серьезных внутренних разногласий. Нельзя сказать, что в каждой книге речь идет только о каком-то одном Цехе, но большая ее часть посвящается именно определенному виду магии. Первая книга, к примеру, называется "Некромагия" - читателю остается самому догадаться, какому именно магическому Цеху в ней уделено наибольшее внимание.

Первоначально опубликовано в журнале "Реальность фантастики".

Весь материал взят с сайта: http://www.dtf.ru/

Объектом изучения в данной статье станет инструмент организации, коммуникации и координации игрового проекта, далее называемый 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/