Современный переосмысленный менеджер аккаунтов игроков для Freelancer Server, переработанный под большие игровые сборки, кириллицу, асинхронную обработку и расширяемую архитектуру.
Note
Этот проект является частью экосистемы Lizerium и относится к направлению:
Если вы ищете связанные инженерные и вспомогательные инструменты, начните оттуда.
Note
Этот проект является переосмыслением и модернизацией старого инструмента управления аккаунтами игроков для серверов Freelancer (2003).
Он создаётся как более современная, масштабируемая и расширяемая версия классического DS Account Manager / DCAM.
DCAM (Dvurechensky Account Manager / DS Account Manager Rework) — это переработанный инструмент для анализа, отображения и управления данными аккаунтов игроков на сервере Freelancer.
Изначально старые менеджеры аккаунтов создавались в эпоху, когда размеры игровых сборок, структура данных, кодировки и требования к архитектуре были совершенно другими.
Со временем стало очевидно, что старый подход:
- плохо масштабируется,
- плохо переносит большие модификации,
- ломается на кириллице,
- сложно расширяется,
- и плохо подходит для современной инфраструктуры.
Поэтому проект был пересобран заново с упором на:
- читаемую архитектуру,
- поддержку больших игровых данных,
- современный .NET-подход,
- нормальную работу с кириллицей,
- асинхронную обработку,
- расширяемость под будущие сервисы.
- 📖 О проекте
- 🌖 Предыстория
- ❗ Почему проект пришлось пересоздать
- 🌀 1. Слишком долгая обработка крупных игровых сборок
- 🌀 2. Базовая версия инструмента была англоязычной
- 🌀 3. Проблемы с кириллицей и кодировками
- 🌀 4. Устаревший подход на XSD-структурах
- 🌀 5. Смешанная логика без нормального разделения ответственности
- 🌀 6. Последовательные алгоритмы тормозили всё приложение
- 🌀 7. Не хватало интеграции с современной экосистемой
- 🚀 Что было изменено
- 🧠 Архитектурная идея
- 🧱 Технические улучшения
- 📜 История и происхождение
⚠️ Текущее состояние- 🔗 Наследие и алгоритмы
- 📜 История изменений
- ⚖️ Лицензия
- 💬 Примечание
Я, Dvurechensky, решил пересоздать эту программу практически с нуля, потому что старый подход перестал соответствовать реальным условиям работы с моим проектом.
Изначально инструмент был известен как:
- DCAM
- DC Account Manager
- DS Account Manager
Однако он проектировался под совсем другие объёмы данных и под игровые сборки, которые были существенно легче и проще, чем те, с которыми мне приходится работать сейчас.
Моя игра и даже сам классический проект Freelancer анализировались по 10+ минут.
Для современных задач это уже неприемлемо, особенно если инструмент должен использоваться регулярно и как часть более крупного рабочего пайплайна.
Старый инструмент изначально был ориентирован на англоязычную среду и не был адаптирован под локализованные игровые проекты.
Мне нужен был инструмент, который можно нормально использовать в русскоязычной рабочей среде без постоянных костылей.
При открытии игровых данных, где информационные карты или другие текстовые данные содержали кириллицу, старый инструмент вместо текста показывал:
????????????????- мусорные символы
- сломанную текстовую разметку
Это делало часть данных либо плохо читаемой, либо вообще бесполезной для анализа.
В старой версии инструмента для ориентира в алгоритмах и структурах активно использовались XSD-описания ключевых классов.
Этот подход:
- морально устарел,
- неудобен в сопровождении,
- плохо масштабируется,
- и уже не соответствует нормальной современной разработке под .NET.
Старая структура проекта страдала от классической проблемы старых WinForms/WPF-инструментов:
- логика обработки,
- логика хранения,
- логика отображения,
- и события UI
часто находились в одном месте.
Например, в MainWindow.cs могло быть 2000+ строк, где всё было перемешано между собой.
Это сильно мешало:
- сопровождению,
- тестированию,
- рефакторингу,
- и добавлению новых функций.
Большая часть старой логики выполнялась последовательно, а не параллельно или асинхронно.
Из-за этого:
- долгие операции блокировали поток,
- UI страдал,
- масштабирование на больших игровых данных было плохим,
- а дальнейшее развитие проекта становилось мучительным.
Старый инструмент был слишком изолированным и плохо подходил для встраивания в более крупную инфраструктуру.
Мне не хватало возможности интегрировать его с:
- собственными сервисами античита,
- внутренними утилитами,
- синхронизацией с порталом Lizerium,
- и в целом с более современной инженерной экосистемой.
Проект был не просто слегка подчищен, а фактически переосмыслен и собран заново.
Проект был снят с синхронных рельсов и переведён в асинхронный режим работы.
Это дало возможность:
- не блокировать UI,
- ускорить обработку,
- лучше масштабироваться на больших данных,
- подготовить проект к более тяжёлым сценариям анализа.
Старый подход на базе:
DataSetDataTable- XSD-дизайнеров
был полностью удалён.
Причина простая:
XSD-дизайнеры официально не поддерживаются в .NET Core / .NET 5 / .NET 6 / .NET 7 / .NET 8, а значит строить современный проект вокруг них — плохая идея.
Вместо устаревшего DataSet-подхода проект был переведён на:
List<T>- POCO-классы
- DTO-модели
Это дало:
- более прозрачную структуру данных,
- читаемую сериализацию/десериализацию,
- лучшую тестируемость,
- нормальную поддержку рефакторинга,
- и более современный инженерный подход.
Проект был полностью переработан в сторону:
- MVP-паттерна
- сервисного слоя
- разделения ответственности
- более чистой и расширяемой структуры
При этом в проекте сознательно соблюдаются принципы:
- SOLID
- разделение UI и логики
- тестируемость
- переиспользуемость компонентов
Ключевая идея архитектуры здесь следующая:
Presenter отвечает за:
- сценарии работы,
- обработку действий пользователя,
- координацию сервисов,
- преобразование данных для отображения.
Он не должен зависеть от конкретной формы или конкретного окна.
View (например, MainWindow) должна отвечать только за:
- отображение данных,
- обработку событий интерфейса,
- передачу действий пользователя в Presenter.
Она не должна быть местом, где живёт вся бизнес-логика проекта.
Чтобы Presenter был:
- тестируемым,
- переиспользуемым,
- независимым от UI-фреймворка,
создаётся интерфейс IMainView, который описывает только то, что Presenter может вызвать на форме.
Это позволяет:
- не закапывать логику в UI,
- проще покрывать код тестами,
- легче рефакторить проект в будущем.
На текущем этапе проект уже ориентирован не просто на "старый редактор аккаунтов", а на более серьёзную инженерную основу.
- более быструю обработку игровых аккаунтов,
- корректную работу с кириллицей и текстовыми данными,
- расширение анализа игровых сущностей,
- интеграцию с внутренними сервисами,
- возможную связку с античитом,
- синхронизацию с инфраструктурой Lizerium,
- дальнейшую модульную переработку старых компонентов.
Этот проект основан на историческом наследии старого инструмента:
Менеджер аккаунтов игроков для Freelancer Server.
cannonjoshktstgt
Этот проект сыграл важную роль в своё время, и текущая переработка не пытается "стереть" это наследие, а наоборот — сохранить его смысл, но перенести в более современную форму.
Warning
Проект с большой долей вероятности находится в активной разработке.
Это означает, что:
- часть функционала может быть временно не возвращена,
- часть старых возможностей может быть ещё в процессе переноса,
- некоторые внутренние компоненты могут находиться в стадии перепроектирования.
Если вы наткнулись на проект на промежуточной стадии — это нормально.
Если вы хотите участвовать в развитии проекта — вы вправе:
- изучать структуру,
- предлагать улучшения,
- дорабатывать то, что я ещё не успел вернуть в рабочее состояние после обновления архитектуры.
В исторической основе проекта использовались алгоритмы, происхождение которых, вероятно, связано со следующими инструментами:
Вероятно использовались из:
flhash.exe- автор:
sherlog@t-online.de - дата:
2003-06-11
Вероятно использовались из:
flfachash.exe- автор:
Haenlomal - дата:
октябрь 2006
История обновлений проекта ведётся отдельно.
📄 См.: CHANGELOG.md
Проект распространяется в соответствии с лицензией, указанной в файле LICENSE.
Этот проект — не просто "старый менеджер аккаунтов, переписанный заново".
Это попытка:
- сохранить полезную инженерную основу старого инструмента,
- убрать технический долг,
- привести структуру к современному виду,
- и подготовить его к реальному использованию в больших игровых экосистемах.
И если раньше это был просто локальный утилитарный инструмент,
то теперь он движется в сторону полноценного, расширяемого и инженерно вменяемого приложения.