Requirements in Conflict Player vs. Designer vs. Cheater David - - PowerPoint PPT Presentation

Requirements in Conflict

Player vs. Designer vs. Cheater

David Callele David Callele Eric Neufeld Eric Neufeld Kevin Schneider Kevin Schneider {callele, eric, kas}@cs.usask.ca {callele, eric, kas}@cs.usask.ca

David Callele et al., RE2008 David Callele et al., RE2008 2 2

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

Stakeholder Diversity

• Producers

Producers

• Designer, Developer, Publisher,

Designer, Developer, Publisher, Distributor, Vendor Distributor, Vendor

• Financier, Marketer, Media, After

Financier, Marketer, Media, After-

• market

market Suppliers, Regulator, Society Suppliers, Regulator, Society

• Consumers

Consumers

• Game players

Game players

• Player

Player vs.

• vs. Game (PvG)

Game (PvG)‏‏

• • Player

Player vs.

• vs. Player (PvP)

Player (PvP)‏‏

David Callele et al., RE2008 David Callele et al., RE2008 3 3

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

Producer Requirements

• Game Design and Implementation

Game Design and Implementation

• Gameplay (emotional) experience

Gameplay (emotional) experience

• Financial success

Financial success

• Security

Security

• Artistic vision

Artistic vision

• IP protection

IP protection

• Integrity of gameplay experience

Integrity of gameplay experience

• Positive player experience

Positive player experience

David Callele et al., RE2008 David Callele et al., RE2008 4 4

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

Consumer Requirements

• Emotional experience (fun, escape,

Emotional experience (fun, escape, accomplishment) accomplishment)

• Value for my money

Value for my money

• Some control over the gameplay

Some control over the gameplay experience experience

• Give me at least

Give me at least some some choices! choices!

• Self

Self-

• validation

validation

David Callele et al., RE2008 David Callele et al., RE2008 5 5

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

The Problem

• No game is perfectly designed

No game is perfectly designed

• Player feels betrayed

Player feels betrayed

• Puzzles too hard / easy

Puzzles too hard / easy

• Gameplay is repetitive / boring / takes

Gameplay is repetitive / boring / takes too long too long

• Can't play just the fun parts

Can't play just the fun parts

• Can't fix the bad parts

Can't fix the bad parts

David Callele et al., RE2008 David Callele et al., RE2008 6 6

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

Conflict: Who has Control?

• Constructive stakeholders

Constructive stakeholders

• Work to improve a (flawed) experience

Work to improve a (flawed) experience

• Destructive stakeholders

Destructive stakeholders

• Work to interfere with the gameplay experience

Work to interfere with the gameplay experience

• Cheat: the game, other players

Cheat: the game, other players

• Destructive infrastructure attacks

Destructive infrastructure attacks

• Disruptive gameplay (a.k.a.

Disruptive gameplay (a.k.a. griefing) griefing)‏‏

• • Security threats anticipated by

Security threats anticipated by a a priori priori security requirements security requirements

David Callele et al., RE2008 David Callele et al., RE2008 7 7

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

The Proposal

• Use in

Use in-

• game justice systems as a

game justice systems as a metaphor for just metaphor for just-

• in

in-

• time

time requirements negotiation requirements negotiation

• Gameplay requirements

Gameplay requirements ↔ ↔ Laws Laws

• Justice systems

Justice systems

• Authority

Authority

• Penalty

Penalty

• Enforcement

Enforcement

• Recidivism

Recidivism

David Callele et al., RE2008 David Callele et al., RE2008 8 8

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

Prior Experience

• Administrative Control

Administrative Control

• Developer acts as judiciary

Developer acts as judiciary

• Player Control

Player Control

• Usually, with assistance of developer

Usually, with assistance of developer

• A Tale In The Desert

A Tale In The Desert

• Player Classing

Player Classing

• Players for virtual world (PvG)

Players for virtual world (PvG)‏‏

• • Players for combat (PvP)

Players for combat (PvP)‏‏

David Callele et al., RE2008 David Callele et al., RE2008 9 9

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

Discussion

• Dynamic RE techniques for

Dynamic RE techniques for

• Eliciting and capturing requirements

Eliciting and capturing requirements

• Translating requirements into laws

Translating requirements into laws

• Translating laws into gameplay

Translating laws into gameplay

• A priori vs Runtime requirements

A priori vs Runtime requirements

• Is it possible?

Is it possible?

• Can we handle the repercussions?

Can we handle the repercussions?

• Is it worth it?

Is it worth it?

David Callele et al., RE2008 David Callele et al., RE2008 10 10

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

Extension to Other Areas

• Is the concept applicable to other

Is the concept applicable to other areas? areas?

• In what manner?

In what manner?

• Are specific techniques applicable?

Are specific techniques applicable?

David Callele et al., RE2008 David Callele et al., RE2008 11 11

• Dept. of Computer Science, U of S
• Dept. of Computer Science, U of S

Conclusions

• Realtime requirements negotiation

Realtime requirements negotiation could be implemented via in could be implemented via in-

• game

game justice systems justice systems

• Transition from concept to

Transition from concept to implementation is difficult implementation is difficult

• Extensibility to other domains is still an

Extensibility to other domains is still an

• pen question
• pen question