Вокруг Вселенной — выбор и последствия, Система Миссий (полный перевод, видео+текст)

СГ: Привет, и добро пожаловать на очередной эпизод Вокруг Вселенной – нашего еженедельного взгляда на продолжающуюся разработку Star Citizen. Я – Сэнди Гардинер.

ДХ: А я – Джош Херман

СГ: У нас припасено кое-что крутое для вас сегодня. Позже в шоу мы поговорим с Тони Зуровеком и другими, чтобы узнать побольше об улучшенной системе миссий. Она должна привнести целую кучу геймплея в Постоянную Вселенную.

ДХ: Но прежде чем мы перейдем к этому, сейчас время для нового выпуска Burndown, где мы обсудим весь прогресс в работе над релизом Alpha 3.0 за эту неделю.

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

С возвращением к Burndown, нашему еженедельному шоу, посвященному проблемам, мешающим релизу Star Citizen Alpha 3.0. Прошлую неделю мы завершили с 76 обязательными к исправлению ошибками, которые были приоритизированы как 10 блокеров, 50 критических, 14 с высоким приоритетом и две со средним. Давайте сверимся с командой, чтобы увидеть, как мы продвигаемся.

Дистанция короткого квантового перелета установлена слишком далеко, так что перелет между лунами или пунктами, между которыми не должно быть замедленной версии, слишком долгий. Около 25 минут назад или около получаса Майк Диллон говорил об этом. Способ исправить эту проблему для Майка, вероятно, может заключаться в откате изменений.

В общем баг с системой квантовых перелетов был связан со слишком медленным перелетом по системе. Наша звездная система огромна. Не столь велика, как настоящая Солнечная система, но она схожа по масштабам. И недавно мы ввели перелеты на близкие расстояния между точками, находящимися близко друг к другу, вроде точек вокруг планеты. К сожалению, при наших расчетах мы не учли то, как быстро мы летим, и в наших коротких перелетах динамически рассчитывали лишь то, как быстро достигается скорость квантового перелета, и как быстро происходит замедление. Одним из решений, что также исправляло проблемы с выбором цели, была замена физического «толчка», который мы использовали, когда «подталкивали» корабль вперед, на просчитываемую оболочку того, где вы должны находиться. Мы могли передать значения, что через пять секунд вы должны быть там-то при такой-то скорости, что также позволило нам отрегулировать время разгона и замедления совместно с дизайнерами, чтобы они знали, что могут изменять это, чтобы сократить этот аспект. И теперь это позволяет нам медленно путешествовать вокруг планет, но при этом быстро летать между самими лунами, что занимает всего 5-6, может 10 секунд в зависимости от расстояния. Мы все еще работаем над подкруткой этих значений, чтобы у нас были отличные долгие интересные перелеты, когда вы можете выбраться из кресла и погулять по кораблю и так далее, но, чтобы перелет с одной стороны планеты к другой все же не занимал пол часа, ибо это не весело. У нас была другая проблема с тем, что иногда мы летели слишком быстро, так как слишком сильно ускорились в другом направлении. В общем все это было вопросом балансировки кода, чтобы убедиться, что он все верно просчитывает, а также работы с дизайнерами, чтобы визуальная часть и ощущение полета соответствовали их ожиданиям, а затем работы с визуальными эффектами, чтобы заставить все это выглядеть красиво. И в конце концов все сложилось отлично, так что теперь это работает довольно хорошо. Есть еще несколько правок, которые мы хотим внести, но основной объем работы завершен.

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

В общем недавно мы разбирались с багом в ПУ для билда 3.0. Я хотел уронить корабль на персонажа на посадочной площадке, просто чтобы увидеть анимации. Но в итоге корабль взорвался.

Корабль взрывается, а игрок просто стоит на месте, будто ничего не случилось. Корабль влетает в него, давайте поставим паузу, корабль взрывается, а парень такой: «да без проблем». Есть другое видео, корабль влетает в человека и затем взрывается, а парень продолжает летать, будто ему все-равно и ничего не случилось.

В QA мы считаем, что размер имеет значение, а потому я заспавнил Starfarer. И вот я разгоняюсь… и довольно быстро Starfarer также взрывается.

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

Это связано с тем, как вы описываете баг. Вы берете, тащите одну ветку, и как по цепочке решается несколько заявок в Jira. Вроде вот этого: «Проспектор не получает урона по двигателям». UV перекрывает проблему, которую я пытаюсь вывести на более высокий уровень, так что мне все-равно надо будет переговорить с инженерами на сегодняшней планерке, чтобы сказать им, что это две вещи, которые мне необходимы для достижения 3.0. Остальное тоже было бы неплохо для вещей в 3.0, но эти две просто необходимы для меня.

Отлично, по кораблям на данный момент, как я сказал, дела идут в разной степени плохо. Мой звук будет тогда, когда они вернут текущие временные отрезки или карты UV и урона. Это касается где-то трети кораблей. Остальные получили достаточно ухода, так что можно их запускать.

Еще одной важной механикой 3.0, на которой мы фокусировались в этот раз, является логика восстановления после потери соединения. Это значит, что теперь мы можем различать намеренное и ненамеренное отключение. Намеренное отключение – это когда вы открываете меню и выбираете выход – это намеренное отключение. Но при ненамеренном отключении может быть любая ситуация, когда вы теряете соединение с вашим провайдером, а может произошел вылет клиента, и вы пытаетесь вернуться в игру. Так что когда бэк-енд определяет, что произошло ненамеренное отключение, то мы сохраняем мета-данные игрока, а также токен резервирования соединения к определенному игровому серверу для вашего респавна. Так что когда вы подключаетесь обратно, то перед вами сразу же появится всплывающий диалог, в котором говорится: «Эй, а не хотите ли переподключиться к игровому серверу, к которому вы были подключены в последний раз?». И когда вы соглашаетесь, система матчмейкинга поместит вас в тот инстанс. И в этом весь смысл, знаете, сетевой объект между сервером и клиентом должен синхронизироваться, и задача заключается в том, чтобы заспавнить вас именно в той же локации вселенной, в которой вы были на момент потери соединения.

Я хочу пройтись по всем срезам, а в первую очередь я хочу быть уверен, что вы можете легко путешествовать по системе. И об этом как раз весь набор этих механик. Вы знаете, начиная с посадки в корабль и взлета, работы системы TC, работы квантовых перелетов, посещения локаций и так далее. Вот все это мы должны заставить работать. И это же касается карты или прыжков на байках. И чтобы взлететь, вы проделываете все эти штуки. И я думаю, что это действительно хорошие вещи для Эвокати, это весело, можно проделывать довольно много штуковин. И затем, когда будет готов этот набор из 26 оставшихся багов… Не забывайте, что эти 26 багов я хочу исправить, чтобы Эвокати могли приступить, но я уверен, что мы исправим еще кучу прочих вещей одновременно с этим. И затем, когда у нас будет этот набор фиксов, мы сядем с Тоддом и скажем: «Хорошо, а на каких механиках мы хотим сосредоточиться далее?». И мы отберем, скажем, еще 10-20 элементов, которые нужно как следует просмотреть, или, может, 10-15, и мы скажем: «Так, вот еще 17 проблем, которые нужно исправить к следующему релизу для Эвокати. Давайте заставим все это работать.» При этом есть еще список фиксов помимо этого. Нужно разбираться с одной механикой за раз и продолжать в том же духе. И вот так мы и разберемся со всем этим.

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

На момент съемки мы уменьшили общее число обязательных к исправлению ошибок на 50, некоторые путем исправления багов, а некоторые отложили на потом, чтобы мы смогли сфокусироваться на полировке прочих. И как сказал Эрин, у нас остается 26 ошибок, мешающих первому релизу для группы Эвокати. Так что возвращайтесь на следующей неделе, чтобы продолжить наблюдать изнутри за продвижением к релизу 3.0 в Burndown.

ДХ: Помните, что мы также публикуем обновления для графика разработки 3.0 каждую неделю. Вы можете найти его на нашем сайте, чтобы узнать больше деталей о статусе 3.0.

СГ: Давайте теперь перейдем к системе миссий. Со всеми лунами и планетами, запланированными в Star Citizen, было важно спроектировать систему генерируемых миссий, которые смогут обеспечить много контента.

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

СГ: Давайте взглянем.

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

Большой сложностью с игрой является то, что это очень большая вселенная. И нам нужно наполнить ее интересным контентом и интересными занятиями. И работа, которой я занят для системы миссий, заключается в попытке создать замечательные инструменты, которые дизайнеры могли бы использовать для генерации интересного контента, а также чего-то вроде многоразового контента.

