Digitars

Aus toolbox_interaktion
Wechseln zu: Navigation, Suche
DIGITARS Logo
IMAG0276.jpg

Projektbeschreibung 

„DIGITARS“ ist eine interaktive Anwendung auf dem Multi-Touch-Tisch, welche über spielerische Art die Funktionalitäten und Möglichkeiten eines Multi-Touch-Tisches visualisieren.




Spielidee und Konzept

Bei der kooperativen Zusammenarbeit von sechs Studenten, zweiter Fakultäten, stand zunächst die Idee im Raum, ein Spiel für den Multi-Touch-Tisch xDesk zu konzeptionieren und zu implementieren. Zuerst führten alle Teammitglieder eine Recherche durch. Gesucht wurde dabei nach einem Brettspiel, das möglichst viele gut auf dem interaktiven Tisch realisierbare Komponenten enthält. Während der Recherche wurden wir auf das Brettspiel „Tabu Hot Pen“ aufmerksam. Bei diesem Spiel werden zu Beginn aus allen Mitspielern zwei Gruppen gebildet. In jeder, auf zwei Minuten begrenzten, Spielrunde wird ein Mitglied ausgewährt, welches zuerst einen auf einer Spielkarte abgebildeten Begriff lesen darf. Anschließend skizziert das Teammitglied diesen vorgegebenen Begriff auf einen Zeichenblock. Die übrigen Gruppenmittglieder versuchen den gesuchten Begriff möglichst schnell zu erraten. Pro erratenen Begriff, darf die Spielfigur der Gruppe ein Feld auf dem Spielfeld vorrücken. Das Team, deren Spielfigur als erstes im Ziel ist gewinnt das Spiel. Die Spielablauf sowie die vorhandenen Regeln wurden genau notiert und anschließend analysiert. Bei dem Projekt „DIGITARS“ soll ein Spiel entwickelt werden, bei dem vier Spieler gegeneinander antreten können. Die verschiedenen Spieler werden durch die Farben rot, grün, gelb und blau dargestellt. Durch das Zufallsprinzip sollen je zwei Spieler in einer Runde zusammen spielen, sie bilden ein sogenanntes Spielteam. Um die Schwierigkeit anzuheben und die Spieler unter Zeitdruck zu setzten, ist jede Spielrunde auf eine Minute begrenzt. Einer der beiden Spieler erhält einen Begriff, den er versucht mittels einer Zeichnung darzustellen. Dieser Spieler darf weder sprechen und noch beschreibende Gestik verwenden. Der andere Spieler aus der Zweiergruppe versucht den Begriff möglichst schnell zu erraten.

Wurde der Begriff richtig erraten, erhalten beide Spieler einen Punkt. Wo durch die Bemühungen beider Spieler gesteigert werden. Würde nur der Ratende einen Punkt erhalten, läuft man Gefahr, dass der Zeichnende nicht sein bestes gibt. Ein eindeutiger Sieger kann dennoch ermittelt werden, da die Spielerpaare jede Spielrunde erneut zusammengesetzt werden. Der Grundsatz bei der Konzeption war stets, das Spiel „Tabu Hot Pen“ nicht nur zu digitalisieren, sondern die individuellen und charakterisierenden Möglichkeiten, die ein Multi-Touch-Tisch, wie der xDesk, zur Verfügung stellt zu nutzen. So war es uns ein Anliegen die Multi-Touch-Funktion des Tisches bei der Konzeption zu berücksichtigen, dies taten wir indem mehrere Spieler gleichzeitig mit dem Tisch interagieren können. Beispielsweise ist es möglich, dass ein Spieler eine Spielkomponente positioniert, während ein Mitspieler zeichnet. Mit der Skalierung, Verschiebung und Drehung einiger Komponenten ermöglichten wir die Gestenerkennung der Finger. Ein anderer Aspekt, der mit dem herkömmlichen Brettspiel nicht möglich wäre, ist die Einbindung spezieller Events, die durch die Erkennung von Markern ausgelöst werden.

Aus der besonderen Art des Zeichnens mit dem Finger, ist auch der Projekttitel entstanden. „DIGITARS“ besteht aus der medizinischen Bezeichnung für Finger „digit“ und „ars“ lateinisch für Kunst.


DigitarsKonzept01.png


Zu Beginn des Spieles stellt sich jeder der vier Spieler an eine Tischkante. Aus Zwecken der Chancengleichheit ist die Zeichenfläche deshalb frei beweglich, dreh- und skalierbar. Dadurch ist es möglich, dass der zeichnende Spieler sich die Zeichenfläche so positioniert, dass er ideal zeichnen kann. Links oben an der Zeichenfläche sind verschiedene Steuerelemente abgebildet. Mit betätigen des oberen Elements ist es möglich den Standard Zeichenpinsel auszuwählen. Darunter befindet sich eine Farbauswahl, diese kann man beispielsweise betätigen, wenn man etwas an der Zeichnung besonders hervorheben möchte. Das Löschen der kompletten Malfläche wird durch das berühren des Mülleimers ausgelöst. Durch den Slider kann die Strickstärke beliebig skaliert werden.

Der Begriff, der gezeichnet werden soll muss den zeichnenden Spieler mitgeteilt werden. Hierbei ist es wichtig, dass die anderen Mitspieler den Begriff nicht sehen können. Hierzu haben wir uns im Konzepte eine Begriffabdeckung überlegt, die an der auf dem Multitouch-Tisch auflegenden Unterseite mit einem Marker versehen ist. Wird die Begriffabdeckung auf dem Tisch aufgelegt, wird der Marker auf der Unterseite erkannt. Sobald dies geschehen ist erscheint der Zeichenbegriff leicht versetzt zum Marker, so dass der Begriff für die nicht zeichnenden Spieler verdeckt ist. Wird die Begriffabdeckung von dem Spielfeld entfernt, dann wird der zugehörige Marker nicht mehr erkannt und der Begriff verschwindet vom Tisch. Mit dem berühren des Weiter-Buttons, der auf dem Spielfeld in der Form eines Pfeils dargestellt ist, kann der nächste Begriff angezeigt werden.


ActionCube.png


Jeder Spieler besitzt einen Action Cube. Ein Action Cube ist ein Würfel mit Seitenlänge 5 cm. Auf jeder Fläche des Würfels ist ein Marker angebracht. Passive Spieler, also jene die weder raten noch zeichnen, können diese in der jeweiligen Runde einsetzen. Durch Auflegen des Action Cubes auf den Multi-Touch-Tisch wird ein Event ausgelöst. Hierbei kann man zwei verschiede Arten von Events unterscheiden:

  •  Bei den „Störern“ handelt es sich um Effekte, die es den jeweiligen Spielerpaar erschweren Punkte zu erzielen. Beim ersten Störer wird die Pinseldicke verstärkt wodurch das Zeichne und das Erkennen der gezeichneten Begriffe erschwert wird. Legt man den Action Cube mit einer anderen Seite auf den Multi-Touch-Tisch erfolgt ein Punkteabzug. Ein weiterer Störer ermöglicht das Ersetzten des Malpinsels durch eine Fliegenform, was sich erneut nicht förderlich auf das schnelle erraten des Spielbegriffes auswirkt und somit das Erreichen von vielen Punkten erschwert.
  • Positive Events lösen die sogenannten „Begünstiger“ aus. Durch die Wahl eines Begünstigers erhalten die beiden aktuellen Spieler Bonuspunkte. Mehr Zeit für die Erzielung vom Punkten, erhalten der Zeichner und der Ratende, wenn einer der passiven Spieler den jeweiligen Event auslöst.

Um den jeweiligen Spielerpaar zu verdeutlichen, wie viel Zeit den beiden noch bleibt, wurde ein kreisförmiger Timer in der Mitte der Spielfläche realisiert. Zur zusätzlichen Orientierung erscheint die Zeitanzeige in der jeweiligen Spielerfarbe. Wird die Zeit knapp soll dies zusätzlich durch rote Farbe gekennzeichnet werden.


DigitarsKonzept02.png


Die aktuelle Punktzahl der Spieler sollte auf eine einfach zu erkennende Weise visualisiert werden. Sie besteht aus prozentual im Kreis angeordneten Progressbars für jeden Spieler in der jeweiligen Spielerfarbe. Für jeden erzielten Punkt erhöht sich sie Punkteanzeige. Gewinner ist derjenige, welcher zuerst die volle Punktzahl von 22 Punkten erreicht hat. Dies wird durch einen vollen Kreis auf der Progressbar signalisiert.
Auch über mögliche zukünftige Implementierungen wurden sich Gedanken gemacht. Beispielsweise könnte das Spiel dadurch gestartet werden, dass jeder Spieler mit seinem Action Cube würfelt. Das Programm würde den Markern die Augenzahlen deines normalen Würfels zuordnen. Somit könnte der Spieler mit der höchsten gewürfelten Punktzahl das Spiel beginnen. Es wurde auch überlegt eine Begriff-Kontrolle der Spielcummunity zu ermöglichen. Hierbei sollte ein Begriff-Zeigen-Button im Spielfeld integriert werden. Wird dieser betätigt wird der aktuelle Begriff offen auf der Spieloberfläche angezeigt. Jeder Spieler kann sich nun von der Übereinstimmung des geratenen und vorgegebenen Begriffs überzeugen.



Der XDesk Multitouch-Tisch

XDesk wurde von impressX hergestellt und wird für die Werbung, PoS , Präsentation, Beratung, für Museen, Veranstaltungen und Messen angeboten. Seit 2012 ist XDesk im Betrieb an der GSO-Hochschule.

Technische Eigenschaften

XDesk wiegt 76 kg und die Maße entspricht 1130 x 910 x 900 mm. Der XDesk hatte ursprünglich Windows-XP Betriebssystem und wurde auf Windows-7 aktualisiert.

Steuerungs-PC ist mit folgenden Peripherien ausgerüstet:

  • 2,4 Ghz Intel Core 2 Dual processor
  • Memory: 1GB dual Channel DDR2 (entspricht 2GB RAM)
  • Festplatte: 250 GB Serial-ATA mit 7.200 U/Min
  • ATI HD4850 Grafikkarte.

Multitouch Screen:

  • Display (lxb): 1090x790 mm
  • 52“ WXGA 3LCD-Technologie Screen
  • WXGA 1280x800
  • 1777 Millionen Farben

Kommunikation:

  • Internes Bluetooth 2.1+EDR Modul (Enhanced Data Rate)
  • 10/100/1000BASE-T Gigabit-Ethernet integriert (RJ-45-Anschluss)

Anschlüsse:

  • Fünf USB 2.0 Anschlüsse (4 Belegt)
  • Netzkabel


Komponenten des xDesk

Der xDesk-Multi-Touch-Tisch von innen:

MultiTouchTischInnen.png
Infrarot LEDs, aufgenommen mit einer Kamera ohne infrarot Filter:
IR LEDs.JPG



Die Werkzeuge

Tools.PNG

Multitouch for Java ist ein Open Source Java-Framework, der Interaktivität der Multitouch-Geräte unterstützt. 


TUIO-Protokoll bzw. Tangible user interface ist eine anfassbare Benutzerschnittstelle, die die Interaktion durch physische Objekte erlaubt. TUIO hilft uns die Eingabewerte in Finger- oder Marker-Erkennung zu unterscheiden.


Eclipse ist eine integrierte Entwicklungsumgebung (IDE), die mehrere Programmiersprachen unterstützt.


reacTIVision ist eine Open Source Tracking Software, die die MT4J unterstützt.


TUIO-Simulator ist eine Java-basierte Anwendung, die TUIO-Daten simuliert. Dieser wurde während der Treiberstörungen der Kameras und bei "Home-Programming" für Testzwecke benutzt.


Bitbucket ist ein webbasiertes Versionsverwaltungstool, das die Mercurial-Projekte fördern. Bitbucket wird von australischer Firma Atlassian betrieben und bietet kostenlose Konten, die später mit mehreren Applikationen von Atlassian verknüpft werden können.


Dropbox ist einer Datenverwaltungstool, der lokal und Gerät unabhängig überall Daten-Zugriff ermöglicht. Die Dateien zwischen verschiedenen Rechnern und Benutzern werden nach jeder Änderung synchronisiert und gleichzeitig online gesichert.


Teamviewer ist eine Desktop-Sharing-Software, die die Fernsteuerung und Datenaustausch zwischen zwei Rechnern über Netzwerk ermöglicht. Team-viewer wurde während einigen XDesk-Zugriffsstörungen eingesetzt.


Facebook-Groups wurde bei Kurzmeldungen und bei kurzfristigen Terminvereinbarungen unter Projektmitgliedern angewendet.


Skype. Die Telefonkonferenzen außerhalb der wöchentlichen Projekttreffen wurden über Skype durchgeführt. Auch Pair-Programming haben wir über Skype ge-macht.


Support. Der Hersteller impressx hat Entwickler-Unterstützung bei den Ausfällen des XDesks angeboten.

MT4J


MT4J ist die Abkürzung für „MultiTouch 4 Java“ und wurde von Christopher Ruff am Fraunhofer Institut entwickelt.
Es stellt ein Java Framework dar, welches für das grafische Rendering auf OpenGL und Processing aufbaut. Verwendet werden kann es sowohl für 2D als auch für 2.5D (pseudo 3D) Anwendungen.
Besonderer Vorteil liegt darin, dass es die Cross-platform-Funktionalität aufweist und somit auf allen Betriebssystemen läuft. Zudem ist es frei erhältlich und weist keinerlei weiteren Kosten auf.
MT4J besitzt eine Eingabe- Abstraktionsschicht , eine Szenengraphstruktur und unterstüzt die Windows7 Touch features. Auch Bitmap- und Vector-Schriften können damit aufgerufen werden und über verschiedene, individuell zum Benutzer zugeschnittene User-Interface-Komponenten wie z.B. Buttons, TextViews, ... integriert werden.
Die Übertragung der Multi-Touch-Bewegungsdaten geschieht durch Nutzung des TUIO- Protokolls (welches ebenfalls open source ist). Entsprechende WM_TOUCH-Nachrichten übertragen dann die Bewegungsinformationen auf Windows.
MT4J_und_TUIO.png


Das MT4J-Framework „hört“ -wie üblich bei den Multitouch-Frameworks- den Port 3333 auf einkommende TUIO-Daten ab. Diese werden von einem anderen Programm gesendet. In unserem Fall werden die Daten von der eigenen Tracking-Software des xdesks weitergegeben.
Sendet also die Tracking-Software die TUIO-Daten, so liest MT4J diese und bestimmt welche Art von Geste dies ist. Diese Geste kann dann von „unserem“ Programm bzw. unserer Anwendung implementiert werden.

TUIO-Protokoll

Was ist TUIO?

TUIO (Tangible User Interface Objects) ist ein quelloffenes Framework, das ein gemeinsames Protokoll und ein API für Multitouch-Oberflächen definiert. Das TUIO-Protokoll liefert eine Schnittstelle zwischen der Benutzereingabe und den zugrunde liegenden Applikationsschichten.

TUIO.png

Allgemeine Informationen zum TUIO-Protokoll

  • Ursprünglich wurde TUIO für das quelloffene Toolkit reacTIVision entwickelt
  • TUIO Basiert auf Open Sound Control, welches hauptsächlich für die Echtzeitverarbeitung von Sound und Multimedia-Installationen verwendet wird
  • Das senden der Nachrichten geschieht mittels UDP (User Datagram Protocol)

Implementierung

Das TUIO-Protokoll definiert zwei Hauptklassen von Nachrichten: SET und ALIVE

  • SET-Nachrichten → sammeln Informationen über den Zustand eines Objekts wie Position, Orientierung, Geschwindigkeit und Beschleunigung
  • ALIVE-Nachrichten→ zeigen den aktuellen Satz von Objekten die sich gerade auf der Oberfläche befinden anhand von eindeutigen Sitzungs-IDs
  • FSEQ-Nachrichten → versehen jedes Update mit einer eindeutigen Sequenz-ID

Ein TUIO-Paket besteht aus 3 Nachrichten, die Standardmäßig an den UDP Port 3333 gesendet werden:

  /tuio/2Dcur source application@address 
/tuio/2Dcur alive s_id0 … s_idN
/tuio/2Dcur set s_id x_pos y_pos x_vel y_vel m_accel 
/tuio/2Dcur fseq f_id 

Berechnung der Parameter

Das TUIO Koordinatenystem ist für jede Achse normalisiert, d.h. die X,Y Position wird im Verhältnis der Breite und der Höhe des Tisches angegeben.

  x = sensor_x / sensor_width
y = sensor_y / sensor_height 

Die Bewegungsgeschwindigkeit wird als eine Bewegung über die volle Länge einer Achse innerhalb einer Sekunde definiert. Die Beschleunigung ist die Geschwindigkeitsänderung geteilt durch den Zeitunterschied in Sekunden.

  x = (sensor_dx / sensor_width) / dt 
y = (sensor_dy / sensor_height) / dt 
m = (speed – last_speed) / dt 

Die Rotationsgeschwindigkeit wird als eine volle Umdrehung pro Sekunde gemessen. Die Drehbeschleunigung wird somit aus der Drehzahländerung geteilt durch den Zeitunterschied berechnet.

  A = ((a – last_a) / 2*PI) / dt 
r = ((A – last_A)) / dt 

Fazit

Vorteile

  • Plattformunabhängigkeit
  • Geräteunabhängigkeit, d.h. jedes Gerät kann für Eingaben verwendet werden, sofern das TUIO Protokoll vorhanden ist
  • Eingaben können über das Netzwerk gesendet werden, da Verwendung des UDP Protokolls
  • Bibliotheken für alle gängigen Programmiersprachen vorhanden

Nachteile

  • Es ist nicht ersichtlich von welchem Gerät bzw. von welcher Software die Eingabe kommt
  • Keine Authentifizierung/Autorisierung, d.h. jeder der Zugriff auf den UDP Port hat kann Eingaben senden

Spielkomponenten

Marker-Erkennung


In der MainDrawingScene der MainKlasse wird ständig auf einkommende Marker-Events ge- horcht. Dies geschieht über den „FiducialProcessor“. Er registriert alle erkannten Marker.
In einer eigenen Funktion „processInputEvent“ können nun die Marker mit den jeweiligen ID`s definiert werden. Über eine switch-case-Abfrage werden die ID`s der einkommenden Marker des MTInputEvents abgeglichen.
//fiducial-scene 
//Listen to _all_ fiducial events 
RawFiducialProcessor fiducialProcessor = new RawFiducialProcessor(); 
fiducialProcessor.addProcessorListener(this); registerGlobalInputProcessor(fiducialProcessor);
//Maps the fiducial IDs to the visible component so we can keep track
fiducialIDToComp = new HashMap<Integer, AbstractShape>(); 
font = FontManager.getInstance().createFont(pa, "arial.ttf", 30, MTColor.WHITE);

Begriff-Anzeige


Im Beispiel des Markers mit der ID = 1 soll die Begriffanzeige aktiviert werden. Die nacheinander erscheinenden Begriffe sollen direkt unter der Position des Markers auftauchen und wieder verschwinden, sobald der Marker vom Tisch entfernt wird.
Um dies möglich zu machen, wird in der switch-case eine abstrakte Komponente aufgerufen, die das Textfeld dann kreiert. Hierzu wird lediglich die ID = 1 und die Position des Markers als 3D-Vektor übergeben. In dieser AbstractShape wird dann das definierte Textfeld übergeben.
Begriffanzeige.jpg


Um verschiedene Hochschul-Begriffe anzeigen zu können, werden sie zu Beginn in einem Array abgespeichert:
// Array Begriffe
final String[] begriffe = { "Fakultät", "Mensa",
"EFI", "Vorlesung", "Prof", "Bibliothek", (...) };

Im Anschluss wird ein Textfeld erstellt. In diesem Textfeld soll zu Beginn ein zufälliger Begriff angezeigt werden. Dies geschieht über die Random-Funktion. Ziel ist es, durch Klick auf einen Next-Button, einen neuen zufälligen Begriff zu bekommen. Hierfür wird ein Gesture- Listener benötigt, welcher ständig hört, ob eine Touch-Geste auf diesen Button ausgeübt wird. Ist dies der Fall, also „if (te.isTapped)“, dann wird das alte Textfeld gelöscht und ein neuer Begriff erscheint. Die Position des Begriffes bleibt die vorherige.

Störeffekte


Ein Störeffekt des Tabu-Spieles soll das erschwerte Zeichnen sein. Die Pinselstärke soll ziemlich dick und ungenau dargestellt werden, sodass das gezeichnete Bild nur noch schwer zu erkennen ist. Hierfür muss auf den „pencilBrush“ der Zeichenfläche zugegriffen werden. Dieser „pencilBrush“ setzt sich lediglich aus einer Ellipse zusammen, welche eine bestimmte Farbe und ein Radius zugewiesen wird. Um diese Pinselstärke nun zu verändern, wird die Segmentzahl einfach von 60 auf 90 erhöht und der Radius verringert. Das Ergebnis sieht wie folgt aus:
Stoereffekt_Pinsel.png


Spielelogik


Um die Logik des Tabu-Spieles implementieren zu können, mussten folgende Komponenten beachtet werden:

  • Zu Beginn wird ein Spieler (der Malende) per Zufall ausgewählt
  • Automatisch erscheint die Spielfarbe des Timers in seiner Farbe (und per Touch startet dieser dann)
  • Ein Teampartner (der Errater) wird dann ebenfalls per Zufall ermittelt und über eine Textanzeige wird mitgeteilt, wer der 2. Spieler ist
  • Sollte der Begriff erraten werden und man toucht auf den Button „Begriff richtig“, so erhalten beide Spieler (sowohl der Zeichner, als auch der Errater) einen Punkt!
private void definePlayer() { 
//Define Start-Players
Random r = new Random(); 
Random r2 = new Random(); 
final int Teamkollege; 
// Spieler 1 startet
if (r.nextInt(4) == 1) {
    //Farbe des Timers ist die des Spieler 1
    whichPlayer = 0; 
    //ermittelt Teamkollegen if (r2.nextInt(4) == 1) {
        (...) } 
    else if (r2.nextInt(4) == 2) {
        (...) } 
    else if (r2.nextInt(4) == 3) {
        (...) }
    else{
        (...) } 
    //Punktzähler bei richtigem Begriff
    (...)
    if (te.isTapped()) { 
        //Spieler 1 (=Zeichner) erhält einen Punkt 
        player1++; 
        if (Teamkollege == 2) {
            //Wenn Spieler 2 = Errater, dann bekommt er auch einen Punkt
            player2++;
        } (...)
     }return true;
}
// Spieler 2 startet
(...)}

Spielmenü

Um die benutzergesteuerte Navigation zwischen den verschiedenen Spielebenen zu ermöglichen, wurde ein Spielmenü entworfen. Es sollte möglich sein, vom Startscreen aus das Spiel zu starten. Um dies reibungslos zu ermöglichen soll nach starten des Spiels das Spielmenü automatisch erscheinen und den Spieler verschiedene Auswahlmöglichkeiten zur Verfügung stellen. Hierfür wurden vier, einfach zu erkennende, Buttons von den Studenten des Studiengangs Design entworfen.


Der Button „Start Game“ sollte alle Spielkomponenten auf den Bildschirm laden und anschließend das Spiel starten. Die in einer späteren Version geplanten Minigames sollten durch drücken auf den zugehörigen Button „Start Minigame“ gestartet werden. Möchte man ein bereits angefangenes Spiel, nach einer Unterbrechung weiterführen, so wählt man „Continue Game“. Durch „Exit Game“ wird das Spiel erwartungsgemäß beendet.


Es sollte möglich sein das Spielmenü frei über das Spielfeld zu bewegen. Das Skalieren des Menüs sollte unterbunden werden.

Auf der ersten Szene der Applikation ist das Spielmenü zu sehen:

SpielMenu.jpg
Mit Hilfe des Spielmenüs kann man verschiedene, durch Buttons dargestellte Optionen wählen:
  • Start Game
  • Continue Game
  • Start Minigame
  • Exit Game

Timer

Die Umsetzung des Timers wurde mit OpenGL realisiert. Dabei wurde für jede Ebene (Vordergrund und Hintergrund) ein Wireframemodell erstellt.

Timer Texturierung.png

Der Code dazu lautet wie folgt:

  g.pushMatrix();
     g.translate(center.x,center.y);
     g.rotate(-g.PI/2);
     g.beginShape(g.TRIANGLE_STRIP);
             g.texture(tex);
             g.textureMode(PConstants.NORMALIZED);
             for(float theta=g.TWO_PI*offset; theta<g.TWO_PI; theta+=g.TWO_PI/(segmente*seconds)) {
                     g.vertex(0,0,0.5f,0.5f);
                     g.vertex((float) (radius*Math.cos(theta)), (float) (radius*Math.sin(theta)),0.75f,0.75f);
             }    
             g.vertex(0,0,0.5f,0.5f);
             g.vertex( (float) (radius*Math.cos(g.TWO_PI)), (float) (radius*Math.sin(g.TWO_PI)), 0.75f,0.75f);
     g.endShape();
g.popMatrix();</code>

Bei jeder Zeiteinheit bekommt der Kreis einen späteren Startwert, wodurch die Bewegung entsteht. Im obigen Code ist dies durch die Offset Variable realisiert. In der drawComponent Methode wird durch eine bedingte Verzweigung bestimmt, welche Textur für welchen Spieler dargestellt wird:

  public void drawComponent(PGraphics g) {
     super.drawComponent(g);
     g.smooth();
     if(ctrTime/ctrDuration > 0.8) {
     drawRedDisc(g,80*ctrTime/ctrDuration,60,0);
     }
     drawDisc(g,100,60,0,texBackground);
     if(whichPlayer==0)
             drawDisc(g,100,ctrDuration,ctrTime,texGreen);
     else if(whichPlayer==1)
             drawDisc(g,100,ctrDuration,ctrTime,texBlue);
     else if(whichPlayer==2)
             drawDisc(g,100,ctrDuration,ctrTime,texRed);
     else if(whichPlayer==3)
             drawDisc(g,100,ctrDuration,ctrTime,texYellow);
     if(isRunning) {
             ctrTime += ((float) framerate/60)/ctrDuration;
             if(ctrTime > ctrDuration)
                     isRunning = false;
     }
}

Der rote Schatten, der erscheint wenn die Zeit knapp wird, wurde nicht mit einer Textur umgesetzt sondern direkt mit einem Farbverlauf in OpenGL gezeichnet:

  g.pushMatrix();
     g.translate(center.x,center.y);
     g.rotate(-g.PI/2);
     g.beginShape(g.TRIANGLE_STRIP);
     for(float theta=g.TWO_PI*offset; theta<g.TWO_PI; theta+=g.TWO_PI/ (segmente*seconds)) {
             g.fill(155,25,25,155);
             g.vertex(0,0);
             g.fill(255,50,50,30);
             g.vertex((float) (radius*Math.cos(theta)),(float) (radius*Math.sin(theta)));
     } 
     g.fill(155,25,25,155);
     g.vertex(0,0);
     g.fill(255,50,50,30);
     g.vertex( (float) (radius*Math.cos(g.TWO_PI)), (float) (radius*Math.sin(g.TWO_PI)));
     g.endShape();
g.popMatrix();

Progressbar

Bei der Umsetzung der Progressbar war das Vorgehen ähnlich wie beim Timer. Der einzige Unterschied bestand hier in der Art der Texturierung. Aufgrund des im Bild unten dargestellten Farbverlaufs musste das Texture Mapping mit UV-Koordinaten vorgenommen werden:

  for(float theta=0; theta<=g.TWO_PI*offset; theta+=g.TWO_PI/(4*score)) {
     g.vertex(0,0,0.5f,0.5f);
     xcos = (float) Math.sin(theta);
     ysin = (float) -Math.cos(theta);
     g.vertex(xcos*radius,ysin*radius,0.5f*xcos+0.5f,0.5f*ysin+0.5f);
}
Progressbar.png

Zeichenfläche

Anfangs war es uns wichtig möglichst schnell ein lauffähiges Programm zu haben auf dem man aufbauen kann. Der Framework MT4j bietet bereits eine Vielzahl an fertigen Komponenten an, darunter auch eine Zeichenfläche. Diese haben wir übernommen und für unsere Zwecke modifiziert.

Anpassungen am Aussehen

In der MT4j Variante waren einige unnötige Funktionen wie Speichern, oder verschiedene Pinselarten vorhanden, diese wurden entfernt. Auch die vorhanden Buttons wurden durch schlichtere ersetzt. Eine weitere Änderung wurde am Format der Zeichenfläche vorgenommen. Dieses wurde relativ zur Bildschirmgöße angepasst, so dass auch verschiedene Bildschirmgrößen ein konsistentes Aussehen haben:

  frame.setSizeXYGlobal(pa.width *0.5f, pa.height *0.5f);

Zuletzt wurde noch der Radius der Ecken verkleinert, um das Aussehen einem Blatt Papier anzunähern. Dazu wurde die Komponente MTRoundRectangle durch MTRectangle ersetzt und die Parameter entsprechend angepasst:

  MTRectangle frame = new MTRectangle(pa, -50, -50, 0, pa.width + 100, pa.height + 100);

Zeichenfläche vorher nachher.png


Anpassungen am Verhalten

Ein Problem welches durch die vordefinierte Zeichenfläche entstanden ist, war die beliebige Skalierbarkeit. Es hat sich herausgestellt, dass es während dem Spiel sehr leicht passieren kann, dass man die Zeichenfläche aus Versehen zu klein skaliert und sie danach nicht mehr vergrößern kann. Um den Spielfluss nicht zu stören haben wir uns deshalb dazu entschieden die Skalierbarkeit zu entfernen. Hierzu wurden zunächst alle Standard Input Prozessoren entfernt und danach die gewünschten wieder hinzugefügt (in unserem Falle verschieben und rotieren):

  frame.unregisterAllInputProcessors();
 frame.registerInputProcessor(new DragProcessor(pa));
 frame.registerInputProcessor(new RotateProcessor(pa));

Projektergebnis

Scene2.jpg

Weblinks


Interner Bereich: