Designing Asymmetrical Collaborative Gameplay

for Heterogeneous Device Ecosystems

A Thesis

Submitted to the Faculty

of

Drexel University

by

Robert Sean Speck

in partial fulfillment of the

requirements for the degree

of

Master of Digital Media

June 2013

© Copyright 2013 Robert S. Speck. All Rights Reserved.

ii

DEDICATIONS

This thesis is dedicated to my family: my mom, Amy; my dad, Michael; and my sister,

Holly, as well as the rest of my immediate relatives. My family has always been there to encourage me in my most difficult endeavors, both academic and otherwise. I would also like to dedicate this work to the close friends I have had throughout my life. My family and friends have kept me on course whenever I’ve felt overwhelmed, and humored me all the times I’ve gone on excitedly about new technologies, game ideas, and miscellaneous media-related topics they don’t have any involvement with.

iii

ACKNOWLEDGEMENTS

Thank you to the dedicated members of my thesis committee: Dr. Paul Diefenbach, Jervis

Thompson, and Robert Lloyd. Their unique perspectives and areas of expertise have been invaluable in shaping this thesis into a useful academic contribution to our field. Over many meetings with Paul, he helped me articulate my scattered ideas and gave me detailed and on-point feedback on avenues of research I should pursue. Jervis’ technical skillset helped me past several important roadblocks in my prototype development, and he was always there to caution me against biting off more than I could chew. Rob offered a different perspective outside of academia, and gave a lot of great feedback on my thesis proposal and paper.

I’d like to also extend my thanks to a number of other Digital Media faculty who have mentored me over my graduate career. Thank you to Glen Muschio for introducing me to technical writing and offering extensive assessments on my earlier thesis directions; to Michael Wagner and

Jichen Zhu, who gave helpful critiques each week of thesis class and helped me perfect my “project pitch”; and to all the other Digital Media professors who have offered their advice and feedback.

Thank you to all of my good friends in Digital Media and the graduate program: Girish

Balakrishnan, Nate Lapinski, Glenn Winters, Sonia Havens, Yujie Zhu, Kevin Gross, and Ian

Woskey. Special thanks to Girish and Nate for always keeping me on-track when everything seemed to be going wrong. I hope I’ve been able to reciprocate a fraction of the support that my friends both in and out of the Digital Media program have given me over the last several years.

My classmates have inspired some of my best work, and challenged me to make it even better.

This thesis is the culmination of everything I’ve gained on my own and with the support of my friends and professors.

iv

TABLE OF CONTENTS

LIST OF TABLES ...... vi

LIST OF FIGURES ...... vii

ABSTRACT ...... ix

1. KEY TERMS ...... 1

2. INTRODUCTION & THESIS OVERVIEW ...... 2

3. BACKGROUND INFORMATION ...... 4

3.1. MOBILE GAMES...... 4

3.1.1. MOBILE / HANDHELD PLATFORMS ...... 4

3.1.2. DATA SHARING ...... 10

3.1.3. SOCIAL IMPLICATIONS OF MOBILITY ...... 12

3.1.4. FORM-FACTOR LIMITATIONS ...... 15

3.2. HETEROGENEOUS GAME ECOSYSTEMS ...... 18

3.2.1. CONSOLE-BASED ECOSYSTEMS ...... 18

3.2.2. NETWORK-BASED ECOSYSTEMS ...... 25

3.3. GAME DESIGN FOR HETEROGENEOUS ECOSYSTEMS ...... 28

3.3.1. CROSS-PLATFORM GAME DESIGN ...... 28

3.3.2. CROSS-PLATFORM SHARED EXPERIENCE ...... 32

3.3.3. CROSS-PLATFORM HUMAN FACTORS ...... 34

4. APPROACH ...... 36

4.1. INITIAL EXPERIMENTATION ...... 39

4.1.1. DEVICE CLASSIFICATIONS ...... 39

4.1.2. DEVELOPMENT FRAMEWORKS ...... 41 v

4.1.3. UNITY DESIGN CONSIDERATIONS ...... 43

4.2. HARDWARE CONSTRAINTS ...... 44

4.2.1. PROCESSING POWER ...... 45

4.2.2 RENDERING PERFORMANCE...... 46

4.2.3. FORM FACTOR AND DISPLAY...... 48

4.2.4. CONTROLS ...... 51

4.3. GAME EXPERIENCE ...... 53

4.3.1. PLAYER ROLES ...... 53

4.3.2. GRAPHICAL USER INTERFACE ...... 57

4.3.3. COMMUNITY ...... 59

4.4. NETWORK COMMUNICATION ...... 60

4.4.1. LATE JOIN / EARLY LEAVE ...... 60

4.4.2. CONNECTIVITY OPTIONS ...... 61

4.5. DEVELOPMENT CONSIDERATIONS ...... 63

4.5.1. DEVELOPMENT TOOLS ...... 63

4.5.2. MARKETABILITY ...... 64

4.5.3. EMERGING TECHNOLOGIES ...... 64

5. FUTURE WORK ...... 66

6. CONCLUSION ...... 67

7. LIST OF REFERENCES ...... 69

vi

LIST OF TABLES

Table 1. Mobile gaming device comparisons ...... 5

Table 2. Major gaming consoles and functionalities ...... 19

vii

LIST OF FIGURES

Figure 1. iPad with Retina display example [4] ...... 7

Figure 2. Kindle Fire HD (left) and Nexus 7 (right) [5] ...... 7

Figure 3. Microsoft Surface with Windows 8 RT example [7] ...... 8

Figure 4. Xperia PLAY (left) and PS Vita (right) [10] ...... 9

Figure 5. Nintendo 3DS example [11] ...... 10

Figure 6. Evernote sharing feature example [13] ...... 11

Figure 7. Virtual joystick obscuring game screen [23] ...... 16

Figure 8. Sony Remote Play example [28] ...... 21

Figure 9. Wii U GamePad game extension example [30] ...... 22

Figure 10. Microsoft SmartGlass example [32] ...... 24

Figure 11. OnLive touch interface example [34] ...... 25

Figure 12. GameCenter feature examples [35] ...... 26

Figure 13. Grand Theft Auto III port for Android/iOS [38] ...... 29

Figure 14. Scaleform GFx example from Borderlands 2 [39]...... 31

Figure 15. Adaptative UI demonstrated on Droid Bionic smartphone (left) and iPad (right) ...... 32

Figure 16. Mogi gameplay snapshot [25] ...... 33

Figure 17. Heterogeneous development considerations chart...... 38

Figure 18. Development for different DPI screens...... 40

Figure 19. Adobe AIR prototype featuring network implementation with slowdown...... 42

Figure 20. Mechination demo including hi-poly models and advanced reflections, refractions, etc...... 44

Figure 21. Spawning physics objects networked between devices...... 45 viii

Figure 22. Comparison of rendering statistics, with 6 skinned meshes (left) vs. 2 skinned meshes (right)...... 48

Figure 23. Experiment X gameplay across multiple form factors...... 49

Figure 24. Experiment X perspective and interactions comparisons...... 50

Figure 25. The smartphone (as shown) is able to display only a section of the map view...... 52

Figure 26. Personal computer player role comparisons...... 55

Figure 27. Tablet player role comparisons...... 56

Figure 28. Smartphone player role comparisons...... 57

Figure 29. Letterboxed GUI on certain resolutions...... 59

Figure 30. Nintendo StreetPass demonstration. [42] ...... 60

Figure 31. Super Smash Bros. supports drop-in, drop-out multiplayer in story mode. [44] ...... 61

Figure 32. Photon Cloud network servers. [45] ...... 62

Figure 33. Unity game engine. [46] ...... 63

Figure 34. Leap Motion demonstration. [47] ...... 65

ix

ABSTRACT Designing Asymmetrical Collaborative Gameplay for Heterogeneous Device Ecosystems Robert Sean Speck Paul J. Diefenbach, Ph.D.

Mobile devices have become a major market consideration for developers in recent years, as smartphones and tablets become part of a new technological and social space. However, game experiences on mobile platforms still don’t offer an acceptable level of interconnectivity across diverse ecosystems. This thesis prototypes a compelling multiplayer game experience that works in a heterogeneous environment. It explores the potential of cross-platform development tools to create asymmetrical gameplay between different devices. The end goal of this thesis is to develop a set of techniques and guidelines to be used in designing heterogeneous gaming experiences.

Research will be conducted into existing solutions for cross-platform play, and methods to address the limitations of current cross-platform ecosystems will be explored. In support of this research, a demonstrative multiplayer collaborative gaming experience has been created, with an emphasis on seamless design and user interactions tailored to device features and constraints. This experience seeks to address the impracticality of gaming with friends across mobile platforms. The game uses cloud server connection technology to link users, and examine the role of users and user interaction techniques in a collaborative experience.

x

1

1. KEY TERMS

The following key terms are used throughout this document:

Bluetooth

System for exchanging data wirelessly over short distances.

Ecosystem

A system formed out of interrelated products and services, often offered by a large

parent company.

Geolocation

Real-world geographic positioning data.

Global Positioning System (GPS)

Satellite-based navigation system.

Motility

Each person’s potential to move and to accomplish objectives on the move; this

concept associates opportunity, competence, and capital.

Peer-to-Peer

Multiple computing devices share resources and information without using a

centralized server.

Platform

An ecosystem for delivering games.

Single Sign-On

Once a user has authenticated their account, they can sign in once through any portal

and this information propagates to any supported application. 2

2. INTRODUCTION & THESIS OVERVIEW

Consoles have been a primary platform for video gaming since the inception of the industry. These systems were initially characterized by dependency on television units, but eventually handheld competitors such as the Nintendo Game Boy began to emerge. Mobile systems such as smartphones and tablets have become the predominant market for developers in recent years [1]. For developers mobile devices offer exciting new avenues of exploration in application design. Devices with compact sizes support ease of transportation, and the extended battery life and advanced wireless capabilities of modern technologies allow for diverse use-case scenarios. Always-on data connections and broad wireless coverage promote a connected experience which developers have started to leverage in recent years. Tablet and smartphone devices facilitate and support digital social experiences, predicated on accessible design and the aforementioned connective features [2]. However, game experiences on mobile platforms still don’t offer an acceptable level of interconnectivity across diverse ecosystems.

This thesis prototypes a compelling multiplayer game experience that works in a heterogeneous environment. This thesis explores the potential of cross-platform development tools to create asymmetrical gameplay between different devices, and develops a set of techniques and guidelines to be used in designing heterogeneous gaming experiences. These guidelines will be created based on information drawn from examining existing (and currently emerging) cross-device communication methodologies and the development and implementation of a prototype game. Drawbacks and limitations of existing communication methodologies, which include the issues of closed-ecosystem development and unequal player roles, will be discussed and compared to similar solutions. The benefits of an open approach— 3

