Я ищу любой материал на бесшовных MMO серверах! У меня есть несколько статей в книгах «Разработка многопользовательских игр» и «Gems 5 для программирования игр». Кто-нибудь имеет опыт в этой теме или знает статьи об этом?
Я заинтересован в "взглядах высокого уровня", а также в реализации. Это может стать темой моей магистерской диссертации, и я хотел бы выяснить, насколько сложно написать такую систему, прежде чем я действительно начну работу над диссертацией. Сейчас я не решил, какой язык использовать, я думаю о Java или Scala. Эрланг мог бы быть выбором, но я никогда не работал с этим.
Примечание: основным требованием будет движение. Любые другие игровые системы являются необязательными и дают «бонусный кредит».
Теперь о том, что я имею в виду под «бесшовным сервером»: я хочу настроить кластер серверов, где каждый узел контролирует некоторую часть игрового мира со статическими границами. Игроки теперь могут перемещаться из одного конца света в другой, не переключая экземпляр и не нажимая на какого-нибудь «телепорта». Я думаю, что WoW делает это. В моем бэк-энде игрок переходит с одного сервера на другой.
источник
Ответы:
Основная сложность в управлении такой системой заключается в том, насколько она вам нужна. Как сказал Джош, решение проблемы передачи объекта с одного сервера на другой является ключевой частью пакета.
Это не единственная проблема - если сущности на нескольких серверах должны взаимодействовать как часть одной операции, у вас теперь есть проблема синхронизации, когда каждая система нуждается в данных с другой стороны для продолжения, но к тому времени, когда данные поступают, это может уже будет недействительным. Вы можете попытаться решить эту проблему, разбив операцию на несколько сообщений с возможностью отката, если одна сторона отступит, но, как вы видели из главы 3.1 «Разработка многопользовательских игр», это значительно усложняет любую игровую логику, которая вам требуется. сделай это с. Scala и Erlang помогают вам правильно настроить систему обмена сообщениями - они не помогают вам разбить то, что раньше было функцией из 10 строк, на множество различных сообщений и состояний, которые вы теперь должны отслеживать.
Очевидно, что эта проблема не является совершенно новой, и реляционные базы данных поддерживают такую проблему, сохраняя все данные централизованно и позволяя нескольким клиентам запрашивать и изменять их по мере необходимости, откатывая транзакции в случае необходимости. Это дает вам большинство ваших требований к корректности, но, к сожалению, накладывает непрактичные проблемы с производительностью, а также затрудняет реализацию игровой логики (поскольку большая часть вашей логики теперь записана в хранимых процедурах базы данных). Хорошим решением здесь может быть другой тип базы данных, особенно если вы готовы отказаться от требований к надежности, которые предоставляет большинство СУБД.
Большинство профессиональных игр решают эту проблему, даже не пытаясь ее решить, сохраняя размер осколка достаточно малым, чтобы поместить всех игроков на один сервер, разделяя мир на части, которые на самом деле не взаимодействуют (см. Пример WoW в комментариях выше). или путем распределения игры по серверам на основе функций, а не географии (например, все сражения происходят на одном сервере, все разговоры на другом), чтобы не было «швов» для борьбы.
источник
Реализации, как правило, достаточно глубоко вовлечены, и вы, вероятно, не будете много говорить о них здесь. Программное обеспечение StackExchange не подходит для такого рода дискуссий, не говоря уже о том, что оно потребует значительных затрат чьего-то времени.
Не более или менее сложная, чем любая другая система: это будет зависеть от ваших требований и функций, которые вы собираетесь использовать. Вы можете написать тривиальные реализации тривиально, но нетривиальные вещи, конечно, будут гораздо сложнее. Одна из самых больших проблем заключается в том, что вам, вероятно, не хватит реальных клиентов, чтобы сказать, действительно ли ваша система масштабируется до «массового» уровня, на котором работают WoW и другие игры.
ММО не волшебные. Большинство их технологий не является чем-то особенным, если рассматривать их изолированно. Просто очень маленькие и более простые технологии объединяются очень разумно, чтобы обеспечить более крупномасштабное параллельное моделирование некоторого общего состояния мира.
По сути, то, о чем вы говорите, - это симуляция. Это можно сделать довольно просто и не обязательно для конкретной MMO-технологии (одноранговые игры, как правило, поддерживают все те же базовые механизмы для реализации миграции хоста). Основная предпосылка заключается в том, чтобы каждый сервер понимал топологию серверов «вокруг» него (в частности, сервер для мирового узла A должен знать о серверах для смежных с моделированием мировых узлов), а также определял буфер, вокруг которого вы рассматриваете конкретная моделируемая сущность "близко" к соседнему серверу.
Когда объект входит в «закрытый» буфер, вы также начинаете сообщать о нем на соседний сервер. Как только объект пересекает фактический порог, вы отправляете сообщение на соседний сервер с полным состоянием объекта и сообщением, указывающим, что смежный сервер должен взять на себя объект. Очевидно, вы хотите, чтобы это было максимально надежно.
источник