Как стать автором
Обновить

Комментарии 62

Начал читать и сразу резануло:
А самое главное, что монолит не заточен на построение распределенной архитектуры и, как следствие, обладает низкой эффективностью.

Распределенная (микросервисная) архитектура это в первую очередь про масштаб. Масштаб команды, масштаб нагрузки, масштаб проекта.
тоже не понял этого. статья выглядит как распределенная архитектура ради распределенной архитектуры
А Akka рассматривалась? У Microsoft весь бэк Halo на Orleans построен — так что акторная модель вполне жизнеспособна
Не знаком с этой технологией и как ее можно применить к решению, поэтому нет.
так а какие результаты в вашей реализации сервера? из статьи непонятно написали ли вы его до конца или нет. какой онлайн держит?
«до конца», смотря что Вы имеете ввиду — полностью функциональную инфраструктуру или полностью готовый сервер для запуска «здесь и сейчас». Инфраструктура была подготовлена, все сервисы и механики описанные в статье были реализованы в т.ч. и базовая логика игрока (перемещение, статистика, инвентарь, etc.). Часть статистики я указал в статье по внутренним подсистемам, а онлайн — в данный момент я способен генерировать автотестами, при доступных мощностях моей серверной станции до 18 тыс. игроков в разных регионах игрового мира в т.ч. и выполнение операций передвижения.
Это слишком базовые вещи.

Как именно поддерживаются все механики сервера? Передвижение не игроков, а NPC, их социальное поведение, а не тупо стояние на месте. Там многие ходят порыкивают, травку жуют, есть и более сложные поведенческие скрипты.

Расскажите как игроки в вашем мире могут взаимодействовать, например присутствуя в одном городе в количестве 500+ человек? Тут как бы больше на клиент нагрузка идет, и особо нет смысла в поддержании всего на одном месте.

Минусы:
не поддерживает масштабируемость сервисов;
ограничение игроков в 5 тыс. на одной инсталляции;

Кроме поддержки какого-то максимального онлайна, для него должно быть достаточно контента. А его в Lineage2 как раз примерно на 5000 игроков уже впритык. Зачастую на официальном сервере при превышении среднего онлайна в 3000, уже старались регистрироваться на другом шарде. Ну и ограничение в 5000 чисто на уровне кода, его можно убрать и проверить насколько действительно нагрузочный тест покажет.
Плюс существующие сервисы легко разносятся на разные машины, а MSSQL кластеризируется сам по себе.
Детальную реализацию можно очень долго и нудно обсуждать, в данном случае делится какими-то best practice с моей стороны «как это сделано, а как это» считаю излишним, поскольку это закрытая информация. Да и статья совершенно не про количество контента в самой игре.
Ну закрытая и закрытая. Мы в свое время разрабатывали активную реализацию на джава, и не слишком сильно шифровались.
А не делиться не то, чтобы готовым кодом, а даже простыми вопросами о реализации — ну крутитесь в своем компоте, зачем тогда вообще статья?
Статья не предусматривает подробный гайд, как реализовывать ту или иную механику, а лишь несет ознакомительный характер — как правильно выстраивать архитектуру бэкенд решения для многопользовательской игры. Любая информация по вашим вопросам общедоступна в исходниках уже существующих решений. Вы можете спокойно открыть их и ответить сами на свои вопросы по игровой механике. Спасибо.
Причем тут гайд.

Я спрашивал — как вы проверяли, что оригинальный бэкенд не держит подобную нагрузку, если ограничение в 5000 сделано не потому, что сильно перенагружено, а просто для того, чтобы в шард, контент которого рассчитан на 3000-4000 человек, не налезало сверх головы.
Насколько я помню, когда я держал шард еще 4-х хроник, то при наличии онлайна около 1000-2000 человек, больше всего напрягался компонент, отвечающий за поведение NPC. А основной сервер не более 10-15% cpu на древних каких-то двухядерных атлонах и 4 гб оперативки. Да, для 5000 возможно было бы лучше гигабитный канал, а не 100мбитный. Но «шардировать» пространство? Это не поможет, если много игроков соберутся в одном «квадрате». А гигабит легко выдержит 5000 игроков.
Вы ведь тестировали нагрузку, имитируя онлайн, а не проверяя что должно быть с каналом?

Делать универсальный бэкенд для «любой ММО», не вникая в суть этого ММО — явно не подход. Например банальная вещь — Lineage2 — псевдо3д игра. Геодата у нее хитро оптимизирована для минимальной нагрузки на клиент и AI.

Думаете в eve online именно архитектура позволяет 20.000 игрокам играть с минимальными лагами?
Насколько я знаю, eve online — полный 3д, с кучей нюансов. И решить вопрос масштабирования конкретной локации пришлось трюком со временем, а не шардированием пространства на кусочки (что скорее всего практически нереально сделать красиво).

Я спрашивал — как вы проверяли, что оригинальный бэкенд не держит подобную нагрузку

Простите, но где?

10-15% cpu на древних каких-то двухядерных атлонах и 4 гб оперативки

А вы проверяли в текущей реальности свои же показатели, перед тем как написать? Явно же нет.
Вам точно хватило на запуск С4 4гб ОЗУ? Да это же смешно, С4 Retail минимум требует 8гб ОЗУ не считая вспомогательный систем WS.

Вы почему-то в упор не видите очевидной реальности — статья абсолютно не заставляет никого брать и делать сейчас свой L2 сервер, пользуясь этой архитектурой, а наоборот — дает эталон архитектуры, которой не стоит пренебрегать в том или ином проекте. Дальнейшая полемика бессмысленна.
— Вот как надо делать бэкенд!
— А как вы решили такую-то проблему?
— Это военная тайна.
— Но всё же, как?
— Не скажу!
— Ладно, поясните тогда, почему ваше решение правильное?
— Идите прочь, я Д'Артаньян!

Дальнейшая полемика бессмысленна.

Вы правы, действительно бессмысленна.

статья абсолютно не заставляет никого брать и делать сейчас свой L2 сервер, пользуясь этой архитектурой, а наоборот — дает эталон архитектуры, которой не стоит пренебрегать в том или ином проекте.

Да, не заставляет.
Однако настолько громкое название статьи («Правильная архитектура MMO эмулятора») и радикальная позиция автора («архитектура подходит к любой игре, и точка») вызывает много вопросов, на которые вопрошающие так и не получают конкретного ответа.
Дельные комменты. Возможно 18 тысяч «ходящих» и на старом железе не проблема повторить. Только вот если у вас в мире живёт 18 тысяч игроков, то надо быть готовым к тому что условная треть может оказаться на осаде и быстро накернит сервер.

Меня больше впечатлит не 18 тысяч ботов которые просто ходят по миру, а 2-4 тысячи игроков которые дерутся у замка. Причём это обязательно должны быть «живые» клиенты-боты, которые по настоящему подключаются к серверу.

И NPC и мобы так же могут очень сильно нагружать сервера. В некоторых эмуляторах их вообще во время осад отключали, т.к других вариантов не было.
Прикол в том, что серверу совершенно все равно где находятся игроки — рядом или далеко.
Основная нагрузка при нахождении игроков рядом приходится на сеть и на клиент, а не на CPU.
Отправить сообщение 2000 игрокам с точки зрения CPU несильная разница.
А вот отправить 2000 лишних пакетов?
А 2000 игроков когда кастуют что-то в бою каждые пару секунд — в одной локации это насколько больше трафика нужно отправлять каждому игроку?
При этом опять таки, нагрузка на CPU — не большая.

p.s. Насколько я помню, как раз NPC и составляли основную нагрузку на процессор в оригинальном сервере.
Прикол в том, что серверу совершенно все равно где находятся игроки — рядом или далеко.
А 2000 игроков когда кастуют что-то в бою каждые пару секунд — в одной локации это насколько больше трафика нужно отправлять каждому игроку? При этом опять таки, нагрузка на CPU — не большая.

Нагрузка на CPU, когда игроки находятся в одном месте и воюют — в разы больше, чем когда они в разных местах.

Если одно АОЕ задевает 20 игроков — надо для каждого игрока просчитать повреждения, а там уже десятки формул и проверок. Какой уровень, какой шмот, какие баффы, является противником или союзником. И этих АОЕ каждую секунду так же кидаются десятки.

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

Фри шард образца 2001года на POL эмуляторе тянул 350 игроков, но уже захлёбывался когда был массовый бой примерно 50х50.
Так же сервер очень плохо переносил «прокачку резиста», когда в одной кучке собиралось по 10-30 игроков и постоянно использовали массовый каст дебаффа друг на друге.

Рост нагрузки при массовом пвп — не линейный. Лучше чтобы дрались 100 кучек по 10 игроков, чем 1000 игроков в одном месте.
Если одно АОЕ задевает 20 игроков — надо для каждого игрока просчитать повреждения, а там уже десятки формул и проверок. Какой уровень, какой шмот, какие баффы, является противником или союзником. И этих АОЕ каждую секунду так же кидаются десятки.


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

Основная проблема высокого онлайна упиралась больше не в CPU, а во внешний канал. Из CPU в официальном шарде, напрягался в основном процесс отвечающий за NPC.

И соответственно вопрос о 17.000 живых игроках, я уверен что в первую очередь упрется в то, как организовано сетевое подключение и балансировка игроков, и намекал автору статьи, что имитация 17.000 человек на локалхосте это некорректно. Что 5000 лимит в том же Lineage2 стоял не потому, что он не мог выдержать, а потому что существуют расчету по комфортному количеству людей в созданном контенте, и проблемы с внешним каналом, а не невозможности просчитать нахождение игроков рядом. Плюс опять таки — на стороне сервера просчитать урон это одно. А на стороне клиента отрисовать тысячи игроков рядом, на обычных домашних десктопах?

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

C EVE Online долго страдали разработчики. И писали об этом.
Там не только в архитектуре дело.
Там очень многое на дизайне висит.
Из примеров (далеко не полных, и все о чем я говорю — не раз писалось CCP):


  • из Jita выкинуто вообще все что только можно (миссии агентов, возможность майнить)
  • прикрыта возможность запускать слишком много дронов — как порезкой бонусов тому же Dominix'у так и установкой явных ограничений на количество дронов для карриеров с мазершипами (чтобы они не запускали их сотнями за раз — по drone bandwith то могут, и нести на борту их тоже могут)
  • полетов на слишком высокой скорости — быть не должно а если игроки находят — ну ребаланс будет значит (речь именно про полеты в локальном гриде)
  • Time Delay — мы признаем что система БУДЕТ лагать в некоторых случаях, и в некоторых случаях — зверски. Но пусть хоть одинаково и предсказуемо у всех кто в данной солсистеме. Ну да, послетают таймеры активации но решаемо другими путям
  • убирать необходимость для достижения важных целей летать огромными флотами (нет — это осталось, но можно и без этого достичь чего то)
  • MSSQL — живет на RAMSAN'ах ("рамдиск в терабайт", если еще не подняли размеры)
  • игрокам запретили варпать в ноль на гейты и они начали создавать массово букмарки с читерными схемами (в результате у каждого этих букмарков — десятки тысяч) — ок разрешим в ноль опять но только на ручном управлении а букмарки рядом с гейтами — потрем и запретим делать
  • рынок — на отдельные серверы (вроде по регионам деление), как и чат, как и сервисы обслуживающие персонажа
  • возможность кому то из руководства конкретной корпорации попросить reinforced-ноду где то за сутки (ну вот знают что вероятно будет мочилово в системе — можно просить).
  • из одной системы влиять на другую напрямую — невозможно. ну разве что маркет.
  • переход между системами либо через джамп-гейты (при этом джамп-гейт может либо предложить позднее попробовать либо вообще сказать про перегрузку) либо прыжок корабля с джамп-двигателем(они на маяк прыгают и это тоже не мгновенно) либо мобильные порталы можно открыть (некоторые корабли умеют), опять же не мгновенно либо еще некоторая экзотика (вормхолы например) но опять же — это просто переход и сервер несущий целевую ноду даже за некоторое время (пусть даже минуты) знает что будет переход. Система где никого нет — может вообще быть в оффлайне (загрузится когда нужна будет).
    кстати там не 20к игроков система держит. она спокойно держит 200-300к игроков в онлайне.

А вот как работает подход, чем то похожий на описанный — можно в SecondLife наблюдать. Куча проблема с переходами между рядом стоящими регионами, особенно если высокий пинг. И пофиксить что-то не особо получается. Хотя потихоньку решают.

Нцсофт уже много хроник подряд все больше и больше контента пихает в инстансы, индивидуальные для отдельных игроков/пати/кк, так что по сути тезис что «контента на слишком большой онлайн не хватит» как бы уже не сильно верен.
Сейчас уже по сути больше ограничение из-за того что само железо не вытянет слишком большой онлайн, без ощутимых лагов. Опять же в этом большей частью архитектура самого сервера виновата.
Вы сравниваете теплое с мягким — у EVE такая структура мира, что можно выделять хоть отдельный сервер на отдельную солнечную систему. В случае единого мира и такой сетки, как вы нарисовали (половина континента в одной ноде, а половина в другой) взаимодействие между нодами будет сложнее, чем между игроками и сервером. Расчет линии видимости или действий АИ на границе будет очень сложным, а что будет если на линию разграничения попадет замок во время осады — я вообще не возьмусь прогнозировать.
В ВоВ как раз смена карты (данжи, БГ, остров ночных эльфов) позволяет использовать под каждую локацию отдельную ноду, хоть это и используется только для Battlegrounds.
И на этот счет есть пару, довольно простых решений, которые так или иначе уберут аффект подсистемы контроля границ «на осадах». Да, в целом я с Вами полностью согласен — где-то сложно, а где-то просто. Но архитектура применима абсолютно к любой MMO. Достаточно ее правильно отобразить в том или ином случае.
В ВоВ как раз смена карты (данжи, БГ, остров ночных эльфов) позволяет использовать под каждую локацию отдельную ноду, хоть это и используется только для Battlegrounds.

А вы уверены? Или вы сейчас не о современном ВоВе, а о каком-то древнем? Уже давно при смене локации имеется приличный шанс перелететь на другой шард.

О древнем. Техническая возможность для этого была, но не использовалась, только на аренах и батлграундах. Что изменилось за последние 5-10 лет не знаю, хотя по логике онлайн ведь не растет уже особо.

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

Не знаю как сейчас дела обстоят, но несколько лет назад смена шарда сопровождалась некоторыми неприятными явлениями.
Особенно сильно это проявлялось, когда появилась возможность сделать свою крепость — сделать так, чтобы друзья в пати попали в тот же шард с твоей крепостью — целый квест нещадно приправленный надеждой на рандом.
В общем, не очень комфортно было играть, когда появилось шардирование такое…
Ух ты! А что крепость даёт? Это для гильдий, или для одного игрока? А войны гильдий и захваты замков там ещё не прикрутили?

Для одного игрока.
https://wowpedia.fandom.com/wiki/Garrison


А войны гильдий и захваты замков там ещё не прикрутили?

Не прикрутят. Большинство игроков в ВоВ не заинтересованы в этих вещах.

Не знаю как сейчас, но раньше это было только для игрока. Причем при заходе в крепость игрок попадает в «свой собственный мирок», который никто кроме него не видел (на этом месте каждый игрок видит свою крепость).
Что дает… а хз… Немножко ресурсов…
Скажу лучше так. Как по мне, близзы, чтобы увеличить аудиторию, в какой-то момент начали впихивать всякую несуразную чушь в игру (чушь — именно в контексте «первоначальной» ММО-игры, по отдельности, эти механики вполне себе неплохи).
Это были и «покемоны» — ловишь по Азероту существ и воюешь ими.
Это были и «весёлые фермы» — где мужественный паладин в сияющих доспехах выращивает свеклу и копает картошку.
И «крепость» — одна из механик пришитых белыми нитками, это такой микроменеджмент крепости, наполненный до безобразия одинаковыми повторяющимеся ежедневными заданиями.
Короче забудьте про крепость, скорее всего она вам не понадобится никогда :)

Не совсем. Шардирование и phasing — разные вещи. Если вы про гарнизоны в WoD — там работало фазирование, которое как раз-таки и ломалось довольно часто. Шардирование к тому времени в игре уже было и довольно активно использовалось, начиная с пандарии (предыдущего аддона). Шардинг в WoD можно было увидеть, проходя квест-лайны и стартуя последний квест-сценарий в открытом мире, который незаметно переносил игрока на инстанс-шард со сценарием.

Видимо, я у себя в голове объединил эти два явления в одно.
Спасибо за разъяснение.

А вот когда бегая по локации (или по границе локации, точно не помню уже, кажется всё же не по границе), я видел как другой игрок то исчезал, то появлялся, и при этом в чате были сообщения переключения глобальных каналов, и кроме этого у ника игрока был написан сервер, на который я изначально не заходил — это ведь шардинг?
Darkfall Online был сделан без шардирования (т.е все в едином мире, на одном большом кластере) и можно было воевать на стыках зон. Подгрузки были только при телепортации в данжи, но при этом данжи не были на отдельных инстансах т.к в данжи было было попасть через эксплойт геометрии.
там давно дошло до отдельного сервера на Грид…
Эх линейка, до сих пор лежит на винте архив C4 ванильного сервера от NCSoft, ну и куча исходников личных. В свое время дорабатывали его до C5. Всё через dll-inject. Даже парсер skilldata был пропатчен на добавление любых новых скиллов без проблем. Даже внешность и пол можно было поменять через скиллы/эффекты и телепортироваться куда угодно.
НЛО прилетело и опубликовало эту надпись здесь
Программу, написанную на плюсах, тоже можно считать, как Вы выразились — «константно фризящей». Не в ЯП дело.
Ну во времена С1-С4 на оффе эмуляторы только-только по сути начинали развивать, так что да — тогда они были тем еще адком, почти ничего не могущим и не умеющим.
Сейчас же с этим все более-менее нормально.
Насчет фризов — этим и офф-сервера грешат бывает — на любом ЯП можно написать программу так что она будет «константно тормозить» при определенных условиях. К тому же там, из-за их своеобразной архитектуры работы с бд, это приводит к возможности с гарантией дюпать вещи и т.д. Из последнего подобного — косяки на серверах Essence — думаю те кто в теме помнят об этом и о том какой срач на эту тему был на офф форуме у Инновы.
В линейке по сути сейчас самое узкое место — это сетевая часть, а конкретно пакеты и их размеры. И самая проблема как раз таки в ситуациях когда куча игроков тусуется в одном месте — на осадах, в городах и т.п. В эти моменты клиентам летят просто дикие объемы пакетов с состоянием и изменяющимся статусом окружающих игроков, того что они кастуют и т.д. и т.п. Притом сами эти пакеты достаточно немаленькие по размерам. Хотя конечно нцсофт уже несколько хроник подряд старается это дело оптимизировать, делая все больше и больше крупных пакетов динамическими по структуре, т.е. отсылая их не полностью, а только те части что реально изменились.
Ну и еще сам допотопный движок клиента вносит конечно свою лепту. Все же как бы корейцы не старались, но UE2 полноценно в многопроцессорность и все такое не может, так что в ситуациях «куча народа на экране» клиент тормозит и лагает даже на вполне современном железе…

З.Ы. Сам потихоньку вожусь с одной из версий эмуляторов, на базе ветки Phoenix/OverWorld, так что по сути знаю о чем говорю…
оптимизация обработки пакетов сетевого трафика это отдельная грустная и долгая песня…
CCP вон даже обработку фрагментарных пакетов реализовывали… сейчас правда наверное проще географический распределенные ноды разместить на крупных IX и сделать оптимизацию пакетной обработки через что-то похожее на «Оптимизирующее сжатие трафика»…
А вообще, есть ли в игре оптимизация вида: «Если в данный момент идёт осада и вокруг много игроков, то я не буду отправлять анимацию кастов от игрока который стоит очень далеко»? Ну или чтобы в пиковые нагрузки отключались некоторые анимации (социальные, анимация применения предметов типа SSок)?
Существует несколько настроек клиента, которые позволяют ограничивать видимость PC/NPC, но чтобы полностью отключать анимацию того или иного действия — нужно делать реализацию привязки некоторых настроек игрока, и резать по ним исходящие пакеты.
Существует несколько настроек клиента, которые позволяют ограничивать видимость PC/NPC

Игроку в этом случае не будут пакеты отправляться? Я думал это только для того, чтобы их на уровне клиента не рисовало.
Будут, радиус оповещения является константой на серверной стороне, но тоже решаемо кастомизацией.
Ну пакеты обычно рассылаются только в определенном радиусе или в текущем + соседних регионах (достаточно маленьких по размерам). При желании опять же дальность рассылки в определенных условиях вполне настраивается + можно не слать определенные пакеты в таких условиях, не так уж сильно нужные для информирования клиента об изменениях.

Про блокирующие read/write-операции у Apache Ignite не понял. Всегда можно сделать async read/write. Данные, кстати, хранятся в оффхипе и, если вам надо получить лишь часть данных, а не весь объект, то такая возможность тоже есть

Что-то это не выглядит как высокая производительность.


Во-первых, не нужно сохранять в persistent каждый чих. Сохранение либо по завершении сделки, либо по решению алгоритма (редкий дроп), либо по таймауту. Всё остальное — in memory.


500k в секунду — это одна NVME'шка DC-уровня.

Сохранять что и куда? Persist каких-либо промежуточных данных происходит в память шарда, а уже, как Вы и сказали, основного состояния, часть которого хранится в базе, выполняется по таймауту в data-service. Уточните утверждение, абсолютно не понятен посыл.

Может, я что-то не понял. У вас in-memory сколько tps делает? Хотя бы миллиард выжимаете?

Скорее всего. Я описывал два состояния игровых объектов — базовое и промежуточное. Базовое — складывается в базу по таймауту. Промежуточное — складывается в off-heap память и реплицируется в кластере. Уточните пожалуйста — tps.

transactions per second.

А я бы пошёл от обратного. Сначала отпрофайлил бы некий текущий код, получив самые «горячие» места сервера, и именно их бы оптимизировал. 20% оптимизаций дало бы 80% выигрыша, или как-то так :)
А что при такой архитектуре делать с Штурмом Адены?
те почему выбрана именно такая механика Шардирования — почему не выбрана тактика тех же CCP когда шарды привязываются к узлам с максимальной нагрузкой?
Я, довольно таки, плохо знаком с архитектурой решения ССР, и как они осуществляют балансировку ибо в публичных данных этого не написано. Предположительно они делают тоже самое — при подключении нового шарда, игроки распределяются равномерно между ними. Но и им это проще делать, поскольку данные централизовано хранятся на RAID массивах. У моего решения — в памяти, а шарить память между двумя процессами, даже с помощью nmap, гиблая затея. Здесь, возможно, же, все тоже самое. Первоначальное состояние S1 (100 игроков), подняли S2, оркестратор перебросил какой-то процент игроков, охватывающий те регионы, в которых они находятся, на S2.
просто при географическом Шардинге у вас встает вопрос передачи данных о взаимодействии больших групп игроков. и что Будет происходить при Обсчете взаимодействия скажем 1000 игроков? а если они будут постоянно мигрировать через границу шарда? или например половина игроков буде по одну сторону, а вторая по другую?

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

У CCP все несколько веселее — ищите Дев блоги где они рассказывали про физику и логику работы своей системы в 2018-19 годах навряд ли есть что то более новое.
Если что на физике у них RAM-Drive для БД тогда было сейчас скорее всего переехали на IN-memory…
просто при географическом Шардинге у вас встает вопрос передачи данных о взаимодействии больших групп игроков. и что Будет происходить при Обсчете взаимодействия скажем 1000 игроков

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

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


Предмет перекочует вместе с игроком в том состоянии, в котором он находился до балансировки. Т.е. тут можно рассмотреть два варианта
1. игрок выбросил предмет в регионе 1, перешел через границу, и видит его в выброшенном месте
2. игрок выбросил предмет в регионе 1 и в этот же момент произошло добавление нового шарда, который сузил границы региона 1 и поделил его напополам. В последствии предмет «перекочевал» обратно к игроку в новый шард.

