Spiele: Hat wahrscheinlich jeder schonmal gemacht, die meisten wahrscheinlich auch schonmal auf dem Computer, einige auch auf ihrem Android-Device.

Spielen ist das Eine, Spiele entwickeln das Andere. Und Spiele machen für die Android-Plattform ist auch nochmal was anderes. Im wesentlichen kann man dabei Spiele mit Animationen, also alle Spiele, bei denen sich etwas bewegt, oder Spiele ohne Animationen, zum Beispiel textbasierte Spiele, unterscheiden. Ich will hier auf erste eingehen.

Animierte Spiele können in Android entweder in 2D mit Hilfe von Canvas und SurfaceViews oder in 3D mit Hilfe von OpenGL ES geschrieben werden. Dabei sind mit OpenGL ES auch 2D-Spiele ohne weiteres möglich. Bei der Entscheidung OpenGL ES oder nicht sollte man sich darüber im Klaren sein, dass OpenGL die wahrscheinlich anspruchsvollere Variante ist, da mehr mit Matrizen und Vektoren umgegangen werden muss als in Canvas-basierten Spielen und die dritte Dimension durchaus einen Unterschied macht. Für  OpenGL ES – basierte 2D – Spiele kann man sich zum Beispiel die andengine anschauen (sehr zu empfehlen).

Worüber ich jetzt schreiben werde hat aber weder mit OpenGL ES, noch mit Canvas-basierten Spielen zu tun, es ist etwas genereller, es geht um Loops und Threads.

Generell heißt es, dass ein Spiel eine main Loop haben soll. Diese main Loop ist eine Schleife in der alles geschieht, was sich um die Animation (Rendering), Simulation und Eingabenverarbeitung dreht und die so lange läuft wie das Spiel selber. Das heißt zum Beispiel: ein ball ist in der Mitte des handys, die main Loop macht eine weitere Iteration, stellt dabei fest, dass das Handy nach rechts geneigt wurde, weshalb in der Simulation berechnet wird, dass der Ball drei Pixel weiter rechts dargestellt werden soll, was dann in der Animation gezeichnet wird. Diese generelle Aussage ist falsch oder sollte zumindest so nicht umgesetzt werden.

Das Stichwort heißt Nebenläufigkeit: Anstatt in einem einzigen Thread alles auszuführen sollte klar zwischen den drei Spielelementen, Eingabeverarbeitung, Simulation und Rendering, getrennt werden.

Zunächst einmal zum Rendering-Thread: In diesem wird alles gezeichnet. In OpenGL macht man das ganz einfach, indem man das Interface GLSurfaceView.Renderer implementiert und dann alles in der onDraw()-Methode malen lässt, OpenGL ES kümmert sich dann um einen eigenen Thread. Bei SurfaceViews schaut man sich am besten auf dem offiziellen Blog und im SDK-Beispiel LunarLander um. Das Rendern auf normalen Views ist für viele Zwecke viel zu langsam, weshalb hier nicht näher darauf eingegangen wird.

Als nächstes benötigt man einen Thread, der sich um die Simulation kümmert, das heißt der alle Objekte, deren Verhalten und Position verwaltet.

Als drittes müssen noch die Eingabemethoden ausgelesen werden. Legt man die Werte aus diesen nicht in plain old dataobjects ab (was man aber oft tut), muss hier beim Zugriff auf die Threadsynchronisation geachtet werden.

Das gilt auch für den Zugriff auf die Simulationsobjekte: Auf diese wird sowohl vom Simulationsthread, der diese berechnet, als auch vom Renderingthread zugegriffen, es ist also für Synchronisation zu sorgen! Das bedeutet: Wenn ein Thread eine Methode oder ein Objekt, die oder das als synchronized gekennzeichnet ist, bearbeiten will, kann er das nur, wenn das kein anderer Thread tut.

Hier ein konkretes Beispiel, im Simulationsthread:

final List<GameObject> objects = simulation.objects;

for(int i=0; i++; i<objects.size()){
     GameObject object;
     synchronize(object){
        object.update(deltaTime);
     }
}

und im Rendering Thread:

final List<GameObject> objects = simulation.objects;

for(int i=0; i++; i<objects.size()){
     GameObject object;
     synchronize(object){
        //in diesem Fall wird eine GLSurface View übergeben.
        //es wäre auch möglich das Rendering außerhalb des
        //GameObjects durchzuführen, z.B. in einer Renderer-Klasse.
        object.render(gl);
     }
}

Eigentlich alles ziemlich einfach, oder?

Wir iterieren zum Einen im Simulationsthread einmal über alle Simulationselemente, dies machen wir mit einer normalen for-schleife, weil diese bei Listen performanter sind als foreach-Konstrukte. Wir übergeben einer update-Methode aller Spielelemente eine delta-Zeit und das war’s. Die Deltazeit bezeichnet dabei die Zeit, die seit dem letzten Zeichnen des Bildschirms vergangen ist. Somit kann gewährleistet werden, dass ein Objekt sich immer in der gleichen Zeit gleich weit bewegt, auch wenn unterschiedlich viele Frames pro Sekunde gezeichnet werden können. In der Update-Methode der jeweiligen Spielobjekte muss dann alles berechnet werden, was das Verhalten des Objekts ausmacht, wie zum Beispiel die Position.

Im Rendering-Thread das Selbe: Eine Iteration über alle Spielelemente, wobei jedes Element über eine render()- Methode verfügt, die mit einer übergebenen GLSurfaceView umgehen kann und sich selbst darauf zeichnet. Das funktioniert natürlich auch mit normalen Views oder SurfaceViews. Hier wird auch die Wichtigkeit von Synchronisation deutlich: Stellt Euch vor ein GameObject hätte eine Position{x,y,z}. Gerade als der Rendering-Thread ein Objekt zeichnen will und bereits x und y verarbeitet hat, manipuliert der Simulationsthread den z-Wert, weshalb das Objekt an einer ganz anderen Stelle gezeichnet wird als es eigentlich vorgesehen gewesen wäre. Darum wird das Objekt während es gezeichnet wird einfach von gelockt, weshalb die Simulation nicht mehr darauf zugreifen kann bis das Malen abgeschlossen ist.

Fehlt nur noch… Die Nutzereingabe, richtig! Diese wird normalerweise gepollt, d.h. man fragt zum Beispiel immer nach dem Ort, auf den der Nutzer das letzte mal gedrückt hat ab. Wenn sich dieser nicht verändert hat, bewegt man zum Beispiel eine Figur dort hin, wenn er sich verändert hat, bewegt man sie zu dem neuen Punkt.

So viel zur generellen Theorie der Spielentwicklung. Wirkt eigentlich gar nicht so schwer, muss es auch nicht immer sein. Teil zwei wird ein kurzes praktisches Beispiel der obigen Theorielektion auf Basis einer SurfaceView sein, lasst Euch überraschen.