Рейтинг темы:
  • 0 Голос(ов) - 0 в среднем
  • 1
  • 2
  • 3
  • 4
  • 5
Архитиктура mmo сервера
#11
Такс, ладно... С этим боле мение понятно... А что по поводу зон..А именно:
Вся карта в клиенте я так понимаю нарезана на небольшые куски(зоны) и у игрока, подключенного к серверу и слушающего события и сообщения есть особая зона, зона видимости, Если моб или обьект попадает в эту зону то сервер передает клиенту координаты этого обьекта, если выходит из зоны, сервер отписывает от раздачи этих координат.

Примерно так я сейчас это представляю, в java эмуляторах сделано также, или есть свои тонкости? Какие?)
Ответ
#12
Dеmon Написал:Когда-то наша команда начинала работать на Git, но потом перешли на SVN. Основная причина - полнейшее нежелание пользователей читать мануалы и вникать как работает Git. Пользователи на форуме постоянно создавали тонны тем аля "ПАМАГИТЕ НИМАГУ СКОЧАТЬ ИСХОДНИКИ!!11".

Dеmon Написал:Да больше ничего и не скажешь... Smile
Говоря о Git, имхо, намного лучше, чем SVN.


Никогда не слушайте пользователей в таких вещах, ибо зло. Чтобы они делали если бы вы использовали Mercurial? После >5 лет работы с SVN и его предшественником CVS последний год работаю под GIT. Перевел все свои активные проекты с помощью git-svn в git-формат, и не могу нарадоваться. Один таск = 1 бранч и нет мороки с merge как у SVN, если хочется поэксперементировать - создавай локальный бранч и играйся в нем без вреда основному репозиторию.

Zubastic Написал:Темку про кешед (выше ссылка) почитайте.
Хорошо настроенный и интегрированный ehcache может решить все эти проблемы.
for(;Forum.getPostCount() < Integer.MAX_VALUE; Forum.writeNewPost()); | TERA Video | GamezTERA Emu
Ответ
#13
ldgames Написал:Такс, ладно... С этим боле мение понятно... А что по поводу зон..А именно:
Вся карта в клиенте я так понимаю нарезана на небольшые куски(зоны) и у игрока, подключенного к серверу и слушающего события и сообщения есть особая зона, зона видимости, Если моб или обьект попадает в эту зону то сервер передает клиенту координаты этого обьекта, если выходит из зоны, сервер отписывает от раздачи этих координат.

Примерно так я сейчас это представляю, в java эмуляторах сделано также, или есть свои тонкости? Какие?)

Карта в клиенте нарезана на квадраты. В зоны могут входить разные квадраты или не входить, тут все зависит от разработчика, т.к. само определение "зона" - серверная часть и она существует только на сервере, другими словами в одном квадрате может быть 100 зон, а в другом 1 зона, которая распространяется и на другие квадраты. В основном это используется, как возбудитель каких-либо событий.
Да, у игрока есть определенный лист видимости, в котором лежат все обьекты, которые он видит в своем радиусе и с которыми может взаимодействовать. Клиент тут опять же не при делах, выход и заход в лист видимости осуществляется на серверной стороне, а клиенту всего лишь передается пакет, который отображает игроку обьект.

Если Вы решили изучать архитектуру ММО на л2ж серверах, то это плохая идея, т.к. они очень, очень кривые. В особенности алгоритмы зон видимости, там вообще кошмар и ужас, из-за которого часто утекает память, либо происходят различные NPE (плюсом могу добавить еще сложность разработки с учетом листов видимости).


Цитата:И все таки вернувшись к теме, появилась следующая идейка: Пользователь(клиент) при конекте создает канал, передает сообщение серверу, по UDP протаколу на так сказать 'Прихожую', та в свою очередь подписывает клиента на сообщения и выделяет ему новый поток, И дальше клиент получает координаты других обьектов в зоне видимости и т.д .
При использовании UDP протокола на этапе авторизации очень сильно падает безопасность, т.к. их легче перехватить, да и пакеты могут не дойти.
Лучше организовать работу таким образом:
1. Подключение игрока к серверу авторизации
- TCP протокол
- базовая пакетка авторизации (ключи, авторизация, выбор сервера, выбор персонажа, etc)
- отсылка пакета на реконнект к определенному гейму с проверкой сгенерированных ключей от сервера авторизации (чтобы предотвратить логин без сервера авторизации)
2. Разрыв коннекта клиента с сервером авторизации и работа по UDP протоколу с геймом

Дальше уже ваша фантазия. Заход в мир (инициация персонажа, броадкаст пакетов видимости, различные события по заходу игрока и etc)

P.S: в l2j реализован строгий TCP, если и есть UDP, то он работает по одной подсети сервера и клиента; алгоритмика работы связки авторизации и гейма чем-то схожи с тем, что я описал, но все же в l2j есть существенные недостатки в плане отказоустойчивости и безопасности.
m0nster.art - clear client patches, linkz to utils & code.
Гадаю по капче.
Ответ


Возможно похожие темы ...
Тема Автор Ответы Просмотры Последний пост
  Создание движка сервера (L2) pitch 61 29,670 08-10-2010, 11:33 PM
Последний пост: Blakkky

Перейти к форуму:


Пользователи, просматривающие эту тему: 2 Гость(ей)