Seminar S3: Simulationen

Transkript

1 Seminar S3: Simulationen Simulationen mit Schwerpunkt auf E-Felder und Gravitation war für das Seminarprojekt der S3 unser Thema. Das heißt, dass ein reales System so weit vereinfacht werden soll, dass es durch eine einfache Simulation dargestellt werden kann. Da der Begriff Simulationen für uns noch ziemlich komplex und undeutlich erschien, haben wir uns erstmal darüber informiert was es mit diesem Begriff auf sich hat. Am Ende hatten wir diese Defintion für uns aufgestellt: Simulationen sind Softwareanwendungen/Computerprogramme, welche ein Phänomen der realen Welt nachbilden. Je genauer die Simulationen, desto mehr verraten sie über die reale Welt. Diese Simulationen werden zum Beispiel für Wettervorhersage, Verkehrsplanung und physikalischen Forschungen genutzt. Im Code und beim Implementieren sollte man kurze Methoden verwenden, die nur eine Aufgabe machen (--> führt zur besseren Codequalität). Simulationen weisen oft ein emergentes Verhalten auf. Dieses Verhalten ist nicht in den einzelnen Akteuren programmiert, sondern ergibt sich automatisch als Summe der Verhaltensweisen von allen. Wir haben uns geeinigt sich auf Gravitation zu konzentrieren, da uns das Thema mehr anspricht und wir damit mehr anfangen können als mit E-Feldern. Dabei sind wir auch bis zum Ende geblieben. Das war bei der Projektidee nicht immer so. Für uns war schon von Anfang an klar, dass wir ein Spiel und eine Simulation vereinen möchten. Bei Greenfoot bietet sich das wunderbar an und so können wir die Simulation auch schöner und kreativer gestalten. Unsere erste Projektidee war: Wir stellen das Sonnensystem dar. Dabei wollten wir das Sonnensystem auf Sonne, Erde und Mond vereinfachen und die Planetenbahnen von diesen Planeten simulieren (Geschwindigkeit, Umlaufbahn, Größe etc.). So haben wir uns das ganze ungefähr vorgestellt: Unsere zweiter Projektidee: Wir programmieren ein Multiplayergame, bei dem sich 2 Spieler mithilfe von Raketen ausschalten sollen. Die Physik hinter dem Spiel soll im Abschusswinkel liegen. Die Flugbahn eines Objekts (Rakete), dass aus einem bestimmten Winkel abgeschossen wird, soll simuliert werden. Dabei soll die Reibungskraft unberücksichtigt bleiben. So könnte das später aussehen aber in abgespeckter Version:

2 Wir haben uns schließlich dazu entschieden unsere 2. Projektidee zu verwirklichen, da uns die Vorstellung von Flugbahnen von Objekten mehr anspricht als Planetenumlaufbahnen. Projekt 1 wollen vielleicht auch andere Gruppen aus der Klasse nehmen und wir wollen was individuelles und einzigartiges machen. Außerdem haben wir schon eine Idee, wie man das mit einem Spiel verknüpfen könnte. (--> Eve und Wall-E) Mit der Zeit haben wir gemerkt, dass unsere alte Projektvorstellung zu schwer ist und zu viel Zeit beansprucht. Da die Seminarstunden meistens auch ausfallen und allgemein einoder zweimal in diesem Jahr Seminar ausfällt, haben wir zu wenig Zeit um uns mit so einem umfangreichen Thema zu befassen und es weiter auszubauen. So haben wir ein neues Projektthema entwickelt. Bei dieser Idee soll der Ball gegen eine Rampe fallen und von dort abprallen und dann in ein Tor fliegen, welches sich bewegt. Die Position, an welcher der Ball fallen soll, soll der Spieler selbst auswählen können. Der Physikalische Teil soll hier die Simulationen der Abwurfstelle des Balles und die anschließende Flugbahn, nachdem der Ball von der Rampe abgeprallt ist, sein. Das Spiel werden wir noch durch weitere Levels vervollständigen falls wir noch Zeit haben. Eine grobe Skizze: Das Projekt im Detail: Die wesentlich Elemente unseres Spiels sind: Das Tor, der Ball, der Boden und die Hindernisse. Das Tor soll sich vertikal hoch und runter bewegen. Dadurch wird der Schwierigkeitsgrad erhöht. Die Geschwindigkeit beim vertikalen bewegen bleibt dabei konstant und eine Beschleunigung des Tors findet nicht statt, damit man direkt im Spiel ist.

3 Für die Klasse Ball haben wir eine Rakete benutzt um die Veränderung der Rotation mitzubekommen. Die Rotation und ihre Veränderung während des Spiels kann man nicht gut erkennen. Beim Beenden des Projekt werden wir die Rakete durch einen Ball ersetzen. Bälle können durch einen Mausklick erzeugt werden und es können so immer weiter eine die Spielewelt eingefügt werden. Der Ball bewegt sich tatsächlich wie ein richtiger Ball auf dem die Gravitation der Erde wirkt. Beim freien Fall ist er Anfangs langsam und mit der Zeit beschleunigt er, wie es im Geschwindigkeit-Zeit-Gesetz die Rede ist. Die Geschwindigkeit ist proportional zur Zeit. Wenn der Ball auf normalen geraden Boden aufprallt, erleidet einen selbstfestgesetzten Energieverlust von 20%. Dieser Energieverlust soll aus dem Geschwindigkeitsverlust bei den Abprall und der Reibung bestehen. In der Theorie: Beim Abprall wird die kinetische Energie in Wärmeenergie und Reibungsenergie umgewandelt. Das heißt der Ball springt jetzt nur noch 80% der Höhe, aus der er gefallen ist. Wenn der Ball gegen eine Rampe, also gegen ein Hinderniss welches schräg steht, gilt Wenn der Ball also vertikal (90 Grad) auf die Rampe, die einen Winkel von 45 grad zum Boden hat, dann prallt er von der Rampe mit einem Winkel von 45 Grad wieder ab. Dieser

4 Winkel beschreibt dann die Flugbahn des Balls. Genau so ist es bei den anderen Hindernissen. Man muss den Ball zum perfekten Zeitpunkt und in der perfekten Position loslassen, damit er auch genau so abprallt wie man möchte, wenn man das bewegliche Tor treffen will. Beim erstellen des Spiels sind wir systematisch und chronologisch vorgegangen: (Natürlich zählt zu diesen Schritten auch das tägliche Dokumentieren und festhalten von Arbeitsergebnissen dazu) 1. Hintergrund/ Spielwelt schaffen 2. UML-Diagramm erstellen für eine grobe Vorstellung, wie die Klassen aussehen sollen 3. Objekten bzw. Klassen ihre einzelnen Eigenschaften zuweisen 4. Spiel testen 1. Wenn was nicht funktioniert--> korrigieren und verbessern--> Schritt 4 wiederholen 5. Projekt zusammenfügen 6. Dokumentation vervollständigen 7. Beenden Mit dieser Vorgehensweise haben wir während des ganzen Projekts gearbeitet und haben gehofft das wir etwas Brauchbares und Gutes abgeben können. UML-Diagramm Da wir ungern unsere alte Projekt Idee, in die wir bereits viel Arbeit gesteckt hatten, links liegen lassen wollten hab wir das Spiel mit der Rakete nochmal aufgegriffen und ein wenig bearbeitet. Es zwar nicht das geworden was wir uns anfangs vorgestellt haben, da es

5 jedoch auch nur eine verkürzte Version ist, in die wir nicht so viel Zeit investieren konnten, ist das Ergebnis trotzdem sehr zufrieden stellend. Das Spiel ist nun wie folgt aufgebaut: Es stehen sich zwei Charaktere gegenüber, einmal Eve und einmal Wall-E. Eve kann eine Rakete erzeugen, wenn man Enter drückt. Sobald die Rakete erzeugt ist, kann der Abschusswinkel mittels der Pfeiltasten (Oben, Unten) eingestellt werden. Drückt man Space wird die Rakete abgefeuert, sie fliegt in einer Flugkurve auf Wall-E zu und falls sie ihn trifft entsteht eine Explosion und Wall-E verschwindet. UML-Diagramm Unsere Probleme während des Seminars: Während des Projekts hatten wir ein Zeitproblem. Die Seminarstunden sind öfters ausgefallen, weil das Vorabi bevorstand und wir uns deswegen mehr auf Informatik konzentriert hatten.

6 Außerdem waren wir noch zu dritt in der Gruppe. Als wir anfingen haben wir bemerkt, dass es ziemlich schwer ist ein Spiel bzw. eine Simulation zu dritt zu erstellen. Wir haben uns deswegen die einzelnen Aufgaben immer aufgeteilt. Aber es war immer noch ein Hinderniss, da wir die ganzen Sachen die wir einzeln gemacht haben immer in eine Art "Hauptprogramm" zusammenführen mussten. Aus diesen beiden Probleme hat sich halt ergeben, dass wir öfters mal das Projekt gewechselt hatten, weil die Projekte entweder zeitlich nicht hinkamen oder einem von uns das Projekt nicht gefiel. Dazu kamen noch die Probleme, die wir bei der Implementierung hatten, also beim Schreiben von Funktionen und Klassen, hatten. Den Ball zu implementieren war sehr schwer und wir sind da häufig auf Probleme gestoßen. Ein Beispiel für solche Probleme: Die Rampe wurde als viereckiges Objekt vom Programm anerkannt, weil das Bild zwar extrahiert wurde aber immernoch viereckig war. Die Lösung: Die Rotation der Rampe/Bild musste so verändert werden, sodass sie 45 Grad zum Boden stand. Selbstreflexion: Das Seminar hat uns allen, trotz aller Probleme, sehr Spaß gemacht. Das Thema war eine echte Herausforderung aber hatte einen gewissen Reiß, der uns vorangetrieben hat. Auch wenn wir oft an unserer Verzweiflungsgrenze waren, konnten wir am Ende gute Ergebnisse erzielen und haben viel zu Simulationen gelernt. Für Informatik aber auch für Physik. Im Allgemeinen können wir sagen: Das Seminar war anspruchsvoll aber wir haben uns nicht unterkriegen lassen und haben unsere Ziele verfolgt.