Hallo ihr Lieben,
wie ich ja vor kurzem schon angekündigt habe, möchte ich hier mal so Stück für Stück ein paar Tutorials schreiben, wie man Browsergames entwickeln kann. Ich sage bewusst kann, denn es gibt so viele verschiedene Wege und Möglichkeiten, wie man heutzutage kleinere und größere Spiele programmieren bzw. entwickeln kann. Man muss teilweise nicht mal wissen, wie man genau programmiert.
Ein gutes Beispiel dafür ist z.B. der RPG-Maker, mit dem man, quasi per Drag & Drop Spiele erstellen kann, die man dann auch für den Browser exportieren kann.
Wir sollten uns aber kurz erstmal generell dazu ein Bild machen, was ich persönlich unter einem Browsergame verstehe. Viele verbinden mit Browsergames meistens MMOG oder MMORPG, bei denen dann eine Vielzahl von Spielern gleichzeitig in einer großen Welt agieren. Streng genommen würde ich aber sagen, zählen alle Spiele die eben über einen Browser spielbar sind, in diese Kategorie, da man eben nichts weiter als einen gängigen Browser braucht.
Sicherlich zählen also auch die MMOGs dazu. Aber eben auch kleine einfache Casualgames, wie ein einfaches Klickspiel, ein Rätselspiel oder sogenannte Idle-Games, bei denen man mehr oder weniger, nur die Zeit abwartet. Alles was irgendwo ein wenig Interaktion benötigt und zur Unterhaltung dient.
Es gibt natürlich auch noch die Sparte des Glücksspiels, von denen ich im Laufe der Jahre einige Hundert Spiele programmiert habe. Hier mit dieser Tutorial-Reihe, möchte ich aber genau davon wieder weg, hin zu den Anfängen. Denn zu Beginn, als ich meinen Gewerbeschein geholt habe, wollte ich immer Browsergames bauen, die nicht auf Glück basieren, sondern eher strategisch angelegt sind. Spiele bei denen es um Wirtschaft oder den Aufbau geht.
Wir werden hier aber jetzt erstmal ganz ganz klein und einfach anfangen mit ein paar Grundlagen, damit sich alle ein wenig rein finden können. Wem das alles zu langsam geht, weil er schon gewisse Grundkenntnisse hat, kann dann die entsprechenden "Kapitel" einfach überspringen.
Heute werden wir uns erstmal mit der Basis, dem HTML-Konstrukt einer Website beschäftigen, in der dann am Ende verschiedene Techniken wie normales HTML + CSS + JS eingesetzt werden oder eben spezielle Bibliotheken wie jQuery und Phaser. Ohne eine Basis und zu wissen, warum das Ganze so aufgebaut ist, fehlt aber einfach fundamentales Wissen. Das ist zumindest meine persönliche Einschätzung, nach ca. 20 Jahren Entwicklung.
Schauen wir uns also erst einmal den heutigen Aufbaue einer normalen Website an:
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf8">
<meta name="viewport" content="width=device-width">
<title>Browsergame-Tutorial Part 1</title>
</head>
<body>
Inhalt der Seite
</body>
</html>
</html>Das ist so ein Basis-Code, er beginnt mit einer Definition des DOCTYPE (Dokumenten-Typs) und gibt an, dass es sich um eine HTML 5 Website handelt. Die wir danach über einen aufgehenden TAG (ohne ein '/') für das eigentliche HTML-Dokument starten.
FAST(!) jeder TAG in HTML hat immer einen aufgehenden und eine abschließenden Kennung. Wie z.B. eben das 'html', 'head', 'body', 'title'. Es gibt aber auch ein paar Ausnahmen wie den meta-TAG und später mal z.B. input (hier gab es früher auch einen abschließenden, das macht man heute aber nicht mehr).
Wenn man sich dann den HTML-Bereich ansieht, wird man sehen, dass diese in einen KOPF ('head') und KÖRPER ('body') aufgeteilt ist. Der Kopf enthält quasi alle wichtigen Angaben zum Verhalten des Dokumentes aber kann auch Angaben zur Gestaltung (CSS), Daten für Facebook- und/oder Google-Integrationen enthalten etc.
Früher hat man auch das ganze JavaScript meistens dort hineingelegt, was man heute auf Grund von Ladezeiten der Seite, meist aber ans Ende des Körpers verlegt. Denn wir wissen heute ja, dass Google z.B. sehr auf schnelle Seiten abfährt und wir Menschen auch ungerne eine Website aufrufen, die erstmal 10 Sekunden laden muss.
Wir packen in unseren Dokumenten-Kopf also erst einmal ein paar Angaben zur Kodierung der Seite ('utf8'), die dafür sorgt, das wir auch die deutschen Umlaute wie ä,ü,ö und ein paar andere Sonderzeichen, einfach ganz frei im Text der Seite verwenden können.
Danach geben wir über die 'viewport' Angabe noch an, dass die Größe des Dokumentes sich auf die Größe beziehen soll, die uns das Gerät, auf dem wir die Seite abrufen vorgibt. Für Monitore, wird die Seite dann breiter sein, wie für ein schmales Smartphone bzw. passt sich die Skalierung entsprechend an.
Zu guter Letzt, fehlt dann nur noch die 'title'-Angabe im Kopf (zumindest vorerst) die dafür Sorge trägt, dass im Reiter des Browsers, der entsprechende Informationstext (Titel) unserer Seite steht.
Das wäre erstmal das Basiswissen in Bezug auf den Kopf einer HTML-Seite.
Der Körper als solches, hat in unserem Beispiel noch nicht wirklich viel Inhalt. Da wir ja erst einmal Schritt für Schritt anfangen wollen und es auch nicht zu viel werden soll.
Generell kommt in den KÖRPER ('body') alles das, was der Benutzer am Ende sehen können soll. In unserem Beispiel erstmal nur den Informationstext. Später kommen dann aber noch Knöpfe ('buttons'), Bilder, Videosequenzen etc. pp. hinzu.
Für den Anfang soll das erstmal aber zum HTML-Dokument reichen, da wir uns noch über ein paar andere Dinge Gedanken machen sollten. Die Seite so an sich, könnte man jetzt auch ohne eine entsprechende Server-Software schon über das File-Protokoll in einem Browser aufrufen. (Dazu einfach den Inhalt in eine leere Text-Datei kopieren und mit DATEINAME.html abspeichern und anschließen öffnen.) Später werden wir ggf. aber noch eine Server-Software einsetzen, da das HTTP-Protokoll, war jeder von uns täglich im Browser benutzt einfach mehr Möglichkeiten bietet, da die Browser die Seite dann anders interpretieren können.
Kurz gesagt, das File-Protokoll ermöglicht das Laden von Internetseiten auf dem eigenen PC. So kann man kleinere Seiten einfach laden und anschauen. Will man aber "mehr" machen können, nutzt man eine Server-Software, wie z.B. Apache oder NGINX, die in der Lage sind das HTTP-Protokoll oder z.B. PHP zu interpretieren und verarbeiten.
Wir werden in der ersten Zeit aber rein das HTTP-Protokoll ohne PHP oder ähnliches einsetzen, da wir sehr viel direkt interaktiv über JavaScript in die Seite integrieren und so auch Daten erstmal ganz simple und einfach auf der Festplatte speichern und laden können.
Später wenn es mit PHP soweit ist, können wir die Daten dann aber auch noch verschlüsseln oder z.B. in einer "Cloud" bzw. auf einem externen Server abspeichern. Dann sind die Daten "besser" geschützt bzw. schwerer zu entschlüsseln und vor allem auch noch mal doppelt abgesichert.
Wir sollten jetzt aber noch einmal kurz darauf eingehen, was euch hier später erwarten wird. Denn ihr merkt schon, ich kann euch eine ganze Menge erzählen, wenn es um Spiele und Entwicklung geht und möchte / werde hier auch noch sehr viel berichten und ein wenig aus dem "Nähkästchen" berichten.
Z.B. werde ich euch mit der Zeit auch verraten, wie man mit einfachen kleinen Spielen, Geld im Internet verdienen kann, welche Grauzonen es in Deutschland gibt, in Bezug auf "Glücksspiel im Internet" und welche Plattformen man nutzen kann, um eigene Spiele und Scripte zu verkaufen.
Jetzt haben wir aber erstmal ein Grundgerüst, dass wir dann im nächsten Schritt erst einmal mit ein paar Buttons füllen werden, die wir dann interaktiv bedienen können. Wir werden sie also z.B. mit Klick-Events belegen oder über jQuery an ein Funktion binden.
Warum ich mit so etwas anfangen möchte, wenn es um die Entwicklung von Spielen geht, mag ich auch noch ganz kurz erklären.
Buttons gibt es in vielerlei Weisen. Normale rechteckige Knöpfe, einfach Bilder, unsichtbare Bereiche etc. die in jedem Spiel immer wieder dazu genutzt werden, um eben auf die Eingabe eines Spielers zu reagieren. Sei es um etwas zu bestätigen oder auch zum Abändern von Werten.
Wir werden aber irgendwann vermutlich nicht daran vorbei kommen, für unsere Spiele ein Menü zu bauen, wo man dann halt neue Level anwählen oder Spielstände laden/speichern kann. Daher zählen vor mich, diese Buttons, zu einer der wichtigsten Grundlagen, wenn es um Spiele geht.
Andere wichtige Grundlagen, bei 2D-Spielen zumindest, wird das Laden und Anzeigen von Grafiken und das darstellen von Textinformationen oder Zahlen werden. Das wird man bei Punkteständen, Ressourcen-Anzeigen etc. immer wieder brauchen.
Da ich jetzt aber gerade gefühlt einen halben Roman geschrieben habe, werde ich jetzt erstmal durchatmen und auf euer Feedback warten.
Mich würde interessieren, ob es für euch in Ordnung ist, dass ich euch all meine Gedanken dazu so nieder schreibe. Ob es besser wäre, ich konfrontiere euch einfach hart mit Fakten? Vielleicht hab ich aber auch etwas weggelassen, wo ihr genauere Informationen haben möchtet.
Schreibt mir doch einfach mal (wenn ihr ja eh schon so weit gelesen habt), in die Kommentare, was ihr darüber denkt.
===================================================
Unsere selbst produzierten Malbücher:
MPIOs Malbuch
Tierische Weihnachten
Hilf mit weitere tolle Bücher zu schaffen:
Patreon
Vielen lieben Dank, dass du mein Posting, bis zum Ende durchgelesen hast!