Представьте себе многопользовательсукую игру по типу lineage
Описание процесса и поставновка задачи:
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)На главном сервере так же создается очередь сообщений
Хочу знать ваше мнение по поводу данного алгоритма и концепции в целом.
Комментарии (77)
frol
02.04.2016 09:58+7Если я правильно понял, то, во-первых, у вас тут вопрос, а не статья, а с вопросами люди ходят в гугл или "тостер", во-вторых, у вас тут не вопрос, а поток сознания, который вообще невозможно разобрать.
Padaboo
02.04.2016 10:29-13Прежде чем статья попала в гугл ее кто то вероятно написал и обсудил. Думаю в гугле есть не все.
kahi4
02.04.2016 11:12+5Архитектура онлайн игр (точнее, рекомендации по ее реализации) в гугле уж точно найти можно. Да даже на хабре.
Не в обиду, но вы уверены, что у вас в данный момент хватит компетенции, чтобы реализовать вами запланированное? Может стоит пока не лезть в p2p, остановиться на классической реализации клиент-сервер, а дома для разминки попробовать реализовать p2p чат, и только потом уже думать об каких-то усложнениях архитектуры?Padaboo
02.04.2016 11:17-7Я покопался в интернете на эту тему, https://github.com/Padaboo/javasamples/wiki
Простой клиент сервер не решает проблем в топике, есть идеи?kahi4
02.04.2016 12:07+7Хорошая статья на хабре, первая ссылка гугла, вторая ссылка гугла.
Окей, по проблемам, обозначенным вами (это не те проблемы, с которыми вы столкнетесь, а лишь ваши гипотезы, нужно заметить, т.е. вы решаете проблемы, которые предполагаете, а не на которые наталкиваетесь).
1) "Синхронизация игроков" — в общем то это задача, а не проблема. Интерполяция, экстрополяция и прочие методики. Вы не описали жанр, если это действительно типа line age (ММОРПГ), тут гораздо меньше подводных камней и боли, чем в шутерах (была как-то статья о том, сколько геммороя пришлось решать при разработке последнего battlefield. Вот там с интерполяциями большие трудности)
2) "Клиент серверная синхронизация" — см. пункт 1.
3) "Низкая скорость передачи tcp/upd, низка скорость передачи clien-server" — либо не ориентируйтесь на игроков с каналом 256 кб, либо минимизируйте необходимую для передачи информацию, уменьшайте количество пакетов (для ММОРПГ совершенно не обязательно 60 раз в секунду передавать полную информацию). Посмотрите на алгоритмы, применяемые в других сферах, например, ГНСС. Используйте понятие супер-кадра, состоящего из нескольких кадров. В кадре только совсем оперативная информация (какие действия совершают другие игроки), а так же часть изменений мира (причем именно изменений, а не все состояние мира каждый раз). Пусть супер-кадр состоит из 10 кадров, кадр пересылается 20 раз в секунду, тогда за секунду у вас дважды будет полная информация об изменившемся мире, и 20 раз в секунду оперативная информация. (Более точные решения давать сложно, ничего не зная о механике игры).
5) "Обо всех пакетах должен знать только сервер", — а в чем проблема то?
6) "Игроки находятся на разном расстоянии географически" – что снижает скорость передачи — ставьте сервера в разных географических регионах.
7) "Необходимо посылать пакеты только соседним объектам" — что?
8) "Пакеты могут потеряться, пакеты можно подменить" — ни первое, ни второе — не ваша проблема. Точнее так: в UDP пакеты могут теряться, это нужно учитывать, но если вы поверх UDP залепите гарантированную доставку пакетов — сразу выбирайте TCP. Иначе необходимо делать саму механику игры такой, чтобы пропуск пакета не был критичным (например, положение монстра в прошлый момент времени можно интерполировать), а критичные вещи дублируйте (с приписанием некого ID) по кадрам. Что касается подмены — сервер должен проверять валидность действия, а то, что клиенту может прийти подмененный пакет — с этим вы не многое сможете сделать (опять же, тогда клиент ответит невалидным пакетом, на что резонно его отключить с соответствующим сообщением).
Варианты решения на уровне игры:
— и что это решает?
1) Двумерный массив [][] который соответсвует физической карте игрового мира
2) Добавление игровых объектов в этот массив
3) Добавление радиуса видимости для каждого объекта который может посылать пакеты
Нет, я все же настоятельно рекомендую почитать несколько статей, еще лучше книг, набить руку на проектах по-проще и по-легче.
6) Формируются группы объектов
5) Один из объектов назначается главным
6) Каждый из группы объектов посылает каждому пакет
7) Создается эталонный пакет
8) Главный объект группы посылает всем эталонный пакет
Стоп, вы под «объектом» подразумеваете клиент игрока? Чего? «Решение на уровне сети и сервер:» противоречат моей догадке о том, что вы подразумеваете под объектом. Но зачем тогда внутри сервера игровые объекты обмениваются информацией?
Вообще удручает: это не тостер, а хабр. Тут все делятся своими решениями проблем, а не спрашивают, как их решить (с вроде 2012 года или когда там тостер запустили). Ну ладно, если бы только это. Но на самом деле, есть еще несколько проблем:
— вы пытаетесь сделать то, что вам не под силу (уж простите, возможно вы просто не спали неделю, обдумывали архитектуру, поэтому у вас получилось сомнительное описание)
— вы не предоставили никакой информации ни о механике, ни о ожидаемых нагрузках, ни о посещаемости, ни о ресурсах
— вы решаете не те проблемы, которые возникают
— своими решениями порождаете еще большие проблемы
Помимо совета начать с чего-то попроще, а так же почитать умных книжек, советую спрятать топик в черновики и сделать прототип (или альфа-версию) с совсем топорным решением (обычная клиент-серверная архитектура) и посмотреть, какие проблемы действительно возникнут.
Gaikotsu
02.04.2016 12:18+2Да автору стоило бы взять к примеру те же исходники любого эмулятора ла2 и поизучать их — как все что он пишет реализовано "по уму". Благо исходники эмуляторов линейки в интернете найти можно на любой вкус, почти все варианты веток развития — l2jserver, phoenix/overworld и т.д. и т.п.
Тогда скорее всего этого потока сознания вообще не появилось бы.Padaboo
02.04.2016 12:38-3В основе лежит идея, просто есть ряд проблем их можно обсудить и придумать решение. Несколько движков с чужим кодом до старости крутить можно. Пример:
Я написал некое p2p приложение в нем есть: клиент написаный на C++, сервер написанный на Java, а внутри вставки из С/Python+asm, код подвергся обфускации и документации нет.kahi4
02.04.2016 12:40+4p2p приложение в нем есть: клиент написаный на C++, сервер написанный на Java
Какое емкое противоречивое само себе утверждение.Padaboo
02.04.2016 13:19-6Человек проводит оптимизацию и вставляет низкоуровневый код? что в этом противоречивого?
Mingun
02.04.2016 13:49+6Для начала потрудитесь загуглить аббревиатуру p2p
Padaboo
02.04.2016 15:35-6потрудитесь почитать тему
Mingun
02.04.2016 17:25+2Как только вы определитель с тем, что же вы все-таки написали и напишете статью, а не этот высер, как сказали в первом комментарии.
Padaboo
02.04.2016 18:08-5Хорошо вы когда включаете компьюте, к интернету подключаетесь? К маршрутизатору. Передача данных происходит по воздуху? — нет сокеты.
Mingun
02.04.2016 18:47+1Извините, я не понимаю, что вы говорите. В профиле у вас вроде страна Россия стоит, а впечатление, что разговариваю через переводчик из 2000-х.
mwizard
02.04.2016 19:20+5Скрытый текст
withkittens
02.04.2016 20:16+3О, Magic Gooddy!
JIghtuse
02.04.2016 21:55Синтезатор речи у него забавный был, я в основном только этим и баловался, если устанавливал.
Padaboo
02.04.2016 12:29-4Спасибо, дело в том что если игровой мир меняется минимум 1 раз в секунду то — придется отправлять обновление всего мира каждому игроку т.е. отправлять всю базу данных кажому игроку.
И один игрок в Америке, второй в России, третий Англии отсюда собственно и тема.kahi4
02.04.2016 12:36Так поставьте сервера в Америке, России и Англии, дальше вопрос репликации. Игровой мир меняется гораздо чаще, все раз в секунде. Нужно выделить константные/медленно изменяющиеся объекты, либо объекты, требующие синхронизации только раз (при загрузке). А дальше — бить на небольшие участки, сохраняя баланс между видимостью и размером пакета.
"Посчитать расстояние между всеми объектами" — вы будете считать его до умопомрачения, если объектов много. Есть достаточно хорошие алгоритмы поиска объектов, которые в данный момент могут интересовать игрока. И они никак не связаны с клиент-серверной архитектурой.Padaboo
02.04.2016 13:13-3Теория графов кратчайшие расстояние
kahi4
02.04.2016 14:27+5Еле сдерживаюсь от того, чтобы прибегнуть к художественно-выразительному приему, при котором первая часть слова заменяется на нецензурное, предназначенное для акцентирования несостоятельности.
Что вы так заладили с теорией графов? Во-первых, вы ищете расстояние на географической (пусть и виртуальной карте), т.е. в эвклидовом (да хоть в лобачевском) пространстве, никто не ищет расстояние (не путать с кратчайшим путем) в нем теорией графов. Более того, оно строго задано как квадратный корень из суммы разностей координат. Даже, если вдаваться в матан, расстояние бывает разным (я привел декартово), как бы парадоксально не звучало. Например, манхетаннское. Обычно нужно обосновывать его состоятельность, но и у вас не рокет сайнс, как говорится.
Так вот. Даже если брать его, все равно — найти расстояние между всеми объектами в игровом мире — задача не простая (квадратичная сложность), для чего используются различные уловки (и нет, не теории графов. Не в прямом виде, по крайней мере). Если вы хотите, чтобы вам тут их рассказали — справедливо получите вежлевую просьбу сходить в гугл. И опять же, это не имеет никакого отношения к клиент-серверу. Да и вообще, в своем движке вы уже должны были решить эту задачу (например, если на слэнге вы "кидаете массуху", должны определить, каких "мобов" она должна поразить).
Во-вторых, теория графов достаточно большая и расплывчатая наука. Матрица тоже является графом (а еще тензером, но теория тензорных исчислений не достаточно хипстерская, что ее лепить куда непоподя). Так что поиск эвклидова расстояния в теории графов тоже почти наверное как-то описывается.Padaboo
02.04.2016 18:03-3Не очень большая эта теория, советую «дискретная математика для программиста»
kahi4
02.04.2016 20:18+3Теория конечных автоматов не очень большая (к слову, технически ее можно считать подмножеством теории графов), но что-то в книге только по ее основам 600 страниц. Да и имел ввиду я то, что в теорию графов можно вписать много чего. По своей сути — граф — это лишь способ представления данных. Барицентрическая система координат так же может быть представлена в виде графа, да даже декартова. Это не означает, что все нужно все задачи решать исключительно в рамках теории графов. Особенно поиск расстояния.
P.S. Я, в общем то, инженер, поэтому в состоянии осилить книги "для инженеров". Уж простите, но о большинстве книг "чего-то там для программистов" у меня сложилось плохое впечатление, так что в 99% случаев это ассоциируется с "для чайников". Исключения бывают, но даже в достойных книгах все ужасно урезано, упрощено и оставляет только кучу вопросов после себя, что потом все равно лезешь в книгу для ВУЗов.
oxidmod
02.04.2016 10:30+1>> 1) Двумерный массив [][] который соответсвует физической карте игрового мира
Боюсь массив со всем игровым миром и всеми объектами будет огромным… Нужно как минимум разбить на локации, но локации не должны касаться видимости в клиенте, чтобы игрок не исчезал с экрана переступая невидимую черту. Либо делать так, чтобы локации накладывались друг на друга и находясь на пересечении игрок мог получать пакеты с обеих локаций (правда чревато подлагиваниями на границе локаций)
>> 8) Главный объект группы посылает всем эталонный пакет
не уверен что этот везунчик будет рад своей роли
>> 1)Клиенты посы лают сообщения по таймауту
а если я просто сижу в пустой локации и АФКашу, зачем мой клиент шлет бесполезные пакеты серверу?
+ таймаут — это гаранированный лаг между нажатием кнопки и пакетом отправленным на сервер. в той же ла2 дагерщики и хиллеры играют на клаве как на рояле и скилы должны применяться мгновенно.Padaboo
02.04.2016 10:39-6Да массив будет огромным- вся бза данных, одно большое сообщение со всеми объектами, поэтому сообщениями будут обмениваться только ближай друг к другу объекты и сервер.
Незнаю будет он рад нет своей роли но кто то должен это делать, какой то из клиентов с быстрой скоростью или сервер.
Если афк то да, а если вы бежите по локации с зажатой клавишой W?oxidmod
02.04.2016 10:44+1>> Незнаю будет он рад нет своей роли но кто то должен это делать, какой то из клиентов с быстрой скоростью или сервер.
а еще этот клиент по исходящему трафику сможет понять что он везунчик и, допустим, подделать эталонный пакет. что тогда?Padaboo
02.04.2016 10:52-2Это уже отдельный вопрос безопасности:
1)Шифрование самого сообщения
2)Прием сообщений только от клиента — прикрепления хэша или ключа клиентскоро приложения
3)Некий гвард
4)Жалобы пользователь
5)Контроль админаoxidmod
02.04.2016 11:14+1если клиент шифрует пакеты, а клиент у игрока, то это всеравно что не шифровать. При желании клиент расковыряется и алгоритм шифрования будет получен вместе со всеми ключами
Gaikotsu
02.04.2016 12:10Боюсь массив со всем игровым миром и всеми объектами будет огромным… Нужно как минимум разбить на локации, но локации не должны касаться видимости в клиенте, чтобы игрок не исчезал с экрана переступая невидимую черту. Либо делать так, чтобы локации накладывались друг на друга и находясь на пересечении игрок мог получать пакеты с обеих локаций (правда чревато подлагиваниями на границе локаций)
В той же линейке кстати примерно так и сделано — весь игровой мир разбит на регионы определенного размера, и для каждого региона ведется обновляемый список-массив объектов в нем (игроков, неписей, предметов на земле). когда к примеру игрок заходит в регион, то ему присылаются пакеты с информацией обо всех объектах в этом регионе, а так же в соседних регионах, ну а игрокам уже находящимся в этом регионе и прилегающих — присылается информация, что рядом новый игрок. в принципе таким же образом броадкастится и много другой информации (каст скиллов, появление на земле дропа и его подбор и т.д.) — всем игрокам текущего региона и соседних.
Кстати как раз из-за этого в линейке есть возможность делать очень нехорошую пакость с игроками в определенной локации — злоумышленник может накидать скажем несколько десятков тысяч стрел отдельными кучками и любой игрок, пришедший/телепортировавшися в эту локацию банально подвисает, т.к. клиент просто офигевает от такого количества одномоментно прилетевших пакетов и необходимости все это отрисовать.
lexore
02.04.2016 12:52Для начала, почитайте вот это http://fursoffers.narod.ru/Packets.htm
Ещё там не упомянута geodata — у lineage на неё тоже много завязано.
В играх типа линейки "видимость моба/игрока" — фикция.Padaboo
02.04.2016 13:59-3Для сервера может и фикция, а на видяхе и графике сильно сказывается
kahi4
02.04.2016 14:12Ну так на клиенте и рассчитывайте видимость. Это вообще никаким боком к клиент-серверной архитектуре не относится (единственное преимущество — пересылать меньше данных. Но накладки от этого мизерные по сравнению с необходимой вычислительной мощностью сервера для этого).
rPman
02.04.2016 18:23+2Если готовы как следует заморочиться, получить минимальную (при локально ограниченных перемещениях — это 99% времени игрока) нагрузку на сеть за счет незначительного повышения нагрузки на машины игроков (и p2p можно будет позже вписать для еще большей разгрузки сетевых каналов сервера, к тому же сами сервера на столько близки по логике с клиентами что так же красиво раскидываются по географическому положению):
- клиенты передают на сервер только действия пользователя (вплоть до на низком уровне — нажатия кнопок на мышке и клавиатуре но лучше конечно определить события, которые что то меняют в мире)
- Каждый клиент хранит информацию обо всех объектах в своем окружении и самое главное, обо всех объектах, которые необходимы для проведения вычислений 'следующего состояния' объектов, которые могут его менять
2.а. при перемещении игрока ему с сервера передается информация обо всех новых объектах, попадающих в эту область видимости (для оптимизации рекомендуется область загрузки объектов слегка расширить, и слать необходимую информацию заранее но фоном, например расставляя приоритеты для данных по направлению движения)
2.б. таким образом. все клиенты получают события ото всех игроков в своем окружении (игроки в данном случае как те же объекты мира но действие которых нельзя вычислить, хотя можно всегда найти ситуации где и тут можно соптимизировать, например если игрок сидит на машине, управляемой алгоритмом — значит координаты можно не слать) - каждый клиент вычисляет следующее состояние на основании хранящихся у него данных, выполняя фактически всю ту же работу что и сервер но только в локальном окружении игрока
3.а. всегда можно часть критичной логики завернуть на серверную сторону, например генерация лута - ввести лог событий и состояний всех объектов для возможности отката их назад с проигрыванием входящих событий, в случае, когда часть из них несинхронизирована по времени (например игрок отреагировал на действие другого игрока но это событие опоздало, соответственно откатываем действия назад и проигрываем с новым логом состояний (на самом деле алгоритм не тривиальный, возможны вариации на тему накопления событий в течении интервала времени или по отмашке серверного тикера, это если реализовывать p2p рассылку событий от игроков)
- Подойти к выбору протокола tcp/udp с особой тщательностью, какие проблемы хотим — лаги или глюки (игроков будет колбасить, команды теряться и еще разнообразные артефакты), так же возможна комбинация протоколов для разного типа трафика.
но технология подразумевает возможность корректной работы при потери данных (откатываем состояние, и перестраиваем с новыми данными), а значит udp само напрашивается. - защита от злонамеренной рассинхронизации данных клиент-сервер (когда клиент рисует свое состояние объектов, несовместимое с сервером, с попыткой считерить) встроена в идеологию — пользователь ничего не может изменить в алгоритме, потому как сервер и клиенты всеравно будут видеть верную картину, а не ту что читер себе нарисовал.
6.а. но этот алгоритм слабо защищен от ботов автоматизации действий на стороне клиента — информации много, серверные алгоритмы и логика — на виду, некоторые игры, с обманом игроков будет сложно реализовать (типа вот ваши статы с коэффициентами, вы думаете что формула dps — простое умножение а она трехэтажная с интегралами)
p.s. алгоритм на самом деле очень сложный, но эта технология идеальна для сложных миров (динамично изменяющиеся от действий игрока, например разрушаемое или изменяемое окружение) с большим количеством игроков и логикой, максимально реализуемой на стороне клиента (помним, если переборщить, то боты автоматизации будет очень просто написать)Padaboo
02.04.2016 18:45-3В общем объект(клиент/сервер) просто посылает сообщения серверу и другим игрока.
Вопрос в том как это оптимизировать: 1) ускорить передачу 2) отсечь ненужную информацию 3) правильно синхронизировать
Спасибо интересно. Добавлю к описанию алгоритма — есть над чем подумать.
Самое сложное сформулировать — а захардкодить уже не так сложно.rPman
02.04.2016 19:16Все алгоритмы в конечном счете отличаются в том что именно рассылает сервер клиентам — в описанном мною возможна ситуация, когда сервер долгое время шлет клиентам ТОЛЬКО нажимаемые кнопки или уже как бонус — возможность слать это сразу между клиентами (но на сервер конечно придется слать всеравно).
Вы представляете на сколько это оптимальнее чем слать изменения состояния окружения, особенно когда вы решить сделать его изменяемым (собственно по этой причине ММРПГ это не делают, так как тупо шлют все всем с квадратичным ростом трафика при массовках)
kahi4
02.04.2016 18:52+7Все, хватит. Вам дают советы, вы отпираетесь. Зачем тогда спрашивать, если все равно не слушаете?
По порядку. Вы действительно считаете, что пробрасывание пакетов через другие машины будет быстрее, чем прямое обращение к серверу? Не хочу вас расстраивать, так что пусть вас расстроит физика. А поиск быстрейшего пути пакета (замечу, что он далеко не всегда самый короткий) вообще задача стека TCP/IP (UDP/IP). Думаете, вы сможете решить эту задачу эффективнее, чем 30 лет опыта нескольких сотен бородатых мужиков? К слову, ищется он без какой-либо теории графов, надеюсь, более подробную об этом информацию вы в состоянии найти самостоятельно.
Хорошо, допустим, вы хотите, чтобы определенные клиенты брали на себя функции сервера. Даже не хочу начинать перечислять возникающие проблемы. Например, что если владелец этого клиента — недобросовестный? Если через него будут играть много игроков и все в разных локациях, уверены, что клиент потянет эту производительность? Вы хоть представляете, какие проблемы возникают при реализации репликации? Или это переложите на плечи, допустим, mongo? Если да, то почему сразу так не сделать? И опять же, и что дальше?
- Как вы будете определять геопозицию игроков? А если они не захотят предоставлять информацию?
- "visible_radius" на какой черт это передавать каждый раз? Это вообще константа, на которой завязана далеко не графика (у графики свой радиус видимости).
- rotate,radius поворот не так задается
- message[string,chat], зачем это пересылать каждый раз? Почему не сделать для этого отдельный канал?
- gruops[clan,party], мегаважная информация, действительно достойная пересылки в каждом сообщении (пакете), ага.
- "игрок монстры и сервер выполняя действия формируют сообщения или пакеты" С чего вдруг монстры формируют сообщения? Не нужно смешивать все в одну кучу.
Теперь о том, как это все же нужно делать:
- Если вы замахиваетесь на клиентов со всех точек мира — размещайте свои сервера в разных регионах. Репликации между своими серверами делаются гораздо проще, чем между неподвласными вам машинами. А еще лучше — замахнитесь только на какой-то региональный рынок. Окупится, будут деньги — наймите специалиста, хорошо в этом разбирающегося и со стажем 5+ лет, да и у самого появятся идеи к этому времени.
- Сделайте рабочий прототип. Профилируйте слабые места, определяйте, что создает трудности, откуда берутся задержки, с чем возникают проблемы. У меня складывается впечатление, что вы сейчас находитесь на стадии "хм, а давай ка я запилю ММОРПГ. О, так там же нужно будет решать эти проблемы. И как их решать?". Судите сами — вы задаете вопрос, напрямую касающийся способа организации хранения данных (пусть и под предлогом их пересылки), организации мира и всего такого. Это означает, что вы еще их не решили, что, в свою очередь, указывает на то, что максимум, что у вас есть — бегающий персонаж в unity по равнинным просторам.
- Скорее всего, вы используете какой-то движок (unity, UE, cryengine), у которого из коробки уже есть нужный функционал, которому вам хватит с головой. Когда начнете упираться в этот функционал — хватит денег нанять 5 специалистов, поверьте.
- Ближе к коду и архитектуре: разбиваете весь игровой мир на регионы. Регионы бьете на субрегионы, достаточно маленькие. Статически (это очень важно, так как просчитывается только раз, при генерации мира) рассчитываете области видимости и взаимодейтсвия субрегионов, исходя из чего в дальнейшем будете определять, что вам нужно пересчитывать и пересылать. Когда клиент заходит на сервер — определять, в каком регионе и субрегионе он сейчас находится, и пересылаете ему всю информацию о текущем субрегионе (а так же те, которые он может видеть/взаимодейтсвовать с которыми). В дальнейшем пересылаете только изменения в этом мире (лежащие на полу предметы, например, пересылать второй раз нет смысла). Передаете (и не очень часто, например, как я предлагал, кадрами, собирающимися в суперкадр) положение других игроков и монстров. На клиенте экстраполируете положение их в моменты времени, точная информация о которых в текущий момент не доступна (почти наверное, траектории движения монстров известна заранее, после синхронизации вообще можно не передавать о них информацию, пока их передвижение кто-то не прервет). Напишите статью о своих результатах, небольшой своеобразный отчет, где в графиках и числах видны проблемы, и тогда спрашивайте у сообщества, что с этим стоит делать.
Padaboo
02.04.2016 19:07-11Статья псевдокод, что бы просто передать мысль в целом — на объективность не покушаюсь. Любые советы ценны.
Первое что будет сделано это p2p udp чат, для эмитации пересылки сообщений. Про бородатых дядек забудьте — это бабкины сказки, в linux/unix есть комьюнити которое все коллективно пишет и обсуждает.
java jmonkey engine, они предлагают использовать spidermonkey.
Сложно/невозможно тоже забудь: поток, сокет, очереди немножко алгоритмов и сообщение.mwizard
02.04.2016 19:27+10Про бородатых дядек забудьте — это бабкины сказки
Как же ты бесишь!
В посте демонстрируются полнейшее дилетантство, полное непонимание базовых принципов дизайна распределенных приложений, зато присутствуют невообразимый гонор, ничем не подкрепленная самоуверенность и хамство по отношению к немногочисленным доброжелателям.
Да, у меня preepeclaw.
kahi4
02.04.2016 20:03+1Под бородатыми дядями я, в первую очередь, подразумеваю Серфа Винтона и Боба Кана (второй, впрочем, без бороды). И смысл в том, что они работают над вычислительными сетями уже 50 лет, может больше, каждый имеет докторскую степень в этой области и более 5 различных очень почетных наград. Помимо них в том же сообществе linux/unix есть еще много предостойнейших людей с докторскими степенями, посвятивших свои жизни сетевым технологиям. Вероятность того, что вы (вот прям со всей силы сопротивляюсь тому, чтобы вешать ярлыки, но вот чую нутром, что у вас то и высшего пока еще нет, хоть можно возразить "это не показатель") придумаете что-то более совершенное стремится к нулю (особенно после предложения использовать сервер в p2p приложении). Да я даже больше скажу — все дружно всем хабром вместе вряд ли сильно прорвемся вперед и придумаем что-то более эффективное (и что не будет являться уже придуманным, но имеющим проблемы с внедрением).
Есть комьюнити которое все коллективно пишет и обсуждает.
Только решения в нем принимают не все. И не все решает это комьюнити. И чтобы там быть услышанным — нужно хоть что-то показать.
Wilk
03.04.2016 04:57+2Здравствуйте.
Большое Вам спасибо за комментарии к данному произведению искусства.
Saffron
02.04.2016 19:22Вот самое интересное — как обеспечить безопасность игры, чтобы злонамеренный клиент её не попортил. В принципе, если игра не соревновательная и не про продажу вещей, которые можно нарисовать забесплатно на стороне клиента, то можно дать клиенту больше власти.
А если безопасность нужна — то как устроить p2p? Если вы сделаете чистый клиент-сервер, да ещё не перекладывая сервеную функциональность на клиента, то серверу будет сложно обработать полный поток, и вообще я таких реализаций не видал. Во всех встреченных играх были мапхаки — клиент-софт в памяти держит то, что клиент-человек видеть не должен. Но человек всегда может вытащить это из памяти или проанализировав трафик.
Ладно, допустим нам нечего скрывать, у нас игра с полной информацией. И мы хотим p2p, но тогда нужно не только полную информацию перенести на клиент, но и игромеханические расчёты. Теоретически, есть соответствующие криптографические алгоритмы, но я не специалист. А всегда хотел узнать.
Так что давайте мы сначала решим более простую задачу: p2p все ко всем с полной информацией и пошаговая игра (чтобы не упереться в производительность), где клиенты могут друг другу не доверять. А потом уже делать более сложные вещи вроде федерации (где уже нет каждый к каждому, а есть голосование клиентов) и риалтайма.
Так что если у кого есть ссылки на необходимые алгоритмы, а ещё лучше библиотеки, поделитесь. Я давно мечтал сделать безопасный дайсомёт, который не требует доверия одной из сторон.Padaboo
02.04.2016 19:25-2На каждом клиенте будет что то вроде гварда+шифрование и имитация сервера в критических местах:
Взломать зафлудить и распарсить можно что угодно.
Вопрос сколько времени и трудозатрат это займет и нужно ли вообще. Библиотек пока нет нарабатываем идею — сделаю выложу в свой гитхаб и на тестах распиарю.
rPman
02.04.2016 19:29Для справки, все (или большая часть) ММРПГ игр топ класса не проверяет на лету клиента, много делает на его стороне (например движения) и поэтому под них существуют такие вещи как спидхак… грубо говоря вы можете подредактировать файлы клиента и нарисовать мост над пропастью… и воспользоваться без проблем им в игре.
Saffron
02.04.2016 19:59Я знаю. Но вот дайсомёт можно сделать безопасный. Взять один из тех головоломных алгоритмов для тайного голосования с верификацией. А потом вокруг этого надёжного источника рандома и прочую верифицируемую игромеханику.
Gaikotsu
02.04.2016 23:38Ну не все, вон ниже уже пример с линейкой написали и это именно так и есть — все что присылает клиент проверяется и перепроверяется не один раз.
И по сути как раз все или почти все уязвимости в ней как раз и вызваны недостаточной тщательностью проверок в полученных от клиента данных.
И этим не только эмули грешат, но и офф сервера. Вон та же банальная уязвимость с возможностью тягать с сервера файлы размером до 8кб (ща вроде даже уже до 16кб) через запросы хтмл-диалогов. Притом о ней вроде все уже знают и работает она с самых первых хроник. Но фиг знает по какой причине, но нцсофт это так и не починит.
Вообще, самым первым правилом при разработке любой онлайновой вещи (игры или сервиса какого, не столкь важно) всегда должно быть простое правило — никогда не доверяй данным от клиента.
А то будет вон как с тем же Archeage, с хорошо нашумевшим в свое время багом на скиллы в нем. Я просто хз как так можно было писать ммо топ класса, чтобы не делать простейших проверок на то, что у игрока есть запрашиваемый им скилл. В итоге, в результате отсутствия этих проверок игроки могли использовать вобще какие угодно скиллы — к примеру массовые скиллы боссов, убивающих все и вся с одного каста.rPman
02.04.2016 23:59-1Всему виной unreal engine, он изначально дизайнился для игр single player based, практически все топовые игры основаны на нем.
Т.е. разработчики пишут игру как бы сингл, а затем что получается успеть допилить, синхронизируют с сервером,…
Никаких разговоров о том, чтобы на сервере повторять всю игровую механику, что так долго реализовывали на клиенте и речи нет.
А чтобы совсем убить — пипл хавает и не такое, для того, чтобы усложнить жизнь умникам — делаются геймгварды — пытающиеся отследить основные способы внедрения и модификации данных и кода (кстати каждый локализатор вынужден делать это самостоятельно, интересно почему), таким образом позволяет закрыть глаза на очень маленькое количество читеров.
Padaboo
02.04.2016 19:34Ну двумерном массиве который будет представлять из себя абстракцию карты кроме игроков и монстров буду стоять, непроходимости, телепорты туда можно запихать спецефические вещи.
Цитирую совет Погугли «гексагональная сетка» и «гексагональная система координат»
Предлогают NIO + простой клиент сервер.
lexore
02.04.2016 23:00+5Прошу прощения, перечитал пост внимательно и увидел вопрос в конце.
Хочу знать ваше мнение по поводу данного алгоритма и концепции в целом.
Алгоритм — г**но, концпеция — г**но.
В той же самой линейке принцип прост: все делается на сервере. На клиенте только визуализация того, что пришлет сервер. Клиент без подтверждения сервера даже двинуться не может. Когда вы нажимаете на землю, чтобы передвинуть перса, он туда пойдет только после того, как сервер даст на это добро.
Если вам интересно, можете поснифать пакетики между клиентом и сервером. А если очень интересно, поставьте себе сервер линейки на яве и разбирайтесь, как там сделано. Тем более, что яву вы знаете. А вообще вам дали отличные ссылки (которые очень легко гуглятся, кстати), которых вам хватит с головой.
P.S.
Вообще сетевой стек MMORPG — это, я бы сказал, скучновато. Вот у стрелялок стек писать куда интереснее.
Но даже там все уже придумано до нас. Например, в этой статье от Valve.Saffron
02.04.2016 23:23А вот в старом добром варкрафте 3 всё делает один из клиентов. Соответственно концепция у него вполне рабочая.
kahi4
02.04.2016 23:58+2Нет, в старом варкрафте 3 было ровно так же. Разница лишь в том, что сервер был на одном из клиентов, а не централизованно у всех. И в CS (half-life в целом) было так же (разве что с примесями интерполяции, что хорошо заметно на переодических телепортах игроков при плохом соединении). Вот только в этом случае, если владелец сервера захочет использовать читы — ему никто не сможет помешать. Осторожно предполагаю, что в quaqe 3 было так же.
Saffron
03.04.2016 00:44+1Конечно не смогут помешать читить. Но смогут обнаружить. Варкрафт третий работает с полностью открытой информацией. Каждый клиент повторяет все игромеханические вычисления. При обнаружении расхождений с другим игроком, а они случатся, если он читит игромеханически, просто прервётся игра. Но при этом раз информация полная, значит доступен мапхак, причём для всех игроков.
Padaboo
03.04.2016 03:39-5Are you coding a game or a nuclear launcher?
The idea is very simple: if i play football with someone and this guy just use his hands or drugs, i will not play with him anymore.
The root of cheats (and flame, and toxic community) is that you are trying to be a boss, a chief, who decides who is playing with who. You have kind of the same problem you have with big society, with thief and tax evasion etc.
You can see it the other way around and think of this simple principle that should always be used by open source community: i, owner of my computer, decides what my computer will do.
If i go in a dungeon with a lot of monster and it pisses my off then i should be able to tell to my computer «delete them, i don't want that».
You can go further: you play with a friends (in the same bus, neighbourhood ect. it's what i tried to achieve in a previous game engine) and you go in a cave. Then, you friend decides that there is a lot of monster spitting nukes and throwing lasers with their eyes etc.
If you agree with that, well, it's ok, you can play with him. If you don't want it, ask him to don't do that. If he still wants to do that, then you can either let him fight them alone (and you'll not see them, nor take damage from them) or you just stop play with that guy.
You probably have this picture from terminator 2 with the 2 boys saying «i shot you first», «no i did it first» «no, me» (in french it's like that). There is not perfect solution to that. The server approach means that an adult will sit on a rock and arbiter everything.
But i am not a kid. No one is gonna tell me who is right and who is wrong just as if i was a kid. I am old enough to decide if i want to play with someone or not.
Note that it's also the best way to avoid trolls, haters, trashtalkers etc. How do you avoid them irl? How do you avoid them on skype?
You can avoid them because nobody but you decides who is your friend and who is not.
The server vs p2p is an opposition much deeper than it looks like. It's political, it's boss/employees or, the opposite, people working together because they want it, like in open source. It's internet vs minitel (https://en.wikipedia.org/wiki/Minitel i don't know equivalent things in other countries), it's microsoft/apple vs linux, imperialism vs anarchism, transcendence vs immanence…
I am learning, reading, listening conferences, thinking etc on that for years. I could do a thesis on it.
Are you in open source because you don't have enough money/influence to make proprietary things or are you on open source because you want it?
https://hub.jmonkeyengine.org/t/server-architecture-not-for-fun/35520/35
Padaboo
03.04.2016 04:54-5lineage 2 protocol: http://www.la2kings.ru/la2bot/packets.html
NIO: http://tutorials.jenkov.com/java-nio/overview.html and simple client server
Source Multiplayer Networking: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
protobuf: https://github.com/google/protobuf
гексогональная система координат
abstractbug
04.04.2016 10:55+1К чему данная статья, которая на самом деле вопрос человека решившего «неделю» назад создать свою mmo, на хабре? Может стоило задать вопрос на тостере?
По моему, Вы просто не правильно выбрали ресурс.Padaboo
04.04.2016 11:06-2На структуризацию и сохранение данных больше похоже.
Решил написать больше 5-7 лет назад, пришлось освоить все что можно и нельзя. Только только подхожу к началу работы.
Padaboo
05.04.2016 08:14-3Есть идея реализовать все алгоритмы.
Выбрать какой то один распространненный язык программирования.
И реализовать алгоритм + описание сложить в одном месте.
Незнаю пока как это сделать. Сообществом или скинуться деньгами и заказать. Потом сделать хаб.
mwizard
Padaboo
Обсуждение статьи идеи
likerRr
Перед обсуждением было бы неплохо должным образом оформить статью. Количество орфографических и пунктуационных ошибок просто зашкаливает и вызывает отвращение уже на первом абзаце.
Padaboo
http://s8.hostingkartinok.com/uploads/images/2016/04/cfe09a6d7b332093d6c59569a2a7f48a.gif