Seite 3 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 41 bis 60 von 69

Thema: Analytisches Anspielen

  1. #41
    Nochmal danke fürs Spielen und den Stream!

    Einige der Sachen lassen sich relativ leicht umsetzen und ich stimme grundsätzlich bei den meisten Sachen zu. Was den ganzen Menü Kram betrifft muss ich wirklich mal schauen wie leicht sich das alles editieren lässt. Gerade da vieles davon nichts ist was "notwendig" ist - es funktioniert ja alles - aber im großen und ganzen "Nice to have" bzw. um Dinge einfach übersichtlicher oder weniger umständlich zu machen. Was das Balancing betrifft muss ich aber wirklich schauen, da würde ich offen gestanden eher ungerne was dran rütteln (Ausnahme vielleicht die Chimäre, aber das ist wieder eine Sache für sich).

  2. #42
    Heyho, sehr interessante und informative Streams machst du da.
    Wenn das tatsächlich ein regelmäßiges Format wird - was ich großartig fände -, würd ich einfach mal ganz dreist mein eigenes Spiel als Kandidaten für eine Analyse in den Ring werfen.

    FröhlicheSchatzjagd ist ein Roguelite, das sich wie eine Mischung aus Isaac und Handheld-Zelda spielt. Ist natürlich mal was ganz anderes als klassische RPGs, aber da du ja selbst ein Spiel mit AKS und Pixelmovement produzierst, findest du bestimmt interessante Kritikpunkte und Verbesserungsvorschläge.
    Würde mich sehr freuen!

  3. #43
    @All:
    Hier dann auch das zugeschnittene VOD: https://www.twitch.tv/videos/400566622
    Vorraussichtlich nächstes Wochenende HYBRIS - Pulse of Ruin, Details folgen kurzfristig.

    @Sölf: Immer gern
    Ich hatte mir eigentlich vorgenommen nochmal etwas weiter zu spielen, aber mal sehen wann ich dazu komme. Ich würde mich schon gern nochmal genauer ins KS eindenken und etwas mehr sehen. Ich war jedenfalls alles in allem gut unterhalten.

    @Kingzi:
    Das Spiel hab ich doch sogar schon mal im Blick gehabt! Aber es scheint sich viel getan zu haben seit der Version die ich kenne. Und hab mehr Spielstunden in Isaac als ich zugeben möchte. Hab auch schon das DynRPG logo gesehen... :>

    Das Spiel schau ich mir auf jeden Fall genauer an!

  4. #44
    Sofern du Kameradschaft weiterspielst ist der nächste Part auch nochmal interessant, da doch etwas anders als der Anfang. Ich nehm mal kurz was vorweg, da du den Dialog eh geskippt hast:

    Es gibt 2 Möglichkeiten um weiter zu kommen. Entweder man erfüllt diesen Auftrag von der Generalin, oder man muss 10.000 Vael (über Nebenquests und Monster Drops) sammeln. Da gibts dann auch mehrere Nebenquests, an denen du bisher ja dezent dran vorbeigerannt bist (da nicht markiert, aber du hast auch mit niemandem quasi geredet xD). Wie sinnig diese Wahl ist (die eine ist ganz klar besser, da man das Geld in Ausrüstung statt die Überfahrt investieren kann) ist dann wieder ne eigene Diskussion.

    Ich bin jedenfalls gerne wieder dabei. Auch ruhig privat oder sonstwie - sag einfach bescheid. Nächste Woche muss ich aber leider passen, da ist das Wochenende schon verplant... xD

  5. #45
    So schnell bin ich ohnehin nicht, ich muss ja auch mal wieder zur Arbeit...
    Ich sag auf jeden Fall bescheid wenn ich weiterspiele.

  6. #46
    In erschreckender Regelmäßigkeit:
    HYBRIS - Pulse of Ruin, heute, 19 Uhr!

  7. #47
    Das VOD gibts wieder? Ich bin heute leider nicht da, aber würd später bestimmt zumindest nochmal durchskippen wollen. :0

  8. #48
    Klar, VOD gibts immer.

  9. #49
    Stream ist live.

  10. #50
    So, ich konnte das Video nun endlich anschauen. Leider hatte ich die Ankündigung zu spät gesehen und hatte den Samstagabend schon verplant und war in den Alpen am Iglu bauen.
    Erstmal vielen Dank euch für das Video, ich konnte hier einiges mitnehmen.
    Einerseits ist es schade, dass ich nicht dabei war, andererseits ist sind für mich die Learnings so grösser, da ich nicht reinreden konnte.

    Ich gehe mal auf die Punkte ein, die mir wichtig erscheinen. Wenn Fragen zu anderen sind, werde ich da natürlich auch was dazu schreiben.

    -Viele der Kleinigkeiten liegen leider den Limitationen des Makers zugrunde. Das betrifft z.B. das Gridbasierte Laufen. Auf diese Dinge gehe ich mal nicht ein.
    -Tagebuch: Dass es noch nicht zugänglich sein soll finde ich einen guten Vorschlag. Das mit dem Mapwechsel konnte ich damals nicht anders lösen, heute hätte ich schon Ideen dazu. Den Bug, den du hier gefunden hast, finde ich jetzt nicht so tragisch. Man muss da ja schon absichtlich was kaputtmachen wollen.
    -Das Leuchten des Ewigen Flusses in der Stadt fand ich auch eine schöne Idee.
    -Das mit dem Verlieren im ersten Kampf ist tatsächlich so noch nie aufgefallen. Das lässt sich schnell fixen.
    -Munition für Pistole: Gilt nur innerhalb des Kampfes, da die Fähigkeit ausserhalb für das Lösen von Rätseln nötig ist und daher unendlich Schüsse zwingend sind. Hätte ich aber erwähnen können.

    Tutorials:
    Es war etwas unglücklich, dass du die Nachrichten zum Auswahl der Ziele oder zum Ausrüsten der Aktionen nicht richtig gesehen hast. Bisher schien es mir, dass die Konzepte verstanden wurden. Ursprünglich hatte ich lange Tutorialtexte. Diese nerven mich allerdings bei anderen Spielen stark, weshalb ich eine andere Lösung wollte. Ich hatte diese Variante mit etwa 15 Spielern getestet, die das Spiel noch nicht kannten und habe es aufgrund des Feedbacks dann so umgesetzt. Wie hätte es für dich gepasst?


    Kampfsystem:

    Die Grundidee des Kampfsystems ist Limitation. Da anfangs nur wenige Techniken verfügbar sind, kommt das da noch nicht in der Form zum Tragen. Auf die Nummerntasten können 6 Basis und 3 Zusatzfunktionen ausgerüstet werden (z.B. auch der Schussangriff). Gegen Ende des Spiels hat man etwa 200 Techniken zur Auswahl und muss davon 9 Auswählen, die man in den Kampf mitnimmt.


    Aus diesem Grund ist auch der Menüscreen nach dem Game Over wichtig, damit sich der Spieler neu formieren kann. Mit den falschen Aktionen kann es auch sein, dass man gegen Standardgegner stark im Nachteil ist. Und ich erwarte vom Spieler nicht, nach jedem Kampf zu speichern. Daher finde ich persönlich die Lösung mit dem Game Over und der darauffolgenden Menüauswahl gut.

    Level-ups: Im Level-up Bildschirm werden unten links benötigte Erfahrungspunkte und aktuelle Erfahrungspunkte angezeigt. So weiss der Spieler, wie viel er hochstufen kann. Den Hinweis mit den Zahlen finde ich gut, das ist tatsächlich nicht klar. Dort müsste noch "Lv" dazustehen.
    Im ersten Dungeon hattest du ja schon diverse Level-up Möglichkeiten. Aus diesem Grund finde ich eine Bestätigung der Levelauswahl nicht nötig. Levelups sind im Spiel sehr gängig, ein Charakter kommt ohne Grinden mindestens auf Levle 200 gegen Ende des Spiels.

    Erlernen der Techniken: Du hast Stärken noch nicht gelernt, da zwei Elemente auf Level 4 sein müssen, deshalb sind dort auch zwei Icons abgebildet und z.B. bei Puls-Stich nur das Stoss-Element.


    Steuerung: Mein Ansatz war, dass viele Spieler RPG Maker Spiele mit der Tastatur spielen und die konventionelle Steuerung eben auf einen Controller ausgelegt ist. Ich finde es zeitlich effizienter, eine Taste auszuwählen anstatt durch ein Menü zu scrollen. Zudem erlaubt die Freie Belegung der Techniken auf die Nummerntasten eigene Konfigurationsmöglichkeiten.

    Problematik Spielerfreiheit:
    Im Spiel habe ich sehr stark mit Spielerfreiheiten experimentiert. Durch das Levelsystem kann jeder Charakter alles erlernen und somit ist nicht vorgegeben, welche Techniken wann verfügbar sind. Deine Ideen z.B. mit Scan finde ich schön, aber in einem solchen System sind sie schwerer umzusetzen. Das war bei der Entwicklung gerade auch bei den Kämpfen herausfordernd. Denn es braucht jeweils mehrere mögliche Strategien, da die Charakterskills von Spieler zu Spieler variieren. In Zukunft werde ich eher auf ein System setzen, das etwas mehr einschränkt.

    Zeitleiste: Hier ist die Kritik völlig berechtigt. Die Idee war eigentlich, den Spieler etwas unter Druck zu setzen. Die Stopps sind drin, um es dann doch nicht zu schwer zu machen. Die heben das System aber tatsächlich wieder auf.

    Elementsystem: Noch eine kurze Erklärung zu den Prozentzahlen oben rechts im Kampf. Die werden erst etwas später erläutert. Wenn Elementaraktionen verwendet werden (z.B. Wind), stärkt dies Wind (z.B. von 100% auf 105% und senkt Erde z.B. von 100% auf 95%). Wind macht dann 105% Schaden und Erde nur noch 95%. Diese Werte können so vom Spieler wie auch vom Gegner taktisch verändert werden. Ausserdem sind die Werte auch je nach Gebiet nicht immer 100%. z.B. ist in einem Vulkan Feuer bereits auf 150% und Wasser auf 50%.


    Abschliessend:
    Du bist vor Allem auf technische Punkte eingegangen. Die Dinge, die du entdeckt hast, sind tatsächlich eher Kleinigkeiten aber ich verstehe deinen Punkt sehr wohl. Die Betatester haben hier aber auch wirklich super Arbeit geleistet und vieles gemeldet. Das Problem ist halt, dass das Spiel verdammt gross geworden ist (etwa 50 Stunden Spielzeit), was für ein Einmannprojekt den Rahmen halt etwas sprengt. Auch hier habe ich für mich gelernt, mich in Zukunft etwas einzuschränken um die Details mehr ausarbeiten zu können.

    Interessieren würde mich noch, wie du die Informationsvergaben in der Story gefunden hast und ob du den Einstieg aus Storyperspektive spannend fandest. Würdest du das Spiel weiterspielen? Gründe?
    Wenn du früh genug ankündigst, können wir auch gerne noch eine Session machen, wo ich dabeisein kann.
    Ich finde es toll, dass du kritisch bist und das hilft mir als Entwickler sehr.

  11. #51
    Hey, schön dass es dir was genützt hat!

    Zitat Zitat von lucien3 Beitrag anzeigen
    -Viele der Kleinigkeiten liegen leider den Limitationen des Makers zugrunde. Das betrifft z.B. das Gridbasierte Laufen. Auf diese Dinge gehe ich mal nicht ein.
    Ich denke die Limitierungen das Makers liegen höher als du denkst, aber mir ist auch klar, dass nicht jeder mal eben in der Engine zum schreibt.
    Gegen das gridbasierte Laufen an sich hab ich auch gar keine Einwände. Aber viele der Feinheiten die ich angesprochen habe ließen theoretisch sich sicherlich beheben.
    Notiz am Rande, nicht dass es hier relevant wäre: Ich hab schon mit Pixelmovement im XP gearbeitet.

    Zitat Zitat von lucien3 Beitrag anzeigen
    Das mit dem Mapwechsel konnte ich damals nicht anders lösen, heute hätte ich schon Ideen dazu. Den Bug, den du hier gefunden hast, finde ich jetzt nicht so tragisch. Man muss da ja schon absichtlich was kaputtmachen wollen.
    Sicher nicht sonderlich tragisch, unterschreibe ich so. Dennoch etwas, das auch unfreiwillig zu Bugs führen kann.

    Zitat Zitat von lucien3 Beitrag anzeigen
    -Munition für Pistole: Gilt nur innerhalb des Kampfes, da die Fähigkeit ausserhalb für das Lösen von Rätseln nötig ist und daher unendlich Schüsse zwingend sind. Hätte ich aber erwähnen können.
    Vielleicht ist eine zweite Art Munition eine plausible Ausrede...

    Zitat Zitat von lucien3 Beitrag anzeigen
    Tutorials:
    Es war etwas unglücklich, dass du die Nachrichten zum Auswahl der Ziele oder zum Ausrüsten der Aktionen nicht richtig gesehen hast. Bisher schien es mir, dass die Konzepte verstanden wurden. Ursprünglich hatte ich lange Tutorialtexte. Diese nerven mich allerdings bei anderen Spielen stark, weshalb ich eine andere Lösung wollte. Ich hatte diese Variante mit etwa 15 Spielern getestet, die das Spiel noch nicht kannten und habe es aufgrund des Feedbacks dann so umgesetzt. Wie hätte es für dich gepasst?
    Ein kleines visuelles Feedback dafür, welcher Gegner ausgewählt wurde könnte da vielleicht schon helfen. Außerdem wäre es cool wenn ich einen Error-Indikator (Sound / Sound + Animation) bekommen würde, wenn ich versuche einen Gegner anzugreifen den es nicht gibt. Das passiert denke ich Spielern nur auf Basis von Unverständnis oder Missclick. Ansonsten denke ich, dass Spieler den Auswahlmodus schon auch ohne Texte verstehen - die Rumprobierphase darf schon existieren. Ich finde das schon gut so, ohne die Tutorialtexte.

    Zitat Zitat von lucien3 Beitrag anzeigen
    Steuerung: Mein Ansatz war, dass viele Spieler RPG Maker Spiele mit der Tastatur spielen und die konventionelle Steuerung eben auf einen Controller ausgelegt ist. Ich finde es zeitlich effizienter, eine Taste auszuwählen anstatt durch ein Menü zu scrollen. Zudem erlaubt die Freie Belegung der Techniken auf die Nummerntasten eigene Konfigurationsmöglichkeiten.
    In der Tat braucht das System sehr wenige Tastendrücke. Allerdings verstehe ich nicht, wieso das System besser für Tastatur geeignet sein soll. Der typische Controller hat locker 10 Tasten zur Verfügung und dennoch entscheidet sich das typische Konsolen RPG dafür, die Auswahl durch einen Cursor zu machen.
    Meine Probleme kamen denke ich daher, dass meine rechte Hand vom Hauptspiel auf den Pfeiltasten liegt, die Pfeiltasten allerdings in den Kämpfen keine (oder nur wenig?) Bewandtnis haben.
    Und abgesehen davon ist für mich als Spieler ohne Numpad diese lange Reihe von 1-9 (bzw. 0-9?) recht unpraktisch.


    Zitat Zitat von lucien3 Beitrag anzeigen
    Kampfsystem:
    Die Grundidee des Kampfsystems ist Limitation. Da anfangs nur wenige Techniken verfügbar sind, kommt das da noch nicht in der Form zum Tragen. Auf die Nummerntasten können 6 Basis und 3 Zusatzfunktionen ausgerüstet werden (z.B. auch der Schussangriff). Gegen Ende des Spiels hat man etwa 200 Techniken zur Auswahl und muss davon 9 Auswählen, die man in den Kampf mitnimmt.
    Klingt sehr interessant!

    Zitat Zitat von lucien3 Beitrag anzeigen
    Aus diesem Grund ist auch der Menüscreen nach dem Game Over wichtig, damit sich der Spieler neu formieren kann. Mit den falschen Aktionen kann es auch sein, dass man gegen Standardgegner stark im Nachteil ist. Und ich erwarte vom Spieler nicht, nach jedem Kampf zu speichern. Daher finde ich persönlich die Lösung mit dem Game Over und der darauffolgenden Menüauswahl gut.
    Die Menüauswahl ergibt dann durchaus Sinn. Ich hatte das allerdings so verstanden, dass der Spieler etwas verliert wenn er das Neustartfeature nutzt. Wenn das so sein sollte, sehe ich darin ein Problem, weil das wiederum Spieler dazu bringt zwischen den Kämpfen zu speichern.


    Zitat Zitat von lucien3 Beitrag anzeigen
    Level-ups: Im Level-up Bildschirm werden unten links benötigte Erfahrungspunkte und aktuelle Erfahrungspunkte angezeigt. So weiss der Spieler, wie viel er hochstufen kann. Den Hinweis mit den Zahlen finde ich gut, das ist tatsächlich nicht klar. Dort müsste noch "Lv" dazustehen.
    Im ersten Dungeon hattest du ja schon diverse Level-up Möglichkeiten. Aus diesem Grund finde ich eine Bestätigung der Levelauswahl nicht nötig. Levelups sind im Spiel sehr gängig, ein Charakter kommt ohne Grinden mindestens auf Levle 200 gegen Ende des Spiels.
    An der Stelle nur der Hinweis: Ich denke viele Spieler Skillen beim ersten Levelup aus Versehen beim Austesten das Menüs. Das muss nicht mal ein Problem sein.

    Zitat Zitat von lucien3 Beitrag anzeigen
    Erlernen der Techniken: Du hast Stärken noch nicht gelernt, da zwei Elemente auf Level 4 sein müssen, deshalb sind dort auch zwei Icons abgebildet und z.B. bei Puls-Stich nur das Stoss-Element.
    Ich verstehe, wäre ich allerdings ingame so schnell nicht drauf gekommen.

    Zitat Zitat von lucien3 Beitrag anzeigen
    Elementsystem: Noch eine kurze Erklärung zu den Prozentzahlen oben rechts im Kampf. Die werden erst etwas später erläutert. Wenn Elementaraktionen verwendet werden (z.B. Wind), stärkt dies Wind (z.B. von 100% auf 105% und senkt Erde z.B. von 100% auf 95%). Wind macht dann 105% Schaden und Erde nur noch 95%. Diese Werte können so vom Spieler wie auch vom Gegner taktisch verändert werden. Ausserdem sind die Werte auch je nach Gebiet nicht immer 100%. z.B. ist in einem Vulkan Feuer bereits auf 150% und Wasser auf 50%.
    Ich verstehe, finde ich aber auch gar nicht mal so offensichtlich.

    Zitat Zitat von lucien3 Beitrag anzeigen
    Interessieren würde mich noch, wie du die Informationsvergaben in der Story gefunden hast und ob du den Einstieg aus Storyperspektive spannend fandest.
    Disclaimer dazu: Story ist nicht gerade mein Spezialgebiet. Ich schreibe für mein eigenes Spiel, und das wars dann auch.
    Also: Von dem was ich gesehen habe, finde ich das Setting und Story vielversprechend. Das Setting erlaubt definitiv auch spannende Entwicklungen, hat viel Raum für politische und persönliche Verwicklungen. Mag ich.

    Charakter writing:
    Die beiden Protagonisten wirken auf mich erstmal ziemlich generisch. Viel von Kiros Motivation hab ich noch nicht mitbekommen. Der wird sicherlich später noch ausgebaut, aber vielleicht kann man davon schon mal einen Brocken hinwerfen.
    Das fällt mir gerade wirklich schwer zu beschreiben... aber irgendwie hatten die Beiden mehrfach die selben Themen. Vielleicht fehlt mir einfach hin und wieder mal ein Satz, der suggeriert dass da mehr Vorgeschichte und Lebensweg ist, als ich als Spieler sehe. Für mich ist Kiro "talentiert und jung" und Evan "erfahren und badass", aber dann auch nicht viel mehr.

    Vielleicht ist es anschaulicher am Beispiel der Bewohner des Schwarzen Doms:
    Irgendwie hatte ich das Gefühl alle Gespräche drehen sich um ihre Unwissenheit und Abgeschottetheit. Und klar ist das wichtig, das mal explizit zu sagen. Aber viel dieser Unwissenheit könnte man auch implizit in ein Gespräch einfließen lassen, das sich um das Leben der Dombewohner dreht.

    Beispiel:
    Variante 1: Bewohner: "Ich finde es gut, dass die Leute hier mit 50 umgebracht werden."
    Variante 2: Bewohner: "Ach wissen Sie, einerseits finde ich es ja ganz gut, dass es mit meinem Alten bald so weit ist.
    Immerhin kann Anika dann endlich zu mit ziehen. Aber irgendwie, irgendwie hätte ich schon gern noch etwas mehr Zeit mit ihm..."

    Zitat Zitat von lucien3 Beitrag anzeigen
    Würdest du das Spiel weiterspielen? Gründe?
    Aus meiner persönlichen Perspektive: Privat hätte ich das nie angefangen - denn privat spiele ich im Moment gar nichts weiter...

    Also andere Perspektive, denk ich ein Spieler wäre gehooked?
    Wenn mich die Story geködert hätte ja.
    Wenn ich auf Gameplay aus bin ... bin ich unsicher. Es klingt zwar so als wäre das Midgame/Endgame Kampfsystem sehr interessant, aber es kommuniziert das früh im Spiel nicht.
    Ich denke es ist immer eine ganz gute Sache, wenn man den Spieler erahnen lässt wie cool es später noch wird.
    Dafür hat Path of Exile diesen riesen Skillgraphen. Und dafür steigen viele Spiele mit einem Endgame Charakter im Vorspann ein, bis man dann seinen Lvl1 Charakter bekommt. Ich kann dir leider nicht sagen, mit welchen Eigenschaften du werben solltest, weil ich sie nicht kenne. Aber die coolsten Features, die du hast, früh anzuteasern sorgt dafür, dass mehr Spieler bei der Stange bleiben weil sie sich auf was freuen können.

    Zitat Zitat von lucien3 Beitrag anzeigen
    Wenn du früh genug ankündigst, können wir auch gerne noch eine Session machen, wo ich dabeisein kann.
    Wenn ich dem Spiel mal eine zweite Runde gebe, sag ich Bescheid.

    Zitat Zitat von lucien3 Beitrag anzeigen
    Ich finde es toll, dass du kritisch bist und das hilft mir als Entwickler sehr.
    Sehr gut!

  12. #52
    Zitat Zitat von Brei Beitrag anzeigen
    Aber die coolsten Features, die du hast, früh anzuteasern sorgt dafür, dass mehr Spieler bei der Stange bleiben weil sie sich auf was freuen können.
    Aber bei mir wars dann zu viel! :P

  13. #53
    Zitat Zitat von Sölf Beitrag anzeigen
    Aber bei mir wars dann zu viel! :P
    Ich sagte anteasern, im Sinne von "erahnen lassen was da kommt" oder "kurz vorführen" ... nicht "alle gleich hergeben" :P

    @all:
    So wie es aussieht behalte ich den Takt bei und schau mir Samstag "Fröhliche Schatzjagd" an!

  14. #54
    Es bleibt bei heute 19:00, Fröhliche Schatzjagd.
    Mit DynRpg kenne ich mich halt sogar mal aus. :>
    https://www.twitch.tv/breidewitzka

  15. #55
    Soooo!
    Link zum VOD: https://www.twitch.tv/videos/407559687
    Meine Warteschlange ist damit auch leer, also wenn wer ein Spiel hat, das ich mal anschauen soll: immer her damit!

    @Kingzi:
    Ich hab nach dem Stream nochmal rumprobiert und mein Laptop hat das Spiel auch danach nicht mit mehr FPS hinbekommen.
    Allerdings kam mir da ein Patch in den Sinn, Siehe: https://www.multimediaxis.de/threads...read-2/page106 und zwar "AntiLag(Slow)"

    Der Patch ändert den Zeitpunkt zu dem event pages umgeschlagen werden auf das Ende das Frames. Das hat den Vorteil, dass Pages nicht nach jeder geänderten Variable überprüft werden müssen. (und bei der Menge event pages sowie Variablenoperationen in deinem Spiel macht das schon gut was aus)

    Ich hab den Patch mal ausprobiert und es hat die Performance bei mir *deutlich* verbessert, ohne dass ich irgendwelche Bugs gesehen hätte.
    Dennoch: Wenn du an Stellen stößt an denen die Page nicht bis zum Ende des Frames warten kann, müsstest du die Page checks manuell machen. Das Plugin dazu ist Pipifax, und der Aufwand das einzubauen (falls überhaupt nötig) sollte im Rahmen sein.

  16. #56
    Erstmal danke fürs Spielen. War cool das Spiel endlich mal in Aktion zu sehen, ich wollte das wirklich schon seit dem ersten Release spielen aber habs bis heute nicht gemacht. Ist jedenfalls richtig cool - wenns fertig ist guck ichs mir auch nochmal genauer an. xD

    Was Spiele betrifft, wenn sich keiner meldet, ich hätte da noch 3:

    - Mehr Kameradschaft, weil das einfach das ist was mich am meisten interessiert.
    - Dungeon Delver, wobei das eher nur "interessant" anzugucken ist. Im Endeffekt ist es nicht wirklich zu dem geworden was ich anfangs geplant hatte und ich weiß nicht ob ich das Spiel irgendwann nochmal weitermache. Grundidee war ne Mischung aus Isaac (freischalten von Kram) und nem uralten 2k3 Kurzspiel.
    - EMDES 2, ein Dungeon Crawler der sich seeeehr stark an der Etrian Odyssey Reihe für den NDS/3DS orientiert. Würde mich neben Kameradschaft am ehesten interessieren.

    Wenn du magst und sich keiner mehr meldet sag bescheid, ich lad dann wieder ne aktuelle Version hoch. Bei Kameradschaft hab ich auch ein paar der einfachen Dinge schon umgesetzt und den Questlog weiter eingebaut. An die ganzen Menüs mit den Anzeigen hab ich mich aber dann doch erstmal noch nicht rangewagt.

  17. #57
    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?

  18. #58
    Zitat Zitat von Kingzi Beitrag anzeigen
    Nochmal danke für den Stream und die technischen Ratschläge, genau wie für diesen Tipp.
    Immer gern

    Zitat Zitat von Kingzi Beitrag anzeigen
    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?
    Ich hab es zwar auf die schnelle auch nicht hinbekommen Better AEP und Dynrpg 0.3 in deinem Projekt zum Laufen zu bekommen, seltsamerweise ging es allerdings problemlos in meinem. (Ich habe einfach den Patch als .ips in den "DynPatches" Ordner gezogen und es hat erfolgreich den Title Screen übersprungen. Mehr hab ich nicht getestet. Aber grundsätzlich scheint Better AEP + DynRpg 0.3 + OpenGl zu funktionieren. Ist mir ein Rätsel, warum es in deinem Projekt nicht so klappt. (Ich bekomme dann irgendeine Assertion Failure)

    Edit: Ich bekomme dein Spiel sogar so weit, dass ich den Title Screen überspringe. Aber, egal ob ich das tue oder nicht: Mit Dynrpg 0.32 fliegt mir das Spiel hinter dem Title Screen um die Ohren.

    Abgesehen davon: Auto Saves und Auto Loads habe ich selber im Spiel, das ist gar kein Problem. Zum Titel skippen hab ich spontan nichts gefunden.

    Zitat Zitat von Kingzi Beitrag anzeigen
    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.
    Klingt gut, mach ruhig auch viel mit Farbe.

    Zitat Zitat von Kingzi Beitrag anzeigen
    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.
    Also, in dem Zusammenhang habe ich da gerade Folgendes rumliegen:
    @picture_change_layer [pictureId], [layerId]
    mit den relevanten layerIds (0: unter allen events; 1: unter allen same-layer-as-hero events, 2: über allen same-layer-as-hero events)

    Innerhalb der Layer ist die Reihenfolge immer noch den Ids folgend.
    Unklar, ob dir das weiterhelfen würde.

    Was ich außerdem rumliegen habe:
    Einen Befehl um die Grafik eines Events um genau x Pixel zu bewegen, ohne dabei das Tile zu wechseln.

    Auf die Premiumlösung, allen Event selbst Pixelmovement zu geben, bin ich auch scharf, und vielleicht bauen wir sowas auch mal - aber das kann noch dauern.


    Zitat Zitat von Kingzi Beitrag anzeigen
    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.
    Mach das so

    Zitat Zitat von Kingzi Beitrag anzeigen
    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?
    Nicht, dass ich wüsste.

    Zitat Zitat von Kingzi Beitrag anzeigen
    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?
    Gute Frage. Ich bin der Sache nie gezielt nachgegangen. Ich hatte mal ein sehr langes Event das sich laggy angefühlt hat - und das sich weniger laggy angefühlt hat, nachdem ich einen Teil gecallt habe. Aber das ist viele Jahre her, und ich hab da nie Diagnose betrieben. Ich wollte mir immer mal ein Plugin für solche Zeitmessungen bauen, aber das habe ich noch nicht. Ich habe auch keine Ahnung wie schnell der Maker Eventcode einließt, oder wann, oder ob/wie er das cacht.

    Geändert von Brei (07.04.2019 um 19:45 Uhr)

  19. #59
    Zitat Zitat von Brei Beitrag anzeigen
    Ich hab es zwar auf die schnelle auch nicht hinbekommen Better AEP und Dynrpg 0.3 in deinem Projekt zum Laufen zu bekommen, seltsamerweise ging es allerdings problemlos in meinem. (Ich habe einfach den Patch als .ips in den "DynPatches" Ordner gezogen und es hat erfolgreich den Title Screen übersprungen. Mehr hab ich nicht getestet. Aber grundsätzlich scheint Better AEP + DynRpg 0.3 + OpenGl zu funktionieren. Ist mir ein Rätsel, warum es in deinem Projekt nicht so klappt. (Ich bekomme dann irgendeine Assertion Failure)

    Edit: Ich bekomme dein Spiel sogar so weit, dass ich den Title Screen überspringe. Aber, egal ob ich das tue oder nicht: Mit Dynrpg 0.32 fliegt mir das Spiel hinter dem Title Screen um die Ohren.
    Habs jetzt hinbekommen
    Keine Ahnung, warum beim Ausprobieren gestern die exe einfach gar nicht gestartet ist, aber ich hab mir jetzt einfach eine komplett neue exe nach und nach mit allen Patches vollgepackt, die ich brauch, Voodoo-Magie betrieben und den Vollmond angeheult, und jetzt geht's.


    Zitat Zitat von Brei Beitrag anzeigen
    Was ich außerdem rumliegen habe:
    Einen Befehl um die Grafik eines Events um genau x Pixel zu bewegen, ohne dabei das Tile zu wechseln.
    Verhalten Event-Grafiken sich denn dabei entsprechend ihrer Pixel-Position oder ihrer Tile-Position? Sprich, könnte ich theoretisch 10 Gegner-Events in irgendeine Ecke packen und die zugehörigen Grafiken effektiv als Pictures pixelweise irgendwo über den Screen schieben und die würden brav in der richtigen Reihenfolge entsprechend ihrer Y-Koordinate dargestellt? Bzw. wie weit kann ich den Sprite überhaupt unabhängig vom Event bewegen? Beliebig, oder moved das Event nach 16 Pixeln nach?
    In jedem Fall wäre mir das glaub ich eine große Hilfe, falls du's mit mir teilen könntest.


    Zitat Zitat von Brei Beitrag anzeigen
    Gute Frage. Ich bin der Sache nie gezielt nachgegangen. Ich hatte mal ein sehr langes Event das sich laggy angefühlt hat - und das sich weniger laggy angefühlt hat, nachdem ich einen Teil gecallt habe. Aber das ist viele Jahre her, und ich hab da nie Diagnose betrieben. Ich wollte mir immer mal ein Plugin für solche Zeitmessungen bauen, aber das habe ich noch nicht. Ich habe auch keine Ahnung wie schnell der Maker Eventcode einließt, oder wann, oder ob/wie er das cacht.
    Dieses wage Gefühl hatte ich nämlich auch, konnte aber nirgendwo was definitives dazu finden. Wär 'n interessanter Fakt für performantes Scripting.

  20. #60
    @Sölf:
    Ja doch, ich überleg mir das mal.

    @Kingzi:
    Ist ja schonmal ziemlich nice, dass das OpenGL plugin sich doch noch gebeugt hat!

    Zitat Zitat von Kingzi Beitrag anzeigen
    Verhalten Event-Grafiken sich denn dabei entsprechend ihrer Pixel-Position oder ihrer Tile-Position? Sprich, könnte ich theoretisch 10 Gegner-Events in irgendeine Ecke packen und die zugehörigen Grafiken effektiv als Pictures pixelweise irgendwo über den Screen schieben und die würden brav in der richtigen Reihenfolge entsprechend ihrer Y-Koordinate dargestellt? Bzw. wie weit kann ich den Sprite überhaupt unabhängig vom Event bewegen? Beliebig, oder moved das Event nach 16 Pixeln nach?
    In jedem Fall wäre mir das glaub ich eine große Hilfe, falls du's mit mir teilen könntest.
    Die Events verhalten sich entsprechend ihrer Grid Position und moven nicht nach. Sie werden aber nach pixelgenauer y-Position gezeichnet. Ich kann dir gerne zeitnah ein paar Getter/Setter etc. für den Offset schreiben und dann lass ich dir das zukommen. Hast du Interesse am Sourcecode?

    Edit: Der Event Offset ist leider nur 8 Bit groß, das ist ein Problem für den Ansatz ...
    Allerdings könnte ich die grid Position eben doch nachziehen und das Event bleibt dann halt im Phasing mode...

    Zitat Zitat von Kingzi Beitrag anzeigen
    Dieses wage Gefühl hatte ich nämlich auch, konnte aber nirgendwo was definitives dazu finden. Wär 'n interessanter Fakt für performantes Scripting.
    Wenn ich irgendwann mal bisschen Langeweile habe schreib ich das Zeitmess-Plugin und finde das mal raus...

    Geändert von Brei (08.04.2019 um 20:38 Uhr)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •