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

Use Cases der Tutoriums-Anwendung MiniPong

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

Klassendiagramm

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.

Klassendiagramm: Detailansicht der View-Loop

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. Die entsprechenden Beziehungspfeile (blau markiert) werden allerdings nur der nebenstehenden Detailansicht des Klassendiagramms, aber nicht im Übersichtsdiagramm angezeigt (da das Übersichtsdiagramm anderenfalls etwas unübersichtlich werden würde). Die Init-Prozedur erzeugt diese 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:

1. Simulation der Ball/Schläger-Physik
2. 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.

Klassendiagramm: Detailansicht der Model-Loop

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.

1. Reaktion auf Aktionen des Benutzers.
2. Reaktion auf Aktionen des Balls.

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/json/init.json
• web/js/lib/require/json.js
• web/js/lib/require/require.js
• web/js/lib/require/text.js

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, collisionCanvasBall, 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;
  }
);

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

Ball-View und Ball-Model

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/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.

Paddle

Schläger-Model und Schläger-View

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; } }
                     );
...

Text

Text-Model und Text-View

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 ([http://www.w3schools.com/tags/canvas_textalign.asp Aufhängepunkt}: left, center, right)
• textBaseline ([http://www.w3schools.com/tags/canvas_textbaseline.as 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

Button-Model und Button-View

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); „<code>model</code>“
}

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.

Kollisionserkennung und -behandlung

Hilfsprozeduren für 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

Model-Loop und View-Loop

ModelLoop: Konstruktor

function ModelLoop(p_collision, p_f, p_models)
{
  var l_seconds = 1 / p_f;
  this.milliseconds = 1000 * l_seconds;

  this.f_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();
    };
}

ModelLoop:Öffentliche Methoden

ModelLoop.prototype =
{
  start:
    function()
    {
      if (this.v_timer == null)
      { this.v_timer = setInterval(this.f_update_model, this.milliseconds) }
    },

  stop:
    function()
    {
       if (this.v_timer != null)
       {
         clearInterval(this.v_timer);
         delete this.v_timer;
       }
    }
};

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);
    };
}

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;
      }
    }
};

Initialisierung

Initialisierung der Web-Anwendung

function init(p_window, p_init)
{
  var l_canvas_init     = p_init.canvas,
      l_canvas          = p_window.document.getElementById("canvas"),
      l_document        = p_window.document,

      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),

      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];

  l_canvas.width  = l_canvas_init.width;
  l_canvas.height = l_canvas_init.height;

  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

MiniPong: Die Spiellogik

function minipong(p_init, p_models)
{
  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);

  // 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]); }
  }

  // Collision detection and handling.
  function f_collision()
  {
    collisionBallPaddle(l_ball, l_paddle, function(){ l_score.value++; });
    collisionCanvasBall(l_stage, l_ball, f_stop);
    collisionStagePaddle(l_stage, l_paddle);
  }

  // Reset the game.
  function f_reset()
  {
    l_score.value = 0;
    l_info.value  = '';
    l_ball.reset();
    l_paddle.reset();
  }

  // Start the game.
  function f_start()
  {
    f_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();
  }

  // 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;
  }

  // Stop the game and display a welcome message.
  f_stop();
  l_info.value = p_init.welcome;
}

Quellen

1. 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)
2. Kowarschick (MMProg): Wolfgang Kowarschick; Vorlesung „Multimedia-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 3 (Vorlesung)