Analysing the E ect of Additional Haptic Information on ...mdv/courses/CM30082/projects.bho/2009-10/... · Analysing the E ect of Additional Haptic Information on Task Performance

Analysing the Effect of Additional Haptic Information on

Task Performance and Personal Experience in a

Tightly-Coupled Collaborative Game

Richard Bowater

Bachelor of Science in Computer Science with HonoursThe University of Bath

May 2010

This dissertation may be made available for consultation within the Uni-versity Library and may be photocopied or lent to other libraries for thepurposes of consultation.

Signed:

Analysing the Effect of Additional Haptic

Information on Task Performance and Personal

Experience in a Tightly-Coupled Collaborative

Game

Submitted by: Richard Bowater

COPYRIGHT

Attention is drawn to the fact that copyright of this dissertation rests with its author. TheIntellectual Property Rights of the products produced as part of the project belong to theUniversity of Bath (see http://www.bath.ac.uk/ordinances/#intelprop).This copy of the dissertation has been supplied on condition that anyone who consults itis understood to recognise that its copyright rests with its author and that no quotationfrom the dissertation and no information derived from it may be published without theprior written consent of the author.

Declaration

This dissertation is submitted to the University of Bath in accordance with the requirementsof the degree of Bachelor of Science in the Department of Computer Science. No portion ofthe work in this dissertation has been submitted in support of an application for any otherdegree or qualification of this or any other university or institution of learning. Exceptwhere specifically acknowledged, it is the work of the author.

Signed:

Abstract

When people work together, they require information about the activity and the environ-ment that they are in. This information is usually obtained by what they see, hear andtouch. This project examines the potential of this touch, or haptic, information to alterthe personal experience and performance of a collaborative activity.

This project shows that the provision of haptic information in a collaborative game yieldspositive benefits to the performance of the task when decisions are made intuitively. It alsoshows that this haptic information influences perceptions of the personal experience of anindividual. These findings are discussed in more detail and further work is proposed basedon ideas extrapolated from this discussion.

Contents

1 Introduction 11.1 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Literature Survey 52.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Haptics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Force Feedback Devices . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Effect of Haptics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.1 Coupling in Collaborative Environments . . . . . . . . . . . . . . . . 15

2.4 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5 Metrics Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Task and Concept Design 203.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Designing the Collaborative Task . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Task Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Selecting the Game Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1 Merging two Existing Concepts . . . . . . . . . . . . . . . . . . . . . 23

4 Game Design 244.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Process Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 Input Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.4.1 Input/Output Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 274.4.2 Force Feedback Mappings . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 Mechanics Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5.1 Enforcing Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . 284.5.2 Cooperative Interference . . . . . . . . . . . . . . . . . . . . . . . . . 294.5.3 Deliberative and Intuitive thinking . . . . . . . . . . . . . . . . . . . 29

4.6 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

ii

CONTENTS iii

5 Implementation 335.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2 Programming Language and Input Devices . . . . . . . . . . . . . . . . . . 335.3 Game Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3.1 Collision Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3.2 Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3.3 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.3.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4 Input Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.4.1 Force Feedback Effects . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.5 Data Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Pilot Study 446.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2 Study Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.3 Study Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3.1 Participant Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.3.2 Experiment Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.3.3 Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.3.4 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4 Results and Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 Main Experiment 527.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.2 Study Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2.1 Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.3 Study Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.3.1 Participant Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3.2 Experiment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.3.3 Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.3.4 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.4 Quantitative Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.4.1 Analysis of Time Results . . . . . . . . . . . . . . . . . . . . . . . . 617.4.2 Analysis of the amount of balls lost . . . . . . . . . . . . . . . . . . . 637.4.3 Analysis of participant score . . . . . . . . . . . . . . . . . . . . . . 65

7.5 Qualitative Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.5.1 Perceived Enjoyment . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.5.2 Perceived Mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.5.3 Perceived Ease of Use . . . . . . . . . . . . . . . . . . . . . . . . . . 697.5.4 Personal Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.5.5 Perceived Ability to Collaborate . . . . . . . . . . . . . . . . . . . . 707.5.6 Perceived Time to Complete . . . . . . . . . . . . . . . . . . . . . . 707.5.7 Perceived Ability to Aim . . . . . . . . . . . . . . . . . . . . . . . . 71

7.6 Discussion of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

CONTENTS iv

8 Conclusions 778.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778.2 General Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2.1 Provision of Additional Information . . . . . . . . . . . . . . . . . . 798.2.2 Task Performance in Visual Spatial tasks . . . . . . . . . . . . . . . 808.2.3 Immersion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.2.4 Objectives and Personal Goals . . . . . . . . . . . . . . . . . . . . . 828.2.5 Relationships and Communication . . . . . . . . . . . . . . . . . . . 84

8.3 Critical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858.3.1 Task Design and Implementation . . . . . . . . . . . . . . . . . . . . 868.3.2 Experimental Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

8.4 Further Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888.4.1 Benefits of Additional Information . . . . . . . . . . . . . . . . . . . 888.4.2 Distributed Tightly-Coupled Collaboration . . . . . . . . . . . . . . 89

A Experiment Screenshots 94

B Ethics Checklist 100

C Consent Forms 104C.1 Pilot Study Consent Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . 105C.2 Experimental Study Consent Forms . . . . . . . . . . . . . . . . . . . . . . 111

D Raw Results Data 142D.1 Pilot Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

D.1.1 Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143D.1.2 Raw Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

D.2 Experimental Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165D.2.1 Experimental Permutations . . . . . . . . . . . . . . . . . . . . . . . 165D.2.2 Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166D.2.3 Raw Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264D.2.4 Analysed Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266D.2.5 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269D.2.6 Observational Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

E Code Listings 276E.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276E.2 Main Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

E.2.1 File: Program.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277E.3 Game Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

E.3.1 File: Engine.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278E.4 Input Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

E.4.1 File: InputHandler.cs . . . . . . . . . . . . . . . . . . . . . . . . . . 293E.5 Data Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

CONTENTS v

E.5.1 File: DataLogger.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . 298E.6 Game Ball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

E.6.1 File: Ball.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300E.7 Game Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

E.7.1 File: Block.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306E.8 Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

E.8.1 File: Player.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308E.9 Score Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

E.9.1 File: Score.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

F Project CD 312

List of Figures

3.1 The initial game concept design . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 The initial interface layout design for the main game window . . . . . . . . 264.2 System components design diagram . . . . . . . . . . . . . . . . . . . . . . . 314.3 The iterative design document for the main game area . . . . . . . . . . . . 32

5.1 Shows how the direction of the ball is changed on collision with a player . . 355.2 Shows how the direction of the ball is changed on collision with a block . . 365.3 The assets for each object in the game . . . . . . . . . . . . . . . . . . . . . 385.4 The force feedback editor program used for effect creation . . . . . . . . . . 405.5 The strength, duration and direction of the ball collision effect . . . . . . . 415.6 The strength, duration and direction of the block collision effect . . . . . . 415.7 Operational flow for the engine . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1 How the experiment area was set up, including approximate distances andscreen sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2 A photo of participants playing the non-force feedback game . . . . . . . . 476.3 A photo of participants playing the force feedback game . . . . . . . . . . . 476.4 Top: The original collision model. Bottom: The revised collision model. . . 51

7.1 Graph of the times taken for the deliberative thinking task . . . . . . . . . 627.2 Graph of the times taken for the intuitive thinking task . . . . . . . . . . . 637.3 Graph of the amount of balls lost by each pair for the deliberative thinking

task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.4 Graph of the amount of balls lost by each pair for the intuitive thinking task 657.5 Graph of the total score for each pair for the deliberative thinking task . . . 667.6 Graph of the total score for each pair for the intuitive thinking task . . . . 67

8.1 The 3 player attitude changing states . . . . . . . . . . . . . . . . . . . . . . 83

A.1 The starting state of the game. . . . . . . . . . . . . . . . . . . . . . . . . . 95A.2 The launched ball state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96A.3 The block destruction state. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97A.4 The multiball state once a grey block has been destroyed. . . . . . . . . . . 98A.5 The blue ball lost state. Red ball lost has opposite effect. . . . . . . . . . . 99

vi

LIST OF FIGURES vii

D.1 Graphs that show the actual time to complete with minimum and maximumvalues. Left: Deliberative thinking results. Right: Intuitive thinking results. 269

D.2 Graphs that show the average time to complete for each type of thinking.Left: With maximum and minimum values. Right: With standard deviation. 269

D.3 Graphs that show the actual amount of balls lost with minimum and max-imum values. Left: Deliberative thinking results. Right: Intuitive thinkingresults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

D.4 Graphs that show the average amount of balls lost each game for each type ofthinking. Left: With maximum and minimum values. Right: With standarddeviation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

D.5 Graphs that show the average player score type of thinking with min maxvalues. Left: Deliberative thinking results. Right: Intuitive thinking results. 271

D.6 Graphs that show the average player score type of thinking with standarddeviation. Left: Deliberative thinking results. Right: Intuitive thinkingresults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

List of Tables

4.1 The mapping of input state to an output state . . . . . . . . . . . . . . . . 274.2 The mapping of input state or action to a force feedback effect . . . . . . . 28

5.1 Description of the subsystems within the game engine . . . . . . . . . . . . 35

7.1 Results of game time analysis for deliberative thinking task . . . . . . . . . 617.2 Results of game time analysis for intuitive thinking task . . . . . . . . . . . 627.3 Results of ball loss analysis for deliberative thinking task . . . . . . . . . . 637.4 Results of ball loss analysis for intuitive thinking task . . . . . . . . . . . . 647.5 Results of total score analysis for deliberative thinking task . . . . . . . . . 657.6 Results of total score analysis for intuitive thinking task . . . . . . . . . . . 667.7 Results of perceived enjoyment for deliberative thinking task . . . . . . . . 687.8 Results of perceived enjoyment for intuitive thinking task . . . . . . . . . . 687.9 Results of perceived amount of mistakes for deliberative thinking task . . . 687.10 Results of perceived amount of mistakes for intuitive thinking task . . . . . 697.11 Results of how participants felt about how force feedback effects affected

perceived ease of the game . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.12 Results of which game participants believed easier to work together in . . . 707.13 Results of which game participants believed took the longest to complete . 717.14 Results of perceived ability to accurately aim for deliberative thinking task 727.15 Results of perceived ability to accurately aim for intuitive thinking task . . 72

D.1 The permutations of volunteers to control for order effects. Each permuta-tion is evaluated three times. . . . . . . . . . . . . . . . . . . . . . . . . . . 165

D.2 The raw statistics for the slow ball volunteers . . . . . . . . . . . . . . . . . 264D.3 The raw statistics for the fast ball volunteers . . . . . . . . . . . . . . . . . 265D.4 Results of game time analysis for deliberative thinking task . . . . . . . . . 266D.5 Results of game time analysis for intuitive thinking task . . . . . . . . . . . 266D.6 Results of ball loss analysis for deliberative thinking task . . . . . . . . . . 266D.7 Results of ball loss analysis for intuitive thinking task . . . . . . . . . . . . 267D.8 Results of Player 1 score analysis for deliberative thinking task . . . . . . . 267D.9 Results of Player 1 score analysis for intuitive thinking task . . . . . . . . . 267D.10 Results of Player 2 score analysis for deliberative thinking task . . . . . . . 268D.11 Results of Player 2 score analysis for intuitive thinking task . . . . . . . . . 268

viii

Acknowledgements

Many thanks to my supervisor Dr Leon Watts, as without his guidance and encouragement,this project would not have been possible. I would also like to thank Selina Odedra andBrett Billington for their help and support.

ix

Chapter 1

Introduction

When people work together in the physical world, they make use of the things they see, hearand feel to help coordinate their individual actions. This project examines the potential forphysical sensations to improve the experience of collaborating individuals in an activity.

When using a computer interface, a human usually receives information through one pri-mary modality: Sight. There are secondary modalities in which additional information isprovided, the provision of sound and the stimulation of the sense of touch, the latter isbetter known as haptics. By combining one or more of these modalities in an interface, theadditional information provided by them can affect the way users interact with an interface(Gee et al., 2003).

The word Haptic, coming from the Greek “haptesthai”, means “to touch” (Harris, 2008).Additional information provided through the haptic channel has been used in many differentsystems for many different purposes. There are examples where haptic feedback has beenprovided to assist blind users when accessing the internet (Kuber et al., 2007) by renderingHTML elements through the stimulation of touch.

The provision of haptic information has increased in consumer devices over the last fewyears, with more devices using motors to provide this information through force feedbackeffects. Mobile phones are the most widely used device which provides a rumble effect toillustrate when a text message or phone call has been received.

Other widely used devices which are particularly relevant to this project are the inputdevices, otherwise known as controllers, for games consoles. The three most popular gamesconsoles on the market today use force feedback effects in their controllers: The NintendoWii (Nintendo, 2006), the Microsoft Xbox 360 (Microsoft, 2005) and the Sony PlayStation3 (Sony, 2007).

1

CHAPTER 1. INTRODUCTION 2

There are examples of devices that are created for more bespoke purposes; custom madefor a single purpose or task. Examples include a device that can assist a surgeon whenperforming robotic surgery (Bethea et al., 2004) and the provision of a heightened senseof immersion in computer games (Andrews et al., 2006).

Immersion can be thought of as being so engrossed in a task or environment that you areunaware of events occurring outside of that environment (Agarwal and Karahanna, 2000).It is an experiential matter, which means it is to do with the personal feelings and opinionsof a person as they interact with a computer or virtual environment. It cannot be thoughtof as an objectively measurable quantity which is related to the performance of a task. Forexample, a flight simulator may immerse players to the extent that they can genuinely feellike they are flying a plane. This is known as the feeling of presence (Witmer and Singer,1998).

Collaborative systems are becoming increasingly important as companies become increas-ingly multi-national and distributed. Additionally, with the ever increasing internet con-nection speeds, the demand for collaborative systems that provide a highly interdependentwork environment are more feasible.

Collaboration can be thought of, at a basic level, as two or more people identifying com-mon and individual goals in the pursuit of a shared objective. This is closely related tocooperation, which can be thought of as the process of identifying and distributing labourfor tasks in order to achieve common goals so that a shared objective can be met and themanagement of interference that may be present during.

The interdependence between people in collaborative work environments is known as cou-pling. Two or more people are tightly coupled if they are highly reliant upon one anotherand require frequent communication with each other. The opposite of this is known asloose coupling.

A task can have different thinking and reasoning requirements. The cognitive processrequired to solve a crossword puzzle is distinctly different to the ones required when per-forming an emergency stop in a car. These two different ways of thinking can be thought ofas deliberative, where thinking is considered, careful and intentional, and intuitive, wherethinking is spontaneous, instinctive and automatic. These two types of thinking make upthe dual process model of thinking (Kowalski, 2006).

The primary aim of this project is to find out whether providing additional informationthrough the haptic channel about what is seen visually yields benefits in user performancewhen completing a task. This task must stimulate the two types of thinking: Deliberativeand Intuitive.

There are two secondary aims. The first is to see whether this provided information im-proves the enjoyment of completing a task, which in turn heightens the sense of immersion.


The second looks at the provision of cooperative interference and the affect this has on ausers own personal goals in the pursuit of a collaborative objective.

1.1 Document Structure

Chapter 2 is a survey of literature related to the important ideas and concepts to providea solid foundation for the design. It illustrates the importance of haptic information andcollaborative work environments and provides examples of haptic information affecting taskperformance and perceptions.

Chapter 3 discusses the identification of a collaborative task and the selection of a gameconcept which will serve as the primary way to complete the task. It shows that theconcept has to be collaborative and robust enough to enable the provision of cooperativeinterference.

Chapter 4 shows the design of the game, specifically the interface, the mechanics and thesystem components and how each design decision was made with the collaborative task inmind. The design gave a clear definition of how the key concepts were designed into thegame, with details on how collaboration would be enforced, cooperative interference wouldbe provided, switching between deliberative and intuitive decision making and the mappingof force feedback effects to input/ouput states.

Chapter 5 discusses the implementation of the software. Specifically, the programming lan-guage used for development, the implementation of system components and the sub-systemused within the main system component. The implementation gives specific details abouthow the system components interact, with specific attention paid to the strength and typeof force feedback effects and the game mechanics that were used to enforce collaboration.

Chapter 6 shows the details of a pilot study performed in order to validate and verify thegame functionality and the gathering of metrics. The results of the pilot study raised andfixed implementation issues and validated the methodologies for the experimental study.

Chapter 7 shows the details of the experimental study. The experiment is described andthe analysed results are then presented, followed by a discussion on the findings. The resultsshow that there is a benefit in task performance when the task is intuitive when additionalinformation is provided, as well as there being an effect on perceptions and personal goalswith collaborative interference.


Chapter 8 brings together all the findings in the project in a final conclusion. It discussesthe findings, critiques the process and outlines further work that can be performed. Itshows that with all the areas of research and the findings made, there is a framework fromwhich further studies could be performed.

Chapter 2

Literature Survey

2.1 Introduction

The main aim of this project is to investigate how the performance of a collaborative taskis affected by the provision of additional information through the haptic channel.

A device that is capable of creating this additional information is known as a force feedbackdevice. These devices provide information to users through the production of physical forcefeedback effects, such as rumble or vibration, in order to stimulate the sense of the touch.

When people collaborate, they organise individual activities required to reach a goal. Thedegree of interdependence and synchronization required between each individual is knownas “coupling”. The more reliant individuals are on each other to progress, the tighter theirwork is said to be coupled.

A human can be thought to make decisions in two distinct ways: Intuitively and delibera-tively. Decisional requirements within a task may differ. A task that requires immediateand instinctive decisions can be thought of as an intuitive task. One that requires consciousand controlled decisions can be thought of as a deliberative task.

This review of related literature will begin with an introduction to the field of haptics. Thiswill discuss both the human aspect of haptics, such as how information is provided, andthe computer aspect, such as the devices available that provide force feedback effects.

This will be followed up with a discussion of collaboration and cooperation. Tightly andloosely coupled collaborative working are considered, with respect to goals. Collaborativetasks involve decision making processes that are governed by the degree of coupling and

5

CHAPTER 2. LITERATURE SURVEY 6

the time frame for action.

The final section is a discussion of metric gathering techniques and what will need to bemeasured when performing an experiment in collaborative haptics.

The chapter concludes by arguing that there is a need for more research to explore thepotential of haptic information to enhance the performance of a collaboration in both delib-erative and intuitive tasks, as well as more research into the affect of providing interferencewhen users are trying to cooperate in a collaborative work environment.

2.2 Haptics

The word Haptic comes from the Greek “haptesthai”, meaning “To Touch” (Harris, 2008).As such, the field of Haptics is primarily concerned with the study of the sense of touch. Justas eyes receive information from the immediate surroundings and ears receive informationthrough methods such as speech or speakers, the sense of touch receives information aboutthe objects that we feel.

It is believed that humans receive information through four different input modalities: Vi-sual, Auditory, Haptic and Movement (Dix et al., 2003). Visual and auditory are consideredthe main modalities through which information is supplied, but provision of additional in-formation through the haptic modality has increased in use due to the high penetrationrate of mobile phones where, in the developed world, it is estimated that 97 out of 100people on average own one (Union, 2008).

Consumer goods, such as mobile phones, primarily provide haptic information throughthe use of actuators, which provide mechanical motion by the activation of a motor. Thisprovides a limited range of sensations which it can create and is usually limited to vibrationsof varying strength. Mobile phones usually provide this vibration in addition to auditoryand visual information, such as when a call is received.

Research has shown that users believed the provision of visual, auditory and haptic infor-mation in mobile phones created a more preferable experience over the provision of visualand auditory information alone. Participants were asked to select a ring tone where sim-ple vibrations and flashing lights would play along to the beat and then do the same fora ringtone where vibrations were disabled. Participants reported that the former was amore preferable experience and some participants reported a perception of increased audiofidelity (Chang and OSullivan, 2005).

Research has shown that the provision of haptic information is useful when used in assistivetechnologies. There has been research into the provision of haptic information for visually


impaired users when browsing a website (Kuber et al., 2007) and a haptic mouse used tointerpret Windows operating system elements such as buttons, sliders and pull-down menusthrough a mouse that provides haptic information (Gillespie and O’Mohdrain, 1995).

The provision of haptic information is also known as haptic feedback. It is commonlydivided into two different but related modalities: Vibrotactile and Kinaesthetic Immersion(2007). Kinaesthetics is how one perceives where their body is positioned; an “awarenessof the position of the body and limbs” Dix et al. (2003).

While the provision of haptic information via kinaesthetics is not the aim of this project, it isimportant to be aware of it due to the way it works. The process of receiving and processinginformation kinaesthetically is constant. Humans are always utilising their kinaestheticsense, be it to perform some activity or to get into a more comfortable position when doingnothing.

Vibrotactile refers to the stimulation of human subcutaneous tissue to transmit informationthrough receptors within this tissue, which are described by Dix et al. (2003) as follows:

• Thermoreceptors respond to heat stimulus.

• Nociceptors respond to pain.

• Mechanoreceptors respond to applied pressure.

Mechanoreceptors can be divided into two types: instantaneous, where the receptors re-spond to immediate pressure but stop responding if continuous pressure is applied andcontinuous, where the receptors only respond when continuous pressure is applied (Dixet al., 2003). It is these receptors that are stimulated by, for example, the vibration of amobile phone.

This study looks only at the stimulation of mechanoreceptors, due to the small of existingliterature around stimulation of the other two receptors combined with the ethical andlogistical constraints upon the provision of pain and heat to participants of an experimentalstudy. As such, when referring to the provision of haptic information, it will mean theprovision of stimulus to the mechanoreceptors.

The study of haptics has progressed to the point where it is possible to split the researchof haptics into 3 distinct areas (Srinivasan, 2006):

• Human Haptics - The study of human sensing and manipulation through touch.

• Machine Haptics - The research, development and creation of devices that augmentor replace the human sense of touch.


• Computer Haptics - Primarily deals with the creation of software or algorithms torender the touch and feel of virtual objects.

Human haptics can be thought of as the biological mechanics of the sense of touch, suchas the cognitive processes that occur when haptic information is provided and how thisinformation is processed. Computer haptics involves the creation of virtual environments,in which objects can be controlled, touched and manipulated. Machine haptics is thedesign and creation of devices which bridge the gap between human and computer haptics.A virtual environment will provide the haptic information to the human via the use of adevice which provides force feedback effects.

Discussion so far has primarily been around human haptics and the way a human receiveshaptic information. The following section discusses force feedback devices and their uses.

2.2.1 Force Feedback Devices

Force feedback can be thought of as the provision of haptic information through the useof a mechanical means (Telerobotics, 2009). As such, a force feedback device can be con-sidered as a collection of one or more of these mechanical systems and the provision of aforce feedback “effect” utilises these mechanical systems to transmit information, such asa rumble or resistance to movement. Force feedback is the medium in which a computersystem provides haptic information to a user.

Different force feedback devices are capable of providing effects of differing complexity.Based on the range of effects a device can provide, it can fall into one of three categories(Corporation, 2007):

• Rumble feedback - Devices that are only capable of providing basic rumble effects

• Tactile feedback - Devices that can provide taps, clicks and vibration effects

• Full force feedback - Devices that are capable of resisting a user’s movements andbeing able to change its physical position

An example of a device that provides rumble feedback has already been discussed; the mo-bile phone. Another example of a device that provides rumble feedback and has particularrelevance to this project are game controllers. From their first introduction to mainstreamhome computer gaming with the Nintendo 64 via the use of a “rumble pak” peripheral(Tyson, 2000), controllers that provide rumble effects have increased in use and are cur-rently available in all three of the major home consoles: The Nintendo Wii (Nintendo,2006), the Microsoft Xbox 360 (Microsoft, 2005) and the Sony PlayStation 3 (Sony, 2007).


While still providing rumble effects today, the range of rumble they provide has increasedsince their introduction. Within the Microsoft Xbox 360 controller there are two separaterumble motors, one for the left and the other for the right side of the controller, eachof which capable of providing a varying amount of rumble (Ditchburn, 2009). These canprovide a larger variety of effects than those afforded by the single motor solution of theNintendo 64. For example, a driving game where the player begins to veer off the roadcould receive feedback from the motor on the left side of the controller if they were veeringthat way, and vice versa. This communicates two pieces of information: The first beingthe fact that a player is going off road, the second being which side of the player is goingoff road. This is information that could not be provided by a single motor, which couldonly communicate the former.

An interesting observation is that with the introduction of the Nintendo Wii, there hasbeen an integration of vibrotactile, via the provision of rumble, and kinaesthetic, via theuse of a gesture based control scheme. Gesture input is kinaesthetic, as games such as WiiSports (Nintendo, 2006) are modelled on sports games such as tennis. Wii tennis relies ona player’s ability, as in real tennis, to be aware of the position of their limbs in order tofocus on the position of the ball instead of the position of their bat. The forthcoming Natal(2009) device from Microsoft focuses solely on kinaesthetic input via accurately pinpointingthe location of individual limbs in order to simulate driving a car. This is done by holdingan invisible steering wheel and pushing the accelerator with the position of your foot.

Due to the increasing use of haptics in a variety of different ways in the home games consolemarket, who knows what the future has in store for haptics in this area?

Devices that provide tactile feedback are present in everyday life and it is highly likelythat everyone has used one at some point in their lives. Keyboards, mice and mobile phonenumber pads could all be considered to be devices that provide tactile feedback. The tactilefeedback they provide can be thought of as being very simple; only informing a user thata button has been pressed (Srinivasan, 2006). While simple, it has been proven that thisfeedback is extremely useful. A study conducted into the provision of vibrotactile feedbackto signify a button being pressed on the virtual keyboard of a smart phone showed thatparticipants could enter significantly more letters, made fewer errors in input and correctedmore of those errors that were made than when this feedback was not enabled (Brewsteret al., 2007).

Full force feedback devices can provide the largest range of force feedback effects. They areusually created for specific purposes, with companies such as Immersion and Sensable cre-ating and researching devices to enable interaction with virtual 3D environments (Sallnas,2001), (Sallnas et al., 2000).

Full force feedback devices are used to convey the largest amount of information out of thethree types. They can be used to supply information about the size, shape and positionof an object, as well as providing the feeling of impenetrability when touching objects in a


virtual 3D environment (Immersion, 2007).

The force feedback device that will be used in this project, the Microsoft Force Feedback 2,is a full force feedback device. Not only is it capable of providing rumble feedback, but it isalso capable of providing forces and resistance to movement of the joystick by a user. Thisis commonly used in the Microsoft Flight Simulator series to simulate the stick shaker, adevice commonly used to provide forewarning of an engine stall in aircrafts. Interestingly,this in itself is a force feedback effect in modern airplanes. In the older light aircraft, theeffect of the joystick shaking occurred due to aerodynamic buffeting as the pilot approacheda stall. This no longer occurs in servo controlled aircrafts, so the effect is replicated usingan electric motor due to its usefulness as a warning mechanism (Wikipedia contributors,2010).

All of these devices, no matter how complex, exist to provide a mapping of a system state toa force feedback effect. Mapping is a key concept within human-computer machine haptics,and can be thought of as having two types. “Natural” mappings are intuitive; they requirea minimal amount of time to understand and simulate a real world action or state. Forexample, when a human lifts a block they get information about the size and shape ofthe object. If this state of lifting can be mapped to a force feedback effect that providesequivalent feedback in a virtual environment, this can be considered as a natural mapping.Due to the constraint of real world effects, the amount of natural mappings are limited tothis set.

The second type of mapping is known as an “artificial” mapping, which are less intuitivewhen compared to natural mappings. An artificial mapping may require time for the userto interpret the purpose of the effect in the context of the system being used. While this isa notable drawback for artificial mappings, it has the benefits of having a set of mappingslarger than those contained in natural.

Now that force feedback devices have been discussed, the following section contains adiscussion on existing research into the effect of haptic information in three different areas.

2.2.2 Effect of Haptics

Existing research into the effect of haptics has yielded strong evidence to support thatthe provision of haptic information can affect three different areas: Task Performance,User perceptions and Immersion. The following sections define these three areas beforediscussing the research and the results found.


Task Performance

Research suggests that the provision of haptic information has a positive effect on taskperformance. The study mentioned in the force feedback devices section which involvedthe provision of tactile feedback for the task of entering text through a virtual keyboardon a smart phone yielded an increase in time efficiency and a decrease in the amount ofmistakes (Srinivasan, 2006). The amount of time taken to complete a task and the amountof mistakes made, which can also be thought of as accuracy, appear to be the two keyelements to the performance of a task.

A study with a force feedback enabled mouse in a 2D Windows-based GUI found thatthere was a positive increase in task performance. The task that participants were requiredto perform was to navigate the mouse through a tunnel of varying sizes, with the forcefeedback effect being a “pull” towards the centre of the tunnel. It was found that withthe force feedback effects, participants were observed to complete the task 52% faster thanwithout. The accuracy of this task was not recorded in this study (Dennerlein et al., 2000).

Another study that was conducted looked at the effect of delayed haptic and visual feedbackin a collaborative virtual environment. The purpose of this study was to emulate the effectof network latency in real life collaborative environments and the effect that delays had ona participant and those they were working with. The task was to collaboratively identify atarget and the results showed adverse affects to task performance. Participants made moremistakes and took longer to complete the task (Jay et al., 2007).

The last two papers that are to be discussed are related, as they were performed with similarequipment setups and similar scenarios. The first looked at accuracy of a task which was tocollaboratively manipulate blocks using a Phantom Omni which provided a sense of form,mass and friction to the blocks. Specifically, it required participants to stack blocks in aspecific order. The results of this study showed that the amount of times participants failedto lift cubes was greatly reduced when force feedback effects were provided. The amountof time taken to complete was not recorded in this study (Sallnas, 2001).

The last paper used the same task and the same haptic devices in order to answer differentexperimental aims. This research paper looked at the amount of time it took participantsto complete the collaborative lifting of the blocks into the correct order. The results showedthat the amount of time taken to complete the task was reduced significantly when forcefeedback effects were provided (Sallnas et al., 2000).

Another area that this last paper looked at was the effect of haptics on participant’s percep-tions of task performance, social presence and virtual presence. The next section discussesresearch papers on the effect of haptics on the perceptions of a user.


User Perception

Research into the area of haptics revealed that the provision of haptic information cangreatly change the perceptions of a person. The study mentioned in the first section onhaptics that involved the provision of haptic and visual information on a mobile phone whenlistening to ringtones revealed that some participants perceived there to be an increase inaudio fidelity when the phone vibrated to the music, even when there was no difference inthe audio played (Chang and OSullivan, 2005).

Another study that looked at the collaborative performance of the “ring on a wire” task,which involves the navigation of a ring over a bent wire to reach an end point. Participantsin this study were distributed and unable to see each other, but the results state thatthe participants feeling of “togetherness”, which was a sense that they were working withanother human rather than a machine, was increased by the provision of force feedbackeffects (Ho et al., 1998).

There is also evidence to suggest that haptic information has a positive effect on perceptionsoutside of the field of academic research. A training system for the da Vinci robotic surgicalsystem which wishes to use force feedback effects to allow users to perceive themselves tobe operating on a person when they aren’t (Baheti et al., 2008) is an example. Anotherexample is the provision of force feedback effects to assist operators of mechanical arms.This provision of resistance in the operator interface allows a user to perceive that theobject the mechanical arm is lifting has weight, while technically unnecessary, is seen tohave benefits in the accuracy of lifting and manipulating objects (Telerobotics, 2009).

In the last study mentioned in the previous section, it was found that users perceived theirtask performance to be greater when force feedback was enabled. Additionally, participantsperceived themselves to be more virtually present when force feedback effects were enabled.Virtual presence is defined as a subjective feeling of being in one place or environment whenphysically located in another (Sallnas et al., 2000).

The concept of social presence being a subjective feeling of being is similar to that ofimmersion; both can be seen as the feeling of presence within another environment whilephysically located in another (Witmer and Singer, 1998). This will be discussed further inthe following section.

Immersion

The research on perceptions revealed that the concept of social presence was similar to thepsychological state of immersion. Both social presence and immersion can be defined as aperception of being located in one environment while being physically located in another.


If a person feels that they are on the outside looking in, they are no longer immersedin what they are doing (Witmer and Singer, 1998). Similarly, Agarwal and Karahanna(2000) offer the view that immersion is the focus of attention, the “experience of totalengagement where other attentional demands are, in essence, ignored.” By having all yourattention focused on a task, the cognitive burden of completing the task lowers (Agarwaland Karahanna, 2000).

A common theme of the literature reviewed in this area is that immersion is a subjective,personal and individual experience; one that is based upon previous experience, personalpreferences and opinions (Burney and Lock, 2007), (Witmer and Singer, 1998), (Agarwaland Karahanna, 2000).

It was shown in a research paper that players felt more immersed in a game that providedmore physical disconnection from the outside world. To elaborate, the game was providedin two scenarios: The first was in front of a flat screen and the second was in a dome, whichprovided a more enclosed experience. Participants reported that being surrounded by thegame made them feel more immersed in it (Burney and Lock, 2007).

The concepts of social presence and immersion appear to be closely related. As such, for thepurposes of this project, immersion and social presence will be synonymous and refer to thefeeling of total engagement with the task, with people being less aware of the environmentoutside of the task.

Summary of Haptics

Haptics are used to provide information through the stimulation of touch, just as booksprovide textural information through the use of sight. Haptic devices are mechanical sys-tems that can provide this haptic information through the provision of stimulus to themechanoreceptors located under the skin. Haptic devices that are capable of only provid-ing a limited range of stimulus through force feedback effects have shown to create not onlya preferable experience but also yield advantages in performance.

Haptic devices are commonly used in collaborative virtual environments where objects canbe touched, controlled and manipulated through these devices. They have been found toincrease the feeling of togetherness and virtual presence from geographically distributedusers. Virtual presence, which in this report is being treated as synonymous with im-mersion, is the state of being where all attentional demands are focused on the virtualenvironment, leaving a user unaware or “disconnected” from the outside environment inwhich they reside.


2.3 Collaboration

Some of the research discussed in the previous section involved collaborative work environ-ments. As this is a key area that is critical to this project, it is important to understandwhat it is. While collaboration and co-operation are often thought of as being synonymous;both involving working together to achieve a goal, the separation of these two terms is oftenunclear.

When people collaborate, they pursue their own individual goals while simultaneouslyidentifying common goals to meet a shared objective. Co-operation is required to identify,distribute and execute tasks to achieve these individual and common goals, whereas collab-oration is not concerned with how a goal is achieved or how labour is divided (Nezamiradet al., 2005). Hoc (2001) explores the definition of co-operation in more detail and definesit as “Interference Management”. Interference is defined as the following:

• Precondition - In order to complete a task, an individual relies on the completion ofa different task belonging to another individual.

• Interaction - The desires of an individual or group change or otherwise influence thetasks of another, thus changing their personal goals.

• Mutual Control - The activities one individual or group undertake to complete a taskare controlled by another individual or group.

• Redundancy - When one individual is unable to fulfil a task and as such that taskmust be allocated elsewhere.

When people co-operate, they work together to minimise this interference.

Although their appears to be a consensus between numerous authors that to co-operate allinvolved parties must work towards the achievement of a shared objective, Hoc offers theargument that it is not necessary for each person to share the same objective to co-operate(Hoc, 2001). For example, an individual may ask another to assist in a problem solvingexercise. They may be working to two completely different objectives, but an individualrequires the co-operation of the other to achieve a personal goal.

In order to generalise these for the purpose of this paper, collaboration will be defined asa group of people working together to identify common goals in order to meet a sharedobjective. Co-operation will be defined as two or more people who distribute and completetasks to meet these common or personal goals and thus, by extension, the shared objective,if one exists.

Collaboration is present throughout all walks of life, from collaborative working scenariosto team games. It is something regularly encountered in day to day life.


To give an example using the previous definitions, take the scenario of two people passingeach other in a corridor. Collaboratively, there has been a common goal identified (passeach other). They co-operate by having one person stand still while the other passes, thusachieving the common goal in order to continue towards their own objective (which mayor may not be shared).

It is important to make this distinction between collaboration and co-operation as withinthe scope of the project, users are going to be co-operating on tasks in order to meet thecollaborative objective.

2.3.1 Coupling in Collaborative Environments

As mentioned earlier, the interdependence and synchronicity required between each in-dividual in a collaborative working environment is known as “coupling”. There are twodistinct extremes of coupling, known respectively as “tight” and “loose”.

Tightly coupled collaborative scenarios in the context of one-to-one working, can be definedas follows Pinelle and Gutwin (2005):

• High interdependence - An individual’s actions affect the other significantly and reg-ularly.

• Low differentiation - An individual is not self contained or distinct. Each individualmay not have a distinct purpose or role.

• High integration - Each individual must communicate and interact regularly with theother to manage interdependence.

Using this definition, an example of a tightly coupled collaborative scenario would be peopleworking together to write a piece of software. They are highly dependent on each other asone has to rely on the code they write not interfering with the code of the other individual.

Due to this, there is a high level of integration as each one has to know what the other isdoing in order to prevent any of these potential clashes in code. They are not seen as selfcontained, with both of them writing the same piece of software with little or no defineddifference in their role. Additionally, the potential for interference is increased due to thehigh reliance between the two people.

Pinelle and Gutwin (2005) define loosely coupled collaborative scenarios in the context ofone-to-one working as follows:


• Low interdependence - One individual’s actions will affect another’s minimally, infre-quently or not at all.

• High differentiation - An individual’s role is distinct, separated and self-contained.

• Low integration - An individual rarely has to communicate and interact with anotheras interdependence is low.

An example of a loosely coupled collaborative scenario would be the head teacher and thestudent psychologist at a school. Each member of staff have the same objective (the smoothrunning of school operations), but their jobs require that they interact very rarely. Therewould be little immediate need for results when they do interact due to their independentnature. This means that there is a low potential for interference, as the people involvedinteract very rarely and as such directly cooperative activities will not present themselvesoften.

It is important to have this distinction between types of coupling as co-operative computergames are almost always tightly coupled, requiring immediate interaction from each indi-vidual playing in order to progress in the game. This is usually due to the requirement ofboth players to progress past an obstacle or solve a puzzle.

With the rise of the internet as a communication medium, physically separated individualscan work together in tightly coupled scenarios. Utilising technologies such as web camerasand microphones in a video conference environment makes this possible by allowing anindividual to see and hear another.

This physical separation is also present in modern co-operative computer games. Theyrequire the same level of interaction as when the players are present in the same room, butwith each player having their own point of view rather than a shared environment leads toa lack of awareness of player location and state. This is usually remedied through in gamepointers and the use of microphones.

2.4 Tasks

Throughout this literature review, there has been an abundance of existing literature onthe effect of haptics on task performance, but most of the research involves performingdifferent tasks such as block stacking and navigating a ring over a wire. There is one thingthat these tasks have in common, which is that they are all tasks that allow people tohave near unlimited thinking time when making decisions about how to perform them.None of the existing literature found discussed the other type of task, one which requiresan immediate decision and leaves very little time to think. For example, when a driver


performs an emergency stop in their car, a decision has been made. The decision was notconsidered or thought about, it was instinctive and automatic.

These two types of decision making can be seen as a dual process model. These are wheretwo systems are operating in tandem. The two types of thinking within this model aredefined as follows (Kowalski, 2006):

• Intuitive Thinking is automatic, subconscious and natural.

• Deliberative Thinking is controlled, effortful and mostly conscious.

Research into these two different types of decision making has shown that the way thebrain is stimulated in distinctly different ways, with areas associated with effort showingmore activity in a deliberative thinking, referred to as dominance-solvable, game and areasassociated with how effortless a game is showed more activity in an intuitive thinking,referred to as coordination, game (Kuo et al., 2009).

“Precuneus activity correlates positively with how ‘effortful’ a dominance-solvablegame is, whereas insula activity correlates positively with how ‘effortless’ a co-ordination game is.” (Kuo et al., 2009)

It can be assumed that there is also a migration of deliberative to intuitive thinking overtime, such as when learning how to drive. This initially effortful task eventually becomeseffortless and subconscious. This could also explain why people are more “naturally”talented at different tasks than others. Individuals may have more prior experience withcompleting that or a similar task and the types of problems they present than others andwould thus be more prepared for them. This was used as a control during the experimentand is discussed in the conclusion in Chapter 8.

Summary of Collaboration and Tasks

Collaboration and co-operation are distinctly different. Collaboration is the pursuit ofshared or individual objective by way of creating shared and personal goals, whereas coop-eration is the identification of tasks and the distribution of labour to perform these tasks.To cooperate, it is not necessary for each person involved to share the same objective.

Tight coupling is signified by a high level of interdependence between collaborators, eachone relying greatly on the other. This type of coupling can apply to people who arephysically distributed, due to the advancement of communicative technology within thisarea.


When making a decision, the brain is stimulated in distinctly different ways depending onwhether the task is intuitive or deliberative. There is a migration of deliberative to intuitiveover time, as long as a task or action is repeated often enough. This could be why peoplewith prior experience in a task will be better at it than those who have none.

2.5 Metrics Gathering

The final area in which literature was reviewed primarily dealt with methods of metricsgathering and analysis in the existing studies that have been discussed within this section.

As the primary aim of this project is to measure task performance, it’s important to knowwhat quantitative data can be used to measure it. In the review of literature related tothe effect of haptics on task performance, two measurements were used. The first wascomparing the amount of time taken to complete the task with haptics enabled to theamount of time taken when haptics are disabled. The second measurement was comparingof the amount of mistakes, or accuracy, when completing the task with haptics enabled tothe amount of mistakes when haptics are disabled. Commonly, these two measurementswere used together as a measurement of task performance, and this the approach thisproject shall adopt (Jay et al., 2007), (Srinivasan, 2006).

As the analysis of the data will require repeated measurements from the same participants,a paired, or dependent, t-test over repeated measures will be used to test the data forsignificance (Weiss, 1998).

There are two different types of data that can be gathered within experimental research:Qualitative and Quantitative. Qualitative data refers to any data that cannot be capturednumerically, such as opinions and observations. There are 3 main ways to gather this data:Interviews, questionnaires and observations. Quantitative data refers to data that can becaptured numerically and can then consequently be subjected to statistical analysis. It ispossible to extract more quantitative data from a qualitative source using a Likert scale(Trochim, 2006).

As previously mentioned, the immersion that a person feels is a subjective experience(Burney and Lock, 2007). Subjective data can be prone to bias through external sources,specifically via confirmation bias and the halo effect. The halo effect is defined as “theinfluence of a global evaluation on evaluations of individual attributes of a person” (Nisbettand Wilson, 1977). For this project, it can be defined as the effect of a previous evaluationof similar tasks affecting the perception of another. For example, a person may perceivea game to be fun because of the colours used. A second game could be played that usesdifferent colours and the perception of that game could be that it isn’t fun, with this opinionbeing based on the previous game that had more preferable colours.


Confirmation bias is a similar concept and involves the interpretation of evidence based onpre-existing hypotheses or expectations (Nickerson, 2004). It differs from the halo effect bythe way that hypotheses may be formed even if someone has not performed the task before,based on similar or related information to what the task involves. Due to this potentialbias, utilising qualitative results makes it difficult to extract meaningful, impartial anduseful data.

There is one main way in which quantitative data can be obtained from qualitative, andthat is though the use of a Likert scale. A likert scale can either be even, 4, or odd, 5 and7, and these even and odd scales are used for different purposes. An even scale is usedwhen a positive or negative response is required, whereas an odd scale adds the option fora participant to provide a neutral response (Trochim, 2006). The benefits of a Likert scaleis the ability to quickly process qualitative information as if it was quantitative. Likertscales are used in many of the research papers discussed in this literature review for themeasurement of qualitative data, such as levels of perceived social and virtual presence(Sallnas et al., 2000) and the feeling of “togetherness” (Ho et al., 1998).

2.6 Conclusion

The review of relevant literature identified two gaps in existing research into collaborativehaptics. While the performance of a task has been shown to be improved in collaborativeand non-collaborative work environments when haptic information is provided, the deci-sional requirements of all the tasks within this research are deliberative. They allow for anear unlimited amount of thinking time before a decision has to be made. This makes upthe primary aim of this project.

The second gap is research on the effect of providing interference to cooperation and theeffect that has on personal goals in collaborative work environments. Interference may affectthe way people approach a task, or change a person’s personal goals as the interferencemay open up alternative ways of achieving their personal goal while closing off others. Thisgap makes up one of the secondary aims of this project.

Chapter 3

Task and Concept Design

3.1 Introduction

Using the fundamental ideas and concepts discussed in the previous chapter, the software foran experimental study can be designed. It would be necessary for the design to incorporatethese aforementioned ideas and concepts in order to successfully meet the aims of theproject.

This chapter begins with a discussion on the design of the collaborative task that playerswill have to perform in order to reach a defined objective. The design of the task isimportant as there are key requirements it must meet.

The chapter closes with a discussion on the game concept that will be used in order toconvey this task to the users. The concept refers to how the collaborative task is to beachieved and provides the framework for the game design, which will be discussed in thefollowing chapter.

3.2 Designing the Collaborative Task

Design of the collaborative task is imperative to the success of the project, as it is the taskthat is central to the development of the software and the experiments that take place.This means that the task must be designed with the project aims in mind.

There are numerous collaborative tasks that could be considered. In order to constrainthese tasks, high level requirements are needed in order to provide the scope of what a task

20

CHAPTER 3. TASK AND CONCEPT DESIGN 21

needs to do. Once the tasks are constrained, a task most appropriate for the aims of theproject can be designed.

3.2.1 Task Requirements

During the design, the following high level requirements were taken into account:

1. The task must be able to stimulate both types of thinking separately, deliberativeand intuitive

2. The task must give measurable metrics to enable task performance to be recorded

3. The task must include clearly defined common goals for collaboration

4. The task must be able to invoke interference to successful co-operation

5. The task must have clear input/output states for haptic force feedback mapping

The first requirement was deemed necessary as creating two separate tasks for each typeof thinking would have been difficult to control for. By using the same task but having theability to switch between deliberative and intuitive thinking, task metrics can be gatheredand compared between each type. Additionally, only a single piece of software would haveto be developed.

The second requirement means that whatever task is selected, it has to have measureablemetrics. As the medium is that of a computer game there are certain metrics that wouldbe expected, such as player score, time taken and lives lost. The third requirement meansthe task has to be collaborative; that the task has to have collaborative goals to meet anoverall objective as stated in the literature survey.

The fourth requirement refers back to the management of interference (lit survey). Whenpeople collaborate, they pursue their own personal goals. When interference is invoked,are these personal goals changed to enable successful co-operation? The final requirementmeans the task must have defined states on which haptic effects can be mapped.

The cognitive response requirements of the task as in the first requirement limited theamount of tasks that could be designed. Initial ideas focused on taking an existing tasksuch as navigating a maze or a block manipulation task as performed in other studiesSallnas et al. (2000), but this had many disadvantages.

The main disadvantage is that deliberative and intuitive thinking could only be enabledby the use of time constraints. By giving players a small amount of time, players have less


time to think about the decisions they make and thus have to act more intuitively. Timeconstraints eliminated the ability to use perceived time as a measurement of enjoyment, asplayers would be aware of how much time they have and thus be able to work out whichone they completed more quickly.

The task that was finally selected was that of collaborative block destruction. Playerswould have to work together in order to destroy a series of blocks through some means,for example shooting them or hitting them with an object. Both types of thinking couldbe invoked by controlling the speed of the object or the rate at which they could shoot. Ahigh speed object or high rate of fire would leave less time to plan movements without aplayer being aware of the game time.

Metrics could be gathered by the comparison of score obtained from destroying blocks,comparison of the amount of mistakes made and comparison of the amount of time takento destroy all of the blocks.

As the medium is a game, collaborative interference could be invoked by giving certainblocks the ability to have game altering properties that are invoked upon their destruction.This is due to the willing suspension of disbelief, which means players will be more willingto accept unrealistic events for the promise of entertainment (Atkins, 2003).

Finally, there are defined states due to the nature of the task. The objective is to destroythe blocks, with each block destruction providing an output. Additionally, players willhave to aim at the blocks in some way, for example with an object or projectile, in orderto destroy blocks which provides input states.

With a task selected, the next step in the design process was the selection of a conceptwithin which the task could be executed.

3.3 Selecting the Game Concept

With a task selected, the next stage of the design process was to select a game concept.There are many ways in which blocks can be destroyed, for example in a collaborativeshooting gallery scenario or ball throwing so it was important to select one that would bestmeet the project aims.

Early on in the design process it was decided to use a concept that already exists. Theprimary benefit of using a familiar concept is that it reduces the effects of learning meaningthat there will be less impact on results.


3.3.1 Merging two Existing Concepts

The decision was made to merge two existing concepts after a single concept could not befound. The two concepts that were merged are a Pong type game, which is similar to PingPong and a Breakout type game, where a ball is bounced into a wall of blocks in order todestroy it.

Figure 3.1: The initial game concept design

Figure 3.1 on page 23 shows the concept, which is each player bouncing a ball betweeneach other in order to destroy blocks. As in breakout, the game ends once all the blocks aredestroyed. Being a combination of two existing game concepts, this concept will be familiarto a large group of users. Additionally, the task itself is simple and straight forward. Thisreduces the effect of learning, particularly for those unfamiliar with the concept.

In order to switch between intuitive and deliberative thinking, the speed of the ball canbe varied. By using a ball travelling slowly, players can think deliberatively by taking thetime to position and aim. Conversely, a fast ball gives little time to aim, necessitating moreintuitive decisions.

Co-operative interference can be created by granting the blocks different properties. Forexample, the destruction of one of these blocks could place a second ball into play, givingthe potential for each player to have a ball. This would allow the task to be completed inparallel instead of passing the task between players. Another block may only be able to bedestroyed by one player, necessitating that players co-operate to facilitate its destruction.

With the concept decided, the next step was the design of the game.

Chapter 4

Game Design

4.1 Introduction

With a collaborative task and game concept decided, the next step in the creation of thegame was the design. The design of the game is important, as it is crucial in deciding whatfindings can be made and the conclusions that can be drawn.

As such, this chapter primarily discusses the decisions made during the design process,from the creation of the game mechanics to the mapping of force feedback effects to theinput/output states. Every decision made needs to be justified and appropriate in order toachieve the aims of the project.

This chapter opens with a short discussion on the development process that was selected.Following this, there is a discussion on the design of the game. This is split into threesections:

1. The design of the user interface with particular focus on the information provided tousers

2. The design of input states to output states and the mapping of force feedback effectsto these

3. The design of the mechanics of the game, such as how collaboration was enforced.

The chapter closes with a discussion on the design of the system components and how theyinteract.

24

CHAPTER 4. GAME DESIGN 25

4.2 Process Selection

Due to the software being a one-time use prototype tool, conventional design methodologieswere not followed. Instead, the design was game state based. This involved designing thekey states that the game would be in and the mechanics that would create these states,with the research questions being the driving force behind each design decision that wasmade.

When designing and developing the game, the decision was made early on to adopt a moreagile process of software development. This decision was made for three reasons:

1. To enable rapid development of the game

2. To dynamically re-design and re-scope the project at short notice

3. To prioritise implemented functionality based around the project aims and researchquestions

4.3 Interface Design

Following the selection of a concept, the user interface could be designed around it. Thedesign of the interface was split into two sections: The positioning and content of the userinterface and the design of the game area.

The design of the interface had to consider the needs of the project. It needs to be as simpleand as functional as possible; only providing information that is necessary and relevant.

Figure 4.1 on page 26 shows the initial interface layout design. In order to contrast againstthe foreground elements, the background colour needed to be solid and plain. Additionally,the entire game window should be maximised to the full size of the screen. Both of theseminimise the amount of distractions that participants are subjected to, which should allowthem to focus on the task.

The main area of the game window contains the visual representation of the game. Thesidebar contains information about the game such as player score and mistakes made.

The original design of the sidebar provided information about the time taken by the players.This functionality was removed during the pilot study as it allowed players to choose thegame that took longer by remembering the time it took, rather than it being a perceivedamount of time.


Figure 4.1: The initial interface layout design for the main game window

The design of the visual representation of the game was the next phase of the interfacedesign. Due to the agile approach, this part of the interface was iterated over and modifiednumerous times as additional mechanics were implemented, as designs were made for eachkey game state.

Figure 4.3 on page 32 shows the main iterative stages of the design and also shows the im-plementation of additional game mechanics as they were designed. The visual informationwas provided in order to minimise the learning process required.

The colours used in this visual game representation were chosen for contrast and to separateeach game object. The colours for each player are opposites, red and blue, and this schemefollows through to the player specific blocks. The non-player specific block is green, makingup all three colours of the RGB colour model. Additionally, grey was chosen for the multi-ball block as it was distinctly different from the other colours used.

Over the course of the games visual representation design, the following key game stateswere identified and had user interface designs produced:

• New game state. The start of the game, prior to any input from the user

• The block collision game states

– Collision with a normal block by any player

– Collision with a player specific block by the owning player

– Collision with a player specific block by the non-owning player


– Collision with a block that puts a second ball in play

• End game state

4.4 Input Mappings

4.4.1 Input/Output Mappings

Due to the nature of the task, the input/output mappings are inherently simple. This isbecause the game itself dictates the movement of the ball; players only have control overthe original launch of the ball and the angle at which it rebounds off the player. As such,output state depends on the launch state of the ball. Table 4.1 on page 27 shows thesediffering output states for a particular input.

Input Output (Pre-Ball Launch) Output (Post-Ball Launch)

Move joystick left Move player and ball left Move player left

Move joystick right Move player and ball right Move player right

Trigger button pressed Set ball in motion None

Table 4.1: The mapping of input state to an output state

4.4.2 Force Feedback Mappings

The force feedback mappings show the type of effect that will be triggered by an input stateor action within the game. The force feedback effects that are triggered provide additionalinformation through the haptic channel about what is currently represented visually withinthe game.

Table 4.2 on page 28 shows these effect mappings. The additional information beingprovided revolves around two different objects within the game: The player and the ball.For the ball, additional information is provided about the current collision state. For theplayer, the joystick pulls to the origin to provide resistance to movement. The idea for thisis to provide a feeling of weight to the player’s in game character.


Input State or Event Force Feedback Effect

Ball strikes current player Joystick rebounds away from ball

Ball strikes other player Rumble to signify collision

Ball strikes wall Rumble to signify collision

Ball strikes block Rumble to signify collision

Move joystick in any direction Joystick returns to origin

Table 4.2: The mapping of input state or action to a force feedback effect

4.5 Mechanics Design

While there are numerous core game mechanics, this section discusses the design of themechanics around the three of the most important objectives: Enforcing collaboration,providing cooperative interference and stimulating deliberative and intuitive thinking sep-arately.

Due to the task being that of block destruction, it allows for the mechanics to be modifiedgreatly merely by modifying the properties of the blocks that are being destroyed. Forexample, a block can be made indestructible, providing a wall between the players or adestructible block could alter the properties of the game by reversing player controls.

Additionally, the movement speed of the ball and player objects could be changed in orderto modify and create constraints on how the task can be accomplished by the players. Forexample, by increasing the maximum speed that the player can move may allow a playerto reach a ball more quickly but rebound it with less accuracy.

4.5.1 Enforcing Collaboration

When the game concept was chosen, the task it conveyed was not inherently collaborative.While two players could play it and destroy the blocks, it was possible for a single playerto do it by themselves without involving a second player at all.

During the design process, two ways of enforcing collaboration were identified and chosento enforce collaboration. The first of these was the addition of a “combo multiplier”. Thiswould multiply the amount of points given for the destruction of a block by the numberof times the ball has been rallied between both players without losing it, up to a definedmaximum.

This meant that in order to get the largest score overall, both players would have to hit theball between them without losing it in order to maximise the score that players can get.


While this would encourage players to pass the ball between each other, it was still possiblefor a single player to complete the task by themselves. This was implemented through theuse of blocks that can only be destroyed by one player.

This enforced both players to work together to complete the task as player 1 cannot destroythe blocks meant for player 2 and vice versa, which meant that a player would have nochoice but to pass the ball to the other player in order to destroy every single block.

4.5.2 Cooperative Interference

One of the ideas discussed in the literature survey was that of cooperative interference. Forsuccessful cooperation to occur, both players must manage this interference (Hoc, 2001).Within this game, interference will be provided through the use of a destructible block thatalters the game mechanics.

The decision was made that upon the destruction of the block, a second ball would be addedinto play. The main reason for this was that it altered the way that the task objective couldbe completed. By providing two balls, it would no longer be necessary to “pass” the ballbetween players; each player could have one each.

Originally, the position of the second ball originated at the location of the destroyed me-chanic manipulating block. When performing the pilot study it became apparent that assoon as the second ball was put into play, it was impossible for the players not to lose it asthe second ball.

The game was updated so that the second ball was created at the location of the playerwho did not strike the manipulating block. As with the original functionality, the playerhas no control over when the second ball is launched; it occurs automatically as soon asthe manipulating block is destroyed.

4.5.3 Deliberative and Intuitive thinking

The primary aim of the project is to observe if force feedback has any affect on taskperformance for two different types of thinking: deliberative and intuitive. As researchstated within the literature survey, intuitive thinking is subconscious and automatic, whiledeliberative is conscious and controlled. Together they are known as the dual process modelof thinking (Kowalski, 2006).

It was decided that the controlling factor between these two types of thinking was time.If a person was in a situation where they had to make an immediate decision, they would


not deliberate over the decision. If the decision was not immediate, a person would havetime to think about the choice they make.

In order to stimulate these two different types of thinking, the ball speed would be modified.The reason for this is that when presented with a slow ball, a player would have time toaim and think about the direction in which they want the ball to go. Given a sufficientlyfast ball, a player would not have this time to think and would thus respond intuitively.

The two precise speeds at which the ball will travel was decided in the pilot study in orderto use the most appropriate speeds. A ball that travels too slowly would make the gamefrustrating and boring. A ball that is too fast would mean a player would not have enoughtime to reach the ball before it falls out of play.

4.6 System Design

The design of the system took place in order to provide an idea of the necessary componentsneeded for implementation and how they would interact.

Figure 4.2 on page 31 shows the system design diagram. The approach was to create acentral engine to instantiate, control and manipulate individual objects. The engine wouldbe responsible for:

• Instantiating objects, input handlers and the data logger

• Processing data provided by the input handlers

• Updating the state of the game objects

• Retrieving the state of the game objects and passing the data to the data logger

• Rendering the game window, visual representation of the game and additional data

The reason for this was that due to the agile method of design and development, the codebase and components would be changing on a rapid basis. Building everything around acentral engine allowed a modular component structure to be adopted which meant func-tionality that needed to be implemented after the initial iteration, such as the data loggerand input handler, could be rapidly implemented.


Figure 4.2: System components design diagram


Figure 4.3: The iterative design document for the main game area

Chapter 5

Implementation

5.1 Introduction

This chapter discusses the implementation of the design illustrated in the previous chapter,providing information about how the different components of the game work.

This chapter opens with a discussion on the input devices that the game will support andthe programming language selected for this purpose. Following this, there is a discussionon key implemented functionality for each of the game components that were identified inthe design. Figure 4.2 on page 31 shows these components.

This chapter is not intended to be a system wide code and development discussion. It isintended to explain and show the implementation of key processes and functionality, suchas the program flow and the creation and use of the force feedback effects.

Full code listings can be found in Appendix E on page 276.

5.2 Programming Language and Input Devices

The selection of the language in which the game was developed had to consider the inputdevices which would provide force feedback effects. The devices that were to be used withinthis project were Microsoft Force Feedback 2 joysticks so as such the selected language hadto support the DirectInput library.

C# was selected as the programming language for two reasons: The first was that the

33

CHAPTER 5. IMPLEMENTATION 34

language itself is well documented and high level, allowing it to be learnt quite quickly.The second reason was that it is the only officially supported language that works with theXNA framework, a collection of libraries tailored for game development.

XNA was created in order to minimise the development of boilerplate code, code thatis repeated throughout the program with little alteration, and maximise the amount ofdevelopment on implementing the design (Microsoft, 2004).

Using C# with XNA allowed for rapid application development by providing a templatewhich contained the core structure of a game such as content loading, which is any externalfile needed to be loaded such as images, game loop functionality and screen rendering. Italso has support for standard C# libraries in addition to its own, allowing the support ofalternative input libraries.

The structure and core functionality required for a game, such as asset management (pic-tures and sounds) and game loops are handled automatically in pre-created functions, aswell as built in functions to handle the rendering of the game screen. This allowed devel-opment to be focused on the implementation of the game components instead of more lowlevel functionality.

The main drawback to using C# with XNA was that while games developed with it runnatively on both Windows and the Microsoft XBOX, it could only do this while using theXInput library, which is a library to interface with generic controllers and created to replacethe now deprecated DirectInput.

XInput itself does not support the Microsoft Force Feedback 2 joystick, so the Input Handlercomponent had to be developed in C# alone in order to enable utilisation of the joystickand its force feedback effects.

5.3 Game Engine

The game engine, as its name would suggest, is the driving component of the game. It isresponsible for initialising all additional components, running the game loop and endingthe game. A high level flow diagram of how the game engine operates is shown in Figure5.7 on page 43.

The initialisation process is split into three stages. The first stage is the initialisation ofall the game objects, which are the ball, block and player. Each game object stores stateinformation such as position, size and colour for a single instance of an object, such as oneplayer. On initialisation, numerous instances of the objects are created and the initial statevalues for each are set.


The second stage is the initialisation of the Input Handler, which on initialisation assignsa joystick to a player. The final stage is the initialisation of the Data Logger which ensuresthat the log file can be opened and is writable.

The Engine then commences the game loop, which will continually iterate until the gamesend condition is met. There are numerous sub-systems that are executed within the gameloop, the purpose of which is to update and modify the game objects. Table 5.1 on page5.1 shows all of the sub-systems within the engine with a description.

Sub-system Description

Collision Detection Checks whether the ball has intersected with another object

Object Movement Updates the position of the player and ball objects

Screen Rendering Obtains positional information from game objects and draws them

Table 5.1: Description of the subsystems within the game engine

What follows is a discussion on each of the subsystems and the objects and componentsthey interact with. This section then closes with a discussion on how configuration of theengine for differing ball movement speeds and enabling and disabling force feedback effectswas accomplished.

5.3.1 Collision Detection

In every iteration of the game loop, the engine checks for whether the ball has collided withanother game object, such as a player or block, and updates the object state if a collisionhas occurred. This is done by checking whether a ball object has intersected another object.

On the event of an intersection, the engine handles it differently depending on the object.For an intersection with a player, the engine instructs the Input Handler to play a forcefeedback effect if they are enabled. It then updates the ball state by calling a functionwithin the ball object called PlyrCollision(PlayerPosition), which takes the position of theplayer the ball has intersected as a parameter.

Figure 5.1: Shows how the direction of the ball is changed on collision with a player

This function changes the direction of the ball depending on the position on the playerobject the ball intersected with. It ignores the angle at which the ball approaches the


player in order to provide players with a predictable ability to aim. This can be seen inFigure 5.1 on page 35.

For an intersection with a block object, the Engine checks the player who last struck theball and the type of block the ball intersected with. Depending on the type of block, theengine updates the block and second ball state in a different way. As mentioned in thedesign, there are three block types. A standard block which is destroyed when a ball collideswith it, a player specific block where only the corresponding player can destroy it and amulti-ball block, which creates a second ball if it’s in play.

The engine checks the type of the block first. If it’s a multi-ball block, it then checks ifthere is a second ball already in play. If there isn’t, it updates the state of the secondball, firstly by changing location of the player who did not strike the ball last and secondlysetting the ball to active movement. It then sets the block to a destroyed state.

If the block is player specific, the engine checks the last player to strike the ball andcompares it to the owning player of the block. If there is a match, the block is set to adestroyed state. If it isn’t, the block state is not updated. Otherwise, the block is set to adestroyed state. For the standard block, it is always set to the destroyed state in the eventof a collision.

Figure 5.2: Shows how the direction of the ball is changed on collision with a block

After processing the block state, the engine updates the ball state by calling a functionwithin the ball object called BlockCollision(BlockPosition), which takes the position of theblock the ball has intersected as a parameter. This function changes the direction the ballis travelling in depending on the side of the block the ball intersected with. This can beseen in Figure 5.2 on page 36.

5.3.2 Movement

There are two movement sub-systems within the game engine: One that updates the po-sition of the player object and one that updates the position of the ball object. For themovement of the player object, the engine obtains calls the GetAxisState() function whichreturns a value between -5000 and 5000. This value represents the current position of thejoystick on the X axis.

The engine divides this value by 5000 in order to obtain a value between 0 and 1. It then


multiplies it by the maximum speed of the player to obtain an amount which the playerneeds to be moved. This amount it then sent to the player object which checks whether itcan move the required distance without hitting a boundary, such as the edge of the screen,using the CheckMove() function. The position of the player is then updated by an amountthat will always remain within the game area boundaries.

The code for this functionality within the engine is shown below.

// Accumulate the p l a y e r movement .accumove [ p lyrno ] . X += ( j s [ p lyrno ] . GetAxisState ( ) / 5000) ∗

p lyr [ p lyrno ] . p lyrspd ;

// I f the accumulated movement v e c t o r i s l o n g e r than a g iven// v a l u e .i f ( accumove [ p lyrno ] . Length ( ) > . 5 ){

// Check whether i t ’ s p o s s i b l e to move .Vector2 mv = plyr [ p lyrno ] . CheckMove ( accumove [ p lyrno ] ) ;

// Move the p l a y e r by the g iven amount .p lyr [ p lyrno ] . p lyrpos = plyr [ p lyrno ] . p lyrpos + mv;

}

To update the position of the ball object, the engine checks if a ball is active and if it is,adds the current velocity of the ball to its current position. It then uses a function withinthe ball object, CheckBounds(), which checks whether the ball is still in active play afterbeing moved. If the ball has fallen out of play, it is de-activated and the position is resetto the position of the player who was not last to hit it.

When a second ball is added into play, the engine also moves and checks if that ball hasfallen out of play. If has, the ball is de-activated and the position moved out of view untilanother grey block has been activated.

The CheckBounds() function is also responsible for changing the velocity of the ball if ithas struck a wall. If a wall has been struck, the direction along the X axis that the ball istravelling is inverted and a wall collision variable within the ball object is set to true. Inevery iteration of the game loop, the engine checks whether this variable is true. If it is,it instructs the Input Handler to play a collision effect before setting the variable in theobject to false.

5.3.3 Rendering

The XNA framework made it simple to render the objects to the game screen using builtin functions. In every iteration of the game loop, each object is drawn in turn based on the


game asset, position and colour. The following code shows the function to draw a player.

/// <summary>/// This f u n c t i o n draws a p l a y e r ./// </summary>/// <param name=” s t a t e ”>The p l a y e r to draw</param>private void DrawPlayer ( Player s t a t e ){

spr i t eBatch . Draw( plyrchar , s t a t e . p lyrpos , null , s t a t e . p l y r c o l ) ;}

