Un serveur dédié Hytale n’est pas un simple “hébergement de partie”. C’est une pile Java complète, authentifiée, capable d’exécuter des mondes, des plugins et même une architecture multi-serveurs native. Ce guide couvre ce qui compte vraiment pour administrer un serveur : prérequis, commandes de démarrage, réseau QUIC/UDP, structure des fichiers, performance, plugins recommandés, et mécanismes de transfert entre serveurs.

Comment créer un serveur Hytale ?

1) Prérequis et dimensionnement

Configuration minimale

Un serveur Hytale peut tourner sur n’importe quelle machine disposant :

  • 4 Go de RAM minimum
  • Java 25 (LTS) obligatoire
  • CPU en x64 ou arm64

Cette base suffit pour des tests et de petits environnements. En production, la consommation dépend surtout de ce que font les personnes connectées, pas seulement de leur nombre.

Comprendre ce qui consomme quoi

Règles pratiques :

  • CPU : augmente avec le nombre d’entités actives (PNJ, créatures, scripts), et avec certaines charges de simulation.
  • RAM : augmente avec la surface de monde chargée, donc la distance d’affichage, et le fait que chacun explore dans une direction différente.

La JVM masque parfois les besoins réels. Un serveur peut “prendre” beaucoup de mémoire sans en avoir besoin, puis s’effondrer en charge à cause du ramasse-miettes (garbage collector). Si vous voyez le CPU grimper sans raison apparente, c’est souvent un signal de pression mémoire.

Bon réflexe : testez plusieurs valeurs de -Xmx pour forcer une limite nette et observer le comportement.

2) Installer Java 25 et vérifier la version active

Hytale exige Java 25 LTS. Adoptium (Temurin) est généralement privilégié pour sa distribution stable.

Vérifiez l’installation avec : java --version

Vous devez obtenir une sortie indiquant une version 25 LTS (ex. 25.0.1 LTS), sinon le serveur risque de ne pas démarrer ou d’être instable.

3) Récupérer les fichiers serveur

Deux méthodes existent. Elles servent le même but, mais pas le même usage.

Option A : copie manuelle depuis l’installation du Launcher

Avantage : rapide pour tester.
Inconvénient : pénible à maintenir à jour.

Chemins typiques :

  • 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

Dans ce dossier, vous trouverez :

  • un répertoire Server/
  • un fichier Assets.zip

Copiez Server/ et Assets.zip vers votre dossier de serveur dédié.

Option B : Hytale Downloader CLI

Avantage : adapté à la production, mises à jour plus propres.
Principe : outil en ligne de commande qui télécharge les fichiers serveur et assets, avec authentification OAuth2.

Commandes courantes :

  • Télécharger la dernière version : ./hytale-downloader
  • Afficher la version du jeu sans télécharger : ./hytale-downloader -print-version
  • Version de l’outil : ./hytale-downloader -version
  • Vérifier une mise à jour de l’outil : ./hytale-downloader -check-update
  • Choisir un fichier de sortie : ./hytale-downloader -download-path game.zip
  • Utiliser un canal : ./hytale-downloader -patchline pre-release
  • Désactiver le check auto : ./hytale-downloader -skip-update-check

4) Lancer le serveur : commandes et aide intégrée

Commande minimale : java -jar HytaleServer.jar --assets PathToAssets.zip

Le paramètre --assets doit pointer vers le bon chemin, pas vers un “exemple”. Sur Windows, cela ressemble souvent à C:\...\Assets.zip.

Pour voir la liste complète des options disponibles : java -jar HytaleServer.jar --help

Vous y trouverez notamment :

  • --bind (adresse/port d’écoute)
  • --auth-mode (authenticated/offline)
  • options de backup (fréquence, dossier)
  • options liées aux plugins, au diagnostic, etc.

5) Authentification obligatoire : ce que ça change

Après le premier démarrage, un serveur Hytale doit être authentifié. Sans cela, il ne peut pas communiquer correctement avec les services associés, et le système limite les abus.

Dans la console serveur : /auth login device

Le serveur affiche un code temporaire. Vous le saisissez sur : https://accounts.hytale.com/device

Une fois validé, la console confirme l’authentification en mode OAUTH_DEVICE.

Limite et comptes “provider”

Chaque licence Hytale autorise jusqu’à 100 serveurs. Au-delà, il faut soit d’autres licences, soit un statut spécifique de type “Server Provider”, avec une procédure d’authentification adaptée aux gros parcs.

6) Réseau : QUIC sur UDP, pas de TCP

Port par défaut

Le port par défaut est 5520.

Changer le port : java -jar HytaleServer.jar --assets PathToAssets.zip --bind 0.0.0.0:25565

Point clé : UDP uniquement

Hytale utilise QUIC au-dessus d’UDP. Cela implique :

  • redirection de port UDP sur votre routeur (si serveur derrière NAT)
  • règles de pare-feu UDP
  • aucun port-forward TCP requis pour l’accès au serveur

Diagnostic NAT

QUIC gère généralement bien le NAT, mais si des connexions échouent :

  • vérifiez que la redirection est bien en UDP, pas en TCP
  • certains NAT symétriques peuvent compliquer la donne côté serveur : un VPS ou un dédié réduit ce risque
  • côté client, même derrière CGNAT (fréquent sur mobile), la connexion fonctionne généralement

Exemples de règles pare-feu

Windows (Defender) :
New-NetFirewallRule -DisplayName "Hytale Server" -Direction Inbound -Protocol UDP -LocalPort 5520 -Action Allow

Linux iptables :
sudo iptables -A INPUT -p udp --dport 5520 -j ACCEPT

Linux ufw :
sudo ufw allow 5520/udp

7) Structure des fichiers : ce que vous devez surveiller

Répertoires importants :

  • .cache/ : cache de fichiers optimisés
  • logs/ : journaux du serveur
  • mods/ : mods/plugins installés
  • universe/ : mondes et données associées

Fichiers de contrôle :

  • config.json : configuration globale
  • permissions.json : droits et rôles
  • whitelist.json : liste autorisée
  • bans.json : bannissements

Univers et mondes

Les mondes sont stockés sous universe/worlds/. Chaque monde possède son propre config.json (seed, génération, règles PvP, sauvegarde, tick, etc.).

Détail d’architecture utile : chaque monde dispose de son thread principal, et délègue du travail parallèle à un pool de threads partagé. En clair, multiplier les mondes actifs peut augmenter la concurrence CPU, même si le serveur “tient”.

Attention aux modifications à chaud

Les fichiers JSON sont lus au démarrage, puis réécrits lorsque des actions ont lieu en jeu (permissions, listes, etc.). Modifier un JSON pendant que le serveur tourne peut être écrasé par une écriture automatique.

8) Performance : RAM, distance d’affichage et cache AOT

La distance d’affichage est le levier principal

C’est le facteur le plus corrélé à la RAM. Recommandation courante : plafonner à 12 chunks (384 blocs) pour préserver performance et lisibilité du gameplay.

Repère utile : Minecraft utilise souvent 10 chunks (160 blocs). 384 blocs côté Hytale correspondent à un rayon beaucoup plus large, donc à davantage de données actives. Si vous gardez les valeurs par défaut, attendez-vous à une empreinte mémoire plus élevée.

Ajuster la mémoire JVM

Augmenter -Xmx donne de l’air, mais trop haut peut aussi masquer des problèmes. L’approche propre est empirique : vous fixez une limite, vous observez logs, latence et CPU, puis vous itérez.

Accélérer le boot : AOT cache

Le serveur embarque un cache AOT (HytaleServer.aot) qui réduit le temps de démarrage en évitant une partie du “warmup” JIT.

Commande :
java -XX:AOTCache=HytaleServer.aot -jar HytaleServer.jar --assets PathToAssets.zip

9) Mods et plugins : installation, sécurité, métriques

Installer des mods

Les mods (souvent en .zip ou .jar) se placent dans mods/. Le serveur les charge au démarrage.

Désactiver Sentry en développement

Hytale utilise Sentry pour collecter des rapports de crash. En développement de plugins, vous n’avez aucun intérêt à remonter vos erreurs de test.

Désactivation :
java -jar HytaleServer.jar --assets PathToAssets.zip --disable-sentry

Plugins souvent cités côté hébergeurs

Des partenaires comme Nitrado et Apex Hosting maintiennent des plugins orientés exploitation :

  • WebServer : base pour exposer des APIs ou outils web
  • Query : statut serveur et métriques simples via HTTP
  • PerformanceSaver : ajuste dynamiquement la view distance selon la charge
  • PrometheusExporter : métriques JVM/serveur détaillées pour monitoring

10) Architecture multi-serveurs native : transferts sans “proxy” obligatoire

Hytale propose des mécanismes intégrés de routage de connexions. Cela évite de reproduire un schéma type BungeeCord pour les besoins basiques.

Player referral : transférer un joueur déjà connecté

Le serveur d’origine envoie une “référence” contenant hôte, port, et un payload optionnel (jusqu’à 4 Ko). Le client ouvre une nouvelle connexion et présente ce payload au handshake.

Signature d’API :
PlayerRef.referToServer(host, port, data)

Sécurité : le payload transite via le client, donc il peut être altéré. Si vous y mettez un contexte de session, signez-le (HMAC avec secret partagé, par exemple) pour que le serveur cible puisse vérifier l’authenticité.

Usages typiques : lobby → serveur de jeu, matchmaking, transfert d’état léger, contrôle d’accès.

Évolution annoncée : possibilité d’indiquer une liste de cibles à tester, pour gérer des fallbacks.

Redirect au handshake : forcer une redirection avant connexion complète

Lors de l’établissement de la connexion, un serveur peut refuser et rediriger automatiquement vers un autre serveur.

API :
PlayerSetupConnectEvent.referToServer(host, port, data)

Usages : répartition de charge, routage régional, imposer un passage par un lobby.

Fallback après déconnexion

Si un serveur tombe ou si la connexion casse, le client peut reconnecter automatiquement vers un serveur de secours, au lieu de revenir au menu.

Usages : ramener vers un lobby après crash, absorber des redémarrages, limiter la frustration.

Évolution annoncée : paquet de fallback “first-party” attendu peu après le lancement en accès anticipé.

Construire un proxy personnalisé

Si vous voulez une couche intermédiaire, elle doit parler QUIC. Une approche mentionnée est d’utiliser Netty QUIC pour décoder et relayer du trafic. Les définitions de paquets et la structure du protocole sont disponibles dans le jar serveur, sous :
com.hypixel.hytale.protocol.packets

11) Compatibilité protocolaire : contraintes et fenêtre de mise à jou

Le protocole Hytale utilise un hash de compatibilité. Si client et serveur ne correspondent pas exactement, la connexion est rejetée.

Conséquence immédiate : lors d’une mise à jour, un serveur doit suivre vite, sinon les personnes passées sur la nouvelle version ne peuvent plus rejoindre.

Évolution annoncée : tolérance de versions avec une fenêtre de ±2 versions, pour laisser un délai de mise à jour sans couper l’accès.

12) Détails d’écosystème : dépendances, discovery, paiements, DNS

Publication Maven Central

Le jar serveur doit être publié sur Maven Central afin de servir de dépendance pour des projets de modding. Les détails de versioning sont attendus au moment du lancement, mais l’intention est de fournir une base officielle standardisée.

Server discovery et catalogue

Une fonctionnalité annoncée vise à intégrer un catalogue accessible depuis le menu principal, avec opt-in côté opérateurs. L’inscription s’accompagnerait :

  • de règles opérateurs et standards communautaires
  • d’un système de self-rating, utilisé pour filtrage et contrôle parental
  • de mesures d’enforcement si le contenu ne correspond pas au rating déclaré

Détail notable : les “player counts” affichés par le discovery seraient dérivés de la télémétrie client, pas du chiffre déclaré par le serveur. Objectif : empêcher le spoofing et rendre les chiffres plus fiables.

Parties

Un système de groupes persistants, capable de suivre les transferts et les files d’attente. Le catalogue de serveurs afficherait les contraintes de taille, pour éviter les surprises.

Paiements intégrés

Une passerelle de paiement côté client, que les serveurs peuvent utiliser sans gérer eux-mêmes les données de paiement. Côté opérateur, cela réduit la complexité. Côté utilisateurs, cela évite les sites tiers et centralise la traçabilité.

SRV records : pas encore

La connexion via domaine sans port (SRV DNS) est évoquée mais non supportée pour l’instant. Une justification technique est avancée : manque de bibliothèque C# jugée suffisamment robuste pour une feature réseau centrale, sans embarquer un client DNS complet trop lourd.

APIs first-party

Les serveurs authentifiés devraient accéder à des endpoints officiels pour :

  • résolution UUID ↔ nom, en unitaire et en bulk
  • versioning et check d’update
  • profils publics (cosmétiques, rendu d’avatar, etc.)
  • télémétrie serveur pour discovery
  • reporting ToS
  • paiements

Points “sous considération” :

  • sanctions globales plateforme
  • liste d’amis (avec permissions)
  • webhooks (changement de pseudo, sanctions, etc.)

Objectifs : rate limits généreux, endpoints bulk, réponses cache-friendly, accès authentifié, API versionnée avec fenêtres de dépréciation.

5 / 5 - (3 votes)

Vous aimerez aussi