Autor Thema: Alternative Scheduling-Algorithmen für das Sequenzwert-System  (Gelesen 222 mal)

qxmbjjgj

  • Newbie
  • *
  • Beiträge: 1
    • Profil anzeigen
In meiner Gruppe ist (wegen Robotern und Street-Sams) das Problem, dass die Spieler schon fertig sind mit dem Töten bevor der erste NPC zum Zug kommt, besonders ausgeprägt.

Um trotzdem mit den vorgefertigen NPCs aus dem GRW spielen zu können habe ich nach systematischen Abhilfen gesucht und bin auf folgendes gekommen:

Jeder am Kampf beteiligte Charakter/Gegenstand würfelt nach Vanilla-Regeln zu Beginn jeder Runde seinen Sequenzwert.
Wir setzen eine Zahl, die ich »Rundenzeit« nenne auf die Summe aller Sequenzwerte.
Wir bestimmen den Charakter, der am Zug sein soll indem wir ihn zufällig wählen, gewichtet mit seinem jeweiligen Sequenzwert (wir könnten z.B. eine Zufallszahl erzeugen zwischen 0 und der Rundenzeit erzeugen (im Zweifel mit 3d10 o.ä.)).
Der Charakter am Zug gibt ein Quantum AP aus (z.B. mindestens 10)—die ausgegeben AP werden abgezogen vom Sequenzwert des Charakters und von der Rundenzeit.
Hat kein Charakter mehr einen Sequenzwert über 0, so ist die Runde beendet und neue Sequenzwerte werden gewürfelt (analog zu Vanilla übertragen sich negative Sequenzwerte).

Liegen Ereignisse vor, die z.B. laut GRW nach einer bestimmten Anzahl AP geschehen sollen (z.B. eine Granate explodiert) so wird deren Sequenzwert auf die aktuelle Rundenzeit minus die angedachte Anzahl an AP, multipliziert mit der Anzahl von Spielern (t_ereignis = rundenzeit - (t_ap * anzahlSpieler)) gesetzt – auch denkbar wäre hier mit 100/rundendauer (wobei rundendauer hier die Summe der Sequenzwerte zu Beginn der Runde meint) zu skalieren.
In diesem Fall erweitern wir die Bestimmung, welcher Charakter am Zug ist um eine Klausel, die besagt, dass Ereignisse genau dann am Zug sind, wenn die Rundenzeit kleiner oder gleich ihrem Sequenzwert ist.

Handhabhar halte ich das ganze mit einer Implementierung mancher Teile des Contact-Kampfsystems (inklusive dem Vanilla- und obigem Sequenzwert-System) in Haskell auf meinem GM-Laptop.
Bei Interesse könnte ich eine simpler zu bedienende/wartbarere Implementierung z.B. in python basteln.