Entwicklung eines E-Learning Toolkits für strategische Kartenspiele

Transkript

1 Fakultät II Informatik, Wirtschafts- und Rechtswissenschaften Department für Informatik Diplomarbeit Entwicklung eines E-Learning Toolkits für strategische Kartenspiele Thomas Preschel Erstgutachter: Dr. Hans Fleischhack Zweitgutachterin: Dr. Elke Wilkeit

2 Danksagung Bedanken möchte ich mich bei meiner Familie und bei meinen Freunden, die mich während meiner Diplomarbeit und meines gesamten Studiums unterstützt haben. Mein besonderer Dank gilt Dr. Elke Wilkeit und Dr. Hans Fleischhack, die mir bei der Anfertigung der Arbeit mit Rat und Tat zur Seite standen, und den Teilnehmern der Bridge-Gruppe, die seit eineinhalb Jahren an der Universität Oldenburg besteht.

3 Zusammenfassung Strategische Kartenspiele wie Bridge und Poker sind schwer zu meistern. Wie erfolgreiche Spieler immer wieder zeigen, sind spielerisches Können und die passenden Strategien der Schlüssel zum Bestehen in solchen Spielen. Zum Vermitteln dieser Fähigkeiten wurden Bridge- und Pokerschulen gegründet. Verbreitete Computerprogramme zu Bridge und Poker sind allerdings nicht speziell für das Unterrichten in Gruppen ausgelegt, und die Erstellung von Lehrmaterial, das Spielsituationen realitätsnah darstellt, ist aufgrund der Anzahl darzustellender Elemente schwierig. In dieser Arbeit wird die Entwicklung einer Software-Komponente beschrieben, mit deren Hilfe Lehrmaterialien für das Kartenspiel Bridge und die Pokervariante Texas Hold'Em erstellt werden können. Die Software ist eine Erweiterung für das Programm Microsoft PowerPoint 2007 und ermöglicht es, vorgegebene oder interaktive Spielabläufe in PowerPoint-Präsentationen einzufügen. Es werden aber auch Ansätze vorgestellt, die Software für andere Kartenspiele und Anwendungsbereiche zu erweitern. Für die Entwicklung wurden Methoden des Agility -Ansatzes angewendet, der sich durch eine hohe Flexibilität und kurze Entwicklungszyklen auszeichnet. In einer abschließenden Bewertung werden die Vor- und Nachteile diskutiert, die sich bei der Anwendung des Agility-Vorgehensmodells in diesem Projekt ergeben haben.

4 Inhaltsverzeichnis 1 Einleitung Grundlagen E-Learning Kartenspiele Bridge Das PBN-Dateiformat zur Speicherung von Bridge-Spielabläufen Bridge-Programme Poker Microsoft Office PowerPoint Erstellen von Präsentationen mit PowerPoint Vorführung und Verteilung von Präsentationen Erweiterung von PowerPoint mit eigenen Komponenten OpenOffice.org Impress Die Programmiersprache C# und das.net-konzept Vorgehensmodelle der Software-Entwicklung Familien von Vorgehensmodellen Extreme Programming Der Agility Ansatz Vergleich mit anderen Arbeiten Richard Pavlicek For Bridge Players Bridge Master Patrik Schulz: Ein Tutorensystem für Bridgelehrer Christian Lerch: Bridge Tutor Bridge Baron und GIB Bridge Base Online Articulate E-Learning Studio Zusammenfassung Aufgabenbeschreibung Anwendungsbereich und Benutzerrollen Aufgaben Anzeige von Spielkarten Bridge Poker Anforderungen Anforderungen aus der Sicht der Lernenden Anforderungen aus der Sicht der Lehrperson Technische Anforderungen Erweiterbarkeit... 57

5 5 Lösungsansatz Anwendung des Agility Ansatzes in dieser Arbeit Projektplan Entwicklungsressourcen Programmierrichtlinien Implementierung Zyklus Aufgabenplanung Implementierung Tests Ergebnis Zyklus Diskussion Aufgabenplanung Implementierung Tests Ergebnis Zyklus Diskussion Aufgabenplanung Implementierung Tests Ergebnis Zyklus Diskussion Aufgabenplanung Implementierung Tests Ergebnis Zyklus Diskussion Aufgabenplanung Implementierung Ergebnis Ergebnis Anwendungsbeispiele Evaluation Kriterien aus der Sicht der Lernenden Kriterien aus der Sicht des Lehrenden Sonstige Kriterien Zusammenfassung und Ausblick Bewertung des Ergebnisses Bewertung des Entwicklungsverfahrens Fazit Ausblick... 96

6 Anhang A.1 Quellen A.2 Benutzte Software A.2.1 Einrichtung der Entwicklungsumgebung Visual Studio A.2.2 Einrichtung von PowerPoint 2007 für die Entwicklung A.3 Technische Referenz A.3.1 Projektabhängigkeiten A.3.2 Klassenübersicht A.3.3 VBA-Makros A.3.4 Datendateien A.4 Inhalt der CD A.5 Installationsanleitung

7 Abbildungsverzeichnis Abbildung 2.1: Schematische Darstellung Bridge Abbildung 2.2: Bridge-Boards Abbildung 2.3: Bidding Box Abbildung 2.4: Texas Hold'Em Poker schematisch Abbildung 2.5: Poker Outs Abbildung 2.6: Microsoft PowerPoint SmartArt Beispiel Abbildung 2.7: Office Sicherheitswarnung bei Makros Abbildung 2.8:.NET Namespaces Abbildung 2.9: Backlog beim Scrum-Prozess Abbildung 3.1: Beispiel aus den Übungsaufgaben von Richard Pavlicek Abbildung 3.2: Bridge Master Abbildung 3.3: Bridge Teacher Abbildung 3.4: Bridge Tutor Abbildung 3.5: Bridge Baron Abbildung 3.6: GIB Abbildung 3.7: Bridge Base Online Abbildung 3.8: Articulate Presenter Abbildung 6.1: Klassendiagramm PBN-Komponente Abbildung 6.2: Bridge Abspiel Mock-Up in PowerPoint Abbildung 6.3: Bridge Abspiel Mock-Up in Impress Abbildung 6.4: Bridge Abspiel Vorlage Abbildung 6.5: Bridge-Abspiel Zyklus Abbildung 7.1: Anwendungsbeispiel Kartenverteilung erzeugen Abbildung 7.2: Anwendungsbeispiel unvollständige Reizung einfügen Abbildung 7.3: Anwendungsbeispiel Reizung aufzeichnen Abbildung 7.4: Anwendungsbeispiel feste Reizung Abbildung 7.5: Anwendungsbeispiel Abspiel aufzeichnen Abbildung 7.6: Anwendungsbeispiel fertiges Abspiel einfügen Abbildung 7.7: Anwendungsbeispiel freies Abspiel mit Vorgabe Abbildung 7.8: Anwendungsbeispiel Quiz einfügen Abbildung 7.9: Anwendungsbeispiel Poker Kartenverteilung Abbildung 7.10: Anwendungsbeispiel Poker einfügen Abbildung 7.11: Anwendungsbeispiel Poker Spieltisch Abbildung A.1: Projektabhängigkeiten

8 Tabellenverzeichnis Tabelle 2.1: Bridge-Abrechnung Stichpunkte Tabelle 2.2: Bridge-Abrechnung für erfolgreiche Kontrakte Tabelle 2.3: Bridge-Abrechnung für Überstiche Tabelle 2.4: Bridge-Abrechnung Strafpunkte bei verlorenen Kontrakten Tabelle 2.5: Aufbau einer PBN-Datei Tabelle 2.6: PBN Kodierung Spielkarten Tabelle 2.7: Poker-Kombinationen Tabelle 6.1: Backlog Zyklus Tabelle 6.2: Backlog Zyklus Tabelle 6.3: Backlog Zyklus Tabelle 6.4: Backlog Zyklus Tabelle 6.5: Backlog Zyklus

9 Einleitung 9 1 Einleitung Das Kartenspiel Bridge ähnelt anderen strategischen Kartenspielen in der Hinsicht, dass sich aus dem relativ einfachen Spielmaterial eines Kartenspiels und einem überschaubaren Satz von Grundregeln eine riesige Menge an taktischen Möglichkeiten ergibt. Aus diesem Umstand erklärt sich wohl die große weltweite Beliebtheit von Bridge. Gerade die Tatsache, dass das Spiel schwer zu meistern ist, hat zu dem Wunsch geführt, Bridge mehr als sportlichen Wettkampf und weniger als Glücksspiel zu betreiben. Um diesem Ziel näher zu kommen, wurden zusätzliche Regeln eingeführt, die bei Bridge- Turnieren den Glücksfaktor minimieren sollen. Eine Maßnahme ist, dass unterschiedliche Teams mit derselben Kartenverteilung spielen, damit ihr Spielerfolg vergleichbar ist. Spielerische Schwächen wirken sich auf diese Weise allerdings auch viel deutlicher aus. Wie bei anderen Sportarten wurden Clubs und Schulen für Bridge gegründet, in denen Unterricht für das turniermäßige Spiel gegeben wird. Aus der Motivation heraus, die Erstellung von Lehrmaterial durch ein Computerprogramm zu vereinfachen, ergab sich das Thema dieser Diplomarbeit. In vielen Fällen existiert bereits Lehrmaterial, das mit verbreiteten Programmen wie Microsoft PowerPoint entworfen wurde. Da PowerPoint keine speziellen Funktionen für Bridge enthält, ist dies allerdings aufwändig. Aufgrund der Vielzahl der benötigten Grafikelemente ist es schwer, Spielsituationen nachzustellen, besonders wenn diese interaktiv ablaufen sollen. Wünschenswert wäre es außerdem, gespielte Bridgepartien auf einfache Weise in das Lehrmaterial aufnehmen zu können, um sie mit den Schülern nachträglich zu analysieren. Viele der Anforderungen können einzeln durch bereits verfügbare Programme erfüllt werden, aber nicht insgesamt mit nur einem Programm in Kombination mit PowerPoint. In dieser Arbeit wurde besonderer Wert darauf gelegt, die geforderten Funktionen in einem leicht zu bedienenden Programm zur Verfügung zu stellen und eine ansprechende Präsentation des Lehrmaterials zu ermöglichen. Der Nutzen der Arbeit sollte allerdings nicht auf das Spiel Bridge beschränkt bleiben. Das Programmkonzept wurde so flexibel entwickelt, dass es in Form eines Toolkits auf einfache Weise für andere Themenbereiche erweitert werden kann. Als Name für das Projekt wurde deshalb E-Learning Toolkit oder kurz ETK gewählt. Als zweiter Aufgabenbereich wurde die Poker-Variante Texas Hold Em behandelt. Damit sollte gezeigt werden, wie die entwickelten Konzepte erweitert werden können. Das Spiel ist in den letzten Jahren sehr populär geworden, Poker-Unterricht könnte also auch in kommerzieller Hinsicht interessant werden. Denkbar ist es aber auch, das E-Learning Toolkit für den Informatik-Unterricht einzusetzen, so könnten beispielsweise Algorithmen interaktiv dargestellt werden. Der Zeitraum für die Entwicklung des E-Learning Toolkits sollte etwa vier Monate betragen. Die Anforderungen an das Programm wurden zu Beginn grob definiert und im

10 Einleitung 10 Laufe der Entwicklung in einer Reihe von Interviews anhand von Prototypen und Demonstrationen weiter verfeinert. Es war allerdings noch nicht abzusehen, ob sich alle Anforderungen mit den verfügbaren Programmschnittstellen von Microsoft PowerPoint zufriedenstellend erfüllen lassen. Aus diesem Grund musste bei der Entwicklung äußerst flexibel vorgegangen werden. Für die Umsetzung wurde ein Vorgehensmodell nach dem Agility -Ansatz gewählt. Der Ansatz zeichnet sich durch sehr kurze Entwicklungszyklen aus, deren Ergebnisse jeweils die Grundlage für die Planung der folgenden Zyklen bilden. Microsoft stellt für die Erweiterung von PowerPoint das Paket Visual Studio Tools for Office bereit. Zusammen mit der Entwicklungsumgebung Visual Studio ist es damit möglich, Erweiterungsmodule für PowerPoint zu erstellen. Die verwendbaren Programmiersprachen sind C# und Visual Basic, wobei für diese Arbeit C# gewählt wurde. Die Arbeit ist folgendermaßen aufgebaut: Nach der Einleitung im ersten Kapitel wird im nächsten Kapitel der Begriff E-Learning genauer definiert. Weiterhin werden die Spiele Bridge und Texas Hold Em Poker beschrieben, sowie die Software Microsoft PowerPoint 2007, die durch das E-Learning Toolkit erweitert wird. Schließlich werden die Programmiersprache C# und die Entwicklungsumgebung Visual Studio 2008 vorgestellt und das Agility-Vorgehensmodell erläutert. Das dritte Kapitel gibt einen Überblick über andere Arbeiten und Computerprogramme, die sich mit ähnlichen Problemstellungen zu den Themen E-Learning und Bridge beschäftigen. Im vierten Kapitel werden die Aufgaben konkretisiert, die das Programm erfüllen soll. Die Basis ist dabei ein erstes Interview mit dem Auftraggeber, bei dem der grundlegende Leistungsumfang für die zu entwickelnde Software festgelegt wurde. Das fünfte Kapitel beschreibt den gewählten Lösungsansatz für die Entwicklung und zeigt, wie die Methoden des Agility-Ansatzes für die Strukturierung der Entwicklung eingesetzt wurden. Im sechsten Kapitel werden die Entwicklungszyklen dokumentiert. Jeder Entwicklungszyklus dauerte etwa vier Wochen und wurde durch eine Evaluation des bisherigen Ergebnisses abgeschlossen, welche gleichzeitig die Grundlage für die Aufgaben des nächsten Entwicklungszyklus bildete. Das Ergebnis der Entwicklung wird in Form von Anwendungsbeispielen in Kapitel 7 vorgestellt. Es folgt eine Analyse, welche Forderungen der Aufgabenstellung erfüllt werden konnten. In Kapitel 8 erfolgt eine Bewertung sowohl des Ergebnisses dieser Arbeit, als auch des verwendeten Vorgehensmodells. In einem Ausblick werden Möglichkeiten vorgestellt, wie das E-Learning Toolkit weiter verbessert und für andere Problemstellungen erweitert werden kann.

11 Grundlagen 11 2 Grundlagen Zum Verständnis der Arbeit werden zunächst die grundlegenden Konzepte und Techniken dargestellt. Der Begriff E-Learning wird nur kurz erläutert, da die Erstellung von Lehrmaterial in PowerPoint zwar die Zielsetzung hat, für E-Learning genutzt zu werden, mit PowerPoint alleine aber noch kein E-Learning System aufgebaut werden kann. Mit dem Einsatz einer zusätzlichen Software (einem Lehrmanagementsystem oder LMS ) wird allerdings auch PowerPoint in professionellen E-Learning-Umgebungen eingesetzt (siehe [15]). In diesem Kapitel werden weiterhin die Grundlagen der Kartenspiele Bridge und Texas Hold Em Poker vorgestellt, bei Bridge wird außerdem darauf eingegangen, wie Bridgepartien mit Hilfe des PBN-Dateiformats gespeichert werden können. Es folgt eine einführende Beschreibung der Programme Microsoft PowerPoint 2007 und OpenOffice Impress. Abschließend werden die Programmiersprache C# und die Entwicklungsumgebung Microsoft Visual Studio 2008 vorgestellt, sowie das verwendete Agility -Entwicklungsmodell. 2.1 E-Learning Der Begriff E-Learning umfasst einen weiten Bereich von Möglichkeiten, wie sowohl das Lehren als auch das Lernen mit Hilfe von Informations- und Kommunikationstechnologien verbessert werden können. Zum Einsatz kommen dabei Standardprogramme wie Web- Browser, - und Textverarbeitungsprogramme sowie speziell für E-Learning abgestimmte Software-Werkzeuge. Bei einem traditionellen Unterrichtsmodell mit einer Lehrperson und einer Gruppe von Lernenden steht die Erstellung von Lehrmaterial im Vordergrund. Ein entsprechendes Softwarewerkzeug soll dabei leicht zu bedienen sein und ansprechende Ergebnisse ermöglichen. Ein anderer Anwendungsbereich beim E-Learning ist das selbstständige Lernen allein oder in Gruppen. Durch eine interaktive Gestaltung des Lehrmaterials im Sinne eines entdeckenden Lernens [1] kann das Lernen erheblich abwechslungsreicher und produktiver gestaltet werden. Gerade bei Kartenspielen bietet es sich an, Spielsituationen zu simulieren. Außerdem kann der Lernerfolg mit interaktiven Quizkomponenten abgefragt werden [2]. Ein relativ neues Schlagwort im E-Learning-Bereich ist das Rapid E-Learning. Hierbei sollen Inhalte analog dem Rapid Prototyping in der Softwareentwicklung möglichst schnell und damit kostengünstig erstellt werden. Häufig werden dazu verbreitete Programme zur Erstellung von Präsentationen wie Microsoft PowerPoint aus dem Microsoft Office Programmpaket oder Impress aus dem Open Source-Projekt OpenOffice benutzt [16]. Die Vorteile dieser Programme sind ihr breites Sortiment an

12 Grundlagen 12 Gestaltungsmöglichkeiten und das schnelle Erlernen der Benutzung. Spezielle Funktionen für E-Learning werden in der Grundausstattung aber nicht angeboten. Die in dieser Arbeit entwickelte Komponente erweitert das Programm Microsoft PowerPoint, so dass Spielsituationen aus den behandelten Spielen in Präsentationen eingefügt und mit den vorhandenen Programmfunktionen weiter bearbeitet werden können. 2.2 Kartenspiele Die Kartenspiele Bridge und Poker unterscheiden sich grundlegend in ihrer Spielweise und für beide Spiele ist das Beherrschen unterschiedlicher Fertigkeiten notwendig. Es bestehen aber auch Gemeinsamkeiten, da es sich im Sinne der Spieltheorie in beiden Fällen um Mehrpersonen-Nullsummenspiele mit unvollständiger Information handelt (siehe [17] und [18]). Die Spieler müssen stets die Wahrscheinlichkeiten abwägen, mit denen bestimmte Kartenverteilungen auftreten können, und versuchen, aus den Spielaktionen der Gegner zusätzliche Informationen zu gewinnen. Spielstrategien können nicht in jeder Situation erfolgreich sein, und bei Poker gehört es zu den Grundlagen des Spiels, die Gegenspieler möglichst so zu täuschen, dass sie ungünstige Entscheidungen treffen. Trotzdem haben gute Spieler eine sehr beständige Erfolgsquote, da ihre Spielweise auf lange Sicht häufiger zum Gewinn führt. Das Lernen einer systematischen Spielweise ist also für beide Spiele sehr wichtig Bridge Bridge ist ein Kartenspiel, das mit einem französischen Blatt (52 Karten) gespielt wird. Es spielen zwei Parteien mit jeweils zwei Spielern gegeneinander. Die Spieler sitzen um einen Tisch; ihre Positionen werden in Bridge mit Nord, Ost, Süd und West (N, O, S, W) bezeichnet. Die jeweiligen Partner sitzen sich gegenüber, es spielt also das Paar in den Positionen N und S gegen das Paar in den Positionen O und W. Bei Bridge werden üblicherweise die Spielfarben Herz als Cœur und Kreuz als Treff bezeichnet. Pik und Cœur werden Oberfarben genannt, Karo und Treff sind die Unterfarben [3]. Das Ziel des Spiels ist es, zusammen mit dem eigenen Spielpartner eine vorher ausgehandelte Anzahl von Stichen zu gewinnen oder zu übertreffen. In der ersten Spielphase, der Reizung, geben die Spieler reihum Gebote ab, welche Anzahl von Stichen sie bei Wahl einer bestimmten Trumpffarbe ihrer Meinung nach erreichen können. Die Reizphase dauert an, bis ein Gebot von allen übrigen Spielern durch Passen akzeptiert wird. Dieses Gebot ist dann der sogenannte Kontrakt und bestimmt die Trumpffarbe und die Anzahl Stiche, die erreicht werden muss. Kontrakte ohne Trumpffarbe sind ebenfalls möglich. In der Spielphase werden insgesamt 13 Stiche gespielt. Erreicht das spielende Paar (das den Kontrakt angesagt hat) seine festgelegte Summe, erhält es eine vom Kontrakt abhängige Punktzahl gutgeschrieben. Zusätzliche Stiche bringen Bonuspunkte; wird die Anzahl hingegen nicht erreicht, werden Punkte abgezogen.

13 Grundlagen 13 Ein Spieler des spielenden Paars ist der Alleinspieler. Zum Alleinspieler wird derjenige Spieler bestimmt, der zuerst ein Gebot in der ausgehandelten Trumpffarbe abgegeben hat. Das ist nicht notwendigerweise der Spieler, der das letzte Gebot abgegeben hat. Sein Spielpartner wird als Dummy bezeichnet, da er am Anfang der Abspielphase seine Karten offen auf den Tisch legen muss und die Karten nach Anweisung des Alleinspielers spielen muss. Zum Spielablauf darf der Dummy-Spieler nichts mehr beitragen, auch nicht in Form von Kommentaren. Eine schematische Darstellung des Spieltisches wird in Abbildung 2.1 gezeigt. Abbildung 2.1: Schematische Darstellung Bridge Der Dummy-Spieler ist in Position Nord. Diese als Kontrakt-Bridge bezeichnete Form des Bridge-Spiels wurde um 1925 erstmalig gespielt [4]. In Bridge-Turnieren wird ebenfalls diese Art des Spiels verwendet, allerdings wird dieselbe Kartenverteilung mehrfach an unterschiedlichen Tischen gespielt, um den Glücksfaktor bei der Kartenverteilung zu minimieren. Im englischen Bridge wird deshalb von Duplicate Bridge gesprochen [19]. Es gibt unterschiedliche Formen von Bridge-Turnieren: Beim Paarturnier tritt ein Spielerpaar gegen alle anderen Paare an, während beim Teamturnier aus zwei Paaren bestehende Teams gegeneinander spielen. In jeder Runde eines Team-Turniers spielen beide Paare eines Teams jeweils ein Board gegen die Paare eines anderen Teams. Anschließend werden die Boards getauscht, so dass die Paare beider Teams beide Boards nacheinander spielen. Das eine Paar spielt die Karten in Position NS, das andere Paar die Position OW. So ist sichergestellt, dass alle Teams dieselben Spielsituationen einmal spielen und unterschiedliche Punktsummen allein durch unterschiedliche Spielweisen zustande kommen können. Eine im privaten Rahmen gespielte Bridgevariante ist das Rubberbridge. Das Ziel bei dieser Variante ist, als erstes Paar eine Summe von 100 Punkten (das sogenannte Rubber ) zu erreichen. Die Punktzählung unterscheidet sich allerdings grundlegend von

14 Grundlagen 14 der im Turnierbridge gebräuchlichen Zählweise. Das Spielergebnis beim Rubberbridge ist stark vom Glück abhängig [19]. Spielvorbereitung Zu Beginn des Spiels verteilt der als Teiler bezeichneten Geber die Karten an die Spieler. Der Teiler ist beim ersten Spiel der Spieler in der Position Nord, bei folgenden Spielen geht die Funktion des Teilers an den nächsten Spieler im Uhrzeigersinn weiter. Beim turniermäßigen Spiel werden die Karten nicht vom Teiler gegeben, sie werden stattdessen vor dem Turnier gemischt und in speziellen Behältern, den Boards aufbewahrt (siehe Abbildung 2.2). In jedem Board sind die Karten bereits auf die vier Spieler aufgeteilt und werden nach einem Spiel ebenso wieder verstaut, damit an einem anderen Spieltisch mit derselben Kartenverteilung gespielt werden kann. Abbildung 2.2: Bridge-Boards Aus [19], Klaus Köpplinger Reizung Bei der Reizung geben die Spieler reihum ihre Gebote ab, beginnend mit dem Teiler. Ein abgegebenes Gebot muss höher sein als vorherige Gebote, ansonsten muss der Spieler passen. Gebote enthalten implizit die Ankündigung, dass die Mehrheit der Stiche gewonnen wird. Zu der Gebotshöhe werden 6 Stiche addiert, ein Gebot der Höhe 1 bedeutet also, dass mindestens 7 Stiche gewonnen werden müssen. Das höchste Gebot von 7 verlangt, dass alle 13 Stiche gewonnen werden. Zur Angabe eines Gebots gehört außerdem die Trumpffarbe. Gebote können auch ohne Trumpf angesagt werden (bezeichnet als Sans Atout, abgekürzt als SA ; im Englischen No Trump, abgekürzt als NT ). Bei den Trumpffarben gilt die Rangordnung Treff, Karo, Cœur, Pik, Sans Atout. Das Gebot 1 ist demnach höher als das Gebot 1, wird aber von dem Gebot 1 SA übertroffen, das wiederum niedriger als das Gebot 2 ist. Zur Erleichterung des Bietvorgangs und um das unerlaubte Weitergeben von Informationen zu verhindern wurde die sogenannte Bidding Box eingeführt, die alle möglichen Gebote als Karten enthält. Ein Spieler gibt sein Gebot ab, indem er die entsprechende

15 Grundlagen 15 Karte auf dem Tisch vor sich ablegt. Vorhandene niedrigere Gebotskarten werden mit abgelegt, damit der Spieler die nächste Gebotskarte greifen kann, für die Reizung sind diese aber ohne Bedeutung (siehe Abbildung 2.3). Frühere Gebote müssen stets sichtbar auf dem Tisch bleiben, so dass jeder Spieler zu jeder Zeit die komplette Reizung nachvollziehen kann. Abbildung 2.3: Bidding Box Aus [19] Wird beim Bieten eine mögliche Stufe übersprungen (ein Spieler reizt z. B. 3, obwohl er noch 2 reizen könnte), muss der bietende Spieler auf diesen Umstand hinweisen. Die Reizung wird dann kurz unterbrochen, um sicherzustellen, dass jeder Spieler dies zur Kenntnis genommen hat. Bidding Boxen enthalten für diesen Fall eine Stop-Karte, die zusammen mit dem Gebot auf den Tisch gelegt wird. Als spezielle Karte enthält die Bidding Box weiterhin eine Karte Alert. Wenn ein Spieler ein Gebot abgibt, das aus einer speziellen Absprache resultiert, muss der Partner des Spielers durch die Alert-Karte anzeigen, dass dieses Gebot eine besondere Bedeutung besitzt. Solche Gebote werden als künstliche oder konventionelle Gebote bezeichnet, da der Spieler nicht unbedingt beabsichtigt, die gebotene Trumpffarbe zu spielen. Der Partner ist in diesem Fall oft gezwungen, ein weiteres Gebot abzugeben. Bei Bridge-Turnieren können die Gegenspieler verlangen, dass die Bedeutung eines künstlichen Gebots erklärt wird. Gebote, die außer der Spielabsicht keine besonderen, auf Absprache beruhenden Informationen enthalten, werden dagegen als natürliche Gebote bezeichnet. Im Laufe der Evolution des Bridgespiels wurde die Strategie beim Bieten immer weiter verfeinert, so dass auch natürliche Gebote eine gewisse konventionelle Bedeutung haben, während die verbreitete Stayman -Konvention (siehe [3]) nicht mehr als alertierpflichtig gilt, ebenso Gebote über der Spielstufe 3 SA. Die Idee des Alertierens wurde also zugunsten eines flüssigen Spielablaufs abgewandelt. Wenn nach Abgabe eines Gebots die übrigen Spieler passen, wird das Gebot der Kontrakt des Spiels und die spielende Partei wird durch den Spieler, der das Gebot abgegeben hat, und seinen Spielpartner gebildet. Dieser Spieler wird aber nicht zwangsläufig zum Alleinspieler, das ist immer der Spieler, der zuerst ein Gebot in der zu spielenden

16 Grundlagen 16 Trumpffarbe abgegeben hat. Gewinnt ein Spieler beispielsweise die Reizung mit einem Gebot von 4, so wird trotzdem sein Partner der Alleinspieler, wenn dieser im Verlauf der Reizung als Erster ein Pik-Gebot abgegeben hat. Bei der Reizung streben die Spielpartner an, einen Fit zu finden, also eine Spielfarbe, in der sie gemeinsam mindestens 8 Karten und damit eine robuste Mehrheit besitzen. Im einfachsten Fall wird ein Fit dadurch gefunden, dass ein Spieler eine Farbe reizt und sein Partner dieselbe Farbe auf der nächsten Gewinnstufe reizt. Natürlich macht es nur dann Sinn zu reizen, wenn die Blätter der beiden Spieler auch einigermaßen spielstark sind, ansonsten muss gepasst werden. Wenn zwei Spieler keinen Fit finden können, einigen sie sich meistens auf ein Spiel in Sans Atout, da sie durch die Abgabe von Geboten Spielstärke angezeigt haben und das Fehlen eines Fits die Wahrscheinlichkeit erhöht, zumindest in allen Farben einige Karten zu halten. Höhere Kontrakte werden bei Gewinn eines Spiels auch durch höhere Punktwertungen belohnt, für die Spieler ist es also sinnvoll, den höchstmöglichen Kontrakt auszuhandeln, auch wenn die Gegenspieler bereits die Reizung aufgegeben haben und nur noch passen. Das beste mögliche Gebot hängt natürlich von den Karten beider Spieler eines Paars ab, trotzdem dürfen sie außerhalb des Bietens keinerlei Informationen austauschen. Durch die Abgabe von Geboten treiben die Spieler nicht nur ihr eigenes Spiel voran, sie verhindern auch, dass die Gegner möglicherweise ein sehr gutes Spiel zusammen aushandeln. Es kann manchmal strategisch sinnvoll sein, ein nicht zu gewinnendes Spiel auszureizen, weil die in dem Fall erhaltenen Minuspunkte immer noch günstiger sind als die Punkte, die den Gegnern im Falle eines Gewinns angerechnet werden. Ein solches Gebot wird Sperrgebot genannt, wenn die Reizung der Gegner dadurch erschwert werden soll, oder Opfergebot, wenn es tatsächlich gespielt werden soll [3]. Gegen diese Praxis kann sich ein Paar bis zu einem gewissen Grad durch Abgabe eines Kontra -Gebots wehren. Dabei wird das zuletzt abgegebene Gebot kontriert, und falls dieser Kontrakt gespielt und verloren wird, werden die angerechneten Minuspunkte erhöht. Dieses Kontra wird als Strafkontra bezeichnet, und alleine schon die Möglichkeit, ein Gebot zu kontrieren, verringert die Zahl der Situationen, in denen ein hoffnungsloses Spiel gereizt wird um einen Gewinn der Gegenpartei zu verhindern. Wird das Spiel im Kontra trotzdem gewonnen, fällt die Belohnung allerdings auch höher aus, außerdem kann ein Paar auf ein Kontra des Gegners mit einem Rekontra -Gebot antworten, durch das die gewonnene oder verlorene Punktsumme weiter erhöht wird. Kontra sollte also nicht in jeder Situation gereizt werden, sondern nur wenn davon ausgegangen wird, dass der Gegner auch tatsächlich mit hoher Wahrscheinlichkeit verliert. Das Gebot des eigenen Spielpartners darf nicht kontriert werden. Ein Kontra gilt immer nur für das zuletzt abgegebene Gebot. Wird ein neues reguläres Gebot gereizt, verlieren Kontra und Rekontra ihre Wirkung. Spätere Gebote können aber wieder kontriert werden. Bidding-Boxen enthalten deshalb mehrere Kontra-Karten, die mit einem roten X gekennzeichnet sind. Für Rekontra-Gebote sind Karten mit blauem XX vorhanden.

17 Grundlagen 17 Das Kontra-Gebot kann dafür genutzt werden, dem Spielpartner eine Information zukommen zu lassen, weil davon ausgegangen wird, dass noch weitere reguläre Gebote gereizt werden und das Kontra keine Auswirkung für die Punkteabrechnung haben wird. Dieses Kontra wird als Informationskontra bezeichnet und deutet normalerweise auf Spielbereitschaft in den nicht gereizten Farben hin sowie auf die Spielstärke des eigenen Blatts, die sonst für die Abgabe eines Eröffnungsgebots gereicht hätte. Sofern der Gegner nicht noch reizt, sollte der Partner auf ein Informationskontra unbedingt noch ein Gebot abgeben, auch wenn sein Blatt sehr schwach ist, damit der Partner noch einmal reizen kann. Abspiel Nachdem der Alleinspieler und der zu spielende Kontrakt feststehen, beginnt der linke Gegenspieler des Alleinspielers mit dem Abspiel. Sobald dieser eine Karte ausgespielt hat, legt der Dummy-Spieler seine Karten nach Spielfarben sortiert auf den Tisch (siehe Abbildung 2.1). Die Trumpffarbe wird immer ganz links aufgereiht, die anderen Farben folgen nach Wertigkeit. Zur besseren Übersichtlichkeit können Karo und Treff vertauscht werden. Der Dummy-Spieler darf in das folgende Spiel nicht mehr eingreifen, er führt nur noch die Anweisungen des Alleinspielers aus. Bei Bridge herrscht Bedienpflicht. Nur wenn ein Spieler die geforderte Farbe nicht mehr hat, kann er eine andere Farbe spielen. Mit einer Trumpfkarte kann er stechen oder schnappen, ansonsten bleibt ihm nichts weiter übrig, als eine Karte einer anderen Farbe abzuwerfen. Die höchste Karte in der ursprünglich geforderten Farbe gewinnt den Stich, oder falls Trümpfe gespielt wurden, gewinnt der höchste Trumpf. Der Spieler, der die gewinnende Karte gespielt hat, spielt danach zum nächsten Stich aus. Sobald die Karten des Dummy-Spielers auf dem Tisch liegen, kann der Alleinspieler alle Karten seiner Partei sehen und sich einen Plan für das Spiel überlegen. Neben ziemlich sicheren Karten in Sequenzen von Ass an abwärts (den sogenannten Topstichen ) können noch auf andere Weise Stiche entwickelt werden. In langen Farben können auch niedrige Karten Längenstiche machen, wenn die Gegner ihre hohen Karten in dieser Farbe aufgebraucht haben. In dem Fall sollte allerdings verhindert werden, dass die Gegenspieler mit Trumpf schnappen können. Eine gängige Strategie ist deshalb die Trümpfe zu ziehen, also Trumpfkarten auszuspielen, damit die Gegner mit Trumpf bedienen müssen. Oft ist während einer Bridgepartie der Ausgang des Spiels schon klar, bevor alle Stiche gespielt wurden. In diesem Fall ist es üblich, dass der Alleinspieler einen Claim ankündigt. Dabei gibt er an, wie viele der verbleibenden Stiche er noch gewinnen wird und zeigt den Gegenspielern seine Karten. Wenn die Gegenspieler den Claim nicht akzeptieren, können sie verlangen, dass der Alleinspieler seine beabsichtigte Spielweise erklärt oder dass die Partie zu Ende gespielt wird. In den meisten Fällen ist das Ergebnis nach dem Aufdecken der Karten aber eindeutig.

18 Grundlagen 18 Punktwertungen Für die Punktwertungen von Bridge-Spielen muss die Gefahrenlage berücksichtigt werden. Nach einem festgelegten Muster wird vor jedem Spiel bestimmt, ob sich Spielerpaare in Gefahr befinden, wodurch sich die Punktwertung für gewonnene und verlorene Spiele ändert. Es bestehen vier Möglichkeiten: keiner ist in Gefahr, Paar NS in Gefahr, Paar OW in Gefahr, alle in Gefahr. Bridge-Boards sind durchnummeriert, und eine Beschriftung der Spielerpositionen auf rotem Hintergrund weist darauf hin, dass sich das entsprechende Paar in Gefahr befindet. Jedes Spiel wird mit einer gewissen Punktzahl bewertet. Grundsätzlich erhält ein Paar bei einem gewonnenen Kontrakt für jeden im Kontrakt angesagten Stich nach dem sechsten eine bestimmte Punktzahl. Stiche in Unterfarben (Treff, Karo) zählen 20 Punkte pro Stich, in Oberfarbe 30 Punkte pro Stich und in Sans Atout 40 Punkte für den ersten Stich und 30 Punkte für alle weiteren Stiche. Die Punktzahl wird bei Kontra verdoppelt und bei Rekontra vervierfacht (siehe Tabelle 2.1). Stichpunkte Nicht kontriert Kontriert Rekontriert Unterfarben (, ) Oberfarben (, ) Sans Atout (7. Stich) Sans Atout (weitere Stiche) Tabelle 2.1: Bridge-Abrechnung Stichpunkte Aus [3] Zu den Stichpunkten wird je nach Höhe des Kontrakts eine bestimmte Prämie addiert. Kontrakte ab 100 Stichpunkten gelten als Vollspiele (ab 3 SA, 4 in Oberfarbe oder 5 in Unterfarbe). Die Vollspielprämie beträgt 300 Punkte nicht in Gefahr und 500 Punkte in Gefahr. Kontrakte unterhalb dieser Grenzen zählen als Teilkontrakte und bringen unabhängig von der Gefahrenlage nur 50 zusätzliche Punkte. Ab der 6. Spielstufe wird ein Kontrakt als Kleinschlemm (englisch Small Slam ) bezeichnet und bringt noch einmal 500 oder 750 Punkte je nach Gefahrenlage. Für den Großschlemm (englisch Grand Slam ) auf Spielstufe 7 (alle Stiche) beträgt die Prämie 1000 oder 1500 Punkte [3].

19 Grundlagen 19 Für gewonnene Kontrakte ergibt sich die folgende Punkteberechnung (Tabelle 2.2): Nicht kontriert Nicht in Gefahr Spielstufe SA Nicht in Gefahr Spielstufe SA Nicht in Gefahr Spielstufe SA Teilkontrakt Vollspiel Kleinschlemm Großschlemm Kontriert Teilkontrakt Vollspiel Kleinschlemm Großschlemm Rekontriert Teilkontrakt Vollspiel Kleinschlemm Großschlemm In Gefahr Spielstufe SA In Gefahr Spielstufe SA In Gefahr Spielstufe SA Tabelle 2.2: Bridge-Abrechnung für erfolgreiche Kontrakte

20 Grundlagen 20 Gewonnene Kontrakte im Kontra werden mit Zusatzpunkten berechnet. Es werden nicht nur höhere Stichpunkte gewährt (siehe Tabelle 2.1), sondern auch eine Zusatzprämie von 50 Punkten. Außerdem gilt durch die höhere Stichpunktsumme bereits ein Spiel ab Spielstufe 2 in Sans Atout oder Oberfarbe und ab Spielstufe 3 in Unterfarbe als Vollspiel. Für gewonnene Kontrakte im Rekontra beträgt die Zusatzprämie 100 Punkte und als Vollspiele gelten alle Spiele mit Ausnahme von Spielen der Spielstufe 1 in Unterfarbe. Die höheren Prämien werden nur gewährt, wenn der Kontrakt auf der entsprechenden Stufe angesagt wurde, es reicht also nicht, einen niedrigen Kontrakt anzusagen und dann eine höhere Zahl von Stichen zu gewinnen. Werden mehr Stiche gemacht als vom Kontrakt gefordert werden (die sogenannten Überstiche ), zählen diese wie die Stichpunkte. Einen Unterschied gibt es aber bei Spielen in Kontra oder Rekontra. Wird ein Spiel im Kontra gewonnen, zählen Überstiche je 100 Punkte nicht in Gefahr und 200 Punkte in Gefahr. Im Rekontra werden diese Werte nochmals verdoppelt (Tabelle 2.3). Stichpunkte für Überstiche Nicht kontriert Kontriert Rekontriert Nicht in Gefahr In Gefahr Nicht in Gefahr In Gefahr Unterfarben (, ) Oberfarben (, ), Sans Atout Tabelle 2.3: Bridge-Abrechnung für Überstiche Aus [19] Bei verlorenen Spielen erhalten die Gegenspieler eine Prämie abhängig von der Zahl der Stiche ( Faller ), die der Alleinspieler zu wenig gemacht hat (Tabelle 2.4). Faller Nicht in Gefahr In Gefahr Nicht kontriert Kontriert Rekontriert Nicht kontriert Kontriert Rekontriert Ein Faller Zwei Faller Drei Faller Für jeden weiteren Faller Tabelle 2.4: Bridge-Abrechnung Strafpunkte bei verlorenen Kontrakten Aus [3]

21 Grundlagen 21 Bietsysteme Offensichtlich ist das Finden des besten Kontrakts von großer Bedeutung für erfolgreiches Bridgespiel. In seiner ursprünglichen Form unterliegt das Reizen bei Bridge nur wenigen Einschränkungen, allerdings haben sich manche Strategien als so nützlich erwiesen, dass sie praktisch zum Grundregelwerk des Spiels gezählt werden können [4]. Zu große Abweichungen von diesen allgemein anerkannten Prinzipien könnten zudem den eigenen Spielpartner mehr verwirren als den Gegner. Beim sportlich betriebenen Bridge soll das spielerische Können ausschlaggebend sein und nicht die Fähigkeit, die gegnerischen Spieler durch Bluffen zu überlisten. Eine Maßnahme ist deshalb, eine Reihe von Konventionen bei der Reizung, zusammengefasst als Bietsystem bezeichnet, als bindende Grundlage für Bridge-Turniere festzulegen. In Deutschland wird das System Forum-D oft angewendet [20], eine große weltweite Verbreitung hat auch das amerikanische System Standard American Yellow Card [21]. Etwaige Abweichungen vom Bietsystem oder zusätzliche Absprachen sind zwar nicht ausgeschlossen, müssen den Mitspielern aber mitgeteilt werden, so dass alle Spieler aus den Geboten die gleichen Informationen erhalten. Bewertung von Blättern Von zentraler Bedeutung für die Frage, ob auf einer bestimmten Spielstufe gereizt werden soll, ist die Spielstärke des eigenen Blatts. Spielstärke ergibt sich hauptsächlich durch das Vorhandensein von hohen Kartenwerten. Eine ungleichmäßige Verteilung der Spielfarben kann die Spielstärke weiter steigern. Lange Farben eignen sich gut als Trumpffarben oder um Längenstiche zu entwickeln. Bei kurzen Farben besteht eventuell die Möglichkeit, diese abzuwerfen und anschließend mit Trumpf zu schnappen. Für eine schnelle Möglichkeit, die Spielstärke eines Blatts abzuschätzen, wurde das folgende System entwickelt, das die Grundlage nahezu aller Bridge-Bietsysteme bildet [22]. Zunächst werden die Figurenpunkte aufsummiert nach dem Schlüssel Ass = 4, König = 3, Dame = 2, Bube = 1 Insgesamt sind 40 Figurenpunkte im Spiel. Die meisten Gebote bei der Reizung setzen eine bestimmte Mindeststärke voraus, oft gibt es auch eine Obergrenze. Aus den abgegebenen Geboten können so schon sehr genaue Vorstellungen darüber gewonnen werden, wie die Karten verteilt sind. Am Anfang der Reizung wissen die Spieler noch nichts über die Blätter ihrer Spielpartner. Lange Farben sind von Vorteil, da sie eventuell als Trumpffarben benutzt werden können. Kurze Farben sind zunächst nicht so aussagekräftig, da noch nicht bekannt ist, wie der Partner in dieser Farbe ausgestattet ist. Daher werden am Anfang der Reizung sogenannte Längenpunkte zur Summe der Figurenpunkte addiert. Jede Karte ab der 5. Karte einer Farbe zählt einen Längenpunkt. Längenpunkte werden nur für Farben gezählt, die auch mindestens 3 Figurenpunkte aufweisen.

22 Grundlagen 22 Im folgenden Beispiel ist die Summe der Figuren- und Längenpunkte 14 (ein Längenpunkt in Treff): A 8 B 9 5 D 10 8 K D B 7 5 Hier ist die Summe der Figuren- und Längenpunkte 8 (keine Längenpunkte): B B 5 D 10 8 A 7 Um bei einer Reizung ein Eröffnungsgebot abgeben zu können, sollte ein Blatt mindestens 12 Figurenpunkte (abgekürzt 12F) oder 13 Figuren- und Längenpunkte (abgekürzt 13FL) haben. Sobald zwei Spieler eine gemeinsame Trumpffarbe in einem Fit gefunden haben, werden weitere Merkmale in Form von Verteilungspunkten in die Bewertung einbezogen. Kurze Farben mit zwei Karten ( Doubleton ), einer Karte ( Singleton ) oder gänzlich fehlende Farben ( Chicane ) bringen jeweils 1, 2 oder 3 Verteilungspunkte. Eine vorhandene neunte Trumpfkarte bringt zwei Punkte, weitere Trümpfe jeweils einen Punkt [20]. Die Summe der Figuren- und Verteilungspunkte (abgekürzt FV) kann also noch mehr Spielstärke anzeigen. Dies ist in der Hinsicht wichtig, dass die kombinierte Spielstärke zusammen mit dem Partner das wichtigste Entscheidungskriterium ist, ob ein höherwertiges Vollspiel oder gar ein Schlemm versucht werden sollte Das PBN-Dateiformat zur Speicherung von Bridge-Spielabläufen Für Bridge wurden viele Computerprogramme entwickelt, unter Anderem zur Erzeugung von Kartenverteilungen, zum Spielen der Reiz- und Abspielphase am Computer, zur Analyse von Spielen und zur Abrechnung von Bridgeturnieren. Zunächst waren diese Programme nicht untereinander kompatibel, Programmausgaben eines Programms konnten nicht in andere Programme geladen werden. Einige Bridge-Spieler und Autoren von Bridge-Software diskutierten in der Newsgroup rec.games.bridge Möglichkeiten, wie ihre Programme untereinander Daten austauschen könnten. Unter der Koordination von Tis Veugen in Zusammenarbeit mit Kaj G. Backas wurde 1998 die Portable Bridge Notation für die Speicherung von Bridge-Spielen in Computerdateien vorgeschlagen. Grundlage der Definition waren die Anforderungen und Lösungsvorschläge der Mitglieder der Newsgroup. Aktuell wird die Version 2.1 des Standards verwendet [24]. PBN basiert auf dem Portable Game Notation -Format, das zur Speicherung von Schachspielen entwickelt wurde. Das Format sollte für Menschen verständlich und von

23 Grundlagen 23 Hand erstellbar sein, aber auch leicht in Computerprogrammen zu implementieren sein. Weiterhin sollte PBN ein offener Standard sein, der frei von jedem benutzbar ist und bei Bedarf für weitere Aufgabenstellungen erweitert werden kann. Die Spieldaten werden mit dem Zeichensatz ISO 8859/1 codiert, wodurch auch eine Reihe von Umlauten zulässig ist. Spieltechnische Begriffe müssen aber auf Englisch geschrieben werden (z. B. NT für Sans Atout, oder Both um anzuzeigen, dass alle Spieler in Gefahr sind). In der PBN-Spezifikation werden Abfolgen von Zeichen ( Tokens ) definiert, mit denen Informationen innerhalb einer PBN-Datei dargestellt werden sollen. Das wichtigste Konstrukt ist das sogenannte Tag Pair, das eine beliebige Zeichenfolge einem bestimmten Bezeichner (dem Tag ) zuordnet. Ein Tag Pair hat die Form [Bezeichner Zeichenfolge ] Jede Zeile der PBN-Datei kann höchstens ein Tag Pair enthalten. Weiterhin können Kommentare auf zwei verschiedene Weisen eingefügt werden. Mit einem vorangestellten Semikolon gilt die restliche Zeile als Kommentar. Mehrzeilige Kommentare müssen in geschweiften Klammern { } eingefasst sein. Eine spezielle Bedeutung haben Zeilen, die mit einer Raute # beginnen. Diese enthalten technische Informationen zu der PBN-Datei (z. B. die benutzte PBN-Version) und sind nicht einem bestimmten Spiel innerhalb der Datei zugeordnet. Alle übrigen Zeichenfolgen haben eine unterschiedliche Bedeutung, je nachdem an welcher Stelle der Datei sie vorkommen. Eine PBN-Datei kann eine beliebige Anzahl einzelner Spiele enthalten, die jeweils durch eine Leerzeile voneinander getrennt werden. Die Daten für ein Spiel werden logisch in Abschnitte ( Sections ) unterteilt (Tabelle 2.5): Identification Section Auction Section Play Section (optional) Supplemental Section Leerzeile [ ] weitere Spiele Tabelle 2.5: Aufbau einer PBN-Datei PBN-Dateien können in zwei Formen vorliegen. Das sogenannte Import-Format erlaubt einige Freiheiten bezüglich der Zeilenenden, zusätzlicher Leerzeichen und bei einigen Tags und ermöglicht es beispielsweise, PBN-Dateien manuell mit einem Texteditor zu erstellen. Im Export-Format gelten striktere Regeln, damit die Dateien auf unterschiedlichen Plattformen kompatibel sind. Zeilen müssen dann zwingend mit der in Windows gebräuchlichen CRLF-Zeichenfolge abgeschlossen werden.

24 Grundlagen 24 Identification Section Der Abschnitt identification section enthält alle wichtigen Daten eines Spiels, die in Form von Tag Pairs angegeben werden. Die PBN-Spezifikation verlangt das Vorhandensein einiger obligatorischer Tags: den Spielort, die Boardnummer, die Namen der Spieler und das Datum des Spiels. Weiterhin sind alle spieltechnischen Daten vorgeschrieben: Die Position des Teilers, die Gefahrenlage, die Kartenverteilung, die Art der Punkteabrechnung, die Position des Alleinspielers ( Declarer ), der Kontrakt und das Spielergebnis. Andere Informationen sind optional (z. B. wird bei Turnieren oft der Spielraum angegeben, wenn in unterschiedlichen Räumen gespielt wurde). Das folgende Beispiel aus [24] zeigt alle notwendigen Tags: [Event "International Amsterdam Airport Schiphol Bridgetournament"] [Site "Amsterdam, The Netherlands NLD"] [Date " "] [Board "1"] [West "Podgor"] [North "Westra"] [East "Kalish"] [South "Leufkens"] [Dealer "N"] [Vulnerable "None"] [Deal "N:.63.AKQ987.A9732 A8654.KQ5.T.QJT6 J973.J K4 KQT2.AT.J "] [Scoring "IMP"] [Declarer "S"] [Contract "5HX"] [Result "9"] { S H 6 3 D A K Q C A S K Q 10 2 S A H A 10 H K Q 5 D J D 10 C 8 5 C Q J 10 6 S J H J D 3 C K 4 } Die Kartenverteilung ist im Kommentar ergänzend dargestellt, für Bridge-Programme ist aber nur der Inhalt des Deal-Tags ausschlaggebend. Dort werden die Karten der Spieler durch ein Leerzeichen voneinander getrennt, Spielfarben durch einen Punkt (in der Reihenfolge Pik-Cœur-Karo-Treff). Karten werden immer durch ein einzelnes Zeichen dargestellt, dabei gilt die im unteren Teil von Tabelle 2.6 angegebene Zuordnung.

25 Grundlagen 25 Treff Clubs Karo Diamonds Cœur Hearts Pik Spades C D H S Bube Jack Dame Queen König King 2 9 T J Q K A Ass Ace Tabelle 2.6: PBN Kodierung Spielkarten In Spezialfällen können auch unvollständige Kartenverteilungen in PBN-Dateien gespeichert werden. Dabei müssen allen Spielern zumindest dieselbe Anzahl Karten zugewiesen sein. Mit unvollständig gegebenen Händen kann eine spezielle Spielsituation dargestellt werden, für die nur einige Karten benötigt werden. Um die Erstellung von PBN-Dateien zu vereinfachen, können für die Tags zwei Abkürzungen benutzt werden, sofern die Datei mehrere Spiele beschreibt. Anstelle einer Zeichenfolge kann einem Tag das Symbol # zugewiesen werden. In dem Fall wird der Wert des vorherigen Spiels übernommen. Wenn also in der Beispieldatei weitere Spiele hinzugefügt werden, wird mit dem Tag Pair [Event "#"] die im ersten Spiel angegebene Zeichenfolge International Amsterdam Schiphol Bridgetournament übernommen. Eine weitergehende Vereinfachung bei der Angabe von Tags ist die Zuweisung von Standardwerten. Mit der Zeile [Event "##International Amsterdam Airport Schiphol Bridgetournament"] wird dieser Wert als Standardwert für das Event-Tag gespeichert und muss bei den folgenden Spielen nicht mehr angegeben werden. Auction Section Dieser Abschnitt beginnt stets mit dem Auction-Tag. Das Auction-Tag legt den Spieler fest, der die folgende Reiztabelle anführt. Im Normalfall ist dies der Teiler, der auch im Dealer-Tag angegeben wurde. Als Besonderheit lässt das PBN-Format jedoch zu, dass die Reiztabelle mit einem anderen Spieler beginnt (z. B. immer Nord). Da die Reizung erst mit dem Teiler beginnt, muss für die vorangehenden Spieler ein Minus in die Reiztabelle eingefügt werden. Bei PBN-Dateien im Export-Format ist dieser Spezialfall allerdings nicht erlaubt.

26 Grundlagen 26 Das folgende Beispiel zeigt eine Reizung, bei der Spieler Nord regulär beginnt: [Auction "N"] 1D 1S 3H =1= 4S 4NT =2= X Pass Pass 5C X 5H X Pass Pass Pass [Note "1:non-forcing 6-9 points, 6-card"] [Note "2:two colors: clubs and diamonds"] Die Gebote bei der Reizung werden durch die Gebotshöhe und die Spielfarbe angegeben: C = Clubs (Treff), D = Diamonds (Karo), H = Hearts (Cœur), S = Spades (Pik), NT = No Trump (Sans Atout). Weitere mögliche Gebote sind Pass, X für Kontra und XX für Rekontra. Wenn die Reizung mit AP = All Pass beginnt, haben alle vier Spieler gepasst. In diesem Beispiel sind zwei Gebote mit Anmerkungen in der Form =n= versehen, wobei n eine fortlaufende Zahl ist. Erklärungstexte zu den Anmerkungen sind nach der Reiztabelle in Form von Note-Tags angegeben. Einige häufig gebrauchte Anmerkungen können über spezielle Symbole den Geboten zugeordnet werden. Mit dem Symbol! kann beispielsweise auf ein gutes Gebot hingewiesen werden, mit?? auf ein sehr schlechtes Gebot. Bei diesen Suffix genannten Symbolen kann in der PBN-Datei kein Erklärungstext angegeben werden. Eine ähnliche Funktion haben die Numeric Annotation Glyphs oder NAGs. Diese werden in der Form $n angegeben, wobei n eine Zahl ist, die einer bestimmten Bedeutung entspricht. Suffix-Symbole können auch durch entsprechende NAGs ausgedrückt werden, so kann z. B. das Symbol! für ein gutes Gebot durch $1 ersetzt werden. Irregularities Während der Reizung kann bei menschlichen Spielern gelegentlich ein Fehler passieren. Wenn ein regelwidriges Gebot abgegeben wurde, können die Gegenspieler verlangen, dass das Gebot zurückgenommen wird, sie können es aber auch akzeptieren. Auf diesen Umstand wird in PBN-Dateien mit den sogenannten Irregularities hingewiesen. Das Symbol ^I wird einem ungenügenden Gebot vorangestellt. Wird ein Spieler bei der Reizung übergangen, wird in der Reiztabelle anstelle des Gebots das Symbol ^S benutzt. Ein weiterer Fehler, der am Ende der Reizphase passieren kann, ist dass der falsche Spieler ausspielt und anschließend der Spieler als Dummy seine Karten auf den Tisch legt, der eigentlich der Alleinspieler wäre. Dieser Fehler wird in PBN-Dateien dadurch vermerkt, dass im Declarer-Tag an der Position des tatsächlichen Alleinspieler das Zeichen ^ vorangestellt wird. Wenn eine unvollendete Reizung in einer PBN-Datei gespeichert werden soll, kann mit dem Symbol + in der Reiztabelle der Punkt markiert werden, an dem die Reizung fortgesetzt werden muss. Dieser Mechanismus kann hilfreich sein, wenn PBN als Austauschformat für Bridge-Programme benutzt wird.

27 Grundlagen 27 Play Section Der Abschnitt für das Abspiel beginnt mit dem Play-Tag und ist ähnlich dem vorangehenden Abschnitt zur Reizung aufgebaut. Der im Play-Tag angegebene Spieler ist der Spieler, der zum ersten Stich ausgespielt hat, also der vom Alleinspieler aus gesehen linke Gegenspieler. Auch hier ist es möglich, einen abweichenden Spieler anzugeben, sofern die Datei nicht im Export-Format gespeichert wird. Nicht gespielte Karten werden dann mit einem Minus gekennzeichnet. Die Reihenfolge der Spieler wird über den gesamten Abschnitt beibehalten, auch wenn der Ausspieler bei jedem Stich wechseln kann. Im folgenden Beispiel beginnt also jede Zeile mit dem Spieler in Position West: [Play "W"] SK =1= H3 S4 S3 C5 C2 C6 CK S2 H6 S5 S7 C8 CA CT C4 D2 DA DT D3 D4 DK H5 H H2 * [Note "1:highest of series"] Karten werden durch zwei Zeichen dargestellt (siehe Tabelle 2.6). Spielt ein Spieler keine Karte aus, wird dies durch ein Minus dargestellt. Im angegebenen Beispiel wurde das Spiel im 7. Stich beendet (Claim), nachdem der Spieler in Position Süd die Karte 2 ausgespielt hat. Das vorzeitige Beenden des Spiels wird durch das Zeichen * ausgedrückt. Soll das Spiel hingegen an dieser Stelle später fortgesetzt werden, wird das Zeichen + eingesetzt. Wie bei der Reizung können Anmerkungen, Suffix-Symbole und NAGs benutzt werden. Für das Abspiel gelten andere Werte für NAGs als bei der Reizung. Ein gutes Ausspiel wird beispielsweise durch $7 angedeutet. Beim Abspiel können zwei Irregularities auftreten. Wird einer Karte das Symbol ^L vorangestellt, wurde diese Karte außerhalb der eigentlichen Reihenfolge gespielt. Eine falsch ausgespielte Karte (Verletzung der Bedienpflicht), die nicht zurückgenommen wurde, wird mit einem vorangehenden ^R gekennzeichnet. Supplemental Section Dieser optionale Abschnitt enthält alle Tags, die auf den Abschnitt Play Section folgen, bis zur nächsten Leerzeile (die ein neues Spiel anzeigt) oder bis zum Ende der Datei. Dieser Abschnitt kann zusätzliche Informationen enthalten, z. B. zum Punktestand eines Turniers.

28 Grundlagen Bridge-Programme Viele Bridgepartien und ganze Turniere werden mittlerweile archiviert und im Internet zum Download zur Verfügung gestellt. Dabei werden alle für die jeweiligen Spiele relevanten Informationen inklusive Kartenverteilungen, Biethistorien und genauem Ablauf des Abspiels aufgezeichnet. Häufig werden diese Daten im PBN-Format gespeichert. Auf seiner PBN-Homepage [23] pflegt Tis Veugen unter dem Punkt PBN Software eine umfangreiche Liste von Programmen, mit denen sich PBN-Dateien anzeigen, überprüfen und bearbeiten lassen. Eine Aufgabe ist dabei die Erzeugung von zufälligen Kartenverteilungen ( Deals ), die als PBN-Dateien gespeichert werden. Bridge stellt aufgrund seiner Komplexität allerdings besondere Anforderungen an Deal-Programme. Das Programm Big Deal, das Hans van Staveren auf seiner Homepage [25] zum Download anbietet, soll besonders gut geeignet sein, zufällige Kartenverteilungen zu erzeugen. Wie van Staveren in der Dokumentation [26] ausführt, ist die Benutzung gebräuchlicher Algorithmen zur Generierung von Pseudo-Zufallszahlen nicht ausreichend für Bridge, da diese meistens nur eine Auflösung von 32 Bit aufweisen. Die Zahl der möglichen Kartenverteilungen bei Bridge beträgt allerdings ca. 0,7 x Da die Algorithmen außerdem nur pseudo-zufällige Zahlen erzeugen, können sich erkennbare Muster schon nach viel weniger Durchläufen wiederholen. Big Deal nutzt aus kryptographischen Anwendungen bekannte Methoden, um Zufallszahlen mit einer Auflösung von 160 Bit zu generieren und damit bessere Kartenverteilungen zu erzeugen. Double-Dummy-Analyse Eine weitere nützliche Anwendung für Bridge-Programme ist die sogenannte Double- Dummy-Analyse. Bei diesem Verfahren wird bei einer vollständig bekannten Kartenverteilung (also unter der Annahme, der Alleinspieler kann die Karten von zwei weiteren Spielern sehen, daher der Begriff Double Dummy ) errechnet, welche Kontrakte maximal erfüllt werden können, wenn alle Spieler optimal spielen. Damit kann die Spielleistung von Computerprogrammen oder auch menschlichen Spielern beurteilt werden, wobei diese allerdings die Karten ihrer Gegenspieler nicht kennen. Eines der ersten Projekte zur Entwicklung eines Computer-Bridgespielers wurde von Matthew L. Ginsberg an der Universität von Oregon gestartet [27]. Die Entwicklung eines Double-Dummy-Solvers führte zur Entwicklung des Programms GIB oder Ginsberg's Intelligent Bridgeplayer, das mittlerweile als kommerzielles Produkt erhältlich ist und als spielstärkstes Computerbridgeprogramm der Welt beworben wird [28]. Das Programm wird auch als single dummy Bridgeprogramm bezeichnet, da es regulär, ohne Kenntnis der gegnerischen Karten spielt. Ginsberg hebt in [27] hervor, dass GIB 1998 bei den World Bridge Championships in Lille in einem Teilnehmerfeld mit 34 Weltklassespielern den 12. Platz gemacht hat, um zu verdeutlichen, welche Spielstärke das Programm zu der Zeit bereits besaß. Das originale Programm zur Double-Dummy-Analyse, das Ginsberg an der Universität von Oregon entwickelt hatte, ist nach René Steiner [29] noch frei erhältlich. Steiner hat das Programm gibtrix entwickelt (siehe Anhang A.2), das mit Hilfe von gib eine Double- Dummy-Analyse von Bridgeverteilungen ermöglicht, die in einer PBN-Datei gespeichert sind.

29 Grundlagen Poker Poker ist ein Wettspiel, das in Runden abläuft, und mit 52 Karten gespielt wird. In jeder Runde bekommen alle Spieler eine gewisse Anzahl Karten verdeckt ausgeteilt und geben anschließend in der Wettphase Gebote in Form von Chips ab (der Spielwährung). Die Chips werden von den Reserven der Spieler in die Tischmitte (den Pot ) gelegt. Es ist möglich, jederzeit in einer Runde zu passen, schon gesetzte Gebote gehen dadurch allerdings verloren. Diejenigen Spieler, die mit dem Höchstbietenden mitgegangen sind, vergleichen anschließend ihre Karten. Die höchste Kombination gewinnt den Pot. Es gibt eine große Zahl von Pokervarianten. Diese unterschieden sich darin, wie die Karten verteilt werden, welche Anzahl von Wettrunden durchgeführt wird und welche Mindest- und Höchstgrenzen für die Gebote gelten. Fast allen Pokervarianten ist die Bewertung von Kartenkombinationen gemein, die sich nach der Wahrscheinlichkeit für das Auftreten der jeweiligen Kombinationen richtet (siehe Tabelle 2.7). Name Bedeutung Beispiel Entscheidungskriterium Höchste Karte Keine der unteren A Höhe der einzelnen Karten (High Card) Kombinationen K J 7 4 Ein Paar (One Pair) Zwei Karten gleichen Wertes J 8 6 Höhe des Paars und der Beikarten Zwei Paare (Two Pair) Zwei Paare J J 8 8 A Höhe der Paare und der Beikarte Drilling (Three Of A Kind) Drei Karten gleichen Wertes Q Q Q A 4 Höhe des Drillings und der Beikarten Straße Fünf Karten in einer J Höchste Karte (Straight) Reihe Flush Fünf Karten in einer K Höhe der einzelnen Karten Farbe Full House Ein Drilling und ein Paar K K K 9 9 Höhe des Drillings und Höhe des Paars Vierling (Four Of A Kind) Vier Karten gleichen Wertes A A A A 4 Höhe des Vierlings und der Beikarte Straight Flush Straße in einer Farbe J Q Höchste Karte Royal Flush Straße in einer Farbe mit Ass als höchster Karte 10 J Q K A Split Pot Tabelle 2.7: Poker-Kombinationen Aus [30] Ein Pokerblatt besteht aus fünf Karten. Seltenere Kombinationen wie eine Straße (fünf in den Kartenwerten aufeinanderfolgende Karten) schlagen häufigere Kombinationen wie ein Paar (zwei gleiche Kartenwerte bei drei beliebigen anderen Karten mit unterschiedlichen Werten). Bei gleichen Kombinationen entscheidet der höhere Kartenwert der zu der Kombination gehörenden Karten, welches Blatt gewinnt. Sind diese Karten gleichwertig, entscheiden die restlichen Karten (die Beikarten ). Haben alle Karten den gleichen

30 Grundlagen 30 Kartenwert, werden die Chips gleichmäßig auf die Spieler aufgeteilt ( Split Pot ). Innerhalb der Kartenfarben gibt es bezüglich der Kombination keine Rangordnung. Texas Hold Em Eine der populärsten Pokervarianten ist Texas Hold Em. Bei dieser Variante erhält jeder Spieler nur zwei Karten verdeckt ausgeteilt. Im Laufe einer Spielrunde werden vom Kartengeber bis zu fünf weitere Karten offen in der Tischmitte aufgedeckt (siehe Abbildung 2.4), sofern kein Spieler die Runde schon vorzeitig gewinnen konnte. Die Spieler wählen aus ihren beiden Handkarten und den fünf offenen Karten die Kombination aus fünf Karten, die den höchsten Spielwert hat. Weil die offenen Karten von allen Spielern genutzt werden können, werden sie Gemeinschaftskarten oder Community Cards genannt [5]. Ein Teil der Popularität von Texas Hold Em ist sicherlich in der Tatsache begründet, dass die Gemeinschaftskarten in jeder Runde andere Bedingungen schaffen, und somit kombinatorisches Denken und Spielstrategie eine große Bedeutung für eine erfolgreiche Spielweise haben. Weil den Spielern außerdem sieben Karten zur Verfügung stehen, kommen höherwertige Kombinationen vergleichsweise häufig vor, und die Spieler müssen im Laufe einer Spielrunde ihre Karten immer wieder neu bewerten und gegen die Gewinnchancen der Mitspieler abwägen. Abbildung 2.4: Texas Hold'Em Poker schematisch Die Chipreserven der Spieler müssen sichtbar vor ihnen abgelegt werden ( Stack ). Eine Spielrunde bei Texas Hold Em läuft über maximal vier Wettrunden. Die erste Wettrunde beginnt, nachdem alle Spieler ihre beiden Handkarten vom Geber erhalten haben. Die Funktion des Gebers wird in jeder Spielrunde im Uhrzeigersinn weitergegeben. Falls die Karten nicht von einem Spieler sondern von einem speziellen Kartengeber verteilt werden,

31 Grundlagen 31 hat trotzdem ein Spieler die Rolle des Gebers inne und erhält eine Spielmarke (den Dealer Button ) um dies anzuzeigen. Normalerweise muss in einer Wettrunde der Spieler links vom Geber das erste Gebot abgeben oder passen ( fold ). Eine Ausnahme gibt es in der ersten Wettrunde: die beiden auf den Geber folgenden Spieler sind gezwungen, Einsätze in den Pot zu zahlen. Die Einsätze werden Blinds genannt, da die Spieler diese unabhängig von ihren Karten setzen müssen. Der erste Spieler muss einen vor Beginn des Spiels abgesprochenen Betrag ( Small Blind ) setzen und der zweite Spieler muss auf den Betrag des Big Blind verdoppeln (z. B. 4 Chips/8 Chips). Die folgenden Spieler können die Wette halten ( call ), indem sie den geforderten Betrag an Chips in den Pot legen oder entsprechend viele Chips nachlegen, falls sie bereits gewettet haben. Ist der gesetzte Betrag eines Spielers bereits so hoch wie die aktuelle Wette, kann er einfach mitgehen, ohne Chips nachzulegen ( check ). Um die Wette zu erhöhen ( raise ) muss mindestens der Betrag des Big Blinds dazugelegt werden. Je nach Spielform können auch Obergrenzen für das Erhöhen gelten (z. B. fixe Limits, Pot Limit). Im Spiel ohne Limit hingegen können Spieler ihren gesamten Stack wetten ( All In ). Zum All In ist ein Spieler außerdem gezwungen, wenn er einen geforderten Blind nicht mehr aufbringen kann oder nicht mehr genug Chips zum Mitgehen hat, aber die Wette nicht aufgeben will. In diesem Fall wird ein sogenannter Side Pot aufgemacht, in den die Spieler einzahlen, die über die Wette des Spielers hinausgehen, der all in ist. Auf die Chips im Side Pot haben nur noch die Spieler Anspruch, die eingezahlt haben. Gibt es nur noch einen Spieler, der nicht aus der Runde ausgeschieden ist, gewinnt er automatisch den Pot, ohne seine Karten zeigen zu müssen. Ansonsten wird eine Wettrunde beendet, wenn die Wette eines Spielers nicht mehr von anderen Spielern weiter erhöht wird (bei Limit-Spielen kann allerdings auch die maximal mögliche Anzahl von Erhöhungen beschränkt sein, siehe [5]). Im Anschluss an die erste Wettrunde deckt der Kartengeber die ersten drei Gemeinschaftskarten auf (den Flop ) und die zweite Wettrunde wird durchgeführt. Es folgen noch zwei Wettrunden, in denen jeweils eine weitere Karte aufgedeckt wird ( Turn und River ). Sofern noch mehrere Spieler an der Wette beteiligt sind, werden ihre Karten im Showdown verglichen. Texas Hold Em wird im Allgemeinen auf zwei verschiedene Weisen gespielt. Beim Turnierspiel beginnen alle Spieler mit einer bestimmten Menge an Chips. Ist der Chipvorrat eines Spielers aufgebraucht, scheidet er aus. Üblicherweise werden beim Turnierspiel die Blinds im Laufe des Spiels nach einem festgelegten Schlüssel regelmäßig erhöht (beispielsweise alle 15 Minuten), da durch das Ausscheiden von Spielern die Chipreserven der verbleibenden Spieler immer mehr ansteigen. Im Cash-Game hingegen können Spieler jederzeit zu einer Runde hinzukommen oder den Tisch verlassen. Außerdem ist es möglich, Chips nachzukaufen. Blinderhöhungen finden bei dieser Spielart nicht statt [5]. Odds und Outs Die Grundlage für die Entscheidung, bei einer Texas Hold Em-Wette mitzugehen, zu erhöhen oder zu passen, ist die Wahrscheinlichkeit, im Laufe der Runde eine gewinnende Kartenkombination zu erhalten. Hat ein Spieler beispielsweise zwei Herz-Karten und im

32 Grundlagen 32 Flop werden zwei weitere Herz-Karten aufgedeckt, spricht man von einem Flush Draw. Wird aufgrund des Wettverlaufs angenommen, dass ein Gegenspieler eine gute Kombination mit Ass-Paar oder zwei anderen Paaren hat, ist zum Gewinnen ein besseres Blatt nötig (Abbildung 2.5). Angenommen, die vierte Gemeinschaftskarte ist kein Herz, wie hoch ist die Chance, noch einen Flush (5 Karten gleicher Farbe) zu vervollständigen? Hand Flop Turn River? Abbildung 2.5: Poker Outs Das Pokerspiel hat 52 Karten, davon sind 13 Herzkarten. Unter den 6 bereits bekannten Karten sind 4 Herzkarten, es sind also 9 weitere Herzkarten (die Outs ) unter den verbleibenden 46 Karten, das entspricht einer Chance ( Odds ) von etwa 19,5 % [5]. Natürlich bedeutet das noch nicht, dass ein Spieler in so einem Fall unbedingt aus der Wette aussteigen sollte, durch aggressives Erhöhen könnte der Gegner möglicherweise noch zum Aufgeben gebracht werden. Falls es aber zum Showdown kommt, stehen die Chancen relativ schlecht. Wäre der Flop günstiger ausgefallen, hätte sich möglicherweise eine bessere Gewinnchance ergeben. Mit einer Herz-Neun anstelle einer Herz-Zehn bestünde die Chance, mit einer Sieben eine Straße zu vervollständigen ( ). Zu den 9 Outs kämen also weitere 4 für die Siebenen, was eine Gewinnchance von insgesamt etwa 28 % bedeuten würde. Pot-Odds Ein weiteres wichtiges Kriterium beim Pokern ist das Verhältnis der Chips, die zum Mitgehen in den Pot gelegt werden müssen, zum Wert der Chips im Pot. Beträgt die aktuelle Wette 10 Chips und im Pot liegen 30 Chips von drei anderen Spielern, betragen die Pot- Odds 10:40 oder 25 %. Liegt die Gewinnwahrscheinlichkeit des eigenen Blatts bei mindestens 25 % ist der Break-Even-Point erreicht, ab dem sich Gewinne und Verluste die Waage halten. Durch Erhöhen der Wette können außerdem die Pot-Odds für die Gegenspieler verändert werden, wodurch diese möglicherweise aus der Runde aussteigen [5]. 2.3 Microsoft Office PowerPoint 2007 Microsoft PowerPoint dient zur Erstellung von Präsentationen, etwa des Begleitmaterials für einen Vortrag. Die Präsentationen sind in Form von Seiten organisiert, die entsprechend des Vorbilds der Präsentation mit einem Overhead-Projektor als Folien bezeichnet werden. Folien können Texte oder andere Elemente enthalten, die erst nach und nach angezeigt werden. Um die Folien ansprechender zu gestalten, ist es möglich, Animationen zu verwenden. So können beispielsweise Textzeilen vom Bildrand her eingeschoben werden oder Grafiken bewegt werden.

33 Grundlagen 33 In der Version 2007 von PowerPoint wurde eine neue Benutzungsoberfläche eingeführt, die die vorherigen Menüelemente und Toolbars in einer neuen Multifunktionsleiste ( Ribbon ) zusammenführt. Ebenfalls neu ist die Unterstützung von XML-Dateiformaten. Während das in PowerPoint bis Version 2003 benutzte Dateiformat ppt ein binäres, proprietäres Dateiformat ist, kann in PowerPoint 2007 im XML-basierten Format Office Open XML mit der Dateiendung pptx gespeichert werden. Mit diesem Format ist es zumindest theoretisch für andere Softwarehersteller möglich, PowerPoint-Dateien in eigenen Anwendungen zu unterstützen Erstellen von Präsentationen mit PowerPoint PowerPoint ist darauf zugeschnitten, in kürzester Zeit Informationen visuell darzustellen. Sehr hilfreich ist dabei die große Sammlung von vorgefertigten Elementen, die zur Verfügung gestellt werden. Diese reichen von einfachen Symbolen bis zu den sogenannten SmartArt -Diagrammen, die vom Anwender mit entsprechenden Texten gefüllt werden können (siehe Abbildung 2.6). Abbildung 2.6: Microsoft PowerPoint SmartArt Beispiel Alle Elemente auf einer Folie werden logisch als Shapes verwaltet. Ein Shape steht für ein Textelement, eine Grafik oder ein Symbol, und enthält Daten über die Position und die Größe des Shapes sowie mögliche Formatierungsoptionen. SmartArt-Diagramme werden als Gruppierungen von Shapes verwaltet. Die optischen Effekte einer Folie werden als Animationen bezeichnet. Dabei muss es sich nicht unbedingt um eine Bewegung handeln, auch das Einblenden einer Textzeile wird als Animation behandelt. Weitere Möglichkeiten sind das Ausblenden von Shapes, Bewegung, Größenänderung und Änderung der Formatierung (z. B. Textgröße, Hintergrundfarbe). Animationen werden für jede Folie in einer Zeitlinie verwaltet. Dabei kann für die einzelnen Animationen festgelegt werden, ob sie gleichzeitig mit anderen Animationen oder nacheinander ausgeführt werden sollen, und ob sie durch Mausklick oder nach einer bestimmten Zeit automatisch ausgelöst werden (der sogenannte Trigger [6]).

34 Grundlagen 34 Neben der Hauptzeitlinie können weitere Zeitlinien festgelegt werden, die durch das Klicken auf ein bestimmtes Shape gestartet werden. So ist es bereits möglich, eine einfache Form der Interaktivität zu erzeugen, beispielsweise das Anzeigen eines Erklärungstextes, wenn auf einen bestimmten Begriff geklickt wird. Der Vortragende einer Präsentation (oder der Betrachter an einem Computer) kann so die Abfolge des Geschehens bestimmen und wahlweise Teile davon überspringen. Eine Sonderstellung in Präsentationen nehmen die sogenannten Makros ein. Ursprünglich als Erleichterung für die Bedienung von PowerPoint gedacht, wurden mit jeder Version von PowerPoint die Verwendungsmöglichkeiten für Makros erweitert. Zur Ausführung eines Makros kann eine Tastenkombination zugewiesen werden, z. B. um das aktuelle Datum in die gerade bearbeitete Folie einzufügen. Makros können aber auch als Mausklickereignis für einzelne Shapes festgelegt werden, wodurch sie während der Vorführung von Präsentationen eingesetzt werden können [6] Vorführung und Verteilung von Präsentationen Im Allgemeinen werden PowerPoint-Präsentationen mit PowerPoint selber über die Funktion Bildschirmpräsentation angezeigt. Wenn Präsentationen an Benutzer verteilt werden sollen, denen Microsoft Office nicht zur Verfügung steht, kann der PowerPoint Viewer von Microsoft zur Anzeige benutzt werden. Diese Software wird von Microsoft kostenlos zur Verfügung gestellt. Der PowerPoint Viewer kann Präsentationen anzeigen, aber nicht ändern. Wenn Lehrmaterialien für E-Learning verteilt werden sollen, ist es also möglich, die PowerPoint-Dateien zum Download zur Verfügung zu stellen und für die Anzeige auf den PowerPoint Viewer zu verweisen. Eine wesentliche Einschränkung des PowerPoint- Viewers ist jedoch, dass keine Makros ausgeführt werden können [6]. Mit PowerPoint ist es außerdem möglich, selbstablaufende CDs zu erstellen, mit denen Präsentationen angezeigt werden können. Die CDs enthalten eine spezielle Version des PowerPoint-Viewers, die direkt von der CD lauffähig ist. Für diese Version gilt ebenfalls, dass keine Makros ausgeführt werden können. Eine weitere Möglichkeit zur Verteilung des Materials ist die Umwandlung in ein anderes Dateiformat. PowerPoint selber bietet das Umwandeln in HTML an. Wie in [15] weiter ausgeführt wird, ist die Darstellungsqualität nur bei der Betrachtung im Microsoft Internet Explorer zufriedenstellend, dazu ist allerdings die Installation einer Browsererweiterung notwendig. Außerdem können Makros nicht ausgeführt werden und einige Animationen werden nicht unterstützt [7]. Von Microsoft wird eine Programmkomponente zum Download angeboten, mit der PowerPoint-Präsentationen als PDF-Dateien gespeichert werden können [6]. In diesem Format können aber Animationen, Multimedia-Elemente und Makros nicht verwendet werden. Für die Wiedergabe im Internet bietet sich außerdem das Flash-Format an, für das die meisten Benutzer den benötigten Flash-Player im Browser installiert haben. Zur Erstellung von Flash-Inhalten aus PowerPoint-Präsentationen ist allerdings weitere Software notwendig (siehe Kapitel 3.7 und [6]).

35 Grundlagen Erweiterung von PowerPoint mit eigenen Komponenten In Kapitel wurde bereits die Verwendung von Makros angesprochen. Makros werden als VBA-Programmtext ( Visual Basic for Applications ) in Präsentationen gespeichert und bei Aufruf durch PowerPoint interpretiert. Makros haben nicht nur Zugriff auf alle Programmfunktionen von PowerPoint, sondern prinzipiell auf alle Systemfunktionen von Windows. Zwar hat ein Autor einer Präsentation damit fast unbegrenzte Möglichkeiten, diese mit Programmfunktionen auszustatten, das Potential für Missbrauch ist damit allerdings ebenso unbegrenzt. Die Unwissenheit vieler Computerbenutzer, dass Office-Dokumente genauso gefährlich wie Exe-Dateien sind, hat zu einer großen Verbreitung von Makro-Viren geführt [31]. In Office 2007 werden Makros nur auf Nachfrage ausgeführt. Sinnvollerweise ist die Nachfrage nicht ein Dialog, den viele Benutzer aus Gewohnheit einfach wegklicken würden, sondern eine Schaltfläche, die beim Laden der Datei angezeigt wird (siehe Abbildung 2.7). Wenn der Benutzer den Hinweis ignoriert, wird die Ausführung von Makros verhindert. Weiterhin muss bei der Verwendung des in Office 2007 eingeführten XML-Speicherformats die Dateiendung pptm verwendet werden, wenn eine Präsentation Makros enthält. Benutzer sollen daran sofort erkennen, ob eine PowerPoint-Datei potenziell gefährlichen Code enthält. Abbildung 2.7: Office Sicherheitswarnung bei Makros Die Programmierung von VBA-Code ist direkt in PowerPoint möglich, eine separate Entwicklungsumgebung muss nicht installiert sein. Die in Office integrierte Entwicklungsumgebung hat allerdings nur einen begrenzten Funktionsumfang. Der Zugriff auf die Entwicklerfunktionen muss in den PowerPoint-Optionen unter dem Punkt Entwicklerregisterkarte in der Multifunktionsleiste anzeigen freigegeben werden (siehe Anhang A.2.2). Mit der Einführung der.net-technologie (siehe Kapitel 2.4) verfolgte Microsoft das Ziel, verschiedene Programmiersprachen zu vereinheitlichen und zu modernisieren. Insbesondere VBA-Programmcode entsprach nicht mehr diesen Anforderungen. Deshalb wurde beginnend mit Office 2003 ein neues Erweiterungsmodell Visual Studio Tools for Office geschaffen, das die Entwicklung von Office-Erweiterungen auf der Grundlage von.net ermöglicht. Wie der Name schon andeutet, wird dazu die Entwicklungsumgebung Microsoft Visual Studio benötigt. Auf dieser Grundlage erschaffene Erweiterungsprogramme für Office werden von Microsoft Office Business Applications genannt [12]. Einfache Erweiterungen, die bestimmte Funktionen zu Office-Programmen hinzufügen und in etwa den VBA-Makros entsprechen, werden meistens als Add-Ins bezeichnet.

36 Grundlagen OpenOffice.org Impress 3.0 Das Projekt OpenOffice.org ist ein freies Bürosoftwarepaket, das unter anderem für Textverarbeitung, Tabellenkalkulation, Präsentationen und das Erstellen von Diagrammen genutzt werden kann [32]. Der Funktionsumfang und die Bedienung orientieren sich stark an der Microsoft Office Suite und sollen eine freie und quelloffene Alternative dazu darstellen. Das OpenOffice-Programm Writer entspricht Microsoft Word und Impress entspricht Microsoft PowerPoint. Mit OpenOffice können die Dateiformate von Microsoft Office (doc, ppt, ) geöffnet und bearbeitet werden, seit Version 3.0 auch die neuen Office Open XML Formate (docx, pptx, ). OpenOffice.org favorisiert aber das Format Open Document Format (ODF). Obwohl die Entwicklergemeinde von OpenOffice.org daran arbeitet, den Funktionsumfang der Microsoft-Programme möglichst komplett abzubilden, werden einige Features nicht unterstützt oder unterscheiden sich deutlich in der Darstellung [33]. Die in Microsoft Office verwendete Makrosprache VBA kann in OpenOffice nicht ausgeführt werden. Die dort verwendete Sprache StarBasic ist VBA zwar sehr ähnlich, da VBA aber stark an die interne Arbeitsweise der Microsoft Office Programme angebunden ist, können VBA- Makros nicht einfach übersetzt werden. Auf diese Weise wird aber auch die Gefahr reduziert, dass schadhafter Code in Dokumenten Systemausfälle und Datenverluste verursacht. 2.4 Die Programmiersprache C# und das.net-konzept Dem Wandel der Computertechnik vom allgegenwärtigen Windows-PC zur vernetzten Internet-Welt wurden viele Microsoft-Technologien wie Win32-API, OLE und COM nicht mehr gerecht. Um mit der vorhandenen Windows-Basis kompatibel zu bleiben, mussten auch viele Einschränkungen und Designschwächen übernommen werden [11]. Der Erfolg von Suns Java-Plattform zeigte, wie eine moderne Lösung für eine heterogene, vernetzte Welt aussehen könnte. Der Versuch von Microsoft, Java und Windows in Form der Programmiersprache J++ zu verbinden, scheiterte am Widerstand von Sun [36]. Microsoft übernahm einige Konzepte von Java und schuf damit die eigene Plattform.NET. Aus der Java Virtual Machine wurde bei Microsoft die Common Language Runtime, wobei schon angedeutet wird, dass verschiedene Programmiersprachen eingesetzt werden können. Neben Visual Basic.NET, das für die große Gemeinde der Visual Basic-Programmierer weiterentwickelt wurde, schuf Microsoft eine neue Sprache C#, die zwar C++-Programmierer ansprechen sollte, ansonsten aber Java viel näher steht als C++. Ursprünglich wurde noch ein J++- Nachfolger J# unterstützt, der in Visual Studio 2008 aber fallengelassen wurde. Sowohl Java als auch.net unterstützen Entwickler durch eine umfangreiche Klassenbibliothek, die für viele Standardaufgaben Lösungen enthält. Insbesondere die Erstellung grafischer Oberflächen wird durch vorgefertigte Elemente erleichtert. Während die Java Klassenbibliothek aber prinzipiell plattformunabhängig ist, stützt sich.net weitgehend auf die Funktionen des Windows-Betriebssystems. Eine Portierung von.net-programmen für andere Plattformen ist also schwieriger. Aus diesem Grund wurde das Open Source

37 Grundlagen 37 Projekt Mono [37] als plattformunabhängige Alternative entwickelt, um.net-programme in anderen Betriebssystemen auszuführen. Zur Ausführung von.net-programmen ist genau wie bei Java eine installierte Runtime-Komponente nötig, die das.net Framework enthält. Die derzeit aktuelle (und in dieser Arbeit benutzte) Version ist 3.5. Die Entwicklungsumgebung Microsoft Visual Studio 2008 Visual Studio ist eine integrierte Entwicklungsumgebung (Integrated Development Environment, IDE) für die Programmiersprachen C++, C# und Visual Basic. Außerdem wird die Entwicklung von SQL-Datenbankprojekten und von Webprojekten unterstützt. Für die Entwicklung von Microsoft Office Add-Ins sind zwei Komponenten von Visual Studio besonders wichtig. Die mitgelieferte Produktdokumentation MSDN Library enthält neben der Beschreibung der Entwicklungsumgebung und der unterstützten Programmiersprachen eine Referenz für das gesamte.net Framework und weitere APIs, darunter auch die für die Erstellung von Microsoft Office Add-Ins wichtigen Schnittstellen der Office-Programme. In Visual Studio 2008 ist im Gegensatz zur Vorgängerversion Visual Studio 2005 bereits das Software Development Kit Microsoft Visual Studio Tools for Office 3.0 integriert, das für die Entwicklung von Office-Erweiterungen benötigt wird (siehe Kapitel 2.3.3). In dieser Version ist es möglich, Steuerelemente für die Multifunktionsleiste von Office-Anwendungsprogrammen (siehe Kapitel 2.3) mit Hilfe eines grafischen Editors zu entwerfen. Ein Softwareprojekt in Visual Studio kann aus mehreren Unterprojekten bestehen, die in einer Projektmappe zusammengefasst sind. Unterprojekte können in unterschiedlichen Programmiersprachen verfasst sein und erzeugen jeweils eine eigene Projektausgabe, meistens eine Funktionsbibliothek (Dynamic Link Library oder DLL) oder eine ausführbare Exe-Datei, falls in dem Projekt ein Startpunkt festgelegt wurde. Die erzeugten Dateien sind allerdings nur lauffähig, wenn das passende.net Framework installiert ist. Innerhalb der Projekte ist der Programmcode in Klassen organisiert. Klassen wiederum werden in der Namespace-Hierarchie gegliedert, im Normalfall ist das auch die Verzeichnisstruktur innerhalb eines Projekts. Im folgenden Ausschnitt der Projektmappe ETK (siehe Abbildung 2.8) befindet sich die Klasse Strings im Namespace Bridge und kann über Bridge.Strings referenziert werden. Die Klasse Images ist im Namespace Bridge.PBNTree und wird über Bridge.PBNTree.Images referenziert. Projektmappe ETK C#-Projekt Bridge Strings.cs Unterverzeichnis PBNTree Images.cs Abbildung 2.8:.NET Namespaces

38 Grundlagen 38 Projekte können untereinander über Verweise verknüpft werden. Wenn aus einem anderen Projekt heraus ein Verweis auf das Bridge-Projekt vorhanden ist, kann ebenfalls über Bridge.Strings auf die entsprechende Klasse zugegriffen werden. Über Projektgrenzen sind aber nur Klassen und Member sichtbar, die den Zugriffsmodifizierer public haben. Projektverweise können nur streng hierarchisch verwendet werden, Ringverweise sind nicht zulässig. Visual Studio erstellt automatisch Kompilierungsregeln, so dass abhängige Projekte stets kompiliert werden, wenn auf sie direkt oder indirekt verwiesen wird. Visual Studio erzeugt für neue Projekte die Buildkonfigurationen Debug und Release, die sich in den Kompilierungsoptionen unterscheiden. Weitere Buildkonfigurationen können vom Benutzer angelegt werden. Standardmäßig werden die Projektausgaben je nach Konfiguration in den Unterverzeichnissen bin/debug und bin/release erzeugt. Einzelne Klassendateien wie in Java werden nicht erstellt. In der Dateiansicht von Visual Studio können weitere Datendateien in den Quellverzeichnissen angezeigt werden (dazu müssen sie aber manuell zum Projekt hinzugefügt werden). Diese können als Inhaltsdateien festgelegt werden, wodurch sie beim Kompilieren in das Ausgabeverzeichnis kopiert werden. Wichtig ist dies auch bei der Erstellung eines Setup-Programms, das die Inhaltsdateien in die Installationsdatei übernehmen kann. Für Anwendungsprogramme müssen häufig Konfigurationseinstellungen gespeichert werden. In Windows geschieht dies üblicherweise über Einträge in der Registry. Visual Studio unterstützt diese Aufgabe durch die Möglichkeit Settings für ein Projekt festzulegen, für die automatisch eine passende Zugriffsklasse erstellt wird. Die Datenfelder dieser Klasse können einfach als normale Datenfelder angesehen werden, die ihren Inhalt zwischen den Programmausführungen erhalten. Von der eigentlichen Technik, mit der diese Daten gespeichert werden, kann so abstrahiert werden (sie werden nicht in der Registry gespeichert, sondern in einem bestimmten Systemordner im Benutzerverzeichnis). In Visual Studio kann für Softwareprojekte ein Installationsprogramm auf Basis der Windows Installer-Technologie erstellt werden. Das Installationsprogramm kann so konfiguriert werden, dass notwendige Softwarekomponenten (etwa das.net Framework) zusammen mit dem eigentlichen Anwendungsprogramm installiert werden. Es ist möglich, auf diese Weise eine Office-Anpassung zu verteilen, die sich sehr einfach installieren lässt [12]. Als Teil der C#-Sprachspezifikation [38] hat Microsoft eine XML-basierte Syntax für die Programmdokumentation eingeführt. Damit ist es möglich, beim Kompilieren eines Programms eine XML-Datei zu erstellen, aus der die Dokumentation zu der erstellten Software von Visual Studio oder andere Programmen ausgelesen werden kann. Der Quelltexteditor von Visual Studio kann dann beispielsweise die Kommentare zu Methodenparametern anzeigen, wenn eine Klasse aus der mit XML-Kommentaren versehenen Programmbibliothek benutzt wird. Mit geeigneten Programmen kann aus der XML-Dokumentation außerdem eine Programmdokumentation im HTML- oder CHM-Format (Windows Help File) generiert werden [39].

39 Grundlagen Vorgehensmodelle der Software-Entwicklung Mit steigender Speicherkapazität und Leistungsfähigkeit von Computern konnten zwar immer komplexere Problemstellungen behandelt werden, allerdings erreichten die Softwareprojekte sehr schnell einen Umfang, der ohne Strukturierung nicht mehr bewältigt werden konnte. Eine ingenieursmäßige Vorgehensweise mit einer Zerlegung des Entwicklungsprozesses in besser handhabbare Teilschritte war notwendig. Ein Problem bei der Entwicklung war das hohe Ausmaß der Abhängigkeit zwischen verschiedenen Programmteilen. Die Einführung von weniger maschinennahen und besser strukturierbaren Programmiersprachen ermöglichte zunächst die Aufteilung von Programmen in Module, woraus sich später die objektorientierte Programmierung entwickelte. Beim objektorientierten Ansatz enthalten Quelltexte nicht nur die Funktionalität eines Programms, sondern definieren auch die Verwendung der Programmelemente. Die Trennung der Spezifikation von der Implementierung lässt es zu, dass ein Programm von mehreren Entwicklern in Teilaufgaben bearbeitet werden kann, und verhindert zumindest prinzipiell, dass sich Programmfehler durch Wechselwirkungen auf andere Programmteile auswirken können. Ein Vorgehensmodell in der Software-Entwicklung beschreibt den kompletten Ablauf einer Entwicklung von der Analyse der Problemstellung über die Architektur der Software bis zur Implementierung, Auslieferung und anschließenden Wartung des Systems. Aufgrund der hohen Zahl von möglichen Einflussfaktoren kann allerdings kein Vorgehensmodell als allgemein gültig angesehen werden. In bestimmten Bereichen (z. B. bei Behörden) kann aber ein Entwicklungsmodell vorgeschrieben sein [34] Familien von Vorgehensmodellen Vorgehensmodelle lassen sich in Familien einordnen: die Familie der Phasen-, Wasserfallund Schleifenmodelle, die Familie der prototypischen Vorgehensmodelle und die Familie der inkrementellen, evolutionären, rekursiven und iterativen Verbesserungsmodelle [8]. Schon 1956 wurde das Phasenmodell veröffentlicht, das die Entwicklung in einen klaren Ablauf der Phasen Analyse, Entwurf, Implementierung und Einsatz einteilt. Die Phasen können je nach konkretem Modell weiter ausgeprägt werden. In Verbesserungen des Phasenmodells kann während der Abarbeitung in frühere Phasen zurückgesprungen werden, falls Fehler in der vorherigen Phase entdeckt werden, oder Phasen schleifenartig durchlaufen werden, bis zur nächsten Phase übergegangen wird. Ein großer Vorteil bei diesen Modellen ist, dass alle Anforderungen stets berücksichtigt sind, da ein vorheriger Schritt abgeschlossen sein muss, damit der nächste begonnen werden kann. Das Durchlaufen des Modells kann allerdings zeitaufwändig sein, besonders wenn Phasen wiederholt werden müssen. Ein weiterer Nachteil ist, dass eine konkrete Implementierung erst relativ spät zur Verfügung steht und Missverständnisse bei der Aufgabenstellung möglicherweise erst dann festgestellt werden.

40 Grundlagen 40 Bei prototypischen Entwicklungsmodellen soll gerade diese Schwierigkeit vermieden werden. In den verschiedenen Entwicklungsphasen ist die Erstellung von Prototypen vorgesehen, mit denen Fehler in vorherigen Schritten leichter festgestellt werden können. Ein Prototyp kann auf unterschiedliche Weise realisiert werden. Das Ziel ist immer, den Prototypen möglichst schnell und kostengünstig zu erstellen. Dazu kann die Zahl der Programmfunktionen reduziert werden oder Funktionalität durch Vorgabe von Antworten simuliert werden. Wenn zunächst nur das Aussehen der Benutzungsoberfläche geklärt werden soll, kann der Prototyp auch als Mock-Up ohne jegliche Funktionalität oder in Form von Skizzen ( Papierprototyp ) zur Verfügung gestellt werden. Prototypische Entwicklungsmodelle bieten sich besonders dann an, wenn die Anforderungen an das zu entwickelnde System unklar sind und mit Hilfe des Prototypen weiter analysiert werden müssen [8]. Beim iterativen Entwicklungsmodell steht ebenfalls im Vordergrund, möglichst schnell ein einsatzfähiges Programm zu erhalten. Dazu wird bei der Entwicklung zunächst nur eine Teilmenge der Anforderungen berücksichtigt, für die alle Phasen durchlaufen werden. Der Prototyp ist bei dieser Familie von Entwicklungsmodellen kein Wegwerfprodukt, sondern stellt die Grundlage für die nächste Entwicklungsiteration dar. Iterative Entwicklungsmodelle sind ebenfalls sehr nützlich, wenn Anforderungen unscharf sind. Bei der ersten Iteration kann mit den Anforderungen begonnen werden, bei denen die größte Klarheit herrscht. Ein Nachteil solcher Modelle ist allerdings, dass eine größere Anzahl von Entwicklungsschritten koordiniert werden muss und häufiger unterschiedliche Versionen verwaltet werden müssen. Damit das Modell anwendbar ist, muss außerdem von Anfang an auf Erweiterbarkeit geachtet werden, da sonst in folgenden Inkrementen zu viel Arbeit aus vorhergehenden Schritten wiederholt werden muss. Iterative Entwicklungsmodelle können eingesetzt werden, wenn die Entwickler mit Methoden oder Entwicklungswerkzeugen wenig Erfahrung haben, die gesammelte Erfahrung kann dann in weiteren Inkrementen genutzt werden [8]. Außerdem können einzelne Methoden oder Werkzeuge ausgetauscht werden, wenn sie sich als weniger tauglich erweisen Extreme Programming Bei vielen Softwareprojekten wurde festgestellt, dass Entwicklungsmodelle nicht garantieren, dass Projekte im vorgesehenen Zeitrahmen fertiggestellt werden können, wobei die meiste Zeit nicht mit der Implementierung, sondern mit anderen Phasen verbracht wird. Der Druck ist groß, bei der Implementierung vom beschlossenen Design abzuweichen und Abkürzungen oder Provisorien zu benutzen. Eine Abkehr von den etablierten schwergewichtigen Entwicklungsmodellen ist das sogenannte Extreme Programming oder kurz XP. Grundlage von XP ist die Leichtgewichtigkeit, also die rasche Erstellung eines ausführbaren Systems mit einem Minimum an weiteren Schritten wie Design oder Modellierung [8]. Die Lösung von Teilaufgaben liegt in der Verantwortung von einzelnen Entwicklern oder kleinen Teams, wobei häufig das Pair Programming in Zweierteams praktiziert wird. Das Ergebnis der Entwicklung bildet hauptsächlich der erstellte Quelltext, der fortlaufend weiter optimiert wird.

41 Grundlagen 41 Bei XP ist eine intensive Zusammenarbeit der Entwickler wichtig, jeder muss mit dem System in seiner Gesamtheit vertraut sein. Die Teamgröße und damit die Projektgröße ist damit aber auch begrenzt, da ab einem gewissen Punkt die Kommunikation nicht mehr ausreichend ist. Das Vorgehensmodell eignet sich eher für erfahrene Entwickler, die diszipliniert arbeiten können Der Agility Ansatz Dem Extreme Programming wurde aufgrund der vordergründigen Unstrukturiertheit viel Kritik entgegengebracht. Für dessen Verfechter stellt XP aber einen außerordentlich flexiblen Ansatz dar. Diese Flexibilität wollten die Autoren des agilen Manifests [35] als Grundlage eines umfassenderen Entwicklungsmodells beibehalten. Extreme Programming stellt dabei den bekanntesten agilen Ansatz dar, Agilität als Leitbild lässt sich aber auch auf traditionellere Vorgehensmodelle anwenden [9]. Das agile Manifest misst der Kommunikation sowohl zwischen Entwicklern und Auftraggebern als auch der Entwickler untereinander einen hohen Stellenwert bei. Als oberstes Ziel wird die schnelle Erstellung von funktionierender Software formuliert, die im Laufe des Prozesses kontinuierlich verbessert werden soll. Das Reagieren auf Änderungen wird zwar über das sture Befolgen eines Plans gestellt, auf etablierte Methoden wie das saubere Dokumentieren von Zwischenergebnissen wird aber nicht generell verzichtet [10]. Ausgehend vom agilen Manifest wurden einige agile Methoden vorgeschlagen. Eine zentrale Forderung ist, dass der gesamte Entwicklungsprozess von der Planung über die Anforderungsanalyse und das Design bis hin zu Programmierung, Test und Dokumentation mehrfach in kurzen Zyklen durchlaufen wird [9]. Im verbreiteten agilen Entwicklungsprozess Scrum bestehen Projekte aus einer Folge von 30-tägigen Iterationen, die Sprints genannt werden [10]. Die 30 Tage sind ein Richtwert, von dem abgewichen werden kann. Ein Sprint wird allerdings nicht verlängert, wenn Aufgaben nicht erledigt werden konnten. Nicht erfüllte Anforderungen werden in die Planung des nächsten Sprints aufgenommen. Das zentrale Element des Entwicklungsprozesses ist das Backlog, das eine Sammlung aller Forderungen und offener Wünsche an das Projekt enthält (siehe Abbildung 2.9). Zu Beginn eines Sprints werden diejenigen Anforderungen ausgewählt, die während des nächsten Sprints entwickelt werden sollen. Diese Liste bildet das Sprint-Backlog. Abbildung 2.9: Backlog beim Scrum-Prozess Aus [9]

42 Grundlagen 42 Die Entwicklung wird vom Scrum-Team, bestehend aus Designern, Programmierern und User Interface Spezialisten, eigenverantwortlich umgesetzt. Das Team plant und organisiert seine Arbeit selbst. Dazu trifft es sich täglich zu Meetings, den sogenannten Scrums, von denen die Methode ihren Namen erhalten hat. Zum Abschluss eines Sprints stellt das Team die Ergebnisse allen Interessierten vor (vorzugsweise unter Mitwirkung des Auftraggebers), die aufgrund der neuen Erkenntnisse das Produkt-Backlog erweitern oder ändern können [10].

43 Vergleich mit anderen Arbeiten 43 3 Vergleich mit anderen Arbeiten In diesem Kapitel werden beispielhaft einige Projekte und Arbeiten vorgestellt, die als Zielsetzung ebenfalls das Lehren oder Lernen von Bridge mit Computerunterstützung ermöglichen sollen. Die Internetseite von Bridge Base Online (siehe Kapitel 3.6) ist zwar nicht speziell für das Lernen von Bridge vorgesehen, stellt als größte Plattform für das Online-Spiel aber eine Referenz für den Ablauf von Bridge-Spielen am Computer dar. Weiterhin wird die Software Articulate E-Learning Studio 09 vorgestellt, deren Vorgänger bereits in [15] als mögliche Alternative untersucht wurde, E-Learning Material für Bridge zu erstellen. Für Texas Hold Em Poker existieren ebenso wie für Bridge zahlreiche Computerprogramme und Internetplattformen, vor allem für das Online-Spiel gegen andere Teilnehmer. In dieser Arbeit wurde allerdings nur eine einfache Poker-Komponente implementiert, um die Erweiterbarkeit des E-Learning Toolkits und einen möglichen Ansatz für den Einsatz im Poker-Unterricht zu veranschaulichen. Ein umfassender Vergleich mit bestehenden Programmen und Materialien zu Poker wurde deshalb nicht durchgeführt. 3.1 Richard Pavlicek For Bridge Players Richard Pavlicek ist ein Experte für das Unterrichten von Bridge. Auf seiner Internetseite For Bridge Players [40] stellt er sein Lehrmaterial vor. Ein Bridge-Grundkurs steht im HTML-Format zum freien Download bereit, weiterführendes Lehrmaterial im PDF-Format wird zum Kauf angeboten. Pavlicek bietet eine große Anzahl Bridge-Quizze an (Multiple Choice Übungsaufgaben). Neben den Aufgaben im Lehrmaterial veröffentlicht er monatlich Tests zu einem bestimmten Thema. Diese Aufgaben können als PDF-Dateien heruntergeladen oder online gelöst werden. Dabei werden Statistiken über die Anzahl der Teilnehmer und die minimale, maximale und durchschnittlich erreichte Punktzahl geführt. Aufgaben vergangener Monate können inklusive detaillierter Erklärungen zu den Lösungen heruntergeladen werden. Das Lehrmaterial von Pavlicek deckt einen großen Bereich von Schwierigkeitsgraden ab und ist mit teilweise sehr schwierigen Übungsaufgaben auch für weiter fortgeschrittene Spieler fordernd. Dabei wird durchgängig eine vereinfachte Darstellung der Spielsituationen verwendet (siehe Abbildung 3.1). Mögliche Spielverläufe können aber nur mit Papier und Bleistift durchgespielt werden.

44 Vergleich mit anderen Arbeiten 44 As South, assume you are declarer in 4 on each deal. Can you find the surefire play to guarantee making your contract? A K 95 K 64 A Q 9 K 92 N Lead: Q W E East plays 3 S Q J A 4 Abbildung 3.1: Beispiel aus den Übungsaufgaben von Richard Pavlicek Aus [40] Unter dem Punkt Bridge Utilities können einige Bridge-Programme heruntergeladen werden. Pavlicek setzt dabei auf das von ihm entwickelte Dateiformat RBN, das zwar PBN ähnelt, aber etwas einfacher aufgebaut ist. Ein Programm zur Konvertierung verschiedener Bridge-Dateiformate inklusive RBN und PBN ist ebenfalls vorhanden. Zur Erzeugung von Kartenverteilungen hat Pavlicek das Programm RP Deal Finder entwickelt. Bei diesem Programm können sehr detaillierte Kriterien für die gewünschten Verteilungen angegeben werden, darunter auch die Erfüllbarkeit eines bestimmten Kontrakts. Zu diesem Zweck enthält das Programm eine Datenbank von ca Kartenverteilungen, für die mittels Double-Dummy-Analyse die maximal erfüllbaren Kontrakte aller Spieler bereits ermittelt wurden. Das Angebot von Pavlicek ist für fortgeschrittene Spieler aufgrund der inhaltlichen Tiefe sehr gut geeignet. Die einfache Darstellung und nicht vorhandene Interaktivität erschweren aber eine Verwendung in Unterrichtssituationen. Die angebotenen Programme haben nützliche Funktionen, die Bedienung könnte aber denjenigen schwerfallen, die das Ausführen von Programmen in der Befehlszeile nicht gewohnt sind.

45 Vergleich mit anderen Arbeiten Bridge Master Das Unternehmen Q-plus Software GmbH bietet verschiedene Computerprogramme für das Lernen und Spielen von Bridge an [41]. Das Produkt Q-plus Bridge ist ein Programm, mit dem ein Spieler Bridgepartien gegen Computerspieler spielen kann, und wird in mehreren Sprachen angeboten. Es sind aber auch einige weitere Programme erhältlich, die speziell auf das Lernen von Bridge ausgelegt sind. Neben dem Programm Lerne Bridge zu spielen, das die Grundlagen des Spiels zeigt und kostenlos heruntergeladen werden kann, sind Programme zum Trainieren der Reizung und des Abspiels vorhanden, etwa das Programm Bridge Master zum Trainieren des Spiels des Alleinspielers (siehe Abbildung 3.2). Abbildung 3.2: Bridge Master Bei Bridge Master wird dem Benutzer die Aufgabe gestellt, bei vorgegebener Kartenverteilung einen bestimmten Kontrakt zu erfüllen. Der Benutzer übernimmt immer die Rolle des Alleinspielers in Position Süd. Eine Demonstrationsversion des Programms kann von der Internetseite von Q-plus [42] heruntergeladen werden. Bridge Master basiert auf der Vugraph -Technologie zur Spieldarstellung, die auch bei Bridge Base Online (siehe Kapitel 3.6) zum Einsatz kommt. Für den Eigengebrauch ist das Programm Bridge Master gut dazu geeignet, das Abspiel zu trainieren. Zu den Spielsituationen werden Kommentare angezeigt. Eine Einbettung in weiterführendes Spielmaterial ist aber nicht möglich, und bei einer Vorführung in einer Unterrichtssituation wären Programmeingaben nötig, die den Ablauf der Präsentation stören können.

46 Vergleich mit anderen Arbeiten Patrik Schulz: Ein Tutorensystem für Bridgelehrer Patrik Schulz hat in seiner Masterarbeit [13] die Software Bridge Teacher für die Unterstützung im Bridgeunterricht entwickelt (siehe Abbildung 3.3). In der Arbeit wurde festgestellt, dass die erhältlichen Bridgeprogramme nicht für die Bedürfnisse des E-Learning geeignet sind. Mit Bridge Teacher ist es möglich, Kartenverteilungen einzugeben oder aus Dateien im PBN-Format einzulesen und die Reizung und das Abspiel durchzuführen. Es ist außerdem möglich, gesprochene Kommentare als Audiodateien abzuspielen. Für die Anzeige von Lehrmaterial ist eine Funktion vorgesehen, die HTML-Dateien oder PDF- Dokumente anzeigt. Abbildung 3.3: Bridge Teacher Aus [13] Das Programm enthält Ansätze, die Darstellung von Spielverläufen mit dem Lehrmaterial zu verbinden. Da aber nur HTML-Dateien und PDF-Dokumente unterstützt werden, können PowerPoint-Präsentationen nicht direkt angezeigt werden. Wie in [15] gezeigt wurde, ist die Umwandlung von PowerPoint-Dateien in andere Formate nur möglich, wenn Einschränkungen in Kauf genommen werden. Eine zusammenhängende Präsentation im Unterricht ist schwierig, da zur Anzeige von Dateien Programmeingaben vorgenommen werden müssen. 3.4 Christian Lerch: Bridge Tutor Die Software Bridge Tutor, die Christian Lerch in seiner Diplomarbeit [14] entwickelt hat, ist ein eigenständiges Programm zum Trainieren der Abspielphase von Bridge-Partien (siehe Abbildung 3.4). Kartenverteilungen und Bietverläufe werden aus PBN-Dateien eingelesen. Der eigentliche Bietvorgang wird in Bridge Tutor nicht simuliert, der gespielte Kontrakt wird durch die jeweilige PBN-Datei festgelegt. Das Programm enthält einen Editor, mit dem Spielsituationen erstellt und abgespeichert werden können.

47 Vergleich mit anderen Arbeiten 47 Abbildung 3.4: Bridge Tutor Aus [14] Der Benutzer der Software spielt in jeder Partie den Alleinspieler, die beiden Gegenspieler werden vom Computer übernommen. Die Spielweise der Gegenspieler wird durch spezielle Regeln festgelegt, die in den PBN-Dateien gespeichert werden. Die Computerspieler sollen etwaige Spielfehler des Alleinspielers ausnutzen und z. B. stechen, wenn sie die Gelegenheit dazu haben. Das PBN-Format wurde in Bridge Tutor entsprechend erweitert, so dass die Abspielregeln in den Dateien gespeichert werden können. Bei der Implementierung von Bridge Tutor wurde ein großer Wert auf eine ansprechende Präsentation und eine einfache Bedienung gelegt. Die Spielkarten werden sehr realistisch dargestellt, wodurch das Spiel plastisch und authentisch wirkt. Eine Verwendung zusammen mit Lehrmaterial im Unterricht ist allerdings schwierig, da das Programm nicht für diesen Zweck entwickelt wurde und keine entsprechende Anzeigefunktion enthält. 3.5 Bridge Baron und GIB Die kommerzielle Software Bridge Baron wird von der Firma Great Game Products angeboten. Das Programm ermöglicht das Spielen von Bridge-Partien gegen den Computer. Dabei wird sowohl die Reizung als auch das Abspiel simuliert, und der Benutzer kann die Rolle des Alleinspielers oder eines Gegenspielers übernehmen. Bridge Baron unterstützt eine große Zahl von unterschiedlichen Bietkonventionen, sowie verschiedene Analysefunktionen und Abrechnungsmethoden [43]. Das Programm steht in Konkurrenz zu Matthew Ginsbergs GIB [28], das einen ähnlichen Funktionsumfang bietet. Eine Demonstrationsversion von Bridge Baron kann auf der Internetseite des Herstellers [43] heruntergeladen werden.

48 Vergleich mit anderen Arbeiten 48 Abbildung 3.5: Bridge Baron Sowohl die Darstellung bei Bridge Baron (siehe Abbildung 3.5) als auch bei GIB (siehe Abbildung 3.6) ist eher zweckmäßig gehalten. Viele Funktionen werden über Menüs und Einstellungsfenster ausgewählt. Die Benutzungsoberfläche ist klar auf einzelne Benutzer zugeschnitten. Für die Verwendung im Bridge-Unterricht ist die Bedienung zu kompliziert, und die Darstellung ist bei beiden Programmen nicht für die Präsentation mit einem Beamer optimiert. Abbildung 3.6: GIB Aus [28]

49 Vergleich mit anderen Arbeiten Bridge Base Online Nach Aussage des Betreibers ist die Webseite von Bridge Base Online [44] die größte Online-Community für Bridge. Mit ihrer Vugraph genannten Technologie ist es möglich, über den Dienst von Bridge Base Online zusammen mit Spielern aus der ganzen Welt Bridge zu spielen. Die Mitgliedschaft ist kostenlos; finanziert wird das System über Werbeeinblendungen und bestimmte Premium -Dienste, beispielsweise das Führen einer Online-Punktliste. Obwohl der Zugang zum System von Bridge Base Online auch über eine Client-Software für Windows möglich ist, die von der Webseite heruntergeladen werden kann, ist der einfachste Weg für die Teilnahme die Online-Flash-Version (siehe Abbildung 3.7). Nach Angabe von Bridge Base ist damit der Zugang von jedem Browser mit Flash-9-Unterstützung möglich, auch in Linux oder auf Apple Macintosh Rechnern. Für die Anmeldung im System und zur Teilnahme an Bridge-Partien ist die Einrichtung eines Benutzerkontos notwendig. Über einen Gastzugang ist immerhin das Kiebitzen an Spieltischen oder das Betrachten von Live-Übertragungen von Bridge-Turnieren möglich. Die Darstellungsqualität bei Bridge Base Online ist sehr gut. Die Spielelemente sind klar voneinander abgegrenzt und die Grafiken und Schriftarten werden gut an die jeweilige Bildschirmauflösung angepasst. Abbildung 3.7: Bridge Base Online

50 Vergleich mit anderen Arbeiten Articulate E-Learning Studio 09 In [15] wurden verschiedene Programme unter dem Gesichtspunkt untersucht, ob sie für die Erstellung von Bridge-Lehrmaterial in Verbindung mit PowerPoint geeignet sind. Dabei wurde zunächst betrachtet, in welcher Form das Material im Unterricht benutzt oder von Lernenden am eigenen Computer betrachtet werden kann. In diesem Zusammenhang spielen Lehrmanagementsysteme eine große Rolle, da sich damit komplette E-Learning Umgebungen aufbauen lassen, die neben der Verwaltung der Lehrinhalte auch die Benutzerverwaltung und Kommunikationsdienste bereitstellen. Die Firma Articulate bietet die Software Articulate E-Learning Studio 09 an, mit der Präsentationen, die mit Microsoft PowerPoint erstellt wurden, in Lehrmanagementsystemen genutzt werden können [45]. Mit der Komponente Articulate Presenter ist es möglich, PowerPoint-Präsentationen in eine Reihe von Videoformaten umzuwandeln (siehe Abbildung 3.8). Für die Verwendung in Lehrmanagementsystemen bietet sich das Flash- Format an, weil die meisten Benutzer Flash mit ihrem Internetbrowser wiedergeben können (siehe [15]). Mit Articulate Presenter ist es außerdem möglich, gesprochene Kommentare aufzuzeichnen und mit den Präsentationen zu synchronisieren. Abbildung 3.8: Articulate Presenter Aus [45] Die einzelnen Programmteile des E-Learning Studio werden in die Benutzungsoberfläche von PowerPoint integriert, so dass direkt damit gearbeitet werden kann, ohne weitere Programme aufrufen zu müssen. Mit den Programmkomponenten Engage und Quizmaker werden neue Vorlagen und grafische Elemente zu PowerPoint hinzugefügt, die speziell für die Benutzung im E-Learning-Bereich entworfen wurden. Mit Quizmaker können Quizze erstellt werden, bei denen Fragen mit verschiedenen Eingabemöglichkeiten versehen werden können, beispielsweise Multiple-Choice-Antworten oder Lückentexte. Obwohl das E-Learning Studio eine sehr ausgereifte Software ist und viele Funktionen speziell für E-Learning anbietet, wurde in [15] festgestellt, dass die Erstellung von Lehrmaterial für Bridge durch die Software nicht vereinfacht wird. Die komplexen Zusammenhänge des Spiels lassen sich nur bedingt mit den angebotenen Darstellungselemen-

51 Vergleich mit anderen Arbeiten 51 ten umsetzen, und bei der Quizmaker-Komponente ist die Verwendung von Kartengrafiken oder Symbolen für Spielfarben nur mit Einschränkungen möglich. 3.8 Zusammenfassung Die hier vorgestellten Programme und Materialien decken jeweils nur einen Teil der Problemstellung ab. Sie sind entweder bezüglich der inhaltlichen Tiefe gut für das Lehren von Bridge-Spielstrategien geeignet oder von der Darstellungsweise her gut für den Einsatz im Unterricht zu gebrauchen. Ein einfach zu bedienendes Programm, das beiden Anforderungen gerecht wird, fehlt aber bisher. Die Grafiken und Animationen der Spielprogramme sorgen für einen sehr realistischen und anschaulichen Spielverlauf, der gut für das Vermitteln von Bridge-Strategien geeignet wäre. Die nötigen Programmeingaben und die fehlende Verknüpfung mit Lehrmaterial sind für den Einsatz im Unterricht aber hinderlich. Das statische Spielmaterial könnte zwar in Präsentationen für den Unterricht eingesetzt werden, die anschauliche Vermittlung von Abläufen ist damit aber nicht möglich. Die E-Learning Software von Articulate lässt sich einfach bedienen und ermöglicht die Erstellung von sehr ansprechendem Lehrmaterial, ist aber nicht für Bridge oder andere Kartenspiele ausgelegt. Als Ziel dieser Arbeit soll daher ein Programm entwickelt werden, dass den Inhalt von traditionellem Lehrmaterial mit der anschaulichen Darstellung der hier vorgestellten Bridgeprogramme verbindet und möglichst unkompliziert im Unterricht eingesetzt werden kann.

52 Aufgabenbeschreibung 52 4 Aufgabenbeschreibung Das Ziel dieser Arbeit ist die Entwicklung einer Erweiterungskomponente für Microsoft PowerPoint 2007, mit der Spielsituationen aus Kartenspielen zur Illustrierung von Beispielen in Lehrmaterial eingefügt werden können. Die Bedienung der Komponente soll in die Benutzungsoberfläche von PowerPoint integriert werden. Zu Beginn der Entwicklung wurden die Anforderungen bewusst unscharf formuliert. Die in Kapitel 3 aufgeführten Arbeiten und Softwareprojekte standen dabei als Vorlage zur Verfügung, ein ähnlicher Funktionsumfang sollte im Rahmen dieser Arbeit erreicht werden. Im ersten Interview mit dem Auftraggeber wurden Forderungen und Wünsche an das Projekt ausgearbeitet, die später in weiteren Treffen konkretisiert wurden. Die Aufgabenstellung, zwei unterschiedliche Kartenspiele zu unterstützen, legt es bereits nahe, die Softwarekomponente modular aufzubauen. So wäre es auch denkbar, im Rahmen des E-Learning Toolkits Komponenten für andere Spiele und andere Themenbereiche zu implementieren. Dieser Gedanke wurde zwar nicht explizit in die Aufgabenliste aufgenommen, bestimmte aber als zentrale Anforderung den Aufbau der Programmmodule. 4.1 Anwendungsbereich und Benutzerrollen Die Funktionen der in dieser Arbeit entwickelten Software lassen sich einzeln auch mit anderen Programmen realisieren. Ein entscheidender Unterschied ist jedoch, dass das E-Learning Toolkit auf einen bestimmten Kontext zugeschnitten ist, der besondere Anforderungen an die Benutzungsschnittstelle und das erzeugte Material stellt. Die Software ist für die Benutzung von Lehrpersonen (beispielsweise in Bridge-Schulen) vorgesehen. Das erstellte Lehrmaterial soll entweder im Unterricht mit einem Beamer dargestellt werden oder von Lernenden an ihren eigenen Rechnern betrachtet werden. Es kann davon ausgegangen werden, dass in beiden Fällen überwiegend Rechner mit dem Betriebssystem Microsoft Windows benutzt werden und für die Erstellung von Lehrmaterial das Softwarepaket Microsoft Office zum Einsatz kommt. Aus diesem Grund liegt der Schwerpunkt dieser Arbeit in der Entwicklung einer Komponente für Microsoft Power- Point unter Windows. Zur Zeit sind sowohl die Versionen Windows XP als auch Windows Vista verbreitet, die Software sollte also in beiden Versionen lauffähig sein. Viele Benutzer setzen anstelle von Microsoft-Produkten lieber freie Software ein. Das Betriebssystem Linux ist mittlerweile so weit fortgeschritten, dass auch Benutzer mit wenig Computerwissen sehr komfortabel damit arbeiten können. Das freie Office-Paket von OpenOffice.org (siehe Kapitel 2.3.4) kann sowohl in Windows als auch in Linux ausgeführt werden. OpenOffice ist zu Microsoft Office kompatibel und kann dessen Dateiformate lesen und schreiben. Ein Teil der Aufgabenstellung ist deshalb, zu prüfen, in wel-

53 Aufgabenbeschreibung 53 chem Maße das E-Learning Toolkit und das erstellte Lehrmaterial unter Linux und in OpenOffice genutzt werden können. Zum Festlegen der Aufgabenstellung wurden zwei prinzipielle Benutzerrollen betrachtet: die Lehrperson, die das Programm für die Erstellung von Lehrmaterial benutzt, und die Lernenden als Zielgruppe des Lehrmaterials. Während aus der Sicht der Lehrperson eher der Funktionsumfang und die Benutzungsfreundlichkeit der Programmoberfläche im Vordergrund stehen, ist aus der Sicht der Lernenden die Qualität des Materials ausschlaggebend. Lehrpersonen sind die prinzipiellen Benutzer der zu entwickelnden Software. Sie erstellen neues Lehrmaterial oder erweitern vorhandenes Lehrmaterial mit PowerPoint unter Zuhilfenahme der Programmfunktionen des E-Learning Toolkits. Dabei wechseln sie häufig zwischen den Funktionen von PowerPoint und denen von ETK hin und her. Beim Einsatz im normalen Unterricht wird das Lehrmaterial mit Hilfe eines Beamers präsentiert. Zusätzlich kann das Material den Lernenden zur Verfügung gestellt werden, z. B. als Download über das Internet. Dabei kann das Material mit Übungsaufgaben erweitert werden. Lernende werden nicht mit dem E-Learning Toolkit selber konfrontiert, sondern mit dessen Ergebnis in Form von Präsentationen, die sie im Unterricht verfolgen oder als Dateien auf dem eigenen Computer ansehen können. 4.2 Aufgaben Die Aufgabenstellung wurde zunächst als eine Liste von Wünschen an das Softwareprodukt formuliert, aus denen im Laufe der Entwicklung konkrete Programmieraufgaben abgeleitet wurden. Die Aufgaben sind aus der Sicht des Lehrers beschrieben, der bestimmte Ziele erreichen will Anzeige von Spielkarten Die einfachste Aufgabe ist, einzelne Spielkarten in die Präsentation einzufügen. In einer Übersicht sollen alle verfügbaren Karten dargestellt werden, wobei der verwendete Kartensatz und die Sprache der Karten auswählbar sein soll. Durch Mausklick soll eine Karte in die aktuelle Folie eingefügt werden können. Der Benutzer kann anschließend die Karte verschieben oder deren Größe ändern Bridge Die Bridge-Komponente soll als zentrales Element die gespeicherten Spiele einer PBN- Datei anzeigen. Von dieser Übersicht ausgehend können dann die einzelnen Programmfunktionen ausgewählt werden. Die wählbaren Funktionen sollen hervorgehoben werden, so dass sofort erkennbar ist, an welcher Stelle eine bestimmte Funktion aufgerufen werden kann. Für das Einlesen von PBN-Dateien muss ein Programmmodul erstellt werden, das den Inhalt der Dateien entsprechend der PBN-Spezifikation [24] interpretiert. Dabei müssen auch Sonderfälle beachtet werden, beispielsweise Irregularities (siehe Kapitel 2.2.2).

54 Aufgabenbeschreibung 54 In einer Baumstruktur sollen alle Spiele angezeigt werden, die in der PBN-Datei enthalten sind. Für jedes Spiel sollen die folgenden Daten angezeigt werden: Boardnummer Position des Teilers Gefahrenlage Kartenverteilung Sonstige Informationen, die im ID-Abschnitt angegeben sind Ablauf der Reizung Kontrakt Ablauf des Abspiels Spielergebnis Weitere Funktionen der Bridge-Komponente sollen über das Anklicken von Einträgen in der PBN-Ansicht aufgerufen werden können. Wenn der Benutzer beispielsweise auf die Spielkarten eines Spielers klickt, soll ein Dialog angezeigt werden, mit dem die Karten in die Präsentation eingefügt werden können. Bearbeiten von PBN-Dateien Obwohl die Bearbeitung von PBN-Dateien auch mit anderen Programmen möglich ist (z. B. [13]), würde die Erstellung und Änderung von PBN-Dateien mit Hilfe des E-Learning Toolkits und damit innerhalb von PowerPoint die Bedienung vereinfachen. Eine häufige Aufgabe ist die Erstellung einer Kartenverteilung, mit der ein bestimmter Sachverhalt illustriert werden soll. Dabei soll es möglich sein, die Karten der Spieler auszuwählen oder zufällig zu verteilen. Aus den in Kapitel genannten Gründen muss der verwendete Zufallsgenerator allerdings bessere Zufallszahlen liefern als die gebräuchlichen Algorithmen zur Erzeugung von Pseudo-Zufallszahlen. Für die generierten Kartenverteilungen wäre es außerdem wünschenswert, mittels Double-Dummy-Analyse (siehe Kapitel 2.2.3) die bei optimaler Spielweise maximal möglichen Kontrakte zu ermitteln. Ein Kontrakt sollte zusammen mit der Kartenverteilung als PBN-Datei gespeichert werden können, damit eine passende Abspielsituation in die Präsentation eingefügt werden kann, ohne dass vorher die Reizung durchgespielt werden muss. Für die Vervollständigung der PBN-Datei sollte es schließlich möglich sein, den Ablauf der Reizung und des Abspiels in der PBN-Datei zu speichern. Dabei sollen auch Anmerkungen eingegeben werden können. Ob dies über ein externes Programm oder eine Methode innerhalb des E-Learning Toolkits geschieht, muss in den weiteren Entwicklungszyklen geklärt werden.

55 Aufgabenbeschreibung 55 Darstellen von Blättern und Bewertungsquiz Durch Anklicken der Kartenverteilung eines Spielers in der PBN-Ansicht sollen die Karten in der Präsentation dargestellt werden können. Dabei sind drei Darstellungsarten vorgesehen: als Kartengrafiken, als vereinfachte Liste, wie im folgenden Beispiel: A 8 B 9 5 D 10 8 K D B 7 5 in Form eines interaktiven Bewertungsquiz, bei dem der Betrachter unter verschiedenen Punktwertungen oder möglichen Geboten wählen kann. Bei der Anzeige der Präsentation soll es dann möglich sein, eine Antwort auszuwählen, wodurch ein passender Erklärungstext angezeigt werden soll. Darstellung der Reizung Sofern in der PBN-Datei ein Reizverlauf gespeichert wurde, soll dieser bei der Anzeige der Präsentation Schritt für Schritt angezeigt werden können. Dazu sollten auch die Spielkarten der Spieler und die Gefahrenlage angezeigt werden. In der PBN-Datei enthaltene Kommentare zu Geboten sollen ebenfalls angezeigt werden. Bei dieser Darstellungsweise sollten keine VBA-Makros verwendet werden, damit die Präsentation auch mit dem PowerPoint Viewer (siehe Kapitel 2.3.2) möglich ist. Wünschenswert wäre es außerdem, dass bei der Präsentation ein beliebiger Reizverlauf durchgespielt werden kann. Dazu ist allerdings der Einsatz von VBA-Makros notwendig. Zur Abgabe von Geboten sollte eine Bidding Box (siehe Kapitel 2.2.1) nachgebildet werden. Weiterhin ist es sinnvoll, wenn Gebote in einer Undo-Funktion wieder zurückgenommen werden können, damit im Unterricht Alternativen besprochen werden können. Beim Anklicken des Reizverlaufs soll ein Dialog angezeigt werden, mit dem der Reizverlauf in die Präsentation eingefügt werden kann. In dem Dialog sollen Darstellungsoptionen wie der verwendete Kartensatz und die Anordnung der Spielelemente ausgewählt werden können. Darstellung des Abspiels Eine wichtige Aufgabe ist die Darstellung des Abspiels. Die gespielten Karten und eventuell vorhandene Kommentare sollen angezeigt werden. Um bestimmte Spielsituationen darzustellen, sollen die Karten einzelner Spieler wahlweise offen gezeigt werden oder verdeckt bleiben. Die Darstellung des Abspiels sollte ebenfalls ohne VBA-Makros implementiert werden, damit sie im PowerPoint Viewer angesehen werden kann. Ähnlich der Funktion zur Darstellung der Reizung soll durch Anklicken des Spielverlaufs ein Dialog mit

56 Aufgabenbeschreibung 56 Einstellungsmöglichkeiten für die Darstellung des Abspiels angezeigt werden. Außerdem sollte die Möglichkeit implementiert werden, einen freien Spielverlauf zu behandeln, wozu allerdings ebenfalls die Verwendung von VBA-Makros notwendig ist. Die jeweils gespielte Karte sollte dabei mit der Maus ausgewählt werden können. Eine Undo-Funktion ist auch hier sinnvoll Poker Wünschenswert wäre es, für die Pokerkomponente ein Dateiformat zu unterstützen, mit dem Pokerpartien gespeichert werden können. Dabei soll es möglich sein, die Handkarten einer wählbaren Zahl von Spielern und die Gemeinschaftskarten einzugeben oder zufällig zu verteilen, um die Karten eines Spielers oder den Spielablauf einer Pokerrunde darstellen zu können. In der Benutzungsoberfläche der Poker-Komponente sollen die verteilten Karten angezeigt werden. Darstellung von Blättern Durch Wahl eines Pokerblatts soll dieses in Form von Kartengrafiken in die Präsentation eingefügt werden. Die Gemeinschaftskarten sollen ebenfalls dargestellt werden können. Darstellung des Spieltisches Bei der Wahl dieser Option soll der Spieltisch mit allen Spielern in die Präsentation eingefügt werden. Dabei soll festgelegt werden können, wie viele Chips jeder Spieler in seinem Vorrat hat, wie hoch die Blinds sind und welcher Spieler die Position des Dealers hat. Bei der Wiedergabe soll es möglich sein, die Pokerrunde interaktiv bis zum Ende zu spielen. Falls es zum Showdown kommt, sollen die besten Kombinationen der Spieler angezeigt werden und der oder die Gewinner der Runde ermittelt werden. 4.3 Anforderungen Obwohl die Anforderungen an die Funktionalität zunächst sehr generell gehalten sind, sollen weitere Anforderungen bezüglich der Qualität, Benutzbarkeit und der späteren Wartbarkeit und Erweiterbarkeit grundsätzlich erfüllt werden und im Laufe der Entwicklung als Grundlage für die Evaluation der Zwischenschritte benutzt werden Anforderungen aus der Sicht der Lernenden Für Lernende ist die Qualität des erzeugten Lehrmaterials ausschlaggebend. Eine Anforderung ist, dass das Material auf verschiedenen Ausgabegeräten, die unterschiedliche Bildschirmauflösungen haben können, gut lesbar dargestellt werden soll. Außerdem soll das Lehrmaterial interaktiv sein und das Durchspielen unterschiedlicher Spielwege ermöglichen. Wenn das Lehrmaterial von den Lernenden auf ihren eigenen Computern betrachtet werden soll, muss es mit möglichst vielen Systemkonfigurationen kompatibel sein.

57 Aufgabenbeschreibung Anforderungen aus der Sicht der Lehrperson Da bei der Erstellung von Lehrmaterial häufig zwischen den Funktionen von PowerPoint und denen des E-Learning Toolkits gewechselt wird, sollte das Programm idealerweise komplett in die Oberfläche von PowerPoint integriert sein. Auch bei der Wiedergabe von Lehrmaterial sollte es nicht nötig sein, während der Präsentation zu einem anderen Programm zu wechseln, weil das den Ablauf stark stört. Bei Lehrpersonen kann nicht zwingend ein großes Computerwissen vorausgesetzt werden, obwohl zumindest etwas Erfahrung in der Benutzung von PowerPoint vorhanden sein sollte. Verschachtelte Menüs und verborgene Einstellungen könnten verwirrend sein, stattdessen sollten Wahlmöglichkeiten klar aufgeführt werden und in einem Point-and-Shoot - Stil ausgewählt werden können. Zusammengehörende Programmfunktionen sollten nach Möglichkeit nicht über verschiedene Eingabefenster verteilt werden. Für den produktiven Einsatz einer Software ist es wichtig, wiederkehrende Aufgaben zu vereinfachen oder nach Möglichkeit zu automatisieren. Im E-Learning Bereich ist es aber auch von Vorteil, wenn die Präsentation angepasst werden kann, um einen bestimmten Aspekt des Lehrmaterials hervorzuheben oder um einem persönlichen Stil zu entsprechen. Durch den Gebrauch von Vorlagen können beide Ziele erreicht werden. Anhand von Vorlagen ist es möglich, wiederkehrende Inhalte auf einfache Weise für das jeweilige Lernziel zu erzeugen. Unterschiedliche Vorlagen können dabei benutzt werden, um zu bestimmen, in welchem Grad die Darstellung von Spielsituationen realistisch oder schematisch sein soll. Außerdem können die Vorlagen für einen bestimmten Stil angepasst werden Technische Anforderungen Da die vorgesehenen Benutzer möglicherweise nur wenig Computerwissen besitzen, sollten Fehlersituationen möglichst frühzeitig abgefangen und verständlich erläutert werden. Es sollte außerdem sichergestellt werden, dass Programmfehler nicht zu unbeabsichtigtem Datenverlust führen können. Beim Laden und Speichern von Dateien sollten die in Windows gebräuchlichen Dialoge verwendet werden, damit der Benutzer sich damit leichter zurechtfindet. Das Laufzeitverhalten und die Geschwindigkeit des PowerPoint Add-Ins sind von geringerer Bedeutung, sofern sie das Arbeiten nicht übermäßig behindern. Eine größere Bedeutung hat das Reaktionsverhalten des erstellten Lehrmaterials, da bei einer Präsentation im Unterricht Verzögerungen störend sein können. Die Darstellungsgeschwindigkeit sollte während der Entwicklung auch mit leistungsschwächeren Rechnern überprüft werden Erweiterbarkeit Ein wichtiges Kriterium bei der Entwicklung sollte die Erweiterbarkeit des Programmcodes sein. Ein Hilfsmittel ist hierbei die Einteilung in Programmmodule, die über möglichst abstrakte Schnittstellen miteinander verbunden sind. So ist gewährleistet, dass sich Änderungen an einem Programmmodul möglichst wenig auf andere Module auswirken.

58 Lösungsansatz 58 5 Lösungsansatz Ausgehend von der Aufgabenbeschreibung wurde eine Vorgehensweise ausgearbeitet. Hierbei mussten einige Vorgaben beachtet werden, etwa der vorgegebene Zeitrahmen für die Arbeit und die vorgesehene Einsatzumgebung. Ob alle Anforderungen mit den geplanten Mitteln umgesetzt werden können, war zu Beginn der Entwicklung noch nicht absehbar. Die Methoden des Agility Ansatzes sollten dabei eine größtmögliche Flexibilität gewährleisten, das Vorgehen während der Entwicklung an auftauchende Probleme anzupassen. 5.1 Anwendung des Agility Ansatzes in dieser Arbeit Als wichtigstes Hilfsmittel wurde für diese Arbeit die Führung eines Backlogs angewendet. Da eine vorherige detaillierte Anforderungsanalyse und ein vollständig durchgeführtes Design nicht vorlagen, mussten im Backlog diese Aufgabenteile berücksichtigt werden. Dazu wurde das Backlog in vier Abschnitte aufgeteilt. Jeder Entwicklungszyklus sollte mit einer Besprechung beginnen, bei der die aktuellen Anforderungen und die Evaluation des Ergebnisses des vorangehenden Entwicklungszyklus besprochen wurden. Der erste Abschnitt des Backlogs führt die Erkenntnisse dieser Diskussion auf. Im zweiten Abschnitt wurden konkrete Aufgaben abgeleitet, die im aktuellen oder einem folgenden Entwicklungszyklus bearbeitet werden sollten. Im dritten Abschnitt wurde der Fortschritt des aktuellen Zyklus festgehalten. Der letzte Abschnitt enthält Hinweise auf Umstände, die genauer dokumentiert werden müssen, da sie für die Erweiterung des Programms wichtig sind oder weil benutzte Ressourcen aus fremden Quellen stammen, deren Ursprung dokumentiert werden musste. Die Backlogs der einzelnen Entwicklungszyklen sind auf der beiliegenden CD im Unterverzeichnis Backlog einsehbar (siehe Anhang A.4). 5.2 Projektplan Das Projekt wurde zunächst auf vier Entwicklungszyklen geschätzt, wobei in einem anschließenden fünften Entwicklungszyklus noch Änderungen vorgenommen werden konnten. Die Entwicklungszyklen sollten eine Dauer von ca. einem Monat haben. Am Anfang jedes Entwicklungszyklus stand eine Diskussion in Form eines Brainstormings, in dem alle Ideen für die Umsetzung der aktuellen Aufgaben gesammelt wurden. Außerdem wurde das Ergebnis des vorherigen Zyklus untersucht. 5.3 Entwicklungsressourcen Für die Entwicklung stand Microsoft Visual Studio 2008 zur Verfügung. Als Testumgebung konnte Office 2007 sowohl unter Windows XP als auch unter Windows Vista herangezogen werden. Während der Entwicklung wurden weitere Programme und Ressourcen

59 Lösungsansatz 59 benutzt (siehe Anhang A.2). Die kommerziellen Programme Microsoft Visio 2007 und Paint Shop Pro 8 wurden für die Bearbeitung der EMF-Kartengrafiken und der sonstigen Icons und Grafiken benutzt, prinzipiell können dafür aber auch freie Alternativen eingesetzt werden. 5.4 Programmierrichtlinien Gerade bei Projekten, die von mehreren Personen bearbeitet werden, ist es wichtig, Programmierrichtlinien festzulegen. Auch wenn ein Teil des Projekts von nur einer Person behandelt wird, ist es wahrscheinlich, dass andere Personen diesen Teil später pflegen, weiterentwickeln oder in anderen Projektteilen benutzen werden. Durch einheitliche Richtlinien kann die Lesbarkeit und damit die Wartbarkeit des Sourcecodes verbessert werden. Bei der Entwicklung des E-Learning Toolkits wurden deshalb die folgenden Richtlinien befolgt: Bezeichner, Klassennamen und Methodennamen sind nach Möglichkeit auf Englisch zu formulieren. Englische Begriffe sind in der Regel kürzer als deutsche Begriffe, und eine Mischung aus Deutsch und Englisch ist für die Lesbarkeit nicht günstig. Wenn vorhandene Klassen erweitert werden, ist es außerdem notwendig, die ursprünglich benutzten Methodennamen zu überschreiben. Falls ein englischer Begriff wenig gebräuchlich ist, kann die deutsche Bedeutung in einem Kommentar angegeben werden. Programmkommentare werden auf Deutsch formuliert. Während die Benennung von Bezeichnern auf Englisch aus den oben genannten Gründen sinnvoll ist, wurde für diese Arbeit festgelegt, dass die Programmkommentare auf Deutsch verfasst werden sollen. Falls ein Projekt international weiterentwickelt werden soll, wäre natürlich auch hier die Verwendung der englischen Sprache angebracht. Die Quelltextformatierung wird auf einen Java-ähnlichen Stil umgestellt. Dies ist eher eine Frage des persönlichen Stils. Das Belassen von geschweiften Klammern auf der entsprechenden Zeile (wie in if ( ) { ) spart eine Zeile ein. Die Standardeinstellungen des Quelltexteditors von Visual Studio müssen dann allerdings geändert werden. Die XML-Dokumentation soll genutzt werden. Visual Studio unterstützt Entwickler durch die automatische Generierung von XML- Tags für die Programmdokumentation (siehe Kapitel 2.4). Weiterhin wird das Fehlen von Kommentaren beim Kompilieren als Warnung angezeigt, wenn in den Projekteigenschaften die XML-Dokumentation aktiviert wurde. Die angegebenen Kommentare werden beispielsweise in der automatischen Textvervollständigung des Quelltexteditors von Visual Studio angezeigt, was die Programmierung enorm vereinfacht. Die Erstellung der XML- Dokumentation muss für alle Unterprojekte in den Projekteigenschaften aktiviert werden.

60 Implementierung 60 6 Implementierung Das E-Learning Toolkit wurde in fünf Entwicklungszyklen implementiert, die jeweils den Umfang eines Monats hatten. Im ersten Entwicklungszyklus wurden grundlegende Funktionen bearbeitet. Die hauptsächliche Entwicklung fand in den folgenden drei Zyklen statt. Der letzte Entwicklungszyklus war für Aufgaben vorgesehen, die aus Zeitgründen in den vorangehenden Zyklen nicht mehr berücksichtigt wurden, sowie für die Verbesserung von Aspekten, die bei der Evaluierung des Programms bemängelt wurden. Die vollständige Liste der Unterprojekte und aller entwickelten Klassen befindet sich in Anhang A.3. Die erstellten Vorlagen und Datendateien werden dort ebenfalls aufgeführt. 6.1 Zyklus 1 Beim ersten Entwicklungszyklus standen grundlegende Konzepte im Vordergrund. Für die Planung der weiteren Entwicklung war es wichtig, ein prototypisches Add-In für Power- Point 2007 zu entwickeln. Um sicherzustellen, dass die Grundaufgaben von ETK mit den gewählten Methoden erfüllt werden können, sollte dieses Add-In demonstrieren, wie Objekte innerhalb von PowerPoint-Präsentationen manipuliert werden können. Eine weitere wichtige Grundlage war eine Komponente, um PBN-Dateien einzulesen. Alle Funktionen in den folgenden Entwicklungszyklen sollten nach Möglichkeit mit entsprechenden PBN-Dateien getestet werden, weil auf diese Weise am einfachsten eine Vielzahl von Sonderfällen behandelt werden konnte. Die Ausweitung auf das Spiel Poker wurde zunächst zurückgestellt, bis eine funktionierende Komponente für Bridge fertiggestellt war. Zum Abschluss des ersten Zyklus wurde ein Prototyp für das Bridge-Abspiel als Mock- Up in PowerPoint erstellt. Anhand des Prototypen konnte das weitere Vorgehen für den zweiten Entwicklungszyklus diskutiert werden Aufgabenplanung Im ersten Interview mit dem Auftraggeber wurden in einem Brainstorming alle Ideen festgehalten, welche Funktionen im Programm zur Verfügung stehen sollen und wie diese am besten implementiert werden können. Dabei war es wichtig, auch alternative Vorgehensweisen zu berücksichtigen. Bei einem Programm wie ETK, das sehr stark von einer anderen Software und dessen Schnittstellen abhängt, kann nicht in jedem Fall davon ausgegangen werden, dass sich Funktionen wie beabsichtigt realisieren lassen. Im ersten Zyklus waren viele Faktoren noch nicht endgültig entschieden und es wäre durchaus noch denkbar gewesen, Änderungen an den gewählten Entwicklungstools, am Projektplan oder auch an der Aufgabenstellung vorzunehmen. Der große Vorteil bei diesem Ansatz war,

61 Implementierung 61 dass möglicherweise auftretende grundsätzliche Probleme schon sehr frühzeitig mit dem Auftraggeber besprochen werden konnten. Die Hauptaufgabe von ETK ist es, programmgesteuert Inhalte in PowerPoint-Präsentationen einzufügen. Als Inspiration dienten dabei die SmartArt-Elemente (siehe Kapitel 2.3.1), bei denen ebenfalls eine vorgegebene Struktur mit benutzerdefinierten Daten ausgestaltet wird. Eine Idee beim Brainstorming war, den späteren Benutzern die Möglichkeit einzuräumen, diesen Prozess nach ihren eigenen Vorstellungen zu verändern. Dies lässt sich dadurch realisieren, dass Vorlagen für die einzufügenden Inhalte ebenfalls als Power- Point-Dateien vorliegen. So können die Benutzer auf gewohnte Weise daran Änderungen vornehmen und es muss keine Funktion zur Anpassung der Vorlage programmiert werden. Die grundlegende Arbeitsweise von ETK sollte also so ablaufen, dass Vorgaben aus einer Vorlagendatei eingelesen werden und entsprechend den Daten einer PBN-Datei auf eine bestimmte Spielsituation angepasst werden. Der erzeugte Inhalt wird anschließend in die Zielpräsentation eingefügt. Dazu ist es notwendig, die Objekte der Vorlage gezielt, am besten über einen eindeutigen Namen, zu referenzieren. Als erste Aufgabe bot es sich also an, ein PowerPoint Add-In zu implementieren, mit dessen Hilfe den Shapes in einer PowerPoint-Datei eindeutige Namen zugewiesen werden können, weil diese Funktion eine Voraussetzung für das Erstellen der Vorlagen ist. Die Darstellung von Spielsituationen sollte interaktiv ablaufen und es sollte möglich sein, eine Bridge-Partie komplett nachzuspielen, so wie sie in der PBN-Datei abgespeichert ist. Diese Grundaufgabe sollte im ersten Entwicklungszyklus durch eine manuell erstellte PowerPoint-Präsentation demonstriert werden. Noch sehr viel wertvoller für den Unterricht ist es natürlich, bei der Präsentation auch alternative Spielwege oder das völlig freie Spiel zeigen zu können. Dies übersteigt allerdings die Möglichkeiten der PowerPoint- Animationen und konnte nur über VBA-Makros realisiert werden. Die Ansätze zur Darstellung von freien Spielabläufen sollten in einem späteren Entwicklungszyklus weiter verfolgt werden. Eine notwendige Basiskomponente für die weitere Entwicklung war die PBN-Komponente. Zunächst war es geplant, das Einlesen von PBN-Dateien zu unterstützen, damit weitere Programmkomponenten diese Daten verarbeiten können. Um die Komponente testen zu können, sollte ein einfaches Testprogramm implementiert werden. Für spätere Entwicklungszyklen wurde geplant, die PBN-Komponente so zu erweitern, dass PBN- Dateien erstellt oder verändert und abgespeichert werden können. Wünschenswert war es außerdem, ein Programm zu entwickeln oder einzubinden, mit dem Kartenverteilungen erzeugt und durch Double-Dummy-Analyse (siehe Kapitel 2.2.3) untersucht werden können. Eine weitere Voraussetzung für spätere Entwicklungsschritte waren die grafischen Elemente, die in die Präsentationen eingefügt werden sollen, vor allem die Grafiken für die Spielkarten. Diese sollten in verschiedenen Auflösungen gut lesbar sein, da davon auszugehen war, dass die Präsentationen im Unterricht auch über Beamer präsentiert werden. Aus diesem Grund sollten nach Möglichkeit Vektorgrafiken zum Einsatz kommen, da diese für verschieden Auflösungen skaliert werden können, ohne zu sehr an Detailgrad zu verlieren.

62 Implementierung 62 Obwohl zunächst nur ein Kartensatz erstellt wurde, sollte es grundsätzlich möglich sein, verschiedene Kartensätze mit unterschiedlichen Kartendarstellungen zu verwenden, von denen beim Einfügen von Spielsituationen ein Kartensatz ausgewählt wird. Außerdem sollten Karten sowohl in deutscher Schreibweise (B, D, J, A) als auch in englischer Schreibweise (J, Q, K, A) verwendet werden können. Optional sollten verschiedene Kartenrückseiten verwendet werden können. Im ersten Entwicklungszyklus wurde die folgende Aufgabenplanung als Grundlage für das Backlog erstellt (Tabelle 6.1): Aufgabe Zyklus Entwicklung eines PowerPoint Add-Ins in Visual Studio 2008 als Prototyp: Shapes umbenennen 1 Mock-Up Bridge Abspiel als Prototyp 1 Entwicklung der Bridge-Komponente: Anzeige von PBN-Dateien als Baumstruktur. Durch 2 Klicken auf Elemente sollen die entsprechenden Inhalte in die aktuelle Präsentation eingefügt werden. Entwicklung der Poker-Komponente: Erzeugen und Anzeige von Pokerpartien 4 Kartengrafiken Kartengrafiken als Vektorgrafik 1 Funktion zum Einfügen einzelner Karten implementieren 2 Organisation der Kartengrafiken als Kartensatz-Komponente 2 PBN Import Komponente für Bridge PBN-Dateien einlesen 1 Testprogramm 1 PBN-Dateien speichern 3 Kartenverteilungen erzeugen 3 Double-Dummy Analyse 3 Vorlagen Bridge-Abspiel mit festem Ablauf 2 Freies Bridge-Abspiel mit Makros 3 Bridge-Reizung mit festem Ablauf 3 Freie Bridge-Reizung mit Makros 3 Bridge-Hände anzeigen 3 Bridge Bewertungsquiz für Hände 3 Poker Spielverlauf anzeigen 4 Poker freier Spielverlauf mit Makros 4 Poker Hände anzeigen 4 Tabelle 6.1: Backlog Zyklus 1

63 Implementierung Implementierung Gemäß Tabelle 6.1 wurden im ersten Entwicklungszyklus die folgenden Aufgabenbereiche bearbeitet: Kartengrafiken Für die Kartengrafiken sollte ein Vektorgrafikformat benutzt werden. In [13] befindet sich ein Hinweis auf das Paket svgcards von David Bellot [46], das Grafiken für Spielkarten im SVG-Format enthält. SVG (scalable vector graphics) ist ein vektorbasiertes Grafikformat, das vom W3C (World Wide Web Consortium, siehe [47]) als Standard etabliert wurde. Die Kartengrafiken können gemäß der GNU Lesser General Public License (LGPL) (siehe Anhang A.2) auch in eigenen Projekten verwendet werden und abgeändert werden. Die veränderten Karten müssen allerdings ebenfalls unter der LGPL-Lizenz freigegeben werden. Da PowerPoint das SVG-Format nicht unterstützt, mussten die Kartengrafiken in ein anderes Format umgewandelt werden. Gewählt wurde das Format Enhanced Metafile (EMF), das sowohl von PowerPoint als auch von OpenOffice Impress (siehe Kapitel 2.3.4) unterstützt wird. Für die Umwandlung wurde das Programm Microsoft Visio 2007 benutzt (siehe Anhang A.2). Erstellung eines Mock-Ups zur Darstellung des Bridge-Abspiels Unter Benutzung der EMF-Kartengrafiken wurde eine Beispielpräsentation erstellt, die zeigt, wie ein Stich beim Abspiel dargestellt werden kann. Dabei wurden einige grundlegende Techniken demonstriert: Auslösung von Animationen durch Mausklick, Folgen von Animationen, die gleichzeitig oder nacheinander abgespielt werden, Bewegung von Shapes und das Entfernen von Shapes mit einer Animation des Typs Beenden. Implementierung eines PowerPoint Add-Ins zum Umbenennen von Shapes Mit Hilfe des SDKs Visual Studio Tools for Office 3.0 (VSTO), das ein Bestandteil von Visual Studio 2008 ist (siehe Kapitel 2.4), können Add-Ins für Microsoft Office entwickelt werden. Bei der Erstellung eines neuen Projekts in Visual Studio kann eine Projektvorlage für ein PowerPoint-Add-In gewählt werden. Es wird dann ein Projekt mit vorgefertigtem Programmcode erstellt, der bereits alle nötigen Verweise enthält. Die weitere Vorgehensweise zur Implementierung eines Add-Ins wird in [12] ausführlich beschrieben. Alle Funktionen des E-Learning Toolkits sollten auf diese Weise in die Oberfläche von PowerPoint integriert und über das in dem Unterprojekt ETKPPAddIn erstellte Add-In aufgerufen werden. Im ersten Zyklus wurde zunächst ein einfaches Add-In implementiert, um Erfahrungen mit dieser Technologie zu sammeln und die Entwicklung der Komponenten für Bridge und Poker planen zu können. Shapes in PowerPoint-Präsentationen erhalten bei der Erstellung automatisch einen Namen (z. B. Grafik 34 ). Dieser Name ist für Benutzer normalerweise nicht sichtbar und kann über die Programmoberfläche von PowerPoint nicht geändert werden. In ETK sollten Shapes über einen eindeutigen Namen referenziert werden. Dazu war es notwendig,

64 Implementierung 64 dass Shapes in Vorlagen entsprechend umbenannt werden können. Als Aufgabe für das prototypische Add-In bot es sich also an, eine Komponente zu implementieren, mit der die Namen von Shapes angezeigt und vom Benutzer verändert werden können. Um die Komponente in der Multifunktionsleiste von PowerPoint aktivieren zu können, wurde in der Klasse Ribbon1 eine Schaltfläche entworfen, die unter dem Punkt Add-Ins von PowerPoint angezeigt wird. Mit dieser Schaltfläche wird das Steuerelement Renamer- Control angezeigt. Beim Anlegen des PowerPoint Add-In-Projekts wurde von Visual Studio ein temporäres Sicherheitszertifikat angelegt. Während der Installation des E-Learning Toolkits wird deshalb ein Unbekannter Herausgeber angezeigt, wenn die Bestätigung des Benutzers zur Aktivierung des Add-Ins angefordert wird. Ein signiertes Sicherheitszertifikat kann in dieser Arbeit nicht veröffentlicht werden, weil damit jeder unter dem im Zertifikat gespeicherten Namen auftreten und möglicherweise schädlichen Programmcode verbreiten könnte. PBN-Importkomponente Eine wichtige Grundlage für die weitere Implementierung war die PBN-Importkomponente. Damit wurde nicht nur eine Datenstruktur für Bridge festgelegt, mit Hilfe von PBN-Dateien sollten auch alle weiteren Funktionen für Bridge getestet werden. Es war also sehr wichtig, dass nicht schon beim Einlesen von PBN-Dateien Daten verfälscht werden. Aus diesem Grund wurde neben der Importkomponente ein Testprogramm implementiert, mit dem kontrolliert werden konnte, ob der Inhalt einer PBN-Datei korrekt eingelesen wurde. Entsprechend der PBN-Spezifikation [24] mussten viele Sonderfälle beachtet werden, für die Testdateien erstellt wurden. Die Klasse PBNFile entspricht einer PBN-Datei und enthält eine Sammlung von Game-Objekten, die jeweils ein Spiel beschreiben. Auf die Liste kann über die IEnumerable-Schnittstelle zugegriffen werden. Durch das erzeugen eines PBNFile-Objekts wird die PBN-Datei eingelesen. Falls beim Einlesen Fehler auftreten, werden diese in einer Fehlerliste gespeichert, die über die Methode geterrorlist abgerufen werden kann. Das Einlesen der PBN-Datei soll bei Fehlern so weit wie möglich fortgesetzt werden. Nach der PBN-Spezifikation kann eine PBN-Datei als eine Abfolge von Tokens aufgefasst werden. Manche Tokens haben für sich genommen eine Bedeutung, andere Tokens ergeben zusammengesetzt ein logisches Element (z. B. ein TagPair, das aus dem Token [, einem Namen, einem oder mehreren Leerzeichen, einem String-Token und dem Token ] besteht). Mit der Klasse PBNTokenizer wird eine PBN-Datei eingelesen und in logische Elemente aufgeteilt. Mit der statischen Methode parse in der Klasse Game werden die Elemente eines Spiels eingelesen und in den passende Objekten gespeichert. Alle Bestandteile eines Spiels sind vom Typ Element. Die Unterklassen AuctionCall, Card, Comment, Escape, GameSeperator, Irregularity, NAG, Note und TagPair stehen dabei für bekannte Tokens (siehe Kapitel 2.2.2). Die Klasse TagPair spaltet sich weiterhin in die Unterklassen Contract, Deal, Result und Vulnerable auf, die verwendet werden, wenn das TagPair den jeweiligen Inhalt

65 Implementierung 65 enthält. Die Hilfsklasse Trick enthält die gespielten Karten eines Stichs, ist selber aber nicht vom Typ Element.. Die Zuordnung der eingelesenen Tokens zu Klassen geschieht über eine der statischen Methoden getnextelement, getnextelementauction und getnext- ElementPlay in der Klasse Element. Die Vererbungshierarchie der Klassen wird in Abbildung 6.1 gezeigt. Abbildung 6.1: Klassendiagramm PBN-Komp Komponente Die Klasse PBNStrings enthält alle in der PBN-Komponente benutzten Zeichenfolgen und soll eine spätere Übersetzung des Programms vereinfachen. In der Klasse Const werden Konstanten und Aufzählungstypen definiert, die verhindern sollen, dass in den Klas- sen der Bridge-Komponente inkonsistente Reihenfolgen oder Bezeichnungen verwendet werden. Die Ausnahme PBNException wird für Fehlersituationen beim Einlesen von PBN-

66 Implementierung 66 Dateien verwendet. Die Klasse Scoring stellt Methoden bereit, mit denen die Punktabrechnung für ein Bridgespiel berechnet werden kann. Das Testprogramm PBNTest wurde als Konsolenprogramm entwickelt. Es liest die als Parameter angegebene PBN-Datei ein und gibt die interpretierten Daten aus. Die Programmausgabe kann über das Umleitungssymbol > in eine Datei geschrieben werden. Zusammenfassung Die folgenden Projekte in der Projektmappe ETK wurden im ersten Entwicklungszyklus erstellt: ETKPPAddIn Enthält das prototypische Add-In zur Umbenennung von Shapes. PBN PBNTest Die PBN-Importkomponente. Testprogramm für das Paket PBN. Außerdem wurde die Präsentation Bridge-Mockup.pptx erstellt (siehe Anhang A.4) Tests Zum Testen der PBN-Komponente wurden die folgenden Testdateien erstellt: test1-1.pbn: test1-2.pbn: test1-3.pbn: test1-4.pbn: test1-5.pbn: test1-6.pbn: test1-7.pbn: test1-8.pbn: Die Datei wurde aus der PBN-Spezifikation entnommen und enthält ein Spiel mit Anmerkungen in den Abschnitten Auction und Play. Testet verschiedene syntaktische Regeln und Fehler (z. B. nicht abgeschlossene Kommentare). Enthält mehrere Spiele, wobei das Festlegen von Standard-Tags, NAGs und Irregularities getestet werden. Testet die Neudefinition von Standard-Tags. Testet Einträge für den Supplemental-Abschnitt und TagPairs, die über mehrere Zeilen gehen. Testet Anmerkungen mit zwei- oder dreistelligen Schlüsseln. Testet minimale Dateien für die Reizung und das Abspiel. Testet Anmerkungen, die Umlaute enthalten. Die Testdateien und Testprotokolle sind im Unterverzeichnis Testdateien der beiliegenden CD einsehbar (siehe Anhang A.4).

67 Implementierung Ergebnis Alle in Tabelle 6.1 für den ersten Entwicklungszyklus vorgesehenen en Aufgaben wurden bearbeitet. Anhand des erstellten Mock-Ups konnte die Darstellung der Kartengrafiken und der beabsichtigte Einsatz von Animationen demonstriert werden (siehe Abbildung 6.2). Außerdem konnten Shapes mit Hilfe des entwickelten Shape Renamer Add-Ins umbenannt werden. Abbildung 6.2: Bridge Abspiel Mock-Up in PowerPoint Obwohl die Darstellung des Mock-Ups in OpenOffice Impress generell gelang, wurden einige Unterschiede deutlich. Die Ziffern und Symbole der Spielkarten waren etwas zu groß, so dass für Impress möglicherweise separate Kartengrafiken erstellt werden müssten. Entscheidend war allerdings ein Darstellungsfehler, lungsfehler, der nur während der Anzeige der Animationen auftrat (siehe Abbildung 6.3). Es wäre also notwendig gewesen, für Impress eine eigene Methode zur Darstellung der Animationen zu implementieren. Aufgrund der Open Source-Natur von OpenOffice wäre es außerdem möglich, zusammen mit der Ent- wicklergemeinde an der Lösung des Problems zu arbeiten. Mit dem E-Learning Toolkit Material zu erstellen, das sowohl mit PowerPoint als auch mit Impress dargestellt werden kann, schien aber zunächst nicht möglich, und der nötige Aufwand würde den Rahmen dieser Arbeit übersteigen. Aus diesem Grund wurden weitere Tests mit Impress nicht durchgeführt und eine mögliche Anpassung des E-Learning Toolkits für OpenOffice Impress als Aufgabe für zukünftige Arbeiten angesehen.

68 Implementierung 68 Abbildung 6.3: Bridge Abspiel Mock-Up in Impress 6.2 Zyklus 2 Im zweiten Zyklus wurde mit der Implementierung der Bridge-Komponente begonnen. Zunächst sollte das Bridge-Abspiel mit festem Spielverlauf aus einer PBN-Datei eingelesen und in die Präsentation eingefügt werden. Außerdem wurden eine Komponente zum Einfügen einzelner Spielkarten und ein Installationsprogramm für das E-Learning Toolkit implementiert Diskussion Ausgehend von der Evaluation des im ersten Entwicklungszyklus erstellten Mock-Ups wurde das gewünschte Aussehen für die Darstellung des Abspiels diskutiert. Neben den bereits enthaltenen Elementen Stichzähler und Kontrakt sollten noch die Boardnummer, die Gefahrenlage und die Position des Teilers angezeigt werden. Die Kartendarstellung im Mock-Up entspricht schematisch dem Aussehen des Tisches bei einer normalen Bridge- Runde, wobei der Dummy-Spieler die Karten nach Farben sortiert auf dem Tisch auslegt. Die Dummy-Karten würden bei dieser Vorlage aber immer am oberen Bildschirmrand angezeigt werden, auch wenn der Dummy-Spieler nicht in Position Nord ist. Deshalb sollte eine weitere Vorlage erstellt werden, bei der die Dummy-Karten wie die Karten der anderen Spieler dargestellt werden. Damit kann statt des Dummy-Spielers der tatsächliche Spieler in Position Nord am oberen Bildschirmrand angezeigt werden. Weiterhin sollte die Darstellungsweise in der Software Bridge Base Online (siehe Kapitel 3.6) untersucht werden, um eine entsprechende Vorlage für ETK zu erstellen. Um Vorlagen leichter auswählen zu können, sollte von der jeweils gewählten Vorlage und vom gewählten Kartensatz eine Vorschaugrafik angezeigt werden.

69 Implementierung 69 Damit die Kartengrafiken sowohl von der Komponente zum Einfügen einzelner Karten als auch von der Bridge-Komponente (und später von der Poker-Komponente) genutzt werden können, sollte die Verwaltung der Kartengrafiken als eigenständiges Modul implementiert werden. Nachdem eine PBN-Datei durch die Bridge-Komponente geladen wurde, sollten die enthaltenen Informationen in einer Baumstruktur angezeigt werden. Dabei sollte ein einzelnes Spiel ausgewählt werden können und der Spielablauf durch Anklicken des entsprechenden Abschnitts der PBN-Ansicht in die Präsentation eingefügt werden. Außerdem sollte eine Funktion implementiert werden, mit der gesteuert werden kann, welche Stiche angezeigt werden. Es sollte möglich sein, Stiche am Beginn des Abspiels zu überspringen und weitere Stiche im Schnelldurchgang anzuzeigen, falls sie für die Darstellung eines bestimmten Sachverhalts nicht von Bedeutung sind. Die Karten der ausgewählten Stiche sollen hingegen nur bei Mausklick abgespielt werden. Die Geschwindigkeit der Animationen sollte in beiden Fällen einstellbar sein. Außerdem sollten die in der PBN-Datei gespeicherten Kommentare angezeigt werden, wenn die betreffende Karte gespielt wurde. Weil im normalen Bridgespiel die Karten nicht offen gezeigt werden, sollte es weiterhin möglich sein, nur die Karten ausgewählter Spieler anzuzeigen (z. B. nur die Karten des Alleinspielers und des Dummy-Spielers). In der Diskussion zum zweiten Entwicklungszyklus wurden Ideen gesammelt, wie es später möglich sein könnte, alternative Spielabläufe zu erstellen und zu speichern. Als mögliche Herangehensweise wurde dabei vorgeschlagen, dass bei einer freien Durchführung des Abspiels der Spielverlauf aufgezeichnet und zur späteren Verwendung als PBN-Datei abgespeichert wird. Da das Add-In nur auf dem Entwicklungsrechner direkt in PowerPoint eingesetzt werden konnte, sollte ein Installationsprogramm erstellt werden, das das E-Learning Toolkit zusammen mit weiteren erforderlichen Softwarekomponenten installiert. Die späteren Benutzer sollten das Programm so auf einfache Weise installieren können, ohne weitere Komponenten einrichten zu müssen.

70 Implementierung Aufgabenplanung Aus den geplanten Aufgaben wurde das folgende Backlog für den zweiten Entwicklungszyklus erstellt (Tabelle 6.2): Aufgabe Zyklus Entwicklung des Installationsprogramms 2 Entwicklung der Bridge-Komponente: Anzeige von PBN-Dateien als Baumstruktur. Durch 2 Klicken auf Elemente sollen die entsprechenden Inhalte in die aktuelle Präsentation eingefügt werden. Organisation der Kartengrafiken als Kartensatz-Komponente 2 Funktion zum Einfügen einzelner Karten implementieren 2 Aufzeichnen von Reizabläufen und Spielabläufen und Speichern als PBN-Dateien 4 Vorlagen Bridge-Abspiel mit festem Ablauf ohne Makros Erstellen einer Vorlage mit festem Dummy in Position Nord. Die Karten des Dummy- 2 Spielers sollen nach Spielfarben getrennt angeordnet werden. Erstellen einer Vorlage mit Spielern in ihren tatsächlichen Positionen. 2 Erstellen einer Vorlage, die an die Darstellung bei BBO angelehnt ist. 2 Karten von Spielern wahlweise verdecken 2 Anzeige des Spiels erst ab einem bestimmten Stich 2 Ausgewählte Stiche manuell oder automatisch abspielen 2 Geschwindigkeit der Animationen einstellbar 2 Anzeige von Kommentaren (Notes und NAGs) 2 Anzeige einer Vorschau für die gewählte Vorlage und den gewählten Kartensatz 2 Tabelle 6.2: Backlog Zyklus Implementierung Bei der Entwicklung des Installationsprogramms waren die Hinweise aus [12] äußerst hilfreich. Damit die erforderlichen Komponenten.Net Framework 3.5, VSTO 3.0 Runtime und Office 2007 PIAs durch das Installationsprogramm installiert werden konnten, mussten Einstellungen an der Entwicklungsumgebung vorgenommen werden (siehe Anhang A.2.1). Nützlich war dabei das Programm Bootstrapper Manifest Generator (siehe Anhang A.2), mit dem die Komponente Office 2007 PIAs zum Katalog der verfügbaren Installationspakete hinzugefügt wurde. Durch das Hinzufügen der Projektausgabe des Projekts ETKPPAddIn, das Verweise auf alle anderen Komponenten enthält, wurden die Projektabhängigkeiten automatisch erkannt. Die Abhängigkeiten von den Microsoft- Programmbibliotheken mussten jedoch ausgeschlossen werden, da sie durch die Komponente Office 2007 PIAs erfüllt wurden. Die von den einzelnen Komponenten benötigten Datendateien wurden nicht automatisch hinzugefügt. In der Projektansicht konnte aber festgelegt werden, dass sie als Inhaltsdateien gehandhabt werden und durch Hinzufügen der Inhalts-Projektausgabe zum Setup-Projekt hinzugefügt werden. Auf diese Weise wurden auch die Dateien über-

71 Implementierung 71 nommen, die nachträglich hinzugefügt wurden. Eine Übersicht der Datendateien befindet sich in Anhang A.3.4. Die beiden Dateien ETKPPAddIn.vsto und ETKPPAddIn.dll.manifest werden beim Kompilieren des Projekts ETKPPAddIn im Ausgabeverzeichnis erstellt. Diese Dateien sind für die Ausführung des Add-Ins notwendig, werden aber durch die Projektausgabe nicht automatisch zum Setup-Projekt hinzugefügt. Sie mussten deshalb manuell hinzugefügt werden. Da es jedoch nicht möglich ist, das Verzeichnis der hinzugefügten Dateien je nach Erstellungskonfiguration (Debug oder Release) anzugeben, wurde in den Projekteinstellungen festgelegt, dass die Projektausgabe von ETKPPAddIn stets in das Unterverzeichnis bin ausgegeben werden soll. So sind die betreffenden Dateien unabhängig von der Konfiguration immer im selben Verzeichnis. Komponente für Kartengrafiken und Funktion zum Einfügen einzelner Karten Die Komponente zur Verwaltung von Kartengrafiken Cards ermittelt die Dateinamen der Kartengrafiken, damit sie in die Präsentation eingefügt werden können. Dabei sollten Funktionen zur Auswahl des Kartensatzes, der verwendeten Kartenrückseite und der benutzten Sprache implementiert werden. Ein Kartensatz wird durch die abstrakte Klasse CardSet dargestellt. Mit der statischen Methode getcardset wird eine Instanz einer konkreten Unterklasse zurückgegeben, die dem gewählten Kartensatz entspricht. Die Komponente enthält weiterhin die Klasse SelectCardSetWindow, mit der ein Fenster zum Auswählen des Kartensatzes angezeigt werden kann. Die erste Anwendung für die Komponente Cards war die CardInserter-Komponente. Diese sollte alle Karten eines Kartensatzes auflisten und bei Mausklick die ausgewählte Karte in die Präsentation einfügen. So konnte auch auf einfache Weise die Komponente Cards getestet werden. Die einzige Klasse der CardInserter-Komponente ist ein Steuerelement, das in der PowerPoint-Oberfläche angezeigt wird. Weil die Auswahl des Kartensatzes im Steuerelement enthalten ist, wird die Klasse SelectCardSetWindow aus der Cards- Komponente nicht benötigt. Bridge-Komponente Für das Bridge-Steuerelement BridgeControl wurde zuerst die Anzeige von PBN-Dateien implementiert. Falls beim Einlesen einer Datei Fehler auftreten, werden sie in einer Loganzeige aufgelistet. Im Verzeichnis, in dem das E-Learning Toolkit installiert ist, wird außerdem eine Logdatei ETK.log geführt, die für die Fehlersuche hilfreich ist. Das zentrale Element der Bridge-Komponente ist eine Baumansicht der in der PBN- Datei enthaltenen Spiele. Diese dient gleichzeitig zur Auswahl der Programmfunktionen, die ausgeführt werden sollen. Dazu wurde die.net-klasse TreeView durch die Klasse CustomTreeView erweitert. Zusammen mit der Klasse CustomTreeNode ist es möglich, Knoten in der Baumansicht anzuzeigen, die darauf reagieren, wenn mit der Maus auf sie gezeigt oder geklickt wird, und die wahlweise eine eigene Methode zur Darstellung des Inhalts implementieren. Die beiden Klassen befinden sich im Namespace Bridge.CustomUI. Im Namespace PBNTree sind die Klassen enthalten, die CustomTreeNode erweitern und den Inhalt der PBN-Datei anzeigen. Zur besseren Übersicht zeigt jeder Knoten ein Icon

72 Implementierung 72 an, das in der Klasse Images aufgelistet ist. Die entsprechenden Grafiken wurden als Ressourcen zum Projekt hinzugefügt (in den Projekteinstellungen), wodurch sie automatisch in das Unterverzeichnis Resources kopiert wurden (siehe Anhang A.3.4). Im zweiten Entwicklungszyklus wurde zunächst die Klasse PlayTreeNode, mit der das Abspiel in der PBN-Ansicht angezeigt wird, darauf ausgelegt, auf Mausklicks zu reagieren. Beim Anklicken des Knotens wird das Fenster SetupWindow aus dem Namespace Bridge.BridgeTemplates.Play BridgeTemplates.Play angezeigt. In diesem Fenster kann eine der im folgenden Absatz beschriebenen Vorlagen ausgewählt werden, die für das Einfügen des Abspiels verwendet werden soll. Die Vorlage wird im Fenster als Miniaturansicht angezeigt. Vorlagen für das Abspiel Für das Abspiel wurden drei Vorlagendateien erstellt. Die erste Vorlage stellt die Karten des Dummy-Spielers am oberen Bildschirmrand spaltenweise nach Spielfarben getrennt dar. Die Karten der übrigen Spieler werden in einer Reihe dargestellt, wobei zwischen den einzelnen Spielfarben ein Zwischenraum gelassen wird. Bei der zweiten Vorlage wird auch der Dummy-Spieler auf diese Weise dargestellt, wodurch er an einer anderen Position der Vorlage eingefügt werden kann. Die dritte Vorlage orientiert sich an der Darstellung bei Bridge Base Online (siehe Kapitel 3.6). Diese Darstellung ist übersichtlich und platzspa- rend, zwischen den Spielfarben wird allerdings kein Zwischenraum gelassen. In den Vorlagen müssen alle Kartenverteilungen darstellbar sein. Für die Karten der Spieler sind deshalb Platzhalter vorhanden, die alle Möglichkeiten abdecken (siehe Abbildung 6.4). Wenn zwischen den Spielfarben jeweils zwei Karten freigelassen werden sollen (wie in Abbildung 6..2), müssen Platzhalter für 19 Karten vorhanden sein (für maxi- mal drei Zwischenräume von je zwei Karten und 13 Handkarten). Bei der Verarbeitung der Vorlage werden die tatsächlich genutzten Spielkarten eingefügt. Welcher Zwischen- raum gelassen wird und ob die Dummy-Karten aufgeteilt werden sollen, bestimmt die Anzahl der Platzhalter in der Vorlage. Damit die entsprechenden Shapes referenzierbar sind, wurde ihnen bei der Erstellung der Vorlage mit der ShapeRenamer-Komponente ein eindeutiger Name gegeben. Abbildung 6.4: Bridge Abspiel Vorlage

73 Implementierung 73 In Abbildung 6.4 sind weitere Elemente zur Darstellung des Spielverlaufs zu sehen. Oben links ist die Anzeige des Teilers und der Gefahrenlage. Der Text wird den aus der PBN-Datei eingelesenen Daten entsprechend geändert und der Hintergrund rot eingefärbt, wenn ein Spieler sich in Gefahr befindet. Ebenfalls zu sehen sind die Anzeige des Kontrakts in der unteren linken Ecke und die Stichzähler beider Parteien in der unteren rechten Ecke. Weitere Elemente sind die Bezeichner der Spieler, eine Textbox für Anmerkungen und die Ablageplätze der Karten. Durch die Ablageplätze wird lediglich eine Position markiert, an die bei der Darstellung des Abspiels die Karten des jeweiligen Spielers bewegt werden. Shapes in der Vorlage können also sowohl für ein einzufügendes Objekt stehen, als auch eine Position für die Bewegung festlegen. Die Boardnummer kann schließlich in der Titelzeile angezeigt werden. Die Klasse Template im Namespace Bridge.BridgeTemplates.Play wird von der Klasse SetupWindow für das Einfügen einer Abspiel-Vorlage benutzt. Dabei können im Setup- Fenster Einstellungen vorgenommen werden, beispielsweise das Verdecken eines Spielers. Dazu werden die Spielkarten als Kartenrückseiten eingefügt, so dass der Betrachter nur die Anzahl der Karten eines Spielers sehen kann. Die Kartenvorderseiten werden ebenfalls eingefügt, sind zunächst aber unsichtbar und werden immer von der Mitte der Hand aus abgespielt, da sonst leicht zu sehen wäre, wie viele Karten einer Farbe ein Spieler hält. Weitere Einstellungen im Setup-Fenster verändern den benutzten Kartensatz und legen fest, welche Stiche angezeigt werden. Das Abspielen der Karten wird mit Animationen dargestellt, wodurch die Karten auf die Abspielplätze bewegt werden. Am Ende des Stichs werden die gespielten Karten entfernt. Normalerweise wird eine Karte nur nach einem Mausklick gespielt, im Setup-Fenster können Stiche jedoch abgewählt werden, wodurch sie automatisch abgespielt werden. Die Geschwindigkeit der Animationen kann eingestellt werden. Abgewählte Stiche am Anfang der Liste werden komplett übersprungen. Sobald alle Einstellungen getroffen wurden, wird ein Template-Objekt erzeugt, mit dem die Vorlage in die aktuelle Präsentation übernommen wird. Die einzelnen Elemente der Vorlage werden durch die Klassen im Namespace Bridge. BridgeTemplates.Elements dargestellt. So können Elemente auch für andere Vorlagentypen benutzt werden (z. B. für die Anzeige der Gefahrenlage und der Spielerhände bei der Reizung). Eine besondere Bedeutung hat die abstrakte Klasse AbstractHand, die eine Basisklasse für die verschiedenen Darstellungen von Spielerhänden ist. Auf diese Weise können leicht neue Darstellungsarten hinzugefügt werden, ohne dass dafür der vorhandene Code zur Durchführung des Abspiels geändert werden muss. In der Klasse Notebox wurde eine Funktion implementiert, die in den aus der PBN- Datei eingelesenen Kommentaren die Abkürzungen \C, \D, \H und \S durch die Symbole für Treff, Karo Herz und Pik ersetzt. Dies entspricht einer Konvention, die in der PBN- Spezifikation für Kommentare eingeführt wurde [24]. Die eigentliche Interaktion mit PowerPoint geschieht über die Schnittstellenklassen PPInterface und PPTemplateInterface. Durch die Verwendung dieser Schnittstellen wird von der eigentlichen Software PowerPoint, in der die Bridge-Komponente ausgeführt wird, abstrahiert. Die Schnittstellen wurden in einem eigenen Projekt PPWrapper erstellt. Die von PowerPoint verwendeten Aufzählungstypen wurden durch die Klasse TemplateTypes abgebildet. Die Bridge-Komponente ist somit bezüglich der verwendeten Software neutral

74 Implementierung 74 und könnte prinzipiell ohne Änderung mit einer anderen Software benutzt werden, die in der Lage ist, beide Schnittstellen zu implementieren (speziell OpenOffice Impress). In der jetzigen Fassung werden die Schnittstellen durch die Klassen ThisAddIn und PPTemplate im Projekt ETKPPAddIn implementiert. Einige Einstellungen werden in den Settings für das Bridge-Projekt gespeichert, beispielsweise der zuletzt verwendete Kartensatz und die zuletzt verwendete Vorlage. So muss nicht bei jedem Starten der Software erneut der Kartensatz geändert werden, wenn dieser grundsätzlich mit den englischen Bezeichnungen verwendet werden soll. Zusammenfassung Die folgenden Projekte in der Projektmappe ETK wurden im zweiten Entwicklungszyklus erstellt: ETKSetup Cards CardInserter Bridge PPWrapper Erstellt das Installationsprogramm für das E-Learning Toolkit. Verwaltet die verfügbaren Kartensätze. Eine Komponente zum Einfügen einzelner Karten. Die Bridge-Komponente, mit der Spielabläufe eingefügt werden können. Enthält die Schnittstellenklassen, mit denen Funktionen von Power- Point aufgerufen werden Tests Die Darstellung der PBN-Dateien in der Bridge-Komponente wurde mit den Testdateien test1-1.pbn und test1-3.pbn getestet. Die Datei test1-3.pbn enthält dabei eine Reihe von Sonderfällen, die bei der Darstellung berücksichtigt werden mussten. Funktionstests der Bridge-Komponente und der Vorlagen wurden mit den folgenden Testdateien durchgeführt: test2-1.pbn: test2-2.pbn: test2-3.pbn: Testet die Anzeige unterschiedlicher Spielresultate. Testet das Ersetzen der Abkürzungen \C und \D durch die Symbole für Treff und Karo in Anmerkungen. Testet eine Datei, in der kein Spielergebnis vorgegeben ist. test2-4.pbn: Testet Zwischenräume zwischen den Karten bei Händen mit nur 1, 2 oder 3 Farben. test2-5.pbn: Testet Anmerkungen und NAGs.

75 Implementierung 75 test2-6.pbn: Testet ein Spiel, bei dem West Alleinspieler ist. Die Testdateien sind im Unterverzeichnis Testdateien der beiliegenden CD einsehbar (siehe Anhang A.4) Ergebnis Alle für diesen Entwicklungszyklus vorgesehenen Aufgaben wurden bearbeitet. Das Bridge- Abspiel konnte wie vorgesehen dargestellt werden (siehe Abbildung 6.5). Abbildung 6.5: Bridge-Abspiel Zyklus Zyklus 3 Nachdem im zweiten Zyklus erfolgreich das Bridge-Abspiel mit festem Spielverlauf implementiert wurde, sollte im dritten Entwicklungszyklus die Reizung ergänzt werden. Weiterhin sollte die freie Reizung und das freie Abspiel implementiert werden Diskussion Zunächst wurde das Ergebnis des zweiten Zyklus diskutiert. Es fiel auf, dass die Karten durch die Unterteilung der Farben übersichtlich dargestellt waren, diese Übersichtlichkeit im Laufe des Spiels jedoch verlorenging. Deshalb wurde vorgeschlagen, die Karten nach jedem Stich zu verschieben, so dass die Farben wieder zusammenhängend sind. Außerdem wurde die Darstellungsweise beim Programm Bridge Master (siehe Kapitel 3.2) untersucht. Dort werden die Karten sehr übersichtlich in Textform angezeigt. Gespielte Karten sind ebenfalls stark vereinfacht. Aus diesem Grund sollte in ETK eine weitere Vorlage für das Abspiel erstellt werden, bei der die Karten in Textform dargestellt

76 Implementierung 76 werden, und ein neuer, vereinfachter Kartensatz entworfen werden. Bei der Implementierung der Reizung sollte ebenfalls wahlweise die vereinfachte Darstellung verwendet werden können. Für die freie Reizung und das freie Abspiel musste eine Implementierungsmethode gefunden werden. Die Alternativen waren die Benutzung von VBA-Makros oder eine Implementierung im Add-In. Falls die Durchführung des freien Spiels durch das Add-In erfolgt wäre, hätte es allerdings stets auf dem Rechner installiert sein müssen, auf dem die Präsentation angezeigt wird. Eine weitere Aufgabe im dritten Zyklus war das Einfügen der Karten eines Spielers in die Präsentation, wobei wahlweise zu den Karten ein interaktives Quiz erzeugt werden sollte. Zusätzlich wurde diskutiert, wie die Erzeugung von Kartenverteilungen implementiert werden könnte. Die Kartenverteilungen sollten als PBN-Dateien abgespeichert werden. Dazu müsste die PBN-Komponente erweitert werden, so dass auch das Abspeichern einer PBN-Datei möglich ist. Nützlich wäre es außerdem, wenn für die erzeugte Kartenverteilung mittels Double-Dummy-Analyse die maximal möglichen Kontrakte ermittelt werden können. Dafür müsste ein entsprechendes Analyseprogramm in ETK eingebunden werden, da eine eigene Implementierung zu aufwändig wäre Aufgabenplanung Aus den geplanten Aufgaben wurde das folgende Backlog für den dritten Entwicklungszyklus erstellt (Tabelle 6.3): Aufgabe Zyklus Erstellung eines weiteren Kartensatzes mit vereinfachten Karten 3 Vorlagen Bridge-Abspiel Bei Bridge-Abspiel die Karten nach jedem Stich zusammenschieben 3 Erstellung einer neuen Vorlage mit Karten in Textform 3 Neue Vorlagen Bridge Freies Bridge-Abspiel mit Makros 3 Bridge-Reizung mit festem Ablauf ohne Makros 3 Freie Bridge-Reizung mit Makros 3 Bridge-Hände anzeigen 3 Bridge Bewertungsquiz für Hände 3 Kartenverteilungen erzeugen PBN-Dateien speichern 4 Kartenverteilungen erzeugen 4 Double-Dummy Analyse 4 Tabelle 6.3: Backlog Zyklus 3

77 Implementierung Implementierung Im dritten Entwicklungszyklus wurden die folgenden Aufgaben nach Tabelle 6.3 bearbeitet: Änderungen an den Vorlagen zum Bridge-Abspiel Das Zusammenschieben der Karten wurde in den Klassen zur Darstellung der Bridge- Hände im Namespace Bridge.BridgeTemplates.Elements implementiert. Für die Darstellung der Karten in Textform wurde außerdem die Klasse HandSimple erstellt, die von der Klasse AbstractHand erbt. Auf diese Weise konnte der neue Handtyp einfach in den bestehenden Code integriert werden. Weil Texte in PowerPoint-Folien nicht durch Animationen geändert werden können, werden die vereinfachten Hände als eine Reihe von Textboxen in die Präsentation eingefügt, wobei nur die jeweils aktuelle Textbox über Animationen aufgedeckt wird. Aus den vorhandenen Kartengrafiken wurden vereinfachte Kartengrafiken erstellt, die jeweils nur das Symbol der Kartenfarbe und den Kartenwert darstellen. Der neue Kartensatz wurde in dem Unterverzeichnis CardSets\simple zum Projekt Cards hinzugefügt. Erstellung von Vorlagen für die Bridge-Reizung Die Bridge-Reizung sollte durch Anklicken des entsprechenden Knotens in der PBN- Anzeige in die Präsentation eingefügt werden. Dazu wurde die Klasse AuctionNode im Namespace Bridge.PBNTree erweitert. Im Namespace Bridge.BridgeTemplates.Auction wurden die Klassen SetupWindow und Template erstellt. Die Klassen ähneln den gleichnamigen Klassen aus dem Namespace Bridge.BridgeTemplates.Play. Auch bei der Reizung ist es möglich, einzelne Gebote abzuwählen, wodurch sie übersprungen oder automatisch angezeigt werden. Zum Anzeigen der Reizung wurde die Klasse AuctionTable im Namespace Bridge.BridgeTemplates.Elements erstellt. Wie bei der Anzeige der vereinfachten Hände werden mehrere Tabellen eingefügt, von denen nur die jeweils aktuelle Tabelle sichtbar ist. Für die Reizung wurden zwei Vorlagendateien erstellt, so dass zwischen der Darstellung der Hände als Spielkarten oder in Textform gewählt werden kann. Implementierung der freien Reizung und des freien Abspiels Bei dem Versuch, das freie Spiel im Add-In zu implementieren, wurde klar, dass es schwierig ist, durch das Anklicken von Shapes während der Anzeige der Präsentation Funktionen im Add-In aufzurufen. Aus diesem Grund wurde entschieden, das freie Spiel mit VBA- Makros zu realisieren. Dabei trat allerdings eine andere Schwierigkeit auf. Die Animationen, die für die Darstellung der festen Reizung und des festen Abspiels benutzt wurden, konnten in dieser Form in Makros nicht verwendet werden. Die Animationsfolge hätte während der Ausführung verändert werden müssen, um auf die Eingaben des Benutzers zu reagieren. Bei jeder Änderung der Animationsfolge durch ein VBA-Makro wird sie jedoch auf den anfänglichen Zustand zurückgesetzt, was die beabsichtigte Verwendung unmöglich machte. Es blieb also nur die Herangehensweise, die Positionen der Shapes direkt in der Folie zu ändern. Mit VBA-Makros ist es darüber hinaus möglich, Texte in Shapes direkt zu ändern, so dass es nicht länger notwendig ist, mehrere Exemplare von Textboxen oder Tabellen einzufügen.

78 Implementierung 78 VBA-Programmcode kann leider nicht in Visual Studio 2008 bearbeitet werden, weil die von Visual Studio unterstützte Version von Visual Basic nicht mit VBA kompatibel ist. Die Makros wurden deshalb innerhalb der Entwicklungsumgebung von PowerPoint entwickelt (siehe Anhang A.2.2). Über die Funktion zum Exportieren von VBA-Makros konnten die Quelltexte nach der Entwicklung als Dateien gespeichert und in die Projektmappe ETK übernommen werden. Sie werden allerdings nur als Inhaltsdateien geführt (siehe Anhang A.3.4), da sie nicht kompiliert werden können. Auf diese Weise werden die VBA-Dateien aber zum Setup-Programm hinzugefügt, damit sie bei der Erstellung von Lehrmaterial übernommen werden können. Zu diesem Zweck wurde im Namespace Bridge. BridgeTemplates die Klasse VBA implementiert, die den VBA-Programmcode in die Präsentation einfügt. Die folgenden VBA-Klassen und Programmmodule wurden erstellt: ETK_Bridge_Makros Enthält die Makros, die beim Klicken auf Spielkarten oder Gebote aufgerufen werden. ETK_Bridge_Main Enthält alle Makros, die durch Benutzerinteraktion ausgelöst werden können. ETK_Bridge_Global Enthält generelle Hilfsfunktionen und Typdefinitionen. Klasse Game Klasse Player Klasse Card Klasse Trick Klasse HandSimple Klasse Auction Klasse AuctionCall Führt das freie Abspiel durch. Entspricht einem Spieler. Entspricht einer gespielten Karte. Entspricht einem gespielten Stich. Wird für die Darstellung von vereinfachten Händen benutzt. Führt die freie Reizung durch. Entspricht einem Gebot. In VBA-Modulen definierte Variablen gelten global für eine Präsentation. Weil bei der Anzeige möglicherweise zwischen Folien gewechselt wird, auf denen freie Bridge-Spiele durchgeführt werden, muss für jede Folie mit einem freien Spiel ein eigenes Game-Objekt oder Auction-Objekt gespeichert werden, das die Daten und benutzten Objekte des auf der jeweiligen Folie vorhandenen Spiels enthält. Das Modul ETK_Bridge_Main führt dazu die beiden Listen games und auctions. Beim Starten eines Spiels wird ein passendes Objekt erzeugt oder es wird ein für die Folie vorhandenes Objekt wiederverwendet. Alle Makro- Subroutinen, die durch Benutzereingaben aufgerufen werden, müssen an das entsprechende Objekt der aktuellen Folie weitergeleitet werden. Zu allen Bridge-Vorlagen wurden Symbole für die Steuerung des freien Spiels hinzugefügt. Zum Starten des freien Spiels wurde eine Textbox hinzugefügt. Außerdem wurden drei Symbole für die Funktionen Undo, Zurücksetzen und Beenden hinzugefügt. Die

79 Implementierung 79 Undo-Funktion nimmt die zuletzt ausgeführte Spielaktion zurück. Zu diesem Zweck wird jede Aktion in einer Liste von Trick-Objekten beim freien Abspiel bzw. AuctionCall- Objekten bei der freien Reizung gespeichert. Mit der Zurücksetzen-Funktion wird der ursprüngliche Zustand der Folie wiederhergestellt. Die Beenden-Funktion setzt die Folie zurück und wechselt zur nächsten Folie. Damit bei einem Fehlklick nicht versehentlich die Folie gewechselt wird, ist der Folienübergang über Mausklick deaktiviert, während das freie Spiel durchgeführt wird. Sobald das freie Spiel beendet wurde, wird das Ergebnis der Reizung oder das Spielergebnis angezeigt. Anzeige von Bridge-Händen Für die Anzeige von Händen sollten drei Möglichkeiten wählbar sein: Die Darstellung als Spielkarten, als Text oder als Quiz. In diesem Entwicklungszyklus wurden nur die beiden Möglichkeiten zur Darstellung als Spielkarten und als Text implementiert. Die Klasse HandNode im Namespace Bridge.PBNTree wurde so erweitert, dass beim Anklicken des Knotens ein Fenster zum Einfügen der Handkarten angezeigt wird. Das Fenster wurde in der Klasse SetupWindow im Namespace Bridge.BridgeTemplates.Hand implementiert Tests Die im 3. Zyklus neu erstellten Vorlagen und Makros wurden mit den Testdateien getestet, die in den vorherigen Zyklen bereits genutzt wurden. Außerdem wurden die beiden Testdateien S5Hx.pbn und W3SA.pbn benutzt, bei denen der Alleinspieler je einmal in Position Süd und in Position West ist. Zusätzlich wurden die folgenden Testdateien zum Testen der Reizung erstellt: test3-1.pbn: test3-2.pbn: test3-3.pbn: Enthält eine längere Reiztabelle. Enthält eine Reiztabelle, in der jedes mögliche Gebot vorkommt. Die Reiztabelle enthält nur AP für All Pass (alle Spieler passen zu Beginn der Reizung). Die Testdateien sind im Unterverzeichnis Testdateien der beiliegenden CD einsehbar (siehe Anhang A.4) Ergebnis Von den geplanten Aufgaben wurde das Bewertungsquiz nicht bearbeitet, die Aufgabe wurde deshalb in den vierten Entwicklungszyklus verschoben. Die freie Reizung und das freie Abspiel konnten in Form von VBA-Makros implementiert werden. 6.4 Zyklus 4 Die in den bisherigen Zyklen entwickelten Vorlagen benötigen passende PBN-Dateien, um Spielsituationen darzustellen. Beim Entwurf von Lehrmaterial müsste also weitere Soft-

80 Implementierung 80 ware zur Erzeugung von PBN-Dateien benutzt werden. Im vierten Entwicklungszyklus sollten deshalb Methoden implementiert werden, mit denen innerhalb des E-Learning Toolkits PBN-Dateien erzeugt werden können Diskussion Für die Erstellung von Lehrmaterial ist es häufig notwendig, eine bestimmte Kartenverteilung zu erzeugen. Grundsätzlich könnte ein bestehendes Programm zur Erzeugung von Kartenverteilungen in ETK integriert werden. Untersucht wurden die Programme Big Deal von Hans von Staveren [26] und RP Deal Finder von Richard Pavlicek [40]. RP Deal Finder ist aufgrund der Option, Kartenverteilungen nach speziellen Kriterien erstellen zu können, sehr interessant. Die komplizierte Syntax des Kommandozeilenprogramms würde allerdings eine aufwändige Integration bedeuten und es müsste eine passende Bedienungsoberfläche entworfen werden, die alle Optionen abdeckt. Aus diesem Grund wurde von dieser Möglichkeit vorläufig abgesehen. Wie von Staveren erklärt (siehe Kapitel bzw. [26]), wird für die Erzeugung von Zufallsverteilungen mit Computerprogrammen der Einsatz eines verbesserten Zufallszahlengenerators benötigt. Es könnte also entweder sein Programm Big Deal in das E-Learning Toolkit integriert werden oder eine ähnliche Funktion entwickelt werden. Für die späteren Benutzer wäre es sehr praktisch, wenn eine Kartenverteilung wahlweise durch Zufallsgenerator oder manuell erstellt werden könnte. Für die erzeugten Kartenverteilungen sollte außerdem eine Double-Dummy-Analyse zur Ermittlung des optimalen Kontrakts durchgeführt werden können. Dazu sollte das Programm gibtrix von René Steiner untersucht werden, das in Verbindung mit dem von Matthew Ginsberg entwickelten gib die Double-Dummy-Analyse für PBN-Dateien durchführen kann (siehe Kapitel und Anhang A.2). Bei der Evaluierung der Ergebnisse des vorherigen Zyklus wurden einige Möglichkeiten zur Verbesserung gefunden. Bei den vorhandenen Vorlagen sind teilweise die gespielten Karten unübersichtlich platziert. Deshalb sollten weitere Vorlagen erstellt werden, in denen die Hände der Spieler und die gespielten Karten deutlicher voneinander abgesetzt sind. In der Reizung sollten außerdem noch die Karten Stop und Alert ergänzt werden. Bei der freien Reizung und beim freien Abspiel war es bisher nicht möglich, die Karten ausgewählter Spieler zu verdecken. Dazu wäre es notwendig gewesen, in den VBA-Makros ein Spielprogramm zu implementieren, das die passenden Spielaktionen durchführt. Eine weniger aufwändige Lösung war, den in der PBN-Datei gespeicherten Spielverlauf für das freie Spiel als Vorgabe zu übernehmen. Solange dieser Spielverlauf befolgt wurde, konnten von den verdeckten Spielern die vorgegebenen Spielaktionen durchgeführt werden. Die Karten mussten allerdings aufgedeckt werden, sobald ein von der Vorgabe abweichender Spielverlauf durchgeführt wurde. In diesem Entwicklungszyklus wurde außerdem die Idee aus dem zweiten Entwicklungszyklus aufgegriffen, während des freien Spiels den Spielverlauf aufzuzeichnen und als PBN- Datei abzuspeichern. Auf diese Weise können zu den erzeugten Kartenverteilungen komplette Spielabläufe erstellt werden, ohne dass ein weiteres Programm zur Bearbeitung der

81 Implementierung 81 PBN-Datei benötigt wird. Es sollte dabei eine Funktion implementiert werden, mit der bei der Durchführung des Spiels Anmerkungen eingegeben werden können. Die Entwicklung der Poker-Komponente wurde ebenfalls besprochen. Wie bei Bridge sollte es möglich sein, einzelne Pokerhände oder die Spielsituation am Pokertisch einzufügen. Dabei sollte ein fester Spielablauf ohne Makros und ein freier Spielverlauf mit Makros durchgeführt werden können Aufgabenplanung Zusätzlich zu den in diesem Zyklus geplanten Aufgaben wurde die aus dem letzten Zyklus verbleibende Aufgabe zur Implementierung eines Bewertungsquiz in das Backlog aufgenommen (siehe Tabelle 6.4). Die Entwicklung der Poker-Komponente wurde in den fünften Entwicklungszyklus verschoben, weil die Entwicklung der Bridge-Komponente erst abgeschlossen werden sollte. Aufgabe Zyklus Vorgegebener Ablauf bei der freien Reizung und beim freien Abspiel und verdeckte 4 Spieler zulassen Aufzeichnen von Reizabläufen und Spielabläufen beim freien Spiel und Speichern als 4 PBN-Dateien Implementierung der Karten Stop und Alert in der Reizung 4 Neue Vorlagen mit besserer Übersichtlichkeit erstellen 4 Neue Vorlage Bridge: Bewertungsquiz für Hände 4 Bridge Kartenverteilungen erzeugen PBN-Dateien speichern 4 Kartenverteilungen erzeugen manuell und mit Zufallsgenerator 4 Double-Dummy Analyse 4 Entwicklung der Poker-Komponente Erzeugen und Anzeige von Pokerpartien 5 Poker Vorlage Spielverlauf anzeigen 5 Poker Vorlage freier Spielverlauf mit Makros 5 Poker Hände anzeigen 5 Tabelle 6.4: Backlog Zyklus Implementierung Es wurden zwei weitere Vorlagen für das Bridge-Abspiel erstellt, bei denen die Karten der Spielerhände und die gespielten Karten deutlicher zu unterscheiden sind. Außerdem wurden für die Reizung zwei Symbole für Stop und Alert eingefügt. Während das Stop- Symbol automatisch angezeigt wird, sobald eine Reizung im Sprung erfolgt (siehe Kapitel 2.2.1), macht die Anzeige das Alert-Symbols nur dann Sinn, wenn eine entsprechende

82 Implementierung 82 Anmerkung zu dem alertierten Gebot vorhanden ist. Für die in den PBN-Dateien gespeicherten Anmerkungen wurde deshalb die Abkürzung \A eingeführt. Bei der Anzeige der Reizung wird an der entsprechenden Stelle dann das Alert-Symbol angezeigt. Änderungen an den vorhandenen Vorlagen Um die Vorgabe des Spielverlaufs für die freie Reizung oder das freie Abspiel zu implementieren, mussten die vorgegebenen Spielaktionen an das VBA-Programm übergeben werden. Dazu wurde die Klasse PBNBase im Namespace Bridge.BridgeTemplates. Elements entwickelt, mit der eine vorhandene PBN-Datei in Form von Tags in das freie Spiel eingefügt werden kann. Tags sind Zeichenfolgen, die Shapes in PowerPoint- Präsentationen zugeordnet werden. Sie sind bei der Anzeige der Präsentation unsichtbar, können aber von VBA-Makros ausgelesen werden. Bei der Ausführung des VBA- Programms werden dann die vorgegebenen Spielaktionen durchgeführt. Dabei werden auch vorhandene Anmerkungen angezeigt. Die VBA-Makros wurden so erweitert, dass der durchgeführte Spielverlauf als PBN- Datei gespeichert werden kann. Für die Undo-Funktion (siehe Kapitel 6.3.3) musste bereits der Spielverlauf in den AuctionCall- bzw. Trick-Objekten festgehalten werden. Zusammen mit dem PBN-Rumpf, der mit der für die vorherige Teilaufgabe benötigten Vorgabe in Tags gespeichert wird, kann am Ende der Reizung oder des Abspiels eine komplette PBN-Datei erzeugt werden. Zur Anzeige eines Dialogs, in dem der Speicherort für die erzeugte Datei angegeben werden kann, wurde das Code-Fragment Ariad Common File Dialogs von Ariad Software verwendet (siehe Anhang A.2). Zur Eingabe von Anmerkungen wurde in den Vorlagen eine Schaltfläche ergänzt. Für die Reizung wurde außerdem eine Schaltfläche für Alert implementiert. Beim Anklicken kann ebenfalls eine Anmerkung eingegeben werden, der automatisch die Abkürzung \A vorangestellt wird. Bei der Anzeige von Bridge-Händen sollte die Möglichkeit ergänzt werden, ein Bewertungsquiz in die Folien einzufügen. Dazu wurde im Namespace Bridge.BridgeTemplates. Hand die Klasse TemplateQuiz ergänzt, mit der ein Quiz nach der Vorlage Quiz.pptx in die Präsentation eingefügt werden kann. Dabei können bis zu vier Antworten vorgegeben werden. Beim Anklicken wird für richtige und falsche Antworten der jeweils passende Erklärungstext angezeigt. Erzeugen von Kartenverteilungen Zum Erzeugen von Kartenverteilungen wurden die Klassen DealGeneratorWindow und DealHandControl im Namespace Bridge.DealGenerator implementiert. Die Spielkarten der Spieler können per Mausklick ausgewählt oder zufällig verteilt werden. In der Klasse RandomGenerator wird für die Erzeugung von Zufallszahlen ein kryptografischer Zufallszahlengenerator verwendet (RNGCryptoServiceProvider). Dieser benutzt Systemfunktionen des Windows CryptAPI (siehe [48]) und kann für Bridge als hinreichend zufällig betrachtet werden. In der Dokumentation von Big Deal [26] werden ebenfalls kryptographische Methoden als Grundlage für die Entwicklung des Programms genannt.

83 Implementierung 83 Damit die erzeugten Kartenverteilungen als PBN-Dateien gespeichert werden können, wurde die Klasse Game im Namespace PBN so erweitert, dass Game-Objekte mit einer übergebenen Kartenverteilung erzeugt werden und über die Methode ToPBNString in eine PBN-konforme Zeichenkette umgewandelt werden können. Die Zeichenfolge kann anschließend in einer PBN-Datei gespeichert werden. Die Klassen für die einzelnen Elemente der Datei im Namespace PBN.Elements wurden ebenfalls mit einer ToPBNString-Methode ergänzt. In der Game-Klasse wird also aus den PBN-Zeichenfolgen der enthaltenen Elemente die PBN-Zeichenfolge für das Spiel gebildet. Wenn eine Kartenverteilung erstellt wurde, kann eine Double-Dummy-Analyse durchgeführt werden. Der dabei ermittelte optimale Kontrakt kann in die PBN-Datei übernommen werden. So ist es möglich, die Kartenverteilung für das Einfügen einer Abspielsituation zu verwenden, ohne dass ein Reizverlauf festgelegt werden muss. Der übernommene Kontrakt kann aber auch frei gewählt werden, die Durchführung der Analyse ist optional. Double-Dummy-Analyse Für die Double-Dummy-Analyse musste das Programm gibtrix in das E-Learning Toolkit eingebunden werden. Dazu wurde das Projekt Gibtrix hinzugefügt. Mit der Klasse Gibtrix- Wrapper kann für eine Kartenverteilung die Analyse durchgeführt werden. Das Programm wird zwar in einem eigenen Prozess ausgeführt, die Analyse kann aber entweder synchron gestartet werden (der aufrufende Thread wartet, bis die Analyse abgeschlossen ist) oder asynchron (der aufrufende Thread kehrt sofort zurück). Im synchronen Fall wird das Ergebnis von der Methode analyze zurückgegeben. Im asynchronen Fall wird beim Aufruf der Methode eine Delegate-Methode übergeben, an die das Ergebnis weitergegeben wird, sobald die Analyse abgeschlossen ist. Dabei wird ein Fenster angezeigt, dass auf die laufende Analyse hinweist. Es enthält zwar einen Fortschrittsbalken, da die Dauer aber nicht abgeschätzt werden kann, wird kein realistischer Wert angezeigt. Das Programm gibtrix führt für die eigentliche Analyse das Programm gib aus. Die beiden Programmdateien sowie eine Konfigurationsdatei für gibtrix sind im Projekt Gibtrix als Inhaltsdateien im Unterverzeichnis gibtrix enthalten. Auf diese Weise wird im späteren Programmverzeichnis von ETK ebenfalls ein Unterverzeichnis gibtrix erzeugt, das die Dateien enthält. Zur Durchführung einer Analyse muss die Kartenverteilung in einer temporären PBN-Datei gespeichert werden. Das Ergebnis der Analyse wird anschließend aus der Ausgabedatei von gibtrix ausgelesen Tests Für das Testen der erweiterten Vorlagen wurden die in den vorherigen Zyklen erstellten Testdateien benutzt. So konnte auch kontrolliert werden, dass das Hinzufügen von neuen Features nicht die vorhandenen Funktionen beeinträchtigt hat. Außerdem wurde zum Testen der Abkürzung \A, die in Anmerkungen für das Anzeigen von Alert benutzt wird, die Testdatei test4-1.pbn erstellt.

84 Implementierung 84 Das Programm PBNTest wurde so erweitert, dass optional für die übergebene PBN- Datei eine Double-Dummy-Analyse durchgeführt werden kann. Die Ergebnisse für die beiden Dateien S5Hx.pbn und W3SA.pbn können in den Testprotokollen auf der beiliegenden CD (siehe Anhang A.4) betrachtet werden Ergebnis Alle für den vierten Entwicklungszyklus geplanten Aufgaben konnten bearbeitet werden. Mit den hinzugefügten Funktionen zur Erstellung einer Kartenverteilung und zur Aufzeichnung der Reizung und des Abspiels ist es ohne weitere Hilfsprogramme möglich, eine komplette PBN-Datei mit einem bestimmten Lehrinhalt zu erstellen. Die Aufzeichnungsfunktion kann aber auch hilfreich sein, wenn Lernende einen eigenen Lösungsweg für eine bestimmte Problemstellung speichern oder untereinander austauschen wollen. Die Möglichkeit, Vorgaben in das freie Spiel zu übernehmen, ist außerdem sinnvoll, wenn die Karten der Gegenspieler nicht aufgedeckt werden sollen, denn das ist es ja gerade, was die Schwierigkeit beim Bridge-Spiel ausmacht. 6.5 Zyklus 5 Im fünften Entwicklungszyklus konnte mit der Implementierung der Poker-Komponente begonnen werden. Mit der Bridge-Komponente wurde gezeigt, wie mit den verfügbaren Methoden der Ablauf eines Kartenspiels in eine PowerPoint-Präsentation eingefügt werden kann. Die Poker-Komponente sollte verdeutlichen, dass durch den modularen Aufbau mit wenig Aufwand ein weiteres Kartenspiel unterstützt werden kann Diskussion Wie bereits im vierten Entwicklungszyklus festgehalten wurde, sollte die Poker-Komponente sowohl feste Spielabläufe als auch freie Spielabläufe darstellen können. Bei festen Abläufen wäre es günstig, wenn zur Speicherung ebenfalls ein Dateiformat zur Verfügung stände. Dazu könnte das PBN-Dateiformat für Poker angepasst werden oder ein neues Format entwickelt werden. Außerdem sollten Poker-Hände in die Präsentation eingefügt werden können. Bei der Evaluation der Bridge-Komponente fiel auf, dass es beim freien Abspiel mit verdeckten Spielern vorkommen kann, dass bei einem verdeckten Spieler eine andere Karte gespielt werden soll, als in der Vorgabe festgelegt wurde. Deshalb sollte es möglich sein, die verdeckten Karten bei Bedarf aufzudecken, damit eine beliebige Karte gespielt werden kann. Für die Benutzung des E-Learning Toolkits wurde eine Anleitung erstellt. Die Anleitung sollte über das Startmenü oder aus der Bedienungsoberfläche heraus über eine Hilfefunktion aufgerufen werden können.

85 Implementierung Aufgabenplanung Für den fünften Entwicklungszyklus wurden die folgenden Aufgaben festgelegt (siehe Tabelle 6.5): Aufgabe Zyklus Hilfefunktion für Bridge, Poker und CardInserter 5 Bridge: bei freier Reizung und freiem Abspiel die Karten verdeckter Spieler aufdecken, 5 wenn auf die Spielerbezeichnung geklickt wird. Poker Entwicklung der Poker-Komponente: Erzeugen und Anzeige von Pokerpartien 5 Poker Vorlage Spielverlauf anzeigen - Poker Vorlage freier Spielverlauf mit Makros 5 Poker Hände anzeigen 5 Tabelle 6.5: Backlog Zyklus 5 Weil die Implementierung eines Speicherformats für Poker-Spiele in der begrenzten Zeit zu aufwändig gewesen wäre, wurde in diesem Entwicklungszyklus nur das freie Pokerspiel implementiert Implementierung Für die Hilfefunktion wurde ein neues Unterprojekt ETKHelp in die Projektmappe aufgenommen. In diesem Projekt sind die Hilfedatei ETK Kurzanleitung.doc und die Klasse Help enthalten. Die Hilfedatei wird explizit in das ETKSetup-Projekt aufgenommen, damit vom Installer ein Eintrag im Startmenü mit der Datei verknüpft werden kann. Die Klasse Help enthält eine statische Methode zur Anzeige der Hilfedatei, dabei wird die in Windows festgelegte Programmverknüpfung ausgeführt. Da es sich um eine Doc-Datei handelt, wird sie mit Microsoft Word angezeigt, wenn das Programm installiert ist. Bridge Die VBA-Dateien für die freie Reizung und das freie Abspiel wurden mit Makros ergänzt, die beim Anklicken der Spielerbezeichnungen aufgerufen werden. Dadurch werden die verborgenen Karten des jeweiligen Spielers sichtbar gemacht. Poker Für das Poker-Projekt wurde das Steuerelement PokerControl implementiert, mit dem fünf Gemeinschaftskarten und die Handkarten von bis zu sechs Spielern festgelegt werden können. Die Karten können in einem Menü ausgewählt oder zufällig verteilt werden. Dazu wird die Klasse RandomGenerator benutzt, die dem Zufallsgenerator entspricht, der in der Bridge-Komponente verwendet wurde. Außerdem können einzelne Hände, die Gemeinschaftskarten oder die gesamte Pokerrunde in die Präsentation eingefügt werden. Für

86 Implementierung 86 Poker wird standardmäßig der vereinfachte Kartensatz mit den englischen Kartenbezeichnungen J, Q, K verwendet (siehe Kapitel 6.3.3), was im Poker-Steuerelement allerdings geändert werden kann. Die Klassen Const und Strings legen die in der Poker-Komponente benutzten Aufzählungstypen und Zeichenfolgen fest. Die Klasse Card stellt eine einzelne Karte dar. Mit der Klasse Combinations kann die beste Kartenkombination eines Spielers ermittelt werden. Für das Einfügen des freien Pokerspiels wurden die Klassen SetupWindow, PlayerControl und Template im Namespace Poker.PokerTemplates.Table implementiert. Beim Einfügen kann ein Titel für die Folie, die Höhe der Blinds, die Chipreserven der Spieler und die Position des Dealers festgelegt werden. Es wurden zwei Vorlagen Poker1.pptx und Poker2.pptx erstellt. In der zweiten Vorlage sind die Karten der Spieler weiter voneinander entfernt und können so leichter unterschieden werden. Zum Einfügen der VBA-Makros wurde die Klasse VBA erstellt. Die folgenden Makros wurden für das freie Pokerspiel entwickelt: ETK_Poker_Global ETK_Poker_Main Klasse PokerGame Klasse PokerHand Enthält generelle Hilfsfunktionen und Typdefinitionen. Enthält alle Makros, die durch Benutzerinteraktion ausgelöst werden können. Führt das freie Pokerspiel durch. Entspricht einem Spieler bei Poker. Ähnlich den VBA-Makros für Bridge wird für jede Folie, die ein freies Pokerspiel enthält, ein eigenes PokerGame-Objekt geführt. Während der Durchführung kann so auf eine andere Folie gewechselt werden, ohne dass die Daten verlorengehen. Benutzereingaben werden an das jeweils zugehörige Objekt weitergeleitet. Die Steuerung des Poker- Spiels geschieht über die Schaltflächen Fold, Check, Call, Raise und All In. Es werden immer nur die Schaltflächen angezeigt, die in der aktuellen Spielsituation benutzt werden können. Dabei wird beachtet, dass die Wette immer um mindestens den Betrag des Big Blinds erhöht werden muss (siehe Kapitel 2.2.4) Ergebnis Bei der Entwicklung der Poker-Komponente im fünften Zyklus konnten nur grundlegende Funktionen implementiert werden. Eine Undo-Funktion wie bei den freien Bridge-Spielen wurde nicht implementiert. Es konnte aber gezeigt werden, dass mit den vorhandenen Funktionen des E-Learning Toolkits relativ schnell ein weiteres Kartenspiel integriert werden konnte. Ein Anwendungsbeispiel für die Poker-Komponente wird in Kapitel 7.1 vorgestellt.

87 Ergebnis 87 7 Ergebnis Mit der endgültigen Version des E-Learning Toolkits wurden einige exemplarische Vorgehensweisen erarbeitet. Diese Beispiele stellen die typischen Aufgaben dar, für die das Programm eingesetzt werden kann. Dabei konnte die Benutzungsfreundlichkeit des Programms untersucht werden und es konnte überprüft werden, welche Anforderungen der Aufgabenstellung (siehe Kapitel 4) erfüllt wurden. Die Wirkung einer mit Hilfe von ETK erstellten Präsentation auf ein Publikum konnte bei einem Vortrag erprobt werden, in dem diese Arbeit vorgestellt wurde. Die Folien des Vortrags sind auf der beigefügten CD enthalten (siehe Anhang A.4). 7.1 Anwendungsbeispiele Die folgenden Anwendungsbeispiele zeigen, wie mit dem E-Learning Toolkit verschiedene Spielsituationen dargestellt werden können. Dabei ist zu beachten, dass freie Spielverläufe nur mit Microsoft PowerPoint angezeigt werden können. Für feste Spielabläufe genügt hingegen der PowerPoint Viewer. Die in den Beispielen erwähnten Dateien sind auf der beigefügten CD im Verzeichnis Anwendungsbeispiele enthalten (siehe Anhang A.4). Bridge Dieses Beispiel zeigt, wie ein komplettes Spiel mit ETK erzeugt und in eine Präsentation eingefügt werden kann. Natürlich können auch bestehende PBN-Dateien verwendet werden, wodurch die Zwischenschritte zur Aufzeichnung des Spielverlaufs wegfallen. Zur Erstellung des Anwendungsbeispiels wird in PowerPoint eine leere Präsentation erzeugt. Im ersten Schritt wird eine Kartenverteilung über die Schaltfläche Neu generiert (siehe Abbildung 7.1). Die Kartenverteilung wird anschließend als Datei Kartenverteilung.pbn gespeichert. Abbildung 7.1: Anwendungsbeispiel Kartenverteilung erzeugen

88 Ergebnis 88 Durch Anklicken der Zeile Reizung in der PBN-Anzeige wird eine freie Reizung in die Präsentation eingefügt. Weil noch kein Reizablauf gespeichert wurde, ist die Liste der Gebote leer (Abbildung 7.2). Abbildung 7.2: Anwendungsbeispiel unvollständige Reizung einfügen Die Reizung kann in der PowerPoint-Bildschirmpräsentation aufgezeichnet werden. Dabei können auch Anmerkungen eingegeben werden. Die fertige Reizung wird als Datei Reizung.pbn gespeichert (Abbildung 7..3). Abbildung 7.3: Anwendungsbeispiel Reizung aufzeichnen

89 Ergebnis 89 Die Folie, mit der die Reizung aufgezeichnet wurde, kann gelöscht werden, nachdem die PBN-Datei gespeichert wurde. Durch öffnen der Datei in ETK kann der komplette Verlauf als feste Reizung eingefügt werden (Abbildung 7.4). Abbildung 7.4: Anwendungsbeispiel feste Reizung Bridge Abspiel Auf ähnliche Weise wie für die Reizung kann ein Spielverlauf für das Abspiel aufge- zeichnet werden. Dazu wird zunächst ein leerer Spielverlauf als freies Abspiel ohne Vor- gabe in die Präsentation eingefügt (Abbildung 7.5). Abbildung 7.5: Anwendungsbeispiel Abspiel aufzeichnen

90 Ergebnis 90 Der komplette Spielverlauf wird als Datei Abspiel.pbn gespeichert. Die Folie zur Auf- zeichnung des Abspiels kann entfernt werden, weil das freie Abspiel erneut eingefügt werden soll. Dabei wird der vorher aufgezeichnete Spielverlauf als Vorgabe übernommen, so dass es möglich ist, die Karten von Spielern zu verdecken (Abbildung 7..6). Abbildung 7.6: Anwendungsbeispiel fertiges Abspiel einfügen Solange die Karten der Vorgabe gespielt werden, bleiben die Karten der Spieler O und W verborgen. Durch Anklicken der Spielerbezeichnung können die Karten eines Spielers aber aufgedeckt werden, wenn eine andere Karte als die Vorgesehene gespielt werden soll (Abbildung 7.7). Abbildung 7.7: Anwendungsbeispiel freies Abspiel mit Vorgabe

91 Ergebnis 91 Durch Anklicken einer Hand in der PBN-Anzeige können die Karten als Quiz in die Präsentation eingefügt werden (Abbildung 7.8). Abbildung 7.8: Anwendungsbeispiel Quiz einfügen Poker In der jetzigen Version ist nur das Einfügen einer freien Pokerrunde möglich. In der Poker- Komponente können die Gemeinschaftskarten und die Spielkarten für bis zu sechs Spieler festgelegt oder zufällig ausgewählt werden (siehe Abbildung 7.9). Abbildung 7.9: Anwendungsbeispiel Poker Kartenverteilung