Id

IMRS

a

ARRAA

KMMGSPALCDL

1

iiawehbafpp

tw

(l

0d

The Journal of Systems and Software 84 (2011) 1989–2004

Contents lists available at ScienceDirect

The Journal of Systems and Software

journa l homepage: www.e lsev ier .com/ locate / j ss

mplementing multiplayer pervasive installations based on mobile sensingevices: Field experience and user evaluation from a public showcase

oannis Chatzigiannakis, Georgios Mylonas ∗, Panagiotis Kokkinos, Orestis Akribopoulos,arios Logaras, Irene Mavrommati

esearch Academic Computer Technology Institute (RACTI), Computer Engineering and Informatics Department, University of Patras, Greece,chool of Applied Art, Hellenic Open University, Greece

r t i c l e i n f o

rticle history:eceived 16 February 2011eceived in revised form 24 June 2011ccepted 26 June 2011vailable online 22 July 2011

eywords:obileiddlewareaming

a b s t r a c t

In this work we discuss Fun in Numbers, a software platform for implementing multiplayer games andinteractive installations, that are based on the use of ad hoc mobile sensing devices. We utilize a detailedlog of a three-day long public showcase as a basis to discuss the implementation issues related to a setof games and installations, which are examples of this unique category of applications, utilizing a blendof technologies. We discuss their fundamental concepts and features, also arguing that they have manyaspects and potential uses. The architecture of the platform and implementation details are highlighted inthis work, along with detailed descriptions of the protocols used. Our experiments shed light on a numberof key issues, such as network scaling and real-time performance, and we provide experiments regardingcross-layer software issues. We additionally provide data showing that such games and installations can

ensorservasivepplicationocation-awareontext-awareeployment

be efficiently supported by our platform, with as many as 50 concurrent players in the same physicalspace. These results are backed up by a user evaluation study from a large sample of 136 visitors, whichshows that such applications can be seriously fun.

© 2011 Elsevier Inc. All rights reserved.

arge-scale

. Introduction – motivation

We are currently witnessing an unprecedented level of activityn many fields related to the cross section of the digital and phys-cal domain. We are gradually discovering what we can do (i.e., inconceptual sense) and how to implement it (software and hard-are ecosystems), getting closer to the pervasive computing future

nvisioned in the previous decades. In the meantime, our idea ofow and where this vision is going to be applied has moved welleyond the classic “smart fridge” paradigm. In that respect, gamingnd entertainment are two fields that we believe are ideal targetsor applying this vision; they attract tremendous interest and haverogressed along with all of the major advances in computing theast few decades.

In this work, we discuss our vision for creating unique mul-iplayer games and interactive installations, by enhancing themith concepts that have stemmed from the research community

∗ Corresponding author. Tel.: +30 2610960377.E-mail addresses: ichatz@cti.gr (I. Chatzigiannakis), mylonasg@cti.gr

G. Mylonas), kokkinop@cti.gr (P. Kokkinos), akribopo@cti.gr (O. Akribopoulos),ogaras@cti.gr (M. Logaras), mavrommati@cti.gr (I. Mavrommati).

164-1212/$ – see front matter © 2011 Elsevier Inc. All rights reserved.oi:10.1016/j.jss.2011.06.062

the last few years. We have witnessed the astounding activity andresults produced by the Wireless Sensor Network (WSN) researchcommunity in the last decade. Such activity has focused on provid-ing solutions on more general distributed computing problems orspecialized application issues, producing a wealth of algorithmicsolutions and protocols, delivering practical results. The breadthof the issues studied the past few years is astounding, mainly dueto the paradigm shift that took place gradually, from small net-worked “islands” to the Internet of Things. Thanks to such softwaresystems, we are seeing projects with sensor networks monitoringthe seismic activity in a remote volcano (Song et al., 2009) inside ajungle and robotic actors (Knight et al., 2011) sensing in real-timethe reactions of the audience.

Furthermore, we have the so-called “Physical Computing” com-munity, mostly related to new media artists and interactiondesigners, with the Arduino ecosystem as its pinnacle. Develop-ment environments simple and powerful enough for non-computerscientists, have allowed the creation of a multitude of inter-active installation based on cheap embedded microcontrollers,

sensing components and actuators. However, sophistication andefficiency are often not regarded as primary issues, and implemen-tations in this category, more often than not, are considered as“prototypes”.

1 System

petiPffgiWttstCpItsamuou(t

otasbhtastb

daafatdtictwiiceeameo

tavw

990 I. Chatzigiannakis et al. / The Journal of

Moreover, at the same time frame, Pervasive Gaming has been aopular research subject (and a buzzword at the same time). In gen-ral, pervasive gaming refers to gaming applications conducted inhe open space, combined with some degree of context-awarenessn a scripted or unscripted fashion. The proliferation, initially, ofDAs and recently of smartphones (e.g., Apple’s iPhone), whicheature networking and sensing capabilities, has provided a plat-orm to implement such applications. Concepts used in pervasiveaming are also being adapted by more traditional mobile gam-ng platforms, such as proximity sensing and social networking.

e argue here that the pairing of efficient software systems andhe above concepts can lead to astonishing results, especially inhe unique context presented here. Up till now, we have not reallyeen the broad adaptation of the research community’s results byhe creative community, even though both are using similar tools.oming from a WSN research background, we have chosen inex-ensive WSN hardware as a basis for implementing such concepts.

n this work, we attempt to shed light into some of the main prac-ical issues that arise when combining pervasive gaming and WSN,uch as network scaling and number of users/players. We are over-ll interested in games and installations based on three features,ovement, presence, and other sensing inputs, all provided by these of sensor networking techniques. We focus here on the usef movement and presence to demonstrate our point. We buildpon our previous work, utilizing the Fun in Numbers frameworkAkribopoulos et al., 2009), a framework for creating mobile loca-ive multiplayer games.

Such games are fine examples of distributed systems, the designf which must deal with a number of challenges, depending on theype implemented: distributed and reliable operation, scalabilitynd efficient network communication, real-time operation con-traints, energy efficiency, time synchronization, etc. Thus, it shoulde clear that this category of applications, apart from suitableardware, needs efficient, flexible and reliable software systemso support their implementation. However, since this is a rel-tively new field, there are still some key issues, e.g., networkcaling, real-time performance, maximum number of users, etc.,hat have not been thoroughly studied even on an experimentalasis.

Fun in Numbers (FinN) is, in general, a platform for creating,eploying and administering multi-player games with pervasivend locative features that employ wireless sensor network nodess the gaming devices. We discuss here its architecture and maineatures, along with a set of key implementation issues. We utilizemulti-tier approach, that can be customized for several different

ypes of applications, based on tried models and technologies. Weescribe in detail the protocols upon which the implementation ofhe system services is based. Using FinN, we have implemented 4nstallations (see Section 6) that fall into the discussed applicationategory. We utilize Sun’s SPOT nodes as our prototype implemen-ation hardware platform, which provide the basic functionalities ofireless sensor network nodes. A number of services are currently

mplemented, allowing location awareness of wireless devices inndoor environments, performing sensing tasks while on the move,oordinating basic distributed operations. We provide a series ofxperimental results, essentially the result of a three-day-longxhibition at a local theater, organized in order to validate theppeal of the installations and the overall suitability of the imple-entation. This is one of very few works presenting large-scale

xperimental results in realistic settings, and specifically in frontf an unbiased audience.

Our results indicate a very positive response from the people

hat visited this exhibition and that the implementation platform isdequate in most of the aspects considered. We also opted for pro-iding a detailed log of our field experiences from this exhibition,hich emphasizes the difficulties we faced, along with a discussion

s and Software 84 (2011) 1989–2004

on practical guidelines for deploying such large-scale systems – i.e.,with up to 50 concurrent users.

Regarding the organization of this work, in Section 2 we discussrelated work and differences from the approach presented here.In Section 3 our perspective on multiplayer games and interactiveinstallations is presented. We provide sample scenarios, along withan overview of the architecture of our software platform. Impor-tant aspects, such as technologies used and services provided byFinN are discussed in Section 4. The evaluation of a set of cross-layer issues is discussed in Section 5. A description of the deployedinstallations follows in Section 6. In the remaining sections, weprovide a day-to-day description of a public showcase of our plat-form, supported by experimental data (Section 7), while in Section8 we provide results from a user evaluation study, that shows avery positive reaction towards our implementation. Lastly, we pro-vide a discussion on lessons learned from such an exhibition, andconclude this work.

2. Related work

There has been a wealth of activity in the pervasive gaming andinteractive installations the last decade or so. Pervasive gamingcan mean many different things; we prefer to define it generallyas games played in the physical space, indoors or outdoors, usingmobile handheld devices, context-awareness, and in certain casessome degree of infrastructure and scripting. Using “the world as agame board” is also a pretty good overall description; IPERG pro-vides a nice overview of recent trends in pervasive gaming, whichcan range from geocaching games, to playing tag-and-chase (Cheoket al., 2003) games in an urban scale. However, we believe per-vasive gaming has not yet reached its full potential. We too usesome of these familiar concepts in our work, but we emphasizereal-time interaction and context-awareness, along with intensephysical activity and large-scale deployments, features that havenot been explored previously to such a degree.

More specifically, large-scale interactive installations and gam-ing and the practical aspects of such concepts have not beendiscussed extensively in the bibliography. There are a number ofworks, like Barrenetxea et al. (2008), that discuss specifically aboutWSN deployment issues, but focus solely on stationary cases andstandard WSN applications; they are also described only from theperspective of a research scientist as an end-user. More innova-tive applications based on WSN are discussed in Senseable CityLab, UCLA Urban Sense, Chatzigiannakis et al. (2011). Other worksstudy pervasive games on a potentially urban scale, following amore centralized approach, where interactions between players areless frequent. Most of the works from the new media and interac-tive installations communities focus on small-scale deployments.Furthermore, there are few works discussing large deployments infront of the general public, e.g., Misund et al. (2009). However, inter-player interaction is on a different context, since they do not focuson rapidly changing network topologies, but usually discuss lessdynamic scenarios with smaller number of players. There is a com-mon pattern in such works; efficiency and scaling of the respectiveimplementations are usually not backed up by real-world data. Wediscuss here the deployment and operation of 50 devices in parallel,at the same physical location and in real-life conditions (a publicexhibition).

Pervasive gaming and interactive installations in a cultural set-ting has been a popular subject in recent years. Economou et al.(2008) gives an overview of the types of applications developed

for mobile devices in a museum setting. An example of a pervasivegame example in urban scale with a touristic context is Ballagaset al. (2008). The work reported here can be used to extend suchworks, providing additional interactivity and context-awareness,

System

wmitmi

o(sdwdatiacas

dbmtAb(odnp

Kc6otlomnouj

2miaudi

3

iugab(ei

I. Chatzigiannakis et al. / The Journal of

ith greater accuracy and efficiency as backed by the deploy-ent data. An interesting concept of applying games is described

n Reeves and Read (2009), where multiplayer games are utilizedo stimulate human interest and engagement in a work environ-

ent; complementary to this approach, our work could be used tomplement such games in larger, open physical spaces.

The last few years we are also seeing mobile gaming devicesf all sorts gaining “pervasive” features; e.g., current smartphonese.g., Apple’s iPhone) and next-generation portable gaming con-oles (e.g., the Nintendo 3DS) utilize concepts such as proximityetection to spontaneously ignite “tournaments”, or use social net-orking sites to add context to gaming experience. Adding to thisimension, we emphasize concepts from more “traditional” games,nd take them to another level by allowing physical game interac-ions through computing devices. Conceptually similar to this works Ubisoft’s “Battle Tag”, a multiplayer game made commerciallyvailable at the end of 2010; however, this is a very confined game,ontext-wise, and it’s current implementation allows a compar-tively limited number of players (i.e., 8), whereas we currentlyupport as much as 50 players in the same space.

Moreover, in this work, we utilize IEEE 802.15.4-compatibleevices, a wireless networking solution that, in our opinion, suitsetter the application domain we are discussing here and offersore possibilities. To our knowledge, this is one of the first works

o utilize such technologies in the pervasive gaming research area.lthough smartphones and portable gaming consoles carry a num-er of integrated sensors and have built-in wireless capabilitiesWiFi, Bluetooth), they are not as versatile and easy to scale, inrder to develop ad hoc networking techniques. E.g., Bluetooth’sesign does not allow quick and efficient detection of networkeighborhoods in under 100 ms time (a typical limit for humanerception).

Regarding the specific interactive installations presented here,eefe et al. (2008) describes a concept for drawing in 3D space,onceptually close to the “Chromatize Images” installation (Section), but we focus on multiplayer features and use of everydaybjects as interface methods, rather than on accuracy and ges-ure recognition. Finally, our work comes in contrast to approachesike Nintendo’s Wii or Microsoft’s Kinect. The use of cameras andther optic technologies translate into constraints in the deploy-ent field and the number of players supported. This work does

ot exclude fields with obstacles and other means of blocking line-f-sight and can be utilized outdoors. Additionally, it can supportp to 50 players, whereas such technologies are typically limited to

ust 4.This paper extends our own previous work (Akribopoulos et al.,

009; Chatzigiannakis et al., 2010a), by providing additional imple-entations of interactive installations, evaluation of software

mplementation issues, along with large-scale deployment datand user evaluation results in real-life conditions. The protocolssed in FinN were briefly referenced in these works; here, they areescribed for the first time in much more detail, providing also

nsight to their actual implementation.

. Fun in numbers overview – concepts and architecture

We first discuss about the type of applications we are interestedn; FinN targets scenarios where a large number of users participatesing wireless handheld devices with sensing capabilities. Theseames and installations can take place in the same or different placend time. Overall, the operation of the games is either supported

y a backbone infrastructure that provides a number of servicese.g., localization, context awareness) and through which a centralntity coordinates and records the games’ progress, or all operations done in an ad hoc fashion.

s and Software 84 (2011) 1989–2004 1991

The users’ devices use wireless ad hoc networking protocolsto establish network connections/neighborhoods, communicatingwith other user devices or infrastructure ones. Embedded sensorsare utilized for providing input from the physical world, translatedaccording to the rules of each game/installation. E.g., high tempera-tures could be translated as “prohibited” areas. Accelerometers areused for recognizing gestures made by users; gestures are mappedto player interactions, e.g., “pass on the token”. Proximity detection,currently made possible through the use of wireless signal charac-teristics, is also used as a means of input, as well as movementoverall, i.e., not just gestures. Such input can be used to monitorthe progress inside a game and also enforce the rules defined forit. By utilizing such input we essentially create games in a more“traditional” fashion, but with added interaction features.

We provide here a categorization of the applications we envi-sion, in terms of interaction between users, existence of aninfrastructure and time-wise operation:

Spontaneous: activities are set up instantly between players, e.g.,imagine when a having a break from work at the office, playinga tag-and-run game with 15 players for a couple of minutes. Nospecific infrastructure is needed, with communication and sensinginputs be provided only by the mobile devices the players are car-rying themselves. For example, game results could be uploaded andstored centrally after the game is over, in order to gather statisticsor gain/gather game score points. No specific limits are imposedwhatsoever regarding time and place.

Storyline-based: a degree of infrastructure is used in order toprovide presence and other sensing input combined with a mix-ture of some sort of scenario and timely events. A central authoritycoordinates the game as mandated by the given script. An exampleof such a game, could be an entertainment/educational installationinside a museum, where players are given an initial scenario andmust discover elements to move forward in the game by visitingplaces, etc. The infrastructure intervenes both in the spatial andtemporal domains to define the possible game outcomes, but all isperformed within specifically defined limits.

Community-based: this is basically the rehash of traditionalgames, like “hide and seek”, augmented with the aid of computingdevices with sensing abilities, which can help in game operation,rules arbitration, statistics book-keeping, etc. They can be bothinfrastructure-less or infrastructure-based, but the distinct ele-ment here is the concept of the gaming community. This means,that there is a community playing games of various sorts, with theplaying activity spanning across a long time period and with largegaming interaction among the members of the community (Fig. 1).

FinN’s architecture is based on a hierarchy of layers for scalabil-ity and easy customization to different scenarios (heterogeneity).A number of services are currently implemented, allowing locationawareness of wireless devices in indoor environments, performingsensing tasks while on the move, coordinating basic distributedoperations and offering delay-tolerant communication. Playerscarry one or more handheld devices with wireless communica-tion and sensing capabilities. A backbone infrastructure may alsobe available, possibly forming a wireless mesh network. Such aninfrastructure consists of Stations, which are able to support theplayer devices with a number of services (e.g., localization, contextawareness) and may also operate actuators that add certain gam-ing elements. Each game instance is assigned to and coordinatedby a specific Engine, which is the local authority for each physicalgame site. The World is the topmost element that manages multiplephysical game sites and allows interaction with social networkingsites, e.g., Twitter. Fig. 2 illustrates these elements.

