University of Southern California Dissertations and Theses

Amoeboid: cross-device game design

(USC Thesis Other)

Amoeboid: cross-device game design

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content University of Southern California

AMOEBOID:
Cross-Device Game Design

Michael James Murdock
School of Cinematic Arts, Interactive Media and Games Division
30 March 2014

Murdock 1
Table of Contents

1. Abstract………………………………………….……………………….2
1.1 Story and World……………………………….………………………..2
2. Format…………………………………….…………………………........3
3. Goals…………………….…………………….………………………….4
3.1 Explore crossdevice game mechanics design……………………...4
3.2 Create a world that persists across devices…………………………5
3.3 Demonstrate a proofofconcept that is less than 20 minutes of gameplay while
displaying a variety of crossdevice gameplay.………………………….6
4. Feedback from Winteractive…………………….……………………...7
4.1 Key questions from Winteractive…………………….……………….8
5. Categories of Exploration…………………….………………………...9
5.1 Maps of multidevice worlds…………………….…………………....9
5.2 Expected reactions across devices (Mechanics Consistency)…..10
5.3 Using the best features of devices…………………….…………….10
5.4 Time between interactions…………………….……………………...11
6. Changes…………………….…………………….…………………….12
6.1 Cutting puzzles…………………….…………………….……………12
6.2 A Linear Experience…………………….…………………….………13
6.3 Make crossdevice interaction more apparent and sooner………...14
7. Design Approach Guidelines…………………….…………………….14
8. Focusing of crossdevice design intent…………………….…………16
9. Conclusions and next steps…………………….……………………...17
10. Works Cited…………………….…………………….………………..18

Murdock 2
Michael Murdock
USC, SCA, IMGD Thesis
30 March 2014
AMOEBOID: Cross-Device Game Design
1. Abstract
Amoeboid is a single player game that features a persistent world explored
across multiple devices. It takes place in a wonky laboratory from two vastly
different perspectives as two characters work together to avert an imminent
crisis. The two characters’ gameplay is split across mobile and console devices . . .
each serving as a window into the world of the game.
The game is not intended to be a complete commercial product, but rather
a proof-of-concept for cross-device game design. The area of exploration is
focused on the possibilities for game development when mobile and console
platforms are merged and considered to be one platform from inception to
implementation.
The core goals of Amoeboid are to examine ways for players to have a
continuous sense of narrative and space as they move from device to device and
to build a complete experience the showcases several cross-device mechanics.

1.1 Story and World
Amoeboid is a short story about a simple experiment quickly spiraling out
of control. Players progress through the experience through the perspectives of

Murdock 3
both the amoeba (on the tablet) and the scientist (on the console) as they
encounter bigger and bigger problems. By playing both perspectives, the player
learns the full story and ultimately fixes the catastrophe they inadvertently
created.
The world of Amoeboid was designed with multi-device interaction in
mind. The laboratory in which the story takes place has content that is available
for each device embedded within it. Thus, the persistence of the experience for
the player played an integral role in the rules and conventions of the world.

2. Format
Amoeboid has two main characters: A scientist and a mutant amoeba. The
player sees the world through both macro and micro scales. The scientist’s story
is played on a console with a gamepad from a first-person perspective, the
amoeba’s on a mobile device with touch and tilt controls. Each storyline is
designed specifically to best use the affordances of the host device.
For the scientist, the gameplay is the full 3d laboratory explored in the first
person; for the amoeba, gameplay is a 2d platformer comprised of several short
levels. Because Amoeboid explores the relationship between mobile and PC
gameplay, Players must play both mobile and console portions of the game for a
complete playthrough.
The idea is not to emulate the abilities of another device, but to use the
unique characteristics of the device to expand the world of the game. For the

Murdock 4
demonstration of Amoeboid, both devices are directly connected via a WI-FI
router and are able to freely send and receive information throughout a
playthrough.

3. Goals
Given the technical complexities of device networking and designing for
multiple target platforms, the scope of Amoeboid was kept to a short, small
experience so that the following goals could be sufficiently explored and iterated
upon. The following subsections contain an expanded explanation of each key
goal.

3.1 Explore cross-device game mechanics design
“We use an average of three different screen combinations every day”
(The New Multi-Screen World , 17, Google 2012) Amazingly, 90% of consumers
1
use multiple screens over time to accomplish a task. Additionally, 98% of those
consumers move between devices in the same day. (Google, 17)
Right now, some of their interactions are continuous, such as email,
Netflix, Facebook . . . the user can pick up directly where they left off on any
device they own. But many of their interactions are discrete, self-contained
worlds. Popular games such as Angry Birds (Rovio, 2009), Temple Run (Imangi
Studios, 2011) , and Clash of Clans (Supercell, 2012) only exist in their mobile
1
This document served as an important guide for designing crossdevice mechanics. Although it
exhaustively covered consumer behavior for daily tasks, games were omitted from the findings. We used
this as an opportunity to explore this gap in knowledge. downloadable here

Murdock 5
form.
Amoeboid is aimed at creating a continuous world for players to
experience no matter which device they’re currently using. Over the course of
the design process, my team is discovering effective methods and best-practices
bridging the gap between the mobile experience and the console experience.
We characterized typical mobile gameplay to have shorter play sessions
and simple mechanics that used touchscreen and motion controls. We decided
that a console game session was represented by longer. more immersive
2
gameplay sessions that utilized the precise controls of a gamepad.

3.2 Create a world that persists across devices
One of the first challenges for Amoeboid was to create a world in which
interaction across devices inherently makes sense. Each step along the way we
have been challenging ourselves to find compelling content for each device for
each story beat. We’ve also developed a consistent visual language to help the
player recognize that the world extends beyond the frame of their current
window.
Since many users already jump between devices during the course of the
day, the habits are already in place . . . we pushed to utilize this behavior to form
a more complete sense of the world of Amoeboid.

2
Immersive in the sense that the interface is less of an impedance to the gameplay and the player generally
has more time and attention to “inhabit” the world of the game.

Murdock 6
3.3 Demonstrate a proof-of-concept that is less than 20 minutes of
gameplay while displaying a variety of cross-device gameplay.
We’ve set a limit of no more than 20 minutes per playthrough (with the
ideal length being 10 - 15 minutes). Within this amount of time, we aim to deliver
around five compelling and varied cross-device game interactions. Because of
this length requirement, we’ve been cutting and refining content to best let the
player jump into the experience.
It’s noteworthy that the mobile experience is a driving factor in shortening
the game length: mobile games tend to have quicker play sessions. Several levels
of Angry Birds could be completed in a few minutes, whereas a console level may
take tens of minutes (or much longer). The game length now implies a few
complete mobile game levels and one complete console level.
We’re designing a few “pick-up-and-play” mechanics so that the player can
focus more on the multi-device experience and less on learning gameplay. We’ve
greatly simplified the interactions to rely less on teaching mechanics and more
on using the game literacy that many gamers already have. (Although we’re also
including tutorial segments for accessibility to non-gamers.) Consequently, the
Scientist’s perspective is comprised mainly of walking exploration and simple
“press to interact” environmental objects. The amoeba’s gameplay is touch and
tilt based, and most playtesters were able to figure out how to interact with no
tutorial in less than 20 seconds.

Murdock 7
4. Feedback from Winteractive
Two weeks prior to the winter thesis show, we had a playtest that
showcased a separate mechanic working on each device. On the tablet, players
could platform through a level “Angry Birds” style by stretching and flinging the
amoeba around. On the console, players could explore a laboratory and solve a
simple “fetch quest” puzzle by locating 3 pieces of a laboratory experiment.
However, the worlds were not yet connected. Although there was overlap
in assets and design in the mobile and console worlds, at this point, they were not
actually communicating with each other. I decided that instead of polishing the
experience we had, two discrete games, we needed to complete a portion of the
game that did showcase cross-device interaction. It is a core feature of the
Amoeboid experience and I knew we had to convey that concept to players.
The playthrough involved the player as the scientist exploring the
laboratory and finding “experiment cubes” on the console. They then slotted
them into a grid, thus “constructing” the amoeba’s mobile level. At the press of a
3
button, the entire level to that point was sent to the tablet where the player could
play through from the inside of the experiment as a platformer with touch
controls.
A lot didn’t work well at Winteractive. Gameplay was buggy and
unbalanced, and players weren’t able to orient themselves in the world between
devices. However rough, I was pleased that the players were able to experience
3
The mechanic is conceptually similar to connecting hamster tubes as the scientist to form a level for
amoeba and added to the grand difference in scales between the two characters.

