MMProg: Praktikum: WiSe 2017/18: Ball03: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „{{MMProg:Praktikum:WiSe 2017/18:Menü}} '''Musterlösung''': [https://glossar.hs-augsburg.de/beispiel/tutorium/es6/ball/WK_Ball03/ SVN-Repository] ==Ziel==…“) |
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 9: | Zeile 9: | ||
* Das Prinzip „[[Don't repeat yourself]]“ (DRY) wird unterstützt. Um dies zu erreichen, muss sichergestellt werden, dass viele Module in diversen Projekten [[Wiederverwendbarkeit |wiederverwendet]] werden können.<ref>[[Programmierprinzipien]]</ref><ref>[[Qualität]]</ref> | * Das Prinzip „[[Don't repeat yourself]]“ (DRY) wird unterstützt. Um dies zu erreichen, muss sichergestellt werden, dass viele Module in diversen Projekten [[Wiederverwendbarkeit |wiederverwendet]] werden können.<ref>[[Programmierprinzipien]]</ref><ref>[[Qualität]]</ref> | ||
* Mehrere Programmierer können gleichzeitig an einem Projekt arbeiten. Hier muss sichergestellt sein, dass möglichst saubere Schnittstellen definiert werden, damit ein Programmierer nicht ständig an die Änderungen eines anderen Programmierers anpassen muss. (Die Definition von Schnittstellen ist eine der Kernaufgaben von Informatikern. | * Mehrere Programmierer können gleichzeitig an einem Projekt arbeiten. Hier muss sichergestellt sein, dass möglichst saubere Schnittstellen definiert werden, damit ein Programmierer nicht ständig an die Änderungen eines anderen Programmierers anpassen muss. (Die Definition von Schnittstellen ist eine der Kernaufgaben von Informatikern. Dabei handelt es sich um einen kreativen Prozess. Der Programmierer hingegen braucht „lediglich“ die Spezifikation umzusetzen. Das ist {{iAllg}} deutliche weniger kreativ.) | ||
Dabei handelt es sich um einen kreativen Prozess. Der Programmierer hingegen braucht „lediglich“ die Spezifikation umzusetzen. Das ist {{iAllg}} deutliche weniger kreativ.) | |||
* Jede Änderung an einem vorhandenen Code kann Fehler zur Fogle haben. Daher ist es von Vorteil, wenn ausgetestete, wiederverwendbare Module bestehen. Bei der Fehlersuche befindet sich der Code {{iAllg}} nicht in einem dieser Module, sondern im neu erstellten Code. Das vereinfacht die Fehlersuche deutlich. | * Jede Änderung an einem vorhandenen Code kann Fehler zur Fogle haben. Daher ist es von Vorteil, wenn ausgetestete, wiederverwendbare Module bestehen. Bei der Fehlersuche befindet sich der Code {{iAllg}} nicht in einem dieser Module, sondern im neu erstellten Code. Das vereinfacht die Fehlersuche deutlich. | ||
| Zeile 32: | Zeile 31: | ||
Schreiben Sie Ihre Lösungen der Aufgabe $i$ in die Ordner <code>game</code>$i$<code>.js</code>. | Schreiben Sie Ihre Lösungen der Aufgabe $i$ in die Ordner <code>game</code>$i$<code>.js</code>. | ||
Versuchen Sie möglichst viele Module der jeweils vorangegangenen Aufgabe wiederzuverwenden. | |||
===Aufgabe 0=== | |||
Es gibt in <code>WK_Ball03_empty</code> eine <code>app0</code> mit zugehörigem Modul <code>game0</code>. | |||
Dabei handelt es sich um eine App, die im Sinne des zweiten Teils des Tutoriums erstellt wurde. | |||
Sehen Sie sich zunächst diese App an und analysieren Sie, wie diese funktioniert. | |||
Beachten Sie insbesondere Folgedes: | |||
* Es wird ein Ball-Modell erzeugt, mit Attributen „Radius“, „Position“, „Geschwindigkeit“ und „Beschleunigung“. | |||
* Dieser Ball wird durch einen einfarbigen Kreis mit Rand visualisiert. | |||
* Der Ball bewegt sich gemäß seinen Initialparametern schräg über die Bühne, wobei seine Geschwindigkeit stetig zunimmt. | |||
* Bei einer Kollission mit dem Bühnenrand ändert er seine Bewegungsrichtung. | |||
Die gesamte beschriebene Spiellogik ist in einer Datei enthalten: <code>game0.js</code>. So eine Datei bezeichne ich als '''Moloch'''. | |||
Das Prinzip „Implementiere keinen Moloch“ nennt man fachsprachlich „[[Modularisierung]]“. | |||
Beachten Sie, dass das Programm gar nicht so molochartig ist, wie es zunächst scheint. Es kommen schon einige | |||
Module zum Einsatz: | |||
* <code>index.html</code>: Eine HTML-Seite zum Starten der eigentlichen Web-Anwendung, sobald sie vom Browser geladen wird. | |||
* <code>app.scss</code>: Eine SCSS-Datei, die das Layout der HTML-Datei festlegt (insbesondere die Hintergrundfarbe). | |||
* <code>pixi.js</code>: Eine sehr mächtige 2D-Grafik-Bibliothek, die sehr modular aufgebaut ist. | |||
* <code>GameLoopPixi</code>: Eine Game-Loop-Klasse, die Ihnen im Rahmen des Praktikums zur Verfügung gestellt wird. Diese Modul benutzt seinerseits das Hilfsmodul <code>EventDispatcher</code>. | |||
* <code>app0.js</code>: Das Hauptmodul. Es stellt mit Hilfe der zuvor genannten Module die Spielumgebung zur Verfügung: Eine PIXI-Bühne, eine Gameloop sowie eine CSS-Datei. Sobald die Umgebung erstellt und initialisiert wurde, startet diese Modul das eigentliche Spielmodul <code>game0.js</code>. | |||
* <code>app0.js</code>: Das immer noch molochartige Spielmodul, das im Rahmen des Praktikums in diverse Einzelmodule aufgeteilt werden wird. | |||
===Aufgabe 1=== | ===Aufgabe 1=== | ||
Version vom 16. November 2017, 11:35 Uhr
Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:
| Korrektheit: 3 (zu größeren Teilen überprüft) |
Umfang: 4 (unwichtige Fakten fehlen) |
Quellenangaben: 3 (wichtige Quellen vorhanden) |
Quellenarten: 5 (ausgezeichnet) |
Konformität: 3 (gut) |
Inhalt | Game Loop 01 | Ball 02 | Ball 03 | Ball 03b | Pong 01
Musterlösung: SVN-Repository
Ziel
Ziel dieser Praktikumsaufgabe ist es, Lösungen des zweiten Teils des Tutoriums zu modularisieren. Die Modularisierung hat mehrere Vorteile:
- Das Prinzip „Don't repeat yourself“ (DRY) wird unterstützt. Um dies zu erreichen, muss sichergestellt werden, dass viele Module in diversen Projekten wiederverwendet werden können.[1][2]
- Mehrere Programmierer können gleichzeitig an einem Projekt arbeiten. Hier muss sichergestellt sein, dass möglichst saubere Schnittstellen definiert werden, damit ein Programmierer nicht ständig an die Änderungen eines anderen Programmierers anpassen muss. (Die Definition von Schnittstellen ist eine der Kernaufgaben von Informatikern. Dabei handelt es sich um einen kreativen Prozess. Der Programmierer hingegen braucht „lediglich“ die Spezifikation umzusetzen. Das ist i. Allg. deutliche weniger kreativ.)
- Jede Änderung an einem vorhandenen Code kann Fehler zur Fogle haben. Daher ist es von Vorteil, wenn ausgetestete, wiederverwendbare Module bestehen. Bei der Fehlersuche befindet sich der Code i. Allg. nicht in einem dieser Module, sondern im neu erstellten Code. Das vereinfacht die Fehlersuche deutlich.
Aufgaben
Laden Sie das leere Projekt WK_Ball03_empty auf Ihren Rechner.
Installieren Sie aber nicht die Node.js-Module, das machen Sie später. Sie finden das leere Projekt im
Repository-Pfad https://glossar.hs-augsburg.de/beispiel/tutorium/es6 im Unterordner empty.
Erstellen Sie ein neues Projekt praktikum03 und kopieren Sie die Ordner src und web (samt Inhalt)
sowie alle Dateien, die Sie im Wurzelverzeichnis des Projektes WK_Ball03_Empty
finden, mittels Crtl-/Apfel-C Crtl-/Apfel-V in Ihr eigenes Projekt. (Die Frage, ob WebStorm seinen eigenen File Watcher zum
Übersetzen von ES6-Code in ES5-Code verwenden soll, beantworten Sie bitte mit „No“. Das erledigt Webpack für Sie.)
Nun können Sie in Ihrem eigenen Projekt die benötigten Node.js-Module installieren: npm i.
Sie können Ihr Projekt zur Übung auch im Subversion-Repository speichern. Das ist aber nicht so wichtig.
In Ihrem Projekt finden Sie wiederum mehrere Web-Anwendungen: index01.html verwendet die gepackte Version von app01.js,
die ihrerseits das Spiel game01/game.js einbindet. Et cetera.
Schreiben Sie Ihre Lösungen der Aufgabe $i$ in die Ordner game$i$.js.
Versuchen Sie möglichst viele Module der jeweils vorangegangenen Aufgabe wiederzuverwenden.
Aufgabe 0
Es gibt in WK_Ball03_empty eine app0 mit zugehörigem Modul game0.
Dabei handelt es sich um eine App, die im Sinne des zweiten Teils des Tutoriums erstellt wurde.
Sehen Sie sich zunächst diese App an und analysieren Sie, wie diese funktioniert.
Beachten Sie insbesondere Folgedes:
- Es wird ein Ball-Modell erzeugt, mit Attributen „Radius“, „Position“, „Geschwindigkeit“ und „Beschleunigung“.
- Dieser Ball wird durch einen einfarbigen Kreis mit Rand visualisiert.
- Der Ball bewegt sich gemäß seinen Initialparametern schräg über die Bühne, wobei seine Geschwindigkeit stetig zunimmt.
- Bei einer Kollission mit dem Bühnenrand ändert er seine Bewegungsrichtung.
Die gesamte beschriebene Spiellogik ist in einer Datei enthalten: game0.js. So eine Datei bezeichne ich als Moloch.
Das Prinzip „Implementiere keinen Moloch“ nennt man fachsprachlich „Modularisierung“.
Beachten Sie, dass das Programm gar nicht so molochartig ist, wie es zunächst scheint. Es kommen schon einige Module zum Einsatz:
index.html: Eine HTML-Seite zum Starten der eigentlichen Web-Anwendung, sobald sie vom Browser geladen wird.app.scss: Eine SCSS-Datei, die das Layout der HTML-Datei festlegt (insbesondere die Hintergrundfarbe).pixi.js: Eine sehr mächtige 2D-Grafik-Bibliothek, die sehr modular aufgebaut ist.GameLoopPixi: Eine Game-Loop-Klasse, die Ihnen im Rahmen des Praktikums zur Verfügung gestellt wird. Diese Modul benutzt seinerseits das HilfsmodulEventDispatcher.app0.js: Das Hauptmodul. Es stellt mit Hilfe der zuvor genannten Module die Spielumgebung zur Verfügung: Eine PIXI-Bühne, eine Gameloop sowie eine CSS-Datei. Sobald die Umgebung erstellt und initialisiert wurde, startet diese Modul das eigentliche Spielmodulgame0.js.app0.js: Das immer noch molochartige Spielmodul, das im Rahmen des Praktikums in diverse Einzelmodule aufgeteilt werden wird.
Aufgabe 1
Quellen
- Kowarschick (MMProg): Wolfgang Kowarschick; Vorlesung „Multimedia-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 3 (Vorlesung)