These heterogeneous elements (in terms of role, communica-tion, computation and energy capabilities) form a loosely-coupled,highly modular and customizable hierarchy. This allows FinN tosupport both ad-hoc and infrastructure-based games (or interactive

1992 I. Chatzigiannakis et al. / The Journal of Systems and Software 84 (2011) 1989–2004

seum

itmmbttifip

bndPbsbtgiapsi(

Fig. 1. (a) Spontaneous (tagging game), (b) Storyline-based (mu

nstallations). In the first case, a very limited backbone infrastruc-ure is available, thus almost all communication and computation

ust be performed by the handheld devices in a fully distributedanner. In the second case, we wish to take advantage of the back-

one by following a “2-tier principle” (Imielinski and Korth, 1996),hus moving communication and computation to the fixed part ofhe network. Our approach allows services (e.g., discovery, prox-mity detection, gesture recognition) to be seamlessly reallocatedrom the player devices (where computation and communications expensive) to the backbone infrastructure (where resources areractically unlimited) with minimum programming effort.

Guardian layer: This layer essentially involves the devices usedy players during the games. The Guardian is the software compo-ent running in each player’s wireless sensing device and uses theevice’s capabilities in terms of user interface, communication, etc.rotocols for the discovery and the communication with the “back-one” infrastructure and other Guardians are provided (see nextection). When another Guardian peer is discovered, the player maye prompted for further action, by using the sensors and the but-ons of her device. For monitoring the evolution of the game, eachame-related action is represented by an Event. Guardian peers alsomplement services that allow them to interact even when theyre disconnected from the “backbone” infrastructure for extendederiods of time. In particular, when an Event occurs, the Guardian

tores it to the device memory and when communication with thenfrastructure is possible, then all collected Events are forwardeddelay-tolerant communication service). Also, Guardians provide a

Fig. 2. Overall multilayer

excursion), (c) Community-based (augmented hide-and-seek).

subsystem, which processes the samples of the accelerometer andrecognizes gestures that correspond to game-related actions.

Game Station layer: This layer implements the “backbone”infrastructure, which is important, though not mandatory for allof the games developed. It provides localization and context-awareness services and it is through this infrastructure that the dataof the players are transferred to and from the higher layers of thearchitecture, for coordination and storing purposes. This wirelessbackbone is established by Station peers, with each Station con-trolling a specific physical area, responsible for the coordination ofthe infrastructure and of the game itself. The Stations communi-cate with the users’ devices either through local ad hoc networksor via personal area non-IP networks and act as gateways, essen-tially allowing communication between the players’ devices andthe Game Engine. Multiple Stations can be attached to an Engine inorder to extend area coverage or add points-of-interest. During theinitialization of a game, Stations communicate with the Engine andretrieve data such as the set of players, which are registered for thisgame instance, player devices and places-of-interest. Stations arealso responsible for the Guardians’ initialization and for forwardingall data generated during the course of a game to the Engine.

Game Engine layer: Each game instance is assigned to and coor-dinated by a specific Game Engine, i.e., it is the local “authority”for each game site. The Engine retrieves data from higher layers

and stores them locally, for the duration of a specific game. Inorder to avoid computational and communication overhead, databetween higher layers and the Engines can be synchronized period-

architecture of FinN.

I. Chatzigiannakis et al. / The Journal of Systems and Software 84 (2011) 1989–2004 1993

ittsiFv

agtavsisIsPirdmw

4

eStoaaubmtab

tpuEaP

Fig. 3. Technologies and layers used in the system.

cally. Thus, the processing and storage of generated events duringhe game is done locally. The Engine is also a control mechanismhat provides game-specific services and implements various gamecenarios. Communication between the Engine and the Stationss carried out through wired and/or wireless IP-based networks.inally, the Engine features an embedded Web container for pro-iding additional game specific information to players directly.

World layer: The World layer is the topmost layer of the hier-rchy, enabling the management of multiple FinN games, physicalame sites and users. In this layer lies the Hyper Engine, poten-ially interconnecting discrete games and installations, providingunified system. E.g., in an exhibition with multiple installations

isitors can interact with all installations using a single device. Theystem “remembers” the actions of a particular visitor from anothernstallation or a previous visit to a particular installation. Thus, itupervises all on-going games and monitors the events generated.t also enables easy logging of various statistics during parallel gameessions (such as in Section 8). This layer also includes the Worldortal, which is the central point of system management, providingnteraction with all the different game instances operating in theeal world. It is also the central storing point for all game-relatedata, such as player-related statistics and game history. Further-ore, it allows personalization capabilities and possible interactionith external social networking sites.

. Implementation details – software services

We implemented FinN using Sun’s SPOT platform for the play-rs’ devices. It is a small, battery-operated device running thequawk Java Virtual Machine, which acts as both an operating sys-em and a software application platform, allowing programmingf the devices in the Java Micro Edition (J2ME) platform. It usesn 180 MHz ARM920T-based microcontroller with 512 kB of RAMnd 4MB Flash. An IEEE 802.15.4 compliant CC2420 transceiver issed for communication. They also provide a basic user interface (2uttons and 8 LEDs) and a number of sensors (accelerometer, ther-istor, light). We decided to use this particular platform due to

he available computational resources; other WSN platforms usu-lly offer 10 kB of RAM and a processor at 8 MHz. The 8 LEDs and 2uttons improve the interfacing methods of the device.

A challenging aspect of this implementation was to enableransfer of data through the various heterogeneous layers. The com-lication arises from the fact that player devices are implemented

sing Java Micro Edition, while the other layers using Standarddition (see Fig. 3). Thus the standard Java Serialization API is notvailable across different editions. We decided to extend the Javaersistence Storage API to ensure that services and game events are

Fig. 4. Interconnections between the different layers.

communicated across layers in a seamless and efficient way. Com-munication between the Engine and World layers is implementedvia Hibernate; Remote Method Invocation (RMI) was used to allowcommunication between the Engine and Station layers. We imple-mented object serialization in combination with the RadiogramsAPI within the Squawk VM to enable the seamless exchange of dataobjects between Stations and Guardians. As a result, this approachallows the programmer to use the same objects throughout all lay-ers of the system without the need to keep separate versions foreach Java edition. Clearly, this reduces the development and main-tenance efforts. In Section 5 we evaluate the overhead to exchangeobjects across all layers of the heterogeneous hierarchy.

The key services provided by the platform, such as neighbordiscovery, localization and information exchange are discussed inthe following paragraphs. These services are fundamental in imple-menting our envisioned applications, while their interconnectionis depicted in Fig. 4.

Neighbor Discovery: Echo Protocol offers local connectivityawareness, while it is designed to run on resource-limited devices.It is also robust, able to adjust quickly to frequent and significanttopology changes and capable of distinguishing the different rolesof the discovered neighboring nodes (i.e., player, backbone/mobilestation). In addition, it allows customization of the propagated mes-sages. In particular, FinN player devices and backbone stations arecharacterized by a list of attribute-value pairs that describe the sta-tus of the game.

These descriptions are constantly broadcasted by the devices.In this respect, the Echo Protocol is also used as the building blockof other protocols and services, such as localization and leaderelection. In particular, in the leader election service the ID of thedevice/player broadcasted, is used as key parameter for selectingthe leader among a set of players. Echo Protocol is able to recognizewhether the communication with the surrounding devices is bi-directional or not. In general, players interact in pairs or in groupsby executing (simultaneously or not) actions. The coordination ofplayer actions almost always requires symmetric communication.The majority of theoretical works consider wireless links to be sym-metric, however in practice most of the times this is not true fora multitude of reasons. This fact significantly complicates gamedesign; a unidirectional link cannot provide acknowledgments of

receipt of messages. To overcome this problem, the Echo protocolattaches to each broadcasted packet the list of detected neigh-bors; i.e., the devices it has received a beacon from in the last

1 System

3l

ccdcdctticcbIcnsam

psStmactaawpMagBir

urbtattcic

raoa(egptlg

ao

994 I. Chatzigiannakis et al. / The Journal of

×beacon interval period. This attribute-value pair may lookike: neighbors = [11,81,5,43].

Echo Protocol relies on the devices’ IEEE 802.15.4 radio. Inontrast to Bluetooth, data is exchanged without establishing aonnection and concurrent transmission of messages to multipleevices is supported. Thus the interval between consecutive broad-asts can be set to less than 100ms time period while Bluetoothevices may take up to 10.24 s (Hay and Harle, 2009), signifi-antly improving discovery among devices. Clearly, by decreasinghe value of the interval of broadcasts, a near real-time responseo the topology changes can be achieved, at the expense ofncreased network load and energy consumption due to the bea-on messages exchanged. Moreover, Bluetooth limitations such asoncurrent connections to multiple nodes are handled much bettery 802.15.4, which allows a completely ad hoc network topology.n practice, we have seen Sun SPOTs handling up to 20 concurrentonnections, in the same 802.15.4 wireless channel, to neighboringodes, while having sufficient system operation. The flexibility ofelecting different 802.15.4 channels to use in Sun SPOTs, allows formuch greater total number of nodes as described in the experi-ental results section.Furthermore, although IEEE 802.15.4 is not currently nearly as

opular as Bluetooth or WiFi in mainstream mobile devices, e.g.,martphones, its use in combination with platforms such as SunPOTs possesses certain advantages. Apart from allowing access tohe lower network levels, typical 802.15.4 radios offer the ability to

odify the nodes’ communication range. Typical values range fromfew centimeters (minimum range) to 30 m (maximum). Setting aommunication range of 2 m allows the use of the radio transceivero be used as a sort of proximity sensor, in cases of course whereccurate distance estimation does not play a significant role. Suchtypical case is in our ad hoc games; players tend to move rapidlyhile, e.g., playing a tag game, while game interaction can takelace when players are in small physical proximity of each other.oreover, there is also the issue of energy consumption. Almost

ll of the current hardware sensor nodes use IEEE 802.15.4, for aood reason. It can have similar or lesser power requirements thanluetooth, while having a greater communication range. Also, it

s much better in handling power consumption than IEEE 802.11adios, due to lower bandwidth, transmission range, etc.

Since IEEE 802.154 targets specific market segmentsntil now, its adoption outside these environments and theesearch/academic sector is not wide. Therefore, there has toe a bridge/gateway device used in order to communicate withhe 802.15.4 devices (since there are few integrated solutionsvailable), which adds certain overhead and complexity. However,he provided Sun SPOT SDK alleviates many of these issues, liftinghis burden from developers. Also, since it targets low poweronsumption, its bandwidth is lower even than Bluetooth, andn cases where higher bandwidth is needed (e.g., input from aamera), that would potentially pose a problem.

Localization: In certain games, user devices need to sense theirelative location to each other and to specific landmarks. A simplepproach for proximity detection is to use the attribute-value pairsf the Echo protocol. By properly adjusting the transmission powernd assuming that the players hold the devices in a particular waye.g., strapped on their knee), the distance to another device can bestimated by the player device. For example, in a hidden treasureame devices can detect if the players have discovered them. Thisractically translates close to proximity detection. We typically sethe communication range to be around 2 m in cases where we uti-ize such a kind of proximity detection (e.g., spontaneous ad hoc

ames Akribopoulos et al., 2009).

In other games/installations (e.g., “Magnetize Words”), moreccurate location information is required on the relative positionf the players. The incorporation of location awareness in ad hoc

s and Software 84 (2011) 1989–2004

mobile sensor networks is a well-studied subject. A radio-basedapproach was chosen again here, using a fixed infrastructure con-sisting of at least three backbone stations (the so-called anchornodes) and the periodic broadcasts of the Echo protocol. Thisapproach allows the implementation of a wide range of centralizedlocalization algorithms (e.g., Savvides et al., 2004). For each bea-con received by these nodes, the Received Signal Strength Indicator(RSSI) and the Link Quality Indicator (LQI) are extracted to measurethe power of the signal. These indicators are continuously for-warded to the Engine Layer that computes the position of the devicebased on a set of previously-collected values (training values). Weimplemented the following algorithms: a) Simple Localization, theposition is that of the station with the bigger RSSI, b)Average Local-ization, using the euclidean distance between received RSSI/LQI andpreviously trained values, c) k-NN Localization, based on k-nearestneighbors algorithm in order to map the position of a node and d)Hybrid Localization, a combination of the above algorithms, whichwas the one used in practice.

More specifically, our decision to use the hybrid approach was atrade-off between accuracy and easiness of setup. Given the instal-lation we wanted to use the localization algorithm with (Section 6,“Magnetize Words”), there were certain rather unique localizationrequirements. Essentially, what we wanted to do was localizationmostly on a single axis, i.e., in parallel to a wall where certain imageswere projected, and not in a 2-axis plane (e.g., x and y). Thus, we sim-plified the problem of localization to provide a quicker response tothe players’ movement along a projection wall. This led also to asimplified setup approach: we divide the area that is to be local-ized in discrete sub-areas. We then conduct an initial calibrationphase, where we acquire readings from a single node placed in eachone of the sub-areas. After this initial phase, and during operationof the installation, the hybrid algorithm uses two steps: (a) it usesthe Simple Localization algorithm to detect a general sub-area, (b)it then uses one of the other two algorithms to compute a sub-area within the general sub-area computed in the previous step.This was due to the fact that the simple algorithm was better atdetecting a general sub-area than the other two, limiting possiblelocalization results and thus potential localization instabilities. Inpractice, we saw that the Average algorithm performed better inour deployment area.

Information Exchange: Given our choice of discovery and local-ization schemes, we now describe how game-related informationis exchanged between player devices and across FinN layers. Thebasic element of communication is the Event, which maintains a listof attribute-value pairs. Notifications of events can be delivered inthree different modes: real-time, multi-hop or delay-tolerant. Real-time mode is available when both sender and receiver devices arewithin transmission range. In the “Tug-of-war” interactive instal-lation, this mode is used to transmit continuous readings from theaccelerometer, so that the backbone Station can perform gesturerecognition. In this mode, failed transmissions are not repeated.Multi-hop mode is available when sender and receiver are notwithin communication range and the event needs to be deliv-ered without any time constraint. The default routing protocolprovided by Sun SPOT is AODV – other routing protocols can beused depending on the expected network conditions and desiredperformance.

Furthermore, due to various reasons (e.g., arbitrary movementof players, game strategies) communication with the “backbone”infrastructure (the Stations) may not be always possible. Duringthis period, the evolution of the game should not be affected, asplayers interact with each other and create events. In this case, the

delay-tolerant mode allows operation on both connected and dis-connected modes. When communication with the infrastructureis available, events are transmitted, otherwise events are storedand sent when communication is established. Thus, players can

I. Chatzigiannakis et al. / The Journal of Systems and Software 84 (2011) 1989–2004 1995

t buck

et

uPotrbm

smdpaeoeitbw

t

Fig. 5. Toddlers and children interact with the smar

nter and leave the area covered by the infrastructure, enjoyinghe games and keeping their statistics or history consistent.

User Interface: we utilize the 8 LEDs on the devices, the 2ser buttons and the accelerometer found on the SPOT boards.layer devices execute a subsystem, which processes the samplesf a 3-axis accelerometer and recognizes gestures that correspondo game-related actions. We aimed at user-independent gestureecognition, with no training phase involved, and supported fourasic gestures: (i) clockwise, (ii) counter-clockwise and (iii) violentovement with direction to the right/left.These specific gestures were chosen because of their relative

implicity to be recognized and the nature of the games imple-ented so far. Since we target multiple demographic groups and

o not require large precision in our games, we chose to use a sim-le approach. We sample the 3-axial accelerometer of Sun SPOTst 20 Hz and continuously check the convolutions between differ-nt planes in a certain time frame; we map them to this small setf gestures when the samples received are above a certain accel-ration threshold. If a more advanced gesture recognition systems required, this service can be transferred in upper architectureiers in a similar way to the Localization module. However, as can

e seen in the user evaluation results presented in this work, usersere quite happy in practice with the gesture recognition results.

Regarding user interface methods that are not provided byhe devices themselves, significant aspects are graphics, sound

Fig. 6. Players dip their hand in smart buckets and throw the

ets to pick one of the basic colors (Chromatize It!).

effects and music. We utilized Processing, which provides a protyp-ing environment with multimedia capabilities. In all installationsdescribed here, we developed graphical interfaces and also usedsound (utilizing the Minim library) to provide feedback andenhance the experience of the visitors. At the same time, the move-ment and number of players, the intensity of their gestures, and theconcurrent gestures, generated a background soundtrack coveringthe whole location. Moreover, “Chromatize Images” and “Chrom-atize it!” utilized tangible objects: players “dipped” their devicein “smart” paint buckets in order to “pick” a color, see Figs. 5 and6. The buckets were essentially containing a Station node with itscommunication range set to a minimum, acting in a similar fashionto an RFID tag (Fig. 7).

5. Cross-layer issues – evaluation

In this section we take a closer look at issues introduced byhaving a tiered architecture with different hardware/software plat-forms. As mentioned in the previous sections and depicted inFigs. 3 and 4, we have the Guardian, Station and Engine layers toimplement our distributed system. The protocols discussed in the

previous sections may execute in different layers and, in complexcases, objects may have to traverse all of FinN’s layers. Thus, cross-layer issues and their effect on the system’s overall performanceare quite important. The experiments and setup discussed here

color to paint the pop-art image (Chromatize Images).

1996 I. Chatzigiannakis et al. / The Journal of Systems and Software 84 (2011) 1989–2004

nter, C

pd

tsiXcndenrpemt

otGpuatatt8

Fm

Fig. 7. Snapshot of the Lithografio Venue: Tug of War game in the ce

rovide insight into some of the issues we ran into during actualeployment inside more realistic settings.

During the evaluation presented in this section, we utilized lap-ops and desktop computers, along with a number of Alix Gateways,o as to build our backbone infrastructure. Their small size wasdeal for using them as Game Stations or Engines. The lightweightubuntu Linux distribution was used on the Alix gateways, whileommunication between them was established over WiFi. Commu-ication between the Engine for the experiments and the relatedatabase (MySQL) was established over 100 Mbps Ethernet. Allxperiments took place indoors, in a controlled environment, i.e., aumber of our office rooms, while all nodes were placed in the sameoom during each of the experiments. In experiments with multi-le nodes, all nodes were placed within a distance of 1–2 m fromach other, on the same height, using no special physical arrange-ent, i.e., not in a grid fashion, in order to simulate more typical

opologies.As a characteristic example, we study here the propagation time

f events generated in the players’ devices, as they cross all ofhe system’s different layers. We initially assume that a device’suardian is already connected to the infrastructure. timeG is therocessing time of an event in the Guardian Layer, on its way topper layers, while timeS and timeE is the time spend in the Stationnd Engine Layers, respectively. In our experiments we transmit-ed 100 events each time. The overall time for 1 event is 46 ms on

verage. Individual duration on each layer is formed as follows:imeG = 38 ms, timeS = 2.5 ms and timeE = 5.5 ms. This makes it clearhat timeG acquires the highest percentage of overall time, namely3%. By further analyzing timeG we observed that the biggest part

ig. 8. The pipeline effect between the three layers, Guardian, Station and Engine. One Gueasured for i = 100.

hromatize It! at the back/right, Chromatize Images at the back/left.

of this time is due to the built-in communications functions of SunSPOTs, which are also utilized by FinN. These functions set cer-tain boundaries for the time efficiency of overall communication.We also evaluated the case where players/Guardians are gatheredaround a Station, in order to upload the generated events. In thiscase, we measured the required time for all events to be insertedin the database in relation to the number of Guardians participat-ing in this procedure. While keeping static the number of storedevents on each Guardian (100 events), we increased the number ofGuardians sending the events. We were particularly interested inthe event reception rate (ms/event) on the Station layer, as well asthe event processing rate (ms/event) on the Station and Engine lay-ers. The Event reception rate shows the time needed for an Eventto be received by the Station, while event processing rate shows therequired time for an Event to be processed on the Station and Enginelayers, respectively.

Our first set of experiments were conducted using a singleGuardian. In this case, the event reception rate was 37.6 ms/event,while the event processing rate on the Station layer was 2.4 ms/eventand on the Engine layer 5.3 ms/event. It is obvious that process-ing rates are significantly higher than the event reception rate. Forthis reason, the Station and the Engine remain idle for 35.2 ms and32.3 ms per event, respectively, meaning that a bottleneck effect isobserved on the Guardian layer. This effect is caused due to thelimitations of the devices. Also, we should note that our imple-

mentation allows events to be processed in an asynchronous wayas already mentioned. This results in a pipeline effect regarding theuppermost layers of the system. These effects, as well as the differ-ence between event reception and processing rate, are illustrated

ardian is updating infrastructure with i events in number. The durations noted are

I. Chatzigiannakis et al. / The Journal of System

Table 1Distribution of time in milliseconds between different layers. Due to the bottleneckeffect, Overall time is approximately same with Total Guardian time. Proc signifiesthe processing time on each layer.

Nodes Guardian Station Engine Overall

Total Total Proc Total Proc

1 3760 3722 242 3725 531 37862 6031 5993 272 5996 840 60363 7106 7068 425 7070 1216 71114 8709 8669 511 8674 1839 87155 9115 9074 620 9079 2295 9121

ii

cmtpSci

(see Fig. 13) as to allow guests to gradually experience a spectrum

6 21,009 20,969 768 20,973 2648 21,015

n Fig. 8. Due to this, the overall time for 100 events to be insertedn the database is totalG + timeS + timeE.

Next, we increased the number of Guardians repeating the pro-edure described above. This created a realistic scenario, whereore than one Guardians are updating the infrastructure simul-

aneously. We tried to decrease the event reception rate as little asossible, achieving a rate lower than the event processing rate on the

tation. This would result in events to be received faster than theyould be processed forcing a significant number of events pushedn the queue. The results are summarized in Table 1.

Fig. 9. Visitors move in the physical space with “word cl

Fig. 10. The red and green teams competing each othe

s and Software 84 (2011) 1989–2004 1997

6. Showcased interactive installations overview

We showcased a set of interactive installations at a three-dayevent, open to the public, that took place at the Lithografio theater,Patras, Greece. A set of 4 installations-games was demonstrated,each one of them revealing different characteristics and aspectsof the applications discussed here. Each visitor was given a smalllightweight device (a Sun SPOT, see Fig. 5). Visitors interacted withthe installations either by physical movement (see Fig. 9) or byperforming (Figs. 10 and 11) gestures (see Fig. 12).

Given the showcase venue, we decided on exhibiting a subset ofthe applications possible with FinN. More specifically, we decidednot to include our spontaneous ad hoc games already implemented(Section 3), because of the space limitations we had in an indoorsarea, and also because of the “interference” and possible annoy-ances such activities would probably have in the more “static”applications described here. However, a set of experimental resultson such applications and a more detailed description are availablein Chatzigiannakis et al. (2010a, 2010b).

The installations were placed in such a way inside the venue

of potential interactions with the digital world. As soon as the vis-itor entered the “interactive area”, a word cloud from “MagnetizeWords” would follow her. Requiring limited interaction and based

ouds” following them around (Magnetize Words).

r to “pull the rope” using gestures (Tug of War).

1998 I. Chatzigiannakis et al. / The Journal of Systems and Software 84 (2011) 1989–2004

Fig. 11. The green team trying to develop a common strategy – the red team still discussing (Tug of War).

Fig. 12. Synchronized gestures for color throwing to mix colors on the canvas (Chromatize Images).

Fig. 13. The setup of the installations in Lithografio Venue. The boundaries for each installation are seamless and defined from a set of 9 infrastructure game stations (S1–S9).

System

oaikui“

iidoimioftpt

fhTwtb

tslttcvgtoma

btppetfc

7

2matfbttI

on the corresponding Game.In Fig. 14 the analysis of the received events per game is illus-

trated. Events are divided into four types. (i) Init/Start: events

Table 2Events received from each station separated by game (from left to right: Tug of War,Chromatize It, Chromatize Image, Magnetize Words). 5% (4407 of 87,157) eventswere received from stations which were not related to the game contained in theevent message.

BaseStation Games

TOW CI CImage MW

S1 7868 23 8 2

I. Chatzigiannakis et al. / The Journal of

n motion visitor’s movement alone, “Magnetize Words” acts liken invitation and warm-up for the interaction about to follow. Mov-ng to the right, on “Tug of War”, participants experience a differentind of interaction; they stand almost still, performing gesturessing their arms alone. Moving further through the Venue, vis-

tors combine motion and gestures to play “Chromatize It!” andChromatize Images”.

Magnetize Words Our presence and motion in the physical worlds the most natural way to interact with the digital world. On the vis-tor’s entrance in the space of projections, as soon as the visitor isetected, a “poem” is formed and then decomposed into a cloudf words,1 following her motion across a 10-m long wall. A local-zation algorithm is used to detect in real-time to recognize the

ovement of the users along this wall. The word clouds follow-ng two or more visitors can mix as they physically approach eachther, and words are “magnetized” and exchanged between the dif-erent clouds. The words are continuously rearranged according tohe movement of visitors and duration of interactions with otherlayers, with the word-order continuously alternating, affectinghe perceived meaning.

Tug Of War Fast and violent hand gestures are used to express oureelings in many daily encounters. Visitors are invited to interact in aighly competitive game by continuously performing fast gestures.he game is played by 2 teams with over 10 persons on each teamhere each team tries to “pull the rope” and expand over the area of

he other team. Certain gestures (that are randomly selected) muste repeated as many times as possible within a given time frame.

Chromatize It! Light is a magical medium of significant impor-ance to our daily activities. Visitors move through the physicalpace that is illuminated by three light sources (red, blue and yel-ow). As soon as they enter the areas that are brightly illuminated,hey “pick” the respective color; we are using proximity detec-ion to detect players that enter these specific areas. These colorsan be then used to color an initially white chromatic mass. Theisitor must approach the mass and performing a throwing-likeesture to splash the color. The floating mass gradually changes itsone representing the mixture of the combined colors. More thanne players can simultaneously participate to collectively color theass to a particular target color. When the correct mixture has been

chieved, players advance to the next level.Chromatize Images Players dip their hand-held devices in paint

uckets, “pick” colors, and throw them on the screen, in ordero color familiar pop-art images. These images have been pre-rocessed and separated into color areas, thus players are addingrogressively layers, and are not randomly “drawing”. Several play-rs can mix their colors by throwing them simultaneously towardshe projection surface and make color combinations. Sounds, dif-erent and related to each of the images, reward the players whenompleting the coloring of each image.

. An exhibition log

The decision for organizing such an event was taken on January010, five months before the exhibition. We had multiple goals:ost importantly, it was time to demonstrate our work in front ofgeneral audience. Until that time, our work was presented mostly

o a computer-science related audience (i.e., colleagues, students,aculty, etc.). It would therefore be a great opportunity to get feed-

ack from a broader public with varying degree of expertise onechnological issues. Our target was to have a large-scale event, inerms of deployment and size of audience, in real-life conditions.n such an environment, evaluation regarding satisfaction/fun, as

1 Much like the “Magnetic Poetry” kits.

s and Software 84 (2011) 1989–2004 1999

well as the overall system performance on a technical and non-technical level, would be more realistic and accurate. The followingfive months we extended our work, reworked two already show-cased installations (Tug of War, Chromatize It!) and implementedtwo additional ones (Chromatize Images, Magnetize Words). Thelog contained in this section is also meant to serve as an index ofpractical issues surrounding the setup and operation of large-scaledeployments, in the context of a public exhibition.

Day One – Monday. After developing, testing and debugging forfive months, we had only one and a half day to setup our showcase.Seven PCs, 60 sensor nodes and lots of cables needed to be in placeand work as expected. However, the setup was completed only onehour before the opening of the exhibition. As this was the first timefor our team to setup an installation of this scale, there was a signif-icant deviation on our time estimates. During that single hour, wehad to perform an overall test of the installations. Visitors wouldtake a device by entering the interaction area and move throughthe installation carrying this single device. Everything seemed tobe ready.

During this one-hour test a major problem was revealed: it wasnot possible to move through the area and interact with all instal-lations carrying a single device. The protocol deciding which gameshould be executed, based on the received broadcast messages ofeach game-related Station, was not working properly. This was dueto the high transmission power of the devices and the nature ofsignal propagation in indoor environments. Due to reflections, etc.,most stations received the majority of events, continuously enter-ing a negotiations phase with the users’ devices and thus quicklysaturating the medium. Additionally, the small beacon interval wehad set meant that a lot of transmissions were taking place, fur-ther worsening this particular situation. We quickly switched to“plan B”, disabling this specific feature. That meant that each gamewould have a number of dedicated devices and some extra laborfor us reflashing the sensor nodes. However, at 19:00 everythingseemed ready for the opening of the exhibition. As proved later,there was still heavy interference between the games because ofthe short distances between game Stations.

During the first day, visitors came and played from 19:20 until22:30, with a total of 87,157 recorder game-related Events. TheEvents received from each station, with respect to each installation,are presented in Table 2. An issue evident by simply observing thetable, is that 5% of events were received from stations that were notrelated with the game described on the Event. For instance, whenvisitors were playing Chromatize Images their device was incor-rectly connected to a Tug of War station S1. As a result, properlygenerated gestures and generated Events had no visual feedback

S2 3018 0 0 0S3 2669 24,699 81 9S4 113 11 24,578 29S5 405 0 0 7336S6 165 3 32 5899S7 830 16 11 9332S8 0 0 0 1S9 0 0 0 22

2000 I. Chatzigiannakis et al. / The Journal of Systems and Software 84 (2011) 1989–2004

gDffs

Iebt

ctcsittr(2Edcso

dFwbSfptwdtofTa

cliteu

Table 3Events received from each station separated by game.

BaseStation Games

TOW CI CImage MW

S1 29,548 0 0 0S2 39,939 0 0 0S3 0 503 0 0S4 0 0 2819 0S5 0 0 0 82S6 0 0 0 71S7 0 0 0 71S8 0 0 0 67S9 0 0 0 11

Fig. 14. Overall event statistics for the 1st day.

enerated when a player’s device connects to a Station, (ii)isinit/Stop: events generated when a player’s device disconnects

rom a station, (iii) Gestures: events generated when a player per-orms a gesture and (iv) Errors: events received from unrelatedtations.

The fact illustrated in Fig. 14 is that 85% of the events werenit/Start and Disinit/Stop, 8% were error events and only 7% of thevents generated from players gestures. Error events were causedy the short distances between the Stations; due to the layout ofhe venue we could not place them in greater distances.

The large number of Init/Start and Disinit/Stop events wereaused for two reasons. The first one is the short distances betweenhe Stations: visitors’ devices were constantly connecting and dis-onnecting on several Stations; not only to the Stations that wereupposed to be registered for each game. E.g., someone was play-ng Chromatize Images but the device she carried was connectingo stations S1, S3, S4. As a result, each disconnection and connec-ion to another Station generated a Disinit Event and a Init Event,espectively. The second reason is the topology discovery protocolsee Echo Protocol, Akribopoulos et al., 2009; Chatzigiannakis et al.,010b). During the first day, we have enabled the operation of thecho Protocol for real time response (i.e., 500 ms) along with theistinction between uni-directional and bi-directional links. Thesehoices, combined with the large number of participants (over 50imultaneously), saturated the wireless medium causing continu-us misreported connect/disconnect events.

In order to resolve these issues and be prepared for the seconday of the exhibition, we proceeded to perform a set of changes.irst of all, we set each game to its own radio channel. In thisay, the generation of Error events was dealt with successfully,

ecause the devices of one game could not communicate with thetations of another game. Because of the fact that communicationrequency is essential for the rightful operation of the localizationrotocol, we chose to use the default 802.15.4 channel on “Magne-ize Words”, as it offers good granularity on RSSI values. Moreover,e enabled a “light” version of the neighbor discovery protocol byisabling the bidirectional neighbor recognition and increasing theime response of the protocol (5000 ms). The mobility of the playersn the interactive installations was limited and there was no needor immediate response to any changes regarding players’ position.hese changes aimed to reduce the Init/Start and Disinit/Stop Eventsnd decrease the network load.

Day Two – Tuesday. In the second day of the exhibition, visitorsame from 19:26 until 22:23. As stated above, the devices’ wire-ess channel were set specifically for exactly one installation. So,

nstead of distributing them from a single stand upon entrance tohe exhibition area, we had a set of switched on devices in front ofach installation for visitors to use – i.e., the device could be notsed on another one. All of the nodes in the deployment area were

Fig. 15. Overall event statistics for the 2nd day (logarithmic scale).

in continuous use throughout the exhibition, with a backup of afew nodes in “standby” in case of the nodes’ batteries depletion.Most of the nodes were in range of each other due to the indoorsdeployment area we chose. There were 73,111 events generatedand participants seemed to be enjoying themselves more than theprevious day. The events received from each station separated bygame are illustrated in Table 3. An overall improvement in com-parison to the first day is obvious. There are no error events, due tooperation on different radio channels on each game.

Fig. 15 depicts a breakdown of the received events per game.There are striking differences when compared to the first day. Apartfrom the fact that there are no error events, a different distribu-tion of the events per type is observed. First of all, the Init/Start,Disinit/Stop events were reduced at a great scale due to the changesin the Echo Protocol. Moreover, a great increase in the gesture eventsper game is observed, while the operation of the overall system wasimproved. There were no malfunctions, therefore no delays duringthe gameplay resulting in a significant increase of the performedgestures.

Nevertheless, there were complaints about the difficulty in per-forming gestures with the SPOT devices, same as in day one. Thegesture recognition algorithm used is based on the 3-axis relativeacceleration input from the device’s accelerometer. If the rela-tive acceleration is smaller than a threshold, then the gesture isdismissed. In order to ease the gestures in general, we decide todecrease this threshold, making them “easier”. In addition to thatchange, we unified the results of gestures in “Chromatize Images”and “Chromatize It!” installation. Before that, visitors were sup-posed to perform only one of the six gestures in order to “throw”colors, making the gestures somehow difficult to visitor withoutprevious experience.

Day Three – Wednesday. On the last day, about 250 visitorscame from 19 : 40 until 22 : 50. A total of 75,304 Events wererecorded, reported in Table 4.

There was a small increase on gesture events reaching 3% oneach game, due to the changes in gesture recognition and report.The Figure with the overall Event statistics is similar to the figure ofthe 2nd day (Fig. 15) therefore is not presented. At last, everything

I. Chatzigiannakis et al. / The Journal of System

Table 4Events received from each station separated by game.

BaseStation Games

TOW CI CImage MW

S1 30,434 0 0 0S2 41,137 0 0 0S3 0 518 0 0S4 0 0 2904 0S5 0 0 0 84S6 0 0 0 73S7 0 0 0 73

ws45

