Очень здорово запрограммировать механизм или программный модуль, заставив его выполнять свою волю.
С похожими мыслями в конце 2018 года я думал о том, чем хочу заниматься.
собственный Сервер WoW, которым я буду полностью управлять.
После изучения исходников C++ МАНГО , я пришел к выводу, что не могу просто взять и реализовать все свои идеи, не понимая, как работает MMO RPG-сервер от начала до конца.
И для этого я решил реализовать мой двигатель.
С нуля.
Начну с того, что поначалу у меня были только исходники из документации.
С переменным успехом я искал по крупицам ответы на свои многочисленные вопросы на форумах (в этом плане огромный респект сообществу МАНГО , - очень отзывчивая команда).
В общей сложности прошло несколько месяцев, прежде чем я методом проб и ошибок реализовал свой первый рабочий прототип.
Авторизоваться сервер - и смог попасть на экран выбора персонажа.
Короче говоря, сервер входа (как и аутентификация в клиенте WoW) построен на использовании алгоритма рекомендуемая розничная цена .
Описание алгоритма выходит за рамки статьи, но вкратце он позволяет идентифицировать пользователя без передачи пароля на сервер, благодаря чему пароль (даже в кэшированном виде) может быть не хранить на сервере.
Даже предпочтительно .
Алгоритм шифрования Мирового сервера скорее всего отличается от клиента к клиенту (к такому выводу я пришел после беглого изучения исходного кода Серверы WoW 3.3.5a ).
Я разрабатывал сервер для WoW версии 2.4.3. Он использует что-то вроде шифр Цезаря .
Хотя чаще (в исходном коде) можно встретить название HeaderCrypt или Wowcrypt. В версии 2.4.3 зашифрованы первые 6 байт: размер (2) и код операции (4) каждый пакет на Мировом сервере ( кроме первой упаковки ).
Соответственно, если вы перехватите пакет (снифф), вы не сможете определить, какой именно.
код операции оно будет отправлено.
А если пакет большой, то его можно разделить на несколько и чтобы их корректно достать из буфера нужны вот эти самые первые 2 байта ( размер ).
Кратко процесс входа на сервер можно описать следующим образом:
Клиент последовательно обменивается данными с сервером входа и в случае успеха получает токен SRP (сессионный ключ), который затем будет использоваться для создания токен шифрования/дешифрования пакетов (криптоключ).
Токен создается на этапе «отправить запрос аутентификации» (см.
схему выше).
После чего клиенту отправляется авторизационный ответ, суть которого — показать, что операция прошла успешно.
Ответ аутентификации — единственный незашифрованный пакет, последующие пакеты будут зашифрованы с использованием криптоключ .
По поводу шифра - он у меня реализован Так .
Процесс взаимодействия с Мировым сервером прост - клиент отправляет зашифрованный пакет, на сервере он помещается в буфер, расшифровываются первые несколько байтов (как я писал выше), получаем размер( размер ) и код операции ( код операции ) и если количество байтов в буфере > = размер , затем получаем список необходимых обработчиков (их может быть несколько) по заданному коду операции и передаем их размер байт из буфера.
Или ждем получения оставшихся байтов.
Заслуживает особого внимания Обновление пакета .
Он отличается от других пакетов более сложная структура .
Каждый пакет необходимо расшифровать .
Если пакет пропущен, следующий (по алгоритму) будет расшифрован неправильно.
Я с особым усердием наступил на эти грабли.
В чем суть моего сервера
Во-первых, я написал это на Python 3 (asyncio + SQLAlchemy).Точнее, на момент создания у меня еще не было опыта работы с SQLAlchemy — я приобрел его позже, когда решил, что существующая у меня реализация работы с БД ужасна во всех ее проявлениях (и в то же время я решил изучить новую технологию).
И я в очередной раз переписал проект с нуля.
Во-вторых, несколько отличался и подход к обработке данных.
Я решил отказаться от идеи глобального хранилища всех объектов (где каждый объект также содержит методы для работы с ним) и создавать специальные менеджеры (менеджер) для работы с каждым отдельным типом объекта: Предмет, Игрок, Юнит и т.д. если я хочу выполнить действие над Игрок , Я использую Менеджер игрока , который выполняет желаемое действие и удаляется из памяти.
В первую очередь это было сделано ради читабельности.
Например, подобные Сорт в MANGOS лично мне это кажется громоздким (как и C++, несмотря на его многочисленные преимущества).
Каждый отдельный класс объектов представляет собой модель SQLAlchemy, а также структуру данных, в которой хранится текущее состояние.
Поэтому я использую такие объекты Не только для взаимодействия с базой данных, но и для обмена структурированными данными между частями приложения.
В-третьих, я использую специальные классы — handler — коллекцию которых использую для обработки.
Каждый обработчик должен выполнить одну типовую задачу.
И (опционально) он может вернуть ответ (код операции + данные — структура, аналогичная запросу), который затем будет отправлен клиенту.
В-четвёртых, почти сразу я решил не делать ещё один движок MANGOS, а вместо этого начал экспериментировать со свободой использования( Что может быть сделано кроме уже реализовано в других подобных проектах ? ).
Все началось с идеи использовать собственный набор данных (данные, которые мы загружаем в базу данных).
Короче говоря, моя цель — больше творчества без границ, а не создание модифицированного (или похожего на близз) сервера WoW. В-пятых, я неоднократно переписывал код, чтобы сделать его более читабельным и в принципе мне удалось создать более-менее единую архитектуру.
Думаю это несомненный плюс для тех, кто будет читать источник .
В этих же целях при разработке упор был сделан на ООП.
О самом сервере
Вероятно, имеет смысл сказать несколько слов о том, что на самом деле реализовано.
- Собственно, вход на сервер
- Создание/удаление персонажа
- Вход в мир
- Отображение экипированных предметов и оружия
- Отображение окружающих игроков/мобов
- Трансляция движения/чата (сказать/крикнуть)
- Погода
- Показать сообщение дня
Что дальше
На стадии разработки серверы У меня была идея создать Механизм шаблонов 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
-
Поисковая Система Azoos: Объективный Обзор
19 Oct, 24 -
Пузырь Роста Рынка Erp-Систем В России.
19 Oct, 24 -
Какие Системы Помощи Будут В Будущем?
19 Oct, 24 -
Подкаст «Я Сказал На Каннада» (№ 17)
19 Oct, 24 -
Seo-Инструментарий
19 Oct, 24