Der Thread heisst doch: Ein Spielleiter muss auch mal "nein" sagen dürfen.
Das, in Kombination die andere Seite der Doktrin das der Spielleiter "Ja" sagen sollte, ist fuer mich ein klarer Indikator das es in dem Thread um das Themengebiet geht wie man mit das "Nein" als Technik sinnvoll einsetzen kann ohne lauter das Warnleuchten vor Augen blinken zu haben das man ggf. auch noch unangebracht Spielerinput blockiert.
Sich dort hinzustellen und am Thread Thema vorbei sich ueber die "Ja" Technik auszulassen, welche Probleme es vielleicht loest, welcher Struktur ihm zu eigen ist und in welchen Ausmass sie dem Nein ueberlegen sei, wirkt es doch ziemlich aggressiv und nicht im geringsten konstruktiv.
Ansonsten, ich habe mich ja fast daran gewoehnt das Argumente meinerseits ignoriert und Beispiele bis kurz vor'm letzten Drittel gelesen werden und dann sinnentstellt aber:
[..] in denen die Spieler nach und nach Möglichkeiten abchecken, bis sie schließlich die richtige finden, weil man das als die interessantere Form von Herausforderung empfindet, ist das völlig in Ordnung [..]Ich bin versucht zu fragen ob ich dem naechsten der erneut unterstellt es ginge beim "Nein" sagen darum das es nur eine einzigen Weg gibt den es zu finden gilt irgendwie Gewalt antun darf.
Um versuchen das Problem strukturell zu betrachten.
Bevor es etwas gibt das es zu betrachten gibt sollte ein Spannungsfeld gegeben werden. Da ich von der Praemisse ausgehe das man aufregende Situationen betrachtet.
Bei den bisherigen Beispielen waere das:
"Der/Die Charakter(e) sind auf der Flucht und befinden sich im dritten Stock eines Gebaeudes."
"Der/Die Charakter(e) beobachten von einer Ballustrade aus den Ballsaal und wollen eingreifen obwohl der Weg die Treppe hinab zu lang braucht."
"Der/Die Charakter(e) wollen in ein Gebaeude einsteigen und koennen nicht durch die Vordertuer."
Um die Struktur zu verdeutlichen haette man bei einer Programmierung dann ein entsprechendes Modul oder Objekt.
In diesem Modul stellt der Spieler dann eine Bedingung auf wie:
"Flucht aus dem dritten Stock mittels Mistwagen geglueckt."
"Distanz zum Ort mittels Kronleuchter ueberwunden."
"Gebaeude per Hintereingang zugaenglich."
Sagt der Spielleiter nun dazu "Ja", ist das Modul bzw. Objekt abgeschlossen,
heisst das Abenteur laeuft ausserhalb des Moduls weiter. Ich stelle nicht in Absprache das das Objekt einige interessante Eigenschaften weiter vererbt, wie der Amok-fahrende Mistwagen, aber der Vorgang, respektive die Prozedur fuer sich genommen ist beendet. So etwas wie:
IF <Player Condition> = True THEN
EXIT SUB;
ELSE [.. ReCall der Prozedur mit <Player Condition> = False ..]
Insofern verstehe ich nicht in wie das "Ja" in Bezug auf den Spannungsaufbau der Szene konstruktiv wirken kann respektive soll. Auf den Spielfluss bezogen beendet es den entsprechenden Spannungsaufbau anstelle ihn irgendwie zu bereichern.
Die Ereignisse werden durch das Nein auch nicht sequentieller, bauen mehr auf einander auf, als das quasi eine Umgebungsvariable angepasst wird.
Angenommen man setzt Hintertuer = False [Weil das Haus keine Hintertuer hat. Weil man keine Hintertueren mehr sehen kann. Weil eine Hintertuer nur eine Vordertuer hinten ist. Weil man Hintertueren nicht abkann seit einem die letzte im RL zankte. etc. ..]
Dann folgt daraus nicht das es eine vorgegebene Sequenz mit einer Geheimtuer und altechsischen Zeichen gibt, die man lesen muss, nachdem man vier NSCs in der Reihenfolge 3 2 4 1 abgraste, sondern nur das da keine Hintertuer ist.
Ebenso kann es natuerlich auf einander aufbauen. Angenommen man findet keinen Kronleuchter, oder der Kronleuchter ist arg weit weg, dann baut die naechste Handlung auf der Nicht-Existenz bzw. der Problem Existenz des Kronleuchter auf.
