Физика на сервере и отдельные локации в UNet

[siriusspark]

Привет всем.

В процессе написания авторитарного сервера на UNet LLAPI (низкоуровневой UNet-архитектуре) возникла пара вопросов.

В игре планируется расчет физики на сервере. Собственно, как я понимаю, если считать физику на сервере, то там присутствует упрощенная сцена локации, представленная лишь набором упрощенных же по возможности коллайдеров и где игроки - это по сути тоже объекты только лишь с навешенными на них скриптами, коллайдерами и ригидбоди. Никакой визуальной составляющей то бишь. А в клиентах уже как раз все бегает прыгает красивое и навороченное, но без каких либо коллайдеров и так далее, оно просто находится по тем координатам, которые им передает сервер. Все верно?

И теперь одно но! Это для одной локации. А когда локаций несколько? Как тогда просчитывать физику одновременно для всех, точнее где? Сцена ведь на сервере одна загружена, или я чего то не знаю или не понимаю? Объединять на севере все локации в одну? Или запускать отдельную копию сервера для каждой из локаций? Кто знает и может подсказать как оно делается?

[IDoNotExist]

Или запускать отдельную копию сервера для каждой из локаций? Кто знает и может подсказать как оно делается?

"Оно" обычно на юнити не делается.

[siriusspark]

Почему ж нет? Низкоуровневый API UNet'а вполне позволяет написать свой грамотный авторитарный сервер. Ну и собственно, если даже и нет, какие у вас предложения?

[Ert Donuell]

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

[Woolf]

Низкоуровневый API UNet'а вполне позволяет написать свой грамотный авторитарный сервер

На одном потоке? Вы шутите?

[siriusspark]

Ну хорошо, а что вы предлагаете? Были мысли в сторону node.js, но к нему не так то просто прикрутить физику.

[IDoNotExist]

Ну хорошо, а что вы предлагаете? Были мысли в сторону node.js, но к нему не так то просто прикрутить физику.

Зачем вам физика на сервере?

[maksimov]

Все верно?

Да.

И теперь одно но! Это для одной локации. А когда локаций несколько?

Тогда запускайте для каждой локации по процессу, который будет выступать в роли "мастер-клиента", и пишите "лобби-сервер", отвечающий за коннект, авторизацию и матчмэкинг.

Или запускать отдельную копию сервера для каждой из локаций?

Кто знает и может подсказать как оно делается?

Unity3d - это инструмент для разработки клиентского приложения. Поэтому, как правило, "серверную физику" просчитывают на одном из клиентов (мастер-клиенте).

Ну хорошо, а что вы предлагаете?

Всё упирается в вопрос, что вы хотите получить в результате. Для разных целей подходят разные решения.

Вот тут хорошо описаны все возможные подходы по реализации физики на авторитарном сервере:
https://doc.photonengine.com/en/onpremi ... ive-server

[siriusspark]

Зачем вам физика на сервере?

Затем что у меня онлайн гоночная игра с продвинутой физикой авто. Неохота чтобы из-за возможных различий просчета физики на разных клиентах победа в гонке могла достаться не тому кто на самом деле победил и всякое такое.