Beiträge von Tamschi

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?

Ich konnte während der letzten Woche kaum was tun, habe dafür aber gestern und heute ein neues Plugin und ein Update veröffentlicht.

Dynamic Actors erlaubt die gleichzeitige Kontrolle von Dynamic Characters und/oder Dynamic Pictures, eignet sich also vor allem, um Grafiken für die Spielcharaktere einzurichten. Ich habe auch ein paar Extrafunktionen für NPCs mit eingebaut und da dieses Plugin quasi nur die anderen beiden automatisiert ist es gratis.

Bei Live Menu and Pause hatte ich mir wohl anfangs etwas zu viel vorgenommen und dann ein halbes Dutzend subtile Fehler nicht bemerkt. Die sind jetzt behoben, sodass z.B. Spieler nicht mehr aus Versehen mit offenem Menü Ereignisse aktivieren können. (In-Spieler-Hineinrammen und automatische/parallele Events funktionieren trotzdem.)

Die eigentliche Motivation für das Update war aber, die Option hinzuzufügen, das Hauptmenü bei laufenden Ereignissen automatisch zu schließen, damit es in Spielszenen nicht im Weg ist. Parallel laufende Ereignisse und solche, die "sofort" abgeschlossen sind, schließen das Menü allerdings nicht, damit es nicht zu unnötigen Unterbrechungen kommt.

Zitat von I.Z.

Tamschi meeegaaa niceee!!!

Hoffe, der Papierkramstapel ist gleich mitabgearbeitet worden?

Leider ist der etwas größer, aber ich mache Fortschritte. Habe mir noch ein paar Aufbewahrungsboxen für lose Zettel ausgedruckt, damit ich Quittungen sortieren kann.
(Ich kann einige davon noch einreichen, was mir hoffentlich ein bisschen mehr finanziellen Freiraum beschert.)

Zitat von ChimaereJade

Tamschi
Sorry, jetzt warst Du mir bei den Wortmelungen untergegangen. Ich finde solche "Visual Equipment"-Plugins immer super nützlich - gerade wenn man eine Vielzahl an Ausrüstungskombinationen in seinem Spiel hat! Aber auch wenn man sich anfangs im Spiel einen Charakter selbst zusammen basteln kann, hat solch ein Plugin einen großen Mehrwert!
Wie schaut es denn mit der Performance aus? Kann man sagen, dass diese bei einem ~5-10 Jahre alten PC weniger ins Gewicht fällt?

Ist (auf diesem schnellen PC) nicht wirklich messbar, weil der Performance-Impact selbst im Debug-Modus zu gering ist.

Alles was ich sagen kann ist, dass es für alle Sprite_Character zusammen in meinem Test weit weniger als 1ms kostet. (Über 5 Sekunden/~300 Frames taucht das 3 mal auf bei 1ms Abtastrate, ich tippe also auf ca. 0.01ms pro frame für 26 sprites oder ~0,4µs pro Sprite (mit großer Ungenauigkeit).)

In einem echten Spiel mit höherer Anzahl von Ausrüstungsitems ist das sicher etwas mehr, aber solange die Bilder gleich sind kann man auch Regeln mit mehreren Ausrüstungsgegenständen definieren.

Ich habe das jetzt nicht extra dafür verzweigt, wenn es gar keine Regeln für einen Sprite gibt, weil es eh schon sehr schnell ist. Ich kann jetzt nicht aus dem Stehgreif sagen, ob es dadurch schneller oder langsamer würde. Vielleicht ein paar Prozent schneller, aber man würde es höchstwahrscheinlich selbst auf alten PCs nicht merken.

Das Zusammensetzen der Bilder passiert rein auf der GPU ohne Rücklesen, wird aber auch im RPG-Maker-eigenen Cache abgelegt und daher in der Regel nicht wiederholt. Der Ladevorgang ist weiterhin größtenteils asynchron (nur gepuffert, um Flackern zu vermeiden), in sofern wird's nicht ruckeln solange es nicht eh schon Ruckler gibt.