P.s. чтобы каких-то неочевидных багов не происходило, я блокирую любое телодвижение объектов в мире при «расширении/сужении» кластера, увы операция сама по себе дорогостоящая.
Дельта данных каждого игрока уже существует во всех шардах кластера средствами репликации. Так что это особого аффекта не должно вызвать, как и сейчас с перемещением. А взаимодействие игрок-игрок на границах — обмен трафика между шардами.

и насколько быстро оно работает? Вот два шарда 500 человек в одном 500 человек в Другом — атакуют друг-друга через границу шарда… что-то мне сомнительно что у вас будет происходить всё без проблем — по сути БД будет обновляться Двумя шардами, нагрузка на БД практический удваивается, а то и учетверяется, тк запросы идут под одними тем же объектам для двух шардов, реплики здесь не особо помогут тк взаимодействие идет МЕЖДУ объектами на разных шардах…

В общем думается мне что без механизма динамического шардирвоания который создаст Зону в которую уместятся обе группы игроков и выделит им отдельный шард у вас не будет без явных фризов и багов… технический я бы Шардировал именно по группам игроков по сути генерируя для каждой группы псевдо мир в котором они крутятся и старался бы сделать систему в которой не было вобще привязки к статичным объектам…

Предмет перекочует вместе с игроком в том состоянии, в котором он находился до балансировки. Т.е. тут можно рассмотреть два варианта
1. игрок выбросил предмет в регионе 1, перешел через границу, и видит его в выброшенном месте
2. игрок выбросил предмет в регионе 1 и в этот же момент произошло добавление нового шарда, который сузил границы региона 1 и поделил его напополам. В последствии предмет «перекочевал» обратно к игроку в новый шард.


вы делаете расчет на идеальный мир — "… а он имеет свойство тормозить!!!" — игрок бежит в шарде №1 и выкидывает объект ровно за Тик до границы объект выпадает тк условия проверки проходят нормально — у игрока объект в ТЕОРИИ должен пропасть Транзакция на удаление Объекта в БД улетела — НО она не мгновенная(!!!) и Вот тут начинается веселье, тк Игрок попадает на другой Шард где ЕЩЁ нет информации о Отсутствии объекта у Игрока и он может выложить его повторно… И возникает очень интересная коллизия — объект Валиден и есть На шарде №1 Объект Валиден и Есть на шарде №2 и Объекта нет у игрока о чем прилетает подтверждение из БД в реплики обоих шардов…

Даже если у вас есть четкое отслеживание ID-ов Объектов и каждый ID уникален и это проверяется — вопрос в том как у вас происходит обработка свободно «лежащих» на «Земле» объектов? Если вы думаете что тут проблема только с Дюп-ом объектов то вы сильно заблуждаетесь Босы, Мобы и NPC тоже Дюпаются…
Ну смотрите, идея виртуальных регионов тоже уже предусмотрена, и включатся они должны в момент этих самых скоплений персонажей на границах, как и с массовыми мероприятиями (вдруг замок попадет в границу). Сама бд не нагружена от слова совсем, а вот сокет — да. Для промежуточного состояния используется не бд, а память и репликация, также для консистентной обработки планируется использовать распределённый CAS ключей.
а зачем тогда Вобще Статические Шарды? делаете по умолчанию Для каждого игрока динамический шард при приближении к другому игроку сливаете Их на новый шард если у них возникает взаимодействие, если нет то просто Отображаете «Тень» — да система более Сложная, но гораздо более гибкая тк реально пропадает всякая привязка и ограничения.
Интересная идея, возможно будет взята на вооружение. Спасибо
Эта работа проведена для обучения или «Just fro fun»?
Кому в настоящий момент может понадобиться сервер Lineage 2 для больших онлайнов?
Эта работа была проведена для создания готовой платформы/решения разработки.
Странно. В 2021 году я не знаю проектов L2 кроме оффициальных серверов, где нагрузка может быть больше чем несколько сотен одновременных игроков.
L2 уже давно в небытие. Есть же Aion и другие ;)
Понял, обкатка идеи на том что было.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории