Добрый день!
Предположим, нужно написать сетевую мультиплеерную игру с реалистичным поведением твердых тел (то, что называют "физикой" в играх). Т.е. есть игровой сервер, есть клиенты. Как совмещать расчет физики и сетевое взаимодейстивие клиентов с сервером? Можно сделать, чтобы только сервер рассчитывал физику, но что-то мне подсказывает, что это не есть гуд. Как вообще по-хорошему можно сделать такую вещь, причем собственный физический движок писать не хочется?

Здравствуйте, Сергей, Вы писали:

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

Здравствуйте, Сергей, Вы писали:

С>Добрый день!
Привет
С> Как вообще по-хорошему можно сделать такую вещь, причем собственный физический движок писать не хочется?

Если не хочешь напрягать сервер — предлагаю следующий подход:

На сервере должен идти основной обьект управления — назовём его — "карта", распределительное ядро — скажем "синхронизатор" и информационный блок — пусть будет "телеком".

"карта" должна предоставлять публиц функции objectXY_changed, object_dissapiered ...

"телеком" получает сообщения от клиентов в виде двух пакетов: физика, персонаж.

оба передаются "синхронизатору".

В "синхронизаторе" всё разбивается по очередям и приоритетам,

Как только очередь прозесса приходит, изменение некоторых физических данных рассылается всем клиентам через "телеком", персонаж же когда подходит его очередь передаётся на "карту", а от туда и "телекому".

В это время на узерах логические движки принимают информацию и отстраивают миры — каждый локально.

Такой конструкт хорошим не назовёшь, потому что существует ни один мир а столько сколько клиентов подключено, таким образом больше вероятнасть ошибок и у каждого uzera дожна быть полная версия программы. Но эффект разгружения сервера на лицо — сервер в данном случае выполняйет лишь синхронизирующую роль — конструкт старых игрушек — "Warcraft I, Dune II"

Здравствуйте, WolfHound, Вы писали:

WH>Клиенты шлют на сервер команды, а сервер возвращает состояния объектов.
Команды какого рода?
WH>И что именно тебе это подсказывает?
Ну, предположим, клиентов штук 8. А частота обновления мира на сервере 60 гц. Получается, каждому клиенту 60 раз в секунду следует отправлять матрицы трансформаций каждого объекта? Не будет ли это слишком большой нагрузкой?
WH>Все считать на сервере. Иначе будет куча проблем с синхронизацией.
WH>Однако имеет смысл дублировать расчеты и на клиенте для обеспечения плавности но как только с сервера пришли данные то нужно замещать расчеты клиента на то что прислал сервер.
Мысль безусловно хорошая, но не совсем ясно как реализовывать.
WH>Полностью на клиенте имеет смысл делать расчеты не влияющие на состояние в игре.
Ну, это ясно.

Здравствуйте, Сергей, Вы писали:

Есть статья , описывающая , как это реализованно в Age of Empires. Рекомендую почитать.

Здравствуйте, Сергей, Вы писали:

WH>>Клиенты шлют на сервер команды, а сервер возвращает состояния объектов.
С>Команды какого рода?
О, великий сервер! Пришли мне состояние объекта "игрок" и заодно вот того камня.



в самом деле, что за дурацкий вопрос?

Здравствуйте, minorlogic, Вы писали:

M>Есть статья , описывающая , как это реализованно в Age of Empires. Рекомендую почитать.

А что, в этой игре есть физика? Собственно, вопрос в том, как совместить физику и мультиплеер.

Здравствуйте, DEMON HOOD, Вы писали:

DH>О, великий сервер! Пришли мне состояние объекта "игрок" и заодно вот того камня.
На команды такого рода я сначала и подумал. А потом мне стало кое-что неясно, что именно, см. ниже.
DH>
DH>в самом деле, что за дурацкий вопрос?
На сервере есть мир, состоящий из твердых тел. Каждый раз нужно запрашивать положения всех тел? Тел много, а если не всех, то как определить, состояние каких тел надо запрашивать, а каких нет? А если всех, то зачем запрашивать, пусть сервер сам шлет всегда и все.
Или имелись ввиду команды от клиентов типа "Игрок 'orbb' повернул руль на -31 градус и вдавил акселератор до упора", т. е. по сути клиенты должны представлять собой лишь устроиства ввода, подключенные через сеть?

Здравствуйте, Сергей, Вы писали:

С>А что, в этой игре есть физика? Собственно, вопрос в том, как совместить физику и мультиплеер.

Нет там описание сетевой модели , в которую можно вписать физику любой сложности.

Я бы вообще рассматривал две основные модели
1. Event Locking которая как раз в стать есть.
Преимущества — сколь угодно сложный мир , все считается на клиенте, совершенно не жрет трафик .
Недостатки — заведомо чуть большая инерционность (время отклика).

2. Не знаю как называется , но она в 3д шутерах. Когда "важные решения " принимает сервер , и рассылает для синхронизации клиентам.
Преимущества — Высокое время отклика
Недостатки — трафик напрямую зависит от сложности взаимодействующего мира.

Здравствуйте, Сергей, Вы писали:

С>На сервере есть мир, состоящий из твердых тел. Каждый раз нужно запрашивать положения всех тел?
как вариант — консоль отсылает текущее положение игрока, а сервер возвращает положение тел только "в зоне видимости"

С>Или имелись ввиду команды от клиентов типа "Игрок 'orbb' повернул руль на -31 градус и вдавил акселератор до упора", т. е. по сути клиенты должны представлять собой лишь устроиства ввода, подключенные через сеть?
можно и так.

Здравствуйте, WolfHound, Вы писали:

WH>Нпример есть в игре какойнибудь исключительно визуальный эффект... скажем круги на воде от пуль.
WH>Тк эффект искючительно визуальный то рассинхронизация в данном случае ничем не грозит, а раз нам это ничем не грозит то нефиг напрягать сервер всякой фигней.

Т.е. один чел эти круги увидит, а другой — нет?

Здравствуйте, Real 3L0, Вы писали:

WH>>Нпример есть в игре какойнибудь исключительно визуальный эффект... скажем круги на воде от пуль.
WH>>Тк эффект искючительно визуальный то рассинхронизация в данном случае ничем не грозит, а раз нам это ничем не грозит то нефиг напрягать сервер всякой фигней.
R3>Т.е. один чел эти круги увидит, а другой — нет?
Не совсем так.
У разных челов эти круги могут иногда отрисоваться немного по разному. (ибо пули это важная часть состояния мира и они синхронизированы)
Но в данном случае овчинка выделки не стоит ибо кто будет в кваке во время разборки сравнивавать круги на воде на разных компах?

Здравствуйте, Сергей, Вы писали:

С>На сервере есть мир, состоящий из твердых тел. Каждый раз нужно запрашивать положения всех тел?
Нет. Сервер должен присылать состояния видимых объектов.
С>Или имелись ввиду команды от клиентов типа "Игрок 'orbb' повернул руль на -31 градус и вдавил акселератор до упора", т. е. по сути клиенты должны представлять собой лишь устроиства ввода, подключенные через сеть?
Именно так.

Всем участвовавшим спасибо, вопрос можно считать закрытым.

Здравствуйте, Сергей, Вы писали:

С>Ну, предположим, клиентов штук 8. А частота обновления мира на сервере 60 гц. Получается, каждому клиенту 60 раз в секунду следует отправлять матрицы трансформаций каждого объекта? Не будет ли это слишком большой нагрузкой?

Зачем? Можно пересылать, например, пакеты примерно такого формата :
timeStamp // синхронизация во времени
пространственные координаты
ориетнация объекта (3 угловые координаты)
первые производные пространственных и угловых координат (скорости)
при необходимости более плавного перемещения — вторые производные пространственных и угловых координат (ускорения)

Данные для объекта пересылать как только старые потеряют актуальность. И для синхронизации изредка. В реальной жизни за глаза хватает пересылки такой структуры около 5 раз в секунду для движущегося объекта.

Таким образом, расчет весь идет на сервере, а у клиента есть достаточно адекватная позиция любого объекта на любой момент времени.

Здравствуйте, serge_levin, Вы писали:

_>Зачем? Можно пересылать, например, пакеты примерно такого формата :
_>timeStamp // синхронизация во времени
_>пространственные координаты
_>ориетнация объекта (3 угловые координаты)
_>первые производные пространственных и угловых координат (скорости)
_>при необходимости более плавного перемещения — вторые производные пространственных и угловых координат (ускорения)

_>Данные для объекта пересылать как только старые потеряют актуальность. И для синхронизации изредка. В реальной жизни за глаза хватает пересылки такой структуры около 5 раз в секунду для движущегося объекта.

_>Таким образом, расчет весь идет на сервере, а у клиента есть достаточно адекватная позиция любого объекта на любой момент времени.

Спасибо за идею, буду реализовывать.