ЦЕНТР ПОДПИСЧИКОВ: ТЕХНИЧЕСКИЙ КОНТЕНТ

К ведущему Джареду Хакаби присоединились директор по техническому контенту Шон Трейси, руководитель направления компьютерной графики Форрест Стефан и технический художник Гейдж Холлман, чтобы обсудить недавние достижения, которые помогают разработчикам воплощать Star Citizen в жизнь.

Джаред: Добро пожаловать на наш первый «Центр подписчиков» в 2018 году. Я ваш ведущий, контент-менеджер по глобальному производству видео Джаред Хакаби, и сегодня с нами эксперты по технологиям. Мы поговорим обо всех технологиях, которые мы разрабатываем или уже разработали для Star Citizen. Справа от меня человек, кто, возможно, не нуждается в представлении. Но мы все же представим его, потому что эти выпуски всегда смотрят новички. Итак, как тебя зовут и что ты делаешь для Star Citizen?

Шон: Ты только что ввел всех в заблуждение. Я справа относительно съемочной площадки, но относительно тебя я сижу слева.

Джаред: Да ладно, кто-то хоть раз при взгляде на меня говорил: «о, этот парень отличает право от лево»? Нет. Никто так не делал.

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

Джаред: Хорошо. А кто сидит не справа от тебя?

Форрест: Меня зовут Форрест Стефан, я руководитель направления компьютерной графики. Обычно я делаю все, что требуется Шону Трейси. Это очень большой объем художественных работ, которые хочет получить Крис.

Шон: Да, и обычно если мы хотим немедленно получить какой-то результат, который точно понравится Крису, мы поручаем эту задачу Форресту. Он уже очень давно работает вместе с Крисом, и у них схожие вкусы. Форрест очень хорошо понимает те вещи, которые ожидает получить Крис.

Джаред: И теперь действительно справа от меня…

Гейдж: Гейдж Холлман, технический художник. Я работаю под руководствам Шона, в основном, над персонажами, персонажными технологиями и различными элементами на серверной стороне.

Джаред: Шон, я знаю, ты участвовал в проекте с самого начала. Когда ты решил присоединиться к Star Citizen?

Шон: Это было забавно. Кто-то отправил мне email на мой старый адрес в Crytek, а потом спросил: «почему ты не получил мое письмо? У тебя все еще есть работающий адрес в Crytek.» Во время изначального лицензирования и оценки стоимости движка я был вовлечен в процесс вместе с Крисом, Форрестом и группой аутсорсеров. В итоге мы покинули Crytek и пришли в CIG, в студию в Остине.

Джаред: А потом присоединился Франкфурт.

Шон: Это произошло спустя три года после моего перехода в CIG.

Джаред: Гейдж, а ты, насколько я знаю, попал на борт благодаря состязанию «Следующий великий космический корабль» (TNGS)?

Гейдж: Да , это забавная история.

Джаред: Итак, если вы смотрите «Центр подписчиков» впервые, то это шоу в формате Q&A, где мы за круглым столом отвечаем на вопросы от подписчиков. Поскольку это эксклюзивное шоу для подписчиков, мы принимаем вопросы только от них через Спектрум – нашу площадку для общения, доступную на сайте RSI. Кликайте на Спектрум, затем заходите в чат для подписчиков и задавайте свои вопросы там. Также мы создали тему в Логове подписчиков – это форумная секция для подписчиков в Спектруме. Там мы на протяжении всей недели собирали ваши вопросы. С них мы и начнем.

• Первый вопрос: в прошлом году вы создали множество основополагающих инструментов, вроде системы ИИ Subsumption, редактора SolEd и др. Можем ли мы теперь предположить, что работа над ними закончена? Что инструменты готовы?

Шон: Абсолютно. Инструменты готовы, и все счастливы с ними работать. Им никогда больше не потребуются доработки или переделки. В первой же своей версии они получились идеальными. Следующий вопрос.

Форрест: Инструменты проходят через стадии.

Шон: Да, конечно.

Форрест: Сначала вы реализуете инструмент, чтобы он помог вам выполнить поставленную задачу. После чего вам приходится повторно проанализировать его и ответить на вопросы: позволяет ли он выполнить задачу так быстро, как нам хотелось бы? Достаточно ли способ взаимодействия с инструментом дружественен пользователю? Обычно при первой реализации наши инструменты довольно сложные, то есть пользоваться ими достаточно сложно. Вы хотите максимально упростить их, потому что это снижает число ошибок, а также ускоряет процесс работы. Обычно инструменты проходят через пару итераций. Думаю, ответ на этот вопрос будет такой: да, они реализованы и кое-как функционируют, но им все еще требуется множество доработок. Мы используем ПО, вроде пакетов от Adobe и Autodesk, с номерами версий 11, 14 и т.д. Развитие этих программ никогда не прекращается, потому что всегда можно что-то улучшить.

Шон: Как говорит Эрик, приходится разглагольствовать по поводу незначительных деталей, чтобы вникнуть в работу этих инструментов. Ненавижу слишком усложнять, но в процесс вовлечено множество слоев и инструментов. Например, вы можете вызвать определенный скрипт в 3D Max, который кто-то написал для художников, запустить редактор «песочницы», который мы используем, или наш патчер копирования билдов – все это инструменты, и у каждого из них существует множество слоев. На данный момент мы работаем над некоторой структуризацией всех этих инструментов, чтобы они точнее подходили для той задачи, для которой мы их используем.

Хороший пример: у нас есть команда по общему инструментарию в Великобритании – ей управляет Мартин Сениор. К общим инструментам относится все, что выходит за пределы редактора. Затем у нас есть команда по инструментам «песочницы» во Франкфурте – ей заведует Саша Хоба. И сюда относятся все инструменты, входящие в наш редактор, например, редактор планет, редактор маршрутов и другие вещи. Потом у нас идет еще один слой инструментов – это инструменты для художников и аниматоров. Мы пишем их поверх DCC-приложений, вроде 3D Max, Maya, Motion Builder. И технические художники как раз тратят очень много времени на их разработку. Мы всегда стараемся ускорить и улучшить рабочий процесс художников по окружению, снизить подверженность различных вещей багам, либо как-то еще автоматизировать процесс. То же верно и для инструментов по анимации. У нас довольно большая команда технических аниматоров – ее ведет Роб Хаус в Дерби.

И сейчас я рассказал только про три различные студии. Можете представить, что между ними происходит очень бурное общение. Много утренних собраний и обсуждений. Это дает вам представление о том, на что похожа команда, но где же мы находимся в данный момент с точки зрения инструментов? Как только появляется какая-то геймплейная система, нам нужно либо сразу же, либо вскоре после ее релиза разработать инструментарий, относящийся к представленным в ней функциям. Он нужен чтобы можно было реализовать эти функции. Так что последнюю пару лет на нас с Форрестом лежала огромная ответственность. Мы целенаправленно были сосредоточены на инструментах для создания контента, потому что знали про огромный масштаб игры.  Учитывая то количество и качество контента, который нам нужно создать, эти инструменты должны быть очень функциональными для художников. Мы не можем использовать такой же подход, как в большинстве AAA-проектов, когда делается один уникальный персонаж – ваш главный герой, а затем к нему добавляется еще 12 персонажей, и на этом все. Мы говорим о тысячах уже созданных игровых ресурсах для персонажей: это рубашки, штаны – что угодно. Затем такая же степень многосложности, если не более высокая, у вас присутствует в окружении. А корабли еще сложнее.

Итак, у нас собраны все эти инструменты и конвейеры, и мы можем реализовать поставленные задачи. Возникает вопрос – где бутылочные горлышки? На что уходит большая часть времени? Потому что все, о чем думает технический художник после того, как заставит конвейер работать, – это как сделать его лучше. Этот вопрос стоит перед нами ежедневно – как сделать инструменты для разработчиков лучше и проще. Но поскольку мы в значительной степени концентрируем свое внимание на инструментах для создания контента, наша способность непосредственно создавать контент значительно превосходит возможность внедрять уже созданный контент в игру. И это не очень хорошо. Допустим, мы разработали большое количество контента (к примеру, игроки пока не видят контент для Squadron 42), но из-за его обилия он может оставаться неиспользуемым на протяжении одного, двух, трех месяцев. А затем что происходит – меняется сама система. Изменения может внести команда по функционалу, или это может быть британская студия – мы без понятия. Но затем происходит то, что я называю «гниением игровых ресурсов» – какой-то элемент так долго остается неиспользуемым, что начинает «загнивать». Баги появляются как бы задним числом из-за того, что изменениям подверглись какие-то основополагающие принципы. Поэтому наш фокус сдвигается. Нам нужно убедиться, что наши инструменты для внедрения контента соответствуют нашей скорости и способности производить конкретный контент.

Джаред: То, о чем ты говоришь, это каждодневные трудности. Так проходит стандартный процесс разработки игр.

Шон: Я думаю, так происходит при разработке любого ПО.

Джаред: Одни команды двигаются вперед быстрее других.

Шон: Да, верно, Это независимые вещи. Люди очень злятся, когда они сделают очень крутой объект, как, например, Джеймс со своим великолепным персонажем, а затем этот объект лежит целый месяц и ждет внедрения. Потом в какой-то момент разработчик возвращается к работе над своим объектом, или кто-то другой берет его для добавления в игру, и оказывается, что там полно ошибок. В итоге приходится возвращать персонажа обратно Джеймсу с претензиями вида: «ты же говорил, что все готово, а на самом деле там полно ошибок!» Такие ситуации могут создавать конфликты, поэтому нам приходится разбираться с ними со стороны инструментария и потоков разработки. Это постоянный непрекращающийся процесс. Мы никогда не закончим работу над инструментами, и нужно с этим смириться. Но это также значит, что нам нужно очень четко выставлять приоритеты для каждого элемента, основываясь на глобальных «бутылочных горлышках», которые не дают двигаться дальше.

Изначально в CryEngine у нас была очень прочная концепция – «что вы видите, то вы и получаете». Теперь она перешла в Lumberyard. Ее суть в том, что когда дизайнеры работают над уровнем, и кто-то из них создает какой-то элемент – давайте использовать его. Вот как эта банка с Red Bull. Мы ставим банку на стол. Теперь дизайнер захочет протестировать ее и посмотреть, как она в действительности расположена в игре. Если ему придется пройти через все этапы: запустить приложение, скомпилировать код, потратить 20 минут на блуждание по уровню, чтобы в итоге увидеть кружку на столе, он поставит ее однажды и никогда больше не станет возвращаться к этому вопросу. Даже если кружка стоит неидеально (например, мы хотим, чтобы она стояла на бумажке), дизайнер не станет ничего переделывать. Ведь чтобы даже чуть-чуть передвинуть кружку ему придется заново потратить 20 минут на прохождение всех этапов. И мы как раз пытаемся улучшить эту концепцию «что вы видите, то вы и получаете».

Иногда она может идти вразрез с механизмами работы системы. В том смысле, что иногда для системы важно, чтобы вы не обновляли все объекты в реальном времени, а вместо этого запекали, сохраняли, экспортировали их или еще как-то фиксировали их на месте. Но концепция «что вы видите, то вы и получаете» никогда не будет зафиксирована. Она всегда подвержена изменениям, к ней всегда можно обратиться. Думаю, некоторые из разработанных нами в прошлом инструментов не то чтобы должны быть переделаны, но скорее перестроены под новые потоки разработки. Хороший пример тут – это Subsumption. Мы рассматривали использование GU ID с контейнерами объектов – это просто такой метод идентификации определенных контейнеров объектов. Subsumption использует список всех этих ID, и проблема для дизайнера в том, что если он создает новый контейнер объектов, он не может вручную добавить его в список, дождаться генерации билда, а затем посмотреть на нововведения. И это как раз идет в разрез с функциональностью концепции «что вы видите, то вы и получаете». Это большое направление в области разработки инструментов.

Надеюсь, я ответил на вопрос.

Джаред: Короткий ответ – нет, мы не закончили работу над инструментами.

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

Форрест: Изначально мы потратили время на сбор отснятого видео для Криса. Команда QA и некоторые разработчики занимались записью этих материалов, затем они вернулись от Криса, и он попросил меня пройтись по ним, сделать обзор и дополнить их некоторыми дополнительными видео.

Джаред: Подожди. Когда ты говоришь «записать видео», надо понимать, что мы делаем это точно так же, как и вы, парни. Мы загружаем игру, открываем OBS. При записи мы пользуемся тем же игровым клиентом, который доступен вам.

Форрест: В прошлом механизм рендеринга для кат-сцен, вроде трейлера из оригинальной кампании по сбору средств и наших рекламных роликов для кораблей, работал так, что нам сначала приходилось все устанавливать в редакторе, затем запускать игру через редактор движка, и только после этого он визуализировал происходящее в видеофайл. Все это мы делали вручную. Скажем, если я хотел, чтобы мимо пролетел корабль, мне нужно было создать быстрый эффект частиц, прикрепить его к двигателю, затем в программе указать правильный ключевой кадр, когда нужно активировать этот эффект… В общем, все делалось вручную, как при создании фильма. Но затем наши инструменты становились все более и более сложными. Шасси у кораблей начали убираться автоматически, и инструменты по своему функционалу стали превосходить наши кинематографичные методы создания роликов. Нам стало очень сложно вручную создавать такие трейлеры и кат-сцены. И мы поняли, что ранее мы показывали художественные наработки, но теперь пришла пора начать показывать вместе с ними также игровой процесс и механики. Поэтому кат-сцены эволюционировали, перешли от демонстрации художеств к демонстрации игры. Ведь прочие элементы важны ничуть не меньше, чем визуальная составляющая.

Пожалуй, впервые цель была обозначена предельно ясно – захватить видео прямо из игры. Крис четко дал понять, что он хочет именно видео из игры. Мы начали записывать видео, и многие полученные материалы оказались довольно грубыми. Так вышло из-за того, что мы использовали недоразвитые инструменты, вроде камеры наблюдателя, режиссерской камеры и других. Не важно, как мы их назовем. И я сказал: «Хорошо, дайте мне попробовать». Я попробовал, и они оказались такими неотесанными. Я не понимал, как мне передвинуть камеру. Сначала вам нужно зажать F4, а затем буквально поставить локоть на клавишу, чтобы двигать камеру вверх-вниз. Потом нужно положить палец на правый джойстик для вращения камеры… все функции работали подобным образом. За полторы недели я отрастил третью руку. Я подзывал случайных людей и говорил: «Мне нужно, чтобы ты удерживал эту клавишу, пока я буду делать что-то еще». Потом я смотрел на отснятый материал и понимал, что он мне не нравится, потому что тут нет движения камеры, не используется правило третей, или просто что-то идет не так. Инструмент не задействовал весь тот потенциал, который Крис использовал для синематиков.

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

