Projekt: Lambda

Aus toolbox_interaktion
Wechseln zu: Navigation, Suche
Lambda 0.jpg

Unsere Idee war, ein virtuelles Paintball-Spiel zu programmieren, bei welchem der Spieler durch Interaktion ein individuelles Medienerlebnis erfährt. Der Spieler steht vor einer Leinwand, auf die eine 3D-Welt mit einem Beamer projiziert wird. Abhängig von der Position des Spielers im Raum vor der Leinwand ändert sich die Perspektive der dargestellten 3D-Landschaft. Die Position des Spielers wird mit zwei Kameras erfasst und aus den Kamerabildern wird die 3D-Koordinate berechnet. Diese 3D-Koordinate wird zur Weiterverarbeitung an die 3D-Engine übergeben. Für den Schuss wird eine Infrarot-Laser-Pistole gebaut, die auf der Leinwand einen unsichtbaren Punkt erzeugt. Eine IR-Kamera zeichnet den Laserpunkt auf der Leinwand auf und übermittelt ihn ebenfalls an die 3D-Engine.




Bildverarbeitung

Hardware

Komponenten

Hardware Anwendung
  • 2x Webcams
  • IR - Laserpistole
  • Infrarotkamera
  • Beamer
  • Leinwand
  • Shuttle PC
  • 3D Koordinatenermittlung
  • Schuss
  • Laserschusserkennung
  • Projektion der 3D-Spielumgebung
  • Projektion der 3D-Spielumgebung
  • Verarbeitung der Daten


Halterungen und deren Modifikationen

Um nun diese Komponenten in ihrem Zweck so anzubringen, dass es ohne den Spieler in seinem Aktionsradius zu stören, möglich ist die verschiedenen benötigten Daten zu ermitteln wird ein Stangensystem Namens „Stolmen“ von einem allg. bekannten schwedischen Möbelhersteller verwendet.

Um nun Beamer, IR-Kamera und Webcams dort zu befestigten, werden ein paar technische Modifikationen vorgenommen.

Webcam- und Beamerhalterung


Laserpistole

Da entschieden wurde, dass die Waffe einen Infrarot Laserstrahl schießt, musste nun überlegt werden, wie dies realisiert werden kann und wie sie konstruiert wird. Das war die Aufgabe der Bildverarbeitungsgruppe. Es musste ein geeignetes Gehäuse gefunden werden, in dem der Infrarot Laser integriert wird. Wichtig war, dass ein Taster zum Auslösen des Schusses und ein Ein/Aus Schalter vorhanden sind.


Schaltung

Da der Laser nur mit einem Kabel geliefert wurde, musste eine Schaltung her. In dieser Schaltung müssen der Taster und der Schalter integriert sein. Mit einem Potentiometer wurde die Anzahl der auslösbaren Schüsse bestimmt. Begrenzt wurde es auf einen Zeitraum von circa 60ms. Die Schaltung zusammengebaut und entworfen hatte ein Experte dieses Faches. Aufgrund dieses Vorteils musste die fertige Schaltung nur noch in die Wasserpistole eingebaut werden.

Laserpistole mit Schaltung

Spielfeldaufbau

Die verschiedenen Komponenten werden wie folgt im Spielfeld platziert:

Kameras, für die Koordinatenerkennung wichtig, befinden sich rechts und links neben der Leinwand. Da die Kamera nur einen begrenzten Öffnungswinkel hat, muss das Spielfeld auf ein Trapez gestaucht werden, da sonst nicht alle Information aufgenommen werden können.

Das Spielfeld, ca. 3x3 m groß, befindet sich 3,5 m von der Leinwand entfernt. Da Beamer und IR-Kamera nebeneinander stehen sollten, um der IR-Kamera zu ermöglichen auch das gesamte projizierte Bild aufzunehmen, werden diese Komponenten direkt über dem Spielfeld positionierten.

Spielfeld

Roterkennung

Das Erfassen des Spielers erfolgte über ein markantes Merkmal, das sich von der Umgebung unterscheidet. Es gab Überlegungen Leuchtdioden einzusetzen, doch entschieden wir uns für die Verwendung eines roten Käppis, denn wie folgend beschrieben ist, waren die Ergebnisse der Rotdetektion völlig ausreichend. Man kann im Programm Eyesweb Patches zusammenbauen - ein Patch gleicht einem kompletten Datenfluss von der Eingabe über die Verarbeitung bis hin zur Ausgabe. Die einzelnen (Verarbeitungs-)Schritte können mittels verschiedener Blöcke durchgeführt werden. Der unten gezeigte EyesWeb-Patch lambda_rotverfolgung.eyw ist im internen Bereich zum Download abgelegt.

Die Aufnahme des Bildes erfolgt über die zwei Webcams und wird in Eyesweb jeweils über ein Framegrabber-Modul (Block) erfasst, in dem auch Einstellungen wie Kameraauflösung und Framerate festgelegt werden können. Weiterhin bezieht sich die Erläuterung nun auf den Ablauf mit nur einer Kamera, denn er ist für beide Kameras identisch.

Eyeswebpatch zur Roterkennung

Nach dem Erfassen des Kamerabildes wird das RGB-Bild in das HSV-Farbmodell konvertiert, denn interessant sind nur die Farben und Sättigung der einzelnen Pixel und keine Rot-, Grün- oder Blauanteile. Aus dem HSV-Bild wird nun nur der HUE-Kanal ausgewählt, der als Grauwert dargestellt wird, wobei rote Pixel als schwarze oder weiße Pixel dargestellt werden – Grund hierfür ist ein Umbruch des Spektrums in diesem Bereich. Dazwischen liegt das komplette Farbspektrum, also als Grauwerte. Die interessanten roten Farbwerte sind aber nur die, die in Richtung Schwarz tendieren. Mit einem passend gewählten Schwellwert (Schieberegler) werden die uninteressanten Farben des Farbspektrums größtenteils minimiert bzw. herausgefiltert. Dabei erhält man also die schwarzen Pixel, die mit einem Not-Operator in weiße invertiert werden. Mit einem Opening, einer morphologischen Operation, können Rauschen und übrig gebliebene andere Farben vermindert oder sogar eliminiert werden.

Um ein zuverlässiges Ergebnis zu erzielen, werden neben Farbwert zusätzlich die Sättigungswerte behandelt. Auch hier kann ein geeigneter Schwellwert, den situationsabhängigen Lichtverhältnissen entsprechend, mit einem Schieberegler festgelegt werden. Durch eine pixelweise Verknüpfung mit einem Und-Operator erhält man nun ein Binärbild, das satte rote Farben als weiße Pixel zeigt.

Dieser detektierte Bereich, also das rote Käppi, muss für weitere Vorgehensweisen in Form von Koordinaten (2D) ausgegeben werden. Mit dem Baricenter-Block kann der Schwerpunkt dieses Bereichs ermittelt werden.

