RPG-Maker 2000 Kurs

Dies ist der downloadbare Grundkurs zum RPG Maker 2000. Hiermit lernt ihr nicht:

• Das Erstellen eines kompletten Spieles.


• Wie man eine Story für ein Spiel aufbaut.
(Nachtrag: Tut ihr doch xD)

• Wie man eine gute Athmosphäre (Game-Feeling)erstellt


• Wie ihr euren Hund dazu bringt "Love me Tender" zu singen ^_^

• Was ein SWITCH ist!


• Wie man vermeiden kann sich im Forum "unbeliebt" zu machen durch Fragen wie: "Was ist ein Switch?".


• Wie man das Grundgerüst eines Spiels erstellt


• Wie man Maps, Objekte und Animationen erstellt und bearbeitet.


• Wie man die Database bearbeitet


• Wie man eigenes Material importiert


• Wie man die kleinen Feinheiten des RPG Makers handhabt.


• Wie man seitenweise Text lesen kann, die nicht mal was mit Schule/Beruf zu tun haben ^^

• Teil 1 - Für bluuuutige Anfänger


• Teil 2 - Für Anfänger


• Teil 3 - Für Fortgeschrittene I
• Teil 4 - Für Fortgeschrittene II
• Teil 5 - Für Fortgeschrittene III
• Teil 6 - Für Fortgeschrittene III

Wenn du den Maker zuallererst startest, musst du ein neues Projekt starten, dieses kannst du, in dem du entweder in der Menüleiste auf "Project" klickst, und "Create new project" auswählst, oder indem du auf die leere Seite oben links klickst. Du musst nun Namen des Verzeichnisses und des Projektes angeben(da steht noch was von "Default Project Path", aber das musst du nicht ändern), und schon gehts los. Du kannst jetzt sehen, dass die richtige Makeroberfläche aus drei Fenstern besteht, einmal dem Chipset-Fenster, oben links, dem Menüstruktur-Fenster, darunter, und dem MapFenster, rechts, dem größten und wichtigsten. Im Mapfenster kannst du im Moment nur eine blau Masse sehen, die Wasser darsetllen soll. Im Menüstruktur Fenster kannst du sehen, dass du die Map "MAP0001" ausgewählt hast. Das ist kein schöner Name, also klicken wir mal mit der rechten Maustaste auf "MAP0001". Ein kleines Untermenü faährt heraus. in dem uns aber vorerst nur "Map Properties" interressiert. Ein klick, und ein neues Fenster öffnet sich, in dem zeimlich viele Optionen sind, die doch recht kompliziert scheinen, auf den ersten Blick. Arbeiten wir uns doch erst einmal durch. Eignetlich sollte "MAP0001" in der Eingabefläche "Name" blinken, das heißt, hier kann der Name der Map angegeben werden. Wir nennen sie mal "Stadt 1". Dadrunter steht "ChipSet". Moment, kennen wir das nicht irgendwoher? Genau, das Fenster oben links war das "ChipSet-Fenster", und dort wurden allerlei Grafiken angezeigt, mit denen Man die Map füllen kann. Also ist das Chipset die Grafikpalette, die uns für die Map zur Verfügung steht. Da wir die Map ja schon "Stadt 1" genannt haben, wollen wir natürlich nicht das Welt-ChipSet, sondern eins, das auch für eine Stadt passt. Also wählen wir die Schaltfläche "Fasade" Weiter darunter Steht "Map Size" und es ist eine Größe von 100*100 angegeben. Dieses bedeutet 100 Felder in der breite, und 100 Felder in der Höhe, das ist für unsere erste Stadt dann doch ein bisschen groß. Also schrauben wir das ganze mal auf 30*20 runter. Die beiden Sachen darunter lassen wir vorerst links liegen, und auch das gesamte Menü unter "Parallax" interessiert uns erst einmal nicht. Das einzige in deisem ganzen Menü, das jetzt noch relevant ist, ist Background Music. Dort haben wir drei verschiedene Auswahlmöglichkeiten, von denen eine, nämlich "Parent Map" deaktiviert sein dürfte. Diese bedeutet, dass die Hintergrundmusik der übergeordneten Map weiterverwendet wird, da es hier aber keine gibt, ist die Auswahl nicht möglich. Die zweite Möglichkeit, "No Change" bedeutet, dass die Musik von der Map übernommen wird, von welcher man diese hier erreicht hat, und die dritte Möglichkeit, die wir nun wählen, heißt "Set to:", und bedeutet, das wir eine Hintergrundmusik auswählen können. Wir klicken jetzt auf die drei Pünktchen, und sehen sofort eine relativ große Liste voller Musikstücke. Mein persönlicher Favorit für eine Stadt ist "Village 3", gleichzeitig auch letzte Midi in der Reihe. Ein klick auf Play, und schon können wir sie hören. Es gibt hier einen ganzen Haufen Einstellungen, die ich jetzt nicht erläutern werden. Wenn wir jetzt auf OK klicken, ist die Musik als Hintergrundmusik für die Map "Stadt1" ausgewählt. Aber obwohl das Menü weg ist, hören wir das Lied immer noch, also noch mal Menü aufrufen, und auf Stop klicken! Okay, damit hätten wir die Einstellungen für die Map abgeschlossen!

Jetzt gehts hier zum richtigen Erstellen der Map über, denn eine Stadt braucht bekanntlich Häuser. Wie du siehts, ist die Map schon viel kleiner geworden, und auch die Grafik im ChipsetFenster hat sich verändert. Leider ist immer noch alles blau, und unsere Stadt soll ja nicht schwimmen. Nehmen wir zuerst mal eine Wiese als Untergrund, das ist entweder das erste, oder das zweite Feld in der zweiten Reihe, klick einfach auf eins der beiden drauf. Jetzt noch ein klick, auf die Farbdose, rechts über dem Chipset Fenster, in der gleichen Reihe, wo auch der Bleistift markiert ist. Damit haben wir den Füllmodus ausgewählt, der, ähnlich wie in Zeichenprogrammen, bestimmte Flächen mit einem bestimmten ChipsetTeil füllt. Ein klick in das MapFenster, und schon haben wir unserer Stadt einen Wiesenuntergrund verpasst. Nun kommt das erste Haus an die Reihe. Etwas weiter untem im ChipSet Fenster können wir 3 Quadrate, je 3*3 Felder erkennen, die Häuserwände darstellen. Einmal aus grauen Steinen, einmal weiß verputzt, und einmal ein Holzhaus. Ein Haus sollte natürlich briter sein, als diese drei Felder, und damit wir nicht alles einzeln anklicken müssen, gibts ein paar nützliche Tricks: Zuerst wechselst du oben wieder vom "Füll-Modus" in den "Zeichen-Modus"(Bleistift). Jetzt wählen wir mal vom ersten Haustyp (dem grauen), das erste Feld oben links aus, und lassen den Stift gedrückt, und ziehen ihn bis zum dritten feld nach unten. Nun haben wir gleich die gesamte linke Seite des Hauses ausgewählt, und mit einem Klick ins MapFenster, können wir sie an einen beliebigen Ort auf der Karte setzen. Nun markieren wir die drei Felder von oben nach unten rechts daneben, und setzen sie auf der Karte auch neben die vorhin gesetzten. Aber jetzt klicken wir nicht nur einmal dahin, sondern am besten 4, 5 mal, bis das Haus die gewünschte Breite hat. Nun noch rechts auf die gleiche Art den rechten Rand dran setzen, fertig. Naja, fast, fehlt noch ein Dach für unser Haus. Das gibts im ChipSet etwas weiter unten, da seht ihr dann zeimlich viele Rote und türkise Kacheln. Die beiden roten ganz links eignen sich gut, also markieren wir sie mal, und setzen sie über das ganze Haus drüber. Fast fertig.. Nur noch Eingang, Fenster, vielleicht ein schicker Kamin und noch ein paar Blümchen davor? Alles möglich, aber wo denn? Das Geheimnis des Mapdesigns ist, dass es im Maker mehrere Schichten gibt, die übereinander gesetzt werdeen könne. Im Moment befinden wir uns im sogenannten "Lower Modus", dass heiß, wir setzten nur die untere Schicht, und um höhere Objekte, wie eben Fenster zu setzen, müssen wir in den "Upper Modus" wechseln. Dies geht entweder mit der Taste F6, oder in dem wir oben in der langen Leiste mit den vielen kleine Symbolen auf das blaue Viereck mit dem Pfeil klicken(Das grüne für den "Lower Modus" sollte ausgewählt sein). Hier können wir sehen, dass alles sofort etwas dunkler wird, und sich das ChipSet im Fenster verändert. Hier gibt es nun Schilder, Briefkästen, Bäume, Büsche, Fenster,... Experimentiert selbst etwas damit herum, und gestaltet die Map mal etwas lebendiger. Fügt noch weitere Häuser hinzu, und verbindet sie mit Wegen, Straßen, ... Wenn ihr alle gemacht und verstanden habt, gehen wir zum zweiten Punkt.

Unsere Karte sollte jetzt für den Anfang schon recht gut aussehen, einige Häuser, Straßen, Bäume, Blumen,... Aber in ein richtiges Rollenspiel (und nicht nur darein) gehören natürlich auch andere Leute als der Held, nämlich die "NPCs"(Non Player Characters), die, wie der Name schon sagt, nicht vom Spieler gesteuert werden können. Zuerst setzen wir mal einen Mann mitten in die Map, der uns begrüßen soll. da im ChipSet natürlich keine Menschen zu sehen sind, müssen wir in den dritten verfügbaren Modus, den "Event Modus" wechseln, entweder mit dem gelben Viereck, oder mit F7. Im Event Modus werden sämtliche Ereignisse undseres Spiels "programmiert". Keine Angst, natürlich brauchen wir nicht wirklich zu programmieren, der Maker hat schon sämtliche Funktionen, die wir benötigen (obwohls gerne ein paar mehr sein könnten...), um den Ablauf festzulegen. Zurück zu dem Mann, wie sollen wir den jetzt hinbekommen. Die ganze Map ist jetzt gerastert, also klicken wir mal doppelt auf das Feld, wo der Mann stehen soll. Aha, schon wieder ist ein neues Fenster aufgegangen, und schon wieder sind da seehr viele unverständliche Funktionen. Schauen wir uns erst mal das (normalerweise) leere, pinke Feld links unten an, über dem "Select Graphic" steht, und neben dem der schöne Knopf mit der Aufschrift "Set" ist. Diesen klicken wir nun an. Wieder ein Menü, und ziemlich vviele Auswahlmöglichkeiten. Wählen wir mal den Punkt "Chara1" aus, eines der gebräuchlichsten "Character Sets", wie diese Grafiken heißen. Nun wählen wir hier mal den Soldaten aus (mit der roten Rüstung). Unter den Grafiken kann man die Blickrichtung, sowie die Schritte ändern. Das lassen wir aber und bestätigen alles. Das Fenster seiht jetzt wieder so aus wie vorhin, nur dieses Mal mit der Soldaten-Grafik, das heißt, dass im Spiel an dieser Stelle der Soldat steht. Die Fensterüberschrift lautet "Event Editor - ID:0001", und dadrunter ist als Eventname nur "Ev0001" angegeben. Man muss den Namen des Events nicht ändern, aber es wird später die Übersicht sehr erleichtern, also geben wir dem Ereignis (bzw. der Person) den treffenden Namen "Soldat". Natürlich redet der Mensch noch nicht mit uns, das heißt wohl, dass wir noch immer was ändern müssen. Wir klicken nun doppelt auf das große weiße Feld mit dem Namen "Event Commands", und das nächste Fenster springt uns entgegen. Hier sind drei Seiten voller Optionen und Mittel unser Spiel zu gestalten, wovon im Rahmen des Kurses sicher noch alle erläutert werden. Zuerst interessiert uns nur die erste Option auf der ersten Seite "Show Message", die bewirkt, den Text, den wir nun eingeben (etwa: Ein schöner Tag, findet Ihr nicht auch?), im Spiel anzeigen zu lassen, wenn man den Soldaten mit "Enter" oder "Space" anredet. Den Text bestätigen wir, aber noch ist das ein bisschen wenig. Der Rpgmaker kann mit Hilfe von gewissen "FaceSets", also Gesichtsgrafiken, Bei einer Nachricht links oder rechts daneben das Gesicht des Sprechers anzeigen lassen. Dazu müssen wir aber vor der Message ein Face auswählen, das geht, indem wir im Feld "Event Commands" nicht unter das bisher bestehende Kommando klicken, sondern direkt dadrauf. Wieder auf der ersten Seite, doch dieses Mal das dritte Kommando links (Select Face...) angeklickt, öffnet sich ein neues Fenster, indem wir die Gesichtdgrafik auswählen können. In dem Feld "Select Face Graphic" sollte es eigentlich schwarz sein, also klicken wir einaml auf "Set...". Im nun geöffneten Fenster bleiben wir beim aktuell ausgewählten Set, und schon können wir in der ersten Reihe den Soldaten erkennen. Ein Klick und bestätigen, schon ist er ausgewählt. Jetzt können wir auswählen, ob das Gesicht links oder rechts vom Text, gespiegelt oder nicht angezeigt wird. Alles fertig (links ungespiegelt sollte reichen) bestätigen wir erstmal, bis wir wieder im "Ur-Fenster" sind. Hier gehen wir jetzt erst einmal raus, um das bisherige zu testen. Der Soldat wird jetzt verkleinert auf einem Feld angezeigt, und wir setze nun einen Startpunkt. Das geht, in dem wir mit rechts auf das gewünschte Feld klicken und wählen "Set Start Party Position". Der Startpunkt ist da, und wir können testen (F9)! Bestätigt die Speicheraufforderung, und wählt Start. Jetzt könnt ihr in der Stadt herumlaufen, und schließlich auch mit dem Soldaten reden (Enter). Wenn ihr alles getestet habt, drückt Alt+F4, was euch sofort zum Maker zurückbringt. Okay, nun kommen wir zum "Debuggen" (Fahlerberichtigen). Vielleicht sind euch einige der folgenden Fehler aufgefallen:?

• Man kann nicht alles lesen, was ich eingetippt habe... ?


• Anstatt "Ö", oder "Ü", stehen da seltsame Zeichen... ?


• Ich rede den Soldaten an, wenn ich ihn nur berühre... ?


• Ich kann über/unter dem Soldaten laufen.

Tipps dazu (Bitte auch durchlesen, wenn ihr keine Fehler gemacht habt!!!): Im ersten Fall habt ihr einfach zu viel in eine Zeile getippt, das kann passieren, da nicht alle Buchstaben gleich groß angezeigt werden, und man so die Übersicht verlieren kann, und dass durch das Face die gestrichelte Linie nicht mehr als Absperrung dient. Im zweiten Fall liegt der Fehler in der Schriftart die dem Maker beiliegt, und die keine deutschen Umlaute (ä, ö, ü, ß) enthält. Zur Lösung empfiehlt sisch einfach die Schreibung von "oe" anstatt ö, oder "ss" anstatt ß. Man kann auch einen diverser Umlautepatches benutzen, die sich im Umlauf befinden.Im dritten Fall habt ihr etwas bei den Einstellungen (wahrscheinlich aus Versehen) verändert, was in diesem Falle nicht von Nutzen ist. Doppelklickt auf das Soldatenfeld, so dass ihr wieder das EventFenster geöffnet habt. Rechts neben dem Bildchen müsste unter "Event Start Condition" (Die Bedingung, dass das Ereignis im weißen Feld eintritt) "On hero Touch" oder "On Touch (Event, Hero)" eingetellt sein, also wird das Ereignis bei Berührung ausgelöst. Ändert dies auf "Push Key" und das Ereignis wird wieder durch Tastendruck ausgelöst.Fall 4 ist vom Problem her dasselbe, wieder ist eine geringfügige Einstellung verstellt. Dieses Mal ist wahrscheinlich unter Position (auch rechts neben den Bildchen) entweder "Below Hero" (Event befindet sich unterhalb des Helden, kann überlaufen werden) oder "Above Hero" (Event kann unterlaufen werden) eingestellt, ändert dies einfach auf "Same Level As Hero"..Soo, das wär schon mal gemacht, wenn wir jetzt testen, sollten wir in der Stadt herumlaufen, und mit dem Soldaten reden können. Da wir ihn mitten in die Stadt gestellt haben, scheint er ja kaum Dienst zu haben, also ist es etwas unrealistisch, wenn er einfach nur dort stehen bleibt. Es gibt im Maker schon verschiedene Bewegungsmuster, die wir ihm jetzt verpassen können. Wieder ins Event-Menü des Soldaten, dieses Mal interessiert uns die Einstellung unterhalb des Bildchens, "Movement Type" sthet darüber. Voreingestellt ist "Stay Still", das heißt, er bleibt ruhigstehen. Die anderen Möglichkeiten sind "Random Movement", "Cycle Up-Down", "Cycle Left-Right", Step Toward Hero", "Step away from hero" und "By its route"."Random Movement" steht für eine zufällige Bewegung, dass heißt, der Soldat läuft irgendwie in unserer Karte herum (für jetzt die beste Einstellung)."Cycle Up-Down" steht dafür, dass der Soldat solange nach oben läuft, bis er auf ein festes Hindernis stößt, dann dreht er um, und läuft nach unten, bis er auch hier auf ein Hindernis stößt. Das immer im Kreis."Cycle Left-Right" ist das gleiche, nur dass er nach links und rechts läuft."Step Toward Hero" bewirkt, dass der Soldat immer auf den Helden zuläuft, ihm also folgt."Step Away from Hero" ist das Gegenteil, der Soldat würde immer vor dem Helden ausweichen.Die funktion "By Its Route" wird vorraussichtlich im nächsten Teil des Kurses besprochen.Unter Frequenzy könnt ihr einstellen, wie groß die Lauffrequenz ist(bei niedrigerer Frequenz als 8 wirkt es abgehackt...)...Zur Bewegung gehört noch etwas mehr dazu, deshalb bewegen wir unseren Blick jetzt mal vom "Movement Type" etwas nach Rechts zum "Animation Type", also zur Art der Animation. Voreingestellt ist "Common/Without Stepping", was bedeutet, dass der Soldat, wenn er auf der Stelle steht, sich nicht andersweitig bewegt, und sich, wenn er angesprochen wird in die richtung des sprechers dreht. Sinnvoll für sie meisten Gelegenheiten. Es gibt noch einen Haufen anderer Möglichkeiten, die wir jetzt schnell mal durchgehen."Common/With Stepping" bedeutet, dass der Soldat auch auf der Stelle gehen würde, sich aber bei Ansprechen trotzdem in jede Richtung dreht. Das scheint zwar etwas sinnlos (welcher MEnsch rennt denn auf der Stelle??), aber lässt sich in vielen Situationen gebrauchen, z.B. Fitnessstudio, Mann rennt auf der Stelle, oder spezielle Charaktersets, die animierte Gegenstände enthalten, die sich dann "bewegen"."Without Stepping" bedeutet NICHT, dass sich der Soldat bewegt, ohne die Fußanimation zu benutzen, sondern, dass er sich bewegt, ohne sich in die Laufrichtung zu drehen, er dreht sich auch nicht wenn er angesprochen wird. Am besten zu benutzen, wenn man will, dass jemand nur seitwärts läuft, und sich nicht umdreht, wenn er angesprochen wird."Fixed Direction" ist in etwa dasselbe, am einfachsten kann man sich das klar machen, wenn man "Common/Without Stepping" mit "Without Stepping", und "Common/With Stepping" mit "Fixed Direction" vergleicht. Der einzige Unterschied ist nämlich, dass der Soldat sich beim Ansprechen zwar auch nicht umdreht, dafür aber auch auf der Stelle läuft.Fixed Graphic" ist nun die äußerste Form, der Soldat hätte keine Ganganimation, und wir auch beim Ansprechen nicht umgedreht. Das ist für Personen eigentlich nicht sehr gebräuchlich, sondern kann für völlig unbewegliche Objekte eingesetzt werden, etwa Schatten. Wenn man einen Schatten einsetzt, oder ein anderes durchsichtiges Bild, sollte man bei "Transp." neben dem Bild einen Haken setzen."4 Anim Turn Right" ist die letzte Funktion, die bewirkt, dass sich der Soldat im Uhrzeigersinn herum im Kreis drehen würde. Das ist wieder für Objekte gut, aber dieses Mal für welche mit 4 verschiedenen Phasen..Der allerletzte Abschnitt zum Thema NPCs befasst sich mit der kleine Funktion unter dem "Animation Type", nämlich mit dem "Movement Type". Hier kann man einstellen, wie schnell sich der Soldat im Vergleich zur Normaleinstellung der Heldengeschwindigkeit bewegen kann (Hier ist aber nix abgehackt). Wie man Geschwindigkeit des Heldn verändern kann, kommt auch vorraussichtlich im nächsten Teil des Kurses. Puuhh....Ganz schön viel Text, aber wenn ihr alles verarbeitet habt (Probierts einfach aus), können wir ja dann mit Punkt 3 fortfahren.

Soo, jetzt wenden wir uns einem sehr wichtigen Kapitel der Rpg-Maker Programmierung zu, den Switches, bzw. den Schaltern. Damit kann man überprüfen, ob ein bestimmtes Ereignis schon eingetreten ist. Am besten erläutern wir das Mal an einem einfachen Beispiel. Erinnert ihr euch noch an den Soldaten, den wir in unsere Map gestzt haben? Ich hoffe ihr habt das Projekt noch nicht gelöscht, damit habe ich noch vieeeel vor. Also, klickt den Soldaten im Event modus doppelt an. Da könnt ihr jetzt wieder den Satz sehen, den ihr eingegeben habt. Nun klicken wir doppelt unter diesen Satz, und wählen bei den "Event Kommandos" in der linken Spalte "Change Switch" aus. Da sind wieder ein paar Optionen (Keine Angst, ALLE werden erklärt!). Zuerst wenden wir uns der Zeile "One:....." zu. Hier kannst du genau auswählen, welcher Switch an- oder ausgeschaltet werden soll. Ein Doppelklick in das Feld mit dem Inhalt "0001: StrongBox" und schon sind wir im Auswahlbereich. In der linken Spalte können wir zwischen den Switches 1 - 20, 21 - 40, ... auswählen. Dies geht nur bis 100, was für ein komplettes RPG doch ziemlich wenig wäre (ja, WENIG!). Deshalb könnt ihr unter "Max. Field Number" die Zahl der möglichen Switches bis auf 5000 heraufstellen. Lasst am besten jetzt aber erstmal alles so wie es ist, und wählt wieder die Switches 1 - 20 aus. In der rechten Spalte ist jetzt der 1. Switch ausgewählt, und in dem Eingabefeld unten rechts können wir den Namen ändern. Nennt ihn "GesprächSoldat". Es ist nützlich, den Switches immer sinnvolle Namen zu geben, weil man sonst leicht den Überblick verlieren könnte. Jetzt bestätigen wir mit ok, und sind schon wieder ein Menü weiter vorher. Eigentlich könnten wir jetzt alles so lassen, aber wie versprochen, will ich versuchen, den Rest auch noch zu erklären. Die nächste Funktion ist "Range", bei der Man einen Starwert, und einen Endwert auswählen kann. Mit dieser Funktion ist es möglich, ganze Gruppen von Switches zu aktivieren/deaktivieren, was durchaus nützlich sein kann. Wenn zum Beispiel in einer bestimmten Situation mehrere Switches aktiviert werden (5, 10, mehr..), und die nachher wieder abgeschaltet werden müssen, spart es viel Zeit, mit diese Funktion einfach die ganze Gruppe auszuschalten. Die dritte Auswahlmöglichkeit, "Variab" steht für die Funktion, dass man einen bestimmten Switch an/abschalten kann, der durch den Wert einer Variable bestimmt wird. Was es genau mit den Variablen auf sich hat, werde ich in einem folgenden Teil noch erklären. Nun wählen wir also wieder die erste Funktion ("One", mit GesprächSoldat) aus. Unter der Rubrik Set können wir nun die Aktion definieren, die mit diesem Switch gemacht wird. Durch "ON" wird der Switch eingeschaltet, durch "OFF" wieder aus ^^. Wenn ihr "ON/OFF Trigger" aktiviert, wird der Switch hier wenn er schon an ist, wieder ausgeschaltet, und wenn er aus ist, wieder an. Wir lassen ihn jetzt aber auf "ON" und bestätigen das ganze.Toll...Jetzt haben wir den Switch angemacht ..Was soll uns das denn bringen? Ziemlich viel, nun vielleicht nicht gerade in dieser Situation, aber sonst schon... Ganz oben links, rechts neben dem Namen des Events ist das Feld "New Page". Damit kann man eine zweite "Seite" des Events erstellen. Klickt es an, und schon könnt ihr sehen, dass man nun zwischen den beiden Seite hin und her wechseln kann. Nun bleiben wir also auf Seite zwei. Die Funktion des Switches soll in diesem Fall sein, dass der Soldat etwas anderes sagt, wenn man ihm zum zweiten Mal anspricht. In dem Bereich unten links, den wir ja schon bei Punkt 2 ausführlich beschrieben haben, könnten wir jetzt einstellen, dass sich der Soldat nach dem Gespräch anders bewegt, oder auch anders aussieht. Nun zurück zu dem Problem, dass der Soldat etwas anderes sagen soll. Oben links, in dem Feld Event Conditions interessiert uns jetzt zuerst die erste Zeile: "Switch". Wenn ihr hier das Häkchen macht, was ihr auch tun solltet, seht ihr, dass das graue Feld daneben weiß wird, und "GesprächSoldat" drinstehen sollte. Wenn das so ist, ist gut, wenn nicht klickt auf die drei Punkte dan ebn, und wählt den Switch aus. Da wir dies eingestellt haben, wird die zweite Seite aufgerufen, sobald der Switch "GesprächSoldat" aktiviert ist. Die zweite Zeile, auch Switch kann ebenfalls aktiviert werden, um in anderen Fällen sicher zu gehen, dass die seite nur anspringt, wenn zwei bestimmte Switches aktiviert sind. Die anderen Zeilen lassen wir zuerst mal außen vor.Ins Feld rechts fügen wir jetzt wie gewohnt das Gesicht das Soldaten ein (Falls ihr es vergessen habt, über Select Face Graphic) und schreiben einen neuen Text darunter, zum Beispiel "Was wollt Ihr noch?". So, ich hoffe ihr habt die Funktionen von Switches verstanden. Mit Switches kann man überprüfen, ob ein bestimmtes Ereignis schon in Gang getreten ist, etc.

Die Teleports sind ein seeeeehr wichtiger Bestandteil eines Rollenspiels. Der satz kommt euch bekannt vor? Es gibt halt vieles, was sehr wichtig ist, zum Beispiel die Databes, Switches, Teleports, Variablen, Move events,... Also zurück zu den Teleports. Teleports sind da, um zwei Maps zu verknüpfen. Das heißt, wenn man auf ein bestimmtes Feld geht, zum Beispiel in den Eingang eines Hauses, wird man auf eine zweite Map gebracht, die das innere des Hauses darstellt. Die andere Möglichkeit ist, das man zum Beispiel von einem Gegner zusammengeschlagen wird, und darauf ins Krankenhaus teleportiert wird, also wieder auf eine andere Map. Ohne Teleports kann man nicht zwischen Maps wechseln. Genug der Theorie. Ich hoffe, ihr habt noch das Projekt, das wir im Rahmen des ersten Teils erstellt haben. Wenn nicht, holt es mit Möglichkeit nach, es ist nicht besonders viel gewesen. Habt ihrs aufgerufen? Gut! Jetzt klickt im Übersichtsfenster mit der rechten Maustaste auf "Stadt 1", und wählt "Create New Map". Darauf kommt ihr wieder in das bekannte Mapmenü, wo ihr die verschiedenen Mapeinstellungen vornehmen könnt. Nennt die Map "Kampfarena", warum, werde ich noch erklären. Die Größe würde ich bei 20*15 auf der kleinsten Einstellung lassen. Als Hintergrundmusik passt was nettes wie "Farewell 3", aber da bleibt euch natürlich freie Wahl. Als Chipset solltet ihr unbedingt "Inner" wählen. Dieses ChipSet steht, wie der Name schon zeigt für das Innere von Räumen. Na, schon klar geworden? Wir erstellen jetzt eines der Häuser, die wir auf der Map "Stadt 1" haben, von innen, und wollen das ganze mit Teleports verknüpfen! Teilt den Raum mit Hilfe einer zwischenwad in zwei Teile, zwischen denen nur ein kleiner Durchgang besteht. Stellt in diesen Durchgang eine Person rein, die aufs erste ansprechen ungefähr mit "Ihr kommt hier nicht ohne Codewort rein!" reagiert. Das heißt, in den hinteren Bereich der Kampfarena kommt man nicht so einfach hinein. Jetzt wird ein Switch aktiviert, der "Codebenoetigt" heißen soll. Wählt dafür Switch Nummer 0002. Jetzt erstellen wir erst einmal den normalen Übergang zwischen den beiden Karten, nämlich durch die Tür. Dafür gibts einen ganz einfachen Trick! Geht in den Event Modus, falls ihr noch nicht drin seit, Klickt mit rechts auf das Feld, von dem man weg soll, und wählt Move Event. Ein neues Menü fährt heraus, in dem ihr rchts die Map, und links die Mapübersicht sehen könnt. Wählt also links die Zielmap und das Zielfeld aus. Wie ihr seht, ist auf dem Feld, wo ihr eben geklickt habt, ein pinkes Quadrat zu sehen, ein Zeichen für ein Event, das später "durchsichtig" ist. Mit einem Doppelklick darauf könnt ihr sehen, dass es sich unter dem Helden befindet, und auf Berührung funktioniert. Rechts stehen DREI Befehle! Wieso drei?? Würde ein Teleport nicht reichen? Im Prinzip natürlich schon. Der mittlere Befehl ist der normale Teleportbefehl, den ihr am Anfang erstellt habt, als ihr das Zielfeld gewählt habt. Darüber und darunter stehen einmal Erase-, und einmal Show Screen. Erase Screen lässt vor dem Teleport den Bildschirm auf eine bestimmte Weise ausblenden, Show Screen zeigt ihn dann wieder an. Beide sind auf "Create Removing Place" gestellt. Diesen Effekt mag ich persönlich nicht so gerne. Am besten finde ich "Fade Out" und "Fade In". Diese Effekte lassen den Bildschirm langsam verdunkeln, und dann wieder heller werden. Wenn ihr jetzt auf der Stadtmap das Teleport-Event in Gegenrichtung erstellt, werdet ihr sehen, dass wieder der alte Effekt eingestellt ist. Um das zu ändern müssen wir zum ersten mal in "DIE DATABASE" gehen. Das wichtigste Werkzeug, um das Gerüst deines RPG's zu erstellen. Dahin kommt man entweder, wenn man auf "F8" drückt, oder wenn man auf das Symbol rechts von "1/8" klickt. In der Database kann man seehr viele Einstellungen vornehmen, mehr dazu in den nächsten Kapiteln dieses Teils, und im gesamten dritten Teil. Wählt in der oberen Leiste "System" aus, das ist das zweite von rechts. Dort gibt es viele Auswahlmöglichkeiten, von denen uns momentan aber nur "Teleport transition" interessiert, das ist rechts von dem Bild unten links. Da sind wieder mal Erase und Show Screen anzutreffen, bei denen wir jetzt unsere bevorzugte Variante einstellen können. Fertig? Dann klickt auf okay, und erstellt zum Test ein neues "Move-Event". Wenn ihr es jetzt aufruft, werdet ihr sehen, dass die Teleportvariante, die ihr gerade eingestellt habt, jetzt auch aktiviert ist. Toll, was? Okay, okay, erspart auf jeden Fall viel Arbeit. Erstellt den Teleport jetzt auch in anderer Richtung, das heißt, man soll jederzeit vom draußen ins Haus, und vom Haus nach draußen können. Das wars dann. Viel Text für so eine einfache Funktion, nicht? *g*

Unseren ersten kleinen Kontakt mit der Database hatten wir ja schon, doch jetzt schauen wir sie uns mal etwas genauer an. Wenn ihr sie wie gewohnt mit "F8" oder einem Klick auf das passende Symbol aufruft, sollte noch das Verzeichnis "System" aufgerufen sein. Wechselt gleich auf das erste Verzeichnis, mit dem Namen "Hero". Hier könnt ihr viele Namen, Felder und Einstellungen sehen. Doch bevor wir uns systematisch durcharbeiten, kommt erstmal die Frage auf: "Was genau ist die Database?". Um es mal mit einem Filmzitat deutlich zu machen: "Die Matrix ist schwer zu erklären, man muss sie selbst erlebt haben." So in etwa ist es auch mit der Database. Man könnte sie als eine Art Grundgerüst für ein RPG bezeichnen, denn hier werden die Helden gespeichert, Fähigkeiten erstellt, Items gemacht, Kämpfe eingestellt, und und und... Zurück zum Thema ^^ Wie ihr seht, teilt sich der Bildschirm in dieser (und in den meisten anderen Rubriken auch) in zwei Teile, einmal ein großer Balken, der die gesamte Linke Seite ausfüllt, und viele kleinere Einstellungen und Bilder rechts daneben. Der linke Balken steht grundsätzlich für die Navigation, dort kann man zwischen den einzelnen Helden, Skills oder Monstern wechseln. Rechts sind dann die Einstellungen, die jedes mal neu getroffen werden (sollten). Links seht ihr jetzt eine ganze Menge Heldennamen, und wenn ihr verschiedene anklickt, seht ihr, dass sie schon komplett voreingestellt sind. Das ist übrigens in jeder Rubrik so. Allerdings kommen diese Helden, vor allem "Alex" in sehr vielen RPG's vor, vor allem von Leuten, die sich die Einstellungen hier nicht zutrauten. Deshalb solltet ihr, wenn euer Spiel halbwegs erfolgreich/beliebt werden soll möglichst einen eigenen Helden erstellen. Und das wollen wir jetzt tun. Löscht am besten alle Helden, oder wenn ihr sie zum Vergleich bebehalten wollt, dann klickt unten Links auf "Max. Field Number..." und stellt sie auf 9 oder höher. Dann wählt auf jeden Fall ein freies Feld aus.

• Name: Der Name des Helden. Lasst euer Kreativität freien Lauf, aber bloß nicht Alex! *g*


• Degree: Der Rang/Beruf des Helden, wird im Menü angezeigt. Kämpfer etc. ist immer gut.


• Select Walk Graphic: Die Grafik des Helden, mir gefällt Chara 4, der dritte in der oberen Reihe. Bei transp. könnt ihr ihn durchsichtig anzeigen lassen.


• Initial Level: Das Anfangslevel, das der Held hat. 1 empfiehlt sich, oder?


• Max Level: Das höchste Level, das dder Held erreichen kann. Da es nur 50 Level gibt, würde ich auch die maximale Anzahl einstellen.


• Critical Hit Chance: Die Wahrscheinlichkeit, mit der der Held im Kampf einen kritischen Treffer landet. 20% sind okay.


• Select Face Graphic: Das Gesicht des Helden, das im Menü angezeigt wird. Sollte zur Charaktergrafik passen.


• 2 Sword Style: Der Held trägt zwei Waffen, und kein Schild.


• Equipment Fix: Die Ausrüstung lässt sich im Spiel nicht ändern. Praktisch, wenn jemand nur kurzzeitig in der gruppe ist, und sehr gute Ausrüstung hat(sonst könnte man alles verkaufen/mit dem Hero selbst anziehen).


• Control by AI: Charakter wird im Kampf automatisch gesteuert.


• Strong defense: Charakter hat eine besonders ausgeprägte Verteidigung.

• Curve Of Abilities:Hier könnt ihr einstellen, wie sich die sechs Charakterwerte HP, MP, Stärke, Verteidigung, Schnelligkeit und Geistesstärke im Laufe des Spiels verändern sollen. Einfach ein Doppelklick auf das entsprechende Feld. Dort könnt ihr die Werte per Mausklick verändern, rechts oben exakt einstellen, und Rechts unten generieren lassen. Ich empfehle letztere Variante, und dann Stärke, HP, Verteidigung zwischen Normal und Exellent, MP, Schnelligkeit und Geistesstärke zwischen Normal und Low einzustellen. Eigentlich ist das ja egal, aber jeder Charakter sollte seine Stärken und Schwächen haben, damit am Ende eine Gute party zustande kommt.


• Curve Of Experience: Hier lässt sich im Detail einstellen, wie viel Erfahrung der Held benötigt, um das jeweils nächste Level zu erreichen etc. Ich würde die Finger noch davon lassen, da die Voreinstellungen recht gut sind.

Dann kommen wir also zum nächsten Bereich, nämlich "Skills". Links könnt ihr eine wirklich LANGE Liste von Skills sehen, die alle gut funktionieren, und schön eingestellt wurden. Aber wir sind ja schließlich hier, um unser eigenes RPG zu gestalten, oder? Also löscht alle, oder erhöht die maximale Anzahl (genau wie bei "Hero"). Alles in allem sollte vor Euch jetzt ein großer Bereich mit sehr vielen leeren Feldern oder Auswahlen liegen. Wenn ja, dann gehts wieder mal los.

• Name: der Name des Skills, wie er im Kampf und im Menü erscheinen wird. Für unseren ersten Skill z.Bsp. "Kraftschlag".


• Classification: Eine größere Auswahl, in der man die Art des Skills bestimmen kann. Zuerst auf "Norm" lassen (Normale Fähigkeit).


• MP Cost: Bestimmt, wieviel MP der Skill kosten soll. Da unser Skill ein Starker Schlag werden soll, der überdurchschnittlich viel Leben abnimmt, so viel MP, das man ihn auf Level 1 höchstens 2 mal benutzen kann.


• Explanation: Ein kurzer text, der den Effekt des Skills beschreiben soll. Etwa: "Ein besonders kräftiger Schlag (Ein Gegner)".


• Effect Range: Welche Charaktere/Monster betrifft der Skill? Einen Feind, Alle Feinde, den Benutzer, einen Verbündeten, Alle Verbündete? Am besten auf "Single enemy" lassen.


• Using Message: Die Nachricht, die bei Benutzen des Skills erscheint. Zum Beispiel " nutzt den Kraftschlag". Unbedingt ein Leerzeichen vor das erste Wort schreiben! Unter "Chant", "Cast" und "Use" könnt ihr englische vorgefertigte Messages aufrufen (nicht gut -_-).


• Battle Animation: Die Animation, die erscheint, wenn man den Skill im Kampf benutzt. Ihr könnt natürlich etwas rumexperimentieren, da wir aber schon bald eigene Animationen erstellen (wollen) könnt ihr sie auch so lassen, wie sie ist.


• Failure Message: Hier können wir aus vorgefertigten Nachrichten auswählen, was geschrieben wird, wenn der Skill fehlschlägt. Da alles (noch) englisch ist, können wir sie auf "Failed" lassen.


• Hit Chance: Hier kann auf einer Skala von 0 bis 10 ausgewählt werden, wie stark die Stärke des Helden den Schaden beeinflussen soll, den der Skill verursacht. Da der Kraftschlag eine physiche Attacke ist, so ca. auf 4, sonst wird der Schaden auf späteren Levels sehr stark beeinflusst.


• Mind Chance: Fast gleich, nur dass dieses Mal ausgewählt wird, wie stark die geistesstärke den Schaden beeinflusst. Aus gleichem Grund wie oben auf 0 setzen.


• Variance: Bestimmt, wie stark der Schaden vom Zufall bestimmt wird. Wenn man annimmt, dass der Held etwas Glück brauch, um eine schwache Zone des gegners zu treffen, kann man Variance so ungefähr auf 2 oder 3 setzen.


• Basis Effect: Der Schaden, der verursacht werden würde, wenn alle drei Werte oben auf 0 gesetzt wären, und der Gegner keine Verteidigung hätte. Da muss natürlich jeder selbst wissen, wie stark der Skill werden soll, hängt natürlich auch von den Gegnern ab. Meinetwegen auf 13..


• Ability Down: Der wert, bei dem dieser Schaden verursacht wird. Also, wenn es auf Hp ist, werden als Grundschaden 13 HP abgezogen, bei Defense wird die Verteidigung um 13 Punkte verringert, usw. "Absorption" bedeutet, dass der Held den Wert, den der Gegner abgezogen bekommen hat, dazu erhält, "Defnc.Ignor." richtet den Schaden an, ohne die gegnerische Verteidigungsstärke mit einzubeziehen. Wenn man bei Effect Range den Skill auf die Party wirken lässt, wird hier aus dem Ability Down ein Ability Up, das heißt, der jeweilige wert wird erhöht (z.B. für Heilungsskills).

Weiter mit Teil drei unseres ersten Ausfluges in die Database, den Items. Wie ihr wahrscheinlich alle wisst, sind Items ein Muss in Kämpfen, denn wenn die MP schwindet, und die HP sich dem Nullpunkt nähert hat man immer noch eine Potion, einen Trank, Heilkräuter und so weiter zu Hand. Sollte man zumindest. Aber nicht nur das, sondern auch Ausrüstungsgegenstände wie Waffen oder Rüstungen wollen erstellt werden! Also nichts wie ran. Wählt am besten in der linken Liste eins der leeren Felder ganz unten aus, da die Standartitems recht gut sind. Natürlich könnt ihr auch alles neu machen!

• Name: Hier könnt ihr den Namen des Items eingeben (WOW ^^).


• Price: Der Preis des Items; Items mit einem Preis von 0 können nicht verkauft werden. Muss je nach Spielbalance eingestellt werden (Wie viel Geld soll es kosten, wieviel kriegt man von Gegnern, etc).


• Explanation: Die Funktion des Items, so wie sie im Menü angezeigt wird.

• Classification: Hier kann man auswählen, welchen Typ von Item man erstellen will.


• Common Goods: Das sind Items, die einfach nur da sind, ohne einen besonderen Zweck zu erfüllen. Sinnlos? Nein! Stell dir vor, du erhältst ein Päckchen, dass du abliefern musst. Das sollte man weder benutzen können, noch kann man es ausrüsten, etc. Aber man muss es halt haben. Common Goods sind die einfachsten Items. Name, Text und Preis - das wars!

• Arms: Ahhh...da sind wir also endlich bei den Waffen. Natürlich brauch jeder Held eine gute Waffe (okay, warum eigentlich?). Unser Held wirt ganz klassisch Schwertträger. Natürlich ist das nicht besonders einfallsreich, aber die Ritter im Mittelalter haben auch nicht mit Mistgabeln gekämpft, weil alle anderen Schwerter hatten, oder? Der Vorteil in dieser Kategorie ist: Wenn ihr alles versteht, lässt sich das Wissen grundsätzlich auf alle anderen Ausrüstungsgegenstände übertragen. Hier gibt es jetzt eine ganze Menge neue Auswahlmöglichkeiten.


• Name, Price, Explanation: Altes Schwert, 50, "Ein rostiges Langschwert, zweihändig" (Natürlich nur ein Vorschlag)


• Equip Hand: Typ des Schwertes: Einhändig (One) oder Zweihändig (Both). Ich denke, ergibt sich aus der Beschreibung der waffe, hmm?


• The Hero who..: Wer kann die Waffe benutzen? Macht am besten alle anderen Helden (falls vorhanden) au0er unserem neuen weg, also nur er kann die Waffe benutzen. Ist fast immer auch der beste Weg.


• Change Ability Value: Welcher wert wird durch das Anlegen geändert? Ich sehe das gerne realistisch: Was bringt uns so ein Schwert? Zuerst einmal und auch hauptsächlich mehr Angriffsschaden (schlechte Waffe, + 8). Schläge des Gegners können etwas besser abgewehert werden (Verteidigung + 2), die Zauberkraft/Geistesstärke wird nicht beeinflusst, und die Geschwindigkeit muss unter dem Gewicht leiden (schwere alte Waffe, -3). Bei einem Bogen wär das wieder anders, da man damit weder abwehrt, noch laufen muss.


• Battle Animation: Das Erstellen von Animationen besprechen wir später noch, aber man sollte für jede Waffe schon die passende Animation auswählen, die dann im Kampf beim Zuschlagen angezeigt wird."Sword A" ist recht gut dafür, denke ich.


• Preemptive Attack: Man schlägt auf jeden Fall vor dem Gegner zu.


• Attack Twice: Innerhalb eines Angriffs wird zweimal Schaden zugefügt.


• Attack All Enemies: Alle Feinde werden bei einem Angriff geschlagen.


• Ignor.Monster Evasion: Trotz des Namens, bedeutet es einfach nur, dass man gewöhnlich daneben haut ^^;;

• MP Cost: Wie viel MP soll ein Schlag mit der Waffe kosten? 0!


• Hit Chance: Wie groß ist die Chance, dass ein Schlag trifft? 80-90%..


• Critical Hit Chance: Wie groß ist die Chance, einen kritischen Treffer zu landen? So um die 10%..

• Shield: Der nächste Itemtyp, das Schild. Auch bekannt aus den meisten RPG's, zur Abwehr sinnvoll. Kann natürlich nur in Verbindung mit Einhändern eingestzt werden.

• Prevent Critical Hit: Gegner können Helden nicht mehr mit kritischen Treffern verwunden.


• Rise Avoid of...: Erhöht die Chance, dass man gegnerischen Schlägen ausweicht.


• Half MP: Für Skills/etc. braucht man nur noch die Hälfte der MP. Bei einem Schild nicht wirklich sinnvoll.


• No Terrain Damage: Man kann bestimmte Gebietstypen bestimmen, in denen man bei jedem Schritt Leben abgezogen bekommt. Wenn man das jeweilige Item ausgewählt hat, erhält man keinen Abzug mehr.

• Armor: Rüstung, keine neue Funktionen.


• Helmet: Helm, ebenfalls nix neues..


• Other: Kleine Accesoires, Amulette, etc. Ratet mal...nix neues ^^ Wie ihr sehtt, könnt ihr jetzt ganz leicht schon die komplette Ausrüstung des Helden fertigstellen. Cool, was?

• Medicine: Items, die bestimmte Sachen heilen. Potions fallen in diese Rubrik. Und damit wollen wir auch gleich anfangen, weil hier mal wieder mehrere Einstellungen neu sind. Nennt das item Potion, stellt ein, das alle es benutzen können, den Preis, und die Erklärung.


• Use Number Of Times: Wie oft kann man das Item benutzen? Normalerweise ein Mal, es sei denn, es ist ein besonderes Item. Limitless ist auch oft nützlich..


• Effect Range: Kam zwar schonmal im Skillbereich vor, aber trotzdem: Wen trifft das Item, einen Helden, oder die ganze Party?


• HP Recovery: Falls HP geheilt werden soll (wie bei uns), kann man entweder eine bestimmte Prozentzahl der Gesamt-HP heilen(linkes Feld), oder eine bestimmte Menge. (Mal wieder) rational gesehen: So ein Trank hat eine bestimmte Menge, die garantiert nicht bei einem Helden 3000 HP heilen wird, und beim anderen nur 30, weil sie auf verschiedenen Levels sind, oder?


• Mp Recovery: Genau das gleiche, nur mit der MP.


• Use only in Field: Das Item darf nicht im Kampf benutzt werden.


• Effective only on...: Item kann nur mit "toten" Helden verwendet werden (wiederbeleben).

• Book: Ein Buch, aus dem man eine bestimmte Technik lernt. Ist einigen von euch vielleicht aus diversen RPG's bekannt. Neues gibts hier kaum.


• Learn Tech Skill: Welcher Skill wird gelernt? Wenn ihr, wie ich euch geraten habe, den leichten Heilungsskill gelernt habt, dann packt ihn hier rein. Sonst lasst es erstmal. Den Preis macht ihr auf 0, schließlich soll man so etwas wertvolles ja finden, und nicht (ver)kaufen.


• Material: Da ist den Programmierern/Übersetzern wohl kein passender Name eingefallen... Mit diesen Items wird ein bestimmter Wert des Helden dauerhaft verändert. Oder auch mehrere. Das heißt, wenn man zum Beispiel ein Item mit dem Namen "MP-Apfel" macht, wird durch ihn die MP des Helden für den Rest des Spieles gesteigert. Solche Items sollten immer sehr wertvoll sein, und am besten nicht käuflich erhältlich, da man seinen Helden sonst künstlich "aufpowern" könnte.


• Unique: Wieder kein sehr treffender Name. Einfach ein Item das einen bestimmten Skill auslöst, wie zum Beispiel in FF7 die Granate einen Feuerzauber bewirkt.


• Using Message: Bei "Common Item" kommt die für Items normale Nachricht, wenn man es im Kampf benutzt, unter "Base on Setup of ...." kommt die Nachricht, die auch der Skill hat. das heißt, wenn man einen Heilstein macht, der den Skill leichte Heilung bewirkt, kommt entweder eine Nachricht vom Typ "Herr Yx benutzt den Heilstein", oder "Herr Yx zaubert die Leichte Heilung".

• Initial Equipment: Hier könnt ihr die Anfangsausrüstung einstellen. Packt ihm die schlechteste Waffe und eine schlechte Rüstung rein. Warum nur so wenig? Unser Held ist schließlich schlecht, also soll er nicht direkt am Anfang mit Waffe, Rüstung, Helm, Extra usw. dastehen. Und ein Schild kann er ja nicht tragen, da die Waffe zweihändig ist, hmm?


• Unarmed Battle Animation: Die Kampfanimation, die erscheint, wenn der Held ohne Waffe angreift. Lasst es am besten auf "Hit A".


• Skills: Hier kann man einstellen, auf welchem Level der Held welchen Skill lernen soll. Dazu müsst ihr einen Doppelklick in das erste frei Feld machen, und dann Level und Skill auswählen. Packt am besten den Skill "Kraftschlag" auf Level 2 oder 3, damit man nach dem Austeigen schon erste Erfolgserlebnisse verbuchen kann.


• Tech Skill Slot Name: Wenn der Auswahlpunkt für die Skills im Kampf später einen eigenen Namen für diesen Helden haben soll, müsst ihr ihn hier eingeben. Das klingt zwar nicht besonders sinnvoll, ist aber schon gut, wenn man zum Beispiel einen Magier hat, dann nennt man das bei ihm "Zauber", und beim Kämpfer zum Beispiel "Schw.Tech."...

Der letzte Abschnitt bleibt allerdings noch unbesprochen. Sorry, aber das kommt erst im nächsten Teil (vorraussichtlich, ich versprech jetzt gar nix mehr ^^).

Ganz so will ich euch jetzt aber auch nicht stehen lassen, also beendet die Database (übrigens immer mit Ok, wenn man Cancel macht, wird alles geänderte gelöscht!!!!!) und erstellt auf der Kampfarena Map im Eingangsbereich ein Event. Als Grafik dafür könnt ihr am besten die Truhe aus dem CharSet "Object 1" nehmen.
Stellt auch Fixed Graphic ein, da sich die Truhe sonst "öffnet" wenn man sie von der Seite anspricht. Doppelklick ins große Feld, und im Event Menü auf Seite 1, wenn ihr nicht drauf seit. In der linken Spalte seht ihr jetzt den Befehl "Add Item", klickt ihn an. Oben müssen wir zwischen Item erhalten (Add) und abgeben (Drop) wählen, und bleiben natürlich bei Add. Darunter lassen wir "Fix" aktiviert, und wählen "unsere" Potion aus, denn im Moment ist das erste Item der Liste aktiviert, das zwar auch Potion heßt, aber "englisch" ist. Unter "Operand" wählen wir auch Fix, und dann 2.
Okay, danach noch eine Message alà "2 Potions erhalten!". Vergesst nicht, davor ein Face: Erase zu setzen, sonst kommt die Mitteilung noch mit dem Gesicht des Helden oder gar des Soldaten. Dann aktiviert ihr den nächsten freien Switch, macht eine zweite Seite, mit der Bedingung, dass der Switch aktiviert ist, ändert die Grafik dort auf die offene Truhe (gleiche Grafik, nur Face-Direction: Left).
Das heißt, sobald man die Truhe öffnet, nimmt man zwei Potions heraus, und sie ist dann dauerhaft offen und leer..

Was wäre ein Rpg ohne die Kämpfe gegen Massen von Monstern, und starken Endgegnern. Zu aller erst müssen wir ein weiteres Mal in die Database. Was, schon wieder? Jap, und so schnell kommen wir auch nicht mehr raus ^^. Okay, wie ihr höchstwahrscheinlich schon geraten habt, gehen wir nun auf die Rubrik "Monster". Auf bekanntem wege fügen wir ein neues Monster hinzu. Jetzt wieder der bekannte Streifzug:

• Name: Der Name, jetzt zum beispiel "Echse".


• Ability Value: Die Werte des Monsters, genau so, wie auch der Held sie hat. Vor allem hier wird viel Kleinarbeit zu tun sein, denn diese werte müssen auf Schwierigkeitsgrad, Stärke des Helden/der ganzen Gruppe, Anzahl der Monster, die gleichzeitig kämpfen sollen, und, und, und... Wenn wir davon ausgehen, dass der Held gegen zwei Echsen kämpfen soll, er auf Level 1 ist, schlechte Ausrüstung hat, alleine kämpft, dass niemand Skills kann, und dass der Kampf für einen Level 1 Kampf recht schwer werden soll, eignen sich die Werte: HP: 20, Attack: 15, Mind: 1(Keine Zauber), MP: 1(Dito), Defense: 18 und Agility: 23. Natürlich könnt ihr nach Belieben andere Werte nehmen.


• Select Monsters Graphic: Hier kann die Grafik des Monsters ausgewählt werden. Zu unserem echsenmensch passt natürlich hervorragend die Grafik "Lizardmen". Im Gleichen Auswahlmenü können wir unter "Change Fellow Colour" die Farben des Monsters ändern, zum Beispiel, um verschiedene Gattungen zu gestalten, etc. Unter "Transp." Könnt ihr das Monster transparent anzeigen lassen, und unter "Air" könnt ihr es als fliegend gelten lassen.


• Gain: Was bekommt man am Ende des Kampfes? "Exp", also Erfahrung. Der Kampf sollte schwer sein, aber man kämpft gegen zwei Gegner, der Held wird schon bei 30 Exp aufsteigen. Wenn man 6 auswählt, müsste der held also diese Party drei Mal besiegen, um zum ersten Mal aufzusteigen. "Money" bedeutet das Geld, dass man am Ende des Kampfes erhalten wird. Auch hier muss wieder abgeschätzt werden. Der Kampf ist hart, der Held sollte sich also vom Geld Potions etc. kaufen. Eine andere Variante ist natürlich, dass der Held sich eine neue waffe kaufen sollte. Da ich als nächstbeste Waffe ein Breitschwert für 100 erstellt habe, würde ich meinen Preis für die Potions auf 30 heruntersetzen, dafür das Geld, dass ein Monster hergibt, auf 10 setzen. Und "Item" ist EIN Item, dass man für jede besiegte echse mit einer gewissen Chance erhält. In meinem Fall hier eine Potion mit einer Chance von 35%. Schließlich soll man nicht sofort das ganze Geld für die Waffe sparen.


• Critical Hit Chance: Die Chance für einen kritischen Treffer (Vielleicht so um die 20%, wenn überhaupt).


• Usually Miss: Erhöht die Rate für Schläge daneben (Aus lassen!).


• Action Patterns: Hier werden dem Monster seine Skills verpasst. Vorgegeben bei jedem neuen Monster ist "Subject:Normal Hit Conditions:Usually Priority:50". Was heißt das? Der Name der Attacke ist Normal Hit. das ist ein vorgegebener Name, der einfach bedeutet, dass das Monster losrennt und draufschlägt. Die Bedingung, wann das Monster die Attacke auslöst steht auf Usually, also gewöhnlich. Das heißt, der Gegner wird diese Attacke ohne besonderen Grund benutzen. Priority steht auf 50. Priority ist die Dringlichkeit, mit der eine Attacke im Kampf benutzt werden soll. Am besten klicken wir mal auf das freie Feld unter Normal Hit, und drücken dann Enter.


• Action Conditions: Die bedingung, mit der diese Attacke ausgeführt wird.


• Type: Usually: Gewöhnliche Attacke, wird benutzt, wenn kein Grund vorhanden ist, eine andere attacke auszuführen.


• Priority: Dringlichkeit, mit der die Attacke ausgeführt wird.


• Turn switch ON/OFF: Wenn die Attacke ausgeführt wird, wird ein bestimmter Switch an/ausgeschaltet. Wozu das gut ist, im nächsten Abschnitt.

• Type: Switch: Attacke wird nur benutzt, wenn ein bestimmter Switch aktiviert ist. Sehr nützlich, zum beispiel, könnte man einen Switch anschalten, wenn der Held eine besondere Waffe trägt, die alle Orks verursacht zu fliehen, etc.


• Switch: Der Switch, der Angeschaltet sein muss.


• Type: Turn Number: Die Attacke wird automatisch in einer gewissen Runde ausgeführt. Zum Beispiel könnten Diebe fliehen, wenn sie nach 5 Runden noch Kämpfen, usw.


• Turn Number: Hier muss nur im zweiten Feld die Nummer der Runde eingeschaltet werden.


• Type: Monster Quantity: Der Gegner wird diese Attacke benutzen, wenn eine bestimmte Anzahl an Monstern vorhanden ist.


• Monster Quantity: Die Attacke wird benutzt, wenn mehr (erstes Feld) als x, und weniger (zweites Feld) als y Monster gegen den Helden kämpfen.


• Type: Oneself HP: Attacke wird bei bestimmten HP Wert des Gegners gestartet. Zum Beispiel bei Heilung! Oneself HP: Die Attacke wird ausgeführt, wenn der Gegner mehr als x Prozent (erstes Feld) und weniger als y Prozent der Gesamt-HP hat.


• Type: Oneself MP:Attacke wird bei bestimmten MP Wert des Gegners gestartet.


• Oneself MP: Die Attacke wird ausgeführt, wenn der Gegner mehr als x Prozent (erstes Feld) und weniger als y Prozent (zweites Feld) der Gesamt-MP hat.


• Type: Hero Average Level: Die Attacke wird ausgeführt, wenn das Durchschnittslevel der Helden ((Level-Held 1 + Level-Held 2+ ....)/Heldenzahl) einen bestimmten Wert hat.


• Hero Average Level: Der Gegner führt eine bestimmte Attacke (Flucht, härtere Schläge) aus, wenn das Durchschnittslevel der Helden über Wert x (Feld 1), und unter Wert y (Feld 2) liegt..


• Type: Hero Exhaustion: Theoretisch greift der Gegner mit dieser Attacke an, wenn der Held einen bestimmten Hp-Wert hat. Praktisch habe ich allerdings durch diese Funktion keine Veränderungen hinbekommen...

• Behaviour: das mögliche (vorprogrammierte) Verhalten des Gegners. Hier kann aus verschiedenen vorgegebenen Möglichkeiten ausgewählt werden.


• Normal Hit: Ein normaler Schlag, einfach mittendrauf. Die Standartattacke, die bei jedem Gegner schon voreingestellt ist.


• Critical Hit: KEIN kritischer Schlag, wie der Name vermuten lässt, sondern zwei Schläge hintereinander. Läuft auf das gleiche hinaus, aber nimmt eventuell zu viel Leben ab, wenn man sich verkalkuliert.


• Defend: Der Gegner verzichtet darauf, anzugreifen, sondern bereitet sich auf die Angriffe der Helden vor, dass heißt, er wird weniger Schaden erleiden. Besonders sinnvoll eigentlich nicht, sollte man höchstens als Usually Attacke neben dem normalen Angriff verwenden.


• Watch State: Als normale "Attacke" meiner Meinung nach ziemlich sinnlos, der Gegner beobachtet nur die Situation. Natürlich kann man derartiges auf Switch machen, dass heißt, wenn im Kampf ein besonderes Ereignis eingetreten ist.


• Accumulate Power: Wer kennt sie nicht? Meldungen der Art "Herr Yx" lädt sich auf. Das ist genau diese Funktion, das Monster wird seine Angriffskraft sammeln, und dafür in der nächsten Runde fest zuschlagen. Das lässt sich gut mit einem Normal-Attack-Skill verbinden, der auf den Switch "Aufgeladen" eingeschaltet wird, etc.


• Self-Annihilation: Der Gegner wird sich selbst umbringen, und dabei den Helden doppelt so stark wie mit einem normalen Angriff verletzen. Denkbar wäre ein Bomber wie in FF7, der nicht angreifen kann, sich dafür immer weiter aufbläst, und nach 5 Runden verheerenden Schaden verursacht.


• Escape: Der Gegner wird fliehen, gut nützlich in Verbindung mit "Hero Average Level", dass heißt, der Gegner wird vor einer starken Pasrty Angst bekommen, und abhauen.


• Nothing: Der Gegner tut nichts. Denkbar in verbuindung mit einem Critical-Hit, der den Gegner viel Kraft kostet, und deswegen er eine Runde aussetzen muss.


• Skills: Hier kann der Gegner einen der Skills benutzen, die auch der Held einsetzen kann. Die Eigenschaften werden alle übertragen, nur dass der Held angegriffen wird, und nicht anders.


• Transform: Der Gegner transformiert zu einem anderen Wesen. So kann zum Beispiel ein Endgegner nach 10 Zügen zu einer stärkeren Form mutieren, etc.

So, damit wäre die Monsterrubrik abgeschlossen. Kämpfen können wir jetzt trotzdem (noch) nicht. Spielt ein bisschen mit den Skills herum, denkt euch Kombinationen aus, und so weiter. Unsere Echse sollte allerdings erstmal keinen anderen Skill bekommen, da sie sonst viel zu stark ist. Okay, ganz fertig sind wir natürlich noch nicht, die "Condition Effect" und "Afflicted Condition" Felder sind wie immer frei geblieben, aber ich verspreche euch, dass sämtliche Geheimnisse darum am Ende dieses Kursteils aufgedeckt sein werden. Wenn ihr alles verstanden habt, können wir ja mit dem nächsten Kapitel fortfahren.

Jaaaa!! Wir bleiben in der Database ^^ So, erstmal alle euphorischen Gefühle gebremst? Gut! Wir bleiben trotzdem in der Database, weil dort alles einzustellen ist, was man für Kämpfe einstellen kann. Allerdings wechseln wir ein weiteres Mal das Stammverzeichnis, und wählen in der oberen Leiste "Monster-Party". Links müssten wir die bekannte lange Liste sehen, und rechts sollte uns eine Hexe vor einem Wald ins Auge springen. Wo genau sind wir hier? Richtig, im Monster PArty Menü. Aber was kann man hier machen: Kurzum, man stellt die gegnertruppen zusammen. Aber nicht nur das, man schreibt ganze Kämpfe. Der Kampf lässt sich hier wie ein normales Event gestalten, Switches können eingeschaltet werden, Gespräche können geführt werden, und und und. Ja, auch Kämpfe laufen (fast) wie der Rest ab. Zeit, mal wieder systematisch durchzugehen. Wählt ein freies Feld aus (wenn nötig, schafft eins).

• Name: Der Name der Monster-Party. Eigentlich völlig irrelevant, da der Spieler ihn niemals zu sehen bekommen wird, aber nachher zu Üersichtsgründen empfehlen sich passende Namen wie 2 Echsen (auch jetzt sehr passend ^^) oder Endgegner - Golem.


• AutoName Group: verpasst der Gruppe automatisch einen Namen. Wenn sie aus zwei Echsen und einem Slime besteht, wird der intelligente Name "Echsex 2, Slime" zu Stande kommen.


• Battle Test: der bei weitem meistgebrauchteste Knopf in dieser Rubrik. Man wählt die Helden, ihre Level und Ausrüstung aus, und startet den Kampf, den man auch im Spiel erlben wird. Nur hier können die letzten Feinen Einstellungen vorgenommen werden, etc. In dieser Rubrik läässt sich mit dem Knopf "Initial Stat." übrigens die Anfangsausrüstung des Helden bequem und schnell einichten. Übrigens: Im ampf hat man SEHR viele nützliche Items zur Hand ^^. Macht an jetzt am besten nach jeder veränderung an Gegnern, oder am Kampf selbst einen Testkampf, um die Auswirkungen zu prüfen.


• Change BG: Hier lässt sich der Hintergrund für den Testkampf bestimmen, was allerdings keine Auswirkungen auf den Spielverluf hat, außer, dass man die Monster möglichst passend plazieren kann.
• "Bild": Dort, wo man jetzt noch den leeren Hintergrund sieht, kann man gleich die Monster sehen. Anhand dieser Grafik kann man die Monster so verscheieben, dass sie zum Background passend angezeigt werden.
• Add: Das Monster, das in der rechten Liste ausgewählt ist, wird zur MonsterParty hinzugefügt. Wählt die Echse aus, und fügt zwei hinzu!


• Delete: Falls innerhalb der Monsterparty ein Gegner ausgewählt ist, wird er wieder entfernt. Clear All: alle Monster aus der Party werden entfernt.


• In Row: Die Monster werden alle in einer Reihe relativ zentral aufgestellt, fliegende Monster höher, als normale.


• Appear in: Die einfache Auswahl, in welchem Landschaftsteil diese Gegner auftauchen können. was genau das für Landschaften sind, etc. in einem späteren Teil. Meine Empfehlung: Immer alles aktivieren, denn von alleine kommen sie eh nicht.

• Battle Events: Ein sehr wichtiger Teil dieser Rubrik. Vor allem in Bosskämpfen ist es doch toll, wenn die Helden sich nach einigen Runden Wortgefechte mit den Bösen liefern usw. Eigentlich sollte uns das ganze noch von den normalen Events bekannt vorkommen. Das ganze lässt sich in 100 Seiten aufteilen. Wenn ihr bei Trigger auf die drei Punkte klickt, bekommt ihr ungefähr das geliefert, was bei Events die linke obere Seite ausmacht, also die Startbedingungen.


• Switch: Insgesamt zwei Mal, das heißt, das Event wird durch einen Switch gestartet, der auf einer anderen seite aktiviert werden kann, oder durch einen speziellen Skill. erinnert ihr euch, an den Skill Typ Switch, den wir ausgelassen haben? Genau so einen kann man hier zum Beispiel gebrauchen. Oder ein Event, dass einen Switch aktiviert. Natürlich lässt sich dass auch so gebrauchen, aber Kämpfe werden gerade durch so etwas abwechslungsreicher! (Übrigens: der ausgelassene Escape-Skill lässt einen im Kampf sicher fliehen.) Okay, zurück ins Menü. Die Variablen lassen wir noch aus.


• Turn No.: Wie vorhin bei den Monsterskills, lässt sich hier ein bestimmtes Ereignis hervorrufen, wenn eine bestimmte Rundenzahl vorbei ist (Nur ins zweite feld eingeben!).


• Exhaustion: Gleiches Problem wie eben -_-


• Monsters: Hier können wir ein Monster auswählen, und bestimmen, bei welchem ungefähren HP Wert das Ereignis hervorgerufen wird.


• Hero: Hier können wir das gleiche auswählen, nur ist die Frage, was passiert, wenn die HP des Helden einen bestimmten Wert erreicht hat. Wir setzen den ersten Wert auf 0 (Hp muss mer als 0% der Gesamt-HP betragen), und den zweiten auf 25 (Ereignis wird hervorgerufen, wenn der Held weniger als 25% seiner Gesamt-HP hat). Dann bestätigen wir.

• Enemy Encounter: Wenn man bei MonsterParty auf ein Monster in der Anzeigre klickt, kann man die Funktion "Route from appearance" auswählen. Das heißt, das Monster wird versteckt, und ist so unsichtbar. Wenn man jetzt während des Kampfes auf Enemy Encounter geht, und dieses Monster anschaltet, wir es angezeigt. Das ist vor allem nützlich, wenn man wie zum Beispiel im englischen Spiel DestinysCallComplete gegen Graf Dracula kämpft, und er sich nach einer Zeit in 4 Fledermäuse auflöst. Auch sonst, wenn Endgegner während des Kampfes Gehilfen rufen sollen etc.


• Stop Combat: Beendet den Kampf auf der Stelle, nützlich, wenn man den Gegner einen finalen Schlag ausführen lässt, von dem die Helden ohnmächtig werden, usw.

Auch wenn ihr noch nicht alle anderen Befehle kennt, so seit doch sicher, dass sie alle noch vorkommen werden! Als nächstes können wir ein neues Monster machen. Die Soldatin, die die Kampfarena bewacht. Warum genau, wird noch klar werden. Wir sollten übrigens davon ausgehen, dass der Held auf Level 3 ist, noch die Standartausrüstung hat, und es ein harter Kampf werden soll. Macht, wenn ihr sie als Gegner habt, eine Party, in der nur sie ist, und macht ein Event, dass zu beginn des Kampfes aufgerufen wird. Darin können wir einen Text wie: "Trainiert habt ihr genug. Jetzt zeigt, was ihr gelernt habt!" packen. Wozu genau, wie gesagt gleich. Denn jetzt folgt erstmal ein längerer Kursprojekt-Abschnitt. Erinnert ihr euch noch, die Soldatin sagte, sie würde uns nur hereinlassen, wenn wir den Code kennen? Okay, WER kennt den Code? Logischerweise der Soldat, der draußen herum spaziert. Deshalb rufen wir sein event auf, und verpassen ihm eine zweite Seite. Als bedingung aktivieren wir links den Switch "Codebenoetigt", und geben ein kleines Gespräch ein, das darauf hinausläuft, dass der Soldat den Code vergessen hat, ihn aber bei sich zu Hause aufgeschrieben hat, und dem Held den Schlüssel für sein Haus gibt. Erinnert ihr euch noch an den letzten Teil, als wir das Item "Schlüssel" erstellt haben? Wenn nicht, dann lest es nach, oder macht es einfach nochmal neu. Doch, falls ihr den Schlüsel noch habt, ändert die Classification von Common Goods auf Switch. Unbedingt die Anzahl der Benutzungen auf unendlich stellen, und einen neuen Switch aktivieren. Sehr gut, zurück auf die Stadtkarte. Ich hoffe, ihr habt, als wir die Stadt im ersten Teil erstelt haben, gleich mehrere Häuser angelegt. Denn eins werden wir jetzt benötigen, das soll nämlich das Haus des Soldaten sein. Setzt in den Eingang eine Tür. Ihr wisst nicht wie das geht? Ganz einfach, macht ein Event, und wählt als Grafik eine der Türen aus "Object1" aus. Jetzt können wir auf die erste Seite bei Push Key etwas wie "Sie ist verschlossen" anzeigen lassen. Jetzt setzen wir noch ein durchsichtiges Event genau vor die Haustür, das unter dem Helden ist, und "On hero touch" funktioniert, also wenn der Held darüber läuft. Dieses Event soll den Switch "vortuer" aktivieren. Jetzt setzen wir irgendwo auf die Stadtkarte ein Event, am besten aus Übersichtsgründen nach oben links in die Ecke. Dieses Event sollte ebenfals durchsichtig sein, und auf Parallel Process geschaltet sein. Als Startbedingungen (AUF SEITE 2!!) aktivieren wir ganz einfach sowohl den Switch, der vom Item Schlüssel aktiviert wird, als auch den Switch, der aktiviert wird. Als Effekt sollte ein Switch "Tür offen" angeschaltet werden, die beiden Switche wieder aus, das Item abgenommen werden, und eine Message "Ja, die Tür ist auf" angezeigt werden. In das Tür-Event plazieren wir eine zweite Seite, die auf den Tür-Offen-Switch hört, und das Event Below Hero setzt, durchsichtig macht, und in eine neue Map teleportiert, die das innere des Hauses darstellen soll. In das Parallel Process Event müssen wir übrigens die erste Seite aufrufen lassen, sobald NUR der Switch vom Item aktiviert ist, dann lassen wir eine Nachricht "Hier kann ich den Schlüssel nicht benutzen" anzeigen, und den Item Switch wieder ausstellen, damit man das Item öfters neutzen kann. Warum diese Reihenfolge? Ganz einfach. Der Rpg-Maker überprüft die Seiten von rechts nach links, das heißt, er wird zuerst kucken, ob beide an sind, bevor er schaut, ob nur eins an ist. Sonst wären vielleicht beide an, und trotzdem würde die Fehlschlag-Nachricht zuerst kommen. Rund um das Feld vor der Tür müssen übrigens weitere Events plaziert werden, die den Switch wieder ausschalten, damit der Switch nicht immer anbleibt, und das Spiel denkt, man stände noch immer vor der Haustür. Okay, so weit, so gut. Im Haus können wir in eins der Regale ein Event plazieren, mit dem man das Common-Good-Item "Code" erhält. Es muss auch ein Switch aktiviert werden, sonst könnte man sich den Code ja zig mal holen! Sonst sollte es dort nichts zuholen geben. Übrigens, packt in das Event, mit dem man herausteleportiert wird eine zweite Seite, in der man herausteleportiert wird, die aber den Switch Tür offen ausschaltet, wenn man den Code hat. Sehr schön. Am besten probiert ihr das ganze mal aus, und testet die Reaktionen des Soldaten, wenn ihr ihn zu verschiedenen Zeitpunkten ansprecht (Code benötigt, Code benötigt, und Schlüssell, Tür offen, Code dabei, ...). Falls Fehler dabei sein sollten, überprüft den Spielverlauf. Zurück in die Kampfarena. Exditiert das Soldatin-Event, dass den Durchgang versperrt, in dem ihr auf die letzte Seite unter Bedingungen einstellt:

• Item hold: Codezettel. Das bedeutet, das Ereignis wird ausgelöst, wenn der Held den Codezettel besitzt.


• Hero Need: Bedeutet übrigens, dass das Ereignis ausgelöst wird, falls ein bestimmter Held in der Gruppe ist.

• Name: Hier könnt ihr der Area einen Namen geben. Nützlich, wenn man die Weltkarte in verschiedene Areas aufteilt, etc.


• Set Area: Hier müsst ihr auf der Map jetzt den gewünschten Bereich auswählen, der dann die Area ist. Wählt den hinteren Bereich, der zuvor nicht erreichbar war.


• Map Encounter Rate Editor: Langer Name, kurzer Sinn: Die Monsterpartys, die auftauchen werden. Das könnte euch vielleicht noch vom Map-erstellen bekannt vorkommen. da handelt es sich exakt um das selbe, nur das alle Monster in der gesamten Map auftauchen.

So, jetzt müssen wir nur noch die Häufigkeit der Gegner einstellen. Schließlich wollen wir ja nicht, dass sie jeden Schritt kommen, oder nur alle 10.000 ^^. Deshalb plazieren wir ein Parallel Process Event in die Kampfarena. Als Effekt wählen wir den Befehl auf Seite 3 der events, "Encounter Rate". Hier müssen wir nur eine einzige Zahl einstellen, die bewirkt, nach wie vielen Schritten durchschnittlic ein Gegner auftaucht. 25 ist eigentlich ein guter Wert, auch wenn es zuerst nach recht viel klingt.
So, jetzt könnt ihr mal alles testen. Übrigens, wenn ihr keine Lust habt jedes Mal von vorne anzufangen: Wenn man mit esc. Ins Menü geht, und auf Save geht, kann man den aktuellen Spielstand abspeichern!
Und sobald ihr in der Kampfarena seit, und kämpft, sollte schon der erste Fehler auftauchen: Man kämpft auf einer Wiese?!?!
Um das zu ändern, gehen wir auf die "Map properties" der Kampfarena, und sehen uns die Auswahl rechts von der Hintergrundmusik an:

• Battle Background: Damit lässt sich bestimmen, wie der Kampfhintergrund auf der jeweiligen Map bestimmt wird.


• Parent Map: Die Auswahl hängt ganz von der übergeordneten Map ab. Auf jeden Fall wird die Einstellung übernommen.


• By Terrain Chip: Ein Thema, das vorrausichtlich im nächsten Teil des Kurses behandelt werden wird.


• Set To...: Die Funktion, die wir jetzt brauchen. Der Hintergrund wird fest ausgewählt. Für das Hausinnere passt immer noch am besten der BattleBackGround Castle.

So, ab jetzt wird bei jedem Zufallskampf, der auf dieser Map stattfindet der Hintergrund Castle verwendet werden. Wenn ihr jetzt nochmal durchtestet, sollten sich keine Probleme mehr ergeben!
Allerdings ergibt sich ein anderes: Der Held wird nicht besonders lange überleben. Deshalb errichten wir auf der stadtmap ein neues Haus samt inneren, dass dem Held gehören soll. An das Bett packen wir dann ein Event mit der Funktion: "Full Recovery: All Party Members". das heißt, alle Gruppenmitglieder werden voll geheilt.
Dann wollen wir uns nochmal kurz den Bosskämpfen widmen. Wie ihr euch schon gedacht habt, können diese ja kaum stattfinden, in dem man solange im Kreis läuft, bis der Endgegner kommt, hmm? Das ganze können wir jetzt gut mit der Soldatengegnerin verbinden, die wir schon erstellt haben. Ruft die Kampfarena Map auf, und editiert das zweite Soldatin Event. Packt ihr noch eine Message rein: "Ihr dnekt, ihr seid stark?! Dann kämpft gegen MICH!!", die einen Switch aktiviert. Es sollte klar werden, dass die Soldatin beim nächsten Mal ernst macht, und man auf Level 3 sein sollte.
Erstellt dann eine zweite Seite, mit dem Switch als Bedingung, und als Effekt den ersten Befehl auf Seite 2, Start Combat.

• Try Enemy Group: Die feindliche Party (in diesem Fall die, mit der Soldatin).


• Battle Background: Der Hintergrund, unbedingt mit Set: Castle!


• Escape Case: Free Escape bedeutet, dass die Flucht unmöglich ist (ÜBERSETZUNGSFEHLER!!!), und Stop Event, dass man fliehen kann. Wenn ihr Add Case auswählt, könnt ihr sehen, dass nach dem Event zwei leere Blöcke sind. VICTORY bedeutet, was passiert, wenn man den Kampf gewinnt, und ESCAPE, weas passiert, wenn man geflohen ist.


• Defeat Case: Was geschieht, wenn man verliert. Die voreinstellungg Game Over bedeutet, dass das Spiel beendet wird, auf Add Case kommt ein weiterer Fall dazu. Besonders nützlich, wenn man einen Kampf nicht gewinnen SOLL. Allerdings muss man da beachten, die Gruppe zu heilen, weil man sonst beim nächsten Kampf sofort stirbt.

wenn ihr wollt, könnt ihr bei beidem Add Case wählen, um den Kampf spannender zu gestalten. First Strike: Der Held darf zuerst zuschlagen.
So, wenn ihr alles eingestellt habt, füllt die Felder danach aus, vergesst die Heilung bei DEFEAT Case nicht, und macht bei VICTORY einen Switch an, und lasst euch hinaausteleportieren. Sobald ihr wieder hineingeht, sollte die Soldatin jetzt wieder den Eingang zur Kampfarena blockieren, weil man stark genug ist.
Jahuu, damit wäre dieses Kapitel, das wohl längste in der Geschichte des Rpgmaker-Kurses wohl abgeschlossen. Wenn ihr wollt, könnt ihr für die Kampfarena noch andere Gruppen erstellen, etc.

Vom längsten zu einem der kürzesten Kapitel. Warum? Das werdet ihr sofort sehen, sobald ihr die Databse-Rubrik Attributes aufruft. Viel einzustellen gibts hier wirklich nicht. Attribute sind mit waffen, Helden, Rüstungen, usw. verbunden. Jeder kennt wahrscheinlich ein Flammenschwert, oder die Schattenrüstung. Ein neues Attribut zu erstellen lohnt sich kaum, denn außer dem Namen muss man kaum etwas verändern. Übersetzt einfach die Namen ins Deutsche, und schon habt ihrs. (Schwert, Speer, Schock, Bogen, Feuer, Eis, Blitz, Wasser, Erde, Luft, Heilig, Schatten, Angriff, Verteidigung, Geist, Speed, Saugen).

• Classificaton: Die Art des Attributes: Magisches, oder Waffenattribut.


• Rate Of Effect: Für jedes attribut gibt es fünf verschiedene Stufen. Diese kann man auswählen, um zu bestimmen, wie stark eine Waffe mit diesem Attribut umgeht, usw.

Jetzt gehen wir die bisherigen Rubriken mal durch. In Hero lässt sich unter Afflicted Conditon einrichten, wie viel Schaden der Held mit einer Waffe des Typs "Feuer", oder mit einem Speer verursacht, bzw. Mit einem Skill. Bei Skills kann man unter Attack/Defens Attribut einrichten, mit welchem Attribut der Skill angreift, bzw. Vor was Schutz gegeben wird. Bei AusrüstungsItems gilt genau das gleiche. Und auch bei Mostern kann man einstellen, wie viel Schaden sie mit Feuerskills verursachen, usw. Wenn ihr wollt, könnt ihr ja einen Feuerskill entwerfen, oder ein Eisschwert. Das wars auch schon wieder ^^.

Wechselt in der Database einfach ins nächste Verzeichnis, nämlich Conditions. Conditions sind die aus allen RPG's bekannten Zustände, wie Vergiftet, Stumm, Schlafend, Blind, und so weiter. Der Vorteil: Auch hier ist schon fast alles was man braucht vorgegeben. Sicher, falls euch neue Zustände einfallen, könnt ihr auch welche entwerfen, deshalb gehen wir mal wieder alles durch.

• Normal: Der erste Zustand in der linken Liste ist ein besonderer, der unbedingt beibehalten muss. Normal bedeutet eigentlich nur Tot, bzw. Bewusstlos. Das heißt, wenn ihr im Kampf einen besonderen Namen für diese Bedingung haben wollt, dann müsst ihr sie hier ändern.


• Poison: Vergiftet, der Held verliert kontinuierlich Leben, auch nach dem Kampf.


• Blind: Blind bleibt Blind, der Held hat eine geringe Chance, den Gegner mit einem normalen Angriff zu treffen.


• Silence: Stumm. Der Held hat keine Chance, Zauber auszusprechen.


• Berserk: Wütend, Berserker. Die Verteidigung wird verringert, die Trefferchance reduziert.


• Chaos: Verwirrt, der Held wird seine Verbündeten angreifen.


• Sleep: Schlafend, der Held wird ausgelassen, und kann nicht unternehmen.


• Numb: Paralysiert.


• Shock: Geschockt. Der Held kann eine runde lang nichts unternehmen.


• MindBlow: MP-Entzug. Der Held verliert Zug für Zug MP.

• Name: Name des Zustandes.


• Classification: Die Art der Bedingung: Combat Effect bedeutet, dass die sich nur im Kampf auswirkt, bei Movement Effect auch im Rest des Spiels (Vergiftet).


• Colour: Die Farbe, mit der der Zustand im Kampf und im Menü angezeigt werden soll.


• Priority: Die Wichtigkeit des Zustandes. Wenn ein Held zwei Zustände hat, wird der mit höheren Priority angezeigt werden.


• Action Limitation: Die Begrenzung des Zustandes. Restriction beduetet grundsätzlich erstmal Handlungsfreiheit, Inside Battle Handlungsunfähigkeit, Common Enemy Attack, dass nur der Feind angegriffen wird, und Common Ally Attack, dass nur Verbündete attackiert werden.


• Effect Chance: Wieder die bekannten Buchstaben. Wie groß ist die Wahrscheinlichkeit, dass der Held in den Zustand versetzt wird, eine Waffe den Zustand bewirkt usw.


• How to Heal: Natural Healing: Das Opfer wir nach X Runden mit einer Wahrscheinlichkeit von Y% vom Zustand befreit. Healing by The Shock: Das Opfer wird nach einem Treffer mit einer Wahrscheinlichkeit von Z% geheilt.


• Abilitys Half Cost: Angriff, Verteidigung, Geist oder Speed werden halbiert.


• Hit rate Change: Die trefferwahrscheinlichkeit des Opfers wird auf X % gesetzt.


• Cant Use...: Man kann nicht angreifen (Hit chance), oder keine Zauber aussprechen (Mind Chance).


• Ally state Message: Die Nachricht, die erscheint, wenn der Held in diesen Zustand fällt.


• Enemy State Message: Die Nachricht, die erscheint, wnn ein Gegner in den Status fällt.


• Already in This state: Die Nachricht, die erscheint, wenn das Opfer vergiftet wird, und schon vergiftet ist (bzw. eingeschläfert, wenn es schläft,...). Wenn keine Nachricht erscheinen soll, einfach auslasssen!


• State Is Regular...: Eine Nachricht, die jede Runde erscheint, wenn das Opfer in diesem Zustand ist: "Z.Bsp: Echse leidet unter dem Gift". Wenn keine Nachricht erscheinen soll, einfach auslassen.


• Recovery State Message: Die Nachricht, die erscheint, wenn das Opfer vom Zustand geheilt wird.


• Decrease HP: During Battle Turn: Pro Runde werden Maximal X % der Hp abgezogen, plus zusätzlich Y Punkte.


• Decrease HP: Map Movement: Alle X Schritte werden Y Punkte abgezogen.


• Decrease MP: During Battle Turn: Pro Runde werden Maximal X % der Mp abgezogen, plus zusätzlich Y Punkte.


• Decrease MP: Map Movement: Alle X Schritte werden Y Punkte abgezogen.

• Hero: Hier lässt sich unter Condition Effect bewirken, wie stark der Held anfällig für verschiedene Conditions ist.


• Skills: Bei Change to Condition könnt ihr auswählen, in welchen Zustand die Fähigkeit das Opfer versetzen soll.


• Items: Waffen: Bei Change To Condition könnt ihr auswählen, in welchen Zustand die waffe den Gegner versetzt, mit Changing Chance könnt ihr die Wahrscheinlichkeit verändern, dass das stattfindet.


• Items: Rüstung, Helm, Zusatz,..: Bwei prevent Condition können wir auswählen, vor welchem Zustand das Item schützen soll, und unter Prevent Chance, mit welcher Wahrscheinlichkeit es das tut.


• Items: Medicine: Bei Change to könnt ihr nicht auswählen, in welchen Zustand das Item den Helden versetzt, sondern von welchem es geheilt wird. Falls ihr eine Phönixfeder machen wollt, müsst ihr also Change to: Normal(Tot/Bewusstlos) auswählen. Wenn ihr wollt, könnt ihr ja jetzt eine erstellen, und auch Gegengifte, etc.


• Monster: Bei Condition Effect könnt ihr auswählen, welchen Effekt diverschiedenen Zustände auf den Gegner haben. So sollten Slimes eine tiefe Empfindlichkeit gegenüber Gift haben, Pflanzen aber eine hohe gegenüber Feuer, usw.

Kampfanimationen sind ein sehr wichtiger Bestandteil eines RPG's (Woher kenn ich diesen Satz? *g*) Erstens sind sie im Standartkampfsystem erforderlich, schließlich wollen wir ja nicht, dass deer Held den "Flammensturm" zaubert, aber auf dem Bildschirm kein Flammensturm zu sehen ist! Ein anderer nützlicher Verwendungszweck ist das Ausdrücken von Emotionen.
Vielleicht fragt ihr euch jetzt, warum man seine Emotionen im Kampf ausdrücken sollte, aber für die, die es noch nicht wissen: Man kann Animationen auch mitten im RPG abspielen lassen, und ihr kennt sicher alle diese "..." oder Schweisstropfen-Sprechblasen aus diversen professionellen Rollenspielen. Deshalb sollten wir uns auch ganz schnell vom Begriff Kampfanimationen verabschieden, denn man braucht sie immer und überall. Naja, fast *g*
Startet den Maker und die Database, falls ihr es noch nicht getan habt, und wählt die Registerkarte "Battle Animation". Schon wieder dieser Begriff ^^. Wie ihr sehen könnt, sind mal wieder Massen von Animationen vorgegeben, die wir aber auch drinlassen wollen, da sie allesamt sehr gut und nützlich sind. Also erhöhen wir wie gewohnt die maximale Anzahl, und erstellen eine neue Animation.

• Name: Hmm, dreimal dürft ihr raten.


• Select Battle Animation: Hier müsst ihr das Animation-Set auswählen, mit dem ihr die neue Animation erstellen wollt. Wenn wir zum Beispiel eine Attacke namens Frostbolzen erstellen wollen, dann könnten wir das Set "Cold" auswählen. Ab jetzt wollen wir einfach mal davon ausgehen, dass wir genau diese Attacke erstellen.


• Test Victim: Das Monster, an dem wir die Animation auslassen wollen, bzw. ein bestimmter Gegner, um sie ihm genau anzupassen. Aber warum sollte man eine Animation genau anpassen, schließlich kann man ja eine Attacke gegen jeden verwenden, oder? Im Prinzip ist das ja auch richtig, aber in guten Spielen sollten Kämpfe abwechslungsreich sein, das heißt, es sollte ordentlich Gebrauch von Events im Kampf gemacht werden. Also kann es auch gut sein, dass mitten im Kampf ein Gegner überläuft, oder Hilfe erscheint, die einen Eiszauber genau auf einen bestimmten Gegner schleudert, und ihn tötet. Und wenn die Animation in solchen Fällen nicht gut sitzt, dann...


• Max.Frame: Die Anzahl der einzelnen Bilder der Animation. Mit der Voreinstellung 20 werdet ihr in den meisten Fällen eher nicht auskommen, da ein einzelner Frame nur ein Bruchteil einer Sekunde ist. In meiner fertigen "Frostbolzen"-Animation habe ich 75 Frames gebraucht.


• SE and Flash Timing: Wenn man hier doppelklickt, dann kann man sich einen bestimmten Frame aussuchen, und in diesem einen Soundeffekt ertönen, und den Gegner oder den Bildschirm aufleuchten lassen. Das sollte man vernünftigerweise erst am Ende der Animation einbauen.


• Apply Scope: Hier kann man die Hilfslinie, die voreingestellt ist, und mitten durch den Gegner geht ausblenden lassen, falls dieser Zauber auf alle Gegner wirken soll. Sonst ist diese Linie ein gutes Mittel zur Orientierung.


• Y coord. Line: Hier lässt sich die zweite Hilfslinie unterhalb, über, oder genau mittig vom Gegner plazieren. Falls die Technik auf alle wirkt, lässt sich hier nicht auswählen.


• Frames: Hier könnt ihr zwischen den verschieden Frames wählen, um nachher Änderungen vorzunehmen, etc.

So, nun kommen wir zum wichtigsten Fenster, sozusagen dem "Animationseditor". Hier drin lässt sich die komplette Animation erstellen, Frame für Frame. Das System ist wirklich einfach! Ihr wählt in der unteren Leiste das Bild aus, das angezeigt werden sollt, und klickt dann oben im Feld auf die Stelle, wo es in der späteren Animation zu sehen sein soll. Mit einem rechtsklick auf die einzelnen Bilder könnt ihr dann Farbgebung, Größe (Magnification) und Transparenz verändern!
Das normale Vorgehen verläuft so:
Man wählt die Bilder für den ersten Frame aus (übrigens: Leider nur max 8!), und setzt sie an die richtige Stelle. da diese auch einen Moment zu sehen sein sollen, müssen wir genau diese Szene so um die dreimal machen. Natürlich kann man jetzt das ganze dreimal neu einsetzen, oder aber zu einem nützlichen Trick greifen, den ich euch gleich verrate. Danach verändert man die Bilder, bringt Bewegungen rein, Sounds und Flashs dazu, undundund...

Nun zu den Hilfsmitteln, die und das Erstellen von Animationen auf viele verschiedene Arten vereinfachen können. Sie befinden sich, ihr habt es schon geahnt, in der Spalte rechts vom Editor.

• Use Grid: Mit dieser Funktion aktiviert ihr ein vorgegebenes Raster, auf dem man die Bilder dann immer stückweise vorbewegt. Ist sehr nützlich, um zum Beispiel die Höhe von zwei Bildern genau gleich zu stellen, und erspart so Fummelarbeit.


• Get Previous: Das ist der Trick den ich vorhin schon angesprochen habe. Klickt man man irgendeinem Frame, ausser dem ersten auf diesen Knopf, dann wird der Frame die exakte Kopie des vorigen. Seht ihr? Man erstellt einen Frame, also Nummer 1, klickt auf zwei, dann auf "Get Previous", dann auf drei, wieder auf "Get Previous", und schon ist dieser Teil der Animation lange genug zu sehen.


• Edit: Bei Edit könnt ihr verschiedene Bereiche einer Animation editieren. Zuerst müsst ihr oben den Bereich angeben X * Y, wobei X der erste Frame, und Y der letzte ist, mit dem etwas gemacht wird. Wenn ihr euern Bereich ausgewählt habt, müsst ihr euch zwischen den beiden Möglichkeiten "Copy.Pag" und "Clear" entscheiden. Die erste Möglichkeit könnte man als eine erweiterte Form von "Get Previous" bezeichnen. Der Bereich, den ihr ausgewählt habt, wird kopiert, und ab dem Frame Z, den ihr noch eingeben müsst, wieder eingefügt. Das lässt sich wunderbar benutzen, wenn man einen Teilabschnitt der Animation wiederholen lassen möchte. Wählt ihr "Clear", wird einfach der Abschnitt, den ihr eigegeben habt, gelöscht.


• Complete: Das ist eine der nützlichsten Funktionen des Animationseditors, denn hiermit lässt sich auch vieeel Zeit sparen. Stellt euch folgende Situation vor: Ihr macht eine Feuerball-Animation, nud der Feuerball soll sich nach dem Aufprall über den ganzen Bildschirm ausbreiten. Wenn das flüssig aussehen soll, brauch man schonmal 30 frames und viel Arbeit. Aber nur, wenn man Complete nicht kennt! Nehmen wir an, der Ball prallt in Frame 40 auf, und soll sich bis Frame 70 ausbreiten. Setzt in Frame 40 den Ball so, wie er soll, und den gleichen Ball auch in Frame 70. Diesen vergrößert ihr dann so, wie ihr es wollt, am besten noch mit etwas Transparenz. Nun klickt ihr auf Complete, wählt rechts "Magnification" und "Transparency" aus, links oben 40 und 70, und linkis unten beides mal nur die Nummer des Feuerballs (achtung, sie muss in beiden Frames gleich sein!!). Dann klickt ihr auf OK, und schaut euch an, was der Maker da wieder wundervolles vollbracht hat! Complete ist nämlich ein Befehl, zwei Frames logisch zu verküpfen, dass heißt in diesem speziellen Fall, den Feuerball gelichmäßig größer und transparenter werden zu lassen, so dass am Ende eine flüssige Animation rauskommt.


• Create All: Diese Funktion ist eine weitere sehr nützliche. Vor allem kann man sie sehr gut zum Umfärben, verändern der Größe, etc. verwenden. Lasst es mich an einem Beispiel erläutern: Ich mache eine x-beliebige Animation, in der ein Stein vorkommt. Dieser Stein kommt in so ziemlich allen Frames vor, und dreht sich im Kreis (Okay, nächstes mal lass ich mir ein besseres Beispiel einfallen, ich versprechs). Allerdings will ich, dass dieser Stein, der im AnimSet klein und grau ist, in einem hellen rot schimmert, etwas größer ist, und auch noch ein bisschen transparent. Natürlich kann ich jetzt alle Steine in jedem Frame mit rechtsklick und so weiter editieren, aber das dauert ja Stunden. Also wieder nur ein Klick auf "Create All", rechts wird Pattern deaktiviert, und bei den anderen Möglichkeiten das gewünschte eingestellt, unter "Cells" klicke ich nur die 1 an (mein Stein ist immer die 1), und oben links aktiviere ich alle Frames, in denen der Stein vorkommt. Ok, und das wars! Der Stein hat jetzt überall die gewünschte Farbe, die richtige Größe und ist gleich transparent.


• Playback: Probierts aus ^^

So, das war jetzt alles, was man über Animationen wissen sollte... Achja..da fehlt doch noch was, der obligatorische Rundgang durch die Database, den ich mir jetzt aber sparen werde. Nun könnt ihr überall, wo eine Animation gefordert ist (Waffen, Skills,...) auch eure eigenen Anims einfügen. Noch was: Das Abspielen von Animationen im normalen Spiel.
Ihr müsst im Eventdialog auf Seite 2 "Show Battle Animation" auswählen. Dort müsst ihr links die Animation einstellen, rechts oben, auf welches Event sie abgespielt werden soll, außerdem könnt ihr noch wählen, ob sie auf Vollbild vergrößert werden soll, und ob das Event erst weitergehen soll, wenn die Animation abgelaufen ist.

JETZT wisst ihr aber wirklich alles, was man über das Erstellen von Animationen wissen sollte.

Ja, unglaublich aber wahr: Wir haben endlich den zweiten Punkt dieses Kurses erreicht, und, was noch unglaublicher ist: Schaltet die Database aus!!!!!
Okay, wir sind nicht für immer fertig mit ihr. Aber eine kurze Pause können wir uns ja mal gönnen, hmm? Zurück zum Thema: Das Importieren von Sets. Unter Umständen denkt ihr euch jetzt: Was gibts denn da groß zu importieren? Einfach runterladen, kopieren und einfügen. Das ist natürlich ein Weg, aber auch der schlechteste. Wer Dateien nur einfügt kann keine transparente Farbe bestimmen, und wird am Ende große Probleme haben. Unter Umständen können ganze Projekte verloren gehen (ACHTUNG: Das kann auch sonst passieren, deshalb am besten jede Woche eine Sicherheitskopie anlegen!!!).
Was es genau mit diesen Problemen auf sich hat: Vielleicht habt ihr euch ja schonmal auf dieser, oder auf einer anderen Seite umgeschaut, und euch Sets angesehen. Zum Beispiel Chipsets. Wie ihr auch im Maker sehen könnt, hat das normale Chipset im Uppermode pinke Hintergründe. Die werden aber im Spiel nicht angezeigt. Warum das? Standartmäßig wurde dieses Pink als transparente Farbe eingestellt.
Und genau diesen Effekt kann man mit Importieren bewirken. Wenn man einfach nur ins Verzeichnis kopiert, wird automatisch die Farbe als transparent genommen, die auf der Farbpalette die 0 hat, also standartmäßig: Schwarz.

2. Problem: Wenn euer Spiel fertig ist, und ihr es veröffentlichen wollt, oder wenn ihr nur eine Demo herausbringen wollt, müsst ihr das ganze natürlich irgendwie zusammenpacken. Da ergeben sich zwei Möglichkeiten. Variante A (die ich übrigens nicht bevorzuge): Erstellen einer Gamedisk. Dies lässt sich einfach machen, in dem man auf das Symbol neben "Projekt schließen" klickt. Das ganze Projekt wird dann zu einer selbst extrahierenden EXE-Datei zusammengefügt (und noch einigen anderen Dateien), die ihr dann anschließend nochmal zippt.
Sagte ich das ganze Projekt? Natürlich werden nur die Dateien hineingefügt, von denen der Maker auch weiß, dass sie da sind, also die importierten. Weil viele Leute einfach nur reinkopieren und dann eine Gamedisk erstellen, treten beim Starten von vielen Spielen Fehler auf.
Variante B, die ich bevorzuge ist einfach den Projektordner zu zippen. Der große Vorteil dabei: Die File ist kleiner, und außerdem kommt auch alles mit. Natürlich ist letzteres nicht das Problem, wenn ihr immer schön importiert.

Jetzt haben wir also schön uznd relativ lange über die Vorteile des Importierens gesprochen, aber eine Frage bleibt bestehen: Wie importiert man Sets?
Ein Klick auf das Symbol neben dem für die Database reicht schon. Jetzt müsst ihr nur noch auswählen, in welcher Rubrik ihr importieren wollt, für den letzten Punkt dies Kursteils wählen wir die Chipsets. Ladet euch deshalb vorher die beiden Chipsets "Mischset (#3)" (Fassade) und "Final Fantasy 6 (#2)" (Inneneinrichtung) runter. Natürlich in der Chipsetsrubrik von Rpg2000.de
Ihr habt sie? Gut, dann geht auf Import, und wählt das richtige Verzeichnis. Wenn ihr jetzt die Datei auswählt, werdet ihr bei der einen ein blinken des pinken Hintergrudes bemerken (=> transparente Farbe wurde schon richtig gewählt), beim anderen allerdings nicht. Deshalb müsst ihr jetzt einmal auf den hellgrünen Hintergrund im Upper-Bereich klicken, der daraufhin anfängt zu blinken, und abjetzt transparent angezeigt wird.

So, nun habt ihr auch dieses richtig SCHWERE Kapitel des makerns bewältigt ^^

So, nachdem wir uns nun mal eine kleine Auszeit genommen haben, öffnen wir mal wieder die Database. In der oberen Leiste seht ihr wahrscheinlich schon die passende Registerkarte.
Unter Terrains könnt ihr (ausnahmsweise ^^) mal die wörtliche Übersetzung des Begriffas verstehen. Terrains sind Gebiete, bzw. Landschaftstypen, die es gibt.
Auf ChipSets lässt sich dann nachher einstellen, welchen Landschaftstyp ein bestimmtes Feld hat. Wenn der Maker diesen Landschaftstyp kennt, weiß er dann nämlich auch, welcher Battlebackground verwendet werden soll, falls es auf eben diesem Feld zu einem Kampf kommt, bzw, ob eine Landung mit Luftschiff möglich ist, sowas in der Art.
Nun gut, ich hoffe, ihr habt es inzwischen geschafft, die Database zu öffnen, und auf "Terrains" zu wechseln. Links ist wieder einmal die bekannte Liste zu sehen, in der wir jetzt ein neues Terrain erstellen. Am besten gehen wir alles nocheinmal durch, und erstellen eine Canyongegend.

• Name: Moment mal...hatten wir das nicht schon?
  Da das eine Berggegend werden soll, nennen wir das Terrain am besten Canyon oder so ähnlich...


• Damage: Hier lässt sich der Schaden einstellen, der verursacht wird, wenn die Gruppe/der Held über dieses Terrain läuft. Als bestes Beispiel dafür ist wahrscheinlich standartmäßig der Sumpf zu nennen. Durch diese Funktion kann der Held seltsamerweise nicht getötet werden, dass heißt, mit einem Lebenspunkt wird dann kein Schaden mehr verursacht.
  Da man sich beim laufen auf Bergpfaden ja nicht gerade zwangsläufig verletzt, sollten wir diese Einstellung auf 0 lassen.


• Enemy Magnify: Das ist die Häufigkeit, mit der Monster in diesem Terrain auftreten. 100% ist der normale Wert, der für die Map gewählt wurde, bei 50% kommen Monster dann nur halb so häufig, wie auf anderen Terraintypen.
  Man kann die ganze Situation sehen wie man will, aber ich denke, für den Anfang sollte man auch hier einfach 100% eingestellt lassen.


• Select Battle Background: Der Hintergrund, der bei einem Kampf auf diesem Landschaftstyp angezeigt wird. Aber nur, falls bei den "Map Properties" unter "BattleBackground" "By Terrain Chip" eingestellt wurde.
  Natürlich empfiehlt sich hier besonders der Background "Canyon" der auf diesen Landschaftstyp quasi zugeschnitten ist.


• Vehicles passing principle: Hier lässt sich einstellen, mit welchen Fahrzeugen dieser Landschaftstyp befahrbar ist.


• Passable by Boat: Man kann mit dem Boot über dieses Terrain fahren.


• Passable by Ship: Man kann mit dem Schifff über dieses Terrain fahren.
  (Was genau der Unterschied ist: Im nächsten Teil)


• Passable by Airship: Man kann über dieses Terrain mit dem Luftschiff hinwegfliegen.


• Airship Landing: Man kann auf diesem Terrain mit dem Luftschiff landen.
  Natürlich sollte man im Gebirge nicht mit dem Boot, bzw. dem Schiff fahren können, deshalb lassen wir diese Funktionen deaktiviert. Ob man mit dem Luftschiff darüber fliegen kann, ist eine andere Frage. Wenn man sich Gedanken um ein komplexes spiel macht, sollte man sich überlegen, was genau das aktuelle Fluggerät kann, so sollte man eventuell zwischen Gebirge und Hochgebirge trennen.


• Common Chara..: Hier lässt sich einstellen, wie der Held dargestellt wird, wenn er auf diesem Landschaftstyp läuft. Auch hier gibt es wieder vier Auswahlmöglichkeiten.


• Normal: Die Voreinstellung, Held wird wie im Charakterset angezeigt.


• Tanslucent 1/3: Das untere Drittel des Körpers wird transparent, und man kann den Hintergrund sehen.


• Translucent 1/2: Die Hälfte wird transparent.


• Translucent whole body: Der ganze Körper ist durchsichtlich.

Vielleicht fragt ihr euch jetzt, was für einen Sinn es macht, den Körper durchsichtig werden zu lassen. Nunja, die Fälle, in denen die Hälfte, bzw. ein Drittel des Körpers verdeckt werden, eignen sich besonders, wenn der Held auf der Weltkarte durch Wälder oder Hohes Gras läuft, ganz durchsichtig, wenn er schwimmen soll.
Logischerweise lassen wir den Helden normal angezeigt werden, es sein denn, in der Berggegend muss er durch Geröll waten oder etwas derartiges.

So, das war es eigentlich auch schon wieder. Um euch etwas einzuüben, solltet ihr vielleicht noch einige zusätzliche Terrains erstellen, zum Beispiel die Stadt, das innere eines Schlosses, usw. Wenn ihr denkt, dass ihr gut vorbereitet seit, dann wechseln wir zum nächsten Punkt, und einem sehr wichtigen dazu, den Chipsets!

Sooooo, da wären wir jetzt also. Mitdenkend, wie ihr seit, habt ihr jetzt alle bestimmt schon das richtige Verzeichnis ausgewählt (für alle anderen: => Database => Chipsets)
Auf den ersten Blick könnte diese Rubrik wieder sehr verwirrend sein, wenn man mal von der bekannten, obligatorischen Auswahlliste am linken Bildschirmrand absieht. Den Großteil des bildes nimmt irgendeine Grafik (ja, es ist ein ChipSet) ein, das irgendwie zerhackt wirkt, und mit Zahlen überlegt ist. Wenn man in der Nähe dieses Feldes auf verschiedene Schaltflächen klickt, ändern sich die Zahlen zu Symbolen wie X und O, oder werden zu Pfeilen.

Um den Überblick zu bewahren, und um unsere Chipsets einzubauen (ja, die, die wir in Punkt zwei noch so kunstvoll importiert haben), erweitern wir die Auswahlliste um zwei weitere ChipSets.
Sobald wir auf das erste leere Feld klicken, wird das ganze schon etwas übersichtlicher, da sich das ChipSet Feld einfach schwarz färbt. Und sämtliche anderen Eingabefelder sind auch geleert. Dreimal dürft ihr raten, was jetzt kommt...
1..
2...
uuuuund....
3!! Jaaa, der systematische Durchlauf!

• Name: Kein Kommentar
  Für das erste Set am besten etwas wie "Stadt 01" oder so..


• Select ChipSet Graphic: Hier kann man aus der Liste der Sets im ChipSet Verzeichnis das gewünschte auswählen. Hier nehmen wir passenderweise das ChipSet "mischset3", mit dem wir unsere Stadt erstellen werden.


• LowerChip/UpperChip: Hier lässt sich zwischen den beiden Stufen des Sets wechseln. Zuerst bleiben wir im LowerChip.


• Terrain Typ: Hiermit lässt sich das Terrain für einen bestimmten Abschnitt des Chipsets bestimmen. In der Liste rechts kann man zwischen den verschiedenen Terrains wechseln, mit einem Klick auf ein bestimmtes Feld wird das Terrain dort dann auf das Ausgewählte verändert. Mit verändertem Terrain werden dann auch die unterschiedliche Eigenschaften verwendet (Battlebackground, Schaden, Gegneranzahl...)
  Zuerst lassen wir hier alles auf der Voreinstellung, da wir uns gleich noch einen kleinen Trick zu Nutze machen können.


• Passing, Blocking: Der wohl wichtigste, aber auch langwierigste Teil bei der Eingliederung eines neuen ChipSets. In dieser Rubrik lässt sich einstellen, über welche Abschnitte des chipSets man laufen darf, und über welche nicht. Zur Erläuterung: Natürlich sollte man über Wiese laufen können, aber nicht über einen Zaun. Um dieses dem Maker beizubringen nutzt man diese Funktion.
  Wie ihr sehen könnt, ist die Voreinstellung auf "O". Dieses Symbol steht dafür, dass man das Feld beliebig überqueren kann.
  Bei einem Klick auf dieses Symbol wird das "X" erscheinen. Das steht dafür, das man das Feld weder betreten, noch überqueren kann (ja, das ist ein Unterschied!).
  Noch ein Klick weiter erscheint ein Stern. Der Stern steht dafür, dass dieses spezielle Feld über einem ist. Wenn man zum Beispiel Verstrebungen in der Decke, oder Rohre darstellen will, unter denen der Held durchlaufen kann, ist dies der richtige Befehl. Vorausgesetzt, ihr klickt hier auf einem Symbol der ersten drei Reihen des ChipSet herum, dann wird bei einem erneuten Klick aus dem Stern ein Quadrat. Dieses Symbol zu erklären ist nicht ganz so einfach. Normalerweise nimmt man dieses Quadrat für Abschnitte, die einfach "Das Nichts" darstellen sollen, und meistens schwarz sind. Wenn man das Quadrat verwendet, kann der Held so zu einem kleinen Teil in dieses Feld hineingehen... Am besten probiert ihr es aus.. Tipp: Um das ChipSet realistischer, und räumlicher werden zu lassen, sollte man oft mit dem Sternsymbol arbeiten. Wenn man zum Beispiel die oberste Reihe eines Hausdaches "Over hero" einstellt, dann wird der Effekt erzeugt, der Held sei hinter dem Haus. Das gleiche lässt sich auf fast alles andere verwenden (Bäume, Laternen, ...) Nehmt euch viel Zeit für diesen Teil, da er sehr wichtig ist. Und seit vor allem später nicht enttäuscht, wenn ihr die Hälfte der Abschnitte dann doch falsch deklariert habt. Die richtige Bedeutung einiger Abschnitte wird oft erst später im Zusammenhang klar. So gut wie niemand wird es schaffen, ein Set beim ersten Versuch perfekt einzustellen, auch ich muss meistens noch bis zu 5 mal nachbessern. Wechselt außerdem in den Upper-Mode, und ändert dort auch Begehbarkeit, etc. Dann kehrt zurück.


• Pass 4 Dir.: Wenn ihr hier draufklickt, dann werdet ihr plötzlich überall Pfeile sehen. Naja, fast überall, wenn ihr euch das mal genauer anschaut, nur dort, wo ihr vorher O, bzw. Stern gewählt habt. Diese Pfeile bedeuten, in welche Richtung man das Feld verlassen kann, bzw. aus welcher Richtung man es betreten kann. Oft ist diese Funktion nicht sehr bedeuteend, da nur in wenigen Fällen die Richtungen eingeschränkt werden müssen. Ein Beispiel dafür will ich mal darstellen:
  In einem normalen Raum geht enie Treppe nach oben. Diese Treppe soll natürlich frei begehbar sein, sonst wäre das ja sinnlos. Neben der Treppe ist der normale Fußboden, den man auch betreten kann. Wer einiges Vorstellungsvermögen besitzt, weiß schon worauf ich hinaus will: Jetzt kann man einfach von irgendeinem Punkt des Fußbodes die Treppe betreten, ganz egal, ob an diesem Punkt theoretisch schon ein Meter Höhenunterschied besteht. Damit dieses verhindert wird, muss man im ChipSet den Pfeil zur jeweiligen Seite wegnehmen (oder auch zu beiden, wenn die treppe nur ein Feld breit ist) und schon ist das Problem gelöst! Derartige Problem werdet ihr öfters fiden, wenn ihr euch genauer und öfter mit ChipSets auseinandersetzen müsst. Allerdings hat das ganze auch versteckte Fallen: Wenn sich im ChipSet ein Stuhl befindet, der mit dem Rücken zur "Kamera" zeigt, liegt der Gedanke nahe, ihn einfach "Over Hero" einzustellen, und den Gang nach unten abzustellen. Das Problem: Wenn man sich nun ein Feld "unter" dem Stuhl befindet, ist der Kopf des Helden nicht zu sehen. Sowas muss man immer bedenken.
  So, auch hier solltet ihr euch genau Zeit nehmen. Wenn ihr über die einzelnen Abschnitte nachdenkt, dann wird euch auffallen, dass sich mit dieser Funktion viel am ChipSet "rumbasteln" lässt.


• Counter Attribute: Falls euch diese Schaltfläche nicht auffallen sollte, liegt es daran, dass sie sich nur im "Upper" Modus befindet. Damit lassen sich Tische, Theken oder sonstiges definieren. Der Trick: Wenn sich zwischen dir und einem Event (Verkäufer, ...) ein Feld befindet, dass mit dieser Funktion als Theke definiert wurde, dann Wird das Verkäufer-Event bei Tastendruck trotzdem ausgeführt (das gleiche lässt sich auch mit einem normalen Tisch machen, über den man die gegenüber sitzende Person anspricht.
  Normalerweise gibt es in Sets nur ein bis zwei Abschnitte, die sich hiermit verbinden lassen.


• Set to All: Diese Funktion existiert widerum nur im Lower-Modus. "Set to All" ist auch der Trick, den ich oben schonmal angesprochen habe. Wählt man das aus, und dann ein bestimmtes Terrain, dann wird das ganze ChipSet auf dieses Terrain umgestellt (und das spart WIRKLICH Klickarbeit!). Es lohnt sich auch, wenn der Großteil des Sets ein bestimmtes Terrain haben soll.
  Falls ihr es noch nicht getan habt, erstellt schnell ein Terrain "Stadt" (Ja, das sollte wirklich kein großer Aufwand sein), und setzt so das Terrain des gesamten ChipSets auf Stadt. Ob das bisher wirklich sinnvoll war, da es ja noch keine Kämpfe in der Stadt gibt, sei mal dahingestellt.


• Sea Chips Animation: Hier wird die Wasseranimation des ChipSets angezeigt. Auf manchen Innen-Chipsets wird hier nicht viel sinnvolles zu sehen sein, da Wasser ja für Häuser nicht unbedingt benötigt wird.
  Bei unserem ChipSet sollte eine schöne blaue Wasseranimation zu sehen sein *g*


• Sequence: Hier lässt sich zwischen zwei verschiedenen Animationen für das Wasser wählen, wenn man es ändert, dann wird die Ändrung im Fenster darüber gleich bemerkbar.
  Mir persönlich geäfllt 1-2-3-2 besser als 1-2-3, aber das ist wohl Geschmackssache..


• Speed: Hier kann man wählen, wie schnell die wasseranimation abgespielt werden soll. Es stehen zwei Möglichkeiten zu Verfügung.
  Naja, Die schnelle Animation gefällt mir persönlich nicht so toll.

Sooo, das wars dann erstmal. Wenn euch die Einstellungen gefallen, dann beendet die Database mit OK. Im Übersichtsfenster (unten links) wählt ihr nun die Stadt-Map mit Rechtsklick aus, und geht auf "Map Properties". Jetzt wählt ihr unter ChipSet das neu erstellte aus, und seht....DAS CHAOS.
Eure schöne Stadt ist komplett..naja..zerstört, kaum ein Chip sitzt noch am rechten Fleck. Aber es nützt alles nichts, die Spieler wollen die Standart-ChipSets einfach nicht mehr sehen. Versucht euch zu erholen, und leert am besten den Bildschirm, und fangt nocheinmal von vorne an. Nach einiger Zeit werdet ihr wahrscheinlich merken, dass das neue ChipSet einman viel besser aussieht, und auch noch viel mehr Designmöglichkeiten hat. Ließen sich mit dem Standart-ChipSet kaum ansehbare Gebäude erstellen, dann kann man jetzt wunderbare Bauwerke errichten. Auch die umgebung lässt sich viel besser designen. Lasst euch viel Zeit (Die werdet ihr bis zum nächsten Kursteil haben ^^) und spielt mit dem ChipSet herum. Vergrößert die Stadtmap, um noch mehr Detail darauf zu bringen, und ihr werdet mit der Zeit automatisch besser, denn Mapdesign will gelernt sein!
Wenn ihr für den Anfang genug habt, oder glaubt, fertig zu sein, dann testet doch einfach mal das Spiel. Ich kann euch mit einer gewissen Sicherheit garantieren, falls ihr einigermaßen viele Bauteile des Sets verwendet habt, dass es Anzeigefehler geben wird, dass der Held über Mauern oder Zäune läuft, oder vor steinernem Boden stehen bleibt. Diese Fehler bleiben nicht aus, und müssen in mühevoller Kleinarbeit in der Database behoben werden..
So weit so gut, Zeit für das zweite ChipSet, "ff6-innen". Richtet es ein, und gestaltet die restlichen Innenmaps mit diesem (Ja, ich habe in einem Satz jetzt um die halbe Stunde Arbeit zusammengefasst XDD). Vergrößern von Räumen lohnt sich, gebt Häusern Kellerräume oder höhere Stockwerke hinzu! Das Set ist unheimlich komplex, und lässt euch die Grafik von Final Fantasy 6 fast eins zu eins umsetzen.

Ich hoffe, ich konnte euch mit diesem relativ umfangreichen Kapitel das Einbauen und die verwendung von ChipSets etwas näherbringen. Alle Tricks des Mapdesigns zu erläutern hätte den Rahmen wohl unweigerlich gesprengt, außerdem ist es auch wirklich nicht sehr einfach.
Auch hier gilt: Übung macht den Meister!

Dieser Abschnitt ist für das eigentliche Spiel relativ unbedeutend und nur dafür wichtig, die Grundbegriffe Eurem Spiel anzupassen. Es ist sozusagen die Übersetzungsfunktion für alles mögliche. Wie euch bestimmt schon aufgefallen ist, muss man im Menü zwischen Equipment und Skills wählen, und im Kampf benutzt man Attack, damit der Gegner 25 damage received. Falls euer Spiel Englisch seiin soll ist das natürlich kein Problem, aber in einem deutsch-sprachigen Spiel trägt eine komplette Übersetzung natürlich auch zum "Flair" bei. Außerdem lassen sich hier gut Spezialbegriffe einbringen, falls Attack Power doch lieber "Energie" oder ähnliches heißen soll. Wie in anderen Kategorien auch gehen wir hier einfach mal alles durch. Auch wenn das ja normalerweise immer schnell vorbeigeht, könnte es dieses mal unter Umständen etwas länger dauern, so sind gleich fünf Seiten voll Eingaben auszufüllen.

• Start Battle: Wie ihr vielleicht seht, ist vor der Eingabe Box (und vor den meisten anderen auch) ein Graues Feld, in dem " (CharaName) " steht. Dabei handelt es sich immer um eine oder mehrere Variablen. "CharaName" steht sowohl für den Namen von Charakteren, als auch den von Monstern. Wenn man gegen zwei Slimes kämpft, wird also später im Kampf erscheinen: Slime erscheint (vorausgesetzt, man hat in das Feld dahinter " erscheint" eingegeben) Slime erscheint Das heisst, das man in diesem Fall das eingibt, was im Kampf dann hinter dem Monsternamen erscheint. Ein Satz wie "Vor euch erscheint ein (CharaName)" ist also NICHT möglich. Naja, die Auswahl ist natürlich immer groß, aber ich denke ein einfaches " erscheint" wird es tun. Wichtig ist, ein Leerzeichen (immer, nicht nur hier!) vor das "erscheint" zu setzen (bzw. Hinter etwas, falls man eingibt und dann eine Variable kommt), da die Eingabe sonst direkt hinter den Monsternamen gesetzt wird.


• Headstart Attack Chance: Das ist die Möglichkeit auf einen Erstschlag. Ein Erstschlag im Kampf ist sozusagen eine zusätzliche Runde, also darf die Gruppe einmal agieren, bevor die Gegner überhaupt eine Chance haben. Hier gibts auch keine Variablen zu beachten. Hier kann man seinen Ideen freien Lauf lassen (und das sollte man auch, immer das gleiche Einheitsdeutsch kann nerven!!), das heißt, alles vom einfachen "Chance auf Erstschlag" bis zum "Ihr dürft zuerst draufhauen, yeah!" ist okay.


• Escape Success: Diese Nachrichtr wird erscheinen, wenn ihr erfolgreich aus dem Kampf geflohen seit. Wie genau der Maker feststellt, ob man es schafft zu fliehen ist selbst Profis noch ein Rätsel (nein, ich bin mir sicher, das beruht auf Logik, und viele wissen wie das klappt, aber ich nicht ^^).. Vielleicht hat der AGI-WErt was damit zu tun? Keine Ahnung *ggg* Sooo..einige Vorschlaege: "Flucht gelungen", "Ihr könnt entkommen!", "Ihr flieht vor den Feinden" oder "Ihr ergreift feige die Flucht"


• Failure Escape: Ja, ihr habt es schon geraten: Das genaue Gegenteil von vorhin, das heißt, diese Nachricht wird angezeigt, wenn der Spieler es nicht geschafft habt, zu fliehen. Wenn ich anmerken darf: Die ultimative Möglichkeit auf den Seelen gequälter und verletzter Spieler herumzuhacken XDD "Ihr wurdet aufgehalten" (lahm), "Keine Chance, Eure Feigheit wurde bestraft!" (Schon vieeel besser), "Vielleicht habt Ihr beim nächsten Versuch mehr Glück" (fies) oder "Eure Gegner lassen sich nicht so leicht abhaengen."


• Victory: Die Message die kommt, wenn der Spieler es endlich geschafft hat die Gegner zu besiegen. "Kampf gewonnen", "Ihr habt es den Gegner gezeigt!", "Ihr habt Eure Feinde vernichtet!" und "Etwas weniger Abschaum auf dieser Welt!" sind sicherlich gute Möglichkeiten (Okay..das erste nicht so wirklich...He, es soll Leute geben, denen gefällt sowas)


• Annihilation: Eure Party wurde besiegt. Jetzt kommt nur noch diese Message. Sensible Programmierer werden den Spieler jetzt beruhigen, ermutigen, es nochmal zu probieren.. Andere wollen Spaß haben, und streuen noch ordentlich Salz in die Wunde, muahahahahah ^^ "Moeget Ihr beim naechsten mal mehr Glueck haben...", "Eure Party wurde besiegt...", "Das Schicksal der Welt ist besiegelt..", "Ihr wart wohl zu schlecht, um zu gewinnen.." oder "Schwaechlinge koennen nichts ausrichten!"


• Got Experience: Im grauen Kasten springt euch gleich ein neues Symbol ins Auge: (X) steht immer für eine Zahl, in diesem Fall die Erfahrung, die man erhalten hat.
  " Exp erhalten" sollte keine schlechte Wahl sein...


• Got Money: Und noch eine neue Variable: (Unit) steht für den Namen der Währung, den man weiter hinten noch ändern kann. Übrigens, hier kann man den Text eingeben, der erscheinen wird, wenn man Geld von den Gegnern bekommt. Außerdem kann man vor UND hinter die Variablen schreiben (Luxus Leute, purer Luxus!!) "Ihr habt ... gefunden"," ... gefunden!", oder vielleicht doch lieber " .... aufgehoben!"?


• Got Item: Was denkt ihr, wofür (Item Name) steht? Ja? UNGLAUBLICH, ihr habt es erraten, für den Namen des Objektes, das der Held am Ende des Kampfes vom Gegner bekommt! " erhalten!", " vom Gegner bekommen!", hmm? Hört sich doch TOLL an


• Common Attack: Die Message, die erscheint, wenn der Held/das Monster einen Angriff startet. Deshalb sind Sachen wie " stürzt sich auf die Monster" nicht besonders praktisch. " greift die Gegner an!", " stuerzt sich auf die Feinde!", " faellt ueber die Gegner her!", " stuermt auf sein Opfer zu!"


• Ally Kill (Congenial Hit): Langer Name, kurzer Sinn: Ein kritischer Treffer, von einem Partymitglied dem Gegner zugefügt. Deshalb sollte man hier schon eher etwas positives verfassen. "Zack, Bumm, Volltreffer!", "Cool, ein kritischer Schlag!", "Der hat gesessen!"


• Enemy Kill (Regretful Hit): Arf, die Übersetzung verwirrt mich jetzt aber doch ^^. Auf jeden Fall ein kritischer Treffer, der von einem Feind verursacht wurde. Ein "Juhuu, Volltreffer" wäre jetzt vielleicht weniger angebracht ^^ (Es sei denn, man WILL den Spieler quälen) "Ohoh, das hat wehgetan..", "Ahh, das war ein harter Schlag!", "Das sieht schlecht aus, Volltreffer..."


• Defense: Die Nachricht, die kommt, wenn man im Kampf "Defense" gewählt hat. " wehrt ab.", " blockt.", " verteidigt sich."


• Watch State (Enemy): Erinnert ihr euch noch an diese sinnlose Fähigkeit im Kampf, die man dem Gegner als Skill zuweisen konnte? DAS ist die passende Message dazu. " schaut sich den Kampf an..", " wartet ab und sieht zu.." ... SINNLOS!


• Strength Save (Enemy): Ja, noch einer dieser Gegner-Skills, dieses Mal "Accumulate Power", also die Ansammlung von Stärke, um in der nächsten Runde stärker draufzuhauen. " sammelt Kraft", " bereitet sich vor", " konzentriert seine Kraft"


• Burst Oneself (Enemy): Weils so schön ist: Noch ein Spruch zu einer gegnerischen Attacke, nämlich zu "Self-Annihilation". Dass heißt, dieser Text erscheint, wenn der Gegner sich selbst in die Luft sprengt. " explodiert.", " jagt sich selbst hoch.", " sprengt sich in die Luft"...


• Escape (Enemy): Diese Nachricht erscheint, wenn der Gegner vor der Heldenparty flieht. Die passende Gelegenheit, um das Selbstvertrauen des Spielers zu stäreken..oder auch nicht ^^ " flieht ängstlich", " erkennt eure Stärke und flieht." oder auch " flieht vor Eurem Mundgeruch.", " hat besseres zu tun..", " gibt sich nicht mit Schwaechlingen ab."


• Transform Enemy: Die Nachricht erscheint, wenn der Gegner transformiert, also seine Gestalt wechselt (und in den meisten Fällen auch stärker, schneller, usw. wird). " transformiert.", " wechselt seine Gestalt.", ...

Unglaublich, die erste Seite ist endlich abgeschlossen.. Jetzt nehmt die Zeit mal vier, und ihr wisst, was euch noch erwartet ^^. Wie ihr vielleicht schon seht sind wir noch immer bei den Battle Messages, also den Nachrichten, die im Kampf angezeigt werden.
• Enemy Damage Give: Schaden, der dem Gegner zugefügt wurde. Dank der unglücklichen Anordnung der Variablen und Eingabefelder lässt sich hier kein vernünftiger deutscher Satz zusammenstellen. Das einzige was man hinbekommt ist ein Satz wie Slime 20 HP verloren. He, ich kenn mich nicht aus, vielleicht gibts im japanischen ja eine Subjekt-Objekt-Prädikat Stellung, wie im Lateinischen, aber..naja, ich sollte nicht klagen. " HP verloren" ist noch einigermaßen akzeptabel..


• Enemy Damage: Nach langem Rumprobieren habe ich auch die Bedeutung dieser Funktion begriffen, denn sie ist sowohl von der gar seltsamen Betitelung, als auch von dem vorgegebenen englischen Text schwer zu entschlüsseln! Der Text, den man hier eingibt, erscheint dann, wenn der Held den Gegner zwar angreift, und auch trifft, der Gegner aber keinen Schaden erhaelt, da der Held zu schwach ist. " erhaelt leider keinen Schaden.", " wird nicht verwundet.", " bleibt unverletzt",...


• Friend Damage: Im Prinzip das gleiche wie bei Enemy Damage Give, also treten auch die gleichen sprachtechnischen Probleme auf :/ Naja, der einzige Unterschied ist jetzt, dass dies erscheint, wenn ein Mitglied dere Heldenparty verwundet wird. Auch hier ist " HP verloren..." das einzige was mir einfällt... Okay, ganz kluge Leute kommen jetzt mit " Schaden erhalten" XDD


• Friend Damage Accept: Hier wurde in der Überschrift durch das Accept wenigstens ein kleiner Hinweis auf die tiefere Bedeutung dieses Eingabefeldes gegeben. Es handelt sich hier um das gleiche wie bei diesem ominösen Enemy Damage, nur, dass es darum geht, dass das Partymitglied zu gut ist, um verwundet zu werden. "Wird zum Glück nicht verletzt.", " hält dem Angriff Stand", " bleibt unverletzt" ...


• Technical Skill Failure A: Diese Message erscheint, wenn der Charakter eine Fähigkeit einsetzen will, und diese aus irgendeinem Grund nicht ausführen kann. (Fragt mich NICHT warum, das PASSIERT einfach).. " schafft es nicht...", " ist zu schlecht...", " hat Pech gehabt.."


• Technical Skill Failure B: Das gleiche wie oben, nur dass man hier einen anderen Satz eingeben kann (erinnert ihr euch? Bei den Skills musste man auch eine Failure Message angeben, wobei drei Möglichkeiten Failure hießen. Ihr ändert gerade genau DIESE Liste!!) .... Techni--....: s.o.


• Avoid Physical Attack: Naja, auch eine "Verfehl-Meldung", allerdings wird diese angezeigt, wenn der Schlag daneben geht, dass heißt, wenn man zufällig nicht trifft, oder aber zum Beispiel im Zustand Blind ist. " weicht aus." liegt jetzt voll im Trend!


• Item Use: Naja, halt die Nachricht, die angezeigt wird, wenn der Held ein Objekt benutzt. Dank einer weiteren, fürs Deutsche ziemlich unglücklichen S-O-P Konstruktion lässt sich auch hier kein vernünftiger Satz hinbekommen. Probierts mit einem " verwendet!" oder so was ähnlichem.


• Ability Value Recovery: So richtig sicher bin ich mir hier leider nicht, ich denke, dass diese Nachricht erscheint, wenn nach einem Stärke-Entzug sie Stärke wiederhergestellt wird, oder so was in der Art.. Da ich diese Nachricht noch nie im Spiel gesehen habe, bin ich mir natürlich auch nicht besonders sicher..Vielleicht " geheilt!"...


• Ability Up: Diese Message erscheint, wenn ein bestimmter Statuswert erhöht wird, zum Beispiel durch den Zauber Attack Up, der die Angriffsstärke erhöht. " gestiegen!" sollte ausreichen..


• Ability Down: dieser Text wird angezeigt, sobald ein bestimmter Statuswert gesenkt wird, zum Besipiel durch den Zauber Attack Down... Denkt mal scharf nach..." gesunken!" vielleicht?


• Ally Ability Cost Absorption: Nunja, über diese englische Bezeichnung mag man sich streiten... Auf jeden Fall wird dieser Text angezeigt, wenn der Held dem Gegner einen bestimmten Wert entzieht. Könnt ihr euch noch an die Skills erinnern, wo wir bei "Ability Down" unter anderem die Funktion "Absorption" hatten. Bei Skills, bei denen dies aktiviert ist, wird dem Helden der wert draufgerechnet, den er dem Gegner entzogen hat. " entzogen." ist doch voooolll coooooll


• Enemy Ability Cost Absorption: Genau das gleiche wie beim vorigen Punkt, nur das dieses Mal die Messaqe eigegeben werden muss, die erscheint, sollte der Gegner einem Helden irgendetwas entziehen. s.o.


• Defense Up: Wenn man über einen Zauber (z.Bsp: Heat Barrier (gibts das???)) die Verteidigung steigert, dann erscheint diese Sondermessage.. Warum ist mir zwar nicht klar, aber das ist halt so XD
  " Vert. gestiegen", " Vert. steigt!", " Def. Up" (okay, dummes Beispiel)


• Defense Down: Kein Kommentar... Nein Okay, ich bin ja nicht so. Das erscheint, wenn die Verteidigung sinkt. " Vert. gesunken..", "Vert. sinkt!"


• Level Up: Diese Nachricht ercheint, wenn der Charakter nach einem Kampf ein Level aufsteigen sollte. Die Ausgabeform ist dann so: Herr Yx Lv. 7 -...-. Wie man diesen Satz noch fortführen will ist ein weiteres Problem ^^ " erreicht..", " Level Up!"


• Special Skill learned: Dieser Text wird angezeigt, sollte der Held im Zuge eines Levelaufstieges eine neue Technik lernen. " gelernt!", " gemeistert!", " kann jetzt benutzt werden!"

Ja, damit hätten wir sowohl die zweite Seite des Vocabularys abgeschlossen, als auch die Battle Messages. Wenn ihr auf Seite drei schaut, werdet ihr sehen, dass wir uns jetzt mit den SHops beschäftigen. Wie genau man einen Shop einbaut, wird sicherlich schon in einem der nächsten Kursteile erläutert werden! Außerdem haben wir jetzt eine enorme Arbeitserleichterung.. Okay, ICH habe sie, denn der folgende Abschnitt kommt insgesamt drei Mal. Da ist so, damit man mit unterschiedlich Sätzen unterschiedliche Shop-Besitzer simulieren kann, schließlich soll ja nicht immer überall das gleiche stehen ^^

• Choose Business: Die Nachricht, die über der Auswahl von Kaufen, Verkaufen und Verlassen steht. Sozusagen der Willkommens-Text. Da man drei Shops erstellen kann, solltet ihr unbedingt versuchen, die Verkäufer verschieden zu gestalten, also einen feundlich, den anderen gehetzt und einen neutral... "Herzlich Willkommen!", "Waehlt schnell, ich hab zu tun!", "Guten Tag", "Wie kann ich Euch helfen?", "Bitte, entscheidet Euch!!",...


• Choose Business (After Second Watching): Dieser Text erscheint da, wo gerade auch der Begrüßungstext war, wenn man einnmal in ein Menü (zum Beispiel ins Verkaufen-Menü) gegangen ist, und dann wieder herausgeht, um ein anderes Menü zu wählen. Im Klartext, der Verkäufer der freundlich ist, fragt, wie er weiterhelfen kann, der gehetzte will den Kunden eher los werden.
  "Sonst noch was?", "Noch mehr?", "Ich hab nicht ewig Zeit!", "Jetzt kommt!", "Macht schneller!", "Kauft, oder geht!!"...


• Purchase: Die Auswahlmöglichkeit ins Verkaufmenü zu gehen, die unter dem Begrüßungssatz des Shops steht. "Kaufen", "Erwerben",..(Fällt euch was besseres ein?)


• Sell: Die Aswahlmöglichkeit um ins Verkaufmenü zu kommen, steht ebenfalls unter dem Begrüßungstext. "Verkaufen"


• Leave: Die dritte Auswahlmöglichkeit, die bewirkt das man den Shop verlässt. "Verlassen", "Ende", "Raus", "Schluss", und und und...


• Buy Chosen Item: Dieser Text steht im Kauf-Menü unter den vorhandenen Artikel, während man gerade wählt, was man kaufen will (sofern man genug Geld dabei hat). "Was solls sein?", "Was??", "Was kauft Ihr?"


• Input Number of Items for Purchasing: Dieser Text teht da, wo der vorherige Text auch stand, wenn man wählt, wieviele man vom gewählten Objekt kaufen will. "Wie viele?", "Anzahl?"


• Purchasing Complete: Der Text erscheint, wenn man etwas gekauft hat. "Erledigt!", "Fertig!", "Danke!", "..."...


• Sell Chosen Item: Das ist der entsprechende Text zu "Buy Chosen Item", nr dieses Mal halt im Verkaufsmenü. "Was habt Ihr?", "Zeigt her!", "Beeilt Euch!"


• Input Number of Items for sale: Der Text wird angezeigt, wenn der Spieler wählt, wieviele Objekte einer Art er verkaufen will. "Wie viele?", "Anzahl!?"


• Sale Complete: Das wird angezigt, wenn der Verkauf abgeschlossen ist.
  "Okay..", "Danke!", "Fertig!", "Jetzt geht!"

Gut, einmal durch, das ganze müsst ihr jetzt noch zwerimal eingeben. Achtet darauf, dass ihr schön verschiedene Sätze benutzt, denn ein Spiel lebt auch von der Abwechslung! Als nächstes kommen wir dann zu den Inn Messages, auch wenn diese nicht mal eine halbeSeite umfassen. Außerdem kommen diese auch doppelt vor, das heißt dieses Kapitel ist es kaum wert, ein eigenes genannt zu werden!

• Lodging Selection: Das ist der Text, der kommt, wenn der Held ein Inn (also Hotel, Gasthof) aufruft. Er besteht aus zwei Teilen, erstmal dem oberen, in dem der Preis genannt wird, und dem unteren, in dem noch einmal ein zusätzlicher Satz kommt. "Nur ... um hier zu bleiben!", "Nur ... fuer eine Nacht!", "Zahlt ..., geniesst die Nacht", " ... pro Nacht! und "Wollt ihr uebernachten?", "Wollt ihr hierbleiben?", "Bleibt Ihr?", "Wollt Ihr ein Zimmer?"


• Lodge: Die positive Antwort auf diese Frage, also, der Entschluss, in diesem Inn zu übernachten. "Ja!", "Hier bleiben", "Okay!"


• Stay at 1 Night: Die negative Antwort (achtet gar nicht auf die Überschrift ^^) "Nein!", "Heute nicht"
  So, das ganze jetzt nochmal eingeben..Auch hier könntet ihr versuchen, das zweite Inn vom Stil her ganz anders zu gestalten, auch wenn das natürlich nicht immer so einfach ist.


• Number of Owned Items: Da verstehe einer die Anordnung der Begriffe o.O
  Auf jeden Fall wird dieser Text wieder im Shop angezeigt. Nämlich, wenn ihr zwischen den verschiedenen Items wählt, wird rechts angezeigt, wie viele dieser Art sich in eurem Besitz befinden, und das Wörtchen vor dieser Zahl gebt ihr hier ein.
  "Dabei", "Im Besitz"


• Number of Equipped Items: Wenn ihr im Shop bei den Ausrüstungsgegenständen Wählt, dann wird unter der Anzahl der Objekte im Inventar auch die Anzahl der Objekte angezeigt, die bereits ausgerüstet sind. "Ausgeruestet", "Angelegt"


• Currency Unit: Der Name der Währung in der Spielwelt. Dieser Name wird öfters angezeigt, zum Beispiel, wenn man nach einem Kampf Geld bekommt, wenn man im Shop oder im Inn ist, oder wenn man ins Menü geht. Hier könnt ihr eurer Fantasie wirklich freien Lauf lassen. Naja, einige Vorschläge kann ich ja trotzdem machen: "Gil", "GP", "Gold", "Creds"...

Unglaublich, aber wahr! Wir sind schon auf der letzten Seite der Vocabularies angekommen. Hier sind jetzt die wirklich wichtigen Begriffe untergebracht, wie die Auswahlmöglichkeiten im Menü und im Kampf, oder die elementaren Begriffe, wie die Namen der Statuswerte.

• Level: Der Begriff für die Level. HE, man kann das umbenennen, wenn man es unbedingt für nötig hält. "Level", "Stufe", "Rang"...


• Level (Abbr.): Die Abkürzung für den Begriff Level, darf Maximal 2 Zeichen enthalten. "Lv", "L.", "S.", "R."


• HP: Der Begriff für die Lebenspunkte. Da im nächsten Punkt die Abkürzug kommt, solltem an jetzt vielleicht noch eine längere Form nehmen...
  "Leben", "LebensP.", "HP" *g*
  
• HP (Abbr.): Die Abkürzung für HP (das hört sich unglaublich lächerlich an ^^)
  "HP", "H", "LP"...


• MP: Der Begriff für die Magiepunkte, oder wie man sie nennen will. Da es im Kursprojekt ja auch Kampftechnike gibt, die diese Art von Punkten verbrauchen, nenn ich sie "TechnikP."...


• MP (Abbr.): Die Akürzung für die Magie/Technikpunkte. Wie alle anderen Abbkürzungen auch, darf sie maximal aus zwei Buchstaben bestehen.
  "MP", "TP", "AP", "M"...


• Normal: Nunja... Wenn irgendwo vorher vom Maker aus Normal stand, dann steht dort jetz dieses Wort. Warum man das in einem deutschem Spiel ändern sollte, müsst ihr euch selbst überlegen.. "Normal", "Standart"...


• Exp (Abbr.): Die Abkürzung (zwei Buchstaben) für die Erfahrungspunkte..Schon seltsam, dass wir die Abkürzung eingeben dürfen, den langen Begriff aber nicht ^^ "EP", "Ex", "E."


• MP Cost: Wenn man im Menü ins Skill Menü geht, nud dort einen Auswählt, steht da ebenfalls "(MP Cost): (x)". "Kosten", "MP"


• Arms: Im Ausrüstungsmenü, der Oberbegriff für Waffen/das was man in der Hand hält. (Ich weiß ja nicht, ob man in eurem Spiel nur Waffen in der Hand halten kann...)
  "Waffen", aber auch "Arm"..


• Attack: Der NAme für den Statuswert "Attack", also den Stärkewert, aus dem unter anderem der Schaden am Gegner berechnet wird.
  "Angriff", "Staerke", "Kraft"


• Shield: Der Überbegriff für die Objektgruppe: Schilder, der dann auch im Ausrüstungsmenü angezeigt wird. Vielleicht: "Schild"?.."2. Arm"


• Defense: Der Name des Statuswertes Verteidigung, der dafür verantwortlich ist, dass der Schaden, der dem Helden vom Gegner zugefügt wurde, vermindert wird.
  "Vert.", "Def.", "Konst."


• Armor: Der Überbegriff für die Objektgruppe der Rüstungen. Wird, ihr habt es schon erraten, ebenfalls im Ausrüstungsmenü angezeigt. "Ruestung", "Koerper"


• Mind: Der Stautuswert, der bei einigen Skills (vor allem bei Zaubersprüchen) dafür sorgt, dass sich der Schaden vergrößert/verkleinert. "Geist", "ZKraft", "MagKraft...


• Helmet: Der blablabla..Helme..blablabla "Helm", "Kopf"


• Agility: Lasst euch nicht vom voreingegebenen Wort in der englischen Fassung täuschen, dieser Statuswert hat gar nichts mit dem Wort "Ability" zu tun, sondern nur mit der Geschwindigkeit. "Agilitaet", "Geschw.", "Speed" (Agility war uns zu englisch, hehe)


• Other: Das sind die nützlichen Zusatzausrüstungsgegenstände, die meistens etwas hilfreiches wie Schutz vor Gift oder sowas erreichen. "Zeugs", "Sonst.", "Acces."



Gut, diese Gruppe von Begrifen hätten wir fertig, ab zur nächsten! Bei den "Commands" dreht es sich hauptsächlich um verschiedene Auswahlmöglichkeiten im Kampf, im Menü, und zu Beginn des Spieles.



• Fight: Im Kampf, wenn man zwischen dem AktionsMenü, dem CPU-gesteuerten Kampf und der Flucht wählt, das erste.
  "Aktion", "Kampf!", "Action!"


• Auto: Die Auswahl für den computergesteuerten Kampf.
  "AutoKampf", "CPU"


• Escape: Die Auswahl Flucht, also im Kampf vor dme Gegner abzuhauen (Warum erklär ich das, holt euch ein Wörterbuch XDD)
  "Flucht", "Fliehen"
  
• Attack: Jetzt befinden wir uns im Aktionsmenü des Kampfes. Einen normalen Angriff auf den Gegner starten. "Attacke", "Angriff"


• Defense: Die Möglichkeit, sich voll auf den Angriff des Gegners vorzubereiten, und seine Verteidigung so für eine Runde zu erhöhen.
  "Vert.", "Block"


• Item: Sowohl im Kampf, als auch im Menü, wenn man ins jeweilige Untermenü wechselt.
  "Objekt", "Item"


• Skills: Der Name für das Skill-Unter-Menü im Standartmenü, und für das Skillmenü im Kampf, wenn man dem jeweiligen Helden keinen besonderen Namen für diese Auswahl zugeiesen hat (siehe: Hero) "Skills", "Techniken", "Abilities"


• Equipment: Der Name für das Ausrüstungsmenü.
  "Ausruestung"


• Save: Wenn man im Standartmenü diese Schaltfläche auswählt, erhält man die Möglichkeit, abzuspeichern, um das Spiel später, oder wenn man gestorben ist, von diesem Zeitpunkt fortzusetzen. Ob man speichern kann ist auf den "Map Properties" festgelegt, allerdings kann man das auch zusätzlich steuern.
  "Speichern", "Save"


• End Game: Die Möglichkeit, das Spiel vom Menü aus zu Beenden (ein einfaches Alt + F4 macht dies aber bedeutend schneller).
  "Beenden", "Ende"


• New Game: Im Startmenü. Die Möglichkeit, ein komplett neues Spiel zu beginnen.
  "Neu", "Beginnen"


• Continue: Ein zuvor gespeichertes Spiel laden.
  "Laden", "Fortsetzen"



Und wieder ein Teilabschnitt beendet. Nun kommen wir endlich zum letzten Abschnitt der Vocabularies, und damit auch zum Ende dieses Kapitels.

• Choose File for a Save Game: Dieser Text erscheint als Überschrift im Speichern-Menü, wenn man auswählen muss, auf welchen Spielstand man speichern will.
  "Auf welchen Spielstand wollen Sie speichern?", "Wohin soll gespeichert werden?"


• Choose File for a Load Game: Im Prinzip das gleiche, nur dass man dieses Mal den Einleitungstext des Laden-Menüs eingibt.
  "Welcher Spielstand soll geladen werden?", "Von welchem Spielstand wollen sie weiterspielen?", "Welcher darfs sein?"


• Exit Confirmation: Die obligatorische Frage, ob man sich WIRKLICH WIRKLICH sicher ist, dass man beenden will. "Wirklich beenden?", "Ist schon Schluss?"
• File: Der Name für einen Spielstand. Wenn man sein Spiel als Geschichte aufbaut, kann man den Spielstand dann schon mal "Story" nennen..
  "Spielstand", "File", "Data", "Story"


• Yes: Das deutsche Wort für Yes ist...ja, ihr habts *g*
  "Ja", "Okay"


• No: Nein
  "Nein"




Endlich haben wirs geschafft, und das wohl längste aller bisherigen Kurs-Kapitel ist beendet. Zum Vergleich: Allein dieses Kapitel hat ungefähr die Größe des gesamten letzten Kurses. Und das ist erst ein Drittel dieses Kurses. Nein, Natürlich nicht. Aller Wahrscheinlichkeit werden die beiden anderen Kapitel zusammen nicht mal solang wie das hier, dafür werdet ihr dort viel mehr lernen können, als in diesem (nicht sher sinnvollen) Kapitel.

Ich hoffe, ihr habt euch von diesen gewaltigen Textmassen einigermaßen erholt, und seit jetzt wieder aufnahmefähig!
Wechselt in der Database auf das Systemverzeichnis. Hier könnt ihr jede Menge Einstellugen am System eures RPG's vornehmen. So könnt ihr zum Beispiel die Kampfmusik, Auswahlsounds, Titelbildschirm, usw. verändern.
Am besten gehen wir auch das Systemverzeichnis mal mit System durch:

• Boat: Wenn ihr auf "Set" klickt, dann könnt ihr die Grafik des Bootes verändern. Was es genau damit auf sich hat: In einem späteren Teil. Da wir im Moment noch kein Boot benötigen, lassen wir die Grafik so.


• Ship: Wenn ihr auf "Set" klickt, dann könnt ihr die Grafik des Schiffes verändern. Okay, den Unterscheid der Vehikel erklär ich gleich... Da wir im Moment noch kein Schiff benötigen, lassen wir die Grafik so.


• Airship: Wenn ihr auf "Set" klickt, dann könnt ihr die Grafik des Luftschiffes ändern. Der unterschied der Vehikel: Wisst ihr noch, im letzten Teil, als wir die Terrains hatten. Dort gab es ja die Funktion "Passable by...", damit konnten wir einstellen, ob das Terrain z.B mit einem Boot befahrbar ist. So kann man zum Beispiel Seichtes Wasser und Tiefes Wasser definieren, wovon das erste dann mit allem befahrbar ist, das zweite aber nur von Schiff und Luftschiff überquerbar ist. Und über Gebirge kann nur das Luftschiff fliegen XDD Da wir im Moment noch kein Luftschiff benötigen, lassen wir die Grafik so.


• Title Graphic: Das wird später das Titelbild des Spieles sein, dass am Anfang erscheint, wenn man zwischen "Start", "Laden" und "Ende" wählt. Die meisten Projekte benutzen ein eigens Titelbild, dass u.a. einen Schriftzug mit dem Nameen des Spiels enthält...
  Ob wir extra fürs Kursprojekt ein Titelbild erstellen sollten bleibt in Frage gestellt.


• Game Over Graphic: Könnt ihr euchs denken? Nein?? Diese Grafik erscheint z.Bsp. wenn der Held im Kampf stirbt und das Spiel verloren ist. S.o.


• Init Party: Hier stellt man die Party ein, mit der das Spiel begonnen werden soll. Besonders praktisch: Wenn man alle Members auf None stellt, ist bei Spielbeginn kein Held zu sehen (kann man gebrauchen, wenn man ein Intro machen will, etc.) Für das Kursprojekt ist es (wenigstens bisher) angebracht, unseren selbsterstellten Hero als einziges Startmitglied der Party zu setzen.


• System BGM: Hier kann man die verscheidenen Standartmusiken auswählen, die in jeweiligen bestimmten Situationen auftreten. (Keine Angst, wenn man mehrere Battlemusics nutzen will, kann man sie auch im Spiel umstellen!)


• TitleScreen: Musik, die beim Startbildschirm ertönt.


• Battle: Musik, die im Kampf ertönt.


• Battle End: Musik, die beim Ende des Kampfes ertönt.


• Inn: Musik, die beim Schlafen im Inn ertönt.


• Boat: Musik, die beim Fahren des Bootes kommt.


• Ship: Musik, die beim Fahren des Schiffes kommt.


• Airship: Musik, die bei Fliegen des Luftschiffes ertönt.


• GameOver: Musik, die beim GameOver-Bildschirm ertönt. Welche Musiken ihr auswählt bleibt natürlich vollkommen euch überlassen. Man sollte nur darauf achten, keine fröhlichen GO-Musiken einzusetzen, etc.


• System SE: Im Prinzip das gleiche wie oben, nur dieses Mal gehts nicht um die Hintergrundmusiken, sondern um die Soundeffekte.


• Cursor Movement: Sound, der bei dem Bewegen des Cursors (in Auswahlmenüs,..) kommt.


• Decision: Sound, der bei der Auswahl einer Option ertönt.


• Cancel: Sound, der ertönt, wenn man in einem Auswahlmenü Esc (C...) drückt.


• Buzzer: Sound, der ertönt, wenn man eine inaktive Funktion auswählen will.
  
  
• Start Battle: Sound, der beim Start eines Kampfes ertönt.


• Escape: Sound, der ertönt, wenn man aus dem Kampf flieht.


• Enemy Attack: Ertönt, wenn ein Monster im Kampf angreift.


• Enemys Damage: Kommt, wenn ein Held einen Gegner trifft.


• Friends Damage: Sound, der kommt, wenn ein Held im Kampf getroffen wird.


• Evasion: Bei Fehlschlag eines Angriffs.


• Enemy Die: Tod eines Monsters.
• Item Use: Bei Benutzen eines Gegenstandes. Auch heir könnt ihr prinzipiell auswählen, was ihr wollt, allerdings sollte der Sound immer passend sein.



• Initial System Graohic: Wenn ihr hier auf Set klickt, könnt ihr das Sytemset wählen und noch zwei weitere Einstellungen vornehmen. Das Systemset ist ein wichtiger Bestandteil jedes Spieles. Das Systemset legt die Hintergründe des MEnüs und der Messages fest, die Farben der Messages und die Zehlen, die bei der TimerFunktion erscheinen (mehr dazu in "Rm2K-Kurs #78 - Jaha, ich lebe noch" XDD). Wenn ihr euch das ausgewählte Systemset anschaut, werdet ihr wahrscheinlich den grün-schwarzen Farbverlauf erkennen, der als Hintergrund jeder Message zu sehen ist. Nun zu den Einstellungen. Die erste hat den schönen Namen "Wallpaper", wobei man zwischen "Enlarge to Tile Display" und "Tile Display" wählen kann. Durch ersteres wird in Messages/etc. der Hintergrund auf die Größe des Fensters angepasst (wie im Moment eingestellt). Zweite Auswahl lässt das klaeine quadratische Kästchen immer wieder neben- und untereinander setzen. Das sieht mit dem Standartset nicht unbedingt so toll aus, ist bei anderen Sets aber ein Muss.
  Dann gäbe es da noch die Game Font. Hier könnt ihr zwischen zwei verschiedenen Schriften wählen (die sich bei mir nicht unterscheiden!!). Wenn es bei euch unterschiedliche Schriften seien sollten, dann wählt die schönere :)
  Es gibt auf rpg2000.de (und natürlich auch auf anderen Seiten) sehr viele schöne Systemsets zum Download, da sollte für jeden was dabei sein.
  
  
• Teleport Transition: Hier könnt ihr die allgemeine Anzeigeweise für Teleports auswählen. Teleports finden, wenn nicht genau bestimmt, dann immer so statt. Wählt die passenden Bildschirm Lösch (Erase) und Zeige (Show) Verfahren.


• Start Battle: Das gleiche, nur nicht zum Teleport, sondern zum Beginn eines Kampfes.


• End Battle: s.o. (Leseanleitung: Man ersetze Beginn durch Ende!)

Damit wäre nun die System Rubrik abgeschlossen. Wie ihr seht, lassen sich hier die wichtigsten Grundeinstellungen für das Spiel vornehmen. Übrigens, alle Einstellungen können im weiteren pielverlauf geändert werden, also bleibt viel Freiraum für Extras. (Zum Beispiel, dass der Spieler sich selbst ein Systemset aussucht,..)

Da isnd wir also angekommen: Im wirklich letzten Abschnitt der Database. Natürlich heißt das nicht, dass ihr jetzt nie wieder dieses Tool benutzen müsst. Wahrscheinlich müsst ihr sogar schon ziemlich bald wieder ran. Denn jedes neue Monster, jedes Item, jeder Kampf will hier eingestellt werden. Ein wichtiger Teil der Database ist auch dieser letzte hier, die Common Events. Leider werden diese oft nicht beachtet, wodurch sich manche Leute einiges komplizierter machen als notwendig.
Kommen wir nun zur Frage: was sind Common Events eigentlich?
Das ist eigentlich recht einfach zu beantworten. Common Events sind im Prinzip das gleiche wie normale (Autostart/PP-)Events, nur, dass sie von jeder Map aufgerufen werden können, bzw. auf jeder Map parallel laufen.
Das war euch zu kompliziert? Okay...
Erinnert ihr euch noch an das Parallel Process Event auf der Stadtmap, dass im Zusammenhang mit dem Schlüssel des Soldaten stand? Ihr wisst schon, dass Event, das dafür sorgte, dass der Held eine Message sagte, entweder dass der Schlüssel am jeweiligen Standort nicht zu gebrauchen war, oder dass die Tür geöffnet wurde.
Dieses Event wurde ausgelöst, sobald der Switch "schluesselbenutzt" aktiviert wurde. Falls ihr den Schlüssel aber mal auf einer anderen Map benutzen solltet (z.Bsp. in der Kampfarena), dann kam keine Nachricht.
Das können wir jetzt mit einem Common Event ändern. Dazu löschen wir aus dem besagten Event die Seite mit dem Spruch (NICHT die Seite, auf der die Tür geöffnet wird!) und gehen in die Database. Dort wählen wir in der linken Auswahlliste das erste freie Feld (also 001) aus. Rechts oben gibt es dann einige wenige Einstellungen zu machen. Die erste, Name gibt dem Event einen Namen, was vor allem später besonders wichtig ist, wenn man viele Common Events benutzt.
Event Start Condition ist die Haupteinstellung. Wenn man sie auf Call lässt, dann wird das Event nur durchgeführt, wenn man es aufruft (im Zusammenhang mit einem Speicherpunktsystem sehr nützlich!).
Die anderen beiden Einstellungen sollten euch schon von den "normalen" Events bekannt vorkommen. Bei AutoStart wird das Event automatisch durchgeführt und blockiert alle anderen Aktionen des Spiels, bei ParallelProcess laufen alle weiteren Aktionen ohne Unterbrechung durch.
Rechts kann man bei den letzteren Fällen noch einstellen, ob für das Event ein StartSwitch erforderlich ist, und wenn ja, welcher.
Wir wollen dieses Event auf AutoStart schalten und natürlich durch den Switch "schluesselbenutzt" starten lassen. Jetzt kommen wir zu etwas neuem und Unbekannten, was ich aber noch nicht erklären werde. (Ja, der nächste Teil kommt bestimmt..)
Im leeren weißen Feld unten könnt ihr, wie bei jedem Event, jetzt die bekannten "Kommandos" einsetzen. Geht nun auf Seite 3 der Liste und wählt aus der rechten Spalte Fork Conditions. Im neuen Menü aktiviert ihr "Switch", wählt den Switch "vor tuer" (oder wie ihr ihn genannt habt) und rechts daneben "OFF". Unten macht ihr noch das Häkchen vor "Add ELSE Case" weg.
Ihr solltet jetzt folgendes sehen:
<>FORK Optn:Switch (000X:vor Tuer) - OFF
<>
:END Case
So, jetzt macht ihr einen Doppelklick auf das innere "<>" und schreibt nun die Message hinein. "Hmm, hier kann ich den Schlüssel nicht benutzen" oder so ähnlich.
Danach klickt ihr widerum auf das "<>" Zeichen und wählt dieses Mal Sitch aus. Dort deaktiviert ihr den Switch "schluesselbenutz" wieder.
Damit wären wir jetzt fertig. Zu Fork Conditions sei gesagt: Das, was innerhalb der Fork steht wird in diesem Fall nur ausgeführt, wenn der Switch "vor Tuer" AUSgeschaltet ist.
So, das war eine Anwendung von Common Events. Am besten gehen wir noch eine zweite durch, die euch auch sehr interessieren sollte: Viele von euch werden sicherlich schon mal ein (Rpg-Maker-)Spiel mit einem Tag/Nacht-Zyklus gespielt haben. Dieses Feature ist nicht nur ein netter Effekt sondern auch ein Faktor, der sich sinnvoll ins Spiel einbauen lässt
=> bestimmte Leute sind nur tagsüber anzutreffen, die örtliche Bar ist nur nachts geöffnet. Soweit zur Theorie, jetzt gehts los. Nur zur Vorwarnung: Unter Umständen kann dieser Abschnitt schon ganz schön komplex werden. Also scheut euch nicht, ihn mehrmals durchzulesen und vergleicht ihn mit dem beigepacktem Kursprojekt! Als erstes fangen wir mit den Common Events an. Von diesen brauchen wir gleich 4 Stück. Das erste nennen wir "Tag/Nacht". Es wird durch den Switch "Tag/Nacht Aktiv" aufgerufen. WICHTIG: Es muss UNBEDINGT auf ParallelProcess geschaltet sein, sonst läuft nix mehr!!
Jetzt müssen wir uns überlegen, wie lange ein (Spiel-)Tag dauern soll. Am besten ist ein Wert zwischen 4 und 8 Minuten. Man sollte auf jeden Fall keine zu lange Zeit einstellen, dazu ein kleines Beispiel:
Spieler X zockt dein Game. Schon seit 5 Minuten sucht er den entscheidenen Hinweis, wo es weitergeht. Da trifft er zufällig Mann Y, der ihm sagt, dass die Lösung des Rätsels Nachts an Platz Z zu finden ist. X macht sich auf den Weg und kommt an Platz Z an, doch grade wird es hell. Dank des Tag/Nacht Zyklus, der auf 20 Minuten eingestellt ist, hat er schon nach der Hälfte der Zeit keinen Bock mehr und hört auf.
Dieses Beispiel ist keineswegs an den Haaren herbeigezogen, sondern entspricht leider oft der Realität. Also, in der Kürze liegt die Würze!
Zurück zu unserem Event. Für dieses Beispiel gehe ich von einem 4-Minuten Tag ab. Als erstes brauchen wir deshalb eine Wartefunktion. Diese findet sich unten rechts auf Seite 2 mit dem Namen "Wait..". Hier kann man die Wartezeit in Zehntelsekunden angeben. Das klingt zwar übergenau, aber ist in vielen Situation erforderlich. Ein Tag hat nach unserem System 2400 Zehntelsekunden und ein halber Tag (bis zur Dämmerung) 1200. Da die Höchsteinstellung bei "Wait" 1000 ist müssen wir erst einen 1000er und dann einen 200er Wait hinpacken. Nach dieser Wartezeit ändern wir erst mal einige Switches: "Tag" wird aus-, und "Nacht" angestellt. Natürlich soll es jetzt auch dunkel werden. Den passenden Befehl findet ihr ebenfalls auf Seite 2, dieses Mal rechts oben. Er heißt "Set Screen Tone". Hier findet ihr jetzt 4 Schieberegler, die ersten drei verändern den Anteil der Grundfarben, der letzte die Farbstärke.
Beispiel: Wenn ihr Blau und Grün runterschraubt bekommt das gesamte Bild einen Rotstich, das ist praktisch um die Illusion eines Alarmes oder eines besonders heißen Raumes entstehen zu lassen.
Stellt am besten alle Regler auf 70. Unten könnt ihr bei Time nochmal in Zehntelsekunden einstellen, wie lange die Verdunkelung des Bildschirms dauern soll. 10 Sekunden (100 Zehntel) sind eine angebrachte Zeit, meiner Meinung nach. Bei "Wait Until Done" könnt ihr einstellen, dass das Spiel erst dann fortfahren soll, wenn die Verdunkelung abgesclossen ist. Bitte DEaktivieren!
So, der Übergang zur Nacht wäre getan, jetzt das ganze noch einmal umgekehrt. Dazu erstellen wir erst einmal das nächste Even, dass wir "Nacht/Tag" nennen. Dieses soll durch den Switch "Nacht/Tag Aktiv" gestartet werden. Im Prinzip ist alles identisch, nur dass der Switch "Nacht" aus, der Switch "Tag" angeschaltet und bei den Farbeinstellungen wieder alles auf 100 gesetzt wird. So, nun müssen wir an den beiden Events noch etwas ändern. Also rufen wir wieder das erste auf. Unter den bisherigen Befehlen machen wir weiter. Zuerst wird der Switch "Nacht/Tag Aktiv" auf ON gestellt, danach der Switch "Tag/Nacht Aktiv" auf OFF. Beim zweiten Event verfahren wir umgekehrt.
Das hat einen einfachen Effekt.
Tag/Nacht startet
120 Sekunden Wartezeit
Bildschirm wird dunkel
Tag/Nacht wird beendet
Nacht/Tag startet
120 Sekunden Wartezeit
Bildschirm wird hell
Nacht/Tag wird beendet
Tag/Nacht startet
usw..
Also: Event 1 läuft ab, danach läuft Event 2 ab, dann wieder Event 1, ...
Nun gut, diese Events bewirken also, dass der Bildschirm nach je zwei Minuten hell, bzw. dunkel wird. Also, sobald wir sie richtig ins Game einbauen. Da gibts nur ein Problem: Das wollen wir gar nicht!
Ja, ihr habt mich richtig verstanden. Wir wollen keinen Tag Nach Zyklus, bei dem es ständig dunkel oder hell wird. Denn wenn der Held in Häudern ist, soll das System zwar weiterlaufen, aber es soll nicht einfach hell oder dunkel werden, schließlich sind Häuser beleuchtet!
Also brauchen wir zwei weitere Items, in denen der Zyklus zwar auch läuft, aber keine Auswirkungen auf die Helligkeit hat.
Das erste nennen wir "Tag/Nacht invsbl." und lassen es durch den gleichnamigen Switch aktivieren. Inhaltlich ist es ziemlich identisch zu "Tag/Nacht", nur dass der Set Screen Tone Befehl fehlt, und die beiden Switches am Ende durch die entsprechenden "invsbl.-"Switches ersetzt werden müssen (ich hoffe ihr kommt noch mit).
Auf die gleiche Weise verfahrt ihr mit dem "Nacht/Tag invsbl." Event.
Okay, ich denke, dass war jetzt etwas viel auf einmal (belehrt mich eines besseren!), deshalb jetzt alle Events noch einmal:
Name: Tag/Nacht Event S.C.: Parallel Process Appearance C.S.: 00YY: Tag/Nacht Aktiv

<>Wait: 100.0s.
<>Wait: 20.0s
<>Change Switch:[00XX:Tag]-OFF Set
<>Change Switch:[00XY:Nacht]-ON Set
<>Set Screen Tone:(R070,G070,B070,S070),10.0sec
<>Change Switch:[00YX:Nacht/Tag Aktiv]-ON Set
<>Change Switch:[00YY:Tag/Nacht Aktiv]-OFF Set
<>


Name: Nacht/Tag Event S.C.: Parallel Process Appearance C.S.: 00YX: Nacht/Tag Aktiv

<>Wait: 100.0s.
<>Wait: 20.0s
<>Change Switch:[00XY:Nacht]-OFF Set
<>Change Switch:[00XX:Tag]-ON Set
<>Set Screen Tone:(R100,G100,B100,S100),10.0sec
<>Change Switch:[00YY:Tag/Nacht Aktiv]-ON Set
<>Change Switch:[00YX:Nacht/Tag Aktiv]-OFF Set
<>

Name: Tag/Nacht invsbl. Event S.C.: Parallel Process Appearance C.S.: 00XZ: Tag/Nacht invsbl.

<>Wait: 100.0s.
<>Wait: 20.0s
<>Change Switch:[00XX:Tag]-OFF Set
<>Change Switch:[00XY:Nacht]-ON Set
<>Change Switch:[00YZ:Nacht/Tag invsbl.]-ON Set
<>Change Switch:[00XZ:Tag/Nacht invsbl.]-OFF Set
<>

Name: Nacht/Tag invsbl. Event S.C.: Parallel Process Appearance C.S.: 00YZ: Nacht/Tag invsbl.

<>Wait: 100.0s.
<>Wait: 20.0s
<>Change Switch:[00XY:Nacht]-OFF Set
<>Change Switch:[00XX:Tag]-ON Set
<>Change Switch:[00XZ:Tag/Nacht invsbl.]-ON Set
<>Change Switch:[00YZ:Nacht/Tag invsbl.]-OFF Set
<>

So, ich hoffe diese Auflistung hilft euch weiter, falls ihr vorhin bei meinen kryptischen Beschreibungen den Überblick verloren habt. Wie ihr seht steht jetzt alo der Zyklus, nun muss er nur noch ins Spiel eingebunden werden. Das erfordert einige Arbeit, auch wenn sie sich noch in Grenzen hält. Auch jetzt kann ich nur empfehlen, aufmerksam zu lesen, denn einfacher wirds nicht!

Zuerst einmal müssen wir ein Event auf der ersten spielbaren Map machen (Das heißt, wenn wir später nochmal Intros behandeln nicht in der Intro Map, sondern auf unserer StadtMap!).
Auf der ersten Seite dieses Events schalten wir die Switches "Tag", "Tag/Nacht Aktiv" und "DaySet" ein. Das Event steht auf AutoStart. Seite 2 aktivieren wir mit dem Switch "DaySet" und schalten auf Push Key...
Durch die ersten Events wird einmal dem Programm gesagt, dass es Tag ist, außerdem wird der Tag/Nacht Zyklus gestartet, d.h. in 2 Minuten wird das Spiel dunkel. Der Switch DaySet ist nur dafür da, dass diese Seite nur ein einziges Mal aufgerufen wird und nicht immer und immer wieder. Solche Switches werden noch oft gebraucht!
Danach erstellen wir noch ein zweites Event.
Seite 1 wird aktiviert wenn der Switch "Tag" und der Switch "Zyklus start" aktiviert sind, Seite 2 bei "Nacht" und "Zyklus Start". Seite 1 aktiviert "Tag/Nacht Aktiv" und Seite 2 "Nacht/Tag aktiv". Auf beiden Seiten wird danach "Zyklus Start" ausgeschaltet.
Beide Seiten stehen auf Parallel Process!
Jetzt wenden wir uns allen Türen zu. Zwischen Teleport und Show Screen kommen jetzt folgende Kommandos:

Switch Tag/Nacht Aktiv aus
Switch Nacht/Tag Aktiv aus
Switch Zyklus Start an
Screen Tone auf 100, 100, 100, 100 (0 Sekunden Übergangszeit!)

Wichtig ist, dass dies bei wirklich allen Türen passiert. Nun wenden wir uns den einzelnen Häusern zu. Zuerst kopieren wir das zweite Event (Rechtsklick, Copy), wechseln auf die Kampfarena und fügen es dort an eine beliebige Stelle ein (Rechtsklick, Paste). Jetzt ersetzen wir den Switch "Tag/Ncht Aktiv" durch "Tag/Nacht invsbl." und auf Seite 2 den Switch "Nacht/Tag Aktiv" durch "Nacht/Tag invsbl".
Dieses Event wir erneut kopiert und in den beiden anderen Häusern eingefügt. Nun müssen wir bei allen Türen zwischen Teleport und Show Screen folgendes setzen:

Switch Tag/Nacht invsbl. aus
Switch Nacht/Tag invsbl. aus
Switch Zyklus Start an

Den Set Screen Tone müssen wir dieses Mal ins 2. Stadt Event packen. Also, zurück auf die Stadt Map, und Event öffnen. Auf Seite eins macht ihr die "normalen" Einstellungen, auf Seite 2 die dunklen (70, 70, 70, 70!). Wichtig ist, dass ihr auch hier die Übergangszeit auf 0 setzt!
So, macht diesen Vorgang (mit den Switches) auch bei allen anderen Ausgängen aus den Häusern. Wenn ihr jetzt testet werdet ihr vielleicht einen unangenehmen Effekt beobachten: Wenn ihr nachts ein Haus verlasst ist für einen kurzen Moment die Stadt hell, bevor der Bildschirm dunkle wird. Dies kann man dadurch verhindern, dass man bei den Teleports aus den Häusern RAUS das Show Screen wegnimmt. Dieses packen wir dann ans Ende der beiden Seiten unseres Stadt Events.

Damit wären wir fertig. Dieser Tag/Nacht Zyklus ist jetzt universell einsetzbar, man muss nur immer darauf achten, dass man die richtigen Events benutzt!
Eins möchte ich noh hinzufügen: Dieser Zyklus ist nicht besonders gut, aber wahrscheinlich das beste, was man aus den bisherigen Kenntnissen herausholen kann.

A - was'n das?
Zu aller erst: Dieses Kapitel wird vom Aufbau sicherlich etwas an Seijuros geniales Tutorial zum gleichen Thema erinnern. Allerdings ist der komplette Text hier von mir selbst geschrieben, also trotzdem lesen! ^^

Mit Variablen hatte höchstwahrscheinlich jeder von euch schon einmal (z.B. in der Schule) zu tun. Meistens werden Variablen in Zusammenhang mit der Mathematik gebraucht (Löse nach x auf, x², etc.). Daher sollten die meisten das schon wissen: Jede Variable steht für einen Wert. So kann man zum Beispiel sagen, dass X für die Zahl 5 steht.
So könnte man zum Beispiel jemanden im Maker sagen lassen: "Du hast X Äpfel gesammelt!". Das praktische daran ist, dass man nicht für jede Apfelzahl eine einzelne Message schreiben muss, sondern direkt einen allgemeingültigen Text für jeden X Wet hat.
Variablen sind auch für andere Dinge im Zusammenhang mit einem Kampfsystem etc. wichtig. So lassen sich die HP des Helden in einer Variable speichern und so weiter..

B - und wozu das alles??
Für einfach ALLES: Kampfsystem, (Zusatz)menüs, Minigames, Rätsel, Anzeigen von Pictures, ...
So gut wie jedes Script oder Tutorial verwendet Variablen, unter anderem auch das "professionelle" Tag/Nacht-System, das am Ende dieses Kursteils erklärt werden wird.

C - gehts hier mal los?
Ja.

C - Die einzelnen Funktionen
Da wir gerade die stinklangweiligen "Was bewirkt Feld XYZ"-Textmassen der Database hinter uns haben...
..machen wir genau das gleiche bei den Variablen! Juhuuuuu! Nun gut, vielleicht kann ichs ja etwas informativer gestalten..

One: Läuft genau wie bei den Switches. Hier wählt man die eine Variable aus, deren Wert verändert werden soll. Aus der altbekannten Auswahlliste lässt sich hier die gewünschte Variable auswählen, die maximale Anzahl an Variablen lässt sich durch "Max. Field Nr." verändern.

Range: Auch das kennt ihr vielleicht noch von den Switches. Hiermit lässt sich gleich ein ganzer Bereich von Variablen (dieser geht von der Variable aus dem ersten bis zu der aus dem zweiten Feld) verändern. So lassen sich nach einem Minigame zum Beispiel alle zugehörigen Variablen wieder auf 0 zurücksetzen.

Variab: Diese Funktion ist für Anfänger vielleicht nicht so interessant, aber für anspruchsvollere Funktionen (gibt bestimmt auch einfache Anwendungsmöglichkeiten) sehr nützlich. Hier wird nicht die Variable verändert, die man auswählt, sondern die Variable mit der Nummer, die dem Wert der Variable entspricht. Zu kompliziert?
Beispiel: Ihr wählt in diesem Feld Variable Nr. 10 aus. Der Wert dieser Variable wurde vorher auf 15 gesetzt. Nun wird Dank dieser Funktion Variable Nr. 15 verändert.

Das sind die drei Möglichkeiten zur Bestimmung der zu verändernden Variable(n). Als nächstes kann man die Rechenart auswählen.

Set: Die Variable wird auf einen bestimmten Wert gesetzt. Es ist völlig egal, ob ihr voriger Wert 0, 22, 3467 oder -12 war.

+: No Comment (Falls ihr das nicht versteht: Wir empfehlen den Maker grundsätzlich nicht für Kinder unterhalb des Grundschulalters.)

-, *, /: s.o.

Mod: Jaaa, das ist spannend, das ist nicht mal Grundwissen (außer wenn ihr Mathe/Informatik habt). Mit Mod wird der Rest der Ganzzahldivision ausgegeben, soll heißen: 43 Mod 7 = 1! Nicht verstanden?
Bei der Division von 43 mit 7 kommt 6 heraus mit dem Rest 1. Dieser Rest wird durch die Mod-Funktion ausgegeben.
Diese Funktion ist besonders praktisch um an einzelne Stellen einer Zahl heranzukommen. So wird bei 1234 Mod 10 die Zahl 4 ausgegeben. Teilen wir 1234 durch 10 erhalten wir beim Maker 123. 123 Mod 10 ist 3. 12 Mod 10 ist 2. So kann man zum Beispiel eine Zahl in die einzelnen Stellen zerlegen. (Was ihr wiederrum sehr praktisch finden werdet, solltet ihr euch jemals an ein eigenes Kampfsystem heranwagen.)

Die einzelnen Rechenarten haben wir nun schnell hinter uns gebracht, kommen wir zum Hauptteil. Hier wird festgelegt, auf welchen Wert die Variable gesetzt, bzw. welcher Wert hinzugefügt oder abgezogen werden soll.

Set: Hier wird die Variable auf den Wert gesetzt, den ihr auswählt (bzw. mit diesem Wert multipliziert, addiert,...). Diese Funktion ist eigentlich die Standartfunktion von Variablen, bzw. die am häufigsten verwendete.

Variable: Hier wird die Variable auf den Wert einer anderen Variablen gesetzt nämlich auf den Wert derer, die ihr auswählt.
Beispiel: Ihr habt die Variable "Held-HP", und die Variable "Held-Max-HP". Nun geht ihr zu irgendeinem Event bei dem Ihr voll geheilt werdet. Da macht ihr dann im Event die Funktion: Variable 0001: Held-HP, Set, Variable 0002: Held-Max-HP. Dadurch wird die aktuelle HP auf die maximale HP gesetzt.

Variable (No.): Diese Funktion ist ähnlich der oberen, wo man die Variable auswählte. Denn dieses Mal wird die aktuelle Variable nicht auf den Wert der hier gewählten gesetzt, sondern auf den Wert der Variable deren Nummer der hier gewählten entspricht.
Bsp: Ihr wählt hier Variable 5. Diese Variable hat den Wert 27. Und Variable Nummer 27 hat den Wert 321. Dann wird die oben gewählte Variable auf 321 gesetzt (bzw. dazu addiert, multipliziert, ...)

Rand.: Dieses Mal geht es um eine Zufallszahl, die zwischen der ersten und der zweiten eingabe liegt.
Beispiel: Wenn ihr ins erste Feld 7 und ins zweite Feld 15 eingebt, dann kann eure Variable auf 7, 8, 9, 10, 11, 12, 13, 14 und 15 gesetzt werden.

Item: Eine sehr praktische Funktion. In der erste Spalte wählt man ein beliebiges Objekt aus, in der zweiten Spalte kann man zwischen "Owned No." und "Equipped No." unterscheiden. Hierbei wird die Variable entweder auf die Zahl gesetzt, die der Anzahl der jeweiligen Items, die der Held mit sich rumträgt, entspricht (Owned), oder auf die Anzahl der jeweiligen Items, die die Gruppenmitglieder ausgerüstet haben. So kann man dann in einer Message anzeigen lassen: "Ahh, wie ich sehe habt ihr nur (Variable) Tränke!"

Hero: In der ersten Spalte wählt man einen Helden aus, in der zweiten einen bestimmten (Status)Wert, der mit diesem Helden zusammenängt. Auf diesen Wert wird dann jeweils die Variable gesetzt.

Gut, von einem wichtigen Aspekt der Rpg-Maker Programmierung direkt zum nächsten, nämlich den Fork Conditions. Auch hier werden diejenigen von euch, die in der Schule schonmal Mathe/Info hatten oder sich in ihrer Freizeit mit Programmierung beschaffen, einen Vorteil haben. Es handelt sich um die "Wenn.. dann.." Funktion, in den meisten Programmiersprachen "IF...THEN".
Dabei wird ein bestimmtes Ereignis erstellt, dass allerdings nur eintritt, wenn eine bestimmte Bedingung erfüllt ist. Eigentlich kommen Forks schon in der linken Leiste mit den Start-Bedingungen vor. Dort hat man zwar keine besonders große Auswahl, aber man kann einstellen, dass die bestimmte Seite nur dann aufgerufen wird, wenn eine bestimmte Bedingung erfüllt wird, zum Beispiel, dass ein bestimmter Switch eingeschaltet ist, oder dass eine Variable einen besonderen Wert hat, etc.
Eine Fork Condition ist aber eine Funktion wie jede andere, dass heißt, sie wird innerhalb der Seite verwendet, um zum Beispiel in einem längeren Gespräch einen Satz anzeigen zu lassen, der entweder den Helden für eine getane Arbeit lobt, oder ihn daran erinnert, diese noch zu erledigen. Natürlich könnte man sowas auch noch mit mehreren Seiten regeln, was allerdings nachher ziemlich unübersichtlich wäre.

Am besten schauen wir uns nun einmal die verschiedenen Funktionen von "Fork Conditions" etwas genauer an. Übrigens, den Befehl findet ihr rechts auf der dritten Seite in der Event-Auswahlliste.

Wie ihr sehen könnt, ist der Auswahlbereich der verschiedenen Forks in 2 Seiten aufgeteilt. Wir beginnen natürlich auf der ersten.

Switch: Hier lässt sich natürlich als Bedingung eistellen, dass der jeweilige Switch aus oder angeschaltet ist.

Variable: Und sofort tauchen sie wieder auf, unsere lieben Variablen ^^. Hier lässt sich als Bedingung einiges einstellen. Die bestimmte Variable muss entweder gleich (same), ungleich (others), größer (bigger), kleiner (smaller), größer gleich (above) oder kleiner gleich (below) einem bestimmten Wert (Set XXX) oder einer bestimmten Variable (Variable XXX) sein. Das heißt, hier lässt sich zum Beispiel als Bedingung einstellen, dass Variable X kleiner sein muss als 12, oder dass Variable Y nicht gleich Variable Z sein darf.

Timer: Auch wenn wir die Timerfunktion bisher noch nicht besprochen haben, lasst mich soviel sagen. Man kann einen Timer auf einen bestimmten Wert setzen, und zum Beispiel als Countdown bis zur Zerstörung eines Hauses oder so laufen lassen. Hier kann man nun als Bedingung einstellen, dass der Wert des Timer größer oder kleiner gleich X Minuten und Y Sekunden sein muss. Zum Beispiel könnte man den Helden sagen lassen "Ohoh, jetzt müssen wir uns beeilen!", wenn er nur noch eine Minute oder weniger Zeit hat.

Money: Hier lässt sich überprüfen, ob das Gold der Gruppe/des Helden größer oder kleiner ist, als ein bestimmter Wert. So kann man Verkäufer darauf hinweisen lassen, dass der Held wiederkommen soll, wenn er mehr Geld debi hat, etc.

Nun wechseln wir auf Seite 2 der Auswahlliste.

Item: Hat der Held ein bestimmtes Item dabei (has it), oder hat er es nicht (doesn't have it)?

Hero: Zuerst lässt sich hier der Name des Helden auswählen, der die Grundlage der Bedingung sein soll. Mit einem Doppelklick auf das Feld darunter (oder mit einem einfachen Klick auf das "...") lässt sich ein weiteres Fenster öffnen, in dem man nun die Bedingung wählt.

So, weiter gehts zu noch einer wichtigen Funktion des Makers, die einzigen Unterschiede dieses Mal sind, dass sie weder besonders kompliziert ist, noch besonders umfangreich, noch, dass es viel über sie zu erzählen gibt.
Show Choice ist eine Auswahlfunktion. So kann man nach einem Gespräch fragen, ob der Spieler alles verstanden hat und wenn er mit Nein antwortet, die wichtigen Fakten noch einmal aufzählen lassen.
Man kann ebenso den Spieler vor die Wahl stellen, welchen von drei Orten er zuerst besuchen möchte, usw.
Dem Spieler die Wahl zu lassen ist oft ein entscheidender Faktor für ein Spiel. Wenn zuviel ohne Einfluss des Spielers geschieht, wird dieser dann oft nur noch zum Zuschauer eines interaktiven Spielfilmes, in dem er ab unz zu Kampfkommandos geben darf.
Wenn man den Spieler stärkeren Einfluss gewähren will, wäre eine Möglichkeit, die Dialoge des Spieles im Multiple-Choice Verfahren zu gestalten, wie es oft in Adventures benutzt wird. Dass heißt, der Spieler wählt selbst aus, was der Held sagen soll.

Man kann den Spieler maximal zwischen 4 Möglichkeiten wählen lassen, will man weniger haben, dann einfach das ungewünschte Feld freilassen. (Wenn man aber das dritte freilässt und etwas ins vierte Feld schreibt, wird das dritte Feld auch als Auswahl gelten). Auf der rechten Seite kann man aus einer Liste von Möglichkeiten unter der Überschrift "Cancel Case" wählen.

Dieser Fall tritte ein, wenn man bei einer Auswahl im Spiel die Escape-Taste drückt. Die Standarteinstellung ist auf "Choose 2", was daran liegt, dass oft Fragen der Art ja oder nein gestellt werden. Wenn man dann abbricht, wird "Nein" gewählt.
Ignore bewirkt, dass beim Druck der Abbrechen-Taste nichts passiert, bei Add Case wird ein weiterer Fall hinzugefügt.

Mit den verschiedenen Fällen ist es wie bei den Fork Conditions. Das, was nach der jeweiligen Auswahl passieren soll, muss immer zwischen das XYZ - Case und das entsprechende END Case gestellt werden. Was hinter das letzte End Case gestellt wird, passiert dann wieder in jedem Fall.
Nun ist es an der Zeit, einige Choices in das Kursprojekt einzubauen, um das ganze zu testen. Zu aller erst nehmen wir uns den Betrüger aus dem letzten Kapitel vor, schließlich soll man als Spieler ja auch die Chance haben, nicht auf ihn hereinzufallen, selbst wenn man genug Geld hat. Deshalb packen wir an eine passende Stelle die Choice, ob der Held das Angebot des Betrügers annehmen will. In den "Ja"-Case packen wir dann alle folgenden Aktionen, in den Nein-Case eine Message der Art: "Kommtwieder, wenn Ihr es Euch anders überlegt habt!"

Ähnliche Fragen könnt ihr in viele Dialoge usw. einbauen!

Gut, angekommen im letzten Abschnitt dieses sechsten Kursteiles, angekommen bei der weitaus besseren Variante des Tag/Nacht - Zyklusses. Wenn irh euch erinnert, der Zyklus, den wir im letzten Kursteil hatten, war nicht besonders gut. So fing jedesmal, wenn man in einen neuen Raum kam, der Zähler wieder von vorne an. Das lässt sich mit Hilfe von Variablen viel einfacher, übersichtlicher und besser gestalten!

Das erste, was nun geschehen muss, ist, alles wieder auf den Ausgangsstatus zurück zu bringen. Alle Events, die nur mit dem Tag/Nacht Zyklus zu tun haben, werden gelöscht, in alle Teleports werden die Veränderungen der Switches rausgenommen, und die Teleports selber werden wieder auf die Erase Screen - Teleport - Show Screen Form gebracht, auch die, die aus den Häusern hinaus führen. Wenn man jetzt testet, sollte alles wieder normal und ohne Tag/Nacht Zyklus laufen.

Als nächstes öffnen wir die Database und gehen in den Common Events Bereich. Es bleibt euch überlassen, ob ihr die Alten Tag/Nacht Events lassen wollt, oder nicht. Auf jeden Fall kommt jetzt direkt der erste große Vorteil: Dank der neu gelernten Fork Conditions-Funktion brauchen wir jetzt nicht mehr 4 sondern nur noch EIN Event. Diese stellt ihr auf Parallel Process, ohne Startswitch.

Wir beginnen mit einer ForkCondition, die überprüft, ob der Switch ZyjklusStop AUSgeschaltet ist. Man brauch hier keinen ELSE Case hinzuzufügen. Diesen Switch kann man dann im Spiel aktivieren, wenn man möchte, dss die Zeit angehalten wird, zum Beispiel in Zwischensequenzen/etc. Innerhalb dieser Fork beginnen wir mit einer weiteren Fork, die überprüft, ob die Variable Uhrzeit über 240 sein sollte. Ist dies der Fall, dann kommt ein Goto Label 2. Anschließend folgt die Cycle Funktion. Wenn ihr diese auf Seite 3 der Events aktiviert, seht ihr wieder ein Geblide, ähnlich dem von Forks oder Choices, nur dass es hier nicht mehrere Felder gibt. Cycle steht für eine Schleife, dass heißt, immer wenn alle Befehle innerhalb des Cycles ausgeführt worden sind, springt der Maker wieder zurück zum Anfang des Cycles, also geht das im Proinzip endlos so weiter. Innerhalb der Schleife beginnen wir mit einem Wait von einer Sekunde (bzw. 10 * 0,1 Sec). Danach erhöhen wir die Variable Uhrzeit um 1. Das hat den Effekt, dass jede Sekunde einzeln gewertet wird, und nicht wie im alten Entwurf die gesamte Zeitspanne als ganzes. Dann kommt die Fork, die überprüft, ob inzwischen der Switch "Zyklus Stop" angeschaltet wurde. Sollte das der Fall sein, dann geht der Maker zu Label 1, dieses setzt ihr nach ganz unten im Common Event. Danach kommt eine Fork (wir befinden uns immer noch im Cycle!), die als Bedingung hat, dass der Wert der Uhrzeit-Variable auf 240 steht (Wenn ihr nicht 4 Minuten für einen halben Tag haben wollt, stellt hir einen anderen Wert ein!). Wenn das der Fall ist, kommt gleich die nächste Fork, die überprüft, ob der Switch T/N unsichtbar AUS ist. In Gebäuden ist dieser Switch dann angeschaltet, dass heißt, es macht sich keine Veränderung der Helligkeit bemerkbar. Wenn der Switch nun aber aus ist, wird der Screen Tone auf 70/70/70/100 (stellt es nach euren Wünschen ein) gesetzt. In diese Fork kommt sonst nichts weiteres, aber in die Übergeordnete (mit der Bedingung, dass Uhrzeit = 240 ist) kommt als nächstes ein Break Cycle. Dieser Befehl lässt den Cycle beenden und den Maker hinter diesen springen. Ein weiterer Befehl kommt nicht herein. Hinter den Cycle setzen wir das Label Nr. 2.

Zum Überblick, was ist bisher passiert?
Das Event wird automatisch zu Beginn des Spieles aufgerufen (sollte nicht gerade der Switch "ZyklusStop" eingeschaltet sein...) . Dann wird überprüft, ob es nicht schon Nacht ist (Variable Uhrzeit > 240), wenn dies der Fall ist geht es hinter dem ersten Cacle weiter. In diesem wird 4 Minuten lang eine Variable erhöht und zwischendurch immer überprüft, ob der Zyklus nicht gestoppt werden muss. Dann wird, falls sich der Held unter freiem Himmel befindet der Bildschirm verdunkelt, aber auf jeden Fall der Cycle unterbrochen. Also läuft hier der Tag ab, kann aber jederzeit angehalten werden (die bisherige Uhrzeit bleibt allerdings in der Variable gespeichert!).

Nach dem Label Nr. 2 folgt ein weiterer Cycle. Kopiert dazu den oberen samt Inhalt und fügt ihn hier ein. Das einzige, was jetzt noch verändert werden muss ist
1. Die Fork, die überprüft, ob die Variable Uhrzeit den Wert 240 hat, muss überprüfen, ob die Variable den Wert 480 hat.
2. Der Screen Tone muss auf 100/100/100/100 gesetzt werden.
Unter diesem Cycle setzt ihr die Variable "Uhrzeit" wieder auf 0.

Das wars fürs Common Event, aber für die, denen das jetzt zu viel Text und ein zu verschachtelter Aufbau war, will ich das fertige Event noch einmal wiedergeben:

<> FORK Optn:Switch[00XY:ZyklusStop] - OFF
 <> FORK Optn:Varbl[000X:Uhrzeit]-240 abov
  <>GOTO Label: 2No
  <>
 :END Case
 <>CYCLE
  <>Wait: 1.0s
  <>Variable Ch:[000X:Uhrzeit]+ , 1
  <>FORK Optn:Switch[00XY:ZyklusStop] - ON
   <>GOTO Label: 1No
   <>
  :END Case
  <>FORK Optn:Varbl[000X:Uhrzeit]-240
   <>FORK Optn:Switch[00YZ:T/N unsichtbar] - OFF
    <>Set Screen Tone:(R070,G070,B070,S100),5.0 sec
    <>
   :END Case
   <>BREAK Cycle
   <>
  :END Case
  <>
 :END Cycle
 <>LABEL: 2No
 <>CYCLE
  <>Wait: 1.0s
  <>Variable Ch:[000X:Uhrzeit]+ , 1
  <>FORK Optn:Switch[00XY:ZyklusStop] - ON
   <>GOTO Label: 1No
   <>
  :END Case
  <>FORK Optn:Varbl[000X:Uhrzeit]-480
   <>FORK Optn:Switch[00YZ:T/N unsichtbar] - OFF
    <>Set Screen Tone:(R100,G100,B100,S100),5.0 sec
    <>
   :END Case
   <>BREAK Cycle
   <>
  :END Case
  <>
 :END Cycle
 Variable Ch[000X:Uhrzeit]Set, 0
 <>
:END Case
<>LABEL: 1No
<>


Das ist das komplette Common Event, das jetzt die vorigen (unübersichtlichen) VIER anderen Common Events ersetzt.
Allein reicht leider auch dieses Event nicht, ein bisschen muss noch per Hand gearbeitet werden. Bei jedem Teleport von der Stadt Map (bzw. von einer Map, auf der der Zyklus zu sehen ist) auf eine Map, wo der Zyklus nicht zu sehen ist, müssen zwischen dem Teleport und dem Show Screen einmal der Switch "T/N unsichtbar" eingeschaltet, und der Screen Tone auf 100/100/100/100 gesetzt werden. wichtig dabei ist, dass man bei der Zeit zur Umstellung der Helligkeit nbedingt 0 eingibt, und Wait until Done, sonst sieht man bei Nacht das Innere des Hauses zuerst dunkel.
Bei jedem Teleport von einer Innen auf ein Außenmap muss der Switch wieder ausgeschaltet werden, außerdem muss der Screen Tone wieder auf Nacht gesetzt werden, wenn denn die Uhrzeit bei mehr als 240 liegt (Jap, da muss eine Fork hin!). Mehr gibt es nicht zu machen, keine zusätzlichen Events oder sonstwas.

Nun muss halt nur immer noch daran gedacht werden, bei jedem Teleport die jeweiligen Funktionen einzugeben und den Zyklus anzuhalten, wenn nötig: Übrigens, wenn ihr jetzt im Spiel einen Zeitsprung haben wollt, einfach nur der Uhrzeit-Variable den bestimmten Wert geben, und ggf. noch die Helligkeit umstellen.

Einige der Fragen, die im Forum dieser Seite am häufigsten gestellt werden, ist:
"Wie erstelle ich ein Intro?"
Allein diese Frage hat schon etwas komisches an sich. was erwarten die Leute, die sie stellen, als Antwort?
Eine Funktion "Create intro", bei der man einfach nur ein Knopf drücken muss, und dann schreiben, wie mans haben will?
Einen allmächtigen Befehl, der ihnen, richtig eingesetzt, die ganze Arbeit abnimmt?
Oder vielleicht doch eine komplexe Antwort, die ihnen sämtliche Aspekte des introerstellens erläutert?
Wer letzteres erwartet, ist schon auf dem richtigen Wege. Denn das erstellen von Intros geht nicht mit einem Klick, noch ist es mal eben schnell zu machen. Ein gutes Intro erfordert Zeit, und Aufwand.

Die Frage "Wie erstelle ich ein perfektes Intro?" kann wahrscheinlich nicht mal ich gut beantworten. Denn einmal habe ich selbst noch nie eins erstellt, andererseits ist das vielleicht auch eine Frage, auf die es keine Antwort gibt. Es gibt sicherlich unterschiedliche Arten von Intros, von denen alle ihre Vor- und Nachteile haben..

Das Intro, dass es nicht gibt.

Ja, die Überschrift ist zwar nicht perfekt, erfüllt aber ihren Sinn. Diese Variante wird zum Beispiel in Final Fantasy VII, was ja eigentlich recht bekannt sein sollte, verwendet. Einige werden sich vielleicht erinnern können, wie es dort ablief: Ein kurzer Schwenk über Midgard, ein Blick auf Aerith, eine der Hauptpersonen, ein einlaufender Zug, los gehts:
Der Vorteil dieser Variante war, dass es ohne lange Wartepausen direkt mit dem Spiel losging, wo es dann direkt zur ersten Konfrontation kam. Keine Vorgeschichte, kein unnötiges Gelaber, einfach ein guter, schneller Einstieg. Der Spieler lernt die Welt und die Charaktere erst nach und nach kennen, was gut sein kann, aber nicht unbedingt gut sein muss. Ein solches Intro erfordert sicherlich viel Feingefühl.

Die Vorgeschichte.

Das ist sicherlich eine der langweiligeren Varianten, auf jeden Fall kommt es darauf an, wie man sie verwendet. Da mir jetzt kein besseres Beispiel einfällt, nehme ich das PlayStation RPG "Blaze&Blade", was allerdings nur wenigen von euch bekannt sein dürfte...
Das einzige was der Spieler erfährt, ist die Vorgeschichte des Landes Mabresia, und der Grund für die Ausbreitung der Dämonen, etc.
Es wird einfach ein Text vorgelesen, der gleichzeitig noch eingeblendet wird. Zu den Charakteren, die alle vom Spieler selbst erstellt werden, wird nichts gesagt.
Diese Variante halte ich allerdings nicht für besonders empfehlenswert. Wenn schon nichts zu irgendwelche besonderen Ereignisse gezeigt wird, und auch nicht die Charaktere vorgestellt werden, halte ich die erste Variante, das Intro größtenteils wegzulassen, für deutlich besser.
In dieser Variante muss der spieler nur lesen oder zuhören, er kann nicht eingreifen, noch kann er irgendwelche tollen Ereignisse beobachten.
Vom technischen her gehört diese Variante sicherlich zu den einfachsten. Sie lässt sich leicht mit Pictures, oder noch leichter mit Messages durchführen.

Das Intro zum Mitspielen.

Dies ist widerum kein "echtes" Intro, kann aber gut als solches bezeichnet werden. Als prominentes Beispiel nehme ich mal "Star Ocean 2", optimal Claude's Handlungsstrang.
Die Gruppe analysieren den seltsamen Planeten oder Asteroiden, auf dem Claudes Team gelandet ist. Er widersetzt sich den Anweisungen seines Vaters und wird auf den Planeten von Rena "gebeamt".
Diese Szene hat mit der restlichen Handlung nicht allzu viel zu tun, sondern gibt nur die Grundlage für das Zusammentreffen der beiden und für die seltsamen Umstände. Claudes Charakter wird vorgestellt, und man erhält einen ersten Einblick in die Welt, aus der er kommt. Der Spieler steuert Claude zwar, doch die meisten Ereignisse geschehen automatisch.
Das gute an dieser Variante ist, dass der Spieler größtenteils die Kontrolle behält, und sich mit Steuerung etc. vertraut machen kann, während ihm die charaktere vorgestellt werden. Er wird nicht zum bloßen Zuschauer degradiert, und ist doch nicht völlig auf sich allein gestellt.

Das mysteriöse Ereignis...

Hierbei handelt es sich widerum um eine andere Variante.
Das Spiel beginnt mit einem Ereignis, das meistens vor der eigentlichen geschichte stattfindet. Man sieht eine bestimmte Szene. Dies kann nun in der Kindheit des Helden spielen, oder 500 Jahre vor der eigentlichen Geschichte.
Auffällig daran ist, dass der Spieler bei solchen Intros oft nicht versteht, worum es geht..
Er sieht Personen, die irgendetwas machen, liest Text, dessen Sinn er nicht wirklich versteht und ist ersteinmal ziemlich verwirrt.
Natürlich kann es auch anders sein, es ist klar, was pasiert, warum und was es bewirkt. Ein gutes Beispiel zur ersten Variante ist das bekannte Playstation-RPG Xenogears.
Wer das Spiel zum ersten Mal spielt, wird nicht verstehen, was genau im Intro passiert, weiß nicht wann es stattfindet und welche Folgen es hat, ...
Der Vorteil bei einem solchen Intro ist es, dass man das ganze Spiel unter Umständen auf diese Szene ausrichten kann, dass heißt, mit der Zeit wird immer klarer, worum es da ging, was passiert ist, usw.

Das mysteriöse Ereignis...Part 2

Dieses Intro hat eine gewisse Ähnlichkeit zur vorhergehenden Variante.
Wieder handelt es sich um eine bestimmte Szene, ein Gespräch, oder sonst etwas, was unter Umständen sogar spielbar sein kann.
Der Unterschied ist nun, dass das ganze nicht in der Vergangenheit stattfindet, sondern in der Zukunft.
Diese Szene kann der Schluss des Spiels sein, oder ein beliebiger Punkt in der Mitte der Handlung. Wieder findet eine bestimtme Handlung statt und am Ende kommt dann ein Text, wie etwa "2 Jahre vorher" oder "Wenn ich mich erinnere, wie alles begann", worauf das eigentliche Spiel anfängt.
Als exellentes Beispiel dazu kann ich das englische Makergame "A blurred line" nennen, das ihr bei uns unter Futur -> Demos finden könnt.
Das schöne an dieser Variante ist zum Beispiel, dass man zum Zeitpunkt des Intros die Charaktere nicht kennt, die im Intro vorkommen.
So kann es sein, dass man im Intro einen bösen begleitet, aber mit ihm fiebert und erst im Spielverlauf über dessen wahren Charakter herausfindet. Genauso kann ein Held, den ihr im Spiel liebgewinnen werdet vorkommen, ohne, dass der Spieler etwas über ihn weiß.
Man weiß von Anfang an, worauf das Spiel hinausläuft und fragt sich, wie es von einem idyllischen Anfang zu einem eventuell chaotischen Intro kommen konnte. Das motiviert ungemein, weiterzuspielen, wenn man dies richtig einbaut.

Dies waren nur einige Varianten und ich bin sicher, dass man mit einigem Nachdenken auf noch viel mehr kommt und ich kann ja auch nicht alles aufzählen..
Jede der hier vorgestellten Varianten kann, wenn sie richtig eingesetzt wird, zum perfekten Intro zu eurem Speil werden.. Nicht jedes Intro passt zu jedem Game.

Wichtig ist auch, dass man nicht das Intro vor dem eigentlichen Spiel macht. Wenn man ein Projekt entwicklet, sollte man sich imemr erst die Hauptstory ausdenken, bevor man sich Gedanken darüber macht, wie es losgeht.. (Im Falle von Intro #1 fällt das natürlich weg ^^)

Gerade bei den letzten beiden Varianten, die ich vorgestellt habe, muss man sich überlegen, welche Szene man nimmt und wie diese in die Geschichte integriert wird. So sollte man weder ein vergangenes Ereignis wählen, das später kaum noch etwas mit dem Spiel zu tun haben wird, noch sollte man ein zukünftiges Ereignis wählen, dass schon nach 10, 20 Minuten Spielzeit erreicht ist.


Nun wollen wir mal schauen, wie wir das in unser Kursprojekt umsetzen können.
Für alle, die nciht wissen, worum es dabei geht (nochmalige Erklärung): Zu sogut wie jeder Funktion/etc., die ich hier erkläre gebe ich dann nachher Anwendungsbeispiele an. Diese sind alle miteinander in einem Projekt verknüpft. seit Teil 3 gibt es eben dieses Projekt auch zum Download am Ende jedes Kursteils. Natürlich wird das wohl bei jedem zu Hause anders aussehen, und das ist nur meine Version. Wer bei der ERklärung heir nicht mitkommt, der kann sich meine Version runterladen, und sich den Code nochmal in Ruhe anschaun.

So, nun zur Anwendung: Das Projekt hat ja bisher keine allzu geniale Story oder etwas ähnliches. Dies muss wohl irgendeinmal dazu kommen, aber da wir bis jetzt nichts ausgedacht haben, fallen wohl "Das mysteriöse ereignis Part I/II" weg. "Das Intro, dass es nicht gibt" ist wohl auch keine so tolle Variante, da der Spieler hier nicht mitten in die Action entlassen wird, sondern einfach in der Stadt startet. Ich wähle hier die Variante "Das Intro zum Mitspielen". Praktisch, da in diesem weder groß die Story erklärt werden muss, noch sonst etwas besonderes. Naja, eigentlich werde ich ein Mittelding einsetzen. Die geplante Szene:

Neue Map, vor der Stadt, unter Umständen ein kleiner See, eine Höhle..
Vor der Höhle steht eine Person, nicht der Held (wie man als neuer Spieler allerdings nicht wissen kann). In Wahrheit handelt es sich um den besten Freund unseres Helden.
ER fängt an zu sprechen, in etwa Sachen wie "Komm schon, komm da raus!", "Was machst du da so lange". Nach einiger Zeit komtm aus der Höhle eine Stimme: "Juhuu, ich habs!!". Die Person vor der Höhle springt zur Seite, und unser Held kommt hinaus. Er zeigt sienem Frund etwas, zum Beispiel eine Perle, einen Klumpen Gold oder sonst etwas, was er in dieser Höhle gefunden hat. Die beiden gehen ein Stück und unterhalten sich dabei. Der Name des Helden fällt, außerdem wird klar, dass die beiden Freunde sind, ...

Nachdem sie zu einer Weggabelung kommen, verabschiedet sich der Freund, der in einem benachbarten Dorf wohnt. Der Held macht sich nun auf den weg nahc Hause, hierbei kann er vom Spieler gesteuert werden.

Dies ist nur ein möglicher Anfang für dieses Spiel, man köntne es auf viel verschiedene Varainten machen, von denen jede andere Auswirkungen auf den Verlauf der Story haben könnte. Dadurch, dass wir den Freund eingebaut haben, ist es eigentlich empfehlenswert, ihn in der Geschichte wieder auftauchen zu lassen. Nicht unbedingt als kämpfendes Gruppenmitglied, aber vielleicht als Übermittler von Informationen, Retter in der Not, Auftragsgeber oder ähnliches.

Eine andere Möglichkeit, das Spiel starten zu lassen, wäre zum Beispiel gewesen, den Helden irgendwo aufwachen zu lassen, ohne Erinnerung an seine Vergangenheit oder seine Person. Der erste, den er getroffen hätte, hätte ihn dann erkennen können, worauf der Held sich wundert, ob er diese Person kennt. so erfährt er Schritt für Schritt über seine Vergangenheit. Ist meines Erachtens in diesem Falle die schlechtere Wahl, da es einen derartigen Spielbeginn schon sehr oft gab, und dieser eigentlich auch voraussetzt, dass der Charakter des Helden mit irgendwlechen Geheimnissen zusammenhängt, die es zu lüften gilt.

Soviel zur Theorie, nun kommt es in den nächsten Kapiteln zum Praktischem. Sicher ist es eingen von euch ein Rätsel, wie die Charaktere von allein ihren Weg laufen sollen, oder wie es dem Freund des Helden gelingen soll, vor dem Eingang wegzuspringen, wie der Held plötzlich aus der Höhle kommt, ...

Nun sind wir also bei einem der Befehle die in so gut wie jedem Spiel am häufigsten benutzt werden (dazu gehört natürlich Show Message, aber auch Change Switch oder der Wait-Befehl, den wir in diesem Kapitel ebenfalls kennenlernen werden). Mit Move Event ist es möglich ein bestimmtes Event (also zum Beispiel einen anderen Charakter oder auch den Helden) zu bewegen. Man kann also Charaktere auf Befehl eine bestimmte strecke ablaufen lassen, sie herumspringen lassen, Gespräche abwechslungsreicher gestalten, Grafiken verändern, ... Den Befehl findet ihr im normalen Katalog der Eventbefehle auf Seite 2, rechts unten. Zuerst einmal gehen wir die einzelnen Felder durch:

Object Character: Hier wählt ihr das Event aus, welches sich bewegen soll. Standartmäßig vorgegeben sind:
Hero: Der Held, also die Figur, die der Spieler steuert. Boat, Ship, Airship: Das sind die 3 vordefinierten Fahrzeuge. Diese werden in einem späteren Teil ausführlicher besprochen. this Event: Damit bewegt man das Event, "in" dem sich der Move Event Befehl befindet, also oft einen Gesprächspartner.

Außerdem kann man jedes andere Event auswählen, dass sich auf der jeweiligen Map befindet. Wäre ja auch sinnlos ein Event auf einer Map zu bewegen, die man überhaupt nicht sieht :)

Movement Frequency: Hiermit kann man die Flüssigkeit der Bewegung regulieren, von 1 für sehr abgehackt bis 8 für flüssig. Man kann hier NICHT das tempo der Bewegung einstellen! Ich empfehle grundsätzlich den wert 8, eine niedrige Frequenzy ist fast nie nötig.

Movement Route: Hier werden alle Bewegungsbefehle angezeigt, die ihr ausgewählt habt. Wenn ihr an einer besttimten Stelle noch etwas einfügen wollt, klickt auf das Feld, wo ihr die Änderung vorsetzen wollt. Wenn ihr einen bestimmten Befehl löschen wollt, drückt entweder auf "Entf" oder auf den "Delete"-Button unter diesem Feld. Mit dem "Clear All"-Button lässt sich das gesamte Feld löschen.

Repeat Action: Wenn ihr dieses Kästchen ankreuzt, dann wird die ausgewählte Bewegung immer wieder ausgeführt werden. Die Möglichkeit, das zu stoppen, wird später besprochen! (aber noch in diesem Kapitel)

Ignore, if..: Wenn das Event an irgendeinem Punkt eine Bewegung nicht ausführen kann, und dieses Kästchen abgehakt ist, dann wird der jeweilige Bewegungsbefehl übersprungen. Das geht so lange weiter, bis ein Befehl kommt, der vom Event ausgeführt werden kann. Wenn dieses Kästchen nicht abgehakt ist, dann wird das Event einfach solange, bis der Weg wieder frei ist.

Step Up: Das Event bewegt sich ein Feld nach oben (und schaut dementsprechend dann auch in diese Richtung).

Step Right, Down, Left: Das Event bewegt sich ein Feld nach Rechts/Unten/Links.

Step Right-Up: Das Event bewegt sich schräg nach rechts oben. Diese Bewegung kann nicht ausgeführt werden, wenn sowohl das Feld über, als auch das Feld rechts neben dem Event blockiert sind!

Step Right-Down, Left-Down, Left-Up: Das Event bewegt sich schräg nach Rechts unten/Links unten/Links oben. Auch hier muss wieder eines der benachbarten Felder frei sein.

Random Dir Step: Das Event macht einen Schritt in eine zufällige Richtung. Aber nur die 4 Standartrichtungen, nicht eine der Diagonalen.

Step Toward Hero: Das Event wird einen Schritt auf den Helden zumachen. Nicht verwirren lassen, in der linken Leiste wird dieser Befehl als "Follow Hero" angezeigt.

Step Away from Hero: Das Event wird einen Schritt vom Helden wegmachen. Wird als "Escape from Hero" angezeigt.

Step Forward: Das Event wird einen Schritt in seine Blickrichtung machen (Normaleinstellung: Unten, außer beim Helden natürlich).

Move Speed Up: Hiermit lässt sich jetzt, im Gegensatz zur Frequency, die Bewegungsgeschwindigkeit einstellen. Bei diesem Knopf kann man sie erhöhen.

Move Speed Down: Unglaublich, aber wahr: Dieser Knopf verringert tatsächlich die Geschwindigkeit... Wer hätte das erwartet?

Face Up: Hiermit kann man die Blickrichtung des Events nach oben ändern. Nützlich, wenn sich Leute umdrehen sollen.

Face Right, Down, Left: Ändert die Blickrichtung nach Rechts/Unten/Links.

Turn Right 90°: Das Event machtz eine Vierteldrehung im Uhrzeigersinn. War die Blickrichtung also nach oben, ist sie jetzt nach Rechts.

Turn Left 90°: Das Event dreht sich gegen den Uhrzeigersinn. Wer hätte es erwartet?

Turn 180°: Hiermit dreht sich das Event einmal ganze herum. Schaut es also grad nach oben, schaut es danach nach Unten.

Right-Lft Turn 90°: Das Event macht zufällig eine Vierteldrehung im oder gegen den Uhrzeigersinn.

Random Direction: Das Event schaut in eine zufällige Richtung.

Normal Face Hero: Das Event schaut in Richtung des Helden.

Reverse Face Hero: Das Event schaut vom Helden weg.

Wait a Moment: In der Bewegung wird eine (sehr) kurze Pause gemacht. Sollte man am besten benutzen, wenn sich ein Event nacheinander in verschiedene Richtungen dreht, da das ganze sonst zu schnell passiert.

Move Frequency Up: Hiermit kann man die Flüssigkeit der Bewegung erhöhen, nicht die Geschwindigkeit!

Move Frequency down: Unglaublich: Man verringert die Flüssigkeit der Bewegung.

Start Jump: Hiermit beginnt der Held/das Event einen Sprung, das heißt, er erhebt sich in die Luft. Jetzt kann er in eine bestimmte Richtung bewegt werden, in die er springen soll.

End Jump: Hiermit beendet man den Sprung wieder, das heißt, das Even landet wieder auf dem Boden. Wenn man Start Jump und End Jump direkt hintereinander packt, springt das Event nur einmal kurz in die Luft.

Fix Direction: Hiermit beginnt man die Fixierung der Blickrichtung. Das heißt, wenn das Event nach rechts schaut, man dann die Blickrichtung fixiert, und es dann zBsp. nach oben bewegt, dann geht es zwar nach oben, schaut aber nach rechts.

Cancel Dir. Fixation: Hiermit beendet man die Fixierung wieder.

Start Slip Through: Ein Befehl, der öfters zum Einsatz kommt, zum Beispiel, wenn ein Event über eine Mauer springt etc. Im Prinzip ist dieser Befehl dazu gut, dass das jeweilige Event über jedes Feld laufen kann, selbst wenn dieses blockiert sein sollte.

End Slip Through: dieses Durchrutschen wird beendet, und das Event kann keine Hindernisse mehr "durchfliegen".

Stop Animation: Hiermit kann man für einen bestimmten Zeitraum die Bewegungsanimation des Events ausschalten, dass heißt das Event gleitet nun bewegungslos über die Map.

Resume Animation: Die Animation wird wieder aktiviert.

Transp. Up: Die Transparenz des Events wird erhöht. Je höher, desto durchsichtiger.

Transp. Down: Die Transparenz wird wieder verringert.

Switch ON: Damit lässt sich während einer Bewegung ein Switch anschalten. Das ist praktisch, wenn zu einem bestimmten Zeitpunkt dieser Bewegung etwas anderes passieren soll. Beispiel:
Wir haben einmal ein Event, dass einen Computer darstellen soll. Dieses Event bekommt 2 Seiten. Auf Seite 1 haben wir das Bild von einem ausgeschalteten PC mit dunklem Monitor. Seite 2 hat als Startbedingung einen Switch und zeigt als Bild einen Monitor mit Text drauf. Im gleichen Raum steht jetzt noch eine Person 3 Felder unter diesem PC. Wenn der Held diese anredet kommt erst ein kurzer Dialog, und dann folgende Animation:
- Up
- Up
- Wait
- Switch[xyz]-ON
- Down
- Down
Die Person geht also 2 Felder nach oben, wartet einen Moment, dann wird der Switch angeschaltet UND GENAU DANN wechselt das Bild des PCs und des Monitors, und er geht wieder zurück. Praktisch, nicht?

Switch OFF: dementsprechend kann natürlich auch ein Switch ausgeschaltet werden.

Change Graphic: Hiermit lässt sich die Grafik des Events ändern. Die zwei Hauptanwendungen dafür sind einmal, das Event verschwinden zu lassen. Wenn zum Beispiel ein Charakter das Zimmer verlassen soll, dann lässt man ihn erst zum Ausgang gehen und dann verschwinden, dass heißt, man ändert die Grafik auf ein leeres Feld. (zum Beispiel das letzte Feld in Crown 7, was dem RTP beiliegt) Alternativ kann man natürlich auch einen Switch anstellen, der die Grafik auf ein leeres Feld stellt, und das Level auf "below hero". Wegen letzterem ist die Switchvariante auch zu empfehlen, sonst kann es leicht passieren, dass der Held nachher von seinem unsichtbarem Freund blockiert wird. Die ander Anwendung sind die Posen. Davon gibt es zu manchen Charakteren eine Menge zum Download, wenn ihr auf rpg2000.de unter Charaktere -> Besondere schaut, findet ihr schon einige gute Sachen. Bei Posen kniet sich der Held zum Beispiel hin, liegt verletzt auf dem Boden, etc.

Play SE: Hiermit lässt sich ein beliebiger Soundeffekt während der Bewegung abspielen.

Als Zusatz zum Move Event Befehl seien noch zwei andere, sehr nützliche, Befehle genannt. Zum einen Move All. Dafür muss man wissen, dass in einem Event nach einem Move Event nicht einfach gewartet wird, bis dieses vorbei ist, sondern dass es sofort weitergeht. Beispiel:

Karl und Heinz führen ein Gespräch:
"Jau, wie gehts?"
"Josch, ganz gut..."
"Das ist fein.. hast du mal dein Geschichtsbuch?"
"Jaaaau, ich hol es mal"
Move Event: weit weg und wieder zurück
"Hier ist es"

So wie das Event jetzt aussieht würde die Message "Hier ist es" schon angezeigt werden, sobald Heinz losgeht. Wenn man nun aber nach dem Move Event ein Move All einsetzt, dann wird erst gewartet, bis alle Move Events abgelaufen sind, bevor es im Event weitergeht.
Mit Stop All lassen sich alle Move Events anhalten. Das ist zum Beispiel praktisch, wenn man Events, die auf "Repeat Action" gestellt sind, abschalten will.

Der Move Event Befehl lässt sich klasse in Gesprächen einsetzen. Wenn zwei oder mehr Leute reden, müssen diese ja nicht nur stur herumstehen. Man kann die Leute etwas hin- und herlaufen lassen, sie können manchmal erschrocken aufspringen und man kann, wenn man sich die Mühe machen will, Posen benutzen, in denen die charaktere zum Beispiel die Hände bewegen, oder nachdenklich den Kopf senken, ...
In selbstablaufenden Szenen, wie zum Beispiel dem Intro sind Move Events natürlich unersetzlich.

Sooo... Ich habe ab sofort vor, das Kursprojekt etwas mehr von den einzelnen Funktionen abzugrenzen. Das soll heißen, dass man nicht unbedingt das Kursprojekt benutzen muss, wenn man den Kurs verfolgt...Ich empfehle es natürlich trotzdem ^^

Okay, zurück zum eigentlichen Thema, dass Intro für unser Kursprojekt. Das ganze wird so ablaufen, wie ich im ersten Abschnitt schon gesagt habe.
Wir beginnen also mit einer neuen Map, die nicht allzu groß sein sollte.. Als Chipset lässt sich zum Beispiel gut das Set namens "CT Berge" verwenden... (Ihr findet es unter Chpsets->Welt & Dungeons)
Als Hintergrundmusik habe ich die Midi namens "mtkoltz" aus der großartigen Midi Sammlung von Final Fantasy 6 genommen.
Das neue Chipset muss natürlich erst einmal in der Database eingerichtet werden. Am Anfang kann es durchaus etwas kompliziert sein, mit dem Set umzugehen, aber nach etwas herumprobieren solltet ihr eigentlich damit zurechtkommen.

Nun müssen wir die Map gestalten, wobei euch relativ freie Hand gelassen ist. Da das Chipset leider keinen Höhleneingang hat, werden wir da etwas improvisieren müssen. Wir können es nämlich so einbauen, dass der Höhleneingang seitlich liegt, also so, dass man ihn nicht sehen kann. Entweder machen wir den Eingang an den linken Rand des Bildschirms, oder an eine andere Stelle, an die wir natürlich eine höher gelegene Ebene hinpacken müssen (sonst könnte der Held ja schlecht in eine Höhle gehen).
Ich entscheide mich für die 2. Variante. Der Startpunkt des Helden wird auf den Eingang gelegt (nicht davor). Wenn ihr jetzt startet, dann steht unser Held auf der höheren Ebene, dass soll natürlich nicht so sein, da man den Helden am Anfang gar nicht sehen soll (er ist ja in der Höhle). Dafür gehen wir in die Database unter System und stellen als ersten Helden "None" ein, dass heißt, in der Party befindet sich zum Anfang gar kein Mitglied.
Vor den Eingang stellt ihr nun den Freund des Helden, mit dem Blick auf die Höhle gerichtet.
Jetzt brauchen wir noch ein Autostart-Event, damit das Intro auch sofort beginnt.

Dieses Event können wir damit beginnen, dass der Freund unserem Helden in der Höhle etwas zuruft, zum Beispiel "Komm endlich raus da!", "Sag doch was!", ...
Dadurch wird dem Spieler klargemacht, dass der Freund vor einer Höhle steht und noch mit jemand anderem unterwegs ist. Als nächstes kommt dann aus der Höhle eine Stimme: "Ich habs!!", worauf der Held hervortreten soll. Unser Problem ist jetzt natürlich, wie bekommen wir den Helden aus der Höhle heraus? Dabei treffen wir auf folgende Schwierigkeiten:

Pictures sind, wie man würtlich übersetzen kann, Bilder. Dabei kann man wirklich alles benutzen. Im Gegensatz zu Chipsets, Charsets, oder Animationen sind Pictures nicht auf bestimmte Größen und Formen festgelegt. Man kann im Grunde genommen jedes Bild benutzen, allerdings besteht auch bei Pictures die Grundbedingung, dass sie nicht mehr als 256 Farben haben.
Wenn ihr ein Bild habt, dass ihr in eurem Projekt verwenden wollt, dann müsst ihr dieses zunächst, wie auch alle anderen Dateien, über die Importfunktion des Maker importieren (das kleine Symbol neben dem Database Knöpfchen, RAW Material Editor). wenn ihr so etwas vergesst, kann es nachher passieren, dass in eurem Projekt Dateien fehlen, und dass es zu Fehlern kommt. Beim importieren müsst ihr auf eine Farbe klicken. Diese wird dann später im Spiel transparent angezeigt. Das ist bei fast allen Pictures äußerst wichtig, da es fast immer einen Bereich des Bildes gibt, der transparent angezeigt werden soll. wenn das nicht so ist: Keine sorge, die transparente farbe lässt sich auch deaktivieren!

Pictures werden vielfältig eingesetzt, das hängt immer vom Autor ab. Wenn die Hauptfigur zum Beispiel einen Brief liest, kann man entweder diesen Brief über die Messagefunktion anzeigen lassen. Wer sich aber viel Mühe machen will, um ein möglichst schönes Spiel zu gestalten, der kann mit Hilfe eines Grafikprogrammes so einen Brief erstellen, und als Bild anzeigen lassen.
Leute, die nicht im Besitz so toller Programme wie Photoshop oder Paint Shop Pro sind, mögen zwar auf den ersten Blick Nachteile haben, allerdings gibt es auch gute, kostenlose, Alternativen. Pictures aller möglicher art findet ihr auch auf dieser Seite hier in der Picturerubrik, die es erst seit kurzer Zeit gibt, allerdings schon eine Menge Einträge hat.

Nun wenden wir uns aber einmal den Befehlen zu, die nötig sind, um Pictures im Maker zu verwenden. Der erste Befehl wäre "Show Picture" (Seite 2, rechts)
Wie gewohnt folgt der kurze Befehlsüberblick:

Pic. Number: Hier wählt man die Nummer aus, die das Bild haben soll, dass man anzeigt. es können leider nur 20 Pictures parallel angezeigt werden. Wenn bereits ein Pic mit der Nummer angezeigt wird, die das neue Bild hier eingetragen bekommt, dann wird das alte Bild nicht mehr angezeigt. Das heißt, es können nicht 2 Bilder gleichzeitig angezeigt werden, die die gleiche Nummer tragen.

Select Picture: Hier wählt man das Bild aus, dass man anzeigen will.

Position: Hier gibt man die Pixelkoordinaten für die Position an. Je größer der X-Wert, desto weiter rechts wird das Bild angezeigt. Je größer der Y-Wert, desto weiter unten. Die Koordinaten bezeihen sich auf die Mitte des Pictures. Wenn man also ein Bild auf 160/120 anzeigen lässt (die Gesamtauflösung beträgt 320*240 Pixel) befindet es sich genau in der Mitte des Bildschirms. Ansonsten ist häufiges Ausprobieren die einzige Lösung, ein Bild exakt zu platzieren.

By Variable: Die andere Variante, ein Picture anzeigen zu lassen, nämlich auf vorher gfestgelegten und in Variablen gespeicherten Koordinaten. eine weitere Anwendungsmöglichkeit für Variablen. Ich möchte hier mal ein klaines Beispiel anführen:
Man braucht in seinem Spiel ein bestimmtes Picture immer wieder, dieses Picture soll jedes Mal an der gleichen Stelle angezeigt werden. Man stelle sich jetzt vor, dass man den Befehl dafür ungefähr 100 mal verwendet hat. Nun stellt sich heraus, dass das gnaze dohc nicht so hinkommt, und alles 5 Pixel nach rechts verschoben werden muss.
Der kluge Autor hat bei jedem der Befehle "Show by Variable" verwendet, geht nun nur in ein bestimmtes Event, wo jener Wert festgelegt wurde und ändert ihn um 5.
Der nicht so kluge Autor hat jetzt die spannende Aufgabe, hunderte von Events abzuklappern, und überall die Koordinaten zu ändern...(wenn er wenigstens gelernt hat, wird er jetzt Variablen verwenden).
Wenn man also bestimmte Koordinaten immer wieder verwenden will, lohnt es sich, diese mit Hilfe von Variablen festzulegen.

Move with Map: Diese Bezeichnung kann etwas verwirrend sein: Wenn dieses Kästchen abgehakt ist, und das Picture angezeigt wird, woraufhin sich der Held frei bewegen kann, wird das Picture genau an dem Platz bleiben, wo es hingesetzt wurde. Wenn hier kein Haken ist, wird das Picture an der Stelle des Bildschirms bleiben, wo es hingesetzt ist. wenn es also in der Mitte ist, und der Held nach unten marschiert, bewegt sich das Bild mit nach unten, so dass es in der Mitte bleibt.

Magnification: Hiermit kann man die prozentuale Größe wählen, in der das Bild angezeigt werden soll. Wenn man es auf 100% lässt, wird das Bild so angezeigt, wie es ist. Bei höheren Werten größer, bei tieferen Werten kleiner.

Transparency: Hiermit kann man die Transparenz einstellen. Standartmäßig ist 0% eingestellt, dass heißt, das Bild ist überhaupt nicht durchsichtig. Bei 100% sieht man dann gar nichts mehr.

Transparent Color: Man kann zwischen Stir und None wählen. Bei Stir wird die Farbe transparent gewählt, die man vorher beim Importieren angeklickt hat. Wenn man None wählt, wird keine Farbe transparent gezeigt. Praktisch, wenn man ein Bild hat, dass keine transparenten Stellen enthält.

Additional Effect: Hier lassen sich nocheinmal einige Einstellungen vornehmen:

Dungeons, wer kennt sie nicht? Kein RPG ohne sie, kein Spiel perfekt ohne DEN einen Dungeon, in dem jeder Spieler verzweifelt...
Doch wie genau schaffe ich es, gute, spannende und ausbalancierte Dungeons zu erstellen? Auf diese Frage werde ich im folgenden versuchen, eine Antwort zu geben.

•  Das Mapping
Auf die Frage, wie man einen Dungeon mappen sollte, gibt es wohl sicherlich keine einfache Antwort. Das liegt zum einen daran, dass Dungeons in vollkommen unterschiedlichen Umgebungen stattfinden können. So kann ein normales Hochhaus genauso zu einem Dungeon werden wie eine Kanalisation, ein Park oder, wie so oft, eine Höhle. Selbst, wenn man mit dem Begriff "Dungeon" nur Höhlen assoziiert, gibt es doch wieder unterschiedliche Arten. Ist es eine natürliche Grotte? Wurden Gänge von Menschen ausgegraben? Gibt es dort befestigte Anlagen? usw.usw.
Nehmen wir mal an, dass wir nun eine von Menschen gegrabene Höhle haben. Was machen wir damit? Schließlich soll sich der Spieler ja einige Zeit darin aufhalten, ohne, dass es besonders langweilig wird.
Zuallererst muss mann sich überlgen, was der Charakter in dieser Höhle will. Will er sie durchqueren? Will er eine Räuberbande ausschalten, die sich dort verschanzt hat? Will er einen seltenen Schatz finden? Oder noch was anderes?

Zu Rätseln komme ich übrigens später, also nicht wundern, wenn sie hier nicht erwähnt werden.


•  Durchqueren:
So eine Höhle zu mappen ist recht angenehm. Man legt einen Eingang fest, sowie einen Ausgang, das ganze kann ruhig auf einer einzigen Map sein, natürlich kann sich das ganze aber auch durch mehrere Etagen ziehen. Generell fallen Maps für Dungeons recht groß aus, also beim Erstellen nicht zu geizig sein =D.
Um den Spieler in einer solchen Höhle für längere Zeit zu beschäftigen, braucht man vor allem Abzweigungen und Sackgassen. Ein Schlangenförmiger Weg kann schnell durchlaufen werden, aber wenn man an jeder Abzweigung beide Wege ausprobieren will, weil am Ende eine Schatztruhe als Belohnung warten könnte, zieht sich die Angelegenheit.
Wenn von einer Abzweigung in die "falsche", also die "Nicht-Ausgangs" Richtung noch einmal eine Abzweigung abgeht, ist der Spieler lange beschäftigt und wird sich am Ausgang umso mehr freuen, diesen Abschnitt des Spiels bewältigt zu haben.


•  Schatzsuche:
Für so etwas biete sich natürlich ideal eine rätsellastige "mehrstöckige" Höhle an, in der der Spieler immer von einem Ort zum anderen eilen muss, um schließlich zum begehrten Objekt zu gelangen.
Deshalb kann man hierfür am besten mehrere Maps verwenden. Zum Besipiel eine Eingangsmap, in der der -auf irgendeine Art verschlossene- Raum zum Schatz ist, sowie eine Treppe oder ähnliches nach unten, und außerdem noch ein weiterer Gang, der woanders hin führt. Wenn man diesem Gang folgt könnte man zum Beispiel in einen weiteren Abschnitt kommen, in dem sich eine (unbedeutende) Truhe finden lässt.
Während man im Untergeschoss vielleicht eins von drei Objekten findet, die man zum Betreten des Schatzraums braucht (mehr dazu später), die anderen zwei aber an wieder aanderen Orten versteckt sind.


•  Räuberbande:
Im Prinzip kann man eine derartige Höhle ganz ähnlich wie die letzte gestalten.
Den Aufbau kann man theoretisch übernehmen, auch wenn man das ganze auf eine einzige Ebene übertragen könnte. Der Raum zum Schatz ist nun der Raum zum Endgegner (der Schatz hätte natürlich auch bewacht werden können), der Zugang dazu ist nun halt von einer Tür versperrt, für die man erstmal den Schlüssel finden muss. Diesen hat vielleicht eine Wache, die irgendwo in dieser Höhle stationiert ist.
Das Problem: Die Höhle ist groß, und Wachen gibt es viele. Wer fies sein will, gibt jeder wache einen Schlüssel, leider passt nur einer, was dazu führt, dass der Spieler nach der ersten besiegten Wache schon wieder zurückgeht, nur um zu merken, dass er den falschen Schlüssel hat ^^'
Wie ihr seht, bietet dieses Szenario viele nette Möglichkeiten.


•  Allgemeines:
Allgemein sollte man beim Mapping in Dungeons einiges beachten. Denn eine der wichtigsten Eigenschaften von Dungeons ist die Atmosphäre, die stimmen sollte. Bedrohliche, spannende Stimmung ist meistens die richtige Wahl. Dazu trägt natürlich vornehmlich die Musik bei, aber aber auch das Design. Enge, verzweigte Gänge sind oft wirksamer als große Hallen (beachtet: oft heißt nicht immer ^^), helle Chipsets wirken oft unbedrohlicher. Wenn ihr aber trotzdem ein helles Chipset für passend haltet, macht es via "Set Screen Tone" ein bisschen dunkler (siehe Tag/Nacht Zyklus). Fackeln an den Wänden sehen auch immer nett aus (denkt euch aber eine logische Erklärung aus, wenn ihr in natürlichen Grotten Facklen an den Wänden habt =D) und lassen sich mit netten Effekten untermalen (dazu komme ich später noch). Falls in den Chipset eurer Wahl keine Fackeln sind, dann schaut euch vielleicht mal hier auf der seite in der Charset Sektion um, da sollten theoretisch welche sein ^^'
Nett sind auch kleine "Schockeffekte", zum Beispiel lasst ihr den Helden über eine Brücke gehen, die plötzlich einstürzt und ihn in eine tiefere Ebene fallen lässt, aus der er sich erst wieder "hocharbeiten" muss.

Rätsel:
Ein Dungeon ohne Rätsel ist kein Dungeon (obwohl es wie immer Ausnahmen geben mag), und das führt uns zu diesem Abschnitt. Das schöne an Rätsel ist, dass die Leute meistens nicht einmal erwarten, dass ihr besonders kreativ sein müsst. Ich meine, jedes zweite Spiel hat ein Schalterrätsel, aber so lange sich sowas nicht innerhalb des Spiels andauernd wiederholt, stört das kaum jemanden. Außerdem ist es bei solchen Dingen auch nicht gerade einfach, kreativ zu sein. Sicher kann man ein besonders verzwicktes Schaltsystem entwerfen, oder das größte Kistenlabyrinth, was es je gab, aber das ist immer noch nichts "neues". Und wenn ihr eine tolle Idee habt, dann achtet darauf, nicht euer gesamtes Pulver am Anfang zu verschießen. Schließlich hat ein normales RPG viele Dungeons, dementsprechend auch viele Rätsel, wenn ihr also in den ersten Dungeon schon ein geniales kombiniertes Kistenverschiebeschaltergeneratorenschlüsselsteinrätsel einbaut und euch dann für den nächsten Dungeon nichts mehr einfällt, habt ihr das Ziel verfehlt. Ideal ist es vielleicht eher, eine Art Kurve in Sachen Dungeons zu haben, dass soll heißen, mit jedem Dungeon komplexere und schwierigere Rätsel einzuführen.
Nun aber dazu, wie man diese einzelnen Rätsel auf- bzw. einbaut:


•  Kistenrätsel:
Sozusagen die Königin unter den Rätseln, und auch eins der "gefährlichsten" Arten von Rätseln. Zuviele Verschieberätsel können den Spielspaß genausogut eindämmen wie dicke Bugs oder eine miese Story. Ich verweise da nur auf das relativ neue Adventure Baphomeths Fluch 3, dass diesen Fehler meiner Meinung nach leider begangen hat.
Falls ihr so einem Rätsel noch nie begegnet seit, hier eine kurze Erläuterung:
Ein Kistenrätsel bedeutet meist, dass der Held zu einem bestimmten Eingang will, der Weg dorthin aber von Kisten verstellt ist. Diese muss man nun so verschieben, dass der Weg frei wird. Allerdings lassen sie sich auch in "falsche" Richtungen verschieben, wodurch es unmöglich gemacht wird, das Ziel zu erreichen, und man noch einmal von vorne beginnen muss.
Alternativ muss man die Kisten verschieben, um zum Beispiel an einen höher gelegenen Ort zu gelangen, oder um einen Abgrund zu überqueren.
So ein Rätsel lässt sich auf unterschiedliche Weisen programmieren, die einfachste ist jedoch, die Kisten auf Druck der Aktionstaste (Enter, Leertaste, ...) in Blickrichtung des Helden verschieben zu lassen.
Das Event sähe dann folgendermaßen aus:

(On Push Key)
Fork Condition: Hero, Face Up
-Move Event: this Event, Step Up, Ignore if can't be moved
-Move All
Fork Condition: Hero, Face Right
-Move Event: this Event, Step Right, Ignore if can't be moved
-Move All
Fork Condition: Hero, Face Down
-Move Event: this Event, Step Down, Ignore if can't be moved
-Move All
Fork Condition: Hero, Face Left
-Move Event: this Event, Step Left, Ignore if can't be moved
-Move All

Ich hoffe mal, dass euch das Prinzip klar geworden ist.
"Ignore if can't be moved" ist wichtig, damit sich das Spiel nicht aufhängt, falls der Spieler versucht, die Kiste in eine Richtung zu verschieben, in die sie sich nicht bewegen lässt.
"Move All" ist wiederum wichtig, damit sich die Kiste erst ein Feld fortbewegt, bevor der Held wieder eine andere verschieben kann. Ansonsten kann es nämlich leicht passieren, dass sich die Kiste "aus Versehen" zwei Felder in eine Richtung bewegt ^^'

Ihr fragt euch jetzt vielleicht, was passiert, wenn der Held die Kisten falsch verschiebt, und sich das Rätsel nicht mehr lösen lässt?
Die antwort ist eigentlich simpel. Sobald sich der Spieler mit dem Charakter auf eine andere Map begibt, und dann wieder zurückkehrt, sind die Kisten wieder an ihrer Ausgangsposition. Darum empfiehlt es sich, solche Rätsel auf einer seperaten Map anzulegen =)


•  Schalterrätsel:
Schalterrätsel sind die zweite beliebte Rätselform in RPGs. Bei solchen Rätseln sind euch generell alle Freiheiten gelassen, so könnt ihr den Spieler theoretisch erst einmal 100 Schalter anstellen lassen, bevor er den Raum mit dem Endgegner betreten darf.
Als Beispiel will ich einmal das Schalterrätsel aus dem ersten Dungeon von Kokibis Spiel "A Gate into Eternity" nehmen. Dies ist sozusagen ein doppeltes Schalterrätsel. Ausgangssituation ist, dass ein Generator angeschaltet werden muss, damit die Charaktere weiter voran gehen können. Dieser Generator kann mit Hilfe von vier Energiequellen oder ähnlichen Sachen aktiviert werden. Vom Hauptgang, der geradeaus zu der Stelle führt, die die Aktivierung des Generators benötigt, führen also vier Nebengänge ab, die allerdings jeweils versperrt sind. Um den Zugang zu Gang A zu öffnen, muss man 2 Hebel betätigen. Wenn man das getan hat, ist Gang A geöffnet, der gegenüberliegende Gang B allerdings verschlossen. Um den zu öffnen, muss man den zweiten Hebel erneut umlegen, wodurch Gang A allerdings wieder geschlossen wird. Das ist zwar kein besonders großes Hindernis, aber vielleicht eine nette Ergänzung. Genauso ist die Angelegenheit bei Gang C und D. Wenn man in jedem Gang war und die jeweilige Energiequelle aktiviert hat, ist der Genertator angeschmissen und der nächste Raum zugänglich.
Zum programmiertechnischen lässt sich nicht viel sagen, das Ganze ist problemlos mit Switches zu machen ^^'


•  Schlüsselrätsel:
Im Grunde genommen ist dies nur eine abgewandelte Version des Schalterrätsels.
Dort musste der Spieler an irgendeine Stelle des Dungeons, um einen oder mehrere Schalter umzulegen. Hier muss der Spieler nun an irgendeine Stelle des Dungeons, um einen Gegner zu besiegen und ihm einen Schlüssel abzunehmen... oder diesen in einer Truhe zu finden.
Es ändert sich also kaum etwas =)

Gegner:
Gegner gehören natürlich genauso zu einem Dungeon dazu, wie die Rätsel ^^'
Auch wenn sich ein Dungeon ohne Gegner denken ließe, würde er mit der Zeit doch wahrscheinlich ziemlich langweilig werden.


•  Standartgegner:
Wie der Titel schon sagt, geht es hier um die Gegner, die alle paar Momente auftauchen, um den Helden das Leben schwer zu machen. Wichtig ist hierbei, dass es einmal neue Gegner sind, aber auch unterschiedliche Gegner. Die Kämpfe können mit der Zeit ganz schön ermüdend sein, und wenn man das ganze Spiel über gegen die gleichen Monster antreten muss, die in einem Gebiet ohne jegliche Variation kommen, umso mehr. Abwechselnde Monster Parties mit unterschiedlichen Schwierigkeiten können da zumindest teilweise Abhilfe schaffen und der "Oho, ein neuer Gegner, mal schauen, was der so drauf hat" Effekt ist meiner Meinung nach auch nicht zu unterschätzen.


•  Bossgegner:
Zu einem guten Dungeon gehört auch ein guter Endgegner. Ein Endgegner ^^'
Mehrere Bosse in einem Dungeon sind meiner Meinung nach nicht angebracht, ein "Höhepunkt" sollte schon ausreichen.
Wie der Name schon sagt, sollte dieser Gegner im Optimalfall auch am Ende des Dungeons sein. Wenn man zum Beispiel einen Dungeon hat, in dem der Charakter einen Schatz sucht, hat der Spieler nun zwei "gute" Punkte, an denen er den Endgegner erscheinen lassen kann.
Der erste Punkt ist natürlich, den Endgegner den Wächter des Schatzes sein zu lassen. Man trifft dann auf ihn, nachdem man sämtliche Rätsel gelöst hat, um in den Raum mit dem Schatz hineinzukommen. Nachdem man ihn besiegt hat, bekommt man die gesuchte Trophäe und ist froh. Diese Stelle ist also der Höhepunkt des Dungeons (oder sollte es sein). Nun kann man den Spieler entweder direkt aus dem Dungeon hinausteleportieren, was meiner Meinung nach die bessere Lösung ist. Alternativ kann man den Spieler aber auch den ganzen weg wieder hinauslaufen lassen, was ziemlich nervig sein kann, wenn die Helden vom Kampf noch angeschlagen sind, und sich der Weg zum Ausgang zieht.
An dieser Stelle gäbe es die zweite Möglichkeit. Man lässt den Schatz unbewacht, und die Helden wieder den Rückweg antreten. Der Spieler mag nun denken, dass es in diesem Dungeon überhaupt keinen Boss gab. Aber wenn er gerade hinausgehen will, erscheint plötzlich ein zweiter Schatzjäger, der den Helden den Schatz abnehmen will. Oder ein riesiges Spinnenmonster XDD
Damit wäre der Höhepunkt des Dungeons gleichzeitig das Ende, was, wie ich denke, eine gute Sache ist ^^

Balancing:
In dieser Untersektion kann ich nicht viel mehr machen, als euch ein paar gute Ratschläge zu geben, das meiste bleibt einfach euren eigenen Einschätzungen überlassen.
Worum es hier gehen soll, versteht ihr hoffentlich alle.


•  Größe:
Eine der Sachen, die ausbalanciert werden muss, ist die Größe eines Dungeons. Ihr müsst darauf achten, dass der komplette Dungeon weder in 2 Minuten durchlaufen werden kann, noch darf sich das ganze über 12 Ebenen mit 100*100 Maps hinziehen, da dann selbst Hardcorespieler entnervt aufgeben könnten =).
Das lässt sich am besten ausbalancieren, wenn ihr alle Gegner eingebaut habt, und den Dungeon selber zur Probe spielt, oder noch besser, jemand anderen spielen lasst, der nicht weiß, welche Wege man gehen muss. Wenn ihr dann auf die Zeit achtet, solltet ihr euch eine Vorstellung machen können, ob die Größe des Dungeons gut gewählt ist, oder ihr vielleicht noch einige Anpassungen vornehmen solltet.


•  Rätsel:
Wichtig bei Rätseln ist, dass sie nicht zu schwer sind (natürlich auch nicht zu leicht) und den Spieler nicht unnötig lange beschäftigen.
Als Negativbeispiel könnt ihr euch zum Beispiel einen Dungeon denken, in dem ihr 3 Schalter in bestimmter Reihenfolge aktivieren müsst. Diese 3 Schalter sind an den äußersten Ecken des Dungeons, und dem Spieler wird die Reihenfolge nicht gesagt, so dass er ewig umherirren muss, bis er das geschafft hat. Nervig.
Oder ein Kistenrätsel, in dem man 20 Kisten verschieben muss, um zum Ziel zu gelangen. Die Lösung lässt sich allerdings nur durch wiederholtes Ausprobieren herausfinden. Äußerst demotivierend.


•  Gegner:
Das sollte eigentlich klar sein. Die wichtigen Punkte hierbei sind natürlich, dass die Gegner nicht zu oft auftauchen, nicht zu stark sind, oder dem Spieler nicht ohne große Anstrengung viel Erfahrung geben. MAcht euch vielleicht vorher Gedanken darüber, wieviel stärker die Helden in dem Dungeon werden sollen, und balanciert das ganze unter diesem Gesichtspunkt aus. Die Anzahl der Gegnergruppen ist wirklich wichtig, nichts ist so nervig, wie alle 3 Schritte einen neuen Kampf führen zu müssen -.-

Effekte:
Der letzte Punkt in dieser Kategorie ^^'
Effekte können die Atmosphäre in einem Dungeon entscheidend verbessern. Zusätzlich zur Hintergrundmusik, die natürlich die (falls gewünscht) düster spannende Atmosphäre ausstrahlen sollte, kann der ein oder andere Soundeffekt noch eine nette Ergänzung sein. Zum Beispiel kann ein stetes Tropfgeräusch dem Spieler vermitteln, dass Wände und Boden feucht glitschig sein, in einer Höhle mit Lavaströmen kann man ein ständiges Brodeln laufen lassen, so wie vielleicht das gelegentliche Platzen einer Luftblase.
Auch leise Geräusche der Monster im Hintergrund sind eine hübsche Ergänzung. Ein gelegentliches Brüllen, Fluggeräusche von Fledermäusen, Kratzgeräusche, ...

Ein ganz anderer Effekt, der in einigen Spielen verwendet wird, ist die Verdunkelung. Dazu braucht man ein Bild, dass an den Ränder schwarz ist, und nur in der Mitte einen andersfarbigen Kreis hat, der dann später transparent wird. So kann der Spieler dann immer nur die unmittelbare Umgebung der Helden sehen, die Ränder des Bildschrims sind dunkel.

Noch ein anderer Effekt, der sich auch in anderen Gebieten einbringen lässt, sind Fackelscheine. Dazu braucht ihr das passende Charset (Besonderes -> Fackelscheine), mit dem sich über Fackeln oder Kerzen ein Leuchteffekt erzeugen lässt.


Das wars auch schon mit dieser Rubrik. Abschließend ist nur zu sagen, dass ihr darauf achten solltet, eure Dungeons gut zu balancieren und außerdem nicht zu viele von ihnen zu machen. Wenn sich in eurem Spiel nur ein Dungeon an den nächsten reiht, wird es schnell langweilig. Ich hoffe, ich konnte euch zu einigen Ideen verhelfen ^_^'

Kursprojekt: Dungeon
So, nun der Abschnitt zum Kursprojekt.
Das ganze muss nun in mehreren Schritten angegangen werden. Schritt 1 wäre, den Dungeon logisch in die Story des Spiels einzubinden. Das Kursprojekt hat bisher zwar keine großartige Story, aber das kann sich ja ändern.
Die Story, die ich mir für diesen Fall ausgedacht hatte, ist vielleicht nicht besonders episch, aber ein guter Vorwand, einen Dungeon einzubringen ^^'
Nachdem man in der Kampfarena die Soldatin besiegt hat, wird ja bekanntermaßen ein Switch aktiviert. Wenn dieser Switch aktiviert ist, lasse ich nun im Event, das bisher die Meldung "Ich will noch nicht wieder aus der Stadt weggehen" anzeigen ließ, eine neue Seite aufrufen, die den Helden auf die Intromap teleportiert. (Die mit der Kreuzung, wo Kiren und sein Freund Deji sich getrennt haben). Bisher war dort nicht viel mehr zu machen, als dass man in Kirens Stadt (Zellheim) gehen konnte. Wenn man versuchte, zu Deji (Saalburg) zu gehen, kam eine Meldung, dass Kiren nach Hause wolle, und nicht zu Deji. Jetzt aber lassen wir in diesem Event ebenfalls eine zweite Seite aufrufen, wenn der Switch von eben aktiviert ist, wodurch Kiren nach Saalburg teleportiert wird. Natürlich muss die stadt nun noch gemappt werden.
Für diesen Teil sind die Innenleben der Häuser allerdings von keiner Bedeutung, also braucht ihr erst einmal nur das äußere zu mappen. Anschließend stellt in die Nähe des eingangs einen Mann, der Dejis Vater sein soll. Nun nur noch ein Autostart Event hinzufügen, so dass er sofort ein Gespröch beginnt, wenn man mit Kiren in die Stadt kommt. Der genaue Wortlaut des Gespräches ist irrelevant, er teilt Kiren nur mit, dass die Familie von Banditen beraubt wurde und Deji diesen in eine Höhle gefolgt ist, um das Geld der Familie zurückzuforden. Kiren beschließt darauf, ihm zu helfen.
Als nächste Map brauchen wir das Äußere der Höhle, auch wenn man dieses theoretisch weglassen könnte. Ich habe dazu das Chipset Welt/Dungeons -> Breath of Fire 2 benutzt. Wichtig ist, dass ihr beim Teleport nicht den Tag/Nacht Zyklus vergesst, also den Switch T/N unsichtbar an stellt und den Screen Tone wieder auf normale Verhältnisse setzt. Bei herausgehen müsst ihr den T/N-Zyklus natürlich auch beachten ^^'
Den Dungeon selber habe ich mit dem Chipset Dungeon (Braun) gemappt, was allerdings relativ kompliziert zu handhaben ist. Ihr könnt also ruhig ein anderes benutzen... die Idee für den Dungeon war, ihn nicht allzu groß zu machen. Das Rätsel sollte einfach gehandhabt werden, es müssen 3 Steine gefunden werden, um eine Leiter herunterfahren zu lassen, die zu einem Vorsprung führt, auf dem der Endboss ist. Das ganze habe ich auf 3 Maps verteilt. Die Schlüsselsteine lassen sich in Kisten finden, außerdem habe ich noch eine weitere Kiste hinzugefügt, die (vorerst) leer bleibt. Mehr zu dieser Kiste später.
Das system war dann ganz einfach. Jedes Mal, wenn man einen Stein gefunden hat, wird natürlich ein Switch aktiviert, damit man die Kiste nicht unendlich oft öffnen kann und jedes Mal wieder einen Stein bekommt. Beim Event, in das man die Steine einsetzen muss, wird dann ganz einfach geprüft, ob alle Switches aktiviert sind. Ist dies der Fall, wird die Leiter heruntergefahren, also ein Switch aktiviert, durch den die Felder, die vorher nichts außer dem Hintergrund angezeigt haben jetzt die Leiter darüber anzeigen.
Oben angekommen wird ein Event ausgelöst, in dem man sieht, wie sich Deji und der Banditenanführer prügeln. Nützlich dazu ist der Befehl "Flash Event", mit dem man ein Event für eine bestimmte Zeit einfärben kann, also Deji nach einem Schlag des Banditen rot aufleuchten lassen kann. Schließlich ist Deji erledigt und Kiren wird ihm zu Hilfe eilen. Dazu müssen wir natürlich zuerst einmal den Banditen als Gegner erstellen. Ich habe ihn von der Schwierigkeit her ungefähr so stark wie die Soldatin aus der Kampfarena gemacht, er sollte also für den Helden kein großes Hindernis sien, der zu diesem Zeitpunkt auf Level 4 oder sogar schon 5 ist. Außerdem habe ich für den ganzen Dungeon gleich nochmal ein neues Monster erstellt, da man ja nicht immer gegen die gleichen Gegner kämpfen will. Sowas muss natürlich getestet und ausbalanciert werden ^^'

Nachdem der Gegner besiegt ist, habe ich das Projekt erst einmal enden lassen, da ich es im nächsten Teil an dieser Stelle fortführen will.

Speicherpunkte sind in so gut wie allen RPGs vorhanden, wenn auch in vielen unterschiedlichen Formen. Die normalste und am weitesten verbreitete ist die Form des leuchtenden Dingsda, auf das man draufgehen muss.
Makertechnisch gesehen wäre dies ein On Hero Touch Event, dass die Speicherfunktion aktiviert, umgeben von On Hero Touch Events, die die Speicherfunktion wieder deaktivieren. Das ganze ist also relativ simpel zu lösen. Zu aller erst muss die Speicherfunktion anfänglich erst einmal deaktiviert sein. Dies lässt sich ganz einfach lösen, im ersten Autostart Event des Spiels einfach den Befehl "Disable Save: Disable" verwenden (zu finden auf Seite 3 des Event Dialoges). Nun muss eine geeignete Position für den Speicherpunkt gewäht werden. Optimal für sowas ist natürlich immer eine Stadt, der Eingang eines Dungeons, bzw. eine Stelle kurz vor dem Bossgegner, falls der Dungeon lang war. Dort erstellt ihr nun ein einfaches Event, Below Hero, die Grafik ist egal, sucht euch irgendetwas passendes aus (zum Beispiel die Flamme aus den RTP Charsets). Dieses Event braucht auch nur eine Seite, die mit "On Hero Touch" aktiviert wird. Dort gehört der Befehl "Disable save: Enable" hinein, sowie eventuell eine Message "-Speicherpunkt-". Jetzt kann der Spieler, wenn er mit dem Helden auf diesen Punkt läuft, das Menü aufrufen und die Speicherfunktion wählen.
Das Problem: Wenn er von diesem Feld runtergeht, kann er das immer noch tun. Deshalb müssen wir auf den vier benachbarten Feldern (falls der speicherpunkt nicht ovr einer Wand steht, sonst nur drei oder sogar 2 ^^') ebenfalls On Hero touch Events erstellen, die einfach den Befehl "Disable Save: Disable" beinhalten.
Natürlich gibt es diverse Abwandlungen. So könnte man den Speicherpunkt auch als Same Level as Hero Event erstellen, der durch Push Key aufgerufen wird und den Befehl "Call Save Menu" enthält (direkt über disable save). So lässt sich nichts mit dem Menü machen ^^'

Als Zusatz dazu kann man gleich noch Items machen, die nur auf Speicherpunkten benutzbar sind, wie das allseits bekannte Zelt. Dazu brauchen wir erst einmal Item in der Kategorie Switch, welches nur ein mal benutzt werden kann. Dieses aktiviert dann einen Switch, nennen wir ihn mal "Zelt benutzt". Der nächste Schritt ist es, ein Common Event zu erstellen, welches aktiviert wird, sobald eben dieser Switch angeschaltet ist. Dort wird mit einer Fork Condition geprüft, ob der Switch "Savepoint" aktiviert ist (nicht wundern, kommt gleich). Ist dies der Fall, wird die gesamte Gruppe geheilt und der Zeltbenutzt Switch wieder ausgestellt. Ist dies NICHT der Fall, kommt eine Message "Hier kann das Zelt nicht benutzt werden", der Held bekommt ein Zelt dazu (weil er seins ja benutzt hat und dieses verschwunden ist, obwohl es ja gar nicht geklappt hat), außerdem wird der Switch wiederum deaktiviert.
Nun muss nur noch bei jedem Savepoint Event der Switch "Savepoint" aktiviert werden bzw. bei jedem angrenzenden Event wieder deaktiveiert werden. Ta-daa!

Die letzte Variante, die mir jetzt noch einfällt ist das Speicheritem, also ein Gegenstand, den man nur ienmal benutzen kann, mit dem man dann aber überall speichern kann. Wie das funktioniert solltet ihr eigentlich selber ahnen können, aber zur Sicherheit will ich es nochmal erklären:
A) Ein Item muss erstellt werden, Klasse Switch, Number of Uses 1.
B) Ein Common Event muss erstellt werden, das bei diesem Switch aufgerufen wird.
C) Es muss den Spieler speichern lassen (Call Save Menu)
D) Der Switch muss wieder deaktiviert werden

Kursprojekt: Hier gibt es dieses Mal nicht soviel zu sagen, so dass sich eine eigene Rubrik nicht lohnt. Ich habe im bisherigen Projekt zwei Speicherpunkte eingebaut, einmal in den Eingangsbereich des Dungeons und einmal auf die Hauptmap von Zellheim.

Mit Zufallsgeneratoren lässt sich im Maker eine Menge anstellen. Zumindest, wenn man schon etwas fortgeschritten ist, und sich vielleicht an ein eigenes Kampfsystem wagen will, wo, wie im Standart KS, Zufall eine sehr wichtige Rolle spielt. So unterliegen die Schadenswerte, die Spieler und Gegner verursachen teilweise Zufallsroutinen, es wird zufällig bestimmt, gegen welche Gegner man kämpft und WANN man gegen sie kämpft, ob die Flucht gelingt wird vom Zufall beeinflusst, kritische Treffer natürlich auch, das erhalten von Items usw. usw.
Natürlich gehen wir solche Themen noch nicht an (ich fürchte ich könnte das auch gar nicht ^^'), sondern befassen uns mit anderen Anwendungsmöglichkeiten von Zufallsgeneratoren.


•  Zufällige NPC Antworten:
Dies ist eine nette Funktion, die meines Wissens gar nicht mal häufig genutzt wird. So kann es ziemlich langweilig sein, wenn der typische NPC nur einen Satz drauf hat, erst recht, wenn dieser vom Kaliber "Die ernte wird bei diesem Wetter nicht sehr gut werden." ist. Ich meine, wer beim fünften Gespräch immer noch so einen Satz von sich gibt würde in der normalen Welt für geistig gestört erklärt werden xD
In RPGs ist das prinzipiell etwas anderes, und einen NPC jedes Mal etwas anderes entgegnen zu lassen ist technisch unmöglich. Also beschränken wir uns zum Beispiel auf 3 Sätze, die er von sich geben kann. Dazu brauchen wir als erstes eine Variable, die wir allerdings für alle NPCs im gesamten Spiel verwenden können.
Der Befehl "Change Variable: Set Rand. 1 * 3" setzt die ausgewählte Variable auf einen Zufallswert zwischen 1 und 3. Als nächstes 3 Fork Conditions, die abfragen, ob die Variable auf 1, 2 oder 3 steht, in jede Fork Condition ein anderer Antwortsatz und fertig sind wir.
Das ganze lässt sich also theoretisch auf tausende von Antwortsätzen erweitern XD
Natürlich kann es nun immer noch vorkommen, dass der NPC beim zweiten Ansprechen das gleiche sagt, wie beim ersten Mal, aber spätestens beim dritten oder vierten Ansprechen ist dies sehr unwahrscheinlich.


•  Zufällige Kisteninhalte:
Das ist ein schönes Extra bei Spielen, wovon der Spieler meist nichts merken wird, außer wenn er eine Szene mehrfach spielt, oder darauf hingewiesen wird. Prinzipiell funktioniert diese Funktion genauso, wie die zufälligen Antworten des NPC. Zuerst wird eine Variable auf einen Zufallswert festgelegt, danach wird sie per Fork Conditions überprüft, und der Held erhält bei jeder Variante ein anderes Item. Wer fies sein will, kann auch eine Möglichkeit einbauen, dass der Held gar nichts bekommt. Leere Kisten sind ärgerlich ^_~
Alternativ kann man Kisten auch erst zufällig erscheinen lassen, das heißt, wenn man einen Dungeon betritt, wird für jede Kiste eine Zufallsvariable ermittelt, die bestimmt, ob die Kiste angezeigt wird, oder nicht. Das ist allerdings nicht wirklich sinnvoll.


•  Zufallswetter:
Diese Funktion geht noch einmal einen Schritt weiter, zentral ist der Befehl "Call Weather Effect" (Seite 2), mit dem man Regen und Schnee in verschiedenen Stärken anzeigen lassen kann.
Vom Aufbau her ist die Funktion mit dem Tag/Nacht Zyklus zu vergleichen. Man braucht ein Common Event, das aktiviert ist, wenn der Switch "Wetteranzeige" aktiviert ist. (Der Switch muss dann natürlich ausgestellt werden, wenn man Höhlen oder Räume betritt, ein Indoor-Schneesturm kommt eher nicht so gut ^^) Man lässt dann einfach eine Zufallsvariable ermitteln, nach der das Wetter auf eine der 7 Möglichkeiten gestellt wird (Nichts, Regen leicht, Regen Mittel, Regen stark, Schnee leicht, Schnee Mittel, Schnee stark) und dann ein Wait kommt, bis sich das Wetter wieder verändert.
Eventuell sollte man die Möglichkeit das Nichts geschieht bei mehreren möglichen Variablenwerten wählen lassen, da es sonst viel öfter regnet und schneit, als dass die Sonne scheint. Außerdem muss man auch auf die Region achten, in der sich der Held befindet, Schnee in der Wüste ist doch eher unpassend.

Kursprojekt: Hier gibt es wieder einmal nicht besonders viel zu sagen. Ich habe in Zellheim einen weiteren NPC hinzugefügt, der drei zufällige Sprüche von sich gibt, außerdem habe ich der Truhe im Dungeon, die bisher nur leer war, ebenfalls einen Zufallseffekt verpasst, so dass sie entweder weiterhin leer ist, eine Potion oder sogar zwei enthält.

Auf zu unserem ersten Punkt! Und direkt wirds schon etwas peinlich für mich, denn der Grundsatz des Makern lautet:
Bevor nicht alles geplant ist, wird der Maker nichtmal eingeschaltet!
Eine Regel, die wir bisher grundsätzlich missachtet haben, zumindest wenn man unser Kursprojekt als "richtiges" Spiel ansieht. Wer sich etwas in der Makerszene auskennt, oder regelmäßig in unsere Szenennews schaut, der weiß, dass zwar viele potentiell sehr gute Spiele angekündigt werden, aber merkwürdigerweise nie als Demo, geschweige denn als Vollversion erscheinen. Woran liegt das?
Dafür gibt es mehrere Gründe, von denen sich die meisten mit einer guten Projektplanung schon im Vorfeld beseitigen lassen.

Zu hohe Ziele
Bevor man mit einem Projekt startet, muss man sich im Klaren darüber sein, was man will. Soll es ein Action-Kampfsystem sein, oder ein Sideview-KS? Oder doch das Standard-Maker KS? Will ich ein eigenes Menü einbauen? Sollen alle Grafiken selbstgezeichnet werden?
Diese Fragen stellen sich leider viel zu wenige, was man sich täglich in den Makerforen anschauen kann. Tausende von Features, eins schöner als das andere werden da den zukünftigen Spielern versprochen, meist von Leuten, die den Maker seit einer Woche besitzen und sich noch Fragen, warum man für SNES Rollenspiele Variablen nach x auflösen muss und was die "Gabel Bedingung" soll. Es empfielt sich grundsätzlich, vor dem Beginn mit dem ersten eigenen Spiel, die Zeit zu investieren, sich wirklich mit der Technik des Makers vertraut zu machen. Man muss sich realistische Ziele setzen, die technisch realisierbar sind und nicht einen schlichten Wunschzettel mit lauter "coolen Sachen" die man unbedingt haben muss. Übrigens etwas, von dem sich heutzutage viele Leute einfach zu sehr beeinflussen lassen, ist der Aberglaube, dass ein Spiel ohne geniale Grafiken und umwerfende Features nicht gut sein kann. Dies ist schlichtweg falsch, und wird von diversen Spielen, zum Beispiel "A Blurred Line", einem Sci-Fi Abenteuer mit teilweise GRÄSSLICHEM Mapping, widerlegt. Keiner wird euch den Kopf abhacken, wenn ihr ein storytechnisch geniales RPG auf die Beine stellt, dass das Standard KS benutzt. Selbst Alex als Held kann noch toleriert werden, wenn er ein intelligenter Charakter in einer von Intrigen und Krieg durchzogenen epischen Fantasystory ist.
Neben dem technischen muss bei der Zielsetzung auch das Ausmaß der Story beachtet werden. Wenn ihr eine Geschichte schreibt, die sich über einen Handlungszeitraum von zwanzig Jahren erstreckt, siebenunddreißig Hauptcharaktere samt ihrer Familien beinhaltet und in dreihundertfünfzehn Städten in neunundvierzig Ländern spielt, die alle ihre eigene Sprache sowie Architekturstile und Musikrichtungen haben, sitzt ihr wahrscheinlich ein Leben lang an eurem Spiel, außerdem bezweifle ich, dass ihr auch nur annähernd mit den 5000 Switches und Variablen auskommt. Eine komplexe Story ist gut. Eine komplexe Story, an deren Umsetzung ihr ewig sitzen würdet nicht.
Bei der Frage der Ressourcen ist es im Grunde ähnlich bei der Technik. Wer ein Spiel macht, das halbwegs erstgenommen werden soll, kommt einfach nicht drum rum, an irgendeinem Punkt selbst Hand anlegen zu müssen (zeichnerisch, natürlich ^^).
Da mag es noch so viele Objekte und Charaktere mit vorgezeichneten Posen geben, aber irgendwas fehlt immer. Prinzipiell ist das Zeichnen von Sachen gar nicht so schwer. Selbst grafischen Nieten wie mir gelingt es mit etwas Übung, die Haare von Charsets umzufärben, oder dem Charakter ein Schwert in die Hand zu pixeln (sogar mit Hau-Drauf-Pose! xD). Schwieriger wirds dann schon, wenn der Charakter einen Dämon hinaufbeschwören soll, oder vom Dach eines Hochhauses springt und sich im Fall geschickt an einem Fahnenmast festhält und sich in ein offenstehendes Fenster hineinhangelt. Kurzum: Wenn ihr actiongeladene Szenen ansprechend darstellen wollt, oder die Charaktere zum Beispiel im Kampfsystem verwenden wollt, solltet ihr mit Zeichenprogrammen vertraut sein, und einiges an Geduld mitbringen. Die Steigerung des ganzen ist übrigens das futuristische RPG, ein Genre, in dem ihr so gut wie alleine darsteht. Ich spreche hier aus Erfahrung und kann sagen, dass das komplette Neu-zeichnen von Chipsets kein Zuckerschlecken ist. So interessante Geschichten ihr euch auch schon ausdacht haben mögt, wenn ihr nicht wirklich massig Motivation, Zeit und eine gute Portion Können und Talent mitbringt, möchte ich euch von diesem Genre erst einmal abraten.

Keine vernünftige Organisation

Ordnung ist das halbe Leben, ein Spruch, der zumindest beim Rpg-Maker gilt. Die meisten Projekte scheitern daran, dass ihr Ersteller die Lust an ihnen verliert und sie entnervt aufgibt. Dies kann einmal daran liegen, dass er, wie im vorherigen Punkt erläutert, seine Pläne nicht vernünftig umsetzen kann und immer wieder zu halbherzigen Ersatzlösungen greifen muss, bis er schließlich vollkommen unzufrieden ist, oder vor eine Grenze kommt, die sich eben unmöglich umgehen lässt. Der andere Punkt ist, dass er den Durchblick in seinem eigenen Projekt verliert. Wenn man an den Punkt kommt, an dem man stundenlang nach einem bestimmten Chipset sucht, dass doch irgendwo auf dem PC sein muss, oder ums Verrecken nicht das Event findet, welches für eine bestimmte Szene wichtig ist, dann ist es meistens schon zu spät. Der sicherste Weg, dies zu vermeiden, ist von Anfang an organisiert vorzugehen, und vor allem - im Voraus zu planen!
Wenn man sich vor Beginn mit dem Spiel Gedanken über die Handlung, die Charaktere, die Technik usw. macht, dann weiß man doch, was man später einmal braucht. Wenn man ein Spiel in einer mittelalterlichen Welt macht, und die Handlung die Party durch Berggegenden über Schlösser und Klöster durch verlassene Höhlen und einsame Wälder führt, dann kann man die Chipsets dafür doch schon suchen. Weniges ist ärgerlicher, als mittem im Spiel herauszufinden, dass der zentrale Handlungsort der Story nicht umsetzbar ist, weil das nötige Chipset fehlt. Ähnlich bei anderen Aspekten, wie zum Beispiel der Musik oder den Charaktersets. Wenn man sich schon vor Spielbeginn einen großen Vorrat mit Sets, die man brauchen könnte (lieber zwei zuviel, als eins zu wenig) beschafft und geordnet auf der Festplatte sammelt, muss man später nicht wertvolle Zeit mit Suchen verschwenden. Ordnung ist auch in der Database des Makers ungeheuer nützlich. Wenn man Events schon zu Beginn ordnet, also meinetwegen Event 0001 bis 0050 für Schwerter, 0055 bis 0105 für Bögen, 0110 bis 0210 für Rüstungen usw., hat man später den blitzschnellen Überblick. Gleiches gilt für Variablen und Switches, vor allem, wenn größere technische Vorhaben wie Kampfsysteme und Menüs mit im Spiel sind.
Und auch, wenn man dann endlich mit dem Makern anfängt, ist es mit der Ordnung noch lange nicht vorbei. Zu aller erst sollte man sich Gedanken darüber machen, in welcher Reihenfolge man sein Spiel angehen will. Ich will hier nicht behaupten, ein Patentrezept zu haben, aber grundsätzlich ist es sinnvoll, technische Sachen schon vor Beginn der Arbeit am eigentlichen Spiel zu regeln. Einmal hat man dann noch einmal die Probe, ob man auch wirklich in der Lage dazu ist, seine Ideen zumindest im technischen Bereich umzusetzen, außerdem kommt man dann nicht in die unangenehme Situation (die mir übrigens sehr vertraut ist =P), Platzhalter für technische Sachen einsetzen zu müssen. Also nach dem Motto "Wenn das KS fertig ist, kommt hier jetzt ein Bosskampf" oder "Hier müsste man jetzt eigentlich mit der Chemielabor-Funktion diese beiden Items kombinieren, mach ich dann später."
Auf die Frage, in welcher Reihenfolge man jetzt fortfährt, wird man die unterschiedlichsten Antworten erhalten. Ich selber gehe lieber nach dem Map-für-Map-Verfahren fort, dass heißt, ich mappe eine Karte, dann setze ich NPC's, dann schreibe ich Dialoge, mache die nötigen Events, ab zur nächsten Map. Genau betrachtet ist dies eigentlich kein besonders effizientes Verfahren. Wenn man sich ausreichend Gedanken über sein Spiel macht, weiß man schließlich, was man will und es ist praktischer, erstmal einen ganzen Ort samt Häusern zu mappen, bevor man diese untereinander verknüpft und mit Leben füllt. So kann man sich besser auf eine Tätigkeit konzentrieren, anstatt ständig von einer Punkt zum nächsten springen zu müssen.
Weiterhin sollte man darauf achten, den Events (vor allem den NPCs) immer Namen zu geben, damit dann nicht später bei Move Events das große Chaos entsteht. Dass man die Struktur im Map-Tree logisch anlegen sollte, erklärt sich ja von selbst.
Wer die Maps nach dem Schema "Schloss(Erdgeschoss(Zimmer 1(Zimmer 2(1. Stock(Flur(Zimmer 1(Dach(Keller))))))))" anordnet, findet später natürlich nichts wieder. Ebenso kompliziert wird das ganze, wenn man die Maps nicht unterordnet, sonder alle auf der gleichen Ebene hat, da kann das Suchen nach der richtigen Karte auch zur Dauerbeschäftigung werden. Also eine Anordnung: "Schloss(Erdgeschoss(Zimmer 1, Zimmer 2), 1. Stock(Flur(Zimmer 1, Hinterzimmer), Abstellkammer), Dach)".

Keinen Überblick über die Story
Fast genauso schlimm, wie wenn man mittem im Spiel feststellt, dass die Technik einfach nicht hinhaut, ist es, wenn man merkt, dass man nicht weiß, wie es jetzt weitergehen soll, oder worum es eigentlich momentan geht. Ich kann mir zwar kaum vorstellen, dass aus diesem Grunde besonders viele Spiele gecancelt werden (nunja, mein erstes Spiel ist genau deshalb gestorben, ich hatte einfach drauflos gemakert), aber mangelnde Organisation im Storybereich ist sicherlich verantwortlich für eine große Zahl von langweiligen und einfach schlechten Spielen. Die Frage nach einer guten Story werde ich versuchen, im nächsten Kapitel zu beantworten, aber auch hier ist bei der Organisation einiges zu beachten. Unverzichtbar sind Stift und Notizblock (bzw. Tastatur und Notepad), um sich die Story zu notieren. Ein kleiner Vorgang, den sich einfach zu viele Leute sparen. Je komplizierter das ganze, desto härter wird es, den Überblick zu behalten. Es ist keine Schande, wenn ihr auf Anhieb mal nicht das Alter oder den Nachnamen eines der Charaktere wisst, aber katastrophal wird es, wenn ihr das dann nirgendswo mehr nachlesen könnt, und sich so sogar Fehler ins Spiel einschleichen. Wenn es in eurer Spiewelt 12 wichtige Gottheiten gibt, müsst ihr sie nicht auswendig beim Namen kennen, doch wenn dann abwechselnd von 8 und 13 Göttern die Rede ist, wirds peinlich. Wer sich also vor Spielbeginn die Zeit nimmt, ausführlich die Welt (samt Kultur, Rassen, wichtigen Städten, Kontinenten, Bräuchen etc.) und die Charaktere (Profil, Geschichte, Rolle in der Story - nicht nur bei Helden!) niederzuschreiben, der bringt mit größerer Wahrscheinlichkeit ein gutes Spiel zustande. Außerdem wichtig sind ein kompletter grober Handlungsablauf (noch ohne große Detail, Sidequests usw.) und detailliertere Abläufe für Kapitel/Abschnitte, um sich ein Bild über den Umfang des Spiels machen zu können und "was noch alles kommt". So lassen sich Überraschungen wie "Oh, jetzt bin ich ja irgendwie schon fertig... dachte das Spiel würde länger werden." oder "Was war jetzt eigentlich die Handlung des Spiels?" vermeiden, und man kann besser beurteilen, ob die Spieler später einmal den Überblick über das Ganze behalten werden. Bei einem guten Spiel sollte sich nie die Frage "Was mache ich hier überhaupt?" stellen.
Wenn man sich in der Planungsphase befindet, ist es durchaus zu empfehlen, ständig ein Zettelchen und einen Stift mit sich zu führen. Fast jeder kennt die situation: Man ist irgendwo unterwegs und ganz plötzlich kommt einem eine (scheinbar xD) geniale Idee. Doch wenn man dann zu Hause ist, um das Ganze umzusetzen, hat man sie wieder vergessen. Dies passiert öfter als man denkt und gerade wenn man noch zur Schule geht, ist die Chance besonders hoch, dass einem während die Gedanken so schweifen die tollsten Ideen kommen. Aber nur nicht beim Bekritzeln des Mathehefts mit denselbigen erwischen lassen ;D
Die gesammelten Ideen lassen sich so auch viel besser einem Freund präsentieren, etwas was man immer tun sollte, um unabhängige Meinungen über Story und Charaktere einzuholen, da man manchmal einfach nicht selbst einschätzen kann, was gut ist und was nicht.

Um wieder auf den Anfang, also das Kursprojekt zurückzukommen: Ihr seht, wenn man ein eigenes Spiel angeht, dann sollte man das keinswegs so tun, wie wir es mit dem Kursprojekt gemacht haben. Wenn man aber nur die Technik erlernen will, ist eigentlich nichts daran auszusetzen.

Dies ist eine Frage, die sich jeder unbedingt stellen muss, bevor er sein erstes eigenes Rollenspiel angeht. Viele technisch und grafisch guten Spiele scheitern einfach an einer miesen Story (man siehe nur einen Großteil der Ego-Shooter, die heutzutage veröffentlicht werden und bei denen eine Story schon nicht einmal mehr Nebensache zu sein scheint). Ich bezweifle, dass es auf diese Frage nur eine richtige Antwort gibt, bzw. eine perfekte Antwort. Ich werde versuchen, meine Ansichten darüber, was eine gute Story ausmacht, zu erläutern, ob ihr euch daran halten wollt, ist eine ganz andere Sache. Euch muss nur klar sein, dass ein Hauptziel ist, die Spieler zum weiterspielen zu motivieren, d.h., das Spiel muss spannend bleiben. Die Frage, die deshalb unweigerlich mit unserer Oberfrage verbunden ist lautet:
"Wie baue ich Spannung auf?" Dazu einige Methoden:

Action
Wer ein Kinofan ist, und sich gerne mal den neuesten Hollywoodstreifen ansieht weiß: Nichts ist kurzweiliger als Action. Wilde Verfolgungsjagden, rasante Kameraschwenks, Explosionen, Schießereien, Flucht vor Lawinen, zusammenstürzende Tempel, Weltraumschlachten, und und und...
Actionsequenzen sind das Herstück vieler Filme und ein ständiger Spannungsgarant. Das gleiche gilt natürlich auch für Computerspiele, also Rollenspiele. Kaum ein Spieler wird gähnend Alt+F4 drücken, wenn er unter Zeitdruck eine zusammenbrechende Höhle verlassen muss, knapp an der HP-Grenze gegen den Endboss kämpft oder den Pfeilen der verfolgenden NPCs ausweichen muss. Aufgrund der mangelnden 3-Dimensionalität des Makers hinkt der Vergleich mit Filmen etwas, aber Spannung durch Action lässt sich trotzdem auf vielen Wegen im Maker umsetzen. Wichtig ist nur, dass einem klar ist, dass ein Spiel nicht dadurch spannender wird, wenn man alle 3 Sekunden Zufallskämpfe bestreiten muss.
Zeitdruck lässt sich zum Beispiel ausgesprochen leicht umsetzen. Im Event Editor gibt es nämlich die nützliche Funktion "Timer Operations", und damit habt ihr eigentlich schon alles, was ihr braucht. Mit "Set Timer" könnt ihr eine bestimmte Zeit setzen, die dann im Sekundentakt abläuft, wenn ihr "Start Timer" auswählt. Ihr könnt dem Spieler die Zeit anzeigen lassen oder auch nicht, und bestimmen, ob sie in Kämpfen (Achtung: gilt natürlich nur für das Standartkampfsystem) weiterläuft. Mit "Stop Timer" könnt ihr den Timer anhalten und mit dem Befehl "Clear Timer" (der befindet sich allerdings auf seite 3 der Event Befehle und nicht unter "Timer Operations") kann man den Timer wieder auf 0 runtersetzen.
Damit dann auch was passiert, wenn der Timer abgelaufen ist (sonst wär er ja für nix gut xD) könnt ihr mit einer Fork Condition in einem Parallel Process Event abfragen, ob die Zeit schon bei 0 Sekunden ist, und dann ein bestimmtes Ereignis auslösen.
Action und rasante Handlung lassen sich natürlich immer noch am besten in Zwischensequenzen regeln, also Abschnitten, in denen der Spieler mal die Finger von der Tastatur nehmen kann um sich auf die Handlung zu konzentrieren =D
Oft gilt hier: Je mehr gleichzeitig passiert, desto realistischer wirkt das ganze. Wenn zwei befeindete Gruppen gegeneinander Kämpfen sollen, warten der Held und der gegnerische Boss nicht erst, bis sich die anderen Leute der Reihe nach gegenseitig bewusstlos kloppen, sondern legen logischerweise auch direkt los. Damit man beim Erstellen von solchen Szenen nicht den Überblick verliert, sollte man die einzelnen "Unterhandlungen" in verschiedene Events packen, und der Reihe nach machen. Soll heißen, zuerst machen wir das Startevent, in dem der spieler die Kontrolle abgibt und vielleicht erstmal ein wenig geredet wird, bevor die Action beginnt. Dann schalten wir einen Switch an. Nun machen wir ein Parallel Process Event, das bei diesem Switch startet. Darein kommt dann wie Held 2 eine Granate auf Gegner 4 wirft, dieser zu Seite hechtet, Held 2 nach vorne stürmt und von Gegner 4 mit einer Keule zu Boden geschlagen wird, worauf er einen Schritt zurück geht und dann Gegner 4 bei dessen Ansturm aufspießt. Zwischendurch explodiert mit einer netten Animation noch die Granate vom Anfang. Neues Event, Held 3 zückt seine Armbrust während Gegner 2 und 3 auf ihn losrennen. Er springt zurück und schießt, trifft Gegner 2, der zu Boden geht. Gegner 3 läuft weiter auf ihn zu und Held 2 schmeißt die Armbrust weg und zieht im gleichen Moment einen Dolch, doch wird vom Schwert von Gegner 3 erwischt und fliegt drei Meter in die Tiefe, bleibt bewusstlos liegen. Drittes Event, Held 1 und Gegner 1 zücken die Säbel und dreschen gegenseitig auf sich ein, bewegen sich etwas vom Geschehen fort. Neuer Switch an, Kampf geht weiter, bis Held 1 schließlich Gegner 1 fertig macht. Wenn der Switch angeschaltet wird, wenden sich Gegner 3 und Held 2 einander zu und Gegner 3 wird im Lauf von einer weiteren Granate erwischt.
Die ganze Sequenz sollte dann am Ende parallel laufen und einen chaotischen aber spannenden Eindruck erzeugen. Wichtig ist nicht unbedingt, dass der Spieler jede Bewegung mitbekommt, sondern, dass der Gesamteindruck stimmt.

Rätsel
Damit meine ich natürlich nicht Kisten-Verschiebe- oder Schalterrätsel, sondern Geheimnisse, Unklarheiten etc., eine, wenn richtig angewandte, sehr gute Methode um Spannung zu erzeugen. Eine Möglichkeit, solche Rätsel in die Story einzubauen, hatten wir schon in einem der vorherigen Teile, als es um das Intro für ein Spiel ging. Damals nannte ich die Möglichkeit "Das mysteriöse Ereignis" und es ging um eine bestimmte Szene oder einen Handlungsabschnitt, in dem der Spieler nicht weiß, was vor sich geht. Solche Szenen kann man natürlich nicht nur im Intro gebrauchen, sondern überall im Spiel. Einmal ein kurzes Beispiel: Die Gruppe um Alex und Deji hat von eim alten Mann den Hinweis bekommen, dass ein Dämon die Stadt Icksdorf unsicher macht, und man ihn besiegen kann, wenn man vorher in einer Höhle drei heilige Siegel mit dem Schwert des Auserwählten bricht (das sich rein zufällig in Alex' Besitz befindet). Schön und gut, Alex und Deji gehen in die Höhle, plätten alle Monster, brechen die Siegel und besiegen den Dämon, worauf sie sich fröhlich einen saufen gehen. Szenenwechsel in einen dunklen Raum mit zwei verhüllten Gestalten (! xD). A: "Der Plan schreitet fort, mein Gebieter." B: "Der Vogel ist im Nest?" A: "Ja, die Schranke ist gebrochen!" B: "Wohlan, dann möge der Bär nun den Honig suchen!" A: "Wie Ihr befehlt, mein Herr." Dieser (jetzt mal absichtlich lächerlich klingende xD) Dialog ist natürlich erst einmal total unverständlich. Aber er zeigt, wenn er seinen Zweck erfüllt, dem Spieler, dass die Dinge nicht ganz so einfach sind wie sie scheinen und dass die Geschichte noch lange nicht vorbei ist. Optimal sollten derartige Szenen den Spieler immer wieder zum Weiterspielen motivieren und ihm ein Ziel geben, nämlich hinter die Geheimnisse zu kommen und alle Rätsel zu lösen.
Es gibt natürlich noch viele weitere Möglichkeiten, dem Spiel etwas Mysteriöses zu verleihen. Zum Beispiel kann man von Zeit zu Zeit immer wieder einen bestimmten Charakter auftauchen lassen, der dem Held aus der Patsche hilft und kryptische Bemerkungen von sich gibt, dessen Motivationen aber erst ganz am Ende des Spiels klar werden. Ebenso könnte man den Helden ein mysteriöses Objekt mit sich tragen lassen, hinter dem diverse Parteien her sind, dessen Funktion aber unbekannt ist usw. Ihr seht, eurer Fantasie sind da kaum Grenzen gesetzt. Um noch einen weiteren Weg zu gehen, dem man dieser Rubrik hier zuschreiben könnte: Prophezeiungen. Der Gebrauch von uralten überlieferten Prophezeiungen oder einem Charakter der in die Zukunft schauen kann, kann ein Spiel erheblich interessanter Gestalten. Auch hier muss man behutsam vorgehen. Prophezeiungen wie "Am 3. August wird Otto, der Auserwählte, um drei Uhr den bösen Drachen Kuno töten" sind nicht zu empfehlen; höchstens wenn es schon zwei Uhr ist und der böse Drache Kuno noch gar keinen Auftritt hatte, könnte sie zur Spannung beitragen. Da empfiehlt sich "Ich sehe ein Boot, mit drei Männern. Sie rudern, aber das Boot bewegt sich nicht von der Stelle... Egal wie stark der Vordermann rudert, die beiden Anderen steuern ohne dass er es merkt dagegen an." als Hinweis auf Verräter innerhalb der Gruppe schon eher. Alternativ kann man auch als vorrübergehendes Ziel die Erfüllung einer alten Prophezeiung verwenden. So will der Held vielleicht ein Volk von Buschleuten zum organisierten Widerstand gegen die Microsoft Inc. aufrufen, aber sie weigern sich, da in ihrer heiligen Schrift steht, dass sie niemandem folgen dürfen, bis nicht der Mond vom Himmel fällt und die Sterne am Tage zu sehen sind. Dann muss der Held sich eine Atombombe organisieren um den Mond zu sprengen und.... eh, ich schweife ab, aber ich denke es wird klar, was ich sagen wollte XD

Storywendungen
Storywendungen dürfen in keiner guten Story fehlen, tun es leider aber in viel zu vielen ^^;
Wie immer gilt, solange was passiert, ist Spannung da und der Spieler ist motiviert, weiter zu machen. Und gerade große Ereignisse in der Story tragen oft einen guten Teil dazu bei. Ich nehme jetzt mal als Beispiel Final Fantasy 7 und wers nicht gespielt hat, der hat halt Pech gehabt =P: Ein Mitglied der Party, Cait Sith ist in Wahrheit ein Spion der bösen Shinra Inc. Dies weiß der Spieler natürlich nicht und nimmt ihn in die Gruppe auf. Zusammen laufen sie durch die Gegend, lösen Sidequests und haben viel Spaß zusammen. Eines Tages suchen sie ein bestimmtes Objekt (schlagt mich, ich hab vergessen was... ich glaube einen Schlüsselstein), hinter dem auch die Shinra Inc. her ist. Kaum haben sies gefunden, klaut Cait Sith es und eine Verfolgungsjagd durch einen Vergnügungspark beginnt, bis Cait Sith schließlich eingekesselt wird. Er gesteht den anderen, dass er ein Spion ist und droht damit, die Tochter eines Partymitgliedes töten zu lassen (omg!) wenn sie ihn nicht laufen lassen. Ta-daa! Das war ein sehr gutes Beispiel. Auch wenn Cait Sith nicht gerade eins der charismatischsten Partymitglieder war, so hätte man doch nicht mit so etwas gerechnet. Diebstahl! Geiselnahme! Verrat!! An der Stelle wird wohl kaum jemand daran denken, den Controller beiseite zu legen und lieber Hausaufgaben zu machen - nein, man will natürlich hinter her, das Objekt zurückhaben, es dem Verräter heimzahlen und die Welt retten.
Verrat eignet sich deshalb fast immer hervorragend (mehr dazu später). Weitere häufig verwendete Aufhänger für Storywendungen sind das plötzliche Versterben von Charakteren, übrigens wie in der Klischee-Storywendung #1: Held lebt mit Eltern im Dorf, friedlich. Eines Tages kommt der dämonische Dämonen-Dämon Satan und tötet die Eltern (wieso auch immer), worauf der Held auszieht um die Welt zu retten was er dann tut. TEH END!
Wieso die Story schwachsinnig ist, muss ich wohl niemandem erklären, aber wenn es sie nicht schon 24435 mal gäbe, würde die anfängliche Storywendung wahrscheinlich sehr zur Spannung beitragen. Außerdem kann man jederzeit eine Alien/Orkinvasion zum Anlass für gravierende Veränderungen in der Geschichte nehmen; lasst eurer Fantasie freien Lauf =D

Damit hätten wir die Hauptmöglichkeiten zur Erzeugung von Spannung in einem Spiel geklärt (zumindest fallen mir auf Anhieb keine weiteren ein). Aber eine Frage steht natürlich noch offen: Zu welchen Zeitpunkten sollte ich sie in mein Spiel einbauen?
Dabei kann man am besten mit einer sogenannten Spannungskurve arbeiten. wer ab und zu mal die PC Games liest, der wird wissen, dass dort bei größeren Tests zu Spielen in der wertung immer eine Motivationskurve zu sehen ist, die unserer Spannungskurve ziemlich ähnlich ist. Dort wird zu mehreren Zeitpunkten angezeigt, wie groß die Motivation, an dieser Stelle weiterzuspielen, ist. Das liest sich dann zum Beispiel "1 Stunde (5 Punkte): Riesige detaillierte Spielwelt voll mit interessanten Charakteren wartet auf erkundung durch den Spieler; 3 Stunden (4 Punkte): Größtenteils spannender Hauptquest schickt Spieler von Ort zu Ort, viele mögliche Aufgaben; 7 Stunden (1 Punkt): Mühsames Aufleveln für langweilige Aufgaben, keine Abwechslung gegeben; 15 (2 Punkte): Schlapper Schlussdungeon mit interessantem Endgegner, aber viel zu leicht". So sollte es optimal aber nicht aussehen. An Stelle dieser Kurve sollte es eine grundsätzliche Aufwärtsbewegung geben, aber wellenförmig. Soll nicht heißen, dass es die ersten 5 Stunden schnarchlangweilig sein soll, damit es später spannender werden kann, sondern dass sich die Story von einem Höhepunkt zum nächsten bewegt: "Party kommt in Dorf, Mädchen wurde entführt. Party rettet Mädchen vor Entführern und kommt zurück, große Feier. Dorf wird von Banditen überfallen und Party stellt Widerstand auf die Beine, Endkampf gegen Banditenboss. Party reist weiter und gerät ins Kriegsgebiet. Held wird zum Anführer der Streitmächte von Land A und plant Feldzug gegen Land B. Große Schlacht. Es stellt sich heraus, dass der Krieg von Land C eingefädelt wurde, dass nun die geschwächten Länder A und B invadieren will. Held schließt Frieden mit Land B und zusammen wird die Invasion von Land C gestoppt und böse gegnerische Fürst erledigt. Aus."
Auch wenn das natürlich keine perfekte Story ist, so wird sie doch mit der Zeit immer "größer", epischer und spannender, mit jeder Menge Action und auch einer größeren Storywendung im späteren Verlauf, die dann zum absoluten Höhepunkt der Geschichte führt. Wenn ihr es schafft, dass die Spannungskurve eures Spiels ungefähr so aussieht, dann habt ihr schonmal einen großen Schritt in Richtung eines guten RPGs geschafft.

Der nächste wichtige Faktor in einer guten Story sind die Charaktere. Ein Spiel lebt von seinen Charakteren, genau wie das bei Büchern und Filmen der Fall ist. Wenn die Gruppe aus hirnlosen Vollidioten besteht, deren einzige Absicht es ist, alles plattzuhauen was ihnen in den Weg kommt, dann hätte sich der Ersteller lieber an einem Mulitplayer Ego-Shooter als an einem Rollenspiel versuchen sollen, und das wird ihm in den meisten Fällen dann auch von den Spielern, die nach einer Viertelstunde keine Lust mehr hatten klargemacht.
Charaktere eines Spieles sind aber in erster Hinsicht nicht das Produkt von Tippbewegungen auf der Tastatur des Spielers, sondern "Menschen" (oder Elfen, Zwerge, Monster, was auch immer). Menschen denken und handeln meist nicht ohne Grund. Sie sind bis zu einem gewissen Grade intelligent und haben ihre persönlichen Eigenschaften, Ziele und Motivationen, die sich in ihren Handlungen und Dialogen wiederspiegeln sollten. Bevor man also bei Dialogen wild drauf los schreibt, um eine möglichst kurzweilige Unterhaltung zu Stande zu bringen und vielleicht den ein oder anderen Witz zu reißen, sollte man darüber nachdenken, ob die geplante Unterhaltung überhaupt zu den Charakteren passt, zwischen denen sie stattfindet. Nehmen wir an in der Planungsphase unseres Spieles haben wir die Charaktere Gertrud und Hans-Dieter konzipiert. Gertrud ist eine offene, junge Bauerstochter, die in ihrer Freizeit gern mit Tieren spielt, malt und kleinen Kindern das Einmaleins beibringt. Sie hat Angst vor allem, was Lärm macht und groß ist, außerdem fürchtet sie sich im Dunkeln, wenn sie allein ist oder in besonders großen/kleinen Räumen. Hans-Dieter ist ein hartgesottener Söldner, dessen Vater ihn mit drei Jahren an die Fremdenlegion verkauft hat, wo er bis zu seinem sechzehnten Lebensjahr dreimal täglich die Toiletten mit einer Nagelschere reinigen musste und er für jedes Wort, das seinem Mund entfuhr fünf Stunden lang ausgepeitscht wurde.

Nun ist Hans-Dieter mit dem Auftrag unterwegs, das böse Tentakelmonster Hrutzkar in einer nahegelegenen Höhle zu töten und seinen Kopf auf einem 2 Meter langen Eisenspieß zu pfählen, den er mit sich rumträgt. Er kommt also am Hof von Gertrud vorbei und will wissen, wo er lang muss.

Schlechtes Beispiel:
Hans-Dieter: (trägt Eisenspieß in der einen Hand, geht auf Hof zu, wo Gertrud gerade mit den Hühnern fangen spielt) Hallo! Wo gehts denn hier zur Höhle vom Tentakelmonster?
Gertrud: (dreht sich um und kichert) Was für ein riesiger Spieß! Wollt Ihr den alten Hrutzkar aufspießen?
HD: Oh ja, das ist mein Auftrag, junge Dame. Aber ich habe mich verirrt. (kratzt sich am Kopf)
Gertrud: Wartet, ich komme mit und zeige Euch den Weg!
HD: Haha, das ist ja Spitze!

Gutes Beispiel:
Hans-Dieter: (Geht auf Gertrud zu, die gerade mit den Hühnern fangen spielt und rammt den Eisenspieß in den Boden) Grunz.
Gertrud: (springt auf, dreht sich um, reißt furchterfüllt die Augen auf und stolpert nach Hinten) W-w-was k-kann Ich f-f-für Sie tun, w-w-werter H-herr?
Hans-Dieter: (grunzt) Wo's hier die Höhle in der das scheiß Drecksvieh namens Hrutzkacke oder so leben soll?
Gertrud: (weicht ängstlich auf allen Vieren zurück) W-w-w-wie bitte?
HD: Hrutzkar, das verdammte Tentakelmonster. Ich will das Mistding hiermit aufspießen. (reißt Eisenspieß hervor und richtet ihn auf Gertrud.)
Gertrud: HILFEEEEEEEEEEEE!!! (rennt um ihr Leben)
HD: (schüttelt den Kopf) Ich hasse Frauen.

Wie man am zweiten Beispiel sehen kann, können sich so ganz schnell Probleme ergeben. Die beiden Charaktere handeln zwar genau richtig, d.h. die Szene ist auch wirklich realistisch, im Gegensatz zur ersten, aber den Weg hat Hans-Dieter noch immer nicht gefunden. Man sieht also mal wieder, dass eine genaue Planung praktisch ist, man aber durch gründliches Dialogeschreiben und so weiter noch mal eine weitere Chance zur Überprüfung der Story habt. Bevor man hier jetzt einen Kompromiss eingeht, und die charaktere um Willen des Storyfortschrittes wie in Beispiel 1 reden lässt, oder sie gleich ganz umschreibt, kann man einfach noch einen neuen Charakter hinzufügen, zum Beispiel Gertruds Opa, der sich nicht so leicht einschüchtern lässt und seine Enkelin dazu überredet, Hans-Dieter zur Höhle zu führen (wenn es denn für die Story notwendig sein sollte, dass die beiden zusammen losziehen).
Durch die realistische Anwendung von Charakterzügen kann ein Spiel also interessanter und vielfältiger werden, aber bei ungenauer Planung kann es schon mal geschehen, dass die Story so ein Eigenleben entwickelt und sich am Ende zu etwas völlig anderem entwickelt als ursprünglich geplant.
Außerdem muss man immer die Motivationen der Charaktere im Auge behalten, vor allem wenn es darum geht, dass sich ein neues Mitglied der Gruppe anschließt. Schließlich sollte man schon einen guten Grund haben, wenn man sich dazu entschließt, sein bisheriges Leben (Haus, Familie, etc.) hinter sich zu lassen, um mit einer Gruppe von Abenteurern durchs Land zu ziehen und sein Leben zu riskieren. Wenn ein Land von einem Tyrann regiert wird, ist in der wirklichen Welt kaum jemand mutig genug, um aktiv etwas dagegen zu unternehmen. Selbst wenn einem das eigene Leben nicht allzu viel wert sein sollte, steht doch immer die Gefahr für die Angehörigen im Hintergrund. Ein schlichtes "Mir gefällt das System nicht" reicht eben nicht bei jedem Typ von Charakter als Grund, sich der Gruppe anzuschließen. Motivationen spielen auch beim oben genannten Verrat eines Charakters eine große Rolle. Wenn er die Gruppe verrät steht er also auf der anderen Seite. Wieso? Warum kämpft er nicht für die Sache der Gruppe? Was hat er davon, sich "Undercover" einzuschleusen? Unter welchem Vorwand schließt er sich der Gruppe an? Ist er vom Charaktertyp her überhaupt in der Lage, seine Rolle überzeugend zu spielen?

Jetzt komme ich wieder ein bisschen auf die Planungsphase zurück, auch wenn der Bezug zur richtigen Umsetzung des Charakters noch da ist: Wie mache ich meine Charaktere realistisch?
Dazu sollte man sich einmal über die Natur der meisten Menschen Gedanken machen. Vollkommen gute oder vollkommen böse Menschen existieren eigentlich nicht. Überspitzt ausgedrückt hat wohl selbst ein Mädchen, dass sich in ihrer Freizeit ehrenamtlich für Behinderte engagiert und ihr gesamtes Taschengeld an Brot für die Welt spendet, schon mal mit ihrer besten Freundin über jemanden gelästert. Die richtige Welt ist nicht schwarz/weiß sondern grau. Viele Menschen sind bestechlich auf die Frage, ob man einen Mord begehen würde, wenn garantiert wäre, dass dieser nicht auffliegt, würden wahrscheinlich mehr Menschen mit ja antworten, als man sich im ersten Moment denkt. Sicher darf man seine Charaktere etwas auf einen bestimmten Typ festlegen, und keiner wird es einem übel nehmen, wenn der Held ein rechtschaffener gut aussehender Soldat ist, der Unrecht nicht ausstehen kann und für seine eigenen Ideale kämpft. Moment, warum ist er dann Soldat geworden? ;)
Aber eben darum muss man sich auch bei den Gegenspielern (die ich bewusst nicht Bösewichte nenne) über die Motive im Klaren sein. Der Endgegner in einem Spiel muss eben nicht unbedingt der machthungrige Möchtegern-Diktator sein, sondern ist vielleicht der überzeugte Forscher, der die Zerstörung der Erde vorraussieht, wenn das Problem der Überbevölkerung nicht bald gelöst ist und deshalb ein Virus entwickelt hat, das 90% der Bevölkerung auslöscht.

Neben den Charakteren ist für ein gutes storytechnisches Gesamtbild auch die Spielwelt von großer Bedeutung. Viele Spieleentwickler machen sich meiner Meinung nach leider viel zu wenig Gedanken darüber, wie ihre Welt funktionieren soll. Nehmen wir eine RPG-typische Welt. Technisches Level: Mittelalter. Magie: Ja. Elfen, Zwerge, Orks: Ja.
Der unerfahrene/übereilte Makerer legt jetzt einfach los. Der Held zieht los um dies und das zu machen, schließt sich mit einem befreundeten Zwerg und Elf zusammen, die er in einem der Nachbardörfer kennengelernt hat, zieht durchs Land. Sie treffen noch auf einen Zauberer, nehmen zusammen ein paar Orkdörfer auseinander und kommen in die Hauptstadt des Landes, wo sie dem König ihre Dienste anbieten, weil sie gehört haben, dass etwas gegen die drohende Gefahr des fiesen Erzmagiers im Norden unternommen werden soll.
Nicht vorhandene Motivationen der Charaktere lassen wir jetzt mal außer acht =P. Punkt 1: Wenn wir uns im Mittelalter befinden, dann befinden wir uns auch wirklich im Mittelalter. Der Held kommt vom Lande. Kann er Lesen und Schreiben? Nein! Da eine derartige Unfähigkeit aber oft im späteren Spielverlauf Probleme aufwerfen könnte, nehmen wir mal an, dass es in "unserem" Mittelalter normal ist, dass Kinder Lesen und Schreiben lernen, ob jetzt im Dorf oder in der Großstadt. Wo lernen sie das? In Schulen. Gibt es auf unserer Dorfmap eine Schule? Nein? Logikfehler! Einer der häufigste Logikfehler ist übrigens das Fehlen sämtlicher sanitären Einrichtung bzw. der Zwang, solche zu benutzen XDD. Spaß beiseite, weiter im Text. Er schließt sich mit seinen Elfen- und Zwergenfreunden aus dem Nachbardorf zusammen. Wohnen Elfen und Zwerge in Dörfern, zusammen mit Menschen? Wieso nicht? Achtung! Aus eigener Erfahrung sollten wir wissen, dass es manchmal schwer ist, unbekanntes oder andersartiges zu akzeptieren. Deshalb gibts hier in den meisten Restaurants ja auch keine gegrillten Heuschrecken oder rohen Fisch (welch Schande...). Konsequenterweise wirft sich die Frage auf, ob in unserer Welt jedermann so tolerant ist, dass Menschen, Elfen und Zwerge gemütlich untereinander leben. Jetzt kann man das einfach bejahen und fertig ist man, die ganzen interessanten Möglichkeiten achtlos beiseite geworfen. Wenn man den Gedanken weiterspinnt tun sich nämlich jede Menge Ideen auf (mir zumindest). Man könnte in den größeren Städten Elfen- bzw. Zwergenviertel haben, in denen der Held als Mensch gar nicht willkommen ist, man könnte sie extra in abgetrennten Dörfern leben lassen. Es kann radikale Vereinigungen geben, die für die Verbannung aller Nichtmenschen plädieren, es kann Diskriminierung und Hass vorkommen, Verbrechen und Brandstiftung, ... (ich weiß, dass das keine schöne Sachen sind, aber wer eine quietschbunte Welt mit Feen und knuffigen redenden Plüschtieren will, der sollte sich evtl. ein anderes Tutorial suchen)
Aber weiter im Text, nehmen wir an die drei Jungs sind alles Außenseiter und tolerant und haben schon seit vielen Jahren immer Spaß gehabt. Jetzt ziehen sie also los und treffen den Zauberer, der sich ihnen anschließt. Habt ihr einen alten Mann mit Rauschebart im Kopf? Ja? Keine Überraschung, aber mehr zum Thema Klischees später. Es gibt also Zauberer. Wie groß ist der Anteil von Zauberern in der Bevölkerung? Einer von zehn? Dann müssen aber auch wirklich viele vorkommen. Einer von Hundert, oder gar einer von Tausend. Wenn das der Fall ist, was macht der Zauberer dann einfach so in der Gegend? Man könnte meinen, dass der König irgendwie versuchen würde, die paar Zauberer, die es in seinem Land gibt, unter Kontrolle zu halten und vielleicht für militärische Zwecke etc. einzusetzen. Immer könnte so ein frei rumlaufender Magus ja nach Gutdünken Angst und Schrecken verbreiten, wenn ihm grad danach ist. Würde die nichtmagische Bevölkerung nicht aus Angst vor sowas versuchen, die Zauberer unter strikter Kontrolle zu behalten? Höchstwahrscheinlich.
Vielleicht kann aber auch jeder Zauberer werden, wenn er nur etwas Talent mitbringt und sich verpflichtet, mit dem Besuch der staatlichen Magierschule in den Dienst des Königs zu treten. Also nehmen wir mal an, dass es sich bei unserem Zauberer hier um einen staatlichen Zauberer handelt, der den Vorsitz über einen gewissen Landkreis hat, und sich da um das Wohl der Menschen kümmert. Jetzt braucht er also schon einen triftigen Grund, um mit der Gruppe mitzukommen, aber da wir das ja außer acht lassen, nehmen wir einfach mal an, dass er soeben zufällig einen Befehl vom König erhalten hat, innerhalb der nächsten Wochen zur Hauptstadt zu kommen. Von ihm kann die Gruppe dann auch gleich mal erfahren, dass im Norden das Reich des fiesen Erzmagiers ist. Nächste Frage! Wie sieht es in dem Reich aus? Wer wohnt da? Wohnen die freiwillig da, oder unter Terrorherrschaft des Magiers? Oder sind sie verhext? Kämpfen sie für den Erzmagier, wenn es zum Krieg kommen sollte, oder laufen sie fröhlich über? Und wieso genau droht Gefahr vom fiesen Erzmagier? Nur weil er fies sein soll, oder wurden ernsthafte Drohungen ausgesprochen? Könnte man sich nicht denken, dass die Geschichte vom fiesen Erzmagier nur ein Vorwand des eigenen Königs ist, im Norden einzumarschieren? Was ist eigentlich im westen, Süden und Osten? XD
Der nächste Punkt wäre also die Plättung des Orkdorfes. Wieso? Sind alle Orks grundsätzlich böse? Ist es nicht schwachsinnig anzunehmen, dass alle Orks grundsätzlich böse sind, weil die grüne Haut haben, für Menschen unattraktiv aussehen und eine andere Sprache sprechen? Dieser Punkt ist folglich der schwächste in der sowieso schon schwachen Story. Nehmen wir also mal an, dass die Gruppe beim Wandern in der Nähe des Dorfes von einer Gruppe Orks attackiert wird. Ist das Grund genug, zum Gegenangriff überzugehen? Sind die Helden, die wie vorhin festgestellt außerordentlich tolerant und freundlich sind, überhaupt in der Lage dazu, einen kaltblütigen Angriff auf ein harmloses Dorf zu starten, dessen Bewohner sich nur aufgrund vergangener Gefechte vor den Menschen fürchten? Glaubt denn wirklich jemand an die Gerüchte, dass die Orks nachts kleine Kinder stehlen um sie am Spieß zu braten? Wohl kaum. Orkdorf gestrichen, finito!
Nun kommt die Gruppe also in die Hauptstadt. Hauptstadt will was heißen, denn in der Regel (Canberra, Pretoria und Washington D.C. mal ausgenommen) ist die Hauptstadt auch die größte bzw. bevölkerungsreichste Stadt eines Landes. Nunja, wir befinden uns im (frühen) Mittelalter kurz vor der typischen Bevölkerungsexplosion und in unserem kleinen Königreich (wie groß soll es im Vergleich zu den anderen denn sein?) gibt es meinetwegen 30.000 Einwohner, von denen 2.000 in der Hauptstadt wohnen. Natürlich erwartet niemand, dass ihr 500 Häuser mappt, aber dann dürft ihr die Stadt auch nicht so darstellen, als ob sie komplett begehbar wäre. Meinetwegen kommt man zum Stadttor, in die Einkaufsstraße, zum Hotel und zum Palast des Königs. Als nächstes die Frage: was ist typisch für eine große Stadt. Einmal eben die vielen Leute. Worauf sich die Frage stellt, wieso Menschen überhaupt in einer Stadt wohnen? Natürlich teilweise zum Selbstschutz, sie leben hinter Stadtmauern die mit Soldaten bemannt sind. Aber ist die Kriminalität wirklich so hoch, dass man auf dem Lande nicht sicher leben kann? Oder ist es nicht viel mehr so, dass Familien in die Stadt ziehen, weil sie Arbeit suchen? Also muss es auch Fabriken/Werkstätten geben. Für Kleidung, Waffen oder sonstiges. Nicht jeder zehnte Einwohner einer Stadt kann Hufschmied sein, im Gegensatz zu einem 20-Seelen Dorf. Diese Fabriken müssen ja nicht unbedingt direkt vorkommen, aber sie könnten gut ein Teil der Hintergrundgeschichte sein. Weiter: Bekommt jeder, der in die Stadt geht, um lukrative Arbeit zu suchen, auch einen guten Job? Leider nein. Daraus folgt, dass es in großen Städten auch oft ein großes Arm/Reich-Gefälle gibt. Wenn ihr also die Einkaufsstrße mappt, denkt vielleicht mal drüber nach, einen Bettler in die Ecke zu setzen, oder ein kleines Mädchen, dass Zündhölzer verkauft ;D
Last but not least die Audienz beim König. Dem halbwegs realistisch-denkenden Menschen müsste jetzt eine Erkenntnis kommen: Kann ein normaler Bürger eines Landes, selbst wenn es nur 30.000 Einwohner hat so eben munter zum König reinspazieren und ihn mal auf ein Wort sprechen? Ja? Falsch!
An einem königlichen Hof muss man sich wahrscheinlich erst einmal an zehn verschiedenen Leute vorbeikämpfen, um zum König durchgelassen zu werden, der wahrscheinlich auch besseres zu tun hat, als den ganzen Tag lang in seinem Thronsaal auf Besucher zu warten.

Wenn ihr bei eurer Story all diese Fragen (bzw. die, die sich bei euch stellen) während des Spiels überzeugend beantworten könnt und sich keinerlei Probleme wie oben dargelegt auftun, dann kann ich nur sagen: Respekt.
Nur wenige Leute schaffen es, eine Story zu schreiben, die frei von jeglichen Logikfehlern ist. Alles in allem kann ich euch aber nur empfehlen: Bevor ihr euch an einer epischen Story versucht, solltet ihr welche kennen. Und dies geht natürlich am besten, in dem ihr Bücher lest, speziell Fantasybücher, wenn ihr es auf das klassische RPG-Genre abgesehen haben solltet. Wenn ihr die richtige Literatur verschlunge habt, dann solltet ihr ein ungefähres Bild davon haben, was gute Charaktere sind, was eine glaubhafte Spielwelt ausmacht und wie man passende Dialoge schreibt. Zum Thema umfangreiche und detaillierte Welt passt natürlich JRR Tolkien's Mittelerde/Valinor Sammlung, ein Detailreichtum der in Jahrzehnten entstanden ist =P

Dieses Kapitel ist eigentlich nur ein kleiner Nachschlag zum Vorherigen. Ich bin ja jetzt relativ detailreich darauf eingegangen, was eine gute Story ausmacht und in den meisten Fällen gilt, dass diese Punkte, wenn sie nicht beachtet werden, negativ auffallen. Zum Beispiel die Rubrik "Action". Wenn die fehlt, ist das Spiel schon fast zum Scheitern verurteilt. Ich als Spieler möchte nicht von Ort zu Ort zu Ort gehen, ohne das irgendwas passiert. Und da geht es ganz sicher nicht nur mir so. Wenn Langeweile aufkommt, dann hat das Spiel ganz eindeutig ein Problem, da brauche ich jetzt gar nicht mehr groß drauf eingehen.

Zum nächsten Punkt, Rätsel. Wie gesagt, Rätsel sind gut. Wenn ein Spiel mysteriös ist, ist das toll. Wenn am Ende alles aufgeklärt wird, warscheinlich noch mit dem großen "Aha!"-Effekt, dann ist das noch toller. Wenn das aber eben nicht geschieht, dann fühle ich mich, hart gesagt, verarscht. Wenn mysteriöse charaktere auftauchen, Sachen passieren, die ich nicht verstehe und ich gefesselt weiterspiele, um hinter all diese Geheimnisse zu kommen und dann plötzlich vor dem Game Over Bildschirm stehe, dann ist doch irgendwas mächtig faul. Deshalb rate ich euch, unbedingt im Kopf zu behalten, was ihr wisst, und was der Spieler weiß. Ich hoffe, dass es nicht allzu oft passiert, aber wenn ein Autor seine Handlungsstränge durcheinanderbringt und nicht alle zu Ende führt, dann ist das ziemlich tragisch.

Ein weiterer Fehler, der damit in engem Zusammenhang steht, ist das Übertreiben. Mysteriöse Charaktere sing gut, aber wenn jeder zweite aktive Charakter in Zeichensprache redet und eine schwarze Kutte trägt, dann ist das definitiv zu viel des Guten. Man sollte den Spieler nicht zu sehr überfordern. Wenn ihr in eurem Intro acht verschiedene Charaktere habt, deren Dialoge und Aktionen der Spieler nicht versteht, solltet ihr nicht erwarten, dass er sich zehn Stunden später, wenn sie zum ersten Mal in der Story vorkommen noch an den genauen Wortlaut erinnert. Und zu viele Geheimnisse und Verschwörungen können schon schnell ins Lächerliche abfallen. Traurigerweise kann ich dieses Mal nicht behaupten, nur aus Theorie zu sprechen, es gibt tatsächlich das ein oder andere Spiel (will hier ja keine Namen nennen =P) wo der Ersteller eine etwas zu komplexe Story umsetzen wollte (zumindest nehme ich mal an, dass sie komplex war, und die diversen sehr konfusen Charaktere nicht nur aus Spaß vorkamen xD). An der Grenze des erträglichen in Sachen Geheimnisse usw. will ich mal Xenogears nennen ein Spiel mit mehr als nur einem mysteriösen Charakter und vielen unverständlichen Sequenzen, die sich erst langsam aufklären, aber geradezu genial =).

Ebenso vermieden werden sollten unlogische Storywendungen, die es leider noch viel zu oft gibt. Den Verräter in der Gruppe der Helden gibt es vielen Spielen, doch Motivation, Hintergrund und Verhalten des Charakters vor seinem Verrat werden nur allzu oft außer Acht gelassen. So ist in einer gewissen Fernsehserie die Vizechefin einer Polizeieinheit in Wahrheit ein Maulwurf einer internationalen Verbrecherorganisation oder so, was sich zu Ende der vorletzten Folge von Staffel 1 herausstellt. Gut, wie sie es geschafft hat, eine derart wichtige Position zu erlangen bzw. wie sie zur Verbrecherin geworden ist wird nicht weiter behandelt und ist der Fantasie des Zuschauers überlassen. Fein. Aber handelt sie innerhalb der Staffel bevor sie sich offenbart (und gleich mal nen Mord an einem wichtigen Charakter begeht) auch nur einmal irgendwie gegen die Interessen der ander Charaktere? Keine Spur, selbst rückblickend betrachtet. Sie rettet dem ein oder anderen das Leben, wird mehrmals fast umgebracht, gibt alles um die Bösen (die um drei Ecken eigentlich mit ihr zusammenarbeiten) aufzuhalten und so weiter. Für mich klingt das sehr verdächtig nach einer zwanghaften Storywendung. Irgendwer hat sich wohl gedacht "Jetz müssn wer des Ganze aber mit nem deftigen Kracher beenden!" und schnell mal die böse Über-Verschwörung ins Script gemogelt. Genau so, wie es eigentlich nicht laufen sollte. Klasse wäre der plötzliche Charakterwechsel gewesen, wenn es vorher ein Dutzend kleinerer Hinweise und seltsamer Begebenheiten gegeben hätte, die sich nun alle durch diese Schlüsselszene erklären würden. Aber nix da. Deshalb sollte man sich immer im Klaren sein, dass Storywendungen zwar gut sind, aber keine Storywendungen immer noch besser als unlogische. Und wenn man zuviele einbaut, dann gibt es einmal den Effekt, dass der Spieler den Überblick verliert, und zum anderen wirkt die Story arg unglaubwürdig.
Noch ein schönes leider oft vorkommendes Beispiel für schlechte Storywendungen sind Klischeehafte Aufdeckungen über die Verwandschaft des Helden, entweder, Klischee #1: "Du bist in Wahrheit ein Prinz! Jetzt darfst du doch die Prinzessin heiraten und über uns regieren, hach, was ein ZUFALL!" oder, auch schön (Star Wars, aber da ist es Kult =P): "Du bist meine Schwester, Leia *heul* Endlich habe ich dich wieder. Jahahaa...". Prominentestes RPG-Beispiel dafür ist wohl Final Fantasy 8 mit der Basketballplatzszene. Ich HASSE sie xD. Wer das Spiel gespielt hat, weiß genau, wovon ich rede, und für alle anderen fasse ich es mal als ein "Oh mein Gott! Wir sechs Helden haben alle die Erinnerung an unsere Kindheit verloren. Wisst ihr was, wir sind alle (!) Geschwister! Und die böse Hexe gegen die wir seit was weiß ich wie vielen Spielstunden kämpfen ist in Wahrheit unsere Mutter! Kommt, wir nehmen sie in die Party auf!" Kein Scherz.

Das wohl am weitesten verbreitete Storymanko (mal abgesehen von einfach schlechten Charakteren usw.) ist das Überpowern von Charakteren. Besonder häufig vertreten in größeren Bücherzyklen oder Manga/Animeserien. Als Beispiel nenne ich mal die wohl bekannteste Mangaserie, Dragonball. Die ganze Story fängt gar nicht schlecht an und schafft es auch, zumindest so in den ersten 10 Bänden größtenteils ziemlich witzig zu bleiben. So um Band 17 rum hat dann das lustige Trainieren und in freundlichen-Turnieren-kämpfen ein Ende und das ganze wird Ernst!!!!!!! (ich zittere). Soll heißen, es kommen jede Menge Erzböse Charaktere, einer stärker als der nächste. Das tolle daran ist, dass jedes Mal, wenn der neue Endboss kommt, er ungefähr so stark ist, dass er die komplette Erdbevölkerung im Alleingang auslöschen könnte (bzw. später im Manga das Universum mit einem Fingerschnippen zerstören kann). Dann hat er den ersten Kampf mit den Helden, tötet zwei oder drei und zieht erstmal wieder von dannen, um irgendwas anderes lustiges zu tun. Die toten Charaktere werden wiederbelebt (eine tolle Erfindung im Dragonball Universum) und alle trainieren und werden irgendwie genau so stark wie der ehemals stärkste Chara ever. Sie machen ihn platt. Alle froh. Der nächste kommt, 10.000 mal so stark wie sein Vorgänger, und das ganze wiederholt sich. Das passiert dann so ungefähr fünf Mal, bis der Autor keine Lust mehr hatte und die zu diesem Zeitpunkt meiner Meinung nach mehr als langweilige Serie beendet. Um den Schluss aus dieser Erzählung zu ziehen: Eine Story wird nicht dadurch interessanter, dass immer, wenn der stärkste vorhandene Gegner besiegt ist, plötzlich aus dem nichts ein noch stärkerer auftaucht. Im Gegenteil ist es empfehlenswert, wenn man im Anfangsverlauf dem Spieler die Grenzen zeigt, nach dem Motto "Das ist der stärkste Kerl im Universum und ihr werdet jetzt mindestens 20 Spielstunden brauchen, bis ihr ihn fertig machen könnt und dann ist auch gut."

Last but not least sind die Klischees. Wer kennt sie nicht, den rechtschaffenden blonden Helden, die wunderhübsche Prinzessin die vor dem Drachen gerettet werden muss, der ewig Witzbold der nichts als Unfug im Kopf hat, die böse Hexe, den schweigsamen Elfen, der muskelbepackte axtschwingende Barbar, der Erzdämonen, der die Welt vernichten will, den fiesen Grafen, der es auf die Freundin des Helden abgesehen hat, der nette Vater, der den Helden alleine aufzeiht und zu Beginn des Spiels stirbt, ......
Alles Charaktere, wie man sie in der ein oder anderen Form schon tausendmal gesehen hat. Klischees lassen sich nicht vollkommen vermeiden, wenn man ein Rollenspiel erstellt, soviel ist klar. Wenn die Helden eine Gruppe von Zirkusclowns, Vergewaltigern und Abflussreinigern sind, weil es das noch nie so gab, hat man das Ziel ja auch irgendwie verfehlt. Es kommt viel mehr darauf an, wie man diese Klischees verwendet. Meiner Meinung nach, passt der rechtschaffene Held wunderbar, wenn er von den anderen Charakteren der Welt nur nicht zu ernst genommen wird. So lang bei Sätzen wie "Natürlich helfe ich dir, die Katze aus dem Feuer zu holen, Mädchen" ein ironisches "Herrgott, nimm mal den Heiligenschein ab, es blendet" aus dem Hintergrund kommt, ist das doch kein Problem. Und das verwöhnte Burgfräulein kann mit seiner Einstellung der Welt gegen über auch mal in die ein oder andere problematische Situation geraten, aus der ihr dann vielleicht gerade der zuvor verhasste ewig zynische Taschendieb helfen muss.