Форрест: Итак, мы приступили к созданию трейлера 3.0. Это был «живой продукт». Знаете, многие люди спрашивали, как нам удалось получить такой высокий FPS и прочее. Часто, когда я заходил в игру, там на сервере было не так много народу.

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

Однако перед нами также стоял вопрос, как добиться приемлемого FPS. Так что я заходил в игру в 2 часа дня и спрашивал: «Парни, кто хочет поиграть со мной?» Затем, действуя практически в тайне, я записывал свой игровой опыт вместе с другими игроками.

Как мне удалось привлечь игроков? Я спрашивал: «Кто хочет поиграть со мной?» А меня спрашивали в ответ: «А какие корабли у тебя есть?». И я отвечал: «Все.»

Шон: «Отлично, давай вызывай Bengal.»

Форрест: Так я играл с людьми, попутно привлекая нашу внутреннюю команду QA на матчи в Star Marine. Фактически я изучил инструменты, для создания которых приложил все усилия. Я играл в игру и записывал свой игровой опыт.

Джаред: И теперь у нас есть трейлер.

Форрест: Да, и Крис посмотрел и сказал: «Вижу, ты можешь это сделать.»

Конечно, но мне кажется, мне удалось показать процесс несколько проще, чем есть на самом деле. Потому что это сложно. Это было настоящим испытанием. Но часть моей работы состоит в том, чтобы дать Крису то, чего он хочет. Он был восхищен моим желанием переработать механизм записи видео. Я хочу эти режиссерские камеры, они мне нравятся. Я знаю, что у Криса за плечами опыт работы в киноиндустрии, так что он это понимает. Мы хотим иметь возможность задействовать кинематографичный режим не только в Squadron 42, но и в Постоянной Вселенной, потому что кто же откажется от возможности записать свой игровой опыт. Игроки в любом случае будут снимать такие видео. Как это называется? Машинима. Я любил снимать их, когда был помладше. Так что я вернулся в детство и спросил себя: «Насколько круто будет иметь возможность делать это и вот это?»

В общем, мы решили создать инструмент. Мы решили взять текущие режиссерские и наблюдательские камеры, доступ к которым есть у каждого из вас (нужно только нажать F4, заложить локоть за голову, ну и так далее) и построить на их основе инструмент. Первый шаг, как мне кажется, это просто захватить что-то и определиться с интерфейсом. Надо посмотреть, кто занимается подобными задачами на данный момент. Вы же не изобретаете колесо с нуля – вы отталкиваетесь от существующих наработок конкурентов. Вам предстоит проанализировать, что у них получается хорошо, а что не очень. Затем вы, по сути, развиваете идею (это не кража!). И вам всегда нужно идти в ногу с современными технологиями. Всегда нужно знать, чем занимаются люди вокруг вас. Делать свою работу так же хорошо и даже лучше. Я спросил у Шона и еще у некоторых людей, кто сейчас делает что-то подобное. Кто лучший? И он ответил, что это Mario Odyssey.

Шон: Я много играл в Mario Odyssey со своими детьми, да и сам тоже. Идея в том, что там нет никакого барьера, есть только режим снимков. И это хороший инструмент, он очень дружественен к игроку – именно к этому и стремится Форрест. Было очень забавно использовать Марио в качестве референса, особенно отправлять его Крису. Скриншот из Марио с активированным режимом снимков.

Джаред: И как все прошло?

Шон: Знаете, он сказал, что это шикарно. Вот от чего нам стоит отталкиваться. Как, кстати, и от Nvidia Ansel с другой стороны. Цель здесь – создать дружественный к игроку инструмент, который удалит барьер для входа и при этом окажется столь же мощным, как Nvidia Ansel или режим снимков в Марио. Даже в Zelda есть режим скриншотов, с которым вы можете работать. Я думаю, сделать наш инструмент столь же доступным – это достойное стремление.

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

Шон: Да, да. Ожидания от релиза инструмента по кастомизации довольно явные. Очень важно здесь смотреть, как эту задачу решают другие разработчики, о чем как раз упомянул Форрест. Как реализована кастомизация в играх вроде Black Desert Online или Destiny. Подход к кастомизации везде различается. И с самого начала мы хотим предоставить лишь базовые возможности, вроде выбора голов, причесок, глаз и расцветок.

Джаред: Для первого этапа?

Шон: Да, но даже в процессе реализации такого ограниченного опыта кастомизации все равно можно наделать ошибок. Одной из таких ошибок будет, например, недостаточно интуитивный интерфейс. Также нужно убедиться, что система разработана с прицелом на дальнейшую масштабируемость. Как я уже говорил ранее, из-за различного уровня взаимодействия между командами из разных студий может получиться так, что какой-то элемент будет разработан, но он не удовлетворит ожиданиям Криса, Тодда или моим собственным. Так что в основном работа теперь перешла целиком к команде по функционалу. Это междисциплинная команда, состоящая из программистов, инженеров по интерфейсу и художников, и все они работают сообща над одной задачей. Они довольно успешно продвигаются вперед, но что интересно, Гейдж еще месяц назад закончил работу над игровыми ресурсами, и в одном из прошлых шоу я говорил, что это наша цель на 3.0. Однако интерфейс оказался не готов, он не соответствовал нашим требованиям, поэтому ввод системы в строй пришлось отложить. Но Гейдж еще в октябре или ноябре прошелся по всем необходимым ресурсам.

Джаред: Скажи что-нибудь, Гейдж.

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

Джаред: Всегда в конце?

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

Джаред: Очевидно, эта первая версия кастомизатора персонажей, которая запланирована к релизу вместе с 3.1, не окажется последней. Что в ней будет, а чего не будет?

Шон: Не будет скульптинга – таков замысел.

Джаред: И DNA. Это первая версия, мы говорим о первой версии.

Шон: Да, и DNA. Мы можем предоставить вам и их, но тут есть трудности, о которых я уже говорил раньше. Они связаны с логикой работы ригов (// наборов из скелета и оболочки персонажа, прим. перев.) и желанием, к примеру, добавить поддержку Faceware для лиц и разделение анимаций. А в дальнейшем мы хотим даже иметь возможность обновлять имплементацию кода ригов прямо во время его исполнения и сохранять его для вашего персонажа. Это как раз и называется DNA. Но это не столь же просто, как разместить парочку смешанных форм и переключаться между ними, и на то есть множество причин. Конечно, мы можем так поступить, но итоговый результат окажется не тем, чего мы ждем от этой системы. Поэтому у вас будет возможность выбирать головы, прически и глаза и менять их цвета.

Я имею в виду, что мы уже определились с некоторыми вещами, вроде того, что в текущем потоке разработки у нас для каждой прически должны быть свои изображения. Но является ли такой подход в достаточной степени масштабируемым? Не следует ли нам применить тут рендер в текстуру для волос? Потом оказывается, что волосы прекрасно отображаются при рендере в текстуру, и возникает вопрос, как все это собрать. Очень много рутины, с которой приходится разбираться. Вот почему эту задачу передали отдельной команде по функционалу. Но возвращаясь к Гейджу, он уже собрал все эти игровые объекты, потому что нам нужно обеспечить их работу для Squadron 42, Постоянной Вселенной и для всех дизайнеров. Все потому, что у нас есть инструмент для редактирования лиц и редактор экипировки – с их помощью мы создаем всех НИП.

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

Шон: Для Squadron 42 это было одной из интересных и сложных проблем. Мы можем также рассказать, как мы справились с ней для PU, но в Squadron размеры голов и шей различались. Думаю, в «Вокруг Вселенной» мы расскажем, как нам удалось применить эту систему для Takaka – одного из наиболее интересных персонажей в Squadron 42.

Гейдж: Он под два метра ростом.

Шон: Да, два метра или около того. Он реально большой. Я сбился с мысли… Так, там были разные размеры при переходе от головы к шее. И это кажется логичным, потому что у разных людей просто разные пропорции, но проблема возникает, когда вы используете модульную систему. Например, рубашка не растягивается в плечах. Она просто не двигается, как положено, из-за чего вы не можете использовать одну и ту же рубашку для разных персонажей. Вот почему мы решили использовать систему ярлыков. Вы знаете, класс 1 и класс 0 – это высококачественные персонажи, которые получили свою собственную индивидуальную одежду. Она была разработана исключительно для них. Я не могу сейчас приводить примеры, но кем бы они ни были, они индивидуальны.

Как мы разрешили эту проблему в PU – мы унифицировали форму шеи. У нас был набор различных форм, которые мы унифицировали.

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

Форрест: Мы в буквальном смысле прошли мимо его стола, а Гейдж смотрел и решал, какие варианты выглядят странно. Если вариант сильно бросается в глаза, значит это уже другой персонаж, и мы зашли слишком далеко. Вы не можете менять форму черепа, потому что в противном случае у некоторых людей просто окажутся огромные головы. И вам нужно надеть на голову кепку.

Гейдж: Нельзя просто растянуть голову, это не будет так работать.

Шон: Здесь присутствуют компоненты, относящиеся к классу сущностей головы персонажа. Каждый из них несет в себе сложную логику и инициирует работу групп других сущностей на теле персонажа. Вот где на сцену выходит комплексность. Опять же, порой я завидую другим играм, поскольку очень сложно создать систему, которая будет делать все сразу. Как правило вы можете создать систему и сделать для нее некоторые поблажки, основанные на дизайне вашего геймплея. Если вы разрабатываете MMO, вы можете сделать иные поблажки, нежели при разработке однопользовательской сюжетной игры. И теперь вы понимаете мою проблему – нам нужна система, которая, во-первых, должна сосуществовать в PU и SQ42, во-вторых, отвечать за все.

Джаред: И мы пытаемся ее создать.

Шон: Да. Я бы не стал делать как-то иначе.

Джаред: Это причина, по которой мы начали проект. Мы так работаем, и никак иначе. Никто не может указывать нам, что мы способны сделать, а что нет.

Шон: Ну, кроме Криса.

Джаред: В общем, с 3.1 мы намерены предоставить вам нашу первую версию системы кастомизации персонажей. Вы увидите головы, глаза и прически. И, конечно, мы продолжим работать над ней, добавлять функции и в конце концов придем к реализации системы DNA. Как и со всеми прочими элементами в Star Citizen, это итерационный процесс разработки.

Хороший момент, чтобы отметить, что к нам поступает множество вопросов о работе системы страхования. Украденные корабли и все такое. Хочу сказать, что больше информации на этот счет вы получите в пятничной трансляции «Обратной стороны Вселенной». У нас в гостях будут Тодд Папи и Брайан Чемберс, и мы поговорим с ними о наших будущих планах касаемо пиратства и подобных вещей. Но уже сейчас я могу сказать вам, что комментарии в Спектруме были даны в таком же ключе. То есть Уилл Мейден говорил о текущей реализации системы страховки и о том, как кража кораблей работает в 3.0, 3.1 и 3.2, но ни в коем случае он не имел в виду долгосрочный дизайн. Пока что мы не вносили никаких изменений в долгосрочный дизайн. И мы попросим Тодда Папи прояснить данный момент в пятницу. Присоединяетесь к эфиру, чтобы узнать о планах по обновлению будущего дизайна.

Шон: Это был самый лучший уход от ответа на вопрос, который я когда либо слышал.

Джаред: Мне это уже не впервой.

Итак, вернемся к вопросам из чата.

• Крис в «Обратной стороне Вселенной» упомянул, что у Hull C есть проблемы с раскладыванием из-за анимированной физической сетки. Знаете ли вы что-нибудь об этом? То есть пока работа над Hull C приостановлена, а занятые над ним люди назначены на решение других задач. У нас есть решение?

Шон: Нет, мы пока не нашли решение. Но это не потому, что решения нет, а потому, что мы не работаем над ним. Проблема в основном относится к самой системе физики и ложится на плечи инженеров по физике, которые сидят во Франкфурте. Команда столкнулась с парочкой проблем, но одна из них – это как раз анимированная физика. Это та вещь, которая требует изменений, что снова возвращает нас к концепции «что вы видите, то вы и получаете». Но та система, которую мы используем на данный момент, в любом случае будет переработана. Это довольна статичная система физических сеток в том смысле, что после реализации она уже не меняется. Мы можем включать или выключать ее, но в самом движке заложены такие фундаментальные принципы, когда концепция зон противопоставляется концепции сущностей. То есть зона не является и не может являться сущностью, следовательно со стороны кода вы не можете реализовать такой же функционал в пределах зоны, какой доступен вам для сущности.

Еще один пример зоны (а физическая сетка – это именно зона) – VisArea – объект, использующийся для определения зоны, где будет происходить отсечение невидимых линий и оптимизация. Эти объекты наряду с порталами вызывают определенные регионы или зоны, с которыми порой возникает та же самая проблема – они не анимируются. Так что каждый раз, когда мы хотим изменить корабль, мы сталкиваемся с этой проблемой. Она возникает даже при разрушении корабля.

Но у Hull C есть и другие проблемы. Кажется, кто-то делал быструю сборку, где к Hull C было прикреплено 50 Hornet или подобных кораблей. Но не думайте, что вы сможете сделать так же! Просто это дает представление о влиянии на производительность в том случае, когда корабль укомплектован таким большим количеством груза. Снижение производительности в данном случае в первую очередь затрагивает графический процессор, а не центральный, и это действительно беспокоит нас. Нам предстоит разобраться с некоторыми вопросами тут, но среди них нет ничего непреодолимого. Всего лишь дело времени… и денег.

Джаред: Это одна из тех вещей, где мне часто приходится заявлять, что мы занимаемся именно разработкой, а не производством игры. Мы ищем, обнаруживаем ответы, а не просто берем готовые чертежи и строим по ним игру. Нет такого, что мы нанимаем рабочих, они приходят и видят все готовое на чертежах – нужно лишь следовать инструкциям. Разработка игры – это процесс постоянных проб и ошибок.

Шон: Ты только что назвал нас строителями-подрядчиками?

Джаред: Может его, или его.

• Ранее мы немного затронули тему того, над чем работает Форрест. Речь об инструменте для управления камерой. Но над чем вы, парни, трудитесь в данный момент?

Шон: Я уже начал рассказывать о структурах инструментов и концепции возвращения к отложенному контенту. Если вы хотите погрузиться в детали, то конечно я шутил по поводу Форреста, но на данный момент я трачу много времени на работу над этим. Не буду жаловаться, но я все же скучаю по возможности просто открыть редактор и взяться за решение проблем напрямую. Я работаю с командами, создающими различные инструменты. Расставляю приоритеты на год и убеждаюсь, что мы поддерживаем команду по функционалу.

Гейдж: Со своей стороны я отвечаю за разработку инструментов по работе с персонажами в Maya. Приходится много работать с британской командой и Робом Хаусом в Дерби, постоянно общаться с ними. Здесь мы создаем инструменты, которые затем синхронизируются с их инструментами, внедряем их проверки на жизнеспособность, помогаем направлять весь процесс работы над персонажами. Так что мы можем распространять наши инструменты напрямую командам по персонажам. Они создают свои модели и все необходимое и проводят тесты, чтобы убедиться, что все хорошо. Затем результаты автоматически передаются обратно нам, и мы можем благополучно запускать свой конвейер. После завершения всех этапов следует внедрение.

Джаред: Следующий вопрос от подписчиков:

• Привет, Шон. Давненько мы не слышали про Faceware. Как там обстоят дела с ней?

Шон: Продвигаются вполне успешно. Прошло уже много времени с того момента, как мы решили использовать ее. Думаю, мы впервые показали технологию на Gamescom, затем у нас был установлен комплект на CitizenCon, где мы демонстрировали ее в работе в реальном времени. Существуют еще некоторые вопросы относительно производительности, с которыми мы хотим разобраться. На данном этапе я не думаю, что кто-либо согласится выпустить Faceware в качестве игровой функции, если она хоть как-то будет влиять на производительность. Никто не хочет падения производительности. Предполагаю, что и игроки не захотят, чтобы технология оказала какой-либо отрицательный эффект на производительность. Так что мы стараемся полностью разобраться с этим моментом. Как всем известно, в работе над Faceware не было задействовано огромной команды. Напротив, ее реализацией занимались всего два-три человека. Это Грэм Филлипс в Великобритании, а также некоторые ребята из команд QA и дизайна.

В общем, функция работает онлайн, она есть в игре, но ее пока нет в PU – она отключена. Но мы готовы к ее внедрению. Осталась еще пара вещей, вроде хорошего интерфейса для игроков, потому что у нас много инструментов, которые просто сидят в консольных переменных. У нас теперь есть новая концепция внутренних командных структур и междисциплинные команды, поэтому FOIP как функция будет направлена одной из таких команд. Большая часть тяжелой работы уже выполнена, так что им нужно лишь создать для нее интерфейс – будь то оверлей Спектрума или меню опций – чтобы вы могли настраивать различные параметры. Я реально хотел добавить ее в инструмент создания персонажа. Мне кажется, это будет очень увлекательной вещью – управлять мимикой своего персонажа в процессе скульптинга.

Короче, нам надо добавить интерфейс со множеством различных опций. Дизайнерам придется взглянуть на него, чтобы определить, как этот интерфейс будет согласовываться с видеовызовами игроку, и как будет работать структура группы. Так что Faceware как игровая функция готова, но она подвергается уже упомянутому мной «гниению игровых ресурсов». В том смысле, что с ее внедрением в игру не было особого продвижения. Однако работы над самой функцией продолжаются, Грэм все еще вносит изменения в механизм ее функционирования. Должно быть она появится уже скоро. Не уверен, есть ли она в нашей Дорожной карте, но она появится.

Джаред: На данный момент ее там нет, потому что у ребят, которые будут ее внедрять в игру, сейчас много другой работы. На данный момент мы не можем точно предсказать, в каком квартале она будет выпущена, поэтому мы пока придерживаем ее. Тут как с Hull C. Люди знают, что мы работаем над ним, они видели его в «Вокруг Вселенной», но корабля на данный момент нет в Дорожной карте. Мы добрались до определенной точки в его разработке, но теперь нам нужно разрешить некоторые проблемы внедрения. Однако дело в том, что ответственные за это разработчики нужны нам для работы над другими задачами, которые являются более ценными для Постоянной Вселенной на данный момент. Если быть честными, мы можем добавить Hull C в PU в 3.1, но вам все равно понадобится возможность загружать и разгружать груз для него. Я имею в виду, что другие игровые системы, которые необходимы для реального функционирования PU, все еще не выпущены. Это одна из таких вещей, которую вы можете «приколоть», а людей перевести на работу над более важными задачами. То же самое и с имплементацией Faceware. У нас есть ребята для ее внедрения, но сейчас они заняты другими делами.

Шон: И я готов подтвердить, что в прошлом мы откладывали какие-то функции, когда они не были в достаточной мере готовы. Я знаю, сообщество всегда защищает нас, в том смысле, что это Альфа, но мы не судим о вещах с позиции альфа-версии, мы судим о них с позиции живого, выпущенного и полностью завершенного коммерческого продукта. Так что с учетом такой концепции нам нужно быть более осторожными с релизом игровых функций. Это очень классно, что мы можем предоставить эти функции вам, ребята. Я раньше уже упоминал об этом – прослойка между разработчиками и сообществом в CIG очень тонкая, они находятся очень близко друг к другу. Вы можете работать над какой-то функцией, которая уже через неделю окажется в руках игроков. И это пугает, потому что обычно мы остаемся вне сети на годы и тратим это время на работу с собственными функциями, их внутреннее использование и поиск проблем. А затем, когда функция наконец выходит в релиз, вы можете быть уверены, что с ней все будет хорошо. Но наша прослойка очень тонкая.

Форрест: Для меня это 24 часа.

Шон: Возможно. Даже такое вполне возможно. Я создавал какую-то вещь, и спустя всего лишь 24 часа она уже находилась в чужих руках.

Гейдж: Пара вещей, над которыми мы работали, отправились в релиз.

Шон: Да, я видел, что монокль показался в списке изменений патча. Крупное ли это нововведение? Нет, конечно. Так ли он важен для игры? Да нет, не особо. Но мы работали над этой штукой шесть месяцев назад, и он до сих пор не был выпущен. Но мы знаем, что консьержи все равно его получат. Мы увидели, что его собираются выпустить в релиз, и не поняли, с чего вдруг. Он не прошел весь путь внедрения, но это была работа на 10 минут. Пара кликов, и готово. Просто я совершенно не ожидал увидеть его в списке изменений патча. Взяли и добавили, вот так тоже бывает.

Джаред: Монокля нет в 3.0. Он намечен на релиз в 3.0.1. Как раз хорошая возможность упомянуть, что прошлой ночью мы выпустили патч 3.0.1 для тестирования Эвокати.

Шон: Так это значит, информация не подлежит разглашению? А я только что все разболтал. Это провал.

Джаред: Да, мы трудимся над патчем 3.0.1, который содержит небольшие исправления багов. Это не патч 3.1, который станет нашим крупным квартальным релизом и будет включать в себя всю работу по оптимизации. Основная задача 3.0.1 – решить проблему «мячика для гольфа» или «шарика для пинг-понга», или как вы его еще называете.

Шон: Проблема в том, что вы здесь, и скелет персонажа тоже здесь. И этот шарик на самом деле является представлением скелета. Помните, два года назад я хотел добавить каркасное представление для скелета, чтобы когда это произойдет, я бы знал причину? В какой-то степени я даже рад, что мы так не поступили, потому что я не ожидал, что игроки вообще когда-либо увидят это. Разве что при возникновении бага. Но все равно я рад, что мы этого не сделали, иначе вокруг бы бегали персонажи из проволоки. Маленький шарик, как я полагаю, в данном случае безопаснее. Он обозначает начальный узел модели.

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

И на этом сегодняшнее шоу подходит к концу. Может хотите еще что-то сказать сообществу перед уходом?

Гейдж: Я может быть предложу сделать пасхалку – нарисовать лицо Криса Робертса на этом шарике.

Джаред: Да, ты можешь предложить. Мы будем сидеть тут и слушать . Вообще я часто подкалываю Криса. Играюсь с его телесуфлером и прочими вещами. В общем, я подкалываю его чаще, чем кто-либо еще.

Форрест: Ты предложил, твое предложение отвергли.

Джаред: В общем, на этом мы завершаем январскую трансляцию «Центра подписчиков». Возвращайтесь сюда в пятницу, когда мы проведем трансляцию «Обратной стороны Вселенной» в очень удобное для Великобритании время – в 8 часов утра. Так что вы сможете увидеть разницу между Диско в полдень и Диско в 8 утра. С нами будут Брайан Чемберс и Тодд Папи, и они ответят а вопросы по материалам выпуска «Вокруг Вселенной», который на этой неделе посвящен новостям из студии во Франкфурте. И конечно мы расспросим Тода и его текущем видении пиратского геймплея.

Я Джаред, со мной были Шон, Форрест и Гейдж. Увидимся в следующий раз.

Перевод: H_Rush

Обсудить на форуме star-citizen.ru

Источник: https://star-citizen.ru