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 очень темная тема, как я понял.