Пара слов начинающему дизайнеру уровней


Ярослав Кравцов
Ведущий дизайнер уровней компании G5 Entertainment AB. Участвовал в разработке мобильных и казуальных игр по франчайзам Star Wars, The Sims, The Simpsons, Hellboy, Saints Row, Red Faction для таких издателей как Electronic Arts, THQ, Konami.

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

Левел-дизайну не учат в школах, его не преподают в институтах. А значит, нельзя требовать от дизайнера уровней профильного образования, как, скажем, от программиста или художника. Но это не означает, что левел-дизайнером может быть кто угодно. Не факт, что этот «кто угодно» сможет собирать волшебные уровни. Ведь уровни это то, что игрок может наблюдать в игре до 100% игрового времени. Если игрок попал на плохой уровень, то он с него никуда не денется длительное время, и за это время у него успеет сложиться плохое мнение об игре в целом. Это будет особенно печально, если случится в демо-версии.

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

Совет №1: Адекватное восприятие игры
На мой взгляд, самым важным качеством ЛД является способность четко осознавать разницу между игрой и процессом ее создания. Что игра должна быть в радость, а работа есть работа, и не наоборот. Он должен понимать, что это в готовой игре все гладко и без ошибок, а в ходе разработки ошибки неизбежно будут. Ведь человеку свойственно ошибаться. И лучше найти свои промахи самостоятельно, а не надеяться на тестеров. Для этого ЛД в первую очередь должен понимать, кто такой игрок, и как он будет вести себя на уровне (как будет, а не как должен — игрок ничего никому не должен).

Плохо: ЛД два часа кропит в редакторе, а затем час носится по уровню. После чего считает свой уровень «шедевральным» на основании того, что он неплохо провел час времени в игре. На критику огрызается. Не знает, что такое редизайн. Уровни подозрительно напоминают о той игре, в которую он играет не меньше двух часов каждый день.

Хорошо: ЛД — сверх-игрок. Он не играет в свои уровни, он их осматривает с целью понять, как этот уровень увидит игрок и что ему может не понравиться.

Совет №2: виденье игры
Пока у ЛД нет виденья игры, за ее создание лучше не браться. Иначе игра станет дневником, в котором ЛД будет отмечать свое настроение и недавно просмотренные фильмы и игры. Для формирования единого виденья существует ГДД и концепт-арт. Если эти материалы не предоставлены, то ЛД должен их требовать, а не ждать, когда его попросят переделать двухмесячную работу.

Плохо: ЛД думает, что у него есть единое виденье игры, но не замечает, как это виденье меняется в зависимости от текущего дня (после выходных, перед выходными).

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

Совет №3: набор фич и их распределение
ЛД должен знать, какие фичи планируются вообще и какие должны использоваться на том или ином уровне. Чтобы ЛД не строил непроходимых заборов, когда у персонажа есть возможность лазить по стенам. Чтобы ЛД не перетянул на свой уровень все фичи, поломав тем самым Learning Curve. Чтобы ЛД не оставил ту или иную фичу незаслуженно забытой.

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

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

Совет №4: непрерывность насыщенности
В любой момент игрового процесса на уровне должно быть что-то, имеющее смысл для игрока. Не должно быть моментов, когда нет ничего интересного. Это касается как геймплейных ситуаций, так и графических красот. Если игрок заскучает от хождения по однообразным пустым коридорам, то нет прощения ЛД. Игрок не должен скучать. Мы же индустрия развлечений, ё-маё!

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

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

Хорошо: Когда события идут так плотно, что игрок, сев на 15 минут посмотреть, что за игра, отвлекается от нее лишь после финальных титров.

Совет №5: контрастность
Любой момент уровня (читай — геймплея) должен отличаться от остальных. Сначала игрок отстреливает врагов, потом исполняет акробатические кульбиты, затем получает дозу сюжета и вновь бьет супостатов. Ибо если игрок покрошил пачку негодяев, а ему снова подсовывают такое же испытание, то он заскучает от необходимости совершать однотипные действия. Зато если на трассе после сложных поворотов дать прямой участок, то его прямота станет особенной. Как белое на фоне черного становится еще белее.

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

Хорошо: Если уж решили делать сочное мясо, то нужно продумать не менее сочное отсутствие мяса. Например, места на уровне, где нет врагов и очень красиво.

Совет №6: яркость
Если уж делать то или иное место в игре, то делать его ярким и запоминающимся. Это непросто. Я бы даже сказал, что это неочевидно, и явного рецепта яркости дать не могу. Однако ярко, это, как минимум, не тускло. Так что если отказываться от всех унылых элементов, то можно, в конце концов, прийти к яркости. А если добавлять уникальные, запоминающиеся штрихи, то путь к яркости будет короче.

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

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

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

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

Хорошо: Еще на стадии прототипа выявили опасные технические моменты и сообразили, как с ними бороться. Левел-дизайнер, собирая уровни, не только осознает их визуальную и геймплейную крутизну, но еще и представляет, как оно заработает в реальных условиях. А это не столько достигается попыткой все заранее рассчитать, сколько приходит с опытом.

Совет №8: умеренная предсказуемость для игрока
ЛД должен сделать свою работу так, чтобы игрок всегда понимал, куда ему двигаться дальше, но не чувствовал себя посаженным в вагонетку на рельсах. Если игрок застрял и не знает что делать, то это не его вина. Также нельзя, чтобы одни и те же игровые элементы вели себя по-разному без видимых на то причин.

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

Хорошо: Угомонившийся левел-дизайнер понимает, что игрок играет ради удовольствия, а удовольствие — это когда у тебя все получается. Поэтому ненавязчиво намекает игроку, куда двигаться дальше. И с разнообразием настройки врагов не выпендривается, ведь так и игроку понятнее, что к чему в игровом мире, и баланс проще настраивать.

Совет №9: командная работа
Я думаю, не надо объяснять, что чем больше размах игры, тем больше команда людей, которые над ней работают. А команды бывают разные: слаженные и не очень. Логично, что хорошие игры получаются у хороших команд, а хорошие команды — это те, в которых хорошая командная работа. Как я уже говорил, через ЛД проходят труды программистов, геймдизайнеров, художников, моделлеров, звуковиков, сценаристов и прочей творческой братии, а затем их ждет еще и тесное общение с тестерами. А значит, ЛД должен контактировать со всеми этими людьми, а не прятаться за фразы типа «что мне сказали, то я и делаю, а остальное не ведаю». При разработке будут возникать проблемы, которые нельзя решить в рамках одного отдела, и тогда нужно брать в охапку программистов/художников/геймдизайнеров/продюсеров/кофедринкеров и обсуждать эти проблемы и способы их решения. Не стесняться требовать, ведь это специфика профессии.

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

Хорошо: ЛД знает, что ошибки в исходном материале не исправятся чудесным образом в конечном уровне. Знает, что программисты тулзов сами могут не догадаться, чем можно облегчить жизнь ЛД и сократить сроки разработки.

Совет №10: приоритеты
Часто слышно, как разработчики жалуются, что будь у них еще немножко времени, и они таки сделали бы игру лучше, вычистили в ней баги. Это нытье. Сроки разработки это то же, что и технические ограничения. Надо правильно спланировать работу над уровнем: схема, грубая сборка уровня целиком, проверка геймплея, внесение изменений, более аккуратная сборка, правка крупных багов, правка низкоприоритетных багов. При таком подходе срыв сроков уже не так страшен: лучше целый неидеальный уровень, нежели только половина, но более красивая. В этом плане мне нравятся слова Сальвадора Дали: «Работа над по-настоящему великим полотном может и должна быть завершена за шесть дней. После этого картину можно отделывать до бесконечности, но по истечении указанного срока полотно в общих чертах завершено, и вышло оно таким, каким ему предназначено быть».

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

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

Совет №11: играть в собственные уровни
Если в редакторе уровень кажется нормальным, чему вторит игра в дебаг-режиме, то все равно заключительное слово за игрой на том устройстве, под которое она делалась, и без читов. А для пущей уверенности надо выбросить из головы схему уровня и играть только по тому, что видно на экране. ЛД, будучи создателем уровня, знает, как его надо проходить, куда смотреть, что делать. Вот надо от этого абстрагироваться и взглянуть на уровень глазами игрока. И тогда вполне возможно, что уровень окажется непроходимым или же весьма занудным. Это перекликается с советом №1, только в одном случае ЛД видит результат через редактор карт, а в другом — через игру. Поскольку игра делается для тех, кто будет познавать ее вторым способом, то разработчик просто обязан сам играть в собственные игры. Если он этого не делает, сваливая эту обязанность на плечи QA, то значит он балбес, и качество делаемых им игр ему безразлично.

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

Плохо: ЛД разделяет свою работу на любимые и нелюбимые части. Он любит долго ваять в редакторе и не любит сотый раз играть один и тот же момент на уровне. Соответственно, у ЛД затык с отладкой уровня, так как он не проверяет собственные изменения.

Хорошо: ЛД способен сам отсмотреть собственный уровень и вычистить его от очевидных ошибок, не запуская конвейер внутреннего и внешнего тестирования. К тому же существует ряд ошибок, которые может заметить только ЛД и 2% игроков, которым не повезло.

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

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

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

Совет №13: аккуратность
По сути, это продолжение предыдущего совета, только с расширением ответственности на весь проект. В аккуратной работе не только меньше ошибок, но и те, что найдутся, будет гораздо проще исправить. К тому же, если над одним уровнем работают несколько человек, то требование все делать аккуратно становится обязательным. Это, в первую очередь, будет проявлением уважения к коллегам, которые станут разбираться в том, что ЛД оставит после себя.

Плохо: ЛД оставляет часть работы на потом, а когда возвращается, то не может разобраться в своем же огороде.

Хорошо: ЛД делает работу так, что другой ЛД, будучи подключенным к проекту, сможет быстро понять что к чему.

Совет №14: набор уровней как оскароносный сценарий
В игре обычно есть сюжет. И если это приличный сюжет, то в нем будет каноническая структура: экспозиция, завязка, усложнение, перипетии, кульминация, развязка, финал. ЛД стоит обратить внимание на эту последовательность и перенести ее на геймплей в наборе уровней, составляющих игру. Начать со спокойного туториала, затем продемонстрировать первые проблемы и далее по нарастающей, но апогей сложности должен быть не на последнем уровне, а перед ним. Конец игры — это конец геймплея. Поэтому нужен буфер между раскаленным геймплеем и его отсутствием.

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

Хорошо: После эпической битвы на огромной карте идет финальный бой с боссом на достаточно скромной карте, где кроме босса нет других сложностей. А сам босс хоть и не прост, но более проходим, нежели предыдущий уровень.

Совет №15: правдоподобие как способ погружения
Чтобы игрок мог погрузиться в игру, он должен поверить в нее. Для этого любое дизайнерское решение должно быть логично, иметь подобие в реальном мире игрока. Если ЛД конструирует завод, то такой, в котором могли бы работать виртуальные человечки. Если прокладывает реку, то не делает ее такой, какими реки в нашем мире не бывают (если только это не является ключевой особенностью). И пускай никакие виртуальные человечки не работают на нашем заводе и не сплавляются по реке, но у игрока есть фантазия, и он будет домысливать увиденные образы.

Потому в играх так часто встречаются туалеты — это не от сортирного юмора, а потому, что игрок увидит, что виртуальным человечкам тоже надо ходить в туалет, а значит, они живые и весь мир игры живой. Пример — Fallout 3.

Однако, без фанатизма. Геймплей не должен страдать от правдорубства на уровнях, и в случае такого конфликта лучше уступить геймплею. Например, серия Prince of Persia, чьи роскошные замки сложно представить пригодными для мирной жизни.

Плохо: ЛД боится, что игроку будет неудобно в тесных помещениях (хотя, на самом деле, неудобно самому ЛД), и поэтому дает игроку неправдоподобно большие комнаты. Желая пустить игрока змейкой по маршруту, укладывает змейкой речку, а игрок удивляется способности речки разворачиваться на 180 градусов и иметь начало и конец на одной и той же высоте.

Хорошо: ЛД старается не щеголять фразой «игровая условность», потому что он немножко «того» с головой и живет в своих фантазиях, которые воплощает через редактор. Он не будет делать этот мир неуютным.

Совет №16: пространство по фэн-шую
Я не специалист по фэн-шую, но мне нравится идея рассматривать окружающую обстановку как пространство потоков энергии. Ведь игрок и есть поток энергии. Ему нужно позволить плавно течь из комнаты в комнату, из емкости в емкость.

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

Хорошо: ЛД чувствует потоки на своем уровне. Убирает с пути игрока препятствия. Не заворачивает его не туда, но и не дает разгоняться. Он знает, какую задать ширину ущелья для танкового раша, чтобы атака не захлебнулась, или ущелье не превратилось в поле со стенками.

Совет №17: искусственное и не очень
Довольно очевидный совет для опытного ЛД, но, к сожалению, весьма актуальный для начинающих. Там, где предполагается искусственность (жилые дома, индустриальный интерьер) должны преобладать прямые линии и не менее прямые углы. Когда же речь идет о естественных объектах, созданных матушкой-природой, то никаких прямых линий и углов не должно быть в помине.

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

Хорошо: ЛД чувствует в каком случае какие изобразительные средства нужны и не терпит, когда линии скал, рек, оврагов рисуют абсолютно прямыми, а лес похож на лесопосадку.

Совет №18: копипаст — друг и враг
Самый быстрый способ создать уровень, это создать его часть, а затем расклонировать ее. Это же способ создать самый худший уровень. Поэтому нужен баланс между скоростью и качеством. А еще игроку удобно, когда он видит знакомые элементы дизайна и знает, как с ними быть. Но игрок будет негодовать, если игра будет однообразной. И вообще игрок может заблудиться, если перепутает разные части уровня, потому что они выглядят одинаково. Так что, копируя базовые элементы, нужно вносить поправки, отличающие копию от исходника.

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

Хорошо: ЛД в своей работе использует все доступные техники, в том числе копипаст. Но без палева. Копирует только общие детали, наделяя каждую из них своими уникальными мелочами.

Совет № 19: игроки — они разные
Одним нравится грубое насилие, другие предпочитают утонченность. Одним нравится искать секреты, а другие нервничают от того, что не умеют и не хотят разыскивать эти секретные места. ЛД не должен считать, что игрокам понравится то, что нравится ему. Поэтому ЛД должен оставлять игроку возможность играть в том стиле, который ему больше по душе.

Плохо: ЛД, не отдавая тому отчет, делает игру для себя и очень ругается на непонимание коллег, попробовавших его творение на зуб. Потому что ему нравится медленный геймплей, с посещением всех нычек, а коллеги предпочитают быстрый темп и разбиваются о дисбаланс.

Хорошо: для ЛД любой геймплейный момент — головоломка, которую можно решить несколькими способами. И это не для replayability, а для игроков разных типов.

Совет№ 20: отказ от круглого
Быть кратным десяти — уныло. Быть кратным пяти — тоже не круто. Топ10 — было уже миллион раз. 20 советов — глупое ограничение сверху. Игрок не бегает по уровням с рулеткой, но он почувствует фальшь, если все элементы будут привязаны к грубой сетке. Надо понимать, что, например, «3, 10, 23, 25, 37, 50, 64, 100» — это равноправный набор чисел, и не надо заводить в нем любимчиков. Просто нам нравятся числа, которые удобно считать в уме, но это еще не повод использовать только их. Коли плохи дела с устным счетом, то надо держать калькулятор под рукой, а не выбирать легкий путь десятикратных чисел. Особенно странно использовать круглые числа там, где с ними не требуется проводить устные вычисления.

Совет № 21: вдохновение
Я бы не советовал начинать создание уровней с пустого листа, отрицая существование других игр. Чтобы хорошо делать свою работу, надо вдохновляться, смотреть, как сделаны локации в других играх, какие существуют технологии и приемы. Заимствовать что-либо не надо, это подрубает оригинальность проекта и вообще является дурным тоном. Но изобретать велосипед тоже нерационально. И не надо думать, что если знать игродельческую кухню, то играть в игры становится неинтересно. Наоборот, как художник способен прочувствовать все тонкости полотна мастера, так игродел сможет в полной мере вкусить от творчества своих коллег.

Совет №22: век живи — век учись
Допустим, есть несколько моделей домиков и задача построить из них на уровне деревню. Можно сразу намалевать две пересекающиеся дороги и расставить домики вдоль них. А можно сначала поискать фотографии деревень (от Проскудина-Горского до наших дней), посмотреть на реальные деревни в Google Earth, почитать про градостроительство. Любую творческую задачу можно выполнить лучше, если пополнить свой багаж знаний о ней.

Совет №23: правильная лень
Хороший ЛД — ленивый ЛД. Лень долго делать свою работу, а потом еще и переделывать. Поэтому ленивый ЛД предпочитает выполнять поставленные задачи быстро и без необходимости многократно их дорабатывать.


***

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

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


http://dtf.ru/articles/read.php?id=55126