Murdock 8
a cross-device world and begin to see the connection of the game design across
platforms. However, it was abundantly clear that a lot had to change so that the
focus of the experience was on the cross-device interactions.

4.1 Key questions from Winteractive
In a winter show post-mortem, my team identified four key questions to
improve and explore for the second half of the project:

1. How could we make a map of the multi-device game world to orient the
player in an experience that jumps between platforms? Players got lost in the
Winteractive demo. We had to find a solution for giving players a clear “You are
Here” indicator, not just spatially, but within the narrative and world of the
game.
2. What kinds of interactions and mechanics would create expected
reactions across devices? Abilities and world rules should be consistent across
platforms, how can we use mechanics to show that the worlds of tablet and
console are windows into the same world?
3. How can we best use the affordances of a particular device? What’s good
(and bad) about a gamepad controller? What’s good (and bad) about a touch / tilt
mobile device? The point where one form of input begins to break down, is a
great opportunity for another to take over and allow the player to touch the
game world in a more robust way.

Murdock 9
4. How can we design for a variety of time changes between gameplay on
devices? What does an immediate jump between platforms look like? What
about an interaction that is less immediate . . . occurring over several hours or
days?

These four questions turned into the framework for exploration in the
second half of the project. Our goal is to have a solution for how we solved each
one. Also, seeing as most questions exist on a gradient, we aim to show a
compelling example at each extreme end of the spectrum.

5. Categories of Exploration
Given the aforementioned questions, the following is a breakdown of
specific challenges and proposed solutions we’re currently implementing.

5.1 Maps of multi-device worlds
Primarily, we are dealing with this challenge primarily by constructing a
stronger narrative. Story is a good way to pull a player through an experience. To
orient the player in the game (and between devices) we have a clear story beat
that lets them know where they are in the physical space, what’s at stake, and
what their goal is.
Secondly, we’re exploring a visual language that helps orient the player in
the space. One weakness of the Winteractive show build was that the visual

Murdock 10
styles of the mobile and console levels looked too similar. (fig 1) Our solution is to
have each area feature colors unique to the host platform where that content is
available.

Fig 1. Winter show screenshots showing the micro world of the amoeba and the Macro World of the scientist.

5.2 Expected reactions across devices (Mechanics Consistency)
The world of Amoeboid is tightly interlinked between devices. As a result,
for (almost) every action a corresponding cross-device reaction should occur. In a
portion of the story, when the gravity generator goes haywire, the worlds on
both the tablet and console invert and the player is walking (and squishing) on
the ceiling.
Further into this portion of the game, the player is able to flip their mobile
device upside down, to flip the gravity in the console world. This tie between the
physical orientation of the device and the mechanic of gravity inverting is a
strong display of cause and effect that makes both devices feel more connected.

5.3 Using the best features of devices

