Diese Studienarbeit baut auf der Arbeit von Tim Steffens [Ste05] auf. Bei seiner Studienarbeit handelt es sich um ein System zur einfachen Präsentation handschriftlicher Lehrinhalte mittels eines Tablet PCs und eines Beamers. Im Wesentlichen wird das Beschreiben von Folien und deren gleichzeitige Projektion mit einem Overheadprojektor ersetzt. Das Programm, welches aus der Studienarbeit Tim Steffens hervorgegangen ist, enthält Mängel in der Programmierung und im Entwurf aus softwaretechnischer und -ergonomischer Sicht. Diese Mängel reichen von ungünstig gewählten Schaltflächen über ein immer langsamer werdendes System bis hin zu Abstürzen während des laufenden Betriebs. Meine Studienarbeit soll dieses System genauer analysieren, bestehende Fehler korrigieren und gleichzeitig das gesamte System nach neuen Anforderungen umgestalten.

Interact is an interactive 2D physics based game that can be controlled via the Nintendo Wiimote.

Rechnernetze gehört zu den Fächern, die ein breites Spektrum an Anwendungsgebieten abdecken. Die vielen unterschiedlichen Protokolle sind Belege dafür. Jedes Protokoll hat sozusagen ein eigenes Anwendungsbereich und doch sind deren Aufgaben unter dem Nenner gleich. Miteinander zu Kommunizieren, Informationen auszutauschen und das möglichst auf eine sichere und schnelle Art und Weise. Als Beispiel denke man an Autos, Handys, Lokale Netze in einem kleinen Betrieb, Intranet in einer größeren Organisation oder in Netze die über Länder hinweggehen. Ein modernes Auto an sich hat schon eine Vielzahl an Bussystemen in sich integriert. CAN, LIN, FlexRay oder MOST Bus sind ein paar Stichworte dazu. Wenn man jetzt von der Autoindustrie weggeht und an die Autonomen Systeme kommt, gibt es dort ein Routing Information Protokoll, das innerhalb von Autonomen Systemen verwendet wird. Routing Information Protokoll ist eines der meist verwendeten Protokolle innerhalb von Autonomen Systemen. Das Routing Information Protokoll ist einer der zentralen Bestandteile des Forschungsbereiches der AG Steigner. Die Arbeit widmet sich unter Anderem dieser Forschungsunterstützung.Diese Studienarbeit hat das Ziel die Testumgebung XTPeer auf die VNUML Version 1.8 zu integrieren.

Für die Netzwerkprogrammierung hat sich auf breiter Front das Socket API nach Vorbild der Berkley Sockets durchgesetzt. Die "normalen" Sockets in Form von Stream- oder Datagram-Sockets erleichtern zwar die Programmierarbeit, verschleiern jedoch auch zahlreiche Details der Netzwerkkommunikation vor dem Programmierer. So ist man beispielsweise auf die Nutzung der Protokolle TCP oder UDP eingeschränkt und agiert zwangsläufig bereits auf dem Application-Layer des TCP/IP Referenzmodells. Für den Zugriff auf tiefer gelegene Netzwerkschichten, d.h. für den Zugriff auf die Headerdaten eines Netzwerkpaketes, hält das Socket API die sogenannten RAW Sockets bereit. Mit ihnen ist es möglich, alle IP Pakete inklusive Headerdaten zu lesen oder von Grund auf neu zu generieren. Hiermit ist es nun auch möglich, Protokolle zu verwenden, die dem Anwendungsprogrammierer bislang nicht zugänglich waren (z.B. ICMP oder OSPF) oder sogar eigene IP basierte Protokolle zu entwickeln. RAW Sockets stoßen an ihre Grenzen, wenn es darum geht auf den Data-Link-Layer der Netzwerkkommunikation zuzugreifen. Unter Linux gibt es hierfür einen weiteren Socket-Typ: Den PACKET Socket. Die Studienarbeit möchte einen Einstieg in die Programmierung mit den eher unbekannten RAW und PACKET Sockets schaffen. Dabei werden einige Beispielprogramme vorgestellt und mögliche Anwendungsgebiete aufgezeigt.

Ziel dieser Studienarbeit war es, Erfahrungen in der Grafik- und Spieleprogrammierung zu sammeln. Als Grundidee kam dabei die Erstellung eines 3-dimensionalen Terrains auf. Solche Terrains werden heutzutage nicht nur in der Spielebranche eingesetzt, wo sie in beinahe jedem Genre vertreten sind, sondern auch z.B. in der Geologie zur Erstellung von Simulationen von Plattentektonik. Die simple Erstellung eines 3-dimensionalen Terrains wäre für eine Studienarbeit jedoch zu trivial, daher sollte das Terrain spezielle Anforderungen erfüllen. Zum einen sollte das Terrain dynamisch erzeugt werden, d.h. der Benutzer des Programms hat Einfluss darauf, wie sich das Terrain entwickelt. Dies sollte vorzugsweise spielerisch eingebracht werden. Zum anderen sollte das Terrain zufällig generiert werden. Dies bedeutet, dass keine vormodellierte Landschaft genutzt, sondern jede Erhebung/- Vertiefung des Terrains mittels Zufallsfaktoren erzeugt werden sollte. Zusätzlich sollte das Terrain endlos erzeugt werden. Bei einer Bewegung über das Terrain sollte also niemals ein Ende erreicht werden. Also auch keine Kreistrecke, sondern ein wirklich endloses und stets anders aussehendes Terrain. Desweiteren sollte es dem Benutzer møglich sein, ein Fluggerät über das Terrain zu steuern. Dies gab dann auch die Chance, aus der oben genannten dynamischen Anforderung ein spielerisches Element zu machen, indem der Benutzer das Terrain durch Einsammeln von sogenannten TerraformItems beeinflussen kann. Die Steuerung eines Fluggerätes spielt auch für die geforderte Endlosigkeit des Terrains eine wichtige Rolle, da diese ohne eine Möglichkeit der Fortbewegung gar nicht nachprüfbar wäre. Das Problem mit der Endlosigkeit ist dabei, dass kein System endlosen Speicher zur Verfügung hat um das Terrain komplett zu speichern und dem Benutzer somit die Option zu bieten, die gleiche Strecke zurückzufliegen. Eine Lösung für diese Problematik wäre bei einer Kehrtwende das Terrain auch rückwärts wieder neu zu generieren. Der Einfachheit halber sollte stattdessen ein komplette Kehrtwende einfach nicht zugelassen werden. Eine Kollisionserkennung musste dann natürlich auch implementiert werden. Zum einen weil das Fluggerät ja nicht einfach wie ein Geist durch das Terrain hindurchgleiten sollte, zum anderen muss das Programm ja irgendwie das Einsammeln der oben angesprochenen TerraformItem-Objekte registrieren können. Weitere Objekte wie Bäume oder Felsen sollten das Terrain optisch aufwerten. Zu guter Letzt sollte noch eine simple Benutzeroberfläche erstellt werden, um dem Benutzer diverse Bedienelemente und Rückmeldungen zu bieten. Damit sollte es z.B. auch möglich sein dass Terrain direkt zu verändern.