Reusing the Game World

Reusing the Game World Aspects of replacing traditional 2D menu interaction with interaction inside the 3D world

KAMILLA

PAHLEFORS

Master of Science Thesis Stockholm, Sweden 2007

Reusing the Game World Aspects of replacing traditional 2D menu interaction with interaction inside the 3D world

KAMILLA

PAHLEFORS

Master’s Thesis in Human Computer Interaction (30 ECTS credits) at the School of Media Technology Royal Institute of Technology year 2007 Supervisor at CSC was Olle Bälter Examiner was Lars Kjelldahl TRITA-CSC-E 2007:098 ISRN-KTH/CSC/E--07/098--SE ISSN-1653-5715

Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se

Reusing the game world – Aspects of replacing traditional 2D menu interaction with interaction inside the 3D world Abstract

In today’s computer game industry the developers are forced to compete hard for the players. This results in computer games that constantly and rapidly become more and more advanced and refined. To achieve this, the developers need to find new and interesting ways to attract players to their game or franchise. One game feature; the 3D menu, so far not fully implemented anywhere, consists in providing menu functionality in the 3D world and through it let players do things that normally are done in a 2D menu, such as change different settings, reach tutorials and start the game. The purpose of this Master’s project is to investigate if using the 3D world for what is traditionally done through 2D menu interaction can be suitable from a UI design perspective as well as from a user perspective. The study was conducted through prototype tests and a large survey through a questionnaire that was answered by 40 people. The menu feature was also theoretically investigated from a UI design and HCI perspective through studying literature within these areas. The results show that there are a number of things that can improve if a 3D menu is used, such as first impression of the game, menu navigation, graphical look and immersion. However, there are also things that are more easily achieved with traditional 2D menus, such as speed through the menu and helping the user through implementing standard menu solutions. Generally the 3D menu feature was liked by some, especially by the ones who got to try the prototype, and less liked by others, especially players who value speed through the menus the most. The questionnaire also showed that there can be substantial differences in opinions on the 3D menu between players who play different game types and the developer who considers implementing 3D menus has potentially a lot to gain if the target group includes MMORPG players.

Återanvändning av spelvärlden – Aspekter kring att ersätta traditionella 2D-menyer med interaktion i 3D-världen Sammanfattning

I datorspelsindustrin idag tvingas datorspelsutvecklarna slåss hårt om spelarna. Detta medför att datorspelen hela tiden snabbt blir mer och mer avancerade och förfinade. För att uppnå den här förbättringen krävs att utvecklarna hittar nya och intressanta sätt att locka spelarna till deras spel eller spelserie. En speldesignsidé; 3D-menyn, som hittills inte har blivit implementerad fullt ut någonstans, består i att tillhandahålla det som normalt nås via 2D-menyer, såsom inställningar, övningsbanor samt starta spelet, i 3D världen istället. Syftet med det här examensarbetet är att undersöka ifall användandet av 3D-menyer kan vara fördelaktigt från ett användarperspektiv såväl som från ett teoretiskt perspektiv gällande gränssnittsdesign. Studien genomfördes med hjälp av prototyptester samt ett fristående frågeformulär, vilket besvarades av 40 personer. Menydesignen utvärderades också teoretiskt sett från perspektiven gränssnittsdesign samt MDI med hjälp av litteratur från dessa områden. Studiens resultat visar att det finns ett antal aspekter som kan vara bättre hos 3Dmenyer, såsom första intrycket från spelet, menynavigationen, det grafiska utseendet samt förmågan att underlätta inlevelse. Det finns å andra sidan saker som är lättare att uppnå med hjälp av traditionella 2D-menyer, såsom att menyn är snabb att använda, samt att hjälpa spelaren genom att följa standarder inom menydesign. Generellt tyckte vissa om 3D-menydesignen, speciellt de som fick testa den under prototyp-testerna, medan andra tyckte sämre om designen, till exempel de som framförallt värdesätter att en meny är snabb att använda. Frågeformuläret visade också att det kan finnas stora skillnader i åsikterna kring 3D-menyer mellan spelare som föredrar olika spelgenrer och på grund av detta kan det finnas det mycket att vinna för spelutvecklare som tittar närmare på att använda 3D-menyer och vars målgrupp inkluderar spelare från MMORPG-genren.

Preface

This is a Master’s thesis in Human-Computer Interaction at the Royal Institute of Technology.

I want to thank: • The DICE studio, for letting me do my Master’s project with them. • The staff at DICE who took their time to fill out the survey, join the play-tests and give me feedback on my work. • Lars Gustavsson, Creative Director and my supervisor at DICE, for always answering my questions and taking his time throughout this project. • Lars Kjelldahl, Examiner at KTH, for embracing this project. • Olle Bälter, Supervisor at KT H, for giving me feedback on the academic sides of this project. • Sara Jansson, student doing her Master’s project and later Assistant Producer at DICE, for good cooperation, for giving second opinions and for being around for support. • My family and friends who put up with me during the time this project was initiated, carried out and above all wrapped up. This project gave me valuable knowledge about what working with computer games can be like. It also gave me good general training in working closely with people from different disciplines within a company. I am very grateful that I got the opportunity to do my Master’s project at DICE, above all because the company is a highly inspiring environment to be in. People are dedicated, talented and helpful, which made my Master’s project time even more rewarding.

Table of contents 1

INTRODUCTION ..................................................................................................................................... 1 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7.

2

BACKGROUND .................................................................................................................................... 1 3D MENUS ........................................................................................................................................... 3 EARLIER PUBLICATIONS ON THE SUBJECT ......................................................................................... 4 PROBLEMS .......................................................................................................................................... 5 PURPOSE ............................................................................................................................................. 5 LIMITATIONS....................................................................................................................................... 5 DIGITAL ILLUSIONS ............................................................................................................................ 5

THEORY .................................................................................................................................................... 6 2.1. 3D MENUS ........................................................................................................................................... 6 2.1.1 3D in interfaces ................................................................................................................... 6 2.1.2 Games using the world ....................................................................................................... 7 2.2. GUI THEORIES .................................................................................................................................... 8 2.2.1 Usability Definition ............................................................................................................ 8 2.2.2 Interface objectives ............................................................................................................. 9 2.2.3 Fitts’ Law ..........................................................................................................................10 2.2.4 Information load ...............................................................................................................10 2.2.5 Feedback............................................................................................................................11 2.2.6 Novice to experienced users ............................................................................................11 2.3. GAME DESIGN THEORY .....................................................................................................................12 2.3.1 Constructing 3D game worlds .........................................................................................12 2.3.2 Starting the game ..............................................................................................................13 2.3.3 Game interfaces ................................................................................................................14 2.3.4 Gamer types ......................................................................................................................14 2.3.5 Online games.....................................................................................................................15 2.3.6 Game design today ...........................................................................................................15 2.3.7 Psychological responses ...................................................................................................16 2.4. 3D MENUS MEETS UI THEORY ..........................................................................................................17 2.4.1 3D in menus ......................................................................................................................17 2.4.2 2D menu theory ................................................................................................................17

3

METHOD CHAPTER ............................................................................................................................19 3.1. METHOD THEORY .............................................................................................................................19 3.1.1 Recruiting participants .....................................................................................................19 3.1.2 Prototyping........................................................................................................................19 3.1.3 Survey through questionnaire ..........................................................................................21 3.1.4 Data analysis .....................................................................................................................22 3.1.5 User stories........................................................................................................................22 3.2. METHOD DESCRIPTION .....................................................................................................................23 3.2.1 Assumptions......................................................................................................................23 3.2.2 Recruiting participants .....................................................................................................23 3.2.3 Prototyping........................................................................................................................24 3.2.4 Testing ...............................................................................................................................25 3.2.5 Survey through questionnaire ..........................................................................................25 3.3. IMPLEMENTATION ............................................................................................................................26 3.3.1 Participants........................................................................................................................26 3.3.2 Prototyping........................................................................................................................27 3.3.3 Survey through questionnaire ..........................................................................................32

4

RESULTS..................................................................................................................................................33 4.1. PAPER PROTOTYPING ........................................................................................................................33 4.2. COMPUTER BASED PROTOTYPING ....................................................................................................34 4.2.1 First prototype test ............................................................................................................34 4.2.2 Second prototype test .......................................................................................................35

4.2.3 Third prototype test ..........................................................................................................35 4.3. SURVEY THROUGH QUESTIONNAIRE ................................................................................................36 4.3.1 Gaming habits ...................................................................................................................36 4.3.2 Opinions on 2D menus .....................................................................................................37 4.3.3 Opinions on 3D menus .....................................................................................................39 4.4. RESULT COMPILATION – PROTOTYPE TESTS AND SURVEY ..............................................................43 4.4.1 Results - Test participants ................................................................................................43 4.4.2 Results - Survey participants............................................................................................43 4.4.3 Test participants versus survey respondents ...................................................................43 5

CONCLUSIONS......................................................................................................................................45 5.1. QUESTIONS .......................................................................................................................................45 5.1.1 Question One.....................................................................................................................45 5.1.2 Question Two....................................................................................................................45 5.1.3 Question Three..................................................................................................................46 5.1.4 Question Four....................................................................................................................47 5.1.5 Question Five ....................................................................................................................47 5.2. OVERCOMING THE CHALLENGES .....................................................................................................47

6

DISCUSSION ...........................................................................................................................................49 6.1. IMPROVEMENTS ................................................................................................................................49 6.1.1 Prototype tests ...................................................................................................................49 6.1.2 Questionnaire ....................................................................................................................49 6.2. RESULTS............................................................................................................................................50 6.3. FURTHER RESEARCH .........................................................................................................................51

7

WORD LIST.............................................................................................................................................52 REFERENCES.........................................................................................................................................53

1 INTRODUCTION ”As we have said, every design decision you make must serve the entertainment value of the game. In addition, every design decision must serve your goals for the game’s overall degree of realism. Some genres demand more realism than others. It’s up to you to establish how much realism you want and in what areas. During the design process, you must continually monitor your decisions to see if they are meeting your goals.” (Rollings & Adams, 2003, p. 82).

1.1. Background The computer game menu is one of the parts constituting the user interface, the UI, which allows the player to interact with the game. Through this menu, a 2D interface, the player navigates, typically when starting and ending the game but sometimes also during the game. Numerous books have been written on how to design and implement good game menus and the books generally describe interface features and functions in great detail (e.g. Fox, 2005; Gunderloy, 2005; Saunders & Novak, 2007). There are however some challenges that generally present themselves due to the very nature of game menus. Below is a description of four of the large challenges for game developers, as I see it, and how they affect the player. As the quality and level of detail in game graphics has improved over the years the players’ level of expectation on the game in general has gone up. What was a top notch game based on its graphics only a few years ago leaves less of an impression today. • Challenge 1: Game developers have to compete hard for the consumers and a big part of the game budget goes into the game environment and its graphics because they constitute the main part of the game. Menus typically end up visually less impressive. Since the game menu is one of the first things that meets the player who starts a new game it seems likely that a poor menu can have a negative effect on how the player feels about the game. In the same way, a surprisingly good or interesting menu should be able to enhance the player’s first impression and perhaps even game experience. • Challenge 2: If the first thing that meets the player when he or she starts the game is a menu that creates a negative experience, through for example causing confusion, frustration or disappointment, the player’s attitude towards the game can be affected negatively. As games have become more complex, the game menus have followed. It is often difficult to present a large amount of game menu options in an intuitive way and most menu structures simply reflect how other game menus have been structured before. • Challenge 3: Users have to learn how to navigate through the menu and all of its contents, which can take time and be frustrating. Before the user has learnt how the menu works and is navigated, confusion and frustration may occur. 1

Games usually present the player with an alternative world providing fun, challenge, excitement, escape etc. To achieve this, immersion is considered extremely important. • Challenge 4: Even if the game itself can be highly immersive, the game menu is traditionally not, and if the menu is used during game play the immersion is easily broken. Because of the four challenges and the reasoning presented above, doing research on and further developing game menu design can become important in the increasingly competitive game industry. Game developers should therefore be interested in facing and overcoming the following condensed game menu challenges: 1. 2. 3. 4.

Less impressive graphics than the actual game A possible first negative impression from the game Complex and non-intuitive navigation Breaking the immersion

These challenges can to a certain degree be overcome by making sure the traditional 2D game menu is designed, implemented and iterated on in a satisfying way. There are however examples of games (Grand Theft Auto-San Andreas; Animal Crossing-Wild World; NBA Live 07, Vietcong) which to some extent have implemented solutions that seem to help the game overcome some of these challenges in a more creative and non traditional way; parts of the traditional 2D menu have been replaced with interaction in the 3D world. The player can save the current game through walking up to a floppy disk, see figure 1, (Grand Theft Auto - San Andreas) or through walking to the bed, see figure 2, (Animal Crossing - Wild World) with the 3D character in the actual 3D game world. In Vietcong the player can freely walk around in an area, talk to characters and take tutorials (see figure 3).

Figure 1. Screenshot from G T A – San Andreas (2004).

Figure 2. Screenshot from A nimal Crossing – Wild World (2005).

Figure 3. Screenshot from Vietcong (2002).

Another game that has implemented an interesting game start solution is NBA Live 07 which faces the second and to some extent the first challenge. As soon as the game is started the player is presented with an empty basket ball practice gym, see figure 4, and controls a character that can move around and practice shooting. The game has an ordinary 2D menu, see figure 5, that is spiced up through having the practice gym as the menu background, why challenge one can be regarded as faced. The 2D menu still has 2D objects constituting the actual menu on top of the background, why it does not come all the way in facing challenge one.

2

Figure 4. When the game starts the player can immediately practice (screenshot from NBA Live 07).

Figure 5. The menu is an ordinary 2D menu with the gym as background (screenshot from N BA Live 07).

1.2. 3D menus If the design ideas presented above are combined and further developed the result can be a new type of game menu, a “3D menu”, which can constitute an alternative to ordinary 2D menus. Below is a description of what a 3D menu is, according to how I define it, and how it can be used. The 3D menu is an in-game 3D world that the player is brought to immediately after the game is started. If a game has a 3D menu it does not need and should not have a traditional 2D game menu. 3D menus can be used in games that take place in a 3D world, and should share 3D objects with that world. The game and the 3D menu should however not be the same thing: players are either in the 3D menu or in the 3D game in contrast to the G TA implementation where the 3D menu elements are scattered in the actual game world. In the 3D menu, options that are normally accessed in a 2D menu such as settings or launch of the game are provided. A scenario describing what accessing an NBA game that runs on a PC and that has a 3D menu could be like is presented below.

“The player double clicks the “NBA” icon on the desktop. The legal screens are shown followed by a loading bar. A few seconds later the player finds himself standing in a sports facility changing room full of loc kers, each with a name and photo of a player on them. This environment is the 3D menu, but that is not communicated to the player. One lock er is open and it says “B. Wallace” on it. The player walk s up to the locker and can through pointing and clicking on things in the lock er, such as different shirts, wristbands and bandanas, try them on. On the inside of the lock er door there is a full length mirror in which he can see himself, Ben Wallace, and how the selected gear look s on him. If he would walk up to another lock er and click on it, that lock er would instead open and he would becom e that team member. H e does not do that, but instead he walks up to a stereo on a shelf on the wall and moves the slider to get different music in the speakers. N ext to the stereo is a calendar and through pointing and clicking on dates he can se that his team, the Chicago Bulls (the whole gym is decorated in Chicago Bulls merchandise), will play against different teams on different days. H e leaves the calendar on March 22:nd, the day when they are up against th e Cleveland Cavaliers. The player walk s towards the door on which it says “Game Arena” and finds a corridor. A s he walks through the door and corridor the player leaves the 3D menu. Now the actual NBA basketball game, where the player is Ben Wallace in the Chicago Bulls, meeting the Cleveland Cavaliers, is loading. When the player comes out of the corridor he walks into a large basketball arena filled with spectators and his teammates and opponents are already doing their warm-up on the center court”. 3

If the NBA PC game would have an ordinary 2D menu, the options that were presented in this 3D menu could instead have been available as: • A list of basketball players that the player can choose to play as. • A list of clothes and accessories that the character can wear. • A list of radio stations that can be played in the speakers. • A list of different teams that the player can be up against in the game. • A button to access the actual basketball game. In this thesis and according to its description above, a 3D menu is: • A 3D world providing options that are normally found in 2D menus. • A solution that can constitute an alternative to ordinary 2D menus to increase immersion and make the game menu and the game less different. A 3D menu is not a concept used in menu or game design but merely a name that is used throughout this thesis to describe the type of menu presented above. The game “Planetside” has to some extent implemented a 3D menu and the game and feature is described in the theory chapter. If the 3D menu can help facing or even overcoming challenges presented by traditional menus there could be a lot to gain for the game developers as well as for the players. This however needs to be thoroughly investigated and tested, which is what has been done in this project. At a first glance, 3D menus can: • Give the menu as impressive graphics as the real game because it is set in the real game. • Give the player a first positive impression because the game world is presented right away. • Reduce the navigation problems, since navigating in a purposefully designed 3D world is intuitive: we all spend our lives navigating through 3D space. • Provide as much immersion as the game does, given that the “3D menu” interaction does not break it.

1.3. Earlier publications on the subject There is not much written on this specific topic, in fact I found no articles or books that even suggested replacing 2D menus with 3D alternatives. The only remotely related material I came across was on incorporating 3D objects in the 2D interface in a computer game (Fox, 2005). This however is merely a graphical change to the user; it does not change how the 2D menu would be used, why it is of little interest for this study. There is however an extensive number of books on game interface design (e.g. Fox, 2005; Gunderloy, 2005; Saunders & Novak, 2007), as well as of course user interface design in general (e.g. Faulkner, 1998; Galitz, 2002). There are also publications on how game worlds can be constructed, and I found Ernest Adams’ article “Construction of Ludic Space” (2003) particularly interesting. Adams discusses the design of and the rules applying to construction of 3D worlds for games in great detail. He recommends designing so that familiar locations or objects are placed in the 3D world to give the player cues of what he or she is expected to do in that environment. 4

1.4. Problems The problems discussed in this report are: Can a 3D world present an environment that to some extent can replace traditional game menus? If so, in which types of games and to what extent can it be used? How does this relate to traditional menu usage and what is better and what is worse, from an HCI and UI design perspective? What do players think about this solution and how do they react if presented with it? Are there other advantages with this menu solution than the possible removal of the four challenges presented above?

1.5. Purpose The purpose of this project is to investigate and survey if using the 3D world for what is traditionally done through 2D menu interaction can be suitable from a UI design perspective as well as from a user perspective.

1.6. Limitations This project is limited to games that take place in a 3D world. It is focused on PC games, even if console and portable console games also are discussed for reference. Arcade games are not studied in this project.

1.7. Digital Illusions Digital Illusions Creative Entertainment, also called Digital Illusions CE or simply DICE, is the most well-known and successful Swedish game developer, as well as one of the biggest game developing studios in the world. In October 2006 a merger between DICE and Electronic Arts, EA, was realised and DICE is now “EA Digital Illusions Creative Entertainment”. They develop video and computer games mainly in the first-person shooter (FPS) and racing genre for all leading platforms such as PlayStation 2, PlayStation 3, Xbox, Xbox 360 and PC. DICE works with three core values – quality, well-being and innovation; • They and aim at producing games of excellent quality regarding design, technical performance and game experience for the consumer. • They consider the staff their most important asset and strive to take good care of their employees. • Their innovation value is expressed in the 2005 annual report by the CE O Patrick Söderlund: “Innovation is an absolute necessity in our sector. We do not need to always revolutionize our products, but they will not be better without evolution.” They concentrate on producing games for the Unites States and Europe but also aim at making games for a global mass-market (Digital Illusions CE, 2006).

5

2 THEORY “Too often, video game interfaces are an afterthought. Sufficient time is not scheduled for interface design because too many project managers assume anyone can whip up an interface….” (Fox, 2005, p. 1). In this chapter there are four main parts. First of all there are reviews of how 3D is used in interfaces and of a few interesting games that are innovative in their menu usage. Second is a chapter presenting UI theory regarding 2D menus with bits and pieces from the field, followed by a chapter on game design theory. Last is a chapter uniting the three first chapters through looking at how 2D menu theory can be applied to 3D menu design. The material in this chapter has mainly been collected from books, games and articles written by people in the UI or game industry. Some articles, mainly from the virtual reality and virtual world research area, were found in the Association for Computing Machinery Digital Library (ACM DL) and could be used in this study. The research articles in the menu research field that were found were often very specialized in highly specific interaction methods which are of no importance to this study. Subsequently only very few research articles from the menu field are taken into consideration in this thesis.

2.1. 3D menus Looking at and testing 3D menus require that similar features have been studied. Below are descriptions of how 3D currently is used in interfaces and how some games on the market have used interesting menu solutions.

2.1.1 3D in interfaces Contemporary 2D menus often include elements that are in 3D; either they are prerendered 3D or they are real-time 3D. In pre-rendered 3D a 3D object is used in a 3D program to create the 2D artwork. In real-time 3D the actual 3D object is used in the interface and the camera can move around and provide different view angles of the 3D object. This technology is common in so called “player editors” (see figure 6) which is where the look or other attributes of the character can be changed. In this approach the 3D model is drawn on top of the 2D interface (Fox, 2005).

Figure 6. Screenshot from the Tiger Woods PG A Tour 2007 character customization interface or “player editor” (Aaron, 2006).

6

Incorporating 3D in 2D interfaces can be very expensive and time-consuming and can create more unanticipated problems than a regular 2D interface would (Fox, 2005). Geometry and textures for the 3D objects can take a long time to build, why it is highly important to spend a fair amount of time on planning and making solid concept designs (Fox, 2005). Another disadvantage with having 3D objects in the interface is that it will be unclear exactly how the interface will look until everything, including the 3D objects that will go in the interface, works in the game engine (Fox, 2005).

2.1.2 Games using the world There are however games that, instead of taking some of the game to the menu, instead takes some of the menu to the game. The following four games all have some interaction in the game world that is typically found in a menu. The games run on different platforms; PC, PlayStation 2 (PS2) and Nintendo DS (DS). Planetside Planetside (PC) is sometimes referred to as a massively multiplayer online first person shooter or an MMO FPS. It was released in 2003 by Sony Online Entertainment and was something as unusual as an FPS with a monthly subscription fee (Park, 2003). The game offered a multiplayer environment, before the player joined the actual game, that let players practice shooting and using vehicles inside different buildings in the pregame world. The unusual and interesting aspect here is that Planetside provided access to for instance tutorial and practice range content through a 3D environment instead of through a 2D menu (Planetside, 2003). This was done through an environment, an open field in the 3D world, with different large buildings that could be entered. Inside the buildings there was for example a test driving room where the flying vehicles in the game could be tested. The environment is however very extensive and created to have room for many simultaneous players, but when tested more than three years after the game was released the pre-game environment was almost empty and felt deserted and may therefore not be such a great design after all. Vietcong Vietcong (PC) is an FPS with both singleplayer and multiplayer modes released in 2003 by Pterodon (Kasavin, 2003). It has, just as Planetside, an interesting way of giving access to some of the tutorials. The player can, in a singleplayer environment, walk around in a camp and speak to different characters. Equipment can be picked up and tested in the 3D world, hence the tutorials in this part of the game are not accessed through a 2D menu (Vietcong, 2003). Grand Theft Auto – San Andreas In Grand Theft Auto – San Andreas (PS2), or simply G TA – San Andreas, the player is mostly involved in gang shootings, car theft, tag raids and other violent or illegal activities, for which the developers, Rockstar North, has gotten a lot of criticism but also a lot of attention (Gerstmann, 2004). In the game description the game is a “modern action adventure” game set in a 3D environment (Gerstmann, 2004).

7

From the UI and menu perspective the game presents some interesting ideas. Making changes to the character is done in 2D, but menus of that kind are accessed from different places in the actual 3D game. The player goes to the barber shop to access the menu where different hair-dos and beards are available and goes to the garage to get the car repainted. Food is bought and eaten in different restaurants (see figure 7) and clothes are changed in a room in the character’s house, using small 2D menus. In the house one even more interesting action can take place: the character can walk up to a floppy disk, the size of modern PC-screen, that is hanging freely in one of the rooms, and this is will save the game. The restaurant and the barber shop brings 2D menus to the actual game world, but the floppy disk situated in the 3D world takes the idea one step further, which is interesting when studying 3D menus. Figure 7. A small 2D menu distributed in the game world, from G TA – San Anreas (2005).

Animal Crossing – Wild world Animal Crossing – Wild World (DS) is a very different game compared to the three games mentioned above. It is a virtual life game by Nintendo and was released in 2005 (Navarro, 2005). The player controls a character which moves around in a world full of characters and things to collect, grow, buy and sell, to mention a few. This game has above all one feature that is interesting in the context of this report. The game can be saved by walking up to the character’s bed in the house in the game world. The player is then asked a question “ Do you want to quit playing for now” and can choose a suitable answer. If “save and end” is selected as an answer the character lies down in the bed and the game is saved. To start the game, the player selects which of the sleeping avatars he or she wants to wake up and play with. Here a traditional 2D menu option has, as in G TA – San Andreas, been moved into the game world (Animal Crossing – Wild World, 2005).

2.2. GUI theories There are numerous theories popular within User Interface (UI) design and Graphical UI (GUI) design. I have chosen a few of them that apply to game menu design as well as to other forms of UI design, or that can be used to highlight differences between 2D and 3D navigation.

2.2.1 Usability Definition The International Organization for Standardization (ISO) has developed a definition for how software can be evaluated in terms of usability. The ISO-definition, called ISO 9241-11, suggests that evaluation should be performed with respect to the following three measures: effectiveness (accuracy and completeness of users achieving set goals), efficiency (the resources expended to complete goals) and satisfaction (the users’ attitude) (Federoff, 2002). 8

The major difference between software in general and computer games is that we use computer games for fun. Therefore one can argue that the satisfaction is the most important factor, since a computer game is no fun if we get it right (effectiveness) the first time (efficiency). However, one should keep in mind that these measures can be used for different aspects of the game even though they might not be met by the game in general. If we go down into detail we still want all aspects of the game to be effective, efficient and satisfying. As Pardew expresses it (2004) “… you don’t want to make it hard for a player to figure out what to do, but you do want to make it somewhat hard for him to actually do it. If the game is too easy to play, it won’t be satisfying. So, you have to straddle a fine line between ‘too hard’ and ‘too easy’.” This also means that when the player wants to perform something, this should be done in an effective, efficient and satisfying way.

2.2.2 Interface objectives When looking at how to create a good menu system for a game, the following ten user interface objectives first stated in the 1990 paper “Heuristic Analysis” by Molich and Nielsen, and later refined by Nielsen and Mack, can be used (Ahearn, 2001). These interface objectives can therefore be used to compare if the 3D environment can live up to the quality standards that can be expected from good traditional 2D menus. 1. Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. 2. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. 3. User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. 4. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. 5. Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. 6. Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. 9

7. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. 8. Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. 9. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. 10. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

2.2.3 Fitts’ Law Fitts’ law states that " The time required to acquire a target is a function of distance to the target and its size." (Fitts, 1954). Time = a + b log2 ( D / S +1 ) D is the distance between the starting point of the cursor and the object. S is the width of the object in the direction of the cursor movement, while a and b are empirical constants (Galitz, 2002)

The equation above, one of the common mathematical formulations to describe the law, might not immediately describe how it works, but Harris (2006) describes Fitts’ law as follows: “Fitts’ law can be used when placing and designing the size and shape of interactive objects in 2D interfaces”. An example of what the law says is that small objects located close to the cursor can be acquired fast while it would take longer to acquire the same object if it was further away from the cursor. In the same way a large object far from the cursor is faster to hit than a small one placed there. When designing a 2D menu, having Fitt’s law in mind is important since it generally is good to have a menu that can be used fast, to avoid user frustration.

2.2.4 Information load The amount of information displayed on a page in a 2D user interface should not exceed 25 % density, which means that no more than 25 % of the screen should contain information for the user. It is also important that no part of the screen contains too much information in a small area. Therefore the local density, the density in a small area on the screen, should not exceed 30% (Galitz, 2002). This research is based on text-based screens, why the numbers might be slightly different if the information appears in boxes or on buttons in a graphical user interface (Galitz, 2002). 10

For menu design this brings that a menu page should not contain, for example, 40 buttons, even if the 40 buttons actually do fit on the screen. Every menu page needs to have a good relation between information and space, which limits how much information there can be in every menu screen.

2.2.5 Feedback When users work with computer systems they need good feedback to confirm the actions they perform. Some general ideas and guidelines about this are presented by Sánchez-Crespo Dalmau in his Article “Learn Faster to Play Better: How to Shorten the Learning Cycle” published in Gamasutra (1999). For any action we expect immediate feedback. This feedback should appear no later than 0,05 seconds after the action is performed. For actions that take the system a bit longer, for example 2 or 3 seconds, there should be visual feedback, for example a cursor animation, to inform the user that something is being handled. For actions that take even longer it is appropriate to provide some kind of message when the action is performed, because the user might forget that something was being performed by the system (Sánchez-Crespo Dalmau, 1999).

2.2.6 Novice to experienced users Novice users of a system require more feedback from the system than an experienced user does. The following statements are advice for when designing a system for novice users: • • •

All initiatives should come from the computer – since the user will not know what can be done with the system. User decisions should be made from a small set of options – to avoid that the user may feel overwhelmed by the size of the system. All system messages should be clear – so that the user will not get puzzled by what the message means. The novice user does not always need to know what is going on in detail.

Expert users on the other hand will give rapid responses and they organize their knowledge of the system “according to a higher conceptual structure” than novice users. Expert users will typically search for and use short ways of achieving what they want. They often use accelerators, for example keyboard shortcuts, to speed up interaction with the system (Faulkner, 1998). To make both novice and experienced users comfortable in and satisfied with a game menu, both groups’ demands need to be taken into consideration. The menu should provide appropriate amounts of information in each screen, but the experienced user should be able to find keyboard shortcuts to accelerate menu usage. It should always be clear to the user what needs to be done and the system messages should, at least for functions accessed by novice users, always be expressed in general terms so that the user does not get confused.

11

2.3. Game design theory This chapter consists of both theory expressed in books and articles, but also from studying a broad variety of recent games where information has been retrieved from different games during 2006 and 2007.

2.3.1 Constructing 3D game worlds All computer games, independent of size, takes place in some sort of world, visual or not, and game settings are almost always implemented in some sort of physical space (Rollings & Adams, 2003). New players seem to put more importance into the look of the virtual world in contrast to more experienced players, who are more concerned with other features (Bartle, 2003). When constructing a 3D game world, curved surfaces are often avoided because they are expensive since they are constituted by a lot of polygons, while rectilinear ones do not. This leaves many 3D worlds looking sparse and sterile because the game could not fit enough natural objects and the number of objects constitutes a limitation for the game world. In 2D games the primary limitation is variety since the space is displayed like an image and it is expensive to create many images that are rich in detail (Adams, 2003). Familiarity and game world metaphors are important in game world construction. Familiar locations are important because they provide cues to what is to be found there, and game world metaphors can be a convenient way of communicating familiarity to the player. It is important to not misuse the players trust in familiarity, through for example not following real world conventions, since that would be violating the players’ expectations (Adams, 2003). When constructing a game world it is also important to not make the mistake of “falling in love with realism at the expense of functionality” as expressed by Amy Jo Kim (1998). She explains how Origin, a game developer, made this classic first-timeworld-builder mistake when designing the chat system for their 3D online game “Ultima Online”. The users criticised the chat design because it lacked many features common in online chat applications and as a result the in-game chat was rejected in favour of stand-alone chat applications such as ICQ (Kim, 1998). On the other hand, realism can bring great value to a game world as long as it does not decrease the functionality. Fraser and Fisher (1998) discuss intelligent virtual worlds and stress that a challenge for the developers is to create unpredictable and rich worlds in terms of interconnected processes. The world should be highly responsive to the user, rather than indifferent. When 3D objects in 2D menus were discussed earlier in this chapter the time factor was mentioned; 3D objects are time consuming to build. When it comes to actual games and game worlds this brings that it is significantly more time consuming to bring a computer game from concept to finished product when the game is situated in a 3D world compared with in 2D. This is partly because new demands are placed on textures, lighting and animations. The fact that the environment is so time consuming to build can generate other problems for the developer such as reluctance towards rejecting designs that after implementation do not live up to the game design goals. 12

This might occur if the project managers get attached to a feature implementation not because it is very good but because of the time and money already spent on this development (Hague, 2000). The size of the game world and the number and type of players in it are also factors that need to be carefully planned. How a world is perceived depends on how it is populated, described in great detail in Bartle’s “Designing Virtual Worlds” (2003) why the world size in relation to the number simultaneous inhabitants should be carefully tested. If the number of simultaneous players on a game server is large that can in turn cause problems regarding network bandwidth (Das et al., 1997). The size of the game world needs to be limited since the game world is not infinite. This is often achieved through using world objects as physical boundaries that the player cannot pass, such as an unclimbable cliffs or an impassable forest (Bartle, 2003). These rules that seem to apply to game world design makes some of the differences between 2D menus and 3D worlds clear. 2D menu screens can be highly detailed and made graphically interesting with shapes of any kind, but the different menu screens usually look very much the same since textures are expensive to make. Different areas in the 3D worlds, on the other hand, can have endless variations, but each object in the world must be rather simple and angular. It is also desirable to use concepts familiar to the user, but this is valid in both 3D worlds and 2D menus. Making the 3D world too realistic should be more of a problem in 3D menus since 2D menus do not have a real world equivalence to live up to. The need for the menu to be unpredictable should also only apply to 3D menus since the 2D menu is not a world in the same sense as the 3D equivalence. The time aspect is important when looking at 3D menus. If making the menu is considerably slower than making a 2D menu the value from making it in 3D must be larger than it would have to be if they took equally long time to produce. However the difference in time spent on the two interfaces should not have to be very large since the majority of the items in the 3D menu should be reused from the actual game world. The size of game world, number of simultaneous players and the boundaries of the game world are things that need to be thought over when constructing a 3D menu, but does not pose any problems when constructing a 2D menu.

2.3.2 Starting the game When a game is started for the first time the player must be actively engaged in the game within 15 minutes or he or she might not become as interested in the game as if this criteria was met (Shelley, 2001). There are three important factors that a game should have to get the player into the game in a satisfying way: • An interesting starting situation • Minimal barriers to entry (interface or back-story) • A few decisions for the player to make initially If these factors are met by the game the player can get absorbed into the game and have fun without any frustration (Shelley, 2001). One game that has implemented an interesting solution regarding the start-up situation is NBA Live 07. When the game starts the camera shows a basketball practice gym where a basketball player and a ball are found. The player can immediately take control of the player and start practicing 13

dribbling, long shots and slam dunks. To play the real NBA game the game’s 2D menu is brought up on top of the gym which becomes the menu background, and a match can be set up. When the game is loading the user can once again use the character and practice and when the level is loaded the camera slides through the wall of the gym and down to the basketball stadium. This game start is rather unique and should certainly be sufficient to make the game avoid the typical game menu pitfalls that can stop the player from initially committing to the game. The game offers an interesting starting situation, has minimal barriers to entry and lets the player try the game hands on immediately after start-up. Another criterion, of technical nature, that applies to the start of a 3D game is the video setting option and its availability. This has to do with monitor and other hardware settings. To quote Karl Emdin (2007), a Software Engineer at DICE: ”There are some technical issues that make it unsuitable to change video settings while at the same time drawing a complex world. Some settings require the rendering to be reinitialized and the screen to turn black, others can degrade the performance of the application substantially, making it very hard to interact with the world while changing them. It is even possible that the user adjusts the settings so that the world cannot be drawn at all, making it virtually impossible to restore them”. This reasoning gives that video settings should be accessed from 2D and not only from 3D.

2.3.3 Game interfaces The game interface has two primary goals, which both let the player communicate with the game. The primary goals are: “feedback (receiving information from the game) and control (providing information to the game)” according to Saunders and Novak (2007). A secondary goal is to add to the game’s immersion. If a game is immersive it captures the player and makes him or her almost forget that they are playing a game. It is not easy to design the game interface so that the interface itself makes the game feel more immersive. However a poor game interface can break the immersion that the game already provides. Saunders and Novak states that a poorly designed interface easily can break the immersion of the game (2007). In applications other than games, such as word processors, the application and the interface are perceived as a package, but game menus can often be perceived as something you have to go through on your way to the game world. In the perfect scenario this should not have to be the case (Ahearn, 2001). According to these opinions it would be preferable if game menus become less apparent and stand out less from the game world.

2.3.4 Gamer types Several different strategies to how to categorize gamers can be found in the game research literature. One commonly referenced way of categorizing gamers, is by dividing them into “Achievers”, “Socializes”, “Explorers” and “Killers”, as stated by Bartle (Alix, 2005; Bartle, 2003; Rollings & Adams, 2003). The four categories are divided into two main groups: the ones who enjoy acting on other players or the game environment, and the ones that enjoy acting with other players or the game environment. With “acting on” Bartle means manipulating, exploiting or controlling, and it is used by “ Killers”, who act on other players and want to dominate others, and by “Achievers”, who act on the world and like doing things that help them achieve 14

defined goals. With “acting with” he means learning about and communicating with, and it is used by “Socializers”, who act with other players and socialize as themselves or through a role, and “ Explorers”, who act with the world and whose joy is discovery and seeking out the new (Bartle, 2003). Bartle’s player type categorization was created as a means of categorizing Multiple-User Dungeon (MUD) players, but has proved to be applicable to other game types as well. MUD was also the original name for what today is called “virtual worlds” (Bartle, 2003). The categorization takes into consideration what people think is fun in virtual worlds, and has been successfully applied to players in a vide variety of virtual worlds (Bartle, 2003). Another way of categorizing the gamers, using four categories, is by dividing them into “Warriors”, prioritizing weapons, technology and combat, “Narrators” who favors plot, characters and exploration, “Strategists”, who prefer challenging gameplay and being forced to think a lot, and “Interactors”, who prioritize competing and cooperating with other players (Alix, 2005). The four categories were developed as an alternative to Bartle’s (2003) gamer types. Alix (2005) suggests that these four types can be used to categorize gamers, but also stresses that gamers generally are comprised from several or all four of the gamer types. The gamer types can be used in game design: “Which player type does the majority of our target group belong to? Explorers? O K, let’s make a large game world with endless exploration possibilities…”. The types can also be used in high level game design where decisions could be made about which kind of menu the game should have. If the developer wants many “Interactors” to play the game, then maybe chatting should be supported both in the game world as well as in the game menu?

2.3.5 Online games Playing online games went from a small scale fraction of the game industry to a large and popular industry between 1995 and 2002 (Rollings and Adams, 2003). One of the large benefits with online playing is the possibility to socialize with other players, and to construct good game environments for socializing the game designer must become somewhat of a social architect. Players in online multiplayer games can experience competitive gameplay, cooperative gameplay or team based gameplay (Rollings & Adams, 2003). Technically, however, online multiplayer games pose a number of problems or difficulties such as hosting issues, delay times and loss of data in the connection (Rollings & Adams, 2003).

2.3.6 Game design today When looking at modern 3D PC games a number of design trends are clearly apparent. The following design trends are commonly observed: Trends 1. Online multiplayer sessions – Playing over the Internet is almost a standard alternative today even if singleplayer game sessions are also common. In online play, gamers can for example compete, cooperate, socialize or help each other. 15

2. 3. 4.

5.

Experienced players helping beginners to pick up the game play is common, especially in MMORPGs. In-game chat – The game provides possibilities to chat to other players. Some games feature messaging to a whole team or group, while other games provide the possibility to engage in private conversations between players. In-game friends – The players can become “friends” with other players and through doing this they can easily see when their friends are playing the game. Being friends can often simplify playing together on the same game server. In-game grouping – Players can join temporary or more permanent groups in games. These groups can be for playing together or otherwise helping each other within the game. If a game provides grouping it helps strengthen social bonds and can increase the players’ loyalty to the game (Sellers, 2002). Players helping one another is common outside groups as well (Sellers, 2002). Game lobbies – Games can provide a possibility to wait for other players or simply socialize with other players through chatting before joining a game (Calicia, 1998). This feature, often provided in 2D, is called a game lobby and is getting increasingly common. In 2006 it had become so commonly used that a company launched an advertisement solution designed to be implemented in game lobbies (Dobson, 2006).

Game design and HCI Even though both development of electronic games and human-computer interaction (HCI) research have been around for a number of decades it has taken quite some time before they were combined, but now the interaction between the two fields seems to have begun (Helms Jørgensen, 2004). However, much is still to be done and here is how the highly experienced game designer Ernest Adams explains the situation: “I’ve been working for a major game developing company for 8 years and I’ve never seen a methodologically sound study of who the players are … game design is based on common wisdom and guesses – designers build games for themselves” (Helms Jørgensen, 2004).

2.3.7 Psychological responses What is listed above all helps to describe how good design is achieved. Below are some of the psychological responses that the user may experience when exposed to bad design, listed by Galitz (2002): • Confusion • Annoyance • Frustration • Panic or stress • Boredom These psychological responses are all very negative and the menu should not cause any of these emotions. Because of this it is of the highest importance that guidelines for creating good UI design are studied and followed. If the menu does not cause any of these emotions it does not however automatically bring that the design is good; the design can simply be average. Therefore making sure that these psychological responses do not appear is not enough to ensure the evaluated design is good: the users should in other ways express their positive responses to the evaluated design. 16

2.4. 3D menus meets UI theory This study is to a large extent a user study including tests and a survey. The goal of this study is to evaluate both the users attitudes towards 3D menus, but also to look at how the 3D menu idea stands when UI theories are applied to the solution. This is important since game interfaces should be evaluated with respect to the same interface measures as other UIs, stated in the usability ISO definition. In the following chapter 3D menus will be looked at in relation to 2D interface and menu theories.

2.4.1 3D in menus One of the few aspects on 3D in menus that can be found is that incorporating 3D objects in the interface can be complicated since it is unclear exactly how it will look until the actual game is done. This is even more true if a 3D menu is to be made. The actual game will need to be working and all the objects that are to be used in the menu, which are hopefully objects from the actual game, may not be done early in the menu development process either. This can make it hard to get a good view of the 3D menu before the game works properly.

2.4.2 2D menu theory Below follows a couple of aspects that are commonly worked with in 2D menu design. They are looked at from a perspective where both demands on 2D menus and 3D menus are discussed. The time aspect One problem with the 3D menu observed in this study is that it can be slower to use than a 2D menu. However, a 2D interface follows a number of technical and logical rules that does not apply to the 3D environment. The 2D interface can fit many options in one screen but filling the screen with a lot of content and options makes the menu hard to use (Galitz, 2002). If all clickable options are small they will take longer to acquire with the cursor, according to Fitt’s law, and that will make usage slow. If less information it put on every screen the menu interface will contain more screens which will require more navigating with can give the menu a longer learning curve. If more content and options are put in a 3D world it does not affect navigation in the same way because the 3D menu per definition is more intuitive to navigate in, and because there is a 360 degree view to be seen if the character can turn around. Interface objectives Four out of the ten interface objectives by Nielsen (2005) bring up a number of aspects that can be applied to 2D versus 3D menu design. The remaining seven objectives are interesting and worth considering, but they do not point out any differences between 2D and 3D menu design, why they are not further discussed in this report. Nielsen’s second interface objective deals with the “Match between system and the real world” where it is suggested that words, phrases and concepts familiar to the user should be used. Real-world conventions should be followed and system-oriented terms should be avoided (Nielsen, 2005). Pardew (2004) has similar opinions stating the following: sometimes there are no clear standards for how something in the game or game interface should work. Then trying to come close to how the real world works 17

can be very useful. This will make the learning curve shorter since the player can guess how to perform the action (Pardew, 2004). Avoiding system-oriented terms and coming close to how the real world works is clearly easier to accomplish if the interface is a 3D world. Instead of using complicated option and sub-option names, objects and environments familiar to the player can be used. The fourth interface objective brings up the similar question of consistency and standards. It suggests that the user should not have to wonder if different words, situations or actions mean the same thing. But even if the importance of using the right words is stressed here, the 2D menu can be considered to have a small advantage in this matter. Even if there may be little confusion over what real world objects do it doesn’t follow the PC game genre standards to provide the options in 3D. Gamers are probably very familiar with that “video settings” usually will control the resolution of your monitor, but will they be as sure about what will happen when they walk up to a video set in a 3D environment? There are no conventions for how a 3D menu should be designed, why the 3D menu right now cannot follow interface objective four, while the 2D menu can. However, interface standards have not always evolved from something that is logical and intuitive but simply from a solution that happened to be implemented in a game that became very popular. Insisting on following genre conventions in menus can therefore make the games less and less intuitive. The sixth interface objective discusses that the interface should minimize the memory load the user has to deal with; things should be visible instead of memorized (Nielsen, 2005). This statement is strongly supported by Galitz (2002) who explains that human beings usually can recall 2000-3000 words, but can recognize up to 100 000 words. It is also thoroughly discussed in “The Design of Everyday Things” by Norman (1988) where he recommends providing knowledge in the world; visual cues, instead of forcing the user to have knowledge in the head; memorizing how things work. Here the 3D menu has a great advantage since it can show things without forcing the user into sub-categories as in a 2D menu. The eighth interface objective states that interface design can gain from being minimalist. Here the 2D menu has a problem in that it can take a lot of words to explain something that can be clear to the user if in a 3D world. According to Galitz (2002) information load guidelines a 2D interface should not contain more than 25 % information, which is probably very unusual in PC menus which are known for being information heavy. Feedback Feedback to the user is especially important when the actions take more than a split second. This can be achieved in the 3D world through object animations. This can however be more expensive in a 3D world compared to in a 2D interface, because 3D animations are expensive to make.

18

3 METHOD CHAPTER The methods used in this study will be described below. The method chapter is divided into three parts; the “method theory” part where general theories are explained, the “method description” part where the methods used in this study are motivated and finally the “implementation” part where it is described how the methods were used.

3.1. Method theory 3.1.1 Recruiting participants When test participants are to be gathered and convinced to participate in a test it is recommended to explain the nature of the research to potential participants (Rubin 1994). According to Nielsen (2000) the optimum number of test users when evaluating usability in interface design is five. When five participants are used 85 % of the problems in the interface design will be found (see graph 1). The graph below shows the equation N(1-(1-L)n), where N is the total number of usability problems, n is the number of users and L is the proportion of usability problems found when testing one user. In the graph the L value is set to 31 %, which is a typical value for this factor (Nielsen, 2000). Graph 1

Graph 1. The relation between usability problems found as a function of the number of test users (Nielsen, 2000).

3.1.2 Prototyping Prototypes are used to gather information from users about a design so that feedback can be given to the designer and they are particularly useful in the early stages of the design phase. The primary goal of using prototypes is to communicate opinions from the users and having high accuracy or thoroughness is not prioritized (Galitz, 2002). The prototype is a simulation of an actual system and can be a rough approximation or more detailed and can allow user interaction. A key characteristic for a prototype is that it can be rapidly changed as the prototype testing is performed (Galitz, 2002). 19

Paper prototyping is suitable to use early in the design process because a paper prototype can be assembled without large time or money investments (Galitz, 2002; Shelley, 2001; Shneiderman & Plaisant, 2005). A paper prototype, which is a lowfidelity prototype, requires no programming and is easily modified and iterated on. Their look and feel is generally so far from the real system that the participants using the prototype easily understand that the design is not final (Galitz, 2002). On the other hand their large differences from the final system can make them difficult to understand and testing them often requires a large portion of imagination (Galitz, 2002). Computer-based prototyping can on the other hand help giving the users a good impression of what the finished design will look like. The prototype, a medium-fidelity to high-fidelity prototype, can however deceive the user into believing that the design is somewhat final, which may prohibit good design suggestions from being expressed by the user. They are also much more expensive and time consuming to develop and change than paper prototypes are (Galitz, 2002). The test material When user tests are to be conducted it is imperative that the test material, such as the questionnaires and the task scenarios are carefully prepared (Rubin, 1994). Some of the commonly used questionnaires are the screening questionnaire, the background questionnaire, the pre-test questionnaire and the post-test questionnaire (Rubin, 1994). The screening questionnaire is used to select participants for the user test. The questionnaire should ensure that the users being tested are in fact members of the product’s target group (Rubin, 1994). The background questionnaire consists of a set of questions that the test participants often get to answer just prior to the test. It is used to collect historical information about the participants as well as data that may affect the user performance in the test. The questions can address areas such as previous knowledge, attitude towards or preferences within the topic of the test (Rubin, 1994). The pre-test questionnaire is also used just prior to the test, but the questions deal more directly with things concerning the product or interface that is being tested. It can include questions about the product being used, such as “ Does it look easy to use?” It can also be used to group participants according to level of expertise within the subject of the test (Rubin, 1994). The post-test questionnaire is handed out after the test and is used to gather information about things that cannot easily be observed during the test. Performance-related questions should not be asked in the post-test questionnaire (Rubin, 1994). The task scenarios, another form of written test material, should describe what the participant is expected to do during the test, as well as the end results that the participant will be encouraged to reach. Realistic scenarios should be provided to help the participant to “stay in role” which can be useful to keep the participant motivated. The scenarios can either be given to the participant in written form, or read to the participant. They can be given to the participant on one occasion or distributed over a period of time so that the participant does not get distracted or intimidated. (Rubin, 1994)

20

The testing The traditional way to test a product or interface is to have a test monitor present either in the same room as the test participant, or through an observation channel such as behind a semi-reflecting mirror or with a video connection from the test room. It is however possible to collect preference data from many users simultaneously, without having test monitors, using what is called a “self-reporting methodology”. This methodology can be used to retrieve data from a large number of participants and is based on that the user is given a questionnaire through which he or she can leave feedback on the test and the product being tested (Rubin, 1994). When user tests are conducted all test participants should receive the same information about the test session right before the test starts. The information is given to make the participants at ease and can describe what will happen during the test session and should clearly state that the product is being tested; not the user. It should, however, be clarified to the user what he or she is expected to do during the test. The information should be kept brief, since the test participant is unlikely to be able to assimilate large amounts of information. The users should be encouraged to ask questions (Rubin, 1994). When it comes to testing a feature or idea it is vital keep in mind that something that generates good feedback from the test participants might still not be suitable for the interface design at hand. When a user is presented to the feature it might look impressive or neat, but as the system is being used over time the feature may be found to have little or no value (Galitz, 2002).

3.1.3 Survey through questionnaire In the chapters above questionnaires are used before, during and after testing to retrieve information from users. When evaluating a system or interface questionnaires can however be used separately, without being used for testing, as a means of collecting attitudes from users (Faulkner, 1998). Surveys can be used to understand preferences of broad base of users. It can be used both for existing and potential products and you can generalize data from a larger population than what would be possible if you did for example interviews. It is often used in the early stages of production to get a good picture of the potential user. One of the most important aspects of writing a survey is that the language must be very clear so that different interpretations do not disturb the result. This is obtained through a number of tests and iterations on the written survey questions (Rubin, 1994). The questionnaire When using any form of written questionnaire to obtain information from users it is highly important that the questionnaire is thoroughly worked through and has been iterated on (Faulkner, 1998; Rubin, 1994; Shneiderman & Plaisant, 2005). The structure of the questionnaire is important (Faulkner, 1998; Rubin, 1994) and the questions should be ordered so that the more general ones are placed before the more specific ones (Faulkner, 1998). Self-administrated questionnaires leave the user completely dependent on what the test designer has written since the user has no possibility to ask anyone about details in the questions. Therefore a pilot test of the questionnaire is of the outmost importance (Faulkner, 1998; Rubin, 1994). 21

Close-ended questions, such as questions with check-box or scale answers, are sometimes recommended over open-ended questions where the participants write answers in their own words (Faulkner 1998; Rubin, 1994). Using close-ended questions both decreases the time it takes for the participant to complete the questionnaire, as well as the time it takes to compile and analyze the data from the questionnaires (Faulkner, 1998; Rubin, 1994). Open-ended questions can however generate answers that provide information on a broader basis, since the user can express his or her opinions in a more accurate way (Faulkner, 1998). Close-ended questions can have the answers distributed on a Likert scale, which is a scale through which the participant registers his or her agreement or disagreement with a statement (Rubin, 1994). It is common to have a seven point scale with the middle option being the neutral choice (Faulkner, 1998; Rubin, 1994). Other ways to restraint the length or diversity of the participant’s answers is to provide checkboxes or fill-in questions, where a very limited space is left for the written answer (Rubin, 1994).

3.1.4 Data analysis Quantitative data can be analyzed through different statistical tests. One of them is the Analysis of variance test (AN O VA test), which can be used to see if there is any difference between groups regarding a variable (Sallnäs, 2006). The AN OVA test takes data from several data sets and returns an F-value and a p-value. A low p-value indicates that there is a significant difference between the different sets of data. A Fvalue close to 1 indicates that there are no differences between the two groups, while a value far from 1 indicates the opposite. When a hypothesis is to be tested a significance level (α) of 0,05 is often chosen. This means that if the test that is used returns a pvalue that is smaller than 0,05 the null hypothesis can be rejected and the results can be referred to as statistically significant on a significance level of 0,05. This also brings that the probability for that the perceived relation is a coincidence is less than 5 % (Kirkman, 1996).

3.1.5 User stories User stories are used as a communication method in system and software development. It is a method where stories, instead of large design documents, are written (Cohn 2004). The user story itself describes functionality that will be valuable to the user or the purchaser of the system. The story consists of three parts as described by Cohn (2004): 1. A written description of the story used for planning and as a reminder. 2. Conversations about the story that serve to flesh out the details of the story. 3. Tests that convey and document details and that can be used to determine when a story is complete. This is an example of a typical user story: User story: “As a player I want to be able to read the game instructions on a sign.” Tests: “Verify that there is a physical sign with instructions written on it.” “Verify that the text can be read by several players at the same time if they are close to the sign.” “Verify that the text can be changed between sessions.” 22

3.2. Method description The following main methods, further described below, were used in this study:

3.2.1 Assumptions When a study of this kind is conducted it is extremely difficult to test all aspects of the problem. For the testing, a finite scope had to be decided on, and the following approach was taken. A 3D menu with as many popular game design features as possible was tested. The following features and conditions were implemented in the prototypes: Multiplayer:

The participants were in the same 3D world menu as other players. They were in a multiplayer session of the 3D menu.

Chat:

Players could chat with other players through both open and private messages.

Friends:

The participants could make friends with the other players that were in the 3D menu.

Grouping:

The participants could create, join and leave groups.

Lobby functionality:

The participants could together or alone join game sessions from the 3D menu.

To decide to go with this approach, a number of assumptions were made: If the test participants do not like the 3D menu, there is a rather high probability that it would not be liked by users if it was implemented in games. If the test participants do like the 3D menu, further tests can be made with more scaled down versions of the 3D menu to see if it would still appeal to the gamers. To complement the study with the large scale 3D menu, questions were asked in the questionnaire about the idea with a 3D menu, without mentioning details such as the ones listed above. In the questionnaire the direct concept of a 3D menu was discussed.

3.2.2 Recruiting participants The users involved in testing and questionnaire answering should all belong to the target group for the final product according to the statements above. Since this study looks at games where the player is in a 3D world, but from no specific game genre, the target group is quite broad. All gamers who can imagine playing a 3D game can be considered belonging to the target group. According to a large yearly study conducted by the Entertainment Software Association (ESA) the average American game player is 33 years old. Nearly 50 % of the gamers are 18-49 years old, and the remaining 50 % are almost evenly divided between the age categories below 18 and above 50 (ESA, 2007). The users that were involved in testing and questionnaire answering in this study are all employees at DICE. This was a requirement from DICE since there was other sensitive material in the test world. This is not optimal according to the 23

recommendations about which users to use for tests, since they are a somewhat homogenous group in terms of where they live and choice of career. It should be emphasized however that the respondents held different positions within the company and were designers, programmers and artist as well as office assistants. It is however not only negative to have all participants working for DICE. That they are all employees at DICE results in that they all work with computers every day. They range from fairly to extremely familiar with computer games. These facts ruled out the need for an initial screening questionnaire, suggested by Rubin (1994), to choose participants.

3.2.3 Prototyping When preparing a prototype design there are naturally a lot of design decisions to be made. Since the 3D menu solution is evaluated as a possible alternative to traditional 2D menus I believe it should be tested as it possibly could be used in future menu design. Therefore all five game design trends listed earlier in this report was taken into consideration and also implemented in the programmed prototype. The five game design trends stated that the following features are common in contemporary PC game design: 1. Online multiplayer sessions 2. In-game chat 3. In-game friends 4. In-game grouping 5. Game lobbies To test the ideas examined in this thesis, prototype tests were conducted to gather opinions from users. The prototypes all contained representations of a 3D world where settings could be made. All tests were conducted with all participants simultaneously in the same 3D world. This was done to test the functionality and feeling of a 3D menu while the player is not alone in the 3D world. I designed and tested the parts of the paper and computer based prototype that had to do with 3D menus and settings in the 3D world. Sara Jansson, who did her Master’s project (2007) on social aspects of 3D environments, designed and tested other parts of the prototypes for her project. Paper prototyping The main goal of the paper prototyping in this study was to test aspects such as size and distances between the different parts of the 3D environment. It was important to do this before the implementation of the 3D environment began, because making changes to the paper prototype is quicker and easier than making them to the 3D environment. The first paper prototype test, with three participants, was the pilot study. The second paper prototype test was the main test with five participants, as recommended by Nielsen (2000). Questionnaires were used together with the paper prototype to get some first opinions on the concept of a 3D environment that provided what is usually presented to the user in a 2D menu. The background questionnaire and the pre-test questionnaire were combined into one rather extensive questionnaire handed out to the participants before the paper prototype test. A post-test questionnaire was used to gather information from the users after the tests. 24

Computer based prototyping The computer based prototype was implemented according to the original design but with design changes made according to the results from the paper prototype tests. The programming of the computer based prototype was done by programmers at DICE. When changes were to be made to the programmed prototype, due to results from the prototype tests, they needed to be communicated between the prototype designer and the programmer in a clear and effective way. To obtain this way of communication user stories were used. This communication method was introduced and tried at DICE during the time when the computer based prototyping was conducted. They suited the purpose very well why they were used within this project. Questionnaires were used before and after the programmed prototype in the same way as with the paper prototype.

3.2.4 Testing Since the main goal of this study is to evaluate if 3D menus can replace traditional 2D menus, it was essential to conduct prototype tests. Since many of the games situated in computer generated 3D worlds are multiplayer games, where many players from different geographical locations coexist and cooperate in the 3D world, the player tests were designed so that the participants tested the 3D menus in multiplayer sessions. This was enabled to simulate contemporary game design features such as chatting, making in-game friends, grouping and joining games together, something that is usually possible from so called game lobbies.

3.2.5 Survey through questionnaire The main reasons for using a self administrated questionnaire was that information from quite a large number of gamers was needed while the questions were straight forward enough in the sense that they did not need a lot of explanation. The purpose was to determine the attitudes and desires of the users, for which Galitz (2002) recommends using questionnaires. The goal with the questionnaire was not to come up with statistically valid numbers but rather to see tendencies within player categories. Many of the questions required comparisons between different statements. In those cases, closed questions were used. To gain more specific information about opinions, open questions were also used. This resulted in a questionnaire that to a certain extent was easily analyzed, whereas it required more work to gain useful information from other areas of the questionnaire. For some questions, alternatives were given, but an extra suggestion that the participant could formulate, was given as recommended by Faulkner (1998). The questionnaire was first tested on five participants in a so called pilot test recommended by Rubin (1994), and then adjusted based on their feedback. 40 persons answered the improved and final questionnaire. The survey questionnaire was first given out to the prototype test participants as a pre-test questionnaire before it was used as an independent survey through questionnaire.

25

Respondent subsets The answers of the survey are looked at as a whole but in some chosen questions subsets are selected and looked at. Since this study looks at a possible solution for a 3D game, the replies from participants who mainly play 3D games can be extra interesting. Two subsets were therefore selected and used when analyzing some data from the questionnaire. The players in each subset have spent many hours during the last year playing massively multiplayer online role-playing games (MMORPGs) or first person shooter games (FPSs). MMORPG is a game genre originating in role playing games (RPGs) in the strategy game genre while FPS is a genre in the action genre together with racing and fighting games (Saunders & Novak, 2007). For both being games played in 3D environment they are very different. The core of an FPS game is its camera perspective which lets the player look at the game world through the characters eyes, and that it has a fast-paced action oriented gameplay. The role-playing game (RPG) genre is characterized by that the game characters advance in power through the game, it has an emphasis on story and dialogue and that there are plenty of items for the player to find (Saunders & Novak, 2007). Because they are very different I assumed that if preferences and opinions vary between players significantly within any 3D game genres, these two genres would display that variation. Participants that considered themselves belonging to other game genres than MMORPG and FPS were unfortunately too few to constitute a subset. Only zero to two players were found belonging to each of the other game groups, why they were not looked at when data was analyzed. The same reason, too few players in each potential subset of participants, made analysis of player subsets from Alix’s player types non-rewarding. In Bartle’s system some groups were large enough to be looked at as subsets.

3.3. Implementation The core part of this project consisted in designing and testing prototypes of a 3D world which could replace a 2D menu in a 3D game, and evaluating these ideas in theory through an extensive questionnaire used in a survey.

3.3.1 Participants All recruiting of participants was made within DICE and all participation took place during working hours. Participants were recruited through e-mail or personal face to face invitations. Recruiting participants for the tests For the paper prototype tests, a handful of people were asked to participate a few days prior to the test sessions. The participants were chosen so that the tests would have participants from different positions within DICE. When the wanted number of participants had accepted the invitation the test was conducted. For the programmed prototype tests a group of approximately 15 people were invited via mail. Their availability for participation was tracked through meeting bookings in Microsoft Outlook, which prevented play-tests with too few participants. If too few people could participate the play-test was simply moved to a time when more people could.

26

Recruiting participants for the questionnaire survey Recruiting users for the questionnaire survey needed a bit more work since a rather high number of participants was wanted. The goal with the questionnaire survey was to receive 30 answers. To achieve this, an e-mail was sent out to all project and department managers at DICE, explaining the purpose of the survey and asking for permission to ask their employees if they wanted to participate and if they could do so during working hours. Approval was given from all managers but one whose team had a heavy workload at the time. An invitation to join the survey was thereafter sent out via e-mail to all members of the other teams, which added up to around 200 people. The invitation included the same brief background information that was sent to the managers, but also included the participation approvals from the managers. The invitation had information about where to find the questionnaire and when to hand it in, but also included information about that everyone writing their name on the questionnaire would be in a lottery where a secret prize could be won. Selecting subsets Two subsets were defined: one with players who play slow paced games and one with players who play fast paced games. To decide which players who play slow paced games, the amount of hours spent on the games types was looked at. Everyone who had spent the largest amount of hours on massively multiplayer online role-playing games (MMORPGs) was considered to belong to that group. To decide who belonged to the group who plays fast played games a somewhat different approach had to be taken. A typically fast paced genre is the first person shooter (FPS) genre. Since the participants were all employees at DICE, who has released many titles in the FPS genre, many hours logged in that genre does not necessarily imply that the respondent belong in the fast paced games group. Therefore the members of this group were the ones who placed FPS games first in the question “rate which game genres you like the most” and had logged the most hours in the FSP genre.

3.3.2 Prototyping The prototyping was carried out in two main steps: paper prototyping and programmed prototyping. All prototype tests were carried out as multiplayer tests; all players were in the same environment, 2D or 3D, during the play-tests. Together with the prototype tests, before and after, questionnaires were used to gather information about opinions and experiences from the test participants. Paper prototyping The work with the paper prototype was carried out quite early in the project. The prototype physically consisted of a table sized game board, with a hexagon pattern, player representations, cards used as representations for options and actions that would be represented in the user interface if this had been a programmed prototype. The board game represented a top down view of a 3D environment with five houses located around a main play field. In the houses, different settings could be changed and actions could be performed. The player could change which items he or she could use and what abilities he or she had. The paper prototype tests were set in a military context since they served as pre-study to the programmed prototype tests which were 27

to take place in an environment built with the Battlefield 2 engine. In this way, characters (soldiers) and gear (weapons and vehicles) from Battlefield 2 could be used in the programmed prototype. The paper prototype tests were held in a conference room within the DICE office. Both two play-tests proceeded in the same way. All players started out with their player representation, a small light-weight plastic ball with a cardboard name tag on top and three tooth picks as legs, located in a randomized position in the open play field between the buildings on the board game. Each of the players got to make moves when it was their turn to do so. A move consisted in the following: moving the character 1-6 steps (decided by rolling a dice in the first prototype test, decided by the player in the second play-test) in the hexagon pattern, interacting with something in the world or chatting or grouping with another player. The things that could be interacted with were: • A computer, represented by a paper hexagon with a computer symbol and located in one of the houses, through which a list of player groups and its members could be accessed. The list was in case of user-computer interaction passed to the player who could read it to find out which player was in which group. • Different weapons, each represented by a hexagon with a weapon symbol, located in a weapon house. When a user interacted with the weapon the user could choose to find out information about the weapon type or to test the weapon. Finding out information about a weapon was achieved by reading a bullet point list of weapon attributes such as which distance the weapon is preferably used from. Testing the weapon was done by rolling a dice. The score was written down by the test administrators and a high score list for each of the three available weapons was kept. • Different vehicles, represented by one or several connected hexagons with a vehicle symbol, located in the garage building. Interaction with the vehicles worked in the same way as interacting with the weapons: information collection and testing. The information provided about the vehicle was its top speed, its weight and the number of passengers it could take. Testing the vehicle worked in the same way as testing the weapons. Chatting was done through writing a message on a post-it and handing the post-it to one of the other players. Multiplayer communication could take place, in which case the message was shown to several players who could reply to all the other players in that conversation. Grouping was achieved through sending a group invitation to a player, physically a paper note with “group request” on it, which could be answered with a “accept” or a “deny” paper note from the invited player. All players had a list of goals to achieve. Goals could be “make two players join your group”, “talk to three other players and get replies from them”, “find out how fast the fastest vehicle in the garage can run” or “get and keep the highest score from shooting with the pistol” . For every goal that was achieved the player received a point and the player who had the most points when the play-test ended won. In the first prototype test three players were invited. I administrated the test together with Sara Jansson who also tested things in the prototype tests. Before the test was 28

started a pre play-test questionnaire was handed out to the participants. This was what would be handed out as the survey through questionnaire to other persons later, why it was pilot tested as a pre-test questionnaire during the first paper prototype test. It contained general gaming habit questions as well as more specific questions around the game genre. It took the participants around 20-25 minutes to fill out this questionnaire. There was also a six-page document with rules that all participants read before the test started. The actual prototype play-test lasted for about 30 minutes. After the play-test the participants got a post-test questionnaire that addressed more specific questions around the play-test and the board game. During the play-test both administrators took note of what happened. Both administrators also controlled a number of characters who did nothing but respond to actions from the other players. This made it possible to simulate the interaction players can experience with non-player characters (NPCs) in computer games. An NPC is a character that is some way looks and behaves like a player, but its behaviour has been preprogrammed by the game developer. Figure 8. A photo from the second paper prototype test.

Five players were invited to the second play-test, three of which had participated in the first play-test. This test was documented through photography with a digital camera (see figure 8) and filmed with a digital video camera. The pre play-test questionnaire from the first prototype test was refined in a number of question and answer formulations. The rule document was discussed before start of the play-test, instead of read by all participants, so that it would not be as time consuming as during the last play-test. This however resulted in some confusion during the play-test about how the game was to be played. Computer based Prototyping For the programmed prototype a pre-test and a post-test questionnaire were designed. The pre-test questionnaire consisted of general questions about the player’s general gaming habits and preferences. The pre-test questionnaire, the same as for the paper prototype tests, was later used for the survey. The post-test questionnaire collected the participants’ opinions on the prototype and the prototype test. The programmed prototype was built in the Battlefield 2 engine. Battlefield 2 is a game in the first person shooter genre, developed by DICE and released in 2005. The programmed prototype offered a 3D environment with four houses located around a main play field. The number of houses had been reduced between the paper and the programmed prototype tests since one of them, the computer settings house, was considered unnecessary since no computer settings could actually be changed from the 29

computer based prototype. The area was confined by fences and buildings so that the players could not go outside the specified test area. In the houses, different settings could be changed and actions could be performed. This was obtained through walking up to different 3D objects and pressing an “interact” key on the keyboard. Then a 2D image was displayed with which the players could interact through moving the mouse and thereby aim at different options (see figure 9). The choice was made with a left mouse click and the escape key removed the 2D interface without changing any settings. The player could through this solution select which items he or she could use and what abilities he or she had. The participants joined the programmed prototype tests from their computers at their desks. Before each play-test a link was always sent out to the participants so that the latest build could be downloaded. The prototype was changed between the different play-tests. Using user stories helped in keeping the communication with the programmers fast and simple. Thanks to the stories it was easy to see how much time that would pass between prototype tests and when the next test session could take place. Roughly three weeks passed between each of the programmed prototype tests. Below is a description of the prototype tests in general followed by some details about each programmed prototype test. In each of the programmed prototypes the following happened. The players logged into the game using nick names that were given to them before the test. Each player then controlled an unarmed 3D soldier who appeared in a 3D environment visible to all other players who were there. The players could go through a house to reach a shooting range where different weapons could be tested. When the player approached any of the shooting ranges a weapon appeared in the soldier’s hands and the player could shoot at targets. Points were received for every target that was hit and the total shooting score for all players currently logged into the prototype test could be viewed on the scoreboard which was opened by pressing “Tab”. The players could also go through a large house to reach a garage and a driving range where different vehicles such as jeeps and tanks could be tested. The players could also walk into a house which contained lockers. When the player stood in front of the locker the “E” key could be pressed to open a 2D image of a locker (see figure 9). Through pointing up and down with the cursor the player could choose to change which abilities to have, such as extra speed when driving vehicles in the driving range or extra points when shooting at targets in the shooting range. Figure 9. A screenshot from the 2D locker.

Other actions that could be performed by the players were chatting and grouping with other players. Chatting was done through keyboard commands, where J, K and L 30

enabled chat to everyone around you, everyone in play-test or everyone in the group the player was in. Private messages could also be sent by hitting Enter key and then typing the nick name of the character that was going to receive the message, followed by another Enter press. Thereafter a chat message could be written on the keyboard and sent to the player by hitting the enter key. This interaction method was later changed so that a character could be pointed at, a button could be pressed, and a small 2D menu would appear in the middle of the screen. There was an option called “chat” and that would open the kind of private chat that was previously accessed through typing that player’s nick name. Grouping could, from the second play-test, be done in the same way but with choosing the option “invite to group” as an alternative in the 2D menu.

Figure 10. T he test area map.

There were eleven participants in the first programmed prototype play-test. Before the test the participants received information via e-mail about how the play-test would be conducted. They also each got a nick name and a description of the character that they were going to act as in the play-test. This was planned because interaction and socialization with strangers were other aspects that were to be tested by Sara Jansson. Each participant also received a list of goals to reach in the play-test, to ensure that the play-test situation would reflect what might happen in a real game session. After the play-test the participants were asked to answer a paper post-test questionnaire that was distributed to all participants at their desks. All eleven participants answered the questionnaire. The day after the play-test a list of planned improvements was sent out to the participants together with some word of appreciation for their participation and feedback. Redesigning the programmed prototype for the second programmed prototype test initially took around one week. One of the changes that were made between the first and the second play-test was that a map over the test area (see figure 10) was put up close to where the players started when they had loaded the test level. Signs were also put up outside the buildings, showing a large picture of what was found inside the building, to further facilitate the players’ navigation in the test area. There were ten participants in the second play-test. For this play-test, no specific character descriptions or player goals were given to the participants. They were asked to use the nickname from last play-test and to act similar to the way they did in the last 31

play-test. After the play-test the participants were asked to answer an electronic survey that was published on the DICE intranet. The link to the survey was sent out via email after the play-test and all ten participants answered the survey. Redesigning the prototype from version two to version three took around one week. Some new features, such as more testable equipment and a refined driving area, were introduced. An invitation e-mail was sent out on the day of the play-test. The e-mail contained information about the play-test, a pre play-test meeting and a link to the electronic survey that was to be answered after the play-test. Before the play-test there was, as announced, an information meeting where I informed the participants about how the play-test would work and what they were expected to do. Around 20 people were invited to participate in the third play-test, out of which 16 people could join the test. The players had been asked to log in to the game in groups of a few players at a time. This was decided to simulate that players come and go in online sessions. After the play-test the participants were asked to answer an electronic survey just as in play-test two. This time 15 participants replied to the survey.

3.3.3 Survey through questionnaire To understand the user opinions of and preferences regarding the 3D menu ideas a questionnaire with a mixture of 32 closed and open questions was put together. The questionnaire was offered to around 200 people at the DICE office which includes programmers, artists, designers, game testers and administrative staff. 40 persons answered the questionnaire which was more than the goal of 30 respondents. The questionnaire was designed according to the guidelines from Rubin, Faulkner, Shneiderman & Plaisant presented above, with respect to layout, question formulation, answer types as well as to testing and iterating on the questionnaire. The questionnaire was pilot tested on three persons, then iterated on and tested on two more persons. Changes were made based on feedback in several areas. The form of the answers, for example “how many hours per month do you…” was changed to “how many hours per week do you…” on some questions to reduce complexity. Also, the game genres were changed slightly to make them less ambiguous. After these two pilot test iterations were made the questionnaire was sent out to the 200 employees at DICE. The survey invitation was sent out in its final form on a Monday and the answers were due to be handed in during the same week. The questionnaire was printed out and 25 copies were placed centrally in the office. During the week more questionnaires were printed out when there were only few copies left. This approach was taken because it could possibly make the questionnaire more popular; the thought “Wow, a lot of people must have already answered the questionnaire” was preferred over “Wow, that’s a huge pile of questionnaires, no one is answering them I guess…”. The respondents were asked to place the questionnaires in a box that only had a small slot so that no one could read what other people had replied. The questionnaire could be handed in anonymously but a prize would be given to one of the respondents who provided their name. This approach was taken to open the possibility to ask some of the participants to specify potential unclear answers, which was also done in some cases. 32

4 RESULTS This chapter presents the data analysis and other outcomes from the paper prototype test in the first part, the programmed prototype test in the second part and the survey through questionnaire in the third part. A fourth part presents all the results in a more condensed form.

4.1. Paper prototyping The results from the paper prototyping set the frames for how the programmed prototype would be designed. First of all the paper prototype indicated that providing a world where players move around, make settings, explore and interact with other players can be appealing; the participants in both play-tests looked and sounded like they were enjoying themselves. The two paper prototype tests did not give any data such as ratings etcetera, but still provided user feedback on the aspects that needed to be decided on before the computer based prototype was developed. By watching the play-tests it became apparent that the test area needed a social area. The players were sometimes so busy with exploring and using the environment that they failed to notice that other players wanted to chat or otherwise interact. It would therefore be good with a part of the test area where players could go to interact, chat or group with other players. In the post-test questionnaire that was filled out after the first prototype test a number of suggestions for changes were found. Most of them were implemented before the second play-test. In the first paper prototype play-test the participants had goals to achieve which were chosen to simulate the motivation and goals a player can have when using a game menu. The player who achieved the most goals won the play-test. The aspect of winning or loosing the play-test turned out to be considered superfluous, why it was removed in play-test two. Two dice were used to decide how many hexagons a player could move when it was his or her turn. This was considered unnatural by some test participants since it does not reflect how the actual 3D menu would work; any player should be able to walk equally far in the same amount of time in the 3D world. The dice were therefore not a part of the game play in the second play-test. The players were also asked about, and were generally happy with, the distances between locations in the board game environment, why they were kept for prototype test two and also used when constructing the programmed prototype. In retro perspective the paper prototyping gave many valuable results through observations and the post-test questionnaire which prevented a computer based prototype from being developed only to be heavily reworked after the first prototype test. A few valuable results were that the size of the board game, approximately 15*20 hexagons, was about right when there were a handful of players in the game (it was not too crowded or too empty) and chatting and grouping while making settings seemed appreciated. The paper prototype tests required extensive preparations but gave valuable information and were therefore worthwhile.

33

4.2. Computer based prototyping The computer based prototype was designed and implemented with the experiences and lessons from the paper prototype in mind. I participated as a player in the prototype tests of the programmed prototype to get a good view of how the test was going and to simply observe the players’ behaviours. It is however very difficult to get a feeling for if the players are enjoying themselves or not when you cannot see how they look or hear what they say. Due to this, most of the results from the tests with the computer based prototype came from the post-test survey answers.

4.2.1 First prototype test The first prototype test lasted for around a quarter of an hour and had eleven participants. The fact that the participants were asked to play under an alias and act according to predefined characteristics seemed to make some of the participants slightly reserved. Other than that, and some technical issues before the play-test was up and running, the play-test went well. The following numbers were the results of the post-test questionnaire. Six participants or 55 % liked the size of the area being tested, while four participants or 36 % thought it was too big. Only one person thought the size was too small. On the question “ Did you find it meaningful to be in the 3D menu? Not meaningful 1 2 3 4 5 6 7 Very meaningful” the average response was 5,1. Seven of the eleven participants, or 64 %, gave a response that was above 4. In one question the participants were asked if the would prefer to access equipment in 3D, as in the playtest, or in 2D as games traditionally do. Nine participants answered the question and all of them preferred the 3D solution. In the play-test the participants could test game items in the 3D menu. The participants were asked if they preferred to try the items alone or if they preferred to have other players around in the test area. A total of eleven players preferred to have other players around and no one answered that they would prefer to be alone in the 3D menu while testing items. The players were also asked if they would prefer to select another form of equipment for testing from a 2D menu or in a 3D world, like the one they just tested, and all nine respondents who answered this question replied that they would prefer the 3D interaction. This gives that the answer was unanimously positive towards accessing different kinds of equipment through a 3D world. Ten out of ten respondents answered “yes” when faced with the question “Did you miss that there weren’t any information logged/ displayed about how well you and other players performed?” regarding skill based testing of the equipment. There were some open questions in the questionnaire and the answers from some of them were very diverse, as Faulkner and Rubin implied, and hard to base any improvements on. One questions however generated some valuable information since the responses revealed that four of the eleven participants wanted signs outside buildings in the 3D menu, or wrote that they had had difficulties to find buildings.

34

An observation made during the play-tests was that many participants asked other players for help through the game text chat in the test area. They mainly asked about where to find different buildings and equipment, but also asked each other how some things in the test area were to be used. Sometimes the questions were not noticed or simply disregarded, but in many cases a player would answer the question and also physically in the 3D world show where something was found. Some observations were also made during the play-test that would affect how the prototype was changed. Many participants spent a considerable amount of time and energy on trying to escape the test area that was surrounded by fences and buildings so that all participants would be in the same part of the game world. Many also tried to harm or annoy other players through trying to apply violence to them through using equipment. These two phenomena could best be described by a curiosity or competitiveness to try and break the game rules. To avoid this occurring in future playtests large efforts had to be made to build the environment so that this kind of abuse could be minimized.

4.2.2 Second prototype test Ten players joined the second play-test and six of them had not participated in the previous test. It was very clear that some players had been in the test area before because they immediately ran to the places where they could do things, while the firsttime participants were in the test area longer before they decided what to do. The new players sometimes asked other players for instructions on where to go or what to do and usually someone would try to help them. Six of the participants, or 60 %, liked the size of the map being tested, which could be crossed in about 30 seconds, while four or 40 % thought it was too big, in relation to how many players that were in the play-test. All players gave any of the answers “ O K”, “good” or “very good” on a scale with the following options: “very bad”, “bad”, “O K”, “good” or “very good” regarding what they though about the new signs outside the buildings. The participants were asked about what they had done in the play-test in two different locations and could check any number of options. In four replies in each area players admitted that they had been trying to apply violence to or annoy other players. One participant mentioned that the improvements that had been made to minimize abuse, which consisted in a lot of fence which left some areas looking a bit like cages, made parts of the test area look unfriendly and not a “place to hang around and chat with people”. Five respectively seven of the ten participants replied that they had, in the two areas, devoted some time to exercising friendly activities involving other players. There were also many open questions in this web survey which resulted in many diverse answers. Many players however mentioned that they appreciated and wanted more competing in using equipment as well as suggested how that could be achieved. This was a good suggestion in terms of making the 3D environment fun to use, but making the 3D menu too much like the game can be unnecessary since the actual game should be the main feature, not the menu.

4.2.3 Third prototype test Out of the 15 participants that answered the survey after the play-test 73 % liked the size of the map, while 20 % thought it was too big and 7 % though it was too small. This was a 22 %, or 13 percentage points, increase of content participants when it 35

comes to size of the test area. The size of the area had not been changed since the second play-test but the number of participants had increased with 20 %. One question specifically asked the players what they thought about, in the 3D world, being able access the possibility to change their character attributes and access other information traditionally accessed in a 2D menu. No respondents gave a negative reply, eight gave a neutral response and seven respondents gave any of the positive responses on a five point scale with the third option being the neutral one. In the third prototype test the post-test questionnaire gave rather detailed improvement suggestions where rather advanced forms of competing with other players were requested. Comments from other participants were then heard stating that “this is not the actual game, it shouldn’t be TO O much fun or there is no use producing an actual game.” The suggestions were however mostly not of any importance to this study, why they are not further discussed in this report.

4.3. Survey through questionnaire Out of the 200 persons that were offered to answer the survey 40 people did. This is not a good response rate, but was enough for what was considered needed to answer the questions discussed in this project. The low response rate can however probably be explained by the fact that the reply time was short, no proper reminders were sent out and the survey was distributed in a very work intense period at DICE only about a month before the studio released a new game. Two of the survey participants were women and 38 were men, with a total average age of 28 years. The youngest participant was 18 and the oldest was 40 years old.

4.3.1 Gaming habits The amount of time spent on playing games varied significantly between test participants, who played between 0 and 40 hours per week. The average time played was eleven hours and the standard deviation was nine hours. The most popular game categories, with aspect to how many hours all participants spent on them in total is listed in the left column, while the most liked games based on “favourite game” is listed in the right column. Most played game genres (% of the time) MMORPG (39 %) FPS (15 %), Action (12 %) Adventure / RPG (8,9 %) Strategy (8,5 %) Other games (6 %) Sims / manager (4,9 %) Racing (4,5 %) Platform (2,1 %)

Most liked game genres (%) FPS (30 %) Adventure / RPG (20 %) Other games (20%) Strategy (17,5 %) MMORPG (15 %) Action (7,5 %)

In average 56 % of the time played was spent on playing online games. The games were played on the following equipment:

36

PC Stationary Console Portable Console Mobile Phone Arcade machine

59,5 % 33,7 % 4,9 % 1,4 % 0,6 %

4.3.2 Opinions on 2D menus On the question “When you start a multiplayer game, rank the following due to importance: get straight into the action, meet new people to play with, find your friends and play with them” 50 % of the participants said that finding their friends was the most important while 45 % prioritized getting into the game. Only 5 % rated meeting new friends highest. Out of the 20 people that rated “meeting their friends” highest, 16 people or 80 % put “straight into action” second and “meet new people” third. Out of the 18 people putting “straight into action” first, twelve people or 67 % put “meet my friends” second and meet new people last. This gives that 80 % of all respondents put meet new friends last. In one rather central question in the survey the respondents were asked to rate how important they considered different menu qualities to be. The question was formulated as follows: “How important are the following qualities of a menu? Not at all important 1 2 3 4 5 6 7 Extremely important” Average 5. Visual style corresponds to the game 5,18 6. Audio style corresponds to the game 4,54 7. Intuitive to handle 5,98 8. Easy to handle 5,40 9. Fast to handle 5,78 10. Creatively constructed 3,85 11. Gives you the emotion of the game 4,54 The participants’ responses revealed the following: “Intuitive to handle” got the highest average rating, 5,98, in terms of importance and the importance was given a high rating (“5”, “6” or “7”) by 35 respondents. “Intuitive to handle” was the only option that was not rated lower than “3” by any respondents. “Fast to handle” was rated second most important and got a slightly lower average score: 5,78. The importance was given a high rating by 33 respondents. No respondents gave “fast to handle” a response lower than “2”. The response rated the third most important was the fourth one; “easy to handle”, with 31 high ratings. The fourth most important was “visual style corresponds to the game”, with 29 high ratings. “Audio style corresponds to the game” got 24 high ratings and “gives you the emotion of the game” got 22 high ratings, but the two got the same average result and therefore ended up in a shared fifth place. The average ratings of the categories shows that only “creatively constructed” was considered to be closer to “not at all important” than to “extremely important” in average. This gives us that according to this survey a menu system that only is “creatively constructed” will not gain large sympathies from the users, compared to menus with main qualities from the other options. However, the grade “1”, “not at all 37

important”, was given by four people to each of the three options that had the lowest average score. An important note regarding this question is that the scale does not have a negative and a positive extreme like for example “it highly spoils the menu”, “neutral option” and “it highly improves the menu” has. The seven qualities of a menu listed above are all rated because they were considered to possibly be important to the user. In this question the answers from the two subsets “MMORPG-players” and “FPSplayers” were also compared. I assumed that the players from the later group would rate the importance of option number 5, fast to handle, higher than the MMORPG players would. It turned out that the nine respondents in the FPS group had an average response of 6,0 while the 13 respondents in the MMORPG group had an average of 5,4. Both subsets displayed a standard deviation of 1,6. An AN O VA test of the ratings for the two groups however returned a p-value of 0,39 and an F of 0,76. This shows that there is no significant difference between the two groups on the p=0,05 level which is recommended and frequently used. Player type subsets There were two questions where the participants were asked to rate how much they belonged to each of four groups, in percent. There were two different player type systems. In Alix’s system the participants rated how much they belonged to each of the following groups: “Warrior”, “Narrator”, “Strategist” and “Interactor”. The results are shown in table 1 below. Table 1

The average column shows how much the respondents in average regarded themselves as each of the four player types. In average the respondents thought they were 35 % narrators, 24 % warriors, 21 % strategists and 19 % interactors. The occurrences column describes how many respondents that considered themselves to be more that player type than any other player type. A respondent who had answered 20 %, 20 %, 20 % and 40 % in the respective categories would be one of the five interactors and the grouping did not require a reply of 50 % or higher. Respondents who answered for example 30 %, 30 %, 20 % and 20 % are not considered to belong to any player type group. Only five persons or less regarded themselves as mostly warrior, strategist or interactor, while 14 respondents regarded themselves as mostly narrators. The low numbers in three of the categories make comparisons between the four groups rather uninteresting. Because of the nature of the answer types, which depends on the nature of the problem; very few of us are 100 % of one player type. It is not even interesting 38

to compare the narrators with the rest of the population, since very little possibly separate the two groups from each other. Therefore the result in this question was not taken into consideration when the survey data was analyzed. In Bartle’s player type system the respondents were distributed mainly between two categories: achievers and explorers with 45 % and 35 % of the players belonging to each of the groups. Comparisons can therefore be made between “achievers” and “explorers”. Table 2

4.3.3 Opinions on 3D menus General opinions The questionnaire contained a question about what the respondents would think about 3D menus: “If a 3D PC game would bring you right into the 3D-world after the installation (first time user) or initial loading, without a menu session between the two stages, and let you change settings in the 3D-environment of the game, would you appreciate it?” The answer was requested on a 7 point scale as follows: “I would hate it 1 2 3 4 5 6 7 I would love it”. The responses were distributed as follows: Table 3

Out of the 40 questionnaires that were handed in 37 contained answers on this question. The replies were spread out over all seven options and generated an average of 4,2 which is a response slightly shifting towards the positive side. Seven of the 37 respondents chose alternative 4, the neutral option, and if those seven are taken out of the population the average is 4,3. The number of strong negative responses, “1” or “2”, are eleven which is one less than the number of strong positive responses, “6” or “7”. However, the number of slightly negative responses, “3”, was only one and the number of slightly positive responses “5” was six. In total twelve persons gave a negative response while 18 persons gave a positive response. Specified opinions In the following question the participants were allowed to further specify what might be good or bad with the solution briefly presented in the previous question. They were allowed to check as many as they liked from the following five statements The idea above sounds: 39

1. 2. 3. 4. 5.

Like a downgrade from current menu functionality Like an upgrade from current menu functionality Like fun New and therefore interesting Slower than ordinary menus

Table 4

This question was answered by all but one participant who did not check any of the five alternatives. According to the answers on this question a slightly larger percentage of the participants thought the solution would be a downgrade than an upgrade compared to menu solutions that are common today. However, four participants checked both option one and option two, which indicates that they noted that the solution can be a downgrade in some senses and an upgrade in others. This gives that only 27 of the 40 participants checked if they thought the solution would be an upgrade or a downgrade. A total of 25 respondents, or 63 %, replied either or both of 3 (it sounds like fun) and 4 (it sound new and therefore interesting). Ten answered that they thought this solution would be slower than traditional menu solutions. In total, eleven respondents gave any or both negative responses, 1 and 5, and none of the positive responses. At least one of the positive responses, 2, 3 or 4, and none of the negative responses were given by seventeen or 43 % of the participants. In total 21 persons said something negative and 27 persons said something positive. These numbers show that the participants can see many positive aspects that a 3D menu could bring but also the downsides with the solution. One fourth of the respondents worry that the solution will be slower than ordinary menus. This question was also analyzed with respect to the two large player type groups “achievers” and “explorers” that were observed in the player type analysis above. The middle and the right column show how many of the respondents from each group that agreed with each statement. Table 5

As the table above shows there were rather large differences between the two groups. It was 37 % less common for explorers to think that 3D menus are a downgrade from traditional menu functionality compared to the achievers. It was twice as common for 40

the explorers to think the idea sounds like an upgrade, compared with the achievers. The exact same numbers is valid for the “new and therefore exciting” answer. The achievers were about 50 % more inclined to agree with the statement that the 3D menu sounds slower than ordinary 2D menus. Further on, 3D menus were rated as fun by 36 % of the achievers and 55 % of the explorers, which is a 50 % higher result. AN O VA tests on these numbers show a tendency that there are actually differences between the two groups in the results in question 2 and 4: both p values are 0,07 while F is 3,6. On the other questions the p-value is 0,37 or more, why they should not be considered statistically significant, even if they can be looked at as interesting tendencies. From this subset analysis it seems like explorers are more positive towards the 3D menu solution than both the achievers and than the total average for all groups. In the same way, achievers seem to be more negative towards the idea than both the explorers and the total average. Table 6

The two player groups, MMORPG players and FPS players, were also compared in some of the options in this question. In the FPS group 33 % thought the solution would be slower than ordinary menus and 11 % though the solution would be an upgrade. In the MMORPG group 23 % thought the solution would be slower than ordinary menus and 54 % thought it would be an upgrade compared to ordinary menus. However the percentage that believed the solution would be a downgrade was around 55 %. This indicates that some of the respondents in the MMORPG group thought it would be both an upgrade and a downgrade. Preferences In the next question the participants were asked to answer how they would prefer to make selections in PC games. They were given three alternatives to choose from, showing different ways of picking equipment: from a list of equipment names, a series of equipment images with names or a 3D version where the character can walk up to a table to choose between different items, without labels.

41

Figure 9. Screenshot from Vietcong (2002).

Figure 10. Screenshot from Battlefield 2 (2005).

Figure 11. Screenshot from Vietcong (2002).

Table 7

All 40 participants answered the question. Only one preferred choosing equipment from a list with equipment names. The majority, 28 participants or 70 %, preferred choosing from equipment images and text and eleven participants or 28 % preferred making the choice in 3D. Table 8

If the population is divided into groups of players who play fast paced games, the FPS group consisting of nine participants, and slow paced games, and the MMORPG group consisting of 13 participants, the numbers are distributed a bit differently. Most participants from both two groups preferred choosing from images and text, but the answers are spread out in another way. The largest difference is seen among those who would prefer to make their choices in 3D. It is more than three times as common that a MMORPG player prefers to make the choices in 3D as it is for an FPS player. Table 9

The results were also compared for fourteen achievers and the nine explorers. Here the results were fairly similar with the largest difference between the two groups being 9 percent units.

42

4.4. Result compilation – prototype tests and survey 4.4.1 Results - Test participants Out of the test participants in the first programmed prototype play-test 64 % of the test participants gave a positive answer when asked if they felt it was meaningful to be in the 3D menu. All of them preferred to access different kinds of game equipment in the 3D menu compared to in a 2D menu. All of the participants would in one form or another want to have other players in their vicinity when they tested equipment in the 3D menu. They also wanted information about how well they performed in skill based equipment testing compared to the other players. A number of players asked other players for help or guidance in the test area. The players wanted signs and a map to be able to quickly navigate in the 3D menu. All of the participants in the third prototype test gave a neutral (53 %) or a positive (47 %) response on the question that asked for their opinions on being able to change character attributes and access traditional 2D menu information in the 3D test area.

4.4.2 Results - Survey participants Around half of the respondents prioritize meeting their friends before starting the game while the other half prioritize going straight into the game. Intuitive and fast to handle were the main priorities in a menu while audio style, followed by easy to handle and visually correspondent to the game were slightly less important. Emotion given and creativeness in construction of the menu were considered the least important. A negative response was given by 12 persons and a positive was given by 18 on the question if they would appreciate a 3D menu. About 40 % though that a 3D menu would be a downgrade compared to traditional menus, and as many thought it would be an upgrade. It sounds like fun was a statement 35 % agreed with and it sounds new and therefore interesting sounded correct to 50 % of the participants. Around 25 % expressed that the solution sounds slower than ordinary menus. Explorers seem to be more positive towards the 3D menu system than achievers and other players, while achievers seem more negative. Out of the explorers 73 % considered 3D menus and upgrade while the same number for the achievers was 36 %. The FPS players rated fast to handle more important than the MMORPG players did, even if it cannot be considered statistically significant. Around 33 % of the FPS players thought the 3D menu would be slower than ordinary menus, compared with 23 % of the MMORPG players. More then half of the MMORPG players thought that the 3D menu sounds like an upgrade from 2D menus while only 11 % of the FPS players agreed. The majority, 70 % of the survey respondents, preferred choosing equipment in a screen with images and text, while 28 % would prefer to do it in 3D.

4.4.3 Test participants versus survey respondents The group who got to try the 3D menu, the test participants, were overall more positive towards the 3D menu than the survey respondents. In the former 100 % preferred choosing equipment in 3D while the number was only 28 % in the latter. However 45 % of the survey respondents thought they would appreciate a 3D menu, why the low 28 % in the previous question might not be an important result. The players may see other advantages with the 3D menu than only the ones related to their 43

experiences when selecting equipment. They may also be a bit reserved towards the 3D menu idea since they have no experiences of them.

44

5 CONCLUSIONS The questions asked in the beginning of this Master’s thesis were the following: 1. Can a 3D world present an environment that to some extent can replace traditional game menus? 2. If so, in which types of games and to what extent can it be used? 3. How does this relate to traditional menu usage and what is better and what is worse, from an HCI and UI design perspective? 4. What do players think about this solution and how do they react if presented with it? 5. Are there other advantages with this menu solution than the possible removal of the four challenges presented in the beginning of this report? The four computer game menu challenges that I find are common in traditional 2D menu design and were described in the beginning of this report are the following, in a shortened form: 1. 2. 3. 4.

Less impressive graphics than the actual game A possible first negative impression from the game Complex and non-intuitive navigation Breaking the immersion

The questions will be answered one by one in this chapter, through looking at the results of the study described in this thesis. Last but not least it will be explained how a 3D menu can face and overcome all four menu challenges.

5.1. Questions 5.1.1 Question One Question: Can a 3D world present an environment that to some extent can replace traditional game menus? Answer: Yes, to some extent it can. The game developer who decides to implement a 3D menu solution will take a risk of alienating some players who prioritize speed through the menus, or they will also have to offer faster ways of using the 3D menu like for example provide keyboard shortcuts. The developer will however provide a feature that can contribute to providing an extra interesting game, especially to players who prioritize 3D interaction and world exploration, which should be an important quality.

5.1.2 Question Two If the 3D world can present an environment that to some extent can replace traditional game menus, in which types of games and to what extent can it be used? Answer: Replacing traditional game menus with 3D menus would, according to this study, be most beneficial in MMORPGs, or in other game types through which the 45

developer wants to attract players from the MMORPG genre. It does not seem to appeal to the FPS players, why it possibly does not fit FPS games. Other gamer types were not analyzable since there were too few participants in each of the groups. The 3D menu solution should only be used in environments where the 3D game world corresponds well to how the menu world would have to work and look. It would have to be complemented with at least “video settings” which should be accessible through a 2D screen, since the situation might occur when a player cannot see or use the game world because of the current video settings.

5.1.3 Question Three Question: How does the 3D menu solution relate to traditional menu usage and what is better and what is worse, from an HCI and UI design perspective? Answer: Designing, implementing and using 3D menus is very different from the equivalence for 2D menus. A successful 3D menu needs to look as good and welcoming as the real game world, instead of sparse and alienating like Planetside, to use its full capacity as an alternative to 2D menus. Positive sides with 3D menus over 2D menus: • 3D menus can have a much more intuitive navigation than 2D menus do and intuitive menus are what the respondents value the most in menu design. • 3D menus have an advantage through that the players can meet, socialize and in other ways interact with other players in the 3D menu, something that seemed appreciated in the user tests, in a more intuitive way then what is possible in 2D game lobbies today. • 3D menus can give players a first good impression of the game since it in many ways is as appealing as the game itself. • 3D menus offer as impressive graphics as the game because they are set in the game environment. • 3D menus support immersion and the player can get more attached to the game and the game characters earlier than what is likely when using 2D menus. • 3D menus can shorten loading time for the actual game, given that it contains objects that also exist in the actual game world. • 3D menu worlds can at least to some extent, depending on genre, follow realworld conventions, recommended in the second interface objective by Nielsen (2005). Negative sides with 3D menus over 2D menus: • Since there basically are no 3D menus in games there are no standards for how they will work, which would have been good to follow according to the fourth interface objective (Nielsen, 2005). This might confuse players before 3D menus become common. • The 3D menu is potentially slower to use than the 2D menu for the experienced players since they often learn patterns, through for example keyboard shortcuts, in which to control the menu for their frequent actions. 46

•

Making changes to a 3D world is expensive because 3D content is more expensive to produce than 2D content.

5.1.4 Question Four Question: What do players think about this solution and how do they react if presented with it? Answer: The players who participated in tests and surveys in this study gave very heterogeneous answers. The test participants were over all rather happy with the 3D menu, 100 % said that they would prefer to make choices in 3D rather than in 2D, while the survey respondents were more neutral or carefully positive to the 3D menu. When faced with images of selecting equipment from text, from text and images or selecting directly in 3D 28 % of the respondents would prefer the last option, in 3D, while 70 % preferred text and images together. If subsets are looked at it is clear that MMORPG players seem much more positive towards 3D menus than FPS players. However, as many as 45 % of the participants thought they would appreciate a 3D menu. The fact that the survey respondents did not get to test 3D menus makes the rather low interest in them logical. It is common that people are reserved against new ideas. Also, the fact that the image showing 3D interaction did not reveal if the user would be presented with labels when close to the weapon table, makes their cool interest understandable.

5.1.5 Question Five Question: Are there other advantages with this menu solution than the possible removal of the four challenges presented in the beginning of this report? Answer: Yes there are other advantages. In the computer based play-tests the participants asked other participants for help with finding their way or with how things were used or achieved. In 3D multiplayer menus players should be able to help each other. The fact that there can be many players in a 3D menu can also improve chances of players helping each other since it feels more natural to start talking to someone you walk by, as in 3D, than to someone in a list, as in 2D lobbies.

5.2. Overcoming the challenges Here are, once again, the four challenges that are very common in 2D menus. Below each challenge the solution presented by using 3D menus will be described. 1. The 2D menu has less impressive graphics than the actual game. The 3D menu has as impressive graphics as the actual game because it is set in the game environment. 2. The 2D menu can cause a possible first negative impression of the game. The 3D menu is not likely to cause any negative impression from the game since the world with its look and feel is presented right away.

47

3. The 2D menu can have a complex and non-intuitive navigation. The 3D menu, if implemented the way it was intended, offers intuitive navigation since it is set in a real world. 4. The 2D menu can easily break the immersion. The 3D menu does not break the immersion since unnatural objects are avoided and objects from the game world are used. This condensed answer shows that 3D menus can face and overcome the four game menu challenges presented in the beginning of this report. This however requires that the 3D menu is implemented the way it was intended and that the object and setting in the 3D menu is actually as worked on as the actual game. As much as possible from the real game must be used and only a very small part of what is presented in the 3D menu may be made to be used solely in the 3D menu.

48

6 DISCUSSION This chapter contains reflections on different parts of this project; both reflections on what could have been done better but also recommendations on what parts of this subject that could be studied further.

6.1. Improvements Looking back at a project of this magnitude it is easy to see what could have been done better. In the beginning it is hard to get the big picture but in retrospective it becomes clear where more preparations could have been put in or where things could have been done in a better way. The things that could have been done better are presented in this chapter.

6.1.1 Prototype tests Test participants The test participants should preferably have been people who would specifically have been the target group for this type of product or game feature. It is not recommended to have game designers as test participants (Faulkner, 1998). The circumstances, however, limited my choice of participants to employees within DICE, why some of the participants also were designers. The first tests, testing the paper prototype, did not go into great feature detail, but were high level tests to set the framework for the programmed prototype. The later programmed prototype tests tested the feature in greater detail, but were still conducted with a variety of employees within DICE. Even though it in general does not justify only having staff from the industry as test participants, this is however how the vast majority of the testing of computer games is conducted. Testing games When test are conducted with computer games it is easy for the test participant to start playing instead of testing. This is good since the test environment should simulate the natural environment and usage for that product. This can also bring that the participant will be in a very playful mood. This was obvious during the play-tests through that many participants tried hard to outsmart the game by trying to jump over or sneak between small spaces in between fences and thereby escape the confined test area. Many attempts, some of them successful, were also made to try to harm other players despite that all damage to players was disabled in the prototype. This might affect the type of observations that could be made during the tests.

6.1.2 Questionnaire Questionnaire answerers The same is valid for the persons answering the questionnaire, as for the test participants; game designers are generally not the most representative users of the end product. Here, however, the respondents were more diverse; people from very different projects, positions, nationalities and with different responsibilities answered the questionnaire. Many of them played computer games quite regularly, whereas 49

others played more seldom. Different genres were preferred, as well as different game platforms, which points out that the respondents were a quite heterogenic group after all. The low questionnaire participation, only 40 out of approximately 200 persons replied, could be a result of the very high workload at DICE when the questionnaire was distributed. They launched a new game, Battlefield 2142, only a month after the questionnaire was distributed and many employees could not find the time to fill it out. Questionnaire distribution In some questions a larger population would have generated more answers that could have provided interesting data. Therefore it could have been beneficial if a larger population had been recruited for the survey. The answers were informative, if looking at the whole survey population, but a larger population would have made more data analysis of population subsets possible. The respondents should have had a longer time before the deadline. Also reminders should have been sent out to remind the participants of the survey.

6.2. Results The results show some clear relations between how someone who gets the 3D menu explained to them, in this case the survey respondents, and how someone who gets to try the 3D menu, the test participants, vary in their opinions. It is possible that the test participants, who had closer contact with me than the survey respondents had, gave more positive answers to not be “rude” and that the survey respondents did not have the same sense of having to be nice when it came to opinions on the 3D menu. This phenomenon is called “experimenter expectancy effects” and refers to the unintentional ways in which a researcher can influence the test participants into giving answers that more correspond to the researcher’s hypothesis (Passer & Smith, 2004). One even more important factor was probably the difference between the test situation and the survey description of the 3D menu. The test participants tested the 3D menu in multiplayer sessions, while the survey respondents only were asked about the very concept of the 3D menu: the idea of having many players in the menu at the same time was never mentioned. Also the survey respondents probably had no experience of 3D menus to relate to when answering the question. This was of course a flaw in the survey why it would be good to include the multiplayer aspect in a questionnaire if further studies are to be made in this field. One feature in the 3D menu that at first seemed to possibly be very valuable was the possibility to meet new friends to play with. This however did not seem to appeal to most of the survey respondents, since 80 % valued that lower than meeting up with their existing friends or joining the game right away, and it would be interesting to see a more extensive test where it is investigated to what extent players would use that possibility in a 3D menu. It was very interesting to see that the results from the survey varied quite a lot between players who mainly play games from different genres. The survey can therefore answer which gamers, rather than which games, that would benefit from implementing a 3D menu. This can still be very interesting information since game developers continuously look to extend their market share through among other things getting many players to get interested in their game. This can of course be done by broadening 50

their game experience so that it can appeal to players who mainly play games from other genres. Furthermore I believe that the results show that implementing a 3D menu will take a lot of planning and iterating to be successful. It also requires that the menu is implemented in the right type of game. I also believe that the gamers will be divided in their reactions regarding the 3D menu just as the users in this study have been. Some players will not like it, but some players will like it and the relation between the two is hard to speculate in. I personally would very much like to see a 3D menu fully implemented and released in a game and I think doing that is the only way to truly know if the 3D menu is something that belongs in future menu design.

6.3. Further research As mentioned in the chapters above there are things that I would recommend for further testing and research: A questionnaire survey aimed at gamers who do not work with computer games could be distributed, and offered to a larger population. It would be good if around ten times as many answers were collected in the study, to make data analysis of more subsets interesting and perhaps also significant results more frequent. The questionnaire should contain questions where the 3D menu is explained as the rich multifunctional menu solution that it was tested as. Also the answers should be given anonymously to reduce risks of respondents wanting to give the “right” answers. In the same way, user tests should be conducted where a more scaled down prototype is tested, to see the participants’ attitudes towards a singelplayer 3D menu.

51

7 WORD LIST Build

A computer game build is a version of the game and the term is used during the development of a game. “The latest build” is the current version of the game.

FPS

First Person Shooter.

Gamasutra

Gamasutra is a well regarded website which collects articles and news from the game industry (Tengå, 2007).

Gameplay

Gameplay can be defined as consisting of “the challenges that the game presents and the actions the player may take to overcome them” (Adams, 2003).

Immersion

A state of being deeply engaged or involved; absorption.

Learning curve

The learning curve refers to a relationship between the duration of learning or experience and the resulting progress.

MMORPG

Massively Multiplayer Online Role-Playing Game.

NPC

Non-player character, a character whose behaviour is predefined by the game designer and programmed to be triggered by different events that happens in the game (Bartle, 2003).

52

References Articles Adams, E. (2003) The Construction of Ludic Space. Level Up Conference Proceedings, DiGRA Games Research Association. Accessed 20070809. http: / / www.digra.org / dl / db / 05150.52280 Alix, A. (2005) Beyond P-1: Who plays online? Proceedings of DiGRA 2005 Conference: Changing views – Worlds in play. www.tuchemnitz.de / phil / medkom / mn / spive / index.php?option=com_docman&task=doc_d ownload&gid=23 Aaron, T. (2004) Tiger Woods PGA Tour 2007 for Xbox 360 Review. Gamespot. http: / / www.gamespot.com / xbox360 / sports / tigerwoodspgatour07 / review.html?om_a ct=convert&om_clk=gssummary&tag=summary;review Calicia, B (1998) Hanging Out in the Lobby. Gamasutra. Accessed 20070801. http: / / www.gamasutra.com / features / game_design / rules/ 19980918.htm Das, T. K.., Singh, G., Mitchell, A., Kumar, S. McGree, K (1997) N etEffect: a network architecture for large-scale multi-user virtual worlds. Proceedings of the ACM symposium on Virtual reality software and technology VRST '97. Publisher: ACM Press. Dobson, J (2006) Product news: D emonWare Releases Lobby Advertising Solution. Gamasutra. Accessed 20070807. http: / / www.gamasutra.com / php-bin / news_index.php?story=9797 ESA, Entertainment Software Association (2007) 2007 Sales, D emographic and U sage Data – E ssential Facts. Accessed 20061019. http: / / www.theesa.com /archives / ESA-EF%202007%20F.pdf Federoff, M (2002) H euristics and U sability Guidelines for th e Creation and Evaluation of Fun in Video Games. Accessed 20070816. http: / / melissafederoff.com / heuristics_usability_games.html Fitts, P.M. (1954) The Information Capacity of the Human Motor System in Controlling the A mplitude of Movem ent. Journal of experimental Psychology, 47, 381-391. Fraser, G. & Fisher S. (1998) Intelligent Virtual Worlds Continue to D evelop. ACM SIG GRAPH Computer Graphics, Volume 32 Issue 3. Gerstmann, J. (2004) Grand Theft Auto – San Andreas. Gamespot. Acessed 20070809. http: / / www.gamespot.com /ps2 / action / gta4 / review.html?om_act=convert&om_clk= tabs&tag=tabs%3Breviews&page=4 Hague, J. (2000) Are virtual worlds worth it? ACM SIG GRAPH Computer Graphics, Volume 34 Issue 2. 53

Harris, J (2006) Giving you Fitt’s. Accessed 20070716. http: / / blogs.msdn.com / jensenh / archive /2006 /08 /22 /711808.aspx Helms Jørgensen, A. (2004) Marrying HCI / U sability and Computer Games: A preliminary look. ACM. Jansson, S. (2007) Master’s Thesis preliminarily on “Social aspects of 3D environments”. To be published. Linköpings Universitet. Kasavin, G. (2003) Vietcong. Gamespot. Accessed 20070809. http: / / www.gamespot.com /pc /action / vietcong / review.html?tag=tabs;reviews Kim, A. J., Fraser, G., Fisher, S. (1998) Real-time Interactive Graphics in Computer Gaming. ACM SIG GRAPH Computer Graphics, Volume 32 Issue 2. Kirkman, T. (1996) A NO V A: A Nalysis Of V Ariance between groups. Accessed 20070731. http: / / www.physics.csbsju.edu / stats / anova.html Navarro, A. (2005) Animal Crossing - Wild World. Gamespot. Accessed 20070809. http: / / www.gamespot.com / ds / rpg / animalcrossingds/ review.html?om_act=convert& om_clk=tabs&tag=tabs%3Breviews&page=2 Nielsen, J. (2005) H euristics for Interface D esign. Accessed 20061019. http: / / www.useit.com / papers/ heuristic / heuristic_list.html Nielsen, J. (2000) Why You Only N eed To Test With Five U sers. Accessed 20070613. http: / / www.useit.com / alertbox / 20000319.html Park, A. (2003) Planetside. Gamespot. Accessed 20070809. http: / / www.gamespot.com /pc / rpg / planetside / review.html?om_act=convert&om_cl k=gssummary&tag=summary%3Breview&page=1 Sánchez-Crespo Dalmau, D. (1999) L earn Faster to Play Better: How to Shorten the L earning Cycle. Gamasutra. Accessed 20070827 http: / / www.gamasutra.com / features / 19991108 / dalmau_01.htm http: / / www.gamasutra.com / features / 19991108 / dalmau_02.htm http: / / www.gamasutra.com / features / 19991108 / dalmau_03.htm http: / / www.gamasutra.com / features / 19991108 / dalmau_04.htm http: / / www.gamasutra.com / features / 19991108 / dalmau_05.htm Sellers, M (2002) Creating effective groups and group roles in massively multiplayer Games. Gamasutra. Accessed 20070801. http: / / www.gamasutra.com / resource_guide /20020916 / sellers_02.htm http: / / www.gamasutra.com / resource_guide /20020916 / sellers_03.htm Shelley, B (2001) Guidelines for D eveloping Successful Games. Gamasutra. Accessed 20070809. http: / / www.gamasutra.com / features / 20010815 / shelley_01.htm 54

Books Ahearn, L. (2001) Game Art Elements. Phoenix, AZ, USA: Paraglyph Press. Bartle, R (2003) D esigning virtual worlds. USA: New riders publishing. Cohn, M (2004) U ser Stories Applied – For Agile S oftware D evelopment. Boston: Pearson Education, Inc. Faulkner, C. (1998) The E ssence of Human-Computer Interaction. Essex: Prentice Hall. Fox, B. (2005) Game Interface D esign. USA: Thomson course technology. Galitz, W. (2002) The E ssential Guide to U ser Interface D esign. USA: John Wiley & Sons Inc. Gunderloy (2005) D eveloper to D esigner – GUI D esign for the Busy D eveloper. USA: Sybex. Norman, D. (1988) The D esign of Everyday Things. New York: Basic Books. Pardew, L (2004) Game design for teens. Ebrary. Passer, M. & Smith, R. (2004) Psychology: The science of mind and behaviour, 2nd edn. New York: McGraw-Hill. Rollings, A & Adams, E. (2003) Andrew Rollings and Ernest Adams on Game D esign. Berkeley: New Riders Publishing. Rubin, J. (1994) Handbook of usability testing – How to plan, design and conduct effective tests. New York: John Wiley & Sons, Inc. Saunders, K. & Novak, J. (2007) Game D evelopment E ssentials – Gam e Interface D esign. USA: Thomson Delmar Learning. Shneiderman, B. & Plaisant, C. (2005) D esigning the U ser Interface – Strategies for Effective Human-Computer Interaction, 4th edn. USA: Pearson Education, Inc.

Games Animal Crossing – Wild World (2005) Nintendo DS: Nintendo. Battlefield 2(2005) PC: DICE. Grand Theft Auto – San Andreas (2004) PS2: Rockstar North. NBA Live 07 (2006) Xbox 360: E A. Planetside (2003) PC: Sony Online Entertainment. 55

Tiger Woods PG A Tour 2007 (2006) Xbox 360: EA. Vietcong (2002) PC: Pterodon.

Other Digital Illusions CE AB (2006) 2005 - Annual report. Emdin, K. (2007) Private conversation on video settings, 20070820. Kertz, A. (2006) Private conversation on porting games, 20061027. Sallnäs, E. (2006) Utvärderingsmetoder inom MDI 2D1408 – Analys av utvärderingsdata ( Evaluation methods within HCI 2D1408 – Analysis of evaluation data). Lecture notes. KTH: Stockholm. Tengå, J. (2007) Private conversation on Gamasutra, 20070813.

56

TRITA-CSC-E 2007: 098 ISRN-KTH/CSC/E--07/098--SE ISSN-1653-5715

www.kth.se