Головна » Статті » На дозвіллі » Різне

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

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

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

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

no continied



Джерело: http://www.dtf.ru/articles/read.php?id=55126
Категорія: Різне | Додав: TormoYaDer3814 (01.04.2003)
Переглядів: 1225 | Теги: дизайн, разработка, гейм, уровень, игровой, level, Developer, постройка, игра, дезайн | Рейтинг: 4.0/1
Всього коментарів: 0
avatar