DevGAMM Hamburg 2015: Чему меня научили авторы Witcher 3 и This War of Mine
- 20 сентября, 2015
- 4 комментария
10-11 сентября в Гамбурге прошла конференция DevGAMM. На мой взгляд, событие историческое, так как это первый раз, когда DevGAMM прошел как европейская конференция, а не как конференция разработчиков из стран СНГ. Скажем спасибо Лерике Маллаевой за это достижение. За то, что вытаскивает нас из родного болота.
На конференции я помогал Маше показывать Message Quest на шоукейсе. Её отчет можно почитать тут. А ещё бегал с фотоаппаратом, и мои фотографии можно посмотреть тут.
К слову о шоукейсе. Вспомнил, что когда-то платил немалые деньги, чтобы показать свою игру на Ярмарке Проектов на КРИ 2009. Бесплатное участие на DevGAMM:Showcase кажется какой-то магией в сравнении с теми временами. Главное, чтобы игра была хорошего качества и смогла пройти отбор.
Ладно, я тут не отчет о конференции собрался писать, а рассказать о новых знаниях, которые вынес с конференции. К сожалению, не смог присутствовать на большинстве докладов потому что был занят на шоукейсе. Но те доклады, куда удалось попасть, отставили у меня след, и мне хочется им поделиться.
Начну с Ведьмака 3. От CD Projekt Red выступал Стен Юст (Stan Just), арт продюсер Witcher 3. Доклад Стена обязателен к просмотру, как только он появится на официальном канале конференции. Я не буду его пересказывать, лишь выделю несколько моментов про организацию продакшена (из лекции и последующей беседы в кулуарах). Все-таки Стэн — тот человек, который отвечал за производство 1500+ катсцен, а значит, знает толк в продакшене.
Во-первых, по организационной структуре. Каждая команда имеет двух людей во главе — продюсера и лида. Продюсер отвечает за планирование, а лид — за качество. Это разумно, так как по опыту знаю, что если эти функции объединены в одном человеке, то невольно возникает перекос либо в одну, либо в другую сторону. Впрочем, имеет смысл только для больших команд.
Во-вторых, у них следующий подход к сборке игрового мира — он делится на составляющие (города, поселки, леса) и над каждой составляющей работает свой набор специалистов. Есть художники, работающие над оформлением. Есть левел-дизайнеры, работающие над оформлением и базовым геймплеем на локации. А есть дизайнеры квестов, которые на этих локациях создают сюжетные квесты. После чего команда катсцен создает все необходимые катсцены.
Мне было интересно, как же столько людей, работающих над одним контентом, не мешают друг другу. Стен говорит, что это потому что все знают сюжет. Левел-дизайнер не уберет случайно дом, в котором проходит часть квеста, потому что он знает, что этот дом нужен по сюжету. Плюс, раз в неделю все команды синхронизируются.
В итоге пайплайн получается следующим: сценаристы пишут основной сюжет, на уровне “вот тут должна быть свадьба”. Дизайнеры квестов прорабатывают историю, сочиняя квесты про свадьбу. У них достаточно свободы творчества, чтобы их история перекладывалась на геймплей. Главное не отходить от общей темы. Раз сказали “свадьба”, то значит нужно делать свадьбу и сопутствующие активности.
Когда сюжет квестов готов, то он расписывается на ассеты и таски. Уникальные объекты, предметы одежды, головы, анимации, озвучка, катсцены и т.п.
Ещё интересный момент. В редакторе карт дизайнеры видят метки, обозначающие “вот тут есть катсцена, осторожней”. Хотя дизайнер не может в один клик посмотреть катсцену (её запуск несколько сложнее), он всё равно предупрежден, а потому аккуратен в этом месте.
Вообще, скажу я вам, крутая штука, когда в редакторе карт можно оставлять комментарии. Это помогает в общении между художниками и дизайнерами, работающими над одним контентом. Дизайнеру проще написать прямо в локации “расчисти тут проход”, чем объяснять художнику на пальцах, что он имеет ввиду. А художник может сообщить, что он собирается переделать какую-то часть локации и сейчас лучше геймплей там не создавать.
Теперь немного о прототипах от Гжегожа Мазура (Grzegorz Mazur), ведущего программиста This War of Mine. Гжегож рассказал о том, как 11bit Studios прототипировали This War is Mine. Для меня ключевым моментом стал факт, что они сначала каждую систему прототипировали отдельно, и затем всё наработки собрали в единый прототип игры.
Честно говоря, для меня это было откровением. Потому что раньше я думал, что нужно сразу делать прототип всей игры. Чтобы всё то, что должно быть фаном в игре, было уже в прототипе. И чтобы не было такого, что сделали прототип голой механики, и сразу после этого запустили продакшен.
Конечно, доля правды в моём подходе есть, но двухстадийный подход Гжегожа мне нравится больше. Сначала поделать отдельных прототипов так, как это удобно сделать в каждом конкретном случае (что-то накодить, что-то набросать в экселе, что-то собрать из конструктора лего, а прототип арта делать просто картинкой). Все-таки прототип всей игры — это большой кусок, который сложно прожевать. Так что вполне разумно разрезать его на маленькие кусочки. Как, собственно, следует делать с любой большой и непонятной задачей.
На всякий случай напомню народную мудрость: “Нельзя лечить продакшеном ошибки препродакшена”.
На этом всё. Смотрите записи докладов. Готовьтесь поехать 10-11 декабря на DevGAMM в Минске.
