← Blog

Configurer les fichiers de son serveur de jeu : le guide des reglages

Par Benjamin D. · PDG

· Mis à jour le 11 septembre 2026 · Lecture 10 min

Sommaire

La configuration serveur de jeu est ce qui distingue une partie fade d'une aventure qui retient ses joueurs plusieurs mois. Tout se joue dans quelques fichiers texte : multiplicateurs de ressources, courbe d'expérience, difficulté des ennemis, pénalités de mort, rythme des cycles. Ce guide explique comment lire, modifier et valider ces réglages proprement, jeu par jeu, sans casser une sauvegarde en cours.



Où vivent les réglages et comment fonctionne une configuration serveur de jeu

Chaque moteur de jeu a sa propre logique, mais on retrouve toujours trois familles de paramètres :

  • Les paramètres de démarrage (arguments de la ligne de commande) : port, nom de la partie, mot de passe, monde chargé, mémoire allouée. Ils sont lus une seule fois au démarrage du processus.
  • Les fichiers de configuration persistants : server.properties, GameUserSettings.ini, serverconfig.xml, PalWorldSettings.ini, sandboxvars.lua. C'est là que vivent la difficulté, les taux de récolte et la progression.
  • Les valeurs stockées dans le monde : seed, biomes générés, listes d'engrammes déjà débloqués. Modifier le fichier ne réécrit pas toujours ces données rétroactivement.

Sur un panel Pterodactyl, tu retrouves ces fichiers dans le gestionnaire de fichiers, et les arguments de démarrage dans l'onglet de démarrage. Si tu administres une partie Minecraft, la page dédiée hébergeur Minecraft détaille l'environnement technique dans lequel ces fichiers sont manipulés. Pour le reste du catalogue, Tous nos serveurs de jeu reprend les mêmes principes d'accès aux fichiers.

La règle d'or : arrêter le processus avant d'éditer

Presque tous les serveurs de jeu réécrivent leurs fichiers de configuration à l'extinction. Si tu édites GameUserSettings.ini pendant que le serveur tourne, il écrasera ton travail en s'arrêtant. La séquence correcte est toujours la même :

  1. Arrêter le serveur depuis la console du panel (arrêt propre, pas kill).
  2. Déclencher une sauvegarde manuelle en plus des sauvegardes automatiques.
  3. Éditer le fichier, une modification thématique à la fois.
  4. Redémarrer et vérifier dans la console qu'aucune ligne n'est rejetée.

Vérifier la syntaxe avant de redémarrer

Une virgule oubliée dans un fichier Lua ou un guillemet mal fermé dans un XML empêche le démarrage. Pour les formats structurés, un contrôle en ligne de commande sur la machine évite dix minutes de debug :

# valider un JSON de configuration (FiveM, plugins, modpacks)
python3 -m json.tool server-data/config.json > /dev/null

# valider un XML (7 Days to Die)
xmllint --noout serverconfig.xml

# valider un script Lua (Project Zomboid)
luac -p Zomboid/Server/monserveur_SandboxVars.lua


Régler la difficulté, les ressources et la progression selon sa communauté

Avant de toucher un multiplicateur, définis le profil de ta communauté. Un groupe de dix amis qui joue deux heures le soir n'a pas les mêmes besoins qu'un serveur public à cinquante connectés. Trois profils couvrent la majorité des cas.

Profil Objectif Orientation des réglages
Groupe privé, sessions courtes Voir du contenu vite Récolte x3 à x5, XP x2, apprivoisement accéléré, pénalité de mort allégée
Serveur public semi-hardcore Progression méritée, économie stable Récolte x1,5 à x2, XP x1,5, décomposition active, PvP encadré par horaires
Serveur hardcore / roleplay Tension permanente Taux officiels ou inférieurs, loot rare, mort punitive, whitelist obligatoire

Minecraft : server.properties

Le fichier est un simple couple clé/valeur. Les paramètres qui changent réellement la sensation de jeu :

difficulty=hard
hardcore=false
pvp=true
spawn-protection=16
view-distance=8
simulation-distance=6
max-players=40
white-list=true
enforce-whitelist=true
player-idle-timeout=15
allow-flight=false

view-distance et simulation-distance ne sont pas seulement du confort visuel : ce sont les deux leviers les plus lourds sur le temps de tick. Sur une partie moddée dense, descendre simulation-distance à 5 ou 6 rend souvent plus de fluidité que n'importe quel réglage de mémoire. La liste exhaustive des clés est documentée sur le wiki de référence.

ARK : GameUserSettings.ini et Game.ini

ARK sépare les réglages généraux (GameUserSettings.ini) des réglages fins de courbes et de loot (Game.ini). Une base solide pour un serveur communautaire :

[ServerSettings]
DifficultyOffset=1.0
OverrideOfficialDifficulty=5.0
XPMultiplier=2.0
TamingSpeedMultiplier=5.0
HarvestAmountMultiplier=3.0
ResourcesRespawnPeriodMultiplier=0.5
StructureResistanceMultiplier=1.0
PlayerCharacterFoodDrainMultiplier=0.8
ServerPVE=False
ServerCrosshair=True
AllowThirdPersonPlayer=True
ShowMapPlayerLocation=True
EnablePvPGamma=False

OverrideOfficialDifficulty=5.0 fixe le niveau maximal des créatures sauvages à 150. C'est le réglage que les joueurs remarquent en premier, bien avant les multiplicateurs de récolte. Attention : il ne s'applique pas aux créatures déjà générées, un wipe des dinos sauvages est nécessaire pour qu'il prenne effet partout. Les particularités de chaque version sont détaillées sur les pages Serveur ARK Survival Evolved et Serveur ARK Survival Ascended.

Palworld : une seule ligne, beaucoup de pièges

Tous les réglages tiennent sur une ligne unique dans PalWorldSettings.ini. Une parenthèse mal placée et le serveur repart sur les valeurs par défaut sans prévenir :

OptionSettings=(Difficulty=None,DayTimeSpeedRate=1.000000,
NightTimeSpeedRate=2.000000,ExpRate=2.000000,PalCaptureRate=1.500000,
PalSpawnNumRate=1.200000,CollectionDropRate=2.000000,
EnemyDropItemRate=1.500000,DeathPenalty=ItemAndEquipment,
bEnablePlayerToPlayerDamage=False,bEnableFriendlyFire=False,
GuildPlayerMaxNum=8,ServerPlayerMaxNum=24)

Le réflexe utile : copier la ligne dans un éditeur, compter les parenthèses, puis recoller. Et vérifier après redémarrage que les valeurs sont bien actives en jeu, pas seulement dans le fichier. NightTimeSpeedRate à 2 raccourcit les nuits sans toucher au rythme de la journée : c'est un des réglages les plus appréciés sur les parties familiales.

Valheim : les modificateurs de monde

Valheim se configure principalement par arguments de démarrage, avec le système de world modifiers :

./valheim_server.x86_64 -nographics -batchmode \
  -name "Communaute Nord" -port 2456 -world "MidgardPublic" \
  -password "motdepasse-solide" -crossplay \
  -preset normal \
  -modifier combat hard \
  -modifier resources more \
  -modifier portals casual \
  -modifier deathpenalty casual

Combiner combat hard et deathpenalty casual donne un excellent compromis : les combats restent tendus, mais une mort n'anéantit pas une soirée entière. Les détails de mise en œuvre sont sur la page Serveur Valheim.

7 Days to Die : serverconfig.xml

<property name="GameDifficulty" value="3"/>
<property name="BloodMoonFrequency" value="7"/>
<property name="BloodMoonEnemyCount" value="8"/>
<property name="LootAbundance" value="125"/>
<property name="LootRespawnDays" value="30"/>
<property name="XPMultiplier" value="150"/>
<property name="DropOnDeath" value="1"/>
<property name="LandClaimSize" value="41"/>
<property name="MaxSpawnedZombies" value="64"/>

MaxSpawnedZombies et BloodMoonEnemyCount sont à la fois des réglages de difficulté et des réglages de charge CPU. Monter le second à 16 sur une partie à vingt joueurs génère une charge d'IA considérable la nuit de lune de sang. Monte progressivement, en observant le comportement du serveur. Voir Serveur 7 Days to Die.

Project Zomboid : sandboxvars.lua

SandboxVars = {
    Zombies = 3,              -- 1 insane ... 4 normal ... 6 none
    Distribution = 1,
    DayLength = 3,
    StartMonth = 7,
    WaterShut = 4,
    ElecShut = 4,
    LootRespawn = 4,
    XpMultiplier = 2.0,
    ZombieRespawnHours = 72.0,
    NightDarkness = 2,
}

Dans Project Zomboid, la population de zombies déjà générée persiste dans les chunks explorés. Un passage de Zombies = 4 à Zombies = 2 ne repeuple pas immédiatement la carte : l'effet se ressent sur les zones neuves et au fil des respawns.



Appliquer les changements sans casser la partie en cours

Le vrai risque n'est pas la mauvaise valeur, c'est la mauvaise méthode d'application. Trois catégories à distinguer :

Type de réglage Prise en effet Exemples
Immédiat au redémarrage Rétroactif sur tout le monde Taux de récolte, XP, PvP on/off, difficulté d'un mob à venir
Appliqué aux nouvelles entités Nécessite un respawn ou un wipe partiel Niveau des créatures sauvages, abondance du loot en conteneur
Figé à la génération du monde Nécessite un nouveau monde Seed, taille de carte, biomes, type de terrain

Annoncer avant de modifier

Un changement de multiplicateur modifie l'économie de ta communauté. Doubler les ressources dévalue le stock des anciens joueurs ; les diviser par deux frustre les nouveaux. La bonne pratique : annoncer 48 h à l'avance sur Discord, indiquer précisément quelles valeurs changent, et garder l'ancienne configuration dans un fichier de secours.

# conserver une copie datée avant chaque modification
cp GameUserSettings.ini GameUserSettings.ini.$(date +%F)

# comparer deux versions pour retracer un réglage
diff -u GameUserSettings.ini.2025-01-12 GameUserSettings.ini

Utiliser le contrôle d'accès comme un réglage de difficulté

La whitelist n'est pas seulement un outil de modération : c'est un paramètre de gameplay. Sur un serveur hardcore, elle filtre les joueurs qui ne liront pas les règles et évite les vagues de nouveaux comptes après chaque raid. Côté Minecraft :

whitelist add Pseudo
whitelist reload
whitelist on

# limiter les commandes sensibles
op PseudoAdmin
deop PseudoTest

Pour Rust, l'essentiel du réglage des taux passe par des plugins Oxide plutôt que par des convars natives, ce qui impose de valider les versions de plugins après chaque mise à jour forcée du jeu. Détails sur Serveur Rust. Pense aussi à protéger les accès RCON avec un mot de passe long et unique, jamais réutilisé ailleurs.



Faire tenir la configuration serveur de jeu dans le temps

Un fichier de réglages bien pensé, c'est un fichier documenté, versionné et surveillé. Trois habitudes suffisent.

1. Documenter chaque valeur non standard

Dans les formats qui l'autorisent, ajoute un commentaire expliquant pourquoi une valeur a été choisie. Six mois plus tard, personne ne se souvient de la raison d'un TamingSpeedMultiplier=7.0. Pour les formats sans commentaires (INI d'ARK, ligne unique de Palworld), tiens un fichier CHANGELOG-config.txt à côté :

2025-01-12 | XPMultiplier 1.5 -> 2.0 | progression trop lente signalee en vocal
2025-01-20 | OverrideOfficialDifficulty 4.0 -> 5.0 | wipe dinos sauvages effectue
2025-02-02 | view-distance 10 -> 8 | pics de tick au-dela de 25 joueurs

2. Corréler réglages et performances

Beaucoup de plaintes de lag viennent d'un réglage, pas de la machine. Les paramètres à surveiller en priorité, quel que soit le jeu : distance de simulation, nombre maximal d'entités, nombre de créatures apprivoisées par tribu, taux de respawn des ressources, fréquence de sauvegarde automatique. Une sauvegarde toutes les 60 secondes sur une carte volumineuse crée un micro-freeze récurrent ; passer à 300 secondes lisse l'expérience tout en restant sûr.

# Rust : espacer les sauvegardes et cadrer la population
+server.maxplayers 120
+server.saveinterval 300
+decay.upkeep true

Le stockage NVMe et un CPU Ryzen à haute fréquence absorbent une bonne partie de ces à-coups, mais aucun matériel ne compense une distance de simulation surdimensionnée couplée à des milliers d'entités actives. La console live du panel permet de relire les temps de tick juste après un changement : c'est le seul juge fiable.

3. Reprendre la configuration après chaque mise à jour

Les mises à jour majeures ajoutent des clés, en renomment, en déprécient. Après un patch, ouvre le fichier de référence généré par le jeu et compare-le à ta version : tu y trouveras les nouvelles options par défaut que tu n'as pas encore réglées. La documentation du panel (Source) précise comment isoler les variables d'environnement des fichiers persistants pour éviter qu'une réinstallation ne réécrive tes réglages. D'autres guides de réglages par jeu sont regroupés sur le Blog Fly-Serv.

Checklist avant de rouvrir aux joueurs

  • Sauvegarde manuelle datée effectuée et téléchargée en local.
  • Syntaxe validée (JSON, XML, Lua) avant redémarrage.
  • Console relue sur les 50 premières lignes de démarrage, aucun warning de clé inconnue.
  • Test en jeu des deux ou trois valeurs modifiées, pas seulement lecture du fichier.
  • Changement annoncé à la communauté, ancienne version conservée.
  • Mots de passe administrateur et RCON distincts et longs.


Ce qu'il faut retenir

Régler les fichiers d'un serveur, c'est un travail d'itération : une modification thématique à la fois, une sauvegarde avant, une vérification en jeu après. Documente tes valeurs, surveille l'impact sur les temps de tick et écoute les retours de tes joueurs. Une communauté reste fidèle à une expérience cohérente, pas à des multiplicateurs extrêmes.



FAQ

Pourquoi mes modifications dans GameUserSettings.ini disparaissent-elles après un redémarrage ?

Parce que le serveur réécrit ce fichier lorsqu'il s'arrête : si tu édites pendant qu'il tourne, la version en mémoire écrase la tienne. Arrête complètement le processus depuis la console du panel, attends la fin de l'extinction, puis édite et redémarre. Vérifie aussi que les mêmes clés ne sont pas forcées via les variables de démarrage, qui prennent le dessus sur le fichier.

Un changement de difficulté s'applique-t-il aux créatures et au loot déjà présents ?

Rarement. Les niveaux des créatures sauvages et le contenu des conteneurs sont déterminés à leur génération. Après avoir augmenté la difficulté, il faut déclencher un respawn (commande de wipe des créatures sauvages sur ARK, délai de LootRespawnDays sur 7 Days to Die) pour que les nouvelles valeurs s'appliquent partout. Les taux de récolte et d'expérience, eux, sont immédiats.

Quels réglages toucher en premier quand les joueurs signalent du lag ?

Commence par la distance de simulation et la distance de rendu, puis la fréquence des sauvegardes automatiques, le nombre maximal d'entités actives et le plafond de créatures par groupe. Modifie une seule valeur à la fois et relis les temps de tick dans la console live après dix minutes de jeu réel, sinon tu ne sauras pas quel changement a produit l'amélioration.