CIPHER CITIES - eprints.qut.edu.au5.1 Web 2.0 28 5.2 Community Building 32 ... 7.2.10 Findings and Recommendations (Game Conceptualization) 91 ... 8.2.1 Step 1: Collection of Details

CIPHER CITIES Creating Tools to Support and Sustain Community Co-production in the Area of Mobile Game Design

Sherwin Huang BA Creative Industries

(Communication Design)

Communication Design Faculty Creative Industries

Queensland University of Technology

Supervised by: Debra Polson

Submitted in completion of Master of Creative Industries

Acknowledgements The acknowledgements may have its place at the start, but it represents the end of my adventurous foray into the dark abyss that is new knowledge. Like any successful adventurer, I could not have gone at it alone, just like Mr T. would not have been as successful a mercenary without the A‐Team, and so I must give credit where it is due:

My supervisor Deb Polson For starting me off at ACID and later getting me started on the idea of taking up post graduate studies. Thanks for being so patient and spending all that time reading draft after draft of my exegesis. Your guidance has been invaluable. The Cipher Team Yang Wong, Ben Gribbin & Timothy Tran One couldn’t ask for a better bunch to work with. Even with deadlines and stress not a single frayed nerve. Especially Yang with his cool can do attitude and Ben and Timothy for slogging it out with all the coding. You guys make meetings so much more tolerable. My Family For giving me so much support even though most people my age back home have already started doing proper work. ACID For the scholarship and logistical support, without which I would be poor and destitute. Test Subjects For just turning up.

Designing a Web Based Interface to Encourage the Creation of Mobile Phone Based Location Based Games

Contents 1. Overview 12. Introduction 33. Methodology 7 3.1 Grounded Theory 8

3.2 Participatory Action Research 10

3.3 User Testing 12

3.4 Team Collaboration 14

4. Looking at Location Based Games 17 4.1 Location Based Gaming at a Glance 17

4.2 Picking Apart Location Based Games 20

4.3 Derived Concept 25

4.4 Positioning Cipher Cities 27

5. Design Considerations 28 5.1 Web 2.0 28

5.2 Community Building 32

5.3 Technological Mediation 35

5.4 Persistence & Capability for Real Time Interaction 39

5.5 Allowing Representation of Identities 43

5.6 Content Creation 45

5.7 Interaction Design and Usability Issues 48

6 Resulting Creative Work 50 6.1 Outline of Main Interface Components 50

6.2 Initial Main Interface Designs 52

6.2.1 Personalised Profile Page 52

6.2.2 Group Page 54

6.2.3 Game Viewer Page 55

6.2.4 Game Builder Structure 57

6.2.5 Game Builder Step 3 58

6.2.6 Game Builder Step 4 59

7. User Studies and Findings 60 7.1 Cipher Cities User Testing Stage 1 61

7.1.1 Executive Summary 61

7.1.2 Problem Statements 62

7.1.3 User Profile 64

7.1.4 Methodology 65

7.1.5 Task List 67


7.1.6 Test Environment/Equipment 71

7.1.7 Test Monitor Role 71

7.1.8 Findings and Recommendations 72

7.2 Cipher Cities User Testing Stage 2 76



7.2.3 User Profile 78

7.2.4 Methodology 79

7.2.5 Task List 83


7.2.7 Test Monitor Role 87

7.2.8 Evaluation Measures 88

7.2.9 Findings and Recommendations (Game Builder) 89

7.2.10 Findings and Recommendations (Game Conceptualization) 91

7.3 Cipher – MiLK Game Builder Workshop 94



7.3.3 Workshop Schedule 97

7.3.4 Task List 98


7.3.6 Workshop Facilitator Role 101

7.3.7 Evaluation Measures 102

7.3.8 Findings and Recommendations 103

8. Current Cipher Interfaces 106 8.1 The City Page 107

8.2 Registration 109

8.2.1 Step 1: Collection of Details 110

8.2.2 Step 2: Verification 112

8.2.3 Step 3: Profiling 114

8.3 Personalised Home Page 116

8.4 Participation and Game Listing 118

8.4.1 Game List 120

8.4.2 Game Page 121

8.4.3 Join a Game 122

8.5 Game Creation 124

8.5.1 Game Creation Step 1 125






8.5.6 Game Creation Complete 132

8.6 Groups 133

8.7 Game Icons 135

9. Findings 136 9.1 Interface and Interaction 136

9.3 Practice 138

9.4 Potential for Future Research 139

References 140 Appendices A. Analysis of Location Based Games B. Results from Analysis of Location Based Games C. Cipher Cities User Testing Stage 1 Results D. Cipher Cities User Testing Stage 2 Results E. Cipher – MiLK Game Builder Workshop Results


1

1. Overview My foray into location based gaming started because as a web designer, I felt that I wanted to expand

my practice from one that consisted of straightforward interface design, to one that encompassed a

wider variety of skills by improving on my knowledge and expertise in the burgeoning field of interaction

design. This allowed me at the same time, to incorporate other aspects of design that include the user‐

centred design of tools for collaboration, content creation and community creation. I take a particular

interest in the opportunities afforded by the convergence of web and game based technologies,

especially when mobile interaction is afforded by such convergences.

This exegesis describes the theoretical underpinnings that have informed the creation of a series of

graphical interfaces that serve to bridge the gap between system capabilities as envisaged by the

developers and a user’s experience facilitated by an interface. The actual research into creation of the

interface was preceded by an exploration of the field of location based gaming from which the initial

area of interest was derived. Due to the fact that location based gaming is still an emerging field, it

required the creation of a custom taxonomy for the works to be systematically separated into their

various elements for analysis. The taxonomy to be created involved the combination of three smaller

individual taxonomies in a way that has not been attempted previously and in a way that would give a

balanced account of what makes up a location based game.

The area of interested identified was how location based games might be made more readily available

for a wider audience. Cipher Cities, which was a system in development at the time, was one that was

already designed for such an application, but now required an interface that would appropriately

represent what it aimed to achieve. I joined the team as their interface designer and it became clear

that due to the location centric nature of the game, the only feasible way to go about democratising the

participation in such games was to make it easy for people to build their own. The issue that arose was

how an interface could encourage the creation of as well as participation in location based games. This

required reference from current Web 2.0 applications that use members as creators of content as well

as research into the theories behind community building, content creation and distribution in support of

such an interface.


2

These theories were put into practice and implemented before being evaluated and verified through a

series of user testing sessions that served to refine the system in terms of user interface design and

system functions.

The result of the research is the first interface ever created that works to support a system for the

creation of location based games by the public. More importantly, it is a robust, interface that is

attractive as well as usable.


3

2. Introduction The initial research into LBGs in an attempt to find a way to improve or change the way such games are

played. I found the concept of LBGs, which involves taking games out of the usual private space into

public space extremely interesting. The fact that a computer based game can be played out in “real”

space provides a plethora of opportunities for subversion of space, and as well as encouraging direct

social interaction, possibly even enhancing it (Benford, 2005c, p. 2).

In order to better understand location based games, rather than trying to recreate the genre, I applied

grounded theory research methods and drew inspiration from other successful location based games,

because that was the most feasible way to tackle the subject. Glaser suggests, “Since so much of

originality or creativity is not new ideas – since most ideas are already known in some way – but new

connections between conceptual ideas, this puts a premium on the discovery and adept use of

theoretical codes, which are the connectors.” (Glaser, 1992, p. 29) By analysing related work and then

forming connections between them to fill what was once a void, new ideas can be generated and

adapted from current situations. In Research Methods for Designing Effective Experiences, Nathan

Shedroff writes that systematically picking through situations to create a “more complete understanding

of experiences as well as opportunities for redesign.” By systematically, Shedroff refers to the use of

taxonomies in deconstructing a work (Shedroff, 2003, p. 156). This would entail the creation of a larger

taxonomy that would be able to “disassemble” the games sufficiently to be analysed in detail.

In section 4, I will outline how this broader taxonomy was constructed of a variety of relevant

taxonomies that dealt with a range of issues pertaining to gaming, ranging from rules: Salen and

Zimmerman’s Rules of Play (Salen, 2004, p. 130), to player participation: Aarseth’s Typology of Textual

Communication (Aarseth, 1997, p. 58) to technology: Malcolm McCullough in Digital Ground, has

proposed a set of 10 “essential functions” for pervasive systems (McCullough, 2004, p. 73‐92).

Applying the combined taxonomy like acts a chromatogram allows the ideas in each of the games to be

distilled, and the most glaring issue that came out of the analysis were the technological constraints

resulting from the fact that all the games required technology that would be set up at great cost, or

required more advanced experience with technology to participate in. These issues meant that only a

privileged few in and around certain geographical locations were eligible to participate in such games.


4

Being involved with ACID by way of a scholarship presented me with the opportunity of contributing to

the design of the Cipher Cities system which is a web based system for the creation and deployment of

LBGs.

When I came on board the team, the engine built for Cipher Cities was already very robust, having

already been tested through a number of location based games that had been created using the system

and run over a few years, including Cipher Valley and several iterations of Scoot. While these trials had

been successful, interest now lay in how the system might be presented in order to reach a larger

audience, allowing people anywhere to build and distribute their own games. This provided me with an

opportunity to explore my own interest in opening up location based games, and allowed me to be part

of an exciting project with a team that would provide all the necessary support for any research to be

done as well as enhance my primary practice as an interface designer. How I operated as part of the

team is detailed in section 3.4, which talks about the Cipher Cities team, our roles and how we worked

together.

It is important to note that Cipher Cities is an attempt to combine location based games with digital

social networks as is often seen in sites with community created content. While doing studies into how

users might be encouraged to create content for such a large number of localities, it became clear that

there would be a need to take reference from the Web 2.0 model of content creation and distribution.

The term system is used because the design of the user interface will have to be designed in tandem

with the capabilities of the system and vice versa, as they are informed initially by theory, as

documented in section 5, the experience of other team members, and later on through user testing as

seen in section 6.

The emphasis on social networking and status building grew as research into content creation showed

that participation was often dependent on some aspects of sociality and status being addressed as

detailed in section 5.6. This entailed the provision of functionality that would encourage the propagation

of communities, because the idea of making a meaningful contribution to an online community is a

factor that will encourage the creation of content and greater participation. Content and community are

clearly very much intertwined, and it would not be possible to have content generation without

facilitating for community and vice versa (Sangwan, 2005, p. 2). This is discussed further in section 4.1.


5

To address the issue of community building, research was done into factors involved in the propagation

of online communities. In following with the grounded theory approach, literature and current examples

were referenced. What resulted was a system that was a cross between MySpace, Flickr and eBay. This

would allow users to build a personal profile, and earn rankings for themselves by playing and building

games. They would be able to join groups for users with similar interests and share their games and play

alongside other users.

What really sets Cipher Cities apart from other Web 2.0 style applications is that unlike most web 2.0

applications such as Flickr or YouTube where user created content could be as straightforward as a

snapshot straight from a simple digital camera, as in the case of Flickr, or as complex as an edited video

on YouTube, the crux of the issue is that there exists a spectrum of difficulty that varies from requiring

nothing but an internet connection and a camera to making short films, but no matter which end of the

spectrum a user was at, participation in content creation was still possible, and would result in

something that was “consumable” by other members of the site.

Having looked at the different vectors that intersect and form a game, it became clear that even basic

games have to address a large number of factors and follow a logical sequence of events in order to

achieve even the most basic level of playability. From looking at this, it is clear that the spectrum of

difficulty still exists for Cipher Cities, except that unlike Flickr or YouTube, even at the most basic level a

great amount of thought and planning has to go into making game to make it consumable.

Quality content is especially important because it helps in getting users to participate and return to the

site. As mentioned earlier community building and content creation are intertwined, and communities

built around location based games would not be possible without location specific content. This

consideration therefore made content creation the focus of the study. It was imperative that the build

system was easy to use, and served not only as a tool, but as a guide as well, taking users through the

various steps, and providing all the necessary fields that would allow for users to build their own

playable games.

While much is said about the aspects of community building and Web 2.0, and a lot of what has been

documented has contributed to the eventual design of the system, the user studies in this exegetical

component will mainly focus on the game builder, because due to time constraints it would not be


6

possible to study community’s effects on location based games. It was found therefore to be enough to

conduct detailed studies on the nature of content creation, particularly focusing on the game creation

process and usability of the interface.

This was achieved through participatory action design going through 4 main action research iterations.

The initial iteration involved peer critique, and while it was represented diagrammatically as only one

iteration, it really consisted of many smaller iterations made up of meetings with the team that go on

throughout the process. Following this was three other iterations, as seen in sections 6.1 to 6.3, which

required the development of methods of evaluation that would facilitate the assessment of the

interfaces and determine their levels of effectiveness for their intended purpose since the interfaces

required complex responses from users, it was necessary to combine various methods of trialling. The

first focused on the interface as a whole, ensuring that the language was appropriate, and the final 2

were focused on the functionality of the game builder interfaces, essentially requiring players to create

their own games.

The result of this process is the design of an easy to use game builder that will later be supported by a

community base of players and builders that empower the everyday person in the creation of and

participation in location based games.

My contributions are outlined in section 4.8, which shows the initial interfaces and chapter 7 which

shows the final interfaces that have been influenced by user testing, as well as in the iterations of the

user studies in section 5, which involved the adaptation of existing methodologies for user testing to suit

the complexity of the expected user outcomes.


7

3. Methodology

Diagram 3.1: The practice-led, participatory design action research cycle overlayed with a grounded theory framework

The research was designed to be practice‐led, culminating in the creation of an informed work. This

work was to be the result of analyses of other location based games and relevant literature from a

grounded theory approach, refined further by use of the participatory action research model based on

the Kemmis and McTaggart action research spiral (Kemmis, 2005, p. 564).


8

3.1 Grounded Theory

The draw of the grounded theory technique was its empowering nature, especially coming from a

position like mine, starting with an area of interest rather than a preconceived problem (Glaser, 1998, p.

118). This approach involves not reading literature first, but generating hypothesis from data (Glaser,

1998, p. 68). Drawing inspiration from related work stems from taking up a grounded theory approach

since as Glaser puts it, “Since so much of originality or creativity is not new ideas – since most ideas are

already known in some way – but new connections between conceptual ideas, this puts a premium on

the discovery and adept use of theoretical codes, which are the connectors.” (Glaser, 1992, p. 29)

Through analyses of related work, deriving data and comparisons from the analysis, and then forming

connections between them to fill what was once a void, I was able to generate and adapt new ideas

from current situations.

In diagram 3.1, the action research cycle has in it elements of grounded theory, which was mapped out

by Barbara Adkins in “research as discovery” method (Adkins, 2006). This meant that results of the

iterations allowed any issues present to continually emerge throughout the process (Glaser, 1998, p.

119). This often resulted in emergence of issues that mean revaluating the way the problem was

approached, or issues that concerned the results of previous iterations. This also guided the evolution of

the various iterations involved in the research cycle.

The initial hypothesis was to be generated from observations and involved the following initial steps:

• analysis of related work

• data collected from the analysis was tabulated

• description of patterns from collected data

• a retrospective approach that resulted in building on one idea

• identification of key issues with the work (application of theory)

• conduct of a technology audit (application of theory)

• identification of related feasibilities (application of theory)

Having started with the hypothesis that there was some improvement that could be made to the way

location based games were played, I made observations and found of patterns in the observations. This


9

pattern indicated that the problem lay with the way games were deployed with regards to technology

and as a result geographically.

In order to allow the base problem to emerge, I had to look at examples of previously run location based

games. The fact that location based gaming is a nascent field as stated earlier was advantageous for

working from a grounded theory perspective, because the lack of substantial literature studying location

based games meant that there would not be so much of an issue of being influenced by literature in the

area of study (Glaser, 1998, p. 67). As such, I was in a position to create a starting point of my own. The

question that had to be addressed first was: How does one go about creating this starting point?

In Research Methods for Designing Effective Experiences, Shedroff writes that systematically picking

through situations to create a “more complete understanding of experiences as well as opportunities for

redesign.” By systematically, Shedroff refers to the use of taxonomies in deconstructing a work

(Shedroff, 2003 p. 156). This entailed the creation of a larger taxonomy than what was available, and

that would be able to “disassemble” the games sufficiently to be analysed in detail so that the individual

units could be compared in hopes of finding gaps. Because this section addresses the general method by

which this research will be conducted, the taxonomies in question will be discussed in greater depth in

the following section.

This combined taxonomy was applied to location based games and yielded enough data to form a

concrete starting point, which allowed the commencement of design work, accompanied by the

iterations that will make up the action research. The first iteration required the developing of a basic

layout, and had all the primary features that would address issues exposed by the taxonomical study

conducted earlier. This will be discussed in further details in the section “Looking at Location Based

Games”.


10

3.2 Participatory Action Research

Kemmis and McTaggart describes the action research process as a “cyclic or spiral process” which

“alternates between action and critical reflection” (Dick, 2004) in order to refine the methods of

production as well as the prototype. This was especially relevant because its “emergent and responsive”

nature, which evolves from cycle to cycle (Dick, 2004) allowed me as a researcher to gain a better

understanding of my work as it progressed, especially in a grounded theory framework thus ensuring

that at all times there was firm grasp on the evolution of the project.

Richard L. Baskerville (Baskerville, 1999) writes that “Action research aims at an increased

understanding of an immediate social situation, with emphasis on the complex and multivariate nature

of this social setting in the IS domain.” and that “Action research is performed collaboratively and

enhances the competencies of the respective actors.” Because it allowed me to gain immediate insight

on developments which could be applied to the refinements that would take place post reflection, using

participatory action research allowed me to greater understand the impact of the complex translation of

an interface between system platforms.

Participatory action research is a subset of action research which incorporates sociality into action

research such that it engages people in examining their knowledge and their interpretive categories as

well as being critical. It also aims to transform theory and practice by exploring other perspectives within

what might be personal theories and discourses (Kemmis, 2005, p. 566 ‐ 568). Such research has been

defined as “an inquiry that is done by or with insiders to an organization or community, but never to or

on them. It is a reflective process, but is different from isolated, spontaneous reflection in that it is

deliberately and systematically undertaken and generally requires that some form of evidence be

presented to support assertations.” (Herr, 2005, p. 3) This was especially ideal for Cipher Cities, because

while I had my own preconceptions about how it would be best to design an interface, end users would

be the ones required to perform complex tasks, the process of which was little understood at the time

(Lazar, 2006, p. 15) This helped weed out any personal biases or preconceptions that might have been

present through the iterative process of gathering evidence, which in this case was usability testing.

When grounded theory analysis was completed the area of interest was define, design of the actual

action research process began. In this case, the analysis showed that there was a distinct geographical

“favouritism” involved in the deployment and participation of location based games decided by way of


11

technological resources and knowledge. In order to be able to approach this, I joined the Cipher Cities

project, which had the potential allow anyone to design as well as participate in location based games

without having to acquire additional hardware (see “Looking at Location Based Games” and “Design

Considerations”) if properly presented. This then led to having to design a site on a conceptual

framework based on community building and content creation.

The implications for the implementation of a participatory action research system was that it would

have to involve participants, because the complexity of the system to be designed as the builder would

invariably have to incorporate users in the process order to ensure that the design was going in the right

direction. By engaging and cooperating with “outsiders” (Herr, 2005, p. 36‐40) through user testing, the

team as insiders was be able to gain the advantage of the user’s perspectives and expectations from the

interface.

Another positive aspect of participatory action research was that working as part of a team, I had could

draw from the experience and capabilities of the other team members. This stemmed from recognizing

that “workers are a prime source of innovation, that design ideas arise in collaboration with participants

from diverse backgrounds, and that technology is but one option in addressing emergent problems.”

(Trigg, 2000) By accepting contributions from others the project evolved in ways that would not have

been possible if I was the only one working on the system, because the team consisted of specialists in

each area that who were able to lend their experience and knowledge to the project.


12

3.3 User Testing Musser summed up the importance of involving users in the design process when he wrote that “User

engagement and efficiency are first‐order priorities and should not be sacrificed for the latest

technology or interface fad.” (Musser, 2007, p. 33) The case with Cipher Cities is that while most of the

site was designed with reference to existing literature or websites, the game builder being a first of its

kind tool had to be designed from the ground up which proved to be an even greater challenge because

of the complex nature of the tool (but this will be discussed at a later stage).

The user testing process required the recruitment of participants at various stages of the project to help

test the interface at its various levels of completion. The focus of the tests evolved with the progress of

the project, and moved from a broader study that covered aspects like language and site usability to one

that was more narrowed down to look at specific features of the site and functionality.

The kinds of tests run also varied in accordance to the various stages of the project’s development cycle

so as to optimally use what each stage of development was able to offer for testing (Rubin, 1994, p. 30‐

31). The 3 main kinds of tests conducted were the exploratory test, the assessment test and the

validation test.

The exploratory test was conducted during the early stages of prototype production, where the

interface was at its most basic in terms of functionality. This required participants to navigate through

the prototype and confirm if the designs were sufficiently usable by looking at the effectiveness of

organization, the graphic approach, accessibility, points where help will be required and how to address

reference information (Rubin, 1994, p. 31‐36).

The assessment test involved confirming that the low level‐operations were usable, which meant that

unlike the exploratory test which dealt with language, categorization and appearance; this test involved

the participant in performing various tasks, and would involve working with functioning versions of the

prototype. This was especially important because it allowed me to determine if a working process as

defined by the team was indeed simple enough for regular users to grasp (Rubin, 1994, p. 37‐38).

The final kind of test was the validation test which was conducted closer to the release date and served

to confirm that the issues uncovered during earlier tests were fixed and that users could actually use the


13

interface and that they were able to produce content that could be used by other users as well (Rubin,

1994, p. 38‐46).

It is important to note that these are just quick descriptions of what will take place. Each test was run

with a methodology of its own that is documented in section 6 in far greater detail. The results of these

tests will be presented both in a report form as well as with short vignettes or images from each one.


14

3.4 Team Collaboration

Having been presented with a scholarship from ACID, I was given the opportunity to join the team for

any projects that might be related to my area of research. In this case it was the Cipher Cities project,

which was taking an approach to location based gaming that was akin to where my interest lay in that it

allowed people to create location based games. The Cipher system had already seen use in two location

based games, namely Cipher Valley and Scoot, so the back end that would deliver SMSes was already

quite robust and well tested. The team, which was experienced in the design and delivery of location

based games had already begun planning for a system that would allow the system to be deployed on a

far larger scale, enabling the general public to engage in the creation and distribution of location based

game; a task that would required an interaction designer to assist in the design and development of the

interface and consequently additional system features. When I came on board the team consisted of:

• Lead Designer: Debra Polson

• System Architect: Yang Wong

And in later stages was later supplemented by the addition of more technical staff:

• Interface Coders: Timothy Tran and Benjamin Gribbin

The practice led research tied in with the action research cycle in that it involved me in my role as the

interface designer (which developed into interaction designer and later usability tester) going through

the process of design and testing and then going back to the team with feedback involving the team in

the following ways:

• Workshops/Peer review

• Support for user testing

• Conduct of personal debrief (one on one debrief with team members)

• Shared documentation

As part of the action research cycle, peer review was instrumental throughout the iterations not only

during initial design phases and prior to the first round of user testing where the first iterations of the

interfaces were being designed, but also post user testing in later versions of the interface when the

implemented changes were reviewed before being finalized. It should be noted that because Cipher


15

Cities is in fact ground breaking in that it allows users to build their own location based games, there

was no way for the team to reference any examples, and as such much of the design, especially with the

game builder, had to be built from experience and some amount of imagination, which while isn’t a

scientific method of design, allows for the creation of interfaces that combine “interesting ways with

familiar ways of interacting” (Wright, 2005, p. 25) which is essentially what we wanted the builder to

be.

Workshops and Peer Reviews

Initial peer review involved getting the team together for workshops to decide on the functions that the

system would benefit from. Polson as an experienced game designer, having had experience designing

and directing previous iterations of Scoot and Cipher Valley was able to provide insight into what users

might expect from the system in terms of functions and features, guiding the team’s activities and

interpreting user responses and technical reports into overall project specifications. Because the Cipher

engine was significantly developed, Yang Wong as the system architect was able to clarify any questions

we had about system issues, and let us know what we could or could not achieve within the time frame

and with the available resources. My role meant that I was to act as a bridge between the development

team and the end user, primarily concerning myself with aesthetics, user experience and usability,

starting with a theoretical approach to usability that later expanded into a more practical approach

involving usability trials. In taking a user centred approach, it was necessary to settle on the functions

and the creation of an interface that would serve to represent the system (Isaacs, 2002, p. 87‐90) in a

way that would ensure it served to enhance the user experience, as well as support individual user

access, promote community building as well as the production and dissemination of content.

From the results of the initial workshops the first iterations of the interface designs were produced that

were eventually refined over a series of other workshops and user testing sessions. The functions

themselves were also not fixed and would change to suit the results of user tests. These interfaces were

later refined further in user testing, and when Gribbin and Tran came on as interface coders later, they

participated in the peer review process as well, where the team helping not only to scope the project,

but also contributed in helping refine the interface further.

User testing

User testing also benefited from the contribution of team members, especially in recruitment of test

participants as well as aiding in the monitoring of tests. During usability testing, I was involved in the


16

planning of tests and in the conducting of the tests both logistically as well as acting as a monitor. It was

important that team members made themselves available to help out during testing due to the fact that

testing requires more than one monitor to be present, as can be seen from the methodology portion of

the user testing section. There was also useful input during the preparation of test plans and

questionnaires when members of the team would help to refine some of the questions being asked as

well as contribute to the questionnaire with issues that they felt were important to the design and

development of the system both with the interface and the architecture.

Personal Debriefs and Shared Documentation

The results of the user tests were compiled and disseminated, following which a personal debrief was

conducted with relevant members of the team to evaluate the possibility of such a change and prepare

them for potential changes that may have to be made. The personal debrief was possible because of the

team’s compact size and flexible meeting times, which allowed us to meet one on one more or less

anytime during working hours. This debrief was then followed by another workshop to confirm and

finalize the changes that had to be made. The second round allowed the team to go through the

changes together and evaluate them in terms of priority. This is how the majority of late stage

workshops were conducted, having moved on from higher level design issues to dealing with more

specific issues that came up during testing.

Shared documentation in the form of emails and post workshop write ups acted as informed

specifications that determined the ongoing development of the system. These were emailed to all

members of the team to disseminate information or for personal debriefs.

Working this way as part of a team gave me the opportunity to create and internalize a personal work

method, as well as refine my practice of working with an interdisciplinary team, especially given the size

and scope of the project. All this has served to advance my practice as an interface designer, allowing

me to work on a more diverse set of projects.


17

4. Looking at Location Based Games

4.1 Location Based Gaming at a Glance Pervasive gaming is a field which has emerged from the advent of ubiquitous computing, which has in

turn benefited from the continued development of smaller and more powerful processors (Lightman,

2002 , p. 114). It has opened the doors for computer games to be moved into an increasingly public

domain (Benford, 2005c , p. 2), encouraging direct social interaction, possibly even enhancing it. At

present, pervasive games come in a variety of flavours.

Location based games (also sometimes called Location‐Aware games) are a subset of pervasive games.

These games incorporate precise spatial tracking, and can be used to describe “any game that

incorporates the player’s location (even if relative) and/or movement into the game.” (Uhlir, 2005)

These games regard the entire world as a game board (Magerkurth C., 2005 , p. 8), creating game‐

scapes as large as the system allows it to be.

Such games are often designed with the intention of taking gaming out of a personal space, projecting it

into a public/social space (Hall, 2005 , p. 47), creating what the leading theorists in the field have come

to term “social computing” (Cheok et al., 2004), extending the notion of “personal” computing that has

been associated with the personal computer into networks built on real world interaction, reinvigorating

the levels of social interaction that was previously associated with board games (Benford, 2005c),

simultaneously exploiting the increasingly pervasive nature of technology ergo creating possibilities for

the building of relationships between individuals at a level that was not possible before; from only

people playing the game around a table top to the sum total of people with the means and motivation

to participate.

The problem with many such games is one of the features defines them: they require precise spatial

tracking. Tracking is more often than not performed with the aid of GPS technology, which while already

fickle in that it requires a variety of factors to be available for efficient operation (relatively clear skies,

open and unsheltered areas) has proven to be unreliable in the urban areas that the games are

deployed in because of interference from buildings (Benford, 2005b, p. 11). Some have tried to


18

overcome the problem by introducing “seamful design” into games, which involves incorporating these

limitations into the games rather than trying to work around them (Broll and Benford, 2005, p. 1) in

order to promote the use of games over a wider zone. However, both approaches still centre around the

use of Wi‐Fi hotspots that may or may not be present in many urban areas, which means that it

magnifies the zone of play somewhat, but still not really being able to deliver the game on a global scale,

thus limiting the opportunities for the games to actually be exploited for “limitless” (I use the term

loosely, discounting many less developed areas) social computing.

These are all areas that have to be addressed with a system which makes use of accessible technology

which will allow a larger body of everyday people greater agency within their surroundings and with

each other on a day to day basis, as far as possible without the need to acquire specialized equipment of

set up and network especially for the game (Borriello et al., p. 36), thus making it effectively a real‐world

system.

Another branch of location based games, are based on the mobile phone platform, where players

engage in activities within locations that they encounter during the course of their day to day life. With

advances in mobile technology and an increasingly developed infrastructure these games are steadily

gaining in popularity. In the United States alone, 2004 saw mobile location based games taking in $72

million, an amount that is expected to increase to $430 million by 2009 (Kushner, 2006, p. 62).

Location based games run on a mobile platform have the capacity to be played over a much larger area,

because of the availability of GSM networks in most built areas (Sotamaa, 2002, p. 36), but this spread

also has limitations that may work against the system, because games often cannot be accurately

location aware due to technological limitations and have difficulty tracking and updating the location of

players spread out over a large area (Borriello et al., p. 38). With such a system, there is no fixed area for

play; therefore these games are more likely to involve the player’s daily lives rather than the actual

space (Chang, 2004a, p. 1).

It should be noted that location based gaming is a nascent field (Uhlir, 2005), and that the lines in the

sand have not been drawn, so to speak. Not much has been written of the nature of location based

games, and there is a lack of a clear distinction of how a location based game is put together. It is known

that these games are effectively a hybrid, often mapping the virtual world of computer games on to the


19

real world (Capra, 2005), whilst incorporating forms interactions that we have grown to be familiar with

through real world interactions and social behaviour (Magerkurth C., 2005, p. 2), be it the most banal

such as moving through a space, or something like playing a game of tag.

It is in the aspect of design that there is a great crevasse in terms of knowledge available to the

researcher. As such, there is need for a means by which such games can be analyzed and picked apart so

as to determine how best to design a game that is engaging, playable, and ultimately will be accessible

to an audience on a much wider scale than has been seen previously, thus increasing possibilities for

social interaction.


20

4.2 Picking Apart Location Based Games In order to deconstruct location based games, we must first discuss what a game is. The general notion

of gaming is often taken for granted as an activity we do for leisure, but what really makes a game?

Much has already been written about what games are and how to define a game (See (Salen, 2004)), so

to go into that would be mere repetition and thus unnecessary. A more suitable alternative would be to

look at a definition of a game so as to gain a better understanding of what a game constitutes.

Back in 1971, games were described by Avedon and Sutton‐Smith as “an exercise of voluntary control

systems, in which there is a contest between powers, confined by rules in order to produce a

disequilibrial outcome.” (Avedon, 1971, p. 405). We know from that description that a game is

something that is people become a part of voluntarily, and by becoming participants, they become part

of a contest, whether between players, or between players and the system. All of which is governed by a

set of rules that help to define one side as a winner and one side as a loser. This still holds true today,

but what else constitutes a game that has been designed to fit today’s context?

A more recent definition states that games, specifically computer games are “a form of art in which

participants, termed players, make decisions in order to manage resources through game tokens in the

pursuit of a goal” (Costikyan, 2006, p.196). Thus we can see that computer games are more specific

about the forms of interaction that they require participants to engage in. To look more closely at what

constitutes a game, we can look deeper into what Costikyan has written about computer games

(Costikyan, 2006, p. 196‐202) who writes that games involve decision making. Players have to be

motivated to take part in a series of actions in order to reach a greater goal. In order to promote

decision making, games have to have a set of goals. There must be goals for players whether explicitly

described or self motivated. Games must also involve opposition for players, from other players, the

system, or both. Players also need to be allowed to manage some sort of resource; these resources can

come in the form of tokens that are visual representations of the resources. Players must also have

information, that indicates to players their progress or state in the game, which entails the management

of resources and players

Looking at Avedon and Sutton‐Smith as well as Costikyan’s definitions, it becomes apparent that there

are two basic levels at which a game must be analysed. The first component can be referred to as the


21

powers, referring to the player or the system. Costikyan refers more directly to one end of the power

being the players. The player’s role within the system with regards to the level of interaction a player

has within a system, in terms of interaction between players, and between players and the system. This

will reveal the kinds of resources that players encounter, if they are allowed to create resources of their

own, or if they are only allowed to manipulate resources as encountered within the system. This

management of resources then dictates the kind of information that players will have available to them,

as well as the kinds of decisions to be made (Costikyan, 2006, p. 196‐202).

The player’s role and affordances in a location based game has the potential become of greater focus as

technologies used in pervasive games mature. No longer satisfied with merely playing the game, players

want to be able to create custom content and form communities (Radenkovic, 2005, p. 12). This

component of the taxonomy will entail a description of the nature and level of decision making

(interactivity) that players are faced with within a game system, essentially determining the how much

interactivity and separating it into a series of identifiable nodes. There have been many debates as to

how to go about such an undertaking, due to the dubious and general nature of the use of the term

“games” (Ekelinen, 2003, p. 195) (games as drama, game books etc.).

There has been an ongoing dispute with regards to how games should be studied, with some scholars

attempting a colonization of the field of serious gaming by studying games with approaches akin to

those usually used in the study of cinema or literature (Frasca, 2003a), and others recognizing that while

there are some similarities between games and traditional forms of narrative, the dissimilitude is

sufficient enough to warrant the creation of new schools of thought with regards to games (Juul, 2005, p.

225).

It is from this debate that ergodic theory was created by Aarseth in an attempt to carve out a theory for

games as an entity evolved from current literary theory (Aarseth, 1997, p. 17). Aarseth describes ergodic

theory as a means by which to describe “a type of discourse whose signs emerge as a path produced by

a non‐trivial element of work…produced by some kind of cybernetic system, i.e., a machine (or a human)

that operates on an information feedback loop” (Aarseth, 1999, p. 32‐33). This could take on any

number of forms, from the ancient I‐Ching, to any number of “multicursal” or ”multilinear” (Aarseth,

1997, p. 44) works we see today.

In his Typology of Textual Communication (Aarseth, 1997, p. 58), which was designed for the

deconstruction and categorization of ergodic literature, Aarseth states that narrative in an ergodic text is


22

made up of smaller units, namely textons and scriptons. Textons are the basic unit of which these

narratives are made up. They are the “strings as they exist in the text” (Aarseth, 1997, p. 62), which

when woven together or rearranged to form scriptons, from which users (or players in this case) may

draw meaning from the work. As with most other forms of meaning it is generated from context, or the

medium that is used to transmit the scripton. It is from these 2 basic units that Aarseth creates a

textonomy (typology of the text) that allows the deconstruction of how interaction can take place within

an ergodic work such as a computer game. And it is this taxonomy that will be used to analyse the

player’s role in the system.

The second component which will be looked at is the rules, which effectively dictate how the players

operate within the system. Rules are essential in defining and describing a game (Avedon, 1971, p. 167‐

178), and it is what essentially makes up the play element of games(Huizinga, 1955, p. 11). Rules are also

the bounds that the system places on players which define the goals as discussed by Costikyan. By

shaping the decisions that players make, creating opposition between players and tension between the

player and the system, two categories of play are created: paidia and ludus.

Caillois described the difference between paidia and ludus by categorizing paidia as a free state of play,

characterized by its “impromptu and unruly” (Caillois, 1958, p. 28) nature and ludus as a progression of

paidia, where play becomes more refined and disciplined, with clearly defined rules (Caillois, 1958, p.

28‐29). In more recent years, Frasca attempts to create a dialectical approach to the categorization of

games as either paidia or ludus. Frasca differentiates paidia and ludus by stating that in the latter, the

rules lead to a definite win/lose state, whereas paidia is a more open form of play free of such an end

state (Frasca, 2003b, p. 30). These of course are just very basic examples to elaborate on how important

rules are in the context of framing a game, and how they can define the game, but to go any further into

this however, would mean going off tangent.

Rules are important because among other things they foster interaction between players. Games always

involve some form of competition, even if they are cooperative. Huizinga (Huizinga, 1955, p. 47)

observes that the term “playing together” is “antithetical”, because even when engaging in play with

another party there always will be a form of “conflict”, and this is especially so when the game requires

“application, knowledge, skill, courage and strength”, because at the end of the day playing a game is

about winning. Needless to say, conflict between the player and the system will always be present, but

Designing

it would a

of compet

A third co

is an offsp

would be

discussed

future of

research w

system de

manifesta

Rollings a

games (Ro

summary

some way

framewor

other.

Rebuildin

a Web Based I

also be reason

tition.

omponent not

pring of the u

like playing M

. Rollings and

computing ha

will have to b

esign will be a

ation of the ga

nd Adams als

ollings, 2003,

of the large m

y playing a co

rk for the taxo

g that diagram

nterface to En

nable to say t

t mentioned

biquitous com

Monopoly wit

d Adams write

ardware” (Ro

be focused on

about looking

ame.

so provide a d

p. 9) (see dia

many conside

omplementary

onomy’s stru

Diagram 4

m to better s

courage the Cr

that even at a

in the definit

mputer. How

thout a Mono

e that the “fu

ollings, 2003,

n the effects o

g into how ha

diagrammatic

agram 4.1 on

erations requ

y role to the o

cture, illustra

.1: Ryan and Adam

uit the needs

reation of Mob

a cooperative

ion is mediat

then can we

opoly set. The

uture of intera

p. 533), and a

of hardware o

rdware and s

c view of the f

the following

ired in game

other. This m

ating the relat

m’s factors in comp

s of this taxon

bile Phone Bas

e level, player

ion. Pervasive

neglect the v

erefore it is im

active enterta

as we move t

on interactivit

software are p

factors involv

g page). They

design, with

odel can be u

tionships that

puter game design

nomy, it woul

ed Location Ba

s will also hav

e gaming, as

very medium

mperative tha

ainment is clo

owards this f

ty. For the tax

put together

ved in designi

describe the

each of the c

updated to se

t the compon

n

d look like di

ased Games

ve varying lev

discussed ear

of the game?

at the system

osely tied to t

future further

xonomy how

to form the

ing computer

e diagram as a

components i

erve as a basic

nents have to

agram 4.2 be

23

vels

rlier

? It

be

the

r

ever,

r

a

n

c

each

elow.

Designing

This taxon

of its thre

rather tha

directly is

roles) as w

from the

drawing in

the inner

broader p

parts unti

game”, w

in Append

a Web Based I

nomy looks at

ee stated sect

an the game c

the “Core M

well “Interact

Rollings and A

nformation fr

circle represe

perspective, a

il the pertinen

ith each part

dix A.

nterface to En

Diagram 4.2: R

t games from

tions, it analys

centric appro

echanics” (ru

tivity” portion

Adams mode

rom the curre

ents a part of

as seen from t

nt issues arise

playing an eq

courage the Cr

Redefined taxonom

m a different p

ses the conte

oach as seen i

ules of play, p

n by way of th

l in that while

ent untamed

f the taxonom

the circumfer

e that can be

qually import

reation of Mob

my for analysing g

perspective in

ents of games

n the previou

player roles), “

he study of ap

e if focuses o

(nascent) sta

my that will be

rence of each

acknowledge

tant role in its

bile Phone Bas

games.

n that while it

s from a more

us model. Wh

“Storytelling a

pplied hardwa

n the creatio

ate of location

e applied to t

h third, distilli

ed and assimi

s design. Deta

ed Location Ba

t acknowledg

e player centr

hat the taxono

and Narrative

are. Another

n of a game,

n based game

the existing ga

ng and narro

ilated into th

ails of the ana

ased Games

es the import

ric perspectiv

omy will addr

e” (also playe

way it differs

it does so by

es. Each third

ames. From a

wing down th

e centre as “m

alysis can be s

24

tance

ve

ress

er

s

of

a

he

my

seen


25

4.3 Derived Concept Location based games, while having the potential to be very powerful social connectors that aspire to

allow people to subvert spaces by “blurring the boundary between the fictional world of a performance

and the real world of everyday events” (Benford, 2005a) are still afflicted by two key issues that can be

derived from the results of the analysis. The first being technological determination, or the limitation of

deployment of games to a privileged few locations, and the next being a lack of persistence, which can

be said to stem from technological determination as well.

While the games are constituted similarly so that they are playable and engaging, the main difference

between them is hardware and deployment. The crux of the matter is that technology is limiting the

locations, and duration of deployment and thus the potential for participation and social interaction.

This is reflected in system issues (see Appendix A), where in order to be playable, all the games require

the early deployment of equipment and the creation of a specific set of software tools for that

deployment. This is especially glaring in the case of CYSMN, and Human Pacman that require the use of

extremely specialized hardware which would be out of the reach of the average person, and are thus

restricted to design and deployment by people with a specialized set of skills. Even with increasingly

common equipment like GPS units, there are still issues with location such as cloud cover or obstruction

(Benford, 2005b, p. 11), as well as having to purchase a dedicated piece of hardware if one does not

already own a GPS unit.

The specialized deployment of equipment also means that for prolonged deployment there will have to

be maintenance, which limits the duration that games can run for. This means that in games like CYSMN,

Human Pacman and even Conqwest which run for a short duration of time, the interaction between

players during the game is often constricted either due to time limitations for the game or for

deployment.

A game like Conqwest circumvents many of these issues by using mobile phones as the main tool for

participation. Mobile phones are increasingly ubiquitous on a global level, and therefore do not require

special set up in order to function within a network. The phone also enables a game to fulfil many of the

requirements for a ubiquitous system without the need for additional equipment. However, even in

Conqwest there is the use of Semacode, which requires players to download specialized software on to


26

their phone, along with the developers having to physically apply the Semacode tags to the game’s

environment. FIASCO on the other hand goes for a far less technical method of deployment, requiring

users to go on location and take photos as proof of participation. This of course ties the player to

location, but then the location then becomes a backdrop, rather than the focus of the participation.

While many developers attempt to use cutting edge hardware like in CYSMN and Human Pacman, some

others try to make use of more readily available technology like digital cameras in FIASCO, GPS in

GeoCaching or Semacode software installed on mobiles in Conqwest. Even with the latter three, there

are issues pertaining to the technology employed. FIASO as discussed earlier does not really link location

to technology as much, GPS technology has its share of limitations in terms of coverage and monetary

cost in investing in a GPS unit, and the use of Semacode while ingenious requires users to install

software on their mobile phones, which presents issues of coding for multiple models of phone, the

comfort level for potential users with installing software and of course legal issues from the placing of

markers.

Technology wise, mobile phones clearly have an advantage over other technologies in terms of coverage

because of the low cost of infrastructure deployment (Levinson, 2004, p. 126) as well as with the sheer

number of users resulting in mobile services “bursting at the seams everywhere in the world” (Levinson,

2004, p. 129) which really is the key for increasing the coverage of location based games on a global

scale.

Another key aspect of mobile phones is that they now come with a standard SMS function which can be

leveraged for the dissemination of content, and the ever increasing computing power of the mobile

phone means that building an application that uses the mobile phone will allow for greater extensibility,

allowing for the growth of the application to make use of more the mobile’s more dynamic functions

such as WiFi or GPRS capabilities allowing users to access as well as create more diverse forms of media,

particularly rich media (Musser, 2007, p. 39).


27

4.4 Positioning Cipher Cities There is a need to create a system that will enable the creation and deployment of location based games

over areas with basic mobile connectivity thus empowering individuals who are not in a geographically

viable position to participate and build their own games thus increasing the possibilities for social

interaction.


28

5. Design Considerations The first consideration is that location based games are inevitably tied to location. Cipher Cities allows

the creation of location based games; therefore it would be possible to design and release the tool, but

the question was how to encourage or even catalyse the creation of such games? We had to find a way

to mobilize the masses, and as an interaction designer, and a user of web applications such as Flickr

(Flickr, 2006) and YouTube (YouTube, 2006), I was in a position to provide an answer: Web 2.0.

5.1 Web 2.0 The recent move towards user created content was christened Web 2.0 and is essentially what has been

referred to as the rebirth of the internet after the dot com crash of 2001. Web 2.0 can be seen as the

natural evolution in the convergence between traditional, and new media as broadband internet access

increases and hardware prices become more readily available, resulting in shifting consumer trends

(Jaokar, 2006, p.19‐32). Web 2.0 has transformed the way people have used the internet, from passive

to active consumers. It has empowered the masses, subscribing to the wisdom of many instead of the

privileged few, and allowed the man on the street to contribute to the news as much as the largest

broadcaster, which is evident in the proliferation of blogs reporting on the war (Hesseldahl, 2003). This

new shift in content production and consumption has even prompted Time magazine to name “You”

person of the year for 2006 (Grossman, 2006).

Despite all the hype surrounding Web 2.0, there is still often uncertainty as to what it refers to and what

it entails. An article by Tim O’Reilly, who first came up with the term gives us seven principles that

defines what a Web 2.0 service really is (O'Reilly, 2005). They are:

1. The Web as a Platform

2. Harnessing Collective Intelligence

3. Data is the Next Intel Inside

4. End of the Software Release cycle

5. Lightweight Programming Models

6. Software Above the Level of a Single Device

7. Rich User Experiences


29

The Web as a Platform

Citing several key differences between the Netscape browser and Google, O’Reilly talks about how a

Web 2.0 application is native to the web, rather than desktop bound, allowing users to gain access not

only to always the latest versions, but also to always have a link to a database (O'Reilly, 2005). It

therefore becomes a service rather than just an application, because a browser without access to

content essentially has no value.

Another advantage of using the web as an application platform is also that because of accessibility, it is

geared for potential use by a large number of users including those of niche markets, “harnessing a large

number of casual users who contribute data implicitly rather than a small number who contribute

explicitly” (Jaokar, 2006, p. 36).

Harnessing Collective Intelligence

This refers to how sites like eBay, Flickr and most notably Wikipedia grow out of content created by

users to add value to their sites through “peer production, the wisdom of crowds and the network effect”

(Jaokar, 2006, p. 37‐38). Peer production has been described as “armies of amateurs, happy to work for

free”, who build content for today’s most successful Web companies. This army makes use of the tools

provided in the Web 2.0 model to form “a distributed labour force of unprecedented scale” (Anderson,

2006). This tapping into the wisdom of crowds ensures the quality of content that is produced. The

network effects from user contributions acts as a system of distribution as well as a filter to allowing the

body of knowledge to be suitably enriched.

Data is the Next Intel Inside

At the heart of every Web 2.0 application is the combination of function and data. It is the presentation

of data that is the crucial element, because the system less the data would be an empty shell. Having

said that, the data presented does not even have to belong to the company that is presenting it, like in

the case of Google maps, who use the satellite images but don’t own them. What the company can own,

however is annotated data such as comments, which is an essential point of difference when dealing

with data (as in the case of Google maps) that is not proprietary. “Core data” such as “location, identity,

calendaring of public events, product identifiers and namespaces” are also important, because it is this

aggregated data that can be turned into a system service.

End of the Software Release Cycle


30

Many Web 2.0 applications are in a constant state of “Beta” release, because improvements are

constantly being made. There is no stipulated “end” state that the system should have, but rather a

constant updating to cater to user’s needs. O’Reilly even goes so far as to say that “Users must be

treated as co‐developers” Because the applications are web based, updating will not require users to

undertake any special steps to keep up, with Flickr deploying new builds “up to every half hour” (Coates,

2005).

Lightweight Programming Models

Because of the sheer amount of data to be dealt with, both in complexity of the application and of the

data it is presenting, Web 2.0 applications should act to syndicate data instead of orchestrate it. This

means that applications should be designed to access and present data only when required. AJAX is a

common option for this, because of its ability to retrieve and display only relevant bits on information

on the page. O’Reilly also talks about designing for “hackability” and remixability, which is something

that Google Maps and Flickr have done successfully with their APIs.

Software Above the Level of a Single Device

This simply refers to extending the functionality of the system on to other devices such as mobile

phones, enabling those devices to access data hosted on a database. This opens up the potential for

using devices as source of rich media that can be created on location (Musser, 2007, p. 39).

Rich User Experiences

Gmail, Google Maps and Google’s online spreadsheet are examples of how the functionality of desktop

application GUIs, such as manipulating data by dragging and almost instantaneous updating has been

made available online. All this is made possible through the application of AJAX technologies, which will

be discussed in further detail later on.

Looking at the seven principles, it is clear that the Web 2.0 model is especially relevant to Cipher Cities

for several reasons:

1. Cipher Cities requires localized, user created content

Because location based games are tethered to location, content has to be created specifically

for each location where games will be played. Due to the spread of the internet, it will not be


31

possible for us to create such a vast amount of content over so many geographical locations. We

therefore require users to take up the mantle of content creator. This is especially important

since the creative/consumption balance is driven by supply rather than demand (Jaokar, 2006,

p.68).

2. Cipher Cities is all about distribution of data over different devices

The content created online by users will eventually be accessed by members using mobile

phones.

3. Cipher Cities requires an aggregator for content creation

The fulfilment of a content creator’s needs for self actualization in community driven collective

intelligence will serve as motivation for the content drive (Jaokar, 2006, p. 71).


32

5.2 Community Building The design of a community site is a holistic endeavour that spans across a variety of disciplines. A site

has to be visually appealing to spark an initial interest, it has to be sufficiently easy to use in order to

encourage return visits, and then there is the issue of how fresh content will be made available to users.

While all of them appear to be separate entities, they are really tied together by interaction design,

which has to balance the sublime of the aesthetic with the principles of usability and the study of how a

user might interact with a given system. This is especially so, because Cipher Cities as a community and

location based gaming site has to be designed to have mass appeal, rather than only to a niche audience.

The idea is to get location based gaming “out there”, and available to the standard internet user on a

worldwide scale, rather than leaving it in the confines of academia, or to areas that are more

“technologically advanced”.

Given that location based games are about making virtual connections on a physical plane, the Cipher

Cities game engine is an ideal system for community building, because even with online communities,

there is an increasing need for face‐to‐face meetings to take place in order to create trusting

relationships (Blanchard and Markus, 2002, p. 7).

It has also been observed, that many sites that offer “ready made” content for user consumption often

found themselves unable to make money, rather the internet is more a source of affiliation, where web

tools enable or enhance social connections, rather than just serve as a source of information (Joinson,

2003, p. 186). This is increasingly the case, which can be seen with the explosion of sites like MySpace,

Flickr, Digg and the like, that allow users access to tools for social networking as well as content creation,

which is now being seen as being part of the new channel of mass communications (Hummel and

Lechner, 2002, p.1). This of course refers to Web 2.0, as mentioned earlier which involves the user as

the content creator.

To define the Cipher Cities model for community, Mynatt (Mynatt et al., 1997, p. 211) states that, online

communities should fulfil the following technical requirements:

• Technologically mediated

• Persistent


33

• Capability for real‐time interaction (In a forum style interface, this could mean that users can

refresh and get new updates.)

• Multi user (This is a given.)

• Allow for representation of identities through use of icons, or with signatures. This point is also

confirmed by Blanchard (Blanchard and Markus, 2002, p.7)

As developers, there is the need for us to also address the fact that a virtual community differs from a

virtual “settlement”, where a “sense of community” is defined as being a sense that participation in an

online group is affective, rather than in a settlement where in a “virtual settlement”, interaction

between members lack that sense of an affective bond, for example helping each other out (Blanchard

and Markus, 2002, p. 2). The sense of community exists over four dimensions:

1. Feelings of membership: This arises from feeling of “belonging”, or identification. This can be

addressed by allowing diverse formation of groups so that there is “a group for ever user”.

2. Feelings of influence: Being able to have a say in the group or by helping other users.

3. Integration and fulfilment of needs: Comes from having shared values and meeting other’s

needs while at the same time meeting one’s own needs.

4. Shared emotional connection: Created by frequent, high quality interaction between users.

Some of these points can be seen as directly derived from Maslow’s hierarchy of needs, which dictate

that people are motivated to fulfil their needs that exist in an order akin to a pyramid (as seen in

diagram 5.1), in which lower needs have to be satisfied in order to move on to higher needs. (Kim, 2000,

p. 8‐9).

Diagram 5.1: Maslow’s hierarchy of needs


34

The lower levels such as physiological factors pertain to being able to participate, and maintain an

identity. This has been addressed in base level system planning, which has resulted in the current

version of Cipher Cities. Security and safety refer to how their information is stored and protected, and

how the system is designed in order to allow players to participate safely. The other three factors: social,

self‐esteem/ego and self actualization are the issues that this document will address, using as a

reference the 4 dimensions of sense of community. Social needs can be addressed by a combination of

all 4 dimensions, particularly having feelings of membership, self‐esteem/ego and self actualization

needs by allowing users to have a feeling of influence, integration and creating shared emotional

connections between users.


35

5.3 Technological Mediation

Needless to say, an online community is one that is technologically mediated. This is especially so in a

system like that of Cipher Cities, because it makes use of a variety of platforms to meet this expectation.

There is also the question of the most suitable platform to choose in order to be able to best cater to

user’s needs and expectations with regards to the present state of the internet, or in comparison with

services that are currently available to them. Again, these factors are intertwined, and although not

exactly the same thing, both affect each other.

The Cipher Cities interfaces were initially developed with Flash. There was the intention to continue

working with Flash in order to minimize the amount of translation required for the system to be

operational, as well as the fact that using Flash would circumvent any cross platform compatibility issues

that often plague HTML development. In fact, the administrative interfaces are still Flash based. The

advantage of Flash is also that it supports the creation of attractive transitions with minimal effort, thus

creating the possibility for greater feedback to the user, increased interactivity (draggable menus etc.),

as well as creating a more visual experience for the user. Additionally, with Flash being primarily vector

based software, it also meant that display sizes would not be so much of an issue because vector images

can be easily resized without detracting from the quality of the graphics.

Also, sites like fotologue (Fotologue) as seen in diagram 5.2, an online photo sharing website has

demonstrated the possibilities for the use of Flash in building systems that display vast amounts of

content. Flash works well in the display of information in such a manner because it allows for only

selected content to be refreshed in reaction to a user’s interaction, therefore minimizing the amount of

repeat downloading of similar content, such as the navigation bars and certain elements that are

uniform from page to page.


36

Diagram 5.2: The Fotologue interface, constructed entirely in Flash

With Flash, however also come with plug‐in compatibility and usability issues. With compatibility, it is

that if the site is built with the latest, most stable release of Flash, then users will find themselves having

to upgrade their Flash players, which may prove daunting for less experienced users. This is also coupled

with the deficiencies that come with navigating a Flash site, such as the inability to use the back button,

as well as the option to choose to open up links in new windows, both of which are methods of

navigation that are employed by users in order to expedite the navigation of websites, especially if the

sites are thick with information.

The other possibility was to build the site with a HTML base. By employing AJAX, it would be possible to

recreate the interactivity of Flash, as well as create “behind the scenes” retrieval of information

available in Flash without having to hassle the user with plug‐ins, at the same time allowing users to

continue the use of conventional approaches to navigation, creating a richer online experience as

employed in Flickr (diagram 5.3) (Flickr, 2006) and Gmail. The lightweight nature of the language also

means that updates can be frequent, and specific, rather than with Flash that will require a compilation

of entire portions of the system. This enhances the immediacy that users will be able to access the

updates.


37

Diagram 5.3: Flickr, built on an AJAX framework is also capable of such complex interactions

As mentioned previously, the issue with operating over a variety of platforms, especially with regards to

HTML content is the sheer diversity of configurations that have to be catered to, with configurations not

necessarily displaying content the way it was designed. This creates issues not only at a user level, but

also at a development level, because of the sheer amount of content that has to be managed. Thus the

question of how we are to create a site that can be easily updated in terms of layout, graphics, as well as

be cross platform compatible arises.

At the user level, the web interface is been designed to be able to operate on a diverse set of displays,

starting from 1024 x 768, and will eventually be validated and tested across various systems. This will

ensure compatibility across systems and browsers so that potential users are not left stranded due to a

lack of suitable hardware. The use of CSS ensures that the site’s appearance can be updated with

minimum hassle, and can be built to address accessibility issues such as font size and colour.

At the game participant level, players are also allowed to participate with just minimum hardware

requirements to fulfil. The use of the now ubiquitous short message system as a delivery platform

means that just about any user with a standard mobile phone will be able to receive and send messages,


38

thus enabling them to participate. The system itself is flexible, in that it does not cause too many

constraints (Friedl, 2003, p. 213). Any additional technology that may be involved is optional and will be

up to up to the game builders, who will specify any additional requirements, but the bottom line is that

users will not be required by Cipher Cities to acquire additional hardware in order to participate in

games that are created solely using the Cipher Cities system. Additionally, using the mobile phone as a

base platform allows us as developers to “future proof” the system by slowly introducing more complex

mobile phone based applications making use of the mobile phone’s increasing technological capabilities

as the user base grows.


39

5.4 Persistence & Capability for Real Time Interaction Both of these points have been grouped together, because persistence and real time interaction are

closely linked in that persistence relies on the user’s ability to be able to return at any time to interact

with both the system and other users, and real time interaction, which in this case deals with how the

system deals with user input.

In the case of Cipher Cities, a persistent state is supported on two levels: user interactions, which is how

users interact with each other, and at a game interaction level, which is how a user is allowed to interact

with the system during a game. These issues are first and foremost addressed with the facilitation of

content creation and distribution, which encourages the propagation of communities by way of forming

discussion around participation in, or creation of games.

Community “germination” in Cipher Cities by way of building discussion around content is supported by

Sangwan (Sangwan, 2005, p. 2), who talks of users congregating around “common needs and interests”,

and Andrews who opens his article with a similar observation about users wanting to meet users with

common interests (Andrews, 2002, p. 64), but also goes on to talk about the advantage of “interwoven

content and discussion” that allows users to create discussion around content without having to enter a

specified notice board. There is then the need to select the most efficient way to facilitate discussion

between users.

First the decision must be made whether or not groups should be the sole creation of users, developers,

or a combination of both. There are essentially three approaches to group creation: top down

(developer created), bottom up (member created) and a hybrid (Kim, 2000, p. 316). Top down groups

are more focused and can be branded more easily, because after all, they are created by the

development team and centre around specified content. Bottom up groups act as aggregators,

promoting the growth of communities and hybrids are a combination of both. As you shall soon see,

Cipher Cities employs the hybrid method, giving users a greater sense of ownership over the groups that

they themselves have created, while maintaining groups that are available to support users. As seen in

diagram 5.4, Flickr (Flickr, 2006) has also employed such a method of community creation, allowing

users to create their own groups, while maintaining some areas for users to talk directly to staff.


40

Diagram 5.4: Flickr has a set of official groups created by admin staff alongside others that users can create.

In the case of groups, especially when spread over a wide geographical area, or even in such cases as

games that run for an indefinite duration, there is a distinct advantage of facilitating discussions

asynchronously through use of message boards rather than synchronously via real time chat. Amy Jo

Kim in Community Building on the Web (Kim, 2000, p. 34‐36) provides the following reasons to use a

message board:

• They provide “a sense of place”

• Provide visible context, because it would allow users to return to discussions at any time, which

circumvents differences in time, and personal schedules (Churchill and Bly, 2000, p. 7).


41

• Encourage sub groups and branching. Message boards are also scalable in that they allow the

creation of new persistent threads, and maybe even promote creation of new groups. (Hummel

and Lechner, 2002, p. 9)

• Introduce images. Allowing images to be used creates a more emotionally involved area because

people can post their pictures or images with which to express themselves.

• Record of the community’s evolving history (the boards serve as an archive of contact between

members)

Cipher Cities is being built to be run at a global level and designed to be accessible to users with just a

moderate amount of experience, and a regular mobile phone means that there is the potential for

games to be spread across a wide area geographically. As such, there is an expressed need for games to

be classified first and foremost geographically, so that users will be able to locate games that are of

reasonable geographical proximity so that they will be able to participate. There will already be a built in

“game location” reference in each game, but users will also be able to submit their games to a set of

groups that will allow users to locate games not only by geographical location, but by geographical

location, as well as the type of game that is of interest to them, or of a specified type.

Cipher Cities takes reference from sites like Flickr and Last.fm (Diagram 5.5) (Last.fm, 2007) in allowing

users to create their own groups, as well as facilitating user discussions at a group level by providing

users with rich tools for creation and participation in discussion threads (Kim, 2000, p. 317). By allowing

users to congregate on common ground it then promotes communications between users, and the

forming of relationships.


42

Diagram 5.5: A Last.fm group has functions that allow users to discuss pertinent issues with regards to the group.

Beyond the building of regular communities, users are also allowed to create discussions around

individual games by way of the “post card”. Each game has a post card that is created the moment the

game begins, which allows users to engage in discussion within the bounds of that game’s page, or

rather an interweaving of content and discussion within a page as mentioned earlier. Users will also be

encouraged to upload an image of the game upon completion. The use of images and the provision of

facilities for discussion will hopefully create an atmosphere that encourages users to engage each other

in discussion.

With that, there is the need to address the issue of game creation, which is to say the generation of

content that communities can be built around. Obviously there can be no community without content,

and because the site’s draw will first and foremost be the location based games, as developers it is our

intention to then create communities around these games, and as such there was a “chicken or the egg”

dilemma; whether to design the community elements first, or the game elements first as will be

discussed later on.


43

5.5 Allowing Representation of Identities Allowing users to project their personalities on to their avatars, and having a sufficient number of

communities to choose from, a user can become active participants (Friedl, 2003, p. 215). The potential

for community creation has already been created, therefore extending user identity is important in

community sites because clearly it gives a user the sense that the character is a reflection of self, albeit a

virtual one, which then affects the quality of communication (Chan et al., 2004, p. 5).

Between users, this sense of identity extends to how they are able to identify with each other, by way of

interests, or location. In interpersonal communication, it creates greater familiarity between users

(Hummel and Lechner, 2002, p. 6), especially over an extended period of communication, or when

posting on forums. This feeling of being able to recognize another user by way of their virtual identity is

also very important in being able to create a sense of virtual community (Blanchard and Markus, 2002, p.

5).

Cipher Citizens will be allowed to customize their identities with the following details:

• Country

• City: Updated when the country is selected, the city is a more accurate description of the user’s

location.

• Age

• Gender

• Avatar: A user picture that will represent the user. This will serve as a representation of the user

in the virtual community. Giving a face to the name, if you will (Bartle, 2004, p. 155).

• A Little About Yourself: The user will be allowed to enter personal details into the text box to

create more personality.

• Forum Signature: This is the text at the end of every post left in a forum. These give a

personality to the poster (Blanchard and Markus, 2002, p. 7)

Additionally, there will also be a rating system similar to that of eBay, the difference being that there will

be 2 different rating systems per user. The first is a player score system, which is a scoring system for

the individual user that allows a user to keep track of personal progress, and is an accumulation of


44

scores from completed games. The other system keeps track of a player’s developer rating, which is

basically an aggregation of ratings that a user receives for games developed.

These scores will serve not only as a source of pride, but because the top 10 players and developers will

then be displayed on every user’s home page, it is also as a source of competition fuel that encourages

users to compete for higher scores, encouraging increased user participation as both player and as

developer (Chan et al., 2004, p. 2). A distinct advantage of having a developer rating is that it will also

serve as a reward to developers for building good content (Surnam, 2001, p. 136‐138) as well as form of

user level quality control, which is important for the propagation of online communities (Leimeister et

al., 2004, p. 7). With the rating system, developers will want to maintain a certain standard for content

created, or they will not be seriously regarded as developers.


45

5.6 Content Creation It is clear that in order to follow the Web 2.0 model discussed previously, Cipher Cities will have to

facilitate the creation and sharing of content at a community level in order to encourage the creation of

content. To motive users to create usable content, it will be necessary to cater to their needs for self

satisfaction and “ego boost” which come from creating good content and receiving recognition for it as

described in the previous section, since most content creators want to build a reputation and have the

prestige of being recognized for doing good work (Surnam, 2001, p. 131‐132). This act of self

actualization is what motivates content creators to create content (Jaokar, 2006, p. 72).

Standing with content creators are the communities that benefit from content. A community in Cipher

Cities would only be able to maintain its perceived value by ensuring a flow of content that will serve to

reinforce interest (Utvich, 2004, p. 246). This constant flow of content would also act as a hook to bring

in new members, especially since the more content there is, there greater the possibility for

“personalized results” to be available. This is especially so since in the case location is a very specific and

personal thing. Diagram 5.6 illustrates this cycle of content creation and the greater community, which

is no longer a chain, where content is created from a central source and fed to the body, but rather the

body acts as a system to generate content which it then consumes (Jaokar, 2006, p. 76).

Diagram 5.6: Content creation cycle.


46

Allowing members to build games and contribute the game to groups also gives a context to the act of

creation (social networking/content sharing), which when coupled with a personalized online identity

and a system for building reputation serves not only to invite creation and participation (Musser, 2007, p.

17) by providing engagement, acceptance and most importantly giving recognition to achievers.

Designing for community and for users to be able to fulfil certain innate needs within a wider social

setting as discussed earlier has been described as setting network effects by default (Musser, 2007, p.

16). This technique, like “ego boost” is specifically for user gratification or creating avenues for user

gratification to promote participation and as a result the propagation of content by harnessing the

masses needs by appealing to their desire to pursue matters of self interest and as a result creating a

collective intelligence. An example cited was Napster, which was built on people wanting to download

MP3s, as a result becoming a network of files. Musser provides a diagram (Musser, 2007, p. 17) as seen

in diagram 5.7 to help with the understanding of how context plays a part in content creation.

Diagram 5.7: Musser’s content creation dynamic.

People and Context have all been satisfied by accommodating to user needs by designing for community

creation as discussed in earlier sections, but while we know what kind of data we want from users

(games) and the deployment platform (web, mobile) what remains to be dealt with is how to design a

tool that will operate on the current web platform that allows the creation of data. Reiterating a point

made in the section on Grounded Theory, the main issue with Cipher Cities is that while features of the

site such as community building and content sharing are not new concepts, but rather are designed

taking reference from taxonomies and other sites, the game builder is a first of its kind and therefore

will be built without being able to take reference from distinct frameworks.


47

There is therefore the need for a series of assumptions to be made that can then be applied to the

design process that will inform the design of the interface (Mirel, 2004, p. 67). These implemented

assumptions will then be put through a series of user evaluations for refinement.

Despite the lack of a concrete start point, Surman lists 5 principles (Surnam, 2001, p. 158) that designers

can take into consideration while designing such tools:

1. Balance simplicity, access and power

2. Fit in with the normal daily routine of users

3. Empower users

4. Make it free or cheap

5. Listen constantly to what users are saying

From these 5 principles, we can conclude that the builder should be easy to access without the need for

additional software, and due to the complexity of the final product, it should incorporate error checking

and complex interaction without the usual hassles of the internet such as page reloads. It must be

robust enough to support all the features that a game in the Cipher system is capable of and more, it

should facilitate emergence in terms of allowing for the application of the system to unintended uses

(Musser, 2007, p. 18), and is still easy to use so that new users will be encouraged to build games. This

simplicity will allow a wider body of users to have access to game creation, which in turn means it will be

easier to rope in the long tail to aid in content aggregation. This means that collective intelligence is

harnessed, from which useful content can be derived, such as ratings and comments for games. What

this means is that “noise” will be weeded out, at the same time increasing the value of usable content

(Surnam, 2001, p. 136).


48

5.7 Interaction Design and Usability Issues Once all the functions were decided upon, it was then possible to start on the actual site design. During

the design phase, I first decided on a look and feel, and then moved on to interface design that was split

into two other portions: navigation and content. This order of working allowed me a systematic

approach to layout sort of like building a house.

The look and feel of Cipher Cities is in itself not so much an issue of interaction design, but it does have

an effect on usability especially with colour blind users. Primarily, the site had to look sleek, and like

much of the “Web 2.0” sites now I decided to design the site with a glossy feel to it. The colour scheme

around all this was picked by looking at the word Cipher in the dictionary and uses associative words.

Looking up the Thinkmap Visual Thesaurus (http://www.visualthesaurus.com/), words related to cipher

ranged from “zilch”, or “nothing”, to “secret code” or “encrypt”. It would appear that cipher in the case

of Cipher Cities would denote something secretive or coded rather than “nothing”. It would be going too

far off tangent to talk about the actual processes behind the selection of colours, but rather than

choosing a completely dark theme, it was decided that a brighter sort of scheme would be more suited

to a site where people were supposed to meet, than something dark, which would make the site look

seedy.

The bright greens and combinations of gray, a relatively monochromatic approach to the colour scheme,

serve as colours for technology, some secrecy and give an overall clinical, futurist cleanliness to the site.

The fonts used also serve to extend this feeling. By using fonts that are of a more modernist variety,

which is to say san serif fonts of transitional or geometric fonts, the site takes on a look that separates it

from traditional forms of presentation such as books, and newspapers, which usually employ serif fonts

like Times New Roman. In this case the fonts chosen for the site are Verdana, Trebuchet and Tahoma.

These include for headers and most communication functions of the site, instead of creating custom

graphics for all the headers. Such fonts are more readable on screen (Silver, 2005, p. 202), and the fact

that they are readily available on user’s systems means that consistency across the website can be easily

maintained through the use of CSS (Silver, 2005, p. 40).

In terms of navigation, Cipher Cities employs standard interaction design conventions; including the use

of the main logo as a link that returns the user to the home page, as well as a navigation bar on top of


49

the page and links that have mouse‐over states to indicate to the user that parts of the site are clickable.

The reason for positioning the navigation bar on the top is that it takes up less space on the screen, and

its status is immediately established in the hierarchy as being the main source of navigation. More

importantly, this ensures that the entire navigation bar will be visible above the “fold” of the page, or

above the point from which the page will have to be scrolled (Silver, 2005, p. 199‐201). The bottom line

was that principles of affordance had to be applied: things were designed to appear the way they should

function (Donald, 1998, p. 87).

The links on the navigation bar also change in colour to reflect current section that the user is in,

creating a sort of mapping between the navigation bar and the portion of content being accessed. The

colour of navigation is also designed to cater to colour blind users, avoiding the use of colours that may

cause problems with users who cannot differentiate between certain colours (Silver, 2005, p. 161). Links

within text are also of a colour that is sufficiently different from the text to indicate a link, which is

another nod to the principles of affordance (Donald, 1998, p. 95). Additionally, those links also have

mouse‐over states that will indicate to the user when a link is active.

Because many web users prefer to scan through pages, rather than actually read all the content (Spool,

1999, p. 70), long sentences are kept to a minimum, and content within pages are separated into

columns as far as possible, which shortens sentence, and breaks up information into more well defined

portions, allowing the user to find and digest the information presented on the page (Krug, 2000, p. 36).

Within columns, data is also tabulated in order to group relevant portions of information together. In

order to reduce the amount of unnecessary distraction, rather than using standard tables with defined

lines (Krug, 2000, p. 38), the monochromatic gray colours from the look and feel will be employed in the

separation of content.


50

6. Resulting Creative Work

6.1 Outline of Main Interface Components Research has shown that there is no definite way to ensure that a sense of community can be recreated

online, rather it is a matter of providing tools that will enable the relevant processes to take place that

will forge this sense of community(Blanchard and Markus, 2002, p.7). These points are addressed by

implementing a rich set of tools to facilitate user interaction and identity creation, as will be discussed in

the sections “Persistence & Capability for Real Time Interaction” and “Allowing Representation of

Identities”. Using this as a starting point and reference for the exploration of Cipher Cities’ design as a

system and as an interface will demonstrate how as mentioned before, the design of a system such as

this is requires the use of a variety of skills.

With accordance to Louis Sullivan dictum “Form follows function” as quoted by Marc Silver in Exploring

Interface Design (Silver, 2005, p. 29). The site’s architecture and functions will have an effect on the

content available, and given that a site’s content, navigation and interface should all tie in together to

create as congruous a user experience (Spool, 1999, p. 10), the site’s primary goals were first decided

upon before the interface was designed. It was decided that Cipher Cities would provide users with the

following functions that have a base in the theories of community building and also take into

consideration the principles of web 2.0:

1. personalized profiles, including (promoting participation thus harnessing collective):

a. A custom avatar

b. Basic personal information

c. A player rating system

d. A game developer rating system

2. a way to keep track of personal statistics covering (promoting participation thus

harnessing collective):

a. personal scores

b. joined games


51

c. completed games

d. communities

3. the ability to create games in a “desktop” style wizard with the ability to (harnessing

collective intelligence, data is the next Intel inside, rich user experiences):

a. build a game around a narrative

b. create nodes

c. write clues

d. specify start and finish times

e. specify equipment required

f. send games to certain groups

4. join games (promoting participation thus harnessing collective):

a. at individual or team level

b. and invite friends to games

5. community building tools (harnessing collective intelligence, data is the next Intel

inside):

a. Community creation

b. Community customization

c. Message board system

d. Inter‐member communication services

6. a system that allows users to keep track of completed games that (harnessing

collective):

a. preserves the details of completed games

b. enables players to keep in touch


52

6.2 Initial Main Interface Designs Presented below are the results of incorporating the information gathered from the previous section

into a series of interfaces. The screenshots displayed demonstrate what the interfaces should look like

after it has been used and there is data to populate it. These will be generated dynamically and will

change along with use.

6.2.1 Personalised Profile Page

Intended Impact/Interactions:

a Users will have personalized avatars.

b Users can enter personal details and a short personal description. Other users will also be able to

send private messages via the messaging system.


53

c A list of players that the user has played games displays social connections.

d Games that a user has participated in, or created are displayed so that other users might be able to

make connections.

e A notice board allows other users to leave publicly viewable messages to the user.


54

6.2.2 Group Page


a Groups can have their own custom image identifying the group as well as a description of

the group’s purpose. This serves to bring together like minded individuals.

b A list of members will be on view so that individuals will be able to connect with likeminded

users.

c A forum is available to foster discussion and allow group members to support each other.

d The top 10 players and games foster participation both by players and builders by

highlighting their achievements.


55

6.2.3 Game Viewer Page


a A player that has completed a game will be allowed to vote. This makes up the game’s overall

rating. This serves as a filtering system that highlights better games as well as encourages builders

to create better content.

b There is information displayed about the game including location as well as a description.

c The list of players allows players to connect with each other.

d The snapshots the can be uploaded once a game is completed means that players can share

experiences.

e Notes allow players to communicate publicly to each other as well as the builder.

f The top 10 list encourages player participation, especially in terms of competitive participation.


56

g The slider allows players to easily rate the game.


57

6.2.4 Game Builder Structure

The game builder functions as would a desktop

application, and acts in the form of a wizard so

that it guides players through the process of

building a game. It has been created with the

five principles of online tools as described by

Surnam:

1. Balance simplicity, access and power

2. Fit in with the normal daily routine of

users

3. Empower users

4. Make it free or cheap

5. Listen constantly to what users are

saying

The creation of a game has been designed as a

five step process that requires the creator to fill

in a series of fields. During the process of filling

the fields, users will be assisted by descriptions

that are available on screen at all times.

There is the possibility of the implementation

of a save feature where details are saved in

between steps so as to allow the user to come

back and continue again later on.


58

6.2.5 Game Builder Step 3


a Builders can add checkpoints without reloading the page.

b Node info will automatically be revised as the builder makes changes.

c Builders can rearrange the checkpoints by dragging and dropping.

d Deletion of checkpoints can take place without having to reload the page.

e Builders are informed of remaining characters in each field.

f Clues can be added, and function like checkpoints.

g Clues can also be deleted accordingly.


59

6.2.6 Game Builder Step 4


In functioning like an application the builder has been designed to allow builders to test their games in a

real time system as if they were playing the game. They will be able to go through the game and send as

well as receive responses.


60

7. User Studies and Findings

While some interface issues have been resolved by members of the development team and as a result

corrected, it is inherently difficult to get everything right the first time, especially when designing

complex tools for end users. There is therefore the need to involve users in evaluation so as to ensure

that the tool is built to suit the needs of the end user (Isaacs, 2002, p. 87‐90). There is always the

possibility that many other potentially important issues may have escaped attention, therefore what

remains is to have usability tests conducted on the system.

The tests will involve enlisting potential site users rather than just conducting heuristic testing alone,

because while heuristic testing may turn up some problems, leaving an actual user to find a way around

the site will best allow us to turn out any faults that may have been overlooked (Silver, 2005, p. 284).

Only by conducting the test and analysing the results, it will then be possible to determine if all these

design considerations are truly capable of facilitating the interactions that Cipher Cities has intended.

This section describes the processes and findings of each stage of testing, leaving the results in the

appendices for reference so as not to clutter the picture with too much detail.


61

7.1 Cipher Cities User Testing Stage 1

7.1.1 Executive Summary Cipher Cities has reached a critical point in production where the interface has to be finalized in order

for the mechanics to be augmented. It is at this time that user testing has had to be implemented in

order to uncover the advantages and disadvantages presented by the present interface.

Testing was conducted over 2 days on the 2nd and 3rd of November at the ACID media lab with Eryn

Grant acting as the test monitor, Sherwin Huang as data logger and video operator and Chan Min Wye

serving as the timer.

During the course of the test, 9 participants were involved in helping to evaluate the interface with a

static preliminary version of the interface. Of course, the preliminary nature of the interface meant that

there were some unresolved issues, however these issues did not result in anything major, and as such

would not have affected the outcome drastically.

The main concern of this round of tests was to confirm that the language used was suitable for the

general user, and that the interface was easy to use as well as sufficiently attractive.

Testing resulted in the discovery of several minor issues with regards to the labelling of items, or of

naming conventions used in the interface, all of which will not take much effort to correct.

However, on the whole, users found the site easy to use, and easy to navigate despite the fact that

much of the site is not fully functional, and they were using a fully populated home page as opposed to a

beginner page as proposed for new users. This is a good indication that the site will be able to function

as it was designed to.


62

7.1.2 Problem Statements Site Purpose 1. Is the initial page sufficiently indicative of the site’s purpose?

2. Is the unregistered viewer given enough agency within the site to

understand its purpose?

Registration 1. Is the language used appropriate?

Home Page view 1. Can users identify the purpose of each section on the home page?

2. Are users able to find and update their profile information?

3. Is the purpose of the notice board sufficiently obvious?

4. Can the users manage their notice board?

Message system 1. Are users able to locate their message page?

2. Do users know how to send messages?

3. Can users reply to messages?

Joining a game 1. Are users able to quickly find a game based on location?

2. Once found, can the user identify the various elements of a game

page?

3. Can the user successfully join a game and understand the process?

4. Does the user know how to add notices?

Game creation 1. Can the user complete the initial fields without assistance?

2. Are the terms used sufficiently descriptive?

3. Is the user able to identify the difference between a node and a

clue?

4. Can the user add and remove nodes and clues without difficulty?

Game revision 1. Is the user able to find where to go in order to revise a game?

2. Does the user know how to remove a game?


63

Group Participation 1. Is the user able to find a group?

2. Can the user quickly identify the group’s purpose?

3. Is the user able to identify the various elements in the group screen?

4. Does the user know how to join and leave a group?

5. Is the user able to create a thread in the forum system?

6. Can the user reply to forum discussions?


64

7.1.3 User Profile

Testing will take place over the course of 3‐5 days (depending on availability of the participants) at the

ACID media lab, and will involve between 8 to 10 individuals with varying levels of experience of internet

and paid content for mobile phones (with a minimum of at least some experience of text messaging),

with approximately 3 participants tested per day. The participants will be broken down into the

following categories:

• Two participants will be less experienced with internet use and will constitute the “possible user”

group that is, users that stumble upon the site and may be inclined to participate. These users

need not have any experience with mobile content services.

• Eight participants will have relatively regular contact with the internet, constituting an hour or

more of use daily basis, with more emphasis on time spent actually surfing the internet then

checking emails and instant messaging. This group will be further divided into 2 sub‐groups:

o Four with previous experience with paying for mobile content through text messaging.

o Four without previous experience with mobile content services.


65

7.1.4 Methodology The usability test is designed to gather user opinions on the site and interface in terms of efficacy of use,

and appropriateness of presentation. This will be conducted through discussion with, and engaging the

participant in simulating the performance of a series of tasks on paper prototypes as well as identifying

on screen elements and explaining terminology. These will help to ensure that the elements are

appropriately located, and named, as well as ensuring that there is sufficient functionality to create a

satisfying user experience.

The test will consist of the following sections:

1. Participant greeting and form filling

Participants will be greeted by the test monitor as per the script, and will be seated at the desk. They

will then be presented with the relevant documentation such as the confidentiality agreement form and

a form for their background details. They will also be informed that they will be recorded for reference.

2. Orientation

Participants will receive an introduction as detailed in the script and will be informed of the reason they

are there, and they will be given a brief overview of Cipher Cities, but not giving away its full purpose.

They will also be assured that the product is under evaluation and not them. At this time the computer

will already be ready for the user, but the monitor will be off.

3. Page Evaluation and Exploratory Test

After orientation, the computer monitor will be switched on, and the participant will be shown a

screenshot of the main page that will be displayed to unregistered users. At this point in time,

participants will still not be aware of the purpose of the site. They will then be asked for impressions,

and to give an indication of what function they think the site performs. Failing this, they will receive and

explanation and they will be asked what they felt would give a better indication. They will also be asked

to explain what they feel each section heading means to them. This will confirm if the navigation is

consistent with the content it represents.


66

The exploratory test will involve the users being presented a series of screenshots and then asking them

to perform a series of tasks on each screen, and for certain screens, they will be asked to locate

elements on the screen.

During this time the test monitor will inform the participant of the task which is to be simulated. The

participant will then verbalize the processes and indicate with the aid of the mouse where they would

click in order to perform certain actions.

4. Participant Debriefing

Once the testing has been completed, the participant will be informed of completion by the test monitor,

and will be debriefed. At this time, the participant will fill out a questionnaire with regards to the site’s

appearance and presentation, as well as be asked to give some overall comments about how they felt

about the site, and elaborate on the problems they have had with the site.

Upon completion of all steps, the participants will then be thanked, and remuneration will be presented

to them.


67

7.1.5 Task List Task

No.

Task Description Task Detail

1 Identify the site’s purpose. Req: Index page

SCC: Participant is able to give a rundown of

what the site does.

MTC: 5 min.

2 Go through registration page

and fill in questionnaire.

Req: Cipher Cities registration pages

SCC: Complete questionnaire

MTC: 8 min.

3 Take a look at the home page

and fill in the questionnaire.

Req: Personal home page.


MTC: 8 min.

4 Update your profile Req: Personal home page, info update page

SCC: Participant must be able to locate the

update profile page.

MTC: 2 min.

5 Add notices, remove notices Req: Personal home page

SCC: Participant is able to add notices and

remove notices from notice board.

MTC: 2 min.


68

6 Find the message page, find the

create message page, reply a

message

Req: Personal home page, message list page

SCC: Participant is able to find the message

page, and create as well as reply to

messages.

MTC: 2min.

7 Locate a game Req: Personal home page, game list page,

game view page

SCC: Participant is able to locate a game

MTC: 1 min.

8 Join a game Req: Game view page, game join pages

SCC: Participant is able to join a game.

MTC: 0:30 min.

9 Add notices and upload

snapshots

Req: Game view page

SCC: Participant is able to locate a game

MTC: 1 min.

10 Take a look at the game creation

system and fill in the

questionnaire

Req: Game creation pages


MTC: 8 min.

11 Locate page for revising a

created game

Req: Personal home page, game list page,

game view page

SCC: Participant is able to access the revise


69

game page

MTC: 1 min.

12 Delete a game Req: Personal home page, game list page,

game view page

SCC: Participant is able to delete a game

MTC: 1 min.

13 Locate a group Req: Personal home page, group list page,

group view page

SCC: Participant is able to locate the group

“location based gamers”

MTC: 1 min.

14 Identify group’s purpose Req: Group view page

SCC: Participant is able to identify the purpose

of the group

MTC: 0.5 min.

15 Join the group Req: Group view page

SCC: Participant is able to join the group

MTC: 0.5 min.

16 Add messages to forum Req: Group view page, group message list

SCC: Participant is able to locate the forum

and add a message.


70

MTC: 0.5 min.

17 Reply to discussion Req: Group message list, thread view

SCC: Participant is able to locate a thread and

add a reply to the discussion.

MTC: 0.5 min.

Approximate total time: 45 minutes


71

7.1.6 Test Environment/Equipment

The test will require an environment like a standard home / office computer area, including a desk with

a computer, computer chair and various ornaments with which to decorate the table as well as

distractions such as noise, which can be created by playing music through attached speakers. The room

may be occupied by other non participating personnel as well in order to enhance the realism of

distractions.

The computer involved should have an internet browser installed on which the pages will be displayed.

The pages will be linked together by a simple series of hot spots that will allow the user to maneuver

through them without any actual functionality involved. This will simulate actual navigation through the

site. The PC will be at on state, but will not be switched on until the user is oriented. Following which,

the user will be allowed to power on the monitor and click a link to the page.

7.1.7 Test Monitor Role

The test monitor will be responsible for orientating the participant, and will be responsible for

interacting with the participant in order give the participant tasks as well as to elicit verbal responses

from the participant with regards to the interface and the actions taken.

The test monitor is also responsible for keeping time during the performance of tasks.

In this case, the test monitor will not be responsible for recording, instead a data logger will be

employed to make notes of all actions and any comments made. This will allow the test monitor to fully

concentrate on interacting with the participant. However, because of the test monitor’s proximity to the

participant, notes can be taken of interesting responses or of any facial expressions that might the

participant might display.


72

7.1.8 Findings and Recommendations View Appendix C for detailed results

Task 1 Source of Error Recommendation

Just by looking at this

page, what do you

think Cipher Cities is

about?

Lack of appropriate descriptive material

on the home page to clearly illustrate

the site’s purpose.

The text was sufficient to give participants

and idea of what the site was about, but not

detailed enough to create a conceptual

image.

To add more text would make the page far

too cluttered with reading material.

It would be best to include a descriptive

graphical illustration of how Cipher Cities

works on the front page.


Go to the registration

page.

Now please describe

the terms in your own

words using this

form.

Participants did not quite understand

the concept of “Email” and “Mobile” in

step 2 of registration. This is probably

due to the fact that either they did not

read the description, did not notice the

description, or did not understand what

the description was telling them.

Ideally, the user should be able to complete

registration without having to stress over

what the terms mean. The description is

merely there as an aid.

Replacing the term “Email” and “Mobile” with

something more descriptive, or including a

line of text explicitly detailing the nature of

the field on that page would help the user to

understand better what to enter.

A possible would be “Verification code

received in Email” and Verification code

received on Mobile”.


73


Now go back to the

home page.

Now please fill up this

form describing the

terms you find there

with your own words.

“Game Creator” seen as person who

“defined the concept”, or as the “person

who made the game” instead of being

the tool for creating games.

This should be renamed into something less

confusing. A suitable one would be “Create

Game”

“Play List” and “Creation List” causes

confusion with participants. Some

imagine “Play List” to have association

with music, because it is often used in

music players, and “Creation List” is not

sufficiently firm.

“Play List” should be renamed to “Games

Played” and “Creation List” to “Games Made”

“Groups” had some participants

confused as to their meaning. If they

were their groups, or merely highlighted

groups.

Rename “Groups” “Your Groups”. To create

that connection to the user that the groups

are those they are a member of.


The first would be to

find the page where

you would update

your user profile.

Participants initially had trouble finding

the update profile page. This could be

attributed to 2 factors:

1. They did not really register and

upload a personal avatar;

therefore they were not aware

of what their avatar was.

2. The avatar image on the upper

right hand side that is supposed

to link directly to the profile

page was not completed during

testing.

By final release, the avatar image on the

upper right hand side will be a direct link to

profile update.

There will also be a direct link from the user’s

personal home page.


74


Please take a look at

the game creation

system and fill in the

questionnaire.

Next button is too small and

insufficiently obvious.

Increase size and contrast of the next button.

“X” button is often misread as an

indication to close a node, as opposed to

delete.

Additional descriptions should be added to the

description panel detailing its use.

The final working version of the accordion will

also ensure that there is confirmation before a

node is deleted.

This will prevent any accidental deletion of

information.

Most participants were not sure what a

node is, and consequently the whole

concepts around nodes.

Despite the description, participants were not

able to grasp the concept of “nodes”.

This is most likely because nodes are a foreign

term to them, and have no relation to

navigation as the treasure map suggests.

Using a more meaningful term like

“checkpoint” for the treasure hunt would

reinforce this.


75


Say you have created

a game. Now locate

the page for revising

the game you have

created.

Participants were able to go to the page

of the game they created, however

many of them missed the link to revise

game page.

Increase contrast of the buttons that link to

game revision page.


76

7.2 Cipher Cities User Testing Stage 2

7.2.1 Executive Summary This round of testing sees Cipher Cities being tested not only at an interface level, but at a conceptual

level as well. We wanted to see if participants, even with just a basic level of knowledge would be able

to build games of their own. This was performed in a variety of environments, with varying user

configurations. By doing this, we hoped to discover how well the Cipher Cities interface is able to

introduce the concept of game building to first time builders, and how best to help get these first timers

on their feet and building.

In order to do this, we ran a series of 5 test sessions, each running for an average of 4 hours each, taking

place over a number of weeks. During these tests, participants were asked to create games, and publish

them in Cipher Cities using the interface refined from earlier testing.

During the tests, participants had their processes recorded and broken down into steps, from which we

hope to derive a systematic approach to game building that we will be to use with new builders.

This round of tests proved that many of the interface issues that faced the first version have indeed

been resolved, but uncovered several minor issues such as the presentation of fields, and participants

having to constantly go through the game testing simulator to get to checkpoints.

At a conceptual level, an issue that will have a major effect on the interface is the fact that all the

participants felt that it would be better to build games as part of a group. This is an issue that will have

to be carefully considered, because the current version only allows for individual users to get a builder

score for games built.

Overall, the participants said that they generally enjoyed the process of game building, and some found

that it was a very fulfilling process and one that they would like to undertake on their own in the future.


77

7.2.2 Problem Statements

Conceptualization 5. What kinds of steps do users go through in coming up with a

game?

6. What kinds of issues do users face when creating a game?

7. Given the fields they need to complete (i.e. clues and

checkpoints), as well as the required materials, are users able to

come up with a game of their own easily enough?

8. Are the materials useful?

Game creation 5. Can the user complete the initial fields without assistance?

6. Can the user add and remove nodes and clues without difficulty?

7. Does the interface add to or detract from the experience of

game creation?


78

7.2.3 User Profile Because of the variety of users that Cipher Cities is anticipated to attract, there is no specific age group

that is being targeted.

Tests will be conducted both individually as well as in groups, creating the game in an indoor

environment, with maps and internet access, on location, as well as being left to create a game alone.

These measures are taken so as to determine the effectiveness of designing games in a variety of user

configurations.

Groups will count as one test subject; with at least 5 subjects involved. Subjects (or in the groups at least

one individual) are required to have at least basic experience in internet use. This is merely to ensure

that they are able to at least navigate their way through the interface.

The participants will qualify as long as they meet the following minimum standards.

• Spend at least an average of an hour a day on the internet. Doing either or a combination of the

following:

o Emailing

o Surfing the internet

o Instant messaging

• Have experience participating in an online community.

• Have at least a year of experience in internet use.

The essential element to testing is really how users will be working in groups, or on their own. They

participants will therefore be divided as such:

C1: Group

C2: Individual in room

C3: Individual on location

C4: Individual alone


79

7.2.4 Methodology This round of testing is designed to confirm that issues uncovered during earlier stages of testing have

been rectified. The test will be conducted in a variety of configurations, and as such the methodology

will be broken down to describe each configuration in more detail. The configurations include working

off maps while being observed, on location being observed, and participant being allowed to build a

game independently.

A uniform trait shared by all tests is that users will be briefed about location based gaming, and will be

allowed to look at the website to give them an idea of what they will have to build given the tools. They

will also be provided with copies of a printed template which they can use while creating clues for the

various checkpoints. The test will consist of the following sections:

1. Participant greeting and form filling

The group of participants will be greeted by the test monitor as per the script, and will be seated at a

desk. They will then be presented with the relevant documentation such as the confidentiality

agreement form and a form for their background details. They will also be informed that they will be

recorded for reference.

2. Orientation

Participants will receive an introduction as detailed in the script and will be informed of the reason they

are there, and they will be given a brief overview of Cipher Cities. They will be provided with a builder

pack each containing a map of the designated area where their game will be situated, as well as post‐it

notes, blank paper, and a pencil.

3.1 Paper based game creation and translation

After orientation, the users will be allowed to start planning their game on paper. Once they feel that

their game is sufficiently detailed, they can proceed on to a computer where they will be allowed to put

their game into the game builder, at the same time being monitored by an assistant.


80

For these tests, South Bank has been chosen, because it is a popular leisure area that most residents of

Queensland should have at least some familiarity with. Also, information about the most popular

locations at South Bank can be easily found online, making it less of a hassle to build while at the same

time away from the location.

During the time when they are putting their game into the builder, they will be left on their own to

figure out how to go about it. If the participants should face any difficulties, the test monitor(s) will be

on hand to offer assistance.

Upon completion of the game builder, participants will then be asked to fill up a brief questionnaire that

will seek to confirm that the changes made were appropriate.

3.2 On location game creation

After orientation, the user will be allowed to go to a location of their choice. There they will be followed

by the test monitor who will observe where checkpoints are placed and find out why they were chosen.

The test monitor will also observe how the participant goes about planning the path and how the

checkpoints are arranged.


81

Once the participant is satisfied that there are enough points, they will be given access to a computer

with an internet connection that will then allow the input of data into the Cipher Cities game builder.

During the time when the game is being put into the builder, they will be left on their own to figure out

how to go about it. If the participants should face any difficulties, the test monitor(s) will be on hand to

offer assistance.



3.3 Own time Game Creation

After orientation, the user will be given the templates and allowed to go off to create their own games.

Upon completion, the user will then come back to the test monitor who will then direct them to the

game builder. During this time, the participant will be asked to keep track of their progress for reference

by the test monitor later on.

During the time when the game is being put into the builder, they will be left on their own to figure out

how to go about it. If the participants should face any difficulties, the test monitor(s) will be on hand to

offer assistance.


82

The test monitor will then discuss with the participant their process when creating the game, and any

difficulties that may have been encountered during the creation of the game, as well as any aids that the

participant may have made use of in order to be able to create the game.



4. Participant Debriefing

Once the testing has been completed, all participants will be individually interviewed to confirm any

observations made of their performance if any observations have been made.


83

7.2.5 Task List Paper based game creation and translation

On location game creation

Task

No.


1 Come up with a game that will

guide players from point A to

point B on the map.

Req: Map package.

SCC: Participant is satisfied with the structure

of the game they have created on paper.

MTC: n/a

2 Enter details of planned game

into system.

Req: Cipher Cities “Build a Game” section.

SCC: Participant completes all the steps of the

builder.

MTC: 30 min.

Task

No.


1 Choose a location and come up

with a game that will guide

players from point A to point B

on the map.

Req: Form templates.

SCC: Participant is satisfied with the

checkpoints created and is ready to put

the game into the interface.

MTC: n/a


into system.




84

Own time game creation

builder.

MTC: 30 min.

Task

No.


1 Build a game for Cipher Cities. Req: Form templates.

SCC: Participant is satisfied with the

checkpoints created and is ready to put

the game into the interface.

MTC: n/a


into system.



builder.

MTC: 30 min.


85

7.2.6 Test Environment/Equipment The requirements will vary amongst the various configurations for testing will vary according to the kind

of testing being undertaken.

Paper based game creation and translation The participant (or group) will be overseen by a test monitor, who will be assisted by assistant monitors

who will follow each user throughout the process of game creation, observing them in action.

The test will require a room large enough for the participants as well as their monitors. Ideally, the room

should also have a large table that will allow the materials to be spread out without getting too

cluttered.

A computer should also be available. The computer should have a compatible internet browser installed

(Firefox) on which the pages will be displayed, as well as internet connectivity so that participants can

create and save their games as they would if using the site anywhere else.

Items that participants receive when they start testing will contain:

1. A map of the South Bank area.

2. A pack of large post‐it notes.


86

3. A pack of small post‐it notes.

4. 10 sheets of template printouts.

5. Blank paper.

6. 1 pen and 1 pencil.

On location game creation The participant will be observed by a test monitor who will provide guidance when required, but

otherwise left alone to create the game.

A location will be required, that will be chosen by the participant. When the participant feels that the

game is sufficiently complete, both will move to a location with a computer.

A computer should also be available. The computer should have a compatible internet browser installed

(Firefox) on which the pages will be displayed, as well as internet connectivity so that participants can

create and save their games as they would if using the site anywhere else.

Participants will just receive the template printouts.

Own time game creation

Participants will be required to create a game on their own, so they will just be given instructions to find

a location of their own and proceed to create a game within a week, and when they are ready report to

the test monitor who will provide access to the webpage.

Eventually a computer should also be available. The computer should have a compatible internet

browser installed (Firefox) on which the pages will be displayed, as well as internet connectivity so that

participants can create and save their games as they would if using the site anywhere else.

Participants will just receive the template printouts.


87

7.2.7 Test Monitor Role The test monitor will be responsible for orientating the participant, and will be responsible for

interacting with the participant in order give the participant tasks as well as to elicit verbal responses

from the participant with regards to the interface and the actions taken.

In this case the test monitor is also responsible for keeping time during the performance of tasks. Rather,

this will be taken on by the assistant monitors who will follow participants through the course of testing.

Assistant monitors will also take on the role of data logger and will make notes of all actions and any

comments made.


88

7.2.8 Evaluation Measures The following evaluation measures will be collected and calculated:

1. Number of participants who managed to complete building a game and the number who did not

manage to complete.

2. Steps taken in conceptualization.

3. Use of materials in conceptualization.

4. User comments during conceptualization with regards to the process.

5. User comments with regards to the interface and nature of interaction.

6. Unusual or unexpected responses that the participants have with regards to the interface.

7. Compilation of form results.

8. Error classification:

• Non‐critical errors: Errors a participant makes that can be recovered.

• Critical errors: Participant unable to complete task, or unable to recover from an error made.


89

7.2.9 Findings and Recommendations: Game Builder See Appendix D for detailed results. 1) Descriptions were often overlooked. / Participants unsure if a field will be visible to players.

In this case both the descriptions at the side, and the tool tips were overlooked by most of the

participants. Even if they noticed the descriptions, none of them looked there for help. It would be best

to retain the descriptions as an overview of the page, but make detailed descriptions of the fields

available on mouse click, so that it will be displayed somewhere close to the field when the user wants

to see it. This way, players can also check if a field is visible to players.

2) Builders often overlook the local/global option in step 1.

Because it is just a checkbox, it is easily overlooked because builders are focused on the text boxes. One

participant has suggested moving it to step 2 because it seems to match all the other check boxes. This

is perhaps a good way around the issue.

3) Game simulator in step 4 is not as efficient as it should be because builders have to cycle back and

forth if checkpoints are found to have mistakes during testing.

Allow players to select individual checkpoints and edit them on that page. This will reduce the hassle of

going back and forth.

4) Case sensitivity in answers.

All answers should adopt standardized caps.

5) Some participants expressed that it would be good if players can be told if they are receiving a hint

or a question.

Include a default “hint:” or “clue:” in each field that requires it.

6) Nearly all participants have indicated that they prefer to build a game as part of a group.

Add the option for players to be able to add a number of co‐builders. This should ideally be on the step 1

of the game builder, and will function like the “add team mates” function at “join a game” page. This


90

would mean that the game score would be shared amongst all creators, but there would be larger

implications for the game poster.

Including a team game builder however, would increase the possibilities for interactions between

members and would open up a new set of possible roles and relationships.


91

7.2.10 Findings and Recommendations: Game Conceptualization

See Appendix D for detailed results.

Game creation steps

Studying how the participants created games, it became clear that there are 4 main steps that all of

them had in common:

1) Select a location and come up with a theme

It was found that in most cases a more familiar location will be selected, often pertaining to the builder’s

personal interest. This will allow the builder to come up with a game more easily because it takes

reference from personal experience / local knowledge.

2) Choose checkpoints

This step involves builders picking a list of possible checkpoints to be trimmed down later. Like the

location, builders would select checkpoints based on personal interaction at those places.

3) Set checkpoints

Using the chosen checkpoints, builders will look at each of them in more detail and determine their

suitability. At this point, participants usually make use of the checkpoint printouts to make quick write

ups about the location.

4) Input into Game Builder / refine clues

At this point, builders input the clues they have created into the system. This is also often an

opportunity for them to ensure that their answers meet the character limit, and to check for any

mistakes they may have overlooked earlier.

Main issues

There are a number of issues that builders often face when creating a game. These usually stem from a

lack of experience in planning or participating in such games. Leaving these unaddressed will often mean

that either the game builder will have to go through additional steps, or will render the game unplayable.


92

1) Set a theme

Builders who overlook how they want a game to be played will be faced with difficulties in setting up at

a later time. It is important to determine a theme or the nature of the game while deciding on the

location, preferably before even going to the location because this addresses the issues of what players

will be asked to look out for. This will mean that players either have to look for items that are available

at the location, or clues planted by the builders.

Determining the theme before they actually go out to the location will allow them to think about the

kinds of checkpoints they will look out for, as well as what they will want players to look for, thus

determining the kinds of materials they will require for set up.

Setting a theme will also assist builders in coming up with questions and hints at the location. This

means that the game will be built more efficiently, and players will enjoy smoother gaming experience.

2) Ambiguous questions / hints / answers

Builders should always keep in mind the fact that some things can be referred to with more than one

name, and that things that may be prominent to them may not be prominent to someone else. They

should therefore strive to create answers that while difficult to acquire, will still be findable provided

that players follow the clues and hints.

One way to do this is to think from the player’s perspective rather than only using their own point of

view when trying to come up with answers. Builders should look at their questions and hints try to

imagine if they were playing for the first time if they would be able to find the answer.

Another way around this is to be very specific about what players should find. Some builders have tried

to get players to send in answers like “open ground” or “decommissioned ship in the museum”. While

these may not be incorrect per say, they are too general and especially in the latter, too general while

too specific with terms.

Bearing in mind that the Cipher system only allows for players to send in specific answers, it is best that

answers are kept short.


93

3) Lack of details in instructions / descriptions

Builders should try to be as detailed as possible in instructions and descriptions because that will mean

that players will be able to not only prepare themselves for the game, but also get involved in the theme

of the game if any.

The instructions are especially important because it will work with the hints and questions to build a

complete experience for players.

4) Materials

With participants that created games in a confined environment, they were provided with a list of

equipment that would assist them in the creation of a game. This was because they were removed from

the location.

After building games with participants on location, it was found that the only really important piece of

equipment was the checkpoint templates that they found very useful in building the game on location.

While a map may be helpful, builders who are working in a familiar location often find that there is no

need for a map and work well enough with just the templates.


94

7.3 Cipher Cities Game Builder Workshop

7.3.1 Executive Summary

The workshop makes use of the Cipher Cities game builder interface in order to get a feel for how a

creating location based games might be employed in schools. This also provided an opportunity for

running another series of usability tests on the game builder interface, as well as to see how players

respond to playing games they have created.

The workshop involved 20 students from primary to middle school levels and 8 teachers who came to

attend the workshop at the DESC in Adelaide. The students and teachers grouped according to their

school were given an overview of location based games and tasked to build their own using the game

builder.

They were left on their own to wander the areas around DESC and come up with ideas for their games

and input them into the system. This round of tests surfaced far less issues than the previous few, other

than a technical issue which affected publishing, this round of tests confirms that the builder interface is

almost ready for public release.


95

Notably, we had a group from the school for the vision impaired, including one girl who was completely

blind. While there were initial concerns that they would have trouble participating in the workshop,

their presence created additional challenges for the other groups in creating their games, which made

the process all the more engaging and the games more interesting.


96

7.3.2 Problem Statements

Conceptualization 9. Given a briefing, will students and teachers be able to come up

with a game?

10. Can the created games be completed?

Event creation 8. Can the user complete the fields without assistance?

9. Does the interface add to or detract from the experience of

game creation?


97

7.3.3 Workshop Schedule 0900 – 0930 Orientation

• Introduction to location based events

o Geocaching

o Pac Manhattan

o Can You See Me Now

o Scoot

• Introduction to the system

• How to make your own events

• Pre workshop questionnaire

0931 – 1000 Out and about

• Teachers take students out to find points for events

1001 – 1130 Event creation

• Teachers and students input the data they have collected to create an event.

1131 – 1200 Participation

• Groups swap events to participate in.

1201 – 1300 Post‐event Discussion

• Find out if there were any glaring difficulties

• Was it easy to build an event? If not why?

• If they enjoyed it

• Anything they would like to have seen but were not available

• Post workshop questionnaire


98

7.3.4 Task List Task

No.


1 Locate checkpoints. Teachers will take students out to the area

surrounding DESC and locate a total of up to 6

checkpoints.

The distance between checkpoints and the kinds of

checkpoints will be to the discretion of the group.


into system.

Teachers and students will be assigned a SIM card

and be allowed to log in to input the findings of their

walk outside into the Cipher interface.

3 Play a game.

Groups will exchange games for play. This will

involve each team being manually assigned a game.

4 Discussion/Debrief Groups will be allowed to talk about their

experiences while playing the games and any issues

encountered.

This will also provide an opportunity for teachers to

discuss any learning potential that comes with

participation and creation.


99

7.3.5 Test Environment/Equipment The workshop will take place in the DESC building in Adelaide. Students and teachers will be separated

into groups according to their school.

Groups will each be assigned a computer and a SIM card, which will be used with their own mobile

phones.

The test will require a room large enough to accommodate up to 20 people, which includes groups as

well as monitors.

A total of 3 computers will also be required for testing to take place; one for each group. The computers

can be situated together in the same area so that participants will encounter the usual distractions that

they would face in a home or work area.


100

All the computers should have an internet browser installed on which the pages will be displayed. The

computers should have internet connectivity so that participants can create and save their events as

they would if using the site anywhere else.

Participants will be able to use the area surrounding the DESC building for locating checkpoints and

plotting a game path.


101

7.3.6 Workshop Facilitator Role The facilitator will be responsible for orientating the participant, and will be responsible for interacting

with the participant in order give the participant tasks as well as to elicit verbal responses from the

participant with regards to the interface and the actions taken.

The facilitator should also attempt to identify and discuss any possible implications for pedagogical

application and issues that may arise with such a system.


102

7.3.7 Evaluation Measures The following evaluation measures will be collected and calculated:

1. Number of participants who managed to complete building a game and the number who did not

manage to complete.

2. Completion of assigned games.

3. Unusual or unexpected responses that the participants have with regards to the interface.

4. Error classification:

• Non‐critical errors: Errors a participant makes that can be recovered from.

• Critical errors: Participant unable to complete task, or unable to recover from an error made.

• System errors: Issues caused by bugs within the system.


103

7.3.8 Findings and recommendations See Appendix E for detailed results. Conceptualization

There were no major issues noted during the creation or playing of the games. 80% of teachers stated

that they found it easy to build events, and all students found it easy to build events, with 13% saying

they strongly agreed that it was easy. This is a marked improvement over their expectations prior to

building and event of their own where only 38% of students felt that it would be easy to build events.

The games played by other teams could be completed, and students indicated that they enjoyed

participating and would be encouraged to create more games in the future.


104

Event creation

The interface has proven to be friendly enough for even young users to use without much assistance

from the facilitators.

General response to the interface was positive both from students and teachers, with teachers rating

the interface an average 1.96/7 and students giving it a rating of 2.312/7, with 1 being the highest score.

All teachers agreed that they understood the process of building an event, with 60% of students

agreeing that they understood the process, 20% strongly agreeing, and only 6% not really being able to

understand the process. With more guidance that will be available in the final version, users will have

less difficulties understanding the process.


105

Interface Recommendations

1. Removal of title field in game builder. It was found to be more of a hindrance than a help. There

was confusion of its use and it was often not properly titled.

2. Expansion of text boxes in game builder from single line to multi line. Some participants felt that

would make the text in the box easier to read without having to scroll too much.

3. Use of text boxes in game tester, because participants often did not realize that they could

update their checkpoints directly from that screen.

4. Auto save function even when using links at the top of the screen. One participant used the link

to get around and lost data on the page.

5. Add extra fields to cater for multiple answers.

6. Remove “Preview” button because there is already a “next” button on the page. That confuses

users.

7. Scripting issues with publish button need to be worked out.


106

8. Current Cipher Interfaces The interfaces here mirror those that will eventually be released once initial test releases are complete.

In order to work around the restraints of production times and release deadlines, the system will be

built component by component. These interfaces are accurate as of the time of writing, but given that

the system is constantly in a state of improvement and change prior to release there is no way to control

the version that will be available online.


107

8.1 The City Page



108

When building this page, the issues considered were that users typically try to get a gist of a website

from just a glance. It was therefore important that the Cipher Cities concept was concisely presented to

users in a form that would be easy to digest, and visually appealing. To ensure that the main message is

communicated efficiently, the main body of content would also have to be viewable without the user

having to scroll down the page. In order to address these issues, icons were used to illustrate some of

the main functions the site would offer, along with a short caption. In addition to the descriptions,

pictures drawn from the pool of game photos will also be displayed to show how members are

participating in the site. Beneath all the pertinent information is additional information that interested

users who scroll down will be able to view. This is information that while may not be critical to attracting

a user’s attention may serve to help make a decision as to whether to sign up. Once a user is logged in,

parts “d”, “e” and “f” will no longer be displayed.

a The logo serves as a secondary link back to the home page that is always present

b Persistent prompts to user to log in on register. Once logged it, it displays the user picture, profile

and links to the message system.

c Links to the various sections.

d Describes features to potential users. This will only display if not logged in.

e Lets user view game posters.

f Prominent registration link.

g Serves as a news widget for updating users.

h Displays all the latest games created.

i Lists newest citizens.


109

8.2 Registration

Registration is essentially a three step

process. During the registration, a help

panel is available on hand to describe the

fields to the user, so that there will be

minimal confusion. This is especially

important when handling fields that

involve the user’s mobile phone details.


110

8.2.1 Step 1: Collection of Details


a Progress is indicated to the user via a step number display. The current step is made bold.

b This serves as a help bar, giving assistance to users who have trouble with fields.


111

Once the details have been collected and checked by the system, the user is taken to the next page, and

will simultaneously be sent a verification email and verification SMS to ensure that the details provided

are accurate.

c The user id must be unique.

d The email address must be unique and will be verified.

e Passwords are standard.

f The mobile number must be unique as well and will be verified.

g This humanity check prevents spammers from jamming up the system.

h Terms and conditions is needed from legals

i This is where the user agrees to the terms and conditions.

j Continues to the next step. This follows web conventions.


112

8.2.2 Step 2: Verification


a A verification code is sent to the user’s email address. From there, the user can click the link to

come back to this page with the number filled in, or enter it manually.


113

If the user is unable to complete this step, they will be allowed to come back at a later time to enter the

details. To ensure minimum confusion, the user who is unable to complete verification will be sent back

to this page immediately after the next log in.

b A verification code will be sent to the user via SMS. This must be filled in.

c In case either fails, of if the user thinks there was a problem with the details filled in previously,

they will be able to either resend the verification codes, or edit their details.


114

8.2.2 Step 3: Profiling


a The user can select a country, or choose not to.

b The city option makes the user more place specific.


115

Users who complete verification will be able to participate fully; therefore it is necessary that they have

a suitable profile. As such, this last step to registration involves the creation of a personalized profile.

The user will be given the option to enter details as necessary. Fields that are not completed will not be

displayed when the profile is viewed.

Once this step has been complete, the user will be informed that registration has been successful and

sent to the home page from where the user will be able to start playing.

c The user can choose to enter an age, or it may be removed for protection of younger users.

d The user has an option whether or not to specify gender.

e The user will be allowed to upload a personalized avatar. This will be resized accordingly by the

system.

f The user will be allowed to customize their profile by talking more about themselves and creating a

forum signature. This is essential for identity building, which is a building block of community

building.


116

8.3 Personalised Home Page


The personalized homepage was designed to serve as a member’s control panel, allowing for the display

of pertinent information as well as a means of communication with other members. It grows along with


117

the member in question and will serve to present a member to a broader community of users, thus

enabling a sense of achievement as well as attachment to the system as described earlier.

a Persistent interface

b Quick links to information that is pertinent to the user.

c Avatar and player ranking

d Player ratings. Player ranking derived from games played and completed, creator rating from

average of all games created.

e Member’s detailed statistics.

f Member’s alerts including messages and invitations.

g Member info and blurb.

h Notices left by other members that are viewable by the public.

i Allows member to update profile.

j List of games the member is participating in.

k List of games built by player

l Members who have played games together with current member.

m Top games in Cipher cities. Below that are the top players and builders.

n Groups the member belongs to.


118

8.4 Participation and Game Listing

There are 2 different kinds of

games. The first kind is a race

game, and the second is an open

game. They both operate within

similar systems, except that the

former functions within a limited

span of time and the latter can be

joined at any time.


119

Race Games

• Takes place within a limited time span, or involves players or teams competing to complete the

game first.

• Start times are specified by the game creator.

• Players involved will receive an SMS at start time. In a team, one member will be appointed to

be “team leader” and as such will receive all SMSes from the server.

• All players registered to a team will be able to check their progress at any time by sending a text

to the system, which will identify their mobile number and return their current position. For

example: “You are currently position 1/10 teams”. This is important in order to maintain

competitive tension.

• At each check point, players will receive a clue that will enable them to find the next location, or

entitle them to move beyond that point.

• Should the first clue prove insufficient, players can request for up to 5 clues before the system

sends the actual answer.

• Upon completion of the last point, the player or team will be sent an SMS informing them of

their standing and their completion will be logged on to the server.

• Players receive 3 points for winning a game and 1 point for completion.

• Depending on whether the game’s creator specifies a need for a photo of the last checkpoint is

uploaded, the player or team is then able to rate the game and the game creator.

Open Games

• Players join and take part whenever they like. Participation can also take place at team level.

• The first clue is sent upon registration.

• At each check point, players will receive a clue that will enable them to find the next location, or

entitle them to move beyond that point.

• Should the first clue prove insufficient, players can request for up to 5 clues before the system

sends the actual answer.

• Upon completion of the last point, the player or team will be sent an SMS informing them of

their standing and their completion will be logged on to the server.

• Depending on whether the game’s creator specifies a need for a photo of the last checkpoint is

uploaded, the player or team is then able to rate the game and the game creator.


120

8.4.1 Game List


The game list was designed so that all the important details that a user will typically need when deciding

whether or not to join a game would be displayed. Things such as the type of game, location as well as

start and end times means that the user will know if they are able to participate in the first place. To aid

with this, there is the ability to filter games by location.

a Allows the user to filter display by Location and more specifically place.

b The user can sort by the various options available. An arrow will indicate the kind of sorting.

c On mouse over more details will be displayed.


121

8.4.2 Game Page


The game page was designed so that it resembled the personalised home page. This would ensure

uniformity in the presentation of the site to help

a Game title, image as well as statistics are contained in this section.

b Information about the game’s builder.

c Displays more detailed information about participating in the game.

d Most recent ratings received.

e Photos uploaded by players who have completed.

f Notes left by players. This acts as a forum board.

g List of players sorted by the most recent.


122

8.4.3 Join a Game


This page was designed so that by default users would be reminded that they can and preferably should

play games with their friends. Allowing players to select team mates from a drop down menu also


123

means that they would be able to do so quickly and without too much difficulty. The option for them to

add friends who are not yet team mates is also left open for the sake of flexibility.

a The player in the act of joining can add players up to the limit set by the game creator.

b The first member of the team is always the one creating the game.

c Players can select from a drop down menu, which displays players currently in the game, or by

entering a friend’s user ID in the text box. If they decide that they do not want to have to many

players they can delete one with the X.


124

8.5 Game Creation The design of the game creation system was critical to the deployment of the system, because success

hinged on the ability of most users to create and deploy playable games of their own. Drawing from

Debra Polson’s experiences with designing her own location based games, the interface was designed to

guide a user through a logical sequence of steps that would help build the game up in a manner that

would ensure that the created game will be, if not enjoyable at least coherent and playable. The

sequence was refined by user testing, and verified by allowing groups of participants to build their own

games and play them.


125

8.5.1 Game Creation Step 1


The first step involves setting up an overall theme for the game, including a default image and a short

description or story. This ensures that there is cohesion for the rest of the steps.

a List of steps to inform builder of progress.

b The game title is a mandatory field.

c Builders can upload an image to represent the game.

d A detailed description will allow players to know more about the game.

e Location is a list of countries, and place is more specific because builders can manually enter

details.

f Builders can save anytime while building so information can be retrieved if the system crashes.


126



This step requires the user to make slightly more complicated choices involving how the game is played

and what players will need in order to take part. The description panel is there to help the user make

the right decisions. This screen had much refinement from the user testing process by way of the terms

used and how they were interpreted by users.

a This is whether the game will be visible in the game browser. A public game is viewable on the

browser and available to all, but a private game is only available to those invited.

b The player will have to choose the kind of game it will be, which will affect what is displayed below.

c Start times are standard for both race and open games, but only race games have a designated end

time.


127

d Users will be able to specify how many people must be in a team in order to participate in the

game.

e Users will also be able to suggest the kinds of equipment that may be required. This can be

customized to suit the location of the game.

f Instructions allow builders to create a varying degree of complexity in a game.

g Using game links means that builders will be able to expand the scope of the game beyond the

Cipher Cities website.


128



For building a game proper, users are presented with some initial checkpoints to show that they can

have more than one. Features felt to be essential for ease of use and convenience included the ability to

drag and drop checkpoints to rearrange them, and a character counter that would alert users to the

number of characters left for each text box. The naming conventions were revised after user testing to

incorporate more appropriate terms.

a Players can create checkpoints as required, with up to a maximum of 10 checkpoints.

b Information regarding the total number of checkpoints and the number of clues per checkpoint is

displayed prominently.

c Each node expands like an accordion when clicked, revealing editing functions. They can also be


129

deleted when not required.

d The SMS question that will be sent to players will have a limited number of characters.

e The SMS answer is limited to an even shorter answer, because lengthy answers will cause

confusion and complication.

f Users can create up to 5 hints per checkpoint.

g This will be the message players receive upon completion.


130



This screen allows the user to review the checkpoints before moving on to the final screen. The interface

simulates the playing of the game on an actual mobile phone and allows users to test their games as

they would on a mobile phone. Results from user testing have prompted the addition of features that

allow users to make direct changes to checkpoints from this screen rather than having to go back a step.

Other changes include automatically expanding the checkpoint that is being tested so there will be less

confusion in finding the right field to correct if changes need to be made.

a The checkpoint’s title will be displayed. Like the previous step, the checkpoints open up in an

accordion fashion.

b All the information entered in the previous section is displayed here. It is all directly editable.

c Players enter information into the mobile phone and receive replies as if they were playing the

game on a regular phone.


131



This screen show what the game poster will look like to other users prior to being published. This allows

changes to be made before a game is released to the public. If a game is published and changes need to

be made, there are provisions for that as well.

a The publish button is prominently displayed so users know where to click and is indicative that this

is the final step.


132

8.5.6 Game Creation Complete


This confirms that the user’s game has been published and allows builders to invite friends and other

members to participate. This is like the join game page, which encourages the sharing of games amongst

friends.

a Builders can either select from a list of team mates, or enter specific details such as a player ID.

b A list of invited players will be displayed.


133

8.6 Groups


Currently the grouping feature will be part of the next phase of release and will initially be limited to

what we as the administrators create. Later releases will see users being able to create their own groups.

Some suggested groups have been: city, park, coast, kids, over 18, walk, drive and bike.

These are very general and allow players to group themselves in accordance to the kind of elements

they might be interested in seeing in a game. Other categories right now could include country. So that

players can cluster by geographical location.

a Players can switch the view between groups they are already members of, and browsing all

available groups.


134

8.6.1 Group Page


Individual group pages are relatively straightforward in that it displays information with a similar layout

to a game page, or a profile page. Creating a set of conventions that operate throughout the site means

that users can be assured of a standard and will have less difficulty learning how to use it.

Designing

8.7 Ga

The treas

into subty

all the nod

see who c

feel inclin

Because o

can run in

A series o

• Fi

• Fi

• Fi

• Fi

These ico

they migh

Figure 6.1

a Web Based I

ame Ico

ure hunt gen

ypes, one is th

ds to win, but

can finish the

ed.

of the nature

ndefinitely, or

of icons have b

igure 6.1, the

igure 6.2 repr

igure 6.3 is th

igure 6.4 repr

ns are display

ht be interest

nterface to En

ons

re, which is th

he race game

t the differen

fastest, whe

of game play

r until the cre

been designe

e map with a c

resents an ina

he icon for an

resents an op

yed as part of

ed in playing.

Figure 6.2

courage the Cr

he only kind o

e, and the oth

nce as the nam

reas in an op

y, a race game

eator decides

ed to reflect t

clock represe

active or ende

open game

pen game tha

f game detail

.

Figu

reation of Mob

of game user

her the open g

me suggests i

en game play

e typically run

to end it.

he type of ga

ents an ongoin

ed race game

t has been en

s and allow u

ure 6.3

bile Phone Bas

s will be allow

game. They b

s that in a rac

yers are allow

n for a short d

me as well as

ng race game

e.

nded.

sers to quick

Figure 6

ed Location Ba

wed to create

both require u

ce game, play

wed to particip

duration, but

s the game’s s

e.

ly identify the

6.4

ased Games

e can be divid

users to comp

yers compete

pate when th

an open gam

status:

e kinds of gam

135

ed

plete

e to

hey

me

mes


136

9. Findings

9.1 Interface and Interaction Keeping with the goal of designing an interface that will encourage the creation of mobile based location

based games, the current interfaces have been designed with reference to current literature and

available examples to provide sufficient agency to users in a form that is sufficiently easy to use such

that they will be encouraged to participate. However, with Web 2.0 systems there is never any real

conclusion, and this is the case with the Cipher interface. As the public launch draws near, preparations

will have to be made for further evaluations in order to keep up with increased user expectations and

user requests.

While the site has been proven to be usable, there is no way to gauge if the concept as a whole will be

entirely successful until the actual launch. Results from user testing indicate that the current “Game

Builder” interfaces have proven to be successful beyond our expectations because user testing has

shown them to be easy to use, with participants during the most recent iteration of testing being able to

go through the process without any issues. Most participants have even expressed that they found the

creation process to be enjoyable, and one that they would like to go through again. Furthermore, the

current iteration of the game builder fulfils Surman’s 5 principles for online tools:

• Balance simplicity, access and power

Users have had little or no issues with creation games when left on their own.

• Fit in with the normal daily routine of users

With computers becoming increasingly part of day to day life for most people, no special

effort has to be made to access the tool.

• Empower users

For the first time, users are able to create and participate in their own location based games.


137

• Make it free or cheap

Building a game is a matter of accessing the website and does not require any additional fee.

• Listen constantly to what users are saying

The site’s design is constantly being informed by user evaluation and as such has evolved

into one that caters to specific needs highlighted by users.

Future versions of the game builder will be guided by observation of user usage patterns and requests

when it is eventually released, who ultimately serve as the most accurate informants with regards to

what will be best for the application (Musser, 2007, p. 42). User tests have indicated that allowing them

to build a game cooperatively would make it a more enjoyable experience, however due to time

constraints it was not possible to implement it in this version. It is likely that the next version will also

likely incorporate more complex tools for creating games that can operate in a non‐linear fashion as well

as the ability for builders to map paths on personal maps. Despite the fact that it is a given eventuality

and that it would have been feasible to design and implement such tools at this point in time, it has

been decided that releasing more features with increasing levels of complexity over a period of time will

allow users to come to terms with the application and avoid confusion (Musser, 2007, p. 45).

Apart from a web centric approach, future versions of the system will be designed to allow all the

processes to take place on the mobile phone via GPRS. This includes the creation of games as well as the

accessing of various elements of the Cipher site. This is especially possible because of the site’s modular

nature and the step based creation system. By implementing the GPRS model, it is hoped that SMS fees

can be circumvented, and the system can be run without extra cost to the user other than that of

bandwidth. These new Cipher interfaces for mobile devices will have to go through a separate process of

iterations due to the fact that they will have to be redesigned to better suit the platform.

Another often requested feature has been the inclusion of tutorials. This will likely be implemented in

the wider public release, and will involve the use of flash animations to describe better what a location

based game is, and considerations for building a location based game. Results compiled from observing

users has given an insight into the steps generally taken by users when planning for a location based

game and can be used as a base for building a tutorial.


138

9.2 Practice Applied Knowledge

As a result of engagement in the Cipher Cities project, my practice has indeed evolved along with the

requirements placed on to me by the performance of research and participation in the project. Initially

starting off with the basic ability to design aesthetically pleasing interfaces, I find myself in a position to

be able to create interfaces that cater to the user’s needs while making the most of what the system

designer has to offer. This was only possible through working as part of a team. Also acquired was the

ability to create interfaces that are grounded in theory. These interfaces are purpose built and are

designed to support or promote certain kinds of interaction, in the case community building, which is

something I have become extremely familiar with over the course of the project and is something I can

incorporate into my practice. Notably, the success of the Cipher Cities builder interface has resulted in a

spin off product that is caters for educational purposes, which is based on a number of the Cipher Cities

build interface’s theoretical underpinnings. It has undergone several rounds of testing and is currently

being used by teachers in a school in Cairns.

Collaboration

Through the course of the research, it has become clear to me that my role as a designer is slightly

schizophrenic. With the development team, I have to act as a voice for the user, making things easier for

them where possible, negotiating with the team to include useful features or discard those that are

redundant. When dealing with users I often have to speak for the development team, designing for

features that users have to come to terms with in order to be able to fully participate. This duality is

especially evident in designing for the game builder interface, where users have to be faced with an

entirely interface that requires them to build a game, which is an unconventional and yet essential to

the sustenance of the system. In developing the system, I had to design on behalf of the developers for

the end users at the same time representing the end user during meetings to discuss the designs.

Evaluation Methodology

Another significant and unforeseen result of the research is that a methodology for the design and

development of user interfaces has been created and has been adopted by ACID and put to use in

subsequent variations of the Cipher Cities project. The method is a combination of methods for user

testing outlined by Rubin in the Handbook of Usability Testing (Rubin, 1994), with a system of debriefing


139

and information dissemination that has evolved over the course of the development cycle.

Accompanying this is a set of templates for formulating questionnaires for usability tests as well as

checklists that will assist in the set up of areas for usability testing. The questionnaire template now

become a staple for many usability tests conducted for other Cipher spin offs.

The use of this methodology has helped to streamline the design and testing process which in turn has

had positive effects on the production and refinement of projects as well. The development of the

method has then allowed me to expand my area of practice, from being an interface designer to take on

the additional role of a usability tester.

9.3 Potential for Future Research While this study has been able to cover the groundwork for the creation of an interface that will

facilitate or attempt to facilitate the described actions as mentioned previously, its scope has been

limited to just that due to time constraints. A more comprehensive study would allow for the

observation of real world usage of the interface and its actual effects on community building and game

creation. Another area of interest that this study was unfortunately unable to explore were the effects

of a digital social network on location based gaming, which would give more insight into motivations for

creating and participating in games. More research can be done in this area, which will allow for a

greater understanding into this emerging area of gaming as a web service. This aspect will have to be

left to another time, or another thesis.


140

References

Aarseth, E. J. (1999) In Cyberspace Textuality(Ed, Ryan, M.) Bloomington, Indianapolis. (2006) Geocaching Australia.

AARSETH, E. J. (1999) Aporia and Epiphany in Doom and The Speaking Clock: The Temporality of Ergodic Art. IN RYAN, M. (Ed.) Cyberspace Textuality. Bloomington, Indianapolis.

AARSETH, J. E. (1997) Cybertext: Perspectives on Ergodic Literature, Baltimore, USA, John Hopkins University Press.

ADKINS, B. (2006) The Practice of Research as Discovery.

ANDERSON, C. (2006) People Power: Blogs, user reviews, photo‐sharing – the peer production era has arrived.

ANDREWS, D. C. (2002) Audience‐specific online community design http://doi.acm.org/10.1145/505248.505275. Commun. ACM, 45, 64‐68.

AVEDON, E., SUTTON‐SMITH, B. (1971) The Study of Games, USA, Joh Wiley & Sons, Inc.

BARRON, R. (2005) GeoCaching Rules.

BARTLE, R. A. (2004) Designing Virtual Worlds, USA, New Riders Publishing.

BASKERVILLE, R. L. (1999) Investigating Information Systems With Action Research. Communications of the Association for Information Systems, 2.

BATEMAN, C., BOON, R. (2006) 21st Century Game Design, Hingham, Mass., Charles River Media, Inc.

BENFORD, S. (2005a) Pushing the boundaries of interaction in public. Interactions, 12, 57.

BENFORD, S., CRABTREE, A., FLINTHAM, M., DROZD, A., ANASTASI, R., PAXTON, M., TANDAVANITJ, N., ADAMS, M., ROW‐FARR, J. (2005b) Can You See Me Now? , Mixed Reality Laboratory, Blast Theory.

BENFORD, S., MAGERKURTH, C., LJUNGSTRAND, P. (2005c) Bridging the physical and digital in pervasive gaming. Communications of the ACM, 48, 54 ‐ 57.

BLANCHARD, A. L. & MARKUS, M. L. (2002) Sense of virtual community ‐ maintaining the experience of belonging. System Sciences, 2002. HICSS. Proceedings of the 35th Annual Hawaii International Conference on.

BORRIELLO, G., CHALMERS, M., LAMARCA, A. & NIXON, P. (2005) Delivering real‐world ubiquitous location systems. Association for Computing Machinery. Communications of the ACM, 48, 36.

BROLL, G. & BENFORD, S. (2005) Seamful Design for Location‐Based Mobile Games.

CAILLOIS, R. (1958) Man, Play and Games, New York, The Free Press.

http://doi.acm.org/10.1145/505248.505275�


141

CAPRA, M., RADENKOVIC, M., BENFORD, S., OPPERMANN, L., DROZD, A., FLINTHAM M. (2005) The multimedia challenges raised by pervasive games. International Multimedia Conference Proceedings of the 13th annual ACM international conference on Multimedia SESSION: Brave new topics 1: multimedia challenges for planetary scale applications. Singapore, ACM Press New York, NY, USA.

CHAN, C. M. L., BHANDAR, M., OH, L.‐B. & CHAN, H.‐C. (2004) Recognition and participation in a virtual community. System Sciences, 2004. Proceedings of the 37th Annual Hawaii International Conference on.

CHANG, M., GOODMAN, E. (2004a) Fiasco:Location‐based, physical gameplay with a digital interface. Second International Conference on Pervasive Computing. Vienna, Austria.

CHANG, M., GOODMAN, E. (2004b) Learning from a Fiasco: Design in Conversation with Social Science Research. CHI. Vienna, Austria.

CHEOK, A. D. MXR Research Lab HP.

CHEOK, A. D., XU, K., LIU, W., GOH, K. H., TEO, H. S., TEO, S. L., FARBIZ, F., LEE, S. P., KATAI, O., KAWAKAMI, H. & NOTSU, A. (2004) Ubiquitous human media for social and physical interaction. SICE 2004 Annual Conference.

CHURCHILL, E. F. & BLY, S. (2000) Culture vultures: considering culture and communication in virtual environments http://doi.acm.org/10.1145/377272.377279. SIGGROUP Bull., 21, 6‐11.

COATES, T. (2005) Cal Henderson on "How We Built Flickr"..

COSTIKYAN, G. (2006) I have no words & I must design. IN SALEN K., Z. E. (Ed.) The Game Design Reader. London, England, MIT Press.

CRABTREE, A., BENFORD, S., RODDEN, T., GREENHALGH, C., FLINTHAM, M., ANASTASI, R., DROZD, A., ADAMS, M., ROW‐FARR, J., TANDAVANITJ, N., STEED, A. (2004) Orchestrating a mixed reality game 'on the ground'. Conference on Human Factors in Computing Systems Proceedings of the SIGCHI conference on Human factors in computing systems. Vienna, Austria, ACM Press New York, NY, USA.

DICK, B. (2004) A beginner’s guide to action research.

DONALD, N. A. (1998) The Design of Everyday Things, London, MIT Press.

EKELINEN, M., TRONSTAD, R. (2003) Video Games and Configurative Performances. IN WOLF, M. J. P., PERRON, B. (Ed.) The Video Game Theory Reader. London, England, Routledge.

FLICKR (2006) Flickr.com.

FOTOLOGUE http://fotologue.jp.

FRASCA, G. (2003a) Ludologists love stories, too: notes from a debate that never took place. Level Up Digital Games Research Conference 2003. University of Utrecht, The Netherlands.

http://doi.acm.org/10.1145/377272.377279�

http://fotologue.jp/�


142

FRASCA, G. (2003b) Simulation Versus Narrative. IN WOLF, M. J. P., PERRON, B. (Ed.) The Video Game Theory Reader. London, England, Routledge.

FRIEDL, M. (2003) Online Game Interactivity Theory, Hingham, Mass., Charles River Media.

GLASER, B. (1998) Doing Grounded Theory: Issues and Discussions, California, Sociology Press.

GROSSMAN, L. (2006) Time's Person of the Year: You.

HALL, J. (2005) Future of Games: Mobile Gaming. IN RAESSENS, J., GOLDSTEIN, J. (Ed.) Handbook of Computer Game Studies. Cambridge, Mass., MIT Press.

HERR, K., ANDERSON, G. L. (2005) The Action Research Dissertation, California, SAGE Publications.

HESSELDAHL, A. (2003) Best War Blogs.

HUIZINGA, J. (1955) Homo Ludens: A study of the play element in culture, USA, Routeledge & Kegan Paul Ltd.

HUMMEL, J. & LECHNER, U. (2002) Social profiles of virtual communities. System Sciences, 2002. HICSS. Proceedings of the 35th Annual Hawaii International Conference on.

ISAACS, E. W., A. (2002) Designing from Both Sides of the Screen, Indianapolis, USA, New Riders.

JAOKAR, A., FISH, T. (2006) Mobile Web 2.0, London, Futuretext.

JOINSON, A. N. (2003) Understanding the Psychology of Internet Behaviour, New York, New York, Palgrave Macmillan.

JUUL, J. (2005) Games Telling Stories? IN RAESSENS, J., GOLDSTEIN, J. (Ed.) Handbook of Computer Game Studies. Cambridge, Massachusetts, MIT Press.

KEMMIS, S., MCTAGGART, R. (2005) Participatory Action Research. IN DENZIN, N., LINCOLN Y. S. (Ed.) The Sage Handbook of Qualitative Research. Third Edition ed. London, England, Sage Publications Inc.

KIM, A. J. (2000) Community Building on the Web, California, USA, Peachpit Press.

KRUG, S. (2000) Don't Make Me Think ‐ A Common Sense Approach To Web Usability, Indiana, USA, New Riders Publishing.

KUSHNER, D. (2006) Location, location, location [location‐based games]. Spectrum, IEEE, 43, 62‐67.

LAST.FM (2007) http://www.last.fm.

LAZAR, J. (2006) Web Usability: A User‐Centered Design Approach, Boston, Pearson Education Inc.

LEIMEISTER, J. M., SIDIRAS, P. & KRCMAR, H. (2004) Success factors of virtual communities from the perspective of members and operators: an empirical study. System Sciences, 2004. Proceedings of the 37th Annual Hawaii International Conference on.

http://www.last.fm/�


143

LEVINSON, P. (2004) Cellphone: The Story of the World's Most Mobile Medium and How It Has Transformed Everything!, New York, Palgrave Macmillan.

LIGHTMAN, A., ROJAS, W. (2002) Brave New Unwired World, New York, USA, John Wiley & Sons Inc.

MAGERKURTH C., C. A. D., MANDRYK R. L., NILSEN T. (2005) Pervasive games: bringing computer entertainment back to the real world. Computers in Entertainment (CIE), 3, 4 ‐ 4.

MCCULLOUGH, M. (2004) Digital Ground, USA, MIT Press.

MIREL, B. (2004) Interaction Design for Complex Problem Solving, San Francisco, California, Morgan Kaufmann.

MUSSER, J., O'REILLY, T. (2007) Web 2.0: Principles and Best Practices, California, O'Reilly Media, Inc.

MYNATT, E. D., ADLER, A., ITO, M. & O'DAY, V. L. (1997) Design for network communities http://doi.acm.org/10.1145/258549.258707. Proceedings of the SIGCHI conference on Human factors in computing systems. Atlanta, Georgia, United States, ACM Press.

O'REILLY, T. (2005) What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software.

RADENKOVIC, M. (2005) Novel infrastructures for supporting mixed‐reality experiences. Multimedia, IEEE, 12, 12‐19.

ROLLINGS, A., ADAMS, E. (2003) Game Design, Indianapolis, Indiana, New Riders.

RUBIN, J. (1994) Handbook of Usability Testing ‐ How to Play, Design and Conduct Effective Tests, New York, USA, John Wiley & Sons, Inc.

SALEN, K., ZIMMERMAN, E. (2004) Rules of Play: Game Design Fundamentals, Massachusetts, MIT Press.

SANGWAN, S. (2005) Virtual Community Success: A Uses and Gratifications Perspective. System Sciences, 2005. HICSS '05. Proceedings of the 38th Annual Hawaii International Conference on.

SHEDROFF, N. (2003) Research Methods for Designing Effective Experiences. IN LAUREL, B. (Ed.) Design research : methods and perspectives. Cambridge, Massachusets, MIT Press.

SILVER, M. (2005) Exploring Interface Design, New York, USA, Delmar Learning.

SOTAMAA, O. (2002) All The World’s A Botfighter Stage:Notes on Location‐based Multi‐User Gaming. IN MÄYRÄ., F. (Ed.) Computer Games and Digital Cultures Conference. Tampere, Finland, Tampere University Press.

SPOOL, J. M., ET AL (1999) Web Site Usability ‐ A Designer's Guide, California, USA, Morgan Kaufmann Publishers, Inc.

SURNAM, M., WERSHLER‐HENRY, D. (2001) Common Space: Beyond Virtual Community, Canada, Financial Times.com.

http://doi.acm.org/10.1145/258549.258707�


144

SVAHN, M. (2005) Future‐proofing advergaming: a systematisation for the media buyer. Proceedings of the second Australasian conference on Interactive entertainment. Sydney, Australia, Creativity \& Cognition Studios Press.

TRIGG, R., CLEMENT, A. (2000) Computer Professionals for Social Responsibility. Participatory Design.

UHLIR, K. (2005) Kurt Uhlir says the industry’s lack of understanding of the complexities of location technology is holding back LBG. Mobile Games Analyst, 3.

UTVICH, M. (2004) Write a Story as a Building: Interactive Media Design. IN HAGEBÖLLING, H. (Ed.) Interactive Dramaturgies. Berlin, Springer‐Verlag Berlin Heidelberg.

WRIGHT, P., MCCARTHY, J. (2005) The value of the novel in designing for experience. IN PIRHONEN, A., ISOMÄKI, H., ROAST, C., SAARILUOMA, P. (Ed.) Future Interaction Design. Singapore, Springer‐Verlag.

YOUTUBE (2006) http://www.youtube.com.

http://www.youtube.com/�

Appendix A


A‐1

Can You See Me Now (CYSMN) Context In a nutshell, CYSMN could be likened to a digitally enhanced version of cops and robbers. Taking place

in a built up area 500m by 1000m in dimension, runners who are physically present in the location,

chase 15 players through the streets. The catch is that while runners are there in person, the players

participate by controlling an avatar through a virtual representation of the actual location. Runners

therefore can only “see” players as representations on a handheld computer. They then have to track

players down and get within 5m of them to effectively “see” them and put them out of the game.

Similarly, players can only see runners as they are represented on the virtual world by way of GPS

tracking and will do their best to avoid them.

Rules of Play

Operational Rules

CYSMN runs for a total of 2 hours from start to finish, in an area 500m by 100m in size, during which

virtual players can join in at any point in time, with a total of 15 players online, and any number of

players in queue waiting to join in. At any time there will be 4 runners trying to “see” the players.

Players are dropped into the virtual space to start the game at any one of several predetermined start

points. All players start with no points, and scoring is determined by the total duration of time spent in

the virtual environment.

Runners are tracked by GPS and are displayed on the player’s map of the location. Similarly, player

locations are transmitted wirelessly to each runner’s handheld computer.

Each runner is equipped with a walkie‐talkie that they can use to communicate with each other. These

conversations are then streamed in real time so that the online players can listen in. Likewise, players

are able to chat using a text based interface that runners will have access to.


A‐2

While runners play in the physical environment, players participate within a 3d representation of the

actual environment, which restricts their movement to where actual streets are. Players will not be able

to enter buildings or cross virtual fences as defined in the virtual environment.

As with cops and robbers the challenge is for the player to not get caught by the runner, which happens

when the runner comes within a 5m of the player’s position displayed on the hand held computer’s

screen. The runner will then take a photograph of the location that the player was “seen”.

Constitutive Rules

• Players begin with a value of zero.

• A player’s value increases with time.

• Players are restricted to move from point to point within a virtual grid (1000m by 500m in

physical dimensions), further restricted by blocks within the grid.

• As long as the player is greater than 5m from the runner they continue to be in the game and

their value increases accordingly.

• If a player is within 5m of a runner their value becomes zero again and they have to queue to

reenter the game.

Implicit Rules

• Runners will not run through buildings to trap players. This is because GPS does not always work

indoors and this would allow them an unfair advantage.

• Participants will not abuse each other.

• In order to play again, players must join the queue.

• Local knowledge will be used to the advantage of whoever has it.

• Communication will only be through the means provided.

• Mislead each other to get other players in the way of runners to avoid being caught.

Competition and Cooperation CYSMN involves up to 15 players participating at any time, but the players are constantly being taken

out, with new players being put in to substitute those who have been “seen” by the runners.


A‐3

Players are not shown their scores at all during play. Only after they are out is their score revealed to

them, following which, they highest scores will be put on a high score list.

There is a sense that in a way, because players are participating virtually, and only see runners as virtual

representations, they are playing against a virtual opponent with human intelligence. The fact that they

are allowed to communicate with each other indicates that some level of cooperation is allowed to take

place, however there is no real incentive for cooperation and players may use communication for other

purposes as well, such as misleading other players so that they end up getting “seen” instead.

Stripping away all the technology, CYSMN is in a way a little like Pac‐Man, except that instead of the

rigidity of a maze, players are given streets. Players compete for a little more than a space to call their

own, away from runners, and from other players (who might draw the attention of runners). Sure, they

might help other players to tell them where the runners are (for real), but the bottom line would be that

players are all fighting for their own space, which entails competition more than cooperation.


A‐4

User Participation

Dynamics

Runners and players act as textons, and by moving within the space, they create a variable number of

scriptons. They do not add anything to the system and as such, the game can be said to be employing

intratextonic dynamics (IDT).

Determinability

The state of the game is indeterminate. From the start, players are put into random (although

predetermined) start points from which they proceed to move around in an environment where both all

agents in the system (players and runners) are all controlled by people. This ensures that game

experience will be different.

Transiency

As mentioned in determinability, all agents in the game are controlled by actual people. Because of that,

for the duration of the game, even if a player is removed the game will continue to run; scriptons will

continue to be generated. For the 2 hours that the game runs, the virtual world is persistent and as such

it is transient.


A‐5

Perspective

Each player’s individual actions have an effect on the game world and will affect the outcome, therefore

it can be said that the game is personal.

Access

The game is designed such that virtual players are constrained by limits to their movement such as

speed, as well as the environment. For the player, the game in itself can only reach a conclusion either

by the player being eliminated or the game coming to a complete end. These 2 scenarios however, are

limited by the factors as mentioned above, because the game can only end for a player if “seen” by the

runners and that is provided that they move close enough to the runners. The complete end is then

limited to surviving the entire game until it finishes. Either way, players do not have direct access to

every part of the game at any time.

Linking

There are no links in the game, because it only consists of one level, in which the players are free to do

as they please. There are no prerequisites to complete.

User function

Players neither add nor remove anything from the space, therefore in this case the player’s function is a

configurative one, being able to generate or alter scriptons by way of communicating with fellow players.

The scriptons being altered refer to the way that players as well as runners move through space, and

this is achieved either through direct action such as movement of the avatar, or the processing of

communication (textual as well as audio).


A‐6

System Issues

Sites and devices are embedded with microprocessors.

In CYSMN, sites refer to both the actual locations as well as where players are participating from. It is a

given that runners are equipped with microprocessor‐ed equipment that have been specially configured

to function as part of the network that forms the game. Players operating from home make use of

computers to play. In order to play they install software, which enables their equipment to connect with

the system. This is the kind of “low level” communication that McCullough was referring to.

WiFi antennas are embedded at the actual location before the game takes place. These are only used for

the duration of the game, and are subsequently removed. An interesting point to note is the use of GPS

devices that interface with overhead satellites. The satellites constantly orbit the planet, and their

position determines the availability of the service over the location. These are not embedded in the

location per se, but do serve the location as if they were.

Sensors detect action.

The sensors in question here are the GPS devices that runners have on. They connect them to the

system that detects their movement and displays it to the players at home.

Communication links form ad hoc networks of devices.

Networking of devices in CYSMN is carefully worked out before hand. The only ad hoc aspect of the

network is the use of GPS devices, however these were temperamental and GPS glitches such as black

spots where there would be no GPS reception, or from errors in the location. A lot of the problems with

GPS stemmed from satellite positioning which meant that there was not much control over how it

would affect the game. There was also the problem of locating GPS satellites which take “several

minutes” before a fix on satellites could be acquired During these periods, runners could disappear from

the virtual space (Benford, 2005b).

Tags identify actors.

Tagging is an essential part of the game, because runners have to be tagged in order for their individual

positions to be tracked and displayed in the virtual environment.


A‐7

Actuators close the loop.

There is a distinct lack of intelligent actuation in the game. For the duration of the game there is a

continued streaming of information from the runners as well as the players. These streams are not

adjusted by the system to create optimal performance, and neither do they reconfigure themselves to

change the game.

Controls make it participatory.

As a player, CYSMN does not offer actual physical participation. That is not to say that the game is not

entirely enjoyable, but the lack of participation in the physical and haptic sense does detract from its

claim of being a pervasive game. The pervasiveness is more focused on runners than on actual players.

Display spreads out.

Again, the display that spreads out applies only to runners. Players have to play from a terminal that is in

a fixed location. The runners on the ground are equipped with PDAs that are updated with accordance

to their location. This is not a giant display in the sense, but it does provide the runners with a display

that moves in accordance with them.

Fixed locations track mobile positions.

As discussed an earlier point, players in their fixed positions are able to track the locations of the

runners that are moving around within a physical location. This is actually facilitated by a “control room”

(Crabtree, 2004) that does the actual tracking and broadcasts it to the players.

Software models situations.

CYSMN’s system acts as a conduit for interaction. It does not actually have any intelligence of its own,

because it has not been designed to model situations for users. Despite the shortcomings, connection

details have been extracted from the system, enabling the designers to diagnose possible problem areas

that will allow for improvements in later incarnations.

Tuning overcomes rigidity.


A‐8

The repeated process of running CYSMN allows the system to be tuned and improved each time it is run.

The issue then is that each city that the game takes place in requires that the system be tuned to the

model of that city, because of the direct interdependence between the system and the physical location.

This will allow the individual units of hardware to be tuned to function more efficiently, but the system

as a whole still suffers from constraints with respect to on the ground tuning because each city and

unique, and the system cannot be tuned while it is running. Evidence of this can be seen in the

deployment of WiFi antennas, which require prior planning and the means to install them. It would not

be feasible to then move or disconnect these antennas during a game as that would severely disrupt

game play.


A‐9

FIASCO

Context Created to function around New York’s urban landscape, FIASCO is an urban game that makes use of the

internet to create a series of location specific activities that encourage players to be physically involved

with space whilst promoting player interaction. It is a virtual “turf war” which involves players creating

stunts with elements given to them from the FIASCO website at an actual physical location, having a

picture of the stunt taken and then uploading it to the FIASCO website where other players vote to

determine if the stunt is outrages enough, which then deems if that location becomes part of that

player’s territory (or turf).

Rules of Play

Operational Rules

The player’s objective in the game is to expand the size of their territory on the map.

They achieve this by first selecting a location in New York with a web based application that then

generates elements of a stunt that they will have to perform at that location.

There are three elements that players will be presented with: object, action and theme. The object is

described as being “characteristically New York items”, action refers to a traditional street game (ie

hopscotch), and theme is a locale specific word (ie “vice”). There is also the fourth element of location,

which means that performance of the stunt has to take into consideration the context of the location

where it is taking place. In fact the stunt should be out of context with the place where it was performed,

because what is deemed to be “appropriate” behavior is very much grounded in location: the more

outrageous the better.

Photos of the stunt are then uploaded to the website and other players can vote on the stunt to

determine its “amusement value”. When multiple players are fighting for the same piece of “turf” then

the player with the most amusing stunt will win it.


A‐10

Players then go on collecting territories on the map of New York, going to other street corners and

challenging other players through the same process of performing stunts and getting them rated.

Constitutive Rules

• All players start with a value of zero.

• First time players then choose a point to start.

• When choosing a location, players are given a set of 3 parameters to follow.

• Players go to respective points and participate with accordance to set parameters.

• Players are rated on participation by other players.

• The player with highest rated participation at point will have value increased.

Implicit Rules

• Players should not set up dummy accounts to vote for themselves.

• The stunts performed should not be exactly the same as one that has been performed before.

• Do not claim other people’s stunts to be yours.

• Be nice to other players.

• Photographs uploaded are not to be doctored in any way.

• Stunts must be performed in location in an impromptu style setting.


A‐11

Competition and Cooperation

In FIASCO, the number of players is not limited, because persistent gaming is one of the key features.

Having a larger number of players will make the game more robust in that more activities will take place

at any given point in time and increase the chance of simultaneous activities occurring.

The game is based upon getting the highest score at any point. In order for players to secure their turf,

they have to receive the highest score, which will then mark that area as theirs. This score is displayed

on the website, and is only as constant to the player as the frequency that the player visits the website.

Players are also given a ranking that will allow them to track their standing in the game. This ranking is

displayed on a table that will allow direct comparison with other players.

Players act as obstacles for other players, when competing for the same piece of turf. The game’s

structure was built around the generation of competition between players on many levels. The first and

most basic level is a contest for turf, or space. Once these competitions begin, players will start looking

at each other’s rankings on the ranking tables.

Even with the introduction of a “posse” section to track player alliances, there will always be the need

for one player to come out on top. Salen and Zimmerman put it best by saying that “all games are

competitive” and “all games are cooperative” (Salen, 2004 pg. 255). Players cooperate with the system

and with each other in order to achieve a goal insofar as to submit their “behavior”, but at the core of it

is still the spirit of competition.


A‐12

User Participation

Dynamics

FIASCO has textonic dynamics (TDT), because players shape the way that the game is played through the

performance of stunts. These stunts represent textons, and when players perform them whether

completely original or not, they provide other players with material to build their stunts upon: an

evolving point of reference. This then affects the way that voting takes place and how territory is then

distributed (the forming of scriptons).

Determinability

As with games that involve human interaction for progress, FIASO is indeterminable because at any

point in time, players will not be able to tell how the game will unfold, or what other players may be up

to.

Transiency

Just as the game is indeterminate because of the human factor involved, it is also transient, because as a

persistent system of game play where players continue about their play at their own time, there is no

time at which the game is completely at a stand still. As long as there are players, the game will carry on

being played, not stopping to wait for any one participant.

Perspective

The game is very much a personal one, because each stunt that a player contributes stands to alter the

distribution of “turf” amongst players, as well as the overall ranking. This will then affect how other

players may play the game.

Access

Players have to make their way to the selected space as well as perform the stunt and go through the

process of having pictures taken and have the pictures uploaded before they have a chance to win the

territory, which will lead on to further development of the game, so it can be said that player’s access is

controlled.


A‐13

Linking

Players can access any area within the game at any time, limited only by their own personal ability to

travel. This is then limited strictly to access in the physical sense. However, it is understood that the

game not only operates in the physical realm, but the virtual as well.

In order to access a territory as their own, the player then has to undertake the steps documented in the

operational rules for them to take ownership of that space.

However, even if ownership is not achieved, such incursions of territory may form rivalries which then

allow for further expansion of the game’s meaning.

Because the game is one of social interaction between players, these conflicts can be seen as scriptonic

in nature, adding to how the game is seen by other players, therefore linking is conditional.

User Function

In FIASCO, the player’s role is textonic, because as discussed before, the creation of stunts and with it

the creation of conflict means that players are in a position to add textons and traversal functions of

their own to the game.


A‐14

System Issues


Despite having taken reference from other location based games such as Geocaching(Chang, 2004b) and

CYSMN(Chang, 2004b), the hardware requirements of the game were stripped down to create a more

user centric approach, attempting to allow users to participate with the minimal amount of specialized

hardware as seen in the other 2 games. Fiasco involves players in more of direct physical interaction

with a location. As such there is no need for physically embedding devices into locations.


Because no sensors were present at any sites, all players had to provide a sensor of their own, which

was a device for capturing images of them performing the assigned stunts. The sensors can then be said

to be the players themselves, or their accomplices who take the picture for them for uploading.


As mentioned before, the user centric nature of the game has removed the hardware from the locations.

This allows the game to be deployed more flexibly, but detracts from the flexibility of communication

between players and the system.


When players sign up, they choose a user name that will be assigned to them for the duration that

FIASO runs. During this time, any stunts that they perform will be associated with that username.


This does not quite apply because there are no actuators applied in the environment. It can be said that

players act as their own actuators, but the changes are only reflected in the virtual, like when they take

over turf.


Again, there are no real controls in the spaces. Players do physically interact with the space within a set

of behaviors that have been prescribed to them, but they do not have the ability to interface with the

virtual from the given space.


A‐15


The display does not spread out.


By selecting a turf to battle for, players give themselves locations to be associated with that can then be

tracked from fixed locations. The players are mobile and able to move from turf to turf, thus they are

mobile. The issue with this is that the player’s location is not updated in real time.


The map of New York that players use to select turf to battle for models situations by creating the

random stunts for the users that are directly influenced by the locations. The system is not intelligent

enough to create these models on its own, but rather it is fed in to the system by its designers.


The absence of restrictions imposed by a location specific system meant that more people were eligible

for participation because of the widespread availability of the basic hardware requirements. This lack of

hardware restriction gave players pretty much free reign over how they wanted to play the game and

how they would play it.

Uploading pictures could be as soon as they wanted, or as late as they wanted. However, the grounding

of the game in more “established” forms of technology, along with the time delayed nature of play

(considering turnaround time between stunt performed and photo uploaded) also means that there is

less uncertainty to contend with in terms of designing the game as players are all responsible for their

own hardware.

The system itself is not a rigid one, and because of the delayed nature of play as mentioned before,

tuning can take place during the game, because it will take place within the software aspect and not

have too much impact on the game.


A‐16

Conqwest Context Conqwest is a “pervasive‐advergame” (Svahn, 2005) created for Qwest Wireless in the United States to

advertise their line of camera phones. It is a treasure hunt style location based game that employs

camera phone technology alongside Semacode tags (a kind of barcode designed to be read by mobile

phone cameras). It was devised to work with 5 teams from various high schools, each consisting of

between 20 to 25 players, competing against each other for a $5000 prize to be donated to the winning

team’s school.

Rules of Play

Operational Rules

In Conqwest, the designated city is divided into 8 zones which the various teams are supposed to move

between in order to locate Semacode tags, which hold variable value and function as treasure. The first

team to collect $5000 worth of treasure will be declared the winner and will get to keep the money.

Each team is assigned an animal totem and is divided into 2 groups. The first group consists of 5 players

will be assigned as movers they will be responsible for carrying with them their team totem. This group

is also tasked with preventing from other teams from taking over their base.

The rest of the players will be searchers and will be responsible for moving around the zone that the

team has occupied looking for treasure (Semacode tags).

All players are given camera phones in order to play the game. Movers will be given phones that will

allow them to enter and defend their base and searchers will be given phones that they can use to

collect treasure. Additionally, each team will be given maps that show them where the zones and bases

are and how the movers must move their totems.


A‐17

Treasure is collected by a searcher taking a photo of the Semacode tag which is sent back to Conqwest

HQ, but before the value of the treasure is allocated to them, the treasure must be unlocked. Unlocking

the treasure involves the team’s movers occupying the zone’s base.

There are 3 different base codes at any zone’s base. One is for entry, one for exit and one for challenge.

To secure a base, movers must carry the team’s totem to the section’s allocated base area and take a

photo of the appropriate “base code” (entry for an empty base, challenge for an occupied base), which

is then sent back to HQ for verification. To leave a base, the movers have to take a photo of the exit

code and send it to HQ. During movement from base to base, movers have to move along a designated

path or be disqualified from the game.

The zones are contestable in that even though there may be a team already in a zone, another team

may come by and challenge that team to control of the zone. To activate this feature, the team has to

take a photo of the “challenge” base code and send it back to HQ. The challenge involves both teams

bidding for the zone with an amount of money that they have acquired. The amounts they bid are then

exchanged, and the team that bids the higher amount gets to stay in the zone. The losing team has to

leave and will not be able to go back to the zone for a duration of 30 minutes.

Each zone has a super treasure, the location of which is initially given to the team when they enter that

zone as a sentence with missing characters in it. Every 6 minutes the letters are slowly revealed to the

team, therefore the longer they spend in the zone the more letters they will get thus increasing their

chances of finding that hidden special treasure.

Throughout the game, teams interact with the system with their mobile phones, and at the same time

are kept up to date on the progress of the game through an FM broadcast. This FM broadcast is

managed by an “operator” who gives details on each team’s progress their location and results of

challenges.

Constitutive Rules

• Teams start with a value of zero.


A‐18

• Players of a team are split into 2 groups. A smaller group with 5 players, with the rest of the

players in a larger group.

• Teams move from area to area, with the smaller group moving via a predefined route. If the

group does not follow the designated path the game is over for the team.

• Upon reaching each area the team is to register themselves.

• If there is another team already at the area then each team will offer a total amount from their

value. This value is then exchanged and the team with the higher value is registered for that

point, and the team with the lower value is deregistered.

• Once a team is registered at an area, the larger group may proceed to collect points within that

area. Each point that players of the team find will be added to the total of the entire team.

• Upon registration, the team will be given a series of characters. Every 6 minutes the number of

characters will increase. These characters will form coherent sentences that can collect a greater

number of points from a location within the designated area.

• The first team that collects 5000 points wins.

Implicit Rules

• Semacode tags are not to be moved around.

• All equipment is to be treated with care and returned in good condition afterwards. This

includes hand phones and totems.

• Players in teams must cooperate.

• No jeering at other teams.

• No exchanging of information between members of opposing teams.


A‐19


Up to 125 players can participate in the game at the same time, divided into 5 teams. These 5 teams are

spread out over 8 zones of play which although means that there is a smaller chance for teams to meet

in the zones, there is still a possibility that the teams will encounter each other at one point in time or

another.

Team scores are broadcast over an FM station, keeping all teams aware of each other’s progress

towards the final score of 5000. This keeps teams constantly aware of each other’s progress and in turn

fosters a further competitiveness between teams. This comparison takes place in real time, because the

game takes place within a limited time frame.

At a team level, players work together in order to locate treasure, and because there is no individual

score counting, players maybe less inclined to compete within a team. Between teams however, there is

a greater chance of conflict occurring, especially over control of zones, because each zone can only

accommodate one team at a time, and only through control of zones can players collect treasure.

User Participation

Dynamics

Conqwest employs intratextonic dynamics (IDT), because players are able to change the state of the

game by using the predetermined actions that are allotted to them.

They are restricted to interaction with the system through a series of Semacode tags, which are pre

positioned within the space. These tags, along with each player and the location form the textonic level

on which the scriptons are then built upon.

Players do not contribute to the game by adding textons of their own. There can be no addition of

textons on top of what is already available. Instead, there can only be a shortage of textons, which is to

say that if players are unable to find any of the tags, but even then the textons are not removed from

the game, they are merely not uncovered.


A‐20

Determinability

As with CYSMN and FIASCO, any game that involves human players will be indeterminate because of the

element of conscious thought.

Transiency

Conqwest is an intransient game. This statement can be viewed from 2 levels. The first is that of the

team. If a team infringes on rules and is disqualified, as long as it is within the time span of the game, it

will continue to be played; with or without the team.

The second level is that of the individual player. The absence of the player does not mean that the game

will be put on hold. If a player takes a break to go to the toilet, other team members will still continue to

play despite being one person down.

Perspective

Each player’s actions contribute to their team’s progress, which is then affects by how other teams may

play. A searcher’s inability or ability to find treasure, or a mover’s bad luck in bidding all contributes to

the success or failure of a team. Therefore it is personal for every player.

Access

Teams are free to move around within the area allocated to the game. However, it is insufficient to

equate this to random access, because another part of forming scriptons is the locating of treasure.

The “Super treasure” within each zone can only be unlocked by team with the treasure’s location. In

order to get the location, players have to wait for a certain amount of time in each zone, and the letters

spelling out the location will be sent to them. During which they can either wait for the letters to come,

or once they think they can figure it out they can go straight to where they think it is hidden.

All this would entail a discovering of the location, or an “unlocking” by waiting in the zone for an

appropriate amount of time in order to gain access to the texton that is the treasure, therefore access is

controlled.


A‐21

Linking

In order to collect treasure from a zone, the team must first “enter” if. This responsibility lies with the

movers, who carry the totem to the zone’s base. Movers have to follow a fixed path, and during

movement are restricted by traffic and other possible forms of obstruction, but there different ways

that movers can take to get from zone to zone. Therefore linking is conditional.

User Function

Players take on a configurative function in Conqwest. As mentioned in Dynamics, there can be no

addition of textons, and the player’s function is to locate the hidden textons. As such the player takes on

the role of configuring the state of game play rather than rewriting it or adding to it.


A‐22

System Issues


Player hardware consisted of camera phones that would allow them to take photos of the Semacode

tags to be sent back to HQ. Because Conqwest was an “advergame” for promoting camera phones,

player hardware was provided for by the sponsor; however Semacode tags were designed for use with a

wide variety of phones, as long as the Semacode decoder is installed. The user of mobile phones meant

that existing GSM infrastructure could be employed within the system. As such there was no need for

the sites to have electronics physically present to facilitate game play.


The sensors employed in this game were camera phones that players controlled. These phones allowed

players to interact with their environment in a way that would facilitate a sort of mixed reality

interfacing. Scanning a physical Semacode and receiving virtual “money”.


As mentioned before, the network that the game is built on is GSM that is already available. What the

system does is that it allows players to report back when they reach a tag. This means that the

communication is not of a continuous nature, but rather it depends on when the player comes in

contact with a tag and if the player then chooses to scan it. Therefore the networking of devices is very

much an ad hoc one.


Phones each have their own unique number, so when a player sends a scanned tag back to HQ, they can

be identified by the phone number.


A‐23


There are no actuators employed, because of the nature of the game. Like in FIASCO, players act as their

own actuators, choosing when to scan the tags that will be sent back to HQ.


The act of having to actually point the camera phone and take a picture in order to scan it involves the

player physically in the space, at the same time allowing the player to interface with virtual elements.


The mobile phone acting as a textual display allows players to get on the spot information about the

space. Examples of this can be seen when they battle for a base. First the player must scan the challenge

code for a base, and then they will participate in the act of bidding for the space, all of which takes place

at the base. Players scanning Semacode tags also interact in a similar way. By scanning the code they will

receive confirmation to tell them if they have received treasure. The visual display is spread out, but not

in each location. It is instead “built into” the players.


Player’s locations can be tracked with the system by comparing the phone’s number to the tags scanned.

This will enable a map of a player’s movement to be created.


Because the locational elements (Semacode tags) are not “smart” devices, means that the system does

not model situations automatically. The situations are modeled by physical intervention like putting up

the tags, not virtually. The question of “Who is here and what are they doing?” is thus not one that can

be answered by looking at the system, but by the rules of the game, ie.The player is there to scan a tag.


Semacode tags are a good way that location specific information can be delivered to players without the

use of additional hardware. By placing a tag at a certain location, players can then retrieve information

from the tag, simultaneously broadcasting the player’s location back to HQ. The deployment of the tags

is also relatively simple, because it involves the printing of a relevant tag on paper or a sticker and

attaching it to the appropriate location.


A‐24

By building the system around Semacodes and mobile phones, the Conqwest designers have created a

game that can be quickly and easily expanded as well ported from one city to the next, minimizing the

amount of planning involved as well as the cost of set up.

Hardware tuning becomes much less of an issue because of the use of established technologies, instead

the focus becomes one of streamlining the system to facilitate the game more efficiently.


A‐25

GeoCaching

Context GeoCaching is an global treasure hunt, where players with GPS units hunt for a cache of items hidden

somewhere by fellow players. When found, the player then fills in cache logbook and usually takes an

item, replacing it with something else. After a cache is found, the finder can then log the find online.

Locations of caches are available online. In Australia, for example, players find caches in their locality by

visiting the website (www.geocaching.com), and choose their location by country and state. This will

then bring up a list of caches in the specified state. By choosing a cache, details such as a description of

the location as well as additional hints will be displayed that they will be able to refer to in order to find

it. Players will even be able to download waypoints for their GPS unit.

Rules of Play

Operational Rules

The only “official” rules are found at the GeoCaching website, which summarizes it in 4 lines:

1. Take something from the cache

2. Leave something in the cache

3. Write about it in the logbook

Where you place a cache is up to you.

GeoCaching allows players to create their own games by creating their own caches. There are protocols

which describe what should go into the cache and how to go about hiding it that the player is

recommended to follow, but it is up to the discretion of the person doing the hiding because there is no

formal regulating body controlling the content of the caches or how they are handled.

There are rules that have been created by players, but those rules are more of reinforced common

sense than guidelines for play. These rules fall in between being implicit and operational, because on

http://www.geocaching.com/�


A‐26

one hand someone has already put them down in writing, but on the other hand players who have not

already seen these rules may have already made a point not to do these things. A good example was

found at the AustinExplorer.com (Barron, 2005):

• Never trespass on private property on the hunt for a cache.

• Never leave food or drink in a cache as they may attract animals that will damage the cache.

• Never leave any item in a cache that is not suitable for viewing by children. There are lots of

families who cache together.

• Never log a cache find unless you actually find the cache. If the cache is missing then report it to

the cache owner.

• Never log a virtual cache until you have confirmed the find with the owner or via Austin

Explorer's auto‐confirm web pages.

• Always rehide a cache exactly as you found it. The cache owner may have taken extra effort to

make the cache difficult to find. Respect their intentions.

Constitutive Rules

• Item(s) is/are positioned by owner.

• Owner makes grid numbers available to players.

• Item starts with a value of zero.

• Value of item goes up by one each time another player locates it.

• Owner retrieves item(s).

Implicit Rules

• Do not move the cache unless otherwise stated.

• Fill in the cache log with legible writing.

• If taking something from a cache, replace it with something else.

• Ensure that the cache is properly hidden again after it is found.

• If the cache is made to be weather proof, ensure that it is properly resealed.

• When hiding a cache, provide accurate details of where to find it.

• Do not hide the cache in inaccessible or dangerous areas.

• Do not claim to find a cache unless you’ve really found it.


A‐27


As an open treasure hunt, any number of players may be involved in locating a cache at the same time.

When a player locates a cache and reports the find back to the site, their total number of finds is then

totaled.

GeoCaching Australia’s website (2006) has a list of top finders and hiders on the main page, along with

top caches, which means that some players may prefer to hide caches than actually go out looking for

them, and compete to create caches rather than just find them.

Finders more often than not work together to locate a cache. Evidence of this can be seen again at the

website where cache pages allow finders to leave information about the found cache. Each bit of

information a finder posts helps other finders to locate the cache more easily. Even though there may

be competition between players to see who finds the most caches, because caches are shared between

all the players (when you take something you have to replace it with something else), there is no real

competition for resources.

Similarly for hiders who may be more concerned with having the most popular caches, they do not

compete for space per se, but are rather more concerned that players will be able to find their cache.

There is more a sense that the system fosters cooperative competition rather than outright conflict.


A‐28

User Participation

Dynamics

A player can take on the role of both hider and finder, but either way the game still involves textonic

dynamics (TDT). As a player, textonic dynamics would involve taking and replacing objects from the

cache as well as adding an entry into the log book. In the game who finds the cache may be just as

interesting as what the cache contains, therefore by performing those actions they are adding textons

into the game. The role of the hider in textonic dynamics is quite clear. By creating the cache they are

effectively extending game play by the addition of a texton in the form of the cache.

Determinability

The whole object of the game is for players to locate the cache. Some players may be interested in the

log book, whilst some others are interested in the items in the cache, whilst others may only be

interested in the thrill of finding it. What this then means is that determinability is affected by several

factors. Players cannot determine for sure what they will find in the cache, or which players may have

found it previously. That the cache is still there is another factor that players cannot confirm until they

actually go about the search. Therefore the game is indeterminate.

Transiency

Because the physical elements of the game are so grounded in the real world, the game is in a constant

state of change, with the environment, weather and various other factors, as discussed in

determinability possibly affecting the state of the cache. Other players will also continue to play the

game therefore there is no stoppage and the game continues on in a transient manner.

Perspective

By giving each player a chance to contribute both as finder and hider, this puts participants in the

privileged position of being central to the game play. In a sub genere of GeoCaching, players are allowed

to move the cache around, thus affecting how other players go about the search. Thus it is a personal

perspective.

Access


A‐29

Player’s access is controlled. This is because caches are hidden from view, and the coordinates provided

are not always of the greatest accuracy due to GPS limitations, and thus they will only be able to locate

the cache if they follow the clues that have been provided. The search for items maybe said to be the

fulfillment of a task or requirements that players must fulfill before being able to progress, either in

ranking or in personal progress.

Linking

The way players are linked from their start point to the location of the item are through a series of

decisions pertaining to knowledge of terrain and personal preference, and these form the links in the

steps players need to take in order to location a cache, so although a player may also have the

coordinates of various caches to be looked for in no particular order, the linking is still conditional.


A‐30

User Function

As discussed earlier, players can create their own content through the hiding of caches or with what

they add or take away from a cache. Therefore every player has a function that is textonic.

System Issues


The use of GPS means that there is no need for site specific implementation of technology. It is a wide

area network that can be accessed from most outdoor locations provided there are a sufficient number

of satellites overhead.


The sensors in question here are not directly linked to the game. GPS detects a player’s movement and

reports it back.


Use of communications here is on the basis of player preference. A player that is part of a group may

employ mobile phones, or walkie‐talkies to assist them in the search, but it is explicitly part of the

system.

Another aspect of creating communication links is the internet. These links are an implemented part of

the system, and although not necessarily location based, they create ad hoc networks by allowing the

player to participate at will.


Like FIASCO, players have user ids that will identify them when they find caches or when they hide the

caches. Again this aspect is not a local one and does not update in real time.


There are no actuators in Geocaching.


A‐31


GPS as a navigational aid puts the player into the game, because the player interacts with the system

through physical movement, but it should be noted that there is no real interaction with any virtual

system.


There is no display in Geocaching.


Players can be tracked only through caches that they find. There is no indication of their movements in

between, and it is not possible to track the player’s actual movements.


Geocaching relies less and technology more on the human element, so there is no software model for

modeling situations.


Taking part in Geocaching does not require a large amount of complicated hardware, but the essential

piece of hardware that players must own in order to participate is the GPS unit. However, despite the

uptake in technology, GPS has not found its way into mainstream device application per se. People

interested in participating would then have to purchase the GPS unit in order to participate. Given that,

anyone with a GPS unit can take part.

Tuning is not so much an issue with Geocaching, because a large part of the system is reliant on satellite

technology, which players have way of modifying.


A‐32

Human Pacman

Context Human Pacman is an updated augmented reality version of the Namco arcade game. Developed by the

National University of Singapore and deployed on campus, it involved players taking on the roles of

Pacmen and ghosts to physically chase each other around a designated portion of the campus aided by

helpers located at a computer terminal. These helpers provided the physical players with information

about terrain, and position of opposing characters.

The game involved interaction on a virtual as well as physical level creating a variety pf possible

interaction between all players, as well as varying modes of play ranging from treasure hunting to tag.

Rules of Play

Operational Rules

The objective of the Pacmen is to consume all the cookies in the game space, and inversely the task of

the ghosts is to remove the Pacment from the game, all before the decided time runs out. The duration

of the game is decided by the players.

Players will be divided into teams. One team represents the Pacmen, and the other team the ghosts. The

teams will be divided into 2 groups, the physical players and the helpers. Each physical player on the

team will be assigned with a helper who will aid with navigation as well as tracking the location of other

players.

Physical players will be provided with a wearable computer system that will allow their movement and

state to the tracked throughout the game, and helpers will be allotted a terminal from which they can

track the state of their assigned physical player as well as that of other players.

A Pacman is removed from the game when a ghost physically touches a player. There is a sensor on the

wearable computer that when touched indicates that the player is out of the game.


A‐33

Pacmen can also remove ghosts from the game, however like in the arcade version; this state can only

be achieved if the Pacman consumes a special cookie. In this case the special cookie is an actual physical

object that is hidden from view. The presence of this special cookie is indicated when the Pacman moves

within a 10m radius of the cookie through a series of sounds. The Pacman then has to find the special

cookie and hold it in order to collect the cookie. The cookie however can only be collected once by each

Pacman, following which it becomes useless. Once the cookie has been collected, the Pacman can either

decide to consume it, or send it to another player within the vicinity.

After consuming the special cookie, the Pacmen are given the power to turn the tables on the ghosts

and touch them instead. The power lasts for a minute, following which the player is returned to the

original state.

Regular cookies are easier to consume, and they come in the form of balls that the Pacman has to step

through. Every time a cookie is “consumed” it disappears from view.

Constitutive Rules

In this case there can be 2 separate sets of constitutive rules, because unlike in the other games

discussed, opposing teams have opposing goals. Therefore although they both play within the same

system, the outcome will be a result of different tasks performed.

Pacman

• Players starts at point zero with a value of zero. And is switched to mode zero. Mode zero

represents the player in original state, which is before consuming the ghost eating cookie. After

consuming the cookie their mode will be switched to one.

• Players moves over grid adding a point whenever moving over a new space in the grid.

• When the total sum of all the spaces in the grid is added up the player’s team wins.

• If the player is found to be on the same grid as an opposing team member, the player will have

to go back to point zero.

• Three contacts with a member of the opposing team means the player is out.

• If player reaches special grid numbers (not defined in specifications), they will be given the

opportunity to switch their mode to one. If they switch the mode to one, players can enter into


A‐34

the same grid as opposing players and receive points. This will send the opposing player back to

their point zero and add points to the player.

• Once a player enters the special grid number and switches the mode, the special grid becomes

disabled to them.

• Players entering the special grid can opt to send the mode switch to other players in grids that

are a certain radius away.

Ghosts

• Players start at point zero (different from Pacmen’s point zero).

• Players move within grid.

• When player enters same grid as opposing team player, the opposing player will go back to their

point zero.

• When players reach a total score that is a multiple of 3 the player’s team wins. Multiple of

threes because every Pacman has 3 lives, so 2 players would mean a score of 6.

• If the player in the other team has reached the special grid, then entering the same grid as them

will mean going back to point zero.

Implicit Rules

• Players are not to smack each other.

• Contact between player and helper will only be through the means provided.

• Equipment must be kept on at all times unless there is a malfunction.

• Play will cease in bad weather (ie heavy rain).

• Do no leave the play area during the game.


Human Pacman supports 4 physical players and 4 helpers (Cheok), which means there are 4 players on

each team, with 2 on the ground and 2 supporting virtually. There is no high score list in the game, and

each player is only able to see their own total score, which is updated in real time.

The game does not pause, but because each physical player has a helper, the helper can update them of

a fellow player’s score. Another possibility would be that the player could engage in verbal


A‐35

communication with a fellow team member. Players from different teams (Pacmen and ghosts) would

not have any standard by which to exchange scores, because they are playing for different kinds of

points.

Players from different teams act as obstacles to each other during game play. Because the ghosts are

after the Pacmen, and although the Pacmen try to escape the ghosts for most part, there is a conflict for

space. Between Pacment however, they are given means to cooperate in order to overcome the

opponent by way of sharing the special cookies that will allow them to “eat” the ghosts.

Between Pacmen, however there is also a sense that conflict will arise from players having to compete

for in game resources such as the cookies. These add up to points which determine eventually which

player wins.

User Participation

Dynamics

The game allows players to participate in intratextonic dynamics (IDT), because for both sides (Pacmen

and ghosts), there is a goal to be met that can be achieved through interaction with only the objects

available in the game. This objective is very clearly defined and may be achieved through a series of

tangible outcomes. The structure is also such that players communicate with each other only on a

personal level. Which is to say, helper to Pacman and helper to helper; there is no wide area

broadcasting like in CYSMN that can affect how other players may act. Therefore, although they do

contribute to the experience, the outcomes are fixed. This is different from CYSMN, where players just

keep running, hoping to make it until the time runs out.

Determinability

Players start at the same place, but movement during game play is only restricted by paths. Any path

can be chosen, therefore there is no determinate way that players will move.

Transiency


A‐36

When a player is taken out of the game, as long as the timer has not reached zero and there are still

enough players from opposing sides left, the game continues. Therefore it is intransient.

Perspective

The game play is personal, because the game revolves around the players, and their actions will affect

the outcome of the game as well as the game dynamics.

Access

Player’s access in the game is controlled, because in order to activate the ghost eating mode, they have

to first locate the special cookie. This means that they have to physically make it to the location of the

cookie and find it before they can be allowed to start attacking the ghosts.

Linking

As mentioned earlier, players have to follow the paths within the area to move around. They are not

supposed to cut through buildings or move through areas not designated as paths, but on the other

hand there maybe various paths linking point A to point B, therefore players can make a choice as to

how to move between points. Linking can then be said to be conditional.

User Function

The players take on a configurative function, making use of the resources at their disposal to make the

most of the experience. They do not add to the game world, and therefore they are only able to

manipulate existing elements.


A‐37

System Issues


The use of see through head mounted displays allows users to see the virtual world overlaid over the

real world. In order to overcome the problem of uncertainty experienced by the team in CYSMN, the

game’s designers have created a system that incorporates a GPS system with a dead‐reckoning module

that is effectively a pace counter to increase positional accuracy as well as an inertia cube that allows

the player’s head movements to be tracked. They also make use of a firewire camera that takes in video

input from the surrounding and sends it back to a computer that processes the data and sends it back to

the HMD.

There is also the use of a WiFi infrastructure that allows information to be sent to and from the system,

as well as Bluetooth devices at various locations around the space.


There is a variety of sensors employed in this case. The first is the gyroscope on the head mounted

display, which allows the system to track the user’s head movements. Second would be the GPS system

that tracks the player’s position, as well as a dead‐reckoning module that aids in ascertaining the

player’s location.

Bluetooth devices are also employed. These are programmed to detect a player’s proximity and

feedback the information.


Like CYSMN, because of the real time nature of the game, player’s information is constantly being sent

back to the system.


A‐38


Each player must have a tag in order to have the location appropriately represented in the virtual world.


Bluetooth devices detect how close a player is and then gives audio feedback. Once out of a certain

radius, the audio feedback stops. This works as an actuator by which players can gauge their distance

from the device.


As the name Human Pacman, the game focuses very much on human interaction that is mediated by the

system. The fact that it is an exercise in augmented reality game play means that the player’s physical

actions affect the game and are reflected in the system.

There is a combination of physical interaction, where players a player taps a rival player on the shoulder

in order to put the other out of the game, as well as the Bluetooth devices that require a player to come

into physical contact with them. There is also the aspect of physical‐virtual interaction where players

“eat” virtual cookies walking into them.


The head mounted display allows the game’s designers to spread the display out as far as the system

can reach. Again, this is not a display system that is physically built into the location, but is one that

players have to take around with them.


As is with the case of other games, a control center can monitor the movements of the players as they

move through the space.



A‐39

The software does not have an intelligent system of context monitoring, because it was only created

with the intent of facilitating the game of Human Pacman.


From the equipment used in the game, it is quite clear that at present only people with access to the

actual system would be able to play the game. The hardware used Human Pacman is by far the most

sophisticated of all the game discussed. The issue then is that the hardware would be too expensive at

this point in time for most players to afford.

All of the player hardware is then put together in a shell like backpack that makes it easy for them to

carry everything around and serves to protect the expensive hardware as well. The use of the backpack

also removes the computer and all the additional hardware from sight, making the system more

transparent to the user.

The infrastructure required for such an activity would take money and time to set up and would

probably require technical knowledge and skill that may be beyond the normal user. In order to

implement the game in another location, the space would have to be remodeled in order to be overlaid

on to the new space.

Appendix B


B‐1

Rules of Play The rules will be analyzed with the taxonomy from Salen and Zimmerman’s Rules of Play (Salen, 2004, p.

130). It is a comprehensive taxonomy which states that there are three kinds of rules in games:

1. Operational Rules

These rules are standard rules that come with a game. They usually come in the form of

instructions, which dictate how the game will be played.

2. Constitutive Rules

This refers to the underlying logic of a game, which is more often than not grounded in logic and

mathematics. These rules do not directly influence player behavior like operational rules, but

instead could be described as functioning more on a game’s “mechanical” level than the human

level.

3. Implicit Rules

These pertain to good sportsmanship and other forms of appropriate behavior between players

of a game. They vary depending on the context of the game, for example who the game is being

played with or where the game is played.

The way these rules place restrictions on the game then affect the way a game is played. They

determine if players will be inclined to cooperate against the game, or if inter‐player conflict will arise,

resulting in competition. In order to properly appreciate the implications that the rules have on play,

Salen and Zimmerman (Salen, 2004, p. 254) have devised a set of questions that help to highlight the

nature of conflict that is present:

• “How many players can play?”

This directly influences the kind of conflict that can take place. A single player game

would mean the player only has to contend with the system, but a game with more than

one player would open up possibilities for competition on a variety of levels.

• “Do they play simultaneously or do they alternate playing the game?”

Playing at the same time can result in competition for space, or in the case of some

games “experience points”, health potions or whatever else it is that will affect the

player’s prestige or durability within the game space.


B‐2

• “Is there a high score list?”

This pertains to pride that may be derived by players from seeing their score as the

highest. Again this encourages competition.

• “Are players given constant feedback about their relative scores?”

The more constant and prominent the feedback, the more competitive players will tend

to get with each other while playing the game.

• “Does the game pause to allow players to directly compare their scores and other game

statistics?”

Statistics usually indicate how well a player has done in a stage, and comparing these

statistics will invariable cause players to create competition around the various statistics.

• “Are there computer‐generated opponents and obstacles that players face together or

do the players serve as opponents for each other?”

“Does the structure of the game allow players to have direct conflict with each other?”

“Are there resources for which players can compete?”

These three questions should be answered together, because they describe if game play

is cooperative or directly competitive, and then later elaborate how competition may

arise. Direct conflict would involve players accidentally (or intentionally) killing each

other off, or competition for resources within the game, examples of which are “health

potions” or gold coins may cause conflict to arise even during cooperative play.

Games always involve some form of competition, even if they are cooperative. Huizinga observes that

the term “playing together” is “antithetical”, because even when engaging in play with another party

there always will be a form of “conflict”, and this is especially so when the game requires “application,

knowledge, skill, courage and strength” (Huizinga, 1955, p. 48), because at the end of the day playing a

game is about winning. Needless to say, conflict between the player and the system will always be

present, but it would also be reasonable to say that even at a cooperative level, players will also have

varying levels of competition.


B‐3

Player Role This involves describing the kind of role players take on within the system, essentially determining the

level that players are able to interact within the system; if their actions affect the system as a whole or if

they can contribute to the content held within a system.

It will be discussed using Aarseth’s Typology of Textual Communication (Aarseth, 1997, p. 58) in which

he states that narrative in interactive work is made up of smaller units, namely textons and scriptons.

Textons are the basic unit of which these narratives are made up. They are the “strings as they exist in

the text” (Aarseth, 1997, p. 62), which when woven together become scriptons, from which users (or

players in this case) may draw meaning from the work. As with most other forms of meaning it is

generated from context, or the medium that is used to transmit the scripton. It is from these 2 basic

units that Aarseth creates a textonomy (a clever play on the word taxonomy) that classifies how

interaction can take place within interactive works.

Aarseth’s textonomy is broken down into 7 variables. Just for simplifying the example, these variables

will be used in reference to games, which is after all a form of interactive work:

• Dynamics

This refers to how the game system is presented to a player. Aarseth states that there are 3

kinds of dynamics:

1. A static game would be one where the state of the game presented to a player is

constant. An example of this would be Mario Brothers where each time a level is played

the same situations are encountered at exactly the same time with no change. Identical

scriptons (levels) are presented using identical textons (game elements such as baddies).

2. An intratextonic (IDT) game is one that would present to players a series of variable

scriptons based upon a fixed number of textons that are already present. An example of

this would be a board game such as snakes and ladders. The board is fixed, as are the

pieces involved, but the game state progresses with each roll of the die and each turn.

The randomness of the die allows the game to be a little different each time, meaning

different scriptons are created.


B‐4

3. A textonic (TDT) game would be one in which the number of textons is not known, and

as such neither are the scriptons. An example of this would be an MMPORPG (Massive

Multiplayer Online Role‐playing Game), such has “Second Life” where the constant

presence of players can result in constant changes to the textons within a system.

• Determinability

Referring to the Randomness of game play, a determinable game would be one where the

player would always encounter the same set of situations, with one event always leading on to

another one in a fixed manner. An indeterminable game would be one where the state of play

differs from play to play. Games that rely on human intervention to progress, such as MMORPGs

are more often than not random because situations can change without any foreseeable pattern.

• Transiency

The game’s transiency which reflects how the game might continue even though the player is

not active. A game that progresses with time would be described as transient, as would a

persistent state game, such as an MMORPG which is carried on without the user’s presence or

intervention (Bartle, 2004). Snakes and Ladders would qualify as intransient, because it relies on

the user’s presence for the game to progress.

• Perspective

This deals with the player’s role in the game world, which is to say that if the player’s actions can

affect the game world, then it is seen as personal, and if not it is impersonal.

• Access

If a player is allowed access to all scriptons of a game at any time, then the access is random. Or

else if the user has to follow a set series of steps, then it is controlled. An example of this would

be the racing game Need for Speed where players have to complete certain tracks before being

allowed unlock (access) to more cars and tracks. This would mean that the game is controlled.

• Linking

Linking is better described as how players are connected to various activities or locations in the

game; if they have to complete certain conditions before being able to reach other portions of


B‐5

the game. For example, in a game like Splinter Cell, the player is allowed to roam free within a

level, but in order to access portions of level the player is expected to complete certain tasks

that will unlock those portions. The tasks are compulsory, and a player would not be able to

complete the level without first completing the tasks. This would mean that Splinter Cell is

explicitly linked. There are also games that allow players to progress through the game through

a less rigid structure of game play. These games allow players to choose which portions they

want to complete in order to progress. In these games, links can be seen to be conditional.

Seldom do games have a system of no linkage, because challenge is often an essential quality of

a game (Caillois, 1958, p. 65), which more often than not involve the completion of tasks to

reach goals.

• User function

All users take on an implicit interpretive function when playing a game. This is a given, because

interpretation is an integral part of making sense of any system. There are however three other

functions that users can take on: explorative, configurative and textonic. These operate in

relation to a user’s level of interaction within a system:

1. If the game is one of just exploration, the player will take on an explorative function.

2. If the player makes his own story (scripton) along the way by his actions within the game

using available textons, then the function is configurative.

3. Players that can create or add content (textons) permanently to the game are seen as

taking on a textonic function.


B‐6

System Issues Malcolm McCullough in Digital Ground, has proposed a set of 10 “essential functions” (McCullough,

2004 p. 73‐92) for pervasive systems. Bearing in mind that a lot of it is still very much future driven, and

that the functions are a set of guidelines, these 10 functions create a framework for the kinds of

hardware functionality that will make a pervasive system “truly pervasive”. The functions are as follows:

1. Sites and devices are embedded with microprocessors.

This is to say that microprocessors are embedded within interoperable devices that will enable

them operate flexibly and serve multiple functions. McCullough refers to systems that will be

able to communicate with each other at “lower levels” (McCullough, 2004 p. 74), which would

do away with the need for constructing a fully fledged network. This would allow devices to

operate on an intermittent, local level, which is what many pervasive games strive to achieve.

2. Sensors detect action.

A variety of devices are discussed with regards to sensors, from motion detectors to pressure

sensors. It is acknowledged that the most commonly applied sensor is the optical sensor, but

that is not to say that sensors only function on a tactile level. There are a variety of other ways

that systems can “sense” changes in the environment, including Bluetooth and RFID, both of

which can operate with proximity triggers. The main issue is if there are sensors within the game

that detect action, or changes in the environment, and how these then affect the game itself.

3. Communication links form ad hoc networks of devices.

The term ad hoc says volumes about the nature of the networks involved. McCullough talks of

“unplanned communication” (McCullough, 2004 p. 78), devices creating connections opened

only when necessary. This “Adaptive reassignment of locally networked devices” refers to the

use of devices in the context of their surroundings. This then points to the creation of location

specific network devices that operate on small networks; whether the operation within the

network is user controlled, or system triggered is another matter altogether.

4. Tags identify actors.


B‐7

This involves the idea of having a unique tag that will allow participants to be identified on the

personal level. This is of course the source of much contention, with sensitivities with regards to

RFID still very much a focus of attention. Privacy issues aside, this would refer to whether

players are individually identified.

5. Actuators close the loop.

An actuator is a “mechanism that puts something into automatic action”. One of the examples

McCullough uses to illustrate this point is the use of actuators to adjust sunshades in buildings.

This does not mean that the actuator has to be completely hardware driven, because on the

other hand for players in a game, actuators involve changes in the environment that are

external from themselves. McCullough also goes on to say that “participatory adjustment on

daily and seasonal cycles have long been alleged to be more satisfying than those that are

uniform.” (McCullough, 2004, p. 85) So the question then is whether or not the game’s system

makes affordances for actuation on a hardware level.

6. Controls make it participatory.

This discusses how controls affect the way the system may be perceived, thus affecting the

experience that is derived from participation. It looks at whether the controls involve users in a

more physical sense, beyond what is commonly referred to as “window‐icon‐menu‐pointer

(WIMP) technology” (McCullough, 2004, p. 86). This is especially important when creating

experience based systems like games. How do the controls encourage meaningful participation?

7. Display spreads out.

The mobility of the display in a sense is a hallmark of the age of ubiquitous computing. Think of

the scenario in The Minority Report, where advertisements that interact with you are

everywhere. Any space becomes a display in pervasive computing. Although at present the

technology is limited, this makes reference to mixed reality, and how we combine virtual reality

with physical reality. How does the game create a kind of traveling interface?

8. Fixed locations track mobile positions.

The notion of being able to identify users was discussed earlier in point number 4, but this takes

the technology beyond the point just of just identifying users, but rather it involves tracking the


B‐8

position of these users. At present, examples of these forms of tracking are available in the form

of GPS devices, and even the tracking of mobile phones. Again, this opens up another can of

worms with regards to privacy. Services are already being offered that allow mobile users to

track each other’s position without the knowledge of the other party (Lightman, 2002, p. 80).

But how else do the games track positions of their users?

9. Software models situations.

“Who is here and what are they doing?” (McCullough, 2004, p. 91) is the key issue with

modeling situations. The construction of a system that will be able to function on a location

based context involves being able to create “intelligent” systems. Such systems are still not fully

developed due to technological constraints, but how does the game create the illusion of

contextual awareness with the hardware involved?

10. Tuning overcomes rigidity.

The notion of tuning comes from the need to create more flexible systems that will be able to

adapt to the changes that might take place during the course that a system is implemented or if

the system needs to be implemented in another location. McCullough proposes 3 questions

when discussing tuning: “How are new devices added? What model underlies the world in which

all of these interoperate? Must the whole system be rebalanced each time it incorporates

another element?”(McCullough, 2004, p. 92). These questions make us question the nature of a

system’s flexibility, which has a profound effect on location based games, because it will

determine how a game may be moved from location to location or expanded to include more

locations. If small tweaks would be enough to allow the system to be transplanted, or if

additional devices can be easily added to facilitate an expansion of player base.


B‐9

Analysis Compilation The rules cover a wide range of features within the game, and analysis of the rules as such may not

produce results that can be automatically categorized or classified. As such, the rules have to be broken

down even to even smaller pieces in order to gain clearer insight into each game’s inner workings.

Going back to the definition of a game, Greg Costikyan dissected a successful game into 6 key factors:

decision making, goals, opposition, managing resources, game tokens and information (Costikyan, 2006,

p. 196 ‐ 202). Additionally, he also had a list of other things that helped to strengthen games, one of

which was socializing, which correlates with the social factor that designers of location based games

have a particular interest in (Benford, 2005c pg. 54). Socializing, as Costikyan puts it, is “how the system

encourages or discourages socialization” (Costikyan, 2006, p. 208).

Player role as well as system issues will be addressed using the categories already assigned to them

within the taxonomies. In order to create a clearer image of how the each game is represented after

being dissected, all the results will be tabulated together, so that all the games can be compared side by

side.

The results will then be discussed, with each item discussed in terms of all 5 games. It is from the

discussion that the main issues that lie in the will be fleshed out, allowing parts to be picked or improved

upon in the creation of a location based game that attempts to address the pertinent issues.


B‐10

CYSMN FIASCO CQ GC HP Decision making Y Y Y N Y Goals Y Y Y Y Y Opposition N Y Y N Y/N Resource Management

N Y Y N Y

Tokens N Y Y Y Y Information Y Y Y Y Y Socializing Y Y Y Y Y Dynamics IDT TDT IDT TDT IDT Determinability indeterminate indeterminate indeterminate indeterminate indeterminate Transiency transient transient transient transient transient Perspective personal personal personal personal personal Access controlled controlled controlled controlled controlled Linking none conditional conditional conditional conditional User Functions configurative textonic configurative textonic configurative Sites and devices embedded with microprocessors

Y (temporary) N Y N Y (temporary)

Sensors detect action Y Y Y N Y Communication Links form ad hoc networks

N N Y N N

Tags identify actors Y Y Y Y Y Actuators close the loop

N N N N Y

Controls make it participatory

N Y Y Y Y

Display spreads out N N Y N Y Fixed locations track mobile positions

Y Y Y Y Y

Software models situations

Y Y N Y N

Tuning overcomes rigidity

N Y Y Y N

Legend Rules Player Roles System Issues


B‐11

Decision Making Every one of the games looked at feature decision making of some sort or another. The rules support

decision making by implementing goals, creating opposition, giving players the opportunity to manage

resources, and giving the player information on the game state.

Costikyan differentiates decision making from interaction by stating that making a decision involves

interacting with a purpose (Costikyan, 2006). This could mean interacting with objects in the game, or

with fellow players. How the games create interactions that are purposeful are by creating interactions

that will have an impact on the player’s state in a game, whether it’s as an individual player (CYSMN,

FIASCO, GeoCaching), or within a large team context (Conqwest, Human Pacman).

Goals

Each game has its ultimate goal delineated as part of the rules, which give the player something to work

towards. CYSMN’s goal is simply for players to not get caught for the duration of the game, in Conqwest

the goal is simply to reach 5000 points in order to win the cash prize, and in Human Pacman, the player’s

goal is to consume all the cookies in the space. These are all very definite goals that define when the

game will come to an end.

There are also games where the goal is does not prescribe a fixed end, rather creating a series of

challenges for players that can go on in a perpetual manner. FIASCO’s goal is for players to increase the

size of their territory, GeoCaching’s goal is for players to locate as many caches as they possibly can, but

neither state when someone is has won the game or when the game is ultimately over. There is a sense

that these games will go on indefinitely as long as there are participants. These can be put into the

category of persistent games, or one that is permanently in operation (Bateman, 2006, p. 173).

A feature that all games share is that they allow players to work towards a goal that represents a

quantifiable outcome. It is from these quantifiable outcomes that players derive the pleasure of playing

a game (Salen, 2004, p. 238).

Opposition


B‐12

As discussed earlier, all games need to incorporate some form of opposition or another in order for it to

qualify as a game, whether the opposition is from the system, or from the other players.

CYSMN incorporates human system agents against players, FIASCO has players playing against each

other, similarly in Human Pacman players compete against players and Conqwest pits team against team,

all in the pursuit of quantifiable outcomes as discussed in Goals. The nature of these games is that they

make use of direct opposition in order to create player tension (Salen, 2004, p. 250).

With the exception of FIASCO and GeoCaching, the other games involve players competing for resources

that will affect the state of play, thus effectively defining a winner. FIASCO despite being a persistent

system with no definite end incorporates the appropriation of territory, thus creating direct conflict for a

piece of turf.

In GeoCaching however, players do not compete for the availability of resources, instead they compete

for a rating from finding a cache. It is not an integral part of the game, and players do not necessarily

have to achieve a certain score in order to continue playing. As such, players do not face opposition with

each other per se; rather they find themselves challenged by the system which requires them to

navigate in order to find the hidden cache.

Managing Resources CYSMN, FIASCO, Conqwest and Human Pacman all feature resource management as part of the system.

In these games, the resources are a means by which players work towards a final goal in the game.

CYSMN and FIASCO involve the use of space as the main source of conflict, whereas Conqwest has

money or credits as a resource, which can be used when teams fight it out for territory. Human Pacman

has a variety of resources that can create conflict or cooperation between players, such as cookies,

“magic cookies” or “lives”. For example a Pacman struggling to maintain a certain number of “lives”

would feel a greater sense of tension against a ghost who is looking to deprive the player of it.

Again, Geocaching is different in that it does not require players to manage resources that affect the

state of the game in a directly or in an immediate fashion. This lack of tension from managing resources

is another aspect that leads to players not having to participate in the game competitively. There are


B‐13

resources to be managed, namely the cache, but there isn’t enough tension between players over that

resource to foster a sense of competition.

Tokens

Each game involves the player in manipulating tokens of some sort. The act of manipulating the tokens

is often central to the game, and not just encouraged by the rules, but plays a part in the way the game

operates as well.

The use of tokens is the one thing that is uniform throughout all the games without exception. Players

need to have an aspect of the game that they can manipulate in order to feel connected to go the game.

CYMSN, given that players are managing space, their virtual characters act as the token, not unlike the

way a piece acts as a token in a board game (Costikyan, 2006, p. 200). Even in Geocaching, which does

not have resources to manage involves the player in manipulation of the contents of the cache as well as

the log book.

Information

The use of information in all the games is straightforward enough. The rules themselves are a form of

information that set up a context that players can use to decipher the feedback they get from the game.

During the course of the game, the rules stipulate the flow of information, for instance the use of the

text based messaging system and walkie talkies in CYSMN, and in web based games like FIASCO and

Geocaching, information is made available on their respective websites.

The rules also affect how players perceive information. For example in Human Pacman the rules dictate

how players will be informed of the location of the “magic cookie” by creating a variable beeping sounds

in relation to the player’s proximity to the cookie.

Socializing

While the rules cannot force players to socialize, it does affect the way players communicate, or

exchange information as mentioned previously, therefore the rules can be seen as either encouraging or

discouraging social behavior (Costikyan, 2006, p. 208).


B‐14

CYSMN with its text based communication does allow users to communicate but because of the game’s

intense chase‐style game play, the dialogue between players may be limited to interactions with regards

to the game due to constraints created by game tension.

FIASCO, Conqwest and Human Pacman all promote a more tangible form of social interaction by giving

participants the opportunity to meet face to face. This is especially so in the case of Human Pacman,

where actual physical contact is encouraged by the game. FIASCO claims to encourage interaction

between players by intentionally implementing a “partial lack of control” (Chang, 2004b, p. 4) as to how

players can use the system. It merely acts as a conduit for player interaction.

At the heart of Geocaching is another means of communication between players. One of the key aspects

of being able to locate a cache lies in being able to commit to creating meaningful dialogue with fellow

players in a form of mutual dependency. The hiders have to provide information for finders who provide

feedback. Each cache has a forum of its own that allows finders to discuss the details of the search and

provide feedback for the hider. This mutual dependency that creates bonds within players (Bateman,

2006, p. 232 ‐ 233), and coupled with the game’s persistent nature allows for greater opportunities for

community building than any of the other games.

Dynamics

All games fall under the category of being dynamic, because of they all center on human interaction.

Therefore at the lowest level, the games are intratextonic because the way that players interact with

each other forms the game. Comparing the games in terms of dynamics, it becomes clear that the

games with the greatest levels of persistence allow players the opportunity to contribute on a textonic

level. CYSMN and Human Pacman are both games that last a few hours, and Conqwest is a day long

event, but FIASCO was run over a longer duration of time, and Geocaching is still in play.

Transiency

The games are all transient, although the intensity of change within a span of time is again affected by

the duration of the game: the shorter a game the greater the change from moment to moment. This can

be seen in the example of CYSMN where player turnover is so rapid that they can be put back on a

queue if they are removed from the game.


B‐15

Perspective

Because location based gaming requires users to contribute to the system, all of the games involve

players in a personal manner.

Access

Because location based games deal with movement in a physical space, all access is limited to

movement though a series of paths. Even if the movement is “virtual” like in CYSMN, it is bounded by a

fixed speed as well as a virtual model of the city. This means that players have to fulfill the condition of

movement before being able to access scriptons.

Linking

All the games with the exception of CYSMN involve the player in conditional linking. It can be seen as

such because despite having a series of set tasks to perform, there is no fixed stage structure that would

cause explicit linking to be necessary. There are no set triggers that will activate other actions. CYSMN is

different in that it does not have a set of tasks for the player to perform. The player is working towards

survival in a game that is time based, and how the player goes about reaching that goal is not affected

by any factors implemented within the system. Explicit linking would not serve as well as conditional

links because they restrict the player too much, because the implementation of such links would “force”

players to perform certain actions that do not necessarily agree with them, especially if they have to

perform the actions in reality.

User Functions

As mentioned previously players all interact with each other to form the game, and because of that the

games are all dynamic, resulting in 2 predominant forms of user function: textonic and configurative.

That is not to say that there is always a direct correlation between user function and dynamics, rather it

is a result of analyzing games of a similar genre, specifically dealing with mediated human interaction.

FIASCO and Geocaching were designed around a less restrictive set of rules that allow users freedom of

interaction with each other as well as contribution to the system, which is reflected in the creation of


B‐16

stunts and caches respectively. This means that textons can be freely generated by users and added to

the system.

The other games although also promoting player interaction, find themselves working within the

constraints of time and location. All of them are tied down to a smaller space, and operate within a

shorter time span, which limit the ways that users are allowed to interact with each other as well as how

much they can contribute to the system.

Sites and devices embedded with microprocessors

CYMSN and Human Pacman require that sites be specially prepared before the games can take place.

The technology required has to be installed beforehand and removed once the game is completed. This

is of course disadvantageous because it means that it will be difficult to implement on a large scale. Both

games also require that the human elements have to be specially equipped in order for the game to be

operational. In the case of CYSMN, it’s the GPS equipped PDAs and in Human Pacman it’s the backpack

of equipment.

Conqwest works around this by making use of GSM networks that already exist as well as mobile phones.

This gives them the flexibility of possible redeployment without having to reprogram the entire system,

or set up complex hardware beforehand.

Sensors detect action

With the exception of Geocaching and FIASCO, the other games employ sensors that can report back to

the system from the location. Geocaching does employ sensors in the form of GPS units, but the player’s

movements are not reported back to the system from the location itself. Similarly, FIASCO requires users

to take pictures and upload them, but the action is not captured by the system at the time of

performance, and at the location. In Conqwest, sensors are embedded within devices in the form of a

camera, and are user activated, but can only operate when present within the designated space.

Communication links form ad hoc networks

The only system that explicitly made use of ad hoc networking was Conqwest, aided by the use of

mobile phones. This allowed users to join and leave the network as required. There are opportunities for


B‐17

ad hoc networks to be used in Geocaching and FIASCO as well, but they have not been prescribed by the

system, and are hence a matter of player choice. For example, a finder in Geocaching might decide to

bring a laptop along during the search, and upon finding the cache immediately connect to the internet

and report the find.

Tags identify actors

This is a compulsory component of the systems, because they are games, and only through identification

can players be scored accordingly.

Actuators close the loop

There is often the issue of intelligent actuation within all the games except for Human Pacman. The use

of an automated system that detects locational changes requires that the location is specially prepared,

as with the Bluetooth devices in Human Pacman. Conqwest employs a form of player governed

actuation, by allowing players to control when information is sent out.

Controls make it participatory

All the games except for CYSMN put the players physically within a location. This is not to say that

CYSMN was not a participatory experience, but it resulted in the lack of having the tactile sense of being

within a space.

Display spreads out

Only Human Pacman and Conqwest offer displays that spread out over an environment, but in both

cases the display is not within the environment, but carried along with players. The use of mobile

phones in Conqwest makes it a more sensible choice when deploying such systems, although Pacman’s

set up allowed for greater interaction and realism.

Fixed locations track mobile positions

All the games employ a central server that allows positions to be tracked. This is often a result having a

game in which positions of players can be tracked during movement, like in CYSMN or Human Pacman,

or when positions of players are reported at certain points and can be verified by the system or other

players. This can be seen in the use of photographic evidence in FIASCO, or the confirmation of the


B‐18

locations of caches by other players in Geocaching. Similarly, Conqwest has pre‐deployed tags that the

designers have mapped out. By finding these tags and reporting back to the system, their locations can

be tracked.

Software models situations

The software in the all the games were built around the concept that they would function as games, but

none are intelligent enough to contextualize situations without human intervention.

Tuning overcomes rigidity

The games can all be tuned, however in the case of CYSMN and Human Pacman, because of the

explicitly location dependent nature as well as the intense nature of gaming, it is not possible to tune

the game during the course of play. The location sensitivity also means that when the system is moved

from location to location, therefore more problems may be encountered as a result of possibly vastly

different physical locations

Appendix C


C‐1

TASK 1 What do you think Cipher Cities is about? Participant Time:mins Observations Comments 1

4:44 Aware that it is a kind of online game, however there is confusion as to site’s purpose. Head moved closer to screen. Baffled appearance at times.

Possibility that fonts are too small indicated by leaning forward. Not enough elaboration on the site’s purpose on main page alone.

2

1:04 Confused about the purpose of the site. Said it was about “Live situations and finding ways around”. Only had a quick look at the front page.

3

3:30 No idea at all. “It is a game.” See background questionnaire.

4

6:43 Location based games (“seems to have something to do with…”) Not entirely sure.

5

1:18 Socializing online games. Teams and group work within games. Have to sign up.

From this point this has been revised so they only see limited pages.

6

0:13 Gaming, community based online gaming.

7

1:04 Games, website, discussion forums.

8

0:54 Multiplayer gaming, Social interaction, community

9

0:49 Games, interactive games, community

* highlighted is the median Mean time to complete: 2:15 min Fasted time to complete: 0:13 min Slowest time to complete: 6:43 min Standard deviation: 2:12 min


C‐2

TASK 2

Go to registration page and fill in questionnaire. Participant Time (mins) Observations Comments 1

4:04 Missed “Next” button. Did not go through registration sequentially. Did not quite understand the concept of “Email” and “Mobile” in step 2 of registration.

Next button perhaps not sufficiently obvious.

2

4:55 No issues with navigating. Did not quite understand the concept of “Email” and “Mobile” in step 2 of registration.

3

3:20 No issues with navigation Did not quite understand the concept of “Email” and “Mobile” in step 2 of registration.

4

6:35 No issues.

5

3:10 Did not quite understand the concept of “Email” and “Mobile” in step 2 of registration. Described the 2 instead of saying they were to enter a code.

6

3:48 Unsure of what “Verification code” means.

7

4:05 Those “email” in step 2 referred to “personal email”.

8

2:50 Tried to click step numbers on top of page. Did not quite understand the concept of “Email” and “Mobile” in step 2 of registration.

9

2:05 Did not quite understand the concept of “Email” and “Mobile” in step 2 of registration.

* highlighted is the median Mean time to complete: 3:52 min Fasted time to complete: 2:05 min Slowest time to complete: 6:35 min


C‐3

Standard deviation: 1:19 min


C‐4

TASK 3

Go back to home page and fill in questionnaire. Participant Time (mins) Observations Comments 1

4:56 Had to go back and forth to determine what things were. Confusion as to meaning of “Creation List” “Groups” was not sufficiently telling to the participant that those were the groups joined.

Possibility of too much complexity being introduced to users at this stage.

2

5:04 No issues here.

3

6:23 A lot of confusion in site navigation and terms in home page. (Started stressing about meanings etc) Unsure of all terms except for “Team mates”

Again see background questionnaire.

4

11 No issues.

5

3:08 “Game Creator” seen as person who “defined the concept” “Team Mates” seen as people in “your group”

6

3:20 “Games played” seen as history. “Games made” no idea. “Play list” not sure. “Creation list” newest games... a bit vague.

7

2:38 No issues.

8

3:14 “Game Creator” thought to be “author of specific games. “Play list” seen as “music you listen to”. Creation list seen as series of games you have played. Groups seen as “groups you sign up with in different games”

9

2:40 Game Creator “info about people that have created the game”


C‐5

Didn’t understand creation list. “Something to do with game creator”

* highlighted is the median Mean time to complete: 8:49 min Fasted time to complete: 2:38 min Slowest time to complete: 11 min Standard deviation: 2:41 min


C‐6

TASK 4

Find page to update user profile. Participant Time (mins) Observations Comments 1

1:23 Couldn’t find it initially. Repeatedly attempted to click on user image.

User supposed to be able to access page by clicking user image, however it was not available in this prototype.

2

0:33 Some trouble locating the page. This was due to issues with linking in the prototype.

3

0:22 Had small problems. Had to look around abit.

4

0:45 Small problems locating the page, but generally okay.

5

0:55 No issues. Participants informed that their avatar is the cartoon creature.

6

0:14 Found it after some looking.

7

0:19 No issues.

8

0:22 No issues.

9

0:15 No issues.


Task Accuracy % of participants performing successfully:

• within time allotted: 100% • Regardless of time: n/a • Regardless of time including people who needed help: n/a


C‐7

TASK 5 Add or remove notices from the notice board on home page. Participant Time (mins) Observations Comments 1

0:10 No issues here. Participant commented that it would be good if two notice boards were available for friends and general public.

None.

2

1:15 Did not see notice board at first, and went into the message system.

3

0:06 No issues.

4

0:18 Delay in finding notice board.

5

0:22 Went to messages first.

6

0:07 No issues.

7

0:07 No issues.

8

0:15 No issues.

9

0:05 No issues.



C‐8




C‐9

TASK 6 Send a message. Participant Time (mins) Observations Comments 1

0:08 No issues. Commented that “after a few times you should be used to it.”

2

0:04 No issues.

3

0:12 No issues.

4

0:23 Good. No issues.

5

0:10 No issues.

6

0:04 No issues.

7

0:05 No issues.

8

0:23 Clicked on person’s picture to send a message.

This is not wrong.

9

0:15 No issues.



C‐10




C‐11

TASK 7 Locate the game “Mystery of the giant purse” Participant Time (mins) Observations Comments 1

0:08 No issues.

2

0:07 No issues.

3

0:11 No issues.

4

0:14 No issues.

5

0:30 Scrolled around page but eventually found the link. Other than that, no issues.

6

0:07 No issues.

7

0:04 No issues.

8

0:11 No issues.

9

0:14 No issues.



C‐12




C‐13

TASK 8 Join the game. Participant Time (mins) Observations Comments 1

0:04 No issues.

2

0:07 No issues.

3

0:11 No issues.

4

0:03 No issues.

5

0:03 No issues.

6

0:04 No issues.

7

0:03 No issues.

8

0:05 No issues.

9

0:06 No issues.



C‐14




C‐15

TASK 9 Upload a snapshot. Participant Time (mins) Observations Comments 1

0:06 Very quick. No issues.

2

0:13 Easy. No issues.

3

0:14 No issues.

4

0:06 No issues.

5

0:31 Went to view snapshots instead.

6

0:53 Ok.

7

0:31 Small amount of confusion, but found it eventually.

8

0:14 No issues.

9

0:42 Went back to home page, but later it became clear to her.

* highlighted is the median Mean time to complete: 0:23 Fasted time to complete: 0:06 Slowest time to complete: 0:42 Standard deviation: 16.57757


C‐16




C‐17

TASK 10 Add a notice to the game. Participant Time (mins) Observations Comments 1


2

0:08 With ease. No issues.

3

0:16 No issues.

4

0:03 No issues.

5

0:08 No issues.

6

0:03 No issues.

7

0:06 No issues.

8

0:05 No issues.

9

0:03 No issues.

* highlighted is the median Mean time to complete: 0:08 Fasted time to complete: 0:03 Slowest time to complete: 0:03 Standard deviation: 6.291302


C‐18




C‐19

TASK 11 Look at game creation and fill in the questionnaires. Participant Time (mins) Observations Comments 1

4:49 Had to be shown how to move between steps by pressing the “Next” button. Broke the page by clicking too quickly. Concept of “X” not obvious enough. He thought it was to close the node. Saw node as “add another title”.

“Next” button is too small.

2

8:39 Some problems with terminology. “No idea what node is”

3

5:35 Unable to describe what a “node” is.

4

13:45 Except for “Race” and “Open” games, participant gets it completely after thoroughly reading the descriptions on the right of the screen. Description for “Race” and “Open” games not sufficiently clear.

Descriptions are close to development team’s own definitions. See questionnaire.

5

5:05 Location taken as “current place you are in” “Not sure” what node is, and consequently the whole concepts around nodes. X seen as don’t do something.

6

4:32 “No idea” what node or node info are.

7

5:35 Location seen as meaning “my own country”“Node” seen as “put something on front page – notify a forum or game list.

8

4:53 Location and city seen as where the author reside. “Node” seen as start point of map

9

4:53 “Node” is seen as “description of a game about checkpoint.” “X” seen as close boxes.

* highlighted is the median


C‐20

Mean time to complete: 6:25 min Fasted time to complete: 4:32 min Slowest time to complete: 13:45 min Standard deviation: 3:00 min


C‐21

TASK 12

Locate page for revising game. Participant Time (mins) Observations Comments 1

0:25 No issues.

2

1:05 Found it and skipped it before going back to it.

3

1:45 Had trouble noticing icon.

4

0:19 No issues.

5

1:08 Taking time to find. Went to list of games.

6

1:43 Few problems finding the link back to page.

7

0:31 Some small problems. Did not notice icon at first.

8

1:14 Went to “game list to look to revise game” Remarked “Same pages isn’t it?” Eventually found the page.

This was probably because games created and game list consisted of the same games.

9

0:42 No issues.



• within time allotted: 45% • Regardless of time: 55%


C‐22

• Regardless of time including people who needed help: n/a


C‐23

TASK 13 Delete a game you have created. Participant Time (mins) Observations Comments 1

0:14 Good. No issues.

2

0:35 Had some trouble noticing the button, but found it in the end.

The page was broken at the time, therefore the button was not displayed exactly where it should have been.

3

0:30 No issues.

4

0:07 No issues.

5

0:08 No issues.

6

0:08 No issues.

7

0:08 No issues.

8

0:05 No issues.

9

0:04 No issues.



C‐24




C‐25

TASK 14 Find a place where you can find people to play games with. Participant Time (mins) Observations Comments 1

0:19 Problem with the concept. Tried to join a game.

This is probably a result of the phrasing of the question.

2

0:13 No issues.

3

0:08 No issues.

4

0:06 No issues.

5

0:10 No issues.

6

0:09 Went to groups page.

7

0:02 No issues.

8

0:14 No issues.

9

0:06 No issues.



C‐26




C‐27

TASK 15 What is this group about? Participant Time (mins) Observations Comments 1

0:35 A little confused, but was guided by question.

This problem was inherited from previous question.

2


3

0:52 Gave up. Possibly because the group’s “about” was gibberish.

4

0:04 Gave up. See above.

5

0:11 No issues. Question was rephrased.

6

0:05 No issues.

7

0:08 No issues.

8

0:07 No issues.

9

0:03 No issues.



C‐28


• within time allotted: 78% • Regardless of time: 11% • Regardless of time including people who needed help: 11%


C‐29

TASK 16 Join the group. Participant Time (mins) Observations Comments 1

0:08 No issues.

2

0:05 No issues.

3

0:15 No issues.

4

0:15 No issues.

5

0:08 No issues.

6

0:04 No issues.

7

0:06 No issues.

8

0:03 No issues.

9

0:08 Missed the link at first.



C‐30




C‐31

TASK 17 Start a discussion in the group. Participant Time (mins) Observations Comments 1

0:20 No issues.

2

0:24 A little bit of problem finding link.

3

0:32 Went to the forum.

4

1:31 Problems finding forum but knew what to look for.

Possibly because of question phrasing.

5

0:08 No issues.

6

0:03 No issues.

7

0:15 No issues.

8

0:08 No issues.

9

0:11 No issues.



C‐32


• within time allotted: 77% • Regardless of time: 22% • Regardless of time including people who needed help: n/a


C‐33

Preference levels These are subjective measures of the Cipher Cities interface taken after the test, with 1 being the best and 7 being the worst. Qn1 Simple…………….….…3…2…1…0…1…2…3………Complex Qn2 User Friendly……..…3…2…1…0…1…2…3………Not User Friendly Qn3 Well Organized…….3…2…1…0…1…2…3………Messy Qn4 Safe………………..….…3…2…1…0…1…2…3………Unsafe Qn5 I like………………..……3…2…1…0…1…2…3………I Dislike (1)(2)(3)(4)(5)(6)(7) Post test Questionnaire Qn1 Qn2 Qn3 Qn4 Qn5 P1.1 2 2 2 2 2 P1.2 2 2 1 1 2 P1.3 5 2 2 1 1 3.666667 2.555556 2.888889 3 2.555556


C‐34

Post test Questionnaire In addition to their preference levels as seen above, the post test questionnaire also had a series of questions that were designed to confirm some of the issues that we hoped to address with this iteration of the interface. Some of these issues are less obvious and might not have been obvious just by documenting their performance of tasks, while there was a need to confirm some of the others that were critical to the performance of the system. Many of the comments made by participants serve to reinforce the results of main portion of the test. Q1 Cipher Cities has made the concept of location based gaming clearer to me.

Strongly Disagree Disagree Neither Agree Strongly Agree

P1 1 P2 1 P3 1 P4 1 P5 1 P6 1 P7 1 P8 1 P9 1 TOTAL 1 2 6 Participant comments: P1 “Emphasis on location.”

P2 “I have a basic idea of what they are about as I didn't really know anything about them before I

came in.”

P3 “Still not 100% sure but definitely a little clearer.”

P5 “Location aspect was not emphasized.”

P6 “Still unclear what sort of games site deals with. What is the connection to mobiles? Is it web games or phone games?”

P8 “Need a "about us" page.”

P9 “I had a little knowledge beforehand, but Cipher Cities has made the concept clearer to me.”


C‐35

Q2 Overall, I found the site easy to navigate.


P1 1 P2 1 P3 1 P4 1 P5 1 P6 1 P7 1 P8 1 P9 1 TOTAL 1 2 6

Participant comments: P1 “Too many repetitive links. Have to include more head sections/links.”

P2 “Once all the links work it will be easy, and it is like most sites where as you around and explore

you will find out more.”

P3 “Very busy but you'd get used to it.”

P5 “Some important links could have been more noticeable.”

P6 “Most of the site was easy. Editing profile was difficult. Didn't like having to guess it might be by clicking on avatar.”

P7 “There is an initial learning curve (all websites do) but it is not difficult to "master" the navigation of the site.”

P8 “With the exception for editing a created game. (needs to be highlighted).”

P9 “I had a little trouble at some point but the descriptions on the right hand side on some pages helped.”


C‐36

Q3 The pages of the site are well organized.


P1 1 P2 1 P3 1 P4 1 P5 1 P6 1 P7 1 P8 1 P9 1 TOTAL 2 6 1

Participant comments: P1 “There is a flow.”

P2 “The main info is always at the top and the layout is consistent throughout.”


C‐37

Q4 I could complete the registration process without much difficulty.


P1 1 P2 1 P3 1 P4 1 P5 1 P6 1 P7 1 P8 1 P9 1 TOTAL 1 3 5

Participant comments: P2 “They are straightforward questions which are similar to everything on the web. They are known

terms.”

P3 “Would need more assistance.”

P7 “Provided I read the instructions.”


C‐38

Q5 It is easy to locate and join a game.


P1 1 P2 1 P3 1 P4 1 P5 1 P6 1 P7 1 P8 1 P9 1 TOTAL 1 6 2

Participant comments: P2 “Fairly straightforward and easy.”

P3 “Not for me but I would never go on a site like this and I don’t play computer games.”

P9 “Once I got a feel for the website, certain functions became clearer to me.”


C‐39

Q6 I was able to understand the process of game creation.


P1 1 P2 1 P3 1 P4 1 P5 1 P6 1 P7 1 P8 1 P9 1 TOTAL 1 1 7

Participant comments: P2 “It was set out in easy steps. I just didn't know what a node was but I would as soon as I had

played games.”

P3 “Didn't actually get to do it so no.”

P6 “Not sure what it is I just created.”

P8 “Without knowledge of what a "node" is it was difficult to grasp the intention of the creation page.”

P9 “Again at first I didn't understand but then using the website and reading infor provided I was able to understand the processs of game creation.”


C‐40

Q7 I was able to find and join a group.


P1 1 P2 1 P3 1 P4 1 P5 1 P6 1 P7 1 P8 1 P9 1 TOTAL 1 4 4

Participant comments: P2 “Very similar to other web based groups.”

P3 “I needed help.”

P6 “Nice simple system.”


C‐41

Q8 This site would encourage me to participage in games.


P1 1 P2 1 P3 1 P4 1 P5 1 P6 1 P7 1 P8 1 P9 1 TOTAL 1 2 3 3

Participant comments: P2 “I find that I want to explore it a bit more now.”

P3 “No interested.”

P6 “But what games will I be playing?”

P8 “I'm not really into games, so even though it looks interesting, I probably still wouldn't want to

participate.”


C‐42

Q9 This site would encourage me to create games of my own.


P1 1 P2 1 P3 1 P4 1 P5 1 P6 1 P7 1 P8 1 P9 1 TOTAL 2 3 2 2

Participant comments: P2 “I think as soon as I knew the system and had played a few games I would want to create my

own ‐ the other side of gaming.”

P3 “Don't play computer games.”

P6 “Personalize games. Very interesting.”

P8 “Tutorial page for slow learners.”

P9 “As I said before I don't have a strong interest in gaming.”


Appendix D


D‐1

C1 Group C2 Individual in room C3 Individual on location C4 Individual alone


D‐2

Game creation steps G1 G2 G3 G4 G5

1 Location assigned

Location assigned

Location assigned

Location selection and theme/purpose

Location selection and theme/purpose

2 Identifying potential checkpoints

Deciding on checkpoints

Marking checkpoints and pathing

Choosing checkpoints

Preselecting potential checkpoints

3 Assigning roles

Deciding on a way to connect the checkpoints

Creating clues

Input and clue creation

Finalizing checkpoints, making hints and pathing

4 Deciding on a path

Creating in depth clues

Input and Theme creation

Input and clue checking

5 Coming up with a concept

Development of selected concept

*For more detail on each step refer to the appendix Given that G1 to G3 built games at a location that was specified to them, they actually were able to skip a step that G4 and G5 had to undergo. This missing step is made up for in italics.


D‐3

Game Builder Interface

Step 1 G1 No issues encountered.

G2 The brief description was too brief. This detracted from the whole theme they built up

while coming up with ideas for the game.

G3 Missed the Global/Local option which he felt should be on the next page, because he thought the first step was for descriptive purposes.

G4 Missed the Global/Local option. He was confused about what it meant.

G5 No issues encountered.

Step 2 G1 Suggested that maybe there was no need for a start time to be assigned to an open game

because there was no competition factored in.

G2 They used the instructions to help players orientate themselves to how the game will be played.


G4 Confused by the Game start date, thinking that it referred to when he went to walk the ground. Start time thought to meant duration of game. He left the minutes unselected.

G5 Chose invite only option because she felt the game would only be for students of the school. Did not assign equipment because she felt it was up to the students.


D‐4

Step 3 G1 Minor issues included being unsure if fields were case sensitive, and if full stops in the

answers fields would affect how the player answered.

G2 Case sensitivity was brought up. They wanted to know if answers were case sensitive. When a page is completed, users should be able to go back and forth by just clicking on the page number instead of going back and forwards. There was no limit displayed form the completion message, so they wrote a really long one.

G3 He felt that there should be an option to save and come back at another time to continue. He assumed that players would be sent the title as well as the question. This was because of the way that the fields were labeled.

G4 Successfully deleted and added checkpoints. (there is still an issue with coloration) Missed the completion message saying it wasn’t obvious enough.

G5 Successfully deleted and added checkpoints. (there is still an issue with coloration) No issues adding and deleting hints. Felt that there should be an indication of what the player will and will not see.


D‐5

Step 4 G1 They found it entertaining to go through the game they made.

A major issue was that when doing a test run of the game, they had to go back to edit portions of the game, and then when they came back to the test screen they had to go through the entire series of steps again to reach the last step they left off at.

G2 They felt it would be good if messages sent to the player indicated if they were clues or a question for a new checkpoint. They also thought it would be good to indicate to the player which clue they are on.


G4 Was not aware that answers were case sensitive. Completion message should be displayed as well.

G5 Felt it would be better if builders could select the hint from the list rather than go through all the steps again. When testing game the “enter” key should act as the reply button, so that less clicking would have to be done.


D‐6

Step 5 G1 They initially overlooked the presence of the poster and had to be guided to it.

G2 They did not look at the game poster initially, although one member did indicate that he

noticed the link.


G4 Noticed the game poster.

G5 Noticed the game poster but didn’t feel need to view it.


D‐7

Preference levels These are subjective measures of the Cipher Cities interface taken after the test, with 1 being the best and 7 being the worst. The results show that the site has been well received by the participants and is viewed in a positive light. Qn1 Simple………………..…3…2…1…0…1…2…3………Complex Qn2 User Friendly……..…3…2…1…0…1…2…3………Not User Friendly Qn3 Well Organized…….3…2…1…0…1…2…3………Messy Qn4 Safe………………………3…2…1…0…1…2…3………Unsafe Qn5 I like…………….....……3…2…1…0…1…2…3………I Dislike (1) (2) (3) (4) (5) (6) (7) Qn1 Qn2 Qn3 Qn4 Qn5 G1.1 2 2 2 2 2 G1.2 2 2 1 1 2 G1.3 5 2 2 1 1 G2.1 2 1 1 1 1 G2.2 2 2 3 4 2 G2.3 1 1 1 1 1 G3 1 1 1 4 1 G4 3 2 2 2 2 G5 2 2 2 2 2 Mean: 2.134 1.706 1.668 2.266 1.6


D‐8

The post test questionnaire contains series of questions that were designed to further investigate some

issues that may not have been obvious enough through monitoring the way participants interacted with

the system.

Q1 I found it easy building my own game.


G1.1 1 G1.2 1 G1.3 1 G2.1 1 G2.2 1 G2.3 1 G3 1 G4 1 G5 1 TOTAL 1 6 2

Participant comments: G1.1 “It was fun to organize!”

G1.2 “Both easy and difficult – At first my ambitions were bigger than time and working 2

uncooperative children allowed. But I’m pleased with the result.”

G1.3 “I was not entirely uninitiated.”

G2.1 No comment.

G2.2 No comment.

G2.3 “On one hand it is easy to create an overall game + feel for it, etc., it is not that easy to think of all the little things that link one place to the next.”

G3 No comment.

G4 No comment.

G5 No comment.


D‐9

Q2 The game builder is well structured.


G1.1 1 G1.2 1 G1.3 1 G2.1 1 G2.2 1 G2.3 1 G3 1 G4 1 G5 1 TOTAL 6 3

Participant comments: G1.1 “Visual aids (mapping) would make it easier. But it was very useful.

G1.2 “It’s great.”

G1.3 No comment.

G2.1 No comment.

G2.2 “I think there should be more info provided about “What is an SMS based game.”

G2.3 “Neat +well presented. User friendly.”

G3 No comment.

G4 No comment.

G5 No comment.


D‐10

Q3 I can understand the process of building a game.


G1.1 1 G1.2 1 G1.3 1 G2.1 1 G2.2 1 G2.3 1 G3 1 G4 1 G5 1 TOTAL 9

Participant comments: G1.1 No comment.

G1.2 “After the process, yes! I’d like to have more time to think about it though.”

G1.3 No comment.

G2.1 “It would be difficult to understand what type of game you can build without first seeing an

example.”

G2.2 “But I think there should be more of a “hold my hand” approach on the website… maybe even a walk‐thru of how someone else made one…”

G2.3 No comment.

G3 No comment.

G4 Add in more instructions and checkpoint allowances.

G5 No comment.


D‐11

Q4 Building my own game was an enjoyable process.


G1.1 1 G1.2 1 G1.3 1 G2.1 1 G2.2 1 G2.3 1 G3 1 G4 1 G5 1 TOTAL 1 5 3

Participant comments: G1.1 “It is interesting to incorporate intellect and enjoyment in a creation.”

G1.2 “Except for the distractions of young kids.”

G1.3 No comment.

G2.1 No comment.

G2.2 “Good fun… there’s heaps of potential and it would be good for writers too…”

G2.3 “For me there were too many elements to building a game. Brainstorming and deciding

different possibilities are fun”

G3 No comment.

G4 No comment.

G5 No comment.


D‐12

Q5 I would be encouraged to build games of my own


G1.1 1 G1.2 1 G1.3 1 G2.1 1 G2.2 1 G2.3 1 G3 1 G4 1 G5 1 TOTAL 1 2 5 2

Participant comments: G1.1 No comment.

G1.2 “My kids can do this type of thing better. I’d be more into a narrative game.”

G1.3 No comment.

G2.1 No comment.

G2.2 “I like the ability to add an in‐depth storyline”

G2.3 No comment.

G3 No comment.

G4 No comment.

G5 No comment.


D‐13

Notes from debriefing G1

General feel was that they would prefer to build games as part of a group. Parents stated that they

would rather build games for their children than for themselves.

It would be good if they were able to edit the game over a period of time and through multiple sessions

instead of going through it all at one shot, because at home they would take their time to build a game

over weekends. This would ensure that the younger family members would be able to pay attention

over shorter periods.

G2

There were mixed feelings, about building in a game in a group. On one hand they felt it was good in a

group because they could bounce ideas around, but on the other hand they felt that there would be less

conflict if they went about building a game individually.

They felt that users would benefit from seeing an example before building a game for the first time.

A discussion indicated that while the current number of clues would be sufficient for regular game

builders, more advanced users might want to have more checkpoints available to them.

G3

The participant felt that while some may be inclined to build games on their own, it would be better to

make games as part of a group. As mentioned previously, he felt that making games as part of a group

meant that ideas could be exchange and it would be “less stressful”.

G4

The participant felt that he would like to make games for weekend hikers, but he would rather make a

game as part of a group rather than alone, because it would be mundane having to go to the locations

on his own. Being part of a group also meant that he would have more opinions.


D‐14

The participant felt very strongly that it would be better if there were more than 10 checkpoints

because he wanted to make games that would span greater distances. Also, the nature of the terrain

meant that it would be better to lead players through a trail using a series of nearby checkpoints, so that

they don’t get lost. He also had the idea of creating a game that could be played in 2 parts, using hints as

a substitute for the end message.

G5

She felt that it would be better to make the game as part of a group, because that meant that there

would be more ideas for her to work with.

The descriptions at the side were not noticeable enough, and would be better if they were in the line of

vision.

G1 This family of five has been living in Brisbane for some years now, and as such was familiar with the

South Bank area and the amenities available there.

They undertook the conceptualization of a game in 6 main steps:

1) Identifying potential checkpoints

This entailed identifying locations that they were most familiar with and then marking them out with the

post‐it notes provided. Everyone had a hand in this activity. Interesting locations were also written down

on a larger piece of paper in the form of a list.

2) Assigning roles

The family attempted to designate roles to members of the family. This did not quite work out because

the younger children were getting distracted, but their oldest was fully capable of taking on the role of

the scribe, while the parents were mainly leading the design phase by guiding the family through the

process in a systematic manner as will be covered in the following steps.


D‐15

3) Deciding on a path

At this point there was an issue of how to go about this: Would it be through a constructed narrative or

by taking on the form of a guided tour of sorts? In order to decide on whether to create a narrative or a

tour, they came to the conclusion that they would have to choose a path first and then see how they

could link the points of the path together.

During this time there were a multitude of checkpoints marked on the map, but they were limited to 10,

so in order to narrow down the number, they asked themselves “What do you like to do at South Bank?”

and “Where do you like to go?” This also helped greatly in defining some of the more interesting points

that they could use for clues. It also helped, because this meant that the places that they had the most

interest in were chosen. In addition to family contributions, the internet was also used to select the

more relevant checkpoints, because while choosing checkpoints, the family was constantly trying to

come up with clues, for each location, and sometimes they found themselves unable to come up with

anything because they had no physical access to the places. The internet helped a lot because it allowed

them to research each location in far greater detail, and in a shorter time. Using information from the

internet, a lot of the important points about each location was selected. These points would also prove

to be the starting points for clues, or would immediately be turned into clues.

To help in elaborating on the checkpoints they made use of the templates provided, making use of the

fields provided as guides. This part involved much of the family, but the younger children were starting

to grow restless, so they did not have much to contribute.

Eventually the path chosen was a result of a family consensus and since most of the points of interest

were already marked out on the map, it was a matter of ordering the points in a manner that they felt

most comfortable with. The question asked then was “What would the family do?” This meant

elaborating on the sequence of activities they would undertake during a day out at South Bank. For

them it was a matter of how the family usually spent time in South Bank. It was decided that usually

they would spend a most of the day walking around South Bank, before ending up at the manmade

beach where they would cool down and have an ice cream before leaving.

There was then a debate about how they would best approach the individual checkpoints. If the

checkpoints were too far away, or required too much travel they would be replaced with another closer


D‐16

checkpoint. Once all the checkpoints were deemed suitable, they started to order them according to the

route taken during a typical family outing.

It was at this time that they started numbering the smaller post‐its that were on the map, also using the

larger post‐it notes, jotting down basic clues and numbering them in order of the path they would have

taken as a family.

4) Coming up with a concept

From part 3 the seed for the final concept was already planted. The approach of looking at the path

from the perspective of a family outing meant that the most convenient way of turning the game from a

series of checkpoints into an overall concept was to refer to it as a “Family Day Out”. A way for tourists

and locals alike to explore South Bank and see what this family felt were the more interesting sights.

5) Development of selected concept

It was when they were finally exposed to the Cipher Interface proper that they were able to fully expand

on their selected concept. While the paper forms provided had the fields that they would require to

begin the simple development of a game, to the extent that all the clues could have been defined, they

were only used for a brief outline of each checkpoint.

Once at the game builder, they started to create additional clues to supplement those that they already

had. Because the theme was a sort of guided tour around South Bank, the clues used basically involved

exploration and interesting bits of information of various landmarks around South Bank, and Museums

that surround the area.


D‐17

Game Builder

Step 1

No issues encountered.

Step 2

Suggested that maybe there was no need for a start time to be assigned to an open game because there

was no competition factored in.

Step 3

At this time the original clues were reinterpreted and more clues added.

The younger kids were all gone, but the oldest managed to figure out the interface without any difficulty

at all easily moving through the interface despite being in contact with it for the first time.

Minor issues included being unsure if fields were case sensitive, and if full stops in the answers fields

would affect how the player answered.

BUG: Adding more than 7 checkpoints would break the div at the end.

Step 4

They found it entertaining to go through the game they made.

A major issue was that when doing a test run of the game, they had to go back to edit portions of the

game, and then when they came back to the test screen they had to go through the entire series of

steps again to reach the last step they left off at.

Step 5

They initially overlooked the presence of the poster and had to be guided to it.


D‐18

They generally felt that it was a good experience using superlatives like “Great” and commenting that it

was “wonderful to see the result”


D‐19

Post Test Questionnaire

The post test questionnaire contains series of questions that were designed to further investigate some


the system.



P1.1 1 P1.2 1 P1.3 1 TOTAL 2 1

Participant comments: P1.1 “It was fun to organize!”

P1.2 “Both easy and difficult – At first my ambitions were bigger than time and working 2

uncooperative children allowed. But I’m pleased with the result.”

P1.3 “I was not entirely uninitiated.”



P1.1 1 P1.2 1 P1.3 1 TOTAL 3

Participant comments: P1.1 “Visual aids (mapping) would make it easier. But it was very useful.

P1.2 “It’s great.”

P1.3 No comment.


D‐20



P1.1 1 P1.2 1 P1.3 1 TOTAL 3

Participant comments: P1.1 No comment.

P1.2 “After the process, yes! I’d like to have more time to think about it though.”

P1.3 No comment.



P1.1 1 P1.2 1 P1.3 1 TOTAL 3

Participant comments: P1.1 “It is interesting to incorporate intellect and enjoyment in a creation.”

P1.2 “Except for the distractions of young kids.”

P1.3 No comment.


D‐21

Preference levels These are subjective measures of the Cipher Cities interface taken after the test, with 1 being the best and 7 being the worst. Qn1 Simple…………….……3…2…1…0…1…2…3………Complex Qn2 User Friendly….….…3…2…1…0…1…2…3………Not User Friendly Qn3 Well Organized…….3…2…1…0…1…2…3………Messy Qn4 Safe………………………3…2…1…0…1…2…3………Unsafe Qn5 I like…………….....……3…2…1…0…1…2…3………I Dislike (1)(2)(3)(4)(5)(6) (7) Qn1 Qn2 Qn3 Qn4 Qn5 P1.1 2 2 2 2 2 P1.2 2 2 1 1 2 P1.3 5 2 2 1 1 3 2.2 1.67 1.33 1.67

Opinions

“It was easy to create an adventure, although I think a tourism attraction and also a story narrative

would have creating something interesting also. Not only is the “game builder” a way to teach other

people interesting facts, but the process is a good personal experience.”

“Narrative and characters”

“Add hint: as prefix to SMS hints.

Improve the process of testing vs going back to the checkpoint/hint screens.

Allow people to send MMS separate from sending answers.

Well done!

I want to be able to print my game check points and hints.”


D‐22

Notes from Debriefing

Making their own games

General feel was that they would prefer to build games as part of a group. Parents stated that they

would rather build games for their children than for themselves.

They also felt it would be useful to have as a guide for a visiting family, or even as a story telling device.

The mother recounted how the father used to have a running story about a kangaroo that he would tell

the children when they were little and she felt with this, the story could have been made even more

interesting.

Education

Parents felt that this would serve as a useful learning too, and the kids would like to see the games

being used in school.

Other points

It would be good if they were able to edit the game over a period of time and through multiple sessions

instead of going through it all at one shot, because at home they would take their time to build a game

over weekends. This would ensure that the younger family members would be able to pay attention

over shorter periods.

It was suggested that the printable forms be made to reflect the online interface, so that clues could be

created on location and later entered online.

Earlier in testing it a question was raised about the use of language in an SMS based game, because

language used in SMSing is often different from language used in normal writing or conversation. How

would we regulate this difference?


D‐23

G2 This family of five has been living in Brisbane for some years now, and as such was familiar with the

South Bank area and the amenities available there.

They undertook the conceptualization of a game in 6 main steps:

1) Deciding on checkpoints

Initially the group decided that they wanted to go at it point by point, first deciding on a starting location,

and then moving on to subsequent checkpoints, but they eventually decided to confirm their

checkpoints first before deciding on where to start. In order to do this, located places that they were

familiar with and marking those locations out with post‐it notes, numbering them along the way. This

group decided that they would create first decide on checkpoints, and on the order of checkpoints

before connecting them together.

While deciding on checkpoints, they were already coming up with clues that they could use, even

though they were not yet sure of the theme that would be employed.

2) Deciding on a way to connect the checkpoints

They realized that they had to decide on an overall theme for the game that would enable them to

connect all the checkpoints together as part of a logical sequence of events. The first asked “Do you

want a narrative?” The older brother proposed that since there were clues it was akin to a kind of

detective story, sort of like “Where in the World is Carmen San Diego”, so they decided to make it a sort

of detective game that involved the player finding clues.

They were not entirely sure what the outcome would be, or the narrative involved, therefore they

decided to create the narrative as they went through the checkpoints.

They thought of using word games such as missing alphabets and even employing a cipher of their own,

but decided that it would be too much trouble to make one up in such a short time. While writing clues


D‐24

they employed conventions like “Report for duty..” and employed the use of made up static to create

the illusion of the player actually being involved in a police/detective mystery.

To add to the whole concept of a scavenger hunt, they decided that in their games they would have to

“give them [the players] something to find or do”. They discussed how they would leave clues and how

they might plant clues in South Bank. This included leaving numbers, and sticking clues around various

locations in South Bank where players would have to look for them. This would mean that players would

actually have to go to the location and find the code before being able to proceed to the checkpoint.

They also decided that instead of making the last clue the answer, they would try to make it a clue that

would definitely mean that the player would be able to find the answer, yet requiring that the player

would have to be at the location in order to actually progress to the next checkpoint.

4) Creating in depth clues

They used the printed templates to start properly documenting their progress, employing the internet

to help them find interesting things about locations that they could use in clues.

One of the checkpoints was the state library, and they decided that there were computers there that

could be used by the general public, so hey even decided to use the internet for delivering clues. There

were also clues that involved them having to look for someone who might be working in the library. This

brought up questions of what time they would have to run the game in order for that librarian to be

there. They would have to inform players that the game would take place at a fixed time during the day

in case the librarian would be off shift.

There was also a suggestion that maybe they should have the clues in rhyme, but then they were

already halfway through making clues, therefore they decided to continue along the lines that they have

been following all along.

They also created more subtle clues that made use of capitalization of text within the clues to guide

players to resolutions.


D‐25

At about halfway creating checkpoints they ran out of ideas for continuing with the theme, so they

diverged from the detective story and even decided to reduce the number of checkpoints from 10 to 8.

They would later attribute this to the limited amount of time they had to create the game. They felt that

given a week they would be able to come up with a more complete narrative. Despite the divergence

from the detective story, they kept up the use of common elements like mystery and the use of

simulated static in their clues to continue with the feel of the game. The new theme was a cross

between a seafaring captain and a detective tale.

One issue that they faced was also that they wanted to use the cinema as a checkpoint. In the cinema

they required players to locate a movie screening time to progress in the game. Of course, this would

mean that the game can only be played for as long as the movie runs. The ability to update the game

will enable the creator to change the name of the movie so that the game can continue on despite

changes at the location. The group however proposed that the game only run for a fixed duration.

Notes about roles within the group

The group decided to forgo the formal assigning of roles, instead everyone was expected to give a hand

in all parts of the conceptualization. Despite this, there were no significant problems with them being

able to create the game, other than the fact that naturally some members will have to contribute more

than others.

While coming up with an overall theme for the game and getting production to go along, one

member (sister) was pushing the production process, getting everyone in line and focused,

while one member (brother) was continually conceptualizing and coming up with ideas to drive

the game along. The remaining member did not have much to contribute during this time.

While coming up with clues, it was more or less the same situation. This meant that the

remaining member had less input than the other two members, which could have implications

for feelings of ownership with the game. While there were no observed issues here, this point

should be noted when the system is used in an educational context.


D‐26

Game Builder

Step 1

The brief description was too brief. This detracted from the whole theme they built up while coming up

with ideas for the game.

Step 2

They used the instructions to help players orientate themselves to how the game will be played.

Step 3

Case sensitivity was brought up. They wanted to know if answers were case sensitive.

When a page is completed, users should be able to go back and forth by just clicking on the page

number instead of going back and forwards.

There was no limit displayed form the completion message, so they wrote a really long one.

Step 4

They felt it would be good if messages sent to the player indicated if they were clues or a question for a

new checkpoint. They also thought it would be good to indicate to the player which clue they are on.

Step 5

They did not look at the game poster initially, although one member did indicate that he noticed the link.


D‐27

Post Test Questionnaire The post test questionnaire contains series of questions that were designed to further investigate some


the system.



P1.1 1 P1.2 1 P1.3 1 TOTAL 1 1 1


P1.2 No comment.

P1.3 “On one hand it is easy to create an overall game + feel for it, etc., it is not that easy to think

of all the little things that link one place to the next.”



P1.1 1 P1.2 1 P1.3 1 TOTAL 1 2


P1.2 “I think there should be more info provided about “What is an SMS based game.”

P1.3 “Neat +well presented. User friendly.”


D‐28



P1.1 1 P1.2 1 P1.3 1 TOTAL 3

Participant comments: P1.1 “It would be difficult to understand what type of game you can build without first seeing an

example.”

P1.2 “But I think there should be more of a “hold my hand” approach on the website… maybe even a walk‐thru of how someone else made one…”

P1.3 No comment.



P1.1 1 P1.2 1 P1.3 1 TOTAL 1 2


P1.2 “Good fun… there’s heaps of potential and it would be good for writers too…”

P1.3 “For me there were too many elements to building a game. Brainstorming and deciding

different possibilities are fun”


D‐29

Preference levels These are subjective measures of the Cipher Cities interface taken after the test, with 1 being the best and 7 being the worst. Qn1 Simple……………….…3…2…1…0…1…2…3………Complex Qn2 User Friendly……..…3…2…1…0…1…2…3………Not User Friendly Qn3 Well Organized…….3…2…1…0…1…2…3………Messy Qn4 Safe………………………3…2…1…0…1…2…3………Unsafe Qn5 I like…………….....……3…2…1…0…1…2…3………I Dislike (1)(2)(3)(4)(5)(6)(7) Qn1 Qn2 Qn3 Qn4 Qn5 P1.1 2 1 1 1 1 P1.2 2 2 3 4 2 P1.3 1 1 1 1 1 1.67 1.33 1.67 2 1.33

Opinions

“‐Features I would like to see: A heading at the top of each text indicating if the information is an

instruction for the next point or if it is a clue.”

“Maybe if time based then the next clues/hints could be smsed to player after certain amount of time

‐then there could be an option for the player to pause by texting this…”

“Add hint: as prefix to SMS hints.

Improve the process of testing vs going back to the checkpoint/hint screens.

Allow people to send MMS separate from sending answers.

Well done!

I want to be able to print my game check points and hints.”


D‐30



There were mixed feelings, about building in a game in a group. On one hand they felt it was good in a

group because they could bounce ideas around, but on the other hand they felt that there would be less

conflict if they went about building a game individually.

Other points

They felt that it was rewarding because they could make a story. They also felt it would be good if there

could be multiple answers to a checkpoint (non linear).

They felt that users would benefit from seeing an example before building a game for the first time.

A discussion indicated that while the current number of clues would be sufficient for regular game

builders, more advanced users might want to have more checkpoints available to them.


D‐31

G3 This instance of user testing was undertaken by an individual participant who has spent a year living in

Brisbane. At the time of the test, the individual had just spent a day at South Bank, and therefore said he

was able to construct a series of checkpoints from memory. The participant also indicated that he has

had prior experience in creating as well as taking part in scavenger hunts.

Before starting, he was briefed on SMS location based games and how the Cipher Cities system worked.

The participant was given a tour of the various functions available to users, including a game poster and

was told that this is what he would be able to create. He was also shown the various steps in game

creation and told that this was the tool he would eventually use to create the game.

This participant undertook the task of building a game in three steps:

1) Marking checkpoints and pathing

The participant first marked out checkpoints, immediately focusing on locations that he felt reasonably

familiar with. He had a preference for locations that he could picture in his mind, and created labels

using the mini post‐its, labeling each checkpoint as he moved through them.

At this point, he also came up with short descriptions for checkpoints that he felt more familiar with on

the mini post‐its.

The participant noted that a treasure hunt should have a theme, or a story in order to be engaging, but

he decided to hold off formalizing a proper theme until he felt confident that he was able to create clues

around the checkpoints. Despite the participant claiming not to have a theme in mind, or wanting to put

off creating a theme until a later time, it was clear that he was building a game that would lead players

from the Botanical Gardens to the end of South Bank at the Queensland Art Gallery. This was clear when

at the end he decided to use his game as a sort of introduction to popular hangouts for QUT College

students.


D‐32

When he was later asked about why he designed his path to lead in a line from one end of South Bank to

the other end, and if he did that with the intention to “lead” players by allowing them to assume that

they would be moving in a fixed direction, he indicated that he also intentionally chose a checkpoint

(South Bank Cinemas) that deviated from the straight path, so as to “throw players off” the trail. This

indicated that he had the path in mind from the time he starting laying out checkpoints.

Also, despite being informed that there was a maximum of 10 checkpoints he could create, with an

emphasis that there was no need to use all the checkpoints the participant decided to select 10

checkpoints that he could later narrow down if he wanted.

2) Creating clues

When the participant decided to actually start writing down clues for each individual checkpoint, he

expressed that he was daunted by the fact that there was actually so much thought that had to be

thought out. This was his first exposure to the checkpoint template. He also expressed that he might

have trouble coming up with a theme.

The participant noted that the idea is that a theme can be worked around the checkpoints that were

initially selected. He could not think of a unifying theme that he could use, and when reminded that the

internet was available to him, he declined, saying that he was able to work from memory. He also did

not feel that he had to gather so many details because he was only going to construct the game using

prominent landmarks that would be easily accessible and would not have to cost money to view. One

example was for the Maritime Museum where he was unsure of how to create a clue, and yet decided

to use only the anchor outside as a point of reference because he did not want players to have to pay

extra costs in order to participate.

Referring to previous experience, he said that in creating such a game he usually worked in a group that

would “walk the ground” beforehand, before setting up. He also said that working in a group meant that

there were more ideas to be shared and that the game would likely be more interesting.

An example of a clue the participant came up with is “I used to swim in ages past, but swim no more

because I rust.” When asked about the tone of language he chose for some of the clues, he said that the


D‐33

“Idea is to catch their attention.” When probed further, he admitted that he was once again referring to

previous experience, which meant that he was thinking about a time when he was creating games for

teens of between the ages of 13‐17.

It was also noted that when creating checkpoints, the participant used very long answers. When asked if

he expected players to text back such long answers, he said he assumed that players would be able to

identify the answers from locations. An example of such an answer is “Ship, decommissioned & in the

museum.” This clearly illustrates that he did not have in mind the fact that it will be difficult for players

to text back such answers from just looking at a location. When this was explained to him, he decided to

cut answers down to keywords.

When working with printed templates, he had to clarify which fields players would be able to see. This is

a point that would come up again later when he was working in the interface.

3) Input and Theme creation

While the participant had actually already come up with a path, he was unsure of how he would actually

create a kind of “back story” that would go along with the path. He then realized that all the checkpoints

he selected were actually places that were popular with his friends when he was in QUT College. He

therefore decided to make it a sort of orienteering exercise, because he had come up with the clues

earlier, this would also mean that he would not need to rewrite the clues, which he would have had to

do if he chose a more complex theme.

While doing this he also revised some of his hints so that it would be easier to locate checkpoints. He as

also starting to feel fatigued, and decided that he would use only 8 of his 10 selected checkpoints.


D‐34

Game Builder

Step 1

Missed the Global/Local option which he felt should be on the next page, because he thought the first

step was for descriptive purposes.

Step 2

No issues.

Step 3

He felt that there should be an option to save and come back at another time to continue.

He assumed that players would be sent the title as well as the question. This was because of the way

that the fields were labeled.

Step 4

No issues.

Step 5

No issues.


D‐35



the system.



P3 1 TOTAL 1

Participant comments: P3 No comment.



P3 1 TOTAL 1



D‐36



P3 1 TOTAL 1




P3 1 TOTAL 1




P3 1 TOTAL 1



D‐37

Preference levels These are subjective measures of the Cipher Cities interface taken after the test, with 1 being the best and 7 being the worst. Qn1 Simple……………….…3…2…1…0…1…2…3………Complex Qn2 User Friendly……..…3…2…1…0…1…2…3………Not User Friendly Qn3 Well Organized…….3…2…1…0…1…2…3………Messy Qn4 Safe………………………3…2…1…0…1…2…3………Unsafe Qn5 I like…………….....……3…2…1…0…1…2…3………I Dislike (1)(2)(3)(4)(5)(6)(7) Qn1 Qn2 Qn3 Qn4 Qn5 P3 1 1 1 4 1 1 1 1 4 1


D‐38



The participant felt that while some may be inclined to build games on their own, it would be better to

make games as part of a group. As mentioned previously, he felt that making games as part of a group

meant that ideas could be exchange and it would be “less stressful”.

Other points

The participant felt that it would be good if there was a “Picture Hunt” function where players could be

sent pictures by MMS that they could look for, instead of just text.


D‐39

G4 User testing was conducted at a location of the participant’s choice, with the test monitor following to

observe the process of game creation. When the participant decided that the game was sufficiently

developed, the process was taken back to the computer where the written clues were put into the

system. The participant has had recent experience creating treasure hunts, but in an urban location

rather than in a rural area that this game was designed in.

No material was provided other than the printed templates, allowing the participant to find his own way

to build a game.

The participant undertook the task of building a game in three steps:

1) Location selection and theme/purpose

The participant is a self confessed outdoors type of person, so he wanted to make a game and have fun

in the process of making it. This led him to choose a hiking track that he would enjoy hiking on. Being a

seasoned outdoors person, this track was an easy walk to him, but would possibly have been more

daunting to unseasoned walkers.

In choosing the track, he already decided on the eventual game path even before going to the ground.

The fact that he chose a hiking trail also meant that game would be a straightforward orienteering

course that would allow players to familiarize themselves with their surroundings during the walk.

2) Choosing checkpoints

The participant chose a start point and an end point a total of 7km in distance. He then went on location

and walked through the grounds, covering the entire length of the location, during which more

prominent areas were chosen as checkpoints. The participant stated that the reason for this was that

players would then have less trouble locating the checkpoints, especially since most areas in such a

vegetated area appear to be uniform.


D‐40

When a suitable checkpoint was found, a short checkpoint title and description was marked on the

templates. He said he would come up with the hints later when he got back to the computer, because

he wanted to be able to locate the checkpoints quickly without being hindered along the way.

At this point he had little idea what the game in entirety would be about, but decided to proceed

without giving it much thought until later on in the process. This would prove troublesome for someone

building an actual game, because later he decided it would be better to plant items at checkpoints, but

was not able to, because it was too far to walk all over again.

Being told that there was a maximum of 10 checkpoints, he tried to limit himself along the way, but later

said that he would have liked to have more checkpoints in order to make the distance between

checkpoints shorter.

While filling in the checkpoint templates, the participant was unsure if the title would be available to the

players, but once told was quick to recover from the confusion.

3) Input and clue creation

The participant decided to create hints later on in the game creation stage, and when he first started, it

was clear that he was not very clear on how to create a clue that would guide players to specific

locations that players would be able to identify, first creating clues like “follow the trail”, expecting

players to identify a series of steps along the way as a checkpoint.

He was also unsure of what an appropriate answer might look like. The result of which was answers that

were so long and ambiguous that participants might have trouble discovering what they are. This

required the test monitor to explain to him that he should imagine that he is the player, and try to

create clues that would lead to something that was unmistakably identifiable so that the answers would

not end up being a matter of guess work.

After this prompting he decided it would be a good idea to plant things along the trail, near to the

described checkpoints that were definitely alien to the environment so that players would have to look

for them, but would not have trouble identifying them once they were found.


D‐41

Despite this, there were still issues with regards to how the players would be able to send in exact

answers, since even generic items sometimes have a number of names. He therefore decided it would

be better to tag the items and that players would just send in what was written on tags as answers.

The initial instructions were merely for players to follow the trail, but after the participant decided to

change the format of the game, he decided that he would have to update the instructions so that

players would not be left feeling confused as to how the game is played. He added that players should

send the answer in exactly as written on the tags.

While creating the answers, he found that it was not clear to him if the answers players sent had to be

exactly as he entered it in the builder. For example, “a red flag” or “red flag”.

While working with the game builder, it also became clear that the participant was not aware of how

the hints worked. He initially felt that there was no need for hints, and when asked later why he didn’t

want to use them he said he thought it was because all the hints would be sent to the player at the

same time, and would thus serve the same purpose as a question. When he did find out how clues were

used, he started to get more creative with checkpoint answers and even created a checkpoint near a

stream that forced users to taste the water before being able to get to the next checkpoint.

He also created checkpoints the intentionally misleads players into walking through a small stream, and

only sending them the right hint when they get the answer wrong the first time round. He also made use

of rules that were in effect at the location to punish players who didn’t manage to find the answer the

first time round. This took place at the tree top walk where players would only be able to walk through

in one direction. A checkpoint was located at the end of the walk, and if players missed it, they would

have to walk all the way around to the start point again, another kilometer or so, with a steep upslope

walk at the end. This adds another dimension to the game, physically taxing players for participating.

This discovery that hints could be used also meant that he used more of what he could find on location,

rather than planted items.


D‐42

Materials

While other participants were provided with additional materials such as maps and stick it notes for

creating a game, this participant only made use of the printed templates while walking the ground. He

had no difficulty working without the additional materials, and without using the internet for reference,

because writing notes and taking pictures meant he was able to recall the checkpoints in greater detail.


D‐43

Game Builder

Step 1

Missed the Global/Local option. He was confused about what it meant.

Step 2

Confused by the Game start date, thinking that it referred to when he went to walk the ground.

Start time thought to meant duration of game. He left the minutes unselected.

Step 3

Successfully deleted and added checkpoints. (there is still an issue with coloration)

Missed the completion message saying it wasn’t obvious enough.

Step 4

Was not aware that answers were case sensitive.

Completion message should be displayed as well.

Step 5

Noticed the game poster.


D‐44



the system.



P3 1 TOTAL 1




P3 1 TOTAL 1



D‐45



P3 1 TOTAL 1

Participant comments: P3 Add in more instructions and checkpoint allowances.



P3 1 TOTAL 1




P3 1 TOTAL 1



D‐46

Preference levels These are subjective measures of the Cipher Cities interface taken after the test, with 1 being the best and 7 being the worst. Qn1 Simple………….….……3…2…1…0…1…2…3………Complex Qn2 User Friendly……..…3…2…1…0…1…2…3………Not User Friendly Qn3 Well Organized…….3…2…1…0…1…2…3………Messy Qn4 Safe………………………3…2…1…0…1…2…3………Unsafe Qn5 I like………………..……3…2…1…0…1…2…3………I Dislike (1) (2) (3) (4) (5) (6) (7) Qn1 Qn2 Qn3 Qn4 Qn5 P3 3 2 2 2 2 3 2 2 2 2


D‐47



The participant felt that he would like to make games for weekend hikers, but he would rather make a

game as part of a group rather than alone, because it would be mundane having to go to the locations

on his own. Being part of a group also meant that he would have more opinions.

Other points

The participant felt very strongly that it would be better if there were more than 10 checkpoints

because he wanted to make games that would span greater distances. Also, the nature of the terrain

meant that it would be better to lead players through a trail using a series of nearby checkpoints, so that

they don’t get lost. He also had the idea of creating a game that could be played in 2 parts, using hints as

a substitute for the end message.


D‐48

G5 In this round of testing, the participant was given the Cipher Cities URL, template print outs, and told to

go out and create a game of her choosing. Having had experience in moderating school camps, the

participant chose her old secondary (high) school as the location where her game would be played.

Having set up treasure hunts before helped her organize her process so that she would be able to build

a game. She described her system of conceptualization to me as described below:

1) Location selection and theme/purpose

The participant chose her old school because she felt it was a familiar location, and she enjoyed

moderating school camps when she was there about 5 years back. She felt that going there would give

her the opportunity to meet with old teachers again as well as build a game at the same time.

Because she was already very familiar with the school grounds, she identified some key areas, and

locations while on her way there. This allowed her quickly build the game without mulling over which

locations to pick as checkpoints when she got there.

One of her main considerations was that her game would not use planted objects, or parts of the school

that could be subject to change, because she felt that planted checkpoints had a high likelihood to go

missing, and she wanted the game to be something that could reused.

2) Preselecting potential checkpoints

Because the participant was very familiar with the school grounds, she chose a number of potential

checkpoints before she actually went to the school, making mental notes of the places where she felt

she could put good checkpoints. By preselecting these checkpoints, she felt it made her job on the

actual location much easier, because she already had an idea of where some checkpoints would be.

Even if she had to make revisions, she would make them around the preselected locations.

3) Finalizing checkpoints, making hints and pathing


D‐49

Because she already had a list of checkpoints in her head, the participant found that she had to do two

rounds of the location. The first round was for her to confirm that the checkpoints she selected earlier

would be suitable, and to make a note of where they are, and the second round would have her creating

questions and hints for each checkpoint. While she did these rounds she also mentally connected these

checkpoints together with a path.

Because her game was to be an orientation to school grounds, she felt that students should feel familiar

with the layout of the school after the game, and yet she did not want it to be too easy by just making

students find large parts of the school like rooms. Therefore, she decided to use parts of the school that

are not usually noticed by students unless they really look closely; things that she called “fine details”.

She said that this consisted of mostly irrelevant things that students would not usually notice in day

in school, but also some things that students would notice as well. This meant that students

would have really pay attention to their surroundings to get some of the answers.

To further emphasize on the orientation aspects of the game, she designed the game so that students

would go around in circles. She felt that these repeated encounters with certain parts of the school

would mean that students would get a feel for the school layout quickly.

In creating her answers she said she paid attention to the language that she used, and tried to create

answers that people could identify straight off from just looking at the locations.

She also felt that 8 checkpoints were about as many as she could fit into the school grounds, because it

was such a small location. She said that if it was a larger location she would have used the maximum of

10.

While filling up the printed templates, she felt that it was slightly confusing because she was not sure

which fields the player would be able to see and which they would not.

4) Input and clue checking

The input stage also served as a point where the participant could check her hints and questions to see if

they were a suitable length, and if her answers were correct.


D‐50

When she encountered an answer that she felt had to be revised, she revised the question as well, in

order to suit the new, shorter answer.

Materials

The participant worked solely using the printed templates. Going to the location, she felt that she did

not need any additional aids like provided to the other participants.

She did comment that the print outs were slightly wasteful and that she would prefer if they were

slightly smaller, about half the A4 size.


D‐51

Game Builder

Step 1

Filled in a detailed description.

Step 2

Chose invite only option because she felt the game would only be for students of the school.

Did not assign equipment because she felt it was up to the students.

Step 3

Successfully deleted and added checkpoints. (there is still an issue with coloration)

No issues adding and deleting hints.

Felt that there should be an indication of what the player will and will not see.

Step 4

Felt it would be better if builders could select the hint from the list rather than go through all the steps

again.

When testing game the “enter” key should act as the reply button, so that less clicking would have to be

done.

Step 5

Noticed the game poster but didn’t feel need to view it.


D‐52



the system.



P3 1 TOTAL 1




P3 1 TOTAL 1



D‐53



P3 1 TOTAL 1




P3 1 TOTAL 1




P3 1 TOTAL 1



D‐54

Preference levels These are subjective measures of the Cipher Cities interface taken after the test, with 1 being the best and 7 being the worst. Qn1 Simple………………….3…2…1…0…1…2…3………Complex Qn2 User Friendly…….…3…2…1…0…1…2…3………Not User Friendly Qn3 Well Organized…….3…2…1…0…1…2…3………Messy Qn4 Safe………………………3…2…1…0…1…2…3………Unsafe Qn5 I like…………........……3…2…1…0…1…2…3………I Dislike (1) (2) (3) (4) (5) (6) (7) Qn1 Qn2 Qn3 Qn4 Qn5 P3 2 2 2 2 2 2 2 2 2 2


D‐55



As a frequent participant in online forums, the participant felt that the system would be a good

supplement for their outings.

She felt that it would be better to make the game as part of a group, because that meant that there

would be more ideas for her to work with.

Other points

Participant added that she felt that the case sensitivity should be uniform (ie all stored in lower case), so

that players would not struggle with capitalization.

Hints should cycle, so that when a player reaches the last hint, the next hint will be the first one again.

The descriptions at the side were not noticeable enough, and would be better if they were in the line of

vision.

Appendix E


E‐1

G1 Primary School Teachers G2 Secondary School Teachers G3 Primary School Students G4 Secondary School Students


E‐2

The post workshop questionnaire contains series of questions that were designed to further investigate

some issues that may not have been obvious enough through monitoring the way participants

interacted with the system.

Q1 I feel it will be easy to build learning activities that use mobiles.


G1.1 1 G1.2 1 G1.3 1 G1.4 1 G1.5 G2.1 1 G2.2 1 G2.3 TOTAL 1 5

Additional comments: G1.1 No comment.

G1.2 No comment.

G1.3 No comment.

G1.4

No comment.

G1.5 No comment.

G2.1 No comment.

G2.2 No comment.

G2.3 “I don’t think it will be easy to generate a really good application.”


E‐3

The post workshop questionnaire contains series of questions that were designed to further investigate

some issues that may not have been obvious enough through monitoring the way participants

interacted with the system.

Q1 I feel it will be easy to build learning activities that use mobiles.


G1.1 G1.2 G1.3 1 G1.4 G1.5 1 G2.1 1 G2.2 1 G2.3 1 TOTAL 1 5


G1.2 No comment.

G1.3 No comment.

G1.4

No comment.

G1.5 “At first the process seemed quite simple but to make the game successful requires some practice.

G2.1 No comment.

G2.2 No comment.

G2.3 No comment.


E‐4

Q2 The event builder is well structured.


G1.1 G1.2 G1.3 1 G1.4 G1.5 1 G2.1 1 G2.2 1 G2.3 1 TOTAL 5

What compelled you to apply for this workshop? Teacher comments: G1.1 No comment.

G1.2 No comment.

G1.3 No comment.

G1.4

No comment.

G1.5 No comment.

G2.1 No comment.

G2.2 “Needs larger text fields so can see entire text.”

G2.3 No comment.


E‐5

Q3 I can understand the process of building an event.


G1.1 G1.2 G1.3 1 G1.4 G1.5 1 G2.1 1 G2.2 1 G2.3 1 TOTAL 5 1


G1.2 No comment.

G1.3 No comment.

G1.4

No comment.

G1.5 No comment.

G2.1 No comment.

G2.2 No comment.

G2.3 No comment.


E‐6

Q4 Building the event was an enjoyable process.


G1.1 G1.2 G1.3 1 G1.4 G1.5 1 G2.1 1 G2.2 1 G2.3 1 TOTAL 2 3


G1.2 No comment.

G1.3 No comment.

G1.4

No comment.

G1.5 No comment.

G2.1 No comment.

G2.2 No comment.

G2.3 “I don’t think it will be easy to generate a really good application.”


E‐7

Q5 I would be encouraged to make more events in the future.


G1.1 G1.2 G1.3 1 G1.4 G1.5 1 G2.1 1 G2.2 1 G2.3 1 TOTAL 4 1


G1.2 No comment.

G1.3 No comment.

G1.4

No comment.

G1.5 No comment.

G2.1 No comment.

G2.2 No comment.

G2.3 No comment.


E‐8

Preference levels These are subjective measures of the Cipher Cities interface taken after the test, with 1 being the best

and 7 being the worst. The results show that the site has been well received by the participants and is

viewed in a positive light.

Qn1 Simple…………………3…2…1…0…1…2…3………Complex Qn2 User Friendly…….…3…2…1…0…1…2…3………Not User Friendly Qn3 Well Organized…...3…2…1…0…1…2…3………Messy Qn4 Attractive…….………3…2…1…0…1…2…3………Unattractive Qn5 I like……………....……3…2…1…0…1…2…3………I Dislike (1) (2) (3) (4) (5) (6) (7) Qn1 Qn2 Qn3 Qn4 Qn5 G1.1 1 1 2 2 2 G1.2 G1.3 G1.4 G1.5 5 2 2 1 1 G2.1 1 1 1 1 1 G2.2 2 2 3 1 2 G2.3 3 2 2 2 1 Mean: 2.4 1.6 2 1.4 1.4


E‐9

Difficulties encountered:

“Technical issues getting SMS + publishing our game”

“Non‐specific answers” (with regards to creating an event. Refers to the need for a very specific set of

answers)

“Spelling/typos” (with regards to their own event)

“Specific answers”

Like to see:

“Instructions on how it works from beginning to end on the site.”

“I would like to see this combined with PODMO.”

Things they liked:

“Active + hands‐on”

“Engagement of students was excellent – indication of the appealing nature of the tasks.”

“Its simplicity.”


E‐10

STUDENTS PRE‐TEST

What do you like about mobile phones?

G3.1 “Games and all the cool features like ringtones, voice recorder etc.”

G3.2 “Don’t have one.”

G3.3 “I like the ringtones.”

G3.4

“Play games and texting people”

G3.5 “You talk to people”

G3.6 “Calling friends, games, music.”

G3.7 “Talking to your friends, games”

G3.8 “Games ringtones, internet”

G3.9

“SMS, ringtones”

G3.10

No comment.

G3.11

No comment.

G4.1

“Being able to be in contact with friends”

G4.2

“Easy to keep in contact.”

G4.3

“SMS”


E‐11

G4.4

“Multimedia integration, mp3 music videso photos cameras”

G4.5

“Ringtones, games”

G4.6

“Messaging.”

G4.7

“Ringtones, videos, camera, especially with high technology these days.”

G4.8

“most likely the designs of the mobile, games and mp3s on phones”

G4.9

“Camera, receiving messages, calls”


E‐12

POST TEST QUESTIONNAIRE Q1 I found it easy to build events.


G3.1 1 G3.2 1 G3.3 G3.4 1 G3.5 G3.6 G3.7 1 G3.8 G3.9 G3.10 1 G3.11 1 G4.1 1 G4.2 1 G4.3 1 G4.4 1 G4.5 1 G4.6 1 G4.7 1 G4.8 1 G4.9 1 TOTAL 13 2


E‐13


G3.2 No comment.

G3.3 No comment.

G3.4

“It was fun and easy.”

G3.5 No comment.

G3.6 No comment.

G3.7 “It was a bit difficult.”

G3.8 No comment.

G3.9

No comment.

G3.10

No comment.

G3.11

No comment.

G4.1

No comment.

G4.2

No comment.

G4.3

No comment.

G4.4

No comment.

G4.5

No comment.

G4.6

No comment.

G4.7

“Fun exciting.”

G4.8

No comment.

G4.9

No comment.


E‐14

Q2 The event builder is well structured.


G3.1 1 G3.2 1 G3.3 G3.4 1 G3.5 G3.6 G3.7 1 G3.8 G3.9 G3.10 1 G3.11 1 G4.1 1 G4.2 1 G4.3 1 G4.4 1 G4.5 1 G4.6 1 G4.7 1 G4.8 1 G4.9 1 TOTAL 4 9 2


E‐15


G3.2 No comment.

G3.3 No comment.

G3.4

No comment.

G3.5 No comment.

G3.6 No comment.

G3.7 No comment.

G3.8 No comment.

G3.9

No comment.

G3.10

No comment.

G3.11

No comment.

G4.1

No comment.

G4.2

No comment.

G4.3

No comment.

G4.4

No comment.

G4.5

No comment.

G4.6

No comment.

G4.7

“Needs improvement with cookies”

G4.8

No comment.

G4.9

“easy to follow instructions.”


E‐16

Q3 I can understand the process of building an event.


G3.1 1 G3.2 1 G3.3 G3.4 1 G3.5 G3.6 G3.7 1 G3.8 G3.9 G3.10 1 G3.11 1 G4.1 1 G4.2 1 G4.3 1 G4.4 1 G4.5 1 G4.6 1 G4.7 1 G4.8 1 G4.9 1 TOTAL 1 2 9 3


E‐17


G3.2 No comment.

G3.3 No comment.

G3.4

No comment.

G3.5 No comment.

G3.6 No comment.

G3.7 No comment.

G3.8 No comment.

G3.9

No comment.

G3.10

No comment.

G3.11

No comment.

G4.1

No comment.

G4.2

No comment.

G4.3

No comment.

G4.4

No comment.

G4.5

No comment.

G4.6

No comment.

G4.7

“easy to understand with instructions.”

G4.8

No comment.

G4.9

No comment.


E‐18

Q4 Building the event was an enjoyable process.


G3.1 1 G3.2 1 G3.3 G3.4 1 G3.5 G3.6 G3.7 1 G3.8 G3.9 G3.10 1 G3.11 1 G4.1 1 G4.2 1 G4.3 1 G4.4 1 G4.5 1 G4.6 G4.7 1 G4.8 1 G4.9 1 TOTAL 1 5 9


E‐19


G3.2 No comment.

G3.3 No comment.

G3.4

No comment.

G3.5 No comment.

G3.6 No comment.

G3.7 “Definitely”

G3.8 No comment.

G3.9

No comment.

G3.10

No comment.

G3.11

No comment.

G4.1

No comment.

G4.2

No comment.

G4.3

No comment.

G4.4

No comment.

G4.5

No comment.

G4.6

“Apart from it not publishing.”

G4.7

“Great teamwork.”

G4.8

No comment.

G4.9

No comment.


E‐20

Q5 I would like to make more events in future.


G3.1 1 G3.2 1 G3.3 G3.4 1 G3.5 G3.6 G3.7 1 G3.8 G3.9 G3.10 1 G3.11 1 G4.1 1 G4.2 1 G4.3 1 G4.4 1 G4.5 1 G4.6 1 G4.7 1 G4.8 1 G4.9 1 TOTAL 5 6 4


E‐21


G3.2 No comment.

G3.3 No comment.

G3.4

No comment.

G3.5 No comment.

G3.6 No comment.

G3.7 No comment.

G3.8 No comment.

G3.9

No comment.

G3.10

No comment.

G3.11

No comment.

G4.1

No comment.

G4.2

No comment.

G4.3

No comment.

G4.4

No comment.

G4.5

No comment.

G4.6

No comment.

G4.7

No comment.

G4.8

No comment.

G4.9

No comment.


E‐22

Preference levels These are subjective measures of the Cipher Cities interface taken after the test, with 1 being the best and 7 being the worst. The results show that the site has been well received by the participants and is viewed in a positive light. Qn1 Simple…………………3…2…1…0…1…2…3………Complex Qn2 User Friendly…….…3…2…1…0…1…2…3………Not User Friendly Qn3 Well Organized…...3…2…1…0…1…2…3………Messy Qn4 Attractive…….………3…2…1…0…1…2…3………Unattractive Qn5 I like……………....……3…2…1…0…1…2…3………I Dislike (1) (2) (3) (4) (5) (6) (7) Qn1 Qn2 Qn3 Qn4 Qn5 G3.1 2 3 4 3 2 G3.2 3 2 2 1 1 G3.3 G3.4 4 1 4 4 4 G3.5 G3.6 G3.7 5 1 1 1 1 G3.8 G3.9 G3.10 2 1 2 2 1 G3.11 3 1 2 1 2 G4.1 2 2 3 2 5 G4.2 3 1 2 3 1 G4.3 2 2 1 3 1 G4.4 1 1 1 1 1 G4.5 1 3 4 3 4 G4.6 1 1 2 1 1 G4.7 1 2 2 1 1 G4.8 5 6 5 3 3 G4.9 4 4 4 4 4 Mean: 2.6 2.06 2.6 2.2 2.1


E‐23

Additional Comments: “Publish didn’t work.” “Great, new way to learn.”


E‐24

Other observations: Participants asked for fields that would allow for multiple answers.

Site malfunctions in IE resulting in publish function not working.

Participants felt that larger text fields for questions and hints would be better.

There was some confusion with regards to whether the title would be displayed to the user.

Documents

CIPHER CITIES - eprints.qut.edu.au5.1 Web 2.0 28 5.2 Community Building 32 ... 7.2.10 Findings and Recommendations (Game Conceptualization) 91 ... 8.2.1 Step 1: Collection of Details