Eine Glättung – ein zeitliche Mittelung – der X- und Y-Koordinaten vermindert „zitternde“ Werte, die üblicherweise auftreten. Abschließend können die 2DKoordinaten der beiden Kameras ausgegeben werden.

Lasererkennung

Um dem Spieler überhaupt zu ermöglichen, auf die Leinwand zu schießen, wird eine Laserpistole benutzt. Da das Beamerbild keine Infrarotanteile besitzt, wird es quasi für die IR-Kamera unsichtbar. Somit ist es möglich den Schuss zu detektierten, ohne zusätzliche Hintergrundinformationen der 3D-Anwendung zu erhalten, was die Binarisierung um einiges erleichtert (näheres dazu später).


Schusskoordinatenerkennung

Wie schon erwähnt, setzt sich die Erkennung des Schusses hauptsächlich aus einer normalen Binarisierung zusammen. Anhand eines variablen Schwellwertes S, lässt sich der Laserpunkt gut herausfiltern.

Um nun die Koordinaten des Punktes zu erhalten, wird nun noch der Mittelwert der Fläche errechnet und dessen x- und y- Koordinaten ausgegeben.

Laserpunkt vor und nach Binarisierung

Problem hierbei ist nur, dass das Kamerabild der IR-Kamera größer ist als das vom Beamer projizierte Bild, was es schwierig macht die Koordinaten auf die 3DAnwendung zu mappen.

Region of Interest Um das gerade genannte Problem zu lösen, gab es im Endeffekt zwei Varianten. Das Grundprinzip bestand einfach nur daraus ein umschreibendes Rechteck“ festzulegen was auf das projizierte Bild des Beamers passt, um dann nur in diesem Rechteck Koordinaten auszugeben.


Variante 1:

Active Area, ein in Eyes Web erstellter Block speichert die Daten eines Rechtecks, wobei hierfür die einzelnen Koordinaten des linken, oberen Eckpunkts und des rechten, unteren Eckpunkts verwendet wird. Die benötigten Informationen erhält man durch die Extraktion der einzelnen Koordinaten eines in einem Click- Display erstellten Rechtecks, das das Beamerbild umschließt.


Umschreibendes Rechteck

Umständlich hierbei ist, dass durch den IR-Filter das Beamerbild nicht zu erkennen ist. Um nun den oberen, linken Punkt und den unteren, rechten Punkt zu markieren, muss man diese auf eine andere Art und Weiße sichtbar machen.


Variante 2:

In der endgültigen Ausführung umgeht man die Erstellung des Blocks indem die Differenz der Koordinaten des linken, oberen Punktes des Rechtecks und den ermittelten Koordinaten des Punktes im Originalbild bilden. Diesen Wert werden die Breite bzw. Höhe des umschreibenden Rechtecks geteilt, um jeweils für x und y relative Werte zu erhalten.

Dies ist wichtig um später in der 3D-Anwendung diese relativen Werte mit der Breite bzw. Höhe, also der Auflösung des Beamerbildes zu multiplizieren um den genauen Punkt im Spielbild festlegen zu können. Somit kann der Schuss fast auf den Pixel genau, auf die 3D-Anwendung gemappt werden.

Der unten gezeigte EyesWeb-Patch laser-extract1.eyw ist im internen Bereich zum Download abgelegt.

Eyesweb Programmierung

3D-Positionsberechnung

Die wohl größte Hürde bei der Interpretation der von der Bildverarbeitung gelieferten Daten bestand darin, aus den zwei Kamerabildern der Webcams die 3DKoordinaten des Spielers zu berechnen, der mit einer roten Basecap markiert war.

Es ist es wichtig, dass die Bilder der beiden Kameras einigermaßen synchron beim Bildverarbeitungsprogramm eintreffen. Wird der zeitliche Versatz zu groß, so dass der Spieler sich zwischen dem Eintreffen des linken und des rechten Kamerabildes merklich bewegt hat, so ist das Ergebnis der Berechnung ungenau und nicht vorhersehbar. Glücklicherweise hatten wir aber mit diesem Problem auf unseren produktiv eingesetzten Rechnern nicht zu kämpfen. Andere getestete PCs kamen mit den über USB einströmenden Daten nicht klar und so war der Versatz teilweise enorm.

Wichtig bei der Betrachtung ist immer auch die Wahl des zugrunde liegenden Koordinatensystems. Um Spieler und Kamerapositionen gleichermaßen mit positiven Koordinaten versehen zu können haben wir uns für folgende Festlegung entschieden:

Koordinatensystem

Als Basis für die Berechnung entschieden wir uns für das Prinzip der Disparität:


Disparität

Bei zwei nicht geneigten und parallel sehenden Kameras kann man – vorausgesetzt man kennt zwei korrespondierende Bildpunkte in den Kamerabildern – den Abstand des Urpunktes zu den Kameras mit folgender Formel berechnen:

Formel 1

Lambda 9.png

B - Stereobasis (Abstand der Kameras zueinander)

f - Brennweite der Kameras

d - Disparität (Abstand der Bildpunkte in linkem und rechtem Kamerabild)

z - Tiefe des Raumpunktes


Das Prinzip dieses Ansatzes ist also folgender: Je weiter entfernt sich ein Raumpunkt von den Kameras befindet, desto weniger weichen die x-Koordinaten dieses Punktes in den Kamerabildern voneinander ab. Je näher er ist, desto unterschiedlicher werden die x-Koordinaten. Verrechnet man das mit der Brennweite und der Stereobasis, so bekommt man einen Wert für die Entfernung des Punktes.

In [I1] steht noch der Hinweis, dass es in der Regel schwer ist, aus zwei Kamerabildern jeweils korrespondierende Punkte für diese Berechnung zu finden. Mit unserer Markierung und der Roterkennung wäre das allerdings ein verhältnismäßig leicht lösbares Problem.

Doch wir sind mit dieser Formel im Hinblick auf unser Projekt trotzdem nicht glücklich. Zum einen funktioniert dieses Verfahren bei kleiner Stereobasis nur gut, wenn die Disparität groß, also der Abstand des zu trackenden Gegenstandes zu den Kameras klein ist. Bei uns ist der Abstand aber aufgrund der Spielvorgabe und der kleinen Öffnungswinkel der Kameras eher groß. Zum andern müssen wir – um den relevanten Raum komplett im Bild zu haben – die Kameras sowohl nach innen schwenken, als auch nach unten neigen. Die Formel lässt sich somit also nicht mehr ohne weiteres anwenden.


Variante der Berechnung basierend auf der Disparität

Da wir aber den genauen Abstand des Spielers in Metern gar nicht benötigen, sondern nur eine qualitative Aussage über die Entfernung für unseren Spiel brauchen, auf der anderen Seite aber geneigte und geschwenkte Kameras einsetzen müssen stellte ich folgende Überlegung an:

Das grundsätzliche Verhalten der Disparität besteht auch bei geneigten und geschwenkten Kameras weiter: Je näher ein Raumpunkt, desto mehr unterscheiden sich die Koordinaten der Bildpunkte. Diesen Umstand würden wir uns zu Nutze machen.

Des Weiteren ist durch 0 noch nicht die Frage geklärt, wie sich x- und y- Koordinaten des Raumpunktes berechnen lassen. Logische Überlegungen lieferten folgende Formeln für die drei Raumkoordinaten:

Formel 2

Lambda 10.png

Da die Kameras beide gleich weit nach unten geneigt sind sollte die y-Koordinate des Raumpunktes eigentlich gleich der y-Koordinate beider Bildpunkte sein, sicherheitshalber bilden wir hier aber auch einfach den Mittelwert.

Es gibt einen Unterschied zu der normalen Disparitäten-Berechnung: Bildet man die Differenz zwischen linker und rechter x-Koordinate, so geht sie bei großer Entfernung und der klassischen Kameraanordnung gegen 0, bei unserer Methode mit geschwenkten Kameras hingegen kann die Differenz sowohl positive wie negative Werte annehmen. Das stellt aber kein Problem dar, wie ich später genauer erläutern werde.

Ein Problem bleibt allerdings bis jetzt ungelöst: Auch diese neuen Formeln beziehen sich nur auf die Kameraebene, die durch die beiden Richtungsvektoren1 der Kameras definiert wird. Wir wollen die Koordinaten aber in Relation zum Spieler haben, also in unserem globalen Koordinatensystem. So sind die Koordinaten noch voneinander abhängig, das heißt im Beispiel: Läuft der Spieler aufrecht und mittig auf die Kameras zu, so würde sich sowohl der z-Wert, als auch der y-Wert ändern, obwohl sich eigentlich nur die Tiefenkoordinate ändern soll.

Die Ursache dieses Verhaltens ist wie schon erwähnt die Tatsache, dass die Kameras nach unten geneigt sind. Wir bekommen also einen Ortsvektor von x’, y’, z’ geliefert, der sich auf ein um den Neigungswinkel gedrehtes Koordinatensystem bezieht. Um diesen Fehler zu korrigieren müssen wir also diesen Vektor um genau den negativen Neigungswinkel der Kameras um die x-Achse drehen. Das bewerkstelligt diese Transformationsmatrix:

Formel 3

Lambda 11.png

Sowohl die einfachen algebraischen Operationen, wie auch die Matrixmultiplikation lassen sich mit den Standardblöcken von EyesWeb umsetzen, was die Anwendung auf mehreren verschiedenen Rechnern enorm erleichtert.


Kalibrierung des Systems

Da wir mit unserer Berechnung Werte innerhalb eines kaum vorhersehbaren Bereichs bekommen, müssen wir die Daten normieren, bevor wir wirklich etwas mit ihnen anfangen können.

Halten wir uns noch mal vor Augen, was mit den errechneten Koordinaten passieren soll: Die Bewegungen eines virtuellen Spielers sollen von denen des realen Spielers gesteuert werden. Umgesetzt wird das normalerweise durch die Verschiebung einer Kamera oder eines Objekts in der 3D-Welt. Die Wertebereiche in dieser Welt sind aber mit Sicherheit andere als die von EyesWeb ausgegebenen. Um eine komplizierte Umrechnung der Werte in dem 3D-Echtzeitsystem zu vermeiden liegt es also nahe, EyesWeb dazu zu bringen, für jede Koordinate nur reelle Werte zwischen 0 und 1 auszugeben. Auf der Anwendungsseite, also der 3D-Umgebung genügt es dann, diese Werte mit einem passenden Faktor zu multiplizieren und eventuell eine Konstante als Versatz im Raum zu addieren.

Gleichzeitig erkannten wir darin die Lösung für die Aufgabe der Kalibrierung. An den Ausgängen des Blocks „MaxMin“ liegen konstant die bislang größten und kleinsten Werte des eingehenden Datenstroms an. Diese können wir direkt als „Input min“- und „Input max“-Werte für den Block „Rescale“ verwenden. „Output min“ und „Output max“ werden auf 0 und 1 (oder 1 und 0 – je nachdem, wie die Werte orientiert sind) gesetzt.

Eigener Block

Kurz gesagt erreichen wir somit folgendes: Der von uns unbekannte Wertebereich der Positionsberechnung wird mit diesen beiden Blöcken auf Werte zwischen 0 und 1 skaliert. Es ist darauf zu achten, dass die Werte des eingehenden Datenstroms vorher von integer auf real-Werte umgewandelt wurden, da sonst entweder 0 oder 1 anliegt.

Um das System also zu kalibrieren benötigen wir außer dem Neigungswinkel der Kameras (der näherungsweise durch die Abmessungen des Raumes als gegeben angenommen werden darf) nur noch einen Spieler, der vor dem Antritt des ersten Spiels die Ränder des Spielraumes mit seiner Markierung abläuft. Damit werden alle relevanten extremen Werte (Minima und Maxima) aus unserer Berechnung einmal angenommen, im „MaxMin“-Block gespeichert und anschließend entsprechend skaliert.

Weil dieses Vorgehen vielleicht etwas schwer vorstellbar ist, so hier noch konkreter darauf eingegangen werden: Während der Kalibrierung macht sich die reale Bewegung durch eine etwas merkwürdig anmutende Bewegung im virtuellen Raum bemerkbar. Geht der Spieler zum Beispiel das erste Mal nach rechts, so befindet er sich direkt und über die gesamte Dauer der Bewegung am rechten Spielfeldrand im virtuellen Raum. Der Grund dafür liegt auf der Hand: Mit jedem Schritt nach rechts betritt der Spieler einen Raumpunkt, den er bisher noch nicht betreten hat und er erzeugt somit ein neues Extremum. Beim Zurückgehen in die andere Richtung verhält sich das System dann aber schon viel realistischer, da die Werte zu diesem Zeitpunkt dann schon „bekannt“ sind. Der Spieler spannt sich beim anfänglichen Durchlaufen des Spielfeldes (der Kalibrierung) also praktisch seinen nutzbaren Raum nach und nach auf.

Wir benötigen weder die genauen Orte, Neigungen, Schwenkungen, Öffnungswinkel oder Chipgrößen der Kameras, noch die Abmessungen des Spielfeldes. Die Justierung des Systems gestaltet sich somit sehr einfach nachdem die Kameras einmal so ausgerichtet sind, dass sie den gesamten bespielbaren Raum erfassen.

