nen globalen DAtenmanager zu nutzen halte ich hier auch für sinvoll. Mit ner handvoll dafür geschriebener funktionen könnte man dann auch das hinzufügen/entfernen von relevanten objekten managen. Durchaus eine überlegung wert.

Mein Speichersystem ist recht einfach gehalten und versionsunabhängig, indem ich es ausschließlich auf Info-Variablen beschränke. Ich verwende auch game_save und game_load, allerdings speichere ich per SV_INFO-Modus nur diejenigen Variablen, die ich tatsächlich brauche.

- Ich speichere Grafik- und Spieleinstellungen. z.B. aufloesung_x_i //_i für Info -> Lese im Manual unter game_save -> SV_INFO

- Ich speichere den Spielfortschritt. Eine Variable für den Karrierefortschritt des Spielers, eine Variable für verdiente Credits, ein paar wenige andere Variablen für Achievements und den Item-Shop. z.B. karrierefortschritt_i und credits_i

Bei jedem Spielstart wird die Speicherdatei ausgelesen. Mein Code ist so ausgelegt, dass die Auflösungs- und Soundeinstellungen bei jedem Spielstart nach diesen Variablen eingestellt werden, genau wie Mausempfindlichkeit, Helligkeit, Kontrast, Grafikeffekte, Shader, Anti-Aliasing etc.
Beim Spielfortschritt ist das ähnlich: Wenn der Karrierefortschritt bei 0 ist, kann nur ein neues Spiel gestartet werden. Falls bei 1, ist die erste Mission schon geschafft und es kann mit der Zweiten fortgefahren werden.
So auch beim Item-shop. Ist die Variable für die verbesserte Pistole auf 1, befindet sich diese im Inventar des Spielers und wird im Item-Shop als gekauft markiert.

Der Spieler merkt nichts von diesem minimalistischen System. Außer, dass die Speicherdatei nur 1 Kilobyte klein ist und er weder was vom Speichern noch vom Laden merkt, da es quasi in Echtzeit funktioniert.

Wenn man dieses einfache System beibehält gibt es nachher auch keine Probleme mit fehlerhaften Speicherdateien bei verschiedenen Versionen. Klar sind Rollenspiele ein wenig komplexer als ein Arenashooter, aber trotzdem würde ich so einfach wie möglich halten und auf ein Variablensystem setzen. Speichere zumindest nur das, was du wirklich brauchst. Das geht schneller, ist eleganter, vermeidet Fehler und etliche Probleme.

Ach und vergiss das mit dem eigenen Speichersystem. Das von Gamestudio ist mehr als gut genug, läuft fehlerfrei, wenn man es richtig einsetzt :-) . Ein Eigenes bringt nur Probleme und Frust falls du kein erfahrener Programmierer bist. Nicht böse gemeint, nur meine Erfahrung. Never touch a running system.

In der Hinsicht könnte man game_save/game_load für allgemeine Applikations-Optionen zu Beginn des Programmstarts verwenden, wie Rondidon vorgeschlagen hat. Aber der Spielstand an sich ist ne ganz andere Kiste, meiner Meinung nach. Ein "Variablensystem" kann man hier bei einem RPG nahezu gar nicht anwenden, weil es da folgenden Spagat gibt:

- Es würde funktionieren, wenn man ALLES in allein stehenden Variablen ausdrückt (Quests, Items, Itemzustände[zB Anwendungen] etc.)

- Auf der anderen Seite würde jeder halbwegs ambitionierter Coder dafür Structs verwenden, die wiederum nicht mit game_save/game_load abgespeichert werden können ... Das Manual sagt zwar, dass das irgendwie funktionieren soll, wenn man alles in ein "Überstruct" schmeißt und dieses Struct zum Speichern registriert. Allerdings gehen alle Pointer so oder so flöten - also Dreck!

Da ich nicht zu der Sorte Leute gehöre, die einen Kompromiss mit der Engine eingehen, indem sie das Quest- und Itemsystem auf endlos lange und multidimensionalen Arrays stützen, ist die Engine-eigene Speicherfunktion für mich also total für die Katz!

Ein Anderer Gedanke ist, dass ich immer versuche alles so sauber wie möglich zu halten - daher empfinde ich die Variante mit ausreichend "Dummy-Objekten" auch sehr unbefriedigend ^^ Auch weil ich mir dann gleich wieder den Kopf über Sachen zerbreche, wie: Was macht der Arbeitsspeicher? Wie wirkt sich das alles auf die gesamte Performance aus? ...

Mag sich pingelig anhören, aber in solchen Problemen kann ich mich so festbeißen, dass ich iwann keine Lust mehr habe irgendwelche angefangenen Projekte fortzuführen.
In dem Sinne: Der Weg ist das Ziel. Nimm das, was zu deinem bisherigen Script gut passt und möglichst problemlos umzusetzten ist

Hallo,

ich wollte mich schon lange mal melden auf eure Beiträge zum Thema "Spielstand speichern". Wie es aber so kommt, gab es ein paar andere Probleme mit denen ich unmittelbar danach "kämpfen" musste.

Zum Thema "Speichern":

Ich denke, ich werde tatsächlich die von der Engine zur Verfügung gestellten Speicher- und Ladefunktionen nutzen. Ich stelle ständig fest, dass mir insbesondere bei den Quests und Dialogen immer noch so die eine oder andere Variable fehlt. Das wäre ja dann wie beschrieben jedesmal das Aus für evtl. Updates. Meinen Level Goldstein kann man jetzt bereits schon probespielen. Wobei mir immer wieder Bugs auffallen, die wiederem dann meistens mit einer zusätzlichen Funktion und Variablen behoben werden können. Da ich mal davon ausgehe, dass ich sowieso nicht alle Bugs allein finden werde, scheidet das wiederum aus.

Also werde ich dann das normale Speichersystem verwenden. Es wird dann 10 Speicherstände geben. Das sollte ausreichend sein.

Schön wäre es, wenn ich neben dem Speichernamen noch einen Screenshot der letzten Spielerpositiuon einblenden könnte. Das sollte doch irgendwie gehen.

Es gibt ja die folgende Möglichkeit:



Ich habe aber darüber weiter nichts brauchbares gefunden. Habt ihr da einen Tipp?

Ein weiteres Problem hatte ich noch:

Meine Dialoge mit den NPC's werden in einer Funktion über viele viele If's ausgelesen und verglichen. Ein Array habe ich nicht verwendet. Der Grund dafür lag daran, dass ich am Anfang noch nicht so viele Dialoge hatte, diese immer mehr wurden, ich das dann nicht umstellen wollte ....... ja und dann war es eben so.

Jetzt "crasht" meine Funktion wenn ich eine bestimmte Anzahl von Scriptzeilen in der FUnktion überschtitten wird. Ich habe die Anzahl jetzt nicht nachgezählt, ea sind aber etliche 1000. Den Fehler kann ich mir jetzt nicht erklären. Habe daher eine zweite Vergleichsfunktiuon erstellt und es geht jetzt wieder.

Nächsten Problem:

Ich erhalte einen "D3D - out of Memory Error". Das habe ich mal auf den Speicher meiner Grafikkarte geschoben. Ein weiterer Fehler meinerseits, wenn man das als Fehlere bezeichnen kann, lag daran, dass ich viele Paneld mit ".bmp" Grafiken erstellt habe. Da habe ich dann nicht auf die Anzahl geachtet, Bei bmp. kommt ja schnell mal eine Größr von 4MB zusammen. Jetzt verwende ich .PCX, sollte ich von Anfang an vewenden.

Wie sieht es denn mit der Verwendung von z.B. .JPG aus? Die haben ja ein relativ geringen Umfang.

GRuß, Andreas

Hallo Andreas,

Zu deinen "out of memory" Problemen.

Ich hatte in meinem eigenen Projekt eine Zeit lang ähnliche Probleme. Tatsächlich lag das aber nicht an fehlerhaften Funktionen und Scripting-Komplexitäten, sondern an schlechtem Umgang mit Ressourcen. Die Abstürze kamen immer beim Laden von Leveln, teilweise seltsame E1513s, oder auch mal "out of memory". Ich hatte zu dem Zeitpunkt sehr viele Entities in meinen Levels (jeder Grashalm einzeln gepflanzt, viele unnötige Zier-Objekte ohne echten Sinn) und vor allem sehr viele unkomprimierte Texturen im Einsatz. Ein geladenes Level verbrauchte alleine schon mal an die 400 Megabyte im Speicher.

Ich habe das dann gelöst, indem ich zunächt alle Texturen und Grafiken komprimiert habe (DDS, auch für Modelle) und vor allem unnötige Texturen und Entites entfernt habe. Alle Gras-Modelle habe ich duch ein großes Modell ersetzt und damit die Entity-zahl im Level um 5/6 reduziert. Außerdem habe ich für mein gesamtes Spiel jetzt nur noch etwa 30 komprimierte Texturen, die allesamt in allen Levels wiederverwendet werden anstatt etwa 120, die teilweise nur für einzelne Objekte vorgesehen waren oder je nach Level variierten.

Seither läuft das Spiel nicht nur stabil, sondern auch sehr schnell, selbst mit erweiterten Shadereffekten und auch auf langsameren Rechnern. Abstürze habe ich nun keine mehr.

Ich würde dir also raten, zunächst zu optimieren und dadurch Speicher einzusparen. Danach lösen sich viele Probleme von alleine.

"Supercan" funktioniert übrigends ähnlich. Im Spiel sind nur recht wenige unterschiedliche Modelle und nur sehr wenige Texturen zu sehen. Die Levels sind auch recht klein gehalten. Durch guten Umgang mit Ressourcen gewinnt man letztendlich mehr als mit großer Texturen- und Modell-Vielfalt.

zu deiner Dialog-Funktion: Splitte sie einfach in zwei Funktionen. z.B. Dialogfunktion1 und Dialogfunktion2. Du solltest dir eben merken, welcher Dialog in welcher Funktion steckt.

Ok, die Tipps habe ich soweit befolgt.

Allerdings habe ich immer noch diesem "out of memory" Error.

Das was ich merkwürdig finde ist, dass ich mein Level im aktuellen Gamestudio builden lasse und danach der Level problemlos funktioniert.

Am nächten Tag möchte ich den Level dann wieder laden und starten und dann erst kommt dieser Fehler.

Danach lösche ich viele Modelle, besonders die letzten eingebrachten, aber es ändert sich nichts daran. Den Fehler erhalte ich immer noch.

Erst wenn ich dann sehr viele Modelle o.Ä. lösche läuft es wieder. Ist schon schade. ich bin kurz vor der Fertigstellung und der Präsentation. Das wirft mich mal wieder so richtig zurück. Naja, das werde ich dann wohl auch noch hinbekommen.

Ich werde mal so einige Panels in Strings umwandeln. Vielleicht bringt das ja was.

GRuß, Andreas

Nexus erhöhen?

Du MUSST und WIRST das hinbekommen grinseengel! Es währe so schön wieder etwas von deinem projekt zu sehen.
Sorry, das ich sonst nichts nützliches zu sagen hab. ^^


mfg
OTTER

Nein, das habe ich bereits schon probiert. Ändert nichts.
Mal eine Frage:
Nach Druck von F12 kann man ja die Systemressourchen sehen. Gibt es da eine Empfehlung wie hoch der Memory maximal sein sollte? Meine FPS liegt bei etwa 45, das ist nicht das Problem.

Wann sprichst Du von der wmb und wann von der wmp?
(Bitte, jeweils an der entsprechenden Stelle einfügen! )