29 января в Высшей школе экономики прошли две лекции от специалистов в сфере геймдизайна. На Хабре был анонс сего мероприятия, и я решил посетить и написать обзор.
1. Прототипирование для чайников: как сделать хорошую игру
Лектор — Кулешов Степан, продюсер в Banzai Games.
Главный вывод первой половины вечера такой: многократная проверка своих идей нужна всегда нужна ДО релиза всей игры. No Man’s Sky на старте была чистым воплощением идеи, и это был провал. Аудитория, которая играет в неё сейчас, после стольких патчей, несравненно меньше стартовой: все наигрались в ключевые механики и покинули игру из-за потери интереса.
Чтобы избежать такого же конца, нужно создавать прототипы. Они дают обратную связь, должны делаться максимально быстро и должны полностью отражать то, что вы хотите протестировать. Правда, последние два пункта всегда находятся в противоречии. Но даже идеальный прототип лишь позволит повысить вероятность того, что вам удастся получить ценную информацию для развития игры, а денег он в любом случае будет стоить.
Прототип делаем не на каждую фичу, но на каждый проект.
В конце лекции выступающий раскрыл тему стоимости прототипа:
Чистая стоимость очень зависит от жанра, самой игры и от того, что тестируете. Если я скажу какую-то цифру, она не будет значить ничего. Если в процентном отношении, то, думаю, все прототипы занимают где-то 10-20% от стоимости всей игры.
Тестировать с помощью прототипов приходится всем участвующим в создании продукта: UX/UI, разработчикам, геймдизайнерам. Как сказал лектор: “Мы все немножко прототипируем...”
Прототипирование — необходимо, но это сплошные проблемы. Эта мысль всплывала так часто, что даже я понял. Сумел записать следующие моменты:
- Сложно сформулировать вопросы, на которые хотим в ходе теста получить ответы;
- Сложно выделить независимые объекты, которые можно тестировать по отдельности;
- Сложно показывать наработки другим, обычно тестируют только на себе, на своем опыте;
- Сложно делать плохо: всегда хочется подкрутить там, подкрутить тут и не уложиться в дедлайн. Больше пары дней прототип не делается.
Кто-то в зале уже прототипировал? И как, вам понравилось?
Посреди лекции услышал позади фразу: “Ощущение, что он говорит про эскизы...”. Да уж, сходства между профессиями есть. Казалось бы, всюду говорят о постоянной проверке идей, гипотез, а все равно каждый раз как в первый.
К концу лекции возник интересный спор:
В: Допустим, я задумал аналог Dirt. На что мне делать прототипы? Там же куча всего: трение, прыжки…
О: Делать прототип на каждый аспект, посмотреть как хорошо трение работает на кубике. Но зачем ещё один Dirt?
В: Окей, допустим делаем Dirt в космосе!
О: Нужно тестировать эту идею. Если вы задумали в игре что-то уникальное, то это уникальное отличие нужно стремиться проверить в первую очередь. Делаем прототип Dirt в космосе, а потом выясняем, что в это неинтересно играть, поскольку оказывается, колесам в космосе не за что цепляться!
У кого есть гениальная идея игры, о которой он уже поведал своему другу?
Что, только 2-3 человека? Где все гениальные идеи?
Кто-то в зале задал вопрос: “А что, если при тестировании прототипа украдут идею игры?”
— От идеи до реализации огромная пропасть. Я обычно рассказываю свои идеи: если тот, кому я рассказываю, её реализует, я буду только рад.
Был вопрос о том, как попасть в профессию:
— Обычно в продакшн приходят из продакт менеджеров, из геймдизайна. Я из третьей школы, которую обычно все ненавидят — я из разработчиков. Поэтому я знаю, кто и что не так делает, и не стесняюсь об этом им говорить.
После лекции взял у Степана небольшое интервью:
В: Что изменится в профессии геймдизайнера в ближайшие годы?
О: Геймдизайнер скоро разделится на несколько разных профессий — думаю, это будут балансер, нарративщик, технический геймдизайнер… Левел-дизайнер недавно вот уже выделился в отдельную должность.
В: Какие источники по геймдизайну Вы посоветуете читать, может, что-то из блогов?
О: На русском — это Манжеты ГД, если знаешь английский, то просто вбивай в гугл gamedev forum. Но эти советы больше для новичков, опытным геймдизайнерам обычно понятно, что и как делать.
В: Какие ещё крупные скачки были в геймдизайне?
О: Слушай, ну ты прям валишь… Тетрис когда изобрели, потом был match-3…
В: То есть обычно связано с жанрами, с их динамикой? — Да, сильно завязано на жанры.
В: В лекции вы упоминали проблемы прототипирования. А что, можете сказать о геймдизайне в целом, что пока не решено?
О: Да всё! Как сделать хорошую игру?
В: Ну, это глобальная проблема… — Как сделать баланс, как сформировать грамотный нарратив… Пайплайны ещё не могут быть выстроены нигде. Data Driven казалось бы работает, но и там оказываются проблемы.
2. Левел-дизайн игр
Лектор — Горанский Михаил, старший гейм-дизайнер Mail.ru Group.
Когда я согласился прочитать лекцию, думал, о чем же вам рассказать.
И тут мы получили уровни, которые отдали делать на аутсорс…
Так что я решил показать их ошибки, и ошибки левел-дизайна в целом.
Михаил начал с небольшого обзора. Левел-дизайн отвечает за геометрию уровня, и соответственно, за передвижение игрока. В итоге уровень нужно выстроить так, чтобы толкать игрока к использованию механик.
И далее начался тотальный разбор Blasphemous.
— Смотрите, в таких играх обычно оружие должно проходить сквозь платформы, оно не проходит только сквозь боковые стены. Но здесь не так! Вы не сможете метнуть через платформы, хотя это нужно для победы. Одна из ошибок левел-дизайна: нарушение логики использования механик.
Среди других ошибок были:
- Ограничение пространства ради вау-эффекта
- Кажущаяся доступность области, которая на самом деле не доступна.
Ещё одна ошибка — постоянный повтор механик. Но не всегда, иногда такое допустимо: когда к механике добавляется новая механика, и если механика применяется на сильно измененной геометрии, например, с плоскости переходим на вертикальный геймплей: “После использования механики должно пройти какое-то время, а потом вы визуально или как-то ещё напоминаете игроку ту ситуацию, когда он впервые её использовал, и тут сразу становится понятно, что ему делать.”
Какие же хорошие решения для левел-дизайна прозвучали на лекции?
Во первых, нужно сформулировать набор правил геймплея, и не нарушать их на протяжении всей игры. К примеру, если вы выбрали один вид для двери, которая не должна открываться, то не стоит её внезапно делать единственной открывающейся на уровне. И если вы посреди игры решили что-то изменить, надо сначала это безболезненно показать для игрока, потом ещё раз с малым для него уроном, а потом уже сталкивать с изменившимся правилом на 100%.
Во вторых, надо обязательно заранее сформировать набор стандартных размерностей и дистанций, которыми вы будете измерять все объекты на уровне. Иначе в схожих местах игрок будет применять одну и ту же механику с разным успехом, не понимая, что изменилось. Например, возникнет ситуация, когда длины прыжка физически не хватает для преодоления небольшой пропасти.
Первый уровень, который продаст игру, лучше всегда делать в конце разработки всей игры. Тогда уже глубоко чувствуются связи между механиками и окружением, геометрией уровня.
Часто геймплей портят перегрузом механик. Больше 2-3 механик одновременно игрок не должен использовать, он просто не будет замечать, что нужно делать. Большая проблема сделать так, чтобы игрок страдал, понимая, что это честно, что он виноват. Успех Souls-like игр основан на этом.
Игрок должен испытывать удовольствие, даже когда он страдает — что-то типо правила.
Одним из пунктов было разделение двух подходов к построению уровней в игре: иммерсивность и контекстуальность. Как оказалось, эти термины часто путают. Что же хотел прояснить лектор?
Цель иммерсивности — сделать игру максимально логичной в рамках её сеттинга. Если сеттинг предполагает, что люди ходят в туалет — на уровне обязательно найдется туалет для каждого персонажа. А контекстуальность просто создает фон для непосредственно геймплея. К примеру, Принц Персии — абсолютно контекстуальная игра. Действие происходит в замке, но то, что расположено на уровнях, не может работать как замок. Вам просто говорят, что это замок, есть архитектурные элементы замка, и это работает.
Ферма горит, когда её ударяешь мечом — это контекстуальность? — Да. Ты поджигаешь ферму, поскольку наносишь ей урон, а она не может ответить, потому что она бедный хиппи.
В конце лекции поинтересовались, какие игры с точки зрения уровней сделаны хорошо:
— Это все DOOM, карта De dust из CS, Bloodborne, Showel Knight, Dishonored, Arx Fatalis, Deus Ex, кроме второго…
— А почему De dust столько лет так популярна?
— Там есть несколько хороших моментов: целых три “бутылочных горлышка” — так называются места, где максимально скапливаются игроки. Они не всегда должны быть прям узкими, просто называются так. Далее, все спауны хорошо сбалансированы, они дают разные бонусы, но при этом равные по выгоде. И там ещё встречаются места, которые удобны как для профи, так и для новичков.
Итоги
В целом, лекции были не очень насыщенные, но много интересного прояснилось при в ответах на вопросы из зала. Мероприятие шло с 19:00 до 22:00; понятно, что такого времени мало для полного ознакомления с темами, особенно в отрыве от остальных аспектов разработки игр. Но в промежутке между лекциями и некоторое время после окончания была хорошая возможность задать вопросы лично.
Большая часть интересующихся желали найти возможность поучаствовать в реальных проектах. Хоть мероприятие организовано ВШЭ, здесь были не только студенты; часто люди задавали вопросы о смене своей деятельности на геймдизайн. Конкуренция за кадры тут была нешуточная — как только задавался вопрос о вакансиях, тут же раздавались сбоку просьбы также прислать портфолио и им.
Считаю, что такие мероприятия хорошо подходят именно для общения со специалистами в отрасли, поскольку наиболее релевантная информация об обстановке — именно у них.
