Hotsticks Specification

H OTSTICKS
P ROJECT S PECIFICATION
System Analyst:
H ARINI P ADMANABHAN
Documentation:
R OBER T K NUUTI
Programmer:
W ILLIAM A R THUR
Project Supervisor:
W ILIAM A R THUR
ii
Signatures
By signing this document, the following personnel approve the following
content is true and that the undersigned shall take responsibility for
all required actions.
Name
Title
iii
Signature
Date
iv
SIGNATURES
Changeset
2013-10-26: Effective Print Date
vi
CHANGESET
Preface
This Software Requirement Speifications document is purposed to delineate the Hot Sticks Microsoft XBox Live video game. The acquirer
shall be defined as the Microsoft Game Studios Entity defined in the
SPMP document. This organization shall be represented by the University of Michigan Flint Computer Science, Engineering Science, and
Physics Department in general, and Dr. Michael Farmer in specific.
The document contains all information on the specifications to be
followed during Hot Sticks development. This includes definitions for
work products, and Intelectual Proprty for deliverables. This document
shall serve as the project blueprint as well as catalog inherent changes
to the proposed system. The result, and purpose, of this document
shall be the finished Hot Sticks video game for the Microsoft XBox 360
game console.
vii
viii
PREFACE
Contents
Signatures
iii
Changeset
Preface
vii
SPMP
1 Overview
1.1 Project Summary . . . . . . . . . . . . .
1.1.1 Purpose, Scope, and Objectives
1.1.2 Assumptions and Constraints .
1.1.3 Project Deliverables . . . . . . .
1.1.4 Schedule and Budget Summary
1.2 Evolution of the Plan . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
4
4
5
5
2 References
3 Definitions
3.1 Synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Project Terms . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
9
4 Project Organization
4.1 External Interfaces . . . . . . . .
4.2 Internal Structure . . . . . . . . .
4.2.1 Documentation . . . . . . .
4.2.2 Communication . . . . . .
4.2.3 Capstone Progress Report .
4.2.4 Authorities . . . . . . . . .
4.3 Roles and Responsibilities . . . .
4.3.1 Documentation Authority .
4.3.2 Analysis Authority . . . . .
4.3.3 Programming Authority . .
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
11
11
12
12
12
12
14
14
CONTENTS
5 Managerial Process
5.1 Start-up Plan . . . . . . . . . . . .
5.1.1 Estimation Plan . . . . . .
5.1.2 Staffing Plan . . . . . . . .
5.1.3 Resource Acquisition Plan
5.1.4 Project Staff Training Plan
5.1.5 Work Plan . . . . . . . . . .
5.2 Control Plan . . . . . . . . . . . .
5.2.1 Requirements Control Plan
5.2.2 Schedule Control Plan . . .
5.2.3 Budget Control Plan . . . .
5.2.4 Quality Control Plan . . . .
5.2.5 Reporting Plan . . . . . . .
5.2.6 Metrics Collection Plan . .
5.3 Risk Management Plan . . . . . .
5.3.1 Risks . . . . . . . . . . . . .
5.3.2 Impact measure . . . . . .
5.4 Closeout Plan . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
15
15
16
17
23
23
23
24
24
24
25
26
26
32
34
6 Technical Process
6.1 Process Model . . . . . . . . . .
6.1.1 Develop a Model . . . . .
6.1.2 Build a Feature List . . .
6.1.3 Plan By Feature . . . . .
6.1.4 Design by Feature . . . .
6.1.5 Build by Feature . . . . .
6.2 Methods, Tools, and Techniques
6.2.1 Modeling . . . . . . . . . .
6.2.2 Documentation . . . . . .
6.2.3 Tools . . . . . . . . . . . .
6.3 Infrastructure Plans . . . . . . .
6.3.1 Client Software . . . . . .
6.3.2 Server Software . . . . . .
6.3.3 New Software Proposition
6.4 Product Acceptance Plan . . . .
6.4.1 IEEE SPMP Document . .
6.4.2 IEEE SRS . . . . . . . . .
6.4.3 IEEE SDD . . . . . . . . .
6.4.4 Hot Sticks Application . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
35
36
37
38
38
39
39
40
40
40
40
41
41
41
42
42
42
42
7 Supporting Process
7.1 Configuration Management Plan . . . .
7.1.1 Configuration Management . . .
7.1.2 Configuration Identification . . .
7.1.3 Configuration Control . . . . . .
7.1.4 Tools, Techniques, and Methods
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
44
45
46
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
CONTENTS
xi
7.2 Verification and Validation Plan .

7.3 Documentation Plan . . . . . . . .
7.4 Quality Assurance Plan . . . . . .
7.4.1 Initial phase . . . . . . . . .
7.5 Reviews and Audits . . . . . . . .
7.6 Problems Resolution Plan . . . . .
7.6.1 Human Resources . . . . .
7.6.2 Documentation . . . . . . .
7.6.3 Source Code . . . . . . . .
7.7 Subcontractor Management Plan
7.8 Process Improvement Plan . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
47
47
48
49
49
49
49
50
50
8 Additional Plans
51
8.1 Intellectual Property . . . . . . . . . . . . . . . . . . . . . . . 51
8.2 Acquisition of Staff . . . . . . . . . . . . . . . . . . . . . . . . 51
II
SRS
1 Introduction
1.1 Purpose . . . . . . . . . . .
1.2 Scope . . . . . . . . . . . .
1.3 Definitions, Acronyms, and
1.4 References . . . . . . . . .
1.5 Overview . . . . . . . . . .
53
. . . . . . . . .
. . . . . . . . .
Abbreviations
. . . . . . . . .
. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
2 Overall Description
2.1 Product Perspective . . . . . . . . . . . . . . .
2.2 Product Functions . . . . . . . . . . . . . . . .
2.2.1 Milestone 1: Base Game Development
2.2.2 Milestone 2: Multi Tier Refactor . . . .
2.2.3 Milestone 3: State Control . . . . . . .
2.2.4 Milestone 4: Manipulation . . . . . . .
2.2.5 Milestone 5: Replay . . . . . . . . . . .
2.2.6 Milestone 6: Local Multiplayer . . . . .
2.2.7 Milestone 7: Network Multiplayer . . .
2.2.8 Milestone 8: Artificial Intelligence . . .
2.2.9 Milestone 9: Third Dimension . . . . .
2.3 User Characteristics . . . . . . . . . . . . . . .
2.4 Constraints . . . . . . . . . . . . . . . . . . . .
2.5 Assumptions and Dependencies . . . . . . . .
2.6 Apportioning of Requirements . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
55
55
56
56
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
59
59
61
61
62
62
62
63
63
63
63
63
64
64
xii
3 Specific Requirements
3.1 External Interfaces . . . . . . . . . . . . .
3.2 User interfaces . . . . . . . . . . . . . . . .
3.3 Hardware interfaces . . . . . . . . . . . . .
3.4 Software interfaces . . . . . . . . . . . . .
3.5 Communications interfaces . . . . . . . .
3.6 Classes . . . . . . . . . . . . . . . . . . . .
3.6.1 Artist . . . . . . . . . . . . . . . . . .
3.6.2 Ball . . . . . . . . . . . . . . . . . . .
3.6.3 Ball Manager . . . . . . . . . . . . .
3.6.4 Game . . . . . . . . . . . . . . . . .
3.6.5 Game Content . . . . . . . . . . . .
3.6.6 Game Object . . . . . . . . . . . . .
3.6.7 Game Settings Manager . . . . . . .
3.6.8 Game State Manager . . . . . . . .
3.6.9 Input . . . . . . . . . . . . . . . . . .
3.6.10Load Save Manager . . . . . . . . .
3.6.11Menu Content . . . . . . . . . . . .
3.6.12Menu Manager . . . . . . . . . . . .
3.6.13Object Manager . . . . . . . . . . . .
3.6.14Pause Manager . . . . . . . . . . . .
3.6.15Persistent Data Manager . . . . . .
3.6.16Pocket . . . . . . . . . . . . . . . . .
3.6.17Physics . . . . . . . . . . . . . . . .
3.6.18Stick Manager . . . . . . . . . . . .
3.6.19Table . . . . . . . . . . . . . . . . . .
3.6.20Title Manager . . . . . . . . . . . . .
3.6.21Warp . . . . . . . . . . . . . . . . . .
3.6.22Warp Manager . . . . . . . . . . . .
3.7 Sequence Charts . . . . . . . . . . . . . . .
3.8 Performance requirements . . . . . . . . .
3.9 Design constraints . . . . . . . . . . . . . .
3.10 Software system attributes . . . . . . . . .
3.10.1Reliability . . . . . . . . . . . . . . .
3.10.2Availability . . . . . . . . . . . . . .
3.10.3Security . . . . . . . . . . . . . . . .
3.10.4Maintainability . . . . . . . . . . . .
3.10.5Portability . . . . . . . . . . . . . . .
3.11 Other Requirements . . . . . . . . . . . . .
3.11.1Controller Support . . . . . . . . . .
3.11.2Keyboard Support . . . . . . . . . .
3.11.3Language and Localization Support
CONTENTS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
65
65
65
69
69
69
69
71
72
73
75
76
77
78
79
81
82
83
84
85
86
87
88
89
89
90
91
91
92
93
93
93
93
94
94
94
94
94
94
95
95
CONTENTS
xiii
III
97
SDD
1 Introduction
1.1 Purpose . . . . .
1.2 Scope . . . . . .
1.3 Definitions . . .
1.3.1 Synonyms
1.3.2 Terms . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 References
.
.
.
.
.
99
99
99
99
99
99
101
3 Decomposition Description
3.1 Class Decomposition . . . . . . . .
3.1.1 Artist . . . . . . . . . . . . . .
3.1.2 Ball Manager . . . . . . . . .
3.1.3 Ball . . . . . . . . . . . . . . .
3.1.4 Game Content . . . . . . . .
3.1.5 Game Object . . . . . . . . .
3.1.6 Game Settings Manager . . .
3.1.7 Game State Manager . . . .
3.1.8 Game . . . . . . . . . . . . .
3.1.9 Input . . . . . . . . . . . . . .
3.1.10Load Save Manager . . . . .
3.1.11Menu Content . . . . . . . .
3.1.12Menu Manager . . . . . . . .
3.1.13Object Manager . . . . . . . .
3.1.14Pause Manager . . . . . . . .
3.1.15Persistent Data Manager . .
3.1.16Physics . . . . . . . . . . . .
3.1.17Pocket . . . . . . . . . . . . .
3.1.18Stick Manager . . . . . . . .
3.1.19Table . . . . . . . . . . . . . .
3.1.20Title Manager . . . . . . . . .
3.1.21Warp Manager . . . . . . . .
3.1.22Warp . . . . . . . . . . . . . .
3.2 Concurrent Process Decomposition
3.3 Data Decomposition . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
103
. 103
. 103
. 104
. 105
. 105
. 106
. 107
. 107
. 108
. 109
. 111
. 111
. 112
. 112
. 113
. 114
. 115
. 115
. 116
. 116
. 117
. 117
. 117
. 118
. 118
4 Dependency Description
4.1 Intermodule Dependencies
4.1.1 Sequence Charts . .
4.1.2 Modules . . . . . . .
4.2 Interprocess Dependencies
4.3 Data Dependencies . . . .
4.3.1 Data Flow Diagram
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
119
. 119
. 119
. 124
. 125
. 125
. 125
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xiv
5 Interface Description
5.1 Module Interface . . . .
5.1.1 Associations . . .
5.1.2 Game . . . . . .
5.1.3 Dependencies . .
5.1.4 Aggregation . . .
5.2 Process Interface . . . .
5.2.1 User Interaction
5.2.2 Live Update . . .
5.2.3 Game Play . . . .
CONTENTS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Detailed Design
6.1 Module Detailed Design . . . . . . .
6.1.1 Game Management Module .
6.1.2 Game Input-Output Module
6.1.3 Game Objects Module . . . .
6.2 Detailed Class Design . . . . . . . .
6.2.1 Artist . . . . . . . . . . . . . .
6.2.2 Draw Balls . . . . . . . . . .
6.2.3 Ball . . . . . . . . . . . . . . .
6.2.4 BallManager . . . . . . . . .
6.2.5 GameContent . . . . . . . . .
6.2.6 GameObject . . . . . . . . . .
6.2.7 GameStateManager . . . . .
6.2.8 Game . . . . . . . . . . . . .
6.2.9 Input . . . . . . . . . . . . . .
6.2.10LoadSaveManager . . . . . .
6.2.11MenuContent . . . . . . . . .
6.2.12SetLoadSaveManager . . . .
6.2.13MenuManager . . . . . . . .
6.2.14ObjectManager . . . . . . . .
6.2.15PauseManager . . . . . . . .
6.2.16PersistentDataManager . . .
6.2.17Physics . . . . . . . . . . . .
6.2.18Pocket . . . . . . . . . . . . .
6.2.19StickManager . . . . . . . . .
6.2.20Table . . . . . . . . . . . . . .
6.2.21TitleManager . . . . . . . . .
6.2.22WarpManager . . . . . . . . .
6.2.23Warp . . . . . . . . . . . . . .
6.3 Data Detailed Design . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
131
. 131
. 131
. 132
. 132
. 132
. 132
. 132
. 133
. 133
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
135
. 135
. 135
. 138
. 138
. 139
. 139
. 140
. 145
. 145
. 149
. 150
. 150
. 152
. 155
. 156
. 157
. 157
. 158
. 158
. 161
. 161
. 163
. 166
. 166
. 167
. 167
. 167
. 170
. 170
CONTENTS
Annex
A.1
A.2
A.3
A.4
A.5
A.6
xv
A: Game Screenshots
Title Screen . . . . . .
Game Screen . . . . .
Mid Shot . . . . . . .
Settings Menu . . . .
Pause Screen . . . . .
Save Menu . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Annex B: API Documentation
171
. 171
. 172
. 173
. 173
. 174
. 174
175
Documentation Conventions
C.7 Dates . . . . . . . . . . . . .
C.7.1 In Prose . . . . . . . .
C.7.2 In Figures and Tables
C.8 Pseudocode . . . . . . . . . .
C.8.1 Naming Conventions .
C.8.2 Reserved Words . . . .
C.8.3 Included Libraries . .
C.8.4 Construction . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
177
. 177
. 177
. 177
. 178
. 178
. 179
. 180
. 181
COCOMO Estimation
D.9 Tasks . . . . . .
D.10Module Decision
D.11Point Calculation
D.11.1Reasoning
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
185
. 185
. 185
. 186
. 186
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Annex E: Weekly Progress Reports
191
Annex F: Bug Reports
193
xvi
CONTENTS
List of Figures
4.1 Hot Sticks Organization Chart . . . . . . . . . . . . . . . . . 13
5.1 Preliminary Development GANTT of Hot Sticks Project . . . 20
5.2 Predevelopment GANTT of Hot Sticks Project . . . . . . . . 20
5.3 Development Cycle GANTT of Hot Sticks Project . . . . . . 21
3.1
3.2
3.3
3.4
Hot Sticks Context Diagram . . . . . . . .

Primary Menu and Table Design . . . . . .
Primary Game Elements and Title Screen
Hot Sticks Top Level Class Diagram . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
66
67
68
70
4.1 Warp Object Collision Sequence Diagram .

4.2 Warp Warp Collision Sequence Diagram . .
4.3 Cue Stick Update Sequence Diagram . . . .
4.4 Detecting Warp Collision Sequence Diagram
4.5 Game Save Sequence Diagram . . . . . . . .
4.6 Game Load Sequence Diagram . . . . . . . .
4.7 Game Load Sequence Diagram . . . . . . . .
4.8 Warp Table Collision Sequence Diagram . .
4.9 Top Level DFD . . . . . . . . . . . . . . . . .
4.10 Ball Management DFD . . . . . . . . . . . .
4.11 Ball Pocket Collision DFD . . . . . . . . . . .
4.12 Ball Warp Collision DFD . . . . . . . . . . .
4.13 Ball Table Collision DFD . . . . . . . . . . .
4.14 Ball Ball Collision DFD . . . . . . . . . . . .
4.15 Menu Management DFD . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
120
120
121
122
122
123
123
124
125
126
127
127
128
128
129
6.1 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . 136

6.2 Module Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 137
D.3 Coefficient Overview . . . . . . . . . . . . . . . . . . . . . . . 186
D.4 PMAT calculations . . . . . . . . . . . . . . . . . . . . . . . . 188
D.5 First COCOMO calculation . . . . . . . . . . . . . . . . . . . 190
xvii
xviii
LIST OF FIGURES
List of Tables
5.1 FDD Process Training Outline . . . . . . . . . . . . . . . . . 17
5.2 C# Training Outline . . . . . . . . . . . . . . . . . . . . . . . 17
5.3 Risk Management Weighting . . . . . . . . . . . . . . . . . . 32
C.1 Global Project Abbreviations Table . . . . . . . . . . . . . . 178
C.2 Example of Casing in Pseudocode . . . . . . . . . . . . . . . 178
xix
xx
LIST OF TABLES
Part I
SPMP
Chapter 1
Overview
1.1
1.1.1
Project Summary
Purpose, Scope, and Objectives
State of the Gaming Industry

Advances in computing have brought all facets of modern life into the
information age. This has helped transform entertainment into a major business entity. The video game industry is one of the largest divisions of the entertainment industry today. Sales and distribution vary
from traditional brick-and-mortar to digital medium. The Platforms
encompass computers, consoles, and a myriad of portable devices. To
date, Microsofts XBox 360 gaming console has sold well over 30 million units. Adding to that a Microsoft Windows worldwide install base
of over a billion, one can see the potential of video games.
Conception of Hot Sticks
The video game industry is a booming business. Competition is fierce;
to achieve success a game must stand out from the crowd. To date,
all pool table video games are mere imitations of the original. There
are none which dare to take the classic game of billiards into another
dimension. This is where the problem lies. Our solution to this problem
is Hot Sticks.
The business world revolves around supply and demand. D3 is here
to heed the call of demand. At the request of Microsoft Game Studios,
the industry heavyweight in downloadable console gaming; we at D3
have developed a solution. This solution is a quality game, both in
concept and execution. Hot Sticks brings the traditional game of billiards into the third dimension. Mechanics will emulate real-life pool
play, satisfying even the most avid billiard enthusiast. Hot Sticks game
3
CHAPTER 1. OVERVIEW
play will deliver a unique twist not possible in the real world; playing
multiple tables in one single game. With multiple tiers of a table, balls
may traverse up or down levels. Warp zones on every level transport
moving balls to the levels above or below. Hot Sticks takes strategy to
a whole new level! Game settings are user-customizable. Alter friction,
add levels or change all warp destinations to random locations: Defy
the laws of physics themselves. No two games will ever be the same.
And what would a game of pool be without friends? Play locally with
family or with friends online using Microsofts live system.
Target Audience
Hot Sticks is destined both for PC Games for Windows and XBox Live on
the XBox 360 gaming console. With a solid foundation in the physics
of pool playing, Hot Sticks will definitely appeal to the billiard enthusiast. And with a new twist on the game of pool and intuitive control
design, this game will also capture the imaginations of casual gamers
of any age. Add in customizable gaming rules and online multiplayer
through XBox Live or Windows Live and Hot Sticks becomes the multidimensional billiards game for anyone interested in fun.
1.1.2
Assumptions and Constraints
Hot Sticks will be developed under heavy constraints. The documentation and development cycle shall be done concurrently, and a product that fulfills the contract specification needs to be delivered by first
quarter of 2010.
The resources provided is also limited. Budgeting and Personnel is
limited to what our sponsor, the University of Michigan-Flints CSESP
department, can afford. Professional reviews are schedulable for guidance when a need arises.
1.1.3
Project Deliverables
The Deliverables of this project encompass:

IEEE SPMP Document
IEEE SRS Document
IEEE SDD Document
Hot Sticks Application
In addition, there shall be weekly presentations of software iterations
throughout the development cycle starting January 4, 2010, to the final
delivery date.
1.2. EVOLUTION OF THE PLAN
1.1.4
Schedule and Budget Summary
The schedule for the team members have been allotted after through
discussions on factors that influence the plan such as individual team
member class timings, work timings, process model specification, distribution of work, individual speed, and technical know-how to name
a few. Fall back plans have been included taking into account human
factors such as lack of productivity, ideas, removal of old methods for a
new start, and also personal situations that could crop up. The technical factors that influence the schedule have also been considered, and
the coders have been pre-planned a training schedule that has them familiarizing with the software languages. The schedule has been made
as accurate as possible including fall back options to continue the work
flow patterns needed by the process model.
The team has proposed and analyzed various strategies to keep the
project cost effective as possible. All project specification requirements
shall be analyzed and a budget estimate calculated. The required budget has the probability of being extended further as the team plans to
include improvement methods in testing of the code that absolutely demands the need to scale the upper limit of the budget. The issue will
be discussed with the course instructor Dr. Farmer and the Computer
Science Department of the University of Michigan Flint, for the sanctioning of the required expenditure. Proof will be produced that the
methodology adopted is essential for the gaming environment and the
amount calculated is the most feasible for the given scope of the software. The total budget allocation of this project shall be managed by
the University of Michigan Flint.
1.2
Evolution of the Plan
Evolution will occur in real time utilizing the power of a wiki system.
The plan shall be reviewed once each week to ensure that the quality
of the project remains consistent. Updates to the wiki are generated
on edit, and a change log is available globally over the entire wiki, or
locally on a per-document basis. Notifications are similarly produced in
real time, publishing them to the Atom 1.0 website syndication format,
where participants in the project can immediately see changes made.
CHAPTER 1. OVERVIEW
Chapter 2
References
Documents used for the established of this whitepaper can be found as
below.
P ALMER , S. R., F ELSING , J. M. A Practical Guide to Feature-Driven
Development. Prentice Hall PTR. 2002.
P RESSMAN , R. Software Engineering: A Practioners Approach. McGrawHill Science/Engineering/Math. 6th ed.
IEEE C OMPUTER S OCIETY. IEEE Standard for Software Project Management Plans. (1058-1998). 8 Dec 1998.
CHAPTER 2. REFERENCES
Chapter 3
Definitions
3.1
Synonyms
This document uses the term XBox and XBox 360 interchangeably.
Note that in both cases, this should be read as XBox 360. When discussing matters that are different between the XBox and PC software,
the two are refereed to as the XBox System or the PC System.
Also, when mentioning the PC operating system Windows, this should
be read as Microsoft Windows XP or Higher.
3.2
Project Terms
Warp A type of positional transport which has a clear entry and exit
point.
Wormhold A type of positional transport which has a clear entry but a
fuzzy exit point.
10
CHAPTER 3. DEFINITIONS
Chapter 4
Project Organization
4.1
External Interfaces
This sub clause of the SPMP shall describe the organizational boundaries between the project and external entities such as user interface,
hardware interfaces, software interfaces, organizational charts and diagrams can also be used to depict the projects external interfaces.
In our software projects all these entities can be found in Figure 4.1,
where the organizational chart defines a layers of authority.
4.2
4.2.1
Internal Structure
Documentation
The project documentation will be created and distributed by an online

wiki system. This is necessary due to the fact that the development
team will not be co located in one work environment. All project documentation shall be stored and distributed exclusively through this
system.
4.2.2
Communication
Communication shall be facilitated through weekly development team

meetings. Preliminary Meetings are to be held weekly on Wednesday
evenings from 5:30 PM until 8:00 PM in the Murchie Science Building,
S Flint campus
3rd floor breezeway at the University of Michigan A
from September 1st, 2010 until December 9th, 2010.
Development meetings shall be held weekly on Saturdays at 9:00
AM in the ITS Computer Lab located in the same building until April
20th, 2010. After this date, all communication shall occur through
11
12
CHAPTER 4. PROJECT ORGANIZATION
email, corresponding to the Hot Sticks organization chart.

Other formal communication shall be performed through email pro S Flint.
vided by the University of Michigan A
4.2.3
Capstone Progress Report
A weekly report shall be filled out which will serve as an itemized list of
names to activities performed throughout the week. This memo shall
review the topics intended to be covered during the meeting and what
tasks will need to be performed for the next iteration. The progress
report shall be written by the Documentation Authority, distributed
to development members via the wiki, and presented to the Customer
Representative on every workweek Tuesday.
4.2.4
Authorities
The software development team shall consist of three members, each

holding a position which defines who is the ultimate authority in the
related subject matter. These units are,
Documentation
Analysis
Programming
This format forms a circle of responsibilities that can be seen in the
attached Organization Chart. This can be seen in Figure 4.1.
4.3
Roles and Responsibilities
Specialist positions are not observed in D3 . Instead, authorities are

placed for responsible parties and all project members shall participate
in all stages of Hot Sticks development. The project shall not have a
project leader, but instead act as a single entity with three different
perspective supervisors.
4.3.1
Documentation Authority
Robert Knuuti All matters pertaining to documentation formatting,

production, aggregation, distribution, and conventions shall be supervised by this authority. The Documentation authority shall actively
review software analysis artifacts and produce whitepapers for the Programming authority to review.
Additional tasks placed unto the Documentation Authority are configuration management and technological adviser for developmental
tools.
4.3. ROLES AND RESPONSIBILITIES
13
William Arthur
Programming Authority
Pr
og
r
Ma amm
tte in
rs g
sis
aly s
A n tte r
Ma
Do
cu
m
Ma e nt
tte atio
rs
n
ing
mm
ra rs
o g te
Pr Mat
Analysis
Matters
Harini Padmanabhan
Analysis Authority
Robert Knuuti
Documentation Authority
Documentation
Matters
Figure 4.1: Hot Sticks Organization Chart
14
4.3.2
CHAPTER 4. PROJECT ORGANIZATION
Analysis Authority
Harini Padmanabhan All matters pertaining to the analysis, high

