В онлайн так же как и на компе (с учетом wifi, лучше wifi 5GHz, но можно и ethernet подключать). Про блутуз выше писал - Airpods с первого раза не подрубились, но с ними везде такая проблема бывает, кроме устройств Apple. Другие не тестил. Про powerbank не пробовал, где-то читал, что нужно помощнее ватт на 20W хотя бы. В самолете от розетки на кресле норм работал. Также спокойно заряжал зарядкой от макбука. Хард можно подключать без проблем.
Я тестировал на внешнем монике FC5, FC3, FC3:Blood Dragon и Serious Sam 4 - выше 1280x800 на внешнем монике для них не было, но возможно это не для всех игр так.
Вспомнил: лет 5-6 назад у нас с женой стоял один PC на двоих с разделением профилей через софтину Астер (https://habr.com/ru/company/onlinepro/blog/109183/). К ее профилю был подключен моник/клава/мышь, а к моему - телек, блутуз-уши и геймпад (и все это к одному системнику). Софтина и конфиг позволяли одновременно запускать оба профиля - мне играть и ей работать) Бывали некоторые лаги - периодически у жены на секунду мерцал экран, но в остальном работало отлично.
Я планирую отдельно потестировать Steam Deck в качестве PC, отдельно с виндой на внешнем диске/флешке/карточке памяти) С запуском от Chrome до Rider, Unity и Unreal) По результатам отпишусь)
1) Обычно одна система — один компонент, и система проходится по всем компонентам данного типа. Тут все ок. Но когда нужно два и более компонентов, да, чтения рандомные. Обычно система производит поиск компонента, проверяет его на null (существует или нет) и кеширует его на время работы Execute(). На наших малых кол-вах объектов/компонентов, мощностях и CCU нам это ок.
2) Смотрели только те, что указаны в статье. Сейчас немного смотрим другие, как идеи для улучшения нашего фреймворка.
Да, Zenject избыточен, да, можно использовать его не по феншую — так любую библиотеку можно использовать не так, как задумано. Проблема только в криворукости разработчиков и их опыте.
Статья по сути своей хороша лишь тем, что указаны проблемы Zenject с точки зрения DI. Написано, что плохо, и как делать не стоит. Но не написано, как делать стоит в каждом конкретном случае)
Ну тут только 2 варианта:
1. Клиент симулирует.
2. Интерполяция между дошедшими состояниями. Т.е. если дошли Состояние5 и Состояние7, а Состояния 6 еще нет, но уже нужно, оно получается с помощью интерполяции.
С вводом так. Подписываем ввод номером тика, и шлем по udp пачкой N последних, за счет этого вероятность доставки сильно повышается.
Обратно сервер получает от клиента номер последнего дошедшего состояния, и есть параметр, который говорит, насколько часто надо посылать полный стейт (который тем не менее хитро запакован, с учетом знаний об игре — content-aware compression).
Если вы про диаграмму связей, то это стандартные возможности Visual Studio.
Если про схему с ECS, то схему накидал от руки на листочке, а потом попросил дизайнера отрисовать в графическом редакторе)
Да, у нас есть predication и rollback. Об этом я чуть-чуть писал в предыдущей статье, и скоро выйдет новая, где про это будет очень подробно.
Если кратко, на клиенте мы симулируем только локального игрока, остальных не трогаем, берем с сервера (т.е. игрок смотрит на мир в прошлом, а сам в нем в будущем).
Откат во времени есть, работает только на сервере. Подробнее об этом будет в статье.
У нас изначально были определенные техтребования к решению, и хотелось, чтобы какие-то фичи уже были реализованы, например, интерполяция. Можно было бы ее напилить «сверху», но мы в итоге сошлись на плотной интеграции — и быстрее реализовать, и легче исправить)
По связи физ. движка и ECS, в целом это выглядит так — на сервере есть специальные системы для физики, они создают специальные компоненты, к которым привязаны объекты из физической библиотеки. Отдельно в цикле обновляется “мир” физики, вместе с ним обновляются позиции/ориентация объектов, обрабатываются коллизии.
Да, сейчас у нас здоровенный класс Entity, и я думал о том, чтобы разбивать его либо на partial-классы, либо делать методы-расширения (extensions). Руки пока не дошли)
Мы синхронизируем вcё состояние мира, и это действительно много (у нас было 5Kb). Но мы запилили дельта-компрессию, и теперь трафик небольшой (в среднем 300 байт на стейт).
Да, с детерминизмом 3d-физики пока проблемы. Но в нашем случае детерминизм не нужен. У нас клиент симулируют то же самое, что сервер (ну почти то же самое) — prediction, и если есть расхождения, откатывает на последнее валидное состояние с сервера — rollback (Скоро выйдет наша статья про эту часть). Расхождения из-за недетерминизма могут быть, но в наших размахах несущественные.
Это наша первая реализация, так что не все может быть идеально.
Формально мы не различаем типы сущностей. Для нас сущность может содержать любой компонент, хоть все сразу (но не более одного — особенность реализации). Фактически, системы в коде сами понимают, что это за сущность, по типу компонентов на ней. Например, на двери скорее всего будет компонент Door с ее параметрами и какой-нибудь Destructable, если ее можно разрушать.
По идее ECS все равно, что за объекты у вас в игре, вы сами решаете, каким образом их «обозначить» и нужно ли их как-то различать. Я видел примеры реализаций ECS как с различаемыми типами сущностей (где можно конкретно сказать, что это игрок, это оружие, это препятствие и у них могут быть только «вот эти» компоненты), так и с обобщенной сущностью, где понять, что это за сущность, можно только по ее компонентам (как реализовано у нас).
В онлайн так же как и на компе (с учетом wifi, лучше wifi 5GHz, но можно и ethernet подключать).
Про блутуз выше писал - Airpods с первого раза не подрубились, но с ними везде такая проблема бывает, кроме устройств Apple. Другие не тестил.
Про powerbank не пробовал, где-то читал, что нужно помощнее ватт на 20W хотя бы. В самолете от розетки на кресле норм работал. Также спокойно заряжал зарядкой от макбука.
Хард можно подключать без проблем.
Я тестировал на внешнем монике FC5, FC3, FC3:Blood Dragon и Serious Sam 4 - выше 1280x800 на внешнем монике для них не было, но возможно это не для всех игр так.
Вспомнил: лет 5-6 назад у нас с женой стоял один PC на двоих с разделением профилей через софтину Астер (https://habr.com/ru/company/onlinepro/blog/109183/). К ее профилю был подключен моник/клава/мышь, а к моему - телек, блутуз-уши и геймпад (и все это к одному системнику). Софтина и конфиг позволяли одновременно запускать оба профиля - мне играть и ей работать) Бывали некоторые лаги - периодически у жены на секунду мерцал экран, но в остальном работало отлично.
Я планирую отдельно потестировать Steam Deck в качестве PC, отдельно с виндой на внешнем диске/флешке/карточке памяти) С запуском от Chrome до Rider, Unity и Unreal) По результатам отпишусь)
2) Смотрели только те, что указаны в статье. Сейчас немного смотрим другие, как идеи для улучшения нашего фреймворка.
Статья по сути своей хороша лишь тем, что указаны проблемы Zenject с точки зрения DI. Написано, что плохо, и как делать не стоит. Но не написано, как делать стоит в каждом конкретном случае)
1. Клиент симулирует.
2. Интерполяция между дошедшими состояниями. Т.е. если дошли Состояние5 и Состояние7, а Состояния 6 еще нет, но уже нужно, оно получается с помощью интерполяции.
Обратно сервер получает от клиента номер последнего дошедшего состояния, и есть параметр, который говорит, насколько часто надо посылать полный стейт (который тем не менее хитро запакован, с учетом знаний об игре — content-aware compression).
Если про схему с ECS, то схему накидал от руки на листочке, а потом попросил дизайнера отрисовать в графическом редакторе)
Если кратко, на клиенте мы симулируем только локального игрока, остальных не трогаем, берем с сервера (т.е. игрок смотрит на мир в прошлом, а сам в нем в будущем).
Откат во времени есть, работает только на сервере. Подробнее об этом будет в статье.
Формально мы не различаем типы сущностей. Для нас сущность может содержать любой компонент, хоть все сразу (но не более одного — особенность реализации). Фактически, системы в коде сами понимают, что это за сущность, по типу компонентов на ней. Например, на двери скорее всего будет компонент Door с ее параметрами и какой-нибудь Destructable, если ее можно разрушать.
По идее ECS все равно, что за объекты у вас в игре, вы сами решаете, каким образом их «обозначить» и нужно ли их как-то различать. Я видел примеры реализаций ECS как с различаемыми типами сущностей (где можно конкретно сказать, что это игрок, это оружие, это препятствие и у них могут быть только «вот эти» компоненты), так и с обобщенной сущностью, где понять, что это за сущность, можно только по ее компонентам (как реализовано у нас).