Jan212010

Jan212010 - 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 Inheritance
 Polymorphism
 Collision
Detec;on
 January
21,
2010 Arnav
Jhala
 
 Adapted
from
Jim
Whitehead’s
slides
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Classifica;on
 •  Classifica;on
is
the
act
of
assigning
things
to
 categories of things. •  Examples:
 –  The
is‐a
rela;onship
 –  A
Volkwagen
JeOa
is a
(kind
of)
car.
 –  A
hot
dog
is a
(kind
of)
food.
 •  Classifica;on
is
at
the
heart
of
object‐oriented
 modeling.
 –  An
object‐oriented
class
represents
a
category
 •  Class
car,
Class
food
 –  Object
instances
(in
OO)
are
instances
of
categories
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Developing
classes
 •  The
process
of
taking
a
set
of
real
world
objects
 and
developing
its
associated
category
is
called
 abstrac'on.
 •  Example:
 –  If
I
give
you
the
set
of
food
items:
 •  Cheese
whizz,
hot
dog,
corn
chips,
bran
flakes,
chicken
 –  The
act
by
which
you
create
the
category
food
and
call
 these
all
examples
of
food,
is
abstrac2on.
 •  The
process
of
abstrac;on
is
used
to
determine
 what
classes
should
be
in
your
soXware
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Hierarchies
of
Categories
 •  Some;mes
there
are
situa;ons
where
you
have
mul;ple
levels
of
 categories
 –  Category1
is
a
(kind
of)
Category2
is
a
(kind
of)
Category3
 –  Example
 •  •  •  •  A
cell
phone
is a
(kind
of)
telephone
 A
wired
phone
is a
(kind
of)
telephone
 An
iPhone
is a
(kind
of)
cell
phone
 Telephone
is
an
abstract
category
 •  In
soXware,
may
want
to
represent
things
like
telephone,
but
never
have
 direct
instances
 –  Only
want
instances
of
sub‐categories
 –  Example:
want
to
represent
telephones,
but
do
not
want
instances
of
 telephone.
Only
want
instances
of
cell
phone,
or
wired
phone.
 –  In
soXware,
we
would
like
telephone
to
provide
details
about
all
telephones…
 –  
…but
not
to
give
cell
phone
or
wired‐phone
specific
informa;on
 •  Cell
phones
have
text
messaging,
wired
phones
do
not
 •  All
phones
have
a
telephone
number,
can
make
and
receive
calls
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Represen;ng
Abstract
Categories
 •  Two
ways
to
represent
abstract
categories
 –  Interface
 •  Class
proper;es
 •  Method
names
and
parameter
lists,
but
no
method
 implementa'ons
of
any
methods.
 •  Class
variables
 •  Can
have
a
mixture
of:
 –  Abstract
Class
 –  Methods
that
are
fully
implemented
 »  Might
(or
might
not)
be
overridden
in
subclasses
 –  Methods
that
only
have
a
name
and
a
parameter
list
 »  Abstract
method
 »  Must
be
implemented
in
subclasses
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Interface
 •  Describes
a
set
of
methods,
proper;es
that
must
 be
implemented
by
all
subclasses
 –  But,
no
implementa;on
details
are
given
 –  Subclasses
can
implement
the
methods
and
 proper;es
as
they
see
fit
 •  So
long
as
they
match
the
types
of
the
proper;es,
method
 return
values,
and
method
parameters
 •  Describes
the
external
boundary
of
class
 –  What
other
classes
need
to
know
to
use
its
features
 –  Provides
no
implementa;on
detail
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Defining
an
interface
 [attributes] [access-modifiers] interface identifier [:base-interface(s)] { interface-body } Simple example: interface ITelephone { public string PhoneNum {get; set;} // Phone number property, can read and write } void display_phone_num(); // Output phone number •  Naming
conven;on:
 –  Put
capital
“I”
in
front
of
interface
name
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Using
an
Interface
 interface ITelephone { public string PhoneNum {get; set;} // Phone number property, can read and write } void display_phone_num(); // Output phone number public cellphone : ITelephone { public string PhoneNum {get; set;} // Use automatic property to implement interface property public void display_phone_num() { System.Console.WriteLine(“cell phone number is {0}”, PhoneNum); } } •  Syntac;cally,
looks
like
inheritance
 •  Must
implement
all
aspects
of
interface
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Abstract
Classes
 •  Some;mes
you
want
to:
 –  Define
the
informa;on
passing
interface
for
a
class
 –  And
provide
implementa;ons
for
some
simple
 methods
that
all
subclasses
are
likely
to
use,
while
 only
providing
interfaces
for
some
other
methods
 which
subclasses
must
implement
 •  Can
do
this
with
an
interface
 •  An
abstract
class
looks
like
a
regular
class,
except
 –  Some
methods
are
marked
abstract
and
some
are
 marked
or
virtual
 •  Cannot
use
an
interface
for
this
 •  Define
an
abstract
class
instead
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Abstract
vs
Virtual
Methods
 •  An
abstract
method
 –  Only
the
name,
return
type,
and
parameter
list
is
provided
 –  There
is
no
implementa;on
–
subclasses
must
implement
 –  Must
use
override
keyword
in
implemen;ng
method
 •  A
virtual
method
 –  The
en;re
method
is
implemented
 •  Have
name,
return
type,
parameter
list,
and
implemen;ng
statements
 –  Use
of
virtual
keyword
signifies
that
subclasses
are
welcome
to
 override
 –  Subclasses
may
provide
new
implementa;on,
but
are
not
required
to
 do
so
 •  If
they
do,
must
use
override
keyword
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Example
of
Abstract
and
Virtual
Methods
 class Telephone { public string PhoneNum {get; set;} // Phone number property, can read and write virtual void display_phone_num() // Output phone number, might be overridden by subclasses { System.Console.WriteLine(“Telephone number is {0}”, PhoneNum); } abstract bool call(string num_to_call); subclasses } public cellphone : Telephone { public override void display_phone_num() // Overrides implementation in Telephone { System.Console.WriteLine(“Cell phone number is {0}”, PhoneNum); } public override bool call(string num_to_call) given in Telephone { … // implementation of calling logic } // Implements abstract method // Abstract class, must be implemented by } UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Overriding
methods
 •  Given:
class
B
is
a
subclass
of
class
A
 –  class
B:
A
{
…
}
 •  Methods
in
B
can
override
(re‐implement)
any
 method
in
A
 –  Do
not
need
to
use
override
keyword
for
this,
just
do
 it
 –  Only
need
to
use
override
when
method
in
A
is
 marked
virtual,
or
abstract
 –  Acts
as
a
way
of
forcing
programmer
to
focus
on
the
 inten;on
of
the
person
developing
the
parent
class
(A)

 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Interface
vs
Abstract
Class
 •  Interface
 –  Pro
 •  A
class
can
inherit
mul;ple
interfaces
 •  Interfaces
can
inherit
(specialize)
other
interfaces
 –  Can
have
rich
hierarchies
of
interfaces
 •  Can
create
containers
with
interfaces
 –  Hold
instances
of
any
kind
of
subclass
 •  Can
create
references
to
interfaces
 –  Can
refer
to
instances
of
any
kind
of
subclass
 –  Con
 •  Cannot
provide
any
implementa;on,
even
for
simple,
 generic
methods
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Interface
vs
Abstract
Class
(cont’d)
 •  Abstract
class
 –  Pro
 •  Can
provide
implementa;on
of
some
methods,
while
leaving
others
to
be
 implemented
by
subclasses
 •  Allows
deferring
some,
but
not
all,
implementa;on
decisions
to
subclass
 •  Useful
when
there
needs
to
be
a
fixed
call
order
among
methods
 •  Can
implement
method
that
defines
call
order,
but
leave
implementa;on
 of
called
methods
to
subclasses
 •  Template Method pa8ern –  Con
 •  Subclass
can
only
inherit
one
Abstract
class
 •  Abstract
class
must
be
top
of
inheritance
hierarchy
 •  Parent
class
may
make
some
implementa;on
decisions
subclass
cannot
 easily
change
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Interface
vs
Abstract
class
(cont’d)
 •  C#
code
tends
to
prefer
interfaces
over
abstract
 classes
 •  For
game
code
 –  Can
define
interfaces
for
specific
roles
of
objects
in
 game
 •  ICollidable
(for
objects
that
can
collide
with
one
another)
 –  Player,
Enemy,
Bullets
can
all
have
dis;nct
implementa;ons,
but
 s;ll
inherit
from
ICollidable
 •  Then,
use
List<ICollidable>
to
hold
all
collidable
objects
 –  One
list
can
hold
objects
of
type
Player,
Enemy,
and
Bullet,
even
 though
their
implementa;ons
are
very
different
 •  Collision
detec;on
then
only
uses
methods
and
proper;es
in
 ICollidable
interface
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Broad
vs
Narrow
Sweep
 •  With
many
small
objects
in
large
playfield
 •  Broad
sweep
 –  Each
object
only
has
the
poten;al
to
collide
with
nearby
 objects
 –  Perform
a
quick
pass
over
n
objects
to

 determine
which
pairs
have
poten;al
 to
intersect,
p
 –  Perform
p
x
p
check
of
object
 pairs
that
have
poten;al
to
 intersect
 •  Narrow
sweep
 •  Drama;cally
reduces
#
of
checks
 Mushihimesama
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Broad
sweep
approaches
 •  Grid
 –  –  –  –  Divide
playfield
into
a
grid
of
squares
 Place
each
object
in
its
square
 Only
need
to
check
contents
of
square
against
itself
and
neighboring
squares
 See
hOp://www.harveycartel.org/metanet/tutorials/tutorialB.html
for
 example
 •  Space
par;;oning
tree
 •  Applica;on‐specific
 –  Subdivide
space
as
needed
into

 rectangles
 –  Use
tree
data
structure
to
point

 to
objects
in
space
 –  Only
need
to
check
tree
leaves
 –  Quadtree,
Binary
Space
Par;;on
(BSP)
 tree
 –  2D‐shooter:
only
need
to
check
 for
collision
against
ship
 –  Do
quick
y
check
for
broad
sweep
 Point
Quadtree
(Wikipedia)
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Space
Par;;on
Grid
 •  Subdivide
space
into
a
grid
 –  Each
cell
in
the
grid
holds
a
list
of
the
objects
contained
in
the
cell
 –  Objects
that
overlap
cells
are
placed
in
mul;ple
cells
 –  One
approach:
 class Grid { // The collision grid // Grid is a 2D array, where each element holds a list of IGameObject List<IGameObject>[,] grid; int grid_cols; // # of grid columns int grid_rows; // # of grid rows int cell_x; // x width of each grid cell int cell_y; // y width of each grid cell … This
is
a
rela;vely
memory
intensive
approach.
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Grid
Cell
Size
Issues
 •  Grid
too
fine
 –  Cell
size
similar
to
object
size
 –  Many
objects
will
overlap
cells
 –  Slows
update
and
collision
checks
 –  Few
overlaps
(good)
 –  Larger
number
of
n
x
n
checks
within
a
cell
 –  Complexity
of
object
geometry
makes

 pairwise
comparison
too
hard
 –  Solu;on:
make
grid
size
smaller,
objects

 broken
up
into
smaller
pieces
 –  Can
happen
if
object
sizes
vary
widely
 Grid
too
coarse
 (complexity)
 Grid
too
fine
 •  Grid
too
large
 •  Grid
too
coarse
with
respect
to

 object
complexity
 •  Grid
too
large
and
too
fine
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Grid
Collision
Test
 •  Within
each
cell
 –  Compare
each
object
in
cell
with
every
other
 object
in
cell
 // Simple cell compare – does twice as many compares as –  Pairwise
comparison,
but
only
within
cells
 necessary void cell_collide(int row, int col) { foreach (IGameObject g in grid[row,col]) { foreach (IGameObject h in grid[row,col]) { if (g == h ) continue; if (object_test(g,h) == true) { g.collided = true; h.collided = true; } } } } UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Object
Update
 •  When
an
object
moves,
it
may
change
cell
loca;on
 •  Need
to
compute
cell(s)
holding
object
at
new
loca;on
 –  May
be
more
than
one
due
to
overlap
 •  If
new
cell,
add
object
to
cell
 –  This
is
O(1),
since
only
adding
to
end
of
list
 •  If
leaving
exis;ng
cell,
need
to
remove
from
list
 –  Naïve
approach:
O(#
elems
in
cell),
since
need
to
traverse
lists
to
find
 object
to
remove
 •  A
problem,
since
fast
moving
objects
may
mean
large
frac;on
of
objects
 need
to
update
each
;ck.
Approaches
O(n2)
 –  BeOer
approach:
have
each
game
object
maintain
pointer
back
to
its
 loca;on
in
list
in
each
cell
 •  But,
requires
you
to
write
your
own
linked
list
class
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Collision
Detec;on
 •  Collision
detec;on
 –  Determining
if
two
objects
intersect
(true
or
false)
 –  Example:
did
bullet
hit
opponent?
 –  Determining
when
two
objects
came
into
contact
 –  Determining
where
two
objects
intersect
 •  At
what
point
during
their
mo;on
did
they
intersect?
 •  Example:
Two
balls
needing
to
bounce
off
each
other
 •  Which
points
on
the
objects
touch
during
a
collision?
 •  Example:
Pong:
where
ball
hits
paddle
is
important
 •  Collision
resolu;on
(collision
determina;on)
 •  Complexity
of
answering
these
ques;ons
increases
in
 order
given
 –  If
<
when
<
where
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Key
to
collision
detec;on:
scaling
 •  Key
constraint:
only
16.667ms
per
clock
;ck
 –  Limited
;me
to
perform
collision
detec;on
 •  Object
shapes
in
2D
games
can
be
quite
complex
 –  Naïve:
check
two
objects
pixel‐by‐pixel
for
collisions
 •  Many
objects
can
poten;ally
 
collide
 –  Naïve:
check
every
object

 pair
for
collisions
 •  Drawback
of
naïve
approach
 –  Takes
too
long
 –  Doesn’t
scale
to
large
numbers
 
of
objects
 •  Approaches
for
scaling
 –  Reduce
#
of
collision
pairs
 –  Reduce
cost
of
each
collision
check
 Chu
Chu
Rocket,
Dreamcast
 UC
Santa
Cruz
 Naïve
Collision
Detec;on:
n
x
n
 checking
 Computer
Science
–
Game
Design
 •  Assume
 –  n
objects
in
game
 –  All
n
objects
can
poten;ally
intersect
with
each
other
 •  Conceptually
easiest
approach
 –  Check
each
object
against
every
other
object
for
 intersec;ons
 –  Leads
to
(n‐1)
+
(n‐2)
+
…
+
1
=
n(n‐1)/2
=
O(n2) checks
 –  Done
poorly,
can
be
exactly
n2
checks

 –  Example:
420
objects
leads
to
87,990
checks,
per
clock
 ;ck
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Broad
vs
Narrow
Sweep
 •  With
many
small
objects
in
large
playfield
 •  Broad
sweep
 –  Each
object
only
has
the
poten;al
to
collide
with
nearby
 objects
 –  Perform
a
quick
pass
over
n
objects
to

 determine
which
pairs
have
poten;al
 to
intersect,
p
 –  Perform
p
x
p
check
of
object
 pairs
that
have
poten;al
to
 intersect
 •  Narrow
sweep
 •  Drama;cally
reduces
#
of
checks
 Mushihimesama
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Broad
sweep
approaches
 •  Grid
 –  –  –  –  Divide
playfield
into
a
grid
of
squares
 Place
each
object
in
its
square
 Only
need
to
check
contents
of
square
against
itself
and
neighboring
squares
 See
hOp://www.harveycartel.org/metanet/tutorials/tutorialB.html
for
 example
 •  Space
par;;oning
tree
 •  Applica;on‐specific
 –  Subdivide
space
as
needed
into

 rectangles
 –  Use
tree
data
structure
to
point

 to
objects
in
space
 –  Only
need
to
check
tree
leaves
 –  Quadtree,
Binary
Space
Par;;on
(BSP)
 tree
 –  2D‐shooter:
only
need
to
check
 for
collision
against
ship
 –  Do
quick
y
check
for
broad
sweep
 Point
Quadtree
(Wikipedia)
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Reducing
Cost
of
Checking
Two
Objects
for
Collision
 •  General
approach
is
to
subs;tute
a
bounding
 volume
for
a
more
complex
object
 •  Desirable
proper;es
of
bounding
volumes:
 –  Inexpensive
intersec;on
tests
 –  Tight
fiwng
 –  Inexpensive
to
compute
 –  Easy
to
rotate
and
transform
 –  Low
memory
use
 Megaman
X1
(Capcom).
White
boxes
represent
bounding
 volumes.
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Common
Bounding
Volumes
 Circle/Sphere
 Axis‐Aligned
 Bounding
Box
 (AABB)
 Oriented
 Bounding
Box
 (OBB)
 Convex
Hull
 BeOer
bounds,
beOer
culling
 Faster
test,
less
memory
 •  Most
introductory
game
programming
texts
call
 AABBs
simply
“bounding
boxes”
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Circle
Bounding
Box
 •  Simple
storage,
easy
intersec;on
test
 Compare
Euclidean
distance
 •  Rota;onally
invariant
 c
 r
 between
circle
centers
against
sum
 of
circle
radii.
 bool circle_intersect(circle a, circle b) { Point d; // d = b.c – a.c d.x = a.c.x – b.c.x; d.y = a.c.y – b.c.y; int dist2 = d.x*d.x + d.y*d.y; // d dot d int radiusSum = a.r + b.r; if (dist2 <= radiusSum * radiusSum) { return true; } else { return false; } struct circle { Point c; // center int r; // radius } struct Point { int x; int y; } } UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Axis‐Aligned
Bounding
Boxes
(AABBs)
 •  Three
common
representa;ons
 –  Min‐max
 min
 max
 // min.x<=x<=max.x // min.y<=y<=max.y struct AABB { Point min; Point max; } struct Point { int x; int y; } –  Min‐widths
 min
 dx
 dy
 // min.x<=x<=min.x+dx // min.y<=y<=min.y+dy struct AABB { Point min; int dx; // x width int dy; // y width } ry
 rx
 –  Center‐radius
 Can
easily
be
extended
to
3D
 c
 // | c.x-x | <= rx | c.y-y | <= ry struct AABB { Point c; int rx; // x radius int ry; // y radius } UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Axis
Aligned
Bounding
Box
Intersec;on
(min‐max)
 •  Two
AABBs
intersect
only
if
 they
overlap
on
both
axes
 bool IntersectAABB(AABB a, AABB b) { { if (a.max.x <
b.min.x || a.min.x < b.max.x) return false; if (a.max.y <
b.min.y || a.min.y < b.max.y) return false; } return true; a.max.y<b.min.y
 a.max.x<b.min.x
 a.min.x=b.min.x
 a.min.x>b.max.x
 a.min.y=b.min.y
 a.min.y>b.max.y
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 Axis
Aligned
Bounding
Box
Intersec;on
(min‐width)
 •  Two
AABBs
intersect
only
if
 they
overlap
on
both
axes
 bool IntersectAABB(AABB a, AABB b) { { int t; t=a.min.x-b.min.x; if (t > b.dx || -t > a.dx) return false; t=a.min.y-b.min.y; if (t > b.dy || -t > a.dy) return false; return true; } // Note: requires more operations than // min-max case (2 more subtractions, 2 more negations) ‐(a.min.y‐ b.min.y)>a.dy
 ‐(a.min.x‐ b.min.x)>a.dx
 a.min.x=b.min.x
 (a.min.x‐ b.min.x)>b.dx
 a.min.y=b.min.y
 (a.min.y‐ b.min.y)>b.dy
 UC
Santa
Cruz
 Computer
Science
–
Game
Design
 AABB
Intersec;on
(center‐radius)
 •  Two
AABBs
intersect
only
if
 they
overlap
on
both
axes
 bool IntersectAABB(AABB a, AABB b) { { if (Abs(a.c.x – b.c.x) > (a.r.dx + b.r.dx)) return false; if (Abs(a.c.y – b.c.y) > (a.r.dy + b.r.dy)) ) return false; return true; } // Note: Abs() typically single instruction on modern processors a.c.y‐b.c.y
>
 a.ry+b.ry
 b.c.x‐a.c.x
>
 a.rx+b.ry
 a.c.x=b.c.x
 a.c.x‐b.c.x
>
 a.rx+b.rx
 b.c.y‐a.c.y
>
a.ry+b.ry
 a.c.y=b.c.y
 ...
View Full Document

This note was uploaded on 11/10/2010 for the course CMPS 20 taught by Professor Jhala,a during the Spring '10 term at UCSC.

Ask a homework question - tutors are online