So, weiter geht’s mit der Android Spieleentwicklung. Eigentlich wollte ich nur zwei Tutorials schreiben- Theorie und Praxis- habe mich jetzt aber doch entschlossen, den Praxisteil deutlich umfangreicher zu gestalten. Dabei werde ich mit Euch zunächst die Grundlagen für ein Canvas basiertes 2D-Spiel schaffen und anschließend darauf ein Spiel aufbauen. Dabei werden wir eine Client- und eine Serverseite, basierend auf der Google App Engine, implementieren, Das Tutorial wird sich deshalb noch über einige Wochen hin strecken.
Heute implementieren wir erstmal die praktische Grundlage und schreiben dafür eine abstrakte Basisactivity, die zwei Threads verwaltet (einen für das Rendering, einen für die Simulation) und Touchevents und Beschleunigungen wahr nimmt. Außerdem entwerfen wir ein Listenerkonzept, mit dem die Klasse einfach genutzt werden kann.
Für denjenigen der oder diejenige die nicht weiß, worum es bei den im vorherigen Satz genannten Dingen geht, zumindest theoretisch, und/oder noch keine Kenntnisse in Java besitzt, ist dieses Tutorial wahrscheinlich nicht sehr hilfreich. Wer anderer Meinung ist kann’s trotzdem probieren. Los geht’s!
Zunächst einmal grundlegendes zum Android-Stil:
- Member Variablen (globale Variablen) werden mit einem m am anfang geschrieben, also zum Beispiel mVariable.
- Statische Variablen mit einem s
- Felder (static final …) werden groß geschrieben und Wörter mit Unterstrichen (_) getrennt, wie sonst auch in Java üblich.
- Methoden werden in der Zeile ihrer Deklaration geöffnet (void testMethode(){ … anstatt void testMethode
{ …).
- final ist ein gutes Wort wenn eine Variable nicht nochmal verändert werden soll.
- Nicht private Variablen sollten mit Javadoc dokumentiert sein, Methoden auch (wie auch sonst in Java).
- Außer die Benennung ist absolut selbsterklärend, das ist aber selten der Fall (auch bei Gettern und Settern).
- Methodenzugriffe kosten (Rechen) Zeit und die ist auf Mobilen Geräten knapp.
- Der Garbagecollector sollte Während des Spielbetriebs so selten angeworfen werden müssen wie möglich, sonst kann es zu Rucklern kommen.
Nachdem das gesagt ist geht’s gleich los:
Zunächst einmal erstellen wir eine neue abstrakte Klasse die von Activity ableitet, ich habe sie passenderweise GameActivity genannt.
public abstract class GameActivity extends Activity
Wie bei Activities üblich überschreiben wir onCreate(). Dabei initialisieren wir zunächst eine member Variable vom Typ SurfaceView, auf die wir später alles malen werden. Anschließend holen wir uns von der SurfaceView über getHolder() den zugrunde liegenden SurfaceHolder. Über diesen ist es uns möglich, die SurfaceView zu verändern. Anschließend fügen wir dem Holder die eigene Klasse als Callback hinzu (addCallback()). Dazu müssen wir das Interface SurfaceView.Callback implementieren, was uns zu den Methoden surfaceChanged(), surfaceCreated() und surfaceDestroyed() zwingt. Die Namen sind ziemlich selbsterklärend. In surfaceCreated() und surfaceDestroyed() werden wir weiter unten etwas hineinschreiben, surfaceChanged(), was zum Beispiel aufgerufen wird wenn das Handy gedreht wird, behandeln wir nicht. Wir setzen die SurfaceView-Instanz als Content View.
Als nächstes erstellen wir in onCreate() zwei Threads, einen für die Simulation, einen für das Rendering:
mRenderingThread = new Thread(new Runnable(){
public void run() {
render();
}
}, "Rendering Thread");
mSimulationThread = new Thread(new Runnable(){
public void run() {
simulate();
}
}, "Simulation Thread");
Das sind die beiden im Theoriekapitel beschriebenen Threads. Gar nicht so kompliziert. Wie Ihr an den Namen erkennen könnt handelt es sich bei den Threads um globale Variablen, da wir sie später aus einer anderen Methode heraus wieder beenden können wollen. Das ist erstmal alles was wir in onCreate() machen.
Jetzt zum Listener-Konzept. Wir benötigen zwei Interfaces, eines für die Simulation und eines für das Rendering.
Dem SimulationListener geben wir drei Methoden: initializeSimulation(), simulationIteration(float delta) und isInitializingSimulation(). Die erste dieser Methoden dient dazu, alles zu laden was für die Simulation notwendig ist, Daten vom Server oder aus einer Datenbank zum Beispiel. Wenn das Laden abgeschlossen ist muss isInitializingSimulation() false zurückgeben. So weiß unsere abstrakte Basisactivity dass das Laden der Simulation abgeschlossen ist und mit dem Durchlaufen der Simulation begonnen werden kann. Dafür wird simulationIteration(float delta) genutzt. Delta ist die Zeit in Sekunden, die seit der letzten Simulationsiteration vergangen ist. So kann sichergestellt werden dass sich alle Spielgegenstände immer gleich schnell bewegen, unabhängig von der geschwindigkeit mit der die Simulationsiterationen durchlaufen werden und auch unabhängig von der Zahl der Frames pro Sekunde. Diese Technik nennt sich Frame Rate Independent Movements, ein Name der hier nicht so recht passt; näheres kann hier nachgelesen werden.
Der RenderingListener, auch ein Interface, erhält die Methoden render(Canvas canvas), initializeRendering() und isInitializingRendering(). Darüber hinaus bekommt er noch die Methoden renderSplash(Canvas canvas) und initializeSplash(). Die ersten drei Methoden machen das Gleiche wie der SimulationListener auch. render(Canvas canvas) bekommt dabei ein Canvas-Objekt übergeben, auf das der Listener dann alle Spielgrafiken zeichnen kann. Die beiden letztgenannten Methoden sind dafür da, einen Splashscreen oder Ladebildschirm zu laden und zu zeichnen. initializeSplash() sollte dabei so schnell wie möglich durchlaufen werden damit der Nutzer nicht denkt dass das Spiel hängt. Sobald isInitializingRendering() und isInitializingSimulation() false zurück geben ist das Laden abgeschlossen und es kann zum Spielablauf mit render(Canvas canvas) übergegangen werden.
Um die Listener auch setzen zu können müssen wir auch noch jeweils einen Setter implementieren, was eigentlich kein Problem sein sollte.
Mit dem obigen gesagt ist auch schon klar, was die beiden Threadmethoden simulate() und render() machen. Fangen wir bei der Umsetzung mit simulate() an:
private void simulate(){
if(mSimulationListener != null){
mSimulationListener.initializeSimulation();
}
while(mMainLoopRunning){
if(mSimulationListener != null
&& !mSimulationListener.isInitializingSimulation()
&& mRenderingListener != null
&& !mRenderingListener.isInitializingRendering()){
mDeltaTime = (System.nanoTime() - mLastSimulationIteration)
/ 1000000000.0f;
mLastSimulationIteration = System.nanoTime();
mSimulationListener.simulationIteration(mDeltaTime);
}
}
}
Zuerst führen wir die Initialisierung der Simulation durch. Ist das erledigt geht die main Loop der Simulation los. Das aber nur, wenn auch alle für das Rendering notwendigen Dinge bereits geladen wurden. Wir wollen ja nicht dass das Spiel schon los geht bevor der User überhaupt irgend etwas sieht. In der main Loop messen wir die delta Time. Wie ihr seht benötigen wir dafür zwei weitere Member. Wir ziehen einfach von System.nanoTime() den Zeitstempel der letzten Iteration ab und teilen das Ergebnis durch eine Milliarde um von Nanosekunden auf Sekunden zu kommen. Nun setzen wir den Zeitstempel auf die aktuelle Zeit und rufen die simulationIteration(float delta) des SimulationListeners auf. So einfach ist das. Nun können Klassen die sich als SimulationListener bei unserer Basisactivity einhängen Entfernungen, Bewegungen, Kollisionen usw. in ihrer eigenen Methode simulationIteration(float delta) berechnen und das mit einer konstanten Geschwindigkeit, z.B. 100 Pixel pro Sekunde.
Machen wir mit der Methode render() weiter:
private void render(){
if(mRenderingListener != null){
mRenderingListener.initializeSplash();
}
new Thread(new Runnable(){
@Override
public void run() {
if(mRenderingListener != null){
mRenderingListener.initializeRendering();
}
}
}).start();
Canvas c;
while(mMainLoopRunning){
c = null;
try {
c = mSurfaceHolder.lockCanvas();
synchronized (mSurfaceHolder) {
if(mRenderingListener != null){
if(mRenderingListener.isInitializingRendering()
|| mSimulationListener == null
|| mSimulationListener.isInitializingSimulation()){
mRenderingListener.renderSplash(c);
} else{
mRenderingListener.render(c);
}
}
}
} finally {
if (c != null) {
mSurfaceHolder.unlockCanvasAndPost(c);
}
}
//the fps calculation
mFPSCount++;
mTimeElapsed += (System.nanoTime() - mLastRenderingIteration)
/ 1000000000.0;
if(mTimeElapsed >= 1){
mFPS = mFPSCount;
Log.d("GameActivity", "FPS: " + mFPS);
mFPSCount = 0;
mTimeElapsed = 0;
}
mLastRenderingIteration = System.nanoTime();
}
}
Etwas umfangreicher, etwa 30 Zeilen, aber auch nicht so kompliziert. Das Vorgehen ist ähnlich wie bei der Simulation. Als erstes initialisieren wir den Splashscreen. Das sollte, wie erwähnt, möglichst zügig passieren damit niemand warten muss. Anschließend initialisieren wir das Rendering. Das machen wir nebenläufig machen damit unser Ladebildschirm schonmal angezeigt werden kann. Dann deklarieren wir ein Canvas-Objekt und steigen auch schon in die Rendering main Loop ein. Der Teil mit der Canvas, der jetzt kommt, ist übrigens größtenteils dem LunarLander Codebeispiel entnommen. Zuerst einmal holen wir uns von unserem SurfaceHolder die aktuelle Canvas und sperren diese. Mit dem Sperren hat es auf sich dass die Canvas, wenn sie nicht gesperrt ist, verändert werden kann, auch von Elementen die wir nicht in unserer Hand haben. So stellen wir also sicher dass am Ende auch das auf dem Bildschirm erscheint, was wir wollen. Nun, da wir uns in einem Thread befinden und nicht wollen dass ein anderer Thread uns einen Strich durch die Canvas macht, synchronisieren wir noch unseren SurfaceHolder und geben anschließend unsere Canvas an den RenderingListener weiter. Je nachdem, ob alle für das Spiel notwendigen Elemente bereits geladen sind oder nicht, kriegt entweder renderSplash() oder render() die Canvas zum Malen überreicht. Abschließend entsperren wir unser CanvasObjekt wieder und posten es mit unserem SurfaceHolder auf den Bildschirm. Das machen wir in einem finally-Block, damit unsere Oberfläche, falls es beim Zeichnen in einer der Renderingmethoden zu Exceptions kommt, nicht in einem inkonsistenten Zustand bleibt.
Das war auch schon alles was das Rendering angeht.
Abschließend sollen noch die Frames pro Sekunde gezählt werden.
Frames pro Sekunde (FPS) sagen aus wie viele komplette Bilder innerhalb einer Sekunde gezeichnet werden. Das menschliche Auge beginnt dabei ab etwa 24 FPS zu glauben, es handle sich um Bewegungen. Alles darunter ist zu langsam und sollte den Entwickler zum Nachdenken bringen. Zur Performanceoptimierung komme ich in einem anderen Kapitel. Die in Android maximale Anzahl von FPS liegt bei 61. Wenn man sein Spiel zwischen 50 und 61 FPS bringen kann, kann man sich schon sehr sicher sein dass es auf den meisten Geräten zuverlässig läuft (testen sollte man aber trotzdem).
Zurück zur Implementierung! In jeder Renderingiteration erhöhen wir ganz einfach einen Counter mFPSCount und zählen anschließend die seit der letzten Iteration vergangene Zeit in einer anderen Membervariable zusammen. Wenn diese zweite Variable größer gleich eins ist, ist eine Sekunde vergangen und die FPS können ausgegeben werden. Da man sie vielleicht auch noch anderswo als in der LogCat sehen will, habe ich auch noch einen Member mFPS erstellt, über den andere Klassen auf die aktuellen Frames pro Sekunde zugreifen können. Wir setzen den FPS-Counter und den Zeitnehmer zurück und halten den Zeitstempel der aktuellen Iteration fest. Fertig ist der Inhalt des rendering-Threads!
Würde man jetzt von der Activity ableiten, Listener einhängen und etwas schönes zeichnen wollen, würde nichts geschehen. Warum nicht? Ganz Klar: Die beiden Hauptthreads wurden ja noch gar nicht gestartet. Aber wo machen wir das am besten? Den simulation-Thread können wir schon in der onCreate()-Methode starten. Mit dem rendering-Thread ist das anders, der muss erst darauf warten dass die SurfaceView, auf der er zeichnen will, bereit ist. Da war doch was… Wir hatten ja das Interface SurfaceHolder.Callback implementiert, das uns eine Methode surfaceCreated() zur Verfügung stellt. Allem Anschein nach der richtige Punkt um das Rendering anzustoßen. Der Einfachheit halber habe ich an dieser Stelle auch den Simulationsthread gestartet. Wie Ihr, wenn Ihr aufmerksam wart, sicherlich bemerkt habt, gibt es in den main Loops der beiden Threads noch eine Variable mMainLoopRunning. Diese müssen wir also auch noch auf true setzen, bevor wir die Threads starten.
Jetzt können wir ein Spiel zum laufen bringen. Aber manchmal, auch wenn das Spiel noch so schön ist, will man es auch wieder beenden. Glücklicherweise stellt das Interface SurfaceHolder.Callback auch noch die Methode surfaceDestroyed() zur Verfügung, in der wir die beiden Threads stoppen können. Das sieht dann für den rendering-Thread so aus:
mMainLoopRunning = false;
boolean retry = true;
while (retry) {
try {
mRenderingThread.join();
retry = false;
} catch (InterruptedException e) {
}
}
Wir stoppen einfach den rendering-Thread indem wir join() aufrufen. Wenn es dabei zu einer Exception kommt, versuchen wir es einfach nochmal, solange bis es gut geht. Mit dem Simulationsthread machen wir das Selbe, und schon können wir ein Spiel sowohl starten als auch beenden.
Jetzt haben wir alle Komponenten beisammen um eine Spiel zu zeichnen. Fehlt noch die Eingabe. Alle Geräte, die den Android Market nutzen wollen, müssen über mindestens einen Beschleunigungssensor und einen Touchscreen verfügen. Also kümmern wir uns darum, dass wir diese beiden sicheren Eingabemethoden nutzen können.
Um auf Touch Events reagieren zu können implementieren wir das Interface OnTouchListener, wodurch wir dazu gezwungen werden, die Methode boolean onTouch(MotionEvent event) zu implementieren. Den Listener hängen wir in unserer onCreate() – Methode in unsere SurfaceView ein. Nun wird onTouch() bei jedem Drücken auf unsere Spieloberfläche aufgerufen. Das MotionEvent das dabei übergeben wird, enthält dabei einige wichtige Informationen. Wir verarbeiten von diesen Informationen die Art und die Position des Events. Damit auch ableitende Klassen darauf zugreifen können, erstellen wir darum die drei Membervariablen mIsTouched, mTouchX und mTouchY.
Wenn unser MotionEvent (über die Methode getAction()) nun die Information beinhaltet, dass ein Drücken oder eine Bewegung eines Fingers auf dem Bildschirm stattgefunden hat, halten wir die Position fest und setzen mIsTouched auf true. Hat das Event die Action MotionEvent.ActionUp, so ist kein Finger mehr auf dem Bildschirm und wir setzen mIsTouched auf false. In code sieht das so aus (Getter und Setter nicht vergessen):
if(event.getAction() == MotionEvent.ACTION_DOWN
|| event.getAction() == MotionEvent.ACTION_MOVE){
mTouchX = (int)event.getX();
mTouchY = (int)event.getY();
mIsTouched = true;
}
if( event.getAction() == MotionEvent.ACTION_UP ){
mIsTouched = false;
}
return true;
Wenn mIsTouched true zurückgibt, befindet sich gerade ein Finger auf dem Bildschirm. Ist es false, befindet sich dort keiner. So können Bewegungen erkannt werden und Beispielsweise Objekte über das Spielfeld gezogen oder Pfade gezeichnet werden.
Nach den Touchevents bleibt uns nur noch eins zu tun, bevor wir mit unserer Basisactivity anfangen können Spiele zu schreiben. Wir sprechen die Beschleunigungssensoren an. Dafür brauchen wir mal wieder ein Interface um uns als Listener einzuhängen – ein Konzept, dass sich durch so ziemlich alles in Android durchzieht. Wir implementieren SensorEventListener und erhalten onAccuracyChanged() und onSensorChanged(SensorEvent event). Die erste dieser beiden Methoden ignorieren wir. Die zweite Methode wird aufgerufen, wenn der Beschleunigungssensor irgend etwas mitgekriegt hat. Wie schon zuvor enthält das Event die entsprechenden Informationen. Für das Weitergeben an ableitende Klassen erstellen wir das float-Array mAcceleration mit der Größe drei. Mit
System.arraycopy( event.values, 0, mAcceleration, 0, 3 );
Kopieren wir die Werte des Events ab der Position 0 in unser Array ab der Position 0, das die Länge 3 hat. Die drei Werte, die sich jetzt in unserem Array befinden, sind die der Beschleunigung auf der X-, Y- und Z-Achse im Raum. Auch diese geben wir über Getter nach außen weiter:
public float getAccelerationOnXAxis( ){
return mAcceleration[0];
}
Für die anderen beiden Achsen machen wir das entsprechend.
Jetzt haben wir einen super Listener implementiert, haben diesen aber noch nirgends eingehängt. Dafür springen wir zurück in die onCreate()- Methode. Zunächst holen wir uns dort einen SensorManager aus dem SystemService. Das geht wie folgt:
SensorManager manager = (SensorManager)getSystemService(Context.SENSOR_SERVICE);
Nun fragen wir ab, ob überhaubt ein Beschleunigungssensor vorhanden ist, indem wir uns die Liste vorhandener Sensoren geben lassen.
if(manager.getSensorList(Sensor.TYPE_ACCELEROMETER).size() > 0)
Wenn es Sensoren gibt, holen wir uns einfach den erstbesten Sensor aus der Liste (weil in der Regel nicht mehr als einer da ist) und registrieren uns bei diesem als Listener:
final Sensor accelerometer = manager.getSensorList(Sensor.TYPE_ACCELEROMETER).get(0); manager.registerListener( this, accelerometer, SensorManager.SENSOR_DELAY_GAME);
Dabei legen wir über SensorManager.SENSOR_DELAY_GAME fest, mit welcher Präzision wir über Beschleunigungen informiert werden wollen. In unserem Fall wählen wir eine Geschwindigkeit, die für Spiele ausreichend ist, und fertig sind wir.
Der Teil über die Eingabemethoden ist übrigens stark an das Tutorial von Mario Zechner auf AndroidPit angelehnt.
Damit ist es geschafft! Wir haben eine abstrakte Basisactivity geschaffen, die es uns erlaubt, über ein Listenerkonzept 2D-Spiele für Android zu implementieren, inklusive Eingabemechanismen, Splashscreen und zwei-Thread-System.
Wenn Ihr an manchen Stellen nicht mitgekommen seid oder einfach gleich mit dem Spieleentwickeln anfangen wollt, findet ihr hier den Code zu der abstrakten Klasse, hier den Code zum Rendering- und hier den Code zum SimulationListener. Leitet dafür einfach eine Klasse von der GameActivity ab, erstellt Klassen die von SimulationListener und RenderingListener ableiten und hängt diese bevor(!) Ihr in Eurer abgeleiteten Klasse super.onCreate() aufruft als Listener über setRenderingListener() und setSimulationListener() ein. Bastelt darauf basierend Euer eigenes Spiel oder wartet noch auf das nächste Tutorial, da werden wir die erste Figur über den Bildschirm wandern lassen.
Wie Ihr seht mache ich die Tutorials relativ umfangreich, bitte habt deshalb Nachsicht wenn es ein paar Wochen dauert bis der nächste Teil erscheint.
.
