Selbstbauanleitung: RetroShooter mit HTML5 | Teil 1

Norman erzählt in einer kleinen Selbstbauanleitung, wie man ein Game in HTML 5 programmiert. Hier ist der erste Teil:

Es war einmal ein kleiner Nerd, der nicht schlafen konnte. Es war morgens um zwei, er war noch immer nicht müde und da dachte er sich, programmiert er sich doch mal nen Retro-Shooter. Und weil der kleine Nerd sich gern nach außen kommuniziert, schreibt er nun diese Artikelreihe für euch.

Fangen wir erstmal mit den grundlegenden Dingen an. Es gibt ja nun das tolle Ding, das alle HTML5 nennen. Gemeint ist damit eigentlich die ganze Reihe der Standard-Webtechnologien, nämlich HTML, CSS und Javascript. Das tolle daran ist, dass sich bei allen dreien in letzter Zeit so unglaublich viel tut. Somit ist nun mit modernen Browsern vieles möglich, das vorher Flash brauchte: Musik und Videos abspielen und sogar Spiele!

Vorallem letzteres geht dank des neuen Canvas-Elements. Das Canvas – zu deutsch Leinwand – stellt für den Programmierer das Gleiche dar, wie für einen Künstler: Man kann darauf malen, was man will. Leider hat man auch die selben Beschränkungen: Malt man etwas darauf, ist es nicht einfach markier- und verschiebbar. Aber dazu komm ich später, denn in der ersten Ausgabe soll es nicht nur eine Einleitung und Grundlagen-Bla geben sondern auch ein wenig Inhaltliches.

Wie programmiert man ein Spiel?

Erstmal ein wenig Theorie. Ein Spiel programmiert sich ja nun nicht einfach so, man muss schon wissen, wie man dem Computer trotz seines begrenzten Verständnisses klar macht, was man will.

Die wirklich komplexen Titel benutzen dafür natürlich eine fertige Engine. Früher – also ganz früher – war das noch nicht so unbedingt der Fall. Der Commodore-Freak hat sich einen kleinen Vertical-Shooter durchaus auch einfach so runter geschrieben.

Und genau das ist auch mein Plan.

Was ist eine Engine?

Hauptaufgabe des Spielemotors ist es, Bilder zu generieren und an die Grafikkarte zu schicken – wenn möglich mindestens 30 Mal pro Sekunde. Was passiert, wenn es weniger oft klappt, kennen wir: Es ruckelt und zuckelt. Sicher, bei einem Vertical Shooter der altmodischen Art, tun es auch zwanzig Bilder die Sekunde, aber man muss ja nicht alles altbacken angehen. Das Bild am Ende auf die Leinwand zu bringen kann man auch wieder unterschiedlich umsetzen.

Single Buffering, Double Buffering, Triple Buffering?

Zwei der typischen Bekannten erscheinen hier sinnvoll: Direkt auf die Leinwand malen oder im Hintergrund auf eine versteckte Leinwand malen und diese dann auf die gezeigte kopieren. Letzteres nennt man Double Buffering. Man kann das sogar noch zuspitzen und eine weitere versteckte Leinwand nutzen. Das ist dann Triple Buffering. Inwiefern dreifaches Puffern des Bildes Vorteile gegenüber dem zweifachen bringt, weiß ich nicht, aber zweifaches Schreiben ist vorallem dann von Nutzen, wenn das eigentliche Zeichnen zu langsam vonstattengeht und dadurch ein Flimmern erzeugt.

Aber wie jetzt nun malen?

Das eigentliche Malen kann man sich für ein Programm natürlich nicht ganz so vorstellen, wie für einen Menschen – selbst wenn dieser ein Programm dazu verwendet. Wir müssen uns damit zufrieden geben, sogenannte Primitive zu verwenden. Das sind beim Canvas Linien, Vierecke und Kurven. Daraus kann man alles generieren, was man sich nur wünschen kann, wenn man nur abstrakt genug herangeht.

Will man also zum Beispiel ein Raumschiff von unten in der Mitte gerade nach oben fliegen lassen, springt man an einen Eckpunkt, an dem man mit dem Zeichnen der Linien beginnen will und zieht dann Linien oder Kurven, bis man sich ein Wunschraumschiff zusammengebastelt hat. Um es zu bewegen, beginnt man beim nächsten mal ein bisschen weiter oben und das so lange, bis es das gewünschte Ziel erreicht hat.

Das Ganze kann man natürlich auch mit mehr als einem Raumschiff machen. Diese können auch in unterschiedliche Richtungen fliegen. Es müssen ja nicht mal Raumschiffe sein. Genausogut, kann man so auch Projektile verschießen und Power-Ups erscheinen lassen.

Renderfunktion

Damit alles vernünftig der Reihe nach abläuft, lässt man es nacheinander in einer einzigen Funktion passieren, die möglichste alle 33 Millisekunden durchläuft, um die gewünschten 30 Bilder pro Sekunde zu erreichen. Weil man aber nicht so genau einschätzen kann, wie lange die Funktion nun wirklich im Einzelnen braucht, verzichtet man auf einen generischen Aufruf, der sie in einem strikten Zeitrahmen aufruft, sondern lässt die Funktion ihre Laufzeit messen und sich dann selbst wieder nach einer Zeitspanne aufrufen, die dann auf die Laufzeit addiert möglichst 33 Millisekunden ergibt.

Das klingt jetzt alles vielleicht total kompliziert, aber ist es überhaupt nicht. Man hält nur am Anfang von allem die aktuelle Zeit fest und zieht dann nach all der Malerei diesen Wert von der nun aktuellen Uhrzeit ab und schon hat man, was man braucht.

Ist ein Spiel nicht noch viel mehr als nur Malerei?

Natürlich gehört noch mehr dazu, als nur einfach irgendwo herumzumalen, schließlich wollen wir keinen Film animieren, sondern etwas Interaktives schaffen. Dazu müssen wir Tastatur-Eingaben auslesen, Kollisionen abfragen, Level, Leben und Punkte zählen. Das alles erwartet dich im dritten Teil dieser Reihe.

Wann geht’s nun los? Ich will programmieren!

Im nächsten Teil werde ich nicht mehr weiter mit Theorie langweilen und direkt starten. Wir werden eine ganz einfache HTML-Seite mit einem Canvas-Element bauen und auch schon darauf malen – 30 Bilder pro Sekunde. Um die Langeweile bis zum nächsten Teil ein wenig zu mindern, habe ich mal ein paar nette Links zum Thema zusammen gesammelt:

http://www.squakenet.com/games-download/vertical-shooter
http://abstract-productions.net/game/shooter.html
http://www.codeproject.com/Articles/396959/Mario5