Вместо того, чтобы дизайнеру надо было говорить: «в этой миссии должно быть 3 корабля, из которых два должно быть пиратами, а один – охраной», они должны говорить: «Эй, нам нужно что-то вроде отдельной миссии, где пираты и UEE сражаются друг с другом». И система смотрит на вселенную и говорит: «На самом деле эта часть звездной системы – довольно богатая область, где может быть довольно много кораблей охраны, так что мы заспавним целую кучу кораблей охраны, и, наверное, одного пирата, который попал в зону, а теперь пытается вырваться». И наоборот, может быть что-то вроде: «Ох, это довольно опасный район, это довольно бедная область вселенной, довольно суровая, мы бы хотели тут банду пиратов, а может одного-двух пиратов, но с пиратским подкреплением, готовым прыгнуть и присоединиться к ним.» И таким образом вселенная становится гораздо более случайной и живой, вместо того, чтобы дизайнеры специально указывали: «Эй, каждый раз, когда вы прилетаете в эту определенную часть космоса, вы будете находить двух пиратов, сражающихся с одним кораблем UEE.» И что мы хотим быть способны делать, это сказать: «Вот корабль, знаете, у него есть инженерный отсек, мостик, столовая» и дизайнеры хотят быть способны сказать: «Хорошо, кораблю нужно два пилота, 4 охранника и группа инженеров… поехали». И система должна суметь определить, где именно на корабле эти персонажи должны появиться, а также создать их с верными паттернами поведения.

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

Редактор Subsumption, созданный Тони, позволяет дизайнерам устанавливать требования для кораблей, чтобы мы могли сказать: «Ок, супер, знаешь, нужно такое-то количество пилотов с таким-то поведением, и нужно такое-то количество охранников с таким-то поведением. Но подбор логичных мест для спавна этих персонажей был еще той проблемой. Некоторое время персонажи появлялись поверх столов, стоящими поверх корабля. И со временем мы находили логичные места для персонажей. Так что это был довольно долгий процесс улучшения, но мы достигли цели.

Вещи, которые позволяет делать Subsumption, заключаются… Я могу просто найти позицию на трех планетах, я могу найти аванпост на одной из этих планет, десятки сотен аванпостов, сколько бы у нас их не было, а затем я могу найти комнату, и заспавнить коробку в любой из них.

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

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

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

Работа с Subsumption довольно схожа с тем, как мы привыкли работать с FlowGraph. Это все еще визуальный редактор скриптов, и нам все еще нужно создавать миссии с объектами и логикой прогресса миссии. Но Subsumption позволяет нам создавать вещи более модульным способом, и более многоразовым. Так что, скажем, если мы вернемся к той миссии, где мы подбираем коробку с планеты, а точнее с аванпоста, мы бы создали немного логики, которую можно использовать для любого количества миссий, что-то вроде того, что когда вы подбираете коробку, вам показывает цель, куда ее нужно отнести, а когда вы бросаете коробку, то цель появляется на коробке. В Subsumption нам достаточно выстроить эту логику один раз, чтобы использовать ее множество раз во многих миссиях. Сейчас кажется, что это действительно незначительная мелочь, но возможность выстроить ее однажды и использовать множество раз среди контента миссий, на самом деле означает, что игровой опыт более последователен, а также это освобождает время для того, чтобы мы делали более интересные вещи.