level development, cohesion and coupling, and relations between elements shall be supervised by this authority. The Analysis authority
shall validate produced artifacts and check the feasibility of the said
artifacts.
4.3.3
Programming Authority
William Arthur All matters pertaining to the coding conventions, algorithms, binaries, and unit testing shall be supervised by this authority. The Programming authority shall ensure that produced content
adheres to the specification document and shall address accidental engineering defects to other members for potential revision.
Chapter 5
Managerial Process
5.1
5.1.1
Start-up Plan
Estimation Plan
In this plan, D3 shall use COCOMO II 2000 professional estimation

software to calculate the estimated cost of the Hot Sticks project and
provide an estimate to the required time to produce Hot Sticks.
5.1.2
Staffing Plan
The overall project plan will require a full-time staff of three persons.
Each of these three persons shall assume authority over a specific area
of application development. The roles and responsibilities of the three
full-time staff personnel will fluctuate during the development process.
As only three personnel will be recruited for the development project,
necessity states that each will be of the highest skill level for their individual role of authority. These personnel will be necessary for the
entire duration of the project. Personnel are to be obtained from remaining members of the previous development team, formerly known
as B*Harp. The following paragraphs denote how specific positions will
be filled by available personnel. All staffing breakdowns are assume to
be experts in the listed responsibility unless noted otherwise.
There is to be one Documentation Authority, one Programming Authority and one Analysis Authority.
5.1.3
Resource Acquisition Plan
Many resources must be acquired to facilitate project completion. These

are listed below in order of necessary acquisition.
15
16
CHAPTER 5. MANAGERIAL PROCESS
Infrastructure
A wiki document system is to be implemented for all project documentation. This resource is to be acquired by the Documentation authority. Administration and maintenance of aforementioned resource will
be the responsibility of the Documentation authority as well.
Training
Software and training resource acquisition for each project member
shall be the responsibility of each member. Microsoft MSDN memberships are to be obtained by Programming authority. Members are
individually responsible for obtaining memberships. These will be obtained through University of Michigan Flint CSESP department resources. Information on said resources can be obtained from Systems
Administrator Senior David Rosemary of the CSESP department.
Software
Additional software resources to obtain are Microsoft Visual Studio

2008 Professional and Microsoft XNA Game Studio 3.1 software. These
are to be obtained through Microsoft DreamSpark student resources
or though the MSDNAA program provided by the CSESP department.
The above resources are of no monetary cost and are to be obtained no
later than January 26, 2009.
XNA Creators Club professional membership must also be obtained.
This will be necessary to support game transfer to the XBox 360 gaming system. This is to be obtained by Systems Administrator Senior
David Rosemary of the CSESP department. Resource monetary cost is
governed by the University of Michigan Flints CSESP department. All
requests must be submitted by January 26, 2009.
5.1.4
Project Staff Training Plan
FDD Process Training

All team personnel will undergo Feature Driven Development training.
This is to be a self-study training exercise. FDD training coordinator
is to be Documentation authority. All members will receive training
materials from the FDD training coordinator and execute a one-week
self-training session, specified in Table 5.1.
Development Language Training
Development language training will be done to facilitate the Build by
Feature process. The application will be developed entirely using the
C# high-level programming language. Programming authority William
5.1. START-UP PLAN

Entry Criteria
Exit Criteria
17
None
Process refinement and modification meeting held and FDD process
has been tailored to suit the application.
Information distribution
2009.10.28
Training Date
2009.11.04
Table 5.1: FDD Process Training Outline

Training Summary
Entry Criteria
MSDN registration has been completed through University of Michigan Flint CSESP department resources.
Exit Criteria
Inception of first Feature Build Process
Date of Training
2009.11.18
Table 5.2: C# Training Outline
Arthur, as well as all team members will take part in C# training. All
development team members will take part in self-study. This will be
facilitated by Microsoft MSDN C# Development Training Center. Training will be conducted online through examples and training videos and
exercises. An outline of this is illustrated in Table 5.2.
Microsoft XNA Game Studio 3.1 training is to be completed by all
development team members. Training is to be completed by self-study.
Self-study will be facilitated by online resources and printed materials.
5.1.5
Work Plan
Work Activities
The work activities shall be defined for each project deliverable as defined in Section 1.1.3.
IEEE SPMP Document This deliverable shall be comprised by the
following list of work activities:
Project Initiation This work activity will include all project inception
activities. Project scope shall be determined as well as determination of all stakeholders.
18
Requirements Gathering Customer requirements shall be gathered

during this work activity. Communication methods will be established between project stakeholders.
Estimation This work activity shall encompass all activities necessary
to facilitate a reasonable accurate initial estimate of project cost
and duration.
Scheduling Contained in this work activity are all supporting efforts
to determine a schedule for project implementation. This work
activity will be refined for granularity as necessary for the duration
of the project.
Modeling Analysis The problem shall be modeled during this activity.
This will include all domain modeling activity defined in Section 6.
Delivery This work activity shall encompass all work necessary to deliver the SPMP a whitepaper to all stakeholders defined in the
project initiation work activity.
IEEE SRS Document This deliverable shall be comprised of the following work activities:
System Modeling Analysis This work activity shall encompass all activities necessary to execute modeling of the problem to be solved.
These activities shall be defined in Section 6.
System Modeling Design Activities which constitute this work activity
are those used in modeling the system to be fabricated. These
activities shall be defined in Section 6.
Delivery This work activity shall encompass all work necessary to deliver the SRS a whitepaper to all stakeholders defined in the project
initiation work activity.
IEEE SDD Document This deliverable shall be comprised of the following work activities:
Planning Mapping out of tasks and general flow of individual requirements and distributing tasks.
Design Entities Identification of data types and/or enumerations.
Object Relationship Identification of object relationships and cardinality.
Views Choosing appropriate design views to effectively convey information.
5.1. START-UP PLAN
19
Descriptions Detailed itemization describing functionality and usability.

Delivery This work activity shall encompass all work necessary to deliver the SDD a whitepaper to all stakeholders defined in the project
initiation work activity.
Hot Sticks Application This delivery shall be comprised of an iteration of activities. Each iteration shall have:
Object Modeling Analysis This work activity shall encompass all tasks
necessary to model the problem to be solved for all iterations of the
software application. Problem modeling activities shall be defined
in Section 6.
Object Modeling Design All activities relevant to the modeling of software product modules shall occur during this work activity. This
activity shall be repeated iteratively for all modules to be included
in finished product. Product modeling activities shall be defined
in Section 6.
Object Coding This work activity shall encompass all work necessary
to transfer design documentation to code language specified by
product.
Function Testing Definition of this work activity is any effort necessary to test products of the aforementioned work activity Function
Coding.
Integration This work activity shall encompass all necessary effort to
integrate modules constructed into the overall application.
On the final deliverable, will have an additional two work activities,
Application Testing This work activity shall be identified as any work

which must be done to test the application as a whole. This
work activity is to be completed once all iterative functions have
achieved integration.
Application Delivery This work activity shall encompass all work necessary to deliver the finished application to all stakeholders defined in the project initiation work activity.
Schedule Allocation
The schedule allocation for predevelopment is illustrated in Figure 5.1.
This pertains to the SPMP development, construction, and personal
training.
Schedule allocation for predevelopment setup is illustrated in Fig-
20
Figure 5.1: Preliminary Development GANTT of Hot Sticks Project
Figure 5.2: Predevelopment GANTT of Hot Sticks Project
ure 5.2. This focuses on refactoring of tasks from project members

after weighing in the difficulties experienced in training, infrastructure
setup, and preliminary document construction.
Schedule allocation for development cycles is illustrated in Figure 5.3.
This outlines the project timeline for completing individual phases of
development.
Resource Allocation
This section describes the resources for work activities of the project
such as computing resources, software skills, testing the software product and simulation facilities, and administrative support. For instance,
in computing resources our software team is going to need two XBox
360 console to test the each project deliverables to our customer representative, in software skills the development team was assigned learning C# as a self training and apply this knowledge for the development of this software product which is the major factor of this software
project, and in administrative support category, the Documentation
Authority was assigned to document each delivery of the project.
Project Initiation This work activity provides information regarding
to initiate the project by planning or define the scope, purpose and of
5.1. START-UP PLAN
Figure 5.3: Development Cycle GANTT of Hot Sticks Project
21
22
the project in the software development life cycle. In our project initiation, we define the scope of the our project by stating that the video
gaming industry is booming in todays age so we decided to develop a
pool game for the XBox 360 console for our users. Defining our users
in a generic way, our users are who play as single player or multiplayer
not preferably categorize for a specific age, as to target Hot Stickss
rating to the ESRB E rating or equivalent.
Requirements Gathering User requirements describe the demand
from that software product to be delivered to our user. In this case
requirements gathering from our users would be challenging due to
the fact our users dont know what they want based on their assumptions and requirement. Users would be ourselves such as software
team members and the customer representative.
Estimation In this work activity, D3 makes sure that the delivery of
each of the working product to be delivered in a time frame that was
scheduled. Based on user requirements our team can calculate the
estimation of the delivery of the whole project and cost of the project.
Scheduling In scheduling work activity, the documentation of our
project provides the information duration of each process in the software development project. Also it assigns each individual to do a certain tasks for documentation for IEEE 1058-1998 standard. For example, schedule for software development weekly meeting, schedule for
individuals to research on the material for training such as learning
new language C# and schedule for meeting with customer representative. Delay of scheduling can cause duration for each work activity goes
longer to be done.
Modeling Analysis In modeling analysis work activity, our software
development team built the class base diagram, use cases for each
object in the project. Basically it describes the overall system and correlation between objects and users through our use cases and Class
Responsibility Collaboration (CRC) cards to get the job done.
SPMP Delivery Software Project Management Plan Delivery is the
print out copy of a final documentation of the software project to be
delivered to the customer. This involves the description work activities,
elements of the project, project estimation of how long its going to take
to complete the working product estimation time of each individuals
effort to finish their tasks.
5.2. CONTROL PLAN
23
Budget Allocation
Allocation of monetary resources shall be handled independent of this
whitepaper. Initial budget, as defined in Section 1.1.4 is the only allocation in which the Hot Sticks project is permitted to have.
5.2
5.2.1
Control Plan
Requirements Control Plan
Changes shall be permitted, and encouraged throughout the development of the project. Those wishing to submit changes are required to
present their changes to leaders of the project during the weekly project
meeting, or by submitting a plan through email. The change plan shall
cover both the gains and losses for implementing the change, as well
as a time estimate for completion.
The change will then be put under analysis before it is put into the
projects development cycle. Each authority will review the changes
and verify the information provided by the developer. If the change
has the approval of two of the three authorities, the change shall be
implemented in the next iteration. A message will be sent out to the
software architects to revise the specification and then delegating tasks
in re factor the document and then distributing the changes to the rest
of the development team.
5.2.2
Schedule Control Plan
Documentation Reporting
Documentation will be performed actively throughout the project and
will be dynamically updated, and reported in accordance to the project
evolution plan. Weekly updates shall be distributed to development
team members. These updates shall occur by way of the Capstone
Progress Report document template provided by the User Representative Entity. This shall be updated weekly and is to be transmitted
to all stakeholders including customer representative. Transmission
shall occur every Tuesday beginning January 19, 2010 and continue
through April 19, 2010 with the exclusion of March 2, 2010. This
weekly document shall record tasks completed, tasks to be worked on
as well as unanticipated tasks for each individual development team
member. Project performance as well as individual work performance
shall be documented in this manner.
24
Staffing Report
Team members are required accomplish assigned tasks itemized in the
weekly report. There are no time constraints for completion of tasks,
but frequent oral communication is required of the team member to
itemize sub tasks involved in the completion of the task.
5.2.3
Budget Control Plan
The budget control for the product involves communication with the
Customer Representative, which will submit a file to the University of
Michigan Flints CSESP department, which will be passed before their
administration board for approval. Team members will plan business
strategies to keep the expenditure within limits. If need arises for additional expenditure it is required to file for the amount to the Customer
Representative, stating the cause for the increase in expense. All purchasing plans shall be reviewed by D3 such that no excess product is
presented for order. This shall minimize the rejection rate of required
elements, and improve the team image.
5.2.4
Quality Control Plan
Customer needs and ease of use is the main target, features needed for
the software are developed with this in mind. During the development
phase of a feature, the team analysts will work along with the coders
to suggest strategies. Review meetings shall be held where each feature will be discussed and analyzed to ensure quality outcome of the
product. Features will be tested and modified to include any change
for further improvement. Peer reviews are held to get a different perspective, it helps improve the overall approach.
Source code quality control shall be obtained through the select process itemized in Section 6.1.
5.2.5
Reporting Plan
Documentation will be performed actively throughout the project. Individual tasks are to be reported to the Documentation Authority to be
complied into the Weekly Capstone Progress Reports.
Capstone Progress Report
Weekly updates through the Capstone Progress Report shall update
members on the progress of each element. Tasks to be worked on,
actual work completed, unanticipated tasks and future tasks shall be
defined within this document. Work responsibilities and actual work
performed shall be explicitly stated within this document. The current
state of the project shall also be defined within this document. This
5.2. CONTROL PLAN
25
document shall be transmitted to all stakeholders weekly at the project

review meetings each Tuesday throughout the development life cycle.
5.2.6
Metrics Collection Plan
The metrics will be reported on a weekly basis and will measure the
completeness of a section of the project. To be complete, the entire
section must be in working order before the section passes the metric collection. When goals are not reached the team shall adjust the
schedule and adjust the plan. Metrics weekly reporting shall occur in
the Capstone Progress report document after the first iteration.
Requirements Gathering Metrics
Requirement gathering metrics shall be performed. This will be accomplished by tracking the number of classes in the application to
the number of individual requirements. This number shall be plotted
against the previous occurrence to show project requirement complexity.
Analysis Metrics
Analysis metrics will be comprised of the number of classes as well as
the number of methods. Average methods per class will be used to
track project complexity.
Design Metrics
Design metrics will include the tracking of the number of classes, methods and average methods per class. In addition, the popular Cyclonic
Complexity collection metric shall be calculated per method.
Coding Metrics
Coding metrics shall be collected, and will be comprised of the number
of classes, methods and average number of methods per class.
Testing Metrics
Testing metrics shall be utilized through the tracking of the number
of classes, the number of methods as well as the average number of
methods per class. In addition, the number of defects injected per
class shall be tracked.
26
5.3
Risk Management Plan
The critical risk items outline in the COCOMO risks enumerated over
several fields of the development, including the lack of education in
game design, graphics, tools, training, language, model, embedded systems, cross platform development, and unfamiliarity with physic manipulations.
Based off of these elements, the following risks outlined are
Project
Technology
Staff
Consumer
Business
Schedule
Cost
5.3.1
Risks
Inadequate Staffing
Working as a three member team on a completely new code developing environment may end up resulting in inefficient work flow. There
maybe necessary more than the assigned members to work on a particular issue and hence this will lead to either decrease of functionality,
or one of the members working to match their schedule and the newly
added task, contributing to inefficient management skills. This delays
the development cycle even more because now we have to resolve issues
while accelerating development.
RMMM The staffing is fixed, unless additions can be made, the only
solution to the problem of having more work flow is to schedule the
work load better to fit the time needed to compensate for the extra
work using the timeboxing strategy specified in Section 6.
Insufficient Language/Coding skills
The language being used is XNA and C#, which is a first time experience
for the coders, thus there is a problem of unknown language initially
and the problem of little known language.
RMMM Constant training, regular practice, thorough research is required to gain familiarity and understanding.
5.3. RISK MANAGEMENT PLAN
27
Graphic Glitch during Development

The entire product relies on the graphic skills to implement all the
features and methods. Coders are working on the XBox 360 and the
languages to implement them for the first time, hence the problem of
lack of skill surfaces.
RMMM Practice graphic induced coding, research available libraries,
see examples.
Coding Errors
Due to limited language skills, the error in the code may not be found
out, it takes a through knowledge of functions and the proper way to
implement them to fully avoid this situation.
RMMM Adding comments to the code helps to resolve the problem
more quickly, it takes a through knowledge of functions and the proper
way to implement them to fully avoid this situation, thus practice and
learn the language as much as possible.
Irregular Workflow Pattern
Due to the schedule pattern involving attending university and taking
up classes, the scheduled in finishing the required feature may extend
and also the weekly meeting to review and reflect on progress may also
delay.
RMMM Plan ahead, always keep room for handling changes, a back
up method has to be there at all times for working in a group to stop
delays.
Misinformed Communication
The team member may understand the requirement wrong, and start
on the coding incorrect and will have to start over, this is a waste of
man hours and delay in time.
RMMM Speak up any doubts, clarify the requirement thoroughly, pay
attention when discussion is commencing.
Abandoning Methods
Half way into the coding or development phase methods can be considered not do able and abandoned to adopt new strategy, this is a delay
in man hours and project workflow time.
28
RMMM Plan more thoroughly covering all possibilities of risks, errors

and failures. Make a back up plan to fall back on.
Inaccurate Problem Solving Strategy
The game is heavily dependent on the physics engine, which requires
the approach of solving real time gaming situations for accurate play.
Incorrect approach to implement the laws of physics results in an error
prone game.
RMMM Read and understand the laws of physics, practice solving
similar problems, consult the university physics staff for guidance.
Overriding Functions
The cohesion and coupling of the entire modules decides the functionality of the game, which will go adverse if there are over-riding functions
that give faulty calculations to the game inputs.
RMMM Understand the coding requirements and strategy from the
start, mark down the properties of functions, review and test the code
after each significant addition of data.
Training Delay
The time allotted to learn the software techniques before implementing them maybe delayed due to team members incorrect planning or
sudden personal intrusions.
RMMM Use Capstone Progress Report to predict schedule planning
and a lot times, compare results after a week and improvise scheduling
to better suite the user need and project need.
Data Loss
System saves on files, file location, code updating, document updating
can be lost if not done thoroughly. Carelessness could surface due to
either interruptions or distractions leading to these data loss. This is a
loss of man hours and time.
RMMM Update frequently, the changes, be sure to check if file is
saved, handle all the files carefully and store it where it is easy to
remember, have name tags.
29
Mishandling the Output Devices

The XBox, and controller, if tampered, may get damaged thereby stopping the project work flow since the entire testing process depends on
the output devices.
RMMM
Handle the devices with care.
Schedule Delays
Personal issues, sudden challenges, poor management technique could
result in the delay of the project timeline. This affects the entire process, including the deadline to be met.
RMMM Constantly monitor capstone progress report, any delays are
detected from the deviations observed.
Lack of Cross Platform Development
Working on multiple platforms, raises unfamiliarity issues, development problems and time delays.
RMMM Thorough research of devices and system to be working on is
necessary, practice makes perfect so practice, read and understand.
Lack of Experience in Embedded Systems
Raises unfamiliarity issues, development problems and time delays.
RMMM Through research of devices and system to be working on is
necessary, practice makes perfect so practice, read and understand.
Lack of Game Development Background
Unfamiliarity with gaming concepts ensures the problems of development, design and testing of the entire software.
RMMM Browse through the millions of online database that talk of
game development, download game development codes to test and run
them, learn and develop mini games, small steps lead to big achievements.
30
Resource Limitations
The project scope requires the need of two XBox 360 for ensuring
smooth flow of the testing, design and development cycle. Other unanticipated requirements of hardware or software objects may arise. The
budget allocation puts a limits on this and hence it affects the entire
process.
RMMM Obtain necessary hardware and software resources as early
as possible. Plan budget allocation accurately, if situation unavoidable personnel expenditure are to be incurred to maintain the project
development pace.
Unfamiliar Processor Model
The FDD process is by itself not widespread compared to the other
process models that are used. Any doubts that arise in the implementation of the methods would delay schedule due to limited number of
resources available to refer (both on the Internet and textbook).
RMMM Consult the professor for guidance,state the problem and the
solution method being implemented. Several software are modeled on
combining elements from different process model, so essentially this is
acceptable so long as the software development runs smooth.
Incorrect Process Approach
The FDD process step by step approach to the development of the software could be mis-interpreted or applied wrong. This results in a faulty
approach.
RMMM Consult the professor for guidance,state the problem and the
solution method being implemented. Several softwares are modeled on
combining elements from different process model, so essentially this is
acceptable so long as the software development runs smooth.
Unfamiliar Language Library XNA The library of the development
languages is the base for coding, if libraries functions are unknown
it could result in errors, time delays to search and understand the
required functions or an unnecessary approach to solve the issue there
by making the code longer and more prone to inconsistencies.
RMMM All team members learn XNA Language Library. Constant
training, regular practice, thorough research is required to gain familiarity and understanding.
31
Poor Documentation
The entire content to be written requires the need to be accurate, a
systematic flow pattern and up to date. Human errors involving over
riding documents, errors, poor language skills and duplicate entries
upsets the accuracy and the format of submission.
RMMM Review the document before making any changes, Frequently
update, keep a track of changes included, practice forming coherent
and grammatically correct sentences.
Unstable Project Requirements
The project is a first for all the developers and the team involved, thus
changes are to be expected. This could mean the start from scratch or
to remodel certain approaches. This cause time delays and more man
hours to be invested.
RMMM Clearly define project specifications initially, brain storm possible faults and alternate approaches, choose what is best and the team
members all agree upon. Be open to suggestions.
Failure to Meet Expectations
All the users have expectations of a game to behave in a manner that
makes it easy for them to use and understand. The expected features
by all the users can not be met, the system is very limited to team
member skills.
RMMM Develop features that form the base for any game which makes
it run efficiently, other features may be included based on constraints
and necessity.
Review Follow Up Failure
Reviews are conducted to discuss and arrive to conclusions, approaches
and improvise the project. If not practiced it leads to decrease in the
quality of approach.
RMMM Make sure to follow the required schedule time allotted for
reviewing, if not make arrangements to hold another meeting or get the
information from a missed review session. Maintain a record stating
changes and comments.
32
Unfamiliarity with Development Tools

The development tools chosen are new, thus it takes research and practice to approach the right way.
RMMM Constant training, regular practice, thorough research is required to gain familiarity and understanding.
Game Removal
Microsoft removes the game due to violations of copyright or breach of
terms.
RMMM We remove the association with Microsoft and halt the XBox
version, the Desktop version does not require authorization by Microsoft adherence it will continue to be deployed.
5.3.2
Impact measure
There are three measures of impact used, ranging low, average, considerable, high, and catastrophic impacts. The weighing for these measure
are displayed in Table 5.3
The Risk Exposure shall be calculated by RE = P C, where p is the
probability of the risk and C is the cost incurred. This factor does not
apply to our system.
Table 5.3: Risk Management Weighting
Risks
Risks Category
Probability
Impact
Weight
Code errors
Technology, Project
60%
30
Schedule delays
Staffing, Schedule
60%
18
Insufficient language
coding
skills
Technology, Project
40%
16
Unfamiliar language library
Technology, Project, Schedule
40%
16
Graphic development glitch
Technology, Project
50%
15
Training Delay
Staffing, Project
50%
15
Over-riding functions
Technology, Project
30%
12
Continued on Next Page
33
continued from previous page

Risks
Risk Category
Probability
Impact
Weight
Lack of Skill in
Cross
Platform
Development
Technology, Project
30%
12
Inaccurate problem solving strategy
Project
20%
10
Review Follow-up
failure
Project
25%
10
Unfamiliarity
with
Development Tools
Technology
25%
10
Irregular workflow pattern
Staffing, Schedule
30%
Lack
of
Skill
With Embedded
System
Technology, Project
30%
Lack of Game Development Background
Technology, Project
30%
Abandoning
methods
Technology, Project
20%
Game Removal
Business
10%
Mishandling the
output devices
Project, Technology
10%
Misinformed
Communication
Technology, Project, Schedule
10%
Unstable project
requirement
Technology
25%
2.5
Data Loss
Project
5%
Expectation Failure
Customer
20%
Inadequate
Staffing
Staffing, Project, Schedule
20%
Continued on Next Page
34

continued from previous page
Risks
Risk Category
Probability
Impact
Weight
Incorrect Process
Model Approach
Project
20%
Resource limitation
Technology, Project, Cost
20%
Unfamiliar
cess Model
Pro-
Project
15%
1.5
Poor documentation
Project
5%
0.5
5.4
Closeout Plan
D3 shall maintain the general tiered staff assignments specified in Section 4.3 at the end of the Hot Sticks project lifecycle. The project archive
shall maintain itself on the wiki site, which contains a history of all
actions taken with the project, as well as hold the most up-to-date
version of whitepapers. Information about the project for review can
be obtained through contacting the Project Manager, or by contacting
Dr. Michael Farmer of the University of Michigan Flint. Documentation, reports, and other whitepapers can be obtained by contacting the
Documentation Authority. These whitepapers span analysis and the
meeting minutes that detail project actions, planning, modeling, and
summaries explaining each of these elements.
By signing their name in the Signatures section, all parties involved
with the closeout plan agree to the above terms for post development.
Chapter 6
Technical Process
6.1
Process Model
The process model that Hot Sticks will be following is FDD, or Feature
Driven Development. With feature driven development, there are five
major sections defined process in the specification to the model,
each with defined tasks. The FDD process is similar to iterative methods, but it pulls many traits from Extreme Programming and DSDM,
with many sections being able to return to others.
6.1.1
Develop a Model
In this stage, development and research on the game of pool is to be

preformed. The application will be hashed out in detail to define what
boarders will be needed in the development. This stage focuses more
on the boundaries of the application than the granularity of how the
application will be coded. There are six required and one optional steps
to be preformed in this process.
Form the Modeling Team
The project manager establishes a team using staff with permanent
positions.
Domain Walkthrough
The modeling team shall scope the development of the Hot Sticks system from what is expected of the application to necessary technologies
and other meta-development topics.
35
36
CHAPTER 6. TECHNICAL PROCESS
Study Documents
An optional step where the modeling team reviews the documents created in the previous step. This should be skipped on the first circuit of
development, but is absolutely essential when preforming review or re
factoring requirements.
Develop the Model
In small groups, the modeling team will each develop a model on the
Hot Sticks system, and offer a presentation of what their group made.
From there, the group collectively decides on one, merges, or re preforms this step.
Refine the Object Model
Does not apply in the first circuit, but in those that follow, theres a high
possibility that the Object Model will need updating for new changes.
This step takes advantages of those changes and re factors and applies
them to the Domain Model.
Define Complex Model Elements
When necessary, label the elements used in diagrams so that they can
be easily understood at a later date.
The exit condition from this process to the next is checked by a
Assessment of both internal and external elements. This is checked
by the domain experts and then reproduced for the customer to assess
that what will be preformed is satisfactory.
Upon completion, there should be:
Class Diagrams that give the model some shape
Basic methods to be used inside these classes
Sequence Diagrams to illustrate program flow
Notes that illustrate why particular items were chosen over others.
6.1.2
Build a Feature List
The shortest to define, the Feature List is built after the Model has been
defined. Using the programmers from within the model team, the team
shall identify feature sets from the domain model developed from the
Walkthrough. Each area is decomposed into activities that eventually
form steps to solve a particular problem. Each feature is worded in a
way that clients understand, using a template of action result object.
Each feature should be preserved to be completed within 2 weeks,
to ensure minimal complexity, but not as simple as to obtain or set
6.1. PROCESS MODEL
37
individual elements. In the case that a feature is longer than 2 weeks

to complete, the feature must be broken down into n sub-features until
it satisfies this condition.
Again, the exit condition is set by preforming internal and external
assessments where the feature list is verified by the domain experts
and customer.
Once this stage is completed, there should be:
List of Subjects
For each subject, a list of activities that fall under the subject
For each activity, an associative feature to satisfy the necessary
conditions.
6.1.3
Plan By Feature
Once their is a feature list, a planning team is formed from the development manager and the chief programmers to generate a basic schedule.
The schedule shall dictate when a feature will be done, scaled by week.
Determining deadlines is preformed by the following criteria check
Dependencies between features
Load balancing between code owners
Feature complexity
Bringing forward high-risk features first
Being considerate on when milestones can be set, and what is
required for the milestone
Preforming DSDMs MoSCoW on the above criteria to ensure that
the applications most essential features are placed at the front.
Chief programmers are assigned ownership of business activities
(or a batch of features). The assignment weighs in on the development
sequence, dependency of features, load of programmer, and the complexity of the coding.
Classes shall be assigned to developers to supervise the development of the features. As with the chief programmers, classes are assigned considering the complexity, balance, usage, and sequence the
classes are used.
At the end of this process, the following documents should have
been produced:
Activities have deadlines
Chief programmers are assigned to business activities
Developers are assigned to a list of classes.
38
6.1.4
3
4
Design by Feature
For every feature, this process is preformed. It is also under this process that the actual feature is prototyped.
To start, a feature team shall be formed from team members, under the recommendation of the Programming Authority. The option of
preforming a preliminary Domain Walkthrough and review of documentation shall be decided collectively by the feature team. At this point,
the team shall develop detailed sequence diagrams to illustrate program flow, and each document checked into the versioning system for
tracking purposes. After preforming the sequence diagrams, the Programming Authority shall review the generated artifacts and refine the
Object Model. Finally, the feature team shall write out a class listing
with prototypes for methods, placing class and method documentation
above each prototype. The Documentation Authority shall aggregate
the documentation from the source code into API documentation for
the other members.
The feature team, before moving on, shall review all the artifacts
generated and validate that the discussions preformed match.
Upon leaving the following artifacts shall have been generated:
A document describing the package developed
A document specifying all referenced material used in the development
Sequence Diagrams illustrating program flow
Updated Object Model
Generated API Documentation
Outlined prototypes of what needs to be coded
6.1.5
Build by Feature
This process preforms the steps for coding and implementing individual
features.
First, the feature team shall implement the required classes and
methods. After completion, the code shall be inspected for defects,
removing them before proceeding. Then unit testing is preformed to
validate that the produced code evaluates as specified by the documentation. Then the code is tested for any logical defects which results
in unexpected execution. Once the above elements are complete the
Chief Programmer reviews the activities and promotes the feature into
the build.
Upon completion the following documents shall be completed:
Classes and Methods both coded and inspect
6.2. METHODS, TOOLS, AND TECHNIQUES
39
Classes that have promoted to build inclusion

Completion of the Feature, with a review document over events
taken.
6.2
6.2.1
Methods, Tools, and Techniques

Modeling
D3 will adhere to the FDD best practices outlined in A Practical Guide

to Feature-Driven Development.
Domain Object Modeling (DOM)
Identifying and building class diagrams within the project domain. Each
object is assigned a stereotype, relationships with cardinality, and basic operations (methods). In addition to developing the class diagrams,
sequence diagrams shall be provided to illustrate common behavior
and workflow. The modeling shall be preformed using color to apply
visual emphasis on the model.
The information for forming the DOM shall be performed by the
system analysts and developers, and the information shall be obtained
through the Domain Expert.
Develop by Feature (DbF)
Features are the components in which Hot Sticks will be developed
upon. Each feature shall adhere to the feature template of action
result object.
Class/Code Ownership (CO)
Each Hot Sticks developer team shall be assigned a class to be responsible for and to manage.
Feature Teams
Teams shall be formed between class owners to collaborate on how to
satisfy a feature. The teams are not to be mutually exclusive, and the
development shall be preformed in the open.
Inspection
Once a week, the development process shall be inspected by the customer representative during the presentation of the Weekly Progress
Report. This covers coding inspection, documentation consistency, and
the development cohesion between the two.
40
Regular Build Schedule

Every day shall result in a build. Each build shall have a high level
description of changes made, supplemented with a bug tracking system
for storing detailed information about the changes.
6.2.2
Documentation
The format and standard of documentation will be illustrated in Annex A.6
6.2.3
Tools
Documentation
Developers will be collaborating documentation distributively over the
Internet via the dokuwiki web application. Upon a major phase completion, the wiki shall be converted into a hard document using the LaTeX
typesetting engine. A PDF of each of these periods shall be placed online in the dokuwiki system. Hard copies are produced on every release
version of Hot Sticks.
Coding
Program code will be made available through the use of a mercurial
repository. MS Visual Studio will handle build, compilation, linking,
unit testing, debugging, and packaging of all source code, and MS
Game Studio will handle the XNA libraries and the transfer of the program to the XBox system.
Bug tracking will be preformed using the Mantis Bug Tracking system.
6.3
6.3.1
Infrastructure Plans
Client Software
Each member is responsible for establishing and maintaining their own

personal infrastructure.
Each member of the Programming Unit shall acquire a Microsoft Visual Studio 2008 with XNA Game Studio 3.1 for project development
under Microsoft Windows XP, Microsoft Windows Vista SP1, and Microsoft Windows 7. In addition, each member wishing to participate in
source code evaluation shall need to use a Subversion client, in particular the TortiseSVN client.
The Documentation Authority shall use TeX Live 2009 to compile
6.4. PRODUCT ACCEPTANCE PLAN
41
hard copies of the Wiki documentation. Members wishing to develop/contribute charts and graphics shall use Microsoft Visio 2007.
Scheduling and tracking software shall be performed using Microsoft
Project 2007.
6.3.2
Server Software
The project shall use a LAMP webserver with libGD and LaTeX publishing capabilities, and a server to host subversion repositories. Both
resources will be implemented and managed by the Documentation
Authority.
These servers shall be used for hosting project content including,
Dokuwiki for Project Documentation
Subversion SCM for Hot Sticks
libapache2-svn for enabling webDAV support for subversion
WebSVN for web access to the Subversion client
Doxygen for documentation generation
MySQL for database transactions for all web services.
MantisBT Project Bug Tracking
6.3.3
New Software Proposition
When members wish to introduce new software, they shall present it

to the affected team members and illustrate the features that the software provides. After proposing this content, the affected members shall
demo the software for one week, and then come upon a decision by
way of vote determining if the new software should be accepted into
the project or to reject the software.
6.4
Product Acceptance Plan
Product acceptance criteria shall be set forth in this subsection. All

stakeholder policies shall be defined herein.
Project deliverables specified in Section 1.1.3 of this whitepaper
shall be delivered to all stakeholders. The following represents delivery specifics for each project deliverable.
42
6.4.1
IEEE SPMP Document
This document shall be tendered to customer representative on December 14, 2009. The acceptance of the whitepaper shall be determined by quality specifications delivered by the customer representative at project inception. Customer representative shall be sole judge of
whitepaper acceptance.
6.4.2
IEEE SRS
This document shall be tendered to customer representative on April

27, 2010. The acceptance of the whitepaper shall be determined by
quality specifications delivered by the customer representative at project
inception. Customer representative shall be sole judge of whitepaper
acceptance.
6.4.3
IEEE SDD
This document shall be tendered to customer representative on April

27, 2010. The acceptance of the whitepaper shall cover the detailed
development elements of each utilized class, and illustrate relations
and the conception of pseudocode for physical code generation.
6.4.4
Hot Sticks Application
The completed gaming application Hot Sticks shall be delivered to customer representative on April 20, 2010. Acceptance criteria shall be
defined as,
Demonstration of the final working product in form of a final review, conducted on or before April 20, 2010. This review shall
demonstrate fulfillment of product specifications set forth in this
requirement.
Completed application shall be reviewed for both functional requirements and non-functional requirements specified by the customer within the documents accepted by customer representatives.
2
Customer representatives shall be sole judge of product acceptance,

based on criteria set forth in whitepaper deliverables accepted by customer representatives.
Chapter 7
Supporting Process
7.1
Configuration Management Plan
Scope
All items identified in Section 1.1.3 shall be considered as configuration
artifacts. The configuration elements that will be covered are:
Base Lining
Versioning
Dependency Tracking
Change Management
Requirements Tracing
These elements shall be applied throughout the life cycle of the project.
7.1.1
Configuration Management
Organization
The organizational role shall be as defined in Section ??. The user
organization shall be defined as Microsoft Game Studios. User organization shall be in direct communication with development team. Interface between user organization and development organization shall be
achieved by weekly, direct communication between development team,
in the entirety, and user organization representative.
43
44
CHAPTER 7. SUPPORTING PROCESS
Responsibilities
Baseline management and implementation shall be achieved by the
entire organizational structure of the development team as defined in
Section 4.3. The user organization representative shall be responsible
for the determination of acceptance of configuration management items
for baseline purposes.
Interface Management
There shall be no external organizational entities.
Implementation
Baselines shall be established weekly, as defined in Section ??. A software review board shall consist of all entities identified in Section 4.
The board shall convene weekly and more frequently if schedule slips
occur.
7.1.2
Configuration Identification
Conventions
Naming and labeling conventions are to adhere to the specifications
outlined in Section ?? and in Annex A.6.
Baselines
All configuration items shall be defined as new to the work entities. No
purchased or reuse software items shall be included in any deliverable
entities. The hardware environment for all configuration items shall be
identical. The development environment is defined in Section ??.
Configuration Items
IEEE SPMP Document A deliverable whitepaper. Tools required will
be word processing software and documentation wiki system. Acceptance criteria is defined through the user representative illustrated in
the syllabus of University of Michigan Flint, Course No. CSC 383.
IEEE SRS Document A deliverable whitepaper. Tools required will
be word processing software and documentation wiki system. Acceptance criteria is define through the user representative illustrated in
the syllabus of University of Michigan Flint, Course no. CSC 483.
7.1. CONFIGURATION MANAGEMENT PLAN
45
IEEE SDD Document A deliverable whitepaper. Tools required will be

word processing software and documentation wiki system. Acceptance
criteria is defined through the user representative illustrated in the
syllabus of University of Michigan Flint, Course no. CSC 483.
Hot Sticks Application A deliverable Software Product. Tools required shall be Microsoft Visual Studio, XNA Game Studio, and XBox
360. Acceptance criteria is defined through the user representative illustrated in the syllabus of University of Michigan Flint, Course no.
CSC 483.
Hot Sticks Weekly Iterations A demonstration of the software iteration. Tools requires shall be Microsoft Visual Studio, XNA Game Studio,
and XBox 360. Acceptance criteria is defined through the user representative illustrated in the syllabus of University of Michigan Flint,
Course no. CSC 483.
7.1.3
Configuration Control
Code Control
Documentation control shall be realized through the usage of the wiki
system listed in Section ?? and Section ??. The source code control shall be implemented through use of Subversion mentioned in the
same sections.
Levels of Authority
Changes to a baseline shall be controlled by multiple entities, defined
by the product itself. Any configuration item baseline may be changed
by the project manager as well as the user representative. Specific
items may be changed by the following personnel:
IEEE SPMP Document The Documentation Authority shall have authority to effect baseline change.
IEEE SRS Document The Documentation Authority shall have authority to effect baseline change.
IEEE SDD Document The Documentation Authority shall have authority to effect baseline change.
Hot Sticks Application The Programming Authority shall have authority to effect baseline change.
46
7.1.4
Tools, Techniques, and Methods
The Tools and Methods for configuration management are previously

defined in the above subsections.
7.2
Verification and Validation Plan
In this section, includes the verification and validation of the software

project including scope, tools, techniques and responsibilities for the
verification and validation work activities. For instance, verifying the
scope of the project which is making a pool video game for Microsoft
XNA environment for XBox console and delivering each piece of working product in the next semester to the Microsoft Game Studios representative. As a professional software team we must validate and verify
that each deliverable of our software system meets the user requirement, review it in our next scheduled meeting for the next iteration,
what we have delivered so far to our customer and if the customer has
changed software requirements then we should implement the requirements changes into our existing software system for our customer standards and attributes. Also verification and validation plan includes the
objectives to find defects and determine if the required functions and
attributes are built into the software system.
7.3
Documentation Plan
Documentation for source code development shall be processed using

Doxygen documentation generator. The Source code highlighting shall
be generated via GenSHi documentation highlighting system for the
wiki system, and the listings package with a custom stylesheet inside
the LaTeX version. Source code will not be delivered in hard copy form,
but the API documentation shall be made available to all project members upon request. Each entry in the SCM is required to have a revision summary explaining what was changed and have an undersigned
whom is responsible for the check-in.
Documents that these elements persist to are itemized in Section ??
with the following templates:
SPMP: IEEE Std 1058-1998
SRS: IEEE Std 830-1998, Class Variant
SDD: IEEE Std 1016-1998
In addition, the project source code documentation shall adhere

to the above specifications. Testing shall occur on each project iteration and encompass product stability, reliability, responsiveness, and
7.4. QUALITY ASSURANCE PLAN
47
overall human interfacing review such as appropriate input layouts,

effective GUI representation of data, and proper transitions between
elements.
7.4
Quality Assurance Plan
This checklist is provided as part of the evaluation process its purpose

is to assure that documents achieve the highest standards relative to
format, consistency, completeness, quality, and presentation. To ensure the quality is maintained and achieved in developing each feature
of the FDD model the following checklist must be ensured at all times.
Quality assurance combines all elements of planning, developing
and testing of the features.
7.4.1
Initial phase
1. Identify Standards and Guidelines

2. Evaluate Software Tools
3. Evaluate Process Method
4. Evaluate Project Planning, Development, and Design
5. Evaluate Coding Language
6. Evaluate Requirements Analysis
7. List Required Features
8. Evaluate Scheduling Plan
9. Evaluate Project Bi-Weekly Milestones
10. Evaluate Graphic Requirements
11. Evaluate Design Process
12. Evaluate Team member Skills and Shortcomings
13. Evaluate Workflow Distribution
14. Evaluate Review Process
15. Evaluate Pseudo Testing Process
16. Evaluate Product Readiness
17. Perform Configuration Audits
18. Evaluate Risk Management
48
19. Evaluate Product Marketing Management
These checks are to be preformed in real time and by all development team members. Should a change not satisfy the above criteria,
the user whom identified the issue shall contact the the owning authority and request it to be changed. The authority shall distribute this
information to the responsible class owners and monitor the progress
of the change.
During each phase, the quality checklist must be addressed and
possibly have peer review if the quality does not meet the standard.
The peer reviews shall be attached to the quality checklist.
7.5
Reviews and Audits
There are different kinds of reviews based on each development phase

of the software, and they are held every two weeks and also whenever
the need arises to hold them for the benefit of the software development.
During the life-cycle of the software development, the following types
of reviews are conducted:
1. Specification Review: The project specifications, the scope of project,
features to be implemented are all discussed.
2. Requirements Review: The team members reflect on the requirement analysis for developing a particular feature, and also the
the general requirements for the software along with methods of
implementation to achieve them.
3. Design Review: Team members see the design requirements of the
product, verify the approach decided by the team and discuss on
any new developments that would be required.
4. Preliminary Design Review: This is the pseudo code testing review
of the product features, the team gets to see the working demo and
analyze the possibilities of improvement and arrive to conclusions
about the product.
5. Critical Design Review: During the critical design phase of a feature, the team reflects on any drawbacks or additions the design
requires or that can be included for over all high performance.
Any problems are critically analyzed, brute force methods used if
necessary to ensure the smooth flow of the team work.
6. Production Readiness Review: Once the design phases are over,
each feature is tested over in different environments to ensure
product stability and to find out any glitches along the lines.
7.6. PROBLEMS RESOLUTION PLAN
49
7. Acceptance Test Review: The product is demonstrated to the customer or business partner and feedback is accepted. Based on the
feedback given the product is then subjected to one final modification routine in accordance with the demands.
8. Post-Implementation Review: Once the product has gone through
all the stages of development, design, the team decides the marketing factors of deploying the product. This involves product promotion ads, legal documents, user manuals etc.
9. Informal reviews: Depending on the kind of situation that the
team face during the product development, design phase, informal reviews will be held just to handle the situations. This could
involve issues relating to less contribution from a particular team
or individual, wrong approach taken despite the specification discussed etc.
Audits are conducted for the product and will be scheduled accordingly informing the entire team of the time and requirements to complete before them. A review report is maintained so that all the discussed topics are logged and distributed to the team in the Capstone
Progress Report document, after each session to facilitate a history of
performed tasks. The software shall be very reliable if the team follows
through all these reviews diligently.
7.6
7.6.1
Problems Resolution Plan

Human Resources
Problems between human personality elements shall be managed by

the project leader. Should a severe issue arise, the project consultant
may inject or deject the personnel from the project.
7.6.2
Documentation
Documentation issues which arise shall be solved by the Documentation Unit by way of majority vote.
7.6.3
Source Code
Problems and other issues involving the source code shall be submitted via the bug tracking system listed in Section 6.2 and are refereed
to as tickets. The term issue is used vaguely in this system, and shall
be used for reporting both new additions to the program, or injected
defects. Each problem shall have a date issue found, due date, category, the level of reproduction, a reporter, a programmer assignment,
50
resolution status, estimated fix time, problem summary, detailed issue

log, and miscellaneous files which assist in illustrating the problem.
Each problem will have a modification log which tracks all changes
to each ticket. On each ticket resolution, a hard copy of the ticket is
attached in Annex A.6
7.7
Subcontractor Management Plan
Subcontracting shall not be permitted as per user representative conditions set for attribution illustrated through Academic Misconduct.
7.8
Process Improvement Plan
This section of SPMP shall include basically the improvement assessing mechanism for the project and determine what areas need to be
improved and implement this improvement plan, which means in our
project it will not only be fixing bugs in LOC (lines of codes) but assure
how to implement customer issues into the system to make it evolve to
suit customer requirements. For example, if the balls on our pool game
happen to appear larger than the customers expectation then it will be
brought to attention in the next meeting with a determination of how to
change the size of the balls. Similarly, if the customer wants the table
size to be change or the pool stick size or color then we can decide how
to implement such changes into our system.
Chapter 8
Additional Plans
8.1
Intellectual Property
All details involving Intellectual Property of this document is specified

by the University of Michigans policy to student projects. The release
and distribution of private information about the personnel that have
invested time in the project shall be managed by the same organization.
Should a problem arise with Intellectual Property ownership, consultation by the Project Manager and Project Supervisor shall be provided to the involved user.
8.2
Acquisition of Staff
Upon the addition of staff in the project, the Project Manager and Chief
Documentationist shall provide access to the SPMP, SRS, and the history of SDD documents to the staff member. In addition, the staff
member shall undergo three training seminars,
Project Vision Seminar where the goals and accomplishments of the
project are addressed
Project Documentation Overview where a generic view of how documentation shall be used in the project
Project Programming Overview where a generic view of how programming activities shall be performed in the project.
51
52
CHAPTER 8. ADDITIONAL PLANS
Part II
SRS
53
Chapter 1
Introduction
1.1
Purpose
This whitepaper is designed to illustrate in detail the requirements of

creating a cross platform pool game over the course of specifications
directed underneath the IEEE standardization corporation. This generalization shall specify exactly what and how the Hot Sticks project
shall be composed of and break down each individual component such
that guest developers can obtain a proper image and philosophy for the
project as discussed in detail inside the Hot Sticks SPMP document.
This SRS document shall encompass descriptions of each component
in the running head revision of Hot Sticks development. Albeit, this
document shall not describe low level constructs of a given language,
such as the meaning of a for-loop, or other source code language primitives.
1.2
Scope
This specification shall apply to the Windows Vista, Windows 7 and

XBox 360binaries to be produced, as outlined in the Software Design
and Project Plan documents for the Hot Stickssystem. The goal of this
project is to develop a game that is user friendly that is delivered in a
unique way, with the End Users satisfaction being the primary goal in
mind.
1.3
Definitions, Acronyms, and Abbreviations
A feature is any form of user, system, query, or reaction that requires

some form of manipulation on the behalf of developers. Note that this
project follows Feature Driven Development (henceforth FDD), thus
55
56
development is centric to this concept. The term Business Activity

as specified in the FDD process and referenced in Hot Sticks SPMP
whitepaper illustrates a series of features to accomplish a task.
This document will use the terms Milestone, Business Activities and
Phases interchangeably. When such a term is read, understand that
it is a barrier regarding some developmental requirements. This document makes a careful separation between Milestones and Business
Activities, where Milestones may contain several Business Activities, or
may split them into two Milestones.
The terms XBox and XBox 360 are used interchangeably, which
should always be understood to mean XBox 360.
1.4
References
This document references one additional specification papers which

was developed specifically for Hot Sticks. This document is the Hot
Sticks Software Project Management Plan, which illustrates the business plan for proper development, scheduling, milestone identification,
organizational structure of active developers and project leaders, as
well as developmental tools required to complete the project. This document conforms to the IEEE SPMP 1058-1998 standard, using the
class focused template. This document is still in draft form, thus, due
to this fact, a hard copy of this document is not frequently made. Although, the head revision of this document is made readily available
online for all developers in the Hot Sticks system in a wiki format.
Frequently, the constructs of FDD are used throughout this document. The FDD specification can be located on Nebulons website.
A more detailed document illustrating FDD can be found in the book
A Practical Guide to Feature Driven Development 1st edition written by
Stephan Palmer and John M. Felsing.
An additional document that would facilitate fluency in reading would
be the OMG OCL 2.0 draft specification document, which is what the
constructs of pseudocode utilized in this document was based upon.
This document is freely available from the OMG website.
1.5
CHAPTER 1. INTRODUCTION
Overview
This document shall now discuss the specification vision via descriptions, and itemize how each component of design shall be designed.
The description section shall explain the project vision and definitions on why such views are made in the development. In addition, the
description shall itemize all the required features to be performed in
a Phase. Limitations, assumptions, and developer assignments made
1.5. OVERVIEW
57
during development shall be defined here.

The requirements section shall itemize by class how each component in the system shall operate. This is done by way of sequence, Class
Responsibilities Collaborator (CRC) cards, and class diagrams, and
defining attributes and methods belonging to the associated classes.
Pseudocode shall be used to explain the general flow of the module and
provide additional clarity.
58
Chapter 2
Overall Description
2.1
Product Perspective
Hot Sticks is a stand alone game installable on Windows Vista or Windows 7 and XBox game consoles. It is a single player or multi player
environment to be run on a single machine. The game requires a video
card compatible with XNAs Game Studio or the latest version of DirectX, to execute efficiently. The game is compatible only with Windows
and not other operating systems. The game I/O controllers are the joy
stick and keyboard.
User interface, which comprises of the display screen and the game
loaded, is very easy to understand. The layout and the color of the user
interface is very appealing. The user shall be able to learn directions
for game play using the available help option, which shows the user
which controller element is used for which action. The system displays
the exact output as per the chosen element of the game controllers.
The hardware interface for the system, since it runs on both PC and
XBox 360 console, are all the hardware that are required to connect
them. The main interfaces are the TV screen, laptop screen, XBox 360,
mouse, keyboard and joystick.
2.2
Product Functions
The project shall be broken into several phases, where functionality is

divided by conceptual blocking. Each feature shall be specified by the
model of action result object.
2.2.1
Milestone 1: Base Game Development
This phase is to be identified as a basic pool game without any additional functionality.
59
60
CHAPTER 2. OVERALL DESCRIPTION
List of Features
Check if Cue is Ball.
Obtain Ball Radius from Ball.
Update Position of Ball. (x,y,z)
Update Velocity of Ball.
Update Direction of Ball.
Check for Motion of Ball Animation.
Detect Collision of Ball Animation.
Resolve Collision of Ball Animation.
Update the Ball Location from Ball Animation.
Update Ball Table on Pocket Collision from Ball Animation.
Position the Location of the Stick.
Set Validity of Stick.
Update Stick Validity from Stick Animation.
Update Stick Location if Stick Enabled at Ball Cue location from
Stick Animation.
Update Ball Force if Stick Enabled from Stick Animation.
Update Ball Velocity if Stick Enabled from Ballshot Input signal
on Stick Animation.
Obtain BallShot signal from Input.
Obtain StickAngle signal from Input.
Obtain StickForce signal from Input.
Calculate output of Stick-Ball collision using Physics.
Calculate output of Ball-Ball collision using Physics.
Calculate output of Ball-Table collision using Physics.
Manipulate Ball Speed using Physics.
Get Bounds of Table.
Obtain Pockets of Table.
Get Layer of Table.
Obtain Location of Pocket.
2.2. PRODUCT FUNCTIONS
2.2.2
61
Milestone 2: Multi Tier Refactor
This phase shall refactor the product to allow for multi-tier gameplay.
This includes the ability to traverse the tables using warps.
Move Cueball position from Ball Manager
Update Game State in GameStateManager
Snap View to Cueball Level on no Ball Movement in Game State
Manager
Signal Cue Placement from Input
Signal Table Up from Input
Signal Table Down from Input
Display Current Level View in Artist
Set Current Level View in Artist
Draw Warps in Artist
Add Warp to Game Content
Create a new Warp Pair from Warp
Resolve Actions in Warp Manager
2.2.3
Milestone 3: State Control
This phase shall refactor the product to allow state controls. This includes game saves, replays, pause, resume and other transitions.
Snapshot Menu Content in Artist
Exit the Game if Exit State is set in Game.
Accelerate Time while in Shot State in Game.
Decelerate Time while in Shot State in Game.
Reset Time when balls are not moving in Game.
Set Game State to Title State in Game State Manager
Set Game State to Paused State in Game State Manager
Set Game State to Load Save State in Game State Manager
Return to Title State from Pause State in Game State Manager.
62

Resume Game State to Previous State from Pause Screen in Game
State Manager
Set Title Manager Data in Menu Content
Set Pause Manager Data in Menu Content
Set Load Save Manager Data in Menu Content
Write Data to Persistent Storage.
Read Data from Persistent Storage.
Serialize data from Game Content.
Select Option to Manage in Title Manager
Select Option to Manage in Pause Manager
Select Option to Manage in Load Save Manager
2.2.4
Milestone 4: Manipulation
This phase shall refactor the product to allow user changeable physics
settings, and other various configurations. In addition to physics, the
user shall be able to change the number of balls, game rules, and
general activities in an options menu.
Enter Game Customization Mode from TitleManager.
Enter Game Customization Mode from PauseManager.
Change the Mobility of Warps in GameSettingsManager.
Increase the number of warps in GameSettingsManager.
Decrease the number of warps in GameSettingsManager.
Place the Warp Location in GameSettingsManager.
2.2.5
Milestone 5: Replay
This phase shall refactor the product such that a user has the ability
to replay games and have the capabilities to track backward through a
previous saved game.
2.2.6
Milestone 6: Local Multiplayer
This phase shall refactor the product to allow multiple users to play a
game at once with separate controllers. This includes creating competitive games where players play against one another.
2.3. USER CHARACTERISTICS
2.2.7
63
Milestone 7: Network Multiplayer
This phase shall refactor the product to allow multiple users to play a
game at once using separate XBoxconsoles within XBoxLive.
2.2.8
Milestone 8: Artificial Intelligence
This phase shall refactor the product to enable agent monitoring and
interactions.
2.2.9
Milestone 9: Third Dimension
This phase shall refactor the product to work in three dimensional

space. This includes the addition of camera angles and views, and
ball jumps.
2.3
User Characteristics
A wide range of people varying in gender, age, and nationalities are the
users of this game system. The common characteristics required of the
users are:
1. Must know to operate computer
2. Must know to operate XBox 360
3. Must know to connect the TV with XBox 360
4. Must understand the language to use the help guide
5. Must understand the game (reading instructions)
6. Must have the ability to use keyboard
7. Must have the ability to use mouse
8. Must have the ability to use joystick
2.4
Constraints
The limitations based on which the product has been modeled are:
1. Requires Windows Operating System, XBox 360.
2. Requires XNA Game Studio 3.0 or higher.
3. Requires video card drivers compatible with DirectX 9.0.
4. Graphic display is two dimensional.
64
5. Audio files need licensing rights.

6. Supports at most two simultaneous players.
2.5
Assumptions and Dependencies
It is assumed that users are capable of reading and understanding

the English language interface. It is also assumed that both external
hardware and software are functioning properly.
The project depends on user input through a joystick or keyboard
interface which is controlled either by the XBox or a Microsoft Windows
OS platform.
2.6
Apportioning of Requirements
In accordance to the FDD process, work shall be divided class-wise. All

documentation matters in regards to classes are to be held responsible by the owning party, and shall be proofread by the documentation
authority specified in the Hot Sticks SPMP document.
Chapter 3
Specific Requirements
3.1
External Interfaces
There are only two forms of interface used in both the production and
binary versions of Hot Sticks. The first is a player at the XBox unit
itself. The second is a player at a PC computer. These interfaces gameplay elements such as controller inputs and file data. In response, Hot
Sticks sends both of these interfaces display and reaction data such as
force feedback.
The second interface is user at Visual Studio, which is used by developers, where code is deployed to the XBox unit and debug data is
fed back to the development environment.
These interfaces are illustrated via figure 3.1.
3.2
User interfaces
User interfaces shall be designed as reactive and animated such that it

is pleasing to the eye. The sport of pool is known for its smooth gameplay with hard colors and distinct designs of game elements. Figure 3.2
and Figure 3.3 shall be the baseline for user interface placement and
design.
3.3
Hardware interfaces
Hot Sticks shall be extremely flexible in game input. Users shall be

able to utilize keyboard, mouse, and/or gamepad input devices to interact with all necessary controls for interacting with the system. These
interfaces have libraries provided by XNA for handling signal input.
65
66
CHAPTER 3. SPECIFIC REQUIREMENTS
Player@Xbox
Display Output
Debug Data
Controller Input
Game Code
Hotsticks
Keyboard/Mouse/Gamepad
Input
Player@Computer
User@Microsoft Visual
Studio
Display Output
Figure 3.1: Hot Sticks Context Diagram
3.3. HARDWARE INTERFACES
Figure 3.2: Primary Menu and Table Design
67
68
Figure 3.3: Primary Game Elements and Title Screen
3.4. SOFTWARE INTERFACES
3.4
69
Software interfaces
The primary and only software interface this project shall use is the
XNA game libraries provided by Microsoft. These libraries provide extensive functionality on generating graphic primitives, interfacing user
input, and control constructs. The version this project shall use version 3.1 of XNA Game Studio provided by Microsoft
3.5
Communications interfaces
Communication interfaces are provided inside the XNA game libraries

specified in the software interfaces. This inherently means utilizing a
Windows Live ID associated with an XNA profile shall be needed for
deployment. All management of this interface shall be handled by Microsoft.
3.6
Classes
The identified classes for the Hot Sticks development can be seen in
Figure 3.4
3.6.1
Artist
Owner: Rob The artist class offers the capabilities for drawing primitives, compiling view elements on a canvas, applying textures, and
visually depicting all graphical elements in the Hot Sticks project.
CRC Card
Responsibilities
Knows
Snapshot of Game Content
Snapshot of Game State Manager
Position where the elapsed time should be drawn
Position where game state should be drawn
Does
Draw graphical primitives in 2D
Apply a texture to primitives
Create structure
Show total elapsed time
70
Persitent Data Manager
1
1
-DBase : Game Content

+WriteData()
+ReadData()
+Serialize()
+Snapshot()
XNA::Game
Game
-DBase : GameContent
-MenuData : Menu Content
+LoadContent()
+UnloadContent()
+Initalize()
+Update()
+Draw()
Warp Manager
1
BallManager
-CueBallLocationUpdate : Vector3
-UpdateCueBallPosition : bool
+MoveCueBallPosition()
1
1
Game State Manager

1
+Movement : bool
+Scratch : bool
+ScratchLevel : float
+State : GameState
+Pause : bool
+Exit : bool
+LoadSave : bool
+CuePlaced : bool
-Previous State : GameState
+UpdateState()
Object Manager
#Number Iterations : int
+Resolve() : GameContent
#DetectCollision()
#BoundaryCheckMovingObjectRectangle() : Vector3
#BoundaryCheckStaticObjectRectangle() : Vector3
#BoundaryRectangle() : Rectangle
#BoundaryCheckObject() : Vector4
StickManager
+UpdateStick()
Physics
1
+CalculateBallBallCollision() : decimal
+CalcluateBallTableCollision() : decimal
+AdjustBallSpeed() : Ball
1
1
1..4
Input
1
Artist
-Exit : bool = False

-Shot : bool = False
-PrepareShot : bool = False
-DeltaAngle : float = 0
-Force : float = 20
-FreezeLevel : int = 0
-pad : GamePadState
-ppad : GamePadState
-keyboard : GamePadState
-pkeyboard : GamePadState
-MenuSelection : bool
-MenuMovement : int
-GameSpeed : float
+SetFreezeLevel()
+HasShot() : bool
+PlacementDone() : bool
+SignalPrepareShot() : bool
+Angle() : float
+GetForce() : float
+DirectionalShift() : int
+DirectionalMovement() : Vector2
+MenuMovement() : int
+GameSpeed() : float
+MenuSelection() : bool
-DBase : GameContent
-TraceTime : Vector2
-TraceForce : Vector2
-TraceLevel : Vector2
-StateManager : Game State Manager
-Menu : Menu Content
+Snapshot()
+Go()
-DrawBalls()
-DrawTable()
-DrawStick()
-DrawClock()
-DrawPauseScreen()
-DrawFileMenuScreen()
-DrawTitleScreen()
-DrawExitConfirmationScreen()
1
GameContent
1
1..*
+Balls : Ball
+Pockets : Pocket
+Stick : GameObject
+Tables : Table
+Warp : Warp
+IsMoving : bool
+GameLevel : int
+AddBall()
+AddPocket()
+AddTable()
+AddStick()
+AddWarp()
1
1
1
1
Menu Content
1..*
*
Ball
Table
-Cue : bool = False

-Radius : float
-Barrier : Rectangle
-CuePlacement : Rectangle
-Title Manager Data : Title Manager

-Pause Manager Data : Pause Manager
-Load Save Manager Data : Load Save Manager
-Game Settings Manager Data : Game Settings Manager
+SetTitleManager()
+SetPauseManager()
+SetLoadSaveManager()
+SetGameSettingsManager()
*
1
GameObject
-Sprite : Texture2D
-Center : Vector2
-Velocity : Vector2
-Rotation : float
-Scale : float
-Layer : float
-Alive : bool
*
1..*
Pocket
1
1
*
Pause Manager
-Radius : int
1
Game Settings Manager
Load Save Manager
Warp
-ID : int
Title Manager
-Logo : Texture2D
+UpdateSetting()
Menu Manager
-CurrentOption : int
-ListOptions : string
-Background : Texture2D
-Overlay : Texture2D
-Font : SpriteFont
-Start Position : Vector2
#SelectOption()
Figure 3.4: Hot Sticks Top Level Class Diagram
3.6. CLASSES
71
Show amount of force imparted on cueball

Update Canvas
Collaborators
Game
GameContent
MenuContent
Attributes
DBase The snapshot of game content in question
TraceTime The location in which the game timer shall be drawn on
the screen, using upper left hand corner
TraceForce The location in which the inputted force shall be drawn on
the screen, using upper left hand corner.
StateManager Snapshot of the current game state using the GameStateManager utility class
MenuContent List of all needed elements to draw menu screens.
Methods
Snapshot Obtains a snapshot of the current game data and state in
which to draw to the screen
Go Redraws associated graphical elements held in Game Content
3.6.2
Ball
Owner: Bill A Ball class is an object representing individual pool balls

located on a table. Each pool ball shall be seen as a radius from a
particular coordinate, and have a uniquely identified BallID. Ball object
class is a child class inheriting all properties of the GameObject class.
CRC Card
Responsibilities
Knows
Ball Radius
Ball Cue Ball Status
72

Warp ID of Warp which ball is interacting with (during WarpBall collision)
Ball Identification number
All GameObject Data
Does
Collaborators
None
Attributes
CueBall A Boolean value representing if a given ball is to be identified
as a CueBall or if it is a normal ball.
Radius Integer that represents the number of pixels the balls radius
shall be.
IsCue Boolean value which represents ball status as the cue ball.
WarpingWarpID Integer ID number of Warp object during Warp-Ball
collision.
BallID The identification number of the Ball object.
Methods
None
3.6.3
Ball Manager
Owner: Bill The Ball Manager class shall manage each ball that exists
in a game and handle all positional updates and provide a signal to
show whether or not there is any movement on the table.
CRC Card
Responsibilities
Knows
The position change of the Cue Ball
The indication to change Cue Ball position
Does
Determines if any Balls are in Motion
Updates Positions of all Ball Objects
3.6. CLASSES
73
Detects Collisions of all Objects

Resolves Collisions of all Ball Objects
Verifies that all ball objects are within table bounds.
Collaborators
Physics
Attributes
CueBallLocationUpdate Position vector to update cue ball position
from public methods.
UpdateCueBallPosition Boolean value to indicate whether Cue ball
position has to be updated.
Methods
Resolve Public function used to initiate ball management functions.
DetectCollision Detects object collisions between all game objects. Collisions are then resolved utilizing the Physics class methods.
MoveCueBallPosition Updates changes in the cue ball position.
3.6.4
Game
Owner: Rob The game class is a generated class that must be used
for XNA games to properly launch. The class executes an initial load
of libraries and data, then runs the update method every sixtieth of a
second, followed directly by the draw method every sixtieth of a second.
Upon game closure, the unload game data is run.
CRC Card
Responsibilities
Knows
Scaling factors
Game element textures
User Input
Ball IDs
Warp IDs
Does
Initializes Game
74

Load Game Data
Unloads Game Data
Updates Game Data
Draws Game Data
Collaborators
GameContent
Artist
Input
GameStateManager
StickManager
WarpManager
GameManager
Attributes
BALL_SCALE Scale factor to apply to balls
STICK_SCALE Scale factor to apply to the stick
TABLE_SCALE Scale factor to apply to the table
POCKET_SCALE Scale factor to apply to the pockets
WARP_SCALE Scale factor to apply to warps
pad Gamepad input
keyboard Keyboard input
StickSprites List of stick sprites
TableSprites List of table sprites
BallSprites List of ball sprites
PocketSprites List of pocket sprites
WarpSprites List of warp sprites
MenuSprites List of menu sprites
3.6. CLASSES
75
Methods
Initialize Loads all non-graphic requirements of the game
LoadContent Loads all graphic requirements of the game
UnloadContent Releases all graphic requirements of the game
Update Loops every sixtith of a second which holds sequential gamestate methods.
Draw Redraws the viewport according to the methods placed here.
3.6.5
Game Content
Owner: Bill Game content contains all objects such as Balls, Tables,
Pockets and a pool stick. The Game Content class also keeps track of
presence of total ball object movement.
CRC Card
Responsibilities
Knows
A list of Ball class objects.
A list of Table class objects.
A list of Pocket class objects.
A list of GameObject class objects for pool stick.
A list of Warp class objects.
If any Ball objects from the list of Balls has a Velocity Magnitude greater than zero.
The current game level in view.
The Warp Pair count for the addition of Warp objects by pair.
Does
Adds Ball objects to Balls list.
Adds Table objects to Tables list.
Adds Pocket objects to Pockets list.
Adds Warp objects to Warps list.
Collaborators
None
76
Attributes
Balls Ball class objects organized into a list data structure.
Tables Table class objects organized into a list data structure.
Pockets Pocket class objects organized into a list data structure.
Stick GameObject class object with single instantiation.
Warps Warp class objects organized into a list data structure.
IsMoving Boolean value to indicate if any Ball objects in Balls list have
Velocity Magnitude greater than zero.
GameLevel Integer value to indicate current table level of play.
WarpPairCounter Counter used to add Warp objects in multiples of
two.
Methods
AddBall This function is used to add Ball class objects to the list of
Balls.
AddPocket Function to enable the addition of pocket class objects to
the list of Pockets.
AddTable Method to enable the addition of Pocket class objects to the
Pockets list data structure.
AddStick Method to enable the addition of GameObject class objects
to the Sticks list data structure.
AddWarp Method to enable the addition of Warp class objects to the
Warps list data structure.
3.6.6
Game Object
Owner: Rob The Game Object class is a parent class for all graphical
objects in the Hot Sticks system. It acts as a dataholder for object
texture, dimensions, scaling, and other factors.
CRC Card
Knows
Texture of Object
Position of Object
Type of Object
3.6. CLASSES
77
Objects Center
Velocity of Object
Rotation of Object
Scale of Object
Layer of Object
Visibility of Object
Does
None
Collaborators
None
Attributes
Sprite A 2D raster image to represent the object.
Position The absolute x,y pairing representing where the objects center shall be placed on the graphics device.
Type Enumerated type to determine what type of object this is.
Center The x,y pairing of the sprites center.
Velocity A x,y pairing where x represents the direction in radians, and
y represents the magnitude the object shall be moving.
Rotation The value in radians in which the sprite shall be rotated.
Scale A floating point value to represent how much to scale a sprite
from its original size
Layer Specifies the order in which the graphic shall be painted. Smaller
numbers are painted after larger numbers.
Alive Boolean value to determine object visibility
Methods
None
3.6.7
Owner: Bill The Game Settings Manager class is an inherited class

from Menu Manager. It handles all user-configurable game settings.
The class handles the display of menu options as well as the facilitation
of menu selections based on state and game content data.
78
CRC Card
Responsibilities
Knows
Menu Manager Data
Does
Updates Game State indication flags based on user selections.
Facilitates Game Content changes based on user selections.
Collaborators
None
Attributes
None
Methods
SelectOption Updates game state flags dependent on user menu item
selection.
UpdateSettings Enacts the game content changes indicated by user
menu item selection.
3.6.8
Game State Manager
Owner: Bill Manages the game states of the Hot Sticks game, acting
as the gatekeeper for state transitions.
CRC Card
Responsibilities
Knows
Ball Movement state
Cue Placement state
Scratch state
Scratch Level
Pause state
Exit state
LoadSave state
3.6. CLASSES
79
Does
Detects Ball motion
Sets game state to indicate ball movement when ball are in
motion.
Sets game state to allow Cue placement when ball motion
stops.
Sets game state to allow Shot placement once Cue is placed.
Sets game state to allow game pause.
Sets game state to indicate game exit.
Sets game state to facilitate Load and Save file utilities.
Collaborators
None
Attributes
State Current active state of Hot Sticks game application.
Movement Boolean indication of any ball object movement.
ScratchLevel The GameLevel attribute last before cue ball scratch.
Scratch Indication of Cue Ball scratch status.
Cueplaced Cue ball indication of successful placement after cue ball
scratch.
Pause Indication of all game object movement frozen.
Exit Flag to indicate desired exit from current state.
Load Save Indicator to flag desire to enter file operation state.
Previous State State value of previous state.
Methods
UpdateState Checks the current game state and changes it to make
cue placements and shot placements accordingly when ball are
not in motion.
3.6.9
Input
Owner: Rob Input handles the unification of input devices keyboard,

mouse, and gamepad, and listens without blocking for desired inputs;
offering signals for other classes to interact.
80
CRC Card
Responsibilities
Knows
Ball Shot input

Angle input
Force input
Exit input
Controller Freeze Level
Current and Previous Game Pad input
Current and Previous Keyboard input
Does
Listens for Input

Get Ball Shot Signal
Get the angle of Shot
Get the force of Shot
Sets the freeze level to constrain input commands
Get directional pad inputs.
Collaborators
None
Attributes
Exit Holds a Boolean value for when the exit input has occurred.
Shot A Boolean value to signify a shot input was fired.
PrepareShot A Boolean value to signify a shot is about to be taken.
DeltaAngle A delta measure (in radians) to propagate the angle of a
given shot.
Force A measure to specify the strength of a given shot.
FreezeLevel Holder for determining specific input availability. This
functions as a lock.
Pad The current state of the gamepad
ppad The previous state of the gamepad
keyboard Only enabled on Windows, the current state of the keyboard
pkeyboard Only enabled on Windows, the previous state of the keyboard
3.6. CLASSES
81
Methods
SetFreezeLevel Sets the freeze level of inputs
HasShot Returns true when a shot command event occurs.
Angle Returns the current angle of owning device.
GetForce Returns the force of owning device.
PlacementDone Returns true when user has placed a ball on the
screen.
SignalPrepareShot Returns true when user is starting to make a shot
DirectionalShift Returns a delta value which is used to change the
currently visible level
DirectionalMovement Returns two values to represent a delta movement that is performed when a user needs to place a ball on the
table.
3.6.10
Load Save Manager
Owner: Bill The Load Save Manager acts as a controller for screen
display when saving and loading a game. When either the save or load
option is fired, it updates the state of the game.
CRC Card
Responsibilities
Knows
State of game save
Menu Manager Data
Does
Knows its own state
Collaborators
None
Attributes
None
82
Methods
Select Option Updates game state flags dependent on user menu item
selection.
3.6.11
Menu Content
Owner: Bill The Menu Content is the information holder class containing all menu management class objects for Hot Sticks game application.
CRC Card
Responsibilities
Knows
Title manager class object.
Pause manager class object.
Load/Save manager class object.
Game Settings manager class object.
Does
None
Collaborators
None
Attributes
TitleManagerData TitleManager object for splash screen content and
management.
PauseManagerData PauseManager object for pause screen content and
management.
LoadSaveManagerData LoadSaveManager object for LoadSave menu
content and management.
SettingsData GameSettingsManager object for altering game play settings.
3.6. CLASSES
83
Methods
SetTitleManager Method to initialize instance of TitleManager attribute.
SetPauseManager Set instance of PauseManager attribute.
SetLoadSaveManager Set instance of LoadSaveManager attribute.
SetGameSettingsManager Set instance of GameSettingsManager attribute.
3.6.12
Menu Manager
Owner: Bill The Menu Manager is the parent class for all menu class
objects of the Hot Sticks game application. It maintains all data and
methods relative to menu management.
CRC Card
Responsibilities
Knows
The option of a menu which is currently pointed to by the
menu selection indicator.
The list of options in the current menu for selection.
Background graphic for the current menu screen.
Graphic for the menu indication pointer.
Scaling factor for the indicator graphic object.
Overlay for graphical display purposes.
Font for option menu strings.
Starting screen position for menu display.
Does
None
Collaborators
None
84
Attributes
CurrentOption The integer value of the currently indicated option of
the current menu.
ListOptions List of alphanumeric strings describing current menu options.
Background Background graphic for screen.
OptionIndicator Texture graphic for menu selection indicator object.
IndicatorScale Scale factor for indicator texture.
Overlay Screen overlay for display of menu content over game content.
MenuFont Sprite menu font.
StartPosition The screen position to display string menu options.
Methods
SelectOption Virtual method to be overwritten by inherited classes.
AddOption Method to add string description options for menu selection choices.
3.6.13
Object Manager
Owner: Bill Manages GameObject, their movements and collision.

Ensures that ball (in motion and at rest) are contained inside specific
boundary limits and do not occupy the same position.
CRC Card
Responsibilities
Knows
Number of times to repeat Update method per method call.
Does
Sets boundary positions of static objects.
Sets boundary positions of moving objects.
Creates rectangular boundary for collision.
Ensures game objects do not occupy the same space.
Collaborators
None
3.6. CLASSES
85
Attributes
NumberIterations The number of times to perform the content of the
Update method.
Methods
Resolve A public virtual function that returns objects of GameContent
and is to be overridden.
DetectCollision A protected virtual function that detects collision of
objects relevant to the class and returns objects of GameContent.
BoundaryCheckMovingObjectRectangle Detects if a moving object
has passed the rectangular boundary set by a rectangle
BoundaryCheckStaticObjectRectangle Resolves a static object position to within a specified boundary.
BoundaryRectangle Creates a barrier that is less in each direction by
the radius of an object.
BoundaryCheckObject Ensures two mobile objects to occupy different
physical space at any instant.
3.6.14
Pause Manager
Owner: Bill The Pause Manager class is an inherited class from MenuManager. It handles game pause options and selections. The class
handles the display of menu options as well as the facilitation of menu
selections based on state and game content data.
CRC Card
Responsibilities
Knows
MenuManager data
Does
Collaborators
None
86
Attributes
None
Methods
SelectOption Updates game state flags dependent on user menu item
selection.
3.6.15
Persistent Data Manager
Owner: Bill The Persistent Data Manager class handles all persistent
data storage functions of the Hot Sticks game application.
CRC Card
Knows
Game content object for all Hot Sticks game application data.
Save File Data structure type which holds all pertinent data
to be saved or loaded.
An XML serializer data object for XML conversion.
An asynchronous indicator for file operation status.
The file storage name for file operations.
The storage device where game data files will be found/placed.
Indication of storage device selection initiation.
Indication of storage device selection.
Indication of storage device end of selection initiated.
Does
Takes snapshot of current game content data.
Selects file storage device for file operations.
Writes serialized data to file storage location.
Reads serialized data from file storage location.
Packs data into Game content class object after read.
Unpacks data from Game content class object for write.
Collaborators
None
3.6. CLASSES
87
Attributes
GameContent The data manager copy of all game content.
GameSave The extracted critical save data.
DataSerializer XML data serializer class instance to convert game data
to XML data.
DeviceResult Flag to indicate asynchronous result.
StorageFileName The file name for game data storage.
StorageDevice The storage device for file storage.
StorageDeviceSelectionInitiated Flag to indicate file location selection initiated.
StorageDeviceSelected Flag to indicate that the file storage device selection has been completed.
StorageDeviceEndInitiated Flag to indicate the file selection end statement has been initiated.
Methods
SnapShot Method to set the PersistentDataManager game content to
current game content.
Initialize Method to initialize file storage option selection and file creation.
WriteData Method to initiate a write of game data.
ReadData Method to initiate the read of game data from persistent
storage media.
PackGameSaveData Method to convert the game content to a serializable format.
UnpackGameSaveData Convert the saved data to the structure format
and return the modified GameContent data
3.6.16
Pocket
Owner: Bill An information holder class. It contains the bounds and

level a given pocket shall be drawn.
88
CRC Card
Responsibilities
Knows
Radius
Does
Defines the radius of balls.
Collaborators
None
Attributes
Radius The radius used for determining ball collisions.
Methods
None
3.6.17
Physics
Owner: Bill A computation class. Computes the collision between

game objects with other game objects and boundary rectangle, adjusts
ball velocity due to friction.
CRC Card
Knows
None
Does
Resolve Ball-Ball collisions
Resolve Ball-Table collisions
Adjust Ball Velocity
Collaborators
None
Attributes
None
3.6. CLASSES
89
Methods
CalculateObjectObjectCollision Resolves the collision of two game objects which are undergoing collision and manipulate the collision
by way of redirection.
CalculateObjectRectangleCollision Takes in a Ball and a Table Bound
which are undergoing collision and manipulating the collision by
way of redirection.
AdjustObjectSpeed Adjusts the speed of a given ball by way of friction.
CalculateAbsoluteVelocityFromComponentVector Computes the direction and magnitude velocity vector from component vector.
CalculateAbsoluteAngleFromRelative Computes an absolute reference angle from a reference angle and an angle relative to it.
CalculateComponentVectorFromVelocity Computes a component vector from direction and magnitude vector
3.6.18
Stick Manager
Owner: Bill Stick Manager handles all aspects of cue stick movement.
It will update stick position and velocity. Stick Manager will also handle
Stick and Cue Ball interaction.
CRC Card
Knows
None
Does
Updates Stick position and velocity data.
Updates Cue Ball velocity data.
Attributes
None
Methods
UpdateStick Function to update the position and velocity vector of the
pool stick as well as the Cue Ball.
3.6.19
Table
Owner: Bill An information holder class. It contains the bounds and

layer identity for the table in question.
90
CRC Card
Responsibility
Knows
X coordinate
Y coordinate
Does
Set table boundaries
Set table boundary for cue ball
Update layer number
Collaborators
None
Attributes
TheGameObject GameObject class instantiation to hold all instantiated game objects.
Bounds The table boundaries
CueBounds The cue ball boundaries
Methods
None
3.6.20
Title Manager
Owner: Bill Manages the splash screen menu for the Hot Sticks game
application. It recognizes the option user has selected from the menu.
CRC Card
Responsibilities
Knows
None
Does
Recognizes the currently selected option from menu.
Selected option is set to true.
3.6. CLASSES
91
Collaborators
None
Attributes
None
Methods
SelectOption Function to enact the option selected by the user.
3.6.21
Warp
Owner: Bill Warps have the ability to teleport balls from one table
level or position to another.
CRC Card
Responsibilities
Knows
WarpID
Does
Moves Ball objects to different table positions.
Collaborators
None
Attributes
WarpID Warp pairing number to indicate which warp a ball will teleport
to upon collision.
Methods
Resolve Public method to resolve all Warp object activity and WarpBall collisions.
DetectCollision Private method to resolve all Warp collision activity.
3.6.22
Warp Manager
Owner: Bill Warp Manager manages the warp objects in the game. It
manages warp movement and collisions between them.
92
CRC Card
Knows
None
Does
Detects collision between warps and balls.
Changes ball position on collision.
Generates random position for balls.
Handles collisions between Warp objects.
Moves Warp objects based on their velocity.
Places new Warp objects into position as directed from user.
Collaborators
None
Attributes
None
Methods
DetectCollision Detects collision of warps with other game objects
Resolve Resolves the collision between warps and game objects
AdjustWarpPosition Private warp method to move warp position from
warp velocity data.
DetectWarpWarpCollision Method to handle Warp collision with other
warp objects as well as table objects.
MoveWarpPosition Warp Manager method to move the last Warp of
the list of warps while positioning the last added Warp object.
3.7
Sequence Charts
For Sequence charts and data flow between object, refer to the SDD
Section 4.
3.8. PERFORMANCE REQUIREMENTS
3.8
93
Performance requirements
The Hot Sticks application performance shall conform to the measures

set forth in this section. All performance requirements are defined as
follows. Any performance issue not listed is not considered critical for
the software product, as the following list is inclusive of all performance
requirements.
1
of a second between Draw
The Hot Sticks system shall not exceed 30
events.
1
of a second between UpThe Hot Sticks system shall not exceed 30
date events.
The Hot Sticks system shall support High Definition Graphics up to
720 lines of vertical resolution and 1280 lines of horizontal resolution.
The Hot Sticks application shall support two-dimensional graphical
game display.
The Hot Sticks system shall support at most two simultaneous players with no more than a 5% decrease of any of the above performance
requirements.
3.9
Design constraints
The Hot Sticks system is designed for implementation on both the Microsoft XBox 360 gaming console and Microsoft Windows operating
systems. This constraint limits the implementation programming language to C#. Also, this limits the software Integrated Development
Environment to Microsoft Visual Studio and Microsoft XNA Game Development. Microsoft Windows Operating System support shall be designed for and limited to Windows Vista and Windows 7 Operating Systems.
3.10
Software system attributes
Hot Sticks system attributes shall be specified for the following categories; Reliability, Availability, Security, Maintainability, and Portability.
3.10.1
Reliability
The Hot Sticks system shall be required to have the ability to complete
an initiated game of pool 95% of the time. Completion of the game shall
be defined as the ability to continue player interaction with the system
until all pool balls have been eliminated from the playing field. Each
individual instance of a game must be able to be completed within two
hours of inception to qualify as a completed game.
94
3.10.2
Availability
The Hot Sticks application shall be capable of initiating a game session

95% of the time such session initiation attempts are made.
3.10.3
Security
The Hot Sticks application shall employ the following methods to promote system and and environment security. All network aspects of
the Hot Sticks system shall conform to XNA Creators Club specifications for network application. The Hot Sticks application shall be peerreviewed by the XNA Creators Club peer-review system before release
to the general public.
3.10.4
Maintainability
The Hot Sticks system shall be delivered in a way that makes it revisable using the development tools specified in the above section, 3.5 Design Constraints. The Hot Sticks system shall make no statement of
warranty respective of the aspect of system maintainability other than
the above statement.
3.10.5
Portability
The Hot Sticks system shall support deployment to the Microsoft XBox
gaming console as well as Microsoft Windows operating systems Windows Vista and Windows 7. All components and code shall be defined
as host-dependent on the above named deployment platforms. The
Hot Sticks system shall make no statement of portability to operating
systems or gaming systems other than those listed directly above.
3.11
3.11.1
Other Requirements
Controller Support
The Hot Sticks system shall provide support for the Microsoft XBox
360 gaming controller. This support is to include the Microsoft XBox
360 gaming console, Microsoft Windows Vista operating system and Microsoft Windows 7 operating system. Only officially licensed Microsoft
corporation controllers, manufactured directly for Microsoft corporation shall be supported. Third-party controllers licensed by, but not
manufactured for, Microsoft corporation shall not be supported. This
includes, but is not limited to, controllers by such manufacturers as
Mad Catz. Controller support shall only include support for functionality expressly listed in the game design.
3.11. OTHER REQUIREMENTS
3.11.2
95
Keyboard Support
The Hot Sticks system shall provide keyboard support. Keyboard support shall be limited to the Microsoft Windows Vista and Microsoft Windows 7 operating systems. There shall be no keyboard support for
the Microsoft XBox 360 gaming console. Keyboard support shall be
provided only for officially licensed Microsoft Corporation Keyboard devices. Officially licensed Microsoft Corporation keyboard devices are
defined as standard English-language keyboard devices manufactured
for or by Microsoft Corporation for sale in the United States.
All device support shall be exclusively for those devices which are
officially licensed by and manufactured for Microsoft Corporation for
sale in the United States.
3.11.3
Language and Localization Support
There shall be no implied Hot Sticks system support for localization for
any country, region or language. The Hot Sticks system shall provide
only English-language support for the United States.
96
Part III
SDD
97
Chapter 1
Introduction
1.1
Purpose
This Software Design Document details design and implementation details for the Hot Sticks game development project. The intended reading
audience of this document are the project stakeholders as defined in
the Software Management Plan document. These stakeholders are the
customer representative and the Dynamic Digital Development team.
1.2
Scope
The scope of this document is to define the design of the Hot Sticks
XBox 360 game application. Design details such as architecture and
module/object definition shall be detailed within this document.
1.3
1.3.1
Definitions
Synonyms
This document uses the term XBox and XBox 360 interchangeably.
Note that in both cases, this should be read as XBox 360.
When discussing matters that are different between the XBox and
PC software, the two are refereed to as the XBox System or the PC
System.
1.3.2
Terms
For common terms, please refer to the SPMP Section 3.
99
100
Chapter 2
References
This document references two specification papers which was developed specifically for Hot Sticks. The first document is the Hot Sticks
Software Project Management Plan, which illustrates the business plan
for proper development, scheduling, milestone identification, organizational structure of active developers and project leaders, as well as developmental tools required to complete the project. This reference conforms to the IEEE SPMP 1016-1998 standard. The second document is
the Hot Sticks Software Requirements Specification, which illustrates
a detailed analysis of what each component of the Hot Sticks project
is to be performed to. This document conforms to the IEEE SRS 8301998 standard. Both document are still in draft form, thus a hard copy
of this document is not frequently available. The head revision of this
document is made readily available online for all developers located on
the Hot Sticks wiki website.
Frequently, the constructs of FDD are used throughout this document. The FDD specification can be located on Nebulons website.
A more detailed document illustrating FDD can be found in the book
A Practical Guide to Feature Driven Development 1st edition written by
Stephan Palmer and John M. Felsing.
101
102
CHAPTER 2. REFERENCES
Chapter 3
Decomposition
Description
3.1
Class Decomposition
For datatypes, constructors, and passed values, consult the API documentation in Annex A.6.
3.1.1
Artist
The Artist class shall have six private variables which it uses for internal manipulation and contains two public methods for execution. In
general, the public method count should not increase past these two.
Additional functionality shall be obtained through extending the two
public methods using private functions.
Attributes
private
content Content manager pass for dynamic loading of skins.
DBase The game object database.
Bucket Primary sprite painting variable to draw elements.
graphics The manager for the graphical device to paint sprites
upon.
util A utility font texture used for testing purposes.
TraceForce Location to position text to show the amount of force
imparted on the cueball.
TraceTime Location to position text to show the total elapsed
time spent in-game.
103
104
CHAPTER 3. DECOMPOSITION DESCRIPTION

StateManager Game State management and reference.
Menu The menu content pipeline.
Colors List of colors to apply to warps when drawing.
Methods
Private
DrawTable/0 Draws all table elements. This includes the table
itself, the pockets that belong to the table, and the currently
visible, wormholes and warps.
DrawBalls/0 Draws the currently visible balls.
DrawStick/0 Draws the stick at the cueballs position, correctly
adjusting to the cues sprite.
DrawGameSettingsScreen/0 Draws the game settings data to
the screen.
DrawPauseScreen/0 Draws the pause screen, using a darken
overlay for previously drawn objects.
DrawTitleScreen/0 Draws the Title Screen menu data.
DrawFileMenuScreen/0 Draws the persistent storage menu data.
DrawClock/1 Draws a utility game timer in the upper right hand
corner of the viewport.
Public
Snapshot/3 Captures the current Game and Menu Content, and
current State, to the class for later use.
Go/1 Draws out all objects contained within the data obtained
through Snapshot. The function acts as a state determinant
for drawing functions.
3.1.2
Ball Manager
Coordinates all moving Ball objects. It Updates position based on ball

position and velocity, detects collisions between all Game Content objects and ensures all objects are within table boundaries. Ball Manager
also monitors Ball object for movement and notes when all balls are
stationary.
Attributes
private
CueBallLocationUpdate Cue Ball position vector used to update
the position from method with public access.
UpdateCueBallPosition Flag to indicate the cue ball position has
been modified and needs to be updated.
3.1. CLASS DECOMPOSITION
105
Methods
protected
DetectCollision/2 The Detect Collision method determines if any
Game Content objects have collided. The method will call the
Physics class static methods to resolve any collisions
public
Resolve/2 The Resolve function is the public function to access
all Ball Manager Methods. First the ball object positions are
updated, then checked for boundary limits. Collision detection method is then called, and the modified Game Content
object is returned.
MoveCueBallPosition/1 Method to effect a change of cue ball position.
3.1.3
Ball
An object which represents pool ball objects. It inherits from the generic
Game Object class and adds traits specific to Ball objects.
Attributes
public
Radius The radius of ball object
IsCue Boolean flag to determine if ball object is cue ball.
WarpingWarpID Integer value which corresponds to Warp object
WarpID. If ball object is currently colliding with Warp object,
this value represents warp ID. If ball object is not colliding
with Warp object, this value will be negative.
BallID The unique ball identification number.
Methods
3.1.4
Game Content
Data holding class which holds all pool game objects. Pool game objects
aggregate within this object.
Attributes
public
Balls List of Ball objects to be maintained.
Tables List of Table objects to be maintained.
106

Pockets List of pockets to be maintained.
Stick List of stick objects to be maintained.
Warps List of Warp objects to be maintained.
IsMoving Response value that is true when balls are still moving
on the table, and false when everything has stopped moving.
GameLevel Current Game board level.
WarpPairCounter The counter for adding Warp objects by pair.
Methods
None
3.1.5
Game Object
Primitive data holder containing the essential elements required for object display.
Attributes
public
Sprite Holder for object texture.
Position The absolute position of the center of the object with the
first value being its x coordinate, the second its y coordinate,
and the third the table level. The special position of -1 for its
level is given for balls that are not on the table any longer.
Type The type of sprite this object is.
Center The centerpoint of the sprite texture with its x value being
first value, and its y value being the second.
Velocity The current velocity of the object where the direction is
the first value, and the magnitude is its second value.
Rotation The rotational value to apply to the texture, specified by
a decimal value between 0 and 1, rotating counter clockwise.
Scale The scale factor to apply to the sprite graphic.
Layer The drawing layer that specifies the order in which the object shall be drawn. The larger the number, the lower priority
it has to be drawn.
Alive The visibility of the object.
Methods
None
3.1.6
107
Pause screen menu for Hot Sticks game application.

Attributes
None
Methods
public
SelectOption/1 Method to enact currently selected menu option.
updateSettings/2 Method to update the Game Content of the
Hot Sticks game application for customized game settings
based on currently selected menu option.
3.1.7
Game State Manager
Finite state machine for the game.

Attributes
public
State Current state of the game application.
PreviousState The previous state of the game application.
PrePauseState State before pause state initiated.
PreSettingState Game State before entering the Game Settings
menu state.
Movement Boolean value for aggregate movement of all objects.
Scratch Boolean value to indicate cue ball scratch.
ScratchLevel Level of play cue ball was on when scratch occurred.
CuePlaced Boolean flag to indicated scratched cue ball has been
replaced to desired location on table.
Pause Flag to initiate change of game pause state.
LoadSave Signal flag to indicate desire to change to file IO state.
Exit Binary flag to indicate desire to exit current state.
Next Binary flag to indicate next operational state.
SetGameAttributes Flag to indicate the desire to enter/exit game
attribute setting state.
Placement Indicator to signal the entry into placement mode.
108
Methods
public
UpdateState/0 Public method to update state of the game based
on GamStateManager attributes.
3.1.8
Game
Primary driver of Hot Sticks system. Every class that requires direct
access to XBox components must be defined here.
Attributes
private
graphics The the display adapter to paint graphics on.
DBase The master internal game pipeline database.
Bucket Primary graphics drawing object.
UserInput User input abstraction instantiation.
StickManager Primary manager object for stick updates.
BallManager Primary manager object for ball updates.
WarpManager Primary manager object for warp updates.
StateManager Primary manager object for game state updates.
GameMenus Collection of game menu management classes.
FileDataManager Manager of file IO for game saves.
pad The previous gamepad input state.
keyboard The previous keyboard input state.
TABLE_SCALE Scaling factor to apply to all table objects.
POCKET_SCALE Scaling factor to apply to all pocket objects.
MAXIMUM_LEVEL The maximum number of allowable tables.
STANDARD_TIME Standard target update time.
TimeFactor Current target update time.
public
BALL_SCALE The scaling factor for Ball objects.
WARP_SCALE The scaling factor for Warp objects.
STICK_SCALE The scaling factor for Stick objects.
StickSprites The string list where the stick sprites are located in
the content pipeline.
109
TableSprites The string list where the table sprites are located in
BallSprites The string list where the ball sprites are located in
PocketSprites The string list where the pocket sprites are located
in the content pipeline.
WarpSprites The string list where the warp sprites are located in
MenuSprites The string list where the menu sprites are located
in the content pipeline.
Methods
private
RackBalls/0 Positions balls in a triangular form following pool
rules.
protected
Initialize/0 Allows the game to perform any initialization it needs
to before starting to run. This is where it can query for
any required services and load any non-graphic related content. Calling base.Initialize will enumerate through any components and initialize them as well.
LoadContent/0 Load Content will be called once per game and
is the place to load all textures and preload positions of the
game content.
UnloadContent/0 UnloadContent will be called once per game
and is the place to unload all content.
Update/1 Allows the game to run logic such as updating the
world, checking for collisions, gathering input, and playing
audio.
Draw/1 This is called when the game should draw itself.
3.1.9
Input
User input abstraction system which obtains input and translates them
into standard input methods used throughout the game.
Attributes
private
PrepareShot Boolean check value when a user is allowed to prepare a shot.
110

Shot Boolean check value to show when a user has taken a shot.
Exit Boolean test value used to show that the user inputted the
exit command.
DeltaAngle A decimal value between -1 and 1 to give in the current angle.
Force The force in which to apply when a shot has been performed.
FreezeLevel Integer value that specifies how to lock out shots to
be taken.
pad The gamepad state the user signaled during the current update.
ppad The gamepad state the user signaled during the last update.
keyboard The keyboard state the user signaled during the current update.
pkeyboard The keyboard state the user signaled during the last
update.
Methods
private
UpDownDirectionalShift/0 Method to return an integer value
based on D-pad game pad up/down status or keyboard U
or D keys.
LeftRightDirectionalShift/0 Private method to indicate left-right
of d-pad or L-R keys of keyboard.
public
SetFreezeLevel/0 Sets the Freeze level of the controller equal to
zero, meaning all input is accepted.
SetFreezeLevel/1 Set the Freeze level of the controller equal to
the passed value. Zero unlocks all controls, One or Greater
Locks shot control.
SignalExit/0 Tests user input for the required button combination to terminate the application.
SignalPrepareShot/0 Tests user input for preparing to take a
shot.
HasShot/0 Tests user input for the required button combination
to preform a shot.
GetForce/0 Returns the force inputted by the user.
Angle/0 Returns a delta value sent from the gamepad left joystick
or keyboard directional buttons.
111
DirectionalMovement/0 Method to return the directional delta

coordinates of the cue ball object.
PlacementDone/0 Public method to indicate if B button was depressed used to indicate cue placement has finished.
LevelChange/0 Method to indicate value of level change.
MenuMovement/0 Method to indicate the value of shift in menu
options.
MenuSelection/0 Indication of current menu selection.
GameSpeed/0 Return value to increase or decrease game target
update time.
UpdatePauseStatus/0 Retrieve Pause indication status change.
3.1.10
Load Save Manager
File I/O menu for Hot Sticks game application.

Attributes
public
State State of load and save operation to be completed.
Methods
public
3.1.11
Menu Content
Information holder class containing all menu management class objects for Hot Sticks game application.
Attributes
public
TitleManagerData TitleManager object for splash screen content
and management.
PauseManagerData PauseManager object for pause screen content and management.
LoadSaveManagerData LodSaveManager object for LoadSave menu
content and management.
SettingsData GameSettingsManager object for altering game play
settings.
112
Methods
public
SetTitleManager/1 Method to initialize instance of TitleManager
attribute.
SetPauseManager/1 Set instance of PauseManager attribute.
SetLoadSaveManager/1 Set instance of LoadSaveManager attribute.
SetGameSettingsManager/1 Set instance of GameSettingsManager attribute.
3.1.12
Menu Manager
MenuManager class manages the display content and options selected

for options menu objects.
Attributes
public
ListOptions List of alphanumeric strings describing current menu
options.
Background Background graphic for screen.
OptionIndicator Texture graphic for menu selection indicator object.
IndicatorScale Scale factor for indicator texture.
Overlay Screen overlay for display of menu content over game
content.
MenuFont Sprite menu font.
CurrentOption The integer value of the currently indicated option of the current menu.
StartPosition he screen position to display string menu options.
Methods
public
SelectOption/1 Public method to enact menu option currently
in selection.
AddOption/1 Adds a passed string to the option list for the menu
3.1.13
Object Manager
Class manages the movements of mobile Game Object objects and resolves all problems which may arise from their movement.
113
Attributes
None
Methods
protected
DetectCollision/1 Virtual method to detect collision of objects
relevant to inherited class objects.
DetectCollision/2 Virtual method to detect collision of objects
relevant to inherited class objects.
BoundaryCheckMovingObjectRectangle/3 BoundaryCheck is a
method to detect if a moving object has passed the rectangular boundary set by a rectangle.
BoundaryCheckStaticObjectRectangle/2 Method to resolve a static
object position to within a specified boundary.
BoundaryRectangle/2 BoundaryRectangle generates a new rectangle based on an existing rectangle and an object Radius.
The BoundaryRectangle is used to create a barrier which is
less in each direction by the radius of an object.
BoundaryCheckObject/6 Method to assure two mobile objects
DO NOT occupy the same physical space at the same time.
public
Resolve/1 Virtual method for public call. Must be overridden in
any inherited class declaration.
Resolve/2 Virtual Method for public call. Must be overridden in
any inherited class declaration.
3.1.14
Pause Manager
Pause screen menu for Hot Sticks game application.

Attributes
None
Methods
public
114
3.1.15
Persistent Data Manager
The persistent data manager acts as proxy between persistent storage

units and the Hot Sticks application. It takes game data, serializes it,
and can parse this data into game-like objects.
Attributes
private
GameContent The data manager copy of all game content.
GameSave The extracted critical save data.
DataSerializer XML data serializer class instance to convert game
data to XML data.
DeviceResult Flag to indicate asynchronous result.
StorageFileName The file name for game data storage.
StorageDevice The storage device for file storage.
StorageDeviceSelectionInitiated Flag to indicate file location selection initiated.
StorageDeviceSelected Flag to indicate that the file storage device selection has been completed.
StorageDeviceEndInitiated Flag to indicate the file selection end
statement has been initiated.
Methods
private
PackGameSaveData/0 Method to convert the game content to a
serializable format.
UnpackGameSaveData/0 Convert the saved data to the structure format and return the modified Game Content data.
public
SnapShot/1 Method to set the Persistent Data Manager game
content to current game content.
Initialize/0 Method to initialize file storage option selection and
file creation.
WriteData/0 Method to initiate a write of game data.
ReadData/1 Method to initiate the read of game data from persistent storage media.
3.1.16
115
Physics
Static operator which performs physical transformations on various

collisions within the Hot Sticks game. It also controls velocities of objects it is aware of.
Attributes
None
Methods
private
CalculateAbsoluteVelocityFromComponentVector/1 Method to
calculate direction and magnitude velocity vector from component vector. Private method used by public Physics methods.
CalculateAbsoluteAngleFromRelative/2 Method to calculate an
absolute reference angle from an absolute reference angle and
an Angle relative to it. Private method used by public Physics
methods.
CalculateComponentVectorFromVelocity/1 Method to compute
a component vector from a direction and magnitude vector.
Private method used by public Physics methods.
public
CalculateObjectObjectCollision/4 Method to resolve collision of
two movable objects in respect to velocities.
AdjustObjectSpeed/2 This method is used to adjust the magnitude of the velocity vector of a moving object.
CalculateObjectRectangleCollision/3 This method alters the velocity of an object which collides with a stationary wall.
VelocityBoundaryResolution/1 Method to verify velocity vector
direction and magnitude within boundary limits. Public method.
VelocityVectorAddition/2 Method to add two velocity vectors comprised of direction and magnitude elements. Private method
used by public Physics methods.
3.1.17
Pocket
Pocket is an object which represents pool pocket objects. It inherits

from the Game Object class and adds traits specific to pocket objects.
116
Attributes
public
radius The radius, in pixels, of the sprite sheet begin used.
Methods
None
3.1.18
Stick Manager
The Stick Manager Class governs the update of stick velocity vector.
Attributes
None
Methods
public
UpdateStick/3 UpdateStick takes the Game Content object passed
to it and modifies the Stick. The Stick is the Game Object
class instantiation which represents the pool cue stick. This
update method also modifies the Velocity vector of the pool
cue ball. This method must only be called when the Ball objects are not in motion.
3.1.19
Table
Table Class inherits from Game Object class. It supplements Game

Object by the addition of a bounding rectangle for table boundary and
a bounding rectangle for cue ball placement on table.
Attributes
public
Bounds A rectangular position boxing the tables furthest bounds
CueBounds A rectangular position boxing where the cue ball can
be placed when a scratch occurs.
Methods
None
3.1.20
117
Title Manager
Splash Screen menu for Hot Sticks game application.

Attributes
public
Logo Major texture to apply as the game logo.
Methods
public
3.1.21
Warp Manager
Warp Manager is a type of Object Manager which manages the Warp

objects of the Hot Sticks game application.
Attributes
Methods
protected
DetectCollision/1 Method to detect collisions of warp objects with
other game content objects.
private
AdjustWarpPosition/1 Private warp method to move warp position from warp velocity data.
DetectWarpWarpCollision/1 Method to handle Warp collision with
other warp objects as well as table objects.
public
Resolve/1 Method to resolve any movement of Warp objects and
collisions.
MoveWarpPosition/2 Warp Manager method to move the last Warp
of the list of warps while positioning the last added Warp object.
3.1.22
Warp
Warp class is a game object which transports colliding ball objects to

other game table levels. Warp is a type of pocket which transports ball
objects to other table objects rather than removing them from all table
objects.
118
Attributes
public
WarpID Indexed value to identify unique or paired warps.
Methods
None
3.2
Concurrent Process Decomposition
Hot Sticks has no build in concurrent processing. All code is executed

sequentially at a variable refresh rate.
3.3
Data Decomposition
This subsection details the data description, structures and methods

for all data not defined in the module decomposition above. The application currently does not define or contain any data which has not
been defined within the module decomposition. The data contained
in the identified modules is defined in the SRS Section 3 in the class
definition subsections.
Chapter 4
Dependency Description
4.1
Intermodule Dependencies
The three defined modules in the Hot Sticks project are Game Object,
Game Input-Output and Game Management. Each of the modules are
interdependent from one another.
4.1.1
Sequence Charts
Warping of objects
The Ball Manager receives the update and sends information to the
Warp Manager to resolve warp ball collision. The Warp Manager then
gets data from the Ball and Warp class through GameContent and finds
the new ball positions according to the warping warp ID that the balls
warp had. This is illustrated in Figure 4.1.
Warp Warp collision
The warp objects collide with each other and bounce off in the same
manner ball objects collide with one another. The WarpManager receives an update and iterates though the warps to detect warp collisions, it then passes the objects to the Physics class to resolve the final
velocities. This is illustrated in Figure 4.2.
Update Cue Stick
Ball Manager receives update and signals the Ball to detect if the ball
is Cue, and updates the stick position to enable user to make a shot.
This is illustrated in Figure 4.3.
119
120
CHAPTER 4. DEPENDENCY DESCRIPTION
Figure 4.1: Warp Object Collision Sequence Diagram
Figure 4.2: Warp Warp Collision Sequence Diagram
4.1. INTERMODULE DEPENDENCIES
121
Figure 4.3: Cue Stick Update Sequence Diagram

Detect Warp collision
Warp Manager receives update and retrieves ball and warp data through
game content to detect when balls pass over warps. This is shown in
Figure 4.4
Game Save
From the Menu screen the user selects the game save option, which
is handled by the TitleManager class. The Title manager then signals
the LoadSaveManager class to call the PersistentDataManager class to
save the current snapshot of the game in the internal file storage. This
is shown in Figure 4.5
Game Load
From the Menu screen the user selects the game load option, which
is handled by the Title Manager class. The Title Manager then signals
the Load Save Manager class to call the Persistent Data Manager class
to load the game from the internal file storage and passes it on to the
Game Content class.
Pause Game
The Game class receives the update and checks with the Input class if
the game is paused or not. The Input class sends back the feed for the
game state. If paused then Game class signals the Game State Manager class that the game has been paused. The Game State Manager
122
Figure 4.4: Detecting Warp Collision Sequence Diagram
Figure 4.5: Game Save Sequence Diagram
4.1. INTERMODULE DEPENDENCIES
123
Figure 4.6: Game Load Sequence Diagram

tells the Pause Manager class to pause the game. This is shown in
Figure 4.7
Warp Table Collision
The warp manager receives the update from game content, which signals it to access the Warp class to get the warp data. It sends the
data to the Physics class to resolve the warp table collision. This is
illustrated in Figure 4.8.
4.1.2
Modules
Game Input-Output Module

The class objects within the module depends on the Game class, which
is the main class to manage the game applications and is contained
in the Game Management module. The elements of class objects from
the Game Management and Game Object modules are required by the
Artist class to display the game.
Game Module
The class objects within the module depends on the Game class, which
is contained in the Game Management Module.
124
Figure 4.7: Game Load Sequence Diagram
Figure 4.8: Warp Table Collision Sequence Diagram
4.2. INTERPROCESS DEPENDENCIES
125
Figure 4.9: Top Level DFD

Game Management
The classes within the Game Object modules are utilized by the Game
Management class. The Artist class contained within the Game InputOutput module is required to display the game objects.
4.2
Interprocess Dependencies
The Hot Sticks game is single process based, hence Interprocess dependencies does not apply to it.
4.3
Data Dependencies
This subsection details the data dependencies for all data not defined
in the Data decomposition. Plans shall be established once the Hot
Sticks project increases in complexity.
4.3.1
Data Flow Diagram
The top level DFD shows the main data flow of the Hot Sticks game
application. It can be found in Figure 4.9
126
Figure 4.10: Ball Management DFD

Ball Management
Ball objects in the game undergo collision, and friction and warping.
When they have collisions with another ball object or table boundary
they are resolved by the Physics class. When a ball passes on top of
a warp it gets transported to a different level. The frictional force is
applied to adjust the ball velocity at every point in the game. When
balls approach directly onto a pocket then the ball is set aside since
the use has scored by putting the ball into the pocket. This is shown
in Figure 4.10
Ball Pocket Collision
Ball objects that approach the pocket are set aside from the playing
table since the user has secured the ball by the action. If the ball is a
cue ball then it is called as Scratch and the cue ball is placed again
on the table and the cue stick is enabled for the player to make the
shot. This is shown in Figure 4.11
Ball Warp Collision
Balls when they go over warps gets transported to a different level. The
warping ID of the warp is found and the ball is sent to the level pointed
out by the warping ID, as shown in Figure 4.12.
4.3. DATA DEPENDENCIES
Figure 4.11: Ball Pocket Collision DFD
Figure 4.12: Ball Warp Collision DFD
127
128
Figure 4.13: Ball Table Collision DFD
Figure 4.14: Ball Ball Collision DFD
Ball Table Collision

Ball objects when they hit the table they bounce back owing to the
angle at which the balls hit the table. The Ball data is sent to the
Physics class along with table boundary from the Table class. Physics
then resolves for the angle of incidence and deflection and gives out the
final ball direction. This is shown in Figure 4.13
Ball Ball Collision
Ball objects collide with one another and bounce back with different
directions and velocities depending on the line of contact between them.
When ball objects collide, their position vectors and velocity vectors are
sent to the physics class to resolve the final velocities and direction of
each ball.
4.3. DATA DEPENDENCIES
129
Figure 4.15: Menu Management DFD

Menu Management
Menu content for the game displays the menu options set for the game.
As the user iterates through different options the selected choice is then
processed. If the user chooses to save a game, a snapshot of the game is
saved in the internal storage of Xbox/Windows PC. If the user chooses
to load a game then he browses through a string of names available and
loads the game by choosing one of them. The use can also pause the
game, and access both load and save option in the paused state. The
use if he wishes to terminate the game chooses the exit option and the
exit process inside Game class handles the exiting of the game. This is
shown in Figure 4.15
130
Chapter 5
Interface Description
5.1
Module Interface
All interfaces are described in the class diagram shown in Figure 3.4,
located in the SRS, Section 3.
5.1.1
Associations
Game Content
Game Content has many assignment attributes for storing data elements of other classes, making it the primary content pipeline for the
Hot Sticks application. Content such as balls and warps can have any
number of elements added to the class, as there is at least one of each
and an infinite quantity within the game. Elements such as stick, table, and pockets have a constraint of having at least one copy, but have
an upper limit.
In addition to this content, the class also must allow access to the
game data for the manager and drawing methods concerning the pool
table and its elements, so it has a single strong connection between
Ball Manager, Stick Manager, and Artist.
Menu Content
Similar to Game Content, Menu Content has data holding attributes for
each visible menu screen. The model chosen for menu interfaces dictates that every menus data is constructed off of a standard datatype
and is extended to attribute to new additions for the menu. Thus, the
menu content has data holdings for each individual screen. As each
screen is its own class, menu content has a strong single association
to each screen class.
131
132
CHAPTER 5. INTERFACE DESCRIPTION
5.1.2
Game
Game has a strong, one to four relation with input as the input class
acts as a middle layer class standardizing input commands. As the
XBox has a limit of only four controllers, the association has a limit of
four elements.
5.1.3
Dependencies
Physics
Physics interfaces with the ball manager in two situations:
Collision: when two balls collide, physics calculates the needed
changes and returns it to
Acceleration: a constant value used to slow moving balls.
5.1.4
Aggregation
Game
The game class is the primary driver for the Hot Sticks application.
Thus, there are several class elements that are classified as a part of
game, rather than associated with game. The Hot Sticks application is
composed of a persistent data manager for saving and loading; warp,
ball, and stick managers for responding to game events, artist for drawing responsive data, and menu content and game content to give access
to the data in the game.
5.2
Process Interface
Interprocess communication shall be achieved by sharing memory through

classes located in a central content pipeline class. This includes every
game object and acts as a proxy for access, and provides functional
encapsulation for obtaining game data. The XNA platform provides
a networking functionality for interconnecting XBox and Windows PC
elements using a standard communication interface. Essential data
elements such as player turn, currently visible level, player shot, and
game history shall be sent over the network interface using the content
pipeline class.
5.2.1
User Interaction
User interaction shall be passed by way of shared memory using the

XBox 360 or Windows PC system as a host machine. The XNA libraries
provide accesses to this data.
5.2. PROCESS INTERFACE
5.2.2
133
Live Update
Updates run using the shared memory located in the content pipeline
class. The Hot Sticks system shall never lock this data to facilitate
real-time updating.
5.2.3
Game Play
Game Play is accomplished by interfacing Hot Sticks with XNA. Thus,

the system uses the XNA libraries to communicate Game Play elements
to the XBox units using shared memory.
134
CHAPTER 5. INTERFACE DESCRIPTION
Chapter 6
Detailed Design
6.1
Module Detailed Design
The detailed design of all Hotsticks game application modules are defined in this subsection of the Software Design Document. Each essential hardware components are depicted in Figure 6.1.
Each Hot Sticks class member belongs to one of three modules:
Game Management, Game I/O, or Game Objects. These separations
are depicted in Figure 6.2.
6.1.1
Game Management Module
This Hotsticks game application module is defined in detail in this subsection. The Module is comprised of the following objects.
Class Objects
BallManager Child class of ObjectManager to manage Ball class objects.
Game The Microsoft XNA game class which is the main class to manage the game application.
GameSettingsManager User-definable game attribute management class
GameStateManager Class to monitor and set game state.
MenuManager MenuManager class manages the display content and
options selected for options menu objects..
LoadSaveManager File I/O menu for Hotsticks game application.
ObjectManager Non-instantiated parent class designed to manage game
objects.
135
136
CHAPTER 6. DETAILED DESIGN
Monitor
XNA Interface
Microsoft LIVE
Gamepad
Windows PC
Xbox
1..4
1..*
1
Keyboard
Figure 6.1: Deployment Diagram
6.1. MODULE DETAILED DESIGN
137
Game Management Module
Game I/O Module
Game Objects
Table
Input
Game State Manager
Warp
StickManager
Ball
Warp Manager
Pocket
Object Manager
GameObject
Ball Manager
Game Content
Physics
enumeration
GameState
Game
Menu Content
Load Save Manager
Menu Manager
Title Manager
Pause Manager
Persitent Data Manager
Figure 6.2: Module Diagram
Artist
138
PauseManager Pause screen menu for Hotsticks game application

PersistentDataManager Class object to manage the file-I/O operations of the Hotsticks game application.
Physics Static class of Physics-calculation methods to resolve physical
movements for other management objects.
StickManager Object to manage the movement and actions of Stick
class objects.
WarpManager Child class of ObjectManager to manage Warp class objects.
TitleManager Splash Screen menu for Hotsticks game application.
6.1.2
Game Input-Output Module
This Hot Sticks game application module is defined in detail in this

subsection.
Class Objects
Artist The Artist class utilizes the Microsoft XNA game objects to display game content objects.
Input Class object which provides abstraction for hardware game interfaces.
6.1.3
Game Objects Module
This Hot Sticks game application module is defined in detail in this

subsection.
Class Objects
Ball Child class of GameObject which defines pool ball objects.
GameContent Class object which contains all game objects for the Hot
Sticks application.
GameObject Parent class which contains data and methods relevant
to all pool game objects.
MenuContent Information holder class containing all menu management class objects for Hotsticks game application.
Pocket Child class of GameObject which defines pool table pocket objects.
Table Child class of GameObject which defines pool Table objects.
6.2. DETAILED CLASS DESIGN
139
Warp Child class of Pocket class which defines objects used to transfer
ball objects.
Data Structure Objects
GameState Enumerated data type which defines the possible states
the Hotsticks game may take.
SpriteType Enumerated data type which defines the possible sprite
types for the Hotsticks game application.
LoadSaveState Defines the possible values for load and save operational states.
SaveFileData Defines all GameContent data which will be saved and
retrieved during game save operations.
6.2
6.2.1
Detailed Class Design

Artist
Snapshot

1
2
3
4
context A r t i s t : : Snapshot ( GameContent content ,

GameStateManager state , MenuContent menu) :
DBase = content ;
StateManager = s t a t e ;
Menu = menu;
Go

1
2
3
context A r t i s t : : Go ( ) :
( ) Elements are layered with the newest item
( ) being placed on top o f the r e s t o f the screen .
4
5
6
7
8
9
10
11
12
13
14
( ) Screens take precedence over game o b j e c t s

i f StateManager . State == GameState . SplashScreen :
DrawTitleScreen ( ) ;
else i f StateManager . State == GameState . GamePaused
DrawTable ( ) ;
DrawBalls ( ) ;
i f ! DBase . IsMoving :
DrawStick ( ) ;
DrawPauseScreen ( ) ;
else i f StateManager . State == GameState . FileOperations
140
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
DrawTable ( ) ;
DrawBalls ( ) ;
DrawFileMenuScreen ( ) ;
else i f StateManager . State == GameState . ExitGame
DrawExitConfirmationScreen ( ) ;
else i f StateManager . State == GameState . ShotPrep
DrawTable ( ) ;
DrawBalls ( ) ;
DrawStick ( ) ;
else i f StateManager . State == GameState . CuePlacement
DrawTable ( ) ;
DrawBalls ( ) ;
else i f StateManager . State == GameState . BallMovement
DrawTable ( ) ;
DrawBalls ( ) ;
else
( ) Do Nothing
32
33
DrawClock ( gameTime ) ;
6.2.2
Draw Balls

1
2
3
4
5
context A r t i s t : : DrawBalls ( ) :
Bucket . Begin ( ) ;
foreach Ball x in DBase . Balls
Bucket . Draw ( x . Sprite , x . P o s i t i o n ) ;
Bucket .End ( ) ;
Draw Table

1
2
3
4
5
context A r t i s t : : DrawTable ( ) :
foreach Table x in DBase . Tables
Bucket .End ( ) ;
Draw Stick

1
2
3
context A r t i s t : : DrawStick ( ) :
ballRadius = new Float ;

4
5
6
7
8
141
foreach GameObject x in DBase . Sticks

ballRadius = 0;
foreach Ball y in DBase . Balls
i f y . IsCue
ballRadius = y . Radius ;
9
10
11
12
13
14
15
positionDelta = new Float ;

( ) Calculate radius o f cue s p r i t e
positionDelta . Y = Math. Sqrt ( ballRadius ballRadius +
x . Sprite . Height/2 x . Scale ) ;
( ) Calculate the angle from the top l e f t corner o f
the s t i c k s p o s i t i o n
positionDelta .X = x . V e l o c i t y .X + Math. PI
Math. ArcCos ( ballRadius/positionDelta . Y ) ;
positionDelta =
Physics . VelocityBoundaryResolution ( positionDelta ) ;
16
17
18
19
20
( ) O f f s e t p o s i t i o n based o f f o f delta
s t i c k P o s i t i o n = new Float ;
s t i c k P o s i t i o n . Y = Math. Sin ( P o s i t i o n D e l t a V e l o c i t y .X)
PositionDeltaVelocity .Y;
s t i c k P o s i t i o n .X = a . P o s i t i o n . Y + 25.0 f
Math. Cos ( P o s i t i o n D e l t a V e l o c i t y .X)
PositionDeltaVelocity .Y;
21
22
23
x . Rotation = x . V e l o c i t y .X + Math. PI / 2 f ;
24
25
Bucket .End ( ) ;
Draw Clock

1
2
3
4
5
6
7
context A r t i s t : : DrawClock ( ) :
( ) u t i l i t y c l o c k
String s t r = String . Concat (
gameTime . TotalGameTime . Minutes . ToString ( ) , " : " ,
gameTime . TotalGameTime . Seconds . ToString ( ) , " : " ,
gameTime . TotalGameTime . Milliseconds . ToString ( ) ) ;
8
9
10
11
( ) Get s i z e o f s t r i n g i n p i x e l s t o r i g h t a l i g n t e x t
t e x t S i z e = u t i l . MeasureString ( s t r ) . Width ;
TraceTime = graphics . GraphicsDevice . Viewport . Width
t e x t S i z e .X;
142
12
13
Bucket . Draw ( str , TraceTime ) ;

Bucket .End ( ) ;
Draw Pause Screen

1
2
3
4
5
context A r t i s t : : DrawPauseScreen ( ) :
p o s i t i o n = new {
s t a r t = new Float { x , y } ;
end = new Float { x , y } ;
};
6
7
10
p o s i t i o n . s t a r t .X = Screen . Width / 2
Menu. PauseManagerData . Background . Width / 2;
p o s i t i o n . end .X = Screen . Width / 2 +
Menu. PauseManagerData . Background . Width / 2;
p o s i t i o n . s t a r t . Y = Screen . Height / 2
Menu. PauseManagerData . Background . Height / 2;
p o s i t i o n . end . Y = Screen . Height / 2 +
Menu. PauseManagerData . Background . Height / 2;
11
12
13
14
15
16
17
18
19
20
21
22
Bucket . Draw (Menu. PauseManagerData . Overlay , p o s i t i o n ) ;
for i from 0:Menu. PauseManagerData . ListOptions . Count
shift =
Menu. PauseManagerData . ListOptions [ i ] . StringHeight ( ) ;
i f i == Menu. PauseManagerData . CurrentOption
Bucket . Draw ( DBase . Balls [ " e i g h t " ] ,
{ p o s i t i o n . s t a r t .X +
Menu. PauseManagerData . S t a r t P o s i t i o n .X
Menu. PauseManagerData . OptionIndicator . Width
Menu. PauseManagerData . Scale ,
position . start .Y +
Menu. PauseManagerData . S t a r t P o s i t i o n . Y + s h i f t
i,
Menu. PauseManagerData . OptionIndicator . Height
Menu. PauseManagerData . Scale
}) ) ;
23
24
25
Bucket . Draw (Menu. PauseManagerData . ListOptions [ i ] ,

{ Menu. PauseManagerData . S t a r t P o s i t i o n .X +
p o s i t i o n . s t a r t . X,

26
27
143
Menu. PauseManagerData . S t a r t P o s i t i o n . Y +
p o s i t i o n . s t a r t . Y+ s h i f t i
}) ;
28
29
Bucket .End ( ) ;
Draw File Menu Screen

1
2
3
4
5
6
context A r t i s t : : DrawFileMenuScreen ( ) :
};
Menu. LoadSaveManagerData . Background . Width / 2;
Menu. LoadSaveManagerData . Background . Width / 2;
Menu. LoadSaveManagerData . Background . Height / 2;
Menu. LoadSaveManagerData . Background . Height / 2;
10
11
12
13
14
15
16
17
18
19
20
21
Bucket . Draw (Menu. LoadSaveManagerData . Overlay , p o s i t i o n ) ;
for i from 0:Menu. LoadSaveManagerData . ListOptions . Count
shift =
Menu. LoadSaveManagerData . ListOptions [ i ] . StringHeight ( ) ;
i f i == Menu. LoadSaveManagerData . CurrentOption
Menu. LoadSaveManagerData . S t a r t P o s i t i o n .X
Menu. LoadSaveManagerData . S t a r t P o s i t i o n . Y +
shift i ,
Menu. LoadSaveManagerData . OptionIndicator . Width
DBase . Balls [ " e i g h t " ] . Scale ,
Menu. LoadSaveManagerData . OptionIndicator . Height
DBase . Balls [ " e i g h t " ] . Scale
}) ) ;
22
23
Bucket . Draw (Menu. LoadSaveManagerData . ListOptions [ i ] ,
144
24
25
26

{ Menu. LoadSaveManagerData . S t a r t P o s i t i o n .X +
Menu. LoadSaveManagerData . S t a r t P o s i t i o n . Y +
p o s i t i o n . s t a r t . Y+ s h i f t i
}) ;
27
28
Bucket .End ( ) ;
Draw Title Screen

1
2
3
4
5
6
context A r t i s t : : DrawFileMenuScreen ( ) :
};
Menu. TitleManagerData . Background . Width / 2;
Menu. TitleManagerData . Background . Width / 2;
Menu. TitleManagerData . Background . Height / 2;
Menu. TitleManagerData . Background . Height / 2;
10
11
12
13
14
15
16
17
18
19
20
21
22
Bucket . Draw (Menu. TitleManagerData . Overlay , p o s i t i o n ) ;
for i from 0:Menu. TitleManagerData . ListOptions . Count
shift =
Menu. TitleManagerData . ListOptions [ i ] . StringHeight ( ) ;
i f i == Menu. TitleManagerData . CurrentOption
Menu. TitleManagerData . S t a r t P o s i t i o n .X
DBase . Balls [ " e i g h t " ] . Sprite . Width
DBase . Balls [ " e i g h t " ] . Scale ,
Menu. TitleManagerData . S t a r t P o s i t i o n . Y + s h i f t
i,
Menu. TileManagerData . OptionIndicator . Width
Menu. TileManagerData . Scale ,
Menu. TileManagerData . OptionIndicator . Height
Menu. TileManagerData . Scale
}) ;

23
24
25
26
145
Bucket . Draw (Menu. TitleManagerData . ListOptions [ i ] ,

{ Menu. TitleManagerData . S t a r t P o s i t i o n .X +
Menu. TitleManagerData . S t a r t P o s i t i o n . Y +
position . start .Y + s h i f t i
}) ;
27
28
Bucket .End ( ) ;
6.2.3
Ball
6.2.4
BallManager
Resolve

1
context BallManager : : Resolve ( GameContent content ,

GameStateManager stateManager ) : GameContent
2
3
4
5
6
7
8
9
10
Float movement = 0;
Rectangle tableRectangle = new Rectangle ;
Rectangle cueRectangle = new Rectangle ;
Boolean notWarp = true ;
d e l t a P o s i t i o n = new { 0 , 0 , 0 } ;
Float distance = 0;
Integer methodCounter = 0;
Float f r a c t i o n a l = 1 / t h i s . NumberIterations ;
11
12
13
14
15
16
17
18
19
20
while methodCounter < t h i s .Number I t e r a t i o n s :

foreach b a l l in content . b a l l s
i f ( b a l l . V e l o c i t y .Mag > 0) or
( stateManager . State ( ! BallMovement ) :
b a l l . P o s i t i o n .X += Math. Sin ( b a l l . V e l o c i t y . Dir )
b a l l . V e l o c i t y .Mag f r a c t i o n a l ;
b a l l . P o s i t i o n . Y = Cos ( b a l l . V e l o c i t y . Dir )
b a l l . V e l o c i t y .Mag f r a c t i o n a l ;
tableRectangle = BallManager . BoundaryRectangle
( content . Tables [ content . Level ] . Bounds,
b a l l . Radius ) ;
ball . Position =
BallManager . BoundaryCheckMovingObjectRectangle
( b a l l . Position , b a l l . Velocity ,
tableRectangle ) ;
b a l l . V e l o c i t y = Physics . AdjustObjectSpeed (
b a l l . Velocity , f r a c t i o n a l ) ;
movement += b a l l . V e l o c i t y .Mag;
146
21
22
23
i f ( b a l l . IsCue )
content . Stick [ 0 ] . P o s i t i o n = b a l l . P o s i t i o n ;
24
25
26
27
28
29
30
31
32
33
i f b a l l . WarpingWarpID >= 0:
notWarp = true ;
foreach warp in content . Warps
i f warp . WarpID == b a l l . WarpingID :
d e l t a P o s i t i o n .X = warp . P o s i t i o n .X
b a l l . P o s i t i o n .X;
d e l t a P o s i t i o n . Y = warp . P o s i t i o n . Y
ball . Position .Y;
distance = Math. Sqrt ( d e l t a P o s i t i o n .X ^ 2 +
deltaPosition .Y ^ 2 ) ;
i f ( warp . Radius + b a l l . Radius distance >=
0.1 )
notWarp = f a l s e ;
34
35
36
i f notWarp :
b a l l . WarpingWarpID = 1;
37
38
39
40
41
42
43
44
45
46
i f movement < 0.001:

content . IsMoving = f l a s e ;
stateManager . Movement = f a l s e ;
foreach b a l l in content . b a l l s
i f ( ball . Position .Z < 0 )
b a l l . A l i v e = true ;
ball . Position =
content . Tables [ content . Level ] . P o s i t i o n . Center ;
content . Stick [ 0 ] . P o s i t i o n = b a l l . P o s i t i o n ;
47
48
49
50
51
52
53
54
55
56
57
58
i f ( t h i s . UpdateCueBallPosition )
b a l l . P o s t i i o n .X +=
t h i s . CueBallLocationUpdate .X;
b a l l . P o s i t i o n . Y +=
t h i s . CueBallLocationUpdate . Y ;
b a l l . P o s i t i o n . Z = t h i . CueBallLocationUpdate . Z ;
cueRectangle = BallManager . BoundaryRectangle (
content . Tables [ content . Level ] . CueBounds,
ball . Position =
BallManager . BoundaryCheckStaticObjectRectangle (
b a l l . Position ,
cueRecctangle ) ;
Me. UpdateCueBallPosition = f a l s e ;
147
59
60
61
62
else
content . IsMoving = true ;
stateManager . Movement = true ;
63
64
65
66
67
content = BallManager . D e t e c t C o l l i s i o n s (
content ,
stateManager ) ;
methodCounter += 1;
68
69
return content ;
MoveCueBallPosition

1
2
3
4
context BallManager : : MoveCueBallPosition ( Vector3

newPosition ) :
UpdateCueBallPosition = true ;
CueBallLocationUpdate = newPosition ;
return ;
DetectCollison

1
2
3
4
5
6
context BallManager : : D e t e c t C o l l i s i o n ( GameContent

content , GameStateManager stateManager ) : GameContent
objectSeparation = new { 0 , 0 } ;
f l o a t distance = 0;
Rectangle tableRectangle = new Rectangle ;
returnVector2 = new { X=0 ,Y= 0 } ;
returnVector4 = new { X=0 ,Y=0 ,Z=0 ,W= 0 } ;
7
8
9
10
11
12
13
14
15
16
for ball1 from 0: content . Balls . Count1

for ball2 from ball1 +1: content . Balls . Count
i f ( ball1 . P o s i t i o n . Z == ball2 . P o s i t i o n . Z AND
ball1 . P o s i t i o n . Z >= 0 )
objectSeparation .X = ball1 .X ball2 .X;
objectSeparation . Y = ball1 . Y ball2 . Y ;
distance = Math. Sqrt ( objectSeparation .X ^ 2 +
objectSeparation . Y ^ 2 ) ;
i f ( ball1 . Radius + ball2 . Radius distance >
0.1 )
returnVector4 =
ObjectManager . BoundaryCheckObject (
ball1 . Position ,
148
17
18
19
20
21
22
23
24
25

ball1 . Velocity ,
ball1 . Radius ,
ball2 . Position ,
ball2 . Velocity ,
ball2 . Radius ) ;
ball1 .X = returnVector4 .X;
ball1 . Y = returnVector4 . Y ;
ball2 .X = returnVector4 . Z ;
ball2 . Y = returnVector4 .W;
26
27
28
29
30
31
32
33
34
35
returnVector4 =
Physics . CalculateObjectObjectCollision (
ball1 . Position ,
ball1 . Velocity ,
ball2 . Position ,
ball2 . V e l o c i t y ) ;
ball1 . Dir = returnVector4 .X;
ball1 .Mag = returnVector4 . Y ;
ball2 . Dir = returnVector4 . Z ;
ball2 .Mag = returnVector4 .W;
36
37
38
39
40
41
42
43
44
45
46
47
foreach b a l l in content . Balls

tableRectangle = BoundaryRectangle (
content . Tables [ 0 ] . Bounds,
i f tableRectangle . Contains ( b a l l . P o s i t i o n ) :
else
returnVector2 =
Physics . CalculateObjectRectangleCollision (
b a l l . Position ,
b a l l . Velocity ,
tableRectangle ) ;
b a l l . V e l o c i t y = returnVector2 ;
48
49
50
51
52
53
54
55
56
57

foreach pocket in content . Pockets
i f b a l l . P o s i t i o n . Z = pocket . P o s i t i o n . Z
objectSeparation .X = b a l l . P o s i t i o n .X
pocket . P o s i t i o n .X + pocket . Center .X;
objectSeparation . Y = b a l l . P o s i t i o n . Y
pocket . P o s i t i o n . Y pocket . Center . Y ;
distance = SquareRoot ( objectSeparation .X ^ 2 +
objectSeparation . Y ^ 2 ) ;
i f distance < ( b a l l . Radius + pocket . Radius ) :
ball . alive = false ;
b a l l . V e l o c i t y = 0;
149
stateManager . Scratch = true ;
stateManager . ScratchLevel = b a l l . P o s i t i o n . Z ;
58
59
60
61
b a l l . P o s i t i o n . Z = 1;
62
63
64
return content ;
6.2.5
GameContent
AddBall

1
2
context GameContent : : AddBall ( Ball newBall ) :

Balls . Add ( newBall ) ;
AddPocket

1
2
context GameContent : : AddPocket ( Pocket newPocket ) :

Pockets . Add ( newPocket ) ;
AddTable

1
2
context GameContent : : AddTable ( Table newTable ) :

Tables . Add ( newTable ) ;
AddStick

1
2
context GameContent : : AddStick ( Stick newStick ) :

Stick . Add ( newStick ) ;
AddWarp

1
2
context GameContent : : AddWarp ( Warp newWarp ) :

Warps . Add ( newWarp ) ;
150
6.2.6
GameObject
6.2.7
GameStateManager
UpdateState

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
context GameStateManager : : UpdateState ( ) :

i f State == ShotPrep :
i f Movement
previousState = s t a t e ;
s t a t e = BallMovement ;
else i f pause :
prePauseState = s t a t e ;
s t a t e = gamePaused
else i f s t a t e == ballMovement :
i f not movement
i f scratch
s t a t e = cuePlacement ;
scratch = f a l s e ;
else
s t a t e = shotPrep ;
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
i f pause
s t a t e = gamePaused ;
pause = f a l s e ;
else i f s t a t e == cuePlacement
i f cueplaced
cuePlaced = f a l s e ;
i f paused
s t a t e = gamePaused ;
pause = f a l s e ;
else i f s t a t e == gamePaused
i f pause
s t a t e = prePauseState ;
pause = f a l s e ;
else i f loadSave
prevoiusState = s t a t e ;
state = fileOperations ;
loadSave = f a l s e ;
else i f setGameAttributes

41
42
43
44
45
46
47
48
preSettingsState = s t a t e ;
s t a t e = gameSettings ;
setGameAttributes = f a l s e ;
else i f e x i t
s t a t e = splashScreen ;
exit = false ;
49
50
else i f s t a t e == f i l e O p e r a t i o n s
51
52
53
54
55
if exit
s t a t e = previousState ;
previousState = f i l e O p e r a t i o n s ;
exit = false ;
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
else i f s t a t e == splashScreen
i f next
next = f a l s e ;
else i f loadSave
state = fileOperations ;
loadSave = f a l s e ;
else i f setGameAttributes
preSettingsState = s t a t e ;
s t a t e = gameSettings ;
setGameAttributes = f a l s e ;
else i f e x i t
s t a t e = exitGame ;
exit = false ;
else i f s t a t e == exitGame
76
77
78
79
80
81
82
83
84
85
86
else i f s t a t e == gameSettings
if exit
s t a t e = preSettingsState ;
exit = false ;
else i f placement
s t a t e = warpPlacement ;
placement = f a l s e ;
else i f s t a t e == warpPlacement
if exit
151
152

s t a t e = previousState ;
exit = false ;
87
88
89
90
else
6.2.8
Game
Initialize

1
2
context Game: : I n i t i a l i z e ( ) :
( ) No added data
LoadContent

1
2
context Game: : LoadContent ( ) :

( ) Load a l l s p r i t e s h e e t s and content
UnloadContent

1
2
context Game: : UnloadContent ( ) :

( ) No added data
Update

1
2
3
context Game: : Update ( ) :

UserInput = Input . PlayerOne ;
GameLevel = ( GameLevel + UserInput . LevelChange ) %
MAXIMUM_LEVEL;
4
5
6
i f GameLevel < 0:
GameLevel = MAXIMUM_LEVEL 1;
7
8
Game. Speed = UserInput . GameSpeed ;
9
10
11
12
13
14
15
i f StateManager . State == State . BallMovement :

BallManager . Resolve ( ) ;
WarpManager . Resolve ( ) ;
i f UserInput . UpdatePauseState :
StateManager . Pause = true ;
else i f StateManager . State == State . ShotPrep :

16
17
18
19
20
21
22
23
UserInput . SetFreezeLevel ( ) ;
StickManager . UpdateStick ( UserInput . Angle ( ) ) ;
i f UserInput . HasShot :
UserInput . SetFreezeLevel ( 1 ) ;
StickManager . UpdateStick (
UserInput . Angle ( ) ,
UserInput . GetForce ( ) ;
);
24
25
26
27
28
BallManager . Resolve ( ) ;
WarpManager . Resolve ( ) ;
i f UserInput . UpdatePauseState :
29
30
31
32
33
34
35
36
else i f StateManager . State = State . CuePlacement :

BallManager . MoveCueBallPosition (
{ UserInput . DirectionalMovement ( ) ,
StateManager . ScratchLevel }
);
i f UserInput . UpdatePauseStatus :
37
38
39
40
41
42
43
else i f StateManager . State == State . SplashScreen :

TitleManagerData . CurrentOption +=
UserInput .MenuMovement ( ) ;
i f TitleManagerData . CurrentOption < 0:
TitleManagerData . CurrentOption = 0;
else i f TitleManagerData . CurrentOption >
TitleManagerData . ListOptions . Count :
TitleManagerDta . CurrentOption =
TitleManagerData . ListOptions . Count ;
44
45
46
i f UserInput . MenuSelection :
TitleManagerData . SelectOption ( StateManager ) ;
47
48
49
50
51
52
53
54
55
else i f StateManager . State == State . FileOperations :

FileDataManager . I n i t i a l i z e ( ) ;
LoadSaveManagerData . CurrentOption +=
i f LoadSaveManagerData . CurrentOption < 0:
LoadSaveManagerData . CurrentOption = 0;
else i f LoadSaveManagerData . CurrentOption >
LoadSaveManagerData . ListOptions . Count :
LoadSaveManagerData . CurrentOption =
LoadSaveManagerData . ListOptions . Count ;
153
154
56
57
58
59
60
61
62
63
64

i f UserInput . MenuSelection ( ) :
LoadSaveManagerData . SelectOption ( StateManager ) ;
i f LoadSaveManagerData . State == LoadSaveState . Load :
Game = FileDataManager . ReadData (Me) ;
LoadSaveManagerData . State = LoadSaveState . I d l e ;
else i f LoadSaveManagerData . State ==
LoadSaveState . Save :
FileDataManager . SnapShot ( ) ;
FileDataManager . WriteData ( ) ;
LoadSaveManagerData . State = LoadSaveState . I d l e ;
65
66
67
68
69
70
71
else i f StateManager . State == State . GamePaused :

PauseManagerData . CurrentOption +=
i f PauseManagerData . CurrentOption < 0:
PauseManagerData . CurrentOption = 0;
else i f PauseManagerData . CurrentOption >
PauseManagerData . ListOptions . Count :
PauseManagerData . CurrentOption =
PauseManagerData . ListOptions . Count ;
72
73
74
i f UserInput . MenuSelection ( ) :
PauseManagerData . SelectOption ( StateManager ) ;
75
76
77
78
79
80
81
else i f StateManager . State == State . GameSettings :

SettingsData . CurrentOption +=
i f SettingsData . CurrentOption < 0:
SettingsData . CurrentOption = 0;
else i f SettingsData . CurrentOptions >
SettingsData . ListOptions . Count
SettingsData . CurrentOption =
SettingsData . L i s t o p t i o n s . Count ;
82
83
84
85
i f ( UserInput . MenuSelection ( ) :
SettingsData . SelectOption ( StateManager ) ;
SettingsData . UpdateStettings (Me) ;
86
87
88
else i f StateManager . State == State . ExitGame :

Me. Exit ( 0 ) ;
89
90
91
92
93
94
else i f StateManager . State == State >WarpPlacement :

WarpManager . MoveWarpPosition (
{ UserInput . DirectionalMovement ( ) ,
GameLevel } ) ;
i f UserInput . PlacementDone
155
StateManager . Exit = true ;

while WarpPairCounter > 0
Warps . RemoveAt ( Warps . Count1) ;
WarpPairCounter = 1;
95
96
97
98
99
100
101
102
i f UserInput . MenuSelection :
i f WarpPairCounter == 0:
StateManager . Exit == true ;
103
104
105
106
StateManager . UpdateState ( ) ;
( ) Store f o r next c y c l e
UserInput = Input . PlayerOne ;
Draw

1
2
3
context Game: : Draw ( ) :

A r t i s t . Snapshot ( DBase ) ;
A r t i s t .Go ( ) ;
6.2.9
Input
SetFreezeLevel

1
2
context Input : : SetFreezeLevel ( i n t a ) :

pre : a<=0;
3
4
FreezeLevel = 0;
5
6
7
context Input : : SetFreezeLevel ( i n t a ) :

pre : a>0;
8
9
FreezeLevel = a ;
HasShot

1
2
context Input : : HasShot ( ) : Boolean

return Shot ;
156
Angle

1
2
context Input : : Angle ( ) : Float

return DeltaAngle ;
getForce

1
2
context Input : : GetForce ( ) : Float

return Force ;
PlacementDone

1
2
context Input : : PlacementDone ( ) : Boolean

return Placed ;
SignalPrepareShot

1
2
context Input : : SignalPrepareShot ( ) : Boolean

return PrepareShot ;
DirectionalShift

1
2
context Input : : D i r e c t i o n a l S h i f t ( ) : Float

return DeltaView ;
DirectionalMovement

1
2
context Input : : DirectionalMovement ( ) : Vector

return DeltaMovement ;
6.2.10
LoadSaveManager
SelectOption
157

1
context LoadSaveManager : : SelectOption ( GameStateManager

stateManager ) :
2
3
4
5
6
7
8
9
10
i f currentOption == 0:
s t a t e = load ;
else i f currentOption == 1:
s t a t e = save ;
stateManager . e x i t = true ;
else
currentOption = 0;
6.2.11
MenuContent
SetTitleManager

1
2
context MenuContent : : SetTitleManager ( TitleManager t i t l e ) :

TitleManagerData = t i t l e ;
SetPauseManager

1
2
context MenuContent : : SetPauseManager ( PauseManager pause ) :

PauseManagerData = pause ;
6.2.12
SetLoadSaveManager

1
context MenuContent : : SetLoadSaveManager ( LoadSaveManager

fileio ) :
LoadSaveManagerData = f i l e i o ;
SetGameSettingsManager

1
context
MenuContent : : SetGameSettingsManager ( GameSettingsManager
settings ) :
SettingsData = s e t t i n g s ;

158
6.2.13
MenuManager
AddOption

1
2
context MenuManager : : AddOption ( s t r i n g option ) : Null

ListOptions . add ( option ) ;
6.2.14
ObjectManager
Resolve

1
context ObjectManager : : Resolve ( GameContent content ,

GameStateManager stateManager ) : GameContent
2
3
return content ;
DetectCollision

1
context ObjectManager : : D e t e c t C o l l i s i o n ( GameContent

content , GameStateManager stateManager ) : GameContent
2
3
return content ;
BoundaryCheckMovingObjectRectangle

1
context
ObjectManager : : BoundaryCheckMovingObjectRectangle ( Vector
position , Vector v e l o c i t y , Rectangle boundary ) : Vector
2
3
4
5
6
7
8
9
10
d e l t a = new { X=0 ,Y= 0 } ;

i f ( boundary . Contains ( p o s i t i o n ) )
else
i f ( boundary . Top > p o s i t i o n . Y ) :
d e l t a . Y = boundary . Top 0.0001 p o s i t i o n . Y ;
p o s i t i o n . Y = boundary . Top 0.0001;
d e l t a .X = d e l t a . Y / Cos ( v e l o c i t y . Dir )
Sin ( v e l o c i t y . Dir ) ;
p o s i t i o n .X = d e l t a .X;
11
12
13
14
else i f ( boundary . bottom < p o s i t i o n . Y ) :

d e l t a . Y = p o s i t i o n . Y boundary . Bottom + 0.0001;
p o s i t i o n . Y = boundary . Bottom + 0.0001;

15
16
159
d e l t a .X = d e l t a . Y / Math. Cos ( v e l o c i t y . Dir )

Math. Sin ( v e l o c i t y . Dir ) ;
p o s i t i o n .X += d e l t a .X;
17
18
19
20
21
22
else i f ( boundary . Right < p o s i t i o n .X) :

d e l t a .X = p o s i t i o n .X boundary . Right + 0.0001;
p o s i t i o n .X = boundary . Right + 0.0001;
d e l t a . Y = d e l t a .X / Math. Sin ( v e l o c i t y . Dir )
Math. Cos ( v e l o c i t y . Dir ) ;
p o s i t i o n . Y = d e l t a . Y ;
23
24
25
26
27
28
else
d e l t a .X = Boundary . L e f t 0.0001 p o s i t i o n .X
p o s i t i o n .X = boundary . L e f t 0.001;
d e l t a . Y = d e l t a .X / Math. Sin ( v e l o c i t y . Dir )
Math. Cos ( v e l o c i t y . Dir ) ;
p o s i t i o n . Y += d e l t a . Y ;
29
30
return p o s i t i o n ;
BoundaryCheckObject

1
context ObjectManager : : BoundaryCheckObject ( Vector3

position1 , Vector2 v e l o c i t y 1 , f l o a t radius1 , Vector3
position2 , Vector2 v e l o c i t y 2 , f l o a t radius2 ) : Vector4
2
3
4
5
6
7
8
r e s u l t s = new { X=0 ,Y=0 ,Z=0 ,W= 0 } ;

f l o a t slomo = 0.01;
f l o a t magnitude = 0;
f l o a t distance = Math. Sqrt ( ( position1 .X position2 .X)
^ 2 + ( position1 . Y position2 . Y ) ^ 2) ;
f l o a t previous = distance ;
magnitude = v e l o c i t y 1 .Mag + v e l o c i t y 2 .Mag;
9
10
11
i f ( magnitude < 0.1 ) :

v e l o c i t y 1 .Mag = 1;
12
13
14
15
16
while ( distance < previous ) :

position1 .X = Math. Sin ( v e l o c i t y 1 . Dir )
v e l o c i t y 1 .Mag slomo ;
position1 . Y += Math. Cos ( v e l o c i t y 1 . Dir )
position2 .X = Math. Sin ( v e l o c i t y 2 . Dir )
160
17
18
19
20
21

position2 . Y += Math. Cos ( v e l o c i t y 2 . Dir )
previous = distance ;
distance = Math. Sqrt ( ( position1 .X position2 .X) ^ 2
+ ( position1 . Y position2 . Y ) ^ 2) ;
i f ( distance < previous ) :
v e l o c i t y 1 . Dir += Pi ;
22
23
24
25
26
r e s u l t s .X
results .Y
results .Z
r e s u l t s .W
=
=
=
=
position1 .X;
position1 . Y ;
position2 .X;
position2 . Y ;
27
28
return r e s u l t s ;
BoundaryCheckStaticObjectRectangle

1
context
ObjectManager : : BoundaryCheckStaticObjectRectangle
( Vector3 position , Rectangle perimiter ) : Vector3
2
3
4
5
i f ( ! perimiter . Contains ( p o s i t i o n ) )
p o s i t i o n .X = Math. Clamp ( p o s i t i o n . X, perimiter ) ;
p o s i t i o n . Y = Math. Clamp ( p o s i t i o n . X, perimiter ) ;
6
7
return p o s i t i o n ;
BoundaryRectangle

1
context ObjectManager : : BoundaryRectangle ( Rectangle

perimiter , f l o a t radius ) : Rectangle
2
3
4
5
6
7
8
9
10
11
f l o a t X;
float Y
f l o a t height
f l o a t width ;
Rectangle boundary ;
boundary .X = perimiter .X + radius ;
boundary . Y = perimiter . Y + radius ;
boundary . Height = perimiter . Width 2radius ;
boundary . Height = preimiter . Height 2radius ;
12
13
return boundary ;
6.2.15
161
PauseManager
SelectOption

1
context PauseManager : : SelectOption ( GameStateManager

stateManager ) :
2
3
4
5
6
7
8
9
10
11
stateManager . pause = true ;
stateManager . loadsave = true ;
stateManager . setgameattributes = true ;
else
12
13
currentoption = 0;
6.2.16
PersistentDataManager
Snapshot

1
context PersistentDataManager : : Snapshot ( GameContent

content ) :
gameContent = content ;
Initialize

1
context PersistentDataManager : : I n i t i a l i z e ( ) :
2
3
5
6
7
8
9
10
11
12
i f ( storageDevice ! = Null ) and ( storageDevice Selected

== f a l s e ) :
stoarageContainer f i l e c o n t a i n e r =
storageDevice . OpenContainer ;
s t r i n g fileName = path . combine ( f i l e c o n t a i n t e r ) ;
i f ! F i l e . Exists ( fileName ) :
n e w f i l e = F i l e . create ( fileName ) ;
f i l e c o n t a i n e r . dispose ;
storageDeviceSelected = true ;
else
i f ! storageDeviceSelectionInitiated :
r e s u l t = Guide . BeginShowStorageDeviceSelector ;
162
13

s t o r a g e D e v i c e S e l e c t i o n I n i t i a t e d = true ;
14
15
16
17
else i f r e s u l t . iscompleted &&

s t o r a g e D e v i c e S e l e c t i o n I n i t i a t e d == f a l s e :
storageDevice = Guide . EndShowStorageDeviceSelector ;
deviceEnd = true ;
WriteData

1
2
3
4
5
6
7
8
context PersistentDataManager : : WriteData ( ) :

PackGameSaveData ;
device = StorageDevice . OpenContainer ( " Hoststicks " ) ;
s t r i n g filename = Path . combine ( device ) ;
FileStream save = F i l e . open ( filename ) ;
D a t a S e r i a l i z e r . S e r i a l i z e ( save , GameSave ) ;
save . close ;
device . Dispose ;
ReadData

1
2
3
4
5
6
7
8
context PersistentDataManager : : WriteData (Game game ) :

GameContent
device = StorageDevice . OpenContainer ( " Hoststicks " ) ;
s t r i n g filename = Path . combine ( device ) ;
i f filename . Exists
FileStream load = F i l e . open ( filename ) ;
GameSave = D a t a S e r i a l i z e r . D e s e r i a l i z e ( load ) ;
load . close ;
device . Dispose ;
9
10
11
Me. UnpackGameSaveData (Game) ;

return content ;
PackGameSaveData

1
2
3
4
5
6
7
context PersistentDataManager : : PackGameSaveData ( ) :

GameLevel = GameContent . GameLevel ;
Layers = GameContent . Tables . Count ;
GameSave . B a l l P o s i t i o n s . Clear ;
GameSave . BallIDs . Clear ;
foreach b a l l in GameContent . Balls :
GameSave . B a l l P o s i t i o n s . Add ( b a l l ) ;

8
163
GameSave . B a l l I d s . Add ( b a l l ) ;
9
10
11
12
13
14
15
16
GameSave . WarpPositions . Clear ;

GameSave . WarpVelocities . Clear ;
GameSave . WarpIDs . Clear ;
foreach warp in GameContent . Warps :
GameSave . WarpPositions . Add ( warp ) ;
GameSave . WarpVelocities . Add ( warp ) ;
GameSave . WarpIDs . Add ( warp ) ;
UnpackGameSaveData

1
2
3
4
5
6
7
context PersistentDataManager : : UnpackGameSaveData (Game

game ) :
GameContent . GameLevel = GameLevel ;
GameContent . Balls . Clear ;
b a l l = new Ball ;
b a l l . P o s i t i o n = GameSave . B a l l P o s i t i o n s [ 0 ] ;
b a l l . IsCue = true ;
GameContent . Balls . Add ( b a l l ) ;
8
9
10
11
12
for i from 1:GameSave . BallIDs . count :

b a l l = new Ball ;
b a l l . P o s i t i o n = GameSave . B a l l p o s i t i o n s [ i ] ;
GameContent . Balls . Add ( b a l l ) ;
13
14
15
16
17
18
19
20
GameContent . Warps . c l e a r ;
for i from 1:GameSave . WarpIDs . count
warp = new Warp ;
warp . P o s i t i o n = GameSave . WarpPositions [ i ] ;
warp . V e l o c i t y = GameSave . WarpVelocities [ i ] ;
warp . ID = GameSave . WarpIDs [ i ] ;
GameContent . Warps . Add ( warp ) ;
6.2.17
Physics
CalculateObjectRectangleCollision

1
context
Physics : : CalculateObjectRectangleCollision ( Vector3
position , Vector2 v e l o c i t y , Rectangle rectangle ) :
Vector
164
2
3
4
5
6
7
8
9
i f ( rectangle . Top > p o s i t i o n . Y ) or ( rectangle . Bottom <

position .Y ) :
i f ( v e l o c i t y . Dir < Pi )
v e l o c i t y . Dir = Pi v e l o c i t y . Dir ) ;
else
v e l o c i t y . Dir = 3Pi v e l o c i t y . Dir ;
else i f ( rectangle . Right < p o s i t i o n .X OR
rectangle . L e f t > p o s i t i o n .X)
v e l o c i t y .X = 2Pi v e l o c i t y . Dir ;
else
10
11
return v e l o c i t y ;
AdjustObjectSpeed

1
2
3
4
5
context Physics : : AdjustObjectSpeed ( Vector2 v e l o c i t y ,

f l o a t f a c t o r ) : Vector
i f ( v e l o c i t y .Mag > 3)
v e l o c i t y .Mag = ( 0.085 f a c t o r ) ;
else
v e l o c i t y .Mag = 0.96 ^ f a c t o r ;
6
7
8
i f ( v e l o c i t y .Mag < 0.05) :

v e l o c i t y .Mag = 0;
9
10
CalculateAbsoluteVelocityFromComponentVector

1
2
3
context
Physics : : CalculateAbsoluteAngleFromRelative ( Vector2
component ) : Vector
vector r e s u l t = new { X=0 ,Y= 0 } ;
r e s u l t .Mag = Math. Sqrt ( component .X ^ 2 + component . Y
^ 2) ;
4
5
6
7
8
9
10
11
i f ( r e s u l t .Mag == 0)
r e s u l t . Dir = 0;
else
r e s u l t . Dir = ArcSin ( component .Mag / r e s u l t .Mag) ) ;
i f ( component . Dir >= 0)
r e s u l t . Dir = ( Pi / 2) + r e s u l t . Dir ;
else

12
165
r e s u l t . Dir = (3 Pi / 2) r e s u l t . Dir ;
13
14
return r e s u l t ;
CalculateAbsoluteAngleFromRelative

1
2
3
4
5
context
Physics : : CalculateAbsoluteAngleFromRelative ( Vector2
absolute , Vector2 r e l a t i v e ) : Vector
vector r e s u l t = new { Dir =0 , Res = 0 } ;
r e s u l t . Dir = absolute . Dir + r e l a t i v e . Dir ;
r e s u l t . Res = VelocityBoundaryResolution ( r e s u l t ) ;
CalculateComponentVectorFromVelocity

1
2
3
4
5
context Physics : : CalculateComponentVectorFromVelocity

( Vector2 v e l o c i t y ) : Vector
Vector2 r e s u l t = new { X=0 ,Y= 0 } ;
r e s u l t .X = v e l o c i t y .Mag Sin ( v e l o c i t y . Dir ) ;
r e s u l t . Y = v e l o c i t y .Mag Cos ( v e l o c i t y . Dir ) ;
VelocityBoundaryResolution

1
2
3
4
5
context Physics : : VelocityBoundaryResolution ( Vector2

v e l o c i t y ) : Vector
i f ( v e l o c i t y . Dir < 0.0 f )
v e l o c i t y . Dir = v e l o c i t y . Dir + 2Pi ;
else i f ( v e l o c i t y . Dir > 2Pi )
v e l o c i t y . Dir = v e l o c i t y . Dir 2Pi ;
6
7
8
i f ( v e l o c i t y .Mag < 0.01)

V e l o c i t y . Y = 0.0 f ;
9
10
VelocityVectorAddition
166

1
2
3
4
5
6
8
9
10
context Physics : : VelocityVectorAddition ( Vector2 vector1 ,

Vector2 vector2 ) : Vector
Vector component1 = new { X=0 ,Y= 0 } ;
Vector component2 = new { X=0 ,Y= 0 } ;
Vector componentSum = new { X=0 ,Y= 0 } ;
Vector r e s u l t = new { X=0 ,Y= 0 } ;
component1 =
CalculateComponentVectorFromVelocity ( vector1 ) ;
component2 =
CalculateComponentVectorFromVelocity ( vector2 ) ;
componentSum .X = Component1 .X + Component2 .X;
componentSum . Y = Component1 . Y + Component2 . Y ;
result =
CalculateAbsoluteVelocityFromComponentVector ( componentSum ) ;
11
12
6.2.18
Pocket
6.2.19
StickManager
UpdateStick

1
4
5
context StickManager : : UpdateStick ( GameContent content ,

f l o a t angle , f l o a t f o r c e ) : GameContent
stickVector = new Vector (
content . Stick . V e l o c i t y .X+=angle , f o r c e ) ;
stickVector = Physics . VelocityBoundaryResolution (
stickVector ) ;
content . Stick . V e l o c i t y .X = stickVector .X;
content . Stick . V e l o c i t y . Y = stickVector . Y ;
6
7
8
9
10
foreach Ball in content . Balls

i f Ball . Cue == true
Ball . V e l o c i t y .X += stickVector .X;
Ball . V e l o c i t y . Y += stickVector . Y ;
11
12
return content ;
6.2.20
Table
6.2.21
TitleManager
167
SelectOption

1
2
3
4
5
6
7
8
9
10
context TitleManager : : SelectOption ( GameStateManager

stateManager ) :
stateManager . next = true ;
stateManager . loadsave = true ;
stateManager . setgameattributes = true ;
else
11
12
currentoption = 0;
6.2.22
WarpManager
Resolve

1
2
3
4
context WarpManager : : Resolve ( GameContent content ) :

GameContent
content = WarpManager . D e t e c t C o l l i s i o n s ( content ) ;
content = adjustWarpPosition ( content ) ;
return Content ;
DetectCollision

1
2
3
4
context WarpManager : : D e t e c t C o l l i s i o n ( GameContent

content ) : GameContent
Vector2 separation = new Vector2 ;
f l o a t distance = new f l o a t 0.0 f ;
bool warpMateFound = f a l s e ;
5
6
7
8
9
10

foreach warp in content . Warps
i f warp . P o s i t i o n . Z = b a l l . P o s i t i o n . Z :
separation .X = warp . P o s i t i o n .X b a l l . P o s i t i o n .X;
separation . Y = warp . P o s i t i o n . Y b a l l . P o s i t i o n . Y ;
168
11
12
13
14
15
16
17

distance = Math. Sqrt ( separation .X ^ 2 +
separation . Y ^ 2) ;
i f ( warp . Radius + b a l l . Radius distance > 0 . 1 )
and ( b a l l . WarpingWarpID < 0) :
foreach warp2 in content . Warps
i f ( warp . warpID == warp2 . WarpID ) and
( warp . P o s i t i o n ! = warp2 . P o s i t i o n ) :
b a l l . P o s i t i o n = warp2 . P o s i t i o n ;
b a l l . WarpingWarpID = warp2 . WarpID ;
warpMateFound = true ;
18
19
20
21
22
23
i f ! warpMateFound :
i n t randomIndex = random# ( 0 to
content . Waprs . count 1 ) ;
ball . Position =
content . Warps [ randomIndex ] . P o s i t i o n ;
b a l l . WarpingWarpID =
content . Warps [ randomIndex ] . WarpID ;
24
25
26
content . GameLevel = b a l l . P o s i t i o n . Z ;
27
28
return content ;
AdjustWarpPosition

1
context WarpManager : : AdjustWarpPosition ( GameContent

rectangle = new rectangle
3
4
5
6
7
8
9
foreach warp in Warps

i f warp v e l o c i t y > 0
warp . x += sin ( d i r e c t i o n ) magnitude ;
warp . y = cos ( d i r e c t i o n ) magnitude ;
rectangle = boundaryRectangle ;
warp . p o s i t i o n =
BoundaryCheckMovingObjectRectangle ( warp . position ,
warp . v e l o c i t y , rectangle ) ;
10
11
return Content ;
DetectWarpWarpCollision
169

1
context WarpManager : : DetectWarpWarpCollision ( GameContent

2
3
4
5
6
7
rectangle = new rectangle ;

separation = new vector2 ;
distance = 0;
returnvector2 = new { X=0 ,Y= 0 } ;
returnvector4 = new { X=0 ,Y=0 ,Z=0 ,W= 0 } ;
8
9
10
11
12
13
14
for i from 0:warps . count 1

for j from i : warps . count
i f warps [ i ] . p o s i t i o n . z == warps [ j ] . p o s i t i o n . z
separation . x = warps [ i ] . x warps [ j ] . x ;
separation . y = warps [ i ] . y warps [ j ] . y ;
distance = squareroot ( x^2 + y ^2) ;
15
16
17
18
19
20
21
22
23
24
i f warps [ i ] . radius + warps [ j ] . radius distance > 0.1

returnvector4 = BoundaryCheckObject ;
warp [ i ] . x = returnvector4 . x ;
warp [ i ] . y = returnvector4 . y ;
warp [ j ] . x = returnvector4 . z ;
warp [ j ] . y = returnvector4 .w;
returnvector4 =
Physics . CalculateObjectObjectCollision ;
warp [ i ] . v e l o c i t y = returnvector4 ( x , y ) ;
warp [ j ] . v e l o c i t y = returnvector4 ( z ,w) ;
25
26
27
28
29
30
31
32
foreach warp in Warps

rectangle = BoundaryRectangle ;
i f rectangle . contains ( warp )
( ) Do Nothing
else
returnvector2 =
Physics . CalculateObjectRectangleCollision ;
warp . v e l o c i t y = returnvector2 ;
33
34
return Content ;
MoveWarpPosition

1
2
3
context WarpManager : : MoveWarpPosition ( GameContent

content , vector3 adjustment ) : GameContent
rectangle = new rectangle ;
rectangle = BoundaryRectangle ;
170
4
5
6
7
Warps [ Warps . count pairCounter ] . x += adjustment . x ;

Warps [ Warps . count pairCounter ] . y += adjustment . y ;
Warps [ Warps . count pairCounter ] . z = adjustment . z ;
Warps [ Warps . count pairCounter ] . p o s i t i o n =
BoundaryCheckStaticObjectRectangle ;
8
9
return Content ;
6.2.23
6.3
Warp
Data Detailed Design
The Hot Sticks application detailed data design is defined in this subsection of the Software Design Document. Currently, there are no data
structures or methods which are not contained or defined within the
detailed module decompositions.
Annex A: Game
Screenshots
A.1
Title Screen
171
172
A.2
ANNEX A: GAME SCREENSHOTS
Game Screen
A.3. MID SHOT
A.3
Mid Shot
A.4
Settings Menu
173
174
ANNEX A: GAME SCREENSHOTS
A.5
Pause Screen
A.6
Save Menu
Annex B: API
Documentation
175
176
ANNEX B: API DOCUMENTATION
Documentation
Conventions
C.7
C.7.1
Dates
In Prose
When writing dates in prose, it shall adhere to the Gregorian Calendar, and written out completely and in Big Endian format. This
means that a date in a paragraph shall be written as Month Date (with
st|nd|rd|th), Year, where the month is written out completely, the numerical date without leading zeros, and the year is the full year. After
writing the year, it is to be followed with a comma, unless the sentence
ends with the date. In addition, no sentence is permitted to begin with
a Date.
Examples
. . . which will take place on January 22, 1943.
On July 1, 1943, members shall. . .
C.7.2
In Figures and Tables
Dates used in documentation will adhere to the Gregorian Calendar

ISO 8601 format, split by a full stop without spaces.
Examples
2009.11.22
On 2000.05.01 users shall. . .
177
178
DOCUMENTATION CONVENTIONS
Term
Abbreviation
Configuration
Index
Temporary
User
Variable
cfg
idx
tmp
usr
var
Table C.1: Global Project Abbreviations Table

Correct
Incorrect
Class Variables
Radius
BallTexture
ABall
radius
balltexture
aBall
ball_texture
a_ball
Local Variables
tempRadius
theBall
TempRadius
the_ball
Table C.2: Example of Casing in Pseudocode
C.8
Pseudocode
Pseudocode shall be developed off of the OCL 2.0 specification set by

OMG. If a method has the need to use pseudocode to illustrate part of
its operations, the entire method shall be written in pseudocode.
C.8.1
Naming Conventions
Variables used in Pseudocode elements must be descriptive of what

the data it holds. Do not use terms like bd to represent a balls data,
instead use the full words, ball and data. Exceptions to this can be
seen in Table C.1.
Classes, Methods, and Class Variables

These shall be written using capital camel case, meaning that the first
letter of these elements are capitalized, there are no underscores, hyphens, or spaces, and the letter of each word is capitalized. A few
examples can be seen in Table C.2.
C.8. PSEUDOCODE
179
Local Variables
All local variables, those that exist only in the scope of the function,
shall follow the same rules set by naming classes, methods, and class
variables, only they will be normal camel case. See below for some
examples
Looping Variables
The usage of foreach loops are preferred, but should you need a looping
variable, use i, j, and k, in that order.
C.8.2
Reserved Words
The common development words below are reserved for special purposes,
context a class scoping operator that specifies the start of a new function.
rec identifier used when defining a method to specify that it is a recursive method.
pre test a guard operation that only runs a method if the test condition
is true.
if test a block identifier that executes only when the test condition is
true.
else if test a block identifier that executes only when the previous blocked
identifier results in false and if the test condition is true.
else a block identifier which executes only when all associated block
statements fail.
for initial, test, post looping operator which has an initialization, test
condition for determining when the loop operation shall terminate, and a post execution operation that runs at the end of the
loop bock.
for var **from** range looping operator which steps on each number
in a range and assigns the value to var.
foreach DataType Var in List anonymous looping operator that iterates
over every element in array, storing the current arrays value in
the datatype var.
return ?var identifies what shall be returned after execution. If nothing is provided, the value passed is null
180
var = new ?DataType ?Size Initializes a variable. If a datatype is specified, it places the constraint of the datatype on the variable. If size
is provided, it allocates an array for the variable.
C.8.3
Included Libraries
There exists a few special libraries the define several utility functions
that act as static classes.
Math
All standard math operators perform operations operate as floating
point numbers.
Math.Sqrt(Var) takes the square root of the given number
Math.Sin(Var) takes the sine of the given number in radians
Math.Cos(Var) takes the cosine of the given number in radians
Math.Pi the constant value of Pi
Math.Ceil(Var) rounds the passed number up to the next integer
Math.Floor(Var) truncates the passed number to an integer
Math.Clamp(Var,LowerBound,UpperBound) Returns the value of Var
where if Var is less than the LowerBound, it is the value of the
LowerBound, and if its greater than the UpperBound, it is the
UpperBound.
Lists
All variables are considered as lists of variables, where the default size
of a variable is a dimension one. Below are methods which a list can
use to manipulate themselves.
list[index ] Access the data held at the position of index. If the passed
index is negative, it starts from the end of the list. If the passed
index is larger than the list size, it wraps back to the beginning.
list.Find(var) Returns the index where the passed variable is located
at. If it does not exist, the list returns a null.
list.Add(var) Adds the variable to the end list.
list.Push(var) Adds the variable to the front of the list.
list.Remove(var) Removes the specified variable from the list. Does
nothing if the variable is not in the list.
C.8. PSEUDOCODE
181
list.Pop() => removes the last list element.

list.ForEach(operation) Performs a given action on each element in a
list. This is the same as calling a foreach block and setting the
operation equal to the currently working element. For example
a.ForEach(+7) adds seven to each element in a, and a.ForEach(b+c)
makes every element in a equal to b+c. This is similar to OCamls
map function. Note that only in the scope of a ForEach method is
a special variable called Me, which represents the current element
during its iteration.
C.8.4
Construction
Elements with the same level of indention are members of the same
block of execution. The basic flow of produced pseudocode shall start
with a method identifier which specifies the context, method name, inputted datatypes with associated names, and the return type, followed
by any form of preconditions, then to the algorithm of the method, and
finally to a return statement.
Examples

1
2
3
context Demo : : F a c t o r i a l ( Integer Number ) : Integer

( ) Computes f a c t o r i a l
pre : Number > 0;
4
5
6
7
f = new;
for i from 1:Number
f = i ;
8
9
return f ;
Breaking this down we see several elementary elements,

Note the formation of the first line: context class::method(DataType
Data): ReturnType
Notice the single line comment is done by typing (-). This is more
readable than the common double slash.
The pre command is typed first, and given a test condition. This
condition test if a number is greater than zero, because a factorial
that is negative does not make much sense.
The usage of the new operator to identify the creation of a typeless variable. This means that anything can be put inside the
variable f.
182
The for-from loop, which takes each value of 1 to Number, and

stores it inside of i until the end of looping.
The return construct.

1
2
3
context rec Demo : : F a c t o r i a l ( Integer number ) : Integer

( )Computes f a c t o r i a l r e c u r s i v e l y
pre : number > 0;
4
5
6
7
8
i f number <= 1
return 1;
else
return number F a c t o r i a l ( number1) ;
The most notable thing in this code fragment is the addition of the
rec command at its definition. This ensures that the reader will know
this function will be used again within itself. Notice the usage of return.
It can be sent a static value, a variable, and methods.

1
2
3
4
5
( Gets an English l e t t e r grade based o f f o f )

( a f l o a t i n g p o i n t percentage
)
context Demo : : GetLetterGrade ( Float percent ) : String
pre : Percent < 1;
pre : Percent > 0;
6
7
8
9
10
11
12
13
14
15
16
17
letterGrade = new;
i f percent >= 0.9
letterGrade = "A" ;
else i f percent >= 0.8
letterGrade = "B" ;
letterGrade = "C" ;
letterGrade = "D" ;
else
letterGrade = "E" ;
18
19
return letterGrade ;
Here, we introduce a few more constructs.
Partitioned comments are opened with (* and closed with *).
Code indention illustrates code blocks.
You may have multiple pre statements. If any fail, the entire definition shall not run.
C.8. PSEUDOCODE
183

1
2
3
4
5
(
Pushes a o b j e c t t o the class l i s t
)
context Demo : : Push (Some element ) :
ObjectList . Add ( element ) ;
This tiny entry notes several new things,

When a definition has no return type, you do not have to specify
any datatype on the head line.
You dont have to explicitly type the word return at the end of its
definition.
A return, however, may be placed at a location you wish to break
out of the definition.
Notice the lack of a pre condition. If there are no restrictions on
the method definitions calling, then you may simply drop any pre
condition.
Note the variable ObjectList. There is not a previous definition for
this variable, because it is a class variable.
Look at the datatype Some. This can represent any type of element: Integer, Float, Numeric, Boolean, or String.

1
2
3
4
5
6
7
(
Performs a scanning square root , which i s e s s e n t i a l l y
the square r o o t f u n c t i o n performed over an e n t i r e l i s t
o f values .
)
context Demo : : ScanSquareRoot ( Numeric number ) : Float
pre : number . ForEach ( >0) ;
8
9
10
11
answer = new Float number . Size ;

for i =0 , i <number . Size , i ++
answer [ i ] = Math. Sqrt ( number [ i ] ) ;
12
13
return answer ;
This code fragment is a bit trickier. Notice how the pre statement
has a ForEach statement in it. The pre identifier understands how to
expand lists and tests all conditions. This means that the pre condition
here performs a test on every single Number which evaluates as true
only when greater than zero.
184
Next, notice how the variable answer has both a datatype constraint
and a size constraint. Also, note how the vanilla for loop is written, and
how the math operator is accessed.
Since we now have use the ForEach list operator, lets revise the
above code a bit.

1
2
3
4
5
6
7
(
Performs a scanning square root , which i s e s s e n t i a l l y
the square r o o t f u n c t i o n performed over an e n t i r e l i s t
o f values .
)
context Demo : : ScanSquareRoot ( Numeric number ) : Float
pre : number . ForEach ( >0) ;
8
9
return number . ForEach ( =Math. Sqrt (Me) ) ;

We can apply function calls to ForEach elements using the special
term Me to identify the current term in the rooting function. This call
illustrates the power of the foreach construct, as it saves space, and
conceptually makes sense.
COCOMO Estimation
D.9
Tasks
Cost Estimating For cost estimation, the publicly available COCOMO

system will offer a cost estimate for Hot Sticks. Instead of calculating SLOCs, we shall use the point values calculated by FPA. The key
modules shall be defined by the top level class diagram generated in
Domain Analysis. This value shall be reviewed in each delivery of a
working product.
D.10
Module Decision
Breaking down our project, there are twelve definable classes that we
will calculate as a module.
GUI : A generic interface for displaying data on a screen
Collision : A manager that monitors collisions and actions to be
taken when a collision happens
User Input : Manages keyboard, mouse, and controller input
Warp Management : Controls how warps and wormholes behave
Game Flow Control : Manages game states such as Title Screen,
game play screen, save game screen, options, etc
Physics : Generic physics modeling class that acts as an I/O unit.
Resources : A class that contains and manages all data that can
be varied.
Data History : A class that keeps track of each game play action
Animation : Sequential image overlay system
Viewport : Controls in-game views
185
186
COCOMO ESTIMATION
Variable
Level
PREC
FLEX
RESL
TEAM
PMAT
Low
Low
Very Low
High
High
RCPX
RUSE
PDIF
PERS
PREX
FCIL
SCED
Very High
High
High
High
Low
Low
Low
Figure D.3: Coefficient Overview
AI : The User Agent that can understand the game environment

and suggests/acts with artificial intelligence.
Network : Network Dataflow manager that transmits and decodes
multiplayer information.
D.11
Point Calculation
As were still quite new to the actual concept of game development,

every member is well educated in the meta-documents that revolve
around this. Because of that, weve noticed that the scale factors resulted in rather low numbers, but the effort multipliers were high.
D.11.1
Reasoning
PREC
Understanding of Project: Considerable, as every has a general
understanding of the project requirements.
Experience: Moderate, due to the lack of game development knowledge
Concurrent: Some, as our platform, the XBox, does not change
Innovation: Considerable, as theres a considerable amount of
physics computation.
D.11. POINT CALCULATION
187
FLEX
Conformance to Standards: Basic, as our user right now only
requires a software product that works.
External Specifications: Full, as XBox live has zero flexibility.
Early Completion Premium: Low, as the end date is inflexible.
RESL
Critical Risk Items: 26, making this element very low
Milestones: N/A None are known.
Architecture focus: 33, Largely documented, but not to the extreme of waterfall.
Percent Architects: 60, as the Architects branch into the development side shortly after the coding begins next semester.
Uncertainty in Key Elements: Considerable, as all staff are unfamiliar with C# programming and XNA libraries.
Number of Critical Risk Items: 5-10
No experience in game development

No experience in graphics manipulation
Lack of understanding of the tools available
Lack of professional training
Little experience in C# programming
New/unfamiliar process model
Most staff never worked in embedded system development
environment
Unfamiliar with multiple platform development
Unfamiliar mathematical manipulation of data structures.
TEAM
Consistency of culture and Objectives: Full, our environment shall
not change.
Accommodations of new objectives: Strong, as the two parties,
DDD and Dr. Farmer, will be in frequent communication
Experience in Teamship: Considerable, as all the staff have worked
together for about 5 months.
Team Building for Vision: Basic, as DDD has a collective understanding of the project, but not a unified vision yet.
188
COCOMO ESTIMATION
Type
Value
Aggregate (x*1000)
RM
SPP
SPT
SSM
SQA
SCM
OPF
OPD
TP
ISM
SPE
IC
PR
QPM
SQM
DP
TCM
PCM
75
75
50
DNA
35
42
90
90
35
N/A
DN
75
90
50
75
75
N/A
DN
208
208
138
0
97
110
250
250
97
0
0
208
250
138
208
208
0
0
Figure D.4: PMAT calculations
PMAT
RCPX
Rated very high, because the stability and reaction of data in video
games have to be realistic, or the user will not be totally immersed in
it. Also, the quality of the documentation will heavily drive the development of the program.
RUSE
Reuse will be high, due to the nature of pool having several similar
elements (balls/warps and their applied forms on the GUI screens).
Also, we will be adapting XNA into the game, thus, we will be reusing a
whole library of code in our project.
PDIF
This is also high, as the platform is extremely stable. The hardware
and programming logic of embedded systems such as the XBox does
not change without strong backward compatibility.
D.11. POINT CALCULATION
189
PERS
This is high, because our staffing will not change unless there are outstanding circumstances beyond the scope of the project.
PREX
This is low. The development of this project has no external costs; The
only cost is man hours.
FCIL
There are very few tools needed for the development of this project, so
this is remarked as low.
SCED
This is difficult to measure due to the fact that the staff are all students.
Using the metric that 30% of the week is dedicated to class environment
and planning around 12 hour days, this means that the available time
is 85%, which is low.
AA
Rated at 4, because the code will need testing and evaluation.
UNFM
Due to our level of experience, this is rated at 80%, because no one has
worked with the C# programming language and XNA libraries; but we
all have a strong background in programming in C++.
SUSE
Structure: Nominal, as we all know how to write clean code, and
the documentation will support this.
Application Clarity: This is clear, as all objects, by nature of our
game, will have a high level of cohesion.
Self Description: High, as our documentation model says to write
what a section of code is supposed to do first, and then the code
is written to model this.
190
COCOMO ESTIMATION
Figure D.5: First COCOMO calculation
Annex E: Weekly Progress

Reports
191
192
ANNEX E: WEEKLY PROGRESS REPORTS
Annex F: Bug Reports
193

Hotsticks Specification

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hotsticks Specification

Uploaded by

Copyright:

Available Formats

H OTSTICKS

7.2 Verification and Validation Plan .

Annex B: API Documentation

Annex E: Weekly Progress Reports

Annex F: Bug Reports

Hot Sticks Context Diagram . . . . . . . .

4.1 Warp Object Collision Sequence Diagram .

6.1 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . 136

State of the Gaming Industry

Assumptions and Constraints

The Deliverables of this project encompass:

1.2. EVOLUTION OF THE PLAN

Schedule and Budget Summary

Evolution of the Plan

P RESSMAN , R. Software Engineering: A Practioners Approach. McGrawHill Science/Engineering/Math. 6th ed.

The project documentation will be created and distributed by an online

Communication shall be facilitated through weekly development team

CHAPTER 4. PROJECT ORGANIZATION

email, corresponding to the Hot Sticks organization chart.

Capstone Progress Report

The software development team shall consist of three members, each

Roles and Responsibilities

Specialist positions are not observed in D3 . Instead, authorities are

Robert Knuuti All matters pertaining to documentation formatting,

4.3. ROLES AND RESPONSIBILITIES

Figure 4.1: Hot Sticks Organization Chart

CHAPTER 4. PROJECT ORGANIZATION

Harini Padmanabhan All matters pertaining to the analysis, high

In this plan, D3 shall use COCOMO II 2000 professional estimation

Resource Acquisition Plan

Many resources must be acquired to facilitate project completion. These

CHAPTER 5. MANAGERIAL PROCESS

Additional software resources to obtain are Microsoft Visual Studio

Project Staff Training Plan

FDD Process Training

5.1. START-UP PLAN

Table 5.1: FDD Process Training Outline

Inception of first Feature Build Process

CHAPTER 5. MANAGERIAL PROCESS

Requirements Gathering Customer requirements shall be gathered

5.1. START-UP PLAN

Descriptions Detailed itemization describing functionality and usability.

Application Testing This work activity shall be identified as any work

CHAPTER 5. MANAGERIAL PROCESS

Figure 5.1: Preliminary Development GANTT of Hot Sticks Project

Figure 5.2: Predevelopment GANTT of Hot Sticks Project

ure 5.2. This focuses on refactoring of tasks from project members

5.1. START-UP PLAN

Figure 5.3: Development Cycle GANTT of Hot Sticks Project

CHAPTER 5. MANAGERIAL PROCESS

5.2. CONTROL PLAN

Schedule Control Plan

CHAPTER 5. MANAGERIAL PROCESS

Budget Control Plan

Quality Control Plan

5.2. CONTROL PLAN

document shall be transmitted to all stakeholders weekly at the project

Metrics Collection Plan

CHAPTER 5. MANAGERIAL PROCESS

Risk Management Plan

5.3. RISK MANAGEMENT PLAN

Graphic Glitch during Development

CHAPTER 5. MANAGERIAL PROCESS

RMMM Plan more thoroughly covering all possibilities of risks, errors