A Pervasive Educational Game on Pervasive Computer Networks Tobias Moebert, Raphael Zender, Ulrike Lucke University of Potsdam, Germany Dpt. of Computer Science
[email protected] Abstract: From experience, difficult subject matters are usually not well understood by students if only presented face-to-face. Practical exercises or project-based team work are valid instruments to tackle this problem. However, students are required to have a strong motivation and self discipline in order to stay involved. Strategies like game-based learning can help to foster intrinsic motivation and thus to improve the learning outcome. This paper presents a game that helps students to understand the structure and dynamics of mobile computer networks. In particular, the game is a pervasive, strategic adventure. It is designed for mobile devices, uses context information for the game play, and tightly interweaves digital and real-life environments. Based on an educational and technical conception, implementation and use of the game are described. Lessons learned from first experiments with the game lead to further directions of research and development.
Introduction Mobile or pervasive games enjoy an increasing popularity both for learning and for entertainment at all. The idea to combine online computer games with real-life settings became popular within the last decade. Players are equipped with mobile devices and move around in a given area. Locations and moves of the players are even relevant if no positioning mechanism is used. Moreover, augmented or mixed reality can be used to tightly interweave the virtual game story with physical artifacts (Magerkurth et al. 2005). Thus, the field of pervasive gaming brings together the perspectives of technology (Benford et al., 2006), game design (Crawford 2003), psychology and culture (Salen & Zimmerman 2004) – and, if used for educational purposes, pedagogies (Thomas 2005). A special challenge for the game designer is that the borders between the game and the physical environment are not as apparent as in traditional play settings (Huizinga 1938), but build the so-called magic circle as a special place in time and space (Montola 2005). That’s why the game design has to ensure that players don’t lose touch with reality, or sustain an accident on the street. From the multitude of pervasive games that have been developed, we’d like to draw special attention to the following: Chawton House (Weal et al. 2007) is an English manor related to the writer Jane Austen. It was equipped with an infrastructure for extending literacy field trips with location-sensitive devices. A learning game was designed that puts children into the place of historic writers, transforming what they see and what they explore to a story that is transferred back to classroom. Detective Alavi (Fotouhi-Ghanzvini et al. 2011) helps computer science students of Persian language to understand English terminology. Their task within the game is to solve a criminal case on the “death” of a processor. In the game story, system components, vendors etc. and their relationships are personalized and mapped to rooms, buildings and persons in real-life. REXplorer (Ballagas et al. 2008) is a game for tourists in the historic German city of Regensburg forcing them to learn about its history and attractions. The story is around supernatural phenomena and a scientist who is asked to analyze them. Players are equipped with a mobile device that allows them to interact with legendary figures. The goal is to find as much magical energy as possible. REWARD (Triebel et al. 2010) has a similar approach of exploring an unknown area. There is no actual game story, but players have to collect photographs of visual tags from hidden places they shall find. A Campus Navigation System developed at Dublin City University (Hatt & Muntean 2007) guides students trough some activities they have to perform during their first days on campus. Students are requested to enter specific buildings associated with these tasks. When the correct position is detected, the game engine lets them perform a virtual task. This comes along with collecting happiness, education, energy, and money; with the final goal of virtual graduation.
CollecTic (Hielscher 2006) is a Playstation game. Users are requested to find public hotspots with WiFi access. Depending on parameters like signal strength, physical address, or security settings, the hotspots are coded with symbols of different shape, colour, and size, and are arranged in a 3x3 grid. Players have to collect rows with all equal symbols. There are a large number of shooters deployed as a pervasive game, like BotFighters or Shoot Me If You Can. Players have to locate their opponents by moving through the real world, and to catch or destroy them by taking photographs or in a virtual fight. There are also augmented reality versions of traditional games like Pacman and Quake. We believe that a pervasive game, which closely interweaves real-life settings and artifacts with a digital game, may activate students to a much larger extent and may create a deeper knowledge compared to the isolated experience of a digital or mobile game, or even to traditional project-based or classroom learning. This paper presents our development of a pervasive game for computer science students that want to learn about characteristics, effects, and problems in communication networks. The concept is based on a survey among students in order to derive requirements regarding technology, organizational issues, and game story. The paper is organized as follows: The next section presents our thoughts on the subject, general requirements, and the resulting game story. Then, the implementation and use of the game are described. The final section draws a conclusion and outlines further work.
Idea and Concept of the Game Pervasive Computer Networks as a Subject of Learning Due to their complex structure and dynamic behavior, computer networks are a comparatively difficult subject in computer science education. This is especially true for wireless transmissions among mobile devices, which face additional problems of instability. So called mobile ad-hoc networks (MANETs) are built from nodes that do have only temporary network connection, limited computing and networking resources, and limited energy. A typical scenario is depicted in Figure 1. A crash and the resulting traffic jam are detected by involved vehicles, and step-by-step sent forward to others in order to circumvent the affected area and to request rescue/ambulance. Other popular application scenarios are, for instance, sensor networks like those used in assisted living or emergency management. Moreover, heterogeneity is another issue in MANETs, but not tackled in this article.
Figure 1: Vehicular communication networks are a popular application scenario of pervasive communication. The problems of data delivery in MANETs arise from the contradiction between autonomous behavior of nodes and global functioning of the network. On the one hand, nodes have to take care of their energy, safe their computing and networking resources, and generally follow individual goals and strategies ─ for short, they act more or less selfish in order to stay alive. Usually, they do not have knowledge about the global state of the system, but only about their individual neighbors. On the other hand, messages have to be sent through the
network, which can only take place with the help of these nodes (or at least some special repeaters). This requires the sender to address the receiver of his message, to find a way through the network, and to dynamically react on changes or problems that might occur. Computer science offers a large set of protocols for such routing tasks, each with individual benefits and drawbacks and thus more or less suited for a particular scenario. From the experience of the authors, students tend towards the global perspective in such a scenario; they often have difficulties to understand the reasons why mobile nodes act somehow uncooperative. They usually prefer to simply define global parameters and rules in a centralized way. That’s why our approach was to let students feel like a mobile node, to take care of their isolated existence while being part of a larger whole, and to contrast this with the global perspective of message transfer in a MANET. We mapped the topology and behavior of MANETs to the scenario of strollers in a park that occasionally meet and exchange packets of data, thus keeping communication operational. Technical Design Requirements Derived from the results of a previous survey among our students (Lucke 2011), we identified a number of design requirements for the planned game: We don’t need a compromise of medium-sized devices; we have to guarantee distinction between large and small screens (notebooks/PCs and smart phone) including different interaction concepts. The overwhelming willingness of students to use own devices comes along with a variety of platforms to support. Thus, there are strong requirements for platform independence of the developed game. In contrast to wireless LAN on campus, access via mobile phone networks is in the students’ private responsibility. So, a mixed strategy is necessary. Students are well familiar with mobile devices and the internet. Thus, the game design does not need to take care of novice computer users. Since many students are experienced game players, we need to have different levels of difficulty in order to attract all students. There is no clear preference for a funny, serious, or sportive game. This is independent from age, gender, and program of study. So we need a balanced mix of these aspects. The game shall be in online team-play modus, and can be mobile across the campuses of the university or even across the whole city. Rally and adventure are the most promising game types, but also hard to implement. Alternatively, cards can be a sufficient approach, if there is a sportive element in order to attract all groups of students. Göth et al. (2006) provide five more requirements derived from their experiments with context-aware games, touching the subject from ergonomics’ point of view: A continuous use of the mobile device narrows the user’s focus to the system and thus may overburden his cognitive capabilities. Focus change can be forced by bringing the system to the front only in reaction to certain events. Animations should be avoided while the system shall not be in the focus of the user. IT shall be used only where it is necessary, since traditional methods and tools are not efficient or effective enough. The functions of the system shall be reduced as much as possible in order to avoid distractions. These requirements directly lead to the concept of our game, presented in the following section. We followed the guidelines stated above with one exception: The continuous use of the mobile device without cognitive overburdening of the user was facilitated by restricting the time of play to a few minutes and keeping the mobile interface simple. Game Story Recent research (Crawford 2003; Salen & Zimmerman 2004; Varney 2006) led to a number of guidelines to be followed when designing an educational game, of which we’d like to emphasize the following: Educational games shall foster learners to question their previous assumptions, and to develop own strategies for solving complex problems. Game play shall be based on existing knowledge about real-life, including (visual) metaphors for the subject of the game. A narrative context keeps together elements and information throughout a game.
Long-, medium-, and short-term goals help to motivate players during game play. Control and freedom of action need to be balanced. While unlimited freedom is often perceived to be boring or unchallenging, strict control degrades the player to a visitor. Some studies point towards female players preferring 2D-interfaces, but regarding the genre of the game there could not be found any gender-based differences. A fundamental point is that games usually do not help to acquire factual knowledge, but rather help to repeat, to build own mnemonics and metaphors, and to find a deeper understanding of previously presented facts and methods. For instance, a student could remember special situations of the game when challenged with a problem during exams or professional work, and thus would be able to recall associated knowledge and skills. In this way, the main learning goal of the game is that students may recognize the manifold characteristics and problems of a MANET, and may develop strategies to face them. In more detail, students may judge the influence that limited resources of a node and dynamic topology of a network have on proper operation; and students may experience the relationship between topology of a network and characteristics of a routing protocol in order to select or even design a suitable solution for a given scenario. To consider the duality of perspectives in a MANET, associated with contradicting goals and behaviour, we decided to split players in two groups: nodes (mobile, outdoor) and messages (stationary, indoor). Previous analysis has shown that a targeted combination of mobile and stationary players may lead to an even more satisfactory game experience (Lindt et al. 2006), since mobility is explicitly perceived and the degree of immersion is higher. The following table describes core aspects of the game for these groups. groups
nodes (mobile players, outdoor area)
messages (stationary players, indoor lab)
goals
keep battery loaded find neighbor nodes forward messages through the network
challenges
collect batteries keep connected
end of the game
send messages through the network select promising start and end nodes higher score for routes with more nodes bonus for reaching certain nodes topology changes while nodes move only one message at a time transmission takes time node with many messages is bottle neck limited number of high-priority messages less than two nodes left time over
moving and instable nodes changing topology bottle necks finding paths through the network delay or loss of messages
learning aspects
battery is empty less than two nodes left time over limited range of sensing limited range of transmissions limited resources changing neighborhood
Table 1: The game concept separates players into nodes (local view) and messages (global perspective). While mobile nodes see only their immediate neighborhood, stationary players have a global perspective on the scenario. The messages role requires players to appropriately select nodes for transferring messages, and to balance low and high priority messages. The nodes role requires players to keep themselves and the network alive, i. e. to move around in order to find/keep connections and to find batteries. Nodes can collect two types of objects: batteries (to remain in the game) and boosters (to temporarily extend their transmission range). Their energy consumption is rising with the number of connected neighbor nodes and the number or forwarded messages. Nodes receive scores for connections to other nodes and for forwarding of messages. Message players receive scores for successfully sending messages.
The game design includes different levels of difficulty. The higher the level, the lower is the assistance by the game engine; so, more aspects of routing have to be realized by the players themselves. There are three levels of difficulty defined: basic level (low demand, strong assistance): This modus is to make the players familiar with the game without making complex decisions. The majority of routing issues are simulated by the game engine. advanced level (medium demand, medium assistance): Here, some further latitudes and challenges come into play. Players have to think about their basic actions, e. g. how to prioritize messages or how to localize neighbor nodes. expert level (strong demand, low assistance): In this modus, the game engine provides only minimal support to the players. They have to solve complex problems when sending/forwarding messages through the network. A key characteristic of the game is that long-term goals stay valid throughout the whole game play, while medium- and short-term goals arise with increasing level of difficulty. While long-term goals provide a familiar and reliable framework for the player, and help him to identify himself with his role, medium- and short-term goals on different levels keep variation and motivation, and cause deeper understanding.
Implementation and Practical Use Development of the game was based on formal modeling of use cases, activities, related system components, and their internal interfaces. Such technical details shall be omitted here. We’d like to focus on a more abstract level presenting the overall architecture of the gaming system, involved tools, implemented user interfaces, and findings from game play. System architecture The game infrastructure was designed as client/server architecture. Clients receive their user interfaces from the server. Additionally, the server keeps the game data and logics, including processing and generation of events (like placing an object on the field, movement of a node, collecting an object, transmitting a message, and so on.) All components are connected via internet. The resulting architecture is depicted in Figure 2. administration
mobile player (nodes)
stationary player (messages)
data base game server Figure 2: The game architecture integrates mobile devices with stationary clients and a central game engine.
The game server includes an Apache HTTP server with PHP and a Doctrine object relational mapper for accessing a MySQL data base. The HTTP server provides the user interfaces to the browsers. PHP is used to dynamically generate adequate web pages, related to the current game status. Doctrine simplifies persistent access to the data base from PHP. Moreover, this abstraction layer allows to easily migrating the infrastructure to other data base systems. The game leader/administrator and the messages players get access to the game from desktop devices with a traditional web browser. The browser must support HTML5, CSS3, and JavaScript. Data transmission between server and clients is realized with AJAX and JSON in order to keep communication asynchronous and compact, and thus to speed-up game play. The nodes players access the game from mobile web browsers on their smartphones. Thus, the system is platform-independent. However, different browsers often do render a web page in a slightly different manner. That’s why the Sencha Touch framework for developing mobile web applications was used. It allows deploying consistent interfaces for Apple iOS 3+, Google Android 2.1+, and BlackBerry 6+. With CSS3 stylesheets any look and feel can be applied to the interface. The size of control elements is automatically adjusted to the current screen size and resolution. Moreover, HTML5 support simplifies audio and video integration. Such development frameworks also provide abstraction mechanisms for available hardware (like sensors) and native features of the respective operating system. From the available sensor data, mainly the GPS coordinates are used for the game. They are combined with data from a geo information system in order to relate the player’s position with his (physical and virtual) environment. Available map types reach from simple road networks to complex satellite images. The Google Maps services were used because of the tight integration with the Android and iOS operating systems as well as the Sencha Touch framework. User Interfaces According to the defined roles of players and the associated types of devices, a set of different user interfaces was designed: for mobile nodes, messages players, and the administrator. Each of these interfaces has a certain purpose and design (Lindt et al. 2006), which shall be explained in the following.
Figure 3: Mobile players (nodes) see a simple gaming interface that provides only limited information to them.
The game starts with a simple login screen as depicted in the left hand part of Figure 3. Since the context is not security-relevant, and no data is stored beyond a single game play, no access codes or passwords are required. A screenshot of the main gaming interface for mobile nodes is given in the right hand part of Figure 3. There are three areas: At the top, symbols provide an overview on current score, number of neighbors, remaining time, and energy resources. The interface is dominated by a map of the gaming area. It shows the positions of one’s own, other nodes, and objects to collect. A blue and a red circle mark the ranges of sensing and transmitting, as well as the range of collecting objects. In the bottom area, there is some textual information on objects within reach, active objects (like booster for transmission range), a button for collecting objects, and relevant hints.
Figure 4: Stationary players have a global view on the network infrastructure and the status of their messages. Interfaces for stationary players are designed for larger screens; they offer more detailed information and have horizontal orientation. Figure 4 shows the gaming interface for the messages players. It is dominated by a large overview map of the gaming area in the left hand part. There are markers for all nodes and their transmission ranges. Currently selected nodes and own messages underway, if any, are highlighted. On the right hand side, there are five blocks (the last one is not displayed in this screenshot). They provide status information on the game (remaining time) and the player himself (name, score) as well as control elements to interact with the game. A player can select start and end nodes, and can send a message. Finally, relevant hints and a legend of used symbols (not displayed) are offered.
Figure 5: The game admin overlooks all nodes, messages, and scores of the players (German interface).
For the game leader or admin, there is an initial interface to adjust parameters (like level of difficulty, gaming area, duration of play, specifics of simulated routing protocol) and to actually start a game. During game play, the interface offers detailed information, as depicted in Figure 5. It provides an overview on the current game (remaining time, current parameters) and the players (name, current position, last position update, score, battery, booster activity). Furthermore, status messages of the used routing protocol, a map with all players and objects, and a suspend button are offered. When a game is suspended, there is a resume button instead. Finally, the session can be closed from this interface. Playing the Game The organization of game play is simple: For each level of difficulty, two turns are carried out. After the first turn, player groups exchange their roles from messages to nodes and vice-versa. The duration of each turn depends on the number of players and the level of difficulty. A test run with 10 computer science students showed out that the developed game is working well. Students were split into two groups. Initially, the basic level was played several times while repeatedly switching groups. Afterwards, a short questionnaire was completed. All players had lots of fun. However, after solving some simple problems with single devices and operating systems, some bugs in game administration and performance problems with interpretation of geo coordinates were encountered. Also, test players provided some hints on how to improve the game. Those led to further implementations and a second test, whose results are currently being analyzed.
Figure 6: Three “nodes” in the game while searching the campus for batteries during the first test. In general, all participating students liked the idea of educational games in general and this game in particular. 80% rated games as a valuable instrument for such subjects, and only 20% were slightly skeptical. Criticism was focused on difficulty: 40% rated the game too difficult and not self-explained; 30% wanted more help, and 20% wanted an easier game play for the basic, introductory level. This might be caused by the isolated game play without an accompanying course (i.e. lessons, exercises, literature). Another indication for this is that 90% of students did not rate the high number of players (und thus, the high dynamics of the game) as annoying, and that 80% wanted to directly handle more aspects of routing in higher levels. 40% of players asked for a narrative context of the game play, which may also make introduction easier. The recent test run and future experience with using the game in classes will surely bring up new findings on how to adjust and extend the game for a valuable educational arrangement.
Future Work Completion, improvement, practical use, and evaluation of the game will be carried out during the next months. In this respect, the following subjects of work are intended: Some aspects of the game are designed but not yet fully implemented. Above all, completion includes higher levels of difficulty and better performance of player tracking. Moreover, a persistent management of users and their score could help to further motivate students by a rewarding or caste scheme. Also, there is the idea to insert a trouble maker that tries to intercept messages in order to address security issues. Finally, the game shall be extended to other routing protocols. Among further improvement of the game, physical artifacts shall be closer integrated in order to achieve a higher degree of immersion (Clarke et al. 2009; Varney 2006). Several experiences with interweaving 3D virtual worlds and classroom settings prove the educational benefit of such solutions (Lucke & Zender 2011). Also, first tests started on including gestures into game-play (Pfeiffer et al. 2011) for a more intuitive interaction and reduction of cognitive load. Another idea is to create special scenarios like a sensor network in a forest fire area in order to provide a narrative context. For all these issues, further conceptual work is necessary. The game will be integrated into the course “Network-based Computing” during the upcoming winter term. A systematic evaluation of benefits, drawbacks, and general conditions of use will take place, and the game-based approach will be contrasted to traditional lectures with exercises. Furthermore, the experience from this development shall be transferred to other pervasive educational games. A second game for helping freshmen with the new situation on campus is currently being developed (Lucke 2011). Also, there are some new ideas for games on the history of computing, and on a subject-independent pervasive crossword puzzle. Those projects shall be started throughout the next months with the help of interested students. Finally, there is some on-going research on cross-platform development kits for mobile devices. They provide an abstraction layer for description of functionality and interfaces, which is automatically mapped to native code for a number of platforms. This is independent from limited browser-based applications and thus offers direct access to system features, provides a higher degree of freedom in design, and leads to a significantly better performance.
References Ballagas R. et al., 2008, Gaming Tourism: Lessons from Evaluating REXplorer, a Pervasive Game for Tourists. Pervasive Computing, LNCS Vol. 5013, Springer, Berlin, Germany, pp. 244-261. Benford S. et al., 2006, The frame of the game: blurring the boundary between fiction and reality in mobile experiences. Proc. SIGCHI Human Factors in Computing Systems (CHI), Montreal, Quebec, pp. 427-436. Clarke, J., Dede, C., & Dieterle, E. (2009). Emerging Technologies for Collaborative, Mediated, Immersive Learning. In Voogt, J., & Knezek, G. (Eds.) International Handbook of Information Technology in Primary and Secondary Education. (pp. 901-910), Berlin : Springer. Crawford C., 2003. On game design. New Riders, Boston/NY, USA. Fotouhi-Ghanzvini, F. et al. (2011). Implementing Mixed Reality Games for Mobile Language Learning. Proc. IADIS Int. Conf. on Mobile Learning. Avila, Spain, paper F054. Göth, C. et al. (2006). The Focus Problem in Mobile Learning. Proc. IEEE Workshop on Wireless, Mobile and Ubiquitous Technologies in Education. Athens, Greece. Hatt, V. & Muntean, G., 2007. A Game-based Campus Navigation System for Mobile Devices. Proc. Digital Convergence in a Knowledge Society, Dublin, Ireland, pp. . Hielscher J., 2006. CollecTic – Discovering The World Around Us. Description of a Masters graduation project (9 pages). online at http://pixelsix.net/collectic/JHielscher_CollecTic_12.pdf
Huizinga J., 1938. Homo Ludens. Proeve eener bepaling van het spel-element der cultuur. H.D. Tjeenk Willink & Zoon, Haarlem, Netherlands. Lindt I. et al., 2006, Combining Multiple Gaming Interfaces in Epidemic Menace. Proc. SIGCHI Human Factors in Computing Systems (CHI). Montreal, Canada, pp. 213-218. Lucke, U. (2011). A Pervasive Game for Freshmen to Explore their Campus: Requirements and Design Issues. Proc. IADIS Int. Conf. on Mobile Learning, Avila, Spain, paper F079. Lucke, U. & Zender, R. (2011): 3D Interactions between Virtual Worlds and Real Life in an E-Learning Community. Advances in Human-Computer Interaction, 2011. New York, NY : Hindawi. Magerkurth C. et al., 2005. Pervasive games: bringing computer entertainment back to the real world. ACM Computers in Entertainment. Vol. 3, No. 3, article 4-A (19 pages). Montola M., 2005, Exploring the Edge of the Magic Circle: Defining Pervasive Games. Proc. Digital Arts and Culture. Copenhagen, Denmark, pp. 1-4. Pfeiffer, L., Zender, R. & Lucke, U. (2011). Gestenerkennung auf mobilen Geräten: Aktueller Stand und Potential für das Lernen. Proc. Workshop Mobile Learning, in conjunction with DeLFI 2011 conference, Dresden, Germany (to appear). Salen K. & Zimmerman E., 2004. Rules of Play. Game Design Fundamentals. MIT Press, Cambridge/MA, USA. Thomas S., 2005, Pervasive, Persuasive eLearning: Modeling the Pervasive Learning Space. Proc. IEEE Pervasive Computing and Communications (PerCom) Workshops. Kauai/HI, USA, pp. 332-336. Triebel T. et al., 2010, REWARD a Real World Achievement and record database. Proc. IEEE Pervasive Computing and Communications (PerCom) Workshops, Mannheim, Germany, pp. 835 – 837. Varney, A. (2006): Immersion Unexplained. The Escapist, 57, pp. 20-23, Stamford, CT : Themis. Weal, M. J. et al., 2007, A Card Based Metaphor for Organising Pervasive Educational Experiences. Proc. IEEE Pervasive Computing and Communications (PerCom) Workshops. White Plains/NY, USA, pp. 165 – 170.
