Thema: RPG Design Patterns

[1of3]

Hi.

Auf der Forge hat ein gewisser John Kirk ein 261-seitiges Buch über Designstrukturen in P&P-Rollenspielen geschrieben.

Ich habs mal überflogen und finde es sehr lesenswert.


Thread auf der Forge

Download

[Ein]

Ich habs mal überflogen und mir einige Pattern wahllos herausgepickt und genauer angesehen.

Es ist soweit okay, allerdings hat es für mich keinen sonderlichen Nutzen, da im Grunde nur Dinge erzählt werden, die jeder erfahrener Rollenspielautor bereits weiß. Ich bezweifel daher auch, anders als die Forgianer, dass dieses Buch das Rollenspieldesign revolutionieren wird.

Im Grunde wäre das ganze was für Einsteiger ins Design, allerdings denke ich, dass man mehr durch Ausprobieren und Analysieren lernt als durch das Kopieren von Mustern. Wir sind schließlich Autoren und keine Codemonkeys.

Der entscheidene Knackpunkt dabei ist, dass die verschiedenen Mechanismen, die in einem Rollenspiel vorhanden sind, nicht isoliert existieren, sondern stets in Wechselwirkung miteinander stehen. Dieses Zusammenspiel kann man meines Erachtens aber nur durch Erfahrung meistern. Die paar lustigen Grafiken im Game Summary sind da kein Ersatz.

Desweiteren ist der Autor voreingenommen bezüglich "gutem" Rollenspiel, ein Problem, dass sich bei jedem analytischen Ansatz ans Design ergibt. Es gibt kein absolut gutes Design, es gibt nur Designs die schlecht sind und solche die gut abgestimmt sind. Was allerdings ein wirklich gutes Design ist vor allem eine Frage vom Geschmack des Betrachters.

[Tantalos]

Ja, wer sich schon mehr mit dem Thema beschäftigt hat, kommt nur auf schon stark begangene Ideen. Aber ich find die lektüre durchaus Interessant und erheiternt. Es werden halt nochmal viele interessante Dinge zusammengefasst. Die Patterns selber halte ich auch für relativ uninteressant, aber es liest sich sehr schön und, und das finde ich im übrigen sehr aufschlussreich, lässt Arbeitsweisen von anderen Bereichen auf das Rollenspiel anwenden.

btw:

Attendance Reward
Intent
Provide players with incentives that reward them for showing up to gaming sessions.#

*lol*

[1of3]

Ist doch treffend.

Bei den Systemen am Ende, sind allerdings einige Fehler drin.

[Morgh]

AAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHH H!!!!!!!!!!!!!!!!!!!!!!!!!!

Sie sind überall!!! Zuerst hiess es nur "Tu das Bad nicht neben das Schlafzimmer!", dann haben sie dir gesagt wie du deine Klassen und Software modellieren sollst und jetzt? Rollenspielpatterns! Ich glaub's nicht.. 

[8t88]

AAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!

Sie sind überall!!! Zuerst hiess es nur "Tu das Bad nicht neben das Schlafzimmer!", dann haben sie dir gesagt wie du deine Klassen und Software modellieren sollst und jetzt? Rollenspielpatterns! Ich glaub's nicht.. 

Spieler und SL brauchst du das garnicht, also keine Sorge!

[Tantalos]

Sie sind überall!!! Zuerst hiess es nur "Tu das Bad nicht neben das Schlafzimmer!",

Warum? Spart doch Weg?

[Gast]

Ich habe das auch mal grob überflogen und werde wenn ich die Zeit habe, dass ganze auch mal vertiefen.

Den Gedanken an sich finde ich schon sehr interessant, was ich natürlich auch darauf zurückführe, dass ich Software-Entwickler bin ;-)
Der Hauptteil der Einwände, die Ein gibt ist für mich auch nichtig. Genau die Sachen kann man sich auch in Bezug auf DesignPattern in der Software-entwicklung anhören. Natürlich sind Design-Pattern nicht ein Alheilmittel, man kann sich kein Software-System bauen, indem man seiner MEinung nach passende Pattern nimmt und sie kombiniert, da läuft man Gefahr totalen Mist zusammenzustellen. Und bei Rollenspielen ist das ähnlich, man kann sich ein Spiel nicht aus Pattern wie Lego zusammenstecken...
Der Sinn von Pattern ist es Probleme, die oft auftreten mit Lösungen und (vor allen Dingen) Lösungsansätzen versorgen. Design Pattern sind abstrakte Lösungen für Probleme die oft vorkommen und wenn ich vor einem Problem stehe von dem ich weiß, dass andere es auch schon hatten habe ich eine gute Chance, dass es ein Pattern gibt. Wenn es eins gibt setze ich das nicht blind ein, sondern evaluiere erst ob es für meinen Fall sinvoll es und entscheide ob ich es einsetze, modifizieren muss oder ganz die Finger davon lasse. Und vor solchen Entscheidungen stehe ich oft. Auch als Rollenspielautor. Und ich finde schon, dass Pattern eine gewisse Hilfe darstellen können.
Auch das mit dem "man kann es nicht in kleine Happen zerteilen" zählt nicht. Man kann das nämlich schon. Man muss sich nur, wie in der SW-Entwiklung, über die Schnittstellen einig und im Klaren sein. Die meisten Leute gehen an die Entwicklung eines Rollenspiels heran wie wir es in der Steinzeit des SW-Entwicklung getan haben: Einfach drauf los.
Intelligentere und bessere Sachen kommen mit Sicherheit heraus, wenn man sich von Zeit zu Zeit auch mal Gedanken zu dem Entwicklungsprozess an sich macht. Dass muss nicht jeder aber einige sollten.
Und ich finde schade, wenn die immer mit einem dutzend schneller Pseudo-Argumente ausgehebelt werden sollen. Klar ich will und werde jetzt auch klein Rollenspiel aus Pattern zusammenbauen (das geht auch gar nicht), aber vielleicht greife ich wirklich mal auf eins zurück? Und da bin ich froh, wenn es welche gibt.
Letzten Endes sind sich Software-Entwicklung und Rollenspielentwicklung recht ähnlich und ich glaube fest dass einige Errungenschaften der modernen SW-Entwicklung auch im Rollenspielbereich Früchte tragen könnten.

Was die Qualität der speziellen Pattern angeht, da denke ich dass man noch diskutieren kann. Pattern sollten wirklich unvoreingenommen sein.

Ach ja zum Abschluss:

Wir sind schließlich Autoren und keine Codemonkeys.

Ich bin kein Codemonkey.
Dieses unterschwellige "wir sind kreativ, die sind dumme Zeilenhacker" finde ich ziemlich daneben.

[Thalamus Grondak]

Letzten Endes sind sich Software-Entwicklung und Rollenspielentwicklung recht ähnlich und ich glaube fest dass einige Errungenschaften der modernen SW-Entwicklung auch im Rollenspielbereich Früchte tragen könnten.

Stimmt, SW-Entwicklung hat sich aus den RPGs die Klassen entliehen.
RPGs wiederrum die Templates aus der SW-Entwicklung 

im Ernst:
Ich kann dir da voll zustimmen. Bestimmte Probleme tauchen immer wieder auf, und da ist es gut, Lösungsvorschläge zu haben. Oft zeigen solche Pattern einem auch Probleme bei etwas das man gerade machen wollte, die man vllt erst viel später bemerkt hätte, und dann hätte man viel Arbeit umsonst gemacht.
Ist Tatsächlich irgendwie wie SW-Entwicklung.

[Hr. Rabe]

@Marcel Gehlen
  Full. Ack.

Aber ich nehme an, Programmierer denken da einfach sehr ähnlich.

----

immt, SW-Entwicklung hat sich aus den RPGs die Klassen entliehen.
RPGs wiederrum die Templates aus der SW-Entwicklung

lol

----

Ich finde die Idee gut, diese Patterns mal aufzuschreiben und solche zu entwickeln.
Den, auch wenn er es (vieleicht) nicht zugeben will, selbst Ein hat für sich selbst implizite Patterns im Kopf. Das hat jeder, der schon zwei oder mehr Rpg-Systeme oder Teile von Systemen geschrieben hat.

Zu den einzelnen Patterns werde ich vieleicht auch noch was sagen, wenn ich mir das durchgelesen habe.

Gruß,
raVen

[1of3]

Wobei der Witz ist, dass der gute Mann tatsächlich Sachen aufgeschrieben hat, die ich nie für ein Pattern gehalten hätte, z.B. Last One Standing.

[Callisto]

* Callisto wirkt die Beschwörung Threadnekromantie ! ! !

Ich lese das gerade, weil ich ja selbst am Basteln bin. Nur, wie genau soll ich mir Gauge übersetzen?

Btw: Ich halte das für eine sinnvolle Lektüre, gerade als Einsteiger ins Systembasteln

[Joerg.D]

Guck mal hier, dass ist etwas neuer :-)

[Callisto]

Ooops, ich hab den halt zuerst mit der SuFu gefunden *unschuldigpfeiff*

edit: Danke !

[Crimson King]

Da ich die RPG-Design Patterns nicht kenne, kann ich nur für die aus der Informatik sprechen. Wenn der selbe Grundgedanke dahinter steckt, lässt sich das aber übertragen.

Die Entwurfsmuster in der Informatik sind Best Practices zur Lösung bestimmter, gut definierbarer Probleme. Solange man sie genau so verwendet, leisten sie auch enorm viel. Was man keinesfalls machen darf, ist sie als Allheilmittel anzusehen und jedes Problem so lange zu transformieren und umzuformulieren, bis man irgendwie irgend ein Pattern darauf anwenden kann. Viele Probleme sind individuell und nicht Standard.