Ich grüble schon seit einiger Zeit über ein Problem nach, für das mir einfach keine gescheite Lösung einfallen will. Begonnen hat es mit dem Versuch, mein geliebtes und mittlerweile recht bewährtes Homebrew für ein breiteres Publikum aufzubereiten. Das System an sich ist eher regelleicht, auch hatte ich nie Schwierigkeiten, die Philosophie dahinter zu erklären. Dennoch wollte es mir nicht gelingen, aus dem Ganzen einen zusammenhängenden Text zu zimmern.
Einer der größten Stolpersteine war dabei die Universalität der Kernmechaniken, die jede zweite Formulierung mit Ausnahmen spicken oder zu hyperkorrektem Wissenschaftlerjargon eindampfen wollte. (Z.B. das Prinzip, das eigentlich alles ein Charakter sein kann... FATE-Spieler kennen vielleicht das Problem, nicht genau zu wissen, was man denn jetzt mit welchem Konstrukt am besten abbildet...) Nicht, dass sich so etwas nicht ausklammern ließe, nur nutze ich an einigen Stellen genau jene Eigenschaft, um die Abstraktionsebene im laufenden Spiel zu verschieben. In einer Massenschlacht etwa wird jede Armee zu einem Charakter, einzelne Soldaten(-gruppen) sind die "Lebenspunkte" dieses Charakters usw.
Dies nur beispielhaft als (häufigeren) Fall des grundsätzlichen Problems: Eine Entwicklung weg von konkreten (optional-) Regeln für jeden Einzelfall hin zu allgemein anwendbaren, tendenziell etwas abstrakteren Mechanismen, wie sie gerade in der Indie-Ecke zu beobachten ist, führt (IMHO) erst einmal zu deutlichem Mehrwert. Eine geschickte Verschachtelung einzelner Regelelemente kann implizit Wechselwirkungen erzeugen, die den Spielablauf grundlegend beeinflussen können, ohne daß der Spieler dazu Mehraufwand betreiben müßte. Meiner Meinung nach bedeutet gutes kohärentes Design auch immer ein enges, nicht immer sofort erkennbares Ineinandergreifen der verschiedenen Regelteile. (Ist SW hier ein gutes Beispiel? Oder verrenne ich mich da?)
Ich bin aber mittlerweile an einem Punkt angekommen, an dem sowohl die Anwendungsmöglichkeiten als auch die Art und Weise, wie bestimmte Mechanismen interpretiert werden können, so vielfältig sind, dass ein Einsteiger diese nicht mehr auf einen Blick erfassen kann. Eine mögliche Lösung, die ich bereits z.T. verfolge ist, für die häufigsten Fälle Anwendungsbeispiele zu geben und es ansonsten bei einem allgemeinen Hinweis zu belassen. Mein System hat da den Vorteil, dass die Zahl der konkreten Optionen überschaubar ist. Ich will mich auch garnicht sosehr an der Universalität eines Systems aufhängen, vielmehr geht es mir um das Verhältnis zwischen expliziter (ausdrücklich beschriebener) und impliziter (energenter) komplexität und wieviel von letzterer man dem Spieler vermitteln sollte.
Ganz simples Beispiel: In irgendeiner Iteration eines "Herr der Ringe"-Rollenspiels hieß es, Probenschwierigkeiten sollten bitte immer Vielfache von 5 sein. Es gäbe Gründe(TM) dafür, die zu erklären aber zu weit führen würde. Das hat mich ein wenig vor den Kopf gestoßen, schließlich sollte ich, zumindest als SL, doch das System, das ich leiten will, verstanden haben.
Letztlich lag der Grund dafür bloß in der Glockenkurve des Würfelsystems und war gar nicht so kompliziert. Zum Einen fällt mir hier auf, daß ein Mechanismus, der das Spiel (hier den Wertebereich der Schwierigkeiten) unnötig einschränkt, eher unter schlechtes Design fällt. Zum Anderen bin ich aber tatsächlich nicht sicher, ob es für den durchschnittlichen Spieler besser gewesen wäre, das Ganze mathematisch aufzubereiten.
Kommen wir also zu meiner eigentlichen Frage: Ist es eurer Meinung nach besser, nur die Regeln an sich zu erklären und die Spieler einfach entdecken zu lassen, wie sich das Spiel in der Praxis anfühlt oder sollte mehr Wert darauf gelegt werden, zu vermitteln, wie sich das Werkzeug, das man dem Spieler in die Hand gibt, an besten einsetzen läßt? Oder verfehlen meine Überlegungen hier des Pudels eigentlichen Kern?
Edit:
Um nicht zu kompliziert zu denken: Angenommen ich hätte einen Mechanismus, der zwei oder mehr an sich grundverschiedene Dinge gut abbilden kann, sollte ich dann versuchen, einfach einen gemeinsamen Namen für diesen Mechanismus zu finden oder ist es günstiger, mehrere gleiche oder ähnliche Mechanismen unter verschiedenen Namen bereitzustellen?