Das offizielle Minecraft Wiki twittert hier: Wiki-Twitter  –  Chatte im Wiki-Discord  – Noch keinen Server gefunden? Es gibt einen Wiki-Server

Plugin API

Aus Minecraft Wiki
Wechseln zu: Navigation, Suche

Ganz allgemein ist ein Plugin eine Datei, die einer Software - in diesem Fall Minecraft - optional hinzugefügt werden kann, um sie zu verändern. Damit ein Plugin eingesetzt werden kann, muss die Software eine Schnittstelle zur Verfügung stellen, die sogenannte Plugin API.

Funktionsweise[Bearbeiten]

Eine Plugin API (Application Programming Interface) ist eine Programmierschnittstelle. Sie besteht aus:

  • Festlegung, in welchen Ordnern bzw. Verzeichnissen die Plugins abgelegt werden müssen.
  • Festlegung, wie die Plugins heißen müssen.
  • Festlegung, welchen Inhalt die Plugins haben und wie sie formatiert sein müssen.
  • Fähigkeit der Software, die definierten Plugins einlesen und ihren Inhalt verarbeiten zu können.

Jeder Benutzer, der die Plugin API kennt, kann ein Plugin schreiben, um das Aussehen oder die Funktion der Software verändern. Einfacher ist es, der Software ein bereits existierendes Plugin hinzuzufügen. Der Name "Plugin" bedeutet wörtlich "Einstöpseln" eines Steckers (= Plugin-Datei) in eine Steckdose (= Plugin API der Software). Nur wenn das Plugin genau zur Plugin API passt, funktioniert es.

Vanilla Plugin API[Bearbeiten]

Das unmodifizierte Originalspiel bietet folgende Möglichkeiten für Plugins:

  • Ein Client-Ressourcenpaket ist eine zip-Datei, die im Ordner .minecraft/resourcepacks abgelegt (= eingestöpselt) wird. Über das Ressourcenpaket-Menü werden die einzelnen Plugins (= Ressourcenpakete) aktiviert. Mit einem Ressourcenpaket wird das Aussehen des Spiels verändert: Texturen, Geräusche, Blockformen, Texte etc.
  • Ein Welt-Ressourcenpaket wird vom Ersteller der Welt im Weltordner abgelegt. Über das Menü kann dieses Plugin nicht entfernt werden.
  • Ein Server-Ressourcenpaket wird vom Serverbetreiber im Internet abgelegt, die URL wird in den server.properties eingetragen.
  • Neu mit Version 1.13: Ein Datenpaket ist eine zip-Datei, die im Ordner Weltordner/datapacks einer bestimmten Welt abgelegt wird. Über den Befehl /datapack werden die einzelnen Plugins (= Datenpakete) aktiviert. Mit einem Datenpaket wird das Verhalten der jeweiligen Welt verändert: Fortschritte, Rezepte, Kreaturenbeute, Befehlsabläufe (Funktionen) etc.

Die zip-Dateien enthalten meistens Textdateien im JSON-Format, mit denen beschrieben wird, welche Daten des Spiels sich wie ändern sollen.

Modifizierte Plugin APIs[Bearbeiten]

Es gibt einige Modifikationen, die dem Spiel eine erweiterte Plugin API zur Verfügung stellen. Die bekanntesten sind Forge und Liteloader für Minecraft-Clients sowie Bukkit für Minecraft-Server. Wie in der Funktionsweise beschrieben, legen auch diese Plugin APIs bestimmte Ordner fest, in denen bestimmte Dateien in einem bestimmten Format stehen müssen. Meist handelt es sich dabei um Java-Dateien. Die Mod-Plugins gehen über die Vanilla-Plugins hinaus, denn sie können dem Spiel neue Spielelemente (Blöcke, Gegenstände, Kreaturen, Biome, Dimensionen etc.) hinzufügen.

Server-Plugins werden häufig eingesetzt, um Minecraft-Server um neue Funktionen zu erweitert. Dazu gehören z.B. Verwaltungsfunktionen wie Ränge und Rechtevergabe und Spielfunktionen wie neue Spielmodi. Beim Programmieren von Server-Plugins möchte man üblicherweise erreichen, dass die Besucher des Servers einfach ihren unmodifizierten Vanilla-Client benutzen können. Dazu greifen die Server-Plugins in die Kommunikation zwischen Client und Server ein. Wie hier beschrieben, verwaltet der Server die Welt und die Clients zeigen sie an. Dazu sendet jeder Client Datenpakete mit Informationen an den Server (z.B. eine Abbauaktion auf einen Block), und der per Plugin modifizierte Server sendet die passenden Datenpakete zurück (z.B. Abbau nicht erlaubt, weil der Spieler das passende Recht nicht hat).

Plugins und Modifikationen[Bearbeiten]

Sowohl mit Plugins als auch mit Modifikationen ("Mods") kann man das Spiel verändern. Aber während ein Plugin nur zur jeweiligen Plugin API passen muss, ist eine Modifikation wesentlich schwieriger: Hierbei wird das Programm auseinandergenommen (dekompiliert), der Programmcode verändert und schließlich ein neues, modifiziertes Spiel hergestellt. Damit stößt man schnell an lizenzrechtliche Probleme, denn Mojang unterstützt solche Veränderungen seines Spiels nur in einem gewissem Rahmen:

Flag of the United Kingdom.svg If you've bought the Game, you may play around with it and modify it. We'd appreciate it if you didn't use this for griefing, though, and remember not to distribute the changed versions of our software. Basically, mods (or plugins, or tools) are cool (you can distribute those), hacked versions of the Game client or server are not (you can't distribute those).
Flag of Germany.svg Wenn du das Spiel gekauft hast, darfst du damit experimentieren und es verändern. Aber wir würden es begrüßen, wenn du das nicht für zerstörerische Zwecke tust (Griefing). Und denke daran, veränderte Versionen unseres Programmes nicht zu verbreiten. Grundsätzlich sind Mods (oder Plugins oder Zusatzprogramme) cool (du darfst sie verbreiten), gecrackte Versionen von Client oder Server sind es nicht (du darfst sie nicht verbreiten).

Die Veränderungen oder Erweiterungen für Minecraft müssen also getrennt vom Originalspiel verbreitet werden. Man darf nicht das Spiel verändern und dann verbreiten. Das bedeutet, dass nicht der Mod-/Plugin-Hersteller, sondern der Mod-/Plugin-Anwender die Veränderung mit seiner rechtmäßig erworbenen Originalversion des Spiels verbinden muss. Und das ist mit Plugins wesentlich einfacher möglich als mit Mods.

Geschichte (Java Edition)[Bearbeiten]

Hier wird ein Überblick über die Entwicklung der Plugin API gegeben, der Schwerpunkt liegt dabei auf den tatsächlich durchgeführten Änderungen. Wer auch etwas über die im Laufe der Zeit veröffentlichten (und mittlerweile teilweise überholten) Pläne und Konzepte wissen möchte, kann sie in dieser ausführlichen Übersicht finden.

  • Mit Veröffentlichung der ersten Mehrspielerversion Classic 0.0.15a für die Java Edition im Juni 2009 entstanden die ersten modifizierten Minecraft-Server. Notch reagierte und wies darauf hin, dass Modifizieren okay sei, aber man dürfe nur die Mod selbst verbreiten, nicht das modifizierte Spiel[1]. Kurz darauf erläuterte er seine Pläne bezüglich einer Modifikations-Unterstützung[2]: "Ich werde eine Art Server API veröffentlichen, damit man Plugins einfacher schreiben kann, als in den Datenfluss zwischen Client und Server einzugreifen. Die API wird solche Dinge zur Verfügung stellen, wie Blockplatzierungen, welche Blockart, Spielerbewegungen und Chateingaben. Die API wird es dann ermöglichen, Nachrichten zu senden, Spieler zu teleportieren, Blöcke zu setzen und wahrscheinlich auch die Welt zu laden und zu speichern."
  • Ein Jahr später, als Notch seinen bisherigen Job gekündigt hatte und sich nun vollzeit der Weiterentwicklung von Minecraft widmete, griff er im Juli 2010 zu Beginn der Alpha-Versionen das Thema wieder auf: Er plante, dass Server-Funktionen beliebig zuschaltbar sein können (pluginable) und dies jedem möglich sein soll (open API). Man sollte seine eigenen Mods in Java schreiben und die Java-Klassendateien in den Serverordner stellen und dann über die server.properties dem Server mitteilen können, welche Mod er laden soll. Es sollte auch möglich sein, mehrere Mods zu laden[3].
  • Im September 2010 (zu Zeiten von Alpha 1.1) erstellte eine unabhängige Gruppe von Programmierern - darunter Dinnerbone und Grum, die damals noch nicht bei Mojang waren - eine Minecraft-Mod namens hMod, die Minecraft-Server mit verbesserten Funktionen ausstattete. Wie jede Mod musste auch diese laufend an neue Minecraft Versionen angepasst werden. hMod wurde mit Beta 1.2 eingestellt.
  • Mit der Alpha 1.2.2 (10. November 2010) wurde der neue Menüpunkt "Mods and Texture Packs" im Hauptmenü eingeführt, mit dem man dem Programm Mods und Texturenpakete hinzufügen können sollte. Allerdings funktionierte er nur für Texturenpakete.
  • Im Dezember 2010 begann die Beta-Phase, in der das Spiel fertiggestellt werden sollte. Notch schrieb in seinem Blog[4]: "Mit Beta wird das Spiel aufpoliert und es wird mehr Inhalt hinzugefügt. Wir werden früh damit beginnen, eine anständige Modifikations-Unterstützung einzubauen mit einer stabilen API und wir würden uns über jeden Vorschlag freuen, den wir von den Modifizierern da draußen bekommen können." Dieses Angebot nahmen einige ehemalige hMod-Programmierer (unter anderem Dinnerbone und Grum) wahr, die gerade dabei waren, unter dem Namen Bukkit eine neue Mod für Minecraft-Server zu entwickeln. Sie trafen sich mit Mojang-Mitarbeitern, um über die Modifizierungs-Unterstützung zu sprechen[5].
  • Im April 2011 wurde der Fertigstellungstermin der ersten Vollversion auf Mitte November 2011 festgelegt und Notch machte sich genauere Gedanken über die API, die er bis dahin noch einbauen wollte[6]: "Es werden bereits großartige Mods gemacht und es wird unmöglich sein, dass wir eine API zur Verfügung stellen können, die so gut und dynamisch sein wird, um all das zu unterstützen, was es bereits gibt. Ich möchte weiterhin unbedingt, dass Modifikationen ein Teil von Minecraft ist, aber ich bin nicht davon überzeugt, dass der richtige Weg darin besteht, monatelang an einer API zu programmieren, die zum Schluss die Modifizierer nicht überzeugen wird. Es gibt wahrscheinlich bessere Wege. Die Hauptprobleme sind, zu verhinden, dass jemand anderes unser Spiel verkaufen würde (außer er hat einen Lizenzvertrag mit uns) und sicherzustellen, dass Mods nicht mit jedem Spiel-Update neu geschrieben werden müssen."
  • Am 26. April 2011 veröffentlichte Notch einen Plan zur Unterstützung von Mods[7]: "Nach einigen internen Diskussionen und allgemeinen Bedenken haben wir einen Plan gefunden, um Mods zu unterstützen. Es ist noch ein bisschen vage und die Details könnte sich noch ändern, nachdem es unsere Rechtsanwälte bearbeitet haben, aber das haben wir vor:
    • Spieler können sich kostenlos als "Mod-Entwickler" eintragen lassen. Dabei stimmen sie einem Lizenzvertrag zu.
    • Mod-Entwickler können den Quellcode aus unserer Versionsverwaltung herunterladen. Sobald wir eine Änderung am Programm vornehmen, wird sie allen Mod-Entwicklern zur Verfügung stehen, unverschleiert und unzensiert.
    • Mod-Entwickler erhalten ein eindeutiges Zertifikat, um ihre Mods zu signieren. Das heißt, dass die Spieler genau sehen können, wer welche Mod gemacht hat und wählen können, welchem einzelnen Entwickler sie vertrauen wollen.
    • Die Lizenz wird folgende Regeln enthalten:
      • Mods dürfen nur von Spielern benutzt werden, die Minecraft gekauft haben.
      • Mods dürfen nicht verkauft oder anderweitig an ihnen verdient werden, außer man hat einen Lizenzvertrag mit uns.
      • Mods dürfen nicht schädlich sein (selbstverständlich).
      • Wir behalten uns das Recht vor, die Mod-Idee in das Spiel aufzunehmen. Diese Regel soll verhindern, dass wir eine bestimmte neue Funktion nur deshalb nicht ins Spiel bringen können, weil es irgendwo eine Mod gibt, die etwas Ähnliches macht. Außerdem können wir so Bugfixes ins Spiel nehmen, die von der Gemeinschaft kommen.
Auf lange Sicht hoffen wir, dass so viele atemberaubende neue Sachen mit Minecraft entstehen und damit gespielt wird. Wir haben vor, gute Mods zu kaufen oder zu lizensieren und sie selbst zu verkaufen. Wahrscheinlich wird es einen Marktplatz für Mods geben, wo man Mods verkaufen und kaufen kann, die Fans geschrieben haben oder wir kaufen und integrieren schöne Mods, die zum Minecraft -Konzept gut passen."
  • Am 10. Juni 2011 hieß es[8]: "Mit Beta 1.7 wird die Modifizierungs-Unterstützung in kleinem Rahmen beginnen. Wir werden den Quellcode vor der Veröffentlichung von Beta 1.7 einer sehr SEHR kleinen Gruppe von Mod-Entwicklern zur Verfügung stellen. Die Erfahrungen mit dieser Aktion lassen wir in die endgültigen Details zur Ausgestaltung einfließen. Dann werden wir die Mod API so bald wie möglich nach der Beta 1.7 veröffentlichen."
  • Doch am 15. November, drei Tage vor der Veröffentlichung des fertigen Spiels hieß es leider[9]: "Die letzten Wochen waren unglaublich stressig und in vielerlei Hinsicht emotional aufwühlend und ich bin so erleichert, endlich eine fertige Minecraft-Version zu haben, die wir der Welt am Freitag präsentieren können. (...) Eine Sache, die uns irgendwie durch die Lappen gegangen ist, ist die Mod-Unterstützung. Das tut mir leid und ich übernehme die volle Verantwortung dafür, dass das vergessen wurde. Aber wenn der neue Launcher kommt, wird das Teil eines neuen, aufregenden Projektes sein, über das ich jetzt noch nicht sprechen kann."
  • Mit Veröffentlichung der Vollversion 1.0 am 18. November 2011 hatte der Menüpunkt "Mods and Texture Packs" für Mods immer noch keine Funktion und wurde daher in "Texture Packs" umbenannt. Notch übergab die weitere Entwicklung von Minecraft in die Hände von Jeb. Dieser erklärte in einem Interview, dass seine absolute Hauptpriorität auf der Erstellung einer Mod API läge. In einem anderen Interview sagte er, dass die größte Herausforderung einer Mod API darin läge, dass die Modifikationen ohne Änderung des Minecraft-Programms möglich sein sollen. Obwohl er es noch nicht so genannt hatte, beschrieb er damit das Plugin-Konzept für die Mod API.
  • Die Vollversion 1.1 (12. Januar 2012) enthielt eine neue Kommunikation zwischen Client und Server, die sogenannten Plugin Channels. Das löste das große Problem, sich mit einem beliebig modifizierten Client an einem beliebig anders modifizierten Server anzumelden, ohne dass das Spiel abstürzt. Das Konzept für die Plugin Channels wurde nicht von Mojang, sondern vom Bukkit-Team, das als Server-Mod-Hersteller sehr an einer Lösung interessiert war, mit Unterstützung von Mojang für Minecraft entwickelt[10]. Version 1.1 war somit der erste von vielen Schritten zur Mod API.
  • Mit der Vollversion 1.2 (12w07a) wird am 5. Februar 2012 das Anvil Format eingeführt, das unter anderem die maximale BlockID von 256 auf 4096 erhöht, womit genug Platz für zusätzliche Blöcke von Mods geschaffen wird.
  • Einen Tag vor Veröffentlichung der Vollversion 1.2 (28. Februar 2012) verließen die vier Hauptentwickler von Bukkit (Dinnerbone, Grum, EvilSeph und Tahg) ihr Projekt und wechselten zu Mojang[11]. Sie hatten die Aufgabe, den Vanilla Minecraft-Server genauso flexibel und vielseitig zu gestalten, wie er es mit der Bukkit-Mod war. Geplant war zuerst eine neue Mod API für Server, später soll dann auch das Modifizieren auf Client-Seite unterstützt werden. Die offizielle Bezeichnung für die Mod API lautete nun Minecraft API[12].
  • Im März 2012 erläutert Jeb in einem Interview auf der GDC (Games Developer Conference) Details zur geplanten Minecraft API: Die Plugins sollen so einfach wie möglich zu finden, herunterzuladen und zu installieren sein[13].
  • Bei Veröffentlichung der Vollversion 1.2.5 (1.2.5 Pre) (30. März 2012) verkündete Mojang, dass die Minecraft API mit Beteiligung der Minecraft-Community entwickelt werden sollte[14]. Am 30. Juni war es dann soweit: im Minecraftforum fand eine öffentliche Diskussionsrunde statt. Eine Zusammenfassung der Ergebnisse wurde von Mojang-Mitarbeiter EvilSeph hier veröffentlicht.
  • Mit der Vollversion 1.3 (12w18a) (3. Mai 12) wurde die Möglichkeit von Server-Texturenpaketen eingeführt. Ein Server-Texturenpaket konnte in den server.properties angegeben werden und wurde dem Client zum Download angeboten, falls er es nicht installiert hatte. Dieses Feature war ein weiterer Schritt zur Minecraft API.
  • Mit der Vollversion 1.3 (12w27a) (5. Juli 2012) wurde im Hinblick auf die Minecraft API die bislang getrennt programmierte Einzel- und Mehrspielerversion von Minecraft zusammengefasst, damit man eine Mod nicht zwei Mal hinzufügen musste[15].
  • In der Zeit der Veröffentlichung der Vollversion 1.3 (1.3 Pre) (26. Juli 2012) schrieb Dinnerbone die erste Java-Klasse für die Minecraft API und nannte sie Workbench[16].
  • Mit Veröffentlichung der Vollversion 1.3 (1. August 2012) startete Mojang eine Webseite, auf der Vorschläge für die Minecraft API gesammelt werden konnten: Minecraft API Proposal System.
  • Am zweiten Tag der Minecon 2012 (25. November 2012), kurz nach Veröffentlichung der Vollversion 1.4.5 verkündete Jeb in einer Präsentation[17] die Pläne für die API, die nun offiziell Plugin API genannt wurde, weil man die Minecraft-Modifikationen ohne Änderung der Programmdatei hinzufügen (= plugin) können sollte[18]. Auf die Entwicklung der Plugin API wurde damals auch auf den aktuellen Hilfeseiten des Mojang Customer Support hingewiesen.
  • Mit der Vollversion 1.5 (13w02a) (10. Januar 2013) wurden die Texturen für Gegenstände, die im Programm minecraft.jar bisher in gemeinsamen Dateien zusammengefasst waren (terrain.png und /gui/items.png) in einzelne Dateien aufgeteilt (in den Ordnern textures/blocks und /textures/items). Dadurch wurde die Änderung einer einzelnen Textur wesentlich vereinfacht. Gleichzeitig wurde die Animation von beweglichen Texturen aus dem Programm in den Texturenordner ausgelagert. Jetzt konnte man animierte Texturen ändern, ohne in den Programmcode eingreifen zu müssen. Außerdem konnten nun HD-Texturen mit höherer Auflösung als nur 16×16 Pixel erstellt werden.
  • Mit der Vollversion 1.5 (13w03a) (17. Januar 2013) wurde der Menüpunkt für das Aktivieren von Texturenpaketen vom Hauptmenü in das Pausenmenü verschoben, wodurch man Texturenpakete jetzt während des Spiels aktivieren und deaktivieren konnte. Das war ein Schritt in die Richtung, dass Texturenpakete nicht mehr für das gesamt Spiel gelten sollten, sondern für jede einzelne Welt individuell hinzugeschaltet werden könnten.
  • Mit der Vollversion 1.6 (13w16a) (18. April 2013) wurde ein neuer Launcher veröffentlicht, der den Weg für die Plugin API ebnete. Er erhielt kurz darauf einen "Local Version Editor", der alle Einstellungen zum Starten des Programms minecraft.jar anzeigte, die man in diesem ersten Schritt allerdings noch nicht ändern konnte. Gleichzeitig wurde die Ordnerstruktur der Standard-Ressourcen geändert, die ab jetzt assets (Bestandsdaten) genannt wurden:
    • Im Programm minecraft.jar wurden im /assets-Ordner neben den Texturen auch einige Texte (Splash-Texte, Epilog) und eine Datei für die Schriften hinterlegt.
    • Im .minecraft-Ordner wurden im /assets-Unterordner die Sounds und die aus minecraft.jar ausgelagerten Sprachendateien als Standard-Ressourcen zusammengestellt.
Das deutete an, dass man zukünftig alle diese Ressourcen ändern können wird.
  • Mit der Vollversion 1.6 (13w24a) (13. Juni 2013) wurde der bisherige Menüpunkt zum Aktivieren von Texturenpaketen ersetzt durch das Menü/Optionen/Ressourcenpakete, mit dem man nun Ressourcenpakete während des Spiels aktivieren und deaktivieren konnte. Gleichzeitig bekamen die Ressourcenpakete eine Hierarchie, sodass man jetzt ein Mini-Ressourcenpaket zum Ändern einer einzigen Textur oder eines einzigen Sounds erstellen konnte. Die Einführung der Ressourcenpakete war ein großer Schritt Richtung Plugin API[19]. Ein Minecraft-Ressourcenpaket ist eine Sammlung von Dateien, die ohne Veränderung des Programms hinzugefügt (= plugin) werden kann. Dinnerbone erklärte, dass zukünftig jede Mod (Programmmodifikation), jedes Plugin (Änderung ohne Programmmodifikation) und auch die Standard-Ressourcen von Minecraft als Ressourcenpaket behandelt werden würden[20]. In diesem Zusammenhang wurde mit JSON ein strukturiertes Datenformat für Metadaten eingeführt. Teil der Plugin API sind also JSON-Dateien.
  • Mit der Vollversion 1.7 (13w36a) (5. September 2013) wurden die ersten Befehle zur Verfügung gestellt, die NBT-Daten als Parameter enthalten konnten. Das war ein gewaltiger Schritt, denn die NBT-Daten sind alle Daten, die beim Speichern des Spiels in Dateien geschrieben werden. Mit Hilfe der NBT-Parameter konnte man jetzt ohne Mods auf Spielelemente zugreifen, die bislang nicht erreichbar waren (z.B. Riesen).
  • Mit der Vollversion 1.7 (13w37a) (12. September 2013) wurden die ID-Namen eingeführt. Statt einer Zahl (1 für Stein) bekam jeder Gegenstand nun den Namensraum "minecraft" (z.B. minecraft:stone), sodass man zukünftig mit anderen Namensräumen auch auf Gegenstände von Mods zugreifen können wird.
  • Mit der Vollversion 1.7 (13w38a) (19. September 2013) wurden die Shader eingeführt. Zuerst war das nur eine einfache Sammlung von Grafikeffekten, ab Vollversion 1.8 (14w05a) wurden dann die ersten Shader im Spiel verwendet. Die Shader sind Teil der Standard-Ressourcen und können folglich über ein Ressourcenpaket geändert werden. Die zugehörige API besteht aus GLSL- (OpenGL Shader Language) und JSON-Dateien.
  • Seit der Vollversion 1.7 (13w39b) (27. September 2013) weist Minecraft im Startbildschirm auf eine veraltete OpenGL-Version hin. Das Spiel wird zukünftig mit OpenGL 2.1 laufen, was eine der Voraussetzungen für die Plugin API ist[21].
  • Große Teile der Vollversion 1.7 (1.7.2 Pre) (25. Oktober 2013) wurden als Vorbereitung für die Plugin API umgeschrieben. Das war mit ein Grund, warum das Update 1.7 den Namen The Update that changed the World trug[22].
  • Auf der Minecon 2013 (2. November 2013), die kurz nach der Veröffentlichung der Vollversion 1.7 stattfand, wurden zwei neue Mojang-Mitarbeiter vorgestellt[23] die die Arbeit an der Plugin API unterstützen sollen: Michael Stoyke, der das Minecraft Coder Pack entwickelt hat, und Ryan Holtz von der amerikanischen Spieleentwicklerfirma Bat Country Entertainment.
  • Mit der Vollversion 1.8 (14w06a) (6. Februar 2014) wurden die Konstruktionsmodelle für die dreidimensionale Darstellung als Standard-Ressource ausgelagert. Das war wieder ein wichtiger Schritt für die Plugin API, denn nun konnte man - zunächst nur für Blöcke - erstmals ohne Programmänderung das dreidimensionale Aussehen von Spielelementen ändern. Mit einem Ressourcenpaket konnte man nun nicht nur fotorealistische HD-Texturen ins Spiel bringen, sondern auch z.B. die Rillen in Gemeißelten Steinziegeln plastisch darstellen.
  • Mit der Vollversion 1.8 (14w07a) (14. Februar 2014) konnte man in einer Welt ein Welt-Ressourcenpaket integrieren. Damit konnte man z.B. Abenteuerwelten mit veränderten Ressourcen erstellen: Abenteuerwelten, die durch das Hinzufügen (= plugin) einer Datei modifiziert wurden. Außerdem wurde mit dieser Version das komplette Inventarsystem in Vorbereitung auf die Plugin API intern umgestellt[24]: Gegenstände im Inventar konnten jetzt fremde NBT-Daten haben, die von Vanilla-Minecraft nicht beachtet wurden. Damit war es möglich geworden, Gegenständen Eigenschaften zu geben, die nicht von Minecraft, sondern von Plugins verarbeitet werden.
  • Mit der Vollversion 1.8 (14w08a) (19. Februar 2014) wurden die Generierungscodes von Flachland-Welten auf ID-Namen umgestellt.
  • Mit der Vollversion 1.8 (14w11a) (13. März 2014) wurde das Konzept des Blockzustands hinzugefügt. Damit wird für jeden Block festgelegt, welche Zustände er haben kann und wie sich diese optisch voneinander unterscheiden.
  • Mit der Launcher-Version 1.4.2 (2. Mai 2014) wurde der "Local Version Editor", der bislang den Zusatz "NYI" (not yet implemented = noch nicht fertiggestellt) hatte, wieder aus dem Launcher entfernt.
  • Mit der Vollversion 1.8 (14w25a) (18. Juni 2014) wurden die dreidimensionalen Konstruktionsmodelle auch für Gegenstände eingeführt (wenn man sie in der Hand hält oder als Drop).
  • Mit der Vollversion 1.8 (14w26a) (25. Juni 2014) wurde der Welttyp Debug-Modus hinzugefügt, der alle Blöcke in allen Zuständen anzeigt, sodass man Änderungen an den Texturen oder Blockmodellen leicht testen kann.
  • Mit der Vollversion 1.8 (14w28a) (9. Juli 2014) wurden ID-Namen auch für Statuseffekte und Verzauberungen eingeführt. Gleichzeitig wurde nach 5 Monaten die Arbeit an den Konstruktionsmodellen für abgeschlossen erklärt[25].
  • Bukkit ist eine zusätzliche API für Minecraft, die durch Modifizierung des Programms zur Verfügung gestellt und vor allem von Serverbetreibern weltweit genutzt wird. Im August 2014 gaben die bisherigen Bukkit-Entwickler ihre Arbeit auf. In der anschließenden Diskussion bot Dinnerbone seine Hilfe an, betonte aber, dass Bukkit nicht die offizielle Plugin API von Minecraft sei[26].
  • Am 30. April 2015 präsentierte Microsoft das Minecraft Mod Developer Pack, einen neuen Zusatz für sein Entwicklungswerkzeug "Visual Studio", mit dem man Minecraft-Mods erstellen kann. Das führte zu einiger Verwirrung[27], weil es so schien, als ob damit die offizielle Mod API veröffentlicht sei - immerhin ist Microsoft seit Ende 2014 der neue Eigentümer von Mojang und Minecraft. Doch Dinnerbone stellte klar[28], dass Mojang das Modifizieren zwar duldet, aber nicht offiziell unterstützt. Der offizielle Weg wird die Plugin API sein, an der weiterhin gearbeitet würde[29]. Auf die Frage, wo die Plugin API denn bleibe, antwortete Dinnerbone, dass man nicht etwas Unausgegorenes herausgeben, sondern es solange verbessern möchte, bis es wirklich gut ist[30].
  • Mit der Vollversion 1.9 (15w31a) (29. Juli 2015) gab es Erweiterungen der Modelldaten: Nun können auch Gegenstände Zustände haben, was Modelle für bewegliche Gegenstände wie Bogen, Kompass etc. ermöglicht.
  • Mit der Vollversion 1.9 (15w43a) (21. Oktober 2015) wurden die bisher im Programm enthaltenen Regeln zur Generierung von Beute in Truhen, von getöteten Kreaturen und beim Angeln in Beutetabellen ausgelagert. Damit können nun Truhen mit beliebigem Inhalt und Kreaturen mit beliebigen Drops erzeugt werden, verknüpft mit Wahrscheinlichkeiten und Bedingungen.
  • Am 10. August 2016 wurde nach längerer Entwicklungsarbeit mit Vollversion 1.11 (16w32a) die erste Entwicklungsversion von 1.11 veröffentlicht, bei der sämtliche ID-Namen von Objekten und Blockobjekten in Format und Schreibweise an die Block-ID-Namen und Gegenstand-ID-Namen angepasst wurden.
  • Am 25. September 2016 wurde auf der MineCon die geplante Plugin API für die Pocket Edition vorgestellt. Die Pocket Edition wurde bereits 2011 begonnen und hinkte der Java Edition inhaltlich lange Zeit hinterher. Seit dem Verkauf von Mojang an Microsoft wurde jedoch verstärkt daran gearbeitet. Die Unvollständigkeit hat aber auch den Vorteil, dass man noch die Möglichkeit hat, Konzepte einzubauen, deren Realisierung in der Java Edition sehr aufwändig wäre. So wurden bereits im Juni 2016 Add-Ons für die Pocket Edition angekündigt[31]. Das sind JSON-Skripte, mit denen man vorhandene Spielelemente modifizieren kann. In der Java Edition gibt es das auch, aber nicht in dem Ausmaß und nicht für Kreaturen. In der Java Edition kann man nur die NBT-Daten von Kreaturen manipulieren, nicht aber Funktionen austauschen. Auf der MineCon wurde die Funktionsweise der Add-Ons demonstriert. Danach demonstrierte Searge die geplante Plugin API[32]. Sie sollte nach ihrer Fertigstellung das Modifizieren der Pocket Edition und der Windows 10 Edition über C#-Plugins ermöglichen. Die Java Edition würde diese Plugin API nicht bekommen.
  • Mit der Vollversion 1.12 (17w14a) (5. April 2017) wurden die bisher fest programmierten Erfolge in Fortschritte geändert, die nun als Fortschrittsdaten in den Standard-Ressourcen hinterlegt sind und im Weltordner angepasst und erweitert werden können. Außerdem wurden die Handwerk-Rezepte als Rezeptdaten in die Standard-Ressourcen ausgelagert. Sie werden im Rezeptbuch angezeigt, können aber noch nicht geändert oder erweitert werden.
  • Mit der Vollversion 1.13 (17w43a) (25. Oktober 2017) wurden Datenpakete hinzugefügt, die ähnlich wie Ressourcenpakete funktionieren, jedoch individuell geänderte Daten für eine bestimmte Welt enthalten. Im Gegensatz zu den Ressourcenpaketen können sie über einen Befehl ein- und ausgeschaltet werden. Mit weiteren 1.13-Entwicklungsversionen wurden Rezepte änderbar gemacht, es können auch neue hinzugefügt werden. Außerdem wurden Aliasdaten hinzugefügt, um ID-Namen zu Gruppen zusammenfassen zu können. Die Metadaten wurden komplett aus dem Spiel entfernt. Die Blockvarianten, die bisher über Metadaten abgebildet wurde, erhielten dadurch eigene ID-Namen. Aus der zweistufigen Identifizierung (Block-ID-Name + Metadaten) wurde eine einstufige (nur ID-Name). Außerdem wurden immer mehr Minecraft-Daten mit einem Namensraum versehen.
  • Am 3. Januar 2018 wurde mit Vollversion 1.13 (18w01a) der Datengenerator veröffentlicht, mit dem Daten aus der minecraft.jar extrahiert werden können.
  • Obwohl immer mehr Daten über JSON-Skripte geändert werden können, sagt Jeb im Januar 2018, dass es für die Java Edition zur Zeit keine konkreten Pläne für eine Modding API gibt[33].
  • Am 10. Juli 2018 wurden mit Vollversion 1.13 (1.13-pre7) Definitionsdateien für Schriftdaten hinzugefügt. Damit ist es möglich, beliebige Zeichen nicht nur in der Unicode-Schrift, sondern auch in der Minecraft-Schrift darzustellen.

Geschichte (Bedrock Edition)[Bearbeiten]

Auf der Minecon 2016 erläuterte Searge das Konzept der Plugin API und die weiteren Pläne:

  • Add-Ons sind Veränderungen der vorhandenen Eigenschaften des Spiels durch JSON-Skripte.
  • Plugins sind Erweiterungen des Spiels mit völlig neuen Eigenschaften durch C#-Programme.
  • Sie sind voll kompatibel mit den Add-Ons.
  • Sie werden quelloffen weitergegeben, so dass jeder lesen kann, was sie machen und sich interessante Dinge herauskopieren kann.
  • Sie werden beim Starten des Spiels geladen und mit dem Mono C# Compiler kompiliert.
  • Im Gegensatz zu den Java-Mods gibt es ein Sandbox-System zur Sicherheit, damit die Plugins keinen Schaden auf dem Computer anrichten können.
  • Sie können eine eigene API definieren, die von anderen Plugins genutzt werden kann.
  • Über ein Manifest kann man harte und weiche Abhängigkeiten zu anderen Plugins festlegen. Eine harte Abhängigkeit bedeutet, dass das Plugin nur zusammen mit dem anderen Plugin funktioniert. Eine weiche Abhängigkeit bedeutet, dass das Plugin auch alleine funktioniert, aber zusammen mit dem anderen Plugin neue Funktionen zur Verfügung stellt.

Das war der Entwicklungsplan:

  • Die Grundlagen waren bereits im September 2016 fertig, Searge zeigte eine Demo auf der MineCon.
  • Als nächstes sollten alle existierenden Spielfunktionen als API zugänglich gemacht werden.
  • Im zweiten Schritt sollte die Hinzufügung neuer Spielfunktionen ermöglicht werden.
  • Es waren Beispiele, Dokumentationen und Hilfsprogramme geplant.
  • Die erste benutzbare Version sollte im Frühjahr 2017 fertig sein.
  • Die Windows 10 Edition sollte die neuen Funktionen auf jeden Fall haben. Die Pocket Edition sollte folgen, sobald Lösungen für die einzelnen Plattformen gefunden sind. Die Konsolenedition sollte folgen, sobald sie mit der Pocket Edition kompatibel ist. Die Java Edition würde diese Funktionen nicht bekommen.

Die volle (englische) Präsentation kann hier angeschaut werden, die Präsentation der Plugin API beginnt bei 16:24

Allerdings wurde 2017 keine Plugin API für die Bedrock Edition veröffentlicht. Stattdessen wurde im Juli 2017 bei Mojang eine neue Programmiererstelle für dieses Thema ausgeschrieben[34].

Einzelnachweise[Bearbeiten]

Promotional Content