3D.ru

Просто у каждого сервера есть свой сосед, и они обмениваются данными

Ert Donuell писал(а):Просто у каждого сервера есть свой сосед, и они обмениваются данными

Как-то не очень похоже на авторитарный выделенный сервер. Это ваша работа? Второе видео на канале имеет подозрительное название peers.

Да, это моя работа. У меня есть сетевое решение, которое позволяет настраивать авторитарные сервера, размещаемые как в одном приложении, так и на разных машинах с тем, чтобы можно было создавать огромные миры с динамической подгрузкой (что и продемонстрировано на видео), а также позволяет создавать p2p приложения, в которых управление ботами может перейти к наследнику, если хост отвалится (что продемонстрировано на втором видео)

Ert Donuell писал(а):Да, это моя работа. У меня есть сетевое решение, которое позволяет настраивать авторитарные сервера, размещаемые как в одном приложении, так и на разных машинах с тем, чтобы можно было создавать огромные миры с динамической подгрузкой (что и продемонстрировано на видео), а также позволяет создавать p2p приложения, в которых управление ботами может перейти к наследнику, если хост отвалится (что продемонстрировано на втором видео)

Реализацию синхронизации показать можете?

Это большой сетевой фреймворк, который я почти допереписывал с нуля. Синхронизацию чего именно? Клиен шлёт инпуты на сервер, а сервер отсылает клиенту и соседним серверам новое положение аватара. Дальше делается лерп от текущей позиции до целевой

Ert Donuell писал(а):Это большой сетевой фреймворк, который я почти допереписывал с нуля. Синхронизацию чего именно? Клиен шлёт инпуты на сервер, а сервер отсылает клиенту и соседним серверам новое положение аватара. Дальше делается лерп от текущей позиции до целевой

Дьявол кроется в мелочах. В целом у меня работает так же, только сервер один.
Вы используете SyncVar? Command/RPC? LLAPI? (У меня Command/RPC и я думаю, что забиваю гвозди микроскопом)
Как именно делается лерп? Ведь пакет может запоздать или прийти раньше, объект может двигаться не линейно. Как это все обрабатывается? (у Command/RPC например явный джиттер, я писал компенсацию для этого)
Плюс частота кадров клиента может не совпадать с частотой тиков сервера(пока себя избавил от этого фиксацией кадров, но это специфичное решение). Понятно, что это лечится лерпом, как-то: position + lerpunclamped(oldposition, position, Time.deltatime \ timeticrate) , но точность по идее снижается(У меня это вылезает из-за преимущественно кругового движения).

Можете хотя-бы со способом отсылки/приема помочь?

Filosov писал(а):Вы используете SyncVar? Command/RPC? LLAPI? (У меня Command/RPC и я думаю, что забиваю гвозди микроскопом)

Нет, ничего такого не использую. В там используются стринги, рефлексия и прочие тормозные радости. Не то, чтобы я имел честь с ними сношаться, но слышал я о них достаточно. Вместо этого я написал свой RUDP протокол передачи данных поверх UDP. Можно отправлять данные одним из пяти способов:
- Reliable Ordered - как TCP, все данные доставляются в том же порядке, что и отправлены, без дублирования и потерь;
- Reliable Unordered - то же, что и выше, но данные могут прийти не по порядку. Чуть быстрее, чем Reliable Ordered;
- Reliable Sequenced - Все данные приходят по порядку, но если какие-то теряются, то игнорируются. Последнее отправленное сообщение будет доставлено гарантированно. Удобно для передачи положения игроков/ботов;
- Unreliable Sequenced - то же, что и выше. Данные доставляются по порядку, но нет гарантии, что последнее сообщение будет доставлено. Самый быстрый метод;
- Unreliable Unordered - то же, что и UDP - никакого порядка, никаких гарантий. Медленнее верхнего, так как в случае, если данные будут одновременно отправлены на один канал, Unreliable Sequenced озадачится отправкой только последнего сообщения, а Unreliable Unordered отправит оба.

В результате всё летает. По крайней мере, у меня проблем не возникало. Использовал стандартный юнилерп: transform.position = Vector3.Lerp(transform.position, targetTransform, Time.fixedDeltaTime);

Кстати, отмечу, что делаю лерп не от старой позиции, а от текущей. Получается нелинейно, но плавно

Ert Donuell писал(а):

Filosov писал(а):Вы используете SyncVar? Command/RPC? LLAPI? (У меня Command/RPC и я думаю, что забиваю гвозди микроскопом)

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

В результате всё летает. По крайней мере, у меня проблем не возникало. Использовал стандартный юнилерп: transform.position = Vector3.Lerp(transform.position, targetTransform, Time.fixedDeltaTime);

То есть вы писали сторонний сетевой код, а потом его пристыковывали к Unity? Можете рассказать, как? Какую литературу использовали, ссылки?

Кстати конкретный код лерпа странный:
Во-первых аргумент t задан просто, как время. По идее им задается отношение к 1. То есть t = 1 это будет targetTransform, а t = 0.5 точка между
transform.position и targetTransform.

Во-вторых, почему Time.fixedDeltaTime? Оно же не связано с кадрами. Как этот код компенсирует плавающий FPS вообще не понятно.

Я просто написал dll библиотеку на шарпе. Читал очень много всего, ковырял много разных исходников, советовался с разными умными людьми, проводил много тестов. Сообщения приходят в FixedUpdate. Я использовал FixedUpdated для интерполяции, так как получилось равномерное дотягивание объекта. Никаких проблем я не заметил при данном подходе. Можете поэкспериментировать с этим, елси интересно. Это нелинейная интерполяция, которая, по сути, никогда не дотягивает до целевой точки, но бесконечно приближает к ней. Я могу предположить, что на деле я использовал несколько иной код, сейчас мне трудно припомнить. Вероятно, данная интерполяция (а точнее - интерполяция по именно данной формуле) вообще не годна