monster
Как я создал Монстра
game_loops
Игровые циклы (core loops)

DevGAMM Hamburg 2015: Чему меня научили авторы Witcher 3 и This War of Mine

  • Сентябрь 20, 2015
  • 4 комментария

10-11 сентября в Гамбурге прошла конференция DevGAMM. На мой взгляд, событие историческое, так как это первый раз, когда DevGAMM прошел как европейская конференция, а не как конференция разработчиков из стран СНГ. Скажем спасибо Лерике Маллаевой за это достижение. За то, что вытаскивает нас из родного болота.

На конференции я помогал Маше показывать Message Quest на шоукейсе. Её отчет можно почитать тут. А ещё бегал с фотоаппаратом, и мои фотографии можно посмотреть тут. 

К слову о шоукейсе. Вспомнил, что когда-то платил немалые деньги, чтобы показать свою игру на Ярмарке Проектов на КРИ 2009. Бесплатное участие на DevGAMM:Showcase кажется какой-то магией в сравнении с теми временами. Главное, чтобы игра была хорошего качества и смогла пройти отбор. 

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

 stan_just

Начну с Ведьмака 3. От CD Projekt Red выступал Стен Юст (Stan Just), арт продюсер Witcher 3. Доклад Стена обязателен к просмотру, как только он появится на официальном канале конференции. Я не буду его пересказывать, лишь выделю несколько моментов про организацию продакшена (из лекции и последующей беседы в кулуарах). Все-таки Стэн — тот человек, который отвечал за производство 1500+ катсцен, а значит, знает толк в продакшене.

 w3_structure

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

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

 stan_just2

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

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

Когда сюжет квестов готов, то он расписывается на ассеты и таски. Уникальные объекты, предметы одежды, головы, анимации, озвучка, катсцены и т.п.

 stan_just3

Ещё интересный момент. В редакторе карт дизайнеры видят метки, обозначающие “вот тут есть катсцена, осторожней”. Хотя дизайнер не может в один клик посмотреть катсцену (её запуск несколько сложнее), он всё равно предупрежден, а потому аккуратен в этом месте. 

Вообще, скажу я вам, крутая штука, когда в редакторе карт можно оставлять комментарии. Это помогает в общении между художниками и дизайнерами, работающими над одним контентом. Дизайнеру проще написать прямо в локации “расчисти тут проход”, чем объяснять художнику на пальцах, что он имеет ввиду. А художник может сообщить, что он собирается переделать какую-то часть локации и сейчас лучше геймплей там не создавать.

 twom_prototype_whynot

Теперь немного о прототипах от Гжегожа Мазура (Grzegorz Mazur), ведущего программиста This War of Mine. Гжегож рассказал о том, как 11bit Studios прототипировали This War is Mine. Для меня ключевым моментом стал факт, что они сначала каждую систему прототипировали отдельно, и затем всё наработки собрали в единый прототип игры.

 twom_prototype_demo

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

 twom_prototype_excel

Конечно, доля правды в моём подходе есть, но двухстадийный подход Гжегожа мне нравится больше. Сначала поделать отдельных прототипов так, как это удобно сделать в каждом конкретном случае (что-то накодить, что-то набросать в экселе, что-то собрать из конструктора лего, а прототип арта делать просто картинкой). Все-таки прототип всей игры — это большой кусок, который сложно прожевать. Так что вполне разумно разрезать его на маленькие кусочки. Как, собственно, следует делать с любой большой и непонятной задачей. 

На всякий случай напомню народную мудрость: “Нельзя лечить продакшеном ошибки препродакшена”. 

На этом всё. Смотрите записи докладов. Готовьтесь поехать 10-11 декабря на DevGAMM в Минске.

 

  • Анна

    Спасибо, интересный материал. А на русском отчет по Message Quest есть (про Гамбург)? (что-то не нашла)

  • Pingback: Videos Online And More! DevGAMM Blog()

  • Pingback: Видео онлайн и многое другое! DevGAMM Блог()

  • Cadmus

    По Ведьмаку пока нечего сказать, еще не смотрел. По This War of Mine скажу — это зависит. Если у вас маленькая студия/мало ресурсов и/или вы делаете новую игру (пусть новую только для вас) тогда этот подход имеет смысл. Если у вас много ресурсов и/или вы делаете сиквел или делали подобную игру раньше — есть смысл прототипировать на живую. Разработчикам Assassins Creed нет смысла выносить отдельно фичи — у них многие механики переходят из части в часть — еще некоторые добавляются — их есть смысл пристраивать сразу к тому, что уже есть.

Switch language:
Facebook