Das deutsche Python-Forum

Hi,

Ich habe ein paar Hilfsfunktionen geschrieben, mit denen TextRPGs in reinem Python geschrieben werden können.

Die Skripte sind dabei so nah wie möglich an Skripten für Theaterstücke und trotzdem noch Python.

Im Hintergrund bindet es eine vollständige RPG Bibliothek ein, die auf einem freien (d.h. frei lizensierten) Pen-and-Paper Regelwerk aufbaut ( http://1w6.org ).

Ihr könnt es den Code bisher auf http://freehg.org/u/ArneBab/textrpg finden.

Ein Skript sieht dann zum Beispiel so aus (gerade ad-hoc geschrieben):


Da das alles reines Python ist, kann man damit auch noch verschiedenstes anderes machen, z.B. Wanderungen durch Irrgärten (gibt es in branching_story.py) uvm.

Und ich hoffe, dass ich das Design sauber genug bekommen habe, dass es möglich ist, es so umzustellen, dass mit einem einfachen
from rpg_lib.graphic_rpg import *
das gleiche Skript eine GUI Umgebung nutzen kann (bzw. dass es einfach ist, ein graphic_rpg Modul zu schreiben, das das Skript ausliest).

Für einfache Nutzung habe ich die ersten zwei Kapitel eines Tutorials geschrieben (auch als TextRPG ):
- http://freehg.org/u/ArneBab/textrpg

(Liegt alles in einem Mercurial repository - Versionsverwaltungssystem in Python).

Ich würde mich über Rückmeldungen freuen!

Ich finds gut! :]

Aber die Kommentare und Variablennamen, etc sollte Englisch sein

Freut mich!

Das Beispielskript habe ich gerade extra hier für's Forum geschrieben und während dem Schreiben lokal getestet

Meinst du die Variablen im Tutorial?

Lieben Gruß

Ne, ich meine die im Modul.
Dort ist einiges an Doku nur auch Deutsch und die Modulnamen wie z.B. "Namensgrammatik" sollten auch Englisch sein.

In dem Modul sind noch einige "Altlasten" aus der Zeit als ich gerade mit Python angefangen habe, v.a. in "amov", das erste wirkliche Python Modul (bzw. Package), das ich geschrieben habe, und zu der Zeit fiel mir Programmieren mit deutschen Variablen und Kommentaren um einiges leichter.

Inzwischen habe ich eine Übersetzung der Sachen im amov größtenteils vorbereitet, aber noch nicht durchgeführt.

Gerade bei den Charakterblättern (yaml Dokumenten mit allen relevanten Charakterinformationen) ist noch etwas Arbeit nötig, um sie transparent in verschiedenen Sprachen nutzen zu können, so dass eine Komplettübersetzung wohl noch etwas dauern wird (sie wird wohl kommen, wenn ich das darunter liegende Regelwerk auf Englisch übersetze).

Im textrpg_1d6 package werden dann die deutschen Variablen transparent ersetzt. Bei einigen Charakterdaten werden in Rückgabewerten allerdings noch die deutschen Begriffe angezeigt.

Hm, ich hatte mich mal vor Jahren mit der Realisierung von RPGs und Textadventures beschäftigt und kam da zu dem Schluss, dass ein konsequent objektorientierter Ansatz, wie man ihn damals derweilen bei MUDs sah, das beste wäre. Ich bin mir nicht sicher, wie gut der lineare "storyboard"-Ansatz funktioniert, wenn das ganze komplizierter wird.

Ich würde also Orte, Personen und Gegenstände modellieren und dann gemäß der Regeln interagieren lassen. Gespräche, allgemein die Story wäre für ich ein Wechselspiel aus Aktion und Reaktion, was ich auch über entsprechende "trigger" realisieren würde. Quasi eine große "wenn-dann-Maschine".

Die Idee, quasi eine DSL für Rollenspiele zu bauen, finde ich gut.

PS: Das Spielsystem von 1W6 ist zugegeben einfach und vielleicht für derartige Script-Umsetzungen gut geeignet, aber leider nicht mein Geschmack, was traditionelles P&P-Rollenspiel angeht. Aber ich mag auch Fudge nicht und GURPS ist mir wiederum mit seinen vielen Skills zu kompliziert...

Stefan

Hi Stefan,



Meine Gründe dafür, es so zu probieren sind:
- Es bietet einen schönen Lernweg: Erst einfach erzählen, dann einfache "wenn dann" Abfragen, dann Interaktionen, dann volle state-machines (eine sehr eifnache Version davon ist branching_story.py).
- Es ist einfach Python, d.h. es objektorientiert zu machen ist recht leicht möglich (durch die Charaktere ist es das teils schon).
- Es soll eine extrem einfache Grund-API für Benutzerinteraktionen bieten: story(...) zum Erzählen und ask(...) zum Abfragen (die auch von allen sonstigen Kommandos genutzt werden). Beide können auch in GUIs realisiert werden.

