HTML5-Tutorium: Canvas: MiniPong 04
Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:
Korrektheit: 3 (zu größeren Teilen überprüft) |
Umfang: 3 (einige wichtige Fakten fehlen) |
Quellenangaben: 5 (vollständig vorhanden) |
Quellenarten: 5 (ausgezeichnet) |
Konformität: 5 (ausgezeichnet) |
HTML-Tutorium: MiniPong
MiniPong: | Teil 1 | Teil 2 | Teil 3 | Teil 4 | Teil 5
Musterlösung: index.html
(WK_MiniPong04 (SVN))
Leeres Projekt: index.html
(WK_MiniPong04_empty (SVN))
Ziel: Das fertige Spiel „MiniPong“
Im vierten Teil des Tutoriums wird eine funktionsfähige Version von MiniPong erstellt.
Use Cases
Ein Spieler kann das Spiel starten (Startknopf) und vorzeitig beenden (Stopp-Knopf). Nach Spielstart kann der Spieler den Schläger am unteren Rand des Spielfeldes mit Hilfe der Richtungstasten des Keyboards nach links und rechts bewegen.
Nachdem das Spiel gestartet wurde, bewegt sich der Ball geradlinig im Spielfeld, wobei die Startrichtung zufällig gewählt wird. Kollisionen mit der linken, oberen oder rechten Wand haben eine Richtungsänderung des Balls zur Folge (Einfallswinkel = Ausfallwinkel). Eine Kollision mit der unteren Wand beendet das Spiel.
Ziel des Spiels sind möglichst viele Kollision des Balls mit dem Schläger. Eine derartige Kollision hat eine Richtungsänderung sowie einen Punktgewinn zur Folge. Der aktuelle Punktestand (Score) wird der Benutzer jederzeit angezeigt.
Wird der Schläger im Moment der Kollision bewegt, so wird der Ball abhängig von der Bewegungsrichtung und Geschwindigkeit des Schlägers abgelenkt (Simulation von Reibung).
Klassenmodell
Eine genauere Analyse der Use Cases zeigt, welche Module benötigt werden. Die verschiedenen Module sind verschieden eingefärbt:
- grau: Initialisierung der Anwendung
- blau: Model der Anwendung
- orange: Controller zur Behandlung der Benutzeraktionen (mit Ausnahme von Formularelementen, die in der View enthalten sind)
- flieder: Anwendungslogik
- grün: Anwendungsview
- gelb: Kollisionserkennung und -behandlung
Die Kollisionserkennung und -behandlung erhält eine eigene Farbe, da sie eine Mischung aus Model und Controller ist. Einerseits verändert sie die Bewegungseigenschaften beweglicher Objekte (Ball und Schläger). Das heißt, sie ist wesentlicher Bestandteil des Models. Andererseits informiert sie die Anwendung über Aktionen des Balls, damit diese entsprechend reagieren kann. Dies ist eine typische Controllertätigkeit.
Das Modul „init
“ hat die Aufgabe das Spiel zu initialisieren. Es definiert eine Prozedur
„init
“, die zunächst die wesentlichen Objekte erstellt und dann das Spiel startet.
Im Klassendiagramm sind rote Pfeile zu den Modulen eingezeichnet, die das Init-Modul benötigt.
Das sind die beiden Funktionsmodule „logic/minipong
“ und „control/keyboard
“
sowie diverse Model- und View-Klassen. Für jede dieser Klassen – mit Ausnahme der Klasse „ModelStage
“ –
erzeugt init
ein oder im Falle der Text-Klassen sogar jeweils zwei Objekte. Als Stage-Objekt kommt
– wie im dritten Teil des Tutoriums – das in der HTML-Datei enthaltene
Canvas-Element zum Einsatz.
Die View-Objekte sind ausschließlich der Prozedur „init
“ bekannt. Diese Objekte visualisieren
die Model-Objekte, d. h. den aktuellen Zustand des Spiels. Da sich der Zustand des Spiel häufig ändert,
erstellt init
eine View-Loop, deren Aufgabe es ist, die Visualisierung möglichst häufig,
am Besten 60 mal pro Sekunde zu erneuern. Dazu ruft die View-Loop, sobald sie einmal gestartet wurde,
regelmäßig die Zeichenmethode „draw
“ der einzelnen View-Objekte auf.
Die View umfasst sechs Elemente:
- einen Button (Start, Stopp)
- einen Ball
- einen Schläger
- zwei Textfelder (Score und allgemeine Informationen)
Die View-Loop muss diese sechs Objekte selbstverständlich kennen, damit sie sie darstellen kann. Allerdings
reicht es, wenn ihr eine Liste von View-Objekten übergeben wird. Die einzige Forderung, die die die View-Loop
an diese Objekte stellt, ist, dass für sie eine Zeichenmethode „draw(p_context)
“ defiert wurde,
mittels derer sie die Objekte auf dem Canvas (oder evtl. auch im HTML-Dokument selbst) visualisieren kann.
Das heißt, die View-Klassen, deren Objekte von der View-Loop visualisiert werden sollen, müssen das
Interface „View
“ implementieren.
Die Init-Prozedur erzeugt die sechs View-Objekte sowie die zugehörigen Model-Objekte, ordnet den View-Objekten die entsprechenden Model-Objekte zu und übergibt dann ein Array mit allen View-Objekten der View-Loop. Sobald diese gestartet wird, aktualisiert sie regelmäßig die grafische Darstellung dieser Objekte im HTML-Dokument.
Die Init-Prozedur lädt ein weiteres Modul: „control/keyboard
“. Diese fängt alle Tastaturereignisse ab.
Sobald auf der Tastatur eine entsprechende Taste gedrückt wird, ruft sie sie Methode „start
“ des Schlägers
(d. h. eines Objektes der Klasse „ModelPaddle
“) auf und setzt ihn in Bewegung.
Welcher Taste welche Bewegungsrichtung zugeordnet ist, wird in der Init-Datei „init.json
“ festgelegt.
Danach wird das eigentlich Spiel gestartet. Die Spiellogik wird in der Prozedur „minipong
“ implementiert.
Diese Prozedur muss die Model-Objekte des Spiels kennen, da sie deren Werte liest und in bestimmten Situationen verändert.
Jede Änderung einen Model-Objekts, dem ein View-Objekt zugeordnet ist, wird fast sofort (genau gesagt, bei der nächsten Ausführung
der View-Loop) visualisiert. Da dies automatisch geschieht, muss die Prozedur „minipong
“ nichts weiter machen,
als beispielsweise den Text innerhalb eines Text-Objekts der Klasse „ModelText
“ oder die Beschriftung des Buttons
innerhalb des Objekts der Klasse „ModelButton
“ zu ändern. Sobald dies geschehen ist, wird die Änderung im HTML-Dokument
automatisch übernommen.
Die Spiellogik hat zwei wichtige Aufgaben:
- Simulation der Ball/Schläger-Physik
- Reaktion auf Ereignisse wie Aktivierung des Start-Buttons (Spielstart), Kollision des Schlägers mit dem Ball (Punktgewinn), Verlust des Balles am unteren Bühnenrand (Spielende) etc.
Für die erste Aufgabe verwendet sie eine Model-Loop, die alle beweglichen Objekte, d. h. alle Model-Objekte, die über die Methode
„move
“ verfügen, möglichst oft pro Sekunde mittels dieser Methode an eine neue Position verschiebt.
Das nebenstehende Diagramm zeigt abermals eine Detailansicht des Klassendiagramm, in dem alle für die ModelLoop notwendigen
Beziehungen eingetragen wurde. Auch hier gilt: Im Übersichtsdiagramm wurden die Beziehungspfeile, die im nebenstehenden Diagramm blau markiert wurden,
aus Gründen der Übersichtlichkeit nicht eingetragen.
Die Model-Loop wird nicht von der Init-Prozedur, sondern von der Prozedur „minipong
“ erzeugt.
Die Init-Prozedur benötigt dieses Objekt nicht. Die MiniPong-Prozedur benötigt es dagegen nicht nur, sondern muss es auch
gemäß ihren Bedürfnissen initialisieren: Der ModelLoop muss eine spezielle Kollisionsfunktion übergeben werden.
Die zweite Aufgabe „Reaktion auf Ereignisse“ zerfällt in zwei Aufgaben.
- Reaktion auf Aktionen des Benutzers.
- Reaktion auf Aktionen des Balls.
Für die Model-Loop gilt diesselbe Aussage wie für die View-Loop: Es ist gleichgültig, um welche Art von Model-Objekte es sich handelt.
Es muss nur sichergestellt sein, dass sie das Interface „Movable
“ implementieren. Das heißt, sie müssen
eine Methode „move(p_seconds)
“ bestzen. Model-Objekte, für die dies nicht gilt, können ihre Position nicht
kontinuierlich ändern und werden daher der Model-Loop auch nicht zur Behandlung übergeben.
In diesem Spiel gibt es nur eine Benutzeraktion, auf die minipong
direkt reagieren muss: „Klick auf den Start-Stopp-Button“ .
Die zweite Aktion „Bewegung des Schlägers“ wird vom Keyboard-Controller direkt an den Schläger weitergeleitet.
Für die Aktion „Button-Klick“ muss minipong
dem Button in jedem der beiden Spielzustände „Spiel gestoppt“ und „Spiel gestartet“
eine geeignete Callback-Funktion zuweisen, die die jeweils passende Aktion ausführt. Im Fall „Spiel gestoppt“ muss der Button-Klick das
Spiel starten und im Fall „Spiel gestartet“ muss er das Spiel beenden.
Der Ball kann zwei weitere Aktionen ausführen. Er kann mit dem Schläger kollidieren oder das Spielfeld verlassen. Beide Aktionen werden von
der Kollisionsbehandlung erkannt. Jedes mal, wenn eine wenn der Ball eine dieser beiden Aktionen durchführt
muss die Prozedur „minipong
“ darüber informiert werden, damit sie entsprechend reagieren kann.
Hierzu definiert sie mit Hilfe der drei Hilfs-Prozeduren „collisionBallPaddle
“, „collisionBallPaddle
“
und „collisionStagePaddle
“ eine geeignete Kollissionsprozedur, die sie der Model-Loop zur Kollisionserkennung und
-behandlung übergibt.
Neues Projekt anlegen
Legen Sie ein neues Projekt mit dem Namen „MiniPong04
“ an.
Erstellen Sie folgende Ordner:
web
web/css
web/json
web/js
web/js/lib
web/js/lib/require
web/js/app
web/js/app/collision
web/js/app/control
web/js/app/logic
web/js/app/model
web/js/app/view
Kopieren Sie folgende Dateien des Projektes MiniPong03 in das neue Projekt:
web/index.html
(Ersetzen Sie im Titel „MiniPong03
“ durch „MiniPong04
“ und ersetzen Sie im Copyright-Kommentar meinen Namen durch Ihren Namen.)web/css/main.css
web/js/lib/require/json.js
web/js/lib/require/require.js
web/js/lib/require/text.js
Fügen Sie in die Datei „index.html
“ hinter dem Canvas-Element ein Button-Element ein:
<form>
<button id="button_start_stop" type="button"></button>
</form>
Erstellen Sie die Datei „web/js/main.js
“ und fügen Sie folgenden Code ein:
requirejs.config
({
baseUrl: 'js', // By default load any modules from directory js
paths :
{
app: 'app',
model: 'app/model',
view: 'app/view',
control: 'app/control',
logic: 'app/logic',
collision: 'app/collision',
loadjson: 'lib/require/json',
text: 'lib/require/text',
json: '../json'
}
});
requirejs
( ['loadjson!json/init.json', 'app/init'],
function(initJSON, init)
{
//init(window, initJSON);
}
);
Für jedes Modulpaket wurden ein Ordner angelegt und eine Kurzbezeichnung des Modulpfades festgelegt:
Farbe | Ordner | Modulpfad | Modulzweck |
---|---|---|---|
grau | js/app
|
app
|
Initialisierung der Anwendung |
blau | web/js/app/model
|
model
|
Model der Anwendung |
grün | web/js/app/view
|
view
|
Anwendungsview |
orange | web/js/app/controller
|
controller
|
Controller zur Behandlung der Benutzeraktionen |
flieder | web/js/app/logic
|
logic
|
Anwendungslogik |
gelb | web/js/app/collision
|
collision
|
Kollisionserkennung und -behandlung |
Erstellen Sie für jedes Modul, das im Klassendiagramm aufgeführt ist (mit Ausnahme von ModelStage
), eine leere Datei
in der dieses Modul implementiert wird. Achten Sie darauf, dass die Farbmarkierung der Module mit den Farbmarkierungen
der Modulordner übereinstimmt:
web/js/app
init.js
web/js/app/model
button.js
ball.js
paddle.js
text.js
loop.js
web/js/app/view
button.js
ball.js
paddle.js
text.js
loop.js
web/js/app/control
keyboard.js
web/js/app/logic
minipong.js
web/js/app/collision
ball_paddle.js
stage_ball.js
stage_paddle.js
Fügen Sie in jede Datei ein RequireJS-Kommando ein, das dafür sorgt, dass die benötigten Module geladen und die darin definierten Funktionen (d. h. Prozeduren bzw. Konstruktorfunktionen) dem Modul zur Verfügung gestellt werden. Welche Module ein Modul benötigt, erkennt man an den roten Pfeilen im Klassendiagramm.
Von den meisten Module geht kein roter Pfeil aus. In diese können Sie jeweils folgenden Code einfügen:
define
( [],
function()
{ "use strict";
return null;
}
);
Von minipong
gehen vier rote Pfeile aus. Das heißt, in die Datei „minipong.js
“
müssen sie folgende RequireJS-Kommando einfügen:
define
(['collision/ball_paddle', 'collision/stage_ball', 'collision/stage_paddle',
'model/loop'
],
function(collisionBallPaddle, collisionStageBall, collisionStagePaddle,
ModelLoop
)
{ "use strict";
return null;
}
);
Die Reihenfolge, in der Sie die benötigten Module laden, ist unwichtig. Wichtig ist nur, dass die Reihenfolge der Kurzbezeichnungen der Modulpfade mit der Reihenfolge der Parameter in der Callback-Funktion übereinstimmt.
Das Init-Modul „app/init
“ benötigt sehr viele andere Module, um seine Aufgabe zu erledigen.
Entsprechend lang ist die Modulliste:
define
( ['model/button', 'view/button',
'model/ball', 'view/ball',
'model/paddle', 'view/paddle',
'model/text', 'view/text',
'view/loop',
'control/keyboard',
'logic/minipong'
],
function(ModelButton, ViewButton,
ModelBall, ViewBall,
ModelPaddle, ViewPaddle,
ModelText, ViewText,
ViewLoop,
controlKeyboard,
minipong
)
{ "use strict";
return null;
}
);
Jetzt fehlt noch die Datei „web/json/init.json
“, die schon ziemliche Ausmaße angenommen hat,
weil sie für (fast) jedes Modul im Diagramm geeignete Initialwerte enthält:
{
"canvas":
{
"element": "canvas",
"width": 400,
"height": 300
},
"game":
{
"fps": 120,
"welcome": "Willkommen bei MiniPong",
"ballLost": "Das Spiel ist vorbei :-(",
"startGame": "Spiel starten",
"stopGame": "Spiel beenden"
},
"model":
{
"buttonStartStop":
{},
"ball":
{
"r": 10,
"pos": { "x": 195 , "y": 10 },
"vel": { "x": { "min": 50, "max": 200 },
"y": { "min": 150, "max": 200 }
}
},
"paddle":
{
"width": 50,
"height": 8,
"pos": {"x": 175, "y": 287},
"vel": {"x": 100, "y": 0},
"acc": {"x": 500, "y": 0},
"friction": 0.3
},
"info":
{
"pos": {"x": 10, "y": 130}
},
"score":
{
"pos": {"x": 5, "y": 3},
"template": "Punkte: $1",
"value": 0
}
},
"view":
{
"buttonStartStop":
{
"elementID": "button_start_stop"
},
"ball":
{
"color": "#55AA55",
"borderWidth": 1,
"borderColor": "#000000"
},
"paddle":
{
"color": "#aa55cc",
"borderWidth": 1,
"borderColor": "#000000"
},
"info":
{
"color": "#000000",
"font": "bold 25px Verdana, Geneva, sans-serif",
"textAlign": "center"
},
"score":
{
"color": "#000000",
"font": "bold 20px \"Courier New\", Courier, monospace",
"textBaseline": "top"
}
},
"control":
{
"player":
{
"left": {"key": "ArrowLeft", "keyCode": 37},
"right": {"key": "ArrowRight", "keyCode": 39}
}
}
}
Wenn Sie alles richtig gemacht haben, sollten Sie jetzt die Datei „index.html
“ im Browser fehlerfrei laden können.
Diese Datei hat noch keine Inhalte, mit Ausnahme eines leeren Canvas-Elements. In der Browser-Konsole sollten aber keine Fehler gemeldet werden.
Es ist allerdings ziemlich unbefriedigend, wenn man eine Web-Anwendung ausführt und überhaupt nichts zu sehen ist, obwohl etwas passiert. Öffnen Sie in den Browser-Entwicklertools die Netzwerkansicht und laden Sie die HTML-Datei erneut. Dann sollten Sie sehen, dass 23 Dateien geladen werden. (Hier ist später noch Optimierungsarbeit angesagt. Die Anzahl der Dateien muss reduziert und die Inhalte müssen komprimiert werden. Das ist aber nicht Thema dieses Tutoriums.)
Sie können probehalber auch mal console.log
-Befehle in die einzelnen Dateien einfügen, damit Sie sehen in welcher Reihenfolge die Module geladen werden.
console.log('Modul "MODULNAME" wird geladen');
// Ersetzen Sie MODULNAME durch den Namen des aktuellen Moduls.
define
( [],
function()
{ "use strict";
console.log('Modul "MODULNAME" wurde geladen');
// Ersetzen Sie MODULNAME durch den Namen des aktuellen Moduls.
return null;
}
);
Als Musterlösung gibt es das Projekt WK_MiniPong04_empty (SVN).
Die darin enthaltene Datei index.html
verwendet allerdings den Befehl „terminal.log
“, den Sie als Übungsaufgabe im Praktikum erstellen sollten. Damit werden die Log-Nachrichten
im HTML-Dokument und nicht in der Browser-Konsole ausgegeben. Außerdem wurde der Logging-Code etwas erweitert, sodass anhand von Einrückungen
zu sehen ist, welcher Code von welchem Modul geladen wird.
Models und Views
Ball
In den vorangegangenen Teilen des Tutoriums war der Ball ständig sichtbar und ständig in Bewegung. Das heißt, es wurden nur folgende Attribute und Methoden benötigt:
r
(Radius)x
(aktuelle $x$-Position)y
(aktuelle $y$-Position)vx
(aktuelle Geschwindigkeit in $x$-Richtung)vy
(aktuelle Geschwindigkeit in $y$-Richtung)move(p_seconds)
(Bewegen des Balls an die neue Position, die sich aus der aktuellen Position, der Geschwindigkeit und der Anzahl der Sekunden seit der letzten Berechnung der Position ergibt)
Im eigentlichen Spiel werden jedoch viel mehr Attribute und Methoden benötigt. Der Ball ist beim Start der Web-Anwendung zunächst unsichtbar, erst beim Spielstart wird er sichtbar gemacht
visible
(Flag, ob der Ball sichtbar oder unsichtbar ist)show()
(Methode, um den Ball sichtbar zu machen)hide()
(Methode, um den Ball unsichtbar zu machen)
Solange der Ball unsichtbar ist, bewegt er sich nicht (vx === 0
und vy === 0
) und befindet sich an seiner Startposition
(x === x_start
und y === y_start
). Bei einem Reset des Spiels werden Position und Geschwindigkeit auf passende Startwerte gesetzt.
Diese werden dem Konstruktor „ModelBall
“ im Parameter „p_init
“ übergeben und vom Konstruktor dann in folgenden Attribute gespeichert:
x_start
($x$-Koordinate der Startposition)y_start
($y$-Koordinate der Startposition)vx_start_min
(minimale Startgeschwindigkeit in $x$-Richtung)vx_start_max
(maximale Startgeschwindigkeit in $x$-Richtung)vy_start_min
(minimale Startgeschwindigkeit in $y$-Richtung)vy_start_max
(maximale Startgeschwindigkeit in $y$-Richtung)
Man beachte, dass der Ball bei jedem Spielstart von derselben Position aus startet, aber dass die Startgeschwindigkeit (in Grenzen) zufällig gewählt wird.
Um das Spiel starten, beenden und neu starten zu können, werden drei weitere Methoden benötigt:
reset()
(Ball anhalten, unsichtbar machen und auf die Startposition setzen)start()
(Ball auf eine zufällige Startgeschwindigkeit setzen)stop()
(Ball anhalten, d. h., die Geschwindigkeit auf Null setzen)
Insgesamt ergibt sich damit folgender Code:
Konstruktor
function ModelBall(p_init)
{
this.r = p_init.r;
this.x_start = p_init.pos.x;
this.y_start = p_init.pos.y;
this.vx_start_min = p_init.vel.x.min;
this.vx_start_max = p_init.vel.x.max;
this.vy_start_min = p_init.vel.y.min;
this.vy_start_max = p_init.vel.y.max;
this.reset(); // initializes further attributes
}
Öffentliche Methoden
ModelBall.prototype =
{
reset:
function()
{
this.stop(); // By default, the ball does not move around.
this.hide(); // By default, the ball is invisible.
this.x = this.x_start;
this.y = this.y_start;
},
show:
function() { this.visible = true; },
hide:
function() { this.visible = false; },
stop:
function()
{
this.vx = 0;
this.vy = 0;
},
start:
function()
{
// react only if the ball is not already moving
if (this.visible === true && this.vx === 0 && this.vy === 0)
{
this.vx = (Math.random() < 0.5 ? 1 : -1)*
(this.vx_start_min +
Math.random()*(this.vx_start_max - this.vx_start_min)
);
this.vy = (Math.random() < 0.5 ? 1 : -1)*
(this.vy_start_min +
Math.random()*(this.vy_start_max - this.vy_start_min)
);
}
},
move:
function(p_seconds)
{
this.x += this.vx * p_seconds;
this.y += this.vy * p_seconds;
}
};
Fügen Sie diesen Code in den Rumpf der Callback-Funktion in der Datei „model/ball.js
“ ein. Vergessen Sie nicht,
in dieser Callback-Funktionen den Return-Befehl
return null;
durch den Return-Befehl
return ModelBall;
zu ersetzen.
Die Ball-View ändert sich nur in einem Aspekt gegenüber der Version aus dem zweiten und dritten Teil des Tutoriums.
Die Draw-Funktion darf den Ball nur zeichnen, wenn er sichtbar ist. Kopieren Sie also den Inhalt der Datei
view/ball.js
aus dem dritten Teil des Tutoriums in die neue Datei view/ball.js
und fügen Sie die If-Anweisung
if (this.model.visible === true)
vor den eigentlichen Zeichenbefehl „p_context.drawImage
“ ein.
Paddle
Der Schläger ist sehr ähnlich aufgebaut wie der Ball. (Der Code ist also nicht DRY. Man sollte zwei allgemeine Klassen „ModelGeoObject
“
und „ViewGeoObject
“ definieren, von denen alle Geo-Objekt-Klassen wie „ModelBall
“, „ViewBall
“ gemeinsame
Eigenschaften erben.)
Dem Schläger ist neben Position und Geschwindigkeit auch noch eine Beschleunigung zugeordnet. Für alle drei Vektoren sind feste Startwerte vorgegeben, d. h. der Schläger befindet sich bei Spielbeginn stets an derselben Stelle, startet, sobald der Benutzer ihn bewegt, mit derselben Geschwindigkeit und wird stets im gleichen Maße schneller, je länger der Spieler die entsprechende Steuertaste gedrückt hält.
Gegenüber dem Ball gibt es ein weiteres Attribut, das für die Realisierung der Use Cases wichtig ist:
friction
(Reibung, genauer Reibungsfaktor)
Wenn sich der Schläger bei eine Kollision mit dem Ball bewegt, wird der Ball aufgrund der Reibung kurzzeitig vom Schläger in $x$-Richtung mitgezogen. Das heißt, die $x$-Geschwindigkeit des Schlägers ändert sich. Diese wird berechnet, indem zur $x$-Geschwindigkeit des Balls die $x$-Geschwindigkeit mal dem Reibungsfaktor des Schlägers addiert wird. Wenn die Reibung gleich Null ist hat also bei einer Kollision die Geschwindigkeit des Schlägers keine Auswirkung auf die Geschwindigkeit des Balls. Je größer der Reibungsfaktor gewählt wird, desto größer ist die Ablenkung. In der Musterlösung wurde der Reibungsfaktor auf $0,3$ gesetzt.
Zu guter Letzt werden noch vier berechnete Attribute für den Schläger definiert:
get left() { return this.x; }
(linke $x$-Koordinate des Schlägers)get right() { return this.x + this.width; }
(rechte $x$-Koordinate des Schlägers)get top() { return this.y; }
(linke $y$-Koordinate des Schlägers)get bottom() { return this.y + this.height; }
(rechte $y$-Koordinate des Schlägers)
Diese Attribute vereinfachen die Kollisionsfunktionen etwas, bei denen mehrfach auf die verschiedenen Seiten des Schlägers zugegriffen werden muss.
Insgesamt sieht die Implementierung des Schlägermodells folgendermaßen aus:
Konstruktor
function ModelPaddle(p_init)
{
this.width = p_init.width;
this.height = p_init.height;
this.x_start = p_init.pos.x;
this.y_start = p_init.pos.y;
this.vx_start = p_init.vel.x;
this.vy_start = p_init.vel.y;
this.ax_start = p_init.acc.x;
this.ay_start = p_init.acc.y;
this.friction = p_init.friction;
this.reset(); // initializes further attributes
}
Öffentliche Methoden
ModelPaddle.prototype =
{
reset:
function()
{
this.stop(); // By default, the paddle does not move around.
this.hide(); // By default, the paddle is invisible.
this.x = this.x_start;
this.y = this.y_start;
},
show:
function()
{ this.visible = true; },
hide:
function()
{ this.visible = false; },
stop:
function()
{ this.vx = 0;
this.vy = 0;
this.ax = 0;
this.ay = 0;
},
start:
function(p_direction)
{
// react only if the paddle is visible not already moving
if (this.visible === true &&
this.vx === 0 && this.vy === 0
)
{
switch (p_direction)
{
case "left":
this.vx = -this.vx_start;
this.ax = -this.ax_start;
break;
case "right":
this.vx = this.vx_start;
this.ax = this.ax_start;
break;
case "up":
this.vy = -this.vy_start;
this.ay = -this.ay_start;
break;
case "down":
this.vy = this.vy_start;
this.ay = this.ay_start;
break;
}
}
},
move:
function(p_seconds)
{ this.x += this.vx * p_seconds;
this.y += this.vy * p_seconds;
this.vx += this.ax * p_seconds;
this.vy += this.ay * p_seconds;
},
/** The left side of the paddle (read only). */
get left() { return this.x; },
/** The right side of the paddle (read only). */
get right() { return this.x + this.width; },
/** The top side of the paddle (read only). */
get top() { return this.y; },
/** The bottom side of the paddle (read only). */
get bottom() { return this.y + this.height; }
};
Beachten Sie, dass es hier empfehlenswert ist, das Prototyp-Objekt des Konstruktors nicht mit mehrere Befehle der Art
ModelPaddle.prototype.reset = function(){...};
ModelPaddle.prototype.show = function(){...};
ModelPaddle.prototype.hide = function(){...};
...
zu befüllen, sondern ein eigenes Prototyp-Objekt zu definieren:
ModelPaddle.prototype =
{
reset: function(){...},
show: function(){...},
hide: function(){...},
...
get left() { return this.x; },
get right() { return this.x + this.width; },
...
};
Der Grund ist, dass es keine einfache Syntax gibt, eine Getter- oder einer Setter-Methode zu einem
bestehenden Objekt hinzuzufügen. Im obigen Beispiel müsste man beispielsweise Folgendes schreiben,
um Getter-Methoden zum Objekt „ModelPaddle.prototype
“ nachträglich hinzuzufügen:
Object.defineProperty(ModelPaddle.prototype,
'left',
{ get: function() { return this.x; } }
);
Object.defineProperty(ModelPaddle.prototype,
'right',
{ get: function() { return this.x + this.width; } }
);
...
Die Paddle-View ändert sich wiederum nur in einem Aspekt gegenüber der Version aus dem zweiten und dritten Teil des Tutoriums.
Die Draw-Funktion darf den Schläger nur zeichnen, wenn er sichtbar ist. Kopieren Sie also den Inhalt der Datei
view/paddle.js
aus dem dritten Teil des Tutoriums in die neue Datei view/paddle.js
und fügen Sie die If-Anweisung
if (this.model.visible === true)
vor den eigentlichen Zeichenbefehl „p_context.drawImage
“ ein.
Text
Im Spiel „MiniPong“ gibt es zwei Textfelder: Eines zum Anzeigen des Scores und eines zum Anzeigen von allgemeinen Informationen. Im Gegensatz zu Ball und Schläger bewegt sich ein Text (in diesem Spiel!) nicht. Daher benötigt man im Model wesentlich weniger Attribute und Methode.
x
($x$-Position des Text-Aufhängepunkt)y
($y$-Position der Text-Baseline)template
(ein optionaler String, der die Zeichenfolge „$1
“ enthält)value
(der Wert, der im Textfeld dargestellt werden soll)text
(ein Read-only-Attribut: „return template.replace('$1', value)
“)visible
(Sichtbarkeit des Textes)
Das zugehörige View-Objekt legt das Aussehen des Textes fest:
color
(Textfarbe)font
(Textfont, analog zu CSS-Fonts)textAlign
(Aufhängepunkt:left
,center
,right
)textBaseline
(Baseline:top
,bottom
,middle
,alphabetic
,hanging
)
Damit sollte eigentlich klar sein, wie die Model- und die View-Klasse aussehen-
Fügen Sie diesen Code in den Rumpf der Callback-Funktion in der Datei „model/text.js
“ ein. Vergessen Sie nicht,
in dieser Callback-Funktionen den Return-Befehl
return null;
durch den Return-Befehl
return ModelText;
zu ersetzen.
ModelText
: Konstruktor
function ModelText(p_init)
{
this.x = p_init.pos.x;
this.y = p_init.pos.y;
this.template = p_init.template;
this.value = p_init.value;
this.visible = true;
}
ModelText
: Öffentliche Methoden
ModelText.prototype =
{
// read only attribute
get text()
{ return (this.value == null)
? ''
: (this.template == null)
? this.value.toString()
: this.template.replace('$1', this.value);
}
};
Die View-Klasse ist auch nicht viel komplexer. Auf die Vorberechnung eine Mini-Canvas, der anstelle des Textes in den Haupt-Canvas kopiert wird, wird hier verzichtet. Da sich der Text-Inhalt ändern kann und üblicherweise auch regelmäßig ändert, müsste man bei jeder Text-Änderung einen neuen derartigen Mini-Canvas erstellen. Das ist zwar möglich, führt hier aber zu weit.
ViewText
: Konstruktor
function ViewText(p_model, p_init /*, p_document*/)
{
this.model = p_model;
this.color = p_init.color || 'black';
this.font = p_init.font || 'normal';
this.textAlign = p_init.textAlign || 'left';
this.textBaseline = p_init.textBaseline || 'alphabetic';
}
ViewText
: Öffentliche Methoden
ViewText.prototype.draw =
function(p_context)
{
var l_model = this.model;
if (l_model.value == null || l_model.value.toString() === '')
return;
// ALL font attributes must be set, as it cannot be
// guaranteed that another module has changed some font
// attributes before.
p_context.font = this.font;
p_context.textAlign = this.textAlign;
p_context.textBaseline = this.textBaseline;
p_context.fillStyle = this.color;
p_context.fillText(l_model.text,
(this.textAlign === 'center')
? p_context.canvas.clientWidth/2
: l_model.x,
l_model.y
);
};
Haben Sie an die Return-Anweisung „return ViewText;
“ gedacht?
Button
Einen grafischen Button, der im Canvas dargestellt wird, könnte man mit Hilfe eines Rechtecks oder Kreises und eines Textes realisieren. Button-Klicks müsste man dann mit Hilfe eine Kollisionserkennung („Mausspitze kollidiert mit Button“) und -behandlung verarbeiten.
Hier soll ein einfacherer Weg eingeschlafen werden: Als Button wird ein HTML-Button verwendet, der sich außerhalb der Bühne befindet. Folgende Attribute sind in einem Model-Objekt enthalten:
label
(Der Text, mit dem der Button im HTML-Dokument beschriftet sein soll.)class
(Ein CSS-Klassen-Name, der dem Button-Element im HTML-Dokument zugeordnet wird. Beispielsweise kann man eine CSS-Klasse „.hidden
“ definieren, mit dem man den Button unsichtbar machen kann.)onClick
(Eine Methode, die aufgerufen wird, sobald der Button geklickt wird.)
Der Konstruktor übernimmt für diese Attribute wie üblich alle Initialwerte aus einen Init-Objekt namens „p_init
“. Ein Problem besteht dabei allerdings.
Das Init-Objekt wird üblicherweise aus einer JSON-Datei eingelesen. Eine derartige Datei kann keine JavaScript-Funktionen enthalten.
Das heißt, das Attribut „onClick
“ wird üblicherweise mit „null
“ initialisiert. Es ist dann die Aufgabe einer Logikkomponente
diesem Attribut zur rechten Zeit eine geeignete Prozedur zuzuweisen.
ModelButton: Konstruktor
function ModelButton(p_init)
{
this.label = p_init.label || null;
this.class = p_init.class || null;
this.onClick = p_init.onClick || null;
}
Die View ist auch nicht sonderlich kompliziert.
Der Konstruktor speichert wie üblich das zugehörige Model im Attribut „model
“.
Außerdem sucht er im HTML-Dokument denjenigen Button, der mit dem Model verknüpft werden soll.
ViewButton: Konstruktor
function ViewButton(p_model, p_init, p_document)
{
this.model = p_model;
this.element = p_document.getElementById(p_init.elementID);
}
Sie Draw-Methode macht nichts weiter, als alle Attribute, die im Model definiert sind, in das zugehörige HTML-Button-Element zu kopieren, sofern das jeweilige Attribut im Model definiert ist und sich vom im HTML-Button-Element gespeicherten Wert unterscheidet.
ViewButton: Öffentliche Methoden
ViewButton.prototype.draw =
function()
{
var l_model = this.model,
l_element = this.element;
if (l_model.label != null && l_element.innerHTML !== this.model.label)
{ l_element.innerHTML = this.model.label; }
if (l_model.class != null && l_element.className !== this.model.class)
{ l_element.className = this.model.class; }
if (l_model.onClick != null && l_element.onclick !== this.model.onClick)
{ l_element.onclick = this.model.onClick; }
};
Da die Draw-Methode regelmäßig aufgerufen wird (ca. 60 mal pro Sekunde), ändert sich das Aussehen und/oder das Verhalten des Button automatisch mit jeder Änderung des Models.
Eigentlich ist das ein Overkill. So eine Änderung des Button-Labels und des Button-Verhaltens passiert nur ein paar mal pro Spiel. Hätte die Logik eine direkten Zugriff auf die View, könnte man es sich sparen, den Button durch die View-Loop aktualisieren zu lassen. Wenn man der Spiellogik – aus gutem Grund – keinen direkten Zugriff auf die View gewähren will und man den Button auch nicht viele Dutzend mal pro Sekunde aktualisieren will, hilft der Einsatz des so genannten Observer-Patterns weiter. Dies soll hier aber nicht weiter verfolgt werden.
Keyboard-Controller
Der Controller zum Steuern des Paddles per Tastatur ändert sich nicht. Er kann eins zu eins
aus dem dritten Teil des Tutoriums übernommen
und in die Datei controller/keyboard.js
eingefügt werden.
Kollisionserkennung und -behandlung
Im dritten Teil des Tutoriums wurde die Kollisionserkennung und -behandlung als Teil des Models angesehen. Ihre einzige Aufgabe war es, Geschwindigkeit und Position von beweglichen Objekten im Falle von Kollisionen zu korrigieren. Nun kommt noch eine weitere Aufgabe hinzu. Sie muss die Spiellogik über Kollisionen informieren, die das Spielgeschehen beeinflussen. Im Fall von MiniPong sind das die Kollision von Schläger und Ball (Punktgewinn) sowie die Kollision von Schläger und unterem Bühnenrand (Spielende).
Bislang gab es lediglich ein Modul namens
„[1]
“
zur Kollisionsbehandlung. Dieses Modul droht zum Giganten zu werden, wenn immer mehr und mehr Kollisionsarten behandelt werden müssen.
Daher wird es in mehrere Teilmodule aufgespalten.
Die Kollisionsprozedur „
collisionStagePaddle
“ kann eins zu eins vom dritten Teil des Tutoriums übernommen werden,
da die Kollision des Paddles mit der Wand keine Auswirkung auf das Spielgeschehen hat. Diese Kollision bewirkt lediglich,
dass der Schläger gestoppt wird. Und das erledigt die Prozedur von sich aus. Allerdings gibt es durchaus Situationen, in denen auch
eine Kollision zwischen Schläger und Wand von der Spiellogik behandelt werden muss. Beispielsweise kann man im Breakout-Spiel Bolo
mit dem Schläger gegen die Wand „donnern“. Wenn man dies fest genug macht, wenn also der Schläger bei der Kollision mit der Wand eine gewisse
Geschwindigkeit hat, wird der Raum leicht erschüttert. Dies hat auch Auswirkungen auf den Ball, dessen Geschwindigkeitsvektor dadurch leicht verändert wird.
Auf diese Weise kann man den Ball, wenn er irgendwo feststeckt, häufig wieder frei bekommen.
Die folgende Implementierung der Kollisionsprozedur „
collisionStagePaddle
“ unterscheidet sich in einer Hinsicht von der ursprünglichen
Implementierung. Anstatt die Ränder des Schlägers zu berechnen, werden die neuen Schläger-Attribute „left
“, „right
“, „top
“ und „bottom
“ verwendet. Fügen Sie diesen Code ins Modul „collision/stage_paddle
“ ein (und vergessen Sie nicht, den Return-Befehl anzupassen).
function collisionStagePaddle(p_stage, p_paddle)
{
// If the paddle collides with the left wall of the stage,
// stop it and move it back to the stage.
if (p_paddle.vx < 0 && p_paddle.left <= 0)
{
p_paddle.stop();
p_paddle.x = 0;
}
// If the paddle collides with the right wall of the stage,
// stop it and move it back to the stage.
if (p_paddle.vx > 0 && p_paddle.right >= p_stage.width)
{
p_paddle.stop();
p_paddle.x = p_stage.width - p_paddle.width;
}
// If the paddle collides with the top wall of the stage,
// stop it and move it back to the stage.
if (p_paddle.vy < 0 && p_paddle.top <= 0)
{
p_paddle.stop();
p_paddle.y = 0;
}
// If the paddle collides with the bottom wall of the stage,
// stop it and move it back onto the stage.
if (p_paddle.vy > 0 && p_paddle.bottom >= p_stage.height)
{
p_paddle.stop();
p_paddle.y = p_stage.height - p_paddle.height;
}
}
Die Kollisionsprozedur „collisionStageBall
“ ist im Modul „collision/stage_ball
“ enthalten.
Die Prozedur kann allerdings nicht eins zu eins vom dritten Teil des Tutoriums übernommen werden, da die Kollision mit
der unteren Wand anders behandelt werden muss, als die Kollision mit den übrigen Wänden.
Bei einer Kollision mit der unteren Wand wird das Spiel beendet. Für die Behandlung des Spielendes ist die
Spiellogik zuständig. Um über diese Art der Kollision benachrichtigt zu werden, übergibt sie der
Kollisionsprozedur „collisionStageBall
“ im Parameter „cb_hit
“ eine Callback-Funktion,
die im Falle einer Kollision mit der unteren Wand aufgerufen werden soll. Damit die Spiel erst endet,
wenn der Ball die Bühne vollständig verlassen hat, wird die untere Wand etwas nach unten in den nicht sichtbaren Bereich
verschoben.
function collisionStageBall(p_stage, p_ball, cb_exit)
{
// If the ball collides with the left or the right wall of the stage
// mirror its x-velocity and move the ball back onto the stage.
if (p_ball.x <= p_ball.r)
{
p_ball.vx = -p_ball.vx;
p_ball.x += 2*(p_ball.r - p_ball.x);
}
if (p_ball.x >= p_stage.width - p_ball.r)
{
p_ball.vx = -p_ball.vx;
p_ball.x -= 2*(p_ball.r - p_stage.width + p_ball.x);
}
// If the ball collides with the top wall of the stage
// mirror its y-velocity and move the ball back onto the stage.
if (p_ball.y <= p_ball.r)
{
p_ball.vy = -p_ball.vy;
p_ball.y += 2*(p_ball.r - p_ball.y);
}
// If the ball leaves the bottom of the stage, call cb_exit.
// Factor 1.5: The ball is really outside the stage an thus invisible,
// even if the view draws a very thick border around it.
if (p_ball.y >= p_stage.height + 1.5*p_ball.r)
{ if (cb_exit)
cb_exit();
}
}
Zu guter Letzt muss noch die Kollisionserkennung und -behandlung für Kollisionen des Balls mit dem Schläger
realisiert werden. Über jede derartige Kollision wird die Spiellogik ebenfalls mit einer Callback-Funktion informiert,
damit letztere den Punktestand aktualisieren kann.
Die nachfolgende Implementierung der Kollisionserkennung und -behandlung ist ziemlich primitiv, da nur zwei Fälle
unterschieden werden: Kollision des Balles mit der oberen oder der unteren Seite des Schlägers. Das reicht
zunächst für unsere Zwecke, führt aber schon zu Problemen, wenn ein senkrechter Schläger an einer Seitenwand
verwendet werden soll. In diesem Fall müsste die Kollisionsprozedur umgeschrieben werden.
Bei einer korrekten Kollisionserkennung und -behandlung zwischen Kreis und Rechteck müssen 8 Fälle unterschieden werden:
Kollision des Balls mit einer der vier Seitenwände sowie Kollision des Balls mit einer der vier Ecken.
function collisionBallPaddle(p_ball, p_paddle, cb_hit)
{
if (p_ball.y + p_ball.r >= p_paddle.top &&
p_ball.y + p_ball.r <= p_paddle.bottom &&
p_ball.x + 0.5*p_ball.r >= p_paddle.left &&
p_ball.x - 0.5*p_ball.r <= p_paddle.right
)
{
// Resolve penetration.
if (p_ball.vy > 0) // The ball is moving from top to bottom.
{ p_ball.y = p_paddle.top - p_ball.r; }
else // The ball is moving from bottom to top.
{ p_ball.y = p_paddle.bottom + p_ball.r; }
// Modify the velocity of the ball.
p_ball.vy = -p_ball.vy;
p_ball.vx += p_paddle.friction*p_paddle.vx;
// If the paddle hits the ball, invoke the callback function.
if (cb_hit)
{ cb_hit(); }
}
}
Model- und View-Loop
Die Model-Loop sowie die View-Loop waren bislang Bestandteile des Moduls
„minipong.js
“. Da dieses Modul deutlich größer wird,
sollte es zerschlagen werden. Für die MiniPong-Anwedung wird es in vier Einzelmodule unterteilt:
init
(Erzeugung aller wesentlichen Objekte; Starten der View Loop; Verknüpfung des Keyboard-Controllers mit dem Paddle)
ViewLoop
(Visualisierung der aktuellen Zustände der grafischen Objekte des Spiels)
ModelLoop
(Berechnung der Positionen der beweglichen Objekte des Spiels; Information der Spiellogik über bestimmte Kollisionen)
minipong
(Die Spiellogik)
Zunächst werden die beiden Loops in eigenständige Module ausgelagert. Beide Module werden als Klassen realisiert.
Das heißt, es müssen jeweils ein ViewLoop
- und ein ModelLoop
-Objekt erzeugt werden.
Diese Objekte kennen jeweils zwei Methoden start
und stop
, den denen die Loops
gestartet und auch wieder angehalten werden können. Im Falle der View-Loop ist das für das Spiel MiniPong nicht
sonderlich wichtig, da diese View nur einmal gestartet wird und dann dauerhaft aktiv ist. Bei einer komplexeren Web-Anwendung
solle man allerdings versuchen, die View-Loop nur während des eigentlichen Spiels zu aktivieren. So eine Loop
kostet Rechenpower und belastet damit insbesondere den Akku von mobilen Geräten.
Die Model-Loop muss auch schon von der MiniPong-Spiellogik gestartet und gestoppt werden können. Dies wird insbesondere
bei einer erweiterten Variante deutlich, bei dem das Spiel durch eine Pause-Taste temporär angehalten werden kann
(index_pause.html).
Die View-Loop erhält als Argumente das Fenster in dem die Web-Anwendung läuft, einen Canvas, auf dem grafische Objekte visualisiert werden sollen
sowie eine Liste, die die Views dieser Objekte enthält. Die View-Loop löscht zu Beginn den Canvas und ruft dann für alle View-Objekte die
Methode „draw
“ auf. Dieser übergibt sie als Argument den 2D-Context des Canvas-Elements. Allerdings ist die Draw-Methode nicht
verpflichtet, ein Objekt auf den Canvas zu zeichnen. Sie kann auch ein Objekt im DOM-Baum des HTML-Dokuments aktualisieren.
Dies macht beispielsweise die Draw-Methode des Button-Objekts.
ViewLoop: Konstruktor
function ViewLoop(p_window, p_canvas, p_views)
{
var l_context = p_canvas.getContext("2d"),
n = p_views.length;
this.v_window = p_window;
this.m_update_view =
function m_update_view()
{
// clear canvas
l_context.clearRect(0, 0, p_canvas.width, p_canvas.height);
// draw all visual objects
for (var i = 0; i <n; i++ )
{ p_views[i].draw(l_context); }
p_window.requestAnimationFrame(m_update_view);
};
}
Aktiviert und am Laufen gehalten wird die View-Loop wie üblich mit Hilfe der Methode „window.requestAnimationFrame
“.
Diese Methode liefert beim Aufruf eine Integerzahl zurück, die den Timer eindeutig identifiziert. Wenn man diesen Identifikator speichert,
kann man die rekursiven Aufrufe der Methode „window.cancelAnimationFrame
“ unterbrechen und so die Loop anhalten.
Dies wird ausgenutzt, um die Start- und die Stopp-Methode zu realisieren.
ViewLoop:Öffentliche Methoden
ViewLoop.prototype =
{
start:
function()
{
if (this.v_timer == null)
{ this.v_timer = this.v_window.requestAnimationFrame(this.m_update_view); }
},
stop:
function()
{
if (this.v_timer != null)
{
this.v_window.cancelAnimationFrame(this.v_timer);
delete this.v_timer;
}
}
};
Der Model-Loop-Konstruktor erwartet als Input eine Kollisionsprozedur, die
(angestrebte) Update-Frequenz sowie eine Liste von Model-Objekten,
die bewegt werden sollen.
Der Konstruktor definiert ein „privates“ Attribut „v_milliseconds
“ und eine „private“ Methode „m_update_model
“
auf die die Start- und die Stop-Methode zugreifen können. (In Wirklichkeit handelt es sich um ein öffentliches Attribut und um eine öffentliche Methode,
da im Prototype-Objekt keine privaten Elemente definiert werden können. Ich kennzeichne private Elemente einfach mittels eines Namenszusatzes
„v_...
“ – v
für „(Zustands-)Variable“ – bzw. „m_...
“ – m
für „Methode“ – und weiß damit,
dass ich von außerhalb nicht auf derartige Elemente zugreifen darf.)
Die Methode „m_update_model
“ ruft zunächst für alle Objekte die Move-Methode auf und führt anschließend (a posteriori)
mit Hilfe der Kollisionsprozedur eine Kollisionserkennung und -behandlung durch.
ModelLoop: Konstruktor
function ModelLoop(p_collision, p_f, p_models)
{
var l_seconds = 1 / p_f;
this.v_milliseconds = 1000 * l_seconds;
this.m_update_model =
function ()
{
// move around all movable objects
for (var i = 0, n = p_models.length; i < n; i++)
{ p_models[i].move(l_seconds); }
// detect and handle collision (a posteriori)
p_collision();
};
}
Die Model-Update-Methode soll regelmäßig alle v_milliseconds
Millisekunden aufgerufen werden.
Dazu wird die JavaScript-Funktion „setInterval
“ verwendet (die allerdings die Zeitvorgaben nicht sonderlich genau nimmt).
Diese Funktion liefert, wie auch schon requestAnimationFrame
, beim Aufruf eine Integerzahl zurück,
mit der der Timer eindeutig identifiziert wird. Mit Hilfe dieses Identifikators und der Funktion „clearInterval
“
kann man den Timer anhalten. Die Star- und die Stopp-Methoden können daher auf genau dieselbe Art realisiert werden,
wie bei der View-Loop:
ModelLoop:Öffentliche Methoden
ModelLoop.prototype =
{
start:
function()
{
if (this.v_timer == null)
{ this.v_timer = setInterval(this.m_update_model, this.v_milliseconds) }
},
stop:
function()
{
if (this.v_timer != null)
{
clearInterval(this.v_timer);
delete this.v_timer;
}
}
};
Initialisierung
Die Initialisierungsprozedur „init
“ hat zwei Aufgaben: Zunächst muss sie alle wesentlichen Objekte erstellen
und anschließend die Anwendung zu Laufen bringen.
Sie erwartet zwei Argumente: das Fenster, in dem die Anwendung läuft und das Initialisierungsobjekt,
das in der JSON-Datei definiert wurde:
function init(p_window, p_init)
Anschließend muss sie die benötigten Objekte erstellen bzw. aus dem HTML-Dokument extrahieren.
Die View-Objekte benötigen das im Browser-Fenster enthalten HTML-Dokument sowie das
darin enthalten Canvas-Element. Auch der Keyboard-Controller benötigt das HTML-Dokument.
var l_canvas_init = p_init.canvas,
l_document = p_window.document,
l_canvas = l_document.getElementById(l_canvas_init.element),
Als nächstes müssen alle Model- und View-Objekte erzeugt werden, mit Ausnahme des ModelStage
-Objekts.
(Als ModelStage
-Objekt wird das Canvas-Init-Objekt verwendet. Es enthält die Größe und die Breite der Bühne,
und das ist alles was die Kollisionsprozedur von der Bühne wissen muss.)
Jedem Model-Objekt werden die Initialisierungsinformationen übergeben, die für das jeweilige Objekt im Initialisierungsobjekt
„p_init
“ enthalten sind. Jedem View-Objekt werden nicht nur Initialisierungsinformationen aus dem
p_init
-Objekt übergeben, sondern auch das Model, das es darstellen soll. Darüber hinaus benötigen
einige Objekte das Objekt „p_dokument
“, um einen Mini-Canvas zum Cachen der grafischen Darstellung
des Models erstellen zu können.
l_model_button = new ModelButton(p_init.model.buttonStartStop),
l_view_button = new ViewButton(l_model_button, p_init.view.buttonStartStop, l_document),
l_model_ball = new ModelBall(p_init.model.ball),
l_view_ball = new ViewBall(l_model_ball, p_init.view.ball, l_document),
l_model_paddle = new ModelPaddle(p_init.model.paddle),
l_view_paddle = new ViewPaddle(l_model_paddle, p_init.view.paddle, l_document),
l_model_info = new ModelText(p_init.model.info),
l_view_info = new ViewText(l_model_info, p_init.view.info),
l_model_score = new ModelText(p_init.model.score),
l_view_score = new ViewText(l_model_score, p_init.view.score),
Als nächstes werden die soeben erzeugten Model- und View-Objekte in Container gesteckt,
damit sie möglichst einfach an die Spiellogik bzw. die View-Loop übergeben werden können.
Die Modelle werden in ein Hasharray (= JavaScript-Objekt) gepackt, da die Spiellogik
namentlich auf die Objekte zugreifen können muss.
für die View-Loop wird ein einfaches Array als Container eingesetzt, da diese einfach der
Reihe nach für alle View-Objekte die Draw-Methode aufruft.
l_models = { stage: l_canvas_init,
button: l_model_button,
ball: l_model_ball,
paddle: l_model_paddle,
info: l_model_info,
score: l_model_score
},
l_views = [ l_view_button, l_view_ball, l_view_paddle, l_view_info, l_view_score];
Wie üblich muss noch die Größe des Canvas angepasst werden. Diese Größe ist wie immer im Objekt
„l_canvas_init
“ enthalten.
l_canvas.width = l_canvas_init.width;
l_canvas.height = l_canvas_init.height;
Zu guter Letzt muss Init-Prozedur eine View-Loop erzeugen und starten (das geht in einem Aufwasch,
die die Loop nicht mehr angehalten werden soll), den Keyboard-Controller dem Paddle zuweisen
und die Spiellogik starten.
Bei jedem dieser drei Aufrufe übergibt sie einige der zuvor erzeugten Objekte:
ViewLoop
: alle View-Objekte
controlKeyboard
: das Paddle-Model
minipong
: alle Model-Objekte
new ViewLoop(p_window, l_canvas, l_views).start();
controlKeyboard(p_window, p_init.control.player, l_model_paddle);
minipong(p_init.game, l_models);
MiniPong
Nachdem das Modul „logic/minipong
“ von allen übrigen Aufgaben befreit wurde, ist es nur noch für die Umsetzung der Spiellogik verantwortlich.
Sie erhält von der Init-Prozedur die für sie bestimmten Initialisierungswerte sowie die Model-Objekte, die sie manipulieren kann und soll.
function minipong(p_init, p_models)
Zunächst speichert sie alle Model-Objekte in lokalen Variablen. Das hat den Vorteil, dass sie nicht immer
Aufrufe der Art „p_models.xyz
“ tätigen muss. Außerdem legt sie ein leeres Array „l_models_movable
“
an, das später alle beweglichen Model-Objekte enthält, d. h. alle Model-Objekte, für die die Methode „l_move
“
existiert. Zu guter Letzt legt sie in der Variablen „l_model_loop
“ eine Model-Loop an, die die Position und Geschwindigkeit
der beweglichen Objekte regelmäßig aktualisiert. Als Kollisionsprozedur wird diesem Objekt die Funktion „f_collision
“
übergeben. Diese Funktion wird weiter unten im Funktionsrumpf von minipong
definiert.
var l_stage = p_models.stage,
l_button = p_models.button,
l_info = p_models.info,
l_score = p_models.score,
l_ball = p_models.ball,
l_paddle = p_models.paddle,
l_models_movable = [],
l_model_loop = new ModelLoop(f_collision, p_init.fps, l_models_movable);
Nun ist es an der Zeit, das Array „l_models_movable
“ zu befüllen. Dazu wird einfach die Liste mit
allen Model-Objekt durchlaufen. Alle Objekte, die die Methode „move
“ enthalten werden in dieses Array eingefügt.
// Store all model objects that have a move method within the array l_models_movable.
for (var k in p_models)
{ if (p_models.hasOwnProperty(k) && p_models[k].move != null)
{ l_models_movable.push(p_models[k]); }
}
Mit den letzten beiden Anweisunges startet „minipong
“ die Anwendung. Sie ruft
dazu die Prozedur „f_stop
“ auf (da der Benutzer das Spiel erst mittel eine Klicks auf den Start-Knopf starten muss) und schreibt eine
Willkommensbotschaft in Info-Textfeld (und überschreibt damit die Meldung, die die Stopp-Funktion ins Info-Textfeld geschrieben hat.).
// Stop the game and display a welcome message.
f_stop();
l_info.value = p_init.welcome;
Nun müssen noch vier Prozeduren definiert werden, die in verschiedenen Spielsituationen aufgerufen werden.
Alle vier Prozeduren werden im Rumpf der Prozedur „minipong
“ definiert. Das heißt, nur
minipong
kann auf diese Prozeduren zugreifen. Sie kann sie allerdings als Callback-Funktionen
an andere Prozeduren und Methoden weiterleiten. Und genau das macht sie auch.
Ganz wichtig für die Spiellogik ist die Definition einer geeigneten Kollisionsprozedur,
die der Model-Loop übergeben wird, um die Kollisionserkennung und -behandlung damit durchzuführen.
Diese Prozedur verwendet die drei Hilfsprozeduren „collisionBallPaddle
“, „collisionStageBall
“ und „ collisionStagePaddle
“,
die einfach nacheinander aufgerufen werden.
Zwei dieser Prozeduren erwarten als Input eine Callback-Funktion, die im Falle von bestimmten Kollisiones von der Kollisionsbehandlung aufgerufen werden.
Die Prozedur „collisionBallPaddle
“ ruft die Callback-Funktion auf, sobald der Ball mit dem Schläger kollidiert.
In diesem Fall soll der Punktestand erhöht werden. Das wird mit einer sehr einfachen anonymen Prozedur erledigt:
function(){ l_score.value++; }
Diese Prozedur erhöht bei jedem Aufruf im Text-Feld „score
“ den Wert „value
“ um eins.
Sobald ein neues Spiel gestartet wird, wird dieser Vert auf 0
gesetzt.
Die Prozedur „collisionStageBall
“ informiert minipong
mittels Callback, wenn der Ball die Bühne verlässt.
Als Callback-Funktion wird dieser Prozedur die Prozedur „f_stop
“ (siehe unten) übergeben, um das Spiel zu beenden.
// Collision detection and handling.
function f_collision()
{
collisionBallPaddle(l_ball, l_paddle, function(){ l_score.value++; });
collisionStageBall(l_stage, l_ball, f_stop);
collisionStagePaddle(l_stage, l_paddle);
}
Ganz zu Beginn des Spiels, bei einem Abbruch durch den Spieler mittel Button-Klick und sobald der
Ball die Bühne verlässt wird das Spiel beendet. Dies ist die Aufgabe der Prozedur „f_stop
“.
Sie hält die Model-Loop und Ball an und macht Ball und Schläger unsichtbar.
Dann ändert sie das Aussehen und das Verhalten des Start-Stopp-Buttons:
Sie weißt ihm das Label „p_init.startGame
“ (=== "Spiel starten"
gemäß init.json
)
und die Prozedur „p_start
“ zu. Das heißt, bei einem Klick auf diesen Button wird die Prozedur „p_start
“
ausgeführt. Zu guter Letzt schreibt sie ins Info-Textfeld eine Nachricht, dass das Spiel beendet ist. Diese Nachricht
kann man überschreiben, indem man direkt im Anschluss an einen Aufruf von „p_stop
“ eine
andere Nachricht ins Info-Textfeld schreibt. Dies geschieht direkt nachdem die Web-Anwendung gestartet wurde (siehe oben),
// Stop the game.
function f_stop()
{
l_model_loop.stop();
l_ball.stop();
l_ball.hide();
l_paddle.hide();
l_button.label = p_init.startGame;
l_button.onClick = f_start;
l_info.value = p_init.ballLost;
}
Wenn das Spiel angehalten wurde, kann man es mit einem Klick auf den Start-Stopp-Button starten.
Die zugehörige Start-Prozedur muss das Spiel zunächst zurücksetzen. Sie setzt den Score-Wert auf 0
,
löscht den Inhalt des Info-Textfeldes und setzt Schläger und Ball zurück an die Startpositionen.
Dann ändert sie das Aussehen und das Verhalten des Start-Stopp-Buttons:
Sie weißt ihm das Label „p_init.stopGame
“ (=== "Spiel beenden"
gemäß init.json
)
und die Prozedur „p_stop
“ zu. Das heißt, bei einem Klick auf diesen Button wird die Prozedur „p_stop
“
ausgeführt und das Spiel sofort beendet.
Nun kann sie das eigentliche Spiel starten. Dazu macht sie Schläger und Ball sichtbar und startet dann den Ball und die Model-Loop.
Jetzt sind die Call-Backfunktionen der Kollisionsprozedur scharfgeschaltet. Das heißt, Kollisionen vom Schläger mit dem Ball
werden mit einem Puktgewinn belohnt (dieser wird durch die View-Loop auch sofort angezeigt).
Wenn der Ball die Bühne verlässt oder wenn der Benutzer den Start-Stopp-Button drückt, wird das Spiel beendet.
Der erspielte Score ist zu diesem Zeitpunkt noch sichtbar. Erst mit einem neuen Spielstart wird er wieder auf 0
gesetzt.
// Start the game.
function f_start()
{
l_score.value = 0;
l_info.value = '';
l_ball.reset();
l_paddle.reset();
l_button.label = p_init.stopGame;
l_button.onClick = f_stop;
l_paddle.show();
l_ball.show();
l_ball.start();
l_model_loop.start();
}
Main
Jetzt müssen Sie in der Datei „main
“ noch den Kommentar vor dem Aufruf der Prozedur „init
“ löschen.
Damit wurden alle Module vollständig erstellt und MiniPong sollte gespielt werden können.
Quellen
- Braun (2011): Herbert Braun; Webanimationen mit Canvas; in: c't Webdesign; Band: 2011; Seite(n): 44–48; Verlag: Heise Zeitschriften Verlag; Adresse: Hannover; 2011; Quellengüte: 5 (Artikel)
- Kowarschick (MMProg): Wolfgang Kowarschick; Vorlesung „Multimedia-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 3 (Vorlesung)