an experience not tied to console hardware—will be described. A collection of terms to define emergent development techniques will be delineated.

4

3. BACKGROUND INFORMATION

This thesis incorporates information about mobile hardware and software platforms, particularly related to data sharing and interactive capabilities of standard mobile devices.

The implications of mobility on device usage, motivations behind shared user experiences, and the limitations of mobile platforms as related to game design and networking constraints are discussed. Additionally, the difficulties of communicating across disparate platforms are researched and reviewed. An exploration of existing solutions for cross-platform play is conducted, with critiques of software solutions and the capabilities of various high-profile devices. Informed by research into game development techniques, this thesis then proposes best practices for asymmetrical cross-platform experiences and describes a prototype game that demonstrates these principles.

3.1. MOBILE GAMES

3.1.1. MOBILE / HANDHELD PLATFORMS In seeking to leverage existing mobile devices for cross-platform play, it is necessary to compile data on the most popular mobile platforms available. There are a number of modern devices that fall into the category of “mobile,” many with unique hardware and software. The primary devices to note, based on research results, are the Apple iPad and iPhone, the Google Nexus 7 and Amazon Kindle Fire HD, the Microsoft Surface, the PS Vita and Sony Xperia Play, and the Nintendo 3DS and Wii U GamePad peripheral. An overview of the data is summarized in the table below. 5

Table 1. Mobile gaming device comparisons

Device Name Manufacturer Form Factor Control Options Extras iPad with Apple Tablet (9.7”) Multitouch capacitive Retina Retina touchscreen, display Display accelerometer/gyroscope, offers front and back-facing 2048x1538 cameras resolution iPhone 5 Apple Smartphone Multitouch capacitive N/A touchscreen, accelerometer/gyroscope, front and back-facing cameras Nexus 7 ASUS / Tablet (7”) Multitouch capacitive N/A Google touchscreen, accelerometer/gyroscope, front-facing camera, NFC Kindle Fire Amazon Tablet (7” Multitouch capacitive N/A HD and 8.9”) touchscreen, accelerometer/gyroscope, front-facing camera Surface with Microsoft Tablet (10.6”) Multitouch capacitive Supports Windows RT touchscreen, wide range accelerometer/gyroscope, of legacy front and back-facing USB devices cameras, mouse + w/ full-sized keyboard support USB 2.0 port. Xperia Sony Smartphone Multitouch capacitive N/A PLAY touchscreen, accelerometer, front and back-facing cameras, physical controls w/ two touch analog joysticks PlayStation Sony Handheld Multitouch capacitive N/A Vita Console touchscreen, accelerometer/gyroscope, front and back-facing cameras, physical controls w/ two analog joysticks, trackpad on back of unit

6

Table 2 (cont’d). Mobile gaming device comparisons

3DS Nintendo Handheld Resistive touchscreen, Two-screen Console accelerometer/gyroscope, device, top front and back-facing screen has cameras, physical special controls w/ analog circle glasses-free pad 3D feature. Wii U Nintendo Controller / Resistive touchscreen, Requires Wii GamePad Tablet (10.2”, accelerometer/gyroscope, U for game screen size front-facing cameras, processing 6.2”) physical controls w/ two analog joysticks, NFC

The Apple iPad was the first consumer tablet to gain popularity, developing a stripped-down version of Apple’s OSX operating system with almost entirely touch-based controls (save for some basic navigation buttons on the device). The iPhone was one of the first and most popular devices in the smartphone category, and also operates entirely with touch controls. These devices use capacitive touchscreen technology, which does not allow pressure sensing but allows for increasing finger tracking accuracy compared to older resistive touch technology. The iPad and iPhone can support up to ten touches, and by touching the screen with multiple fingers at a time users can execute pre-defined touch

“gestures” such as swipes or pinches. iPhones and iPads feature accelerometers and gyroscopes, allowing the device to track its own positioning data and detect the angle at which is being tilted or shaken. iPhones and newer iPads also feature one or more cameras.

The newest iPad also features a new high-resolution display called “retina” which at the time of launch had the highest pixel density of any device on the market [3]. 7

Figure 1. iPad with Retina display example [4]

The Nexus 7 and Kindle Fire HD are two of the most popular Android tablets currently, and share most of the same features as the Apple hardware. Android tablets however have increased support for external peripherals such as game controllers, connected via Bluetooth or directly via USB adapters. The Nexus 7 also supports Near Field

Communication (NFC), which allows devices to communicate with one another wirelessly when in close proximity and can be used to initiate games or other applications [5].

Figure 2. Kindle Fire HD (left) and Nexus 7 (right) [5] 8

The Microsoft Surface tablet shares most of the same features as the iPad. The

Surface emphasizes the ability to connect a keyboard and mouse, which while technically supported on the iPad and on Android are not usually touted as connective features. Two editions of the Surface tablet are offered: one with Windows RT, a modified version of

Windows for mobile devices, and a Surface Pro with the full Windows 8 operating systemin the next several months a version with a full version of the Windows operating system, which allows access to a large amount of existing software that other mobile platforms lack

(especially advanced productivity software and videogames) [6].

Figure 3. Microsoft Surface with Windows 8 RT example [7]

The Xperia PLAY is a modified Android phone from Sony with special access to a

Sony store and integrated physical gaming controls. These controls are more limited than a normal controller or the PS Vita, however, and the Xperia PLAY has largely been ignored by developers [8]. The PS Vita is the successor to Sony’s PlayStation Portable, and combines a 9

multitouch screen with full physical controls (including analog joysticks), as well as a large trackpad on the back of the device which can also receive touch input [9].

Figure 4. Xperia PLAY (left) and PS Vita (right) [10]

The Nintendo 3DS is the successor to Nintendo’s DS system, featuring two screens and physical controls with a special “Circle Pad” analog nub. The bottom screen supports resistive touch input, whereas the top screen is a high-resolution panel capable of producing a glasses-free 3D effect. This 3D effect has been largely unsuccessful due to the eye strain imposed upon players, although it does offer extra depth of field compared to games played on normal displays [11]. The Wii U GamePad peripheral, while not a device in its own right, offers a number of similar capabilities to autonomous handhelds, albeit with processing done remotely on the Wii U system. The GamePad has a resistive touchscreen display, physical controls with two analog joysticks, and a camera. 10

Figure 5. Nintendo 3DS example [11]

3.1.2. DATA SHARING Data sharing is one of the most ubiquitous features across mobile platforms. Pushing data effortlessly between devices enables a wide range of functionalities in applications, and was especially important for implementing the multiplayer game experience prototype for this thesis. Android tablets, in particular those featuring the “Google Experience” branding, tightly integrate social features in the form of various Google services (mail, instant messaging, location awareness and Google+) embedded in the device’s operating system. This default integration makes it simple for users to sync data across devices, removing the need to configure from scratch a tablet device in the same way users traditionally set up new personal computers. Instantaneous access to data, while convenient to the end user, is not the major advantage of such cloud-based service integration. Developers (both first and third-party) can make use of user data—with permission—to facilitate a number of interactions that have become synonymous with the mobile experience. Geolocation data allows applications to automatically tune data based on the user’s physical location; the simplest example being a 11

weather app showing forecasts for the user’s city, and automatically updating itself if the user travels. Connecting the user’s email account allows for the import of a user’s contacts, allowing applications to share information to user’s friends; note-taking applications such as Evernote can offer one-click sharing of a note to any listed contact, or offer users the ability to automatically deliver the note to any indicated email address using this cross-service connectivity [12].

Figure 6. Evernote sharing feature example [13]

Adding to this seamless experience is the ability to store information such as save data and browser bookmarks directly to the user’s Google account, creating an effortless back-up solution. Computer-based services such as Apple’s iCloud and Dropbox (both of which have since been ported to mobile platforms) were created to easily store and transfer user data. These cloud-based services are especially necessary on mobile platforms which usually feature limited flash-memory based storage space. That being said, sharing data between users on mobile platforms still has room for further expansion, particularly in the context of mobile games. 12

Communicating information is crucial in gameplay experiences, particularly in the context of multiplayer games. Collaboration between players is difficult if not impossible to maintain without the ability to push information efficiently between players. While the limitations of touchscreen interaction in particular will be examined later in this paper, the research conducted by Dr. Velez [14], a professor at Rutgers University, demonstrates the difficulties in quickly conducting complex interactions—such as multitasking and inputting text—with small form-factor devices. Additionally, mobile devices can be expected to be used in an extremely diverse set of scenarios, as discussed in the following section. Therefore, techniques for transmitting data between data must take into account not only networking limitations but the capability of the user to transmit information. Sharing information between users and contextual experience are considerations in design lexicon this thesis explores.

3.1.3. SOCIAL IMPLICATIONS OF MOBILITY Mobile devices are significant not only for the mechanical possibilities of sharing data, but also for the sociological impact of ubiquitous computing. Mobile systems have altered our perceptions of both technology and technologically-mediated society. Professor

Bonss and Dr. Kesselring [15] of Bundeswehr University Munich stress that mobility has become “a general principal of modernity.” Mobility has always been a part of society, but only recently has mobility had a positive role to play in shaping structural change in our interactions. Mobility has shifted from “movement” to the “potential for movement,” or

“directionality to non-directionality.” In other words, the capability for movement and simultaneous interconnectedness is redefining social experiences [15]. 13

A discussion of social experiences requires an examination of the link between mobility and the concept of “social capital.” Social capital shifts as the nature of our professional and casual relationships change over time. It is not examinable on an individual basis, but rather as a summation of the social interactions between groups of people. The process of crossing new social lines is termed “social mobility, [which] has three dimensions, namely spatial, temporal, and contextual.” [16]. These dimensions offer a compelling structure to examine the evolution of mobile devices in society.

Mobile devices have altered the spatial mobility of social groups. The original conception of the personal computer was a device confined to a specific area, in much the same way as an appliance or television. This paradigm was altered with the introduction of the laptop, a personal computer specifically designed for transportation. The “personal” aspect of personal computer remained intact, as laptops were still intended primarily for a single user; screens with low horizontal viewing angles, lack of always-on data connectivity and general physical unwieldiness prevent laptops from serving as the focus of a local social experience. Smartphones and tablets, with their compact dimensions, advanced connectivity, and long battery life can easily be passed from person to person and carried into nearly any setting [16].

In terms of temporal mobility, mobile devices present a different use scenario than potentially communal devices such as gaming consoles. Console games generally require a certain level of time commitment, and experiences are crafted to keep the user playing contiguously for as long as possible. In contrast, mobile devices can be used in any situation, allowing for a greatly reduced average allocation of time to mobile experiences.

Additionally, unlike on a personal computer, users of mobile devices are generally locked 14

into one application at a time due to memory and screen size limitations; so while time is spent in short bursts, attention is paid exclusively to one experience at a time (with the exception of viewing notifications, a feature supported by most modern mobile operating systems).

These contextual experiences comprise an integral component of pervasive game design. Hannu Korhonen, et. al [17], working for Nokia’s game research division, define pervasive games as games in which “context information is utilized to modify a game world or it is converted to game elements.” Contextual mobility represents one of the most dramatic evolutions of social mobility in mobile devices. As smartphones and tablets can be transported to nearly any setting, users are faced with a diverse set of contextual scenarios on an unprecedented level. With laptops, developers rarely needed to take into account how their applications could be utilized in a non-productive environment such as an elevator; or taken from the opposite direction, how an application would work with a user out-and-about on city streets far from their home network. Korhonen, et. al [17] notes that social interaction outside of the game may disrupt the player’s in-game experience, or conversely a deeply absorbing game experience might present hazards to the player during a commute.

Based on the results of their research, Korhonen, et. al [17] recommends several guidelines which will be important for the topic of designing shared experiences, which will be examined shortly. Developers must take into account the fact that game sessions will often be fragmented with pervasive games. Additionally, in games that support individual players dropping and returning to the game experience, players were usually driven to resume the experience due to curiosity—although players usually requested the ability to be apprised of important game events via notifications. While players enjoyed contextual integration such as 15

game events tied to the time of day, these events became problematic when conflicting with social obligations such as morning class. As Liu, et. al [18] warns, increases in social mobility create new challenges in accruing social capital between developers and consumers.

Pervasive gameplay must strike a delicate balance to motivate players and create fun experiences, without presenting situations in which players cannot progress due to play context.

3.1.4. FORM-FACTOR LIMITATIONS Games on mobile devices have a number of design restrictions. These restrictions stem not only from the graphical capabilities of the units but also the physical design and accepted input methods. Current popular smartphones and tablets require users to interact primarily via touch, eschewing traditional input methods such as keyboards or joysticks. Touch-based interactions can rapidly scale between simple and overly complex, depending on the context of the application. Touch screens can offer a simple analogue of traditional controls, equating a tap on the screen over a virtual graphic to the action of pressing a hardware button.

Alternatively, users can interact with swipes or more complicated “gestures” (tracing a pattern on the touch screen with one or more fingers) which are then interpreted by the software on the device. While haptic feedback devices such as Tactus Technology’s display prototype [19] exist, and phones such as the Nexus 4 offer vibration on key presses [20], commercial touchscreen technology has not yet advanced to the point of offering users full physical feedback. This presents a key detraction from the user experience [21].

Abstraction from physical controls (and by extension detailed kinetic feedback) forces developers to create new methods of interacting with applications—especially with games, 16

which historically can have very complex interaction requirements. As a result, mobile markets predominantly feature “casual” games, which allow for simpler control schemes [22]. Many successful mobile games feature only a single user interaction. Examples include Angry Birds, in which users interact with a uniform simple swipe; or Canabault, a side-scrolling “runner” game in which the only user interaction is a tap on the screen to jump.

Simplistic control schemes avert the issue of potential user frustration, particularly in relation to not only kinetic feedback but perceived precision of manipulating on-screen elements. Mobile games in action/adventure genres have struggled with the issue of accuracy, often defaulting to virtual imitations of joysticks to allow for issues such as simultaneous character and camera movement control. Because there is no physical presence to the joystick yet it must be manipulated with a certain degree of accuracy to accomplish the player’s ends, virtual joysticks force the user to devote additional visual attention. This additional attention can raise input accuracy, but detracts from the primary focus of the game—the gameplay.

Figure 7. Virtual joystick obscuring game screen [23]

17

The emphasis on connectivity with mobile devices ultimately clashes with the issue of effortless user interaction described above. Current users of mobile devices must contend with connectivity restrictions stemming from closed ecosystems. It is difficult to find mobile games that allow for any capability for cross-platform play, despite the gigantic growth in the mobile market over the past several years—and the most commonly observed use case scenarios.

Müller, et. al [24] notes that current tablet ownership within the United States has grown to unprecedented levels in recent years, rising from 3% to 19% between 2010 and 2011.

Additionally, over 50% of Americans are now smartphone users [1]. From over 700 use case diaries collected from tablet owners, Müller, et. al [24] found that email checking, social networking, and gaming were the three most common uses for tablets. Gameplay occurrences were most likely to be conducted “on the couch, at home, [or] in the car.”

Game projects should seek to maximize the available time commitment of potential users. Licoppe and Inada [25] define the concept of motility as it relates to user mobility. The environment of the player is directly related to the player’s ability to accomplish game objectives. Tailoring the gameplay based on the user’s contextual scenario will allow for a more rewarding experience. However, as a simple anecdotal observance, take the following situation: a device owner is at home, nearby several friends, and would like to share a game experience with them. Each person has access to a device with comparable computing power, though these devices vary in form factor and operating systems (ranging from Android smartphones, to iPads, to Windows-based netbooks). The fragmented nature of portable ecosystems precludes their ability to have a cross-platform play experience, with some exceptions. Certain turn-based games such as Words with Friends are authored across multiple platforms, but contain very limited interactivity. Exceptions are beginning to exist, such as the 18

collaborative action RPG game Dungeon Defenders, which presents a seamless cross-platform play experience. These games however do not vary the experience between devices beyond adjusting control schemes.

3.2. HETEROGENEOUS GAME ECOSYSTEMS A game ecosystem may be a hardware dependency such as Sony’s PSP and PS3 interoperation, or can be a software ecosystem such as Apple’s Game Center or Google Play

Games. As part of this thesis, leading cross-platform gaming console-based ecosystems are examined. Additionally, high-profile mobile and handheld gaming devices are discussed addressing their features and limitations. Finally, techniques for adapting games between multiple computing platforms are presented.

3.2.1. CONSOLE-BASED ECOSYSTEMS Companies have begun to notice the possibilities of game experiences across multiple form factors. Sony, Microsoft, and Nintendo—the three corporate leaders of the gaming industry—have created and demonstrated several techniques for cross-platform gameplay.

However, in most instances, cross-platform gameplay is dependent on a company’s particular ecosystem. OnLive and other cloud-computing companies also offer an interesting alternative for displaying games across many devices. The advantages and limitations of these techniques will be discussed. An overview of the data is summarized in the table below.

19

Table 3. Major gaming consoles and functionalities

Device Name Manufacturer Remote Play Control Options Extras PlayStation 3 Sony Yes; PSP and Hardware Control UI, PS Vita. Game controls w/ stream music streaming on analog and videos local wireless. joystick(s), touchscreen remapping (PS Vita) Wii U Nintendo Yes; GamePad Hardware Asymmetric controller. controls w/ competition Game analog (different game streaming + joysticks, views streamed custom resistive to GamePad) interactions on touchscreen local wireless. Xbox 360 Microsoft Yes; Tablet and Capacitive Control UI, Smartphone touchscreens stream music devices. and videos. Custom Additional interactions on interactions for local wireless. games and other media. OnLive OnLive Yes; Varied Varied; mouse “Spectate MicroConsole (PCs and + keyboard, mode” to view (+ Varied mobile console any game being Hardware) devices). Game controllers, played on the streaming from touch overlays. service. remote servers.

Sony’s approach has been to marry several of their existing gaming platforms. Sony has arguably been experimenting with this technique for some time, with the introduction of

“Remote Play” between PS3 and PlayStation Portable (PSP) devices several years ago.

Remote Play operates similarly to the concept of a “remote desktop” in traditional computing; Sony takes a live stream of the PS3’s output and streams it wirelessly to the display of the PSP (and more recently the PSP’s successor, the PS Vita). By default, Remote 20

Play allows users to control menu functionality of the PS3, and access content such as music, videos, and—most importantly—games [26]. The PS Vita, with its superior control options over the PSP, offers some additional functionality, such as serving as a replacement controller for the PS3. It also offers expanded control options for Remote Play games by mapping missing trigger buttons to the PS Vita’s touchscreen or back trackpad [27].

The functionality to control games, however, had to be included by game developers in order to be accessible. Only two games for the PSP were ever announced with Remote

Play functionality, and it was dropped from both titles. A number of PlayStation Network games, and the library of PlayStation 1 games Sony offers on the PS3 are compatible. All processing is handled locally on the PS3, with the handheld receiving a processed video stream as described. This approach is very similar to the technique of cloud gaming services such as OnLive, which I will discuss shortly. Sony’ s approach appears fundamentally flawed, as the only extended functionality offered in relation to gaming is the ability to push the game from the television screen to the handheld screen; and it is impractical to conduct a

Remote Play session outside of the living room, as the PS3 must be left on continually in a special standby mode. There is no opportunity to create new cross-device experiences with

Sony’s approach.

21

Figure 8. Sony Remote Play example [28]

Nintendo’s Wii U console is entirely predicated on the concept of gameplay between different form factors. In addition to supporting traditional controllers, the Wii U ships with a hybrid controller called the GamePad, featuring a tablet-like form factor, touchscreen, and analog controls. The Wii U offers expanded functionality compared to Sony’s Remote

Play—all Wii U games can be streamed to the GamePad, with Nintendo stressing the feature as a way to play console-quality games in the living room while family members or roommates use the television for something else. The Wii U also offers what is termed

“asymmetric competition,” wherein a player using the GamePad as a controller has a different experience than other local players.

In other words, one gameplay experience happens on the traditional console display

(a television) while an entirely different game view is pushed to the GamePad’s display and controlled autonomously by the player using that controller. Developers are currently brainstorming a number of different uses for this functionality: the latest Madden game for the Wii U uses the GamePad as an external playbook, using the touchscreen as a way to draw 22

out plays for the in-game characters to follow; whereas Luigi’s Ghost Mansion streams a modified version of the game map to a player controlling a “ghost” character with the

GamePad, which gives the “ghost” player access to extra visual elements on the map [29].

The main limitation of the Wii U experience is again linked to the fact that all processing for the extended gameplay is handled on the console. The Wii U ships with only one GamePad, but supports an additional GamePad—at the expense of halving the frames- per-second of games played with two GamePads. Because the devices used in Nintendo’s approach aren’t capable of autonomous performance, the expandability of the platform is severely limited.

Figure 9. Wii U GamePad game extension example [30]

Microsoft has yet another alternate approach with their Xbox 360 ecosystem, dubbed

“SmartGlass.” SmartGlass is an application for smartphones and tablets that allows for similar remote control of a console, and access to games and movies. Unlike Sony and

Nintendo’s approach, however, SmartGlass has been released not only on Windows-based mobile devices, but iOS and Android devices as well. Like Sony’s Remote Play, SmartGlass 23

functionality is available only on limited titles, as developers need to work this functionality into their games.

By offering SmartGlass as a mobile application, Microsoft goes a step further than

Sony in repurposing existing hardware; the trade-off being that SmartGlass-enabled games are now constrained by the limited control schemes of mobile devices, which are presently almost exclusively touch-controlled. Demonstrations of SmartGlass show the capability to

“push” movies viewed on a mobile device to the Xbox 360 (and vice-versa), although this is limited to content purchased through Microsoft’s emerging retail ecosystem. SmartGlass will also display supplementary information about a piece of media while it plays on the 360, and serves as a multitouch remote control for all 360 functionality (movies, music, and Internet browsing).

Integration between SmartGlass and game experiences seems to be entirely up to the developer, similar to the Wii U GamePad’s approach; however Xbox 360 games cannot be streamed to the SmartGlass app, although this may change with the next iteration of the Xbox

[31]. Despite making us of autonomous devices, there are no current demonstrations of functionality that supports adding multiple tablet or smartphone devices to the SmartGlass experience. Additionally, Microsoft’s approach suffers ergonomically, as users attempting to use SmartGlass on their tablets to actively engage with games requires the controller to be placed aside, and then picked up again to resume full control of the primary game experience. Microsoft has not announced any plans to open SmartGlass development to independent developers. This severely limits the potential for interesting new development techniques to emerge.

24

Figure 10. Microsoft SmartGlass example [32]

OnLive (and competing services such as Gaikai) are another area of technology in which explorations in delivering games across multiple platforms and form factors have been conducted. OnLive was originally conceived as a service that allows high-quality PC gaming on older PC hardware, but recently released applications for iOS and Android as well. Like the PS3, OnLive works by compressing video streams rendered from powerful computing hardware and delivering it remotely to devices with the OnLive application installed.

OnLive, however, is optimized to deliver these streams over high-speed wireless connections rather than local wireless connections, and operates several large server farms (clusters of high-end computers) through the United States which host the games and make all gameplay calculations. In addition to playing games, users of the service can also “spectate” on any game currently in progress in the OnLive system, and access a host of social functionalities.

An advantage of OnLive compared to offerings from Microsoft, Sony, or Nintendo is that because games are hosted entirely remotely, there are no space concerns for the end-user, in addition to obviously working on a much wider range of hardware (not only computers 25

and mobile devices, but even some “smart” TVs and set-top boxes). OnLive has also experimented with special touch overlays for certain games for Android and iOS to prevent having to use an external controller, although the implementation is extremely basic at present (equivalent to the virtual buttons and joysticks found on some mobile games).

Additionally, picture quality on OnLive even on good connections is noticeably worse than competitors’ offerings [33]. Due to the nature of the OnLive experience, it is also not possible to play multiplayer games over a local wireless connection, a notable drawback compared to competing offerings.

Figure 11. OnLive touch interface example [34]

3.2.2. NETWORK-BASED ECOSYSTEMS Mobile platforms suffer from an undeveloped network infrastructure, making it a challenge to not only connect to other players but to maintain the connection at a reasonable strength. Unlike consoles such as the Xbox 360 and the PlayStation 3, even the most popular mobile platforms (iOS and Android) are fractured in terms of multiplayer frameworks, with a 26

number of competing services available to developers (to the point that for many developers the best solution is creating their own network framework). Apple offers a unified multiplayer framework with the “Game Center” service. Game Center offers a global ranking system, a matchmaking system based on a list of friends, and the option of local (peer-to-peer) connectivity or connection over the Internet using Apple’s servers [35].

Figure 12. GameCenter feature examples [35]

There are still several concerns with the Game Center framework. Game Center is not cross-platform, blocking developers from crafting experiences across multiple mobile operating systems. Users are also required to make a new account with Game Center, and although this is simple to set up (especially if the user already has an Apple ID) it is still an additional step that users need to take and another set of account credentials to remember.

Game Center is offered as an isolated application from the actual Apple App Store, further segmenting the experience rather than building it into the underlying operating system in the same way, for example, Android integrates Google Mail. 27

Game Center does not offer a way to deal with latency concerns when remotely connecting with other players via Apple’s servers; as a general rule, smartphones and tablets do not allow for Ethernet connectivity, while less-portable devices such as consoles and personal computers can be hardwired to the Internet to reduce latency issues on slower connections. Developers again compensate for this hardware deficiency in the design of their applications, with many popular multiplayer games (such as Words with Friends and Draw

Something) focusing on turn-based functionality. Removing the real-time element from multiplayer eliminates issues of lag, but severely limits the type of experiences that can be created.

The most viable approach to real-time multiplayer is direct peer-to-peer connectivity

(using a normal wireless network or Bluetooth), which Game Center will gracefully default to if users are on the same wireless network. Game Center can connect devices directly when not on the same network, but the developer is then limited to a maximum of four players and must deal with the usual latency issues. The requirement of proximity further alters the design decisions that the developer needs to make. Handheld gaming consoles have for some time offered notifications when the user is in proximity with a friend’s compatible device. Mobile users cannot predictably be assumed to have one global networked account, even on iOS with

Game Center [36].

This issue can be addressed by including multiple networking frameworks in an application, but this solution is clunky, difficult for small developers and potentially confusing to consumers. A possible approach to differentiate and enhance the multiplayer experience is to integrate a universally popular social service, such as Facebook. Facebook doesn’t actually offer the ability to connect users together in the context of gameplay, but it serves an important 28

role for developers as a unified platform for allowing consumers to share their gameplay experiences. Infinity Blade 2, for example, integrates Facebook to offer players the ability to take screenshots of their in-game achievements, and automatically share this data with their friends. In contrast to the disconnect between the App Store and the Game Center application,

Facebook offers “Single Sign-On” (SSO) [37]. Some applications have experimented with using Facebook as a pairing solution, using their own custom server to handle network traffic.

Google has announced a new game networking framework dubbed Google Play

Games, which seems to address a number of the previously-stated issues. Google Play

Games is presented as a cross-platform solution, and integrates Google+ for social networking functionality. At the time of writing this service has not been extensively demonstrated, so it cannot yet be seen how effective Google’s approach will be. [Cite]

3.3. GAME DESIGN FOR HETEROGENEOUS ECOSYSTEMS Designing games for console or networked-based ecosystems must address differences in the connected platforms. This includes both the challenge of designing a game for different form factors and interface elements as well as the human-factors.

3.3.1. CROSS-PLATFORM GAME DESIGN While companies are just beginning to investigate the possibilities of cross-platform and cross-device play, many titles have had separate versions released across a number of different platforms. Gameplay and user interface considerations can be informed by the techniques that developers have used in porting games between multiple platforms and form factors. 29

One of the most common types of “ports” is releasing a completely modified version of a game; for example, releasing a side-scrolling platformer on a mobile platform that shares the name of a major title released on Xbox 360. This technique is not very helpful for creating cross-platform solutions, and is inefficient in terms of development.

Many older console and computer games are directly ported to mobile platforms, with their interfaces and controls completely redone where necessary. This method is much easier to apply to systems such as the PS Vita which share a number of hardware similarities with existing console controllers, but much more difficult when it comes to translating games made with physical controls in mind to touchscreen devices. Often virtual joysticks and buttons are employed which mimic the appearance and to a limited extent the functionality of pre-existing controls, but provide only visual (not tactile) feedback. Additionally, these virtual elements must all be placed on the “front” of the device since they only exist on the screen, which makes it impossible to replicate triggers (commonly found at the top or back of devices).

Figure 13. Grand Theft Auto III port for Android/iOS [38] 30

Games that only require a mouse pointer can be transitioned much more easily across platforms, only losing the “hover” element of functionality. Some of these games actually control better on mobile devices, as it is easier to tap and drag elements directly on a screen rather than approximate these actions with an external pointer.

The more minimalistic the original game design, the more easily it can be ported between different platforms and form factors, as well. As discussed earlier, many games made for iOS and Android have adopted a “one touch” interactivity scheme, where all game functionality can be accomplished with timed taps or drags with a finger on the screen. These games, such as Superbrothers: Swords and Sworcery (available across almost every platform, including PC), typically feature few if any interface elements, reducing the need to create extra assets and set up layout code between multiple devices.

A technique that requires a lot of additional preproduction time is to create an adaptable game from the outset: i.e. a game that automatically reflows the game content and user interface based on the size and resolution of the device that it is running on. Many modern games use a solution known as Scaleform GFx for their user interface elements, which allows integration of Adobe Flash-based interfaces in games. Adobe Flash calculates images using vectors, meaning that each image is mathematically computed and can be redrawn at any scale without losing resolution. Traditional raster-based graphics are resolution-dependent as image data is written pixel-by-pixel. The adaptability of Adobe Flash has allowed for quick conversion of games created within Flash for mobile platforms, with a large amount of Flash games converted for the Android and iOS platforms.

31

Figure 14. Scaleform GFx example from Borderlands 2 [39]

As one of the experiments conducted while creating the initial prototype for the example game that accompanies, a hybrid solution for resizing and reflowing game assets has been explored. By creating assets initially at the maximum expected resolution (in this case

2048 x 1536, the resolution of the retina display on the Apple iPad), these assets can be intelligently resized and repositioned to work across any device with equivalent or lower resolution. Working with pre-rendered bitmap interface assets allows a much greater level of detail than vector illustrations. Downsides to this approach include a larger file size and a lack of legibility when reduced to the smartphone form factor, although this can be mitigated by intelligent smoothing algorithms or swapping in additional assets at key resolution breakpoints (for example, a set of assets for smartphone-spec, tablet-spec, and retina-spec devices), a technique which is commonly used for multiplatform development.

32

Figure 15. Adaptative UI demonstrated on Droid Bionic smartphone (left) and iPad (right)

3.3.2. CROSS-PLATFORM SHARED EXPERIENCE Challenges in mobile development include not only constructing an experience in line with social constraints, but motivating users to participate in the actual experience. Liu. et al

[18] discovered that “active [users] were more driven by intrinsic motivations rather than… extrinsic incentives.” Extrinsic incentives are rewards offered to the user by the game developers, such as in-game perks or prizes. Intrinsic motivations are internalized impetuses—performing an experiment due to a fascination with science, or a desire to help people [40]. In the case of Liu, et. al’s [18] experiment, users were called on to aid other users of an application; and while many users did so only for the provided rewards, it was found that the most prolific participants did so primarily for the intrinsic benefits— helping others for the sake of improving other users’ experience.

Community-based games and applications do currently exist in mobile markets, but the social aspects of these games are predominantly based on extrinsic motivations—high scores, match win percentages, unlocking new items and achievements, etc. In the 33

experiment conducted by Licoppe and Inada [25], two common player types were observed participating in the popular multiplayer mobile game, Mogi: “determined collectors” and

“social players.” While determined collectors participated mainly to collect in-game items and rewards, social players’ main objective was to “meet other players and communicate with them.” A game designed for local multiplayer with extant friends offers an opportunity to leverage not only the social capital that exists in that specific social situation but also introduce collaborative gameplay based solely on intrinsic motivation: aiding friends to succeed in a shared gameplay experience.

Figure 16. Mogi gameplay snapshot [25]

Designing a real-time multiplayer experience introduces additional complexity, both in the game experience and how users interact with both the game and with each other. Beznosyk, et. al [41] asserts that collaboration in multiplayer games increases the popularity of such games, but requires extra motivation in the game experience for players to “interact with each other in an effective manner.” The two broad approaches to collaboration are defined as closely-coupled and loosely-coupled interaction. Closely-coupled experiences allow players to directly influence on another, whereas loosely-coupled interaction provide more autonomous 34

roles for players. Beznosyk, et. al [41] notes that the conditions under which games are played, such as physical proximity and available communication channels between players, can affect the gameplay experience, especially in the case of closely-coupled interactions (due to “high dependency between players”).

Beznosyk, et. al [41] specifically studied gameplay scenarios in which play happens over a distance and with no communication between players. While players did not report any loss of enjoyment of the game experience due to geographical distance from other players, a significant decrease in efficiency was observed when not in geographical proximity to other players. The study also found that closely-coupled games produced higher levels of collaboration than loosely-coupled games, and that higher levels of collaboration were positively linked to player enjoyment. Additionally, any delays or waiting introduced by the necessity of collaborating with other players reduced enjoyment. Finally, the greater the perceived contribution of a player’s partner, the more likely the player was to overlook any other negative factors of the game experience.

3.3.3. CROSS-PLATFORM HUMAN FACTORS Communicating between multiple form factors has additional implications to consider beyond interface design and technological limitations: the issue of role symmetry, or how tasks are divided between users, must be taken into account. An experiment in role symmetry was conducted by Velez, et. al [14] using a variation of Tetris, played across heterogeneous computing platforms (in this case, a computer and a PDA). “An analysis of the solution times found that subjects with mixed platforms worked slower than their homogeneous counter- parts, that is, a person in charge with a PC worked faster if his partner had a PC.” 35

This experiment noted that effective collaboration required “common grounding,” or creating a shared understanding of a task through communication. The larger the observed difference between display sizes and input mechanisms, the less-effectively subjects were able to communicate to accomplish tasks. Additionally, subjects were more likely to become frustrated or impatient with each other. Limiting the authority of individuals with more powerful computing device in an exchange also negatively impacted the quality of collaboration; however, asymmetries in computing had more limited negative impact when roles were designed specifically with the capabilities of each platform in mind. To create a successful game experience across heterogeneous devices, it is necessary to design a game experience with roles properly distributed between players based on their computing device.

36

4. APPROACH This thesis investigates design guidelines for creating cross-platform, asymmetrical multiplayer experiences. The results of the research conducted for this thesis have been demonstrated with the creation of a cross-platform application: Experiment X. Experiment X was designed as a 3rd person, multiplayer platformer game. This game type was selected due to the simplistic gameplay requirements (in terms of character movement and environment animations). The game scenario involved the escape of the title character, offering different player role possibilities in terms of assisting or interfering with Experiment X. Of the existing commercial solutions, the approach this thesis proposes contains elements most in common with Microsoft’s “SmartGlass” technology, which integrates with numerous devices running multiple operating systems. The results of this thesis research and prototyping can be used to describe a foundation for creating cross-platform, asymmetrical multiplayer experiences.

Current research has been conducted into mobile technologies, pervasive computing, and existing and emergent techniques used by large corporations for extending device interactions within their own ecosystems. A number of experiments with different technologies were performed before arriving at the final demonstrative prototype.

We drew from this data a set of design principles that were examined in the creation of Experiment X, which was revised during development based on the development experience, further research, and new information about cross-platform technologies as they continue to mature. We will describe a set of development considerations and guidelines drawn from our research and development efforts, and how these informed Experiment X.

This chapter first examines the experimentation conducted for this thesis. We then review hardware constraints and how these constraints inform game design as exemplified by the 37

prototype. Next, we discuss the components of a heterogeneous game experience, especially the role of the player in the experience. Finally, we review the networking technologies applicable to heterogeneous game design and the development considerations of creating cross-device games. A chart organizing these design issues can be found on the following page.

38

Figure 17. Heterogeneous development considerations chart.

39

4.1. INITIAL EXPERIMENTATION A number of different experiments were explored in the course of determining design principles for heterogeneous game design. This section details these experiments and delineates the conclusions drawn from successes and failure. Topics explored include the use of device classifications to determine hardware capabilities, experiments with different development frameworks to determine the best solution for our experimental prototype, and the cross-platform design considerations of our chosen framework.

4.1.1. DEVICE CLASSIFICATIONS Google offers advice for Android developers as pertains to "supporting multiple screens." [42] Google’s categories were examined for the purposes of determining the direction of research into device classifications. Their parameters of interest include screen size, screen density, orientation, resolution, and density-independent pixel units. Screen sizes,

“measured as the screen’s diagonal,” are grouped into four sizes: small, normal, large, and extra large.

Screen size is a definite consideration for creating interfaces to interact with games, both from a visual and a usability standpoint. As mentioned previously, a number of games apply virtualized representations of joysticks to the screen as an input option. When tested in actual play, this approach has additional drawbacks beyond the ones previously discussed; smaller devices such as smartphones require the user to physically obscure the screen when placing their fingers on the screen for virtual controls. Additionally, heavier devices such as the iPad 3 cannot be comfortably supported with one hand for extended periods of time.

Creating user experiences based on screen size and rendered screen resolution alone produces a poor experience, as this approach does not take into account screen density, or the 40

actual quantity of pixels that make up the screen. In order to create readable experiences across a variety of devices, heterogeneous games must support an array of different pixel densities. The iPad 3’s retina display, as discussed in Section 3.1.1, is an example of a high- density display. Games that do not properly take into account the increased pixel density of the retina screen will be displayed at an incorrect size. Google suggests the use of “density- independent pixels,” which are virtual units used to define graphical user interface layouts in terms of scale and positioning that should work across multiple potential screen densities.

Potential solutions for displaying GUIs across heterogeneous devices will be discussed in our design guidelines.

Figure 18. Development for different DPI screens.

Another parameter Google notes which becomes important for developing for mobile devices is orientation. Due to the increased mobility of tablets and smartphones over traditional personal computers, users can make use of the device in either portrait or landscape orientation. Games should therefore take these orientations into account; 41

implementing support for different orientations can add new control and perspective options to the gaming experience, especially in terms of player roles. These parameters were used as a metric for the Experiment X prototype, including the decision to eschew virtual joysticks for mobile control options. Due to development timeline constraints not all features were addressed (including orientation of the screen and device weight). Some components saw partial implementation, such as pixel density. Pixel density was used as part of determining device classification for the automatic detection featured in Experiment X, but was not taken into account for the purpose of resizing graphical user interface elements.

4.1.2. DEVELOPMENT FRAMEWORKS Originally we investigated Game Center [35] as a solution for heterogeneous development due to its ability to network different iOS devices with real-time, server-based, and turn-based networking However, there are a number of limitations to using Game Center, as discussed in Section 3.2.2. First, it only works between iOS devices—not only is it not cross-platform with Android and other mobile operating systems, but Game Center games also cannot communicate with personal computers, even those running OSX. Second, Game

Center is not available by default in any development environment other than Apple's Xcode development tool; there are plugins written to make use of its functionality in Unity, Flash, etc., but they add additional cost and implementation concerns. Game Center also requires that users have an Apple account and sign into it when playing a game with Game Center integration. Benefits of Game Center, on the other hand, include integration with push notifications for games on iOS. 42

A second solution that was examined was Adobe AIR, which offers cross-platform publishing to Windows, OSX, Android, and iOS. We created a proof-of-concept that helped demonstrate a number of the concepts that made it into the final prototype, both in what was successfully created and what was difficult to implement or failed to work as intended. In the course of implementing this prototype we discovered different techniques for sending information over a wireless network; both "reliable" and "unreliable" techniques for transmitting data over the network. "Unreliable" transmission of data is necessary for real- time updating of positioning data, etc. without an unacceptable amount of lag; however, this prototype did not implement intelligent interpolation (as seen in the final prototype) to visually smooth motions communicated across the network, resulting in visual stuttering.

Figure 19. Adobe AIR prototype featuring network implementation with slowdown.

The primary issue with utilizing Adobe AIR as a development environment for heterogeneous games is a lack of suitability for creating well-performant 3D experiences.

Our prototype implemented Starling 3D, a game framework built on top of Adobe AIR 43

featuring hardware acceleration; even with the performance increases afforded by this framework, the implementation of real-time networking noticeably degraded performance.

We therefore transitioned to Unity Pro, a 3D game engine that also features cross-platform publishing support, which offers more of the functionalities that our design guidelines suggest are necessary for creating heterogeneous experiences.

4.1.3. UNITY DESIGN CONSIDERATIONS In our initial Unity experimentation, we discovered some helpful optimization techniques for cross-platform development. For example, while object scale typically has little impact on rendering on personal computers, it was determined that this was not true on certain mobile platforms where the CPU may present a notable bottleneck in rendering.

Therefore, a heterogeneous design consideration is that the scale of all objects in a scene should be kept at "1" whenever possible. Similarly, Unity’s OnGUI method of graphical user interface overlays has noted performance issues on certain mobile platforms. We therefore implemented a GUI approach involving creating a second camera view and pointing it at user interface elements placed within the actual scene, and then overlaying this camera's view.

While this does create the overhead of processing an additional camera, it eliminates the necessity of continually updating via the built-in OnGUI method.

The initial Unity prototype was constructed using assets from an ongoing external project called Mechination. These assets were eventually dubbed unsuitable and replaced for the final prototype, but this experimentation helped to illustrate areas where optimization was necessary for creating heterogeneous experiences. It is important to design with heterogeneous devices in mind from the outset; the assets were created at a polygon count 44

and with enough skinned meshes (the performance impact of which will be addressed in our design guidelines) to make it infeasible to port them to mobile devices without complete reconstruction. Additionally, due to rendering limitations a number of elements cannot be ported directly to mobile platforms, including particle effects, advanced reflections and refractions, etc. and were omitted from Experiment X to focus on larger design issues.

Figure 20. Mechination demo including hi-poly models and advanced reflections, refractions, etc.

4.2. HARDWARE CONSTRAINTS Player experience is often governed by the hardware platform. This section discusses some factors in game development that are difficult to approximate between devices without actually altering gameplay, including the processing power, rendering performance, form factor, and user interface controls.

45

4.2.1. PROCESSING POWER The performance of a device can affect the number of objects that can be rendered on screen at one time, the intensity of physics calculations that can be achieved, and the sophistication of artificial intelligence agents within the game. A technique that can be implemented in cross-device play to address these limitations is the ability to run calculations on the most powerful device (in terms of hardware capabilities) present in the game scenario, and push the results of these calculations out to other devices over the network. Benefits of this approach include not only performance improvements but also consistency of environmental interactions such as physics-enabled object behavior, which are computed differently each time they are run and would therefore be out-of-sync if run locally on each platform. Applying this technique does produce heavy network load due to the necessity of continually streaming positioning data for every element that needs to be kept in sync; therefore this would not be appropriate for devices connecting over limited data connections, and would likely need a fallback physics implementation or other game design consideration.

Figure 21. Spawning physics objects networked between devices.

46

This can be seen in the prototype game created for this project with a simple moving platform; the animation calculations for the platform are processed on the device designated as the “master” client in the experience, and then the positioning data is pushed to other connected devices. This technique was then applied to the physics-enabled droppable objects, which are spawned as network objects. Physics calculations on these objects are performed locally and then pushed across the network using the same smoothing techniques applied to the streamed positioning data of the player character. Notable frame rate improvements were observed when designating the personal computer as the “master” client versus the smartphone or tablet device (exact frame rate discrepancies varied depending on the resolution of the game on the personal computer). Some example statistics include physics calculations for 20 simple networked objects running at 60 FPS on the personal computer, as opposed to the 15 FPS benchmark achieved when using our test Android tablet for calculations.

4.2.2 RENDERING PERFORMANCE When designing games for a heterogeneous environment, the graphical rendering performance of each platform can vary greatly and must be addressed by the design. At present, mobile devices do not have the graphical capabilities of personal computers. There are several limitations involved in creating assets that work across all devices without causing performance bottlenecks. Technical limitations such as polygon count, shaders and memory allocations for textures, animations and the number of meshes skinned for animation, vary between devices. Assets must either be created for the “lowest common denominator” among devices expected to participate in the game experience (requiring 47

careful planning and optimization for maximum graphical quality), or a number of different assets must be prepared which can be swapped out depending on the detected capabilities of the device. Real-time lighting and shadows can be a major performance issue for low-power devices; this can be mitigated by “baking” light maps, which encodes the data from a light source into the textures of objects within the scene, and baked and real-time lighting effects can be combined depending on the platform.

In addition to rendering optimizations, multiple representations of the game environment can be presented, such as showing a full 3D character on detailed terrain on one platform and a dot on a 2D map on a different platform. For example, an outdated mobile device such as a first-generation iPod Touch (which cannot handle full 3D graphics) could be introduced to a heterogeneous experience by presenting a 2D game view and pushing the character’s location on the X- and Z-axes from more advanced devices. This would allow the iPod Touch player to interact with the game using a technique such as tap-to-move (which will be discussed in one of the following sections).

The Experiment X prototype uses a number of the optimization techniques mentioned in order to present a unified experience across platforms, including occlusion culling, baking of environment lightmaps with soft shadows, static and dynamic batching, and mesh and polycount optimizations. The prototype also implements per-platform optimizations techniques where applicable, such as stripping bytecode, optimizing mesh data to remove unused components, forcing vertex-lit lighting (after baking the lightmaps at high detail), and disabling 24/32-bit depth buffers on iOS and Android. The capability of easily implementing these optimizations appears to be very necessary when choosing a development environment for heterogeneous games. Prior to implementing this optimization, frame rate on Android 48

testing devices (of median average power compared to the current industry standard) was below 15 FPS in any game area with an average number of objects onscreen; and below 6

FPS on Android tablet devices, which rendered more of the environment at a time. Following optimizations, frame rates rose to 30-60 FPS depending on the number and complexity of renderable objects. The most valuable optimizations appeared to be baking lightmaps and reducing the number of skinned meshes—replacing a character with 6 skinned meshes with another character with 2 skinned meshes with similar complexity, polygon count, and overall quality (as seen below) resulted in a frame rate increase of 20-30 FPS.

Figure 22. Comparison of rendering statistics, with 6 skinned meshes (left) vs. 2 skinned meshes (right).

4.2.3. FORM FACTOR AND DISPLAY The form factor and display parameters of devices are important considerations in heterogeneous play. These hardware components are primary factors in constructing player roles. Displays for personal computing devices are generally larger than those of mobile devices due to basic portability needs. Since the introduction of the retina display on the iPad

3, mobile devices have implemented high-resolution screen panels with extremely high dots- per-inch (DPI) ratios. Mobility requirements for smartphones ensure that even the largest 49

devices remain pocket-sized. Tablet and laptop devices therefore typically retain a drastically increased screen size and resolution compared to smartphone devices. These differing form factors, combined with the primary control methods available, produce different appropriate interactions across devices. As an example of leveraging appropriate interactions across varying device form factors, our Experiment X prototype implemented three different player roles in the shared gameplay environment. These player roles and their place in the game design will be discussed in a following section.

Figure 23. Experiment X gameplay across multiple form factors.

In Experiment X, the player on the laptop controls a character from a 3rd person perspective with automatic camera tracking, using standard mouse and keyboard controls.

The camera view can be manually altered by repositioning the mouse, and zoomed in and out with the scroll wheel. The player on the tablet drops obstacles in the path of Experiment X from a top-down perspective using the touchscreen. The tablet player can reposition the camera view by dragging a finger on the screen. The player on the smartphone interacts with 50

Experiment X from a side perspective that automatically tracks with the character’s position in the environment. Environmental set pieces can be triggered with taps on the screen. These interactions were created to leverage the available interfaces on each device, and designed in such a way as to incorporate the research into device classifications discussed previously.

The direct 3rd person control of the computer was chosen due to the presence of physical controls, including a precise input mechanism (the mouse). These interfaces make the personal computer ideal for a role that includes full locomotion and camera manipulation, centered on the player character. In contrast, the touchscreen on tablet and smartphones make these devices well-suited for interaction with the game environment due to the ability to rapidly select multiple points on the screen, as discussed in the following section. The high- density screens of mobile devices ostensibly allow for the display of wide map views. The limited screen size of smartphone devices can make using a broad view problematic, however, depending on the design of the game experience. An environmental view could be displayed on a smartphone device, but the user would need to contend with “fog of war” as only a small subset could be displayed on the screen at a time without legibility issues. This could be a desired limitation on the smartphone player depending on the role of that player in the game experience.

Figure 24. Experiment X perspective and interactions comparisons. 51

4.2.4. CONTROLS In prior research sections the different hardware capabilities of various devices present on the market today were explored. Based on this research and the experimentation component of this thesis, a number of conclusions were presented about the appropriateness of various input devices for different game roles and tasks. However, for a game in a heterogeneous environment, there may be one functional need or objective that has to be available across many form factors and input methods. This presents a great challenge in designing the user interaction as even a simple screen size change can present several obstacles.

As noted in the prior section, while even a small form factor today might support as high a resolution as a larger one, the ability to discern small (even high-resolution) game objects is limited. Furthermore, the ability to accurately select small regions in a touch environment is even more restrictive. Therefore, the game presentation must often adapt to take advantage of the form factor and available hardware control input. As noted in Section

3.1.1, most tablets and smartphones lack hardware controls, with capacitive touchscreens serving as the main means of interaction. On the tablet, multitouch capabilities make it possible to quickly and efficiently select multiple points in the environment with taps and swipes, making the tablet ideal for triggering set-pieces and placing obstacles. The smaller screen size of a smartphone, however, would necessitate a drag gesture to manipulate the camera view before another section of the environment could be accessed (a factor that will be examined in a later section).

52

Figure 25. The smartphone (as shown) is able to display only a section of the map view.

In Experiment X, the common task of 3rd person navigation was selected to highlight these challenges and demonstrate a strategy for addressing them for three different environments, namely the laptop, tablet, and smartphone. On the laptop, the player controls the character from a third-person perspective using standard keyboard controls combined with a floating camera system mapped to the mouse. This method takes advantage of the hardware controls of the personal computer.

Variations of this navigation technique were experimented with on mobile devices during the course of the prototype development, including accelerometer steering and tap-to- move. Tap-to-move was found to be a more efficient way to approximate efficient third- person movement on mobile devices without the necessity of a virtual overlay. In this technique a ray is cast from the position of the player’s finger to the appropriate spot on 3D terrain, at which point the character is automatically interpolated to that position. This functionality could be assigned to an alternative gesture such as a two-finger tap to avoid interfering with other tap-based mechanics such as tap-to-fire. Additionally, tap-to-move 53

could be implemented on a map view on a smartphone device for more complex input paths.

However, while tap-to-move is adequate for 3rd person navigation on a tablet, it was determined to still be less intuitive and dynamic than laptop controls. In a heterogeneous multiplayer environment, this disadvantage could prove to be frustrating, as discussed in

Section 3.3.3. It was therefore decided to implement an alternate player role for the tablet.

4.3. GAME EXPERIENCE As noted previously in Sections 3.1.4, games are designed or repurposed for various hardware configurations in different ways. Yet, many of these do not fully leverage the gameplay experience or hardware itself. This section delineates elements of the user experience necessary to make full use of the potential of heterogeneous design.

4.3.1. PLAYER ROLES As noted in the prior section of research, dividing players into appropriate roles is an important potential approach for constructing a viable heterogeneous play experience. In this instance, a player’s “role” refers to a broad system of interactions that differs noticeably for each player based on their platform, as opposed to the traditional delineation of roles wherein players receive different powers and abilities but retain the same basic methods of interacting with the game experience (in terms of both software and hardware controls, although controls will be discussed in detail later). The alternative to modifying play experiences into unique roles is attempting to implement a system in which each player can accomplish the same interactions using varied inputs (such as replicating a controller’s buttons using a software overlay on a mobile device). The drawbacks of such an approach, described in a previous 54

section, indicate that it should not be a preferred tactic for constructing heterogeneous experiences.

Experiment X implements a basic system of player roles by placing the player in control, support of, or opposition to a humanoid held prisoner in a military facility. Players are divided into designated roles to simplify necessary interactions while still promoting a diverse game experience. The game is envisioned to scale based on the number of players present and the roles that they been assigned in order to maintain consistency in difficulty.

This scalability is envisioned to be implemented by integrating artificial intelligence agents to assume non-present roles, or altering the game parameters based on the roles available.

Different roles involve different interactions with the game world and character, with different combinations of roles enhancing overall game functionality due to the unique advantages and interface considerations of each device. The default demonstration environment involves three players: one utilizing a laptop device, one using a smartphone device, and one using a tablet device (operating systems are irrelevant for the purposes of this demonstration). Once connected, players interact with the game using elements unique to their computing devices, with varying perspectives based on the hardware parameters of the device.

On the computer, the player is assigned a role directly guiding the protagonist from a

3rd person perspective using the mouse and keyboard, as discussed in prior sections. This role is an appropriate use of the personal computer due to both the form factor advantages (in terms of precise control over the camera motion, and a spacious screen to display the game world) and the hardware specifications of the computing device. Direct control of the protagonist in a full 3D environment requires maximum processing and rendering efficiency, 55

which the personal computer’s graphics capabilities are able to provide, as shown in Figure

26 (in the left image). While the personal computer has sufficient screen size to display a top- down map view without the need for excessive scrolling (as seen in the image on the right), the mouse pointer can only be positioned at one place at a time and is thus ill-suited for rapidly interacting with the environment.

Figure 26. Personal computer player role comparisons.

On the tablet, the player is assigned an antagonistic role, interfering with the protagonist by placing obstacles from an overhead perspective using the touchscreen. This role takes advantage of both large screen (as compared to smartphones) and high pixel density of tablet devices; additionally, the top-down perspective requires less detail rendering in the environment, as appropriate for the reduced hardware specifications of tablet devices.

The increased display size and pixel density allows for a broad view of the map, reducing the necessity of dragging the view to reveal additional sections of the environment. As seen in

Figure 27, the ability to rapidly select points at different locations throughout the room 56

makes the top-down perspective (in the left image) more valuable than the side perspective

(in the right image), which is unable to display all components of game areas.

Figure 27. Tablet player role comparisons.

On the smartphone, the player’s role was chosen bearing in mind the limitations of the device in terms of form factor, display, and technical specifications. The smartphone player does not directly control the camera view, which instead tracks with the protagonist’s movements from a side perspective. This allows the smartphone player to focus on one-tap interactions with the environment, as well as reduces the number of objects that need to be rendered at any given point. Because the smartphone player can assist Experiment X through tapping on the environment, the reduced field of view on the smartphone becomes a gameplay consideration that prevents foreknowledge of the level on the part of the smartphone player, as seen in Figure 28 (in the left image). This role removes the need for fine control of the player character from a 3rd person perspective—typically frustrating even when implementing techniques such as tap-to-move, especially in a 3D environment where 57

portions of the environment could be obscured by set pieces (as seen in the right image below). At the same time the smartphone player remains engaged in the experience.

Figure 28. Smartphone player role comparisons.

4.3.2. GRAPHICAL USER INTERFACE As discussed in previous research, interaction should be tailored as much as possible to the strengths and weaknesses of the player’s device in order to reduce potential frustration and maximize players’ capabilities to fulfill their roles in the game experience. Gameplay requirements should be constructed to avoid the necessity of virtual joysticks or other callbacks to physical interfaces that do not translate well to interfaces which lack physical feedback. The user interface cannot be completely abstracted, however. Techniques that this thesis explored for implementing valuable user interfaces in heterogeneous game experiences include vector-based scalable user interfaces, adaptative bitmap-based systems with intelligent smoothing, and automatic swapping of bitmap-based UI elements at pre- designated resolution with assets created at a number of different scales. Each of these approaches offer different benefits and drawbacks. 58

While vector-based user interfaces offer the easiest programmatic scalability combined with visual fidelity, most current development environments (with the exception of

Adobe AIR) require expensive plug-ins and additional preparation work in order to include vector-based UIs. Additionally, it can be difficult to create vector-based UIs that offer the same level of visual complexity as bitmap-based UIs. As investigated earlier in this paper, mathematical scaling and redistribution of interface elements can also be applied to bitmap- based UIs, but this degrades the image quality when significantly resized from the original resolution images were created at. Creating unique UI elements for each resolution presents the best visual front, but presents a potentially-staggering workload for designers across multiple devices, resolutions, and form factors.

Experiment X avoids user interface elements as much as possible. Where necessary, the prototype implements an adaptative UI as this offers the best compromise between functionality and visual fidelity with the lowest time investment (due to limited production time available for creating the final prototype). The NGUI plug-in for the Unity game engine allowed for the creation of bitmap user interface elements which were then automatically resized depending on the detected screen resolution and dimensions of the device the elements are displayed on. There are small legibility concerns with the current prototype due to this implementation, especially blurriness of the graphics due to resizing.

59

Figure 29. Letterboxed GUI on certain resolutions.

4.3.3. COMMUNITY A heterogeneous gaming experience promotes a social experience with minimum inconvenience to users, in much the same way as Nintendo’s “Street Pass” system for the

3DS presents an unobtrusive networked experience [42]. Smartphone and tablet devices present a superior “Street Pass” experience due to the elimination of specialized hardware (a handheld gaming console) in favor of multi-purpose connected devices. Social connectivity, such as achievements or objective updates, can be integrated non-obtrusively following the conclusion of the gameplay experience. While we experimented with various community systems, integration was beyond the scope of this project.

60

Figure 30. Nintendo StreetPass demonstration. [42]

4.4. NETWORK COMMUNICATION

4.4.1. LATE JOIN / EARLY LEAVE As discussed in my prior research, a major consideration for multi-platform play is the mobility of the players. For many multiplayer games, players are allowed to join the game experience after it has been initiated; additionally, large-scale multiplayer experiences do not terminate when a player leaves the experience before the conclusion of the game. In order to present a seamless play experience, games created for heterogeneous devices must account for the possibility of players entering or exiting the game at any point. While a player at a personal computer could be assumed to have some level of stability, a player accessing the game from a smartphone could have a number of environmental factors leading to the early termination of play. Possible solutions include automatically defaulting to artificial intelligence for players when that player is not present, or creating a tiered gameplay experience where players can enter or leave gameplay without disrupting the overarching experience. The Experiment X prototype supports late join and early leave in a limited capacity. Players can join or leave the game experience at any point; however, no 61

fallback exists to assume the role of players that are not present in the experience. When the

“master server” exits the experience, control defaults to the most recently-joined player.

Improvements to the late join / early leave system will be discussed in the “Future Work” section.

Figure 31. Super Smash Bros. supports drop-in, drop-out multiplayer in story mode. [44]

4.4.2. CONNECTIVITY OPTIONS Various connectivity options for mobile devices were discussed in previous research.

For non-real-time heterogeneous experiences, any networking protocol can be implemented without affecting the game experience. For real-time multiplayer, however, players must be matched with the lowest possible latency to avoid desynchronizing the game experience. For independent game developers without access to expansive server systems, peer-to-peer networking (over Bluetooth or WiFi) offers an economical solution with fast data transfer.

Another networking technology, cloud networking, has been popularized by services such as

OnLive but has applications in any multiplayer game experience. 62

The example game created for this project pairs players seamlessly across any wireless connection using cloud server technology. Pairing happens “behind the scenes,” as devices are automatically assigned to a virtual room if it exists upon connection to the cloud, or create a virtual room if one does not already exist. The application creates a seamless experience without requiring the user to register with one or more networking frameworks

(such as Game Center), while maintaining the possibility of integrating social connectivity with Facebook in a post-gameplay scenario. A number of solutions for network connectivity exist and were given consideration for viability, including Unity’s networking support. The

Photon Cloud service was chosen, due to it building on the existing syntax for Unity’s networking with the capability of matching players using cloud technology. It is possible with Photon Cloud to connect any personal computing and/or mobile device together and allow them to communicate in real time.

Figure 32. Photon Cloud network servers. [45]

63

4.5. DEVELOPMENT CONSIDERATIONS

4.5.1. DEVELOPMENT TOOLS Designing heterogeneous game experiences requires additional set-up from developers. Therefore an important consideration for designing these experiences is access to game creation tools that can streamline development. Unity Pro, which was used to create the prototype for this thesis, consolidates time-intensive tasks by offering capabilities such as generic references in code which work across multiple platforms without writing individual cases; additionally, parameters can be set on a per-platform basis to enable different compressions techniques or level-of-detail without writing additional code. Experiment X was designed to be published to the following platforms: web, Windows, OSX, and iOS and

Android (for both smartphone and tablets). Using a development kit that offers one-click publishing to varied platforms drastically cuts down on time taken in development and testing, enabling more efficient workflows.

Figure 33. Unity game engine. [46] 64

4.5.2. MARKETABILITY The current state of game development tools and the evolving skillsets of game designers have made it easier than ever to create heterogeneous game experiences. However, there are still a number of previously-discussed barriers—such as time investment, design considerations, and access to varied hardware—that raise the question of viability. The benefits of cross-platform play should outweigh the costs of development. Heterogeneous game experiences make it as easy as possible to participate in game experiences with friends, defying the “walled garden” nature of traditional gaming ecosystems. Heterogeneous games also offer a unique opportunity to offer multiple player roles within a cohesive setting, with real differentiation in both software and hardware controls.

4.5.3. EMERGING TECHNOLOGIES New technologies are continually being introduced that offer new avenues of interaction across heterogeneous platforms. The design considerations reviewed thus far should be applicable for future technologies. For example, the upcoming Leap Motion device enables hand-tracking controls for personal computing devices. This opens up additional possibilities regarding player roles, interactions, and user interface considerations on the computer; however, these interactions are still informed by the data already collected on gesture-based controls, form factor considerations, and other design factors. Other technologies such as the Oculus Rift, which places the player’s perspective in virtual reality, can be viewed under the same design parameters.

65

Figure 34. Leap Motion demonstration. [47]

66

5. FUTURE WORK

The current demonstrative prototype has room for additional expansion. It is representative of the basic functionalities of an asymmetrical game experience across heterogeneous devices. Improvements could be made to the structure of the experience, especially in regard to usability tweaks for a more cohesive network experience. The late join

/ early leave handling of the prototype should be expanded to compensate for non-present player roles via A.I. or tiered experience design; additionally, functionality to manually designate a “master server” device or intelligently select between present devices based on advanced technical specifications should be implemented. For a commercial game project, the user interface would also need to be expanded to include one of the prior-discussed more complex graphical user interface models. The current prototype implements only tap functionality on the smartphone and tablet devices; support for swipes and other gestures could be added to improve cross-device interactions. While the latest iteration of the prototype does not implement a gyroscope control scheme on mobile, this interaction was implemented and tested in a prior development build, and could serve as a possible alternate control scheme in future design work. The capability to demonstrate additional perspectives on mobile was also tested on a prior development build but was not extensively tested in the prototype.

67

6. CONCLUSION

Several areas of broad gameplay techniques have been examined as part of this thesis.

“Transitory gameplay” can denote an experience that involves a process of transitioning between virtual and physical device-based interactions. This is the experience offered by

Microsoft’s SmartGlass and the Wii U GamePad peripheral, in which the player controls multiple devices in the course of gameplay and must make an intellectual and physical switch between devices as a normal part of the game experience. This thesis primarily examines a collaborative played scenario, wherein different users assume different player roles depending on the device, as demonstrated in the prototype Experiment X. “Synergistic gameplay” is a type of gameplay that Experiment X seeks to offer. Expanding on the concept of asymmetric gameplay described previously, synergistic gameplay explicitly seeks to enhance game experiences by utilizing interactions not possible on a paired hardware device.

For example, the capability of rapidly accessing multiple points on a tablet screen simultaneously as part of a god-mode perspective, an interaction not possible or efficient on a personal computer.

“Mutable gameplay” best describes the overall game experience of envisioned heterogeneous game experiences and Experiment X. Games featuring mutable gameplay are designed for adaptive functionality depending on the interactive potential of the device they are played on. In this case, interactive potential includes elements such as the form factor, resolution, and unique interface elements (such as a pointing device, touchscreen, or joystick). Games with mutable gameplay offer a unique game role depending on the detected device. There are a number of factors that must be considered in order to design mutable 68

heterogeneous experiences, both in terms of game design and external development concerns

(such as game engine support for cross-platform publishing). Based on our research and experimentation, we posit that heterogeneous game design is both possible and valuable in the emerging game industry, even across ecosystems. Successful game experiences should examine, incorporate, and build upon the guidelines of this thesis which demonstrated that asymmetric roles designed around each heterogeneous platform’s unique characteristics represents a powerful multiplayer game model in the ever-expanding diversity of game systems.

69

7. LIST OF REFERENCES

[1] "Smartphone penetration breaks 50% barrier in the U.S.," Gizmag, [Online]. Available: http://www.gizmag.com/us-smartphone-penetration-passes-50-percent/23768/.

[2] G. Gruman, "The iPad's Victory in Defining the Tablet: What It Means," InfoWorld, Jul. 2011. [Online]. Available: http://www.infoworld.com/d/mobile-technology/the-ipads-victory-in-defining-the-tablet-what- it-means-431.

[3] "iPad Specs," Apple, Oct. 2012. [Online]. Available: http://www.apple.com/ipad/specs.

[4] "iPad with Retina Display," Apple, Oct. 2012. [Online]. Available: http://www.apple.com/ipad/overview.

[5] "Nexus 7 vs. Kindle Fire: What a Difference $19 makes," Wired, Oct. 2012. [Online]. Available: http://www.wired.com/gadgetlab/2012/07/nexus-7-will-return-a-profit-for-google-and-asus.

[6] "Surface with Windows RT," Surface, Oct. 2012. [Online]. Available: http://www.microsoft.com/Surface/en-US/surface-with-windows-rt/home.

[7] "Mcrosoft Surface Release Date: Microsoft is Betting Big on its Tablet Release This Fall," BostInno, Oct. 2012. [Online]. Available: http://bostinno.com/2012/10/08/microsoft-surface-release-date-microsoft-is- betting-big-on-its-tablet-release-this-fall-photos/#ss__238928_238846_0__ss.

[8] "Xperia PLAY," Sony Mobile, [Online]. Available: http://www.sonymobile.com/us/products/phones/xperia-play/.

[9] "PlayStation Vita System Features," PlayStation Vita, Oct. 2012. [Online]. Available: http://us.playstation.com/psvita/features/.

[10] "PlayStation Mobile goes live on VIta and selected Android devices," Mobile Orchard, Oct. 2012. [Online]. Available: http://mobileorchard.com/playstation-mobile-goes-live-on-vita-and-selected-android- devices/.

[11] "Nintendo 3DS," Nintendo, Oct. 2012. [Online]. Available: http://www.nintendo.com/3ds.

[12] "Introducing Android 4.0," Android, Jun. 2012. [Online]. Available: http://www.android.com/about/ice- cream-sandwich.

[13] "Sharing Notes in Evernote for Android," Evernote, Oct. 2012. [Online]. Available: https://support.evernote.com/link/portal/16051/16058/Article/2126/Sharing-Notes-in-Evernote-for- Android.

[14] M. Velez, "Who's in Charge Here?," ACM Transactions on Computer-Human Interaction, vol. 11, no. 4, pp. 407-444, Dec. 2004. 70

[15] W. Bonss and S. Kesselring, "Mobility and the Cosmopolitan Perspective," in Workshop at the Reflexive Modernization Research Centre, Munich, 2004.

[16] H. Ali-Hussan, et. al., "Mobile Collaboration: Exploring the Role of Social Capital," Advances in Information Systems, vol. 41, no. 2, pp. 9-24, May 2010.

[17] H. Korhonen, et. al., "Pervasive Mobile Games - a New Mindset for Players and Developers," in Fun and Games 2008, Berlin, 2008.

[18] Y. Liu, et. al., "Drawing on Mobile Crowds Via Social Media. Case UbiAsk: Image Based Social Media Search Across Languages," Multimedia Systems, vol. 18, pp. 53-67, Jun. 2012.

[19] "Tactus Technology unveils touchscreen prototype with appearing and disappearing keys," The Verge, [Online]. Available: http://www.theverge.com/2012/6/5/3064674/tactus-technology-prototype- touchscreen-.

[20] "Google Nexus 4 Review," LaptopMag, [Online]. Available: http://www.laptopmag.com/review/.

[21] T. Fenlon and W. Wilson, "How the iPhone Works," HowStuffWorks, Jun. 2011. [Online]. Available: http://electronics.howstuffworks.com/iphone.htm.

[22] C. Taylor, "'Casual Games' to Fuel Mobile Gaming Market," The Register, Oct. 2006. [Online]. Available: http://www.theregister.co.uk/2006/10/06/casual_games_fuel_mobile_market/.

[23] IGN, "Speedball 2 Evolution iPhone Review," Oct. 2012. [Online]. Available: http://www.ign.com/articles/2011/03/10/speedball-2-evolution-iphone-review.

[24] H. Müller, et. al., "Understanding Tablet Use: A Multi-Method Exploration," in MobileHCI'12, San Francisco, CA, USA, 2012.

[25] C. Inada and Y. Licoppe, "Emergent Uses of a Multiplayer Location-aware Mobile Game: the Interactional Consequences of Mediated Encounters," Mobilities, vol. 1, no. 1, pp. 39-61, Aug. 2006.

[26] "About Remote Play," PlayStation, Oct. 2012. [Online]. Available: http://manuals.playstation.net/document/en/ps3/current/remoteplay/remoteplay.html.

[27] "PS Vita Remote Play is finally here. But how does it work?," GamesRadar, Oct. 2012. [Online]. Available: http://www.gamesradar.com/ps-vita-remote-play/.

[28] "Sony America VP Says PS3-Vita Remote Play Can 'Easily' Deliver What Wii U Offers," GenGAME, [Online]. Available: http://gengame.net/2012/09/sony-america-vp-says-ps3-vita-remote-play-can-easily-.

[29] "Wii U Features," Nintendo, Oct. 2012. [Online]. Available: http://www.nintendo.com/wiiu/features.

[30] "Nintendo's Wii U GamePad Transforms The Tablet, Doubles The Gaming Stakes," Fast Company, Oct. 2012. [Online]. Available: http://www.fastcompany.com/3000097/nintendos-wii-u-gamepad-transforms- tablet-. 71

[31] "Introducing XBox SmartGlass," Xbox, Oct. 2012. [Online]. Available: http://www.xbox.com/en- US/smartglass.

[32] "What is Xbox SmartGlass?," Gizmodo, Oct. 2012. [Online]. Available: http://gizmodo.com/5915553/what-is-xbox-smartglass.

[33] "Cloud Services Let Gadgets Punch above their Weight," MIT Technology Review, Oct. 2012. [Online]. Available: http://www.technologyreview.com/news/421931/cloud-services-let-gadgets-punch-above- their-weight/.

[34] "OnLive Android Playing Darksiders," GeekBeat.TV, Oct. 2012. [Online]. Available: http://geekbeat.tv/onlive-for-android-review-high-end-gaming-for-any-tablet/online-android-playing- darksiders/.

[35] "Game Center," Apple, Jun. 2012. [Online]. Available: http://www.apple.com/game-center.

[36] J. Jordan, "Executive Briefing: Cross Platform Mobile Game Development," Pocket Gamer, [Online]. Available: http://www.pocketgamer.biz/r/PG.Biz/PocketGamer.biz+Reports/feature.asp?c=29670.

[37] "Implementing Single Sign-On (SS0)," Facebook, Jun. 2012. [Online]. Available: http://developers.facebook.com/docs/mobile/ios/build#implementsso.

[38] "Grand Theft Auto III Available On Android and iOS," Click4TechNews, Oct. 2012. [Online]. Available: http://click4technews.blogspot.com/2011/12/grand-theft-auto-iii-available-on.html.

[39] "Scaleform GFX to be bundled with Unreal Engine," Eat3D, Oct. 2012. [Online]. Available: http://eat3d.com/blog/chrisperr/scaleform-gfx-be-bundled-unreal-engine-3.

[40] K. Chard, et. al., "Social Cloud Computing: A Vision for Socially Motivated Resource Sharing," Services Computing, pp. 1-5, 2010.

[41] A. Beznosyk, et. al., "The Influence of Cooperative Game Design Patterns for Remote Play on Player Experience," in APCHI '12, New York, USA, 2012, pp. 11-20.

[42] "Supporting Multiple Screens," Google, [Online]. Available: http://developer.android.com/guide/practices/screens_support.html. [Accessed 2013].

[43] "StreetPass," Nintendo, Jun. 2012. [Online]. Available: http://www.nintendo.com/3ds/features#/8.

[44] S. Rodriguez, "Dairantou Smash Brothers X," 9 March 2008. [Online]. Available: http://www.nintendoworldreport.com/review/15519. [Accessed June 2013].

[45] "Photon Cloud New WorldMap," Exit Games, [Online]. Available: http://blog.exitgames.com/2012/11/photon-cloud-regions-global-low-latency-free-of-charge/photon- cloud-new-worldmap/. [Accessed June 2013]. 72

[46] T. Higgins, "Pre-Order Unity Android, Get a Google Nexus One!," 24 June 2010. [Online]. Available: http://blogs.unity3d.com/2010/06/24/pre-order-unity-android-get-a-google-nexus-one/. [Accessed June 2013].

[47] M. Elgan, "How Microsoft is losing control of gesture-based interfaces to Leap Motion," 2 April 2013. [Online]. Available: http://www.digitalartsonline.co.uk/features/interactive-design/how-microsoft-lost- control-of-gestural-interfaces/. [Accessed June 2013].

73