3D.ru

Если для необходимого вам tickrate, вам не хватит лимита Photon Cloud в 500 сообщений/секунда на комнату - выходом является Photon On Premise. Там никаких ограничений нет. =)

maksimov писал(а):Пропускная способность может быть у канала. Метрики скриптов - это цикломатическая сложность, топологическая мера Чена, информационная прочность, читабельность,...

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

Чтобы было понятно о чем я веду речь. У меня сейчас есть синхронизация сделанная через Unet с использованием Command/RPC. В процессе изучения, как это все не работает, я сделал лог работы сети. Я записываю в текстовый файл время отправки позиции с сервера, а так же время приема этой позиции на клиенте(именно приема, а не отображения). Запускаю это все на локалхосте. На одном и том же компьютере. И наблюдаю минимальную латентность в 33миллисекунды. Это время которое видимо тратится на формирование пакета и его отправку, а затем распаковку. Никаких проблем с сетью очевидно на локалхосте быть не может(пинг 0), пробовал более мощные компьютеры и не увидел разницы(точнее разница есть при запуске других приложений, но влияние на минимальное время не заметил, самое низкое время 25миллисекунд) По мне 33миллисекунды это много. Поэтому мне и интересно, какая у его скриптов(кода формирования/обработки пакета) минимальная латентность. Если это вообще связано с кодом так-таковым.

maksimov писал(а):60 обновлений чего?

Позиции, положения.

maksimov писал(а):Вы снова путаете понятия. 60 FPS - это фреймрейт (необходимый, например для плавной анимации).
Вы собрались пытаться гонять байты через всю планету по разнородной сети, с той же скоростью, с какой может гонять байты компьютер по своей материнке?

Я ничего не путаю, я говорю о частоте обновления. В 21веке она далеко не 15 раз в секунду, как советует нам юнити.
Обратите внимание на сводную таблицу игр, там минимум 30.
https://www.blurbusters.com/network-lag/

maksimov писал(а):Фотоновский лимит: 500 сообщений в секунду на каждую комнату. И это более чем впечатляющий задел с гигантским запасом, который вы вряд ли когда-нибудь сможете полезно исчерпать даже на четверть.

Это In или out? Или вместе? Если в одну сторону то это 10-9 человек баттлфилда. Если в обе то вообще не более 4х. В своей игре я рассчитывал на 4-6 игроков в комнате. То есть 500 это неплохо, но это далеко не "более чем впечатляющий задел с гигантским запасом".

maksimov писал(а):Да. По умолчанию отправка производится с определённой периодичностью (которую можно изменить в настройках клиента). При этом скопом отправляются все пакеты, накопившиеся с момента предыдущей отправки. И это очень здорово с точки зрения оптимизации.
Но если возникает необходимость немедленной отправки пакета, достаточно вызвать функцию PhotonNetwork.SendOutgoingCommands();.

Еще немного сурового Uneta. Я пробовал использовать SyncVar и он просто "обрезает" сендрейт больше 29-30(причем эти пакеты тоже приходят как попало на локалхосте). То есть я задаю в скрипте: sendInterval = 0.0167f, а потом сижу с секундомером и смотрю в профайлер. И никогда там 60 на секунду не набиралось. Около 30. Поэтому я использую, Command/RPC, они позволяют самому настроить, когда, что и как. Вот оптимальность их применения меня настораживает. Сейчас я имею 30 положений в секунду, интерполируя другие 30. И все равно пакет может "потеряться" (прийти через 50миллисекунд это на локалхосте то). Даже когда все работает хорошо, бываю микрослаттеры (интервалом секунд 5) Сейчас налаживаю экстраполяцию для "потерянных" кадров. Это все впринципе ожидаемо, но напоминаю, это не интернет и даже толком не LAN. Кстати Command/RPC даже на Unrealibal канале лучше переживают потерю пакетов, чем SyncVar, проверено clumsy и в интернете (есть друг с белым IP и мощным железом).
Почему-то Гленн Фидлер считает, что пакет не должен задерживаться и не должен быть большим и сильно фрагментированным.

maksimov писал(а):Вам нужно искать способы "как отправлять данные как можно реже и как можно меньше", а не наоборот. =)

Вы конечно же можете отправлять хоть по тридцать пакетов каждый кадр (но не больше 500 в секунду). А ещё вы может сделать каждый пакет размером с мегабайт. Если цель - забить канал бесполезным информационным шумом - можно придумать массу подобных вещей.
Но к эффективной коммуникации это не имеет никакого отношения.

Можно вообще не делать сетевую игру. Мне не нужно 30 пакетов в кадр. Мне нужен один пакет на одного игрока в кадр, в котором его данные о положении (сервер то авторитарный).

maksimov писал(а):Да.

Они живут с представления сервиса (Photon Cloud) и продажи лицензии (Photon On Premise).
Им всё равно, где вы будете использовать купленное приложение - в интернете или интранете.

Я имею ввиду есть ли у них минимальный функционал? Аналог хамачи или что-то вроде. Серые IP очень темная тема, как я понял.

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

ArmoredElite писал(а):Изучай uNet... Фотон обычно используются в играх сделанные на скорую руку, а на uNet можно сляпать выделенный сервер. Клиент просто будет отправлять нажатия клавиш а на сервере будет вся симуляция игры, сервер же будет рассылать инфу всем клиентам об изменениях в симуляции...

Чувак, ты такой классный.

Покадрово передавать положение игроков? Это что, чтобы с интерполяцией/экстраполяцией не мучиться? Кстати, если бы хотелось, можно было бы по те самые 500 раз в секунду передавать положения всех игроков разом Только успевайте пакеты собирать. А если серьёзно, под свои 100м/с техники используйте интерполяцию и не извращайтесь. Прогоните тесты и посмотрите, при какой частоте передачи данных при наличии интерполяции разница перестаёт быть существенной

Ert Donuell писал(а):Покадрово передавать положение игроков? Это что, чтобы с интерполяцией/экстраполяцией не мучиться? Кстати, если бы хотелось, можно было бы по те самые 500 раз в секунду передавать положения всех игроков разом Только успевайте пакеты собирать. А если серьёзно, под свои 100м/с техники используйте интерполяцию и не извращайтесь. Прогоните тесты и посмотрите, при какой частоте передачи данных при наличии интерполяции разница перестаёт быть существенной

А если читать тред, то можно узнать, что интерполяция у меня сейчас есть. Кроме того у меня авторитарный сервер и именно он определяет позицию(а еще объекты не останавливаются). Вы мне предлагаете принимать координаты, как попало, а потом по ним строить приблизительную траекторию? Я пробовал разные варианты синхронизаций, которые находил в сети. И этот вариант отпадает из-за низкой точности. Буквально 2 минуты игры и мой корабль имеет погрешность в 10метров с сервером.

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

Ert Donuell писал(а):Не путайте интерполяцию с экстраполяцией. И если уж Вы экстраполируете, то погрешность через две минуты игры говорит лишь о том, что по пришествии актуальных данных, Вы не осуществляете коррекцию. Ещё бы у Вас не росла погрешность. Экстраполяция даёт предсказать, а потом предсказание корректируется под реально пришедшие данные

Я прекрасно понимаю разницу. И говорить такое поведение может о куче вещей, например о рассинхроне во времени(если все позиции буферизуются). Еще это может быть просто погрешностью синхронизации. Потому, что отлерпенная позиция плохо попадает по искомой. Как например работает дефолтная синхронизация Uneta?

Пример лерпа (видно и три сервера, и клиент, всё самописное). Никакой нарастающей рассинхронизации:

Несколько месяцев сам терзал себя этим вопросом, и результат таков:
Если вы новичок и деньги == проблема , то сразу забудьте о Photon'е. Не важно сервер или клауд(последнее вообще трэш для такого вида игр). Про UNet вообще упоминать не хочется, так как по максимальному тарифу вы получите общий онлайн игры == 200 человек, что катастрофически мало(если только шутер не онли для локальной сети, тогда можно и его, так как ограничений нет и API приятный + примеров от самих Unity множество).
А от себя посоветовать могу старую систему - через Master Server + Network View. Нужно только хостинг оплачивать(на который зальёте мастера), и логику для клиентов написать(весь API в документации юнити в Legacy топике).
Плюсы:
1)Никаких ограничений, просто запустили консольный .cpp самого мастер сервера на машине(она обязана иметь белый IP), коннектитесь к нему через клиентов(опять же всё поймёте при разборе API), и Мастер сервер будет создавать комнаты для игроков. 2) Логику для комнат писать очень легко, так как API для Network View не очень большой. 3) На хостинг заливается просто .cpp мастер сервера с парой папок, и как результат это не весит ровным счётом ничего(так же этот плюс можно отнести и к тому, что на некоторых VDS запрещены установки целых серверов). 4) Master Server так же имеет Facilitator, который сможет(или хотя бы сделает попытку) пробиться через Брандмауэр благодаря NAT Poungh Touch.
Минус метода - кто то в комнате будет хостом(но не будет знать об этом), и если он решит ливнуть(или же его провайдер так решит), то и сама комната дропнется(можно сделать костыль - заранее законнектить свои клиенты на комнаты, и игроки будут уже подключаться к ним). Ограничение онлайна прописываете в самом .cpp Мастер сервера(имеется ввиду общего онлайна, ограничение для комнат уже при написании логики клиента зададите).
Оптимальный ли метод? - Не знаю, но это хотя бы бесплатно) Если вопрос не в деньгах, то тогда можете уже и на Photon Server глядеть.

Чтобы "среднего" пользователя сделать сервером придется сношаться с брендмаурами, роутерами и пр системами за которыми "прячется" пользователь...
Почему сетевые игры не работают через инет? Зачем нужны все эти хамачи, гарены и прочие VPN для чайников если все так просто?

Unet позволяет любой онлайн без ограничений вообще, а 200 дается при покупке ПРО...

Ert Donuell писал(а):Пример лерпа (видно и три сервера, и клиент, всё самописное). Никакой нарастающей рассинхронизации:

Не очень понимаю, как выводится на одну сцену, но я в принципе не очень интересовался пиринговой сетью. Она мне не подходит. Что до синхронизации, то тут мне нужен код, чтобы её проверить. Не могу судить по ролику, но разрывы кажется были, а у меня камера игрока на объекте.

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

Nubila писал(а):Несколько месяцев сам терзал себя этим вопросом, и результат таков:
Если вы новичок и деньги == проблема , то сразу забудьте о Photon'е. Не важно сервер или клауд(последнее вообще трэш для такого вида игр). Про UNet вообще упоминать не хочется, так как по максимальному тарифу вы получите общий онлайн игры == 200 человек, что катастрофически мало(если только шутер не онли для локальной сети, тогда можно и его, так как ограничений нет и API приятный + примеров от самих Unity множество).
А от себя посоветовать могу старую систему - через Master Server + Network View. Нужно только хостинг оплачивать(на который зальёте мастера), и логику для клиентов написать(весь API в документации юнити в Legacy топике).
Плюсы:
1)Никаких ограничений, просто запустили консольный .cpp самого мастер сервера на машине(она обязана иметь белый IP), коннектитесь к нему через клиентов(опять же всё поймёте при разборе API), и Мастер сервер будет создавать комнаты для игроков. 2) Логику для комнат писать очень легко, так как API для Network View не очень большой. 3) На хостинг заливается просто .cpp мастер сервера с парой папок, и как результат это не весит ровным счётом ничего(так же этот плюс можно отнести и к тому, что на некоторых VDS запрещены установки целых серверов). 4) Master Server так же имеет Facilitator, который сможет(или хотя бы сделает попытку) пробиться через Брандмауэр благодаря NAT Poungh Touch.
Минус метода - кто то в комнате будет хостом(но не будет знать об этом), и если он решит ливнуть(или же его провайдер так решит), то и сама комната дропнется(можно сделать костыль - заранее законнектить свои клиенты на комнаты, и игроки будут уже подключаться к ним). Ограничение онлайна прописываете в самом .cpp Мастер сервера(имеется ввиду общего онлайна, ограничение для комнат уже при написании логики клиента зададите).
Оптимальный ли метод? - Не знаю, но это хотя бы бесплатно) Если вопрос не в деньгах, то тогда можете уже и на Photon Server глядеть.

Но ведь сделать выделенный сервер и платить только за хостинг можно уже сейчас на Unet-e. У меня именно так. Есть в ассетсторе МастерСервер и с ним вполне создаются комнаты. Хостится на арендуемом сервере. Впрочем у него есть свои "фичи" и поведение у него несколько отличается от теста с прямым подключением по IP.
Не понимаю, зачем вам старый нетворк.
Не припомню, чтоб он нат пробивал. Просто хостится на белом IP и через него идет траффик или запускается сервер с игровой логикой.

Filosov писал(а):

Ert Donuell писал(а):Пример лерпа (видно и три сервера, и клиент, всё самописное). Никакой нарастающей рассинхронизации:

Не очень понимаю, как выводится на одну сцену, но я в принципе не очень интересовался пиринговой сетью. Она мне не подходит. Что до синхронизации, то тут мне нужен код, чтобы её проверить. Не могу судить по ролику, но разрывы кажется были, а у меня камера игрока на объекте.

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

Filosov писал(а):

Ert Donuell писал(а):Пример лерпа (видно и три сервера, и клиент, всё самописное). Никакой нарастающей рассинхронизации:

Не очень понимаю, как выводится на одну сцену, но я в принципе не очень интересовался пиринговой сетью. Она мне не подходит. Что до синхронизации, то тут мне нужен код, чтобы её проверить. Не могу судить по ролику, но разрывы кажется были, а у меня камера игрока на объекте.

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

Nubila писал(а):Несколько месяцев сам терзал себя этим вопросом, и результат таков:
Если вы новичок и деньги == проблема , то сразу забудьте о Photon'е. Не важно сервер или клауд(последнее вообще трэш для такого вида игр). Про UNet вообще упоминать не хочется, так как по максимальному тарифу вы получите общий онлайн игры == 200 человек, что катастрофически мало(если только шутер не онли для локальной сети, тогда можно и его, так как ограничений нет и API приятный + примеров от самих Unity множество).
А от себя посоветовать могу старую систему - через Master Server + Network View. Нужно только хостинг оплачивать(на который зальёте мастера), и логику для клиентов написать(весь API в документации юнити в Legacy топике).
Плюсы:
1)Никаких ограничений, просто запустили консольный .cpp самого мастер сервера на машине(она обязана иметь белый IP), коннектитесь к нему через клиентов(опять же всё поймёте при разборе API), и Мастер сервер будет создавать комнаты для игроков. 2) Логику для комнат писать очень легко, так как API для Network View не очень большой. 3) На хостинг заливается просто .cpp мастер сервера с парой папок, и как результат это не весит ровным счётом ничего(так же этот плюс можно отнести и к тому, что на некоторых VDS запрещены установки целых серверов). 4) Master Server так же имеет Facilitator, который сможет(или хотя бы сделает попытку) пробиться через Брандмауэр благодаря NAT Poungh Touch.
Минус метода - кто то в комнате будет хостом(но не будет знать об этом), и если он решит ливнуть(или же его провайдер так решит), то и сама комната дропнется(можно сделать костыль - заранее законнектить свои клиенты на комнаты, и игроки будут уже подключаться к ним). Ограничение онлайна прописываете в самом .cpp Мастер сервера(имеется ввиду общего онлайна, ограничение для комнат уже при написании логики клиента зададите).
Оптимальный ли метод? - Не знаю, но это хотя бы бесплатно) Если вопрос не в деньгах, то тогда можете уже и на Photon Server глядеть.

Но ведь сделать выделенный сервер и платить только за хостинг можно уже сейчас на Unet-e. У меня именно так. Есть в ассетсторе МастерСервер и с ним вполне создаются комнаты. Хостится на арендуемом сервере. Впрочем у него есть свои "фичи" и поведение у него несколько отличается от теста с прямым подключением по IP.
Не понимаю, зачем вам старый нетворк.
Не припомню, чтоб он нат пробивал. Просто хостится на белом IP и через него идет траффик или запускается сервер с игровой логикой.

Но а как же CCU ограничения от Unet'a?
Я не знаю за какой вы МастерСервер в ассетсторе, я про этот https://docs.unity3d.com/Manual/net-MasterServer.html
Старый , так как новый требует оплату за более чем 20 человек онлайна.

Ert Donuell писал(а):Это не пиринговая сеть. Это три авторитарных сервера и один клиент, который прыгает с одного сервера на другой. И в тут нет прерываний, всё идёт абсолютно бесшовно. Смотрите на клиента (внизу)

Прерывания в данном случае это потеря кадра\позиции(у меня со стороны они тоже не очень заметны, если бы делал стратегию, вообще бы не заморачивался.) Интересно про переход. Как данные о состоянии передаются с сервера на сервер? Сразу отсылаются на три сервера?
В любом случае без кода я ничего не смогу проверить.

Nubila писал(а):Но а как же CCU ограничения от Unet'a?
Я не знаю за какой вы МастерСервер в ассетсторе, я про этот https://docs.unity3d.com/Manual/net-MasterServer.html
Старый , так как новый требует оплату за более чем 20 человек онлайна.

Друг с белым IP хостует сервер. К нему хоть 1000 игроков может присоединиться. Канал не выдержит.
Ограничение работает если вы работаете через сервера юнити.

Про мастер сервер: https://assetstore.unity.com/packages/t ... work-71391
В принципе его можно самому сделать. На данном этапе меня синхронизация больше беспокоит.