Ошибки геймдизайнера: Горячая десятка

Страница 1 из 2

Дмитрий Ножнин
Геймдизайнер внешних проектов в фирме "1С". В прошлом работал над проектами "Аллоды" 1 и 2, "Проклятые Земли", "Демиурги" 1 и 2, "Вторая Мировая".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
  стр. 1 из 2  

Copyright © 2019 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение