Designing a persistent online strategy game - Department of ...

More documents

Recommendations

Info

30 Chapter 4. Models & methods for evaluating games Figure 4.1: The procedure to separate fun and usability problems. Adapted from Barendregt et al. [2]. 2. Was it meant to be difficult? If yes it is a fun problem, if no a usability problem. 3. Can taking over the device (mouse, gamepad etc.) solve the problem? If yes it is a motor skill problem that can either be a fun or a usability problem, go to 4. If no it is a fun problem, for example that the game is too scary and the player does not want to continue. 4. Was it meant to be difficult? If yes it is a fun problem because the game is too hard, if no it is a usability problem. 4.3 Differences between productivity software and video games Usability methods were designed for productivity software, but games are not productive in themselves. It is important, when choosing methods for evaluating games, to understand how they differ from other types of software. Knowing the differences can also help in designing new methods for evaluation. Pagulayan et al. [48] have identified several differences between video games and productivity software that will be presented below. Productivity software is used as a tool to accomplish a task. The only thing that separates it from a hammer is the domain and the purpose for usage. Games, on the other hand, should be fun; they have no other purpose than entertainment. They are more like movies or books in that sense. Games should also stimulate thoughts and emotions. Other types of software also require thinking, but that is not the purpose. Games define their own goals. Other types of software are used to achieve external goals. Some applications have easily defined goals, like an online store. Other types of software can have more complex and variable goals, like a spreadsheet program. The challenge
4.4. Playability and gameplay 31 is to design an interface that let the user achieve her goals as easy as possible. This is harder when the software is more general. Games define goals in the world that the game creates, and they are only valid in that context. This can make it easier because the evaluator exactly knows which goals the player has. The challenge is to convey the goals to the player and making sure that the player is aware of the resources accessible to reach the goals. Users want consistency when using productivity applications. Menus should work the same way even between different types of applications. Games have to create a different experience every time to prevent the player from becoming bored. They should offer alterative strategies and new rules to learn. The pressure to all the time create new experiences can make game designers abandon used and tested interface solutions and standards. Most productivity applications are controlled in the same way. The user often uses a keyboard and mouse. Games have different controls for different types of games and platforms. They are often innovative and solve many different issues, but they can also introduce entirely new challenges. Productivity software offer just as much sound and graphic as necessary to convey functionality. In games the environment is created by using sound and graphics. It can also be used to set the mood and create tension in a game. This could lead to that usability becomes sacrificed for the sake of aesthetics. 4.4 Playability and gameplay Playability is usually understood as usability in the domain of games [18]. Järvinen et al. [27] tries to further define the term. They define playability as “a qualitative term for the uses of both design and evaluation. It refers, on the one hand, to the guidelines regarding how to implement the necessary elements (such as rules) to give birth to a desired sort of gameplay...”. Gameplay is basically what defines a game as a game. It concerns both the formal elements of a game, i.e. the rules and components, and the player. Gameplay and interaction are the same, but the term gameplay is used when a player interacts with a game (with rules and goals). Different types of games offer remarkably different types of gameplay. Anyone that plays games long enough forms their own concept of good and bad gameplay based on their experience [17]. Evaluating playability means to analyze how well a game conforms to a desired sort of gameplay. Playability can be divided into the four components functional, structural, audiovisual and social playability [27]. Functional playability refers to the functional aspects that affect gameplay. It relates to the controls of the game and is close to traditional usability. Analysing functional playability means for example to evaluate how well the input-device is configured to give the desired gameplay. Structural playability concerns the mechanics of games. One thing that gives structure to a game is the rules of the game and the patterns that emerge from these rules.
Page 1: Designing a persistent online strat
Page 5 and 6: Contents 1 Introduction 1 1.1 Defin
Page 7 and 8: CONTENTS v 8 Result of the implemen
Page 9 and 10: CONTENTS vii Appendix C Manus till
Page 11 and 12: Chapter 1 Introduction The purpose
Page 13 and 14: 1.3. Goals 3 of the gameplay and on
Page 15 and 16: Chapter 2 Methods This chapter expl
Page 17 and 18: 2.3. Focus groups 7 questionnaires
Page 19 and 20: 2.6. Evaluation 9 observe users int
Page 21 and 22: Chapter 3 Requirements engineering
Page 23 and 24: 3.3. The Non-Functional Requirement
Page 33 and 34: 3.4. Eliciting requirements 23 - Fo
Page 35 and 36: 3.4. Eliciting requirements 25 unst
Page 37 and 38: Chapter 4 Models & methods for eval
Page 39: 4.2. Beyond usability in the design
Page 43 and 44: 4.5. Flow 33 difficulty of the task
Page 45 and 46: 4.5. Flow 35 Figure 4.3: The optima
Page 47 and 48: 4.7. Player experiences in games 37
Page 49 and 50: 4.8. Methods for the evaluation of
Page 51 and 52: 4.8. Methods for the evaluation of
Page 53 and 54: Chapter 5 Pre-study This chapter pr
Page 55 and 56: 5.6. Result of the brainstorming 45
Page 57 and 58: 5.8. Result of the focus groups 47
Page 59 and 60: 5.8. Result of the focus groups 49
Page 61 and 62: Chapter 6 Result of the pre-study S
Page 63 and 64: 6.2. Examples of dropped ideas 53 n
Page 65 and 66: 6.2. Examples of dropped ideas 55 -
Page 67 and 68: Chapter 7 Implementation of the fun
Page 69 and 70: 7.3. System architecture 59 7.3 Sys
Page 71 and 72: 7.3. System architecture 61 Figure
Page 73 and 74: Chapter 8 Result of the implementat
Page 75 and 76: 8.1. Overview of the prototype 65 A
Page 77 and 78: 8.1. Overview of the prototype 67 F
Page 79 and 80: 8.1. Overview of the prototype 69 w
Page 81 and 82: 8.1. Overview of the prototype 71 8
Page 83 and 84: 8.1. Overview of the prototype 73 W
Page 85 and 86: 8.1. Overview of the prototype 75 F
Page 87 and 88: Chapter 9 Evaluation This chapter d
Page 89 and 90: 9.3. Focus group evaluation 79 Anot
Page 91 and 92:
9.4. Result of the focus group eval
Page 93 and 94:
Chapter 10 Resulting design documen
Page 95 and 96:
10.4. Timescale 85 - Forts. Forts a
Page 97 and 98:
10.8. Encounters 87 10.8 Encounters
Page 99 and 100:
10.12. Cities 89 10.12.1 Buildings
Page 101 and 102:
10.14. Resources 91 10.13.1 Race at
Page 103 and 104:
10.15. Family and family members 93
Page 105 and 106:
10.17. Conquest and expansion 95 10
Page 107 and 108:
10.18. Battles 97 captured. The pla
Page 109 and 110:
10.21. Diplomacy 99 is of course al
Page 111 and 112:
10.24. Issues that needs to be reso
Page 113 and 114:
Chapter 11 Discussion & Conclusion
Page 115 and 116:
11.2. Future work 105 A forum was l
Page 117 and 118:
Chapter 12 Acknowledgements We woul
Page 119 and 120:
References [1] Arsenault, D. DARK W
Page 121 and 122:
REFERENCES 111 [28] Johnson, B., an
Page 123:
Appendices 113
Page 126 and 127:
116 Chapter A. Pre-prototype game s
Page 128 and 129:
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
130 Chapter B. Enkät Vad/vilka del
Page 142 and 143:
132 Chapter C. Manus till brainstor
Page 144 and 145:
134 Chapter D. Resultat - brainstor
Page 146 and 147:
136 Chapter D. Resultat - brainstor
Page 148 and 149:
138 Chapter E. Resultat - brainstor
Page 150 and 151:
140 Chapter E. Resultat - brainstor
Page 152 and 153:
142 Chapter F. Manus för diskussio
Page 154 and 155:
144 Chapter G. Frågor som måste b
Page 156 and 157:
146 Chapter G. Frågor som måste b
Page 158 and 159:
148 Chapter H. Annoterade idéer ti
Page 160 and 161:
Page 162 and 163:
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
166 Chapter I. Heuristiker för utv
Page 178 and 179:
168 Chapter J. Found issues in heur
Page 180 and 181:
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
Page 188 and 189:
178 Chapter K. Utvärderingsmanus f
Page 190 and 191:
180 Chapter K. Utvärderingsmanus f
Page 192 and 193:
182 Chapter L. Resultat av utvärde
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
188 Chapter M. Resultat av utvärde
Page 200 and 201:
Page 202 and 203:
Page 204 and 205:
Page 206 and 207:
196 Chapter N. Resultat av utvärde
Page 208 and 209:
198 Chapter N. Resultat av utvärde
show all

Designing a persistent online strategy game - Department of ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?