Lang, lang ist’s her, aber jetzt ist es wieder soweit, der achte Kursteil ist hier. Dieses Mal befasse ich mich mit Dungeons, Zufallsgeneratoren und andere Anwendungen dafür, sowie einem Speicherpunktsystem. Ich werde versuchen, die Trennung zwischen Allgemeinem und Kursprojekt etwas stärker einzuhalten.

• Dungeons und alles, was dazu gehört
• Speicherpunkte
• Zufall

Altbekannt, doch nützlich wie immer: Das Kursprojekt!
Für alle, die es nicht kennen: Das Kursprojekt ist ein sekundäres Projekt, in dem ihr alle neuen Funktionen, die ihr hier lernt halbwegs sinnvoll einbauen könnt. Es soll keineswegs euer eigenes Projekt ersetzen, sondern nur zu Testzwecken da sein.

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 man sich überlegen, 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 Beispiel 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 anderen 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 Fackeln 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ätsle 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 so was 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. Zu viele Verschieberätsel können den Spielspaß genauso gut 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 separaten 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 Generator 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, wie viel 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, das 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 Bildschirms 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 war’s 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 ^_^'

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ückzufordern. 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 sein, der zu diesem Zeitpunkt auf Level 4 oder sogar schon 5 ist. Außerdem habe ich für den ganzen Dungeon gleich noch mal ein neues Monster erstellt, da man ja nicht immer gegen die gleichen Gegner kämpfen will. So was 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ählt werden. Optimal für so was 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 vor 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 deaktiviert werden. Ta-daa!

Die letzte Variante, die mir jetzt noch einfällt ist das Speicheritem, also ein Gegenstand, den man nur einmal 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 noch mal 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.

ACHTUNG! Was einige Leute noch immer nicht gemerkt zu haben scheinen: Seit dem dritten Teil findet sich im vorletzten Kapitel "Das Kursprojekt" ein Link zu einer Zipdatei, die das Projekt mit sämtlichen hier verwendeten Beispielen enthält. Wer also Fragen zu einem gewissen abschnitt hat, kann sich das ganze am besten noch einmal "fertig" anschauen!

Frohe Weihnachten ^_^' <- auf letzten Drücker fertig geschrieben, deshalb schreib ich hier jetzt keine Romane mehr XD

Auch dieses Mal gibt es wieder das Kursprojekt zum Download bei uns. Wer in diesem oder einem der letzten Teile Probleme hatte, kann sich das ganze noch einmal fertig im Spiel anschauen.

Ich denke, ich werde ein bisschen zur allgemeinen Planung von Spielen erzählen... Falls ihr Ideen habt, könnt ihr mir gerne eine e-Mail schreiben.