Beiträge von Tamschi

Okay, also: Update! Dynamic Pictures hat jetzt eine Web-Demo und kostet $20 statt $15 (außer ihr habt schon Dynamic Character, dazu gleich mehr), ist dafür aber auch deutlich gewachsen, denn es gibt jetzt

Modifikatoren,

bzw. "modifiers", die ihr dynamisch auf Bilder anwenden könnt:

Ihr könnt euch das wie stapelbare visuelle Stile vorstellen, die auch (kompatibel zu CSS-<easing-function>s) animiert sein können. Das kann wie gehabt regelbasiert sein, aber ihr könnt die Stile auch per Plugin-Befehl kurz forcieren. Falls der Modifikator gerade mitten in der Animation steckt und sich ändern soll, dann dreht diese auch genau an der Stelle um und läuft mit der neuen Geschwindigkeit in die andere Richtung weiter, was meiner Meinung nach ziemlich smooth aussieht.

Modifikatoren sind (in leicht erweiterter Fassung) auch in

Dynamic Characters

verfügbar, also für die Sprites, die auf der Karte angezeigt werden:

Es gibt auch ebenenbasierte Variationen (wobei ihr einen "großen" Charakter auf alle 8 Slots eines Spritesheets anwenden könnt, ohne die Grafik zu kopieren), die auch auf dem Speicherbildschirm funktionieren (aber noch nicht auf anderen Fenstern. Ich arbeite langsam daran...):

Eine weitere Besonderheit ist, dass diese Modifikatoren in 3D definiert werden können und sich (mit JavaScript) durchgehend animieren lassen:

Ihr könnt damit also auch Charaktere teils eintauchen oder ganz tauchen lassen (auch bei gleibleibender Position auf dem Bildschirm) und die visuelle Reihenfolge ändern. Ich habe gerade keinen Bildschirmfoto davon, aber wenn ihr Charaktere dreht, dann wird beim eintauchen auch immer die "tiefstliegende" Seite transparent. Kopfsprünge und Bauchplatscher sind damit also auch möglich (wobei dieses Plugin allein vielleicht nicht so gut für komplexe Animationen geeignet ist).

Als letzte Zusatzfunktion gibt es hier zusätzlich zu "Tint" noch "Fade", mit der ihr Charaktere multiplikativ färben könnt.

Vielleicht eignet sich das z.B. für schickere Schatten, da ihr mit den Regeln auch auf die Kacheleigenschaften reagieren könnt und die Animationsgeschwindigkeit an die Laufgeschwindigkeit angepasst werden kann (wie teilweise in dem ersten GIF).

Dynamic Characters kostet auch $20. Da sich diese Plugins relativ viel Code teilen, wird das jeweils andere aber $5 günstiger, falls ihr schon eines davon habt.

Moin und Frohe Feiertage!

Ich war mal wieder ewig lange verschwunden weil offline einiges passiert ist, aber ich habe seit meinem letzten Post hier wenigstens eine Handvoll neuer Plugins hochgeladen.

Ich stelle euch mal kurz die vor, die gratis sind:

R-Stick Mouse

Dadurch kann durch Neigen des rechten Sticks auf dem Gamepad ein virtueller Mauszeiger eingeblendet und gesteuert werden.

Der Mauszeiger ist dabei ein "Bild", also kann er auch mit Dynamic Pictures angepasst bzw. inzwischen auch animiert werden.

Eine Webdemo ist hier mit dabei. Ich meine, es besser hinzubekommen haben als die meisten größeren Konsolenspiele

(Es gibt auch ein Optionsmenü für Geschwindigtkeit und Deadzone. Falls ihr eine alternative Optionsszene benutzt, dann solltet ihr diese Optionen unbedingt dort einbinden.)

Message Autoplay (kommerzielle Nutzung: $5)

Das ist ziemlich genau äquivalent zur "Auto"-Funktion in Ren'Py: Solange es (per Button-Sprite oder Taste) aktiviert ist, enden manuell-bestätigte Textpausen nach entsprechender Zeit automatisch. Es gibt auch ein Optionsmenü, wo Spieler die Geschwindigkeit(en) und wann das Spiel automatisch anhalten soll einstellen können.

Sketch-Plugins

