Second Life Development

There are certain limitations on the realism that is possible in 3D environments in general and in Second Life in particular. The resolution and graphical realism achievable is not of the quality obtainable in many 2D settings. This is offset by the gains in user perspective and spatial awareness. Within these constraints, in constructing the basilica it was important for it to be a realistic representation, in structure, appearance and scale. It was also important that it be accessible so that students could view it from multiple internal and external locations.

The design of the basilica in Second Life brings together information from a number of sources in an attempt to develop an historically accurate reconstruction.

1. Archaeological surveys – for example floor plans which define the location of walls and the

boundaries of the basilica.

2. The iterative application of domain expert knowledge.

3. Photographs of other buildings from the same time period.

Below three examples of how the design evolved are discussed. Of particular interest are: issues of scale, developing reconstructions based on partial information, and the overall modelling process.

Scale within 3D Environments

Scale was a significant challenge to address. Whilst the site plans provided the relative scale of areas of the basilica, they did not provide a mapping to real world measurements. This was obtained by reviewing photographs of the site which contained measuring markers. From this baseline it was then possible to develop an accurate scale model of the basilica.

The question then arose as to whether it was desirable to build the basilica to a fixed scale, or whether it would be better to build the basilica to a scale which would mimic the feel of the building in relation to the size of 6th Century Byzantine people. In terms of developing an accurate representation of the basilica in Second Life, both approaches required an identical approach, with an iterative process being used to provide a mapping between the real and virtual world measurements.

In developing the mapping, the height of the doorways was used as a reference point. By comparing the height of a doorway with the height of an average size person it was possible to obtain a scaling factor which could be used to map real world measurements into suitable Second Life sizes.

Prior to developing the model in Second Life, a similar exercise was undertaken using a number of Quake 2 game maps. During this process, a complete floor plan of the basilica was developed in order to evaluate whether the approach generated a reasonable real world to virtual world scaling factor. As described in Chapter 3 the process was informed by existing work in the area and solicited input from domain experts and students. This investigation suggested that the relative scale was perceived as more important than absolute scale.

Reconstruction Issues

When developing the model of the basilica, certain structural issues were challenging to address. In particular the design of the roof was difficult to ascertain owing to the fact that very little archaeological data was uncovered during the excavation of the site. This is not unexpected, given the way in which the roof would have been exposed to the elements to a far greater extent than the walls and ground works of the church. In addition, the reported explosive destruction of the basilica [16] may have hastened the destruction of the roof, leaving little remaining evidence from which to deduce its original structure.

Given the lack of archaeological evidence available on the site, piecing together an accurate reconstruction required some detective work. Evidence was brought together from a variety of sources to enable the construction of mock-ups which were then critically evaluated by domain experts. When considering the example of the location and appearance of domes on the basilica roof, the layout of the walls in a square formation could suggest a location of a dome. Locating the basilica within its historical context meant that photographs of surviving buildings of similar providence could be used.

In addition, knowledge about the function and culture of the Byzantine Empire could help in these deductions.

The model went through a number of phases in its development, from paper and pencil drawings to 3D models in 3D Studio Max and, finally, Second Life. During each phase, refinements were made. It was particularly noticeable that the 3D first person perspective offered by Second Life allowed a number of adjustments to be identified and made whilst the model was being reviewed by domain experts, the location of the domes being one example. Other examples include the size and shape of statues, the location of windows, the location and shape of the altar and the interior decoration of the building.

The Modelling Process

From the desire for a historically accurate reconstruction, a number of choices about how to use the technology offered by Second Life flowed. For example, there are two ways to build in Second Life: using multiple basic primitive shapes which are grouped together into complex objects, or applying texturing to create sculpted primitives that look like complex objects.

Both approaches give a similar visual appearance when viewed from a distance; however, the sculpted primitives approach does not provide the functionality associated with the complex object it represents: for example, a window or hole in the wall – with a sculpted primitive, the window cannot be opened, or the hole in the wall traversed. This is because, in reality, the window and hole are nothing more than paintings on a solid canvass, with Second Life playing visual tricks to give the appearance of the object being represented. In addition, when viewed close up sculpted primitives tend to appear flat. This reduces their realism as the full visual effect provided by a sculpted primitive object is only visible from a relatively narrow viewing angle.

In contrast, combining multiple basic primitive shapes into a single complex object is able to give both the correct appearance and the functionality associated with the object being represented. When considering the previous examples, the window could be built to support being opened and closed and the hole in the wall could be introduced to allow objects to pass through it. This is because visual tricks are not used to give a flat shape the appearance of a more complex object. In addition, as complex objects comprise several primitive shapes, they can be viewed from any angle and will continue to provide realistic visual representations no matter how closely they are viewed.

A policy of using multiple simple primitive shapes was adopted. Not only does this approach provide an accurate close up representation of the church, but it also makes it possible for students to explore them from a variety of different angles. In addition, the use of simple primitive shapes also makes it possible for the basilica to be constructed in much the same way as it would have been when originally built. The down side, however, is that the approach requires the use of far more primitive shapes than alternative techniques, which in turn means that construction process is more labour intensive and leads to a more complicated building overall.

The Visitor Centre – Linking Second Life with the Excavation Process

The visitor centre provides space for students to construct exhibitions based on their excavation work within the virtual simulator. Providing this facility posed a number of technical challenges which needed to be addressed:

• Authentication and authorisation (Individual and group based).

• Importing digital data relating to the material culture discovered during the excavation process into Second Life.

• Provision of metadata describing these digital resources to enable them to be presented in an accurate context.

When students come to create their exhibition they invoke a script which identifies them and authorises them to access their excavation findings. All the state, objects and information about the excavation that can be used by students is preloaded into Second Life. However, in order to gain access to these resources, students need to make progress in the excavation simulator. When a student visits the visitor centre, their identity and authorisation are checked and a script is invoked which takes a copy of all the objects that they have discovered and places them into a finds box to which the students have access. Students can then add the items to their inventory as required. As the excavation objects already exist within Second Life, this process only has to retrieve excavation metadata from outwith the Second Life environment. This metadata is then used by the scripts to copy the required excavation objects for the students to access from their finds box. In order to achieve this it was necessary to:

• Make use of Second Life’s internal scripting language Linden Scripting Language. • Define and implement an MMS interface to support the exportation of data from resources. • Make use of the Second Life interfaces which allow importation and exportation of data.

Importing and Exporting Data into and out of Second Life

To enable communication between Second Life and external services HTTP [223, 224] requests are used. Supported by Linden Scripting Language, HTTP requests are designed to transfer small amounts of data. This limitation means that intelligent scripts needed to be developed to transfer data which is larger than that normally permitted by the size limits.

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 constructed

to fall within the Linden Scripting Language size limits, with larger data being split over several requests. 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, it is not possible for Second Life to circumvent the limitations of Linden Scripting Language alone. As multiple requests may need to be made to receive all data within a stream, Second Life 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 Figure 65 a stream is broken down into a series of chunks, with a pre-defined terminator. If, after receiving a response, Second Life 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. If no terminator is detected, Second Life will make a further request. This process will continue until such time as the terminator is detected by the Second Life client. A flowchart depicting the process is shown in Figure 66

These two approaches, when taken together, provide support for two way communication between Second Life and external services. However as Second Life clients cannot listen for connections, the communication is event based with the Second Life client responsible for initiating the process as required.

Figure 65 – Content Stream used for Communication between MMS and Second Life

Start

Finish Communication Yes Stream Terminator _Received? No

Data Received Request MMS Content

Process Incoming Data Data Received

End of Stream

Request MMS Content from Offset

4.11 Chapter Summary

This chapter has presented and analysed a substantial case study which demonstrates how learning environments can be enhanced through the integration of gaming methods and technologies in order to facilitate support for exploratory fieldwork. Furthermore this chapter shows that this integration is technically feasible and has significant educational benefit. The objectives addressed by the LAVA excavation simulator are highlighted, with some of the challenges often associated with the teaching of archaeology in a classroom environment discussed.

In contrast to other work in this domain, this work started with a set of pedagogical goals which the framework was designed to address. A significant investigation into the domain to be used for the case study, namely archaeology, was then undertaken. This showed that there is a substantial and real gap between the theoretical and practical aspects of the subject, something that LAVA bridges. The specific excavation used in the case study was analysed and shown to be of significant educational and research interest. Through an overview of the history of the basilica and the excavation work which has been undertaken, the existing archaeological questions that remain are identified, thereby placing the site in a wider academic context.

Having set the framework and provided the background and motivation for the case study, the rest of the chapter goes on to present the design adopted and the solutions developed to meet the educational objectives set out in this and other chapters within the dissertation.

Through the introduction of the LAVA case study, a detailed outline of the excavation simulator has been provided from a student perspective, outlining the activities that are undertaken through the interfaces provided. The user’s perspective is a key part of the design. It is shown that gaming methods, in particular the use of goals, levels and chance all regulate the progress users make through the system and develop engagement. The progressive revealing of artefacts as an excavation progresses is consistent with the goal of supporting exploratory learning. What is more, the linking of the excavation simulator with a reconstruction of the basilica and visitor centre brings together the functionality of 2D and 3D distributed systems so that the educational experience is maximised.

The discussion in this chapter has considered some of the key components of the framework as well as their functionality within the system. A service based approach is advocated by this work. This aids communication between learners and lecturers and provides a structure through which anytime access, self-paced learning and groupwork can be supported. The excavation logic provides the central module which mediates communication between users, institutional learning environments, the excavation learning environment, and Second Life. Although the case study is specific to an individual excavation, it has been shown that the structure used is generic within the domain of exploratory learning about environments which may be inaccessible for a variety of temporal, financial or other reasons, for example: history, geography, architecture and space travel.

The design decisions highlighted in section 4.9 demonstrate that significant and systematic investigatory work has gone into the design of the system. In particular the establishment of a functional division of labour between 2D and 3D user interfaces significantly influences the overall design. This section provides insight into the implementation process that has been adopted, as well emphasizing the student focus which has been adopted with respect to the implementation of the simulator.

Finally the chapter concludes by considering some of the key implementation activities which have been undertaken in order to provide a fully functional excavation simulation operating over several discrete systems.