[AMatutat]

Dungeon: Add three audience escape rooms and let the audience pick targets instead of steps

Der PR baut auf dem Publikumsmodus aus #3307 auf. Er bringt drei Escape-Rooms für Lehrveranstaltungen
und ändert, wie das Publikum die Figur steuert. Im FOMO- und im KI-Raum stimmt es nicht mehr über
jeden Schritt ab, sondern wählt ein Ziel aus einer Liste. Die Figur läuft per Wegsuche selbst dorthin
und benutzt das Ziel.

Relay

• Am Relay-Server (Java) ändert sich nichts, auch nicht am Protokoll. Die Geräte schicken als Stimme
  weiterhin die Nummer der Antwort, ab 1 gezählt.
• Geändert ist nur die Seite, die das Relay an die Geräte ausliefert (web/app.js, web/style.css).
  Damit die Änderungen ankommen, muss das Relay neu deployt werden. Ohne Deploy läuft alles weiter,
  die Geräte zeigen dann nur Buchstaben ohne Antworttexte.
• Single und Multiple Choice zeigen die Antworttexte auf den Knöpfen, eine Zeile je Antwort, sobald
  das Spiel sie mitschickt (answers). Die Hinweise darunter verweisen dann nicht mehr auf den
  Spielbildschirm.
• Antworten tragen Buchstaben A, B, C … statt Zahlen, wie auf dem Spielbildschirm. Auf der Tastatur
  wählen die Buchstabentasten, groß oder klein. Beschriftete Optionen wie Ja/Nein behalten die
  Zifferntasten.
• Der Hinweis unter „Weiter“ nennt auch die 2 Sekunden, die bleiben, wenn alle bereit sind.
• Die Seite baut die Eingaben neu auf, wenn sich die Antworttexte ändern.

Engine und Publikumsmodus

Das Paket engine bleibt unverändert, alle Änderungen liegen in feature.*.

Zielwahl statt einzelner Schritte

• Die neue Komponente AudienceTarget hat einen Namen und eine Bedingung, wann das Ziel in der
  Liste steht. AudienceTarget.tile(...) markiert ein Feld wie den Ausgang.
• Ohne offenen Dialog sammelt der neue Kontext AudienceContext.Goto alle Ziele, deren Bedingung
  gilt und die die Figur erreicht, sortiert nach Namen. Die Geräte zeigen ihn als Single Choice
  (controls() liefert choice). Tracking und Spielbildschirm sehen ihn als goto, gezählt wird
  der Name des Ziels.
• TileStepper plant den Weg per Breitensuche über die Felder. Ein Feld zählt nur, wenn auch ein
  einzelner Schritt dorthin ginge. So weicht die Suche Terminals, Truhen und NPCs aus, was die
  Wegsuche der Engine nicht tut. Die Figur läuft den Weg Feld für Feld, dreht sich zum Ziel und
  benutzt es. Was hinter einer geschlossenen Tür liegt, fehlt in der Liste.
• Ist kein Ziel erreichbar, bekommt das Publikum das Steuerkreuz. Räume ohne Ziele steuern wie
  bisher mit Pfeilen.
• Die Zielwahl dauert so lange wie ein Bewegungsfenster und endet 3 Sekunden, nachdem alle
  abgestimmt haben.

Spielbildschirm

• Über jedem wählbaren Ziel steht ein Schild mit Buchstabe und Name. Der Server schickt die
  Positionen mit dem HUD-Zustand, der Client rechnet sie mit der Kamera auf den Bildschirm um.
• InteractionFeedback.showAlways(...) umrandet alle interagierbaren Objekte dauerhaft, ohne
  Mauszeiger, und das Objekt, das „Benutzen“ auslösen würde, rot. Eine zweite Variante nimmt einen
  Filter. In Räumen mit Zielen umrandet sie nur die wählbaren Ziele, der rote Rand entfällt.
• Optionen von Multiple-Choice-Dialogen tragen Buchstaben statt Nummern, auch in der
  Stimmenverteilung (DialogFactory.letterChoiceOptions, DialogFactory.choiceLetter).
• RoomCamera hält die Kamera auf der Mitte des Raums und zoomt so, dass der ganze Raum zu sehen
  ist.

Abstimmung

• AudienceSystem.windowEnd legt fest, wann ein Fenster früher endet. Rätsel und Zielwahl enden
  10 Sekunden, nachdem die Hälfte abgestimmt hat, und 3 Sekunden, nachdem alle abgestimmt haben.
  Texte enden nach 5 und 2 Sekunden. Einzelne Schritte behalten ihre Zeit.
• Bilddialoge, etwa vom Prefab deco-image, bekommen eine „Weiter“-Abstimmung. Die Stimme schließt
  das Bild wie sein Schließen-Knopf.
• Bei Choice-Dialogen schickt das Spiel die Antworttexte an die Geräte (answers).

Bewegung und Level

• Die Figur steht mit der Mitte ihrer Hitbox auf der Mitte des Feldes. Damit funktionieren auch
  Figuren mit größerem Sprite wie der Rogue. AudienceSystem.standOn stellt NPCs genauso auf ein
  Feld.
• Ein Objekt belegt jedes Feld, in das seine Hitbox reicht. Ein zwei Felder breites Whiteboard
  lässt sich deshalb von vor beiden Feldern benutzen.
• Deco hat 33 neue Einträge Lab… mit den Labor-Grafiken aus objects/tech. Stehende Geräte
  blockieren ihr Feld, Wandgeräte nicht.

Neue Räume

• rooms.automaton.AutomatonRoom, „Gefangen im Automaten“ (runAutomatonRoom). Vier Fragen zu
  regulären Sprachen und Grammatiken, Kleene repariert Terminal 3, Steuerung mit Pfeilen.
• rooms.fomo.FomoRoom, „Gefangen im Modell“ (runFomoRoom). Modellierung und reguläre Sprachen,
  Vorraum mit Übungsfragen, Zielwahl, Rätsel mit Modellierungskreislauf und Graphmodell.
• rooms.ki.KiRoom, „Gefangen im Entscheidungsbaum“ (runKiRoom). Fünf Fragen zu maschinellem
  Lernen und Entscheidungsbäumen, Zielwahl. Quinlan baut Terminal 4 wieder auf, und die Reihenfolge
  der Ziffern folgt dem Informationsgewinn.
• Jeder Raum hat eine Vorher- und eine Nachher-Umfrage mit Selbsteinschätzung
  (surveys/pre-<raum>.json, surveys/post-<raum>.json). F4 im Hauptmenü öffnet den Level-Editor.
• game/doc/audience.md beschreibt die Räume, die Zielwahl und wie ein eigener Raum Ziele setzt.

Tests

• Neue Unit-Tests für Wegsuche und Routen (TileStepperTest), Zielwahl und Buchstaben
  (AudienceContextTest), das frühere Fensterende (AudienceSystemTest) und den Filter der
  Umrandung (InteractionFeedbackTest).
• Ein temporärer Test hat FOMO- und KI-Raum mit echten Kollisionen vom Start bis zum Ausgang
  durchgespielt. Er ist nicht eingecheckt.
• Lokal getestet mit ./gradlew :audience:relay:run und
  DUNGEON_AUDIENCE_RELAY= ./gradlew :game:runFomoRoom.
• spotlessCheck, checkstyleMain, checkstyleTest und :game:test laufen durch.

[Flamtky]

Ein paar Punkte habe ich gefunden, vor allem beim Startfeld des Helden.

[Flamtky]

Hatte noch einen dummen Test gefunden