Скорее всего. Я описывал два состояния игровых объектов — базовое и промежуточное. Базовое — складывается в базу по таймауту. Промежуточное — складывается в off-heap память и реплицируется в кластере. Уточните пожалуйста — tps.
Я спрашивал — как вы проверяли, что оригинальный бэкенд не держит подобную нагрузку
Простите, но где?
10-15% cpu на древних каких-то двухядерных атлонах и 4 гб оперативки
А вы проверяли в текущей реальности свои же показатели, перед тем как написать? Явно же нет.
Вам точно хватило на запуск С4 4гб ОЗУ? Да это же смешно, С4 Retail минимум требует 8гб ОЗУ не считая вспомогательный систем WS.
Вы почему-то в упор не видите очевидной реальности — статья абсолютно не заставляет никого брать и делать сейчас свой L2 сервер, пользуясь этой архитектурой, а наоборот — дает эталон архитектуры, которой не стоит пренебрегать в том или ином проекте. Дальнейшая полемика бессмысленна.
Сохранять что и куда? Persist каких-либо промежуточных данных происходит в память шарда, а уже, как Вы и сказали, основного состояния, часть которого хранится в базе, выполняется по таймауту в data-service. Уточните утверждение, абсолютно не понятен посыл.
Статья не предусматривает подробный гайд, как реализовывать ту или иную механику, а лишь несет ознакомительный характер — как правильно выстраивать архитектуру бэкенд решения для многопользовательской игры. Любая информация по вашим вопросам общедоступна в исходниках уже существующих решений. Вы можете спокойно открыть их и ответить сами на свои вопросы по игровой механике. Спасибо.
Детальную реализацию можно очень долго и нудно обсуждать, в данном случае делится какими-то best practice с моей стороны «как это сделано, а как это» считаю излишним, поскольку это закрытая информация. Да и статья совершенно не про количество контента в самой игре.
И на этот счет есть пару, довольно простых решений, которые так или иначе уберут аффект подсистемы контроля границ «на осадах». Да, в целом я с Вами полностью согласен — где-то сложно, а где-то просто. Но архитектура применима абсолютно к любой MMO. Достаточно ее правильно отобразить в том или ином случае.
«до конца», смотря что Вы имеете ввиду — полностью функциональную инфраструктуру или полностью готовый сервер для запуска «здесь и сейчас». Инфраструктура была подготовлена, все сервисы и механики описанные в статье были реализованы в т.ч. и базовая логика игрока (перемещение, статистика, инвентарь, etc.). Часть статистики я указал в статье по внутренним подсистемам, а онлайн — в данный момент я способен генерировать автотестами, при доступных мощностях моей серверной станции до 18 тыс. игроков в разных регионах игрового мира в т.ч. и выполнение операций передвижения.
По сути, кому что по душе, к примеру Camel для меня — сложноват, а Integration — почему-то в самый раз, но, наверно, подводных камней больше, особенно при работе с каналами.
Простите, но где?
А вы проверяли в текущей реальности свои же показатели, перед тем как написать? Явно же нет.
Вам точно хватило на запуск С4 4гб ОЗУ? Да это же смешно, С4 Retail минимум требует 8гб ОЗУ не считая вспомогательный систем WS.
Вы почему-то в упор не видите очевидной реальности — статья абсолютно не заставляет никого брать и делать сейчас свой L2 сервер, пользуясь этой архитектурой, а наоборот — дает эталон архитектуры, которой не стоит пренебрегать в том или ином проекте. Дальнейшая полемика бессмысленна.