Making The Game – Part 18: Concept for school use and outlook

Posted on Sunday, July 22nd, 2012

In summary it can be said that the objectives of the work have been achieved, although not all planned components of the application were implemented. Therefore this elements had to be added to the actual game before useing it in schools. This includes not only the creation of the particular subject-appropriate questions further a training mode is needed for the practical use.However, the quiz show is already fully implemented in the current version.
Concept for schools
Since the application was developed primarily for use in schools, a concept of how the application will be used there is essential. As described previously the game is a “drill and practice”-application. Since no instructions are given on the subject, knowledge must have been passed in the previous lessons to the students.
The used questions of the game should be tested before the lessen by the teacher, so that only the material taught is queried.
At the beginning of the lesson, the class should be divided into equal-sized groups of about five students. Depending on the existing multi-touch hardware two groups, with the use of desktop computers, or three, with the use of larger devices such as multi-touch tables, are assigned to a unit.
Whereas the use of desktop devices only allowes one player per group to operate the multi-touch screen, a player has be choosen before each question. The cutscenes are the perfect time for the exchange of the players.
Since the game is very easy to understand and operate, the students can work independently on it. The teacher collectes the scores of each group after each round and records them on the board.
After each round played, the contracting groups are replaced, so that different groups compete against each other. Since a round needs between seven and ten minutes three to four rounds can be played per lessen.
At the end of the lesson, the individual results of the groups are added together, and a winner is determined.
With the announcement of Microsoft, that in September 2012 the upcoming operating system Windows 8 is preferred to use touch-events as input mechanism, it is most likely that a change in user interface design will occur.
The resulting benefits, which were discussed in this blog-series, will make the use of computers for young and old more easy. So the step to development NUI-applications should be made as soon as possible.

Since the programmers point of view was a little short in this series next week a new blog series called “How to …” starts which exclusively deals with Flash programming. This provides various approaches how I solved problems in the development of my application and how different tasks have been addressed in detail.


Making The Game – Part 17: Evaluation and deployment of the application

Posted on Sunday, July 15th, 2012

The aim of this work has been to develop an edutainment application for natural user interfaces that can be used in the classroom and at home. They should encourage children and young people on a funy way to test their newly acquired knowledge. Care was taken that the game motivates learners by appealing animations, cut scenes and mini-games.
Since it is important in the learning process that the learner feels comfortable, the actual knowledge query was packed in a trivia game. Thus, the player does not notice that he just answered questions that could be used ​​just as well in an exam.
Due to time constraints, unfortunately, no evaluation of the application in schools could be made. Instead, the game was tested with people in between 13 to 80 years. It was shown on a multi-touch enabled device for testing. No instructions or explanations, except that is it is a touch-screen, were given. A question data-base with questions on general knowledge was choosen for this test.

BBuzzer with the four buttons to answer the questions

Buzzer with the four buttons to answer the questions

Despite initial problems understanding how to operate the program, all subjects were able figure it out in a short time. After the control by touch was understood, there were less operating problems than expected.
There were few criticisms regarding the choice of the questions and selected category name, however, this could be easily changed by changing the underlying database.
Another criticism of individuals were the choices of the sequences between the questions. These were based on popular games and Internet memes.
To please all the players this parts of the game had to be improved in a further version.
Presentation at CeBIT
After analyzing the application it has been exhibited at CeBIT 2012.
Due to the high level of noise in the hall, it was difficult even with external speakers to hear the tone of the game. So it was turned off after the first day and the in-game instructions have been replaced by a personal instruction.
Because of the most rapid explanations a lot if visitors had some problems related to the countdown and to the use of the buzzer at the bottom of the screen.
The feedback from the visitors was almost always very positive. So a lot of people highlighted the choice of input method by finger and body control and described it as being innovative and positive.
Since the last day was free for all visitors, on this day mainly the webcam game “Catch All” was shown in a modified version, where players had to catch diamonds. It became clear that especially younger people and children were enthusiastic whith this control. But also older visitors quickly understood, without an explanation, how the game was played.

CeBIT 2012 - Braincademy, Webcam-Game, Collage

CeBIT 2012 – Braincademy, Webcam-Game, Collage


Upcoming blog entries
Making The Game – Part 18: Concept for school use and outlook


Making The Game – Part 16: Mini-Games

Posted on Sunday, July 8th, 2012

Mini-games within the application help to maintain a large varriety in the entertainement process. They challenge the player in other fields than answering questions.
Through the various systems on which the application will be able to run, every mini-game itself determines what requirements it has to be playable on the current system
Before the individual mini-games are developed, these were roughly designed in the storyboard phase.

Sketches of possible mini-games

Sketches of possible mini-games

Catch All and Catch Selected
The games “Catch All” and “Catch Selected” are two mini games that do not work with touch input, but are controlled by the motion detection using a webcam.
Both games are consistent with the concepts of “moving school” or the “dynamic learning”. These state that learning can be improved if the students have to move around. In addition, the movement is a change from the otherwise sedentary playing experience, compensating the inner urge to move.
Both Webcam games have the task of catching falling objects. While in “Catch Selected” just the right answers to a question should be caught, in “Catch All” all objects should be collected.
Catch All in a modified version at CeBIT 2012

Catch All in a modified version at CeBIT 2012

Since the players in front of the camera needs room to move, the maximum number of players in these two mini-games is limited. But also with regard to the use in the school these players limit is reasonable. If a higher number of players would play it could happen that the players start to jostle in the competition situation to have an unfair advantage. This is prevented by the limitation.
(Note: The game can be played here in a modified form: )
Quick Select
“Quick Select” is a reaction game. Similar to “Catch Selected” the players will be asked questions or given sentences that must be completed. Corresponding solutions are shown by time, so you can see only one answer. Does the player see the correct answer to the question he has to push his “buzzer” or its player key on the keyboard. Is the question answered correctly, points are added to his account and the next question is asked. At a wrong answer and the game continues.
“Quick Select” is the only mini-game where a player can respond to a question several times. With this second chance he can compensate for a wrong answer.
Since the game can be controlled with keyboard and touch input, there are no restrictions on the number of players or the existing hardware, so it is playable on any device.
Defend Your Base
Defend your base in an early version

Defend your base in an early version

The mini-game “Defend Your Base” is from the genre of “Tower Defense games” (abbreviated TD). Task in this kind of game is to defend the own base. In conventional TD games, it is the responsibility of the player by building defensive structures (usually turrets or towers, hence the term “tower defense”) to defend their own base.
In the implemented version the attacker, represented by red circles, has to be “crushed” with the players fingers. This mini-game was implemented to train the hand-eye coordination of the player.

By the simultaneous interaction at different locations on the screen at the same time, the multi-touch capabilities are completely exhausted in this mini-game.
Since the control via mouse only allowes the interaction with one point at a time, the game is by this type of control more difficult than via touch.
Moreover, the use of the mouse limits the number of players to one person, while on multi-touch devices a higher number of players is possible.

Upcoming blog entries
Making The Game – Part 17: Evaluation and deployment of the application
Making The Game – Part 18: Concept for school use and outlook


Making The Game – Part 15: Game stages

Posted on Sunday, July 1st, 2012

Gameplay, the user's perspective

Gameplay, the user’s perspective

The development of the component of the Games is one of the most elaborate parts of the application. So during the analysis and design phase of the game a flow chart from the players perspective is created (see right).
After choosing the ammount of players in the round, the general procedure is explained to them, after which a short intro is played before the question shows up. After the fourth and eighth round of questions a mini-game starts in order to create variety in the game. After the second mini-game the high score is shown and the game is over.
As the players point of view is different from the programmers perspective, another chart is used which divides the process / the game into eight stages. By this classification it can be determined based on the current phase number, which part of the game is currently running. After finishing a phase the next is started. By this seperation the application is much like a film which parts run piece by piece on players command.
After the selection of the number of players main function game_init() which takes you through the different phases is called.
Description of the phases:
„ON AIR“ Logo from the game intro

„ON AIR“ Logo from the game intro

Phase 0:
On the first function-call an external *.swf file is played, in which the user is greeted by the game show host. The number of rounds is increased. And while the greeting-sequence plays the 1st Phase is already being called.
Phase 1:
In the first phase, all necessary variables are initialized and reset to its original value, so the round can easily start from scratch.
This also means that all player levels are reset to level 2, the balances are zeroed out the previous rounds and the list of previously asked questions will be emptied. The reset is done because it is assumed that the players take turns in front of the device and compete in each round with new candidates.
Furthermore, the background and other graphical elements such as the category display and “Buzzer” of the player are positioned.
Since this phase happens during the intro we have to wait until its end before we continue.
Phase 2:
Phase 2 of the game is the instruction phase. The control of the game and the rules are explained to the player. This is shown graphically a animation of the “Buzzer”.
After the instruction the game continues to the first actual game phase.
Cutscene before Question 1

Cutscene before Question 1

Phase 3:
The third phase of the game is the entry point for each new question asked in the game.
A random question is selected in it while the player sees a slightly funny designed intro-sequence. This includes the number of the current question that the candidate keeps track of how many questions he has already been answered. At the end of the intro to the category of question, and the obtained points are displayed and read aloud.
Phase 4:
After the intro finishes playing and the players know the category, they will be directed to the question. It is either used one of the standard transitions or, if available, the stored audio file in the already mentioned “Pretalk” entry in the question database.
Furthermore the question appears in phase 4 and is read. While the question is read, the “buzzer” is disabled, so that everyone knows the complete text. Thus is made in this version to prevent players to rush into answering.
Phase 5 / 6:
From this point where the four possible answers are displayed, the players have the chance to answer by pressing their “buzzer”. If the last answer is read Phase 6 is called which stars a ten-second countdown.
If the countdown expires, or a player answers the question correctly, the statement read to the correct answer and the points are distributed.
Question with four answers

Question with four answers

Phase 7:
The last phase of the game is the verifier. In it all text fields, that have been animated during the quetion, are returned to their original position and the “buzzer” is disabled for all the players again.
In addition, it is checked how the game should proceed at this point. Thus, after the fourth and eighth round a mini-game is selected at random to create a change between the question and answer sessions.

Many games use such phases or loops to control their process. Simple jump-phases at a jump ‘n run game or a running countdown use this method. By dividing the application into simple parts the application always knows what has happened, what’s happening now and which step needs to be done afterwards.


Upcoming blog entries
Making The Game – Part 16: Mini-Games
Making The Game – Part 17: Evaluation and deployment of the application
Making The Game – Part 18: Concept for school use and outlook


Making The Game – Part 14: Knowledge base and question selection / Working with XML

Posted on Sunday, June 24th, 2012

The knowledge- or question-base is at the heart of the program. Here are all questions and answers listed by category. Because it should not be required to create audio files for each of these databases, the first lines of the XML file tells the program if the questions are read aloud in the game or only appear textually.


  1.  <CATALOG>
  3.         <ITEM name="audio">true</ITEM>


(Note: The application and the decision to record all audio parts manually now are six months old. If I would create this app now, I would try a different approach and fall back to a TTS-API, such as the unofficial Google TTS-API.)


Each question in the catalog is marked by a unique identification number. Whith the ID the question could be accessed directly in an authoring tool. She is also an indicator how many questions already have been created in a category.


The possible number of points for the question reflects the difficulty. The lowest value that can be given for a question is 1000 points, which corresponds to the players level 1. Higher levels are valued with 2000, 3000, … Points. There is no upper limit at the points classification but it should be avoided to create questions higher than 4000 points, as the player loses points from incorrect answers, which could quickly lead to high levels of frustration.
The most important entities in the XML file are the question, the answers and the number of the correct answer. It includes the question text, which appears in the animated program, and the four possible answers.


  1.  <CATEGORY name="Das Internet? Gibts den Blödsinn immer noch?">
  3.     <ITEM name="category">catalog/cat/cat7.mp3</ITEM>
  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.  …


As seen in the extract from the general knowledge database, the linking of the individual audio components is a large part of the structure.
(Note: And actually, I should have used a fixed convention to determine how the files are named so that thay could automatically, so that I could call them without entry in the XML-file … -.-)


The name of the individual audio items correspond to the textual parts, so it is easy to see which sound file corresponds to a text section.
The only exceptions to this are the entries “pretalk” and “correct”. The recording tells the information of the “correct” entry, but also gives an expanded explanation of why the answer is correct. In the game the audio is played, once the solution of the answer appears.
By using the “pretalk” entry the lead author of the questionnaire can add a brief description of the actual question to set the scene. The entry is optional and must not be used.


The random selection of a question during the game is done automatically by calling the function selectQuestion() (see code below). This verifies if a game is played at the moment or whether it is requested outside of the game, which happens for example in the training mode. Is a game round currently in progress, the current player level for subsequent validation checks is taken.


From a random category a random question is taken. To ensure that the question is in the range of player level it is checked against the current level value. In the next instance it is determined whether the ID is part of the list of already asked questions.
Is the question outside the player levels, or was it already called ​ a new question will be selected at random. This process is repeated until a question has been found that satisfies both conditions.


  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.     }
  8.     var categorySelected:int;
  9.     var questionSelected:int;
  10.     var simpleCounter:int = 0;
  12.     do {
  13.         simpleCounter++;
  16.         var categoryAmmount:int = basicXMLCatalog.CATEGORY.length();
  18.         // select one category randomly
  19.         categorySelected = randomNumber(1,categoryAmmount);
  22.         var questionAmmount:int =
  23.              basicXMLCatalog.CATEGORY[categorySelected1].
  24.              QUESTION.length();
  26.         // select one question randomly
  27.         questionSelected = randomNumber(1, questionAmmount);
  29.         // check if the question is in the current level-range
  30.         var possiblePoints =
  31.                 basicXMLCatalog.CATEGORY[categorySelected1].
  32.                 QUESTION[questionSelected1].ITEM.(@name=="points");
  33.         var outOfRange:Boolean = true;
  34.         if(possiblePoints <= lvl*1000){ outOfRange = false; }
  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.         }
  44.         // failsafe… no questions… go out of level-range
  45.         if(simpleCounter > 20){ outOfRange = false; }
  47.         // failsafe #2… just ask a question again
  48.         if(simpleCounter > 40){ alreadyAsked = false; }
  50.     // search until the question was not already asked
  51.     } while (outOfRange || alreadyAsked);
  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);
  57.     // save the question data
  58.     question_currentXML =
  59.              basicXMLCatalog.CATEGORY[categorySelected1].
  60.              QUESTION[questionSelected1];
  62.     // return the xml-data
  63.     return question_currentXML;
  64.  }


As it can not be ensured by the program that sufficient questions are stored in the knowledge base, an emergency strategy must be selected. Thus, to find after twenty fruitless passes, an appropriate question outside of the player’s levelis chosen.
If no question could be found for another twenty runs also questions, which were already asked, were also allowed again. This will ensure that the game could be played through with badly created knowledge bases.

If a question has been chosen and it is rated as suitable, its ID is added to the list of asked questions, all relevant data is read from the XML file, and cached for future use.


Upcoming blog entries
Making The Game – Part 15: Game stages
Making The Game – Part 16: Mini-Games
Making The Game – Part 17: Evaluation and deployment of the application
Making The Game – Part 18: Concept for school use and outlook