Geometry Friends
A cooperative game using the Wii Remote
José Bernardo Guimarães Rocha
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Júri
Presidente: Professor Doutor Joaquim Armando Pires Jorge
Orientador: Professor Doutor Rui Filipe Fernandes Prada
Co-Orientador: Professor Doutor Mário Rui Fonseca Dos Santos Gomes
Vogal: Professor Doutor Nuno Manuel Robalo Correia
Maio de 2009
Acknowledgements
I would like to acknowledge Samuel Mascarenhas for the work done in the development of Geometry
Friends. I would also like to thank all the people that were involved with testing Geometry Friends.
Additionally, I would like to thank Sandra Gama for supplying me with the LaTeX model for this document,
invaluable LaTeX tips and proof reading this document.
i
ii
Resumo e palavras-chave
Resumo Nestre trabalho, apresentamos a nossa experiência no desenho e desenvolvimento de um
jogo cooperativo simples e co-localizado que utiliza o Wii Remote para controlar as personagens.
De acordo com um estudo recente, existe uma demografia inteira de pontenciais jogadores que
perfere este tipo de jogo e não joga actualmente devido a falta de ofertas.
Começamos com a exposição do trabalho relacionado - Desafios de Gameplay; Padrões de Desenho para Jogos; Teorias de Tarefas de Grupo (do campo de Psicologia Social); Análise de jogos
cooperativos; A Wii, o seu comando e o software para o utilizar num PC. Continuamos através da
exploração do potencial para a cooperação de cada um dos tipos de Tarefas de Grupo e através
da formalização de várias mecânicas de jogo que encontrámos durante a análise de jogos.
De seguida, examinamos a nossa experiência no desenho e desenvolvimento de Geometry
Friends. Em termos de desenho, tivemos o cuidado de utilizar os Padrões de Desenho para
Jogos e Desafios de Gameplay que suportavam jogabilidade cooperativa. Enquanto, em termos
de desenvolvimento tecnológico utilizámos várias tecnologias que nos permitram criar o jogo que
intencionávamos criar - um motor de jogo (XNA), um motor de física (Farseer) e uma API que
permitia utilizar o Wii Remote (WiimoteLib).
Realizámos vários testes com utilizadores durante o desenvolvimento do jogo para determinar se
o jogo era divertiado, cooperativo e se os controlos eram adequados. Globalmente, os resultados
dos testes foram positivos.
Palavras-chave: Jogo Cooperativo Co-localizado, Wii Remote, Desafios de Gameplay, Padrões de
Desenho para Jogos
iii
iv
Abstract and keywords
Abstract In this paper, we expose our experience in designing and developing a simple co-located and
cooperative game that uses the Wii Remote for character control. According to a recent study,
there is an entire demographic of potential players that favours this type of game and does not
currently play due to lack of offerings.
We begin by exposing related work - Gameplay Chalenges; Game Design Patterns; Group Task
Theories (from the field of Social Psychology); Analysis of cooperative games; The Wii, it’s controller and software for using it on a PC. We continue by exploring the potential for cooperation
of each of the Group Task types and formalizing several game mechanics we encountered while
doing our game analysis.
We then proceed to examine our experience in designing and developing Geometry Friends. From
a design perspective, we carefully used some of the Design Patterns and Gameplay Challenges
that were supportive of cooperative gameplay. While, from a technological development perspective we used several technological solutions that allowed us to create the game we set out to
create. These were - a game engine (XNA), a physics engine (Farseer) and an API that allowed
interfacing with the Wii Remote (WiimoteLib).
Several user tests were made during the development of the game so that we could ascertain if the
game was fun, cooperative and if the controls were adequate. Overall, the results of the evaluation
were positive.
Keywords: Co-located Cooperative Video Games, Wii Remote, Gameplay Challenges, Game Design
Patterns
v
vi
Contents
Acknowledgements
i
Index
vi
List of Figures
ix
List of Tables
x
1 Introduction
1
2 State of the Art
2.1 Challenges . . . . . . . . . . .
2.1.1 Pure Challenges . . . .
2.1.2 Applied Challenges . .
2.2 Game Design Patterns . . . . .
2.3 Social Psychology . . . . . . .
2.3.1 Ringelmann effect . . .
2.3.2 Task Classification . . .
2.4 Game Analysis . . . . . . . . .
2.4.1 World of Warcraft . . . .
2.4.2 Lego Star Wars . . . . .
2.4.3 Team Fortress 2 . . . .
2.4.4 Left 4 Dead . . . . . . .
2.4.5 Counter-Strike . . . . .
2.5 Wii . . . . . . . . . . . . . . . .
2.5.1 Wii Remote . . . . . . .
2.5.2 Nunchuk . . . . . . . .
2.5.3 Wii Remote and the PC
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
6
8
9
9
9
10
10
12
13
15
17
19
19
20
20
3 Conceptual Model
3.1 Task potential for cooperation . . . . . .
3.1.1 Divisibility . . . . . . . . . . . . .
3.1.2 Optimizing . . . . . . . . . . . .
3.1.3 Combinability . . . . . . . . . . .
3.2 Challenges used in Cooperative Games
3.2.1 Pure Challenges . . . . . . . . .
3.2.2 Applied Challenges . . . . . . .
3.3 Design Patterns for Cooperative games
3.3.1 Complementarity . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
26
26
27
27
30
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
viii
CONTENTS
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
Synergies between abilities . . . . . . . . .
Support Abilities . . . . . . . . . . . . . . .
Shared Goals . . . . . . . . . . . . . . . . .
Synergies between goals . . . . . . . . . .
Special Rules for Players of the same Team
Mechanisms for sharing . . . . . . . . . . .
4 Geometry Friends
4.1 Main Characteristics . . . . .
4.2 Overview . . . . . . . . . . .
4.2.1 Player Motivation. . .
4.2.2 Game Genre. . . . . .
4.2.3 Target Customer. . . .
4.2.4 Target Platforms. . . .
4.2.5 Design Objectives. . .
4.3 Designing Geometry Friends
4.3.1 Patterns Used . . . .
4.3.2 Challenges used . . .
4.3.3 Tasks used . . . . . .
4.4 Technological Solutions . . .
4.4.1 XNA . . . . . . . . . .
4.4.2 Farseer . . . . . . . .
4.4.3 WiimoteLib . . . . . .
4.4.4 Wiigle . . . . . . . . .
4.5 Development Process . . . .
4.5.1 First Prototype . . . .
4.5.2 Second Prototype . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
32
32
33
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
36
36
36
36
36
36
37
37
37
37
38
38
38
39
39
40
40
42
5 Evaluation
5.1 Mojo Evaluation . . . . . . . . . . . . . . . . . . .
5.1.1 Tester’s Characteristics . . . . . . . . . .
5.1.2 Results . . . . . . . . . . . . . . . . . . .
5.1.3 Adjustments made due to User Feedback
5.2 Final Evaluation . . . . . . . . . . . . . . . . . . .
5.2.1 Method . . . . . . . . . . . . . . . . . . .
5.2.2 Test User’s profiles . . . . . . . . . . . . .
5.2.3 Results . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
45
46
47
48
48
49
49
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Conclusions
55
Bibliography
56
List of Figures
2.1 The Wii Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 The Wii’s Nunchuk accessory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
21
3.1 Conceptual Model Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
35
35
35
40
40
40
42
42
42
42
42
42
Initial sketch of a level . . . . .
Actions of the Ball character . .
Actions of the Square character
Level 1 of the first prototype . .
Level 2 of the first prototype . .
Level 3 of the first prototype . .
Level 1 of the second prototype
Level 2 of the second prototype
Level 3 of the second prototype
Level 4 of the second prototype
Level 5 of the second prototype
Level 6 of the second prototype
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
x
LIST OF FIGURES
List of Tables
2.1
2.2
2.3
2.4
Driver and API License Overview . . . . . . .
Wii Remote Support Overview . . . . . . . .
Wii Remote Extra Features Support Overview
NunChuk Support Overview . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
23
23
24
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
Sample Characteristics . . . . . . . . . . . . . .
Experience with the Wii . . . . . . . . . . . . . .
Game Evaluation Overview . . . . . . . . . . . .
Level Difficulty Evaluation . . . . . . . . . . . . .
Evaluation of the Fun of each level . . . . . . . .
Level Evaluation from a Character’s Perspective
DGD1 profiles of the sample . . . . . . . . . . .
Casual vs Hardcore . . . . . . . . . . . . . . . .
Concentration . . . . . . . . . . . . . . . . . . . .
Challenge . . . . . . . . . . . . . . . . . . . . . .
Player Skills . . . . . . . . . . . . . . . . . . . . .
Control . . . . . . . . . . . . . . . . . . . . . . .
Clear Goals . . . . . . . . . . . . . . . . . . . . .
Feedback . . . . . . . . . . . . . . . . . . . . . .
Immersion . . . . . . . . . . . . . . . . . . . . . .
Social Interaction . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
46
47
47
48
49
49
50
50
51
52
52
52
53
53
xi
.
.
.
.
Chapter 1
Introduction
Nowadays, some of the most successful games offer some sort of cooperative gameplay. In fact, one of
the most successful games of the market is an MMORPG1 , a game genre which tends to be very focused
on cooperation between different players (we are of course referring to World of Warcraft2 ). Similarly,
several other high profile games have a cooperative nature - Counter-Strike3 , one of the most popular
Multiplayer FPS4 games ever, is essentially a game where players cooperate in teams while attempting
to defeat the other team; More recently, Valve (the company behind Counter-Strike) has released Team
Fortress 25 , a sequel to one of the most popular QuakeWorld mods, uses a class-based teamplay as
one of its core mechanics (much like the original mod). Other games have suddenly returned the focus
to the possibility of playing games cooperatively, such as was present on most games during the early
years of the games consoles - Lego Star Wars6 and its sequel are clear examples of this type. These are
games that allow a second player to join in on the fun, despite being able to be played in single-player
mode; The latest Mario, Super Mario Galaxy7 , also allows a second player to play cooperatively.
This sudden re-emergence of cooperative play is supported by the fact that studies on the demographics of players suggest that there is a whole group of potential players that currently do not play
because games are not made for them[1]. This group favors cooperative experiences and play experiences shared with others in the same physical space. This fact may justify the success of Nintendo’s
Wii and some titles such as the Buzz8 series.
Another important benefit of cooperative modes, is that they allow players of different skill levels to
play together. This is their main advantage to competitive player modes. In competitive player modes,
the difference in skill levels between a novice player and an expert player can make it impossible for a
novice player to enjoy the game. This causes a huge barrier to entry for new players which can prevent
the expansion of a game’s player base[7].
Due to its wide user base, interesting and different controller, in addition to its already giant success in
attracting non gamers, the Wii console is a clear opportunity to attempt to reach the previously mentioned
1 Massive
Multiplayer Online Role Playing Games
of Warcraft official website: www.worldofwarcraft.com
3 Counter-Strike official website: www.counter-strike.net
4 First Person Shooter
5 Team Fortress 2 official website: orange.half-life2.com/tf2.html
6 Lego Star Wars official website: www.legostarwarsthevideogame.com
7 Super Mario Galaxy official website: www.supermariogalaxy.com
8 Buzz official website: www.buzzthegame.com
2 World
1
2
CHAPTER 1. INTRODUCTION
demographic. In order to reach this demographic, we developed a simple co-located cooperative game
named Geometry Friends that uses the Wii Remote for input.
This document is organized into six chapters. The first chapter is this introduction, in which we expose the motivation behind this project and the structure of this document. The following one presents
several existing concepts that are helpful when designing a cooperative game. We start by presenting
the concept of gameplay challenges[9] as proposed by Rollings and Adams. It then continues to explore the notion of design patterns as applied to gameplay elements[2]. The following section exposes
relevant social psychology theories for cooperative games - the Ringelmann effect[6] and Steiner’s task
typology[14]. After this initial presentation, we analyse some successful games with cooperative elements so that we can understand how they manage to create interesting cooperative experiences.
Finally, we present information regarding the Wii console, the Wii remote and the current development
stage of using a Wii Remote on the PC.
In chapter three, we present the conceptual model used for developing Geometry Friends. We start
by gauging the potential for cooperation of each of the task types presented in the previous chapter. This
allows us to quickly assess wether a task is supportive of cooperative gameplay by determining its task
type. We the proceed to examine how the challenge types are used to promote cooperation and which
archetypical challenges exist within each type. The last section of this chapter presents game design
patterns that are used to support and promote cooperation in games.
The following chapter, chapter four, presents our work in developing a simple two player cooperative
game using the Wiimote. It begins by laying out our high concept for the game. We continue this chapter
by exposing the technological solutions we chose to employ in the development of the game, as well as
the justifications for their use.
In the next chapter we present our evaluation process and results from testing the game using two
different methodologies. One based on a questionnaire that was constructed by us, while the other is
based on Gameflow’s Criteria for Player Enjoyement[16].
The last chapter exposes the conclusions we drew from our work in this game.
Chapter 2
State of the Art
In order to better understand how a game can be made to be more cooperative, several theories were
analysed - Gameplay Challenges, Game Design Patterns and Social Psychology theories.
2.1
Challenges
Rollings and Adams define gameplay formally as: "‘One or more casually linked series of challenges
in a simulated environment"[9]. This definition of gameplay makes us understand the potential utility of
challenges when designing a cooperative game. If gameplay is viewed as series of linked challenges,
surely, by making sure that the challenges used effectivly promote cooperation, we design a better
cooperative game. They also propose a categorization of gameplay challenges [9]. This categorization
separates the challenges into two groups - Pure and Applied Challenges. They also define two other
classes of challenges implicit (a challenge that is not specifically designed, and is instead an emergent
feature of the game design) and explicit (intentionally designed challenges).
2.1.1
Pure Challenges
Pure challenges are singular units of gameplay, and as such limit themselves to a particular archetype
of gameplay. Typically, in games, challenges are hybrid and rarely appear in their pure form.
Logic and Inference challenges
"‘This type of challenges tests the ability of players to assimilate information and use that information to
decide upon the best course of action"[9]. Logic challenges are usually applied in games with perfect
information (games where the players know the complete state of play). Whereas Inference challenges
are typically present in games with imperfect information (games where players do not know the complete state of play), in which players must atttempt to draw conclusions about the hidden parts of the
state of play.
3
4
CHAPTER 2. STATE OF THE ART
Lateral Thinking challenges
"‘A lateral-thinking challenge tasks the player to draw on their previous experience and knowledge and
combine them in a new and unexpected way "[9]. The knowledge used to surpass these challenges can
be either intrisic (obtained inside the game world) or extrinsic (gained outside the game world, real life
for example).
Memory challenges
"‘Memory challenges tax the player’s memory of recent (and sometimes not so recent) game events"[9].
They rely only on memory of game events, and not memory of events that happened outside the game.
It is important to note that these challenges appear quite often in games as implicit challenges.
Intelligence challenges
"‘Intelligence-based challenges rely purely on the intelligence quotient of the player "[9]. This type of
challenges does not exist in its pure form in games, the only place where this type of challenge is
present is in intelligence quotient (IQ) tests. They often appear as a part of other challenges. A more
intelligent player will perform better in a game that uses the more cerebral challenges.
Knowledge challenges
"‘These rely on the knowledge of player "[9]. They can be dependent of intrisic knowledge or extrinsic
knowledge. Intricic knowledge challenges exist in practically all games, but are most common to games
with a heavy emphasis on background story and characters (such as role-playing games and adventure
games). Extrinsic knowledge challenges are quite common in quiz-type games such as Trivial Pursuit.
Pattern-Recognition challenges
"‘The impressive abilities of the human brain mainly stem from one basic ability: pattern recognition"[9].
This ability can be used effectively in games, by making the player have to recognize a pattern of attack
(Super Mario Advance), a complex system for spells (Dungeon Master) or even secret rooms (Doom).
It is important to be careful when designing games around these challenges, because they can make
or break a game - a player that can make 100% accurate preddictions about an entirely deterministic
game will easily ruin the fun factor for other players.
Moral challenges
"‘High-level challenges that operate at universal, cultural, tribal and personal level. Each successive
level affects a smaller area. Usually, lower levels have precedence"[9]. Universal moral challenges are
invariant no matter what the context is. They concern the good of all living beings within the confines of
the simulated universe, this type of challenges assumes a single correct choice independently of your
own position. Cultural moral challenges relate to the good of a culture (a loosely affiliated collection of
individuals all living by roughly the same standards) as a whole, unlike universal moral challenges, by
2.1. CHALLENGES
5
changing the point of view to that of another culture the correct choice will change aswell. Tribal cultural
challenges deal with the good of any group of closely affiliated individuals. Personal cultural challenges
are a moral choice made for an individual with a direct outcome on that individual’s own well-being and
state of mind. An interesting way to create moral challenges is by challenging the player on different
moral levels at the same time (i.e. the needs of the many outweight the needs of the few).
Spatial Awareness challenges
"‘The purpose of this type of challenge is to test the spatial awareness of the player "[9]. Typically, spatial
awareness challenges are implicit, and as such have only been explored implicitly with success in a
handful of games such as Snakes and Tron. Flight simulators, space-flying games and 3D combat
games usually rely heavily on spatial awareness challenges.
Coordination challenges
"‘This type of challenges tests the ability of the player to perform many simultaneous actions."[9] They
are usually found combined with reflex/reaction time challenges. The pure form of this challenge does
not depend on any time constraints, but this challenge is only found occasionally in its pure form. It is important to consider the degree of precision that this type of challenges should require - allow a degree of
sloppyness or require a delicate touch. A concept that is associated with coordination challenges is timing - "‘the ability to overcome an obstacle by coordinating player moves with something else happening
on the screen"[9]. Another important concept to grasp is the notion of special moves - "‘special abilities
that are triggered by using a complex sequence of joystick moves and button presses". Games that rely
too heavily on special moves are difficult to balance due to the emphasis on the physical dexterity of a
player.
Reflex/reaction challenges
"‘Testing the timing abilities of the player is the focus of this type of challenges"[9]. It is uncommon to
find this type of challenges used in an isolated form and, as was stated above, it is quite common to find
coordination challeges combined with these. Usually, these challenges are a factor in most games, and
only a few types tend not to rely on them - turn-based games, adventures and role-playing games.
Physical challenges
"‘Like expected physical challenges challenge the physical being of a player "[9], and this is in part the
reason why they are rare in games. This is mostly due to the fact that most input methods for computer
games are inadequate for this type of challenge, and supplying an adequate intput device is expensive.
However with advent of the Wii, and the propagation of accelerometer techonology to the other two
consoles, it has become more common to find this type of challenges in games.
6
CHAPTER 2. STATE OF THE ART
2.1.2
Applied Challenges
"‘An applied challenge is the combination of one or more pure challenge forms applied to a given gameplay situation or style"[9].
Race
"‘A race is an attempt to accomplish something before someone else does"[9]. This can be extremely
varied, from an actual physical race through space, to a race for accumulation of resources, to practically anything else. Despite our typical perception of races as competition without conflict they can be
combined with conflict as well. Due to the fact that races put time pressure on a player, they discourage
careful strategic thought and instead encourage direct, brute force solutions.
Puzzles
"‘A puzzle is primarly a mental challenge"[9], that typically is presented as a lock that when solved
opens up another part of the game. Due to the difference in brainpower in each individual, a time limit
on a puzzle may make the puzzle impossible for some players. Puzzles that require trial and error to
complete are a case of bad game design, and should instead be solved by considering the hints and
clues provided inside the game.
Exploration
"‘Exploration is a key element of many games and is often its own reward"[9]. Despite this, exploration
cannot be devoid of challenge or it becomes merely sightseeing, which is quickly exhausted. Some
common obstacles exist to pose challenges to a player’s exploration:
1. Locked door - A common obstacle is the locked door, this does not have to be a literal locked door,
but can be "‘any device that can prevent player progress until the player has done something to
unlock it"[9].
2. Trap - Another typical obstacle to exploration is the trap - "‘a device that somehow harms the
player’s avatar when it is triggered"[9]. It is important to note that, for players, the real fun to be
had with traps comes from finding them and disabling.
3. Maze - "‘An area where every place looks alike"[9]. The player needs to discover how the places
are related to get out, usually by wandering around. In good mazes, there are usually clues to the
maze’s organization found in the rooms, while in poor mazes the player needs to find the way out
by trial and error.
4. Illogical spaces - "‘Illogical spaces are a variant on the maze theme"[9]. Going South of area A to
area B and then North of area B does not bring back to area A, and thus the players are required
to keep a map so that they can find their bearings. This type of obstacle should be used sparringly
and only in places where there is an explanation for it.
5. Teleporters - A teleporter is any mechanism that suddenly transports the player from where he is to
somewhere else. They are the modern equivalent of illogical spaces. Teleporters can be one-way
(allowing for a one way trip only) or two way (they allow the player to teleport back to his previous
2.1. CHALLENGES
7
position). Hidden teleporters can make an area very difficult to explore, if there are many of them
in the area.
Conflict
"‘To win a game, a player must beat the other players. If he beats them by attacking them directly in
some way, the game is about conflict"[9].
The challenges associated with conflict depend on the following:
• Scale of the action - from individuals to whole armies.
• Speed at which the conflict takes place - from turn-based (allowing all the time you want) to frenetic
activity.
• Complexity of victory conditions - from simple survival to complex missions with goals and subgoals.
Scale
• Strategy - "‘Strategy is the mental act of planning: taking advantage of your situation and resources, antecipating your opponent’s moves, knowing and minimizing your weaknesses"[9]. Strategic challenges require that the player assess the game situation carefully and devise a plan of
action. Pure strategy games favour players with a certain type of talent, and appeal more to these
players. Due to the fact that games try to appeal to a broader audience, strategic challenges tend
to include elements of chance and missing information.
• Tactics - "‘Tactics involves putting a plan into execution, the process of accomplishing the goals that
strategy calls for "[9]. Responding to unexpected events or conditions also falls into the domain of
tactics. Tactical games that require no strategy are possible - a small squad combat game in which
the soldiers are always moving into unknown territory contains no opportunities for strategy.
• Logistics - "‘Logistics deals with supporting troops in the field and bringing fresh troops to the
front lines"[9]. Most computer games avoid most of the logistical challenges posed by real life
warfare, such as bringing fuel and food to where they are needed, due to the fact that players find
them boring and distracting from the main focus of the game - combat. However, there is one
important logistical challenge in modern real-time strategy (RTS) games - weapons production (or
unit production). In most RPGs the limited size of the character’s inventories presents another
logistical challenge - a significant portion of the player’s time is spent equiping and balancing a
party of different characters with all they require to fend off against the world.
• Personal - "‘At a personal level, the player controls an avatar who battles directly against one or
more opponents, often at very high speeds"[9]. The challenge of personal combat is immediate,
exciting and visceral.
Victory conditions
• Survival - "‘The fundamental challenge in any conflict-based challenge is survival"[9]. Survival is
about defending oneself, but many games require that the player defend other (usually defenseless) things. The player must prepared to sacrifice some things in order to protect others. In most
conflict games survival in itself is not the victory condition, but it is nevertheless a key component
to victory.
8
CHAPTER 2. STATE OF THE ART
• Stealth - "‘Stealth challenges deal with the ability to move undetected"[9]. They are typically used
in games when a player is placed in situations where he is at a disadvantage and direct combat is
ill-advised.
Economics
"‘An economy is a system in which resources move around, either physically from place to place, or
conceptually, from owner to owner "[9]. This does not necessarily imply money, any resource that can
be created, moved, stored, earned, exchanged, or destroyed can be involved. Economic challenges are
defined in terms of the flow of resources. In some games the challenge is simply to acumulate resources
- the main challenge here comes from understanding the mechanisms by which wealth is created and
to optimize them to his own advantage. A more interesting challenge, comes from attempting to attain
a balance in an economy - produce too little of a vital resource and the whole economy grinds; produce
too much, and it piles up, taking up space and wasting time and resources that could be better used
elsewhere. A peculiar economic challenge involves looking after a small number of entities (or even a
single one), the challenge is making sure their needs are met and perhapes improve their growth.
Conceptual challenges
"‘These require that the player understands something new"[9]. They often occur in construction and
management simulations (where the player must come to understand the processes being simulated).
From a game design perspective, they are the richest and most interesting to design because these
offer broadest scope for innovation. However, they can be difficult to design and even more difficult to
program.
2.2
Game Design Patterns
In 2003, Björk and Lundgren propose the formalisation of game design patterns in a manner much
like the one used by software design patterns[3]. Part of the intent of this formalisation is to have a well
supported language that allows people to understand each other perfectly when analysing and designing
games.
The formalisation of design patterns, as proposed by Björk and Lundgren is as follows:
1. Name - As expected, states the name of pattern, Björk and Lundgren suggest that the names
used should be short, specific and idiomatic, but not necessarily intuitive, so that it can provide
mneumonic support after the description has been read.
2. Description - The description should be a concise description of the pattern, with notes refering
to the game where it was identified, as well as examples of games where the pattern is typically
found and also containing information on how the pattern can effect the structural framework.
3. Consequences - Should present the consequences and trade-offs of the solution that the pattern
suggests, so that an educated choice can be made.
4. Using the pattern - This should present common choices that relate to the pattern’s usage, exemplified by specific game elements from published games.
2.3. SOCIAL PSYCHOLOGY
9
5. Relations - Describes how a pattern relates to other patterns, i.e.: possible conflicts between the
usage of different patterns alongside this one, patterns that are either a more general abstraction
of this pattern, or a more concrete implementation of the pattern described.
According to the authors, one of the important aspects of their choice of design patterns over game
mechanics as common language for game design, is that game mechanics can easily be turned into a
design pattern, while the opposite is not true.
The relevance of design patterns in this work, as opposed to challenges, is that they allow us to formalise more abstract aspects that help create a coooperative game. In order to reduce redundancy, we
chose to only formalise the aspects that proved to difficult to formalise as challenges. Plus, challenges
have the added benefit of using categories that aid in identifying in which game genre a specific type of
challenge should be used.
2.3
Social Psychology
In the field of social psychology, some work has been done in studying and classifying group tasks. We
decided to include Steiner’s typology[14] due to the fact that it can be used to quickly assess the pontential for cooperation presented by the several challenge types - it is essentially, a handy assessment
tool, that can help us understand the face value of any given challenge for cooperation. We also present
an interesting phenomena that happens in groups (and which is also clearly visible in most large group
games) - the Ringelmann effect[6].
2.3.1
Ringelmann effect
An interesting effect that happens when groups of people perform tasks is known as the Ringelmann
effect - imagine that if individual people were able to pull at an average weight of 63 kg by themselves,
two people working in group will not pull a weight of 126 kg, neither will three people be able to pull
189 kg. The number of people in a group has an inverse relationship with the individual effort. Steiner
proposes that this is caused by deficient effort coordination. Another alternative justification for this
problem is that members of the group decrease their motivation.
2.3.2
Task Classification
Steiner[14] proposes a typology of group tasks:
• Divisibility - divisible (doing a math proof) versus unitary (e.g., reading a page)
• Optimizing - maximizing/optimizing (optimizing is a term used for qualitative measures, such as
[writing a good essay]) or minimizing
• Combinability – Additive - group result is the sum of those of its members-e.g.: group pulling a weight using a
rope
– Compensatory - group result is the average of those of its members-e.g., estimating a pig’s
weight based on farmers’ guesses
– Disjunctive - group result is a chosen outcome from some member
10
CHAPTER 2. STATE OF THE ART
– Conjunctive - group result requires every member to contribute-e.g.: a relay race
– Discretionary - group result depends on how individuals’ results are weighted.
2.4
Game Analysis
In order to better understand the game mechanics of cooperative games, several game titles with cooperative gameplay options were examined. This allowed for a better understanding of common mechanics
between several titles, and how certain cooperative game mechanics transcended genres.
2.4.1
World of Warcraft
One of the most popular MMORPGs is World of Warcraft[4]. Like City of Heroes, and many other RPGs,
this game also uses a class template in order to make the gameplay varied. Each one of the games’
classes typically fulfills a role within a group, the most typical way to define the roles each character
plays within a group is called the Holy Trinity[31]:
• Tank - The purpose of this role is to soak most of the damage done by enemies. Typically, tanks
can take more damage than characters performing the other roles before dying, plus they also
mitigate and avoid more of it than others.
• Healer - As expected, the purpose of this role is to heal the members of the group, in order to keep
them from dying.
• Damage Dealer - Characters playing in this role will deal most of the damage done to enemies by
the group. There are two types of damage dealers, ranged and melee damage dealers.
This game currently has ten classes that players can play as:
• Druid - a shapeshifting class that can choose to play as either one of the three roles and is also
capable of stealth;
• Hunter - a ranged damage dealer that has the support of a pet, that is able to set traps;
• Mage - a ranged damage dealer;
• Paladin - a holy warrior that is able to be played as a tank, healer, or melee damage dealer;
• Priest - a class that can choose to play as a healer or as a ranged damage dealer;
• Rogue - a melee damage dealer with stealth, that is capable of opening locks and disarming traps;
• Shaman - a class that is capable of being a healer, melee damage dealer or ranged damage
dealer;
• Warlock - a ranged damage dealer that has demonic minions as pets;
• Warrior - a class that can fill the role of tank or melee damage dealer;
• Death Knight- a Hero class added in the latest expansion that can be played as a melee damage
dealer or as a tank;
World of Warcraft is a real-time conflict game at a personal scale, but, due to it being a MMO, is
somewhat open-ended and victory conditions as such do not exist for the game itself, but rather for
specific aspects of the game. An important separation in WoW and most MMPORPG’s is the difference
between Player versus Player (PvP) and Player versus Environment (PvE).
2.4. GAME ANALYSIS
11
In PvE players fight against computer controlled enemies and the gameplay revolves around doing
quests and dungeons. The objectives of quests are too varied to list here, but the game allows the
sharing of quests so that grouping with other players is both encouraged and viable. Players also have
the option of going into dungeons. These have tougher enemies, and while most of the content that
exists outside it can be easily done by a single player, dungeons are made for groups of players. Most
dungeons are intended for groups of five players, while the bigger ones (which are also known as raids)
are intended for groups of 10 or 25 players. Due to the way that this dungeons are setup, they require
a certain amount of tanks, healers and damage dealers. Healers support the group by keeping it alive,
Damage Dealers support it by dealing damage to the enemies and Tanks support it by minimizing the
damage that it takes.
PvP in WoW is separated into three types - World PvP, Battlegrounds and Arena. The victory conditions depend on the type of PvP in which players are engaged in:
• World PvP - This type of PvP action is typically without goals or objectives, it mostly comes down
to a simple question of survival. However, certain zones of the game have more complex and
optional objectives. These typically involve capturing certain zones, or grabbing and taking an
object into a capture point.
• Battlegrounds - These are essentially PvP maps that have a player limit in them. Objectives are
varied and depend on what battleground you are in – Warsong Gulch[34] - A typical Capture the Flag map where the first team to achieve three
captures wins. This variant does not allow players to perform a flag capture if their flag is not
in its starting position. This causes most of the action in this battleground to occur around
the flag’s starting position and the flag carrier’s position. Which in turn makes it hard for a
single player to succeed in grabbing a flag or taking down a flag carrier. Some of the classes
in this game are better at carrying and running flags beacause they have better survivability
and mobility. Flag carriers are key part of this battleground and should be supported by their
teams;
– Arathi Basin[28] - A capture and hold type of map where players must capture certain zones
and keep control of it so that they can generate points periodically (the first team to 2000
points wins). There are only five locations to capture in this map and they are captured by
using a flag. While doing so, a player is unable to do anything else and any damage taken will
stop prevent the capture. This makes it important for a team to support and protect allies that
are attempting to capture a location. It is quite common that the classes that can use stealth
try and capture a location while the opposition is focused elsewhere;
– Alterac Valley[27] - Here, the objective is depleting your opponents’ reinforcements (killing
members of the enemy team reduces their reinforcement count by one, eliminating their general is an instant victory, capturing certain buildings and eliminating other non player characters also reduces their reinforcement count). Capturing a building works the same way as
in Arathi Basin, and, despite not being vital to winning the map, there are some important
benefits to doing so. A captured graveyard helps with the logistical aspect of conflict, letting
players that have died respawn closer to where the action is taking place. A team’s general
is protected by four characters, these are linked to that team’s four towers. If the towers are
captured for the first time they are despawned. This makes it easier to eliminate the enemy’s
general not only because he loses protection, but also because while these characters are
alive the general is stronger;
12
CHAPTER 2. STATE OF THE ART
– Eye of the storm[30] - A mixture between Warsong Gulch and Arathi Basin, is a race for points
where having control over towers yelds points periodically, and capturing a flag (that starts in
the center of the map) in one of your towers also awards a number of points (depending on
how many towers that team is holding). Unlike the other battlegrounds that allow the capturing
of locations, in Eye of the Storm capturing does not require using a flag. Instead the team that
has the most players in a location will start capturing it. This provides incentive for players to
group together so that they can capture a location. Like in Warsong gulch, certain classes
are better suited for flag carrying;
– Strand of the Ancients[33] - In this battleground, teams take turns attacking and defending a
relic. The team that captures the relic in the shortest ammount of time wins. In order to reach
the relic the attacking team needs to destroy the walls that are blocking the way. Similarly to
the Alterac Valley battleground, graveyards can be captured so that a team can reinforce its
front lines more quickly. However, only the attacking team can do so, and the defending team
cannot recover a captured graveyard. One of the main focus for the attacking team is using
siege weapons to break down the walls. The defending team has turrets at the walls that help
them deal with these siege weapons and enemy players. Another way to break down the
walls is by using explosive charges that they can pick up at special places. These deal 25%
damage to the wall after 10 seconds. Defending players can defuse them and it is imperative
that they do so. In this battleground , it is important for players to support (in the case of the
attacking team) or work together to destroy (in the case of the defending team) siege weapons
due to their importance to the race challenge ineherent to the victory condition.
• Arena[29] - This is the simplest PvP battle, the objective of which is simply eliminating the other
team. The are three size formats in the Arena: two versus two, three versus three and five versus
five. The small scale of this makes every player an extremely important part of the team, where
losing even a single teammate can put your team at a severe disadvantage. This is the reason
why healing is vital to a team in the Arena in all but smaller format.
Since we are dealing with a computer RPG, there is a logistical challenge to the game in the form of
equipping a character with suitable gear. This is a central piece of the gameplay in most MMORPGs,
and, since most of better gear is obtainable only in high level dungeons (or raids) or through the PvP
system, it is one of the most important incentives that players have to group together. Like many other
MMORPGs, there are professions[32] that players can choose to take, these usually fall within the crafter
or gatherer category. This allows for a form of cooperation to emerge between gatherers and crafters.
By using the game’s auction houses and currency, gatherers can sell the raw materials obtained from
their profession while crafters then buy them and transform them into other items (or gear) that players
can then use.
2.4.2
Lego Star Wars
Lego Star Wars: The Video Game[24] is a platform game that can be played cooperatively with two
players (or alternatively, the second player can be played by a the game’s Artificial Intelligence). The
games consist of essentially two modes - story mode and free play mode. Free play is unlocked after
finishing a level in story mode. While in story mode the objective is simply reaching the end of the level,
in free play mode, players scounder the levels trying to amass lego studs and kit pieces (an economic
challenge). The lego studs are scattered throughout the levels or dropped by enemies and can be used
2.4. GAME ANALYSIS
13
to purchase additional characters, cheats and some fun items. This game uses a class-based design in
order to distinguish its types of characters, and it has six different and useful types of characters:
• Jedi - This type of characters can double jump, allowing them to reach higher places. They can
also use the force on certain items or lego blocks to solve puzzles. They attack enemies at melee
range and deflect blaster shots with their lightsabers;
• Sith - The dark Jedi have the same abilities as normal Jedi, but they can also manipulate certain
objects with the dark force;
• Super Jumper - Characters that are part of this type can jump even higher than Jedi, making them
great for collecting items that seem to be out of reach;
• Grappler - Blaster wielding characters can shoot targets at a distance and also use a grapple on
certain platforms to reach higher places;
• Protocol Droid - This type of character is unable to jump or attack, its main ability is opening and
using certain doors or switches;
• Astromech Droid - Like the Protocol Droid type, these can also open some special doors and
switches and are unable to jump, but additionally they can hover in the air for a certain period of
time. Despite not being able to attack enemies they can stun them for a brief period of time with
their taser.
This game focuses heavily on puzzles, most of them require that the player uses a particular type
or types of character in order to move forward or acquire a kit piece. Other puzzles require players to
use multiple characters to pull levers or press floor plates simultaneously (which is also a coordination
challenge). As expected of a platform game, spatial awareness, coordination and reflex/reaction challenges are present throughout the game and an integral part of the gameplay. This real-time game has
several conflict challenges at a personal scale and allows opportunities to use strategy and tactics to
quickly resolve these. However, the conflict challenges present in this game are quite forgiving. The only
penalty for dying is dropping a part of the studs you have amassed in the current level which you can
then collect before they disappear. Health is plentiful in the game, which makes the related economical
challenge easy and also helps make combat more forgiving.
Playing this game with a second player, not only allows players to progress through the game faster
than by using the game’s AI partner, but it also makes it easier to recover the pieces that are dropped
when a player dies.
2.4.3
Team Fortress 2
The latest installement[13] of the Team Fortress series does not stray too far from the Team Fortress[25]
and Team Fortress Classic[26] - it still is, in its essence, a real time conflict game at a personal level.
However, the game has refined the old Team Fortress game modes and introduced some new ones with
interesting new victory conditions:
• Capture the flag[23] - Team Fortress 2 provides a variant of Capture the Flag (a gameplay mode
where the objective is capturing the enemies’ flag). The objective is being the first team to achieve
a set number of captures (typically three) before the time runs out. The major difference between
this variant and most CTF gameplay modes in other games is that a player can make a capture
while his own flag is not in its starting position;
14
CHAPTER 2. STATE OF THE ART
• Control Point[23] - This gameplay mode is centered around control points (areas of a map that can
be captured by a team). These are captured by having more players than the opposing team on
them over a duration of time. It comes in two variants:
– Traditional Control Point[23] - Maps played in this mode are symmetrical, with both teams
starting with the same number of control points, and an additional uncontrolled one in the
middle. The team that manages to capture all control points wins.
– Attack/Defend[23] - The RED team starts with all control points and must prevent the other
team (BLU) to capture them. The BLU team wins if it can capture all the control points;
• Territorial Control[23] - This gameplay mode is best explained as a campaign of small Traditional
Control maps, where the objective is capturing the opposing team’s home territory. When attacking
a team’s home territory, the gameplay switches to the Attack/Defend mode;
• Payload[23] - The objective of this mode for the BLU team is to escort a cart full of explosives
through a series of checkpoints and into the RED team’s base in a limit of time. The cart is pushed
by having players near it;
• Arena[23] - In this gameplay mode, dead players do not respawn and victory can be achieved
either by wiping out the enemy team, or by capturing a control point in the center of the map that
unlocks after one minute has passed.
When a map ends without any team achieving its objective the game goes into sudden death mode.
In this mode players that are killed will not respawn, while in this mode survival becomes much more
important. This emphasis on survival is also shared by the Arena gameplay mode.
Team Fortress 2 is a class-based FPS game where players have a choice to play as one of nine
classes:
• Scout[22] - The fastest class in the game carries a short range double-barreled shotgun and is
able to double jump. This high mobility makes the Scout perfect for flag carrying on CTF maps. He
also counts as two characters for the purpose of pushing mine carts and capturing locations. This
makes the scout valuable addition to a team in these types of maps;
• Soldier[22] - One of the slower characters in the game, the Soldier has a rocket launcher and high
health. This allows him to take vertical shortcuts by rocket jumping (a techinique that involves
jumping and shooting a rocket into the ground to jump higher) into higher ground. The rocket
launcher is a high damage weapon that makes the soldier an intricate part of a team’s attack. The
rocket’s splash damage and knockback allows the soldier to control areas which makes him well
suited for defense aswell;
• Pyro[22] - The flamethrower yelding character has medium speed and health and is able to use
a compression blast to push rockets and explosives in another direction. The high spread of his
weapon can be used to ignite cloaked or disguised spies. Additionally, he can be quite useful as
an ambush class due to its area of effect weapon;
• Demoman[22] - Another medium speed and health character, this one specialises in explosives
which allows him to setup sticky bombs as traps that can be exploded on demand. This makes
the Demoman perfect for controlling zones both in a team’s offense and defense by adding a trap
challenge to exploration. A typical usage of sticky bombs is protecting either your team’s flag with
it, a capture point or even the cart. His secondary weapon throws grenades, which like the soldier’s
rockets can also be used to control areas.
• Heavy[22] - This class has the highest health and the slowest speed in the game, its weapon is
a minigun. The minigun’s high rate of fire and wide cone allows him to quickly dispose of most
2.4. GAME ANALYSIS
15
enemies, aswell as taking one a large number of enemies. This allows the Heavy to control zones
despite not having an explosive weapon. However, the minigun needs to spin up before firing and
firing it forces the Heavy to move extremely slowly making him an easy target (specially for enemy
snipers). Heavys are one of the medic’s best healing target due to their high health and potential
for damage and it is quite common to see them together;
• Engineer[22] - The Engineer is able to build sentry guns, teleporters and dispensers. These make
the Engineer focus on the logistical aspect of conflect by protecting areas, allowing allies to resupply and help them reach the front lines quicker after respawning. The dispenser can also be used
as trap (it can be exploded on command by the Engineer that built it). Despite being primarly used
in a team’s defense, the engineer can help secure the several resupply zones that exist in maps or
even create one for his team’s offense;
• Medic[22] - Healing other players is this class’ primary ability. He is also able to make himself
and another player invulnerable for a period of time, or boost another player’s damage. While
healing other players he is able to grant them more health than their maximum health, giving them
a bonus of health that slowly fades away if the medic stops healing. The Medic is essentially
a support class, despite being able to stand on his own, he is clearly and important asset in
resupplying teammate’s health (which like the engineer, supports the logistical scale of conflict) in
both offensive and defensive duties;
• Sniper[22] - This low health class is mostly for long range support. The sniper rifle allows him to
kill every class in the game with a single shot as long as it is fully charged. This makes the Sniper
perfect for eliminating high priority targets. However, at close range the sniper is somewhat weak
class. This makes it beneficial to play the sniper stealthly, hiding in hard-to-see areas in order to
avoid getting killed;
• Spy[22] - This class emphasizes stealth over direct conflict by being able to become invisible for
a short time, disguise himself as another class and as a member of the other team. Additionally,
he can disable and destroy engineer’s structures while keeping his disguise and quickly kill enemy
players by backstabing them. This makes the Spy a perfect unit to infiltrate and disrupt the enemy’s
defenses.
The various strength and weakness of characters gives players the possibility of complementing each
other as team in order to achieve victory in a map. An interesting aspect of this game is that the game
itself labels the characters according to three types - Offensive (Scout, Soldier and Pyro), Defensive
(Heavy, Demoman and Engineer) and Support (Spy, Sniper and Medic). However, this labeling does
not mean that the classes are restricted to being played in these types of roles. Offensive classes are
quite often used defensivly, as are Defensive classes used offensivly. The Support classes can used
either offensivly or defensivly, and are able to pull their own weight without requiring the assistance of
teammates. In a sense, Offensive and Defensive classes can support other teammates by providing
cover fire and protecting them from enemies they are unable to attack or spot.
2.4.4
Left 4 Dead
This recent game[12] is a cooperative First Person Shooter set in a zombie apocalypse. The typical
campaign mode[19] allows up to four players (there are four characters that compose a group, when
they are not being controlled by players, the game’s AI takes over) to play cooperatively against hordes
of zombies while trying to escape from zombie infested scenarios. The four human characters’ goal is
16
CHAPTER 2. STATE OF THE ART
to reach a safe house at the end of each level or an escape vehicle in a campaign’s final map. Besides
allowing players to use a melee attack, the game also provides a variety of items and weapons[21] to
assist players in fighting off the zombies:
• A primary weapon - There are two tiers of primary weapons, each tier has a shotgun, and automatic
weapon. The second tier also has a hunting rifle for sniping. Weapon resupplies are spread around
the levels, and players can exchange them freely at these zones;
• Sidearm - Players start with a single pistol, but can also pickup a second one to duel-wield. Pistols
require reloading but have unlimited ammo;
• Ammo - Throughout the levels, players will find stacks of ammo where they can refill their ammo
freely;
• Grenade - The game has two types of grenades (of which a player can only carry one at a time),
a pipebomb and a molotov cocktail. The pipebomb is thrown and attracts zombies to it due to its
beeping sound, while the molotov coktail leaves a field of flame that burns down enemies;
• Health items - Pain pills provide a temporary boost to health, stop you from limping, and can be
handed to teammates in need. First-aid kits restore health permanently to a player, these can be
used either on yourself or teammates. Players can carry one of each of these types of items;
• Area of effect carryables - In the levels you will find gas tanks, oxygen tanks and propane tanks
that you can carry in your hands (thereby making a player unable to use his weapons, but still able
to use the melee attack). These items are useful for game events where players know they will be
attacked by an horde of zombies, due to the effect they have after being shot at (propane tanks
explode, gas tanks leave a wide field of flames around them, while oxygen tanks vent flames for a
briefly before exploding);
• Minigun - In certain areas of a level, players will find a floor mounted minigun to help them hold of
the zombie hordes that will come as part of level event. These miniguns are extremely powerful,
but can only shoot in a 180 degree radius.
An important aspect to consider in this game, is that players on the human team (also known as
Survivors[20]) can become incapacitated and require assistance of a teammate in order to get back to
their feet. Incapacitated Survivors, typically, are able to shoot in order to provide cover for the players
trying to help them get to their feet. This, in addition to the sheer numbers of zombies that attack at
certain points in the game, makes it extremely hard for players to go off by themselves while playing
the game, rewarding cooperative play. At the end of the last map of a campaign, a race challenge
exists, where players are forced to quickly evacuate the level or risk being overrun by massive hordes
of zombies. The map will only end when all live Survivors are inside the evacuation vehicle. It can be
extremely difficult to survive this last bit of a campaign (specially on the harder levels of difficulty) without
players assisting each other.
This game has a second gameplay called Versus[19]. This mode allows a second team to play, one
team takes the role of the Survivors, while the other takes the role of the special zombies (also known
as Infected[18]). The players on the human team need to escape, while the ones on the zombie team
need to prevent them from doing so. The map ends when the human team escapes or when all humans
are killed. The teams are then reversed, making the players replay the map as the opposite team. After
both teams play as both factions, the game calculates the score for both teams and moves on to the
next map in the campaign and this process continues. At the end of the campaign the final scores are
displayed. The zombie team players will shift around between four classes of special zombies, and are
able to choose their spawn position:
2.4. GAME ANALYSIS
17
• Boomer - This type of special zombie can vomit on human players, calling forth a horde of zombies
for each survivor vomited on. Additionally, when killed the boomer explodes and covers nearby
Survivors with bile, achieving the same effect as if the boomer had vomited on them;
• Hunter - A special infected that is capable of wall-jumping and use long-distance jumps to pouce
on top of a survivor (leaving him pinned until his allies kill or use a melee attack to get the Hunter
off him);
• Smoker - This coughing and wheezing infected is capable of using his huge tongue to pull a
survivor towards him (leaving him defenseless, until the tongue is shot at or the smoker killed).
When killed he leaves a cloud of smoke behind obstructing the Survivors’ view.
• Tank - A particularly dangerous special type of infected that is capable of incapacitating Survivors
in a few punches. The tank is also able to withstand quite a lot of damage and throw cars and
debris at Survivors.
One of the most important aspect in playing as infected is coordinating attacks. Any non-tank infected
can be quickly eliminated by a team of Survivors. But, by coordinating attacks with each other (and even
computer spawned hordes of zombies), it is possible to spread enough chaos to make sure that the
players on the Survivor team cannot assist each other.
The game uses an artificial intelligence system for game pacing, dramatics and difficulty called the
Director. Due to the fact that this entity can spawn extra hordes of zombies if the players take too long
in progressing throught the level, there is a certain Race challenge aspect to the game. Exploration
is quite necessary so that players can find ammo, health, or even grenades, particularly in the higher
difficulty settings where they are rarer. This game is a real-time game of conflict at a personal scale
with simple victory conditions (Survivors must get at least a member from point A to point B, while
Infected must prevent them from doing so). However, the other levels of scale are also represented - at
a strategical level, players will typically plan out how to defend themselves against the waves of zombie
horde before a major event in a level; due to its many unknown elements the game has a high emphasis
of the tactical level; the logistical level of conflict is visible in the challenge players face when they choose
which weapon or type of grenade to take, and by allowing them to move certain exploding objects to use
to their advantage. An interesting aspect of this game is that a particular type of enemy the Survivors
face (the witch, a special type of computer controlled Infected) is better off avoided, hence the presence
of a stealth component to the the conflict. This game has economic challenges in the form of sharing and
managing some of the more limited resources - health items and grenades. Additionally, in the harder
gameplay modes, managing ammo becomes quite important, due to its increased scarcity. There are
some exploration challenges present in this game - Survivors face the threat of additional zombies when
they go exploring, and they should stick close together so that they can avoid becoming incapacitated by
themselves (which typically leads to death); Infected, on the other hand, are unable to open doors and
must destroy them (Survivor players typically close doors behind them) in order to reach the Survivors.
2.4.5
Counter-Strike
Counter-Strike[11] is one of the most popular online games where a Counter-Terrorist team faces of
against a Terrorist team for a certain number of rounds on a map. This real-time game is entrenched
with conflict challenges at a personal scale, where tactics and strategy are involved in achieving victory.
It allows a team of players to face off another team of players in a wide variety of scenarios that have
different victory conditions. These depend on both the type of map that you are playing and team in
18
CHAPTER 2. STATE OF THE ART
which you are playing:
• Bomb - In this type of map, the Terrorist’s team objective is planting a bomb and detonating at a
bombsite, while the Counter-Terrorist team’s objective is preventing that from happening within the
time limit. Additionally, either of the teams can win a round by eliminating the other team (as long
as the bomb is not planted), so we also have a survival aspect to this type of maps. Due to the
importance of the bomb (and the bomb holder) it is common for the Terrorist team to escort the
bomb carrier to a bombsite, so that they have a better chance at planting the bomb. While planting
the bomb, a player needs to be stationary, and relies on the protection of teammates. After the
bomb is planted, the Terrorist team needs to prevent the Counter-Terrorist team from defusing it.
This makes the Terrorist team protect the bomb after it has been planted until it is about to explode.
On the other hand, at the beggining of a round, the Counter-Terrorist team will usually protect the
bombsites or even move to attempt to intercept the bomb carrier before reaching a bombsite. If
they succeed in intercepting the bomb, and due to its importance for this type of map’s goals, they
will typically defend it and try to prevent another Terrorist from picking it up. If the bomb is planted,
the Counter-Terrorist team needs to figure in which bombsite it is, and assault it in order to defuse
the bomb. Players that cooperate have the best chance to do so, since, like a player planting a
bomb, a player defusing a bomb is vunerable and can not do anything else. Additionally, bombsites
that have a bomb planted are usually protected by the remaining players of the Terrorist team;
• Assassination - In assassination maps, a random member of the Counter-Terrorist will spawn as
V.I.P. which the rest of the team must escort to a predetermined location in order to win the map.
The Terrorist team needs to simply eliminate this V.I.P. before the time runs out or prevent him from
escaping. As the Bomb type, a team can win by eliminating the other team. The vitality of the V.I.P.
makes it important for the Counter-Terrorist team to escort and protect this player. Terrorist players
can expect to find the V.I.P. heavily protected and will have more success in eliminating him by
coordinating attacks with each other;
• Hostage - The Terrorist team has a certain number of hostages at their starting location. It is the
objective of the Counter-Terrorist team to rescue and escort all live hostages to a rescue point
within the time limit. The Terrorist team must prevent the Counter-Terrorist team from doing so.
Like the other two types, victory is achievable by eliminating the other team. At the beggining of
the round, players on the Terrorist team usually use one or a mixture of the following strategies they will either protect the area where the hostages are located, or move to intercept and possibly
flank the other team’s assault. Due to this, players on the Counter-Terrorist team need to rely on
each other to achieve a successful assault on the hostage’s position. After this, it is beneficial for
the Counter-Terrorist team to escort the player (or players) that are leading the hostages to the
rescue point, so that they can protect them ambushes from players on the Terrorist team.
This game allows players to purchase weapons and items that, due to their differences, allow for
some variance in the type of gameplay players can expect (similar to what happens with a class based
game).
• Sniper rifles allow players to provide long range support at the cost limited mobility (using a sniper
rifle accurately requires being stationary).
• Assault rifles have a high rate of fire and long range, but are less deadly than sniper rifles at long
range, as well as being slightly more innaccurate.
• Submachine guns are middle range weapons with a lower rate of fire and damage than automatic
rifles, but players using them on the move will be more accurate than players using assault rifles.
2.5. WII
19
• Shotguns are better suited for short range (where they deal the most damage) and lose the least
accuracy from moving.
• Pistols are mostly used as a backup weapon, when your weapon is inadequate to the situation you
are facing (e.g. you have no ammo in a clip, your weapon is better at long range and the enemy is
at short range, or your weapon is better at short range and your enemy is at long range).
A certain portion of money is gained automatically at the beggining of each round and additional
ammounts of money can be made by winning rounds or killing enemy players. This leads to an economic challenge where players need to manage their money between rounds so that they are not under
equipped. Players also manage their ammo during a round, and can, if they are running too low on
ammo, drop their weapon and pick up a weapon that is on the ground. Selecting the gear that a player
wants to use is a logistical challenge that is present at the beggining of each round. This logistical
challenge is tied up to the economical challenge ineherent to the game’s currency system. Additionally,
providing a broke teammate with a weapon can be viewed as both a logistical and economical challenge
that promotes cooperation. Due to the fact that the state of play is hidden, this game provides ample
opportunities for the tactical level of conflict. Stealth is intricate part of this game - certain weapons
are stealthier than others and players can choose to walk slowly so that the sound of their footsteps
does not give their position away. Players can also purchase flashbang and smoke grenades to attempt
to blind their enemies or provide cover for teammates. Using these grenades tactically enhances the
stealth aspect of the game by enabling deadlier ambushes on the opposition. Like in most conflict based
games, offensive abilities can be used to support and protect allies reinforcing the cooperative aspect of
the game.
2.5
Wii
The current generation of home video game consoles consists of the Microsoft’s Xbox 360, Sony’s
Playstation 3 and Nintendo’s Wii. This generation has, for the most part, been about graphics and
hi-def content. Both the Playstation 3 and the Xbox 360 were trying to push a norm in hi-def optical
discs (Blu-ray and HD DVD, respectively), and rely heavily on their own graphical prowess in rendering
quasi photo-realistic shots. On the other side of the spectrum there’s the Wii, a games console that
hardware-wise is, at its core, an incremental design over Nintendo’s previous games console - the
GameCube. However, the Wii has managed to surpass both these consoles market-wise due to its
focus on a different interaction paradigm[10]. The Wii (which was codenamed Revolution at its inception)
employs a controller (the Wii Remote) that, despite having traditional gamepad elements, also uses
motion based interaction as a command and control mechanism.
2.5.1
Wii Remote
The Wii Remote’s design is a radical departure from the typical gamepad, resembling a TV remote
controller. However, it still possesses many of the common gamepad inputs - a directional pad; buttons
1 and 2; button A; B trigger button ; home button; plus and minus button; and an off button. Output
wise it has the mandatory rumble feedback feature, a low quality speaker, an external port that allows
connection to several different accessories (the most notable of which is the NunChuk - most games
are controlled with the Wii Remote connected to the NunChuk) and four player LEDs (used to indicate
20
CHAPTER 2. STATE OF THE ART
what player the remote is assigned to). Like so many other controllers it also possesses some internal
memory.
Figure 2.1: The Wii Remote
2.5.2
Nunchuk
The NunChuk is a simple accessory for the Wii Remote that provides a few more inputs - an analog
stick; a Z trigger button; and a button labeled C. The most relevant of these is the analog stick, due to
the fact that it adds one of the most traditional input devices to the Wii Remote, making it an extremely
versatile controller. Like the Wii Remote, the NunChuk accessory has an accelerometer that allows it to
detect motion along three axes (with the same upper limit of 3G).
2.5.3
Wii Remote and the PC
Due to the fact that it uses a Bluetooth connection, several efforts have been made to interface the Wii
Remote with a PC. These efforts can be separated into drivers, APIs and Scripts.
2.5. WII
21
Figure 2.2: The Wii’s Nunchuk accessory
Driver
Several drivers that allow connecting the Wii Remote to a pc are mentioned in the WiiLi webpage[17]:
• DarwiinRemote - an open source driver for Mac Os X, it currently supports the Wii Remote fully,
but it does not allow usage of the NunChuk’s joystick;
• Remote Buddy - a commercial application for Mac Os X that supports several remote controllers,
among them the Wii Remote, the Wii Remote’s functionalities are supported, though NunChuk
support is inexistent;
• WiiinRemote - a Windows Xp driver that supports the Wii Remote and NunChuk;
• GlovePie - an application for Windows that emulates joystick, keyboard and mouse input from a
variety of devices, it basically maps the Wii Remote’s output to the output of one of those devices
through scripting;
• RMX Automation - Windows modular interface for user input and output devices that includes a
plugin for Wii Remote, it appears to works mostly as an input device wrapper (like GlovePie) and
not to support accelerometers;
• WMD - a Wii Remote driver for linux that apparently has turned into vapourware;
APIs
The website (www.WiiLi.org) mentions a decent amount of APIs that support the Wii Remote:
• Libwiiimote - a C based Wii Remote library;
• WiimoteLib - a managed library for the .NET framework, available as a coding tutorial on the web;
• WiimoteCPP - a C++ library for the Wii Remote and NunChuk, it is based on the ManagedWii/WiimoteLib, there has been no source code release yet;
• WiiYourself! - a C++ library that currently supports most of the Wii Remote’s and NunChuk’s
functionalities;
• Wiiuse - a single threaded non-blocking library written in C, supporting both the Wii Remote and
the NunChuk;
22
CHAPTER 2. STATE OF THE ART
• WiiremoteJ - a java API
• WiiJuce - a C++ multiplatform library, it only supports the Wii Remote;
Scripts
Some scripts for interfacing with the Wii Remote are mentioned in the WiiLi webpage[17], these are:
• Wiiewer - a simple python script for plotting a Wii Remote’s motion data;
• Wiimotecom - a small python script that allows connecting a Wii Remote, it appears to have no
functionality besides establishing the connection;
• CWiid - a collection of linux tools written in C that allow interfacing with the Wii Remote;
• Perlwiimote - a perl module that interfaces with libwiimote, providing its functionality;
Comparison between drivers and APIs
In an attempt to shed some light into what each of these drivers and APIs support, four tables are
presented bellow. Scripts have been left out of these tables due to the fact that they possess very limited
functionality and, for the most part, were created with the intent to serve as a proof of concept work.
Table 2.1 is an overview of the software license. Table 2.2 tries to expose the functionalities that pertain
to the Wii Remote directly. Table 2.3 illustrates the state in which the secondary functionalities of the
Wii Remote are implemented in the different software. Table 2.4 summarizes what each of these drivers
and APIs allows in terms of NunChuk usage. When information regarding certain functionalities was
impossible to obtain, the corresponding entry in the tables is ’-’
Table 2.1: Driver and API License Overview
OS
Type
License
Version
Coding
Language
DarwiinRemote
OSX
Driver
BSD
0.6
Objective C
WiiinRemote
WINDOWS
Driver
Open source
2007.1.13
-
Remote Buddy
OSX
Application
Commercial
1.8
-
GlovePie
WINDOWS
Application
Copyright
0.30
-
RMX Automation
WINDOWS
Application
BSD
1.4
C++
Libwiiimote
Linux
API
GPL
0.4
C
WiimoteLib
Windows
API
Ms-PL
1.2.0.0
C#, VB
WiimoteCPP
Windows
API
BSD
release
C++
WiiYourself!
Windows
API
BSD
0.99b
C++
Wiiuse
Multiplatform
API
GPL
0.9
C
WiiremoteJ
Multiplatform
API
-
1.1
Java
WiiJuce
Multiplatform
API
GPL3
0.2
C++
These tables illustrate the fact that driver-wise the Wii Remote is not particularly mature yet. But,
despite this, interfacing the Wii Remote with a computer is already well developed, plenty of API’s have
2.5. WII
23
Table 2.2: Wii Remote Support Overview
Accelerometers
IR
Buttons
Player LEDs
DarwiinRemote
yes
yes
yes
yes
WiiinRemote
yes
yes
yes
yes
Remote Buddy
yes
yes
yes
-
GlovePie
yes
yes
yes
-
RMX Automation
yes
yes
yes
-
Libwiiimote
yes
yes
yes
yes
WiimoteLib
yes
yes
yes
yes
WiimoteCPP
-
-
-
-
WiiYourself!
yes
yes
yes
yes
Wiiuse
yes
yes
yes
-
WiiremoteJ
yes
yes
yes
yes
WiiJuce
yes
yes
yes
yes
Table 2.3: Wii Remote Extra Features Support Overview
Rumble
Speaker
Memory
Battery status
DarwiinRemote
yes
yes
yes
yes
WiiinRemote
yes
-
-
yes
Remote Buddy
-
-
-
-
GlovePie
-
yes
yes
-
RMX Automation
-
-
-
-
Libwiiimote
yes
yes
no
yes
WiimoteLib
yes
-
yes
yes
WiimoteCPP
-
-
-
-
WiiYourself!
yes
yes
yes
-
Wiiuse
-
no
-
-
WiiremoteJ
yes
yes
-
-
WiiJuce
yes
no
no
no
been developed and some of them have most of the important Wii Remote and NunChuk functionalities
implemented. Obviously, for this project, the most relevant APIs are the open source ones. Of these
solutions, it all comes down to a choice between platform and language chosen for development - with
Windows and C# the natural choice falls on WiimoteLib; the WiiYourself! API is an appropriate solution
for C++ development on Windows; despite WiiremoteJ appearing to be a natural choice for Java, but
the lack of a non-proprietary Bluetooth solution in Java makes it unadvisable; Wiiuse is appropriate for
multiplatform development in C; and Libwiimote is adequate for Linux C development.
24
CHAPTER 2. STATE OF THE ART
Table 2.4: NunChuk Support Overview
Accelerometers
Joystick
Buttons
DarwiinRemote
yes
yes
yes
WiiinRemote
-
yes
yes
Remote Buddy
no
no
no
GlovePie
yes
yes
yes
RMX Automation
yes
yes
yes
Libwiiimote
yes
yes
yes
WiimoteLib
yes
yes
yes
WiimoteCPP
-
-
-
WiiYourself!
yes
yes
yes
Wiiuse
yes
yes
yes
WiiremoteJ
yes
yes
yes
WiiJuce
no
no
no
Chapter 3
Conceptual Model
In order to build a cooperative game, we need to understand how the several concepts we have exposed
can be used together to create such a game. This brings us to the conceptual model we elaborated for
this work.
The gameplay definition we approached in the previous chapter, "One or more casually linked series
of challenges in a simulated environment"[9], suggests that gameplay challenges would make up an
important part of a conceptual model for cooperative games. Additionally, since players perform tasks
in order to beat the challenges, it is essencial to understand which types of task have more potential for
cooperation.
Another concept that can be explored successfully to promote cooperation is the usage of high-level
Design Patterns that can either aid the design of a cooperative game, or create additional oportunities
for cooperation.
Figure 3.1: Conceptual Model Overview
3.1
Task potential for cooperation
In this section we explore the potential for cooperation that each of the task types has. This allows us
to use this classification to quickly assess the potential for cooperation of any given task that we can
25
26
CHAPTER 3. CONCEPTUAL MODEL
classify within these types.
3.1.1
Divisibility
The main advantage divisible tasks have over unitary tasks is that they can be divided into smaller pieces
that can easily be assigned to individual members of a group. This allows a Divide an Conquer type of
approach. Unitary tasks, on the other hand, only require a single member of the group to perform it, and
in some cases it can be detrimental to have additional members of a group attempting the same task
simultaneously (imagine that the task requires a single resource to perform, that can only be used by a
single person at a time). However, unitary tasks in which players provide a service to another player, are
an intricate part of cooperative gameplay.
3.1.2
Optimizing
Maximization tasks are well-suited for cooperation, since the focus is on quantity over quality, having
several people to perform it allows for a larger output than what a single person will typically produce.
Optimizing tasks’ focus on quality leads to a different situation, the fact that several members are performing it can raise quality of the work of each member (due to the competitive nature of humans). And,
due to it, the quality of the best solution the group has come up with. It is important to note, that in both
types of task, the Ringelmann effect can appear and will be detrimental, though in optimization tasks it
will cause the most harm.
3.1.3
Combinability
Disjunctive tasks are the least interesting for cooperation in this group, only one member is important
for the outcome of the task, though the process of selecting the member of the group that does the task
can be an interesting group task. The other types are more interesting for cooperation - Additive tasks’
linear sum of the effort of all members helps out weaker members of the group ; Compensatory tasks’
emphasis on averaging the contributions of group members is also supportive of weaker members ;
Conjuctive tasks require that every group member contributes towards the outcome, minimizing the
impact of the Ringelmann effect; Discretionary tasks give groups the freedom to decide how they can
weigh in the contributions of each member allowing for another interesting group choice.
3.2
Challenges used in Cooperative Games
In this section we explore how the challenges defined by Rollings and Adams in [9] are used in current
cooperative game.
3.2. CHALLENGES USED IN COOPERATIVE GAMES
3.2.1
27
Pure Challenges
Physical Challenges.
These can be used to promote cooperative play by making the challenges involve physical effort that
can’t be done by a single player (e.g.: by requiring players to jump in a platform while at the same time
kicking a ball that’s too far away to be kicked by the same player; or by making the effort required to be
too much for one player to handle).
Coordination, Reflex/reaction and Spatial-awareness Challenges.
One of the biggest challenges in cooperative play is the coordination of the members of a team. One
could say that the most obvious display of cooperation is the level of coordination one can see in a
team of players. Coordinating a team of players usually involves several reflex/reaction and coordination
challenges (as long as the game is not turn based) on the part of the individual players as well as some
spatial awareness challenges.
Other types of pure challenges.
Logic and Inference, Lateral-Thinking, Memory, Intelligence, Knowledge-based and Pattern-recognition
Challenges are a subset of pure challenges that appear to have little potential for cooperative play, this
happens mostly due to the fact that these types of challenges are disjunctive tasks. However, adding
extra players to these types of challenges can make the challenges easier. Different players bring
different perspectives which can help in coming up with the correct answer.
Like the previously mentioned challenges, Moral Challenges are not particularly suited to promote
the cooperation between players. This happens due to difference of personalities that exists between
people, and the fact that the choice might cause the crumbling of a group. However, this possible
splintering of the group can make for an interesting gameplay challenge.
3.2.2
Applied Challenges
Race.
This type of challenges usually causes teams of players to focus and work together more tightly due to
the additional pressure. In World of Warcraft, some of the bosses in dungeons have enrage timers, this
means that they will have to be defeated before the time is up or the the boss will enrage and kill the
players. Counter-Strike bomb maps are also a good example of this, if the bomb doesn’t explode before
the time is up (or one of the teams is eliminated) the Counter-Terrorist team wins the round.
Puzzles.
Puzzles can be used to promote cooperation by requiring more than one character in order to solve
it[15]. This can be done either by requiring the effort of more than one character or by needing to
perform actions simultaneously on two separate locations.
28
CHAPTER 3. CONCEPTUAL MODEL
Lego Star Wars uses the later type quite often, dual switches that open doors need to be pulled
simultaneously.
Exploration.
In games of imperfect information where players can cover different areas, exploration becomes an
important asset to a team of players (e.g. : due to the presence of fog of war in RTS1 games, it is
important that teams of players cooperate in order to search for the enemy bases and scout the enemies
defenses, and so that they can spot incoming enemies; in FPS games, it is important to know where the
enemy is so that you don’t get ambushed). In other cases, it is required that the players cooperate so
that they can progress to other areas.
1. Opening Locked Doors - Locked areas can be suitable to cooperative gameplay. These can be
used either in situations where a particular type of character is needed to unlock the area or it can
be opened by using simultaneous switches that require cooperation between players.
Lego Star Wars is a good example of all these situations. Some doors need that several characters
stand on floor plates in order to open them. Others require simultaneous switches, while others
require that a particular type of character opens the door.
2. Trap - They are a commonly used obstacle for defending important locations. Additionally, traps
can force players to cooperate by requiring them to work together in order to disable them, or even
forcing them to thread carefully while exploring an area, sometimes cooperation emerges from
setting off a trap on purpose as a distraction, or even by a player sacrificing himself so that the rest
of the team can pass.
As an example, consider World of Warcraft - a class exists that can set traps, and another class
exists that can spot them and disable them. It is common for players of the second class to
cooperate carefully with their team so that the traps are disabled when the team decides to enter
the room. While the the other class will typically place them to protect important locations.
3. Platforms - Some platforming challenges can be used with complementary abilities so that the
progress of group depends on the cooperation of the elements of the group. In certain games,
particularly in FPS (First Person Shooters), it is common for players to piggy back on top of each
other to reach higher areas.
In Dust (a Counter-Strike bomb map) it is common for terrorist players to piggyback on top of each
other so that they can plant the bomb in a harder to reach location.
Conflict.
This type of challenge relates to games that are won by attacking the opposition directly.
1. Protect - One way that conflict-type challenges have been successfully applied to force players to
cooperate together is by making players defend either a location, a character or even an item. This
usually causes the players to work together as a team instead of trying to be the "hero of the day".
2. Escorts - Another gameplay archetype that is used to force cooperation through conflict are escorts. These usually involve a team of players escorting another character across from one place
1 Real
Time Strategy
3.2. CHALLENGES USED IN COOPERATIVE GAMES
29
to another. Typically the character being escorted is defenseless, but it is not uncommon for escorts to involve accompanying a powerful ally to a location so that it can turn the tides of battle.
Another common escort involves escorting an important item from location A to location B, typically these items are important to the victory conditions of the game, or they can just grant powerful
bonuses to the team that manages to escort them. The Escort archetype can be viewed as an
implementation of the Protect archetype due to the fact that you are protecting another character
or a movable item. However, due to the fact that you are protecting a moving thing, that is moving
towards a goal, there is one important nuance from the typical Protect archetype - the defense
needs to be able to adjust to the movement of the thing being escorted.
An example of this are the assassination maps in the popular online FPS Counter-strike. In these
maps the Counter-Terrorist team will win a round if the VIP can reach an extraction point in the
map.
3. Capture - Sometimes games try to force players to work cooperatively by giving them the objective
to capture something - it can be an item, a location, sometimes even a character. In fact if one
looks at most of the Escort challenges, it is easy to see how it actually has a Capture element to it you complete the Escort when you successfully deliver the thing being protected to its destination.
Several subtypes of capture exist each with its own particularity.
(a) Capture The Flag - This mode of play is present in many online games, and it causes players
to work together by making them protect their flag (or a similar item), while attempting to capture the enemies’ flag. It is in fact a combination of archetypes, namely the Protect archetype
and the Escort archetype - a team needs to protect its flag and needs to escort the player that
has grabbed the opposing team’s flag until he reaches the capture point.
Many examples of this archetype exist in a variety of game genres - FPS, RTS (Starcraft2 )
and MMORPG (World of Warcraft) games all have multiplayer CTF3 modes. The popularity of
CTF dates back to the original Quake and the CTF modification made by Threewave4 , after
this modification CTF became an integral part of most FPS.
(b) Capture Locations - Another common conflict challenge revolves around capturing and protecting locations from being captured. Normally these two modes are mixed together, with
both teams being able to capture each other’s locations, while in other situations a team defends while the other team attempts to get control of the location. Like some of the other
archetypes listed before this archetype is a particular case of the protect archetype.
Examples exist in several game types - Team Fortress 2 has several gametypes that revolve
around the Capture Locations archetype; and the Arathi Basin Battleground for WoW.
4. Bomb - Some games have a mode where the objective is to plant a bomb at one of several locations
(only one of the players carries the bomb from the starting location to the bomb sites) and then
defend it from enemies. This is in reality a combination of two of the archetypes discussed above.
During the first part it falls clearly within the Escort archetype, while the second part deals directly
with the Protect archetype. A characteristic of this mode is that while one team fights to explode
a location the other fights to protect the locations (this overlaps a bit with the Capture Locations
archetype). Due to the fact that the bomb is a resource that is needed in order to achieve the
goal, if the team defending the bomb sites manages to kill the bomb carrier, it is common that they
defend the bomb so that they can starve the terrorist team of an important resource.
2 Starcraft
official website: http://www.blizzard.com/us/starcraft/
The Flag
4 Threewave official website: http://www.threewavesoftware.com/multiplayergames.html
3 Capture
30
CHAPTER 3. CONCEPTUAL MODEL
The best and most known example of this archetype comes from Counter-Strike, though examples
of other games that use this archetype exist (Urban Terror for example).
5. Tougher Conflict Challenges - A typical attempt to make players cooperate with each other is by
posing tougher challenges than those that they can handle by themselves. By making sure the
challenge is practically impossible to be accomplished by a single player, you are effectively giving
them a strong incentive to group together so that they can overcome it.
In MMORPGs, it is common for some enemies to be a lot more powerful and tougher than the rest
of the enemies. These enemies are practically impossible to kill by yourself, and force players to
create or join a group to defeat them.
Economics.
A team of players must work together quite closely in order to manage their resources, and allocate
resources to where they are needed.
While in most games the goal is not amassing resources, they are nonetheless an important aspect
of gameplay. In FPS games, teams try to protect and adequately manage most powerups, weapons and
armors, since they are vital resources that can decide the outcome of the conflict. RTS games since
their inception have been tied up with resource collection, and rely on it so that they can produce units.
This causes any cooperative play of RTS games to be extremely dependent on the management and
protection of resources.
3.3
Design Patterns for Cooperative games
An important result of our game analysis, was a list of Design Patterns that helped promote cooperative
behaviors in games.
3.3.1
Complementarity
• Name - Complementarity
• Description - One of the most commonly used design patterns in cooperative games is making sure
that there is some complementarity between the characters that players control. It is commonly
found in games that have player character classes, though it is also present in some games where
players have a simple choice of weapon or race. This can easily be implemented without the classbased design, simply by using a power-up or weapon like system. Most MMORPGs tend to use
this pattern, as well as some of the most sophisticated First Person Shooters (FPS) and Real Time
Strategy (RTS) games.
Examples - Team Fortress (class-based design in an FPS game), Warcraft 3 (the factions each
have their own strong points), Counter-Strike (uses a weapon-based system), Quake 3 (uses a
more typical weapon system than Counter-Strike, where the weapons are picked up in the map),
City of Heroes and World of Warcraft (both are MMORPGs that use a class based design).
• Consequences - This usually leads to several consequences, one is that characters tend to settle
better in one type of role, another is that even when you have two different character types for the
same role, they will usually be complementary to one another, as they will have different abilities
3.3. DESIGN PATTERNS FOR COOPERATIVE GAMES
31
that will complement each other in that role. A common problem that occurs when using this
pattern lies with trying to achieve balance in an heterogeneous environment, which is both time
consuming and hard.
• Using the pattern - A typical choice that shows up when using this pattern, is determining how
the complementarity will be implemented. How should the ability system be implemented? Do we
want players to be able to change abilities mid game? Does a weapon-like system, where players
drop and pickup new abilities work best for what we are trying to achieve? Or should we settle with
a more typical class-based design, where players’ abilities choices are made at the begining of the
game?
• Relations - This pattern is used often in conjuction with both the "‘Abilities that can only be used
on another player" and the "‘Synergies between abilities" patterns.
3.3.2
Synergies between abilities
• Name - Synergies between abilities
• Description - Another design pattern that is commonly used, is by creating some abilities that yield
better results when used together than they do when they are used independently. This effectivly
causes a high level of synergy between these abilities. These abilities should typically be scattered
accross multiple players in order to promote cooperation.
Examples - World of Warcraft (a shadow priest (who deals mostly shadow damage) can cause an
enemy to become more vulnerable to shadow damage, which also causes an increase of damage
that the warlocks are causing (who also deal shadow damage), Battlefield 1942 (Scouts can use
their binoculars to give out targets for players controlling artillery’s), Team Fortress 2 (one of the
medic’s healing weapons can also increase another player’s damage for a limited time).
• Consequences - The most important consequence of this pattern is that it gives players a strong
incentive to group together with players that have a high level of synergy with them.
• Using the pattern - It is important to take some care to ensure that the abilities are not considered
lackluster when used without the ability that increases it’s power, players do not like being too
dependant on other players.
• Relations - Like stated in the pattern above, this pattern is often used together with the "‘Complementarity" and the "‘Support abilities" patterns.
3.3.3
Support Abilities
• Name - Support abilities
• Description - Sometimes games provide players with abilities that can only be used on another
player. This is partly because the purpose of these abilities is to encourage cooperation between
players.
Examples - Team Fortress 2 (Medics have a weapon that allows them to heal other players), Left 4
Dead (players after taking a certain amount of damage fall down to the ground and require another
player to help them get up), World of Warcraft (healers in raids tend to take a support role, healing
other players so that the group can progress).
• Consequences - An important aspect to consider, is not to overdo this type of abilities to the point
where a player is essencially only supporting other players. Despite the fact that some of the
32
CHAPTER 3. CONCEPTUAL MODEL
players find this rewarding, most players like to be able to pull their own weight, and not depend
completely on their teammates.
• Using the pattern - The main questions that this pattern’s usage poses relate to the level of support
required by the game and the level of dependance we want players to have on each other. This
aspects must be carefully weighed in due to most players not appreciating a pure support role.
• Relations - This pattern can be viewed as a particular case of the "‘Synergies between abilities"
where a player’s ability is potenciating another player’s abilities. Though, as was stated before they
often occur together, and it was important to make the distintion. The presence of this pattern is
also often accompanied by the usage of the "‘Complementarity" pattern.
3.3.4
Shared Goals
• Name - Shared Goals.
• Description - Most games tend to use up a simple design pattern in order to force players to work
together, a group of players will have one non-exclusive goal, that can be completed in a group. In
team based games this pattern is a natural choice due to the necessity of implementing a clear victory condition for a team players. However, in some open-ended game genres (like the MMORPG
genre) this pattern becomes less important (due to players defining their own goals by choosing
what quests they perform). Team FPS (Counter-Strike, Team Fortress 2) have shared goals across
a team of players, the success of a team depends on whether the team can accomplish a certain
goal. In World of Warcraft, groups are often formed because players happen to have the same
quests.
• Consequences - For team based games, the main consequence is that it gives players a clear common goal for them to work towards, and therefore focuses players on what is important to achieve
success in the game. When applied to open-ended games properly, it gives players incentive to
group together so that they can progress more quickly through the game.
• Using the pattern - In team based games, this pattern is an obvious choice in design and, typically,
the foundation on top of which the entire basis of teamplay is formed - a team needs to work
together to achieve its shared goal. In open-ended games, where players (and group of players)
can choose their own objectives, it becomes less of an obvious choice, but using it typically allows
players to achieve their goals faster. However, this requires some consideration of the nature of
the goals and how they are accomplished - Is the shared goal a competitive one (will the players
be effectivly competing to achieve the shared goal, despite working together towards it)? What
design changes can we make to the goal to better support cooperative behaviour? Will grouping
in order to achieve the goal help players achieve the goal faster than they would by themselves?
• Relations - This pattern is related to the pattern "‘Synergies between goals".
3.3.5
Synergies between goals
• Name - Synergies between goals (Interlaced/Intertwined goals).
• Description - When players have different goals, one of the design approaches used to force them
cooperate together is to have some sort of synergy between their goals. A recent example of
this is the way Valve has setup their achievement system with the Pyro and Medic classes in
Team Fortress 2. One of the Pyro’s achievement is killing three enemies while ubercharged (being
made invulnerable by a Medic), while the Medic has an achievement that requires the Medic to
3.3. DESIGN PATTERNS FOR COOPERATIVE GAMES
33
ubercharge a Pyro while the Pyro burns five enemies. In World of Warcraft, it is quite common for
players’s quests to have different goals. One player might require killing a creature, while the other
requires getting an item that drops from said creature.
• Consequences - This pattern promotes cooperation by allowing players with different goals to work
together.
• Using the pattern - This pattern is best suited to be used in games where players have some
freedom when choosing their goals (MMORPGs with their quest systems are usually good candidates, as are some of the more recent games that use achievment systems). Despite some
emergent synergies between goals in open-ended games, implementing this pattern in a game
requires some care when designing it so that we can ensure the existence of the synergies.
• Relations - This pattern is related with the patttern "‘Shared Goals".
3.3.6
Special Rules for Players of the same Team
• Name - Special Rules for Players of the same Team.
• Description - Some games have special rules for players of the same team - an action will have
a different effect when done on a friendly player. The idea behind these differences is to promote
and facilitate cooperation. A good example of this are the special rules for shooting members of
your own team in FPS games (also known as Friendly Fire modes). Another common example are
special rules for movement that involves friendly units.
• Consequences - The consequences of this pattern depend on the particular type of special rule
being used. One of the main advantages of friendly fire modes is that it allows to choose the
degree of control that is required by players. On the most punishing setting for friendly fire modes
(full damage to team members), the advantage of using it is that it incentivates tactical discipline
and self control on the part of the players, but it also leaves players a bit frustrated when they
take team damage. While, on the most forgiving setting (no damage to team members), it has the
advantage of not penalizing players for trying to aid each other, but the tactical discipline that is
encouraged by having the possibility of killing your allies (accidently or not) is lost, causing many
players to become trigger happy. The advantage of treating movement involving friendly units
differently than you treat movement involving enemy units is that it allows teammates to move
without worries of blocking each other’s path. The obvious disadvantage is that it comes at the
cost of realism (or credibility) to the game. Certain games have adressed this is by having soft
collisions between friendly units - trying to go over a friendly unit will nudge the friendly unit softly
to the side. Another disadvantage is that it limits the potential (in FPS) for players to piggy back
and reach other areas. This last aspect can also be viewed as an advatange due to the fact that
the most common use for this technique is to exploit map areas.
• Using the pattern - By deciding to use this pattern, the first thoughts that game designers should
have are - Which special rules make sense in the game? Will they interfere with players’ expectations? Will they oversimplify the game and make team coordination non existant? One of the most
important choices in using friendly fire modescomes down to the level of Friendly Fire that should
be used. Should players damage each other just as strongly as they would damage an enemy?
Or should the damage be minimal or even non existant? The main concern with special movement
rules is deciding how facilitated do we want team movement to be - Should friendly players be
transposable as if they were not there? Or should there be a soft colision where no player takes
exactly the path they expected, but does not feel like they hit a brick wall?
34
CHAPTER 3. CONCEPTUAL MODEL
• Relations - This pattern is not related to the other patterns mentioned and can be used freely with
them.
3.3.7
Mechanisms for sharing
• Name - Mechanisms for sharing
• Description - In games where players pick up resources and can store them for later use, cooperation can greatly benefit if players are allowed to trade these resources between them.
Examples - Left 4 Dead (players can give each other pain pills), Team Fortress (players were
allowed to discard the extra ammo they did not use in order to share it with other teammates),
Warcraft 3 (players of the same team can transfer resources between one and another). Map
information is shared automatically in Warcraft 3 between players of the same team.
• Consequences - This pattern actively promotes cooperation by giving players the chance to allocate resources to where they are most needed and would be better used.
• Using the pattern - Which resources should be shareable? Should there be a maximum ammount
players can share? How should this limit be implemented, by a maximum on each time they share,
or by limiting the ammount of times that players can share resources? Should players only be
allowed to share resources at certain times in the game? Which resources should be shareable?
Which would cause gameplay imbalances?
• Relations - This pattern is related with "‘Support Abilities" due to the fact that giving a teammate
resources is, in its essence a support abilty.
Chapter 4
Geometry Friends
In order to explore some of the patterns and challenges we identified as being supportive to a cooperative gameplay experience, we developed a simple two player cooperative game that uses physics based
puzzles where players work together to overcome the challenges in the least ammount of time possible.
Figure 4.1: Initial sketch of a level
Figure 4.2: Actions of the Ball character
4.1
Figure 4.3: Actions of the Square character
Main Characteristics
• Cooperation - The two characters in the game (a green square and yellow ball) have different and
complementary abilities that allows for a unique gameplay experience. Each player controls only
one of the characters, and, due to the design of the levels, it is important that players cooperate in
order to overcome the different obstacles.
• Wii Remote - The control of each character is done using the Wii Remote (and in the case of the
35
36
CHAPTER 4. GEOMETRY FRIENDS
square character, also the nunchuk acessory). This allows us to use Gesture Recognition by interfacing with the Wii Remote’s accelerometer capabilties and provides a diferent game experience.
• Physics Based Gameplay - The game explores physics concepts (mass, gravity, attrition, etc) as a
way to create a different experience than that which is typically found in 2D platforming games.
• Simple and Minimalistic Graphics - The graphical design of the game is based on simple geometrical figures as can be observed in the first sketch of the game concept.
4.2
Overview
In this section we expose our high concept for Geometry Friends.
4.2.1
Player Motivation.
Players form a partnership with each other and, through mutual cooperation, try to complete each level
as fast as they can. In order to complete a level it is required to collect all the losangles in it. The
levels are varied in their design and require that the players use, not only their dexterity at controlling the
characters, but also logical thinking.
4.2.2
Game Genre.
2D Platforming game.
4.2.3
Target Customer.
The target for this game are essentially Casual Gamers (gamers that have little game literacy and proficiency, play a small ammount of games with the intent of relaxing and killing time) that are searching for
an acessible game that is possible to play for short periods of time. According to the Demographic Game
Design 1 Model [1], the game should be attractive to players that fit the Participant profile (gamers that
focus on the social aspect of gaming and favor cooperation over competition), due to the incentive that
the game provides to a strong social and cooperative interaction.
4.2.4
Target Platforms.
Pc and the Wii Console.
4.2.5
Design Objectives.
• Intuitive Control - The character control should be intuitive and use the Wii Remote.
• Cooperation is the key - It should be impossible to solve any level using only one character.
• Low Learning Curve - A player should be able to learn easily how to control his character. It also
should be easy for a player to understand how a particular gameplay element works in a level.
4.3. DESIGNING GEOMETRY FRIENDS
37
• Character Balance - In this game of heterogenous characters, the characters should be equally
interesting to play.
4.3
4.3.1
Designing Geometry Friends
Patterns Used
We developed Geometry Friends with the Complementarity design pattern in mind. We ended up settling
on two very simple and basic characters - a green square and a yellow ball. As such, we came up with
abilities that made sense from the perspective of our simple geometrical characters, the ball character
can jump and change size (increasing its weight), while the square character can deform itself into
rectangles allowing it to become taller (which helps it reach higher places) or shorter (which helps it
reach narrower places). Another interesting gameplay idea that we came up with, was making the ball
and square collide with parts of level that had the same color as the character in question.
The fact that this design is based around complementarity also helped us establish interesting synergies between the abilities. The fact that the square can stretch to become taller, allows the ball to
use it to reach a higher place than that which either could reach naturally, whereas the fact that the ball
changes weight and size allowed players to use the ball to propel the square up into the air.
One of the most natural design patterns to use on a cooperative game is giving the players a shared
goal that is accomplished by the combined efforts of the group and not by a single character. As such
we gave players a simple goal of collecting all the purple diamonds in the level in order to progress to
the next level. Naturally, the placement of the diamonds on the levels was such that forced players to
cooperate in order to get them. This was achieved mainly by making sure that each of the characters by
itself could not pickup each and every diamond of the level, and also by making sure that the individual
efforts of the characters would not add up to collecting all the diamonds, effectively avoiding a design
that allowed a level to be completed by using a Divide and Conquer approach.
4.3.2
Challenges used
In Geometry Friends, due to the type of game that we had set out to create (a two player co-located
cooperative puzzle and platform game), we focused on mainly the natural type of challenges for this
type of game - Coordination, Reflex/reaction and Spatial-awareness Challenges. These were a natural
choice due to the fact that they are intrinsic to the game type that we developed. This was not the only
reason for this choice, as these challenges are also an interesting choice for cooperative games, due to
the fact that failing these types of challenges results in non-cooperation.
4.3.3
Tasks used
Most of the tasks present in the game are conjuctive tasks, because these require effort from both of the
players so that they can beat the challenge.
38
CHAPTER 4. GEOMETRY FRIENDS
4.4
Technological Solutions
So that we could implement our game concept we had to choose tecnhological solutions that would
facilitate the development. As susch, we decided to search for 2D game engine, a 2D physics engine
and an API that would support the Wiimote and allowed integration with a gestural recognizer created
with Wiigle. We ultimately decided to utilize XNA, Farseer and WiimoteLib.
4.4.1
XNA
XNA is a framework for games created by Microsoft. It allows the development of games for both the
PC and Xbox 360. This framework automatically generates a typical game cycle skeleton and supplies
classes that deal with low level tasks (input, graphics and sound), which are always necessary in the
devlopment of a game. The coding language used by XNA is C#.
The main advantages we saw in XNA were:
• XNA has a very active developer community of developers, who besides participating in forums
also supply some source code for their games.
• Several online tutorials were available.
• XNA uses a coding language we were already familiar with.
Alternatives
Due to the fact that game concept focused on 2D we discarded quite a few 3D centric options, leaving
us with only a few alternatives.
Gamemaker is a graphical tool for the development of 2D games. The biggest hurdle that we found
in using this tool was the difficulty that we would have integrating this tool with the other technological
solutions. This was due to Gamemaker using its own scripting language - GML.
Torque X Engine is a game engine that is integrated with XNA. We decided not to use it, mostly due
to not forseeing any benefit for the game that we intended to develop. Additionally, most of the reviews
we read about it were quite negative.
Torque X Builder is a graphical tool that allows the creation of assets - animations, sprites and levels.
We considered using it to make the level design process easier, but ultimately it became unnecessary.
4.4.2
Farseer
Our need to find a 2D physics engine that could be easily integrated with XNA led us to Farseer. Farseer
is a 2D physics engine for Silverlight and XNA that is based on Box2D - a popular choice among 2D
physics drivers.
The main advantages we saw in using Farseer were:
• Farseer was developed specifically for XNA, which makes the integration process easier.
• The demo and source code contained with the engine ilustrated its potential quite well, and were
also the inspiration for some of our gameplay ideas.
4.4. TECHNOLOGICAL SOLUTIONS
39
• Support for this engine was easily found in internet forums.
Alternatives
We came upon a couple of alternatives to Farseer, but ended up chosing the latter.
ChipmunkXNA and Box2D were two promising alternatives to Farseer. They both used C# and were
developed for XNA, but, at the time we had to make our choice, they were in an early and experimental
stage of development (one of them only had a project page created, and had no public release yet).
Physics2D.Net was another C# alternative, but we chose to use Farseer due to its particular focus on
XNA. The demos supplied by Farseer also seemed richer than the ones supplied by this engine, which
made us think that Farseer would be a more adequate choice.
4.4.3
WiimoteLib
As soon as it became apparent that our technological solutions would end up being C# based, the
WiimoteLib API became the natural choice, due to it being the only API we knew that used C#.
However, besides using C#, there were also some other positive aspects that made us choose this
API:
• It was one of the first APIs to be developed for interfacing a PC with the Wiimote, it is widely used
(it is even used by the gestural recognizer creation tool we were exploring) and its usage was well
documented.
• Quite a few of the other APIs were based on this API.
• It is a pretty mature and complete API - it implements most of the Wiimote’s functionality (at the
time the only things it did not implement were access to both the in-built speaker and the memory).
Alternatives
There were plenty of alternatives to this API, some of them even implemented more of the Wiimote’s
functionality. However, since WiimoteLib was the C# solution that offered the most functionality and due
to our choice of a C# framework, we ended up discarding the alternatives in favor of WiimoteLib.
4.4.4
Wiigle
Wiigle[8] is a gestural recognizer creation tool. It uses the Wiimote to saved gesture examples which
are then used to train statistical classifiers. This tool supports a wide variety of classifiers and allows
users to choose which features they want to use for classification, but it had two significant problems
that prevented its use in Geometry Friends. The trained recognizers could not be saved and it required
using a socket interface between our game and the Wiigle application.
40
CHAPTER 4. GEOMETRY FRIENDS
Alternatives
We had no viable alternative to using it. Our only other options were implementing a simple gesture
recognizer or creating a similar tool from the ground up (which was not viable).
4.5
4.5.1
Development Process
First Prototype
Conception of the first prototype took us five weeks, it included three levels, the implementation of the
characters’ abilities and a high score mechanism.
Figure 4.4: Level 1 of the first
Figure 4.5: Level 2 of the first
Figure 4.6: Level 3 of the first
prototype.
prototype.
prototype.
Development of the First Prototype
The first goal we outlined when developing this prototype was to integrate all the technologies we intended to use - XNA, Farseer, WiimoteLib and Wiigle. This integration was accomplished completely,
with the exception of the integration of Wiigle, in one week by being able to control the Farseer demos
with the Wii Remote.
Having accomplished the integration, our second goal was to develop the characters and implement
their actions. Implementing the movement of the characters was easy due to the Newtonian force system
that Farseer provided. However, as we were attempting to implement the grow/shrink actions of the ball
and the deformation actions of the square, we came accross a problem - the Farseer physics API did
not support deformable geometries. Since we were at an early stage of development, we pondered
changing our physics API and made some attempts to find a suitable replacement. We did not find
a replacement that offered the benefits of Farseer, and, as such, we ended up working around the
problem using Farseer - in order to deform a geometry, we replaced it with an altered geometry using
small increments, untill we reached the intended geometry. This solution proved to be satisfactory, but
had some minor inconvenients - it considerably increased the CPU requirements and caused ocasional
failures in the colision detection algorithms.
Our initial approach to the movement of the ball was reconsidered after some testing - we originally
made the ball move as if a force had been applied to it, but in keeping with the ball metaphor, we
decided to make it move with a rotation. This had the side effect of making it impossible to change the
ball’s momentum mid-air, as is possible in most platform games (though irrealistic). With this in mind,
4.5. DEVELOPMENT PROCESS
41
we still decided to keep the rotation movement, so that players could be challenged conceptually and
search for alternative solutions to the puzzles present in the game.
In order to integrate XNA and Farseer with the WiimoteLib we created input classes similar to the
ones that XNA uses for the Xbox 360 controllers and the keyboard. Even though this process was easy
and fast, we encountered a problem - the current version of WiimoteLibe (at the time) did not support
multiple Wii Remotes. The solution to this involved changes to the API’s code, which was only possible
due to it being an open source project. After some research, we managed to modify the API and the
test application that came with the API so that we could test the support for multiple Wii Remotes. We
then changed the input classes we had created to support connecting to multiple Wii Remotes.
Integrating the result with Wiigle, proved to be more difficult - the only interface mechanism that
this application had was a socket mechanism, and there was no mechanism that supported saving and
loading a previously trained recognizer. Even though we succeeded in integrating this technology, it was
extremely bugged - a jump gesture would make the ball fly up into the air (this was due to the impulse
we were applying being applied perpetually on the ball).
This fact made us settle with simple button controls for some of the actions - the player controlling
the ball could simply tilt the remote to the sides to make it move, push button A to make it jump, and
button 1 and 2 to make it grow and shrink; the square was controlled by using the joystick present on the
Nunchuk, while its deformation was controlled by pushing the B button and doing some simple gestures
at the same time (raising the Wii Remote to make it stretch up, lowering the Nunchuk to make it squat
down, tilting the Wii Remote to the right in order to stretch it towards the right, and tilting the Nunchuk
towards the left to make it stretch to the left).
In the last stage of this development, we attempted to correct some of the existing bugs and created
three different levels The first level was inspired by our original sketch. The second level has a special
white platform that is connected by a spring, this requires that the player controlling the ball grows in
order to access the lower part of the level. In the third level, we introduced a special green platform that
only colides with the square. All these simple gameplay elements were easy to introduce due to the
potential offered by Farseer. However, it became apparent that a level editor would simplify the process
of defining the size and positions of the levels’ objects instead of doing it by trial and error.
User Feedback
The feedback we gathered over the course of development (in informal testing sessions with 3 to 5
users over the course of development) was quite positive, but some parts still required work. One of the
main complaints we received was that the characters were too difficult to control properly with the Wii
controllers. In the case of the square character, the complaint was that the deformations were extremely
difficult to make due to control scheme we had decided on (there were four ways in which the square
could be deformed, and they required that players manipulated both the Wii Remote and the Nunchuk
at the same time). While, in the case of the ball, people had difficulties with the timing of the jumps,
or tilted the remote too much when trying to make the ball move. After this feedback, we decided to
adjust the tolerance values for the verifications that detected the controllers’ orientation, and change the
control scheme of the square. Another useful bit of feedback gathered was making the game use the
least ammount of buttons posible, and relying almost exclusively on the Wii Remote’s and Nunchuk’s
accelerometers for controlling the game.
42
CHAPTER 4. GEOMETRY FRIENDS
In terms of level design, people liked the third level the most. This was, possibly, due to it being a
more open level, where lack of precision with the controls was not as penalizing as in the other levels.
A suggestion that our users made was to use this level as the first due to it seeming simpler than the
other ones, or creating an extremely simple first level to give players a chance at getting the hang of
the controls (a tutorial level). Another important piece of feedback was that in the levels we had, the
square’s role was not as interesting as the ball’s. Most of the users thought that this was caused by
level design making the ball take a more active role in collecting the losangles, while the square had a
passive support type of role.
4.5.2
Second Prototype
We had two weeks to develop the second prototype. This prototype was composed of six levels.
Figure 4.7: Level 1 of the sec-
Figure 4.8: Level 2 of the sec-
Figure 4.9: Level 3 of the sec-
ond prototype.
ond prototype.
ond prototype.
Figure 4.10: Level 4 of the sec-
Figure 4.11: Level 5 of the sec-
Figure 4.12: Level 6 of the sec-
ond prototype.
ond prototype.
ond prototype.
Development of the Second Prototype
One of our main goals for the second prototype’s control scheme was attempting to solve the problems
we had encountered when we attempted to use Wiigle for gestural recognition. As such, we attempted
to implement a save/load mechanism in Wiigle. Even though the initial results were promising, when
we attempted load a previously saved recognizer, we encountered a bug that was too tricky to solve
in a short ammount of time. This was due to the technologies that Wiigle used - this application is
a C# application that uses a virtual machine solution for running java code which causes any sort of
debugging to be practically impossible.
We then decided on a simpler implementation for the gesture recognition. So that we could recognize
an upwards gesture with the Wii Remote, we saved an array with some acceleration vectors from the Wii
Remote. If the diference between the minimum and maximum in the Y axis was over a predetermined
value, we interpretered that as a gesture that corresponded with the ball’s jump action.
4.5. DEVELOPMENT PROCESS
43
We also made some other adjustments to the control scheme - the ball’s growth was modified to
be controlled by a single button (when pressed the ball grew to the maximum size, when released it
decreased to its minimum size; the square’s control scheme was simplified, tilting the Nunchuk sideways
made the square move in that direction, while pointing the Wii Remote up made it stretch up and pointing
it down made it deform downwards.
As a result of our problems caused by the lack of a level editor, we decided to fill the gap by specifying
the level’s contents through an XML file. This file had information regarding all the objects that made part
of a level, including their positions. This solution was implemented quickly, and proved to be extremely
important in the implementation of new levels. The level design was also eased by using image editing
software to determine the positions in which we wished to place the objects.
44
CHAPTER 4. GEOMETRY FRIENDS
Chapter 5
Evaluation
Two sessions of formal evaluation were made so that we could evaluate the game - a session during the
MoJo game showcase and a final evaluation using the Gameflow’s criteria for player enjoymenet[16].
5.1
Mojo Evaluation
The second prototype was formally evaluated during MoJo (a game showcase for games developed in
a game technology course in IST Taguspark). For this purpose, we created a questionaire which would
permit us to evaluate and identify problems that existed in either the gameplay or the game controls.
Another important evaluation tool was observing the users as they played, this allowed us to better
understand some of the problems that other players had already verbalized after testing the game.
Most of focus of the questionnaire was trying to understand if players felt that cooperation was the
main focus of the game and vital to complete each level, if any of the players felt they weren’t vital to
task at hand. This last question came up during our own internal testing - at a certain point during the
development we felt that the square was a support character for the ball and not interesting enough by
itself. We also tried to understand if the players felt that levels we designed were fun, and if the difficulty
of the level was adequate.
5.1.1
Tester’s Characteristics
Table 5.1 presents some characteristics of the participants of the study. As the table shows, most of
our test subjects were male and played games often, this is undoubtly a side-effect of conducting these
evaluations during a Video Game showing in a predominantly male University. Most of the users had
not played our game before which made them perfect to assess the difficulty curve of the game.
The following table (Table 5.2) shows us that most of our users had limited experience with the Wii.
Having players that had limited experience with the Wii allows us to better assess wether or not our
control scheme for our characters are too hard for novice players.
45
46
CHAPTER 5. EVALUATION
Table 5.1: Sample Characteristics
Sex
Video Game Habits
Played this game before
Male
Female
Never
Rarely
Ocasionaly
Frequently
Yes
No
16
0
0
0
6
10
3
13
Table 5.2: Experience with the Wii
None
7
5.1.2
Some
Reasonable
Plenty
2
3
4
Results
Table 5.3 presents a brief overview of some of the results of the study, namely the test subjects were
asked to evaluate both the level of fun of the game and the level of cooperation that the game required
(the numbers represent a scale from 1 to 6, with 6 being highest).
The data gathered from the questionaires has some interesting findings regarding this prototype.
Something that is obviously apparent is that the game’s controls could have been better refined, and
that players found that the ball’s controls were more adequate than those of the square.
Table 5.3: Game Evaluation Overview
Average
Standard
Deviation
Fun
4.5
1.1
Need for Cooperation
5.6
0.73
Importance of the Wii Remote
5.31
0.79
Ball Control
4.69
0.63
Square Control
4.43
0.94
On the other hand, the users felt that one of the main objectives of this game was accomplished - a
game that required two players to work together in order to progress through it. It is noteworthy to point
out that players found that the usage of the Wii Remote and Nunchuk contributed positively to the game
experience.
Level Evaluation
Regarding the level evaluation (Table 5.4 shows the results of evaluating the level difficulty, Table 5.6
provides data from trying to understand if a certain level was dull for one of the characters and Table
5.5 exposes the results of evaluating the fun of each level), it fell within our expectations. The first level
was not found to be particularly fun by players, but its main purpose is serving as a tutorial. Due to the
5.1. MOJO EVALUATION
47
fact that most players found the difficulty of that level adequate, and some actually found it too easy, that
goal seems to be accomplished.
Table 5.4: Level Difficulty Evaluation
Easy
Adequate
Hard
Level 1
4
10
1
Level 2
2
13
0
Level 3
0
15
0
Level 4
2
12
1
Level 5
1
11
2
Level 6
0
9
5
Concerning the remaining levels, players found that the level of fun was on the high end of the scale.
It is interesting to note that a significant part of the players found the last level too hard (5 out of 14),
this can partly explain why these players also found the level less fun than the other players. It seems
that players, for the most part, accepted the increased difficulty that this level had due to it being the last
level of the game.
Table 5.5: Evaluation of the Fun of each level
Average
Standard Deviation
Level 1
3.57
1.02
Level 2
4.4
0.91
Level 3
4.87
0.92
Level 4
4.2
1.15
Level 5
4.64
1.15
Level 6
4.64
1.45
Another thing that we would like to highlight is that, in the game’s fifth level, four players (out of 14)
found the level uninteresting for the square. This can be justified due to the separation and lack of
interaction that exists between the two characters in this level - past the beggining of the level they take
rather different routes, and all but one losangle are collected by the ball player.
5.1.3
Adjustments made due to User Feedback
At the end of the evaluation session, we realised that a small adjustment should be made to the ball we received a few informal complaints that the ball was too hard to handle adequatly. After changing
the behaviour of the ball’s movement so that this aspect was improved upon, we allowed some users to
48
CHAPTER 5. EVALUATION
Table 5.6: Level Evaluation from a Character’s Perspective
Uninteresting for the Ball
Uninteresting for the Square
Level 1
0
1
Level 2
0
1
Level 3
1
0
Level 4
0
2
Level 5
0
4
Level 6
0
0
test the game again and the feedback given to us by them was that the change had been effective and
enough to improve the character’s handling.
5.2
Final Evaluation
After the Mojo Evaluation session, we conducted another formal evaluation session. This time we
choose to evaluate the game by using a pre-existing methodology. Additionally, we also decided to
profile the players according to the DGD1 model[1].
5.2.1
Method
In this section, we present the methods we used in order to ascertain the type of player according to the
Demographic Game Design 1 model[1] and the methods we used to evaluate Geometry friends.
Determining type of player
So that we could better analyse how well Geometry Friends had achieved its goal of providing fun to
Casual players of the Participant profile, it was necessary to determine the type of player that was
evaluating the game. We did this by using an online survey [5] made available by the creators of this
model. It is important to note that the DGD1[1] are not mutually exclusive and this survey identifies how
strongly each of the profiles are present in each player.
Evaluating Geometry Friends
The method used to evaluate the game was by letting users play all the levels of the game. After this
game session, players were asked to use the criteria for Player Enjoyment in Games presented by
GameFlow model’s[16]. This model allows us to examine how users feel about specific areas of the
game. Additionally, as shown in[16], it can be used to review a game quite accurately, assuming one
uses testers with high game literacy. Despite the authors considering that these should not be used as
5.2. FINAL EVALUATION
49
an evaluation tool, the are adequate to our purpose - finding out if we managed to create a game that
has the qualities that are necessary to attract our target demographic. To this end we used a focus group
of ten gamers with high game literacy.
5.2.2
Test User’s profiles
Table 5.7 shows the DGD1 profiling of the group. As can be seen from it, the participant profile, despite
not being the most dominant one, has significant representation for a group of this size.
Table 5.7: DGD1 profiles of the sample
Conqueror
Manager
Wanderer
Participant
Dominantly
0
3
0
1
Strongly
1
0
0
1
Moderately
2
2
4
1
Marginally
0
1
4
4
Total
3
6
8
7
The following table, table 5.8, shows the representation of the Casual and Hardcore demographics
within our focus group. It was surprising to see this many casual gamers (6 out of 10) in a high game
literacy group.
Table 5.8: Casual vs Hardcore
5.2.3
Casual
Hardcore
6
4
Results
To facilitate the analysis of the data we constructed tables that showed the average values and corresponding standard deviation of our user tests. The values that users could assign to these criteria
ranged from 1 to 5. The lowest value meant that the user felt the game went against that criteria, while
the highest value represented that the user felt that the game fulfilled all requirements of that criteria.
Table 5.9 contains the data of the criteria relevant to the Concentration Element. The table shows
that, while users did not feel like they were being overstimulated by various sources, the game did do a
good job at focusing them on the important game tasks. The fact that the game does not overstimulate
players, or try to make a player juggle activities is a non problem. A frenetic pace would not help attract
our target demographic.
The game has some problems in the Challenge element as is easily show in table 5.10. Despite
finding that the game has an adequate dificulty curve, players feel that the game’s challenges do not
match their level. This is due to two extremes, the players that find the type of challenges used in
50
CHAPTER 5. EVALUATION
Table 5.9: Concentration
Average
Standard
Deviation
Games should provides a lot of stimuli from
3.4
0.97
4.2
0.79
4.2
0.79
4.1
0.88
3.4
1.07
4.3
1.34
different sources
Games should provide stimuli that are worth
attending to
Games should quickly grab the players’ attention
and maintain their focus throughout the game
Players should not be burdened with tasks that
do not feel important
Games should have a high workload, while still being
appropriate for the players’ perceptual, cognitive,
and memory limits
Players should not be distracted from tasks that they
want or need to concentrate on
this game easy and proceeded easily from level to level, and those that got stuck for a while trying
to overcome a challenge. Unfortunately, the easiest way to solve this problem is by having adjustable
difficulty settings, but the challenges used in this game are not typically well suited for this solution.
Additionally, most of the problems that player had were caused by deficient cooperation. This helps to
explain why, despite feeling that there is some disconnection between a players skill and the game’s
difficulty, the data gathered shows that players felt the game’s difficulty curve was well adjusted.
Table 5.10: Challenge
Average
Standard
Deviation
Challenges in games must match the player’s skill level
3.1
0.99
Games should provide different levels of challenge
2.7
1.06
4.1
1.2
3.8
1.03
for different players
The level of challenge should increase as the player
progresses through the game and increases their skill
level
Games should provide new challenges at an appropriate
pace
5.2. FINAL EVALUATION
51
Most of the problems related to the Player Skills element (see table 5.11) are due to the game’s
limited protype form. The game has minimal form of in-game help and tutorials. Testing of the game is
currently preceeded by an explanation of the game’s controls and the character’s abilities. This would
have to be corrected so that the game was more accessible to target demographic.
Table 5.11: Player Skills
Average
Standard
Deviation
Players should be able to start playing the game without
3.6
1.07
4.4
0.7
1.6
0.97
3
1.49
3.9
0.88
3.4
1.07
4.3
0.82
reading the manual
Learning the game should not be boring, but be part of
the fun
Games should include online help so players do not need
to exit the game
Players should be taught to play the game through tutorials
or initial levels that feel like playing the game
Games should increase the players’ skills at an appropriate
pace as they progress through the game
Players should be rewarded appropriately for their effort
and skill development
Game interfaces and mechanics should be easy to learn and use
Examination of table 5.12 shows that there is still room to improve the controls - both in terms of the
controls’ responsiveness and accuracy. However, the observation of players suggests that the way to
correct some of the problems players have would be by using a different control scheme. Sometimes
players overtilt the Wii Remote when playing with ball character (or the Nunchuk when playing with the
square character), which does not match the movement gesture they intend to do. The lowest ranked
criteria is caused by a bug currently in the game that makes one character get stuck.
Table 5.13 shows that the game’s objectives are easy to grasp and players are aware of them early
in the game. Improving the visibility of intermediate goals needs to be done carefully. Intermediate goals
are the next step to take in a puzzle, and if it is too obvious players will not be challenged by it.
The user tests show (see table 5.14 that the feedback that players receive from the game needs little
improvement. Determining how close a team of players is to completing a level is a simple matter of
checking how many losangles in the level, the players’ actions result in the movement of their avatar and
knowing the score is a simple matter of checking the in game timer.
The Immersion element of this game, at first glance, appears to be too low (see table 5.15). However,
it is necessary to keep in mind that one of the requirements of the game’s target demographic is that a
game cannot be too consuming and needs to be playable for a few minutes. This suggests that having a
moderate level of Immersion is desirable. Additionally, the authors of these criteria should be evaluated
52
CHAPTER 5. EVALUATION
Table 5.12: Control
Average
Standard
Deviation
Players should feel a sense of control over their characters
4.2
0.63
3.9
0.99
3.8
1.23
3.4
0.88
4.2
0.79
4
1.05
or units and their movements and interactions in the
game world
Players should feel a sense of control over the game
interface and input devices
Players should feel a sense of control over the game shell
(starting, stopping, saving, etc.)
Players should not be able to make errors that are detrimental
to the game and should be supported in recovering from errors
Players should feel a sense of control and impact onto the
game world (like their actions matter and they are shaping
the game world)
Players should feel a sense of control over the actions that
they take and the strategies that they use and that they are
free to play the game the way that they want (not simply
discovering actions and strategies planned by the game
developers)
Table 5.13: Clear Goals
Average
Standard
Deviation
Overriding goals should be clear and presented early
4.4
0.84
Intermediate goals should be clear and presented at
3.9
0.99
appropriate times
Table 5.14: Feedback
Average
Standard
Deviation
Players should receive feedback on progress toward their goals
4.2
0.92
Players should receive immediate feedback on their actions
4.5
0.71
Players should always know their status or score
4.1
1.37
5.2. FINAL EVALUATION
53
through observation[16] and not direct questioning.
Table 5.15: Immersion
Average
Standard
Deviation
Players should become less aware of their surroundings
3.3
0.95
Players should become less self-aware and less worried about
3.1
0.88
Players should experience an altered sense of time
3.2
0.79
Players should feel emotionally involved in the game
2.7
1.06
Players should feel viscerally involved in the game
2.6
1.26
everyday life or self
The Social Interaction allowed by the game is one of the most important requirements. As seen
in table 5.16, our game has succeeded in fullfilling this aspect of our user’s needs. The only Social
Interaction criteria that our game does not meet is not relevant to the type of game - a co-located
cooperative game.
Table 5.16: Social Interaction
Average
Standard
Deviation
Games should support competition and cooperation
4.9
0.32
4.4
0.7
2
1.15
between players
Games should support social interaction between
players (chat, etc.)
Games should support social communities inside and
outside the game
Using these criterias to evaluate Geometry Friends has shown that it has accomplished most of its
objectives succesfully - being a simple two-player co-located cooperative game that catters to a particular
demographic with particular needs. This study has also allowed us to identify some rough edges that
require some additional polishing so that the game provides a better experience for this demographic.
54
CHAPTER 5. EVALUATION
Chapter 6
Conclusions
By focusing on the needs of a specific demographic of players, we were able to determine the requirements of a game for them. This demographic required a cooperative co-located game that allowed social
interaction between players.
Our exploration of current successful cooperative games, game design and social psychology theories allowed us to determine factors that could be used to ensure that our game promoted cooperative
behaviour. First and foremost is the fact that gameplay is a series of challenges that are beaten when
players successfully perform tasks. If we can guarantee that these tasks require or promote cooperation,
we are effectively creating a cooperative game. Steiner’s Task typology[14] can be used as a useful tool
to quickly assess the potential for cooperation of any given task. Within each of the Game Challenges
types[9], there are some game challenge types that have already been used in games to promote cooperation. We also explored and exposed some more abstract notions that games often use to enhance
and promote cooperation between players. Due to the fact that they are more abstract concepts that are
used freely in games, independently of genre, we chose to formalize them as Game Design Pattterns[3].
We developed Geometry Friends, a two player cooperative 2D platform game so that we could test
some of the concepts that we identified. We mainly used three design patterns in the development of this
game - Complementarity, Synergies Between Abilities and Shared Goals. Most of the challenges used
in the game were the natural choice for a platform game - Coordination, Reflex/reaction and Spatialawareness Challenges. We mainly used conjuctive tasks in the challenges present in the game, so that
the challenges were only beaten by joint effort from the players.
Using a development cycle of prototyping and evaluating helped polish each iteration of the game
and identify problem areas that neeeded improvement. The evaluation made during the prototype stage
and the final evaluation shows us that we have sucessfully created a game that emphasizes cooperative
gameplay. However, our evaluation also shows that some extra care should be taken in designing the
levels for a cooperative game that has characters with different abilities. The level design should be
balanced to make sure that one of the players does not feel like he is being left out. In our game, this
was quite apparent on the fifth level. This also suggests that creating a level that is solved entirely by
using a Divide and Conquer approach is not the best idea for a cooperative game.
As future work, it is possible to make further user tests with Geometry Friends (using tests with
indirect questioning to evaluate each of GameFlow’s Criteria for Player Enjoyment), so that it can be
better assessed as a cooperative game for Participant players. Additionally, it is possible to continue to
55
56
CHAPTER 6. CONCLUSIONS
polish several areas of the game. The theoritical work concerning Game Design Patterns and Challenge
Archetypes can continue to be explored. There were enough unused but identified mechanics to attempt
to make a completely different game for a different demographic of users.
Bibliography
[1] C. Bateman and R. Boon. 21st Century Game Design. Charles River Media, 2005.
[2] S. Björk and J. Holopainen. Patterns in Game Design. Charles River Media, 2005.
[3] S. Björk, S. Lundgren, and J. Holopainen. Game design patterns. In Proceedings of Digital Games
Research Conference 2003, 2003.
[4] Blizzard
Entertainment.
World
of
warcraft
official
website.
URL
http://www.
worldofwarcraft.com/. Date accessed - 15th April, 2009.
[5] International Hobo. Dgd1 questionnaire - what playstyle do you prefer? URL http://survey.
ihobo.com/DGD/DGD1.shtml. Date accessed - 15th April, 2009.
[6] A.G. Ingham, G. Levinger, J. Graves, and V. Peckham. The ringelmann effect: Studies of group size
and group performance. Journal of Experimental Social Psychology, 10(4):371–384, July 1974.
[7] Pascal Luban.
The megatrends of game design, part 3, December 2008.
URL
http://www.gamasutra.com/view/feature/3869/the_megatrends_of_game_
design_.php?print=1. Date accessed - 15th April, 2009.
[8] Matthias Rehm, Nikolaus Bee, and Elisabeth André. Wave like an egyption - accelerometer based
gesture recognition for culture specific interactions. In Proceedings of HCI 2008, 2008.
[9] A. Rollings and E. Adams. On Game Design. New Riders, 2003.
[10] Mariko Sanchanta. Nintendo’s wii takes console lead. URL http://www.ft.com/cms/s/0/
51df0c84-6154-11dc-bf25-0000779fd2ac.html?nclickcheck=1. Date published - 12th
September 2007. Date accessed - 15th April, 2009.
[11] Valve Software. Counter-strike official webpage, . URL www.counter-strike.net. Date accessed - 15th April, 2009.
[12] Valve Software. Left 4 dead official website, . URL http://www.l4d.com/. Date accessed 15th April, 2009.
[13] Valve Software. Team fortress 2 official webpage, . URL http://teamfortress.com/. Date
accessed - 15th April, 2009.
[14] L.D. Steiner. Group Process and Productivity (Social Psychological Monograph). Academic Press
Inc, 1972.
[15] Gloria Stern.
cember 1997.
Discussing multiplayer online games with digital arcana’s jeffrey sullivan, DeURL http://www.gamasutra.com/view/feature/3244/discussing_
multiplayer_online_.php?print=1. Date accessed - 15th April, 2009.
[16] P. Sweetster and P. Wyeth. Gameflow: a model for evaluating player enjoyment in games. In
Computers in Entertainment. Volume 3 , Issue 3, July 2005.
[17] Wiili. Wiili. URL www.wiili.org. Date accessed - 15th April, 2009.
[18] Left 4 Dead Wiki. Infected webpage, . URL http://left4dead.wikia.com/wiki/Infected.
Date accessed - 15th April, 2009.
57
58
BIBLIOGRAPHY
[19] Left 4 Dead Wiki. Gameplay modes webpage, . URL http://left4dead.wikia.com/wiki/
Gameplay_modes. Date accessed - 15th April, 2009.
[20] Left 4 Dead Wiki.
Survivors webpage, .
URL http://left4dead.wikia.com/wiki/
Survivors. Date accessed - 15th April, 2009.
[21] Left 4 Dead Wiki. Weapons webpage, . URL http://left4dead.wikia.com/wiki/Weapons.
Date accessed - 15th April, 2009.
[22] TF2 Wiki. Classes webpage, . URL http://tf2wiki.net/wiki/Class. Date accessed - 15th
April, 2009.
[23] TF2 Wiki. Maps webpage, . URL http://tf2wiki.net/wiki/Maps. Date accessed - 15th
April, 2009.
[24] Wikipedia. Lego star wars: The video game webpage, . URL http://en.wikipedia.org/
wiki/Lego_Star_Wars_The_Video_Game. Date accessed - 15th April, 2009.
[25] Wikipedia.
Team fortress webpage, .
URL http://en.wikipedia.org/wiki/Team_
Fortress. Date accessed - 15th April, 2009.
[26] Wikipedia. Team fortress classic webpage, . URL http://en.wikipedia.org/wiki/Team_
Fortress_Classic. Date accessed - 15th April, 2009.
[27] WoWWiki. Alterac valley webpage, . URL http://www.wowwiki.com/Alterac_Valley. Date
accessed - 15th April, 2009.
[28] WoWWiki. Arathi basin webpage, . URL http://www.wowwiki.com/Arathi_basin. Date
accessed - 15th April, 2009.
[29] WoWWiki. Arena webpage, . URL http://www.wowwiki.com/Arena. Date accessed - 15th
April, 2009.
[30] WoWWiki. Eye of the storm webpage, . URL http://www.wowwiki.com/Eye_of_the_storm.
Date accessed - 15th April, 2009.
[31] WoWWiki. Holy trinity webpage, . URL http://www.wowwiki.com/Holy_Trinity. Date
accessed - 15th April, 2009.
[32] WoWWiki. Professions webpage, . URL http://www.wowwiki.com/Professions. Date accessed - 15th April, 2009.
[33] WoWWiki. Strand of the ancients webpage, . URL http://www.wowwiki.com/Strand_of_
the_Ancients. Date accessed - 15th April, 2009.
[34] WoWWiki. Warsong gulch webpage, . URL http://www.wowwiki.com/Warsong_Gulch. Date
accessed - 15th April, 2009.