Официальный Hytale Server Manual описывает установку, конфигурацию и эксплуатацию dedicated-серверов Hytale. Материал рассчитан на администраторов серверов и игроков, которые хостят выделенный сервер самостоятельно.
Данная статья написана опытным Администратором Петром (for_users), является переводом официального мануала по созданию Hytale сервера от HyPixel Studios.
Заглядывайте на хостинг ХайТейл BungeeHost — тарифы появятся в самом скором времени.
Без хостинга всё описанное ниже не будет нести никакого смысла — сервер должен работать круглосуточно и выдерживать нагрузки, а на обычных пользовательских ПК нет даже элементарного белого айпи — компьютер здесь точно не является вариантом для размещения сервера.
Содержание мануала (о чём будет статья)
В руководстве выделены разделы: Server Setup, Running a Hytale Server, Tips & Tricks, Multiserver Architecture, Misc Details и Future Additions. Ниже эти темы изложены в виде цельной инструкции: от требований и установки Java до сети (UDP/QUIC), структуры файлов, модов и многосерверной архитектуры.
Мы подробно перескажем официальный мануал о том, как создать свой сервер HyTale
Требования к серверу Hytale
Сервер Hytale может работать на устройстве с минимум 4 ГБ памяти и Java 25; поддерживаются архитектуры x64 и arm64. В мануале отдельно рекомендуется мониторить RAM и CPU под вашу реальную нагрузку, потому что потребление ресурсов сильно зависит от количества игроков и их поведения.
Общее правило из руководства:
- CPU чаще всего упирается в высокий онлайн или большое количество сущностей (NPC/мобы).
- RAM чаще всего уходит при большой загруженной области мира (высокая дальность прорисовки и игроки, которые расходятся и исследуют мир независимо).
Также отмечено, что без специализированных инструментов сложно точно понять, сколько памяти “на самом деле” нужно Java‑процессу, поэтому предлагается экспериментировать с -Xmx, задавая явные лимиты. Типичный симптом нехватки памяти — рост нагрузки на CPU из‑за сборщика мусора (GC).
Как создать свой сервер HyTale — НАЧАЛО:
Установка Java 25 (обязательно)
Для сервера требуется Java 25, а в качестве рекомендуемого дистрибутива указана Adoptium (Temurin). После установки нужно проверить версию командой java --version и убедиться, что вывод соответствует Java 25 (в примере-— Temurin OpenJDK 25.0.1 LTS).
Где взять файлы сервера Hytale
В мануале описаны два способа получить серверные файлы.
Вариант 1: вручную скопировать из установки лаунчера
Этот способ рекомендован для быстрого тестирования, но его неудобно поддерживать в актуальном состоянии. Файлы находятся в папке установки лаунчера:
- Windows:
%appdata%\Hytale\install\release\package\game\latest - Linux:
$XDG_DATA_HOME/Hytale/install/release/package/game/latest - macOS:
~/Application Support/Hytale/install/release/package/game/latest
Из этой директории нужно скопировать папку Server и файл Assets.zip в папку вашего сервера.
Вариант 2: Hytale Downloader CLI (для продакшена)
Для production-серверов мануал рекомендует использовать Hytale Downloader CLI, потому что так проще поддерживать файлы в актуальном состоянии. Это CLI‑утилита, которая скачивает сервер и ассеты с OAuth2‑аутентификацией; подробности запуска описаны в QUICKSTART.md внутри архива.
В тексте перечислены команды утилиты, включая: скачивание последнего релиза, вывод версии, проверку обновлений, скачивание в заданный файл, выбор канала pre-release, пропуск авто‑проверки обновлений. Архив загрузчика указан как hytale-downloader.zip (Linux & Windows) с домена downloader.hytale.com.
Запуск сервера Hytale (команда старта)
Сервер запускается командой вида:java -jar HytaleServer.jar --assets PathToAssets.zip. То есть серверному JAR нужно передать путь к ассетам (Assets).
Аутентификация сервера ХайТейл (обязательный шаг)
После первого запуска сервер нужно аутентифицировать. В мануале показан сценарий device‑authorization: команда /auth login device, затем выдаётся URL accounts.hytale.com/device и код, который вводится в браузере; после подтверждения сервер сообщает об успешной аутентификации (OAUTH_DEVICE).
Отдельно сказано, что серверная аутентификация нужна, чтобы включить связь с сервисными API и противодействовать злоупотреблениям. Также указан лимит: до 100 серверов на одну игровую лицензию Hytale для предотвращения раннего абьюза; для большего масштаба предлагается покупать дополнительные лицензии или подавать заявку на Server Provider account. Для массовой/автоматической аутентификации серверов отсылают к отдельному гайду “Server Provider Authentication Guide”.
Полный список параметров запуска HyTale (help)
В руководстве предлагается смотреть все аргументы командой:java -jar HytaleServer.jar --help. В примере --help выводит параметры, включая --assets, --auth-mode, --bind, а также параметры автоматических бэкапов (--backup, --backup-dir, --backup-frequency) и флаг подтверждения ранних плагинов (--accept-early-plugins) с предупреждением о возможной нестабильности.
Какой порт сервера, привязка и сеть
Порт сервера Хайтейл по умолчанию — 5520, а изменить его можно через аргумент --bind. В примере показано, как поставить порт 25565: --bind 0.0.0.0:25565.
Важно: Hytale использует QUIC по UDP, не TCP
Мануал подчёркивает, что Hytale использует протокол QUIC поверх UDP, поэтому firewall и проброс портов нужно настраивать именно для UDP, а не для TCP.
На хостингах HyTale, по типу BungeeHost, это всё делается автоматически за Вас.
Что сказано про сеть:
- Если сервер за роутером, нужно пробросить UDP‑порт 5520 (или ваш кастомный порт) на машину с сервером; TCP‑проброс не нужен.
- Приведены примеры правил firewall:
Про NAT отдельно отмечено: QUIC обычно хорошо работает с NAT traversal, но если у игроков проблемы — проверьте, что проброс сделан именно под UDP; симметричный NAT может мешать и тогда лучше VPS/выделенный сервер; клиенты за carrier‑grade NAT (часто на мобильных сетях) обычно подключаются нормально.
Если у Вас не куплен белый айпи, это всё равно не несёт никакого смысла — Ваш сервер будет невидем без интернета. Нужен нормальный хостинг.
Структура файлов сервера HyTale (папки и конфиги)
В мануале перечислена структура директорий и файлов. Основные пути и их смысл:
.cache/— кэш оптимизированных файлов.logs/— логи сервера.mods/— установленные моды.universe/— данные мира и сохранения игроков.bans.json— забаненные игроки.config.json— конфигурация сервера.permissions.json— конфигурация прав.whitelist.json— белый список.
Структура мира (universe/worlds)
Указано, что universe/worlds/ содержит все игровые миры, и у каждого мира есть собственный config.json. В руководстве также говорится, что каждый мир работает на своём main thread и выносит параллельную работу в общий thread pool.
Tips & Tricks (моды, AOT, Sentry, плагины, view distance)
Установка модов на сервер HyTale
Моды предлагается скачивать в формате .zip или .jar из источников вроде CurseForge и класть в папку mods/.
Отключение Sentry при разработке
В мануале есть важное предупреждение: во время активной разработки плагинов нужно отключать Sentry crash reporting, чтобы не отправлять разработческие падения. Для этого указан флаг --disable-sentry в команде запуска.
Использование Ahead-Of-Time (AOT) cache в HyTale
У сервера есть предобученный AOT cache HytaleServer.aot, который ускоряет запуск за счёт пропуска JIT‑прогрева; в тексте дана ссылка на JEP‑514 и пример запуска с -XX:AOTCache=HytaleServer.aot.
Дальность прорисовки (View Distance) и производительность сервера ХайТейл
В руководстве сказано, что view distance — главный драйвер потребления RAM. Рекомендация: ограничить максимальную view distance до 12 чанков (384 блока) ради производительности и геймплея. Для сравнения приведено, что в Minecraft по умолчанию 10 чанков (160 блоков), а дефолт Hytale (384 блока) примерно эквивалентен 24 Minecraft‑чанкам, поэтому ожидается более высокий расход RAM при дефолтных настройках и это нужно тюнить под ожидаемый онлайн.
Мультисерверная архитектура Hytale (без BungeeCord)
Мануал утверждает, что Hytale поддерживает нативные механизмы маршрутизации игроков между серверами и для этого не нужен reverse proxy вроде BungeeCord. Описаны три механизма и отдельная опция “строить прокси”.
Player Referral (перевод игрока на другой сервер)
Referral переводит уже подключённого игрока на другой сервер: сервер отправляет пакет с host/port и опциональной нагрузкой до 4 КБ, клиент открывает новое соединение и передаёт payload в handshake. Есть предупреждение безопасности: payload идёт через клиент и может быть изменён, поэтому его нужно криптографически подписывать (например, HMAC с общим секретом), чтобы принимающий сервер мог проверить подлинность.
Use cases, которые указаны:
Также отмечено “Coming Soon”: массив целей, которые будут пробоваться по очереди как fallback.
Connection Redirect (редирект при подключении)
На этапе handshake сервер может отклонить подключение и отправить клиента на другой сервер, и клиент автоматически подключится к новому адресу. Use cases: балансировка нагрузки, маршрутизация по регионам, принудительное подключение сначала в лобби.
Disconnect Fallback (фолбэк при разрыве)
Если игрок неожиданно отключён (краш сервера или сетевой обрыв), клиент автоматически переподключается к заранее настроенному fallback‑серверу вместо возврата в меню. Use cases: возвращать в лобби после краша game‑сервера и удерживать игрока во время рестартов. Также указано “Coming Soon”: реализация fallback‑пакета ожидается в течение недель после запуска Early Access.
Building a Proxy (собственный прокси)
Предлагается строить кастомные прокси на базе Netty QUIC, потому что Hytale использует QUIC исключительно для client‑server трафика. Указано, что определения пакетов и структура протокола доступны внутри HytaleServer.jar в пакете com.hypixel.hytale.protocol.packets, чтобы декодировать/инспектировать/модифицировать/форвардить трафик между клиентами и backend‑серверами.
Misc Details: JVM, протокол, конфиги, Maven Central
JVM аргументы HyTale
В тексте дана ссылка на гайд по важным JVM‑параметрам (включая -Xms и -Xmx для heap). В контексте сервера это нужно, чтобы контролировать память Java‑процесса.
Обновления протокола и совместимость
Описано: протокол Hytale использует hash для проверки совместимости клиента и сервера, и если хэши не совпадают — подключение отклоняется. Текущее ограничение: клиент и сервер должны быть на точно одинаковой версии протокола; при обновлении серверы должны обновляться сразу, иначе игроки на новой версии не зайдут. “Coming Soon”: толерантность протокола с допуском ±2 версии, чтобы у операторов было окно на обновление без потери онлайна.
Ждём появления ViaVersion плагина, как в Майнкрафте?)
Файлы конфигурации сервера HyTale и перезапись
Сказано, что конфиги (config.json, permissions.json и т. п.) читаются при старте сервера и записываются сервером при внутриигровых действиях (например, выдача прав через команды). Поэтому ручные правки конфигов “на горячую” во время работы сервера, скорее всего, будут перезаписаны.
Публикация артефакта на Maven Central
Указано, что HytaleServer.jar будет опубликован в Maven Central для использования как dependency в моддинговых проектах; точные детали версионирования обещаны ближе к релизу.
Future Additions: что добавят позже
В разделе Future Additions перечислены планируемые функции и ограничения “на сейчас”.
Server & Minigame Discovery (каталог серверов HyTale)
Планируется каталог (из главного меню), где игроки смогут находить серверы и мини‑игры, а операторы смогут опционально добавлять сервер в каталог для продвижения. Для листинга описаны требования: соблюдение правил оператора/стандартов сообщества, честная self‑rating (для фильтров и родительского контроля) и меры enforcement при нарушениях. Отдельно отмечено: отображаемый онлайн в каталоге будет подтверждаться клиентской телеметрией (а не данными сервера), чтобы избежать “накрутки” числа игроков; при этом сервер сможет показывать непроверенный онлайн тем, кто добавил сервер вне каталога.
Parties (группы игроков) в ХайТейл
Планируется party‑система, чтобы игроки могли оставаться вместе при переходах между серверами и очередями мини‑игр. Также описана интеграция с discovery: партия сможет просматривать и заходить на серверы вместе, а ограничения по размеру партии будут видны заранее.
Встроенные платежи (Integrated Payment System) в HyTale
Планируется платёжный шлюз внутри клиента, который сервера смогут использовать для приёма оплат (опционально, но “поощряется”). В руководстве перечислены плюсы для операторов (не нужно хранить платёжные данные и строить инфраструктуру) и для игроков (без внешних сайтов, безопасно и отслеживаемо).
Ну привет, Роблокс)
SRV-записи (DNS) — пока не поддерживаются
Планируется поддержка SRV, чтобы подключаться по домену без указания порта, но текущий статус: не поддерживается и “under evaluation”. Причина, указанная в тексте: нет “battle-tested” C# библиотеки для SRV‑резолва, а альтернативы либо тянут полноценный DNS‑клиент (лишняя сложность и риски), либо недостаточно готовы для продакшена.
Официальные API endpoints HyTale (First‑Party)
Для аутентифицированных серверов планируются официальные API для данных игроков, версий и операций сервера, чтобы снизить зависимость от сторонних сервисов. Перечень планируемых endpoint’ов включает: UUID↔Name, Game Version, Player Profile, Server Telemetry, Report, Payments. “Under Consideration” перечисляет: Global Sanctions, Friends List, Webhook Subscriptions. Также описаны design goals: щедрые rate limits, обязательная аутентификация и версионированный API с окнами депрекаций.
Ожидайте возможности запуска сервера через Minecraft / HyTale Хостинг BungeeHost
Добавить комментарий