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

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.

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 Projekts 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

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

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

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

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 (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

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

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

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

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

Initialisierung der Web-Anwendung

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

MiniPong: Die Spiellogik

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

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)