about

contacts

Pacman Entwicklungskonzepte

Definition – Was ist für uns der Pacman

In einer ersten Phase des Projektes, definierten wir, was der Pacman denn für Eigenschaften haben sollte. Dieser Abschnitt soll darüber Auskunft geben, was für uns der Pacman eigentlich ist.

Zunächst machten wir uns Gedanken, über die Eigenschaften, die der Pacman haben sollte. (Die Eigenschaft der Steuerung findet man in der Übersicht zunächst nicht. Sie ist eher als Kommunikations-Ergebnis zu verstehen und wird später ausführlich beschrieben).

• Aussehen: Es entstanden verschiedenste, Modelle, welche bei der Konstruktion des Pacman ausgewählt werden können. Damit wird dann eine TransformGroup erstellt, welche dann später in das Labyrinth integriert wird. Über das Pacman Objekt werden später die Positionen verändert und die Animationen gestartet.
• Punkte: Es gibt zwei Arten Punkte zu sammeln. Entweder durch das Aufsammeln von Items, oder aber durch das Umbringen eines Monsters. Nach einer Veränderung des Punktestands wird eine Nachricht, an das Labyrinth gesandt, welche den Punktestand dann visualisiert.
• Leben: Natürlich verfügt der Pacman auch über eine bestimmte Anzahl an Leben. Zu Beginn des Spieles wird er mit 5 Leben definiert. Wird der Pacman von einem Monster oder gegnerischem Pacman umgebracht, verliert er ein Leben. Durch das Aufsammeln entsprechender Items, kann sich die Lebensanzahl auch wieder erhöhen. Ähnlich wie bei der Punkteverwaltung wird auch hier bei einer Änderung eine Nachricht an das Labyrinth gesandt, so dass die Anzeige aktualisiert werden kann. Sind alle Leben aufgebraucht, so wird das Spiel beendet, auch in diesem Fall erhält das Labyrinth eine entsprechende Nachricht. Im Multiplayermodus existiert keine Einschränkung der Lebensanzahl. In diesem Fall werden die Anzahl der Tode gezählt.
• Inventar: Läuft der Pacman über ein Item, so versucht er zunächst es auszuführen. Ist es jedoch nicht ausführbar, so steckt er es in seine Taschen und hebt es für eine spätere Verwendung auf. Wie auch bei Punkten und Leben wird jede Veränderung dem Labyrinth mitgeteilt.
• Spielmodi: Schließlich besitzt der Pacman verschiedene Spielmodi. Zum einen ein Unverwundbarkeitsmodus, in den der Pacman nach Verwendung eines Items gerät. Des Weiteren existiert noch ein „Flugmodus“. Dieser wird durch das Labyrinth aktiviert, je nach dem, ob in einem Level Gravitation vorhanden ist, oder nicht. Ein letzter Spielmodus schließlich beeinflusst das Verhalten der Pacman untereinander. Entweder sie spielen miteinander, und beeinflussen sich nicht gegenseitig. Bei einem Spiel gegeneinander wird jeder gegnerische Pacman als feindlich angesehen und er kann ebenso wie Monster getötet werden.

Somit haben es alle geplanten Eigenschaften bis in die endgültige Spielversion geschafft. In späteren Abschnitten werden einzelne Eigenschaften noch ausführlicher beschrieben.

Steuerung

Dieser Abschnitt beschreibt die Entwicklung der Steuerung des Pacman. Dazu fällt sowohl die eigentliche Steuerung des Spielercharakters, als auch die Kommunikation mit weiteren Netzwerkspielern, dem Labyrinth und den Monstern.

Die Situation, in der sich der Pacman befindet ist die folgende. Der Pacman wird zu Beginn des Spieles an eine Position innerhalb des Labyrinths versetzt. Zusätzlich zur Position erhält der Pacman auch noch eine Blickrichtung, die angibt, in welche Richtung der Pacman zu Beginn des Spieles schaut. (Als weitere administrative Parameter wird auch noch angegeben, welches Modell geladen werden soll, und welcher Spielmodus gewählt wurde, darauf wird jedoch später noch genauer eingegangen).

An dieser Startposition angekommen, befindet sich der Spieler in einer diskreten Welt. Ihm stehen theoretisch 6 mögliche Richtungswechsel zu Verfügung:

• Bewegung nach Vorn,
• Bewegung nach Hinten,
• Bewegung nach Links,
• Bewegung nach Rechts,
• Bewegung nach Oben,
• Bewegung nach Unten,

Der Benutzer bekommt von der Kamera die nötigen visuellen Informationen, nach denen er die Entscheidung für die nächste Bewegungsänderung trifft. Nun gibt es zwei Möglichkeiten:

1. entweder der vom Benutzer gewählte Weg ist ungültig, und muss abgebrochen wird,
   (Dieser Fall tritt ein, wenn das Level zurückmeldet, dass die gewählte Zelle nicht begehbar ist.)
2. oder die Bewegung ist gültig und muss ausgeführt werden.

Doch wie geht nun das Auswählen einer gültigen Bewegung vonstatten? Und wie soll dieses animiert werden? Diese Fragen sollen im Folgenden behandelt werden.

Idee: das Message-Konzept

Aus dem Ansatz heraus, dass der Spielercharakter im Multiplayerspiel simultan auf mehreren Rechnern bewegt werden muss bestand die Notwendigkeit, die Eingaben vom Pacman zu trennen. Das von uns erdachte Modell sieht nun vor, dass der Tastatur-Handler[2] mit der ID des Pacman initialisiert wird. So können die entsprechenden Tastendrücke an den Pacman gesandt werden.

Neben den eigentlichen Bewegungsnachrichten gibt es jedoch noch andere Nachrichten, auf die der Pacman reagieren muss. So schicken die Monster eine Nachricht an den Pacman, um ihn zu töten. Ebenso schickt der Pacman auch Nachrichten an Monster oder gegnerische Pacman, sollte er sie gefasst haben.

Doch wie funktioniert nun die Steuerung über mehrere Rechner? Darüber soll mehr im nächsten Abschnitt geschrieben werden.

Multiplayer

Der Grundgedanke des Multiplayermodus, ist der, dass es zwei verschiedene Pacman-Arten gibt:

• Masterpacman und
• Schattenpacman

Der Schattenpacman ist eine leichte Abwandlung des „Masterpacman“. Er besitzt nur noch die Fähigkeit Bewegungsnachrichten zu empfangen, die Unverwundbarkeit anzuzeigen und schließlich noch die Sterbenachricht der Monster oder gegnerischer Pacman auszuwerten. Somit kann der Schattenpacman, keine Items einsammeln, oder benutzen. Darüber hinaus kann er auch keine Monster oder gegnerischen Pacman bekämpfen. Zu jedem Masterpacman existiert auf jedem Client, der an dem Spiel teilnimmt ein Schattenpacman.

Wird nun eine Taste gedrückt, so schickt der Tastatur-Handler eine Nachricht an die ID des für ihn registrierten Masterpacman. Diese Nachricht wird nicht nur lokal verschickt, sondern auch über das Netzwerk propagiert. Somit erhalten die Schattenpacman der anderen Rechner, welche dieselbe ID haben, wie der ursprüngliche Masterpacman die Nachricht. Auf diese Art bewegt sich der Pacman sowohl auf dem lokalen Rechner, wie auch auf allen angeschlossenen Rechnern.

Doch was geschieht bei mehreren ankommenden Nachrichten? Was passiert, wenn nicht genügend Zeit zum Abarbeiten einer Nachricht vorhanden ist. Darüber soll mehr im nächsten Abschnitt geschrieben werden.

Idee: Das Tick Konzept

In diesem Abschnitt soll der zeitliche Ablauf beschrieben werden. Der Pacman wird (wie auch die Kamera, die Monster oder auch das Labyrinth) von der zentralen Game-Instanz in unregelmäßigen Abständen mit einem Tick versorgt. Dieser beinhaltet die Anzahl der Update Schritte, nach dem letzten Aufruf.

Somit bestimmt also die zentrale Game Instanz der Labyrinth Gruppe über das Tempo und Verhalten des Pacman. Da sie auch Monster, die Camera und sich selbst mit Ticks versorgt, ist gewährleistet, dass kein Programmteil zu viel Zeit für sich in Anspruch nimmt. Mehr über das Tick Konzept wird man dann in der Dokumentation der Labyrinth Gruppe finden.

Am Beispiel des Pacman wird als nächstes beschrieben wie das Verarbeiten der Nachrichten funktioniert. Nachrichten werden übrigens unabhängig von einem bestimmten Tick empfangen. Der Grund dafür ist einfach der, dass die User-Eingaben asynchron kommen werden. Auch hier gibt es Unterschiede zwischen Master- und Schattenpacman. Der Masterpacman filtert die ankommenden Nachrichten in der Art, dass nur die neuesten Bewegungsnachrichten akzeptiert werden. Ein Schattenpacman auf der anderen Seite muss jede Nachricht, die er bekommt akzeptieren. (Er bekommt die Nachrichten vom Masterpacman, welcher sie schon gefiltert hat).

Wird nun der Pacman mit einer gewissen Anzahl von Ticks aufgerufen, so entscheidet er zunächst, ob eine Operation[3] schon begonnen wurde, oder nicht. Wurde eine Operation schon begonnen, so wird diese fortgeführt. Im anderen Fall wird eine Nachricht aus der Message-Queue entnommen. Aufgrund des Nachrichtentyps wird bestimmt, welche Tickanzahl benötigt wird, um die Operation abzuschließen. Dabei wird auch der Zeitpunkt bestimmt, zu dem das Labyrinth über den Eintritt in eine neue Zelle informiert werden muss. (Damit wird verhindert, dass Monster und Pacman ohne Schlagabtausch „durcheinander“ laufen.) Schließlich wird die Operation mit der zur Verfügung stehenden Tickzahl durchgeführt.

Wird die Operation erfolgreich beendet wird die behandelte Nachricht gelöscht.

Sollte der Fall eintreten, dass einmal keine Nachricht vorhanden sein sollte, so überprüft der Pacman, ob an seiner Position ein Item aufgetaucht ist, oder ob sich ein Monster nähert. Ist er im Kampfmodus, startet er dann einen Angriff.

Definition der Tasten

Für die Aktionen des Pacman wurden die folgenden Tasten vorbelegt[4]:

Weitere Tasten wurden von der Camera Gruppe definiert, darüber wird aber in der Dokumentation der Camera Gruppe genauer berichtet.

Modelle

Nachdem nun die Funktionsweise des Pacman dargelegt ist, soll nun noch auf die verwendeten Models eingegangen werden. Es wurden zwei verschiedene Arten von Models verwendet. Zum einen ein Modell, bei dem nur Java3D Primitiven verwandt wurden und zum anderen ein Modell, durch das Laden von 3D Modellen.

Jedes von uns verwendete Modell unterstützt zumindest zwei verschiedene Modi. Dies ist zum einen der Standard Modus, in dem der Pacman sich normal bewegt und zum anderen ein Modus, in dem der Pacman stirbt.

Modell durch Verwendung von Java3D Primitiven

Das erste Modell, das von uns erzeugt worden ist, besteht nur aus Java3D Primitiven. Im Standardmodus sieht man den Pacman wie im nebenstehenden Bild. Er besteht aus den folgenden Einzelteilen:

1. Gesicht auf linker Seite(bzw. auf rechter Seite)
   Das Gesicht wurde durch Verwenden eines TriangleFanArrays realisiert. Somit besteht das „runde“ Gesicht aus 26 Dreiecken. Die Fläche wird zweimal verwendet. Einmal zeigt die Normale in die positive Z Richtung, ein anderes Mal zeigt die Normale in die negative Z Richtung. Somit wird erreicht, dass die Fläche von beiden Seiten sichtbar ist.
   
   Dieses Gesicht wird nun durch Morphing animiert. So öffnet und schließt sich der Mund des Pacman.
2. Augen
   Auch die Augen entstanden durch verwenden eines TriangleFanArrays. Hier sind es 32 Dreiecke, die den Augen zu ihrem runden Aussehen verhelfen. Im Gegensatz zum Gesicht ist hier die Fläche geschlossen.
3. Körper
   Der Körper verbindet die beiden Seitenteile miteinander. (Eigentlich sind es 4, da jedes Seitenteil doppelt vorhanden sein muss, da es sonst nicht immer sichtbar ist. Siehe auch Erklärung unter 1.). Diese Verbindungen bestehen aus 26 Vierecken.
4. Skateboard
   Das „Skateboard“ auf dem der Pacman steht besteht aus einer Box.
5. Räder
   Für die Räder des Skateboards fanden schließlich 4 Zylinder Verwendung welche sich alle im die X Achse(als Rotationsachse) drehen.

Der Standardmodus bleibt solange sichtbar, bis der Pacman getötet wird. Geschieht dies, so erscheint die folgende Animation. Zunächst erscheint eine Flasche (im Folgenden auch Spiritbottle[5] genannt). Dann sieht man den Pacman, in der Flasche verschwinden.

Die Spiritbottle besteht aus den folgenden Einzelteilen:

1. Flaschenbasis: Als Basis wird ein Cylinder ohne Deckel verwendet, auf den eine Textur geklebt wurde.
2. Der Flaschenhals besteht aus einer transparenten Cone, die es erlaubt den Pacman auch noch in der Flasche zu erkennen.
3. Den Abschluss der Flasche bilden schließlich noch 2 weitere Zylinder.

Durch die reine Verwendung der Primitiven ergibt sich ein ziemlicher Geschwindigkeitsvorteil. Diesen Vorteil erkauft man sich jedoch mit einer komplizierteren Erstellung des Models. Der Grund dafür ist der, dass kein Tool verwendet werden kann, mit dem ein Modell erzeugt werden kann.

Modelle durch Verwendung eines Loaders

Alle Modelle, die wir durch einen Loader erstellen lassen, liegen entweder als 3DS oder als VRML Datei auf der Platte vor. Diese Modelle unterstützen 3 verschiedene Modi:

• zum einen der Standardmodus,
• einen Unverwundbarkeitsmodus
• und schließlich einen Sterbemodus

Im Standardmodus, sieht man den Pacman seine Füße bewegen, so dass der Eindruck des Laufens entsteht. Währendessen erscheinen im Unverwundbarkeitsmodus Schilde um den Pacman, die es keinem Gegner gestatten dem Pacman etwas anzutun. Im Gegenteil, sie verletzen sich nur selbst. Ein Modell wird etwas anders gehandhabt. Der Name dieses Modells ist „Moriya“. Dieses Modell ist mit einer Katana[6] ausgestattet und kann sich dank der seiner hervorragenden Kampftechnik gut genug Verteidigen, so dass es keine Schilde benötigt. Sollte es dennoch vorkommen, dass der Pacman von einem Monster erwischt wird, so wird er sterben. Dann sieht man den Pacman zusammenklappen.

Schnittstellen zu anderen Gruppen

Natürlich ist der Pacman nur ein Teil des gesamten Kuchens. Ohne die anderen Gruppen könnte er recht wenig, und würde wohl auch nie das sein, was er heute ist. In diesem Abschnitt soll es also um die Zusammenarbeit mit den anderen Gruppen gehen. Dazu wird auf jede der folgenden Gruppen kurz eingegangen:

• Labyrinth,
• Camera,
• Monster,
• Intro / Netzwerk

Labyrinth

Zuerst gilt es die Labyrinth Gruppe zu nennen. Ohne diese Gruppe gäbe es wohl keine Nachrichtenstruktur in der jetzigen Form. Darüber hinaus dient das Labyrinth als zentrale Anlaufstelle für alle Interaktionen mit den anderen Gruppen.

Das beginnt schon mit der Erzeugung des Pacman. Da die Labyrinth Gruppe auch die eigentliche Spielinstanz erschafft bleibt es nicht aus, dass sie auch den Pacman nach den Introvorgaben erzeugen und dafür sorgen, dass im Multiplayerspiel der Pacman auch auf allen verbundenen Rechnern erscheint. Auch danach steht der Pacman in ständigem Kontakt mit dem Labyrinth. Entweder sendet er die jeweiligen Positionen, oder die Punkteanzeige muss aktualisiert werden. Um sich der Camera zu bedienen muss der Pacman auch den Umweg über das Labyrinth gehen, da er sonst die Instanz der Camera nicht kennen würde.

Camera

Eine Zusammenarbeit mit der Camera Gruppe gab es in den folgenden zwei Punkten. Zum einen war es notwendig, dass die Kameraansichten verändert werden. Dafür wurden einige Nachrichten vereinbart, die bei entsprechendem Tastendrücken gesandt werden. Auch hier soll wieder auf die Dokumentation der Kameragruppe hingewiesen werden.

Die Aufgabe der Camera Gruppe war es auch verschiedene Effekte zu Entwickeln. Ein Effekt, der in der endgültigen Version des Spiels enthalten ist, ist das Beben. Mit anderen Worten, die Camera fängt an zu Schwingen. Dieser Effekt findet seine Anwendung bei einem Ableben des Pacman.

Monster

Natürlich war auch eine Zusammenarbeit mit der Monster Gruppe notwendig. Hierbei ging es hauptsächlich um den gegenseitigen Schlagabtausch. Dabei einigte man sich auf eine Bestimmte Art von Nachrichten, die den Pacman bzw. das Monster zum sofortigen Ableben bringen. Um allerdings an die genaue ID und Position eines Monsters oder Pacman zu kommen, war eine Anfrage an das Labyrinth notwendig, welche als zentrale Anlaufstelle auch diese Informationen verwaltete.

Intro / Netzwerk

In Zusammenarbeit mit der Intro und Netzwerkgruppe entstand die Pacman Auswahl, wie sie in der aktuellen Version zu finden ist. Leider fanden nicht alle Features auch Verwendung in der endgültigen Version. So gab es Schnittstellen zur Darstellung einer Voransicht des gewählten Pacman. Auch wäre es möglich gewesen die Tastatursteuerung an die persönlichen Wünsche anzupassen.

Probleme

Natürlich treten in einem solchen Projekt immer wieder auch kleinere und größere zumeist aber zeitraubende Probleme auf. In diesem Abschnitt soll eine Auswahl dieser Probleme besprochen werden.

GELÖST: Interpolieren eines Vektors

Das erste Problem zeigte sich schon in einer recht frühen Praktikumphase. Die Situation war die folgende. Es gab eine erste Version von Camera, Labyrinth und Pacman. Die optimale Vorraussetzung, um die ersten Laufversuche durchzuführen. Das Ergebnis zeigte eine Linksdrehung um 90° wie beabsichtigt. Auch die Kamera drehte sich um 90°, so dass keine Grafikeffekte zu beobachten waren. Dann kam die Rechtsdrehung. Auch hier drehte sich der Pacman um 90° nach rechts und schaute in die richtige Richtung. Doch die Drehung der Camera zeigte, dass sich der Pacman in Wirklichkeit um 270° nach Links drehte, anstatt 90° nach Rechts. Ein kleiner Fehler der sich jedoch nicht einfach zu lokalisieren war. Es zeigte sich schließlich, dass die von Java3D implementierte Funktion zum interpolieren eines Vektors zum nächsten nur nach der Funktion

(1-α)v1 + αv2

realisiert. Nachdem die Ursache gefunden war, half schließlich endlich langes Nachdenken, um eine Lösung zu finden. (Zwischenzeitlich kam man mal auf die Idee eine Kreisgleichung mittels Sinus und Kosinus zu beschreiben und dann …). Die letztendliche Lösung gestaltete sich recht einfach. (Man muss sie eben nur kennen):

(1-α)v1 - αv2

Aber das war sicherlich nicht das letzte aufgetretene Problem.

GELÖST: Das Problem der Beleuchtung

Die Verwendung der 3D Models war zwar schön und gut, doch nach einem ersten Laden der Models in das Labyrinth, sah man nur, dass man nichts sah. Das mit viel Liebe erstellte Modell war im Großen und Ganzem nur noch schwarz. Und das trotz ambienter Lichtquelle. Das Problem schien sich einfach Lösen zu lassen. Man fügte einfach eine direktionale Lichtquelle ein, und hoffte auf das Beste. Doch hier zeigte sich dann, dass unterschiedliche Grafikkarten die Lichtquellen unterschiedlich stark in Betracht zogen. Und so waren die Modelle natürlich zu hell. Ein Umsteigen auf Punktlichtquellen, und ein Wechseln des Dateiformats von 3DS auf VRML brachte schließlich das gewünschte (und endgültige) Ergebnis.

OFFEN: Weichheit der Bewegungen des Pacman

Seit dem wir von der PacmanGruppe zum ersten Mal gesehen hatten, wie flüssig sich die Monster bewegen können hatten wir daran gearbeitet die Bewegung des Pacman ebenso flüssig zu gestalten. Dazu wurde ein erstes Bewegungskonzept, welches darauf beruhte, den genauen Pfad zur nächsten Zelle schon vorzuberechnen, verworfen. Das aktuelle Modell berechnet zu jeder Anzahl der bekommenen Ticks die Position, an welcher der Pacman sein müsste und setzt ihn dahin. Doch nach welchem Modell man sich auch bewegte immer schien es nach der Hälfte des Weges zu ruckeln. Erst der funktionierende Netzwerkcode und damit das testen der Schattenpacman hat aufgezeigt, warum das der Fall war. Der Grund ist der folgende, anders als die Monster, die einen Pfad mit einer Länge von mehreren Zellen ablaufen, läuft der Pacman immer nur den Weg von einer Zelle zur nächsten. Auf dem halben Weg jedoch teilt er zunächst dem Labyrinth den Eintritt in die neue Zelle mit, und danach beginnt er die Items der neuen Zelle einzusammeln(oder zu benutzen). Natürlich muss beim Eintritt in eine neue Zelle auch überprüft werden, ob sich nicht ein Monster oder ein gegnerischer Pacman in ihr befindet, die es zu vertreiben gilt. Erst danach kann die Bewegung fortgeführt werden.

Schlussworte der Praktikumsteilnehmer

In diesem Abschnitt sollen nun noch mal alle Mitglieder der Pacman-Gruppe zu Wort kommen. Auf diese Art hat jeder noch mal die Chance die Eigenen Gedanken zum Praktikum loszuwerden. So stay tuned...

Frank Bergmann

Der ursprüngliche Grund an diesem Praktikum teilzunehmen, war es, die Funktionsweise eines Modellierungssystems näher zu erlernen. In der Beschreibung im Semester davor hieß es genauer, dass 3DS Max[7] verwandt werden sollte. Umso größer war dann meine Überraschung, als ich mitbekam, dass der uns zur Verfügung stehende Modellierer Rhinoceros[8] sein sollte. Der Grund dafür war eine einfachere Lernbarkeit. Nur war das nicht ganz das, was ich wollte. Also bemühte ich mich in den Treffen unserer Gruppe schon früh um eine klare Aufteilung der Aufgaben. Christoph Karwoth kümmerte sich fortan um die Modellierung und Erzeugte all die Modell, die über den Loader eingeladen werden konnten, inklusive der netten Animationen im Kampfmodus, oder beim Dahinscheiden des Pacman. Darüber hinaus schrieb er die Basisklasse für die Verwaltung der Pacman-Informationen. Jihua Xu bekam die Arbeit des Erstellens weiteren Models aus den Java3D Primitiven. Später hatte er dann die Basisklasse zum Abspielen der Sounds geschrieben. Nach dieser Aufteilung entstand das Message Konzept. In enger Zusammenarbeit mit der Labyrinthgruppe gab es dann auch recht schnell eine erste Version eines Pacman. Die nächste Zeit ging es dann um die Überlegung, was man denn nun mit den ganzen eintreffenden Meldungen macht. Eine erste Version arbeitete einfach alle Messages nach dem FIFO Konzept ab. Dies war jedoch nicht allzu gern von den Leitern des Praktikums gesehen, da es so möglich wäre ganze Wegstrecken, durch schnelles Tippen schon zu pre-buffern. So entstand dann eine Mischform. Bewegungsnachrichten[9] werden gefiltert, so dass nur noch die aktuellste Nachricht beachtet wird, andere Nachrichten werden jedoch nach wie vor nach dem FIFO Modell bearbeitet. Auf diese Art ist nun das Pre-buffern nicht länger möglich. Nachdem dieses Problem aus der Welt geschafft war trat das Problem mit den Drehungen auf, welches oben schon beschrieben wurde. In dieser Phase entstanden etliche neue Verfahren, den Pacman zu drehen. Da ich keine Möglichkeit hatte aus einer gedrehten TransformGroup den Blickwinkel des Pacman abzuleiten, brauchte ich neben der eigentlichen Drehung der TransformGroup noch eine Interpolation für den Blickwinkel, den die Camera benötigt. Schließlich benötigte dann noch die Öffnung des Pacman gegenüber dem Intro noch einige Arbeit. Leider sind die dafür erstellten Features einer Voransicht des gewählten Pacman, oder weitere möglichen Parameter nicht in der endgültigen Version erschienen. Soweit der Rückblick über die Arbeit am Praktikum.

Nun aber erst einmal ein Wort des Dankes an alle Praktikumteilnehmer. Es ist schon erstaunlich, was wir da geschaffen haben. Ein Dank natürlich auch an unsere Praktikumleitung, die es uns ermöglichte weitgehend ungebremst etwas auf die Beine zu stellen. Besonderen Dank vor allem auch nochmals der Labyrinth-Gruppe, die in einigen Nachtstunden dafür gesorgt haben, dass der Pacman so stabil im Game verankert ist.

Zusammenfassend lässt sich sagen, dass die Arbeit am Praktikum sehr viel Spaß gemacht hat. Es war interessant mal etwas anderes zu programmieren. Wenn ich etwas an diesem Praktikum gelernt habe, dann den engen Zusammenhang von 3DSpiele-Entwicklung und Linearer Algebra. Im Nachhinein hätte man die Lösung der Aufgabe natürlich noch weiter Planen können, die Phase des Programmierens hat einfach zu früh begonnen. So, jetzt habe ich aber genug geschrieben, vielleicht sollte ich noch ein paar Sachen am Pacman feilen … wäre doch gelacht, wenn wir keine weichere Animation des Pacman hinbekommen würden.

Christoph Karwoth

Es war früh und der Nebel löste sich langsam auf, als sich unsere Gruppe kurz nach Mittag zum Brainstorming versammelte. Das ging nur mühselig voran, bis wir uns einen Kaffee geholt haben. Der war auch unser ständiger Begleiter. Schon am ersten Tag entstanden viele Picassos und andere Zeichnung, die uns noch sehr lange beschäftigten. Viele Bäume mussten dran glauben, bist wir endlich Strom vergeudeten konnten und auch das kunstvolle Gekritzel dechiffrieren mussten. Doch davor mussten wir uns in der GDV-Kongresshalle mit den anderen Treffen. Diese Debatte war vom großen Vorteil. Alle Parteien waren vertreten. Alle haben ihre Schnittstellen enthüllt und alle hatten eine Vision von voll 3-D animierten Pacmen, der Hechtrollen á la Tomb Raider macht, beamen und schissen wie die in Star Treck kann und ein Intro á la Herr der Ringe besitzt. Die Netzwerkstruktur sollte die Telekom Aktie noch weiter in den Keller treiben. Die Kameraführung sollte Spielberg zum Staunen bringen und Labyrinthe, die Schumacher aus Geschwindigkeitsgründen und Kurvenreichhaltigkeit fürchten würde. Und das war nur der Anfang, aber jeder fängt ja klein an.

Erstaunlicherweise haben wir nach wenigen Stunden dem Pacman das Laufen beigebracht. Wir hatten ihn zwar ins Verlies (durch Leveldesign) gepackt, aber er machte sich nichts draus. Mit lachendem Gesicht erkundete er jede Ecke. Teilweise wie Copperfield, konnte er durch die Mauern spazieren. Dies haben wir ihm aber sehr schnell abgewöhnt, da er ja irgendwann feststecken könnte.

Durch die Mailliste und CVS war unsere Kommunikation auch in jedes Dorf möglich, so als ob alle in einem Raum saßen. Man hatte beinah Patzangst.

Lifting vom Pacman hat uns unzählige Kaffeetassen gekostet. Er wurde immer besser. Auch das Designen von der Behausung des Pacman ging auch durch den feinen Leveleditor großartig. Es schien alles sich zum Besten zu wenden, doch das Ungeziefer (Monster) breitete sich aus. Das Kammerjägergeschäft boomte. Fast jeder hat einen Gefangen. Leider wie man es aus unsere Branche kennt, kann man nicht alle ausmerzen. Die Jagt geht also weiter.

Es war ein tolles Praktikum.

Jihua Xu

Vor einem Jahr habe ich das Plug-In für VRML herunter geladen, um die Struktur und die Syntax von VRML kennen zu lernen. Ich kam zu dem Schluss, dass zwar sehr schöne Objekte erzeugen kann, es aber zu aufwendig für komplexe Objekte ist. Da Java3D ähnlich zu VRML ist, hatte ich Zweifel an der Kompetenz der Programmiersprache in diesem Bereich. Nachdem ich einige sehr beeindruckende Szenen der GDV-Übungsaufgaben gesehen hatte, hatte ich große Interesse daran, in diesem Semester an dem Praktikum teilzunehmen um eine Antwort auf die Frage, wie man effizient komplexe Objekte erzeugen kann, zu finden. Im Laufe des Praktikums verwendeten wir dann das Modellierungsprogramm Rhinoceros. Die Möglichkeit die Modelle zu exportieren und mittels eines Loaders in Java zu integrieren, überzeugte mich.

Vor dem Praktikum habe ich noch nie an einem größeren Projekt mitgearbeitet. Ich hatte zwar mit jemandem zusammen in einer Gruppe programmiert, durch strikte Aufgabenteilung war jedoch nicht zu viel Kontakt nötig. In diesem Praktikum: Java3D und VRML lief das anders. Sowohl eine Mailingliste als auch CVS wurden intensiv genutzt, und somit war ein besseres Zusammenarbeiten möglich. Ich erfuhr somit, wie sich eine abstrakte Problemstellung hin zu einer Lösung entwickelt.

Meine Aufgabe in der Gruppe war es einen Pacman zu modellieren. Am Anfang nutzte ich dazu die Eigenschaft Billboard, welche es ermöglichte einen zweidimensionalen Pacman zu erzeugen. Jedoch war dieser Ansatz noch nicht sehr schön. Als ich sah, dass Christoph mittels eines Loaders ein schönes Modell ins Spiel gebracht hat, dachte ich, dass ich lieber mit den Java3D Primitiven arbeite, statt wieder ein Modell mit Hilfe von Rhinoceros zu erschaffen. Somit sammelten wir Erfahrungen bei der Modellierung von beiden Seiten (Modellierung mittels Modeller und Erstellung eines Models mittels Primitiven).

Zum Schluss danke ich allen, für ihre Mithilfe am Praktikum.