Mathesis Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
==== Erste Ziele ====
Zunächst haben wir uns Gedanken über die Schwerpunkte unseres Projektes gemacht. Dazu kamen wir auf folgende Bereiche:

  * **Spezien**: Die Spezien sind der Kern unserer Evolution und benötigen unbedingt sinnvolle Attribute und Funktionen. Wir werden sie als Klasse realisieren.
  * **Umfeld**: Eine Spezies ohne Aufgabe entwickelt sich nicht. Aus diesem Grund muss in die zu bewältigende Aufgabe bzw. in das Umfeld, in dem sich die Spezies aufhält, genauso viel Gedanken hinein gesteckt werden. Nur eine sinnvolle Aufgabe gibt interessante Ergebnisse.
  * **Vererbung**: Vererbung bedeutet, dass unsere Spezien nicht nur lebendig sind, sondern auch nutzbare Informationen beeinhalten, die einer weiteren Generation übergeben werden können. Dabei ist Mutation für Veränderungen ebenfalls wichtig, was alles in allem eine genaue Überlegung benötigt. Schlussendlich braucht man kluge Faktoren für eine Selektion, um die für uns Besten herauszusuchen. Hier bietet sich etwas wie ein Ranking an.
  * **Visualisierung**: Für ein zufriedenes, anschauliches Ergebnis ist es wichtig, die jeweiligen Generationen zu visualisieren, um deren Fortschritt bewundern zu können. Eng dazu angeschlossen sind die Spezien, wo bereits bei deren Attribut-Überlegung ein Nutzen für Visualität da sein muss.

Eine erste Überlegung befindet sich auf unserem [[ws1718:evolutionssimulator:Konzept|Konzeptblatt]].

==== Zeitplan/Zwischenziele ====

Gemiensam mit unserem Konzeptblatt erstellten wir auch einen Zeitplan. 
Um ehrlich zu sein umfasste dieser nicht viel. Und mit nicht viel meinen wir konkret nur zwei Daten. 
Wir hatten uns vorgenommen am **25.01.2018** mit dem Hauptcode CreatureR fertig zu sein und am **15.02.2018** mit der Visualisierung.
Schnell merkten wir , dass der Visualisierungscode notwendig zum Weiterkommen mit dem Hauptcode wurde. Weshalb wir eigentlich diesen Zeitplan überhaupt nicht mehr beachteten und permanent parallel an beiden Codes arbeiteten. 

Vielmehr setzten wir uns dann wöchentliche Ziele, die wir abarbeiteten. Die wichtigsten Punkte sind dabei folgende gewesen: 
  * Anfang des Hauptcodes CreatureR: Klasse für die Entstehung der Kreaturen, deren Fortbewegung und deren Bewertung
  * Anfänge mit pygame -> Umfeld erschaffen 
  * Vererbung durch Selektierung
  * Neustrukturierung des Hauptcodes Creature und Anpassung an den Visualiserungscode pygame
  * Design 
  * mehrere Kreaturen gleichzeitig visualisieren und vererben lassen 
  * unterschiedliche Spezien erzeugen und Visualisieren



=====Das ist Doof(Pygame)=====
PyGame bot uns im Gegensatz zu Turtle wesentlich umfangreichere Visualisierungsmöglichkeiten für unser Projekt. Einer der wichtigsten Vorteile dieses Pakets war dabei, dass wir damit in der Lage dazu waren, mehrere Kreaturen gleichzeitig auf dem Bildschirm erscheinen zu lassen. Mit Turtle konnte man Maximal eine Kreatur beobachten und so zwar den Hauptcode verbessern, aber nicht das volle Ausmaß dessen graphisch darstellen. 
Wie der Name schon sagt ist PyGame an sich für Videospiee mit Python entwickelt worden und ist leider entsprechend nicht besonders gut dokumentiert. Die beste Dokumentation, die wir gefunden hatten waren die Tutorials von KidsCanCode auf YouTube.\\
Das grundsätzliche Konzept eines jeden Spiels also auch eines Spiels, das man mit Pyhtn programmiert ist die sogenannte Game Loop. Diese sorgt dafür, dass das Spiel angezeigt wird und sich je nach bestimmten Inputs etwas auf dem Bildschirm verändert. \\
Auf dem Folgenden Bild erkennt man die Bestandteile eines Game Loops, in die der Sceleton eines PyGame Projekts auch im Groben unterteilt.\newline

Der Processing Input ist alles, was extern vom Code selbst eingegeben wird. Dazu gehören z.B. Interaktionen mit der Maus oder den Tasten auf dem Keyboard. Auch so etwas wie ein „x“ am oberen Fensterrrand zum Schließen des Programms muss in diesen Bereich des Codes eingebaut werden.\\
In der Update Section werden in jedem Frame die neuen Daten verarbeitet, die sich seit dem letzten Frame verändert haben, in unserem Fall also jegliche Fortbewegungne er Kreaturen.\newline

Die Render Section kann man auch als rawing section bezeichen Sie lässt die daten, die beim Updaten sih verändert haben auf dem Bildschirm ausgeben. \newline

Die Uhr am ende der gameloop soll symbolisieren, dass die Game loop sich in jedem Frame wiederholt und so eine Game Loop sich innerhalb von einer Sekunde z.B. 24 mal ( 24 fps = Anzahl an Frames für ein bewegtes Bild) oder auch 60 Mal (Frame rate moderner videospiele) wiederholen kann. Je nach dem wie gut der Prozessor des zum Ausführen verwendeten endgerätes ist, kann das Programm dann auch bei einer zu hohen Frame-Rate ruckeln oder hängen. \newline

Nach dieser etwas längeren Einführung nun zum eigentlichen Code. \newline

====PyGame Sceleton====
Die Notwendigen Bestandteile eines PyGame Codes haben wir so gut wie eins zu eins aus dem „Sceleton Code“ von Kids Can Code (Github link) übernommen. Da dieser für jedes PyGame Projekt so gut wie gleich ist, werden wir ihn an dieser stelle nicht näher erklären, sondern auf das zugehörige Tutorial verweisen. \\

Nun aber wirklich zu **unserem** Code:
Mathesis Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Seiten-Werkzeuge
