Android Android Game

[Trunk]

Hallo!

ich habe vor kurzem ein kleines Android-Spiele-Projekt in Angriff genommen, und es kamen mir zwei Fragen auf, welche ich mir leider nicht durch google oder die Forensuche beantworten konnte, also stelle ich sie einfach mal hier. 😳

Meine erste Frage:

Wenn ich ein Spiel in Android programmieren, werde ich ja aller wahrscheinlichkeit nach die onDraw() Methode benutzten, um damit sozusagen auf das "Canvas" zu zeichnen. Ist es dann trotzdem noch möglich, die Buttons und anderen Elemente des Layout-Editors in Eclipse zu benutzten? Oder muss ich diese Buttons dann selbst programmieren?

Und die zweite Frage:

Wenn ich ein Spiel habe, bei dem sagen wir mal zB der Bau einer Burg 4 Stunden dauert, und man das Spiel quasi wie ein Offline-Browser-Game spielt, wie stelle ich das am besten an? Wie verhindere ich, dass der User einfach die Zeit auf dem Smartphone verändert und so mogelt? Ich kann die App ja kaum andauernd im Hintergrund laufen lassen, also dachte ich dass sie beim Start immer schaut, wieviel Zeit seit dem letzten Mal vergangen ist und dementsprechend updatet. Hat jemand eine mögliche Lösung hierzu?

Ich bedanke mich schonmal recht herzlich! 🙂

LG

 

[Gast2]

Wenn ich ein Spiel in Android programmieren, werde ich ja aller wahrscheinlichkeit nach die onDraw() Methode benutzten, um damit sozusagen auf das "Canvas" zu zeichnen. Ist es dann trotzdem noch möglich, die Buttons und anderen Elemente des Layout-Editors in Eclipse zu benutzten? Oder muss ich diese Buttons dann selbst programmieren?

Keine Ahnung kenne Android da nicht gut genug, aber zu

Wenn ich ein Spiel habe, bei dem sagen wir mal zB der Bau einer Burg 4 Stunden dauert, und man das Spiel quasi wie ein Offline-Browser-Game spielt, wie stelle ich das am besten an? Wie verhindere ich, dass der User einfach die Zeit auf dem Smartphone verändert und so mogelt? Ich kann die App ja kaum andauernd im Hintergrund laufen lassen, also dachte ich dass sie beim Start immer schaut, wieviel Zeit seit dem letzten Mal vergangen ist und dementsprechend updatet. Hat jemand eine mögliche Lösung hierzu?

Hier würde ich einfach die Möglichkeit nutzen die aktuelle Zeit von einem ntp server wie einem der PTB zu beziehen. Internetzugriff ist ja kein Problem auf einem Android Gerät!

[EDIT]Nachtrag: Physikalisch-Technische Bundesanstalt (PTB)[/EDIT]

 

[Marco13]

Beim Android SDK wird doch in Eclipse so ein GUI-Bau-Tool mitinstalliert!? (Und ... obwohl ich solche Tools hasse, kommt man da kaum drumrum, wenn man nicht seine "R" per Hand schreiben will :autsch: )

 

[Trunk]

Beim Android SDK wird doch in Eclipse so ein GUI-Bau-Tool mitinstalliert!? (Und ... obwohl ich solche Tools hasse, kommt man da kaum drumrum, wenn man nicht seine "R" per Hand schreiben will :autsch: )

Die Frage ist nun auch, ob ich den GUI-Editor überhaupt für ein Spiel nutzen sollte. Kann ich dann überhaupt noch onDraw() usw benutzen, wenn ich eine xml-Datei als View angebe?

@kappesf: Danke für den Tipp mit der Zeit!

 

[Marco13]

Kenn' mich da auch nicht so gut aus, aber ... onDraw ist ja nur von "irgendeiner" View, und wenn man genau diese View mit dem GUI-Editor einsetzt, und ein paar Buttons drumherum, sollte das gehen... Aber vielleicht weiß da noch jemand was genaueres...

 

[Trunk]

Also so wie es aussieht kann man eine eigene Klasse schreiben, die von "SurfaceView" erbt, und auf ein solches kann man dann Buttons drüberlegen, da ein Surfaceview wohl im Hintergrund liegt.

Nachdem ich mich jetzt nochmal mit der Uhrzeitsache auseinandergesetzt habe, kommen doch nochmal einige Fragen auf; Ermittelt der oben gegebene Link nicht zB nur deutsche Zeit?

 

[schlingel]

Wenn das Spiel Serverkommunikation benötigt zwecks Interaktion mit anderen Spielern würde ich die Synchronisation mit Timestamps lösen die vom Server geladen werden. Jedes Mal wenn die App startet, holst du dir einen. Die kannst du dann in der App komplett autark von der Systemzeit verwenden.

Je nachdem was du zeichnen möchtest, genügt es tatsächlich, dass du eine Klasse schreibst die von View erbt und dann zeichnet was du brauchst. Die kannst du dann auch wie einen Button in deinen Layout-Container einfügen was es dir erlaubt Buttons, ImageViews etc. zu verwenden.

Der GUI-Editor ist grottenschlecht, ich schreibe immer alles per Hand.

(Und ... obwohl ich solche Tools hasse, kommt man da kaum drumrum, wenn man nicht seine "R" per Hand schreiben will )

Hm? Das generieren von R und die darin enthaltenen IDs ist vollkommen unabhängig vom UI-Editor.

 

[Marco13]

Hm... ich habe mich noch nicht intensiv genug damit beschäftigt, um zu wissen, wo die IDs herkommen, die man bei "getViewById" übergibt/übergeben kann - meine ersten Gehversuche hatte ich auch "handschriftlich" gemacht (vermute aber, dass es auf Android bessere Gründe gibt, das nicht zu tun, als z.B. bei Swing: Auflösungsabhänigkeit von Resourcen, Portrait/Landscape... aber vielleicht erscheint das nur im ersten Moment komplizierter, als es ist, wenn man mal mehr damit macht - das wenige, was ich bisher mit Android gemacht habe, hatte nicht viel mit GUIs zu tun)

 

[...ButAlive]

Vielleicht interessiert dich dieses Video: Google I/O 2009 - Writing Real-Time Games for Android - YouTube

Ist ein Vortrag auf der Google I/O 2009. Es geht relativ tief im Detail darauf ein, auf was man, bei Spieleprogrammierung unter Android, achten sollte. Dabei erklärt der Sprecher wie er replicaisland entwickelt hat.

Ist jetzt nicht gerade leichte Kost, aber der Typ hat einen recht lockeren Stil. Wenn du mit Englisch kein Problem hast, sollte es für dich interessant sein.

 

[Trunk]

Vielleicht interessiert dich dieses Video: Google I/O 2009 - Writing Real-Time Games for Android - YouTube

Ist ein Vortrag auf der Google I/O 2009. Es geht relativ tief im Detail darauf ein, auf was man, bei Spieleprogrammierung unter Android, achten sollte. Dabei erklärt der Sprecher wie er replicaisland entwickelt hat.

Ist jetzt nicht gerade leichte Kost, aber der Typ hat einen recht lockeren Stil. Wenn du mit Englisch kein Problem hast, sollte es für dich interessant sein.

Danke für das video, war auf jedenfall interessant und der Typ ist auch ein sehr sympatischer. 🙂

Während ich meine App nun schon ein bisschen weiterprogrammiert habe, ist mir aufgefallen, dass es wohl noch eine grundlegende Sache gibt, welche ich so nicht ganz verstanden habe... :

Sagen wir ich habe zwei Activities, eine für das Spiel selbst und eine für ein Settings-Menü.
Die Spiel Activity startet bei onCreate() eine GameThread-Klasse, welche zB einen Timer enthält welcher den Spielfluss übernimmt. Ich hoffe soweit ist das klar. Nun wechsle ich so per Button zu dem Settings-Menü:

Intent intent = new Intent(ga, SettingsActivity.class);
	startActivity(intent); }

Wenn ich in dieser neuen Activity bin merke ich nun, dass zB der Timer immernoch läuft. Was von der alten Activity ist denn nun noch da? Wie komme ich zurück? Ich bin davor immer davon ausgegangen dass man die Activity beim zurückgehen wieder mit startActivity(intent); neu starten muss...

Ich hoffe jemand versteht mein grundlegendes Problem? ???:L

 

[schlingel]

Wie du an dieser Grafik sehen kannst, wird eine App beim Starten einer zweiten Activity schlafen gelegt. Du bekommst das in deiner Activity mit in dem du die onPause() Methode überschreibst.

Ob die App dann beendet wird - wenn z.B. der Speicher gebraucht wird - oder ob dann ein Resume aufgerufen wird, weißt du vorhier nie.

Das heißt, du musst in deinem Spiel den aktuellen Screen pausieren, dir merken wo du gerade warst und dann die zweite Activity per startActivityForResult starten. Wenn du es mit dieser Methode startest, bekommst du ein Resultat zurück, wenn deine Settings-Activity wieder geschlossen wurde.
Das bekommst du in der onActivityResult-Methode mit. Prinzipiell alles in der Doku zur Activity nachzulesen, was ein jeder Anfänger auch tun sollte.

So wie ich das sehe, kommst du um ein ordentliches pause/resume nicht herum - der Benutzer könnte ja über die Notifications oder einen Anruf eine andere App starten. Trotzdem würde ich das Starten der Settings-Activity in einen Startbildschirm vorlagern.

 

[Trunk]

Ich denke ich habe das Prinzip auch ganz gut verstanden, die Grafik kannte ich auch schon; was mich nun noch verwirrt, ist folgendes:

Wenn ich zur Activity B wechsle, kann es ja passieren dass Activity A beendet ist, wenn ich wieder zurückwechseln will - auf jeden fall wird onCreate wieder aufgerufen. In der Oncreate erstelle und starte ich meine GameThread-Klasse mit Timer.. und wenn ich nun zurückwechsle wird logischerweise ein neues Objekt davon erstellt, nur wieso hört der alte Timer nicht auf zu ticken? ???:L

Danke trotzdem!

 

[schlingel]

Wenn ich zur Activity B wechsle, kann es ja passieren dass Activity A beendet ist, wenn ich wieder zurückwechseln will - auf jeden fall wird onCreate wieder aufgerufen.

onCreate wird nicht auf jeden Fall aufgerufen. Die Garantie gibt's nur bei onResume. In der Grafik siehst du ja eh, dass die Activity nur im Bedarfsfall abgeschossen wird. Gerade bei neuen Geräten mit viel RAM passiert das nicht so häufig.

und wenn ich nun zurückwechsle wird logischerweise ein neues Objekt davon erstellt, nur wieso hört der alte Timer nicht auf zu ticken?

Weil der Thread noch läuft. Warum sollte der GC einen Thread beenden der noch läuft? Könnte ja sein, dass dies beabsichtigt ist.
Nimm zum Beispiel an, du schreibst einen Web-Server. Das wäre doch saublöd, wenn dir der GC einfach den Thread abschießt nur weil seit 5 Minuten keine Anfrage mehr hereinkam.

Wie gesagt, um ein ordentliches pause/resume kommst du nicht herum.

 

[Trunk]

Ok danke, ich denke das hab ich jetzt hinbekommen, das mit dem Thread beenden auch. 🙂

Eine Frage hätt ich aber noch: Wenn ich in Android Bilder via der BitMapFactory lade, wann tue ich das am Besten? Ständiges neuladen sollte ja verhindert werden.. 😱

 

[schlingel]

Beim onCreate. Ich persönlich starte dabei immer einen AsyncTask und erledige die zeitintesiven Punkte in asynchron und am Schluss erledige ich das Setzen der geladenen Ressourcen im UI-Thread.

Ich hab zu dem Thema einen Artikel geschrieben der erklärt wie das ganze funktioniert.