Nochmal danke für den Stream und die technischen Ratschläge, genau wie für diesen Tipp. Hab mir den Patch gezogen und werd mal testen, ob das an irgendeiner Stelle zu Problemen führt; wüsste aber grade nicht, wo das passieren könnte.



Bezüglich dessen, was im Stream aufkam:

Das OpenGL-Plugin erfordert, so weit ich gesehen hab, DynRPG-Version 3, während meine exe auf Version 2 läuft. Jetzt hab ich versucht, die auf Version 3 zu updaten, aber dann startet sie einfach gar nicht mehr, ohne Fehlermeldung oder sonst was. Hab dann etwas rumprobiert und kann sagen, dass das am Better AEP liegt, sobald ich eine ansonsten "frische" Better AEP-RPG_RT.exe auf Version 3 update, startet sie einfach gar nicht mehr. Sprich, Better AEP und das OpenGL-Plugin schließen sich aus, was sehr ärgerlich/schade ist. Weißt du vielleicht eine gute Alternative zu Better AEP (Title skippen, Auto Saves und Loads ermöglichen), mit der ich das ersetzen kann?

Die Gegner-Typen sind tatsächlich konsequent alles Skelette oder Knochenhaufen, und das hat auch seinen Sinn und soll eigentlich nicht verändert werden. Allerdings versteh ich natürlich den Punkt, dass die Gegner sich teilweise zu ähnlich sehen (vor allem in den ersten Ebenen, wo die meisten humanoid sind). Über einige der Designs werd ich noch mal drübergehen müssen, um sie besser zu differenzieren, vor allem durch ihre Körperform; jeder Gegner-Typ sollte anhand seiner Silhouette allein identifizierbar sein.

Das Menü. Das ist tatsächlich ein etwas leidiges Thema, sowohl was den Zeitaufwand, als auch die konterintuitive Auswählbarkeit von Passive-Items angeht. Beides hatte ich eigentlich gedacht durch das Q-/W-Feature (also die Schnellauswahl zwischen Active-Items) kompensieren zu können, aber anscheinend hat das nicht gereicht. Klar, das hat technisch sowieso nicht ordentlich geklappt wegen der Performance, aber selbst dann wäre es vielleicht immer noch zu langsam/umständlich gewesen, um damit extra zwischen Items durchzuwechseln. Von den Problemen mit ihre Bewegung beendenden Gegnern mal ganz abgesehen.
Zumindest für das Anwählen der Passive-Items ist mir eine gute Idee gekommen; man beginnt im Menü einfach nicht, indem man einen seiner Item-Slots auswählt, um den zu befüllen, sondern, indem man eines seiner Items im Rucksack auswählt und dann einen Slot (im Rucksack oder einen aktiven Slot) wählt, wo dieses Item hinverschoben werden soll. Wenn man nun versucht, ein angewähltes Passive-Item in einen Active-Slot zu legen, geht das einfach nicht, man kann es aber trotzdem in den roten Ablage-/Verkauft-Slot legen, Problem gelöst.
Was den Komfort des Itemwechselns angeht, brauch ich wohl tatsächlich mehr Slots. Einen (A) für Melee-Waffe, zwei (S und D) für "andere Active Items", zu Beginn Bogen und Bomben, und einen exklusiv für Consumables, meinetwegen F, wo dann R exklusiv nur durch die eigenen Consumables durchscrolled. Ob man dann das Menü oder Q/W/E/R in Kampfsituationen pauschal verbietet, käme drauf an, ob ich die Gegner "richtig" gestoppt kriege.

Da auch direkt der nächste Punkt, Spielgefühl und Interaktion zwischen Spieler und Gegner (besonder sim Nahkampf). Ja, es fühlt sich im Moment alles etwas wonky an, weil die Gegner noch auf dem Standard-Grid liegen. Das heißt, sie bleiben manchmal ein großes Stück vor dir stehen, weil du bereits das an sie angrenzende Tile berührst und sie nicht näher als 16 Pixel randürfen, manchmal laufen sie auch in dich rein, weil sie ihre Bewegung noch beenden, selbst wenn sie detecten, dass du ihr Zielfeld betreten hast.
Darum wäre das zweitwichtigste nach der Performance für mich, die Gegner vom Grid zu kriegen, damit sie immer akkurat mit dem Spieler, dessen Projektilen, Nahkampfwaffen usw. interagieren.
Ich sprach gestern ja schon an, dass ich dafür ein Plugin bräuchte, das es mir ermöglicht, die Zeichenreihenfolge von Pictures on the fly zu ändern. Konkret möchte ich, dass jeder Gegner als ein Picture/Spritesheet repräsentiert wird, bei dem ich nur die aktuelle Position ändern muss, ohne es neu anzuzeigen. Aber da die Gegner natürlich wild durcheinander laufen können, müssen die Pictures abhängig von ihrer Y-Koordinate sortiert werden, statt von der Pic-ID.
Das sollte natürlich nicht für alle Pictures gelten, sondern entweder für ~50 Stück, die dann "Same Layer-Objekte" spielen können, oder über nen Comment-Befehl togglebar sein. Das wär wahnsinnig hilfreich.

Ob es eine große Hauptursache für die schlechte Performance gibt, weiß ich aktuell nicht. Was ich weiß ist, dass Gegner-Projektile (entweder deren Movement oder Trefferabfrage, vielleicht beides), das Q/W-Menü und (gerade beim Versuch, das Pixelmovement flüssiger zu kriegen) die Kollision des Spielers mit Wänden/Objekten jeweils für einen Einbruch sorgt. Die Sachen werd ich nochmal generalüberholen oder komplett neu schreiben, dann sollten zumindest die Drops unter 50fps behoben werden können. Falls ich da an meine Grenzen (bzw. die des Makers) stoße und z.B. die Interaktion von Gegner-Projektilen mit Spieler, Gegnern, Objekten, Büschen, Wänden usw. standardmäßig im Maker einfach nicht flüssig hinbekomme, würd ich mich noch mal an dich wenden.

Und noch zwei andere Fragen. Im Maker ist es ja so, dass beim Wechseln einer Eventseite der Maker sich merkt, wo genau im Code er vor dem Wechseln gerade war, und wenn man auf die vorige Eventseite zurückspringt, beginnt er nicht von vorn, sondern von diesem Punkt aus. Bei Mapübergängen macht er das glaub ich auch manchmal; springt an die Stelle im Script eines Events auf der Map, an der das Script war, als die Map das letzte Mal verlassen wurde. Das ist sicherlich ein Feature, das man auf viele clevere Arten nutzen kann, mich stört es aber einfach ungemein und zwingt mich, an diversen Stellen mit Flag zu arbeiten, um auch ja immer zum Script-Anfang zurückzuspringen, wenn die Map gewechselt oder irgendein anderer Code ausgeführt wurde.
Gibt es ein Plugin, das dieses Verhalten des Makers abschaltet, sodass er immer zum Anfang eines Scripts springt, wenn eine Eventseite oder die Map gewechselt wird?
Und steht die Performance eines Scripts in irgendeinem Zusammenhang mit dessen Länge? Sprich, wenn ein Script zum Beispiel ewig lang ist und in einem Go 20 Funktionen ausführt, ist das schlechter für die Performance, als jede einzelne Funktion auszulagern und die nacheinander zu callen?