spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

wie vielleicht dem einen oder anderen aufgefallen sein könnte, habe ich hier schon eine lange, lange Zeit nichts mehr geschrieben (spätestens nach diesem einleitenden Satz dürfte es aufgefallen sein)
im Grunde hat sich nicht wirklich viel getan (auch wenn man mal die fehlende Story außen vor lässt)

ich hatte es schon vor einer ganzen Weile implementieren können, dass man verschiebbare Blöcke verschieben kann
allerdings ist mir erst dann ein Fehler bei der Bewegung und Kollisionsprüfung aufgefallen
wenn 2 Objekte nicht exakt auf gleicher Höhe stehen (was beim Verschieben prinzipiell gegeben ist), aber dennoch fast auf gleicher Höhe sind, dann kann es passieren, dass man durch einen Fehler beim Verschieben nach rechts unten oder links unten auf die jeweilig andere Seite "teleportiert" wird (zumindest meine ich, dass der Fehler sich so bemerkbar gemacht hat)
um diesen Fehler zu beseitigen (und in gewisser Weise auch noch ein anderes Problem), hatte ich die gesamte Bewegung und Kollisionserkennung nochmal neu geschrieben
ein anderer Grund dafür war aber auch, dass die Bewegung nicht unabhängig von der Kollisionserkennung war
es wurde die Bewegung in eine Richtung (hoch, runter, rechts, links) durchgeführt, die Kollisionen (Überlappungen mit der nicht passierbaren Umgebung oder Mapobjekten) geprüft und die Position ggf. anhand der Kollisionen angepasst
das hatte zur Folge, dass bei einer diagonalen Bewegung der Charakter erst vertikal und dann horizontal bewegt wurdfe (oder andersrum), was wiederum zur Folge hatte, dass man in eine Spalte, die eigentlich breit genug für einen sein müsste, nicht hinein laufen konnte (es sei denn, man konnte seine Position mit Hilfe einer Wand ausrichten)
jetzt funktioniert es so, dass erst in einem Schritt die Position aktualisiert wird, dann werden die Kollisionen ermittelt, ausgewertet (ggf. Position angepasst oder das Verschieben eines Objekts begonnen) und noch einmal werden die Kollisionen ermittelt (sollte durch die Anpassung an die vorher geprüften Kollisionen neue aufgetreten sein, steckt man fest, weil man sich durch Bewegung (in die entsprechende Richtung) nicht befreien kann)

ich habe es mittlerweile soweit geschafft, dass es im Groben und Ganzen wie vorher funktioniert
aber was wäre eine Lösung für ein Problem ohne weitere Probleme? ;D
im Moment ist es noch so, dass man dadurch 2 Objekte, die nebeneinander stehen gleichzeitig bewegen kann, aber die Lösung dafür dürfte wohl nicht zu schwer sein
andererseits habe ich nun das Problem, dass die Blöcke nur bis zu einer bestimmten Position nach oben bzw. links geschoben werden können - beim Verschieben nach unten oder rechts gibt es das Problem nicht
dadurch kann es passieren, dass man ein Objekt so weit nach rechts verschiebt, dass man es nicht wieder zurück schieben kann
und natürlich ist es nicht nur eine einzige "Zeile" und "Spalte", nein, es wiederholt sich in scheinbar regelmäßigen abständen

ich weiß nicht, in wie weit ich darüber bereits geschrieben habe (ich bitte euch: wer liest denn schon meine Beiträge? xP), jedenfalls hatte ich ein wenig rumgespielt und kann folgendes sagen
ich muss von Python weg! ='( (zumindest als "Hauptsprache", als Skriptsprache dürfte es gehen)
beispielsweise wird das Spiel wesentlich langsamer, je größer die Map ist (und das nicht, weil viel mehr gezeichnet werden muss), wenn mehr von der Map gezeichnet werden muss (bei gleich großer Map) und die Bewegung frisst mehr Leistung, wenn mehr Mapobjekte vorhanden sind (das liegt natürlich nicht an meinem Code, weil dieser nicht Schuld daran sein kann! und wie wir noch aus einem anderen Thread wissen: ich bin glaubwürdig! es liegt also nicht an meinem Code! ;D)
trotz der oben beschriebenen Probleme werde ich wohl mit der Übersetzung auf C# beginnen

und damit auch für die Allgemeinheit etwas zu sehen ist (ohne das Spiel selbst runterladen zu müssen), habe ich als Anhang ein paar Bilder angehangen, die ich für die Tests mit viel Liebe und Mühe (ein paar Minuten waren das schon... oder so) erstellt habe
sollte tatsächlich jemand von euch wahnwitzigerweise Interesse an der Verwendung haben: nur zu

da ich schon wieder eine viel zu lange Zeit hier nichts mehr geschrieben habe (oder wohl eher, weil ich sonst nichts besseres zu tun habe...), werde ich über den bisherigen Fortschritt beim Umstieg auf C# und .NET berichten:
in letzter Zeit habe ich einiges an Zeit finden können, mich weiter mit dem Umstieg zu beschäftigen
so konnte ich nicht nur sehr viel Python Code in C# Code umwandeln, sondern habe auch schon den ersten Python-Code aus C#-Code heraus ausgeführt, mich mit der notwendigen ContentPipelineExtension beschäftigt und auch herausfinden können, dass ich Rendertargets (bzw. RenderTarget2D) benötigen werde
all das war dann doch nicht wirklich schwierig, auch wenn ich bei den Rendertargets nicht einfach den bisherigen Python-Code übernehmen kann
in Python hatte man Surfaces, die man sich nach belieben erzeugen und dann wild durcheinander verwenden konnte
um ein RenderTarget2D verwenden (bezeichnen) zu können, muss man dem entsprechenden GraphicsDevice erst mitteilen, dass man dieses verwenden möchte
das dürfte allerdings auch nicht zu zu großen Problemen führen, da ich beispielsweise in der einen Draw-Methode die Draw-Methoden der Elemete aufrufen könnte, die sich in ein Rendertarget zeichnen (mit festlegen des Rendertargets beim GraphicsDevice) und danach, nachdem das Rendertarget wieder angepasst wurde, die Rendertargets der Unterelemente zum Zeichnen abrufen

problematisch ist bisher noch, dass ich den meisten Code, den ich geschrieben habe, noch nicht zur Ausführung gebracht habe und damit nicht auszuschließen ist, dass ich irgendwelche Fehler gemacht habe
wobei: wenn man bedenkt, dass ich das gemacht habe, dann sind Fehler doch eigentlich schon von vornherein ausgeschlossen! *hust*
aber natürlich werde ich dem Problem mit Unittests entgegentreten, sobald ich das Klassendesign so angepasst habe, dass es dies zulässt ;D
aber mal Spaß bei Seite: ich hatte tatsächlich bei der Entwicklung des VariablesManager sowas wie Unittests verwendet, allerdings hatte ich den Code dafür entsorgt, als ich ihn "nicht mehr brauchte"... =/ (aber da sich daran ja nichts weiter verändert hat, wird das ja schon alles funktionieren
irgendwann hatte ich mir mal die Überlegung gemacht, dass ich in Python eigentlich sehr wie mit statisch typisierten Sprachen (der Typ eine Variablen ist grundsätzlich bekannt) und daher "nicht richtig" damit arbeite, doch dank der Umstellung auf C# ist mir klar geworden, dass es doch ein wenig mehr war, als ich dachte (es beginnt bei Sachen, wie, dass ich Script-Objekte und Namen von Skripten (Strings) teilweise gleich behandle und der Höhepunkt dürften die "Ingame-Variablen" sein, deren Typisierung ich bisher ignoriert hatte, in C# aber wohl notwendig werden dürfte)
durch die Umstellung habe ich allerdings auch einiges an Code finden können, von dem ich mich fragen musste, warum dieser überhaupt da ist
einige Funktionen wurden beispielsweise von keiner anderen Stelle im Code aufgerufen und konnten einfach ausgelassen werden

und damit ich auch noch mit ein paar Zahlen um mich werfen kann:
bisher habe ich ~ 2000 Zeilen C#-Code für das Spiel und nochmal ~ 500 Zeilen für die bisherige ContentPipelineExtension und es werden noch einige hundert Zeilen dazu kommen
allerdings muss ich auch dazu sagen, dass ich aufgrund meiner Handhabung der Eingaben ein Switch-Block alleine schon ~ 300 Zeilen verbraucht, von dem ich effektiv max. 30 wirklich benötigen würde (würde ich nur die Tasten behandeln, die ich im Spiel derzeit verwende)
und um einen gewissen Vergleich aufzubauen:
das Pythonprojekt hat ~ 3000 Zeilen Code
direkt kann man die beiden Zahlen nicht miteinander vergleichen, da der C# Code aufgrund der Formatierung grundsätzlich ein wenig mehr Platz in Anspruch nimmt (die geschweiften Klammern von Blöcken beanspruchen jeweils 1 Zeile -> 2 zusätzliche Zeilen je Methode, Klasse, Schleife, Bedingung, ...)
und natürlich sagt die Anzahl der Zeilen eigentlich gar nichts aus, aber so hat man zumindest das Gefühl eine Information über sein Spiel gegeben zu haben


womit ich mich im Zusammenhang mit dem Spiel evtl. noch beschäftigen werde sind Dinge, wie die Übersetzung des Python-Codes zur Kompilierzeit (derzeit wird der Code einfach nur unverarbeitet in eine andere Datei verpackt) oder vielleicht auch mit diversen Filtern, wie beispielsweise für die Skalierung (hq3x/hq4x), für Scan Lines o. ä.
allerdings steht jetzt erstmal das zur Anzeige bringen von Spielinhalt im Vordergrund und nicht solche Spielereien...

Hallo,

eigentlich hätte ich noch in der gleichen Woche des letzten Beitrags davon berichten können, dass das Spiel auch unter C# und XNA startet, aber, naja, ich dachte mir "ach komm, bevor du den Thread schon wieder mit einem weiteren Beitrag versiehst, kannst du doch noch ein wenig mehr implementieren!". Allerdings ging es danach nicht mehr ganz so rasch voran. Wie man allerdings an einem anderen Thread schon hätte erkennen können, ist soweit fast alles, was in Python umgesetzt war jetzt auch in C# geschrieben. Und abgesehen von den paar fehlenden Dingen (Fading, transparenter Hintergrund bei Dialogen) gibt es einige Dinge, die in Python noch nicht enthalten waren: verschiebbare Blöcke (mit kontinuierlicher oder blockbasierter Bewegung, Verzögerung und Einschränkung der Richtung, in die geschoben werden kann), buchstabenweise eingeblendeter Text in den Dialogen.
Abgesehen von diesen größtenteils kleinen Erweiterungen habe ich auch schon die ersten Vorzüge der Mechanik mit den Mapobjekten, deren Variablen und Skripten genießen können, die ich mir ersponnen habe. So musste ich nur 2 hübsche Bildchen Malen (eigentlich 4, da 2 Gegenstände mit 2 Zuständen und somit 4 Frames), ein paar Variablen definieren, ein paar Skripte schreiben (alle jeweils kürzer als 10 Zeilen) und schon hatte ich ein Gitter bzw. eine Tür, die ich mit einem Hebel öffnen und schließen konnte.

Das nächste "Minispiel" soll dann die "Rätselkammer" (Ansammlung von verschiedenen Rätseln) sein, welche wohl nicht mehr zu lange auf sich warten lassen und welche von mir somit noch dieses Jahr fertig gestellt werden dürfte. Aber mal Spaß bei Seite...
Ich bin derzeit einerseits ein wenig am Überlegen, wie ich diese Map genau gestalten sollte, also welche Rätsel es geben könnte (die man noch ohne ein echtes Inventar lösen kann), ob es nur eine einzelne Map sein wird und womit ich die Map letztendlich erstellen werde. Aber vielleicht habt ihr ja noch Ideen!

Letzteres leitet zum nächsten Thema über: dem Mapeditor. Ich habe mir vor kurzem erst Tiled angesehen, welchen ich durchaus benutzen könnte. Allerdings finde ich ihn nicht gut genug, als dass er mehr als nur eine Übergangslösung darstellen dürfte, sofern ich ihn intensiver verwenden werde. Entweder ich erstelle über diesen nur die Umgebung an sich und setze die Mapobjekte und deren Skripte später dazu oder ich versuche auch die Mapobjekte damit einzubauen. Das heißt also, dass der Mapeditor dann nur sehr geringfügig an mein Spiel angepasst ist, oder dass ich beim Erstellen stärker aufpassen muss, dass ich im Editor auch die richtigen Angaben mache, damit auf der Map am Ende auch wirklich ein Objekt steht. Zudem dürfte ich zwar Objekte auf der Map platzieren können, diese aber nicht definieren können. Das hat beispielsweise ebenfalls zur Folge, dass ein "Refactoring" (bspw. das Umbenennen eines Mapobjekts) nicht so ohne weiteres möglich ist.
Als Alternative zu Tiled (stellvertretend für vergleichbare Programme) sehe ich nur das Erstellen eines eigenen Editors. Da stellt sich dann wieder die Frage: sollte der Editor vollkommen unabhängig vom Spiel sein (ein gänzlich eigenes Programm), sollte der Editor auf das Spiel zugreifen, um mit diesem den Inhalt des Spiels (die Maps) darzustellen oder sollte der Editor ein Teil des Spiels sein? Alle Punkte haben so ihre Vor- und Nachteile. Im ersten Fall besteht zwar ein etwas höherer Aufwand, damit die WPF/Windows Forms/Swing/Wasauchimmer Anwendung die Map und die Mapobjekte darstellen kann, in den anderen Fällen würde ein gewisser Aufwand für die Anpassung des Spiels bestehen, damit dieses ausreichend flexibel für einen Editor ist. Auch würde ich gerne die Map, die gerade bearbeitet wird _und_ das verwendete Tileset sehen wollen, ohne dass die Darstellung des Einen die des anderen beeinträchtigt (verschiedene Höhen und Breiten). Wenn das Spiel nur in eine andere Anwendung eingebunden wird, wäre das durchaus möglich, nur müsste das Spiel dafür 2x gestartet werden.
Eine Entscheidung meinerseits steht noch aus. Mich würde aber natürlich auch interessieren, was meine überaus an meinem Projekt interessierten Leser für eine Meinung haben.
Für die 2. Variante habe ich bereits XNA WPF Control gefunden, was soweit zu funktionieren scheint.
Als Hinweis zum Mapeditor sei erwähnt: ich orientiere mich dabei sehr an den RPG-Makern, da diese im Grunde eine vergleichbare Funktionalität bereitstellen.


Und als letzten Punkt möchte ich noch nennen, dass ich hoffentlich bald auch eine Story haben werde (für den 3-Dungeons langen Action Adventure). Wie man an der Stelle schon vermuten könnte, werde ich diese nicht selbst schreiben. Da die Person, die sich dafür angeboten hat, allerdings derzeit viel zu tun hat, kann das noch einige Zeit dauern... =/


Mal schauen, wann ich mit der nächsten spielbaren Version fertig sein werde, allerdings wird diese ja dann auch von nicht-Python-Besitzern spielbar sein.

Sacaldur

Zitat von »Schrompf«

Wenn Du schon bei einer Rätselkammer mit Entwicklung bis Ende des Jahres rechnest, solltest Du evtl. kein so großes Projekt angehen.

Da war meine Aussage wohl nicht ganz so eindeutig zu verstehen. Es sollte eher scherzhaft gemeint sein. Ich wollte also nicht sagen, dass ich plane, es erst Ende des Jahres fertig zu haben. (Wenn ich mich ausreichend damit beschäftige, werde ich es wahrscheinlich schon nächste Woche fertig haben.)
Ein Problem ist, dass ich (wie auch einige andere hier im Forum) arbeiten gehe und nach Feierabend nicht immer die Motivation habe, noch ein paar weitere Stunden zu arbeiten. Weiterhin gehe ich noch zu einigen Veranstaltungen (letztes WE der Mobile Game Hackathon), die teilweise viel Zeit in Anspruch nehmen, die ich dann nicht in die Entwicklung des Spiels stecken kann. Ich muss aber auch zugeben, dass ich mir teilweise zu wenig Zeit für das Weiterentwickeln des Projekts nehme, weshalb es eben bisher häufig so langsam voran kam.
Auch wenn es durchaus vernünftig ist, sich ein kleineres Projekt vorzunehmen, würde ich einerseits nicht sagen, dass ich dadurch eher zu einem Ergebnis (fertiges Spiel) komme (die Selbstdisziplin wird auch bei einem kleineren Projekt nicht automatisch besser), andererseits bin ich zu sehr darin bestrebt, genau _diese_ Spiel umzusetzen, als dass ich es einfach pausieren und etwas anderes anfangen könnte.

Allerdings ist es auch nicht gerade so, als hätte ich nie ein anderes Spiel umgesetzt. Beim Global Game Jam habe ich mit 2 anderen zusammen Trevor the Tortoise umgesetzt, letztes Wochenende habe ich an "Purple Party Panda" mitgearbeitet und auf den monatlichen Jams grundsätzlich immer ein anderes Spiel (allerdings nicht immer Computerspiele).


Ich lese aus deinem Beitrag heraus, dass du mir in der Hinsicht zustimmst, dass ein eigener Editor auf Dauer besser ist. Die Frage wäre dann also, wann dieser angegangen wird (unter der Annahme, dass ich an dem Projekt weiterarbeiten werde) und bis dahin würde dann Tiled (mit einem entsprechenden Plugin für den Output) als Übergangslösung dienen.
Aber ja, Undo und Redo dürfte wirklich nicht unbedingt einfach umzusetzen sein und es könnte auch noch die einen oder anderen Probleme geben, die auf mich zukommen werden. Für mich wäre es aber nicht das vorrangige Ziel, dass das Spiel letztendlich auch im Editor selbst gestartet werden kann, was ich aber nicht gänzlich ausschließen will.

Ich bin mir nicht sicher, was du mit "Entity-Property-System" meinst, allerdings müsste ich da spontan am ehesten an die Variablen der Mapobjekte denken (im Spiel bereits umgesetzt).

@Schrompf:
Ja, vielleicht habe ich deinen Beitrag wirklich ein wenig anders verstanden, als er gemeint war. Und was aus meinem Beitrag vielleicht nicht gant eindeutig hervor ging: das Haupthindernis ist nicht unbedingt, dass ich mir nicht viel Zeit nehmen kann, sondern in gewissem Maße eher, dass ich mir nicht viel Zeit nehme. So zum Beispiel habe ich (abgesehen von Eltern, Großeltern und Geschwistern) keine Familie, die viel Zeit in Anspruch nimmt. Das hängt mit der bereits erwähnten Selbstdisziplin (oder dem "am Ball bleiben" zusammen). Während der Umstellung von Python auf C# habe ich beispielsweise ein paar Tage hintereinander quasi ausschließlich mit dem Spiel verbracht (da dies in meiner Urlaubszeit lag). Ich denke, dass das auch damit zusammenhängt, dass die Aufgabe zwar aufwändig, aber nicht komplex war (Python-Code anschauen, C#-Code einhacken).
Ich denke mal, dass ich den eigenen Editor nicht für die bevorstehende Rätselkammer erstellen werde, da dies nur 1 Map sein dürfte und ich die bestimmt auch noch auf andere Art erstellen kann... (Tiled oder notfalls wie bisher per Texteditor)

Bisher hatte ich die möglichen Werte der Variablen nicht weiter eingeschränkt, als durch den zugewiesenen Typ. So gibt es bisher noch keine Einschränkung für Zahlen, dass sie nicht negativ, größer 1, kleiner 100 oder in 10er Schritten sein müssen. Ich bin mir aber nicht sicher, in wie weit ich das benötigen werde. Eine Außnahme ist dabei aber die Angabe von Richtungen, da es dafür einen eigenen Typ gibt, wodurch nur die 8 Richtungen möglich sind. (Wo ich gerade bei Typen bin: wäre es sinnvoll, Listen als Typen für die Variablen einzuführen? Bisher scheint es mir jedenfalls so)
Neben den Variablen der Mapobjekte hätte ich in meinem Fall aber auch noch die Skripte der Maps und Mapobjekte, die Zuweisungen der Skripte, die Variablen der Maps, die "Charsets" (der Name wird auch im RPG-Maker so verwendet, in meinem Fall die Grafiken für die Mapobjekte) und deren Metainformationen sowie die animierten Teile der Tilesets, die ich in Tiled nicht berücksichtigen kann.


@Schorsch:
Ich habe mich bisher nicht intensiver mit dem Pluginsystem beschäftigt, sondern erstmal nur geschaut, wie man sich einen Exporter schreiben kann (da dieser explizit erwähnt wurde). Allerdings werde ich auch noch schauen, was man weiterhin anpassen kann. So habe ich beispielsweise bereits gesehen, dass man sich Kommandos erstellen kann, allerdings bisher noch keinen weiteren Blick darauf geworfen, was man damit anstellen kann.
WPF wäre für mich glücklicherweise nichts neues. Während meiner Ausbildung hatten wir ein Seminar zur Entwicklung mit WPF, im Anschluss ein Projekt für den Microsoft Pixelsense (ehemals Microsoft Surface) und ich kurz vor Ende der Ausbildung nochmal ein weiteres Projekt, welches dann auch auf der CeBit 2011 zu sehen war.
Und selbst wenn ich keine Erfahrung damit hätte: ich hatte mir die XNA Integration bereits ein wenig genauer angesehen, um zu verstehen, wie diese zu verwenden ist und es wird dort offenbar ein Windows Forms Panel verwendet, auf welches mittels XNA gezeichnet wird und welches selbst in WPF eingebunden wird. Es wäre also auch möglich, mit Windows Forms einen Editor zu schreiben, aber da ich bereits mit WPF gearbeitet habe, habe ich nicht unbedingt die Neigung dazu, dies zu tun...


@Saik0:
Bisher habe ich in meinem Fall die ganzen Klassen, die ich für das Spiel anlegen musste. Diese könnte ich dann also teilweise auch in dem Editor verwenden, wofür ich diese allerdings großteils wohl an diese neue Verwendungsart anpassen müsste. So müsste ich wohl die für Ressourcenmanager ein Interface und eine weitere Implementierung erzeugen, damit die Skripte beim Editieren des Spiels nicht aus dem Dateisystem per Contenpipeline sondern aus dem Editor geladen werden. (Was das angeht stelle ich mir das Erzeugen von Texture2D Objekten als nicht sehr amüsant vor, aber mal schauen...)


Es gibt so einige Features, die ich mir für eine spätere Variante des Editor vorstelle, die das Arbetien wesentlich erleichtern können. So zum Beispiel dass festgehalten wird, welche Skripte, Sound oder andere Ressourcen tatsächlich zur Ausführung kommen bzw. zur Laufzeit des Spiels geladen werden, eine Vorschau auf die Geräuschkulisse des Spiels (um die Lautstärken aneinander anzugleichen), einen Debugger für Skripte und noch viele weitere Spielereien. Aber das alles liegt noch in sehr weiter Zukunft und soll deshalb nur eine kleine Randbemerkung darstellen...