Tapped means shut — one change, three consequences

19 August 2026 · game · design

Till: “when I roll 3+6 and tap the two, they go into a selected mode and only fall over when I tap again — we don’t need that.”

Correct, and for two reasons, either of which would have been enough on its own:

The second grab sat in a different part of the screen — on the dice, down in the tray — while your eyes were on the flaps. And the selected flaps already lie forward, just golden. So they differ from the finished state only by colour.

That does not look like “you still have to confirm this”. It looks like a hang.

The new rule

Every selection falls as soon as it adds up. No confirming tap, straight back to rolling.

An incomplete intermediate state — the 3 alone towards a 9 — stays upright and golden. That is not a confirmation but the question “which one else?”. A second tap on the same flap takes it back.

The one condition that had to survive

Under “plus and minus”, 6 and 5 permit 11 or 1. Whoever is heading for 1+10 = 11 and taps the 1 first already has a valid selection: the 1 alone hits the 1.

If it fell immediately, one point would be cleared instead of eleven — without anyone having made a mistake. That exact bug had been fixed the day before. A plain “valid → fall” would have brought it back.

So the rule reads:

fall as soon as the selection adds up AND nothing larger can still come of it (KlappenRegeln.kann_groesser_werden)

Classically, with exactly one target number, the answer is false by construction — there every completed selection falls at once, which is what this was about. Under plus and minus, a tap on the dice accepts the smaller number.

Consequence one: the hint laid out a finished selection

hinweis() set _auswahl = _hinweis.duplicate(). That used to be harmless: a selection just sits there until somebody confirms it.

Now every completed selection falls immediately everywhere else — but not this one, because the hint triggers no shutting. Touching one of the green flaps would then have deselected it instead of tipping it over. The hint would have put the game into a state you can only leave by taking something away.

For display the selection was superfluous anyway: Kasten3D.setze_klappen checks hinweis before auswahl and colours green. The hint now creates no selection at all — it points, the human taps.

That also fits better with what the manual promises: “shows a possible move but does not play it”. Before, it played it halfway.

Consequence two: the status line said the wrong thing

The bottom line read “3 · 9 to go” — the selected flap and the target number.

That worked while the intermediate state was the exception. Now it is the normal case: every incomplete selection stays, every complete one is gone at once. So the line now says what is missing instead of restating the target:

3 · 6 missing

With multiple targets there is no single shortfall — there the old line stays.

Consequence three: the final move

If every completed selection falls, so does the last one. The special case ist_schlusszug(), built two days earlier for the moment of victory, is therefore no longer a special case but the general one — it was simply right earlier.

The guards

In tools/pruefe_ui.gd:

• 3+6 onto a 9: the first flap stays up, the second closes the move, and afterwards the board waits for a roll.
• 1+10 = 11 under plus and minus falls without confirmation.
• Four counter-tests on kann_groesser_werden — including the case where 11 is still reachable another way without the 10.

The lesson is not about Godot and not about input handling: a simplification collects its cost wherever an exception used to be carried silently. The confirming tap was not only a confirmation — it was also the place where “this could still get bigger” was implicitly accounted for. Delete it, and you have to write that part down explicitly.

← Devlog