Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

--- ws1617:2d-jump_n_run [2017/04/01 14:12]
k.sacha
+++ ws1617:2d-jump_n_run [2017/04/17 20:05] (aktuell)
arik
@@ Zeile 1: / Zeile 1: @@
+====== Verbesserungsvorschläge [17.April] ======
+  * Ausblick hinzufügen, was kann noch gemacht werden, was muss verbessert werden?
+  * Da es essentiell ist für euer Projekt würde ich an eurer Stelle noch irgendwo einen Link zu pygame hinzufügen
+  *  Für Leute die noch  nichts mit Spieleprogrammierung zu tun hatten/haben, wäre ein Diagramm wie die verschiedenen Module miteinander kommunizieren Gold wert.
+  * Man könnte noch in einem Abschnitt auf die "Physikengine" eingehen, was wurde wie realisiert ( Schwerkraft, Ballistischer Wurf, etc.). Gerne auch mit Formeln.
 __**Das Jump'n'Run-Projekt**__
@@ Zeile 160: / Zeile 174: @@
 Zuerst wollten wir das Problem lösen, indem wir zu den Platformen, Wände als weitere Klasse hinzugen.
 Die Platformen sollten den Spieler weder von oben noch von unten durchlassen und die Wände sollten von rechts und links nicht zu durchdringen sein.
-Das hat das Problem aber nicht richtig gelöst. Es führte bloß zu neuen Problemen und hat die Kollisionsabfragen in der main.py unnötig verkompliziert.
+Das hat das Problem aber nicht richtig gelöst. Es führte bloß zu neuen Problemen und hat die Kollisionsabfragen in der main.py unnötig verkompliziert. Natürlich haben wir eine Lösung für dieses Problem gefunden.
-Zu diesem Zeitpunkt haben wir auch eiine levels.py erstellt, welche die Parameter aller Objekt-Instanzen der verschiedenen Klassen beinhalten sollte.
-Die levels.py war dafür da den Überblick in der main.py nicht zu verlieren und um die größerwerdende Anzahl verschiedener Objektinstanzen einfach und logisch sortieren zu können.
-Das Erstellen dieser Datei wird von einem Level-editor übernommen, den Tobias in C# geschrieben hat. (Der mit jeder neuen Sprite-Klasse immer komplizierter wurde.)
-Wenn Du dir die level.py anschaust, wirst du sehen, weshalb wir das nicht von hand gemacht haben.
-(Und wir haben gerade einmal 3 Levels)
-Für das Problem mit der Kollisionsinteraktionen zwischen Spieler und Platform haben wir natürlich eine Lösung gefunden.
 Beim Programmieren gibt es immer eine Lösung zu einem Problem. Was wir uns vorstellen können, können wir auch programmieren. Wir haben einfach den Wald for lauter Bäumen nicht gesehen.
-Nach einigen Rumgeteste, haben wir etwas erhalten was die Wall-Klasse überflüssig machte und den code wesentlich vereinfachte.
+Nach einigem Rumgeteste, haben wir etwas erhalten was die Wall-Klasse überflüssig machte und den code wesentlich vereinfachte.
 <code>
@@ Zeile 205: / Zeile 212: @@
             self.player.vel.y = 0
 </code>
+Zu diesem Zeitpunkt haben wir auch eine levels.py erstellt, welche die Parameter aller Objekt-Instanzen der verschiedenen Klassen beinhalten sollte.
+Die levels.py war dafür da den Überblick in der main.py nicht zu verlieren und um die größerwerdende Anzahl verschiedener Objektinstanzen einfach und logisch sortieren zu können.
+Das Erstellen dieser Datei wird von einem Level-editor übernommen, den Tobias in C# geschrieben hat. (Der mit jeder neuen Sprite-Klasse immer komplizierter wurde.)
+Wenn Du dir die level.py anschaust, wirst du sehen, weshalb wir das nicht von hand gemacht haben.
+(Und wir haben gerade einmal 3 Levels)
+levels.py http://i.imgur.com/CN1k43P.png
+__** Der MathesisJump!LevelEditor **__
+Der Level-Editor ist ein zusätzliches Tool, um Levels in Form einer Levels.py-Datei auf einer graphischen Oberfläche zu generieren. Ich habe den Level-Editor inder Programmiersprache C# geschrieben, da ich mit dieser schon einige Jahre Erfahrung habe. Außerdem ist die von Microsoft gestellte Oberfläche zum erstellen von UIs sehr leicht zu bedienen, so dass auch kompliziertere Elemente leicht zu implementieren sind, wie zum Beispiel der Drag-and-Drop-Vorgang von UI-Elementen.
+Wir hatten sehr früh in unserem Projekt festgestellt, dass das Erstellen von Levels schnell sehr unübersichtlich wird, da Python keine Oberfläche bietet, auf der man leicht verschiedene Elemente (zum Beispiel Rechtecke) in einem Fenster anordnen kann, und diesen verschiedene Eigenschaften zuweisen.
+Die ersten Versionen des Level-Editors waren noch recht umständlich zu bedienen, beispielweise waren ursprünglich Platformen nicht nachträglich bewegbar, oder der "Undo"-Button konnte nur eine Aktion rückgängig machen. Andernfalls hätte man alle vorigen Level komplett neu erstellen müssen. (Eine "Zwischenspeichern"-Funktion gibt es übrigens zur Zeit immer noch nicht.) Nach und nach hat auch das Hauptprojekt Gestalt angenommen, so wurden Gegner intelligenter und haben begonnen ihrerseits mit ~Projektilen~ Schneebällen um sich zu werfen. All diese Features durften im Level-Editor natürlich nicht fehlen, zwischendurch wurde eine Option eingefügt, mit der ein Hintergrundbild angezeigt werden kann, damit man im Vorfeld ein Level planen kann (zum Beispiel in GIMP) und dann im Level-Editor nur noch die Rechtecke an die Richtigen Positionen ziehen muss.
+Wie bediene ich den Level-Editor?
+Wenn das Programm gestartet wird, öffnet sich das Haupt-Fenster. Hier sieht man eine schwarze Oberfläche mit einem grauen Raster darauf, und eine Titelleiste, in der sich eine Farb- und Hotkey-Legende befindet, sowie Buttons zum Importieren eines Hintergrundbildes, Rückgängigmachen des letzen Arbeitsschritts, Speichern, Exportieren und Schließen des Fensters. Wenn sich der Cursor über der Arbeitsfläche befindet und einer der Hotkeys (Q, W, .., Z) gedrückt wird, öffnet sich ein Dialog zum erstellen des jeweiligen Objekts. In diesem "New-Object-Dialog" kann die Position, an dem das Objekt erstellt wird eingesehen werden und Eigenschaften, wie etwa der Größe des Objekts verändert werden. Für unterschiedliche Objekte werden unterschiedliche Buttons ausgeblendet, schließlich besitzt beispielsweise eine Plattform keine Eigenschaft, die bestimmt, in welche Richtung sie wirft, eine Plattform kann keine Projektile werfen.
+Wenn man auf "Create" klickt, wird das Objekt im Hauptfenster auf der Arbeitsfläche angezeigt. Wenn man mit der Position unzufrieden ist, kann es noch an die richtige Stelle verschoben werden.
+Sobald man ein Level vollendet hat, kann man auf "Save as Level##" klicken, wobei statt ## die Nummer des Levels angezeigt wird. Dann wird dieses im Arbeitsspeicher gesichert, und man kann mit dem nächsten Level fortfahren. Wenn alle Level erstellt wurden, klickt man zunächst noch einmal auf "Save as Level##", um auch das letzte Level zu speichern, dann drückt man auf "Export", um eine levels.py-Datei exportieren zu lassen. Diese enthält alle erstellten Level.
+Wie funktioniert der Level-Editor?
+Ich werde diese Sektion eher kurz halten, und nur die Grundkonzepte erklären.
+Zuerst vorneweg: Der Level-Editor selbst kann kein Python, ich habe ihm nicht "das Programmieren beigebracht".
+Alles was der Level-Editor tut, ist nach einem bestimmten Schema die Position von UI-Elementen zu ermitteln, eine Transformation der Koordinaten (von "Thickness-Objekten" zu X-Y-Koordinaten, mit dem Ursprung oben-links) zu konvertiren. Dies erreiche ich, indem ich je Objekt-Typ eine Liste für je das Rechteck in der Nutzeroberfläche, und für jede zusätzliche Eigenschaft je eine Liste führe. Beim Drücken auf den "Speichern"-Button wird für jedes Objekt die passenden Eingenschaften dazusortiert, und in einem langen String (einer je Objekt-Typ) abgelegt. Der Export-Button verknüpft diese Strings und schreibt diese zusammen mit einigen konstanten Zeichenketten (zum Beispiel dem Datei-Header) in die Datei levels.py an einen vom Benutzer gewählten Ort auf der Festplatte (oder Speichermedium).
+__**Weiterer Projektverlauf**__
 Zu jedem einfachen Jump 'n' Run gehören natürlich auch Gegner und Stacheln, die den Spieler in einen alternativen Zustand des Lebens versetzen können.
@@ Zeile 219: / Zeile 260: @@
 Das hinzufügen von Hintergrundbildern und nicht animierten Charakteren war relativ einfach.
-Aber die Reihenfolge in der die Objekte auf den Bildschirm gemalt werden war noch nicht korrekt, denn selbst, wenn man für eine bestimmte Sprite-Klasse kein Bild spezifitiert, wir es dennoch als schwarzes Viereck angezeigt.
+Aber die Reihenfolge in der die Objekte auf den Bildschirm gemalt werden war noch nicht korrekt, denn selbst, wenn man für eine bestimmte Sprite-Klasse kein Bild spezifitiert, wir es dennoch als schwarzes Viereck angezeigt. Deshalb müssen alle Platformen zuerst gemalt werden, diese werden dann vom importierten Hintergrundbild übermalt und erst dann wird der Spieler, die Gegner und die Schneebälle gezeichnet.
 <code>
@@ Zeile 244: / Zeile 285: @@
 </code>
-Zum Schluss haben wir uns an Sprite-Animationen gewagt, was aber nach hinten losging. Du(Leser) kannst ruhig die main.py aus dem Ordner mit der Beschriftung "1.0.8 unstable" ausführen und unser Ergebnis sehen.(Er hat nicht ohne Grund "unstable" im Namen.)
+Aber aus irgendeinem Grund wurden die Objekte auf dem Screen nicht gelöscht, wenn man in ein neues Level eintritt.
 Die Gruppenarbeit hat uns sehr viel Spaß gemacht und uns sehr viel über die Programmiersprache "Python" und das Programmieren im Allgemeinen beigebracht (zumindest zwei von uns). Wir sind nicht so weit gekommen, wie wir gewollt hätten.
@@ Zeile 255: / Zeile 295: @@
 Wir würden es keine Gruppe raten, unser konkretes Projekt weiterzuführen. Pygame ist ein nettes Modul, um bestimmte aufgaben zu vereinfachen, aber zur Spieleentwicklung gibt es weitaus bessere Optionen.
-Eine Game-Engine vereinfacht einem die Arbeit immens und erspart einem eine menge Arbeit.
+Eine Game-Engine vereinfacht einem die Arbeit immens, erspart einem eine menge Arbeit und unnötige Bugs, die man als Programmieranfänger mur sehr schwer lösen kann (Zum Beispiel haben Graphiken, die wir für den Player-Sprite geladen haben, falsch angezeigt und Teile des Bildes sind verschoben. Mit einer .gif-Datei hat es aus irgendeinem Grund funktionert.).
 Wir haben vieles durch die Benutzung von Pygame gelernt, aber würden es niemals wieder für die Entwicklung komplexer Spiele benutzen.(ein einfacher 2D platformer zählt hier bereits zu den komplexeren Spielen für uns).
-Die Game-Engine "Godot" ist eine sehr viel bessere Alternative für reine Spieleentwicklung.
+Die Game-Engine "Godot" ist eine sehr viel bessere Alternative für Spieleentwickler.
 __**Literatur, Videos und verwendete Software**__
@@ Zeile 272: / Zeile 312: @@
 Kilian: Atom(IDE), PyCharm(IDE), Adobe Photoshop CC (Bildbearbeitung)
+Inzwischen hat Kilian von Photoshop zu Krita gewechselt (ein 100% freies Programm).
+"Preiset den heiligen St. IGNUcius, auch bekannt unter dem Namen "Richard Stallman"!"
 Adel: Geany(IDE)
@@ Zeile 277: / Zeile 321: @@
-Eine aktuelle Version (26.01.2017) unseres Projekts haben wir bei Hightail hochgeladen:
+Eine aktuelle Version (06.04.2017) unseres Projekts haben wir bei Hightail hochgeladen:
- * [[https://www.hightail.com/download/cUJYa3NWUnJmVFlsYzhUQw | Das Projekt]]
+ * [[https://spaces.hightail.com/space/aN57d/files/fi-b2b05746-df11-482b-9c59-a1381815dcee/fv-0417e82b-8d46-47d7-959b-80a4d8771b8f/Jump%20'n'%20Run.zip | Das Projekt]]

Mathesis Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge