Как написать ядро для сервера майнкрафт

Как написать свое ядро для сервера майнкрафт — Сайт о Игре Minecraft

Как написать свое ядро для сервера майнкрафт — Советы и Инструкции

Как написать свое ядро для сервера майнкрафт

Написание собственного ядра для сервера Minecraft — это очень сложный и трудоемкий процесс, который требует глубоких знаний языка Java, архитектуры сервера Minecraft, опыта работы с API Bukkit и другими инструментами разработки. Однако, если вы все еще хотите попробовать свои силы, следуйте этим шагам:

Шаг 1: Установите необходимое ПО

Для разработки ядра сервера Minecraft вам потребуется использовать следующее ПО:

— Среда разработки Eclipse или IntelliJ IDEA;

— JDK (Java Development Kit);

— API Bukkit (для создания плагинов);

— Сборщик проектов Maven или Gradle.

Шаг 2: Создание нового проекта

Откройте среду разработки Eclipse или IntelliJ IDEA и создайте новый проект Java. Выберите версию JDK, которую вы хотите использовать. Добавьте API Bukkit в ваш проект и установите бесплатную лицензию.

Шаг 3: Написание кода

Вы можете начать с создания простого плагина, который добавляет новый предмет в игру. Для этого вам потребуется создать новый класс в проекте и наследовать его от класса JavaPlugin. Затем вы можете создать метод, который регистрирует новый предмет и добавляет его в игру.

Шаг 4: Тестирование и отладка

Запустите сервер Minecraft и тестирование вашего плагина. Если вы обнаружили ошибки в своем коде, используйте средства отладки вашей IDE для исправления их.

Шаг 5: Выпуск и дистрибуция

После того, как вы закончили разработку ядра сервера Minecraft, упакуйте его в плагин и опубликуйте его на площадке дистрибуции плагинов, таких как BukkitDev или SpigotMC.

— Начните с простых плагинов, а затем переходите к более сложным задачам.

— Изучайте API Bukkit и другие инструменты разработки, чтобы получить глубокие знания в области разработки серверов Minecraft.

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

ULE — самописное MC Java ядро. Часть #1.1 — HelloWorld и изменения…

2022-02-05 в 11:25, admin , рубрики: minecraft, minecraft java edition, minecraft server, Rust, сервер miencraft

Всем привет! Уже столько времени прошло с прошлой статьи, в которой я писал про реализацию своей небольшой версии, написанной на Go, как всегда исходный код доступен на GitHub . Сразу думаю сказать, что за это время успел уже перейти на линукс(Mint Cinnamon), получить проблемы с интегрированной GPU, но в конце концов наконец я смог нормально работать с редактором от JetBrains и сделать переход с Go на Rust, это было сделано так-как я думал изначально писать на расте, но было очень проблематично компилировать. Но вот и был сделан всё-таки переход с улучшениями как производительности так и возможностей!)

Причина перехода с Go на Rust

Изначально я задумывался о создании на нём, но не мог нормально скомпилировать код.

Теперь скорость можно измерять в наносекундах. )

Немного важных уточнений

При переходе на Rust я решил, что стоит делать по-умолчанию английский язык, так-как его знают большинство, а это значит если человек, который не знает русского — сможет вполне использовать, из-за этого все комментарии в статье и коде на GitHub будут написаны на английском языке, при этом может быть и много ошибок. Получилось так-же много файлов, но есть которые почти пустые и только обьединяют несколько модулей, поэтому такие файлы я не буду комментировать, а только оставлю код.

Продолжение #1.1

Код на расте вышел всё-таки в разы больше так-как я пытался использовать как можно больше своего, но всё-таки для лучшего результата использовал много, но важных библиотек и прописал их в Cargo.toml:

Как раз наш Cargo.toml является одним из основных файлов для проекта, а следющий по важности src/main.rs:

В нашем main.rs в самом начале инициализируем отсчёт времени, который вскоре будем использовать для показа время запуска. Потом мы пытаемся инициализировать логгер(fern + log), при неудаче — выводим ошибку и «убиваем» процесс. Следующим шагом у нас идёт создания некого канала, а после строки адресса сервера, но канал, который на самом деле выглядит по методам как UDP, но с блокировкой потоков, он нам нужен для ожидания основного потока, который ждёт результат запуска от потока сетевого сервера(TCP сервер), получилось — выводим информацию об успешном запуске сетевого сервера и за сколько времени запустилось, при ошибке — выводим информацию о проблеме запуска. Если получилось запустить наш TCP сервер, то удаляем наш канал связи и начинаем слушать ввод с консоли. Как видно есть типы SResul(из сокращения SimpleResult) и SimpleError, первый говорит сам за себя, как и второй, но для которого идёт приминение разных trait для показа ошибок.

Наш метод инициализации логгера лежит в файле src/utils/logger/input.rs, но я покажу так-же src/utils/mod.rs и src/utils/logger/mod.rs, так-как они зависимы: src/utils/mod.rs

Просто импортируем модули чата и логгера публично

Тут идёт импорт input.rs и log_lib.rs, а так-же экспорт методов start_input_handler и setup_logger

При инициализации логера мы в первую очередь удаляем файл последнего лога latest.log, потом устанавливаем на каждый уровень лога свой цвет(INFO = серый, WARN — жёлтый, ERROR — красный, TRACE — ярко-красный). Позже идёт инициализация самого логгера fern и для него мы устанавливаем формат: [ДАТА] [УРОВЕНЬ] СООБЩЕНИЕ, цвет имеет только уровень, а дата и сообщение стандартным цвветом консоли. Для логгера устанавливаем вывод в stdout(консоль вывода), минимальный уровень вывода — INFO, а так-же вывод в лог-файл и принимаем эти изменения. Если не было ошибок при этих действиях — возращяем успешный пустой результат.

Далее у нас через main.rs создаётся канал mpsc, который передаётся в другой поток сетевого сервера TCP и это делается через network_server_start из пакета network, который имеет много «пустых» файлов, но оттуда нам нужен лишь протокол, сервер, буферы и обработчики. Сам сетевой сервер располагается по пути src/network/server.rs:

Содержимое сетевого сервера

Да, уже целых 125 строчек, но это ещё мало

Протокол, обработка подключений, чтение и создание пакетов

Так-как ядро я пытаюсь сделать менее зависимым от библиотек, то для чата и протокола будет всё написано с 0 и для обеспечения большего контроля над чтением и записью.

Было решено хранить буферы пакетов в виде векторов к которым добавлены методы чтения и записи(только для Vec<u8>):

Тут мы можем наглядно увидеть чтение VarInt, String, Long и другое, что пока надо было при написании ядра.

Запись к буферам выглядит в разы интересней из-за больших требований к стандарту протокола MineCraft.

Обработчики пакетов на статусы 0(HandShaking) и 1(Status) расположены в одном файле src/network/handler.rs и в нём на каждый тип своя функция.

Вот например HandShaking:

Хоть функция и имеет 20 строчек, но в ней мы требуем лишь чтения первого пакета для определения следующего статуса ну и основное чтение пакета происходит в read_handshake_packet:

Функция чтения HandShake

Мы читаем пакет и при ошибке возращаем её, а если получилось прочитать полностью, то и возращаем результаты чтения.

Для обработки статуса у нас есть иная функция:

В ней снова при вызове в первую очередь проверяем на возможность не только чтения, но и записи так-как на этом этапе мы всегда отдаём некий результат. Снова читаем буффер и пытаемся прочитать его начал сохранив при этом айди пакета(0x00 — Список, 0x01 — Пинг-Понг) я так-же реализовал небольшой генератор буффера для списка:

Сам генератор ответа на список

Для него мы сначала используем информацию о том как должен выглядеть JSON ответа и для ответа мы делаем пустой буффер, записываем байты переведённой сструктуры в JSON и генерируем пакет с айди 0x00. Для серелизации используем serde и serde_json.

Если пингануть сервер, то можно увидеть будет результат. При получении пинг-понг мы просто отправляем копию буфера так-как это более экономный вариант так-как иначе бы пришлось читать Long и другое, что нагружало бы процессор и ОЗУ больше чем просто копия буффера.

Последнее. Input в консоли или же STDIN.

Последняя функция из main.rs — ввод комманд, пока он будет очень примитивный и иметь всего stop и вывод введённого. Так-как имеется не так много возможностей казалось бы, то и ничего важного не будет, но нет! Он будет нам блокировать основной поток приложения возволяя ему работать, ведь если основной поток будет остановлен, то и вся программа остановится. Поэтому как выглядит функция так:

Мы сначала создаём буффер и stdin, а так-же запускаем цикл в котором сначала очищаем буффер от прошлого ввода и потом блокируем поток в ожидании ввода. При получении ввода проверяем на содержмиое и если это stop, то устанавливаем сетевому серверу информацию о том, что надо выключать слушатель и дожидаемся выключения, но если за 6 секунд не произошло отключения — завершаем процесс с кодом 0, если же у нас была введена иная комманда, то просто выводим её в консоль с уровнем INFO, да, просто выводим.

Итог части #1.1

Данная часть была как-бы заменой #1 и в данной конечно из важного было:

Переход на Rust с языка Go

Основной язык проекта — Английский

Улучшение производительности в разы благодаря Rust

Создание логгера и ввода

Полная работа ядра пока в 2 потоках, а не как выходило в Go

Вот такие изменения я думаю стоили такого перехода, тем более учитывая, что Rust мне больше нравиться благодаря своей приближённости к устройству и отличная работа с ОЗУ:

Использование ресурсов при активном пинге Результат при пинге сервера. Почти тоже самое, что и в прошлой части.

Сервер пингуется легко, потребляя 128КБ на Linux, а на моём 4300U запускался за 735236ns.

Я надеюсь вам интересно читать статьи о разработке ядра и снова скажу:

Исходный код ядра доступен на GitHub и если вы хотите поддержать меня валютой, то у меня есть patreon.

Напишите можалуйста ваше мнение о моём процессе. Буду стараться отвечать на все.

Взаранее скажу, что плагины скоро буду вводить и они будут на основе WASM, скорее всего благодаря движку Wasmer.

Создание своего серверного ядра на Go для Minecraft Java. Часть #1 — Основное о идее и малое начало

Тема, которая будет писаться в многих частях будет в основном представлять этапы написания своего серверного ядра для мультиплеера популярной игры Minecraft.

Об игре Minecraft

Игра на данный момент имеет большую популярность среди многих людей, наверное зайдя на тот же ютуб вы можете встретить множество видео или стримов по этой игре, в неё играют люди разных возрастов. В ней вы можете играть как в одиночном режиме, так и мультиплеере. Мы будем разбирать конкретно мультиплеер так-как именно он позволяет играть людям вместе, где есть некоторые проблемы, но так-же и добавлять разнообразие в игру.

О серверах игры

В самой игре нет централизированной системы серверов, что позволяет создавать сервера где угодно, но чаще под них арендуют услуги хостинга. Сервера можно найти очень легко, например введя в поисковик гугл «Мониторинг майнкрафт серверов», а так-же вы можете и создать свой. В основе большенства серверов лежат ядра, которые в свою очередь основаны от одного ядра — Vanilla. Вот малый список ядер, которые часто использут: Paper, Purpur, Spigot, Sponge, Glowstone.

Программная часть серверов

Все ядра, которые были перечислены выше имеют одну и ту же проблемную зависимость — они написаны почти полностью на Java. Сам по себе этот язык классный, много классных особенностей, но в случае огромных проектов часто бывают проблемы например с потреблением ОЗУ, а уже процессор часто бывает второстепенный. Обычный сервер, без дополнений (плагины), при тех же 20-40 игроках может спокойно использовать и 1 или даже 2 гигабайта ОЗУ, а что же говорить о том, что при долгой работе без перезагрузок потребление может занимать и более 6ГБ ОЗУ. Поэтому находятся люди, которые пытаются создавать собственные ядра например на Rust ведётся разработка одного из таких ядер. Я же планирую по частям описывать создание своего ядра, но уже на Go.

Почему же Go?

Я не раз пробовал разные языки для всего подряд (да, даже PHP для серваков. ), но мне показался самым классным Go. В основном нравиться его простота, удобство и экосистема, ведь есть много классных библиотек. Так-же бы я выделил его производительность, ведь она тут очень замечательная.

Зачем?

Да просто :D. А если говорить по правде, то я просто давно хотел сделать, что-то интересное не только для меня, но и другим. А может даже и поможет это кому-то. Ну и конечно возможно это будет очень удобно использовать где-то у себя.

Перед началом

В данном посте я планирую сделать лишь основы, поэтому в следующей части будет больше интересного).

Сначала я бы хотел уточнить, что буду использовать Go последней версии (на момент поста 1.17.5), а так-же редактор GoLand от JetBrains и буду надеяться на вашу поддержу 🙂
Пока на самом начале сервер будет поддерживаться только на 1.12.2, потому-что моё супер вычислительное устройство очень плохо работает в связке GoLand + Minecraft 1.16.5 и выше.

Начало

Называться ядро пока-что будет именно ULE, поэтому будет инициализироваться проект в GoLand, создаём main.go в качестве запускатора.

Инициализация проекта

В качестве упрощения в создании будем использовать одну библиотеку для протокола игры. Она очень мощная, но из неё мне понадобиться только функционал для парсинга сообщений и чтении/записи пакетов, а так-же небольшой обработке игроков. Поэтому установим её таким образом:

go.mod после добавления go-mc

После чего данная библиотека будет автоматически добавлена в go.mod и мы сможем её использовать в нашем коде обращаясь по «github.com/Tnze/go-mc/».

Теперь для удобства я создам директорию server и в нём файл server.go со следующим содержимым:

Как мы видим для работы мы используем net из go-mc для подключений, а так-же принимаем их с помощью нашей функции acceptConnection, которая объявлена в server/accepter.go и её код уже такой:

Здесь вы можете уже заметить, что в списке инпутов есть свой пакет, в папке server/protocol/serverbound, а там находиться уже файл handsnake.go для «рукопожатий», но перед этим стоит разобрать код функции для принятия подключений, в ней мы пока используем при чтении только nextState, так-как в первой части будет готов только пинг и поэтому в обработке типа подключения из HandSnake мы используем только 1, который означает, что это пинг.

Далее по очереди у нас очень важный компонент в работе ядра — чтение HandSnake, который как описывал был расположен в server/protocol/serverbound/handsnake.go и всё что находиться в директории связанной с протоколом конечно будет всё, что с ним связано и делиться всё на ServerBound (для сервера) и ClientBound (для клиента), поэтому при таком разделении у нас будет именно чтение HandSnake со следующим содержимым:

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

После чтения HandSnake пакета мы так-же решаем что делать с ним и поэтому в accepter.go при обработке состояния при 1 — принимаем в виде пинга в функции acceptPing, но принятие пинга уже кому-то может составить проблему из-за большого кода, ведь тут вся функция пинга обходиться нам в server/accepter_ping.go не в 20 строчек:

Обошлось нам всё в 83 строчки. Наверное это ещё очень мало так-как под некоторое была выделена папка config в которой вскоре будет располагаться вся конфигурация, но пока поговорим о нашем любимом пинге. Принятый пинг-подключение мы читать будем не более 3-х раз так-как обычному клиенту этого хватить должно в большинстве случаев, но это и частично нас обезопасит от ping-аттак.. частично. ну ладно, если не получилось отправить пакет, то перестаём его обрабатывать, поэтому каждый раз прочитывая пакет мы так-же узнаём его тип, так-как:

0x00 — получение описания

0x01 — пинг игрока

И вот тут самое интересное, при пинге игрока нам надо просто возвращать отправленный игроком пакет, а вот уже при описании нам приходиться генерировать JSON из нашей структуры, но сама генерация идёт в функции listResp, но для неё у нас есть структура данных listRespPlayer, которая говорит частично за себя ведь она описывать игрока для ответа, другая структура в самой функции генерации ответа уже гораздо больше, которая соответствует минимальному стандарту ответа. Мы так-же устанавливаем в структуру значения по дефолту

И мы тут можем заметить, что идёт обращение к какому-то config, а это просто в корне проекта config/basic.go:

И в нём установлены некоторые дефолтные значения по типу версии протокола (для 1.12.2 версия протокола — 340), а так-же MOTD или же то что вы видите в виде текста под названием сервера.

Для генерации JSON из структуры используем json.Marshal, который может вывести ошибку и так-как он не должен выводить ошибку, то мы заканчиваем работу программы с ошибкой.

Вот и конец первой части истории о самописном серверном ядре для Minecraft Java. Весь исходный код доступен на GitHub. И я буду очень сильно надеяться на вашу поддержку.

В итоге первой части мы получили:

Результат пинга

При этом ядро пока использует 2.1МБ ОЗУ, но стоит учесть, что на Linux он будет использовать гораздо меньше так-как размер потребления указан на Windows 11.

Спасибо за прочтение статьи и скоро выйдет новая часть, посвящённая написанию своего ядра! 🙂

Как написать ядро для сервера майнкрафт

Completing the CAPTCHA proves you are a human and gives you temporary access to the web property.

What can I do to prevent this in the future?

If you are on a personal connection, like at home, you can run an anti-virus scan on your device to make sure it is not infected with malware.

If you are at an office or shared network, you can ask the network administrator to run a scan across the network looking for misconfigured or infected devices.

Another way to prevent getting this page in the future is to use Privacy Pass. You may need to download version 2.0 now from the Chrome Web Store.

Cloudflare Ray ID: 7197dfaacf982301 • Your IP : 178.175.135.34 • Performance & security by Cloudflare