Dieser Artikel ist teilweise als Reaktion auf Dietmar Pfohls Leserbrief zu verstehen, geht in der behandelten Problematik aber weit darüber hinaus.
(Michael Schröpl)Wenn es um die Anpassung von Ligasystemen an meine Vorstellungen von United geht, verspreche ich mir von der Verbreitung des Programms UNITED/ST (das ja immerhin bereits auf Apple, ATARI und IBM-PC läuft) wesentlich mehr als von der Verbreitung kluger Sprüche.
Mit einer (hier in Diskussionen zu bestimmenden) hinreichenden Menge von Parametern sollte das Programm in der Lage sein, jedes United-System, das keine wilden Sonderregeln oder -Spieler erfunden hat, mühelos auszuwerten. In Details beschreiben kann man das Programm hier gar nicht, schon das Handbuch zur Bedienung ist über 50 kByte groß.
Alle folgenden Überlegungen basieren darauf, daß die Verwaltung der Daten von ca. 150 Spielern pro Liga eine Aufgabe ist, mit der ein Spielleiter einerseits überfordert ist (man will ja schließlich nicht ständig Fehler machen) und die andererseits auch ziemlich öde erscheint (der GM soll ja seinen Spaß an der Auswertung haben). Jedes Modell, das auf der Verwaltung von Vereinen auf Papier beruht, lehne ich grundsätzlich ab. Aus dieser Situation heraus ergeben sich einige Folgerungen für UNITED/ST und Oberfoul, die ich als unvermeidlich in Kauf nehme.
Das Regelsystem Oberfoul enthält keine einzige Regeländerung allein aus dem Grund, weil wir die Originalregel etwa nicht als programmierbar angesehen hätten.
Lediglich bei der Transferliste haben wir etwas geschlampt, zuerst die einfachste mögliche Implementierung gewählt und danach freudestrahlend festgestellt, daß uns die entstandene Regeländerung (Sperre des Spielers für eine Runde) ohnehin gut in den Kram paßte.
Alle anderen Unterschiede zu United3 stammen entweder aus der Erkenntnis, daß die Regel in United3 lückenhaft oder nicht funktionstüchtig war (A in V, Härte) oder wurden aus der Erfahrung abgeleitet, daß eine Regel, die niemand anwendet, nicht besonders viel Sinn macht (Spionage).
Außerdem kann UNITED/ST ganz erheblich mehr, als die Oberfoul-Regeln zu beachten. Ganz abgesehen von den mannigfaltigen Service-Informationen: An vielen Stellen kann man, wenn man eine entsprechende Abfrage bewußt überwindet, Sachen tun, die laut Regel verboten sind, z. B. Spieler handeln, obwohl die letzte Handelsrunde bereits vorbei ist usw. Dadurch wird das Programm mit einer ganzen Reihe von Anforderungen ganz nebenbei fertig.
Der Rundenablauf in Oberfoul ist streng in 18 Phasen eingeteilt, aber nicht deshalb, weil das Programm dies so haben will - die Phaseneinteilung übernimmt ausschließlich der GM, der in beliebiger Reihenfolge einzelne Phasen auswerten kann. Nach jeder Phase und nach jedem kompletten Spieltag einer Liga (in Realzeit: etwa nach 30 Minuten) kann die Auswertung unterbrochen und später fortgesetzt werden - eine noch feinere Unterteilung hielten wir nicht für nötig.
Die Aussage, daß jede Regel in einem Auswerteprogramm unterzubringen sei, ist grundsätzlich falsch. Wenigstens dies sollte jedem Leser seit meinem Artikel über beliebig komplizierte gegenseitige Abhängigkeiten von bedingten Handeln klar geworden sein. Probleme, die ein Mensch selbst theoretisch nicht lösen kann, kann auch ein von einem Menschen programmierter Rechner nicht bewältigen.
Aber selbst wenn man voraussetzt, daß solche Regeln aus dem Regelsystem verbannt wären, halte ich es schlicht für unmöglich, ein Programmsystem zu erstellen, das mit beliebigen Sonderspielern fertig wird. Das Problem, das dabei entsteht, ist nämlich keineswegs die Art der Reaktion des Programms, sondern vielmehr das Erkennen einer Situation, in der eine Sondereigenschaft zu berücksichtigen ist. Zwei unterschiedliche Strategien wären dabei denkbar:
Nach dieser Erläuterung wird nun manchem Leser etwas klarer werden, wie ich auf meine speziellen Sonderspieler in AUFSTIEG gekommen bin. Ich weiß, welche Informationen UNITED/ST über einen Spieler besitzt, und ich weiß auch, wie solche Informationen verarbeitet werden. Es gibt für jede Eigenschaft eines Spielers unbenutzte Werte, die man mit besonderen Bedeutungen versehen kann: Alter X kommt auf reguläre Weise nicht zustande, also habe ich festgelegt, daß ein solcher Spieler um beliebig viel Stufen altert; Stärke -1 ist normalerweise nicht möglich, also haben wir festgelegt, daß dieser Wert bedeutet, daß ein Spieler in der entsprechenden Reihe nicht eingesetzt werden darf. Diese Liste ließe sich beliebig verlängern.
Meine Sondereigenschaften sind direkt aus den Fähigkeiten des Programms abgeleitet. Mit einem anderen Programmkonzept wäre ich vielleicht noch auf weitere Typen von Sonderspielern gekommen; aber die in AUFSTIEG existierenden Sonderspieler lassen sich in praktisch jedes Auswerteprogramm mit minimalem Aufwand einbauen. Oft wird sogar überhaupt keine Änderung notwendig sein, da diese Spieler ja keine Regel aktiv verletzen; sie besitzen lediglich ungewöhnliche Werte.
Je nach Art des Wertes tendieren die Sondereigenschaften in AUFSTIEG auch dazu, verlorenzugehen; der Trainingsaufwand pro WP ist die einzige unveränderliche Sondereigenschaft, weil es in United einfach keinen Mechanismus gibt, der diesen Wert jemals verändert und dabei wieder auf 'normal' zurücksetzen könnte. Mit Stufen, Trainierbarkeitsgrenzen, Qualifikationen ist das anders: Hier existieren United-Regeln, die für normalerweise nicht vorkommende Werte undefiniert sind und im Programm einfach sinngemäß erweitert wurden.
Der grundsätzliche Vorteil solcher Sonderspieler ist, daß ich eine einzelne, lokal begrenzte Regeländerung vornehme und dabei ganz automatisch den Zusammenhang zum Rest des Regelsystems überprüfen kann. Ich ändere keine Grundregel von United - ich überprüfe lediglich, was denn wohl passieren würde, wenn eine bestimmte Einschränkung aufgehoben oder ein einzelner Wert eines Spielers verändert würde. Dies ist relativ problemlos möglich.
Definiert man dagegen eine neue Eigenschaft eines Spielers, dann muß man sich Gedanken machen, ob und ggf. wie ein normaler Spieler diese Eigenschaft auf natürlichem Wege erreichen kann und welchen Einfluß die neue Regel auf jede einzelne Regel des kompletten Regelsystems hat - letzteres tun leider manche Spielleiter nicht, was immer mal wieder zu lustigen Sonderspielern führt. Ich erinnere als gutes Beispiel an den beliebig hoch trainierbaren Feldspieler, den sein Besitzer dann plötzlich in A einspielen wollte, als er Stufe 30 erreicht hatte ...
Die Idee, das Problem durch eine Aufteilung in mehrere Programme umgehen zu können, ist übrigens ein glatter Trugschluß. In der Tat ist es nämlich notwendig, immer alle Teilprogramme gleichermaßen anzupassen, da ja schließlich alle Routinen auf denselben Datenbestand zugreifen müssen.
UNITED/ST bestand früher wirklich aus mehreren Teilprogrammen: Auswertung, Saisonwechsel und Hilfsfunktionen. Später kam noch das Programm zum automatischen Aufbau eines Ligasystems hinzu. Da alle Programme ohnehin dieselben Grundroutinen verwenden, war es schließlich das einfachste, sie zusammenzufassen - das kostete nur noch halb so viel Speicherplatz.
Das von Dietmar gewünschte Menü existiert tatsächlich; neben der gewünschten Funktion kann u. a. auch das aktuelle Ligasystem gewählt werden (Lukas braucht so etwas, er leitet drei Ligasysteme - oder waren es vier?)