Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 85
Хочу знать ваше мнение по поводу данного алгоритма и концепции в целом.Что это за срань?
Если я правильно понял, то, во-первых, у вас тут вопрос, а не статья, а с вопросами люди ходят в гугл или "тостер", во-вторых, у вас тут не вопрос, а поток сознания, который вообще невозможно разобрать.
Прежде чем статья попала в гугл ее кто то вероятно написал и обсудил. Думаю в гугле есть не все.
Архитектура онлайн игр (точнее, рекомендации по ее реализации) в гугле уж точно найти можно. Да даже на хабре.
Не в обиду, но вы уверены, что у вас в данный момент хватит компетенции, чтобы реализовать вами запланированное? Может стоит пока не лезть в p2p, остановиться на классической реализации клиент-сервер, а дома для разминки попробовать реализовать p2p чат, и только потом уже думать об каких-то усложнениях архитектуры?
Не в обиду, но вы уверены, что у вас в данный момент хватит компетенции, чтобы реализовать вами запланированное? Может стоит пока не лезть в p2p, остановиться на классической реализации клиент-сервер, а дома для разминки попробовать реализовать p2p чат, и только потом уже думать об каких-то усложнениях архитектуры?
Я покопался в интернете на эту тему, https://github.com/Padaboo/javasamples/wiki
Простой клиент сервер не решает проблем в топике, есть идеи?
Простой клиент сервер не решает проблем в топике, есть идеи?
Хорошая статья на хабре, первая ссылка гугла, вторая ссылка гугла.
Окей, по проблемам, обозначенным вами (это не те проблемы, с которыми вы столкнетесь, а лишь ваши гипотезы, нужно заметить, т.е. вы решаете проблемы, которые предполагаете, а не на которые наталкиваетесь).
1) "Синхронизация игроков" — в общем то это задача, а не проблема. Интерполяция, экстрополяция и прочие методики. Вы не описали жанр, если это действительно типа line age (ММОРПГ), тут гораздо меньше подводных камней и боли, чем в шутерах (была как-то статья о том, сколько геммороя пришлось решать при разработке последнего battlefield. Вот там с интерполяциями большие трудности)
2) "Клиент серверная синхронизация" — см. пункт 1.
3) "Низкая скорость передачи tcp/upd, низка скорость передачи clien-server" — либо не ориентируйтесь на игроков с каналом 256 кб, либо минимизируйте необходимую для передачи информацию, уменьшайте количество пакетов (для ММОРПГ совершенно не обязательно 60 раз в секунду передавать полную информацию). Посмотрите на алгоритмы, применяемые в других сферах, например, ГНСС. Используйте понятие супер-кадра, состоящего из нескольких кадров. В кадре только совсем оперативная информация (какие действия совершают другие игроки), а так же часть изменений мира (причем именно изменений, а не все состояние мира каждый раз). Пусть супер-кадр состоит из 10 кадров, кадр пересылается 20 раз в секунду, тогда за секунду у вас дважды будет полная информация об изменившемся мире, и 20 раз в секунду оперативная информация. (Более точные решения давать сложно, ничего не зная о механике игры).
5) "Обо всех пакетах должен знать только сервер", — а в чем проблема то?
6) "Игроки находятся на разном расстоянии географически" – что снижает скорость передачи — ставьте сервера в разных географических регионах.
7) "Необходимо посылать пакеты только соседним объектам" — что?
8) "Пакеты могут потеряться, пакеты можно подменить" — ни первое, ни второе — не ваша проблема. Точнее так: в UDP пакеты могут теряться, это нужно учитывать, но если вы поверх UDP залепите гарантированную доставку пакетов — сразу выбирайте TCP. Иначе необходимо делать саму механику игры такой, чтобы пропуск пакета не был критичным (например, положение монстра в прошлый момент времени можно интерполировать), а критичные вещи дублируйте (с приписанием некого ID) по кадрам. Что касается подмены — сервер должен проверять валидность действия, а то, что клиенту может прийти подмененный пакет — с этим вы не многое сможете сделать (опять же, тогда клиент ответит невалидным пакетом, на что резонно его отключить с соответствующим сообщением).
Нет, я все же настоятельно рекомендую почитать несколько статей, еще лучше книг, набить руку на проектах по-проще и по-легче.
Стоп, вы под «объектом» подразумеваете клиент игрока? Чего? «Решение на уровне сети и сервер:» противоречат моей догадке о том, что вы подразумеваете под объектом. Но зачем тогда внутри сервера игровые объекты обмениваются информацией?
Вообще удручает: это не тостер, а хабр. Тут все делятся своими решениями проблем, а не спрашивают, как их решить (с вроде 2012 года или когда там тостер запустили). Ну ладно, если бы только это. Но на самом деле, есть еще несколько проблем:
— вы пытаетесь сделать то, что вам не под силу (уж простите, возможно вы просто не спали неделю, обдумывали архитектуру, поэтому у вас получилось сомнительное описание)
— вы не предоставили никакой информации ни о механике, ни о ожидаемых нагрузках, ни о посещаемости, ни о ресурсах
— вы решаете не те проблемы, которые возникают
— своими решениями порождаете еще большие проблемы
Помимо совета начать с чего-то попроще, а так же почитать умных книжек, советую спрятать топик в черновики и сделать прототип (или альфа-версию) с совсем топорным решением (обычная клиент-серверная архитектура) и посмотреть, какие проблемы действительно возникнут.
Окей, по проблемам, обозначенным вами (это не те проблемы, с которыми вы столкнетесь, а лишь ваши гипотезы, нужно заметить, т.е. вы решаете проблемы, которые предполагаете, а не на которые наталкиваетесь).
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 года или когда там тостер запустили). Ну ладно, если бы только это. Но на самом деле, есть еще несколько проблем:
— вы пытаетесь сделать то, что вам не под силу (уж простите, возможно вы просто не спали неделю, обдумывали архитектуру, поэтому у вас получилось сомнительное описание)
— вы не предоставили никакой информации ни о механике, ни о ожидаемых нагрузках, ни о посещаемости, ни о ресурсах
— вы решаете не те проблемы, которые возникают
— своими решениями порождаете еще большие проблемы
Помимо совета начать с чего-то попроще, а так же почитать умных книжек, советую спрятать топик в черновики и сделать прототип (или альфа-версию) с совсем топорным решением (обычная клиент-серверная архитектура) и посмотреть, какие проблемы действительно возникнут.
Да автору стоило бы взять к примеру те же исходники любого эмулятора ла2 и поизучать их — как все что он пишет реализовано "по уму". Благо исходники эмуляторов линейки в интернете найти можно на любой вкус, почти все варианты веток развития — l2jserver, phoenix/overworld и т.д. и т.п.
Тогда скорее всего этого потока сознания вообще не появилось бы.
Тогда скорее всего этого потока сознания вообще не появилось бы.
В основе лежит идея, просто есть ряд проблем их можно обсудить и придумать решение. Несколько движков с чужим кодом до старости крутить можно. Пример:
Я написал некое p2p приложение в нем есть: клиент написаный на C++, сервер написанный на Java, а внутри вставки из С/Python+asm, код подвергся обфускации и документации нет.
Я написал некое p2p приложение в нем есть: клиент написаный на C++, сервер написанный на Java, а внутри вставки из С/Python+asm, код подвергся обфускации и документации нет.
p2p приложение в нем есть: клиент написаный на C++, сервер написанный на Java
Какое емкое противоречивое само себе утверждение.
Человек проводит оптимизацию и вставляет низкоуровневый код? что в этом противоречивого?
Для начала потрудитесь загуглить аббревиатуру p2p
потрудитесь почитать тему
Как у p2p-приложения могут быть "клиент" и "сервер"?
Как только вы определитель с тем, что же вы все-таки написали и напишете статью, а не этот высер, как сказали в первом комментарии.
jni include c++
https://yadi.sk/d/bsH42fNvqkYp8
https://yadi.sk/d/bsH42fNvqkYp8
Спасибо, дело в том что если игровой мир меняется минимум 1 раз в секунду то — придется отправлять обновление всего мира каждому игроку т.е. отправлять всю базу данных кажому игроку.
И один игрок в Америке, второй в России, третий Англии отсюда собственно и тема.
И один игрок в Америке, второй в России, третий Англии отсюда собственно и тема.
Так поставьте сервера в Америке, России и Англии, дальше вопрос репликации. Игровой мир меняется гораздо чаще, все раз в секунде. Нужно выделить константные/медленно изменяющиеся объекты, либо объекты, требующие синхронизации только раз (при загрузке). А дальше — бить на небольшие участки, сохраняя баланс между видимостью и размером пакета.
"Посчитать расстояние между всеми объектами" — вы будете считать его до умопомрачения, если объектов много. Есть достаточно хорошие алгоритмы поиска объектов, которые в данный момент могут интересовать игрока. И они никак не связаны с клиент-серверной архитектурой.
"Посчитать расстояние между всеми объектами" — вы будете считать его до умопомрачения, если объектов много. Есть достаточно хорошие алгоритмы поиска объектов, которые в данный момент могут интересовать игрока. И они никак не связаны с клиент-серверной архитектурой.
Теория графов кратчайшие расстояние
Еле сдерживаюсь от того, чтобы прибегнуть к художественно-выразительному приему, при котором первая часть слова заменяется на нецензурное, предназначенное для акцентирования несостоятельности.
Что вы так заладили с теорией графов? Во-первых, вы ищете расстояние на географической (пусть и виртуальной карте), т.е. в эвклидовом (да хоть в лобачевском) пространстве, никто не ищет расстояние (не путать с кратчайшим путем) в нем теорией графов. Более того, оно строго задано как квадратный корень из суммы разностей координат. Даже, если вдаваться в матан, расстояние бывает разным (я привел декартово), как бы парадоксально не звучало. Например, манхетаннское. Обычно нужно обосновывать его состоятельность, но и у вас не рокет сайнс, как говорится.
Так вот. Даже если брать его, все равно — найти расстояние между всеми объектами в игровом мире — задача не простая (квадратичная сложность), для чего используются различные уловки (и нет, не теории графов. Не в прямом виде, по крайней мере). Если вы хотите, чтобы вам тут их рассказали — справедливо получите вежлевую просьбу сходить в гугл. И опять же, это не имеет никакого отношения к клиент-серверу. Да и вообще, в своем движке вы уже должны были решить эту задачу (например, если на слэнге вы "кидаете массуху", должны определить, каких "мобов" она должна поразить).
Во-вторых, теория графов достаточно большая и расплывчатая наука. Матрица тоже является графом (а еще тензером, но теория тензорных исчислений не достаточно хипстерская, что ее лепить куда непоподя). Так что поиск эвклидова расстояния в теории графов тоже почти наверное как-то описывается.
Что вы так заладили с теорией графов? Во-первых, вы ищете расстояние на географической (пусть и виртуальной карте), т.е. в эвклидовом (да хоть в лобачевском) пространстве, никто не ищет расстояние (не путать с кратчайшим путем) в нем теорией графов. Более того, оно строго задано как квадратный корень из суммы разностей координат. Даже, если вдаваться в матан, расстояние бывает разным (я привел декартово), как бы парадоксально не звучало. Например, манхетаннское. Обычно нужно обосновывать его состоятельность, но и у вас не рокет сайнс, как говорится.
Так вот. Даже если брать его, все равно — найти расстояние между всеми объектами в игровом мире — задача не простая (квадратичная сложность), для чего используются различные уловки (и нет, не теории графов. Не в прямом виде, по крайней мере). Если вы хотите, чтобы вам тут их рассказали — справедливо получите вежлевую просьбу сходить в гугл. И опять же, это не имеет никакого отношения к клиент-серверу. Да и вообще, в своем движке вы уже должны были решить эту задачу (например, если на слэнге вы "кидаете массуху", должны определить, каких "мобов" она должна поразить).
Во-вторых, теория графов достаточно большая и расплывчатая наука. Матрица тоже является графом (а еще тензером, но теория тензорных исчислений не достаточно хипстерская, что ее лепить куда непоподя). Так что поиск эвклидова расстояния в теории графов тоже почти наверное как-то описывается.
Не очень большая эта теория, советую «дискретная математика для программиста»
Теория конечных автоматов не очень большая (к слову, технически ее можно считать подмножеством теории графов), но что-то в книге только по ее основам 600 страниц. Да и имел ввиду я то, что в теорию графов можно вписать много чего. По своей сути — граф — это лишь способ представления данных. Барицентрическая система координат так же может быть представлена в виде графа, да даже декартова. Это не означает, что все нужно все задачи решать исключительно в рамках теории графов. Особенно поиск расстояния.
P.S. Я, в общем то, инженер, поэтому в состоянии осилить книги "для инженеров". Уж простите, но о большинстве книг "чего-то там для программистов" у меня сложилось плохое впечатление, так что в 99% случаев это ассоциируется с "для чайников". Исключения бывают, но даже в достойных книгах все ужасно урезано, упрощено и оставляет только кучу вопросов после себя, что потом все равно лезешь в книгу для ВУЗов.
P.S. Я, в общем то, инженер, поэтому в состоянии осилить книги "для инженеров". Уж простите, но о большинстве книг "чего-то там для программистов" у меня сложилось плохое впечатление, так что в 99% случаев это ассоциируется с "для чайников". Исключения бывают, но даже в достойных книгах все ужасно урезано, упрощено и оставляет только кучу вопросов после себя, что потом все равно лезешь в книгу для ВУЗов.
Стена голова удар
Да массив будет огромным- вся бза данных, одно большое сообщение со всеми объектами, поэтому сообщениями будут обмениваться только ближай друг к другу объекты и сервер.
Незнаю будет он рад нет своей роли но кто то должен это делать, какой то из клиентов с быстрой скоростью или сервер.
Если афк то да, а если вы бежите по локации с зажатой клавишой W?
Незнаю будет он рад нет своей роли но кто то должен это делать, какой то из клиентов с быстрой скоростью или сервер.
Если афк то да, а если вы бежите по локации с зажатой клавишой W?
Боюсь массив со всем игровым миром и всеми объектами будет огромным… Нужно как минимум разбить на локации, но локации не должны касаться видимости в клиенте, чтобы игрок не исчезал с экрана переступая невидимую черту. Либо делать так, чтобы локации накладывались друг на друга и находясь на пересечении игрок мог получать пакеты с обеих локаций (правда чревато подлагиваниями на границе локаций)
В той же линейке кстати примерно так и сделано — весь игровой мир разбит на регионы определенного размера, и для каждого региона ведется обновляемый список-массив объектов в нем (игроков, неписей, предметов на земле). когда к примеру игрок заходит в регион, то ему присылаются пакеты с информацией обо всех объектах в этом регионе, а так же в соседних регионах, ну а игрокам уже находящимся в этом регионе и прилегающих — присылается информация, что рядом новый игрок. в принципе таким же образом броадкастится и много другой информации (каст скиллов, появление на земле дропа и его подбор и т.д.) — всем игрокам текущего региона и соседних.
Кстати как раз из-за этого в линейке есть возможность делать очень нехорошую пакость с игроками в определенной локации — злоумышленник может накидать скажем несколько десятков тысяч стрел отдельными кучками и любой игрок, пришедший/телепортировавшися в эту локацию банально подвисает, т.к. клиент просто офигевает от такого количества одномоментно прилетевших пакетов и необходимости все это отрисовать.
Для начала, почитайте вот это http://fursoffers.narod.ru/Packets.htm
Ещё там не упомянута geodata — у lineage на неё тоже много завязано.
В играх типа линейки "видимость моба/игрока" — фикция.
Ещё там не упомянута geodata — у lineage на неё тоже много завязано.
В играх типа линейки "видимость моба/игрока" — фикция.
шутка про корованы
Первое апреля уже кончилось, если что.
Если готовы как следует заморочиться, получить минимальную (при локально ограниченных перемещениях — это 99% времени игрока) нагрузку на сеть за счет незначительного повышения нагрузки на машины игроков (и p2p можно будет позже вписать для еще большей разгрузки сетевых каналов сервера, к тому же сами сервера на столько близки по логике с клиентами что так же красиво раскидываются по географическому положению):
p.s. алгоритм на самом деле очень сложный, но эта технология идеальна для сложных миров (динамично изменяющиеся от действий игрока, например разрушаемое или изменяемое окружение) с большим количеством игроков и логикой, максимально реализуемой на стороне клиента (помним, если переборщить, то боты автоматизации будет очень просто написать)
- клиенты передают на сервер только действия пользователя (вплоть до на низком уровне — нажатия кнопок на мышке и клавиатуре но лучше конечно определить события, которые что то меняют в мире)
- Каждый клиент хранит информацию обо всех объектах в своем окружении и самое главное, обо всех объектах, которые необходимы для проведения вычислений 'следующего состояния' объектов, которые могут его менять
2.а. при перемещении игрока ему с сервера передается информация обо всех новых объектах, попадающих в эту область видимости (для оптимизации рекомендуется область загрузки объектов слегка расширить, и слать необходимую информацию заранее но фоном, например расставляя приоритеты для данных по направлению движения)
2.б. таким образом. все клиенты получают события ото всех игроков в своем окружении (игроки в данном случае как те же объекты мира но действие которых нельзя вычислить, хотя можно всегда найти ситуации где и тут можно соптимизировать, например если игрок сидит на машине, управляемой алгоритмом — значит координаты можно не слать) - каждый клиент вычисляет следующее состояние на основании хранящихся у него данных, выполняя фактически всю ту же работу что и сервер но только в локальном окружении игрока
3.а. всегда можно часть критичной логики завернуть на серверную сторону, например генерация лута - ввести лог событий и состояний всех объектов для возможности отката их назад с проигрыванием входящих событий, в случае, когда часть из них несинхронизирована по времени (например игрок отреагировал на действие другого игрока но это событие опоздало, соответственно откатываем действия назад и проигрываем с новым логом состояний (на самом деле алгоритм не тривиальный, возможны вариации на тему накопления событий в течении интервала времени или по отмашке серверного тикера, это если реализовывать p2p рассылку событий от игроков)
- Подойти к выбору протокола tcp/udp с особой тщательностью, какие проблемы хотим — лаги или глюки (игроков будет колбасить, команды теряться и еще разнообразные артефакты), так же возможна комбинация протоколов для разного типа трафика.
но технология подразумевает возможность корректной работы при потери данных (откатываем состояние, и перестраиваем с новыми данными), а значит udp само напрашивается. - защита от злонамеренной рассинхронизации данных клиент-сервер (когда клиент рисует свое состояние объектов, несовместимое с сервером, с попыткой считерить) встроена в идеологию — пользователь ничего не может изменить в алгоритме, потому как сервер и клиенты всеравно будут видеть верную картину, а не ту что читер себе нарисовал.
6.а. но этот алгоритм слабо защищен от ботов автоматизации действий на стороне клиента — информации много, серверные алгоритмы и логика — на виду, некоторые игры, с обманом игроков будет сложно реализовать (типа вот ваши статы с коэффициентами, вы думаете что формула dps — простое умножение а она трехэтажная с интегралами)
p.s. алгоритм на самом деле очень сложный, но эта технология идеальна для сложных миров (динамично изменяющиеся от действий игрока, например разрушаемое или изменяемое окружение) с большим количеством игроков и логикой, максимально реализуемой на стороне клиента (помним, если переборщить, то боты автоматизации будет очень просто написать)
В общем объект(клиент/сервер) просто посылает сообщения серверу и другим игрока.
Вопрос в том как это оптимизировать: 1) ускорить передачу 2) отсечь ненужную информацию 3) правильно синхронизировать
Спасибо интересно. Добавлю к описанию алгоритма — есть над чем подумать.
Самое сложное сформулировать — а захардкодить уже не так сложно.
Вопрос в том как это оптимизировать: 1) ускорить передачу 2) отсечь ненужную информацию 3) правильно синхронизировать
Спасибо интересно. Добавлю к описанию алгоритма — есть над чем подумать.
Самое сложное сформулировать — а захардкодить уже не так сложно.
Все алгоритмы в конечном счете отличаются в том что именно рассылает сервер клиентам — в описанном мною возможна ситуация, когда сервер долгое время шлет клиентам ТОЛЬКО нажимаемые кнопки или уже как бонус — возможность слать это сразу между клиентами (но на сервер конечно придется слать всеравно).
Вы представляете на сколько это оптимальнее чем слать изменения состояния окружения, особенно когда вы решить сделать его изменяемым (собственно по этой причине ММРПГ это не делают, так как тупо шлют все всем с квадратичным ростом трафика при массовках)
Вы представляете на сколько это оптимальнее чем слать изменения состояния окружения, особенно когда вы решить сделать его изменяемым (собственно по этой причине ММРПГ это не делают, так как тупо шлют все всем с квадратичным ростом трафика при массовках)
Все, хватит. Вам дают советы, вы отпираетесь. Зачем тогда спрашивать, если все равно не слушаете?
По порядку. Вы действительно считаете, что пробрасывание пакетов через другие машины будет быстрее, чем прямое обращение к серверу? Не хочу вас расстраивать, так что пусть вас расстроит физика. А поиск быстрейшего пути пакета (замечу, что он далеко не всегда самый короткий) вообще задача стека TCP/IP (UDP/IP). Думаете, вы сможете решить эту задачу эффективнее, чем 30 лет опыта нескольких сотен бородатых мужиков? К слову, ищется он без какой-либо теории графов, надеюсь, более подробную об этом информацию вы в состоянии найти самостоятельно.
Хорошо, допустим, вы хотите, чтобы определенные клиенты брали на себя функции сервера. Даже не хочу начинать перечислять возникающие проблемы. Например, что если владелец этого клиента — недобросовестный? Если через него будут играть много игроков и все в разных локациях, уверены, что клиент потянет эту производительность? Вы хоть представляете, какие проблемы возникают при реализации репликации? Или это переложите на плечи, допустим, mongo? Если да, то почему сразу так не сделать? И опять же, и что дальше?
Теперь о том, как это все же нужно делать:
По порядку. Вы действительно считаете, что пробрасывание пакетов через другие машины будет быстрее, чем прямое обращение к серверу? Не хочу вас расстраивать, так что пусть вас расстроит физика. А поиск быстрейшего пути пакета (замечу, что он далеко не всегда самый короткий) вообще задача стека TCP/IP (UDP/IP). Думаете, вы сможете решить эту задачу эффективнее, чем 30 лет опыта нескольких сотен бородатых мужиков? К слову, ищется он без какой-либо теории графов, надеюсь, более подробную об этом информацию вы в состоянии найти самостоятельно.
Хорошо, допустим, вы хотите, чтобы определенные клиенты брали на себя функции сервера. Даже не хочу начинать перечислять возникающие проблемы. Например, что если владелец этого клиента — недобросовестный? Если через него будут играть много игроков и все в разных локациях, уверены, что клиент потянет эту производительность? Вы хоть представляете, какие проблемы возникают при реализации репликации? Или это переложите на плечи, допустим, mongo? Если да, то почему сразу так не сделать? И опять же, и что дальше?
- Как вы будете определять геопозицию игроков? А если они не захотят предоставлять информацию?
- "visible_radius" на какой черт это передавать каждый раз? Это вообще константа, на которой завязана далеко не графика (у графики свой радиус видимости).
- rotate,radius поворот не так задается
- message[string,chat], зачем это пересылать каждый раз? Почему не сделать для этого отдельный канал?
- gruops[clan,party], мегаважная информация, действительно достойная пересылки в каждом сообщении (пакете), ага.
- "игрок монстры и сервер выполняя действия формируют сообщения или пакеты" С чего вдруг монстры формируют сообщения? Не нужно смешивать все в одну кучу.
Теперь о том, как это все же нужно делать:
- Если вы замахиваетесь на клиентов со всех точек мира — размещайте свои сервера в разных регионах. Репликации между своими серверами делаются гораздо проще, чем между неподвласными вам машинами. А еще лучше — замахнитесь только на какой-то региональный рынок. Окупится, будут деньги — наймите специалиста, хорошо в этом разбирающегося и со стажем 5+ лет, да и у самого появятся идеи к этому времени.
- Сделайте рабочий прототип. Профилируйте слабые места, определяйте, что создает трудности, откуда берутся задержки, с чем возникают проблемы. У меня складывается впечатление, что вы сейчас находитесь на стадии "хм, а давай ка я запилю ММОРПГ. О, так там же нужно будет решать эти проблемы. И как их решать?". Судите сами — вы задаете вопрос, напрямую касающийся способа организации хранения данных (пусть и под предлогом их пересылки), организации мира и всего такого. Это означает, что вы еще их не решили, что, в свою очередь, указывает на то, что максимум, что у вас есть — бегающий персонаж в unity по равнинным просторам.
- Скорее всего, вы используете какой-то движок (unity, UE, cryengine), у которого из коробки уже есть нужный функционал, которому вам хватит с головой. Когда начнете упираться в этот функционал — хватит денег нанять 5 специалистов, поверьте.
- Ближе к коду и архитектуре: разбиваете весь игровой мир на регионы. Регионы бьете на субрегионы, достаточно маленькие. Статически (это очень важно, так как просчитывается только раз, при генерации мира) рассчитываете области видимости и взаимодейтсвия субрегионов, исходя из чего в дальнейшем будете определять, что вам нужно пересчитывать и пересылать. Когда клиент заходит на сервер — определять, в каком регионе и субрегионе он сейчас находится, и пересылаете ему всю информацию о текущем субрегионе (а так же те, которые он может видеть/взаимодейтсвовать с которыми). В дальнейшем пересылаете только изменения в этом мире (лежащие на полу предметы, например, пересылать второй раз нет смысла). Передаете (и не очень часто, например, как я предлагал, кадрами, собирающимися в суперкадр) положение других игроков и монстров. На клиенте экстраполируете положение их в моменты времени, точная информация о которых в текущий момент не доступна (почти наверное, траектории движения монстров известна заранее, после синхронизации вообще можно не передавать о них информацию, пока их передвижение кто-то не прервет). Напишите статью о своих результатах, небольшой своеобразный отчет, где в графиках и числах видны проблемы, и тогда спрашивайте у сообщества, что с этим стоит делать.
Статья псевдокод, что бы просто передать мысль в целом — на объективность не покушаюсь. Любые советы ценны.
Первое что будет сделано это p2p udp чат, для эмитации пересылки сообщений. Про бородатых дядек забудьте — это бабкины сказки, в linux/unix есть комьюнити которое все коллективно пишет и обсуждает.
java jmonkey engine, они предлагают использовать spidermonkey.
Сложно/невозможно тоже забудь: поток, сокет, очереди немножко алгоритмов и сообщение.
Первое что будет сделано это p2p udp чат, для эмитации пересылки сообщений. Про бородатых дядек забудьте — это бабкины сказки, в linux/unix есть комьюнити которое все коллективно пишет и обсуждает.
java jmonkey engine, они предлагают использовать spidermonkey.
Сложно/невозможно тоже забудь: поток, сокет, очереди немножко алгоритмов и сообщение.
Про бородатых дядек забудьте — это бабкины сказкиКак же ты бесишь!
В посте демонстрируются полнейшее дилетантство, полное непонимание базовых принципов дизайна распределенных приложений, зато присутствуют невообразимый гонор, ничем не подкрепленная самоуверенность и хамство по отношению к немногочисленным доброжелателям.
Да, у меня preepeclaw.
Под бородатыми дядями я, в первую очередь, подразумеваю Серфа Винтона и Боба Кана (второй, впрочем, без бороды). И смысл в том, что они работают над вычислительными сетями уже 50 лет, может больше, каждый имеет докторскую степень в этой области и более 5 различных очень почетных наград. Помимо них в том же сообществе linux/unix есть еще много предостойнейших людей с докторскими степенями, посвятивших свои жизни сетевым технологиям. Вероятность того, что вы (вот прям со всей силы сопротивляюсь тому, чтобы вешать ярлыки, но вот чую нутром, что у вас то и высшего пока еще нет, хоть можно возразить "это не показатель") придумаете что-то более совершенное стремится к нулю (особенно после предложения использовать сервер в p2p приложении). Да я даже больше скажу — все дружно всем хабром вместе вряд ли сильно прорвемся вперед и придумаем что-то более эффективное (и что не будет являться уже придуманным, но имеющим проблемы с внедрением).
Только решения в нем принимают не все. И не все решает это комьюнити. И чтобы там быть услышанным — нужно хоть что-то показать.
Есть комьюнити которое все коллективно пишет и обсуждает.
Только решения в нем принимают не все. И не все решает это комьюнити. И чтобы там быть услышанным — нужно хоть что-то показать.
Здравствуйте.
Большое Вам спасибо за комментарии к данному произведению искусства.
Большое Вам спасибо за комментарии к данному произведению искусства.
Вот самое интересное — как обеспечить безопасность игры, чтобы злонамеренный клиент её не попортил. В принципе, если игра не соревновательная и не про продажу вещей, которые можно нарисовать забесплатно на стороне клиента, то можно дать клиенту больше власти.
А если безопасность нужна — то как устроить p2p? Если вы сделаете чистый клиент-сервер, да ещё не перекладывая сервеную функциональность на клиента, то серверу будет сложно обработать полный поток, и вообще я таких реализаций не видал. Во всех встреченных играх были мапхаки — клиент-софт в памяти держит то, что клиент-человек видеть не должен. Но человек всегда может вытащить это из памяти или проанализировав трафик.
Ладно, допустим нам нечего скрывать, у нас игра с полной информацией. И мы хотим p2p, но тогда нужно не только полную информацию перенести на клиент, но и игромеханические расчёты. Теоретически, есть соответствующие криптографические алгоритмы, но я не специалист. А всегда хотел узнать.
Так что давайте мы сначала решим более простую задачу: p2p все ко всем с полной информацией и пошаговая игра (чтобы не упереться в производительность), где клиенты могут друг другу не доверять. А потом уже делать более сложные вещи вроде федерации (где уже нет каждый к каждому, а есть голосование клиентов) и риалтайма.
Так что если у кого есть ссылки на необходимые алгоритмы, а ещё лучше библиотеки, поделитесь. Я давно мечтал сделать безопасный дайсомёт, который не требует доверия одной из сторон.
А если безопасность нужна — то как устроить p2p? Если вы сделаете чистый клиент-сервер, да ещё не перекладывая сервеную функциональность на клиента, то серверу будет сложно обработать полный поток, и вообще я таких реализаций не видал. Во всех встреченных играх были мапхаки — клиент-софт в памяти держит то, что клиент-человек видеть не должен. Но человек всегда может вытащить это из памяти или проанализировав трафик.
Ладно, допустим нам нечего скрывать, у нас игра с полной информацией. И мы хотим p2p, но тогда нужно не только полную информацию перенести на клиент, но и игромеханические расчёты. Теоретически, есть соответствующие криптографические алгоритмы, но я не специалист. А всегда хотел узнать.
Так что давайте мы сначала решим более простую задачу: p2p все ко всем с полной информацией и пошаговая игра (чтобы не упереться в производительность), где клиенты могут друг другу не доверять. А потом уже делать более сложные вещи вроде федерации (где уже нет каждый к каждому, а есть голосование клиентов) и риалтайма.
Так что если у кого есть ссылки на необходимые алгоритмы, а ещё лучше библиотеки, поделитесь. Я давно мечтал сделать безопасный дайсомёт, который не требует доверия одной из сторон.
На каждом клиенте будет что то вроде гварда+шифрование и имитация сервера в критических местах:
Взломать зафлудить и распарсить можно что угодно.
Вопрос сколько времени и трудозатрат это займет и нужно ли вообще. Библиотек пока нет нарабатываем идею — сделаю выложу в свой гитхаб и на тестах распиарю.
Взломать зафлудить и распарсить можно что угодно.
Вопрос сколько времени и трудозатрат это займет и нужно ли вообще. Библиотек пока нет нарабатываем идею — сделаю выложу в свой гитхаб и на тестах распиарю.
Для справки, все (или большая часть) ММРПГ игр топ класса не проверяет на лету клиента, много делает на его стороне (например движения) и поэтому под них существуют такие вещи как спидхак… грубо говоря вы можете подредактировать файлы клиента и нарисовать мост над пропастью… и воспользоваться без проблем им в игре.
Я знаю. Но вот дайсомёт можно сделать безопасный. Взять один из тех головоломных алгоритмов для тайного голосования с верификацией. А потом вокруг этого надёжного источника рандома и прочую верифицируемую игромеханику.
Ну не все, вон ниже уже пример с линейкой написали и это именно так и есть — все что присылает клиент проверяется и перепроверяется не один раз.
И по сути как раз все или почти все уязвимости в ней как раз и вызваны недостаточной тщательностью проверок в полученных от клиента данных.
И этим не только эмули грешат, но и офф сервера. Вон та же банальная уязвимость с возможностью тягать с сервера файлы размером до 8кб (ща вроде даже уже до 16кб) через запросы хтмл-диалогов. Притом о ней вроде все уже знают и работает она с самых первых хроник. Но фиг знает по какой причине, но нцсофт это так и не починит.
Вообще, самым первым правилом при разработке любой онлайновой вещи (игры или сервиса какого, не столкь важно) всегда должно быть простое правило — никогда не доверяй данным от клиента.
А то будет вон как с тем же Archeage, с хорошо нашумевшим в свое время багом на скиллы в нем. Я просто хз как так можно было писать ммо топ класса, чтобы не делать простейших проверок на то, что у игрока есть запрашиваемый им скилл. В итоге, в результате отсутствия этих проверок игроки могли использовать вобще какие угодно скиллы — к примеру массовые скиллы боссов, убивающих все и вся с одного каста.
И по сути как раз все или почти все уязвимости в ней как раз и вызваны недостаточной тщательностью проверок в полученных от клиента данных.
И этим не только эмули грешат, но и офф сервера. Вон та же банальная уязвимость с возможностью тягать с сервера файлы размером до 8кб (ща вроде даже уже до 16кб) через запросы хтмл-диалогов. Притом о ней вроде все уже знают и работает она с самых первых хроник. Но фиг знает по какой причине, но нцсофт это так и не починит.
Вообще, самым первым правилом при разработке любой онлайновой вещи (игры или сервиса какого, не столкь важно) всегда должно быть простое правило — никогда не доверяй данным от клиента.
А то будет вон как с тем же Archeage, с хорошо нашумевшим в свое время багом на скиллы в нем. Я просто хз как так можно было писать ммо топ класса, чтобы не делать простейших проверок на то, что у игрока есть запрашиваемый им скилл. В итоге, в результате отсутствия этих проверок игроки могли использовать вобще какие угодно скиллы — к примеру массовые скиллы боссов, убивающих все и вся с одного каста.
Всему виной unreal engine, он изначально дизайнился для игр single player based, практически все топовые игры основаны на нем.
Т.е. разработчики пишут игру как бы сингл, а затем что получается успеть допилить, синхронизируют с сервером,…
Никаких разговоров о том, чтобы на сервере повторять всю игровую механику, что так долго реализовывали на клиенте и речи нет.
А чтобы совсем убить — пипл хавает и не такое, для того, чтобы усложнить жизнь умникам — делаются геймгварды — пытающиеся отследить основные способы внедрения и модификации данных и кода (кстати каждый локализатор вынужден делать это самостоятельно, интересно почему), таким образом позволяет закрыть глаза на очень маленькое количество читеров.
Т.е. разработчики пишут игру как бы сингл, а затем что получается успеть допилить, синхронизируют с сервером,…
Никаких разговоров о том, чтобы на сервере повторять всю игровую механику, что так долго реализовывали на клиенте и речи нет.
А чтобы совсем убить — пипл хавает и не такое, для того, чтобы усложнить жизнь умникам — делаются геймгварды — пытающиеся отследить основные способы внедрения и модификации данных и кода (кстати каждый локализатор вынужден делать это самостоятельно, интересно почему), таким образом позволяет закрыть глаза на очень маленькое количество читеров.
Ну двумерном массиве который будет представлять из себя абстракцию карты кроме игроков и монстров буду стоять, непроходимости, телепорты туда можно запихать спецефические вещи.
Цитирую совет Погугли «гексагональная сетка» и «гексагональная система координат»
Предлогают NIO + простой клиент сервер.
Цитирую совет Погугли «гексагональная сетка» и «гексагональная система координат»
Предлогают NIO + простой клиент сервер.
Прошу прощения, перечитал пост внимательно и увидел вопрос в конце.
Алгоритм — г**но, концпеция — г**но.
В той же самой линейке принцип прост: все делается на сервере. На клиенте только визуализация того, что пришлет сервер. Клиент без подтверждения сервера даже двинуться не может. Когда вы нажимаете на землю, чтобы передвинуть перса, он туда пойдет только после того, как сервер даст на это добро.
Если вам интересно, можете поснифать пакетики между клиентом и сервером. А если очень интересно, поставьте себе сервер линейки на яве и разбирайтесь, как там сделано. Тем более, что яву вы знаете. А вообще вам дали отличные ссылки (которые очень легко гуглятся, кстати), которых вам хватит с головой.
P.S.
Вообще сетевой стек MMORPG — это, я бы сказал, скучновато. Вот у стрелялок стек писать куда интереснее.
Но даже там все уже придумано до нас. Например, в этой статье от Valve.
Хочу знать ваше мнение по поводу данного алгоритма и концепции в целом.
Алгоритм — г**но, концпеция — г**но.
В той же самой линейке принцип прост: все делается на сервере. На клиенте только визуализация того, что пришлет сервер. Клиент без подтверждения сервера даже двинуться не может. Когда вы нажимаете на землю, чтобы передвинуть перса, он туда пойдет только после того, как сервер даст на это добро.
Если вам интересно, можете поснифать пакетики между клиентом и сервером. А если очень интересно, поставьте себе сервер линейки на яве и разбирайтесь, как там сделано. Тем более, что яву вы знаете. А вообще вам дали отличные ссылки (которые очень легко гуглятся, кстати), которых вам хватит с головой.
P.S.
Вообще сетевой стек MMORPG — это, я бы сказал, скучновато. Вот у стрелялок стек писать куда интереснее.
Но даже там все уже придумано до нас. Например, в этой статье от Valve.
А вот в старом добром варкрафте 3 всё делает один из клиентов. Соответственно концепция у него вполне рабочая.
Нет, в старом варкрафте 3 было ровно так же. Разница лишь в том, что сервер был на одном из клиентов, а не централизованно у всех. И в CS (half-life в целом) было так же (разве что с примесями интерполяции, что хорошо заметно на переодических телепортах игроков при плохом соединении). Вот только в этом случае, если владелец сервера захочет использовать читы — ему никто не сможет помешать. Осторожно предполагаю, что в quaqe 3 было так же.
Конечно не смогут помешать читить. Но смогут обнаружить. Варкрафт третий работает с полностью открытой информацией. Каждый клиент повторяет все игромеханические вычисления. При обнаружении расхождений с другим игроком, а они случатся, если он читит игромеханически, просто прервётся игра. Но при этом раз информация полная, значит доступен мапхак, причём для всех игроков.
Are 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
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
lineage 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
гексогональная система координат
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
гексогональная система координат
hex grid coordinates
https://yadi.sk/d/G6MC4IuMqgzsr
https://yadi.sk/d/G6MC4IuMqgzsr
Как считаете где лучше хранить геодату игры? файл,mysql,nosql, память (загруженные классы)
К чему данная статья, которая на самом деле вопрос человека решившего «неделю» назад создать свою mmo, на хабре? Может стоило задать вопрос на тостере?
По моему, Вы просто не правильно выбрали ресурс.
По моему, Вы просто не правильно выбрали ресурс.
Есть идея реализовать все алгоритмы.
Выбрать какой то один распространненный язык программирования.
И реализовать алгоритм + описание сложить в одном месте.
Незнаю пока как это сделать. Сообществом или скинуться деньгами и заказать. Потом сделать хаб.
Выбрать какой то один распространненный язык программирования.
И реализовать алгоритм + описание сложить в одном месте.
Незнаю пока как это сделать. Сообществом или скинуться деньгами и заказать. Потом сделать хаб.
## Архитектура
* Клиент
* Сервер
* База данных
* Сайт
### Клиент
* Посылает и принимате сообщения от сервера.
* Отображает графику и объекты
* Отображает интерфейс пользователя и диалоги
### Сервер
* Принимает и отправляет сообщения.
* Осуществляет контроль версий клиента.
* Отвечает за безопасность.
* Игровая механика и взаимодействия игроков.
* Играет за монстров AI.
* Отвечает за целостность и сохранность данных.
* Держит необходимые данные в памяти и совершает репликации в базу
* Крон задачи
* Чат
* Бэкапы
### Сайт
* Регистраци
* Авторизация
* Настройки
* Форум
* Новостная лента
* Медиа
* Админка
* Библиоткека
* Обратная связь
### Админка
* Управление пользователями
* Обратная связь
* Управление новостями
* Управление бд
###Особенности и узкие места
* Разделение логики:3д движок jmonkey, клиент-сервер.
* Сущьности и модели:3д движка, игровые сущьности, сущьности базы данных.
* Грид: для разделения на локации.
* Шаблон Observer: Для оповещения близконаходящихся объектов.
* Очередь сообщений: для оповещения клиентов.
* Сбор сообщений: сбор сообщений от близко находящихся игроков.
* Игровые вычисления: вычисление игровой механики для близко находящихся игроков и объектов
* Отправка: рассылка общего пакета с вычислениями для близко находящихся игроков и объектов
* Синглтон: создание единичного экземпляра объектаю
* Фабрика: для получения типовых объектов
* Абстракции: для определения полей и методов типовых классов.
* Модульность: 1)гибкость подгрузки вспомогательных классов. 2) разделение на модули. 3)роутинг.
* MVC: отделение логики базы данных, представления, и бизнес логки.
* AI монстров: модуль управления монстрами.
* DAO/ActiveRecord: 1) для работы с базой данных 2) ленивая загрузка
* Балансировка и масштабируемость: запуск нескольких экземпляров приложения, возможность запуска на разных физ машинах.
* Jar библиотеки, оптимизация.
* Сервер авторизации.
### Игровые особеноости клиента и сервера
* Чат (отдельный демон принимающий и передающий очереди сообщений по тикам — таймеру)
* Инстансы (подземелья с отдельной логикой, с таймаутом посещения, физически отделены от общего игрового мира)
* Локации — грид (hex grid coordinates) — оповещение о действиях только рядом стоящих игроков и объектов
* БД: во время старта демона приложения делаются выборки из базы, все объекты находятся в памяти.
во время авторизации игрока создается формирующий запрос в бд и создается объект игрока. Переодически демон сбрасывает данные обратно в бд и чистит память.
* Гвард: проверяет целостность данных клиента, проверяет code-injection, key-press, speed-hack,map hack,drop hack, подмену пакетов.
* Апдейтер: проверяет контрольные суммы файлов и папок, вычисляет разницу, заменяет и докачивает необходимые файлы.
* Установщик: ставит все необходимые библиотеки, создает папку назначает права, распаковывает архив или закачивает файлы, запускает апдейтер, запускает игру.
* Демоны принимают сигналы: старт, стоп, рестарт и позьзовательские доступны в том числе через веб интерфейс.
* Клиент
* Сервер
* База данных
* Сайт
### Клиент
* Посылает и принимате сообщения от сервера.
* Отображает графику и объекты
* Отображает интерфейс пользователя и диалоги
### Сервер
* Принимает и отправляет сообщения.
* Осуществляет контроль версий клиента.
* Отвечает за безопасность.
* Игровая механика и взаимодействия игроков.
* Играет за монстров AI.
* Отвечает за целостность и сохранность данных.
* Держит необходимые данные в памяти и совершает репликации в базу
* Крон задачи
* Чат
* Бэкапы
### Сайт
* Регистраци
* Авторизация
* Настройки
* Форум
* Новостная лента
* Медиа
* Админка
* Библиоткека
* Обратная связь
### Админка
* Управление пользователями
* Обратная связь
* Управление новостями
* Управление бд
###Особенности и узкие места
* Разделение логики:3д движок jmonkey, клиент-сервер.
* Сущьности и модели:3д движка, игровые сущьности, сущьности базы данных.
* Грид: для разделения на локации.
* Шаблон Observer: Для оповещения близконаходящихся объектов.
* Очередь сообщений: для оповещения клиентов.
* Сбор сообщений: сбор сообщений от близко находящихся игроков.
* Игровые вычисления: вычисление игровой механики для близко находящихся игроков и объектов
* Отправка: рассылка общего пакета с вычислениями для близко находящихся игроков и объектов
* Синглтон: создание единичного экземпляра объектаю
* Фабрика: для получения типовых объектов
* Абстракции: для определения полей и методов типовых классов.
* Модульность: 1)гибкость подгрузки вспомогательных классов. 2) разделение на модули. 3)роутинг.
* MVC: отделение логики базы данных, представления, и бизнес логки.
* AI монстров: модуль управления монстрами.
* DAO/ActiveRecord: 1) для работы с базой данных 2) ленивая загрузка
* Балансировка и масштабируемость: запуск нескольких экземпляров приложения, возможность запуска на разных физ машинах.
* Jar библиотеки, оптимизация.
* Сервер авторизации.
### Игровые особеноости клиента и сервера
* Чат (отдельный демон принимающий и передающий очереди сообщений по тикам — таймеру)
* Инстансы (подземелья с отдельной логикой, с таймаутом посещения, физически отделены от общего игрового мира)
* Локации — грид (hex grid coordinates) — оповещение о действиях только рядом стоящих игроков и объектов
* БД: во время старта демона приложения делаются выборки из базы, все объекты находятся в памяти.
во время авторизации игрока создается формирующий запрос в бд и создается объект игрока. Переодически демон сбрасывает данные обратно в бд и чистит память.
* Гвард: проверяет целостность данных клиента, проверяет code-injection, key-press, speed-hack,map hack,drop hack, подмену пакетов.
* Апдейтер: проверяет контрольные суммы файлов и папок, вычисляет разницу, заменяет и докачивает необходимые файлы.
* Установщик: ставит все необходимые библиотеки, создает папку назначает права, распаковывает архив или закачивает файлы, запускает апдейтер, запускает игру.
* Демоны принимают сигналы: старт, стоп, рестарт и позьзовательские доступны в том числе через веб интерфейс.
Вот тебе ссылочка http://gameserverarchitecture.com там все отлично расписано (смотри паттерны), ну во всяком случае ты хотя бы начнешь понимать что такое архитектура, возможно сможешь осмыслить объем работы, и чуть больше понять сколько всего ты не знаешь и на сколько смешны твои потуги в данный момент.
То к чему я пришел
http://s8.hostingkartinok.com/uploads/images/2016/04/d2b543b993ecdc185adfedf769d98e40.jpg
http://s8.hostingkartinok.com/uploads/images/2016/04/d2b543b993ecdc185adfedf769d98e40.jpg
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Синхронизация в онлайн играх