Die Messungen habe ich mit der ~5 Jahre alten NW.js-Version die bei MV dabei ist gemacht. Falls ihr die aktualisiert wird das Spiel insgesamt noch mal schneller, einfach weil dann JavaScript allgemein schneller läuft.

Zitat von Tamschi

Dazu am Rande: Ich arbeite gerade an einem Plugin, mit dem man Charaktersprites (also die Kartengrafiken für Akteure, Ereignisse und Fahrzeuge) dynamisch zusammensetzen kann. Bisschen so wie der Generator, nur eben regelbasiert zur Laufzeit. Dauert allerdings noch ein wenig bis es öffentlich ist, weil ich diese Woche wahrscheinlich keine Zeit habe, mich um das Testen und die Veröffentlichung zu kümmern.

Mein eigentliches Ziel dabei ist, die aktuelle Ausrüstung der Akteure anzuzeigen (bzw. kleine Staubwolken oder Wassertropfen, wenn jemand durch Sand oder Pfützen läuft), aber sowas geht damit denke ich auch.

Das ist jetzt fertig: Dynamic Characters

War dann am Ende doch noch etwas mehr Arbeit, aber ich fühle mich heute wahnsinning produktiv und habe das vorhin nach einer anderen größeren Sache auch noch fertiggemacht. Und jetzt muss ich mal schauen, was ich mit dem Rest des Tages so mache, außer mich langsam durch den Stapel Papierkram hier neben mir zu wühlen

Zitat von I.Z.

[…]

Außerdem habe ich Lunee und Co massiv verkleinert, damit ihr Weltkartensprite nicht genauso groß ist wie die Ereignisse selbst. Aber da wir es besonders kompliziert mögen, musste ich das nicht nur 1x machen sondern 6x, da dreimal unterschiedlicher Van und dreimal unterschiedlicher Van + mysteriöser Compagnon Nr. 1.

Dazu am Rande: Ich arbeite gerade an einem Plugin, mit dem man Charaktersprites (also die Kartengrafiken für Akteure, Ereignisse und Fahrzeuge) dynamisch zusammensetzen kann. Bisschen so wie der Generator, nur eben regelbasiert zur Laufzeit. Dauert allerdings noch ein wenig bis es öffentlich ist, weil ich diese Woche wahrscheinlich keine Zeit habe, mich um das Testen und die Veröffentlichung zu kümmern.

Mein eigentliches Ziel dabei ist, die aktuelle Ausrüstung der Akteure anzuzeigen (bzw. kleine Staubwolken oder Wassertropfen, wenn jemand durch Sand oder Pfützen läuft), aber sowas geht damit denke ich auch.

Zitat von Coucassi

Ben  Tamschi ich bin mir jetzt nicht sicher, Tamschi hat da auf jeden Fall mehr Expertise als ich, aber solange man alle Battler auf den Bildschirm und ins Menü bekommt dürfte es eigentlich gar kein hartes Maximum für die Anzahl möglicher Kampfteilnehmer geben, oder?

Da ist (abgesehen von Problemen mit der Benutzeroberfläche) kein hartes Limit, ja.

Ich hab' vor einiger Zeit ein Scherz-Spiel mit 100 Kämpfern gleichzeitig gesehen und das lief (im Browser) noch relativ gut. War natürlich quasi unspielbar.

Zitat von Ben

Nur interessehalber was ist dabei das Maximum?

Ups, ich hatte vergessen, eine 4 durch 6 zu ersetzen

Überall wo jetzt 6 steht, bzw. 7 als maximum + 1.

Ja, das wird durch die Funktion Game_Party.prototype.maxBattleMembers geregelt.

Wenn du also (in MV oder MZ)

Game_Party.prototype.maxBattleMembers = function() {
    return 6;
};

Sprite_Actor.prototype.setActorHome = function(index) {
    this.setHome(600 + index * 32 * 4/6, 280 + index * 48 * 4/6);
};

schreibst, dann hast du bis zu 6 Kämpfer wo sonst 4 stehen.

Wobei du rechts index auch durch ((index * 2) % 7) ersetzen kannst. Dann stehen die in bis zu zwei Reihen, was sie vielleicht etwas besser sichtbar macht.

Zitat von I.Z.

Tamschi ich finds richtig nice, wie durchdacht deine Plugins sind und auch wie kreativ sie sind, fetten Respekt. Vllt. sollte ich doch noch coden lernen, einfach um sie mal auszuprobieren

Mein Geheimnis ist, dass ich (oft-nicht-so-)heimlich die Bugtracker, Devlogs und Spielerfeedback der Spiele anderer lese

Da kommt dann einiges zusammen, wobei solche Sachen wie die "Flipbooks"-Serie und reines dev-tooling eher auf meinem eigenen Mist gewachsen sind.

Fast alle meiner Plugins lassen sich allerdings auch ohne JavaScript vollständig nutzen (und sind wahrscheinlich deutlich einfacher zu bedienen als die meisten von Yanfly).

Die JS-API ist eher dafür da, dass, falls mal jemand Erweiterungen oder Änderungen and den Funktionen meiner Plugins braucht, die sauber in einem anderen Plugin implementiert werden können und dass bei Updates dann nichts kaputt geht. Battler Flipbook Sound Effect Events ist z.B. komplett über solche Schnittstellen realisiert.

Falls du dich für die Plugin-Erstellung interessierst, kann ich Eloquent JavaScript, 3rd edition (2018) wärmstens empfehlen. Das Buch ist ziemlich genau auf dem gleichen Stand, der auch von der MV-Runtime standardmäßig unterstützt wird. JavaScript | MDN ist als Referenz extrem nützlich, listet aber auch Funktionen auf, die zu neu sind. (MV entspricht normalerweise Chrome 65, aber falls du die Plugins nur für eigene Spiele nutzt, ist es deutlich besser/einfacher einfach NW.js zu aktualisieren.)

Edit: Ach ja, und Plugin Tutorial for RPG Maker MZ (Google Docs) ist sehr praktisch für alles, was wirklich RPG-Maker-spezifisch ist. Ich benutze das aber eigentlich nur für Parameter und andere Metadaten. Wenn du schauen willst, wie irgendwas in der Engine funktioniert, dann öffne deinen Projektordner mit z.B. VS Code und spring' da mit der Volltextsuche (Strg+Shift+F) zur Definition. function Game_Map und function Scene_Map bringen dich z.B. zur Implementierung der Karten (respektive Logik und Grafisches), und // Show Text oder // Conditional Branch führen zu den entsprechenden Befehlen im Game_Interpreter, der Ereignislaufzeit. Die Kommentare setzte ich auch genau so in meinen Plugins, falls ich mich in existierende Befehle einklinke, damit ich die hooks dann direkt mit-finde.

Die RPG Maker-Engine selbst und die meisten Plugins sind allerdings in einem älteren Stil geschrieben. Ich bin schreibfaul und lass mir gern vom Editor etwas helfen, daher benutze ich eher etwas modernere (aber zu 100% kompatible) Klassensyntax und ein paar eigene Idiome, wie diese Art, mich in Engine-Funktionen einzuklinken:

'use strict';

// Dateiname ohne Endung. Ist manchmal praktisch, wenn das zentral geändert werden kann.
const MY_PLUGIN = 'My_Plugin';

const api = window[MY_PLUGIN] = {
  // z.B.
  oldGame_MapUpdate: Game_Map.prototype.update,
  ...(Game_Map.prototype.update = function () { return api.newGame_MapUpdate.apply(this, arguments); }, {}), // "trampoline"-Funktion
  newGame_MapUpdate() {
    // Mein Code hier.
    return api.oldGame_MapUpdate.apply(this, arguments);
  },
};

Für mich ist das praktisch, weil damit alles an einer Stelle liegt. Außerdem können andere Plugins damit sehr zielgerichtet meinen hook ändern oder auch ganz abschalten (My_Plugin.newGame_MapUpdate = MyPlugin.oldGame_MapUpdate;) falls nötig. Falls die Methode etwas spezifischer ist als .update() lass' ich aber meistens den Klassennamen weg.

Ich bin immer noch am Rande meiner Belastungsgrenze was angehäufte Arbeit angeht, aber ich hab' mal wieder ein Plugin fertig: Live Menu and Pause MV + MZ

Meint man wahrscheinlich von der Beschreibung her nicht, aber es war ziemlich kompliziert, das so sauber hinzubekommen. Daher auch der ein bisschen höhere Preis.

Naja, jedenfalls ist das gut für Spiele, die entweder ein bisschen nervenaufreibend oder tiefentspannend sein sollen.

Oder letzteres und dann ersteres, aber Schockmomente im Menü einzubauen ist schon ziemlich fies

Mit dem Menu Editor aus der Super Tools Engine könnt ihr im MV die Menüs etwas ausdünnen, was zusammen mit diesem Plugin nochmal netter aussieht.

(Gibt es schon einen Menü-Editor für MZ? Ich habe ein bisschen gesucht, aber nichts gefunden.)

Die Pause-Funktion funktioniert auch in Kämpfen und bei Videos einwandfrei, das wäre also was bei Echtzeitkämpfen oder falls ihr längere Filmsequenzen habt.

Kleiner Tipp am Rande: Falls ihr ein Tileset-Setup teilen (oder beim selbst veröffentlichten Tileset mitliefern) möchtet, könnt ihr alternativ zu Beispielprojekten auch dieses Tool verwenden: Clipboard Helper for RPG Maker MV (Die kostenlose Version reicht dafür völlig. Ich hab' die "Bearbeitungsfunktion" nur hinter 'ner Bezahlschranke, weil ich dafür nicht umsonst Support machen möchte.)

Ich bin allerdings noch nicht dazu gekommen, das Programm auch mit MZ kompatibel zu machen.

Zitat von Baxeda

Die Vorteile von Party Command Hooks gegenüber Events habe ich in ihrer Funktionsweise aber nicht ganz verstanden. Könntest du mir das vielleicht noch mal in Kurzform erklären?

Es ist rein zur Arbeitseinsparung: Wenn du ich sag' mal 12 verschiedene Truhen mit Items in dein Spiel stellst, dann musst du ja jeweils relativ einzeln:

"Einen Fußball gefunden.", "Ein Schwert gefunden.", "Einen Schild gefunden.", "3 Holzschilde gefunden", "5 Gummihühner gefunden.", usw... Text-Popups schreiben, und dann auch jedes mal anpassen, wenn du die Anzahl oder den Namen von dem Kram änderst. Oder du nutzt ein gemeinsames Ereignis für die Truhen, aber dann ist es schwieriger, die Inhalte individuell anzupassen.

Mit Party Command Hooks kanns du einfach einen von diesen Befehlen in der Truhe direkt verwenden: pasted-from-clipboard.png (die ganzen Parameter und noch ein paar Infos zum Effekt werden dabei vom Plugin in den konfigurierten Schaltern, Variablen und Namen gespeichert) und dann rufst du ein gemeinsames Ereignis auf, das sich wiederverwendbar um die Nachricht an den Spieler bzw. die Reaktion auf ein überfülltes Inventar kümmert und den Self-Switch der Truhe setzt, falls die entleert wurde.

Du musst dann also nur noch ein einziges Mal eine schicke Textbox mit Icons/Farben/Platzhaltern erstellen und kriegst da immer die aktuellsten Infos zum jeweils letzten dieser Befehle.

Zitat von Tamschi

Davon abgesehen baue ich gerade an einem Plugin, das die Infos von den Inventar- und Gruppenänderungsbefehlen abgreift und Ereignissen zur Verfügung stellt:

Ich war tüchtig erkältet und habe das mit dem Vorstellungspost daher noch nicht hinbekommen, aber das ist jetzt fertig: Party Command Hooks

Außerdem habe ich relativ spontan das hier gebastelt, was vielleicht ganz nett ist: Battle Command Descriptions

Müsste auch mit den meisten geänderten Kampfbildschirmen ganz gut funktionieren, jedenfalls geht's schon mal mit Yanfly und VisuStella.

Das Ganze war nicht wirklich Aufwand da klein (Ich habe das Plugin an einem Tag geschrieben weil ich's eh brauche und Testen/Bugfixes/Marketing alles heute gestern (ups, doch schon spät(er)) gemacht.), daher hab' ich's mal versuchsweise zeitlich begrenzt sehr günstig gemacht und haue das jetzt auf allen Kanälen raus die ich kenne. Mal sehen, welche Herangehensweise besser läuft (wobei mein Shop da definitiv nicht statistisch signifikant ist).

Zitat von Lyon

Tamschi

Welche (Social Media) Kanäle strebst du an / nutzt du jetzt?

Hm, ist vielleicht nicht gut zu sehen, weil ich Emojis für die Links benutzt habe.

Ich habe mir erstmal einen mastodon.gamedev.place- und einen Bluesky-Account gemacht.

Twitter habe ich eigentlich keine Lust mehr zu, da wird man ja eh nicht gesehen wenn man nur selten postet.

Reddit habe ich auch und nutze das sporadisch (auch um da mal jemandem weiterzuhelfen), aber das meine Plugins Geld kosten wird da teilweise recht negativ gesehen.

Ich habe mir endlich mal social media accounts für Projektupdates erstellt: 🐘, 🦋

Eigentlich bin ich aber ziemlicher Social-Media-Muffel, also mal sehen, ob das was wird

Davon abgesehen baue ich gerade an einem Plugin, das die Infos von den Inventar- und Gruppenänderungsbefehlen abgreift und Ereignissen zur Verfügung stellt:

Ihr könnt damit dann ein oder zwei Mal eine schicke "Gold gefunden!"- und/oder "Gegenstand gefunden!"-Nachricht implementieren und die dann für die meisten Truhen und so einfach wiederverwenden. Ihr könnt auch eigene Notiztags definieren, über die ihr weitere Schalter, Variablen oder Textbausteine steuern könnt.

Einen Singular zum Plural zu machen ist im Deutschen leider ein bisschen zu kompliziert für die Automatikfunktion, aber ihr könnt das auch ziemlich effizient einzeln über Notiztags festlegen, falls nötig.

Zitat von IanZarewitsch

Ich hab mal ne allgemeine Frage:

Viele von euch besitzen ja praktisch jeden jemals erschienenen Maker. Warum? Wegen der Lizenzen? Einfach weil ihr mit ihnen gewachsen seid, oder weil es neue Features gab, die nicht gehalten haben, was sie versprechen, das aber erst revealed wurde nachdem ihr die gekauft habt?

Wir bleiben auf jeden Fall bei MV und ich zumindest plane nicht mir noch einen weiteren Maker zuzulegen.

Ich verkaufe Plugins, wenn ich sowohl MV als MZ habe, dann kann ich also leicht meinen potentiellen Kundenkreis erweitern

(Fast alle Plugins brauchen keine oder nur minimale Änderungen zwischen diesen Versionen, aber ich muss halt beides haben, um es zu testen.)

Theoretisch könnte ich einige davon wahrscheinlich sogar zu den Ruby-Versionen portieren (die Engine ist nicht groß anders strukturiert), aber die habe ich mir erstmal nur aus Interesse geholt, und weil sie wirklich sehr günstig im Angebot waren und ich wissen wollte, ob es da andere eingebaute Features gibt. Ich kann allerdings auch bisher kein Ruby.

Zitat von Lytharias

Jetzt müsste ich eigentlich, nachdem die Ergebnisfee alle Ergebnisse ausgespuckt hat, einen Plugin Befehl zum "Exportieren"

auswählen können... und daran hapert es.

Jo, da steht zwar "@target MZ" drüber, aber das Teil hat dir das Plugin für RPG Maker MV geschrieben

Der MV-Pluginbefehl dort ist ExportVariables.

Für MZ bräuchtest du eine Befehlsdeklaration und müsstest den Befehl anders registrieren. Ich würde dir da diese Anleitung empfehlen:

- RPG Maker MZ Plugin Tutorial > 4.0 Making a Plugin > 4.2 Deciphering an Official Plugin > Defining Plugin Commands,

- RPG Maker MZ Plugin Tutorial > 4.0 Making a Plugin > 4.3 Explanation about Annotations > Plugin Commands

Java ist komplett anders. Das hier ist JavaScript (was korrekt ist).