Murdock 11
A key attribute of the gamepad is its ability to “vanish” from the players’
minds once they learn the controls. They don’t have to look at it; their attention is
fully focused on the screen.
In the scientist’s world, the controller grants the player an uninterrupted
opportunity to explore the laboratory. They don’t have to look away from the
television once they learn the controls. The primary interact button naturally
falls under the player’s index finger while their thumbs comfortably rest on the
analogue sticks, a first person game convention.
Conversely, on the tablet, as soon as a player interacts, they cover a portion
of the screen. However, the touch screen allows for the device to intuitively
mimic a great variety of interfaces that a gamepad cannot. Each method of
control has its strengths as well as a clear point where the effectiveness of the
input begins to break down.
This is a great opportunity for a tablet touch screen interaction to take
over: any interaction can be a primary interaction as the interface can emulate a
wider variety of control systems.
In the amoeba’s world, the input falls into 3 types: gestural (using the
device’s Inertial Measurement Unit (IMU) for tilt controls, tap and drag. In
playtesting, we’ve discovered that each of these interactions are discovered by
players in less than 20 seconds without a tutorial: The graphics play a strong role
in indicating how the interaction works.

Murdock 12
5.4 Time between interactions
For the Winteractive show, the time between interaction on the tablet and
console was immediate. As soon as the player pressed the “send” button, the level
showed up on the tablet. While this worked, we are now exploring designs
where a player could have their mobile device with them throughout the day
and then carry their progress with them back to the console when they return
home.
Right now, we’re designing levels that could manifest themselves as a
series of challenges on the tablet that run in parallel to the console experience
until the narrative pulls both devices together again. The final reactor section is
designed to represent asynchronous gameplay. We are covering both ends of the
immediacy spectrum by featuring synchronous “second screen” gameplay in the
gravity generator segment.

6. Changes
In response to the rough portions of the Winteractive playthrough, here’s
the key areas we’ve changed:

6.1 Cutting puzzles
Since the core goal of the game is not solving puzzles, but cross-device
game design, we decided to cut the puzzles entirely. Initially a key feature, we
discovered that they take a significant amount of time to solve for the player that

Murdock 13
did not contribute to the intended multi-device design. Currently gameplay is
navigation-based on the console, and action-platforming on the tablet. Both
devices have the same goal: Get to the end of the level to progress. Other games
such as Super Mario Bros.(Nintendo, 1985) and Wolfenstein 3D (Id Software,
1992) formalized this convention and Amoeboid builds upon players knowledge
4
of these game types.

6.2 A Linear Experience
This not only helps in telling the story, it helps orient the player in a world
that expects them to jump across devices. This is a solid way of ensuring that we
know what the player should know at any given point in the experience, so it’s
easier to design the progression of their experience. Again, since the goal is about
cross-device design, a linear experience allows us to focus more attention on
moving between platforms. (fig 2). There is no back-tracking, so the player gets a
new space to explore and interact with a corresponding cross-devices
interaction.
4
These games represent 2d gameplay (Super Mario Bros.) and 3d gameplay (Wolfenstein 3D). Amoeboid
features both styles of gameplay separated by device.

Murdock 14

fig 2. Current map of the game level that has a linear layout.

6.3 Make cross-device interaction more apparent and sooner
For the Winter show, players could play for over 20 minutes before they
encountered the cross-device interaction. We’re now making sure they
experience their first taste within 1 minute. For the entire experience of about 15
minutes, they will jump between devices more than 5 times. Still to do is to
design a simple “Handshake” experience that shows the player the connected
devices and acclimates them to the idea that they will be jumping between the
mobile and console worlds frequently during an Amoeboid playthrough.

7. Design Approach Guidelines
In the design of the world and narrative, we created the rule “If anything
can go wrong . . . it will!” Thus the short story is a domino-effect of increasingly
alarming proportions that must be saved at the last minute by both characters

Murdock 15
working together.
We initially wanted to have a non-linear game in which the player could
explore the interactions at their own pace. However, since we’re crafting an
experience that requires a great deal of the player’s attention to multi-device
cues, we decided linear gameplay would help with player progression and
pacing. This would allow us to build and expand the base vocabulary of
cross-device interactions. We started with the “hello world” of this kind of
thinking. A simple choice in the color of the amoeba on the console immediately
carries into the tablet world and persists for the rest of the game.
Getting the player to think of both devices as one world is the primary
concept of the project, so we knew that we had to introduce this concept as soon
as possible.
Our current design approach is to ask: “ What happens on the console here
in the game; what happens on mobile here? ” Since the progression of gameplay
has been designed, the team has been injecting more cross device design into the
experience. Every step along the way, we make sure that each platform is being
given a significant role in the gameplay. We also look back to the defined
categories of exploration: making sure to have enough unique kinds of design
covered.
For example, a microscope interaction early in the game depicts an
immediate interplay of devices. Players look through a laboratory microscope in
the console world and instantly see through the lens on the tablet where the

Murdock 16
gameplay continues. For a later interaction we made sure to design less
immediate gameplay, something that doesn’t expect the player to have both
devices powered on and right next to each other.
For each portion of the game we ask: “How can this experience bleed back
into the other device?” Even if an interaction doesn’t directly influence
gameplay, it should still indicate that the worlds are interlinked. An example of
this is that the color amoeba the player chooses jumps from the console to the
tablet, then the accessories a player acquires on the tablet comes back to the
console from the tablet. An electrical short circuit in the amoeba’s world starts a
fire in the laboratory that the scientist has to deal with.
We decided on creating a strong visual language to indicate gameplay on
the tablet and console. Tablet levels are black light neon like a bioluminescent
fish tank. The console world is more grey with saturated accent colors. The idea
is that the player will soon recognize a mobile level that exists in the console
world and know when to jump to their tablet.

8. Focusing of cross-device design intent
Amoeboid is being drastically tightened up and simplified to really
showcase the thought in cross-device world and game design. Last semester we
learned that the networked experience has to be the center of every piece of
game design. When Amoeboid started, we worked on creating compelling
experiences on each device and then “wiring” them together.

Murdock 17
This did not work well. Now we create prototypes that are networked.
Most interactions have a cross-device component. We’ve simplified the
networking component to allow faster iteration and more reliable
communication between devices. We’ve dropped the built in game engine
networking (which required accessing an online server that Unity3d maintained)
and are now directly connecting the devices via a local router and IP addresses.
In an increasingly interlinked world, it’s clear to me that it’s far more
effective to prototype and design in a connected environment than try to piece
elements together after the core systems have already been created.
There is a great opportunity for Amoeboid now to make the networked
experience implicit in the world design. Last semester we started with a story,
and then a level, and then an interaction. We’re reversing that sequence now.
We’ve been building connected interactions, which we’re using to sequence out a
level and progression of experiences, and using the story as a tool to wrap
everything together.

9. Conclusions and next steps
Amoeboid has so far achieved two important goals:
1. Design and build a multi-device world and a variety of compelling gameplay
ideas between platforms.
2. Document the progress and uncover pertinent questions and new challenges
for game design.

Murdock 18
The most important finding was that multi-device games ought to be
conceived of and designed for all the platforms at the beginning of the process. It
is a very difficult task to fuse the experiences of multiple devices together after
considerable design work has already been done in isolation. Therefore, at each
step of development, designers should be considering what actions happen on
each device and how those experiences flow into one another.

Since Amoeboid was always designed to be a small vertical-slice of
multi-device game design, the next steps are to further test the guidelines we’ve
been using on a more substantial project. We would like to see how the intrinsic
world design of a game could support a more fully realized game loop, as seen in
games such as Portal (Valve Corporation, 2007). We ended up cutting our puzzles
to enhance the clarity of our multi-device message, but with more time and
development resources, we’re confident that our guidelines would allow us to
naturally integrate them in.

10. Works Cited
Google, Sterling Brands. The New Multi-Screen World, 2012. Digital

Abstract (if available)

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Resurrection/Insurrection

PDF

Alma: designing compassion for healthcare workers through interactive play

PDF

Come with Me: a cooperative game focusing on player emotion

PDF

The moonlighters: a narrative listening approach to videogame storytelling

PDF

Players play: extending the lexicon of games and designing for player interaction

PDF

a•part•ment

PDF

Reality ends here: environmental game design and participatory spectacle

PDF

Free Will: a video game

PDF

Alternative History

PDF

Toward a theory of gesture design

PDF

Video Volume

PDF

Garden designing a creative experience with art and music orchestra

PDF

Ahistoric

PDF

Intimation and experience of the self in games

PDF

My friend and me

PDF

Paralect: an example of transition focused design

PDF

Maum: exploring immersive gameplay with emerging user interface devices

PDF

Outer Wilds: a game of curiosity-driven space exploration

PDF

Behind Shadows: the design and experiment for a new way of interaction - shadow as the controller

PDF

Manjusaka

Asset Metadata

Creator Murdock, Michael James (author)

Core Title Amoeboid: cross-device game design

School School of Cinematic Arts

Degree Master of Fine Arts

Degree Program Interactive Media

Publication Date 04/30/2014

Defense Date 04/17/2014

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag Amoeboid,console,cross-device,Design,device,game,Michael Murdock,mjmurdock,Mobile,OAI-PMH Harvest,videogame

Format application/pdf (imt)

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor McDowell, Alex (committee chair), Malamed, Laird (committee member), Price, Charley (committee member)

Creator Email michael@mjmurdock.com

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c3-405990

Unique identifier UC11295173

Identifier etd-MurdockMic-2458.pdf (filename),usctheses-c3-405990 (legacy record id)

Legacy Identifier etd-MurdockMic-2458.pdf

Dmrecord 405990

Document Type Thesis

Format application/pdf (imt)

Rights Murdock, Michael James

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA