Геймдизайн: как это делается, часть вторая

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

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

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

Ну а на прощание подлинные авторы нашей многотомной книги поделятся сокровенным: итогами прожитого и планами на будущее…

ГЛАВА СЕДЬМАЯ
В КОТОРОЙ КОЛЛЕКТИВНЫЙ АВТОР ПОКАЗЫВАЕТ, КАК ПОЛЕТ ДИЗАЙНЕРСКОЙ ФАНТАЗИИ СОЧЕТАЕТСЯ С ПРОИЗВОДСТВЕННЫМ ПРОЦЕССОМ. А ЧТО ПРОИСХОДИТ С ПЕРВОНАЧАЛЬНОЙ ИГРОИДЕЕЙ В ХОДЕ ЭТОГО ПРОЦЕССА? КАК ОН ВООБЩЕ ОРГАНИЗОВАН? КОГДА ПРОГРАММИСТЫ НАЧИНАЮТ ПИСАТЬ КОД? КОГДА И В КАКОЙ ОЧЕРЕДНОСТИ К ПРОЕКТУ ПОДКЛЮЧАЮТСЯ ЕГО УЧАСТНИКИ? КТО И КАК РАСПРЕДЕЛЯЕТ ЗАДАЧИ? ТОТ, КТО РАЗ ЗА РАЗОМ СВОДИТ РЕЗУЛЬТАТЫ ВОЕДИНО, — КАК ОН УДЕРЖИВАЕТ ВСЕ В ГОЛОВЕ? ЕСЛИ ОТСТУПИТЬ ОТ ПЛАНА — ЭТО НОВЫЙ ПОВОРОТ ИЛИ СХОД С РЕЛЬСОВ?..

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

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

Андрей «КранК» Кузьмин
Директор, KranX Productions

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

И начался испуганный крен в сторону привычных RTS. Получилось и ни туда и ни сюда. Сейчас мне кажется, что это было ошибкой. Стоило довести терраформинговую концепцию противостояния до апофеоза, реализовать задуманное, а не пытаться компенсировать недостатки якобы проверенным средством — «солдатиками». Результаты прототипирования не были адекватно проанализированы, это сместило фокус и в итоге дало недостаточно четкий конечный вариант, о чем мы потом и прочитали на форумах.

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

Александр Мишулин
Креативный директор, Nival Interactive

Дизайнерская идея всегда будет масштабнее реализации, хотя бы потому, что вообразить мы себе можем гораздо больше, чем сделать, по самым разным причинам. С другой стороны, для бизнеса хорошо, чтобы задуманное и продукт отличались не на порядок. Сейчас у нас это получается. Есть такой термин — feature creep, это страшный враг гейм-дизайнера. У этого монстра есть несколько форм, и самая распространенная выглядит так: «А давайте сделаем еще и...». Более сложные формы завязаны на коллектив, когда один человек что-то говорит «в воздух», второй подхватывает, третий модифицирует, идея разрастается как снежный ком и становится большой проблемой для ведущего дизайнера. Существует замечательное заклинание — Creeping Doom, вот это как раз по адресу… Понятное дело, есть feature creep от издателя, который говорит «нужно добавить еще и это», и все молодые дизайнеры (все молодые команды) страдают этим заболеванием в ужасной форме, потому что нет опыта борьбы с подобными вещами. Именно это приводит к появлению «гигантских вселенных» с двадцатью одинаково плохо сделанными «фишками». Впрочем, не без исключений. Например, есть тренд, могущий появиться в индустрии в процессе разработки игры, который придется поддержать и который уже не будет «крипом». Иногда на середине проекта возникают вещи, которые заставляют крепко задуматься, связываться с ними или нет.

Вспомним Halo. Эта игра породила новое поколение консольных шутеров, в которых у главного игрока есть быстро восстанавливающийся щит. После Halo все консольные шутеры взяли этот принцип на вооружение. Это правильная, хорошая идея, это тренд. Шутеры становятся более динамичными, игроки не должны стоять на одном месте, как это было в первом Medal of Honor — тире с переставляемыми мишенями. Повторюсь: это тренд, и если ты в него не вписался, тебе будет плохо — потому что он хорошо работает.

А есть то, что называется Next Big Shiny, Следующая Сияющая Фишка. Тот же gravity gun, который из Half-Life 2 отправился в путешествие по нескольким шутерам. На мой взгляд, это не тренд. Как пришелец, так и ушелец. В HL2 он пришелся к месту, в псионических шутерах тоже, а вот его копии… Другой вариант: дизайнеры придумывают слишком много всего, и чтобы бороться с этим, на самых ранних этапах разработки создаются документы, описывающие масштаб игры — как бюджетный (сроки и объемы требуемых ресурсов), так и геймплейный (основные игровые возможности). Понятно, что это динамический процесс, и если какую-то деталь игры реализовать не удалось, всегда можно передоговориться; но это сложный процесс, и он намеренно сделан сложным, чтобы издатель получал ту игру, которую заказывает.

Далее. Мы дошли до этапа, когда в произведенное можно играть, в объеме одной миссии. Это «альфа». И она, представьте, не играется. Бывает и такое. Чтобы избежать подобного, опытные и богатые издатели и разработчики вроде EA и Maxis сделали эдакий обратный шаг к играм, основанным на идеях. Прототипирование. Прототипирование на ранних стадиях очень полезно. Если мы заняты проектом с необычным геймплеем, его нужно смоделировать на чем угодно — на бумаге, на кубиках. Живет на кубиках — будем аккуратно его дорабатывать. Не живет — до свидания; денег и ресурсов потрачено чуть — не жалко. Не обязательно быть большой компанией, чтобы заниматься прототипированием. Большие команды могут таким образом кидать кости.

«Мы сделали двадцать прототипов. Вот эти три ничего — они пойдут дальше, будем их дорабатывать». Из трех остается один, лучший, он и получает бюджет. Если я не ошибаюсь, Уилл Райт говорил, что Spore в ее нынешнем виде выросла из 120-го прототипа.

Илья Стремовский
Гейм-дизайнер, Nival Interactive

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

Да, можно придумать все, что за эту пятилетку было выпущено во всех жанрах. Но потом ты садишься, считаешь и понимаешь, что воплотить в игре все сразу невозможно. И тогда идея начинает эволюционировать. В случае «Нивала» одна гигантская идея трансформировалась в две поменьше — «Блицкриг» и Silent Storm. Да, обе игры выросли из одной задумки и одного проекта. Потом начинается поиск издателя, который предъявляет собственные требования. Так, панцеркляйны появились в Silent Storm из-за увлечения нашего продюсера миниатюрами в сеттинге стимпанк. В момент, когда родилась эта мысль, игра предполагалась сатирической, комиксовой по духу и панцеркляйны там смотрелись органично. Затем была разработана первая версия графического стиля, и стало ясно, что мы можем и хотим двигаться в сторону большей достоверности. Этот вектор, имевший начало в графике, повлек изменения во всех остальных областях, и использование фантастических наработок пришлось ограничить последними этапами игры… И это только основные вехи, но понятно, что эволюция происходит под влиянием самых разных сил. Как внутрипроектных, так и внешних, включая выход других игр, на которые нельзя не реагировать. Начало программирования — это, конечно, пора экспериментов. Но обычно оно остается за рамками проекта, на этапах технологических демо или подготовки к производству. Самые волнующие и рискованные эксперименты в программировании должны заканчиваться с началом основных работ по проекту.

Петр «Amicus» Прохоренко
Гейм-дизайнер Lesta Studio

Первоначальная идея очень редко доживает без изменений хотя бы до первой играбельной версии. А если доживет, first playable расставит все на свои места, наглядно показав авторам, чего стоят их «гениальные задумки». Вообще, история любого игрового проекта — это история изменений и трансформаций первоначального замысла, его преломления через документацию, команду, издателя, деньги и т.п.

При наличии определенной доли удачи («Сталинград» и «Стальные монстры» — счастливые проекты) удается донести оригинальную концепцию до релиза. В других же случаях концепция меняется в ходе разработки, и различные ее части на разных этапах становятся доминирующими. Это вполне естественный процесс для любого проекта длительностью более года, — конъюнктура рынка меняется, и дизайн должен быть достаточно гибким для того, чтобы не «переломиться» от изменений в тот счастливый момент, когда вы поймете, что один из западных мейджоров выпускает похожий тайтл к Рождеству, тогда как ваша игра будет готова только к следующей Пасхе.

Начало программирования — это старт производства игры. Основные черты дизайна к этому моменту должны быть как минимум обрисованы, а как максимум — подробно задокументированы. Эксперименты будут, это 99,9-процентная вероятность для любого сложного проекта. То, что эти эксперименты будут увлекательными, совершенно не факт. На практике это довольно мучительный процесс выработки оптимальных решений для каждого нового проекта, проходящий в условиях ломки сроков, выползания игры за рамки выделенного бюджета, кранчей, овертаймов и прочих девелоперских радостей. Для сложных и больших проектов нет бюджетов, которые они не могли бы превысить, и нет планов, которые оставались бы нерушимыми. Уважаемые читатели могут самостоятельно изучить «историю успеха» любой известной отечественной игры и в скупых postmortem-строках вроде «мы встретили ряд неожиданных трудностей, поэтому пришлось потратить лишние полгода на доводку баланса» найти подтверждение моим словам.

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

Дмитрий Лисица
Гейм-дизайнер Primal Software

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

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

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

Андрей «КранК» Кузьмин
Директор, KranX Productions

Этапы работы над проектом описаны в нашем внутреннем KranX Productions KodeX. Вряд ли открою Америку. Сначала идет фаза Генезиса, которая рождает концепты. Если совет «генетиков» дает добро, начинается препродакшен и сразу определяется основной силовой скелет будущего проекта: продюсер — гейм-дизайнер (GD) — проект-менеджер (PM). С помощью ведущих направлений (арт, технологии, сценарий) они производят прототипирование (как минимум ментальное в виде дизайн-документа) по нескольким параллельным веткам с целью минимизации рисков (это архиважно). Результаты вдумчиво оцениваются, и, если все OK, начинается собственно производство. Технологическое демо, демо играбельное, «альфа», «бета», постпродакшен. Там свои строгие законы. Майлстоуны. PM постепенно высасывает у всех участников (особенно ведущих) лишний мозг через небольшие отверстия, тщательно проделанные продюсерами. GD в это время распят на кресте изменений в проекте и непрерывно принимает муки творчества, старательно молясь.

Если его не закрепить таким образом — игра будет делаться долгие годы. В общем, PM создает ритм из лид-пакетов, а GD — натягивает амплитуду волны. Продюсер крутит ручки и мощно запитывает агрегат...

Александр Мишулин
Креативный директор, Nival Interactive

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

Петр «Amicus» Прохоренко
Гейм-дизайнер Lesta Studio

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

Андрей «КранК» Кузьмин
Директор, KranX Productions

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

Петр «Amicus» Прохоренко
Гейм-дизайнер Lesta Studio

Я гейм-дизайнер, а распределение задач и контроль — это уже управление проектами… Но, в принципе, очень хорошо, когда гейм-дизайнер находится в курсе всех дел. Это работа такая — совать нос во все щели проекта и находить то, что еще можно подкорректировать «под свое видение»… У нас существует право вето, которым обладают ведущий гейм-дизайнер и руководитель проекта. Пока возможность, юнит, сценарий, игровой момент не нравятся тому или другому — работа не будет принята и пойдет на доделку. Документированием и постановкой задач обычно занимается менеджер проекта совместно с ведущим гейм-дизайнером — это их зона ответственности.

Александр Мишулин
Креативный директор, Nival Interactive

В «Нивале» в каждом отделе есть лид, ведущий, — менеджер, в чьи задачи входит управление отделом. Опираясь на основной план работ, он регулярно назначает задачи своим подчиненным.

Петр «Amicus» Прохоренко
Гейм-дизайнер Lesta Studio

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

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

Александр Мишулин
Креативный директор, Nival Interactive

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

Андрей «КранК» Кузьмин
Директор, KranX Productions

Один человек может очень многое, но не все. Потому что он не Солярис. Уверен, что десять-двадцать слаженно работающих партнеров способны сделать куда больше для эволюции мира, чем сотня наемных рабов. Игра склеивается прежде всего в голове. А потом уже в байтах и пикселях. Если наоборот — это ахтунг. Важно иметь скелет игры и постепенно облагораживать его мясом и кожей. Если скелета нет — есть риск получить кучу экскрементов.

Дмитрий Лисица
Гейм-дизайнер Primal Software

Один человек может эффективно контролировать 5- 7 подчиненных. Если кажется, что можно больше, это способно привести к неочевидному сразу падению качества работы. При разработке игры нужны «приемщики»: продюсер, тестеры, а также те специалисты, которые используют в своей деятельности продукты чужого труда: так, data manager, собирающий юнит из отдельных частей, может проконтролировать результат работы моделлеров и текстурщиков; скриптовик, делающий ролик на движке, видит также достижения data manager’а, собравшего юниты. Разные люди — разные способы деятельности. Кто-то делает все сразу (таких энтузиастов особенно много в начинающих командах), кто-то стал узким специалистом и ему нужно обеспечить материалы для работы, поставляемые другими людьми.

Андрей «КранК» Кузьмин
Директор, KranX Productions

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

Александр Мишулин
Креативный директор, Nival Interactive

Мы все делаем по плану. Если отклоняемся от плана? Что ж, достойная игра не исключена и в этом случае. Более того, отклонения — это, к сожалению, скорее норма для индустрии. Но чем больше отклонение, тем сильнее нужен план, чтобы в конце концов выйти на прямую дорогу.

Петр «Amicus» Прохоренко
Гейм-дизайнер Lesta Studio

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

Дмитрий Лисица
Гейм-дизайнер Primal Software

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

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

ГЛАВА ВОСЬМАЯ
КОТОРУЮ ОБЛАДАЮЩИЙ КОЛЛЕКТИВНЫМ РАЗУМОМ АВТОР ПОСВЯЩАЕТ ПРОБЛЕМЕ ИГРОВОГО БАЛАНСА. КАК ЕГО ОБЕСПЕЧИВАЮТ: С САМОГО НАЧАЛА «ЗАРЫВАЮТ» В ИГРУ ОГРАНИЧЕННОЕ ЧИСЛО РАВНО ВЫИГРЫШНЫХ СТРАТЕГИЙ, КОТОРЫЕ ВПОСЛЕДСТВИИ ОБНАРУЖАТ ИГРОКИ? СОЗДАЮТ УСЛОВИЯ ДЛЯ СУЩЕСТВОВАНИЯ НЕОПРЕДЕЛЕННОГО МНОЖЕСТВА РЕШЕНИЙ? КОГДА НАМЕЧАЕТСЯ НЕСКОЛЬКО УРОВНЕЙ СЛОЖНОСТИ — НАСКОЛЬКО ЭТО ЗАТРУДНЯЕТ НАСТРОЙКУ ИГРЫ? А КАК БАЛАНСИРУЮТ РОЛЕВЫЕ ИГРЫ? РОЛЕВУЮ СИСТЕМУ, НАВЕРНОЕ, ПОВЕРЯЮТ АЛГЕБРОЙ, НО КАКИЕ ПРОБЛЕМЫ СТАВИТ ПЕРЕД РАЗРАБОТЧИКАМИ НАЛИЧИЕ В РПГ ПОВЕСТВОВАНИЯ, А В НЕКОТОРЫХ СЛУЧАЯХ — И ЗАРАНЕЕ ЗАДАННОГО МИРА ИГРЫ?

Более-менее стабильной игровая система может быть тогда, когда она запаяна разработчиками и все взаимосвязи изучены (как в StarCraft), либо если она заключает в себе неограниченное (ну, очень большое) число сочетаний (сотни видов юнитов Total Annihilation в энной степени). В то же время, баланс, совершенно очевидно, имеет разное значение в однопользовательской игре и в мультиплейере. Где в каждом случае проходит граница между сложными приемами (или умелостью) игрока и эксплуатацией самолично обнаруженных им слабых мест, что достойны звания прокола, черной дыры в балансе? Как затыкают эти пробоины в балансе?

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

В общем, как вы работаете с балансом в своих играх, дорогие девелоперы?

Андрей «КранК» Кузьмин
Директор, KranX Productions
Разумеется, можно и нужно не «зарывать» выигрышные стратегии, а создавать достаточные для порождения нетривиального многообразия условия. В шахматах до сих пор находят новые стратегии при всей простоте их правил и сеттинга. Законы работы любого клеточного автомата примитивны — но посмотрите, что они творят! Аналог множества Мандельброта в стратегии — вот идеал. Собственно, в начале разработки «Периметра» мне и хотелось сделать нечто подобное.

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

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

Илья Стремовский
Гейм-дизайнер, Nival Interactive

В мультиплейере игроки занимаются именно что «раскапыванием» выигрышных стратегий. Скажем, пространственное расположение юнитов, формации довольно сложно просчитывать заранее. Отсюда и стили игры, и влияние скорости реакции игроков на исход матча, причем даже в стратегиях. Безусловно, какая-то выигрышная стратегия может пройти мимо разработчика. А вот стоит ли ее латать, зависит от того, действительно ли она стопроцентно выигрышная или на этот лом есть прием, пусть его еще и не обнаружили. Другой вопрос, эта выигрышная стратегия — умение или знание? Например, если очень быстро и точно кликать мышкой, то игрок победит, — это выигрышная стратегия; но даже если рассказать о ней слабому игроку, он не сможет ею воспользоваться, пока не натренируется. Но это справедливо в многопользовательской игре. В сингле все зависит от сложности воспроизведения. Если сложный «как-бы- чит», то он может не быть опасным, а представлять собой особый стиль игрока.

Александр Мишулин
Креативный директор, Nival Interactive

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

Одна из любимых тем на форуме «Демиургов» — «дайте такой-то расе такую-то способность». Но некоторые способности были отрезаны абсолютно намеренно, иначе это приводило к легким победам. Поэтому, если нам захочется делать продолжение «Демиургов» со смешанными колодами, скорее всего, придется переделывать карты. Если сделать возможным всё — то всё сразу развалится. При балансировке такие вещи выявляются исключительно статистикой. Сначала собирается набор колод, AI стравливаются друг с другом, если количество побед и поражений нецензурно различается, то что-то где-то пошло не так. Это простой путь, который не выявит хитрости пользователей. Поэтому бета-тест поможет закрыть эту проблему. В «Блицкриге-2» была специальная утилита, которая позволяла стравливать юниты разных типов в разном составе и изучать статистику сражений, логи, смотреть вероятности и т.д. Но эта утилита использовалась только при первом, черновом проходе баланса...

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

Если танку планировались 50 хитов, то в финале может оказаться 250 — хотя уровень повреждений остался прежним.

Дмитрий Лисица
Гейм-дизайнер Primal Software

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

Андрей «КранК» Кузьмин
Директор, KranX Productions

Для создания баланса считаю архиважным иметь в его основе математическую модель. Систему с заложенным в той или иной форме принципом «камень-ножницы- бумага». А ни в коем случае не табличку параметров, заполняемую «от фонаря» дизайнером и потом подвергающуюся длительной пытке несчастными тестерами. Понимаю, что это тоже способ. Но он негармоничный и потенциально бедный, бутафорский (как это было в «Периметре», кстати, с его многочисленными ошибками в балансе юнитов — посыпаю голову пеплом). Это как с физикой. Мощное математическое ядро дает на выходе многообразную достоверность. Никому не приходит в голову менять координаты ящика напрямую. Меняют его массу, к примеру, а еще лучше материал, из которого он сделан. Так же должно быть и с балансом. Он обязан порождаться фундаментальными правилами игры, а не искусственно навязываться владельцем прищуренного глаза. Такая вот ересь.

Илья Стремовский
Гейм-дизайнер, Nival Interactive

Урегулировать баланс можно, ограничивая разнообразие, выделяя категории юнитов и балансируя именно их (рода войск в «Блицкриге-2»). Или, напротив, «топить» правильное решение в комбинаторном взрыве взаимосвязей, где экспоненциальный рост скорее на пользу. Другой жанр, который топит решения, — это физические симуляторы. Все, начиная с Bridge Builder и заканчивая gravity gun из Half-Life 2, образует слишком большое пространство решений. Ящик нарисован один, но у него очень «сильное поведение».

Александр Мишулин
Креативный директор, Nival Interactive

Пример с Total Annihilation — неординарный способ добиться баланса. Используется в индустрии редко, но все же. Утопить в огромном количестве юнитов. Умом этот масштаб не охватывается, поэтому каждый находит что-то свое. Свой чит. Но так как читов очень много, они компенсируют друг друга, плюс на минус, — работает. Можно выпускать новые и новые юниты, главное — не переступать некоторые законы. Там были свои проблемы, несколько стратегий на грани фола, которые использовались в многопользовательских играх. Однако этот способ затратен по ресурсам, потому что все эти сотни машинок надо нарисовать.

Дмитрий Лисица
Гейм-дизайнер Primal Software

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

RSS
Нет комментариев. Ваш будет первым!
Загрузка...

Понравилась статья?

Поддержи нас, чтобы мы создавали больше полезных ресурсов!

Случайная статья