Plugin-Menüs mit Geyser: Java und Bedrock richtig prüfen
Bevor ihr ein individuelles Minecraft-Plugin für eine Community mit Java und Bedrock abnehmt, prüft den vollständigen Ablauf: Beide Editionen müssen dieselben vorgesehenen Aktionen ausführen, sicher abbrechen und ein korrektes Ergebnis erhalten können. Eine Verbindung über Geyser und ein sichtbares Inventarmenü reichen dafür nicht. Vereinbart zuerst die unterstützten Geräte und Eingabemethoden und testet anschließend mit normalen Spielerrechten.
Bei einer Teamauswahl, einem Lobby-Menü oder einer Event-Anmeldung gehört eine bedienbare Oberfläche für jeden vereinbarten Client zur Lieferung. Die Oberflächen müssen nicht identisch aussehen. Das folgende Beispiel ist ein vorgeschlagener Abnahmetest; Mineando hat diese Minecraft-Tests nicht durchgeführt.
Gesten mit mehreren Bedeutungen erkennen
Lasst alle Aktionen auflisten, die von einer bestimmten Klickart, Tastenkombination oder Chat-Interaktion abhängen. Zu den aktuellen Einschränkungen von Geyser gehören die Unterscheidung von Links- und Rechtsklicks in Inventaren, anklickbare Chat-Links sowie das Erkennen laufender Texteingabe oder Tab-Vervollständigung im Chat. Berücksichtigt diese Grenzen bereits beim Entwurf.
Die Vorgabe „Linksklick auf das Banner zeigt das Team, Rechtsklick tritt bei“ braucht deshalb für Bedrock einen anderen Bedienweg. Das Etikett „Geyser-kompatibel“ erklärt noch nicht, wie beide Aktionen erreichbar sind. Verlangt eine Vorführung vom Öffnen des Menüs bis zur Kontrolle der tatsächlichen Teamzugehörigkeit.
Beschreibt die Aktionen aus Spielersicht: ansehen, auswählen, bestätigen, zurückgehen und abbrechen. Dadurch trennt ihr den Zweck eines Schrittes von der bisherigen Eingabe. Der allgemeine Leitfaden zur Plugin-Abnahme behandelt den gesamten Lieferumfang; hier geht es gezielt um die Bedienung zwischen den Editionen.
Einen konkreten Bedienweg vereinbaren
Vor der Umsetzung bieten sich drei Ansätze zur Besprechung an:
| Ansatz | Was ihr beauftragt | Was geprüft werden muss |
|---|---|---|
| Gemeinsames Inventarmenü | Getrennte Einträge für verschiedene Aktionen | Erreichbarkeit und Verständlichkeit mit jeder vereinbarten Eingabe |
| Java-Menü und Bedrock-Formulare | Zwei Oberflächen mit denselben fachlichen Regeln | Gleichwertige Prüfung, Abbruchmöglichkeiten und Ergebnisse |
| Bedienung über Befehle | Kurzer, auffindbarer Ersatzweg für wesentliche Aktionen | Praktische Nutzung am Zielgerät und reguläre Rechteprüfung |
Bedrock-Formulare sind eine Entwicklungsoption, keine automatische Umwandlung vorhandener Java-Menüs. Geyser dokumentiert den Zugriff auf Cumulus über Geyser oder Floodgate sowie SimpleForm, ModalForm und CustomForm. Die Formulardokumentation unterscheidet gültige Antworten, geschlossene Formulare und ungültige Antworten. Das Entwicklungsteam muss das jeweilige Verhalten der Anwendung festlegen.
Lasst zunächst den kritischsten Ablauf als kleinen Prototyp umsetzen. Ist die Teamauswahl mit Controller umständlich, lösen zehn zusätzliche Menüs dieses Problem nicht. Ein Ersatzbefehl hilft nur, wenn Teilnehmende ihn auf ihrem Gerät finden und tatsächlich eingeben können.
Den unterstützten Umfang festhalten
Dokumentiert den Build des Java-Servers, die Plugin-Version, den Geyser-Build und gegebenenfalls den Floodgate-Build. Ergänzt eingesetzte Proxys und Komponenten zur Protokollübersetzung. Prüft bei der Vorbereitung die unterstützten Versionen und speichert die tatsächlich verwendeten Stände beim Testergebnis. Eine ältere Vorführung belegt keine Kompatibilität nach einem Komponentenwechsel.
Legt jede vereinbarte Kombination aus Client und Eingabe fest: beispielsweise Java mit Maus und Tastatur, Bedrock mit Touchscreen und Bedrock mit Controller. Diese Beispielmatrix verpflichtet nicht zur Unterstützung sämtlicher Geräte. Nutzt die vorgesehenen Zielgeräte, wenn Plattformunterschiede relevant sind. Ein Controller am Computer beweist nicht, dass Konsolenspieler den gesamten Verbindungsweg durchlaufen können.
Testet über den öffentlichen Zugang, mit einem Teilnehmerkonto und in den vorgesehenen Event-Sprachen. Haltet bei Lesbarkeitsproblemen auch die Oberflächenskalierung fest. Administratorrechte und dem Entwickler vertraute Abkürzungen können verdecken, dass normale Spieler einen wichtigen Schritt nicht erreichen.
Beispiel: Team auswählen, ohne versehentlich beizutreten
Angenommen, ein Event hat zwei Teams. Teilnehmende können eine Beschreibung lesen, einen Platz anfragen, bestätigen oder abbrechen. Während ein Menü offen ist, kann das Team voll werden. Folgende Regeln sind ein Vorschlag für die Abstimmung mit dem Entwicklungsteam:
- Das Öffnen einer Beschreibung verändert keine Mitgliedschaft. Auch beim Schließen dieser Ansicht bleibt alles unverändert.
- „Beitreten“ öffnet eine Bestätigung mit dem gewählten Team. Der vorherige Bildschirm darf die Anmeldung nicht unbemerkt abschließen.
- Beim Bestätigen prüft der Server die aktuelle Kapazität und die Teilnahmeberechtigung. Zuvor angezeigte Informationen können inzwischen veraltet sein.
- Die Erfolgsmeldung erscheint erst nach erfolgreicher Anmeldung. Ein inzwischen belegter Platz führt zu einer verständlichen Absage mit Rückweg.
- Wiederholte Eingaben erzeugen weder eine zweite Mitgliedschaft noch eine zusätzliche Belohnung für den Beitritt.
Der Java-Prototyp könnte getrennte Einträge für „Details“ und „Beitreten“ verwenden. Für Bedrock wären Schaltflächen mit anschließendem Bestätigungsformular denkbar. Das sind Entwurfsvorschläge, keine Zusage, dass ein bestimmtes Menü-Plugin diese Funktionen bereits besitzt.
Haltet für jeden Fall die Mitgliedschaft vorher und nachher fest. Sieht ein Spieler eine Erfolgsmeldung, während das Team ihn weiterhin nicht enthält, ist der Test fehlgeschlagen – unabhängig von der korrekten Animation. Sind Kontoverknüpfungen vorgesehen, ergänzt die separat vereinbarten Floodgate-Identitätsprüfungen. Die Oberfläche allein legt nicht fest, welchem Profil das Ergebnis zugeordnet wird.
Unterbrechungen gezielt durchspielen
Wiederholt den Ablauf mit jeder unterstützten Kombination. Schließt das Menü vor der Bestätigung, geht zurück, verbindet euch mit ausstehender Bestätigung neu und bestätigt nach dem Ende der Anmeldung. Lasst außerdem eine zweite Person den letzten Platz belegen, während das erste Menü geöffnet bleibt. Führt diese Übungen in einer kontrollierten Testumgebung durch.
Vereinbart das erwartete Ergebnis jeder Unterbrechung vorher. In diesem Beispiel muss ein erneut geöffnetes Menü die aktuelle Mitgliedschaft zeigen. Eine alte Bestätigung darf weder eine geschlossene Anmeldung noch ein volles Team umgehen. Ein abgebrochener Bildschirm sollte nicht endlos wieder erscheinen: Der Ablauf braucht einen klaren Ausgang.
Sichert bei Fehlern eine kurze Bildschirmaufnahme, die Versionsstände, die Eingabefolge und den daraus entstandenen Serverzustand. Ein einzelnes Bildschirmfoto zeigt nicht, ob eine Eingabe ausgewählt, bestätigt oder abgebrochen hat. Entfernt private Kontodaten und Zugangsdaten aus Belegen, die ihr außerhalb des Teams teilt.
Die Abnahme eindeutig entscheiden
Gebt die Funktion frei, wenn alle wesentlichen Aktionen erreichbar sind, Abbrechen sicher funktioniert, Serverzustand und Meldung übereinstimmen und für die vereinbarte Gerätematrix Belege vorliegen. Haltet rein optische Unterschiede getrennt fest. Kann eine zugesagte Eingabemethode eine wesentliche Aktion nicht ausführen, muss das Design geändert oder die unterstützte Zielgruppe vor dem Start ausdrücklich eingeschränkt werden.
Für ein Projekt zur individuellen Minecraft-Entwicklung helfen die Aktionsliste, die Gerätematrix und ein ausgearbeiteter Ablauf bei der Planung. Mineando kalkuliert kostenpflichtige Projekte einzeln. Wartung, spätere Kompatibilitätsanpassungen und die technische Begleitung des Events werden gesondert vereinbart.
