Guide complet des gamerules de Minecraft
Bonjour !
Les gamerules (ou règles de jeu) sont des options personnalisables qui permettent de modifier le comportement d’un monde Minecraft sans installer de mod. Introduite initialement en version Minecraft 1.4.2, la commande /gamerule donne aux administrateurs la possibilité d’ajuster de nombreux paramètres du jeu en vanilla. En fin de lecture de ce guide, vous saurez à quoi sert chaque gamerule et comment les utiliser, que vous soyez débutant ou admin expérimenté.
Qu’est-ce qu’une gamerule et comment la modifier ?
Une gamerule est un paramètre stocké pour chaque monde Minecraft, qui influence le gameplay. Par exemple, certaines gamerules permettent de désactiver la pluie, de conserver son inventaire après la mort, ou d’empêcher les monstres de faire des dégâts au terrain. Ces options n’affectent que le monde dans lequel elles sont définies, et non l’ensemble du jeu.
Il existe deux façons principales de configurer les gamerules :
- Lors de la création du monde (Java Edition uniquement) – Sur Minecraft Java, un menu “Règles de jeu” est disponible lors de la création d’un monde (avant de lancer la partie). Ce menu classé par catégories propose des interrupteurs pour activer/désactiver certaines gamerules ou définir des valeurs par défaut. Cet écran simplifie l’édition des gamerules avant de jouer. (Note : Ce menu complet n’existe pas dans l’interface de Minecraft Bedrock, qui ne propose que quelques options basiques dans les paramètres du monde.)
- En utilisant la commande
/gamerule en jeu (Java et Bedrock) – Une fois le monde créé, ou sur un serveur, vous pouvez modifier les gamerules à tout moment avec la commande dédiée. La syntaxe est :
- par exemple :
/gamerule doDaylightCycle false. Le nom de la règle n’est pas sensible à la casse (Java) et la valeur est soit un booléen (true ou false), soit un entier selon la gamerule. Utilisez cette commande dans le chat (avec les droits de triche activés ou en étant OP sur un serveur) ou dans la console du serveur. Pour consulter la valeur actuelle d’une règle sans la modifier, entrez simplement /gamerule sans valeur.
Astuce : Certaines gamerules sont également accessibles via les options du jeu. Par exemple, sur Bedrock, une partie des gamerules courantes figurent dans les paramètres de la partie (onglets “Monde” ou “Triche”), mais d’autres ne sont modifiables que par commande. Sur Java, il faudra de toute façon utiliser la commande une fois le monde lancé (ou éditer le fichier server.properties pour quelques réglages serveur, comme le PvP).
Remarque sur les versions : Chaque gamerule peut être propre à Java, à Bedrock, ou aux deux. Nous l’indiquerons pour chacune ci-dessous. De plus, certaines gamerules n’existent que depuis une certaine mise à jour du jeu (ou ont été retirées) : nous préciserons la version d’introduction pour les règles ajoutées en cours de route. Par exemple, doInsomnia (gestion des fantômes) est apparue en 1.15. À l’inverse, la gamerule obsolète announceAchievements a été supprimée en 1.12 et remplacée par announceAdvancements avec le nouveau système d’avancements.
Maintenant, passons en revue la liste complète des gamerules de Minecraft, avec leur utilisation et comment les configurer.
Gamerules liées aux joueurs et à la mort
Ces gamerules modifient des aspects du jeu concernant le joueur, sa survie et son expérience de mort/réapparition.
keepInventory (Java & Bedrock, introduite en 1.4.2) : Permet de conserver son inventaire après la mort si activée (true). Par défaut, elle est désactivée (false), ce qui fait que le joueur lâche tous ses objets à sa mort. Lorsque keepInventory est activée, les joueurs gardent aussi leurs points d’expérience en mourant. (La santé, la faim et les effets de potion sont tout de même réinitialisés normalement.)naturalRegeneration (Java & Bedrock, introduite en 1.6.1) : Contrôle la régénération naturelle de la santé. Par défaut à true (activée), elle permet aux cœurs de remonter si la barre de faim est suffisante. Si vous la désactivez (false), les joueurs ne regagneront plus de vie naturellement et devront utiliser d’autres moyens (potions, pommes dorées, etc.) pour se soigner.doImmediateRespawn (Java & Bedrock, introduite en 1.15) : Permet de réapparaître instantanément sans afficher l’écran de mort. Par défaut false (comportement normal avec menu de mort). En la passant à true, le joueur respawn immédiatement après sa mort. (Sur Bedrock, cette gamerule s’appelle immediateRespawn sans le préfixe “do”.)showDeathMessages (Java & Bedrock, introduite en 1.4.2) : Gère l’affichage des messages de décès. Par défaut true, le jeu affiche dans le chat un message quand un joueur meurt (y compris un message au propriétaire d’un animal apprivoisé si celui-ci meurt). Si mis à false, ces messages de mort sont supprimés du chat.drowningDamage (Java & Bedrock, introduite en 1.15) : Gère les dégâts de noyade. Par défaut true, le joueur perd des cœurs en suffoquant sous l’eau une fois sa barre d’oxygène vide. Si réglé sur false, le joueur ne prendra plus de dégâts de noyade (il continuera cependant de perdre sa réserve d’air).fallDamage (Java & Bedrock, introduite en 1.15) : Gère les dégâts de chute. À true par défaut, le joueur subit des dégâts en cas de chute de hauteur suffisante. En la désactivant (false), les chutes n’infligent plus de dommages aux joueurs, ce qui peut être utile pour un mode créatif ou pour éviter la frustration des chutes mortelles.fireDamage (Java & Bedrock, introduite en 1.15) : Contrôle les dégâts liés au feu, à la lave, aux feux de camp ou aux blocs de magma. Par défaut true, un joueur prendra des dégâts s’il est en feu ou s’il touche de la lave. Réglé sur false, le joueur peut prendre feu visuellement mais ne subira aucun dégât dû aux flammes.freezeDamage (Java & Bedrock, introduite en 1.17) : Gère les dégâts de gel dus à la neige poudreuse. Par défaut true (les joueurs non protégés par des bottes en cuir subissent des dégâts de gel s’ils restent dans la neige poudreuse). Si on la désactive, le joueur ne perdra plus de cœurs en cas d’hypothermie.pvp (Bedrock uniquement) : Permet d’activer ou désactiver le Player versus Player. À true par défaut, les joueurs peuvent se blesser et s’entretuer. En mettant cette gamerule à false sur Bedrock, les joueurs ne peuvent plus se taper les uns les autres (les coups n’infligent plus de dégâts entre joueurs). (Note: Sur Java Edition, le PvP se désactive via le fichier server.properties et non via une gamerule.)spawnRadius (Java & Bedrock, introduite en 1.9) : Définit le rayon (en nombre de blocs) autour du point d’apparition mondial où les joueurs peuvent apparaître la première fois qu’ils rejoignent le serveur ou lorsqu’ils meurent sans lit. Par défaut, ce rayon est de 10 blocs sur Java (ce qui signifie qu’un nouveau joueur spawn aléatoirement dans un carré de 21×21 centré sur le spawn) et 5 blocs sur Bedrock. Augmenter cette valeur élargit la zone d’apparition possible des nouveaux joueurs. (Sur les serveurs dont le mode par défaut est Aventure, ce rayon n’a pas d’effet.)
Gamerules liées aux créatures et aux monstres
Ces gamerules contrôlent le comportement de spawn des mobs (monstres, animaux, PNJ) et la façon dont ils interagissent avec le monde ou le joueur.
doMobSpawning (Java & Bedrock, introduite en 1.4.2) : Gère l’apparition naturelle des mobs dans le monde. Par défaut true, des monstres et animaux apparaissent aléatoirement dans les zones sombres ou biomes appropriés. En mettant doMobSpawning sur false, aucun mob ne spawn naturellement. Attention : cela n’affecte pas certains spawns scriptés comme les mobs générés par les spawners ou par les structures (manoirs, bastions, etc.), qui continueront d’apparaître normalement.doInsomnia (Java & Bedrock, introduite en 1.15) : Contrôle l’apparition des phantoms (créatures volantes hostiles qui attaquent les joueurs n’ayant pas dormi depuis 3 nuits). Par défaut true, les phantoms apparaissent la nuit au bout de quelques jours sans sommeil. Si réglé à false, aucun phantom ne spawn plus du tout, quelle que soit l’insomnie des joueurs.doPatrolSpawning (Java uniquement, introduite en 1.15.2) : Gère l’apparition des patrouilles de pillards (Illager patrols) dans le monde. Par défaut true, de petits groupes de pillards peuvent apparaître occasionnellement dans l’Overworld en tant que patrouilles. Si mis à false, les patrouilles illageoises n’apparaîtront plus du tout.doTraderSpawning (Java uniquement, introduite en 1.15.2) : Gère l’apparition du marchand ambulant (Wandering Trader). Par défaut true, un marchand ambulant apparaît périodiquement près des joueurs. En désactivant cette règle (false), les marchands ambulants ne spawnent plus naturellement dans le monde.doWardenSpawning (Java uniquement, introduite en 1.19) : Permet d’activer ou non l’apparition des Wardens dans les villes antiques des Deep Dark. Par défaut true, un Warden peut émerger du sol si un sculk shrieker est déclenché assez de fois. Si vous la désactivez (false), aucun Warden ne pourra apparaître, même en provoquant des cris dans le noir.mobGriefing (Java & Bedrock, introduite en 1.4.2) : Contrôle si les mobs peuvent modifier le terrain ou interagir avec les objets. Par défaut true, de nombreuses créatures peuvent agir sur le monde : par exemple, les creepers détruisent des blocs en explosant, les endermen peuvent ramasser et déplacer certains blocs, les zombies ou piglins zombifiés peuvent tenter d’écraser les œufs de tortue, les villagers ramassent de la nourriture et plantent des graines, etc.. En réglant mobGriefing sur false, aucune créature ne pourra altérer le terrain ou ramasser d’objets. (Les creepers n’abîmeront plus le sol, les endermen ne voleront plus de bloc, les villageois ne pourront plus rien récolter, etc. – cela affecte aussi le comportement des Allays, Blazes, Withers, etc., qui ne pourront plus interagir avec le monde lorsqu’on désactive cette règle.)disableRaids (Java uniquement, introduite en 1.14.3) : Active ou désactive les raids de pillards sur les villages. Par défaut false (les raids sont autorisés). Si vous mettez disableRaids sur true, aucun raid ne se déclenchera même si un joueur affecté par Mauvais Présage entre dans un village. En outre, si un raid est en cours et que vous basculez cette gamerule à true, le raid en cours s’arrêtera (les vagues suivantes ne se lanceront pas, bien que les pillards déjà présents ne disparaissent pas automatiquement). Astuce : En activant cette gamerule, l’effet Mauvais Présage ne sera pas consommé en entrant dans un village, ce qui permet d’éviter complètement les raids sans perdre l’effet.universalAnger (Java uniquement, introduite en 1.16) : Si activée (true), cette règle fait en sorte que les mobs neutres en colère (ex : loups, Piglins, abeilles) attaquent n’importe quel joueur à proximité, et pas uniquement celui qui les a agressés. Par défaut false, une créature neutre n’en veut qu’au joueur qui l’a frappée. Avec universalAnger:true, toute personne passant à proximité d’un mob énervé risque de se faire attaquer. (Conseil : cette règle est plus efficace en désactivant parallèlement forgiveDeadPlayers.)forgiveDeadPlayers (Java uniquement, introduite en 1.16) : Fonctionne de pair avec la précédente. Par défaut true, lorsque le joueur ciblé par un mob neutre (p.ex. un Enderman en colère) meurt ou s’éloigne suffisamment, la créature abandonne sa vengeance et redevient passive. Si on passe forgiveDeadPlayers à false, les mobs neutres restent en colère même après la mort ou la déconnexion du joueur visé, et ils continueront d’attaquer d’autres joueurs à vue. (Exception : les Piglins oublieront quand même une agression si le joueur responsable met une armure en or entre-temps, et les golems de fer liés à un village pardonnent toujours les joueurs devenus trop impopulaires.)
Gamerules liées au monde et à l’environnement
Ces gamerules affectent les cycles du temps, la météo, l’apparition de phénomènes naturels ou encore certains aspects des explosions dans le monde.
doDaylightCycle (Java & Bedrock, introduite en 1.6.1) : Contrôle le cycle jour/nuit. Par défaut true, le temps s’écoule normalement (jour, nuit, phases de lune). Si réglé sur false, le soleil et la lune cesseront de bouger, figeant l’heure du jour à son état actuel. Utile pour avoir un monde en plein jour permanent, ou au contraire dans une nuit éternelle.doWeatherCycle (Java & Bedrock, introduite en 1.6.1) : Semblable à la précédente, mais pour la météo. Par défaut true, la météo change naturellement (pluie, orage) selon le cycle normal. Désactivée (false), le temps restera figé dans son état actuel (cela n’empêche pas d’utiliser manuellement la commande /weather pour changer la météo si besoin).randomTickSpeed (Java & Bedrock, introduite en 1.8) : Détermine la fréquence des ticks aléatoires par chunk. Les ticks aléatoires contrôlent de nombreux phénomènes naturels comme la croissance des plantes, la propagation de l’herbe ou l’apparition du feuillage mort. Par défaut, cette valeur est de 3 sur Java et 1 sur Bedrock. Une valeur plus élevée accélère tous ces processus (par ex. un randomTickSpeed de 6 double la vitesse de croissance des cultures). À l’inverse, mettre 0 ou une valeur négative désactive complètement les ticks aléatoires (aucune plante ne poussera naturellement). Notez que des valeurs très élevées peuvent entraîner des accélérations extrêmes : au-delà de ~4096, la croissance des plantes ou la décomposition des feuilles deviennent instantanées, ce qui peut causer des ralentissements du jeu.doFireTick (Java & Bedrock, introduite en 1.4.2) : Contrôle si le feu se propage et s’éteint naturellement. Par défaut true, le feu suit les règles normales (il peut se répandre aux blocs inflammables voisins et finit par s’éteindre seul sur les blocs non alimentés). En mettant doFireTick sur false, le feu ne se propage plus du tout et ne s’éteint pas automatiquement. Cela signifie qu’un incendie allumé restera confiné à son bloc initial (et y brûlera indéfiniment tant qu’il y a de quoi brûler). Utile pour éviter que la foudre ne déclenche des feux de forêt, par exemple.doVinesSpread (Java uniquement, introduite en 1.19.4) : Gère la propagation des lianes. Par défaut true, les lianes (celles de la jungle) peuvent pousser et s’étendre sur les côtés des blocs adjacents. En désactivant cette règle, les lianes classiques cesseront de s’étendre. (Note : Ceci n’affecte pas les différentes variantes de lianes introduites plus tard comme les lianes des cavernes, les lianes suintantes du Nether ou les lianes tordues – elles suivent toujours leurs propres mécaniques.)snowAccumulationHeight (Java uniquement, introduite en 1.19.3) : Définit l’épaisseur maximale de couches de neige pouvant s’accumuler sur un bloc lorsqu’il neige. La valeur par défaut est 1 (une seule couche, le comportement classique). En l’augmentant (par ex. 8), la neige pourra s’amonceler en couches plus épaisses au fil des chutes de neige, jusqu’à ce plafond. Mettre 0 empêcherait toute accumulation de neige au sol, au-delà de la couche initiale déposée.waterSourceConversion (Java uniquement, introduite en 1.19.3) : Permet d’autoriser ou d’interdire la création de sources d’eau infinies. Par défaut true (comportement normal : deux blocs d’eau côte à côte peuvent en former un troisième entre eux, etc.). En passant cette gamerule à false, l’eau ne formera plus de nouvelles sources – les seules sources d’eau seront celles déjà présentes, ce qui rend l’eau finie (comme c’est le cas de la lave en temps normal). En d’autres termes, on ne peut plus créer de “puits infini” avec deux seaux d’eau.lavaSourceConversion (Java uniquement, introduite en 1.19.3) : Semblable à la précédente, mais pour la lave. Par défaut false car la lave ne crée normalement pas de source infinie. La passer à true permettrait, en théorie, de générer de nouvelles sources de lave adjacentes (comme on peut le faire avec l’eau). (Note : Même activée, la lave reste une ressource limitée dans la plupart des cas, sauf mécanisme particulier — cette option est donc rarement utilisée.)globalSoundEvents (Java uniquement, introduite en 1.19.3) : Par défaut true. Cette règle influe sur certains événements sonores qui, normalement, sont entendus par tous les joueurs peu importe la distance. Par exemple, la mort de l’Ender Dragon ou l’allumage d’un portail du Nether produisent un son global sur le serveur. En mettant globalSoundEvents à false, ces sons spéciaux ne seront plus audibles que localement (près de la source). Cela peut servir à un administrateur souhaitant masquer ces indices sonores aux joueurs éloignés.respawnBlocksExplode (Bedrock uniquement, introduite en 1.17.30) : Gère l’explosion des lits et des ancres de réapparition dans les dimensions où ils ne sont pas censés être utilisés. Par défaut true (sur Bedrock, comme sur Java, un lit explosera si on tente de dormir dedans dans le Nether ou l’End, idem pour une ancre de réapparition utilisée hors du Nether). En passant cette règle à false sur Bedrock, les lits et ancres n’exploseront plus lorsqu’ils sont utilisés dans la “mauvaise” dimension – ils n’auront tout simplement aucun effet.tntExplodes (Bedrock uniquement) : Permet de désactiver les explosions de TNT. Par défaut true (la TNT explose normalement lorsqu’on l’allume ou qu’on la déclenche). Si on la passe à false, la TNT n’explosera plus du tout une fois allumée – elle disparaîtra sans faire de dégâts ni d’impact sur l’environnement. (Sur Java, il n’existe pas de gamerule pour la TNT ; on peut toutefois retirer les dégâts de TNT via d’autres moyens, ou prévenir leur allumage.)spawnChunkRadius (Java uniquement, introduite en 1.14) : Définit le rayon des chunks de spawn qui restent chargés en permanence autour du point d’apparition du monde. La valeur par défaut est 2, ce qui correspond à un carré de 5×5 chunks toujours actifs autour du spawn. Un rayon plus grand garde plus de chunks chargés à tout moment (utile pour des fermes automatiques situées au spawn, mais attention au coût en performances). Inversement, mettre 0 désactiverait théoriquement la zone de charge permanente (sauf le chunk de spawn lui-même).spectatorsGenerateChunks (Java uniquement, introduite en 1.9) : Par défaut true, les joueurs en mode Spectateur peuvent générer de nouveaux chunks en volant dans des zones encore inexplorées (exactement comme un joueur normal le ferait en se déplaçant). En mettant cette option à false, un spectateur ne déclenchera plus la génération de nouveaux chunks inédits. Cela peut être pratique sur un serveur pour éviter qu’un joueur en mode Spectateur n’aille charger accidentellement d’énormes zones de la carte (utile en UHC par exemple, ou pour limiter l’exploration sans brider les joueurs en survie).projectilesCanBreakBlocks (Java uniquement, introduite en 1.19) : Par défaut true, cette règle permet à certains projectiles d’endommager des blocs. Par exemple, un trident lancé peut briser une stalactite de pierre goutteuse (pointed dripstone). Si vous la désactivez (false), les projectiles n’auront plus d’effet sur les blocs du décor (dans l’exemple, le trident ne cassera plus la stalactite). Cela concerne peu de situations en survie, mais peut éviter des dégâts collatéraux de projectiles dans certaines maps.
Gamerules liées aux objets et aux drops d’items
Ces gamerules modifient ce qui se passe lorsque des blocs ou mobs sont détruits, notamment si des objets sont lâchés ou non, et dans quelle mesure.
doTileDrops (Java & Bedrock, introduite en 1.4.2) : Contrôle si les blocs détruits laissent tomber un item correspondant (le drop du bloc). Par défaut true, casser un bloc (à la main ou avec un outil) fait apparaître l’objet correspondant au sol, comme d’habitude. Si vous désactivez doTileDrops (false), plus aucun bloc ne donnera de loot lorsqu’il est cassé – il disparaîtra simplement. (Note : même désactivée, les contenants comme les coffres, fours, dispensers… laissent quand même échapper leur contenu interne lorsqu’on les brise, mais pas le conteneur lui-même. Par exemple, un coffre laissera tomber les objets qu’il contenait mais pas le coffre en bois en tant qu’objet. En revanche, une boîte de shulker ne lâchera ni elle-même ni son contenu si doTileDrops est false, ce qui fait perdre définitivement les objets stockés dedans.)doEntityDrops (Java & Bedrock, introduite en 1.8.1) : Semblable à la précédente, mais pour les entités non-vivantes. Par défaut true, les entités “objets” comme les bateaux, chariots, peintures, armors stands etc., laissent tomber un item lorsqu’elles sont détruites. Si on la passe à false, aucune entité de ce type ne donnera d’item en étant brisée (ex : un bateau détruit ne donnera pas de bateau dans l’eau). (Cette gamerule n’affecte pas les mobs vivants, voir doMobLoot ci-dessous.) Notez que sur Bedrock, la portée exacte de doEntityDrops peut différer ou être incomplète, mais en général son usage est rare.doMobLoot (Java & Bedrock, introduite en 1.4.2) : Contrôle le loot des créatures vivantes (mobs) lorsqu’elles meurent. Par défaut true, les monstres et animaux lâchent leurs objets habituels et des orbes d’XP à leur mort. Si vous désactivez doMobLoot (false), aucun mob ne donnera de loot ni d’expérience en mourant. Note : Cela n’affecte que les drops liés à la mort des mobs – les autres objets produits par les créatures indépendamment de leur mort (par ex. les œufs pondus par les poules, la laine d’un mouton tondu, ou les roses du Wither générées lorsque celui-ci tue un mob) continueront d’apparaître normalement.blockExplosionDropDecay (Java uniquement, introduite en 1.19.3) : Contrôle la proportion de blocs récupérables lors d’une explosion autre que la TNT. Par défaut true, les explosions non TNT (par ex. l’explosion d’un lit dans le Nether/End, l’explosion d’un cristal de l’End, etc.) verront leurs drops diminuer en fonction de la distance au point central de l’explosion. Concrètement, plus un bloc est éloigné de l’épicentre, moins il a de chances de dropper son item (c’est le comportement normal introduit en 1.18 pour limiter les ressources obtenues via explosions). En passant blockExplosionDropDecay sur false, tous les blocs détruits par ce type d’explosion lâcheront systématiquement un drop, quel que soit leur éloignement.mobExplosionDropDecay (Java uniquement, introduite en 1.19.3) : Même principe que la précédente, mais pour les explosions causées par des mobs. Par défaut true, les explosions de Creepers (ou Bedlington, Wither, etc.) appliqueront une décroissance des drops en fonction de la distance. En la désactivant (false), tous les blocs détruits par une explosion de monstre donneront leur loot normal (ce qui peut augmenter significativement les drops d’une “farm” à Creepers utilisant des explosions).tntExplosionDropDecay (Java uniquement, introduite en 1.19.3) : S’applique aux explosions de TNT. Ici, le comportement par défaut est un peu différent : par défaut false (pas de décroissance, 100% des blocs détruits par de la TNT lâchent un drop). Si vous activez cette gamerule (true), alors la TNT se comportera comme les autres explosions avec un taux aléatoire de drops diminuant avec la distance. (En général, on laisse cette règle sur false pour conserver le fonctionnement habituel de la TNT.)
Gamerules liées aux commandes et à l’interface
Ces gamerules affectent les messages de chat, les annonces d’avancement, l’affichage de certaines infos à l’écran, ainsi que le comportement de retour des commandes.
announceAdvancements (Java uniquement, introduite en 1.12) : Par défaut true, cette règle active l’annonce dans le chat des avancements que les joueurs débloquent (ex : “X a obtenu l’avancement [Pierre taillée]”). En mettant announceAdvancements à false, aucun message d’annonce ne sera envoyé dans le chat lors de la progression d’un joueur. (Sur Bedrock, il n’y a pas d’équivalent car le système d’“Achievements” fonctionne différemment. À noter qu’avant la 1.12, la gamerule équivalente sur Java était announceAchievements, désormais obsolète.)commandBlockOutput (Java & Bedrock, introduite en 1.4.2) : Contrôle si les blocs de commande envoient un message dans le chat des administrateurs lorsqu’ils exécutent une commande. Par défaut true, chaque fois qu’un command block s’active, son résultat (succès/échec ou message de retour) est transmis aux opérateurs connectés. En réglant commandBlockOutput sur false, les blocs de commande resteront silencieux dans le chat. (Cela n’empêche pas le stockage du texte de sortie dans le bloc lui-même, visible via une interface en Java, mais ça évite de spammer le chat admin.)sendCommandFeedback (Java & Bedrock, introduite en 1.8) : Par défaut true, le jeu affiche un retour dans le chat pour chaque commande exécutée par un joueur (par exemple “Game rule doDaylightCycle est désormais false” après un /gamerule, ou le message “Téléportation…” après un /tp). Passer cette règle à false désactive ces messages de feedback pour le joueur. Sur un plan technique, cela change aussi le comportement par défaut des blocs de commande quant au stockage de leur texte de sortie. En somme, si vous trouvez les retours de commande envahissants, désactivez cette gamerule pour épurer le chat.logAdminCommands (Java uniquement, introduite en 1.8) : Si activée (true par défaut), toutes les commandes exécutées par les admins (cheats) seront enregistrées dans les logs du serveur (fichier server.log côté serveur). En la désactivant (false), ces commandes ne seront plus loguées. Cela peut être utile si vous voulez garder le log “propre” sans les commandes tapées, ou au contraire à laisser sur true pour conserver une trace des actions d’administration.reducedDebugInfo (Java uniquement, introduite en 1.8) : Si réglée sur true, certaines informations de débogage et raccourcis d’affichage seront masqués aux joueurs. Concrètement, en activant cette règle, l’écran de debug (F3) devient allégé : il n’affiche plus les coordonnées précises, l’orientation du regard, la balise de chunk, etc. (il reste quelques infos de base comme l’heure du jour). De plus, des raccourcis comme F3+B (hitboxes des entités) ou F3+G (grille des chunks) seront désactivés. Par défaut false (toutes les infos et outils de debug sont disponibles). Cette option est surtout utile en multijoueur si vous voulez empêcher les joueurs de voir certaines données (par exemple sur un serveur UHC pour cacher les coordonnées).showCoordinates (Bedrock uniquement, introduite en 1.12.0) : Par défaut true, affiche les coordonnées XYZ du joueur à l’écran (en haut de la carte dans l’interface Bedrock). Si désactivée, le joueur n’aura plus ses coordonnées d’affichées. (Sur Java, les coordonnées sont toujours visibles via F3, sauf si reducedDebugInfo est activé comme vu ci-dessus.)showDeathMessages (Java & Bedrock) : (Voir plus haut dans la section “Joueurs et mort”. Cette règle a déjà été expliquée.)showTags (Bedrock uniquement, introduite en 1.14.0) : Gère l’affichage de certaines étiquettes dans la description des objets en mode Aventure. Par défaut true, lorsqu’on examine un item dans l’inventaire, s’il possède des restrictions “Can place on” (Peut être placé sur…) ou “Can destroy” (Peut détruire…), ces listes de blocs autorisés s’affichent, de même qu’une éventuelle indication de verrouillage. En mettant showTags à false, on masque ces indications dans l’info-bulle des objets. Utile pour les créateurs de maps aventure qui voudraient cacher ces indices au joueur.showBorderEffect (Bedrock uniquement, introduite en 1.17.30) : Par défaut true, cette règle fait apparaître un effet visuel de particules rouges ascendantes au niveau des blocs de frontière (border blocks) placés dans le monde, afin de matérialiser la “frontière” ainsi définie. Si on la passe à false, ces blocs de bordure seront invisibles (aucune particule n’indiquera leur présence, ils bloqueront juste le passage). Cela peut être utilisé pour créer une barrière invisible sans alerter visuellement le joueur.announceAdvancements (Java uniquement) : (Voir plus haut. Cette règle a été décrite précédemment.)
(NB : Les gamerules liées aux messages de mort et aux avancements ont été détaillées dans les sections précédentes pour éviter les doublons.)
Gamerules d’artisanat et de progression
Ces gamerules permettent de régler la manière dont les joueurs débloquent et utilisent les recettes d’artisanat, ce qui peut être utile pour moduler la progression dans le jeu.
doLimitedCrafting (Java & Bedrock, introduite en 1.12 sur Java) : Par défaut false, ce qui signifie que les joueurs peuvent crafter n’importe quel objet dont ils connaissent la recette, même si elle n’a pas été “débloquée” dans le livre de recettes. En activant doLimitedCrafting (true), on limite le craft aux seules recettes que le joueur a déjà obtenues/découvertes. Autrement dit, si cette règle est sur true, un joueur devra nécessairement avoir trouvé l’ingrédient ou le patron d’une recette pour pouvoir la fabriquer lui-même. C’est une option intéressante pour encourager l’exploration et l’apprentissage progressif des recettes. (Bedrock a reçu cette gamerule plus récemment : elle a été ajoutée dans une mise à jour 1.20.x.)recipesUnlock (Bedrock uniquement, introduite en 1.20.30) : Par défaut true, cette règle contrôle la nécessité de collecter les items pour débloquer automatiquement les recettes correspondantes dans le livre de recettes. Si on la désactive (false), toutes les recettes seront directement disponibles dans le livre de recettes du joueur, sans qu’il ait besoin de découvrir les ingrédients au préalable. En résumé, recipesUnlock=false permet d’avoir d’emblée l’intégralité des recettes visibles (et combiné avec doLimitedCrafting=false, cela autorise même de crafter sans restriction). À l’inverse, en laissant recipesUnlock=true (par défaut), le joueur doit trouver chaque nouvel ingrédient pour voir apparaître la recette liée dans son livre. (Java n’a pas cette gamerule spécifique : le déblocage des recettes y est toujours requis, et seul doLimitedCrafting influence la possibilité de crafter sans déblocage.)
Gamerules techniques et avancées
Cette dernière catégorie regroupe des gamerules davantage destinées aux administrateurs avancés, influant sur des limites techniques du jeu ou des fonctionnalités de commande. La plupart sont spécifiques à un type de serveur ou de version.
commandBlocksEnabled (Bedrock uniquement, introduite en 1.7.0) : Permet d’activer ou désactiver l’utilisation des blocs de commande sur un serveur Bedrock. Par défaut true (les command blocks fonctionnent normalement). Si réglé sur false, les blocs de commande seront totalement inopérants (ils ne pourront pas s’exécuter ni être placés/utilisés). Utile pour les administrateurs Bedrock souhaitant interdire les command blocks sur leur monde (par exemple pour éviter tout usage abusif).commandModificationBlockLimit (Java uniquement, introduite en 1.19.4) : Définit le nombre maximum de blocs qui peuvent être altérés par certaines commandes structurelles comme /clone, /fill ou /fillbiome. La valeur par défaut est 32768 blocs. Si une de ces commandes tente de modifier plus de blocs que cette limite, elle sera annulée (sur Java). Vous pouvez augmenter cette limite si vos opérations dépassent 32k blocs, ou la diminuer pour éviter des abus. (Non disponible sur Bedrock où d’autres limites s’appliquent.)functionCommandLimit (Bedrock uniquement, introduite en 1.9.0) : Définit le nombre maximum de commandes qu’un paquet de fonctions (commande /function) peut exécuter en une seule fois. Par défaut 10000, ce qui est largement suffisant pour la plupart des packs de fonctions. Si un /function contient plus de commandes que cette valeur, l’exécution s’arrêtera avant la fin. Vous pouvez augmenter cette valeur si vous utilisez des function packs très volumineux, ou la réduire pour limiter l’impact de scripts complexes sur votre serveur Bedrock.maxCommandChainLength (Java & Bedrock, introduite en 1.12) : Définit la longueur maximale d’une chaîne de commandes qui peuvent s’exécuter en un seul tick. Par défaut 65536 (une chaîne très longue de ~65k commandes peut se dérouler instantanément). Sur Java, cela s’applique aux command blocks en chaîne et aux commandes /execute imbriquées, tandis que sur Bedrock cela couvre aussi des enchaînements de fonctions. En pratique, cette limite sert surtout à éviter les boucles infinies ou trop longues de commandes. (Évitez de mettre une valeur trop basse, cela pourrait interrompre des fonctions légitimes.)maxCommandForkCount (Java uniquement, introduite en 1.18) : Cette règle un peu technique contrôle le nombre maximal de “forks” de commandes en un tick. En termes simples, c’est une limite liée aux commandes /execute et aux fonctions qui peuvent déclencher d’autres commandes de manière arborescente. La valeur par défaut est 65536. Elle est rarement modifiée, car son utilité est surtout pour les développeurs de datapacks très complexes qui voudraient empêcher une explosion combinatoire de commandes.maxEntityCramming (Java uniquement, introduite en 1.11) : Définit le nombre maximum d’entités empilables (mobs ou joueurs) pouvant se tenir en même temps sur le même bloc avant de subir des dégâts de suffocation. Par défaut 24. Cela signifie que si plus de 24 créatures (hors chauves-souris) se retrouvent coincées dans un espace restreint, elles commenceront à prendre des dégâts d’étouffement (environ 6 pv par demi-seconde) jusqu’à ce que leur nombre repasse sous la limite. Régler maxEntityCramming sur 0 ou une valeur négative désactive cette mécanique, permettant un nombre infini de mobs empilés sans dégâts. Cette gamerule est utile pour contrôler le rendement de fermes à mobs où des dizaines de créatures peuvent s’accumuler en un point.minecartMaxSpeed (Java uniquement, introduite en 1.8) : Définit la vitesse maximale que peuvent atteindre les wagonnets (minecarts). La valeur par défaut est 8.0. Il s’agit d’une valeur interne de vitesse (non directement en m/s, mais proportionnelle). En augmentant ce chiffre, vos wagonnets pourront se déplacer plus rapidement sur les rails. En le diminuant, vous bridez la vitesse max. Notez que des vitesses trop élevées peuvent rendre les rails propulseurs inefficaces ou causer un déraillement visuel du chariot.disableElytraMovementCheck (Java uniquement, introduite en 1.9) : Par défaut false. Sur un serveur Java, le jeu vérifie normalement la vitesse des joueurs pour éviter la triche ou les décalages extrêmes (anti-cheat de vol). En particulier, avec l’Élytre, des latences peuvent faire croire au serveur que le joueur se déplace trop vite de façon anormale. En passant disableElytraMovementCheck à true, vous désactivez cette vérification de vitesse spécifique à l’élytre. Cela peut aider à réduire le lagback (rappel en arrière) des joueurs en vol quand le serveur a des montées de latence. À utiliser avec précaution, car cela pourrait faciliter certaines formes de triche de déplacement (fly hacks).disablePlayerMovementCheck (Java uniquement, introduite en 1.21) : Semblable à la précédente, mais concerne la vitesse de déplacement du joueur de manière générale (pas uniquement en élytre). Par défaut false, le serveur Java surveille les déplacements trop rapides des joueurs pour détecter d’éventuels cheats. Si vous activez disablePlayerMovementCheck (true), le serveur ne fera plus aucune vérification de vitesse des joueurs. Cela peut éliminer tout risque de rubberband dû à la latence, mais ouvre aussi la porte aux cheats de vol ou de speed sans que le serveur ne les détecte. À n’activer que dans des contextes spécifiques (serveur de test, etc.).spectatorsGenerateChunks (Java uniquement) : (Voir section Monde & Environnement ci-dessus.)spawnChunkRadius (Java uniquement) : (Voir section Monde & Environnement ci-dessus.)playersSleepingPercentage (Java & Bedrock, introduite en 1.17 sur Java) : Définit le pourcentage de joueurs qui doivent dormir pour passer la nuit. Par défaut 100 (%), ce qui signifie qu’il faut que tous les joueurs du monde dorment en même temps pour que le cycle passe instantanément au matin. En abaissant cette valeur, on peut permettre à la nuit de sauter avec moins de dormeurs. Par exemple, à 50 (%), il suffira que la moitié des joueurs connectés dorme pour que la nuit se termine. Et à 1 (%) ou moins, un seul joueur dormant pourra faire passer la nuit pour tout le serveur. À l’inverse, une valeur supérieure à 100 empêchera toute transition automatique (même si tout le monde dort, la nuit ne passera pas toute seule). (Bedrock n’a intégré cette option qu’en 1.20.30 environ ; auparavant, seul “tout le monde dort” fonctionnait.)playersNetherPortalCreativeDelay (Java uniquement, introduite en 1.18) : Définit, en nombre de ticks, le temps d’attente dans un portail du Nether pour un joueur en mode Créatif avant la téléportation inter-dimension. Par défaut 1 tick (0,05 seconde), ce qui revient à une téléportation quasi-instantanée pour les créatifs passant un portail. Vous pouvez augmenter légèrement cette valeur si vous souhaitez que même les créatifs aient un petit délai dans les portails, mais en général on laisse 1.playersNetherPortalDefaultDelay (Java uniquement, introduite en 1.18) : De même, définit en ticks le temps d’attente dans un portail pour un joueur en Survie ou Aventure. Par défaut 80 ticks (4 secondes), c’est le délai classique pour changer de dimension via un portail du Nether. En diminuant cette valeur, on peut rendre les voyages inter-dimension plus rapides, et en l’augmentant on les ralentit. (Note : 80 est le minimum pour la survie dans le code vanilla. Des valeurs inférieures pourraient ne pas avoir d’effet.)
En résumé, Minecraft offre une multitude de gamerules permettant d’ajuster finement l’expérience de jeu, que ce soit pour faciliter la vie des débutants (garder l’inventaire après la mort, désactiver le feu ou les creepers destructeurs) ou pour configurer des serveurs aux mécanismes spéciaux (par ex. UHC sans régénération naturelle, maps aventure avec tags masqués, etc.).
N’hésitez pas à expérimenter ces options dans votre monde test pour voir l’impact qu’elles ont. Et rappelez-vous que toute modification d’une gamerule peut être annulée en la remettant à sa valeur par défaut à tout moment avec la commande /gamerule.
Bon jeu et bonne personnalisation !
