Encased (35 стр)

Alprog, можно небольшой вопрос организационного плана? После выхода в ЕА у вас что-то поменялось в пайплайнах, распределении обязанностей и т.п., т.е. все ли прошло по плану, или были какие-то незапланированные моменты, например, большое количество багов, из-за которых пришлось выделять больше ресурсов на QA, или хорошие продажи, которые позволили увеличить масштаб проекта и, соответственно, расширить штат команды, и т.д.?

Alprog
> то тебе нужно совершить некоторую работу и попробовать посмотреть на мир моими
> глазами
<...>
> А ты эдакий дед, который летал ещё на кукурузниках в 50-ых, где все баулы брали
> с собой в салон, и заладил что-то в духе «багаж часто теряют» и «я не верю, что
> если твой багаж потеряют, то ты с покерфейсом купишь новый багаж».
"А ты говно мамонта, которое непонятно кому нужно. Но видишь, я умею смотреть на мир твоими глазами." Главное заменить "говно" на "дед", а "мамонта" на "баул" - и вы цивилизованный и конструктивный собеседник.

Jaxxx
Разумеется, никогда ничего не идёт строго по плану.
Сроки и бюджеты растут быстрее самых смелых прикидок на протяжении всего проекта.
Одновременно и непрерывно происходят всякого рода фичекаты или переосмысления каких-то глав игры в сторону сокращения, упрощения или переиспользования.

Пайплайн тоже постоянно меняется и адаптируется исходя из каких-то сиюминутных достижений, нужд или провалов. Из последнего: у нас появился человек, который полностью занят обязанностями PM, без одновременного совмещения с чем-то другим, как было до сих пор.

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

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

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

u960
> я бы выделил, (судя по колву багов описанных в стиме в группе в вк)
Баги в проекте не потому, что мы не знаем о них. От того, что станет больше людей на QA, ничего принципиально не поменяется. Основная масса проблем из-за расходящихся циклов производства. Например, рефакторинг системы тасок нпс не успел, а скриптерам решение нужно уже сейчас. В итоге пишутся костыли, которые и не будут работать в 100% ситуаций, и зачастую это накладывается на изменившийся в последний день перед релизом гейм- или левелдизайн. Патч при этом переносить тоже нельзя из-за бизнесовых причин или расписания площадок.
Наверное, сейчас последует совет нанимать больше или лучше программистов/скриптеров, но проблемы в IT шапками не закидываются. Больше скриптеров на данном этапе будет означать только больше багов.
На самом же деле нужно правильно балансить циклы производства кода, контента, скриптов и маркетинга таким образом, чтобы все линии сходились вовремя и на актуальном инструментарии.

> посмотрим на следующее крупное обновление
Посмотрим… и что? Вынесем вердикт по профессионализму нашей команды?

> кстати оно когда планируется?
Весной.

Alprog, спасибо за развернутый и содержательный ответ. С Наступающим )

u960
> как было в моем случае
А что за случай?

u960
Не, я имею в виду, что это вообще было? Инди с друзьями? Большая компания? И чем закончилось?

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

Итак, главное техническое изменение — это то, что переделали стейтмашины персонажей с простой цепочки тасок, которые скриптер мог набивать вручную, на сложную структуру. Стейт-машина теперь состоит из стека state'ов. Внизу стека лежит RegularState, описывающий обычное поведение нпс; в случае боя сверху на него кладётся боевой стейт, который оверайдит поведение; ещё выше может располагаться стейт текущего приказа или стейт, описывающий прерывание текущего действия реакцией на попавшую пулю и тому подобное. Стейт смерти всегда помещается на вершину стека и оверайдит все действия.

Стейты состоят из последовательности Job'ов. Стейты или заданы программистом или описываются скриптерами в Behaviour-файлах. В данном случае имеется в виду не unity monobehaviour, а наши скрипты. Но принцип действия довольно схож: behaviour вешается на нпс и имеет внешние переменные, которые можно заполнить для каждого нпс отдельно. В самом behavior перечислены функции-стейты, которые представляют из себя енумераторы job'ов и функции-события.

Псевдокод того, как примерно выглядит файл Behavior:

public Vector3 Point1;
public Vector3 Point2;
public Stand Bed;

Enumerator<Job> PatrolState()
{
   yield return StayAtPoint(Point1, Waiter.Seconds(5.0f));
   yield return StayAtPoint(Point2, Waiter.Seconds(5.0f));
}

Enumerator<Job> SleepState()
{
   yield return StayAtStand(Bed, Waiter.Endless);
}

[OnMorning]
void OnMorning()
{
   SetRegularState("PatrolState");
}

[OnEvening]
void OnEvening()
{
   SetRegularState("SleepState");
}

Здесь задаются переменные для каждого нпс отдельно: 2 точки и кровать.
Ниже идёт описание двух стейтов: патрулирование (стоять по 5 секунд на 1 и 2 точке) и сон (бесконечно находиться на кровати). И наконец функции, обрабатывающие наступление дня и ночи, и переключающие Regular (самый нижний) слой в стеке машины состояний.

Как было сказано ранее, это поведение может быть переопределено, если выше в стеке будет находиться другое поведение. Например, персонаж спит на кровати, но тут начинается бой. CombatState кладётся выше в стеке, персонаж встаёт, начинает драться, после боя стейт убирается и мы возвращаемся в Regular state. Так как текущий job у нас был спать в кровати, то персонаж идёт в кровать и снова ложится.

Реализовано это тем, что Job'ы в свою очередь состоят из низкоуровневых тасок, которые были основой старой системы. Если job был прерван, то он очищает все свои дочерние таски, а по возвращению управления набивает их заново. Job знает, что ему надо сделать (спать в кровати), так что он оценивает ситуацию и набивает соответствующую очередь тасок: убрать оружие, подойти к кровати, повернуться, лечь. Джобы пишут только программисты и обеспечивают их способность добиться желаемого из любого фактического положения нпс. В крайнем случае нпс прибегают к телепортам, если не могут по честному добраться до точки назначения.

А уже из джобов и переменных бехавиора скриптеры составляют стейты. Может показаться, что разделение между джобами и тасками условное, но главное отличие это то, что при прерывании таски стираются и набиваются заново, а джобы — нет. Если нас прервали боем во время выполнения патрулирования точки 2, то после боя нпс пойдёт заканчивать эту джобу (постоит оставшее количество секунд на этой точке).

Текущая схема дизайнилась мной лишь процентов на 40% и в основном это касалось деталей реализации, а на 60% и больше по сути — нашими геймдизайнерами на основе их опыта работы в Larian. Так как похожая схема зарекомендовала себя там хорошо.

а смысл? если пользователи пишут

Alprog
Я конечно не супер эксперт, но у меня возникли к псевдокоду некоторые вопросы :

forwhile
> если пользователи пишут
Длительность загрузки локаций никак не связана с этими переделками. Это связано с новым контентом и бандлами в Unity. Лично я пока сам не смотрел, но вероятно починим. Ты только и занимаешься в этой теме, что выискиваешь негативные комментарии и пытаешься выставить нас в негативном свете. Что ж ты положительные комментарии, которых гораздо больше, не цитируешь? Но даже в процитированном куске есть признание, что игра летала. Когда она снова станет быстро загружаться, что предъявишь? Вернёшься к риторике, что надо вернуть деньги пользователям семёрки (у которых игра работает) или что мы жадные разработчики?

> а смысл?
Смысл чего? Смысл делать игру дальше? Тебе не приходило в голову, что цель переделок не в оптимизации? Или ты даже не читал суть поста, а пошёл на форум, нашёл первый попавшийся негативный комментарий, и заставил меня потерять сейчас 10 минут на ответ, что не верблюд? Я тебе уже неоднократно сообщал, что уровень твоих вопросов в этой теме не дотягивает до уровня разработчика, вся твоя риторика всегда на уровне несмышлёного игрока. И неоднократно повторяю, что для игроков есть группа в vk, в фейсбуке, форум на стиме и дискорде. Но ты даже не игрок. Ты даже игру не видел, а просто выискиваешь негативные комменты и закидываешь сюда. Вообще не понимаю, зачем продолжаю тратить на тебя время. Дальнейшие твои посты буду тереть из этой темы. При усердии в бан.

Nekromant80lvl
> Я конечно не супер эксперт, но у меня возникли к псевдокоду некоторые вопросы
Может ты и не супер эксперт, но вопросы хорошие.

> Как это нормально сохранять/загружать, работая с сохранениями игры?
При срабатывании генератор докручиваем до конца и храним список Job'ов. Список не меняется до следующего запуска стейта. По сути он мог бы быть и не генератором. Мне просто показалось синтаксически приятнее оформлять через yield return, чем оборачивать каждую строку в функцию.

> Учитывает только 2 момента времени суток. не лучше ли было бы сделать атрибут с
> переменной, передающей текущий час/более_точно и уже от этого плясать?
Ну это алиасы на наступление 06 и 18 часов, кажется. Разумеется есть евент и с переменной каждого часа. Ещё более точно скриптеры пока не просили.

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

> не похоже, что было бы примерно как в Elder scrolls системе "расписаний" NPC.
Я не играл в Elder Scrolls. Система больше похожа на Divinity Original Sin. Ну и это не только для расписания. В первую очередь не для расписания, а для квестовой логики.

> Тут некоторый хардкод точек. не лучше ли все это дело
> запихнуть как спецобъект локаций и брать по имени?
Vector3 я написал для простоты псевдокода. На самом деле у нас используется PointTrigger или Entity с PositionModule. И задаётся через drag-n-drop этой ентити в поле редактора.

Взяли на московском DevGAMM «лучшая PC игра» и «Гран-при» конференции.

Alprog
Поздравляю XD