Таких статей тоже немало, но в случае GaaS важно не только выпустить хорошую игру, но и уметь поддерживать ее. То есть, заботиться о том, чтобы игроку было интересно в нее играть через неделю, месяц, год. В большинстве случаев для этого рано или поздно понадобятся новые фичи.
Небольшое уточнее, не все игры из Steam и EGS запускаются. При установке выдает, что игры не поддерживается. Например Doom. Но цифра 590 игры возможно верная.
О доступности в сервисе всех игр из сторов речи не идет, в одном Steam их более 30 тысяч. В ближайших планах Nvidia было расширить каталог как минимум до 1500 игр.
Имеется в виду, что родной контроллер Stadia напрямую подключается к wi-fi?
Да, все верно
Так что основное преимущество Stadia перед GeForce Now — у гугла больше адресов и меньше задержка. Правда, это верно только там, где на этих адресах развернуты сервера Стадии. Так что для России GFN скорее всего будет быстрее.
В России вообще ситуация несколько другая, все приведенные в материале данные и цифры имеют место в США. Но в целом да, вывод касательно серверов правильный
Проекты Dino Squad и War Robots разрабатываются разными командами внутри нашей студии. Мы, конечно же, обмениваемся опытом и техническими решениями между командами, но многие вещи в проектах реализованы совершенно по-разному. И сетевой стек в данном случае — одна из таких вещей. Поэтому делать далекоидущие выводы о War Robots из этой статьи не стоит, в роботах все работает по-другому.
Не уверен, что имеется ввиду под словом «фантом». Я предложение понял так: для каждого игрока в физическом мире заводится не 1, а 12 коллайдеров, и каждый из этих коллайдеров находится в том времени, в котором его видел противник с соответствующим номером. Мы такой вариант сделать не пробовали — он бы нам обошелся существенно дороже в реализации. Что тут хочется отметить:
1) Такой подход не позволил бы нам реализовать второй вариант лагкомпенсации, со «схлопыванием» времени (от которого, справедливости ради, мы в итоге отказались).
2) Двигать коллайдеры все равно придется, просто потому что игроки перемещаются. Но вместо того чтобы условно 12 раз подвинуть 12 коллайдеров, придется один раз сдвинуть 144 (в худшем случае, где все игроки перемещаются и находятся в разном времени). Последний вариант в Unity производительнее, т.к. сцену нужно перестроить только один раз. Поэтому тут большой плюс вашего подхода. Но он похуже по памяти.
3) Проблема тут в том что механизма присвоить коллайдеру «id», который бы учитывался при выполнении физических операций на уровне физического движка — в Unity нет. Есть несколько схожих концепций, но все они имеют свои ограничения:
— В Unity есть слои. Можно разнести коллайдеры по 12-ти разным слоям, и делать, например, рейкаст только в слой стреляющего игрока. В Unity всего 32 слоя, из которых около 15 у нас уже зарезервировано под разные нужды. Если мы раздадим еще по слою на каждого игрока — мы приблизимся к лимиту, и сделать условный режим десматч на 20 игроков уже точно не сможем. Есть вариант перед рейкастом перенести коллайдеры с id игрока на отдельный слой, но он нивелирует все преимущества по производительности (мы такое пробовали).
— В Unity можно выключить ненужные коллайдеры, а после рейкаста их включить. Такие операции, как и манипуляции с номером слоя, приводят к перестроению физической сцены, и бьют по производительности.
— Можно оставить все коллайдеры включенными на одном слое и делать рейкаст через все объекты (RaycastAll). И затем вручную сортировать попадания по дистанции и отбрасывать все коллайдеры, которые принадлежат другим игрокам. Это удорожает стоимость всех физических операций — т.к. растет число коллайдеров на сцене (причем они кучно расположены, что плохо для движка). И появляется дополнительная нагрузка на цпу по сортировке и фильтрации результатов. Станет ли в сумме вся система работать быстрее или медленнее — вопрос открытый.
Обучающиеся нейронные сети — лишь разновидность искусственного интеллекта, которую в геймдев для создания NPC потихоньку пытаются внедрять, но обычно получается довольно громоздко и не оправдывает себя, а потому успешных кейсов практически нет (об одной из попыток реализовать что-то подобное мы писали в своей прошлогодней статье).
Игровой же ИИ — это набор программных методик, предназначенный для создания иллюзии интеллекта, чтобы NPC реагировал на действия игрока определенным образом.
Но ведь в статье упоминались как ярые противники удаленки внутри нашей компании, так и те, кому она в кайф. Что вы подразумеваете под тем, что мы хотим услышать?
Конкретные цифры сейчас не приведу, но поясню пару моментов.
Наш сервер VCS находится в той же сети, что и сервер TeamCity. Соответственно, овертайм на передачу данных минимален. Ну и у нас достаточно мощный парк машин: есть возможность передачи большого количества кастомных аргументов во время сборки, через которые могут запускаться отдельные процессы со специфичным окружением (например, во время сборки мы интегрируемся с базами данных, запускаем отдельные процессы для собирания атласов и т.д.) либо выбор кэш-сервера для конкретного билда. Существуют зависимые сборки по триггерам запуска сторонних конфигураций, запуски на PullRequest и запуски автотестов на нашем парке девайсов.
Все эти вещи связаны в единую инфраструктуру нашего билд-пайплайна. В частности, по завершению сборки наши билды также попадают в файловое хранилище внутри нашей сети, что обеспечивает быструю и гарантированную доставку на девайсы.
Залив на ревью в маркеты у нас осуществляется в полуавтоматическом режиме по нажатию кнопки на сервере TeamCity, когда все наши внутренние проверки пройдены.
Короче говоря, инфраструктура у нас гораздо более сложная, чем может обеспечить Cloud Build.
Альфа-бета-тесты мы тоже используем, но с другой целью — когда нужно протестировать какие-то новые фичи. Автоматизацию же запускаем каждый день по нескольку раз, чтобы сократить время нахождения багов.
Если речь про Cloud Build, то да, смотрели и сравнивали, но он имеет ряд ограничений, которые нам не подходят, ну и еще мы используем разные платформы и специфичное окружение.
Таких статей тоже немало, но в случае GaaS важно не только выпустить хорошую игру, но и уметь поддерживать ее. То есть, заботиться о том, чтобы игроку было интересно в нее играть через неделю, месяц, год. В большинстве случаев для этого рано или поздно понадобятся новые фичи.
В любом случае, прирост производительности за счет VRS в среднем 15-20% эти 6% более чем покрывает.
Впрочем, в статье мы упоминаем, что речь идет о США, и у нас это все немного по-другому устроено.
О доступности в сервисе всех игр из сторов речи не идет, в одном Steam их более 30 тысяч. В ближайших планах Nvidia было расширить каталог как минимум до 1500 игр.
Да, все верно
В России вообще ситуация несколько другая, все приведенные в материале данные и цифры имеют место в США. Но в целом да, вывод касательно серверов правильный
1) Такой подход не позволил бы нам реализовать второй вариант лагкомпенсации, со «схлопыванием» времени (от которого, справедливости ради, мы в итоге отказались).
2) Двигать коллайдеры все равно придется, просто потому что игроки перемещаются. Но вместо того чтобы условно 12 раз подвинуть 12 коллайдеров, придется один раз сдвинуть 144 (в худшем случае, где все игроки перемещаются и находятся в разном времени). Последний вариант в Unity производительнее, т.к. сцену нужно перестроить только один раз. Поэтому тут большой плюс вашего подхода. Но он похуже по памяти.
3) Проблема тут в том что механизма присвоить коллайдеру «id», который бы учитывался при выполнении физических операций на уровне физического движка — в Unity нет. Есть несколько схожих концепций, но все они имеют свои ограничения:
— В Unity есть слои. Можно разнести коллайдеры по 12-ти разным слоям, и делать, например, рейкаст только в слой стреляющего игрока. В Unity всего 32 слоя, из которых около 15 у нас уже зарезервировано под разные нужды. Если мы раздадим еще по слою на каждого игрока — мы приблизимся к лимиту, и сделать условный режим десматч на 20 игроков уже точно не сможем. Есть вариант перед рейкастом перенести коллайдеры с id игрока на отдельный слой, но он нивелирует все преимущества по производительности (мы такое пробовали).
— В Unity можно выключить ненужные коллайдеры, а после рейкаста их включить. Такие операции, как и манипуляции с номером слоя, приводят к перестроению физической сцены, и бьют по производительности.
— Можно оставить все коллайдеры включенными на одном слое и делать рейкаст через все объекты (RaycastAll). И затем вручную сортировать попадания по дистанции и отбрасывать все коллайдеры, которые принадлежат другим игрокам. Это удорожает стоимость всех физических операций — т.к. растет число коллайдеров на сцене (причем они кучно расположены, что плохо для движка). И появляется дополнительная нагрузка на цпу по сортировке и фильтрации результатов. Станет ли в сумме вся система работать быстрее или медленнее — вопрос открытый.
Игровой же ИИ — это набор программных методик, предназначенный для создания иллюзии интеллекта, чтобы NPC реагировал на действия игрока определенным образом.
Наш заместитель CTO как раз выразил обобщенное мнение отдела разработки с цитатами отдельных девелоперов.
Наш сервер VCS находится в той же сети, что и сервер TeamCity. Соответственно, овертайм на передачу данных минимален. Ну и у нас достаточно мощный парк машин: есть возможность передачи большого количества кастомных аргументов во время сборки, через которые могут запускаться отдельные процессы со специфичным окружением (например, во время сборки мы интегрируемся с базами данных, запускаем отдельные процессы для собирания атласов и т.д.) либо выбор кэш-сервера для конкретного билда. Существуют зависимые сборки по триггерам запуска сторонних конфигураций, запуски на PullRequest и запуски автотестов на нашем парке девайсов.
Все эти вещи связаны в единую инфраструктуру нашего билд-пайплайна. В частности, по завершению сборки наши билды также попадают в файловое хранилище внутри нашей сети, что обеспечивает быструю и гарантированную доставку на девайсы.
Залив на ревью в маркеты у нас осуществляется в полуавтоматическом режиме по нажатию кнопки на сервере TeamCity, когда все наши внутренние проверки пройдены.
Короче говоря, инфраструктура у нас гораздо более сложная, чем может обеспечить Cloud Build.