Effektiv: Einfaches soll einfach aussehen, aber es soll Autoren alle Möglichkeiten offen lassen, selbst die, die ich mir selbst noch nicht vorstellen kann.



(Ich habe gerade die Bedeutung von DSL nachgelesen... daher das spezifischere )

Soweit ich es bisher weiß, wurden bisher "externe DSL" geschrieben, also Sprachen, die alles selbst machen.

Ich mit dem TextRPG stattdessen eine "interne DSL" (Domain Specific Language) schreiben, mit der die Nutzer gleich Python nutzen können.

Sie zeigt dann gleichzeitig eine der Sachen, die ich an Python mag: Es ist verdammt lesbar



Rollenspielsysteme sind Geschmackssache, und das ist gut so.

Meiner Erfahrung nach bringt jedes Regelwerk sein eigenes Spielgefühl mit, und auch wenn das "Ein Würfel System" (das RPG dahinter) entworfen wurde, um es leicht zu machen, das Spielgefühl auf verschiedene Welten anzupassen, bringt schon alleine die Tatsache, dass nur ein einzelner W6 verwendet wird, ein eigenes Spielgefühl (auch wenn ich (offline) auch dafür schon zwei Alternativsysteme zur Hand habe).

Effektiv ist es ein Mittelweg zwischen Gurps® und Fudge™. In Kurzform:
- Fudge™ hat zu wenig detaillierte Chars erlaubt und stückweise Charaktersteigerung war nicht möglich (zu große Schritte).
- Gurps® war zu Realitätsfixiert und es mussten zu viele Fertigkeiten aufgeschrieben werden. Außerdem hat es vier Grundeigenschaften festgeschrieben.
- Beide haben tolle Ideen, sind aber inkompatibel.

Das "Ein Würfel System" hat nun einen Wertebereich wie Gurps®, so dass die riesige Gurps® Vor- und Nachteilsliste genutzt werden kann. Gleichzeitig bietet es die Flexibilität von Fudge™ und ermöglicht die Nutzung der vielen kreativen Ideen, die um Fudge™ herum entstanden sind.
Dazu löst es das Fertigkeitenchaos durch die Einführung von Beruf und Hintergrund als Sammlungen von Fertigkeiten auf.

Und es ist echt frei lizensiert

Und jetzt genug des Werbetextes

Und hin zu wichtigen Fragen: Meinst du, dass als grundlegende Nutzerinteraktionen für die Sprachsyntax story() und ask() genügen (wie auch immer sie dann effektiv implementiert werden)?

Sind Spieler (und damit ihre Charaktere) aus deiner Sicht eher aktiv oder passiv? Vor vielen Jahren gab es mal so Solo-Rollenspielbücher, wo man kurze nummerierte Abschnitte lesen konnte, dann eine Entscheidung treffen musste und dann bei einem anderen Abschnitt weiterlesen musste:



Hier bei ist der Spieler extrem passiv, kann nur reagieren und nicht agieren, dafür lässt sich das problemlos mit story() und ask() realisieren. Ich kenne auch Spielleiter und Rollenspiel-Abenteuer, die einen derartigen Spielstil bevorzugen.

Ich bevorzuge es, wenn die Spieler der aktive Part ist und dann die Welt auf ihre Aktionen reagiert. Dies ist mehr die Idee einen "Quellenbuchs", also einer Weltbeschreibung, die den Rahmen setzt und nicht die eines (mehr oder weniger linearen) vorgeschriebenen Abenteuers.

Im letzteren Fall müsste es möglich sein, Dinge wie "im Wald, da sind die Räuber" ;) auszudrücken, damit es dann - jedenfalls wenn der Charakter aus Sicht dieser Räuber ein lohnendes und schwaches Ziel abgibt - zu einem Überfall kommt, wenn der Spielercharakter irgendwann den Wald betritt.

Vielleicht willst du aber eher die klassischen Textadventures (interaktive fiction) nachahmen während ich eher etwas wie Hack, Bard's Tale oder Baldur's Gate im Hinterkopf habe. Für Textadventures sollte dein Ansatz denke ich funktionieren. Man kann ihn ja dank Python beliebig ausbauen.

Übrigens, kennst du BUS, PUB und POO?

Stefan

Ich glaube nicht, dass man D&D Rollenspiele wie Baldur's Gate als klassisches Text-RPG umsetzen kann. Um die Komplexität der Regeln für den User verständlich umzusetzen, braucht es ein richtiges UI, also im mindesten Curses.

D&D ist sowieso zu kompliziert :) Mir ging es bei der BG-Referenz weniger konkret um eine D20-Umsetzung als um die Art der Spiele, dem Spieler (wenigstens gefühlt) die Kontrolle zu überlassen.

Im "normalen" Rollenspiel am Tisch schaue ich auch nicht laufend auf den Charakterbogen. Ich konzentriere mich da auf die Interaktion. Ich glaube daher, es wäre möglich. Ich hatte mal ein Konzept für "Linear Hack" ausgearbeitet, das nur mit einer Kommandozeile wie ein Textadventure auskommen könnte. Sicherlich nicht die ideale Interaktionsform, mehr ein Gedankenexperiment, ob's gehen könnte. Im Prinzip ein Dialog mit dem Computer, wie mit einem menschlichen Spielleiter.

Ein passendes Regelsystem hat möglicherweise Forgotten Futures mit nur drei Basiseigenschaften BODY, MIND und SOUL, die einen Charakter beschreiben. Diese Werte zusammen mit dem Gesundheitsstatus kann man auch noch im Kopf behalten. Dazu kommen zwei dutzend Fertigkeiten, von denen ein Charaktere eh nur ein paar hat. Die kann man sich auf Eingabe von "stats" oder so auch schnell listen lassen.

Stefan

Ach so, dann habe ich dich missverstanden


Ich finde, dass kann man nur bedingt vergleichen. Am Tisch rechnest du händisch aus, was Treffer- und Rettungswürfe angeht. Nach dem zehnten Kampf kennst du die Werte deiner Charaktere zwangsläufig auswendig.
Und bei weniger häufigen Werten muss man auch da nachschauen.

Am PC, wenn alles automatisch gerechnet wird, merke ich mir das gar nicht. Und wenn ein Kampf gegen irgendein Giftvieh ansteht, dann muss ich immer erst in den Charakterbogen schauen, um das geeignetste "Frontschwein" auszuwählen (e.g. der mit dem besten Rettungswurf gegen Gift).

Das muss ein Text-Interface unterstützen, und bei einem simplen Eingabe-Interface wird das schwierig.

Aber eine D&D Umsetzung mit ncurses wäre sicherlich cool


Zumindest in Kämpfen könnte man sich überlegen, wichtige Werte vor der Frage auszugeben. Ich kenne Forgotten Futures nicht, aber bei D&D-Regelsystemen wären das beispielsweise der Status des Charakters (gelähmt, vergiftet, geblendet, etc.) oder seine Gesundheit.

Gibt es beim aktiven Spiel irgendeine direkte Interaktion, die sich nicht mit story() und ask() realisieren lässt? D.h. sind story() und ask() eine ausreichende Grundlage für komplexere Interaktionen?

Die ersten, die ich vorhabe zu ermöglichen sind einfache TextRPGs, weil die am leichtesten zu implementieren sind.

"Im Wald da sind Räuber" sollte ja im Endeffekt auf "ask('where do you want to go'); if target == 'wood' and chars.weaker_than(enemies): story('there are enemies in the wood')" runterzubrechen sein.

Ich will aber darauf achten, dass das System vollständig erweiterbar ist (dafür habe ich zum Beispiel story() und ask() vor kurzem auf wrapper für Klassenfunktionen umgestellt. Erst können sie von Modulen mit recht wenig Aufwand vollständig uminterpretiert werden).

Ich bin noch nicht ganz sicher, wie ich ein GUI RPG realisieren kann, das mit einem einfachen "from graphic_rpg import *" in eine Story eingebunden wird (bin da noch etwas auf unischerem Grund).

POO und PUB sehen übrigens klasse aus!
(Ist BUS wirklich eher ein schwächeres PUB, oder komplett anders realisiert?)

Ich bin am überlegen, ob ich die vielleicht mit einbinden kann, o.ä.. Sie könnten direkt komplexe Geschichten und Eingabeerkennung liefern (nicht zu vergessen, Netzwerkunterstützung uvm.).

Danke für die Links!

Solange die Story linear ist, schon.


Das ist nur dann einfach, wenn die Story linear verläuft, sprich, es nur wenige klar definierte Punkte gibt, an denen der Wald betreten werden kann.

Ein RPG sollte aber – und darauf wollte sma imho auch hinaus – eine nicht-lineare Story verfolgen, bei der der Charakter zu jedem bestimmten Zeitpunkt (bis auf wenige Ausnahmen wie Quest-Dungeons) überall alles tun kann, funktioniert das nicht mehr, wenn du dich nicht mit if-Abfragen tot-programmieren und DRY einhalten willst.

Für nicht-lineare Stories, die dem Spieler weitgehende Handlungsfreiheit einräumen, musst du das System umgestalten. Der Wald (und jedes andere Gebiet) darf dann nicht mehr durch den String "wood" definiert werden, ebenso wenig wie Charaktere unabhängig "im Raum schweben dürfen". Stattdessen musst du jedes Gebiet als Objekt modifizieren und jedem NPC und jedem Monster einen Aufenthaltsort zuweisen. Ein Player-Charakter könnte dann eine "move" Methode haben, die die "leave" Methode des aktuellen Aufenthaltsorts aufruft, eine Reisezeit in die Spielzeit einkalkuliert und anschließend die "enter" Methode des Gebiets aufrufen. Diese "enter" und "leave"-Methoden würden dann jeweils die Trigger auslösen. Ein Monster könnte dann eine "check_attack" Methode besitzen. Die "check_attack" Methode der Räuber wäre dann als Trigger registriert, so dass die Räuber den Charakter eventuell angreifen würden.

Ich arbeite mit einem Regelwerk, bei dem für einen Charakter nur die Werte aufgeschrieben (und damit ausgegeben) werden, die ihn von der Masse abheben.

D.h. was dann ausgegeben würde sind
- etwa 3 Eigenschaften (Stark, schnell, schön, Charismatisch, ... jeweils mit Zahl und einfacherer Darstellung, die für Spieler direkt klar sein sollte (Bsp: sehr gut ist +, überragend ist ++)
- etwa 3 Fertigkeiten und ein Beruf: Was der Char gelernt hat.
- Besonderheiten wie die Spezies des Char, "einarmig" oder "photographisches Gedächtnis".

Dazu Waffe (mit Fertigkeitswert und Schaden), Rüstung (mit Schutz), Wunden und vll. Trefferpunkte (sind nicht unbedingt nötig zu sehen, Wunden sind wichtiger).

Und das kann man auch gut als Text ausgeben, bzw. für bestimmte Situationen nur relevante Werte ausgeben (beim Bequatschen einer Wache bringt mir Schadensresistenz wenig, also warum es anzeigen?).

Außerdem kann man sich "was kann er" da auch leichter merken, bzw. eine kompaktere rein textbasierte Darstellung wählen wie

--- --- --- --- --- ---
Brok
° Große Stärke
° Überragende Konstitution
° Schwache Intelligenz

* Gut im Nahkampf
* Exzellent im Trinken
** Guter Schmied

| Waffe: Dolch (+, 3) # Fertigkeitswert, Schaden
| Rüstung: Straßenkleidung (1)
--- --- --- --- --- ---

(jede einzelne Beschreibung entspricht direkt einem Wert)

Bzw. wirklich komprimiert (und nur "wo gut, wo schwach", nicht die direkten Werte):
--- --- --- --- --- ---
Brok:
+ Stärke, Konstitution
- Intelligenz
* Fertigkeiten: Nahkampf (+), Trinken (++)
* Beruf: Schmied (+)
| Ausrüstung: Dolch (3), Straßenkleidung (1)
--- --- --- --- --- ---

So sind die Chars dann auch leicht zu merken (und als SL bringt es auch große Vorteile, Werte für weniger wichtige NSCs schnell aus dem Ärmel schütteln zu können ).

Die kompakten Werte sind eine Vereinfachung des Wertes dahinter (z.B. sind 14, 15 und 16 gerade "+"; wieviele + ein Wert hat wird auch zur Bestimmung der Kosten einer Steigerung genutzt) und zeigen Spielern direkt, wie gut sie im Vergleich zu anderen sind.

Kann ich die "move" Methode nicht einfach durch
ask("What do you want to do?") -> "move to wood" ausdrücken?

Sieht für mich einfach nur nach "Antworten intelligent/flexibel parsen" aus.

Was das System darunter kann, lässt sich anpassen. Wichtig ist für mich zu wissen, ob ask() und story() die gesamte Interaktion erfassen kann.

Gibt es bei grundlegender Interaktion noch etwas anderes als dem Spieler etwas sagen und eine Eingabe des Spielers anfordern?

ask() gibt den eingegebenen Textstring zurück, nicht nur ja/nein.
Bsp. für eine etwas komplexere Nutzung: http://freehg.org/u/ArneBab/textrpg/fil ... g_story.py

Wenn ask() und story() alles erfassen können, kann das System nämlich ask() und story() in verschiedenen Modulen unterschiedlich definieren und damit die Ausgabe anpassen, ohne das die Geschichte neu geschrieben werden muss.

Anmerkung:
Für ein Graphisches RPG wäre z.B. auch story(background_image = "environment.png") oder ask(answer_type="arrow_keys") eine Möglichkeit.

Alles in der story-Funktion zu schreiben halte ich für sinnvoll, weil dann das Anzeigemodul entscheiden kann, in welcher Reihenfolge es welche Teile der Story umsetzen will (und der Autor nicht darüber nachdenken muss). Mit einzelnen Aufrufen kann ein Autor natürlich immernoch eine bestimmte Reihenfolge erzwingen.