一些学习OpenGL的开源项目

= Einleitung = Dieser Artikel soll in mehreren Etappen an das Thema Spieleentwicklung heranführen. Eine allgemeine Einführung in die Thematik bildet dabei den Grundstock. Diese soll Grundbegriffe und Mechanismen überlicksartig erklären. Anschließend werden die einzelnen Teilaufgaben bei der Entwicklung eines Spiels erklärt. Die so erarbeiteten Themen werden abschließend in eine kleine Space Invaders Variante gegossen. Als kleine Vorwarnung: Ich schreibe seit ca. 10 Jahren kleinere und größere Spiele. Meine Herangehensweise ist sicher nicht die optimalste. Auch können mir im Rahmen dieses Artikels faktische Fehler unterlaufen, ich werde aber versuchen diese zu minimieren. Auch werde ich wo angebracht Anglizismen verwenden da diese das googlen nach weiterführendem Material erleichtern. Auch werde ich einige Wikipedia Links einbauen für Begriffe die man eventuel Nachschlagen möchte. Los geht's. = Was muss ich vorab wissen? = In diesem Artikel setze ich ein paar Dinge als Minimum vorraus. Keine Angst, höhere Mathematik gehört nicht dazu :) * [http://www.mindview.net/Books/TIJ/ Java] * Handhabung von [http://www.eclipse.org/ Eclipse] * Installiertes [http://developer.android.com/sdk/index.html Android SDK] sowie [http://developer.android.com/sdk/eclipse-adt.html Eclipse Plugin] * [http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle Activity Life Cycle] * [http://developer.android.com/guide/developing/eclipse-adt.html Erstellen eines neuen Android Projekts in Eclipse] Den Code zu diesem Tutorial könnt ihr euch per SVN von der Addresse http://android-gamedev.googlecode.com/svn/trunk/ holen. Im Projekt gibt es eine Main Activity die euch gleich wie in den SDK Demos eine Liste an Applikationen zeigt. Einfach das Projekt aus dem SVN auschecken, in Eclipse importieren und eine Run Configuration anlegen und die Default Launch Activity starten. = Wo fang ich an? = Am Anfang jedes Spiels steht eine Idee. Wird es ein Puzzler? Ein Rundenstrategiespiel? Ein First-Person-Shooter? Auch wenn diese Genres unterschiedlicher nicht sein könnten, so unterscheiden sie sich im Grunde ihres Daseins oft wenig. Ein Spiel kann in mehrere Module zur Erledigung diverser Aufgaben eingeteilt werden: * '''Applikationsgerüst''' * '''Eingabe Modul''' * '''Datei I/O Modul''' * '''Grafik Modul''' * '''Sound Modul''' * '''Netzwerk Modul''' * '''Simulations Modul''' Im folgenden wollen wir uns mit diesen 6 Modulen etwas genauer beschäftigen. == Applikationsgerüst == Das Applikationsgerüst stellt die Basis für das Spiel dar. In der Regel ähnelt dieses herkömmlichen Applikationsgerüsten nicht. Spiele sind in den meisten Fällen nicht Event-basiert, d.h. sie laufen ständig, zeichnen dabei die Spielwelt permanent neu, holen sich dauernd neuen User Input und simulieren die Welt (für Kartenspiele und Ähnliches muss dies natürlich nicht gelten). So man nicht gerade für eine Konsole programmiert, stellt sich einem jedoch das Problem, dass die meisten Betriebssystem Event-basierte Programmierung als Paradigma gewählt haben. So auch auf Android. Applikationen werden dabei nur bei Bedarf neu gezeichnet, zum Beispiel wenn der User Text eingibt, einen Button drückt und so weiter, beziehungsweise wird Code nur dann ausgeführt wenn es eine User-Eingabe gibt. Im Allgemeinen hebelt man dies aus, indem man einen seperaten Thread startet der das Betriebssystem veranlasst die Applikation permanent neu zu zeichnen. In diesem Thread befindet sich so gut wie immer eine Schleife, auch Main Loop genannt, innerhalb derer sich immer das selbe abspielt (stark vereinfacht): while( !done ) { processInput( ) simulateWorld( ) renderWorld( ) } Wie genau dieser Main Loop ausschaut hängt von vielerlei Faktoren ab, zum Beispiel dem verwendeten Betriebssystem, dem Spiel selbst und so weiter. Im Rahmen dieses Artikels werden wir sehen wir man dieses Konzept äußerst einfach auf Android implementieren kann. == Eingabe Modul == Um dem Spieler die Möglichkeit zu geben in das Spielsystem einzugreifen müssen dessen Eingaben irgendwie gelesen werden. Diese Aufgabe übernimmt das Eingabe Modul. Tastaturen, Mäuse, Touch-Screens, Joysticks, Gamepads und einige andere exotische Möglichkeiten stehen hier zur Verfügung. Wie man an die Eingabe kommt ist dabei wieder Betriebssystem-abhängig. Android verfügt über einige Eingabe Möglichkeiten. Wir werden uns mit den wichtigsten zwei beschäftigen: dem Touch-Screen sowie dem Accelerometer. == Datei I/O Modul == Alle Resourcen eines Spieles müssen in irgendeiner Form der Applikation zugänglich gemacht werden. In speziellen Fällen kann das Spiel diese On-the-fly zur Laufzeit prozedural selbst erstellen, meistens liegen diese aber in Form von Dateien auf einem Datenträger vor. Auch hier gibt es verschiedene Möglichkeiten der Ablage: Dateien können schön geordnet in Ordnern abgelegt werden, wild in einem einzigen Ordner gespeichert sein oder gar in einem Zip-File fein säuberlich gepackt vorliegen. Das Datei I/O Modul soll dies abstrahieren damit im Programmcode der Zugriff auf die Resourcen erleichtert wird. Android bietet hier schon einen netten Ansatz mit seinem Resourcen und Asset System auf das wir später noch zu sprechen kommen werden. == Grafik Modul == In unseren modernen Zeiten ist für viele Spieleentwickler dieser Teil eines Spiels wohl der wichtigste (teils zu Lasten des Spielspaßes). Dieses Modul übernimmt die Darstellung sämtlicher grafischen Inhalte des Spieles, sei dies das User Interface, welches in der Regel zweidimensional ist oder die Spielewelt selbst, meist in der dritten Dimension. Da letzteres oft rechenintensiv ist, wird spezielle Hardware verwendet um das ganze zu beschleunigen. Die Kommunikation mit dieser Hardware, ihr klar zu machen wie wo was gezeichnet werden soll, sowie die Verwaltung von grafischen Resourcen wie [http://en.wikipedia.org/wiki/Bitmap Bitmaps] und Geometry (auch [http://en.wikipedia.org/wiki/Polygon_mesh Meshes] genannt) ist die Hauptaufgabe dieses System. Hierunter fallen auch Dinge wie das Zeichnen von [http://en.wikipedia.org/wiki/Particle_system Partikel-Effekten] oder der Einsatz von sogenannten [http://en.wikipedia.org/wiki/Shader Shadern] (auf Android noch nicht möglich). Ganz allgemein kann festgehalten werden das die meisten Objekte die simuliert werden auch eine grafische Entsprechung haben. Meiner Erfahrung nach ist es äußerst hilfreich die simulierte Welt komplett unabhängig von der grafischen Darstellung zu machen. Das Grafikmodul holt sich lediglich Information von der Welt-Simulation, hat aber auf diese keinen Einfluss. Wem das etwas zu wage ist: keine Angst der Zusammenhang sollte spätestens beim Entwickeln des Space Invader Clones erkenntlich werden. Es sei jedoch gesagt, dass dieser Ansatz es erlaubt das Grafik Modul beliebig aus zu tauschen, zum Beispiel statt einer 2D Darstellung das ganze auf 3D zu portieren, ohne dass dabei der Simulationsteil geändert werden müsste. Aufmerksamen Lesern ist vielleicht der Zusammenhang zwischen dem Grafik Modul und dem Main Loop bereits aufgefallen. Neuste Grafikkarten wird meist mit Benchmarks zu Leibe gerückt die die sogenannten Frames per Second (kurz FPS) oder [http://en.wikipedia.org/wiki/Frames_per_second#Frame_rates_in_video_games Frame Rate] messen. Diese geben an wie oft der Main Loop in einer Sekunde durchlaufen wurde. Es wird also gezählt wie oft der Main Loop (Input verarbeiten, Welt simulieren und das ganze dann zu zeichnen) in einer Sekunde durchlaufen wird. Im Zuge unserer Unternehmung werden wir immer ein Auge auf die Frame Rate werfen um etwaige Bottlenecks in unserem Spiel identifizieren zu können. Später werden wir sehen wie wir Android 2D und 3D Grafiken über [http://en.wikipedia.org/wiki/OpenGL OpenGL ES] entlocken können. == Sound Modul == Soundeffekte und Musik gehören zu jedem guten Spiel. Dementsprechend kümmert sich das Sound Modul um das A