Proteus: A Cruise Design Tool for the Future

Proteus: A Cruise Design Tool for the Future
Reina Magica
MA thesis
Aalto University School of Arts, Design and Architecture, Department of Media
10 March 2014
2
Master of Arts Thesis Abstract
Author Reina Magica
Title of Thesis Proteus: A Cruise Design Tool for the Future
Department Department of Media
Degree Programme MA in New Media - Game Design and Production
Year 2014
Number of Pages 74 + 23
Language English
Abstract
Proteus is a design tool and VR user testing system developed for the cruise industry. The main research question to
answer was how to use elements of game design and user-oriented design to build a system that allows for fast and
flexible prototyping of cruise ship interior environments before full scale structures are employed. Related to the main
research question was finding ways to map and visualise user experiences and user data that happens during a test session,
integrating the process of design and quick reiteration into a software smoothly and effectively, and what kinds of ideas
can be piloted in a VR environment and how.
Background studies examined emerging markets of new cruisers from new cultures and also the general growth and
competitive nature of the cruise industry to determine a concept for a new tool which would provide the usability to test,
improve, and communicate ship designs and interior layouts at a faster, better, and more cost efficient way than currently
possible. Delving into game design to inspire new features and game design processes that would aid the cruise design
process, a prototype of Proteus was made and tested upon students and potential users. The concept was to make rapid
prototyping available to the interior designers of the ship, and the deck layout architects, while building on an
architectural sound base, such as an embedded blueprint. The models built within the Proteus environment would be able
to be fine-tuned to accurate measurements of scale, while being basic enough to modify flexibly, such as changing the
colour, texture, orientation, and scale, on the fly, even as user testing is running. The program is modelled upon a What
You See is What You Get (WYSIWYG) approach. User testing is run as a mini game or “mission” created in the ship
design editor. The prototype was developed over the course of six months, and both a CAVE-like version and an Oculus
Rift version exists. The result of the trial was that the Proteus system was easy to use for both marine technology related
personnel and also for people with no experience in design software. The main user testing was done in a 2-wall CAVElike environment, and further development was done in Oculus. The environment was enjoyable to navigate in both a
CAVE and Oculus setting, although post-HMD adaptation was needed after some minutes of Oculus use, and extended
use of Oculus lead to some nausea and discomfort for some users.
Keywords Virtual reality, ship design, gamification, game design
3
Acknowledgements
Special thanks to Markku Reunanen and Markus Ahola for being my great supervisors for this project,
and Felipe Marjalizo for programming the demo. I really appreciated having you three on board, and
couldn’t have done it without you! Thanks to Tuukka Takala for the support for the use of Upponurkka
technology and spaces! Thanks to Lauri Lehtonen “the script wizard” when we needed some quick
code tips! Thanks to Antti Kauppi from ABE project for continued feedback and support during
development. Thanks to RCCL and STX Finland for insight into the shipping industry, field trips, and
enthusiastic feedback. Thanks to Jurgen Rosen for contributing a ship deck design to the project, and
Niiler Hardi and Leonidas Samouladas for ship architecture related suggestions. Thanks to Miikka
Junnila for tutoring and support. Thanks to Virpi Ahvenainen, Martin Jogeva, and Vanja Valencak for
ideas and moral support during our cruise-related theses. Thanks to Aalto Service Factory and Jussi
Jykänen for the office space, and Urban Mill for their working space and equipment. Thanks to all the
students and friends who helped me test my project, and the staff at MLab for support and feedback.
Thanks to Media Lab and the great students and teachers I met during the years. And thanks to all my
good friends from other parts of my life, who kept me happy and sane this whole time! Kudos! And I
thank all the developers, artists, and writers of all the great games I played during childhood, for leading
me to become a Master of Game… Design ;). What a title, what an honour. Much WOW.
4
Table of Contents
1. Introduction ................................................................................................................................. 6
1.1 Background ............................................................................................................................ 6
1.2 Research Questions................................................................................................................ 8
1.3 Objective ................................................................................................................................ 8
1.4 Scope and Methodology ........................................................................................................ 9
2. Between Two Disciplines .......................................................................................................... 11
2.1 Cruise Ship Design .............................................................................................................. 11
2.2 Game Design ....................................................................................................................... 12
2.3 Game Design meets Cruise Ship Design ............................................................................. 16
3. Background Study ..................................................................................................................... 18
3.1 Markets ................................................................................................................................ 18
3.2 User Needs and System Design Requirements .................................................................... 19
3.3 Benchmarking ...................................................................................................................... 21
3.3.1 Benchmarking Existing Cruise-related Games .............................................................. 21
3.3.2 Benchmarking Control Interfaces ..................................................................................... 26
3.3.3 Benchmarking Viewing Interfaces ................................................................................ 29
3.3.4 Conclusions from Benchmarking .................................................................................. 31
4. Ship Design and Gamified User Testing ................................................................................... 33
4.1 Concept ................................................................................................................................ 33
4.2 Applying Game Design and Virtual Reality Strategies to a Cruise Design Tool ................ 34
4.3 Planning, Development and Interface Design ..................................................................... 38
4.3.1 Planning ........................................................................................................................ 38
4.3.2 Development ................................................................................................................ 39
4.3.3 Final Demo and Features .............................................................................................. 45
5. Evaluation of the Project ........................................................................................................... 50
5.1 Test Planning ....................................................................................................................... 50
5.2 Test Outline ......................................................................................................................... 51
5.3 Test Implementation ............................................................................................................ 52
5.4 The Tests.............................................................................................................................. 55
5.4.1 Test 1 Virtual Navigation Task ...................................................................................... 58
5.4.2 Test 2 Ship Design Task ................................................................................................. 58
5
5.5 Results ................................................................................................................................. 59
5.6 Discussion and Improvements ............................................................................................. 60
6. Conclusions ............................................................................................................................... 68
7. References................................................................................................................................. 71
6
1. Introduction
1.1 Background
The cruise industry is growing, at a projected rate of 2 million new passengers (from 21.6 million
to 23.6 million passengers) from 2013 to 2017 (Cruise Market Watch: Growth, 2013). Nineteen
new ships will be available by 2015, adding a $3.2 billion US dollar predicted revenue to the
cruise industry. With this increase in new passengers and increased competition by different
shipping companies and new ships, cruise designers and service providers will need to find a way
to differentiate and customise their cruise experiences to come out on top. It is from this
phenomenon and market situation that I have proposed the development of a design system that
tests newer ideas more rapidly, and simulates many environments or situations that can be
encountered on a cruise ship journey, and this is what my project and demo Proteus is born from.
Fig. 1. Woodcut of Proteus, Greek god of rivers and oceans by N.N. (1531), Wikimedia
Commons.
The Proteus project aims to provide the same degree of flexibility and fluidity to the cruise ship
design process as the god it is named after: Proteus, the shapeshifting Greek god of rivers and
oceans (Merriam-Webster, 2014) (see Fig. 1). The software and user-testing setup tries to
provide rapid morphability between designing and user-testing, with an emphasis on natural
controls and interfaces that do not discern between users, whether they have previous skill in
computer-aided design or not.
7
There is a great opportunity for virtual reality and gaming to help optimise cruise designs and
customise the cruise passenger experience more effectively and more cost-effectively than
traditional means. The technology is more accessible and available than ever before: for example,
Oculus Rift, a VR headset is currently available to consumers, for 350 US dollars, and the second
higher resolution version is shipping to pre-ordered customers in July 2014 (Oculus VR, 2014).
In contrast, as part of a traditional design, testing, and quality control process for the ship
Voyager of the Seas, Royal Caribbean Cruise Lines needed to build expensive models of different
concepts at different scales to “ensure they would work in real life”, which increased the cost to
well over the original project estimate of $500 million US dollars (Ship Technology.com, 2012).
Simulating some of these models and environments in a virtual reality system, as part of a design
and assessment process, would reduce some of the needs for expensive models, especially on
larger scales that can be simulated inexpensively via VR. Besides being cost effective, a
dedicated virtual reality design and testing platform for cruise ship designers also increases the
rapidity between prototyping and testing, as it is a hybrid software and hardware system that
functions for both design and testing. Successful commercial uses of virtual reality for customer
experience enhancement include research and application by Disney of virtual reality
technologies and setups on their theme park rides (Mine, 2003), VR-based surgery training
(Kühnapfel et al., 1997) and the currently popular Oculus Rift VR headset, being implement by
game developers to enhance gaming experiences. Similar to Disney, passenger cruise companies
are also in the entertainment and leisure business, and thus I propose there are possibilities in
virtual reality technology as an aid to cruise design that I will explore.
This production is a thesis project created as part of the Cruise and Ferry Experience programme,
a cross-discipline study programme in a passenger ship context involving all six schools of Aalto
University (Aalto University, 2011). My role in this project was as a researcher, game/application
designer, and UI designer, while Felipe Marjalizo is the programmer for the game application.
The supervisors for the project are Markus Ahola from Marine Technology Department, who
runs the Cruise and Ferry Experience Programme, and Markku Reunanen from Media Lab, who
teaches interactive visualisation and 3D User Interfaces, with additional support from instructor
Miikka Junnila, a game lecturer who is in charge of the Game Design and Production Masters
Programme. In addition, the Cruise and Ferry steering group has given support and feedback
during their monthly meetings, alongside industry partners like RCCL (Royal Caribbean Cruise
Lines), STX, Foreship, Antti Kauppi from the Aalto Build Environment (ABE) project, who are
currently developing a shared virtual building environment for education and research, and naval
architecture students Jurgen Rosen, Niiler Hardi, and Leonidas Samouladas.
8
1.2 Research Questions
The main question of this research is “How can elements of game design and user-orientated
design be used to build a fast and flexible design prototyping software and VR system for testing
cruise ship interior environments before full scale structures are employed?”
Sub questions:

How can we map and visualise user experiences and user data that happened within a
testing session?

How can we integrate the process of design and reiteration into software so it can be used
to make design changes smoothly and quickly?

How can a designer pilot ideas before the model or scale building phase of ship
production, and what kind of ideas could be piloted?
1.3 Objective
The objective was to identify novel ways for the cruise industry to test or prototype cruise ship
environments more effectively in terms of time, resources and outcomes of user testing. The idea
is to create a more visual system of design whose outcomes and processes are shareable –
viewers will be able to comment and influence different stages of the interior design of cruise
ships, linking architects, interior designers, stakeholders and decision-makers onto a common
platform. Better communication between key people in the project means better design and
better informed decision-making. The tool becomes the platform on which different participants
can analyse the current state of a design, whether it is the architect, the interior designer, the test
user, or the budget manager.
9
This application is designed for rapid prototyping and testing, within the early stages of the
design, allowing designers to try out new ideas without the added cost of having to build ship
models on a real scale. It aims at allowing designers to freely move between rapid prototyping
and testing cruise ship environments that can be experienced in a realistic and immersive
environment, utilising a virtual reality setup with game controllers and display devices. The
system would allow rapid feedback on deck interior layouts, themes, colours, wallpapers, etc.,
therefore allowing the testing of more ideas in a shorter space of time.
Besides just a 3d design tool, the software will include a built-in user testing platform using
virtual reality, so that participants can see their ship designs in a simulated full scale, and
experience walking and navigation through the ship. The user testing platform is built like a
level-editor in a game, in that the elements inside the design can be edited, and then the game can
be “run” and played by the test user. Meanwhile, the software automatically collects data on user
interaction and user behaviour, such as route taken, time taken to reach certain places, and objects
or rooms that have been interacted with within the virtual cruise ship environment.
1.4 Scope and Methodology
The scope of the research is limited to creating a visual demo of a hybrid design and user-testing
application for designing the interiors and modification of the layout of a passenger deck. It does
not cover engine rooms, machinery or ship balance: only the design of passenger accessible decks
and its interior design. It is assumed that the person(s) using the system have some knowledge of
correct architectural or interior design placement of rooms or objects. The demo software
currently does not restrict incorrect placement of items, walls or rooms.
Interviews and meetings were conducted about what features would be desired within this virtual
reality application, and what features were missing from current tools. Secondly, the way to
integrate the game/virtual simulation aspect was explored. Thirdly, cruise-design games, input
devices, and output devices were benchmarked to judge their suitability for this project by how
well they meet the requirements of the target user groups. As a result of the research outcomes,
the demo was made.
10
The study aims at identifying GUI (Graphical User Interface) elements, game systems, systems
for data-mining user behaviour within a cruise simulation environment that are useful for cruise
design. The demo was designed to function as an application that can create, modify, and
simulate designs in virtual reality. It will be used to analyse passenger navigation, passenger
choices, and the aesthetic appeal and functionality of visual environments. I will use my skills as
a game and UI designer to consider systems for managing the link between designer and user/test
subject, and find ways to organise things on the UI to make a functional link between the two
interfaces used by two different users.
The methodology was to interview designers and ship designers for thoughts on the proposed
system and their needs, benchmark the existing technology and devices that would be suitable for
the design, benchmark similar software, and finally to design and test the prototype. Ship
designers and architects were interviewed concerning the practicalities of cruise ship design, the
nuances of cruise ship design, and what kind of features they would like to see in VR testing
software. At the same time, I attempted to identify the target users of this system and their needs,
and features or design restrictions and goals that will be valuable to the design application, after
speaking to ship interior designers, naval architecture students, and marine technology directors
from Royal Caribbean Cruise Line and STX Finland. The game was developed and iterated in
accordance to the findings and testing, and from advice and feedback from ABE research group
and users.
11
2. Between Two Disciplines
2.1 Cruise Ship Design
Cruises are designed for competition: the competition between one cruise company and another,
competition between on-land services like hotels, a competition on the attractiveness of routes, of
on-board entertainment, of dining and even between newer and older ships of the same company
(Quartermaine & Peter, 2006, p. 23). It must remain competitive in all respects to generate profit,
keep a solid brand image, and to keep it afloat as a popular option for consumer holidays, because
it is competing with tourism and entertainment of all kinds. One could say that competition is the
most critical aspect of cruise design, and therefore, new ways of design and thinking are
paramount and must be constantly researched and rethought, since a company's position in this
industry hinges on its ability to innovate, surprise, and deliver experiences that passengers have
not experienced before. In addition to the visual and sensual appeals that a cruise needs to
deliver, there is a high technical order for both safety and efficiency too, making the cruising
industry one of the most expensive industries during the pre-production phase, as highlighted by
the following quote:
In its design, every ship is a compromise between the optimum demands of trade profit
and the minimum requirements of safety. A cruise ship however, must also be fun – for
its passengers, it is primarily a hotel and entertainment venue that moves. To design,
construct and operate such complex floating cities demands imagination, technical
expertise – and materials – of the very highest order. (Quartermaine & Peter, 2006, p. 7)
As an example of the time and costs and yearly competition that are involved in building and
marketing a state of the art cruise ship, the Royal Caribbean’s Oasis of the Seas, the largest and
tallest cruise liner in the world at the time when it debuted, took five years of planning and
construction at a cost of $1.4 billion (Rusli, 2009). A year later, it was exceeded in size by her
sister ship, Allure of the Seas, by two inches, also from Royal Caribbean Cruise Line (2009). In
a competitive market, publicity is important, and the Allure of the Seas had the publicity and
coverage of being “the largest cruise ship in the world” (Twisted Sifter, 2011). This is the level
of long term planning required within the cruise industry – there is already a strategy for the
successive releases of ships planned five or more years in advance. Consumers, passengers want
to be leading edge too: they want to tell their relatives and friends they were on the largest ship,
12
one that is “nearly as long as the Empire State building is tall” (Rusli, 2009). “It’s in the DNA of
our company, about every 10 years, to take more or less a fresh sheet of paper and create the
greatest cruise ship in the world” (Goldstein, CEO of Royal Caribbean International, cited in
Rusli, 2009).
Royal Caribbean International is a good case example of a group that could use the advantages of
a pipeline which involves rapid prototyping processes in combined virtual and desktop
environments, before the more expensive and time-extensive real scale modelling is employed.
In fact, if implemented properly, or to replace some of those processes all together. With cruising
packages that can cost an average of $490 US dollars for a seven-night cruise, to an average of
$1000 US dollars per package for cruises on the larger ships like Oasis (Rusli, 2009), these are
not trivial amounts of money for consumers, and the target consumers are making critical
decisions of how to spend their money, so the more testing that can be done with consumers
beforehand on design and navigation preferences, the better the outcome. Goldstein stated: “Our
customers want more choice, more options, more variety, they want to be in control of their
vacation decision making” (as quoted by Rusli, 2009), and mentions the “major gamble” as a
cruise operator. With my proposed design system and workflow, it is possible to design for more
choices with less “gambles”. Because it is a market leader in passenger cruises, with a position
and identity to be cutting edge, RCCL could make a progression towards implementing virtual
reality and innovative design technologies, so that ships such as the Allure of the Seas (Rusli,
2009), with its 18 decks of world class amenities, can be designed more rapidly and more
efficiency, with less limits on what ideas can be tested.
2.2 Game Design
Game design, on the most basic level, is “the process of creating the content and rules of a game”
according to Braithwaite (2009, p. 2), a game designer that has worked on twenty-two
internationally known video game titles. Braithwaite describes good game design as designing in
a way that motivates players to reach designate goals, and allows the player to make meaningful
decisions (2009, p. 2). Beyond that, the key factors of game design are nonlinearity, systems and
interaction design, and the magic circle.
13
Games may include many elements of nonlinearity, such as non-linear plot lines, non-linear
strategies for solving a challenge, non-linear order of events, and non-linear selection of
challenges (Rouse, 2005, pp. 119–120). Hence, games can be quite complex designs. A game
can include one, several, or all of these non-linearities, and perhaps there are ever more forms of
nonlinearity too, such as order of action, customisable characters and objects and their effects, for
example. While most products designed for consumers assume a limited number of
functionalities, games are based on a myriad of variable interactions between the player and other
players, players and the game environment. Two-way feedback between the system and the
player is what defines game design. It is possible to find in other forms of intelligent design, for
example, within some more modern consumer electronics and machines which have learning
systems that learn and remember and respond to user choices, but it is essential in game design
that there is two-way feedback and interaction, either between a player and another player, or a
player versus a game system. This interaction is what constitutes as meaningful play, a
meaningful choice and reaction to what has been presented by the system or the player to the
other, and vice versa (Salen & Zimmerman, 2003, p. 61).
Games are also designed to function as a system of relationships between game objects, or the
tokens in the game, and a game environment (the surroundings). Some rules to the system dictate
how game objects and players can act or react to certain situations. A system can be simple or
complex, but in either case, can give significant complexity to the player so that meaningful
choices can be made during the game session (a period of time playing a game). For example, in
Pac-Man, the player has only a single possible action during the whole game: deciding which
direction to turn Pac-man when he reaches any corner or intersection. The ghosts have three
modes: Chase, Scatter, or Frightened, and they have a target tile which they choose to reach, but
each ghost behaves slightly differently: The Red Ghost, Blinky, usually chases behind Pac-Man,
the Pink Ghost, Pinky, usually tries to ambush Pac-Man from the front (Birch, 2010), and so on.
The interaction in here is that the player reacts to enemy positions, and also the enemies react to
the player position, constantly, which is already more complex and intelligent than most
consumer products. The most basic consumer objects, especially non-digital objects, are mostly
one-way interactions: for example, you apply force to scissors and they cut. The consumer
applies an action onto the product, and a single, predictable outcome usually occurs. However,
games create feedback loops of constant feedback, similar to a heater monitoring the air
temperature and adjusting the heating accordingly, but instead of one parameter, games
commonly monitor multiple parameters (such as the players health points, whether a player is in
water, or in the air, or has a power up, or advanced features such as monitoring if the game is too
14
difficult for the player and adjusting the number of enemies or speed accordingly). These
systems and behaviours create situations which can be exciting or thrilling to the player, because
they adjust the environment on a multitude of factors, and part of the player’s work or “play” is to
understand how their environment behaves around them, and what kind of things they do to
trigger certain behaviours from other characters around, such as enemies. Designs and design
systems can also be more thrilling when complex behaviours are built around, that the player
does not need to fully understand, but is approached by the player as something “new” and not
experienced before.
The third element in game design discipline that I will talk about is the concept of the ‘magic
circle’, as described by Huizinga (1949, p. 10), which is a pre-defined physical or ideological
space where certain special rules apply, aka “temporary worlds within real worlds”. Whereas
most product and service designs are set in a “real” setting, games are deliberately set to be
removed from reality and are set within a virtual and totally separate space from the participants
current ‘real’ environment. This separation is unique within the game design discipline versus
many other design disciplines: for example, an architect assumes he is designing houses and
buildings that function in a real world context, and a ship designer feels more or less the same
way. But game design specifically aims to create an imaginary world removed from the real
world, that means, the participant, the player, on starting the game, is supposed to enter into a
fantasy world with a highly specific set of rules that do not apply to the ‘real world’. Game rules
and game actions do not affect reality and vice versa. Games are designed this way for maximum
immersion, or the feeling of being enveloped in the space of the game: the atmosphere, its moods,
its social/political context, its own world. This can possibly aid designers to think “outside the
box” and have more creative freedom when placing a ship design context into such a fantastical
“temporary world” environment.
To begin using concepts from the game design discipline as a tool for designing cruise ships,
firstly I must explain the terminology used. I created a table of terms (see Table 1) that are used
in my project interchangeably between each other, due to the fact the words come from both
general designing (architectural, user interaction, and user experience) and game design. The
context of designer in this case is a cruise ship interior designer and UI/UX designer (User
Interaction and User Experience designer), and the game designer in this case is a digital game
designer.
15
Table 1
List of terms used interchangeably in the Proteus project
Design terminology
Game terminology
Test user
Player
Deck area in user testing
Level
Deck Designer
Level Designer
CAD (Computer Aided Design) tool
Level editor
User testing session
Game session
Test user task
Mission
Plan
Game Design Document
Designer
Game Designer
Operator
GM (Gamemaster)
Avatar/figurine
NPC (Non-player character)
The term “test user” in user testing within my application can be interchangeably called “player”,
since the user testing is happening within a game. Games contain a player or multiple players. In
Proteus, we have only one player.
The person operating the test, or basically the “person behind the computer” is the operator, or in
game terms, a “Gamemaster”. The Gamemaster operates the changes happening live in game. In
this case, it can be the control of NPCs or non-player characters, for example if they walk or
speak. The NPCs are used in my game to give players interesting or useful interactions in the
otherwise static environment.
The deck area used in the user testing is a called a “level”, in game terminology. Commonly
games are made up of multiple “levels” that proceed in difficulty in ascending order. Of course,
level design is not only about ascending difficulty, it is about the content, its interactions afforded
to the player, and its enticement – put simply, “to build spaces that are fun for players to play in”
(Rouse, 2005, p. 445). The software or user interface to the 3d deck design here, is the level
editor.
16
The level editor is where we arrange all the things that the player will be able to see and interact
with, and similar to usual ship deck planning, we will plan the rooms and hallways, and
ultimately pre-design paths for the player on some assumptions of player behaviour, which we
can then test.
The user testing or “game session” is just a way to define the time between the start and end of a
test session. The user task given to the player when they are in the game environment is called a
mission.
Finally, the plan for the whole system and interface, or usually what designers call a plan, in a
game designer’s world, is put into a design document. This document includes all the planned
features, work progress, concept art, list of functionalities, and basically anything that needs to be
defined within a game.
2.3 Game Design meets Cruise Ship Design
Cruise ship design could also start from a similar premise of the magic circle effect of games:
Within the ‘magic circle’, there is a different world with totally different rules and different
things to experience, different characters, different roles, and so on. Surveys note that passengers
are looking for novelty (Chen & Juan, 2011). People want to experience something removed
from their own reality, and that the premise for selling cruise should rest on the promise of
delivering an experience that can be found nowhere else, as similar to the feeling of an epic game
experience. Cruise companies could focus on offering more uniqueness and less regularity:
Change the rules to how people experience and “play” on the ship.
Gamification has various definitions, but in most business cases, it has previously been focused
on the narrow use of certain elements such as points systems within website functionality. Here I
will take the wider definition by Zichermann and Cunningham, which is “The process of gamethinking and game mechanics to engage users and solve problems” (2011, p. 16). For cruise
design, I took the idea of gamification in industrial use a bit further, in that it could use game
design techniques to solve many different kinds of design issues, or to streamline the workflow of
design, rather than solely embedding some game mechanics into a software or interface for
motivational value. Games are designed to have intuitive interfaces, and the game design process
is designed to have fast feedback and interaction between team members, and this is something
that can become more widespread in more traditional design disciplines. I wanted to look into
17
the ship design process and see what ways they can improve the whole development process of
cruise ships and enhance user and customer experience.
Video games also have wide exposure and influence in popular culture. The countries that spend
the most money on video games are Canada, US, UK, and Japan (Compare Database, 2006), the
US being one of the key cruise markets, with the UK to follow. It is very possible that virtual
reality cruise games and related games will be a key solution to marketing cruises or creating
interest in cruising. Both the gamification of cruising and the ‘cruisification’ of gaming should
be considered when designing the future market and facilities for cruises.
18
3. Background Study
3.1 Markets
As a background study on the market situation of cruising and cruise consumers, I analysed
earlier studies by Chen and Juan (2011) and Ahola (2011). The fastest growing cruise market is
Asia, but the Asia-Pacific region accounts for only 7% of all cruising (Chen & Juan, 2011), so the
biggest region of travel remains in the Caribbean. This presents a disconnect between available
services and market demand. Emerging markets such as Asia may require more innovative and
customised service development to ensure it fits that particular market, marking the possibility of
new revenue for the cruise industry. Prototyping suitable cruise design options for emerging
markets can be aided by virtual reality tools, as a cost-effective means to test emergent designs.
The lack of luxury cruising culture in these regions means designers are free to re-invent and
create new services and designs. Customers from the Asia region are mostly first time cruisers
looking for a different travel experience, who consider price, novelty and food quality to be key
factors on cruise selection (Chen & Juan, 2011). Virtual simulation of cruise ship environments
can aid the selection of the most popular elements with new cruise demographics through test
users in virtual reality. In Creating a consumer-driven business model for the cruise line industry:
Case Royal Caribbean Cruise Lines Ltd., Ahola (2011) mentions that Asian consumer markets
had a demand for family-orientated services, casinos, and Asian food on-board (p. 2). These
elements also demand smart floor planning, for example, how to provide a family friendly
environment while separating age-restricted areas such as casinos. Customer service can be
simulated in virtual tools because scale models lack interaction within the environment, which is
actually a key factor in how a passenger experiences cruising. Scale models are static, meaning
they are only good simulations for noting the appearance of the ship, the heights and widths of
spaces, materials, and so forth. They do not include a human and interactive factor. Virtual
environments can provide simulations of virtual passengers and simulations of services so that
designers and testers can preliminarily identify which models of service features passengers like
and dislike before actually building these services. As of the moment, many cruise ship projects
go over budget because of the need to build multiple scale models: The Oasis of the Seas
projected cost was $1.24 billion US dollars, but consequently cost $1.4 billion US dollars to build
(Net Resources International, n.d), because real scale models of some of the decks were built to
check on the overall look and feel of the interiors (Rusli, 2009), so using virtual models could
have drastic cost-saving results.
19
The key point is that a virtual testing tool will be good for both known and lesser researched
markets. For example, little is known about cruise passengers in Australia other than the most
basic demographics: The passengers are mostly from United Kingdom or United States, aged
above sixty, with previous cruising experience (Agnew & Killalea, 2012), that value spa services
and quality of service in general (Ahola, 2011, p. ii). With more virtual simulations and more
user-testing, we could perhaps generate a wider picture of who the cruisers are, what they like,
why they cruise, and what they want from cruising. And moreover the most important thing is,
being able to test things that cruisers may love but do not even know yet because it has not
existed before. This is the main idea of a virtual testing to, it is to test these “what if” scenarios
and settings and see what response comes back from the users.
3.2 User Needs and System Design Requirements
The target users and participants for this system are ship designers, test users, and key decision
makers within cruise companies. The ship designers will use the desktop computer interface with
my design software, while the test users participate in the virtual reality space which is modelled
from the software. Key decision makers will sit inside the space and watch the screens of the VR
while one user is navigating in the deck in VR.
Based on preliminary interviews during April 2013, with participants such as managers from
Royal Caribbean Cruise Lines, marine technology education staff, and Vertti Kivi, interior design
for the modern cruise ship, Viking Grace, I found their needs to be quite distinct: Ship designers
need an easy, intuitive, fast interface for creating and modifying details and visual structures on a
ship deck. Test users need easy-to-use navigation, clear user interfaces, and a feeling of real
space, even when it is a virtual space. Key decision makers and stakeholders in cruising need to
see and feel also a level and degree of real space and reality, and clearness of visual concepts of
the ship deck, as realistically and detailed as possible.
20
Table 2
User needs stated in interviews with cruise industry related people
Types of Users
Features needed in Proteus
Investors/Decision Makers

