Docstoc

Rules of Play Salen and Zimmerman

Document Sample
Rules of Play  Salen and Zimmerman Powered By Docstoc
					In this document: Salen & Zimmerman | Rules of Play (2003) Salen & Zimmerman | The Game Design Reader (2005) Adams & Rollings | Game Design and Development (2007) Fullerton, Hoffman & Swain | The Game Design Workshop (2004) Blythe, Overbeeke, Monk & Wright | Funology (2003) gamasutra.com: links and article summaries

Salen and Zimmerman | Rules of Play (2003)
a game prototype should be created and playtested at, absolutely the latest, 20 percent fof the way into a project schedule. (p.12) Meaningful play (p.34/35) - Emerges from the relationship between player action and system outcome. The meaning of an action in a game resides in the relationship between action and outcome - Occurs when the relationships between actions and outcomes in a game are both o discernable: the results of a player action are communicated back to the player in a perceivable way o integrated into the larger context of the game: e.g. moves in the beginning should have their impact on later moments in the game (like with chess: begin game, middle game, end game) Semiotics: study of meaning; how to signs represent? space of possibility: space in game of all possible actions and meanings. According to Caillois (p.74), a game is: - free: playing is not obligatory - separate: circumscribed within limits of space and time - uncertain - unproductive - governed by rules - make-believe (special awareness of a second reality or of a free unreality) Game, according to S&Z, p.80 A system in which players engage in an artificial conflict, defined by rules, that results in a quantifiable outcome. The lusory attitude is the state of mind required to enter into the play of a game. To play a game, a group of players accepts the limitatations of the rules because of the pleasure a game can afford.

p.83 A puzzle is a specific type of game since there's only 1 correct answer An RPG doesn't have a quantifiable outcome. lusory attitude: accepting the limitations posed by the game. (p.99) Constituative rules: underlying formal (logical) structures Operational rules: players' behaviour, e.g. printed out in rule books Implicit rules: unwritten rules, e.g. etiquette elegant rules allow a player to focus on the play experience rather than on the logic of the rules. p.171 Emergence in games: e.g. bluffing in poker (not explicitly stated in the rules, but...) games must possess a feeling of randomness, but not too much even games with pure chance can be meaningful if the players are given an equal number of turns. Redundancy in information can be used to balance out noise. card game vs. chess: card game has imperfect information since nto everything is always visible. p.211 Information can be known to: - all players: chess - one player only: cards in hand of player - the game only: cards on deck - randomly generated: dice with Ludo Fog of War: as in C&C, the game reveals information (shows map) when player makes a move (uncovering map). Digital games are especially good in this. Cybernetics: studies the behaviour of self-regulating systems. Game theory: - limited to fully rational players which don't exist in the real world - assumes that all players make their strategical moves simultaneously - results of a game theory game are measured in utility, represented by a number. - a payoff matrix is a grid of cells used to diagram the possible outcomes of a game theory problem. - Zero-sum game: gains of the winner are a high as the losses of the loser, like in chess, unlike in casinos. - saddle point is a single best solution for both players in a game - degenerate strategies or exploits can be used over and over again to become the victor. This diminishes meaningful play.

p.265 Game conflicts come in many forms: cooperative, individual, direct, indirect, ... All games are competitive in that players play against eachother or against a system All games are cooperative in that playing means engaging with the shared meanings of the game. Systemic cooperation = fundamental discursive cooperation that happens in every game Player cooperation = players working together to achieve a goal p.284 1 Standard player 2 Dedicated player 3 Unsportsmanlike player 4 Cheater 5 Spoil-sport (not accepting the authority of the game) 2 and 3 use degenerate strategies, which can spoil the game but can also enlarge the space of possibilities p.311 Play of the game is the experiential aspect of the game. Forms of play behaviour: - Game play: when players follow the rules of game in order to play it - Ludic activities: non game behaviors in which participants are "playing" such as tossing a ball in a circle - Being playful: state of being in a playful state of mind such as when the spirit of play is injected into some other action Play = free movement within a more rigid structure Caillois: - Agon: competitive play - Alea: chance-based play - Mimicry: simulation of make-believe - ilinx: vertigo or physically-based play These four can be plotted along an axis that runs from ludus (rule-bound) to paida (free-form play) p.327 the experience of play Play is experienced through participation Psychological processes by which video games are experienced (Sutton-Smith): - Concentration - Visual scanning - Auditory discriminations - Motor responses - Perceptual patterns of learning

Game design is a second-order design problem. A game designer only indirectly designs the player's experience, by directly designing the game rules. So because of that, the game has to be evaluated often to improve the experience. Core mechanic in a game is the essential moment-to-moment activity that players enact. The core mechanic is repeated over and over again in order to create the larger pattern of experience. Core mechanic breaks e.g. in Breakout when the wall is broken and the ball bounces a little further (providing a sort of climax in the game). p.360 Games are autotelic, providing experiences for their own sake.

Salen & Zimmerman | The Game Design Reader (2005)
p.6 Bartle designates 4 types of players: - Achievers: Are proud of their status in the game's built-in level hierarchy, and how short the time it took them to reach it - Explorers: Proud of their knowledge of the game;s finer point - Socialisers Proud of their friendships and their influence - Killers Proud of their reputation and their oft-practised fighting skills Important to notice is that how players play a game differs from what pleasures they want to get from it. P.21 Game design should be iterative. The fun and excitement of playing cannot be calculated in an abstract fashion: it must be experienced. Designers use case studies quite often, to analyze what works and (especially) what does not work. Make small changes, so it;s easier to see the effect of the modifications. p.440: We cannot create drama ; wecan only create the circumstances from which drama will emerge. Mechanics of a game include all its equipment: program code, game controllers, etc. Dynamics of a game refer to what behaviour arises from it. A game's aesthetics are its emotional content; all the kinds of fun that result from playing it.

Understanding how specific game behaviour evokes certain emotional reactions is one of the greatest challenges in game design. So in relation to drama in games we can ask ourselves: - How does drama function as an aesthetic of play? - What kinds of game dynamics can evoke drama? - From what kinds of mechanics do those dynamics emerge? Drama is only one of the game aesthetics of course: - Games can also challenge us - realize our fantasies - bring us in social contact - etc Dramatic tension = level of emotional investment in the story's conflict; the sense of concern, apphrehension and urgency with which we await the story's outcomes.

Dramatic tension comes from two factors: - Uncertainty The outcome is still unknown - Inevitability The contest is moving forward toward resolution Denouement: time between climax and end of story (game). Preparing the winner to win and the loser to lose. The game can be made close by force: limiting the maximum advantage of one player over another. An example of this is a cybernetic feedback system; e.g. in a racing game, the player that lies behind has an increased maximum speed to catch up (being a 'negative' feedback system). Another approach to this is illusion: making the players look more closer together than they actually are. Negative feedback can be a source of uncertainty Positive feedback can be an aid for denouement. Other sources of uncertainty: - pseudo feedback: it just looks asif there are negative feedback systems - escalation: more at stake at the end of a game, such as with the blinds in poker. - hidden energy: e.g. in a game of basketbal, a team can take the lead at the expenses of losing a lot of energy. Pool is another variant on this. - Fog of war: e.g. in civilisation, a player cannot see everything, thus decreasing the info available, causing uncertainty - decelerator: slow element such as a climbing net at the end of a game so that trailing player enters the net before the leading player has left it. - Cashing out: resetting score to 0. Best of 7 concepts; after one game, the score itself no longer counts.

Sources of unevitability: - Any mechanism that can function as a ticking clock. - increase in board size (e.g. in reversi) - waning deck sizes in Magic - depleting gold supplies in Warcraft - decreasing health bars in virtua figther Evaluating Fun and Usability in Computer Games with Children Wolmet Barendregt In evaluation of products, children can have different roles. However, it should be noted that they are less able to read, verbalise, concentrate and perform abstract logical thinking than adults. Summative evaluations: provide a number about a product (e.g. satisfaction) Formative evaluations: elicit points for improvement Age group categorizations: Children younger than 2.5 years cannot be used for usability evaluations since the can't deal with the input devices. Children older than 14 years are too much like adults. 2-5 years: preschool childrens attention span is rather low. Their motivation to please adults and their accommodation to the new (testing room) environment may change from moment to moment, making the test course rather unpredictive. 6-10years: can perform tasks and follow directions. They are willing to explore new things and willing to help. The younger part (6-7) can be a bit shy and inarticulate. Piaget: 2-7years:pre-operational stage:children acquire representation skills in mental imagery and especially language. They can only see the world from their own perspective. 7-11years: concrete operational stage: children develop logic and are able to use rules and units. At the same time, their thoughts remain very much to the present.

MUD = multi-user domain/dimension. Combines elements of role-playing games, hack and slash style computer games and social chat rooms

Adams and Rollings | Game Design and Development (2007)
The most important benefit computers bring to gaming is that the computer relieves the players of the burden of personally implementing the rules. This frees players to become deeply immersed. A game is a type of play activity, conducted in the context of a pretended reality, in which the participants try to achieve at least one arbitrary, nontrivial goalby acting in accordance with rules. (Adams & Rollings, 2007) Core Mechanism: Set of rules that can be implemented algorithmically. E.g. caterpillars move faster than snails. Interaction model: Relation between player's button presses and the actions within the game. Gameplay mode: Available gameplay and supporting user interface. E.g. a soccer game has multiple gameplay modes, e.g. normal play and when shooting a penalty kick (suddenly the mapping of the controls change). Shell menus/screens: Everything but the gameplay mode, so including save actions, start- and endscreen, ... build a part of a level, e.g. level 2. This prototype can include features such as: - basic shape of the game world - (temporary) textures - (temporary) models of props such as trees, furniture, etc. - paths planned for AI driven NPCs (Non-Player Characters) - Lighting design for the level - Locations of trigger points for key events (rigging) - (temporary) sound effects

Evaluate the level: - scale: has the level the right size? - pacing: does the flow of events feel good? - placement of objects & triggers: are they at the right place, to create the right experience? - aesthetics: is the level attractive and enjoyable? Refine this prototype until the right person(s) think it's OK, then "lock" it: after locking no more changes should be made. After that, the design document it will be given to the artists. (if the design document is not sufficiently detailed this can be accompanied by a thorough briefing). In a book like Adams and Rollings, the test procedure is described in which the whole game is tested by the design team itself. Only at the very last testing phase (Beta testing, p.424) the end-users are involved. tips: - get the scope right - avoid conceptual non-sequiturs (james bond blowup) - make atypical levels optional - don't show the player everything at once. Interesting research: - How to visualize the player's health in e.g. a FPS? - Bars - Face (as in Doom) - Number - "Redishness" - breath of the character - other? - movements of the character - body / car of the character (e.g. destruction derby) Cool combo: DanceDance Revolution + eye tracker + Wii controls on a FPS. action games - Interface issues: - keep minimum of necessary details present at screen - use graphical indicators rather than text - make maps user-friendly! (e.g. gamasutra study REF) - avatar, enemies and objects should be quickly identifiable (e.g. blue shirt of lara croft in TR) - simple control, clever mapping of controls (so big buttons for often used commands, not far from eachother) Strategy games – interface issues: interaction models at a large scale: moving large units of characters at once. it's challenging to set up the user interface so that the user can control the action at different scales. Windowed approaches are often used for this. However, many OS alike functions are not used since the games should not look too much like another piece of productivity software. Windows should behave as expected. Buttons should be clear and recognizable. Design both for beginning and advanced users. The former group needs clear and easy

ways to find commands; more advanced players need quick access. Commands should be grouped by functionality. RPGs – interface isues: RPGs permit are relatively large amount of possible actions for the player. This also means the interface is rather complex. Some rules (e.g. throwing dice) can be abstracted away. In fact, one of the interesting things of computer games is that the player does not need to know how all the rules are being implemented. Numbers of e.g. character improvement can be displayed (some players prefer to have the details, others think it's distracting them from the story). Avoid dull repetitive tasks such as 10 x clicking on a lock to pick it (assuming there's a 10% chance of opening it). Rather show progress bars. Also interrupt the player when a task is taking too long or danger arises. Sports games – interface issues: The interface (controls) changes continuously, e.g. in American football games. Mapping complex human motions onto a game controller is hard. Make similar actions in different modes (e.g. offensive and defensive jumping) use the same button. Pull-down menus and other things that look like the Pc desktop since that would interfere with the player's fantasy. Pop-ups and semitransparent windows make more sense, especially when they look like the screens on TV. Sports games are pretty much like action games, so the user interface should be as smooth and fluent as possible. Vehicle simulation – interface issues: The biggest challenge is to map the vehicle controls to the controls available on the pc/console. Many simulations require some simplification (e.g. flight simulators). Unlike in flight simulators, in car driving simulators speed is all-important:  give the player a speedometer.  vary the driving surface  include roadside objects  use sounds chapter 21 on companion website is about online games! Construction and Management Simulations: interface issues: Interfaces can be quite computer-like. Most important variables, such as money to work with, should be at the screen at all times. Adventure games: interface issues: Things to avoid: - puzzles only solvable by trial and error - conceptual non sequiturs - puzzles requiring outside knowledge - too many backward puzzles - too many fedEx (pick up and deliver) puzzles Implement both walk and run movements Recognizing active objects:

-

hunt and click (simply everything) permanently highlighted objects dynamically highlighted objects focus-of-attention highlighting

Create compelling characters, an interesting story and seamlessly integrate puzzles in the whole. Online games Online gaming is a technology rather than a genre. Online games offer opportunities for social interaction. The percentage of women playing online games is for this reason much greater than the percentage for offline games. Online games can have AI but not necessarily (e.g. for NPCs). Local games:  LAN games and physically local play Problems with local play:  Players share same TV, so little screen space per player.  No way of hiding info for other players on single TV  Limit on nr. of players Online gaming solves all of these problems. On the other hand, there are issues with respect to: - technical issues: - Communication model (e.g. p2p / client-server) to choose - transmission delay times - package loss - it's harder to suspend disbelief (no escapism due to e.g. social interaction) - misbehavior of players - need to produce content Design issues for online games: - arriving players (e.g. competition between old-timers and newcomers - disappearing players - real-time vs turn-based games (e.g. do not use more than 5 players in a turnbased game) - chat feature (include!) - collusion (avoid cheating possibilities) - technical security: - use a safe telecommunication protocol (encrypt data to be send) - don't store sensitive data on a player's pc - don't send the player data he isn't suppose to have - don't let the client perform sensitive operations Chapter 8. Creating the user experience

Some general principles: - be consistent - give good feedback - remember that the player is the one in control - limit the number of steps required to take an action - permit easy reversal of actions - minimize physical stress - don't strain the player's short term memory - group related screen-based controls and feedback mechanisms on the screen. - provide shortcuts for experienced players.

Fullerton, Hoffman & Swain | The Game Design Workshop (2004)
Playtesting isn't when the designer and her team play the game and talk about its features. That's called an internal design review. Also, playtesting isn't the QA team rigorously testing every element of the software for flaws. That's bug testing. It's also not about systematically analyzing how users interact with your software by recording their mouse movements, eye movements, navigation patterns, etc. That's usability testing. Main goal is: how to obtain useful feedback that helps you to improve the game. The development process consists of continual iterative steps of playtesting, evaluating and revising. Recruiting playtesters (low->high detail level ) - yourself - testing with confidants - people you don't know Playtest process: - welcome testers and thank them for participating - remind players that you are testing the game, not their skills. Give the, the rules, or let them start the application. - Ask testers to begin plaing as soon as they are ready. - Ask them to talk out loud throughout the game about what they're thinking, questions they may have. Warn them that you won't be able to answer their questions; you just want to know what they are. You won't be stepping in to help them, not because you don't want to, but because you want to where the problem exist with the game and how they solve those problems. - When they are finished playtesting, interview the playtesters or use the following methods to elicit additional feedback

-

Thank the playtesters fot their assistance and feedback. Provide a gift of thanks if you can afford it.

Ways of playtesting: - one-to-one - group testing - feedback forms - interview - open discussion (focus group) For improving the efficiency of playtests, controlled game situations can be used, such as:  the end of the game  a random event that rarely takes place  a special situation within the game  a particular level of the game  new features (cheat codes come in handy here, to quickly move to a certain part)

prototyping stage 1) foundations 2) structure 3) formal details 4) refinement

Functional?

Internally complete?

Balanced?

Fun?

Accessible?

X X X X X X X X

Functional: So that a person that's never played the game before can play it without help. Internal loopholes, spawn camping To avoid loopholes: - Use control situations - Do series of playtests where you instruct the players to attempt to disrupt the system - if possible find players that enjoy alternative or subversive solutions Balancing: Does the game meet the goals you've set for the player experience? (scope, complexity, fairness). Important for balancing is to divide your game into isolated subsystems, that can be altered separately (OO programming). Also

make one change at a time to properly assess the outcomes. Spreadsheets come in handy here. Balancing variables: all kinds of variables: number of players, size of play area, number of available resources, etc. etc.

Factors that can get (/keep) players attached to the game:






challenge  reaching and exceeding goals (hard? clear?)  competing against opponents  stretching personal limits  exercising difficult skills  interesting choices (drama and suspension come from this)  Consequences play  living out fantasies  social interaction  exploration and discovery  Collection  Stimulation  Self-expression and performance  Construction / destruction story  how are aspects of drama applied?  compelling, imaginative comprise?  storyline that drives the gameplay or emerges from it?  unique characters?  what is it about the story, the characters, etc. What's working and what's not for them?

Decisions to offer (the interesting choices). From important to less important:  critical  important  necessary  minor  unconsequential If your game only has the lowest importance aspects, something's wrong. However, you don't want your game to have only critical decisions either. There should be a dramatic arc, it's about creating the right dilemma's at the right moment.

Blythe, Overbeeke, Monk & Wright | Funology (2003)
Piaget divided play into 3 stages:

-

Mastery play (involving repetitive behavior) Symbolic play (fantasy and role playing) Play with rules (structured games)

Sengers: The Engineering of Experience The perspectives of the arts and the humanities also suggest the futility of formally trying to represent experience. Many humanists and artists feel that the complexity, messiness, ill-definedness and enigmatics are fundamental to the nature of human experience. We cannot fully represent experience within the software, and instead try to set up more nuanced relationships between (internal, formal, clean) code and (external, messy, complicated) experiences. I suggest the following heuristics: Hassenzahl - The thing and I Product features: content presentation functionality interaction Apparent product character: pragmatic attributes hedonic attributes Consequences: Appeal Pleasure Satisfaction

Goal mode: product as a means Action mode: using the product as an end in itself Blythe & Hassenzahl – The Semantics of Fun: Differentiating Enjoyable Experiences Fun / Distraction Triviality Repetition Spectacle Transgression Pleasure / Absorption Relevance Progression Aesthetics Commitment

Desmet – Measuring Emotion: Development and Application of an Instrument to Measure Emotional Response to Products.

"emotions guide, enrich and ennoble life; they provide meaning to everyday existence; they render the valuation placed on life and property" (=Cacioppo, J.T., Berntson, G.G., Larsen, J.T., Poehlmann, K.M. & Ito, T.A. (2001). The Psychophysiology of Emotion. In M. Lewis & J.M. Haviland-Jones (Eds.), Handbook of Emotion (2nd edition) (p.173)) Emotions consist of the following phenomena:

-

behavioral reactions (e.g. retreating) expressive reactions (e.g. smiling) physiological reactions (e.g. heart pounding) subjective feelings (e.g. being amused)

Non-verbal instruments: e.g. facial expression (MAX, FACS) Non-verbal rating scales such as SAM have advantages but also disadvantages since they do not measure distinct emotion but only generalized emotional states (in terms of underlying dimensions such as pleasantness and arousal).

Gamasutra.com
(http://www.gamasutra.com/view/feature/1662/game_law_scrum_deals__good_bad_. php) SCRUM: Game development method. What SCRUM refers to is the agile management of the development process with several levels of periodic review and adjustment of goals and tasks by the manager (sometimes referred to as the "SCRUM master"). - it is the increased efficiencies, a happy engaged team and the ability to iterate that result from the SCRUM model that is the “Good.” - often not economically feasible though (too vague to accept for financers like publishers due to e.g. lack of hard milestones) - as with any new technology that offers the benefits of higher efficiencies, the overhead of learning the new methodology often overshadows the value of the new process Guidelines for Developing Successful Games (Shelley) http://www.gamasutra.com/features/20010815/shelley_01.htm
I use "successful" here to mean the commercial success of a game: sales and profits.

Postmodernism and the Three Types of Immersion (Adams) http://www.gamasutra.com/features/20040709/adams_01.shtml

Other useful links
Identifying usability and fun problems in a computer game during first use and after some practice (W. Barendregt, M.M. Bekker, D.G. Bouwhuis and E. Baauw) http://dx.doi.org/10.1016/j.ijhcs.2006.03.004

Abstract This paper describes an experiment to discover the change in the types of detected problems and the attitude of children towards a game when user testing a computer game for young children during first use and after they have practiced with a game. Both the numbers of different types of identified problems and the severity of the

problems are investigated. Based on this knowledge, practitioners could adapt the set up of their user tests to effectively find as many aspects of the game as possible that merit change, according to the aims of the developers. The study shows that usability problems caused by a lack of knowledge were more often identified during first use. Furthermore, fun problems related to a too-high challenge level may disappear after some practice, whereas fun problems caused by the game taking over control for too long while the user wants to proceed playing the game were identified more often after some practice. The study shows that the impact severity of problems detected during first use was higher than when children had more practice with a game. As a result of these changes in experienced problems the commonly used measures efficiency, effectiveness and satisfaction increased when children had practiced with the game. Finally, the study also shows that the set of most severe problems identified during first use may be radically different from the set of most severe problems identified after some practice.


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:44
posted:11/28/2009
language:English
pages:17