Чтобы мы хотели от лаунчеров проектов Minecraft?

Добрый вечер, RuBukkit!

С вами Alrott SlimRG. Много лет уже занимаюсь созданием различных лаунчеров, модов и т.д и т.п. для Minecraft. Еще несколько лет назад планировал написать OpenSource лаунчер для Minecraft, но что-то не срослось (да-да, я в итоге продал его одному проекту, да-да, знаю, что я жадная жопа)

Сегодня хотел бы написать первые строки нового лаунчера и хотелось бы узнать, каким вы, обычные люди, хотели бы видеть лаунчер Minecraft?

Будет хорошо, если все это будет в виде дискуссии, можно рисовать, писать все свои идеи и мнения.
Взамен, постараюсь реализовать все это в принципиально новом лаунчере Minecraft и выложить его в GitHub и сюда

 

Нормальный лаунчер действительно нужен.

Что бы хотелось:

- Отсутствие зависимости от Java. Лаунчер должен быть нативным - один бинарник без зависимостей. Electron и .NET Core 3 отпадают, т.к. их бинарники - лишь контейнеры, распаковывающие гору файлов во временные папки.

- Небольшое потребление памяти - не больше 50-70 мегабайт для насыщенного анимированного дизайна.

- Экономный бинарный, но расширяемый двусторонний протокол. Сервер должен уметь отправлять лаунчеру пакеты, что позволит впоследствии создавать системы мониторинга игроков. И, как следствие, нужна возможность легко создавать и отправлять кастомные пакеты с произвольными бинарными данными внутри.

- Общая скорость работы. 2020й год, а в лаунчерах до сих пор используют md5 для проверки файлов. Для чего? t1ha, wyHash, xxHash - работают практически на скоростях оперативки (особенно два первых). 64х-битного и даже 32х-битного хэша с головой хватит для проверки файла. Кроме того, получаем огромную экономию размера на передаче списка валидных хэшей от сервера лаунчеру.

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

- API для возможности расширять лаунчер и вебчасть, если дефолтных фич не хватает.

- Простота вёрстки дизайна.

------

Теперь про сами фичи. Думаю, для большинства серверов будет достаточно такого списка:
- Авторизация с HWID'ами
- Поддержка авторизации во всех современных CMS
- Возможность разворачивать сервер без сайта
- Установка скинов и плащей
- Скачивание файлов в многопотоке
- Поддержка опциональных модов
- Поддержка разных серверов для выбранных групп пользователей (например, у группы "тестеры" в списке серверов есть сервера, которых нет у других игроков)
- Максимально гибкая проверка файлов без привязки к иерархии клиента (проверка по маскам, поддержка рекурсивного обхода папок, поддержка исключений)
- Поддержка общих папок для разных серверов (например, общие assets'ы, общие libraries, natives и т.д. - разумеется, с произвольной иерархией)
- Произвольный формат строки запуска и аргументов джавы с возможностью переопределить аргументы джавы для каждого клиента и для каждой архитектуры (win32/win64/linux32/linux64/macos)
- Запуск игры через JNI. Незачем создавать отдельный процесс, когда игру можно запустить в контексте лаунчера. Плюсик к скорости и безопасности.
- Защита. Спорный вопрос. Не уверен, что защита из коробки нужна вообще. Ни одна из существующих паблик-защит не защищает ни от чего, такое нет смысла даже ставить. Админы, вероятно, захотят использовать пересобранную джаву - все встроенные в лаунчер защиты будут только мешать. Если и делать - как отдельный и полностью отключаемый модуль.

 

Полностью согласен, хотел использовать Qt с C++17 - вес небольшой, зато скомпилировать можно хоть под мультиварку, хоть под тостер ... Но все же, может вы посоветуете нормальный ЯП и библиотеку.
Что думаете об использовании Vulkan API для анимации?

При очень маленьких размерах можно забыть о модульных проектах и некоторых видах защиты, а также плюшек. Мне больше нравится идея модульных лаунчеров. Т.е. проект разбит на подпроекты. Это улучшит скорость разработки (все же будет на GitHub) и улучшит кастомизацию, а также привнесет все прелести совместного программирования.
50 MB же - это немалый расход памяти, как оперативной, так и жесткой (если конечно не использовать растровую ерись)
Также поясните, пожалуйста, вы про оперативную или долговременную память?

Я тоже о этом же думал. Но можно несколько поподробней изложить свои мысли. Думаю, здесь вы знаете намного больше меня, хоть я и фанат Бруса Шнайера, и хотелось бы почерпнуть немного ваших идей)

Полностью согласен, думал о wyHash или xxHash

Согласен с частотой. Но вот только мастхэв - тут вопрос с подвохом. Понимаете, что одному сироп - другому смертельный яд. Именно поэтому я планирую создать модульный проект. Нужна DLE - заинклудил DLE модуль, нужен WordPress - заинклудил другой, нужна панель новостей или радио - заинклудил, а не нужно - так и нечего этому делать в конечном бинарнике. Это удобно (пример - PCSX2, где я также активный участник), хоть и вес самого проекта и порог вхождения немного выше, чем у монолитных проектов (хотя порой такая солянка бывает в монолитах, что черт голову на дантик завернет)

Полностью согласен, но хотел бы добавить - с нормальной документацией на 2х языках (RU/ENG)

Здесь хотелось бы почитать поподробней, т.к. дизайнер из меня (студент МАИ, технарь) не ахти. Думал сделать аналог HTML+CSS+Events

Просто и элегантно - полностью согласен

Благодаря модульности - это будет реализуемо, даже если не мной, так другими участниками (главное не накосячить с API для взаимодействия)

Можно поподробней, не совсем вас понял.

Это понятно, но все равно - спасибо, думаю, смогу реализовать

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

 

Именно на Qt я и намекал. Превосходный фреймворк, отвечающий всем требованиям, что я написал.
Но у конечных пользователей со сборкой будут большие проблемы. Чтобы Qt не требовал зависимостей, его нужно собрать в статике. А значит, надо собирать и OpenSSL. И всё это проделать для каждой платформы.
В итоге, процесс сборки получится очень нетривиальным. Чтобы упростить, можно закинуть исходники и скрипты сборки в докер. Но, в любом случае, сборка такого лаунчера не будет простой.

В Qt всё из коробки. Если будешь делать рендеринг вручную на DirectX/OpenGL/Vulkan, то, во-первых, лаунчер ты никогда не закончишь, а во-вторых, его станет невозможно поддерживать. Писать кастомный рендер - очень плохая идея.

Не согласен. В первую очередь, лаунчер должен быть платформой, конструктором, а не готовым решением. В самом лаунчере функций мало: скачать и проверить файлы и запустить игру. Это не займёт много места и не загромоздит код.
Модульность? API, так или иначе, уже разделяет код на модули. Например, движок для проверки файлов, диспетчер пакетов и т.д. - независимые блоки, которые не привязаны к вызывающей их стороне.

Про оперативную. Заготовка подобного лаунчера на Qt/QML с эффектами, 3D-скином и кастомным скейлинговым шейдером (масштабирование текстурок скинов по ближайшим соседям) у меня ест ~70 мб, оттуда и цифры. Думаю, вполне адекватный жор за предоставляемые возможности.

Пусть будет общение с сервером или по чистому TCP, или по вебсокетам (у каждого свои плюсы и свои минусы, я пока остановился на вебсокетах из-за поддержки cloudflare и из-за того, что сервер пишу на Go, используя fasthttp, равных которому по скорости пока нет). У каждого пакета будет фиксированной длины заголовок, ориентируясь на который, диспетчер пакетов сможет понять, что это за пакет и как его парсить.
Например, в своих пакетах я использую однобайтовый заголовок:
A BBB CCCC
Где A - бит, определяющий, запрос это или ответ, BBB - 3 бита типов пакета (авторизация, запрос файла, запрос инфы о серверах и т.д., включая КАСТОМНЫЙ пакет с расширенным хедером), а CCCC - 4 бита порядкового номера пакета, чтобы сопоставлять ответы запросам (таким образом, от одного клиента одновременно в обработке может находиться 2^4 = 16 пакетов, что более, чем достаточно).
А следом за хедером - тело пакета. Я делаю порядок полей фиксированным, но можно для каждого поля ввести свой хедер, и порядок полей может быть произвольным. Я решил, что мне этот оверхед не нужен (и парсить фиксированно идущие поля проще).
Примерно в таком ключе у меня сделаны все пакеты протокола.

А подумай лучше о t1ha. wyHash чуть быстрее, но рискует потерять энтропию, а xxHash медленнее тихи.

Поддерживаю. У себя думаю в сторону полной кастомизации запросов, чтобы вообще не привязываться к CMS.

Да, разумеется.

Т.к. юзаю Qt, то использование QML и есть та самая простота вёрстки. Но для кого-то удобнее верстать на html/css, и здесь подойдут фреймворки, типа Ultralight. Можно и в Qt верстать на html, используя WebView на основе хромиума, но, имхо, это уже изврат. А в Qt 6.0 наконец-то сделают QML полностью нативным. Осталось подождать полтора года... Так что, для меня выбор в пользу QML очевиден.

Запуск вебчасти в отсутствие базы.
Это больше к вопросу о поддержке бэкендов: модуль для MySQL, модуль для SQLite, модуль для какой-нибудь простейшей самописной бд (хоть сырые std::map'ы, сброшенные в бинарный файлик) - позволит без какой-либо предварительной настройки окружения поднять рабочую вебчасть.

 

Спасибо

 

Почему не Java?) ХКС, вайм и множество других проектов юзают лаунчер именно на этом яп. Если уж тема касается читов, то тут скорее проблема в нативной защите.

 

А зачем писать на джаве? Разве она даст хоть какие-то преимущества перед нативным кодом?

С ходу недостатки:
- Неудобно работать с нативными компонентами (джава кроссплатформенная, нативки - тащить свои для каждой платформы)
- Зависимость от предустановленной джавы, из-за чего приходится писать, опять же, нативный лоадер, который скачает сначала джаву для запуска лаунчера - шило на мыло
- В контексте одного процесса нельзя запустить игру и выделить память, не перезапуская лаунчер

Что получаешь от нативного:
- Такая же кроссплатформенность
- Цельный продукт - всё происходит в контексте одного процесса
- Нет зависимости от окружения
- Не надо тащить дллки, всё в одном бинарнике для конкретной платформы
- Быстрый запуск, экономия памяти

 

Тут скорее удобство конечного юзера. В том же javaFx можно легко сменить дизайн не пересобирая лаунчер.
А кому то просто важнее игроки, нежели нативные защиты. К лаунчеру на чистой java без нативок больше доверия.
И подписывать не надо, параноики просто скачают jar вместо exe.

 

Добавлю

1. Конечному пользователю хочется скачать, запустить и играть. А не возиться с установкой Java
2. Вытекает из первого. Но предположим у пользователя linux, macOS или, упаси Господи, какая-нибудь другая малоизвестная ОС, где есть JVM, но ее надо ставить.
3. У многих пользователей слабые компьютеры или интернет, поэтому устанавливать софт для запуска софта для запуска игры - по мне - немного непрактично. Come ON, у меня самого есть Ativ Smart PC, который хорошо справляется с игрой на минималистах, но лаунчер Сашка на нем лагает как....
4. Однообразие рынка. Уже есть лаунчер на Java, которому уже много лет и, которой, успешно поддерживается кучей пользователей. Не думаю, что смогу с ним конкурировать на первых порах, да и зачем?

 

К слову, практически всегда у игроков уже стоит джава, поэтому конкретно это проблемой не будет

 

На текущий момент это логично, но новое поколение не играют в маин, потому что сложнаАААААА
Да и вообще не вижу в установке ничего хорошего
Плюс, по себе знаю, как не играл в него около полугода, т.к. лень было Java ставить на линукс

 

В любом случае, я тоже исключительно за нативную реализацию

 

Полностью плюсую. Сейчас тот же тлаунчер уже всем ее проставил. А игроки всегда начинают играть с ванильных серверов через него.

 

Чел на линуксе = мусор, такие уже точно не задонатят.
Там сидят кодеры либо хакеры, или нищеброды с пунктиком "Я не пират". Можно сразу на них забивать.

 

Ну вот - обосрали linux...
Ой, все...

 

Никто не обсирал. Кодеры идут на линуск из за удобства в кодинге, а читеры из за отсутствия защиты.
А простые игроки все на форточке. Ибо им такое извращение не требуется.

 

Это обидно, знаете ли
У меня 2й системой стоит Windows 10 Pro
Более того, я знаю кучу народу с маками, что также обделены

 

И как много из этой кучи маководов донатил в кубиках? Уверен, околоникто.

 

А при чем здесь донаты?
Если бы я писал лаунчер ради донатов и т.д. и т.п., то я бы точно не стал бы писать его OpenSource.
Я такой человек, который больше работает за идею, нежели коммерцию.
Плюс, макаводы обычно при деньгах, если на то пошло. .

 

Ну если ты сможешь написать защиту от читов под мак и линукс. Че и нет.