Making The Game – Teil 18: Konzept zum schulischen Einsatz und Ausblick

Posted on Sonntag, Juli 22nd, 2012

Zusammenfassend kann gesagt werden, dass die Ziele der Arbeit erreicht wurden, auch wenn nicht alle Komponenten der Anwendung, die im Grobkonzept geplant waren, umgesetzt wurden. Deshalb müsste das Lernspiel vor dem tatsächlichen Einsatz in Schulen um diese offenen Punkte ergänzt werden. Dazu gehört neben dem Erstellen der zum jeweiligen Unterricht passenden Fragen-Datenbanken die Erstellung des Trainingsmodus sowie die Entwicklung weiterer Mini-Spiele und das Einpflegen der Evaluationsergebnisse.
Jedoch ist durch die voll implementierte Quiz-Show bereits in der momentanen Version der zu Beginn der Entwicklung gewünschte Spaß und auch ein Lerneffekt bei den Spielenden zu erkennen.
 
Konzept zum schulischen Einsatz
Da die Anwendung hauptsächlich für den Schulunterricht entwickelt wurde, ist ein Konzept, wie die Anwendung in der Schule eingesetzt wird, von Nöten. Wie in den Zielbestimmungen beschrieben, handelt es sich hierbei um eine „Drill and Practice“- Anwendung. Da diese keinen Lehrstoff vermittelt, sondern nur wiederholt und übt, muss das Wissen in den vorherigen Schulstunden an die Schüler weitergegeben worden sein.
Die hinterlegten Fragen des Spieles sollten vor dem Einsatz von der Lehrkraft geprüft werden, damit nur der unterrichtete Stoff abgefragt wird. Vor der Unterrichtsstunde müssen die entsprechenden Computer eingeschaltet und das Programm gestartet werden.
 
Zu Beginn der Unterrichtsstunde sollte die Klasse in gleich große Gruppen von ca. fünf Schülern aufgeteilt werden. Je nach vorhandener Multi-Touch-Hardware werden jeweils zwei Gruppen, bei der Benutzung von Desktop-Computern, oder drei, bei der Verwendung größerer Geräte wie Multi-Touch-Tischen, zusammen einem Gerät zugeteilt.
Da bei der Verwendung von Desktop-Geräten, aus platztechnischen Gründen, jeweils nur ein Spieler pro Gruppe den Multi-Touch-Bildschirm bedienen kann, wird dieser vor jeder Frage ausgewechselt. Für diesen Austausch kann entweder festgelegt werden, dass die Gruppen intern rotieren, damit jeder Schüler einmal an der Reihe war, oder dass die Gruppe selbst bestimmt, wer von ihnen die nächste Frage beantworten soll. Für den Spielerwechsel bieten die Zwischensequenzen sowie der Vortrag des Kategorienamens ein ausreichend großes Zeitfenster.
 
Da das Spiel sehr leicht zu verstehen und zu bedienen ist, können die Schüler selbstständig daran arbeiten. Die Lehrkraft sammelt nach jeder Spielrunde die Punktestände der einzelnen Gruppen und notiert diese an der Tafel.
Nach jeder gespielten Runde werden die kontrahierenden Gruppen ausgetauscht, damit nicht andauernd dieselben Gruppen gegeneinander antreten. Da eine Spielrunde zwischen sieben und zehn Minuten benötigt, können in einer Unterrichts-stunde drei bis vier Runden gespielt werden.
Am Ende der Unterrichtsstunde werden die einzelnen Ergebnisse der Gruppen aufsummiert und somit wird ein Gewinner ermittelt.
 
Ausblick
Durch die Ankündigung Microsofts, dass das im September 2012 kommende Betriebssystem Windows 8 Berührungen zum bevorzugten Eingabemechanismus macht, wird sehr wahrscheinlich der Wandel in Richtung natürlicher Benutzer-oberflächen, welcher bereits auf allen Smartphones Einzug gehalten hat, auch auf anderen PC-Systemen stattfinden.
Die daraus resultierenden Vorteile, welche in dieser Arbeit erläutert wurden, werden den Umgang mit Computern zu einer Selbstverständlichkeit und Leichtigkeit für jung und alt machen, weshalb der Schritt zur Entwicklung von NUI-Anwendungen von Entwicklern so früh wie möglich gemacht werden sollte.
 
 
————
 
 
Da die Programmierer-Sicht ein bisschen kurz kam startet in den nächsten Wochen eine neue Blog-Serie “How to…” die sich ausschließlich mit der Flash- und PHP-Programmierung auseinandersetzt. Darin werden verschiedene Vorgehensweisen erläutert wie ich Probleme bei der Entwicklung meiner Anwendung gelöst habe und wie verschiedene Aufgaben im Detail angegangen wurden.
 
 
 




Making The Game – Teil 17: Evaluation und Einsatz der Anwendung

Posted on Sonntag, Juli 15th, 2012

Ziel dieser Arbeit ist es gewesen, eine Edutainment-Anwendung für natürliche Benutzeroberflächen zu entwickeln, die im Unterricht und zu Hause eingesetzt werden kann. Sie sollte Kinder und Jugendliche auf eine spaßige Weiße dazu animieren, ihr gelerntes Wissen zu testen und durch das Spielen zu festigen. Dabei wurde darauf geachtet, dass die Lernenden durch ansprechende Animationen, Zwischensequenzen und Mini-Spiele motiviert werden, das Spiel immer wieder zu spielen.
Weiterhin sollten die Möglichkeiten von natürlichen Eingabemöglichkeiten, wie Touch-Eingaben und die Steuerung mittels Körperbewegungen, getestet und ansprechend implementiert werden.
 
Da es für den Lernprozess wichtig ist, dass der Lernende sich wohl fühlt, wurde die eigentliche Wissensabfrage so in einem Quiz-Spiel verpackt. Somit merkt der Spieler fast nicht, dass er gerade Fragen, welche genauso gut in einer Klausur gestellt werden könnten, beantwortet.
 
Allgemein
Im Rahmen dieser Arbeit konnte aus zeitlichen Gründen leider keine Evaluation der Anwendung im schulischen Bereich stattfinden. Stattdessen wurde das Spiel verschiedenen Testpersonen zwischen 13 und 80 Jahren auf einem multi-touch-fähigen Gerät zum Testen gezeigt. Dabei wurden keine Instruktionen oder Erklärungen, außer dass es sich um einen Touch-Bildschirm handelt, gegeben. Als Wissensbasis wurden bei diesen Tests Fragen aus dem Bereich Allgemeinwissen verwendet.
 

Buzzer mit den vier Buttons zum beantworten der Fragen

Buzzer mit den vier Buttons zum beantworten der Fragen

Trotz anfänglicher Verständnisprobleme, wie das Programm bedient wird, kamen alle Testpersonen nach kurzer Zeit von selbst darauf, wie gespielt wird. Nachdem die Bedienung per Berührung verstanden wurde, traten auch weniger Bedien-Probleme bei den Mini-Spielen, die anders gesteuert werden, auf.
 
Kritik gab es vereinzelt bezüglich der Wahl der gestellten Fragen und gewählten Kategorienamen, was jedoch durch eine Änderung der zugrunde liegenden Fragen-Datei leicht geändert werden könnte.
Ein anderer Kritikpunkt Einzelner war die Wahl der Sequenzen zwischen den Fragen. Diese wurden in Anlehnung an bekannte Spiele und Internet-Phänomene („Internet Memes“, Definition: lustige Bild-, Ton-, und Videodateien die sich schnell über das Internet verbreiten) angelehnt.
Um allen Spielern gerecht zu werden, müsste an diesen Stellen noch mal nachgebessert werden.
 
Offene Punkte sind der nicht implementierte Trainings-Modus, welcher zu Beginn des Projektes zum Trainieren der Mini-Spiele geplant war, sowie die zwei nicht umgesetzten Mini-Spiele „Slice It“ und „Aim and Shoot“.
 
Einsatz auf der CeBIT
Nach der Analyse im studentischen und privaten Umfeld wurde die Anwendung auf der CeBIT 2012 ausgestellt und das Feedback der Besucher notiert.
 
Durch den hohen Geräuschpegel in der Halle war es selbst mit lauteren, externen Boxen schwer, den Ton des Spieles zu hören, weshalb dieser nach dem ersten Tag ausgeschaltet und die im Spiel integrierte Spielanleitung durch eine persönliche Erklärung ersetzt wurde.
Wegen dieser meist schnellen Erklärungen vor dem Multi-Touch-Computer kam es bei vielen Besuchern dazu, dass sie den „Buzzer“, der gedrückt werden muss, wenn ein Spieler antworten will, am unteren Bildschirmrand sowie den Countdown übersahen und somit wild auf dem Bildschirm rumdrückten, ohne das etwas passierte.
Durch das Beobachten der Spieler wurde darüber hinaus schnell klar, dass diese lieber die Antworten direkt mit dem Finger auswählen würden anstelle der vier Zahlen über dem „Buzzer“, welche den vier Antworten entsprechen.
 
Das Feedback der Fachbesucher fiel fast durchwegs sehr positiv aus, wobei viele die ansprechende Spielweise und die Wahl der Eingabemethode per Finger und Körpersteuerung als innovativ und positiv hervorhoben.
 
Da der letzte Tag für alle Besucher frei war, wurde an diesem Tag hauptsächlich das Webcam-Spiel „Catch All“ in einer abgewandelten Variante, bei der die Spieler Diamanten fangen mussten, gezeigt. Dabei wurde deutlich, dass besonders Jüngere und Kinder von dieser Steuerung, bei der sie sich bewegen müssen, sehr angetan waren. Aber auch ältere Besucher verstanden schnell ohne Erklärung, wie das Spiel gespielt wird.
CeBIT 2012 - Braincademy, Webcam-Spiel, Collage

CeBIT 2012 – Braincademy, Webcam-Spiel, Collage

 
 
 

Kommende Blogeinträge
Making The Game – Teil 18: Konzept zum schulischen Einsatz und Ausblick

 
 
 




Making The Game – Teil 16: Vorstellung der Mini-Spiele

Posted on Sonntag, Juli 8th, 2012

Mini-Spiele innerhalb der Anwendung stellen eine Abwechslung zu den Fragerunden dar. Sie sollen die Spieler primär unterhalten und stellen nicht unbedingt den Anspruch, Lehrinhalte abzufragen.
Durch die verschiedenen Systeme, auf denen die Anwendung lauffähig sein wird, muss jedes Mini-Spiel selbst festlegen, welche Anforderungen es hat, um spielbar zu sein. Bei der Auswahl der Mini-Spiele müssen diese Voraussetzungen berücksichtigt werden.
Bevor die einzelnen Mini-Spiele entwickelt werden, wurden diese in der Storyboard-Phase im Groben konzipiert.

Skizzen von möglichen Mini-Spielen

Skizzen von möglichen Mini-Spielen


 
Catch All und Catch Selected
Die Spiele „Catch All“ und „Catch Selected“ sind zwei Minispiele, die nicht mit Touch-Eingaben arbeiten, sondern über die Bewegungserkennung mittels Webcam gesteuert werden.
Beide Spiele lehnen sich an die Konzepte der „Bewegten Schule“ bzw. des „Bewegten Lernens“ an. Diese besagen, dass das Lernen mit Bewegung die Informationsverarbeitung verbessern kann. Darüber hinaus stellt die Bewegung eine Abwechslung zur sonst sitzenden Beschäftigung des Spielens dar, wodurch der innere Bewegungsdrang vieler Kinder ausgeglichen wird.
 
Beide Webcam-Spiele stellen dem Spieler die Aufgabe, herunterfallende Objekte zu fangen. Während bei „Catch Selected“ nur die richtigen Antworten zu einer gestellten Frage gefangen werden sollen, müssen bei „Catch All“ alle Objekte aufgefangen werden.
Catch All in einer abgewandelten Version auf der CeBIT 2012

Catch All in einer abgewandelten Version auf der CeBIT 2012


 
Da der Spieler vor der Kamera Platz zum Bewegen benötigt, ist die maximale Spielerzahl bei diesen zwei Spielen auf einen begrenzt. Aber auch im Hinblick auf den Einsatz in der Schule ist diese Spielerbegrenzung sinnvoll. Bei einer höheren Spieleranzahl, was beim schulischen Einsatz der Fall ist, könnte es dazu kommen, dass sich die Spieler in der auftretenden Wettkampfsituation gegeneinander anrempeln oder schupsen, um einen unfairen Vorteil zu haben. Dies wird durch die Begrenzung verhindert.
 
(Anmerkung: Das Spiel ist in abgewandelter form unter zu finden)
 
Quick Select
„Quick Select“ ist ein Reaktionsspiel. Ähnlich wie bei „Catch Selected“ werden den Spielern Fragen gestellt oder Sätze vorgegeben, die vervollständigt werden müssen. Entsprechende Lösungsvorschläge werden nach und nach angezeigt, sodass immer nur eine Antwort zu sehen ist. Glaubt der Spieler, die richtige Antwort auf die Frage zu sehen, muss dieser auf seinen „Buzzer“ oder seine Spielertaste auf der Tastatur drücken. Ist die Frage richtig beantwortet, werden ihm die Punkte gut geschrieben und die nächste Frage wird gestellt. Bei einer falschen Antwort geht das Spiel weiter.
 
Dabei ist „Quick Select“ das einzige Spiel, bei dem ein Spieler mehrfach auf eine Frage antworten kann. Durch diese zweite Chance kann er eine vorher falsche Antwort punktetechnisch wieder ausgleichen.
 
Da das Spiel mit Tastatur und über Touch-Eingaben gesteuert werden kann, existieren keine Beschränkungen hinsichtlich der Spieleranzahl oder der vorhandenen Hardware, womit es an jedem Endgerät spielbar ist.
 
Defend Your Base
Defend Your Base in einer frühen Version

Defend Your Base in einer frühen Version


Das Mini-Spiel „Defend Your Base“ stammt aus dem Genre der „Tower Defense Spiele“ (kurz TD). Aufgabe in dieser Art Spiele ist es, die eigene Basis, in diesem Fall den „Buzzer“ des Spielers, vor mehreren anstürmenden Gegnern zu verteidigen. In herkömmlichen TD-Spielen ist es die Aufgabe des Spielers, durch das Bauen von Verteidigungsanlagen (meistens Geschütztürme, daher der Begriff „Tower Defense“) die eigene Basis zu verteidigen.
 
In der hier implementierten Variante muss der Spieler die Angreifer, dargestellt durch rote Kreise, mit den Fingern „zerdrücken“. Durch dieses Mini-Spiel wird kein Wissen abgefragt, dafür jedoch die Hand-Auge-Koordination trainiert.
 
Indem der Spieler gleichzeitig an unterschiedlichen Stellen des Bildschirms mit der Spielwelt interagieren muss, werden die Multi-Touch-Fähigkeiten in diesem Mini-Spiel komplett ausgereizt.
Da die Steuerung per Maus nur die Interaktion mit einem Punkt auf dem Bildschirm ermöglicht, ist das Spiel bei dieser Art der Steuerung für einen Spieler bereits komplizierter als bei der Verwendung von Touch-Eingaben. Darüber hinaus limitiert die Verwendung der Maus die Spieleranzahl auf eine Person, während an Multi-Touch-Geräten eine höhere Spieleranzahl möglich ist.

 
 
 

Kommende Blogeinträge
Making The Game – Teil 17: Evaluation und Einsatz der Anwendung
Making The Game – Teil 18: Konzept zum schulischen Einsatz und Ausblick

 
 
 




Making The Game – Teil 15: Spielablauf und Spielphasen

Posted on Sonntag, Juli 1st, 2012

Spielablauf, Anwendersicht

Spielablauf, Anwendersicht

Die Entwicklung der Spielekomponente ist einer der aufwendigsten und größten Teile in der Anwendung. Deswegen wird während der Analyse und Designphase ein Ablaufplan des Spiels aus der Sicht des Spielers erstellt (siehe Abbildung rechts).
Nach der Auswahl, wie viele Spieler an der Runde teilnehmen, wird den Kandidaten der generelle Ablauf erklärt, woraufhin mit einem kurzen Intro zur Frage übergeleitet wird. Nach der vierten und achten Fragerunde wird jeweils ein Mini-Spiel gestartet, um Abwechslung im Spielverlauf zu schaffen. Nach dem zweiten Mini-Spiel wird die Runde beendet und die Highscore-Liste angezeigt.
 
Da sich die spielerische Sicht auf den Ablauf von der programmiertechnischen Sicht unterscheidet, wird ein weiterer Ablaufplan eingesetzt, der den Ablauf in acht Phasen unterteilt, welche das Spielgeschehen vorantreiben. Durch diese Einteilung kann anhand der aktuellen Phasen-Nummer ermittelt werden, welcher Teil des Spieles momentan ausgeführt wird. Nach ablauf jeder einzelnen Phase wird in die nächste Übergegangen. So läuft die Anwendung ähnlich wie ein Film Stück für Stück ab.
 
 
Nach der Auswahl der teilnehmenden Spieler wird die Hauptfunktion game_init(), welche durch die Phasen führt, aufgerufen.
 
Beschreibung der Phasen:
 
„ON AIR“ Logo aus dem Spiele-Intro

„ON AIR“ Logo aus dem Spiele-Intro

Phase 0:
Beim ersten Aufruf der Funktion wird lediglich das Intro aus einer externen *.swf-Datei abgespielt, in dem der Benutzer vom Spielshow-Moderator begrüßt wird. Dabei wird die Anzahl der gespielten Runden heraufgesetzt. Während die Begrüßung abgespielt wird, wird bereits Phase 1 aufgerufen.
 
Phase 1:
In der ersten Phase werden alle nötigen Variablen initialisiert bzw. auf ihren ursprünglichen Wert zurückgesetzt, damit die Spielrunde problemlos von vorne starten kann.
Dazu gehört, dass das Spielerlevel auf die Stufe 2 zurückgesetzt wird, die Kontostände aus vorherigen Runden genullt werden und die Liste der bereits gestellten Fragen geleert wird. Letzteres wird gemacht, da davon ausgegangen wird ,dass sich die Spieler vor dem Gerät abwechseln und bei jeder Runde neue Kandidaten gegeneinander antreten.
Weiterhin werden der Hintergrund und andere grafische Elemente wie die Kategorie-Anzeige und „Buzzer“ der Spieler positioniert.
 
Da diese Phase während der Begrüßung, die in Phase 0 gestartet wird, stattfindet, wird an dieser Stelle gewartet, bis das Intro fertig abgespielt wurde.
 
Phase 2:
Phase 2 des Spieles ist die Instruktionsphase. Dem Spieler werden darin die Regeln und die Steuerung erklärt. Dabei wird grafisch anhand der „Buzzer“ gezeigt, wie ein Spieler dem Programm mitteilt, dass er die Frage beantworten will und was die Folgen einer richtigen und falschen Antwort sind.
Nachdem die Erklärung fertig abgespielt wurde oder der Spieler sie abbrach, wird zur ersten tatsächlichen Spielphase übergegangen.
 
Zwischensequenz vor Frage 1

Zwischensequenz vor Frage 1

Phase 3:
Die dritte Phase des Spieles ist der Einstiegspunkt für jede neu gestellte Frage im Spiel.
In ihr wird, wie bereits im vorherigen Kapitel angesprochen, eine zufällige Frage ausgewählt. Damit der Spieler während der Auswahl unterhalten wird, wird eine lustig gestaltete Zwischen-sequenz abgespielt. Diese beinhaltet die Nummer der aktuellen Frage, damit der Kandidat die Übersicht behält, wie viele Fragen er bereits beantwortet hat. Am Ende des Intros werden die Kategorie der Frage sowie die zu erhaltenen Punkte angezeigt und vorgelesen.
 
Phase 4:
Nachdem das Intro fertig abgespielt wurde und der Spieler die Kategorie kennt, wird zur Frage übergeleitet. Dabei wird entweder eine der Standardüberleitungen verwendet oder, falls vorhanden, die hinterlegte Audio-Datei im bereits erwähnten „pretalk“-Eintrag in der Fragen-Datenbank.
Des Weiteren wird in Phase 4 die eigentliche Frage eingeblendet und gelesen. Während die Frage vorgetragen wird, sind die „Buzzer“ deaktiviert, damit jeder den kompletten Text gelesen oder gehört hat. Somit soll verhindert werden, dass Spieler, die die Frage vorher bereits gehört haben, schon nach den ersten zu sehenden Worten die Frage beantworten können, nur weil sie diese bereits kennen.
 
Phase 5 / 6:
Während die vier Antwortmöglichkeiten nach und nach eingeblendet werden, haben die Spieler ab diesem Zeitpunkt die Möglichkeit, die Frage zu beantworten, indem sie auf ihre „Buzzer“ drücken. Wurde die letzte Antwort vorgelesen, wird in Phase 6 der zehnsekündige Countdown gestartet.
Ist der Countdown abgelaufen oder beantwortet ein Spieler die Frage korrekt, wird die Erklärung zur richtigen Antwort vorgelesen und die Punkte werden verteilt.
Gestellte Frage mit allen vier Antworten

Gestellte Frage mit allen vier Antworten


 
Phase 7:
Die letzte Spielphase ist die prüfende Instanz. In ihr werden alle Textfelder, die während des Spieles animiert wurden, auf ihre Ausgangsposition zurückgesetzt und die „Buzzer“ für alle Spieler wieder deaktiviert.
 
Darüber hinaus wird geprüft, wie das Spiel an dieser Stelle fortfahren soll. So wird nach der vierten und achten Runde jeweils ein Mini-Spiel per Zufall ausgewählt, um Abwechslung zwischen den Fragerunden zu schaffen, oder nach dem zweiten Mini-Spiel die Highscore-Liste angezeigt.
 
 
 
Viele Spiele benutzen solche Phasen oder auch Schleifen um den Ablauf zu steuern. Sei es die einfache Sprung-Phase bei einem Jump n’ Run Spiel oder ein laufender Counter. Durch die Einteilung der Anwendung in keine Teile lässt sich diese auf eine saubere Art und Weise durchlaufen und weiß zu jedem Zeitpunkt was gerade passiert ist, was jetzt passiert und welcher Schritt danach durchgeführt werden muss.
 
 
 

Kommende Blogeinträge
Making The Game – Teil 16: Mini-Spiele
Making The Game – Teil 17: Evaluation und Einsatz der Anwendung
Making The Game – Teil 18: Konzept zum schulischen Einsatz und Ausblick

 
 
 




Making The Game – Teil 14: Wissensbasis und Fragenauswahl / Arbeiten mit XML

Posted on Sonntag, Juni 24th, 2012

Die Wissens- oder Fragenbasis ist das Herzstück des Programms. In ihr werden alle Fragen und Antworten, die den Spielern gestellt werden können, nach Kategorien sortiert eingetragen. Da es nicht erforderlich sein soll, für jeden dieser Fragenkataloge Audiodateien zu hinterlegen, da die Erstellung der einzelnen Sprachdateien den Arbeitsaufwand um ein Vielfaches erhöht, wird in den ersten Zeilen der XML-Datei festgelegt, ob die Fragen im Spiel vorgelesen werden oder nur textuell erscheinen.
 

  1.  <CATALOG>
  2.     <BASICSETTINGS>
  3.         <ITEM name="audio">true</ITEM>
  4.     </BASICSETTINGS>
  5.  

 
(Anmerkung: Da die Anwendung und diese Entscheidung alle Audio-Parts manuell einzusprechen mittlerweile bereits ein halbes Jahr alt ist, würde ich diese Vorgehensweise heute komplett über den Haufen werfen und auf eine TTS-API, wie die inoffizielle von Google, zurückgreifen. Ich werde hier dennoch meine damalige Vorgehensweise beschreiben.)
 
Jede Frage im Katalog wird dabei durch eine eigene Identifikationsnummer gekennzeichnet. Durch diese könnten später in einem Autoren-Tool die Fragen direkt per ID angesprochen werden. Darüber hinaus ist sie für den Fragen-Autor ein Indikator dafür, wie viele Fragen bereits in einer Kategorie erstellt wurden.
 
Die mögliche Punkteanzahl für die Frage spiegelt deren Schwierigkeitsgrad wieder. Der niedrigste Wert, der für eine Frage gegeben werden kann, ist 1000 Punkte, was dem Spielerlevel 1 entspricht. Entsprechende höhere Level werden durch 2000, 3000,… Punkte im Fragenkatalog dargestellt. Bei der Punkteeinteilung besteht keine Obergrenze, jedoch sollten Fragen über 4000 Punkten vermieden werden, da der Spieler durch falsches Beantworten diese abgezogen bekommt, was bei sehr hohen Werten schnell zu Frustrationen führen kann.
Die wichtigsten Entitäten in der XML-Datei sind jedoch die eigentliche Frage, die Antworten sowie die Nummer der richtigen Antwort. Diese enthalten den Fragentext, welcher im Programm animiert eingeblendet wird sowie die vier möglichen Antworten, die der Spieler vorgegeben bekommt.
 

  1.  <CATEGORY name="Das Internet? Gibts den Blödsinn immer noch?">
  2.  <CATEGORYAUDIO>
  3.     <ITEM name="category">catalog/cat/cat7.mp3</ITEM>
  4.  </CATEGORYAUDIO>
  5.  
  6.  …
  7.  <QUESTION id="3">
  8.      <ITEM name="points">2000</ITEM>
  9.      <ITEM name="text">Wie nennt man die Pauschalgebühr für eine
  10.                         Internet- oder Telefonverbindung?</ITEM>
  11.      <ITEM name="a1">Overrate</ITEM>
  12.      <ITEM name="a2">Connectionrate</ITEM>
  13.      <ITEM name="a3">Flatrate</ITEM>
  14.      <ITEM name="a4">Freiminuten</ITEM>
  15.      <ITEM name="correct">3</ITEM>
  16.      <AUDIOFILES>
  17.         <ITEM name="pretalk"></ITEM>
  18.         <ITEM name="text">catalog/ID005/q_3_0.mp3</ITEM>
  19.         <ITEM name="a1">catalog/ID005/q_3_1.mp3</ITEM>    
  20.         <ITEM name="a2">catalog/ID005/q_3_2.mp3</ITEM>
  21.         <ITEM name="a3">catalog/ID005/q_3_3.mp3</ITEM>
  22.         <ITEM name="a4">catalog/ID005/q_3_4.mp3</ITEM>    
  23.         <ITEM name="correct">catalog/ID005/q_3_5.mp3</ITEM>
  24.      </AUDIOFILES>
  25.  </QUESTION>  
  26.  …

 
Wie in dem Auszug aus dem Allgemeinwissen-Fragenkatalog zu erkennen ist, stellt die Verlinkung der einzelnen Audio-Komponenten einen großen Teil der Struktur dar.
(Anmerkung: Und eigentlich hätte man an dieser Stelle eine feste Konvention wählen sollen um zu bestimmen wie die Dateien benannt sind, damit diese automatisch und ohne einTrag in der XML-Datei gelesen und wiedergegeben werden können. Aber auf die Idee kam ich halt nicht. -.-)
 
Die Bezeichnung der einzelnen Audio-Einträge wurde korrespondierend zu den textuellen Einträgen angelegt, damit schnell ersichtlich wird, in welcher Ton-Datei welcher Textabschnitt gesprochen wird.
Die einzigen Ausnahmen stellen dabei die Einträge unter “pretalk” und “correct” dar. In der Aufnahme für den “correct”-Eintrag wird nicht nur die richtige Antwort vorgelesen, sondern es sollte eine erweiterte Erklärung erfolgen, warum die entsprechende Antwort richtig ist. Im Spiel selbst wird die Datei abgespielt, sobald die Lösung der Antwort angezeigt wird.
Durch die Verwendung des “pretalk”-Eintrags kann der Autor des Fragenkatalogs mit einer kurzen Beschreibung zur eigentlichen Frage hinführen bzw. den Spieler durch eine kurze Erklärung, worum es in der kommenden Frage geht, ins Bilde setzen. Der Eintrag ist dabei optional und muss nicht verwendet werden.
 
Die zufällige Auswahl der jeweiligen Frage während der Spielrunde erfolgt automatisch mit dem Aufruf der Funktion selectQuestion() (siehe Code unten). Diese prüft, ob momentan eine Runde gespielt wird oder ob außerhalb der Spielrunden eine Frage angefordert wird, was zum Beispiel im Trainingsmodus vorkommt. Ist derzeit eine Spielrunde im Gange, wird der aktuelle Spieler-Level für spätere Gültigkeitsprüfungen übernommen.
 
Aus einer zufälligen Kategorie wird danach eine beliebige Frage gewählt. Um sicherzugehen, dass diese auch geeignet ist, wird geprüft, ob sie im Bereich des Spieler-Levels liegt. In der nächsten Instanz wird geprüft, ob die ID der Frage bereits in der Liste der gestellten Fragen enthalten ist.
Liegt die Frage außerhalb des Spieler-Levels oder wurde sie bereits gestellt, wird eine neue Frage per Zufall ausgewählt. Dieser Vorgang wird wiederholt, bis eine Frage gefunden wurde, die beide Bedingungen erfüllt.
 

  1.  function selectQuestion():XML{
  2.     var lvl:int = 999;
  3.     // get current player level if we are in a match
  4.     if(questionNumber>0){
  5.         lvl = game_level;
  6.     }
  7.    
  8.     var categorySelected:int;
  9.     var questionSelected:int;
  10.     var simpleCounter:int = 0;
  11.    
  12.     do {
  13.         simpleCounter++;
  14.    
  15.         // GET NUMBER OF CATEGORIES
  16.         var categoryAmmount:int = basicXMLCatalog.CATEGORY.length();
  17.  
  18.         // select one category randomly
  19.         categorySelected = randomNumber(1,categoryAmmount);
  20.        
  21.         // GET NUMBER OF QUESTIONS IN THE CATEGORY
  22.         var questionAmmount:int =
  23.              basicXMLCatalog.CATEGORY[categorySelected-1].
  24.              QUESTION.length();
  25.  
  26.         // select one question randomly
  27.         questionSelected = randomNumber(1, questionAmmount);
  28.        
  29.         // check if the question is in the current level-range
  30.         var possiblePoints =
  31.                 basicXMLCatalog.CATEGORY[categorySelected-1].
  32.                 QUESTION[questionSelected-1].ITEM.(@name=="points");
  33.         var outOfRange:Boolean = true;
  34.         if(possiblePoints <= lvl*1000){ outOfRange = false; }
  35.        
  36.         // check if the question was already asked
  37.         // if indexOf == -1 –> not asked
  38.         var alreadyAsked:Boolean = true;
  39.         if((questionIDStore.indexOf(categorySelected +
  40.             "-" + questionSelected)) < 0){
  41.             alreadyAsked = false;
  42.         }
  43.        
  44.         // failsafe… no questions… go out of level-range
  45.         if(simpleCounter > 20){ outOfRange = false; }
  46.        
  47.         // failsafe #2… just ask a question again
  48.         if(simpleCounter > 40){ alreadyAsked = false; }
  49.        
  50.     // search until the question was not already asked
  51.     } while (outOfRange || alreadyAsked);
  52.  
  53.     // at this point we have a question selected!
  54.     // save the question ID – we dont want to ask it again
  55.     questionIDStore.push(categorySelected + "-" + questionSelected);
  56.  
  57.     // save the question data
  58.     question_currentXML =
  59.              basicXMLCatalog.CATEGORY[categorySelected-1].
  60.              QUESTION[questionSelected-1];
  61.  
  62.     // return the xml-data
  63.     return question_currentXML;
  64.  }

 
Da nicht sichergestellt werden kann, dass ausreichend Fragen in der verwendeten Wissensbasis hinterlegt sind, muss eine Notfallstrategie gewählt werden. So werden nach zwanzig ergebnislosen Durchläufen, eine passende Frage zu finden, auch Fragen zugelassen, die außerhalb des Spielerlevels liegen, aber noch nicht gestellt wurden.
Sollte nach weiteren zwanzig Durchläufen immer noch keine Frage gefunden worden sein, können auch bereits gestellten Fragen wieder gestellt werden. Somit kann sichergestellt werden, dass das Spiel auch mit schlecht erstellten Wissensbasen bis zum Rundenende durchspielbar ist.
 
Ist eine Frage gewählt und wurde sie als geeignet bewertet, wird ihre ID zu der Liste der gestellten Fragen hinzugefügt, alle zugehörigen Daten werden aus der XML-Datei gelesen und für die weitere Verwendung zwischengespeichert.

 
 
 

Kommende Blogeinträge
Making The Game – Teil 15: Spielablauf und Spielphasen
Making The Game – Teil 16: Mini-Spiele
Making The Game – Teil 17: Evaluation und Einsatz der Anwendung
Making The Game – Teil 18: Konzept zum schulischen Einsatz und Ausblick