In der Praxis stellte die Justierung auch tatsächlich überhaupt kein Problem dar, die manuelle Justierung der Farbgrenzen für die rote Markierung des Spielers war deutlich aufwändiger. Die Kalibrierung passierte mehr oder weniger automatisch im Hintergrund.

Der komplette EyesWeb-Patch lambda_gesamtpatch.eyw für das Projekt Lambda ist im internen Bereich zum Download abgelegt.

3D-Anwendung

Half-Life

Das Computerspiel Half-Life 2 (auch Half-Life², HλLF-LIFE² oder λ², kurz HL2) ist der Nachfolger des Ego-Shooters Half-Life, der von der Firma Valve entwickelt und am 16. November 2004 vom Vertriebspartner Vivendi Universal veröffentlicht wurde.

Das Gameplay ist linear aufgebaut, also in Kapiteln. Ansonsten ist das Spiel sehr abwechslungsreich gestaltet. Das zeigt sich schon in den verschiedenen Handlungsräumen. Es gibt sonnige Landschaften, Industriegebiete, düstere Kanalisationsgänge oder zerstörte Stadtteile, auch verschiedene Aufgabenstellungen, Gegner und besondere Kampfszenarien sorgen für Abwechslung.

Kurz einen Einblick zu Half Life: Die Hauptperson in Half Life ist der Wissenschaftler Gordon Freeman, der in einem unterirdischen Labor, der Black Mesa Forschungsstation einige Versuche durchführt. Bei einem Versuch, bei dem er eine Kristallprobe in einen Laserstrahl stellt, kommt es zur Katastrophe. Ein Tor zu einem anderen Planeten wird geöffnet und außerirdische Wesen kommen in die Forschungsstation. Die Handlung beginnt. Gordon ist ohnmächtig und kommt erst nach einiger Zeit zu sich. In der Zwischenzeit haben diese fremdartigen Wesen eine Vielzahl von anderen Wissenschaftlern entweder getötet oder sie haben sie auch in außerirdische Wesen verwandelt. Die wenigen die überlebt haben, helfen Gordon, indem sie ihm Hinweise geben, oder Türen öffnen. De Wissenschaftler wird aber nicht nur von den Aliens verfolgt, sondern auch von der Regierung, die das Ganze geheim halten will. Zum Schluss muss er sich auf die Seite der Regierung schlagen, da er sonst getötet wird. Hier beginnt dann die Handlung von Half Life 2. Zehn Jahre nach der Katastrophe kämpft Gordon Freeman auf Seiten der Regierung. Er muss in die Stadt City 17, die von Aliens, den Combine heimgesucht wird. Hier kämpft er sich durch die Stadt um zu Dr. Kleiners Labor zu gelangen. Ziel ist es, die Außerirdischen zu vernichten. Auf dem Weg dieses Ziel zu erreichen, muss er sich durch verschieden Kapitel kämpfen und verschiedene Aufgaben lösen.

Die Source-Engine ist eine so genannte Spiele–Engine, mit deren Hilfe Computerspiele realisiert und modifiziert werden. Die Source-Engine besteht aus einer Programmbibliothek und verschiedene Tools, die dazu dienen, Spiele zu entwickeln.

Source engine logo.png

In diesem Bereich wird auf die Bestandteile einer Source-Engine eingegangen, sowie auf die Vorteile der Source Engine von Steam. Steam legt besonderen Wert auf die realistische Darstellung zur Laufzeit. Aus diesem Grund wird besonderer Wert auf das Rendern gelegt. Es ist möglich Skyboxen zu gestalten, die fast an die Realität angrenzen. Wasserflächen haben Reflexe, es kann regnen oder es herrscht Nebel, Verwundete bluten, oder bei Feuer gibt es eine Rauchentwicklung. Diese doch sehr aufwändige Rechenleistung wird durch einen Vertex- Shader der Version 3.0 realisiert sowie durch ein High Dynamic Range Rendering. Zusätzlich gibt es eine enorme Auswahl an Texturen. Texturen sind maßgeblich dafür verantwortlich was gesehen wird und wie es beschaffen ist. Die Source Engine ist auch hier viel flexibler als andere Programme in diesem Bereich. Eine weitere Funktion ist der Multiplayer Network Code der ermöglicht, dass tausende Spieler gleichzeitig spielen können. Es ist nicht nur möglich über das Internet gegeneinander anzutreten, sondern sich auch über LAN gegenseitig zu bekämpfen.

Was auch wesentlich zur realistischen Darstellung beiträgt, ist das glaubwürdige Erscheinungsbild der verschiedenen Charaktere. Es wurde besonderer Wert auf die Gestaltung der Gesichter gelegt. In den Augen der Gegenspieler sieht man Reflexe der Umgebung, durch simulierte Muskulatur kommen Mimik und Gestik gut zum Ausdruck, durch überlagerte Animationsabläufe sind komplexe Simulationen möglich. Das ist auch wichtig für die Physik in der Spielumgebung. Fahrten mit Fahrzeugen sind durch eigene Geräusche, wie das Motorengeräusch oder den Untergrund beeinflusst. Intelligente Models können auf simulierte Gegenstände einwirken. Sie können anrempeln, kämpfen, sprechen und agieren mit dem Spieler. Der Ton ist ein weiterer wichtiger Bestandteil des Spiels. Das integrierte User Interface, erlaubt mit anderen realen Spielern zu agieren. Ein Server Browser zeigt alle Spieler die gerade online sind und ermöglicht es, einem anderen Spieler an dem eigenen Spiel teilnehmen zu lassen. Die Programmierung ist in C/C++ mit Visuel Studio 7.1 geschrieben.


Steam

Steam ist eine Onlinevertriebs-Software. Das System ist eine Zusammenstellung von Software, die als Komplettpaket angeboten wird. Es ermöglicht Wartung und Aktualisierung der angebotenen Software. Valves Spiele wie Half Life 2 werden nur noch über Steam aktualisiert, das zum spielen notwendig ist.

Mittels Steam können Programme heruntergeladen werden. Anschließend muss unter „Meine Spiele“ Half Life 2 Deathmatch und das Spiel Half Life 2 und unter „Tools“ der Source SDK(Software Development Kit) und Source SDK Base installiert werden, um die benötige Software für das Projekt Lambda zu komplettieren. Source SDK beinhaltet den Hammer Editor, den Model Viewer sowie den Face Poser, um Karten, Models und Gesichtsmimiken individuell zu gestalten oder bereits vorhandene Models zu verändern.


Hammer Editor

Der Hammer Editor ist ein Map-Editor, der es ermöglicht, eigene Maps, in denen die Spieler sich bewegen, für Half-Life und Half-Life 2 und deren Modifikationen (Mods) zu entwickeln. Man kann damit auch eigene Mods erstellen. Der Editor befindet sich im Programm-Paket der Software Development Kit.

Er besteht aus fünf einzelnen Programmen. Zum einen aus dem Editor selbst, in dem die Map erstellt wird und mit speziellen Objekten ausgestattet werden kann (Lichter, Waffen, Texturen usw.) Zum anderen aus vier Kompilierprogrammen, mit denen dann die erstellte Map in eine Half-Life-Map-Datei umgewandelt wird. Diese Programme beinhalten die Berechnung der Sichtbarkeit, Geometrie, Objekte und des Lichts.

Maps bestehen aus zwei Komponenten den Brushes und den Entities. Brushes sind einfache geometrische Objekte die die grundlegende Architektur der Map erzeugen. Durch Sie bekommt ein Raum seine Gestalt. Entities sind alle möglichen Objekte die in einem Raum Platz finden und zur realistischen Darstellung dienen, wie zum Beispiel Lichtquellen, Startpunkt des Spielers, Soundeffekte, Non Charakter Player, Einstellungen die den Spielverlauf bestimmen sowie detaillierte oder bewegte Objekte, die sich nicht durch Brushes darstellen lassen. Wie üblich bei 3D-Programmen, gibt es auch beim Hammer Editor auf der Oberfläche sowohl eine dreidimensionale Kameraansicht, als auch die drei Seitenansichten von oben (TOP x/y), von vorn (FRONT y/z) und von der Seite (SIDE x/z). Alles was an Objekten erstellt wird, steht wie in einem 3D-Koordinatensystem in der konstruierten Welt und kann so immer genau einer Position zugeordnet werden.

Seitenansicht beim Hammer Editor

Installation und Einstellungen

Zu Beginn ist es notwendig einige Spiele, wie Half Life 2 und Half Life 2 Deathmatch aus dem Internet zu laden. Danach wird aus dem Bereich Tools das Source SDK gestartet. Einige Zeit später erscheint ein neues Fenster, mit den verschiedenen Editing-Tools. Um den Hammer Editor starten zu können, muss das Spiel, mit dem gearbeitet wird, mindestens einmal gelaufen sein, da sonst kein Spieltitel in der Auswahlliste Current Game erscheint und sich Hammer nicht öffnen lässt. Die Auswahl des Spiels ist wichtig, damit sich Hammer alle GCFDaten, das sind Texturen, Models usw. aus dem jeweiligen Spiel laden kann. Nachdem das Spiel ausgewählt ist öffnet sich mit einem Doppelklick der Hammer Editor.


Werkzeuge

Vorab eine Begriffsbestimmung von Brushes (Blöcke), deren Elemente teilweise für die aufgeführten Werkzeuge relevant sind:

Ein Brush ist eine solide dreidimensionale Form. Blocks oder Brushes sind die Bausteine einer jeden Map. Die Bezeichnungen Block und Brush sind identisch. Im Folgenden werden die verschiedenen Werkzeuge des Hammer Editors aufgeführt.

Selection Tool

Mit diesem Werkzeug können Teile einer Map (Objekte) ausgewählt werden um diese zu verändern.

Magnify Tool

Werkzeug zum Ein- und Auszoomen in dem jeweiligen Fenster.

Camera Tool

Das Camera Tool ermöglicht ein einfaches Navigieren in der 3D-Ansicht. Die Kameraposition kann in den drei anderen Ansichten verändert werden, so dass die Sicht optimal eingestellt werden kann.

Entity Tool

Entities sind notwendig für alle Spezialeffekte und interaktive Elemente. Zum Βeispiel, benötigt man Entities für Lichter, Türen, Knöpfe, Models, Startpunkte für Spieler usw.

Es gibt zwei Arten von Entities:

Brushentities sind alle Entities, die auf einem Brush basieren, also beispielsweise Türen.

Pointentities gehen immer von einem bestimmten Punkt aus, also zum Beispiel einer Lichtquelle.

Das Entity Tool ist in Zusammenhang mit der im rechts im Hammer Editor befindlichen Tool Bar zu benutzen.

Entity Toolbar

Texture Application Tool

Über das Texture Application Tool kann beinahe alles, was mit Texturen zusammenhängt gesteuert werden, z.B. das Wählen, Anpassen und Ersetzen von Texturen. Des Weiteren ist es aber auch möglich, über dieses Tool das Displacement Tool aufzurufen. Mit dem Displacement Tool ist es möglich, Unebenheiten im Boden zu erzeugen.

Daneben befindet sich im Texture Application Tool auch das Tool zum Anwenden von Blendtexturen. Blendtexturen ermöglichen einen sanften Übergang zwischen verschiedenen Texturen.

Clipping Tool

Ermöglicht das Zerschneiden von Objekten.

Vertex Tool

Das Vertex Tool ermöglicht, die Eckpunkte von Brushes zu verschieben oder auch ganze Seiten eines Brushes zu bewegen.

Path Tool

Mit dem Path Tool können Pfade für eingesetzte Entities wie für den Strider sowie Models einfach und schnell erstellt werden. Mit dem Tool kann der Strider oder das Model in der 3D Welt die vorgefertigten Pfadpunkte ablaufen.

Mapping

Map erstellen

Nach der Einarbeitung in das komplexe 3D Programm wurden erste Versuche unternommen, eine Map zu erstellen. Zuerst wurden Wände und Böden einzeln als Blöcke erstellt. Danach wurde der Startspieler erzeugt. Der Startspieler wird mit dem Entity Tool in den Raum gesetzt, indem man unter Entities den „info_ player_start“ einstellt. Der Startspieler ist die Person, mit der man sich im Spiel durch die virtuelle Welt bewegen kann. Er ist dabei selber nicht sichtbar. Bei der Platzierung des Startspielers und der Gegenstände, ist darauf zu achten, dass keine Lücken zwischen den einzelnen Elementen sein dürfen. Gegenstände sowie der Startspieler dürfen nicht in den Boden hineingesetzt werden, da dadurch beim Kompilieren Fehler auftreten bzw. der Spieler nicht vorwärts laufen kann.

Virtuell erstellter Raum


Wände, Böden und Gegenstände bekamen einen individuell zugewiesenen Textur. Diese werden aus der Textur Bar ausgewählt, welche auf der rechten Seite im Hammer Editor zu finden sind.

Texture Bar


Für ausführlichere Einstellungen der Texturen benutzt man das Texture Application Tool auf der linken Seite, das bereits beschrieben wurde.

Damit der Raum beim Spielen nicht dunkel ist, muss er beleuchtet werden. Dies wird mit dem Entity Tool gelöst, indem man rechts in der Menübar unter Entities „light“ auswählt.

Durch die einzeln angelegten Blöcke erwies es sich als schwierig einen realistischen Himmel zu erstellen.

Virtueller Raum mit Textur


Nach ausführlicher Recherche wurde eine Lösung gefunden. Die so genannte Skybox löste dieses Problem. Skybox ermöglicht es eine realistische Landschaftssicht in der virtuellen Welt darzustellen. Die Box an sich ist in der Kameraansicht nur als blaue Fläche zu sehen. Damit im Spiel auch die Skybox als Himmel erscheint, muss der Box eine Himmeltextur, die Half Life bereits zur Verfügung stellt, zugewiesen werden. Ganz wichtig ist es, dass in der Arbeit mit der Skybox nicht das Entity Tool „light“ verwendet werden darf, sondern das „light_environment“ für eine natürliche Beleuchtung der virtuellen Landschaft sorgt und eine „sky_camara“ für eine Referenz auf die 3D Skybox.

Skybox mit Textur und Enviroment Light


Eine 3D Skybox besteht aus echten 3D-Objekten, die man aus Brushs bauen kann. Wichtig dabei zu beachten ist, dass 3D Skyboxen „Miniwelten“ sind, was bedeutet, dass sie später auf das 16-fache ihrer Größe vergrößert und dann dargestellt werden. Wenn man also einen Brush mit den Maßen 8x8x8 Units einstellt, wird dieser am Ende sechszehn mal so groß dargestellt, was dazu führt, dass man im Editor den Brush auf 1/16 der Größe verkleinern muss. Nach den Einstellungen erstellt man sechs Blöcke mit der Textur „toolsskybox“. Hierauf ist auch zu beachten, dass keine Lücken im Raum entstehen (vgl. www.mappingtutorials. de).

Dank der neuen Möglichkeiten mit Skybox wurde der erste erstellte Raum verworfen und mittels neuer Ideen eine bessere und realistischere Welt erstellt. Nachdem der neue Raum zügig erstellt wurde, begannen die Arbeiten an der Landschaftsgestaltung und das Einsetzen eines Gegners (Model). Bäume, Holzstücke, Felsen und Büsche wurden ebenfalls mittels des Entity Tools in den Raum platziert.

Das Einfügen der Entities erfolgt mit der Entity Tool Bar. Das Aufrufen des „Word Model“, der Bibliothek der vorhandenen Objekte, erreicht man mit der rechten Maustaste unter Properties.

Properties


Die Bibliothek bietet viele vorgefertigte Objekte, wie Bäume, Steine, Model und Häuser an. Für die 3D Landschaft wurden hiermit einige Objekte eingefügt.

Entity Bibliothek


Die fertige 3D Landschaft wurde somit erfolgreich geschaffen. Die Komplexität solcher 3D Welten zeigt die Abbildung im Hammer Editor.

Fertige 3D-Landschaft mit Hammer Editor
Fertige 3D-Landschaft mit Half-Life 2

Konsole

Die Konsole dient dazu der ganzen Map eine Spiellogik zuzuweisen oder bei schwierigen Spielsituationen Waffen auszuschalten, zusätzlich Lebensenergie zuweisen usw.

Die Konsole

Hier eine der wichtigsten Konsolenbefehle:

Konsolenbefehle Bedeutung
  • ai_weitere Befehle
  • bot_ weitere Befehle
  • ent_ weitere Befehle
  • nav_ weitere Befehle
  • npc_ weitere Befehle
  • phys_ weitere Befehle
  • sv_ weitere Befehle
  • Intelligenz der Spieler einstellen
  • Bot Einstellungsmöglichkeiten
  • Entities kontrollieren
  • Navigationselemente einfügen und kontrollieren
  • Non_Player_Charakter Einstellungen
  • Physikalische Einstellungen
  • Bedieneinstellungen

Beispiele:

Konsolenbefehle Bedeutung
  • Impulse 101
  • give_weapon_shotgun
  • nav_mark_walkable
  • Nav_save
  • npc_go_do_run
  • npc_thinknow
  • Impulse 107
  • Impulse 103
  • Alle Waffen stehen dem Spieler zur Verfügung.
  • Es wird nur diese Waffe dem Spieler zur Verfügung gestellt.
  • Macht eine markierte Zone für den Gegenspieler begehbar.
  • Speichert die Einstellungen.
  • Bringt den Non_Player_Charakter zum Laufen.
  • Lässt den Non_Player_Charakter denken.
  • Schaltet das Fadenkreuz aus.
  • Zeigt den Lebensbalken des Gegenspielers.


Avatar

Faceposer

Das Werkzeug Faceposer beeinflusst die verschiedenen Mimiken und Gestiken der Models. Gesichtausdrücke lassen sich darstellen, Lippen sind mit Worten synchronisierbar, ganze Sequenzen mit Körperanimationen lassen sich durch Events steuern.

Faceposer


Model Viewer

Der Model Viewer dient dazu 3D Objekte anzuschauen und Veränderungen an ihnen durchzuführen.

Model Viewer


Info_start_player

Models sind Personen und Objekte, die in einer Map handeln. Ein Model kann im Prinzip alles sein, vom Eimer über die Heizung bis zum Buggy oder einem Auto. Der Info_start_player repräsentiert dabei den eigentlichen Spieler. Er übernimmt das Sehen, Gehen und Agieren für den Spieler hinter der Konsole. Um den info_ start_player zu starten, wird das Entity Werkzeug aktiviert. Nun setzt man ein Entity dort in dem Raum, wo das Spiel beginnen soll. Der rechte Teil des Hammer Editor wird durch das setzten des Entities aktiviert. Im ersten Drop-Down-Menü Category muss Entity stehen. Im Drop-Down-Menü Objekts muss info_ start_player ausgewählt sein. In der Camera Ansicht erscheint ein grünes Kästchen, der info_start_player, der den realen Spieler repräsentiert.

Spieler


Strider

Strider

Der Strider ist ein Combine im Spiel Half Life 2. Er ist der größte Gegner, mit 3 Beinen und einer Waffe am Körper. Auch hier wird das Entity Tool benötigt, um ih in den Raum zu setzten. Auf der rechten Seite des Hammers, dann nbc_strider (nbc = non player charakter) auswählen. Um Einstellungen am Strider durchführen zu können, betätigt man Alt + Enter. Es erscheint ein neues Dialogfenster. In dem Bereich Keyvalue „Name“ muss der Name strider_01 eingetragen werden. Das ist der Name des Striders, um eine Verbindung zum Pfad zu erstellen. In de Bereich Keyvalue „Target Path Corner“ muss der Name „strider_01_1“ stehen. Dadurch wird dem Strider vorgegeben wohin er sich als erstes bewegt, wenn das Spiel kompiliert und gestartet wird. Der Pfad auf dem sich der Strider bewegen soll, wird erneut mit dem Entity Tool, genau neben den Strider gesetzt. Path_corner ist das Entity, das in dem Drop-Down Menü Objekts ausge Die Einstellungen bei diesem Entity sind im Keyvalue Name „strider_01_1“, im Keyvalue Next Stop Target „strider_01_2“. Im Ansichtfenster des Editors ersche nen rote Quadrate.

Die Pfadpunkte dürfen nicht in den Boden versinken und auch nicht zu weit oder zu nah beieinander liegen, da sich der Strider sonst nicht bewegt. Es ist wichtig, alle Entitys auch in der Seitenansicht genau zu überprüfen. Im letzten Pfadpunkt ist darauf zu achten, dass als Next Stop Target der erste path_corner steht, damit der Pfad geschlossen ist. Den Pfadpunkten muss noch ein weiteres Entity zur Seite stehen, das info_node_air_hint Entity. Dieses Entity wird neben den erste path_corner gesetzt. Die Einstellung sind unter dem Keyvalue Hint „Strider Node“. Um den Strider als Gegner tauglich zu machen, muss er auf einen reagieren. Es wird ein info_target Entity gesetzt. Die Einstellungen in diesem Entity sind Keyvalue Name „target_strider“, Keyvalue Start Disabled Name „No“ und Keyvalue Target NPC Name „npc_strider“. Das folgende Kommando wird in den Output eines path_corner gesetzt, damit die Kanone des Striders aktiviert wird. | OnPass | strider | SetCannonTarget | target_strider| 0.00 | No |.


NPC

NPC

Non_Player_Charakter sind Wesen, die mit einer gewissen Intelligenz ausgerüstet sind. Um den Gegner in das Spiel zu bringen, wird ein Entity in die Map gesetzt. Es gibt vorgefertigt Non_Player_Charakter wie zum Beispiel Barney. Werte die man in Barneys Einstellungen ändern muss, damit er auf den Spieler reagiert, sind z.B Keyvalue Targetname „ Barney“, Keyvalue Damagefilter „Barney“. Um den Barney Sprechen zu lassen gibt es die Möglichkeit mit ResponseContext einen String mit verschiedenen Werten einzugeben. Mit disableshadows vom Typ Boolean erzeugen wir einen realistischen beweglichen Schatten. Damit Barney eine Waffe hat, wird der Befehl Additionalequipment verwendet. Damit sich Barney bewegt hat man verschieden Möglichkeiten, entweder setzt man einen Pfad wie in der Erklärung des Striders oder man weist über die Konsole, verschieden Regionen, der Map Verhaltensweisen zu.


Server-Plugin

OSC

In diesem Abschnitt folgt eine kurze Beschreibung der Datenübertragung über OSC.

OSC (Open Sound Control) ist ein Nachrichten basiertes Kommunikationsprotokoll, das aktuell hauptsächlich für Echtzeitübertragungen von Sound über Netze und multimediale Installationen verwendet wird.

Im Projekt „Lambda“ werden die Spielerkoordinaten vom Bildverarbeitungsteam im EyesWeb segmentiert und über OSC an die 3D-Anwendung zur weiteren Verarbeitung gesendet.

Dafür wurden die Rechner über LAN miteinander verbunden und die IP-Adresse, das zu benutzende Port und das zu verwendende OSC-Kommando, welches zur späteren Identifizierung der Daten dient, eingestellt. Nun konnte man die Spielerkoordinaten an die 3D-Anwendung schicken. Für die richtige Interpretation und Verwendung der übermittelten Daten durch die Anwendung musste ein Serverplugin in unser Spiel eingebunden werden.

Serverplugin

Plugins sind Anwendungsdateien, die für eine Erweiterung der Funktionalität in Anwendungen sorgen. Serverplugins ändern das Verhalten eines Servers und ermöglichen es z. B. die empfangenen Daten richtig zu interpretieren und für verschiedene Funktionen, die im Plugin definiert werden müssen, zu verwenden.

Uns wurde freundlicherweise ein Serverplugin als zwei Anwendungsdateien (Dateiformat .dll) von Herrn Frieder Weiss zur Verfügung gestellt (siehe interner Bereich), welches wir in unser Spiel nach der richtigen Platzierung im Verzeichnis über den Konsolenbefehlaufruf einbinden konnten. Das Plugin wurde mit Visual Studio in C++ programmiert (siehe interner Bereich).

Die von uns erstellte und kompilierte Map wurde in die Ordnerstruktur des Spiels Half Life 2 Deathmatch eingefügt, denn dieses ermöglichte uns den Multiplayermodus. Unser Spiel fungierte nun als Server und konnte nach Einbindung der zum Serverplugin zugehörigen Dateien in das Verzeichnis von Half Life 2 Deathmatch ausgeführt werden.

Ordnerstrukturen

Wie bereits erwähnt, war es für die Einbindung des Serverplugins wichtig, die entsprechenden Dateien richtig im Verzeichnis zu platzieren. Die folgende Abbildung zeigt eine generelle Ablegung der Ordner nach Installation der Steamplattform auf dem Rechner.

Verzeichnis des Streambenutzerkontos auf dem Rechner


Zu dem Serverplugin gehörte außer den beiden Anwendungsdateien noch die Referenzdatei „oscplugin“ (Dateiformat vdf). Mit deren Hilfe kann auf die Anwendungsdateien referenziert und somit auf Funktionen des Plugins zugegriffen werden. Was uns nach mehreren Anläufen gelungen ist. Die Anwendungsdateien des Serverplugins mussten hierzu in den Ordner „bin“ des Spielverzeichnisses, in dem unsere Map sich befand, und die Referenzdatei wurde im zusätzlich erstellten Ordner „addons“ gespeichert.

Der relative Dateipfad über den es uns gelungen war auf die Funktionen des Plugins zuzugreifen ist folgender:

"file" "..\hl2mp\bin\serverplugin_osc"

Die nächste Abbildung zeigt einen Ausschnitt aus der Ordnerstruktur, in der das Severplugin platziert wurde.

Verzeichnisstruktur zur Platzierung des Serverplugins


Die im Plugin definierten Funktionen, die wir für unser Projekt benutzen konnten, waren zu einen „pos“, die die absolute Position des Spielers ins Spiel überträgt, und zum anderen „move“, die die Positionsdaten in relative Bewegung umwandelte, um eventuelle ruckartige Sprünge zu vermeiden.


Datenübertragung mit FLOSC

Nachdem die Koordinaten aus der Bildverarbeitung und der Koordinatenberechnung auf Werte zwischen 0 und 1 normiert wurden sind sie soweit verrechnet, dass sie von EyesWeb direkt per OSC verschickt werden können, einen passenden Block dafür stellt EyesWeb standardmäßig zur Verfügung.

Für OSC haben wir uns entschieden, weil es zum einen damit sehr leicht möglich ist, die Daten aus EyesWeb heraus über ein lokales Netzwerk an einen anderen Rechner zu senden und somit die Bildverarbeitung von der Darstellung der 3DWelt zu trennen. Ein moderner einzelner Rechner kann dabei schnell überfordert werden. Zum anderen gibt es im Gegensatz zum alternativ angedachten Midi- Protokoll auch die Möglichkeit, die Daten über den FLOSC-Server in Flash zu importieren, um damit alternative Anwendungen zu erstellen. Ein Beispiel für den entsprechenden FLOSC-Client (eigentlich ein XML-Socket) in Flash ist im FLOSC- Paket beim Download enthalten; ihn auf die eigenen Bedürfnisse anzupassen, war relativ simpel.

Um die Daten unterscheidbar zu machen, haben wir sie zu Beginn – wie vorher definiert – als Zeichenkette formatiert und mit der Bezeichnung der jeweiligen Koordinate versehen. Ein Datum sah dann beispielsweise so aus:

y_0.3345

Für Flash ist diese Kennzeichnung sehr hilfreich, da der Unterstrich gleich als Trennzeichen für die String.split-Methode dient. Für das von dem 3D-Team verwendete Half-Life-Plugin war jedoch die Reihenfolge, in der die Daten im OSC-Paket hinterlegt sind aussagekräftiger. Auch war die Konvertierung vom Datentyp String in eine Zahl schwer, daher änderten wir die Kennzeichnung entsprechend.

Ein anderes Problem, das hier auftauchte hing direkt mit EyesWeb zusammen. Die Implementierung des OSC-Blocks ist offenbar fehlerhaft oder zumindest unsauber. So stürzte EyesWeb nach einer kleinen Veränderung mit dem Starten des Patches gerne mal ab. Nach langem hin und her glaubten wir, einen Workaround für den Bug gefunden zu haben. Es kommt scheinbar auf die Position der Datenquelle innerhalb der Zeichenfläche von EyesWeb an. Quellen, die weiter oben liegen müssen an weiter oben liegende Eingänge des OSC-Blocks angeschlossen werden, sonst tritt besagter Fehler auf.

Test und Aufbau

Im Laufe des Projekts fanden auch verschiedenen Testläufe statt. Zum einen um die einzelnen Bildverarbeitungsschritte, wie beispielsweise die 3D-Koordinaten- Erkennung oder auch die Schusserkennung zu testen, zum andern natürlich auch um sicherzustellen, dass die zur Verfügung stehenden Ressourcen wie Rechenleistung, usw. funktionieren und richtig eingesetzt wurden.


Systemtest 3D-Koordinaten

Nachdem wir erfolgreich die Koordinaten des Spielers anhand von Testvideos extrahieren konnten, stand nun der Test im Aufbau selbst an. Hierfür erstellten wir ein eigens, für diesen Zweck programmiertes Flashtool. Diese Flash-Anwendung empfängt die 3D-Koordinaten über OSC/FLOSC und stellt die Position als Kugel innerhalb eines Würfels (Kantenlänge: eine Einheit) dar.

Das Flash-Projekt lambda_3D.fla bzw. lambda_3D.swf zur Anzeige der 3D-Position ist im internen Bereich zum Download abgelegt.

Flash Würfel

Komplettsystemtest

Durch die Realisierung unseres Vogelspiels (Näheres später) war es dann auch möglich einmal einen kompletten Systemtest durchzuführen. Dieses Mal verwendeten wir zwei Rechner, einen für die Aufgaben der Bildverarbeitung, also für den EyesWeb Patch und den zweiten für FLOSC und Flash.

Durch diesen Testlauf stellten wir kleinere Probleme im Bereich der Bildverarbeitung fest, wie beispielsweise die extremen Änderungen der einzelnen Schwellwerte bei verschiedenen Lichteinflüssen, aber auch kleinere Änderungen der Kalibrierung des Systems.

Im Bereich der Flashanwendung waren es Probleme wie beispielsweise die Größe des Trefferbereichs, oder aber auch die genaue Kalibrierung für die Perspektivänderung. Im Großen und Ganzen waren diese Test natürlich essentiell, aber auch sehr zeitintensiv.

Alternativ-Spiel: Die Vögel

Bild aus dem Spiel "Die Vögel"

Spiel-Story

Der Spieler hat blöderweise sein nagelneues Cabrio unter einer Stromleitung geparkt. Gerade als er es bemerkt kommen schon die ersten Vögel, landen auf der Stromleitung und machen, was Vögel nun mal machen. Der Spieler hat aber glücklicherweise eine Schusswaffe (abgebildet als Infrarot-Laserpistole) bei sich und kann die Vögel damit von der Leitung schießen. Die Vögel fliegen hin und wieder angriffslustig auf den Spieler zu, der ihnen dann ausweichen sollte.

Nach der Erstellung der 3D-Welt und der Zeichnung der verschiedenen Flugzustände der Vögel ging es an die Programmierung des Spiels. Das beinhaltete drei große Teile:


Game-Logik

Der Spieler hat einen Lebensbalken, der sich abbaut, wenn er oder sein Cabrio von einem Vogel getroffen wird; bei 0 endet das Spiel. Während des gesamten Spiels steigt die Geburtenrate der Vögel schleichend immer weiter an. Mit dem Fortschreiten der Zeit steigen auch die erreichten Punkte des Spielers. Das Spiel endet zwangsläufig immer damit, dass der Spieler der Schar an Vögeln nicht mehr Herr wird. Er verliert also letztendlich immer.


Künstliche Intelligenz der Vögel

Die Intelligenz der Vögel reduziert sich bei diesem Spiel eigentlich auf eine Zufallssteuerung, mit der festgelegt wird, wo auf der Stromleitung ein Vogel landet, wann er seine Notdurft verrichtet und wann er im besten Kamikazestil auf die Spielerkoordinaten zufliegt.


Animation

Da zu bestimmten Zeitpunkten die Zielpositionen der Vögel festgelegt werden und der Spieler ja auch sehen soll, wie der Vogel zur Zielposition fliegt braucht es eine Art Keyframe-Animation, die gestartet wird, sobald das neue Ziel feststeht.

Besonders bei den Vögeln bot es sich natürlich an, einen objektorientierten Ansatz bei der Programmierung zu verfolgen. Jeder Vogel kann sozusagen für sich entscheiden, wann er was tut. In Flash äußert sich das dann in Form eines eigenen Movieclips, in dem die Programmierung des Vogels stattfindet. Dieser Movieclip wird dann zentral gesteuert dupliziert und läuft anschließend selbständig.

Das Flash-Projekt lambda_shitnshoot.fla bzw. lambda_shitnshoot.swf für das Spiel "Die Vögel" ist im internen Bereich zum Download abgelegt.