Одной из самых больших сложностей на пути к внедрению Subsumption был выбор правильных людей. Многие годы я строил схожие, но гораздо менее продвинутые системы для игр, так что я смог довольно быстро сформировать хорошее представление о работе архитектуры. Но что мне действительно было нужно, так это коллега со стороны игры, кто-то, кто имел дело с похожими проблемами и говорил на том же языке, но у которого было очень-очень детальное знание CryEngine. И нам очень повезло, что мы смогли взять на борт столько талантливых людей из CryTek в 2015 году. И одним из них, в частности, был Франческо Роккуччи, ведущий инженер по ИИ с кучей опыта. Затем мы привлекли еще несколько человек к работе, и в результате многие вещи на разных фронтах разработки продвигаются довольно уверенно. Последняя вещь, которую я бы упомянул в этом контексте, которая продолжает оставаться проблемной для релиза Subsumption, это то, что я бы назвал системой In-point. Это часть технологии, от которой часто зависят куски логики Subsumption. Например, нахождение пути, было работоспособным уже пару лет, но лишь относительно недавно множество визуальных глюков начало исправляться. Такие вещи могут звучать чисто косметическими, но резкие повороты, задевание стен, неверное ускорение – все это может быстро выбить вас из игрового мира и разбить то ощущение погружения, которого мы пытаемся достичь. Было еще множество других проблем с анимацией, особенно связанных с используемыми предметами, которые нужно было решить до того, как персонажи смогли бы правильно взаимодействовать со всем, начиная со стульев и заканчивая контрольными панелями, контейнерами и так далее. Subsumption тесно интегрирована с нашей системой контейнеров объектов, которой нужно было подрасти до определенного уровня до того, как мы могли бы двигаться дальше. И это лишь один из примеров среди множества систем, на которых завязаны Subsumption, и которые должны были достичь определенной функциональности до того, как система смогла бы реально притворяться в жизнь. И вот почему внедрение Subsumption в 3.0 столь важно. Это значит, что множество других важных игровых систем сейчас начинают либо использоваться в игре, либо достигли определенного уровня готовности. И вот почему я ожидаю, что в будущем геймплей начнет продвигаться гораздо большими скачками, чем ранее.

Однажды я пытался заняться отладкой двух персонажей, и обычно мы занимаемся отладкой прямо на экране, у нас есть специальный функционал в игре, когда вы смотрите на персонажа и нажимаете кнопку «слэш» на цифровом блоке клавиатуры, и тогда вам сразу же покажет на экране, что он пытается сделать, его поведение. То есть интерфейс показывает поведение, скажем, активность, в которой он задействован, саб-активность, задействованную логику, переменные и то, что мы зовем индивидуальным логом. Индивидуальный лог схож с тем, как мы говорим о персональной истории, потому что… то, как я пытаюсь управлять поведениями, я реально пытаюсь рассказать историю их решений. Так что вы можете прочитать, и сказать что-то вроде: «О, я действительно разозлен, мне нужно пойти и подобрать что-то… Ох, я не смог найти что-то, так что я собираюсь купить что-то другое.» И вы можете видеть из истории, если что-то идет не так, ибо вы знаете, какую историю хотите рассказать, и если что-то странное происходит, то вы сразу же заметите. Ну и было практически невозможно заниматься отладкой сразу двух персонажей из-за пространства на экране, так что мы создали визуализатор Subsumption – что-то вроде интерпретатора системы со стороны игры и движка. И в начале я отлаживал что-то вроде активностей, а затем я получил помощь от Дейва, так как он хотел заниматься и отладкой миссий с утвержденным дизайном, и я сказал: «Ок, тогда я добавлю отладчик миссий». И он начал с тех вещей, которые были нам нужны. А потом людям действительно начало нравится, ибо они такие: «О, теперь я могу следить за безграничным количеством логов, а не только видеть последние пять строк, и я могу видеть изменения». А затем мы начали внедрять прочий функционал, например, Дейв помог мне внедрить возможность изменения значений переменной на ходу. То есть можно взять поведение, где есть время, скажем пять минут, и когда вы хотите протестировать его, но не хотите ждать пять минут, так что можно поменять время или значение. Или вы можете переназначить значения, чтобы метки снова сработали.

А потом мы общались с дизайнерами и, конечно, когда мы стали разговаривать, их проблема была типа: «Ой, да я проходил всю миссию лишь для того, чтобы вызвать один диалог в конце миссии!» Я в основном работаю со специалистом по программированию здесь в Германии, с Колом Гэбриалом, и мы создали то, что мы называем вкладкой диалогов в визуализаторе Subsumption. И там можно видеть все доступные диалоги. Когда вы выбираете один, вы можете видеть, какие собеседники нужны, а затем вы можете проверить в игре, какие доступны среди всех персонажей в игровом мире. Вы можете выбрать их и нажать старт, и можно вызывать диалог снова и снова, чтобы убедиться в правильности очередности и логики. Или может вы хотите протестировать освещение в игре, вы можете вызвать диалог и убедиться в корректности освещения и постановки. Да, действительно можно вызвать его снова, если вы хотите посмотреть на наложение анимации, что все корректно с точки зрения специалиста по анимации. Они могут создать карту тестирования, разместить трех персонажей, если в разговоре участвуют трое, и вызвать диалог даже вне настоящего окружения. Так что мы действительно пытаемся создать инструмент, который позволяет дизайнерам ускорить процесс, ибо еще одна вещь, которую я всегда любил продвигать, это то, что, если вы не даете дизайнерам быстро выполнять свою работу, они будут бояться повторов. И если они этого боятся, то не получить правильного геймплея. Идея заключается в том, что, если дать дизайнерам правильные инструменты, они могут повторять гораздо больше на своем уровне, со своей логикой, и тогда можно достигнуть лучших результатов. По причинам, связанным с геймплеем, вы не захотите, чтобы дизайнеры боялись повторов логики, типа: «О нет, если я поменяю это вот здесь, то потрачу пять минут на перепроверку. Мда, у меня нет на это времени». Всегда должно быть время на настройку и повторение. И это то, чего мы хотели достичь.

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

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

Есть несколько способов получения заданий и несколько вариантов их принять. Большая часть вашего взаимодействия будет происходить также при помощи вашего MobiGlass. Так что вы можете видеть, что вам доступно, даже в окне заданий. И может он предложит вам не одну миссию, а скажет: «О, смотрите, у меня есть целый ворох миссий доступных для вас, какую вы хотите?». И также, если вы не рядом, вы можете сказать: «Ой, нет, эти миссии не в этой локации, есть вот эти миссии, которые для меня доступны… Я хочу выбрать вот эту».

Определенно есть два типа миссий. Есть миссии, более нацеленные на историю, полагаю, когда есть тот, кто выдает задание, и говорит: «Привет, есть такая-то ситуация, пожалуйста, иди и разберись с этим». И он дает задачу, которую надо выполнить. И затем вы летите и выполняете эту задачу или не выполняете… 

В общем прерыватель миссий – это система, которая работает на сервере, и учитывает репутацию игрока и криминальный статус, и прочие разнообразные факторы, вроде экономических, в данной области. Система генерирует список заданий, появляющихся в MobiGlass игроков, и позволяет им принять те, в которых они заинтересованы. Она также общается с персонажами, выдающими миссии, и они могут запросить у системы, какие задания они могут предложить игроку. Что-то вроде объединения всех этих вещей.

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

Дизайнеры могут создавать таймеры или разнообразные логические триггеры. Может быть так, что, если вы попадаете в определенную область, в которую может вам не стоило, то я такой: «О, знаю, а заспавню-ка я кучу пиратов!». Или: «О, вы очень близки к цели, вы спасли еще 5-6 других персонажей, так что теперь я отправлю к вам кучу пиратов!». Так что дизайнеры действительно могут генерировать и создавать логику, которую хотят, при помощи этих инструментов, каждый из которых очень универсальный и очень эффективный, так как мы также стараемся активировать только то, что задействовано сейчас. И мы можем задействовать множество заданий и множество персонажей.

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

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

Тони как-то сказал: «Игра должна быть интерактивной вселенной». Вселенной с очень открытым стилем геймплея. И вместо того, чтобы все было заскриптовано и ощущалось так, будто оно было туда помещено, и когда вы приходите, оно просто там было, все должно реагировать на игрока. Также, как и баланс сил в игровой вселенной изменяется со временем, так и стычки, которые вам попадаются, должны изменяться. По моему опыту, игрокам вроде нравится, когда происходят вещи, которые не совсем должны. По крайней мере пока это не что-то ломающее игровую механику и не что-то абсурдное. Если пиратская атака происходит в защищенной, укреплённой зоне, но случается лишь однажды, то это будет редким событием, но не думаю, что у игроков будут претензии к этому. Я имею в виду, что, очевидно, если это начнет происходить все время, игроки начнут считать, что это баг. Но забавно заставлять такие вещи случаться случайно. Я имею в виду, что это часть возможностей системы. И раз мы смогли ее создать, то она способна выбирать, достаточно для того, чтобы поддерживать интерес игроков, но не настолько, чтобы люди говорили: «Мда, это просто не имеет смысла, знаете, по логике пираты не стали бы атаковать эту базу». И в таком случае, полагаю, мы выполнили свою работу должным образом.

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

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

