spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

ist schon ganz interessant zu lesen, auch wenn du dich wohl nicht an eine Umsetzung machen wirst
beim Lesen musste ich (mal wieder) an diverse andere Spiele denken
beispielsweise Chrono Trigger: dort hatte man zwar ein rundenbasiertes Kampfsystem, allerdings sah man seine Gegner in der normalen Umgebung und kämpfe auch in dieser
in vielen anderen Spielen mit rundenbasiertem Kampfsystem gibt es für die Kämpfe separate Umgebungen

weiterhin musste ich an Final Fantasy X denken
einerseits hatten die eingesetzten Angriffe/Fähigkeiten/... einfluss auf die Angriffsreihenfolge (also als würden diese Dinge verschieden viel Zeit beanspruchen)
man konnte zu jeder Zeit im Kampf sehen, wie sich die Reihenfolge bei welcher Aktion verändert
außerdem waren die Charaktere nicht ganz so fest auf ihre "Laufbahn" festgeschrieben
es gab ein "Sphärobrett" (oder wie es geschrieben wird), auf welchem man Felder freischalten konnte, welche für verschiedene Verbesserungen der Fähigkeiten sorgten (Stärke +3, Magie +2, ...)
mit jedem Level-Up hat man Punkte bekommen, um sich auf diesem zu bewegen und nach Kämpfen oder in Shops konnte man an die Items zum Freischalten kommen
es gab außerdem "Blockaden" auf diesem Brett, an denen man erst vorbei kam, wenn man sie mit entsprechenden Items beseitigte
es Leere Felder, die man selbst mit Eigenschaften füllen konnte und meines Wissens auch die Möglichkeit, eine Eigenschaft aus einem Feld zu entfernen

Yuna hat beispielsweise von Anfang an eine Ausrichtung zur "Weißmagie", kann sich aber bis zum Ende zu einer besseren "Schwarzmagierin" entwickeln, als Lulu (anfangs Schwarzmagie) es war


ich entwickle (noch) mit Python 3.1 und dafür gibt es auch PyGame
da ich bisher mit Python ausschließlich Pygame genutzt habe, hatte ich quasi nie Versionsprobleme
aber die Problematik verdeutlicht, dass ich mich um etwas, wie Py2Exe kümmern sollte... =/
eine kurze suche auf Google hat mich zu cx_Freeze gebracht, allerdings müsste ich noch schauen, in wie weit das funktioniert und was ich ggf. zu beachten habe

ich habe jetzt den Abschnitt zu den Mapobjekten überarbeitet (weil ich endlich zu einem Weg für diese gekommen bin, den ich wohl auch umsetzen werde)
es ist zwar schon ein wenig was für diese implementiert, allerdings fehlt noch einiges an Arbeit, bevor wieder etwas vorzeigbares entsteht
mal sehen, ob ich es noch diesen Monat hinbekomme (dieses WE steht mal wieder etwas an, aber ansonsten habe ich wohl ein wenig Zeit...)

mir fällt gerade auf: ich habe noch nicht probiert, eine ausführbare Datei zu generieren... =/

Hier mal ein kleines Update, um die bisherigen und (hoffentlich) demnächst folgenden Veränderungen zu beschreiben.

Damit man mich besser verstehen kann, hier meine derzeitigen Gedankengänge dazu:
Bei den Mapobjekten mache ich mir derzeit noch ein paar Gedanken bezüglich der Skriptverwaltung/-ansteuerung. Für jedes Mapobjekt kann für diverse Events (active, enter, ...) festgelegt werden, welches Skript ausgeführt werden soll. Da bin ich derzeit noch am Überlegen, was grubndsätzlich sinnvoll ist und in wie weit "Überladungen" sinnvoll sein könnten. Einerseits kann jedes Gebiet (bzw. jede Maop) beliebig viele Skripte beinhalten, andererseits kann dies auch jede Objektdefinition (bzw. jedes nicht-lokale Mapobjekt). Dass übergeordnete Skripte "nach unten durchgereicht" werden, sofern sie nicht überschrieben werden, halte ich in beiden Fällen für sich gesehen in Ordnung (übergeordnete Objektdefinition zu untergeordneten oder übergeordnetes Gebiet zur untergeordneten). Allerdings bin ich mir nicht sicher, ob Objektdefinitionsskripte die Gebietsskripte überlagern sollten oder umgekehrt und in welchen Fällen dies überhaupt möglich sein soll.
Zur Orientierung überlege ich mir anhand ein paar einfacher Beispielobjekte und einer exemplarischen Umgebung Fälle, in denen diese Konstrukte sinnvoll sein könnten bzw. suche mir Situationen aus bereits vorhandenen Spielen, die sich damit abdecken oder nicht abdecken lassen. So zum Beispiel wird es auf jeden Fall den Helden (nicht-lokale Objektdefinition), Schalter (benannte Instanz) und Monster (unbenannte Instanzen) geben. Der Held beispielsweise dürfte in quasi keiner Situation in (direkter) Abhängigkeit von der Umgebung Aktionen (Skripte) ausführen, weshalb aus dieser Sicht das Überschreiben der Objektskripte durch die Mapskripte nicht gewollt ist. Die unbenannten Instanzen (beispielsweise ein gewöhnliches Monster, welches im Gegensatz zu den anderen eine besondere Bedeutung hat) sollten grundsätzlich die Skripte der Definitionen verwenden und nur für diverse Ereignisse Umgebungsspeziefisches Verhalten aufweisen (öffnen einer Tür) - dafür könnte beim "instanziieren" das Skript festgelegt werden. Das Gleiche gilt auch für benannte Instanzen, wobei diese eher Skripte der Umgebung nutzen würden - wieder ohne "Überschreibung" festgelegte Skripte.
Sollte ich mich konkret entschieden haben, wie ich es umsetzen will, werde ich nochmal schreiben und evtl. den Eingangspost aktualisieren.

Was ich tatäschlich geschafft habe:
Es ist zwar nicht viel, aber der Text der Dialoge passt sich dem vorhandenen Platz an. Bisher heißt das bloß, dass Leerzeichen als Abgrenzung der Wörter verwendet werden und nur so viele Wörter in einer Zeile ausgegeben werden, wie auch in diese Zeile passen.
Es fehlt aber immernoch das Verhalten für das "weiterblättern", sollte ein Text zu lang sein, als dass er auf einmal ausgegeben werden kann. Außerdem soll es später möglich sein, ein Mapobjekt oder eine ID eines solchen zu übergeben und anhand dessen automatisch den (Anzeige-)Namen mit einer Farbe, abhängig von den Objektvariablen, anzuzeigen. Außerdem soll es später möglich sein, eine Text-ID zu übergeben, anhand derer der eigentlich anzuzeigende Text ermittelt wird. Dies wiederum würde eine Übersetzung eines Spiels wesentlich vereinfachen (siehe Internationalisierung und Lokalisierung). Weiterhin sollen noch Formatierung möglich sein, wobei das wichtigste wohl erstmal nur das integrieren von Bildern in den Text sein wird (beispielsweise zur Erklärung der Steuerung).

Ich habe mich eigentlich auch nur daran begeben und nicht mit den Mapobjekten weiter gemacht, weil ich (u. a. während einer Zugfahrt) weiter machen wollte, aber in dem Moment nicht die "Motivation" für die Mapobjekte hatte...
Die Dialoge weiter auszubauen bleibt also aufgeschoben und Mapobjekte sind derzeitiges Entwicklungsziel. Um konkreter zu sein: derzeit verwende ich noch die alte Mapobject-Klasse mit den beiden Ausprägungen Character und Trigger und ich möchte so bald wie möglich zumindest dahin übergehen, dass man kein Character-Objekt mehr herumscheucht, sondern ein Objectdefinition-Objekt (zukünftig vlt. Mapobject) herumkommandieren kann. Der Zugriff auf die Objektdefinitionen und deren Variablen ist bereits möglich, allerdings gibt es noch nicht die Möglichkeit, (benannte und anonyme) "Instanzen" anzulegen.


Worüber ich mir auch schon ein paar Gedanken gemacht habe, was ich aber noch nicht so direkt angesprochen habe:
Welche Ressourcen sollte ich zu Beginn einmal auslesen und die ganze Zeit im Speicher halten und welche sollte ich nur bei Bedarf laden und ggf. wieder entladen?
Eine Möglichkeit wäre es, zu sagen: alle dynamischen Sachen (bspw. Variablen) am Anfang komplett einlesen und alle statischen (Mapdaten, Bilder, Sounds) erst, wenn sie benötigt werden
Zu den Ressourcen an sich: Es gibt bisher Maps, Objektdefinitionen, Tilesets, Charsets, Skripte und Variablen (Sound und Musik ist bisher noch nicht implementiert). Mit Map meine ich die Levelinformationen (welches Tile befindet sich an welcher Stelle, wo befindet sich welches Objekt), welche grundsätzlich klein sein sollte, die Tilesets und Charsets sind bisher die einzigen Ressourcen, die auch grafiken enthalten (Maps und Mapobjekte verweisen auf diese).
Die ersten paar Demos bzw. das Spiel an sich, welches ich hiermit entwickle, dürften wohl so klein sein, dass quasi alles in den Arbeitsspeicher geladen werden könnte, allerdings denke ich nicht, dass ich dies machen sollte, nur weil es möglich ist...

Es wäre ganz interessant zu wissen, wir ihr solche Ressourcen, die nicht im gesamten Spielverlauf benötigt werden, verwaltet bzw. wie dies von größeren Engines (Cry-Engine, Soruce-Engine, Unreal-Engine, "Unity-Engine", ...) gehandhabt wird.

Zunächst erstmal die Frage: interessiert sich jemand für die Entwicklungen an diesem Projekt (oder wohl eher für diese Updates, da eigentlich nicht viel zwischen diesen bisher passiert ist) oder fühlt sich jemand dadurch gestört?
In letzterem Fall könnte ich ja versuchen, Rücksicht darauf zu nehmen, aber letztendlich wohl unabhängig davon oder vom Interesse weiter machen!

Mal wieder ein kleiner Zwischenbericht:
Wiedereinmal habe ich mich nicht (nur) um die Mapobjekte gekümmert. So habe ich meinen Code leicht umstrukturiert (bspw. wird der "ScriptExecuter nicht mehr im "Game" Objekt erzeugt und dann über den "StateManager" an den "GameState" weitergereicht, sondern erst dort erzeugt), die Imports umgestaltet (keine imports im Stile "import pygame" mehr, sondern beispielsweise "from pygame.locals import HWSURFACE") und die Performance ein wenig verbessert.
Für das Aus- und Einblenden hatte ich bisher (warum auch immer) bei jedem Render-Aufruf ein Surface-Objekt erzeugt, schwarz gefüllt, Transparenz gesetzt und es gezeichnet. Jetzt wird die Erzeugung im Konstruktor erledigt und das Zeichnen nur noch dann, wenn keine völlige Transparenz vorhanden ist. (Ich weißt: schon allein dafür, dass ich das nicht sofort gemacht habe, gehöre ich eigentlich gesteinigt.)
Merkwürdigerweise schwankt die Ausfürhungsgeschwindigkeit dennoch, meist sogar unabhängig von Codeänderungen, zwischen den Ausführungen.

Aus Spaß habe ich einfach mal geschaut: was passiert denn, wenn ich die Auflösung (ein Eintrag ist in der "Konfigurationsdatei" vorgesehen) ändere:
Zunächst ist nichts weiter passiert, als dass das Fenster größer wurde. (Der sichtbare Ausschnitt blieb oben links und wurde nicht größer/kleiner/schwammiger/...)
Nach einer kleinen Anpassung (Verbannung von der hardcoded Auflösung an anderer Stelle im Code), wurde dann auch der Sichtbare Ausschnitt größer... und die Performance ging mehr oder weniger den Bach runter.

Eine andere angestrebte Performanceverbesserung, die ich allerdings noch lange lange vor mir herschieben werde (da vermutlich ziemlich umständlich), ist die Umstellung auf eine andere Programmiersprache und eine andere Bibliothek.
Bisher angestrebt habe ich C# und XNA, da C# neben Java und Python die einzige Sprache ist, die ich auch ausreichend beherrsche. (Und weil ich an dem Projekt weiterarbeiten und mich nicht mit einer neuen Sprache rumplagen will.)
Ich bin mir noch nicht ganz sicher, wie ich das mit den Skripten handhaben werde, allerdings werde ich diese wohl weiterhin Python verwenden.
Ich habe zwar schon grobe Überlegungen angestellt, wie ich C# (oder die entsprechende Zwischensprache) als Skriptsprache verwenden könnte, allerdings waren diese wirklich nur sehr grob...

Mapobjekte:
Ich habe es soweit bringen können, dass ich ein Mapobject über die Karte befehligen kann (und nicht mehr ein Character wie vorher). In dem Zusammenhang funktioniert auch alles soweit (Kollision, Anpöbeln der legacy-Character-Objekte etc. ...).
Es dürfte nicht mehr lange dauern, bis auch die anderen Mapobjekte "richtige" Mapobjekte sind.
Darauf würde dann das Implementieren weiterer "Events" anstehen, wie "activate" (Ansprechen oder betreten) oder "push" (damit beispielswesie Blöcke verschiebbar werden).
Wenn es verschiebbare Blöcke (und noch ein paar andere Kleinigkeiten) gibt, wird es wohl mal wieder etwas zu sehen geben
(Ich habe den ersten Beitrag ein wenig überarbeitet, sodass die Mapobjekte jetzt eine Struktur haben und unter "lokale Mapobjekte" ein bisschen mehr steht.)

Eine andere Umstrukturierung gab es bei den Animationen der Charsets.
Bisher war es so, dass ein Character speichern musste, welcher Frame gerade angezeigt werden muss, wie lange der Frame angezeigt werden soll und wie viele "ticks" seitdem vergangen sind.
Jetzt wird dem Mapobject mitgeteilt, wie viel Zeit bisher insgesamt vergangen ist, dieser errechnet die Differenz seit der letzten "Aktionsänderung" (bisher wären das "laufen", "stehen" und "schieben") und gibt das Ergebnis an das Charset weiter, wo dann die Berechnung des darzustellenden Frames stattfindet.
Noch sind die FPS hardcoded, allerdings soll es in Zukunft von der Animation abhängig sein und es wäre denkbar, dass es keine Wiederholung gibt oder dass diverse Frames länger angezeigt werden.

Die Änderung dafür hat aber auch dafür gesorgt, dass Animationen der Umgebung (in dem Variablentest nicht zu sehen) nicht mehr funktionieren. Aber das hat ja Zeit...

euer von euch allen über alles geliebter Sacaldur (was für ein Glück, dass sich eh niemand den Beitrag so weit durchlesen wird! ;D)

nein, dazu hatte ich vorher nichts geschrieben

was das "nichts sichtbar" angeht:
ich habe es in meinem Fall so gelöst, dass einerseits der "GameState" über ein Surface (ich weiß nicht, was vergleichbare Klassen in anderen Libs sind) verfügt, auf dem gan normale gezeichnet wird (Umgebung, Spieler, GUI, ...) und dass er zusätzlich ein Surface besitzt, über welches das Ein- und Ausblenden des Bildes realisiert wird
letzteres Surface wird nur dann auf das 1. Surface gezeichnet, wenn es nicht gänzlich transparent ist
und das ist quasi die Regel

ich lasse mir in der Titelleiste schon seit langem (auch schon im Variablentest zu sehen) die für einen Frame vergangene Zeit in Millisekunden ausgeben
und das Zeichnen des 2. Surface braucht ein paar Millisekunden (für 60 FPS (angestrebt) dürfen 16,666 ms nicht überschritten werden)
ich weiß, dass das Spiel kurz nach der Umstellung grundsätzlich flüssig lief und nur beim Mapwechsel (Aus- und Einblenden) dann ~20 ms je Frame brauchte
jetzt ist es so, dass ein normaler Frame 9-10 ms benötigt und mit Ein- oder Ausblenden 13-15 (oder so)

zu beachten ist:
die Transparenz wird nicht Pixelweise gesetzt, sondern für das gesamte Surface
beide Surfaces sind derzeit 320x240 groß
ich denke, das alleine dürfte schon verdeutlichen, warum ich von Python (oder wohl eher PyGame) weg gehen werde... (irgendwann einmal...)


oder um es anders zu formulieren:
hättest du mal den Quelltext angeschaut! =P


nur so am Rande: es dürfte nicht mehr lange dauern, bis ich nur noch die "neuen Mapobjekte" verwende (und dann nur noch die "Events" implementieren und ich bin wieder beim alten Stand! ;D)

Mal wieder ein kleiner Ziwschenstand:
Vor einer Weile erst habe ich es geschafft, die Umstellung von den bisherigen Charakteren und Triggern auf Mapobjekte durchzuführen (und diverse Bugs zu beheben, die sich wohl im Zuge dessen erst ergeben haben).


Als nächstes werde ich dann erstmal das Verschieben von Mapobjekten implementieren, damit dann mal wieder ein "Minispiel" folgen kann. Dieses dürfte im Gegensatz zu dem Variablentest schon interessanter sein, allerdings immernoch, mehr oder weniger, minimalistisch...
Sobald das fertig ist, würde ich das Kampfsystem in Angriff nehmen, was allerdings auch ein paar andere Dinge voraussetzt, wie das Überarbeiten der Charsets (igendwie muss der Spieler eine Waffe schwingen können) oder die KI für die Gegner, wenn auch ganz einfach gehalten.
Und wenn das dann getan ist, kommt das Inventar an die Reihe, damit dieses (spätestens dann) richtig funktioniert und über mehr Funktionalität verfügt. Dazu würde dann auch gehören, dass man bspw. über einen Shop an weitere Gegenstände kommen kann.

Ich befürchte aber auch, dass das Spiel auf Dauer zu unperformant wird, als dass ich es flüssig auf meinem Laptop (2 Kern 2 GHz Prozessor und Intel-Grafikkarte/-chip) spielen kann. Schon jetzt gibt es die einen oder anderen Dinge, die zu einem Sinken der Framerate führen können. Dazu gehört aber allem voran das Ausführen im Debugmodus, in dem die Framerate von 60 FPS auf ~ 5 FPS einbricht (spürbar an einer enorm verzögerten Bewegung, bei der das Triggern Fehlerhafter Ereignisse keinen Spaß macht). Man könnte meinen, ich solle mich nicht so anstellen und doch einfach meinen um einiges besseren Desktop-PC verwenden, um am Spiel zu entwickeln. Grundsätzlich wäre das ein berichtigter Einwand, allerdings müsste ich dann jedes Mal, wenn ich unterwegs (mit dem Laptop), weiterentwickeln will, den aktuellen Stand auf den Laptop bekommen.
Und ich will sowieso bald auf eine andere Programmiersprache und ein anderes Framework wechseln, bei dem die Performanceprobleme dann hoffentlich nicht so intensiv sind. Es gibt ein paar Gründe, warum ich das noch nicht in Angriff genommen habe:
Derzeit präferiere ich C# und XNA, wobei ich aber auch schauen wollen würde, in wie weit (ohne Codeänderungen) Mono und ANX verwendbar sind. Problematisch könnte bei XNA das Format für die Assets sein, da diese nicht im ursprünglichen Format vorliegen, sondern als *.xnb-Dateien. Ich müsste also ggf. ersteinmal schauen, wie ich die Dateien erzeugen kann, was allerdings möglich sein sollte. Da die Dateien nicht mehr im Ursprünglichen Format vorliegen, wäre es sinnvoll, wenn bis zur Umstellung bereits ein Editor besteht, über welchen das "Übersetzen" der Ressourcen durchgeführt werden kann. In dem Zusammenhang würde ich auch gleich schauen wollen, in wie weit ich meine eigenen Dateien (Maps, Scripte, Variablen etc.) in diesem Format hinterlegen könnte.
Also kurz zusammengefasst: ich halte es derzeit für einen relativ großen Aufwand, der allerdings irgendwann bestritten werden muss...

ok, bisher hatte ich nicht bedacht, dass ich die Erzeugung der XNB-Dateien ohne eigenen Editor erstmal weiterhin Visual Studio machen lassen kann
Ich müsste mich wohl nur noch mit dem Erstellen des Importers beschäftigen und in dem Zusammenhang damit, was Visual Studio aus meinen Dateien (Textdateien für die Maps, Mapobjekte etc.) macht
und damit, wie ich Python-Code ausführen kann bzw. die Skripte kompilieren und zu Laufzeit laden kann

das Problem ist nur:
ich finde die Entwicklung mit Python derzeit als recht einfach und zügig
zudem ist bei den Variablen zwar vorgesehen, dass diese einen bestimmten Typ besitzen, dies wird bisher aber nicht weiter berücksichtigt und ich weiß nicht, in wie weit es möglich/sinnvoll ist, unter C# darauf ebenfalls nicht zu achten (oder es doch lieber "richtig" zu implementieren)

mal sehen, wann ich das angehen werde (ob noch vor dem nächsten "Minispiel" oder erst danach, wobei es für die Spieler sinnvoll wäre, es bereits vorher zu machen)


und ich habe vergessen zu erwähnen: im Startbeitrag gab es ein paar kleinere Änderungen
so zum Beispiel sind jetzt ein paar vordefinierte Variablen und "Events" (Skripte, die automatisch bei bestimmten Ereignissen ausgeführt werden) zu finden