Игра, сервер и клиент

Добрый день.
Решила я написать простенькую игру для развития реализации дальнейших планов. Пишу на С++ под Linux/BSD платформы и только!
На данный момент есть 3D мир и катающиеся по нему шарик - которым я могу управлять.
Прекрасно понимаю что такое TCP/UDP, сокеты. Писала простенькие клиент-серверные приложения стандартными средствами. Сейчас начинаю изучать boost asio для экономии времени и удобства, по крайней мере мне так кажется.
Суть моей задачи написать северную и клиентскую часть для игры о которой написала выше.
Шар в игровом мире начинает двигаться и теоретически клиент должен слать на сервер данные и получать разрешение на действие..

и так.. Что собственно мне не понятно.
Какие данные должен слать клиент игры на сервер, json, xml, serialization просто какие-то бинарные данные ?
как происходит этот механизм отправки данных?
Раньше на простых приложениях я просто подключалась к порту сервера и отправляла json и в конце "\n" что означало конец связи. Я же не могу для игры при каждом движении шара открывать сокет каждый раз и после завершать соединение верно ?! Значит нужно удерживать соединение.
А если удерживать соединение, то какой тип данных слать, если json то там много лишнего мусора будет, за секунду шар может поменять 10-100 разных координат в зависимости от скорости самого шара. А еще клиент должен получить ответ от сервера что можно двигаться по этим точкам и там нет преград.
А самое не понятное мне, это если 2 и больше шариков - которыми управляют другие пользователи.
Как мне получать координаты всех шариков пользователей в реальном времени ?
Между нами сервер, как-то слушать нужно или как это работает ?

0

helena_1990,
-можно не закрывать сокет
-можно слать UDP
-можно слать бинарные данные хотя для ваших объёмов разницу увидеть сложно
-можно после отправки своих координат получать в ответе координаты других

1

Сообщение от helena_1990 Как мне получать координаты всех шариков пользователей в реальном времени ?

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

Сообщение от helena_1990 Какие данные должен слать клиент игры на сервер, json, xml, serialization просто какие-то бинарные данные ?

зависит от игры. если важна производительность, то бинарные подойдут лучше, т.к. их парсинг занимает меньше времени.

Сообщение от helena_1990 как происходит этот механизм отправки данных?

в смысле как? конкретный вопрос задайте.

Сообщение от helena_1990 Я же не могу для игры при каждом движении шара открывать сокет каждый раз и после завершать соединение верно ?! Значит нужно удерживать соединение.

зависит от протокола транспортного уровня(ТСР/UDP).

Сообщение от helena_1990 за секунду шар может поменять 10-100 разных координат в зависимости от скорости самого шара.

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

советую книгу почитать, так хотя бы сложится понимание о том, что вы вообще хотите.
https://www.ozon.ru/context/detail/id/137764980/
P.S. книгу можно найти в интернете.

2

Сообщение от vxg можно слать бинарные данные хотя для ваших объёмов разницу увидеть сложно

решила boost_serialization использовать, малые расходы на трафик.

Сообщение от GbaLog- зависит от того, кто рулит.

Рулит сервер. Диаметр всех шариков и координаты x,y хранятся на сервере.

Сообщение от GbaLog- зависит от протокола транспортного уровня(ТСР/UDP).

решила UDP т.к игра будет быстрой в реальном времени.

Сообщение от GbaLog- вам надо определиться с тем, кто всё-таки рулить будет, сервер или клиент. сейчас большинство игр основываются на топологии клиент-сервер, т.к. так проще всего защитить свою игру.

Сервер есть и все проверки будут лежать на нем..

Сообщение от GbaLog- Сообщение от helena_1990 как происходит этот механизм отправки данных? в смысле как? конкретный вопрос задайте.

Как синхронизировать данные всех игроков ?
Нажала кнопку W, шарик начал движение, запустился механизм отправки пакетов на сервер о нажатой кнопке?!
Получается данные нужно отправлять в секунду n-раз? Я не понимаю как нужно синхронизировать данные между всеми.
Если я буду запрашивать раз в секунду с сервера координаты всех шариков это не будет похоже на некую ДДОС атаку на сервер ?
Получается не совсем в реальном времени если игра будет запрашивать данные раз в секунду. Шарики столкнулись а на сервере этого еще не видно из-за пинга. Или у кого-то медленный интернет то его шарик будет дергаться что для 3D мира с физикой совсем ужасно. Это как-то решается интерполяцией или как ?

0

Сообщение от helena_1990 Нажала кнопку W, шарик начал движение, запустился механизм отправки пакетов на сервер о нажатой кнопке?!

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

Сообщение от helena_1990 Если я буду запрашивать раз в секунду с сервера координаты всех шариков это не будет похоже на некую ДДОС атаку на сервер ?

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

Сообщение от helena_1990 Шарики столкнулись а на сервере этого еще не видно из-за пинга.

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

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

1

Сообщение от GbaLog- сервер же, в свою очередь, шлёт вам новые координаты игры n раз в секунду и вы по ним, соответственно, двигаете шарик.

Получается чем быстрее игра, тем больше запросов нужно слать. Начинаю понимать...

Сообщение от GbaLog- шарики могут столкнуться только и только на сервере

Поняла спасибо.

Сообщение от GbaLog- всё-таки рекомендую прочесть ту книгу

Полезла искать pdf, если у вас есть буду очень рада.

Всем спасибо

Добавлено через 13 минут

Сообщение от helena_1990 Полезла искать pdf

нашла )

0

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

Я, конечно, мимокрокодил, но, по-моему, не самая лучшая идея. Практически во всех онлайн играх, что я видел, клиент сам рулил своим передвижением, а сервер лишь изредка имел возможность "одёрнуть" игрока, если произошла какая-либо рассинхронизация. "Двигать шарик" непосредственно по ответам от сервера и накладно (на каждый "условный кадр" по пакету слать? а для быстрой игры совсем ахтунг) и не очень отзывчиво. Нажали на кнопку "W" и ждём:
1)обработку нажатия на клавишу
2)отправку сообщения серверу
3)время передачи до сервера
4)обработчик поступивших данных сервера
5)отправку сообщения обратно
6)время передачи до клиента
7)вот только теперь меняем координаты и перерисовываем кадр???

По мне так совсем не торт. Нельзя на каждый чих спрашивать разрешение у сервера. Подтверждение нужно получать только для каких то более существенных действий. В том же Wow при отвале от сервера можно ещё побегать пару секунд, пока клиент пытается переподключиться, а вот применить какую-нибудь способность уже не выйдет, клиент будет ожидать ответ от сервера (так и будешь бегать с активной иконкой скила, и анимацией его начала, пока ответ не придёт или таймаут дисконекта не выкинет в меню).

1

Сообщение от Lolobotik Нельзя на каждый чих спрашивать разрешение у сервера

Я так и сделала - не спрашиваю у сервера всё подряд. У меня на сервере видны только столкновения или какое-то особое действие, скажем прыжок, и если предыдущие данные те-же, их не передает на сервер(шарик стоит на месте или двигается только по оси X). Кадры с координатами при хорошей оптимизации в сериализации совсем не пугают сервер как выяснилось на тестах. порядка 10 udp кадров в секунду(думаю лучше больше сделать) ну и интерполяция объектов хорошо спасает. Сделала эмуляцию из 10000 клиентов, и совсем нагрузки нет как на сеть(ушло ~10mbit), так и на процессор(Xeon(R) CPU E5-2603 v4) не топ. Хотя репликация объектов у меня не идеальная но я стараюсь

0

Сообщение от Lolobotik Практически во всех онлайн играх, что я видел, клиент сам рулил своим передвижением...

Вот раздолье для читеров)
К примеру в танках весь рендер происходит на стороне сервера. Вот это тема) Всякие там валлхаки, телепортеры идут лесом. И подделка исходящих пакетов не имеет смысла.

0

Сообщение от Lolobotik на каждый "условный кадр" по пакету слать?

вы успеете нажать хотя бы 60 клавиш за секунду?

Сообщение от Lolobotik Нажали на кнопку "W" и ждём:

нет, не так.
нажали клавишу и бежим туда, куда нажали, а если сервер внезапно решит, что ты читер и не мог туда прийти, то тебя вернёт назад на позицию, которую сервер просчитал.
это нужно для того, чтобы читы было невозможно сделать, имея только влияние на клиента.
вы видели когда-нибудь WarCraft III? там всё на стороне клиента делается и там постоянно страдали от мапхака, да и сейчас страдают, т.к. сделать его - раз плюнуть.

Сообщение от Lolobotik Нельзя на каждый чих спрашивать разрешение у сервера.

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

0

Фразы

сервер же, в свою очередь, шлёт вам новые координаты игры n раз в секунду и вы по ним, соответственно, двигаете шарик.

и

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

звучат, если честно, диаметрально противоположно. Если бы сразу был описан второй вариант, или слова подобраны более тщательно, у меня не было бы никаких вопросов.

в динамичных играх надо продумывать, на какие действия надо спрашивать разрешения. например, на поворот камеры не надо, а на изменение направления движения надо, даже если ты на 1 градус отклонился

Это тёмная для меня тема, так что не буду спорить, но пример про Wow из моего прошлого поста вполне актуален.

0

Сообщение от lArtl Вот раздолье для читеров)

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

0

Сообщение от helena_1990 Не думаю что рендер происходит на сервере...

На сервере ( под этим подразумевается, что данные о движении танка отправляются на сервер, а с сервера - то, что должно отображаться в данный момент).

0

Сообщение от lArtl На сервере

Вот и я имею ввиду что расчет не совсем как понятия рендера с использованием графических библиотек а гораздо проще

0

Сообщение от helena_1990 Вот и я имею ввиду что расчет не совсем как понятия рендера с использованием графических библиотек а гораздо проще

Ну да, рендеринг на стороне сервера, Server Side Rendering, SSR - это не рендеринг с использованием графических библиотек)

0

Сообщение от lArtl Ну да, рендеринг на стороне сервера, Server Side Rendering

SSR явно не для серверов WOT. Вот бы было весело посмотреть как упадет кластер даже на 1к онлайн игроков )) Там уже не рилтайм а пошаговая стратегия бы получилась с 0 fps

0

Сообщение от helena_1990 SSR явно не для серверов WOT. Вот бы было весело посмотреть как упадет кластер даже на 1к онлайн игроков )) Там уже не рилтайм а пошаговая стратегия бы получилась с 0 fps

Вы троллите?)

0

Сообщение от lArtl Вы троллите

Не совсем просто SSR технология не совсем для этих задач. В случае с WOT оптимизация на уровне сети координат. А модель просчета траекторий на сервере не требует рендеринга как самого понятие в это вложенного. Просчитать матрицу координат вершин куда легче. Ну я так думаю, а как оно работает на самом деле нам точно не скажут

0

Сообщение от helena_1990 А самое не понятное мне, это если 2 и больше шариков - которыми управляют другие пользователи.

