Peut-on vraiment faire un plugin Minecraft sans savoir programmer ?

Oui, à condition d'accepter une limite : tu composes des règles dans une grammaire donnée, tu n'écris pas un programme quelconque. Une règle dit « quand ceci arrive, si ces conditions tiennent, alors faire cela ». Presque tout ce qu'un serveur entre amis demande tient dans cette forme : messages d'accueil, récompenses, protections, annonces, commandes maison. Ce qui n'y tient pas, c'est ce qui demande d'inventer une mécanique de jeu entière, et là il faut du Java.

Quelle est la différence avec les blocs de commande ?

Les blocs de commande vivent dans le monde, à un endroit précis, et se déclenchent par redstone ou par horloge. Un plugin se déclenche sur un événement du serveur : un joueur qui se connecte, un bloc cassé, un message dans le chat. Ce que les blocs de commande ne savent pas faire, c'est réagir à ce qui se passe, et surtout empêcher que ça se passe. Une règle NimBlock peut annuler l'événement qui vient d'arriver.

Et par rapport à un datapack ?

Un datapack reste dans le cadre du jeu vanilla : fonctions, avancements, tables de butin. Il ne peut pas ajouter de vraie commande, ni intercepter un chat, ni annuler une action. Un plugin Paper le peut, parce qu'il tourne dans le serveur, pas dans les données du monde. En contrepartie, un datapack marche sur un serveur vanilla, et un plugin demande Paper ou Spigot.

Et par rapport à Skript ?

Skript est l'ancêtre du genre et il est plus puissant, sans comparaison possible : c'est un vrai langage, avec des variables, des boucles et une immense bibliothèque d'extensions. C'est aussi un langage, donc une syntaxe à apprendre, des erreurs à lire, et un fichier qui ne dit pas où il s'est cassé. NimBlock fait beaucoup moins, mais il refuse une règle invalide avant de l'enregistrer et te montre l'endroit exact du problème sur la brique concernée. Si tu es à l'aise avec Skript, reste sur Skript.

Le plugin est-il compilé en Java quelque part ?

Non, et c'est le choix central du produit. Ta spec reste un fichier JSON, et le serveur charge un moteur écrit une fois pour tout le monde qui la lit et l'exécute. Rien n'est engendré, rien n'est compilé. Conséquence pratique : une nouvelle version de Minecraft se paie une fois dans ce moteur, pas dans chacun des plugins écrits avec lui.

Peut-on récupérer le plugin pour un serveur qui n'est pas chez NimBlock ?

C'est prévu, et le moteur qui lit les specs sera publié dans les catalogues de plugins. Une spec est un fichier JSON ordinaire : le moteur la lit depuis le dossier des plugins du serveur. Ce n'est pas encore en ligne au moment où cette page est écrite.

Créer un plugin Minecraft sans coder

Sur un serveur Minecraft, tout ce qui sort du jeu de base passe par un plugin, et un plugin s'écrit en Java. C'est le mur sur lequel butent la plupart des gens qui tiennent un serveur : ils savent exactement ce qu'ils veulent, et la seule route passe par un langage, un projet à compiler et une API à apprendre. Cette page explique ce qu'on peut faire sans, et surtout où sont les limites.

Le mur, et les trois contournements connus

Avant NimBlock, quelqu'un qui ne programme pas a trois options, et chacune a une frontière nette qu'il vaut mieux connaître avant de s'y engager.

Les blocs de commande. Ils vivent dans le monde, à un endroit précis, et se déclenchent par redstone ou par horloge. Ils ne savent pas réagir à un événement du serveur, et encore moins l'empêcher.
Les datapacks. Ils restent dans le cadre vanilla : fonctions, avancements, tables de butin. Pas de vraie commande, pas d'interception du chat, pas d'annulation d'action. En échange, ils tournent sur un serveur vanilla, sans Paper.
Skript. Beaucoup plus puissant que les deux précédents, et plus puissant que NimBlock. C'est un vrai langage, donc une syntaxe à apprendre et des erreurs à décoder.

Ces trois-là existent depuis longtemps et n'ont rien de dépassé. Ce qui manquait, c'est l'étage entre le bloc de commande et le langage.

Une règle, en une phrase

Toute la grammaire de NimBlock tient dans une phrase : quand ceci arrive, si ces conditions tiennent, alors faire cela. Un plugin est une liste de règles, une règle est un déclencheur, quelques conditions et quelques actions. Il n'y a rien d'autre à apprendre, et c'est volontaire : une grammaire qui tient dans une phrase tient aussi dans la tête.

Règle « accueil »

Quand un joueur rejoint la partie

si le joueur a la permission nimblock.vip

alors envoyer « Bienvenue {joueur} ! »

donner 1 pain

jouer un son de niveau

Dans l'éditeur, ce sont des briques qui s'emboîtent : une brique qui n'a pas le droit d'aller à un endroit ne s'y emboîte pas. Et ce que l'éditeur laisse passer, le validateur le reprend : une spec est acceptée ou refusée en entier, jamais à moitié. Un plugin de protection amputé de sa règle de protection ne se verrait pas en jeu, et c'est exactement le genre de panne qu'on ne veut pas.

Ce qu'on peut faire aujourd'hui

9 déclencheurs, 8 conditions, 14 actions. La liste exacte, à jour et avec le détail de chaque paramètre, vit sur la page de grammaire : elle est engendrée à partir du catalogue, donc elle ne ment jamais. En résumé de ce qu'ils permettent :

Réagir à ce qui se passe : une connexion, une déconnexion, un message dans le chat, une mort, un bloc cassé ou posé, une commande que tu inventes, ou simplement toutes les N secondes.
Filtrer sur une permission, le statut d'opérateur, le monde, les points de vie, le contenu d'un texte, une comparaison de nombres, ou une probabilité.
Agir : messages, titres en grand, sons, objets, effets, soins, téléportations, annonces à tout le serveur, exécution d'une commande console, et annulation de l'événement qui vient d'arriver. C'est cette dernière qui transforme la liste en vraies protections.

Ce que ça ne remplace pas

Une page qui promet tout ne sert personne. Ce que NimBlock ne fait pas :

Pas de nouvelle mécanique de jeu. Un nouveau type de bloc, une entité inédite, une interface d'inventaire sur mesure : c'est du Java, et ça le restera.
Pas de variables ni de boucles. Une règle réagit, elle ne calcule pas. Si ton idée demande de stocker un état complexe entre deux événements, tu es au-delà de cette grammaire.
Pas de plugin tiers. NimBlock exécute tes specs, il ne charge pas un .jar téléchargé ailleurs.
Une nouvelle commande attend le prochain démarrage. Le reste s'applique à chaud, sans couper le serveur, mais Minecraft enregistre ses commandes au démarrage : c'est dit dans le panel au moment où ça arrive plutôt que découvert en jeu.

Où le plugin s'exécute

Nulle part il n'y a de Java engendré puis compilé. Le serveur charge un moteur écrit une fois pour tout le monde, et ce moteur lit ta spec. C'est ce qui fait qu'un plugin composé ici n'a pas de dette : quand Minecraft change, c'est le moteur qui s'adapte, une fois, et pas chacun des plugins écrits avec lui.

Sur un serveur NimBlock, l'installation prend un clic et le plugin descend sans couper la partie. Le moteur, lui, sera publié dans les catalogues de plugins, pour que la même spec tourne sur un serveur qui n'est pas hébergé ici.

Questions fréquentes

Peut-on vraiment faire un plugin Minecraft sans savoir programmer ?: Oui, à condition d'accepter une limite : tu composes des règles dans une grammaire donnée, tu n'écris pas un programme quelconque. Une règle dit « quand ceci arrive, si ces conditions tiennent, alors faire cela ». Presque tout ce qu'un serveur entre amis demande tient dans cette forme : messages d'accueil, récompenses, protections, annonces, commandes maison. Ce qui n'y tient pas, c'est ce qui demande d'inventer une mécanique de jeu entière, et là il faut du Java.
Quelle est la différence avec les blocs de commande ?: Les blocs de commande vivent dans le monde, à un endroit précis, et se déclenchent par redstone ou par horloge. Un plugin se déclenche sur un événement du serveur : un joueur qui se connecte, un bloc cassé, un message dans le chat. Ce que les blocs de commande ne savent pas faire, c'est réagir à ce qui se passe, et surtout empêcher que ça se passe. Une règle NimBlock peut annuler l'événement qui vient d'arriver.
Et par rapport à un datapack ?: Un datapack reste dans le cadre du jeu vanilla : fonctions, avancements, tables de butin. Il ne peut pas ajouter de vraie commande, ni intercepter un chat, ni annuler une action. Un plugin Paper le peut, parce qu'il tourne dans le serveur, pas dans les données du monde. En contrepartie, un datapack marche sur un serveur vanilla, et un plugin demande Paper ou Spigot.
Et par rapport à Skript ?: Skript est l'ancêtre du genre et il est plus puissant, sans comparaison possible : c'est un vrai langage, avec des variables, des boucles et une immense bibliothèque d'extensions. C'est aussi un langage, donc une syntaxe à apprendre, des erreurs à lire, et un fichier qui ne dit pas où il s'est cassé. NimBlock fait beaucoup moins, mais il refuse une règle invalide avant de l'enregistrer et te montre l'endroit exact du problème sur la brique concernée. Si tu es à l'aise avec Skript, reste sur Skript.
Le plugin est-il compilé en Java quelque part ?: Non, et c'est le choix central du produit. Ta spec reste un fichier JSON, et le serveur charge un moteur écrit une fois pour tout le monde qui la lit et l'exécute. Rien n'est engendré, rien n'est compilé. Conséquence pratique : une nouvelle version de Minecraft se paie une fois dans ce moteur, pas dans chacun des plugins écrits avec lui.
Peut-on récupérer le plugin pour un serveur qui n'est pas chez NimBlock ?: C'est prévu, et le moteur qui lit les specs sera publié dans les catalogues de plugins. Une spec est un fichier JSON ordinaire : le moteur la lit depuis le dossier des plugins du serveur. Ce n'est pas encore en ligne au moment où cette page est écrite.

Compose ta première règle, et vois-la tourner sur un serveur qui existe déjà.

Créer mon compte Grammaire des plugins

Gratuit pendant la bêta · un serveur de 1 Go par compte