Location-aware narratives are a form of hypertext in which the path of the narrative is determined by the reader's physical location. In this paper we adapt an existing model of location-aware sculptural hypertext to make it suitable for navigating in virtual space, and create an extension to an existing virtual world to demonstrate how hyper-narratives written in this framework may be consumed in both physical and virtual space. We demonstrate the unique potential of virtual spaces by not only adapting the narrative to match the reader's location, but by adapting the reader's location to match the narrative. In doing so, we lay the groundwork for an experiment into whether the immersive effects of location-aware hypernarratives can be heightened by leveraging the inherent benefits of virtual worlds.
Hypertextual narratives are digital narratives that do not
necessarily need to be read in a constrained order and may branch in
multiple places, allowing for many different tellings and re-tellings. A
location-aware hypertextual narrative can detect the reader’s
position in space (through, for example, their mobile phone’s GPS),
allowing an author to guide a user around a specific set of locations
with which they tell their story. Linking a narrative to the reader’s
physical location can provide readers with a more immersive
experience [
Yarncraft is an attempt to leverage Millard et al.’s location-aware model of sculptural hypertext and in particular to adapt the framework of the GeoYarn client they developed to allow arbitrary narratives to be traversed in either physical or virtual space. For our example, we tailor one of the stories marked up in their framework for use in a physical space around the city of Southampton to be used instead in Minecraft1, a creative sandbox virtual world that allows players to explore a stylised, procedurally-generated environment, build structures and artwork, and interact with friendly and hostile non-player characters (NPCs).
This was a two-stage process: firstly, tailoring the framework to be suitable for virtual locations in general (and particularly for use within Minecraft) and secondly, developing a Minecraft mod (a modification to the base game) to read the framework and present the narrative to the user.
Our modifications to the framework primarily concerned four areas: the level of abstraction available when defining locations, the composition of complex location definitions, the ability to handle concepts and locations described in a story that may be undefined in a particular virtual world, and the ability for stories to trigger events which modify the conditions of the virtual world.
Millard et al.’s framework allows for two types of locations to be used: precise locations, that map to specific areas defined by polygons of latitude and longitude points; and abstract locations that are defined by strings such as “Big Ben”, or concepts such as “quiet”, “green” or “crowded”.
Due to the fact that precise locations cannot be generalised across physical and/or virtual worlds (aside from exceptional cases) our proposal primarily concerns additions to abstract location types.
One issue faced by location-aware narratives, both physical and virtual, is the possibility that there may be no appropriate locations in the nearby vicinity. For example, part of the story may be set in a factory, but the user may struggle to access this if they are traversing the narrative in a national park. Virtual spaces face this same problem, but a further step removed: the very concept of a factory may not even exist in a particular virtual world. While this can be mitigated in part by allowing authors to specify suitable worlds for the consumption of their narrative, a truly generalisable framework must provide mechanisms for handling this issue.
Similarly, when designing a location-aware hypertext for a fixed device or set of devices, assumptions can be made about the available hardware and sensors (for example, that a hypertext designed to be consumed on a mobile phone will be provided with GPS coordinates). However location-aware narratives in virtual worlds have access to many more potential information sources at higher levels of accuracy, without the requirement of (additional) sensory hardware. For example, weather data, light level, noise level, as well as more abstract or esoteric information such as the emotional state of nearby people, or the number of spiders within 100m. When designing for a much wider range of devices, platforms and worlds, with a wide range of capabilities and features, it is important to be able to provide the intended experience using alternative sensors when the preferred sensor is unavailable.
In our modification of the GeoYarn format, locations are stored as an ordered list of objects. Each location in the list is one possible match for the location required by the given page. A client should attempt to match the earliest listed location that they have the appropriate sensors for. This mechanism allows authors to define several “fallback” locations that steadily become more general. For example, in the example shown in 3, the page would ideally take place near Big Ben2, though for physical locations outside of Westminster any clock tower would suffice, and for virtual worlds which have no clock tower, or locations that have no concept of a clock tower, any building would suffice.
This mechanism can ensure that stories are consumable on a large range of devices. However, this can still fail, either because fallbacks have not been defined or because they are still too specific for a particular client to interpret (for example, if a client attempts to interpret a story designed for a very specific world). When these failures occur, and clients are unable to attempt to match any of the possible locations, the user should be presented with a map whereby they can define a location that best approximates the query.
As well as allowing authors to define fallback locations, our additions to the GeoYarn format allow for the use of “AndLocation”, “OrLocation” and “NotLocation”. These operators allow for the composition of simple locations to create more specificity, without 2The Great Bell of the clock in Elizabeth Tower, Westminster "type": "AndLocation", "location1": [ { ] requiring each client to provide the full definitions of these locations.
The location in 4 defines a noisy, indoor area. Without the use of AndLocation, this would require each client to provide a tag representing this type of location.
Note also that the locations defined as part of AndLocation, OrLocation, and NotLocation are also defined using arrays, and exhibit the same fallback behaviour as other location arrays. In this case, it would be pragmatic to specify fallbacks for systems that do not support the "noisy" or "indoors" tags.
Location-aware narratives based in the physical world allow the story to be adapted to the user’s location either through branching the story as the user moves through space, or by modifying the tone of a page to suit the user’s current location. However, with a virtual world, the world itself can also be adapted as the narrative progresses. This can be done to shape the general aesthetic and environment of the virtual world to be in keeping with the narrative (as a whole, or at a specific point in time); for example, altering the weather or light levels. This can also be leveraged if the author wishes to trigger specific events during the course of the story. In Figure 5 the player is instructed to go to a place where people gather. Due to the state of mind of the protagonist of the story, it appears deserted at first. But, when the player arrives in Figure 6, a crowd of friendly NPC villagers appear around them.
If this story is to be played in the physical world, then these events would not execute and so they should be used to optionally strengthen or demonstrate the content of the story, rather than as a replacement for it. ]
Our modification to Minecraft acts as the client for reading the narrative framework, and allows for a relatively simple presentation of the stories to the user: when they start the story they receive a short hint of where they can find accessible pages. When they arrive, they receive another message with the text of that page, and more hints to the location of additional pages. A more complex future implementation could add extra functionality such as a means to browse through already collected pages, the ability to switch stories within a particular world, or the ability to save their progress. However, the key challenge of creating the client is appropriately interpreting the location tags and events in a way that matches the aesthetic of the story to that of the virtual world.
In this paper we adapt an existing model of location-aware sculptural hypertext to allow narratives to be traversed in arbitrary space, physical or virtual, allowing users to choose the location and environment that suits them.
The key to successfully generalising this framework will be to ensure and maintain a fine balance between abstracting the framework enough that it can be freely applied to other virtual spaces (as well as the physical world), and still allowing authors to specify locations with enough accuracy that their stories still benefit from being location-aware. The ability to manipulate the reader’s environment in such a drastic fashion - altering the weather, time of day, and even physical laws - is a particularly unique ability of virtual worlds. However, while this can lead to a more tailored (and potentially immersive) experience, the greater and more specific the degree of control exerted over the virtual world, the less abstract the framework becomes. A solution to this is to have a library of standardised vocabulary of tags that all compatible clients must adhere to. While it would be infeasible to provide a comprehensive list of all possible locations or events that an author might require, a limited (but broad) sub-set may be useful as a guaranteed fallback. While the initial barrier to entry for authors trying to develop stories for as-yet unsupported platforms is high (as each virtual world requires a specifically written client to read the story framework and present the narrative), once a client is developed it can be reused for multiple individual stories. Further technical work in this area will be to develop additional clients for alternative virtual spaces and demonstrate how a single story can be read across different worlds, and an authoring tool that includes the means to fully utilise the functionality of virtual spaces.
An interesting avenue for future research in this area is to investigate how readers experience immersion in a virtual world that they feel “at home” in (such as a Minecraft world that they have spent time and effort building in) when compared to a virtual world they have no previous attachment to, and to familiar and unfamiliar physical locations. Further areas of future work include conducting studies to determine how comfortable authors are when writing narratives for multiple worlds, and how users choose to consume them.
While this is an early proof of concept, we hope that the additions made here provide further incentive for people to develop locationaware hypernarratives in new and innovative ways.