Entwicklung einer netzwerkfähigen Brettspiele-App für

Transcrição

Fachbereich 3: Mathematik und Informatik
Bachelorarbeit
Entwicklung einer netzwerkfähigen Brettspiele-App
für Android Tablets mit realen Spielfiguren
Jeffrey Wolfe [email protected] 236 957 8
Saskia Müller [email protected]
236 720 9
1. Oktober 2012
1. Gutachter: Dr. Christoph Stahl
2. Gutachter: Prof. Dr. Bernd Krieg-Brückner
Jeffrey Wolfe, Saskia Müller
Entwicklung einer netzwerkfähigen Brettspiele-App für Android Tablets mit realen Spielfiguren
Bachelorarbeit, Fachbereich 3: Mathematik und Informatik
Universität Bremen, Dezember 2012
Bachelorarbeit
Entwicklung einer netzwerkfähigen Brettspiele-App für Android Tablets mit realen
Spielfiguren
Selbstständigkeitserklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig angefertigt, nicht anderweitig zu
Prüfungszwecken vorgelegt und keine anderen als die angegebenen Hilfsmittel verwendet habe.
Sämtliche wissentlich verwendete Textausschnitte, Zitate oder Inhalte anderer Verfasser wurden
ausdrücklich als solche gekennzeichnet.
Bremen, den 1. Oktober 2012
Jeffrey Wolfe
Saskia Müller
3
Inhaltsverzeichnis
Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
1 Einleitung
1
1.1
Motivation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3
Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Ähnliche Projekte
2.1
2.2
2.3
2.4
2.5
2.6
3
iPawn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
zAPPed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
ePawn Arena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.1
Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Disney’s Appmates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.4.1
Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Dice+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.5.1
Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3 Konzeption von Brettspielen
11
3.1
Geschichtlicher Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
Klassische Brettspiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.3
Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.4
Spielablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.4.1
Gerichteter Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.5
Spielfiguren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.6
Spielzug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.6.1
17
Spielzug Ende erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Technische Grundlagen
19
i
Bachelorarbeit
Spielfiguren
4.1
4.2
4.3
4.4
4.5
Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.1.1
Dalvik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.1.2
Android Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.1.2.1
Androidmanifest.xml . . . . . . . . . . . . . . . . . . . . . . . .
21
4.1.2.2
Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.1.2.3
Intents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2.1
Simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.3.1
Jingle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.4.1
Khronos Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.4.2
OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.4.3
WebGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.4.4
OpenGL ES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.4.5
Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.4.6
OpenGL Räume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
Touchscreens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.5.1
Resistive Touchscreens . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.5.2
Surface Acoustic Wave Touchscreen . . . . . . . . . . . . . . . . . . . . .
31
4.5.3
Infrarot Touchscreens . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.5.4
Kapazitive Touchscreens . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.5.5
Multitouch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.5.6
Was wir verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5 ANABEL
5.1
5.2
5.3
36
5.1.1
Vorüberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.1.1.1
Spielfiguren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.1.1.2
Würfel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2.1
38
Acer Iconia A200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.3.1
Spiel Erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3.1.1
Login Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3.1.2
Choice Activity
. . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3.1.3
Create Game Activity . . . . . . . . . . . . . . . . . . . . . . . .
40
5.3.1.4
XMPP Activity . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Spiel Beitreten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.3.2
ii
35
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bachelorarbeit
Spielfiguren
5.3.2.1
Login Activity und Choice Activity . . . . . . . . . . . . . . . .
41
5.3.2.2
Join Game Activity . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.3.2.3
Accept Invite Activity . . . . . . . . . . . . . . . . . . . . . . . .
42
5.3.2.4
Spielansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6 Implementierung
47
6.1
Android Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
6.2
Boardgame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.2.1
GameApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.2.1.1
Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.2.1.2
Spielfigur setzen . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
CreateGameActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.2.2.1
Take Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
XMPPActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Spielobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.3.1
Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Spieldarstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.4.1
GameView
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
6.4.2
GameRenderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.4.3
RendererDie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.4.4
Texturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
Netzwerkkommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.5.1
Funktionsweise XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
6.5.2
Klasse Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
6.5.3
Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
6.5.4
6.2.2
6.2.3
6.3
6.4
6.5
6.6
6.7
Network Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Interne Abläufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.6.1
Spiel Erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
6.6.2
Spiel Beitreten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
6.6.3
Spielzüge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
Ausblick Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
6.7.1
Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
6.7.1.1
StateRule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
6.7.1.2
MoveRule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
6.7.2
7 Fazit und Ausblick
85
7.1
Was Implementiert wurde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
7.2
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
A Appendix
87
iii
Bachelorarbeit
Spielfiguren
iv
A.1 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
A.2 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
A.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.4 Arbeitsanteil an ANABEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
Bachelorarbeit
Spielfiguren
Abbildungsverzeichnis
2.1
iPawn Gänsespiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
zAPPed edition! Quelle: http://volumique.com/ . . . . . . . . . . . . . . . . . . .
4
2.3
ePawn Arena Quelle: http://www.ePawn.fr/ . . . . . . . . . . . . . . . . . . . . .
6
2.4
Appmates Quelle: http://www.langitberita.com . . . . . . . . . . . . . . . . . . .
7
2.5
DICE+ Quelle: http://scr3.golem.de/screenshots/1206/Dice/DICEcolors.jpg . . .
8
3.1
Mensch ärgere dich nicht Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
5.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.2
Login Activity
39
5.3
Choice Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.4
Create Game Activity Online Modus, vier Spieler Ansicht . . . . . . . . . . . . .
40
5.5
XMPP Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.6
Join Game Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.7
Accept Invite Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.8
Spielansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.9
Angezeigtes Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.10 Gewinnmeldung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.1
Klassendiagramm Paket Boardgame . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.2
Reduzierte Klasse GameApp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.3
Reduzierte Klasse CreateGameActivity . . . . . . . . . . . . . . . . . . . . . . . .
51
6.4
gameLogic Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.5
Spiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.6
Renderer-Paket Klassendiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.7
reduzierte GameView Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
6.8
reduzierter GameRenderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.9
Standart Feld Textur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6.10 Hervorgehobene Textur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6.11 Würfel Textur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.12 reduzierter RendererDie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
6.13 Spielbrett Textur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
6.14 Spielzug Textur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.15 Foto Umrandungs Texturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.16 Klassendiagramm Network Paket . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
6.17 Klasse Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
6.18 Interner Spielablauf beim Spiel erstellen . . . . . . . . . . . . . . . . . . . . . . .
77
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
Bachelorarbeit
Spielfiguren
6.19 Interner Spielablauf beim Spiel beitreten . . . . . . . . . . . . . . . . . . . . . . .
79
6.20 Interner Spielablauf beim Spielzug . . . . . . . . . . . . . . . . . . . . . . . . . .
81
6.21 Klassendiagramm Verallgemeinerung von Regeln . . . . . . . . . . . . . . . . . .
82
A.1 QR Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
1
Kapitel 1
Einleitung
1.1
Motivation
Jeffrey Wolfe
Ein gemütlicher Spieleabend mit Freunden und Familie ist ein sehr beliebter Zeitvertreib, bei dem
man wunderbar das Zusammengehörigkeitsgefühl stärken kann. Außerdem eignen sich Brettspiele
für eigentlich jeden, egal ob jung oder alt. Leider ist es oft nicht möglich zusammen zu spielen,
da man z.B. zu weit voneinander entfernt wohnt, es an Zeit mangelt oder es einfach an der
Organisation, alle an einem Ort zu versammeln, scheitert. Wie macht man es nun einfacher,
dass man unabhängig vom Ort mit jemandem spielen kann? Typischerweise dienen in dieser
Situation Computerspiele, jedoch sind diese gerade für ältere Menschen meist ungeeignet, da
ihnen der Umgang mit Computern schwer fällt oder einfach nicht gefällt. Stattdessen haben wir
uns überlegt, wie man dem echten Brettspiel möglichst nahe kommt und trotzdem entferntes
Spielen über das Internet realisieren kann. Da wir aus dem bereits genanntem Grund Computer
ausgeschlossen haben, boten sich Tablets an, die sich zurzeit immer größerer Beliebtheit erfreuen.
Ein Tablet lässt sich wie ein Spielbrett flach auf den Tisch legen und über den Bildschirm
bedienen. Um so nah wie möglich am echten Brettspiel zu bleiben, wollen wir aber Spielfiguren
statt eines Fingers nutzen.
1.2
Ziel der Arbeit
Das Ziel unserer Arbeit ist es, eine Android App für Tablets zu entwickeln, mit der es möglich
ist, klassische Brettspiele mit echten Figuren, gemeinsam über das Internet an verschiedenen
Orten spielen. Die App soll leicht bedienbar sein und auch auf die Bedürfnisse von Älteren
angepasst sein, z.B. durch große Schrift. Mit der App sollen verschiedene Brettspiele gespielt
können und der Spielablauf dabei so natürlich wie möglich gestaltet werden. Das bedeutet, dass
1
Bachelorarbeit
Spielfiguren
1.3. ÜBERBLICK
wie bei Brettspielen aus Pappe keinerlei bzw. so wenig wie möglich Unterstützung im Bezug auf
Spielregeln geschieht.
Da auch entfernte Spieler mitspielen können sollen, müssen wir allerdings immer protokollieren,
welcher Spieler gerade am Zug ist, an welcher stelle sich die Figuren befinden und wann ein Zug zu
Ende ist. Der Würfel soll hierbei ein dreidimensionaler virtueller Würfel sein. Mit der App sollen
auch Fotos der Spieler gemacht werden können, um sich so näher mit den entfernten Personen
verbunden zu fühlen. Auch sollen die Fotos Anzeigen, wer gerade am Zug ist. Um die klassischen Brettspiele in die heutige Zeit zu versetzten, soll jedes Brettspiel visuelle Unterstützungen
bieten und die Kommunikation an der mehrere Personen an verschiedenen Orten teilnehmen
soll über XMPP laufen. Unterstützt werden, sollen zwei bis vier Personen Spiele. Diese sollen
an mindestens zwei verschiedenen Orten und an mindestens zwei verschiedenen Tablets spielbar
sein.
1.3
Überblick
Bevor wir mit der Arbeit an unserer App angefangen haben, haben wir uns darüber informiert,
was es bereits für ähnliche Projekte gibt, darum befassen wir uns im zweiten Kapitel mit diesen
und grenzen uns von diesen ab. Im dritten Kapitel gehen wir genauer auf Brettspiele ein und
speziell darauf, auf was man bei Mensch ärgere dich nicht achten muss, damit wir dieses Spiel
auf dem Tablet und über das Internet Spielen können. Im vierten Kapitel erklären wir alle
Grundlagen, die für das weitere Verstehen unserer Bachelorarbeit nötig sind. Im fünften Kapitel
stellen wir die entwickelte App und das benutzte Tablet vor. Anschießend folgt im sechsten
Kapitel die Implementierung unserer App und als letztes in Kapitel sieben folgt unser Fazit und
ein Ausblick darüber, was noch umgesetzt werden kann.
2
Kapitel 2
Ähnliche Projekte
In diesem Kapitel stellen wir einige Projekte vor, die unserem mehr oder weniger ähneln und
grenzen uns von ihnen ab, um hervorzuheben, was an unserem Projekt neu ist.
2.1
Abbildung 2.1
Jeffrey Wolfe
iPawn Gänsespiel
Quelle: http://wpuploads.appadvice.com/wp-content/uploads/2011/11/iPawn.jpg
3
Bachelorarbeit
Spielfiguren
2.2. ZAPPED
Die Spielefirma Jumbo vertreibt unter dem Namen iPawn eine Reihe von Gesellschaftspielen,
die auf einem Ipad gespielt werden können. Für jedes der Spiele werden spezielle Spielfiguren
und Spielaccessoires verkauft, für die man eine kostenlose Spiele App herunterladen kann. Diese
Spielfiguren sind dafür ausgelegt zur Interaktion mit dem Spiel zu dienen, je nach Spiel und Figur
werden im Spiel unterschiedliche Dinge ausgelöst.[14]
2.1.1
Abgrenzung
iPawn ist unserem Projekt sehr ähnlich, zwei der bisher erhältlichen Spiele, Gänsespiel und
Leiterspiel, sind ebenfalls Brettspiele. Damit eine Interaktion zwischen Figuren und dem Tablet möglich ist, werden genau wie in unseren Projekt leitfähige Figuren genutzt. Das größte
Unterscheidungsmerkmal ist das Fehlen einer Möglichkeit die Spiele auf verschiedenen Tablets
miteinander zu spielen.
2.2
zAPPed
Die Firma Volumique entwickelt unterschiedliche Augmented Reality Apps für iOS, die entweder
die Kamera des iPhones bzw. iPads oder den Touchscreen dazu nutzen eine App und die Realität
miteinander zu verbinden. Unter der Bezeichnung zAPPed Edition! werden diese von Hasbro verkauft. Zwei dieser Spiele, BattleShip Zapped Edition und SPELLSHOT zAPPed edition!, ähneln
dabei dem was wir in unserem Projekt umsetzen wollen.
Abbildung 2.2
zAPPed edition! Quelle: http://volumique.com/
Die Figuren haben eine leitfähige Lackierung, die die Unterseite nicht komplett bedeckt. So hat
jede Figur mehrere Touch-Punkte, die in einer bestimmten Form angeordnet sind, damit ein
4
Bachelorarbeit
Spielfiguren
KAPITEL 2. ÄHNLICHE PROJEKTE
Muster entsteht durch das man die Figuren voneinander unterscheiden kann.[20]
2.2.1
Abgrenzung
Wie bereits iPawn unterscheiden sich diese Produkte vor allem durch das Fehlen eines Netzwerkmodus. Außerdem kann man nicht jede beliebige Figur aus einem Leitfähig Material nehmen,
sondern braucht die passenden Figuren für die jeweilige App.
2.3
ePawn Arena
Saskia Müller
Die Firma ePawn [8] hat eine neue Technologie entwickelt, die vorraussichtlich Ende des Jahres
auf dem Markt erscheint. Es handelt sich um die ePawn Arena. Wenn es erscheint, wird es
ein 26” Display, welches Figuren erkennen und Bewegungen verfolgen kann. Der momentane
Prototyp ist noch deutlich kleiner und dicker als das finale Gerät sein soll. An dieses Display
kann jedes Smartphone oder Tablet angeschlossen werden, auf dem Android oder iOS laufen.
Auf den angeschlossenen Geräte läuft das Spiel und die Logik, nicht auf dem Display selber.
Die Entwickler von ePawn stellen ein SDK bereit, mit dem jeder seine eigenen Spiele entwickeln
kann. Die ePawn Arena kann bis zu 80 Figuren erkennen. Die Figuren sind mit Tags ausgestattet,
durch die es möglich ist, die Ausrichtung, die Ausrüstung und den Typen der Figur zu erkennen.
Hierdurch können auch Tabletop Spiele umgesetzt werden.
5
Bachelorarbeit
Spielfiguren
2.4. DISNEY’S APPMATES
Abbildung 2.3
2.3.1
ePawn Arena Quelle: http://www.ePawn.fr/
Abgrenzung
ePawn Arena unterscheidet sich in mehreren Dingen von unserem Projekt. Zum Einen benutzt
die ePawn Arena ein eigenständiges Display, welches Möglichkeiten zur Figurerkennung und
Verfolgung bietet und keinerlei Spiellogik in sich hat. Zum Anderen ist es eher auf Tabeltop Spiele
als auf klassische Spiele ausgelegt, die aber dennoch implementiert werden könnten. Außerdem
gibt es keine Möglichkeit, mehrere ePawn Arenas über das Internet zu verbinden und so über
Entfernung mit Freunden zu Spielen.
2.4
Disney’s Appmates
Bei der App Disneys Appmates [3] handelt es sich um eine App für Ipads, bei der man mit einem
Auto aus dem Film ”Cars”, einem Spielzeugauto zum Anfassen, auf verschiedenen Untergründen
fährt. Beispielsweise kann das Auto über Hindernisse springen, was durch schöne Animationen
dargestellt wird. Auch Rennen gegen virtuelle Autos können gefahren werden. Bei diesen Rennen
bewegt man das Auto kaum, das Meiste passiert durch gut gemachte Animationen und Drehen
des Autos in die Richtung, in die es fahren soll. Damit das Auto bzw. die Bildschirmanimation sich
bewegt, muss das Auto nur leicht nach unten gedrückt werden, dadurch reagieren die Sensoren
die unter dem Auto angebracht sind. Begleitet wird das Spiel von passenden Sounds.
6
Bachelorarbeit
Spielfiguren
Abbildung 2.4
2.4.1
Appmates Quelle: http://www.langitberita.com
Abgrenzung
Disney’s Appmates ist am weitesten von unserem Projekt entfernt, da es nichts mit Brettspielen
im eigentlichen Sinne zu tun hat. Die Ähnlichkeit zu unserm Projekt ist, dass echte Figuren auf
einem Tablet benutzt werden und somit eine erweiterte Realität geschaffen wird. In der Art und
Weise, wie die Welt geschaffen wird unterscheidet es sich sehr, da sich die Welt laufend ändert
und die ganze Zeit animiert ist. Unser Animationen sind nur beim Würfeln oder wenn ein Event
erfolgt.
2.5
Dice+
Dice+ ist ein Würfe,l der über Bluetooth das Würfelergebnis an ein Tablet sendet. Die Macher
von DICE+ [6], GIC wollen mit diesem Würfel das Misstrauen der Menschen in die Zufälligkeit
der Digitalen Würfel unterbinden. Der Würfel hat eine weiche, gummiartige Oberfläche mit
einer Seitenlänge von einem Inch. Die Batterien halten bis zu 20 Stunden Dauerrollen oder
realistischer ca. eine Woche bei normalem Gebrauch und ist wiederaufladbar über MicroUSB.
7
Bachelorarbeit
Spielfiguren
2.5. DICE+
Benutzen kann man diesen bei bisher sieben Spielen, die die Firma entwickelt hat. Darunter
befindet sich beispielsweise Ludo, welches dem Spiel Mensch ärgere dich nicht sehr ähnelt. Sie
wollen also, so wie wir das Gefühl des echten Brettspielfeeling, nur legen sie ihren Fokus auf
den Würfel und nicht auf die Figuren. Die sieben Spiele laufen auf Tablets und werden über
den Finger gesteuert. Ein Erscheinungstermin steht noch nicht fest, aber der Preis wird sich
vermutlich um die 30 Dollar belaufen.
Abbildung 2.5
2.5.1
DICE+ Quelle: http://scr3.golem.de/screenshots/1206/Dice/DICEcolors.jpg
Abgrenzung
Bei DICE+ werden ebenfalls Brettspiele für Tablets entwickelt, die mit echtem Spielzubehör
laufen sollen. Hierbei wird ein echter Würfel benutzt, den wir auch noch entwickeln möchten,
allerdings wollen wir die Möglichkeit geben, auch einen digitalen Würfel zu benutzen. Außerdem
wollen wir eher einen klassischen Plastikwürfel inklusive des Würfelbechers haben, als einen mit
einer Gummioberfläche. Zudem Benutzen wir echte Figuren und mit unserer App kann man über
das Internet mit anderen Spielern spielen.
8
Bachelorarbeit
2.6
Spielfiguren
Fazit
In der unten stehenden Tabelle 2.1 zeigen wir die Stärken und Schwächen der Einzelnen Projekte,
dabei stellt sich heraus, dass wir in einem bzw. zwei Punkten als einzige als Positiv in der
Tabelle auftauchen. Das bedeutet, dass unser Projekt, das einzige ist, bei dem es Möglich ist
über das Internet mit anderen zu Spielen. Auch das aufnehmen von Fotos, ist bei uns einzigartig,
dieses Resultiert allerdings daraus, das wir die einzigen mit einem online Spiel sind. Ohne über
Entfernung zu spielen, ist es nicht nötig, Bilder zu übertragen, da sich die Personen gegenüber
Sitzen. In einem Punkt sind wir allerdings zur Zeit etwas schlechter, als die anderen Projekte.
Animationen haben wir zum jetzigen Zeitpunkt noch nicht sehr viele, dieses soll sich aber noch
ändern.
Feature
iPawn
ePawn
DICE+
Appmates
zAPPed
ANABEL
Echte Spielobjekte
+
+
+
+
+
+
Klassische Spiele
+
+
+
-
+
+
Besondere Spiele (Tabletop)
-
+
-
+
+
-
Animationen
+
+
+
+
+
0
Netzwerk
-
-
-
-
-
+
Tabelle 2.1
Schwächen und Stärken der einzelnen Produkten
9
Kapitel 3
Konzeption von Brettspielen Saskia Müller
Jeder kennt sie und jeder hat schon einmal welche gespielt: Die klassischen Brettspiele wie Mensch
ärgere dich nicht oder Schach. Das wichtigste und namensgebende Element eines Brettspieles,
ist das Spielbrett. Mit ihm wird mittels anderer Elemente interagiert, das häufigste Element
ist hierbei die Spielfigur. Es gibt allerdings auch viele andere Elemente, die zu einem Brettspiel
gehören können, gerade bei moderneren Spielen wie Scotland Yard, gibt es als Elemente nicht
nur Spielfiguren sondern auch Chips aus Pappe. Ein weiteres gutes Beispiel hierfür wäre Agathas
letzter Wille. In diesem Spiel gibt es Fallen, die auf dem Spielbrett platziert werden, z.B. in
Form eines Kronleuchters oder eines Bücherregals. Da auf einem Tablet allerdings nicht genügend Platz ist für so viele Elemente, haben wir uns auf Brettspiele spezialisiert, bei denen nur
klassische Spielfiguren, auch Pöppel genannt, benutzt werden. Deshalb wollen wir hier einmal
darauf eingehen, wie man das Brettspiel Mensch ärgere dich nicht, auf dem unser Fokus liegt,
auf die Informatik abbilden kann und was wir benötigen, um das Spiel inklusive der Spielregeln
zu implementieren, aber erst folgt noch ein kleiner Einblick in die Geschichte der Brettspiele und
was wir unter klassischen Brettspielen verstehen.
3.1
Geschichtlicher Hintergrund
Zu den erste Brettspielen, die bekannt sind, gehören das Spiel Königliches Spiel von Ur, welches
von ca. 2600 v. Chr. stammt und das hauptsächlich in Asien, auch noch heute, großen Anklang
findende Spiel Go dessen Ursprung um ca. 400 v. Chr. geschätzt wird. Zu einer ähnlichen Zeit, zu
der erste Ausgrabungen zum Speil Go gefunden wurden (kurz n. Chr.) wird auch der Ursprung
von Schach, ein noch heute hierzu Lande gespieltes Spiel, geschätzt. Zu den neuzeitlichen Spielen
zählen Monopoly, Malefiz und Mensch ärgere dich nicht.
Mensch ärgere dich nicht ist im Verhältnis ein noch sehr junges Spiel, welches 1908 von Josef
Friedrich Schmidt erfunden und 1910 erstmals veröffentlicht wurde. Es ist zurückzuführen auf
11
Bachelorarbeit
Spielfiguren
3.2. KLASSISCHE BRETTSPIELE
das Spiel Pachisi bzw. Chaupar oder Yut. Pachisi hat seinen Ursprung in Indien um 400 n. Chr.
und wird als eines der Ursprünge der europäischen Spielekultur gezählt. Mensch ärgere dich nicht
gilt als eines der populärsten Spiele in Deutschland. Die Spielregen haben sich seit Erscheinung
nicht verändert, allerdings haben sich im Laufe der Zeit mehrere Spielvarianten herausgebildet.
Für mehr Information über diese siehe: [28], [25] und [30]
3.2
Klassische Brettspiele
In diesem Abschnitt wollen wir einmal genau definieren, was wir unter klassischen Brettspielen
definieren, und welche Art von Spielen wir mit unserer App unterstützen wollen. Auf jeden Fall
unterstützen wollen wir Mensch ärgere dich nicht. Die Spiele, die wir unterstützen wollen, sollen
keine Bewegungsregeln enthalten, siehe 3.3, also fallen Spiele wie Schach, Shogi oder Dame raus.
Auch Legespiele wollen und können wir nicht unterstützen, zu ihnen zählen alle Spiele, bei denen
man viele kleine und spezielle Elemente auf das Spielbrett legen muss, wie bei Scrabble. Doch
was verstehen wir jetzt unter klassischen Brettspielen?
Wir verstehen darunter Spiele, die nur aus Übergangsregeln und Situationsregeln bestehen und
möglichst mit Pöppel gespielt werden können, da wir nicht zu viele verschiedene Spielfiguren
benötigen möchten. Dazu würden neben Mensch ärger dich nicht Spiele wie Halma, das Gänse
Spiel, Spuk und einige weitere Spiele zählen.
Haben wir Erstmal eine Auswahl an Spielen fertig, könnten wir uns auch Spiele wie Monopoly,
Dame, Mühle oder Scotland Yard vorstellen. Um Monopoly umzusetzen, müssten wir eine Erkennung von Karten einbauen oder virtuelle Karten benutzen und für die Spielfiguren könnte
man die Pöppel benutzen. Das Geld würde, auf jeden Fall, nur virtuell existieren.
Bei Scotland Yard würde ebenfalls die Kartenerkennung nötig sein. Für Dame und Mühle wären
neue Figuren nötig und für Dame müssten die bereits erwähnten Bewegungsregeln implementiert
werden.
3.3
Regeln
Saskia und Jeffrey
Regeln existieren für jedes Brettspiel, jedoch können diese so extrem unterschiedlich sein, dass
es schwer fällt sie zu verallgemeinern. Auch können Regeln sich auf viele unterschiedliche Spielelemente beziehen, daher teilen wir Regeln für unsere Betrachtung in drei Kategorien ein.
12
Bachelorarbeit
Spielfiguren
KAPITEL 3. KONZEPTION VON BRETTSPIELEN
Übergangsregeln
Diese Regeln legen fest unter welchen Bedingungen von einem Feld auf das nächste Feld
gezogen werden darf, z.B. dass man nur mit einer Sechs eine Figur rausziehen kann.
Bewegungsregeln
Beschreiben nach welchem Muster sich eine Figur bewegt, z.B der Läufer beim Schach, der
sich nur diagonal bewegen darf.
Situationsregeln
Regeln, die die Spielsituation beeinflussen, z.B. bei einer Sechs darf noch einmal gewürfelt
werden oder Ereigniskarten in Monopoly.
Wir konzentrieren uns bei der Realisierung zunächst nur auf Spiele mit Übergangsregeln und
Situationsregeln, daher würde beispielsweise Schach wegfallen.
Da jedes Spiel seine eigenen Regeln hat, ist es nicht möglich eine allgemein gültige Methode
zu programmieren. Daher muss ein Grundgerüst für eine Regel geschaffen werden und jedes
Spiel muss anhand dessen alle Regeln implementieren. Bei Mensch ärgere dich nicht wären es
beispielsweise folgende:
• Sind alle Figuren einer Person auf den Anfangsfeldern, darf bis zu dreimal hintereinander
gewürfelt werden.
• Mit einer Sechs kann eine Figur von den Anfangsfeldern ins Spiel gebracht werden.
• Nach dem Rausstellen einer Figur von den Anfangsfeldern muss das Startfeld im Spielfeld
schnellstmöglich wieder frei gemacht werden.
• Beim Wurf einer Sechs muss, soweit vorhanden, eine Figur von den Anfangsfeldern gezogen
werden.
• Wurde eine Sechs gewürfelt, darf nochmal gewürfelt werden.
• Kann eine Figur geschlagen werden, muss dieses auch geschehen, oder die anderen Mitspieler
dürfen eine Figur des Spielers, der nicht geschlagen hat, aufs Anfangsfeld zurückstellen.
• Figuren in den Zielfeldern dürfen nicht übersprungen werden.
• Die Figuren müssen mit passgenauer Augenzahl auf die Zielfelder gesetzt werden.
Es gibt bei diesem Spiel noch viele weitere Regeln und Varianten, wir beschränken uns hier auf
die angegebenen Regeln.
3.4
Spielablauf
Saskia Müller
Der Spielablauf ist bei vielen Spielen gleich oder ähnlich und kann bei fast allen Spielen verallgemeinert werden. Dazu gehört, dass die Spieler abwechselnd an der Reihe sind und nach
dem letzten Spieler wieder der Erste an der Reihe ist. Außerdem wird bei vielen Spielen ein
sechs-seitiger Würfel benutzt, der nur einmal implementiert werden muss. Gespielt wird immer
13
Bachelorarbeit
Spielfiguren
3.4. SPIELABLAUF
auf einem Brett, dieses besitzt meistens Felder, auf denen Figuren stehen und Linien, die als
Verbindungen zwischen Feldern dienen.
Die Verbindungen sind für jedes Spiel anders, aber die grundlegende Strukturen, die dahinter
stehen, sind die Gleichen. Es handelt sich dabei um (gerichtete) Graphen mit teilweise speziellen
Übergangsregeln. Bei Mensch ärgere dich nicht wären die speziellen Übergangsregeln, dass man
auf die Zielfelder nur gehen kann und auch muss, wenn es sich um seine eigenen Zielfelder handelt. Die zweite spezielle Übergangsregel bei dem Spiel wäre, dass man von den Anfangsfeldern
nur mit einer Sechs kommen kann.
3.4.1
Gerichteter Graph
In ?? zeigen wir den Gerichteten Graphen eines Spielfeldes, anhand unseres Beispiels Mensch
ärgere dich nicht. Doch als erstes wollen wir kurz darauf eingehen, was ein Gerichteter Graph
ist und aus welchen Bestandteilen er besteht.
Ein gerichteter Graph dient dazu eine Menge von Objekten zusammen mit ihren Verbindungen darzustellen und die Richtung in welche diese Verbindung besteht. Häufig werden sie für
Netzpläne benutzt, wie z.B. bei Straßenbahnplänen oder Wegepläne. Siehe [26] und [7]. Da ein
Spielbrett einem Wegeplan sehr ähnelt, eignet sich auch für ein Spielbrett ein gerichteter Graph
sehr gut.
Er besteht aus einer Menge von Knoten V, diese sind die einzelnen Felder auf denen die Figuren
stehen können, es sind insgesamt 72. Der zweite Bestandteil von gerichteten Graphen sind die
geordneten Knotenpaare bzw. die gerichteten Kanten E, die die Richtung vorgeben in welcher
man von einem Knoten zum Nächsten kommt. Der Graph G ist also ein Tupel (V, E), die Menge
aller Knoten und Kanten. Unter Einbeziehung der Übergangsregeln könnte man G als ein Tripel
(V, E, T) darstellen. Hierbei steht T für die Menge aller Übergangsregel (Transition rules).
Der Eingangsgrad eines Knotens v ∈ V ist die eingehenden Kante und der Ausgangsgrad ist
die ausgehenden Kante von einem Knoten zu anderen Knoten. Bei Mensch ärgere dich nicht ist
der Eingangs und Ausgangsgrad in den meisten Fällen eins. Es gibt auch einige Ausnahmen,
bei denen sich der Eingangsgrad und Ausgangsgrad unterschieden. Die vier Anfangsfelder jeder
Farbe, also 16 Knoten, haben einen Eingangsgrad von null oder aber, wenn man die Regeln
beachtet, kann man von jedem nicht-Anfangsfeld und nicht-Zielfeld zurück auf die Anfangsfelder
geworfen werden, also wäre der Eingangsgrad immer 40. Die Felder direkt vor den Zielfeldern,
also vier Knoten, haben einen Ausgangsgrad von zwei, welches dieser Felder für die einzelnen
Figuren als Übergang in Frage kommt, hängt von der Farbe der Figuren ab. Als letztes haben
wir noch die vier Startfelder, diese haben jeweils einen Eingangsgrad von fünf.
14
Bachelorarbeit
Spielfiguren
Unseren gerichteten Graphen werden wir so ähnlich wie möglich optisch an das Spielfeld anpassen,
damit er leichter zu lesen ist.
Abbildung 3.1
Mensch ärgere dich nicht Graph
Wie zu sehen ist, ist Mensch ärgere dich nicht dargestellt als ein gerichteter Graph mit Mehrfachkanten, da von manchen Knoten mehr als eine Kante abgeht.
3.5
Spielfiguren
Bei vielen Brettspielen werden die klassischen Spielfiguren benutzt. Diese sind fürs Spielen auf
dem Tablet besonders geeignet, da sie eine gerade, nicht zu große und nicht zu kleine Standfläche
haben. Monopoly Figuren sind hingegen eher schlecht geeignet, da sie zum Teil sehr unterschied-
15
Bachelorarbeit
Spielfiguren
3.6. SPIELZUG
liche und unebene Standflächen mit teilweise mehreren Touchpunkten haben. Ebenfalls gut zu
benutzen wären Mühle- bzw. Dame-Figuren.
3.6
Spielzug
Ein Spielzug besteht bei fast allen Spielen aus drei Schritten. Der erste Schritt ist das Würfeln,
danach kommt das Setzen der Spielfigur und als letztes kommt eventuell noch eine Aktion. Bei
Monopoly wäre eine Aktion z.B. eine Karte ziehen oder eine Straße oder Häuser kaufen. Bei
Mensch ärgere dich nicht gibt es nur eine mögliche Aktion, die darin besteht eine andere Figur
zu schlagen. Bei Mensch ärgere dich nicht gibt es vier Möglichkeiten wie ein Spielzug ablaufen
kann:
Alle Spielfiguren auf Anfangsfeldern
Spieler würfelt und setzt bei einer Sechs seine Figur auf das Startfeld und prüft ob eine
Figur rausgeworfen wurde.
Bei jeder anderen Zahl ist der gleiche Spieler nochmal an der Reihe, wenn er nicht schon
drei mal an der Reihe war.
Mindestens eine Figur im Spiel
Spieler würfelt und setzt eine Figur auf ein besetztes Feld und wirft die sich auf diesem Feld
befindende Figur raus.
Spieler würfelt und setzt eine Figur auf das neue Feld, welches frei ist.
Wie der Spielzug abläuft kann am Graphen noch genauer gezeigt werden. Jede Spielfigur steht
auf einem Feld, befindet sich also zu jedem Zeitpunkt auf genau einem Knoten. Ist ein Spieler an
der Reihe würfelt er. Pro angezeigtem Auge auf dem Würfel kann die Figur eine Kante weiter
gehen. Wurde beispielsweise eine Zwei gewürfelt kann die gewünschte Figur, von ihrem aktuellen Knoten aus, erst eine Kante weiterziehen und anschließend vom neuen Knoten eine weitere
Kante weiterziehen, dann ist der Würfelwurf verbraucht. Bei Mensch ärgere dich nicht existiert
für jede Figur immer nur ein Weg von einem Knoten zu einem anderen. Dies ergibt sich daraus,
dass die Kanten gerichtet sind, der Eingangsgrad immer nur eins ist und es teilweise bestimmte
Übergangsregeln gibt. Die Startfelder mit einem Eingangsgrad von fünf stellen einen Sonderfall
dar, was nichts daran ändert, dass es nur einen Weg gibt. Um es anders zu formulieren, der
Abstand von einem Knoten zum nächsten ist immer eins und pro Auge des Würfelergebnisses
kann man einen Schritt gehen.
Bei Mensch ärgere dich nicht gibt es immer nur einen möglichen Weg, bei vielen anderen Spielen
gibt es aber mehrere, also gibt es auch mehrere Möglichkeiten, wie ein Spielzug ablaufen kann.
16
Bachelorarbeit
Spielfiguren
Damit ein Spielerwechsel erkannt werden kann ist es wichtig zu wissen, wann ein gültiger Spielzug
zu Ende ist. Dieses wollen wir im Folgenden genauer betrachten.
3.6.1
Spielzug Ende erkennen
Das Wichtigste für die Funktionalität unserer App, ist dass das Ende eines Spielzuges erkannt
wird und der nächste Spieler als aktueller Spieler gekennzeichnet wird. Um dieses zu gewährleisten, müssen verschiedene Spielregeln implementiert werden. Für Mensch ärgere dich nicht
müssen wir dazu folgende Regeln implementieren:
Alle Figuren auf Anfangsfeldern
In diesem Fall ist gleich mehreres zu beachten. Sollte keine Sechs gewürfelt worden sein, ist
der nächste Spieler an der Reihe, der eventuell der selbe Spieler ist. Außerdem muss beim
Würfeln einer Sechs beachtet werden, dass die Figur nur eine Kante laufen darf und nicht
wie üblich sechs.
Würfeln einer Sechs
Wurde eine Sechs gewürfelt ist der selbe Spieler noch einmal an der Reihe.
Kein Überspringen von Figuren auf Zielfeldern
Dieses ist wichtig, um herauszufinden ob es überhaupt mögliche Züge gibt. Sollte es keine
geben ist automatisch der nächste Spieler an der Reihe.
Endfeld der zu setzenden Figur erkennen
Da nicht jeder seine Figur beim Setzen anhebt und auf dem Endfeld erst wieder absetzt,
muss das Endfeld erkannt werden. Ein Beispiel wäre, dass jemand seine Figur zieht, indem
er jedes Feld abzählt und die Figur auf jedem Feld einmal absetzt. Kennt man in diesem Fall
das Zielfeld nicht, kann es schnell zu einer Fehlerkennung des Endes des Spielzuges kommen.
Um das Ende zu erkennen benötigen wir in unserer Implementierung den Graphen.
Es sind also insgesamt fünf Regeln, die beachtet werden müssen, um den korrekten Spielablauf
bei Mensch ärgere dich nicht zu gewährleisten.
• Sind alle Figuren auf den Anfangsfeldern kann bis zu drei mal gewürfelt werden
• Bei einer Sechs darf nochmal gewürfelt werden.
• Figuren können nur mit einer Sechs von den Anfangsfeldern auf das Startfeld im Spiel gesetzt
werden
• In den Zielfeldern können keine Figuren übersprungen werden
• Eine Figur muss pro Würfelauge genau ein Feld gesetzt werden
Sollte auch nur eine der Regeln nicht implementiert werden, kann es dazu kommen, dass das
Spiel stehen bleibt, oder ein Spieler an der Reihe ist, der eigentlich nicht an der Reihe sein sollte.
Andere Regeln, wie z.B. ob eine Figur bei einer Sechs von einem Anfangsfeld ins Spiel gezogen
wird, oder aber eine andere Figur gezogen wird, müssen, und wollen wir nicht beachten, da die
17
Bachelorarbeit
Spielfiguren
3.6. SPIELZUG
Spieler selbst für die Einhaltung der Regeln zuständig sein sollen.
Da es in vielen Spielen, wie schon erwähnt mehr als nur einen möglichen Weg gibt, müssen alle
erkannt werden, damit das Ende eines Spielzuges korrekt erkannt werden kann. Dieses Wege
können durch Tiefensuche, die Tiefe entspricht der Augenzahl, beim Erstellen der Wege aus dem
Graphen gefunden werden.
18
Kapitel 4
Technische Grundlagen
4.1
Android
Jeffrey Wolfe
Mit Android wird sowohl ein Betriebssystem als auch eine Software-Plattform für Smartphones
und Tablets bezeichnet. Man findet Android aber auch immer häufiger auf anderen Geräten wie
Netbooks oder sogennanten Multimedia Sticks, die direkt an den HDMI Eingang eines Fernsehers
angeschlossen werden und so jedem TV die Funktionalität eines Smart-TVs bescheren.[21]
Entwickelt wird Android von der Open Handset Alliance, deren Gründer und Hauptmitglied
Google ist. Sie ist ein Konsortium aus 84 (Stand 2012) Firmen aus den Bereichen Hardware,
Software und Telekommunikation. Zu den Mitgliedern gehören unter anderem Branchengrößen
wie Google, T-mobile, Samsung oder Qualcomm.[2]
Android wird als Open-source Software unter der Apache Lizenz entwickelt. Es ist einem also
freigestellt, wie man Android bzw. den Quelltext nutzt, egal ob privat oder kommerziell.[21]
Der Kernel des Betriebssystem basiert auf Linux, ist jedoch erweitert um Treiber für typische
Hardware von Smartphones und Tablets, sowie zusätzlichen Funktionalitäten und Anpassungen,
die das Verhalten auf diesen Plattformen optimieren sollen. Seit März 2012 wurden große Teile
des Android Quelltextes in den Linux Kernel integriert und es wird angestrebt, dass sich Android
und Linux in der Zukunft eine Codebasis teilen.[21]
Neben dem Kernel finden sich in Android auch viele Systemprogramme und Konfigurationsdateien, die man auch in Linux Distributionen findet, wie beispielsweise die wpa_supplicant.conf in
der die Konfiguration von geschützten W-lan Zugangspunkten geschieht. Nähere Informationen
zu Android in [21]
Ein wichtiger Teil der Android Laufzeitumgebung ist die Dalvik Virtuelle Maschine.
19
Bachelorarbeit
Spielfiguren
4.1. ANDROID
4.1.1
Dalvik
Auf Computern findet sich, sofern Java Anwendungen unterstützt werden sollen, die virtuelle
Maschine von Oracle, ehemals entwickelt von Sun. In Android dagegen wird stattdessen Dalvik
genutzt.
Dalvik unterscheidet sich in vielen Punkten von der Oracle JVM. Da Dalvik auf deutlich leistungsschwächeren Geräten laufen soll, stellt es eine reduzierte VM mit geringerem Speicherbedarf
dar. Im Gegensatz zu Standart Java VMs, die als Kellerautomat konzipiert sind, arbeitet Dalvik
als eine virtuelle Registermaschine. Instruktionen arbeiten direkt auf Variablen, die in virtuellen
Registern gespeichert sind. Dadurch werden Ladezeiten verkürzt, weil das Laden und Speichern
vom Stack entfällt. Es wird weiterhin eine eigene stark optimierte Version von Byte-Code, der
durch den Präprozessor dx erzeugt und in dex statt class Dateien vorliegt, genutzt. Der Programmierer bekommt hiervon jedoch nichts mit, man programmiert in normaler Java-Syntax und ein
Großteil der Java Standart Klassen wurde entweder für Dalvik implementiert oder es existieren
eigene Versionen dieser.[21][17][22]
4.1.2
Android Programmierung
Android Anwendung, üblicherweise als Apps bezeichnet, werden meist in Java mit Hilfe des
Android SDK oder aber in C bzw. C++ mit dem NDK entwickelt. Wobei das NDK vornehmlich
dafür gedacht ist entweder schnell Programme für Android zu portieren, die in diesen Sprachen
implementiert wurden oder wenn sich dadurch bessere Performanz erzielen lässt. Es existieren
zudem noch Projekte, die die Entwicklung in vielen unterschiedlichen Sprachen wie Ruby1 ,
Python2 oder c#3 ermöglichen. Diese sind jedoch nicht offiziell unterstützt und befinden sich in
einem frühen Stadium.
Wenn man eine App schreiben möchte, muss man sich zunächst entscheiden welche API Version
man nutzen möchte. Damit wird bestimmt welche Version von Android auf dem Gerät mindestens
vorhanden sein muss, damit die App funktionieren kann. Android befindet sich in einem stetigem
Wandel, es kommen regelmäßig neue Funktionen hinzuzu oder alte werden entfernt. Festgelegt
wird dies in der Haupt-Konfigurationsdatei jeder Android App, der Androidmanifest.xml.
1 http://ruboto.org/.
2 http://code.google.com/p/android-scripting/.
3 http://xamarin.com/monoforandroid.
20
Bachelorarbeit
4.1.2.1
Spielfiguren
KAPITEL 4. TECHNISCHE GRUNDLAGEN
Androidmanifest.xml
In dieser Datei werden wichtige Einstellungen, die eine App betreffen, gemacht. Es ist eine XML
Datei, die sich im Wurzelverzeichnis jedes Android Projektes befinden muss, der Aufbau sieht
wie folgt aus, wobei nicht jedes Element enthalten sein muss.
1
<?xml version="1.0" encoding="utf−8"?>
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<manifest>
<uses−permission />
<permission />
<permission−tree />
<permission−group />
<instrumentation />
<uses−sdk />
<uses−configuration />
<uses−feature />
<supports−screens />
<compatible−screens />
<supports−gl−texture />
16
17
<application>
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<activity>
<intent−filter>
<action />
<category />
<data />
</intent−filter>
<meta−data />
</activity>
<activity−alias>
<intent−filter> . . . </intent−filter>
<meta−data />
</activity−alias>
32
33
34
35
36
<service>
<meta−data/>
</service>
37
38
39
40
41
<receiver>
<meta−data />
</receiver>
42
43
44
45
46
47
48
<provider>
<grant−uri−permission />
<meta−data />
</provider>
<uses−library />
49
50
</application>
21
Bachelorarbeit
Spielfiguren
4.1. ANDROID
51
52
</manifest>
Listing 4.1
Manifest
Die einzigen Elemente, die erforderlich sind für eine gültige Manifest-Datei sind <manifest> und
<application>. Allerdings ist es wenig sinnvoll nur diese zu definieren, daher gehen wir kurz auf
die Elemente ein, die für unsere Implementierung relevant waren.
<application>
Allgemeine Einstellung der App, wie z.B. android:name="string" zum Festlegen des App
Namens.
<uses-sdk>
Festlegung der minimal erforderlichen Version von Android, um die App ausführen zu können.
<uses-permission>
Benötigte Rechte, z.B Internetzugriff, diese werden vor dem Installieren der App angezeigt
und müssen vom Nutzer bestätigt werden.
<uses-feature>
Genutzte Features wie z.B. OpenGL ES 2.0, man kann bestimmen ob diese erforderlich oder
optional sind. Bei erforderlichen Features wird die App im Android Play Store nur Geräten
angeboten, die diese unterstützen.
<activity>
Definiert die Activities, aus denen sich die App zusammensetzt.
[13]]
4.1.2.2 Activity
Jede Android App besteht aus mindestens einer, meist aber mehreren Activities. Eine Activity
setzt sich aus einer Java Klasse, die von der Klasse Activity erbt und einer XML Datei, dem
Layout, das die grafische Oberfläche beschreibt, zusammen. Das Layout ist sehr simpel aufgebaut.
Es gibt zwei Hauptkomponenten in einer Android Gui. Diese sind entweder Views wie z.B.
Buttons, Textfelder, usw. oder Container, in denen sich Views befinden und die beschreiben, wie
diese angeordnet sind.
1
2
3
4
5
6
7
8
9
<ContainerTyp
android:id="ContainerID"
..weitere Einstellungen..
.
.>
<ViewTyp
android:id="ViewID"
..weitere Einstellungen..
.
22
Bachelorarbeit
10
11
Spielfiguren
./>
</ContainerTyp>
Alle Texte wie etwa Button Beschriftungen sollten optimaler Weise nicht direkt ins Layout
geschrieben werden, sondern in die strings.xml Resource Datei ausgelagert werden und mit
@string/stringname eingebunden werden, dadurch wird automatisch ein lokalisierter Text verwendet, sofern vorhanden.
In der Java Klasse wird die Funktionalität einer Activity implementiert, was passiert wenn ich
auf einen Button drücke, Informationen die mir angezeigt werden sollen und viele andere Dinge.
Auch legt man in der Klasse fest, welche Aufgaben erfüllt werden sollen, wenn die Activity in
einen ihrer drei möglichen Zustände, Resumed, Paused oder Stopped wechselt.
4.1.2.3
Intents
Wie schon angedeutet, bestehen nur wenige Apps nur aus einer einzigen Activity, daher muss
es eine Möglichkeit geben zwischen verschiedenen Activites zu wechseln. Intents bieten uns diese
Funktion, es sind Objekte die eine gewünschte Aktion abstrakt beschreiben. Man initialisiert ein
Intent mit dem eindeutigen Bezeichner der Activity, die man starten will. Als zweite Möglichkeit, können noch extra Informationen übergeben werden. Man ist dabei nicht nur auf Activities
aus der eigenen App beschränkt, sondern kann auch Activities anderer Apps ausführen die eine benötigte Funktion bereitstellen. In diesem Fall ist es jedoch nicht notwendig explizit eine
bestimmte Activity einer bestimmten App aufzurufen. Stattdessen reicht es anzugeben welche
Aufgabe erledigt werden soll, etwa ein Foto aufnehmen und Android startet die Activity, die
diese Aufgabe im System übernimmt.[13]]
4.2
XML
Die Extensible Markup Language ist eine Sprache zur Darstellung von Daten in einer hierarchischen Struktur und wird oft dafür benutzt, Daten zwischen verschiedenen Computersystemen zu
übertragen. Durch die Verwendung von Namespaces kann man in einem XML-Dokument mehrere Sprachen mischen, ein Beispiel hierfür wäre:
Das Element <p> steht für Person, wenn der Namespace beispielsweise xmlns=“verwaltung:personen”
ist. Ist der Namespace hingegen ein Anderer, könnte das Element <p> für etwas ganz anderes
stehen, bei XHTML steht es für einen Absatz. Um hier sicher zu gehen, dass das Element <p>
richtig gedeutet wird, muss ein Namespace angegeben werden. So kann in einem XML-Dokument
das <p> auch für beides stehen, wenn beide Namespaces angegeben wurden, allerdings nacheinander. Der Namespace kann überall im Dokument angegeben werden, wird aber typischerweise
23
Bachelorarbeit
Spielfiguren
4.2. XML
einmal am Anfang angegeben und einmal oder mehrmals, wenn sich der Namespace ändert.
Das Wichtigste beim Aufbau eines XML-Dokuments ist das Element. Der Name eines Elementes kann frei gewählt werden und kann weitere Elemente oder Texte enthalten. Jedes XMLDokument sollte ein Wurzelelement besitzen und jedes Element einen sogenannten End-Tag, der
anzeigt, dass das Element beendet wurde. Da XML weitgehend bekannt ist, wollen wir hier nicht
weiter darauf eingehen und nur ein Beispieldokument, das in unserer App erstellt wird, zeigen.
1
2
3
4
5
6
7
8
9
10
11
<invite xmlns="game:invite">
<color class="java.util.ArrayList">
<integer>0</integer>
<integer>1</integer>
</color>
<player class="java.util.ArrayList">
<string>hugo</string>
<string>franz</string>
</player>
<playerCount>2</playerCount>
</invite>
Für weiter Informationen zu XML siehe [23].
4.2.1
Simple
Simple [16] ist ein Java Framework zum Serialisieren und Deserialisieren von Java Objekten in
eine XML-Form. Es ist, wie der Name sagt, sehr einfach zu benutzen und kann problemlos auch
komplexere Objekte serialisieren und beim Deserialisieren werden sogar Referenzen wieder hergestellt. Das XML, welches dabei entsteht, ist auch für Menschen sehr leserlich und kann somit bei
Bedarf auch von Hand zurückgeparst werden. Um Simple zu benutzen, müssen in der Javaklasse,
die serialisiert werden soll, einige Ergänzungen gemacht werden. Man kann das Wurzelelement
setzen, was im Allgemeinen der Klassenname sein wird, indem man vor Beginn der Klasse @Root
schreibt. Einen Namespace kann man z.B. mit @Namespace(reference=”game:invite”) einfügen.
Da man die Variablen seiner Klasse auch serialisieren möchte, kann man dafür z.B. @Element
benutzen. Um dieses einmal zu verdeutlichen, zeigen wir hier ein einfaches Beispiel einer Javaklasse, die mit Simple serialisiert werden kann und die XML-Datei refinvite die aus der Klasse
entsteht.
1
2
3
4
5
6
7
8
9
@Root
@Namespace(reference="game:invite")
public class Invite implements PacketExtension {
@Element
public int playerCount;
@ElementList
public List<String> player;
@ElementList
public List<Integer> color;
24
Bachelorarbeit
Spielfiguren
10
11
public String from;
12
13
public Invite(){
14
15
}
4.3
XMPP
XMPP [9] steht für Extensible Messaging and Presence Protocol und ist ein Internetstandart,
der hauptsächlich für Instant Messaging verwendet wird. XMPP benutzt den XML Standard
und war früher unter dem Namen Jabber bekannt.
Jeremie Miller veröffentlichte 1999 Jabber, ein Echtzeit-XML-Streaming-Protokoll. 2004 wurde
dieses Protokoll mit einigen Änderungen unter dem Namen XMPP zum Standard. Es ist ein offen
dokumentiertes Protokoll und wird stetig weiter entwickelt. Auch gibt es mehrere Erweiterungen
für XMPP, wie beispielsweise Jingle. Für den Betrieb eines XMPP Netzwerks wird mindestens
ein Server benötigt, in dem die Benutzer durch sogenannte JabberIDs identifiziert werden können. Diese sind wie E-mail-Adressen aufgebaut. Sie bestehen aus einem Benutzernamen gefolgt
von einem Servernamen, die durch das @ Zeichen getrennt werden. Außer der JabberID wird
zum Anmelden an den Server ein Passwort und eine Ressource benötigt. Durch unterschiedliche
Ressourcen kann man sich auch mehr als einmal am Server anmelden. Server gibt es weltweit
tausende, von Privatpersonen, Organisationen sowie großen Firmen wie Google über ihre E-mailAdresse Gmail oder die Software Google Talk. Nachrichten zwischen zwei Personen werden von
der ersten Person zum Server geschickt, vom Server des Senders zum Server des Empfängers und
anschließend vom Server des Empfängers zum Empfänger der Nachricht. Da hierbei mehrere
Stationen sind, an denen die Nachrichten abgehört oder verfälscht werden können, sollten diese
verschlüsselt werden. Dies kann durch SSL/TSL geschehen.
Code Libraries gibt es für viele verschiedene Programmiersprachen z.B. Smack für Java und ein
abgewandeltes Smack für Android mit dem Namen Asmack, von der wir eine Version benutzen,
in der Jingle siehe 4.3.1 integriert ist.
4.3.1
Jingle
Jingle ist eine Erweiterung für XMPP. Es erweitert XMPP um mehrere Funktionen. Eine Funktion ist Peer-to-Peer, eine Verbindung die Rechner gleichgestellt miteinander verbindet. Andere
Funktionen sind Multimedia Funktionen wie Voice over IP oder Videokonferenzen.
25
Bachelorarbeit
Spielfiguren
4.4. OPENGL
4.4
OpenGL
Jeffrey Wolfe
Für die Darstellung des eigentlichen Spielablaufes verwenden wir OpenGL, daher wollen wir in
diesem Abschnitt näher darauf eingehen,was OpenGL ist und wozu es dient.
OpenGL , was für Open Graphics Library steht ist, wie der Name bereits sagt, eine offene
Grafikbibliothek, die von der Khronos Group verwaltet wird.[29]
4.4.1
Khronos Group
Die Khronos Gruppe wurde 2000 von führenden Unternehmen des Bereichs Medien gegründet.
Ihr Ziel ist es, eine offene Standard API zur Erstellung und Wiedergabe von Medien auf einer
Vielzahl von Plattformen und Geräten zu erschaffen. Die Khronos Group ist nicht gewinnorientiert und wird von ihren Mitgliedern finanziert, die im Gegenzug dafür über die API Spezifikationen mitentscheiden dürfen und sich an deren Entwicklung beteiligen können. Weiterhin
erhalten sie als erstes Zugriff auf kommende Spezifikationen und Konformitätstests. Zu den über
100 Mitgliedern der Khronos Group zählen unteranderem AMD, Intel, Nvidia, Google und Adobe. Aus ihren Bemühungen sind unter anderem OpenGL und dessen verschiedene Varianten und
Versionen hervorgegangen. Wir gehen nun kurz auf ein paar dieser ein.[10]
4.4.2
OpenGL
Die ersten Iterationen dieser weit verbreiteten Grafikbibliothek legen die Grundlagen für die
Funktionsweise von OpenGL. Konzipiert wurde OpenGL als ein Zustandsautomat, das heißt:
Man übergibt nicht bei jeder Funktion alle Parameter, sondern setzt diese bei Bedarf, ansonsten
werden die aktuell aktiven Parameter verwendet. Beispielsweise möchte man viele verschiedene
Objekte in einer Farbe zeichnen, also setzt man einmalig den Parameter für die Farbe und
führt dann die Zeichenoperationen aus. So erhalten dann alle Objekte diese Farbe. Ziemlich alle
Funktionen von OpenGL verarbeiten entweder Primitive wie Punkte, Linien oder Polygone zu
Pixeln oder konfigurieren, wie die Primitive verarbeitet werden. OpenGL ist als eine Low-Level
API konzipiert, das heißt, der Programmierer bestimmt jeden einzelnen Schritt der notwendig
ist, um die Szene darzustellen, was einerseits sehr viel Detailwissen, aber im Gegenzug große
Freiheiten ermöglicht.
Die Hauptaufgaben, die OpenGL seit dieser Version bereits erledigt sind:
Rasterung
Das Umwandeln von Vektor-Grafiken zu den aus Pixeln bestehenden Rastergrafiken
26
Bachelorarbeit
Spielfiguren
Transform
Das Bewegen, Rotieren und Skalieren eines 3D Objektes im Raum und die Projekte dessen
auf unseren zweidimensionalen Bildschirm, hierzu später noch mehr
Lightning
Berechnung der Helligheit und Farbe eines Bildpunktes in Abhängigkeit zu einem vom Programmierer vorgegeben Beleuchtungsmodell
Z-Buffering
Berechnung der Sichtbarkeit von Pixeln mittels Tiefeninformationen
Texture mapping
Abbilden einer Textur oder Teile derer auf ein Objekt
Alpha blending
Verarbeitung von Transparenzen
Mit der Version 2.0 wurde die OpenGL Shading Language GLSL eingeführt und damit auch die
fixed-function vertex und fragment pipelines ersetzt, darauf gehen wir später näher ein.[29]
4.4.3
WebGL
WebGL stellt eine Variante von OpenGL ES dar, die es ermöglicht OpenGL direkt im Webbrowser
zu nutzen und somit aufwendige hardwarebeschleunigte 3D-Anwendungen direkt fürs Web in
Javascript zu implementieren wie z.b. das Computerspiel Quake 3.[29]
4.4.4
OpenGL ES
OpenGL for Embedded Systems oder kurz OpenGL ES stellt eine vereinfachte Version von
OpenGL dar, die um redundante Funktionen reduziert wurde, ebenfalls werden weniger Datentypen unterstützt, außerdem fehlen meist die Support Libraries GLUT und GLU. OpenGL ES
findet Einsatz in Smartphones, Tablets, mobilen Videospielkonsolen oder anderen Geräten mit
geringerer Leistung und Speicher wie z.B. dem Raspberry Pi. Bisher existieren zwei Hauptversionen (OpenGL ES 3.0 wurde im August 2012 veröffentlicht), die in Verwendung sind. 1.0 bzw. 1.1
die auf der OpenGL Spezifikation 1.3 bzw. 1.5 basiert und OpenGL ES 2.0 was auf der OpenGL
2.0 Spezifikation aufbaut, aber eine programmierbare Rendering-Pipeline wie in OpenGL 3.1
nutzt, statt festen Funktionen werden Shader genutzt, die in GLSL geschrieben sind. Da wir
in unser Implementierung OpenGL ES 2.0 verwenden, gehen wir auch auf Shader und GLSL
ein.[29]
27
Bachelorarbeit
Spielfiguren
4.4. OPENGL
4.4.5
Shader
Shader sind Computerprogramme, die direkt auf der GPU ausgeführt werden. Sie sind verantwortlich für den größten Teil der Grafik-Pipeline, also wie ein Objekt im Endeffekt dargestellt
wird, mit seiner Position, Ausrichtung, Beleuchtung, Textur, etc. . In OpenGL ES 2.0 stehen zwei
verschiedene Typen von Shadern zur Verfügung, die Vertex Shader, die für alle Transformationen
eines Objektes verantwortlich sind und Pixel oder auch Fragment Shader, die zum Berechnen der
Pixelfarben und Transparenz notwendig sind. Diese beiden Shader werden zu einem Programm
kompiliert, wobei der Vertex Shader Daten an den Fragment Shader übergibt.[31]
Geschrieben werden Shader in der bereits erwähnten OpenGL Shading Language GLSL, die an C
angelehnt ist und dem Programmierer Kontrolle über die Rendering Pipeline auf der Vertex und
Fragment Ebene gibt. Vor der Einführung von GLSL mussten Shader in Assembler geschrieben
werden, was deutlich komplexer und weniger intuitiv ist, als die Syntax einer Hochsprache. Hier
nun zwei Beispiel-Shader, die wir auch in unserem Code verwenden.
Die OpenGL API übergibt die Model-View-Projection Matrix, auf die wir im Anschluss noch
eingehen werden , Vertexkoordinaten, Farben und Texturkoordinaten an den Vertex Shader, die
Farb- und Texturinformationen werden von diesem an den Fragmentshader weitergereicht.
Die Vertexkoordinaten werden im Vertex Shader mit der Model-View-Projection Matrix multipliziert, um die Vertexposition für die Darstellung zu berechnen.[31]
28
Bachelorarbeit
Spielfiguren
uniform mat4 u_MVPMatrix;
1
2
attribute vec4 a_Position;
attribute vec4 a_Color;
attribute vec2 a_TexCoordinate;
3
4
5
6
varying vec4 v_Color;
varying vec2 v_TexCoordinate;
7
8
9
void main(){
v_Color = a_Color;
v_TexCoordinate = a_TexCoordinate;
gl_Position = u_MVPMatrix * a_Position;
};
10
11
12
13
14
Listing 4.2
Vertex Shader
Im Fragment Shader werden aus der Textur und den Farbinformationen die endgültigen Pixelfarben berechnet.
precision mediump float;
1
2
uniform sampler2D u_Texture;
varying vec4 v_Color;
3
4
5
varying vec2 v_TexCoordinate;
void main(){
gl_FragColor = (v_Color * texture2D(u_Texture, v_TexCoordinate));
};
6
7
8
9
Listing 4.3
Fragment Shader
Jeder Datentyp hat in GLSL sowohl eine Typendeklaration, die beschreibt, um was für einen
Datentyp es sich handelt, hier z.B. mat4 für eine 4 stellige Matrix oder vec2 für einen 2 stelligen Vektor, als auch einen Typenqualifzierer, wie beispielsweise Attribute für Inputwerte, wie
Vertex-Position oder Varying für Daten, die vom Vertexshader zum Fragmentshader durchgereicht werden. Um die Daten aus dem Android Code in den Shader zu übergeben, damit dieser
sie verarbeiten und somit zeichnen kann, nutzt man Funktionen der GLES20 API, beispielsweise
GLES20.glGetAttribLocation(programHandle, "a_Position") um ein Handle4 für die Postitionsdaten zu erhalten. Um nun die Daten zu übergeben, gibt man OpenGL einen Pointer auf
diese mittels
GLES20.glVertexAttribPointer(positionHandle, 3, GLES20.GL_FLOAT, false, 0,
field.vertexBuffer), wobei es sehr wichtig ist, bei diesem Aufruf den richtigen Datentyp zu
nennen.
4 int
Wert der Variablen im OpenGL Kontext repräsentiert
29
Bachelorarbeit
Spielfiguren
4.4. OPENGL
4.4.6
OpenGL Räume
Bis zur endgültigen Darstellung eines Objektes auf dem Bildschirm werden dessen geometrischen Daten in mehreren Abschnitten von der Grafik Pipeline verarbeitet, dabei werden sie in
verschiedene Räume oder auch Spaces übertragen.
Object Space
Im Object Space wird das Objekt beschrieben, das heißt, es werden alle Vertices aufgezählt,
die dieses Objekt ausmachen.
Model Space
Nachdem wir nun eine Beschreibung eines Objektes haben, überführen wir dieses in den Model oder auch World Space, also beschreiben wie es in Relation zu anderen Objekten steht.
Dazu wird eine Modelmatrix als Identitätsmatrix initialisiert und auf diese alle Transformationen angewandt, die für das Objekt relevant sind z.B. wollen wir das Objekt fünf Einheiten
nach rechts bewegen und dann 90 Grad um die X-Achse drehen. Die resultierende Matrix
wird dann mit Vertex-Koordinaten des Objektes multipliziert um dessen Repräsentation im
World Space zu erhalten.
View Space
Um zu bestimmen, was wir in unserer Szene überhaupt sehen, definieren wir mittels der
Viewmatrix eine virtuelle Kamera. Es wird festgelegt wo im Raum sie sich befindet und wohin sie ausgerichtet ist. Der View Space beschreibt wo sich alle Objekte befinden, wenn wir
die Szene durch die Kamera betrachten, also in welcher Relationen zur Kamera sie sich befinden. Wir erhalten eine Matrix, die den View Space beschreibt, wenn wir die Modelmatrix
mit der Viewmatrix multiplizieren.
Projection Space
Wir wissen nun wie die Welt aussieht, die wir durch unsere virtuelle Kamera sehen würden.
Diese Darstellung ist aber dreidimensional und wir wollen sie auf einem Gerät betrachten,
das nur einen zweidimensional Bildschirm zur Anzeige hat. Um zu bestimmen, wie unsere
Welt nun schlussendlich auf dem Display gezeigt wird, müssen wir festlegen,wie die Projektion vom Kamera Space in den Projection oder auch Screen Space erfolgen soll. Es stehen für
diese Aufgabe zwei verschiedene Projektionsmodi zur Verfügung. Bei der orthographischen
Projektion erscheinen alle Objekte gleich groß, egal wie weit sie entfernt sind. Diese Projektion wird meist bei 2D Spielen benutzt. Die perspektivische Projektion entspricht unserer
natürlichen Wahrnehmung, je weiter etwas entfernt ist, desto kleiner erscheint es für uns.
Sie wird verwendet, um uns eine dreidimensoniale Welt zu simulieren.
[1][15]
30
Bachelorarbeit
4.5
Spielfiguren
Touchscreens
Touchscreens sind wie in [18] und [32] beschrieben heute weit verbreitete Eingabegeräte, die es
ermöglichen Eingaben mithilfe unseres Fingers oder eines Stiftes auf bestimmten Bereichen des
Bildschirms zu tätigen. Zu finden, sind sie in vielen Bereichen unseres Alltags, beim Fahrkartenautomaten, in Autos, bei unseren neuen Mobiltelefonen den sogenannten Smart Phones und bei
Tablets.
Der erste Schritt in Richtung Touchscreens gelang Dr. Sam Hurst mit seiner Entwicklung des
ersten Touch Sensor im Jahre 1971. Dieser war im Gegensatz zu den heutigen Touchscreens noch
nicht Transparent. 1974 entwickelte Dr. Sam Hurst den ersten Touchscreen, so wie er uns heute
bekannt ist, mit einer transparenten Oberfläche. Es gibt mittlerweile verschiedene Technologien
die wir hier vorstellen möchten.
4.5.1
Resistive Touchscreens
Resistive Touchscreens bestehen aus zwei Schichten einem Top-Layer aus Kunststoff und einem
Grund-Layer der im Allgemeinen aus Glas besteht. Zwischen diesen beiden Schichten sind nichtleitende Abstandshalter, die sogenannten Spacer Dots, die die beiden Schichten voneinander
trennen. Durch den Druck auf den Top-Layer werden die zwei leitendbeschichteten Oberflächen
der beiden Layer zusammengedrückt und es entsteht an der Stelle ein elektrischer Kontakt. Dieser
elektrische Kontakt wird dann vom Controller ausgewertet.
4.5.2
Surface Acoustic Wave Touchscreen
Bei Acoustic Wave Touchscreens werden Signalgeber verwendet die an den Seiten einer Glasfläche
angebracht werden. Diese Signalgeber senden Ultraschallwellen horizontal und vertikal aus. Auf
den gegenüberliegenden Seiten der Signalgeber empfangen Sensoren diese Wellen und werden
durch den Controller ausgewertet. Durch eine Berührung der Oberfläche werden die gesendeten Schallwellen zum Teil absorbiert, wodurch beim Sensor ein verändertes Ergebnis ankommt,
welches vom Controller ausgerechnet wird und so die Position der Berührung berechnet werden
kann. Dieses Verfahren ist sehr genau und die Transparenz der Oberfläche ist sehr gut.
31
Bachelorarbeit
Spielfiguren
4.5. TOUCHSCREENS
4.5.3
Infrarot Touchscreens
Bei Infrarot Touchscreens werden in zwei Seiten im Rahmen des Touchscreens Infrarot LEDs
integriert und auf den gegenüberliegenden Seiten sitzen Phototransistoren, die das Licht empfangen. Durch eine Berührung wird die Verbindung zu beiden Seiten, an der Stelle der Berührung
unterbrochen dieses kann dann wieder vom Controller ausgewertet werden.
4.5.4
Kapazitive Touchscreens
Kapazitive Touchscreens werden wegen ihrer hohen Belastbarkeit, ihrer guten Transparenz und
ihrer hohen Genauigkeit oft in Handys oder Tablets verbaut. Sie sind mit durchsichtigem Metalloxid beschichtet. An den Ecken der Beschichtung ist eine Wechselspannung angelegt, die ein
gleichmäßiges elektrisches Feld über die Oberfläche verteilt. Wird die Oberfläche berühert, wird
ein Teil der elektrischen Ladung über den Finger aufgenommen. Diese Änderung im Elektrischenfeld wird in den Ecken erfasst und stehen im direkten Verhältnis zur Touchposition. Das
Ergebnis wird, wie bei allen anderen Touchscreen Technologien, wieder durch den Controller
weiterverarbeitet und die X und Y Position der Berührung berechnet. Kapazitive Touchscreens
reagieren, im Gegensatz zu den anderen vorgestellten Touchtechnologien, nur auf die Berührung
des Fingers oder Objekten die selbstleitend sind.
4.5.5
Multitouch
Von glsMultitouch ist die Rede, wenn die Touchscreens nicht nur eine Berührung erkennen, sondern gleich mehrere und diese auch verarbeiten können. Bei Kapazitiven Touchscreens werden
hierzu zwei Schichten bestehend aus einer Schicht mit Sendeantennen und einer Schicht mit
Empfängerantennen zwischen dem Display und einer Schutzschicht gelegt. An den Empfängerantennen werden die durch eine Berührung ausgelösten Spannungsänderungen gemessen. Die
Sendeantennen erzeugen das gleichmäßig elektrische Feld und es entsteht eine Kopplung zwischen
Sender und Empfänger.
4.5.6
Was wir verwenden
Handelsübliche Tablets, kann man nur mit zwei der vorgestellten Technologien erwerben, Kapazitiven und resistiven Touchscreens. Da bei resistiven Touchscreens ein gewisser Druck, auf den
Bildschirm ausgeübt werden muss und dieses auf Grund der Größe von den Figuren nur schwer
bzw. nicht 100 prozentig genau ist, ist für unsere App ein resistiver Touchscreen von Nachteil.
32
Bachelorarbeit
Spielfiguren
Zudem werden resistive Touchscreens meistens nur in billig produzierten Tablets, die oft kein
OpenGL ES 2.0 unterstützen, verbaut, was sie für unsere Zwecke unbrauchbar machen.
In unserem Tablet wird ein Kapazitiver Touchscreen verbaut und da unser Spiel mit echten Figuren benutzt werden soll, müssen wir eine Kapazität mit diesen Figuren erzeugen damit ein
Touchevent erkannt werden kann. Deshalb benötigen wir Figuren, die aus einem leitendem Material bestehen. Alle Tablets haben allerdings unterschiedlich viele Touchpunkte, die sie maximal
gleichzeitig erkennen können. Das Maximum liegt bei ca. zehn Touchpunkten gleichzeitig. Bei
vielen Spielen, darunter auch unser Anwendungsbeispiel Mensch ärgere dich nicht haben mehr
als nur zehn Figuren, deswegen darf das Material unserer Figuren keine eigene Kapazität haben,
sondern soll nur Leiten sobald es berührt wird. Man kann auch sagen, es dient als Verlängerung
des Fingers. Aus diesem Grund haben wir uns für Spielfiguren aus Metall entschieden. Es können
jedoch alle Figuren benutzt werden, die aus einem leitendem Material bestehen. Zum Erkennen
der Figuren welche Figur welche ist, gibt es mehrere Möglichkeiten, auf die wir in einem späteren
Kapitel 5.1.1 näher eingehen.
33
Kapitel 5
ANABEL
Jeffrey Wolfe
Jedes Produkt sollte einen Namen haben, damit man weiß wovon gesprochen wird, ohne jedes
Mal zu Beschreiben was es ist. Ein Name verleiht etwas eine Identität. Wir haben unsere App auf
den Namen ANABEL getauft. ANABEL steht für Augmented and Networked App for Board
games to Enhance Life, und soll damit auch gleich beschreiben welchen Zweck diese App hat.
In diesem Kapitel werden wir ANABEL einmal genau vorstellen, erklären den Konzeptionellen
Aufbau und ein Anwendungsbeispiel.
35
Bachelorarbeit
Spielfiguren
5.1. ARCHITEKTUR
5.1
Architektur
Saskia Müller
Abbildung 5.1
Architektur
In dem oben abgebildetem Bild 5.1, sind die Komponenten zu sehen, die dafür nötig sind, um
ANABEL über Entfernung mit mehreren mit mehreren Personen zu Spielen. Hier ist die zur
Zeit angedachte maximal Anzahl an Standorten zu sehen. Dabei wird an jedem Standort ein Tablet, Internetzugriff, ein XMPPAccount und natürlich die App selber benötigt. Die Verbindung
zwischen den einzelnen Tablets geschieht über XMPP und ein bis vier XMPPservern, je nachdem welche Accounts verwendet werden. Die Server untereinander sind ebenfalls über XMPP
verbunden. Mit dieser Weiterleitung haben wir nichts zu tun.
5.1.1
Vorüberlegungen
Jeffrey Wolfe
5.1.1.1 Spielfiguren
Eine Hauptüberlegung bei der Planung war wie man echte Spielfiguren zum Spielen nutzen kann.
Wie bereits in 4.5.6 erklärt wurde müssen Spielfiguren aus einem leitfähigen Material genutzt
werden, damit sie überhaupt auf dem Bildschirm erkannt werden können. Für uns kamen für
die Zuordnung der Figuren nun zwei verschiedene Möglichkeiten in Frage. Entweder alle Figuren
sind gleich, dann müssen sie beim Start alle auf einer vordefinierten Position stehen und werden
36
Bachelorarbeit
Spielfiguren
KAPITEL 5. ANABEL
so zugeordnet. Das heißt die App merkt sich wo sich jede Figur auf dem Spielfeld steht und
aktualisiert diese Informationen bei jedem Spielzug anhand der Logik. Eine Alternative dazu
wäre es, dass Figuren eindeutig erkennbar sind.
Anbieten würde sich dafür ein Verfahren ähnlich dem in [5] beschriebenen. Dabei hätte eine
Figur mehrere Touchpunkte, diese haben je nach Figur unterschiedliche Entfernungen zueinander.
Anhand dieser verschiedenen Distanzen lässt sich dann eindeutig zuordnen um welche Figur es
sich handelt. Denkbar wäre es dabei auch, dass man zusätzlich eine Ausrichtung kodieren könnte.
Die bereits in 3.2 erwähnten Karten könnten auch auf eine ähnliche Weise erkannt werden.
Umgesetzt wurde die Variante mit den gleichwertigen Spielfiguren, die Entwicklung der Kodierung und dafür zu sorgen, dass Spielfiguren mehrere Touchpunkte auslösen, hätte den Aufwand
deutlich erhöht.
5.1.1.2
Würfel
Bei dem Spielwürfel haben wir uns dazu entschieden diesen zumindest vorläufig virtuell einzubauen, jedoch gab bzw. gibt es auch die Idee einen echten oder Dice+ zu verwenden. Hätten wir
einen echten Würfel versucht zu nutzen, sollte es einen Würfelbecher mit einer eingebauten Kamera geben. Diese Kamera würde ein Foto des Würfels aufnehmen wenn er zum Stehen kommt,
welches dann mittels Bilderkennung sagen soll welche Seite oben liegt.
5.2
Testumgebung
Saskia Müller
In diesem Abschnitt gehen wir kurz darauf ein auf welchen Geräten und unter welchen Umständen
wir ANABEL bereits getestet haben. Außerdem beschreiben wir unser Haupttestobjekt, das Acer
Inconia A200 5.2.1, genauer. Neben dem Acer Tablet haben wir für unsere Tests auch das Nexus
7 benutzt. Das Nexus 7 ist allerdings nur ein 7 Zoll Tablet und deswegen nicht sehr gut geeignet,
denn für Figuren ist kein Platz. Da uns nur diese zwei Tablets zur Verfügung standen, haben
wir ANABEL nur an zwei und nicht an vier verschiedenen Orten getestet, außerdem haben wir
auf jeder Seite der Verbindung nur einen Spieler benutzt und ausschließlich gmail.com Accounts
verwendet. Die Internetverbindung bestand in allen Testfällen aus einem Wlan, mit Mobilem
Internet wurde bisher noch nicht getestet.
Unter diesen hier angegebenen Bedingungen funktionierte ANABEL problemlos, einzige Einschränkung war, dass auf Grund der Größe auf dem Nexus 7 keine Figuren getestet werden
konnten.
37
Bachelorarbeit
Spielfiguren
5.3. ANWENDUNGSBEISPIEL
5.2.1
Acer Iconia A200
Das Acer Inconia A200, ist das Tablet auf dem ANABEL entwickelt und getestet wurde. Es ist
ein 10 Zoll Tablet welches OpenGL ES 2.0 fähig ist. OpenGL ES 2.0 ist notwendig um unsere
App laufen zu lassen. Weitere Details zum Tablet listen wir hier einmal auf.
• 10 Zoll Display
• 1280x800 Pixel Auflösung
• Android 4.0 IceCream Sandwich
• OpenGL ES 2.0 fähiger Grafikchip
• Wlan (Beim spielen mit entfernten Personen)
• Kamera
Die 10 Zoll sind wichtig, da sonst ein Spielen mit Figuren nicht möglich wäre, da nicht genug
Platz auf dem Tablet wäre um alle Figuren aufzustellen. Außerdem sind die einzelnen Punkte zu
klein, als das die Figuren überhaupt passend zu den Touchpunkten Größen wären. Da die App in
Android 4.0 programmiert wurde, ist auch eine Android Version von mindestens 4.0 erforderlich,
damit die App läuft. Die komplette Spieloberfläche wurde in OperGL ES 2.0 geschrieben, deswegen muss der Grafikchip dieses unterstützen. Wlan ist erforderlich, da es bei der App möglich ist
auch mit Leuten zu spielen, die sich an einem anderen Ort befinden und die Kamera wird dazu
benutzt um vor Spielbeginn ein Bild von den Mitspielern zu machen, die während des Spielens
angezeigt werden und besonders im Online Modus von Bedeutung sein sollen, da so das Gefühl
gegeben werden soll, dass die andere Person doch nicht so weit entfernt ist.
5.3
Anwendungsbeispiel
Saskia Müller
Im folgenden Anwendungsbeispiel gehen wir davon aus, dass eine kleine Familie, bestehend aus
Mutter, Vater und Kind zu Hause sind in Bremerhaven. Die Oma des Kindes kann leider nicht
da sein, da sie in Berlin wohnt. Sie wollen aber miteinander einen schönen Abend verbringen,
an dem sie Brettspiele spielen. Da die Oma allerdings nicht sehr Technik bewanndert ist, kommt
das Spielen über den PC nicht in Frage, denn die Benutzung der Maus ist für viele ältere Personen schon eine Herausforderung. Deswegen hat die Oma von ihrem Kind ein Tablet geschenkt
bekommen, mit dem sie ganz gut umgehen kann, da sie es mit dem Finger bedienen kann und
somit genau da Klicken kann wo sie möchte und nicht erst versuchen muss, den Mauszeiger an
die richtige Stelle zu bekommen. Da nun beide ein Tablet besitzen, die Familie in Bremerhaven
und die Oma in Berlin, können sie mit unserer App Brettspiele spielen und das sogar mit echten
Figuren, was der Oma besonders gut gefällt, da sie dadurch eher das Gefühl hat, dass ihre Familie
in der Nähe ist und es ihr so leichter fällt, den Überblick über das Spiel zu behalten, als wenn
sie nur bunte Punkte auf einem Bildschirm sieht.
38
Bachelorarbeit
Spielfiguren
KAPITEL 5. ANABEL
Wir teilen das Anwendungsbeispiel in zwei Teile auf. Zum Einen zeigen wir die Vorgehensweise
der Familie, die das Spiel erstellt und danach zeigen wir aus der Sicht der Oma, wie sie diesem
Spiel beitreten kann. Dabei werden wir einmal durch alle Activities unsere App gehen. Activities
in einer Android app sind die verschieden Oberflächen, die die Familie durchlaufen muss, bis sie
zum eigentlichen Spiel gelangen.
5.3.1
Spiel Erstellen
5.3.1.1
Login Activity
Als erstes wenn man die App startet, egal ob man ein Spiel erstellen oder einem beitreten möchte,
muss man sich mit einem Xmppaccount, auch Jabberaccount genannt, einloggen. Zur Zeit ist es
allerdings nur möglich, sich mit einem Googleaccaunt anzumelden. Zum Anmelden gibt der Vater
den Benutzernamen, den Server und das Passwort ein. Anschließend klickt er auf den Button
Login.
Abbildung 5.2
5.3.1.2
Login Activity
Choice Activity
Nachdem er sich erfolgreich eingeloggt hat gelangt er zur Choice Activity. Die Choice Activity
besteht lediglich aus zwei Buttons, zum Einen Spiel erstellen und zum Anderen einem Spiel
beitrete. Hier klickt der Vater auf Spiel erstellen.
39
Bachelorarbeit
Spielfiguren
Abbildung 5.3
Choice Activity
5.3.1.3 Create Game Activity
Nun öffnet sich die Create Game Activity. Standardmäßig ist der Offlinemodus ausgewählt und
die Spieleranzahl auf zwei eingestellt.
Den Modus kann der Vater über die Radiobuttons jederzeit hin- und herschalten und auch die
Spieleranzahl kann er über einen so genannten Spinner jederzeit während des Erstellens eines
Spieles ändern. Er wählt nun den online Modus und die vier Spieler. Hier gibt die Familie nun
ihre drei Namen ein und wählt ihre Farben aus, den Namen der Oma, gibt sie beim Beitreten
zum Spiel selber ein.
Sobald der Vater in den Onlinemodus wechselt kommt ein Hinweistext, dass die Namensfelder
und die Farbfelder für entfernte Spieler frei bleiben sollen. Außerdem ändert sich der Button von
“Spiel erstellen” zu “Erstellen und Freunde Einladen”. Nachdem alles eingetragen ist, klickt der
Vater auf diesen Button und die XMPP Activity öffnet sich.
Abbildung 5.4
40
Create Game Activity Online Modus, vier Spieler Ansicht
Bachelorarbeit
5.3.1.4
Spielfiguren
KAPITEL 5. ANABEL
XMPP Activity
In der XMPP Activity, werden die Freunde vom XMPPaccount angezeigt und es können neue
hinzugefügt werden. Der Vater wählt hier den Accountnamen der Oma aus, indem er diesen
einmal anklickt und anschließend noch auf “Einladen” klickt. Wäre ihr Accountname noch nicht
in der Liste gewesen, hätte der Vater diesen in das Feld direkt unter “Einladen” eingeben können
und danach auf “Freund hinzufügen” klicken können, um ihren Account dauerhaft in seiner
Freundesliste speichern zu können.
Abbildung 5.5
XMPP Activity
Durch den Klick auf “Einladen” wurde die Einladung abgeschickt, und die Oma kann diese
annehmen. Nachdem das geschehen ist, öffnet sich die Spielansicht, die nach dem Beitreten der
Oma genauer gezeigt wird.
5.3.2
5.3.2.1
Spiel Beitreten
Login Activity und Choice Activity
Um dem erstellten Spiel beitreten zu können, muss die Oma sich ebenfalls zuerst mit ihrem
Account einloggen und anschließend in der Choice Activity auf den Button “Spiel beitreten”
klicken.
5.3.2.2
Join Game Activity
In der Join Game Activity, die sich nach dem Klicken auf Spiel Beitreten öffnet, sind alle Einladungen, die an ihren Account geschickt wurden, zu sehen. Zum Annehmen der Einladung, die
41
Bachelorarbeit
Spielfiguren
die Oma von dem Account ihrer Familie erhalten hat, muss sie den entsprechenden Button anklicken und anschließend auf “Einladung Annehmen” klicken. Die Zahlen hinter dem Absender
der Einladung geben an, wie viele Spieler bereits in das Spiel eingetragen wurden und wie viele
insgesamt am Spiel teilnehmen sollen.
Abbildung 5.6
Join Game Activity
5.3.2.3 Accept Invite Activity
Nun öffnet sich die Accept Invite Activity in der die Oma sieht, welche Einstellungen ihre Familie
für dieses Spiel ausgewählt haben, also ihre Namen und die Farbe, die sie ausgewählt haben. In
die freien Felder trägt die Oma nun ihren eigenen Namen und die Farbe, die sie haben möchte
ein. Nachdem sie alles eingetragen hat, drück sie nun noch auf den Button “Antwort Senden”
und das Spiel beginnt auf beiden Seiten.
Abbildung 5.7
42
Accept Invite Activity
Bachelorarbeit
5.3.2.4
Spielfiguren
KAPITEL 5. ANABEL
Spielansicht
Jeffrey Wolfe
Abbildung 5.8
Spielansicht
1
Wie man spielt sollte hoffentlich selbsterklärend sein, trotzdem noch einmal erläutert. Wenn
man am Zug ist, angezeigt durch den Pfeil, der auf das eigene Foto und Spielfarbe gerichtet ist,
darf man Würfeln. Dies tut man indem man mit dem Finger über den Würfel wischt. Solange
alle Spielfiguren auf den Startfeldern stehen hat man drei Versuche eine Sechs zu würfeln und
somit eine Figur raus zu setzen. Man kann jede Figur die sich im Spiel befindet entsprechend
der gewürfelten Augen vorwärts bewegen. Berührt man eine Figur muss man diese auch ziehen,
wohin man ziehen kann wird einem angezeigt siehe Abb.5.9.
1 die
Bilder stammen von : http://www.uncoached.com/wp-content/uploads/2011/04/grandma.jpg ,
http://lespotter001.files.wordpress.com/2009/12/img_1186.jpg ,
http://www.ichbinpapa.de/fileadmin/grafiken/presse/Daniel_Eichhorn.png und
http://www.sabrina-und-andreas.de/myPics/Wir/sonja.JPG
43
Bachelorarbeit
Spielfiguren
Abbildung 5.9
Angezeigtes Ziel
Ob man direkt auf das Zielfeld setzt oder die Felder einzeln abläuft ist einem selbst überlassen.
Stellt man seine Figur auf das Zielfeld ist damit der eigene Zug beendet, sofern man keine
Sechs hatte, und der nächste Spieler ist dran. Befindet sich auf dem Zielfeld bereits eine andere
Spielfigur muss diese wieder auf das nun wieder groß dargestellte Startfeld zurück gesetzt werden.
Ist kein Zug möglich ist direkt der Nächste dran. Wenn man das Spielbrett einmal umrundet hat,
kann man seine Figur in die Zielfelder setzen, dabei dürfen keine Figuren, die sich bereits dort
befinden übersprungen werden. Stehen alle Figuren im Ziel hat man gewonnen und es erscheint
eine Nachricht.
Um eine Spielfigur zu setzen, muss diese nach dem Würfeln einmal berührt werden, erst dann
wird angezeigt, auf welches Feld man diese setzen kann. Bis zu diesem Zeitpunkt kann man
jede beliebige Figur nehmen, die einem selbst gehört. Das Ende eines Spielzuges wird immer
automatisch erkannt. Es ist also keine bestätigende Eingabe seitens des Benutzer nötig, um
den Zug zu beenden, da dieses den Spielfluss unterbrechen würde. Spielregeln, wie bei einer
Sechs muss eine Figur rausgestellt werden, werden nicht geprüft, diese einzuhalten liegt in der
Verantwortung der Mitspieler.
44
Bachelorarbeit
Spielfiguren
KAPITEL 5. ANABEL
Abbildung 5.10
Gewinnmeldung
45
Kapitel 6
Implementierung
Jeffrey Wolfe
Die in im Rahmen dieser Bachelorarbeit entstandene App ist ANABEL. In diesem Kapitel wollen
wir darauf eingehen, wie wir ANABEL umgesetzt haben oder wofür wir zumindest konkrete
Überlegungen gemacht haben wie eine Realisierung aussehen könnte.
6.1
1
2
3
4
5
6
7
8
9
10
11
Android Manifest
Jeffrey Wolfe
.
.
<uses−permission android:name="android.permission.INTERNET" />
<uses−permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses−feature
android:glEsVersion="0x00020000"
android:required="true" />
<supports−screens android:xlargeScreens="true" android:largeScreens="true" android:←requiresSmallestWidthDp="720" android:resizeable="false" android:smallScreens="false"
android:normalScreens="false"/>
.
.
android:screenOrientation="landscape" >
Listing 6.1
←-
Auszug manifest
ANABEL kommt mit lediglich zwei Rechten aus, Internetzugriff und Schreibrechte für den externen Speicher. Die Schreibrechte sind nötig, da die aufgenommen Bilder dort gespeichert werden.
Weiterhin haben wir festgelegt, dass OpenGL ES 2.0 zwingend erforderlich ist. Da sich Geräte
mit kleinem Bildschirm nicht eignen zum Spielen, sind diese nicht zulässig. Um eine korrekte
47
Bachelorarbeit
Spielfiguren
6.2. BOARDGAME
Spieldarstellung zu garantieren, wird die Bildschirmausrichtung im Landschaftsmodus gesperrt.
6.2
Boardgame
Saskia Müller
Unsere App besteht aus sieben verschiedenen Activities. Sie wurden größten Teils per XML
definiert teilweise auch über den Oberflächeneditor für Android in Eclipse und die zwei sehr
dynamisch aufgebauten Activities, XMPPActivity und JoinGameActivity wurden hauptsächlich
im Java Quelltext definiert. Auf zwei Activities wollen wir an dieser Stelle einmal eingehen, um
zu beschrieben, wie eine Activity per XML erstellt wird und wie sie per Quelltext erstellt wird.
Außerdem ist in diesem Paket noch unsere Application, GameApp, enthalten. Dieses ist der
Zentrale Punkt in dem die meisten Objekte gehalten werden und auf den von überall zugegriffen
werden kann. Auch der größte Teil der Logik geschieht zur Zeit in dieser Klasse, dieses werden
wir aber beim Weiterführen dieses Projektes ändern siehe Ausblick Implementierung. In diesem
Paket sind zusätzlich noch drei weitere Pakete, auf die wir noch genauer eingehen.
Abbildung 6.1
6.2.1
Klassendiagramm Paket Boardgame
GameApp
GameApp ist die Zentrale Klasse unserer Implementierung, fast jede Klasse greift auf sie zu. In ihr
werden alle wichtigen Objekte und die Accountnamen der Kommunikationspartner gespeichert.
Außerdem läuft zum jetzigen Zeitpunkt noch ein großer Teil der Logik in dieser Klasse ab.
Hier haben wir alle in Kapitel 3.6.1 angegeben Regeln, die für den richtigen Spielablauf sorgen
implementiert.
48
Bachelorarbeit
Spielfiguren
KAPITEL 6. IMPLEMENTIERUNG
Abbildung 6.2
6.2.1.1
Reduzierte Klasse GameApp
Regeln
Möglichkeit eines Zugs erkennen
Um zu erkennen, ob es einen möglichen Zug für die gewürfelte Augenzahl gibt, wird sobald
das Ergebnis des Würfelwurfes bekannt ist, geprüft ob irgendeine Figur des Spielers gesetzt
werden kann. Dieses geschieht durch Aufruf der Methode anyPossibleMoves(), die weitere
Methoden aufruft. Während des Aufrufs dieser Methode, wird geprüft, ob alle Figuren auf
den Startfeldern stehen, und wenn sie es tun, ob eine Sechs gewürfelt wurde. Und es wird
geprüft, ob es Figuren in den Zielfeldern gibt, wenn ja wird geguckt, ob mit der Würfelzahl,
ohne Überspringen dieser Figur/en, eine Figur gesetzt werden kann. Ist kein Zug möglich
wird automatisch die Methode nextPlayer() aufgerufen, die unter Beachtung aller Regeln
den nächsten Spieler ermittelt, der auch der selbe Spieler sein kann.
49
Bachelorarbeit
Spielfiguren
6.2. BOARDGAME
Möglichkeit Spieler ist ein Weiteres mal am Zug
Ob ein Spieler nochmal am Zug ist wird beim Aufrufen der nextPlayer() Methode unter
Verwendung der onStartField() Methode geprüft, dazu wird die threeTimes Variable zur
Hilfe gezogen. Doch davor wird Überprüft, ob die gewürfelte Zahl eine Sechs ist.
Sechs zum Rausstellen einer Figur
Immer wenn nach dem Würfeln eine Figur angefasst wird, wird die tryMove() Methode
ausgerufen. In dieser wird geprüft, ob die angefasste Figur gesetzt werden kann, und wenn sie
gesetzt werden kann wird der Weg, den sie gehen kann in goal gespeichert. Der letzte Eintrag
in goal, ist das Endfeld, auf dem die Figur nach Beenden des Zuges stehen muss. Bevor diese
Liste aufgebaut wird, wird auf mehrere Fehler überprüft, ob diese Figur überhaupt bewegt
werden kann. Es wird geprüft, ob die Figur überhaupt dem aktuellen Spieler gehört, ob
vor dem Setzen überhaupt gewürfelt wurde, dafür wird das Objekt role benutzt, ob sich
überhaupt ein Token auf dem Feld befindet, dieses kann wichtig sein, wenn der Token auf
dem Spielfeld verrutscht ist oder durch Antippen des falschen Feldes (ausversehen) oder
wenn eine andere Figur bereits angetippt wurde. Ist ein Zug aber möglich, da die eben
genannten Fälle nicht auftreten, wird die Variable goal gefüllt. Ist das angetippte Feld von
Typ eins, also ein Startfeld, wird goal nur mit dem nächsten Feld befüllt. In allen anderen
Fällen wird es mit n*field.next befüllt, wobei n der Anzahl der Augen des Würfelwurfes ist.
Zug endet mit Setzen der Figur auf Zielfeld
Da in goal das Zielfeld für die ausgewählte Figur in Bezug auf das Würfelergebnis gespeichert
wird, ist dieses sehr einfach umzusetzen. Der Zug endet erst, wenn die Figur auf den letzten
Eintrag, der in goal gespeichert ist, gesetzt wird.
6.2.1.2 Spielfigur setzen
Damit eine Figur gesetzt wird muss mindestens zwei mal die Methode tryMove() aufgerufen werden. Das erste Mal wird ihr das Feld auf dem die Figur, die gezogen werden soll, steht aufgerufen.
Daraufhin wird dieses Feld in der Variable inAction gespeichert und die Liste goal wird befüllt.
Beim letzten Mal wird ihr das Endfeld übergeben, auf dem die Figur am Ende des Zuges steht.
Daraufhin wird der Token von dem Feld inAction gelöscht und in dem neuen Feld eingetragen.
Sollte auf dem neuen Feld bereits ein Token gestanden haben, wird dieser mit dem neuen Token überschrieben. Für den rausgeworfenen Token wird über die Methode lookForFreeField() ein
neuer Standort gesucht, auf den dann die Figur zurückgestellt werden muss.
Wenn ein entfernter Spieler ein UpdateMove sendet, wird von der Connection die Methode updateMove() aufgerufen. Diese ruft zuerst mit der, in dem Objekt enthalten, oldID die Methode
tryMove() und anschließend mit newID auf. Es wird also auch beim entfernten Spieler, die Spiellogik aufgerufen. Mithilfe von sendUpdateMove() wird dieses Objekt versendet.
50
Bachelorarbeit
Spielfiguren
Wenn ein UpdateDie eintrifft, wird dieses Ergebnis der Methode fakeRoll() im Renderer mitgeteilt
und der Würfelwurf simuliert.
6.2.2
CreateGameActivity
Anhand dieser Klasse wollen wir auf Android spezifische Programmierung, wie Komponenten,
aufrufen von Activities und ein paar andere Sachen eingehen. Die Klasse CreateGameActivity ist
eine Android Activity, die Angabe von “extends Activity” macht es zu einer Activity. Zusätzlich
muss jede Activity noch dem Android Manifest bekannt gemacht werden, damit diese beim
Aufruf auch als Activity gefunden wird. Das Aussehen dieser Activity haben wir überwiegend in
der Android Layout Datei beschrieben und nicht im Code selber.
Abbildung 6.3
Reduzierte Klasse CreateGameActivity
Layouts
In diesem Abschnitt wollen wir ein paar wichtige Komponenten zeigen und wie diese in einer
Android Layoutdatei definiert werden, anhand der Klasse CreateGameActivity.
51
Bachelorarbeit
Spielfiguren
6.2. BOARDGAME
Button
Bei Android Komponenten, die in der XML definiert werden, wird angegeben durch android:layout_width ob die Große dieser Komponente dem ihr zugewiesenen Text angepasst wird
durch “wrap_content” oder sie z.B. so langgezogen werden, wie die Überliegende Komponente die oft das Layout ist, hier ein GridLayout, durch “fill_parent”. Die Position, an der der
Button angezeigt wird, wird durch die beiden Angaben von android:layout_column und android:layout_row angezeigt. Außerdem kann noch angegeben werden, an welcher Seite die Schwerkraft der Komponente liegt, also an welcher sie angezeigt wird, sollte sie die Position an der sie
sich befindet nicht komplett ausfüllen, durch Angabe von android:layout_gravity. Eine Besonderheit bei Buttons ist android:onClick=“onClickCreate” durch diese Angabe wird die Methode
mit dem Namen onClickCreate der Klasse CreateGameActivity bei einem Klick auf den Button
automatisch aufgerufen. Im Quelltext könnte man dieses durch das Anmelden eines onClickListeners machen. Jede Android Komponente hat außerdem noch eine eindeutige ID, die in der
XML zugewiesen wird, durch die auf diese Komponente im Quelltext wieder zugegriffen werden
kann.
<Button
1
android:id="@+id/bCreate"
android:layout_width="wrap_content"
android:layout_column="0"
android:layout_columnSpan="3"
android:layout_gravity="left"
android:layout_row="9"
android:onClick="onClickCreate"
android:text="@string/bcreate"
android:textSize="40sp" />
2
3
4
5
6
7
8
9
10
Spinner
Der Spinner in Android, ist eine Dropdown Auswahlkomponente, die man auch aus anderen Programmen kennt. Bei ihr kann der Inhalt, welche Auswahlmöglichkeiten zur Verfügung stehen, in
der XML definiert werden, durch Verwendung von Android values. Diese haben wir auch benutzt,
und zwar die Arrays, die Zuweisung dieses geschieht bei uns allerdings erst im Quelltext,(siehe
Beispiel) nicht bereits in der XML. Dieses geschieht aus dem Grund, dass wir hier die bereits
ausgewählten Inhalte, anderer Spinnern, nicht mehr anzeigen wollen, dieses ist allerdings noch
nicht implementiert.
ArrayAdapter<CharSequence> adapterPlayer = ArrayAdapter.createFromResource(this, R.←array.sp_players, R.layout.text_view);
1
RadioButton
RadioButtons werden benutzt um nur einen von mehren Auswahlmöglichkeiten zu akzeptieren,
dafür müssen die zusammengehörenden RadioButtons in eine RadioGroup zusammen gefügt
werden. RadioButtons haben einen speziellen Wert der gesetzt werden kann, das ist der Wert
52
Bachelorarbeit
Spielfiguren
checked. Die übrigen Werte, die wir hier benutzt haben sind zur Beschreibung, an welcher Stelle
dieses Objekt dargestellt werden soll und in in welcher Größe.
1
<RadioButton
android:id="@+id/rbOffline"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="left"
android:checked="true"
android:onClick="onClickOffline"
android:text="@string/offline"
android:textSize="40sp" />
2
3
4
5
6
7
8
9
Um auf diese Komponenten, die in der XML definiert wurden zugreifen zu können, müssen wir
diese in unserer Klasse als Variablen speichern, wir haben uns für globale Variablen entschieden,
da wir an vielen Stellen wieder auf sie zugreifen müssen. Dieses geschieht durch den Befehl
findViewById(R.id.Komponentenid); und einen Cast in die Komponente.
1
eplayer1 = (EditText) findViewById(R.id.etPlayer1);
Dieses machen wir mit allen Komponenten, auf die wir noch einmal zugreifen müssen, dies sind
viele aber nicht alle Komponenten des Layouts. Da wir in dieser Klasse auf unseren globalen Zugriffspunkt der GameApp zugreifen müssen, müssen wir in unsere Klasse folgende Zeile einfügen.
game = ((GameApp)getApplicationContext());
1
Die Zugriffe, die wir auf die Komponenten in unserem Quelltext machen, sind das Setzten der
Sichtbarkeit, das auslesen von Texten, das Auslesen der Position des Spinners und das Ändern
des Textes von den TextViwes. Ist bei dem Klick auf den Button erstellen der RadioButton
online gecheckt, wird eine neue Activity ausgerufen, dieses geschieht mit folgendem Aufruf:
1
2
Intent i = new Intent(this, XMPPActivity.class);
startActivityForResult(i, 1);
Um eine neue Activity aufzurufen, muss zuerst ein neuer Intent erstellt werden mit Angabe
der Klasse, die Aufgerufen werden soll. Danach wird mit dem Befehl startActivity(Intent) die
neue Activity gestartet. startActivityForResult(Intent, 1); benutzt man immer dann, wenn man
nachdem die neu geöffnete Activity geschlossen wurde, ein Ergebnis erhalten möchte und zur
ausgangs Activity zurückkehren möchte. Das Ergebnis wird in der onActivityResult() Methode
verarbeitet.
6.2.2.1
Take Picture
Jeffrey Wolfe
Die Möglichkeiten von Intents wie gerade und in 4.1.2.3 erläutert, machen wir uns zu Nutze um
ein Foto der Spieler machen zu können.
53
Bachelorarbeit
Spielfiguren
6.2. BOARDGAME
1
2
3
4
5
6
7
8
Intent takePictureIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
try {
image = createTempFile("image");
} catch (IOException e) {
return;
}
takePictureIntent.putExtra(MediaStore.EXTRA_OUTPUT, Uri.fromFile(image));
startActivityForResult(takePictureIntent, TAKE_PICTURE);
Beim Klick des Buttons wird ein Intent zum Aufnehmen eines Fotos erzeugt, in diesem Fall ein
Intent der allgemein eine Aufgabe beschreibt. Es wird vom Android System also die standard
Activity für diesen Zweck genutzt. Da wir ein vollwertiges Foto brauchen setzen wir ein Extra,
das der Foto Activity anweist dieses Bild in einer von uns vorgegebenen Datei zu speichern.
1
2
3
4
5
6
7
private File createTempFile(String name) throws IOException{
File file;
name += System.currentTimeMillis();
file = File.createTempFile(name,".png",getExternalFilesDir(null));
file.setWritable(true, false);
return file;
}
Die Datei wird im Daten Ordner, den jede App hat, angelegt und mit einem eindeutigen Bezeichner versehen um Kollision zu verhindern. Um den Ordner unnötig mit etlichen Dateien zu
überfüllen, wird der Inhalt bei jedem Start der App geleert.
In der onActivityResult Methode wird wenn der ResultCode TAKE_PICTURE entspricht ein
weiteres Intent erzeugt.
1
2
3
4
5
6
7
8
9
10
11
12
Intent intent = new Intent("com.android.camera.action.CROP");
intent.setClassName("com.google.android.gallery3d", "com.android.gallery3d.app.CropImage");
intent.setDataAndType(Uri.fromFile(image), "image/png");
intent.putExtra("crop", "true");
intent.putExtra("outputX", 512);
intent.putExtra("outputY", 512);
intent.putExtra("aspectX", 1);
intent.putExtra("aspectY", 1);
intent.putExtra("scale", true);
intent.putExtra("noFaceDetection", true);
intent.putExtra(MediaStore.EXTRA_OUTPUT, Uri.fromFile(croppedImage));
startActivityForResult(intent, CROP_PICTURE);
Wir starten CropImage Activity, die Teil der Gallery ist. Damit soll das eben geschossene Foto
zugeschnitten werden. Um das Bild als Textur nutzen zu können soll das Seitenverhältnis quadratisch sein und die Auflösung eine Zweierpotenz sein. Damit dies sichergestellt wird setzen wir
diese Anforderungen in den Extras.
1
2
3
4
5
6
Bitmap thumb = Bitmap.createScaledBitmap(bitmap, width, height, true);
imButton.setImageBitmap(thumb);
try {
PictureHelper.savePicture(this, pictureForPlayer, bitmap);
.
.
54
Bachelorarbeit
Spielfiguren
Sobald das Bild zugeschnitten wurde, setzen wir eine Thumbnail version als Icon für den Foto
Button und speichern es mit Hilfe des PictureHelper aus dem renderer Paket so, dass es eindeutig
einem Spieler zugeordnet werden kann.
6.2.3
XMPPActivity
Saskia Müller
Anhand der XMPPActivity zeigen wir, wie man einem bestehenden Layout weitere Komponenten
zufügen kann, da dieses dynamisch gestaltet werden muss, weil jeder Benutzer eine unterschiedliche Anzahl an Freunden hat, die er zu einem Spiel einladen könnte. Das Layout für diese Activity
haben wir bereits in der XML festgelegt und uns für ein LinearLayout entschieden, da wir die
Activity nur in der Länge verändern wollen und nicht in der Breite. Um diesem Layout nun
neue Komponenten hinzuzufügen, müssen wir dieses wieder in einer Variablen in unserer Klasse
speichern. Haben wir das getan können wir mit folgenden Befehlen per Quelltext einen neuen
Button hinzufügen:
1
2
3
4
5
6
ToggleButton t = new ToggleButton(this);
t.setTextOn(text);
t.setTextOff(text);
t.setTextSize(45);
t.setChecked(false);
linearLayout.addView(t);
Diese Befehle ähneln denen, die in der XML benutzt werden darum wollen wir hier nichts Näheres
erklären außer, das es wichtig ist, dass die erstellte Komponente durch die addView() Methode
dem Layout bekanntgegeben wird, damit diese auf der Oberfläche auch erscheint. Wir stellen
jeden einzelnen Freund der Freundesliste als einen eigenen ToggleButton dar. Wir haben uns für
ToggleButtons entschieden, da wir später mehr als nur einen Freund zu einem Spiel einladen
können wollen und ToggleButtons dafür schöner fanden als beispielsweise Checkboxen. Diese
speichern wir alle in einer ArrayList um die Buttons später einfach durchlaufen zu können.
Auf weitere Activities gehen wir nicht weiter ein, da wir dort keine besonderen Dinge tun, auf
die genauer eingegangen werden muss, die wir nicht schon durch die zwei Activities beschrieben
haben.
6.3
Spielobjekte
Jeffrey Wolfe
Field
Field ist eine recht simple Klasse, sie enthält lediglich zu welchem Spieler sie gehört, den
Typ, eine ID, die Kanten und welche Spielfigur dort steht, also das Token.
55
Bachelorarbeit
Spielfiguren
6.3. SPIELOBJEKTE
Token
Eine Spielfigur wird durch die Klasse Token repräsentiert. Zur Vereinfachung steht im Token
sowohl das Feld, auf dem es steht, als auch der Spieler, zu dem es gehört.
Player
Über Player gibt es ebenfalls nicht viel zu sagen, lediglich, dass das Attribut local für den
Spielablauf sehr wichtig ist. Dadurch wird entschieden wie der Zug des Spielers realisiert
wird, ein lokaler Spieler wird anders behandelt als ein entfernter, siehe dafür 6.2.1.2.
Roll
Roll stellt das aktuelle Würfel Ergebnis dar und wie viele Schritte noch übrig sind. Die
Schrittweite ist dabei beliebig.
56
Bachelorarbeit
Spielfiguren
Abbildung 6.4
gameLogic Paket
57
Bachelorarbeit
Spielfiguren
6.3. SPIELOBJEKTE
In der aktuell umgesetzten Version der Logik geschieht die Überprüfung von Spielzügen noch
komplett festeinprogrammiert in der GameApp und nicht wie geplant in einer allgemeinen und
austauschbaren Weise. Dies ist einer der wichtigsten Punkte der noch umgesetzt werden soll.
Später soll die Klasse Rule die Oberklasse für alle Regeln darstellen.
Alle anderen Klassen sind implementiert und werden auch genutzt um das Spielen möglich zu
machen.
6.3.1
Board
Das logische Spielbrett wird durch die Klasse Board repräsentiert, in dieser sind alle Spielfelder
enthalten. Alle Instanzen dieses Objekts, die für das komplette Spielfeld nötig sind werden im
Konstruktor aus zwei 2D-Arrays generiert.
1
2
3
4
5
6
7
8
9
10
11
12
13
int[][] DefaultLayout = {
{11,11,00,00,03,03,22,00,00,21,21},
{11,11,00,00,03,29,03,00,00,21,21},
{00,00,00,00,03,29,03,00,00,00,00},
{00,00,00,00,03,29,03,00,00,00,00},
{12,03,03,03,03,29,03,03,03,03,03},
{03,19,19,19,19,00,49,49,49,49,03},
{03,03,03,03,03,39,03,03,03,03,42},
{00,00,00,00,03,39,03,00,00,00,00},
{00,00,00,00,03,39,03,00,00,00,00},
{31,31,00,00,03,39,03,00,00,41,41},
{31,31,00,00,32,03,03,00,00,41,41},
};
Listing 6.2
Mensch ärger dich nicht Brett Layout
Die relevanten Informationen um die Field Objekte zu instanziieren sind recht simpel in den
Zahlenwerten kodiert, die erste Ziffer steht für den Spieler, dem das Feld gehört und die zweite
Ziffer beschreibt den Typ des Feldes. Eine 1 steht etwa für das Startfeld und eine 9 für das
Zielfeld.
1
2
3
4
5
6
String[][] DefaultRule = {
{"0101","0105"},
{"0102","0105"},
{"0201","0105"},
.
.
Listing 6.3
Kanten
Die Kanten, siehe 3.4.1, werden auf eine ähnliche Art und Weise generiert. In der ersten Spalte
steht ein Feld und in den folgenden Spalten stehen die Felder zu denen man von diesem kommen
kann.
58
Bachelorarbeit
6.4
Spielfiguren
Spieldarstellung
Jeffrey Wolfe
Abbildung 6.5
Spiel
Die Darstellung des Spielfeldes erfolgt mittels OpenGL ES 2.0, wobei wir nur die reine OpenGL
API Anbindung von Android nutzen und kein fertige Engine, die den Umgang mit OpenGL
weiter abstrahiert und zusätzliche Funktionalitäten und Helferklassen liefern würde. Da bisher
keine Erfahrung mit OpenGL vorhanden war, habe ich vornehmlich aus Interesse daran OpenGL
kennen zu lernen mich dafür entschieden zunächst auf eine vorhandene 3D Engine zu verzichten.
Die Wahl dazu ES 2.0 statt 1.* zu nutzen begründet sich ebenfalls auf der mangelnden Vorerfahrung, ich habe es als sinnvoll angesehen direkt die aktuelle Version zu lernen auch wenn der
Einsteig sich als schwieriger gestaltet und man weniger Dokumentation findet.
Vorteile von ES 2.0 gegenüber der älteren Version sind eine deutliche größere Flexibilität durch
die Shader, siehe 4.4.5 und eine bessere Performance. Nach dem Fällen dieser Entscheidung
konnte ich damit anfangen den Umgang mit der OpenGL API zu lernen und den renderer zu
implementieren.
59
Bachelorarbeit
Spielfiguren
6.4. SPIELDARSTELLUNG
Abbildung 6.6
Renderer-Paket Klassendiagram
Das Renderer-Paket besteht aus insgesamt 14 (15 wenn man die innere Klasse von GameView
mitzählt) Klassen, wobei die meisten davon Unterklassen von RendererObject darstellen, aber
meist nur im Konstruktor bestimmte Skalierungen oder ähnliches festlegen. Diese Klassen und
RendererObject bedürfen Überarbeitung, RendererObject soll, wie der Name bereits sagt, die
Oberklasse aller zu zeichnenden Objekte sein, wird aber nicht von allen Spielobjekten implemen-
60
Bachelorarbeit
Spielfiguren
tiert bzw. erweitert.
Die Darstellung erfolgt sobald die GameActivity gestartet wird, diese nutzt GameView als ContentView1 .
6.4.1
GameView
Abbildung 6.7
reduzierte GameView Klasse
Die GameView Klasse stellt eine Implementierung der GLSurfaceView aus dem Android Framework dar, eine spezielle Variante einer SurfaceView auf der mit Hilfe eines OpenGL Renderer
gezeichnet wird und dafür in einem eigenen dedizerten Renderer Thread läuft. Da das rendern in
einem eigenen Thread erfolgt, pausiert die GameActivity in ihrer onPause() Methode ebenfalls
die GameView, da es nicht besonders sinnvoll wäre ein Spiel zu rendern was gerade überhaupt
nicht angezeigt wird und dafür Resourcen zu verschwenden. Neben dem Zeichnen des Bildschirms
durch den Renderer erfolgt hier auch der Verarbeitung aller Interaktionen des Spielers mit dem
Touchscreen, also überschreibe ich die abstrakte onTouch(View v, MotionEvent event) Methode.
1
2
3
public boolean onTouchEvent (MotionEvent event){
return gestures.onTouchEvent(event);
}
Einfach nur zu wissen wo der Bildschirm berührt wurde ist für uns nicht ausreichend, daher wird
das event an einen SimpleOnGestureListener weitergereicht, der die ausgeführte Geste erkennt,
man aber nur die Methoden der für uns relevanten Gesten implementieren muss, statt auf alle
zu reagieren.
1
private class GestureListener extends GestureDetector.SimpleOnGestureListener{
2
1 Die
Grafische Darstellung einer Activity
61
Bachelorarbeit
Spielfiguren
GameView view;
3
4
public GestureListener(GameView view){
super();
this.view = view;
}
5
6
7
8
9
public boolean onDown(MotionEvent event) {
if(!onBoard(event)) return true;
makeMove(event);
return true;
}
10
11
12
13
14
15
void makeMove(MotionEvent event){
float x = event.getX();
float y = event.getY();
int cols = game.board.cols();
int rows = game.board.rows();
float width = view.getWidth() * boardscale;
float height = view.getHeight();
float scaleX = cols/width;
float scaleY = rows/height;
int fieldX = (int) (x*scaleX);
int fieldY = (int) (y*scaleY);
Field field = game.board.field(fieldY, fieldX);
if(field!=null) game.tryMove(field);
}
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
@Override
public boolean onFling(MotionEvent e1, MotionEvent e2, float velocityX, float velocityY) {
if(onBoard(e1)) return false;
if(!game.currentPlayer.local) return false;
Log.d("event","fling");
int dx = (int) (e2.getX() − e1.getX()); //Richtung auf der X−Achse
int dy = (int) (e2.getY() − e1.getY()); //Richtung auf der Y−Achse
renderer.rollDie(velocityX, velocityY);
return true;
}
31
32
33
34
35
36
37
38
39
40
41
/*
* Testet ob das Event auf dem Spielbrett war
*/
private boolean onBoard(MotionEvent event){
float x = event.getX();
float boardwidth = view.getWidth() * boardscale;
return(x<boardwidth);
}
42
43
44
45
46
47
48
49
50
@Override
public boolean onScroll(MotionEvent e1, MotionEvent e2,
float distanceX, float distanceY) {
Log.d("Scroll","erkannt");
if(!onBoard(e1) || !onBoard(e2)) return true;
makeMove(e2);
return true;
}
51
52
53
54
55
56
57
58
59
}
62
Bachelorarbeit
Spielfiguren
Zunächst haben wir auf Down, also wenn der Bildschirm einfach berührt wurde und Fling Gesten,
schnelles Wischen über den Bildschirm, reagiert.
Später beim Testen eines kompletten Spielablaufes mit einer Testperson ist uns aufgefallen, dass
das Bewegen der Figuren nur korrekt funktioniert, wenn man die Figur anhebt und auf einem anderen Feld absetzt. Die Testperson hat jedoch versucht die Figur von einem Feld auf ein anderes
zu schieben, was von uns zuvor beim testen nicht bedacht wurde. Aufgrund dessen verarbeiten
wir zusätzlich Scroll Gesten, beachten dabei jedoch nur das zweite MotionEvent, das Ende des
Schiebens, da der Startpunkt bereits in der Down Geste abgearbeitet wurde. Bei allen Gesten
testen wir zuerst ob das Spielbrett berührt wurde oder nicht, Fling Gesten sind nur außerhalb
des Spielfeldes relevant, da sie dazu dienen dem Würfel entsprechend der Wischgeschwindigkeit
auf der X- bzw. Y-Achse einen Drehimpuls zu geben. (36-38) Um zu erkennen welches Spielfeld
berührt wurde, rechnen wir in den Zeilen 19-26 die Bildschirmkoordinaten in Feldkoordinaten
um. Berührungen der Spielfelder werden direkt an die Spiellogik weitergereicht, die diese dann
verarbeitet. Die Darstellung dieser Aktionen und anderer Spielereignisse erfolgt dann im GameRenderer.
63
Bachelorarbeit
Spielfiguren
6.4.2
GameRenderer
Abbildung 6.8
reduzierter GameRenderer
Eine Implementierung der abstrakten Renderer Klasse stellt der von uns verwendete GameRenderer dar, wie dessen Oberklasse läuft dieser in einem eigenen endlos Thread. Sobald die Surface,
die Android Zeichenfläche, existiert werden alle zu zeichnenden Objekt erstellt, OpenGL Einstellungen gemacht, die Matrizen, die die verschiedenden OpenGL Räume repräsentieren, siehe 4.4.6,
initialisiert, Texturen geladen und in einen OpenGL Kontext gebunden, die Shader kompiliert
und deren handle gesetzt. Wenn all diese Dinge geschehen sind wird endlos die onDraw Methode
aufgerufen und somit gezeichnet.
1
2
3
4
Positioniere
nal float eyeX
nal float eyeY
nal float eyeZ
das Auge hinter dem Ursprung.
= 0.0f;
= 0.0f;
= 14f;
5
6
7
8
9
Wir schauen in
nal float lookX
nal float lookY
nal float lookZ
64
die ferne
= 0.0f;
= 0.0f;
= −5.0f;
Bachelorarbeit
Spielfiguren
10
11
12
13
14
Blickrichtung der Kamera
nal float upX = 0.0f;
nal float upY = 1.0f;
nal float upZ = 15.0f;
15
16
17
Setzen der Viewmatrix, sie repräsentiert unsere Kamera
trix.setLookAtM(mViewMatrix, 0, eyeX, eyeY, eyeZ, lookX, lookY, lookZ, upX, upY, upZ);
Listing 6.4
1
2
Initialisierung der View Matrix
blic void onSurfaceChanged(GL10 gl, int width, int height) {
field = new RendererField();
3
4
GLES20.glViewport(0, 0, width, height);
5
6
7
8
9
10
11
12
13
14
15
// Erstellen einer neuen Projektions Matrix, die höhe bleibt gleich
// während die Breite abhängig vom Seitenverhältnis ist.
final float ratio = (float) width / height;
final float left = −ratio;
final float right = ratio;
final float bottom = −1.0f;
final float top = 1.0f;
final float near = 1.0f;
final float far = 15.0f;
Matrix.frustumM(mProjectionMatrix, 0, left, right, bottom, top, near, far);
Listing 6.5
Initialisierung der Projektions Matrix
Die Projektionsmatrix wäre abhängig von der Ausrichtung des Tablets, jedoch forcieren wir den
Landscape Modus, daher ändert sich diese nicht.
Der Großteil des Rendern geschieht passiv, das heißt es wird der Zustand aller Spielobjekte,
die eine visuelle Repräsentation haben überprüft und entsprechend ihrer Zustände gezeichnet.
Beispielsweise wird über alle logischen Spielfelder iteriert und abgefragt welche Farbe sie haben,
abhängig z.B. davon welcher Spieler darauf steht, entsprechend dessen werden sie dann dargestellt. Ein Spielfeld existiert im Renderer nur als ein einzelnes Objekt, dass dann mehrfach an
unterschiedlichen Positionen gezeichnet wird.
1
2
3
4
5
6
7
8
for(int col=0;col<game.board.cols();++col){
for(int row=0;row<game.board.rows();++row){
.
Abfragen relevanter informationen über das Spielfeld
.
drawField(x,y,size,color);
}
}
Zur Darstellung des Spielfeldes werden zwei verschiedene Texturen benutzt:
65
Bachelorarbeit
Spielfiguren
Abbildung 6.9
Standart Feld Textur
Abbildung 6.10
Hervorgehobene Textur2
Zwei wichtige Hilfsklassen zum Darstellen des Spielfeldes sind die beiden Hilfsklassen TextureLoader und TextureColor.
TextureLoader
Texturen können entweder aus Datein, Bitmaps oder Resourcen geladen und in den OpenGL
Kontext gebunden werden.
TextureColor
Erzeugt aus einer Farbe einen OpenGL kompatiblen FloatBuffer zum Einfärben einer Textur.
Das einzige 3D Objekt im Spiel, der Würfel, wird aktiv durch das bereits in 6.4.1 erwähnte
Wischen über den Bildschirm beeinflusst.
2 Grau
66
hinterlegt damit man den Schein erkennen kann
Bachelorarbeit
6.4.3
Spielfiguren
RendererDie
Abbildung 6.11
Würfel Textur
Wie man direkt sehen kann, wird diese Textur nicht einfach auf eine Fläche des Würfels abgebildet, sondern Teile der Textur auf unterschiedliche Flächen, so erhalten wir einen komplett
texturierten dreidimensionalen Würfel.
67
Bachelorarbeit
Spielfiguren
Abbildung 6.12
reduzierter RendererDie
Die Rotation des Würfels kann auf zwei Weisen initiiert werden, entweder wenn ein Spieler würfelt
oder ein simulierter Wurf, der nur dazu dient darzustellen, dass ein entfernter Spieler gewürfelt
hat. Bei einem echten Wurf wird der Würfel zeitabhängig um die X- und Y-Achse rotiert, die
Geschwindigkeiten nehmen dabei durch Multiplikation mit einem Dämpfungsfaktor kontinuierlich ab, solange bis beide einen Schwellenwert unterschreiten. Ist dieser Wert unterschritten wird
überprüft welche Seite oben liegt. Um zu bestimmen welche Seite dies ist, gehen wir dabei wie
folgt vor: Für jede Seite wird ein Vektor im Objektraum definiert, der angibt wohin diese Seite
zeigt.
1
2
3
4
5
6
private
private
private
private
private
private
float[]
float[]
float[]
float[]
float[]
float[]
leftVec
= new float[]{−1,0,0,1};
rightVec = new float[]{1,0,0,1};
upVec
= new float[]{0,1,0,1};
downVec
= new float[]{0,−1,0,1};
forwardVec = new float[]{0,0,1,1};
backVec
= new float[]{0,0,−1,1};
Wir wollen nun wissen wie diese Vektoren in der Bildschirmdarstellung ausgerichtet sind, dafür
werden diese mit der kombinierten Model-View-Projektions Matrix multipliziert.
1
2
3
4
5
6
float[]
float[]
float[]
float[]
float[]
float[]
leftInEyespace = callback.getVecInEyespace(leftVec, modelMatrix);
rightInEyespace = callback.getVecInEyespace(rightVec, modelMatrix);
upInEyespace = callback.getVecInEyespace(upVec, modelMatrix);
downInEyespace = callback.getVecInEyespace(downVec, modelMatrix);
forwardInEyespace = callback.getVecInEyespace(forwardVec, modelMatrix);
backInEyespace = callback.getVecInEyespace(backVec, modelMatrix);
callback ist hier eine Referenz auf GameRenderer.
1
public float[] getVecInEyespace(float[] vec, float[] modelMatrix){
68
Bachelorarbeit
Spielfiguren
float[] resultVec = new float[4];
2
3
Matrix.multiplyMM(mMVPMatrix, 0, mViewMatrix, 0, modelMatrix, 0);
Matrix.multiplyMV(resultVec, 0, mMVPMatrix, 0, vec, 0);
return resultVec;
4
5
6
7
}
Um nun zu bestimmen welche Seite aus der Sicht des Spielers oben liegt, bilden wir die Skalarprodukte der erhaltenen Vektoren mit dem Vektor der aus dem Bildschirm heraus zeigt, also
somit nach oben gerichtet ist. Der Vektor, der dabei das größte Ergebnis liefert entspricht, nun
der Seite die oben liegt, wobei sich gezeigt hat dass ab einem Wert von -16.84 die Seite sehr
eindeutig erkennbar oben liegt und wir somit direkt die Rotation stoppen können. Ist der Wert
jedoch kleiner, rotieren wir den Würfel entsprechend des Ergebnisses und stoppen dann. Hierbei
wäre es für eine spätere Version wünschenswert, wenn der Würfel nicht einfach abrupt stoppen,
sondern ausrollen würde. Zuletzt wird die Augenzahl der Spiellogik mitgeteilt.
Drei der genutzten Texturen wurden bereits gezeigt, nun nur noch kurz die restlichen Texturen
aufgelistet.
6.4.4
Texturen
Abbildung 6.13
Spielbrett Textur
69
Bachelorarbeit
Spielfiguren
6.5. NETZWERKKOMMUNIKATION
Abbildung 6.14
Abbildung 6.15
Spielzug Textur
Foto Umrandungs Texturen
Das waren die letzten Texturen die direkt fertig vorhanden sind, dazu kommen noch die Texturen,
die aus den Fotos, die alle Spieler von sich machen können, generiert werden. Dazu dienen Fotos
die man in der createGameActivity, 6.2.2 machen kann und durch den PictureHelper aus dem
Speicher geladen werden.
6.5
Netzwerkkommunikation
Saskia Müller
Unser Paket “Network” besteht aus neun verschiedenen Klassen, wovon vier Klassen, InviteAccepted, UpdateMove, Invite und UpdateDie , die Objekte repräsentieren, die wir bei einem online
Spiel versenden und vier davon sind die zu den Objekten gehörenden Provider, InviteAcceptedProvider, UpdateMoveProvider, InviteProvider und UpdateDieProvider. Die neunte Klasse in
diesem Paket ist die Hauptklasse der Kommunikation, Connection. Hier wird die Kommunikation aufgebaut, Pakete die von einem anderen Mitspieler gesendet wurden empfangen und eigene
Pakete versendet. Die vier Objekte werden dabei von verschiedenen Klassen erstellt und der
Kommunikationsklasse Connection übergeben. Diese Klassen sind CreateGameActivity, AccInviteActivity und GameApp.
70
Bachelorarbeit
Spielfiguren
Abbildung 6.16
6.5.1
Klassendiagramm Network Paket
Funktionsweise XMPP
Um XMPP zu benutzen sollten einige Begriffe klar sein. Im XMPP Kontext bezeichnet man mit
Packet die Objekte die von einem Benutzer an seinen Server geschickt werden. Es gibt viele verschiedene Packets, zum Beispiel zum Anzeigen des Status, ob man online, offline oder abwesend
ist. Ein bestimmtes Packet, welches für die Kommunikation mit anderen Personen verwendet
wird, ist die Message, diese hat einen Absender und einen Empfänger und wird nach Eintreffen
beim Server an den Empfänger weiter geleitet. Außerdem kann man an Packets verschiedenes
anhängen, beispielsweise Properties oder PacketExtensions. Mit Properties werden hauptsächlich primitive Datenstrukturen wie int oder boolean versendet. Eine PacketExtension kann alles
sein. Darum muss, wenn man eine eigene PacketExtension benutzt, auch ein eigener Provider
geschrieben werden. Ein Provider parst den Inhalt, der PacketExtension, die als XML versendet
wird, nach dem Versenden in den ursprünglichen Inhalt zurück. Der Roster dient der Freundesverwaltung, z.B. ob ein Freund online ist oder um neue Freunde hinzu zu fügen.
71
Bachelorarbeit
Spielfiguren
6.5.2
Klasse Connection
Abbildung 6.17
Klasse Connection
Die Klasse Connection ist die wichtigste Klasse, wenn online gespielt wird. Sie wird in der LoginActivity.class erstellt und der public variable “connection” der GameApp zugeordnet. Im ganzen
Spielverlauf wird auf sie über diese Variable zugegriffen. In GameApp selber werden auf zwei
verschiedene Methoden von Connection zugegriffen, diese sind jene zum Updaten des Spielablaufs sendUpdateMove() und send updateDie(). Die Methoden sendInvite() und sendPicture()
werden von der CreateGameActivity aufgerufen, getFriends() und addFriends() wird von der
XMPPActivity aufgerufen und sendInviteAccepted() wird von der AccInviteActivity aufgerufen.
Auf die Connection wird also von vielen verschiedenen Klassen zugegriffen.
Das Meiste in dieser Klasse geschieht allerdings im Konstruktor. Ihm werden die Einlogdaten für
die XMPPverbindung übergeben. In ihm wird eine Verbindung aufgebaut, Provider und Lisener
angemeldet und die Freundesliste ausgelesen.
Da alles was in der Connection passiert über die XMPPConnection läuft, ist das Erste was wir
machen eine XMPPConnection aufzubauen. Dieses geschieht in einem neuen Thread, da hier
auch Listener laufen die allerdings wartend und nicht aktiv sind. Für den Verbindungsaufbau
benötigen wir drei Befehle. Der Erste gibt an, zu welchem Server sich verbunden werden soll,
mit Standardeinstellungen. Dieses könnte zum Beispiel gmail.com sein. Der Zweite baut eine
Verbindung zum angegeben Server auf und mit dem Dritten loggt man sich mit seinen angegeben
Daten am Server ein. Das Wichtige beim 2. Schritt, ist das hier eine XMPPException abgefangen
werden muss.
72
Bachelorarbeit
1
2
3
4
Spielfiguren
xmpp = new XMPPConnection(server);
try {
xmpp.connect();
xmpp.login(name , passwort);
Nachdem wir uns erfolgreich eingeloggt haben, müssen wir unsere Provider anmelden, damit
wir erhaltene Pakete, die von einer anderen Instanz unseres Spieles ankommen, auch verwerten
können. Dafür müssen wir für jedes unserer vier Objekte die Provider mit einer solchen Zeile
anmelden.
1
roviderManager.getInstance().addExtensionProvider("updateMove", "game:update:move" , new
UpdateMoveProvider());
←-
Hierbei ist der erste Parameter der ElementName, der dem Wurzelelement unseres Objektes
entspricht, der zweite Parameter ist der Namespace, den wir dem Objekt gegeben haben und der
dritte Parameter ist eine Instanz unseres, zum Objekt gehörenden, Providers.
Nachdem die Provider angemeldet sind müssen wir noch Pakete empfangen können. Dazu benötigen wir einen PacketListener oder einen PacketCollector. Wir benutzen einen PacketCollector,
denn wir sollen auf Pakete reagieren und nicht so wie die meisten Instantmessanger einfach jedes
Packet, sobald es ankommt, auf den Bildschirm werfen. Da wir nicht jedes ankommende Paket
behandeln wollen, wie beispielsweise jede Chatnachricht, sondern nur die für das Spiel relevanten
Pakete, übergeben wir dem PacketCollector einen Filter. Dadurch, erhalten wir nur Pakete, die
eine Message sind und eine unserer PacketExtensions enthält. Dieses sieht im Quelltext, wie folgt
aus.
1
2
3
4
5
6
7
OrFilter filter = new OrFilter(new PacketTypeFilter(Message.class),
new PacketExtensionFilter("game:inviteaccepted"));
filter.addFilter(new PacketExtensionFilter("game:invite"));
filter.addFilter(new PacketExtensionFilter("game:update:move"));
filter.addFilter(new PacketExtensionFilter("game:update:die"));
andFilter = new AndFilter(filter);
collector = xmpp.createPacketCollector(andFilter);
Wenn ein akzeptiertes Packet ankommt, wird je nachdem welche PacketExtension das Packet
enthält eine andere Methode aus einer anderen Klasse aufgerufen oder der Klasse GameApp
etwas hinzugefügt.
Wird eine der anderen Methoden unserer Klasse aufgerufen, wird je nach Methode ein neuer
Chat erstellt oder nur eine neue Nachricht gesendet. Ist es die erste Nachricht, die an einen
anderen Spieler geschickt wird, muss ein neuer Chat erstellt werden, der dann für das gesamte
Spiel weiter genutzt wird. Über ihn werden dann im Spielverlauf immer wieder updateMove und
updateDie Pakets gesendet. Indem als erstes eine neue Message erstellt wird und ihr dann die
gewünschte PacketExtension angehangen wird.
73
Bachelorarbeit
Spielfiguren
6.5.3
Provider
Wie schon erwähnt werden in dem Constructor dieser Klasse Provider am ProviderManager
angemeldet, damit unsere vier PacketExtension sinnvoll in ein Objekt zurückgeparst werden
können. Diese Providerklassen müssen PacketExtensionProvider Implementieren und eine Methode überschreiben. Diese ist die parseExtension(parser : XmlPullParser) : PacketExtension.
An dem Beispiel von UpdateMoveProvider werden wir dieses einmal zeigen. Alle vier Klassen
sind von der Funktionsweise her gleich und besitzen alle nur diese eine Methode.
public class UpdateMoveProvider implements PacketExtensionProvider{
1
2
3
4
5
6
7
8
9
public PacketExtension parseExtension(XmlPullParser parser) throws Exception {
boolean stop = false;
int evtType;
String n;
String tId = "";
String fOld = "";
String fNew = "";
10
while (!stop) {
evtType = parser.next();
n = parser.getName();
switch (evtType) {
case XmlPullParser.START_TAG:
11
12
13
14
15
16
if ("tokenId".equals(n)){
tId = parser.nextText();
}
if ("fieldIdOld".equals(n)){
fOld = parser.nextText();
}
if ("fieldIdNew".equals(n)){
fNew = parser.nextText();
}
17
18
19
20
21
22
23
24
25
26
break;
case XmlPullParser.END_TAG:
//Stoppe parser bei Tag </updateMove>
if("updateMove".equals(n)){
Log.v("end_tag" , n);
stop = "updateMove".equals(n);
}
27
28
29
30
31
32
33
34
break;
35
}
36
}
return (new UpdateMove(tId, fOld, fNew));
37
38
39
}
}
40
In dieser Methode habe ich jeweils die Variablen der Klassen zu denen der Provider gehört,
deklariert. Hier sind es tId für TockenID, fOld für die ID des alten Feldes und fNew für die ID
des neuen Feldes, auf dem von nun an der Token steht. Außerdem habe ich noch drei Variablen,
74
Bachelorarbeit
Spielfiguren
die für das Parsen notwendig sind angelegt. Das Parsen läuft so lange weiter bis der End_Tag,
der dem Klassennamen entspricht, hier “updateMove”, erreicht ist und die Variable “stop” auf
true gesetzt wurde. Solange der End_Tag nicht erreicht ist, werden die Start_Tags überprüft,
ob diese einem der Variablen der Klasse entsprechen und daraufhin der nächste Text, den der
Parser zurück gibt der dazugehörigen Variable zugeordnet. Am Ende wird aus den Variablen das
ehemals versendete Objekt wieder hergestellt und zurückgegeben.
6.5.4
Network Objekte
Unsere Network Objekte haben wir bewusst sehr simpel gehalten, da wir diese wieder zurückparsen müssen und dieses je nach dem welche Datenstrukturen versendet werden sehr komplex
werden kann. Da wir sie über XMPP als PacketExtension versenden wollen, müssen diese Klassen
PacketExtension implementieren. Dieses Interface gibt uns vor, dass wir drei Methoden überschreiben müssen von denen für uns nur eine relevant ist und zwar die toXML() Methode. In
dieser geben wir an, wie unser Objekt als XML aussieht und geben dieses als String zurück.
Wir haben hierfür das Framework Simple benutzt, das uns einen Stream zurückgibt, welchen wir
in einen String umändern mussten, deshalb haben wir uns für einen ByteArrayOutputStream
entschieden, da bei diesem die toString() Methode uns das Ergebnis zurückliefert, das wir haben
wollen. Ein Codebeispiel hierfür wollen wir zeigen, indem wir die UpdateMove Klasse zeigen. Um
Simple benutzen zu können haben wir hier fünf Zeilen eingefügt, für unsere drei Variablen haben
wir jeweils die Zeile @Element eingefügt. Außerdem mussten wir einen Namespace einfügen, da
über diesen der dazugehörige Provider geöffnet wird. Um einen einstieg für unseren Parser zu
haben, ab wann unser Objekt anfängt, haben wir noch @Root am Klassenanfang eingefügt durch
das unser XML String mit den Start_Tags updateMove beginnt und mit diesem End_Tag auch
wieder aufhört.
1
2
3
4
5
6
7
8
9
@Root
@Namespace(reference="game:update:move")
public class UpdateMove implements PacketExtension{
@Element
public String tokenId;
@Element
public String fieldIdOld;
@Element
public String fieldIdNew;
10
11
public UpdateMove(){
12
13
}
14
15
16
17
18
19
public UpdateMove(String tId, String fOld, String fNew){
tokenId = tId;
fieldIdOld = fOld;
fieldIdNew = fNew;
}
75
Bachelorarbeit
Spielfiguren
6.6. INTERNE ABLÄUFE
20
21
22
23
24
@Override
public String getElementName() {
return ("updateMove");
}
25
26
27
28
29
@Override
public String getNamespace() {
return ("game:update:move");
}
30
31
32
33
34
35
36
37
@Override
public String toXML() {
Serializer serializer = new Persister();
ByteArrayOutputStream os = new ByteArrayOutputStream();
String xml = "";
try {
serializer.write(this , os);
38
39
} catch (Exception e) {
System.out.println("fehler to xml");
}
xml = os.toString();
return xml;
40
41
42
43
44
45
46
}
}
Alle vier unserer Network Objekte haben die gleichen Methoden und sind sehr ähnlich aufgebaut.
Für Simpel haben wir uns entscheiden, da hierdurch auf sehr einfachem Wege aus einem Objekt
ein XML entsteht. Wir mussten so nur in jedem Objekt einmal @Root, @Namespace mit den
dazugehörigen Namespace angeben und für jede Variable einmal @Element angeben. Dadurch
können wir bei allen vier Klassen die gleiche toXML Methode benutzen und mussten so nicht
aufwendig die XML selber erstellen. Würden wir beispielsweise eine Liste oder andere Objekte in
unserem Objekt haben, könnte dieses aufwendig werden und ist Dank Simple immer die gleiche
einfach Methode.
6.6
Interne Abläufe
Im diesem Abschnitt, wollen wir die wichtigsten Klassen beschrieben und sind auf ihre Verbindungen zu anderen Klassen eingegangen. Wir wollen genauer darauf eingehen, was im Hintergrund
von ANABEL geschieht, wenn ein Spiel erstellt oder einem beigetreten wird und was geschieht
während gespielt wird. Zu diesem Zweck haben wir Sequenzdiagramme erstellt.
76
Bachelorarbeit
6.6.1
Spielfiguren
Spiel Erstellen
Abbildung 6.18
Interner Spielablauf beim Spiel erstellen
Bevor ein Spiel erstellt werden kann muss zunächst einmal die App gestartet werden. Nachdem
die App gestartet ist, wird als erstes die LoginActivity aufgerufen, dieses wird im Android Manifest festgelegt. Nachdem der Benutzer seine Eingaben gemacht und auf Einloggen gedrückt
hat, wird die connection in GameApp gesetzt und die CreateGameActivity gestartet. Nun ist
wieder eine Interaktion vom Benutzer gefordert, auf die hin die XMPPActivity gestartet wird.
Diese muss zum Darstellen der Freundesliste zuerst die connection aus GameApp abfragen und
anschließend den roster aus Connection abfragen. Nachdem die XMPPActivity diese erhalten hat
kann die Oberfläche dargestellt werden. Nun ist erneut eine Aktion des Benutzers gefordert, nach
der die XMPPActivity die Variable to in der GameApp setzt und zurück zur CreateGameActivity
kehrt. Diese fragt die eben gesetzte Variable to wieder ab und sendet eine Einladung an diese
XMPPAdresse, indem die Connection aufgerufen wird. Die connection sendet die Einladung über
77
Bachelorarbeit
Spielfiguren
das Internet zum zweiten Benutzer. Nun wird gewartet, bis der zweite Benutzer die Einladung
annimmt und die akzeptierte Einladung in der Connection eingeht. Die Connection leitet die
eingegangene Einladung an die CreateGameActivity weiter, welche die Daten aus dieser extrahiert und der GameApp übergibt, in der das Spiel initiiert wird und die GameView aufgerufen
wird. Diese wird laufend aktualisiert und läuft bis zum Spielende weiter, und wird durch den
offenen Balken dargestellt. Der Übersicht halber haben wir im Diagramm einen Schritt weggelassen. Nach der LoginAtivity wird die ChoiseActivity aufgerufen, nach der wieder eine Aktion
des Benutzers gefordert ist, auf die hin sich die CreateGameActivity öffnet.
78
Bachelorarbeit
6.6.2
Spielfiguren
Spiel Beitreten
Abbildung 6.19
Interner Spielablauf beim Spiel beitreten
Beim Spiel beitreten sind die ersten Schritte genau wie beim Erstellen, der erste Unterschied ist
erst, dass die LoginActivity und nicht die CreateGameActivity gestartet wird. Auch hier wurde
die ChoiceActivity als Zwischenschritt auf Grund der Übersichtlichkeit weggelassen. Um einem
Spiel beizutreten, muss man zuerst eine Einladung erhalten, diese wird vom anderem Benutzer
gesendet, und kommt nach dem Senden in der Connection an. Die Connection fügt die erhaltene
Einladung, den Einladungen, die in der GameApp gespeichert werden hinzu. Diese Einladungen
79
Bachelorarbeit
Spielfiguren
werden von der LoginAtivity abgefragt und daraus die Oberfläche generiert. Der Benutzer 2
wählt nun eine dieser Einladungen aus. Diese wird von der LoginAtivity als Ausgewählte in die
GameApp eingetragen und anschließend die AccInviteActivity gestartet. Damit diese die Daten
in der Oberfläche eintragen kann, die in der Einladung gespeichert sind muss die ausgewählte
Einladung aus Gameapp abgefragt werden. Die nun noch offenen Felder müssen vom Benutzer
2 ausgefüllt werden und die Einladung angenommen werden. Hat der Benutzer auf Annehmen
geklickt, wird die connection aus GameApp abgefragt und die angenommene Einladung an diese übermittelt. Die Connection sendet diese angenommene Einladung über das Internet an den
anderen Benutzer zurück. Nun wird von der AccInviteActivity die GameApp initiiert und die
GameView gestartet.
Nun ist auf beiden Seiten die Spieldarstellung gestartet und der Benutzer löst, durch Wisch-,
Schiebe- oder Anhebebewegungen Aktionen in unserer App aus.
80
Bachelorarbeit
6.6.3
Spielfiguren
Spielzüge
Jeffrey Wolfe
Abbildung 6.20
Interner Spielablauf beim Spielzug
Bei einem Spielzug werden zwei verschiedene Aktionen vom Spieler durchgeführt, entweder er
bewegt eine Figur oder er wischt über den Bildschirm zum würfeln. In beiden Fällen wird ein
Event ausgelöst, dass an die GameView gesendet und von dort an den GestrueListener weitergereicht wird. Dort wird das Event ausgewertet. Wurde gewürfelt fordert der GestureListener
den GameRenderer dazu auf zu Würfeln, dieser startet den Wurf im RendererDie in dem dort
die Geschwindigkeiten gesetzt werden. Der GameRenderer rendert die Szene kontinuierlich und
fordert den RendererDie regelmäßig auf sich zu aktualisieren. Der RendererDie rotiert daraufhin und gibt seine aktuelle Ausrichtung an den GameRenderer zurück. Die GameView zeichnet
die Szene dann in der Androidoberfläche. Ist der Würfel ausgerollt wird das Ergebnis an die
GameApp mitgeteilt.
Wenn der Spieler eine Figur bewegt hat, gibt der GestureListener der GameApp das berührte
Feld bekannt und es erfolgen Änderungen in Board.
81
Bachelorarbeit
Spielfiguren
6.7. AUSBLICK IMPLEMENTIERUNG
Wie bereits erwähnt wird ununterbrochen gerendert, dabei wird jedes mal der Aktuelle Zustand
des Spielbrettes abgefragt und dann dargestellt.
6.7
Ausblick Implementierung
Jeffrey Wolfe
Die aktuelle Implementierung deckt zwar bereits die von uns gesetzten Mindestanforderungen
ab, jedoch nur für Mensch ärgere dich nicht und nicht für die von uns definierten klassischen
Brettspiele. Wir wollen in diesem Abschnitt ansatzweise darauf eingehen, wie wir bisher gedenken
verschiedene Spiele zu ermöglichen.
Ein Spielbrett ist bereits allgemein umgesetzt, bedarf aber wahrscheinlich noch Anpassungen.
Ein allgemeines Regelsystem fehlt aber bisher noch gänzlich.
Abbildung 6.21
82
Klassendiagramm Verallgemeinerung von Regeln
Bachelorarbeit
6.7.1
Spielfiguren
Rule
Die Klasse Rule wird zu einem Oberinterface für MoveRule und StateRule, die ebenfalls Interfaces
sind. Das Attribut active gibt an ob diese Regel beachtet werden soll oder nicht, dadurch soll die
geplante variable Spielunterstützung möglich sein. watchedObjects Stellt eine Liste der Objekte
dar, die zum Testen der Regel relevant sind. test() überprüft die Regel und liefert zurück, ob sie
erfüllt wurde oder nicht. Wie und was getestet wird muss entsprechend in test() einprogrammiert
werden.
6.7.1.1
StateRule
StateRule stellt eine Abstraktion von Situationsregeln dar, zusätzlich zu den watchedObjects existiert eine Liste von beeinflussbaren Objekten, affectedObjects. Diese Objekte können verändert
werden wenn apply aufgerufen wird, was genau dann geschieht hängt von den zu implementierenden konkreten Situationsregeln ab.
6.7.1.2
MoveRule
MoveRule steht repräsentativ für eine Übergangsrelation und gehört daher zu dem Kanten Objekt
Edge.
6.7.2
Edge
Statt einer Liste von Folgefeldern sollen in einem Feld eine Reihe von Kanten stehen die in Edge
umgesetzt werden. Jede Kante führt eine Liste von Übergangsrelationen.
83
Kapitel 7
Fazit und Ausblick
7.1
Was implementiert wurde
Jeffrey Wolfe
Wir fassen noch einmal kurz zusammen was bisher alles erreicht wurde:
• Ein komplett spielbares Mensch ärgere Dich nicht Spiel auf dem Tablet
• Erkennen von metallischen Spielfiguren
• Virtueller Würfel, der auf Wischen auf dem Bildschirm reagiert
• Spielen mit vier Personen
• Spielen über das Internet
• Netzwerkkommunikation mittels XMPP
• Minimales, unflexibles Regelsystem das entferntes Spielen möglich macht
• Aufnehmen von Benutzerfotos und Anzeigen dieser für lokale Spieler
Somit haben wir die Anforderungen, die wir uns selber gesetzt haben erfüllt, und ein nettes
extra Feature, die Spielerbilder. Jedoch sind noch Funktionen offen, die wir noch gerne umsetzen
würden.
7.2
Ausblick
Jeffrey Wolfe
Da uns das Entwickeln von ANABEL viel Spaß bereitet hat und wir dabei auch ziemlich erfolgreich waren, besteht sehr viel Motivation die Arbeit fortzuführen und aus diesem Prototypen
ein vollwertiges Produkt zu machen. Um dieses Ziel zu erreichen haben wir bereits sehr genaue
Vorstellungen was wir umsetzen wollen.
Regelsystem
In der aktuellen Version sind die vorhandenen Regeln fest einprogrammiert und es werden
auch nur, die für die Spielsynchronisation zwingend notwendigen, umgesetzt. Dies soll auf
85
Bachelorarbeit
Spielfiguren
7.2. AUSBLICK
jeden Fall geändert werden. Das Regelsystem soll komplett verallgemeinert werden, so dass
Regeln beliebig zugefügt, entfernt, an- bzw. ausgeschaltet oder ausgetauscht werden können und es somit möglich ist die Regeln mehrere Brettspiele zu unterstützen, also auch zu
variieren wie sehr das Spiel automatisiert werden soll.
Unterschiedliche Spiele
Das Umsetzen des gerade erwähnten Regelsystems und das bereits allgemein gehaltene Spielbrett, wobei sicher noch Anpassungen erfolgen müssen, sollten es uns ermöglichen unterschiedliche Brettspiele zu realiseren, die nur einen Würfel und Spielfiguren erfordern.
Import-Export
Damit es möglichst simpel ist neue Spiele zuzufügen muss eine Option zum Importieren bzw.
zum Exportieren von Brettspielen in einem eigenen Format implementiert werden.
Umstieg auf eine OpenGL Engine
Da es sich zwar als interessant und lehrreich, jedoch auch mühselig herausgestellt hat das
Spiel ohne Hilfe einer Engine umzusetzen, soll die grafische Darstellung zukünftig mit einer
OpenGL ES 2.0 Engine realisiert werden.
Austausch der Spielerportraits
Die Fotos der Spieler werden zwar erfolgreich gemacht und auch dargestellt, jedoch nur die
von lokalen Spielern. Die Fotos sollen aber auf allen Tablets angezeigt werden, daher muss
man sie übertragen.
Sprachchat
Eine sehr wichtige Funktion um den Sozialfaktor zu steigern stellt die Möglichkeit dar, dass
man mit allen Spielern reden kann, auch mit denen die sich an einem anderen Ort befinden.
Neben diesen für uns sehr wichtigen Features kommt noch das übliche Aufräumen und Optimieren
des bereits vorhandenen Quelltextes.
86
Anhang A
Appendix
A.1
Literatur
[1] Song Ho Ahn. OpenGL Transformation. 2012. url: http://www.songho.ca/opengl/gl_
transform.html.
[2] Open Handset Alliance. [Online; Stand 18. Oktober 2012]. 2012. url: http : / / www .
openhandsetalliance.com/oha_faq.html.
[3] AppMATes. url: http://www.appmatestoys.com/.
[4] Marcus Pant Arno Becker. Android 2 Grundlagen und Programmierung. dpunkt.verlag,
2010.
[5] Julien Mercay Dadvid Phillip Oster. Multi-Touch Screen Recognition of Interactive Objects,
and Application Thereof. 2012. url: http://www.freepatentsonline.com/y2012/0249430.
html.
[6] DICE+. url: http://dicepl.us/.
[7] Annegret Liebers D. Wagner. Grundlagen: Begriffe zu Graphen. Sep. 1998.
[8] ePawn. url: http://www.epawn.fr/.
[9] XMPP Standards Foundation. url: http://xmpp.org/.
[10] Khronos Group. About The Khronos Group. 2012. url: http://www.khronos.org/about.
[11]
[12]
[13]
Google Inc. url: http://developer.android.com/guide/topics/graphics/opengl.html.
Google Inc. 2012. url: http://developer.android.com/.
Google Inc. The AndroidManifest.xml File. 2012. url: http : / / developer . android . com /
[14]
guide/topics/manifest/manifest-intro.html.
ipawn. url: http://jumbo-ipawn.nl/.
[15]
[16]
[17]
Learn OpenGL ES. 2012. url: http://www.learnopengles.com/.
Simple. url: http://simple.sourceforge.net/.
technologeeks. From Linux to Android: Android Internals for Linux Developers. url: http:
//technologeeks.com/Courses/Android-Excerpt.pdf.
87
Bachelorarbeit
Spielfiguren
A.1. LITERATUR
[18]
et al. Uwe Laufs Micha Block. Multi-Touch Technologie, Hard-/Softwareund deren Anwendungsszenarien. Techn. Ber. Fraunhofer-Institut für Arbeitswirtschaft und Organisation
[19]
(IAO), Apr. 2010.
Chris Velazco. Disney’s Appmates Turn The iPad Into An Interactive Playmat. url: http:
[20]
//techcrunch.com/2011/09/27/disneys- appmates- turn- the- ipad- into- an- interactiveplaymat/.
volumique. url: http://volumique.com/v2/?lang=en.
[21]
[22]
Wikipedia. Android (Betriebssystem) — Wikipedia, Die freie Enzyklopädie. [Online; Stand
17. Oktober 2012]. 2012. url: http : / / de . wikipedia . org / w / index . php ? title = Android _
(Betriebssystem)&oldid=109159458.
Wikipedia. Dalvik (software) — Wikipedia, The Free Encyclopedia. [Online; accessed 22October-2012]. 2012. url: http://en.wikipedia.org/w/index.php?title=Dalvik_(software)
[23]
&oldid=518643789.
Wikipedia. Extensible Markup Language — Wikipedia, Die freie Enzyklopädie. [Online;
[24]
Stand 20. Oktober 2012]. 2012. url: http : / / de . wikipedia . org / w / index . php ? title =
Extensible_Markup_Language&oldid=109222777.
Wikipedia. Extensible Messaging and Presence Protocol — Wikipedia, Die freie Enzyklopädie. [Online; Stand 20. Oktober 2012]. 2012. url: http://de.wikipedia.org/w/index.php?
title=Extensible_Messaging_and_Presence_Protocol&oldid=109145282.
[25]
Wikipedia. Go (Spiel) — Wikipedia, Die freie Enzyklopädie. [Online; Stand 20. Oktober
2012]. 2012. url: http : / / de . wikipedia . org / w / index . php ? title = Go _ (Spiel ) &oldid =
107957445.
[26]
Wikipedia. Graph (Graphentheorie) — Wikipedia, Die freie Enzyklopädie. [Online; Stand
20. Oktober 2012]. 2012. url: http : / / de . wikipedia . org / w / index . php ? title = Graph _
[27]
(Graphentheorie)&oldid=109308774.
Wikipedia. Jingle (protocol) — Wikipedia, The Free Encyclopedia. [Online; accessed 20October-2012]. 2012. url: http://en.wikipedia.org/w/index.php?title=Jingle_(protocol)
[28]
&oldid=517746484.
Wikipedia. Mensch ärgere Dich nicht — Wikipedia, Die freie Enzyklopädie. [Online; Stand
[29]
20. Oktober 2012]. 2012. url: http://de.wikipedia.org/w/index.php?title=Mensch_%C3%
A4rgere_Dich_nicht&oldid=108782402.
Wikipedia. OpenGL — Wikipedia, Die freie Enzyklopädie. [Online; Stand 16. Oktober
[30]
2012]. 2012. url: http://de.wikipedia.org/w/index.php?title=OpenGL&oldid=109134238.
Wikipedia. Pachisi — Wikipedia, Die freie Enzyklopädie. [Online; Stand 20. Oktober 2012].
[31]
2012. url: http://de.wikipedia.org/w/index.php?title=Pachisi&oldid=106964297.
Wikipedia. Shader (realtime, logical) — Wikipedia, The Free Encyclopedia. [Online; accessed 16-October-2012]. 2012. url: http://en.wikipedia.org/w/index.php?title=Shader_
(realtime,_logical)&oldid=489443928.
88
Bachelorarbeit
[32]
Spielfiguren
Glossar
Wikipedia. Touchscreen — Wikipedia, Die freie Enzyklopädie. [Online; Stand 20. Oktober
2012]. 2012. url: http : / / de . wikipedia . org / w / index . php ? title = Touchscreen & oldid =
109427759.
A.2
Glossar
Activities
Komponente einer Android App die genau eine bestimmte Aufgabe erledigen soll
S. 22
Android
Betriebssystem und Software-Plattform
S. 1
App
Kurzform von Applikation, üblicherweise für Smartphones oder Tablets
S. 1
Augmented Reality
Erweiterte Realität, computergestützte Erweiterung der Realitätswahrnehmung
S. 4
Dice+
Würfel dessen Wurfergebnis mittels Bluetooth ausgelesen werden kann
S. 7
ePawn
Augmented Reality Technologie für verschiedenartige Spiele
S. 5
Layout
Ein Layout in Android definiert, wie Komponenten in einer Android App angeordnet werden
S. 22
Play Store
Platform auf der man Apps, Musik, Bücher und Filme für Android Geräte kostenlos oder
kostenpflichtig beziehen kann
S. 22
Renderer
Software die aus Objektinformationen eine Visuelle Darstellung berechnet
S. 51
89
Bachelorarbeit
Spielfiguren
A.3. INSTALLATION
Smartphone
Ein Mobiltelefon mit Computer ähnlicher Funktionalität auf das man meist Apps installieren
kann
S. 5
Tablet
Ein Flacher Computer mit Touchscreen
S. 1
Touchscreen
Berührungsempfindlicher Bildschirm
S. 4
XML
eine Sprache zur Darstellung von Daten in einer hirachi- schen Struktur
S. 22
XMPP
Extensible Messaging and Presence Protocol, ein auf XML aufbauendes Protokoll zum
Echtzeit-Streaming
S. 2
A.3 Installation
Jeffrey Wolfe
Abbildung A.1 QR Code
90
Bachelorarbeit
Spielfiguren
Glossar
Um die App zu installieren muss man zunächst in den Einstellungen unter Sicherheit die Installation von unbekannter Herkunft erlauben. Einfach den QR-Code1 einscannen oder auf die Seite
http://goo.gl/bDmXP gehen, runterladen und installieren.
A.4
Arbeitsanteil an ANABEL
Aufgabe
Umsetzung
Planung
Saskia Müller und Jeffrey Wolfe
Kommunikation
Saskia Müller
Verarbeitung von Gesten
Jeffrey Wolfe
Spiel Menus
Saskia Müller
Darstellung Spielansicht
Jeffrey Wolfe
Texturen
Jeffrey Wolfe
Fotos aufnehmen / bearbeiten
Jeffrey Wolfe
Spiel Logik
Saskia Müller und Jeffrey Wolfe
Tabelle A.1
1 Erstellt
Aufgabenverteilung bei der Entwicklung von ANABEL
auf http://goqr.me/de/
91

Entwicklung einer netzwerkfähigen Brettspiele-App für

Transcrição

Documentos relacionados

Januar 2016

April_2016 - Josefbauernfeindsblog

Hello Android - DHBW Stuttgart

Avira Antivirus Pro

pressemitteilung -

Manual tablet samsung android

Leaflet 50PFK6540_12 Released Germany (German) High

Apps-Entwicklung mit Netbeans

Marketinginformation - Box Design by Pro

Der genialste Schutz vor Führerscheinverlust Erkennt alle Laser