Development of the prototype

This section describes the technical implementation of the software components used to build the complete system for developing the location-based learning activities used in this research.

The PaSAT software comprises a desktop application server that allows the creation and playing of game-based tasks in physical locations, in combination with a software

client that runs on a mobile device (such as a PDA). The mobile device is used by

learners in the field to carry out a learning activity using the game facilitated by the mobile device connected to the game server.

4.4.1 Development Platform

All software development was carried out using the .NET platform and the Microsoft Visual Studio integrated development environment (IDE), using the C# language. The .NET platform is a development framework produced by Microsoft that is intended to allow rapid development of internet-based applications across a range of devices,

Applications developed using Microsoft Visual Studio and .NET can be easily deployed on to Windows PCs and mobile devices that have a suitable version of the .NET Framework installed (this restricts the range of possible mobile devices to those running the Windows Mobile operating system).

4.4.2 Software architecture

It became clear from the outset that rolling the game server functionality into the authoring environment was practical and appropriate for a number of reasons. Firstly, this simplified the development process: since the game server component relied on data provided by the authoring environment it made sense to provide server functionality directly from the authoring environment. Secondly, it made conceptual sense from the userÕs perspective, especially in conjunction with the intention of providing real-time viewing and editing of the game-state at runtime. Separating the two components would have made the system harder to develop and less easy to understand for the user.

The PaSAT software was thus developed as two high-level components:

¥ A server and authoring application running on a desktop PC

¥ A client application running on a mobile device (a Windows Mobile device)

These two components communicate using Web Service calls. A Web Service is a server application that responds to incoming requests via the standard HTTP channel (port 80), using structured messages in XML (eXtensible Markup Language).

A Web Service was used for a number of reasons:

¥ Visual Studio includes native support for building, deploying, and consuming Web Services in .NET applications.

¥ Web Services offer stateless connections, i.e. they are more tolerant of interruptions in network connectivity than stateful connections such as sockets, because they do not require a continuous connection.

¥ Web Services allow the exchange of structured messages using XML documents. These documents can be easily parsed by applications that can reference the appropriate XML schema for the document. XML documents can include optional elements, which means that adding elements to include more data does not cause runtime errors because the original structure of the document is still viable.

However, the use of Web Services brings a number of limitations to the system:

1. Web Services are less efficient than custom, socket-based communications, and place greater demands on the system to interpret them.

2. Web Services only allow information PULL, that is to say they only respond to requests and do not allow for any PUSH to available clients.

These limitations were not significant factors for the development of PaSAT. Limitation (1) is not significant because the XML documents exchanged are simple and small, placing little demand on the software. Limitation (2) can be largely overcome by setting the client to poll the server at frequent intervals, simulating information Push by providing regular and frequent Pull.

In order for the two main components of the PaSAT system to communicate via Web Services, a Web Service application was developed as part of the desktop application. This application runs under Internet Information Services, the standard desktop web server application provided by Windows. The Web Service application listens for requests coming in via Web Service calls, and when an appropriate request is received the request is then forwarded to the desktop application. This forwarding is achieved

through the use of an inter-application communication protocol called .NET remoting. The desktop application opens a communications port for listening to a designated other application, the Web Service server, and requests can be made via this mechanism. When the desktop application receives a request from the Web Service server via the remoting mechanism, it performs the required actions and, when appropriate, makes a response via the same channels.

Figure 6 below shows a diagrammatic representation of the architecture of the system.

Figure 6: architecture of PaSAT system

4.4.3 Client-Server architecture

PaSAT employs what is known as a thin-client deployment strategy. The client software that runs on the PDA contains just enough functionality to allow users to connect to the game, see a map and their position, and to perform actions, and see results and other feedback. In addition, the client is responsible for using the mobile deviceÕs GPS hardware to calculate the physical position of the user. However, all of

the data relating to the gameÕs current state (including the current location of the user) is stored on the game server, and accessed periodically by the client. This means that the current game state and the handling of state change events is performed by the server and these changes are then immediately available to all connected clients.

A fat client strategy would store more (potentially all) of the game state data on the client, and the handling of the game state and state changes would be distributed, leading to potential conflicts and difficulties maintaining synchronisation between devices.

For the kinds of activities that PaSAT is intended to support, there are a number of advantages to the thin client approach. These include, but are not limited to, the following:

1. Crash resilience through session persistence: if a PDA crashes and loses local data the player can restore their session because this information is held on the server and not locally.

2. Speed of response: because the PDA software is lightweight it places a small burden on the limited processing capacity of the device and can respond more quickly to user input. This is especially important for simultaneous handling of continuous network and graphical events of the sort envisaged for the interactive mobile activities that PaSAT is intended to support.

3. Ease of deployment: because the game states and configuration are held on the server, deployment of a new game can be performed quickly via a log-in and synchronisation process rather than having to distribute new data or software files to each device

4. Multi-player interactivity: because the connected devices all connect to the server as a hub, multi-player interactivity can be handled easily on the server

rather than having to resolve conflicts arising from multiple devices trying to connect on an ad-hoc basis in the field