FQ

S8 0 0 0 69S9 0 0 0 12

as working the way it was meant. The smooth operation of theystem was verified for a second consecutive day. Overall, around50 visitors participated in this three-day exhibition. On average,0 visitors were participating concurrently and specifically on the

ig. 16. Eventually, is the “Fun in Numbers” platform overall fun? Q1. Are these Interacti3. Is the Tug of War game overall fun? Q4. Is the Chromatize Images overall fun? Q5. Is t

s and Software 84 (2011) 1989–2004 2001

“Tug of War” installation over 20 players participated concurrentlywithout any issues.

8. User evaluation results

After interacting with the installations, visitors were asked tofill in questionnaires regarding their overall experience and systemperformance, as well as specific details such as the response of thedevices used, etc. In total, 136 of the participants (approx. 1/3 of allvisitors) have filled in a questionnaire.

Visitors’ age ranged from 5 to 70 years old, the majority ofwhich (i.e., 70%) was between 20 and 34 years old. We had slightlymore male visitors than female ones (i.e., 57–43%). Almost 1/3 ofthe participants were students, 12% were teachers and about 10%

computer engineers. The profession of the rest of the visitors var-ied including artists, psychiatrists, economists, lawyers, electricalengineers, merchants. None of them had any sort of previous train-ing on how to use the device. In contrast to our previous attempts

ve Installations overall fun? Q2. Is using gestures more fun than pushing buttons?he Chromatize It! game overall fun? Q6. Is the Magnetize Words game overall fun?

2 System

(taaf(c

aQaolwts

Fy

002 I. Chatzigiannakis et al. / The Journal of

Akribopoulos et al., 2009; Chatzigiannakis et al., 2010b), this timehe audience was largely unbiased. It’s worth mentioning thatbout 80% of the visitors claimed that they had never seen suchset of interactive installations. For each question, guests chose

rom a scale from 1 to 5 indicating Strongly Disagree (1), Disagree2), Neutral (3), Agree (4), Strongly Agree (5). The data extracted arelearly depicting the impact of the changes made after each day.

The first group of charts illustrates the opinion of the guestsbout each installation as well as the overall experience (Fig. 16,1–Q6). During the first day, the majority of the visitors (63%)greed or strongly agreed that the interactive installation wereverall fun (Fig. 16, Q1), even though there was a number of prob-

ems regarding the communication of the devices. After we dealed

ith the communication issues and improved the gesture recogni-ion, the percentage of satisfied visitors was increased; during theecond day 73% agreed or strongly agreed that the installations are

ig. 17. Questions about the proper operation of our platform. Q1. Did the Interactive Insou think the device responds well to your movements? Q4. Would adding a screen bene

s and Software 84 (2011) 1989–2004

overall fun while on Day 3 this percentage grew further reaching89%.

Visitors responded well to the use of gestures as a means ofinteracting. Despite the malfunctions of the applications duringfirst day, 70% preferred using gestures instead of pushing buttons.The percentage soared 84% and 97% on Day 2 and 3, respectively(Fig. 16, Q2).

A thin majority of 50% agreed that Tug Of War was overall funon Day 1, with this mixed result most probably due to its partialoperation during that day. When proper function of the installationwas restored (Day 2 and 3), the vast majority of 88% strongly agreedthat Tug of War was fun to play.

“Chromatize Images” and “Chromatize It!” had their enthusi-asts from the first day with 55% and 40% agreeing that the “funfactor” of these two was high, or very high (Fig. 16, Q4 and Q5).They were also the two installations least affected by the commu-

tallations operate well? Q2. Is the device used on the exhibition easy to use? Q3. Dofit the user interface? Q5. Do you think vibration in the device would be useful?

System

nfnotoI

afit(t

iistawtttc(3sr

owumts

vwdatv

9

tdsifasp

ehawtoo

w

I. Chatzigiannakis et al. / The Journal of

ication problems during the first day. Both were relatively isolatedrom the rest of the installations, they relied less on radio commu-ication – in comparison to Magnetize Words – and the numberf participants was smaller that in “Tug Of War”. When the otherwo installations (“Tug of War” and “Magnetize Words”) started toperate without any problems, “Chromatize it!” and “Chromatizemages” lost this advantage.

The installation of “Magnetize Words” had the lowest fun factorccording to the visitors (Fig. 16, Q6). During the first day, only 30%ound the installation fun. The corrections on communication andmprovements on localization are not reflected on the opinion ofhe guests. The rating of Magnetize Words remained in low levels45–50%) most possible due to the limited level of interaction (i.e.,he lack of gestures) and the abstract nature of the installation.

The second group of charts (Fig. 17, Q1–Q5) illustrates the opin-on of the audience regarding functional issues. When asked if thenstallations operate well (Fig. 17, Q1), on Day 1 40% agreed ortrongly agreed indicating the excitement of the audience givenhe major problem that arose during that day. On the second day,fter resolving all communication malfunctions, the majority (70%)as very satisfied from the operation of the installation. During

he third day, this percentage exceeded 88% after the modifica-ions regarding gestures were applied. Nevertheless, the effect ofhe changes we made after Day 2, simplifying gesture recognition,ombined with those on the communication layer, are distinct onFig. 17, Q3); 78% of the visitors agree or strongly agree that on Day

the devices responded well to user input. That percentage wasignificantly lower during the first and second day (10% and 44%,espectively).

Regarding the enabling devices, the majority of the visitors (78%n Day 2 and 83% on Day 3) agreed or strongly agreed that the deviceas easy to use (Fig. 17, Q3). Since SPOTs were not designed to betilized in interactive installations, this leaves room for improve-ent. Despite that fact, young kids (even toddlers, Fig. 5) managed

o play without significant problems. This is also related to the smallize and weight of the device.

When asked about additional feedback means, 53% of theisitors answered that adding a screen to the carrying deviceould benefit the user interface (Fig. 17, Q4). This percentage wasecreased during the following days (43% and 34%) when the oper-tion was restored. An interesting point is also the fact that duringhe three-day more than 70% agreed or strongly agreed that usingibration would benefit the interaction (Fig. 17, Q5).

. Lessons learned – conclusions

After the discussion about our experiences and the user evalua-ion results from this 3-day event, we now clearly understand thateploying multiple and multiplayer interactive installations in theame physical location can be very challenging; careful plannings needed in order to implement efficient systems. Utilizing resultsrom the WSN community is a way to deal with such situations andpplication requirements. The fact that our implementation clearlyurpasses other previous relevant results in terms of number oflayers, is the best argument supporting such an opinion.

There is a certain trade-off when trying to create a pervasivenvironment and deal with scalability at the same time. On the oneand, a completely ad hoc approach seems to scale and behave incceptable levels up to around 20 players. On the other hand, if weish to involve large groups one should adopt multilayer architec-

ures, which introduce additional complexity in deployment and

peration. Our approach was to keep this as simple as possible. It isbvious from our user evaluation results, that it was well worth it.

Regarding the user interface, providing a unified experienceith multiple installations using multiple user inputs received a

s and Software 84 (2011) 1989–2004 2003

warm welcome, even enthusiastic, from a large sample of visitors.People especially welcomed the idea of having large player groups(i.e., up to 20) at the same time. Our experience was that especiallyin competitive games, the large number of player seemed to rein-force the whole concept, while certain players tended to revisit,e.g., “Tug of War” for additional gameplay rounds.

Moreover, well-known human perception limits are more orless valid in the same sense here, although immediate visual feed-back was not required in most cases. In practical terms, settingthresholds below 500 milliseconds, e.g., when detecting networkneighborhood changes, was fast enough to create an immersiveuser experience. However, going over such limits, which would benecessary if we used other networking technologies like Bluetoothwould have devastating results. Also, the large number of playersneeded for creating a compelling experience is served well by thehardware platforms we chose, apart from the efficiency of our soft-ware implementation. Thus, currently technologies like 802.15.4transceivers seem the right way to go when implementing suchconcepts.

An interesting additional point extracted from visitors’ com-ments in the questionnaires, pointing to future work, was thefollowing: about 70% of them saw educational extensions to theshowcased installations. This fact, up to a certain degree, wasbacked up by the fact that even 2-year old children quickly adaptedto the use of the provided devices and were able to interact with theinstallations. Thus, our future plans include, among others, informaleducation applications based on our current work.

Acknowledgements

This work has been partially supported by the European Unionunder contract numbers ICT-215270 (FRONTS). We would like tothank the Lithografion Theater, for providing us with the stagefor experimentation and the sponsors of the three day event:“TO DONTI” publications and Parparoussis winery. We would alsolike to thank A. Aggelopoulos, T. Asproudis, E. Chita, G. Fotinou,A. Korovesis, V. Kappa, C.Koninis, A. Makrigianni, M. Petraki, E.Theodoridis, E. Thermos, A. Tsoumani, E. Tsota for volunteering tohelp with the exhibition.

Appendix B. Supplementary Data

References

Akribopoulos, O., Logaras, M., Vasilakis, N., Kokkinos, P., Mylonas, G., Chatzi-giannakis, I., Spirakis, P., 2009. Developing multiplayer pervasive gamesand networked interactive installations using ad hoc mobile sensor nets.In: ACE’09: Proceedings of the International Conference on Advancesin Computer Entertainment Technology, ACM, New York, NY, USA,doi:http://doi.acm.org/10.1145/1690388.1690418, pp. 174–181.

Alix Gateway, http://www.pcengines.ch/alix1d.htm.Ballagas, R., Kuntze, A., Walz, S.P., 2008. Gaming tourism: lessons from evaluat-

ing rexplorer, a pervasive game for tourists. In: 6th International Conference,Pervasive 2008 Sydney, Australia, pp. 244–262.

Barrenetxea, G., Ingelrest, F., Schaefer, G., Vetterli, M., 2008. The hitchhiker’s guideto successful wireless sensor network deployments. In: SenSys’08: Proceedingsof the 6th ACM Conference on Embedded Network Sensor Systems, ACM, NewYork, NY, USA, doi:http://doi.acm.org/10.1145/1460412.1460418, pp. 43–56.

Battle Tag, a high-tech laser battle game, http://battle-tag.us.ubi.com/.Chatzigiannakis, I., Mylonas, G., Akribopoulos, O., Logaras, M., Kokkinos, P.,

Spirakis, P., 2010a. Brief announcement: Fun in numbers – a plat-form for sensor-based multiplayer pervasive games. In: 22nd ACM Sym-posium on Parallelism in Algorithms and Architectures, SPAA 2010,http://www.cs.jhu.edu/spaa/2010/index.html.

Chatzigiannakis, I., Mylonas, G., Akribopoulos, O., Logaras, M., Kokkinos, P.C., Spi-rakis, P.G., 2010b. The “hot potato” case: challenges in multiplayer pervasive

games based on ad hoc mobile sensor networks and the experimental evaluationof a prototype game, CoRR abs/1002.1099.

Chatzigiannakis, I., Mylonas, G., Vitaletti, A., 2011a. Urban pervasive applications:challenges scenarios and case studies. Computer Science Review 5 (1), 103–118,doi:10.1016/j.cosrev.2010.09.003.

2 System

C

E

H

II

K

K

K

MM

PR

RS

SS

SUW

s

researcher with CTI, Greece. She has also been with PhilipsDesign, the Netherlands, (1995–2000) as a senior interac-tion designer/project manager. Irene has over 15 years ofexperience in design and research, focusing in AmI sys-tems’ interaction.

004 I. Chatzigiannakis et al. / The Journal of

heok, A.D., Fong, S.W., Goh, K.H., Yang, X., Liu, W., Farzbiz, F., 2003. Humanpacman: a sensing-based mobile entertainment system with ubiquitous com-puting and tangible interaction. In: NetGames’03: Proceedings of the 2ndworkshop on Network and system support for games, ACM, New York, NY, USA,doi:http://doi.acm.org/10.1145/963900.963911, pp. 106–117.

conomou, D., Gavalas, D., Kenteris, M., Tsekouras, G.E., 2008. Cultural applicationsfor mobile devices: issues and requirements for authoring tools and devel-opment platforms. Mobile Computing and Communications Review 12 (3),18–33.

ay, S., Harle, R., 2009. Bluetooth tracking without discoverability. In: Choud-hury, T., Quigley, A.J., Strang, T., Suginuma, K. (Eds.), LoCA, Vol. 5561 ofLecture Notes in Computer Science. Springer, pp. 120–137, http://dblp.uni-trier.de/db/conf/loca/loca2009.html#HayH09.

mielinski, T., Korth, H.F., 1996. Mobile Computing. Kluwer Academic Publishers.ntegrated Project on Pervasive Gaming website, http://www.pervasive-

gaming.org/.eefe, D., Acevedo, D., Miles, J., Drury, F., Swartz, S., Laidlaw, D.H., 2008. Scien-

tific sketching for collaborative VR visualization design. IEEE Transactions onVisualization and Computer Graphics 14 (4), 835–847.

inect for Windows SDK, http://research.microsoft.com/en-us/um/redmond/projects/kinectsdk/.

night, H., Satkin, S., Ramakrishna, V., Divvala, S., 2011. A saavy robot standupcomic: online learning through audience tracking. In: Tangible, Embedded andEmbodied Interaction (TEI).

inim audio library, http://code.compartmental.net/tools/minim/.isund, G., Holone, H., Karlsen, J., Tolsby, H., 2009. Chase and catch – sim-

ple as that? Old-fashioned fun of traditional playground games revitalizedwith location-aware mobile phones. In: ACE’09: Proceedings of the Inter-national Conference on Advances in Computer Entertainment Technology,ACM, New York, NY, USA, doi:http://doi.acm.org/10.1145/1690388.1690402, pp.73–80.

rocessing, an open source programming language, http://processing.org/.eeves, B., Read, J.L., 2009. Total Engagement: Using Games and Virtual Worlds to

Change the Way People Work and Businesses Compete. Harvard Business SchoolPress.

elational Persistence for Java and.NET, http://www.hibernate.org/.avvides, A., Srivastava, M., Girod, L., Estrin, D., 2004. Localization in Sen-

sor Networks. Kluwer Academic Publishers, Norwell MA, USA, pp. 327-349,http://portal.acm.org/citation.cfm?id=1013825.1013841.

enseable City Lab, http://senseable.mit.edu/.ong, W.-Z., Huang, R., Xu, M., Ma, A., Shirazi, B., LaHusen, R., 2009. Air-

dropped sensor network for real-time high-fidelity volcano monitoring.In: Proceedings of the 7th international conference on Mobile sys-tems, applications, and services, MobiSys ‘09, ACM, New York, NY,USA, pp. 305–318, doi:http://doi.acm.org/10.1145/1555816.1555847,http://doi.acm.org/10.1145/1555816.1.

un SPOT website, http://www.sunspotworld.com/.CLA Urban Sense, http://urban.cens.ucla.edu/.ii at Nintendo, http://www.nintendo.com/wii.

Ioannis Chatzigiannakis obtained his PhD from theDepartment of Computer Engineering & Informatics ofthe University of Patras in 2003. He is currently AdjunctFaculty at the Computer Engineering & InformaticsDepartment of the University of Patras (since October2005). He is the Director of the Research Unit 1 of Com-puter Technology Institute and Press (since July 2007). Hehas coauthored over 70 scientific publications. His mainresearch interests include distributed and mobile comput-

ing, wireless sensor networks, algorithm engineering andsoftware systems. He has served as a consultant to majorGreek computing industries. He is the Secretary of theEuropean Association for Theoretical Computer Science

ince July 2008.

s and Software 84 (2011) 1989–2004

Georgios Mylonas received his PhD from the Departmentof Computer Engineering and Informatics at the Univer-sity of Patras, Greece, in December 2008. He is currentlyworking as a researcher at the Computer Technology Insti-tute & Press, Patras, Greece. His research interests lie inthe areas of wireless sensor networks, distributed sys-tems and games. He has been involved in several researchprojects, funded by the European Union and the GreekGovernment, which focus on the algorithmic and softwareissues related to wireless sensor networks.

Panagiotis Kokkinos received his Ph.D. in 2010 fromComputer Engineering and Informatics Department(CEID) of University of Patras, Greece, in the field of OpticalGrid Networks, focusing on task scheduling and data rout-ing algorithms. He also holds a M.Sc. degree (2006) and aDiploma (2003) from the same department. His currentresearch activities are in the areas of distributed comput-ing and middleware.

Orestis Akribopoulos is a MSc student of the ComputerEngineering and Informatics Department of the Universityof Patras, Greece. He received his Diploma in ComputerEngineering and Informatics (2009) and he is working asa researcher at the Research Academic Computer Technol-ogy Institute, Patras since 2009. His research interests liein the areas of wireless sensor networks and distributedsystems and pervasive games.

Marios Logaras received his Diploma in Computer Engi-neering and Informatics at the University of Patras, Greece(2010). He is currently a MSc Student on Computer Sci-ence at the same department. He works as a researcherat Research Unit 1 of the Computer Technology Insti-tute since 2008. His research interests lie in the area ofwireless sensor networks and real platform deployment,distributed systems and pervasive gaming.

Irene Mavrommati (PhD-UAegean: Interaction Design,MA-RCA: Multimedia, MA-UCE: Graphic design) is a Lec-turer at the Hellenic Open University, and cooperating