Michael Schröpl, 1998-09-30)(Version 1.1, Michael Schröpl, 1998-09-30)
Ein großer Teil des Aufwands bei der Durchführung einer United-Auswertung besteht in der Eingabe der Anweisungen aller Manager durch den Spielleiter.
Ein Verfahren zum automatischen Einlesen von Anweisungen der Manager würde also die Dauer einer Auswertung möglicherweise erheblich verkürzen - unter zwei Vorausetzungen:
Bisher kennt UNITED/XY keine eindeutige Identifikation eines Spielers.
Wann immer der Spielleiter also irgendetwas tut, was sich auf einen einzelnen Spieler bezieht (Training, Aufstellung etc.), muß er diesen Spieler aus dem Mannschaftskader des Vereins auswählen, und dafür gibt es bisher kein wirklich zuverlässiges Verfahren in United: Theoretisch könnte ein Verein lauter Spieler mit identischen Daten besitzen.
In den meisten Fällen wird der Spielleiter das "schon irgendwie hinkriegen", aber eine Lösung für eine Programmschnittstelle ist "Raten" natürlich nicht.
Um das Problem wirklich zu lösen, bieten sich diverse Verfahren an:
Natürlich hat eine Lösung, die ohne eine erzwungene Änderung der bestehenden Regeln auskommen würde, eine höhere Chance auf eine allgemeine Akzeptanz bei den Spielleitern. Und es war schon immer die Philosophie von UNITED/XY, daß wir keine Insellösungen bauen wollen, sondern etwas, das jeder Spielleiter guten Gewissens einsetzen kann.
Daher würde ich das Primärschlüssel-Modell bevorzugen, falls sich hierbei keine unüberwindbaren Probleme für alle Beteiligten (hier sind insbesondere auch alle Manager gemeint!) ergeben.
Ein häßliches Problem gibt es allerdings genau bei der "schönen" Primärschlüssel-Lösung:
Wie bekommt der Manager die Primärschlüssel, die er in seinen Datenbestand eingeben muß? Und wie adressiert er einen Spieler bereits in derjenigen Runde, in welcher der Spieler entsteht (Einspielen bzw. Handeln eines Talents in der Runde seiner Entdeckung)?
Lustigerweise ist ein ganz ähnliches Problem aber auch bei der Lösung mit den eindeutigen Spielernamen existent:
Wenn der Spielleiter (oder das Auswerteprogramm) während der Auswertung einen als mehrdeutig erkannten Spielernamen ändert, dann entzieht es dem Besitzer die Adressierungsbasis: Der Manager kann ja im allgemeinen Fall gar nicht wissen, wie seine Spieler in einer bestimmten Phase der aktuellen Runde, für die er gerade Anweisungen formulieren will, wirklich heißen werden.
Das Problem ist in beiden Fällen fundamentaler Natur: Es werden eindeutige Identifikationen für Spieler benötigt, aber bevor der Manager diese vom Spielleiter über die Auswertung erhalten hat, muß er sie bereits einsetzen.
Aus der Natur dieses Problems läßt sich eine allgemeine Methode zu seiner Lösung ableiten: Die Vergabe von eindeutigen Primärschlüsseln läßt sich von der Zuordnung dieser Primärschlüssel zeitlich trennen, indem jeder Manager einen Pool von nur ihm zugehörigen Primärschlüsseln erhält.
Bei der Verwendung von Spielernamen ist eine Vorweg-Reservierung natürlich weder eine schöne noch eine triviale Lösung, denn die meisten Manager werden sich ihre Spielernamen selbst aussuchen wollen, und ihnen das zu verbieten wäre eine weitere Regeländerung.
Bei der Verwendung von selbstdefinierten Primärschlüsseln hingegen kann der Spielleiter zu Saisonbeginn jedem Manager eine Handvoll Zahlen ("Nummern der Personalausweise", für die Simulationisten) reservieren, ohne ihn bei der Wahl seiner Spielernamen einzuschränken.
Dieser Pool kann statisch oder dynamisch definiert sein:
Das folgende funktionsfähige und transparentere System zur Vergabe von eindeutigen Primärschlüsseln hat Karl-Wolfgang Weigel vorgeschlagen.
Hierbei wird die Entstehungsgeschichte des Spielers in den Primärschlüssel codiert, und da bei geeigneter Codierung nicht zwei Spieler exakt dieselbe Entstehungsgeschichte haben können, wäre die Eindeutigkeit der Primärschlüssel ebenfalls gewährleistet.
Das Verfahren kommt zudem fast ohne eigene Infrastruktur aus, da sämtliche Informationen im Prinzip bereits heute in TEAMCHEF verfügbar sind (ggf. noch nicht in exakt der hier genannten Syntax).
Konkret bietet sich bei dieser Idee als Primärschlüssel eine Zeichenkette der folgenden Struktur an:
S-L-V-E-Nr.
, wobei die "-"-Zeichen nur zur lesbaren Gliederung eingefügt sind und die einzelnen Abschnitte folgende Bedeutung haben:
| S | Nummer der Saison in der Historie des Ligasystems (positive ganze Zahl) |
|---|---|
| L | Liga des Vereins in der laufenden Saison (positive ganze Zahl) |
| V | Nummer des Vereins innerhalb seiner Liga (positive ganze Zahl, z. B. der im Saison-Info veröffentlichte und bei der Adressierung des Spielplans verwendete Wert) |
| E | Art der Entstehung des Spielers (ein Buchstabe: T für Talententdeckung, G für GM-Angebot) |
| Nr. | Nummer des Spielers innerhalb der Entstehungsart (bei Talenten eine Zahl von 1 bis 3, bei Spielern des GM-Angebots die Kombination aus Rundennummer und laufender Nummer des Spielers im Angebot, getrennt durch das Zeichen "/") |
In diesem Falle wäre der Typ des Primärschlüssels programmintern eine Zeichenkette. Um nicht überflüssigen Platz zu verschenken (unter DOS sind es halt immer noch nur 640 kB), könnte man
abschätzen, so daß trotz aller Strukturierung schlimmstenfalls 16 Zeichen pro Primärschlüssel zusammenkommen würden. (Und das halten wir aus.)
Ein zusätzliches Problem sollte man nicht außer Acht lassen: Die Identifikation eines Spielers kann für einen Manager auch aus einer fremden Quelle kommen, nämlich von einem anderen Manager.
Dieser Fall tritt dann ein, wenn der Manager einen bereits existierenden Spieler in seinen Mannschaftskader aufnimmt. Das ist der Fall bei
Bei der Transferliste kann der Primärschlüssel des Spielers vorher in der Auswertung veröffentlicht werden; beim Privaten Handel muß die Identifikation zusammen mit den anderen Daten des Spielers zwischen den Handelspartnern übermittelt werden.
Man kann natürlich auch alle Primärschlüssel im Saison-Info veröffentlichen - es ist ja nix wirklich Geheimes an ihnen dran (bei entdeckten Talenten steht zwar das Alter des Spielers im Primärschlüssel, aber das kann man auch durch Mitschreiben herausfinden).
In einigen Ligasystemen ist es üblich, während der Saisonpause einen Datenabgleich zwischen Manager und Spielleiter durchzuführen. Dieser Vorgang wird von UNITED/XY bisher bereits insofern unterstützt, als das Programm eine übersichtliche Liste aller Vereins- und Spielerdaten in eine Textdatei ausgeben kann. In meinem Ligasystem AUFSTIEG kann ein Manager jederzeit eine solche Liste anfordern, indem er mir einen an sich selbst adressierten, frankierten Briefumschlag schickt.
Bevor ein Teil eines Zuges, in der OBERFOUL-Terminologie unter dem Namen "Phase" bekannt, zur Auswertung kommt, müßte das Auswerteprogramm in der Lage sein, überhaupt zu erkennen, welche der vorliegenden Informationen als nächstes auszuwerten sind.
Solange der Spielleiter die Sache manuell auswertet, ist er in der Lage, entsprechende Phasenauswertungsfunktionen des Auswerteprogramms mit entsprechenden Informations-Teilmengen aus den ihm vorliegenden Zügen zu versorgen, also in Phase 2 der OBERFOUL-Rundenstruktur auch wirklich die Nichtligaverkäufe für Phase 2 auszuwerten und nicht auch diejenigen für Phase 4, 6, 8, 10, 12, 15 und 17 gleich mit. Diese Phasen heißen in der UNITED/XY-Terminologie alle "Nichtligaverkauf" - das Programm ist darauf vorbereitet, daß eine Phase mehrfach auftreten kann, und hängt einfach weitere Ausgaben an das Ende einer bereit bestehenden Protokolldatei an. Eine Notwendigkeit´, mehrere Phasen desselben Typs unterscheiden zu können, bestand bisher nicht.
Das Zuganfertigungsprogramm TEAMCHEF kennt hingegen sehr wohl eine Phasennumerierung, denn viele Spielleiter (u. a. die beiden Programmautoren von UNITED/XY) fordern diese von ihren Managern.
Um UNITED/XY begreiflich zu machen, welche von mehreren gleichartigen Phasen gemeint ist (also welche der vorliegenden Zugdateien jetzt relevant sind und welche erst später drankommen sollen), bieten sich verschiedene Wege an:
Wenn irgendwas innerhalb eines eingelesenen Zuges eines Managers nicht in Ordnung ist, dann möchte der Spielleiter diesen Zug wahrscheinlich doch lieber selbst eingeben können (und dann dem hierfür verantwortlichen Manager hoffentlich eine saftige Geldstrafe aufbrummen :-).
Hierbei sind verschiedene Realisierungsformen mit erheblich unterschiedlichem Aufwand vorstellbar:
Ganz abgesehen von dem zusätzlichen Aufwand für die Neuprogrammierung aller Eingabedialoge (die schon jetzt einen ganz erheblichen Teil des Programmumfangs ausmachen) stellen sich folgende Fragen:
Ein Zug besteht aus einer Menge von Dateien. Jede einzelne Datei enthält Anweisungen eines Vereins für genau eine Phase.
UNITED/XY stellt ein Verzeichnis mit dem Namen zuege zur Verfügung, in welchem das Programm Zugeingabedateien erwartet. Der Spielleiter kopiert ankommende Zugdateien in dieses Verzeichnis.
Zu diskutieren wäre die Frage, ob das Auswerteprogramm erfolgreich verarbeitete Zugdateien verbrauchen, also löschen soll, oder ob der Spielleiter selbst am Ende der Runde das Zug-Verzeichnis löschen sollte. Der Spielleiter möchte vielleicht die Menge aller Zugdateien für den Fall einer Rückfrage eines Managers archivieren können; vielleicht denkt er eher während der Auswertung daran als vor der Auswertung, und das wäre bereits zu spät, falls das Programm ausgewertete Dateien selbst löscht. (Das wird wohl am Ende ein Programmparameter werden, ich sehe es schon kommen.)
Der Name einer Zugdatei besteht aus Basisname und Endung und entspricht in seiner Syntax den Anforderungen des Betriebssystems DOS 6.0.
Der vorliegende erste Entwurf eines Dateiformats beschränkt sich auf die Darstellung der innerhalb einer syntaktisch und semantisch korrekt aufgebauten Zugdatei minimal zu transportierenden Informationen.
Damit der Spielleiter auch einen fehlerhaften Zug doch noch irgendwie auswerten kann, bietet sich allerdings die Angabe redundanter Informationen an. Beispielsweise ist ein Spieler durch seinen korrekten Primärschlüssel eindeutig beschrieben; die zusätzliche Angabe des Spielernamens bzw. seiner ungefähren Werte (welche sich ja inzwischen durch spieltechnische Effekte geändert haben könnten) würden es dem Spielleiter erlauben, den Zug möglicherweise zu interpretieren, wo es dem Auswerteprogramm nicht gelungen ist.
Um einem möglichen Mißverständnis vorzubeugen: Wenn ein eindeutiger Primärschlüssel definiert ist, dann macht es wenig Sinn, die mitgelieferten redundanten Daten mit den vorliegenden Daten des entsprechenden Spielers zu vergleichen und bei irgendwelchen Abweichungen einen Fehler zu vermuten (und einen Spielleitereingriff zu erlauben). Wären die mitgelieferten Daten nämlich zuverlässiger als der Primärschlüssel, dann bräuchten wir den Primärschlüssel nicht.
Wenn das Programm also den Spieler mit dem Primärschlüssel 0815 findet, dann wird es versuchen, die gewünschte Operation für ihn auszuführen, egal welche redundanten Daten ggf. mitgeliefert wurden und wie stark diese von den vorliegenden Daten abweichen. In dieser Hinsicht wird das Programm weniger mißtrauisch sein als ein Spielleiter - wenn der Manager einen Spieler mit der Identifikation eines anderen, existierenden Spielers seines Mannschaftskaders bezeichnet, dann ist er selber schuld, wenn Murks dabei herauskommt.
In meinen Auswerteprogrammen ist generell das Verfahren verbreitet, bestimmte Informationen am Anfang einer Dateizeile zu lesen und den Rest der Zeile zu ignorieren. (Das liegt an der verwendeten Standardprozedur der Programmiersprache PASCAL, bei der genau dieses Verhalten besonders einfach zu realisieren ist.) An dieser Methode werde ich mich bei der Aufnahme redundanter Informationen in Zugdateien orientieren, so daß ein Autor eines Zugdateierstellungsprogramms an dieser Stelle entsprechende Freiheitsgrade über die mitzuliefernden redundanten Informationen haben, ohne daß bei einer Änderung seiner Vorstellung über redundante Informationen das Dateiformat in UNITED/XY angepaßt werden muß.
Das Auswerteprogramm UNITED/XY besitzt keine unveränderliche Kennzeichnung für den Namen einer Reihe. Die in Deutschland üblichen Zeichenketten T, A, V, M und S sind sprachabhängig und als solche Bestandteil der Meldungsdatei UNITED.MSG.
Daher sollte eine Dateischnittstelle zur Identifikation einer Reihe eine sprachunabhängige Notation zu verwenden. Eine solche Notation ist die Numerierung der Reihen in der Reihenfolge:
| T | A | V | M | S |
|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 |
Ein Spielername in UNITED/XY ist eine maximal 30 Zeichen lange Zeichenkette.
Da diese Zeichenkette variabel lang sein kann und beliebige Zeichen enthalten darf, wird ein Spielername jeweils eine eigene Zeile in jedem nachfolgend beschriebenen Dateiformat einnehmen und diese Zeile im Gegensatz zu allen anderen Zeilen keine zusätzlichen Informationen enthalten dürfen. (Da Spielernamen nur bei der Entstehung eines Spielers anzugeben sind, wird dies nur wenige Dateiformate betreffen.)
Bisher ist es üblich, daß ein Manager in bestimmten Phasen seine Anweisungen bedingt formulieren darf. In keiner mir bekannten United-Regel ist allerdings eine formale Definition der Sprache angegeben, in der diese Bedingungen formuliert werden dürfen - wenn ich meinem Spielleiter sage:
"Falls 10000000000000000000000000001 eine Primzahl ist, verkaufe bitte den Spieler XYZ"
, dann wird dieser wohl oder übel irgendwas tun müssen, was nicht in seiner Regel steht (oder sich einen Nobelpreis verdienen, indem er ein schnelles Verfahren zur Faktorisierung erfindet).
Die Spezifikation einer Sprache, in welcher Bedingungen so formuliert werden könnten, daß UNITED/XY diese selbständig auswerten könnte, ist einerseits eine erhebliche Arbeit und andererseits würde sie eine erhebliche Regeländerung für praktisch alle bestehenden Ligasysteme bedeuten. Ganz zu schweigen davon, daß die wenigsten Manager mit Freude eine algebraische Kürzelsprache lernen werden, für die ich einen einfachen Parser schreiben muß (denn die wird nicht in erster Linie für Menschen einfach zu begreifen sein).
Was man statt dessen aber machen kann, ist die Beibehaltung der bisherigen Regelung, nämlich Prosa in natürlicher Sprache, und die Anzeige einer entsprechenden Bedingung durch das Auswerteprogramm, so daß der Spielleiter die Bedingung in diesem Moment selbst auswerten und das Ergebnis ("Ja" oder "Nein") anschließend eingeben kann. Aus Gründen der Endlichkeit der Bildschirmdarstellung wird die Länge dieses Prosatextes wohl irgendwie beschränkt werden müssen - aber immerhin muß der Manager diesen Text ja auch selbst vorher eintippen.
Diese maximale Länge des Textes ist natürlich selbst auch eine Art Regeländerung, aber was den Managern vorher nicht explizit zugesagt wurde, kann man vergleichsweise einfach ändern.
Der naheliegende Sonderfall ist die leere Zeichenkette als Bedingung. Diese ist automatisch erfüllt und muß nicht explizit vom Spielleiter bestätigt werden. In einem Ligasystem, in dem keine Bedingungen erlaubt sind, wird der Spielleiter also keine Bedingungen im Dialog zu bestätigen haben. (Dieses erwünschte Dialogverhalten läßt sich natürlich durch Erziehung der Manager weniger zuverlässig erreichen als vielmehr durch einen Programmparameter von UNITED/XY, welcher den Auswertungsdialog für Bedingungen unterdrückt und statt desseb alle ggf. doch angegebenen Bedingungen automatisch als erfüllt ansieht.)
Ein Gebot für einen zu versteigernden Spieler besteht immer aus genau einer nicht negativen ganzen Zahl.
Im Rahmen erlaubter Bedingungen ist es bisher üblich, daß ein Manager mehrere Gebote für einen Spieler abgeben darf, wobei normalerweise nur genau eine der verwendeten Bedingungen erfüllt sein sollte.
Für UNITED/XY wäre es prinzipiell kein Problem, wenn ein Manager beliebig viele Gebote für denselben Spieler abgeben würde, denn bei der Auswertung eines jeden einzelnen Gebots wäre sofort feststellbar, ob dieses Gebot zum Kauf des Spielers führen kann oder nicht - irgendeines der Gebote mit erfüllter Bedingung ist letztlich das höchste und wird alle vorherigen Gebote dieses Vereins überschreiben. Fragt sich natürlich, wie glücklich ein Spielleiter ist, wenn ein Manager ihn fröhlich 257 verschiedene Bedingungen für Gebote auf denselben Spieler auswerten läßt - dazu muß der Spielleiter ja normalerweise irgendwas tun, und das kann ziemlich lästig werden. (Da wird sich der Spielleiter dann wohl einen Parameter herbeisehnen, der die maximale Anzahl von Geboten eines Vereins auf denselben Spieler limitiert und bewirkt, daß UNITED/XY alle weiteren Gebote des Vereins für diesen Spieler überliest.)
Darzustellende Informationen:
Der hierbei zu verwendende Primärschlüssel kann von UNITED/XY selbst erzeugt werden. Solange beide Programme synchron arbeiten, ist eine Angabe des Primärschlüssels an dieser Stelle nicht erforderlich. Wird der Primärschlüssel jedoch hier angegeben, dann ist eine explizite Überprüfung der Synchronität beider Programme möglich - mir ist allerdings im Moment nicht klar, was der Spielleiter mit dieser Information anfangen kann. (Bestenfalls wird er etwas früher merken, daß der Manager ab diesem Moment mit falschen Daten arbeitet, aber was kann er dagegen tun?)
Darzustellende Informationen:
Alle weiteren Daten sind redundant.
Darzustellende Informationen:
Darzustellende Informationen: