spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Farben sind in dem Fall vielleicht kein ganz so gutes Beispel, da ich dafür wohl einen eigenen Typen nehmen würde, aber ich weiß, worauf du hinaus willst.

Editor später! Wann später steht noch nicht fest, aber ich denke mal zum "Mini Adventure" (3 Dungeons) evtl., da es in diesem weit mehr Maps geben wird und ich in dem auch eher aufdas Leveldesign achten will, als es bei den derzeitigen Tests erforderlich ist.

Ich habe mein Ziel erreicht, noch dieses Jahr eine weitere Testversion des Spiels fertig zu stellen! =)
Es wird XNA und das .Net Framework benötigt, IronPython ist enthalten, weshalb das Spiel auf ohne IronPython Installation starten sollte. Das Tileset habe ich mir dieses Mal von Zelda: The Minish Cap geliehen, ein paar Grafiken habe ich allerdings selbst erstellt (das sind die weniger schönen ).
Mich würde von denen, die es spielen, interessieren, wie sich das Spiel aus ihrer Sicht bisher anfühlt. Es ist zwar nur ein Bruchteil der späteren Mechaniken eingebaut, aber ich hoffe, dass sich eine Richtung erkennen lässt, in die das Spiel geht.
Ich weiß, dass die Map nicht besonders interessant aussieht, nur hätte ich mit einem guten Tool vermutlich mehr Freude am editieren gehabt...
Auch obwohl ich ein paar Bugs beseitigt hatte, sind immernoch ein paar enthalten. Ihr könnte ja bescheid geben, solltet ihr einen gefunden haben.
Einerseits hatte ich eingebaut, dass der Spieler an Objekten und an der Umgebung "abrutschen" kann, wenn er zu einem sehr kleinen Teil vor einem Hindernis steht. Das hat zur Folge, dass man vor 2 Blöcken stehen kann und immernoch einen anfangen kann, zu verschieben, auch obwohl man zu einem geringen Teil ebenfalls vor dem anderen steht und vorher dadurch keinen von beiden verschieben konnte. Wenn nun 3 Blöcke übereinander stehen und zumindest der mittlere die gleiche Höhe wie der Spieler hat, dann wäre es fast unmöglich gewesen, gezielt den mittleren zu verschieben, da man dazu direkt vor diesem hätte stehen müssen. Da die Koordinaten in Form von Fließkommazahlen gespeichert werden, ist das ohne Hilfe der Umgebung geradezu unmöglich für einen Spieler.
Weiterhin war es bisher möglich, dass tilebasiert verschiebbare Blöcke andere verschiebbare Blöcke verschieben. Der Grund dafür ist, dass für die Bewegung dieser die gleiche Methode verwendet wird, wie für die Spielerbewegung, welcher ja Blöcke verschieben kann. Außerdem wurde nicht geprüft, ob es überhaupt möglich ist, einen Block ein Feld weiter zu schieben. Das hat weiterhin zur Folge, dass man einen Block gegen eine Wand schieben konnte, sodass man ihn dann nicht mehr von dort weg schieben konnte, weil er unbedingt mit dem Kopf durch die Wand ähhh ein Feld weiter Richtung Wand wollte. Den ersten Fehler konnte ich in der Testversion allerdings umgehen, indem ich den 2. behoben habe. Da sich abgesehen vom Spieler nichts von selbst bewegt, kann es also nicht passieren, dass sich zwischen der Prüfung, ob ein Block verschoben werden kann, und der Bewegung des Blocks sich dem Block etwas in den Weg stellt. Der erste Fehler ist also noch da, tritt in dieser Version aber nie auf...
Weiterhin habe ich dem Dialogtext einen Hintergrund gegeben, da sonst der Text nur schwer zu erkennen gewesen wäre. Das war zwar kein großer Aufwand, nur hatte ich es bei der Umstellung von Python zu C# wohl nicht sofort gemacht... =/

Abgesehen davon habe ich mal wieder ein Auge auf die Performance geworfen. Das positive zuerst: die Größe der Map spielt keine Rolle (Breite und Höhe gar nicht, Anzahl Ebenen fast gar nicht). Allerdings sinkt die Performance ein wenig, wenn mehr Tiles sich im Sichtfeld befinden, die gezeichnet werden müssen. Da es wohl nie zu viele zu zeichnende Tiles werden, kann ich das aber getrost ignorieren.
Die Kollisionsprüfung hingegen scheint noch leicht problematisch zu sein, da durch diese das Spiel mit zunehmender Anzahl an Mapobjekten auf gleicher Ebene immer mehr Zeit benötigt. Sie war zwar auch schon unter Python problematisch, allerdings dort wesentlich drastischer, sodass dort weit weniger Mapobjekte notwendig waren, damit das Spiel nicht mehr flüssig lief. Die schlechte Peformance liegt allerdings nicht an einer schlechten Implementierung der Prüfung, sondern an der Handhabung der Variablen (siehe 1. Beitrag in diesem Thema), welche von der Kollisionsprüfung benötigt wird. Da die Breite und Höhe beispielsweise als solche Variablen gespeichert werden. Bei 27 Mapobjekten kommen so ~ 80 Variablenabfragen zu Stande, wodurch die Prüfung auf Kollisionen ~ 2 ms (auf meinem Laptop) dauert. Für die Bewegung eines Objekts wird die Kollisionsprüfung allerdings 2x aufgerufen. Verschiebt man gerade ein Objekt, bewegen sich bereits 2 Objekte. Das Aktualisieren der Szene dauert so bis zu 10 Millisekunden. Das zeichnen benötigt allerdings ebenfalls Zeit und in diesem Fall sind das ~ 4 Millisekunden. Da das Spiel mit 60 FPS laufen soll und das Zeichnen und Berechnen nicht in verschiedenen Thread stattfinden, sollte beides zusammen nach Möglichkeit unter 16 Millisekunden liegen, wofür 14 Millisekunden für so wenig zu viel ist. Die Lösung für das Problem mit den Variablen ist, dass die Werte, die eine besondere Bedeutung haben (width, height, passable, visible) zwischengespeichert werden, wodurch der Overhead beim Abfragen (Typprüfung, Casting, suchen in der Liste der Variablen etc.) entfallen dürfte. Der Manager der Variablen müsste dann nur noch bei Änderungen die Objekte informieren, damit der neue Wert zwischengespeichert wird.
Ich gehe davon aus, dass ich beim Zeichnen auch noch ein wenig Rechenzeit einsparen kann, da bisher scheinbar keine Prüfung enthalten ist, ob ein Objekt sich im sichtbaren Bereich befindet und somit immer versucht wird, alle Objekte zu zeichnen. von der Map jedoch wird nur der benötigte Ausschnitt gezeichnet (und das bereits seit den ersten Versionen des Spiels).

Ich habe den Anfangspost minimal angepasst. Die Liste mit Variablen und die Liste mit Skripten (unterhalb des Abschnitts Mapobjekte) wurden aktualisiert.


@Schrompf:
Ich hatte mir in letzter Zeit ein wenig Gedanken gemacht und mir sind Fälle eingefallen, in denen ich eine Einschränkung des Wertebereichs tatsächlich, zumindest für den Editor, gebrauchen könnte. Bisher ist es beispielsweise nur möglich, Objekte horizontal oder vertikal zu verschieben. Deshalb würde es wenig Sinn machen, die Richtung für das Verschieben auf "oben links" einzuschränken. Ein andere Beispiel wäre, dass eine Höhe und Breite eines Mapobjekts von 0 keinen Sinn macht und zu merkwürdigem Fehlverhalten führt. Aber das sind nur ein paar Beispiele...
Ich muss zugeben, dass ich den Anfang des 2. Absatzes erst gar nicht richtig verstanden habe. Aber ja, in gewisser Weise ist vieles von dem, was ich hier schreibe, ein lautes denken.

@Schorsch:
Ich habe mal wegen des Pluginsystems nachgeschaut, aber es scheint mir so, als wären Im- und Exporter das einzige, was man damit machen kann. Als einzige Hoffnung bleibt mir, dass die Kommandos mich bei der Arbeit unterstützen, allerdings muss ich da erst etwas finden, was diese genauer beschreibt (was sie sind, was sie machen können und wie man sie anlegt).

Ich habe es mit 7zip gepackt. Da ich anfangs noch versucht habe, es unter die 1 MB zu bringen, kann es sein, dass ich noch ein Kompressionsverfahren (vermutlich LZMA) verwendet habe, welches dein verwendetes Programm nicht unterstützt. Ich werde nachher nochmal ein neues Archiv erstellen und hochladen.
Nebenbei bemerkt: 1 MB scheint im Zusammenhang der Anhänge 1.000.000 Byte zu bedeuten. =/

Aber bevor du es dann später nochmal probierst: das Spiel wurde bisher nur "für Windows" entwickelt und nur dort getestet. Gibt es denn das .Net Framework und XNA für Mac bzw. wüsstest du bereits jetzt, wie du eine entsprechende Anwendung ausführen kannst? Wenn nicht, dann dürftest du am Mac mit dem Spiel nichts anfangen können. Wenn doch, dann kann es evtl. sein, dass du dir IronPython für dein System besorgen müsstest. Theoretischerweise dürfte die beigelegte Version auch unter Mono und somit auf anderen Plattformen laufen, versprechen kann ich es nicht...

Ich denke mal, dass die Bezeichnung "Portierung" nicht ganz richtig ist, aber es gäbe da ANX, MonoXNA und MonoGame. Auf Dauer werde ich vermutlich Mono und eins der 3 verwenden, allerdings ist das, genauso wie eine Steuerung per Gamepad o. ä., weniger relevant und deshalb werde ich mich erst in etwas fernerer Zukunft darum kümmern.
Das Spiel ist also nur bisher auf Windows ausgelegt.