Мой любимый пример этих правильных отношений дизайнера – Тесса Баннистер, это персонаж, обитающий на станции ICC. При помощи писателя и актера, а также реализации строк диалога, мы смогли создать этого действительно запоминающегося и живого персонажа для игроков. Кажется, что он им действительно нравится. И моя небольшая часть заключалась в том, как мы упорядочили строки. Писатели дают указания по каждой строчке, но в том виде, в котором строки возвращаются к нам, всегда немного изменяется тон. Возможно, актриса должна была быть жизнерадостной везде, но в одном месте она кажется еще в более приподнятом настроении. Что я сделал, я прослушал все эти строчки, и я их расположил так, чтобы прослеживалась линейная прогрессия, вроде того, что вы сначала встречаете этого человека, затем выполняете для нее миссии… Когда вы ее встречаете, она настолько нейтральна, насколько эта актриса может быть, она очень оживленная, но в этот момент она довольно нейтральная. И чем больше вы выполняете для нее заданий, тем больше ей нравитесь, она становится более дружелюбной до тех пор, пока она не искренне рада вас видеть. И я выстроил такую арку, мне действительно это понравилось, и, кажется, игрокам тоже действительно нравится.

Так что смысл системы миссий заключается в возможности создавать эти… Это целая вселенная, так? Мы не можем проектировать индивидуальные миссии и наполнять их. Раньше мы наполняли вручную индивидуальные миссии. То, что мы собираемся сделать, так это создать типы миссий, которые содержат общую подачу, но могут быть случайные места, абсолютно разные причины необходимости выполнения этой миссии, вас могу атаковать разные люди на разных точках маршрута, а могут и не атаковать. Есть целое множество переменных. И мы как бы создаем этот шаблон, в котором есть выбор из всех этих переменных, а затем все это может генерироваться снова и снова. Я не могу сказать, что вы никогда не будете проходить одну ту же миссию дважды, по крайней мере в 3.0, но, когда у вас будет вся эта галактика, а мы обозначим все эти разнообразные места вкупе со всеми этими разными врагами и так далее, очень маловероятно, что вы получите одну и ту же миссию дважды.

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

ДХ: Это все для эпизода на этой неделе. Спасибо всем нашим подписчикам, которые делают все это возможным. Jump Point за этот месяц будет опубликован в пятницу, так что подписчикам стоит взглянуть.

СГ: Да, взгляните. И снова спасибо всем нашим бекерам за поддержку игры. Мы действительно благодарны за все, что вы делаете, чтобы помочь в разработке Star Citizen.

ДХ: До следующей недели.

Увидимся во вселенной!

Сначала нужно внимательно просмотреть (а главное прослушать) АтВ раза 3, это уже 2 часа, с учетом среднего хронометража в 40 минут. Затем приходится сидеть и слушать буквально по предложению, записывая максимально точный перевод, практически транскрипцию, только сразу на русском — это еще часов 6. При этом команда CIG довольно разношерстная и некоторых спикеров из-за акцента разбирать гораздо сложнее, а для некоторых английский — вообще не родной язык и говорят на нем они откровенно хреново. В итоге получается порядка 12 страниц текста 11 кеглем или более 30 тысяч печатных знаков. Затем час-другой причесываешь текст до вменяемого состояния, когда вроде и точность перевода сохраняется, но и читается нормально. Только после этого можно приступать к работе над видео. Все АтВ разбивается маркерами на отрезки в Premiere, разделяя каждого спикера и называя каждый отрезок соответственно. Потом накладывается локализованные подписи. На это еще пара часов. Только после этого можно приступать к записи каждого отрезка (а их в среднем по паре десятков), при этом одновременно слушая оригинал и пытаясь попасть в хронометраж. Так как у ЦИГ моментальные переходы между спикерами, то можно не успеть проговорить последнюю фразу до окончания отрезка, и тогда все заново. На запись уходит часов 6-7 с учетом самой записи, подрезки, удаления артефактов и шума и прочих обработок в Audition. Потом все это собирается в кучу, финальный монтаж, подгонка уровней громкости и пр., на что еще пара часов. Затем нужно просмотреть все, проверить, и только потом вывод готового ролика и аплоад, что тоже требует времени. Итого в среднем получается около 22 часов чистой работы. Конечно, редко бывает, чтобы я сидел больше 4 часов непрерывно, так что и получается, что перевод я выкладываю через пару дней после публикации AtV. А еще сделайте скидку на пятницу, ибо я тоже человек, и иногда могу немного загулять…