Liste der Anhänge anzeigen (Anzahl: 3)
Fakten und Vorurteile: Der VX ACE
Na toll ... jetzt ist der Thread im falschen Forum gelandet ... kann den bitte jemand in den Community-Bereich verschieben? Danke!
So ... da ein eintsprechender Thread andernorts gefordert worden ist, habe ich jetzt mal einen Erstellt ... zumindest für den ACE. Den SP und den VX kenne ich nicht ausreichend um definitive Aussagen treffen zu können. Ich hoffe, damit hat das ständige abverurteilen des Ace und das nachplappern von Vorurteilen hier im Board dann endlich ein Ende.
Also ... Los gehts!
Vorurteil 1: Das Mapping des VX-ACE ist schlecht und umständlich!
Fakt 1: Bedingt richtig
Es stimmt, das das Mapping des ACE keine getrennten Layer mehr kennt. Wer von den alten Makern kommt, wird daher zu Anfang darüber stolpern, dass Upper-Layer und Lower-Layer beim platzieren zu einem Layer "vermelzen", was bedeutet, löscht man den Lower Layer wieder, entfernt man auch alle entsprechenden Tiles auf dem Upper-Layer. Tatsache ist aber: Man gewöhnt sich dran. Nach 3 Stunden habe ich den Unterschied nichteinmal mehr bemerkt. Wenn man halbwegs im Kopf plant, ändert man den Lower-Layer sowieso nicht so oft.
Vorurteil 2: Die Grafik des ACE ist klotzig!
Fakt 2: Falsch
Das "Klotzige" der ACE-Grafik rührt daher, das Autotiles des ACE nur noch 2x2 Tiles groß sind, statt 3x3, wie auf den alten Makern. Während man bei gut gepixelten "künstlichen" Flächen (Mauern, Hauswänden etc.) praktisch keinen Unterschied sieht und die Wände aufgrund der höheren Auflösung sogar erheblich besser aussehen, ergibt sich bei "organischen" Flächen, Berge, Wälder, Wiesen ... daraus der typische Klotz-Look, den viele so ablehnen. Diese Optik ist aber keineswegs notwendig, wobei man dazu verstehen muss, wie ein Tileset das ACE aufgebaut ist. Jedes ACE-Tileset besteht aus bis zu 9 einzelnen Grafiken, die mit den Buchstaben A - E markiert sind. Während A dem Lower-Layer entspricht, markieren B - E den Upper Layer. Nun kann man sich jedes Tileset nach belieben zusammenstellen, indem man eigene, editierte, oder RTP-Grafiken auf die einzelnen Plätze zuweist:
A1 : Animierte Autotiles (Wasser, Lava)
A2 : Boden-Autotiles (Grass, Sand, Fliesen, Schnee)
A3 : Außenwände-Autotiles (Hauswände mit Dach, Baumwände mit Blättern, Felsklippen ... )
A4 : Innenwände-Autotiles
A5 : Sonstige Tiles
B : Upper Layer
C : Upper Layer
D : Upper Layer
E : Upper Layer |
Anhang 15564 |
Entscheidend für alles ist in diesem Fall NUR A5. A5 ist 256x512 Pixel groß, was 128 Tiles entspricht. Diese Tiles können GANZ NORMAL zum "puzzeln" erwendet werden, so, wie man es bisher von den alten makern gewöhnt war. Alles was notwendig ist, ist eine Anpassung des PNGs durch ein Grafikprogram ... also ein neu Zusammenscheneiden der Tiles. Beispielsweise in dem man ein Set für runde Klippen hinzufügt. Systembedigt eignen sich die Tiles des XP-RTP dazu am besten, weil diese auch schon in der Auflösung 32x32 Pixel vorliegen. Theoretisch geht aber auch alles andere.
Der Rest ... ist dann ganz einfach "Mapping-Skill".
Vorurteil 3: Das Event-System des 2k3 kann mehr, wenn man kein Ruby benutzt!
Fakt 3: Falsch
Der VX-ACE ist von allen Makern der einzige, dessen "rohes" Event-System mit dem des 2k3 gleichaufliegt - das heißt, wenn man partout auf Ruby verzichten will. Es gibt bei beiden Makern jeweils Dinge die einer kann, und der andere nicht, rein vom Umfang her tun sich die Maker aber nicht viel...viele Funktionen sind lediglich anders platziert und manchmal wurden einige Funktionen zu Gunsten der Usability zu einer zusammengelegt. So kennt der ACE beispielsweise keinen "Set Face" Befehl mehr, weil die Facegrafik jetzt direkt dort definiert wird, wo sie hin gehört: im Message-Box-Dialog.
Der Variablen-Dialog ist zum Beispiel etwas abgespeckt worden und das Sound-System kennt keinen fade-In für MP3 / OGG mehr. Dafür ist die Conditional-Branch um ein vielfaches umfangreicher, als beim 2k3, die "gedankenblasen"-Funktion des 2K ist wieder enthalten, und es ist jetzt möglich, das Sichtfeld des Spielers unabhängig vom Charakter zu bewegen... um ein paar Unterschiede zu nennen.
Unterm Strich liegen beide Systeme vom Umfang her also ungefähr gleichauf. |
Anhang 15565 |
Und JETZT kommt Ruby in's Spiel.
In vielen Dialogen des Event-Systems findet sich zusätzlich zu den dort vorhandenen Einstellmöglichkeiten noch eine Zeile mit dem Namen "Script". Dort lassen sich mit kurzen Ruby-Ausdrücken Funktionen oder Bedingungen einfügen, die der Maker von Haus aus nicht hat. Wem also beispielweise die aufgebohrte Conditional-Branch nicht ausreicht, kann dort mit Ruby "neue" Conditions definieren.
So würde
$game_party.members[0].skills.include?($data_skills[1])
beispielsweise Abfragen, ob der Charakter auf Party-Slot 0 den Skill 1 beherscht - unabhängig davon, welcher Charakter grade auf Slot 1 steht.
Vorurteil 4: Ohne Ruby bietet der ACE nichts, was der 2k3 nicht auch könnte!
Fakt 4: Falsch
Der ACE bringt einige, sehr mächtige Werkzeuge mit, die alle eines gemeinsam haben: Sie können direkt über die Datenbank genutzt werden, ohne Ruby!
Da ich nicht auf alles einzeln eingehe, im Folgenden nur ein Abriss des wichtigsten:
Formel-Editor für Fähigkeiten
Der Formel-Editor gewährt dem Spieler maximalen Zugriff auf den Schaden seiner Fähigkeiten. Im Gegensatz zu früher verschiebt man beim ACE keine Regler mehr um den Schaden einer Fähigkeit zu beeinflussen, sondern schreibt die Schadensformel Direkt in die Datenbank -... und zwar für jeden Skill separat, wenn man das will.
100 + a.atk * 6 - b.def * 3 würde beispielsweise bei einem Angriff das 3-fache der Verteidigung des Ziels, vom 6-Fachen der Angriffskraft des Angreifers + 100 abziehen.
b.hp * 0.3 würde die HP des Ziels um 30% verringern.
a.hp - b.hp würde den Schaden des Angriffs aus der Differenz zwischen den HP des Angreifers und denen des Verteidigers errechnen.
a.atk * a.mp würde um so mehr Schaden machen, je mehr MP der Angreifer im Augenblick hat.
(a.agi + a.level) * v[0001] würde Schaden verursachen, der auf dem Geschick und Level des Angreifers beruht, mutipliziert mit dem Wert, der aktuell in der variable 0001 gespeichert ist.
Das ganze lässt sich sogar noch weiter treiben: Gibt es in eurem Spiel eigentlich gar keine Magie und der Magie und Magieabwehr-Stat sind überflüssig? Kein Problem! Benennt "MAT" in der Datenbank einfach in "Charisma" um, streicht den Wert aus allen Schadensformeln und baut stattdessen bei NPC's oder Händlern eine Abfrage ein, die je nach Charismawert eines Charakters deren reaktion verändert. Oder nennt den Wert "Fitness" und nutzt ihn über eine Conditional-Branch dazu, um zu bestimmen, ob ein Charakter Türen aufbrechen oder Abgründe überspringen kann. Oder wie wäre es mit einem Karma-Stat? Da ihr die Verwendung der 4 Stats ATK, DEF, MAT, MDF vollkommen frei definieren könnt, könnt ihr sie auch nutzen, wie ihr wollt.
Da der ACE euch zudem die Möglichkeit bietet, die item-Preise bei Händlern individuell zu gestalten, ist es so z.B. möglich, dass ein Charakter mit hohem Charisma weniger für einen Einkauf bezahlen müsste, als einer mit niedrigem Charisma. Und schon habt ihr ein komplett neues Spielsystem drin...ganz ohne Ruby ;)
Die einzigen beiden Stats, die nicht zu 100% aus dem System gelöst werden können (so lange man das Standart-KS benutzt), sind AGI und LUK. Agi definiert die Zugreihenfolge, LUK die wahrscheinlichkeit, einem negativen State zu widerstehen.
Self-Switches:
Self-Switches sind switches, die direkt an ein Event gebunden sind und die Eventseiten-Verarbeitung beeinflussen. So ist es beispielsweise möglich, einen NPC beim ersten Mal ansprechen etwas anderes sagen zu lassen, als beim Zweiten, OHNE dafür einen entsprechenden Schalter in der Datenbank anlegen zu müssen. Für jedes Event können bis zu 4 Self-Switches (A, B, C, D) definiert werden, die sich über Eventcode jeweis an-, und abschalten lassen. Eine besonderheit ist, das Common-Events einen "Self-Switch" bis ganz nach unten zum ursprünglichen Auslöser durchreichen. Wenn man also aus einem Event heraus ein Common-Event aufruft, und im Verlauf dieses Common-Events ein Self-Switch gesetzt wird, dann wird dieser Self-Switch nicht für das Common-Event, sondern für das ursprüngliche Event gesetzt.
Common-Event-Skills
Ebenfalls wichtig ist, die Tatsache, dass der ACE dazu imstande ist, direkt aus einem Skill heraus ein Common-Event aufzurufen ... auch im Kampf. Das bedeutet, Skills, die ein Spieler durch ein Event simuliert, erfordern keine eigene Eventseite im Encounter-Dialog mehr. Der Skill selbst ruft ein Common-Event auf, und dieses Common-Event greift von außen DIREKT auf den Kampf zu. So können Common-Events des ACE beispielsweise gezielt einzelne Charaktere oder sogar Gegner anhand ihres Truppen-Index ansteuern.
Features.
Das Feature-System zu erklären, würde jetzt den Rahmen sprengen. Vereinfach ausgedrückt, kann man damit ACTORS, CLASSES, ITEMS, WEAPONS, ARMORS und ENEMYS passive Eigenschaften auferlegen.
Einige dieser Eigenschaften - z.B. Elementare Resistenzen - gab es auch schon beim 2k3, wurden beim ACE aber deutlich aufgebohrt. Während man beim 2k3 beispielsweise über einen State lediglich dazu imstande war, einen Statuswert zu verdoppelt oder zu halbieren, geht der ACE hier gleich mehr als nur einen Schritt weiter. Dank der Features kann den Bonus, bzw. Malus nicht nur zwischen *0% und *1000% vollkommen frei bestimmt werden, mann kann auch einen State GLEICHZEITIG verschiedene Statuswerte erhöhen und andere veringern lassen ... z.B. einen State, der die HP und ATK verdoppelt, aber die MP und MAT halbiert.
Andere Zugriffe, die die Features erlauben sind vollkommen neu und greifen tiefer in die Engine ein, als jemals zuvor. So kann man beispielsweise bestimmen, wie wahrscheinlich es ist, das ein Charakter angrgriffen wird. Man kann bestimmen, wie wahrscheinlich es ist, das ein Charakter einen zauber reflektiert, einem kritischen Treffer ausweicht oder einen gegnerischen Angriff kontert. Man kann einem Charakter die passive Fähigkeit geben, permanent HP ... oder MP ... zu regenerieren, man kann bestimmen ob er mehr, oder weniger Mana für einen Zauber bezahlen muss, als normal, oder wie viele Erfahrungspunkte er bekommt...und noch vieles mehr.
Da sich diese Features auf praktisch alle Komponenten des Spiels anwenden lassen, ist damit extrem viel Individualisierung möglich. Zum Beispiel ein Skill, der den Schaden und die Manakosten von Zaubern verdoppelt, ein Accessoire, dass den Charakter mehr EXP oder Gold - oder beides - sammeln lässt. Eine Waffe, die den Effekt von Heilitems verbessert oder eine Rüstung die dazu führt, das der Charakter zusätzlich Heilung durch Heilzauber erhält. Das bedeutet beispielsweise auch, das Ausrüstung beim ACE einen %-Bonus/Malus auf Statuswerte geben kann, statt eines Absoluten Bonus/Malus.
Die 4+ Partymember-Party
Im Gegensatz zum 2k3 unterstützt der ACE Partys, deren Größe mehr als 4 beträgt. Zwar nehmen immer nur die ersten 4 Charaktere am Kampf teil, aber die Charaktere können während des Spiels gegeneinander ausgetauscht werden, so das man, wie in FF auch mal mit 8 oder 10 leuten in der selben Gruppe unterwegs sein kann. Bei Bedarf erhalten die Charaktere auf der Ersatzbank auch EXP, um den Anschluss an die erste Reihe nicht zu verlieren.
Anhang 15566
Vorurteil 5: Wenn ich kein Ruby kann, profitiere ich nicht von der Ruby-Unterstützung!
Fakt 5: Falsch
Der Script-Editor des ACE ist ein Plug-and-Play System.
3d-Party Scripts werden im Internet in großer Anzahl bereit gestellt. Diese Scripts liegen in Textform vor, können einfach per "Copy and Paste" in das Spiel übernommen werden und sind dann sofort funktionsfähig. Die meisten Scripte sind darüberhinaus so geschrieben, das ein Vorgelagerter "Konfigurationskomplex" eine schnelle und einfach anpassung des Scripts erlaubt ... auch für solche Leute, die kein Ruby können. Überlicherweise kommen alle Scripts mit einer präzisen, englischen "Gebrauchsanweisung", in der haarklein drin steht, was der Spieler tun muss, damit das script so funktioniert, wie es soll. Natürlich kann es hin und wieder mal passieren, dass Scripte untereinander nicht kompatibel sind, oder einen Bug enthalten.
In 90% aller Fälle bedeutet aber "Ich krieg das verdammt Blöde Script nicht zum laufen! So eine bekloppte scheiße! Ruby ist der letzte Dreck!" Viel eher: "Ich war zu faul, die kurze Bedienungsanleitung zu lesen! Ich bin so ein bequemes Arschloch! Ich mecker lieber, statt mich zu bemühen!"
Meistens ist es für die Funktion eines Scripts notwendig, so genannte "Note Tags" in Kommentarfelder zu schreiben, oder einen kurzen "Script Call" auszuführen. Defacto lässt sich diese Arbeit KOMPLETT per Copy & Paste ausführen. Das heißt, jemand der vorgefertigte Scripts nutzt, kommt theoretisch nichteinmal selber mit Ruby in Berührung. Er kopiert einfach das Script in den Editor, schaut sich die Bediehungsanleitung des Autoren an, tut was da drin steht, und freut sich, dass es funktioniert.
Und wenn es doch mal probleme gibt, etwa, weil zwei Scripte nicht kompatibel sind: Rubyscripte können genau so einfach wieder aus dem Spiel entfernt werden, wie sie eingefügt wurden: Man muss nur auf ENTF drücken ;)
Hier liegt auch der große Vorteil etwa gegenüber dem Patchsystem von Cherry. Während dieses irreversible veränderungen an der Exe vornimmt, und einmal getätigte Änderungen nicht mehr rückgängig gemacht werden können, egal ob sie möglicherweise sogar zu Problemen und Bugs führen, lassen sich Ruby-Scripte jederzeit zu 100% wieder aus dem Spielprojekt entfernen.
Vorurteil 6: Für den ACE gibt es weniger Ressourcen, als für die alten Maker.
Fakt 6: Richtig
Zumindest , wenn man die Aussage wörtlich interpretiert. Die absolute Menge an Ressourcen für den ACE ist geringer, einfach deshalb, weil er noch nicht so lange auf dem Markt ist. Wer diese Aussage allerdings dahingehend interpretiert, das es für den ACE "ZU WENIGE" verfügbare Ressourcen gibt, könnte recht schnell eines besseren Belehrt werden, denn das Angebot an qualitativ hochwertigen Ressourcen für den ACE ist überwältigend. Zudem sind ACE-Ressourcen im regelfall rechtlich unbedenklich.
Den Unterschied macht hier die Herkunft der Ressourcen aus. Während vieles, was für die älteren maker verfügbar ist, aus Rips von Spielen besteht, sind die für den VX / ACE verfügbaren grafiken zu 95% selbst erstellt. Viele englischssprachige Communitys lehnen alle Ressourcen ab, die die rechte Dritter verletzen. Dadurch können natürlich die kompletten "Ripper" keine Ressourcen für diese maker bereitstellen, was die Menge einschränkt. Gleichsam profitiert aber die Qualität der selbstgepixelten Ressourcen von der höheren Auflösung. Während das Angebot an "eigenen Stilen" bei den alten makern mit Mack und Theodore praktisch erschöpft war, wartet die englische VX-Community hinsichtlich selbstgemachter Ressourcen mit deutlich mehr hochkarätigen "Pixelkünstlern" auf.
So hat nicht nur Mack für die VX Engine gepixel, auch Namen wie Celliana, lunarea, IceDragon, Tsukihime und Thalzon sollte man sich merken, wenn man auf Ressourcensuche geht.
Dazu kommt, das das komplette XP-RTP zum ACE kompatibel ist und Enterbrain regelmäßig neue Ressourcen-Addons veröffentlich ... z.B. Arabian-Nights, Samurai oder Modern Tiles.
Vorurteil 7: Der Ace unterstützt keine Tall-Chars
Fakt 7: Falsch
Richtig ist, das das normale Charset-Format des Ace 32x32 Pixel große Charaktere vorsieht und keine Tall-Chars. Normale Charsets bestehen aus 4 Charakteren nebeneinander, 2 unterainander. Jeder Charakter besitzt 4 Blickrichtungen mit 3 Frames je Blickrichtung.
Falsch hingegen ist, dass die Verwendung solcher Tall-Sprites gar nicht möglich ist.
Durch das Voranstellen eines ! vor den Dateinamen, kann ein Sprite-Sheet eine beliebige Höhe aufweisen - sofern diese durch 8 teilbar ist - und somit auch beliebige Tall-Chars aufnehmen. Durch ein Vorranstellen eines $ vor den Dateinahmen behandelt der ACE Spritesheets ähnlich , wie der XP ... d.H. es kann nur ein Sprite pro Sheet verwendet werden, dieser darf allerdings sowohl auf der X als auch der Y Achse beliebige Maße aufweisen ... sofert diese durch 3 (breite) bzw. durch 4 (höhe) teilbar sind.
Vorurteil 8: Alle Ace-Beführworter tun immer so, als wäre der Ace der Beste Maker aller Zeiten!
Fakt 8: Falsch
Der Ace hat definitiv fehler. Teilweise sogar gravierende. Der Punkt ist: Alle Maker haben solche fehler. Und die fehler, die dem Ace immer angedichtet werden, sind keineswegs die Fehler, die wirklich relevant sind.
Der Ace nutzt beispielsweise dasselbe, unglückliche Event-System wie der Vorgänger und aktualisiert bei jedem Updaten-Zyklus ALLE Events auf der Map, selbst wenn dies nicht notwendig sein sollte. Das resultat davon ist: Ab ca 100 Events auf einer Map geht die Performance des Systems in einen Sturzflug über. Ausuferndes Event-Mapping, wie man es beim 2k3 gerne betrieb, ist damit auf dem Ace nur in sehr kleinem Rahmen möglich, oder man beschränkt sich auf sehr kleine Maps.
Eine weitere, große Schwäche des Systems ist, dass der ACE die aus dem 2k3 bekannte Suchfunktion nicht besitzt. Es ist also nicht mehr möglich, einmal das komplette Spiel automatisch abzusuchen, um festzustellen, wo welche Variable oder welcher Switch zum Einsatz kommt. Das erfordert sehr sorgfältiges Planen und vor allem aussagestarke namen für Switches und Variablen, um sich nicht irgendwann in seinem Spiel zu verheddern.
Vorurteil 9: Der Ace kennt keine Tilesets!
Fakt 9: Falsch
Der Ace arbeitet genau so mit Tilesets, wie es der 2k3 tut. Die einziges Maker, die keine Teilsets besitzen, sind der XP und der VX. Tatsächlich sind die Tilesets des Ace sogar wensentlich größer, als die des 2k3. Während ein Tileset des 2k3 alles in allem (d.H. inklusive Autotiles und animationen) 480 Tiles enthielt, beläuft sich die Gesamtzahl der Tiles beim ACE auf ca 1900 Tiles pro Tileset. Damit erreicht der Ace zwar nicht die "beliebige Größe" des XP, ist aber immer noch ausreichend bestückt für gute Maps. Insbesondere, da der Spieler bis zu 999 Tilsets anlegen kann ...
