Beiträge von Kojote

Die guten Kacheln

Wenn ihr euer kleines einmal ausprobiert, dürftet ihr nun euren Protagonisten herumspringen sehen. Ganz gut bisher, doch fehlen noch ein paar Kleinigkeiten! Zum Beispiel unsere Kacheln fehlen noch, hierzu habe ich für euch einmal etwas vorbereitet:

rpgmakerforum.de/attachment/274/

Anmerkung: Die Grafik wurde aus dem Original Tileset des RPG Maker MV erstellt, ihr könnt sie also frei nutzen, so fern ihr den RPG Maker MV besitzt. Diese Grafik müsst ihr in euer Projekt einfügen unter:

Bibliotheken\Dokumente\Eigene Dokumente\Games\NAME EURES PROJEKTES\img\characters

Anmerkung: Der RPG Maker MV hat manchmal etwas Problem mit dem Nachladen von Grafiken, startet am besten noch einmal den Maker neu, wenn ihr die Grafik eingefügt habt.

Wie ihr noch von ganz am Anfang des Tutorials sicher wisst, sind dies die Bodenplatten, welche über dem Abgrund liegen. Ihr könnt euch nun heraus suchen, welche Bodenplatten begehbar werden und welche später zu einem Absturz führen. Oder ihr erstellt euch mit den freien Bodenplatten neue. Ich werde als begehbare Platten die erste Spalte nutzen, dazu den Mond aus der zweiten Spalte. Somit hätte ich fünf Symbole die ich betreten kann und sieben die ich nicht betreten kann.

Weiter geht es! Wir legen also jetzt fest, welche Tilesets begehbar werden. Dazu hatten wir uns ja auf dem Boden Markierungen gemacht. Alle Events, die auf einem blauen Untergrund liegen, bekommen jetzt eine Grafik zugewiesen.

Öffnet also euer Event 2, Bodenplatte 2, und klickt auf das Bild ganz rechts in eurem Ereignis-Editor:

rpgmakerforum.de/attachment/275/

In der linken Leiste suchen wir nun unsere Grafikdatei und wählen auf der rechten Seite unser Symbol aus. Ist es ausgewählt bestätigt ihr zwei Mal mit OK:

rpgmakerforum.de/attachment/276/

Habt ihr alles richtig gemacht, sieht es bei euch nun so aus:

rpgmakerforum.de/attachment/277/

Diesen Schritt wiederholt ihr nun bei allen anderen Events, die auf einem blauen Untergrund liegen. Achtet dabei etwas auf Abwechslung der Symbole:

rpgmakerforum.de/attachment/278/

Damit wären wir mit den „guten“ Kacheln fertig!

Die bösen Kacheln

In diesem Schritt werden wir uns nun um die „bösen“ Kacheln kümmern. Denn wir müssen noch festlegen was passiert, wenn der Protagonist auf eine falsche Kachel tritt. Entscheiden könnt ihr dies selbst, ob nun ein Pfeil kommt, der den Spieler abschießt oder ob er durch die Bodenplatte fällt oder etwas ganz anderes. Ich habe mich dazu entschieden, dass der Protagonist durch die Bodenplatte fällt.

Demzufolge müssen wir, sobald der Protagonist die Kachel betritt folgendes machen:

Der Protagonist muss unsichtbar werden, da er durch die Bodenplatte fällt

Die Begleiter des Protagonisten müssen unsichtbar werden, da sie ebenfalls durch die Bodenplatte fallen

Es muss ein Sound abgespielt werden, dass die Bodenplatte bricht

Es muss ein Loch im Boden angezeigt werden, durch welches Protagonist und seine Begleiter fallen

Der Spieler muss Game Over gehen

Als Beispiel dient uns Bodenplatte 5. Am Ende unserer Bedingungsabfrage kommt als erstes der Befehl, dass der Protagonist unsichtbar ist. Dazu gehen wir in die Ereignisbefehle auf die zweite Reiterseite. Auf dieser Seite aktivieren wir Transparent ändern..., Schalten die Transparenz auf EIN und bestätigen mit OK:

rpgmakerforum.de/attachment/279/

Auf derselben Reiterseite finden wir auch den passenden Befehl, um unsere Gruppe unsichtbar zu machen. Wir gehen auf Spieler-Gefolge ändern und sagen hier AUS, bestätigt wird wieder mit OK:

rpgmakerforum.de/attachment/280/

Bei euch sieht das ganze demnach so aus:

rpgmakerforum.de/attachment/281/

Fertig? Dann geht es weiter, wir brauchen noch einen Sound, der zeigt, dass die Bodenplatte bricht. Geht wieder in die Ereignisbefehle auf die zweite Reiterseite und suchen uns SE abspielen.

Eingestellt wird hier folgendes:

SE-Sound: Damage2

Lautstärke: 90%

Tonhöhe: 50%

rpgmakerforum.de/attachment/282/

Anschließend wird wieder mit OK bestätigt.

Was nun noch fehlt, ist das Loch im Boden, dazu erstellen wir erst einmal einen Eigenschalter, der uns auf eine neue Eventseite bringt. Geht in die Ereignisbefehle auf die erste Reiterseite. Klickt hier auf Selbstschalter steuern, im neuen Fenster auf Selb.schalter A, Operation EIN, wie immer bestätigen wir mit OK.

Passt auf, dass dieser Befehl ganz am Ende steht:

rpgmakerforum.de/attachment/283/

Erzeugt wird nun als letztes eine neue Ereignisseite, dies funktioniert recht einfach im Ereignis Editor:

rpgmakerforum.de/attachment/284/

Es öffnet sich ein neuer Reiter, in diesem stellen wir folgendes ein:

Selb.schalter: A

Optionen: Gehen und Richtung Fixieren

Priorität: Unter Charakter

Auslöser: Autorun (Autorun ist dafür da, dass das Event sofort gestartet wird, sobald es aufgerufen wird und der Protagonist sich nicht bewegen kann)

rpgmakerforum.de/attachment/285/

Fassen wir noch einmal zusammen, was passiert nun:

Sobald der Protagonist das Event betritt, wird sowohl er, als auch seine Gruppe unsichtbar geschaltet. Ein Sound wird abgespielt, dass die Bodenplatte bricht und das Event wird auf eine neue Eventseite umgeleitet. Dies alles würde innerhalb eines Bruchteils einer Sekunde passieren. Der Protagonist geht also auf die Platte und wäre sofort Game Over. Recht unschön, denn der Spieler wird nun machen: Hääää???? Es muss also Zeit gegeben werden, das der Spieler realisiert, dass der Protagonist durch die Bodenplatte bricht.

Wir sorgen also für einen Halt, dies nennt man Warte-Befehl. Geht also auf die zweite Reiterseite der Ereignisbefehle und da auf Warten. Hier stellen wir einen passenden Wert ein, ich trage 80 Frames ein. Ein Frame bedeutet 1/60 einer Sekunde. Stelle ich also 80 Frames ein, wird ein Wartebefehl von 1,3 Sekunden ausgeführt. Ihr könnt hier gern etwas mehr oder weniger eintragen, ist halt Geschmackssache. Bestätigt wird wie immer mit OK.

rpgmakerforum.de/attachment/286/

Im letzten Schritt auf dieser Eventseite wird noch der Game Over ausgelöst. Wieder einmal begeben wir uns in das Fenster der Ereignisbefehle, dieses Mal dritte Reiterseite, hier finden wir ganz groß Game Over:

rpgmakerforum.de/attachment/287/

Als aller letztes auf dieser Eventseite müssen wir die neue Grafik des Events eintragen, den Schaden im Boden. Ihr kennt den Schritt schon aus Teil 4 des Tutorials, aus diesem Grund erkläre ich nicht noch einmal alles. Das Event würde nun so aussehen:

rpgmakerforum.de/attachment/288/

Damit wäre diese Eventseite auch fertig. Da auf jeder Bodenplatte dasselbe passiert, können wir die nun erstellten Eventbefehle Kopieren und in den Events einfügen, die einen roten Untergrund haben.

Zu allererst kopieren wir uns die Eventseite und fügen sie durch Einfügen in den anderen Events ein:

rpgmakerforum.de/attachment/289/

Danach müssen wir noch den letzten Teil des Events kopieren:

rpgmakerforum.de/attachment/290/

Mit gedrückter Shift-Taste, markiert ihr euch den gesamten Bereich und fügt ihn in alle anderen Events ein, die einen roten Untergrund haben.

Fertig? Dann fehlen nun noch die restlichen Grafiken der roten Events. Dieses Mal nutzt ihr die Grafiken die übrig sind, keinesfalls die gleichen, die wir bei den guten Kacheln verwendet haben, bei mir sieht das ganze nun so aus:

rpgmakerforum.de/attachment/291/

Wie ihr seht, habe ich den Boden wieder komplett grau gefärbt. Im Grund genommen könnt ihr die Markierungen unter den Kacheln lassen, es ist eine gute Hilfe, falls ihr mal etwas verändern wollt. Da die Kacheln genau so groß sind wie der Untergrund würde man die Farbe auch nicht sehen. Ich habe sie nur einmal für euch entfernt, damit ihr die nun fertigen Kacheln besser sehen könnt.

Im Grunde genommen wäre das Event nun fertig und bespielbar. Doch fehlt dem Spieler noch der Hinweis, welche Kacheln er betreten kann und welche besser nicht. Ihr könnt dies machen wie ihr wollt, ich werde dem Spieler im nächsten Teil des Tutorials eine kleine Hilfe geben.

Die Hilfe

In diesem Teil werden wir den Spieler eine kleine Hilfe geben, wie er unbeschadet auf die andere Seite kommt. Dazu habe ich an der Wand einen kleinen Zettel angebracht und ein Event erzeugt. Da ich dies alles schon einmal erklärt habe, hier nur einmal kurz meine Einstellungen:

rpgmakerforum.de/attachment/292/

Um den Spieler eine Hilfe zu geben, werde werden wir den Spieler eine Grafik anzeigen lassen, genauer gesagt dies hier:

rpgmakerforum.de/attachment/293/

Eingefügt wird die Grafik in eurem Projekt unter:

Bibliotheken\Dokumente\Eigene Dokumente\Games\NAME EURES PROJEKTES\img\pictures

Anmerkung: Die Grafik des Pergaments ist frei von pixbay.de von OpenClipart-Vectors, das Geschmiere darauf ist von mir, ihr könnt sie gern verwenden.

Gehen wir zurück zum Event, hier soll das Bild langsam, mit einem kleinen Blendeffekt eingefügt werden. Dazu gehen wir wieder einmal in den Ereignisbefehlen, auf die zweite Reiterseite. Wir suchen uns den Befehl Bild anzeigen... und stellen folgendes ein:

Bild Nummer: 1

Bild: Laurenz_Schatz_Zettel

Deckkraft: 0 (bedeutet das, dass Bild zwar aufgerufen wird, es jedoch keine Deckkraft hat, sprich es ist unsichtbar)

Alles andere lassen wir genau so und bestätigen wie immer mit OK.

rpgmakerforum.de/attachment/294/

Damit wir einen Blendeffekt bekommen, gehen wir abermals in die Ereignisbefehlen und klicken auf Bild bewegen..., hier werden folgende Einstellungen vorgenommen:

Bild Nummer: 1

Deckkraft: 255 (bedeutet das, dass Bild nun auf volle Sichtbarkeit geschalten wird)

Dauer: 60 (bedeutet das, dass Bild innerhalb von 60 Frames (1 Sekunde) voll sichtbar wird)

Warten auf Schluss muss markiert sein (sorgt dafür das, dass Bild erst komplett angezeigt wird, bis ein weiterer Eventbefehl bearbeitet wird)

Wie immer, OK zum Bestätigen, damit hätten wir das Bild erst einmal angezeigt:

rpgmakerforum.de/attachment/295/

Das Bild wäre jetzt für den Spieler sichtbar, doch wollen wir auch, dass der Spieler das Bild wieder entfernen kann. Aus diesem Grund nutzen wir nun eine Schleife. Eine Schleife im RPG Maker ist ein Prozess der innerhalb eines Events so lange abgespielt wird, bis man ihn beendet, keinesfalls ist dies mit einem Parallelen Prozess zu verwechseln. Eine Erläuterung folgt gleich.

Die Schleife findet ihr in den Ereignisbefehlen, auf die ersten Reiterseite:

rpgmakerforum.de/attachment/296/

Nun zur Erklärung, die Schleife würde nur den dauerhaft markierten Bereich wiederholen, so lange, bis aus dem inneren Bereich der Schleife ein Abbruch Befehl kommt. Der Unterschied zu einem Parallelen Prozess ist, dass der Parallele Prozess ständig das gesamte Event abarbeitet, die Schleife nur einen begrenzten Bereich:

rpgmakerforum.de/attachment/298/

Warum brauchen wir eine Schleife? Wir werden jetzt, so lange das Bild angezeigt ist dauerhaft abfragen, ob der Spieler eine Taste drückt. Drückt er diese Taste, wird das Event beendet und die Grafik wird wieder vom Bildschirm verschwinden.

Dazu erzeugen wir eine Bedingungsabfrage, gehen in Bedingte Verzweigung auf die vierte Reiterkarte und wählen eine Tastenabfrage aus, hierbei die Taste OK, diese Taste wäre die Enter-Taste auf der Tastatur:

rpgmakerforum.de/attachment/299/

Wir fragen also dauerhaft ab, ob die Enter-Taste gedrückt wird, passiert dies, soll die Schleife verlassen werden, dazu nutzen wir den Befehl Schleife unterbrechen in den Ereignisbefehlen, auf Reiterseite 1:

rpgmakerforum.de/attachment/300/

Die Schleife hat beim RPG Maker einen kleinen Bug. Würde man diese Einstellungen nun so nutzen würde sich der RPG Maker bzw. das Spiel aufhängen. Grund ist, dass die Schleife sehr schnell abgearbeitet wird und durch die schnellen und vielen Wiederholungen sich beinahe versucht, selbst zu überholen. Dabei entsteht ein Bug und das Spiel friert ein. Diesen Bug kann man aber leicht beheben, in dem wir einen Warte-Frame einfügen, dieser löst das Problem:

rpgmakerforum.de/attachment/301/

Was soll nun noch passieren? Das Bild soll langsam ausgeblendet werden, dazu nutzen wir wieder den Befehl Bild bewegen..., dieses Mal wird aber die Deckkraft auf 0 gesetzt:

rpgmakerforum.de/attachment/302/

Zum Schluss soll das Bild wieder verschwinden, dazu nutzen wir den Befehl Bild löschen...:

rpgmakerforum.de/attachment/303/

Am Ende sieht das Event so aus:

rpgmakerforum.de/attachment/304/

Damit wären wir am Ende unseres kleines Tutorials angekommen. Ich hoffe ihr hatten Spaß daran und könnt euer Spiel um ein schönes, kleines Minispiel erweitern. Ich wünsche Euch viel Erfolg!

Grüße!

Ich will vor dem Ausführen eines Events überprüfen ob er Spieler einen bestimmten Gegenstand im Inventar hat. Normal könnte man das über eine Bedingungsabfrage machen. Problem ist, bei 20 Items wird das etwas sinnlos und unübersichtlich. Kennt jemand nen Scriptcall mit dem man ein bestimmtes Item abfragen kann?

Schreibst du jetzt für mich nen Plugin oder? XD

Oh man, hab es doch noch hinbekommen. Das Plugin hat leider einen kleinen Bug.

Hab jetzt nen anderes Plugin gefunden, was die selbe Funktion erfüllt.

Hehe, der Gedanke war gut, doch der Maker noch nicht so weit. Funktioniert doch nicht, ganz schön kniffelig.

Also wie ich raus gefunden habe, funktioniert der Code oben im MV. Im MZ leider nicht mehr. Hab jetzt nen Plugin gefunden mit dem das geht, aber leider wieder ein Plugin mehr in der Liste. Was geht versuch ich immer mit Events oder Scripts zu lösen.

Man müsste echt mal ne Austauschrunde mit den Resourcen machen.

Ressourcen sind so echt das wichtigste was es für den Maker gibt und davon kann man prinzipiell nie genug haben. Wenn ich was finde, lade ich es immer gleich herunter. Vieles ist jetzt schon nicht mehr zugänglich. Durch Zufall vor ein paar Tagen die Ressourcen von whtDragon gefunden, alle Bildlinks DOWN. Echt ein Jammer!

Ich soriere immer nach Künstler und dann in Unterordnern nach Charset, Picture, Tileset und so weiter. Hab gerade mal geschaut, meine Sammlung ist 3,37 GB groß mit 17.251 Dateien.

Wobei ich bei dir schon gesehen habe, dass du ganz viele Tilesets und Co. hast, die nicht auf meiner Festplatte zu finden sind. Meine Sammelwut ist also noch nicht zu Ende.

Du warst im Spielzeugdesign tätig? Was hast du denn da gemacht, jetzt bin ich neugierig!

Es würde um die selbe Variable gehen, Maker ist der MZ. Habe gerade mal einen Test gemacht.

[definition='2','0']Variable[/definition] 15 = 0.
Danach [definition='2','0']Variable[/definition] 15 gesetzt auf den Wert 5.

Anschließend den Code genutzt:

function save () {
var fs = require ("Variablen Test");
fs.writeFileSync ("./ba", $gameVariables.value(15));
}

Funktioniert leider nicht.

EDIT:

Anscheinend muss man das so schreiben, fs ist keine Variable sondern von NodeJS ein Modul:

function save () {
var fs = require ("fs");
fs.writeFileSync ("./ba", $gameVariables.value(15));
}

Funktioniert aber trotzdem net.

Hi!

Jetzt mal eine ganz verrückte Frage! Ist es möglich eine Variable oder einen Schalter zu speichern, die beim Laden nicht verloren geht?

Beispiel:

Variable A = 0.

Ich speichere das Spiel.

Jetzt ändere ich Variable A = 1 und lade danach das Spiel.

Logischerweise ist nach dem Laden Variable A wieder 0, da das ändern nicht gespeichert wurde.

Ist es möglich dies zu umgehen?

Da hilft nur gute Organisation.

Sieht sehr gut aus! Gestehen muss ich schon, die Versuchung lockt da echt. Vormappen und dann in Photoshop nachbearbeiten...

Zitat von IanZarewitsch

Hier mal mein warming up von heute früh, hab mir nen Zeitlimit von einer Stunde gesetzt. Hab ne ganze Pinterestwand mit irgendwelchen Insekten oder Unterwasserwesen, die ich zum Üben benutze.

Ich hoffe die Tierchen sind klein, im großen Maßstab will man denen sicherlich nicht begegnen.^^

Ansonsten gefallen sie mir sehr gut!

Bei Overlaymapping muss man eindeutig Kosten und Nutzen abwägen. Je nach dem wie viel Zeit man in sein Projekt investieren kann macht das schon ein wenig was aus.

Wir haben uns bei unserem neuen Projekt so entschieden, dass wir normales Mapping nutzen um so gut vorran zu kommen und wir eventuell nachher die ein oder andere Karte noch einmal mit Overlay überarbeiten. Das erspart auch den Ärger, dass wenn man noch einmal eine Änderung vornimmt das im Maker in ein paar Minuten erledigt ist, im Overlay ein rießen Berg Arbeit wird.

Wenn ich jetzt mal hoch rechte mit der letzten Overlaymap die ich machte. Alles in allem fast eine Woche Arbeit für eine Map. Bei 100 Maps, die bei einem großen Spiel schnell zusammen kommen sind das 100 Wochen. Das sind zwei Jahre Projektarbeit und das nur wenn ich das Tempo halte und nicht zwischendurch mal etwas anderes mache. Wenn man nun noch Planung und andere Sachen einrechnet, wäre ich mit Overlay bei einem 100 Maps Spiel bei gut und gern drei Jahren.

Rechne ich mal dagegen, dass ich eine "normale" Map in gut zwei Tagen fertig habe, wenn ich genau so viel Zeit rein stecke, brauche ich für das selbe Projekt "nur" ein Jahr.

Ah, dass meinst du. OK schau ich mir mal an.

Zitat von FlipelyFlip

Kojote sieht wirklich gut aus, bin schon gespannt, wie es da weiter geht
Das einzige, das mich an dem ganzen Screen stört, ist der "Sprechblasenpfeil", dass der nicht direkt an der Leiste von der Textbox anknüpft, sondern als eigenständiges Ding wirkt. Ist jetzt aber wirklich nur Nitpicking auf höchstem Niveau.

lg Flipely

Was meinst du genau damit? Wie dieser Pfeil an der Box hängt?

Der Schadensmanager

Tja, jetzt fahren zwar unsere Stacheln schön ein und aus, das bringt uns aber nicht viel. Wir müssen ja noch festlegen, wann der Spieler wo hin laufen kann, ohne das ihn etwas piekst und tötet bzw. er verletzt wird. Aus diesem Grund nutzen wir Regions IDs. Einige werden sich nun fragen: Was sind Region IDs? Das ist recht einfach zu erklären.

Zwei der eingekreisten Symbole dürften euch bekannt vor kommen – „Karte“, „Events“ und gleich daneben ist „Regions“. Klickt mal drauf. Die Karte wird nun etwas blass und die Tilesets sind weg. Stattdessen sind da Nummern. Dies sind die Regions IDs. Klickt man sie an und „zeichnet“damit auf der Karte herum, legt man unsichtbare Markierungen aus. Diese nutzen wir nun zur Markierung, damit der Maker weiß, wo unser kleiner Protagonist steht.

Auf alle Flächen, wo Events des „Rasters I“ drauf sind, legen wir die Regions ID 1.

Auf alle Flächen, wo Events des „Rasters II“ drauf sind, legen wir die Regions ID 2.

Nun müsste es so bei euch aussehen:

Regions IDs gesetzt? Dann geht es nun zu den Events zurück.

Wir brauchen ein neues Event mit dem Namen „Schadensmanager“.

Einzige Einstellung:

Auslöser: Paralleler Prozess

Nun zum Inhalt:

Warte = 2 Frames (wieder eine Sicherung gegen Lags)

Variable Koordinate Spieler X

Variable Koordinate Spieler Y

Variable Feld ID

Dies sind die Variablen, die wir brauchen. Spieler X und Y einzustellen ist recht einfach. Am besten zu erklären mit einem Bild, hier als Beispiel für die X Koordinate. Y Funktioniert genauso:

Feld ID Infos ruft man etwas anders ab. Feld ID Info ist auf Seite drei der Eventbefehle zu finden.

Wir setzen den Variablennamen ein

Info-Typ ist Region ID

Bestimmungsort wird durch die Variablen X und Y des Spielers ermittelt

Wir fragen also ab, auf welchem Regions-ID-Feld der Spieler ist.

Fertig sieht der ganze Spaß nun so aus:

An dieser Stelle kommen wir nun zu den beiden Schaltern, die wir vorhin gesetzt haben. Ihr erinnert euch sicherlich an die Schalter „Raster I“ und „Raster II“.

Wir hatten es so gemacht, dass der Schalter „Raster I“ an ist, wenn die Stacheln ausgefahren sind, dasselbe bei „Raster II“.

Darum fragen wir nun ab:

Bedingung Schalter „Raster I“ AN?

Wenn nein, passiert nichts wenn ja, beginnt die nächste Bedingung.

Bedingung Regions ID = 1?

Genau hier für brauchten wir die Regions IDs! Ist die Regions ID nicht 1, passiert gar nichts. Wäre aber Regions ID so groß wie 1, wissen wir also, der Spieler steht auf Regions ID 1. Was bedeutet das?

Durch den Schalter „Raster I“ wissen wir bereits, dass die Speere ausgefahren sind. Dadurch, dass die Regions ID die Größe 1 hat, wissen wir auch, dass der Spieler auf einem Feld stehen muss, der zu „Raster I“ gehört, dessen Speere ja ausgefahren sind. Was passiert, wenn der Protagonist Bekanntschaft mit ein paar Speeren macht?

Bei mir passiert folgendes:

Der SE Sound „Cry2“ wird abgespielt

Warte 50 Frames – muss hier sein, weil der Sound gar nicht abgespielt werden würde und der Maker weiter hetzt

Der Zustand des Spielers wird geändert in Tod – bedeutet Game Over!

Das Selbe wiederholen wir bei „Regions ID = 2“ und Schalter „Raster 2“:

Für die, die nicht wissen, wie man den Zustand des Spielers ändert:

Im übrigen kann man außer der gesamten Gruppe auch einstellen, dass nur ein Bestimmter aus der Gruppe stirbt, ich habe ich es jetzt so gelassen, da es egal ist.

Speichert noch zum Schluss mit OK ab.

Damit sind wir am Ende des Tutorials angelangt. Ich wünsche euch viel Spaß beim Nachbau! Für alle Detailverliebten, geht es im nächsten Kapitel noch ein wenig weiter.

Ein klein wenig Detailverliebtheit

Willkommen im Bereich für diejenigen, die detailverliebt sind!

Messerscharfe Speere schießen aus dem Boden aber ... Moment mal! Die machen keine Geräusche? Unglaubwürdig, darum spielen wir noch einmal mit Regions IDs herum und erweitern unsere Karte damit noch etwas.

Mit den Regions IDs steuern wir unsere Geräusche, dabei gilt: Um so weiter weg, um so größer die Regions ID.

Der nächste Schritt ist also ein neues Event, welches wir „Klingengeräusch“ nennen.

Bedingung: Ein neuer Schalter namens „Klingengeräusch 1“ – wir arbeiten hier mit zwei Geräuschen, einmal, wenn die Klingen ausgefahren werden (Schalter „Klingengeräusch 2“) und einmal, wenn die Klingen eingefahren werden (Schalter „Klingengeräusch 1“). Wo wir die Schalter setzen, erkläre ich gleich.

Auslöser: Paralleler Prozess

Die Regions ID, die wir brauchen, wird ja schon im Event „Schadensmanager“ abgefragt, darauf können wir in diesem Event gleich aufbauen.

Zum Inhalt:

Wir fragen ab: ist die Regions ID 1, also steht der Spieler auf einem Regions ID 1 Feld?

Wenn nein, passiert nichts.

Wenn ja, passiert folgendes:

Der SE Sound „Sword3“ wird abgespielt, Lautstärke 80%

Schalter „Klingengeräusch 1“ wird ausgeschaltet

Aber warum?

Ganz einfach: Die Speere fahren zusammen aus, da brauchen wir nur ein Geräusch. Schalten wir nun diesen Schalter nicht aus, würde der SE durch den parallelen Prozess in jedem Frame neu abgespielt werden. Hört sich nicht sehr schön an und wir brauchen den Sound ja nur einmal.

Andernfalls:

Wir fragen ab: ist die Regions ID 2, also steht der Spieler auf einem Regions ID 2 Feld? Wenn nein, passiert nichts.

Wenn ja, passiert folgendes:

Der SE Sound „Sword3“ wird abgespielt, Lautstärke 80%

Schalter „Klingengeräusch 1“ wird ausgeschaltet

Andernfalls:

Wir fragen ab: ist die Regions ID 3, also steht der Spieler auf einem Regions ID 3 Feld? Wenn nein, passiert nichts.

Wenn ja, passiert folgendes:

Der SE Sound „Sword3“ wird abgespielt, Lautstärke 70%

Schalter „Klingengeräusch 1“ wird ausgeschaltet

Andernfalls:

Wir fragen ab: ist die Regions ID 4, also steht der Spieler auf einem Regions ID 4 Feld?

Wenn nein, passiert nichts.

Wenn ja, passiert folgendes:

Der SE Sound „Sword3“ wird abgespielt, Lautstärke 60%

Schalter „Klingengeräusch 1“ wird ausgeschaltet

etc.

Danach müsste es bei euch so aussehen:

Damit haben wir die erste Reiterseite fertig. Diese kopieren wir uns jetzt.

Änderungen an der zweiten Reiterseite:

Bedingung: Ein neuer Schalter Namens „Klingengeräusch 2“

Die Schalter im Inhalt die deaktiviert werden auf „Klingengeräusch 2“ ändern

Das SE Geräusch auf „Sword4“ ändern

Fertig! Damit kann das Event mit OK geschlossen und gespeichert werden. Als letztes öffnen wir uns noch einmal das Event „Schadensmanager“. Hier werden wir nun nämlich festlegen, wann die Schalter „Klingengeräusch 1“ und „Klingengeräusch 2“ angeschaltet werden.

Wir rufen uns kurz ins Gedächtnis:

Schalter „Klingengeräusch 1“ für das Geräusch, wenn die Speere in den Boden gehen

Schalter „Klingengeräusch 2“ für das Geräusch, wenn die Speere aus dem Boden kommen

Schalter „Klingengeräusch 1“ gleich am Anfang anschalten, da als erstes die Speere eingefahren werden.

Etwas weiter unten Schalter „Klingengeräusch 2“ anschalten, da die Speere aus dem Boden kommen.

Noch viel weiter unten Schalter „Klingengeräusch 1“ gleich anschalten, da die Speere wieder eingefahren werden.

Fast am Ende noch einmal Schalter „Klingengeräusch 2“ anschalten, da die Speere aus dem Boden kommen.

Das war es schon. Von nun an gibt es auch Geräusche, wenn die Speere ein- und ausfahren.

Damit endet dieses Tutorial. Ich wünsche euch viel Spaß beim nachbauen!

Stimmt, das hatte ich nicht bedacht, dass könnte man natürlich auch so machen.

Der Absturzmanager

Damit wäre die Brückensteuerung fertig, aber dies bringt uns bis jetzt gar nichts. Denn wie ihr euch sicher erinnert haben wir ja ganz am Anfang die Begehbarkeit geändert, so dass der Spieler über den schwarzen Bereich unter der Brücke laufen kann.

Bisher ist es so, dass der Spieler überall im Bereich der Brücke stehen kann, egal ob unter ihm ein Brückenteil ist. Dies wollen wir jetzt ändern und zwar mit Regions IDs. Eine nähere Erläuterung zu Regions IDs werde ich jetzt nicht aufzeigen. Wie man Regions IDs nutzt erwarte ich jetzt einfach mal auf dem Schwierigkeitsgrad dieses Tutorials. Andernfalls seht in meinen Tutorials „Stachelfallen-Rätsel“ und „Flammen-Rätsel“ nach, da habe ich zu diesem Thema denke ich ausreichend geschrieben.

Bei mir sehen meine Regions IDs so aus:

Unter jedes Stück Brücke muss eine Regions ID, ausser bei m Anfang und Ende hier verschwindet die Brücke ja nicht.

Da der Spieler auch nur in diesem kleinen Bereich den schwarzen Bereich betreten kann, werden wir es auch nur hier möglich machen, dass der Spieler in die Tiefe fällt. Alle anderen schwarzen Bereiche können nicht betreten werden.

Alternativ hätte man auch alles schwarz betretbar machen können. Dann müssten wir aber alles mit Regions IDs am Rand des schwarzen Feldes voll pflastern. Da ich es aber so einfach wie möglich halten will und es nur noch mehr Eventerei geworden wäre hab ich es so gemacht.

Aber kommen wir zurück zum oberen Bild. Ihr seht das es eine Merkwürdigkeit gibt! Am Anfang ist es bei Regions ID 10 bis 14 eine ganze Reihe mit einer ID belegt. Später hat jedes Feld eine eigene ID. Warum?

Ganz einfach: Bei den Regions IDs 10 - 14 handelt es sich um Brückenteile die immer zusammen aktiviert oder deaktiviert werden.

Haben wir aber solche Fälle in dem nur ein Brückenteil verschwindet, können wir diesen Mechanismus nicht anwenden.

Ein Beispiel:

Wir aktivieren den Schalter „Reihe 7“. Alle drei Events wären aktiv, über die gesamte Breite ist die Regions ID.

Wir würden Abfragen:

Ist der Schalter 7 AN?

Wenn JA fragen wir ab: Ist der Spieler auf einer Regions ID die unter der Reihe 7 ist?

Wenn Ja ist alles OK, wenn nein würde der Spieler in den Abgrund sausen.

Nun das Problem!

Ändern wir die Voraussetzungen und sagen Schalter „Reihe 7 L M“ ist AN, es sind nur die Events „Reihe 7 I“ und „Reihe 7 II“ an und wir haben immer noch über die gesamte Breite nur eine Regions ID.

Wir würden Abfragen:

Ist der Schalter 7 L M AN?

Wenn JA fragen wir ab: Ist der Spieler auf einer Regions ID die unter den Events „Reihe 7 I“ und „Reihe 7 II“ ist?

Wenn der Spieler auf „Reihe 7 I“ und „Reihe 7 II“ steht ist alles in Ordnung, dann stimmt es ja auch.

Aber was wenn der Spieler auf dem nicht aktiven Event „Reihe 7 III“ steht? Der Maker wüsste gar nicht was er machen sollte, somit könnte der Spieler einfach da stehen bleiben, ohne das etwas passiert. Drum müssen wir es aufschlüsseln!

Wir würden Abfragen:

Ist der Schalter 7 L M AN?

Wenn JA fragen wir ab: Ist der Spieler auf einer Regions ID die unter dem Event „Reihe 7 I“ ist?

Wenn JA ist alles in Ordnung!

Wenn Nein fragen wir ab: Ist der Spieler auf einer Regions ID die unter dem Event „Reihe 7 II“ ist?

Wenn JA ist alles in Ordnung! Andernfalls muss der Spieler logischerweise auf einem Feld stehen, auf dem zur Zeit kein Brückenteil aktiv ist, was bedeuten würde er steht im schwarzen Bereich und dies bedeutet Game Over für ihn.

Bitte lasst euch beim nächsten Schritt nicht verwirren. Da fragen wir zuerst die Regions ID des Spielers ab und dann erst ob ein Schalter da ist. Gerade eben habe ich es nur anderes herum aufgebaut, damit man besser versteht wo das Problem liegt. Kommen wir nun zu einem neuen Event mit dem Namen „Absturzmanager“.

Einzustellen wäre:

Auslöser: Paralleler Prozess

Dies wäre schon alles, nun aber zum Inhalt der es etwas in sich hat.

Wir müssten normalerweise hier jetzt die X und Y Koordinaten, sowie die Regions ID Abfrage des Spielers einbauen. Da ich aber diese Variablen aus einem anderen Teil des Tutorials nutze, brauche ich sie hier nicht noch einmal auslesen. Dies machen wir schon in einem Event was zum Stachelfallenrätsel gehört.

Wait 2 Frames - unsere Standardwartezeit gegen Lags.

Wir fragen ab: Ist die Regions ID 10? Wenn nein geht es einfach so weiter.

Wenn Ja muss der Spieler auf diesem Regions ID feld stehen. Darum fragen wir weiter ab: Ist der Schalter „Reihe 2“ an, unter dem die Regions ID 10 ist? Wenn Ja ist alles in Ordnung, der Spieler steht brav auf der Brücke.

Wenn Nein, steht der Spieler nicht auf der Brücke und es folgt:

Musikeffekt SE „Fall“ wird abgespielt.

Wir schalten den Spieler auf unsichtbar (er ist ja nicht mehr zu sehen da er herunter gefallen ist).

Warte 40 Frames, damit der Maker nicht weiter hetzt und genug Zeit ist um den SE ab zu spielen.

Der Zustand wird geändert: + Tod

Da der Spieler nun Tod ist, würde nun automatisch der Game Over Bildschirm kommen.

Aber es gibt ja noch mehr Regions IDs die der Spieler betreten kann:

Etwas haarig wird es nun bei den einzelnen ID Feldern, da sind Größe Abfragen vonnöten wenn verschieden Schalter aktiv sein können.

Nehmen wir z.B. die Regions ID 23.

Wir sehen hier drei mögliche Zustände:

Schalter „Reih 9“ kann angeschalten sein, dann wären die Events „Reihe 9 I“, „Reihe 9 II“ und „Reihe 9 III“ eingeschalten

Schalter „Reih 9 L R“ kann angeschalten sein, dann wären die Events „Reihe 9 I“ und „Reihe 9 III“ eingeschalten

Schalter „Reih 9 R“ kann angeschalten sein, dann wäre das Event „Reihe 9 I“ eingeschalten

Wir würden Abfragen:

Ist die Regions ID des Spielers 23?

Wenn Ja, fragen wir ab, ist der Schalter „Reihe 9“ eingeschalten?

Wenn JA, alles in Ordnung!

Wenn Nein, fragen wir ab, ist der Schalter „Reihe 9 L R“ eingeschalten?

Wenn Ja, alles in Ordnung!

Wenn Nein, fragen wir ab, ist der Schalter „Reihe 9 R“ eingeschalten?

Wenn Ja, alles in Ordnung!

Wenn Nein, dann muss es unter dem Spieler sehr schwarz sein, denn da ist keine Brücke und er stürzt in die Tiefe!

Ihr müsst nun alle Regions ID`s nach einander durch gehen und genau so abfragen. Vergesst dabei keine Schalter, dies ist das wichtigste!

Damit wäre dieser Teil des Rätsels fertig und lass euch jetzt einmal in Ruhe eure Regions IDs durch gehen.

Der Schalter

Der wohl kürzeste Teil des gesamten Rätsels. Da wir bei der Steuerung mit einem parallelen Prozess arbeiten, würde die Brücke sofort anfangen los zu legen, wenn wir die Karte betreten. Aus diesem Grund haben wir uns aber eine Bedingung eingebaut, wie ihr euch sicherlich erinnert, nämlich den Schalter „Brückenschalter“. Dieser muss erst einmal angeschalten sein, damit die Brücke los legt und darum kümmern wir uns nun.

Wir brauchen ein neues Event mit einem Schalter. Den setzen wir uns neben die Brücke und nenen ihn „Brückenschalter“.

Einzustellen ist:

Ebenenpriorität: Auf Spielerebene

Auslöser: Aktionstaste

Grafik ist ein Hebelschalter dessen Hebel ganz links ist

Als Option stellen wir ein

Als Inhalt kommt nur:

Schalter „Schalter Brücke“ = AN

Eigenschalter A = AN

Dies wäre auch schon alles für diese Eventseite.

Und los geht es mit der Brücke! Aber was jetzt, wir haben es nicht rechtzeitig auf die Brücke geschafft und sie legt ohne uns los?

Dann brauchen wir einen Neustart der Brücke, aus diesem Grund legen wir uns eine zweite Reiterseite an.

Kopiert am besten wieder die Reiterseite 1 und ändert folgendes:

Grafik ändern zum gleichen Schalter, nur der Hebel ist nun ganz rechts

Bedingung auf Eigenschalter (im engl. Self Switch) A = AN

Der Inhalt wird komplett gelöscht und wird durch folgendes ersetzt:

Schalter „Schalter Brücke“ AUS - damit stoppen wir die Brücke

Da ja schon ein paar Schalter der Brücke an- und ausgeschalten wurden, müssen wir diese Schalterstellungen auch alle rückgängig machen und nutzen dazu gleich einmal einen Schalter Massenbefehl. Mit diesem kann man Schalter von einem bestimmten Schalter bis zu einem anderen bestimmten Schalter umstellen. Bei mir wären es die Schalter 32 bis 56 die für die Brückensteuerung zuständig sind. Anweisung wäre natürlich alle ausschalten.

Eigenschalter A = AUS - damit kommen wir zurück zur ersten Reiterseite und können von neuen den Hebel umlegen

Damit wären wir am Ende des Tutorials angelangt.

Ich wünsche euch viel Spaß beim nachbauen!

Stachelfallenrätsel-Tutorial

Engine: Das Tutorial wurde mit dem RPG Maker VX Ace erstellt, funktioniert jedoch mit jedem anderen RPG Maker.

Rechte: Für kommerzielle und nicht-kommerzielle Verwendung im RPG Maker.

Credits: Game Alchemists - http://gamealchemists.com

Einleitung

Wo ist Laurenz denn jetzt nur wieder gelandet? Merkwürdige Löcher im Boden ... eigenartig!

Was nun?

Schauen wir uns die Sache doch einmal genauer an.

Hier scheint ein gefährlicher Weg anzufangen – spitze Stacheln schießen aus dem Boden, bereit, Laurenz zu Schaschlik zu verarbeiten! Ein spannendes Geschicklichkeitsspiel.

Um was geht es in diesem Tutorial?

In diesem Tutorial befassen wir uns mit einem Fallen-Rätsel. Wir haben eine Fläche vor uns, gespickt mit Speeren die aus dem Boden kommen. Jedoch tun sie dies nicht willkürlich! Wer den Weg hindurch findet, hat das Rätsel gelöst und überlebt diese Aufgabe.

Die Stachelfallen

Kommen wir zum ersten Punkt des Tutorials – den Stacheln. Zuerst brauchen wir unsere Grundkarte, bei mir sieht sie so aus.

Beachtet bitte, dass der Durchgang für unser Rätsel immer eine ungerade Anzahl an Feldern breit sein muss! Bei mir ist der Durchgang sieben Felder breit.

Im Bereich des Durchgangs werden wir nun unsere Stacheln einbringen.

Schon einmal zum Vormerken: Die Stacheln werden in einem Raster aufgelegt. Es gibt zwei Gruppen. Eine Stachelgruppe, die gerade eingefahren ist (nennen wir sie schwarze Gruppe) und eine Gruppe, die gerade ausgefahren ist (nennen wir sie weiße Gruppe). Zwischen dem Wechsel der Gruppen besteht eine Pause, in der sich der Spieler sicher bewegen kann. Hier eine Veranschaulichung, damit ihr seht, auf was es hinausläuft.

Aber nun der Reihe nach. Wir legen unser erstes Event an. Wie ihr seht, sind die eigentlichen Events, die man sieht, sehr schlicht gehalten. Wir erzeugen uns also ein Event und nennen es „Raster I 1“.

Zur Erklärung: Römisch 1 ist die Gruppenzugehörigkeit. Römisch 1 ist die schwarze Gruppe, Römisch 2, zu der wir gleich kommen, ist die weiße Gruppe. Die Zahl dahinter symbolisiert die Nummer des Events in der Gruppe.

Die Einstellungen:

Ebenen-Priorität: Unter Spielerebene

Auslöser: Aktionstaste

Als Grafik nutzen wir die vorhandenen Stacheln, die es schon im Maker gibt. Fündig werdet ihr unter „!Other1“.

Ich habe euch auf dem Bild hervorgehoben, welche Grafik ihr nutzen müsst, nämlich die eingefahrenen Stacheln.

Klickt auf OK , dann sind wir hier schon fertig!

Nun müssen wir die Stacheln im Gang immer abwechselnd verteilen. Eine Stachelfalle, ein Platz frei, eine Stachelfalle, wieder ein Platz frei... Dabei müsst ihr die Löcher im Boden nicht mit Stacheln belegen. Ich hoffe, ihr könnt das Raster und den Sinn des Rasters erkennen.

Wichtig: Ihr müsst die Nummern bei den Stacheln ebenfalls umbenennen, um den Überblick zu behalten. Wie ich schon erklärte, ist Römisch 1 die Gruppe und die Zahl dahinter die Nummer des Events in dieser Gruppe. Zur Erklärung habe ich euch die ersten Events im Bild benannt.

Fertig? Gut dann wären wir schon mit der schwarzen Gruppe fertig, kommen wir zur weißen Gruppe.

Am leichtesten ist es, ihr kopiert euch ein schwarzes Event und nennt es um in „Raster II 1“.

Änderung:

Die Grafik wird geändert, denn die weiße Gruppe hat schon die ausgefahrenen Stacheln.

Nun machen wir das Gleiche noch einmal, wie mit der schwarzen Gruppe. Abwechselnd werden nun die Events der weißen Gruppe zwischen die schon anwesenden schwarzen Events eingefügt. Dabei wieder die Bodenöffnungen auslassen. Nun müsste es so bei euch aussehen.

Nicht das Umbenennen der Events vergessen. Wir machen dies wie bei der weißen Gruppe. Das Römisch II bleibt erhalten und die Zahl dahinter steigt mit jedem Event an.

Damit wäre dieser Teil geschafft. Die Stacheln sind platziert, nun kommt die Steuerung der Stacheln an die Reihe.

Die Stachelfallensteuerung

Wir brauchen ein Event, welches als paralleler Prozess fungiert und die Stacheln steuert. Ein neues Event muss also her, welches wir „Stachelsteuerung“ nennen.

Einzige Einstellung:

Auslöser: Paralleler Prozess

Die Stacheln werden also dauerhaft ein und ausfahren. Fangen wir mit dem ersten Schritt an. Als erstes werden wir die Stacheln, die ausgefahren sind, sprich, die weiße Gruppe, einfahren. Dies regeln wir über Bewegungsrouten.

Diese lauten:

Drehung rechts

Warte 2 Frames

Drehung links

Warte 2 Frames

Drehung unten

Hier kommt nun die gute und kluge Vorsicht zum Vorschein. Gut das wir die Stacheln mit Zahlen benannt haben, nun können wir der Reihe nach durchgehen und fangen mit „Raster II 1“ an.

Um besser zu verstehen, wie die Bewegungsroute funktioniert, hier mal die Veranschaulichung. Die Grafiken der Stacheln funktionieren wie die der Charaktere.

Damit hätten wir aber erst den Stachel „Raster II 1“ eingefahren. Wir wollen aber alle der Gruppe römisch II einfahren. Darum die Bewegungsroute auch für die anderen Events der Gruppe einstellen.

Damit die Speere alle gleichzeitig aus dem Boden kommen, wenden wir einen kleinen Trick an. Alle Bewegungsrouten bekommen nur die Option „Überspringen, wenn Bewegung nicht möglich“, außer die letzte Bewegungsroute, diese bekommt als Zusatz noch den Befehl „Warten bis abgeschlossen“. Würde dieser Wartebefehl nicht da sein, würde der Maker das gesamte Event sprichwörtlich runter rasseln, ohne zu warten, ob die Speere ein- oder ausgefahren sind. Es würde nur ein sinnloses Flackern der Speere entstehen und das wollen wir ja nicht.

So, sieht ja schon recht komplex aus oder?

Aus diesem Grund greifen wir beim nächsten Schritt in diesem Event schon ein wenig vor. Wir setzen einen Schalter mit dem Namen „Raster II“ und stellen diesen auf „AUS“. Bei der Begründung zu diesem Schalter greife ich auch schon ein wenig vor, aber habe mich entschieden, es hier schon einzubauen, da Anfänger vielleicht bei der Länge des Events eh schon genug damit zu tun haben, den Überblick zu behalten.

Wir werden später abfragen, welche Gruppe aktiv ist – die weiße oder die schwarze Gruppe.

Ist die weiße Gruppe aktiv, sprich der Schalter „Raster I“ AN, sind deren Speere ausgefahren. Sind die Speere eingefahren, ist die Gruppe inaktiv, der Schalter „Raster I“ ist AUS.

Ist die schwarze Gruppe aktiv, sprich der Schalter „Raster II“ AN, sind deren Speere ausgefahren. Sind die Speere eingefahren, ist die Gruppe inaktiv, der Schalter „Raster II“ ist AUS.

Da wir die Speere gerade eingefahren haben, ist die Gruppe „Raster II“ also ab sofort inaktiv, der Schalter muss also AUS sein. Ich hoffe, dies war einigermaßen verständlich.

Ich hoffe, dies war einigermaßen verständlich.

Als nächstes erzeugen wir uns eine Trennlinie mit der Kommentarfunktion, diese dient nur der Optik und der Auflockerung. Sie soll uns als Markierung dienen, die uns sagt, eine Rastergruppe hat gerade etwas getan.

Wait 50 Frames – dies ist die Wartezeit, in der der Spieler sich bewegen kann, ohne dass ihm etwas passiert, beide Stachelgruppen sind inaktiv. Über diesen Wartebefehl kann man übrigens auch den Schwierigkeitsgrad steuern. Um so höher die Framezahl, um so länger wird gewartet bis der nächste Befehl beginnt.

Es gilt = 60 Frames = 1 Sekunde

Noch einmal eine Trennlinie

Als letztes ein neuer Schalter nämlich „Raster I“ ist AN

Der nächste Punkt ist nun, dass alle Stacheln von „Raster I“ aktiv werden, sprich aus dem Boden kommen und der Spieler verletzt werden kann.

Aber wir müssen nicht nur über den Schalter sagen, dass die „Raster I“ aktiv wird, wir müssen auch die Stacheln dieser Gruppe ausfahren. Dies machen wir wieder mit Bewegungsroute.

Die Bewegungsroute würde lauten:

Drehung links

Warte 2 Frames

Drehung rechts

Warte 2 Frames

Drehung hoch

Also genau das umgekehrte, was wir vorhin machten. Wir fangen dieses Mal mit dem Event „Raster I 1“ an.

Wiederholt die Bewegungsroute nun bei allen Events der „Raster I“ und ihr müsstet dieses Ergebnis erhalten.

Achtung: Beachtet bitte, dass wieder überall nur „Überspringen“ eingetragen ist und erst beim letzten Event noch der Zusatz „Warte“ hinzukommt!

Die Hälfte haben wir schon!

Die Stacheln der schwarzen Gruppe mit dem Namen „Raster I“ sind nun ausgefahren. Hier verweilen sie auch kurz.

Ein kleiner Kommentar mit einer Trennlinie für die bessere Übersicht

Warte 50 Frames – so lange bleiben die Stacheln draußen

Noch ein Kommentar mit Trennlinie

Aber irgendwann müssen die Stacheln ja mal wieder zurück dahin, wo sie her kamen. Wir schieben also die Stacheln zurück in die Erde – und wie machen wir dies? Mit Bewegungsrouten! Dazu nutzen wir wieder die Bewegungsrouten, die wir als erstes genutzt haben.

Drehung rechts

Warte 2 Frames

Drehung links

Warte 2 Frames

Drehung unten

Dieses Mal wenden wir diese Bewegungsroute aber auf alle Events des „Rasters I“ an.

Achtung: Beachtet bitte, dass wieder überall nur „Überspringen“ eingetragen ist und erst beim letzten Event noch der Zusatz „Warte“ hinzukommt!

Damit wären wir fast fertig, ihr habt es gleich geschafft!

Da die Stacheln eingefahren sind, geht für den Spieler auch keine Gefahr mehr von ihnen aus, darum kommen nun wieder ein paar Schalter auf uns zu.

Schalter „Raster I“ wird ausgeschaltet, da die Speere ja eingefahren, sprich inaktiv sind

Wieder mal eine Trennlinie

Warte 50 Frames – hier kann sich der Spieler wieder sicher bewegen

Noch eine Trennlinie

Schalter „Raster II“ wird angeschaltet, da diese Stacheln nun wieder ausgefahren werden.

Um den Kreis zu schließen, müssen wir nun nur noch die Events von „Raster II“ wieder ausfahren und ihr ahnt was kommt ...

Damit wären wir bei diesem Event fast fertig. Das Einzige, was nun noch kommt, ist:

Wieder mal eine Trennlinie

Warte 50 Frames – hier kann sich der Spieler wieder bewegen

Noch eine Trennlinie

Fertig! Nach dem Warte-Befehl fängt das Event bedingt durch den parallelen Prozess wieder von vorn an.

Was wir jetzt getan haben, ist kurz zusammengefasst:

„Raster II“ eingefahren

50 Frames Wartezeit eingesetzt in der sich der Spieler bewegen kann

„Raster I“ ausgefahren

50 Frames Wartezeit in der die Stacheln von „Raster I“ draußen verweilen

:pfeilblaurechts: „Raster I“ eingefahren

:pfeilblaurechts: 50 Frames Wartezeit eingesetzt in der sich der Spieler bewegen kann

:pfeilblaurechts: „Raster II“ ausgefahren

:pfeilblaurechts: 50 Frames Wartezeit in der die Stacheln von „Raster 2“ draußen verweilen

Wir haben also für die Rastergruppe 1 und 2 einen kompletten Durchgang erstellt und dem Maker gesagt, wie sie sich bewegen sollen. Dank der Wartebefehle am Ende jedes Durchgangs haben wir die Garantie, dass die Gruppe immer gemeinsam ein- und ausfährt.