Neue Minecraft 1.17 Blöcke

Wochenrückblick: Update des Bauservers, Minecraft 1.17 und Gradle

Wochenrückblick4. Juli 2021

Allgemein

In den letzten Wochen wurde alles für den Umstieg auf Minecraft 1.17 vorbereitet. Für die Meisten von uns ist die Prüfungszeit noch nicht vorbei. Dadurch kommt die Entwicklung in vielen Bereichen etwas langsamer voran, als wir uns erhofft haben. Wie die Situation genau aussieht, werden wir in der nächsten Woche näher erläutern, denn heute (drei Stunden vor Erscheinen der News) fand unsere monatliche Teambesprechung statt.

Minecraft 1.17

Die Neuerungen, die mit Minecraft 1.17 dazu kommen sind gewaltig. Wir können uns nicht nur auf Axolotl und Leuchttintenfische freuen; hinzu kommen auch viele neue Dekoblöcke, Kupfer als Erz und vor allem neue Möglichkeiten, die Beleuchtung zu steuern. Hiervon werden wir sicher stark profitieren, denn Licht ist immer eine gute Möglichkeit, die wirklich interessanten Orte und Verstecke hervorzuheben.

Freitag ist es uns als ersten Schritt gelungen, den Bauserver und unsere eigenen Tools dafür auf die neue Version upzudaten. Nun also können unsere Builder beginnen, ein Gefühl für die neuen Möglichkeiten zu gewinnen und zu planen, wie wir sie auf dem PvP einsetzen wollen.

Wie zu erwarten, ging das alles nicht ganz ohne Fehler vonstatten. Gestern (am 03.07.2021) haben wir mit einem Patch nachgebessert und konnten seitdem keine Auffälligkeiten mehr entdecken. Wir warten zwar noch auf das Update von einem unserer externen Bau-Tools, doch hier gab es schon erste Zeichen dafür, dass wir nicht lange warten müssen. Dies stimmt uns optimistisch, dass das Updaten des PvP-Servers keine Hürde darstellen wird!

Die neuen Blöcke wurden direkt am Spawn verbaut

Auch für die Entwickler ist 1.17 ein Segen, denn es setzt nun die Programmierung mit Java 16 voraus und führt einige interessante Neuerungen für die Arbeit mit den internen Abläufen des Minecraft-Servers ein. Während wir auch schon zuvor mit Java 16 hätten programmieren können, gab es hier immer wieder Probleme mit den (wenigen) externen Abhängigkeiten, die wir verwenden. Dass Minecraft nun fest mindestens Java 16 voraussetzt, sorgt dafür, dass die Entwickler diese Abhängigkeiten ebenfalls auf Java 16 aktualisiert haben.

Darüber hinaus arbeiten wir mit einem vorausgesetzten Ressourcenpaket, welches bei der zuvor standardmäßig mit Minecraft ausgelieferten Java-Version (wegen der verwendeten Verschlüsselung) nicht heruntergeladen werden konnte. Da nun auch der Client auf Java 16 setzt, profitieren wir hier insbesondere von dem Update.

Um zu erklären, warum wir für das Update unseres Beta-Servers vermutlich noch eine kleine Weile benötigen werden, muss ein wenig ausgeholt werden. Die Kurzfassung ist, dass wir auf ein externes Tool warten, was es uns ermöglicht auch nach Änderungen an dem internen Code von Minecraft gut wartbaren Code zu schreiben. In der ausführlichen Fassung wird es technisch:

Mojang (die Firma hinter Minecraft) "verschleiert" (obfuscated) den Quellcode der ausführbaren Dateien für den Betrieb des Servers vor der Veröffentlichung. Wir können den ursprünglichen Quellcode, mit dem der Minecraft-Server läuft, also nur in veränderter Form nachvollziehen. So heißt dann eine Eigenschaft eines Objektes, die im originalen Code player gehießen hat, nun schlicht b. Dies wird primär aus Gründen des Kopierschutzes getan. Die Entwickler der Server-Softwares für Minecraft mussten so für ihre Änderungen immer aus dem Kontext nachvollziehen, welche Rolle eine solche Eigenschaft wirklich spielt, weil sie aus dem Namen nicht länger ersichtlich ist.

Nun veröffentlicht Mojang aber seit geraumer Zeit sogenannte "Mappings". Das sind im weitesten Sinne Protokolle der Umschreibungen, die bei der Veröffentlichung vorgenommen wurden. Mit diesen Dateien kann der Quellcode (für die Entwicklung) wieder zu seinem ursprünglichen Zustand zurückversetzt werden und der Inhalt wird viel verständlicher. Bislang hatten die Entwickler der Server-Softwares ihre eigenen Mappings gepflegt und wir konnten auf ihnen aufbauend ebenfalls Änderungen für unsere Funktionen vornehmen und so in sehr interne Prozesse eingreifen, für die keine offiziellen Schnittstelle zur Verfügung gestellt werden.

Mit Minecraft 1.17 sind die Entwickler aber auf die Verwendung der Mojang-Mappings umgestiegen. Aus Lizenzgründen muss die ausführbare Server-Datei aber bei der Veröffentlichung nun ebenfalls wieder "verschleiert" werden. Für uns als Plugin-Entwickler bedeutet dies: Wir erhalten nur die kryptischen Bezeichner und die Wartung unseres Codes gestaltet sich unheimlich aufwendig und verwirrend.

Das Update unserer Plugins auf 1.17 ist bereits seit neun Tagen fertig, aber wir möchten noch auf eine Verbesserung der Entwickler von Paper warten. Hier wird an einem Tool gearbeitet, das es ermöglicht die Plugins gegen den originalen Quellcode zu entwickeln und so von der guten Lesbarkeit zu profitieren, um dann abschließend alles vollautomatisch wieder umschreiben zu lassen. Bis dieses Tool entwickelt wurde, werden wir mit dem Update auf 1.17 also vorerst noch warten.

Unendliche Tiefen

Minecraft 1.17 ist der erste Teil des sogenannten "Caves & Cliffs-Update" und wird als das größte Update bezeichnet, welches die Java-Edition je bekommen hat. Weil wir hierzu von einigen Betatestern gefragt wurden, ob der PvP hiervon profitieren wird, hier mal ein kleiner Ausblick:

Caves & Cliffs beginnt mit neuen Blöcken und Tieren, doch es bereitet auch eine noch viel gravierende Neuerung vor: Mit dem zweiten Teil des Updates (Version 1.18), welches Ende 2021 erscheinen soll, kommt neben weiteren Blöcken und Kreaturen die Möglichkeit dazu, Welten zu erschaffen, die über 1.000 Blöcke tief bzw. hoch sind.

Dies ermöglicht realistischere Berge, neue Untergrundbiome und fantastische Höhlensysteme. Wer es dann noch schafft, sich bis zum Boden der Welt vor zu graben, hat sicher einiges währenddessen erlebt. Wir können es kaum erwarten hiermit zu experimentieren, denn wir wollen bei der Farmwelt definitiv Gebrauch davon machen.

Gradle

Zum Abschluss noch ein technisches Thema: Während die meisten anderen Entwickler zeitlich recht eingebunden waren, hat Scrayos die Gunst der Stunde genutzt, um den Umzug von Maven auf Gradle zu beginnen. Maven und Gradle sind zwei Build-Systeme, die wir für Zusammenbau, Testen und Ausliefern unserer Applikationen verwenden. Aktuell laufen noch alle unserer Applikationen mit Maven. Das liegt auch daran, dass unsere Projekte historisch gewachsen sind und zu der Zeit, zu der wir die Arbeit an diesen Projekten begonnen hatten, Gradle gegenüber Maven noch deutlich unbekannter und schlechter unterstützt war.

Hier zur Erinnerung noch einmal eine unserer Build-Pipelines. Während dieses Build noch mit Maven entstanden ist, können wir schon bald ein solches Bild mit Gradle präsentieren.

Nun haben wir mit der Migration unserer Bibliothek aber einen ersten Schritt in Richtung Gradle unternommen, um von einigen Vorteilen dieses Build-Systems Nutzen zu machen:

  • Wesentlich schnellere lokale Builds: Gradle unterstützt sogenanntes "inkrementelles Kompilieren". Damit müssen beim Kompilieren immer nur die Klassen aktualisiert werden, die sich seit dem letzten Kompilieren verändert haben. Das spart einige Zeit, in der wir so nicht mehr auf den Rechner warten müssen, sondern direkt weiter testen und entwickeln können.

  • Klarere, geordnete Konfiguration mit Code: Gradle unterstützt als eine der Sprachen für die Konfiguration "Kotlin", ein auf der virtuellen Maschine von Java aufbauender Dialekt. Hiermit sind wesentlich kürzere und sehr gut lesbare Konfigurationen möglich, für die darüber hinaus sogar direkt Vervollständigung durch die Entwicklungsumgebung angeboten wird.

  • Leichtere Erstellung von Plugins für das Build-System: Es ist wesentlich leichter für Gradle eine Erweiterung zu erstellen, als es bei Maven der Fall ist. Wir können also mit vergleichsweise geringem Zeitaufwand Änderungen an der Art und Weise vornehmen, wie wir unsere Applikationen und Plugins zusammenbauen.

  • Bessere Verwaltung der Abhängigkeiten: Abhängigkeiten werden in Gradle feiner aufgedröselt und sind so auf einen Blick besser ersichtlich bzw. können zwischen verschiedenen Verwendungszwecken gefiltert werden, um zu jedem Zeitpunkt nur die Abhängigkeiten zu berücksichtigen, die für die jeweilige Etappe relevant sind.

  • Einsicht in den Ablauf des Build-Prozesses: Gradle bietet sogenannte "Scans" an, die uns noch viel detailliertere Einblicke in die interne Arbeitsweise des Build-Systems ermöglichen und durch die wir so Verbesserungen vornehmen können, um die Korrektheit und das schnelle Zusammensetzen unserer Projekte voranzutreiben.

In einer der nächsten Wochen werden darüber hinaus auch weitere Informationen zu unseren Schwierigkeiten beim Umstieg und den tatsächlichen Änderungen, die sich in unseren Pipelines hierdurch ergeben haben, erscheinen. Wir geben euch via Discord, Instagram und per Twitter Bescheid, wenn es Neuigkeiten gibt. Deshalb lasst gerne ein Abo da, um nichts zu verpassen!