Archive for November 2007

Interlude

Donnerstag, 29. November 2007

Oh je. Mein Professor wird langsam ungeduldig. Er findet das ja alles schön und gut bisher, aber die Sache mit den Platzhaltern stört ihn. Ich soll doch endlich mit der richtigen Grafikerstellung anfangen.

Zitat: »Es ist mir egal, ob es funktioniert! Es muss nur gut ausschauen!«

Na mir ist das aber nicht egal. Ich studiere ja nicht umsonst MMVR. Die Interaktion ist das Herzstück. Ansonsten wäre ich beim ›normalen‹ Grafik-Design gelandet. Ich muss wirklich noch einiges schaffen bevor ich mit dem Malen anfange.

Delivery gone well

Mittwoch, 28. November 2007

Endlich ist die Sache mit dem Postsack erledigt. Kein umständliches Rumscripten mehr, ein einzelnes sauberes ›MatchSpritePosition‹ genügt. Nun bewegt er mit und alles ist toll.

Auf Kommando abwerfen und wieder aufnehmen wenn er am Boden liegt funktioniert auch. Abwerfen − nehmen. Abwerfen − nehmen. Abwerfen − ach wenn das Leben doch nur immer so einfach wäre.

Victory/Capitulation

Dienstag, 27. November 2007

Bei dieser Enemy-FollowPath-Sache muss ich jetzt einfach Schluss machen. Wie man am Screenshot sieht, habe ich für das Sprite kurzerhand das umgefärbte Zeppelin (pink) hergenommen. (Übrigens eine weitere angenehme Sache am SGDK2: der RGB-Wert von Sprites sowie Tiles kann in Echtzeit per Script oder Voreinstellung manipuliert werden)

Die braunen Bälle repräsentieren übrigens die Pfadpunkte. Außer der unter dem grauen Zeppelin, das ist der Postsack.

Enemy - Sprite DefinitionEnemy FollowPath - Screenshot

Mein Sieg besteht darin, eine ganz nette Lösung für das Links/Rechts-Problem gefunden zu haben. Wie im einen Screenshot zu sehen, hängt der gewählte Zustand davon ab, ob die horizontale Geschwindigkeit (dx) des Sprites positiv oder negativ ist.

Ein anderer Ansatz dafür war, die Koordinaten der Pfadpunkte miteinander zu vergleichen, ob das X nun größer oder kleiner als beim vorherigen ist. Das scheiterte daran, dass Koordinate 0 (der Startpunkt) minus 1 (letzter angeflogener Punkt) nunmal -1 ergibt, und nicht einen anständigen Wert, wie z.B. 453. Eine Koordinate -1 gibt es nicht, und einen Parameter wie z.B. ›PathLastCoordinate‹ gibt es leider noch nicht im SGDK2.

Vor dem anderen Problem kapituliere ich einstweilen, weil es für das Spiel total irrelevant ist. Ich habe mich bisher nur so ausführlich damit beschäftigt weil es Spaß gemacht hat. Das Problem war, dass ich bei diesem Sprite ebenfalls wollte dass sich das Zeppelin langsam dreht − in mehreren Frames. Bisher hatte ich immer gar keine oder eine ständige Drehung. Aber da dieses Sprite sowieso dazu gedacht ist, Vögel und dergleichen darzustellen, kann ich mir das echt sparen. Wie man schon an meinem frustierten Kommentar erkennen kann − Vögel brauchen keine Dreh-Animationen. Die flattern bloß.

Anbei zwei Beispiele für meine Versuche mich dem Problem zu nähern und das Skripten zu strukturieren:

Mistraal Skripten 9Mistraal Skripten 10

Wind: Sprites, Tiles, Tile Mappings?

Samstag, 24. November 2007

Ich denke darüber nach wie ich die Luftströme am besten integrieren kann. Es gibt dabei einige Sachen, die ich beachten muss: Wenn ich sie als Tile verwende, kann ich sie nicht vor Felsen darstellen (Die Felsen auf der Spielerebene, die man umfliegen muss). SGDK2 hat ein sehr nettes Feature, welches ich einsetzen könnte, damit es doch geht: Tile Mapping. Dabei sagt man der IDE, dass man zwei Tiles miteinander kombinieren möchte, und kann festlegen welches von den beiden im Vordergrund erscheint. Eine Anwendung dafür könnte z.B. sein, dass man Wolken vor transparentem Hintergrund erstellt, und sie dann mit einem einfarbigen Tile verschmilzt. Falls man die Himmelsfarbe ändern möchte, muss man das nur bei dem einfarbigen Tile machen, alles andere aktualisiert sich selbstständig.

Da meine Windströmungen aber animiert sein werden, d.h. min. 4 Frames haben werden, und mein Felsen-Tileset sehr viele Tiles haben wird, wäre das alles viel zu viel Aufwand (Bei einem 20-teiligen Tileset wären das 80 zu erstellende Tile Mappings!).

Eine andere Möglichkeit wäre es, den Wind einfach als Sprite zu behandeln. Der Vorteil daran wäre die pixelgenau Kollisionserkennung von Spieler und Wind, die sicherlich die Steuerung etwas erleichtern würde. Nachteil wäre der hohe Sprite-Count im Spiel. Zudem hätte man unzählige von Sprites und ihren Skripten in der IDE. Schlecht für den Überblick während der Entwicklung.

Aber zum Glück ist mir doch noch eine hübsche Lösung eingefallen: Ich mache einfach eine zusätzliche Hintergrund-Ebene, die mit der selben Geschwindigkeit wie der Vordergrund scrollt. So macht Tricksen Spaß. ^^

Delivery fails

Donnerstag, 22. November 2007

Fein, den Postsack unter den Zeppelin zu hängen war ja gar nicht so schwer. Nur ein ›AddSpriteHere‹ war nötig. Etwas schwieriger gestaltete sich allerdings, dass der Sack auch da bleibt, wo er soll. Zuallererst blieb er einfach in der Luft stehen, wenn das Zeppelin wegflog. Okay, wie bringen wir ihn dazu mitzukommen?

Der Postsack bekommt (was die Bewegungen betrifft) das gleiche Script wie das Zeppelin. Wenn der Spieler nach links drückt, wird diese Bewegung ebenfalls auf den Sack übertragen. Zusätzlich Faktoren sind der Trägheitswert und die Beschleunigung des Zeppelins. Funktioniert schon nicht schlecht. Allerdings macht der Postsack immer noch sehr seltsame Sachen. Wenn das Zeppelin vor einem Felsen festhängt, der Spieler den Knopf aber gedrückt hält, marschiert der Postsack munter durch den Fels hindurch. Und die Bewegungen stimmen nicht exakt mit dem Zeppelin überein.

Das liegt an der Methode, wie ich die beiden Sprites ansteuere. Die Spielerfigur wird über den einfachen Befehl ›MapPlayerToInputs‹ angesteuert, aber für den Postsack ging das nicht. Der bekommt jede Richtungstaste einzeln aufgemappt. Obwohl der gleiche Input reingeht, kommt nicht der selbe Output raus. Schade.

Final Concept

Mittwoch, 21. November 2007

Nun aber mal zum richtigen, zum zu verwirklichenden Konzept:

Mistraal Konzept 1Der Spieler soll in einer wüstenartigen Gegend herumfliegen, die Hitze bringt das Gas evtl. zum Entweichen und erschwert die Steuerung. Dann, entweder nach einer bestimmten Zeit oder einem Event, bricht ein Schneesturm los. Er dauert nur eine kurze Weile, aber danach ist alles vereist. Auch das Zeppelin. Von nun an geht es um Zeit, denn die Eisschicht macht das Schiff viel zu schwer, und es droht abzustürzen. Der Spieler kann von da an nicht mehr an Höhe gewinnen, und muss zusehen, rechtzeitig zu einem sicheren Ort (Ziel am Ende des Levels o.ä.) zu kommen.

Einen Vorgeschmack auf das, was ihm blüht, sollte er es nicht rechtzeitig schaffen, bekommt er durch die Luftschiffe die bisher still und stumm im Hintergrund ankerten. Diese sind ganz genauso mit einer Eisschicht überzogen und zu schwer geworden. Da sie dem Grund aber wesentlich näher sind, erreichen sie ihn auch früher, und der Spieler kann live miterleben, wie sie auf dem Boden aufkrachen und sich in Feuerbälle verwandeln … Auch eine Art der Motivation.

Templates

Dienstag, 20. November 2007

Habe nun ein paar Templates für SGDK importiert. Die gibt’s auf der Supportseite zusätzlich zum runterladen. Templates gibt es eigentlich für alles; Tilesets, Sprites, Sample Games. Ich habe Sprites importiert um ihr Script zu untersuchen und vielleicht ein paar Dinge für meinen Pfad-NPC zu lernen. Auch das Verhalten des Zeppelins lässt noch zu wünschen übrig. Das hat genau das selbe Problem: es muss von einem Guckt-nach-links-unten-Zustand tadellos zum Guckt-nach-rechts-oben-Zustand wechseln können. Es funktioniert mit der Hälfte aller Zustände, aber noch nicht bei allen. Muss noch rausfinden warum. Grummel.

What’s going on here?! (Part 3)

Montag, 19. November 2007

Mistraal Skizzen 8aDie Idee hierzu kam mir während einer Vorlesung zur Existenzgründung. Die war nicht langweilig, ich guckte bloß einmal hoch zur Decke, und da hing diese riesige Lampe, die aus vielen einzelnen mattweißen Kugeln bestand. Ich fühlte mich irgendwie an UFOs erinnert.

Und deshalb stellen die Kugelhaufen auf der Skizze außerirdische Flugkörper dar, die zudem enorme Hitzequellen sind. Der Level stellt sich so dar, dass man ihn einfach nur durchqueren muss. Die UFOs verfolgen das Luftschiff aber die ganze Zeit, fliegen aber auch ständig extrem seltsame Manöver. Der Spieler muss zunächst versuchen, ihnen so gut es geht auszuweichen, denn durch ihre Hitze die sie verströmen, dehnen sie das Gas im Zeppelin zu weit aus. Es kommt daher zu Gasverlusten die das Luftschiff schwerer steuerbar machen.

Kommt es dann irgendwann doch zu einem Kontakt, tut der Spieler gut daran, von da an in der Nähe der UFOs zu bleiben. Nur in ihrer Nähe hat er dann nicht unter den schwereren Flugbedingungen zu leiden. Wie aber schon erwähnt, haben die Aliens viele extreme Flugmanöver drauf, die die Verfolgung sehr erschweren.

Dieses Wechselspiel von Anziehung und Abstoßung, Flucht und Verfolgung finde ich eigentlich ganz reizvoll.

switchToState(left);

Freitag, 16. November 2007

Da so ein Zeppelin ja von Natur aus etwas langsamer ist, kann es natürlich nicht von einer Sekunde auf die andere um 180 Grad rotieren. Was ja aber der Fall ist, wenn der Spieler in eine andere Richtung als bisher fliegen will.

Meine Aufgabe: mehrere Zwischenframes erstellen und Bedingungen für ihr korrektes Abspielen zurecht skripten. Es könnte alles so einfach sein. Wenn das Spiel nur wüsste, ob es gerade einen Zustandswechsel gemacht hat oder nicht. Da ich leider nicht einfach fragen kann: »Hast du dich grad links rum gedreht? Dann spiel jetzt die Frames 2−6 ab!« verkompliziert sich alles … wie schon erwähnt, dieser If-Else-Krampf ist schrecklich.

FollowPath()? Sure!

Donnerstag, 15. November 2007

Ein Zwischenstand: Ich habe jede Menge Sachen angefangen zu scripten, momentan funktioniert noch nichts davon richtig. Sehr am Herzen liegt mir einen NPC an einem Pfad entlanglaufen zu lassen. Das funktioniert soweit tadellos. Allerdings dreht er sich nicht um wenn er an einen Wendepunkt kommt, und läuft so die Hälfte der Zeit rückwärts. Mir scheint ich habe diese ganzen If-Bedingungen und Else-Sachen überhaupt nicht kapiert und rate nur wild während ich eine Rule nach der anderen erstelle, teste, in der Script-Reihenfolge herumschiebe und abändere. Damn.