Floodgate: Bedrock-Spieler ohne Mojang-Konto auf Java-Server zulassen (2026)

Ein Freund am Handy, der Neffe auf der Switch, der Onkel an der Xbox: jeder von ihnen prallt am normalen Java-Server ab, weil keiner eine Java-Lizenz besitzt. Ein zweites Konto kaufen, nur um zusammen zu spielen, macht niemand. Floodgate, das offizielle Begleit-Plugin zu Geyser, ist der legitime Weg, auf den sich Microsoft und das GeyserMC-Team geeinigt haben. Es baut eine stabile Identitaet aus dem vorhandenen Xbox-Live-Konto des Spielers und laesst ihn auf deinen Paper- oder Velocity-Server, ohne dass irgendeine Piraten-Loesung im Spiel waere.

Hier geht es darum, was Floodgate tatsaechlich tut, wie man es neben Geyser auf Paper 1.21+ einrichtet, was die Konfig-Schalter wirklich bedeuten, warum vor jedem Bedrock-Namen ein Punkt steht und wie der Linking-Befehl eine Bedrock-Sitzung in eine vollwertige Java-Konto-Sitzung verwandelt fuer Spieler, die beide Editionen besitzen.

Was Floodgate ist und was nicht

Geyser allein uebersetzt RakNet-Pakete von Bedrock in Java-Protokoll und zurueck. Das ist die einfache Haelfte. Die schwere Haelfte ist die Authentifizierung: ein vanilla Java-Server verlangt einen signierten Login vom Auth-Server von Mojang, und ein Bedrock-Client kann den nicht erzeugen. Bedrock weiss nur, wie man sich gegen Xbox Live authentifiziert.

Floodgate sitzt auf der Java-Seite dieser Unterhaltung und sagt dem Server "vertraue mir, dieser Xbox-Live-Login ist gueltig, hier ist der Spieler". Der Server behandelt das Ergebnis als normale Spielsitzung. Skin, UUID, Name, Rechte, alles verhaelt sich wie bei jeder anderen Verbindung, nur wird die UUID aus der Xbox User ID (XUID) gebaut statt aus einem Mojang-Eintrag.

Was Floodgate nicht ist:

• Kein Cracked-Plugin. Es laesst keine Spieler ohne Xbox-Live-Konto rein.
• Kein Ersatz fuer Geyser. Geyser uebernimmt weiterhin die Protokolluebersetzung. Floodgate kuemmert sich nur um den Auth-Bypass fuer Bedrock-Clients.
• Kein Piraterie-Werkzeug. Microsoft besitzt Mojang und Microsoft besitzt Xbox Live. Ein gueltiges Xbox-Live-Konto ist eine bezahlte Microsoft-Identitaet, dieselbe, mit der der Bedrock-Client das Spiel gekauft hat.

Die Kombination ist abgesegnet. GeyserMC veroeffentlicht beide Projekte auf derselben Seite, und die Repos liegen in derselben Organisation: github.com/GeyserMC/Geyser und github.com/GeyserMC/Floodgate.

Wie Microsoft die Lage veraendert hat

Vor ein paar Jahren waren Java-Konten und Microsoft-Konten getrennte Welten. Mojang hatte einen eigenen Auth-Server, Bedrock hatte den eigenen Xbox-Login. Die Migration auf Microsoft-Konten hat die Java-Logins in denselben Identity-Provider gezogen, aber die Protokolle sind nicht zusammengewachsen. Java laeuft weiterhin ueber den eigenen Login-Flow, Bedrock authentifiziert sich gegen Xbox Live, und ein Bedrock-Client kann immer noch keinen Java-Session-Token erzeugen, obwohl das Microsoft-Konto darunter dasselbe ist.

Floodgate existiert wegen genau dieser Luecke. Die offizielle Position von GeyserMC: das Plugin signiert eine Xbox-Live-Identitaet ueber ein server-lokales Schluesselpaar in die Java-Pipeline, und der Server stimmt explizit zu. Es wird keine Mojang-Lizenzpruefung uebersprungen, kein geschuetzter Identifier gefaelscht. Der Server vertraut einer Schluesseldatei, die du beim ersten Start selbst erzeugst, und Floodgate beglaubigt mit ihr den Bedrock-Spieler.

Damit ist die Linie sauber: wenn jeder Spieler aus dem Mojang-Auth kommen soll, betreibe vanilla Java mit online-mode true und ohne Geyser. Wenn auch Bedrock-Spieler rein sollen, installierst du Geyser plus Floodgate und akzeptierst, dass Bedrock-Identitaeten aus Xbox Live kommen, nicht aus Mojang.

Die richtige Geyser- und Floodgate-Variante waehlen

Geyser gibt es in mehreren Varianten. Floodgate auch. Sie muessen zueinander passen.

Server-Typ	Geyser-Jar	Floodgate-Jar
Einzelner Paper / Purpur Server	Geyser-Spigot	floodgate-spigot
Velocity-Netzwerk	Geyser-Velocity	floodgate-velocity (Proxy) + floodgate-spigot (jeder Backend)
BungeeCord-Netzwerk	Geyser-BungeeCord	floodgate-bungee + floodgate-spigot
Standalone (managed Minecraft-Hoster)	Geyser-Standalone	floodgate-standalone
Fabric / NeoForge	Geyser-Fabric / NeoForge	floodgate-fabric / floodgate-neoforge

Praxisregel fuer 2026:

• 1.21.x Paper-SMP: Geyser-Spigot 2.x plus floodgate-spigot 2.2.x.
• Netzwerk auf Velocity 3.3.x: Geyser-Velocity am Proxy, floodgate-velocity am Proxy, floodgate-spigot auf jedem Paper-Backend.
• Managed-Hoster, der dich keine Jars neben den Server legen laesst: Geyser-Standalone in einer eigenen VM und floodgate-standalone daneben, der Paper-Server mit online-mode false (siehe weiter unten).

Lade nur aus den offiziellen Quellen. Hangar (hangar.papermc.io/GeyserMC) und die Releases-Seite von GeyserMC auf GitHub, mehr gibt es nicht. Forum-Mirrors hinken oft Monate hinterher und du landest mit einem Build, der 1.21.4-Pakete nicht korrekt parst.

Installation auf einem einzelnen Paper 1.21

Der kuerzeste Weg. Paper 1.21 mit Java 21, einfacher Einzelserver, kein Proxy.

1. Server stoppen.
2. Geyser-Spigot.jar und floodgate-spigot.jar in plugins/ legen.
3. Server starten. Beide Plugins legen ihre Konfig-Ordner an: plugins/Geyser-Spigot/ und plugins/floodgate/.
4. Log lesen. Floodgate schreibt etwas wie Generated key file for Floodgate. Keep this safe!. Diese Datei ist plugins/floodgate/key.pem.
5. Server nochmal stoppen.
6. plugins/Geyser-Spigot/config.yml oeffnen und auth-type: floodgate im Block remote: setzen.
7. Optional Floodgate-Konfig anpassen (Defaults sind sauber).
8. Nochmal starten.

Eine reduzierte plugins/Geyser-Spigot/config.yml mit den Zeilen, die wirklich zaehlen:

bedrock:
  address: 0.0.0.0
  port: 19132
  clone-remote-port: false
  motd1: "SMP"
  motd2: "Java + Bedrock"
  server-name: "SMP"
  compression-level: 6
  enable-proxy-protocol: false

remote:
  address: auto
  port: auto
  auth-type: floodgate
  use-proxy-protocol: false

floodgate-key-file: key.pem
passthrough-motd: true
passthrough-player-counts: true
allow-third-party-capes: true
allow-third-party-ears: false
show-cooldown: title
show-coordinates: true
disable-bedrock-scaffolding: true
emote-offhand-workaround: disabled
default-locale: en_us

Die zwei Zeilen, an denen alles haengt, sind auth-type: floodgate und floodgate-key-file: key.pem. Ohne sie versucht Geyser, vom Bedrock-Client einen Java-Login zu verlangen, was nie funktioniert.

Eine reduzierte plugins/floodgate/config.yml:

key-file-name: key.pem
username-prefix: "."
replace-spaces: true
default-locale: system
disable-firstjoin-message: false
disable-leave-message: false
metrics:
  enabled: true
  uuid: 00000000-0000-0000-0000-000000000000
player-link:
  enabled: true
  require-link: false
  allow-linking: true
  type: sqlite

Die Defaults passen den meisten Servern. Was Operatoren als Erstes anpassen, ist username-prefix (siehe gleich) und der player-link-Block, falls Bedrock-Java-Verknuepfung gewuenscht ist.

Installation auf Velocity 3.3

Eine Netzwerksetup ist etwas aufwendiger. Der Grund: Velocity beendet die Bedrock-Verbindung ueber Geyser-Velocity, aber die echte Spielsitzung laeuft auf einem Paper-Backend. Floodgate muss auf beiden Seiten stehen, damit Proxy und Backend sich auf dieselbe Spieleridentitaet einigen.

Reihenfolge der Jars:

• Geyser-Velocity.jar und floodgate-velocity.jar in den plugins/-Ordner des Proxys.
• floodgate-spigot.jar in plugins/ jedes Paper-Backends.
• Geyser-Spigot kommt nicht auf die Backends. Geyser uebersetzt Pakete an einer Stelle, am Proxy.

Nach dem ersten Start erzeugt der Proxy plugins/floodgate/key.pem. Genau diese Datei wird auf jeden Backend nach plugins/floodgate/key.pem kopiert. Solange die Schluessel nicht uebereinstimmen, vertraut der Backend dem Proxy nicht.

Velocity braucht forwarding-mode: modern in velocity.toml und das passende velocity-secret, das in paper-global.yml jedes Backends im Block proxies.velocity eingetragen wird. Floodgate laeuft auf modern forwarding ohne extra Verkabelung, solange die Schluesseldatei beidseitig identisch ist.

In der config.yml von Geyser-Velocity setzen:

remote:
  auth-type: floodgate

address: auto und port: auto arbeiten genauso wie auf einem Einzelserver, der Proxy loest sie aber jetzt ueber die Velocity-Serverliste auf, nicht ueber server.properties.

Der Punkt vor jedem Bedrock-Namen

Oeffne die Spielerliste auf einem Floodgate-Server und du siehst Eintraege wie .SteveBE, .MobileMaster, .PixelKing. Der fuehrende Punkt ist keine Kosmetik, das ist eine Sicherheitsleiste.

Java-Namen haben eine enge Allow-Liste: alphanumerisch und Unterstrich, Laenge 3 bis 16. Bedrock erlaubt viel mehr, inklusive Leerzeichen, Punkten und einem groesseren Unicode-Bereich. Wenn ein Bedrock-Spieler dieselbe Zeichenkette waehlt, die ein Java-Spieler bereits besitzt, bekommst du eine Kollision bei UUID und Rechten. Der Punkt vor dem Namen umgeht das. Ein Punkt ist in einem Java-Namen verboten, also kann ein Java-Konto namens .SteveBE per Definition nicht existieren. Diesen Namensraum hat der Bedrock-Spieler.

replace-spaces: true in der Floodgate-Konfig erledigt den Rest: Leerzeichen im Bedrock-Anzeigenamen werden beim Beitritt durch Unterstriche ersetzt, damit Befehls- und Chat-Parser nicht stolpern.

Das Praefix laesst sich auf leer setzen (username-prefix: ""), aber dann hast du jede Kollision selbst am Hals. Ich habe Operatoren gesehen, die das auf kleinen privaten SMPs machen, wo jeder Spieler bekannt ist und der Namensraum kuratiert ist. Auf einem oeffentlichen Server bleibt der Punkt drin.

Die UUID unter dem Namen ist eine deterministische UUID v3, errechnet aus der Xbox User ID. Zwei wichtige Konsequenzen:

• Derselbe Bedrock-Spieler bekommt fuer immer dieselbe UUID, egal von welchem Bedrock-Geraet aus.
• Plugins, die Daten per UUID ablegen (LuckPerms, EssentialsX-Userdateien, BlueMap-Chunkbesitz), funktionieren ohne Sonderbehandlung. Fuer sie sieht ein Floodgate-Spieler aus wie jeder andere.

Skin-Handling

Skins ueber Floodgate teilen sich in zwei Faelle.

Bedrock-Spieler ohne verknuepftes Java-Konto. Geyser holt den Bedrock-Skin direkt aus dem Client (Bedrock-Skins werden im Login-Paket mitgeschickt) und stellt ihn ueber die FloodgateAPI bereit. Andere Spieler sehen den Bedrock-Skin als Java-Textur. Custom-Bedrock-Skins inklusive 4D- und Animations-Geometrie werden zu einem statischen Java-Skin abgeflacht, weil der Java-Client Bedrock-Geometrien nicht rendern kann. Capes werden teilweise unterstuetzt: Bedrock-Capes erscheinen pro Spieler als Java-Capes, wenn allow-third-party-capes: true in der Geyser-Konfig steht.

Bedrock-Spieler mit verknuepftem Java-Konto. Nach erfolgreichem /linkaccount kann Floodgate den verknuepften Java-Skin anderen Java-Spielern zeigen. Auf der Bedrock-Seite sieht der Spieler weiterhin den Bedrock-Skin, weil der Bedrock-Client Skins aus dem eigenen Pack rendert. Der Skin-Code liegt auf github.com/GeyserMC/Floodgate in den Modulen core und bukkit unter dem Paket skin, falls du im Quelltext nachlesen willst.

Wenn ein Plugin den Floodgate-Skin braucht, ist die FloodgateAPI der Einstieg:

import org.geysermc.floodgate.api.FloodgateApi;

if (FloodgateApi.getInstance().isFloodgatePlayer(uuid)) {
    var fp = FloodgateApi.getInstance().getPlayer(uuid);
    String xuid = fp.getXuid();
    String javaUsername = fp.getJavaUsername();
}

Plugins muessen isFloodgatePlayer pruefen, bevor sie Bedrock-Faehigkeiten annehmen. Ein Java-Spieler hat keine XUID.

Bedrock und Java verknuepfen

Ein Spieler, der beide Editionen besitzt, will meistens, dass sein Bedrock-Fortschritt mit dem bestehenden Java-Konto verschmilzt. Genau dafuer ist das Linking-System da.

Mit player-link.enabled: true und allow-linking: true erscheinen zwei Befehle:

• /linkaccount <code> auf der Java-Seite, ausgefuehrt vom Java-Konto.
• /linkaccount <java-username> <code> auf der Bedrock-Seite, ausgefuehrt vom Bedrock-Konto.

Der erste Befehl auf einer der Seiten erzeugt einen Code, der zweite auf der anderen Seite gibt ihn ein. Nach erfolgreicher Verknuepfung erzeugt Floodgate keine neue Bedrock-UUID mehr fuer diesen Spieler und leitet seine Sitzung auf die UUID des verknuepften Java-Kontos um. Plugins sehen jetzt eine Identitaet statt zwei.

require-link: true dreht die Politik um: nur Bedrock-Spieler, die schon verknuepft haben, kommen rein. Praktisch fuer geschlossene SMPs, in denen jedes Bedrock-Konto an eine reale Java-Identitaet gebunden sein soll. Fuer einen oeffentlichen Server ist es zu hart.

Das Backend ist standardmaessig SQLite (plugins/floodgate/linked.db). Fuer ein Netzwerk mit mehreren Proxys oder Backends sollte man auf MySQL umstellen, damit alle Knoten dieselbe Verknuepfungstabelle lesen. Das Schema liegt auf github.com/GeyserMC/Floodgate unter database/, und Floodgate erzeugt die Tabellen beim ersten Start.

Anti-Abuse: warum Floodgate keine Cracked-Hintertuer ist

Das Thema kommt in Admin-Chats immer wieder hoch, also klaeren wir es.

Eine Floodgate-UUID wird aus der XUID gebaut. Die XUID gibt Xbox Live an ein Microsoft-Konto aus, das Minecraft Bedrock Edition gekauft hat. Es gibt keinen oeffentlichen Weg, eine gueltige XUID zu faelschen, ohne durch Microsofts Auth-Flow zu gehen. Ein Bedrock-Client, der sich ueber Geyser verbinden will, praesentiert seine Login-Chain, die von Microsoft signiert ist. Geyser und Floodgate pruefen diese Kette, bevor die Spielsitzung erzeugt wird.

Vergleich mit echter Cracked-Authentifizierung (online-mode: false, kein Drittauth):

Eigenschaft	Bedrock-Spieler ueber Floodgate	Cracked-Java-Spieler (online-mode: false)
Quelle der Identitaet	Signierter Xbox-Live-Login	Was der Client behauptet
Konto faelschen	Microsoft-Konto mit gekauftem Bedrock noetig	Beliebigen Namen waehlen und verbinden
UUID-Stabilitaet	Deterministisch aus XUID, keine Kollisionen	Aus Namen abgeleitet, Kollisionen leicht
Microsoft genehmigt	Ja, offizieller Pfad GeyserMC + Microsoft	Nein, EULA-Verstoss auf oeffentlichen Servern
Wer kommt rein	Echte zahlende Bedrock-Kunden	Jeder mit einer Client-Jar
Risiko fuer deine Spieler	Wie bei einem Java-Konto	Hoch, Konto-Diebstahl und Identitaetsmissbrauch

Ein Bedrock-Spieler ueber Floodgate liegt naeher an einem Java-Spieler als an einem Cracked. Eine Floodgate-UUID grundsaetzlich verdaechtig zu finden ist falsch. Cracked-Java auf einem oeffentlichen Server fuer in Ordnung zu halten ist falsch.

Fuer Server, die Bedrock und Java wollen, ist die richtige Konfig online-mode: true auf dem Paper-Backend und auth-type: floodgate in Geyser. Die Java-Seite bleibt unter Mojang-Auth, die Bedrock-Seite unter Xbox Live, und Floodgate naeht beides zusammen.

Falls aus irgendeinem Grund online-mode: false noetig ist (manche Hoster hinter BungeeCord-Proxy verlangen das), stelle sicher, dass der Proxy selbst die Authentifizierung erzwingt, etwa ueber ViaProxy oder ein dediziertes Auth-Plugin. Lass die Tuer nie offen.

Installation pruefen mit /geyser dump

Geyser bringt einen Diagnose-Befehl mit, der die bereinigte Konfig und Spielerliste auf einen Pastebin laedt und eine URL zurueckgibt.

/geyser dump

Im Chat sieht man:

A copy of the dump has been uploaded to https://dump.geysermc.org/abc123

Wenn du im GeyserMC-Discord um Hilfe bittest, hang diese URL an. Die Maintainer sehen Version, Plugin-Liste, Floodgate-Status und Remote-Auth-Konfig, ohne dass du yaml kopierst.

Was du selbst im Dump pruefen solltest:

• auth-type muss floodgate sein.
• In der Plugin-Liste muessen Geyser und Floodgate auftauchen, mit den erwarteten Versionen.

Wenn auth-type auf online oder offline steht, kassieren Bedrock-Spieler einen "failed to verify username"-Fehler oder bekommen zufaellige UUIDs, die mit Java-Konten kollidieren. Auf floodgate umstellen und neu starten.

Typische Fehler

Floodgate could not find a player linker. Linking will not work. Falsche MySQL-Zugaenge oder SQLite-Pfad auf einem nur-lesenden Dateisystem. Pruefe player-link in der Floodgate-Konfig oder fall auf type: sqlite zurueck.

The given key file does not match. Backends im Netzwerk haben unterschiedliche key.pem. Schluessel des Proxys auf jeden Backend kopieren, alle neu starten.

Authentication is disabled, this is not safe. Geysers auth-type steht auf offline. Auf floodgate setzen.

Bedrock player kicked: Floodgate handshake failed. Trifft auf Velocity-Netzwerken auf, wenn forwarding-mode auf legacy oder bungeeguard steht. Velocity auf modern stellen und das velocity-secret in jeder paper-global.yml eintragen.

Bedrock-Spieler verbindet, aber Plugins erkennen seine UUID nicht. Der Bedrock-Spieler kam, bevor Floodgate fertig geladen war. Plugins, die PlayerJoinEvent mit niedriger Prioritaet anhaengen und die FloodgateAPI lesen, muessen Floodgate in ihrer plugin.yml als Abhaengigkeit eintragen, damit die Ladereihenfolge stimmt.

Spieler sehen keinen Bedrock-Skin auf der Java-Seite. allow-third-party-capes und das Skin-Laden brauchen Internet-Egress. Wenn der Hoster ausgehendes HTTPS zu textures.minecraft.net oder zum GeyserMC-Skin-Service blockt, fallen die Skins auf Steve zurueck. Egress fuer diese Domains oeffnen.

Username already taken / UUID conflict. Fast immer durch username-prefix: "" und einen Bedrock- plus Java-Spieler mit gleichem Namen verursacht. Punkt-Praefix wieder rein, betroffener Spieler verbindet neu.

Betriebshinweise fuer ein 2026-SMP

Ein paar Punkte, an denen Server in Produktion regelmaessig hangen.

Floodgate verlangsamt den Login nicht spuerbar. Die kryptografische Pruefung passiert auf der Geyser-Seite, nicht in Floodgate, und ist eine einzelne Ed25519-Pruefung pro Beitritt. Der Flaschenhals beim Beitritt ist fast immer das Welt-Laden oder der Resourcepack-Download, nicht der Auth.

Bedrock und Java sollten hinter demselben DDoS-Filter sitzen. RakNet ist UDP und ein beliebtes Ziel fuer Verstaerkungsangriffe wegen des kleinen unconnected-ping-Pakets. Wer 19132/udp ins offene Internet stellt, sieht Traffic. Filter wie MineGuard fangen das am Netzrand ab und lassen nur verifizierte RakNet-Sitzungen durch. Crossplay-Server ziehen im Schnitt mehr Bot-Traffic als reine Java-Server, weil der Bedrock-Eingang leichter zu fingerprinten ist, also lohnt sich DDoS-Schutz frueh.

Backups muessen plugins/floodgate/key.pem und plugins/floodgate/linked.db einschliessen. Schluessel weg, alle verknuepften Konten kaputt. Link-DB weg, jeder Spieler muss neu verknuepfen. Der ganze plugins/floodgate/-Ordner ist klein, unter einem Megabyte selbst auf einem vollen Server.

Beim Paper-Upgrade pruefst du, ob die aktuelle Geyser- und Floodgate-Version die neue Minecraft-Version unterstuetzen, bevor du die Server-Jar wechselst. Die Plugins hinken dem Protokoll bei Minor-Versionen einen oder zwei Tage hinterher und bei Major-Versionen eine Woche. Die GeyserMC-Releases-Seite auf GitHub im Blick behalten.

FAQ

F: Muessen meine Bedrock-Spieler Minecraft Java kaufen, um zu spielen? Nein. Genau das ist der Sinn von Floodgate. Ihre Xbox-Live-Identitaet, dieselbe, mit der sie Bedrock gekauft haben, reicht. Die Java-Lizenz bleibt optional.

F: Kann ein Spieler ohne Microsoft-Konto ueber Floodgate beitreten? Nein. Floodgate verlangt eine signierte Xbox-Live-Login-Chain. Fuer einen offline oder unauthentifizierten Bedrock-Client gibt es keinen Weg.

F: Sollte ich online-mode false auf dem Paper-Backend laufen lassen? Nur, wenn du ein Proxy-Netzwerk mit ordentlichem Auth-Handling am Proxy hast. Fuer einen Einzel-SMP ist online-mode true plus Floodgate richtig: Java-Spieler ueber Mojang, Bedrock ueber Floodgate.

F: Mein Anti-Cheat sieht Bedrock-Spieler komisch laufen, was nun? Bedrock-Physik unterscheidet sich von Java in Details, und Geyser uebersetzt nach besten Kraeften. Die meisten Anti-Cheats haben heute einen "Floodgate-aware"-Modus, der Pruefungen fuer Floodgate-UUIDs lockert. Vulcan, Matrix und Grim koennen das. Diesen Modus einschalten statt globale Pruefungen abzuschalten.

F: Ist der Linking-Befehl sicher? Kann jemand mein Java-Konto stehlen? Linking ist ein zweiseitiges Handshake. Der auf einer Seite erzeugte Code muss auf der anderen Seite aus derselben Spielersitzung eingegeben werden. Ein Java-Konto laesst sich von aussen nicht verknuepfen. Codes laufen schnell ab.

F: Wo gibt es Hilfe, wenn Floodgate Aerger macht? GeyserMC-Discord und der Issue-Tracker auf github.com/GeyserMC/Floodgate. Immer den /geyser dump-Output anhaengen. Maintainer schauen den Kanal taeglich durch.

Ein Crossplay-Server mit Floodgate ist ein kleiner Aufwand mehr in der Plugin-Komplexitaet und ein grosser Schub fuer die Spielerbasis. Das Plugin ist reif, das Unternehmen hinter Minecraft hat den Weg abgesegnet, und die einzige Sorge fuer Operatoren ist, key.pem sauber zu sichern und Geyser aktuell zu halten. Aufsetzen, Adresse an die Handy-Freunde geben, und die Spielerliste fuellt sich mit Namen, die mit einem Punkt anfangen.