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 De- senho 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 con- troller 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 perspec- tive 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 3 2.1 Challenges ...... 3 2.1.1 Pure Challenges ...... 3 2.1.2 Applied Challenges ...... 6 2.2 Game Design Patterns ...... 8 2.3 Social Psychology ...... 9 2.3.1 Ringelmann effect ...... 9 2.3.2 Task Classification ...... 9 2.4 Game Analysis ...... 10 2.4.1 World of Warcraft ...... 10 2.4.2 Lego Star Wars ...... 12 2.4.3 Team Fortress 2 ...... 13 2.4.4 Left 4 Dead ...... 15 2.4.5 Counter-Strike ...... 17 2.5 Wii...... 19 2.5.1 Wii Remote ...... 19 2.5.2 Nunchuk ...... 20 2.5.3 Wii Remote and the PC ...... 20
3 Conceptual Model 25 3.1 Task potential for cooperation ...... 25 3.1.1 Divisibility ...... 26 3.1.2 Optimizing ...... 26 3.1.3 Combinability ...... 26 3.2 Challenges used in Cooperative Games ...... 26 3.2.1 Pure Challenges ...... 27 3.2.2 Applied Challenges ...... 27 3.3 Design Patterns for Cooperative games ...... 30 3.3.1 Complementarity ...... 30
vii viii CONTENTS
3.3.2 Synergies between abilities ...... 31 3.3.3 Support Abilities ...... 31 3.3.4 Shared Goals ...... 32 3.3.5 Synergies between goals ...... 32 3.3.6 Special Rules for Players of the same Team ...... 33 3.3.7 Mechanisms for sharing ...... 34
4 Geometry Friends 35 4.1 Main Characteristics ...... 35 4.2 Overview ...... 36 4.2.1 Player Motivation...... 36 4.2.2 Game Genre...... 36 4.2.3 Target Customer...... 36 4.2.4 Target Platforms...... 36 4.2.5 Design Objectives...... 36 4.3 Designing Geometry Friends ...... 37 4.3.1 Patterns Used ...... 37 4.3.2 Challenges used ...... 37 4.3.3 Tasks used ...... 37 4.4 Technological Solutions ...... 38 4.4.1 XNA ...... 38 4.4.2 Farseer ...... 38 4.4.3 WiimoteLib ...... 39 4.4.4 Wiigle ...... 39 4.5 Development Process ...... 40 4.5.1 First Prototype ...... 40 4.5.2 Second Prototype ...... 42
5 Evaluation 45 5.1 Mojo Evaluation ...... 45 5.1.1 Tester’s Characteristics ...... 45 5.1.2 Results ...... 46 5.1.3 Adjustments made due to User Feedback ...... 47 5.2 Final Evaluation ...... 48 5.2.1 Method ...... 48 5.2.2 Test User’s profiles ...... 49 5.2.3 Results ...... 49
6 Conclusions 55
Bibliography 56 List of Figures
2.1 The Wii Remote ...... 20 2.2 The Wii’s Nunchuk accessory ...... 21
3.1 Conceptual Model Overview ...... 25
4.1 Initial sketch of a level ...... 35 4.2 Actions of the Ball character ...... 35 4.3 Actions of the Square character ...... 35 4.4 Level 1 of the first prototype ...... 40 4.5 Level 2 of the first prototype ...... 40 4.6 Level 3 of the first prototype ...... 40 4.7 Level 1 of the second prototype ...... 42 4.8 Level 2 of the second prototype ...... 42 4.9 Level 3 of the second prototype ...... 42 4.10 Level 4 of the second prototype ...... 42 4.11 Level 5 of the second prototype ...... 42 4.12 Level 6 of the second prototype ...... 42
ix x LIST OF FIGURES List of Tables
2.1 Driver and API License Overview ...... 22 2.2 Wii Remote Support Overview ...... 23 2.3 Wii Remote Extra Features Support Overview ...... 23 2.4 NunChuk Support Overview ...... 24
5.1 Sample Characteristics ...... 46 5.2 Experience with the Wii ...... 46 5.3 Game Evaluation Overview ...... 46 5.4 Level Difficulty Evaluation ...... 47 5.5 Evaluation of the Fun of each level ...... 47 5.6 Level Evaluation from a Character’s Perspective ...... 48 5.7 DGD1 profiles of the sample ...... 49 5.8 Casual vs Hardcore ...... 49 5.9 Concentration ...... 50 5.10 Challenge ...... 50 5.11 Player Skills ...... 51 5.12 Control ...... 52 5.13 Clear Goals ...... 52 5.14 Feedback ...... 52 5.15 Immersion ...... 53 5.16 Social Interaction ...... 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 demo- graphics 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 experi- ences 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
1Massive Multiplayer Online Role Playing Games 2World of Warcraft official website: www.worldofwarcraft.com 3Counter-Strike official website: www.counter-strike.net 4First Person Shooter 5Team Fortress 2 official website: orange.half-life2.com/tf2.html 6Lego Star Wars official website: www.legostarwarsthevideogame.com 7Super Mario Galaxy official website: www.supermariogalaxy.com 8Buzz official website: www.buzzthegame.com
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 ex- pose 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 ex- plore 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 el- ements 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 com- plete 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 im- portant 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 tim- ing - "‘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 game- play 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 practi- cally 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 sub- goals.
Scale
• Strategy - "‘Strategy is the mental act of planning: taking advantage of your situation and re- sources, antecipating your opponent’s moves, knowing and minimizing your weaknesses"[9]. Strate- gic 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 defense- less) 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, exem- plified 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 for- malise 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 pon- tential 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 coop- erative 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 condi- tions 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 gen- eral is an instant victory, capturing certain buildings and eliminating other non player char- acters 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 chal- lenges 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 resup- ply 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 eco- nomic 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 Managed- Wii/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 per- forming 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 27
3.2.1 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 es- corts. These usually involve a team of players escorting another character across from one place
1Real 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 es- corts 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, typi- cally 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 cap- ture 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 pro- tecting 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 de- fends 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.
2Starcraft official website: http://www.blizzard.com/us/starcraft/ 3Capture The Flag 4Threewave official website: http://www.threewavesoftware.com/multiplayergames.html 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 class- based 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 "‘Comple- mentarity" 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 vic- tory 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 com- mon 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 can- didates, 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’ expecta- tions? 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, cooper- ation 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 allo- cate 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 coopera- tive 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 Figure 4.3: Actions of the Square character
4.1 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 inter- facing 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 geomet- rical 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 profi- ciency, 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 Designing Geometry Friends
4.3.1 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 syn- ergies 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 Development Process
4.5.1 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 in- tended 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 Some Reasonable Plenty 7 2 3 4
5.1.2 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
Casual Hardcore
6 4
5.2.3 Results
To facilitate the analysis of the data we constructed tables that showed the average values and cor- responding 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 different sources
Games should provide stimuli that are worth 4.2 0.79 attending to
Games should quickly grab the players’ attention 4.2 0.79 and maintain their focus throughout the game
Players should not be burdened with tasks that 4.1 0.88 do not feel important
Games should have a high workload, while still being 3.4 1.07 appropriate for the players’ perceptual, cognitive, and memory limits
Players should not be distracted from tasks that they 4.3 1.34 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 for different players
The level of challenge should increase as the player 4.1 1.2 progresses through the game and increases their skill level
Games should provide new challenges at an appropriate 3.8 1.03 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 reading the manual
Learning the game should not be boring, but be part of 4.4 0.7 the fun
Games should include online help so players do not need 1.6 0.97 to exit the game
Players should be taught to play the game through tutorials 3 1.49 or initial levels that feel like playing the game
Games should increase the players’ skills at an appropriate 3.9 0.88 pace as they progress through the game
Players should be rewarded appropriately for their effort 3.4 1.07 and skill development
Game interfaces and mechanics should be easy to learn and use 4.3 0.82
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 or units and their movements and interactions in the game world
Players should feel a sense of control over the game 3.9 0.99 interface and input devices
Players should feel a sense of control over the game shell 3.8 1.23 (starting, stopping, saving, etc.)
Players should not be able to make errors that are detrimental 3.4 0.88 to the game and should be supported in recovering from errors
Players should feel a sense of control and impact onto the 4.2 0.79 game world (like their actions matter and they are shaping the game world)
Players should feel a sense of control over the actions that 4 1.05 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 everyday life or self
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
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 between players
Games should support social interaction between 4.4 0.7 players (chat, etc.)
Games should support social communities inside and 2 1.15 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 require- ments 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 theo- ries 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 coop- eration. 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 Spatial- awareness 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 ac- cessed - 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. Discussing multiplayer online games with digital arcana’s jeffrey sullivan, De- cember 1997. URL 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 ac- cessed - 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.