Must be simple to use

Fast/smooth

Multiple people using at once

Good graphics

Duplicates materials/ objects realistically

Easy to control

Can be explained quickly how to use the system

Single player mode

Realistic, hopefully in VR

Must be immersive/believable

Intuitive controls

Flexibility between viewing and designing

Fast

Detailed

Richly sensual, textured

Accurate controls

Be able to train and practise job specific skills/safety
“Players”/Experience testers
Designers
Cruise staff
drills

Realism
From the interviews and analysis, the commonality between all these users is that they need
realism, and accurate controls. For test users and investors, smoothness, ease of control, and
good graphics are most important. The controls need to be intuitive so that not much needs to be
explained, because these groups of people come into using this software and setup through
meetings and test runs, and they are not usually using this software or similar on a daily basis,
therefore there needs to be zero to bare minimal barriers to being able to use the software and
hardware right away. These are good requirements for designers too, but on top of this, designers
need to be able to accurately and easily access design tools, e.g.
21
selecting/grabbing/dropping/drawing objects. Hence, in the GUI (Graphical User Interface)
menus, needs to be easy to access. The problems and critique noted for a virtual reality
simulation was the lack of tactileness or touchability. Vertti Kivi, the interior designer for Viking
Grace, stressed that it was important, as a designer, to be able to see in very rich detail, and also
feel the textures of carpets and wallpapers (personal communication, April 5, 2013), so it was
good to understand this limitation of virtual modelling. This is tactile element is one that cannot
be replicated within system I designed, but should be tested by other means when necessary.
3.3 Benchmarking
3.3.1 Benchmarking Existing Cruise-related Games
There were a wide variety of cruise games found (see Table 3), including cruise design and cruise
economy strategy games, emergency simulation games, roleplaying drama games, and also first
person shooter games and adventure games. They were analysed to determine the genre, features,
and UI and design elements inside the game. Since game reviews speak more about gameplay
than design features, these games were analysed personally through video observation, by
playing the game, and by listing feature content given by the game developer.
Table 3
Analysis of Different Cruise Games
1. Luxury Liner Tycoon (PC)
Genre: Strategy, Cruise Design and Cruise economy Simulation
Description: Build your own luxury cruise liner
Features:
●
Modular ship design, design a cruise with units of services and items
(solariums, chairs)
●
Simulation of costs of running a ship
UI and Design analysis:
●
Icons have no names, confusing branching selection
●
Does not specify how to invite passengers to ship, no icons
22
●
Graphical detail was unrealistic, more like a conceptual model of design of
cruises from a financial view
2. Cruise Ship Tycoon (PC)
Genre: Strategy, Cruise Design and Cruise Economy Simulation
Description: Design and build the facilities of a cruise ship using a budget, run cruises
Features:
●
Random disaster simulation
●
Ship selection (number of decks)
●
20,000 dollar budget
●
Missions, time limits
●
Navigation simulation
UI and Design analysis:
●
Good deck navigation, cutaway view for different decks on the ship
●
3d isometric view for the design interface
●
Realistic looking scale for a ship
●
Good goal systems, with targets to complete “missions
●
Clear icons for building features
●
Overall very fully featured, and looks easy to navigate
Source: Dimitrijevic, 2011.
3. The Ship: Murder Party (PC)
Genre: First Person Shooter
Description: A cruise themed assassination game built upon Source engine.
Features:
●
3d deck, navigate around the interior of a cruise ship
●
Missions
●
Multiplayer
●
Staff on-deck
●
Items, pick up
●
Time limits
UI and Design analysis:
●
Realistic environment, realistic corridors and ship rooms and spaces
●
Atmospheric
●
Item switching system, items can be held and used
23
●
Doors can be opened and closed
●
Labels on characters
●
Proximity to objects or characters gives information
Source: Blazing Griffin, 2014.
4. Lies and Seductions (PC)
Genre: Adventure
Description: A roleplaying adventure game about lies and seduction based on Dangerous
Liaisons by Pierre Choderlos de Laclos
Features:
●
“Four seducible characters”
●
Actions: “flirt, mislead, eavesdrop, and pump information”
●
persuade characters to help you to reach the goal
●
Texas hold'em poker
●
Dancing
●
“Non-player characters forms opinions based on your choices they
perceive”
UI and Design analysis:
●
3d environment
●
Single player, third person view
●
Ship is populated with only four interactive characters and some crew,
somewhat of a “fish tank”
●
Not really a realistic ship simulation, but a caricature of personal drama
between people and flirting
●
Cruise theme was not really relevant, more about several people
interacting in a closed space
●
AI and “opinion forming” characters were interesting
●
Limited multichoice dialogue options, no free dialogue
Source: Lies and Seduction, 2009.
5. Velvet Sundown
Genre: Roleplaying, adventure, multiplayer
Description: Guests are invited on a short cruise, whilst the plot is turning…
Features:
●
Interaction with human players
24
●
Multiplayer, from 4-11 players
●
Objects, quests, chatting
UI and Design analysis:
●
First person view
●
Realistic deck and views
●
Has other people, some possibility for interacting in a normal way with other
passengers, such as natural dialogue and conversation
●
Limited to 11 players maximum
●
Cannot be played alone
Source: Tribe Studios, 2014.
6. EAS – Ship Simulator
Genre: Emergency simulation, training game
Description: An emergency and safety training simulator for cruise personnel
Features:
●
Realistic shipboard environment
●
Realistic sea and weather
●
Safety and Crisis Missions: Abandon ship, Man overboard, Helicopter
operations, Collision, Grounding, Explosion, Structural damage, Excessive list,
Flooding, Search & Rescue.
●
“Real Time feedback of crew events, ship’s condition or scenario progress”
●
Action logging, assessment of performance
UI and Design analysis:
●
First person view
●
Realistic deck, but no other people on board, therefore not very realistic
simulation of an emergency
Source: Marine Consulting, 2014
Cruise design and operations games focused on the design of rooms and services for passengers
and the operational costs, and customer satisfaction. These games had an isometric top view of
the ship, where the player could build different elements of a ship like rooms and deck chairs, in
a modular way, like playing with Lego bricks. These games (see 1 & 2 in Table 3) had a wide
choice of selectable elements, like premade cabins, entertainment, and service facilities that could
be freely placed into a cruise ship deck. The cruise simulation/economy games had good UI ideas
for making a visual editor for a cruise deck. The scale of the ship was quite realistic looking at a
25
glance, however, the placement of the cabins and facilities didn’t take into account the
architecture or safety requirements of a real ship. Costs were automatically deducted from a
budget, the budget itself was linked to revenue, so it was also a kind of simulation of projected
costs and returns of developing a cruise, albeit not in an entirely realistic way, since in these
game modular units can be removed while the cruise is operation, and the money is refunded into
the main budget, which is not how it works in real life. It does however, raise an interesting
proposal about the future of modular design in cruise shipping, and the sort of flexibility of
removal or moveable room and facility units on a ship and how it can react to trends and
demands by passengers, and that ships can be modularly put together to reflect the season or
currently popular features that are requested or suggested by passengers.
The safety simulation and action/first person shooter genre games were most similar to what I
wanted my game to look like in VR. The environments were highly textured and realistic looking
and the first person perspective was effective in placing the player in the scene in an immersive
way. However, the emergency game analysed was devoid of other people or characters, and it
was simulated on an empty ship deck, which might not reflect the situation of a real emergency
(i.e. the chaos and noise of people panicking and running), so within my design program and
game, I want to be able to place human figures (NPCs) that can be interacted with.
My conclusion from the benchmarking was that cruise-themed games were spread over many
different genres of gaming (action, strategy, simulation, adventure) but they each bought some
unique design elements to be considered for Proteus. Novel features such as modular design and
simulation/play mode, taken from cruise economy/simulation games would be added to my
project. I decided to focus more on the interior and navigational design aspects of decks and less
on safety, because I saw that the safety simulation games available were quite fully featured
already. As a new tool, I want to service the market that is underserviced rather than duplicate
something available, so I will focus more on rapid testing and live simulation as originally started,
even though safety is of course an important thing to test on ships.
26
3.3.2 Benchmarking Control Interfaces
At least two control devices are needed because there is a test user (the person viewing the VR
model) and the designer/operator, who manipulates and builds the model of the deck. Initial
research was carried out to determine the suitability of different control devices for project. The
qualities I looked for in a control device were related to ease of use, degree of control, and
comfort. Furthermore, the game/application would be built in Unity, so some support for the
device would be necessary. The findings are shown in Table 5.
Table 4
Control Devices
Oculus Rift
Technology
Additional notes


Control via accelerometer
only (head position
Needs another device for control of
walking
tracking)

Available since May 2013 (dev kit)

360° FOR

Simulator sickness possible, if not

3 DOF

FOV 90° Horizontal

Resolution 1280 x 800
implemented well with controls

Cannot see others in room
Skeletal positional

Some lag during movement
tracking (works fine most

No need to hold a controller
pixels
Kinect

of the time)
Wii mote

Full body tracking

Depth sensor

Microphone

RGB camera

Bluetooth

Requires batteries

Acceleration along 3 axes

No 6 DOF Tracker

Optical sensor

Audio and rumble
feedback
27

Standard buttons and
trigger

Supports two handed
interaction
PlayStation

Move
Tracks ball position and

accelerometer (tilt
position)

Also has second controller for control
(analog stick and trigger)

For the player

Good for designing/navigating in
6 DOF tracking (position
and orientation)

Buttons at front, and
trigger button at back
Leap Motion

Vibration

Wireless

Finger tracking
front of a small screen
Xbox joypad

Limited distance

Limited immersiveness

Comfortable

Good for navigation of large areas

360° directional control

Good for fine and smooth navigation

Additionally buttons can be used as
selectors
Voice control
Mouse

For the player

No need for gestures

Difficult or slow to use for movement

Larger range of detection

Tiring for the speaker

Easy to navigate menus

Issues with background noise
and directions

No implementation in Unity

Slow to enter numbers

Good for designing, as it is a familiar

Standard peripheral

Fine pointing control
and commonly used peripheral for
designers who use computer software

For the designer
28
The conclusion from benchmarking was that the easiest device for the designer would be a mouse,
since it is familiar and allows for fine control. The leap motion was considered, but because it is
a gestural device, there would be many actions that would need to be taught, and holding hands
up for extended periods causes fatigue. So for this, and the learning curve, I didn’t see much
benefit choosing Leap Motion versus something familiar and simpler, something that most people
have used before. The device chosen for the test user was the PlayStation move, for several
reasons. Firstly the PlayStation move has an accelerometer so one could be attached to the head
for monitoring head movements and tilt. At the time of early development, the Oculus Rift kit
was not available to me so we used alternatives. Secondly, the PlayStation Move controller is
equally suitable for both left-handers and right-handers, because the design is symmetrical and
can be held in either hand in the same way, so users can use their dominant hand for fine control.
According to Bowman et. al (2005, p. 325), with asymmetric bimanual controls (two handed
control setup where both hands do separate unrelated actions) the dominant hand should do the
fine precise control, while the less dominant hand can be in charge of bigger, less precise
movements.
Fig. 2 Sony PlayStation 3 Move Controllers, one with a directional joystick (left), and one with a
tracking light ball (right), Amazon.com.
The PS3 Move controllers were used alongside software for PS3 called MoveMe, which is for
developers that use PS3 Move controllers as an input device.
29
3.3.3 Benchmarking Viewing Interfaces
Benchmarking was made to determine a suitable device for experiencing the VR part of the
Proteus system. A normal 2d laptop or desktop screen was selected as the viewing interface for
the designer view for the Proteus application, but different technologies were available for the
VR part of the experience, hence it was necessary to benchmark and compare the pros and cons
of each device. The biggest considerations for a suitable viewing interface for the project was the
suitability, availability, safety and comfort of using the device. In terms of suitability, it was
discussed that the focus is the test user and the operator/designer on the desktop screen, whilst
providing an option to view the test users screen by other participants too, since this would be a
tool used to share and discuss cruise designers. The audience outside of the test user, including
the designer and the stakeholders in a project: whether they be investors, project managers,
structural and interior designers and so on. The viewing interfaces used are an important choice
because this is the method of communication between interdisciplinary personnel involved in a
cruise design project. Availability was measured by the availability for the time frame of this
project, and also the availability in general for developing the tool if one had the means and
opportunity to, analysing what is available commercially today. Safety and comfort are related,
in that factors such as simulator sickness, ergonomics, and body strain were taken into account.
The biggest safety or health issue with virtual reality viewing interfaces is the possibility of
simulator sickness, which is described as “discomfort during, and sometimes after, a session in a
simulated environment” (Kolasinski, 1995, p.1). Kolasinski’s research on simulator sickness
separated the causal factors into three categories: Individual, Simulator, or Task related (1995,
p.2). There were many factors named, but some examples of individual factors include mental
rotation ability, concentration level, perceptual style of an individual, and age. Simulator related
factors include screen size, eye strain, inter-pupillary distance, and field of view. Task-related
simulator sickness factors include duration of task, degree of control, method of movement, and
type of application, and those factors were taken into account later in the design of the tests and
the software, not during hardware selection. The factors taken into account during benchmarking
were mostly related to non-individual factors, since it was not possible to pre-screen test users for
such things as concentration level for example, while other individual factors such as age were
not of concern because motion sickness susceptibility was found to be greatest between 2–12
year olds (Brand, 1975, cited in Kolasinski, 1995, p.17) and no one in my user tests fit that age
group. The biggest simulator sickness related factors taken into account were field of view and
30
duration of task. Wider field of view (FOV) increases the incidence of simulator sickness
(Kennedy et al., cited in Kolasinski, 1995, p. 26). It was noted in other research that simulator
sickness symptoms were more common when visuals were minified (0.5) or magnified (2.0)
image scale factors, and less when on neutral (1.0) scale factor (Draper, Viirre, Furness, &
Gawron, 2001, p. 1). Proteus tries to provide the test user with a real-scale version of cruise
environments in virtual reality. Simulator sickness is less common for people controlling the
motion than for the non-controlling viewers (Casali, cited in Kolasinski, 1995, p. 32). In my
project and testing, the users of the system have control, i.e. the test user, while people can
observe the project on an external screen. Simulator sickness did not vary with changes in time
delay and it was found that head angular position tended have correlations to symptoms (Draper,
Viirre, Furness, & Gawron, p. 1). Stereoscopy was chosen because of increased depth perception
it allows, but according to research, there are increased risks of experiencing nausea but no other
factors of simulator sickness (Kolasinski, 1995, p. 24). For the head mounted devices like Oculus
Rift, inter-pupillary distance can be a problem for people with inter-pupillary distances that are
far greater and smaller than the setting on the system (Kolasinski, p. 27). The Oculus Rift has
adjustment knobs and lens to compensate for near and far sightedness, but I found them difficult
to fine tune. Also the device itself is weighty on the head, and for smaller heads, the strap is not
tight enough to bring the screen close enough, so that I must hold it with my hand to see clearly.
Also sometimes the device would bump into my eyes which was unpleasant and uncomfortable.
Table 5
Types of viewing interfaces and suitability for Proteus user testing
CAVE
FOV: up to 180°
Technical features:

5.1, 7.1 Surround sound

2-6 walls (Floor and ceiling possible also)

Typically 2 projectors per wall (for stereoscopy)
Suitability: The setup is large and expensive, but one 2-wall setup called Upponurkka (Lokki,
Ilmonen, Makela, & Takala, 2006) was running within Aalto University’s Otaniemi campus at
the time of the project’s development, and that was used for the Proteus testing.
Source: Kenyon, 1995
Oculus Rift
31
FOV: About 90° horizontal
Technical features: (May 2013 Dev Kit version)

3DOF (3 Degrees of Freedom) Head tracking

Stereoscopic 3D

Software adjustment for interpupillary distance

Adjustable for mild near-sightedness and far-sightedness with a 3 lens set and diopter
Suitability: Cheap and portable, Oculus Rift is a good solution. The drawback being simulator
sickness related to head mounted devices, such as head and neck strain (current Oculus is 289
grams, while new Oculus will be 379 grams). Also the proximity of the lens to my eyeballs was
discomforting.
Source: Greenwald, 2013
Single screen with projection (stereoscopic)
FOV: Direct viewing FOV about 100°
Technical features:

Single wall

2 projectors per wall

