Liste der Anhänge anzeigen (Anzahl: 3)
Wens interessiert, hier mal die Event Commands aus der englischen Version ;)
Das RTP is heftig, und derbe umfangreich, bin noch nicht durch alles durch, einziger nachteil:
das komplette Vokabular muss manuell übersetzt werden, is alles Jap., aber dafür ist die Systemsprache generell
wenigstens Englisch ^^
siehe Anhang ;)
Liste der Anhänge anzeigen (Anzahl: 2)
Nach ein paar Wochen mit dem VX hier in aller Kürze noch ein paar Details:
Erst mal ein Screenshot aus UiD zum Thema "Blockigkeit":
Anhang 13729
Der Screen ist noch nicht fertig, zeigt aber schon, dass man mit dem Ace genauso unblockig arbeiten kann, wie mit jedem anderen Maker, wenn man darauf verzichtet, die Klippen als Autotiles anzulegen und eben nicht mit dem RTP oder dem VX-Refmap-Set arbeitet. Mit uneditiertem RTP zu arbbeiten war auch beim 2k oder 2k3 genauso eckig und der einzige Grund, warum wir mit weniger Kanten arbeiten können, liegt daran, dass sich irgendwelche findigen Leute auf den Arsch gesetzt haben und z.B. bei den Refmap-Sets die Autotiles bearbeitet haben. Die Bodenstrukturen sind hier ausschließlich mit Autotiles gemacht - ich habe noch ein paar Extra-Tiles auf dem A5 Layer, mit denen man die Kurven noch etwas schöner hinbekommt, die kommen aber auf dem Screen nicht zur Anwendung, weil sie erst zum Finish eingebaut werden. Ein paar der höher gelegenen Baumstrukturen sind Character-Grafiken und der Bach ist auch aus 9x9 Tile großen Charas zusammengebaut - allerdings ist er genauso eckig geraten, wie ein Autotile, weil die Kurven auch nur 16 Pixel breit sind.
MErke: Wer mit uneditiertem RTP arbeitet hat bei jedem Maker verloren - der XP hat zwar theoretisch die geschwungensten Kanten bei den Autotiles, das RTP ist allerdings viel zu flau und Klippenmapping wird auch dort nicht über Autotiles geregelt. Nur weil beim VX/Ace die Klippen in die Autotiles gepackt wurden, heißt das ja noch lange nicht, dass man sie auch auf diese Weise verwenden muss.
Was man auf dem Screen nicht erkennen kann, ist ein Kniff, mit dem man allein mit den Autotiles wunderbar geschwungene Kurven hinbekommt: Man legt ein Autotile - z.B. Gras über Dreck - ganz normal mehr oder weniger quadratisch auf dem Lower Layer an. Dann legt man ein zweites Autotile (im Beispiel Gras) auf dem transparenten Layer an, mit dem man normalerweise Zäune und ähnliches aufzieht - dieses Mal aber mehr oder weniger rautenförmig - wenn man diese beiden Layer miteinander kombiniert, kriegt man absolut unblockige und sehr variantenreiche Kurven hin.
Dann noch eins der neuen Features, nämlich die aufpinselbaren Region-IDs
Anhang 13730
Standardmäßig werden die Regionen, wie schon früher, für unterschiedliche Encounter-Zonen verwendet. Da sie sich im VXA aber so schön aufpinseln lassen kann man sie wunderbar zweckentfremden. In diesem Beispiel werden sie z.B. verwendet, um bestimmte Regionen unpassierbar zu machen - Region 61 (und zwar auch für alle Events, unabhängig vom Layer). Dafür gibt es ein Script von Yanfly, bei dem man auch Events die Überschreitung einzelner Regionen verbieten kann bzw. nur dem Spieler verbietet bestimmte Regionen zu betreten. Das spart einiges an Blockade-Events und sorgt für Übersichtlichkeit. In diesem Beispiel wird über die Regionen außerdem die Entfernung zum Bach gestimmt und der Background-Sound dynamisch angepasst - als Background Musik wird ein Wasserfall-Sound verwendet, der abhängig von der Entfernung zum Wasserfall in der Lautstärke variiert wird. Auf diese Weise bekommt man relativ unkompliziert eine sehr dezente und vor allem realistische Geräuschkulisse hin. Und das Ganze komplett ohne Ruby und extrem ressourcenschonend.
Man kann die Region IDs jedoch auch anders zweckentfremden. Z.B. für Events die ausgelöst werden, wenn man darüber läuft - in UiD gibt es davon jede Menge und Events gehen natürlich zu Lasten der Performance. Hier werden alle Drauflatsch-Events über den gleichen PP abgewickelt, der auch für den Bach-Sound verwendet wird - inklusive aller Teleports. Das mach die Arbeit auch deswegen übersichtlicher, weil ich alles in einem Event bearbeiten kann, wenn Änderungen nötig sind.
In einem anderen Projekt verwende ich die Region-IDs für ein relativ simples Fernkampf KS (=Pistolen, nach einem ähnlichen System wie bei Charistotos Krass - die sterblichen Überreste dieses Spiels gibt's als Download im UiD-Forum): Für die Gegner-KI wird ermittelt, in welcher Region sich der Spieler befindet und dann rennt der Gegner auf einen vordefinierten Punkt, von dem klar ist, dass er den Spieler von dort aus gut treffen kann - auch hier erspart diese Vorgehensweise einges an KI Arbeit und vor allem (wieder mal) an Performance. Wider einmal kann man alles über Event Scripting regeln. Ruby bleibt außen vor.