Mapping quality requirements for pervasive mobile games

ORIGINAL ARTICLE

Mapping quality requirements for pervasive mobile games

Luis Valente1,2• Bruno Feijo2

• Julio Cesar Sampaio do Prado Leite3

Received: 21 April 2014 / Accepted: 27 August 2015 / Published online: 14 September 2015

� Springer-Verlag London 2015

Abstract Games have not received the full attention of the

requirements engineering community. This scenario is

becoming more critical as we move towards newer forms of

games, such as pervasive games. Pervasiveness (the quality

that distinguishes pervasive games from traditional digital

games) holds several meanings, including being ubiquitous,

permeating something, or spreading something, somewhere,

in a physical space. Pervasiveness can be recognized in by

the boundaries of the game expanding every time it is played,

from the virtual (or fictional) world to the real world. Per-

vasive games are a new form of digital entertainment that has

evolved in different forms, such as alternate reality games,

transmedia games, and crossmedia games. Sensor technolo-

gies, networking capabilities, augmented reality systems,

computer vision technology, the internet, and, especially,

mobile devices have been responsible for the rapid evolution

of this new form of digital product. This paper is focused on

‘‘pervasive mobile games’’, which we define as context-

aware games that use mobile devices. We bear in mind that

mobile devices are currently the main driver for fulfilling the

promises of pervasive game playing. Our investigations and

experiments on this class of games led us to study the quality

requirements for pervasive mobile games. Using different

information sources, we gathered a set of interrelated char-

acteristics that are crucial to the success of these games. In

this paper, we begin to clarify the definition and scope of

pervasive mobile games, which are controversial issues in the

literature. Using these fundamentals, we propose a two-level

conceptual map of non-functional requirements that helps to

realize pervasiveness in pervasive mobile games. These non-

functional requirements are then associated with a set of

questions that help the designers in verifying tasks and

operationalizing the requirements of a game. We also pro-

pose a dependence matrix for pervasive game qualities that

enhances the insight into pervasiveness and reveals important

guidelines for the game designers.

Keywords Pervasive mobile games � Requirements

engineering � Non-functional requirements � Dependencematrix

1 Introduction

The problems of game software development have been

intensifying along with the growing demands of the video

game market—a market that is reported to reach $128

billion by 2017 [1]. Complexity is increasing, the quality

requirements are escalating, and the time to market has

been shortening. Although software engineering processes

have been applied to video game development, there are

few works on requirements engineering for video game

design [2]. Processes of video game requirements engi-

neering have unique characteristics when we compare them

& Luis Valente

[email protected]

Bruno Feijo

[email protected]

Julio Cesar Sampaio do Prado Leite

[email protected]

1 MediaLab/Institute of Computing, UFF, Av. Gal. Milton

Tavares de Souza, s/n8, Sao Domingos, Niteroi,

RJ 24210-346, Brazil

2 VisionLab/Department of Informatics, PUC-Rio, Rua

Marques de Sao Vicente 225, Gavea, Rio de Janeiro,

RJ 22451-900, Brazil

3 Department of Informatics, PUC-Rio, Rua Marques de Sao

Vicente 225, Gavea, Rio de Janeiro, RJ 22451-900, Brazil

123

Requirements Eng (2017) 22:137–165

DOI 10.1007/s00766-015-0238-y

http://crossmark.crossref.org/dialog/?doi=10.1007/s00766-015-0238-y&domain=pdf

http://crossmark.crossref.org/dialog/?doi=10.1007/s00766-015-0238-y&domain=pdf

to the processes found in the development of traditional

application software. Some of these characteristics are

discussed in academia and the industry, such as subjective

softgoals (e.g. gameplay, emotions, enjoyment, and fun),

the iterative nature of the requirements management, the

interdisciplinary nature of the development team, and the

fact that games are market-driven products [3–6]. This

whole situation becomes more critical when we move

towards mobile games [4]. In this paper, we focus on an

even less covered area: pervasive mobile games—a sub-

class of pervasive games where the main game device is a

mobile one.

Pervasive games are a recent form of entertainment that

brings the game experience out of the game device and into

the physical world, integrating both virtual and physical

realms. Early examples of pervasive games are Pirates! [7],

Pervasive Clue [8], and Botfighters [9]. The latter is a com-

mercial location-based mobile phone game. More recent

examples are Gbanga Famiglia [10] and Geo Hunters [11],

which are clearly classified as pervasive mobile games. Fig-

ure 1 illustrates Pervasive Word Search (Sect. 4), a pervasive

mobile game developed by the first author, where the goal is

to capture all letters of a word using sources that exist in the

physical world (like colours and Wi-Fi network names).

Historically, game development has been guided by

technological constraints, such as the design of algorithms

with the best possible optimizations regarding run-time and

memory performance. This had led to ad hoc development

that prioritized results over more sophisticated software

engineering methodologies [5].

The game development process is inherently multidis-

ciplinary, comprising activities as diverse as game design,

art production, and software development, among others.

These activities are integrated in two main phases: pre-

production and production. The preproduction phase con-

cerns the work of game designers and artists who produce

creative elements such as the game storyline, game rules,

and multimedia assets. The production phase refers to the

software development.

The integration of these teams that speak ‘‘different

languages’’ is an important (and complex) issue in game

development [3, 4]. The multidisciplinary nature of game

development often raises conflicts among the different

parties, as Callele et al. [3] note:

‘‘Game designers may not understand, for example,

the limitations of artificial intelligence when design-

ing non-player characters while software engineers

may not understand the creative vision or they may

be too willing to compromise that vision in the rush

to ship the product.’’

Callele et al. [3] also mention that many problems in

game development (including failure) arise from the lack

of adequate requirements engineering activities to bind the

preproduction and production phases. For example, a major

source of problems in game development processes relates

to ambitious scope and feature creep [12, 13]. Petrillo et al.

[12] also cite other problems, such as the cutting of features

during the development phase and delays or too optimistic

project schedules.

Requirements engineering in game development needs

to consider some issues that stem from the nature of games.

Games are applications that are designed for entertainment.

Traditional requirements engineering activities focus on

Fig. 1 Pervasive Word Search with the word ‘‘Reynold’’. The player captures a red colour from a red flower to eliminate the letters ‘‘r’’, ‘‘e’’,

and ‘‘d’’ from the target word

138 Requirements Eng (2017) 22:137–165

123

solving problems and supporting work activities, which are

different goals than those found in games.

By having entertainment as the main goal, games have

abstract non-functional requirements, such as fun, flow,

immersion, enjoyment, and delight [3–5]. These require-

ments are related to the emotional aspects that result from

playing a game. For this reason, some researchers refer to

these types of requirements as ‘‘emotional requirements’’

[3, 4], ‘‘psycho-chemical requirements’’ [5], and ‘‘affective

factors’’ [14]. More recently, Callele et al. [15] refine

‘‘emotional requirements’’ into ‘‘experience requirements’’,

which include emotional factors, gameplay factors, and

sensory factors. Apart from these recent advancements,

understanding these requirements in a requirements engi-

neering process is an open issue.

Another problem related to the definition of require-

ments in games stems from the fact that games are mass-

market products. This means that when designing a game,

the real users are unknown. This is similar to what Potts

[16] observed for the construction of commercial off the

shelf software (COTS) requirements; that is, there is no

clear interface between ‘‘customers’’ and ‘‘developers’’.

The game designer ends up acting as the ‘‘customer’’ in the

preproduction phase, which is not a good alternative as the

game designer may produce biased requirements (espe-

cially the ones related to emotional factors such as ‘‘fun’’).

In this regard, the game designer needs support from sev-

eral confirmation techniques, such as focus groups [17].

In this paper, we do not start investigating how sub-

jective softgoals (gameplay, emotions, enjoyment, and fun)

of mass-market products could be modelled and measured.

Instead, we are interested in learning about what makes a

game pervasive—unique qualities and characteristics that

make pervasive games different from traditional digital

games. In this regard, we search for non-functional

requirements (NFRs) that map quality requirements related

to pervasiveness for pervasive mobile games. The perva-

sive mobile games are a subset of pervasive games that use

context-aware mobile devices to enable the interaction

between the environment (physical world) and the virtual

world. This map is based on concrete information sources,

such as books, academic articles, game analyses, and

hands-on experience. Our starting point is an analysis of

the definition and scope of pervasive games, which we

claim contributes to and sheds more light on these currently

controversial issues. Then, we come up with two levels of

non-functional requirements, which are associated with a

set of questions that help the designers in the tasks of

verifying and operationalizing the requirements of a game.

Additionally, we propose a dependence matrix for perva-

sive game qualities that enhances the insight into perva-

siveness and reveals important guidelines for the game

designers. As far as we are aware, there is no other work on

requirements engineering for pervasive mobile games in

the literature. We hope that our proposals can help the

industry to produce better games. Our research work is

pushed by three questions:

R1 What are pervasive games?

R2 What are the differences between pervasive games

and traditional computer games?

R3 How do we make a pervasive mobile game?

We define the results of a requirements construction

process applied to pervasive mobile games as ‘‘a knowl-

edge mapping for pervasive mobile games’’ or ‘‘quality

model for pervasive mobile games’’. Based on the ideas of

Arango&s domain analysis [18], we have performed this

process on the field of pervasive mobile games to answer

questions R1 and R2. Arango [18] defined domain analysis

as ‘‘the identification and acquisition of reusable informa-

tion in a problem domain to be reused in software speci-

fication and construction’’. Domain analysis is part of a

domain engineering process, which Arango [18] defined

originally as a process that concerns producing a reusable

infrastructure to solve problems in a domain.

In the area of software requirements, the term ‘‘non-

functional requirements’’ has been defined differently by

different authors, as surveyed by Glinz [19]. Although

there are discussions about ‘‘non-functional requirements’’

as ‘‘just quality-driven requirements’’ and about ‘‘non-

functional requirements’’ as ‘‘general constraints over

requirements’’, it is a fact that in general quality issues are

treated as non-functional requirements. In this paper, we

use these terms as synonyms: ‘‘non-functional require-

ments’’, ‘‘quality requirements’’, and ‘‘quality’’.

Referring to ‘‘quality attributes’’ is a common practice in

the software architecture area [20]. In software engineer-

ing, Freeman [21] distinguished between basic qualities

(functionality, reliability, ease of use, economy, and safety)

and extra qualities (flexibility, reparability, adaptability,

understandability, documentation, and enhanceability).

Interestingly enough, Freeman [21] defines ‘‘functionality’’

(the cornerstone of software construction) as a ‘‘quality’’.

The remaining qualities have been grouped together as

‘‘non-functional requirements’’, which denotes other qual-

ities in addition to software ‘‘functionality’’.

This paper is organized as follows. Section 2 summa-

rizes the answer to the question R1, while Sect. 3 decom-

poses the qualities of pervasiveness that differentiate

pervasive games from traditional computer games, where

we contribute to partially elucidate questions R2 and R3.

More specifically, Sect. 3 describes a map about pervasive

games knowledge, which includes the process that we

conducted to build this knowledge. This map comprises the

following parts: our vision on pervasive mobile games as a

subset of pervasive mobile games (Sect. 3.1), the

Requirements Eng (2017) 22:137–165 139

123

conceptual map with non-functional requirements

(Sect. 3.2), set of questions to be used to verify and oper-

ationalize the requirements (i.e. the checklists, in

Sect. 3.3), and the dependence matrix of pervasive game

qualities (Sect. 3.4). In Sect. 4, we use the proposed map to

describe how the pervasiveness qualities apply to a work-

ing pervasive mobile game developed by the authors.

Section 5 discusses related works in the literature. Finally,

Sect. 6 concludes the paper and presents some directions

for future works.

2 What pervasive games are: a critical review

While conducting research about pervasive games, we

noticed lack of consensus on definitions and formalisms

about these types of games. We noticed that this field is

highly interdisciplinary and that the approaches to perva-

sive games can be loosely divided into two broad groups:

‘‘cultural’’ and ‘‘technological’’ approaches.

In our interpretation, we use the term ‘‘cultural

approach’’ to refer to approaches originated in the artistic

and social areas, such as design, game studies, and social

studies. The authors in cultural approaches tend to use the

term ‘‘pervasive’’ in its original literal sense (e.g.

‘‘spreading widely throughout an area or a group of peo-

ple’’ [22]) to indicate that some game aspects defy or

expand concepts that are considered central in traditional

game definitions (such as ‘‘the magic circle’’ [23]). Cultural

approaches are more concerned with aspects of gameplay

and the game itself, not emphasizing technology and per-

vasive computing. As an example, for some researchers in

this area [24]) a pervasive game may not use (computing)

technology at all. In these approaches, the concept of

‘‘pervasive games’’ can be very broad, encompassing

simple mobile phone games to ‘‘artistic events’’ with

complex infrastructure.

We use the term ‘‘technological approaches’’ to denote

approaches that place more emphasis on the underlying

technological aspects needed to realize pervasive games.

These approaches often discuss pervasive games through

these ideas: (1) as applications of pervasive/ubiquitous

computing, or context-aware applications; and (2) ‘‘com-

puter-augmented’’ games.

During the literature review, we noticed a set of recur-

ring themes that some authors based upon to discuss per-

vasive games. In this section, we use the term

‘‘perspective’’ to denote a specific theme or set of themes

that underlies a pervasive game discussion. Table 1 sum-

marizes the main perspectives that we identified in the

pervasive game literature.

The work by Nieuwdorp [25] was the first attempt at

clarifying the confusion in the pervasive game discourse.

She used a dichotomy between ‘‘game studies’’ and

‘‘technology’’ to analyse the discussion on pervasive game

research. We agree with Nieuwdorp [25] that the two

perspectives proposed by her (‘‘cultural’’ and ‘‘technol-

ogy’’) are the most appropriate ones to define the basic

approaches to pervasive games. Nieuwdorp [25] explains

that the technological perspective use ‘‘pervasive’’ to

denote ‘‘the technology the games are played with’’, while

the cultural perspective uses ‘‘pervasive’’ ‘‘to describe the

way the game itself (due to this technology) is played in a

real-world setting, and as such blends with it’’.

The ‘‘computer-augmented’’ game perspective considers

the notion of existing real-world (physical) games (e.g.

‘‘capture the flag’’ games) being ‘‘upgraded’’ with some

sort of computing. Magerkurth and co-authors [28] go

further in this regard and consider as ‘‘pervasive games’’

what they categorized as smart toys, affective gaming,

augmented table-top games, and augmented reality games.

This idea implies the existence of a ‘‘mixed-reality’’—the

result of interleaving a virtual layer over a physical world.

We understand that mixed reality is an essential charac-

teristic of pervasive games. Furthermore, this characteristic

is a continuum in the sense presented by Milgram and co-

authors [36], who propose a ‘‘reality-virtuality continuum’’

to represent the varying degrees of complexity that any

mixed-reality situation can exhibit, as Fig. 2 illustrates. We

consider the ‘‘computer-augmented game’’ vision broader

than the ones based on pervasive and ubiquitous computing

concepts (as it includes ‘‘toys’’), although considering

‘‘toys’’ as ‘‘games’’ is up to debate.

In the ‘‘cultural, theatre, technology’’ perspective,

McGonigal [30, 37] propose a broad domain of ‘‘pervasive

play and performance’’ for ‘‘ubiquitous games’’, ‘‘ubicomp

games’’, and ‘‘pervasive games’’. McGonigal [37] defines

‘‘pervasive play’’ as ‘‘consisting of mixed-reality games

that use mobile, ubiquitous and embedded digital tech-

nologies to create virtual playing fields in everyday

spaces’’. She argues that the ‘‘performance’’ aspect enables

the players to maximize their play experience by

Table 1 Perspectives on pervasive games

Perspective Main references

Cultural and technological

dichotomy

Nieuwdorp [25]

Cultural or game studies

approach

Montola et al. [24], Montola et al.

[26], Davies [27]

‘‘Computer-augmented’’ game Schneider and Kortuem [8],

Magerkurth et al. [28], Saarenpaa

[29]

Cultural, theatre, technology McGonigal [30]

Technology, ubiquitous and

pervasive computing,

sensors

Magerkurth et al. [28], Linner et al.

[31], Capra et al. [32], Walther

[33], Hinske [34], Benford [35]


123

performing instead of just participating in the game, thus

becoming ‘‘game actors’’. She defines ‘‘pervasive games’’

as ‘‘performance-based interventions that use game ima-

gery to disrupt the normative conventions of public spaces

and private technologies’’ [30], while ‘‘ubicomp games’’

are advanced game prototypes (possibly with custom

hardware) for research into new ubiquitous computing

technologies. Finally, she considers ‘‘ubiquitous games’’ as

commercial entertainment projects that bring computer

games to the real world.

The ‘‘technology, ubiquitous and pervasive computing,

sensors’’ perspective focuses on issues related to context-

aware applications, mainly considering the games as

applications of ubiquitous and pervasive computing. The

perspectives that focus on these kinds of technology often

refer to the concepts of ‘‘pervasive/ubiquitous computing’’

and ‘‘context-awareness’’ with different meanings, which

can be rather confusing. In pervasive games research these

three concepts (pervasive computing, ubiquitous comput-

ing, and context-aware systems) are often correlated.

Nieuwdorp [25] presents a comprehensive analysis on how

researchers use these terms in pervasive game discussion.

Our analysis on these kinds of perspective is as follows.

Ubiquitous computing is a concept that Weiser [38]

proposed in 1991 for the next wave of computing, when

technology would recede into the background of people’s

lives. In this paradigm, computing devices would be

embedded (and hidden) in environments, adapting their

behaviour to human activities. The devices would be small,

inexpensive, networked, and context-aware. The users

would not have to ‘‘think about computers’’ when using

ubiquitous computing applications. Seven years later, IBM

came up with the term ‘‘pervasive computing’’. Their

vision was the possibility to access information and ser-

vices, anytime, anywhere, focusing on ‘‘e-business’’ [39].

Their focus was on e-business and on the corporate world,

and they related ‘‘pervasive computing’’ to mobile com-

puting and wireless technologies. The original pervasive

computing concept relates to the original sense of the word

‘‘pervasive’’ (as found in Oxford English Dictionary [22]).

After considering all issues above mentioned, we have

the following understanding about what a pervasive game

is. Firstly, we understand that ubiquitous computing

applications use context-awareness to implement their

vision in some environment (called the ‘‘smart environ-

ment’’ by ubiquitous computing researchers). This idea

may seem that in ubiquitous computing, the ‘‘smart envi-

ronment’’ is a place of very restricted in size (like a small

room). We consider that a system is ‘‘context-aware’’ if ‘‘it

uses context to provide relevant information and/or ser-

vices to the user, where relevancy depends on the user’s

task’’, as wrote Dey [40]. Dey [40] defines context as fol-

lows: ‘‘any information that can be used to characterize the

situation of an entity. An entity is a person, place, or object

that is considered relevant to the interaction between a user

and an application, including the user and applications

themselves’’. Then, we realize that ‘‘pervasive computing’’

is a way to expand the ubiquitous computing concept to

larger environments and spaces. In this context, pervasive

computing emerges as the key technology to create the

mixed-reality situation found in pervasive games. There-

fore, we are tempted to adopt a technological perspective to

define a pervasive game as a context-aware game system

that has the following characteristics:

• The game is constantly coming back to the real world,

which means that the game is played in physical places

and it is not constrained to stationary computing

devices;

• The physical world (places, objects) is part of the game,

and it is combined with the virtual world;

• Mixed reality is always existent, and it is created

through pervasive computing technologies;

• The spatial mobility occurs in a physical ‘‘open’’

environment; that is, the ‘‘game world boundary’’ is not

‘‘well-defined’’, and sometimes it can be unconstrained;

• The players use mobile devices (e.g. smartphones,

tablets, custom hardware) to interact with the game and

with other players;

• The game may last for several days or weeks (or more),

blending with the daily lives of players. The game may

define a persistent world that progresses without player

intervention. If some important event happens in the

game, the game may notify the player to take action.

These aspects are not mandatory;

Fig. 2 The reality-virtuality

continuum. Extracted from [36]


123

• The game may focus on promoting social interaction

among players. Social interaction in a pervasive games

may happen directly (face-to-face interaction) or indi-

rectly (mediated through technology). This aspect is not

mandatory as pervasive games may be single-player

games.

Although this attempt to define pervasive games covers

the characteristics found in the majority of the definitions

analysed in our literature review, it is too broad to allow an

effective support to the game designer. Therefore, in the

next section, we narrow down our scope to pervasive

mobile games.

3 Building our map

In this section, we present the process we have used to

elicit, model, and analyse the knowledge related to quality

requirements for pervasive mobile games. To understand

what pervasive games and pervasive mobile games are,

firstly we had to select suitable information sources [41] to

start the elicitation process. The available information

sources were reading material (books and academic arti-

cles), analyses of game projects, and hands-on develop-

ment experience. The key information source for the

elicitation process was the reading material. The elicitation

process was pushed by these research questions outlined

formerly:

R1 What are pervasive games?

R2 What are the differences between pervasive games

and traditional computer games?

R3 How do we make a pervasive mobile game?

We started the elicitation process by searching for

specific journals and conferences dedicated to pervasive

games. We discovered no specific journals for pervasive

games. Conferences dedicated to pervasive games are

nearly non-existent, with PerGames (‘‘International

Workshop on Pervasive Gaming Applications’’,

2004–2007) being a rare example. In 2014, a new confer-

ence dedicated to pervasive games emerged also as ‘‘Per-

Games’’ (‘‘International Conference on Pervasive

Games’’), although it is not related to the former initiative.

Considering this situation, we explored the following areas:

game development, entertainment computing, and perva-

sive computing. An important information source that we

discovered was the IPerG project [42], which was a large

European project dedicated to studying pervasive games

that spanned from 2004 to 2008. The IPerG project pub-

lished several papers, technical reports, and pervasive

game prototypes. Besides the PerGames conferences and

IPerG project, we searched for relevant works in the main

publishers ACM, IEEE, and Springer, which included

proceedings of conferences dedicated to traditional games

and digital entertainment. Examples of these conferences

include ACE (ACM International Conference on Advances

in Computer Entertainment), ICEC (IFIP International

Conference on Entertainment Computing), and DiGRA

(International Conference on Digital Games Research

Association). We also searched for initiatives in non-aca-

demic domains because game developers usually share and

discuss the state-of-the-art information through informal

channels, such as discussion forums and game develop-

ment portals.

The elicitation process was based on keywords, such as:

pervasive games, ubiquitous computing, mixed reality,

games, context-awareness, context-aware games, mobile

game development, and location-based games. We selected

and rejected papers firstly by evaluating the paper title. If

the title seemed important to our research work, we eval-

uated the abstract. If the paper abstract suggested that the

paper could answer our research questions, we kept the

paper for further reading. Otherwise, we did a quick read to

check whether the paper was really not important to discard

it with more confidence. We were especially interested in

papers that described actual pervasive game projects.

While conducting the process to map pervasive game

knowledge, we discovered that the literature lacks con-

sensus on definitions and formalisms about pervasive

games. The literature also mixes up issues related to

diverse areas, such as game design and computer science.

Moreover, we realized that most of the pervasive games

definitions are excessively broad to support a quality

requirements mapping for pervasive games. With these

initial findings, we understood that we needed to narrow

our scope to find answers to our three research questions.

We were also interested in developing pervasive games

with mobile devices from the very beginning. In this

regard, we established criteria to define ‘‘pervasive mobile

games’’—a set of the possible pervasive games found in

the literature, which roughly correspond to context-aware

games that use mobile devices. Section 3.1 discusses in

detail our vision on ‘‘pervasive mobile games’’, and

Table 2 summarizes the defining criteria to select game

projects according to our vision.

Pervasive games and pervasive mobile games have

unique characteristics that distinguish these kinds of games

from traditional computer and mobile games. We consider

that these characteristics contribute to an overall quality of

‘‘pervasiveness’’. Pervasiveness is a quality that makes

pervasive mobile games unique and very different from

traditional computer-based games. According to our

investigation, pervasiveness seems to be an implied and

taken for granted concept in pervasive game discussion. It

is very difficult to define ‘‘pervasiveness’’ objectively


123

because it is an elusive and subtle concept. As we were

interested in developing pervasive mobile games, we

noticed that understanding characteristics that contribute to

in these kinds of games (i.e. ‘‘what makes a game perva-

sive’’) could be more practical in fulfilling our goals of

creating pervasive mobile games than trying to model

pervasiveness itself in a top-down approach. With this idea

in mind, we started investigating the pervasiveness quality

in pervasive mobile games using the following concrete

information sources:

• Twenty-four game projects, summarized in Table 3;

• Books and academic articles related to pervasive

games, which were retrieved from the literature using

these keywords: pervasive games, ubiquitous comput-

ing, mixed reality, games, context-awareness, context-

aware games, mobile game development, and location-

based games;

• The mobile game development experience of the first

two authors, which includes developing games using

embedded sensors.

Using the criteria defined in Table 2, we selected 24

projects to analyse. Table 3 presents these games. We

included games that are not part of the domain and some

borderline cases. Due to space constraints, the reader

should refer to [43] for descriptions and main references

regarding the games in Table 3. Valente and Feijo [43] also

provide information about platforms, sensor, and net-

working technologies that these games use (when

applicable).

The ‘‘borderline cases’’ in Table 2 refer to ‘‘transmedia

pervasive games’’ and games that use other media and

devices as secondary (support) modules. We discuss these

issues in Sects. 3.1.2 and 3.1.3. The game Day of Figurines

is a pervasive game based on mobile devices. However, it

is not part of the domain because it does not satisfy the

mandatory condition C1 in Table 2. Although this game is

out of the domain, it presents some qualities (related to

pervasiveness) that other pervasive mobile games share. In

order to map the knowledge about pervasive mobile games,

we have followed a process composed of 10 steps, which

we detail below:

1. Contextualizing: we started a literature review to

understand what pervasive games were all about;

2. Eliciting from the literature (an information source):

we became overwhelmed and confused about what to

consider as ‘‘pervasive games’’ because we discov-

ered several perspectives from which to approach this

subject. Therefore, we decided to establish criteria to

select suitable games that matched our interests

(develop pervasive games using context-aware

mobile devices). We named the games that matched

these criteria as ‘‘pervasive mobile games’’

(Sect. 3.1);

3. Eliciting from the literature (an information source),

but using feedback from step 2: we started another

literature review, now focused on selecting games

that matched our criteria for pervasive mobile

games.

4. Eliciting from the game experience (an information

source): we started analysing the selected games with

these questions in mind: (1) ‘‘what features does this

game have that makes it a pervasive game?’’; and (2)

‘‘how is this game different from traditional computer

games?’’. Intuitively, this analysis was influenced by

the experience of the first two authors in researching

and developing games;

5. Mapping or modelling the knowledge (conceptual

maps): we gathered all of the material that we have

collected and started to refine it. We were able to

identify an initial list of 16 qualities that pervasive

mobile games have in common. At that time, we had a

single set of first-level qualities for pervasiveness.

Later (step 6), we understood that they were actually

second-level qualities—Fig. 3 illustrates them;

6. Mapping (conceptual maps): while analysing these

qualities, we ‘‘tagged’’ them using labels that meant an

Table 2 Boundary criteria for pervasive mobile games

Condition Description

C1* Games that are context-aware

C2* Games using mobile devices (e.g. tablets, smartphones)

C3 Games that access remote data on the move

C4 Multi-player games

The asterisk denotes mandatory condition

Table 3 Games selected according to the criteria summarized in

Table 2

Condition Games

Out of the

domain

Day of figurines

Borderline

cases

Can you see me now?, Uncle Roy all around you,

Mogi*, Epidemic Menace, Botfighters*, GPS

Mission*, Manhattan Story Mashup

1 and 2 The Journey*, Ere Be Dragons, Pervasive Clue,

REXplorer*

1 and 2 and 3 –

1 and 2 and 4 Pirates!, PAC-LAN, Feeding Yoshi

All conditions Songs of North, Tycoon, Hitchers, Mythical: The

Mobile Awakening, Seek n0 Spell* , Gbanga

Famiglia*, Gigaputt*, GEO Hunters*, Insectopia,

and borderline cases

The asterisk denotes commercial projects


123

attempt at classifying these qualities into groups. Later,

we refined these tags and came up with an initial set of

six qualities (‘‘first-level qualities’’) that grouped

second-level qualities. At a later step (step 10), we

have refined this initial set of first-level qualities and

arrived at the results that Fig. 3 illustrates;

7. Analysis (verification): for each second-level quality,

we identified motivations in the literature to support

each one. In other words, for each quality we collected

use cases in game projects, design rationales, and other

examples that justified the existence of the referred

quality;

8. Mapping (checklists): we used the motivations and

examples identified in step 7 to elaborate checklists for

each second-level quality.

9. Analysis (verification) and mapping (matrix): while

analysing the second-level qualities (by checking the

literature and comparing our results), we noticed that

some qualities could influence or interfere with other

qualities. We recorded these dependencies as a

matrix;

10. Refining the results: we submitted all results (the first-

and second-level qualities, checklists, and depen-

dence relationships) to a requirements engineer expert

for feedback about the process that we conducted to

build our knowledge about pervasive mobile games.

Based on the feedback we received, we refined these

results.

Next subsections present our vision on pervasive mobile

games (Sect. 3.1), the conceptual map (Sect. 3.2), the

checklist (Sect. 3.3), and the dependence matrix, which

represents correlations among qualities (Sect. 3.4).

3.1 What are pervasive mobile games?

We realize that mobile devices are currently the main

driver to fulfil the promises of pervasive game playing

because they are naturally networked, full of sensors,

widespread, and easily accessible. In this context, we

define a ‘‘pervasive mobile game’’ as a game that is played

in the physical world, where players use context-aware

mobile devices to enable the interaction between the

environment (physical world) and the virtual world. To

support mixed-reality situations, we understand that per-

vasive mobile games must be ‘‘context-aware’’. We follow

the definitions created by Dey [40] regarding the concepts

of ‘‘context’’ and ‘‘context-awareness’’.

We use the term ‘‘mobile device’’ for a device that has

the following characteristics:

1. They have networking capabilities that are not limited

to a specific physical place. Examples include mobile

phones and tablets that use networking infrastructure

provided by a mobile operator;

2. They are portable devices—battery-powered devices

that users are able to carry around;

A ‘‘context-aware mobile device’’ is a ‘‘mobile device’’

equipped with sensors that enable it to sense ‘‘relevant

context’’ [40], especially environmental properties.

By using context-aware mobile devices as elements of a

mixed-reality situation, pervasive mobile games are able to

Fig. 3 Non-functional requirements view on pervasiveness for pervasive mobile games


123

have game activities out in open areas or at least not

confined to the static nature of using desktop computers. A

consequence is that these games may require or foster

player movement in local spaces (not necessarily using

network resources on the move).

We see pervasive mobile games as having three general

types, regarding player participation:

• Single-player. This corresponds to a game played with

mobile devices that does not use network resources;

• Single-player connected. This is a single-player game

that uses network resources;

• Multi-player. This is a context-aware game with

multiple players that are connected through a network.

The players can be co-located or not.

Referring to the defining criteria for pervasive mobile

games (Table 2), ‘‘single-player’’ games satisfy conditions

(C1, C2), ‘‘single-player connected’’ games satisfy condi-

tions (C1, C2, C3), and ‘‘multi-player’’ games satisfy all

conditions. Currently, we consider smartphones and tablets

as the main platform for pervasive mobile games because:

• These devices are easily accessible to the general

public;

• These devices are equipped with embedded sensors that

make it possible to implement (some) context-aware-

ness required by pervasive mobile games;

• These devices make it possible to have mobility in

pervasive mobile games (e.g. gameplay in physical

places using networking or not).

We do not consider ‘‘portable’’ or ‘‘mobile’’ games as

pervasive mobile games. Both types of games are played

with mobile devices. However, a ‘‘portable game’’ is not

context-aware and does not use networking. A ‘‘mobile

game’’ requires networking, but it is not context-aware.

The concepts we have developed so far are not enough

to support a proposal of quality requirements for perva-

sive mobile games. Therefore, we have to develop a

number of other concepts to underlie a conceptual map

for quality requirements related to pervasiveness. The

rest of this section is dedicated to these new concepts,

which are: pervasive experience, transmediality, game

scene complexity, and game autonomy. For simplicity,

henceforth we will use the terms ‘‘mobile device’’ and

‘‘context-aware mobile device’’ as synonyms, mainly

referring to ‘‘smartphones and tables’’, unless otherwise

indicated. We expect that in the near future new classes

of context-aware mobile devices become important for

pervasive mobile games. Examples include wearable

devices such as ‘‘smart glasses’’, ‘‘smart bands’’, and

‘‘smart watches’’.

3.1.1 The pervasive experience

We define ‘‘pervasive experience’’ as the experience that

arises from playing the pervasive mobile game. This defi-

nition is the starting point to understand pervasiveness.

Moreover, pervasive experience can be used as an infor-

mation source in knowledge elicitation.

The pervasive experience occurs in mixed-reality envi-

ronments. As a consequence, physical spaces are always

present in pervasive experiences, as physical spaces are

required to build a mixed-reality environment. Further-

more, the pervasive experience is essentially ‘‘local’’

because this type of experience emerges when the player is

playing the game in some place.

We understand that ‘‘pervasiveness’’ is an inherent

quality of a pervasive experience. However, trying to

define pervasiveness is a difficult task because this is an

abstract concept. Instead of trying to define pervasiveness,

we understand that it is more practical to investigate the

qualities that contribute to create pervasiveness. In

Sect. 3.2, we present a conceptual map of pervasiveness in

terms of non-functional requirements that contribute to this

quality.

3.1.2 Pervasive games and transmediality

There are some pervasive games (e.g. Epidemic Menace

[44]) that offer several modes of participation. In these

games, players are able to use different types of devices

(such as mobile phones and desktop PCs) to perform dif-

ferent types of tasks in a complementary way. Players

usually have distinct roles and experience different envi-

ronments. Some researchers [44, 45] have used the term

‘‘crossmedia games’’ to refer to these types of games,

referring to each mode of participation as a ‘‘gaming

interface’’. In this concept, a game interface (or game role)

is part of a greater whole (the game). However, we con-

sider ‘‘transmedia pervasive game’’ a more adequate term

to refer to those types of games, as we understand as

‘‘transmediality’’ the possibility of a game offering differ-

ent participation modes (game roles) through different

devices, media, or environments. In contrast, we consider

as ‘‘crossmedia games’’ the games that can be played on

different (heterogeneous) devices but offer only one mode

of participation.

Transmedia pervasive games may offer some game

interfaces (or participation modes) based on context-aware

mobile devices, as do Can you see me now? [46] and Mogi

[47]. These game interfaces share the same concerns as the

ones found in general pervasive mobile games. In this

paper, we consider these kinds of games as ‘‘borderline


123

pervasive mobile games’’—we refer to the quality of

transmediality for these games, but we are not concerned

about general forms of transmedia pervasive games. In

other words, in this paper we present a conceptual map for

pervasiveness that concerns only the mode of participation

that is carried out through the mobile device. We have

identified some general cases of pervasive mobile games

concerning the concepts presented in this section:

1. The game offers just one game interface, based on

context-aware mobile devices. This includes games

that are available for multiple mobile platforms, such

as Android and iOS. In this case, there is no

transmediality;

2. The game offers several game interfaces, some of them

based on context-aware mobile devices and some of

them based on other kinds of devices (e.g. portable

devices, laptops, desktop computers). Each game

interface is tied to a specific type of device. In other

words, a game interface designed for a mobile device

cannot be played with a laptop computer. These are the

‘‘borderline pervasive mobile games’’;

3. The game offers several game interfaces, all of them

based on context-aware mobile devices. The mobile

device can be used with any of the available game

interfaces. In this case, there is no transmediality;

4. The game offers game interfaces (based on context-

aware mobile devices) and offers secondary interfaces

(based on other kinds of device or not) for support

purposes. For example, in Botfighters [9] players use a

web module (on desktop PCs) to configure their game

avatar, while the actual gameplay is carried out on a

mobile phone. In these cases, we consider that there is

no transmediality.

Referring to the conceptual map of pervasiveness that

Sect. 3.2 presents, transmediality contributes to a quality of

pervasiveness called ‘‘accessibility’’.

3.1.3 Game scene complexity and game autonomy

The integration of the physical and virtual worlds through

context-awareness in pervasive games creates a mixed-re-

ality environment that we refer to as game scene. The game

scene may have various degrees of complexity depending

on the number and types of systems and objects that

compose the mixed-reality environment. We identify three

general cases of increasing game scene complexity:

GSC1 The game scene content is generated dynamically

solely though sensors. Our prototypes Pervasive

Word Search (Sect. 4) and Insectopia [48] are

examples of this case;

GSC2 The game scene uses predetermined context. For

example, the game might require a player to reach

specific physical locations (e.g. a square in a city)

to complete game activities. Examples are Uncle

Roy all around you [49] and PAC-LAN [50]. This

also includes requiring a specific physical place

for the game scene (e.g. a museum, a school

floor);

GSC3 The game scene requires some dedicated and

customized infrastructure to support the mixed-

reality. For example, the infrastructure may take

form as local networking, tracking technologies,

placing sensor technologies in the physical

environment, and placing environment devices in

the game area. This case encompasses several

subcases of different complexities regarding the

required infrastructure and required environment

devices

Environment devices are physical objects that reside in

the physical environment where the game happens, and

they may be able to generate effects or behaviours in the

physical world. Some possibilities for environment devices

are (this is by no means an exhaustive list):

1. Simple output devices, not limited to digital media

(e.g. public displays, audio speakers, smell generators,

weather effects, heat generators, and smoke

generators);

2. Smart objects (input only);

3. Smart objects (input and output);

4. Mechanical or electrical devices equipped with actu-

ators (e.g. sliding doors, elevators, wind generators).

Smart objects are custom computing devices equipped

with sensors and may have networking and output capa-

bilities (not limited to digital media). These devices may be

connected to other smart objects and to a central entity (e.g.

a server) that runs the game. Smart objects may be sta-

tionary or moving.

The literature provides some examples of using objects in

similar ways as the environmental devices that we described

in this section, concerning pervasive games and interactive

installations. The ALICE project [51] creates mixed-reality

environments using public displays and mechanical devices

equipped with actuators. In Manhattan Story Mashup [52],

the game uses a public display to convey information to

players. The Fun-in-Numbers project [53] presents several

interactive installations that use physical objects to com-

municate with players. An example is Magnetize Words

[54], which uses light sources as output devices. Montola

and co-authors [55] present a game using wireless sensor

devices, which could be considered as a type of smart object.


123

Game autonomy refers to what degree the game is able

to exist as an independent system. Game autonomy is

directly related to the game scene complexity, in the sense

that a game with high autonomy requires a low degree of

scene complexity. Two general classes of pervasive mobile

games arise from the concept of game autonomy: ‘‘event

games’’ and ‘‘autonomous games’’. Autonomous games are

able to function independent of other systems and require

no specific places and time to happen, presenting high

game autonomy. On the other hand, event games are per-

vasive games that happen at a specific time and physical

place, for a specific duration, presenting low game auton-

omy. These games may require specific infrastructure. We

can say that these two classes of games represent the

opposite sides of a game autonomy spectrum. Event games

usually share some of the following characteristics:

• The game may happen in a predetermined area. For

example, this area could be a room, a museum, or some

specific city area;

• The physical place where the game takes place is

augmented with technology (as sensors) that enables

important game features. This requires the place to be

prepared before game sessions;

• The game may use human actors as live non-player

characters;

• The game may require orchestration, which means

providing real-time in-game support to help players in

difficulty and to prevent issues from impairing the

game session. More information about this concept can

be found in [56];

• The game may require custom hardware;

• The game may require local wireless networking;

• The game may have a specific time to start and has a

specific duration;

• They may use references to local physical context (e.g.

specific addresses, statues, buildings) as part of the

game.

The game scene complexity also impacts the networking

requirements of a pervasive mobile game. For example,

games that fall in cases GSC1 and GSC2 may require no

networking. Games that fall in case GSC3 require net-

working in most cases. Referring to the conceptual map of

pervasiveness that Sect. 3.2 presents, game autonomy

contributes to a quality of pervasiveness called ‘‘context-

awareness’’. In its current version, this conceptual map

concerns games in cases GSC1, GSC2, and some cases of

GSC3.

3.2 The conceptual map

Figure 3 illustrates a two-level conceptual view on the

pervasiveness quality for pervasive mobile games,

according to our investigation. After studying the 24

selected games (Table 3) and exploring the mobile game

development experience of the first two authors (that

includes games using embedded sensors), we were able to

identify sixteen pervasive game qualities (the second-level

qualities in Fig. 3). Later on, we grouped these sixteen

qualities into the seven first-level NFRs (non-functional

requirements) that Fig. 3 illustrates. Each non-functional

requirement contributes to create pervasiveness, but none

of them in isolation is able to describe the entire perva-

siveness quality. In Fig. 3, we have defined acronyms that

appear in the checklist tables (Sect. 3.3) and in the

dependence matrix (Sect. 3.4, which presents correlations

among qualities).

These results are our first attempt at identifying impor-

tant qualities of pervasiveness. We do not claim that these

results are complete—a more definitive pervasive quality

list would require further investigation about design theory

and additional inspections using more games and

designers.

3.3 The checklists

The checklists are a set of questions that designers can use

to evaluate pervasive game qualities (and thus, pervasive-

ness) in existing projects. We have formulated the check-

lists related to each NFR using two information sources:

1. Observing how the pervasive game qualities were

applied in the pervasive mobile games that we have

studied;

2. The experience of the first two authors in developing

context-aware mobile games.

We were able to identify seven first-level non-functional

requirements that contribute to create pervasiveness: spa-

tiality, sociality, permanence, accessibility, context-

awareness, communicability, and resilience. Each non-

functional requirement contributes to create pervasiveness,

but none of them in isolation is able to describe the entire

pervasiveness quality. Figure 3 illustrates these first-level

qualities along with the second-level pervasive game

qualities that contribute to them. This section describes

each of these non-functional requirements.

The checklists for each quality have questions of dif-

ferent natures. There are questions that ask whether an

aspect of the quality is applicable (‘‘do’’ and ‘‘are’’ type of

questions) and that are questions that ask ‘‘how’’ some

aspect of the quality applies or not (i.e. ‘‘how’’, ‘‘what’’,

and ‘‘which’’ questions). The ‘‘how’’ questions implicitly

ask whether the aspect is present or not (i.e. these questions

include an implicit ‘‘do’’ or ‘‘are’’ question), which means

that they only make sense if the implicit ‘‘do’’ or ‘‘are’’

question is true. The ‘‘how’’ questions invite the designer


123

or developer to investigate how that aspect is present or to

formulate a solution to have that aspect present in a game.

3.3.1 Spatiality (Spa)

Spatiality refers to aspects related to the physical space

usage. For example, it includes how the game defines the

‘‘game scene’’, how the game influences the physical

space, and how the physical space influences the game.

Mobility (Mob, Table 4) This quality relates to two gen-

eral aspects. The first one is mobile computing, which means

‘‘the capacity of moving computing services with us, through

reducing the size of devices, providing network access while

moving, or both’’ [57]. The second aspect refers to the

requirements of movement in a game. This second aspect

may be motivated by design decisions such as promoting

physical health, tourism games (where players would visit

some specific places), and technological constraints (e.g.

limit playing areas to places where location technology

works well). The amount of movement in pervasive games

may vary greatly, ranging from restricted small places (e.g.

Pirates! [7]), dedicated (controlled) parts of a city (e.g. Uncle

Roy all around you [49], PAC-LAN [50]), and unbounded

areas (e.g. Botfighters [9], Insectopia [48], Mogi [47], Gi-

gaputt [58], Gbanga Famiglia [10]). Another important issue

related to Mobility in mixed-reality environments refers to

how the game keeps the consistency between the physical

location of the player and its virtual representation (i.e. how

the rest of the system sees this virtual representation,

including other players). Inconsistency among physical

locations and their virtual representation affects the game

experience negatively, especially in multi-player games.

Local space redefinition (LSR, Table 5) This quality

relates to how the game is able to change the meaning of

the places where the game is played. By ‘‘changing

meaning’’, we denote augmenting value to places, incor-

porating the place (or objects belonging to the place) as

game objects, integrating live (human) non-player charac-

ters, or making the players perceive the place with alter-

native views. This is different from just ‘‘being at a place’’,

or using some property (like location) without referring to

the local context.

3.3.2 Communicability (Com)

Communicability refers to aspects related to how the game

is able to communicate with players and other game

components (as smart objects).

Connectivity (Con, Table 6) Connectivity may exist in

global or local scope. Global scope refers to connecting to

remote peers that are not in the same physical place. Local

scope refers to connecting peers that are co-located. The

connectivity scope directly relates to the space scope of the

game. Global connectivity makes it possible for activities

to happen in very different places, possibly very distant. In

this case, the game space scope can be large. Local con-

nectivity restricts activities to happen in places with more

restricted size. This quality influences all pervasive game

qualities where obtaining remote information may be

required.

3.3.3 Permanence (Perm)

This quality refers to the game as defining a persistent

world. A further degree of permanence would be a game

that possibly evolves by itself over time without player

participation. Other examples of concerns related to this

quality are persistence issues and interleaving game

activities with other non-game activities.

Daily life interleaving (DLI, Table 7) This quality

relates to how the pervasive game is able to become diffuse

through daily life, enabling the player to integrate gaming

sessions with other non-game activities.

Persistency (Per, Table 8) Persistency refers to main-

taining game state to be accessed through different game

sessions over time. This quality is a requirement for games

that aim at simulating a parallel world that evolve by itself.

This includes all games that have social networking or

community aspects. However, not all pervasive games

require persistency.

Table 4 Checklist for MobilityNo. Question

Mob1 Does the game need to use networking while the players are moving?

Mob2 If the game needs networking, how does the game handle networking connectivity issues while

players are on the go?

Mob3 Does the game depend on specific locations to be played? Are players required to move between

specific locations?

Mob4 Does the game require players to walk long distances? What is the order of magnitude of the

potential game area?

Mob5 How does the game keep physical player locations consistent within the game world?


123

3.3.4 Accessibility (Acc)

Accessibility refers to how players are able to access the

game. It relates to the game reach. In this sense, we con-

sider ‘‘accessibility’’ as having a wider scope than the usual

definitions that focus on social issues. We consider acces-

sibility as concerning three groups of issues:

• Social issues (e.g. people with disabilities, gender-

biased content);

• Economic issues (e.g. expensive devices, services and

technology);

• Technological issues (e.g. technical constraints, tech-

nology not widespread).

Access usability (Usa, Table 9) This quality corre-

sponds to traditional usability issues from human–com-

puter interaction focused on mobile devices and

accessibility. An example of an important issue related to

this quality is designing activities that do not require

players to constantly look at the mobile device screen.

This issue especially concerns pervasive games, as play-

ers might be moving during game activities. In this case,

looking at the device screen might risk their safety or may

make them miss part of the game experience. Some

authors refer to this approach as ‘‘design for ‘heads-up’

experience’’ or ‘‘head up game’’ [59, 60]. Other examples

of this concern can be found in [61–63]. Dixon et al. [64]

recommend simple interaction mechanics in game activ-

ities. We interpret this recommendation as a measure to

avoid having the player focus extensively on the game

device interface and thus missing part of the game

experience. Also, this issue can be related to using mul-

tiple modalities for interacting with the player. For

example, games may explore audio and haptic feedback,

as we did in [65, 66]. Another example comes from [67],

which use speech synthesis to keep players informed

about game events, reducing the need to look at the device

screen to continue playing the game.

Research on general usability issues in pervasive games

is still under-explored. The work by Jegers [68] is among

the few ones, where the results indicated that there are

general usability issues that are unique to pervasive games.

A related work is [69], which explored game usability

evaluation in pervasive games. Another example is the

work by Martins and co-authors [70], which explored

usability issues for a wearable interface designed for

‘‘ubiquitous games’’.

Game autonomy (GA, Table 10) This quality refers to

the degree that the game is able to work as an ‘‘independent

system’’. For example, a pervasive mobile game with

Table 5 Checklist for Local

space redefinitionNo. Question

LSR1 Does the game integrate physical places (or their elements) in the gameplay?

LSR2 Does the game give roles to physical places (or their elements) in the gameplay?

LSR3 Does the game help players to have alternative views of the physical environment?

LSR4 What physical resources does the game use as game elements?

LSR5 Does the game use ‘‘live non-player characters’’ (human actors) to reinforce

the mixed-reality overlay?

LSR6 How do game activities affect the physical world?

Table 6 Checklist for

ConnectivityNo. Question

Con1 What are the connectivity requirements for the game? Global? Local? None?

Con2 How does the game handle uncertainties related to connectivity?

Con3 What is the desired space scope for game activities?

Table 7 Checklist for Daily

life interleavingNo. Question

DLI1 Does the game provide a persistent game world?

DLI2 Are game activities designed to be interruptible?

DLI3 Do game activities require long time commitment from players?

DLI4 Which approaches or techniques does the game apply to blend with daily life?

DLI5 Does the game provide equal opportunities for playing in any time?

DLI6 How does the game communicate game-related events to players?

DLI7 Does the game world evolve by itself, while the player is not playing?


123

‘‘high autonomy’’ does not require supervision and prepa-

ration for game sessions. On the other hand, games with

‘‘low autonomy’’ can be considered as ‘‘event games’’

(Sect. 3.1.3).

Transmediality (TM, Table 11) Transmediality mainly

refers to providing different modes of participation (as

different game interfaces) in the game to deliver a broader

transmedia experience (Sect. 3.1.2). In this paper, we are

concerned with issues such as the number of different game

interfaces and the impact of using these different interfaces

in the game—in other words, if the game experience is

balanced among the various interfaces. However, the

qualities related to pervasiveness that we present in this

paper relate to game interfaces based only on context-

aware mobile devices. The pervasive mobile game may

also use smart objects to enrich the game experience.

Device independence (DI, Table 12) This quality relates

to the possibility of using the same (primary) game inter-

face (Sect. 3.1.2) in different mobile platforms.

3.3.5 Sociality (Soc)

Sociality refers to the social aspects and social implications

of the game. For example, it includes aspects such as pri-

vacy, ethical issues, how people relate with each other, and

how activities disturb non-players in public places.

Conformance to physical and social settings (CPS,

Table 13) This quality relates to ethical and privacy con-

cerns, conforming to social conventions, safety concerns

(e.g. protecting players from harm while moving around),

and adequacy to physical settings (e.g. relying on audio

feedback in noisy places).

Social communication (SC, Table 14) This quality

relates to how the game is able to foster or promote social

communication, acting as a medium for people to com-

municate. Social communication in pervasive games may

happen directly (face to face) or indirectly (using tech-

nology as a mediator). Also, the scope of communication

encompasses co-located and distributed people. Social

communication may generate emergent gameplay—com-

plex interaction patterns or behaviours that arise from

people playing the game. A game designer usually cannot

anticipate the effects that might emerge in the gameplay

dynamics, although the designer may foster emergent

gameplay through design decisions. For example, discus-

sion on emergent gameplay issues on general pervasive

games can be found in [71, 72]. A pervasive mobile game

may encourage social interaction by providing different

participation modes that require players to collaborate in

order to complete game activities.

Involving non-players (INP, Table 15) This quality

relates to integrating non-players into the game. Some

games might use this to create ambiguities about who is

playing and who is not, creating what Montola et al. [24]

have defined as ‘‘social expansion’’. This idea is also

related to players having to discover who the other players

are and meet them (physically). By doing so, players might

have to approach strangers on public places and then pro-

ceed to complete game activities. It is important to notice

that involving non-players in the game might raise ethical

issues.

Non-player participation can be passive or active. An

example of passive participation is our prototype Pervasive

Word Search (Sect. 4), which uses other people’s Blue-

tooth devices as a source of content. An example of active


PersistencyNo. Question

Per1 Do game sessions depend on previous sessions or stored data?

Per2 Does the game support internal social networks or communities?

Per3 Does the game world evolve by itself, while the player is not playing?

Table 9 Checklist for Access

usabilityNo. Question

Usa1 Do game activities require players to focus on the device screen all the time?

Usa2 Do game activities use various modalities to interact with the player?

Table 10 Checklist for Game

autonomyNo. Question

GA1 Is the game bound to specific places or local context?

GA2 Does the game require configuring the physical space for a game session?

GA3 Does the game require any kind of supervision (orchestration) when players are playing it?

GA4 Does the game require custom hardware, human actors, or other kind of related resources?


123

participation is Uncle Roy all around you [49], which uses

actors to represent non-player characters.

3.3.6 Context-awareness (CA)

Context-awareness refers to aspects related to how the

game creates and maintains the mixed-reality environ-

ment—the integration between virtual and physical worlds

through exploring context.

Game content adaptability (GCA, Table 16) This quality

relates to context acquisition (through sensors) and

dynamic content generation. Game content adaptability

refers to how a game is able to keep the same (or expected)

gameplay functionality despite favourable or unfavourable

environment conditions. For example, a game that uses Wi-

Fi access point data to generate content should be designed

to work correctly in areas with lots of Wi-Fi access points

(as dense urban areas) as well as in areas with poor Wi-Fi

coverage. Otherwise, the experience that the game aims at

providing may be wanting in some situations.

The accessibility concept referred in question CGA3 is

the same as defined by the ‘‘accessibility’’ non-functional

requirement (Sect. 3.3.4).

Game object tangibility (GOT, Table 17) This quality

relates to how the game uses the mobile device (and other

environment elements) as tangible objects [74]. Ishii and

Ulmer [74] define ‘‘tangible object’’ as a metaphor for

‘‘human–machine interfaces that couples digital informa-

tion to physical objects’’. The users manipulate the physical

object to interact with the application. For example, on a

general context, tangible objects could be pieces of aug-

mented table-top games [28]. Existing research on perva-

sive games suggest that this feature contributes to

increasing player immersion in the game [45, 52, 75].

When considering mobile devices, this quality refers to

aspects such as assigning a purpose for the device (e.g. a

specific role) in the game and having players manipulate

the device according to this purpose to interact with the

game. An example of tangible interaction comes from the

mobile game The Audio Flashlight [65, 66] (although not a


TransmedialityNo. Question

TM1 Does the game offer different participation modes (game roles)?

TM2 If the game offers different modes of participation, are these roles played through

different media (devices)?

TM3 Does the game balance the game experience for the various game roles?

TM4 Does the game need to use other media (e.g. desktop PCs) as support modules?

TM5 Is this game part of a broader transmedia experience?

Table 12 Checklist for Device

independenceNo. Question

DI1 Is it possible to use the game interface across multiple mobile device platforms?


Conformance to physical and

social settings

No. Question

CPS1 How does the game handle player privacy?

CPS2 Do game activities possibly disturb non-players?

CPS3 Do game activities expose players (or non-players) to embarrassing situations?

CPS4 Do game activities conform to local social conventions/etiquette?

CPS5 Are game activities adequate to the physical setting of the game?

Table 14 Checklist for Social

communicationNo. Question

SC1 How does the game use technology as means to improve communication among people?

SC2 How does the game transform the relationships among players?

SC3 Does the game stimulate players to approach/start interactions with other people?

SC4 Does the game use technology to foster communities or social networks?

SC5 Does the game present emergent gameplay?


123

pervasive game) transforms the mobile phone into an

‘‘audio radar’’. The player interacts with the game using

gestures (i.e. tilting the device) according to the volume

and tempo of music. The game uses the device

accelerometer and vibration motors to create this interac-

tion interface. Another example comes from the pervasive

mobile game REXPlorer [76], where the mobile phone is

disguised as a game object through plastic shells to create

the ‘‘The REXplorer ‘detector’’’. The physical object

designed for a specific role in the game is called ‘‘a game

prop’’, which is a term inspired by theatre terminology.

3.3.7 Resilience (Res)

Resilience refers to how the game is able to prevent the

pervasive experience from breaking apart despite the

existence of technological issues that might disrupt the

pervasive experience.

Uncertainty handling policy (UHP, Table 18) This

quality relates to how the game handles noticeable

boundaries, breaks, or gaps among technology compo-

nents, which are known as ‘‘seams’’. This also includes

handling breaks in the smoothness of user experience, due

to inherent technology limitations in precision, accuracy,

availability, and other uncertainties. Some researchers [46,

61] have identified five general strategies to handle these

issues:

• Remove: consists of designing activities so that limi-

tations never appear in the game. This includes using

improved technologies (which is not always possible)

or designing activities that fit the technology limitations

into them;

• Hide: anticipates issues and ‘‘corrects’’ them before the

player has a chance to see them. Contrary to the remove

strategy, in this case the limitations appear in the game,

but are ‘‘corrected’’ before the player notices them;

• Manage: consists of including fallback modes to use

when the primary mode of operation fails. In other

words, the game adapts to the circumstances by having

several modes of operation;

• Reveal: presents the limitations to users and letting

them decide how to act. For example, mobile phones

display the operator signal strength in the user

interface;

• Exploit: means acknowledging the existence of issues

and integrating them into the game as a game design

feature.

The case study in Sect. 4 provides examples on using

the hide strategy.

Game pacing (GP, Table 19) This quality relates to how

technology influences or limits the pacing of the game (or

vice versa). For example, if game activities have high pac-

ing, some sensor technologies might not work well [61, 73].

Some technologies may not provide responses in a real-time

fashion (e.g. Bluetooth device scanning) that might be

required by some games. In those cases, it is necessary to

design game activities that are compatible with the inherent

characteristics of the technology that the game uses. These

issues mainly concern networking and sensor technologies.

3.4 The dependence matrix

During our investigation on pervasive game qualities, we

found several dependencies among them, which clearly

reveal an embedded structure. In this paper, we propose a

matrix, called the dependence matrix, to describe this

structure. Firstly, we present the dependence matrix as a

general instrument (Sect. 3.4.1), although we give exam-

ples with quality requirements for pervasive mobile games.

Afterwards we go into details about the use of this matrix

for the specific case of pervasive mobile games

(Sect. 3.4.2). In this matrix, we kept the terms ‘‘quality’’


Involving non-playersNo. Question

INP1 Does the game involve non-players? How does it do it?

INP2 Does the game have activities where players need to find out who the other players are?

INP3 Does the game generate/use content that is based on other (non-player) people?

INP4 Does the game use human actors for non-player characters?

Table 16 Checklist for Game

content adaptabilityNo. Question

GCA1 How does technology availability affect the game content and the player experience?

GCA2 Does context usage require players to move more in the physical world?

GCA3 Does context usage affect accessibility?

GCA4 Are players able to play the game in various places without manual intervention/re-installation/re-

adaptation/orchestration?


123

and ‘‘quality requirements’’ to facilitate the reading of the

rest of the paper (although general terms would be more

appropriate, such as NFR or softgoals). In this section, we

use the acronyms defined in Fig. 3 (Sect. 3.2) to refer to the

pervasive game qualities.

3.4.1 The general case

We propose that dependencies among non-functional

quality requirements can be understood from the perspec-

tive of two complementary views:

• Operationalization view: this type of dependence arises

when the presence of a quality i is required by the

techniques used to operationalize the quality j. Depend-

ing on to the specific software being developed (e.g. a

specific game), this relationship can be a necessary or

an optional condition for operationalization. For exam-

ple, game content adaptability (GCA) is always

required by Game Autonomy (GA), regardless the

game being developed. On the other hand, depending

on the game being developed, Mobility (Mob) may be

required or not by Local Space Redefinition (LSR);

• Interdependence view: this type of dependence arises

when the presence of a quality helps or hinders another

one, regardless of the software being developed. For

example, game activities with intense game pacing

(GP) may hinder Connectivity (Con) and gathering

sensor information (GCA—game content adaptability)

due to limitations of the involved technologies. An

example of intense game pacing (GP) occurs when

players are moving fast while playing the game (e.g.

playing while sitting on a train or on a car).

In our proposal, the operationalization view has the

following basic relationship:

1. i R j: quality i is required by quality j;

The interdependence view has two types of basic

relationships:

1. i ? j: quality i helps quality j;

2. i - j: quality i hinders quality j.

Also we need some symbols of modality to express

necessity, possibility, and conditionality, which affect a

basic relationship:

• a: ‘‘always holds’’;

• m: ‘‘may hold, in some specific cases’’;

• d: ‘‘will hold if the intensity of the first parameter is

above some threshold’’. This modality applies only to

the help and hinder relationships.

For example, in the domain of pervasive mobile games,

we have: UHP aR GCA (i.e. UHP is always required by

GCA for the operationalization of GCA) and Mob mR LSR

(i.e. Mob may be required, in some cases, by LSR for the

operationalization of LSR), GOT ? LSR (i.e. GOT helps

LSR), Usa - Mob (i.e. Usa hinders Mob), GP m - TM

(i.e. GP may hinder TM in some cases), and GP d - GCA

(i.e. GP will hinder GCA if the intensity of GP is above

some threshold). We present other examples in Sect. 3.4.2.

Table 17 Checklist for Game object tangibility

No. Question

GOT1 Does the game specify a role for mobile devices in the game, or are they mere access terminals?

GOT2 How does the game transform mobile devices into game objects?

GOT3 Does the game use other physical objects (other than mobile devices) equipped with sensors or actuators as game objects?

GOT4 Does the game use mobile devices to create various game props (i.e. various game interfaces)?

GOT5 How does using tangible objects improve the socialization of players in a game?


Uncertainty handling policyNo. Question

UHP1 Which strategy does the game use to handle technology limitations?

UHP2 How does the game handle technology limitations?

UHP3 Does technology correctly acknowledge physical world limits?

Table 19 Checklist for Game pacing

No. Question

GP1 Is the technology the games uses compatible with the game

pacing?

GP2 Do game activities adapt their pacing to accommodate

technology limitations?

GP3 Does the pacing of game activities require the player to focus

exclusively on the game? For how much time?


123

The operationalization and interdependence views in

this section concern implicit relationships—a kind of

relationship that is different than the one that Fig. 3 rep-

resents. Figure 3 represents explicit relationships among

qualities as level refinements—there are first-level NFRs

and second-level NFRs. Figure 3 does not present any

implicit relationship, such as the one that exists between

Game object tangibility (GOT) and Local space redefini-

tion (LSR) (e.g. GOT ? LSR). Figure 4 organizes these

implicit relationships (the operationalization and interde-

pendence views) in a dependence matrix. The dependence

matrix also represents the explicit relationships (the two-

level conceptual map defined in Fig. 3) as horizontal and

vertical headers (e.g. the first-level NFR Spa and its sec-

ond-level NFRs LSR and Mob). The first-level NFR names

are represented in bold italic font and the second-level

NFR names are represented in bold font. We analysed

several games (Table 3) and use our design experience to

define the matrix of Fig. 4. It is important to understand

that Fig. 4 represents the best of our current knowledge,

which is evolving considering the volume of information

we are dealing with.

In Fig. 4, we represent any dependence with a shaded

cell containing the type of relationship. The reader may

read the matrix in row-wise or column-wise direction.

Considering a matrix cell (i,j), where i is a row and j is a

column, reading in row-wise direction reveals straight in-

fluences, such as ‘‘i helps j’’, ‘‘i is required by j’’, and

‘‘i hinders j’’, while reading in column-wise direction

reveals dependencies, such as ‘‘j is helped by i’’, ‘‘j re-

quires i’’, and ‘‘j is hindered by i’’.

Our experience in building the dependence matrix

reveals that we should start filling the matrix by trying first

to find what each quality requires (i.e. column-wise

direction). The other two basic relationships (? and -) are

more naturally defined in row-wise direction. For the sake

of readability, we do not represent self-relationships (e.g.

LSR 9 LSR, Mob 9 Mob, GOT 9 GOT).

The proposed matrix allows a quick verification of

special interdependence relationships, such as the presence

of conflicting qualities revealed by symmetrical cells

containing the symbol -. This is the case of Access

usability (Usa) and Mobility (Mob) in Fig. 4, i.e. the matrix

reveals a challenge to be solved by designers (something

found in many other domains, where conflicting qualities

should be harmonized; such as the case of satisfying both

security and accessibility in a network system).

A visual inspection of the dependence matrix (Fig. 4)

reveals that some qualities are more influential or depen-

dent than others. For instance, UHP has a great influence

on others qualities, because the UHP row has a large

number of non-empty cells. Mob depends on several other

qualities, since the column Mob has a great number of non-

empty cells. We may be tempted to sum the number of

non-empty cells to set a measure of influence or depen-

dency, but this would not capture interrelationships. We

propose to calculate a relationship strength value s for each

cell of the matrix based on the combination of basic

strength values associated with the basic relationship types

(R, 1, -) and their modalities (a, m, d). For example, a

cell with aR would have a strength value greater than a cell

with mR, since ‘‘always required’’ is stronger than ‘‘may be

required in some cases’’. A cell with just R (i.e. not

knowing if always required or not) would be between those

two cases (aR and mR). In this approach, the sum of the

cell values s in a row/column would be a better measure of

influence/dependence. Furthermore, we could sort the

quality requirements according to their strengths. In fact,

any formula that permits a relative numerical comparison

between quality requirements is valid for the above-men-

tioned calculations, provided that it could incorporate the

essence of the interrelationships. In this paper, we propose

the following empirical expression (based on the experi-

ence of the present authors as software engineers) to cal-

culate the relationship strength value s, in which we give

more importance to the R relationship and consider the

negative effect of the hinder relationship as a subtractive

term:

s ¼ f ðsRÞ þ f ðsþÞ � f ðs�Þ ð1Þ

where sR, s?, and s- are the basic strength values of the

relationships R, ?, and -, respectively. In this model, we

consider sR, s?, s- [ [0, 1.0], and sR,[ s?, sR[ s- to

increase the importance of the relationship R. We proposed

the modality function f, which intensifies or reduces the

basic strength values (i.e. sR, s?, s-) according to the

modality symbol (i.e. m, d, a, or none) present in the

relationship, as follows:

f ðxÞ ¼0:5x if m; d

ffiffiffi

xp

if a

x otherwise

8

<

:

ð2Þ

Considering that in Eq. 2, x [ [0, 1.0] (i.e. x can be sR,

s? or s-), we used the square root to increase the impor-

tance of the a modality (‘‘always required’’) over other

possibilities. As a hypothetical example, we may instanti-

ate this model using the arbitrary basic values sR = 0.6,

s? = 0.2, and s- = 0.2. If a cell (i,j) contains ‘‘mR’’ (i.e.

i may be required by j), the relationship strength value

s will be 0.3 (this is the case of this is the case of ‘‘Mob

mR LSR’’ represented in Fig. 4). As another example, if a

cell (i,j) contains ‘‘aR’’ (i.e. i is always required by j), the

relationship strength value s will be 0.775 (e.g. ‘‘UHP

aR LSR’’ represented in Fig. 4).


123

In pervasive mobile games, the cells in the dependence

matrix have only one relationship (such as aR, mR, and

m-). However, on a general case a single dependence

matrix cell (i,j) might contain multiple relationships, such

as ‘‘aR, -’’. (i.e. i is always required by j, but i also

hinders j). As a final remark, we do not recommend using

cells with multiple ? or - (e.g. ?? or ???) because this

type of difference is difficult to be noticed at a higher level

of abstraction. We think this would be more appropriate

when the designer is using specific techniques to opera-

tionalize specific qualities. The reader should refer to [77]

for a discussion of such issues.

The sum of the relationship strengths of a row represents

the degree of influence of the corresponding quality

requirement. The sum of the strengths of a column repre-

sents the degree of dependence of a particular quality

requirement. The matrix is a primary source for several

other analysis and views. The degrees of influence/depen-

dence can be sorted in a descending/ascending order and

help us to identify the most important or critical require-

ments. These identifications provide some rationale for the

software development decisions. This is something similar

to the ‘‘claim softgoals’’ proposed by Chung and co-authors

[78], although here we are at a much higher abstraction

level.

3.4.2 Dependence matrix using pervasive mobile game

examples

The dependence matrix can generate dependence diagrams,

where the more influential qualities (based on their degrees

of influence) are drawn at the higher levels of the graph and

those qualities with the highest degrees of influence are

marked by shaded rectangles. We use the methodology of

Sect. 3.4.1 to analyse the dependencies among the quality

requirements for pervasive mobile games.

For example, we are able to find the most influential

qualities and most dependent qualities by applying Eq. 1

with custom values for sR, s?, and s- to calculate degrees

of influences and degrees of dependence. For example, we

can arbitrarily use sR = 0.6, s? = 0.2, and s- = 0.2 to

boost the R relationship, because we consider this rela-

tionship stronger than the other basic relationships. Fig-

ure 5 illustrates a partial example of influence and

dependence order (the first three elements only) calculated

by applying Eq. 1 with the above-mentioned values for sR,

Fig. 4 The dependence matrix for pervasive mobile game qualities


123

s?, and s-. Figure 5 reveals that among second-level

NFRs, UHP is the most influential quality and LSR is the

most dependent one. This analysis reveals the importance

of UHP, Con, and GCA as second-level NFRs. These

calculations can be carried out by hand or with the help of a

computer program (which is currently under development

by the present authors). For example, we can calculate the

degree of influence of UHP by looking up the row that

contains UHP (in Fig. 4) and applying Eq. 1 in each shaded

cell in that row. Using the above-mentioned values for sR,

s? and s-, this calculation yields: degree of influence =

(0.7746 ? 0.3 ? 0.7446 ? 0.7446 - 0.1 ? 0.7746 ?

0.7746 ? 0.7746) = 4.8476. Similarly, we can calculate

the degree of dependence of LSR by looking up the column

that contains LSR and applying Eq. 1 in each shaded cell in

that column. This calculation yields: degree of depen-

dence = 0.3 ? 0.2 ? 0.3 ? 0.7446 ? 0.2 ? 0.3 ? 0.3 =

2.3746.

Using the dependence matrix in Fig. 4 as reference, we

can draw dependence diagrams. For example, Fig. 6

illustrates a dependence diagram considering only aR re-

lationships (‘‘always required’’) and second-level NFRs.

We chose the UHP quality as the root of the example

diagram because UHP is the most influential quality among

second-level NFRs. To create this diagram, we firstly look

up the row that contains UHP in Fig. 4. Next, we browse

the UHP row searching for aR relationships, which reveals

these qualities: LSR, GOT, GCA, GA, Per, and Con. For

each of these qualities, we repeat this process until there

are no more aR relationships to consider.

As another possible view, we can partition the interde-

pendence matrix into submatrices by rearranging rows and

columns in such a way that regions with great incidences of

strong relationships are grouped. In this later case, the

rearranged matrix may reveal more independent sets of

quality requirements. Also this reordered matrix may

reveal good approaches to the design of the system archi-

tecture. The dependence matrix is a type of Design

Structure Matrix—DSM [79, 80] and, consequently, enjoys

the benefits, algorithms, and tools related to DSMs.

Our research on the dependence matrix is not com-

pleted, but we are confident enough to claim that it can be a

promising technique for non-functional requirements elic-

itation in several other domains. As an example of how we

defined the matrix of Fig. 4, the reader can check the LSR

quality in some games as follows:

1. Mob may be required by LSR for operationalization

(Mob mR LSR): In Feeding Yoshi [61], the players

need to feed a special character by searching for food

in ‘‘plantations’’. The plantations correspond to secure

Wi-Fi access points that are spread on the physical

environment, which requires players to wander around

to find these ‘‘food sources’’;

2. GOT helps LSR (GOT ? LSR): The Gigaputt game

[58] redefines physical places as mini-golf courses. To

help in improving LSR, in these game players manip-

ulate the mobile devices as if they were golf clubs,

using a tangible object metaphor.

3. UHP is always required by LSR for operationalization

(UHP aR LSR): The game needs to use UHP to handle

uncertainty issues related to location data—the game

obtains these data through location systems such as

GPS;

4. INP helps LSR (INP ? LSR): Our prototype Pervasive

Word Search (Sect. 4) uses Bluetooth devices of non-

players to create special game zones that have specific

purposes in the game;

5. Per and Con may be required by LSR for operational-

ization (Per mR LSR, Con mR LSR): this is the case

when the game needs to associate some specific data to

some physical place. For example, our prototype

Location-based quiz [81, appx. C] defines some

questions that the players need to answer when they

arrive at a physical room. Each room has a different set

of questions.

As far as the conditional modality, d, is concerned, we

can produce the following example:

• GP hinders Con if the intensity of GP is above some

threshold (GP d2 Con): If the pacing of activities in the

game is high, connectivity may not work well. For

example, this is an issue that Bell and co-authors [61]

reported for Feeding Yoshi. In that game, when players

were moving fast (on cars, trains), they had trouble

Fig. 5 Partial example of influence/dependence order

Fig. 6 Dependence diagram (aR only) created by visually inspecting

the dependence matrix in Fig. 4, starting with the UHP quality


123

connecting to access points. This caused players on cars

to slow down to be able to catch the virtual content.

4 Case example

This case example demonstrates how the pervasiveness

quality applies to a single-player pervasive mobile game

developed by the authors, Pervasive Word Search. In this

example, we outline which checklist questions are relevant

to the non-functional requirements under discussion. This

section presents the most important non-functional

requirements used to develop this pervasive mobile game.

We had these goals when developing this game (1) a game

that can be played in current smartphones; (2) a context-

aware game that retrieves as much content from the envi-

ronment as possible using current smartphones; (3) a game

that requires no special set-up (regarding infrastructure).

The objective of Pervasive Word Search is to find the

letters from a word that the game draws. The player must

explore the environment surrounding him to find the letters.

While exploring the physical world, the player may interact

with some game zones—the dark, open, and wireless

zones. The ‘‘dark zone’’ is a place with ‘‘low’’ ambient

light. An ‘‘open zone’’ corresponds to an outdoor area. A

wireless zone corresponds to a physical area with a certain

number of Wi-Fi access points and Bluetooth devices.

Interacting with these zones is an important part in this

game.

The player is able to get letters by capturing colours

with the device camera and interacting with the wireless

and dark zones. For example, 1 illustrates a player in

Pervasive Word Search focusing the device camera on a

red flower to capture the letters ‘‘r’’, ‘‘e’’, and ‘‘d’’—thus

getting the letters ‘‘r’’, ‘‘e’’, and ‘‘d’’, and eliminating ‘‘r’’,

‘‘e’’, and ‘‘d’’ from the target word. The game identifies a

finite set of colours: red, yellow, orange, green, purple,

blue, pink, black, white, and grey. The player goes to

wireless zones to get letters that do not exist in the basic

colour names (like ‘‘f’’, considering names in English). The

player has a finite time period to find all letters. Interacting

with the game zones changes the game clock behaviour.

For example, if a wireless zone has lots of devices, the

game clock runs slower. If the player is inside an open

zone, the game clock runs faster. For more specific details

on this game, the reader should refer to [81].

4.1 Analysing pervasiveness

In Pervasive Word Search, the first-level non-functional

requirements that most contribute to pervasiveness are

Spatiality, Resilience, and Context-awareness. This section

uses the checklists (Sect. 3.3) to evaluate the pervasive

game qualities (and thus, pervasiveness) in Pervasive Word

Search. In other words, we describe how the game applies

these requirements and how the other requirements do not

apply to the game. In this section, we refer to checklist

questions by their acronyms.

4.1.1 Spatiality

The game implements the Spatiality quality through Local

space redefinition and Mobility. The game uses Local

space redefinition to define three game zones: the open

zone, the wireless zone, and the dark zone. In this regard,

players are able to perceive physical places as ‘‘game

zones’’ (LSR1, LSR2, LSR3) when they go to physical

places that match the requirements of a specific game zone.

The game does not use live non-player characters (LSR5),

and the game activities do not affect the physical world

(LSR6).

The game applies Mobility, as it requires players to

wander around the physical world to find sources for letters

(Mob4). The game area is unconstrained. This game does

not use networking, so Mob1 and Mob2 do not apply. This

game does not depend on specific locations to be played

(e.g. a specific room, city square, or building), so Mob3

does not apply. The ‘‘game zones’’ are not actual physical

places—they are virtual elements applied to a physical

environment, being created dynamically through context

information. In other words, these ‘‘game zones’’ may

disappear or move over time depending on the current

context. Pervasive Word Search does not use location

information, so Mob5 does not apply.

4.1.2 Resilience

The game implements Resilience by defining Uncertainty

handling policies and adjusting the Game pacing to be

compatible with these policies. The relevant questions for

Uncertainty handling policy are UHP1 and UHP2. The

game applies the general strategy hide to handle several

uncertainties. For example:

• The colours are represented with a limited set of

options. Similar ‘‘colours’’ are grouped with the same

name (e.g. all variations of ‘‘red’’ are considered as

‘‘red’’);

• Bluetooth and Wi-Fi queries are slow operations. It is

also possible that some queries miss some devices or

return false positives. Thus, the game does not require

real-time response to use these data. The interaction

with those sensors is indirect—the game queries the

sensors in the background and announces the results

when they are ready. In other words, the game does not


123

use Bluetooth and Wi-Fi information in real-time

fashion.

• Game zone representation is ambiguous—the game

does not display zone maps nor tracks physical world

limits (UHP3). Instead, the game just informs the

player if he/she has entered or left a game zone (e.g. the

wireless, dark, and open zones).

Regarding the Game pacing, the activities were

designed to not require fast responses from players. Also,

the players are not required to move fast while playing

(GP1). Additionally, the game pacing was adjusted to be

compatible with the nature of some operations that the

game performs (GP2). For example, some activities rely on

Bluetooth and Wi-Fi network queries, which are very slow

operations. The pace of game activities enables players to

focus the physical environment most of the time (GP3).

4.1.3 Context-awareness

Pervasive Word Search explores Context-awareness

mainly through Game content adaptability. The game

generates all content through sensing the environment,

except for the target word that comes from an internal

database (GCA4). In this regard, players may have trouble

playing in areas with no Wi-Fi access points or Bluetooth

devices around (GCA1, GCA3). In this case, players would

have to search for places where these devices could be

found. We do not regard this issue as a problem—instead,

it is part of the requirement to have players explore the

physical world (GCA2).

Pervasive Word Search does not use tangible object

metaphors, so Game object tangibility does not apply to

this game. In other words, the mobile phone works as mere

terminal to play the game, with no specific role in the game

design.

4.1.4 Permanence

The Permanence quality in Pervasive Word Search is

limited. For example, the game barely supports Persis-

tency. Game sessions do not depend on previous session

data. However, the game draws the target word from an

internal database to start a new game session (Per1). The

other persistency questions (Per2 and Per3) do not apply to

the game.

Considering Daily life interleaving, the game does not

require long-time commitment from players (DLI3), as

Pervasive Word Search implements the concept of ‘‘short

play sessions’’ [48] that do not depend on previous ses-

sions. In this regard, the game can be easily interrupted

without further loss to the players (DLI2) and can be

restarted anytime (DLI5). Pervasive Word Search does not

provide a persistent world, so DLI1, DLI4, DLI6, and DLI7

do not apply.

4.1.5 Sociality

Considering Social communication and Pervasive Word

Search as being a single-player game, questions SC1, SC2,

and SC4 do not apply. The game activities do not require

players to approach strangers (SC3). However, the game

encourages players to go to areas with lots of people, as the

game could become easier if there are many Bluetooth

devices in these places (the game clock runs slower in this

situation). Finally, the game is not designed to foster

emergent gameplay (SC5).

Regarding Conformance to physical and social settings,

relevant questions are CPS2, CPS3, CPS4, and CPS5. As

the game requires players to point the device camera to

capture colours, this behaviour might create issues related

to these questions. For example, a player might get repri-

manded while trying to capture a colour while playing in

some places. Also, a player might embarrass people while

trying to capture a colour. In our preliminary tests with this

game, we had no issues regarding these questions, although

evaluating this quality thoroughly would require a more

specific study. Pervasive Word Search does not require

user data (CPS1).

Considering Involving non-players, Pervasive Word

Search generates content using Bluetooth devices (i.e. their

name identifiers) that other people carry (INP3). We can

say that the game involves these non-players indirectly

(INP1). However, the game does not contact these devices

nor the player is required to approach these people (INP1,

CPS2, SC3). Non-players are unable to take part in the

game directly (INP1). The INP2 question does not apply to

this game as it is a single-player game, and neither does

Pervasive Word Search use human actors as non-player

characters (INP4).

4.1.6 Communicability

Pervasive Word Search does not support Communicability,

as it is a single-player game that does not use Connectivity.

Although the game queries Bluetooth devices and Wi-Fi

networks, it does not establish remote connections—the

game uses these devices only as content sources.

4.1.7 Accessibility

Pervasive Word Search is not a transmedia game (TM5)—

the game has only one game interface (TM1). In this

regard, questions TM2, TM3, and TM4 do not apply. This

game was developed originally for Symbian/Qt devices.


123

This means that Device independence is limited to Nokia

smartphones (DI1).

Considering Access usability, the game does not require

players to focus on the device screen most of the time

(Usa1). Instead, the game encourages players to focus on

the physical world, searching for colours. Concerning

Usa2, the game provides two modes of interaction: touch

input (to capture colours) and context input (information

coming from ‘‘the game zones’’).

Considering Game autonomy, Pervasive Word Search

was designed to generate all game content (excluding the

target word) from any physical environment that has

coloured objects, Wi-Fi network access points, and Blue-

tooth devices (GA2). Also, the game may generate extra

(redundant) content when the player enters a ‘‘dark zone’’

(a place with ‘‘low’’ ambient light) or an ‘‘open zone’’ (an

outdoor area). In other words, the game is not bound to a

specific physical place (GA1). The game requires no

orchestration (GA3) and no custom hardware (GA4).

5 Related work

Considering quality attributes before defining the software

architecture has been the main reason for the literature on

non-functional requirements. In this regard, the central

issue is to define in advance (along with the stakeholders)

the desired quality attributes that a given software product

should address. Freeman [21] defined a set of basic quali-

ties (functionality, reliability, ease of use, economy, and

safety) and extra qualities (flexibility, reparability, adapt-

ability, understandability, documentation, and enhance-

ability) that apply to general software systems. However, a

software product may require specific qualities that are not

included in these previous sets of qualities. Also, not all

stakeholders involved in the software definition may be

aware of which qualities to consider. In such cases, the

literature has been producing lists or taxonomies of quali-

ties attributes for software. Some examples are [78, 82, 83].

In this context, the NFR (non-functional requirements)

framework [78] has been a central reference in require-

ments engineering research. This framework has been

proposed by the Toronto group [78]. We present below an

overview of this framework because it is essential to

understand the present paper.

The overall idea in the NFR framework is to treat NFRs

as first class citizens. The framework proposes a language

designed to represent NFRs and their relationships with

other NFRs and with possible functions that will carry on

the NFR implementation. In that perspective, the main task

of requirements engineers is to elicit which NFRs will be

considered, their relationships and their operationalizations

(i.e. how they will be handled in terms of software

functions). A key point in the NFR framework is treating

NFRs as softgoals. The term ‘‘softgoal’’ is in opposition to

‘‘hard goal’’. Softgoals relate to the idea that the notion of

‘‘success’’ may vary among stakeholders, as they may

perceive and evaluate qualities in different ways due to

diverse world-views and backgrounds. This reasoning is

similar to Simon’s idea of ‘‘bounded rationality’’ [84],

which says that rationality is limited by three factors: the

information available at the time of a decision, the cogni-

tive limitations of the person, and the time available to

make a decision. This idea implies that objective, clear-cut

reasoning might be hard to achieve in practice due to the

three factors mentioned previously. In this context, the

NFR framework uses the word ‘‘satisfice’’ when relating to

softgoals, which means that a softgoal is not satisfied, but

‘‘satisficed’’ (i.e. partially satisfied based on qualitative

judgements such as ‘‘is it good enough?’’). The term

‘‘satisfice’’ denotes that the conditions in which a decision

will be made depend on the current context and involved

viewpoints (without precise determination or clear-cut

criteria), which leads to assessing qualities using qualita-

tive judgements. In this sense, the NFR framework deals

with qualities using a qualitative approach, not relying on

hard metrics to evaluate these qualities.

The NFR framework defines a graphical language that

supports modelling and verification. The model produced is

called SIG (Softgoal Interdependence Graph), and the

verification is conducted by qualitative reasoning based on

label propagation [85]. The NFR framework language

defines four major symbols: one to represent a softgoal (a

cloud), one to represent the softgoal operationalization (a

bold cloud), one to represent contribution, and one to

represent correlation. A softgoal has to be named by two

descriptors: a type descriptor and a topic descriptor. The

relationships (lines) are labelled according to label cata-

logues, together with rules used for verification (propaga-

tion). Contributions are relationships on a branch of the

graph, whereas correlations are relations from different

branches. An important side effect of the NFR framework

is that the rationale of decisions is explicit.

Below we provide a simple example of how the NFR

framework deals with quality concerns, using the Pervasive

Word Search game (Sect. 4) and some pervasive qualities

presented in Sect. 3.3. This example refers to an important

feature in Pervasive Word Search—getting letters from the

physical environment. Figure 7 illustrates a possible (par-

tial) quality model concerning the ‘‘get letters’’ feature as a

SIG. The SIG in Fig. 7 defines the overall softgoal Quality

(type) for the PervasiveWordSearch (topic), which is

related to Mobility, Conformance to physical and social

settings, and Game content adaptability using the AND

label. The SIG also relates Mobility to both Local space

redefinition and Game pacing using HELP labels. The SIG


123

represents possible implementations of ‘‘get letters’’ as two

operationalizing softgoals: ‘‘GetLetters by Wi-Fi’’ (getting

letters using Wi-Fi access point names as the source of

information) and ‘‘GetLetters by camera’’ (getting letters

using the smartphone camera to capture coloured objects,

using the captured colour name as the source of

information).

Operationalization through Wi-Fi access point names

contributes in a strong manner to Local space redefinition

(represented with a HELP label), as this operationaliza-

tion helps to create the ‘‘wireless zone’’ in this game, but

it contributes negatively to Game pacing because pacing

needs to be low as Wi-Fi access point scanning is a slow

operation. We may notice that the operationalization

through Wi-Fi access point names correlates to Confor-

mance to physical and social settings with a HELP label

because this operationalization helps to avoid issues

related to checklist questions CPS2, CPS3, CPS4, and

CPS5 (Sect. 3.3.5). This operationalization may con-

tribute negatively to Game content adaptability (repre-

sented with a HURT label) as it will not work in places

that have no Wi-Fi access points around. In these situa-

tions, the player will have to move to another place to find

Wi-Fi access points.

Operationalization though the camera may hinder Game

pacing (a relation represented with a HURT label) because

pacing needs to be low so that the player is able to properly

focus an object to get its colour. This operationalization

may hinder Conformance to physical and social settings

(represented with a HURT label) as the player might get

into situations related to issues mentioned in checklist

questions CPS2, CPS3, CPS4, and CPS5 (Sects. 3.3.5 and

4.1.5). Finally, this operationalization contributes posi-

tively to Game content adaptability (represented with a

HELP label), because coloured objects are widespread and

ubiquitous—the player will have plenty of information

sources to draw letters from the environment.

Using Fig. 7 as a model, it is possible to apply rules for

verification. For instance, if ‘‘get letters’’ is implemented

through access point names, then label propagation will

register Local space redefinition as HELP (?), Game

pacing as HURT (-), Conformance to physical and social

Fig. 7 Softgoal Interdependence Graph example


123

settings (?) as HELP, and Game content adaptability as

HURT (-), resulting in neutral (0) for the overall quality.

On the other hand, if ‘‘get letters’’ is implemented through

the camera, Game pacing registers as HURT (-), Con-

formance to physical and social settings (-) as HURT, and

Game content adaptability as HELP (-), resulting in an

overall negative (-) quality. When verifying the model

using a reasoning (propagation) strategy, the consequences

of a given design choice become more clear. The depen-

dence matrix in Sect. 3.4 is a similar way of dealing with

the interaction of qualities.

In this paper, Fig. 3 illustrates (on the first level) seven

non-functional requirements (qualities) that contribute to

pervasiveness. On the second level, there are sixteen non-

functional requirements that contribute to the first-level

qualities. Using the language of the NFR framework [78],

the first-level non-functional requirements and the perva-

sive game qualities can be considered as NFR softgoals.

Figure 3 corresponds conceptually to a NFR SIG (softgoal

interdependency graph), and all relationships in Fig. 3 are

equivalent to ‘‘HELP’’ contributions in the NFR

framework.

The relationships in Fig. 3 mean that the non-functional

requirement contributes positively to the parent quality. For

example, Uncertainty handling policy and Game pacing

contribute positively to the Resilience quality, which in

turn contributes positively to Pervasiveness, along with

Spatiality, Sociality, Permanence, Accessibility, Context-

awareness, and Communicability. However, not all quali-

ties must be present in all levels to characterize perva-

siveness. We understand that pervasive mobile games may

have different levels of pervasiveness depending on how

these non-functional requirements (qualities) are applied.

For each pervasive game quality in Fig. 3, we have

created a checklist. The checklists are a set of questions

that designers can use to evaluate pervasive game qualities

(and thus, pervasiveness) in existing projects. Another

application of these checklists is to help designers in

introducing pervasive game qualities in new projects, by

answering the questions. This idea of having questions to

help in verifying and operationalizing requirements is

similar to the idea that the GQO (goal-question-opera-

tionalization) [86] proposes.

The dependence matrix in Fig. 4a presents the possible

impact of a quality onto other ones. We defined some

symbols (such as aR, mR, ?) to represent the relationships

(and impacts) that we had identified so far. This idea shares

similarities with the ‘‘label’’ concept that the NFR frame-

work defines for its ‘‘evaluation procedure’’ [78]. We can

also find other similarities with the work by Chung and co-

authors [78], but in our case we are dealing with NFR at a

higher level of abstraction (with no reference to specific

methods for operationalization). The dependence matrix

can be compared to the Design Structure Matrices (DSMs)

[79, 80], which are used to help in analysing dependencies

between design elements in products. More examples of

works related to DSMs are [87–90].

The qualities that we discovered for pervasiveness can

be used to design pervasive mobile games considering non-

functional requirements from the very beginning of the

project development. As Chung and Leite [91] note, non-

functional requirements place restrictions on how the

desired functionality can be implemented, not being

something that could be considered at a later stage of

project development. Hence, integrating non-functional

requirements and the desired functionality is crucial. For

example, Uncertainty handling policy (Sect. 3.3.7) deter-

mines policies to handle technology uncertainties (espe-

cially related to sensors and networking), which might

involve requirements for accuracy, response time, and

other quality factors.

This domain knowledge (the non-functional require-

ments related to pervasiveness and checklists) might be

used to inspire game ideas that may lead to functional

requirements. For example, a game might apply Local

space redefinition (Sect. 3.3.1) to create special ‘‘game

zones’’ in the physical space. For example, our prototype

Pervasive Word Search creates three types of game zones

(wireless, open, dark) in the physical environment. In

Sect. 4, we use Pervasive Word Search to describe how the

non-functional requirements related to pervasiveness are

applied in this game.

The process that we conducted to build knowledge about

pervasive mobile games shares similarities with the process

that Leite and Cappelli [92] conducted to build their

Transparency SIG. In their process, Leite and Cappelli [92]

had the assistance of domain experts to gather knowledge

about the domain and to validate the requirements. The

process that we conducted also had input from domain

experts, and we evaluated the requirements that we dis-

covered using game prototypes that we developed. For

example, Sect. 4 has described an evaluation we had con-

ducted with one of our prototypes.

6 Conclusions

Digital games are creative projects that require the input of

professionals with very diverse backgrounds, including

game designers, artists, and software developers. The game

development process has a preproduction phase where

game designers work on the central vision of the game. In

the preproduction phase, the game designers and artists

create game elements, such as the storyline, game design,

and art assets. Later, the results of this phase are carried on

to the production phase where software developers


123

translate the game vision and integrate multimedia assets

into the software to realize the digital game.

Managing the expectations of these different stake-

holders is a difficult task in game development. Many

projects fail due to problems related to the transition

between the preproduction and production phases.

Improving game development processes requires improv-

ing existing requirements engineering processes to consider

the particularities of game projects. Some of these partic-

ularities follows:

• As game projects are a creative endeavour, the process

must take the preproduction phase into consideration.

Non-game projects do not have a preproduction phase;

• A software requirement may originate in the prepro-

duction phase. For example, a game designer may

propose a functional requirement that turns out to be a

non-functional requirement in software implementa-

tion. In this regard, there are other stakeholders (other

than software developers) that may propose require-

ments; and

• Games are projects that focus on entertainment rather

than productivity. As a result, games have requirements

that are not present in non-game applications, such as

‘‘fun’’, ‘‘gameplay’’, ‘‘enjoyment’’, and ‘‘flow’’.

The advent of pervasive games complicates this scenario

by presenting various issues:

• Research on pervasive games has attracted people with

different backgrounds, such as those that have experi-

ence in computer science, game studies, design, and

theatre, which produces a rich discussion about this

topic but also creates a confusing situation. The end

result is that the discussion on pervasive games is too

broad, especially regarding support for pervasive game

development.

• The literature on pervasive games is confusing and often

mixes up preproduction issues and production ones.

Some of the literature (e.g. game studies and game

design) discusses pervasive games using only prepro-

duction concepts, while other parts of the literature

emphasize technological aspects (e.g. pervasive com-

puting technology). Table 1 summarizes these views.

• A pervasive game integrates the virtual and physical

worlds into a mixed-reality. As a consequence, a game

designer may propose a requirement that can be

operationalized outside of the software realm. For

example, the pervasive game Uncle Roy all around

you [49] uses human actors to play non-player

characters that interact with the player. This is an

example of operationalizing Involving non-players

(Sect. 3.3.5) through means other than software,

which reflects the interdisciplinary nature of pervasive

mobile games.

Considering this confusing scenario, in this paper we

described a process for building knowledge on pervasive

mobile games—a subset of pervasive games that uses con-

text-aware mobile devices to enable the interaction between

the environment (physical world) and the virtual world.

The mapping process that we conducted revolves around

trying to understand what makes a game pervasive—a

question that relates to ‘‘pervasiveness’’, which is a quality

that makes those games unique and it is very hard to

objectively define. Our map regarding pervasiveness in

pervasive mobile games is composed of a conceptual map,

a set of checklists, and a dependence matrix.

The conceptual map describes pervasiveness according

to a set of first-level requirements that we have identified:

spatiality, permanence, accessibility, sociality, context-

awareness, resilience, and communicability. Each first-

level requirement has associated second-level requirements

that contribute to it. For each second-level requirement, we

defined checklists to help to verify and operationalizing

them. Finally, we present the first version of a dependence

matrix that records various relationships among these

requirements and that helps with design decisions.

We see these results, in their current form, as a prag-

matic roadmap to navigate the sea of pervasive mobile

games. These results can help game developers by pro-

viding: (1) a resource to spark novel game ideas; (2) a

language to discuss pervasive mobile games and their

characteristics; (3) a starting point to discover functional

and non-functional requirements for pervasive mobile

games; and (4) a starting point to find other relevant fea-

tures in pervasive mobile games.

We believe that there is a rich research agenda ahead for

pervasive mobile games. In future works, we aim to

explore the following topics:

• Refining and validating the qualities that we identified

using more games and designers;

• Refining the dependence relationships among the

identified qualities;

• Identifying more qualities related to pervasiveness;

• Exploring alternatives to operationalize the qualities

that we reported in this paper. We can begin this

exploration by answering the ‘‘how’’ questions in the

checklists.

Acknowledgments The authors thank CNPq, FAPERJ, FINEP, and

CAPES for the financial support to this paper.

References

1. Gartner (2013) Gartner says worldwide video game market to

total $93 Billion in 2013. http://www.gartner.com/newsroom/id/

2614915


123

http://www.gartner.com/newsroom/id/2614915

http://www.gartner.com/newsroom/id/2614915

2. Callele D, Neufeld E, Schneider K (2011) A report on select

research opportunities in requirements engineering for videogame

development. In: 2011 Fourth international workshop on multi-

media and enjoyable requirements engineering—beyond mere

descriptions and with more fun and games (MERE), pp 26–33

3. Callele D, Neufeld E, Schneider K (2005) Requirements engi-

neering and the creative process in the video game industry. In:

Proceedings on 13th IEEE international conference on require-

ments engineering, 2005, pp 240–250

4. Alves C, Ramalho G, Damasceno A (2007) Challenges in

requirements engineering for mobile games development: the

meantime case study. In: 15th IEEE international requirements

engineering conference, 2007. RE’07. pp 275–280

5. Furtado AWB, Santos ALM, Ramalho GL (2010) Streamlining

domain analysis for digital games product lines. In: Bosch J, Lee

J (eds) Software product lines: going beyond. Springer, Berlin,

pp 316–330

6. Norneby J, Olsson T A new attitude to game engineering:

embrace change, re-use, fun. http://www.gamasutra.com/view/

feature/132491/a_new_attitude_to_game_.php

7. Bjork S, Falk J, Hansson R, Ljungstrand P (2001) Pirates! Using

the physical world as a game board. In: Proceedings of interact

2001, IOS Press, pp 9–13

8. Schneider J, Kortuem G (2001) How to host a pervasive game—

supporting face-to-face interactions in live-action roleplaying. In:

Interactions in live-action roleplaying. UbiComp workshop on

Designing Ubiquitous Computing Games

9. Sotamaa O (2002) All the world’s a Botfighter stage: notes on

location-based multi-user gaming. In: Frans M (ed) Computer

games and digital cultures conference proceedings, Tampere

University Press, Tampere, p 10

10. Gbanga: Gbanga Famiglia, http://gbanga.com/portfolio/gbanga-

famiglia/

11. YD Online: GEO Hunters for iPhone, iPod touch, and iPad on the

iTunes App Store. http://itunes.apple.com/us/app/geo-hunters/

id417926906?mt=8&ign-mpt=uo%3D6

12. Petrillo F, Pimenta M, Trindade F, Dietrich C (2009) What went

wrong? A survey of problems in game development. ACM

Comput Entertain 7:13:1–13:22

13. Kanode CM, Haddad HM (2009) Software engineering chal-

lenges in game development. In: Sixth international conference

on information technology: new generations, 2009. ITNG’09,

pp 260–265

14. Bentley T, Johnston L, von Baggo K (2002) Putting some emo-

tion into requirements engineering. In: Proceedings of the 7th

Australian workshop on requirements engineering

15. Callele D, Neufeld E, Schneider K (2010) An introduction to

experience requirements. In: 18th IEEE international require-

ments engineering conference (RE), 2010, pp 395–396

16. Potts C (1995) Invented requirements and imagined customers:

requirements engineering for off-the-shelf software. In: Pro-

ceedings of the second IEEE international symposium on

requirements engineering, pp 128–130

17. Poels K, de Kort Y, Ijsselsteijn W (2007) ‘‘It is always a lot of

fun!’’: exploring dimensions of digital game experience using

focus group methodology. In: Proceedings of the 2007 conference

on future play. ACM, New York, NY, pp 83–89

18. Arango GF (1988) Domain engineering for software reuse. PhD

Thesis, University of California, Irvine

19. Glinz M (2007) On non-functional requirements. In: 15th IEEE

international requirements engineering conference, 2007. RE’07,

pp 21–26

20. Kazman R, Abowd G, Bass L, Clements P (1996) Scenario-based

analysis of software architecture. IEEE Softw 13:47–55

21. Freeman P (1987) Software perspectives: the system is the

message. Addison-Wesley Longman Publishing Co. Inc, Boston

22. Oxford English Dictionary (2015) Pervasive, adj. http://www.

oxforddictionaries.com/definition/english/pervasive?q=pervasive

23. Salen K, Zimmerman E (2004) Rules of play: game design fun-

damentals. MIT Press, Cambridge

24. Montola M, Stenros J, Wærn A (2009) Pervasive games: theory

and design. Morgan Kaufmann, Burlington

25. Nieuwdorp E (2007) The pervasive discourse: an analysis.

Comput Entertain CIE 5(2):13. doi:10.1145/1279540.1279553

26. Montola M, Waern A, Nieuwdorp E (2006) Domain of pervasive

gaming. IPerG

27. Davies H (2007) Place as media in pervasive games. In:

Porceedings of fourth Australasian conference on interactive

entertainment, pp 7:1–7:4

28. Magerkurth C, Cheok AD, Mandryk RL, Nilsen T (2005) Per-

vasive games: bringing computer entertainment back to the real

world. Comput Entertain CIE 3:4

29. Saarenpaa H, Korhonen H, Paavilainen J (2009) Asynchronous

gameplay in pervasive multiplayer mobile games. In: Proceed-

ings of 27th international conference on extended abstracts on

human factors in computing systems, pp 4213–4218

30. McGonigal J (2006) This might be a game: ubiquitous play and

performance at the turn of the twenty-first century. PhD Thesis,

University of California, Berkeley

31. Linner D, Kirsch F, Radusch I, Steglich S (2005) Context-aware

multimedia provisioning for pervasive games. In: International

symposium on multimedia, IEEE computer society, Los Alami-

tos, CA, pp 60–68

32. Capra M, Radenkovic M, Benford S, Oppermann L, Drozd A,

Flintham M (2005) The multimedia challenges raised by perva-

sive games. In: Proceedings of 13th annual ACM international

conference on multimedia, pp 89–95

33. Walther B (2005) Notes on the methodology of pervasive gam-

ing. In: Kishino F, Kitamura Y, Kato H, Nagata N (eds) Enter-

tainment computing—ICEC 2005. Springer, Berlin, pp 488–495

34. Hinske S, Lampe M, Magerkurth C, Rocker C (2007) Classifying

pervasive games: on pervasive computing and mixed reality.

Concepts Technol Pervasive Games Read Pervasive Gaming Res

1:11–38

35. Benford S, Magerkurth C, Ljungstrand P (2005) Bridging the

physical and digital in pervasive gaming. Communications of the

ACM, vol 48, pp 54–57

36. Milgram P, Takemura H, Utsumi A, Kishino F (1994) Aug-

mented reality: a class of displays on the reality-virtuality con-

tinuum. Syst Res 2351:282–292

37. McGonigal J (2003) A real little game: the pinocchio effect inpervasive play. In: Marinka C, Joost R (eds) Level up conference

proceedings: proceedings of the 2003 digital games research

association conference. CD ROM. University of Utrecht, Utrecht

38. Weiser M (1991) The computer for the 21st century. Sci Am

265:66–75

39. IBM Research: The convenience of small devices: how pervasive

computing will personalize e-business. https://web.archive.org/

web/20000420092553/http://www.research.ibm.com/resources/

magazine/1998/issue_3/bregman398.html

40. Dey AK (2001) Understanding and using context. Pers Ubiqui-

tous Comput 5:4–7

41. Leite JCSP, de Moraes EA, de Castro CEPS (2007) A strategy for

information source identification. In: Anais do WER07—work-

shop em Engenharia de Requisitos, Toronto, pp 25–34

42. IPerG: Integrated Project of Pervasive Games. http://www.perva

sive-gaming.org/index.php

43. Valente L, Feijo B (2013) A survey on pervasive mobile games.

Departamento de Informatica, PUC-Rio, Rio de Janeiro

44. Lindt I, Ohlenburg J, Pankoke-Babatz U, Ghellal S (2007) A

report on the crossmedia game epidemic menace. Comput

Entertain CIE 5(1):8. doi:10.1145/1236224.1236237


123

http://www.gamasutra.com/view/feature/132491/a_new_attitude_to_game_.php

http://www.gamasutra.com/view/feature/132491/a_new_attitude_to_game_.php

http://gbanga.com/portfolio/gbanga-famiglia/

http://gbanga.com/portfolio/gbanga-famiglia/

http://itunes.apple.com/us/app/geo-hunters/id417926906%3fmt%3d8%26ign-mpt%3duo%253D6

http://itunes.apple.com/us/app/geo-hunters/id417926906%3fmt%3d8%26ign-mpt%3duo%253D6

http://www.oxforddictionaries.com/definition/english/pervasive?q=pervasive

http://www.oxforddictionaries.com/definition/english/pervasive?q=pervasive

http://dx.doi.org/10.1145/1279540.1279553

https://web.archive.org/web/20000420092553/http://www.research.ibm.com/resources/magazine/1998/issue_3/bregman398.html



http://www.pervasive-gaming.org/index.php

http://www.pervasive-gaming.org/index.php

http://dx.doi.org/10.1145/1236224.1236237

45. Lindt I, Ohlenburg J, Pankoke-Babatz U, Ghellal S, Oppermann

L, Adams M (2005) Designing cross media games. In: Proceed-

ings of 2nd international workshop on pervasive gaming appli-

cations, Munich, pp 8–13

46. Benford S, Crabtree A, Flintham M, Drozd A, Anastasi R, Paxton

M, Tandavanitj N, Adams M, Row-Farr J (2006) Can you see me

now? ACM Trans Comput Hum Interact TOCHI 13:100–133

47. Joffe B (2007) Mogi. In: Borries F, Walz SP, Bottger M (eds)

Space time play. Birkhauser Basel, pp 224–225

48. Peitz J, Saarenpaa H, Bjork S (2007) Insectopia: exploring per-

vasive games through technology already pervasively available.

In: Proceedings of the international conference on advances in

computer entertainment technology, ACM, New York, NY,

pp 107–114

49. Benford S, Flintham M, Drozd A, Anastasi R, Adams M, Row-

Farr J, Oldroyd A, Sutton J, Park A (2004) Uncle roy all around

you: implicating the city in a location-based performance. In:

ACE04. ACM Press

50. Rashid O, Bamford W, Coulton P, Edwards R, Scheible J (2006)

PAC-LAN: mixed-reality gaming with RFID-enabled mobile

phones. Comput Entertain CIE 4(4):4. doi:10.1145/1178418.

1178425

51. Bartneck C, Hu J, Salem B, Cristescu R, Rauterberg M (2008)

Applying virtual and augmented reality in cultural computing.

IJVR 7:11–18

52. Tuulos V, Scheible J, Nyholm H (2007) Combining web, mobile

phones and public displays in large-scale: manhattan story

mashup. In: LaMarca A, Langheinrich M, Truong K (eds) Per-

vasive Computing. Springer, Berlin, pp 37–54

53. Chatzigiannakis I, Mylonas G, Kokkinos P, Akribopoulos O,

Logaras M, Mavrommati I (2011) Implementing multiplayer

pervasive installations based on mobile sensing devices: field

experience and user evaluation from a public showcase. J Syst

Softw 84:1989–2004

54. FinN: Magnetize words. http://funinnumbers.eu/index.php?op

tion=com_content&view=article&id=15

55. Mottola L, Murphy AL, Picco GP (2006) Pervasive games in a

mote-enabled virtual world using tuple space middleware. In:

Proceedings of 5th ACM SIGCOMM workshop on network and

system support for games. ACM, New York, NY

56. Flintham M (2003) Uncle Roy all around you: mixing games and

theatre on the city streets. In: Copier M, Raessens J (eds) Pro-

ceedings level up the first international conference of the digital

games research association DIGRA, pp 168–177. University of

Utrecht and Digital Games Research Association

57. Lyytinen K, Yoo Y (2002) Issues and challenges in ubiquitous

computing. Commun ACM 45:62–65

58. Gigantic Mechanic: Gigaputt:: Make the world your golf course!

http://giganticmechanic.com/games_gigaputt.html

59. Ballagas R, Walz SP (2007) REXplorer: using player-centered

iterative design techniques for pervasive game development. In:

Magerkurth C, Roecker C (eds) Pervasive gaming applications—

a reader for pervasive gaming research, vol 2. Shaker, Aachen,

pp 255–284

60. Soute I, Markopoulos P, Magielse R (2009) Head up games:

combining the best of both worlds by merging traditional and

digital play. Pers Ubiquitous Comput 14:435–444

61. Bell M, Chalmers M, Barkhuus L, Hall M, Sherwood S, Tennent

P, Brown B, Rowland D, Benford S, Capra M, Hampshire A

(2006) Interweaving mobile games with everyday life. In: Pro-

ceedings of SIGCHI conference on human factors in computing

systems, pp 417–426

62. Ekman I, Ermi L, Lahti J, Nummela J, Lankoski P, Mayra F

(2005) Designing sound for a pervasive mobile game. In: Pro-

ceedings of the 2005 ACM SIGCHI international conference on

advances in computer entertainment technology, pp 110–116

63. Coenen T, Mostmans L, Naessens K (2013) MuseUs: case study

of a pervasive cultural heritage serious game. J Comput Cult

Herit 6:8:1–8:19

64. Dixon D, Kiani SL, Ikram A (2013) Experiences with AR plots:

design issues and recommendations for augmented reality based

mobile games. Commun Mob Comput 2:1–6

65. Valente L, de Souza CS, Feijo B (2008) An exploratory study on

non-visual mobile phone interfaces for games. In: Proceedings of

the VIII Brazilian symposium on human factors in computing

systems. Sociedade Brasileira de Computacao, Porto Alegre,

Brazil, pp 31–39

66. Valente L, Souza CSD, Feijo B (2009) Turn off the graphics:

designing non-visual interfaces for mobile phone games. J Braz

Comput Soc 15:45–58

67. Schmitz M, Moniri MM (2009) Burgomaster and Pedro—a per-

vasive multi-player game for rural tourism. In: Games and virtual

worlds for serious applications, 2009. Conference in VS-

GAMES’09, pp 205–208

68. Jegers K (2008) Investigating the applicability of usability and

playability heuristics for evaluation of pervasive games. In: Third

international conference on internet and web applications and

services, 2008. ICIW’08, pp 656–661

69. Koivisto E, Eladhari M (2006) User evaluation of a pervasive

mmorpg concept. In: DIME conference, Bangkok, Thailand

70. Martins T, Romao T, Sommerer C, Mignonneau L, Correia N

(2008) Towards an interface for untethered ubiquitous gaming.

In: Proceedings of the 2008 international conference on advances

in computer entertainment technology. ACM, New York, NY,

pp 26–33

71. Vogiazou Y, Reid J, Raijmakers B, Eisenstadt M (2006) A

research process for designing ubiquitous social experiences. In:

Proceedings of the 4th Nordic conference on human-computer

interaction: changing roles. ACM, New York, NY, pp 86–95

72. Reid J (2008) Design for coincidence: incorporating real world

artifacts in location based games. In: Proceedings of the 3rd

international conference on digital interactive media in enter-

tainment and arts, ACM, New York, NY, pp 18–25

73. Ishii H, Ullmer B (1997) Tangible bits: towards seamless inter-

faces between people, bits and atoms. In: Proceedings on SIGCHI

conference on human factors in computing systems, pp 234–241

74. Waern A, Montola M, Stenros J (2009) The three-sixty illusion:

designing for immersion in pervasive games. In: Proceedings

27th international conference on human factors in computing

systems, pp 1549–1558 (2009)

75. Ballagas R, Kratz SG, Borchers J, Yu E, Walz SP, Fuhr CO,

Hovestadt L, Tann M (2007) REXplorer: a mobile, pervasive

spell-casting game for tourists. CHI 07 Ext Abstr Hum Factors

Comput Syst pp 1929–1934

76. Drozd A, Benford S, Tandavanitj N, Wright M, Chamberlain A

(2006) Hitchers: designing for cellular positioning. In: Dourish P,

Friday A (eds) UbiComp 2006: ubiquitous computing. Springer,

Berlin, pp 279–296

77. Cunha H, Sampaio do Prado Leite JC, Duboc L, Werneck V

(2013) The challenges of representing transparency as patterns.

In: 2013 IEEE third international workshop on requirements

patterns (RePa), pp 25–30

78. Chung L, Nixon BA, Yu E, Mylopoulos J (1999) Non-functional

requirements in software engineering. Springer, Berlin

79. Baldwin CY, Clark KB (2000) Design rules vol 1: the power of

modularity. MIT Press, Cambridge

80. Lindemann U DSMweb.org: design structure matrix (DSM).

http://dsmweb.org/

81. Valente L (2011) A methodology for conceptual design of per-

vasive games. PhD Thesis, PUC-Rio

82. Boehm BW, Brown JR, Kaspar H (1978) Characteristics of

software quality. North-Holland, Amsterdam


123

http://dx.doi.org/10.1145/1178418.1178425

http://dx.doi.org/10.1145/1178418.1178425

http://funinnumbers.eu/index.php%3foption%3dcom_content%26view%3darticle%26id%3d15

http://funinnumbers.eu/index.php%3foption%3dcom_content%26view%3darticle%26id%3d15

http://giganticmechanic.com/games_gigaputt.html

http://dsmweb.org/

83. Barbacci M, Klein MH, Longstaff TA, Weinstock CB (1995)

Quality attributes. Carnegie-Mellon University, Software Engi-

neering Institute, Pittsburgh

84. Simon HA (1996) The sciences of the artificial, 3rd edn. The MIT

Press, Cambridge

85. Giorgini P, Mylopoulos J, Nicchiarelli E, Sebastiani R (2002)

Reasoning with goal models. In: Spaccapietra S, March ST,

Kambayashi Y (eds) Conceptual modeling—ER 2002. Springer,

Berlin Heidelberg, pp 167–181

86. Serrano M, Leite JCSP (2011) Capturing transparency-related

requirements patterns through argumentation. In: 2011 first

international workshop on requirements patterns (RePa),

pp 32–41

87. Browning TR (2001) Applying the design structure matrix to

system decomposition and integration problems: a review and

new directions. IEEE Trans Eng Manag 48:292–306

88. MacCormack A, Rusnak J, Baldwin CY (2006) Exploring the

structure of complex software designs: an empirical study of open

source and proprietary code. Manag Sci 52:1015–1030

89. Lopes CV, Bajracharya SK (2006) Assessing Aspect Modular-

izations Using Design Structure Matrix and Net Option Value. In:

Rashid A, Aksit M (eds) Transactions on Aspect-Oriented Soft-

ware Development I. Springer, Berlin Heidelberg, pp 1–35

90. Matos PJ, Duarte R, Cardim I, Borba P (2007) Using design

structure matrices to assess modularity in aspect-oriented soft-

ware product lines. In: Proceedings of the first international

workshop on assessment of contemporary modularization tech-

niques. IEEE Computer Society, Washington, DC, USA, p 4

91. Chung L, Leite JCSDP (2009) On non-functional requirements in

software engineering. In: Borgida AT, Chaudhri VK, Giorgini P,

Yu ES (eds) Conceptual modeling: foundations and applications.

Springer, Berlin, pp 363–379

92. Leite JCSDP, Cappelli C (2010) Software transparency. Bus Inf

Syst Eng 2:127–139


123

Mapping quality requirements for pervasive mobile games

Documents

Transcript of Mapping quality requirements for pervasive mobile games