Also flugs die Farbe der Gegner per Zufallsfunktion steuern => fertig ist das prozedurale Spiel
Genau diese Gefahr sehe ich auch. Wenn schon, müßte es sich bei dem erzeugten Attribut (Name, Farbe etc) um ein tragendes Element handeln mit Konsequenzen für den weiteren Spielverlauf, z. B. das Monster X bekommt Y Stärkepunkte und Z Lebenspunkte. Rein optische Gimmicks würden nicht darunterfallen. Man stelle sich vor, jemand schreibt ein Weltraumspiel, in dem Millionen von Planeten erzeugt werden, die sich aber nur darin unterscheiden, daß ein Berg mal dort und dann mal drüben steht oder eine Pflanze mal grün, dann blau aussieht. Ein Superprozedurales Spiel, nur leider völlig öde weil sinnlos. Im Grunde genommen müßten prozedurale Elemente so etwas wie "Bedeutung" haben für das Spiel. Allerdings sobald der Begriff "Bedeutung" mit ins Spiel kommt, explodiert die Schwierigkeit einer Bewertung in einem unbeherrschbaren Ausmaß.
Procedural wäre eher was für Wettbewerbe mit starker Kilobyte-Einschränkung.
Was der Grund war für den Einsatz bei "Elite". Auf heutigen Rechnern hingegen wäre es völlig egal. Da könnte man alle Daten der Planeten komplett aus einer Datei lesen und in den Speicher packen. Daher wäre "Elite" nur Stufe 2.
Das wiederum führt dann gleich zu der Überlegung, daß man tatsächlich als Compo-Bedingung sogar Stufe 3 verlangen müßte: Es werden während des laufenden Spiels Objekte neu erzeugt, deren Zustand gespeichert wird, und die fortan einer weiteren Behandlung und Veränderung durch den Spieler unterliegen mit "Bedeutung" für den weiteren Spielverlauf. Solch ein Kriterium dürfte aber nicht nur für Programmieranfänger schwer einzuhalten sein.
Auch würden die Wettbewerbs- und Wertungenregeln noch komplexer als ohnehin schon werden, was ich den Ausrichtern gar nicht zusätzlich aufhalsen möchte.
Bislang wurde vermieden, interne Vorgehensweisen eines Programms öffentlich zu dokumentieren, da der Aufwand auf allen Seiten, Programmierer und Juroren, zu groß wäre, und dabei sollte man es besser belassen.