Pixelmovementtut Vol.1 Lets Start

[Zeph]

Hi, hab mich mal entschlossen mein Wissen geringfügig weiterzugeben und möchte ein Tut zu einem Skript bringen, was von vielen als sehr schwierig und sehr komplex angesehen wird, durch die richtige Planung und eine logische Denkweise doch eigentlich sehr einfach ist, die Rede ist vom Pixelmovement. Ich möchte in naher zukunft ein kleines Tut schreiben, wie man mittels Planung und der richtigen Umsetzung ein solches Skript umsetzen kann.

So, genug Text, ran an die Buletten:

1. Zuerst sollte man Planen, was man eigentlich alles haben will und sich schonmal gedanken darüber machen, wie man es umsetzt. Wir wollen z.B.

#ein Bild pixelweise Bewegen unter Berücksichtigung der Umgebung.


Wie setzen wir das ganze also um?

Die Bewegung des Bildes ansich realisieren wir über ein Paar Variablen, die die Koordinaten des Bildes darstellen und eine Tastenabfrage.
Die Umgebungsbabfrage realiesiert man ambesten durch eine abfrage der TerrainID, wobei eine bestimmte TerrainID für eine geblockte Umgebung steht.


2. Nachdem man sich nun Gedanken gemacht hat, sollte man diese Gedanken nun durch einem sog. Ablaufkette in einer sinnvollen Reihenfolge festhalten.

"Ablaufkette, hey?" werden sich sicherlich einige Fragen.
Also, eine Ablaufkette unterteilt ein Programm in einzellne Schritte. Begonnen wird mit einem Initalisierungschritt, anschließend folgen Einzellschritte, wobei immer nur 1 Schritt abläuft. Nachdem 1 Schritt abgearbeitet wurde, folgt der nächste.

Bei uns sollte grob etwa so aussehen:




Wenn man dies erstellt hat, kann man das ganze noch durch unsere Überlegungen für die Umsetzung erweitern, was dann etwa so aussehn sollte:




Damit sollte die Planung für das eigentliche Hauptprogramm abgeschlossen sein, nun folgt die erste Umsetzung.

Wie soll man eine solche Ablaufkette geschickt in den Maker umsetzen, und den Code dabei dennoch ordentlich halten? Einfache Antwort "Call Events".
Call Events wirken wie normale Befehle, d.h. sie rufen einen Code auf, welcher abgearbeitet wird. Anschließend springen sie wieder dahin zurück, vonwo sie gecallt wurden, wodurch sie bestens geeignet währen.

Also fangen wir an, wir haben durch unsere erste Ablaufkette festgelegt das wir 4 Schritte haben:

#Init
#Tastenabfrage und Auswertung
#Umgebungscheck
#Bewegung

Für jeden dieser Schritte legen wir nun ein einzellnes CommenEvent an, die wir ebenfalls so benennen. Anschließend kommt noch eins, das wir Ablaufkette nennen und coden dort unsere erste Ablaufkette hinein.

Wie soll das aussehen?



Wir sehen zuerst, das der InitSchritt aufgerufen wird, anschliend folgt ein Cycel indem unsere anderen drei Schritte eingebunden sind. Die Reihenfolge entspricht der Reihenfolge der Ablaufkette. Gefolgt von einem Wait mit 0,0 Sekunden, welches zum Begrenzen der Geschwindigkeit erforderlich ist.

Soweit sogut, fangen wir an und setzen den Schritt Init um. Was soll aber rein?

Um diese Frage zu Beantworten müssen wir uns überlegen, was wir alles im Skript brauchen werden?
Als erstes würde mir da ein Bild einfallen, da dies ja bewegt werden soll. Setzen wir also als erstes ein Bild. Als Koordinaten nehmen wir einfach zwei Variablen, und nennen sie PixelX und PixelY. Damit unserer Bild nicht vom anfangan oben links in der Ecke angezeigt wird, setzen wir unsere Variablen noch auf bestimmte Werte, bevor wir das Bild anzeigen.
Soweit sollte das alles gewesen sein, was wir brauchen, falls uns in den nächsten Schritten noch was einfällt, was hinzukommen sollte, können wir unseren InitSchritt immernoch erweitern.



So sollte es ungefähr aussehen. Als Pic was wir bewegen wollen nehmt erstmal dies:




Damit währe unser InitSchritt fertig und wir können übergehen zum nächsten, der Tastenabfrage. In unserer Ablaufkette haben wir festgelegt, das wir hier die Tasten abfragen und auswerten. Beginnen wir als erstes mit einer Tastenabfrage. Macht kein Häckchen bei "Wait until key hit" und macht nur ein Häckchen bei den Richtungen. Anschließend folgt unsere Auswertung. Auswerten wollen wir die Tasten darüber, indem wir bei den einzellnen Tasten die Position unseres Bildes entsprechend verändern, also wenn wir Hoch drücken, soll sich unser Bild auch Hoch bewegen, was wir durch eine verkleinerung unserer PixelY Koordinate erreichen können. Da wir uns noch nicht sicher seihen können, ob diese Position überhaupt passierbar ist, wollen wir einfach zwei zusätzliche Variablen auf unsere akt. Position setzen und entsprechend bearbeiten. Falls die neue Position möglich währe, gehen wir hin und gleichen unsere Pixelkoordinaten des Bildes entsprechend an.

So sollte unser Code aussehen:



So, kommen wir nun zu der Umegungsabfrage, wir hatten ja zuvor geplant, wir wollen diese Funktion mitttels unserer TerrainID umsetzen. Damit wir dies machen können, legen wir erstmal eine spezielle TerrainID an, die wir "Block" nennen. Wenn möglich auf Platz 2, auf Platz 1 legen wir noch die TerrainID "Lauf" an.



Warum 1 und 2? Wenn wir ein neues Chipset anlegen, bekommen wir werden alle Tiles immer mit einer 1 gekennzeichnet. Würden wir diese TerrainID als geblocktes Feld nehmen, müssten wir alle Felder die man passieren kann, noch auf "Lauf" setzen. Da man meist mehr Stellen hat, die man passieren kann, als umgekehrt, man es so mehr Sinn. Nun stellen wir unsere TerrainIDs in unserem Chipset noch ein.




Ich habe mal diese WandTerrain als geblocket eingestellt.

Soweit so gut, nun müssen wir ja dies noch Berücksichtigen wenn wir uns Fortbewegen wollen. Also gehen wir zu unserer CommenEvent "Umgebungsevent". Dort fragen wir als erstes ab, welche Taste gedrückt wurde. Dies ist ja noch in der Variable "Aktion" gespeichert.
So, nun gehen wir hin und überlegen, was wir alles machen müssen, damit wir abfragen können ob unsere nächste Position frei ist. Dafür gehen wir hin und ziehen unser Bild "Beweger" zu Rate.
Wenn wir nun die Bewegung für "Runter" erstellen wollen, gehen wir hin und müssen diesen Punkt bzw. Linie abfragen:

Wie stellen wir das an?
Ganz einfach, wir gehen hin und legen erstmal die Mitte des Bildes fest. Unser Bild ist 24*48 Pixel groß, was bedeutet, die mitte ist bei 12*24. Diesen Punkt makieren wir uns (rot) zusätzlich makieren uns noch diese drei Punke (blau). Warum das alles?
Die blauen Punkte sind nacher die Koordinaten die wir abfragen müssen, wenn wir uns bewegen wollen. Der rote Punkt ist der Bezugspunkt, auf den wir unsere Koordinaten beziehen müssen. Dies machen wir, indem wir den Abstand von X und Y festhalten. Dies schreibt euch am besten auf.
Eigentlich sollten dies für Punkt 1 (-12,24) Punkt 2 (0,24) und Punkt 3 (12, 24) sein. Dies sollten wir nun in den Maker übertragen, was so aussehen sollte:



Ich bin nun hingegangen und hab die eben errechneten bzw. gemessenen Abstände der Punkte und der Mitte des Bildes auf die neuen Koordinaten hinzuaddiert, da ein Bild im Maker bekanntlich immer von der Mitte aus auf diesen angezeigt wird.

Dadurch bekommen wir die Koordinaten dieser Punke, damit wir mit ihnen die TerrainID abfragen können, müssen wir hingehen und diese Koordinaten noch durch 16 teilen. Diese 16 kommt durch unsere Tilegröße zustande, da ein Tile 16*16 Pixel groß ist.

Von diesen Koordinaten fragen wir nun unsere TerrainID ab. Dazu benutzen wir die den Befehl "GetTerrainID" der sich auf der zweiten Registerseite befindet, linke Spalte.

Die Variable die wir in GetTerrainID abgegeben haben, fragen wir nun ab, ist sie gleich 2, befände sich einer der Punkte auf einem geblockten Tile, wodurch die Bewegung nicht zustande kommen sollte. Also gehen wir in diesem Falle ans Ende des Events. Ein Label schafft dort abhilfe.

Dies machen wir für alle 3 Punkte. Vor dem Label setzen wir nun noch die Pixelkoordinaten auf die TempKoordinaten.

Dies sollte so ungefähr aussehen:



Kommen wir zum letzen CE, der Bewegung:

Dort setzen wir nun ein MovePic auf das Bild mit der BildlabelNr5 rein und bewegen es zu den Koordinaten PixelX und PixelY.




So, das war Teil 1 meines Tutorials zur Planung und Umsetzung eines Pixelmovements mit dem Maker. Falls fragen diesbezüglich auftauchen sollten, bitte einen neuen Thread machen. Ich werd diesen dann mittels eines Links hierdrin erwähnen, da ich nicht will das dies hier vollgepostet wird und eine spätere Übersicht der einzellnen Teile flöten geht.^^". So, viel Spass!

[Kakashi]

Sehr schön und detailliert, das gehört ins Tut. forum!

[Veyrne]

Denke ich auch. Die Qualität reicht völlig.

(Beiträge können hier auf Wunsch gelöscht werden.)

[Zeph]

Sofern ich mich an den nächsten Teil setzen werde, sag ich dann Bescheid.