Идеявейвкор. Ретроспектива

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

С похожими мыслями в конце 2018 года я думал о том, чем хочу заниматься.

собственный Сервер WoW, которым я буду полностью управлять.

После изучения исходников C++ МАНГО , я пришел к выводу, что не могу просто взять и реализовать все свои идеи, не понимая, как работает MMO RPG-сервер от начала до конца.

И для этого я решил реализовать мой двигатель.

С нуля.




Начну с того, что поначалу у меня были только исходники из документации.

С переменным успехом я искал по крупицам ответы на свои многочисленные вопросы на форумах (в этом плане огромный респект сообществу МАНГО , - очень отзывчивая команда).

В общей сложности прошло несколько месяцев, прежде чем я методом проб и ошибок реализовал свой первый рабочий прототип.

Авторизоваться сервер - и смог попасть на экран выбора персонажа.

Короче говоря, сервер входа (как и аутентификация в клиенте WoW) построен на использовании алгоритма рекомендуемая розничная цена .

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

Даже предпочтительно .

Алгоритм шифрования Мирового сервера скорее всего отличается от клиента к клиенту (к такому выводу я пришел после беглого изучения исходного кода Серверы WoW 3.3.5a ).

Я разрабатывал сервер для WoW версии 2.4.3. Он использует что-то вроде шифр Цезаря .

Хотя чаще (в исходном коде) можно встретить название HeaderCrypt или Wowcrypt. В версии 2.4.3 зашифрованы первые 6 байт: размер (2) и код операции (4) каждый пакет на Мировом сервере ( кроме первой упаковки ).

Соответственно, если вы перехватите пакет (снифф), вы не сможете определить, какой именно.

код операции оно будет отправлено.

А если пакет большой, то его можно разделить на несколько и чтобы их корректно достать из буфера нужны вот эти самые первые 2 байта ( размер ).

Кратко процесс входа на сервер можно описать следующим образом:

Идеявейвкор.
</p><p>
 Ретроспектива

Клиент последовательно обменивается данными с сервером входа и в случае успеха получает токен SRP (сессионный ключ), который затем будет использоваться для создания токен шифрования/дешифрования пакетов (криптоключ).

Токен создается на этапе «отправить запрос аутентификации» (см.

схему выше).

После чего клиенту отправляется авторизационный ответ, суть которого — показать, что операция прошла успешно.

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

По поводу шифра - он у меня реализован Так .

Процесс взаимодействия с Мировым сервером прост - клиент отправляет зашифрованный пакет, на сервере он помещается в буфер, расшифровываются первые несколько байтов (как я писал выше), получаем размер( размер ) и код операции ( код операции ) и если количество байтов в буфере > = размер , затем получаем список необходимых обработчиков (их может быть несколько) по заданному коду операции и передаем их размер байт из буфера.

Или ждем получения оставшихся байтов.

Заслуживает особого внимания Обновление пакета .

Он отличается от других пакетов более сложная структура .

Каждый пакет необходимо расшифровать .

Если пакет пропущен, следующий (по алгоритму) будет расшифрован неправильно.

Я с особым усердием наступил на эти грабли.



В чем суть моего сервера

Во-первых, я написал это на Python 3 (asyncio + SQLAlchemy).

Точнее, на момент создания у меня еще не было опыта работы с SQLAlchemy — я приобрел его позже, когда решил, что существующая у меня реализация работы с БД ужасна во всех ее проявлениях (и в то же время я решил изучить новую технологию).

И я в очередной раз переписал проект с нуля.

Во-вторых, несколько отличался и подход к обработке данных.

Я решил отказаться от идеи глобального хранилища всех объектов (где каждый объект также содержит методы для работы с ним) и создавать специальные менеджеры (менеджер) для работы с каждым отдельным типом объекта: Предмет, Игрок, Юнит и т.д. если я хочу выполнить действие над Игрок , Я использую Менеджер игрока , который выполняет желаемое действие и удаляется из памяти.

В первую очередь это было сделано ради читабельности.

Например, подобные Сорт в MANGOS лично мне это кажется громоздким (как и C++, несмотря на его многочисленные преимущества).

Каждый отдельный класс объектов представляет собой модель SQLAlchemy, а также структуру данных, в которой хранится текущее состояние.

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

В-третьих, я использую специальные классы — handler — коллекцию которых использую для обработки.

один код операции .

Каждый обработчик должен выполнить одну типовую задачу.

И (опционально) он может вернуть ответ (код операции + данные — структура, аналогичная запросу), который затем будет отправлен клиенту.

В-четвёртых, почти сразу я решил не делать ещё один движок MANGOS, а вместо этого начал экспериментировать со свободой использования( Что может быть сделано кроме уже реализовано в других подобных проектах ? ).

Все началось с идеи использовать собственный набор данных (данные, которые мы загружаем в базу данных).

Короче говоря, моя цель — больше творчества без границ, а не создание модифицированного (или похожего на близз) сервера WoW. В-пятых, я неоднократно переписывал код, чтобы сделать его более читабельным и в принципе мне удалось создать более-менее единую архитектуру.

Думаю это несомненный плюс для тех, кто будет читать источник .

В этих же целях при разработке упор был сделан на ООП.



О самом сервере

Вероятно, имеет смысл сказать несколько слов о том, что на самом деле реализовано.

  1. Собственно, вход на сервер
  2. Создание/удаление персонажа
  3. Вход в мир
  4. Отображение экипированных предметов и оружия
  5. Отображение окружающих игроков/мобов
  6. Трансляция движения/чата (сказать/крикнуть)
  7. Погода
  8. Показать сообщение дня


Что дальше

На стадии разработки серверы У меня была идея создать Механизм шаблонов MMO RPG , который предоставит формат описания игровых серверов (например, комбинация Login + World server, или шард-ориентированная архитектура, где каждая локация представляет собой отдельный сервер и т. д.), а также серверов, относящихся к игровым косвенно (например, веб-сервер, на котором будет сайт и форум).

Именно поэтому я создал рамки (но не совсем ясно описал это в своем предыдущая статья ).

И сейчас я переписываю сервер на основе этого фреймворка.

Я уже столкнулся с рядом вещей, которые необходимо будет рефакторить, поэтому к моменту выполнения текущей цели я планирую выпустить ряд изменений в сам фреймворк.

О чем я, возможно, напишу в будущем.

Если есть интерес к серии статей.

P.S. продолжайте развивать свой оригинальный проект Я не планирую.

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

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Есть ли у вас опыт написания игрового сервера с нуля? 23.08% Да (есть полностью рабочий игровой сервер, сделанный с нуля) 3 7.69% Да (но не доделал) 1 23.08% Нет (и нет желания) 3 46.15% Хочу попробовать сделать 6 Проголосовали 13 пользователей .

2 пользователя воздержались.

Теги: #Разработка игр #Разработка стартапа #сервер #открытый исходный код #стартап #ООП #открытый исходный код #python3 #mmorpg #srp #idewavecore #idewave-core

Вместе с данным постом часто просматривают: