A cross-media game environment for learning

Bachelor Thesis A cross-media game environment for learning Robert Fohlin 2010-11-09 Subject: Media Technology Level: C Course code: 2ME10E

Abstract Cross-media games are evolving as a new exciting platform for gaming where different devices are used to create a type of game play were a variant of devices, such as mobile phones and laptops are used. This thesis investigates the possibility of merging cross-media games into the domain of Mobile Learning to create a type of mobile learning game where collaboration becomes a vital part of the game play and style enhances collaboration between the users. By studying cross-media games, key features are captured and converted into requirements that are realised in a prototype that enables cross-media gaming with the intention of creating an environment in which learning could be supported. The development process of the prototype is described and evaluated in the thesis. The result presents a categorization of the key features for cross-media gaming and a prototype of a cross-media game. The thesis investigates which are the key technical features for creating cross-medial games for learning that can be identified for supporting the development process? The results presents a categorization of identified features along with potential future work based on the thesis. It is shown that features related to data sharing are highly prioritized and that certain features are absolutely required to enable cross-media gaming whilst others have less priority. Keywords Cross-media gaming, Collaborative gaming, Mobile Learning, Location-based gaming.

Table of Contents 1. Introduction...1 1.1. Purpose and goal... 1 1.2. Research question... 1 1.3. Limitations... 2 1.4. Disposition... 2 2. Theory...3 2.1. Cross-media gaming s relation to mobile and collaborative learning... 3 2.2. Related research... 5 2.2.1. Pirates!... 5 2.2.2. Uncle Roy All Around You... 6 2.2.3. Can You See Me Now?... 7 2.2.4. Savannah... 7 2.2.5. Capture the Flag... 8 2.3. Feature identification and analysis... 8 3. Conceptual design and methods...12 3.1. Prototype game concept... 12 3.2. Feature requirements list... 14 3.2.1. Summary of the requirements... 17 3.3. Development method... 17 3.4. Prototype testing... 17 3.4.1. Requirement validation Software testing... 18 3.4.2. User testing... 19 3.5. Development tools... 19 3.5.1. Java VS Flash... 20 4. Validation...22 4.1. Technical implementation... 22 4.2. Prototype tests... 28 4.2.1. Software testing... 29 4.2.2. User testing... 30 4.2.3. Test result analysis... 30 5. Discussion and concluding remarks...33 5.1. Result... 33 5.1.1. Game play observation... 37 5.2. Lessons learnt... 37 5.3. Future work... 38 6. References...40 Appendix A: Questionnaire...43

Table of figures FIGURE 2.1. CONVERGENCE BETWEEN LEARNING AND TECHNOLOGY (SHARPLES ET AL, 2005)....4 FIGURE 2.2. THE ABSTRACTED FEATURES, AND IN WHAT PROJECTS THEY WERE CLEARLY REPRESENTED...9 FIGURE 3.1 FLOW CHART OVER SKATTJAKT....13 FIGURE 3.2. FLOWCHART DESCRIBING THE GAME FLOW OF THE PROTOTYPE... 14 FIGURE 3.3. TABLE SHOWING THE WORKFLOW OF THE THESIS, ADAPTED FROM SOMMERVILLE (2007)....18 FIGURE 3.4. THE PHASES OF SOFTWARE TESTING (SOMMERVILLE, 2007)... 19 FIGURE 3.5. FLASH VS JAVA PLATFORM COMPARISON....21 FIGURE 4.1. SCHEMA OVER THE PROTOTYPE... 22 FIGURE 4.2. DATABASE SCHEMA FOR THE SQL DATABASE STORING THE GAME DATA... 23 FIGURE 4.3. PROCESS OF RETRIEVING NEW TEXT MESSAGES....24 FIGURE 4.4. SCHEMA SHOWING THE FLOW OF THE LOCATION AWARENESS.... 25 FIGURE 4.5. SCREENSHOT OF THE DESKTOP CLIENT AND ITS MAP MENU... 26 FIGURE 4.6. SCREENSHOT OF THE DESKTOP CLIENT S INTERFACE... 27 FIGURE 4.7. SCREENSHOT OF THE MOBILE CLIENT S INTERFACE....27 FIGURE 4.8. DIAGRAM OF THE ADDED DATABASE ENTITIES... 28 FIGURE 4.9. QUESTIONNAIRE RESULTS... 32 FIGURE 5.1. TABLE OVER THE REQUIRED FEATURES IDENTIFIED... 35 FIGURE 5.2. TABLE OVER THE RECOMMENDED FEATURES IDENTIFIED... 36 FIGURE 5.3. TABLE OVER THE OPTIONAL FEATURES IDENTIFIED... 37

1. Introduction During the last decade, massive improvements have been done in different parts of society due to the introduction of IT infrastructure and services. The health care have been massively improved, security has been modernized to utilize new technology such as IT that have been developed during the last years. Learning however still looks pretty much the same as it always has done. It is assumed that learning takes place within a classroom, the same way that it always have been done. However, new devices such as mobile phones, PDA s and laptops provides a new environment in which learning can occur outside of the classroom, however, this is rarely implemented. Chan and colleagues (2006) state that many countries are aware of those advancements are needed to be done in their education reform; however, they do not how to achieve this and are not willing to risk making changes to an educational system that has in many ways worked in the past. A new, exciting, type of game play that has been developed over the past few years is cross-media gaming, defined by Lindt et al., (2005), as a game that is played over different type of devices. However, in most cases, games developed within this domain have had focus on entertainment rather than learning (Cheok et al., 2006; Flintham et al., 2003). Usually these types of games are location-based, meaning that they use positioning techniques in their gameplay. This type of technologies can be used to support situated learning (Lave & Wenger, 1991) meaning learning that takes place in the same context as it is applied in. These connections, between mobile learning and cross-media gaming could provide a new type of learning environment for students. An example of a game where situated learning was introduced via the use of mobile games is Environmental Detectives (Klopfer & Squire, 2008) were a mobile game was developed that was used for freshmen s at a university s environmental science program. The goal of the game was to let the students go out and collect data about the environment in order to investigate a simulated toxic spill. This game allowed the students to take part in learning activities outside of the classroom. 1.1. Purpose and goal There is currently a quite limited amount of research done about collaboration that takes place across different type of device platforms, such as a combination of mobile and stationonary devices (Uden, 2007). By combining mobile and stationary devices, a new type of learning environment could be provided for students. This thesis tries to identify key features that, from a technical point-of-view, could provide the possibility to develop collaborative games across different platforms. In order to verify the features, the identified features will be analyzed and implemented into a prototype that enables cross-media gaming with possibility to be used within mobile learning. In the conclusion, the importance of these different features will be discussed. 1.2. Research question Due to a relative limited amount of experience within the domain of cross-media gaming, few guidelines regarding the development of that type of game exist. Lindt et al., (2005) do provide a few guidelines for cross-media game development, but these are fairly limited. In order to integrate the domain of cross-media gaming into the domain of mobile learning, a set of guidelines could be useful to clarify issues that could need to be dealt with in regard to the development of that type of games. In 1

order to improve the guidelines for cross-media game development, key features that are commonly occurring in the genre could be identified, summarize these and provide a basic idea of what a cross-media game needs to contain. To clarify what a feature is, the Institute of Electrical and Electronics Engineers or IEEE (1998) defines a software feature as an a distinguishing characteristic of a software item, for instance, a functionality in a system. Therefore, the main research question to be explored in this thesis can be formulated as: Which are the key technical features for creating cross-medial games for learning that can be identified for supporting the development process 1.3. Limitations This thesis focuses on the development of cross-media games. Even though the purpose of the prototype is to enable cross-media gaming that could support learning, the thesis will not investigate the effect the prototype may have on the learning process of the users, but rather focus on identifying the key components needed to develop this type of game from a technological point-of-view. The purpose of the thesis is to identify key features for cross-media games that could support learning, however, in the thesis there shall be no focus on the learning process or evaluation of the learning experience. 1.4. Disposition The first section of this thesis will introduce the theory of mobile learning, collaborative learning and cross-media games to the user. It also includes a literature study of research projects which relates to cross-media gaming and mobile learning. The second section of the thesis will present a set of features which will be implemented into the prototype based on the findings from the previous section. This section will also contain the method used to develop and test the prototype. The third section will present how the features from the previous section was implemented in the prototype along with an validation of those features. The fourth and last section in the thesis will present the result and discussion based on the findings of the previous sections. It also includes a short sub-section which discusses potential future work that could be done based on the findings in this thesis. 2

2. Theory In order to identify what key features relates to cross-media game development, a review of related research has been performed within the fields of cross-media gaming, collaborative and mobile learning was carried out. The first part of this chapter will explain the concepts of cross-media gaming, mobile learning and collaborative learning. The purpose of this is to define what the different concepts means, how they relate to each other and why creating location-based cross-media games that use mobile technologies and promotes learning can be beneficial for increasing collaboration between students. The second part of the chapter will review research projects, which relates to cross-media gaming and mobile learning. In reviewing these related projects I hope to identify key features from these efforts, which can later be used as a base for the requirements. 2.1. Cross-media gaming s relation to mobile and collaborative learning Lindt et al., (2005) defines cross-media gaming as a type of pervasive gaming, games that are played across different devices and across different physical and virtual spaces. Examples of cross-media games are Uncle Roy All Around & Can You See Me Now (Flintham et al., 2003) and Epidemic Menace (Lindt et al., 2006). These are all games that combine the use of mobile devices with stationary platforms to create a unique type of gaming experience where collaboration or other types of interaction between the players are a vital part. In these examples of cross-media games, the games are location-based. Kiefer et al., (2006) define a location-based game as a game that is supported by localization technology and integrates the position of (one or many) players as a main element into its game rules. Games that are location-based can support situated learning approaches; a type of learning that is defined by Lave & Wenger (1991) who argue that learning that takes place outside of a traditional classroom environment can provide pedagogical benefits. The benefits of situated learning can be linked to mobile learning, as stated by Sharples et al., (2005) as they define new learning as situated and that this is supported by new technology through the feature of mobility (see figure 2.1). A common way of describing mobile learning is to say that it is learning which occurs or is supported through the use of mobile devices, such as mobile phones, PDA s and laptops, are all examples of devices that normally are used in cross-media gaming (Schwabe and Göth, 2005). However, Vavoula (2005) argues that there are more dimensions of mobile learning that should be explored. That could be summarizes them into the following: 1. The use of portable technologies. 2. Spatial mobility, the learner who moves between different learning settings. 3. How the learner can alternate between different tools and topics of learning. Moreover, Sharples et al., (2005) state that what makes mobile learning special to other types of learning activities is that it enables learners to learn while being on the move. This enables learners to take information gathered from one context and apply or develop them in another context. They continue by stating that new learning and new technology is related (see figure 2.1), their claims further support the link between situated and mobile learning. And by referring to Brown et al., (1989), 3

which states that learning today should be considered situated and collaborative provides a link between mobile learning, which is using new technology, can be drawn to collaborative learning. Figure 2.1. Convergence between learning and technology (Sharples et al., 2005). Dillenbourg (1999) defines collaborative learning, as a situation where certain forms of interaction between people are expected to occur that would trigger learning mechanisms. However, to make this happen, Dillenbourg(1999) continues by stating that it is important to carefully design the situation where this learning is suppose to take place. Moreover, another issue stated by Wood & O'Malley (1996) is that the potential of collaborative learning is rarely fulfilled to its highest potential in classrooms. Once again referring to Sharples and colleagues (2005) argue that mobile network communication enables people to collaborate and share information and knowledge regardless of their location. To further support the link between mobile and collaborative learning, research have shown that introducing technology supported learning, such as mobile learning can provide students to efficiently collaborate over the devices. Research has also shown that this type of technologysupported learning can result in increasing the students motivation (Corlett et al., 2003; Zurita et al., 2004). To summarize, the links identified between the concepts described above, can all be linked to new learning and its new characteristics that ties them all together. For example, the situated characteristic of new learning is related to the benefits of mobile learning, which allows situated learning to occur. Cross-media gaming can also be related to the situated characteristic as such, as mobile learning, allows the user to be on the move and placed in a situation outside of the classroom. Furthermore, the collaboration characteristic of new learning can be related to the networked characteristic of mobile and cross-media gaming. This shows that the different concepts complement each other, and that benefits from the different concepts are related to characteristics from each other. 4

2.2. Related research In order to identify key features in cross-media games with focus on learning, this section provides a literature study of mobile applications featuring cross-media gaming and mobile learning. Since this thesis is focusing on the technically key features of developing a cross-media learning game, rather than the key features for learning a literature review of related projects seemed like the best way to determine what key features and requirements were required. These projects where identified by searching in academic databases such as Google Scholar and Voyager, or from papers and articles passed on to me from my supervisor. The following key aspects were regarded when selecting the sources: It should be related to mobile and cross-media gaming. It should present a working prototype or game that can be reviewed. It should discuss a technological and design aspects related to its implementation. The purpose of this section is to identify characteristics or features that can be found in different related projects and try to tie them together. The exact requirements of the prototype will be defined later in the thesis. At the end of each sub-section of the related research projects, a list of key features or characteristics from the specific project will be listed and briefly explained. These will then be used in analysing common features and be used as a foundation for creating the requirements for the prototype. 2.2.1. Pirates! Pirates! (Björk et al., 2001) was a research project performed by Nokia Research Centre and the Play Research Studio at the Interactive Institute in Sweden. The aim of the project was to create a context-aware computer game experience and to explore how computer games could be designed for social settings. Pirates! is a multi-player game, which was implemented on handheld computers connected to a wireless local area network. The purpose of Pirates! was to create a game where real world properties, like locations, objects and the relationship between two players real-world positioning would be essential elements of the game. In the game, the players movement pattern is used to trigger different game events. The game takes place in a fantasy world, where each player takes the role of a captain of a pirate ship. The players movement in real world are used to move their ship around, and the players can explore different island and other parts of the game world to increase the level of their captain. The players can also challenge the other captains in battle by moving into the area of their ship and perform attacks against them. The game was run with a client-server approach, using one central server that stored the game logic and collected data from the different mobile clients. The server also stored all the media and graphical files that were required for the game, and on the request of the users, these files were returned to them. Key features identified: Media file management, storing the media files and graphics needed for the game and enabling them to be played or showed when required. 5

Context-awareness, enabling the system to use the players location as data for the game. Location-based triggering, trigger events based on players positioning. 2.2.2. Uncle Roy All Around You Uncle Roy All Around You (Flintham et al., 2003) was a research project where a gameplay was created that mixed physical and virtual worlds. The game consisted of online and street players that interacted together to achieve the objective, to find Uncle Roy s office. The street player was handed a PDA and made their way around central London, following the clues in their PDA in their search for Uncle Roy. Meanwhile the online players observed the street players progress in a parallel virtual world and tried to help them. The street players were searching the city for clues about Uncle Roy while the online player could interact with the virtual world in order to find hints and clues that could help the street player. To be able to interact with each other the players could use different ways of communicating with each other. The online player could send the street player text messages, containing vital information about the surrounding areas and hints about the location of Uncle Roy s office. The street players could in return upload short audio messages to the online player, and in such establish communication between the two. When implementing Uncle Roy All Around You, Flintham et al., (2003) identified the following requirements for enabling the game play: Handling text and audio messaging; Loading colour maps and associated clue trails and serving clues; Queue management so that only a limited number of online players where admitted to the game at any one time; Using a SQL database to store persistent game information (player details and state); Communicating with remote clients including street players clients implemented in Flash and online players clients implemented in Shockwave. Another notable aspect of the Uncle Roy project was the way they decided to approach the positioning of the street players. From previous experiences the researchers had acknowledged that GPS positioning could be inefficient in a city environment. This lead to the researches creating their own approach to dealing with the positioning, called self-reported positioning, where the player reports in his position manually. Key features identified: Media management, storing recorded/captured media. Retrieve and play media related to the game, such as audio and video. Database management, store game information, player details, player states, media etc. Location tracking, keeping track of the real-world position of the real-world player. 6

Communication component, enabling real-time communication between the different players. Could be text-based or audio-based. 2.2.3. Can You See Me Now? Can You See Me Now (Flinthman et al., 2003) was a project, involving player versus player gameplay across different screens. The idea of the game is that up to 20 online players using laptops or desktops, were chased on a map by professional runners who where moving through the actual streets of what the map represented. The runners and the players all shared an online map. The players position was determined by their online interface while the position of the runners were determined using GPS. If a runner came within 5 meters of any one of the players, that player is caught and out of the game. The runners communicated using walkie-talkies and the players could overhear their communication, this was done to make the online players feel closer to the street. The online players used simple text-chat to talk with each other or the runners. Can You See Me Now does not offer any significant collaborative gameplay, but it still shows on interesting ways of bringing people who are using different type of devices into the same game. It also presents an interesting challenge of simultaneously moving the online and real-world players around in the same game-world. Key features identified: Location-based tracking, trigger events based on the location of the player. Location-awareness, be able to track the players position. Synchronization, synchronize the data between the mobile and desktop clients. Text-chat between players, allow players to communicate via chat. 2.2.4. Savannah Facer et al., (2005) studied a collaborative location-based game called Savannah. In Savannah a group of students play the parts as lions on a Savannah, and must work together in order to explore the savannah and find prey to hunt. The game doesn t run across several screens, but it does provide an interesting approach to how the realworld players interact with the virtual game-world. In the game groups of six children role-play being lions exploring a virtual savannah. The players move around on a game-field on about 90x60 meters and based on where on the field they are, new areas of the virtual savannah opens up. The game required collaboration, the students had to choose what animals on the savannah to attack, and how many of them that should perform the attacks. The game uses location-based triggering, which means that the users enter discretely bounded spatial locales in order to trigger events. This is a very common feature in location-based games. It works as follows, the user reports in his/her position, manually or automatically. The game server receives the user s position and if that position is meant to trigger an event the server returns the event. Facer et al., (2005) also bring up the issue of synchronization, in this case it s necessary to make sure that there is only one ongoing attack in a given local at any time, so that there can not be several attacks occurring on different animals in the same area at the same time. Another interesting feature in the game is the Den, an application developed to be able to follow the different players and analyse their movement and actions in the game. This could be used both during and after the game, the ability to be able to 7

visualize how the game played out could be a vital feature in order to evaluate how the players understood the game and how they used the different features of the application. Key features identified: Synchronization, some form of locking, which prevents a unique event to occur multiple times. Location-based triggering, an event handler, which analyses game data from the users and activates events when needed. Post game analysis, the ability to store the game data and analyse it after the game. Sharing game data, sharing the state of the different players between the different devices. 2.2.5. Capture the Flag Capture the Flag (Cheuk et. al., 2006) was a research project that tried to transform the popular outdoor game capture the flag in a mixed environment where the physical world and a virtual world was combined. Each team consisted of two players, a knight real world player) and a guide (virtual-world player). The knight uses a PDA and GPS-sensor to move around in the real world, moving his character in the game-world by moving in the real world. The guide uses a desktop client to assist his teammate. The objective of the knights is to interact with the real world, capture flags and to avoid warriors and traps, objects which are moved in the virtual world by the virtualworld player of the opponent team. Real-world objects that the knight can pick up represent the flags, when this occurs the communication framework ensures that the guides computers are updated to show the new status of the knights. The guides, or the virtual-world player can affect the game outcome by placing magic potions and traps in the world. Magic potions have a positive effect on the teammates of the guide and the traps are used to capture the knights of the opposition. Throughout the game, the players can communicate using text-messages. This communication is vital to succeed in the game, because only the guides can see the positions of the magic potions and the enemy traps. So it s vital for the guides to communicate this to their teammate. The game ends when the enemy s flag is captured and returned to the home base of the knight. Key features identified: Virtual-game-world interaction, the players, both virtual-world and real world, have to be able to interact with the game world. Communication framework, as described above, the communication framework has to provide updates on the different players statuses. E.g. if a knight picks up the opponents flag this have to be visible for the guide. Team awareness, the system has to be aware of what team each player belongs to. 2.3. Feature identification and analysis Based on common features from the literature review in the previous section a set of feature concepts will be described and analysed. The purpose of this effort is to define a number of concepts that later can be implemented in the prototype. 8

Figure 2.2. The abstracted features, and in what projects they were clearly represented. On frequently occurring feature among the projects from the previous section is the ability to share persistent game data. For the applications/games to be run properly over different platforms there is a need to be able to share the game data among the different clients. The data related to the game that needs to be shared does usually seem to be shared through a database. Another feature that would require data to be shared between 9

clients is the feature to allow communication between different clients. To let the different participants of the game communicate with each other is also a common feature among the presented projects. In some cases, like for instance Capture the Flag communication is only allowed between teammates. To determine what players that are teammates the system have to be able to determine what team the player belongs to. This feature is seen in Capture the Flag where the online player is only able to see where his teammate is, and the system is therefore required to have some form of team awareness. In the projects reviewed above it is necessary for the system to be able to track the location of the players, location-awareness is required. In the literature study there is different approaches to this, some use GPS-technology, others such as Uncle Roy All Around uses a self-reporting system. Whatever technology is used, there is a need for the systems to track the positioning of the players. In some cases, such as Uncle Roy All Around You and Pirates! the media files for the game are stored on a server, and uploaded to the clients when it is necessary. This makes it necessary to have some form of media file management, which retrieves the requests for media and returns the files required. In Uncle Roy All Around You, the street player has the option to record short audio messages, and then upload these to the game server and share them with his online partner. This would be another type of action that would be performed by the application s media file management. It is also important for the players of the game to be able to interact and affect or be affected of the virtual game world. An example of game world interaction can be seen in Savannah, where the players positioning in real-life are used to determine if they are within reach of any of the animals they are hunting. And if so is the case, then they can choose to attack these animals. Another example of game world interaction can be seen in Capture the Flag, where the online player can place traps and powerups in the game world, which the real world player can be trapped by or collect in order to gain power bonuses. Synchronization is another feature that can be identified from the literature study. In Can You See Me Now? and Savannah there is a need to synchronize the game data in order to prevent certain actions to occur several times and to ensure that the game data is consistent over all the clients. For instance, in CYSMN the positioning between the street players and the online players where synchronized, so that any delay on the network used to connect the different clients, would not have any major affect the gameplay. As shown in Capture the Flag and Can You See Me Now there is sometimes a need for the players of the different platforms to be sharing the game world. As both the clients operate within the same world and can affect that game world, it is necessary to ensure that all clients are part of the same game world. The features described above have been identified as key features as they have been commonly identified in the literature review (see figure 2.2) and as such will be considered in the prototype game concept. The importance of these features will be validated in the latter stages of the thesis, based on the test results of user and software testing. The features have been identified as important as they have been a clear characteristic of the games reviewed, as for example, the game-world interaction of Savannah is the main element of the game along with the location awareness, same goes for Capture the Flag where these two features along with communication between clients are vital and obvious features of the game. The media file manager has been identified in several of the projects, and is therefore considered an important feature that should be taken into consideration when setting the 10

requirements for the prototype. All of the features that have been identified in the literature review will to some extent be implemented into the prototype to allow a fair evaluation of that requirement. Furthermore, another aspect has to be taken into consideration: How can learning be supported in a game of this stature? As stated in the introduction, the purpose of this thesis is to investigate what features is needed to create a platform on which learning can be supported across different screens. So clearly there is a need to be able to introduce learning into the system as well, however, as stated in the limitations in the previous chapter, the key features identified should be tied to the technological aspects of the system and not the learning. In the prototype at each task the players will be given a question about the University of Hertfordshire or Hatfield (the town where the University is located) that they will have to answer. A correct answer will give them a bonus point while an incorrect answer will deduct points from their total score. This approach is based on common-knowledge about the area, rather than actually supporting any learning. However, these questions could be changed to promote learning by using learning resources supporting, for example, math or history. An example of this type of material is provided by Bletchley Park (2010), where the learning resources about World War II have been created for teachers to use and download. A possible game scenario could be based on this, were this material is introduced into the gameplay. In the next chapter the findings presented in this chapter will be used to define a game play for the prototype that considers key features identified from the reviewed projects in this chapter. 11

3. Conceptual design and methods This chapter will begin with introducing the game concept for the prototype that will be developed. Based on this concept and along with the abstracted features from the previous chapter a requirement list will be created that can be used for creating the prototype. Furthermore, the chapter will also introduce the development methods chosen for the prototype. 3.1. Prototype game concept In order to set the requirements of the prototype, this part describes the game concept that will be used for developing the prototype. In creating the game concept, the features from the previous chapter were considered, and taken into account in order to ensure that there was a need to implement these features in the prototype. Game idea In the game, two players must work together in order to break into an enemy complex and steal important information about the enemy s military. The desktop player, or the intelligence agent as he will be called has been provided with a satellite-system that covers the complex area. He must guide his teammate, the real-world player or field agent into the complex, make sure that he avoids guarding units such as choppers and drones. Inside the complex there are several security components that have to be breached in order to find the secret information. To make collaboration necessary for the players, only the intelligence agent will be able to see the enemy units patrolling the area while the field agent will be the one able to discover the exact location of the clues that needs to be unlocked and upload this information to the intelligence agent that can decrypt the gathered data and unlock where the next piece of information is located. Game flow The game flow for this prototype was expanded from a research project at the Center for Learning and Knowledge or CeLeKT at the Linneaus University. The project is called Skattjakt (Treasure Hunt in English) and is a mobile game, where students are split into groups and each group are handed a mobile phone. Using a map and instructions are given by the phone, the students make their way around a university campus answering questions about the history of the campus area. Skattjakt uses a self-reporting approach to reporting the players location; at each location the students are told to go to. They are given a code that once entered unlocks a question that they have to answer. If they answers the question correctly they are sent on to the next question, if they answers it incorrectly they are sent on a detour as a punishment (Spikol & Milrad, 2008), see figure 3.1 for a detailed flowchart of the game logic. 12

Figure 3.1 Flow-chart over Skattjakt. In this prototype a similar approach will be used, but with some differences. In this thesis prototype, the intelligence agent will be the one with information about the location of the different tasks are. It will be the intelligence agent s job to guide the field agent towards these objectives and unlock the task. And different to Skattjakt the prototype will unlock the tasks based on position of the mobile client, rather than using codes placed at each location. The task will then be unlocked to both the clients and the players can discuss the question by communicating with each other over the network. The game will end when the field-player reaches the final location or when the guards catch him, see figure 3.2. 13

Figure 3.2. Flowchart describing the game flow of the prototype. 3.2. Feature requirements list In this section a list of requirements will be created based on the features from the literature study from the previous chapter and some will be based on the game concept of the prototype. The requirements will be used to develop the prototype and this will be described in the next chapter of the thesis. 14

Requirement 1: Sharing persistent game data The system needs to be able to share data between clients. In both the mobile and desktop clients need to be able to access vital data about the game, such as locations, tasks, states of the different players etc. This is what the sharing persistent game data feature will provide. The system shall provide data to be shared between clients of different medias. Requirement 2: Communication between clients As stated in the game concept, the intelligence agent will have to guide the field agent by letting him know where to go, and to keep him/her away from the guards. To assist this, the teammates should be able to communicate with each other. The system shall provide a text-based chat for the players, which allows communication between mobile and desktop clients. Requirement 3: Team awareness As the prototype is meant to be able to be played by several groups at the same time, there is a need for the system to be able to identify what team a certain user belongs to. The system shall be able to provide the users with team-identification that can be used to determine what team they belong to. Requirement 4: Location-awareness It will be vital for the system to be able to track the field agent s real-world position. As the point of the field agent is to locate special locations where tasks will be unlocked, the system must be able to track his/her location in the real world. The system shall be able to track the position of the real-world player. Requirement 5: Event-based triggering In the prototype, it will be needed to trigger different events based on different factors, such as player position, player state and player input. The system shall be able to trigger events based on player factors. Requirement 6: Game-world interaction As stated in the game concept, the real-world player will be affected by content of the game-world, such as the guards movement. The system needs to let the players affect the game world and make their actions a part of the game. The system shall allow the players actions to affect the game world. Requirement 7: Consistent game data This requirement is based on what Facer et al., (2005) calls synchronization, where they mean that their system had to be able to synchronize the actions of the different players and make sure that nothing happened that wasn t within the rules of the game. 15

The prototype will have to ensure that the different clients all have data that is consistent. The system shall ensure that all connected clients are provided consistent game data. Requirement 8: Media file management As media files will be accessed from both the mobile and desktop clients, there will be a need to deal with these media files and distributed to the clients as needed. The system shall store and distribute media files to the clients when required. Requirement 9: Shared game world As both clients in the prototype will be needed to be aware of the events occurring on the game-area, it will be necessary for them to share the game world. To visualize this, it seems to be a good idea to let all players, virtual-world or real-world, feel like they are a part of the same game. For example, in Capture the Flag, both the players have a similar view of the game world. Of course the online-player has access to a more powerful device with higher screen resolution and can because of that be provided with a more detailed graphical view of the world. The system shall enable users of the different clients to participate in the same game world. Requirement 10: Network communication Due to the nature of the system, several clients split up over different devices, there will be a need for the clients to have network communication. All clients shall be able to communicate via network communication. Requirement 11: Storing post-game data This requirement is included based on the post-game visualization of Savannah. This gave the researchers the opportunity to study how the students went about solving the tasks and track their movement pattern. To enable this, game data will have to be stored in a way that makes it possible to replay the actions of the game and analyse how the game was played by the different teams. The system shall store the game data in such a way so it is possible to provide post-game visualization. Requirement 12: Time-awareness As the point system used in the prototype will be based on how quick you complete the game the system have to be able to track how long the clients has been active in the game. The system shall be able to track the amount of time it takes to play the game. 16

3.2.1. Summary of the requirements Based on the findings from the literature review and based on the gameflow of the planned prototype a total of twelve requirements were substracted and defined. These requirements were set with the focus of providing the functionallity to enable crossmedia gaming, while focus on the design and interaction-driven requirements had lower priority. 3.3. Development method As the development method for the prototype, a rapid prototyping approach was deemed to be the most appropriate one. In rapid prototyping, focus is on quickly delivering a prototype that can be tested. Unlike other more traditional ways of application development, rapid prototyping begins the development with a low amount of planning and requirements are changed throughout the development. Rapid prototyping begins with analysis of the needs and content of the system that shall be developed. Where rapid prototyping differs from other development cycles is that it runs parallel processes of design and research. With rapid prototyping it is assumed that the full understanding of needs, content and objectives is a result of the design process, rather than an input into it (Tripp & Bichelmeyer, 1990). The approach of rapid development is related to iterative development processing (Jakobsen et al., 1999). When developing iterative you develop the software in small, manageable steps. You plan a little. You specify, design, and implement a little. You integrate, test and run each iteration a little. Continue with the next (plan a little). By developing a software system iterative, it allows the developer to change the requirements as the system grows. This seemed a suitable approach to this thesis, considering that there is no input from any customers or potential users of the prototype before the development due to lack of previous work done about these type of games. The choice of rapid prototyping as the development approach is further supported by the fact that the development of cross-media games for learning is an unfamiliar situation. Tripp & Bichelmeyer (1990) claims that rapid prototyping have shown to be more appropriate as a development cycle in situations where there little experience from which to draw. 3.4. Prototype testing To evaluate the prototype, there will be two types of tests performed, software testing and user testing. The process and purpose of these two different types of testing is presented below. The reason for using different approaches is to validate different aspects of the prototype. The software testing will aim to validate the requirements defined in the previous chapter and try to identify if any requirements should be changed. The purpose of the user testing is to test the entire system together with users and evaluate how the features affected the users experience. 17

Figure 3.3. Table showing the workflow of the thesis with the two prototype- and test sections highlighted, adapted from Sommerville (2007). 3.4.1. Requirement validation Software testing In order to validate the requirements defined earlier in this chapter, software testing will be used to test and validate the technology. The purpose of software testing is, according to Sommerville (2007): 1. To demonstrate to the developer and the customer that the software meets its requirements. 2. To discover faults or defects in the software where the behaviour of the software is incorrect, undesirable or does not conform to its specifications. Furthermore, the two goals lead to two different types tests, validation testing; where the system is expected to act correctly given a set of test cases and defect testing; where the test cases are designed to make the system exposes defects. The two fundamental testing activities are component testing testing parts of the system and system testing testing the system as a whole (see figure 3.2). Component testing focuses on testing individual processes in the system rather than the system as a whole, the purpose of this type of testing is to expose faults within the different components as early as possible. An example of component testing would be to just test, for example, the GPS-positioning of a system or the chat-functionality of a system. System testing involves integrating two or more components that implements system features and tests them together, the purpose of this is to validate that the system meets its requirements. There are two phases in system testing that usually is used for most complex systems. Integration testing where the team testing have access to the source code and try to debug any discovered problems. And release testing where the team tests a version that could be released to the users. The purpose of this is to not to let the team debug any problems discovered but rather to report back any issues that occurred and then let the developers deal with them (Sommerville, 2007). In the system testing, a requirement-based testing will be used as a test case. This means the cases used to test the components are based on the requirements for the features of the system (Sommerville, 2007), which means based on each feature s requirements, a set of goals are listed for the test and validated. 18

Figure 3.4. The phases of software testing (Sommerville, 2007). 3.4.2. User testing The purpose of the user tests will be to see how the system works when users who are not familiar with the software uses it. However, as stated in the introduction (see Chapter 1), the main focus in this thesis is to evaluate cross-media gaming from a technological point-of-view. The users learning experience will not be evaluated from the user tests; however, a questionnaire will be given to each of the test users with the purpose of evaluating what they think of the concept of cross-media gaming with focus on learning, a long with a grade-based table where they will grade the importance of some of the features that is able for the users to identify, for example, text-chat between clients. After the test users have filled out the questionnaire a group interview (Sharp et al., 2002) will be held with them. The reason for choosing this approach to the interview is to allow the two players to share and discuss different opinions of the prototype. The purpose of this effort is to try to get further results that could help to evaluate the requirements. 3.5. Development tools This section is to justify and introduce the choices of technology for the prototype. The first decision that was made was what development tool should be used for the mobile client. The two tools that were considered in this case were Adobe s Flash Lite (Adobe, 2010a) and Sun Microsystems Java 2 Platform Micro Edition or J2ME (Sun Microsystems, 2010), which are both scaled down versions of Flash Player and Java 2 that have been developed to use for mobile devices. In deciding what software to use, a certain number of important features were compared between the two development tools. As the prototype shall be a crossmedia game, one of the key features to look for in the development tool is the ability to create cross-media applications is a vital one. These are the following key features that were considered: Cross-media development o The ability to develop and deploy applications for different devices. Rapid deployment o Low development time, easy to deploy to the devices. Cost o The cost of the development tool. Graphical User Interface development, GUI. o How does the software deal with graphics? Support for location-based applications for handheld devices o Does the tool support development for location-based applications? Availability o How many devices support Flash/Java? 19

3.5.1. Java VS Flash In order to determine which software development environent was best suited for developing the prototype, a comparison of the Java- and Flash-platform was made based on the seven key features explained above. Cross-media development In this case, Flash does seem to be the strongest competitor. Not only does Adobe Flash allow you to develop applications for both mobile and desktop platforms, but also the difference between the two are minimal (Economou et al., 2008). Rapid development In this case, Flash does seem to be the strongest competitor. Due to the object-oriented approach of development that Java uses and the timelinebased approach that Flash uses; the development time using Flash Lite to develop a project could only take 30-70% of the time it would take to develop the same project in J2ME (Rush, 2007; Economou et al., 2008). Cost This one goes in Java s advantage. According to Sumoela (2007), the J2ME development tool is available for free, while Adobe only have a 30-day free trial of Adobe Flash, then to get the full version a license have to be bought for $700. GUI When it comes to handling graphical development, the Flash-platform is the clear winner. According to Rush (2007) the Java development tool has a fairly poor support for graphical design while Flash provides a far better platform for developing graphical interfaces and can deal with far more complex animations. Location-based applications None of the two have any support built in for handling positioning data by default. However, there is API s available for both the languages to use that enables you to access the GPS-sensors of Nokia devices, these are both provided by Nokia, the Flash Lite Location API (Nokia, 2010a) and the J2ME Location API, JSR-179 (Nokia, 2010b). These are both fairly easy to implement and use so in this case there is no real advantage in using Flash or Java. No winner. Availability Today, both Java and Flash are well supported on mobile devices. However, there still seem to be a slight advantage for Java in this aspect. In the third quarter of 2008, the number of handheld devices with support for FlashLite reached 800 million, and during the two coming years the number is expected to increase with another 1.5 billion handsets (Strategic Analytics, 2008). However, today Java is close to being supported on any handheld device (Economou et al., 2008) and is supported by close to 70% of the handheld devices in the world (Morales & Nelson, 2007). 20

Figure 3.5. Flash VS Java platform comparison. Based on the comparison of J2ME and FlashLite as a development tool for the prototype, the decision was made to use FlashLite. This is based on the fact that FlashLite seems to have an advantage when it comes to the two key features in the comparison, cross-media development and rapid-development. The two features where J2ME has been the stronger of the two, cost and availability is not as highly prioritised as the others. Furthermore, Flash s ability to provide a simple drag and drop environment for creating the graphical interface should also be considered, as it allows the developer to quickly create a good-looking interface which can be implemented into the prototype. The next chapter will describe how the features defined in this chapter were technically implemented and how the prototype was put developed. 21

4. Validation Based on the methods discussed in the previous chapter, this chapter will describe how the prototype was developed and how the requirements were implemented in the prototype. Part one of this chapter will present how the prototype was developed and the requirements were implemented into it. Part two of the chapter will describe how the tests were performed and what results were found from the tests. 4.1. Technical implementation As described in Chapter 3, Adobe Flash was used as a development tool for developing the mobile and desktop clients. The mobile client was developed using FlashLite 3.1 and implemented on a Nokia 5800 Music Express. Using the Flash Lite Location API from Nokia 1 (2010), it was made possibly to utilize the sensor components of the phone, being able to use technologies such as GPS-positioning, text-messaging, etc, for an technical overview of the prototype, see figure 4.1. The development of the prototype was based on the rapid-prototyping approach and the requirements determined in the previous chapter. Figure 4.1. Schema over the prototype. Below follows a list of each requirement from Chapter 2 along with its definition and a description of how it was technically implemented into the prototype. Requirement 1: Sharing persistent game data The system shall provide data to be shared between clients of different medias. This requirement was simply implemented by setting up an SQL-database that which the different clients could query by using the PHP-scripts as the middleware, to send and retrieve data from the database. The data stored about the game in the database were player-details, message-details, device-details and waypoint details (See Figure 4.2). 22

Figure 4.2. Database schema for the SQL-database storing the game data. Other than the database, an XML-document based on the XML-structure used in Skattjakt (Spikol & Milrad, 2008), was utilized to structure each teams tasks that were to be involved in the game. The both clients upon start accessed this XML-document; this is further explained in the section below about Requirement 3. Requirement 2: Communication between clients The system shall provide a text-based chat for the players, which allows communication between mobile and desktop clients. The text-communication between the clients uses the message-details entity in the database, explained above under the implementation description for sharing persistent game data. To send messages, both the mobile and desktop clients enters the text-message they want to send, and then when posted the text is parsed along with the senders player_id, team_id as parameters into a PHP-script that then inserts the message into the database. To retrieve messages, the clients frequently (every second) queries the database by parsing its team_id and the id of the last message that it received and if any new message have been entered into the database, it is returned to that client (see Figure 4.3). 23

Figure 4.3. Process of retrieving new text-messages. Requirement 3: Team awareness The system shall be able to provide the users with team-identification that can be used to determine what team they belong to. Team awareness is a fairly simple, but vital feature as the prototype has to be able to make sure that certain data is only shared between clients that belong to a certain team. In the prototype, each team have a shared XML-document between them, in this document there is an attribute in the beginning of the XML-document that defines what team the XML belongs to. Upon starting the client, each client sends a request to the database with a unique id. The mobile phones use their device id, accessible by using the GetDeviceID in Actionscript (the language used for programming in Flash) and send a request to the middleware, the middleware will query the database for the link to the XML-document that belongs to that device-id and return the XMLdocument for that device. Then the application loads that XML-document and saves the team-id of that team as a variable in the client s application memory and uses it to identify what team the client belongs to. Requirement 4: Location-awareness The system shall be able to track the position of the real-world player. To be able to track the field-agents position in the real world, the Flash Lite Location API is used to be able to access the phone s GPS-sensors. The position of the player is provided to the mobile client by setting an update interval on 1 second on which the GPS-coordinates are updated. These GPS-coordinates are then converted to simple x and y coordinates to allow the position of the player to be applied onto a static map rather than, for example a Google Map-application. The reason for this is that Google Maps currently have quite bad support for integrating their maps on mobile devices, by converting the position into simple x and y coordinates the player s location can be 24

shown on the static map. To allow the desktop-player to see the location of his teammate, these x and y coordinates are frequently sent to the database via a PHPscript and the player s entry in the database is updated (see Figure 4.4). Figure 4.4. Schema showing the flow of the location-awareness. Requirement 5: Event-based triggering The system shall be able to trigger events based on player factors. In the prototype, the event based triggering is dealt with on the mobile client. In the prototype, the type of event-triggering that occurs if based on the position of the player. Whenever the player comes within a certain distance of a task or an enemy guard, a trigger should start an event. The event-based triggering uses the Game Orchestration Document to retrieve the coordinates for where the task is located, and the mobile client compares the location of the player to these coordinates and if the player is within a certain distance of the task then the task is triggered and unlocked to the player. For determining if the player under risk of being detected by the guards, the Actionscript build-in function hittest is used, which checks if the player s icon overlaps any of the guards icons, if so is the case, the players health is drained. Requirement 6: Game-world interaction The system shall allow the players actions affect the game world. This requirement is actually implemented by the combination of requirement 4 and requirement 5. For the mobile client, the way to affect the game world is to trigger different events by moving into special locations or into the way of an enemy guard. The desktop client do have some other way of interacting with the game-world, which is to, via a map menu (see Figure 4.5), place markers on the map and drop power-ups for the mobile player to pick up. 25

Figure 4.5. Screenshot of the desktop client and its map menu, here adding a waypoint for the field agent. Requirement 7: Consistent game data The system shall ensure that all connected clients are provided consistent game data. This requirement is fairly simple to meet, but yet extremely important to actually implement. The method used is to by using Actionscripts built-in setinterval function ensure that the clients are frequently querying the database for updated game data and also update any changed recorded on the client into the database. Examples of how this is done can be seen in requirement 2 and requirement 4. Requirement 8: Media file management The system shall store and distribute media files to the clients when required. To allow the system to use media files across the different platforms, a media file manager was implemented into the system. This manager is actually distributed across the server and the clients. When loading the Game-XML-document in the beginning of the there is a reference to the media file associated with that task. When called upon, this reference is used to contact the server, which holds the media files, and stream the media to the client. In the prototype, the media files dealt with are audio clues related to the different tasks that can be played when the field-agent unlocks a task. Requirement 9: Shared game world The system shall enable users of the different clients to participate in the same game world. For this requirement there was not really much development needed for the implementation. The two clients share the same map to make them feel part of the same game world and share a similar interface (see figures 4.6 and 4.7). And they are 26

both affected and can interact to some extent with the game world. This feature is really mostly an affect of the game world interaction and the sharing of game data. Figure 4.6. Screenshot of the desktop client s interface. Figure 4.7. Screenshot of the mobile client s interface. Requirement 10: Network communication All clients shall be able to communicate via network communication. Using Actionscripts built-in function loadvars, which allow the clients to send and receive data through network communication. The network protocols used are TCP/IP for the desktop clients and 3G/GPRS for the mobile clients. The data sent is always passed through the PHP-middleware however to insert it into the database. 27

Requirement 11: Storing post-game data The system shall store the game data in such a way so it is possible to provide post-game visualization. To fulfil this requirement, vital game data and events had to be logged into the database. The following data was identified as data that would be stored to allow it to be reused to rebuild the events of the game: Real-world player positioning Task activation Text-messages between the users Real-world player being spotted by guards Answer given for the questions Out of these above events, the text-messages is the only one automatically being stored in a way which allows it to be used after the game. The positioning of the player is updated not inserted into the database, which means that there is only ever one position stored for the player in the player-details table of the database. To deal with this, another entity was created into the database that was called positioninghistory. This entity is updated every five seconds, which allows to rebuild the movement pattern of the player. As for the other events, an entity called game-events was created and every time one of the events occurred, a new row was inserted into that entity, containing information about where it occurred and what type of event it was, for a more detailed explanation of these two entities see figure 4.8. Figure 4.8. Diagram of the added database entities. Requirement 12: Time-awareness The system shall be able to time the amount of time it takes to play the game. This requirement was fulfilled by using the gettimer function in Actionscript, which returns the number of microseconds since midnight January 1,1970 (Adobe, 2010b). By using this function a timer was implemented into the system that keeps track on the duration taken for completing the game. This data is kept on the mobile client and uploaded to the game-server at the end of the game. 4.2. Prototype tests As described in chapter 3, there are two types of tests used to validate the requirements and evaluate the user experience, software testing and user testing. The first part of this sub-chapter will present how the software testing was performed and the second shall describe how the user testing was performed. And to clarify, in the test sections, R1, R2, R3, etc will be used as identifiers for the different requirements. 28