(Auf dieser Seite finden Sie technische Hinweise; für Fragen zu Ablauf, Sinn und Zweck konsultieren Sie die didaktischen Anmerkungen.)
Downloads - Das brauchen Sie für den Unterricht
Sie brauchen die Entwicklungsumgebung Greenfoot, die Sie hier downloaden können. Es gibt verschiedene Versionen, die USB- bzw. Java-only-Version läuft entspannt ohne Administratorrechte (nicht nur vom USB-Stick, sondern auch auf Schülerarbeitsplätzen).
Außerdem brauchen Sie den hus Struktogrammer (struktogrammer.ch). Anleitungen zum Start und Lösung des .jar-Problems in diesem Video. Sie können die Struktogramme natürlich auch mit einer anderen Software oder einem Online-Tool machen (wobei es structorizer.com seit Sommer 2022 (?) nicht mehr gibt).
Wenn Sie das Projekt in der Oberstufe des Beruflichen Gymnasiums Baden-Württemberg benutzen, brauchen Sie noch die Operatorenliste für Struktogramme (aktuell v 2.1 - PDF-Link auf schule-bw.de - Da sich die URLs dort schon mal ändern können, hier noch der Link auf die übergeordnete Seite).
Szenarien
Zu jeder Mission/Tutorial gibt es ein Greenfoot-Szenario. Das kann bei der entsprechenden Mission runtergeladen werden. Alle Szenarien bereits entzippt finden Sie im Verzeichnis UNTERRICHTSMATERIAL.zip (mehr zum Umgang mit diesem Verzeichnis in den didaktischen Anmerkungen).
Die Klasse Peetie
Die Schüler/innen arbeiten IMMER NUR in der Klasse Peetie, und zwar meistens nur in der run()-Methode (Ausnahme: Variablenverwendung, s.u.). Peetie ist die einzige Klasse, die Stride verwendet. Die anderen Klassen müssen nicht angefasst werden (auch nicht von Lehrer/innen).
In der Klasse Peetie steht oben eine kurze Anleitung, was zu tun ist.
Peetie kann in der run-Methode zahlreiche Befehle verwenden (die er i.d.R. von AI_Robot erbt, z.B. Dinge wie geheRechts oder istFelsVoraus). Da es so viele Szenarien gibt, haben wir es leider (noch?) nicht geschafft, Greenfoot eine API-Doc erzeugen zu lassen (was gar nicht schwer ist - Strg J und #schwupp; aber dazu muss die entsprechende Klasse gut kommentiert sein). Die zu verwendenden Befehle stehen aber meist (immer?) oben in der Klasse Peetie, werden in den Story-Videos angesprochen und dürften auch im Arbeitsauftrag/PDF vorhanden sein.
run() ist quasi der act()-Zyklus von peetie. In vielen Szenarien läuft Peeties run()-Methode nur einmal durch. Wir können also Peeties run()-Methode verwenden, als wäre es die act()-Methode.
Imperativ oder objektorientiert?
Greenfoot wurde ja quasi dafür gemacht, die Objektorientierung zu vermitteln (siehe z.B. unseren kompletten Video-Kursus OOP mit Greenfoot). In EFM verwenden wir Greenfoot aber nur deshalb, weil es uns die Möglichkeit gibt, die zu erlernenden Programmierstrukturen anschaulich-spielerisch umzusetzen (wie man weiß, haben wir es ja zuerst in Scratch probiert, das war aber eher nervig).
Deshalb programmieren wir Peetie nur imperativ - Wir verwenden nach Möglichkeit keine OOP-Aspekte wie Attribute oder Konstruktoren, sondern schreiben nur in der run()-Methode Abfolgen von Kontrollstrukturen.
Ausnahme sind die Variablen: Würden wir Variablen in Peeties run()-Methode deklarieren, würden sie dort bei jedem neuen Durchlauf neu deklariert (und damit auch initialisiert) werden. Das wäre in den Szenarien, bei denen die act-Methode durchläuft (und entsprechend Peeties run()-Methode mehrmals läuft), deadly, da die Variablen eben dauernd zurückgesetzt würden.
Also werden Variablen grundsätzlich als Attribute angelegt.
Nerd-Stuff
Hier ein paar Dinge, die eher ins Detail gehen:
Warum sind die Szenarien so kompliziert?
Die Szenarien sind etwas komplizierter als das, was man sonst so mit Schüler/innen in Greenfoot macht. Das hat folgende Gründe:
- Oft wollen wir die act-Methode nur einmal ausführen (z.B.: Peetie geht viermal nach rechts). Wir wollen aber auch ein paar Hilfsknöpfe haben (diese blauen kleinen Knöpfe im Szenario links unten, s.u.), um den Sound an- und abzuschalten oder einen Hilfetext erhalten zu können. Diese Knöpfe können nur "gelistent" werden, wenn das Szenario läuft (also der act-Zyklus).
- Manchmal wollen wir die act-Methode durchlaufen lassen (z.B. wenn die Drohnen Peetie angreifen). Das ist dann ein anderer Szenario-Typ als bei Punkt 1.
- Ärger macht auch die while-Schleife. Greenfoot hängt sich da gerne mal auf. Außerdem ist es nicht möglich, ein Szenario zu stoppen, BEVOR die while-Schleife komplett durchgelaufen ist. Deshalb gibt es für die Szenarien mit der while-Schleife eine zusätzliche Abbruchbedingung, die die Schüler/innen aber nicht sehen.
Szenario-interne Steuerung über Buttons
Die blauen Steuerungsknöpfe sind manchmal bestimmt hilfreich - man kann den Sound an-/abschalten, man kann einen Hilfetext aufrufen (den man mit der Taste R wieder zum Verschwinden bringt, sonst stürzt das Programm manchmal ab :-), man kann das Szenario nochmal neu starten (was man auch über die IDE-Buttons Reset/Run erreichen kann).
Allerdings funktionieren die nur, wenn Peetie mit seiner Arbeit fertig ist (soll heißen: wenn seine run-Methode durchgelaufen ist). Damit es hier keine Verwirrung gibt, sind die Knöpfe ausgeblendet, während Peetie arbeitet. Grundsätzlich fängt Peetie immer an zu arbeiten, sobald man das Szenario mit dem "Run"-Button gestartet hat, erst danach hat man die Möglichkeit, die Knöpfe zu bedienen.
Anders ist das bei den Szenarien, wo die act-Methode durchläuft (z.B. Drohnen-Angriffe). Da kann man bspw. den Sound die ganze Zeit an- und abschalten.
Sound
Um die Szenarien flexibler zu halten, gibt es eine Hilfsklasse Sound, die die Sounds verwaltet. Tipp: Wenn man den Sound per default abschalten will, muss man in dieser Klasse ungefähr in Zeile 26 das Attribut soundIsOn mit false initialisieren.
Sprache: Deutsch oder Englisch?
Wir haben überlegt, ob wir nicht alles auf Englisch machen, also Methoden, Attribute, Klassen, Dateinamen usw. (in der Klasse Sound, die relativ früh entstanden ist, ist das auch so). Wir haben uns (leider?) dagegen entschieden, weil in der Abiturprüfung voraussichtlich eher deutschsprachige Funktionen auftauchen (istBlattVoraus o.ä.).