Moinmoin,
Da mir grade doch etwas langweilig ist, wollte ich mit diesem Thread hier mal eine kleine Sammlung diverser Sachen zusammenstellen, die ich im Laufe meiner Maker-Laufzeit herausgefunden habe und/oder die ich einfach als recht nützlich empfand.
Beachtet halt, dass es meistens wirklich nur Kleinigkeiten sind.
1. Sparsamer Gebrauch von Pictures und Battleanimations
Dies dreht sich darum, dass man nicht zwangsweise drei oder vier mal das gleiche Picture bzw. die gleiche Battleanimation braucht, nur um von jenem Effekt eine andere Farbe zu erhalten.
Wenn ihr diverse Effekte macht (bspw. aufgewirbelte Sandstaubwolken), und ihr wisst, ihr könntet diese noch für andere Sachen verwenden (z.B. Staubwolken als Rauch, Feuerflammen als magische blaue Eisflammen, etc.), würde es euer Spiel nur unnötig groß machen, wenn ihr dasselbe Picture oder Battleanimation in verschiedenen Farben speichern würdet.
Macht euch einfach die Einfärbefunktion für BAs und Pictures zunutze!
Die Effekte selbst wandelt ihr einfach in Graustufen um und importiert dann die BA(s) bzw Picture(s) in euer Projekt.
Ab hier kommt die Einfärbefunktion zum Einsatz.
Da die Einfärbefunktion quasi im 24-Bit-Farbbereich betrieben wird, ist es nicht wirklich schwer, diese zum Einfärben zu verwenden, da man die Farbtöne fast 1:1 in die Prozentzahlen der einzelnen Farben transportieren kann (Alternativ könnt ihr den RGB-Wert, den ihr bspw. in Paint vorgeworfen bekommt, auch einfach durch 1,275 teilen, dann habt ihr den exakten Wert, den ihr als Prozentzahl eingeben müsstet).
Und fertig. Eigentlich sehr simpel, aber dennoch hilfreich, um ein bisschen Speicherplatz zu sparen.
Der einzige Nachteil daran ist, dass es ein geringfügig mehr Arbeitsaufwand ist. Aber schon recht nützlich.
2. Pictures anstelle von Battleanimations verwenden
Wieder ein vorteilhaftes Vergnügen, Speicherplatz zu sparen.
Indem man Pictures anstelle von BAs verwendet, spart man schonmal die paar Kilobyte pro Sprite, den man in einer Battleanimation für nichts verschwendet.
Battleanimations sind immer pro Sprite 96x96 Pixel groß (beim 2k3 sind zusätzlich noch 128x128 machbar). Allein von da her ist es schon eine rechte Platzverschwendung, wenn man eine gerade mal 32x32 Pixel große 25-Frame-Animation in eine BA stopft. Da kann man auch ca. 90% Speicherplatz sparen, indem man die Animation auf Pictures verteilt.
Der Arbeitsaufwand ist an sich derselbe, als wenn man eine Battleanimation in der Database erstellt.
Weiterhin hat es die Vorteile, dass eure Animationen auch insgesamt größer und länger sein können, es ist einfacher, die Größe und Transparenz verändern zu lassen, wenn es sich um ein Stillbild handelt und ihr habt natürlich Zugriff auf die Rotations- und Wabereffekte der Pictures.
Nachteile gegenüber normalen Battleanimations sehe ich keine.
3. Mehr Animationsphasen für CharSets
Eine Sache vorweg: Dies eignet sich eigentlich nur für Heldencharsets, die man selbst kontrollieren kann. Zumindest ist meine Erklärung (was ja mehr ein Skript ist) nur für die kontrollierbaren Heldencharaktere gedacht.
Sooo, eigentlich ist es recht einfach. Es ist nur ein bisschen Arbeitsaufwand (wieso, sag ich nachher) und es ist umso mehr Aufwand, je mehr Animationsphasen man verwendet.
In diesem Tutorial gehe ich von insgesamt 5 Animationsstufen aus, wobei die Standpose die Animationsstufe 3 (also quasi die Mitte) ist.
Weiterhin gehe ich davon aus, dass jede neue Animationsstufe nach 3 Frames (3x 0.0s-Wait) angezeigt wird.
Okay, nun, was ihr dafür braucht, ist folgendes:
- Ein leeres Common Event
- Einen unverbrauchten Switch
- Eine unverbrauchte Variable oder, falls vorhanden, die Variable für die allgemeine Abfrage der Maker-internen Tasten-ID (nicht die für den Tastenpatch!)
Nennt das Event, wie ihr wollt. Ich bezeichne es jetzt mal als Laufevent.
Den Switch nennt ihr "Laufen", die Variable nennt ihr "Tasten-ID". Oder naja...zumindest ich nenn sie so
Stellt das Event auf Parallel Process und lasst es aufrufen, wenn der Switch "Laufen" aktiv ist.
Den Switch braucht ihr, damit der Charakter in Zwischensequenzen nicht ebenfalls animiert wird. Soll er ja auch nicht, ne?
Gut, in das Event fügt ihr zuerst ein Label ein (Label Nr.1).
Als nächstes macht ihr ein Move-Event, in dem ihr dem Charakter die normale Stand-Pose zuweist (Also kein Move-Event an sich, sondern eher eine Änderung des Charsets. Wieso ihr das mit dem Move-Event machen sollt, erkläre ich später).
Danach macht ihr eine Key Input-Abfrage, in der ihr nur die Richtungstasten abfragen lasst. Weiterhin solltet ihr den Haken bei "Wait for Key press" aktivieren. Speichert die Abfrage in der Variable "Tasten-ID".
Dann noch eine Fork-Condition, in der abgefragt wird, ob die Variable "Tasten-ID" kleiner-gleich 4 ist.
Erstellt dann das Label Nr. 2.
Ab hier wirds ein wenig kompliziert, da ab hier der Arbeitsaufwand anfängt. Ich werde mich ab hier auch kurz fassen. Erklärungen gibts später.
Ändert das Aussehen des Charakters per Move-Event auf Animationsstufe 1.
Erstellt ein 0.0s-Wait.
Lasst die Richtungstasten abfragen und den Wert in der Variable "Tasten-ID" speichern. Entfernt den Haken bei "Wait for Key press".
Erstellt eine Fork-Condition, in der abgefragt wird, ob die Variable "Tasten-ID" gleich 0 ist. Erstellt in der Fork-Condition den Befehlt "Go to Label Nr. 1".
Wiederholt die 3 Schritte ab dem 0.0s-Wait noch zwei mal (so dass insgesamt 3 0.0s-Waits da stehen, dreimal die Richtungstasten abgefragt werden und dreimal die Variable "Tasten-ID" abgefragt wird).
Immer nach drei Schritten wird eine neue Animationsphase angezeigt.
Der Grund, wieso immer nach 0.0s (also 1/60 Sekunde bzw. einem Frame) die Tasten abgefragt werden, ist, dass bei nicht gedrückter Taste das CharSet wieder auf die Standpose zurückgeschalten werden muss. Man könnte es natürlich auch einfach alle 0.1 Sekunden oder so machen, aber es würde nunmal einfach eigenartig aussehen, wenn der Char nicht sofort stehen zu bleiben scheint.
Alles weitere entnehmt ihr bitte folgendem Skript, das ich schon fertig gestellt habe (alle Ressourcen sind frei verfügbar, omg)
Klick mich
Zu guter Letzt noch ein paar Kleinigkeiten, die wissenswert sein könnten/dürften/sollten/möchten/wollten, oder die ich einfach mal gesagt haben wollte, weil ichs meistens so mache:
- Ein 0.0s-Wait entspricht 1/60 Sekunde, was wiederrum einem Frame im Maker entspricht.
- Maker-Spiele laufen im Vollbild immer auf 60 fps. Im großen Fenstermodus laufen sie auch im Hintergrund mit 60 fps, werden auf einigen Rechnern allerdings auf 30-40 fps gedrosselt. Im kleinen Fenster-Modus werden sie mit der Anzahl an Frames angezeigt, wie die derzeitige Bildwiederholrate eingestellt ist (Beispiel: Ist die Bildwiederholrate des Monitors auf 85 Hz eingestellt, werden die Maker-Spiele im kleinen Fenstermodus mit 85 fps abgespielt).
- Pictures erscheinen immer über Battleanimations.
- Es ist auch ohne Tastenpatch möglich, ein voll funktionsfähiges Schräglaufskript zu skripten
- Notizbücher wirken Wunder. Schafft euch ein Notizbuch an, in das ihr eure Storyeinzelheiten, Ideen, Charakter-Infos usw. reinschreibt. Ist nützlich, da man dadurch meist neue Ideen hat, während man da andere noch am Schreiben ist.
- Schreibt euch am besten exakt auf, für was welcher Switch und welche Variable im Spiel zuständig ist. Insbesondere bei eigenen Kampfsystemen kann man da schonmal durcheinander geraten. Weitehrin hilft euch dies, aussortieren zu können, welche Switches/Variablen ihr gar nicht braucht oder welche ihr sogar mehrfach für verschiedene Aktionen verwenden könnt.
- MIDIs > MP3s
- Ihr könnt MIDIs im Maker ab einem von euch bestimmten Punkt wiederholen lassen. Hierzu braucht ihr ein MIDI-Programm, das MIDI-Funktion seperat einfügen kann (z.B. Logic Fun, Magix Music Studio, etc.). Öffnet das MIDI-File mit diesem Programm und sucht die Stelle, von wo aus ihr das Lied wiederholen lassen wollt. Öffnet die MIDI-Spur 1 und fügt an dieser Stelle die Control-Funktion Nr. 111 ein.
Speichert das MIDI ab und importiert es in den Maker. Ideal für Kampfmusiken, Nach-Kampf-Musiken oder diverse andere Lieder, die zwar ein musikalisches Intro erfordern, dieses aber wirklich nur einmal abgespielt werden soll.
- Eine Story und deren Umsetzung ist wichtiger als die Grafik.
- Die Grafik ist wichtiger als die Technik.
- Die Technik ist wichtiger als krampfhaft ausgedachte Features, die eh keinen Sinn ergeben oder für das Spiel nciht zwangsläufig wichtig sind.
- Wird die Grafik eines Helden per Move-Event geändert, ist die Änderung nur solange aktiv, bis das nächste Teleport-Event einsetzt. Ändert man die Grafik stattdessen per "Change Hero Appearance", ist die Änderung dauerhaft und wird auch mit Speicherständen gespeichert.
- Chipset-Tiles, die wieder und wieder und wieder verwendet werden, sind nichts schlimmes.
- Es gibt keinen Löffel.
-![]()
- "Lies das E-Book"-Gelaber ist unnötig, wenn man nicht wenigstens den Link dazu postet(Oder einfach die Stelle aus dem E-Book kopiert und postet).
~ V-King