The spriteBatch.Draw() function takes the asset name, the position and the colour of anobject which is to be drawn. Figure 5.3 on page 38 shows all the assets for each object.As can be seen, each asset starts of grey and it is the Draw function that changes thecolour.

Figure 5.3: The assets for each object in the game

5.3.4 Configuration

Due to the need for aspects of the game to be changed as necessary, the game had to beconfigurable. From the design it became apparent that there are two parameters that wouldhave to be configurable: The speed of the ball in order to switch between deliberative andintuitive thinking and the state of the force feedback effects in order to enable and disablethem when required.

As the game was a prototype, configuration was accomplished by providing two globalvariables in the engine: ball speed and force effects. The modification of these variableswould control this functionality for the entire game.

This meant that four different versions of the game had to be compiled: two for the slowball version, one for force feedback enabled and the other disabled, and the same two forthe fast ball version. While inconvenient, it was not an unmanageable way of configuringthe game.


5.4 Input Handler

The Input Handler component is responsible for connecting to the joystick, communicatinginformation from the joystick to the game engine and the loading of the force feedbackeffects.

There is one Input Handler for each player. Upon initialisation, it enumerates all of thedevices connected to the system that are joysticks which have force feedback effect capa-bility. It then checks whether it can gain exclusive access to that joystick to prevent otherinstances of the Input Handler to control it before it gives that access to the player. Ifexclusive access cannot be obtained, it moves on to the next device in the list. If it runsout of devices, the game quits.

Information provision is achieved through a set of functions within the Input Handler itselfwhich return the current position of the X-Axis and the current state of the fire button.The Engine requests and processes this data in every iteration of the game loop.

The loading and utilisation of force feedback effects is accomplished through the use ofexternal files and joystick parameters. The creation and utilisation of these effects is doc-umented in the following section.

5.4.1 Force Feedback Effects

Table 4.2 on page 28 shows that there are three unique force feedback effects that hadto be implemented: Collision rumble, Ball rebound and auto centre. The first two forcefeedback effects were loaded into the joystick from external .ffe files that were created ina force feedback editor. This can be seen in Figure 5.4 on page 5.4, which shows theprogram and the collision rumble effect for when the ball collides with an object, whichwithin this program is labelled blkhit.

The auto centre effect was a property of the joystick that could be set after finding andallocating exclusive access of the joystick to a player and prior to the loading of other forcefeedback effects. When this property is disabled, the joystick will not pull to the centreand instead is left loose, giving players no indication of whether they have returned thejoystick to the central position.

The effect operated on both the X and Y movement axis, regardless of the position of thejoystick. The code used to enable and disable the auto centring property of the joystick isas follows:

// I f f o r c e f e e d b a c k e f f e c t s are enabled , auto c e n t r e the s t i c k .// Otherwise , d i s a b l e i t and a l l o th er e f f e c t s .


Figure 5.4: The force feedback editor program used for effect creation

i f ( hapt ){

j s . P r o p e r t i e s . AutoCenter = true ;}else{

j s . P r o p e r t i e s . AutoCenter = fa l se ;}

As previously explained, the remaining two force feedback effects were created using theforce feedback editor. The following two figures show the details of each force feedbackeffect such as duration, strength and direction in the Y-Axis. The graph within both thesefigures show the range from -50% to 50%, which is the distance in percent that the joystickis moved backward or forward from the centre.

Figure 5.5 on page 41 shows the details of the ball collision rumble effect, which is playedwhen the ball collides with any object other than the player using the joystick. As canbe seen, the joystick is rapidly moved forward and backwards from the centre in order tocreate a vibration effect.


Figure 5.5: The strength, duration and direction of the ball collision effect

Figure 5.6 on page 41 shows the details of the effect played when the ball collides withthe player using the joystick. The joystick moves forward, before jolting back to the centrein order to simulate the effect of the ball rebounding off the player. The effect shown inthe figure is the one played when the ball collides with player 2. The effect for player 1 isthe same, only the joystick moves backwards instead of forwards due to the intended effectof moving the joystick away from the ball.

Figure 5.6: The strength, duration and direction of the block collision effect

As previously stated, these effects were stored in external files and were loaded after ex-clusive access had been granted to a player. A list was created into which each effect wasstored and then loaded to the joystick. The loaded effects could then be used by callingbuilt in functions to Start or Stop the effects. The code for loading each effect into a listis as follows:

// I n i t i a l i s e the e f f e c t l i s t .fx = new List<Ef fectObject >() ;

// Load t h r e e e f f e c t s f o r each p l a y e r .


fx . Add( LoadEffect ( ” b l k h i t . f f e ” ) ) ;fx . Add( LoadEffect ( ” p l y r 1 h i t . f f e ” ) ) ;fx . Add( LoadEffect ( ” p l y r 2 h i t . f f e ” ) ) ;

5.5 Data Logger

The data logging component is responsible for creating a file to log to and writing any datagiven to it to the created file.

Upon initialisation of the data logger, it checks to see whether a given log file exists andcan be opened. If the log file doesn’t exist, it attempts to create and set the names of eachcolumn in a defined structure. The code for this is shown below.

i f ( ! F i l e . Ex i s t s ( this . fn ) ){

l og = F i l e . CreateText ( this . fn ) ;

l og . WriteLine ( ” id , Player 1 Score , Player 2 Score , ” +” Fina l Score , Time Taken , B a l l s Lost , ” +”Game Speed , Haptics Enabled” ) ;

l og . Close ( ) ;}

Once the game is complete, the engine sends the data logger the data which it stores in thelog file. The engine itself is responsible for gathering and formatting the data appropriately,which it accomplishes by gathering the data from all of the objects and passing it as aparameter to the LogData(GameData) function. The code for the process of data logging isshown below:

l og = F i l e . AppendText ( fn ) ;

l og . WriteLine (GameData) ;l og . Close ( ) ;


Figure 5.7: Operational flow for the engine

Chapter 6

Pilot Study

6.1 Introduction

Following the design and implementation of the game, it was deemed necessary to conduct apilot study. The purpose of this was to validate the following areas of the main experimentprior to its execution:

• The procedure - The structure and execution of a single experiment run from startto finish

• The implementation - Ensuring that the game was free from bugs and that the gamemechanics met the requirements

• The data gathering methods - Whether the methods used to extract data yield ap-propriate and useful information

As such, the main focus of the pilot study was not to obtain data with which to satisfy thehypotheses within the project but to obtain data on the previous listed areas to ensure,among other criteria, that the hypotheses could be satisfied. Each area was looked at andrevised after the pilot study based on the data that was gathered. This is discussed infurther detail in the results and findings section which can be found later in this chapter.

Additionally, there were two variables within the game that had to be validated and revisedfrom the pilot. These were the force feedback effects and the speed of the ball, the latterbeing particularly important in the differentiation of deliberative and intuitive thinking.

44

CHAPTER 6. PILOT STUDY 45

It was important to establish that the force feedback effects were of an appropriate strengththat they were noticeable yet would not detract from the experience. With there beingtwo distinct ball speeds within the game, fast and slow, it was necessary to establish thefollowing:

• The fast ball was fast enough to engage intuitive thinking, yet not too fast so partic-ipants are unable to react in time

• The slow ball was slow enough to engage deliberative thinking, yet not too slow forit to become frustrating for the participants to play

The following sections show how the study was designed and executed followed by a dis-cussion on the results and the changes made to the procedure and implementation.

6.2 Study Design

As the main purpose of the study was validation and verification rather than data gathering,questionnaires were created with questions tailored to meet the experimental aims of theproject as well as the mechanics of the game. By obtaining participants opinions on boththe game variables and additional mechanics, such as the ability to aim, it allows the gameto be modified the so that it is fit for purpose.

While the data gathered would not be subjected to any analysis, they give an expectation ofwhat to expect from the actual study. If no meaningful data could be obtained during thepilot, it can be assumed that no meaningful data would be obtained during the experimentalstudy.

6.3 Study Execution

6.3.1 Participant Criteria

The pilot study ran with two pairs of participants with one pair for each ball speed. Theamount of participants was sufficient to validate each area as the data being gathered wasnot going to be used within the main experiment.

Due to this, there were no specific requirements on age, gender, previous experience or anyother factors. All of the participants who took part knew each other personally, but thiswas not a requirement.


For the pilot study, there was a preference that the participants came from a technicalbackground. This was so that any issues with the game mechanics and implementationspecific issues could be pinpointed to a greater precision.

Additionally, care was taken to ensure participants with a large amount of prior computergaming experience were partnered with those that had very little. This served as a controlto see if previous game experience affected the required speed of the ball.

6.3.2 Experiment Area

Figure 6.1: How the experiment area was set up, including approximate distances andscreen sizes

The experiment area consisted of two seats with a joystick in front of each, which is illus-trated in Figure 6.1, Page 46. There was a single monitor shared between both participantsand each participant was able to see and communicate with their partner directly.

The game itself ran full screen, with 90% of the space given to the playable area and theremaining 10% allocated to the game statistics. The way the game screen was divided canbe seen in Figure A.1 in Appendix A on 94, along with some key game states. Uponcompletion of the game, the player icons and statistics remain visible for participants to


see.

The photos in Figure 6.2 on page 47 and Figure 6.3 on page 47 show the set up of theexperiment when in use. Each photo is taken from a different angle to illustrate the setup in detail. The first photo was taken while participants were playing the force feedbackeffects disabled game and the second photo was taken while playing the force feedbackeffects enabled game.

Figure 6.2: A photo of participants playing the non-force feedback game

Figure 6.3: A photo of participants playing the force feedback game

Recordings of an experiment run are provided on the Project CD in Appendix F. Thevideos have been provided in Windows Media Video (WMV) and M4V format to maximise


compatibility. These will show in more detail how the experiment area was set up andutilised in practice.

6.3.3 Materials

The pilot study took place in the HCI laboratory within the University of Bath withthe experimental setup illustrated in the previous section. The single monitor shown wasconnected to a single machine on which the game ran. The game, monitor and machinetogether formed the materials required for the study to take place.

Additionally, each participant was provided with the following materials:

• A briefing/consent form

• A questionnaire to be filled out after playing the game with force feedback effectsenabled

• A questionnaire to be filled out after playing the game with force feedback effectsdisabled

• A general questionnaire to be filled out after both games have been completed

The briefing and consent form were integrated into a single document and served thepurpose of explaining to potential participants what they could expect from taking part inthe pilot study. The signed consent forms for the pilot can be found in Appendix C.1 onpage 105.

A video recorder was also used to record participants if consent was given in order toprovide not only areas of further analysis but also serve the purpose of illustrating how anexperimental run was performed for those who did not attend.

6.3.4 Procedure

For each run through of the experiment, a set procedure was followed. This was to ensurekey responsibilities were executed and that each run was consistent.

The following list details the procedure that was followed during each experiment run:


1. Show potential participants to the experiment area

2. Allow potential participants to place belongings somewhere safe while welcomingthem to the study

3. Give potential participants a copy of the brief/consent form

4. Informally explain the contents of the brief

5. Field any questions that participants may have

6. Once the consent form has been signed, restate that participants can opt to leave atany time

7. Show participants the game screen and explain key mechanics

8. Allow participants a trial run to get used to the controls and mechanics

9. Start experiment with the first game

10. When game is completed, give participants the first questionnaire

11. Once the first questionnaire is completed, start the second game

12. When game is completed, give participants the second questionnaire

13. Once the second questionnaire is completed, give participants a general questionnaire

14. Debrief the participants, explaining what data was obtained and what it will be usedfor


16. Thank them for participating

6.4 Results and Findings

While no data was analysed, the raw results can be found in Appendix D.1.2 on page 163and on the Project CD in Appendix F. The questionnaires completed by the participantscan be found in Appendix D.1.1 on page 143.

When commencing the first run of the pilot study, the procedure had to be modified dueto it being inadequate to gain certain comparative results. the original procedure requiredeach pair to play one game which would have force feedback effects either enabled ordisabled. Running the procedure in this way meant it would have been extremely difficultto use perceived time as a measurement of enjoyment, making it difficult to quantify theimmersive properties of the game (Sallnas et al., 2000).


This was rectified by requiring each pair to play two versions of the game, one with effectsenabled and the other disabled. Each game would be followed by a questionnaire thatwould be identical for each game, allowing comparative analysis between the two games.The order in which they would be played would be randomised so as order effects werecontrolled (Cohen, 1995). A trial run would be performed prior to commencing the realexperiment in order to minimise the effect that learning the game mechanics and controlswould have on the results.

While data was logged correctly and accurately in both runs, it also logged data fromthe trial runs. This is an issue with how data is logged indiscriminately, as it does notdifferentiate between a trial game and experimental run. As the date and time of each playis logged, it would be straight forward to discard any trial information in the main study,so this was deemed to not be an issue that required fixing.

The game operated reliably, with no random crashes or exceptions. However, issues withthe game mechanics presented during the pilot which required changes to the code. Thefirst issue was that the ball would not rebound off the player icons as expected. Specifically,in certain cases it would not rebound in the direction which the participants expected.

This is shown in the feedback received from Player 1 of the slow ball pair, where one oftheir questionnaires (Appendix D.1.1, page 153) stated that the ball “sometimes seemedto go off at odd angles” when rebounding off a player object. This was also noticed byPlayer 2 of the slow ball pair, where one of their questionnaires (Appendix D.1.1, page158) stated that the “Angle of reflection was sometimes a little ‘unpredictable’.”

This problem was more pronounced with participants playing the slow ball version, makingit more frustrating for the participants to play. Player 1 of the slow ball pair stated in aquestionnaire (Appendix D.1.1, page 153) that the “last block takes ages”, although itwas noticed by Player 1 of the fast ball pair (Appendix D.1.1, page 143).

The cause was due to the player object collision code assuming that the origin of the ballwas located in the centre when the actual origin was in the top left corner at 0, 0. Thesolution was to add half the ball width to the x position of the ball when calculating howthe ball should rebound.

The second issue that was noticed during the pilot was that the ball would sometimestemporarily get stuck within one of the blocks. This was referred to Player 2 of the fastball pair in one of their questionnaires (Appendix D.1.1, page 148) as “clipping issues”.

Upon further testing it became apparent that it was possible for the ball to become per-manently stuck within a block. This was due to the collision detection model that wasimplemented, which is illustrated in Figure 6.4 on page 51. Green denotes the area of theblock which would rebound the ball and move it away if it was detected. Within the greyarea, this detection does not happen.


Figure 6.4: Top: The original collision model. Bottom: The revised collision model.

If the speed of the ball was sufficiently high enough, it was possible that the position ofthe ball would have moved from outside of the block to within the grey area between eachiteration of the game loop.

The solution was to revise the collision model as shown in the previous figure, in whichthe ball will always rebound in a direction and be moved outside of the block by howevermany pixels inside the block it is. The implementation chapter contains further discussionon the revised collision model.

Overall the pilot study was a success, providing useful feedback about all aspects of thestudy. It prevented any major game breaking bugs from causing issues when running themain study and refined the process to enable improved data gathering. It also confirmedthat once the previously mentioned implementation issues were resolved, the game was fitfor purpose.

Chapter 7

Main Experiment

7.1 Introduction

Following the implementation of the required changes that were uncovered by the pilotstudy, the design and execution of the main experiment could take place.

The primary experimental question of this project is whether the addition of force feedbackeffects to a tightly coupled collaborative game improves task performance when cognitively,the task has different response requirements.

There are also two secondary questions to do with the participant perception. The first ofthese is whether the addition of force feedback effects improves how immersed a participantis in the game. The second is whether providing co-operative interference through theaddition of a second ball changes the personal goals of a participant and consequently theway the participants approach playing the game.

This section discusses the hypotheses created to answer the experimental questions, thedesign and execution of the study and finally a discussion of the results.

52

CHAPTER 7. MAIN EXPERIMENT 53

7.2 Study Design

7.2.1 Hypotheses

One of the purposes of the pilot study was to confirm two variables: ball speed and forcefeedback effects. These serve as the independent variables for this experiment, the valuesof which will affect the results of the three dependent variables. The dependent variablesserve the purpose of answering the primary experimental question.

The first of these variables is the amount of time taken. The game automatically storesthe total time taken to complete a single game which allows the timings for each pair to becompared. This comparative analysis will show the benefit, if any, provided by the additionof force feedback effects.

The second dependent variable is the amount of mistakes made during game play. Withinthis game, a mistake will be defined as a ball that falls out of play. For every ball that islost, the game will log each ball lost to a total so that the totals from each game can becompared to see how the amount of mistakes are affected by force feedback effects.

The final dependent variable is the amount of points each participant scored. The gameautomatically records the final scores of each participant after a game. These measurementscan then be compared to see how each participant’s score is affected by force feedbackeffects. In addition, each participant’s scores can be compared to see if any difference canbe observed.

Additionally, each participant would be provided with a number of questionnaires in orderto see if the perceptions of each participant corroborated the quantitative data providedas a result of the dependent variables. They also serve the purpose of recording how aparticipant feels about the game, such as perceived performance, perceived ease of use,ability to work together, personal goals and enjoyment.

With these dependent variables in mind, hypotheses can be drawn that will answer theexperimental questions.

Null Hypothesis: H01

The difference in timing between games that engage deliberative thinking with force feed-back effects enabled and those that have them disabled is not significant.

Alternative Hypothesis: HA1

The times recorded for the games that engage deliberative thinking with force feedback


effects enabled will be faster than those where force feedback effects are disabled.


The difference in timing between games that engage intuitive thinking with force feedbackeffects enabled and disabled is not significant.

Alternate Hypothesis: HA2

The times recorded for the games that engage intuitive thinking with force feedback effectsenabled will be faster than those where force feedback effects are disabled.


The difference in the amount of balls lost within games that engage deliberative thinkingwith force feedback effects enabled and disabled is not significant.


The number of balls lost in games that engage deliberative thinking with force feedbackeffects enabled will be lower than those where force feedback effects are disabled.


The difference in the amount of balls lost within games that engage intuitive thinking withforce feedback effects enabled and disabled is not significant.


The number of balls lost in games that engage intuitive thinking with force feedback effectsenabled will be lower than those where force feedback effects are disabled.


The difference between participant scores in games that engage deliberative thinking withforce feedback effects enabled and disabled is not significant.


The scores for each participant in games that engage deliberative thinking with force feed-back enabled will be higher than those where force feedback effects are disabled.



The difference between participant scores in games that engage intuitive thinking with forcefeedback enabled and disabled is not significant.


The scores for each participant in games that engage intuitive thinking with force feedbackenabled will be higher than those where force feedback effects are disabled.


The difference between perceived enjoyment of games with force feedback enabled anddisabled is not significant.


Participants will perceive themselves to have enjoyed games with force feedback effectsenabled more than those where force feedback effects are disabled.


The difference between perceived amount of mistakes in games with force feedback enabledand disabled is not significant.


Participants will perceive themselves to have made less mistakes in games with force feed-back effects enabled than those where force feedback effects are disabled.


The difference between perceived ease of use in games with force feedback effects enabledand disabled is not significant.


Participants will perceive the games with force feedback effects enabled to be easier thanthose where force feedback effects are disabled.


The personal goal of a participant does not change when a second ball is actively in play.



The addition of a second ball in play changes the personal goal of a participant.


The difference between perceived ability to collaborate in games where force feedback effectsare enabled and those that have them disabled is not significant.


Participants will perceive the games with force feedback effects enabled to be easier tocollaborate in than those where force feedback effects are disabled.


The difference between the perceived time taken to complete games with fore feedbackeffects enabled and those that have them disabled is not significant.


Participants will perceive the games with force feedback effects took less time to completethan those where force feedback effects are disabled.


The difference between perceived accuracy while aiming the ball in games where forcefeedback effects are enabled and those where they are disabled is not significant.


Participants will perceive the games with force feedback effects enabled to be easier to aimin than those where force feedback effects are disabled.

7.3 Study Execution

7.3.1 Participant Criteria

Unlike the pilot study which had no requirements for participant criteria, the experimentalstudy had certain limitations on in place as it is the traits of the participants such asexperience, age, gender and background which can affect the results of this experimentalstudy.


The project aimed to obtain, as a minimum, 12 pairs of participants. The justification forthis was so each permutation of ball speed and the order in which the force feedback effectsenabled version of the game is played would be executed at three times each. For all ofthe game permutations and the order in which they were given to participants to play, seeAppendix D.2.1 on page 165.

Given logistical constraints, primarily time and cost, the decision was made to limit thesampled population to that of undergraduate students studying at the University of Bath.Due to this limited population, it would not be accurate to state that conclusions madewithin this project would apply to the general population. While this limits the scientificsignificance of any findings made, it means that participant traits can be recorded moreaccurately.

All of the participants fell within an age range of 19-24 and all came from a scientific back-ground, primarily Computer Science, Mechanical Engineering and Chemical Engineering.Due to the age range and educational background of the participants, it would be reason-able to state that all participants would have at least encountered computer games andall have the ability to grasp the mechanics of the game in this experiment. Additionally,none of the participants suffered from conditions that could have affected their ability toparticipate, such as colour blindness and Repetitive Strain Injury (RSI).

All potential participants were required to bring a partner with them. This was done fortwo reasons: The first reason being the assumption that reliability of participant attendancewould be increased due to mutual reminders and a more relaxed study environment witha partner they know and so that all participants knew each other prior to the study. Thisserves as a control so that potential performance benefits would not be influenced by priorrelationships, but may also cause minor result bias.

Research suggests that males outperform females in tasks that involve spatial ability,whereas females outperform males in tasks that involve verbal ability (?). Due to thisdiffering ability between genders, it is important that the amount of participants from eachgender is balanced as much as possible. One way of controlling this would be to ensurethat all participants were of the same gender. Another way of controlling this would bethrough an approach called counterbalancing which would involve having an equal amountof male/male, male/female and female/female pairs. The former approach was attempted,but due to problems obtaining volunteers this was not possible. This is discussed furtherin the results discussion at the end of this chapter.

7.3.2 Experiment Setup

The main experiment, as with the pilot study, was performed in the HCI laboratory. Thiscreated a controlled environment in which participants could take part in the experiment


without outside interference.

The game itself ran on a single machine with a single monitor and two joysticks connectedto it. Figure 6.1 on page 46 illustrates this, as well as the positioning of participants inrelation to the location of the table. Screenshots from the actual game can be found inAppendix A on page 94 and show different key game states for illustrative purposes.

Photographs of the experimental area that were taken during the pilot study can be foundin Figure 6.2 on page 47 and Figure 6.3 on page 47. With it being a tightly-coupledtask, each participant could see and communicate with their partner at all times, as wellas having visual access to the progress of the other participant within the game.

The machine was required to run a Windows OS. preferably XP or above, due to the gamebeing coded in C# with XNA. Additionally, the machine was required to have .NET 2.0and the XNA Redistributable frameworks installed so that the game could run.

Recordings of an experiment run that was taken during the pilot study are provided onthe Project CD in Appendix F. The videos have been provided in Windows Media Video(WMV) and M4V format to maximise compatibility. They show in more detail how theexperiment area was set up and the positioning of the participants. Although the experi-mental run was taken during the pilot study, changes were not made to the way participantsplay the game. As such, experimental runs in the main experiment were the same as in thepilot.

7.3.3 Materials

The most significant material within the experimental study is the game itself, a discussionaround which can be found in Chapter on page , as well as the machine on which it willrun. Additionally, each participant was provided with the following materials:

• A briefing/consent form

• A questionnaire to be filled out after playing the game with force feedback effectsenabled

• A questionnaire to be filled out after playing the game with force feedback effectsdisabled

• A general questionnaire to be filled out after both games have been completed

The briefing and consent form were integrated into a single document and served thepurpose of explaining to potential participants what they could expect from taking part in


the experiment. The signed consent forms can be found in Appendix C.2 on page 111.

The two questionnaires provided after each game asked the same questions to enable com-parative analysis between the qualitative data obtained. The questionnaire provided at theend of the experiment contained more general questions to obtain further qualitative dataalongside information for controls such as gender, previous experience and relationship withtheir game partner. The completed questionnaires can be found in Appendix D.2.2 onpage 166.

Finally, the experiment was designed to be as ethical as possible. To accomplish this, achecklist was followed in regards to the research ethic guidelines of the department (Watts).The completed ethical checklist can be found in Appendix B on page 100.

7.3.4 Procedure

In order to maintain consistency between each experimental run, a set procedure wasfollowed. Following a set procedure ensures that all necessary steps are taken and that nocrucial steps are missed out. The procedure used within the pilot study was also used here,but the brief overview will be provided here for convenience:

1. Show potential participants to the experiment area

2. Allow potential participants to place belongings somewhere safe while welcomingthem to the study

3. Give potential participants a copy of the brief/consent form

4. Informally explain the contents of the brief


6. Once the consent form has been signed, restate that participants can opt to leave atany time

7. Show participants the game screen and explain key mechanics

8. Allow participants a trial run to get used to the controls and mechanics

9. Start experiment with the first game

10. When game is completed, give participants the first questionnaire

11. Once the first questionnaire is completed, start the second game

12. When game is completed, give participants the second questionnaire


13. Once the second questionnaire is completed, give participants a general questionnaire

14. Debrief the participants, explaining what data was obtained and what it will be usedfor


16. Thank them for participating

The atmosphere was made as informal as possible to ensure that participants were asrelaxed as possible. Participants were reassured that their prior experience and ability ofplaying games was not a factor that they should be worried about, as it was not theirability to play games that was being tested.

The trial run performed was kept the same between all runs to maintain consistency and toallow participants to become used to the controls, mechanics and the force feedback effects.Within the trial, participants completed a game through from start to finish as this wouldexpose all the subtleties of the controls and mechanics and reduce the effect of learning andthe chance of participants encountering something unexpected within an actual run.

As described earlier in the participant criteria section, the order in which participantsplayed the force feedback effects enabled and disabled games was pseudo-randomised tocontrol for order effects. 4 unique permutations of ball speed and force feedback effectswere identified, each of which would be executed the same amount of times. AppendixD.2.1 on page 165 shows the order of games played by participants.

During each run, observational notes were taken by the experimenter. In order to keepexperimenter bias to a minimum, observational notes were limited to noting down commentsparticipants made, potential flaws of the study exposed by an experimental run and obviousemotional responses such as anger or laughter. These can be found in Appendix D.2.6 onpage 272.

7.4 Quantitative Results

To test the results for significance a t-test for paired samples (otherwise known as a de-pendent t-test) using repeated measures will be used. The reason for using this is that allparticipants are paired and the same sample has been tested twice, as all pairs played boththe force feedback enabled and force feedback disabled versions which is what has beenanalysed within the results.

(Weiss, 1998) defines a dependent t-test as the following:


t =d

sd/√n

(7.1)

Where the degree of freedom used df = n− 1.

T-tests are used to compare the difference between two means in order to determine if thedifference in means is a coincidence or not.

To do this a p-value, p, is calculated. In order for statistical significance, p must be lessthan a given probability, which is defined as α. For this study, α = 0.05. If the valueof p is greater than that of α, there is no evidence to reject the notion that the meanswere different through random chance, thus not providing enough evidence to reject a nullhypothesis.

Experimental hypotheses can be found in section 7.2.1. The raw results of this study canbe found in Appendix D.2.3 on page 264 and on the Project CD in Appendix F. AppendixD.2.4 on page 266 contains more detailed analysis of data and appendix D.2.5 on page269 shows the graphs plotted from it.

7.4.1 Analysis of Time Results

The first set of results to be shown is the time comparisons for the completion of the task,starting with the deliberative thinking task. Table 7.1, page 61 shows the deliberativethinking results and a graph of each pairs time is shown in figure 7.1, page 62.

With FF Effects Without FF Effects Difference

Mean 07:04:20 08:28:20 01:24:00

Std. Dev. 01:49:46 04:13:36 03:51:28

Table 7.1: Results of game time analysis for deliberative thinking task

The results of the t-test for the deliberative thinking task shows no significance in theamount of time it took participants to complete (t(5) = 0.597668, p = 0.288049, α = 0.05).As p > α, there is no evidence to reject H01.

Table 7.2, page 62 shows the intuitive thinking results and a graph of each pairs time isshown in figure 7.2, page 63.

The results of the t-test for the intuitive thinking task shows no significance in the amountof time it took participants to complete (t(5) = 1.697644, p = 0.075166, α = 0.05). Asp > α, there is no evidence to reject H02.


Figure 7.1: Graph of the times taken for the deliberative thinking task


Mean 04:28:10 06:14:30 01:46:20

Std. Dev. 01:08:28 01:54:14 02:10:31

Table 7.2: Results of game time analysis for intuitive thinking task

The results of this section show that it is not possible to support either of the alternatehypotheses, which are that there is a decrease in the amount of time taken to complete atask when force feedback is enabled. This in itself does not show that task performance isnot increased, as the amount of mistakes made and the score that the participants obtainedalso factor in when considering the performance of a task. The amount of mistakes madewill be analysed in the next section.


Figure 7.2: Graph of the times taken for the intuitive thinking task

7.4.2 Analysis of the amount of balls lost

This set of results show the analysis of the amount of balls lost in the task, starting withthe deliberative thinking task. Table 7.3, page 63 shows the deliberative thinking resultsand a graph of the amount of mistakes each pair made is shown in figure 7.3, page 64.


Mean 7 11.33333333 4.33333333

Std. Dev. 1.414213562 6.470445631 6.562519841

Table 7.3: Results of ball loss analysis for deliberative thinking task

The results of the t-test for the deliberative thinking task shows no significance in theresults for the amount of balls lost (t(5) = 1.381104, p = 0.112892, α = 0.05). As p > α,there is no evidence to reject H03.

Table 7.4, page 64 shows the intuitive thinking results and a graph of the amount of mistakeseach pair made is shown in figure 7.4, page 65.

The results of the t-test for the intuitive thinking task shows significance in the results forthe amount of balls lost (t(5) = 2.917362, p = 0.016557, α = 0.05). As p < α, there isevidence to reject H04 and support HA4.

The results of this section show that while it can be said that there is no significant difference


Figure 7.3: Graph of the amount of balls lost by each pair for the deliberative thinkingtask


Mean 12.66666667 22.5 9.8333333

Std. Dev. 2.732520204 9.11592014 8.256310718

Table 7.4: Results of ball loss analysis for intuitive thinking task

in the amount of mistakes participants made in the deliberative thinking game, the samecannot be said for the intuitive thinking game. The evidence supports the alternativehypothesis HA4, which states that less mistakes are made when force feedback effects areenabled within the intuitive thinking game.

The final set of qualitative results that will be analysed is the final scores for each pair.


Figure 7.4: Graph of the amount of balls lost by each pair for the intuitive thinking task

7.4.3 Analysis of participant score

This set of results show the total score for each pair, starting with the deliberative thinkingtask. Table 7.5, page 65 shows the deliberative thinking results and a graph of the totalscore obtained is shown in figure 7.5, page 66.


Mean 57431.33333 50507.16667 8552.5

Std. Dev. 6302.910682 7941.117665 6912.455562

Table 7.5: Results of total score analysis for deliberative thinking task

The results of the t-test for the deliberative thinking task shows no significance in the totalscore obtained by participants (t(5) = −1.92013, p = 0.0564, α = 0.05). As p > α, there isno evidence to reject H05.

Table 7.6, page 66 shows the deliberative thinking results and a graph of the total scoreobtained is shown in figure 7.6, page 67.

The results of the t-test for the intuitive thinking task shows significance in the total scoreobtained by participants (t(5) = −7.24748, p = 0.0039, α = 0.05). As p < α, there isevidence to reject H06 and support HA6.

The results of this section show that while it can be said that there is no significant difference


Figure 7.5: Graph of the total score for each pair for the deliberative thinking task


Mean 57742.5 34847.66667 22894.83333

Std. Dev. 6528.919658 9483.762601 7737.950256

Table 7.6: Results of total score analysis for intuitive thinking task

in the total score participants obtained in the deliberative thinking game, the same cannotbe said for the intuitive thinking game. The evidence supports the alternative hypothesisHA6, which states that the average participant score will be higher when force feedbackeffects are enabled within the intuitive thinking game.

With all the quantitative data having been presented, the analysis of the qualitative resultsconcerned with each participants perceptions will be presented in the following section.

7.5 Qualitative Results

All of the data has been extracted from the completed participant questionnaires. Thesecan be found in Appendix D.2.2 on page 166, as well as observation notes made duringeach experimental run which can be found in Appendix D.2.6 on page 272.

All participants noticed the force feedback effects, with no participants finding the strengthof the forces to be too weak. The minority of participants felt that the effects were too


Figure 7.6: Graph of the total score for each pair for the intuitive thinking task

strong, but this will be discussed in a later section.

Every participant understood the basic mechanics of the game. More subtle control nu-ances, such as how the ball specifically rebounds off the participant, were picked up on by aminority of participants and misinterpreted by others, but this may be due to the technicalbackground and previous experience with computer games. In order to verify this, moreresearch would be required.

Participant perception, unless otherwise noted, was measured using a Likert 5 point scale(Sallnas et al., 2000). The scale reads from negative to positive, so a value of 1 wouldindicate a negative perception, 3 would indicate a neutral perception and a value of 5 wouldindicate a positive perception. For the purposes of simplifying the data, if a participantprovided a score with a decimal point it would be rounded up if equal to or greater than0.5. Otherwise the value they gave would be rounded down.

7.5.1 Perceived Enjoyment

As with the quantitative results, the qualitative results will begin with the analysis ofthe deliberative thinking task. Table 7.7 on page 68 shows each participants perceivedenjoyment for the force feedback enabled and disabled games.

The results show that although data for both with and without force feedback effects arequite spread out, the majority of participants preferred the game with force feedback en-


1 2 3 4 5 avr

Effects 0 0 3 5 4 4.08

No Effects 1 0 5 5 1 3.42

Table 7.7: Results of perceived enjoyment for deliberative thinking task

abled. Before supporting or rejecting any hypotheses, the intuitive results will be analysed.Table 7.8 on page 68 shows each participants perceived enjoyment of the intuitive thinkinggames with force feedback enabled and disabled.

1 2 3 4 5 avr

Effects 0 0 3 5 4 4.08

No Effects 0 1 9 2 0 3.08

Table 7.8: Results of perceived enjoyment for intuitive thinking task

The results show a more positive slant for the force feedback enabled game than the delib-erative thinking version. As such, there is evidence to reject H07 and support HA7.

This hypothesis is also supported by the observations made during experimental runs, wherecomments were made stating that participants didn’t like the game when force feedbackeffects were disabled and that they enjoyed the game more with them enabled. Additionally,within the questionnaires 19 out of 24 participants expressed their preference for the forcefeedback enabled versions as the one they preferred.

7.5.2 Perceived Mistakes

This set of results show the amount of mistakes participants perceived themselves to havemade, starting with the deliberative thinking task. Table 7.7 on page 68 shows eachparticipants perceived enjoyment for the force feedback enabled and disabled games. Avalue of 1 indicates that a participant felt they made a lot of mistakes and a value of 5indicates that they felt they made no mistakes at all.

1 2 3 4 5 avr

Effects 1 2 2 4 3 3.5

No Effects 1 1 6 3 1 3.17

Table 7.9: Results of perceived amount of mistakes for deliberative thinking task

The results for both with and without force feedback effects are spread out, with no sub-stantial support for or against the perceived amount of mistakes. As previous, the analysis


of the results for the intuitive thinking game will be presented first. Table 7.10 on page69 shows each participants perceived amount of mistakes in the intuitive thinking gameswith force feedback enabled and disabled.

1 2 3 4 5 avr

Effects 1 3 2 6 0 3.08

No Effects 1 6 3 2 0 2.5

Table 7.10: Results of perceived amount of mistakes for intuitive thinking task

As with the deliberative thinking task results, the data is largely spread out and providesno substantial support for or against the perceived amount of mistakes. As such, there isno evidence to reject H08.

7.5.3 Perceived Ease of Use

This set of results show how participants felt about how the addition of force feedbackaffected the perceived ease of use. Table 7.11 on page 69 shows the perceived ease of usefor both game types. A value of 1 indicates that a participant felt that the addition offorce feedback effects made the game much harder and a value of 5 indicates that they feltthe addition of force feedback made the game easier.

1 2 3 4 5 avr

Deliberative 0 0 4 5 3 3.917

Intuitive 0 2 0 7 3 3.917

Table 7.11: Results of how participants felt about how force feedback effects affected per-ceived ease of the game

The results show that while the data is spread out, especially for intuitive thinking, it isquite heavily in favour of force feedback making the game easier to use. As such, there isevidence to reject H09 and support HA9.

This hypothesis is also supported by the evidence collected from the observations of eachexperimental run, where comments stated that force feedback effects made the game a loteasier and more engaging to play.


7.5.4 Personal Goals

This set of results show how participants felt about how the addition of a second ball intoactive play changed a participant’s personal goal.

Out of 24 participants, 22 stated that their personal goal was changed by the introductionof a second ball into active play. More than half of participants stated that the addition ofa second ball changed the way they played the game in order to reach this new personalgoal. As such, there is evidence to reject H010 and support HA10.

7.5.5 Perceived Ability to Collaborate

This set of results show how participants felt about their ability to work together with theaddition of force feedback. Table 7.12 on page 70 shows the choice of each participant ofwhich game they believed was easier to work in with their partner.

Force Feedback No Feedback Neither

Deliberative 6 1 5

Intuitive 8 2 2

Table 7.12: Results of which game participants believed easier to work together in

Within the deliberative task, there appears to be a split in opinion, with half the partic-ipants believing it was easier to work with their partner when force feedback effects areenabled and the majority of the remainder believing that there was no difference. The re-sults for the intuitive thinking task are different, with the majority of participants findingit easier to work with their partner when force feedback effects are enabled. As such, thereis evidence to reject H011 and support HA11.

7.5.6 Perceived Time to Complete

This set of results show how participants felt about how the addition of force feedbackaffected the perceived time to complete. Table 7.13 on page 71 shows the choice of eachparticipant of which game they believed took longer.

Both participants in pair 02 of the intuitive game participants (pair 03 overall) believedthat the no feedback game took longer (Questionnaires can be found in Appendix D.2.2,page 183), when the actual result was that the force feedback game took 52 seconds longerto complete. This could be due to both participants stating that they enjoyed the forcefeedback version more.


Force Feedback No Feedback

Deliberative 3 9

Intuitive 3 9

Table 7.13: Results of which game participants believed took the longest to complete

The participants in pair 03 of the intuitive game participants (pair 06 overall) were splitdown the middle (Questionnaires can be found in Appendix D.2.2, page 208). While theactual results were that the force feedback enabled game was faster by 02:28, participant2 believed the force feedback enabled game took longer. This could be due to that partic-ipant’s perception, as comments were made on the questionnaire which stated that theyperceived the participant to move more quickly when force feedback effects were disabled,even though this wasn’t the case. They also perceived the no feedback version to be easierto use and more enjoyable.

The participants in pair 04 of the slow ball game (pair 08 overall) were also split down themiddle (Questionnaires can be found in Appendix D.2.2, page 224). While the actualresults were that the force feedback enabled game was slower by 36 seconds, participant1 believed the force feedback disabled game took longer. This could be due to the smalldifference between the time taken coupled with the questionnaire results which stated thatparticipant 1 enjoyed the force feedback enabled version more while participant 2 enjoyedthe force feedback disabled version more.

Both participants in pair 06 of the slow ball game (pair 12 overall) believed that theno feedback game took longer (Questionnaires can be found in Appendix D.2.2, page256), when the actual result was that the force feedback game took 31 seconds longer tocomplete. This could be due to the small difference between the times taken, coupled withboth participants stating that they enjoyed the force feedback enabled version more.

Due to the nature of the results, further investigation would have to be performed beforeany conclusions could be drawn. As such, there is no evidence to reject H012.

During the experiment it became apparent that there was a fringe case where a pair was ableto destroy a large number of blocks in rapid succession. This created potentially anomalousdata and biased participants for the remainder of the run. This exposes a potential flaw inthe experimental study which will be discussed in more detail within the conclusion section.

7.5.7 Perceived Ability to Aim

This set of results show the amount of aiming accuracy participants perceived themselvesto have, starting with the deliberative thinking task. Table 7.14 on page 72 shows


each participants perceived ease of positioning the paddle for accurate aiming in the forcefeedback enabled and disabled games. A value of 1 indicates that a participant felt it wasvery hard to aim and a value of 5 indicates that they felt it was very easy to aim.

1 2 3 4 5 avr

Effects 0 2 1 7 2 3.75

No Effects 2 1 5 2 2 3.08

Table 7.14: Results of perceived ability to accurately aim for deliberative thinking task

The results show that although data for both with and without force feedback effectsare quite spread out, the majority of participants felt that force feedback effects made iteasier to aim within the game. Before supporting or rejecting any hypotheses, the intuitiveresults will be analysed. Table 7.15 on page 72 shows each participants perceived ease ofpositioning the paddle to aim in intuitive thinking games with force feedback enabled anddisabled.

1 2 3 4 5 avr

Effects 0 3 3 5 1 3.33

No Effects 0 2 9 1 0 2.92

Table 7.15: Results of perceived ability to accurately aim for intuitive thinking task

The results show that for the intuitive thinking task, force feedback effects were not per-ceived to improve accuracy significantly, unlike the deliberative thinking task. As such,there is evidence to reject H013 and support HA13, with the caveat of it only applying tothe intuitive thinking game.

7.6 Discussion of Results

Within this project, task performance can be seen as the combination of three unique areas,all of which are derived from the dependent variables:

1. The time taken to complete the task

2. The amount of mistakes made during the task

3. The amount of points earned during the task

The most interesting finding is that for the deliberative thinking task there is no evidenceto support force feedback effects improving task performance. Conversely, there is evidence


to support force feedback effects improving task performance in 2 out of the 3 areas forthe intuitive thinking task. Reasoning for why this may be will be articulated within thissection.

The findings for the amount of time taken show no evidence to support that force feedbackeffects reduce the amount of time taken to complete a task. For the deliberative thinkingtask, this contradicts the existing findings discovered in the literature review, which statesforce feedback effects reduced the amount of time taken (Sallnas et al., 2000). This couldbe due to the fact that the task performed within that study was one of block manipula-tion using a SensAble PHANToM as a haptic device, which differs greatly from the taskperformed in this game using the Microsoft Sidewinder Force Feedback 2 as a haptic de-vice. It could be that the force feedback effects used within this task were unable to assistparticipants in completing the game faster.

This finding was supported by the qualitative data, as there was no evidence to supportthat participants had perceived any time decrease in time taken to complete for bothdeliberative and intuitive games. Most of the participants correctly chose the game thattook longer, unless there was little difference in time between force feedback enabled andforce feedback disabled games.

A decrease in the amount of mistakes made was only supported within the intuitive thinkinggame. This observation may have only been made within the intuitive thinking game tothe speed of the ball used to stimulate the cognitive response. The deliberative thinkinggame had a slower moving ball while the movement speed of each participant remainedthe same between both intuitive and deliberative thinking. Observational notes observeda tendency to overshoot the ball in the intuitive thinking game when force feedback effectswere disabled, but this was not observed in the deliberative thinking game as participantsalways had time to reach the ball and compensate for overshoot, if any.

What force feedback effects were observed by the experimenter to induce change in thedeliberative thinking game was the accuracy of aiming. This is supported by the qualitativedata that concluded that force feedback improved the ability to aim but only within thedeliberative thinking task. It appeared that participants perceived there to be no benefit toaiming when force feedback effects are enabled in the intuitive thinking game. qualitativedata for the perceived amount of mistakes appears to support the notion that participantsperceived no benefit for both types of thinking even when there was one due to the mixedresults received.

The final findings about task performance were the total scores achieved by a pair. An in-crease in the average total score when force feedback effects were enabled was only observedwithin the intuitive thinking game. A reason for this could be due to the close link betweenscore and the amount of mistakes made by both participants. The more participants rallya ball between each other without it falling out of play, a score multiplier is increased to amaximum of 10. Due to the larger average balls lost in the intuitive thinking game when


force feedback effects are disabled, this would entail a constantly low score multiplier. Withthe lower amount of balls lost when force feedback effects are enabled, the average scoremultiplier would have increased. This is a potential improvement and something whichcould have been calculated and recorded if considered during the design phase.

Comparatively, there was no significant difference in the amount of mistakes participantsmade in the deliberative thinking game. This would have led to similar average scoremultipliers which would mean the scores that came out at the end would be similar, whichare reflected in the results in Figure 7.6 on page 67.

Immersion could not be measured using temporal dissociation, as participants were notasked how long they believed it had taken but which one they thought took longer. Instead,participants were asked directly which version of the game they enjoyed more. The resultsshowed that participants on average preferred the version with the force feedback effects,with comments stating that it made it more fun and engaging.

Evidence to suggest that force feedback effects made the game more immersive was pro-vided through observational notes made. Some pairs were observed talking about topicsother than the game. For example, when force feedback effects were disabled pair 02 wereobserved talking about the upcoming Formula One season. When force feedback effectswere enabled, all conversation was focused on the game. This was also observed for otherparticipants.

It cannot be stated conclusively whether perceived enjoyment, ease of use and ability tocollaborate are related. All of these areas showed strong evidence to suggest benefits whenforce feedback effects were enabled, with participants stating that the game was easier touse and that it was easier to work with their partner, irrespective of the cognitive responserequirements. Participants who stated that they enjoyed the force feedback enabled versionsmore usually also reported an increased ability to collaborate and increased ease of use,but in order to draw a conclusive finding, further study would need to be performed.

It was observed that providing interference t]o the co-operating participants through theaddition of a second ball changed the personal goals of the majority of participants. Therewere three distinct goals which participants had reported that their own goal had changedto. These are:

1. To keep both balls in play

2. Pass the ball to the second participant to have one each

3. Keep both balls so as to increase their individual potential score

Participant’s personal goals usually changed to at least one of these listed goals, but some-times it was observed that it had changed to a combination of two of these. What their


personal goal changed to depended on the way they were collaborating with their partner,such as taking more of an adversarial stance.

Evidence suggests that participants may have had an overall personal objective for theduration of the game, for example to obtain the highest score, and immediate goals, whenachieved, would enable them to meet this objective. The addition of the second ballcould have caused participants to reconsider these immediate goals in order to achieve theobjective, which could remain static. There is not enough evidence to support claims suchas these within this project, but it is a very interesting topic that could be studied further.

During the experimental runs, an interesting observation was made about the relationshipsbetween the participants. While it was stipulated that all participants knew each other,the level of previous knowledge was not recorded. From the observational notes madeduring the experimental runs, it appeared that participants who were in a more intimaterelationship than friendship co-operated in a notably different way than those who wereacquaintances and friends. While this may have had an adverse affect on the results as thiswasn’t controlled for, it was also an interesting topic that could be used for further study.

An important factor was that there was no differentiation between the different types offorce feedback effects. There are two distinct types of effect used to convey two differentpieces of information: Resistance effects applied to each participant character to providethe feeling of weight and rumble to provide information about the current collision state ofthe ball. By not differentiating between these two different force feedback effects, it cannotbe said which one or whether it was a combination of both that made any difference. Thisidentifies a weakness of the study that was executed, but is also a potential avenue offurther study.

Another important factor that could have biased qualitative results is the existence of afringe case within the game itself which was mentioned previously. It caused the majorityof blocks to be destroyed if a participant is able to get the ball to approach at a certainangle. When this occurred, the majority of blocks were destroyed which would bias theopinion of participants into thinking that they had performed far better, even if by the endof the run they had performed substantially worse. This is discussed further in the criticalanalysis section of the conclusion on page , as it is a flaw of the task which translated intoa flaw within the study itself.

There were certain restrictions on participant gender due to the differing natural abilitieseach sex has for different types of task, but these were relaxed due to difficulties in obtainingvolunteers. As such, 3 of the 12 pairs composed of male/female pairs, all of whom werein a relationship. It was impossible to obtain female / female pairings due to constraintsin time, eliminating the option of counterbalancing for gender specific abilities. It can beassumed that this had an effect on the results, so further study would be required in orderto discover the extent to which results were affected.


The results and findings made during this experimental study opened up potential furtheravenues of study, such as the separation of force feedback effects, the separation of hapticinformation from visual and aural and participant relationships. These are discussed in theFurther Work section in the conclusion section.

A final, important point is that these results make no conclusive statement about forcefeedback effects affecting all of these discussed areas for all types of task. They merelypresent evidence to support the affect of force feedback effects on this particular task forthe sampled population, which in this experiment is made up of students. These resultsprovide firm groundwork in which further experiments can be performed with more rigidand differing controls, and larger samples of the overall population rather than solely stu-dents to provide more conclusive evidence. Further discussion on this can be found withinthe conclusion section.

Chapter 8

Conclusions

8.1 Introduction

The project began with a review of related literature, beginning with the two domains thatare crucial to this project: Haptics and Collaboration.

From this, an understanding was gathered about the haptic modality, its difference fromother information provision modalities such as visual and auditory, and the provision ofadditional information through this haptic information. Force feedback devices, mechan-ical systems used to transmit haptic information, were shown to fall into three differentcategories based on the range of force feedback effects they could produce.

Research was then conducted which showed that the provision of haptic information on taskperformance, perceptions and immersion. Not only did the provision of haptic informationprovide positive results for all three, it was this stage of the research in which the twodomains of haptics and collaboration began to cross over, through research that measuredtask performance and perceived presence in collaborative virtual environments.

From this, the domain of collaboration was then explored. It began by distinguishing be-tween collaboration and cooperation, with the former being the creation of shared andpersonal goals, and the latter being the identification of tasks in order to meet these afore-mentioned goals. Coupling in collaborative environments was then defined, showing thattightly coupled collaborators had a high level of interdependence and for loosely coupledcollaborators, the opposite.

Lastly, the dual process model for decision making was introduced. Tasks, collaborativeor not, could require different decision making processes based on the requirements of the

77

CHAPTER 8. CONCLUSIONS 78

task. An intuitive task required immediate, automatic decisions whereas deliberative tasksallows for decisions to be controlled and effortful.

These concepts gathered from research into the field were used to aid in the design of acollaborative task and a game concept in which the task would be executed. The task itselfhad a core set of requirements that it had to meet in order to provide recordable measuresthat were useful.

Following this, the game was designed. Every decision made during the design of thedifferent game states and mechanics was heavily influenced by the findings in the literatureand the aims of the project. This allowed a game that was suitable, relevant and appropriatefor the data which it was required to provide when played.

After the implementation in which the core system components were explained, a pilotstudy was conducted to ensure that not only was the developed game fit for purpose, butthe design of the study itself would also provide relevant and useful information. The studyfound that the information provided by the game was useful and yielded critical bugs whichhad to be fixed prior to the experimental study.

The main experimental study was then conducted, which used 12 pairs of participants splitbetween games that stimulated the two types of thinking, deliberative and intuitive, toprovide data in order to be able to answer three experimental aims: The performance ofthe task with and without the provision of force feedback effects, the effect of interferenceon personal goals and the affect of force feedback effects on the feeling of immersion.

The study found that there was a positive effect on task performance when force feedbackeffects were supplied only during the intuitive task. Conclusive evidence was providedto state that a personal goal is changed with the provision of interference. There wasalso evidence to suggest force feedback effects improve enjoyment, which could suggest aheightened sense of immersion.

This chapter begins with in depth discussions into more high level findings and hypothesesthat have been drawn as a result of the combination of existing literature and findings.This is followed by a critical analysis of the task design and experiments. The chaptercloses with a discussion on the further work that could be performed.

8.2 General Discussion

Prior to providing any in depth discussion, this section opens with a discussion that differ-entiates the provision of haptic information from additional information. It then discussesmore in depth, high level concepts and hypotheses based on, but cannot draw directly from,


the data gathered from the experimental study.

8.2.1 Provision of Additional Information

There are numerous modalities of information provision for humans. Within Human Com-puter Interaction, there are four channels of information: Visual, Auditory, Haptic andMovement (Dix et al., 2003). Any of these modalities can be combined to provide ad-ditional information to the user of any system, and it is common to combine visual andauditory in an effective manner (Gee et al., 2003).

Within this project, the haptic channel was chosen to provide additional information, us-ing force feedback effects provided by a joystick. As the haptic channel is one of manymodalities that can provide information, it cannot be stated conclusively whether any ofthe findings in the results or conclusions occurred due to the provision of haptic informa-tion specifically. Any results and conclusions may have occurred if the information wasprovided through another modality, such as auditory.

Qualitative data suggests that the findings observed were at least partially due to theprovision of haptic information, as Player 1 of Pair 01 stated that the “controls felt veryloose” when force feedback effects were disabled. Player 1 of Pair 06 stated that the forcefeedback effects made the joystick “stiffer, which felt easier to guide the paddle.” This isfeedback that would not be observed with information provided through any other channel,as they are specific comments about the haptic information.

Additional information was provided about two different objects, the player object and theball object. As the difference between the two were not clearly defined for the study, evenif it could be stated definitively that it is the addition of haptic information which causedthe observed findings, it could not be stated which object caused it or whether it was acombination of the two.

While the previously given qualitative data, in addition to Player 1 of Pair 04 statingthat the lack of ball collision vibrations “didn’t really effect” them, indicates that therewas separate information being provided and each of them had a perceived value andquality. Qualitative data suggests that the additional information about the player objectthat provided a feeling of weight was perceived to be of more value than the additionalinformation about the objects the ball object had collided with.

In order to state any conclusive findings about the value of haptic information, two sup-plementary studies would have to be performed. The first should separate the ball objecthaptic information from the player object haptic information and compare the objectiveand subjective worth of these, to see if there is a difference in the quality of informationprovided about different objects within the same work environment.


The second study would compare the haptic information for one object, such as the ballobject colliding with another object, and compare it to the same object where additionalinformation is provided by a different modality, such as aural. The observed outcomes couldthen be compared to see whether any observations made about one modality can be madeabout another, or whether one modality is better than another for providing informationabout that specific object.

8.2.2 Task Performance in Visual Spatial tasks

While the results showed that task performance was increased for intuitive thinking taskswhen force feedback effects were enabled, it was unspecific about the nature of the task.What can be said conclusively about the results is that task performance was increased forintuitive thinking visual spatial tasks when force feedback effects were enabled.

Research has shown that there are two different types of learners: Auditory sequential andvisual spatial (Silverman, 2000). Auditory sequential learners are defined by their abilityto process information logically from start to finish, with hearing being their preferredmodality. Visual spatial learners process information by visualising and seeing the conceptsand ideas, with sight being the preferred modality.

For visual spatial learners, it is common for them to excel at tasks that require hand-eyecoordination, such as mazes, mechanics and three dimensional puzzles. Auditory sequentiallearners are defined by their ability to memorise and process information in words, so excelin verbal reasoning, language and communication.

Research has shown that there is a gender specific difference in the ability to perform tasksfor these different types of learning (Colom et al., 2004). Men tend to perform better invisual spatial tasks while women tend to perform better when verbal reasoning is required.

As such, it cannot be said that haptic information improves the performance of all tasks,as it has now been established that there are tasks which have requirements beyond thatof merely being deliberative and intuitive.

This provides an avenue for further study which could study the benefits of haptic oradditional information to task performance in tasks that require verbal reasoning for visualspatial learners. By providing additional information through a learners preferred modality,it could be hypothesised that task performance will increase. This is discussed in the furtherwork section, along with the potential for research of gender specific benefits.


8.2.3 Immersion

The more immersed a person is in a task, the more attentional resources they dedicate tothe completion of that task and the less aware they are of their immediate surroundings.During the execution of the experimental study, it became apparent that how immersedparticipants felt was dependent upon how much they enjoyed the experience they had was.

What cannot be said is which one of these factors affect the other. It could be that beingmore immersed in a game increases the enjoyment felt, or the other way round. Furtherstudy would be required in order to find out which, but both immersion and enjoyment areexperiential; dependent upon how one feels and the experience they had while, for example,playing a game.

The experience that participants had appears to be affected by two factors: Engagementwith the task and engagement with their collaborative partner.

Results suggest that players who had a large amount of previous experience with computergames had an expectation of the movement speed of game objects based on similar gamesthey had played previously. This meant that they would enjoy a game where they perceivedthe ball to be travelling at the “correct” speed, merely because it confirmed what they hadexpected.

This is known as confirmation bias, where a person will interpret evidence based on pre-existing expectations or hypotheses (Nickerson, 2004) and can be seen in questionnairecomments. Player 2 of pair 02 stated that they “liked it being fast”. Player 2 of pair 02stated that the ball speed being faster made the game “more exciting and engaging” andthat “slow would be boring”.

Qualitative data suggests that participant’s perception, and thus engagement with the task,were changed when haptic information was provided. Player 2 of pair 05 stated that onlythe version without haptic information “felt slow”, and that when it was provided it felt“much faster”. Player 2 of pair 06 felt that when haptic information wasn’t provided, thatthe player object “appeared to glide or float horizontally, thereby enabling a more rapidresponse”. In both these cases, there was no difference in object speed between the games.

As it was stipulated that each participant must know their partner personally, it can beassumed that participants had expectations of how well they would work with their partnerprior to commencing this study. Observation notes and questionnaire answers stated thatthe very experienced participants who were partnered with those with no experience tendedto argue more and become frustrated, but this could be due to the relationship of theparticipants. This is discussed in further detail in the Relationships and Communicationsection.


As immersion is a subjective feeling, it is possible that numerous aspects could affect it.By a participant merely knowing that they are being observed in a controlled experimentcould adversely affect the feeling of immersion. Due to this, it would be difficult to statewhether the provision of haptic information gives a heightened sense of immersion withoutfinding a way of performing non-invasive observations.

8.2.4 Objectives and Personal Goals

Within the experimental study there was strong evidence to suggest that the provision ofinterference by adding a second ball object into play changes the personal goal of a player,which in turn changed the attitude of that player towards the game.

During results analysis, it was hypothesised that the participants may have been pursuingan objective, which could either be the collaborative objective to destroy all the blocks ora different, personal objective, such as to win. The introduction of interference changedthe way a player could achieve this goal and as such, may have changed their personal goalto better meet the objective.

The personal goals that were observed within the study appeared to fall into one of twodistinct categories. Some participants had cooperative goals in mind, such as ensuring theirpartner was involved and passing the second ball to them if they weren’t in control of one.This can be thought of as cooperative collaboration, where people have mutual goals andresources are shared.

Other participants were observed to have more competitive goals. This was signified bypersonal goals such as beating their partner in score and hogging both balls if possiblewhenever one was in play. This can be thought of as adversarial collaboration, wherepeople with opposing goals work together for the mutual benefit of both (Cohen et al.,2000). Usually, adversarial collaborators will only reveal information that is necessary tocomplete the collaborative task in order to remain secretive.

In addition to the creation of the ball, there are two other game states that were observedto change the attitudes of the players towards the game, which have been deemed the “freefor all” state and the “pseudo-deadlock” state. Figure 8.1 on page 83 illustrates thesestates.

The “free for all” state has been deemed as such due to the observations made during it.Adversarial collaborators were observed to focus on destroying as many blocks as possibleand actively attempting to prevent their partner from having the ball. Visible disappoint-ment was expressed when this occurred, followed by joy if their partner then proceeded tolose the ball out of play which returned control of the ball to them.


Figure 8.1: The 3 player attitude changing states

Cooperative collaborators ensured that the ball was passed between each participant. Acommon strategy became used between pairs, where a participant would hit one or twoblocks before passing the ball to them to ensure that they were involved.

The “multiball” state is defined by the addition of a second ball object into active playand was the game state which was looked at in most detail within this project. Adversarialcollaborators were observed avoiding the addition of a second ball object at the location ofthe other unless they could find some benefit in it for themselves. Player 2 of pair 10 sawthe addition of a second ball object as “more opportunity to score” for themselves.

Co-operative collaborators were observed to take the approach of actively trying to createa second ball as soon as possible and then ensuring each participant had one ball each inorder to maximise their involvement. Player 2 of pair 07 stated that on the addition of asecond ball, they “tried to keep both balls on opposite sides.”

The final state, “pseudo deadlock”, was arguably the most interesting state. With theblocks in that sequence, the game entered a near deadlock state that demanded effectivecooperation between both players in order to destroy the blocks.

The approach taken in both adversarial and cooperative collaborators was the same. Eachparticipant actively communicated and strategized with each other in order to line up a


shot to successfully destroy one of the blocks. At this point, adversarial collaborators wereobserved to not mind which player specific block was aimed for as long as one of them wasdestroyed, ending the deadlock and allowing players to reach the end game state.

There was an observed difference between adversarial and cooperative collaborators oncethe deadlock state had been resolved. If the last block of an adversarial collaborator wasdestroyed, they would no longer be interested in actively assisting their partner in destroyingtheirs, beyond merely bouncing the ball back.

Pair 10 was an example of where this was observed. Player 2 of this pair, knowing thattheir last block had been destroyed and that it was impossible for player 1 to beat theirscore, no longer bothered to assist in playing the game. To him, the game had alreadyended as his objective, to beat player 1, had been accomplished.

With cooperative collaborators, they continued the same level of cooperation as in thedeadlock state. Actively attempting to assist their partner by communicating positionalinformation and how they were positioning the ball to enable the most ideal shot to destroytheir last remaining blocks.

As can be seen, there is some qualitative data to support this idea of personal goals changingto achieve a personal objective. There is a clear difference between those who played thegame cooperatively and those that played in competitively. In order to make conclusiveclaims, a further study would have to be undertaken.

8.2.5 Relationships and Communication

While it was a requirement that every person who volunteered for the experimental studyknew their partner, the type of relationship the people who participat ed were in wasnot recorded. During observation of the experiment, it became apparent that the type ofrelationship the participants were in affected the way participants perceived the actions ofeach player.

There were three different types of relationship observed during the study: Acquaintance,Friendship and Intimate relationships.

A simple action, such as letting a ball out of play, was interpreted in two different waysdepending on the relationship. Participants that were in an intimate relationship perceivedthe action as the mistake of a novice user, as they expected their partner to not be capableof playing the game. Participants who are friends perceived the action as either being funnyor malicious, depending on the existing expectations of each participant.

Acquaintances did not show any emotion about how the action was perceived, which could


suggest that they had yet to expect anything about each other due to the players notknowing each other well.

Hyperpersonal communication is the process of taking a minimal amount of textual infor-mation and maximising the amount of information obtained from it (Walther, 1996). Itmay be possible to apply this to these findings, as the minimal amount of information pro-vided by a simple action caused participants to perceive it differently based on the existingknowledge and expectations they had of their partner.

These differing expectations that participants had could have affected the way that par-ticipants communicated with each other and co-ordinated actions. Acquaintances spentvery little time communicating and co-ordinating activities, as the participants appearedto have very little existing knowledge of each other beyond first names.

Comparatively, participants who were friends had more of an idea of what to expect fromeach other. As such, they spent more time communicating and coordinating actions. Asdiscussed previously, it appeared that participants had an expectation of adversarial orcooperative collaboration prior to commencing the game based on the type of friendshipthey had with their partner.

Participants who were in an intimate relationship, specifically Pair 02, pair 05 and pair06, were observed to spend a substantial amount of time arguing. The participants inthese pairing were male/female, and all had unbalanced prior experience with computergames with the male participants consistently having more experience than their femalepartners. As such, it appeared they had an expectation of failure or inability from theirfemale partners, and thus adopted a more confrontational style of coordinating actions.

They would be explicit in their demands, insisting that their partner positioned theirplayer object where they’d instructed, and became frustrated when their female partnermade mistakes.

It cannot be stated conclusively that what was observed was due to the type of relation-ship the participants were in, as this was not included in the original project aims butsurfaced when analysing the results and as such there is not enough data. To accomplishthis, a further study would have to be undertaken which specifically looks at participantrelationships.

8.3 Critical Analysis

By the time the analysis of the results was completed, aspects of the project that hadsucceed and those that had failed could clearly be seen. This section discusses these in


further detail, providing insight into the improvements and learning points that have beenobserved.

8.3.1 Task Design and Implementation

The study showed that while the task had succeeded in certain areas, it had failed in someof the most critical. The task succeeded in providing a fun and engaging experience thatwas also clearly affected by the provision of force feedback in both the quantitative andqualitative data it provided, some of the data could have been biased and faulty becauseof the fringe case mentioned in the results in chapter 7, where participants were sometimesable to destroy large amounts of blocks with a “lucky” shot.

Additionally, the division between intuitive and deliberative thinking wasn’t as clear asit could have been. While there was a clear division between most participants, the vastmajority noted that the speed of the ball could have been faster. This suggests that theintuitive task could have engaged deliberative reasoning, but there would be no way toconfirm this without performing a further study.

These points may have occurred due to the task being designed primarily to be a fun andenjoyable game, with the potential for research findings taking a secondary role while furtherliterature was surveyed to gain a better understanding of the related fields. Positively, theprocess of designing the game and its mechanics ensured that each decision made wasjustified in regards to project aims. This meant that even though the task itself could havebeen inherently flawed, it was still able to provide meaningful data.

The logging of data to an external log file, while functional, was extremely primitive. Thisdrawback was noticed within the pilot study and discussed in chapter 6, but was deemedto not be critically important to rectify. While it was possible to analyse the results itprovided, it required an extensive amount of preparation work in order to make it possible.This was because it logged everything as being the same, regardless of whether it was atrial run or not. This meant starting with the first entry, every third record had to bediscarded as trial data.

This leads on to a related point of the primitive way that game configuration was performed.As mentioned in the implementation section in chapter 5, the way that the speed of theball and the status of the haptic effects were controlled was accomplished by building fourdifferent versions of the game; one for each permutation. Due to the constant need to rebuildas a consequence of adopting an agile development model, this became an inconvenience.

More thorough testing could have been performed during the implementation. Apart fromplay testing the game after every major code revision, there was no other testing performed.Had the testing been to a higher standard, some of the issues encountered in the pilot


study, such as the collision detection model being flawed and calculating the origin of theball incorrectly, could have been caught earlier if more functional and unit testing wasperformed.

However, none of these previously mentioned points could be considered critical failures.while inconvenient, the issues with logging and configuration were not detrimental to theoutcome of the project and the changes that had to be made due to the pilot study turnedout to be extremely minor and easy to fix. The logging, configuration and testing, whileminimal, is justified due to the experimental nature of the project and the.

8.3.2 Experimental Design

The design and execution of the pilot study was a clear positive in this study. It allowedcritical errors to be rectified as well as providing a way of ensuring that meaningful datacould be extracted from any experimental study that was performed.

The design and execution of the experiment successfully yielded useful information, but wasinherently flawed in a lot of ways in addition to the issues outlined in the implementationcritique. Firstly, the scope of the research aims were too broad, making it difficult to controlfor everything that could happen. Secondly, the comparison of intuitive and deliberativewas essentially two studies.

This meant that the amount of participants obtained for each type of thinking, six pairs,was possibly too few for the data extracted to be a representative sample. The amount ofparticipants was limited by the lack of interest in volunteering and the short time framein which it was completed. When querying people about volunteering, all replied witha response that stated that, due to the fact it was a game, they assumed it would beextremely popular and decided against volunteering.

Another limitation on the amount of participants could have been the fact that no incentivewas offered. If another study was performed, it would be necessary to provide eithera monetary or edible incentive in order to encourage people to volunteer. The limitedamount of participants led to an imbalance in the amount of male/female and female/femaleparticipants, which means the experiment was not counterbalanced for gender specifictraits.

While there were quite a few flaws, the study still provided strong evidence that, by combin-ing the quantitative and qualitative data, supported many of the experimental hypotheses.In particular, the qualitative evidence around the changing of a user’s personal goal wheninterference is provided showed that the personal goals of 22 out of the 24 total participantsreported that it had. Using this the other conclusive findings, and the solid foundation ofprevious literature that has been reviewed, the study could be re-run with all the learning


points put in place for more conclusive results.

The results obtained also provided a solid groundwork for numerous areas of further study,such as previous relationships, the affect of interference on personal goals on the achieve-ment of collaborative objectives and the affect gender/experience performance has on taskperformance benefits with the provision of haptic information.

It would have been preferable to do a supplementary study to look at a single area in moredepth, such as the separation of haptic information and other information, as the findingsfrom a more targeted study would have had more scientific merit due to the reducedamount of controls required. Due to time constraints, the execution of the supplementarystudy did not go ahead, but it was originally planned to be a study in which a gamethat provides haptic feedback is compared to a game that provides auditory, allowingthe separation of haptic information from additional information as mentioned previouslywithin the conclusion.

8.4 Further Study

During the project, several different avenues of further study presented themselves in addi-tion to those already mentioned in this conclusion. As different findings were made, severalquestions about the fields of collaboration and haptics, both combined and independently,were raised.

The areas outlined below could be investigated further to yield potentially interesting andvaluable findings.

8.4.1 Benefits of Additional Information

This study only looks at whether there is a benefit to providing additional informationthrough the haptic channel. This study was unconcerned with the extent of the benefit fora specific sub-population, but this provides an interesting idea for further study.

There are three different areas where further research on the benefits of additional infor-mation could be performed: Gender specific, experience specific and learning style specific.

It is known that there are differences in cognitive ability for both sexes, primarily aroundverbal reasoning and spatial ability (Colom et al., 2004). This could be investigated to seeif there is a benefit, and the extent of any benefit, additional information has for each sex.

This could be performed in a collaborative or non-collaborative work environment. Female


and Male participants would perform the same task with and without the same additionalinformation and the results compared to see if one group yields a bigger difference inperformance.

Another possible, but similar idea, would be to perform the same task but for experiencedand in-experienced users. The setup and execution of the investigation would be the same asthe gender investigation, only comparing experienced with in-experienced. The differencesin cognitive ability for each sex would have to be controlled for.

Previously, within the task performance for visual spatial tasks discussion, two differentstyles of learning was defined. Additional study could be performed involving the benefitsof additional information in the performance of verbal reasoning tasks for visual spatialand auditory sequential learners.

As mentioned previously, there is a difference between these two types of learners. It wouldbe interesting to find if there is a performance increase for visual spatial learners in verbalreasoning tasks when additional information is provided through a different modality.

8.4.2 Distributed Tightly-Coupled Collaboration

The tightly-coupled collaborative game in this study was played when both participantswere present in the same room. Due to the increasing speeds of internet and the increas-ing availability of communication devices such as microphones and web cameras, tightly-coupled collaboration is becoming increasingly more feasible in the work place and in com-puter games.

This can be observed most obviously within computer games. Most cooperative games canbe played the same way offline with local players as online with remote players. The gameLeft 4 Dead (Valve, 2008) is a popular example of this (Microsoft, 2008).

An investigation could be performed that finds the performance of a locally completedtightly-coupled task and compares it with the performance of the same task that is com-pleted by users who are distributed. This investigation would see if there is a difference intask performance because of the physical presence in the room, rather than the virtual onein a distributed task.

Bibliography

Ritu Agarwal and Elena Karahanna. Time flies when you’re having fun : Cognitiveabsorption and beliefs about information technology usage, dec 2000. URL http:

//www.business.auburn.edu/~corleij/PLS_PAQ/MISQ_24_04_665_Agarwal.pdf.

Sheldon Andrews, Javier Mora, Jochen Lang, and Won-Sook Lee. Hapticast: A physically-based 3d game with haptic feedback, 2006.

Barry Atkins. More than a game. The computer game as fictional form. ManchesterUniversity Press, may 2003. ISBN 0-7190-6365.

A. Baheti, S. Seshadri, A. Kumar, G. Srimathveeravalli, T. Kesavadas, and K. Guru.Virtual reality robotic surgical simulator for the da vinci surgical system. Proceedingsof the 2008 Symposium on Haptic Interfaces for Virtual Environment and TeleoperatorSystems, mar 2008.

Brian T. Bethea, Allison M. Okamura, Masaya Kitagawa, Torin P. Fitton, Stephen M.Cattaneo, Vincent L. Gott, William A. Baumgartner, and David D. Yuh. Application ofhaptic feedback to robotic surgery, jul 2004.

Stephen Brewster, Faraz Chohan, and Lorna Brown. Tactile feedback for mobile interac-tions. CHI Proceedings - Mobile Interaction, pages 159–162, 2007.

Timon Burney and Phillip Lock. Measuring game-play performance and perceived immer-sion in a domed planetarium projection environment. Entertainment Computing - ICEC2007, pages 22–27, 2007.

Angela Chang and Conor OSullivan. Audio-haptic feedback in mobile phones. CHI ’05extended abstracts on Human factors in computing systems, pages 1264–1267, 2005.

Andrew L. Cohen, Debra Cash, and Michael J. Muller. Designing to support adversarialcollaboration. Computer Supported Cooperative Work, pages 31–39, 2000.

Paul R. Cohen. Experimental methods for artificial intelligence, 1995. URL http://www.

cs.colostate.edu/~howe/EMAI/ch3/node11.html. Accessed on 25/04/2010.

90

http://www.business.auburn.edu/~corleij/PLS_PAQ/MISQ_24_04_665_Agarwal.pdf

http://www.business.auburn.edu/~corleij/PLS_PAQ/MISQ_24_04_665_Agarwal.pdf

http://www.cs.colostate.edu/~howe/EMAI/ch3/node11.html

http://www.cs.colostate.edu/~howe/EMAI/ch3/node11.html

BIBLIOGRAPHY 91

Roberto Colom, Ma Jose Contreras, Isabel Arend, Oscar Garcia Leal, and Jose Santacreu.Sex differences in verbal reasoning are mediated by sex differences in spatial ability. ThePsychological Record, 2004.

Immersion Corporation. Devices with that special touch, 2007. URL http://

gamingdeveloper.immersion.com/technology/devices/. Accessed on 04/05/2010.

Jack Tigh Dennerlein, David B. Martin, and Christopher Hasser. Force-feedback improvesperformance for steering and combined steering-targeting tasks, apr 2000. URL http:

//portal.acm.org/citation.cfm?id=332469.

Keith Ditchburn. Xinput - xbox 360 controller api, 2009. URL http://www.toymaker.

info/Games/html/xinput.html. Accessed on 04/05/2010.

Alan Dix, Janet Finlay, Gregory D. Abowd, and Russell Beale. Human Computer Interac-tion, 3rd Edition. Prentice Hall, sep 2003. ISBN 0-13-046109-1.

Marilyn Rose Mc Gee, Phil Gray, and Stephen Brewster. The effective combination ofhaptic and auditory textural information. may 2003.

Richard Brent Gillespie and Sile O’Mohdrain. The moose: A haptic user interface for blindpersons. 1995.

William Harris. How haptic technology works, jun 2008. URL http://electronics.

howstuffworks.com/gadgets/other-gadgets/haptic-technology.htm.

C. Ho, C. Basdogan, M. Slater, N. Durlach, and M. A. Srinivasan. An experiment onthe influence of haptic communication on the sense of being together. jan 1998. URLhttp://www.cs.ucl.ac.uk/staff/m.slater/BTWorkshop/TouchExp/index.html.

Jean-Michal Hoc. Towards a cognitive approach to humanmachine cooperation in dynamicsituations, apr 2001. URL http://www.ingentaconnect.com/content/ap/hc/2001/

00000054/00000004/art00454.

Immersion. Value of haptics, may 2007. URL http://www.immersion.com/docs/

Value-of-Haptics_May07v1-lr.pdf.

Caroline Jay, Mashhuda Glencross, and Roger Hubbold. Modeling the effects of delayedhaptic and visual feedback in a collaborative virtual environment, aug 2007. URL http:

//portal.acm.org/citation.cfm?id=1275511.1275514.

Bob Kowalski. Computational logic as a dual process model of thought, feb 2006. URLhttp://www.doc.ic.ac.uk/~rak/papers/dualprocess.pdf.

Ravi Kuber, Wai Yu, and Graham McAllister. Towards developing assistive haptic feedbackfor visually impaired internet users, 2007. URL http://portal.acm.org/citation.

cfm?id=1240854.

http://gamingdeveloper.immersion.com/technology/devices/

http://gamingdeveloper.immersion.com/technology/devices/

http://portal.acm.org/citation.cfm?id=332469


http://www.toymaker.info/Games/html/xinput.html

http://www.toymaker.info/Games/html/xinput.html

http://electronics.howstuffworks.com/gadgets/other-gadgets/haptic-technology.htm

http://electronics.howstuffworks.com/gadgets/other-gadgets/haptic-technology.htm

http://www.cs.ucl.ac.uk/staff/m.slater/BTWorkshop/TouchExp/index.html

http://www.ingentaconnect.com/content/ap/hc/2001/00000054/00000004/art00454

http://www.ingentaconnect.com/content/ap/hc/2001/00000054/00000004/art00454

http://www.immersion.com/docs/Value-of-Haptics_May07v1-lr.pdf

http://www.immersion.com/docs/Value-of-Haptics_May07v1-lr.pdf

http://portal.acm.org/citation.cfm?id=1275511.1275514


http://www.doc.ic.ac.uk/~rak/papers/dual process.pdf



BIBLIOGRAPHY 92

Wen-Jui Kuo, Tomas Sjostrom, Yu-Ping Chen, Yen-Hsiang Wang, and Chen-Ying Huang.Intuition and deliberation: Two systems for strategizing in the brain. Science, pages519–522, 2009.

Microsoft. Next generation of games starts with xna, 2004. URL https://www.

microsoft.com/presspass/press/2004/mar04/03-24xnalaunchpr.mspx. Accessed on27/04/2010.

Microsoft. Left 4 dead - game detail page, 2008. URL http://www.xbox.com/en-us/

games/l/left4dead/. Accessed on 27/04/2010.

Kaveh Nezamirad, Peter G. Higgins, and Simon Dunstall. Cognitive analysis of collab-oration as an activity, sep 2005. URL http://portal.acm.org/citation.cfm?id=

1124666.1124684.

Raymond S. Nickerson. Confirmation bias: A ubiquitous phenomenon in many guises.Review of General Psychology, pages 175–220, 2004.

Richard E. Nisbett and Timothy DeCamp Wilson. The halo effect: Evidence for un-conscious alteration of judgments. Journal of Feisonality and Social Psychology, pages240–256, 1977.

David Pinelle and Carl Gutwin. A groupware design framework for loosely coupled work-groups, sep 2005. URL http://portal.acm.org/citation.cfm?id=1242033.

Eva-Lotta Sallnas. Improved precision in mediated collaborative manipulation of objectsby haptic force feedback, jan 2001. URL http://www.springerlink.com/content/

qf25mjka3pttdh83/.

Eva-Lotta Sallnas, Kirsten Rassmus-Grohn, and Calle Sjostrom. Supporting presence incollaborative environments by haptic force feedback, dec 2000. URL http://portal.

acm.org/citation.cfm?id=365058.365086.

Linda Kreger Silverman. Identifying visual-spatial and auditory-sequential learners: Avalidation study. Talent development V: Proceedings from the 2000 Henry B. and JocelynWallace National Research Symposium on Talent Development., 2000.

Mandayam A Srinivasan. What is haptics?, sep 2006. URL http://www.sensable.com/

documents/documents/what_is_haptics.pdf.

Kraft Telerobotics. What is force feedback?, 2009. URL http://krafttelerobotics.

com/force_feedback.html.

William M.K. Trochim. Likert scaling, oct 2006. URL http://www.

socialresearchmethods.net/kb/scallik.php.

Jeff Tyson. How n64 works, oct 2000. URL http://electronics.howstuffworks.com/

n64.htm.

https://www.microsoft.com/presspass/press/2004/mar04/03-24xnalaunchpr.mspx

https://www.microsoft.com/presspass/press/2004/mar04/03-24xnalaunchpr.mspx

http://www.xbox.com/en-us/games/l/left4dead/

http://www.xbox.com/en-us/games/l/left4dead/




http://www.springerlink.com/content/qf25mjka3pttdh83/

http://www.springerlink.com/content/qf25mjka3pttdh83/



http://www.sensable.com/documents/documents/what_is_haptics.pdf

http://www.sensable.com/documents/documents/what_is_haptics.pdf

http://krafttelerobotics.com/force_feedback.html

http://krafttelerobotics.com/force_feedback.html

http://www.socialresearchmethods.net/kb/scallik.php

http://www.socialresearchmethods.net/kb/scallik.php

http://electronics.howstuffworks.com/n64.htm

http://electronics.howstuffworks.com/n64.htm

BIBLIOGRAPHY 93

International Telecommunication Union. Ict statistics, july 2008. URL http://www.itu.

int/ITU-D/ict/statistics/ict/index.html. Accessed on 04/05/2010.

Joseph B. Walther. Computer-mediated communication: Impersonal, interpersonal, andhyperpersonal interaction. Communication Research, pages 3–43, 1996.

Leon Watts. 13-point ethics check list. URL http://www.cs.bath.ac.uk/Leon/files/

EthicsChecklist.pdf. Accessed on 26/02/2010.

Neil A. Weiss. Elementary Statistics Fourth Edition. Addison-Wesley, nov 1998. ISBN978-0201598780.

Wikipedia contributors. Stick shaker, apr 2010. URL http://en.wikipedia.org/wiki/

Stick_shaker. Accessed on 04/05/2010.

Bob G. Witmer and Michael J. Singer. Measuring presence in virtual environments: Apresence questionnaire, jun 1998. URL http://mitpress.mit.edu/journals/PRES/

ps00734.pdf.

http://www.itu.int/ITU-D/ict/statistics/ict/index.html

http://www.itu.int/ITU-D/ict/statistics/ict/index.html

http://www.cs.bath.ac.uk/Leon/files/EthicsChecklist.pdf

http://www.cs.bath.ac.uk/Leon/files/EthicsChecklist.pdf

http://en.wikipedia.org/wiki/Stick_shaker

http://en.wikipedia.org/wiki/Stick_shaker

http://mitpress.mit.edu/journals/PRES/ps00734.pdf

http://mitpress.mit.edu/journals/PRES/ps00734.pdf

Appendix A

Experiment Screenshots

94

APPENDIX

A.EXPERIM

ENT

SCREENSHOTS

95

Figure A.1: The starting state of the game.

APPENDIX

A.EXPERIM

ENT

SCREENSHOTS

96

Figure A.2: The launched ball state.

APPENDIX

A.EXPERIM

ENT

SCREENSHOTS

97

Figure A.3: The block destruction state.

APPENDIX

A.EXPERIM

ENT

SCREENSHOTS

98

Figure A.4: The multiball state once a grey block has been destroyed.

APPENDIX

A.EXPERIM

ENT

SCREENSHOTS

99

Figure A.5: The blue ball lost state. Red ball lost has opposite effect.

Appendix B

Ethics Checklist

100

APPENDIX B. ETHICS CHECKLIST 101

UNIVERSITY OF BATH

Department of Computer Science

13-POINT ETHICS CHECK LIST

This document describes the 13 issues that need to be considered carefully before studentsor staff involve other people (participants) for the collection of information as part of theirproject or research.

1. Have you prepared a briefing script for volunteers?

Yes, the briefing script will be provided as part of the consent form and will beexplained verbally, giving participants the opportunity to ask any questions theymay have.

2. Will the participants be using any non-standard hardware?

No.

3. Is there any intentional deception of the participants?

No.

4. How will participants voluntarily give consent?

There will be a consent form outlying key information that the participant will signif they consent to taking part in the experiment.

5. Will the participants be exposed to any risks greater than those encoun-tered in their normal work life?

No.

6. Are you offering any incentive to the participants?

No.


7. Are any of your participants under the age of 16?

No.

8. Do any of your participants have an impairment that will limit their un-derstanding or communication?

No.

9. Are you in a position of authority or influence over any of your partici-pants?

No.

10. Will the participants be informed that they could withdraw at any time?

Yes, all participants will be informed within the consent form and verbally during thebriefing prior to the experiment commencing.

11. Will the participants be informed of your contact details?

Yes, my personal contact details will be provided within the consent form.

12. Will participants be de-briefed?

Yes, participants will be debriefed which involves a discussion of what data wasgathered and what it will be used for.

13. Will the data collected from the participants be stored in an anonymousform?

No. A participant may be asked to consent to being filmed for inclusion in the report.They would be free to decline with no consequence. All other data that is gatheredwill be stored in an anonymous form.


NAME: Richard Bowater

SUPERVISOR (IF APPLICABLE): Dr Leon Watts

SECOND READER (IF APPLICABLE): N/A

PROJECT TITLE: Analysing the Effect of Haptics on Task Performance and Immersionin a Tightly-Coupled Collaborative Game.

DATE: 26/02/2010

Appendix C

Consent Forms

104

APPENDIX C. CONSENT FORMS 105

C.1 Pilot Study Consent Forms

Consent Form

Study: Do force feedback effects make a better game?Name: Richard Bowater, Department of Computer Science. [email protected] Supervisor: Dr. Leon Watts.

You have been invited to participate in an experiment that looks at how collaboration andthe performance of a given task are affected by force feedback technology.

In this experiment you, together with a partner, will try to destroy a series of blocks throughuse of your joysticks to control paddles. The paddles will be used to bounce a ball betweenyou and your partner, the blocks being a wall between each of you. The ball destroys theblocks on contact.

After a short introduction to the game mechanics, you and your partner will then proceed toplay two games. Each game ends when all of the blocks on the screen have been destroyed.Force feedback effects will either be enabled or disabled for the duration of each game.

Following each game you will be asked to complete a short questionnaire about your ex-perience while playing the game. You will also be asked to complete a third questionnaireafter both games to compare the experiences. These should be completed independently,without input from your partner. Upon completion of these questionnaires there will be ashort debriefing session to explain what the results of the game and questionnaires will beused for.

I may ask for your permission to record you while you are playing the game. You are free todecline without reason and there will be no consequence for doing so. No other informationthat can personally identify you will be stored, as all other data is anonymised.

You are free to withdraw from the experiment at any time. It is not necessary toprovide a reason for withdrawal and there will be no consequences for doing so.

If you have any physical impairment, such as colour blindness or injury, that you feel mayimpact your ability to partake in this study, please notify me at the earliest convenience.

I have read and understood the information provided in this form. Any questions I haveasked have been answered satisfactorily. I agree to participate in this experiment.



Consent Form












Consent Form











Consent Form











C.2 Experimental Study Consent Forms

Consent Form












Consent Form











Consent Form











Consent Form











Consent Form












Consent Form











Consent Form











Consent Form











Consent Form











Consent Form












Consent Form












Consent Form











Consent Form











Consent Form











Consent Form











Consent Form












Consent Form












Consent Form












Consent Form











Consent Form











Consent Form











Consent Form











Consent Form











Consent Form










Appendix D

Raw Results Data

D.1 Pilot Study

142

APPENDIX D. RAW RESULTS DATA 143

D.1.1 Questionnaires

Pair 01 (Fast Ball) - Player 1

Haptics Enabled Game Questionnaire

1. On a scale of 1-5, please indicate your enjoyment of the game. (1 being’Awful’ and 5 being ’Excellent’)

4

2. On a scale of 1-5, how well were you able to work with your partner in thegame? (1 being ’Couldn’t work at all together’ and 5 being ’We workedreally well together’)

5

3. From the following list, please tick the statement that matches your per-sonal goal throughout the game

Lose as few balls as possible.

If other, please specify:

4. Did the addition of a second ball change your personal goal? If so, whatto?

No

5. On a scale of 1-5, did you always feel ’in control’ of the paddle? (1 being’Never in control’ and 5 being ’Always in control’)

4

6. On a scale of 1-5, how easy did you find it to position your paddle to aimeffectively? (1 being ’Very Hard’ and 5 being ’ Very Easy’)


3

7. On a scale of 1-5, how many avoidable mistakes do you feel you personallymade? (1 being ’A lot’ and 5 being ’None at all’)

4

8. Did the ball react in the way you expected each time? (Please circle theappropriate answer)

No

If you answered ”No” to the previous question, please provide more detailsbelow

Mostly yes, but occasionally no.

9. Did the speed of the ball affect your enjoyment? (Please circle the appro-priate answer)

Yes

If Yes, why was this?

Not too fast, not too slow.

10. Was there always enough time for you to plan your next move?

Yes

11. Any Additional Comments?

Auto centre good. Rumble also good but didn’t improve by as much.

Thank you for filling out this questionnaire


Haptics Disabled Game Questionnaire


4


5


Lose as few balls as possible.



No


4


3



4


No


Most of the time yes, but occasionally the ball bounced off the paddle ”weirdly”.


Yes


Fast enough to be challenging; not too fast to be difficult.


Yes




General Questionnaire

1. Are you male or female?

Male

2. On a scale of 1-5, please indicate how often you play computer games. (1being ’Once per month or less’ and 5 being ’Every day’)

1

3. Which game do you feel took longer?

Don’t know.

4. Did the force effects enhance your experience? (Please circle the appro-priate answer)

Yes

If Yes, how did they enhance the experience?

I felt the paddle had ”weight”.

5. On a scale of 1-5, please indicate your feelings about the strength of theforce effects (1 being ’Too Light’ and 5 being ’Too Strong’)

4


Auto centre force effects good, rumble was too strong.






5


5


Finish the game as quickly as possible. Lose as few balls as possible. Ensure theother player was involved.



Yes, to control both balls.


5


5



4


No


Clipping issues.


Yes


Fast is fun.


Yes






5


5





Yes, to keep both balls alive (very hard).


5


5



3


No


Very rare clipping issues.


Yes


A fast ball put pressure on, making it fun.


No (with two balls)






Male


5


About the same.


Yes


Gave clear indication of when the ball collided.


3




Pair 02 (Slow Ball) - Player 1



4


4


Finish the game as quickly as possible. Ensure the other player was involved.



Avoid giving the ball to the other player.


5


3



2


No


Still couldn’t judge the angle well.


Yes


Took ages to hit stuff at the end.


Yes


Last block takes ages.





3


4


Finish the game as quickly as possible. Ensure the other player was involved.



Avoid sending both balls to the other player.


5


2



1


No


Sometimes seemed to go off at odd angles.


Yes


Paddle was fast enough to recover mistakes.


Yes


I hate getting the last few blocks in breakout.





Male


4


Non-Feedback


Yes


Centering makes it easier to control the paddle precisely. I think that the rumble onhit helped me concentrate towards the end.


3







4


5





Losing as few balls as possible got harder (impossible sometimes). Both players wereinvolved more (1 ball for each player).


4


3



5


No


Sometimes unpredictable reflection angles.


No



Yes






4


4





Losing as few balls as possible got harder (impossible sometimes). Both players wereinvolved more (1 ball for each player).


3 (overall yes, but finegrained control hard).


1



4


No


Angle of reflection was sometimes a little ”unpredictable”.


No



Yes






Male


2


The first one. (Non-Haptics)


Both


Yes: Paddle not moving on its own/joystick centered automatically was useful forcontrolling the paddle. No: Force effects themselves (e.g. when ball hits paddle) didnot enhance my experience, found them a bit irritating actually.


4



APPENDIX

D.RAW

RESULTSDATA

163D.1.2 Raw Statistics

Fast Ball Results

Run P1 Score P2 Score Total Score Time Taken Balls Lost Game Speed Haptics

Trial 20100 23800 43900 08:52 24 Fast Enabled01 23800 17600 46342 06:37 16 Fast Disabled02 25300 27500 58920 06:19 9 Fast Enabled

APPENDIX

D.RAW

RESULTSDATA

164Slow Ball Results


Trial 20400 22100 46602 06:51 15 Fast Enabled01 25100 29800 54900 08:07 5 Slow Disabled02 29800 27400 57200 08:46 7 Slow Enabled


D.2 Experimental Study

D.2.1 Experimental Permutations

Pair Haptics Enabled Haptics Disabled Ball Speed

01 2nd 1st Slow

02 1st 2nd Fast

03 2nd 1st Fast

04 1st 2nd Slow

05 2nd 1st Slow

06 1st 2nd Fast

07 1st 2nd Fast

08 1st 2nd Slow

09 2nd 1st Slow

10 2nd 1st Fast

11 2nd 1st Fast

12 1st 2nd Slow

Table D.1: The permutations of volunteers to control for order effects. Each permutationis evaluated three times.


D.2.2 Questionnaires




4


4


5


4


3


I felt more in control of the joystick, and the feedback made the game more engaging.I could focus less on the ball contacting the paddle usually and focus more on directingit.






3


3


3


2


2


The control felt very loose and took a while to adjust to from the feedback on trial.





Male

2. On a scale of 1-5, please indicate your previous experience with computergames. (1 being ‘I’ve rarely played games before’ and 5 being ‘I playgames regularly and often’)

5

3. Did you know your partner personally prior to commencing the experi-ment? (Please circle the appropriate answer)

Yes

4. Out of the two games, which game was it easier to work with your partnerin?

Force Feedback

5. Out of the two games, which game do you feel took longer?

No Feedback

6. Out of the two games, which game did you enjoy the most?

Force Feedback


Lose as few balls as possible



Yes, as it meant the other player could get points, so my new goal was to not hitmulti-ball blocks

9. Did the addition of a second ball change the way you played the game? Ifso, what to?

See previous

10. Did the force feedback effects change your personal goal? If so, what to?

No

11. On a scale of 1-5, how did the force feedback effects affect the game? (1being ’Made it much Harder’ and 5 being ’Made it much Easier’)

5


3


Yes


I tihnkj the greater challenge gave a greater sense of achievement if I did well







5


5


5


4


5


With vibration, although easier to get a sense of the progress of the gane, it mademe think I had to put less effort in positioning the paddle, making it easy to makemistakes when not concentrating





4


4


5


5


4


Brings back good memories of arcade games. Would have liked music, but appreciatthe nature of understanding user cognition. Harder to anticipate control when therewasn’t feedback.





Male


5 - I don’t play games as often as I used to.


Yes


Both were as easy


No Feedback


Force Feedback


Finish the game as quickly as possible



Yes, wanted to ensure that we kept both balls alive to ensure maximum chances ofsuccess


Same as 8


Concentrating on using the feedback to help me react accordingly to the paddlesposition


4


3


Yes


Made it easier to react to the paddle/other player with shorter concentration spans


Was pleased to contribute to an exciting final year project. Good luck Rich!






3


3


3


3


1






2


2


4


2


1






Female


1


Yes


Force Feedback


No Feedback


Force Feedback





Try and hit both, at least try and hit one to the other player


Paniced a little and I played worse


Didn’t change


5


4


No








3


2


5


4


3






3


2


5


3


2






Male


5


Yes


Force Feedback


No Feedback


Force Feedback





Yes, to avoid losing a ball


Yes, more defensively / let myself keep the ball going more easily


No


4


4


Yes


I liked it being fast







4


5


5


5


4


Much better - more engaging





3


4


3


2


2


Hard to aim at the small blocks





Male


5


Yes


Force Feedback


No Feedback


Force Feedback





Keep the balls in play


See no. 8


No


5


3


No



No






4


4


4


4


3.5


Rumble makes you feel moe engaged!





3


4


3


3


2


N/A





Male


5


Yes


Force Feedback


No Feedback


Force Feedback


Finish the game as quickly as possible Ensure the other player was involved (to anextent)



A bit.. It gave hope I could finish the game quicker


Added more chance..


No, but it made me feel more engaged which made me play better


4


3.5


Yes


Faster = More exciting and engaging. Slow would be boring.







3


4


5


4


4


Was working well together at the end to get the last few blocks





4


4


3


4


4


Once I got used to the ”lighter” joystick, I found it just as easy to control. The lackof ’hit’ vibrations didn’t really effect me





Male


5


Yes


Both were as easy


Force Feedback


No Feedback





Keep them both in play for as long as possible which makes the game more interest-ing/faster


Tried harder to keep one ball on each side. i.e. not hit the ball to the other player


No


3


4


Yes


Felt I would be more excited if it was faster. Bit slow.







3


3


5


2


2


The physics seemed a bit wonky





4


4


2


1


3


The lack of force feedback was far more noticable than expected. The game playedmuch better with it





Male


5


Yes


Both were as easy


Force Feedback


No Feedback


Ensure the other player was involved



Not losing any balls and trying to keep one ball on each side


Yes, it made it more frantic and I spent less time aiming


No


4


3


Yes


It felt a bit slow at first







4


4


4.5


4.5


2-3


Much easier that time - Less twitchy, felt faster but more controlled





3


3


2 - but not because of the game!


1


1


I’m not very good at thhe game so it’s not necessarily the game





Female


2-3


Yes


Force Feedback


No Feedback


Force Feedback







I tended to only focus on one ball at a time, so not really


Not really


5


3


Yes


I liked having time to think, but not too much time







4


4


5


5


5


Felt much faster





1


1


5


5


5


It was too slow - Way too much time to think





Male


5


Yes


Force Feedback


No Feedback


Force Feedback


Finish the game as quickly as possible Lose as few balls as possible Ensure the otherplayer was involved Win



Yes, to keep both alive


Made it more fun to try to keep 2 alive Playing with 2 balls is better than playingwith 1


No


5


3


Yes


Slow in non-FF version


Release an XBLA version!







4


3


4


2


3






3


4


2


2


4


With the force feedback on the joystick it was stiffer which felt easier to guide thepaddle. Without it there was little resistance which felt a little weird after the firstto goes with it on!





Male


5


Yes


Both were as easy


No Feedback


Force Feedback


Get higher score than Player 2



Keeping both balls on my side of the map to score more


I stopped tracking the main ball with my paddle and kept it sort of inbetween eachball so I could dive towards whichever was closest


No


4


3


No


I think having it more fast might have made it more difficult but less fun


Needs more lasers






5


3


4


2


2


I’m too competitive to work in a team when playing this game





4


4


4


3


3


This was easier to use as the paddle appeared to glide or float horizontally, therebyenabling a more rapid response. Lack of force feedback made me feel a bit detachedfrom the game, although it was easier to focus





Female


3


Yes


No Feedback


Force Feedback


No Feedback





Yes - I wanted to work better as a team with my patner to clear the bricks quickerand finish the game as the ball created a more challenging scenario, which was harderto sustain


See 8


No


2


4


Yes


Was paced just enough to create a challenge, particularly when there were two balls


I won






3


4


3


2


4






4


4


4


3


4






Male


5


Yes


No Feedback


Force Feedback


No Feedback





Yes, keep both balls for as long as possible


Yes, wanted to keep both balls for as long as possible


No


2


5


No








4


5


4


3


2


It would have been good if the force feedback was restricted to each joystick. e.g. Ifplayer 1 hits the ball only player 1 joystick vibrates





3


4


2


3


3






Male


3


Yes


Force Feedback


Force Feedback


Force Feedback





No


Tried to keep both balls on opposite sides


No


4


4


No



It seemed to be quicker with no feedback but harder to aim






5


3


4


4


4


No





5


3


3


4


4


No





Male


4


Yes


Both were the same


No Feedback


Force Feedback





Keep both balls


Less focus on hitting blocks, more on keeping both balls active


No


3


4


No








3


3


5


2


2






4


3


4


3


3






Male


5


Yes


No Feedback


Force Feedback


No Feedback





Made the game more interesting


No


No


3


3


No








5


3


3


3


1






3.8


4.3


4.8


3.1


2.7


Loose joystick





Male


4


Yes


Both were as easy


Force Feedback


Force Feedback


Beat Player 2



Panic


See 8


No


3.5


4


No








5


4


4


4


5


Weird having feedback when opponent hits ball with paddle





3


5


3


4


3


Need the combo limit to be higher





Male


2


Yes


Force Feedback


Force Feedback


Force Feedback


To win



Keep them both in play


Took more concentration but not really - more balls more opportunity to score


No


3


4


Yes


Could have been slightly faster







4


3


3


3


2


Without the haptic was more peaceful and relaxing, but I think I got more into itwith haptics.





3


3


3


3


2






Male


3.75


Yes


Both were the same


No Feedback


Force Feedback





Not really


I tended to lose both


Nope


4


4


No








5


4


4


4


4






3


4


3


3


2






Male


5


Yes


Force Feedback


No Feedback


Force Feedback


Finish the game as quickly as possible Lose as few balls as possible



Losing ‘primary ball’ was acceptable because that ball would always respawn


See 8


No


4


3


Yes


Speed was good







5


5


4


4


4






3


4


4


3


3






Male


5


Yes


Force Feedback


No Feedback


Force Feedback





Keep both balls in play to not break the combo


Played more defensively. Less focus on hitting blocks.


No


5


3


Yes


The speed made the game exciting







5


5


5


4


4






3


3


3


3


2






Male


4


Yes


Force Feedback


No Feedback


Force Feedback


Finish the game as quickly as possible Lose as few balls as possible



Keep both balls in play for as long as possible Ensure other player had a ball


Played more defensively


No


4


3


No








4


4


5


4


4






3


3.5


3.5


3


3






Male


5


Yes


Force Feedback


Non Feedback


Force Feedback





Keep the balls in play for as long as possible


Less precise aiming to keep both balls


No


4


3


No








4


5


5


4


4






2.5


3.5


4


3


3






Male


5


Yes


Force Feedback


Non Feedback


Force Feedback





Try to keep one ball on each side


Made the game more exciting. Less time to think before making a move


No


4


3


No




APPENDIX

D.RAW

RESULTSDATA

264D.2.3 Raw Statistics

Slow Ball Statistics


P01R01 24400 25800 50200 12:23 14 Slow DisabledP01R02 30100 30700 65376 06:43 7 Slow EnabledP04R01 28300 34500 62800 08:07 9 Slow EnabledP04R02 17600 23200 54482 04:19 6 Slow DisabledP05R01 22400 12500 34900 15:02 23 Slow DisabledP05R02 19900 19300 53529 04:08 5 Slow EnabledP08R01 31400 23900 60683 06:30 7 Slow EnabledP08R02 21000 27700 56376 05:54 7 Slow DisabledP09R01 29900 19100 54759 06:24 11 Slow DisabledP09R02 24400 27300 51700 09:37 6 Slow EnabledP12R01 23100 27400 50500 07:21 8 Slow EnabledP12R02 21600 23900 52326 06:48 7 Slow Disabled

Table D.2: The raw statistics for the slow ball volunteers

APPENDIX

D.RAW

RESULTSDATA

265Fast Ball Statistics


P02R01 14500 14900 47610 03:07 14 Fast EnabledP02R02 13000 16200 29200 09:23 37 Fast DisabledP03R01 17900 14700 47441 04:00 12 Fast DisabledP03R02 26100 21500 59178 04:52 11 Fast EnabledP06R01 20700 27200 66828 02:55 8 Fast EnabledP06R02 13200 19500 42299 05:23 18 Fast DisabledP07R01 24500 24800 58884 05:24 15 Fast EnabledP07R02 8700 19600 38900 05:07 16 Fast DisabledP10R01 11900 10200 28546 06:13 28 Fast DisabledP10R02 21400 29000 60397 05:17 15 Fast EnabledP11R01 11200 11500 22700 07:21 24 Fast DisabledP11R02 18900 21700 53558 05:14 13 Fast Enabled

Table D.3: The raw statistics for the fast ball volunteers


D.2.4 Analysed Statistics


Mean 07:04:20 08:28:20 01:24:00

Max 09:37:00 15:02:00 05:25:00

Min 04:08:00 04:19:00 00:11:00

Std. Dev. 01:49:46 04:13:36 03:51:28

Table D.4: Results of game time analysis for deliberative thinking task


Mean 04:28:10 06:14:30 01:46:20

Max 05:24:00 09:23:00 03:59:00

Min 02:55:00 04:00:00 01:05:00

Std. Dev. 01:08:28 01:54:14 02:10:31

Table D.5: Results of game time analysis for intuitive thinking task


Mean 7 11.33333333 4.33333333

Max 9 23 14

Min 5 6 1

Std. Dev. 1.414213562 6.470445631 6.562519841

Table D.6: Results of ball loss analysis for deliberative thinking task



Mean 12.66666667 22.5 9.8333333

Max 15 37 12

Min 8 12 4

Std. Dev. 2.732520204 9.11592014 8.256310718

Table D.7: Results of ball loss analysis for intuitive thinking task


Mean 26200 22816.66667 3383.33333

Max 31400 29900 1500

Min 19900 17600 2300

Std. Dev. 4454.21149 4119.425526 3854.218468

Table D.8: Results of Player 1 score analysis for deliberative thinking task


Mean 21016.66667 12650 8366.66667

Max 26100 17900 8200

Min 14500 8700 5800

Std. Dev. 4127.186289 3041.54566 4580.684083

Table D.9: Results of Player 1 score analysis for intuitive thinking task



Mean 27183.33333 22033.33333 5150

Max 34500 27700 6800

Min 19300 12500 6800

Std. Dev. 5270.452226 5488.776427 2994.27231

Table D.10: Results of Player 2 score analysis for deliberative thinking task


Mean 23183.33333 15283.33333 7900

Max 29000 19600 9400

Min 14900 10200 4700

Std. Dev. 5024.506609 3943.306565 5917.319213

Table D.11: Results of Player 2 score analysis for intuitive thinking task


D.2.5 Graphs

Figure D.1: Graphs that show the actual time to complete with minimum and maximumvalues. Left: Deliberative thinking results. Right: Intuitive thinking results.

Figure D.2: Graphs that show the average time to complete for each type of thinking. Left:With maximum and minimum values. Right: With standard deviation.


Figure D.3: Graphs that show the actual amount of balls lost with minimum and maximumvalues. Left: Deliberative thinking results. Right: Intuitive thinking results.

Figure D.4: Graphs that show the average amount of balls lost each game for each type ofthinking. Left: With maximum and minimum values. Right: With standard deviation.


Figure D.5: Graphs that show the average player score type of thinking with min maxvalues. Left: Deliberative thinking results. Right: Intuitive thinking results.

Figure D.6: Graphs that show the average player score type of thinking with standarddeviation. Left: Deliberative thinking results. Right: Intuitive thinking results.


D.2.6 Observational Notes

Pair 01

Both players found the lack of feedback to be ’weird’. They stated they were less sure whenor whether the ball had collided with the paddle.

Player 2 frequently overshot when attempting to reach the ball without feedback.

Both players started off playing competitively but as blocks decreased and the difficulty tohit them increased, communication and co-operation increased.

Both players began talking about other topics during play, which suggests that the ballmay be too slow and that players are given too much time to think between turns.

Game did become more demanding when there was a single block left. Conversation wasexclusively on the game.

Pair 02

There was very little communication between the pair. They only spoke prior to the ballbeing launched.

Player 2 commented that force feedback made the game a lot easier.

Player 1 commented that they did not like the game when force feedback was disabled.

Player 1 finds it more difficult to grasp the mechanics and frequently overshoots withoutfeedback. Movement is very digital.

Player 2 is more accurate than player 1 and the movements made were more deliberative.

More communication towards the last few blocks with both players becoming obviouslyfustrated.

Both players were arguing with each other while playing the game.


Pair 03

Player 1 grasped how the game worked immediately and proceeded to explain this to player2. Due to this they finished extremely quickly.

Both players enjoyed the haptic feedback more, verbally expressing how much better thegame felt with them enabled.

Pair 04

Player 1 communicated the position of the ball to player 2 often when there were two ballsin play as it seemed player 2 focused only on a single ball.

Player 1 commented that the ball didn’t go the way they wanted it to.

Very little collaboration observed with this pair. They would take it in turns. Both playerswere visibly competing with each other.

Lead to a situation where there were far more red blocks than any other block, making itdifficult for both players.

When force feedback was disabled, communication increased. Understanding of the gamemechanics were improved over the feedback enabled run.

Pair 05

Without haptics, conversation topics again were not related to the game until it got to thelast few blocks.

Both players commented that the feedback enabled version felt more natural than thenon-feedback version.

Player 02 was visibly bored during the non-feedback version and made comments to thateffect.

On commencing the feedback enabled version, player 02 commented that it felt faster andwas more fun for them personally.

Again, both players argued with each other as with pair 02.


Pair 06

Player 02 commented that they were not very good at team work.

At the start of each game, both players were competitive. When it reached the last fewblocks, both players worked together to set up good shots for each other.

Both players commented that the controls of the non-feedback version felt “loose”. Player02 found this a positive, commenting that it made them feel like they could move fastereven though they couldn’t.

Both players also argued with each other. As with the other pairs who argued, they werein an intimate relationship rather than just being friends.

Pair 07

Communication between both players is solely focused on the game.

Player 2 regularly informed player 1 of the balls position.

When haptics were disabled, one player managed to get the ball to rebound in such away that a substantial amount of blocks were destroyed. This made them feel like they’dperformed better in this game even though performance was poor for the remainder of thegame.

Pair 08

These players were more acquaintences than friends. Exposes a weakness in the studywhich is that I do not gather information regarding the level of previous knowledge, justthat knowing each other prior is a prerequisite. This may also be a factor in the previouspairs who are in stronger relationships.

Pair 09

Player 2 was extremely competitive, to the point where they would actively try to ham-per the progress of player 1 by threatening to drop the ball in order to reset the combomultiplyer on purpose. Player 2 would be disappointed when player 1 was given a secondball.


Collaboration increased substantially when it became difficult for both players to completethe task alone. They had to work together in order to to destroy the last few blocks dueto the position they were in.

Pair 10

Player 1 frequently dropped the ball and seemed somewhat unaware of its position. Player2 regularly informed player 1 of the ball position in order to make more progress in thegame. This held true for both games that they played.

Due to this, the amount of balls lost in the games they played were relatively high. Addi-tionally, the score was heavily sqewed in player 2s favour due to the frequency of player 1losing the ball (control of the ball passes to the other player upon loss)

Pair 11

No notes taken

Pair 12

There was little communication from both pairs until the final few blocks. Communicationfrom both players increased in order to identify a block each player was going for and thenposition accordingly.

Both players found the non-haptic enabled version more fustrating when trying to line upand aim for shots. Prior to a ball colliding, player 1 would jolt their joystick towards theball, presumably because they thought that the ball would not make contact.

Appendix E

Code Listings

E.1 Introduction

The code listings are structured in the following way:

• The source code for the program constructor

• The source code for the game components, given in the following order:

1. The Engine - Contains most of the sub systems

2. The Input Handler - Interfaces with the joystick controllers

3. The Data Logger - Writes given data to an output file

• The source code for all the game objects, given in the following order:

1. Ball - Stores state and positional information about a single ball

2. Block - Stores state and positional information about a single block

3. Player - Stores state and positional information about a single player

4. Score - Helper class that calculates and stores the current player score

276

APPENDIX E. CODE LISTINGS 277

E.2 Main Program

E.2.1 File: Program.cs

using System ;

namespace Breong{

stat ic class Program{

/// <summary>/// The main entry po in t f o r the app l i c a t i on ./// </summary>stat ic void Main( string [ ] a rgs ){

using ( Engine game = new Engine ( ) ){

game .Run( ) ;}

}}

}


E.3 Game Engine

E.3.1 File: Engine.cs

#reg ion F i l e Desc r ip t i on////// F i l e : Engine . cs////// The Engine c l a s s d r i v e s the en t i r e game . I t i n i t i a l i s e s the o ther/// c l a s s e s and draws the screen . I t updates the s t a t e o f each o b j e c t/// u n t i l the game has ended , where i t ga ther s the data from each/// o b j e c t and sends i t to the DataLogger t ha t records the data .///#endreg ion

using System ;using System . IO ;using System . Co l l e c t i o n s . Generic ;using System . Linq ;using System .Windows . Forms ;using Microso f t .Xna . Framework ;using Microso f t .Xna . Framework . Audio ;using Microso f t .Xna . Framework . Content ;using Microso f t .Xna . Framework . GamerServices ;using Microso f t .Xna . Framework . Graphics ;using Microso f t .Xna . Framework . Media ;using Microso f t .Xna . Framework . Net ;using Microso f t .Xna . Framework . Storage ;

namespace Breong{

/// <summary>/// The c l a s s type i s an XNA game . Al lows access to the game/// time v a r i a b l e t ha t updates every cy c l e ./// </summary>public class Engine : Mic roso f t .Xna . Framework .Game{

// Graphics Manager and Spr i t e Batch v a r i a b l e s .GraphicsDeviceManager g raph i c s ;Spr i teBatch spr i t eBatch ;

// Object Class v a r i a b l e s .public Player [ ] p ly r ;public Block [ , ] b lk s ;public Bal l [ ] b a l l ;public Score s c r e ;private InputHandler [ ] j s ;private DataLogger d l ;

// Stores how many b a l l s are a c t i v e .private int ba l l a c t ;// Stores how many b l o c k s have been des t royed .private int blkdes ;// Stores how many b l o c k s the re are in t o t a l .private int b l k t l e ;

// Store the accumulated p layer v a r i a b l e .private Vector2 [ ] accumove ;

// Whether or not the game i s a c t i v e ( ended ) .


private bool gmeact ;

// Var iab l e s to contain the s p r i t e s .Texture2D divbord ;Texture2D plyrchar ;Texture2D ba l l c ha r ;Texture2D blkchar ;Spr i teFont arcade ;

// UI Var iab l e s .Rectangle bordpos ;Vector2 textpos ;

// Player , b a l l and b l o c k number cons tant s .private const int plyrmax = 2 ;private const int blkrow = 7 ;private const int b l k c o l = 13 ;private const int ballmax = 2 ;

// Game va r i a b l e f l a g s ( Hapt ics and b a l l speed ) .private const bool hapt = fa l se ;private const f loat ba l l spd = 4 f ;

#reg i on Drawing Functions

/// <summary>/// This func t ion draws a p layer ./// </summary>/// <param name=”s t a t e”>The p layer to draw</param>private void DrawPlayer ( Player s t a t e ){

sp r i t eBatch .Draw( plyrchar , s t a t e . p lyrpos , null , s t a t e . p l y r c o l ) ;}

/// <summary>/// This func t ion draws a b a l l ./// </summary>/// <param name=”s t a t e”>The b a l l to draw</param>private void DrawBall ( Ba l l s t a t e ){

sp r i t eBatch .Draw( ba l l char , s t a t e . ba l lpos , null , s t a t e . b a l l c o l ) ;}

/// <summary>/// This func t ion draws the User In t e r f a c e ./// </summary>private void DrawUI ( ){

// Bui ld the t e x t to go in the UI .String u i t e x t = ”Score ” ;u i t e x t += ”\n\ r ” + s c r e . s c r e ;u i t e x t += ”\n\ r ” + ”−−−−−−−−” ;u i t e x t += ”\n\ r ” + ”P. 1 Score ” ;u i t e x t += ”\n\ r ” + s c r e . p l y r 1 s c r ;u i t e x t += ”\n\ r ” + ”−−−−−−−−” ;u i t e x t += ”\n\ r ” + ”P. 2 Score ” ;u i t e x t += ”\n\ r ” + s c r e . p l y r 2 s c r ;u i t e x t += ”\n\ r ” + ”−−−−−−−−” ;u i t e x t += ”\n\ r ” + ”Combo” ;u i t e x t += ”\n\ r ” + s c r e . screcom ;u i t e x t += ”\n\ r ” + ”−−−−−−−−” ;u i t e x t += ”\n\ r ” + ” Ba l l s Lost ” ;


u i t e x t += ”\n\ r ” + s c r e . l i v e s ;

sp r i t eBatch .Draw( divbord , bordpos , null , Color . White ) ;sp r i t eBatch . DrawString ( arcade , u i t ext , textpos , Color . White ) ;

}

/// <summary>/// This func t ion draws a s i n g l e b l o c k in an array o f b l o c k s ./// </summary>/// <param name=”i”>One co−ord ina te o f a 2D array</param>/// <param name=”j”>One co−ord ina te o f a 2D array</param>private void DrawBlocks ( int i , int j ){

i f ( ! b lk s [ i , j ] . b lkdes ){

sp r i t eBatch .Draw( blkchar , b lk s [ i , j ] . blkpos , null ,b lk s [ i , j ] . b l k c o l ) ;

}}#endreg ion

#reg i on Movement Functions

/// <summary>/// This func t ion moves the p layer by an amount g iven by data/// from the j o y s t i c k movement . Add i t i ona l l y , i f the b a l l isn ’ t/// ac t i ve , the b a l l i s moved with the p layer who i s cu r r en t l y/// in con t ro l o f launching i t ./// </summary>/// <param name=”plyrno”>The p layer to move</param>private void MovePlayer ( int plyrno ){

// I f the f i r e but ton has been pressed and the p layer who// has the b a l l has pressed i t .i f ( j s [ p lyrno ] . F i reButtonState ( ) &&

ba l l [ 0 ] . p r ep ly r == plyrno ){// Act i va te the b a l l and s e t the a c t i v e b a l l v a r i a b l e .ba l l [ 0 ] . b a l l a c t = true ;b a l l a c t = 1 ;// S ta r t the t imer count i f i t hasn ’ t s t a r t e d a l ready .i f ( ! s c r e . t imact ){

s c r e . t imact = true ;}}

// Accumulate the p layer movement .accumove [ p lyrno ] .X += ( j s [ p lyrno ] . GetAxisState ( ) / 5000) ∗

p ly r [ p lyrno ] . p lyrspd ;

// I f the accumulated movement vec to r i s l onger than a g iven// va lue .i f ( accumove [ p lyrno ] . Length ( ) > . 5 ){

// Check whether i t ’ s p o s s i b l e to move .Vector2 mv = plyr [ p lyrno ] . CheckMove ( accumove [ p lyrno ] ) ;

// Move the p layer by the g iven amount .p ly r [ p lyrno ] . p ly rpos = p lyr [ p lyrno ] . p ly rpos + mv;


// Create a new bounding r e c t ang l e .p ly r [ p lyrno ] . p l y r s i z = new Rectangle (

( int ) p ly r [ p lyrno ] . p lyrpos .X, ( int ) p ly r [ p lyrno ] . p ly rpos .Y,p ly r [ p lyrno ] . plyrwid , 10) ;

// I f the b a l l isn ’ t ac t i ve , move the b a l l .i f ( ! b a l l [ 0 ] . b a l l a c t && ba l l [ 0 ] . p r ep ly r == plyrno ){

ba l l [ 0 ] . b a l l p o s = ba l l [ 0 ] . b a l l p o s + mv;}

// Zero out the accumulated movement .accumove [ p lyrno ] = Vector2 . Zero ;

}}

/// <summary>/// This func t ion moves the b a l l based on the v e l o c i t y/// and the speed o f the b a l l ./// </summary>/// <param name=”s t a t e”>The b a l l to move</param>private void MoveBall ( Ba l l s t a t e ){

// Move the b a l l p o s i t i on by the v e l o c i t y .s t a t e . ba l l p o s += s t a t e . b a l l v e l ;// Recreate the r e c t ang l e f o r the b a l l .s t a t e . b a l l s i z = new Rectangle ( ( int ) s t a t e . ba l l p o s .X,

( int ) s t a t e . ba l l p o s .Y, 10 , 10) ;

// I f the b a l l has f a l l e n out o f p lay .i f ( ! s t a t e . CheckBounds ( ) ){

// Deact iva te b a l l .s t a t e . b a l l a c t = fa l se ;

// I f Ba l l 0 has been l o s t .i f ( s t a t e == ba l l [ 0 ] ){

// I f b a l l 1 i s s t i l l in p lay .i f ( b a l l [ 1 ] . b a l l a c t == true ){

// Reset to the l o c a t i on o f the o ther p layer .i f ( b a l l [ 1 ] . p r ep ly r == 0){

s t a t e . p r ep ly r = 0 ;s t a t e . ResetBa l l ( p ly r [ 1 ] . p ly rpos ) ;

}else{

s t a t e . p r ep ly r = 1 ;s t a t e . ResetBa l l ( p ly r [ 0 ] . p ly rpos ) ;

}}else{

i f ( s t a t e . p r ep ly r == 0){

s t a t e . ResetBa l l ( p ly r [ 1 ] . p ly rpos ) ;}else{

s t a t e . ResetBa l l ( p ly r [ 0 ] . p ly rpos ) ;


}}

}// I f b a l l 1 has been l o s t , r e s e t the b a l l o f f screen .else{

ba l l [ 1 ] . b a l l p o s .Y = plyr [ 0 ] . p lyrpos .Y + 40 ;}

// Set b a l l ac t to 0 .ba l l a c t = 0 ;// Reset the combo .s c r e . screcom = 1 ;// Add to the amount o f b a l l s t ha t have been l o s t .s c r e . l i v e s++;

}else{

// I f the b a l l has s t ruck a wa l l .i f ( s t a t e . wa l l c o l == true ){

// Play an e f f e c t f o r each p layer .i f ( hapt ){

j s [ 0 ] . P layEf f e c t (0 ) ;j s [ 1 ] . P layEf f e c t (0 ) ;

}

// Reset the wa l l c o l l i s i o n v a r i a b l e .s t a t e . wa l l c o l = fa l se ;

}// Check whether the b a l l has c o l l i d e d with a b l o c k .CheckCo l l i s i on ( s t a t e ) ;

}}

/// <summary>/// This func t ion checks whether a b a l l has c o l l i d e d with/// a p layer or a b l o c k and hand les i t accord ing l y . I t/// rebounds the b a l l , p l ay s hap t i c e f f e c t s and adds score ./// </summary>/// <param name=”s t a t e”>The b a l l t ha t needs to be checked</param>public void CheckCo l l i s i on ( Ba l l s t a t e ){

// Deduct one from b a l l d i r e c t i on change immunity to// make i t p o s s i b l e to change the d i r e c t i on o f the b a l l .i f ( s t a t e . ballimm > 0){

s t a t e . ballimm−−;}

// Ba l l c o l l i d e s with p layer 1 .i f ( s t a t e . b a l l s i z . I n t e r s e c t s ( p ly r [ 0 ] . p l y r s i z ) ){

i f ( s t a t e . b a l l v e l .Y > 0){

// I f hap t i c s are enabled , p lay hap t i c e f f e c t .i f ( hapt ){

// Play a d i f f e r e n t e f f e c t f o r each p layer .j s [ 0 ] . P layEf f e c t (1 ) ;j s [ 1 ] . P layEf f e c t (0 ) ;


}

// Handle the p layer c o l l i s i o n fo r p layer 1 .s t a t e . P l y rCo l l i s i o n ( p ly r [ 0 ] . p ly rpos .X) ;// Change the b a l l co lour .s t a t e . b a l l c o l = p ly r [ 0 ] . p l y r c o l ;

// Increase the combo and s t o r e the p layer who h i t i t .i f ( s t a t e . p r ep ly r == 1){

i f ( s c r e . screcom < 10){

s c r e . screcom++;}s t a t e . p r ep ly r = 0 ;

}}

}// Ba l l c o l l i d e s with p layer 2 .i f ( s t a t e . b a l l s i z . I n t e r s e c t s ( p ly r [ 1 ] . p l y r s i z ) ){

i f ( s t a t e . b a l l v e l .Y < 0){

i f ( hapt ){

j s [ 1 ] . P layEf f e c t (2 ) ;j s [ 0 ] . P layEf f e c t (0 ) ;

}

s t a t e . P l y rCo l l i s i o n ( p ly r [ 1 ] . p ly rpos .X) ;s t a t e . b a l l c o l = p ly r [ 1 ] . p l y r c o l ;

i f ( s t a t e . p r ep ly r == 0){

i f ( s c r e . screcom < 10){

s c r e . screcom++;}s t a t e . p r ep ly r = 1 ;

}}

}

// Ba l l c o l l i d e s with a b l o c k . Loop fo r every b l o c k to check// each b l o c k f o r c o l l i s i o n .for ( int i = 0 ; i < b l k c o l ; i++){

for ( int j = 0 ; j < blkrow ; j++){

// I f the b a l l has h i t the b l o c k and the b a l l i s a b l e// to h i t a b l o c k .i f ( s t a t e . b a l l s i z . I n t e r s e c t s ( b lk s [ i , j ] . b l k s i z ) ){

// I f hap t i c s are enabled , p lay hap t i c e f f e c t .i f ( hapt ){

// Play the b a l l c o l l i s i o n e f f e c t .j s [ 0 ] . P layEf f e c t (0 ) ;j s [ 1 ] . P layEf f e c t (0 ) ;

}

// Depending on the b l o c k type , ac t in a d i f f e r e n t


// way .switch ( b lk s [ i , j ] . b lktyp ){

// Type 1 b l o c k s can only be des t royed by// p layer 1 .case 1 :

// I f i t ’ s not p l ayer 1 , rebound the b a l li f ( s t a t e . p r ep ly r != 0){

s t a t e . B l o ckCo l l i s i on ( b lk s [ i , j ] . b l k s i z ) ;}// Destroy the b a l l and add po in t selse{

s t a t e . B l o ckCo l l i s i on ( b lk s [ i , j ] . b l k s i z ) ;b lk s [ i , j ] . Destroy ( ) ;s c r e . s c r e += sc r e . CalcScore (

b lk s [ i , j ] . b l kva l ) ;s c r e . p l y r 1 s c r += sc r e . CalcScore (

b lk s [ i , j ] . b l kva l ) ;b lkdes++;

}break ;

// Type 2 b l o c k s can only be des t royed by// p layer 1 .case 2 :

i f ( s t a t e . p r ep ly r != 1){

s t a t e . B l o ckCo l l i s i on ( b lk s [ i , j ] . b l k s i z ) ;}else{


b lk s [ i , j ] . b l kva l ) ;s c r e . p l y r 2 s c r += sc r e . CalcScore (

b lk s [ i , j ] . b l kva l ) ;b lkdes++;

}break ;

// Type 3 b l o c k s c rea t e a second b a l l i f t he re i s// only one in p lay .case 3 :

i f ( b a l l a c t < ballmax ){

// Destroy the b l o c k and add the score .s t a t e . B l o ckCo l l i s i on ( b lk s [ i , j ] . b l k s i z ) ;b lk s [ i , j ] . Destroy ( ) ;s c r e . s c r e += sc r e . CalcScore (

b lk s [ i , j ] . b l kva l ) ;

// Update i n d i v i d u a l score based on// who h i t the b l o c k .i f ( s t a t e . p r ep ly r == 0){

s c r e . p l y r 1 s c r += sc r e . CalcScore (b lk s [ i , j ] . b l kva l ) ;

}else


{s c r e . p l y r 2 s c r += sc r e . CalcScore (

b lk s [ i , j ] . b l kva l ) ;}

// I f the second b a l l i s not in play ,// po s i t i on i t and make i t a c t i v e .i f ( ! b a l l [ 1 ] . b a l l a c t ){

// Reset based on the prev ious p layer// who h i t the b a l l .i f ( s t a t e . p r ep ly r == 0){

ba l l [ 1 ] . p r ep ly r = 0 ;b a l l [ 1 ] . ResetBa l l (

p ly r [ 1 ] . p ly rpos ) ;}else{

ba l l [ 1 ] . p r ep ly r = 1 ;b a l l [ 1 ] . ResetBa l l (

p ly r [ 0 ] . p ly rpos ) ;}ba l l [ 1 ] . b a l l a c t = true ;

}

ba l l a c t++;b lkdes++;

}// Destroy the b l o c k s and add the points , but// don ’ t c rea t e a second b a l l .else{


b lk s [ i , j ] . b l kva l ) ;

i f ( s t a t e . p r ep ly r == 0){


}else{


}

blkdes++;}break ;

// Defau l t b l o c k g e t s des t royed by e i t h e r p l ayer .default :


b lk s [ i , j ] . b l kva l ) ;

i f ( s t a t e . p r ep ly r == 0){

s c r e . p l y r 1 s c r += sc r e . CalcScore (


b lks [ i , j ] . b l kva l ) ;}else{


}

blkdes++;break ;

}}

}}

}

#endreg ion

#reg i on I n i t i a l i s e Funct ions ( Players , Ba l l s , Blocks , Input , UI )

/// <summary>/// This func t i on i n i t i a l i s e s each p layer and the input handler/// fo r each ./// </summary>private void I n i tP l ay e r ( ){

// I n i t i a l i s e the array o f p l a ye r s .p ly r = new Player [ plyrmax ] ;

// I n i t i a l i s e the input .j s = new InputHandler [ plyrmax ] ;

// Create p l ay e r s and c a l l the i n i t i a l i s e func t i on fo r each .for ( int i = 0 ; i < plyrmax ; i++){

p ly r [ i ] = new Player ( GraphicsDevice . Viewport , i ) ;// Create a new input handler .j s [ i ] = new InputHandler ( this , i , hapt ) ;

}}

/// <summary>/// This func t ion i n i t i a l i s e s each b a l l ./// </summary>private void I n i tB a l l ( ){

// Get the po s i t i on o f the f i r s t p l ayerVector2 ppos = p lyr [ 0 ] . p ly rpos ;b a l l = new Bal l [ ballmax ] ;

// I n i t i a l i s e the b a l l wi th the f i r s t p l a y e r s po s i t i on .for ( int i = 0 ; i < ballmax ; i++){

ba l l [ i ] = new Bal l ( ppos , GraphicsDevice . Viewport , ba l l spd ) ;// Of f s e t the b a l l p o s i t i on by 20 to push i t o f f screen .ppos .Y = −20;

}}

/// <summary>/// This func t ion i n i t i a l i s e s an array o f b l o c k s t ha t need to be/// des t royed . Each b l o c k i s i n i t i a l i s e d with a type , which changes


/// the way b a l l s c o l l i d e with i t ./// </summary>private void In i tB lo ck ( ){

// I n i t i a l i s e the array o f b l o c k s .b lks = new Block [ b lkco l , blkrow ] ;

// Ca l cu la t e the width and he i gh t o f the b l o c k s// based on the amount and t h e i r s i z e .int b lkcnthe i ght = ( blkrow ∗ 15) + blkrow − 1 ;int blkcntwidth = ( b l k c o l ∗ 30) + b l k c o l − 1 ;

// Use t h i s width and he i gh t to centre the g r i d o f b l o c k s .Rectangle b lkcntnr = new Rectangle (

( GraphicsDevice . Viewport .Width − 100) / 2 ,( GraphicsDevice . Viewport . Height / 2) ,b lkcnthe ight , b lkcntwidth ) ;

// Create a vec to r to s t o r e the po s i t i on o f the f i r s t b l o c k .Vector2 blkpos = new Vector2 (

b lkcntnr .X − ( blkcntwidth / 2) ,b lkcntnr .Y − ( b lkcn the i ght / 2) ) ;

// Store the l a s t p l ayer e x c l u s i v e b l o c k type ( p layer 1// des t roy or p layer 2 des t roy ) so t ha t they appear in// d i f f e r e n t p l a ce s .int l s t t y p = 1 ;

for ( int i = 0 ; i < b l k c o l ; i++){


// Create a new b l o ck .b lks [ i , j ] = new Block ( ) ;

i f ( ( i + 1) % 2 == 0){

i f ( ( j + 1) % 2 == 0){

// I f i and j d i v i d e by 2 , c rea t e a p layer// e z x c l u s i v e b l o c k .i f ( l s t t y p == 1){

b lks [ i , j ] . I n i t i a l i z e ( blkpos , l s t t y p ) ;l s t t y p = 2 ;

}else i f ( l s t t y p == 2){

b lks [ i , j ] . I n i t i a l i z e ( blkpos , l s t t y p ) ;l s t t y p = 1 ;

}}// I n i t i a l i s e to d e f a u l t type .else{

b lks [ i , j ] . I n i t i a l i z e ( blkpos , 0) ;}

}else i f ( ( i + 3) % 3 == 0){

// I f i and j d i v i d e by 3 , c rea t e a multi−b a l l b l o c k .i f ( ( j + 3) % 3 == 0)


{b lks [ i , j ] . I n i t i a l i z e ( blkpos , 3) ;

}else{


}else{


// Of f s e t the Y po s i t i on to crea t e the next b l o c k// underneath .blkpos .Y += 16 ;

}// Reset the Y po s i t i on and s t a r t a new column .blkpos .Y −= ( blkrow ∗ 16) ;b lkpos .X += 31 ;

}

// Ca l cu la t e the t o t a l amount o f b l o c k s .b l k t l e = b l k c o l ∗ blkrow ;

}

/// <summary>/// This func t ion i n i t i a l i s e s the UI . I t c a l c u l a t e s the po s i t i on/// o f the UI and i t s e lements ./// </summary>private void In i tUI ( ){

Viewport view = GraphicsDevice . Viewport ;Rectangle UIBound = new Rectangle ( view .Width − 100 , view .Y,

100 , view . Height ) ;

// Ca l cu la t e the d i v i d i n g border and t e x t p o s i t i on .bordpos = new Rectangle ( view .Width − 100 , view .Y,

10 , view . Height ) ;t extpos = new Vector2 (UIBound . Le f t + 20 , UIBound .Top + 20) ;

}

#endreg ion

/// <summary>/// This func t ion s tops the game from running . I t prevent s/// the b a l l from moving and s tops the game timer from running ./// Then i t puts the data in to an array and puts i t in to a s i n g l e/// s t r i n g . I t then wr i t e s the data in to a l i s t o f comma sepera ted/// va lue s ./// </summary>public void EndGame( ){

// The array to s t o r e the data .string [ ] datar r = new String [ 8 ] ;// The s t r i n g t ha t s t o r e s the comma sepera ted array va lue s .string gamdat ;

// Stop a l l b a l l movement .gmeact = fa l se ;

// Convert a l l necessary game data to S t r ing .


string id = Convert . ToString (DateTime .Now) ;string spd = Convert . ToString ( b a l l [ 0 ] . ba l l spd ) ;string p l y r 1 s c r = Convert . ToString ( s c r e . p l y r 1 s c r ) ;string p l y r 2 s c r = Convert . ToString ( s c r e . p l y r 2 s c r ) ;string s c r = Convert . ToString ( s c r e . s c r e + s c r e . timbon ) ;string tim = Convert . ToString ( s c r e . gammin) + ” : ” +

Convert . ToString ( s c r e . gamsec ) ;string b l s = Convert . ToString ( s c r e . l i v e s ) ;string hcs = Convert . ToString ( hapt ) ;

// Store a l l the conver ted game data in the array .datar r [ 0 ] = id ;datar r [ 1 ] = p l y r 1 s c r ;datar r [ 2 ] = p l y r 2 s c r ;datar r [ 3 ] = s c r ;datar r [ 4 ] = tim ;datar r [ 5 ] = b l s ;datar r [ 6 ] = spd ;datar r [ 7 ] = hcs ;

// Parse the data in to a s i n g l e s t r i n g .gamdat = String . Jo in ( ” , ” , datar r ) ;

// Try to wr i t e the data to f i l e .dl . LogData ( gamdat ) ;

}

#reg ion Main XNA Methods

/// <summary>/// LoadContent w i l l be c a l l e d once per game and i s the p lace to load/// a l l g raph ic s content ./// </summary>protected override void LoadContent ( ){

// Create a new Spri teBatch , which can be used to draw t e x t u r e s .sp r i t eBatch = new Spr i teBatch ( GraphicsDevice ) ;

// Loads the p layer t e x t u r e and s e t s the width o f the p layer// to the width o f the p layer icon .p lyrchar = this . Content . Load<Texture2D>(” p ly rchar ” ) ;

for ( int i = 0 ; i < plyrmax ; i++){

p ly r [ i ] . p lyrwid = plyrchar .Width ;}

// Loads a l l the p layer t e x t u r e s .ba l l c ha r = this . Content . Load<Texture2D>(” b a l l ” ) ;b lkchar = this . Content . Load<Texture2D>(” block ” ) ;divbord = this . Content . Load<Texture2D>(” divbord ” ) ;arcade = this . Content . Load<SpriteFont>(”Arcade” ) ;

}

/// <summary>/// UnloadContent w i l l be c a l l e d once per game and i s the p lace to/// unload a l l content ./// </summary>protected override void UnloadContent ( ){}


/// <summary>/// Allows the game to run l o g i c such as updat ing the world ,/// check ing f o r c o l l i s i o n s , ga the r ing input , and p lay ing audio ./// </summary>/// <param name=”gameTime”>Provides a snapshot o f t iming/// va lue s .</param>protected override void Update (GameTime gameTime){

// I f the game has not f i n i s h e d .i f ( gmeact ){

// Check each p layer f o r any movement .for ( int i = 0 ; i < plyrmax ; i++){

MovePlayer ( i ) ;}

// Moves each a c t i v e b a l l by t h e i r speed and v e l o c i t y params .for ( int i = 0 ; i < ballmax ; i++){

i f ( b a l l [ i ] . b a l l a c t ){

MoveBall ( b a l l [ i ] ) ;}

}

// S t a r t s the t imer count a f t e r the f i r s t b a l l launch .i f ( s c r e . t imact ){

s c r e . UpdateTime (( long )gameTime . ElapsedGameTime . Tota lMi l l i s e c onds ) ;

}

// Check whether a l l b l o c k s are des t royed . I f so , end the// game .i f ( b lkdes == b l k t l e ){

EndGame( ) ;}

base . Update (gameTime) ;}

}

/// <summary>/// This i s c a l l e d when the game shou ld draw i t s e l f ./// </summary>/// <param name=”gameTime”>Provides a snapshot o f t iming/// va lue s .</param>protected override void Draw(GameTime gameTime){

// Clears the screen and draws i t b l a c k .GraphicsDevice . Clear ( Color . Black ) ;

sp r i t eBatch = new Spr i teBatch ( GraphicsDevice ) ;

sp r i t eBatch . Begin (SpriteBlendMode . AlphaBlend , SpriteSortMode . Deferred ,SaveStateMode . SaveState ) ;

// Ca l l the func t i on to draw a p layer .



DrawPlayer ( p ly r [ i ] ) ;}

// Ca l l the func t i on to draw a b a l l .for ( int i = 0 ; i < ballmax ; i++){

DrawBall ( b a l l [ i ] ) ;}

// Ca l l the func t i on to draw a b l o c k .for ( int i = 0 ; i < b l k c o l ; i++){


DrawBlocks ( i , j ) ;}

}

// Ca l l the func t i on to draw the UI .DrawUI ( ) ;

sp r i t eBatch . End ( ) ;

base .Draw(gameTime) ;}

/// <summary>/// Allows the game to perform any i n i t i a l i z a t i o n i t needs to be f o r e/// s t a r t i n g to run . This i s where i t can query f o r any requ i red/// s e r v i c e s and load any non−graph ic r e l a t e d content . Ca l l i n g/// base . I n i t i a l i z e w i l l enumerate through any components/// and i n i t i a l i z e them as we l l ./// </summary>protected override void I n i t i a l i z e ( ){

// Ca l l the func t i ons to i n i t i a l i s e each o b j e c t .I n i tP l ay e r ( ) ;I n i tB a l l ( ) ;I n i tB lo ck ( ) ;In i tUI ( ) ;

// I n i t i a l i s e the score .s c r e = new Score ( ) ;s c r e . I n i t i a l i z e ( ) ;

// Create a data l o g g e r o b j e c t wi th a f i l e name .dl = new DataLogger ( ”GStat” ) ;

// Act i va te the game .gmeact = true ;

// I n i t i a l i z e the accumulated movement vec to r f o r each p layer .accumove = new Vector2 [ plyrmax ] ;


accumove [ i ] = new Vector2 ( ) ;}

base . I n i t i a l i z e ( ) ;


}

/// <summary>/// This c r ea t e s the Graphics Manager and s e t s the d i s p l a y to f u l l/// screen ./// </summary>public Engine ( ){

graph i c s = new GraphicsDeviceManager ( this ) ;g raph i c s . I sFu l l S c r e en = true ;

Content . RootDirectory = ”Content” ;}

#endreg ion}

}


E.4 Input Handler

E.4.1 File: InputHandler.cs

#reg ion F i l e Desc r ip t i on////// F i l e : InputHandler . cs////// The InputHandler c l a s s s t o r e s dev i ce s t a t e informat ion . I t a s s i gn s a/// dev i ce to a p layer and grants e x c l u s i v e access to t ha t dev i ce f o r the/// fo r ce e f f e c t s .///#endreg ion

using System ;using System . Co l l e c t i o n s . Generic ;using System . Linq ;using System . Text ;using Microso f t . DirectX . Direct Input ;

namespace Breong{

class InputHandler{

// Define the minimum and maximum ax i s va lue s .public const int MAX AXIS = 5000 ;public const int MIN AXIS = −5000;

// Store a dev i ce v a r i a b l e .private Device j s ;

// Store the s t a t e o f the dev i ce .private Joy s t i c kS ta t e j s s t a ;

// Store a l i s t o f e f f e c t s o b j e c t s .private List<Ef fectObject> fx ;

// Store an array o f a x i s va lue s .private int [ ] a x i s ;

#reg i on E f f e c t Functions ( Play Ef f e c t , Load Ef f e c t , Get E f f e c t s )

/// <summary>/// This func t ion p lay s a g iven e f f e c t in the/// l i s t o f e f f e c t s ./// </summary>/// <param name=”e f f ”>The ID of the e f f e c t to play</param>public void PlayEf f e c t ( int e f f ){

// Assigns the de s i r ed e f f e c t to an e f f e c t o b j e c t .Ef f e c tObjec t eo = fx [ e f f ] ;

// Play the e f f e c t .eo . S ta r t (1 , E f f e c t S t a r tF l a g s . NoDownload ) ;

}

/// <summary>/// This func t ion re turns the l i s t o f e f f e c t o b j e c t s ./// </summary>/// <returns>The l i s t o f e f f e c t o b j e c t s .</ returns>


public List<Ef fectObject> GetEf f e c t s ( ){

return fx ;}

/// <summary>/// This func t ion loads a fo r ce feedback in to a l i s t o f/// e f f e c t o b j e c t s and a l s o loads i t in to the j o y s t i c k i t s e l f ./// </summary>/// <param name=”name”>The name of the e f f e c t to load</param>/// <returns>The loaded fo r ce feedback e f f e c t </returns>private Ef f e c tObjec t LoadEffect ( string path ){

// Create a new e f f e c t l i s tE f f e c t L i s t e l = null ;

// Load the g iven e f f e c t .e l = j s . GetEf f e c t s ( path , F i l eE f f e c t sF l a g s . ModifyIfNeeded ) ;

// For each loaded e f f e c t , c r ea t e a new ob j e c t and download// i t to the dev i ce .foreach ( F i l e E f f e c t f e in e l ){

Ef f e c tObjec t f e o = new Ef f e c tObjec t (f e . EffectGuid ,f e . E f f e c tS t ruc t ,j s ) ;

try{

f e o . Download ( ) ;}catch ( Exception ex ){

throw new Exception ( ”Could not download f o r c e ” +” feedback e f f e c t f i l e . ” , ex ) ;

}

// Return the e f f e c t .return f e o ;

}

// I f t he re i s no e f f e c t to load , re turn nu l l .return null ;

}

#endreg ion

#reg i on State Fuct ions (Update , GetFireButton , GetAxis )

/// <summary>/// This func t ion updates the j o y s t i c k s t a t e informat ion ./// </summary>/// <returns>True i f the c o n t r o l l e r s t a t e can be updated ,/// f a l s e otherwise</returns>private bool UpdateState ( ){

try{

// Po l l the j o y s t i c k .j s . Po l l ( ) ;// Update j o y s t i c k s t a t e with the current s t a t e .


j s s t a = j s . Cur rentJoys t i ckState ;return true ;

}catch{

return fa l se ;}

}

/// <summary>/// This func t ion re turns the current va lue o f the X ax i s/// from the c o n t r o l l e r ./// </summary>/// <returns>The va lue o f the x ax i s .</ returns>public f loat GetAxisState ( ){

// I f the j o y s t i c k s t a t e can be updated .i f ( UpdateState ( ) ){

// Return the j o y s t i c k s t a t ereturn ( j s s t a .X) ;

}else{

throw new Appl icat ionExcept ion ( ”Error a cqu i r i ng ” +” ax i s s t a t e in fo rmat ion . ” ) ;

}}

/// <summary>/// This func t ion g e t s the but ton pressed s t a t e o f the f i r e/// t r i g g e r ./// </summary>/// <returns>True i f the but ton i s pressed , f a l s e/// otherwise</returns>public bool FireButtonState ( ){

// I f the c o n t r o l l e r s t a t e can be updated .i f ( UpdateState ( ) ){

// Load the bu t tons in to an arraybyte [ ] btn = j s s t a . GetButtons ( ) ;

// I f the t r i g g e r i s pressed , re turn true .i f ( btn [ 0 ] >= 128){

return true ;}else{

return fa l se ;}

}// Unable to aqu ire c o n t r o l l e r s t a t e , throw excep t ion .else{

throw new Appl icat ionExcept ion ( ”Error a cqu i r i ng ” +”button s t a t e in fo rmat ion . ” ) ;

}}

#endreg ion


/// <summary>/// This cons t ruc tor f i n d s a l l input dev i c e s t ha t are/// fo r ce feedback enab led and a l l o c a t e them to a g iven/// p layer . I t a l s o c a l l s the func t i ons necessary to load/// the f o r ce feedback e f f e c t s in to a g iven l i s t ./// </summary>/// <param name=”ownr”>The c l a s s t ha t r e qu i r e s con t ro l/// o f the device</param>/// <param name=”p l y r”>The p layer to a l l o c a t e the dev i ce to</param>/// <param name=”hapt”>Enable or d i s a b l e hapt i c s</param>public InputHandler ( Engine ownr , int plyr , bool hapt ){

// Get a l i s t o f a l l a t tached dev i c e s t ha t are// at tached and are f o r ce feedback enab led .Dev iceL i s t d ev i c e s = Manager . GetDevices ( DeviceClass . GameControl ,

EnumDevicesFlags . AttachedOnly |EnumDevicesFlags . ForceFeeback ) ;

// Check to see i f the dev i ce i s a v a i l a b l e and// e x c l u s i v e access has not been g iven e l sewhere .i f ( d ev i c e s . Count < p ly r + 1){

throw new Appl icat ionExcept ion ( ”No Con t r o l l e r s Ava i l ab l e ” ) ;}

int p = 0 ;

// For each dev i ce in the gathered l i s t o f dev ices , a l l o c a t e// i t to a p layer .foreach ( Dev ice Ins tance d1 in dev i c e s ){

i f (p == plyr ){

j s = new Device ( d1 . InstanceGuid ) ;i f ( j s == null ){

//Exceptionthrow new Appl i cat ionExcept ion ( ”Unable to ” +

” a s s i gn c o n t r o l l e r to p laye r ” ) ;}

}// Increment p to a l l o c a t e to the next p l ayer .p++;

}

// Give the p layer e x c l u s i v e access to the dev i ce .j s . SetDataFormat ( DeviceDataFormat . Joy s t i ck ) ;j s . SetCooperat iveLeve l ( ownr .Window . Handle ,

Cooperat iveLeve lF lags . Background |Cooperat iveLeve lF lags . Exc lus ive ) ;

// I f hap t i c s are enabled , auto centre the s t i c k .// Otherwise , d i s a b l e i t and a l l hap t i c e f f e c t s .i f ( hapt ){

j s . P rope r t i e s . AutoCenter = true ;}else{

j s . P rope r t i e s . AutoCenter = fa l se ;}


// Acquire the dev i ce .j s . Acquire ( ) ;

// Set up c o n t r o l l e r a x i s .foreach ( Dev iceObject Instance doi in j s . Objects ){

i f ( ( do i . ObjectId & ( int ) DeviceObjectTypeFlags . Axis ) != 0){

j s . P rope r t i e s . SetRange (ParameterHow . ById , do i . ObjectId ,new InputRange (MIN AXIS , MAX AXIS) ) ;

ax i s = new int [ 1 ] ;}

ax i s [ ax i s . Length − 1 ] = doi . O f f s e t ;i f ( ax i s . Length == 2){

break ;}

}

// I n i t i a l i s e the e f f e c t l i s t .fx = new List<Ef fectObject >() ;

// Load three e f f e c t s f o r each p layer .fx .Add( LoadEffect ( ” b l kh i t . f f e ” ) ) ;fx .Add( LoadEffect ( ” p l y r 1h i t . f f e ” ) ) ;fx .Add( LoadEffect ( ” p l y r 2h i t . f f e ” ) ) ;

}}

}


E.5 Data Logger

E.5.1 File: DataLogger.cs

#reg ion F i l e Desc r ip t i on////// F i l e : DataLogger . cs////// The DataLogger c l a s s c r ea t e s ( i f the document doesn ’ t e x i s t )/// and wr i t e s data passed as parameters to CSV f i l e s .///#endreg ion

using System ;using System . IO ;using System . Co l l e c t i o n s . Generic ;using System . Linq ;using System . Text ;

namespace Breong{

class DataLogger{

// The name of the f i l e to wr i t e to .private string fn ;

private StreamWriter l og ;

// The ex tens ion o f the f i l e to wr i t e to .private const String ext = ” . csv ” ;

/// <summary>/// This func t i on wr i t e s a g iven s t r i n g o f data to a/// l o g f i l e . I t a t tempts to append t e x t to the end o f/// the f i l e to keep a t a bu l a r s t r u c t u r e ./// </summary>/// <param name=”data”>The data to wr i t e to a f i l e </param>public void LogData (String data ){

// Try to wr i t e data to the f i l e de f ined in the fn v a r i a b l e .try{

l og = F i l e . AppendText ( fn ) ;

l og . WriteLine ( data ) ;l og . Close ( ) ;

}catch ( Exception ){

throw new Appl icat ionExcept ion ( ”Unable to wr i t e data to ” +” text f i l e ” ) ;

}}

/// <summary>/// This cons t ruc tor checks whether the f i l e name has been/// de f ined . I f i t has , i t then checks i f the f i l e e x i s t s ./// I f the f i l e doesn ’ t e x i s t , i t c r ea t e s i t ./// </summary>/// <param name=”fn”>The f i l e name to attempt to open</param>


public DataLogger (String fn ){

// I s the re data in the fn v a r i a b l e .i f ( fn != null ){

this . fn = fn + ext ;}else{

throw new Appl icat ionExcept ion ( ”Log f i l e name i s i n v a l i d ” ) ;}

// Try and crea t e the f i l e i f i t doesn ’ t e x i s t , c r ea t in g the// headers needed fo r the t a b l e o f r e s u l t s .try{

i f ( ! F i l e . Ex i s t s ( this . fn ) ){

l og = F i l e . CreateText ( this . fn ) ;l og . WriteLine ( ” id , Player 1 Score , Player 2 Score , ” +

”Fina l Score , Time Taken , Ba l l s Lost , ” +”Game Speed , Haptics Enabled” ) ;

l og . Close ( ) ;}

}catch ( Exception ){

throw new Appl icat ionExcept ion ( ”Unable to open log f i l e ” ) ;}

}}

}


E.6 Game Ball

E.6.1 File: Ball.cs

#reg ion F i l e Desc r ip t i on////// F i l e : Ba l l . cs////// The b a l l c l a s s s t o r e s s t a t e informat ion about each b a l l . I t/// checks whether the b a l l i s s t i l l in p lay and whether the b a l l/// has c o l l i d e d with a game ob j e c t or wa l l . I t c a l c u l a t e s how i t/// shou ld reac t and updates the s t a t e accord ing l y .///#endreg ion

using System ;using System . Co l l e c t i o n s . Generic ;using System . Linq ;using Microso f t .Xna . Framework ;using Microso f t .Xna . Framework . Graphics ;

namespace Breong{

public class Bal l{

// Var iab l e s to s t o r e b a l l pos i t i on , v e l o c i t y , speed// and co lour .public Vector2 ba l l p o s ;public Vector2 b a l l v e l ;public f loat ba l l spd ;public Color b a l l c o l ;

// Var iab l e s to s t o r e the prev ious p layer who h i t the b a l l ,// whether the b a l l i s a c t i v e and in p lay and whether// the b a l l has c o l l i d e d with the wa l l .public int prep ly r ;public Boolean b a l l a c t ;public Boolean inp ly ;public Boolean wa l l c o l ;

// Def ines movement bounds and h i t box .Rectangle bal lbound ;public Rectangle b a l l s i z ;

// Block v a r i a b l e s f o r c o l l i s i o n de t e c t i onprivate f loat blkmid ;private f loat b l k l e f ;private f loat b l k r i g ;private f loat maxsiz ;

// Make b a l l immune from b lo ck c o l l i s i o npublic int ballimm ;

#reg i on Boundary/ Co l l i s i o n Checking

/// <summary>/// This func t ion checks whether a b a l l i s w i th in the boundary/// area . I f i t i s , i t then checks whether i t has h i t a wa l l ./// I f i t h i t s the b a l l , i t rebounds and s e t s a wa l l c o l l i s i o n/// v a r i a b l e to t rue .


/// </summary>/// <returns>True i f the b a l l i s s t i l l in play ,/// f a l s e o therwi se .</ returns>public Boolean CheckBounds ( ){

i f ( ba l l p o s .X >= bal lbound .Width − 5){

// Bounce o f f a wa l l .i f ( b a l l v e l .X > 0){

b a l l v e l .X ∗= −1;wa l l c o l = true ;return true ;

}}i f ( ba l l p o s .X <= 0 + 5){

// Bounce o f f a wa l l .i f ( b a l l v e l .X < 0){

b a l l v e l .X ∗= −1;wa l l c o l = true ;return true ;

}}i f ( ba l l p o s .Y >= bal lbound . Height + 20){

// Ba l l has f a l l e n out o f p lay .i f ( b a l l v e l .Y > 0){

b a l l v e l .Y ∗= −1;return fa l se ;

}}i f ( ba l l p o s .Y <= −20){

// Ba l l has f a l l e n out o f p lay .i f ( b a l l v e l .Y < 0){

b a l l v e l .Y ∗= −1;return fa l se ;

}}return true ;

}

/// <summary>/// This func t ion checks whether the b a l l has c o l l i d e d with/// the p layer . Based on the x po s i t i on o f the p layer and/// the b a l l , i t rebounds in a d i f f e r e n t way , with a s t e epe r/// ang le at the f a r ends o f the p layer icon ./// </summary>/// <param name=”p ly rxpos”>The x po s i t i on o f the p layer .</param>public void P l y rCo l l i s i o n ( f loat plyrxpos ){

// Ca l cu la t e the d i f f e r e n c e between the l e f t o f the p layer// and the centre o f the b a l l .f loat d i f f = ( ba l l p o s .X + 5) − plyrxpos ;

// The l e f t s i d e o f the p layer .i f ( d i f f < 5){


b a l l v e l .X = −1.25 f ;}else i f ( d i f f < 12 && d i f f >= 5){



b a l l v e l .X = −0.5 f ;}// The centre o f the p layer .else i f ( d i f f <= 35 && d i f f >= 25){

i f ( d i f f >= 25 && d i f f <= 27){

b a l l v e l .X = −0.25 f ;}else i f ( d i f f <= 35 && d i f f >= 33){

b a l l v e l .X = 0.25 f ;}else i f ( d i f f >= 28 && d i f f <= 29 .5 ){

b a l l v e l .X = −0.15 f ;}else{

b a l l v e l .X = 0.15 f ;}

}// The r i g h t s i d e o f the p layer .else i f ( d i f f > 35 && d i f f <= 43){

b a l l v e l .X = 0 .5 f ;}else i f ( d i f f > 43 && d i f f <= 49){

b a l l v e l .X = 0.75 f ;}else i f ( d i f f > 49 && d i f f <= 55){

b a l l v e l .X = 1 .0 f ;}else i f ( d i f f > 55){

b a l l v e l .X = 1.25 f ;}

// Reset the Y v e l o c i t y and r e po s i t i on the b a l l// d i f f e r e n t l y based on the d i r e c t i on o f t r a v e l .i f ( b a l l v e l .Y >= 0){

b a l l v e l .Y = −1;ba l l p o s .Y −= 2 ;b a l l s i z .Y −= 2 ;

}else{


b a l l v e l .Y = 1 ;ba l l p o s .Y += 2 ;b a l l s i z .Y += 2 ;

}

// Normalise the b a l l v e l o c i t y and mu l t i p l y by the// speed o f the b a l l .b a l l v e l . Normalize ( ) ;b a l l v e l = Vector2 . Mult ip ly ( b a l l v e l , ba l l spd ) ;

}

/// <summary>/// This func t ion checks whether a b a l l has c o l l i d e d with a b l o c k ./// Depending on the s i d e o f the b l o c k which has been s t ruck causes/// the b a l l to rebound in a d i f f e r e n t way ./// </summary>/// <param name=”b l kpo s”>The po s i t i on vec tor o f the b l o c k .</param>public void Blo ckCo l l i s i on ( Rectangle blkpos ){

// Ca l cu la t e the d i s t ance o f the b a l l from the l e f t o f the// b l o c k .b l k l e f = ( ( ba l l p o s .X + 5) − blkpos .X) − ( b lkpos . Height / 2) ;// Ca l cu la t e the d i s t ance from the centre o f the b l o c k .blkmid = ( ( ba l l p o s .Y + 5) − blkpos .Y) − ( b lkpos . Height / 2) ;// Ca l cu la t e the d i s t ance o f the b a l l from the r i g h t o f the// b l o c k .b l k r i g = ( ( ba l l p o s .X + 5) − blkpos .Width ) + ( blkpos . Height / 2) ;

// Ca l cu la t e the maximum va l i d d i s t ance .maxsiz = 5 + ( blkpos . Height / 2) ;

// I f the d i r e c t i on o f the b a l l can be changed .i f ( ballimm == 0){

// Ca l cu la t e i f the b a l l has s t ruck the l e f t s i d e o f the// b l o c k .i f (Math . Abs ( b l k l e f ) >= Math . Abs ( blkmid ) &&

Math . Abs ( b l k l e f ) <= maxsiz ){

b a l l v e l .X ∗= −1;// Move the b a l l away from the b l o c k .ba l l po s .X −= maxsiz − Math . Abs ( b l k l e f ) ;

}// Ca l cu la t e i f the b a l l has s t ruck the r i g h t s i d e o f the// b l o c k .else i f (Math . Abs ( b l k r i g ) >= Math . Abs ( blkmid ) &&

Math . Abs ( b l k r i g ) <= maxsiz ){

b a l l v e l .X ∗= −1;ba l l p o s .X += maxsiz − Math . Abs ( b l k r i g ) ;

}// Ba l l has h i t the top or the bottom s ide o f the b l o c k .else{

b a l l v e l .Y ∗= −1;

// Ca l cu la t e what d i r e c t i on the b a l l i s going in to// move the b l o c k .i f ( b a l l v e l .Y > 0){

ba l l po s .Y += 2 + maxsiz − Math . Abs ( blkmid ) ;}


else{

ba l l po s .Y −= 2 + maxsiz − Math . Abs ( blkmid ) ;}

}

// Make the b a l l immune to d i r e c t i on changes .ballimm = 1 ;

}}

#endreg ion

/// <summary>/// This func t i on r e s e t s the s t a t e o f a b a l l . I t r e s e t s/// pos i t i on , co lour and the p layer who cu r r en t l y c on t r o l s/// the b a l l ./// </summary>/// <param name=”p ly rpos”>The po s i t i on o f the p layer who/// shou ld own the b a l l </param>public void ResetBa l l ( Vector2 p lyrpos ){

// Set the b a l l p o s i t i on to the p layer po s i t i on .ba l l po s = plyrpos ;

// Of f s e t the b a l l p o s i t i on based on the p layer who// con t r o l s i t . Reset accord ing l y .i f ( p r ep ly r == 0){

ba l l po s .X += 25 ;ba l l p o s .Y += 8 ;b a l l c o l = Color . Red ;p rep ly r = 1 ;b a l l v e l = new Vector2 (−1 , −1) ;

}else{

ba l l po s .X += 25 ;ba l l p o s .Y −= 8 ;b a l l c o l = Color . Blue ;p r ep ly r = 0 ;b a l l v e l = new Vector2 (1 , 1) ;

}

b a l l v e l . Normalize ( ) ;b a l l v e l = Vector2 . Mult ip ly ( b a l l v e l , ba l l spd ) ;

this . b a l l s i z .X = ( int ) ba l l p o s .X;this . b a l l s i z .Y = ( int ) ba l l p o s .Y;

b a l l a c t = fa l se ;wa l l c o l = fa l se ;

ballimm = 0 ;}

/// <summary>/// This cons t ruc tor i n i t i a l i s e s each b a l l based on g iven/// po s i t i on and speed ./// </summary>/// <param name=”pos”> I n i t i a l p o s i t i on o f the b a l l </param>/// <param name=”view”>The drawable area o f the screen</param>


/// <param name=”spd”>The speed o f the b a l l </param>public Bal l ( Vector2 pos , Viewport view , f loat spd ){

// Set the po s i t i on and o f f s e t f o r p l ayer 1 .ba l l po s = pos ;ba l l p o s .X += 25 ;ba l l p o s .Y −= 8 ;prep ly r = 0 ;

// Set the b a l l speed and i n i t i a l i s e the v e l o c i t y vec to r .ba l l spd = spd ;b a l l v e l = new Vector2 (1 , 1) ;

// Set the i n i t i a l co lour .b a l l c o l = Color . Blue ;

b a l l v e l . Normalize ( ) ;b a l l v e l = Vector2 . Mult ip ly ( b a l l v e l , ba l l spd ) ;

// Set the boundary o f the b a l l .bal lbound = new Rectangle ( view .X, view .Y,

view .Width − 100 , view . Height ) ;

// I n i t i a l i s e the h i t box o f the b a l l .b a l l s i z = new Rectangle ( ( int ) ba l l p o s .X,

( int ) ba l l p o s .Y, 10 , 10) ;

// Make the b a l l i n a c t i v e and s e t wa l l c o l l i s i o n to f a l s e .ba l l a c t = fa l se ;wa l l c o l = fa l se ;

// Turn b a l l immunity o f fballimm = 0 ;

}}

}


E.7 Game Blocks

E.7.1 File: Block.cs

#reg ion F i l e Desc r ip t i on////// F i l e : Block . cs////// The b l o c k c l a s s s t o r e s s t a t e informat ion about each b l o c k . I t/// i s i n i t i a l i s e d to a type and a va lue as we l l as a co lour .///#endreg ion


namespace Breong{

public class Block{

// The pos i t i on , co lour , type and va lue o f the b l o c k .public Vector2 blkpos ;public Color b l k c o l ;public int blktyp ;public int b lkva l ;

// Whether or not the b l o c k has been des t royed .public Boolean blkdes ;

// Def ines b l o c k po s i t i on i n g boundary and h i t boxes .public Rectangle blkbnd ;public Rectangle b l k s i z ;

/// <summary>/// Destroys a b l o c k by s e t t i n g the s i z e and po s i t i on/// o f the b l o c k to 0 ./// </summary>public void Destroy ( ){

this . b l k s i z = new Rectangle (0 , 0 , 0 , 0) ;b lkdes = true ;

}

/// <summary>/// This func t ion i n i t i a l i s e s a crea ted b l o c k to a pos i t i on ,/// type , va lue and co lour ./// </summary>/// <param name=”pos”>The po s i t i on o f the b l o c k .</param>/// <param name=”typ”>The type o f the b l o c k .</param>public void I n i t i a l i z e ( Vector2 pos , int typ ){

blkpos = new Vector2 ( pos .X, pos .Y) ;b l k s i z = new Rectangle ( ( int ) b lkpos .X, ( int ) b lkpos .Y, 30 , 15) ;blktyp = typ ;i f ( typ == 0){

b l k c o l = Color . ForestGreen ;


b lkva l = 100 ;}else i f ( typ == 1){

b l k c o l = Color . SkyBlue ;b lkva l = 200 ;

}else i f ( typ == 2){

b l k c o l = Color . Salmon ;b lkva l = 200 ;

}else i f ( typ == 3){

b l k c o l = Color . S i l v e r ;b lkva l = 300 ;

}blkdes = fa l se ;

}

public Block ( ){}

}}


E.8 Player

E.8.1 File: Player.cs

#reg ion F i l e Desc r ip t i on////// F i l e : Player . cs////// The Player c l a s s s t o r e s s t a t e informat ion about each p layer ./// I t c a l c u l a t e s the s t a r t i n g po s i t i on o f each p layer and as s i gn s/// a co lour to each . I t a l s o s t o r e s how f a s t each p layer can t r a v e l/// and conta ins a func t ion which c a l c u l a t e s how fa r each p layer/// can move wi th in a de f ined boundary .///#endreg ion


namespace Breong{

public class Player{

// Var iab l e s to s t o r e pos i t i on , width , co lour and speedpublic Vector2 p lyrpos ;public int plyrwid ;public Color p l y r c o l ;public f loat plyrspd ;

// Def ines movement bounds and h i t box .Rectangle p l y r cn t r ;public Rectangle p l y r s i z ;

/// <summary>/// This func t ion checks whether a p layer chara ter can move/// by a g iven amount ./// </summary>/// <param name=”amount”>The amount to move the p layer</param>/// <returns></returns>public Vector2 CheckMove ( Vector2 amount ){

// Ca l cu la t e where the charac ter w i l l move to .Vector2 pos = plyrpos + amount ;

// Ensure the new po s i t i on f a l l s w i th in the bound .pos .X = MathHelper . Clamp(

pos .X, p l y r cn t r .X,p l y r cn t r .X + ( p l y r cn t r .Width − this . p lyrwid ) ) ;

pos .Y = MathHelper . Clamp(pos .Y, p l y r cn t r .Y,p l y r cn t r .Y + p ly r cn t r . Height ) ;

// Return the d i s t ance a l l owed to t r a v e lreturn pos − p lyrpos ;

}


/// <summary>/// This Constructor i n i t i a l i s e s each p layer charac ter by s e t t i n g/// the v a r i a b l e va lue s based on parameters t ha t have been passed/// to i t ./// </summary>/// <param name=”view”>The drawable area o f the screen</param>/// <param name=”plyrno”>The p layer to i n i t i a l i s e </param>public Player ( Viewport view , int plyrno ){

// I f p l ayer 1 , i n i t i a l i s e in one l o c a t i on and s e t co louri f ( p lyrno == 0){

p ly r cn t r = new Rectangle ( view .X, view . Height − 38 ,view .Width − 100 , 8) ;

p lyrpos = new Vector2 ( ( p l y r cn t r .Width / 2) − 30 ,p l y r cn t r . Top) ;

p l y r c o l = Color . Blue ;}else{

p ly r cn t r = new Rectangle ( view .X, view .Y + 30 ,view .Width − 100 , 8) ;

p lyrpos = new Vector2 ( ( p l y r cn t r .Width / 2) − 30 ,p l y r cn t r . Top) ;

p l y r c o l = Color . Red ;}

// Set the h i t box to the po s i t i on and s i z e o f the p layerthis . p l y r s i z = new Rectangle ( ( int ) p lyrpos .X,

( int ) p lyrpos .Y, 60 , 10) ;

// Set the p layer speedplyrspd = 6 .0 f ;

}}

}


E.9 Score Logging

E.9.1 File: Score.cs

#reg ion F i l e Desc r ip t i on////// F i l e : Score . cs////// Stores time score , combo and the amount o f b a l l s l o s t . The/// engine updates the va lue s . I t a l s o c a l c u l a t e s the score by/// mu l t i p l y i n g a g iven va lue by the cu r r en t l y recorded combo va lue .///#endreg ion

using System ;using System . Co l l e c t i o n s . Generic ;using System . Linq ;using System . Text ;

namespace Breong{

public class Score{

//TIMEpublic Boolean t imact ;public Int64 gamsec ;public Int64 gammin ;public Int64 gammil ;f loat mi l i n t ;f loat s e c i n t ;

//SCOREpublic Int64 s c r e ;public Int64 p l y r 1 s c r ;public Int64 p l y r 2 s c r ;public int screcom ;public Int64 timbon ;

//LIVESpublic int l i v e s ;

public Score ( ){}

public void I n i t i a l i z e ( ){

//TIMEt imact = fa l se ;gammil = 0 ;m i l i n t = 1000 f ;s e c i n t = 60 f ;

screcom = 1 ;timbon = 30000 ;

l i v e s = 0 ;}

public void UpdateTime ( long e l apmi l )


{gammil += e lapmi l ;i f ( timbon > 0){

timbon = timbon − 1 ;}

i f ( gammil >= mi l i n t ){

gamsec += 1 ;gammil = 0 ;

}

i f ( gamsec >= s e c i n t ){

gammin += 1 ;gamsec = 0 ;

}}

public int CalcScore ( int baseva l ){

return ( baseva l ∗ screcom ) ;}

}}

Appendix F

Project CD

312

Analysing the E ect of Additional Haptic Information on ...mdv/courses/CM30082/projects.bho/2009-10/... · Analysing the E ect of Additional Haptic Information on Task Performance

Documents