Как написать игровой сервер?

Question

[Padaboo]

Доброго времени суток! В голову пришла мысль создать игру на Java, так как играть одному неинтересно - игра будет многопользовательска.
Движок выбран Jmonkey на базе jogl.
В голову приходит клиент серверная архитектура с небольшими поправками - из того что я нашел в интернете:
1. Клиент посылает сообщения на сервер.
2. Сервер их принимает и оповещает остальных игроков - изменение координат, нажатие клавиш, etc.

Тут у нас сходу появляется несколько проблем:
1. У всех разная скорость соединения нужно как то делать поправку на пинг, даже не знаю как можно сделать корректировку.
2. Непрерывный флуд, пользователи асинхронно посылают сообщения на сервер и при каждом сообщении нужно оповещать всех остальных игроков.
Решение: 1) посылать сообщения не каждый раз при нажатии, а по таймауту. 2) На сервере составлять очереди сообщений и высвобождать их одновременно, так же по таймауту.
3. Игрок нажал кнопку ходить и начал двигаться в определенном направлении у себя на клиенте, но сообщение еще не поступило на сервер и к другим игрокам тут у нас происходит рассинхронизация, пока сервер не будет оповещен и другие игроки не получат его новые действия и координаты с поправками.
Если кто то сталкивался с такими проблемами в играх или в подобных приложениях.
Подскажите направление решения задачи, какие еще проблемы могут встретится в подобной архитектуре. Спасибо.

Comments

[Padaboo]

Многопользовательская онлайн игра – передача пакетов client-server,p2p,tcp/upd,графы
Описание процесса и поставновка задачи:

1)каждый игрок совершает действие у себя на клиенте и должен оповестить об этом игроков монстров и игровые объекты в определенном радиусе.
2) Игрок должен видеть 3d объекты и монстров только в опреденном радиусе.
3) Сервер выполяя действия за мир и монстров и оповещает об этом всех игроков или игроков в опреденном радиусе от объекта.
4) игрок монстры и сервер выполняя действия формируют сообщения или пакеты
5) формат игрового сообщения или пакета псевдокод

[player1,player2,server][time_stamp][client/server][geo_location][game_map_location][net_key][player_id][visible_radius]–
[player1,player2,server]Где каждый элемент это серриализованный объект
player[
actions[ [hit,player2,fireball],[run,vector],[rotate,radius] ],
player[param1,param2],
items[item1,item2],
message[string,chat],
gruops[clan,party],
time[time_stamp]
]

Если отправлять сообщения от клиентов на сервер и формировать большой пакет.

Проблемы:

1) Синхронизация игроков
2) Клиент серверная синхронизация
3) Низкая скорость передачи tcp/upd, низка скорость передачи clien-server
5) Обо всех пакетах должен знать только сервер,
6) Игроки находятся на разном расстоянии географически – что снижает скорость передачи
7) Необходимо посылать пакеты только соседним объектам
8) Пакеты могут потеряться, пакеты можно подменить

Варианты решения на уровне игры:
1) Двумерный массив [][] который соответсвует физической карте игрового мира
2) Добавление игровых объектов в этот массив
3) Добавление радиуса видимости для каждого объекта который может посылать пакеты
4) Объект посылает пакеты только объектам которые находятся в определенном радиусе от него
6) Формируются группы объектов
5) Один из объектов назначается главным
6) Каждый из группы объектов посылает каждому пакет
7) Создается эталонный пакет
8) Главный объект группы посылает всем эталонный пакет

Решение на уровне сети и сервер:
1)Берется карта мира и создается двумерный массив, ячейка содержит в себе информацию о регионе[country][city] и обо всех клиентах находящихся в регионе
2)По этим точкам строится граф и просчитываются кратчайшие пути до каждой точки
3)В каждом регионе выбирается несколько клиентов с самой высокой скоростью
4)Один из клиентов становится сервером передачи данных для всех остальных в регионе
5)Сервера региона передают сообщения по цепочке и по кратчайшему пути между собой и до сервера

1)Клиенты посы лают сообщения по таймауту
2)На сервере создается поток который формирует очереди сообщений
3)На главном сервере так же создается очередь сообщений

Answer 1

[Saboteur]

Обратите внимание, что свободное перемещение доступно в играх с небольшим онлайном.
В играх с большим онлайном, типа линейка/вов, у вас не свободное перемещение а подача команды "бежать на координаты x,y", атаковать противника z
следовательно не так много информации нужно передавать о каждом игроке.

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

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

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

Comments

[Padaboo]

Да сначала нужно написать чат, дали интересну ссылку по теме www.gabrielgambetta.com/fpm_live.html Всеравно какой то алгоритм синхронизации должен быть. Я нажал бежать в точку x клиент ее пробежал, но в какой то момент передумал и развернулся. В это время у другого игрока на клиенте он все еще бежит в ту же сторону.
Тоесть мы будем в следующий раз уже перепроверять бежит ли он в ту же сторону.

[Saboteur]

Padaboo: А так и бывает, когда подлагивает.
Но вы путаете количество сообщений, которые нужно отправлять.
Игрок отправляет на сервер свои действия.
Несколько действий могут быть отправлены за один пакет. Сервер отправляет игрокам сразу очередь действий, а не по каждому игроку отдельно.
Увеличиваем длительность минимального тика - сразу все становится проще.
В большинстве MUD-ов, тик идет пол-секунды. Это просто хватает.

[Padaboo]

Тут к сожалению не чат и не муд. Тут додумывать координаты и передвижение другого игрока придется для "плавности".

[Padaboo]

Сергей: вот видео https://www.youtube.com/watch?v=K6Ct61OI7Jw

[Saboteur]

Padaboo: координаты - сеточкой. Плавное передвижение - это просто анимация.
Даже если сетка мелкая, нужно передавать клик игрока на координаты x,y. Сервер просчитывает путь игрока и передает ключевые параметры - куда двигаться. Клиент отрисовывает это перемещение плавно, но переданы только
игрок на xy, двигается на x1y1, скорость z - грубо говоря 5 или 10 байт.

[Saboteur]

Не путайте анимацию, и клиент-серверное взаимодействие.

[Padaboo]

Сергей: Но тогда какая нагрузка ложится на клиент: есть 199 персонажей или объектов, нам за один "пакет" приходит допустим действия о всех них и мы на клиенте их пытаемся изобразить пока не придет следующий пакет?
Спасибо проясняется!

[Saboteur]

Мне кажется вы взялись за слишком сложную задачу в лоб.

Сервер в любом случае тут является главным оптимизатором.
Он должен решать какому игроку про что слать. Ограничивать запросы по расстоянию. Если игрок А ничего не может сделать игроку Б, то высылать им информацию друг про друга или не обязательно или можно в 10 раз реже. Подойдут поближе - будет больше деталей.

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

Часто используется UDP

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

Если же что-то вроде квейка, где критичны миллисекунды, там пару десятков и КАК бы не оптимизировать критичен пинг от игрока к серверу, а со всеми <30ms не сделать.

[Padaboo]

Сергей: Да серьезно хочу и начать именно с тестирования сообщений и синхронизации, потому что когда на него будет накручена игровая механика будет еще тяжелее.
Нет, хочу сделать один раз что то серьезное - локации это не очень хорошо, единый мир лучше всего.
Суть в том что: если слать часто очень подробные пакеты - будет идеально, но будут лаги с возрастанием количества пользователей.
если слать пакеты редко, то клиента придется заставлять угадывать что будет делать игрок прежде чем придет следующий пакет и тут уже будет сложнее синхронизировать.
Игрок пробежал 400 метров, а следующий пакет отбрасывает его назад и разворачивает на 30 градусов.

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

Например персонаж бежит по дороги и происходит смена локации (визуально находясь в том же месте)

[Saboteur]

"Нет, хочу сделать один раз что то серьезное - локации это не очень хорошо, единый мир лучше всего. "
Суть в том, что вы мыслите стереотипами.

Локация не обязательно смена места, это еще и location - местоположение.
Вычисляете РАССТОЯНИЕ между игроками, и конкретному клиенту высылать то, что касается его текущего местоположения и интерактивных объектов на определенном расстоянии X от него. Можно даже сделать так, чтобы это расстояние X было не статичным, а например уменьшалось автоматически, если рядом много объектов. То есть "в городе" например 20 метров, за городом 100 метров. Добавить исключения для тех объектов, которые контактируют непосредственно с ним или контактировали последние xx секунд

А вообще, IMHO вы беретесь за крупный проект вообще без опыта подобной работы.
В результате есть вероятность около 95%, что проект останется недоделанным, так как получить хотя бы первоначальную рабочую версию у вас получиться очень нескоро, а без заметных успехов, мотивация падает и все останется на бумажке.

[Padaboo]

Сергей: нет, я давно программирую - задача такая впервые

[Padaboo]

Сергей: просто нужно несколько идеи, дискуссий - за что вам и спасибо

[Saboteur]

Вам нужно продумать пакет, который будет отправляться для игрока.
Например объект игрока будет содержать ссылки на объекты, связанные с этим игроком.

Подошел на расстояние - добавляем.
Игроки в группе - добавляем.
Сражение с врагом - добавляем.
Везде таймстампы от последнего действия и тип.
Некоторое время нет действия и тип позволяет - удаляем.

Подошло время отправить нужному игроку пакет - у нас уже есть готовый список объектов про которые нужно отправлять информацию.
Все состояния кодируются.

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

[Padaboo]

Сергей: Допустим игроки дерутся и формируется пакет [player1,player2,] в нутри которых будут вшиты: действия, параметры, координаты, все это серриализовано и зашифровано. Мини кри получатеся.
Синхронизация конечно самое основное: игрок1 ударил игрока2, нужно как то зашифровать этот удар, отправить на сервер и оповестить игрока 2 о нанесенном уроне.
Все параметры тогда должны хранится на сервере а на клиенте только графика и отправка пакетов.

[Saboteur]

"Все параметры тогда должны хранится на сервере а на клиенте только графика и отправка пакетов."
КОНЕЧНО,
иначе я влезу в пакет, подправлю параметры и поубиваю всех на сервере с одного удара.

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

Но вы как-то еще пишете "игроки дерутся", хотя надо смотреть с другой стороны.
Игроки не дерутся, они отправляют команды на сервер.
Сервер вычисляет все взаимодействующие между собой объекты, и отправляет каждому игроку с каждым тиком результат.
Игроки могут и не драться, а например общаться.
Игрок может драться с мобом, а может покупать в магазине предмет - суть не меняется. Игрок отправляет команды, сервер отправляет результат ТИКА, а не именно этого действия игрока, поскольку действие должно быть просчитано с учетом всех остальных действий (например удар заблокирован, или игрок был уже заморожен).
Как-то так.

[Padaboo]

Сергей: "мы на сервере моделируем весь игровой процесс. за единицу времени расчитали все изменения, собрали это в пакет и разослали этот "diff" всем 100 игрокам. и получили ответ с действиями каждого игрока. т.е. получается 100 сообщений таду и 100 обратно. далее все повторяется.

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

[Padaboo]

Сергей: Понятно а про локацию что скажете, разлиновать всю карту по квадратикам, сделать из нее массив. в этот массив поместить игроков. игрокам назначить "радиус видимости" и в радиусе видимости доставлять пакеты?

Потому что допустим на всей карте 1000 игроков и отправлять большуший серриализованный и зашифрованный пакет [player1,player1000] будет тяжело для самого пакета и тежяло расшифровывать и делать обход на клиенте.

[Saboteur]

Фаербол тоже может быть объектом, который куда-то летит. Не нужно передавать, если известно в кого он летит. Но есть же вещи которые взаимодействуют с площадью.

Всегда вся карта делится по квадратикам. С радиусом взаимодействия объектов нужно работать.
Нужно же отправлять не только про игроков, но и про NPC/MOB/items - все объекты.

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

Выбираете какие действия могут обновлять список (например передвижение должно проверять что можно добавить/выкинуть).

К сожалению, у меня реального опыта разработки такого уровня не было. Я в детстве MUD писал, и чуть позже участвовал в разработке одного из java-серверов линейки, но больше как админ а не дев.
Просто был немного в курсе основных проблем и нагрузки.

Answer 2

[Padaboo]

я посрчитал что если мы имеем 100 игроков в локации то за единицу времени нужно будет отправить (100-1)*100 = 9900 сообщений - те самые over 9000

Comments

[Saboteur]

почему 9900?
Почему не 200?

100 от игроков к серверу, и 100 от сервера к игрокам?

[Padaboo]

Сергей: а это уже смотря как выглядит сеть и "пакет" если так {user-data1,user-data2,user-data3}, а если от каждого по отдельности. И опять же как их синхронизировать? Бесперебойный флуд? Или накапливать и всем одновременно рассылать или может быть ставить в очередь?

[Saboteur]

Padaboo: неважно как выглядить сеть.
Все действия просчитываются сервером.
Действия просчитываются не в порядке получения пакетов от клиента, а согласно внутренннему таймингу сервера - у каждого действия игрока есть продолжительность. На сервере в цикле идут "тики", каждый тик - что-то в мире происходит (кто-то колданул, где-то заспавнился моб, что-то передвинулось, что-то скрафтилось, какое-то кол-во здоровья восстановилось). Все крутится вокруг тиков.

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

Если какой-то игрокA решил выполнить команду, которая выполняет противоположное действие - значит со следующим пакетом игрокБ об этом узнает и его клиент начнет отрисовывать другое действие.
В зависимости от количества народу, пропускной способности, и насколько у вас оптимизирован и продуман трафик, это будет практически мгновенно.

[Padaboo]

Сергей: Очень интересная мысль спасибо! А если взять например бег. Тут может быть два варианта как нажатие мышкой и бег в одном направлении
и зажатая клавиша как в квейк. посылается пакет с направленим вектора, скоростью и клиент его рисует. Установился таймер в виде тика, сервер ждет от клиента следующий пакет с тем же действием ну или с путсым действием.
И между этими действиями происходит выстрел, вешается таймер "отката" и после этого мы ждем следующий такой же пакет.

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

[Saboteur]

Padaboo:
Клавиша зажатая в квейк отправляется как команда "вперед". К ней можно добавлять синхронизаци в виде направления. Клик мышкой "бежать сюда" также команда, просто ее нужно дольше просчитать - зато гораздо меньше инфы передавать.

Но игры типа квейк, большой онлайн не поддерживают (20 игроков уже напряг), пинг свыше 30 - уже плохо, свыше 50 - играть уже невозможно.

Поэтому вам нужно определиться с типом игры, которую вы делаете.

Тики есть в любой игре. Не может же пулемет стрелять со скоростью клика мышки - он будет стрелять с установленной скоростью.
Клиент-серверу по TCP (каждое действие должно быть отправлено и отресолвлено)
Сервер-клиенту по UDP (не все пакеты должны дойти, но среди пакетов будут или каждый с синхронизаций действий, или например каждый 5-й или 10й или по времени с более детализированной информацией. Вы же видели, что в квейке бывают лаги, после которых вроде ты вроде как "телепортируешься" на пару шагов после лага - это показатель, что сервер команды просчитывает.

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

[Padaboo]

Сергей: Понятно, а можете поделиться ссылками про tcp udp в играх что бы лучше понять разницу.
За счет чего в квейк лаги с 20 игроков? из за скорости обновления?

[Padaboo]

Сергей: мне сообщество jmonkey тоже сказало про tcp udp и про формат передачи данных valve (counter strike).

[Padaboo]

Padaboo: NIO tcp/udp

[Saboteur]

Padaboo: Какой-то игрок подключился с удаленного сервера, в некий момент или пакеты могли пойти по другому, более медленному маршруту, или просто пару пакетов потерялось, вот и мелкий лаг.
20 игроков в шутерах, при требовании апдейта по 10 раз в секунду - все же трафик.

[Padaboo]

Подключение между тиками либо после перезагрузки уровня. В шутере прокатит в rpg скорее всего нет
https://php.ru/forum/viewtopic.php?f=26&t=57729 тема
тема на хабе разработчиков
https://hub.jmonkeyengine.org/t/server-architectur...

[Padaboo]

Padaboo: подкинули идею с p2p "чатом"

[Padaboo]

Сергей: в общем подкинули идею, все это + upd и p2p - сформулирую лучише идеи и сделаю реализацию на java - выложу на хабр если кармы хватит

Answer 3

[Александр Решетняк]

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

kbengine.org
https://github.com/gamestdio/colyseus