>>40806> Лучше бы описал, что конкретно ты считаешь мессажками, а что rpc. Без конкретики, только различия.
Вот тебе грубый пример:
Пусть в некой одной сетевой игре игрок управляет магом, который может бегать и швырять в остальных игроков фаерболом.
1. Реализация основанная на RPC может выглядеть так:
а) если игрок кликает на землю, то на сервер посылается вызов удаленной процедуры "MoveTo" с координатами клика в качестве аргумента. Сервер ловит вызов, верифицирует и запускает саму процедуру - в данный момент персонаж на сервере стал двигатся к цели. Затем сервер броадкастит этот вызов всем клиентам, которые тоже запускают его и у себя начинают двигать этого персонажа.
б) если игрок кликает на другого персонажа, то на сервер посылается вызов удаленной процедуры "AttackAt" с координатами вражеского персонажа в качестве аргумента. Дальше происходит все то же самое, за исключением, что если у этого персонажа не прошел кд на атаку, то вызов не броадкастится остальным клиентам, а клиенту-инициатору возвращается что-то вроде "AttackAttemptDeclined".
В этой реализации тебе очень важно, что бы все команды точно-точно доходили до сервера и до клиентов, а так же в нужной последовательности. Здесь тебе TCP помогает.
2. Реализация основанная на обмене базовыми сообщениями может выглядеть так:
a) Игрок просто жмет клавиши WASD, а тем временем, каждый третий кадр на сервер реплицируется структура с состояниями этих клавиш (булевое "зажата-отжата"). Сервер в отдельном процессе (обычно выделяется под сетевой обмен с каждым клиентом) обновляет у себя эту структуру и параллельно каждый кадр у себя двигает персонажа в соответствии с нажатыми кнопками. При этом, в том же потоке для сетевого взаимодействия, с неким интервалом происходит обмен в обратную сторону - сервер броадкастит всем клиентам актуальную позицию каждого персонажа. Игровой клиент постоянно получает обновления и каждый кадр интерполирует между своими текущими данными и тем, что пришло.
б) В случае с атакой, сервер просто берет фаербол из пула объектов, активирует его, и начинает каждый кадр менять его позицию, считать коллизию и т.п. При этом, опять же, состояние фаребола реплицируется всем клиентам и они его бодренько отрисовывают, зная его вектор скорости - экстраполируют.
В этой реализации тебе очень важно, что бы все клиенты в каждый момент времени имели самое-самое актуальное состояние игрового мира и что бы задержка между сервером и клиентом была минимальной. Здесь тебе TCP мешает.
Теперь же, если ты все внимательно прочел, то наверняка понял, что RPC это вызов некоей
функции и архитектура основанная на RPC обычно шарит код этой функции между сервером и игровым клиентом.
В то время как альтернативной является архитектура с туповатым клиентом, где обмен идет исключительно
данными, а вся логика выполняется локально и только на сервере.
Ну и напоследок: совершенно очевидно, что IRL все это миксят, потому что где-то лучше послать один раз RPC, а где-то каждый третий кадр реплицировать структуру.
И вот тут то вскрывается
страшная правда: ты не можешь убрать задержку в TCP и заставить его работать "ненадежно". Зато ты легко можешь досыпать абсолютно такой же "надежности" над UDP, именно в тех местах где тебе это нужно.
