Am Ende der 10. Klasse sollen die Schüler in Informatik an einem umfangreicheren Projekt möglichst selbstständig arbeiten. Dazu ist eigentlich keine Zeit, die meisten Informatiklehrer kommen so gerade mal über die Runden dieses Jahr – das erste Jahr mit Informatik in dieser Jahrgangsstufe. Aber für ein klitzekleines Projekt habe ich noch Zeit.

Selbst Wikipedia weiß wenig über die Geschichte des Spiels Stein, Schere, Papier. Ich stelle mir gerne vor, dass schon die alten Germanen so etwas spielten. Jedes Jahr wird die Weltmeisterschaft darin ausgetragen. Man gewinnt durch psychologische Einschätzung des Gegners; am seltensten wird dabei (mit 29,6%) die Schere gewählt. Eine echte Zufallsstrategie würde das Spiel zu einem reinen Glücksspiel werden lassen, aber der Mensch ist zur Erzeugung von Zufallsreihen nicht geeignet.

Meine zehnte Klasse soll sich ein Modell für so ein Turnier einfallen lassen und das dann in Java umsetzen. Allerdings sollen nicht Menschen gegeneinander spielen, sondern vorbereitete Strategien der Schüler (in Form von Java-Klassen). Die besseren Schüler erarbeiten die Infrastruktur des Turniers; wer sich weniger zutraut, soll nur eine Strategie ins Rennen schicken und kann eine Tafel Schokolade gewinnen.

Solch eine Strategie kann sein: „Ich spiele immer Stein.“ Oder: „Ich spiele abwechselnd Stein-Schere-Papier, immer in dieser Reihenfolge.“ Oder man macht die eigene Entscheidung von den vergangenen Entscheidungen des Gegners abhängig. Ich stelle mir das ganze so vor, und jetzt wird es leider technisch:

(Erklärung: # protected, -private, +public. Kursiv: abstract. Nach dem Doppelpunkt: Typ des Rückgabewerts bzw. des Attributs. Die Methode duellbestimmen(Duell) wird für die Verbindung mit anderen Klassen des Turniers gebraucht und ist hier nicht wichtig)

Zur Erläuterung des Diagramms: Es gibt eine Oberklasse Strategie mit den wichtigsten Methoden. Die Klasse ist abstrakt, es soll also gar keine Strategie-Objekte geben können. Vor allem ist die Methode entscheidungMitteilen() als abstrakt definiert. Das heißt, dass jede Unterklasse von Strategie dazu gezwungen wird, diese Methode selbst zu definieren.

Im einfachsten Fall sieht die zu programmierende Unterklasse so aus wie dieses Beispiel zur Ich-wähle-immer-Stein-Klasse:

public class Stein extends Strategie ( ) {
  //Attribute

  //Konstruktoren
  public Stein (String n) {
    super(n);
  }

  //Methoden
  public String entscheidungMitteilen ( ) {
    return "Stein";
  }
}

Die einzigen Bedingungen für die Schüler-Strategien: 1. Sie müssen im Konstruktor ihrer Klasse das Attribut name mit einem Wert versehen, so dass jedes Objekt ein eindeutiges Namen-Attribut erhalten kann. Das macht die Siegerehrung leichter. 2. Es muss natürlich die Methode entscheidungMitteilen() definiert werden, mit dem vorgegebenen Rückgabewert String. Erlaubt sind nur „Stein“, „Schere“ und „Papier“, aber eventuelle Fehler können die durchführenden Turnierklassen abfangen.

Zu klären ist noch die Spielweise. Ich will das Spiel möglichst einfach halten und schlage deshalb vor:

• Jede Strategie spielt einmal gegen jede andere.
• Ein Duell zwischen zwei Strategien dauert 100 Runden, also Entscheidungen. (Statt der üblichen, umständlicheren two out of three.)
• Der Gewinner einer Runde erhält 2 Punkte, der Verlierer 0, bei gleicher Entscheidung gibt es jeweils 1 Punkt.
• Reine Zufallsstrategien sind – aus Gründen – nicht erlaubt. (Vermutlich möchte ich auch Strategien ausschließen, die Zufall nur als ein Element im Algorithmus benutzen.) Lediglich ich als Lehrer schicke eine solche ins Rennen. Die Schüler sind sich noch uneins, ob das ein Vorteil für mich ist oder keiner. Das ist tatsächlich eine interessante Frage. Es ist keiner, hoffe ich.
• Wer am Schluss am meisten Punkte hat, gewinnt.

Ich will deshalb 100 Runden, damit kluge Strategie Zeit haben, die Entscheidungen weniger kluger Strategien zu analysieren und sich darauf einzustellen.

Die Methoden der übergeordneten Klasse Strategie werden natürlich an die Kind-Strategien weitervererbt. Die wichtigsten lauten:

• rundeErfragen() – in der wievielten Runde sind die Spieler gerade (Runde 0 bis 99, der Einfachkeit halber)
• rundenzahlErfragen() – wieviele Runden gibt es insgesamt (100, eigentlich überflüssig, aber so bleiben wir flexibel)
• punkteErfragen() – wieviel Punkte hat man selber im Moment

Und vor allem:

• entscheidungErfragen(int r) – wie hat man sich in Runde r entschieden (falls man mitzählen möchte)
• entscheidungGegnerErfragen(int r) – wie hat sich der Gegner in Runde r entschieden (falls man mitzählen möchte) – in beiden Fällen muss r natürlich kleiner sein als rundeErfragen()

Mit der letzten Methode kann man zum Beispiel ab Runde „1“ die Tit-for-tat-Strategie spielen, also immer die gleiche Entscheidung treffen wie der Gegner in der jeweils vorhergehenden Runde. Für Runde „0“ muss man sich noch etwas einfallen lassen:

public String entscheidungMitteilen() {
   return entscheidungGegnerErfragen(rundeErfragen()-1));
}

Ich schreibe das hier nur relativ skizzenhaft, weil es eh ein wenig technisch ist, und weil die Schüler sich das ja selber einfallen lassen sollen, statt hier abzuschreiben. Es kann also sein, dass die Methoden anders heißen werden, aber das lässt sich leicht anpassen. Zumindest irgendwelche Methoden dieser Art wird es geben.

Ich stelle das hier andererseits so ausführlich da für den Fall, dass hier jemand mitliest, der auch ein bisschen Java kann und Lust hat, selbst eine Strategie ins Rennen zu schicken. Der Gewinner kriegt eine Tafel Schokolade!

— Lose Gedanken zum Schluss:

1. Ja, ich habe mich bei diesem Projekt vom Gefangenendilemma inspirieren lassen.
2. Gerade bei konkurrierenden Strategien und gezählten Punkten ist das Prinzip der Datenkapselung wichtig. Sonst würde ja eine Strategie der anderen in die Entscheidungen pfuschen.
3. Fortgeschrittene Schüler können ein Syndikat gründen und solche Strategien entwickeln, die – etwa anhand der ersten 10 Entscheidungen – sich gegenseitig erkennen und jeweils einer davon danach alle Punkte zuschustern. Gibt sicher noch mehr raffinierte Einfälle.
4. Eine perfekte Strategie kann es demnach nicht geben, da der Erfolg jeder Strategie von der Zusammensetzung der Teilnehmer abhängt.
5. Den BlueJ-Ordner oder eine Jar-Datei maile ich auf Wunsch zu, falls jemand zu Hause damit herumspielen und eigene Strategien erproben will.

Nachtrag: Hier gibt es mein Stein-Schere-Papier interaktiv.