Kurs 4 { Pinball, Breakout & Friends · { an dieser Stelle noch mal ein Lob an ihre Willensst arke sich durch diese Thematik durchzubeiˇen. Larissa war zwar still, arbeitete aber

KURS 4 – PINBALL, BREAKOUT & FRIENDS

Kurs 4 – Pinball, Breakout & Friends

Wir . . .

Samuel Samu kummerte sich standig um al-les mogliche, er selbst war immer motiviert.Am Eroffnungswochenende jammerte er vonAnfang an, er habe keine Ahnung vom Pro-grammieren, doch im Sommer zeigte er unswo der Programmierhammer hangt. Mit sei-nen Computerfahigkeiten wuchs auch seineAufmupfigkeit ;-) und er wurde zu einemvorantreibendem und lebhaftem Geist.

Wenke stellte sich den großen Herausforderun-gen mit Bravour und half uberall mit. Je-derzeit konnten wir auf ihre Zuverlassigkeitund Gewissenhaftigkeit zahlen, mit der sieihre Aufgaben erledigte. Wir vermissten siesehr, da sie am Abschlusswochenende leiderkrank war. Es fiel uns nicht leicht ihr Feh-len auszugleichen. Als Leichtathletin warsie nicht nur beim Sportfest sehr gut zu

gebrauchen, sondern auch zur Organisationunserer coolen Festlichkeiten.

Lucia war sehr nett und immer hilfsbereit. Au-ßerdem konnte man sich voll und ganz aufsie verlassen. Ihre Fantasie kannte bei denLeveln keine Grenzen, und sie entwickelteuns drei schicke Designs.

Das Bergfest gestaltete sie mit anderen zu-sammen zu einer genialen Fete.

Kate unser jungster Spross der Academy warzwar ruhig, aber sehr kreativ. Auch wenn siees als jungste nicht immer ganz leicht hatte,ging sie im Akademieleben nicht unter.

In unserem Kurs behauptete sie sich als einesolide Programmiererin, mag sie am Anfangauch manche Probleme mit der abstraktenMaterie des Programmierens gehabt haben

69


– an dieser Stelle noch mal ein Lob an ihreWillensstarke sich durch diese Thematikdurchzubeißen.

Larissa war zwar still, arbeitete aber trotzdemzugig und prazise.Wir konnten immer aufihre Programme zahlen. Mit ihrer souvera-nen Vortragekunst verzauberte sie uns alle,denn wenn sie vorne stand und ihr Themaprasentierte, verstand jeder gleich worumes ging.

Außerdem zeigt sie uns ihre Kontrolle uberdie Blockflote am Hausmusikabend mit ei-ner Kanon-Sonate.

Paul unser großer Koordinator, hat nie denUberblick verloren. Ohne ihn waren wiraufgeschmissen gewesen. Er fugte alle Klas-sen locker zusammen und sorgte fur einfunktionsfahiges Spiel. Auch er trug zu mitviel Ideenreichtum und witzigen Spruchenzum Erfolg unseres Kurses bei. Er scheutesich nicht Verantwortung zu ubernehmenund zu sagen, was Sache ist.

Philipp war unser Crack, sowohl informatischals auch physikalisch gesehen. Mit viel Spaßprogrammierte er die anspruchsvollen Ani-mationen der Abschlussprasentation undprogrammierte uns alle an die Wand.

Die Programmiersprache beherrschte er wieseine Muttersprache und mit seinem Fach-wissen half er an allen Ecken und Enden.

Alex Klein kam er doch ganz groß raus, was eruns durch seine wunderbare Prasentations-fertigkeit bewies. Mit seiner aufgewecktenArt brachte er, wo auch immer er hin ging,gute Laune mit und trug damit super zurAtmosphare bei.

Timo war der totale Physikjunkie, immer gutdrauf und ließ sich oft von DanY und Minanerven. Er hatte die Ruhe weg und meister-te fruher oder spater samtliche Probleme.

Dank seiner Ruhe loste er nicht nur dieverzwickten Ratsel, sondern minderte denStress in manchen Situationen.

Dany war immer bester Stimmung, auch wennihr Magen laut knurrte. Sie war extremgesprachig und heiterte alle anderen auf.Außerdem stand sie voll und ganz hintereinem PINKEN Breakout. Um uns eines

ihrer Hobbies naher bringen zu konnen, hatsie eine Taekwando-KuA geleitet und Timoim personlichen Schachspiel abgezogen.

Mina wusste immer, was zu tun war. Sie warsehr locker und ließ sich nicht aus der Ru-he bringen, stattdessen brachte sie frischenWind in den Kurs. Zu jeder Situation fielihr ein guter Kommentar ein, mit dem siealle zum Lachen brachte. Ihre freche undehrliche Art macht sie einzigartig.

Kevin war neben Paul die Sammelzentrale un-serer erarbeiteten Ergebnisse. Mit maßlo-ser Vorfreude wartete er auf die fertigenProgrammversionen und verpasste unsererAbschlussprasentation ein fetziges Layout.Dabei ist er samtliche Spielereien in Open-Office auf den Grund gegangen.

Jorg unser junger Kursleiter, der uns immermit Rat und Tat zur Seite stand. Auch inschwierigen Situationen behielt er den Uber-blick und war stets geduldig. Er motivierteuns auch uber die langsten Durststreckenhinweg und fand immer die richtigen Worte,wenn er das benotigte

”Hirnschmalz“ ein-

forderte.

Matthias unser erfahrener und uberaus kom-petenter Kursleiter war sehr hilfsbereit undversuchte uns in jedem Moment die Weltder Informatik etwas naher zu bringen.

Er legte besonders Wert auf Ordnung imQuelltext und die Auflosung der Bilder, wasuns oft in den Wahnsinn trieb. Er liebtees uns darauf hinzuweisen, dass wir unserProjekt

”an die Wand fahren“. Seine Kaf-

feemaschine brachte uns sehr viele Besucheein.

Melli war die beste Schulermentorin. Sie hatuberall gute Stimmung verbreitet, so war esstandig lustig, wenn man auf sie getroffenist.

Beim Hip-Hop war sie immer voller Powerund Motivation und schaffte es auch imtheoretischen Unterricht, uns schwierigenPhysikstoff zu vermitteln.

Alle zusammen haben wir viel geschafft und je-de Menge Spaß gehabt: Was sind wir? INFOS!

70


Einleitung

Paul Nickel

Breakout, Pinball und Friends – das war derName unseres Kurses.

Zusammen mit unseren Kursleitern Jorg Rich-ter, Matthias Taulien und Melina Becker habenwir uns in den Bereich der Computerspielent-wicklung gewagt. Das Ziel des Kurses war esein komplexes Computerspiel zu entwickeln,bei dem auch die Physik und die Mathematikeine wichtige Rolle spielt.

Um das Spiel auf den Bildschirm zu bringenerlernten wir die Programmiersprache Java.

Das Ziel des Kurses war es also ein physikalischmoglich korrektes Computerspiel zu entwickeln– aber es blieb die Frage, wie dieses Spiel ausse-hen sollte?

Angeregt von unserer Kursleitung entschiedenwir uns fur das Spiel Breakout.

Auf der Abbildung ist eine Vorabversion unse-res Spieles zu sehen: Am oberen Spielfeldrandsind verschiedenfarbige Blocke zu sehen, darun-ter befindet sich der Ball und das gelbgefarbtePaddel.

Ziel des Spieles ist es, alle Blocke auf dem Spiel-feld mithilfe des Balls zu zerstoren. Der Ballwird mit dem Paddel im Spielfeld gehalten. ImIdealfall bewegt sich der Ball nach den physi-kalischen Gesetzmaßigkeit und wird an demlinken, rechten und oberen Spielfeldrand sowiean den Blocken und (ganz wichtig) an dem Pad-del reflektiert. Am unteren Spielfeldrand wirdder Ball allerdings nicht reflektiert, sondern ausdem Spiel entfernt.

Diese Grundidee kann man um beliebig vieleModifikationen erweitern. So stehen einem inder Version, wie auf der Abbildung zu sehenist, insgesamt drei Balle zur Verfugung. Zudemhaben die Blocke mehrere Leben und besitzeneine gewisse Art Anziehungskraft. Am unterenSpielfeldrand ist eine rote Zeitleiste zu sehen.Ist diese abgelaufen wird eine neue Reihe vonBlocken erzeugt. Auf der linken, unteren Spiel-feldseite wird der aktuelle Spielstand angege-ben. Auf der rechten, unteren Spielfeldseite istzu sehen, wie viele Balle noch zur Verfugungstehen.

In unserem Spiel, das wir als Team zusammenprogrammiert haben, gibt es unter anderemeine ausfuhrlichere Ausgabe des Spielstands,Buttons mit verschiedenen Funktionen, ein Hil-fefenster, drei verschiedene Level, Bonusobjekteund vieles mehr.

Screenshot eines Breakout-Spieles

Aber nicht nur die Spielidee kann man beliebigmodifizieren: Auch bei der physikalisch kor-rekten Umsetzung des Spieles kann man ,wieJorg immer so schon sagte,

”beliebig viel Ge-

hirnschmalz“ investieren. Bei insgesamt 3 794Zeilen Code unseres Spieles machten die 1 139Zeilen, die das Spiel physikalisch moglichst rea-listisch machen, einen erheblichen Anteil aus.

So haben wir uns in mehreren Einheiten mitverschiedenen physikalischen Themen ausein-andergesetzt: Begonnen mit Vektorberechnung,uber Gravitation bis hin zu Beschleunigung ha-ben wir uns mit einigen Bereichen der Dynamikbeschaftigt.

ObjektorientierteProgrammierung

Larissa Link

Unser Breakout-Spiel haben wir in Java, einerobjektorientierten Programmiersprache entwi-ckelt. Wichtige Aspekte der objektorientiertenProgrammierung und damit die großten Vor-teile dieser Art der Programmierung sind: diehierarchische Klassenstruktur mit Vererbung,also die Aufteilung des Quelltextes in einzelneKlassen, und die Datenkapselung.

71


Klassen und Objekte

In unserem Spiel gibt es verschiedene Spielfi-guren und Spielfunktionen, die unterschiedlichaussehen und verschiedene Eigenschaften undFahigkeiten haben. In einem Programm ist furjedes dieser Elemente eine Klasse vorhanden.Klassen sind Bauplane, sozusagen die Bauanlei-tungen fur die Objekte, die man dann im Spielverwenden kann. Ein Objekt hat Fahigkeiten,bestimmte Aktionen auszufuhren und hat typi-sche Eigenschaften. Diese Eigenschaften – auchAttribute genannt – und die moglichen ausfuhr-baren Handlungen, die man mithilfe von Me-thoden realisiert, sind in der jeweiligen Klasseaufgefuhrt. Jede dieser Klassen hat ihren ei-genen Quelltext – das heißt eine Datei, in dieman in der Programmiersprache Befehle hin-einschreibt, um Methoden und Attribute zudefinieren. Dies ist ein großer Vorteil der objek-torientierten Programmierung: man hat nichteinen großen Programmtext, sondern jede Klas-se hat einen Bereich, eine Datei fur sich, in derprogrammiert werden kann. Das ist vor allemwichtig, wenn man in Gruppen arbeitet. JedeArbeitsgruppe kann beispielsweise eine eigeneKlasse programmieren, damit gleichzeitig anverschiedenen Funktionen des Programms gear-beitet werden kann. Spater lassen sich dann alleKlassen zu einem gemeinsamen Programm zu-sammenfuhren. Sowohl die Attribute, als auchihre Werte und die Methoden einer Klasse las-sen sich nur innerhalb des Quelltextes genaudieser Klasse direkt verandern; nur durch Me-thoden kann man beim Programmieren aufandere

”fremde“ Klassen zugreifen. Das nennt

man Datenkapselung.

Hierarchie und Vererbung

Wenn man eine Klasse geschrieben hat, kannman beliebig viele Objekte dieser Klasse er-zeugen. Diese haben dann die jeweiligen defi-nierten Eigenschaften und konnen auch realihre Methoden ausfuhren. Die Klassen einesProgramms mussen aber nicht alle gleichge-stellt sein. Man kann unter ihnen auch eineHierarchie aufbauen. Das heißt, man kann voneiner Klasse Unterklassen erzeugen. Nur durchdiese Hierarchie unter den Klassen kann ein

sehr wichtiger Aspekt der objektorientiertenProgrammierung zum Tragen kommen, nam-lich die Vererbung. Wenn man von einer Klasseeine neue Unterklasse erstellt, und von dieserObjekte erzeugt, erben diese automatisch alleAttribute und Methoden der Oberklasse. Au-ßerdem kann man in der Unterklasse nun nochzusatzliche Eigenschaften und Fahigkeiten hin-zufugen. Man muss so nicht alle bereits in derOberklasse vorhandenen Attribute und Metho-den nochmal schreiben! Dies erspart Arbeit –die neue Unterklasse hat schon alle in der Ober-klasse gegebenen

”Voraussetzungen“ und lasst

sich dazu noch weiter spezifizieren.

Wie funktioniert eine Animationam Computer?

Lucia Constanze Grosse

Taglich, wenn man am Computer arbeitet odernur im Internet surft, wird man mit sich be-wegenden Grafiken konfrontiert. Das gleichepassiert auch in unserem Computerspiel, dennwas ware ein Breakout-Spiel ohne einen ani-mierten Ball?

Bevor man ein Objekt bewegen kann, mussman es zunachst zeichnen konnen.

Zeichnen einer Grafik

Wenn man eine Grafik am Computer zeichnet,legt man ihre Position durch Koordinaten fest.

Dazu nutzt man ein normales zweidimensio-nales kartesisches Koordinatensystem, welches

72


sich von dem, das wir aus dem Mathematikun-terricht kennen, ein wenig unterscheidet.

Die x-Achse zeigt zwar wie gewohnt von linksnach rechts, die y-Achse jedoch von oben nachunten. Die markierte Kachel hat also die Ko-ordinaten (1|2).

Damit ein Objekt erscheint, muss es genauwie auf einem Papier gezeichnet werden. Dafurbenotigen wir eine Methode, da wir schließ-lich auch sichtbare Objekte verwenden. DieMethode zeichneDich() ist bei uns fur dasZeichnen eines Objekts zustandig. Die Grafikwird mit einem Objekt namens g2d der KlasseGraphics2D, vergleichbar mit einem Multi-funktionsstift, konstruiert und gezeichnet.

Mit der Methode g2d.setColor() legt manfest, welche Farbe das zu zeichnende Objekterhalten soll.

Danach zeichnet man beispielsweise mit der Me-thode g2d.fillRect(100, 200, 50, 10)ein Rechteck, das 50 Pixel breit und 10 Pixelhoch ist; die linke obere Ecke des Rechteckshat die Koordinaten (100|200)

In der Praxis setzen wir nicht sofort Zahlen ein,sondern Variablen. Dies ermoglicht Rechteckemit unterschiedlicher Große und Position zuzeichnen. Bei uns werden die Abmessungen so-gar dynamisch an die Spielfeldgroße angepasst.

Animieren einer Grafik

Fur die Bewegung der Objekte ist die Metho-de bewegeDich() zustandig. Objekte werdenvom Computer bewegt, indem man ihre Ko-ordinaten verandert. Um ein Objekt zum Bei-spiel nach rechts zu verschieben, verandert mandie x-Koordinate. Um es sowohl horizontal alsauch vertikal zu verschieben, verandert mandie x-Koordinate wie auch die y-Koordinate.

In der Methode bewegeDich() weisen wirdem x-Wert und dem y-Wert jeweils neue Wer-te zu. Das Gleichheitszeichen entspricht in die-sem Fall nicht dem gebrauchlichen Gleichheits-zeichen, sondern einer Zuweisung.

x = x + 20

y = y + 10

Wenn man diese Methode mehrmals hinter-einander ablaufen lasst, befindet sich der Balljedes Mal an einer anderen Position:

Je schneller man die Methode hintereinanderablaufen lasst, desto gleichmaßiger und realerwirkt die Bewegung, weil wir die Sprunge zuden neuzugewiesenen Koordinaten nicht mehrwahrnehmen. Dies kann man sich wie bei einemDaumenkino vorstellen.

EntwicklungsumgebungenGreenfoot und Eclipse

Alexander Quint, Kevin Wang

In unserem Kurs haben wir mit zwei soge-nannten Entwicklungsumgebungen gearbeitet:Greenfoot und Eclipse. Beide basieren auf derProgrammiersprache Java, unterscheiden sichaber deutlich.

73


Eine Entwicklungsumgebung hilft dabei, Pro-gramme zu entwickeln. Sie formatiert den Code,zeigt Syntaxfehler an und macht Losungsvor-schlage zur Fehlerbehebung. Außerdem uber-setzt der Compiler den Quellcode in Befehle,die vom Computer ausgefuhrt werden konnen.

Greenfoot ist zum Erlernen von Java gedacht.

Man kann eine Spielfeld-Welt mit graphischenObjekten bevolkern, deren Eigenschaften undFahigkeiten man programmiert – ideal fur einkleines Computerspiel

Eclipse dagegen eine sehr machtige Entwick-lungsumgebung ist, die auch von professionellenProgrammierern benutzt wird. In Eclipse istkein Grundgerust vorgegeben, also muss manalles selbst erstellen.

Greenfoot haben wir am Eroffnungswochenen-de und bei unserer Hausaufgabe verwendet –wahrend der Sommerakademie jedoch habenwir mit Eclipse programmiert.

Hauptfenster von Greenfoot

Die obige Abbildung zeigt das Hauptfenstervon Greenfoot. In der Mitte befindet sich dasSpielfeld. In dieses kann man direkt Objekteeinfugen, und man kann deren Methoden auf-rufen oder Attribute inspizieren. Auf der rech-ten Seite sieht man den Bereich mit den ver-schiedenen Klassen und Unterklassen, z. B. dieKlasse Paddel. Mit den Buttons

”Run“ (vor

Spielstart),”Pause“ (wahrend des Spiels) und

”Reset“ unterhalb des Spielfelds kann man dasSpiel starten, stoppen und in den Anfangszu-stand versetzen. Mit dem Regler

”Geschwindig-

keit“ wird die Geschwindigkeit der beweglichenObjekte (Ball, Paddel) eingestellt.

Im untenstehenden Bild wird die Arbeitsplatt-form von Eclipse dargestellt. Hier sieht man,dass Eclipse deutlich komplexer als Greenfootist.

Arbeitsplattform von Eclipse

Auf der linken Seite sieht man einen Bereich,auf der sich alle Projekte, Pakete und Klassenbefinden. In der Mitte ist das Editorfenster,in dem man den Quelltext fur Programme er-stellen kann. Auf der oberen Leiste gibt es eineinen grunen Button mit einem weißen Pfeil.Wenn man auf diesen klickt, wird das Spielkompiliert und gestart. Unten gibt es einenAusgabebereich fur Fehlermeldungen etc. Aufder rechten Seite befindet sich eine Klassen-hierarchie. Und wenn man einen Programmier-fehler macht, wird dieser durch ein rotes Feldam Rand gekennzeichnet. Wenn man auf ei-ne Gluhbirne am Rand klickt, bekommt manLosungsvorschlage.

Die Entwicklung unseres SpielsDaniela Schafer, JasminaVercrusse

Fur ein komplexes Spiel wie Breakout war essinnvoll die Arbeit aufzuteilen.

Dazu mussten wir noch bevor wir anfingen zuprogrammieren, uberlegen, wie unser Spiel zumSchluss aussehen sollte und eine Programm-struktur entwerfen. Die einzelnen Fachgruppenmussten sich dann Bereiche aussuchen und diedamit verbundenen Klassen programmieren.Mit dieser Vorgehensweise erzielten wir einengroßen Erfolg, weil sich jede Gruppe nur mit

74


Vektor

Kollision

BreakOut

MyJavaGame

ErbtVerwendet MethodenEnthält Objekte

Level 1-3

Level

Hilfsmittel

BallBlock Paddel

Figur

Goodies

Spielfeld

Spielmanager

Zähler

ihrem Themengebiet und dessen Problemenbeschaftigen musste. Teilweise wurde, zum Bei-spiel der Mathematikgruppe, spezielles Fach-wissen ubermittelt. Ein weiterer Vorteil war,dass

verschiedene Klassen gleichzeitig programmiertwerden konnten, was uns sonst nicht moglichgewesen ware.

Um das Programmieren der Klassen zu koordi-nieren, wurden zu Beginn Etappenziele festge-legt. Die unterschiedlichen Versionen wurdenan einem gesammelten Speicherort zusammen-gefugt und mit den jeweiligen Versionsnum-mern bezeichnet. Nachdem alle Klassen in ei-ner Versionsnummer ubereingestimmt hatten,wurden sie zu einem gesamten Spiel mit ebendieser Versionsnummer zusammengefugt.

Ein temporares Problem war, dass jede Fach-gruppe unterschiedlich viele Aufgaben fur diejeweiligen Versionen hatte und unterschiedlichschnell gearbeitet hat. Somit waren die einzel-nen Bereiche oft verschieden weit entwickeltund es konnte nicht immer die neueste Versiondes Spiels erstellt werden, obwohl sie fur einigeGruppen zur Weiterarbeit notig gewesen wa-re. Man musste deshalb provisorisch arbeiten:Hierzu sprach man sich vorher ab, wie die be-notigte Methode heißen solle, und verwendete

sie geeignete Platzhalter.

Ein weiteres Problem konnte sich in der Kom-munikation ergeben: Es kam vor, dass Fach-gruppen an Aufgaben arbeiteten, fur die siegar nicht zustandig waren oder die zustandigeFachgruppe erledigte ihre Aufgaben nicht, weilsie mit anderen Aufgaben beschaftigt war.

Trotz dieser Probleme bot die Gruppenarbeitviele Chancen und verringerte den Arbeitsauf-wand fur die gesamte Gruppe. Ohne diese Auf-teilung waren wir mit unserem Spiel wohl nieso weit gekommen.

Das Herz des Spiels

Kevin Wang, Paul Nickel

Das Herz unseres Breakout-Spiels sind die Klas-sen MyJavaGame, Breakout und die KlasseSpielmanager. Die Klasse MyJavaGame ent-halt ein Grundgerust fur die Animation.Breakout koordiniert das gesamte Spiel, unddie Klasse Spielmanager verwaltet die An-gaben, die den Spielstand betreffen, wie zumBeispiel das aktelle Level, den Punktestandund die Anzahl der Leben.

75


Die Klasse MyJavaGame

Doch wie funktioniert das Zusammenspiel die-ser Klassen? Die Klasse MyJavaGame wurdevon unseren Kursleitern vorbereitet, um unsden Einstieg zu erleichtern. In dieser Klassewar die Rumpf-Animation bereits vorhanden:Zum Beispiel eine Methode, die immer wiederausgefuhrt wird, und in der auch das (alledingsnoch leere) Spielfeld gezeichnet wird.

Die Klasse Breakout

Breakout definierten wir als eine Unterklassevon MyJavaGame, sodass Breakout alle Me-thoden von MyJavaGame ausfuhren kann. Inder Klasse Breakout werden neue Spielfigu-ren und das Spielfeld erzeugt, ihre Positionenberechnet und gezeichnet – sie ist die zentra-le Klasse unseres Spiels. Außerdem wird derPunktestand angezeigt und gepruft, ob eineTaste gedruckt wird.

Betrachten wir die Klasse Breakout naher.Der Quelltext der Klasse Breakout bestehtim Wesentlichen aus vier Abschnitten:

Im Konstruktor stehen die Befehle, die beimStart des Spiel bearbeitet werden. In ihm wer-den zum Beispiel das Spielfeld, die Spielfigurenund die Spalte fur den Spielstand erzeugt.

Im zweiten Abschnitt finden alle Berechnun-gen statt. Dort wird die aktuelle Position desBalls berechnet und gepruft, ob eine Kollisionstattfindet.

Des weiteren gibt es den Bereich, die fur dasZeichnen des Spiels zustandig ist.

Am Schluss befindet sich der Teil, der fur dieBehandlung der Tasten zustandig ist. In ihmist die gesamte Steuerung des Spiels festgelegt:Wenn zum Beispiel die p-Taste gedruckt wird,wird das Spiel pausiert.

Man sieht, dass die Klasse Breakout ziem-lich komplex ist. Damit Breakout nicht zu un-ubersichtlich wurde, haben wir andere wichtigeAufgaben in eigene Klassen ausgelagert.

Die Klasse Spielmanager

Die Berechnung des Spielstands (Punkte, Le-ben, Level) ubernehmen deshalb die Klassen

Spielmanager und Zaehler. Außerdem er-zeugt der Spielmanager neue Level und Goodies.Goodies sind Objekte, die zufallig herunterfal-len, wenn man einen Block zerstort hat. Siekonnen dann vom Spieler eingesammelt wer-den. Damit dies funktioniert, kommunizierendie Klassen Spielmanager und Breakoutmiteinander.

Um den aktuellen Spielstand zu berechnen,steht der Spielmanager in engem Kontakt mitder Klasse Zaehler und der KlasseKollision. Ein Beispiel: Wenn ein Block zer-stort wurde, ruft die Klasse Kollision denZaehler auf, der dann den Punktestand erhoht.Der Punktestand wiederum wird dann vomSpielmanager abgefragt.

Soweit es uns moglich war, haben wir versucht,den Spielmanager unabhangig von der KlasseKollision zu gestalten. In der Praxis siehtdas dann so aus: Sollten keine Blocke mehrauf dem Spielfeld sein, muss nicht die Klas-se Kollision dem Spielmanager mitteilen,dass er ein neues Level erzeugen soll. Vielmehrpruft der Spielmanager selbsttatig, ob auf demSpielfeld noch Blocke sind. Ist dies nicht derFall, erzeugt er automatisch ein neues Level.Somit entstehen zwei getrennte Ablaufe, diedie Fehlerbehebung vereinfachen und das Spielubersichtlicher machen.

Insgesamt bilden die drei Klassen MyJavaGame,Spielmanager und Breakout das Herz un-seres Spiels. Sie bekommen den Großteil allerInformationen ubermittelt und entscheiden aufderen Basis, welche Aktion als nachstes ausge-fuhrt werden soll.

Das Paket figuren

Kate Lau

Das Paket figuren beinhaltet die KlasseFigur und als deren Unterklassen Ball,Block, Paddel und Goody.

Somit ist das Paket figuren fur die verschie-denen Objekte auf dem Spielfeld zustandig.

76


Die Klasse Figur

Die Klasse Figur enthalt alle diejenigen beno-tigten Methoden und Eigenschaften, die alle Fi-guren gemeinsam haben: die Position, die Brei-te, die Hohe, die Geschwindigkeit, die Beschleu-nigung, die Farbe und das Abbild. Fur die Po-sition, die Beschleunigung und die Geschwin-digkeit werden Vektoren benutzt, da man mitihnen geschickter rechnen kann.

Fur die Attribute sind Getter- und Setterme-thoden implementiert. Das sind Methoden, mitdenen man die Werte der Attribute erfragenoder modifizieren kann.

Alle Figuren werden aufs Spielfeld gezeichnet,mussen also eine Methode zeichneDich()bereitstellen. Nun wird ein Ball naturlich an-ders gezeichnet als ein Block. Deshalb kann derCode von zeichneDich() nicht in der KlasseFigur stehen. Sie ist deshalb hier lediglich de-klariert, dadurch ist sichergestellt, dass in allenUnterklassen eine solche Methode implemen-tiert werden muss. In der Fachsprache nenntman solche Methoden

”abstrakt“.

Die Klasse Paddel

Da die Klasse Paddel eine Unterklasse vonFigur ist, erbt ein Paddel-Objekt alle Metho-den und Attribute von der Klasse Figur. Des-halb braucht sie nur wenige zusatzliche Me-thoden. Zum Beispiel kennt das Paddel nochdie beiden Methoden getGanzLinks() sowiesetGanzLinks() und analog die MethodengetGanzRechts() und setGanzRechts().Außerdem wird die Methode zeichneDich()mit Leben gefullt.

Die Klasse Ball

Ein Ball hat drei Attribute mehr als eine Fi-gur: Durchschlagskraft, Masse und Radius. DieMasse wird bei der Kollision von zwei Ballenbenotigt. Durchschlagskraft ist ein boolscherWert (ein Wahrheitswert, der entweder wahroder falsch sein kann) und beschreibt, ob derBall von den Blocken reflektiert wird oder nicht.

Die Klasse Block

Ein Block besitzt noch das Attribut anzLeben.Es zahlt, wie viele Leben ein Block hat, also

wie oft ein Block vom Ball getroffen werdenmuss, bis er verschwindet.

Die Klasse Block hat mehrere Konstruktorenfur die verschiedenen Blocke, etwa fur ruhendeBlocke oder sich bewegende Blocke.

Sie kennt außerdem Methoden, um Leben hin-zuzufugen bzw. abzuziehen und die Anzahl derLeben abzufragen.

Level

Lucia Constanze Grosse

Um fur den notigen Spielspaß zu sorgen, habenwir verschiedene Level entworfen, die unter-schiedlichen Schwierigkeitsgraden entsprechenund besondere Funktionen, wie zum BeispielGoodies besitzen.

Level 1

Wenn ein Block zerstort wird, kann mit einergewissen Chance ein sogenanntes

”Goody“ ent-

stehen. Goodies sind, wie der Name schon ver-rat, Bonusobjekte. Um die Wirkung des Goo-dies auszulosen, muss man das Goody mit demPaddel auffangen.

Die Goodies und ihre Wirkungen

Beim Auffangen dieses Goodies wirddas Paddel breiter.

Dieses Goody sorgt dafur, dass derBall eine Durchschlagskraft bekommtund so durch Blocke hindurch fliegenkann und nicht von ihnen reflektiertwird.

Mit Auffangen dieses Goodies erhaltman funf Extraballe.

77


Unter dem Paddel entsteht eine Si-cherheitsbande, die einen Ball reflek-tiert, falls es dem Spieler nicht gelingt,den Ball mit dem Paddel aufzufangen.

Dieses Goody fuhrt dazu, dass manein weiteres Leben bekommt.

Dieses Goody musste man eigentlichals

”Bady“ bezeichnen, da es bewirkt,

dass das Paddel schmaler wird.

Level 2

Im zweiten Level kommen zu den Funktionenaus Level 1 noch

”Steine“ hinzu. Das sind nicht-

verschwindende Blocke, die den Ball dennochnormal reflektieren. In diesem Level bewegensich die Steine horizontal hin und her. Außer-dem gibt es Blocke, die man 2 treffen muss,bevor sie verschwinden. Man sagt, sie haben 2Leben.

Level 3

In unserem 3. Level gibt es Blocke mit entwedereinem, zwei oder drei Leben. Die Anzahl derLeben eines Blocks lasst sich an seiner Farbeerkennen. Rot steht fur ein Leben, gelb fur zweiund grun fur drei Leben. Wieder gibt es Steine,die sich diesmal aber nicht bewegen.

BeschleunigungPaul Nickel, Philipp Provenzano

Um das Spiel noch realistischer zu gestalten,sollten die sich bewegende Korper eine Schwer-kraft erfahren.

Beim Fall eines Korpers zum Boden erfahrt ereine konstante Geschwindigkeit.

Um die Gravitation nachvollziehen zu konnen,mussten wir uns aus diesem Grund erst einmalmit dem Thema Beschleunigung beschaftigen.

Beim Beschleunigen erfahrt ein Korper einefortwahrende Zunahme der Geschwindigkeit –er wird schneller.

Die durchschnittliche Beschleunigung ~a defi-niert man als:

~a =~v2 − ~v1t2 − t1

Dabei sind ~v1 und ~v2 die Geschwindigkeit zuden Zeitpunkten t1 und t2. Fur t2−t1 schreibenwir kurzer ∆t.

Mit dieser Formel berechnen wir dann die ge-anderte Geschwindigkeit des Korpers:

~vneu = ~valt + ~a ·∆t

Die neue Geschwindigkeit verwenden wir wie-derum zur Berechnung der neuen Position desKorpers:

~sneu = ~salt + ~vneu ·∆t

~s ist bei uns die Position des Mittelpunkts einesObjekts.

Da durch diese Formel die Geschwindigkeit dis-kret beschrieben wird, ist die Berechnung nichthunderprozentig genau – fur unsere Zweckejedoch vollkommen ausreichend.

Kollisionen . . .Samuel Brielmaier

. . . am Spielfeldrand

Damit der Ball bei unserem Spiel im Spielfeldgehalten wird, muss der Ball an den Randernreflektiert werden. Um zu prufen, ob der Ball

78


den Spielfeldrand beruhrt, wird jedes Mal, wenndie Figuren neu gezeichnet werden, abgefragt,ob der Abstand des Ballmittelpunkts zum Randkleiner oder gleich wie sein Radius.

Wenn dies der Fall ist, wird ein Teilvektor (ent-weder die x-, oder die y-Komponente) des Ge-schwindigkeitsvektors gespiegelt.

Konkret bedeutet das bei dem unten zu sehen-den Beispiel:

Die x-Richtung soll entgegengesetzt werden,deshalb wird die x-Komponente des Geschwin-digkeitsvektors invertiert. Dadurch gilt die Ge-setzmaßigkeit

”Einfallswinkel ist gleich Ausfall-

winkel“.

Spielfeldrand

v y

v x

v

Reflexion am linken Spielfedrand: Der Abstand des

Balles zum linken Rand ist hier genau der Radius.

~v steht fur den Geschwindigkeitsvektor, ~vx fur seine

x-Komponente und ~vy fur die y-Komponente.

Bei der Kollision des Balles am oberen Spiel-feldrand wird statt der x-Komponente einfachdie y-Komponente umgedreht.

. . . mit einem Block

Dazu haben wir die Kollision in 8 verschiedeneFalle eingeteilt: Die Kollision mit der Ober-und Unterseite, der linken und rechten Seiteund den vier Ecken bildet hierbei jeweils einenFall.

Spielfeldrand

v vneu

v y

v x vneux

Die invertierte x-Komponente der Geschwindigkeit

ergibt mit der unveranderten y-Komponente den

neuen Geschwindigkeitsvektor.

An der linken und rechten Seite verhalt sichder Ball exakt genau so wie am linken undrechten Spielfeldrand, denn es wird immer nurder x-Vektor invertiert. Dementsprechend wirdbei der Kollision an der Ober- und Unterseiteder y-Vektor invertiert, so wie es auch beimoberen Spielfeldrand der Fall ist.

An den Ecken ist es dagegen erheblich kom-plizierter. Deshalb haben wir uns angesehen,wo der Mittelpunkt des Balles ist, wenn eineKollision stattfindet.

Block

Mittelpunkt des Balles

„Ersatzblock“

Die Reflexion verhalt sich genauso, als wennman zum Berechnen der neuen Werte den Mit-telpunkt des Balles an einem

”Ersatzblock“ re-

79


flektieren lasst, der zum Rand des echten Blocksden Abstand des Radius des Balles hat.

Somit ist die Berechnung deutlich einfacher.Der Mittelpunkt des Balls wird im Kollisionsfall

”Ecke“ an der Beruhrungstangente mit einemKreis (um die Ecke und dem Radius des Balles)reflektiert.

Block

Kreis um die Ecke mit dem Radius des BallesMittelpunkt

des Balles

Berührungs-tangente

Ball

Der Ballmittelpunkt wird an einem Kreis um die

Ecke reflektiert

Ball-Paddel-ProblemWenke Grahneis

Als wir die ersten Versionen unserer Kollisiondes Balls am Paddel testeten, trat immer wiederein Problem auf: Wenn das Paddel den Ball(mit einer Geschwindigkeit 6= 0) von der Seitetraf, blieb der Ball im Paddel hangen, wie manhier erkennen kann:

Das wollten wir naturlich nicht und machtenuns auf die Suche nach der Ursache. Dabeifanden wir folgendes heraus: Wenn der Ballnach der Reflexion am Paddel eine geringere

Geschwindigkeit als das Paddel hat – das Pad-del also schneller ist als der Ball – meldet esnach dem nachste Rechenschritt wieder Kon-takt mit dem Ball. Das fuhrt zu einer weiterenReflexion des Balls. Da der Ball nun wieder inseine ursprungliche Richtung fliegt, hat er imnachsten Rechenschritt hochstwahrscheinlichwieder Kontakt mit dem Paddel und wird re-flektiert. Durch dieses dauernde Reflektierendes Balls hat es fur uns den Anschein, als hattedas Paddel den Ball gefangen.

Unsere erste Idee zur Behebung des Problemswar es, den Ball nach seiner Reflexion am Pad-del noch zusatzlich einen Zeitschritt zuruckzu-setzen. Wir testeten die neue Version und merk-ten schnell, dass diese Losung zwar bei niedri-gen Geschwindigkeiten funktionierte, aber beihohen Geschwindigkeiten des Paddels keinenErfolg hatte. Wir stellten das Problem miteinem physikalischen Versuch nach, bei demzwei Wagen kollidieren und erkannten, dassder Ball eigentlich vom Paddel nicht nur re-flektiert, sondern, sofern das Paddel auch eineGeschwindigkeit besitzt, entsprechend dem Im-pulserhaltungssatz auch beschleunigt wird.

Fur diese Rechnung muss man die Kollision ausdem

”Paddelsystem“ betrachten, das heißt sich

das Koordinatensystem aus Sicht des Paddelsvorstellen. Wenn sich also ein Ball im eigentli-chen Koordinatensystem mit einer Geschwin-digkeit von −10 Pixel pro Sekunde nach linksauf das Paddel zubewegt und das Paddel sichihm mit einer Geschwindigkeit von 50 Pixelpro Sekunde nahert, wurde er sich dem Paddelim

”Paddelsystem“ mit einer Geschwindigkeit

von −60 Pixel pro Sekunde nahern. Der Grunddafur ist, dass das Paddel im

”Paddelsystem“

immer die Geschwindigkeit 0 hat und man demBall somit die Geschwindigkeit des Paddels ab-zieht. Nun wird der Ball am Paddel reflektiert.Das hat zur Folge, dass seine Geschwindigkeitinvertiert wird, also aus −60 Pixel pro Sekun-de, +60 Pixel pro Sekunde werden. Um dieseGeschwindigkeit nun wieder in das normale Ko-ordinatensystem umzurechnen, muss man dieGeschwindigkeit des Paddels wieder dazu ad-dieren: 60 px/s + 50 px/s = 110 px/s. Also hatder Ball nach der Kollision mit dem Paddel eineGeschwindigkeit von 110 Pixel pro Sekunde.

80


Diese Rechnung bauten wir dann in unserenQuelltext der Klasse Kollision ein. Wir fuhrteneinen Test der neuen Version durch, und eszeigte sich, dass das Paddel den Ball erfreuli-cherweise nicht mehr fangen konnte. Leider tratnun ein neues neues Problem auf: Durch denstarken Kick wurde der Ball oft sehr schnell –im obigen Beispiel hat sich die Geschwindig-keit mehr als verzehnfacht! Durch diese hoheGeschwindigkeit wurde der Ball fur den Spie-ler unkontrollierbar. Wir beschlossen, die Me-thode so zu modifizieren, dass der Ball beider Kollision einen geringeren Teil der Paddel-Geschwindigkeit ubertragen wird, so als waredas Paddel weich.

So hatten wir schließlich eine physikalisch kor-rekte und gleichzeitig spielbare Losung gefun-den!

Kollision von zwei BallenPhilipp Provenzano, TimoSimnacher

Die Behandlung der Kollision zwischen zweiBallen hat uns am meisten Kopfzerbrechenbereitet.

Bei der Berechnung der Position der Balle ha-ben wir uns bisher immer an dem Koordinaten-system des Spiels orientiert. Bei der Kollisionmussten wir allerdings ein Koordinatensystemmit einem anderen Ursprung verwenden: Wirarbeiteten im Schwerpunktsystem.

In diesem System ist der Ursprung des Koor-dinatensystems der Schwerpunkt der beidenBalle. Alle Bewegungen werden von dort ausbetrachtet.

Der Ort des Schwerpunktes ist:

~xSp =m1 · ~x1 + m2 · ~x2

m1 + m2

Dabei sind m1 und m2 die Massen und ~x1und ~x2 die Koordinaten der Mittelpunkte derbeiden Kugeln.

Mit der Ableitung nach der Zeit kann man dieGeschwindigkeit des Schwerpunkts berechnen.Aus

d~x1dt

= ~v1 undd~x2dt

= ~v2

folgt:

~vSp =m1 · ~v1 + m2 · ~v2

m1 + m2

Dann ist die Geschwindigkeit des Schwerpunk-tes nach dem Stoß:

~uSp =m1 · ~u1 + m2 · ~u2

m1 + m2

Der Impulserhaltungssatz besagt:

m1 · ~v1 + m2 · ~v2 = m1 · ~u1 + m2 · ~u2

Daraus folgt: ~uSp = ~vSp – die Geschwindigkeitdes Schwerpunkts ist also erhalten!

Im Schwerpunktsystem ist die Geschwindigkeitdes Schwerpunkts 0:

~vSp = 0

0 =m1 · ~v1 + m2 · ~v2

m1 + m2

0 = m1 · ~v1 + m2 · ~v2

Die rechte Seite der Gleichung ist der Gesamt-impuls – er ist im Schwerpunktsystem also im-mer null!

Elastische Stoße imSchwerpunktsystem

Wir berechnen nur elastische Stoße, also sol-che, bei denen keine Bewegungsenergie verlorengeht, etwa durch Verformung. Sie sollen auchreibungsfrei sein, so dass die Balle keinen Drallerhalten.

Zunachst uberzeugt man sich davon, dass dieBetrage der Geschwindigkeiten einzeln erhaltensind:

Wie wir gerade gesehen haben, ist der Gesam-timpuls im Schwerpunktsystem immer null.Dies formt man um:

m1 · ~v1 + m2 · ~v2 = 0

~v2 = −m1

m2· ~v1

Und ebenso nach dem Stoß:

m1 · ~u1 + m2 · ~u2 = 0

81


~u2 = −m1

m2· ~u1

Da wir elastische Stoße betrachten, ist die Ge-samtenergie vor und nach dem Stoß gleich. DieBewegungsenergie eines Korpers errechnet sichaus dem Produkt der Masse und dem Quadratder Geschwindigkeit: E = 1

2 ·m · ~v2. Es gilt

also:1

2m1 ·~v 2

1 +1

2m2 ·~v 2

2 =1

2m1 ·~u 2

1 +1

2m2 ·~u 2

2

Nun kann man fur ~v2 und ~u2 einsetzten, wasman oben erhalten hat:

m1 · ~v 21 + m2 ·

(−m1

m2· ~v1

)2

= m1 · ~u 21 + m2 ·

(−m1

m2· ~u1

)2

m1 · ~v 21 + m2 ·

m 21

m 22

· ~v 21

= m1 · ~u 21 + m2 ·

m 21

m 22

· ~u 21

~v 21 +

m1

m2· ~v 2

1 = ~u 21 +

m1

m2· ~u 2

1(1 +

m1

m2

)· ~v 2

1 =

(1 +

m1

m2

)· ~u 2

1

~v 21 = ~u 2

1

|~v1| = |~u1|

Damit ist gezeigt, dass sich im Schwerpunkt-system der Betrag der Geschwindigkeit jedesBalls nicht andert, seine Richtung moglicher-weise schon.

Um die neue Richtung zu finden, zerlegt mandie Ballgeschwindigkeit zu dem Zeitpunkt, zudem sich die Balle beruhren, in eine Komponen-te parallel und eine Komponente orthogonalzur Beruhrungstangente.

Bei einem reibungsfreien Stoß wirkt keine Krafttangential zur Oberflache. Deshalb andert sichdie Parallelkomponente (blau) nicht. Auch derBetrag der Geschwindigkeit bleibt gleich. Da-durch muss auch der Betrag der Orthogonal-komponente gleich bleiben. Fur die Orthogo-nalkomponente sind deshalb nur zwei verschie-dene Moglichkeiten denkbar: die Orthogonal-komponente vor dem Stoß (dunner schwarzer

Pfeil) oder der Gegenvektor dazu (dunner roterPfeil). Somit erhalt man im Schwerpunktsys-tem die Geschwindigkeit nach dem Stoß (rot)indem man die ursprungliche Geschwindigkeit(schwarz) einfach an der Beruhrtangente spie-gelt.

Stoße im Koordinatensystem unseresSpiels

Wie kann man mit diesem Wissen nun die Stoßein unserem Spielfeld-System berechnen? Ganzeinfach: Man rechnet zunachst alles ins Schwer-punktsystem um, berechnet dort den Stoß undtransformiert schließlich wieder zuruck ins Sys-tem des Spielfeldes.

Zunachst rechnen wir also die Geschwindigkei-ten der Balle in unsrem Koordinatensystem indas Schwerpunktsystem um. Dazu subtrahiertman die Geschwindigkeit des Schwerpunkts vonden anderen Geschwindigkeiten.

Bewegung von zwei Ballen und deren Schwerpunkt

im”normalen“ Koordinatensystem

82


Bewegung von zwei Ballen im Schwerpunktsystem

Anschließend erfolgt die Berechnung der Ge-schwindigkeiten nach dem Stoß im Schwer-punktsystem.

Spiegeln der Geschwindigkeitsvektoren der Balle bei

einer Kollision an der Beruhrungstangente (Schwer-

punktsystem; gestrichelt die jeweils ursprungliche

Richtung)

Zum Schluss mussen wir die neuen Geschwin-digkeitsvektoren wieder in unser

”normales“ Ko-

ordinatensystem zuruckrechnen, indem mandie Geschwindigkeit des Schwerpunktes wiederzu den Ballgeschwindigkeiten hinzuaddiert.

AusblickWenke Grahneis

Was hatten wir gemacht, wenn wir noch mehrZeit gehabt hatten? – Eine Menge!

Nachdem wir alle die Grundlagen beherrschtenund die einzelnen Arbeitsgruppen eingeteilt wa-ren, wage ich zu sagen, dass es in jedem von unsangefangen hat

”rumzutraumen“. Ein richtig

professionelles Computerspiel, das man viel-leicht spater im Media Markt im Regal stehen

Bewegung der Balle nach der Kollision (Schwer-

punktsystem)

Bewegung der Balle nach der Kollision (”normales“

Koordinatensystem)

sieht. Okay, das ist jetzt vielleicht die Extrem-version, aber an Erweiterungsideen mangeltees sicher nicht. Zum Beispiel wollten wir inden vierten Level so etwas wie schwarze Lo-cher einbauen, die den Ball verschwinden las-sen, oder auch Blocke, die bei der Zerstorungdas Spielfeld fur einige Sekunden weiß werdenlassen (

”flash“), waren beim Level-Team im Ge-

sprach. Aber leider waren die zwei Wochen imNu vorbei und es hieß:

”Fertig werden, die Ab-

schlussprasentation steht an!“. Die letzten Ver-besserungen wurden noch getatigt, und dannstand sie, unsere Version 2.0. Das heißt abernicht, dass es nie eine Version 5.0 geben wird.Wir konnen jetzt ja programmieren (zumindestso grob) und hatten solchen Spaß dabei, dasses sich wahrscheinlich niemand nehmen lassenwird, unser

”Breakout“ zu Hause zu erweitern

und noch ein paar Special Features oder Goo-dies einzubauen. Denn nichts ist schoner, alswenn der Computer dann endlich macht, waser soll!

83

Documents

Kurs 4 { Pinball, Breakout & Friends · { an dieser Stelle noch mal ein Lob an ihre Willensst arke sich durch diese Thematik durchzubeiˇen. Larissa war zwar still, arbeitete aber