Hallo Ihr Pixelschieber!
Heute wird’s etwas technisch, es geht nämlich um unser Bedrock-Plugin. Das werden viele gar nicht kennen, und noch weniger kommen damit direkt in Berührung. Aber warum heißt es wie das Minecraft-Grundgestein? Was kann Bedrock? Und warum erzähle ich (nochmal) davon? Hier ein sehr ausführlicher Ein-/Ausblick.
Bedrock ist, kurz gesagt, unsere (Bukkit-/Spigot-) Plugin-Basis. All unsere Plugins hängen davon ab. Es bietet uns Entwicklern (und Euch) eine Code-Basis für wiederkehrende Funktionen, wie:
- Hübsche und vor allem klick- und hover-bare Chat-Ausgaben der Plugins
- Eine einheitliche Hilfe
- Ein mächtiges Rechtemanagement für Pluginfunktionen
- Paginierbare Listen (also sowas mit Seitenzahlen um nicht alles auf einen Schlag auszugeben)
- Inventar-Funktionen
- UUIDs aller Spieler und aktuelle Benutzernamen
- Verschiedene Farbschemata (wir mögen’s halt bunt)
- Und wenn wir uns die Mühe machen wollten weitere Sprachdateien anzulegen, sogar Mehrsprachensupport für alle Plugins.
Für die reine Entwicklung nimmt es uns auch viel Arbeit ab, die wir sonst in jedem Plugin wieder und wieder machen müssten. Stellt es Euch also als Rahmenwerk vor, um das wir unsere Plugins herumbauen. Wie ein Fahrzeuggestell, das je nach Karosserie und Ausstattungsvariante ein anderes Modell ergibt. Aus diesem Grund heißt es auch Bedrock. Eben die Basis auf der alles ruht. Der Vorteil davon? Wir können neue Plugins schneller entwickeln und Fehler in bestehenden Plugins schneller finden, da wir uns nur noch auf die reine Pluginfunktionalität konzentrieren müssen.
Ich erzähle übrigens nochmal davon, weil wir uns mit allen Features die Bedrock beinhalten soll auf die Version 1.0 zubewegen. In der Softwareentwicklung ist das ein Meilenstein, der die erste release-fähige und stabile Version einer Software definiert, die sich in ihrem Grundverhalten und den Grundfunktionen nicht mehr ändert. Heißt: Wir haben etwas zu feiern =)
Natürlich können (und werden) im Laufe der Zeit weitere Funktionen hinzukommen, die Struktur steht aber fest und wird nicht mehr verändert. Es fehlen noch zwei oder drei Features bis zur 1.0 – lang wird’s aber nicht mehr dauern.
In der Zwischenzeit haben wir (auch während der Entwicklung von Bedrock) einige Plugins auf Bedrock um- bzw. neu gebaut, als da wären das Shop-Plugin (das zu meiner – und hoffentlich auch Eurer – vollsten Zufriedenheit funktioniert), das Zonen-Plugin, das Vote-Plugin, das PVP-Plugin, das Death-Plugin, das Nicht-Olymp²-Plugin und natürlich den UUIDHamster (ja, der heißt wirklich so)
Damit Ihr aber auch mal seht, was da wirklich an Arbeit drinsteckt, hab ich Euch aus unserem git (1) mal ein paar Zahlen besorgt:
- 6.322 Codezeilen (davon 4.311 reine Codezeilen ohne Kommentare/Dokumentation, Leerzeilen, etc)
- 342 Commits (2), veteilt auf
- 216 von d1rty mit 9.839 hinzugefügten und 6.649 gelöschten Zeilen
- 126 von blacksheep mit 7.292 hinzugefügten und 3.984 gelöschten Zeilen
- 18 Branches (3)
- 112 Jenkins-Builds (4)
Hier noch unsere Punchcard (5):
Übrigens, die meissten Commits haben wir Ende Juli/Anfang August gemacht. Semesterferien und Urlaub lassen grüßen 😉
Ich hoffe, ihr konntet heute mithalten. Bei Fragen dürft könnt sollt Ihr wie immer fragen. Wenn ich mich wieder mal zu technisch unverständlich ausgedrückt hab, sollen Anmerkungen dazu, aber auch was Euch sonst noch so interessiert – wie immer – in meine Richtung =)
Viele Grüße
d1rty
1) Git ist ein Werkzeug zur Versionierung von allem was in irgendeiner Form gespeichert werden kann (in diesem Fall Text, bzw. Programmcode). Jede “Version” eines Programms ist immer wieder auf- und abrufbar. Damit kann man Änderungen rückgängig machen, verschwinden lassen und wieder herbei holen.
2) Commits sind “Hey git, ich hab hier Änderungen die ich bei Dir speichern möchte, leg das bitte mal als neue Version ab” und reichen vom Umfang her von “ich hab eine Codezeile geändert” bis hin zu “Plugin XY kann jetzt ein neues Feature”.
3) Branches werden genutzt, um Entwicklungszweige zu realisieren, um bspw. neue Funktionen in ein Programm einzubauen. Wenn zwei oder mehr Entwickler an einem Projekt arbeiten, kann es stören, wenn Entwickler A etwas am Code ändert, den Entwickler B ebenfalls gerade bearbeiten will. Daher erzeugt man einen neuen Branch, in dem man ungestört arbeiten kann. Ist man mit seiner Arbeit fertig, erstellt man einen sog. Pull-Request, der die Änderungen aus diesem Branch in die aktuelle Masterkopie (Master-Branch) des Projektes zurückschiebt. Wenn sich in der Zwischenzeit Änderungen einer Datei in beiden Versionen ergeben haben, müssen diese Änderungen allerdings von Hand begutachtet und sinnvoll zusammengefügt werden.
4) Wie einige vermutlich wissen, benötigt ein Bukkit-Server Plugins in Form von JAR-Dateien. Diese Dateien werden von einem Build-System (hier Jenkins) zur Verfügung gestellt. Es compiliert (übersetzt) den Java-Code in eine JAR-Datei und prüft, ob alle Plugins die davon abhängen oder betroffen sein können, ebenfalls noch funktionieren. Weiterhin prüft es, ob es Änderungen im Git gegeben hat und baut automatisch neue git-Versionen des Plugins, die man dann direkt auf dem Minecraft-Server testen kann.
5) Die Punchcard zeigt die Anzahl der Commits in einem Projekt (hier Bedrock) nach Tageszeiten pro Woche an. Wie man sehen kann, haben wir größtenteils Abends und Nachts gearbeitet bzw. comitted. Ist aber logisch, immerhin müssen wir tagsüber ja normalen Beschäftigungen nachgehen 😉