Home HighScore Downloads Diary
 
 
Hier findet ihr zu jeder Version kurz und knapp, was im Code alles so passiert ist. Dies soll also eine Art kleines Programmier-Tagebuch werden. Ich werde versuchen die Hintergründe hinter dem Code ein wenig zu erläutern und euch auch den ein oder anderen Code-Schnipsel hochladen. Habt aber Verständnis dafür, dass hier nicht der gesamte Code gezeigt werden kann, da dies einfach zu viel wäre und den Rahmen sprecngen würde. Ich beziehe mich immer wieder nur auf die relevanten Dinge, die sich in der jeweiligen Version geändert haben.

API Level 22
Android Version 5.1 Lolipop
Sprache Java
Libary Android
Gradle Version 6.1.1
 
  DEXTER_20200929
 
Das Spiel "Chaos Farm" ist ein kleines Sortierspiel, bei dem der Spieler Kisten sortieren muss. Die Regeln sind recht einfach. Ziel ist es in ein Regal, dass 4 Kisten fassen kann 4 gleiche Kisten übereinander zu stapeln. Dabei darf eine Kiste immer nur in ein leeres Regal oder auf eine andere Kiste der gleichen Art gestellt werden. Das war es schon. dabei wird die Zeit, sowie die benötigten Züge gezählt, die der Spieler braucht. Wurde ein Level abgeschlossen, wird auf der Übersicht das nächste Level frei geschalten. Gespeichert soll in dieser ersten Version noch nichts.
Um das ganze aber auch ein wenig abwechslungsreicher zu gestalten soll es neben dem Level Modus auch noch einen endlos-Modus geben. In diesem werden dem Spieler 9 Regale vorgegeben, von denen 5 zufällig befüllt sind. Alle 30 Sekunden kommen dann 4 neue Kisten hinzu. Hat der Spieler 4 gleiche Kisten über einander gestapelt, werden diese aus dem Regal wieder rausgenommen. Die Kisten, die neu dazu kommen, werden zufällig auf die Regale verteilt, die gerade Platz bieten. Sollte durch das Hinzufügen von weiterem 4 Kisten kein Platz mehr sein um Kisten zu verschieben, hat der Spieler das Spiel verloren, da er auch keine mehr verschieben kann.



Um die Level nicht immer wieder neu Codieren wurde hier wieder mit einem externen Editor gearbeitet. In diesem kann ein Level erstellt werden, was dann später in einem kleinen Bild abgelegt wird. Dieses Bild ist insgesamt nur 4Pixel hoch und hat in der Breite so viele Pixel wie es Regale geben soll. Die App grieft sich je nach Level eine solche Datei und setzte als ersts die Regale in der Anzahl der Bixel des Bildes in der Breite. im kommenden Schritt werden wieder (wie bei der Karte) die Farbcodes der Pixel abgefragt und anhand von diesen die jeweiligen Kisten in die Regale gesetzt.
Beim Endlos-Modus sieht es etwas anders aus. hier werden zufällig Kisten in die zufällige Regale gesetzt. Zu Beginn werden 24 Kisten in die 9 Regale plaziert. von nun an werden in Bestimmten Intervallen 4 neue Kisten geliefert un auf die Regale verteilt.
 
  DEXTER_20200918
 
Für diese Version wurde wieder einiges an neuen Kacheln erstellt. Der gesamte Innenraum des Hauses wurde designt und in die App eingeladen. Hier wurden auch neue Animationen erstellt, die neben den drei Automaten an der hinteren Wand auch Fackeln darstellen sollen. Diese werden durch zwei neu erstellte Indexe gesteuert, die durch den bereits existierenden Thread gesteuert werden, der auch die Animation des Wassers steuert.
Neben dem einladen und dem Aufbau des Innenraumes des Hauses sind nun auch die ersten Vorbereitungen für das erste MiniGame implementiert worden. Hierbei sind die Automaten, die sich im Haus an der hinteren Wand befinden mit einem Event versehen worden. Sobald der Nutzer einen dieser Automaten berührt, wird dieses Event aufgerufen. Allerdings hat dies noch keine Auswirkung, da es keine implementation hinter diesem Event gibt.

Wie im ersten Bild zu sehen ist gibt es neben dem Index für das Wasser, die Automaten und die Fackeln auch noch einen Index, der für die Steuerung eines Geldstücks gebraucht wird. Dieses findet sich an der oberen rechten Stelle des Bildschirms und reiht sich still und leise vor sich hin. Hier soll später ein Betrag zu sehen sein, den man im Laufe des Spiels aufbauen oder auch wieder ausgeben kann. Somit zählt auch diese Erweiterung als Vorbereitung für eine kommende Version. Wann genau dies weiter eingebunden wird ist aber erst einmal nicht klar, da die Priorität erst einmal auf dem ersten Spiel liegt.
 
  DEXTER_20200909
 
Bis her wurde alle 15 Millisekunden (0.015 Sekunden) die gesamte Karte mit allen 15.732 Kacheln (171 Kacheln in der Breite und 92 Kacheln in der Höhe) gezeichnet und berechnet. Dies ist natürlich völlig unnötig, da ja immer nur ein kleiner Ausschnitt auf dem Display sichtbar ist und nicht die gesamte Karte.
Im ersten Schritt wurde ermittelt wie viele Kacheln für die Hälfte der Breite und wie viele für die Hälfte der Höhe des Bildschirms gezeichnet und berechnet werden müssen. es wurde desswegen die Hälfte genommen, da sich der Spieler, dessen Kachelposition ja bekannt ist, immer genau in der Mitte des Bildschirms befindet und von dessen Position aus die umliegenden "sichtbaren" Kacheln ermittelt werden. Um einen kleinen Buffer zu haben, wurden jeweils noch 2 Kacheln drauf gerechnet.



Jedesmal, wenn der Spieler sich nun bewegte errechne die App einen neuen Startindex (Spielerposition auf der X Achse minus der Anzahl Kacheln für die Hälfte der Breite des Bildschirms). Die fast gleiche Rechnung wird für den Endpunkt gemacht. Nur werden die Kacheln hierbei nich von der Spielerposition abgezogen sondern drauf gerechnet. Das selbe Vorgehen wird noch einmal für die Y-Achse durchgeführt und schon erhält man auf der X- und der Y-Achse einen Punkt für den Start der Berechnung und des Zeichnens und jeweils einen Endpunkt. Auf diese Weise können nun die beiden Schleifen, mit denen die Matrix der Kacheln durchlaufen wird, nur über die Kacheln laufen gelassen werden, die um den Spieler herum auch auf dem Bildschirm zu sehen sind.
Mit diesem kleinen Kniff konnte ein großer Performance Schub für das Spiel heraus geholt und einiges an ruckeln beseitigen werden.
 
  DEXTER_20200905
 
Um den Spieler nicht mehr mit einem Pad laufen zu lassen, sondern automatisch zu einem bestimmten Punkt auf der Karte muss zu Beginn erst einmal ein wenig Mathe gemacht werden.
Um erst einmal heraus zu bekommen, welche Kachel vom Nutzer angewählt wurde, wird die Y-Position der Berührung auf dem Bildschirm minus der Hälfte der Höhe des Bildschirms genommen und die X-Position minus der Hälfte der Breite des Bildschirms. Somit bekommt man die Entfernung der Berührung zur Mitte des Bildschirms. Ist der ermittelte Y-Wert im Minus Bereich, so wurde der Bildschirm in der oberen Hälfte berührt. Ist der Wert positiv wurde der Bildschirm im unteren Bereich berührt. Bei der X-Position ist es ähnlich. Nur das hier ein negativer Wert für die Linke Seite des Bildschirms steht und ein positiver für die rechte Seite. Diese Werte werden die Maße einer Kachel geteilt. Also der Y-Wert durch die Höhe und der X-Wert durch die Breite. Nun bekommt man als Ergebnis die Anzahl der Kacheln, die die Berührung von der Mitte des Bildschirms entfernt ist. Die Mitte des Bildschirms spielt hier deswegen eine so große Rolle, da sich genau dort der Spieler befindet und dessen aktuelle Position auf der X-Achse wie auch auf der Y-Achse bekannt sind. Wird die X-Position des Spielers nun mit der Kachel-Entfernung auf der X-Achse verrechnet erhält man den X-Wert der Zielkachel und verrechnet man die Y-Poistion des Spielers mit der Kachel-Entfernung auf der Y-Achse so erhält man die Y-Position der Zielkachel.
Nachdem nun klar ist wo es hingehen soll, muss nun ermittelt werden welcher Schritt als nächstes gemacht werden soll. Dafür wird einfach geschaut welcher der größere Wert ist. Natürlich müssen dafür alle Werte in der Positiven Bereich gebracht werden. Ist der Spieler nun 5 Kacheln auf der Y-Achse und 3 Kacheln auf der X-Achse von der Zielkachel entfernt, so wird der Spieler als Erstes auf der Y-Achse wandern, bis beide Werte gleich also bei 3 liegen. Nun entschiedet ein Zufall ob auf der X-Achse oder der Y-Achse weiter gegangen wird. Somit ist allerdings nicht immer klar, welchen weg der Spieler nun nehmen wird.



Da diese Rechnung nach jedem Schritt neu berechnet wird, ist es auch möglich mit dem Finger über den Bildschirm zu streichen und die Richtung auf diese Weise immer wieder zu ändern. Mit einer Berührung auf den Spieler direkt kann die aktuelle Bewegung auch unterbrochen werden und der Spieler bleibt auf der Kachel stehen, die von ihm als nächstes erreicht wird.
 
  DEXTER_20200904
 
An dieser Stelle der Entwicklung besteht schon ein Großteil der App, der jetzt nicht in jedem Detail erklärt werden soll. Dies würde auch den Rahmen sprengen.
Der Aufbau des Grundgerüstes wurde in drei Teile unterteilt und durch die Package-Verwaltung getrennt.



com.fisichkralle.app
Dies ist das package mit dem alles Beginnt. Hier finden wir die Activity, auf die zugegriffen wird, wenn die App gestartet wird. Von dieser Klasse aus geht es in die Initialisierung, bei der alle relevanten Werte ermittelt und geladen werden. Dazu gehören Werte wie die Höhe und die Breite des aktuellen Displays. Von diesem Wert wird auch ermittelt, mit welchen Werten die einzelnen Grafiken skaliert werden müssen, um auf jedem Gerät die gleiche Ansicht zu gewährleisten.
Weiter finden sich hier Handler Klassen, wie z.B. der "FileHandler" wieder, der dafür genutzt wird, um Informationen In Dateien auf dem Handy zu schreiben und diese auch wieder auszulesen. Auch der "GfxHandler" wurde in diesem package untergebracht, in dem die einzelnen Grafiken für alle Bereiche der App geladen werden. Jede Klasse für sich hat noch mal eine eigene Verwaltung. So werden nicht alle Grafiken geladen, sondern nur die, die für den gerade aktive Bereich gebraucht werden.

com.fisichkralle.start
Das package "start" sorgt dafür, dass beim Laden nicht nur ein schwarzer Bildschirm angezeigt wird, sondern eine kleine Animation für den Nutzer zu sehen ist. Weiter wird hier auch ermittelt, wo sich der Spieler gerade befindet und setzte die Umgebung um den Spieler an die richtigen Positionen. Es werden zudem auch die ersten Events abgefeuert um den Spieler nicht "auf" der Grafik des Hauses starten zu lassen (falls er sich gerade dort befindet) sondern das jeweilige Event dafür sorgen kann, dass die Grafiken richtig gesetzt werden. Was genau bei einem solchen Event geschieht, wird im Punkt Dexter_0 erläutert.

com.fisichkralle.dexter
Das package "dexter" ist für die gesamte Welt zuständig, auf der sich der Spieler bewegen kann. Hier werden die Events gesteuert und der Spieler wird hier verwaltet. Allerdings nur solange er sich auch auf der Welt befindet. Sobald später die kleinen Spiele hinzukommen, werden die seine Steuerung übernehmen. In diesem package wird auch die Speicherung für die Position des Spielers auf der Welt vorgenommen. Das Aussehen des Spielers wird zwar im "start" package vorgenommen, da dort dieser auch ausgewählt werden kann. Doch wird diese Information hier geladen und der Spieler nach den geladenen Informationen zusammengebaut. Später soll hier auch der Spieler gespeichert werden. Da es in einer, noch in der ferne liegenden Version, möglich sein soll, dem Spieler einen Hut etc. zu verpassen.



Die Karte hat 171 Kacheln in der Breite und 92 Kacheln in der Höhe. Somit besteht die Karte aus insgesamt 15732 Kacheln die mit 364 verschiedenen Kacheln befüllt werden muss. Hierfür wurde ein Editor, außerhalb der App, erstellt. Mit dessen Hilfe kann die Karte nach eigenem Belieben erstellt werden. Das Ergebnis ist eine kleine Karte, bei der jeder Pixel eine eigene Farbcodierung hat, die für eine Bestimmte Kachel steht. Beim Zusammenbauen der Karte in der App wird diese kleine Karte geladen und jeder Pixel wird nach seinem Farbcode gefragt. Anhand dieses Farbcodes wird dann die richtige Kachel ausgewählt und an die jeweilige Stelle der Welt gesetzt. Das Beispiel, das hier hochgeladen wurde, ist natürlich stark vereinfacht, zeigt aber ganz gut wie das System dahinter funktioniert.
 
  DEXTER_0
 
Zur Vorbereitung auf das Spiel wurden verschiedene Grafiken erstellt. Um die komplette Welt in Kacheln darzustellen und es nicht direkt langweilig werden zu lassen, benötigt es einiges an verschiedenen Kacheln, die alle in der Auflösung 32 x 32 Pixel erstellt wurden.



Eine Besonderheit stellen hier die Kacheln, die z.B. Teile von Wasser oder anderen Animierten Elemente zeigen dar. Hier müssen immer mehrere Kacheln mit nur kleinen unterschieden erstellet werden. Auf diese Weise können diese Kacheln in bestimmten Intervallen gewechselt werden um die Animation wie bei einem *.gif (oder einem Daumenkino) zu realisieren.



Neben den animierten Kacheln gibt es allerding noch eine Besonderheit. Und zwar werden z.B. Gebäude wie das Haus ebenfalls aus Kacheln zusammengebaut und wie jede andere unter den Spieler gezeichnet. Jetzt könnte man zum einen dem Spieler einfach verbieten diese zu betreten, was aber blöd ist, da der Spieler ja auch hinter das Haus gehen soll. Wird es dem Spieler nun erlaubt diese Kacheln zu betreten, würde dieser einfach über die Grafik des Hauses laufen... . Um hier eine vernünftige Lösung zu bekommen sollen Tile-Events eingebaut werden, die reagieren, sobald der Spieler eine neue Kachel betritt. Somit sollen die Grafiken der Kacheln um den Spieler herum ausgetauscht werden.



Insgesamt sind hier 364 verschiedene Kacheln zusammengekommen. Diese werden in der App alle geladen und auf die richtige Größe skaliert, damit auch auf jedem Gerät mit den unterschiedlichsten Auslösungen gleichviele Kachel angezeigt werden können. Somit hat keiner mit einer höheren Auflösung eine größere Übersicht und somit auch keinen Vorteil.

Neben den Kacheln mussten auch für das Menü noch einige Grafiken erstellt werden. Hierbei wurden die Hintergründe als Ganzes erstellt und mit den erstellten Buttons befüllt. Die Buttons wurden immer in dreifacher Ausführung erstellt. Die erste Grafik zeigt den Button im normalen Standard. In der zweiten wurde der Button vom Nutzer angewählt und in der letzten Grafik ist der Button deaktiviert und kann nicht benutzt werden.



Je nach Aktion wird hier die jeweilige Grafik ausgewählt und angezeigt.