т.е. в данном случае существует 2 подхода - авторитарный сервер и неавторитарный. Авторитарный - клиенты отправляют нажатия клавиш. Сервер все это обсчитывает и обновляет состояния игровых объектов у клиентов (т.е. рассылает каждому новые координаты и т.д.). Это в плане нахождения консенсуса наиболее удобно - т.е. все считает сервер в случая рассогласования клиент автоматом не прав.
Второй вариант - неавторитарный сервер. Он занимается только тем что реплицирует присланные события (нажатия клавиш и т.п.) другим игрокамб весь счет происходит на компе каждого. При таком варианте сервер в принципе не обязательное явление. каждый может отсылать события всем другим вообще напрямую. Но нахождение консенсуса вопрос практически неразрешимый.
Вариант третий - каждый считает логику/физику только для своего перса и отправляет обновления координат/статуса всем остальным через сервер или напрямую. Это в плане возможности читов вообще фирменное безобразия.При этом попытки делать какой то античит в конечном итоге разовьются до авторитарного сервера.
Теперя подробнее про минусы авторитарного: нагрузка по моделированию физики/логики на один комп (сервер) и опять же нагрузка по сетевому трафику. Ну с физикой/логикой тут ничего не попишешь. А вот с трафом методы есть.
Суть в чем - обычно в играх не все персонажи играбельны. т.е. есть игроки и есть NPC (в простонородье неписи) управляемые компьютером. Очевидно что состояние игроков серверу необходимо рассылать по любому. А вот с неписями все гораздо интереснее. Им можно рассылать только обновления параметров управляющего ими ИИ. Причем при наличии
группового ИИ рассылать можно обновления группе а не каждому отдельному неписю. Синхронность их работы обеспечивается тем что один и тот же алгоритм дает одни и те же результаты при одних и тех же исходных данных.
Второй апгрейд - серв так или иначе считает видимость игроком других игроков/неписей/изменяемых объектов и шлет обновления только тех объектов которые игрок видит/с которыми так или иначе взаимодействует по правилам игры.

Добавлено через 7 минут

Сообщение от helena_1990 Значит нужно удерживать соединение.

Обычно делают несколько сокетов на каждого клиента. Как минимум один удерживающий коннекцию TCP для тех сообщений доставка которых должна быть гарантированна. К примеру сообщений о появлении другого игрока в поле зрения (а соответственно по такому сообщению клиент должен создать соответствующий объект и как то связать свой внутренний ID объекта с ID объекта на сервере). второй сокет UDP для сообщений которые актуальны только какое то время. К примеру апдейт координат другого игрока. Т.е. если несколько пакетов выпадут то за время их повторной передачи эти данные уже потеряют актуальность. при этом актуален будет последний по времени отправки с сервера пакет. Соответственно повторно отсылать выпавшие пакеты для таких апдейтов не имеет никакого смысла.

Добавлено через 1 минуту
Это то что касается реалтайм игр. Для пошаговых стандартная система запрос/ответ.

Добавлено через 1 час 53 минуты

Сообщение от helena_1990 Просчитать матрицу координат вершин куда легче.

Коллизия выпуклых многоугольников - O(n^3) скалярных произведений от количества вершин.

Сообщение от helena_1990 В случае с WOT оптимизация на уровне сети координат

Там оптимизация и рядом не ночевала. По всей видимости куча видеокарт обсчитают коллизии чрез PhysX. Во всяком случае коллизион меши там именно под PhysX заточены - сборники лоуполи выпуклых многогранников. типа шестигранника вместо цилиндра.

Сообщение от helena_1990 А модель просчета траекторий на сервере не требует рендеринга как самого понятие в это вложенного.

Модель просчета нет. А вот защита от читов будет абсолютной или почти абсолютной только при серверном рендеринге. Других реальных способов от прозрачных текстур препятствий и текстур повышенной заметности целей других игроков не существует. Да и с автоаимом куда потруднее станет чем при использовании точных координат цели извлеченных из клиента.

1

Не думаю что они используют cuda++ на серверах. Это же сколько нужно купить оборудования. Wargamming конечно не бедные ребята но не настолько чтобы покупать сотни тысяч серверов с видео-картами которые морально быстро устаревают. Сделают новые фишки какие-то и все сервера апгрейдить ? А синхронизировать как ? На одном только RU1 больше ~100к игроков онлайн. А расчет до ms. Хотя с другой стороны иногда ПТ-САУ попадает в окна по интересной траектории.. В принципе для коллизий можно использовать совсем примитивы. Часто видно как снаряд попадает куда-то вот совсем не туда. Ну ладно это от темы я уже ушла
Я пока что сделала сериализацию всего мира на сервере + просчет вершин и поверхностей mesh достаточно большого мира, и без GPU всё летает на моем слабеньком сервере Вот я и думаю что в wot тоже не обязательно прибегать к таким суровым методам как использоватье 10ки тысяч GPU ))

0