3.3 programming fundamentals

1. Chapter 3.3
Programming Fundamentals

2. 2
Data Structures
 Arrays
 Elements are adjacent in memory (great
cache consistency)
 They never grow or get reallocated
 In C++ there's no check for going out of
bounds
 Inserting and deleting elements in the
middle is expensive

3. 3
Data Structures
 Linked lists
 Very cheap to add/remove elements.
 Available in the STL (std::list)
 Every element is allocated separately

Lots of little allocations
 Not placed contiguously in memory

4. 4
Data Structures
 Dictionaries
 Maps a set of keys to some data.
 std::map, std::hash, etc
 Very fast access to data
 Perfect for mapping IDs to pointers, or
resource handles to objects

5. 5
Data Structures
 Stacks
 First in, last out
 std::stack adaptor in STL
 Queues
 First in, first out
 std::deque

6. 6
Data Structures
 Bit packing
 Fold all necessary data into a smaller
number of bits
 Very useful for storing boolean flags

(pack 32 in a double word)
 Possible to apply to numerical values if we
can give up range or accuracy
 Very low level trick

Only use when absolutely necessary

7. 7
Object Oriented Design
 Concepts
 Class

Abstract specification of a data type
 Instance

A region of memory with associated semantics to
store all the data members of a class
 Object

Another name for an instance of a class

8. 8
Object Oriented Design
 Inheritance
 Models “is-a” relationship
 Extends behavior of existing classes by
making minor changes

9. 9
Object Oriented Design
 Inheritance
 UML diagram representing inheritance
E n e m y B o s s S u p e r D u p e r B o s s

10. 10
Object Oriented Design
 Polymorphism
 The ability to refer to an object through a
reference (or pointer) of the type of a parent
class
 Key concept of object oriented design

11. 11
Object Oriented Design
 Multiple Inheritance
 Allows a class to have more than one base
class
 Derived class adopts characteristics of all
parent classes
 Huge potential for problems (clashes,
casting, etc)
 Multiple inheritance of abstract interfaces is
much less error prone

12. 12
Component Systems
 Limitations of inheritance
 Tight coupling
 Unclear flow of control
 Not flexible enough
 Static hierarchy

13. 13
Component Systems
 Component system organization
 Use aggregation (composition) instead of
inheritance
 A game entity can “own” multiple
components that determine its behavior
 Each component can execute whenever the
entity is updated
 Messages can be passed between
components and to other entities

14. 14
Component Systems
 Component system organization
G a m e E n t i t y
N a m e = s w o r d
R e n d e r C o m p C o l l i s i o n C o m p D a m a g e C o m p P i c k u p C o m p W i e l d C o m p

15. 15
Component Systems
 Data-Driven Composition
 The structure of the game entities can be
specified in data
 Components are created and loaded at
runtime
 Very easy to change (which is very
important in game development)

16. 16
Component Systems
 Analysis
 Very hard to debug
 Performance can be a bottleneck
 Keeping code and data synchronized can
be a challenge
 Extremely flexible

Great for experimentation and varied gameplay
 Not very useful if problem/game is very well
known ahead of time

17. 17
Design Patterns
 Singleton
 Implements a single instance of a class with
global point of creation and access
 Don't overuse it!!!
S i n g l e t o n
s t a t ic S in g le t o n & G e t I n s t a n c e ( ) ;
/ / R e g u la r m e m b e r f u n c t io n s . . .
s t a t ic S in g le t o n u n iq u e I n s t a n c e ;

18. 18
Design Patterns
 Object Factory
 Creates objects by name
 Pluggable factory allows for new object
types to be registered at runtime
 Extremely useful in game development for
creating new objects, loading games, or
instantiating new content after game ships

19. 19
Design Patterns
 Object factory
O b j e c t F a c t o r y
P r o d u c t * C r e a t e O b je c t ( P r o d u c t T y p e t y p e ) ;
C r e a t e P r o d u c t
P r o d u c t

20. 20
Design Patterns
 Observer
 Allows objects to be notified of specific
events with minimal coupling to the source
of the event
 Two parts

subject and observer

21. 21
Design Patterns
 Observer
S u b j e c t
A t t a c h ( O b s e r v e r * ) ;
D e t a c h ( O b s e r v e r * ) ;
N o t if y ( ) ;
O b s e r v e r
U p d a t e ( ) ;
C o n c r e t e O b s e r v e r
U p d a t e ( ) ;
C o n c r e t e S u b j e c t

22. 22
Design Patterns
 Composite
 Allow a group of objects to be treated as a
single object
 Very useful for GUI elements, hierarchical
objects, inventory systems, etc

23. 23
Design Patterns
 Composite
C o m p o s i t e
O p e r a t io n ( ) ;
lis t < C o m p o n e n t * > c h ild r e n
S p e c i f i c C o m p o n e n t
O p e r a t io n ( ) ;
C o m p o n e n t
O p e r a t io n ( ) ;