The Community for Technology Leaders
RSS Icon
Subscribe
Issue No.04 - October-December (2010 vol.3)
pp: 281-293
Published by the IEEE Computer Society
Kristoffer Getchell , Kingston University, UK
Alan Miller , University of St Andrews, St Andrews
J. Ross Nicoll , University of St Andrews, St Andrews
Rebecca J. Sweetman , University of St Andrews, St Andrews
Colin Allison , University of St Andrews, St Andrews
ABSTRACT
The construction and consolidation of knowledge through the practical application of concepts and processes can be difficult to support for subjects where practice is an integral component of competence and expertise in that domain. For example, participation in an archaeological excavation is not readily available to students, although a detailed understanding of what processes this involves is deemed to be core to the subject. The Laconia Acropolis Virtual Archaeology (LAVA) project has created a cooperative exploratory learning environment that addresses the need for students to engage with the complex practice of excavation. By leveraging the progressive nature of games methodologies and the immersive engagement provided by 3D multiuser virtual environments, LAVA facilitates the adoption of exploratory learning for excavation scenarios which have previously been inaccessible due to barriers of travel, time, and cost. A virtual environment based on real world data has been developed where groups of users are faced with a series of dynamic challenges with which they engage until such time that a certain level of competence is shown. Once a series of domain-specific objectives has been met, users are able to progress forward to the next level of the simulation. The excavation simulator enhances the student learning experience by providing opportunities for students to engage with the process in a customizable, virtual environment. Not only does this provide students with an opportunity to put the theories they are familiar with into practice, but it also allows students to gain experience in applying their skills in a bid to manage an excavation process, thereby making it possible for a greater emphasis to be placed on the practical application of knowledge that the excavation process necessitates. The potential of this approach has been confirmed by a positive user evaluation. LAVA contributes toward the progress of technology-enhanced learning by illustrating the instantiation of a framework which demonstrates how to integrate games methods with learning management systems and virtual worlds in order to support higher order learning behaviors such as applying, analyzing, evaluating, and creating.
Introduction
The application of concepts is an important part of the learning process. By interacting with systems that support this, learners are able to engage in higher order learning behaviors, as originally defined by Bloom [ 1], revised by Anderson [ 2], and summarily represented in Fig. 1 and Table 1. Progression up the hierarchy requires learners to adapt their engagement with the learning process and materials presented. While it is possible at the lowest level (remembering) for learners to simply repeat assimilated information, this becomes less convincing the further up they go. In order to demonstrate understanding, application, analysis, evaluation, and creation, they need to be able to show increasing levels of mastery of the subject matter so that they not only remember the knowledge being acquired, but also consider and reflect on it in a wider context which sees new and preexisting knowledge assimilated to form a coherent model of the wider world. It is therefore desirable to have learning facilities which enable students to move up the hierarchy of learning behaviors.


Fig. 1. Anderson's revision of Bloom's levels of cognitive learning behavior.




Table 1. Anderson's Revised Taxonomy


When considering traditional approaches to education, support for real-world interactions are generally limited, with most systems favoring a didactic approach centered round the transfer of information from the teacher to the student. Technological advancement, epitomized by Moore's Law [ 3], offers an opportunity for these approaches to be enhanced by computer game and multiuser virtual environment (MUVE) technologies that are now widely accessible.
1.1 Games Methodologies
The retasking of the computer game as a tool for teaching and training is not a new concept. Flight simulators, for example, have a long history of use as a means by which pilots can refresh their training and practice the skills required to deal with emergency situations [ 4]. Increasingly, games are also being deployed by the armed forces as a recruitment and training tool, e.g., America's Army [ 5]. Within LAVA, three common themes from computer games are adopted:

    The concept of progression is used to maintain player engagement and is based on the fulfillment of specific subgoals and challenges. This approach is regarded as an effective way to challenge and stimulate a player [ 6], [ 7] with the smaller objectives acting as training exercises which allow players to develop the skills required to meet the increasingly complex challenges that they encounter during the game.

    An element of random behavior within a game's logic is frequently used to influence the outcome of a given situation based on the actions taken by a player. Taking Sudoku as an example, by randomizing the initial seed numbers, each Sudoku game is different, thereby offering a challenge to players.

    A policy of selective revelation allows game designers to control the rate at which in-game information is released to players.

1.2 Multiuser Virtual Environments
As an emerging class of technologies, MUVEs are relatively new, with some of the more mature examples such as There [ 8] and Second Life [ 9] only being released in 2003. By providing a simulated environment within which multiple users can interact through the use of avatars, MUVEs are often used for social purposes. Within an MUVE, each user has their own perspective on the virtual world, with the underlying environment presenting a consistent state to all users. Unlike games, the virtual environment of an MUVE is not fixed and can be modeled and altered by some or all of the users who inhabit it. In addition, each user's avatar can be customized. As the environment is persistent, any changes to it, or a user's avatar, remain over time and are not reset each time a user logs in. In many ways, the environment is similar to that of the real world, with the laws of physics emulated to support real-world behavior such as not being able to walk through walls or falling down due to gravity. There are, however, some notable exceptions which are designed to make movement within the MUVE easier: flying and teleportation for example.
1.3 Web Technologies
Web component technologies utilized in LAVA include: Java and JavaScript programming languages, Flash and QuickTime multimedia players, XHTML webpage language, and the Apache Tomcat web server which supports Java servlets. At a higher level, the web-based MMS institutional learning management system [ 10], [ 11], [ 12] has been adapted by LAVA to act as the integrator for web components, games logic, and the MUVE.
1.4 Case Study
By combining games methodologies, MUVEs and existing web-based learning technologies, the learner can be placed at the center of an immersive, interactive, and collaborative environment which provides learning scenarios that encourage exploration, the application and evaluation of knowledge, and reflection on performance. Hence, progressing to the higher levels of the learning behaviors hierarchy can be supported. While, in principle, many disciplines could benefit from this approach, we have focused on archaeology as it poses a significant challenge to educators in terms of experiential learning and acquisition of advanced skills. The case study reported in this paper investigates the feasibility and the validity of this approach.
The remainder of the paper is organized as follows: Section 2 outlines the challenges of teaching archaeology; Section 3 describes the LAVA system from a user perspective; Section 4 describes the system from a technical perspective; Section 5 summarizes the user and MUVE evaluation undertaken; and Section 6 concludes.
2. Challenges Associated with Teaching Archaeology
The resurgent popularity of books [ 13], films [ 14], and television programs [ 15] dedicated to archaeological discovery demonstrates that people are genuinely intrigued by the past, how our ancestors lived, and the process of detective work that goes into uncovering the hidden secrets locked away in archaeological sites. However, the efforts that are required to organize, undertake, and analyze the results of an archaeological excavation are significant. This broad scope of coverage is a significant challenge to those tasked with designing courses to teach students archaeology. Educators often adopt a theory-based approach which focuses on developing transferrable skills and imparting an understanding of the scientific rationale and processes entrenched within archaeology. Thus, newly graduating students often have a skill set which fails to meet the expectations and needs of practitioners [ 16]. In this way, a theory-based approach can be seen as exasperating the culture clash between industry and academia [ 17]. Organizational issues which act as barriers to experiential learning include:

    The locations of excavation sites and students are not generally well matched, thus courses wishing to focus on cultures and civilizations outwith the locale of the place of study are likely to require the students to travel some distance, adding considerably to the cost of participation in terms of time.

    Students wishing to work on an archaeological excavation are likely to find the financial costs to be high. In many cases, they will be required to pay for their food, lodgings, and equipment. This can be pro-hibitively expensive unless supplementary funding from external bodies and research agencies is found.

    The destructive nature of the excavation process limits the number of students that an excavation site can support. This makes it impossible for multiple students to carry out the same activity several times and as such it is difficult to scale student participation in excavation projects to accommodate normal class sizes.

    As mistakes are likely to be irrecoverable, students are generally only permitted to participate at a low level in the project team hierarchy.

LAVA is based on the archaeological excavation of a Byzantine basilica [ 18] in the Sparta region of Greece [ 19], [ 20] most recently excavated by the British School of Athens during 2000-2001. The excavation is a typical one in that it presents the barriers listed above to student involvement. The LAVA learning environment addresses these issues by providing opportunities for students to

    1. engage with excavation scenarios based on real-world data, from any networked computer,

    2. gain an understanding of the ways in which excavation work is planned and undertaken,

    3. go through the planning and execution of an excavation repeatedly if needed, and

    4. assume managerial roles in the excavation process.

LAVA forces students to consider concerns typically associated with real-world excavation work. These revolve around the attribution of the basilica and the ability to identify cultural artifacts and effects within the basilica grounds.
3. Lava from a Learner's Perspective
In LAVA, learners are organized into teams and resources are allocated on a per group basis. Students within a team operate using a single excavation budget, produce shared documents, and communicate through chat and other shared resources provided through the MMS institutional learning management system. Fig. 2 shows how a virtual excavation is structured into five progressive stages, with all teams starting by producing a project proposal in stage 1.


Fig. 2. Top-level game logic showing five major stages.