Stereoscopy
Suitability: Available at Aalto University (Upponurkka). This setup was what was actually used
during most of the project during the testing, as the camera outputs from Unity made it more
practical to project onto a single screen rather than split the image onto two screens.
After the benchmarking (see Table 6), the CAVE-like system was chosen for testing and
prototyping the project. After the initial testing, the project was ported to an Oculus Rift version
once the kit was available due to accessibility and portability of the device for exhibitions and
home use.
3.3.4 Conclusions from Benchmarking
There were many interesting and varied features found in cruise related games that were novel
concepts for a shipping design tool, such as modular units, character interactions, and mission.
Secondly, there were many good examples of an explorable UI, and ways to navigate a visual 3d
plan of a ship that allowed editing and adding removing features.
32
Viewing interfaces were analysed, with the CAVE setup being the most appropriate chosen for
both comfort and the viewability for multiple stakeholders (such as an audience of people
discussing a cruise design project). Various novel control interfaces were explored, but the most
comfortable, user friendly, technically appropriate and most compatible were the PlayStation
Move and Oculus Rift. The PlayStation move controllers were chosen to be used with the CAVE
wall setup, while later version of the demo ran on Oculus Rift with an Xbox controller.
Possibilities of simulator sickness were analysed and sort to be minimalised, including in the later
design of the user testing tasks so that the exposure to VR device was of a limited amount of time.
33
4. Ship Design and Gamified User Testing
4.1 Concept
The concept is a game and design hybrid application that can be used for testing and collecting
data on user interaction and user feedback within a virtual cruise ship environment. This tool is
designed to be used for rapid prototyping and testing, within the early stages of the design,
allowing designers to try out new ideas cost effectively, with minimal need of physical real scale
models. The application aims at allowing designers to freely move between rapid prototyping
and testing cruise ship environments that can be experienced in a virtually realistic and
immersive environment, utilising a virtual reality setup using appropriate control movements and
devices and display devices.
Fig. 3. XP lines tray drawing, Aalto University
Initially, the idea was to create an application that creates a basic 3d model out of a 2d map or
ship blueprint provided by the architect (see Fig. 3), and enable fast prototyping and testing of
navigation and to be able to tweak the overall visual experience for a cruise passenger fast and
effectively by building an environment with rapid feedback between designing and testing.
Everything can be customised instantaneously, such as wall colour, textures, etc. User testing is
34
as simple as running a “mission”, which would be game terminology for a user task. The path
and stops of the player are recorded as drop points on the map linked by lines, and the times the
player enters the room are recorded also.
4.2 Applying Game Design and Virtual Reality Strategies to a Cruise Design
Tool
The identical of a tool that can alter the design and layout of objects on the cruise ship deck in
game design terms would be a ‘level editor’. There are many synonyms in game design for the
same thing, such as map editor and world editor. According to Rouse (2004), a writer with over
ten years of experience as a game developer, the importance of a level editor is that it both does
basic functionally smoothly and quickly, generally without the need for coding, and also to give
additional features “to empower designers to do the best work possible” (p. 394).
Fig 4. Unity3d, an example of a WYSIWYG editor for games, Its Art Mag
35
The first basic feature of a level editor is to allow the designer to see the world simultaneous
while designing. The first view, the ‘player view’, is same view that the player will have while
playing the game, otherwise known as What You See Is What You Get or WYSIWYG (see Fig.
4). WYSIWYG editors are also commonly used in web development, and other fields such as
interaction design prototyping for web or applications. The second view, the ‘edit view’, is a
perspective view that will be useful for the designer, such as a top down view of the entire map,
or a top down view of one part of the map that is scrollable (cf. Rouse, p.394). This view is good
for the designer to conceptualise the overall spaces of the design, and easy to see hallways and
paths (which I use to track the player movement).
In terms of realism, it would be important to simulate as much of the real environment
encountered by the user as possible (such as other passengers). According to Turner & Turner
(2006), virtual reality aims to “capture the degree to which people feel present in the given
environment” (p. 204). This is a challenge not so much of graphical simulation, which we can
accomplish much better than say, ten to twenty years ago, but that the interpretation and feeling
of a place is not only based on visuals but on other elements. The elements named by Turner &
Turner are rich and “sensuous” details in the environment (p. 204) and length of exposure to an
environment (p. 205). The richness of the textures and other senses like touch, and taste, cannot
be replicated within virtual reality. However, the length of exposure and visual environment and
feeling of space can be. Real places tend to be experienced for a longer time period, such as
visiting a landmark or tourist attraction or a city. The virtual setup is available 24/7 as long as
there are resources and space for it, so it can be a good simulation experience for the feeling of
time.
36
Fig. 5. Fire in the Cargo hold emergency simulation game (video still), Marine Consulting.
Fig. 6. The Ship, first person shooter game (screenshot), Outerlight.
Related to realism, I decided that some level of interaction with passengers and cruise ship staff
on the user testing level/map was important and missing from most user testing process of cruise
design to date. For example, even one example of a commercial emergency simulation game (see
Fig. 5), did not simulate actual passengers or other staff on the ship. In contrast to training games,
games in the entertainment industry usually feature human or humanoid characters to interact
with, for example on the first person shooter game called The Ship (see Fig. 6), The level of
37
realism is quite good, and the atmosphere is enhanced by glimpses of other live, multiplayer
characters.
Presently in cruise ship design, real scale models are used to check the function and feel of an
important space (for example, main shopping deck or recreation areas), and those real scale
models also miss human or simulated interaction. The reason that digital simulations are missing
interaction is likely because of the additional programming and work hours required to achieve
behaviours and AI, but non-digital cruise ship design goes through the traditional workflow of
engineering blueprint to 3d model to final presentation and thus has always skipped the element
of simulated human interaction. Games however, make simulation of humans, humanoids and
interactive characters a standard in most games, because it gives the space atmosphere, and it
creates stories and memorable moments, not to mention interesting and useful interactions.
While most games are not populated by as large an amount of characters and figures as one
would see on a street or ship (though many modern games have gone very far to achieve visual
illusion of such, for example in Assassins Creed, or Skyrim, see Fig. 7), characters are
strategically placed for interaction and to forward a story. This was a feature I wanted to bring
into the environment testing tool because people and interactions can have a huge meaning,
especially on a cruise journey which is basically isolated from the outside world. I wanted to
make the cruise experience meaningful. I wanted designers to be able to test the meanings and the
features they create, and the systems of navigation and interaction that they plan. Part of the
success of navigation and success of ease of use is about planning the environment, much like in
games a very large part of game design is planning the actual levels and maps, which takes create
skill, preplanning, and much testing to achieve great results.
38
Fig. 7. Realism of human characters in Assassin’s Creed IV, PS4 Home
4.3 Planning, Development and Interface Design
4.3.1 Planning
Within several meetings held between the urban planning department, marine technology
department meeting, ABE (Aalto Build Environment) development group, shipping industry
representatives from STX Finland and RCCL (Royal Caribbean Cruise Lines) and myself, the
needs of the industry and academic usage were discussed. Firstly, the outcome was discussed
with the ABE (Aalto Build Environment) group. These discussions provided a framework for
what features my project should feature, and how my project would fit into the Aalto Build
Environment project, how it can build new concepts for the Aalto Build Environment project, and
how we could give creative tools to the future development of the shipping industry. Vertti Kivi,
the interior designer for the ship, Viking Grace (personal communication, April 5, 2013) noted
that if he was to use such software in the future, it should simulate the materials and details of all
the interior elements as accurately as possible. Other case uses named by the marine technology
and shipping industry personnel was an alternative to life size models built for showing to
multiple stakeholders and decision makers, for looking at the overall internal design of a deck.
During the design of the control interface, I had looked for various player input and control
mechanisms that would be possible for the interaction with our main view (player view, interior
of the ship) in my background study. While walking (physically) would have been the most
39
natural way to navigate, the space of the dual wall setup with Kinect did not allow for tracking
for very far distances, and also the player would lose view of the screen when turning around.
Thus, I decided to implement a game controller and use the joystick for movement. A second
controller was used as a pointer and object manipulator.
4.3.2 Development
The initial two months were spent on theoretical research and a visit to the state of the art cruise
ship, Viking Grace, which has innovative and exploratory interior design by Vertti Kivi (see Fig.
8. & Fig. 9.). During the same trip on April 5th 2013, I interviewed Kivi about his thoughts and
wishes on a VR design tool. It was based on the pros and cons he spoke about when dealing with
VR for ship interior design (the lack of feeling of texture, the need for high detail and accurate
scale), that I proceeded to bring the best uses out of VR for cruise interior design and minimalise
the drawbacks.
Fig. 8. Interior Design in state of the art cruise ship, Viking Grace, personal collection.
40
Fig. 9. Colour changing rooms, Viking Grace, personal collection.
The concept for the application was developed with all the features I found in benchmarking
games in mind. I have previous experience using design applications such as a few 3d modelling
programs, and more general 2d design tools like Photoshop, but I found games to have the kind
of UI that is even more user-friendly (when designed well), and also intuitive. Commercial
design software tends to have many things in a list, many features that most people unfamiliar
with the software probably cannot use, but most games are designed UI-wise on the assumption
that people do not know how to use this game: it is aimed at the absolute beginner, the average
person. I wanted to bring some of these simple UI aspects into my software too, knowing that,
this is the tool not only aimed at the more technical personnel in the shipping industry such as the
ship architects and engineers, but it is a tool for communicating design that is aimed at also the
visual designers and the business operations staff, and the decision makers involved in the cruise
industry. It is deliberately aimed not to be fully featured technically, but richly visual, so that
these designs can be communicated to all involved.
In my concept, visual and interior designers can design a deck, complete with rooms, walls,
carpets and decor, and change the colours etc., while also creating user testing tasks for a test user
to participate in in VR. In addition, I wanted to give the richness of interaction into the VR
41
testing. I wanted it to be populated with the characters and non-player characters that appear in
games (see Fig. 10), so that the environments aren’t static, but there is some life there. Later, in
discussions with naval architects, I decided to add a measure of scale to the software, so that all
the rooms had real measurements, and that there was a visible grid which you could use to make
accurate sized rooms, walls, and carpets (see. Fig. 11).
Fig. 10. Concept drawing for voice and avatar interaction. Personal collection.
42
Fig 11. Concept for rulers and grids for designing accurate sized space and facilities and the
design panel. Personal collection.
Fig. 12. First prototype with very basic features
In June 2013, I started to work with programmer Felipe Marjalizo to make a demo and develop
the features for Proteus within the game engine/tool, Unity 3D. The timetable was to finalise
finalise the basic deck by June 22nd, 2013, make working scripts for wall-altering/scaling
functions and drop point scripts by June 29th, 2013 and map all the controllers, if possible test in
working space of the cave by July 6th, 2013. Many drawings and photo edits were made to
explain the interactive concepts, and development proceeded as a step-by-step list of the features
I planned that needed to be implemented by Felipe in script, and dealing or altering the designs
depending on the stumbling blocks and scripting difficulties we found on the way.
43
Examples of an early development To Do list:
1. Turn off the textures of all the rooms
2. Put a floor on the room
3. Top down view camera
4. First person controller + first person view camera
5. First person controls (AWSD movement, left click on objects)
6. Timer on, timer stop (invisible timer, not visible to test user)
7. Invisible drop points for player + joining the lines after the mission ends (10 secs)
8. Link name of the name with the room game object
9. Remake rooms with basic walls with rigid body (5 walls, one opening on one side) (one
invisible walkthrough collider).
10. Doors without a rigid body
11. Make colliders around the whole ship
12. Create mission button > Mission designer screen
44
Fig 13. User testing in the Upponurkka environment, personal collection.
Originally, a third PlayStation move controller was used in the non-dominant hand as a pointer,
but during pilot testing on August 6th 2013, the users noted the difference between the light wand
visuals and his hand, noting it felt weird when he could not see the light wand he was holding (an
outcome of having a screen that is smaller than the players peripheral vision). Having fairly little
use for the pointer, it was removed from the controls to simplify and streamline the design.
During the testing of the prototype software in VR, it was noticed that many things need fine
adjustment. With the original Upponurkka and PlayStation move setup (see Fig 13.), height was
an issue, both the height of the virtual models and the height of the participants. There was much
fine tuning needed, and the reference was mostly by sight and adjustment. Secondly, the walk
speed and controller sensitivity became very crucial. The simulator sickness factor of selfmovement speed named by Kolasinski (1995, p. 34) states that high move speeds resulted in
more simulator sickness and too slow speeds did not indicate movement to the player, and that
was exactly the same issue we needed to deal with through thorough trial and error testing. As
we moved to the project to Oculus Rift later, a similar problem occurred, only with distortion and
view angles along with walk speed. Testing with Oculus Rift was more difficult than with the
CAVE because we could get bad cases of simulator sickness when the settings were not right
45
with any of those issues, which limited the amount of testing we could do. This affected the
quality of the demo as there can be improvements made through adjustment but it has taken
ample amounts of time to fine tune.
4.3.3 Final Demo and Features
The final demo is a ship design environment, with a user testing element embedded in a “mission
designer”, which is a way for the designer to freely set an objective for the player/user-tester and
monitor how they do this task. Monitoring includes recording their total path and locations
during every ten seconds, and the rooms they visit, and the total time taken to reach a goal or
objective. The included demo in Appendix H is optimised for PC running Windows Vista with
Oculus Rift. Several screen resolutions are included, along with full instructions on the features.
The included version differs from the version used in the user testing trials. The previous version
was setup on Upponurkka walls. Also this current version is updated with a new deck plan.
Fig 14. Main menu for designer at top, with open colour, texture, and object panels. Screenshot,
personal collection.
46
The selectable features available on Proteus are:
Deselect – Deselect an object/room/wall/floor
Delete selected – Delete an object/room/wall/floor
Snap ON/OFF – Snap to the grid while moving, on or off
Add Room – Add a generic square room onto the scene
Add Wall – Add a wall into the scene
Add Floor – Add a floor into the scene
Objects – Open the objects panel. When you click an object, adds it to the scene
Move – Move an object/room/wall/floor
Rotate – Rotate an object/room/wall/floor
Scale – Scale an object/room/wall/floor
Set Name – Set a name for a room
Colour Panel – Set a colour for an object/room/wall/floor
Texture – Set a texture for an object/room/wall/floor
2D View – Switch the view to 2D top down view
3D View – Switch the view to 3D topside view
Ship View – Switch the view to zoomed out view of deck
Blueprint ON/OFF – Turn architectural blueprint ON/OFF
Grid ON/OFF – Turn measurement and snap grid ON/OFF
Light ON/OFF – Turn the general lights on ship ON/OFF
Play/Stop Tide – Play or stop tide movement of water (speed and angle adjustable)
Create Mission – Opens up the mission panel. Click an object or room, set it as a goal, and start
the mission
Chat – Type messages that appear on heads of avatars/NPCs in the scene when player meets
them
Deck 1/Deck 2 – Switch to Deck 1 or Deck 2
The automatic features on Proteus are: Automatic user path-tracking, time and interaction data
logging (which rooms the player visits, which items or characters they have interacted with)
47
The menus reflect the kind of features that can be found in 3D software, but simplified. 3D
software is usually very expert orientated, with complex features, and I wanted to take only the
most simple and useful features for the purpose of interior designing with premade objects. I
have many years of experience using Photoshop, a popular image editing and painting software,
and wanted to create a similar kind of menu interface where all the buttons were very selfexplanatory. In the same way, I wanted the learning experience of using the software to be
exploratory, in the same way I learnt how different Photoshop features would work by just trying
them.
All these features were planned and developed, with the underlined items being exceptions, due
to limited time or difficulties with scripting:

A editable deck

Convert 2d map to 3d walls

Move and scale feature for walls

Changing wall colours or wall papers and flooring from a palette

Glow/outline around selected wall

Recording the player movement during the test, coordinates and time - Drop invisible
arrows/points and display top view of map and lines when mission ends

Ability to scale object sizes

Player can navigate with d pad on PS move

Designer can navigate 3d map with arrow keys

Move and scale for objects

Designer interface: Zoom in, zoom out, scroll map

Designer can create a mission for the player and display it onto the player screen

Designer can switch view into 2d or 3d
48

Designer can left click on a wall to select it, then the palette options show up to change the
colour, or dragging on the wall edge will resize that corner

Mission mode – Designers set a mission or target for the player, and the players navigate and
explore the environment in VR to meet that target

Avatars/NPCs

Chat feature – Communicate with avatars/NPCs

Exit signage and general signs
After a discussion with naval architect students that contributed their thoughts about what else
they would like to see in this tool, a tide simulation feature and an architectural cruise ship plan
was added (see Fig. 15 & Fig. 16).
Fig. 15. Deck layout designed by Rosen Jurgen, personal collection.
49
Fig. 16. Premade deck design by Jurgen Rosen, naval architecture student, inside the Proteus
software, personal collection.
50
5. Evaluation of the Project
5.1 Test Planning
The first alpha software was developed over seven weeks, with feedback from persons involved
in the project and feedback from industry personnel before experimental, lab-based user testing
audience was done. Main focuses were functionality and checking all the features were working,
and implementing new features. This took time right up until 23rd of August, 2013, which was
the day of my user testing. I aimed to design a user test study that analysed the usability and
functionality and feedback for the concept of the two frontends of the software:
1) The test user interface via the PlayStation move devices, headset, and screen
2) The designer interface to build a test environment
I wanted to see how users would interact with both interfaces. The tests were planned to be
independent of each other. An additional feature I wanted to test was a voice to text chat feature,
wherein the players spoke to the avatars in the game, and the avatars would “speak” back via
written dialogue which would appear above the avatars head.
Test 1 was designed as a simple task to find something, seeing how well the navigation works.
The room design was not complicated, and players needed to use either simple navigation skills
or a combination asking questions and navigating according to the answers given by the people
on the ship. The answers were devised to be improvised answers of the characters on the ship,
depending on the question asked by the test user. Most characters on the ship would be helpful,
but as not everyone knew about the missing laptop, not everyone would help with the
whereabouts of the laptop, just like in a real life situation when one loses an item. Both user tests
and surveys were designed to be completed in fifteen to twenty minutes. Test users were
scheduled half an hour apart starting from noon until 5:30pm, with a one hour break for myself in
between.
51
5.2 Test Outline
The DECIDE framework (see Preece, Rogers, & Sharp, 2002, p. 348–357) was chosen to guide
the design and evaluation of this test, because of its clear structure for the practical and ethical
issues of running a test, and the clarification of goals and questions that need to be answered.
DECIDE stands for Determine, Explore, Choose, Identify, Decide, and Evaluate.
1. Determine Overall goals
My overall goal of the testing is to determine if the design of the program and setup was intuitive
to use, and whether all necessary and useful features were included.
2. Explore the questions
Does this tool offer the features needed for ship architects to build their designs realistically
enough to use for user testing and viewing? Does it have the features to adequately test their
designs? How is the user experience in this software? Is it easy to follow?
3. Choose the evaluation paradigm, and technique
The “usability testing” paradigm was used (Preece, Rogers, & Sharp, 2002, p. 347). Tests were
conducted for typical tasks in a lab setting, and video and interaction logging, including time
taking, was used, as well as collecting answers on user satisfaction by questionnaire
4. Identify practical Issues
Finding the right audience for the testing, i.e. people who will likely use this tool in the future, or
are already involved in the industry where this tool is used. It was not possible to find test
subjects from the industry only, so from the results, I had to work out how to interpret data from
participants ranging from students in marine technology, to professors, to industry personnel, to
workers in other industries. Overall, I wanted the design simple enough for a non-industryspecific or architecturally trained person to be able to operate, so the test audience sample was
fine for that purpose, but it would have been interesting to have more samples from the marine
technology field too. I identified the biggest obstacle to interpreting the data would be if a
52
recruited tester had no previous experiences with using computer interfaces or graphics software,
so I made it clear that they should indicate what kinds of software they have used, how proficient
they are at it.
5. Decide on how to deal with ethical Issues
The ethics guidelines (Preece, Rogers, & Sharp, 2002, p. 353) were mostly accounted for, in
particular, the ethical issues involving collection of data and use of names. Users were given a
choice to remain anonymous or use a pseudonym, consent was asked for video recordings and
photography, age can be given but not necessary (see Appendix A and B). It was explained to
users that the information will be confidential to the researchers only and written about within the
thesis on a research basis and not published elsewhere. Also names would not be used in
describing the test users within the research publication. Users were also offered refreshments
and snacks before or after testing.
6. Evaluate, interpret and present the data
The data and numbers were analysed post testing from the questionnaire submitted by the test
users during that day, to find any correlations or important comments from the test users.
5.3 Test Implementation
Possible issues with user testing according to Bowman, Kruijff, LaViola and Poupyrev (2005, p.
362 – 367) were identified before testing so that the test would try to minimise these issues.
Issues such as being aware not to affect the test users sense of presence in the virtual world, for
example by not casting shadows on the projection or interrupting the user. The experimental
application should be bug-free. Instructions must be so detailed that the user understands the task
before starting so as to not break the immersion and concentration and presence during the task
by asking questions. Hardware should be checked upon because 3D UI may be less robust than
traditional UI hardware (p. 363). Due to multiple streams of user input, a video recording was
also set up to reflect on user behaviour and user actions during the test, because it is hard to
observe all the multiple streams at once (head movement, hand movement, button inputs, etc.,).
To minimalise simulator sickness occurrences, the tests were designed to be short, both the
design and virtual reality navigation tasks were designed to be around 10–15 minutes maximum.
53
During the early and mid-stages of developing the software and interface, I used the user-centred
development methods described by Preece, Rogers, and Sharp (2002, p. 279). User observations
and interviews were used during the concept stages, by a visit to the currently most advance short
distance cruise ferry operating in Finland in terms of interior design, the Viking Grace. The
Viking Grace’s interior is designed to shift during the day and night to create different ambiences
(Vikinggrace.com, 2013). Passengers were observed and interviewed during the day about what
they like about the design and what they did not like, and what more they would like from a
future cruise ship. By the same token, I also interviewed the interior designer for this ship, Vertti
Kivi, about what kind of software he uses for design, and explained that I was developing
software within my university project which was to aid cruise design through a virtual reality and
game interface.
Test users were selected from students and friends over the age of eighteen. No preference for
gender was taken, therefore anyone who wanted to participate in the test was welcome, and there
was no rebalancing due to gender due to the limited pool of users available to test my demo.
“Quick and dirty” evaluations (Preece, Rogers, & Sharp, 2002, p. 341), meaning informal
feedback, was done during the both the concept design and prototype and demo of the software
and interface. Think-aloud technique (p. 365) was used in the ship design task one so the user
could explain any difficulties they encountered while running through the familiarisation task.
The data equipment used was a timer for all tasks, and notes plus video for the think-aloud task.
The video was aimed from the back of the user as not to be intrusive, and to observe their actions
and behaviour inside the designer interface and the VR interface, not their facial expressions. A
questionnaire was designed with a question and response format (p. 400). Users were asked to
respond with discreet answers, ranges, free-form answers, and Likert scales (see Appendix C and
D). The results were then collated and later analysed for time taken to perform tasks, and the user
feedback given for the tasks.
For test 1, the navigation task, was a small game. The player was introduced to the environment
and the setting. Because it was a VR setting, I had to take them through a method of introduction
based on the “phases of virtual experience” as defined by Steed et al. (2002, p. 2–5) in this order:
54
1. Instruction – A short introduction to what will be happening and tested upon
2. Entry – The entry into the environment, both the physical and virtual space of the demo
3. Boot-strapping – Where the player learns the controls
4. Main Experience – Once the player is familiar with the controls, they will proceed to the
main task or main experience
5. Exit – Jumping out of the virtual and physical space and back to the real world
Instruction was first given as a small explanation of what would be happening. I explained that
the virtual environment will be set on a cruise ship, and that they would be wearing a device on
their head for tracking their head movements and using a controller to navigate, and that I will
give them a navigation task. I proceeded to guide them to the allocated spot in the area where
they should stand (Phase 2, ‘Entry’). I assisted to put the headgear on and calibrate it, along with
asking the participant to calibrate so that the horizon line is horizontal.
After the player had become comfortable with the controls, I gave them a task. The task was to
find their laptop, that they had lost somewhere on the ship. They could search for it in any way
they liked, and I made a point that there are characters on the ship that they could ask for help
from, and made emphasis they should try to talk to those characters if they see them (it was not a
requirement, but it would give me good feedback for the designer-player communication
roleplaying system I had designed). When the task was complete, I congratulated the player for
finding the laptop, and I stopped the timer on the task, and recorded times into their reply survey
for analysis later.
It is noted by Steed et al. (2002, p. 3), that the smoothness of transition between these five phases
is essential to the experience of “presence”, that means, for the user not to break out of immersion
or the context. It was also noted that the more freedom in the environment, (aka open world or
VR experiences), the more instruction is needed before the experience for the controls etc.,
because otherwise the user would be lost or disconnected from the context (p. 3). The aim of the
design of a VR system is that the transition between the real world environment and VR
cognitive model and experience is at the same time as when one enters the VR environment. Any
55
kind of disconnect or discomfort or confusion is referred to as a “jump”, and the design of a VR
system aims to reduce the amount of “jump” or discomfort in the transition (p. 3). After the
initial instruction, there should not be a need to explain further, otherwise the player loses
immersion, and design-wise, it shows that the controls were too complicated or counterintuitive.
Finally, test users were asked to fill the survey of their user feedback and user background (see
Appendix A and B). The survey was designed to cover basic background questions and then ask
how the users felt about using the interface in terms of ease of use: what were the difficulties,
and what could be improved.
5.4 The Tests
Participants
Test users were recruited via Facebook, email, and phone. Participants were recruited from direct
contact or through an announcement on the university forum, out of friends and fellow students.
There were five participants for the virtual reality navigation task, and eight participants for the
ship design task. Users were tested one at a time.
Time
Testing commenced from noon until six-thirty in the evening, and test users each had a maximum
of 30 minutes for testing, given two tasks each.
Organisers and test personnel
My role was to organise, lead and direct the user trials, while assistant and programmer Felipe
Marjalizo set up the hardware during the day of the user testing.
Facility and setup
The facility was an auditorium with dimmable lights, complete with two large walls and four
projectors which made up our immersive projection technology (IPT), alongside PlayStation
move controllers and the detection system for player control. One projector was malfunctional
56
on the day of testing, so we tested without stereoscopic enhancement. We calibrated the
PlayStation 3 and PlayStation controllers units before the formal survey response testers came.
We tested the software and setup with one informal tester to check that the equipment and setup
was in order. A designated standing area was marked by orange Post-It notes.
Test Method
Test users were given a quick explanation of the aims and setup of this test. The aim was to test
the usability of the design interface and the virtual reality user testing interface. It was explained
they would be given a series of tasks to test this. It was also explained if they wanted
refreshments they can feel free to take some before or after the tests, and also that they may quit
the test at any time. Test users were asked if permission was granted for photography and video
to be used for analysis and thesis publication.
Fig. 17. Allocated standing area, personal collection.
57
Fig 18. Attaching tracking headgear inside the Upponurkka, personal collection.
Users were asked to step into the environment marked with the yellow Post-its (Fig. 17). I or my
assistant, helped the test subjects to attach and adjust the headgear: a PlayStation move controller
attached via elastic and head casing (Fig. 18).
The test users were asked to move the controller on their head until their viewing horizon was
even. This calibration process took only 20–30 seconds. I explained what the controls do, that
the up button on the controller was to move forward, left and right were for turning, and down
was walking backwards, and that the view was controlled by which way their head was facing. I
explained they could also crouch and jump but it would not be needed in the task. In the next
phase, bootstrapping: players learnt and adjusted to the controls. It is meant to be intuitive, and
for most players it was. I let the players walk around a while and waited to see if they have any
problems with the control before starting the task. In most cases, it took only 10–30 seconds that
they could use the controls fluidly.
58
5.4.1 Test 1 Virtual Navigation Task
Once I had introduced them to the VR environment using the phases of virtual experience defined
by Steed et al. (2002, p. 2–5) as described in Section 5.2, I explained the scenario. The setting
was a cruise ship, and the situation was that they had lost their laptop. They could use any
possible means to find it, such as asking for advice from other people they see around the ship, or
just looking around by themselves. I encouraged the test subjects to talk to some people (avatars)
if they see them, and I explained they could just talk to these avatars with their voice.
5.4.2 Test 2 Ship Design Task
The ship design task was divided into two parts. The first part is an introduction and not a test.
Test users were introduced to software via a series of tasks (see Appendix G). Part 2 of Test 2
was to recreate as closely as possible, the blueprint of the ship I drew, complete with notes on
wall colours, carpets and signage (see Fig. 19).
Fig. 19. Design task, personal collection.
59
5.5 Results
The results are divided into two different tests: A ship design task (for the desktop software) and
a virtual navigation task, which was in a lab setting in front of a two wall projection system.
Ship Design task
Most users were between 26–42 years old, and 38% of users use AutoCAD, Photoshop, or 3d
software frequently, a quarter had never used any of this software, and another quarter use it only
occasionally. Most (63%) were not involved with marine technology at all. 63% of the users
played videogames one to five times a week.
63% of users ranked the software interface for designing “Mostly easy to use, with some
problems”, and 37% marked “Most things are easy to use”. No one marked “Very easy to use”
or “Very difficult to use”, so I assume the are some problems still to be improved for the interface,
but the overall layout is intuitive. The most frequently mentioned problems were the naming
function, and scaling function (Appendix E). The ship design task questionnaire is in Appendix A,
full results are in Appendix C, analysed feedback on Appendix E.
Virtual Navigation task
Most users were between 26–34 years old, and 40% have never used AutoCAD, Photoshop, or 3d
software, 40% use it occasionally. A quarter had never used any of this software, and another
quarter use it only occasionally. 100% of the users were not involved with marine technology at
all. 80% of the users played video games one to five times a week.
40% of users ranked the software interface for designing “Mostly easy to use, with some
problems”, and 40% marked “Most things are easy to use”, and 20% marked “Very easy to use”.
The tasks were ranked by 80% as “Relatively easy, minor problems”; while 20% found it “Very
easy”. The average time taken to complete the task was around 4 minutes. The ship design task
questionnaire is in Appendix B, full results are in Appendix D, analysed feedback on Appendix F.
60
5.6 Discussion and Improvements
The time taking and questionnaire results support the idea that the interface was generally easy to
use. It did not take very long to complete a task: The users completed the user navigation task
on average in four minutes, and 80% found the task relatively easy with only minor problems.
The tests on Upponurkka ran smoothly: there were no occurrences of sickness while testing with
the large projection screens with test users, but the developers and people involved in the Proteus
project, including me and Felipe Marjalizo, occasionally experienced simulator sickness from
testing our project in Oculus Rift later on. The walking and turning speed on the control setup
was crucial because it was noticed that quite a proportional amount of simulator sickness
occurred when the walk speed was not in-sync with player expectancy
During the design and testing, I had decided that navigation data, such as position points of the
player and the time taken to get between points, would be interesting data to automatically collect.
It was after showing the demo, I was given feedback from the teaching department of the marine
technology and urban planning departments at Aalto University that leaving audio notes that
could be revisited within the virtual ship model, would be a useful tool for them. Due to the strict
period of time available with the programmer for this project, it was not possible to create this
within the timeframe, but it is noted as something that would bring a vast improvement to the
usefulness of this tool, when the stakeholders and the people who need to discuss the design are
not in the same room, and that they can send these projects to the other designers/decisionmakers, and they can just browse the ship and listen to the audio notes and drop their own notes
as replies.
I had decided early on to make a rapid design and user testing tool, where the designer can flip
between a design editor and a running version of their ship/scenario, much like in Unity and other
game editors, and we successfully implemented that. But what we actually found we had coded
allowed the designer can make ‘live’ changes to the scene, like a game master. So instead of just
speeding up the transition between designing and testing, we had made it almost simultaneous:
The player/test user could immediately tell me, as the operator, what is wrong with the design
and how I can fix it. A player can tell the designer or operator that they do not like the wallpaper,
or the position of a couch, and the operator can adjust it in real time, right in front of their eyes.
This feature could actually be much faster for development than running isolated tests. Of course,
61
I have left the feature in there to run tests because at times it is better to let the test user be
undisturbed while they experience the environment and are absorbed in being there, or presence.
I am happy about the flexibility we built in, which meets the aimed objective of building a
platform for different participants to communicate and share upon: A multipurpose, visual,
experiential ship design and testing tool.
Also included near the end of development was a system for live and improvised role play of
situations. Some human models were included into the objects panel in the design menu, so that
designers can place multiple characters on the ship to act as guests, cruise personnel, and so on.
It could be used to simulate the kind of interactions that happen on-board: to see if cruise
personnel are easy to find or easily identifiable, if they can help passengers navigate and find
things more quickly in comparison to signage, and so on. Unfortunately there was no time to
add very detailed or realistic looking models, and right now serve as more as a placeholder. The
human figures are missing animation and AI walking or idle behaviours, and that would be an
improvement in the next release. Currently the operator has to actively follow the player to see
which characters they are close enough to talk to, but in further development, the chat box can
automatically switch to the closet character to the player. Simulating “real” scenes with hundreds
of passengers on a deck at once can still be very tricky to run in real time, because of AI and
processing power for graphics, but in the future maybe this will not be a problem.
During research and testing, I realised the limits to what my virtual reality design tool can
simulate. At the moment, it cannot simulate the feeling of textures and carpets, nor can it
simulate the ambiance of a lively ship deck, with all its people and chatter, though technically, it
is quite possible to simulate the sounds and ambience on the deck. It is possible to even get
sensory gloves that can create sensations in the hand that make people feel similar to textures,
although I have only read of this and have not tried it. However, the visuals and the feeling of
space was enriching and immersive in my demo, and that was useful for testing visual and layout
changes to the interior. The things that could be tested fell into categories such as testing whether
the navigation on a floor plan is confusing for the player/passenger and whether they can see exit
signs and other signage well enough. The “live” design system gives an easy way to work out
how large these visual aids should be and adjust at ease. In that sense, I think I have been
successful in building some of the useful features that are missing in a lot of CAD related design
software which is missing interactive testing features
62
The current prototype, as software, still needs improvement on many levels, such as improving
the user interface, which due to difficulty scripting, can be slightly confusing without help
bubbles on hover, such as the “create mission” button, which will be a pretty unfamiliar term and
concept to ship architects and interior designers since this comes from game design terminology.
In retrospect, I could have named it something more familiar such as “User Testing” or “Create
User Test”. I had inadvertently forgotten that the users were most likely not game designers.
I am happy with the number of features I managed to develop in the short time: practically
everything on my initial list. There was one very useful feature I wish was there – the ability to
automatically convert a 2d map into 3d walls, but this was too technically challenging for
programming in a short period of time. There were other similar cases where technical and time
restrictions diverted functionality slightly, albeit the feature still worked: the selection outer glow
became just a middle glow; scaling by dragging corners became scaling by dragging edges.
Since the Upponurkka dual-wall projection setup was not portable or replicable elsewhere
(without great expense and time), the project was ported to Oculus Rift. Due to limited
development time and many time consuming tasks such as manually calibrating the correct height
of the camera, and walk speed and turning speed, it left very little time to develop the textures
and modelling, which I think look considerably worse inside Oculus Rift in comparison to a wall
projection. More time, and a visual designer, could have improved the visuals of the Oculus Rift
demo. We did not have a separate artist or designer working on the project, so all the 3D models
and textures were contributed by me and my programmer. There are some things in the demo I
am not really satisfied with, such as the look of the doors. All the furniture contributed by the
naval architecture student had to be removed from the demo, because the detailed models had so
many vertices and details, would make the project extremely slowly to the point of being
unusable. This emphasises the disconnection between architectural modelling and realtime/game modelling that was mentioned earlier, in that some of the processes made for
architectural builds are really not suitable for virtual reality testing. Virtual testing needs things
that are on scale, that have good texturing, that look right, but they also need to be simplified or
smartly modelled to be low polygon, small in data size, so that it can run smoothly in a VR
environment.
63
Fig. 20. Trails connecting the paths that the player has explored
I think the “live” map of the player position and trails was a successful feature (see Fig. 20). It
became a visualisation of how people navigate, especially when it is visualised live, during the
testing, on the designers screen. A problem is that the map can start to get messy, but it could be
easily fixed with a reset feature for the display lines. The frequency of the marker points can be
manually set, so for more accurate paths, the drop rate can be much higher, while for a more
general feeling of where a cruise passenger ruminates over longer periods, a less frequent drop
rate can show that. All the data from the player’s movements also goes to a text file, so that
analysis can be made from that data too. At the moment in the demo, the text data is not userfriendly enough, because the text file is accessible only from outside the software and it is not
searchable by specifics. It would be nice to develop this future so that everything can be done
inside the design too, including accessing the data, visualising it with graphs, etc. The second
way to map or record user experience would be a built in screen capture video that actually sees
through the player’s eyes what they do through the whole “mission” or testing session. There
must be other data that could be recorded, like test user preferences for colours, or the test users’
facial expressions that could be analysed through the Kinect, to analyse what body language says
about designs users walk through. All these ideas were possible to implement, but would have
required a longer development time, so they were not pursued.
64
Table 6
Features in current version of Proteus by user group
Test User
Designer

Editable deck

Navigate on deck using a controller

Move and scale feature for walls

Open doors

Changing wall colours, wall papers and

Talk to virtual avatars/characters
flooring from a selection palette

Finish missions by finding or visiting

Add objects

Chat to player

Turn lights on and off

Selection glow on object

Recording player movement during the
test, coordinates and time (Drop
arrows/points every 10 secs visible only to
operator), and display top view of map and
lines when mission ends

Switch floor plan on and off

Ability to scale object sizes

Designer can navigate 3d map with arrow
keys

Move and scale for objects

Designer interface: Zoom in, zoom out,
scroll map

Create a mission for the player and display
it onto the player screen

Switch view into 2d Top down or 3d, or
free rotation
objects or rooms

Travel in elevators

Experience tide simulation and perhaps
nausea
65
Looking at Table 4, the designer had many more features to use than the player, and in the future,
to test more complicated scenarios than just walking around and finding people and rooms, the
test user can have more possible actions, like an inventory to carry and select. This was one of
the features we did not have time to build. Also, if it was made into a longer game or test
scenario, the player themself could choose “missions”, just like a real passenger on a ship, that
they decide for themself what they want to do, like “go to nightclub”, or “find the captain”. It
would give interesting insight on passenger behaviour and passenger wishes during cruise travels.
It would also be interesting to add a clock and time of day, so that the environment and people
would change during the virtual day and night on the cruise ship.
One of the problems with testing an alpha version software on real users, is that they expected
complete and smooth functionality even when I explained it was in early testing phases, as
anticipated by Bowman, Kruijff, LaViola and Poupyrev (2005, p. 362). Most of the feedback
about problems with the interface and usability are about known issues or unfinished features.
The time frame seemed realistic for the project, even though we included or tried to include,
many features, but many times when the programmer fixed one error, there would be some kind
of conflict causing another error. It was quite hard to predict how long each error would take to
fix. Some were simple, some were more time consuming. However, it was useful to gain new
suggestions, and also to map out the complaints during user testing by number of mentions to see
where the most critical problems are. The things that were incomplete were either due to
problems between the code and the unity engine, or the allotted project time budget. The first
step to improving the usability of this software will of course be to fix these bugs with a new time
budget and plan. New features would be voice based chat, and possibly audio notes left in the
virtual environment, which was an idea that came up while discussing ways for architects to
leave notes on the virtual model. Most 3d applications, such as architectural walkthroughs, only
provide symbolic output (Bowman, Kruijff, LaViola Jr., & Poupyrev, 2005, pp. 287–288), in the
form of text, numbers and speech within the environment, but does not provide symbolic input
features, but design annotation would be a very useful feature.
The most interesting suggestions were for the virtual reality interface. Some of the players
frequently referenced other games as to what they expected for the controls and environment, for
example the reference to “strafing” (See Appendix D), which is a term used mostly in first person
shooter games and war strategy type games where the people walk sideways when you press left
66
or right instead of turning. Perhaps “strafing” is the default of how gamers expect controls to
behave (80% of the test users were regular gamers, playing from one to five times a week), while
differing from ‘realism’, for example, in real life while I am walking, I usually never “strafe”. In
realistic driving games, there is also no strafing. It is possible that I would need repeat the test
with non-gamers, to find out how many would see strafing as the natural outcome of pressing left
or right, and how many would see turning and rotation as an outcome.
The collaboration between UI and game designers (my role), ship architects, marine technology
industry personnel, and a software engineer was very interesting. My role was basically the hub
between these three different kinds of roles, and I acted like the control centre for what feedback
and what inputs to give to each three (see Fig. 21).
Fig. 21. Game designer as the hub between other actors, drawing.
With the knowledge from all four, we were able to build something that crossed over between
each field. The actual software could be improved on greatly and further developed, but I think
the most successful part was the cross disciplinary collaboration and applying game design
67
techniques and ideas to solve problems within other design disciplines which previously did not
have much relation.
Secondly, I noted that game environments enable people to switch their conceptual models
quickly to the virtual or game space. Players are easily able to remove themselves from “reality”
or the physical conceptual space, into a digitally constructed and non-physical space designed by
the game-designer, similar to the stairway study by Turner and Turner (2006). Even though were
not able to fully supply the demo with as many textures and objects as there would be on a real
ship, many players remarked that it felt like a ship right away. It is interesting to note that the
clearly defined virtual space and borders really enhanced the concept of magic circle that we see
in gaming, and as described by Huizinga (1949, p.10), in comparison to many normal user testing
scenarios such as product testing or viewing of images or models where we do not ask the user to
enter the actual virtual space in which the game/product/concept is set. Commonly user testing
involves inviting a single test user to a room where they are asked questions about a situation
which they face, but evidently there is a difference between asking how a user would act if they
are in such a situation, and the kind of environment and context they are currently in, which is
that they are in a room with a researcher/research assistant asking questions. For my own
experimental condition, I saw the value of leaving users alone in the scene as if they were faced
with that situation in reality without a researcher there. It was only after the experience I asked
them to reflect on the experience through survey questions, and I did not interrupt their playing
experience unless there was any big issue which there was not, or if they had a question. I was
happy with the success of the magic circle effect, even when I had marked the Post-It note area
on the floor more for technical reasons such as camera tracking than for the magic circle, but it
worked as both.
68
6. Conclusions
The overall goal was to design a functional tool for cruise experience design to be used by
designers of different disciplines (such as interior design, industrial design, and service design)
who are involved in the design of cruise ship interiors and services. The aim was to merge design
and user testing in one application, to enhance the interactivity between users and designers in the
piloting process of the new design ideas. To this extent, I'm happy with the prototype I was able
to create within the resources and span of time I was given, but there are many more features that
I would like to see in the future, but did not have time to complete, such as the automatic 2d
blueprint to 3d model conversion, and additional interactivity such as more complicated missions
and object inventory for the player. I focussed mostly on the functionality and the basic user
interface, but managed to included nearly all the planned features, and answer the research
questions I had about how to map and visualise user experiences, and how to make a platform
that can quickly transition between designing and testing. There were some questions that were
technically harder to answer, such as what method to use to convert a 2d map into a 3d model,
and it was quite a big idea that was beyond reach of the small time frame we had to develop this
tool.
The usability testing framework that I had derived from Preece, Rogers, and Sharp (2002, p.347)
worked well. Using a controlled and well defined laboratory setting with video, time logging,
and questionnaires, made it easier to analyse the results later. I was also the test operator, so it
would be difficult for me to observe or analyse everything at the same time or write my thoughts,
but it was much clearer having their thoughts written to me. I was happy with the test results,
although there were some technical issues which meant there was no stereoscopy during the test,
so I couldn’t test for simulator sickness very much. On the brighter side, since no-one felt sick in
my tests its suggests the two-wall cave setup without stereoscopy does not make subjects dizzy in
short time intervals such as 5–10 minutes of time in the space.
It was difficult to benchmark games in terms of UI and features because some of the games were
released so many years ago that they could not run on my current operating system and I had to
analyse the games through videos. Generally, it is easier to list the features of software than of a
game, as a game might have several key gameplay features, but may have other features that you
69
cannot see or experience in the first few minutes. Games may take some time to experience and
explore to deeper experience and analyse its systems and features, so during benchmarking, I
could not spend enough time to finish or know the game very well, but I took only the key
features and ideas I saw from playing the game briefly.
In hindsight, my role included a lot of project management which added time and planning
stressors to my overall work load, but in a way, it gave me the freedom and responsibility to
really plan the application and how I wanted it to function. There was a team of ship engineering
students that gave input into the project, one month before it finished, and I wished it could have
been sooner because many features could not be changed by then, and the overall structure of the
deck had to be made again, but there were some useful features that were included based on their
suggestions. Overall the management task was the most difficult. My colleague was working on
the programming tasks for the project at night due to other responsibilities in the daytime, so it
meant there were difficulties with task management and communication sometimes, due to the
limited opportunities to communicate. When we did meet face to face, and explain the progress
and development through drawings and hand signals, much more progress was made. Written
directions can be easily misinterpreted without diagrams and verbal explanations.
Future research could focus on more symbolic input and output, and to be able to record the
symbolic input (right now, the test user can speak to the game master/test operator, the game
master can type back, but the feedback is not recorded). I would like to get the ship industry
more involved with the project so that the features can be standardised so that it is practical for
different designers within that field to be able to use it and have the features they need, that
features for both engineers and more aesthetic designers, such as interior designers, can work
with the same application.
In terms of game design, I found it a tight balance between delivering a product that would be
functional and streamlined, versus having many fun, or “entertainment” based features. Maybe
the hardest role was to have to choose between the role of a game designer and that of an
industrial designer. In retrospect, I applied many tools and elements from game design and found
that there was a great opportunity for “fun” inside serious applications. During the testing of the
software, I and my software programmer saw the many “fun” possibilities for what we had
70
actually created, which was basically in game design speak, a real-time level editor, that is, a tool
that can modify a level while the game is running. I was operating the tests as a live “dungeon
master” (DM), a concept that comes from the 80s roleplaying culture of Dungeons and Dragons
(D&D). A dungeon master was the creative mastermind or storyteller or moderator during a
D&D. A game session would be based on a backstory provided by an official game booklet, but
practically a dungeon master would be modifying the game and story depending on the situation.
The DM could tune the game to suit the players. During our pre-test sessions, we found we could
move objects around like a poltergeist, or make it easier for a player by moving objects closer to
them, or directing them to a location by moving objects or moving characters. I felt like we
found some interactive features that should be in ‘serious’ or ‘industrial’ software, but has not
never seen in industrial software due to the absurdity of the idea.
The whole notion of ‘seriousness’ also has the implication of lack of interactivity and dual
feedback. Even in the case of games, it is a very formulated and strict system of when a player
can create input: for example, when they type their name into the system, say yes or no to
questions. Moreover, I find myself moving towards exploring a more fluid system that would
allow a player to give input whenever they want to, with an intelligent system that would adapt to
the player’s input and wishes. I imagine that environments will be more based on self-learning
artificial intelligence, with an environment that will learn and reorganise itself to suit the user. It
is far into the future, but I see the merging of all these different design fields that would create a
richness and fluidity and flexibility that is missing in most industrial software.
The future I see for both cruise design and game design is the ability to absorb and integrate the
best practices, technologies and tricks from other design fields to improve the practice of design
overall.
71
7. References
Aalto University (2011, December 21). Cruise & Ferry Experience - Department of Applied
Mechanics - Aalto University. Retrieved November 8, 2013, from
http://appmech.aalto.fi/en/research/marine_technology/cruise_ferry_experience/
Ahola, A. (2011). Creating a consumer-driven business model for the cruise line industry: Case
Royal Caribbean Cruise Lines Ltd. Retrieved from
http://appmech.aalto.fi/en/research/marine_technology/cruise_ferry_experience/research/pu
blications/econ_thesis_2011_anni_ahola.pdf
Agnew, R., Killalea, H., & Simpson, M. (2012). Destination Visitor Survey Strategic Regional
Research – Western Australia: Evaluating the WA cruise visitor experience. Retrieved from
(http://www.tourism.wa.gov.au/Publications%20Library/Infrastructure%20and%20Investme
nt/Cruise%20shipping/WA_Cruise_visitor_experience.pdf
Amazon (n.d.). Move controller compatible [Photograph]. Retrieved from http://g-ecx.imagesamazon.com/images/G/01/videogames/detail-page/B002I0K6X6.03.lg.jpg
Birch, C. (2010, December 2). GameInternals - Understanding Pac-Man Ghost Behavior.
Retrieved from http://gameinternals.com/post/2072558330/understanding-pac-man-ghostbehavior
Blazing Griffin (2014). The Ship on Steam. Retrieved April 9, 2014, from
http://store.steampowered.com/app/2400/
Bowman, D. A., & Mcmahan, R. P. (2007). Virtual Reality: How Much Immersion Is Enough?
IEEE Computer, 40(7), 36 - 43. doi:10.1109/MC.2007.257
Bowman, D. A., Kruijff, E., LaViola, Jr., J. J., & Poupyrev, I. (2005). 3D user interfaces: Theory
and practice. Boston, MA: Addison-Wesley.
Brathwaite, B., & Schreiber, I. (2009). Challenges for game designers. Boston, Mass: Course
Technology
Compare Database (n.d.). Countries Spending Most On Console And Computer Game - World
Top Ten. Retrieved September 12, 2013, from http://www.mapsofworld.com/world-topten/countries-spending-most-on-console-and-computer-game.html
72
Cruise Market Research: Growth. (2013). Retrieved May 2, 2013, from
http://www.cruisemarketwatch.com/growth/
Draper, M. H., Viirre, E. S., Furness, T. A., & Gawron, V. J. (2001). Effects of Image Scale and
System Time Delay on Simulator Sickness within Head-Coupled Virtual Environments.
Human Factors: The Journal of the Human Factors and Ergonomics Society, 43(1), 129146. doi:10.1518/001872001775992552
Huizinga, J. (1949). Homo ludens. Retrieved from
http://art.yale.edu/file_columns/0000/1474/homo_ludens_johan_huizinga_routledge_1949_.
pdf
Its Art (n.d.). Unity 3D 101. Retrieved from http://www.itsartmag.com/features/itsart/wpcontent/uploads/2013/05/unity-3D.png
Kenyon, R. V. (1995, November). The CAVE Automatic Virtual Environment: Characteristics
and Applications. Retrieved April 8, 2014, from
http://www.cs.uic.edu/~kenyon/Conferences/NASA/Workshop_Noor.html
Kühnapfel, U. G., Kuhn, C., Hubner, M., Krumm, H., Maass, H., & Neisius, B. (1997). The
Karlsruhe Endoscopic Surgery Trainer as an example for virtual reality in medical education.
Minimally Invasive Therapy & Allied Technologies. doi:10.3109/13645709709152715
Kolasinski, E. M. (1995). Simulator Sickness in Virtual Environments. Retrieved from
http://www.dtic.mil/cgibin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA295861
Lies and Seduction (2009). LIES and SEDUCTIONS. Retrieved April 9, 2014, from
http://www.liesandseductions.com/
Marine Consulting (2014). Marine Consulting | Training | Software - EAS - Ship Simulator.
Retrieved April 6, 2014, from http://www.maritimelogic.com/eas-ship-simulator.html
Marine Consulting (2013). Marine Consulting | Training | Software - Mission Videos. Retrieved
September 9, 2013, from http://www.maritimelogic.com/mission-videos.html
Magrino, T. (2008). Study - Europe second largest gaming market. Retrieved May 31, 2013,
from http://www.gamespot.com/news/study-europe-second-largest-gaming-market-6191774
73
Merriam-Webster (2014). Proteus - Definition and More from the Free Merriam-Webster
Dictionary. In Dictionary and Thesaurus - Merriam-Webster Online. Retrieved from
http://www.merriam-webster.com/dictionary/proteus
Mine, M. (2003). Towards Virtual Reality for the Masses: 10 Years of Research at Disney’s VR
Studio. Paper presented at International Immersive Projection Technologies Workshop.
Abstract retrieved from http://www.dvschafer.com/files/disney_vr.pdf
Net Resources International (n.d.). Oasis of the Seas Luxury Cruise Liner - Ship Technology.
Retrieved September 12, 2013, from http://www.shiptechnology.com/projects/oasisoftheseas/
Oculus VR (2014, March 19). Announcing the Oculus Rift Development Kit 2 (DK2) | Oculus Rift
- Virtual Reality Headset for 3D Gaming. Retrieved March 28, 2014, from
http://www.oculusvr.com/blog/announcing-the-oculus-rift-development-kit-2-dk2/
Outerlight (2006). The Ship: Murder Party [PC game]. Edinburgh, Scotland: Blazing Griffin.
PlayStation Move Controller [Photograph]. (n.d.). Retrieved from
http://www.conrad.de/medias/global/ce/9000_9999/9000/9080/9086/908681_BB_00_FB.E
PS_1000.jpg
Preece, J., Rogers, Y., & Sharp, H. (2002). Interaction design: Beyond human-computer
interaction. New York, NY: J. Wiley & Sons.
PS4 Home (2013, December 12). Retrieved from http://www.ps4home.com/wpcontent/uploads/2013/12/Assassin%E2%80%99s-Creed-IV-Black-Flag-DLC-Freedom-CryScreenshots-2.png
Quartermaine, P., & Peter, B. (2006). Cruise: Identity, design and culture. New York: Rizzoli
International Publications.
Rouse, R. (2005). Game design: Theory & practice (2nd ed.). Plano, Tex: Wordware Pub.
Rusli, E. (2009, October 15). World's Most Expensive Cruise Ship - Forbes. Retrieved September
9, 2013, from http://www.forbes.com/2009/10/15/most-expensive-cruise-lifestyle-travelship-royal-caribbean.html
Salen, K., & Zimmerman, E. (2003). Rules of play: Game design fundamentals. Cambridge,
Mass: MIT Press.
74
Steed, A., Benford, S., Dalton, N., Greenhalgh, C., MacColl, I., Randell, C., & Schnädelbach, H.
(2002). Mixed-Reality Interfaces to Immersive Projection Systems. Retrieved from
http://www0.cs.ucl.ac.uk/research/equator/papers/mixed_interface_final.pdf
Turner, P., & Turner, S. (2006). Place, Sense of Place, and Presence. Presence: Teleoperators
and Virtual Environments, 15(2), 204–217. doi:10.1162/pres.2006.15.2.204
Tribe Studios (2014). Velvet Sundown : Velvet Sundown. Retrieved April 9, 2014, from
http://www.velvetsundown.com
Zichermann, G., & Cunningham, C. (2011). Gamification by design: Implementing game
mechanics in web and mobile apps. Sebastopol, Calif: O'Reilly Media.