Interaktiver Beerpongtisch

Aus toolbox_interaktion
Wechseln zu: Navigation, Suche

Das Projekt interaktiver Beerpongtisch war eine Semesterarbeit des Fachbereichs Elektrotechnik im Wintersemester 17/18.

!!!Wichtig: Bei Beerpong steht der Wettkampfcharakter und nicht der Alkoholgenuss im Vordergrund!!!

Beschreibung der Projektidee

Die Idee war es das für Studenten interessante Spiel Beerpong interaktiv umzusetzen. Das Spiel ist für 4 Personen gedacht, die in 2 Teams gegeneinander spielen können. Gespielt wird dabei nach internationalen Beerpongregeln.

Spielprinzip

Üblicherweise wird Beer Pong im 2-gegen-2-Modus gespielt. Die gegnerischen Teams werfen dabei jeweils auf eine Dreiecksformation von zehn Bechern auf der gegenüberliegenden Seite des Spielfeldes. Dabei werfen immer beide Spieler eines Teams, bevor der Ballbesitz wechselt. Im Spielbetrieb muss die gegnerische Mannschaft jeden Becher, der getroffen wurde, austrinken. Es gibt dabei unterschiedliche Arten von Treffern. Wurde der Ball direkt in einen gegnerischen Becher befördert, so gilt es für den Gegner, diesen Becher zu trinken. Gelangt aber der Ball über eine Tischberührung in den Becher, so muss das gegnerische Team zwei Becher trinken(einer davon der getroffene Becher). Treffen beide Spieler eines Teams in den selben Becher des Gegners, muss zusätzlich zur Anzahl der zu trinkenden Becher ein weiterer Becher ausgetrunken werden.

Spielgewinn

Die Mannschaft, die zuerst alle Becher des Gegners treffen konnte, ist das siegreiche Team. Das Verliererteam hat im Anschluss die Becher zu trinken, die sie im Spielgeschehen nicht treffen konnten.

Vorgehen beim Projekt

Bei der Semesterarbeit sollte das oben genannte Spielgeschehen im Groben interaktiv umgesetzt werden. Dabei wurde vor allem auf zwei Hauptaufgaben wert gelegt. Dies war zum einen die Detektion des Ballwurfs und zum anderen das Programmieren der Spiellogik. Programmiert wurde dabei in OpenFrameworks.

Schaubild

Schaubild Interaktiver Beerpongtisch.PNG


Programmierung der Spiellogik

Bei der Programmierung der Spiellogik war das Hauptaugenmerk auf dem ordnungsgemäßen Ausführen des oben näher erläuterten Spielprinzips. Über einen Startknopf kann dabei das Spielgeschehen gestartet werden. Dabei war darauf zu achten, dass je zwei Würfe pro Team anerkannt werden und anschließend der Ballbesitz wechselt. Die Informationen über Treffer oder Fehlwurf werden dabei durch die Detektion des Ballwurfs an die Spiellogik übergeben. Ebenso wird der Spielstand sowie die Spielrichtung dauerhaft angezeigt. Ebenso wird bei Treffer eine Ausgabe eingeleitet und der Spielstand angepasst. Das Spielende wird abhängig vom Spielstand am Ende ebenso angezeigt.

Der Code für die Spiellogik sah dabei wie folgt aus:

Code Teil1.PNG

Code Teil2.PNG

Code Teil3.PNG

Code Teil4.PNG

Code Teil5.PNG

Der Code ist dabei ebenfalls im Content Service erhältlich.

Angedacht war hierbei die Ausgabe über einen Beamer auf dem Spieltisch anzuzeigen, was aufgrund zeitlicher Probleme allerdings nicht weiter getestet werden konnte.

Detektion des Ballwurfs

Für die Interaktion zudem notwendig war die Wurfdetektion des orangefarbenen Spielballes. Hierfür wurde die benötigte orangene Farbe des Spielballes im HSV-Farbraum über die angegebenen Schwellwerte selektiert und mit einer hohen Sättigung verküpft, um den Weiß-Ton aus dem Bild zu entfernen. Folgendes Ergebnis der Selektion im Ergebnisfenster von OpenFrameworks konnte dabei erzielt werden:

Balldetektion.PNG

Das in OpenFrameworks erstellte Programm sieht folgendermaßen aus:

Tracker Teil1.PNG

Tracker Teil2.PNG

Tracker Teil3.PNG

Tracker Teil4.PNG

Zusammenspiel zwischen Spiellogik und Balldetektion

Um Wurfdetektion und Spiellogik zusammen einsetzen zu können, wurden die beiden Programme in einem Projekt verküpft. Hierdurch war es möglich, das Spielgesehen mit den implementierten Funktionen aus einem Programm in OpenFrameworks heraus öffnen zu können.

Alternativ wäre auch eine Verknüpfung über die OSC-Schnittstelle möglich gewesen. Dabei hätte man ein Programm als OSC-Server und das andere als OSC-Reciever einstellen müssen.

Weitere mögliche Aufgaben

Mögliche Erweiterungen, die ebenfalls aufgrund fehlender Zeit nicht weiter umgesetzt werden konnten, sind die Bechererkennung. Durch geeignetes Programm sowie Kamera kann hierbei der Stand der Becher genau aufgenommen und dadurch auch in die Spiellogik eingebaut werden. Ebenso kann die Starterkennung bei vorhandener Kamera im Anschluss auch über QR-Code oder ähnlichem vorgenommen werden.

Fazit des Projekts

Am Ende der Projektphase wurden die Schwierigkeiten herausgefiltert und ein abschließendes Fazit gezogen.

Schwierigkeiten

Die Programmierung in OpenFrameworks bereitete uns zu Beginn des Projekts einige Schwierigkeiten. Nach Überlegungen über die Spiellogik und der Programmierung in einem C-Compiler, mussten wir feststellen, dass der Ablauf in OpenFrameworks so nicht funktioniert. Das Problem lag darin, dass in OpenFrameworks die verschiedene Funktionen zyklisch abgearbeitet werden und so unsere While-Schleifen zu einem Aufhängen des Debug-Vorgangs führten. Die Anpassung an diesen Standard hat uns dabei einiges an Zeit gekostet. Ebenso hatten wir Probleme bei der Balldetektion. So war die Surface-Webcam für die Aufnahme zu ungenau und führte zu missverständlichen Ergebnissen, die wir unnötig lange versuchten zu deuten. Nach Umstieg auf eine bessere Kamera konnte dieses Problem anschließend behoben werden.

Fazit

Nach reibungsfreiem Einstieg in das Projekt haben die erwähnten Probleme dazu geführt, dass wir nicht alle unserer Ziele in die Tat umsetzen konnten. Dennoch konnten wir eine funktionierende Spiellogik programmieren, die mit der Eingabe aus der Balldetektion eine geeignete Ausgabe und dadurch einen geordneten Spielbetrieb gewährleisten.

Link

SourceCode im OCS