Crossplay SMP: ein Server fuer Java und Bedrock mit Geyser und Floodgate

Wenn die PC-Freunde und der Cousin am Handy auf derselben Welt spielen sollen, lohnt es sich nicht, sie auf zwei Server zu trennen. Geyser plus Floodgate macht aus einem normalen Paper einen plattformuebergreifenden SMP, auf dem Java- und Bedrock-Spieler in derselben Welt laufen. In diesem Guide gehen wir die Installation durch, zeigen wie Floodgate Bedrock ohne Java-Account authentifiziert, und besprechen die Stolperfallen bei Praefixen, Resource Packs und Anti-Cheat.

Warum Java und Bedrock ueberhaupt verbinden

Beide Clients sind durch Protokoll und Plattform getrennt. Java Edition spricht TCP und verlangt einen Mojang-Login. Bedrock Edition (Mobile, Switch, Xbox, PlayStation, Windows 10) nutzt RakNet ueber UDP und ist an Xbox Live gebunden. Auf einem reinen Vanilla-Server sehen sie sich nie.

Geyser laeuft als Plugin oder Proxy und uebersetzt RakNet-Pakete vom Bedrock-Client in Java-Pakete, die Paper versteht. Floodgate loest das zweite Problem: Es laesst Bedrock-Spieler ohne Java-Account auf den Server, indem es eine deterministische UUID und einen Username aus der Xbox Live ID erzeugt.

Das Ergebnis ist ein Paper-Server fuer beide Zielgruppen, gemeinsame Welt, gemeinsamer Chat, gemeinsamer Fortschritt. Der billigste Weg, einen SMP fuer 30-50 plattformgemischte Spieler aufzusetzen.

Geyser-Spigot oder Geyser-Standalone

Geyser kommt in mehreren Varianten, die richtige musst du sofort waehlen:

• Geyser-Spigot - jar in plugins/ von Paper oder Purpur. Laeuft im selben Prozess wie der Server. Empfohlen fuer einen einzelnen SMP.
• Geyser-Standalone - eigener Prozess, lauscht auf einem Port und leitet weiter an den Java-Server. Sinnvoll auf Managed Hosts, wo du den Server nicht selbst kontrollierst.
• Geyser-Velocity / Geyser-BungeeCord - fuer Proxy-Netzwerke. Das Plugin liegt dann auf dem Proxy.
• Geyser-Fabric / Geyser-NeoForge - fuer Modded Server.

Fuer einen klassischen Paper-SMP nimmst du Geyser-Spigot.jar und floodgate-spigot.jar von GeyserMC GitHub Releases und Floodgate Releases. Beide jars muessen zur gleichen Minecraft-Version passen.

Installation auf Paper oder Purpur

Stabil unterstuetzte Minecraft-Versionen aktuell: 1.20.x und 1.21.x. Auf 1.19 oder darunter laeuft Geyser zwar, bekommt aber keine Updates mehr.

Die Schritte sind kurz:

1. Server stoppen.
2. Geyser-Spigot.jar und floodgate-spigot.jar in plugins/ legen.
3. Server starten. Die Plugins erzeugen plugins/Geyser-Spigot/config.yml und plugins/floodgate/config.yml.
4. Stoppen, Configs anpassen, neu starten.

Eine minimale plugins/Geyser-Spigot/config.yml:

bedrock:
  address: 0.0.0.0
  port: 19132
  clone-remote-port: false
  motd1: "Crossplay SMP"
  motd2: "Java + Bedrock"
  server-name: "Crossplay SMP"

remote:
  address: auto
  port: auto
  auth-type: floodgate

passthrough-motd: true
passthrough-player-counts: true
allow-third-party-capes: true
allow-third-party-ears: false
show-cooldown: title
show-coordinates: true

auth-type: floodgate weist Geyser an, die Bedrock-Authentifizierung an Floodgate zu uebergeben. Ohne diese Zeile wuerde Geyser einen Java-Account verlangen, was auf Konsolen und Handys nicht klappt.

Eine minimale plugins/floodgate/config.yml:

key-file-name: key.pem
username-prefix: "."
replace-spaces: true
disable-firstjoin-message: false
disable-leave-message: false
default-locale: system

Die Datei key.pem erzeugt Floodgate beim ersten Start. Wenn du Geyser-Standalone separat betreibst, muss dieselbe Datei dorthin kopiert werden.

Ports und Firewall

Bedrock laeuft ueber UDP, nicht TCP. Das verwirrt viele, weil man fuer Java gewohnt ist, nur 25565/tcp zu oeffnen.

Du musst oeffnen:

• 25565/tcp fuer Java-Clients (Standard-Server-Port)
• 19132/udp fuer Bedrock-Clients (Standard-Geyser-Port)

In iptables sieht das so aus:

iptables -A INPUT -p tcp --dport 25565 -j ACCEPT
iptables -A INPUT -p udp --dport 19132 -j ACCEPT

Wenn du hinter einem DDoS-Schutz sitzt, muss der Provider explizit wissen, dass 19132/udp ebenfalls als Game-Port geproxyt werden soll. UDP-Angriffe haben ihre eigene Variante: RakNet liebt geflutete unconnected-ping-Pakete, und ohne richtigen UDP-Filter geht der Server schnell in die Knie. Loesungen wie MineGuard fangen das auf Filter-Ebene ab.

Floodgate-Praefix und warum Namen mit Punkt beginnen

Standardmaessig setzt Floodgate . vor jeden Bedrock-Username. Heisst der Spieler auf Xbox Live SteveBE, erscheint er auf dem Server als .SteveBE.

Der Grund: Java und Bedrock haben unterschiedliche Regeln fuer Namen. Java verbietet Sonderzeichen und Leerzeichen, Bedrock erlaubt vieles inklusive Leerzeichen und Emojis. Wenn ein Java-Spieler SteveBE ist und spaeter ein Bedrock-Account mit gleichem Namen kommt, gibt es Konflikt. Der Punkt-Praefix loest das: ein Punkt ist in Java-Namen unzulaessig, also kann es einen Java-Account .SteveBE per Definition nicht geben.

replace-spaces: true ersetzt zusaetzlich Leerzeichen in Bedrock-Namen durch _, sonst brechen Plugins, die Befehlsargumente parsen.

Der Praefix laesst sich auf leer setzen, dann musst du jede Kollision selbst loesen. Ich lasse den Punkt drin: Gaeste sehen .Username und verstehen sofort, dass dieser Spieler vom Handy oder von der Konsole kommt.

UUIDs der Bedrock-Spieler

Floodgate vergibt keine zufaelligen UUIDs. Es nimmt die Xbox Live ID und berechnet ueber UUID v3 (Name in Namespace) eine deterministische UUID, die fuer einen Account immer identisch bleibt. Das ist wichtig, weil Inventar und Fortschritt in Minecraft an UUIDs gebunden sind.

Praktisch heisst das: Wenn du Spieler zwischen Servern mit demselben Floodgate migrierst, passen Inventar und LuckPerms-Rechte zusammen. Wechselst du Floodgate-Logik oder migrierst von einer anderen Loesung wie GeyserConnect, koennen UUIDs abweichen und Bedrock-Spieler verlieren ihren Fortschritt.

In den meisten Faellen ist das einmaliger Migrationsschmerz. Innerhalb eines Servers bleibt die UUID stabil.

Resource Packs und Texturen

Geyser konvertiert Java-Resource-Packs on-the-fly ins Bedrock-Format, aber nicht jedes Pack ueberlebt die Konvertierung. Was gut funktioniert:

• Block- und Item-Texturen ersetzen
• Sounds ersetzen
• Custom Models via CustomModelData (mit Einschraenkung, siehe unten)

Was schlecht oder gar nicht laeuft:

• OptiFine CIT (Connected Item Textures) - teilweise via Geyser, nicht alles
• OptiFine CEM (Custom Entity Models) - auf Bedrock nicht unterstuetzt
• Shader - haben mit Resource Packs ohnehin nichts zu tun, Bedrock nutzt RenderDragon

Zu CustomModelData: Plugins wie ItemsAdder, MMOItems oder Oraxen verwenden CMD fuer eigene Items. Auf Bedrock klappt das nur, wenn ein eigenes Bedrock-Pack gebaut wurde. ItemsAdder bringt out-of-the-box einen Bedrock-Pack-Generator mit; Oraxen hat eine Geyser-Bridge ueber Plugin-Mappings; MMOItems ist schwieriger und braucht meist ein handgestricktes Bedrock-Pack.

In Geyser-Spigot/config.yml einschalten:

load-resource-packs: true

Danach werden alle Packs aus plugins/Geyser-Spigot/packs/ an den Bedrock-Client geschoben.

UI und Interfaces: was auf Bedrock klemmt

Bedrock rendert die meisten Java-Interfaces ueber das eigene UI, und nicht alles laeuft sauber.

• Schilder editieren - Bedrock oeffnet eigene Tastatur, funktioniert. Color Codes via & koennen verloren gehen.
• Amboss - Umbenennen funktioniert mit Laengenlimit. Lange Namen werden abgeschnitten.
• Buecher - Editieren funktioniert, aber ohne Formatierung.
• Befehlsbloecke - oeffnen sich als reine Textfelder, funktionieren.
• Custom GUIs ueber Inventar (Plugin-Menues via Chest GUI) - klappen fast immer, aber Bedrock-Spieler sehen keine Tick-Animationen und verklicken sich manchmal in der ersten Sekunde.
• Geyser Form-Menues - Geyser bietet eine API, um native Bedrock-Forms vom Plugin aus zu oeffnen. Fuer Bedrock-spezifische Admin-Panels die bessere Wahl als Chest GUI.

Vor dem Launch unbedingt die Hauptszenarien auf einem Bedrock-Geraet durchgehen. Einmal lokal Fehler finden ist besser, als spaeter mit echten Spielern zu reagieren.

Was auf Bedrock anders laeuft

Der ewige Crossplay-Schmerz. Ein paar Punkte:

• Redstone-Automatisierung. Basisschaltungen verhalten sich gleich, aber feine Timings (BUDs, Instant-Repeater) ticken auf Bedrock anders. Wir sind hier auf einem Java-Server, also gilt Java-Logik. Der Bedrock-Spieler sieht nur das Ergebnis.
• Elytra-Flug. Funktioniert, aber Pitch-Empfindlichkeit weicht auf Konsolen mit Controller ab.
• F3-Menue, Pie Chart, Lag-Graphen. Auf Bedrock nicht vorhanden. Performance-Diagnose nur Java-seitig.
• Befehle. Bedrock zeichnet eigenes UI fuer Commands, aber Plugin-Befehle ohne Brigadier-Argument-Provider erscheinen als reiner Text. Ueber die Geyser Form API einpacken.

Anti-Cheat und Bedrock

Heikles Thema. Anti-Cheats wie GrimAC und Vulcan sind gegen die Java-Engine geschrieben und pruefen Physik mit Java-Formeln. Bedrock-Physik ist leicht anders, ohne Exemptions kassieren Bedrock-Spieler in der ersten Minute False Positives auf MovementY oder KnockbackUtil.

GrimAC ab 2.3.x unterstuetzt Floodgate offiziell und exempt-iert Bedrock-Spieler beim Connect. Vulcan kann das auch, aber die Config muss man anfassen. Minimales Vulcan-Beispiel:

checks:
  movement:
    enabled: true
    exempt-floodgate: true
  combat:
    reach:
      exempt-floodgate: true

Anti-Cheat fuer Bedrock komplett auszuschalten ist keine Option: Es gibt Drittanbieter-Clients wie Horion oder ToolBox. Aber Movement-Checks muss man entspannen.

Chat-Praefixe und LuckPerms

Damit Java und Bedrock im Chat unterscheidbar sind, haengt man ein Tag an. Mit LuckPerms eine Folge von Befehlen:

lp creategroup bedrock
lp group bedrock meta setprefix 10 "&e[B] "
lp creategroup java
lp group java meta setprefix 10 "&a[J] "
lp group default parent add java

Floodgate weist Bedrock-Spieler automatisch der Gruppe bedrock zu, wenn in plugins/floodgate/config.yml default-group: bedrock gesetzt ist (Option lebt in Addons, Version pruefen). Alternativ das Plugin FloodgateExtras oder ein kleiner EssentialsX-Hook:

# via EssentialsX-Discord oder onJoin-Skript
on player_join:
  if player has permission "floodgate.player":
    add player to lp group "bedrock"

Danach erscheinen Bedrock-Spieler im Chat als [B] .Steve und Java als [J] Alex. Hilfreich fuer Moderation.

Performance

Geyser selbst frisst wenig, etwa 10-30 MB RAM und einen Hauch CPU fuer Protokoll-Uebersetzung. Floodgate ist noch leichter, sein Job ist nur Handshake-Pruefung und UUID-Erzeugung.

Die echte Last bleibt bei Paper und der Welt. Bedrock-Spieler schicken Chunk-Requests genauso wie Java, der Server verarbeitet jeden Chunk einmal. Wenn 8 GB RAM fuer 30 Java-Spieler gereicht haben, reichen sie fuer dieselben 30 inklusive Bedrock-Anteil, mehr nicht. Geyser ist keine Magie und reduziert keine reale Last.

Was sich lohnt:

• view-distance: 8 in server.properties. Bedrock auf Handys zeichnet ohnehin nicht mehr fluessig.
• network-compression-threshold: 256 fuer Java-Clients, auf Bedrock hat dieser Wert keine Wirkung.
• Welt vorab mit Chunky generieren. Bedrock-Clients im Mobilfunk reagieren empfindlich auf Generation-Lag.

FAQ

Geyser vs Floodgate, was ist der Unterschied?

Geyser uebersetzt Protokoll: Bedrock-Pakete werden in Java-Pakete umgewandelt, die der Server lesen kann. Floodgate kuemmert sich um Authentifizierung: Bedrock-Spieler brauchen keinen Java-Account, Floodgate prueft den Xbox Live Token und laesst sie rein. Beide werden zusammen eingesetzt. Ohne Floodgate koennte ein Bedrock-Client zwar Geyser erreichen, aber der Server wuerde ihn ohne Java-Login abweisen.

Geht Crossplay auf einem Vanilla-Server?

Auf nacktem vanilla.jar nicht, dort laesst sich weder Geyser noch Floodgate installieren. Mindestvoraussetzung ist Paper, Purpur oder Spigot, denn Vanilla hat kein Plugin-System. Wer "vanilla" im Spielgefuehl bleiben will, installiert Paper und einfach keine weiteren Plugins ausser Geyser und Floodgate. Mechanisch ist Paper sehr nah an Vanilla.

Wie registriert man einen Bedrock-Spieler ohne Java-Account?

Manuell muss man gar nichts tun. Floodgate akzeptiert den Xbox Live Token vom Geraet des Spielers und erzeugt selbst eine UUID aus xboxId. Beim ersten Connect landet der Spieler einfach auf dem Server, mit eigener UUID und Namen samt .-Praefix. Falls du AuthMe oder ein anderes Login-Plugin laufen hast, deaktivierst du es fuer Floodgate-Spieler ueber auto-login: true oder per Permission-Exempt fuer floodgate.player.

Sehen Bedrock-Spieler Java-Skins?

Haengt vom Pack ab. Java-Skins sind 64x64 PNG, Bedrock nutzt ein eigenes Skin-Format. Geyser konvertiert Java-Skins on-the-fly in Bedrock-Skins, und Bedrock-Clients sehen ungefaehr dasselbe. Die Option allow-third-party-capes: true in der Geyser-Config aktiviert Capes. Eine Einschraenkung: 4D-Modelle und animierte Bedrock-Skins werden Java nicht angezeigt. Java sieht nur die Body-Textur, ohne Partikel oder Animationen.

Kann Bedrock auf demselben 25565 verbinden?

Nein. Bedrock laeuft ueber UDP und RakNet, Java ueber TCP. Andere Transports, ein Socket reicht nicht fuer beide. Geyser haelt einen separaten UDP-Port (Standard 19132). Du kannst bedrock.port auf einen beliebigen UDP-Port aendern, dann muessen Bedrock-Clients den Port aber manuell eintippen. In Featured Servers ist UDP/19132 Standard.

Was tun, wenn Plugins auf Bedrock kaputt sind?

Zuerst pruefen, ob das Plugin eine Bedrock-kompatible Version oder Geyser-Bridge hat. Fuer populaere (ItemsAdder, Citizens, ProtocolLib) gibt es das. Fuer seltene Plugins ist es einfacher, das UI ueber die Geyser Form API einzupacken: Bedrock-Spieler sehen ein natives Form, Java behaelt das alte Chest GUI. Einmalige Arbeit auf Server-Seite.

Wie geht es weiter

Geyser plus Floodgate ist auf jedem Paper-SMP in einer halben Stunde installiert. Vergiss nur nicht den UDP-Port in der Firewall, das Anti-Cheat-Exempt und einen Test der wichtigen GUIs vom Bedrock-Geraet aus.

Drei naechste Schritte: LuckPerms-Gruppen-Praefixe einrichten, damit die Moderation die Plattform sieht; ein gemeinsames Resource Pack bauen und auf einem Handy testen, damit CMD-Items auf beiden Seiten funktionieren; mindestens grundlegenden DDoS-Schutz vor den UDP-Port stellen, denn ein Bedrock-Server auf einer rohen IP zieht RakNet-Floods magnetisch an.