Am Telefon zählte jeder Fingertipp doppelt

19. August 2026 · spiel · werkzeuge

Till, am Telefon: „wenn ich eine 11 würfele (5+6), lassen sich die Klappen nicht umlegen — nichts passiert; bei Würfen wie 5 (3+2) lässt sich die 5 umklappen.“

Das klingt nach einem Regelfehler. Elf ist eine Summe aus zwei Klappen, fünf ist eine einzelne — wenn Kombinationen nicht gehen und Einzelklappen schon, dann stimmt etwas mit der Prüfung nicht, die Kombinationen erlaubt.

Die falsche Fährte

Also zuerst in den Regelkern geschaut. Dort war nichts:

auswahl_gueltig sagt bei 5+6 = 11 ja.
_auto_zuklappen prüft seit dem Vortag sogar ausdrücklich den Fall 1+10 = 11.
Alle Prüfläufe waren grün.

Sie waren grün, weil sie waehle_klappe() direkt aufrufen — also unterhalb der Eingabe. Und am Rechner war nie etwas kaputt. Der Fehler existierte nur dort, wo kein Test hinsah: in der Eingabekette eines Touchgeräts.

Die Ursache

In project.godot steht input_devices/pointing/emulate_mouse_from_touch auf true. Godot schickt für jeden Fingertipp zusätzlich ein Maus-Ereignis. Spielbrett._auf_vp_input behandelte beide Arten. Also lief _tippe() zweimal je Tipp — und _toggle_klappe ist ein Umschalter.

Zwei Ereignisse je Tipp, ein Umschalter dazwischen. Die beiden heben sich auf, und übrig bleibt genau nichts — kein Fehlerbild, keine Meldung, keine Spur im Log.

Warum es so lange durchkam

Am Telefon fiel es nur bei Kombinationen auf, und das hat den Fehler verkleidet:

Eine einzelne passende Klappe klappt schon im ersten Durchlauf zu — das ist die Ein-Tipp-Regel. Die Phase springt auf WAIT_ROLL, und der zweite Durchlauf läuft ins Leere. Wer eine 5 würfelte, kam also durch. Wer eine 11 würfelte, brauchte 5+6 — und kam nie durch.

Genau diese Asymmetrie liest sich wie eine Regel. „Kombinationen gehen nicht“ ist eine plausible Aussage über ein Spiel; „jeder zweite Tipp wird zurückgenommen“ ist keine, auf die man von aussen kommt.

Belegt war der Fehler erst, als ein echtes InputEventScreenTouch durch die Eingabekette lief und nachgemessen wurde, was ankommt:

Maus(device=-1)   ← das Emulat, wählt Klappe 5 aus
Finger(device=0)  ← der echte Tipp, wählt sie sofort wieder ab

Behoben

In scripts/spielbrett.gd wird das Emulat ausgesondert: mb.device == InputEvent.DEVICE_ID_EMULATION.

Verworfen: „nur noch Maus behandeln“. Das wäre kürzer gewesen und hätte still an der Projekteinstellung gehangen — wer emulate_mouse_from_touch abschaltet, hätte ein Spiel ohne jede Bedienung gehabt. Ein Fix, der von einer Einstellung abhängt, die mit ihm nichts zu tun hat, ist eine Falle für den Nächsten.

Der Riegel

tools/pruefe_ui.gd → _ein_tipp_zaehlt_einmal(). Er stellt genau die kaputte Lage nach — Wurf 11 bei Klappen 1–9, also keine passende Einzelklappe — und schickt beide Ereignisse in der Reihenfolge durch den Handler, in der ein Telefon sie liefert.

Gegenprobe gemacht: mit ausgehängtem Fix im Spielcode meldet er Fingertipp zählt doppelt: … steht [].

Was daraus für andere folgt

Dasselbe Muster steht im geteilten mana-Baukasten und ist dort nicht angefasst: mana_tisch_3d.gd:215, mana_bottom_bar.gd:118, builder_camera.gd:150 behandeln ebenfalls Maus und Touch. Pipfold benutzt keines davon — wer es benutzt, hat vermutlich denselben Fehler.

Das gehört einmal am Kit geprüft und nicht hier nebenbei mitgefixt. Ein Baukasten, den sechs Projekte teilen, ist der falsche Ort für eine Änderung, die man in einem davon gerade eilig braucht.

Und die eigentliche Lehre: Prüfläufe, die unterhalb der Eingabe ansetzen, prüfen das Spiel — nicht das Spielen. Zwischen waehle_klappe() und einem Finger auf Glas liegt eine Kette, die niemand getestet hatte, weil sie am Entwicklungsrechner gar nicht existiert.

← Devlog