Minecraft-Plugin beauftragen: klare Abnahmekriterien
Bevor ihr ein individuelles Minecraft-Plugin beauftragt, solltet ihr drei Dinge festhalten: die unterstützte Umgebung, das erwartete Verhalten für Spieler und Team sowie die Nachweise für die Abnahme. Eine gelungene Vorführung hilft. Zur Übergabe gehört aber auch, was nach einem Neustart, einem unerlaubten Befehl oder dem Ausfall einer Abhängigkeit passiert.
Für eine gewachsene Community wird aus „Wir brauchen ein Event-Plugin“ so ein Auftrag mit prüfbarem Umfang. Als Beispiel dient eine Anmeldung für Veranstaltungen auf einem einzelnen Paper-Server. Das ist eine beispielhafte Spezifikation, kein verfügbares Mineando-Produkt und keine von uns getestete Implementierung.
Beschreibt zuerst den vollständigen Ablauf
Beginnt mit einem Spielerablauf statt mit einer Befehlsliste: Ein berechtigter Spieler meldet sich an, erhält eine Bestätigung und behält seinen Platz nach dem erneuten Verbinden. Das Team kann die Anmeldung schließen und die endgültige Liste einsehen. Klärt, ob eine Abmeldung einen Platz freigibt und ob die Anmeldung bereits die Teilnahme garantiert.
Trennt anschließend notwendige Funktionen von Erweiterungen. Teamzuweisung, Belohnungen, Anmeldung über eine Website und Discord-Benachrichtigungen sind unterschiedliche Liefergegenstände. Braucht die erste Version nur eine Liste im Spiel, gehört diese Grenze in die Beschreibung. Möglicherweise erfüllt ein vorhandenes, gepflegtes Plugin den Bedarf bereits. Individuelle Entwicklung lohnt sich, wenn die fehlende Funktion oder Anbindung für das Projekt entscheidend ist.
Bestimmt eine Person, die offene Regeln verbindlich klärt. Der Entwickler kann nicht wissen, ob Moderatoren die Teilnehmergrenze überschreiten dürfen oder ob ein Verbindungsabbruch den Platz kosten soll. Solche Betriebsentscheidungen verändern die Umsetzung und die dazugehörigen Tests.
Legt die unterstützte Umgebung fest
Notiert Minecraft-Version, Paper-Build, Java-Laufzeit sowie relevante Plugins mit Versionsnummern. Ergänzt gegebenenfalls Proxy und Crossplay-Konfiguration. Stellt eine repräsentative Testkonfiguration ohne Geheimnisse bereit. Haltet fest, ob der Auftrag einen Server oder gemeinsam genutzte Daten mehrerer Server umfasst.
Die Paper-Dokumentation zum Plugin-Deskriptor beschreibt Angaben zur API-Version und zu notwendigen Abhängigkeiten. Diese Angaben unterstützen die Ladeentscheidung. Sie belegen nicht, dass eure gesamte Plugin-Kombination funktioniert. Verlangt deshalb eine Liste der tatsächlich geprüften Kombinationen für die gelieferte Version.
Unser Beispiel wird für eine genau bezeichnete Paper-Umgebung abgenommen. Folia, eine andere Serversoftware oder künftige Minecraft-Versionen brauchen eine ausdrückliche Vereinbarung und eigene Prüfungen. Die Formulierung „mit Minecraft kompatibel“ ist dafür zu ungenau.
Formuliert beobachtbare Abnahmekriterien
Jeder Fall braucht einen Ausgangszustand, eine Aktion und ein erwartetes Ergebnis. Die folgende Tabelle enthält vorgeschlagene Anforderungen für das Anmeldebeispiel. Konkrete Befehle und Berechtigungsknoten werden bei der Umsetzung vereinbart.
| Ausgangszustand und Aktion | Erwartetes Ergebnis |
|---|---|
| Die Anmeldung ist offen; ein berechtigter Spieler meldet sich an. | Ein Eintrag wird gespeichert und der Spieler erhält eine Bestätigung. |
| Derselbe Spieler wiederholt die Anfrage. | Die bestehende Anmeldung wird gemeldet; kein weiterer Platz wird belegt. |
| Zwei Spieler fordern gleichzeitig den letzten Platz an. | Nur einer erhält ihn; der andere bekommt die vereinbarte Meldung zur vollen Veranstaltung. |
| Ein normaler Teilnehmer versucht, die Anmeldung zu schließen. | Die Aktion wird verweigert und die Anmeldung bleibt offen. |
| Das Team schließt die Anmeldung; ein weiterer Spieler versucht sich anzumelden. | Die Anfrage wird abgewiesen, ohne die Liste zu ändern. |
| Der Server wird regulär beendet und neu gestartet. | Bestätigte Anmeldungen und der Öffnungszustand entsprechen den vereinbarten Speicherregeln. |
Verwendet getrennte Testkonten für Teilnehmer, Moderator und Administrator. Prüft verbotene Aktionen ebenso sorgfältig wie erlaubte. Paper beschreibt Berechtigungsdeklarationen und Befehlsberechtigungen. Bei der Abnahme zählt das tatsächliche Verhalten mit eurer Berechtigungskonfiguration.
Dokumentiert pro Fall Plugin-Version, Vorbereitung, Schritte, Soll- und Ist-Ergebnis sowie einen passenden Logauszug oder Screenshot. Bis zur Durchführung bleibt der Status „nicht ausgeführt“. Eine ausgefüllte Vorlage allein ist noch kein Testnachweis.
Entscheidet über Fehlerfälle und Daten
Klärt, wann das Plugin eine erfolgreiche Anmeldung bestätigen darf. Für dieses Beispiel soll die Bestätigung erst nach dauerhafter Speicherung erfolgen. Ist der Speicher nicht erreichbar, könnt ihr als Verhalten festlegen, neue Anmeldungen mit einer verständlichen Meldung abzulehnen. Der Entwickler muss dieses Verhalten entwerfen und nachweisen.
Behandelt einen sauberen Neustart und einen abrupten Prozessabbruch als getrennte Tests. Legt fest, welche bestätigten Einträge jeweils erhalten bleiben müssen, wie der Abbruch in einer Testumgebung simuliert wird und welche Nachweise erforderlich sind. Ein bestandener Neustarttest belegt keine Wiederherstellung nach einem Absturz. Klärt außerdem, wer Daten exportieren oder löschen darf und wann alte Veranstaltungen entfernt werden.
Kommt eine Website oder externe API hinzu, braucht ihr ein führendes System für die Anmeldeliste. Beschreibt Wiederholungsversuche, doppelte Anfragen, Zeitüberschreitungen und einen Weg, unklare Ergebnisse durch das Team aufzulösen. Eine Abnahme auf einem einzelnen Server belegt keine konsistenten Daten im gesamten Netzwerk.
Langsame externe Aufrufe verlangen auch eine technische Entscheidung. Die Paper-Anleitung zur Aufgabenplanung erläutert Risiken aufwendiger Arbeit im Hauptthread und unsicherer Weltzugriffe aus asynchronen Aufgaben. Lasst euch diese Trennung erklären. „Alles läuft asynchron“ ist als Entwurf nicht ausreichend.
Macht die Leistungsprüfung wiederholbar
Ersetzt „darf nicht laggen“ durch ein konkretes Szenario: vereinbarte Anzahl verbundener Spieler, Anmeldeversuche in einem festgelegten Zeitraum, typische Weltaktivität, Hardware, Servereinstellungen und Testdauer. Messbare Grenzwerte legt ihr mit dem technischen Team vor der Abnahme fest. Dieser Artikel nennt weder eine allgemeingültige Spielerzahl noch einen universellen Grenzwert für Antwortzeiten.
Erfasst einen Ausgangswert und wiederholt das Szenario mit aktiver Funktion unter vergleichbaren Bedingungen. Haltet Laufzeiten, Fehler und das für Spieler sichtbare Ergebnis fest. Wenn ihr eine Verlangsamung untersucht, zeichnet das Profil während ihres Auftretens auf. Darauf weist die Paper-Anleitung zum Profiling hin. Eine Vorführung auf einem leeren Server bildet den Anmeldeschub zur Öffnung nicht ab.
Falls die Umgebung erst vorbereitet werden muss, lässt sich verwaltete Infrastruktur mit Bereitstellung, Monitoring und Lasttests vereinbaren. Bewahrt das gemessene Szenario zusammen mit der Version auf, damit spätere Änderungen sinnvoll vergleichbar bleiben.
Plant eine Übergabe, mit der euer Team arbeiten kann
Vereinbart eine versionierte JAR-Datei, Konfigurationsreferenz, Berechtigungsliste, Installations- und Updateanleitung, Speicherorte, bekannte Einschränkungen und das ausgefüllte Abnahmeprotokoll. Zugang zum Quellcode, Build-Anleitung und Anforderungen externer Abhängigkeiten sollten vor Beginn geklärt sein. Sie gehören ausdrücklich in den Lieferumfang.
Beschreibt auch den Rückweg zur vorherigen Version. Der Austausch der JAR-Datei reicht möglicherweise nicht aus, wenn ein Update gespeicherte Daten verändert. Verlangt das unterstützte Wiederherstellungsverfahren und prüft es gesondert. Bestimmt, wer die Bereitstellung übernimmt und wer über offene Fehler entscheidet.
Bei einem festen Veranstaltungstermin sollte die Plugin-Abnahme vor der vollständigen Event-Generalprobe liegen. Plant Zeit für Korrekturen ein. Wartung, Unterstützung künftiger Versionen und technische Live-Begleitung werden separat vereinbart.
Für eine Anfrage zur individuellen Minecraft-Entwicklung helfen Spielerablauf, Zielumgebung, Abnahmekriterien, Termin und Budget. Mineando übernimmt bezahlte Projekte mit individuell vereinbartem Umfang und Angebot. Mit diesen Unterlagen lässt sich der Auftrag konkret besprechen.