Das sind (bisher sieben) Miniplugins ohne garantierte technische Unterstützung jedweder Art, dafür aber komplett gratis.

Die meisten (Chip Damage, Chip Healing, Nested Text Escapes, Through off-Map, Zero Damage Fake Evasion, Zero Damage Fake Miss) ändern gerade einmal eine Funktion in der Engine und sind quasi gemeinfrei. Picture Tasks ist minimal komplexer: Ihr könnt damit je Bild ein Gew. Ereignis per Plugin-Befehl als parallel laufenden Prozess anhängen. Das funktioniert meines Wissens nach auch im Kampf.

Der Hintergrundprozess bricht sofort ab, falls ihr über die Bildnummer ein neues Gew. Ereignis startet oder das Bild ersetzt oder entfernt. Es gibt auch einen expliziten "Stop"-Befehl.

Das war es soweit erst mal mit den Gratisplugins, teils da ich gerade keine Ideen mehr habe und teils weil ich eigentlich nicht so viel Zeit investieren wollte.

Ich nehme aber trotzdem weiterhin Miniplugin-Wünsche an, solange mich das jeweils weniger als eine Stunde kostet.

Falls ich dazu komme, aktualisiere ich später noch das "Dynamic Pictures"-Thema, da sich dort einiges getan hat.

Ja, das ist ein Plugin. Einfach so in eine .js-Datei einfügen und aktivieren, mehr sollte es nicht brauchen.

Eventuell noch

/*:
 * @target MZ
 */

drüberschreiben, damit es keine Warnung gibt.

Falls nichts passiert, dann wird die Funktion eventuell von einem anderen Plugin überschrieben. Setz dieses hier am besten ganz unten in die Liste.

Das Update ist jetzt online, mit Web-Demo: Dynamic Pictures MV + MZ

Ich muss noch die Screenshots und den Seitentext aktualisieren, gestern war es dann doch sehr spät, als die Demo endlich so lief, wie ich mir das vorgestellt hatte.

Ich habe auch mal meine Typdeklarationen hochgeladen: My .d.ts

Das kommt spät, aber dieser Code sollte funktionieren:

const oldCreateWeaponSprite = Sprite_Actor.prototype.createWeaponSprite;
Sprite_Actor.prototype.createWeaponSprite = function () {
  const result = oldCreateWeaponSprite.apply(this, arguments);
  this._weaponSprite.y -= 5;
  return result;
};

Das verschiebt alle Waffen um 5 (canvas-)Pixel nach oben.

(Der oldCreateWeaponSprite-Aufruf geht auch einfacher, aber diese Methode funktioniert wirklich bei absolut jeder Funktion.)

Ich bin mal wieder extrem anderweitig beschäftigt (wann nicht?), schraube aber nebenbei ein bisschen an meinen Plugins: https://www.youtube.com/watch?v=jsL06HbAJCg

(Leider weiß ich immer noch nicht, wie ich hier YouTube einbette )

Jedenfalls kann ich jetzt regelbasiert "Modifikatoren" auf Bilder anwenden, auch mehrere gleichzeitig, die jeweils anhand eines CSS-easings animiert werden.

Musste ich in JS implementieren, da es scheinbar keine Browser-API dafür gibt. Das bedeutet allerdings auch, dass man leicht via JS weitere Easingtypen definieren kann.

(Für cubic-bezier(…) habe ich allerdings eine Minibibliothek verwendet, das hätte ich von Hand nicht ohne sehr viel Aufwand so gut hinbekommen, da CSS da nicht über "t" animiert.)

Im Video schalte ich eine Variable um, das kann aber auch basierend auf einem Statuseffekt ausgelöst werden und so.

Man sieht auch ganz gut, dass der Übergang zwischendrin umkehren kann. Es gibt also keine Sprünge, es sein denn die Dauer wird auf 1 Frame gesetzt oder man benutzt ein steps(…)-easing.

Der Ankerpunkt für Skalierung, Drehung usw. ist relativ zur Textur frei wählbar, kann sich aber verschieben, falls mehrere solche Modifikatoren und gleichzeitig lokale Verschiebung und "Skew" benutzt werden. Ich denke aber, das ist soweit normal und wird für die meisten Spiele irrelevant sein

Eigentlich wollte ich nur einem Freund beim VN-Programmieren helfen, aber es ist wahrscheinlich auch für anderes hilfreich

Den Blend Mode kann man so auch umschalten, aber das wird nicht animiert, sondern genutzt, solange der Modifikator 50% oder mehr angewendet ist.

Ich glaube aber, da sollte man in den meisten Fällen stattdessen GPU-Filtereffekte benutzen, da die dann sauber überblendet werden können. Ich habe aber gerade keine Lust, mich da richtig einzulesen, sonst hätte ich das wahrscheinlich auch noch unterstützt.

Zitat von Jollo

Kannst du mir ein paar typische Dinge nennen, die Plugins inkompatibel machen? Wie kann man sowas, aus deiner Sicht, am besten vermeiden und was für Dinge musstest du bisher ändern? Würde mich interessieren, damit ich das in Zukunft direkt mit beachten kann. Selbst habe ich noch nicht so viele Plugins ausprobiert und hatte daher auch noch nie Probleme.

Ich beantworte das mal.

- Namenskollisionen bzw. unachtsame Nutzung globaler Variablen.

Das lässt sich leicht durch strict-mode und eine IIFE um den Code lösen (wobei ich da stattdessen gern einen try/catch-block verwende, da MV etwas Hilfe beim Anzeigen von Fehlern beim Pluginstart braucht).

Wenn es eine JS-API gibt, dann sollte diese durch eine einzelne globale Variable mit dem Namen des Plugins erreichbar sein.

- intransparentes Ueberschreiben von Methoden bzw. die Aenderung von Aufrufsignaturen.

Also wenn einfach eine neue Version der Funktion eingefuegt wird und es keinen return old.apply(this, arguments);-Aufruf gibt. Ich persoenlich schreibe das auch dann so rein, wenn es weder parameter noch einen Rueckgabewert gibt, da ich nicht weiss, ob jemand anderes an der Stelle diese Regel verletzt.

- Aenderung von Objekten aus der Spielengine selbst.

Dies fuehrt oft zu Namenskollisionen. Man kann den Namen der Properties den Namen des Plugins voranstellen, aber ich benutze stattdessen normalerweise eine WeakMap, da ich nicht moechte, das andere an der Stelle die API meines Plugins umgehen.

(Fuer CustomTraits wuerde ich ein concat auf das Ergebnis von Game_Actor.prototype.currentClass machen, statt das Datenarray zu aendern. Das ist erstmal sauberer und es kann ja sein, dass in den urspruenglichen Daten absichtlich Duplikate vorkommen.)

- keine API / nicht-modifizierbare Hooks

Die oeffentlichen Funktionen des Plugins und solche, die nuetzlich sein koennten, sollten anderen Plugins zur Verfuegung stehen. Fuer die Hooks schreibe ich normalerweise sowas hier:

const api = window[MY_PLUGIN_NAME] = {
  version: {
    featureLevel: 2,
    patchLevel: 0,
  },

  /** @since 1.1.0 */
  oldA_ClassAMethod = A_Class.prototype.aMethod,
  ...(A_Class.prototype.aMethod = function () { return api.newA_ClassAMethod.apply(this, arguments); }, {}),
  newA_ClassAMethod(some, parameters) {
    // Your code here.
    const result = api.oldA_ClassAMethod.apply(this, arguments);
    // Your code here.
    return result;
  },
};

Sieht etwas nervig aus, aber dadurch koennen sich andere Plugins dann vor oder nach diesem Aufruf einklinken oder ihn deaktivieren, ohne dass etwas an meinem Plugin geaendert werden muss. (gut fuer Updates, auch die Versionierung)

- Aenderungen am Aufrufkontext.

Wenn man das Verhalten von Szenen anpasst, muss man z.B. auf Scene_Boot achten, da waerend dieser Szene die Spieldaten noch nicht initialisiert sind. Es kann auch bei neuen Kampfmodi solche Probleme geben, falls andere Plugins eine bestimmte Phasenreihenfolge voraussetzen.

Man kann nicht immer alle Probleme vermeiden, aber meistens geht's ziemlich gut.

(Das ist kein sauberes JSDoc, aber ich glaube das kriegt man bzgl. RPG Maker auch kaum 100% korrekt hin waerend der Quellcode noch lesbar ist.)

Zitat von I.Z.

Uh willst du dabei ins Detail gehen, um was für Projekte es sich handelt?

Nein, habe ich aus privaten Gründen nicht verlinkt

(Ich sollte vielleicht klarstellen, dass der Content nichts problematisches ist, nur definitiv ein bisschen zu spicy für hier.)

@I.Z. Ich tu' mich mit den Kreativaspekten etwas schwer, aber ich bin in mancher Hinsicht sowieso eher ein "Leser". (Mir fehlt glaube ich auch einfach die Übung.)

Ab und an helfe ich allerdings (indirekt) bei ein/zwei Spieleprojekten aus, die ich mag, und bastle (seeeehr langsam) an einem Mini-Fangame wenn ich die Muße dazu habe.

Mit Steam Link geht's sogar auf dem Handy

Aber nicht unterwegs, wobei die Steuerung und Latenz bei mir auch echt zu wünschen übrig lässt (aber mein Handy ist nicht schnell).

Es gibt recht gute Windows- bzw. x86-Tablets, aber ich glaube die sind meistens auch viel schwerer und mit Windows nicht so schnell.

Auf meinem habe ich Linux drauf, was Energieprobleme und Leistung korrigiert, aber da geht ja MZ nicht.

Zitat von Tamschi

Jedenfalls komme ich mal kurz aus meiner zu-viele-Projekte-bedingten Versenkung, weil ich ein kleines Plugin als Auftragsarbeit gemacht habe: R-Stick Mouse MZ

Wie der Titel besagt, ist das ein Mausemulator für Gamepads. Einfach einschalten und euer Spiel geht per Gamepad als Point-and-Click. (Drag&drop geht auch.)

So, jetzt auch für MV. Das war dann doch etwas mehr Arbeit.

Ich habe eine Hover-Funktion für MV eingebaut, damit man allgemein nicht dauernd überall in den Menüs doppelklicken muss. Funktioniert wie in MZ.

Per Touchscreen sollten aber nach-wie-vor zwei Taps nötig sein.

Zitat von Gex83

[…]

Zum Tagesausklang ein bisschen Fernweh. Ist ein Übergang zu einem Gebirgsmoor.

Ich liebe diese Art von Szene. Ist das eine Ebene an Parallax oder mehrere?

(Das wäre auch mal wieder eine gute Pluginidee, aber das gibt es schon.)

Jedenfalls komme ich mal kurz aus meiner zu-viele-Projekte-bedingten Versenkung, weil ich ein kleines Plugin als Auftragsarbeit gemacht habe: R-Stick Mouse MZ

Wie der Titel besagt, ist das ein Mausemulator für Gamepads. Einfach einschalten und euer Spiel geht per Gamepad als Point-and-Click. (Drag&drop geht auch.)

Ich bin dafür schon bezahlt worden, deshalb ist das komplett kostenlos und MIT-lizensiert, obwohl's technich meinen kommerziellen Plugins entspricht.

Ich habe unvernünftigerweise ein ziemlich komplexes Rust-Projekt gestartet (so -artig) und mache deshalb eventuell für eine Weile (ein paar Wochen) etwas langsamer bei RPG Maker. Nicht, dass ich aktuell besonders schnell dabei wäre, aber naja. Falls was daraus wird und ich es veröffentliche, erwähne ich es wahrscheinlich mal hier im Forum.

(Das sollte sich nicht auf den Support bei meinen Plugins auswirken, außer dass ich vielleicht mal zu tief in der Materie bin und dann eine Nachricht nicht so schnell sehe.)

Zitat von Baxeda

Ah, jetzt habe ich es verstanden, danke für die Erhellung! Für eine sehr große und sehr lange Explosion im "Auserwählten" hätten wir das zum

Beispiel gut gebrauchen können, aber da es so etwas nicht gab, haben wir uns mit den Möglichkeiten des Makers durchgemogelt. Aktuell benötige so etwas also momentan nicht, kann mir aber vorstellen, dass das für Leute interessant sein könnte, die gern aufwändige Kampfsequenzen oder Effektanimationen verwenden möchten.

Man kann sonst glaube ich auch recht einfach ein "Play Movie"-Video transparent über den Bildschirm legen.

Ich habe das nicht getestet, aber wenn man Graphics._updateVisibility bzw. im MZ Video._updateVisibility so anpasst, dass der Haupt-<canvas> nicht versteckt wird, dann müsste man den hinter transparenten Videos noch sehen. Wenn man das nicht als veröffentlichtes Plugin ausarbeitet, dann sind das geschätzt 5-6 Zeilen JavaScript, um es an einen Schalter zu binden.

Das müsste auch in einem parallelen Ereignis funktionieren, wenn dadurch der Spielablauf nicht blockiert werden soll. Das Spiel wird durch Videos soweit ich beurteilen kann nicht angehalten oder sonstwie pausiert, das blockiert nur den Interpreter der das Video angezeigt hat. Müsste auch als Dauerschleife klappen.

Ich denke nicht, dass ich eine Demo schneller hinbekommen würde als das Plugin selbst.

Aber ja, es macht wahrscheinlich keinen Sinn. Bewegliche Objekte sind mit animierten Doodads schon gut abgedeckt, für Kämpfer und Charaktere habe ich schon meine eigenen Plugins, und quasi alles andere ist endweder eh animiert oder lässt sich wegen Caching auf diese Weise nicht animieren. Im Endeffekt wäre die einzige Verbesserung, dass man eine Animationsfunktion wie von Tilesetseite A1 auf allen anderen Tilesetseiten unabhängig nutzen könnte und dabei keine Vorgabe der Frameanzahl hätte.

Wenn ich es mit Einzel-PNGs implementieren würde, dann wäre das in Sachen Performance quasi nicht messbar, denke ich, aber selbst ein optimiertes Plugin ist nutzlos wenn man es eh nicht braucht

Zitat von ChimaereJade

Da ich technisch nur über sporadisch es Halbwissen verfüge, finde ich es immer wieder spannend wenn Du einem hier neue/weitere Erkenntnisse über die Funktionsweise des Malers erläutern kannst.

Besten Dank dafür!

Dazu muss ich noch etwas nachtragen: Das Tileset wird in den meisten Frames tatsächlich der Effizienz halber nicht neu gezeichnet, mit animierten Bitmaps wäre das also (standardmäßig) im Takt der Wasseranimation, 2 mal pro Sekunde. Man kann aber einfach .refresh() aufrufen und dann wird es doch neu gezeichnet.

Zitat

Es gibt ja auch (zumindest für MV und MZ wohl auch) Plugins für frei platzierbare Objekte (habe den Namen gerade vergessen), welche ähnlich wie Decals das Mapping erweitern.

Wenn man die dahinter stehende Technik noch eleganter lösen könnte, hätte man wohl durchaus einen Mehrwert geschaffen.

Diese Grid-Free Doodads von Yanfly bzw. VisuStella?

Ich müsste da mehr dazu wissen, was da das Problem ist.

Die Yanfly-Plugins sind technisch okay, soweit ich beurteilen kann. Das einzige Manko ist, dass die so programmiert sind, dass es leichter zu Konflikten mit anderen Plugins kommt. Zur Entwicklungs-UX kann ich allerdings nichts sagen, da ich das Plugin selbst nicht habe bzw. nutze. Ist nur in einem der Spiele dabei, die ich hier auf der Festplatte habe. Von der Laufzeiteffizient her ist YEP_GridFreeDoodads quasi genau so wie Ereignissprites, habe da nichts dran auszusetzen.

Die VisuStella-Plugins haben alle diese nervige Quellcodeverschlüsselung, die wohl auch zur Laufzeit ordentlich Leistung kostet.

"Nervig" daher, dass ich dadurch auch keine Kompatibilität mit diesen Plugins garantieren kann. In der Praxis gibt's meistens trotzdem keine Probleme, aber falls doch kann ich's halt nicht (so einfach) reparieren.

Zitat von ChimaereJade

Dass Gifs weniger effizient laufen sollen als Videos - gerade wenn man nur von wenigen Frames ausgeht, überrascht nicht ziemlich.

Könnte man alternativ eine Bildfolge abrufen, wie sie in einigen Programmen für Animationen verwendet wird? Also beispielsweise durch reine Benennung und Ablage in einem eigens dafür vorgesehenen Ordner?

Beispiel:

Baum_animiert00

Baum_animiert01

Baum_animiert03

usw.

Ich kann mir aber gut vorstellen, dass sowas im Hinblick auf den Video-Speicher nur stark dosiert ratsam wäre, da sonst der Zwischenspeicher schnell überflutet wird, wenn man etliche "Slots" in den Tilemaps durch solche Grafiken ersetzt.

Alles anzeigen

Das ginge an sich. Eine Bitmap ist ja ein Maker-eigenes Bündel aus Eigenschaften, das kann ich (vermutlich) recht einfach auch anders implementieren und dann wechseln. Sehr effizient ist das auch, macht sich zur Laufzeit quasi nicht bemerkbar, sodass da die einzige Grenze wirklich der Videospeicher ist.

Die meisten Maker-Texturen, bei denen das Sinn machen würde, sind nicht wirklich hochauflösend.

Tilesetseiten im MV kosten wahrscheinlich zwischen 1,2 und 1,6 MB VRAM, sodass da ca. 500 zusätzliche Texturen von der Größe wohl realistisch sind, bevor man was an der Bildrate merkt (zumindest für installierte Spiele, im Browser ist das eventuell stärker begrenzt). Das größte Problem wären die Ladezeiten, im MZ (viel) mehr als im MV, da der MZ Ressourcen weniger effizient verwaltet. Videodateien werden soweit ich weiß oft auf der Grafikkarte dekodiert oder sonstwie beschleunigt, bei Bilddateien ist das leider sehr selten möglich.

Bei Bildern, die auf Fenster gezeichnet werden (inkl. denen in img/faces/ und vielen Icons) funktioniert das alles aber leider erstmal nicht. Da müsste man erst das Bild durch einen Sprite ersetzen.

Zitat von Kirimoar

Hmm - ich tu mir gerade schwer zu verstehen was damit genau gemeint ist

Also, ok, Video einbinden - aber was ist mit "in Texturen laden" gemeint?

Könnte mir vorstellen z.B. bei einem Fluss reale Grafiken einzubauen - sowas in etwa?

Wäre interessant zu wissen wie das aussehen könnte. Nicht gut für die Performance ist gerade beim MV Maker natürlich leider generell eher suboptimal

Alles anzeigen

Ja, zum Beispiel. Man könnte dann auch Videodateien mit Show Picture nutzen. Wobei ich nicht weiß, wie das mit dem Abspielen aussehen würde, wäre wahrscheinlich eine unkontrollierte Dauerschleife. (Ich verwende den Maker immer auf Englisch, daher habe ich die deutschen Namen nicht immer parat.)

Wenn die Bildrate und Auflösung Makertypisch gering sind, dann sollte es flüssig(er) laufen. Ich glaube nicht, dass die Daten durch den Hauptspeicher geladen werden müssen.

Zitat von ChimaereJade

Wenn ich das richtig verstanden habe, dann würde ich wohl eher auf GIFs zum Erweitern der Makergrenzen bei den Tilesets setzen, anstelle auf Videodaten. 3-6 Frames könnten hier bereits vieles möglich machen, ohne hoffentlich zu stark auf die Performance drücken.

Vielleicht wäre das ja eher eine Überlegung wert, um beispielsweise sonst nicht animierte Boden-Texturen oder Detailobjekte wie Bäume leicht zu animieren.

Das funktioniert leider nicht (annähernd so einfach). Es gibt zwar ein PixiJS-Plugin für GIFs, aber das wirft keine Texturen aus, weshalb sich das hierfür nicht gut nutzen lässt.

GIFs sind leider auch ineffizient verglichen mit quasi allen anderen Formaten und würden die Performance wahrscheinlich stärker drücken als Videos.

Es ist ja mit PixiJS ziemlich einfach, Videos in Texturen zu laden. Ich überlege gerade, ob ich mich mal dransetzen soll, diese Funktion auch im RPG Maker leicht nutzbar zu machen. Mir fehlt allerdings etwas die Problemstellung dazu, bzw. weiß ich nicht, ob das überhaupt jemand haben wollen würde. Ist auch nicht gut für die Performance, je nach Video und Anzahl.

Macht das Sinn? Würdet ihr sowas nutzen? Wenn ja, wofür?