Bisher wurde ein Controller Framework vorgestellt und die Implementierung auch angeleitet. Die Implementierung war jedoch teilweise papierbasiert und diese Vorgehensweise insgesamt nicht sehr erfolgreich.<\/p>\n\n\n\n
Die Arbeitsschritte waren:<\/p>\n\n\n\n
- Erkl\u00e4rungen der Motivation, Vorgehensweise an der Tafel<\/li>
- Checklisten verteilen<\/li>
- die Abfolge der Spiellevel und der Ereignisse in einem Diagramm aufzeichnen<\/li>
- Anhand einer Beschreibung\/ Checkliste dann die Scripte f\u00fcr den Controller aufbauen<\/li><\/ul>\n\n\n\n
Diese manuelle Vorgehensweise war nicht sehr erfolgreich. Der Nutzen f\u00fcr die Entwicklung war nicht sofort ersichtlich und statt endlich mit dem Spiel loszulegen wollte niemand gerne erst mal auf Papier irgendwelche Bilder zeichnen. <\/p>\n\n\n\n
- die auf Papier erstellten Diagramme wurden nicht an die aktuellen Programm angepasst und konnten so zum Verst\u00e4ndnis des Spieles nicht herangezogen werden. Oder waren dann nicht mehr greifbar, vergessen, nicht abgeheftet.<\/li>
- Die Diagramme wurden im ersten Anlauf ‘zu sch\u00f6n’ gezeichnet mit Karopapier und Lineal. Dieser f\u00fcr erste Versionen \u00fcberfl\u00fcssige Aufwand ben\u00f6tigt viel Zeit und sch\u00f6ne Diagramme werden weniger bereitwillig ge\u00e4ndert. <\/li>
- die Diagramme mussten manuell in Skripte und Ereignisse \u00fcbertragen werden, hier gab es Tippfehler, Abweichungen bei gro\u00df-Kleinschreibung, Auslassungen.<\/li>
- Individuelle Abwandlungen der Controller-Skripte f\u00fchren zu einem hohen Aufwand bei der Unterst\u00fctzung der Sch\u00fcler.<\/li><\/ul>\n\n\n\n
Mit einem toolunterst\u00fctzten ‘Controller-Framework’ sollen diese Probleme vermieden werden. Insbesondere mu\u00df der Planungsschritt “Ablaufplanung” schnell und unkompliziert durchgef\u00fchrt werden k\u00f6nnen.<\/p>\n\n\n\n
F\u00fcr Sch\u00fcler wird das Framework altersgem\u00e4\u00df als Rezeptsammlung bereitgestellt. Nach einer Einf\u00fchrung soll es im Prinzip m\u00f6glich sein durch einfache \u00dcbernahme der generierten Skripte sehr schnell einen Fortschritt zu erzielen. Was dann – hoffentlich – die Motivation steigert das Framework zu benutzen.<\/p>\n\n\n\n
Das Framework soll die folgenden Features aufweisen:<\/p>\n\n\n\n
- Einzelne Level k\u00f6nnen separat gestartet werden w\u00e4hrend der Entwicklung und Test.
Das Durchlaufen komplexer Abl\u00e4ufe bis zu einem bestimmten Fehler wird vermieden. <\/li> - Supportaufwand wird durch Standardisierung verringert. <\/li>
- Die Ereignisse wie ‘gewonnen’, ‘verloren’ k\u00f6nnen simuliert werden und erlauben das einfache Verifizieren der Spielabl\u00e4ufe. <\/li>
- Eine Erweiterung des Spieles um zus\u00e4tzliche Level ist einfach m\u00f6glich.<\/li>
- Der Controller, ein Sprite mit dem Namen ‘Dirigent’, gibt Meldungen aus wenn ein neuer Level gestartet wird. Protokollierung kann ggf. einfach nachger\u00fcstet werden.<\/li><\/ul>\n\n\n\n
Mit der Umstellung des Kurses von scratch1.4 zu scratch3 in 2022 wird eine technische Unterst\u00fctzung mit einem grafischen Tool eingef\u00fchrt. Die Sch\u00fcler m\u00fcssen zwar im Moment weiterhin die generierten Skripte abtippen, aber durch die genaue Abbildung wird ein besseres Ergebnis erwartet.
Eine automatische Erstellung eines importf\u00e4higen Sprite ist noch nicht umgesetzt.<\/p>\n\n\n\nDer Post ist eine \u00dcberarbeitung eines fr\u00fcheren Artikels \u00fcber die Ablaufsteuerung: Auf die Pl\u00e4tze, fertig, los !<\/a><\/p>\n\n\n\n
Bestandteile des Framework<\/h2>\n\n\n\n
Das Framework implementiert eine Controller Pattern bestehend aus einer Zustandmaschine f\u00fcr die Abl\u00e4ufe und Interfaces\/ Templates f\u00fcr Ereignisse im Spielablauf.<\/p>\n\n\n\n
Ein zentrale Controller Komponente implementiert als scratch Sprite ist nur f\u00fcr den \u00fcbergeordneten Spielablauf zust\u00e4ndig.<\/p>\n\n\n\n
Alle Sprite erhalten standardisierte Ereignisse f\u00fcr die Ablaufsteuerung.<\/p>\n\n\n\n
![\"\"](\"http:\/\/heppg.de\/ikg\/wordpress\/wp-content\/uploads\/2023\/04\/ikg_screenflow_2_model-1.png\")
<\/a>UML Diagramm f\u00fcr die Messages zwischen Dirigent und einem Sprite f\u00fcr einen Level ‘Level_1’<\/figcaption><\/figure>\n\n\n\n <\/p>\n\n\n\n
Die Ablaufdiagramme sind grafisch vereinfachte UML StateMachineDiagram. <\/p>\n\n\n\n
![\"\"](\"http:\/\/heppg.de\/ikg\/wordpress\/wp-content\/uploads\/2023\/04\/dirigent_state-1024x431.png\")
<\/a><\/figure>\n\n\n\nDie Zust\u00e4nde haben links die ‘Entry’-Port, rechts die ‘Exit’-Port so dass die Pfeile an den Events entfallen k\u00f6nnen. <\/p>\n\n\n\n
Entry-Aktionen werden in zwei Phasen ‘fertig’ und ‘los’ aufgeteilt und \u00fcber Messages, scratch-Ereignisse angesteuert.<\/p>\n\n\n\n
Werkzeuge, Toolunterst\u00fctzung<\/h2>\n\n\n\n
Das Tool besteht aus einem grafischen Editor f\u00fcr Spielabl\u00e4ufe und der M\u00f6glichkeit daraus den Sprite-Skript-Code zu generieren sowie die Templates f\u00fcr die Ereignisse der Sprite-Spielfiguren.<\/p>\n\n\n\n
Es wurde wenig Aufwand in eine ‘smarte’ Oberfl\u00e4che investiert:<\/p>\n\n\n\n
![\"\"](\"http:\/\/heppg.de\/ikg\/wordpress\/wp-content\/uploads\/2023\/04\/dirigent_simple.screenflow-1024x338.png\")
<\/a><\/figure>\n\n\n\nBedienoberfl\u00e4che des Editor.<\/p>\n\n\n\n
Technisch gesehen l\u00e4uft das Tool im Browser, es wird eine javascript-Bibliothek draw-2d verwendet.
Aus einer einfachen Palette werden die Elemente auf die Arbeitsfl\u00e4che gezogen. Die Verbindungen werden mit der Maus erstellt.<\/p>\n\n\n\nUndo, Redo werden unterst\u00fctzt. Alle Ver\u00e4nderungen werden in einer lokalen Datenbank persistiert. Mit “Store” werden Ergebisse gespeichert und die bis dahin angefallen Zwischenst\u00e4nde dann gel\u00f6scht.<\/p>\n\n\n\n
‘Print’ speichert die Grafik als svg-Datei auf dem Rechner. “skript:dirigent” und “skript:sprite” aktivieren den Generator und die grafische Ausgabe der Skripte. Bisher mu\u00df dann manuell abgetippt werden. F\u00fcr das gezeigte Beispiel sind das im ‘Dirigent’ etwa 50 Bl\u00f6cke.<\/p>\n\n\n\n
Die Server-Komponente ist in python mit ‘tornado’ implementiert, ‘sqlite3’ \u00fcbernimmt die lokale Speicherung.
Die Generierung der Grafiken erzeugt SVG in Webseiten, hier ein Beispiel f\u00fcr die Ausgabe des “skript:dirigent”:<\/p>\n\n\n\n![\"\"](\"http:\/\/heppg.de\/ikg\/wordpress\/wp-content\/uploads\/2023\/04\/dirigent_simple.dirigent.png\")
<\/a>Anzeige des generierten Dirigent-scratch-Skript<\/figcaption><\/figure>\n\n\n\n Die Anzeige der Skripte lehnt sich an die aus scratch3 bekannten Formen und Farben an; die schwarze Schrift ist eine Abweichung von der Pastelloptik und besser lesbar.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Das Controller-Framework hat als zentrale Komponente ein scratch-Sprite mit dem Namen ‘Dirigent’. Das ist der ‘Controller’ des Spiels.
Technisch gesehen implementiert der Controller einen Zustandsautomaten, die Level sind die Zust\u00e4nde und die \u00dcberg\u00e4nge werden \u00fcber Ereignisse gesteuert. GesStartet \u00fcber die gr\u00fcne Flagge.<\/p>\n\n\n\nDie einzelnen Sprites in Scratch (Spielfiguren) erhalten eine standardisierte Schnittstelle aus Ereignissen (Messages).<\/p>\n\n\n\n
LEVEL_1_fertig<\/strong>: Dirigent zu Sprites. Setze die Startwerte f\u00fcr den Level wie:
– zeige dich \/ verstecke dich
– Gr\u00f6\u00dfe
– Position
– Variablen<\/p>\n\n\n\nLEVEL_1_los<\/strong>: Dirigent zu Sprites. Hier geht es los. Die Abl\u00e4ufe werden gestarten, Bewegungen aktiviert etc.<\/p>\n\n\n\n
LEVEL_1_stop<\/strong>: Dirigent zu Sprite. Der level ist beendet, beende Aktionen des Sprite. Stoppe Schleifen.<\/p>\n\n\n\n
gewonnen, verloren, weiter<\/strong> o.\u00e4.: Sprite zu Dirigent. Damit wird der \u00dcbergang zu einem neuen Level gestartet. Hier k\u00f6nnen die Sch\u00fcler (fast) beliebige Namen verwenden.<\/p>\n\n\n\n
In den Beispielen werden die Level in Gro\u00dfbuchstaben geschrieben. Das erleichtert die \u00dcbersicht.<\/p>\n\n\n\n
![\"\"](\"http:\/\/heppg.de\/ikg\/wordpress\/wp-content\/uploads\/2023\/04\/dirigent.sprite-1024x569.png\")
<\/a>Aus dem Ablaufdiagramm erzeugte Scratch-Snippet f\u00fcr ein Sprite.<\/figcaption><\/figure>\n\n\n\n Die Sch\u00fcler f\u00fcllen – statt den Kommentaren – ihre eigenen Abl\u00e4ufe ein.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Spezialfall ‘wiederverwendbarer Level’<\/h2>\n\n\n\n
In den von Sch\u00fclern gezeichneten Ablaufdiagrammen tauchen regelm\u00e4ssig Level auf, die wie ein Unterprogramm an verschiedenen Stellen verwendet wurden. Beispiele sind ein Zwischenlevel ‘der level wurde gewonnen, weiter mit dem n\u00e4chsten Level oder beenden ?’<\/p>\n\n\n\n
Bisher mussten solche Anforderungen durch spezifische (unique) Level gel\u00f6st werden oder die Programmierung wurde ad hoc erg\u00e4nzt.<\/p>\n\n\n\n
Das Tooling unterst\u00fctzt diesen Sonderfall. <\/p>\n\n\n\n
<\/p>\n\n\n\n
![\"\"](\"http:\/\/heppg.de\/ikg\/wordpress\/wp-content\/uploads\/2023\/04\/dirigent_komplex.flow_-1024x333.png\")
<\/a>Komplexes Beispiel mit Zwischenlevel ‘X’<\/figcaption><\/figure>\n\n\n\n Die Skripte des ‘Dirigent’ sind sehr \u00e4hnlich wie des einfachen Beispiels, lediglich an den Stellen wo die Zwischenlevel eingef\u00fcgt sind wird eine weitere Variable ‘p_level’ verwendet.<\/p>\n\n\n\n
![\"\"](\"http:\/\/heppg.de\/ikg\/wordpress\/wp-content\/uploads\/2023\/04\/dirigent_komplex.eventhandling.png\")
<\/a><\/figure>\n\n\n\n![\"\"](\"http:\/\/heppg.de\/ikg\/wordpress\/wp-content\/uploads\/2023\/04\/dirigent_komplex.eventhandling2.png\")
<\/a>Sprite ‘Dirigent’, Beispiele f\u00fcr das Verarbeiten von Ereignissen mit ‘ZwischenLevel’.<\/figcaption><\/figure>\n","protected":false},"excerpt":{"rendered":" Mit einem toolgest\u00fctzten Controller Framework f\u00fcr scratch3-Spiele soll die Entwicklung von Spielen mit scratch vereinfacht werden. Die Ablaufsteuerung eines Scratch-Spieles mit verschiedenen Spielleveln macht Sch\u00fclern der siebten Klasse einige Probleme: Das Spiel kann einmal gespielt werden, beim zweiten Durchlauf erscheinen die Figuren an unerwarteten Stellen. Um Fehler zu suchen mu\u00df das Spiel jedesmal vom Anfang […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,6],"tags":[31],"class_list":["post-1118","post","type-post","status-publish","format-standard","hentry","category-scratch","category-tools","tag-scratch"],"_links":{"self":[{"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/1118","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1118"}],"version-history":[{"count":7,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/1118\/revisions"}],"predecessor-version":[{"id":1135,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/1118\/revisions\/1135"}],"wp:attachment":[{"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1118"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1118"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1118"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Einzelne Level k\u00f6nnen separat gestartet werden w\u00e4hrend der Entwicklung und Test.