Jan142010

Jan142010 - UC
Santa
Cruz
...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: UC
Santa
Cruz
 Computer
Science
–
Game
Design
 CMPS 20: Game Design Experience Imagine
Cup
 Team
Forma9on
 XNA
Input
 January
14,
2010 Arnav
Jhala
 
 Adapted
from
Jim
Whitehead’s
slides
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Announcements
 •  Team
Forma9on
(Details
are
on
the
website)
 –  –  –  –  Team
member
names
and
bio
 Contact
Informa9on
 Means
of
communica9on
 Loca9on
of
mee9ngs
 •  Once
teams
are
formed
I
will
randomly
assign
more
members
in
 teams
of
<4
students
(combine
two
2
person
teams)
 •  This
informa9on
must
be
submiSed,
typewriSen,
on
a
piece
of
 paper.
AUer
submission
of
this
assignment,
each
team
member
will
 be
expected
to
know
this
informa9on,
so
you
should
take
this
 opportunity
to
add
phone
numbers
to
cell
phones,
email
addresses
 to
email
applica9ons,
etc.
 •  Details
of
sec9ons
are
now
on
the
webpage
 •  Link
to
Moodle
class
page
is
now
on
the
main
class
homepage
 •  Email
TA
David
Seagal
or
me
for
Moodle
related
issues
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Kenny
Spade:
Imagine
Cup
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Upcoming
Project
Deliverable
 •  Game
Concept
Document
 –  A
compelling
document
that
sells
your
game
concept
 –  Title
page
 –  Overview
page
 •  Table
at
top:
game
genre,
pla]orm
(PC/XBox),
team
size
 •  Key
points
sec9on
 •  Title
of
game,
name
of
group,
name
of
team
members,
sample
artwork
 –  Bulleted
list
of
important
elements
of
gameplay
 –  Goal
of
game,
what
makes
game
unique,
main
characters,
main
fic9onal
elements
 –  Sample
artwork
image
to
give
feel
of
the
game
 –  Biographies
 •  True,
pocket
biographies
of
each
team
member
(1‐2
paragraphs
each)
stressing
experience
that
 makes
you
a
strong
game
designer
 •  Fic9onal
background,
brief
descrip9on
of
characters,
goal
of
player
in
game,
how
does
player
 interact
with
the
game,
brief
descrip9on
of
levels,
game
audience,
other
important
elements
as
 needed.
 •  Hand‐drawn
sketches
are
fine
 –  1‐3
pages
giving
a
textual
descrip9on
of
the
game
 –  1‐2
pages
of
sample
conceptual
artwork
 •  See
template
and
evalua9on
criteria
on
course
website
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Game
Input
 •  XNA
Framework
supports
three
input
sources
 –  Xbox
360
controller
 •  Wired
controller
under
Windows
 •  Wireless
or
wired
for
Xbox
360
 •  Up
to
4
at
a
9me
 •  Good
default
for
Windows
games
 •  Xbox
360
also
supports
USB

 keyboards
 •  Windows
only
(no
Xbox
360
support)
 –  Keyboard
 –  Mouse
 •  Poll
for
input
 –  Every
clock
9ck,
check
the
state
of
your
input
devices
 –  Generally
works
OK
for
1/60th
second
9cks
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Digital
vs
Analog
Controls
 •  Input
devices
have
two
types
of
controls
 •  Digital
 –  Reports
only
two
states:
on
or
off
 –  Keyboard:
keys
 –  Controller
A,
B,
X,
Y,
Back,
Start,
D‐Pad
 •  Analog
 –  Report
a
range
of
values
 –  XBox
360
controller:
‐1.0f
to
1.0f
 –  Mouse:
mouse
cursor
values
(in
pixels)
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Input
Type
Overview
 Input Device Xbox 360 Controller Digital Buttons 14 Analog Controls 4 Vibration Win? Xbox? Number Yes Yes (wired or wireless with adapter) Yes Yes (wireless or wired) 4 Keyboard >100 0 No Yes 1 Mouse 5 3 No Yes No 1 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Xbox
360
Controller
Input
 •  Every
clock
9ck
 –  Get
state
of
controller
 •  Call
GetState()
on
GamePad
class
 •  Pass
in
PlayerIndex
 –  PlayerIndex.One,
PlayerIndex.Two,
…
 –  Corresponds
to
lit
region
in
“ring
of
light”
 –  Check
if
controller
is
connected
 •  Returns
a
GamePadState
structure
 •  IsConnected
boolean
in
GamePadState
 –  Check
GamePadState
for
current
state
of
digital
and
analog
 inputs
 –  Recall
that
update()
is
called
every
clock
9ck
 •  Get
input
in
update(),
or
a
method
called
from
it
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 GamePad
Class
 public static class GamePad { public static GamePadCapabilities GetCapabilities(PlayerIndex playerIndex); public static GamePadState GetState(PlayerIndex playerIndex); public static GamePadState GetState(PlayerIndex playerIndex, GamePadDeadZone deadZoneMode); public static bool SetVibration(PlayerIndex playerIndex, float leftMotor, float rightMotor); } •  A
sta2c
class
 –  Do
not
need
to
create
an
instance
to
use
 –  All
methods
are
sta9c
 •  GetState
 –  Retrieve
current
state
of
all
inputs
on
one
controller
 •  SetVibra9on
 –  Use
to
make
controller
vibrate
 •  GetCapabili9es
 –  Determine
which
input
types
are
supported.

 –  Can
check
for
voice
support,
and
whether
controller
is
connected.
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 C#
Structs
 •  A
struct
in
C#
is
a
lightweight
alterna9ve
to
a
class
 •  Similar
to
class
 –  Can
have
constructors,
proper9es,
methods,
fields,
 operators,
nested
types,
indexers
 •  Different
from
class
 –  Struct
does
not
support
inheritance,
or
destructors
 –  Is
a
value
type
(classes
are
reference
types)
 •  Rule
of
thumb:
 –  Use
structs
for
types
that
are
small,
simple,
similar
in
 behavior
to
built‐in
types
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 GamePadState
Struct
 public struct GamePadState { public static bool operator !=(GamePadState left, GamePadState right); public static bool operator ==(GamePadState left, GamePadState right); public GamePadButtons Buttons { get; } public GamePadDPad DPad { get; } public bool IsConnected { get; } public int PacketNumber { get; } public GamePadThumbSticks ThumbSticks { get; } public GamePadTriggers Triggers { get; } } •  Proper9es
for
reading
state
of
the
GamePad
 –  –  –  –  Digital
Input:
BuSons,
DPad
 Analog
Input:
ThumbS9cks,
Triggers
 Check
connec9on
state:
IsConneced
 PacketNumber
 •  Number
increases
when
gamepad
state
changes
 •  Use
to
check
if
player
has
changed
gamepad
state
since
last
9ck
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 GamePadBuSons
Struct
(BuSons)
 GamePadState m_pad; // create GamePadState struct m_pad = GamePad.GetState(PlayerIndex.One); // retrieve current controller state if (m_pad.Buttons.A == ButtonState.Pressed) // do something if A button pressed| if (m_pad.Buttons.LeftStick == ButtonState.Pressed) // do something if left stick button pressed if (m_pad.Buttons.Start == ButtonState.Pressed) // do something if start button pressed •  Proper9es
for
retrieving
current
buSon
state
 –  A,
B,
X,
Y
 –  Start,
Back
 –  LeUS9ck,
RightS9ck
 •  When
you
press
straight
down
on
each
joys9ck,
is
a
buSon
press
 –  LeUShoulder,
RightShoulder
 •  Possible
values
are
given
by
BuSonState
enumera9on
 –  Released
–
buSon
is
up
 –  Pressed
–
buSon
is
down
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 GameDPad
Struct
(DPad)
 GamePadState m_pad; m_pad = GamePad.GetState(PlayerIndex.One); if (m_pad.DPad.Up == ButtonState.Pressed) pressed| if (m_pad.DPad.Left == ButtonState.Pressed) pressed // create GamePadState struct // retrieve current controller state // do something if DPad up button // do something if DPad left button •  Proper9es
for
retrieving
current
DPad
buSon
state
 –  Up,
Down,
LeU,
Right
 •  Possible
values
are
given
by
BuSonState
 enumera9on
 –  Released
–
buSon
is
up
 –  Pressed
–
buSon
is
down
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 GamePadThumbs9cks
Struct
(Thumbs9cks)
 GamePadState m_pad; // create GamePadState struct m_pad = GamePad.GetState(PlayerIndex.One); // retrieve current controller state if (m_pad.Thumbsticks.Left.X > 0.0f) // do something if Left joystick pressed to right| if (m_pad.Thumbsticks.Right.Y <
0.0f) // do something if Right joystick pressed down •  Each
thumbs9ck
has
X,
Y
posi9on
 –  Ranges
from
‐1.0f
to
1.0f
 •  LeU
(‐1.0f),
Right
(1.0f),
Up
(1.0f),
Down
(‐1.0f)
 •  0.0f
indicates
not
being
pressed
at
all
 –  Represented
as
a
Vector2
 •  So,
have
 –  LeU.X,
LeU.Y,
Right.X,
Right.Y
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Joys9ck
Dead
Zone
 •  Joys9cks
typically
have
9ny
deflec9on
to
leU/right
or
up/down
 –  Leads
to
“driU”
if
uncompensated
 •  Dead‐zone
 –  Region
around
0.0f
that
is
interpreted
as
not‐moving
 –  Allows
joys9cks
to
have
a
small
amount
of
deflec9on
without
leading
 to
driU
 •  Three
ways
to
handle
this
 –  –  –  –  From
GamePadDeadZone
enumera9on
 IndependentAxes:
X
&
Y
each
have
separate
dead
zone
(default)
 Circular:
X
&
Y
combined
before
processing
dead
zone
 None:
No
processing,
applica9on
must
determine
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 GamePadTriggers
Struct
(Triggers)
 GamePadState m_pad; // create GamePadState struct m_pad = GamePad.GetState(PlayerIndex.One); // retrieve current controller state if (m_pad.Triggers.Left != 0.0f) // do something if Left trigger pressed down| if (m_pad.Triggers.Right >=
0.95f) // do something if Right trigger pressed all the way down •  Each
trigger
ranges
from
0.0f
to
1.0f

 –  Not
pressed:
0.0f
 –  Fully
pressed:
1.0f
 –  Represented
as
a
float
 •  Have
leU
and
right
triggers
 –  Proper9es:
LeU,
Right
 •  Demonstra*on of XNA Input Reporter u*lity –  creators.xna.com/en‐US/u*li*es/inputreporter UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Controller
Vibra9on
 •  Can
set
the
vibra9on
level
of
the
gamepad
 –  Call
SetVibra9on()
on
GamePad
class
 –  Pass
controller
number,
leU
vibra9on,
right
vibra9on
 •  LeU
motor
is
low
frequency
 •  Right
motor
is
high‐frequency
 •  Turn
vibra9on
full
on,
both
motors
 –  GamePad.SetVibra9on(PlayerIndex.One,
1.0f,
1.0f);
 •  Turn
vibra9on
off,
both
motors
 –  GamePad.SetVibra9on(PlayerIndex.One,
0f,
0f);
 UC
Santa
Cruz
 Computer
Science–
Game
Design
 Keyboard
Input
 •  Every
clock
9ck,
poll
state
of
keyboard
 –  Call
GetState()
on
Keyboard
class
 –  Check
if
a
specific
key
is
pressed
 •  •  •  •  •  KeyboardState
keyState
=
Keyboard.GetState()
 •  Keyboard
is
a
sta9c
class
 if
(keyState.IsKeyDown(Keys.keyname))
…
 Also,
IsKeyUp(Keys.keyname)
 Keys
is
an
enumera9on
of
keynames
 Provides
low‐level
access
to
keypress
informa9on
 –  Also,
GetPressedKeys()
 –  Can
determine
if
right/leU
ShiU
key
pressed,
for
example
 •  Returns
array
of
keys
currently
pressed
 •  If
length
of
array
is
zero,
no
keys
currently
pressed UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Mouse
Input
 •  Every
clock
9ck,
poll
state
of
the
mouse
 –  Call
GetState
on
Mouse
class
 –  MouseState
mouseState
=
Mouse.GetState();
 –  Mouse
is
a
sta9c
class
 –  X,
Y
:
posi9on
of
mouse
(int)
 –  LeUBuSon,
MiddleBuSon,
RightBuSon,
XBuSon1,
 XBuSon2
 –  ScrollWheelValue
(int)
 •  Either
Released
or
Pressed
(BuSonState
enumera9on)
 •  Scroll
wheel
represents
cumula9ve
change
over
life9me
of
the
 game
 •  MouseState
contains
a
series
of
proper9es
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Wrapper
Class
 •  What
if
you
want
to
use
the
controller,
if
present,
and
the
keyboard
 if
not?
 •  Create
an
input
wrapper
class
 –  Checks
both
controller
and
keyboard
input
 –  Has
a
series
of
proper9es
to
set/get
current
direc9on
state
 •  Example:
 –  If
controller
connected
AND
controller
DPad
up
arrow
pressed

 •  Set
wrapper’s
up
property
to
true
 –  Else
if
keyboard
Up
key
pressed
 •  Set
wrapper’s
up
property
to
true
 –  Else
 •  Set
wrapper’s
up
property
to
false
 •  Rest
of
applica9on
checks
input
wrapper
class
up
property
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Reading
 •  Read
Chapter
3
(User
Input
and
Collision
 Detec9on)
in
XNA 3.0 •  Download
and
try
XNA
Input
Recorder
demo,
 if
you
have
an
Xbox
360
controller
 •  Try
crea9ng
a
simple
XNA
program
to
collect
 keypress
input

 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Procedural
programming
paradigm
 •  Programs
are
composed
of
a
set
of
procedures
 –  Also
known
as
func9ons,
methods,
etc.
 –  Specify
a
sequence
of
statements
 •  Each
procedure
specifies
a
set
of
steps
in
the
overall
 computa9on
 –  Few
firm
criteria
for
how
to
decompose
a
problem
into
procedures
 •  Focus
is
on
determining
the
steps
in
the
computa9on,
and
the
 sequence
of
those
steps
 •  Some
data
is
passed
as
parameters,
much
data
is
leU
as
global
 variables
 –  Data,
and
the
procedures
that
operate
on
them,
may
be
in
different
 text
files
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Object‐oriented
programming
paradigm
 •  Programs
are
composed
of
objects
 •  An
object
is
composed
of
 •  An
object
is
expected
to
correspond
to
a
 significant
abstrac9on
in
the
applica9on
 •  It
is
possible
to
specialize
objects,
via
inheritance
 •  Class/object
dis9nc9on
 –  E.g.,
square
can
inherit
from
the
more
generic
shape
 –  Specifica9on
of
a
class,
vs.instances
of
a
class
 –  Data
 –  Methods
that
act
on
that
data
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Ways
Procedural
Designs
are
Expressed
in
C#
 •  Pure
procedural
 –  All
methods
are
sta9c,
and
found
in
the
same
class
as
main().
There
is
only
one
 class.

 –  Class
variables
act
as
global
variables.
 –  All
methods
are
sta9c,
and
found
in
the
same
class
as
main().
There
are
mul9ple
 classes,
but
other
classes
only
have
member
variables,
no
methods
(except
a
 constructor).
 –  Object‐orienta9on
only
used
to
cluster
related
global
variables
together
 –  Design
is
strongly
procedural,
but
classes
have
a
small
number
of
methods
defined
 on
them
 •  Pure
procedural
with
data
abstrac9on
 •  Procedural,
with
minor
object‐orienta9on
 •  In
the
vast
majority
of
cases
(and
un9l
you
have
substan9al
experience
as
a
 soUware
designer),
you
should
avoid
use
of
procedural
design
in
object‐ oriented
soUware.
 •  Demonstra*on of some of these from homework submissions UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Bad
Code
Smells
 •  Once
code
has
an
object‐oriented
design,
can
 then
focus
on
improving
its
design
 –  If
the
design
is
procedural,
can’t
even
begin
to
do
this
 •  Refactoring
literature
has
no9on
of
“code
smells”
 –  “If
it
s9nks,
change
it”
(M.
Fowler,
Refactoring)
 –  A
characteris9c
of
a
design
that
is
a
strong
indicator
it
 has
poor
structure,
and
should
be
refactored
 –  Code
smells
are
rules
of
thumb
 •  It’s
not
always
straigh]orward
that
a
bad
smell
must
lead
to
 a
refactoring.
Have
to
use
judgement.
 •  S9ll,
as
new
designers,
bad
code
smells
likely
mean
you
 should
change
your
code.
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Code
Smells:
Duplicated
Code
 •  Duplicated
code
(code
clones)
 –  The
same,
or
very
similar
code,
appears
in
many
 places
 –  Problem
 –  Example
from
homework
 •  A
bug
fix
in
one
code
clone
may
not
be
propagated
to
all
 •  Makes
code
larger
that
it
needs
to
be
 •  Adjacency
checks
to
print
warnings
(“I
smell
a
Wumpus”,
 etc.)
 •  Create
new
method
that
encapsulates
duplicated
code
 •  Replace
code
clones
with
method
call
 –  Fix:
extract method
refactoring
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Code
smells:
Long
Method
 •  Long
method
 –  A
method
that
has
too
many
lines
of
code
 •  How
long
is
too
long?
Depends.

 •  Over
20
is
usually
a
bad
sign.
Under
10
lines
is
typically
good.
 •  S9ll,
no
hard
and
fast
rules.

 •  The
longer
a
method,
the
harder
it
is
to
understand,
change,
 and
reuse
 •  Shoo9ng
logic,
Main
 –  Problem
 –  Example
from
homework
 –  Fix:
extract
method
 •  Take
chunks
of
code
from
inside
long
method,
and
make
a
 new
method
 •  Call
new
method
inside
the
now‐not‐so‐long
method.
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Code
smells:
Feature
Envy
 •  Feature
Envy
 –  Problem:
 –  A
method
in
one
class
uses
primarily
data
and
 methods
from
another
class
to
perform
its
work
 •  Seems
“envious”
ofthe
capabili9es
of
the
other
class
 •  Indicates
abstrac9on
fault.

 •  Ideally
want
data,
and
ac9ons
on
that
data,
to
live
in
the
 same
class.
 •  Feature
Envy
indicates
the
method
was
incorrectly
placed
in
 the
wrong
class
 •  Move
method
 –  Move
the
method
with
feature
envy
to
the
class
containing
the
 most
frequently
used
methods
and
data
items
 –  Fix:
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Code
smells:
Large
class
 •  Large
class
 –  A
class
is
trying
to
do
too
much
 –  Many
instance
variables
 –  Many
methods
 –  Indicates
abstrac9on
fault
 •  There
is
likely
more
than
one
concern
embedded
in
the
code
 •  Or,
some
methods
belong
on
other
classes
 •  Problem:
 •  Fix:
 –  Associated
with
duplicated
code
 –  Extract class
refactoring
 –  Move method
refactoring
 •  Take
a
subset
of
the
instance
variables
and
methods
and
create
a
new
class
with
 them
 •  This
makes
the
ini9al
(long)
class
shorter
 •  Move
one
or
more
methods
to
other
classes
 •  Example
from
homework:
 –  Class
containing
Main()
tends
to
have
too
much
game
logic
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Code
smells:
switch
statements
 •  Switch
statements
 –  The
cases
in
a
switch
statement
contain
logic
for
different
 types
of
instances
of
the
same
class
 –  In
object‐oriented
code,
this
indicates
new
subclasses
 should
be
created
 •  Problem
 –  The
same
switch/case
structure
appears
in
many
places
 •  Fix
 –  Create
new
subclasses
 –  Extract
method
to
move
case
block
logic
into
methods
on
 the
new
subclasses
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Code
smells:
Data
class
 •  Data
class
 –  A
class
that
has
only
class
variables,
geSer/seSer
methods/proper9es,
 and
nothing
else
 –  Is
just
ac9ng
as
a
data
holder
 •  Problem
 –  Typically,
other
classes
have
methods
with
feature
envy
 –  That
is,
there
are
usually
other
methods
that
primarily
manipulate
 data
in
the
data
class
 –  Indicates
these
methods
should
really
be
on
the
data
class
 –  Can
indicate
the
design
is
really
procedural
 •  Fix
 –  Examine
methods
that
use
data
in
the
data
class,
and
use
move
 method
refactoring
to
shiU
methods
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Homework
 •  Read
Chapter
4
in
Learning
XNA
3.0
on
Object‐ Oriented
Design
 •  Read
Chapter
1
(Refactoring,
a
First
Example)
 in
Mar9n
Fowler,
Refactoring
book
 –  Will
post
link
on
forum,
and
put
link
in
syllabus
on
 website
 •  Examine
your
Wumpus
source
code
for
code
 smells
 ...
View Full Document

Ask a homework question - tutors are online