Hallo liebe Gamemaker-Domäne,

in dieser Diskussion soll es um mein Projekt gehen. Bevor ich euch aber einen ineffizienten Blocktext zumute, hier die relevanten Informationen in gut bekömmlicher Kurzform .

WAS ist mein Projekt: TAOTS (AT), ein rundenbasiertes RPG, inspiriert durch Spiele wie die Final Fantasy-Reihe bishin zu Teil X, 2D, Einflüsse aus diversen RPGs unterschiedlichster Art, vorerst eine spielbare Demo mit den Kern-Features.

WER bin ich und was ist mein Hintergrund: Vorstellungsthread

WIE sieht mein Game-Design aus: Hier folgt in Kürze ein Link zu meinem Konzept.

Diskussionsthematik:

Die Diskussion in diesem Thread soll mir durch eure hochgeschätzten Erfahrungswerte helfen, die geignete weitere Vorgehensweise meines Projektes zu definieren. Vor Allem in Bezug auf Code-Organisation meiner Engine und das effiziente Anlegen der Datengrundlagen des Spiels. RPGs dieser Art sind in Hinblick auf die reine Code-Basis wahre Datenbanken Ungetüme. Um darüber zu diskutieren, wie der Code am besten organisiert werden sollte, müsst ihr natürlich wissen was die Engine können soll und was ich bereits gemacht habe. Da dies hier nicht der oben erwähnte Konzeptthread ist, werde ich logischerweise genre-bezogen fragen, nicht aber auf mein Projekt bezogen. Denn hier soll es nicht um die Features gehen, sondern um das Anlegen von Datenbanken, aus denen die für die späteren Features relevanten Variablen effizient, also ausschließlich bei Bedarf abgerufen werden können. Das reicht für die aus, die das Genre kennen und bewahrt uns davor den Rahmen zu sprengen.

Was soll die Engine können? bzw. Was soll die Engine jetzt als Nächstes können?

Die Engine soll überall, wo es möglich ist, erst dann Informationen (Variablen, Scripte) in den Speicher laden, wenn sie gebraucht werden und diese sofort wieder aus dem Speicher befördern, wenn sie erstmal nichtmehr gebraucht erden. Dies soll die nötige Rechenleistung auf ein machbares Minimum reduzieren und so eine gute Performance gewährleisten. Ein persönlich favorisierter Nebeneffekt davon ist für mich, dass durch die dafür notwendige Code-Organisation einen angenehm organisierten Resource-Tree zur Folge hat. Soweit die Theorie. Ein geignetes Beispiel liefere ich im Abschnitt "Was ich bereits gemacht habe", direkt hierunter. Anfängerproblematik hier: Meine Kenntniss von Variablen (vornehmlich Arrays) wurde zwar durch den unschätzbar talentierten und hilfsbereiten Husi schon vertieft. Ich hätte jetzt aber noch keine praktische Vorstellung davon, wie bzw. wo ich Variablen optimalerweise platzieren sollte um sie, in Bezug auf die oben angepeilte Rechenleistungs-Effizienz, sowohl nur bei Bedarf in den Speicher laden lassen zu müssen und es gleichzeitig zu ermöglichen bestimmte Variablen dieser Datenbanken dauerhaft zu verändern. Ein Beispiel wäre hier ein Script (Script nur weil ich mir das gerade so vorstelle), dass als Speicher für die aktuellen Werte eines Kämpfers funktioniert, welche im einfachsten Fall beim aufleveln des Kämpfers eine dauerhafte Erhöhung des Values der betreffenden Variable (bspw. Stärke) zur Folge hat. Es müsste also das Script mit den Kämpferwerten gecalled werden, dann die Änderungen vorgenommen werden, das "geupdatete" Script gespeichert werden und dann wieder bis zum nächsten Gebrauch aus dem Speicher entfernt werden. Ich weiß ehrlich gesagt noch nichtmal, ob das geht. Ich könnte mir auch vorstellen, dass die Variablen im Script zwar jedes Mal wie gewollt verändert werden, aber beim nächsten callen des Scripts nur die Ausgangspunkt-Version des Scripts gerufen wird, wodurch die gewünschte Funktion ausbleiben würde.

Was ich bereits gemacht habe: Das Spiel hat momentan drei Räume, jeder Raum ist ein Platzhalter für einen Aspekt des Spiels(Ein Hauptmenü, eine lokale Map, eine Battlemap). So kann ich in voneinander getrennten Departments arbeiten und testen, was echt angenehm ist. Im Ressource-Tree habe ich bereits für jeden Raumtyp (Händlermenü, Spielermenü, Hauptmenü, Lokale Map, Weltkarte, usw.) einen Raum angelegt. Ein persistentes Objekt, meine Engine, wird zu Beginn des Spiels kreiert und kontrolliert und verwaltet allen Code. So ist es zum Beispiel möglich mit F1 bis F3 direkt zu den entsprechenden Räumen zu springen um den neuesten Code zu testen. Das persistente Objekt beinhaltet ein Script indem durch eine Kombination aus Array und Enumerator (Finite-State-Machine) der aktuelle Raum erkannt und dem diesem Raum zugeordneten Steuerungstyp (Menu, Map) entsprechend entweder das Script zur Bewegung der Spielfigur oder die Menüsteuerung geladen wird. Das funktioniert soweit und stellt das im vorigen Beispiel angekündigte Beispiel meiner Vorstellung von effizienter Code-Organisation dar. Im dritten Raum, der Battlemap, möchte ich nun beginnen, das grundlegende, genretypische Kamfsystem zu entwickeln. Anfängrproblematik hier: Bis jetzt werden die sechs Kampfteilnehmer-Objekte einfach durch die Raumoptionen kreiert. Im fertigen Zustand muss das Spiel aber zu Kampfbeginn sowohl aus den aktuellen Einstellungen des Gruppenmenüs des Spielers die richtigen Kämpferobjekte kreiieren und platzieren, als auch zufallsbasiert einen der diesem Raum/ dieser Map zugeteilten Gegnertrupps kreieren und platzieren. Meine ganz konkrete Frage hierzu: Sollte ich zuerst die Datenbank bzw. die Datenbanken entwickeln, die es dem Battlecontrol-Objekt ermöglichen selbstständig die richtigen Kämpfer-Objekte zu platzieren, oder das erstmal ruhen lassen und daran arbeiten, dass die Geschwindigkeitsvariablen der existierenden Kämpferobjekte vom Battlecontrol-Objekt erkannt, verglichen und daraus eine Zugreihenfolge erstellt wird, nach welcher die Kämpfer ihren Zug bekommen?

Ich hoffe meine Diskussionserläuterung war für ihre Länge ganz angenehm, vielleicht sogar interessant zu lesen und freue mich auf den Austausch mit euch. Mehr zu meinen Features und Mechanics gibts wie angedeutet im Konzeptthread, den ich noch erstellen werde.

Lieben Gruß,

Ben

EDIT: Ich hoffe das meine Erläuterungen jetzt nicht zu sehr ins technische für dieses Forum gehen. Nochmal: Es geht um darum, was sinnvoll wäre als nächstes zu tun. Nicht wie ich das machen soll!

Nochmals lieben Gruß,

Ben

Hi ihr Beiden,

erstmal vielen Dank für die äußerst hilfreichen Antworten. Ich habe durch eure Ausführungen jetzt schon eine ganz andere Vorstellung davon, wie ich weitermachen muss. Natürlich werd ich jetzt trotzdem ganz stumpf einige Fragen zu euren Ausführungen stellen, damit ich nichts falsch verstanden habe. Achtung: Es werden wohl auch Fragen dabei sein, die nur noch mal zur Klarifizierung des von euch angesprochenen dienen, damit ich mir sicher sein kann alles richtig eingordnet zu haben.

Zu Husi:



Was heißt für alle Teilnehmer? Persistent? Also können alle Objekte auf den Code bzw. Variablen, die in einem persistenten Objekt vorliegen zugreifen? Und umgekehrt geht das nicht?



Mit hinzufügen meinst du, dass die object_id schon Teil der in der Map gespeicherten Values ist, oder steht die in deinem Beispiel außerhalb und wird "zusätzlich" in irgendeiner Form mit verwendet?



Dafür müsste dann aber die Anzahl aller Kampfteilnehmer (kann ja von Kampf zu Kampf variieren) erstmal ermittelt werden, richtig? Das bedeutet, dass alle kreiierten Kampfteilnehmer-Objekte eine Kennung zugewiesen bekommen haben müssen und er dann nur zählt, wieviele Objekte mit dieser Kennung gerade existieren und das Ergebnis dann als Variable für die Anzahl der Kampfteilnehmer in diese Formel einsetzt.



Ist das so sinnvoller, als an einer Stelle alle Variablen der Kampfteilnehmer-Objekte zu vergleichen und damit zu arbeiten?

Zu Aku_Ryou:



"Magic Numbers/ Hardgecodete Zahlen sind platte Zahlen, die ich in einer Berechnung verwende anstatt mit einer Variable die Zahl in die Formel einzusetzen und diese so flexibel zu halten, oder?



Gut, dass du das angesprochen hast. Ich hatte nämlich überlegt, wo der Unterschied zwischen einem zweidimensionalen Array und einer ds_map liegt



Das ist aber dann so umsetzbar, dass die Änderungen gespeichert bleiben, wenn das Grid aus dem Speicher fliegt, bis es wieder gebraucht wird, oder? Mag eine dumme Frage sein, aber an genau solchen Dingen haperts momentan noch bei mir.



Achso, in Ordnung. In meiner Anfänger-Vorstellung waren diese Informationen immer in Datenbanken in Scripts (Arrays, Grids) geschrieben und nur bei Bedarf das Scirpt dann gerufen und gelesen worden. Kann mir wenn du das schon extra ansprichst vorstellen, dass deine Variante besser und gängiger ist. Bei mir ist das mit dem Variablen erkennen/ einlesen/ nutzen die nicht in dem Objekt stehen, dass damit etwas tun soll leider noch ein Problem. Hatte mal einen Code, der die agility-variable zweier anderer Objekte vergleichen sollte und das hat vorne und hinten nicht geklappt Ich weiß auch immernoch nicht, ob ich da falsche Variablentypen gewählt habe, die das fremde Objekt dann einfach nicht erkennen konnte, mien Code einfach falsch war, oder die ganze Ideee so umständlich war, dass es für mich noch garnicht umsetzbar war, weil mir das Grundverständnis fehlt



Du hast mir sehr weitergeholfen und ich wollte das auch ungefähr deinen Ausführungen entsprechend angehen: Platzhalter-Sprites und Hintergründe und erstmal die Systeme und Mechanics, bevor ich mit dem Content anfange

Achso, also sind das doch zwei verschiedene Funktionen. Dann werd ich mir als Erstes mal angucken, wo die Unterschiede liegen.

So, nach zweieinhalb arbeitsreichen Wochen komme ich diese Woche wohl endlich mal wieder längere Zeit dazu mich meinem Projekt zu widmen. Ich habe wo ich konnte das bischen Zeit genutzt mich zu den Themen ds_grid und ds_map zu belesen und mich auch bei Anderen durchgefragt. Jetzt gerade gehe ich meine Designs für das Kampfsystem nochmal durch um eine Liste der benötigten Variablen zu erstellen.

Meinem Verständnis nach stehe ich jetzt vor der Wahl ds_grid oder ds_map wobei der Unterschied laut Hilfe darin besteht, dass die map sowohl Key als auch Value in einer Zelle beinhaltet und nicht nur ein Value. Worin bestehen nun für mich die Vorteile bzw. Nachteile eine Map anstatt eines Grids zu nutzen?

Zu Aku_Ryou:

Du hattest geschrieben, dass es sich bei solchen Datenbanken nur um Text handeln würde und ich nur bei Allem was gedrawed wird darauf aufpassen müsste, es nach Verwendung aus dem Speicher zu löschen. Ist die Hilfe da nur sehr vorsichtig, denn da steht zur ds_map, dass man diese Datenbanken auch immer aus dem Speicher löschen sollte.

Lieben Gruß,

Ben

Also ich sitze grad an einem Grid. Ich lege alle Informationen (Values), die ein Kampfteilnehmer braucht, in dieses Grid (HP, etc.). Eine Zeile des Grids enthält dann immer alle notwendigen Values eines Kampfteilnehmers. Ich überlege noch ob ich ein einziges Grid für alle Verbündeten und Gegnerklassen zusammen mache, oder Verbündete und Gegnerklassen trenne. Oder ich trenne auch die Gegnerklassen nach Gebieten, in denen diese auftauchen können, so kann ich Gegner aus früheren Leveln aus dem Speicher löschen. Ist aber alles Zukunftsmusik. Was ich jetzt brauche um ein funktionsfähiges System daraus zu machen, ist einmal die gerade angesprochene Grunddatenbank (momentan halt als grid) in der alle Values die ich den Kämpferobjekten zuordnen muss enthalten sind. Diese kommt dann ins Create Event meines persistenten Controlobjects, welches die Werte dann den Kämpferobjekten zuweist, nachdem diese für den aktuellen Kampf kreiiert wurden. Wie weise ich diese Werte denn zu? Haben die Kämpferobjekte alle nur initialisierte aber "leere" eigene grids in ihrem create event und dann setze ich die bestimmten koordinaten in deren grids gleich den entsprechenden values aus meinem Datenbank grid?

Hallo zusammen,

endlich komme ich mal wieder dazu hier zu schreiben. Auch wenn ich momentan auf sämtliche meiner Daten, Designs und Dokumente zu meinem Game-Design nicht zugreifen kann und durch eine nervige Rücken-OP beeinträchtigt bin. Ich werde wohl in naher Zukunft nochmal ganz von vorne anfangen müssen und mir dabei einen besseren Weg einfallen lassen zu lernen, da ich mit eurer Hilfe so eine klare Vorstellung davon hatte, was ich machen musste, dass ich schlussendlich viel tiefer in die Materie eingedrungen war, als ich mit meinem Wissen noch hätte verarbeiten können

Erstmal werde ich mich wohl darum kümmern mit meinem hier Gelernten die theoretische Basis meines Designs zu erweitern und einen strukturierten und sinnvollen Plan für die Reihenfolge der Entwicklung einzelner Bestandteile meines Projekts zu machen. Auch interessant wäre vielleicht der Zusammenschluss eines kleinen Teams das interessiert wäre an meinem Projekt zu arbeiten. Unter welchen Umständen, müsste sich dann zeigen, vorher werde ich natürlich noch eine Zusammenfassung meines Designs zur Verfügung stellen, wahrscheinlich im allgemeinen Konzepte-Forum. Mal sehen was so kommt und wer sich möglicherweise interessiert zeigt

Lieben Gruß,
Ben