NimBlock Anmelden

Minecraft-Plugin ohne Programmieren erstellen

Auf einem Minecraft-Server läuft alles, was über das Grundspiel hinausgeht, über ein Plugin, und ein Plugin wird in Java geschrieben. Genau daran scheitern die meisten, die einen Server betreiben: Sie wissen genau, was sie wollen, und der einzige Weg führt über eine Programmiersprache, ein Projekt zum Kompilieren und eine API zum Lernen. Diese Seite erklärt was ohne all das geht, und vor allem, wo die Grenzen liegen.

Die Mauer, und die drei bekannten Wege drumherum

Vor NimBlock hat jemand, der nicht programmiert, drei Optionen, und jede hat eine klare Grenze, die man besser kennt, bevor man sich darauf einlässt.

  • Befehlsblöcke. Sie leben in der Welt, an einer festen Stelle, und werden durch Redstone oder einen Taktgeber ausgelöst. Sie können nicht auf ein Server-Ereignis reagieren, geschweige denn es verhindern.
  • Datenpakete. Sie bleiben innerhalb von Vanilla: Funktionen, Fortschritte, Beutetabellen. Kein echter Befehl, kein Abfangen des Chats, kein Rückgängigmachen einer Aktion. Dafür laufen sie auf einem Vanilla-Server, ganz ohne Paper.
  • Skript. Deutlich mächtiger als die beiden vorigen, und mächtiger als NimBlock. Es ist eine echte Sprache, also eine Syntax zum Lernen und Fehler zum Entziffern.

Diese drei gibt es schon lange, und keins davon ist überholt. Was gefehlt hat, ist die Stufe zwischen dem Befehlsblock und der Programmiersprache.

Eine Regel, in einem Satz

Die gesamte Grammatik von NimBlock passt in einen Satz: wenn dies passiert, falls diese Bedingungen zutreffen, dann tue das. Ein Plugin ist eine Liste von Regeln, eine Regel besteht aus einem Auslöser, ein paar Bedingungen und ein paar Aktionen. Es gibt nichts weiter zu lernen, und das ist Absicht: Eine Grammatik, die in einen Satz passt, passt auch in den Kopf.

Regel Willkommen "
Wenn ein Spieler dem Spiel beitritt
falls der Spieler die Berechtigung nimblock.vip hat
dann sende „ Willkommen {spieler} ! "
gib 1 Brot
spiele einen Levelup-Sound

Im Editor sind das Blöcke, die ineinander einrasten: Ein Block, der an einer Stelle nicht erlaubt ist, rastet dort nicht ein. Und was der Editor durchlässt, greift der Validator noch einmal auf: Eine Spec wird als Ganzes angenommen oder abgelehnt, nie zur Hälfte. Ein Schutz-Plugin ohne seine Schutzregel würde im Spiel nicht auffallen, und genau das ist die Art von Ausfall, die niemand will.

Was du heute schon bauen kannst

9 Auslöser, 8 Bedingungen, 14 Aktionen. Die genaue, aktuelle Liste mit allen Parametern findest du auf der Grammatik-Seite: Sie wird direkt aus dem Katalog erzeugt und lügt deshalb nie. Kurz zusammengefasst, was damit möglich ist:

  • Auf das reagieren, was passiert: ein Login, ein Logout, eine Chat-Nachricht, ein Tod, ein abgebauter oder platzierter Block, ein selbst erfundener Befehl, oder einfach alle N Sekunden.
  • Filtern nach einer Berechtigung, dem Operator-Status, der Welt, den Lebenspunkten, dem Inhalt eines Texts, einem Zahlenvergleich, oder einer Wahrscheinlichkeit.
  • Handeln: Nachrichten, große Titel, Sounds, Gegenstände, Effekte, Heilung, Teleports, serverweite Ankündigungen, Ausführen eines Konsolenbefehls, und Abbrechen des Ereignisses, das gerade eingetreten ist. Genau Letzteres macht aus der Liste echten Schutz.

Was es nicht ersetzt

Eine Seite, die alles verspricht, nützt niemandem. Was NimBlock nicht kann:

  • Keine neue Spielmechanik. Ein neuer Blocktyp, eine neue Entität, eine maßgeschneiderte Inventar-Oberfläche: Das ist Java, und das bleibt Java.
  • Keine Variablen und keine Schleifen. Eine Regel reagiert, sie rechnet nicht. Wenn deine Idee verlangt, zwischen zwei Ereignissen einen komplexen Zustand zu speichern, bist du über diese Grammatik hinaus.
  • Keine Plugins von Dritten. NimBlock führt deine Specs aus, es lädt keine anderswo heruntergeladene .jar-Datei.
  • Ein neuer Befehl wartet auf den nächsten Neustart. Alles andere greift sofort, ohne den Server anzuhalten, aber Minecraft registriert seine Befehle beim Start: Das Panel sagt dir das genau in dem Moment, statt dass du es erst im Spiel bemerkst.

Wo das Plugin läuft

Nirgendwo wird Java erzeugt und dann kompiliert. Der Server lädt eine Runtime, die einmal für alle geschrieben wurde, und diese Runtime liest deine Spec. Deshalb hat ein hier zusammengestelltes Plugin keine Altlasten: Wenn sich Minecraft ändert, passt sich die Runtime an, einmal, und nicht jedes einzelne damit geschriebene Plugin.

Auf einem NimBlock-Server dauert die Installation einen Klick, und das Plugin kommt an, ohne das Spiel zu unterbrechen. Die Runtime selbst wird in den Plugin-Katalogen veröffentlicht, damit dieselbe Spec auch auf einem Server läuft, der nicht hier gehostet wird.

Häufige Fragen

Kann man wirklich ein Minecraft-Plugin bauen, ohne programmieren zu können?
Ja, mit einer Einschränkung: Du stellst Regeln innerhalb einer festgelegten Grammatik zusammen, du schreibst kein beliebiges Programm. Eine Regel sagt „wenn das passiert, falls diese Bedingungen zutreffen, dann tue das“. Fast alles, was ein Server unter Freunden braucht, passt in diese Form: Willkommensnachrichten, Belohnungen, Schutzmechanismen, Ankündigungen, eigene Befehle. Was nicht hineinpasst, ist alles, was eine ganz neue Spielmechanik erfindet, und dafür braucht es weiterhin Java.
Was ist der Unterschied zu Befehlsblöcken?
Befehlsblöcke leben in der Welt, an einer festen Stelle, und werden durch Redstone oder einen Taktgeber ausgelöst. Ein Plugin reagiert auf ein Server-Ereignis: ein Spieler, der sich verbindet, ein abgebauter Block, eine Chat-Nachricht. Was Befehlsblöcke nicht können, ist auf das reagieren, was passiert, und vor allem verhindern, dass es passiert. Eine NimBlock-Regel kann das Ereignis, das gerade eingetreten ist, abbrechen.
Und im Vergleich zu einem Datenpaket?
Ein Datenpaket bleibt innerhalb des Vanilla-Spiels: Funktionen, Fortschritte, Beutetabellen. Es kann keinen echten Befehl hinzufügen, keinen Chat abfangen und keine Aktion rückgängig machen. Ein Paper-Plugin kann das, weil es im Server läuft und nicht in den Weltdaten. Im Gegenzug funktioniert ein Datenpaket auf einem Vanilla-Server, während ein Plugin Paper oder Spigot braucht.
Und im Vergleich zu Skript?
Skript ist der Urvater dieser Gattung und um Klassen mächtiger, ganz ohne Vergleich: Es ist eine echte Sprache, mit Variablen, Schleifen und einer riesigen Bibliothek an Erweiterungen. Es ist aber auch eine Sprache, also eine Syntax zum Lernen, Fehler zum Entziffern und eine Datei, die nicht verrät, wo sie kaputtgegangen ist. NimBlock kann deutlich weniger, verweigert aber eine ungültige Regel schon vor dem Speichern und zeigt dir genau die Stelle des Problems am betroffenen Block. Wenn du dich mit Skript wohlfühlst, bleib bei Skript.
Wird das Plugin irgendwo zu Java kompiliert?
Nein, und das ist die zentrale Entscheidung hinter dem Produkt. Deine Spec bleibt eine JSON-Datei, und der Server lädt eine Runtime, die einmal für alle geschrieben wurde und die Spec liest und ausführt. Es wird nichts erzeugt, nichts kompiliert. Die praktische Folge: Eine neue Minecraft-Version kostet einmal in dieser Runtime, nicht in jedem einzelnen damit gebauten Plugin.
Kann ich das Plugin auf einen Server mitnehmen, der nicht bei NimBlock läuft?
Das ist geplant, und die Runtime, die Specs liest, wird in den Plugin-Katalogen veröffentlicht. Eine Spec ist eine ganz normale JSON-Datei: Die Runtime liest sie aus dem Plugins-Ordner des Servers. Zum Zeitpunkt, an dem diese Seite geschrieben wird, ist das noch nicht online.

Stelle deine erste Regel zusammen und sieh ihr beim Laufen zu, auf einem Server, den es schon gibt.

Kostenlos während der Beta · ein Server mit 1 GB pro Konto