A team cannot proceed to successive stages until it has satisfactorily completed the tasks associated with the current stage—a common element of games methodology, with progression depending on competence. LAVA also fosters engagement by providing challenges to learners thereby linking gaming methods with the hierarchy of learning behaviors. Access to the virtual excavation is provided through MMS, so students use their institutional identity. (MMS authenticates users by reference to the institutional LDAP system.) MMS also provides a framework which facilitates the support of self-paced learning and group work. As the system knows the identity of students when logging in, they can be directed to their own personalized page sets, through which they are able to access the resources associated with their course enrolments. Using MMS makes it possible for progress and feedback to be maintained centrally for each individual student, with both students and relevant staff able to access these data as required through their own personalized portals.
3.1 Stage 1: Write Proposal
The team carries out an initial high-level investigation in order to identify and record areas of significance on the acropolis. Their proposal is then submitted as coursework using standard submission tools provided by MMS. The proposal forms the basis of an assessment which is undertaken by the member of faculty in charge of the student cohort. Feedback and authorization to continue are given to the group once their report shows a suitably strong research plan, at which point the team are able to progress to the next stage.
3.2 Stage 2: Site Visit and Funding Application
The team undertakes a preliminary archaeological survey of the ancient acropolis of Sparta to identify and record the range of sites of significance. Students are expected to use a variety of sources both within and outwith LAVA to determine the location of the basilica.
The key resource is a 3D reconstruction of the acropolis and surrounding area as it is today, recreated in the Second Life MUVE. Fig. 3 shows a part of this reconstruction. The first person perspective offered by the MUVE helps students develop spatial awareness of the acropolis. Once the location of the basilica has been deduced, the team collaboratively draft a proposal that seeks an agreement from a (virtual) research council to fund an excavation of the site. This is delivered to faculty staff via MMS. Feedback, authorization, and a confirmed budget are awarded based on the strength of the submitted plan. Teams can then refine their excavation plans and obtain the equipment and experts required for the project.


Fig. 3. A reconstruction of the acropolis theater ruins in Second Life.




3.3 Stage 3: Allocation of Budget and Excavation
At the start of stage 3, each group decides how to allocate their budget in terms of equipment to buy or rent and what personnel to hire. As the excavation progresses, the teams have additional chances to hire new personnel and acquire more equipment. These opportunities can be used to obtain equipment and personnel for short periods of time; for example, if a new specialist is required for a specific part of the excavation process. Figs. 4a and 4b show that, what each group is presented with when selecting personnel and equipment.


Fig. 4. (a) Personnel selection. (b) Equipment selection.




The equipment lists include items that are directly required for the excavation such as spades, brushes, and cameras. In addition, items that are of no real value to the excavation are also included, as well as items that are indirectly required such as cooking pans and tents.
Teams need to carefully consider what is required and select appropriately from the inventory. If a team neglects to make arrangements for food and shelter, the effectiveness of their workforce will be inhibited. In terms of personnel, teams need to select appropriately from lists including trained management, specialist, digging, student, and support staff. There are over 20 categories of specialist to choose from, including anthropologists, cartographers, dendrochronologists, and osteoarchaeologists.
Support staff include drivers, cooks, lawyers, and IT personnel. A form-based interface is provided (as shown in Fig. 4a), which contains the names of the staff that are available for hire, their cost, a description of their specialism, lists of equipment that they are skilled in using, and notes about their experience and competency. When specialist staff are hired an option to obtain related specialist equipment is provided. More general equipment, such as spades, tents, pens, and paper, are obtained separately, again using a form-based interface, as shown in Fig. 4b. Deciding how the budget is spent and how resources are deployed at each stage has a direct impact on the speed of progress, and critically on the quantity and quality of finds that are made. In addition to the interface used by student teams, a management interface is also provided which allows domain experts, i.e., the teaching staff, to configure the staff and equipment that are available to each team as well as the budget and time allocated for them to complete their excavation work.
With the hired staff and equipment in place, groups are able to begin the excavation process. The excavation is divided up into a number of global levels. A level is defined as an activity that is central to the excavation process, which must be completed by the team before progression to the next level is possible. In LAVA, there are six levels that each team must complete in order to finish their excavation work:

    1. Clear overgrowth and remove top soil. Before excavating per se it is necessary to remove any plant overgrowth and top soil which may have encroached onto the site. Also, carefully remove any other debris in order to uncover the remains of the structure of the basilica. See Fig. 5.

    2. Identify the layout of the Basilica walls. Teams need to identify the architectural layout of the basilica, outlining the various rooms housed within its structure. This is needed to uncover the full extent of the buildings on the site. Accurate records of the locations of any finds must be maintained.

    3. Expose features in the floor, locate seventh and ninth century artifacts and identify fallen masonry. Teams must carefully excavate areas of the site in order to uncover artifacts and fragments of architectural details which have been hidden over time. During this process, teams will find material culture from both the seventh and ninth centuries. They will need to carefully consider the context within which items are found if they are to understand how the basilica fell into disrepair.

    4. Expose the West building features inside the Basilica and sixth century artifacts. As the team's work inside the basilica progresses, additional structures around the main building will be uncovered. As new structures are discovered, teams must undertake investigative work in these regions. Within the main basilica building, artifacts from earlier periods maybe uncovered as the excavation trenches deepen. Teams need to carefully manage and organize their work in this part of the excavation, recording the processes they follow accurately if they want to maximize the value of their end of excavation reports and presentations.

    5. Expose mosaics from walls and floors, clean exposed walls. Once teams have excavated down to the floor level of the buildings uncovered, they need to begin a cleaning process in order to reveal hidden architectural details within the walls and floor of the site structures. Some of the details they uncover will have been designed into the architecture; others will have been caused by damage as the basilica fell into disrepair. Teams need to be cognizant of this fact and record the features accordingly.

    6. Locate and expose graves. As a religious building, there are likely to be a number of graves located on the basilica site. While completing their investigation of the basilica and surrounding buildings, teams may discover burial sites containing skeletons and artifacts of archaeological interest that provide an insight into Byzantine culture. As their excavation work progresses, teams will build up a more comprehensive understanding of the basilica site as reflected in the developing plans shown to them in the excavation management interface. Fig. 6a shows the detail that emerges by last level of the excavation process.


3.3.1 Artifact Discovery Throughout the excavation process, teams will uncover a rich variety of material culture which they must examine. Marked on the level maps using clickable red hotspots, some of the finds will be of significance and some not. By clicking on the hotspots, teams can obtain specific data for each item discovered. Depending on the resources allocated to each activity, teams will be given one of three levels of information, with full information about an artifact only being revealed if the team has allocated the correct archaeological expert to the activity: 1) no information, just a photograph of the artifact, 2) basic information accompanied by a photograph of the artifact, and 3) full information accompanied by a photograph of the artifact.


Fig. 5. Level-1 2D interface.






Fig. 6. Artifact and context discovery, management, and bookmarking. (a) Highlighting showing the locations of discovered artifacts. (b) Details of an uncovered context within the site. (c) Bookmarking the details of a discovered artifact. (d) Allocating resources to the investigation of a context.




As with finds, each context uncovered is also marked on the level map, with blue hotspots differentiating them from artifacts. Clicking on a context hotspot will take the team to a new page which contains a short textual description and a graphical illustration of the context as shown in Fig. 6. A decision then needs to be made as to whether to excavate the context or not. If the decision is made to excavate the context, staff and time will need to be allocated to that task. This can be done using the personnel screen as shown in Fig. 6d, with an option available to determine which areas of the site a person should be deployed to (as shown by the highlighting in the figure). If finds are discovered within the context, they will be displayed as a red hotspot on the graphical representation of the context. They may then be processed in the same way as finds located within the main excavation.

As the excavation work progresses, teams need to maintain accurate context sheets and site logs, just as they would do on a real excavation project. Should teams neglect to do this they will find that, when they come to analyze and prepare their finds for presentation in a virtual exhibition, they have lost all the contextual information associated with each of their discoveries. This will make it difficult for them to include detailed excavation data in their excavation reports and presentations, thus forcing them to rely on external sources of information in order to determine the significance of their findings, just as they would do in a real excavation scenario. While this process can prove to be reasonably successful, it is likely to take longer, require more effort and be less accurate than maintaining the original contextual information gained during the excavation.

As with real excavation work, once a team has completed an activity, it is not possible for them to go back and do it again in a different way (within the same simulated excavation). This emphasizes the need for teams to carefully consider the activities they undertake and the resources that they allocate during the excavation process. Through experimentation, teams will be able to identify the relationship between the amount, and type, of resources allocated to a task and the number of finds uncovered. In simple terms, applying more resources that address the requirements of the activity in hand will lead to more discoveries. However, resources are expensive and teams need to carefully consider their budget and allocate resources in an efficient way if they wish to complete their excavation work.

To add realism to the relationship between resources and the number of finds discovered, there is an element of nondeterminism which makes it impossible for students to preempt the outcome of the excavation process by ensuring that the finds returned to each team are different, even if the same resources are allocated to each stage of the excavation process. This is a common gaming method, with chance being used to ensure that outcomes cannot be predetermined by students.

To enable management of existing scenarios and developments of new ones, a comprehensive management interface is provided which enables noncomputing specialists to manage every aspect of a simulated excavation.

By considering the materials discovered in relation to the working practices adopted, teams are able to collaboratively review their onsite effectiveness, making changes to their approach as the excavation develops. This allows each member of the team to build a mediated understanding of the relative success of the decisions that they make.

3.4 Stage 4: Exhibition and Reconstruction
In this stage, teams synchronously explore a full size 3D reconstruction of the basilica in the Second Life MUVE. As shown in Fig. 7a, they are able to view the external walls and architecture to compare the structure of the original buildings with the impressions that they gained through the excavation process. This enables them to critically evaluate the opinions that they have formed based upon the archaeology that they have uncovered.


Fig. 7. (a) The reconstructed basilica viewed from outside. (b) The inside of the basilica. (c) The visitor center. (d) Inside the visitor center.




In addition, they are able to utilize the first person perspective offered by Second Life to move around the internal spaces offered by the basilica as shown in Fig. 7b. This helps in establishing a sense of space and scale, bringing to the fore the grandeur of the church which is hard to envisage from the remnants of the walls which remain today. Teams are also able to observe the furnishings and decorations which adorn the reconstruction and help bring alive the link between the archaeological process and the cultural achievements of sixth century Byzantines.
In terms of completing the excavation process, teams produce a presentation of their findings and an associated excavation report. Within the MUVE, students are given access to a space in the Basilica visitor center shown in Fig. 7c which they can use to curate a museum exhibition which their peers and course tutor can visit ( Fig. 7d).
Additionally, resources are provided within the MUVE to allow the teams to deliver a presentation based on their excavation work.
Finally, after completing the presentation of their excavation findings, teams are able to review the reconstruction of the basilica in Second Life with their course tutor. This allows them to critique the reconstruction of the basilica based on the findings of their own excavation work, and reflect on the approaches they adopted and the conclusions they formed in light of new data obtained by exploring the basilica.
3.5 Stage 5: Assessment and Feedback
Stage 5 completes the excavation, with students submitting their reports and analyzing their personal and team performance. This stage is a reflective exercise, designed to encourage learners to evaluate their own performance. As such it is designed to encourage a number of the higher order learning behaviors. It is also an opportunity for any important observations to be made by staff, and fosters engagement by providing challenges to learners offers the opportunity for misunderstandings and incorrect interpretations to be addressed.
4. Lava System Structure
LAVA exploits three main technologies: an institutional learning management system (MMS), an immersive 3D virtual world (Second Life), and web-based interactive multimedia. Gaming methods are represented by the design of the logical processes which are implemented using communication and control interchanges between MMS, Second Life, and various interactive webpages (see Fig. 8), with persistence provided by relational databases. MMS has an underlying model of users, groups, and resources, whereby any user can be mapped to any resource via membership of a group, which is allocated to that resource. Hence, in LAVA, a resource instance of type “Virtual Excavation” is created and allocated to each team in a class. The MMS model is supported by the database structure shown in Fig 9. Each attempt to access a resource instance by an individual user is referred to the domain level which checks access privileges based on group memberships. MMS itself is implemented in Java and runs inside a Tomcat container on a server.


Fig. 8. LAVA system structure overview.






Fig. 9. MMS user, groups, resources, and protection domains.




Communication between MMS and Second Life is necessary to maintain consistency of state and user identity across the two systems. Second Life only has restricted facilities for communication with the “outside world,” supported by its native programming language, Linden Scripting Language (LSL) [ 21]. The HTTP requests supported by LSL limit transfers to relatively small (1,500 byte) amounts of data. This means that filter scripts are needed to transfer data which are larger than 1,500 bytes.
In terms of exporting data from Second Life, this process is reasonably straightforward, with scripts composing multiple requests which encapsulate the data to be transmitted. Each request is sent to the receiving service sequentially as an HTTP POST request, with the receiving service providing confirmation of receipt. When importing data, which could be any length in size, the LAVA LSL script and the sending service cooperate, with the sending service accepting as an argument an offset which allows Second Life to request data from a specific point in the stream. As shown in Fig. 10, a stream is broken down into a series of chunks, with a predefined terminator. If, after receiving a response, the script fails to detect the terminator, a second request is made with an offset argument being passed to the sending service. The response will then include data from this offset until the end of the stream.


Fig. 10. LAVA/Second Life protocol unit.




If no terminator is detected, the script will make a further request. This process continues until a terminator is detected by the Second Life client.
The architecture, in Fig. 8, uses the model view controller paradigm. This maintains, for each instantiation of an excavation, a single set of consistent excavation states (the model), with multiple aspects offering different views of it using 2D and 3D interfaces. In this arrangement, learners can interact (control) with 2D maps of the excavation site, apply resources, and undertake management functions, with the results of these activities made available to Second Life for the creation of the virtual exhibition.
Fig. 8 also provides an overview of LAVA's integration with existing institutional infrastructure, utilizing resources and services provided by MMS, and Linden Lab's Second Life grid. This enables services from multiple internal and external organizations to be integrated into a single logical workflow. For example, authentication through MMS allows individual students to be authenticated so that excavations can be tailored specifically for each team, while interfacing directly with Second Life makes it possible for students to collaboratively explore the excavation site in a 3D graphical environment.
4.1 Excavation Logic
The excavation logic is responsible for monitoring student progress, providing access to consecutive levels, and bringing together the elements of chance and context which allow the decision-making process to reflect the actions of the teams coupled with the randomness that would be present in a real excavation. These functions support the utilization of gaming methodologies in a way which provides realism, nondeterminism, and engagement.
The excavation logic is also responsible for maintaining access to simulation state data and ensuring consistency of presentation across multiple client interfaces. Fig. 11 shows the excavation model maintained by LAVA. As an excavation progresses, the state of the model maintained by the excavation logic changes. These changes are replicated to all client interfaces, with updates made to MMS whenever a team member completes an activity which leads to the progression to a new stage within the excavation.


Fig. 11. Excavation model maintained by excavation logic.




4.2 Simulation Logic
The simulation logic ensures the progress of an excavation reflects the suitability of resources allotted to it, the decisions made by the team, and also introduces a level of randomness to ensure that no two excavations are identical. Randomization is used to reduce the predictability of each stage of an excavation, therefore encouraging engagement by reducing a learner's ability to preempt the exact outcome of their decisions. In the current implementation, the simulation logic (see Fig. 12) iterates through each excavation day that the students have allocated to a particular task and performs the following calculation:

    1. For each allocated person, select a piece of equipment with the highest skill level, matching their skill that is not already in use.

    2. Iterate through the hours of each day.

    3. During each hour, test up to four artifacts from the level that have not yet been found or identified, and whose find or information skill matches the person's skill.

The probability of someone finding or identifying an artifact is calculated by comparing the skill levels of the person and any equipment they are using, with the difficulty level of the artifact. Each person and piece of equipment calculates their find probability using the following expressions:


$$\eqalign{{\tt Pp} &= 0 .4 + (({\tt Sp - A})^\ast 0.1),\cr\noalign{\vskip-3pt} &\qquad {\tt or}\cr\noalign{\vskip-3pt}{\tt Pe} &= 0 .4 + (({\tt Se - A})^\ast 0.1),}$$

where ${\rm Pp}$ is the probability of discovery by the person, Pe is the probability of discovery by the equipment, ${\rm Sp}$ is the person's skill level, Se is the equipment's skill level, and A is the artifact find difficulty.


Fig. 12. Flowchart of LAVA artifact discovery process.




In the case of a person having a piece of equipment, the two probabilities are combined using


$${\tt Pr} = 1 - ((1 - {\tt Pp})^\ast (1 - {\tt Pe})).$$

This probability (Pr) is then compared to a random number in the range 0 to 1. The artifact is found and identified if the probability is greater than this random number. The logic has been developed to afford a significant advantage to teams that provide an adequate equipment inventory to each task. The constants in the probability expressions were arrived at through user testing with domain experts, in order to satisfy both the realism of an excavation and the pragmatics of coursework.
5. Evaluation
Evaluation of LAVA has focused on three aspects of the system: usability, educational value, and system performance. Of the three aspects, the assessment of educational value is applicable to any implementation of LAVA, with the evaluation of system usability and system performance being specific to the particular implementation of the system.
5.1 MUVE System Performance
A detailed analysis of MUVE system performance including network protocols is the subject of a separate paper [ 22]. We provide a summary here to give context for the user evaluation. When compared to traditional Internet applications MUVEs have stringent responsiveness constraints: when a user issues a command to their avatar they expect a quick response. Additionally, they are resource-hungry. The server simulates nearly all activity, which means that network load is many times that of similar applications such as online computer games, where the ready-made virtual world can be stored locally.
Two elements of system performance were evaluated: 1) to what extent Second Life could support simultaneous use of in-world activity by a computer laboratory of 30 learners, and 2) what impact does such use have upon the network infrastructure. These questions were investigated during an introductory workshop about Second Life for faculty staff. Each participant followed a worksheet, which included visiting and exploring the LAVA basilica. The network systems were instrumented to capture all traffic for postanalysis. In addition, passive observation of workshop participants was undertaken.
The response times experienced by participants did not make their avatars unresponsive, which suggests that a Second Life island is capable of supporting a moderately sized cohort of active learners. The network resource required to support a user varied between 50 and 800 Kbits per second. During peak usage, the total bandwidth for the session rose to several megabits per second. This was well within the local network capacity and the capacity of the path between the lab and Second Life servers. Under the observed network conditions of loss rates smaller than 1 percent, and a round trip time of 150 ms, the network bandwidth required by a Second Life client was found to be less than the steady state of a TCP connection. Thus, computer laboratories connected to the Internet at several megabits per second can be expected to provide good support for a moderately sized class of approximately 30 users concurrently accessing the same region in a virtual world.
5.2 User Evaluation
The user evaluation process was carried out over three academic years. The participants were undergraduate students at the University of St Andrews, educated to at least GCE A-Level or Scottish Highers level. All were in either their second or third year of a four-year undergraduate programme of study and had volunteered to take part. Most were enrolled in a programme which paired archaeology with either ancient or medieval history. The majority had not previously been exposed to either MMS or LAVA; for those students participating in the group evaluations conducted in years two and three, none had participated in any previous trials.
User evaluation methods included questionnaires, structured interviews, individual and group observations, coparticipation, and written records. The evaluation was intended to produce results which would guide the system development with respect to usability, educational value, and student engagement. The methods were not intended to produce statistically significant results in the sense that, for example, a clinical trial would.
This section reports on results from the pre- and postsession questionnaires in years one and two and on the task-specific questionnaires used in year three. At the start of each evaluation session, prior to any activities being undertaken, all participants were asked to complete a questionnaire which included questions relating to education, background experiences, and IT competency. The age distribution of participants in the three evaluation sessions undertaken fell firmly within the 19-21 age range. Nearly 70 percent of the participants, in either their third or fourth year of a four-year course of undergraduate study, evaluated themselves to have an intermediate level of IT competency with 23 percent assessing their skills to be at a novice level and just under 8 percent assessing their skills to be advanced. While interacting with LAVA, participants were organized to work in pairs. In each session, there were several groups working simultaneously, with each accessing an isolated instance of the excavation simulation. The postsession questionnaire consisted of 29 questions: 10 on usability using the System Usability Scale (SUS) [ 23], 15 on perceived educational value using a customized set of questions, and four open questions designed to allow participants the opportunity to provide feedback on aspects of the system not covered elsewhere. Context was added to these data through the use of interviews and individual and group observations.
Figs. 13a and 13b show comparisons of the SUS scores and perceived educational value results returned during each evaluation of LAVA, as recorded over two successive group evaluation sessions. Given how the system development saw the addition of a number of more complex features it is encouraging to note that the average SUS score was not adversely affected between years, thereby indicating that the base level of usability provided by the system remained high. The similarity in spread of usability scores between the first and second year of evaluation is also encouraging. With respect to the educational value results, both the 2006/7 and 2007/8 data sets show promise with a similar spread and slightly more compact distribution being returned in the 2007/8 result set. While the difference in distribution is minor in nature, it is nevertheless encouraging to see the lower end educational value scores being upgraded to indicate higher levels of perceived educational value.


Fig. 13. (a) SUS scores over two years. (b) Perceived educational value over two years.




During these evaluation sessions, a number of issues were detected with respect to the functionality offered by LAVA, which fed back into the system development work. Many of the problems recorded during the first year which related to the equipment and personnel management systems were resolved through redesign, with individual focus groups providing data that were used to guide the development of both subsystems between each group evaluation session.
In order to focus on development issues, the evaluation session undertaken in Year 3 (2008/9), differed from those which preceded it. Instead of evaluating with a large group of participants simultaneously, a small number of participants, some of whom had previously used LAVA, were invited to attend individual evaluation sessions. Individual sessions were scheduled to last between 30 and 45 minutes, with each focusing on a specific aspect of LAVA. In total, eight individual evaluation sessions were undertaken with the focus of each shown in Table 2.

Table 2. Individual Evaluation Session Focus Topics


Each of the individual sessions was designed to identify strengths and weaknesses in the current implementation of LAVA by examining different aspects of the system. Two types of objectives were used: fixed objectives which have a firm set of steps needed to be completed in order for the objective to be met; and loose objectives which are less prescriptive in their approach, with participants' responses to the environment being of interest. Sessions 1-6 were designed using a fixed objective to be achieved by the participant. Sessions 7 and 8 followed a less rigid structure and employed a loose objective with participants being asked to explore and guide others through the virtual environment, respectively.
This mixture of fixed and loose objectives was applied in order to more closely mirror the type of interactions students experience when using LAVA for academic purposes, with the 2D environment being used to drive forward the excavation through a fairly well-defined structure of interactions while the 3D environment allows for more reflective and explorative activities. In addition to providing feedback through interviews and observation by evaluators, participants in the sessions which had fixed objectives were also asked to complete a short posttask questionnaire.
The responses are summarized in Fig. 14. Participants generally performed very well, with all but one evaluation session seeing the participant successfully complete the objectives set, as shown in Fig. 14a. The majority of participants responded positively when asked about the ease with which they were able to complete their objective, as shown in Fig. 14b, and most said they were happy with the way the system provided them with information as they progressed, as shown in Fig. 14c. Several participants commented that they felt that the system had, in some way, hindered their progress, as shown in Fig. 14d, as they worked to meet their objective. These were caused by with users receiving unexpected feedback.


Fig. 14. Usability evaluation summary. (a) Task completion rate. (b) Ease of completion. (c) Rating of progress reporting. (d) Rating of progress management.




Were the students engaged? We illustrate with a quote from an observer during an evaluation session:
“At the start of the evaluation session, once the users were logged in to the system the noise level in the room got louder and louder as the groups began to communicate with each other across the lab. The AN3020 lecturer kept trying to bring the noise level down, however these efforts were in vein. The noise level maintained a consistent plateau as the groups continued to communicate verbally. When the first group to complete stage 1 was shown the artifacts that they had discovered the room went silent, all of the groups focused on what the group to complete stage 1 had done, and then a wave of excitement and activity rolled over the lab as the other groups, spurred on by the outcome, began to try to complete the stage with renewed interest.”
The findings of the evaluation process have been positive. Domain experts agree that the LAVA has been well received by students, with many showing high levels of engagement with the scenarios presented. While it is too early to report on the postgraduation progress of the archaeological student cohorts, the archaeological educators involved with LAVA are confirmed in their view that the framework that supports LAVA should be embedded in the curriculum, with alternative excavations being created.
6. Conclusion
The main contribution of this work is a reference framework which integrates games methodologies with a multiuser immersive 3D world (Second Life) and web-based interactive multimedia. The framework is designed to allow learners to progress to higher order learning behaviors as identified by Anderson's revision of Blooms hierarchy and similar pedagogical frameworks.
In order to evaluate the effectiveness of the framework, an instance of its architecture was developed to support virtual fieldwork. The MMS learning management system was adapted to achieve the integration of 2D and 3D environments, games logic, institutional data sources, and in-system management interfaces. The LAVA case study was aimed specifically at redressing serious limitations in archaeological education: the barriers of cost, time, and experience level in obtaining essential fieldwork experience.
LAVA was deployed in a classroom environment and evaluated by three cohorts of undergraduate students and several domain experts over three academic years. This deployment highlighted the operational aspects of the architecture and enabled the collection of evaluation data based on real-world usage. Interviews and discussion with domain experts Sweetman and Woolf, as well as current and past students, were undertaken in an effort to identify aspects of the teaching of archaeology that could be improved by altering teaching strategies and approaches.
In order to develop realistic excavation scenarios, a functional and temporal decomposition of virtual fieldwork activities was undertaken. The resultant model allowed students to focus on the management and exploratory aspects of their fieldwork, with these activities supported through 2D and 3D interfaces which integrated visualization technologies appropriate to the activity being undertaken. In an effort to engage with learners and develop realistic learning scenarios, simulations were designed to make use of customizable game logic that was able to realistically correlate users' actions to the successful accomplishment of objectives.
While the architecture has been discussed within the context of the LAVA case study, we believe it could be applied in alternative settings. Specifically, it can be used to support any archaeological excavation scenario. In addition, the combination of maintaining state for individual users, support for group work, support for anytime-anywhere access through web and MUVE interfaces and the modularization of system logic could be applied to educational activities which involve the exploration of remote or inaccessible environments. Examples include the creation of historical scenarios, geological fieldwork, architectural projects, and space travel.
Finally, we wish to emphasize that the framework is conceptual and not tied to specific technologies. In particular, there has been growing concern in academia about the suitability of Second Life's business and service model for educational use. In moving from the scenario where there are a small number of classes using virtual worlds occasionally to one where it is a commonly deployed learning resource, issues of scale arise. First, the cost of maintaining a presence on Second Life could become prohibitive, with extra land needing to be leased from Linden Labs for each course. Second, development of educational resources would need to become more efficient, and Second Life's restrictions on saving and loading resources circumvented. Third, having multiple classes simultaneously using an institution's Internet connection may stress wide area network connectivity. These are difficult to address within the context of Second Life's business and service model. One way of meeting the challenges of scale is for institutions to run their own virtual world service. Virtualization and private clouds can be combined to ensure efficient utilization of hardware and provide cost-effective support of multiple land spaces. Running a private service brings with it administrative privileges which facilitate the saving and loading of content. This, in turn, enables content development to occur on local installations using predefined libraries which can be easily loaded and configured. Running a private service would also relieve pressure on the institutions wide area network connectivity. A future direction for our work is to explore the suitability of OpenSim [ 24], an open source virtual world, for running an institutional virtual world service. We have successfully implemented the LAVA basilica and associated resources within OpenSim. Early indications [ 25] are that it will prove a viable alternative to Second Life.

Acknowledgments

This work has been supported by FILTA, the University of St Andrews Fund for Initiatives in Learning, Teaching, and Assessment.

    K. Getchell, A. Miller, J.R. Nicoll, and C. Allison are with the School of Computer Science, University of St Andrews, KY16 9SX, United Kingdom. E-mail: {kg, alan, jrn2005, ca}@cs.st-andrews.ac.uk.

    R.J. Sweetman is with the School of Classics, University of St Andrews, KY16 9AL, United Kingdom.

Manuscript received 8 Dec. 2009; revised 23 Apr. 2010; accepted 30 July 2010; published online 13 Aug. 2010.

For information on obtaining reprints of this article, please send e-mail to: lt@computer.org, and reference IEEECS Log Number TLTSI-2009-12-0192.

Digital Object Identifier no. 10.1109/TLT.2010.25.

References



Kristoffer Getchell received the doctorate degree in “Enabling Exploratory Learning through Virtual Fieldwork” from the School of Computer Science at the University of St Andrews in 2009. He is currently working in industry as a systems analyst.



Alan Miller is a lecturer in computer science at the University of St Andrews, where he researches computer networks with a specific interest in their use for enabling advanced learning resources.



J. Ross Nicoll graduated in computer science from the University of St Andrews, where he now works as a research associate primarily involved with the development of learning management systems and exploring the use of multiuser virtual environments in educational contexts.
Rebecca J. Sweetman is a senior lecturer in archaeology and ancient history at the University of St Andrews. She has been involved at some length with excavations on the Sparta Acropolis in Southern Greece.



Colin Allison is a reader in computer science at the University of St Andrews. He has been involved with the research, development, and deployment of a wide variety of technology-enhanced learning resources for over two decades. He is a member of the IEEE.
21 ms
(Ver 2.0)

Marketing Automation Platform Marketing Automation Tool