hotsticks specification

HOTSTICKSPROJECT SPECIFICATION

System Analyst:HARINI PADMANABHAN

Documentation:ROBERT KNUUTI

Programmer:WILLIAM ARTHUR

Project Supervisor:WILIAM ARTHUR

Signatures

By signing this document, the following personnel approve the followingcontent is true and that the undersigned shall take responsibility forall required actions.

Name Title Signature Date

iii

iv SIGNATURES

Changeset

• 2013-10-26: Effective Print Date

v

vi CHANGESET

Preface

This Software Requirement Speifications document is purposed to de-lineate the Hot Sticks Microsoft XBox Live video game. The acquirershall be defined as the Microsoft Game Studios Entity defined in theSPMP document. This organization shall be represented by the Univer-sity of Michigan – Flint Computer Science, Engineering Science, andPhysics Department in general, and Dr. Michael Farmer in specific.

The document contains all information on the specifications to befollowed during Hot Sticks development. This includes definitions forwork products, and Intelectual Proprty for deliverables. This documentshall serve as the project blueprint as well as catalog inherent changesto the proposed system. The result, and purpose, of this documentshall be the finished Hot Sticks video game for the Microsoft XBox 360game console.

vii

viii PREFACE

Contents

Signatures iii

Changeset v

Preface vii

I SPMP 1

1 Overview 31.1 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Purpose, Scope, and Objectives . . . . . . . . . . . . 31.1.2 Assumptions and Constraints . . . . . . . . . . . . . 41.1.3 Project Deliverables . . . . . . . . . . . . . . . . . . . 41.1.4 Schedule and Budget Summary . . . . . . . . . . . . 5

1.2 Evolution of the Plan . . . . . . . . . . . . . . . . . . . . . . 5

2 References 7

3 Definitions 93.1 Synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Project Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Project Organization 114.1 External Interfaces . . . . . . . . . . . . . . . . . . . . . . . 114.2 Internal Structure . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2.1 Documentation . . . . . . . . . . . . . . . . . . . . . . 114.2.2 Communication . . . . . . . . . . . . . . . . . . . . . 114.2.3 Capstone Progress Report . . . . . . . . . . . . . . . . 124.2.4 Authorities . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . 124.3.1 Documentation Authority . . . . . . . . . . . . . . . . 124.3.2 Analysis Authority . . . . . . . . . . . . . . . . . . . . 144.3.3 Programming Authority . . . . . . . . . . . . . . . . . 14

ix

x CONTENTS

5 Managerial Process 155.1 Start-up Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.1.1 Estimation Plan . . . . . . . . . . . . . . . . . . . . . 155.1.2 Staffing Plan . . . . . . . . . . . . . . . . . . . . . . . 155.1.3 Resource Acquisition Plan . . . . . . . . . . . . . . . 155.1.4 Project Staff Training Plan . . . . . . . . . . . . . . . 165.1.5 Work Plan . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2 Control Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.1 Requirements Control Plan . . . . . . . . . . . . . . . 235.2.2 Schedule Control Plan . . . . . . . . . . . . . . . . . . 235.2.3 Budget Control Plan . . . . . . . . . . . . . . . . . . . 245.2.4 Quality Control Plan . . . . . . . . . . . . . . . . . . . 245.2.5 Reporting Plan . . . . . . . . . . . . . . . . . . . . . . 245.2.6 Metrics Collection Plan . . . . . . . . . . . . . . . . . 25

5.3 Risk Management Plan . . . . . . . . . . . . . . . . . . . . . 265.3.1 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3.2 Impact measure . . . . . . . . . . . . . . . . . . . . . 32

5.4 Closeout Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Technical Process 356.1 Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1.1 Develop a Model . . . . . . . . . . . . . . . . . . . . . 356.1.2 Build a Feature List . . . . . . . . . . . . . . . . . . . 366.1.3 Plan By Feature . . . . . . . . . . . . . . . . . . . . . 376.1.4 Design by Feature . . . . . . . . . . . . . . . . . . . . 386.1.5 Build by Feature . . . . . . . . . . . . . . . . . . . . . 38

6.2 Methods, Tools, and Techniques . . . . . . . . . . . . . . . . 396.2.1 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2.2 Documentation . . . . . . . . . . . . . . . . . . . . . . 406.2.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.3 Infrastructure Plans . . . . . . . . . . . . . . . . . . . . . . . 406.3.1 Client Software . . . . . . . . . . . . . . . . . . . . . . 406.3.2 Server Software . . . . . . . . . . . . . . . . . . . . . . 416.3.3 New Software Proposition . . . . . . . . . . . . . . . . 41

6.4 Product Acceptance Plan . . . . . . . . . . . . . . . . . . . . 416.4.1 IEEE SPMP Document . . . . . . . . . . . . . . . . . . 426.4.2 IEEE SRS . . . . . . . . . . . . . . . . . . . . . . . . . 426.4.3 IEEE SDD . . . . . . . . . . . . . . . . . . . . . . . . . 426.4.4 Hot Sticks Application . . . . . . . . . . . . . . . . . . 42

7 Supporting Process 437.1 Configuration Management Plan . . . . . . . . . . . . . . . . 43

7.1.1 Configuration Management . . . . . . . . . . . . . . . 437.1.2 Configuration Identification . . . . . . . . . . . . . . . 447.1.3 Configuration Control . . . . . . . . . . . . . . . . . . 457.1.4 Tools, Techniques, and Methods . . . . . . . . . . . . 46

CONTENTS xi

7.2 Verification and Validation Plan . . . . . . . . . . . . . . . . 467.3 Documentation Plan . . . . . . . . . . . . . . . . . . . . . . . 467.4 Quality Assurance Plan . . . . . . . . . . . . . . . . . . . . . 47

7.4.1 Initial phase . . . . . . . . . . . . . . . . . . . . . . . . 477.5 Reviews and Audits . . . . . . . . . . . . . . . . . . . . . . . 487.6 Problems Resolution Plan . . . . . . . . . . . . . . . . . . . . 49

7.6.1 Human Resources . . . . . . . . . . . . . . . . . . . . 497.6.2 Documentation . . . . . . . . . . . . . . . . . . . . . . 497.6.3 Source Code . . . . . . . . . . . . . . . . . . . . . . . 49

7.7 Subcontractor Management Plan . . . . . . . . . . . . . . . 507.8 Process Improvement Plan . . . . . . . . . . . . . . . . . . . 50

8 Additional Plans 518.1 Intellectual Property . . . . . . . . . . . . . . . . . . . . . . . 518.2 Acquisition of Staff . . . . . . . . . . . . . . . . . . . . . . . . 51

II SRS 53

1 Introduction 551.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551.3 Definitions, Acronyms, and Abbreviations . . . . . . . . . . 551.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2 Overall Description 592.1 Product Perspective . . . . . . . . . . . . . . . . . . . . . . . 592.2 Product Functions . . . . . . . . . . . . . . . . . . . . . . . . 59

2.2.1 Milestone 1: Base Game Development . . . . . . . . 592.2.2 Milestone 2: Multi Tier Refactor . . . . . . . . . . . . 612.2.3 Milestone 3: State Control . . . . . . . . . . . . . . . 612.2.4 Milestone 4: Manipulation . . . . . . . . . . . . . . . 622.2.5 Milestone 5: Replay . . . . . . . . . . . . . . . . . . . 622.2.6 Milestone 6: Local Multiplayer . . . . . . . . . . . . . 622.2.7 Milestone 7: Network Multiplayer . . . . . . . . . . . 632.2.8 Milestone 8: Artificial Intelligence . . . . . . . . . . . 632.2.9 Milestone 9: Third Dimension . . . . . . . . . . . . . 63

2.3 User Characteristics . . . . . . . . . . . . . . . . . . . . . . . 632.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632.5 Assumptions and Dependencies . . . . . . . . . . . . . . . . 642.6 Apportioning of Requirements . . . . . . . . . . . . . . . . . 64

xii CONTENTS

3 Specific Requirements 653.1 External Interfaces . . . . . . . . . . . . . . . . . . . . . . . 653.2 User interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 653.3 Hardware interfaces . . . . . . . . . . . . . . . . . . . . . . . 653.4 Software interfaces . . . . . . . . . . . . . . . . . . . . . . . 693.5 Communications interfaces . . . . . . . . . . . . . . . . . . 693.6 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.6.1 Artist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.6.2 Ball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.6.3 Ball Manager . . . . . . . . . . . . . . . . . . . . . . . 723.6.4 Game . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.6.5 Game Content . . . . . . . . . . . . . . . . . . . . . . 753.6.6 Game Object . . . . . . . . . . . . . . . . . . . . . . . 763.6.7 Game Settings Manager . . . . . . . . . . . . . . . . . 773.6.8 Game State Manager . . . . . . . . . . . . . . . . . . 783.6.9 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.6.10Load Save Manager . . . . . . . . . . . . . . . . . . . 813.6.11Menu Content . . . . . . . . . . . . . . . . . . . . . . 823.6.12Menu Manager . . . . . . . . . . . . . . . . . . . . . . 833.6.13Object Manager . . . . . . . . . . . . . . . . . . . . . . 843.6.14Pause Manager . . . . . . . . . . . . . . . . . . . . . . 853.6.15Persistent Data Manager . . . . . . . . . . . . . . . . 863.6.16Pocket . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.6.17Physics . . . . . . . . . . . . . . . . . . . . . . . . . . 883.6.18Stick Manager . . . . . . . . . . . . . . . . . . . . . . 893.6.19Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893.6.20Title Manager . . . . . . . . . . . . . . . . . . . . . . . 903.6.21Warp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913.6.22Warp Manager . . . . . . . . . . . . . . . . . . . . . . 91

3.7 Sequence Charts . . . . . . . . . . . . . . . . . . . . . . . . . 923.8 Performance requirements . . . . . . . . . . . . . . . . . . . 933.9 Design constraints . . . . . . . . . . . . . . . . . . . . . . . . 933.10Software system attributes . . . . . . . . . . . . . . . . . . . 93

3.10.1Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 933.10.2Availability . . . . . . . . . . . . . . . . . . . . . . . . 943.10.3Security . . . . . . . . . . . . . . . . . . . . . . . . . . 943.10.4Maintainability . . . . . . . . . . . . . . . . . . . . . . 943.10.5Portability . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.11Other Requirements . . . . . . . . . . . . . . . . . . . . . . . 943.11.1Controller Support . . . . . . . . . . . . . . . . . . . . 943.11.2Keyboard Support . . . . . . . . . . . . . . . . . . . . 953.11.3Language and Localization Support . . . . . . . . . . 95

CONTENTS xiii

III SDD 97

1 Introduction 991.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

1.3.1 Synonyms . . . . . . . . . . . . . . . . . . . . . . . . . 991.3.2 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

2 References 101

3 Decomposition Description 1033.1 Class Decomposition . . . . . . . . . . . . . . . . . . . . . . 103

3.1.1 Artist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033.1.2 Ball Manager . . . . . . . . . . . . . . . . . . . . . . . 1043.1.3 Ball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053.1.4 Game Content . . . . . . . . . . . . . . . . . . . . . . 1053.1.5 Game Object . . . . . . . . . . . . . . . . . . . . . . . 1063.1.6 Game Settings Manager . . . . . . . . . . . . . . . . . 1073.1.7 Game State Manager . . . . . . . . . . . . . . . . . . 1073.1.8 Game . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083.1.9 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093.1.10Load Save Manager . . . . . . . . . . . . . . . . . . . 1113.1.11Menu Content . . . . . . . . . . . . . . . . . . . . . . 1113.1.12Menu Manager . . . . . . . . . . . . . . . . . . . . . . 1123.1.13Object Manager . . . . . . . . . . . . . . . . . . . . . . 1123.1.14Pause Manager . . . . . . . . . . . . . . . . . . . . . . 1133.1.15Persistent Data Manager . . . . . . . . . . . . . . . . 1143.1.16Physics . . . . . . . . . . . . . . . . . . . . . . . . . . 1153.1.17Pocket . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153.1.18Stick Manager . . . . . . . . . . . . . . . . . . . . . . 1163.1.19Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163.1.20Title Manager . . . . . . . . . . . . . . . . . . . . . . . 1173.1.21Warp Manager . . . . . . . . . . . . . . . . . . . . . . 1173.1.22Warp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

3.2 Concurrent Process Decomposition . . . . . . . . . . . . . . 1183.3 Data Decomposition . . . . . . . . . . . . . . . . . . . . . . . 118

4 Dependency Description 1194.1 Intermodule Dependencies . . . . . . . . . . . . . . . . . . . 119

4.1.1 Sequence Charts . . . . . . . . . . . . . . . . . . . . . 1194.1.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 124

4.2 Interprocess Dependencies . . . . . . . . . . . . . . . . . . . 1254.3 Data Dependencies . . . . . . . . . . . . . . . . . . . . . . . 125

4.3.1 Data Flow Diagram . . . . . . . . . . . . . . . . . . . 125

xiv CONTENTS

5 Interface Description 1315.1 Module Interface . . . . . . . . . . . . . . . . . . . . . . . . . 131

5.1.1 Associations . . . . . . . . . . . . . . . . . . . . . . . . 1315.1.2 Game . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.1.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . 1325.1.4 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . 132

5.2 Process Interface . . . . . . . . . . . . . . . . . . . . . . . . . 1325.2.1 User Interaction . . . . . . . . . . . . . . . . . . . . . 1325.2.2 Live Update . . . . . . . . . . . . . . . . . . . . . . . . 1335.2.3 Game Play . . . . . . . . . . . . . . . . . . . . . . . . . 133

6 Detailed Design 1356.1 Module Detailed Design . . . . . . . . . . . . . . . . . . . . . 135

6.1.1 Game Management Module . . . . . . . . . . . . . . . 1356.1.2 Game Input-Output Module . . . . . . . . . . . . . . 1386.1.3 Game Objects Module . . . . . . . . . . . . . . . . . . 138

6.2 Detailed Class Design . . . . . . . . . . . . . . . . . . . . . . 1396.2.1 Artist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396.2.2 Draw Balls . . . . . . . . . . . . . . . . . . . . . . . . 1406.2.3 Ball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456.2.4 BallManager . . . . . . . . . . . . . . . . . . . . . . . 1456.2.5 GameContent . . . . . . . . . . . . . . . . . . . . . . . 1496.2.6 GameObject . . . . . . . . . . . . . . . . . . . . . . . . 1506.2.7 GameStateManager . . . . . . . . . . . . . . . . . . . 1506.2.8 Game . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526.2.9 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556.2.10LoadSaveManager . . . . . . . . . . . . . . . . . . . . 1566.2.11MenuContent . . . . . . . . . . . . . . . . . . . . . . . 1576.2.12SetLoadSaveManager . . . . . . . . . . . . . . . . . . 1576.2.13MenuManager . . . . . . . . . . . . . . . . . . . . . . 1586.2.14ObjectManager . . . . . . . . . . . . . . . . . . . . . . 1586.2.15PauseManager . . . . . . . . . . . . . . . . . . . . . . 1616.2.16PersistentDataManager . . . . . . . . . . . . . . . . . 1616.2.17Physics . . . . . . . . . . . . . . . . . . . . . . . . . . 1636.2.18Pocket . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666.2.19StickManager . . . . . . . . . . . . . . . . . . . . . . . 1666.2.20Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676.2.21TitleManager . . . . . . . . . . . . . . . . . . . . . . . 1676.2.22WarpManager . . . . . . . . . . . . . . . . . . . . . . . 1676.2.23Warp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

6.3 Data Detailed Design . . . . . . . . . . . . . . . . . . . . . . 170

CONTENTS xv

Annex A: Game Screenshots 171A.1 Title Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171A.2 Game Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 172A.3 Mid Shot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173A.4 Settings Menu . . . . . . . . . . . . . . . . . . . . . . . . . . 173A.5 Pause Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 174A.6 Save Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Annex B: API Documentation 175

Documentation Conventions 177C.7 Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

C.7.1 In Prose . . . . . . . . . . . . . . . . . . . . . . . . . . 177C.7.2 In Figures and Tables . . . . . . . . . . . . . . . . . . 177

C.8 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178C.8.1 Naming Conventions . . . . . . . . . . . . . . . . . . . 178C.8.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 179C.8.3 Included Libraries . . . . . . . . . . . . . . . . . . . . 180C.8.4 Construction . . . . . . . . . . . . . . . . . . . . . . . 181

COCOMO Estimation 185D.9 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185D.10Module Decision . . . . . . . . . . . . . . . . . . . . . . . . . 185D.11Point Calculation . . . . . . . . . . . . . . . . . . . . . . . . . 186

D.11.1Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . 205.2 Predevelopment GANTT of Hot Sticks Project . . . . . . . . 205.3 Development Cycle GANTT of Hot Sticks Project . . . . . . 21

3.1 Hot Sticks Context Diagram . . . . . . . . . . . . . . . . . . 663.2 Primary Menu and Table Design . . . . . . . . . . . . . . . . 673.3 Primary Game Elements and Title Screen . . . . . . . . . . 683.4 Hot Sticks Top Level Class Diagram . . . . . . . . . . . . . . 70

4.1 Warp Object Collision Sequence Diagram . . . . . . . . . . 1204.2 Warp Warp Collision Sequence Diagram . . . . . . . . . . . 1204.3 Cue Stick Update Sequence Diagram . . . . . . . . . . . . . 1214.4 Detecting Warp Collision Sequence Diagram . . . . . . . . . 1224.5 Game Save Sequence Diagram . . . . . . . . . . . . . . . . . 1224.6 Game Load Sequence Diagram . . . . . . . . . . . . . . . . . 1234.7 Game Load Sequence Diagram . . . . . . . . . . . . . . . . . 1234.8 Warp Table Collision Sequence Diagram . . . . . . . . . . . 1244.9 Top Level DFD . . . . . . . . . . . . . . . . . . . . . . . . . . 1254.10Ball Management DFD . . . . . . . . . . . . . . . . . . . . . 1264.11Ball Pocket Collision DFD . . . . . . . . . . . . . . . . . . . . 1274.12Ball Warp Collision DFD . . . . . . . . . . . . . . . . . . . . 1274.13Ball Table Collision DFD . . . . . . . . . . . . . . . . . . . . 1284.14Ball Ball Collision DFD . . . . . . . . . . . . . . . . . . . . . 1284.15Menu Management DFD . . . . . . . . . . . . . . . . . . . . 129

6.1 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . 1366.2 Module Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 137

D.3 Coefficient Overview . . . . . . . . . . . . . . . . . . . . . . . 186D.4 PMAT calculations . . . . . . . . . . . . . . . . . . . . . . . . 188D.5 First COCOMO calculation . . . . . . . . . . . . . . . . . . . 190

xvii

xviii LIST OF FIGURES

List of Tables

5.1 FDD Process Training Outline . . . . . . . . . . . . . . . . . 175.2 C# Training Outline . . . . . . . . . . . . . . . . . . . . . . . 175.3 Risk Management Weighting . . . . . . . . . . . . . . . . . . 32

C.1 Global Project Abbreviations Table . . . . . . . . . . . . . . 178C.2 Example of Casing in Pseudocode . . . . . . . . . . . . . . . 178

xix

xx LIST OF TABLES

Part I

SPMP

1

Chapter 1

Overview

1.1 Project Summary

1.1.1 Purpose, Scope, and Objectives

State of the Gaming Industry

Advances in computing have brought all facets of modern life into theinformation age. This has helped transform entertainment into a ma-jor business entity. The video game industry is one of the largest divi-sions of the entertainment industry today. Sales and distribution varyfrom traditional brick-and-mortar to digital medium. The Platformsencompass computers, consoles, and a myriad of portable devices. Todate, Microsoft’s XBox 360 gaming console has sold well over 30 mil-lion units. Adding to that a Microsoft Windows worldwide install baseof 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. Thereare none which dare to take the classic game of billiards into anotherdimension. This is where the problem lies. Our solution to this problemis Hot Sticks.

The business world revolves around supply and demand. D3 is here 2to 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 inconcept and execution. Hot Sticks brings the traditional game of bil-liards into the third dimension. Mechanics will emulate real-life poolplay, satisfying even the most avid billiard enthusiast. Hot Sticks game

3

4 CHAPTER 1. OVERVIEW

play will deliver a unique twist not possible in the real world; playingmultiple tables in one single game. With multiple tiers of a table, ballsmay traverse up or down levels. Warp zones on every level transportmoving balls to the levels above or below. Hot Sticks takes strategy toa whole new level! Game settings are user-customizable. Alter friction,add levels or change all warp destinations to random locations: Defythe laws of physics themselves. No two games will ever be the same.And what would a game of pool be without friends? Play locally withfamily or with friends online using Microsoft’s live system.

Target Audience

Hot Sticks is destined both for PC Games for Windows and XBox Live onthe XBox 360 gaming console. With a solid foundation in the physicsof pool playing, Hot Sticks will definitely appeal to the billiard enthu-siast. And with a new twist on the game of pool and intuitive controldesign, this game will also capture the imaginations of casual gamersof any age. Add in customizable gaming rules and online multiplayerthrough XBox Live or Windows Live and Hot Sticks becomes the multi-dimensional billiards game for anyone interested in fun.

1.1.2 Assumptions and Constraints

Hot Sticks will be developed under heavy constraints. The documen-tation and development cycle shall be done concurrently, and a prod-uct that fulfills the contract specification needs to be delivered by firstquarter of 2010.

The resources provided is also limited. Budgeting and Personnel is2limited to what our sponsor, the University of Michigan-Flint’s CSESPdepartment, can afford. Professional reviews are schedulable for guid-ance 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 iterationsthroughout the development cycle starting January 4, 2010, to the finaldelivery date.

1.2. EVOLUTION OF THE PLAN 5

1.1.4 Schedule and Budget SummaryThe schedule for the team members have been allotted after throughdiscussions on factors that influence the plan such as individual teammember class timings, work timings, process model specification, dis-tribution of work, individual speed, and technical know-how to namea few. Fall back plans have been included taking into account humanfactors such as lack of productivity, ideas, removal of old methods for anew start, and also personal situations that could crop up. The techni-cal factors that influence the schedule have also been considered, andthe coders have been pre-planned a training schedule that has them fa-miliarizing with the software languages. The schedule has been madeas accurate as possible including fall back options to continue the workflow patterns needed by the process model.

The team has proposed and analyzed various strategies to keep the 2project cost effective as possible. All project specification requirementsshall be analyzed and a budget estimate calculated. The required bud-get has the probability of being extended further as the team plans toinclude improvement methods in testing of the code that absolutely de-mands the need to scale the upper limit of the budget. The issue willbe discussed with the course instructor Dr. Farmer and the ComputerScience Department of the University of Michigan – Flint, for the sanc-tioning of the required expenditure. Proof will be produced that themethodology adopted is essential for the gaming environment and theamount calculated is the most feasible for the given scope of the soft-ware. The total budget allocation of this project shall be managed bythe 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 qualityof the project remains consistent. Updates to the wiki are generatedon edit, and a change log is available globally over the entire wiki, orlocally on a per-document basis. Notifications are similarly produced inreal time, publishing them to the Atom 1.0 website syndication format,where participants in the project can immediately see changes made.

6 CHAPTER 1. OVERVIEW

Chapter 2

References

Documents used for the established of this whitepaper can be found asbelow.

PALMER, S. R., FELSING, J. M. A Practical Guide to Feature-DrivenDevelopment. Prentice Hall PTR. 2002.

PRESSMAN, R. Software Engineering: A Practioner’s Approach. McGraw-Hill Science/Engineering/Math. 6th ed.

IEEE COMPUTER SOCIETY. IEEE Standard for Software Project Man-agement Plans. (1058-1998). 8 Dec 1998.

7

8 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 dis-cussing 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 2be read as Microsoft Windows XP or Higher.

3.2 Project Terms

Warp A type of positional transport which has a clear entry and exitpoint.

Wormhold A type of positional transport which has a clear entry but afuzzy exit point.

9

10 CHAPTER 3. DEFINITIONS

Chapter 4

Project Organization

4.1 External Interfaces

This sub clause of the SPMP shall describe the organizational bound-aries between the project and external entities such as user interface,hardware interfaces, software interfaces, organizational charts and di-agrams can also be used to depict the project’s 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 Internal Structure

4.2.1 Documentation

The project documentation will be created and distributed by an onlinewiki system. This is necessary due to the fact that the developmentteam will not be co located in one work environment. All project doc-umentation shall be stored and distributed exclusively through thissystem.

4.2.2 Communication

Communication shall be facilitated through weekly development teammeetings. Preliminary Meetings are to be held weekly on Wednesdayevenings from 5:30 PM until 8:00 PM in the Murchie Science Building,3rd floor breezeway at the University of Michigan âAS Flint campusfrom September 1st, 2010 until December 9th, 2010.

Development meetings shall be held weekly on Saturdays at 9:00 2AM in the ITS Computer Lab located in the same building until April20th, 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-3

vided by the University of Michigan âAS Flint.

4.2.3 Capstone Progress ReportA weekly report shall be filled out which will serve as an itemized list ofnames to activities performed throughout the week. This memo shallreview the topics intended to be covered during the meeting and whattasks will need to be performed for the next iteration. The progressreport shall be written by the Documentation Authority, distributedto development members via the wiki, and presented to the CustomerRepresentative on every workweek Tuesday.

4.2.4 AuthoritiesThe software development team shall consist of three members, eachholding a position which defines who is the ultimate authority in therelated subject matter. These units are,

• Documentation

• Analysis

• Programming

This format forms a circle of responsibilities that can be seen in theattached Organization Chart. This can be seen in Figure 4.1.

4.3 Roles and Responsibilities

Specialist positions are not observed in D3. Instead, authorities areplaced for responsible parties and all project members shall participatein all stages of Hot Sticks development. The project shall not have aproject leader, but instead act as a single entity with three differentperspective supervisors.

4.3.1 Documentation AuthorityRobert Knuuti All matters pertaining to documentation formatting,production, aggregation, distribution, and conventions shall be super-vised by this authority. The Documentation authority shall activelyreview software analysis artifacts and produce whitepapers for the Pro-gramming authority to review.

Additional tasks placed unto the Documentation Authority are con-2figuration management and technological adviser for developmentaltools.

4.3. ROLES AND RESPONSIBILITIES 13

William Arthur

Programming Authority

Robert Knuuti

Documentation Authority

Harini Padmanabhan

Analysis Authority

Pro

gra

mm

ing

Ma

tte

rs

Do

cu

me

nta

tio

n

Ma

tte

rs

Pro

gra

mm

ing

Ma

tters

An

aly

sis

Ma

tters

Analysis

Matters

Documentation

Matters

Figure 4.1: Hot Sticks Organization Chart

14 CHAPTER 4. PROJECT ORGANIZATION

4.3.2 Analysis AuthorityHarini Padmanabhan All matters pertaining to the analysis, highlevel development, cohesion and coupling, and relations between el-ements shall be supervised by this authority. The Analysis authorityshall validate produced artifacts and check the feasibility of the saidartifacts.

4.3.3 Programming AuthorityWilliam Arthur All matters pertaining to the coding conventions, al-gorithms, binaries, and unit testing shall be supervised by this author-ity. The Programming authority shall ensure that produced contentadheres to the specification document and shall address accidental en-gineering defects to other members for potential revision.

Chapter 5

Managerial Process

5.1 Start-up Plan

5.1.1 Estimation Plan

In this plan, D3 shall use COCOMO II 2000 professional estimationsoftware to calculate the estimated cost of the Hot Sticks project andprovide 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 areaof application development. The roles and responsibilities of the threefull-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 in-dividual role of authority. These personnel will be necessary for theentire duration of the project. Personnel are to be obtained from re-maining members of the previous development team, formerly knownas B*Harp. The following paragraphs denote how specific positions willbe filled by available personnel. All staffing breakdowns are assume tobe experts in the listed responsibility unless noted otherwise.

There is to be one Documentation Authority, one Programming Au- 2thority and one Analysis Authority.

5.1.3 Resource Acquisition Plan

Many resources must be acquired to facilitate project completion. Theseare 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 documen-tation. This resource is to be acquired by the Documentation author-ity. Administration and maintenance of aforementioned resource willbe the responsibility of the Documentation authority as well.

Training

Software and training resource acquisition for each project membershall be the responsibility of each member. Microsoft MSDN mem-berships are to be obtained by Programming authority. Members areindividually responsible for obtaining memberships. These will be ob-tained through University of Michigan – Flint CSESP department re-sources. Information on said resources can be obtained from SystemsAdministrator Senior David Rosemary of the CSESP department.

Software

Additional software resources to obtain are Microsoft Visual Studio2008 Professional and Microsoft XNA Game Studio 3.1 software. Theseare to be obtained through Microsoft DreamSpark student resourcesor though the MSDNAA program provided by the CSESP department.The above resources are of no monetary cost and are to be obtained nolater than January 26, 2009.

XNA Creators Club professional membership must also be obtained.2This will be necessary to support game transfer to the XBox 360 gam-ing system. This is to be obtained by Systems Administrator SeniorDavid Rosemary of the CSESP department. Resource monetary cost isgoverned by the University of Michigan – Flint’s CSESP department. Allrequests 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 coordinatoris to be Documentation authority. All members will receive trainingmaterials from the FDD training coordinator and execute a one-weekself-training session, specified in Table 5.1.

Development Language Training

Development language training will be done to facilitate the Build byFeature process. The application will be developed entirely using theC# high-level programming language. Programming authority William

5.1. START-UP PLAN 17

Entry Criteria None

Exit Criteria Process refinement and modifica-tion meeting held and FDD processhas been tailored to suit the appli-cation.

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 com-pleted through University of Michi-gan – Flint CSESP department re-sources.

Exit Criteria Inception of first Feature Build Pro-cess

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. Alldevelopment team members will take part in self-study. This will befacilitated by Microsoft MSDN C# Development Training Center. Train-ing will be conducted online through examples and training videos andexercises. An outline of this is illustrated in Table 5.2.

Microsoft XNA Game Studio 3.1 training is to be completed by all 2development 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 de-fined in Section 1.1.3.

IEEE SPMP Document This deliverable shall be comprised by thefollowing list of work activities:

Project Initiation This work activity will include all project inceptionactivities. Project scope shall be determined as well as determina-tion of all stakeholders.


Requirements Gathering Customer requirements shall be gatheredduring this work activity. Communication methods will be es-tablished between project stakeholders.

Estimation This work activity shall encompass all activities necessaryto facilitate a reasonable accurate initial estimate of project costand duration.

Scheduling Contained in this work activity are all supporting effortsto determine a schedule for project implementation. This workactivity will be refined for granularity as necessary for the durationof 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 de-liver the SPMP a whitepaper to all stakeholders defined in theproject initiation work activity.

IEEE SRS Document This deliverable shall be comprised of the fol-lowing work activities:

System Modeling Analysis This work activity shall encompass all ac-tivities 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 activityare those used in modeling the system to be fabricated. Theseactivities shall be defined in Section 6.

Delivery This work activity shall encompass all work necessary to de-liver the SRS a whitepaper to all stakeholders defined in the projectinitiation work activity.

IEEE SDD Document This deliverable shall be comprised of the fol-lowing work activities:

Planning Mapping out of tasks and general flow of individual require-ments and distributing tasks.

Design Entities Identification of data types and/or enumerations.

Object Relationship Identification of object relationships and cardi-nality.

Views Choosing appropriate design views to effectively convey infor-mation.


Descriptions Detailed itemization describing functionality and usabil-ity.

Delivery This work activity shall encompass all work necessary to de-liver the SDD a whitepaper to all stakeholders defined in the projectinitiation work activity.

Hot Sticks Application This delivery shall be comprised of an itera-tion of activities. Each iteration shall have:

Object Modeling Analysis This work activity shall encompass all tasksnecessary to model the problem to be solved for all iterations of thesoftware application. Problem modeling activities shall be definedin Section 6.

Object Modeling Design All activities relevant to the modeling of soft-ware product modules shall occur during this work activity. Thisactivity shall be repeated iteratively for all modules to be includedin finished product. Product modeling activities shall be definedin Section 6.

Object Coding This work activity shall encompass all work necessaryto transfer design documentation to code language specified byproduct.

Function Testing Definition of this work activity is any effort neces-sary to test products of the aforementioned work activity FunctionCoding.

Integration This work activity shall encompass all necessary effort tointegrate modules constructed into the overall application.

On the final deliverable, will have an additional two work activities, 2

Application Testing This work activity shall be identified as any workwhich must be done to test the application as a whole. Thiswork activity is to be completed once all iterative functions haveachieved integration.

Application Delivery This work activity shall encompass all work nec-essary to deliver the finished application to all stakeholders de-fined 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 personaltraining.

Schedule allocation for predevelopment setup is illustrated in Fig- 2


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 membersafter weighing in the difficulties experienced in training, infrastructuresetup, and preliminary document construction.

Schedule allocation for development cycles is illustrated in Figure 5.3.3This outlines the project timeline for completing individual phases ofdevelopment.

Resource Allocation

This section describes the resources for work activities of the projectsuch as computing resources, software skills, testing the software prod-uct and simulation facilities, and administrative support. For instance,in computing resources our software team is going to need two XBox360 console to test the each project deliverables to our customer repre-sentative, in software skills the development team was assigned learn-ing C# as a self training and apply this knowledge for the develop-ment of this software product which is the major factor of this softwareproject, and in administrative support category, the DocumentationAuthority was assigned to document each delivery of the project.

Project Initiation This work activity provides information regardingto initiate the project by planning or define the scope, purpose and of


Figure 5.3: Development Cycle GANTT of Hot Sticks Project


the project in the software development life cycle. In our project initi-ation, we define the scope of the our project by stating that the videogaming industry is booming in today’s age so we decided to develop apool game for the XBox 360 console for our users. Defining our usersin a generic way, our users are who play as single player or multiplayernot preferably categorize for a specific age, as to target Hot Sticks’srating to the ESRB E rating or equivalent.

Requirements Gathering User requirements describe the demandfrom that software product to be delivered to our user. In this caserequirements gathering from our users would be challenging due tothe fact our users don’t know what they want based on their assump-tions and requirement. Users would be ourselves such as softwareteam members and the customer representative.

Estimation In this work activity, D3 makes sure that the delivery ofeach of the working product to be delivered in a time frame that wasscheduled. Based on user requirements our team can calculate theestimation of the delivery of the whole project and cost of the project.

Scheduling In scheduling work activity, the documentation of ourproject provides the information duration of each process in the soft-ware development project. Also it assigns each individual to do a cer-tain tasks for documentation for IEEE 1058-1998 standard. For exam-ple, schedule for software development weekly meeting, schedule forindividuals to research on the material for training such as learningnew language C# and schedule for meeting with customer representa-tive. Delay of scheduling can cause duration for each work activity goeslonger to be done.

Modeling Analysis In modeling analysis work activity, our softwaredevelopment team built the class base diagram, use cases for eachobject in the project. Basically it describes the overall system and cor-relation between objects and users through our use cases and ClassResponsibility Collaboration (CRC) cards to get the job done.

SPMP Delivery Software Project Management Plan Delivery is theprint out copy of a final documentation of the software project to bedelivered to the customer. This involves the description work activities,elements of the project, project estimation of how long it’s going to taketo complete the working product estimation time of each individual’seffort to finish their tasks.

5.2. CONTROL PLAN 23

Budget Allocation

Allocation of monetary resources shall be handled independent of thiswhitepaper. Initial budget, as defined in Section 1.1.4 is the only allo-cation in which the Hot Sticks project is permitted to have.

5.2 Control Plan

5.2.1 Requirements Control Plan

Changes shall be permitted, and encouraged throughout the develop-ment of the project. Those wishing to submit changes are required topresent their changes to leaders of the project during the weekly projectmeeting, or by submitting a plan through email. The change plan shallcover both the gains and losses for implementing the change, as wellas a time estimate for completion.

The change will then be put under analysis before it is put into the 2project’s development cycle. Each authority will review the changesand verify the information provided by the developer. If the changehas the approval of two of the three authorities, the change shall beimplemented in the next iteration. A message will be sent out to thesoftware architects to revise the specification and then delegating tasksin re factor the document and then distributing the changes to the restof the development team.

5.2.2 Schedule Control Plan

Documentation Reporting

Documentation will be performed actively throughout the project andwill be dynamically updated, and reported in accordance to the projectevolution plan. Weekly updates shall be distributed to developmentteam members. These updates shall occur by way of the CapstoneProgress Report document template provided by the User Represen-tative Entity. This shall be updated weekly and is to be transmittedto all stakeholders including customer representative. Transmissionshall occur every Tuesday beginning January 19, 2010 and continuethrough April 19, 2010 with the exclusion of March 2, 2010. Thisweekly document shall record tasks completed, tasks to be worked onas well as unanticipated tasks for each individual development teammember. Project performance as well as individual work performanceshall be documented in this manner.


Staffing Report

Team members are required accomplish assigned tasks itemized in theweekly report. There are no time constraints for completion of tasks,but frequent oral communication is required of the team member toitemize sub tasks involved in the completion of the task.

5.2.3 Budget Control Plan

The budget control for the product involves communication with theCustomer Representative, which will submit a file to the University ofMichigan – Flint’s CSESP department, which will be passed before theiradministration board for approval. Team members will plan businessstrategies to keep the expenditure within limits. If need arises for addi-tional expenditure it is required to file for the amount to the CustomerRepresentative, stating the cause for the increase in expense. All pur-chasing plans shall be reviewed by D3 such that no excess product ispresented for order. This shall minimize the rejection rate of requiredelements, and improve the team image.

5.2.4 Quality Control Plan

Customer needs and ease of use is the main target, features needed forthe software are developed with this in mind. During the developmentphase of a feature, the team analysts will work along with the codersto suggest strategies. Review meetings shall be held where each fea-ture will be discussed and analyzed to ensure quality outcome of theproduct. Features will be tested and modified to include any changefor further improvement. Peer reviews are held to get a different per-spective, it helps improve the overall approach.

Source code quality control shall be obtained through the select pro-2cess itemized in Section 6.1.

5.2.5 Reporting Plan

Documentation will be performed actively throughout the project. In-dividual tasks are to be reported to the Documentation Authority to becomplied into the Weekly Capstone Progress Reports.

Capstone Progress Report

Weekly updates through the Capstone Progress Report shall updatemembers on the progress of each element. Tasks to be worked on,actual work completed, unanticipated tasks and future tasks shall bedefined within this document. Work responsibilities and actual workperformed shall be explicitly stated within this document. The currentstate 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 projectreview 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 thecompleteness of a section of the project. To be complete, the entiresection must be in working order before the section passes the met-ric collection. When goals are not reached the team shall adjust theschedule and adjust the plan. Metrics weekly reporting shall occur inthe Capstone Progress report document after the first iteration.

Requirements Gathering Metrics

Requirement gathering metrics shall be performed. This will be ac-complished by tracking the number of classes in the application tothe number of individual requirements. This number shall be plottedagainst the previous occurrence to show project requirement complex-ity.

Analysis Metrics

Analysis metrics will be comprised of the number of classes as well asthe number of methods. Average methods per class will be used totrack project complexity.

Design Metrics

Design metrics will include the tracking of the number of classes, meth-ods and average methods per class. In addition, the popular CyclonicComplexity collection metric shall be calculated per method.

Coding Metrics

Coding metrics shall be collected, and will be comprised of the numberof classes, methods and average number of methods per class.

Testing Metrics

Testing metrics shall be utilized through the tracking of the numberof classes, the number of methods as well as the average number ofmethods per class. In addition, the number of defects injected perclass shall be tracked.


5.3 Risk Management Plan

The critical risk items outline in the COCOMO risks enumerated overseveral fields of the development, including the lack of education ingame design, graphics, tools, training, language, model, embedded sys-tems, cross platform development, and unfamiliarity with physic ma-nipulations.

Based off of these elements, the following risks outlined are2

• Project

• Technology

• Staff

• Consumer

• Business

• Schedule

• Cost

5.3.1 Risks

Inadequate Staffing

Working as a three member team on a completely new code develop-ing environment may end up resulting in inefficient work flow. Theremaybe necessary more than the assigned members to work on a par-ticular issue and hence this will lead to either decrease of functionality,or one of the members working to match their schedule and the newlyadded task, contributing to inefficient management skills. This delaysthe development cycle even more because now we have to resolve issueswhile accelerating development.

RMMM The staffing is fixed, unless additions can be made, the onlysolution to the problem of having more work flow is to schedule thework load better to fit the time needed to compensate for the extrawork 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 experiencefor the coders, thus there is a problem of unknown language initiallyand the problem of little known language.

RMMM Constant training, regular practice, thorough research is re-quired 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 thefeatures and methods. Coders are working on the XBox 360 and thelanguages to implement them for the first time, hence the problem oflack 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 foundout, it takes a through knowledge of functions and the proper way toimplement them to fully avoid this situation.

RMMM Adding comments to the code helps to resolve the problemmore quickly, it takes a through knowledge of functions and the properway to implement them to fully avoid this situation, thus practice andlearn the language as much as possible.

Irregular Workflow Pattern

Due to the schedule pattern involving attending university and takingup classes, the scheduled in finishing the required feature may extendand also the weekly meeting to review and reflect on progress may alsodelay.

RMMM Plan ahead, always keep room for handling changes, a backup method has to be there at all times for working in a group to stopdelays.

Misinformed Communication

The team member may understand the requirement wrong, and starton the coding incorrect and will have to start over, this is a waste ofman hours and delay in time.

RMMM Speak up any doubts, clarify the requirement thoroughly, payattention when discussion is commencing.

Abandoning Methods

Half way into the coding or development phase methods can be consid-ered “not do able” and abandoned to adopt new strategy, this is a delayin man hours and project workflow time.


RMMM Plan more thoroughly covering all possibilities of risks, errorsand failures. Make a back up plan to fall back on.

Inaccurate Problem Solving Strategy

The game is heavily dependent on the physics engine, which requiresthe approach of solving real time gaming situations for accurate play.Incorrect approach to implement the laws of physics results in an errorprone game.

RMMM Read and understand the laws of physics, practice solvingsimilar problems, consult the university physics staff for guidance.

Overriding Functions

The cohesion and coupling of the entire modules decides the function-ality of the game, which will go adverse if there are over-riding functionsthat give faulty calculations to the game inputs.

RMMM Understand the coding requirements and strategy from thestart, mark down the properties of functions, review and test the codeafter each significant addition of data.

Training Delay

The time allotted to learn the software techniques before implement-ing them maybe delayed due to team members incorrect planning orsudden personal intrusions.

RMMM Use Capstone Progress Report to predict schedule planningand a lot times, compare results after a week and improvise schedulingto better suite the user need and project need.

Data Loss

System saves on files, file location, code updating, document updatingcan be lost if not done thoroughly. Carelessness could surface due toeither interruptions or distractions leading to these data loss. This is aloss of man hours and time.

RMMM Update frequently, the changes, be sure to check if file issaved, handle all the files carefully and store it where it is easy toremember, have name tags.


Mishandling the Output Devices

The XBox, and controller, if tampered, may get damaged thereby stop-ping the project work flow since the entire testing process depends onthe output devices.

RMMM Handle the devices with care.

Schedule Delays

Personal issues, sudden challenges, poor management technique couldresult in the delay of the project timeline. This affects the entire pro-cess, including the deadline to be met.

RMMM Constantly monitor capstone progress report, any delays aredetected from the deviations observed.

Lack of Cross Platform Development

Working on multiple platforms, raises unfamiliarity issues, develop-ment problems and time delays.

RMMM Thorough research of devices and system to be working on isnecessary, 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 isnecessary, practice makes perfect so practice, read and understand.

Lack of Game Development Background

Unfamiliarity with gaming concepts ensures the problems of develop-ment, design and testing of the entire software.

RMMM Browse through the millions of online database that talk ofgame development, download game development codes to test and runthem, learn and develop mini games, small steps lead to big achieve-ments.


Resource Limitations

The project scope requires the need of two XBox 360 for ensuringsmooth flow of the testing, design and development cycle. Other unan-ticipated requirements of hardware or software objects may arise. Thebudget allocation puts a limits on this and hence it affects the entireprocess.

RMMM Obtain necessary hardware and software resources as earlyas possible. Plan budget allocation accurately, if situation unavoid-able personnel expenditure are to be incurred to maintain the projectdevelopment pace.

Unfamiliar Processor Model

The FDD process is by itself not widespread compared to the otherprocess models that are used. Any doubts that arise in the implemen-tation of the methods would delay schedule due to limited number ofresources available to refer (both on the Internet and textbook).

RMMM Consult the professor for guidance,state the problem and thesolution method being implemented. Several software are modeled oncombining elements from different process model, so essentially this isacceptable so long as the software development runs smooth.

Incorrect Process Approach

The FDD process step by step approach to the development of the soft-ware could be mis-interpreted or applied wrong. This results in a faultyapproach.

RMMM Consult the professor for guidance,state the problem and thesolution method being implemented. Several softwares are modeled oncombining elements from different process model, so essentially this isacceptable so long as the software development runs smooth.

Unfamiliar Language Library XNA The library of the developmentlanguages is the base for coding, if libraries functions are unknownit could result in errors, time delays to search and understand therequired functions or an unnecessary approach to solve the issue thereby making the code longer and more prone to inconsistencies.

RMMM All team members learn XNA Language Library. Constanttraining, regular practice, thorough research is required to gain famil-iarity and understanding.


Poor Documentation

The entire content to be written requires the need to be accurate, asystematic flow pattern and up to date. Human errors involving overriding documents, errors, poor language skills and duplicate entriesupsets the accuracy and the format of submission.

RMMM Review the document before making any changes, Frequentlyupdate, keep a track of changes included, practice forming coherentand grammatically correct sentences.

Unstable Project Requirements

The project is a first for all the developers and the team involved, thuschanges are to be expected. This could mean the start from scratch orto remodel certain approaches. This cause time delays and more manhours to be invested.

RMMM Clearly define project specifications initially, brain storm pos-sible faults and alternate approaches, choose what is best and the teammembers all agree upon. Be open to suggestions.

Failure to Meet Expectations

All the users have expectations of a game to behave in a manner thatmakes it easy for them to use and understand. The expected featuresby all the users can not be met, the system is very limited to teammember skills.

RMMM Develop features that form the base for any game which makesit run efficiently, other features may be included based on constraintsand necessity.

Review Follow Up Failure

Reviews are conducted to discuss and arrive to conclusions, approachesand improvise the project. If not practiced it leads to decrease in thequality of approach.

RMMM Make sure to follow the required schedule time allotted forreviewing, if not make arrangements to hold another meeting or get theinformation from a missed review session. Maintain a record statingchanges and comments.


Unfamiliarity with Development Tools

The development tools chosen are new, thus it takes research and prac-tice to approach the right way.

RMMM Constant training, regular practice, thorough research is re-quired to gain familiarity and understanding.

Game Removal

Microsoft removes the game due to violations of copyright or breach ofterms.

RMMM We remove the association with Microsoft and halt the XBoxversion, the Desktop version does not require authorization by Mi-crosoft adherence it will continue to be deployed.

5.3.2 Impact measureThere are three measures of impact used, ranging low, average, consid-erable, high, and catastrophic impacts. The weighing for these measureare displayed in Table 5.3

The Risk Exposure shall be calculated by RE = PC, where p is the2probability of the risk and C is the cost incurred. This factor does notapply to our system.

Table 5.3: Risk Management Weighting

Risks Risks Category Probability Impact Weight

Code errors Technology, Project 60% 5 30

Schedule delays Staffing, Schedule 60% 3 18

Insufficient lan-guage codingskills

Technology, Project 40% 4 16

Unfamiliar lan-guage library

Technology, Project, Sched-ule

40% 4 16

Graphic develop-ment glitch


Training Delay Staffing, Project 50% 3 15

Over-riding func-tions


Continued on Next Page


continued from previous page

Risks Risk Category Probability Impact Weight

Lack of Skill inCross PlatformDevelopment


Inaccurate prob-lem solving strat-egy

Project 20% 5 10

Review Follow-upfailure

Project 25% 4 10

Unfamiliaritywith Develop-ment Tools

Technology 25% 4 10

Irregular work-flow pattern

Staffing, Schedule 30% 3 9

Lack of SkillWith EmbeddedSystem


Lack of Game De-velopment Back-ground


Abandoningmethods


Game Removal Business 10% 4 4

Mishandling theoutput devices

Project, Technology 10% 4 4

MisinformedCommunication

Technology, Project, Sched-ule

10% 3 3

Unstable projectrequirement

Technology 25% 1 2.5

Data Loss Project 5% 4 2

Expectation Fail-ure

Customer 20% 1 2

InadequateStaffing

Staffing, Project, Schedule 20% 1 2

Continued on Next Page


continued from previous page

Risks Risk Category Probability Impact Weight

Incorrect ProcessModel Approach

Project 20% 1 2

Resource limita-tion

Technology, Project, Cost 20% 1 2

Unfamiliar Pro-cess Model

Project 15% 1 1.5

Poor documenta-tion

Project 5% 1 0.5

5.4 Closeout Plan

D3 shall maintain the general tiered staff assignments specified in Sec-tion 4.3 at the end of the Hot Sticks project lifecycle. The project archiveshall maintain itself on the wiki site, which contains a history of allactions taken with the project, as well as hold the most up-to-dateversion of whitepapers. Information about the project for review canbe obtained through contacting the Project Manager, or by contactingDr. Michael Farmer of the University of Michigan – Flint. Documenta-tion, reports, and other whitepapers can be obtained by contacting theDocumentation Authority. These whitepapers span analysis and themeeting minutes that detail project actions, planning, modeling, andsummaries explaining each of these elements.

By signing their name in the Signatures section, all parties involved2with 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 FeatureDriven Development. With feature driven development, there are fivemajor sections – defined process in the specification – to the model,each with defined tasks. The FDD process is similar to iterative meth-ods, 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 bepreformed. The application will be hashed out in detail to define whatboarders will be needed in the development. This stage focuses moreon the boundaries of the application than the granularity of how theapplication will be coded. There are six required and one optional stepsto be preformed in this process.

Form the Modeling Team

The project manager establishes a team using staff with permanentpositions.

Domain Walkthrough

The modeling team shall scope the development of the Hot Sticks sys-tem from what is expected of the application to necessary technologiesand other meta-development topics.

35

36 CHAPTER 6. TECHNICAL PROCESS

Study Documents

An optional step where the modeling team reviews the documents cre-ated in the previous step. This should be skipped on the first circuit ofdevelopment, but is absolutely essential when preforming review or refactoring requirements.

Develop the Model

In small groups, the modeling team will each develop a model on theHot Sticks system, and offer a presentation of what their group made.From there, the group collectively decides on one, merges, or re pre-forms this step.

Refine the Object Model

Does not apply in the first circuit, but in those that follow, there’s a highpossibility that the Object Model will need updating for new changes.This step takes advantages of those changes and re factors and appliesthem to the Domain Model.

Define Complex Model Elements

When necessary, label the elements used in diagrams so that they canbe easily understood at a later date.

The exit condition from this process to the next is checked by a2Assessment of both internal and external elements. This is checkedby the domain experts and then reproduced for the customer to assessthat what will be preformed is satisfactory.

Upon completion, there should be:3

• 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 ListThe shortest to define, the Feature List is built after the Model has beendefined. Using the programmers from within the model team, the teamshall identify feature sets from the domain model developed from theWalkthrough. Each area is decomposed into activities that eventuallyform steps to solve a particular problem. Each “feature” is worded in away that clients understand, using a template of action result object.

Each feature should be preserved to be completed within 2 weeks,2to 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 weeksto complete, the feature must be broken down into n sub-features untilit satisfies this condition.

Again, the exit condition is set by preforming internal and external 3assessments where the feature list is verified by the domain expertsand customer.

Once this stage is completed, there should be: 4

• List of Subjects

• For each subject, a list of activities that fall under the subject

• For each activity, an associative feature to satisfy the necessaryconditions.

6.1.3 Plan By FeatureOnce their is a feature list, a planning team is formed from the develop-ment 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 isrequired for the milestone

• Preforming DSDM’s MoSCoW on the above criteria to ensure thatthe application’s most essential features are placed at the front.

Chief programmers are assigned ownership of business activities 2(or a batch of features). The assignment weighs in on the developmentsequence, dependency of features, load of programmer, and the com-plexity of the coding.

Classes shall be assigned to developers to supervise the develop- 3ment of the features. As with the chief programmers, classes are as-signed considering the complexity, balance, usage, and sequence theclasses are used.

At the end of this process, the following documents should have 4been produced:

• Activities have deadlines

• Chief programmers are assigned to business activities

• Developers are assigned to a list of classes.


6.1.4 Design by FeatureFor every feature, this process is preformed. It is also under this pro-cess that the actual feature is prototyped.

To start, a feature team shall be formed from team members, un-2der the recommendation of the Programming Authority. The option ofpreforming a preliminary Domain Walkthrough and review of documen-tation shall be decided collectively by the feature team. At this point,the team shall develop detailed sequence diagrams to illustrate pro-gram flow, and each document checked into the versioning system fortracking purposes. After preforming the sequence diagrams, the Pro-gramming Authority shall review the generated artifacts and refine theObject Model. Finally, the feature team shall write out a class listingwith prototypes for methods, placing class and method documentationabove each prototype. The Documentation Authority shall aggregatethe documentation from the source code into API documentation forthe other members.

The feature team, before moving on, shall review all the artifacts3generated and validate that the discussions preformed match.

Upon leaving the following artifacts shall have been generated:4

• A document describing the package developed

• A document specifying all referenced material used in the devel-opment

• Sequence Diagrams illustrating program flow

• Updated Object Model

• Generated API Documentation

• Outlined prototypes of what needs to be coded

6.1.5 Build by FeatureThis process preforms the steps for coding and implementing individualfeatures.

First, the feature team shall implement the required classes and2methods. After completion, the code shall be inspected for defects,removing them before proceeding. Then unit testing is preformed tovalidate that the produced code evaluates as specified by the docu-mentation. Then the code is tested for any logical defects which resultsin unexpected execution. Once the above elements are complete theChief Programmer reviews the activities and promotes the feature intothe build.

Upon completion the following documents shall be completed:3

• 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 eventstaken.

6.2 Methods, Tools, and Techniques

6.2.1 Modeling

D3 will adhere to the FDD best practices outlined in A Practical Guideto Feature-Driven Development.

Domain Object Modeling (DOM)

Identifying and building class diagrams within the project domain. Eachobject is assigned a stereotype, relationships with cardinality, and ba-sic operations (methods). In addition to developing the class diagrams,sequence diagrams shall be provided to illustrate common behaviorand workflow. The modeling shall be preformed using color to applyvisual emphasis on the model.

The information for forming the DOM shall be performed by the 2system analysts and developers, and the information shall be obtainedthrough the Domain Expert.

Develop by Feature (DbF)

Features are the components in which Hot Sticks will be developedupon. 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 respon-sible for and to manage.

Feature Teams

Teams shall be formed between class owners to collaborate on how tosatisfy a feature. The teams are not to be mutually exclusive, and thedevelopment shall be preformed in the open.

Inspection

Once a week, the development process shall be inspected by the cus-tomer representative during the presentation of the Weekly ProgressReport. This covers coding inspection, documentation consistency, andthe development cohesion between the two.


Regular Build Schedule

Every day shall result in a build. Each build shall have a high leveldescription of changes made, supplemented with a bug tracking systemfor storing detailed information about the changes.

6.2.2 Documentation

The format and standard of documentation will be illustrated in An-nex A.6

6.2.3 Tools

Documentation

Developers will be collaborating documentation distributively over theInternet via the dokuwiki web application. Upon a major phase comple-tion, the wiki shall be converted into a hard document using the LaTeXtypesetting engine. A PDF of each of these periods shall be placed on-line in the dokuwiki system. Hard copies are produced on every releaseversion of Hot Sticks.

Coding

Program code will be made available through the use of a mercurialrepository. MS Visual Studio will handle build, compilation, linking,unit testing, debugging, and packaging of all source code, and MSGame Studio will handle the XNA libraries and the transfer of the pro-gram to the XBox system.

Bug tracking will be preformed using the Mantis Bug Tracking sys-tem.

6.3 Infrastructure Plans

6.3.1 Client Software

Each member is responsible for establishing and maintaining their ownpersonal infrastructure.

Each member of the Programming Unit shall acquire a Microsoft Vi-2sual Studio 2008 with XNA Game Studio 3.1 for project developmentunder Microsoft Windows XP, Microsoft Windows Vista SP1, and Mi-crosoft Windows 7. In addition, each member wishing to participate insource code evaluation shall need to use a Subversion client, in partic-ular the TortiseSVN client.

The Documentation Authority shall use TeX Live 2009 to compile3

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 4Project 2007.

6.3.2 Server Software

The project shall use a LAMP webserver with libGD and LaTeX pub-lishing capabilities, and a server to host subversion repositories. Bothresources will be implemented and managed by the DocumentationAuthority.

These servers shall be used for hosting project content including, 2

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 itto the affected team members and illustrate the features that the soft-ware provides. After proposing this content, the affected members shalldemo the software for one week, and then come upon a decision byway of vote determining if the new software should be accepted intothe project or to reject the software.

6.4 Product Acceptance Plan

Product acceptance criteria shall be set forth in this subsection. Allstakeholder policies shall be defined herein.

Project deliverables specified in Section 1.1.3 of this whitepapershall be delivered to all stakeholders. The following represents deliv-ery specifics for each project deliverable.


6.4.1 IEEE SPMP DocumentThis document shall be tendered to customer representative on De-cember 14, 2009. The acceptance of the whitepaper shall be deter-mined by quality specifications delivered by the customer representa-tive at project inception. Customer representative shall be sole judge ofwhitepaper acceptance.

6.4.2 IEEE SRSThis document shall be tendered to customer representative on April27, 2010. The acceptance of the whitepaper shall be determined byquality specifications delivered by the customer representative at projectinception. Customer representative shall be sole judge of whitepaperacceptance.

6.4.3 IEEE SDDThis document shall be tendered to customer representative on April27, 2010. The acceptance of the whitepaper shall cover the detaileddevelopment elements of each utilized class, and illustrate relationsand the conception of pseudocode for physical code generation.

6.4.4 Hot Sticks ApplicationThe completed gaming application Hot Sticks shall be delivered to cus-tomer representative on April 20, 2010. Acceptance criteria shall bedefined as,

• Demonstration of the final working product in form of a final re-view, conducted on or before April 20, 2010. This review shalldemonstrate fulfillment of product specifications set forth in thisrequirement.

• Completed application shall be reviewed for both functional re-quirements and non-functional requirements specified by the cus-tomer within the documents accepted by customer representa-tives.

Customer representatives shall be sole judge of product acceptance,2based on criteria set forth in whitepaper deliverables accepted by cus-tomer representatives.

Chapter 7

Supporting Process

7.1 Configuration Management Plan

Scope

All items identified in Section 1.1.3 shall be considered as configurationartifacts. 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 userorganization shall be defined as Microsoft Game Studios. User organi-zation shall be in direct communication with development team. Inter-face between user organization and development organization shall beachieved 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 theentire organizational structure of the development team as defined inSection 4.3. The user organization representative shall be responsiblefor the determination of acceptance of configuration management itemsfor baseline purposes.

Interface Management

There shall be no external organizational entities.

Implementation

Baselines shall be established weekly, as defined in Section ??. A soft-ware review board shall consist of all entities identified in Section 4.The board shall convene weekly and more frequently if schedule slipsoccur.

7.1.2 Configuration Identification

Conventions

Naming and labeling conventions are to adhere to the specificationsoutlined in Section ?? and in Annex A.6.

Baselines

All configuration items shall be defined as new to the work entities. Nopurchased or reuse software items shall be included in any deliverableentities. The hardware environment for all configuration items shall beidentical. The development environment is defined in Section ??.

Configuration Items

IEEE SPMP Document A deliverable whitepaper. Tools required willbe word processing software and documentation wiki system. Accep-tance criteria is defined through the user representative illustrated inthe syllabus of University of Michigan – Flint, Course No. CSC 383.

IEEE SRS Document A deliverable whitepaper. Tools required willbe word processing software and documentation wiki system. Accep-tance criteria is define through the user representative illustrated inthe 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 beword processing software and documentation wiki system. Acceptancecriteria is defined through the user representative illustrated in thesyllabus of University of Michigan – Flint, Course no. CSC 483.

Hot Sticks Application A deliverable Software Product. Tools re-quired shall be Microsoft Visual Studio, XNA Game Studio, and XBox360. Acceptance criteria is defined through the user representative il-lustrated in the syllabus of University of Michigan – Flint, Course no.CSC 483.

Hot Sticks Weekly Iterations A demonstration of the software itera-tion. Tools requires shall be Microsoft Visual Studio, XNA Game Studio,and XBox 360. Acceptance criteria is defined through the user repre-sentative 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 wikisystem listed in Section ?? and Section ??. The source code con-trol shall be implemented through use of Subversion mentioned in thesame sections.

Levels of Authority

Changes to a baseline shall be controlled by multiple entities, definedby the product itself. Any configuration item baseline may be changedby the project manager as well as the user representative. Specificitems may be changed by the following personnel:

IEEE SPMP Document The Documentation Authority shall have au-thority to effect baseline change.

IEEE SRS Document The Documentation Authority shall have au-thority to effect baseline change.

IEEE SDD Document The Documentation Authority shall have au-thority to effect baseline change.

Hot Sticks Application The Programming Authority shall have au-thority to effect baseline change.


7.1.4 Tools, Techniques, and Methods

The Tools and Methods for configuration management are previouslydefined in the above subsections.

7.2 Verification and Validation Plan

In this section, includes the verification and validation of the softwareproject including scope, tools, techniques and responsibilities for theverification and validation work activities. For instance, verifying thescope of the project which is making a pool video game for MicrosoftXNA environment for XBox console and delivering each piece of work-ing product in the next semester to the Microsoft Game Studios repre-sentative. As a professional software team we must validate and verifythat each deliverable of our software system meets the user require-ment, review it in our next scheduled meeting for the next iteration,what we have delivered so far to our customer and if the customer haschanged software requirements then we should implement the require-ments changes into our existing software system for our customer stan-dards and attributes. Also verification and validation plan includes theobjectives to find defects and determine if the required functions andattributes are built into the software system.

7.3 Documentation Plan

Documentation for source code development shall be processed usingDoxygen documentation generator. The Source code highlighting shallbe generated via GenSHi documentation highlighting system for thewiki system, and the listings package with a custom stylesheet insidethe LaTeX version. Source code will not be delivered in hard copy form,but the API documentation shall be made available to all project mem-bers upon request. Each entry in the SCM is required to have a revi-sion summary explaining what was changed and have an undersignedwhom is responsible for the check-in.

Documents that these elements persist to are itemized in Section ??2with 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 adhere2to the above specifications. Testing shall occur on each project iter-ation 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 betweenelements.

7.4 Quality Assurance Plan

This checklist is provided as part of the evaluation process its purposeis to assure that documents achieve the highest standards relative toformat, consistency, completeness, quality, and presentation. To en-sure the quality is maintained and achieved in developing each featureof the FDD model the following checklist must be ensured at all times.

Quality assurance combines all elements of planning, developing 2and testing of the features.

7.4.1 Initial phase1. 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


19. Evaluate Product Marketing Management

These checks are to be preformed in real time and by all develop- 2ment team members. Should a change not satisfy the above criteria,the user whom identified the issue shall contact the the owning au-thority and request it to be changed. The authority shall distribute thisinformation to the responsible class owners and monitor the progressof the change.

During each phase, the quality checklist must be addressed and2possibly 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 phaseof the software, and they are held every two weeks and also wheneverthe need arises to hold them for the benefit of the software development.

During the life-cycle of the software development, the following typesof 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 require-ment analysis for developing a particular feature, and also thethe general requirements for the software along with methods ofimplementation to achieve them.

3. Design Review: Team members see the design requirements of theproduct, verify the approach decided by the team and discuss onany new developments that would be required.

4. Preliminary Design Review: This is the pseudo code testing reviewof the product features, the team gets to see the working demo andanalyze the possibilities of improvement and arrive to conclusionsabout the product.

5. Critical Design Review: During the critical design phase of a fea-ture, the team reflects on any drawbacks or additions the designrequires or that can be included for over all high performance.Any problems are critically analyzed, brute force methods used ifnecessary 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 ensureproduct 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 cus-tomer or business partner and feedback is accepted. Based on thefeedback given the product is then subjected to one final modifi-cation routine in accordance with the demands.

8. Post-Implementation Review: Once the product has gone throughall the stages of development, design, the team decides the mar-keting factors of deploying the product. This involves product pro-motion ads, legal documents, user manuals etc.

9. Informal reviews: Depending on the kind of situation that theteam face during the product development, design phase, infor-mal reviews will be held just to handle the situations. This couldinvolve issues relating to less contribution from a particular teamor individual, wrong approach taken despite the specification dis-cussed etc.

Audits are conducted for the product and will be scheduled accord- 2ingly informing the entire team of the time and requirements to com-plete before them. A review report is maintained so that all the dis-cussed topics are logged and distributed to the team in the CapstoneProgress Report document, after each session to facilitate a history ofperformed tasks. The software shall be very reliable if the team followsthrough all these reviews diligently.

7.6 Problems Resolution Plan

7.6.1 Human Resources

Problems between human personality elements shall be managed bythe project leader. Should a severe issue arise, the project consultantmay inject or deject the personnel from the project.

7.6.2 Documentation

Documentation issues which arise shall be solved by the Documenta-tion Unit by way of majority vote.

7.6.3 Source Code

Problems and other issues involving the source code shall be submit-ted via the bug tracking system listed in Section 6.2 and are refereedto as tickets. The term “issue” is used vaguely in this system, and shallbe used for reporting both new additions to the program, or injecteddefects. Each problem shall have a date issue found, due date, cate-gory, the level of reproduction, a reporter, a programmer assignment,


resolution status, estimated fix time, problem summary, detailed issuelog, and miscellaneous files which assist in illustrating the problem.

Each problem will have a modification log which tracks all changes2to each ticket. On each ticket resolution, a hard copy of the ticket isattached in Annex A.6

7.7 Subcontractor Management Plan

Subcontracting shall not be permitted as per user representative con-ditions set for attribution illustrated through “Academic Misconduct”.

7.8 Process Improvement Plan

This section of SPMP shall include basically the improvement assess-ing mechanism for the project and determine what areas need to beimproved and implement this improvement plan, which means in ourproject it will not only be fixing bugs in LOC (lines of codes) but assurehow to implement customer issues into the system to make it evolve tosuit customer requirements. For example, if the balls on our pool gamehappen to appear larger than the customers expectation then it will bebrought to attention in the next meeting with a determination of how tochange the size of the balls. Similarly, if the customer wants the tablesize to be change or the pool stick size or color then we can decide howto implement such changes into our system.

Chapter 8

Additional Plans

8.1 Intellectual Property

All details involving Intellectual Property of this document is specifiedby the University of Michigan’s policy to student projects. The releaseand distribution of private information about the personnel that haveinvested time in the project shall be managed by the same organization.

Should a problem arise with Intellectual Property ownership, con- 2sultation by the Project Manager and Project Supervisor shall be pro-vided to the involved user.

8.2 Acquisition of Staff

Upon the addition of staff in the project, the Project Manager and ChiefDocumentationist shall provide access to the SPMP, SRS, and the his-tory of SDD documents to the staff member. In addition, the staffmember shall undergo three training seminars,

Project Vision Seminar where the goals and accomplishments of theproject are addressed

Project Documentation Overview where a generic view of how docu-mentation shall be used in the project

Project Programming Overview where a generic view of how program-ming 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 ofcreating a cross platform pool game over the course of specificationsdirected underneath the IEEE standardization corporation. This gen-eralization shall specify exactly what and how the Hot Sticks projectshall be composed of and break down each individual component suchthat guest developers can obtain a proper image and philosophy for theproject as discussed in detail inside the Hot Sticks SPMP document.This SRS document shall encompass descriptions of each componentin the running head revision of Hot Sticks development. Albeit, thisdocument shall not describe low level constructs of a given language,such as the meaning of a for-loop, or other source code language prim-itives.

1.2 Scope

This specification shall apply to the Windows Vista, Windows 7 andXBox 360binaries to be produced, as outlined in the Software Designand Project Plan documents for the Hot Stickssystem. The goal of thisproject is to develop a game that is user friendly that is delivered in aunique way, with the End User’s satisfaction being the primary goal inmind.

1.3 Definitions, Acronyms, and Abbreviations

A feature is any form of user, system, query, or reaction that requiressome form of manipulation on the behalf of developers. Note that thisproject follows Feature Driven Development (henceforth FDD), thus

55

56 CHAPTER 1. INTRODUCTION

development is centric to this concept. The term Business Activityas specified in the FDD process and referenced in Hot Sticks SPMPwhitepaper illustrates a series of features to accomplish a task.

This document will use the terms Milestone, Business Activities and2Phases interchangeably. When such a term is read, understand thatit is a barrier regarding some developmental requirements. This doc-ument makes a careful separation between Milestones and BusinessActivities, where Milestones may contain several Business Activities, ormay split them into two Milestones.

The terms XBox and XBox 360 are used interchangeably, which3should always be understood to mean XBox 360.

1.4 References

This document references one additional specification papers whichwas developed specifically for Hot Sticks. This document is the HotSticks Software Project Management Plan, which illustrates the busi-ness plan for proper development, scheduling, milestone identification,organizational structure of active developers and project leaders, aswell as developmental tools required to complete the project. This doc-ument conforms to the IEEE SPMP 1058-1998 standard, using theclass focused template. This document is still in draft form, thus, dueto this fact, a hard copy of this document is not frequently made. Al-though, the head revision of this document is made readily availableonline for all developers in the Hot Sticks system in a wiki format.

Frequently, the constructs of FDD are used throughout this doc-2ument. The FDD specification can be located on Nebulon’s website.A more detailed document illustrating FDD can be found in the bookA Practical Guide to Feature Driven Development 1st edition written byStephan Palmer and John M. Felsing.

An additional document that would facilitate fluency in reading would3be the OMG OCL 2.0 draft specification document, which is what theconstructs of pseudocode utilized in this document was based upon.This document is freely available from the OMG website.

1.5 Overview

This document shall now discuss the specification vision via descrip-tions, and itemize how each component of design shall be designed.

The description section shall explain the project vision and defini-2tions on why such views are made in the development. In addition, thedescription shall itemize all the required features to be performed ina 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 compo- 3

nent in the system shall operate. This is done by way of sequence, ClassResponsibilities Collaborator (CRC) cards, and class diagrams, anddefining attributes and methods belonging to the associated classes.Pseudocode shall be used to explain the general flow of the module andprovide additional clarity.

Chapter 2

Overall Description

2.1 Product Perspective

Hot Sticks is a stand alone game installable on Windows Vista or Win-dows 7 and XBox game consoles. It is a single player or multi playerenvironment to be run on a single machine. The game requires a videocard compatible with XNA’s Game Studio or the latest version of Di-rectX, to execute efficiently. The game is compatible only with Windowsand not other operating systems. The game I/O controllers are the joystick and keyboard.

User interface, which comprises of the display screen and the game 2loaded, is very easy to understand. The layout and the color of the userinterface is very appealing. The user shall be able to learn directionsfor game play using the available help option, which shows the userwhich controller element is used for which action. The system displaysthe exact output as per the chosen element of the game controllers.

The hardware interface for the system, since it runs on both PC and 3XBox 360 console, are all the hardware that are required to connectthem. 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 isdivided by conceptual blocking. Each feature shall be specified by themodel 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 addi-tional 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 fromStick Animation.

• Update Ball Force if Stick Enabled from Stick Animation.

• Update Ball Velocity if Stick Enabled from Ballshot Input signalon 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 61

2.2.2 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 StateManager

• 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 in-cludes 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.


• Resume Game State to Previous State from Pause Screen in GameState 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 physicssettings, and other various configurations. In addition to physics, theuser shall be able to change the number of balls, game rules, andgeneral 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 abilityto replay games and have the capabilities to track backward through aprevious saved game.

2.2.6 Milestone 6: Local Multiplayer

This phase shall refactor the product to allow multiple users to play agame at once with separate controllers. This includes creating compet-itive games where players play against one another.

2.3. USER CHARACTERISTICS 63

2.2.7 Milestone 7: Network MultiplayerThis phase shall refactor the product to allow multiple users to play agame at once using separate XBoxconsoles within XBoxLive.

2.2.8 Milestone 8: Artificial IntelligenceThis phase shall refactor the product to enable agent monitoring andinteractions.

2.2.9 Milestone 9: Third Dimension

This phase shall refactor the product to work in three dimensionalspace. This includes the addition of camera angles and views, andball jumps.

2.3 User Characteristics

A wide range of people varying in gender, age, and nationalities are theusers of this game system. The common characteristics required of theusers 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.


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 understandingthe English language interface. It is also assumed that both externalhardware and software are functioning properly.

The project depends on user input through a joystick or keyboard2interface which is controlled either by the XBox or a Microsoft WindowsOS platform.

2.6 Apportioning of Requirements

In accordance to the FDD process, work shall be divided class-wise. Alldocumentation matters in regards to classes are to be held responsi-ble by the owning party, and shall be proofread by the documentationauthority 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 andbinary versions of Hot Sticks. The first is a player at the XBox unititself. The second is a player at a PC computer. These interfaces game-play elements such as controller inputs and file data. In response, HotSticks sends both of these interfaces display and reaction data such asforce feedback.

The second interface is user at Visual Studio, which is used by de- 2velopers, where code is deployed to the XBox unit and debug data isfed back to the development environment.

These interfaces are illustrated via figure 3.1. 3

3.2 User interfaces

User interfaces shall be designed as reactive and animated such that itis pleasing to the eye. The sport of pool is known for it’s smooth game-play with hard colors and distinct designs of game elements. Figure 3.2and Figure 3.3 shall be the baseline for user interface placement anddesign.

3.3 Hardware interfaces

Hot Sticks shall be extremely flexible in game input. Users shall beable to utilize keyboard, mouse, and/or gamepad input devices to in-teract with all necessary controls for interacting with the system. Theseinterfaces have libraries provided by XNA for handling signal input.

65

66 CHAPTER 3. SPECIFIC REQUIREMENTS

Hotsticks

User@Microsoft Visual

StudioPlayer@Xbox

Controller Input Game Code

Display Output Debug Data

Player@ComputerDisplay Output

Keyboard/Mouse/Gamepad

Input

Figure 3.1: Hot Sticks Context Diagram

3.3. HARDWARE INTERFACES 67

Figure 3.2: Primary Menu and Table Design


Figure 3.3: Primary Game Elements and Title Screen

3.4. SOFTWARE INTERFACES 69

3.4 Software interfaces

The primary and only software interface this project shall use is theXNA game libraries provided by Microsoft. These libraries provide ex-tensive functionality on generating graphic primitives, interfacing userinput, and control constructs. The version this project shall use ver-sion 3.1 of XNA Game Studio provided by Microsoft

3.5 Communications interfaces

Communication interfaces are provided inside the XNA game librariesspecified in the software interfaces. This inherently means utilizing aWindows Live ID associated with an XNA profile shall be needed fordeployment. All management of this interface shall be handled by Mi-crosoft.

3.6 Classes

The identified classes for the Hot Sticks development can be seen inFigure 3.4

3.6.1 Artist

Owner: Rob The artist class offers the capabilities for drawing prim-itives, compiling view elements on a canvas, applying textures, andvisually 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


1

1

1 1..4

11

1

1

1

1

+LoadContent()

+UnloadContent()

+Initalize()

+Update()

+Draw()

-DBase : GameContent

-MenuData : Menu Content

Game

+MoveCueBallPosition()

-CueBallLocationUpdate : Vector3

-UpdateCueBallPosition : bool

BallManager

+UpdateStick()

StickManager

+CalculateBallBallCollision() : decimal

+CalcluateBallTableCollision() : decimal

+AdjustBallSpeed() : Ball

Physics

+SetFreezeLevel()

+HasShot() : bool

+PlacementDone() : bool

+SignalPrepareShot() : bool

+Angle() : float

+GetForce() : float

+DirectionalShift() : int

+DirectionalMovement() : Vector2

+MenuMovement() : int

+GameSpeed() : float

+MenuSelection() : bool

-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

Input

+Snapshot()

+Go()

-DrawBalls()

-DrawTable()

-DrawStick()

-DrawClock()

-DrawPauseScreen()

-DrawFileMenuScreen()

-DrawTitleScreen()

-DrawExitConfirmationScreen()

-DBase : GameContent

-TraceTime : Vector2

-TraceForce : Vector2

-TraceLevel : Vector2

-StateManager : Game State Manager

-Menu : Menu Content

Artist

-Sprite : Texture2D

-Center : Vector2

-Velocity : Vector2

-Rotation : float

-Scale : float

-Layer : float

-Alive : bool

GameObject

-Cue : bool = False

-Radius : float

Ball

-Barrier : Rectangle

-CuePlacement : Rectangle

Table

-Radius : int

Pocket

+AddBall()

+AddPocket()

+AddTable()

+AddStick()

+AddWarp()

+Balls : Ball

+Pockets : Pocket

+Stick : GameObject

+Tables : Table

+Warp : Warp

+IsMoving : bool

+GameLevel : int

GameContent

1..*

1

1

1..*

1

1..*

1

1 1

1

1

1

1

1

1

1

-ID : int

Warp

+UpdateState()

+Movement : bool

+Scratch : bool

+ScratchLevel : float

+State : GameState

+Pause : bool

+Exit : bool

+LoadSave : bool

+CuePlaced : bool

-Previous State : GameState

Game State Manager

Warp Manager

+Resolve() : GameContent

#DetectCollision()

#BoundaryCheckMovingObjectRectangle() : Vector3

#BoundaryCheckStaticObjectRectangle() : Vector3

#BoundaryRectangle() : Rectangle

#BoundaryCheckObject() : Vector4

#Number Iterations : int

Object Manager

11

1

1

1

*

XNA::Game

1

1

+SetTitleManager()

+SetPauseManager()

+SetLoadSaveManager()

+SetGameSettingsManager()

-Title Manager Data : Title Manager

-Pause Manager Data : Pause Manager

-Load Save Manager Data : Load Save Manager

-Game Settings Manager Data : Game Settings Manager

Menu Content

+WriteData()

+ReadData()

+Serialize()

+Snapshot()

-DBase : Game Content

Persitent Data Manager

1

1

1

1

1

1

*

*

*

*1

1

1

1

-Logo : Texture2D

Title ManagerLoad Save ManagerPause Manager

#SelectOption()

-CurrentOption : int

-ListOptions : string

-Background : Texture2D

-Overlay : Texture2D

-Font : SpriteFont

-Start Position : Vector2

Menu Manager

+UpdateSetting()

Game Settings Manager

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 onthe screen, using upper left hand corner

TraceForce The location in which the inputted force shall be drawn onthe screen, using upper left hand corner.

StateManager Snapshot of the current game state using the GameS-tateManager utility class

MenuContent List of all needed elements to draw menu screens.

Methods

Snapshot Obtains a snapshot of the current game data and state inwhich 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 ballslocated on a table. Each pool ball shall be seen as a radius from aparticular coordinate, and have a uniquely identified BallID. Ball objectclass is a child class inheriting all properties of the GameObject class.

CRC Card

Responsibilities

• Knows

– Ball Radius

– Ball Cue Ball Status


– Warp ID of Warp which ball is interacting with (during Warp-Ball collision)

– Ball Identification number

– All GameObject Data

• Does

Collaborators

• None

Attributes

CueBall A Boolean value representing if a given ball is to be identifiedas a CueBall or if it is a normal ball.

Radius Integer that represents the number of pixels the ball’s radiusshall be.

IsCue Boolean value which represents ball status as the cue ball.

WarpingWarpID Integer ID number of Warp object during Warp-Ballcollision.

BallID The identification number of the Ball object.

Methods

• None

3.6.3 Ball ManagerOwner: Bill The Ball Manager class shall manage each ball that existsin a game and handle all positional updates and provide a signal toshow 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 positionfrom public methods.

UpdateCueBallPosition Boolean value to indicate whether Cue ballposition has to be updated.

Methods

Resolve Public function used to initiate ball management functions.

DetectCollision Detects object collisions between all game objects. Col-lisions are then resolved utilizing the Physics class methods.

MoveCueBallPosition Updates changes in the cue ball position.

3.6.4 GameOwner: Rob The game class is a generated class that must be usedfor XNA games to properly launch. The class executes an initial loadof libraries and data, then runs the update method every sixtieth of asecond, 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


– 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 game-state 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 ofpresence 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 Magni-tude 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


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 haveVelocity Magnitude greater than zero.

GameLevel Integer value to indicate current table level of play.

WarpPairCounter Counter used to add Warp objects in multiples oftwo.

Methods

AddBall This function is used to add Ball class objects to the list ofBalls.

AddPocket Function to enable the addition of pocket class objects tothe list of Pockets.

AddTable Method to enable the addition of Pocket class objects to thePockets list data structure.

AddStick Method to enable the addition of GameObject class objectsto the Sticks list data structure.

AddWarp Method to enable the addition of Warp class objects to theWarps list data structure.

3.6.6 Game Object

Owner: Rob The Game Object class is a parent class for all graphicalobjects in the Hot Sticks system. It acts as a dataholder for objecttexture, dimensions, scaling, and other factors.

CRC Card

• Knows

– Texture of Object

– Position of Object

– Type of Object

3.6. CLASSES 77

– Object’s 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 object’s cen-ter 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 sprite’s center.

Velocity A x,y pairing where x represents the direction in radians, andy 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 spritefrom it’s original size

Layer Specifies the order in which the graphic shall be painted. Smallernumbers are painted after larger numbers.

Alive Boolean value to determine object visibility

Methods

None

3.6.7 Game Settings ManagerOwner: Bill The Game Settings Manager class is an inherited classfrom Menu Manager. It handles all user-configurable game settings.The class handles the display of menu options as well as the facilitationof menu selections based on state and game content data.


CRC Card

Responsibilities

• Knows

– Menu Manager Data

• Does

– Updates Game State indication flags based on user selec-tions.

– Facilitates Game Content changes based on user selections.

Collaborators

• None

Attributes

None

Methods

SelectOption Updates game state flags dependent on user menu itemselection.

UpdateSettings Enacts the game content changes indicated by usermenu item selection.

3.6.8 Game State ManagerOwner: Bill Manages the game states of the Hot Sticks game, actingas 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 inmotion.

– Sets game state to allow Cue placement when ball motionstops.

– 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 ballscratch.

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 makecue placements and shot placements accordingly when ball arenot in motion.

3.6.9 InputOwner: 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.


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 agiven shot.

Force A measure to specify the strength of a given shot.

FreezeLevel Holder for determining specific input availability. Thisfunctions 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 key-board

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 thescreen.

SignalPrepareShot Returns true when user is starting to make a shot

DirectionalShift Returns a delta value which is used to change thecurrently visible level

DirectionalMovement Returns two values to represent a delta move-ment that is performed when a user needs to place a ball on thetable.

3.6.10 Load Save Manager

Owner: Bill The Load Save Manager acts as a controller for screendisplay when saving and loading a game. When either the save or loadoption is fired, it updates the state of the game.

CRC Card

Responsibilities

• Knows

– State of game save

– Menu Manager Data

• Does


– Knows it’s own state

Collaborators

• None

Attributes

None


Methods

Select Option Updates game state flags dependent on user menu itemselection.

3.6.11 Menu Content

Owner: Bill The Menu Content is the information holder class con-taining all menu management class objects for Hot Sticks game appli-cation.

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 andmanagement.

PauseManagerData PauseManager object for pause screen content andmanagement.

LoadSaveManagerData LoadSaveManager object for LoadSave menucontent and management.

SettingsData GameSettingsManager object for altering game play set-tings.

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 at-tribute.

3.6.12 Menu Manager

Owner: Bill The Menu Manager is the parent class for all menu classobjects of the Hot Sticks game application. It maintains all data andmethods relative to menu management.

CRC Card

Responsibilities

• Knows

– The option of a menu which is currently pointed to by themenu 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


Attributes

CurrentOption The integer value of the currently indicated option ofthe current menu.

ListOptions List of alphanumeric strings describing current menu op-tions.

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 selec-tion choices.

3.6.13 Object ManagerOwner: Bill Manages GameObject, their movements and collision.Ensures that ball (in motion and at rest) are contained inside specificboundary 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 theUpdate method.

Methods

Resolve A public virtual function that returns objects of GameContentand is to be overridden.

DetectCollision A protected virtual function that detects collision ofobjects relevant to the class and returns objects of GameContent.

BoundaryCheckMovingObjectRectangle Detects if a moving objecthas passed the rectangular boundary set by a rectangle

BoundaryCheckStaticObjectRectangle Resolves a static object posi-tion to within a specified boundary.

BoundaryRectangle Creates a barrier that is less in each direction bythe radius of an object.

BoundaryCheckObject Ensures two mobile objects to occupy differentphysical space at any instant.

3.6.14 Pause Manager

Owner: Bill The Pause Manager class is an inherited class from Menu-Manager. It handles game pause options and selections. The classhandles the display of menu options as well as the facilitation of menuselections based on state and game content data.

CRC Card

Responsibilities

• Knows

– MenuManager data

• Does


Collaborators

• None


Attributes

None

Methods

SelectOption Updates game state flags dependent on user menu itemselection.

3.6.15 Persistent Data Manager

Owner: Bill The Persistent Data Manager class handles all persistentdata 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 datato 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 datato 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 selec-tion initiated.

StorageDeviceSelected Flag to indicate that the file storage device se-lection has been completed.

StorageDeviceEndInitiated Flag to indicate the file selection end state-ment has been initiated.

Methods

SnapShot Method to set the PersistentDataManager game content tocurrent game content.

Initialize Method to initialize file storage option selection and file cre-ation.

WriteData Method to initiate a write of game data.

ReadData Method to initiate the read of game data from persistentstorage media.

PackGameSaveData Method to convert the game content to a serializ-able format.

UnpackGameSaveData Convert the saved data to the structure formatand return the modified GameContent data

3.6.16 Pocket

Owner: Bill An information holder class. It contains the bounds andlevel a given pocket shall be drawn.


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 betweengame objects with other game objects and boundary rectangle, adjustsball 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 ob-jects which are undergoing collision and manipulate the collisionby way of redirection.

CalculateObjectRectangleCollision Takes in a Ball and a Table Boundwhich are undergoing collision and manipulating the collision byway of redirection.

AdjustObjectSpeed Adjusts the speed of a given ball by way of friction.

CalculateAbsoluteVelocityFromComponentVector Computes the di-rection and magnitude velocity vector from component vector.

CalculateAbsoluteAngleFromRelative Computes an absolute refer-ence angle from a reference angle and an angle relative to it.

CalculateComponentVectorFromVelocity Computes a component vec-tor from direction and magnitude vector

3.6.18 Stick ManagerOwner: Bill Stick Manager handles all aspects of cue stick movement.It will update stick position and velocity. Stick Manager will also handleStick 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 thepool stick as well as the Cue Ball.

3.6.19 TableOwner: Bill An information holder class. It contains the bounds andlayer identity for the table in question.


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 instanti-ated 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 gameapplication. 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 tablelevel 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 teleportto upon collision.

Methods

Resolve Public method to resolve all Warp object activity and Warp-Ball 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. Itmanages warp movement and collisions between them.


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 fromwarp velocity data.

DetectWarpWarpCollision Method to handle Warp collision with otherwarp objects as well as table objects.

MoveWarpPosition Warp Manager method to move the last Warp ofthe 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 SDDSection 4.

3.8. PERFORMANCE REQUIREMENTS 93

3.8 Performance requirements

The Hot Sticks application performance shall conform to the measuresset forth in this section. All performance requirements are defined asfollows. Any performance issue not listed is not considered critical forthe software product, as the following list is inclusive of all performancerequirements.

The Hot Sticks system shall not exceed 130 of a second between Draw

events.The Hot Sticks system shall not exceed 1

30 of a second between Up-date events.

The Hot Sticks system shall support High Definition Graphics up to720 lines of vertical resolution and 1280 lines of horizontal resolution.

The Hot Sticks application shall support two-dimensional graphicalgame display.

The Hot Sticks system shall support at most two simultaneous play-ers with no more than a 5% decrease of any of the above performancerequirements.

3.9 Design constraints

The Hot Sticks system is designed for implementation on both the Mi-crosoft XBox 360 gaming console and Microsoft Windows operatingsystems. This constraint limits the implementation programming lan-guage to C#. Also, this limits the software Integrated DevelopmentEnvironment to Microsoft Visual Studio and Microsoft XNA Game De-velopment. Microsoft Windows Operating System support shall be de-signed for and limited to Windows Vista and Windows 7 Operating Sys-tems.

3.10 Software system attributes

Hot Sticks system attributes shall be specified for the following cate-gories; Reliability, Availability, Security, Maintainability, and Portabil-ity.

3.10.1 Reliability

The Hot Sticks system shall be required to have the ability to completean initiated game of pool 95% of the time. Completion of the game shallbe defined as the ability to continue player interaction with the systemuntil all pool balls have been eliminated from the playing field. Eachindividual instance of a game must be able to be completed within twohours of inception to qualify as a completed game.


3.10.2 Availability

The Hot Sticks application shall be capable of initiating a game session95% of the time such session initiation attempts are made.

3.10.3 Security

The Hot Sticks application shall employ the following methods to pro-mote system and and environment security. All network aspects ofthe Hot Sticks system shall conform to XNA Creators Club specifica-tions for network application. The Hot Sticks application shall be peer-reviewed by the XNA Creators Club peer-review system before releaseto the general public.

3.10.4 Maintainability

The Hot Sticks system shall be delivered in a way that makes it revis-able using the development tools specified in the above section, 3.5 -Design Constraints. The Hot Sticks system shall make no statement ofwarranty respective of the aspect of system maintainability other thanthe above statement.

3.10.5 Portability

The Hot Sticks system shall support deployment to the Microsoft XBoxgaming console as well as Microsoft Windows operating systems Win-dows Vista and Windows 7. All components and code shall be definedas host-dependent on the above named deployment platforms. TheHot Sticks system shall make no statement of portability to operatingsystems or gaming systems other than those listed directly above.

3.11 Other Requirements

3.11.1 Controller Support

The Hot Sticks system shall provide support for the Microsoft XBox360 gaming controller. This support is to include the Microsoft XBox360 gaming console, Microsoft Windows Vista operating system and Mi-crosoft Windows 7 operating system. Only officially licensed Microsoftcorporation controllers, manufactured directly for Microsoft corpora-tion shall be supported. Third-party controllers licensed by, but notmanufactured for, Microsoft corporation shall not be supported. Thisincludes, but is not limited to, controllers by such manufacturers asMad Catz. Controller support shall only include support for function-ality expressly listed in the game design.

3.11. OTHER REQUIREMENTS 95

3.11.2 Keyboard SupportThe Hot Sticks system shall provide keyboard support. Keyboard sup-port shall be limited to the Microsoft Windows Vista and Microsoft Win-dows 7 operating systems. There shall be no keyboard support forthe Microsoft XBox 360 gaming console. Keyboard support shall beprovided only for officially licensed Microsoft Corporation Keyboard de-vices. Officially licensed Microsoft Corporation keyboard devices aredefined as standard English-language keyboard devices manufacturedfor or by Microsoft Corporation for sale in the United States.

All device support shall be exclusively for those devices which areofficially licensed by and manufactured for Microsoft Corporation forsale in the United States.

3.11.3 Language and Localization SupportThere shall be no implied Hot Sticks system support for localization forany country, region or language. The Hot Sticks system shall provideonly English-language support for the United States.

Part III

SDD

97

Chapter 1

Introduction

1.1 Purpose

This Software Design Document details design and implementation de-tails for the Hot Sticks game development project. The intended readingaudience of this document are the project stakeholders as defined inthe Software Management Plan document. These stakeholders are thecustomer representative and the Dynamic Digital Development team.

1.2 Scope

The scope of this document is to define the design of the Hot SticksXBox 360 game application. Design details such as architecture andmodule/object definition shall be detailed within this document.

1.3 Definitions

1.3.1 SynonymsThis 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 andPC software, the two are refereed to as the XBox System or the PCSystem.

1.3.2 TermsFor common terms, please refer to the SPMP Section 3.

99

Chapter 2

References

This document references two specification papers which was devel-oped specifically for Hot Sticks. The first document is the Hot SticksSoftware Project Management Plan, which illustrates the business planfor proper development, scheduling, milestone identification, organiza-tional structure of active developers and project leaders, as well as de-velopmental tools required to complete the project. This reference con-forms to the IEEE SPMP 1016-1998 standard. The second document isthe Hot Sticks Software Requirements Specification, which illustratesa detailed analysis of what each component of the Hot Sticks projectis to be performed to. This document conforms to the IEEE SRS 830-1998 standard. Both document are still in draft form, thus a hard copyof this document is not frequently available. The head revision of thisdocument is made readily available online for all developers located onthe Hot Sticks wiki website.

Frequently, the constructs of FDD are used throughout this doc-ument. The FDD specification can be located on Nebulon’s website.A more detailed document illustrating FDD can be found in the bookA Practical Guide to Feature Driven Development 1st edition written byStephan Palmer and John M. Felsing.

101

102 CHAPTER 2. REFERENCES

Chapter 3

DecompositionDescription

3.1 Class Decomposition

For datatypes, constructors, and passed values, consult the API docu-mentation in Annex A.6.

3.1.1 Artist

The Artist class shall have six private variables which it uses for inter-nal manipulation and contains two public methods for execution. Ingeneral, the public method count should not increase past these two.Additional functionality shall be obtained through extending the twopublic 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 spritesupon.

util A utility font texture used for testing purposes.

TraceForce Location to position text to show the amount of forceimparted on the cueball.

TraceTime Location to position text to show the total elapsedtime 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 tableitself, the pockets that belong to the table, and the currentlyvisible, wormholes and warps.

DrawBalls/0 Draws the currently visible balls.DrawStick/0 Draws the stick at the cueball’s position, correctly

adjusting to the cue’s 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, andcurrent State, to the class for later use.

Go/1 Draws out all objects contained within the data obtainedthrough Snapshot. The function acts as a state determinantfor drawing functions.

3.1.2 Ball ManagerCoordinates all moving Ball objects. It Updates position based on ballposition and velocity, detects collisions between all Game Content ob-jects and ensures all objects are within table boundaries. Ball Manageralso monitors Ball object for movement and notes when all balls arestationary.

Attributes

• private

CueBallLocationUpdate Cue Ball position vector used to updatethe position from method with public access.

UpdateCueBallPosition Flag to indicate the cue ball position hasbeen modified and needs to be updated.

3.1. CLASS DECOMPOSITION 105

Methods

• protected

DetectCollision/2 The Detect Collision method determines if anyGame Content objects have collided. The method will call thePhysics class static methods to resolve any collisions

• public

Resolve/2 The Resolve function is the public function to accessall Ball Manager Methods. First the ball object positions areupdated, then checked for boundary limits. Collision detec-tion method is then called, and the modified Game Contentobject is returned.

MoveCueBallPosition/1 Method to effect a change of cue ball po-sition.

3.1.3 BallAn object which represents pool ball objects. It inherits from the genericGame 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 objectWarpID. If ball object is currently colliding with Warp object,this value represents warp ID. If ball object is not collidingwith Warp object, this value will be negative.

BallID The unique ball identification number.

Methods

3.1.4 Game ContentData holding class which holds all pool game objects. Pool game objectsaggregate within this object.

Attributes

• public

Balls List of Ball objects to be maintained.

Tables List of Table objects to be maintained.


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 movingon 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 ob-ject display.

Attributes

• public

Sprite Holder for object texture.

Position The absolute position of the center of the object with thefirst value being its x coordinate, the second its y coordinate,and the third the table level. The special position of -1 for itslevel 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 beingfirst value, and its y value being the second.

Velocity The current velocity of the object where the direction isthe first value, and the magnitude is its second value.

Rotation The rotational value to apply to the texture, specified bya 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 ob-ject shall be drawn. The larger the number, the lower priorityit has to be drawn.

Alive The visibility of the object.

Methods

None


3.1.6 Game Settings Manager

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 theHot Sticks game application for customized game settingsbased 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 Settingsmenu 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 oc-curred.

CuePlaced Boolean flag to indicated scratched cue ball has beenreplaced 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 gameattribute setting state.

Placement Indicator to signal the entry into placement mode.


Methods

• public

UpdateState/0 Public method to update state of the game basedon GamStateManager attributes.

3.1.8 Game

Primary driver of Hot Sticks system. Every class that requires directaccess 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 inthe content pipeline.


TableSprites The string list where the table sprites are located inthe content pipeline.

BallSprites The string list where the ball sprites are located inthe content pipeline.

PocketSprites The string list where the pocket sprites are locatedin the content pipeline.

WarpSprites The string list where the warp sprites are located inthe content pipeline.

MenuSprites The string list where the menu sprites are locatedin the content pipeline.

Methods

• private

RackBalls/0 Positions balls in a triangular form following poolrules.

• protected

Initialize/0 Allows the game to perform any initialization it needsto before starting to run. This is where it can query forany required services and load any non-graphic related con-tent. Calling base.Initialize will enumerate through any com-ponents and initialize them as well.

LoadContent/0 Load Content will be called once per game andis the place to load all textures and preload positions of thegame content.

UnloadContent/0 UnloadContent will be called once per gameand is the place to unload all content.

Update/1 Allows the game to run logic such as updating theworld, checking for collisions, gathering input, and playingaudio.

Draw/1 This is called when the game should draw itself.

3.1.9 InputUser input abstraction system which obtains input and translates theminto standard input methods used throughout the game.

Attributes

• private

PrepareShot Boolean check value when a user is allowed to pre-pare a shot.


Shot Boolean check value to show when a user has taken a shot.

Exit Boolean test value used to show that the user inputted theexit command.

DeltaAngle A decimal value between -1 and 1 to give in the cur-rent angle.

Force The force in which to apply when a shot has been per-formed.

FreezeLevel Integer value that specifies how to lock out shots tobe taken.

pad The gamepad state the user signaled during the current up-date.

ppad The gamepad state the user signaled during the last update.

keyboard The keyboard state the user signaled during the cur-rent update.

pkeyboard The keyboard state the user signaled during the lastupdate.

Methods

• private

UpDownDirectionalShift/0 Method to return an integer valuebased on D-pad game pad up/down status or keyboard Uor D keys.

LeftRightDirectionalShift/0 Private method to indicate left-rightof d-pad or L-R keys of keyboard.

• public

SetFreezeLevel/0 Sets the Freeze level of the controller equal tozero, meaning all input is accepted.

SetFreezeLevel/1 Set the Freeze level of the controller equal tothe passed value. Zero unlocks all controls, One or GreaterLocks shot control.

SignalExit/0 Tests user input for the required button combina-tion to terminate the application.

SignalPrepareShot/0 Tests user input for preparing to take ashot.

HasShot/0 Tests user input for the required button combinationto preform a shot.

GetForce/0 Returns the force inputted by the user.

Angle/0 Returns a delta value sent from the gamepad left joystickor keyboard directional buttons.


DirectionalMovement/0 Method to return the directional deltacoordinates of the cue ball object.

PlacementDone/0 Public method to indicate if B button was de-pressed 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 menuoptions.

MenuSelection/0 Indication of current menu selection.

GameSpeed/0 Return value to increase or decrease game targetupdate 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 ob-jects for Hot Sticks game application.

Attributes

• public

TitleManagerData TitleManager object for splash screen contentand management.

PauseManagerData PauseManager object for pause screen con-tent and management.

LoadSaveManagerData LodSaveManager object for LoadSave menucontent and management.

SettingsData GameSettingsManager object for altering game playsettings.


Methods

• public

SetTitleManager/1 Method to initialize instance of TitleManagerattribute.

SetPauseManager/1 Set instance of PauseManager attribute.

SetLoadSaveManager/1 Set instance of LoadSaveManager attribute.

SetGameSettingsManager/1 Set instance of GameSettingsMan-ager attribute.

3.1.12 Menu ManagerMenuManager class manages the display content and options selectedfor options menu objects.

Attributes

• public

ListOptions List of alphanumeric strings describing current menuoptions.

Background Background graphic for screen.

OptionIndicator Texture graphic for menu selection indicator ob-ject.

IndicatorScale Scale factor for indicator texture.

Overlay Screen overlay for display of menu content over gamecontent.

MenuFont Sprite menu font.

CurrentOption The integer value of the currently indicated op-tion of the current menu.

StartPosition he screen position to display string menu options.

Methods

• public

SelectOption/1 Public method to enact menu option currentlyin selection.

AddOption/1 Adds a passed string to the option list for the menu

3.1.13 Object ManagerClass manages the movements of mobile Game Object objects and re-solves all problems which may arise from their movement.


Attributes

None

Methods

• protected

DetectCollision/1 Virtual method to detect collision of objectsrelevant to inherited class objects.

DetectCollision/2 Virtual method to detect collision of objectsrelevant to inherited class objects.

BoundaryCheckMovingObjectRectangle/3 BoundaryCheck is amethod to detect if a moving object has passed the rectangu-lar boundary set by a rectangle.

BoundaryCheckStaticObjectRectangle/2 Method to resolve a staticobject position to within a specified boundary.

BoundaryRectangle/2 BoundaryRectangle generates a new rect-angle based on an existing rectangle and an object Radius.The BoundaryRectangle is used to create a barrier which isless in each direction by the radius of an object.

BoundaryCheckObject/6 Method to assure two mobile objectsDO NOT occupy the same physical space at the same time.

• public

Resolve/1 Virtual method for public call. Must be overridden inany inherited class declaration.

Resolve/2 Virtual Method for public call. Must be overridden inany inherited class declaration.

3.1.14 Pause Manager

Pause screen menu for Hot Sticks game application.

Attributes

None

Methods

• public



3.1.15 Persistent Data Manager

The persistent data manager acts as proxy between persistent storageunits 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 gamedata 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 se-lection initiated.

StorageDeviceSelected Flag to indicate that the file storage de-vice selection has been completed.

StorageDeviceEndInitiated Flag to indicate the file selection endstatement has been initiated.

Methods

• private

PackGameSaveData/0 Method to convert the game content to aserializable format.

UnpackGameSaveData/0 Convert the saved data to the struc-ture format and return the modified Game Content data.

• public

SnapShot/1 Method to set the Persistent Data Manager gamecontent to current game content.

Initialize/0 Method to initialize file storage option selection andfile creation.

WriteData/0 Method to initiate a write of game data.

ReadData/1 Method to initiate the read of game data from per-sistent storage media.


3.1.16 Physics

Static operator which performs physical transformations on variouscollisions within the Hot Sticks game. It also controls velocities of ob-jects it is aware of.

Attributes

None

Methods

• private

CalculateAbsoluteVelocityFromComponentVector/1 Method tocalculate direction and magnitude velocity vector from com-ponent vector. Private method used by public Physics meth-ods.

CalculateAbsoluteAngleFromRelative/2 Method to calculate anabsolute reference angle from an absolute reference angle andan Angle relative to it. Private method used by public Physicsmethods.

CalculateComponentVectorFromVelocity/1 Method to computea component vector from a direction and magnitude vector.Private method used by public Physics methods.

• public

CalculateObjectObjectCollision/4 Method to resolve collision oftwo movable objects in respect to velocities.

AdjustObjectSpeed/2 This method is used to adjust the magni-tude of the velocity vector of a moving object.

CalculateObjectRectangleCollision/3 This method alters the ve-locity of an object which collides with a stationary wall.

VelocityBoundaryResolution/1 Method to verify velocity vectordirection and magnitude within boundary limits. Public method.

VelocityVectorAddition/2 Method to add two velocity vectors com-prised of direction and magnitude elements. Private methodused by public Physics methods.

3.1.17 Pocket

Pocket is an object which represents pool pocket objects. It inheritsfrom the Game Object class and adds traits specific to pocket objects.


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 passedto it and modifies the Stick. The Stick is the Game Objectclass instantiation which represents the pool cue stick. Thisupdate method also modifies the Velocity vector of the poolcue ball. This method must only be called when the Ball ob-jects are not in motion.

3.1.19 Table

Table Class inherits from Game Object class. It supplements GameObject by the addition of a bounding rectangle for table boundary anda bounding rectangle for cue ball placement on table.

Attributes

• public

Bounds A rectangular position boxing the table’s furthest bounds

CueBounds A rectangular position boxing where the cue ball canbe placed when a scratch occurs.

Methods

None


3.1.20 Title ManagerSplash Screen menu for Hot Sticks game application.

Attributes

• public

Logo Major texture to apply as the game logo.

Methods

• public


3.1.21 Warp ManagerWarp Manager is a type of Object Manager which manages the Warpobjects of the Hot Sticks game application.

Attributes

Methods

• protected

DetectCollision/1 Method to detect collisions of warp objects withother game content objects.

• private

AdjustWarpPosition/1 Private warp method to move warp posi-tion from warp velocity data.

DetectWarpWarpCollision/1 Method to handle Warp collision withother warp objects as well as table objects.

• public

Resolve/1 Method to resolve any movement of Warp objects andcollisions.

MoveWarpPosition/2 Warp Manager method to move the last Warpof the list of warps while positioning the last added Warp ob-ject.

3.1.22 WarpWarp class is a game object which transports colliding ball objects toother game table levels. Warp is a type of pocket which transports ballobjects to other table objects rather than removing them from all tableobjects.


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 executedsequentially at a variable refresh rate.

3.3 Data Decomposition

This subsection details the data description, structures and methodsfor all data not defined in the module decomposition above. The ap-plication currently does not define or contain any data which has notbeen defined within the module decomposition. The data containedin the identified modules is defined in the SRS Section 3 in the classdefinition 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 areinterdependent from one another.

4.1.1 Sequence Charts

Warping of objects

The Ball Manager receives the update and sends information to theWarp Manager to resolve warp ball collision. The Warp Manager thengets data from the Ball and Warp class through GameContent and findsthe new ball positions according to the warping warp ID that the ball’swarp had. This is illustrated in Figure 4.1.

Warp Warp collision

The warp objects collide with each other and bounce off in the samemanner ball objects collide with one another. The WarpManager re-ceives an update and iterates though the warps to detect warp colli-sions, it then passes the objects to the Physics class to resolve the finalvelocities. This is illustrated in Figure 4.2.

Update Cue Stick

Ball Manager receives update and signals the Ball to detect if the ballis 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 throughgame content to detect when balls pass over warps. This is shown inFigure 4.4

Game Save

From the Menu screen the user selects the game save option, whichis handled by the TitleManager class. The Title manager then signalsthe LoadSaveManager class to call the PersistentDataManager class tosave the current snapshot of the game in the internal file storage. Thisis shown in Figure 4.5

Game Load

From the Menu screen the user selects the game load option, whichis handled by the Title Manager class. The Title Manager then signalsthe Load Save Manager class to call the Persistent Data Manager classto load the game from the internal file storage and passes it on to theGame Content class.

Pause Game

The Game class receives the update and checks with the Input class ifthe game is paused or not. The Input class sends back the feed for thegame state. If paused then Game class signals the Game State Man-ager class that the game has been paused. The Game State Manager


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 inFigure 4.7

Warp Table Collision

The warp manager receives the update from game content, which sig-nals it to access the Warp class to get the warp data. It sends thedata to the Physics class to resolve the warp table collision. This isillustrated in Figure 4.8.

4.1.2 Modules

Game Input-Output Module

The class objects within the module depends on the Game class, whichis the main class to manage the game applications and is containedin the Game Management module. The elements of class objects fromthe Game Management and Game Object modules are required by theArtist class to display the game.

Game Module

The class objects within the module depends on the Game class, whichis contained in the Game Management Module.


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 GameManagement class. The Artist class contained within the Game Input-Output module is required to display the game objects.

4.2 Interprocess Dependencies

The Hot Sticks game is single process based, hence Interprocess de-pendencies does not apply to it.

4.3 Data Dependencies

This subsection details the data dependencies for all data not definedin the Data decomposition. Plans shall be established once the HotSticks project increases in complexity.

4.3.1 Data Flow Diagram

The top level DFD shows the main data flow of the Hot Sticks gameapplication. It can be found in Figure 4.9


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 boundarythey are resolved by the Physics class. When a ball passes on top ofa warp it gets transported to a different level. The frictional force isapplied to adjust the ball velocity at every point in the game. Whenballs approach directly onto a pocket then the ball is set aside sincethe use has scored by putting the ball into the pocket. This is shownin Figure 4.10

Ball Pocket Collision

Ball objects that approach the pocket are set aside from the playingtable since the user has secured the ball by the action. If the ball is acue ball then it is called as “Scratch” and the cue ball is placed againon the table and the cue stick is enabled for the player to make theshot. This is shown in Figure 4.11

Ball Warp Collision

Balls when they go over warps gets transported to a different level. Thewarping ID of the warp is found and the ball is sent to the level pointedout by the warping ID, as shown in Figure 4.12.

4.3. DATA DEPENDENCIES 127

Figure 4.11: Ball Pocket Collision DFD

Figure 4.12: Ball Warp Collision DFD


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 theangle at which the balls hit the table. The Ball data is sent to thePhysics class along with table boundary from the Table class. Physicsthen resolves for the angle of incidence and deflection and gives out thefinal ball direction. This is shown in Figure 4.13

Ball Ball Collision

Ball objects collide with one another and bounce back with differentdirections and velocities depending on the line of contact between them.When ball objects collide, their position vectors and velocity vectors aresent to the physics class to resolve the final velocities and direction ofeach 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 thenprocessed. If the user chooses to save a game, a snapshot of the game issaved in the internal storage of Xbox/Windows PC. If the user choosesto load a game then he browses through a string of names available andloads the game by choosing one of them. The use can also pause thegame, and access both load and save option in the paused state. Theuse if he wishes to terminate the game chooses the exit option and theexit process inside Game class handles the exiting of the game. This isshown in Figure 4.15

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 ele-ments of other classes, making it the primary content pipeline for theHot Sticks application. Content such as balls and warps can have anynumber of elements added to the class, as there is at least one of eachand an infinite quantity within the game. Elements such as stick, ta-ble, and pockets have a constraint of having at least one copy, but havean upper limit.

In addition to this content, the class also must allow access to the 2game data for the manager and drawing methods concerning the pooltable and it’s elements, so it has a single strong connection betweenBall Manager, Stick Manager, and Artist.

Menu Content

Similar to Game Content, Menu Content has data holding attributes foreach visible menu screen. The model chosen for menu interfaces dic-tates that every menu’s data is constructed off of a standard datatypeand is extended to attribute to new additions for the menu. Thus, themenu content has data holdings for each individual screen. As eachscreen is it’s own class, menu content has a strong single associationto 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 classacts as a middle layer class standardizing input commands. As theXBox has a limit of only four controllers, the association has a limit offour elements.

5.1.3 Dependencies

Physics

Physics interfaces with the ball manager in two situations:

• Collision: when two balls collide, physics calculates the neededchanges 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 ofgame, rather than associated with game. The Hot Sticks application iscomposed of a persistent data manager for saving and loading; warp,ball, and stick managers for responding to game events, artist for draw-ing responsive data, and menu content and game content to give accessto the data in the game.

5.2 Process Interface

Interprocess communication shall be achieved by sharing memory throughclasses located in a central content pipeline class. This includes everygame object and acts as a proxy for access, and provides functionalencapsulation for obtaining game data. The XNA platform providesa networking functionality for interconnecting XBox and Windows PCelements using a standard communication interface. Essential dataelements such as player turn, currently visible level, player shot, andgame history shall be sent over the network interface using the contentpipeline class.

5.2.1 User Interaction

User interaction shall be passed by way of shared memory using theXBox 360 or Windows PC system as a host machine. The XNA librariesprovide accesses to this data.

5.2. PROCESS INTERFACE 133

5.2.2 Live UpdateUpdates run using the shared memory located in the content pipelineclass. The Hot Sticks system shall never lock this data to facilitatereal-time updating.

5.2.3 Game PlayGame Play is accomplished by interfacing Hot Sticks with XNA. Thus,the system uses the XNA libraries to communicate Game Play elementsto 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 de-fined in this subsection of the Software Design Document. Each essen-tial 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 separationsare depicted in Figure 6.2.

6.1.1 Game Management Module

This Hotsticks game application module is defined in detail in this sub-section. The Module is comprised of the following objects.

Class Objects

BallManager Child class of ObjectManager to manage Ball class ob-jects.

Game The Microsoft XNA game class which is the main class to man-age 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 andoptions selected for options menu objects..

LoadSaveManager File I/O menu for Hotsticks game application.

ObjectManager Non-instantiated parent class designed to manage gameobjects.

135

136 CHAPTER 6. DETAILED DESIGN

XNA Interface

Windows PC Xbox

Monitor

Keyboard

Gamepad

1

1..4

1

1

Microsoft LIVE

1..*

1

1

1

Figure 6.1: Deployment Diagram

6.1. MODULE DETAILED DESIGN 137

Game Management Module Game I/O ModuleGame Objects

Game State Manager

Warp Manager

Object Manager

StickManager

GameObject

Ball

Table

Pocket

Warp

Physics

Input

Artist

Game

Ball Manager

Game Content

«enumeration»

GameState

Persitent Data Manager

Title Manager

Load Save Manager

Pause Manager

Menu Manager

Menu Content

Figure 6.2: Module Diagram


PauseManager Pause screen menu for Hotsticks game application

PersistentDataManager Class object to manage the file-I/O opera-tions of the Hotsticks game application.

Physics Static class of Physics-calculation methods to resolve physicalmovements for other management objects.

StickManager Object to manage the movement and actions of Stickclass objects.

WarpManager Child class of ObjectManager to manage Warp class ob-jects.

TitleManager Splash Screen menu for Hotsticks game application.

6.1.2 Game Input-Output ModuleThis Hot Sticks game application module is defined in detail in thissubsection.

Class Objects

Artist The Artist class utilizes the Microsoft XNA game objects to dis-play game content objects.

Input Class object which provides abstraction for hardware game in-terfaces.

6.1.3 Game Objects ModuleThis Hot Sticks game application module is defined in detail in thissubsection.

Class Objects

Ball Child class of GameObject which defines pool ball objects.

GameContent Class object which contains all game objects for the HotSticks application.

GameObject Parent class which contains data and methods relevantto all pool game objects.

MenuContent Information holder class containing all menu manage-ment class objects for Hotsticks game application.

Pocket Child class of GameObject which defines pool table pocket ob-jects.

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 transferball objects.

Data Structure Objects

GameState Enumerated data type which defines the possible statesthe Hotsticks game may take.

SpriteType Enumerated data type which defines the possible spritetypes for the Hotsticks game application.

LoadSaveState Defines the possible values for load and save opera-tional states.

SaveFileData Defines all GameContent data which will be saved andretrieved during game save operations.

6.2 Detailed Class Design

6.2.1 Artist

Snapshot�1 context Art is t : : Snapshot (GameContent content ,

GameStateManager state , MenuContent menu) :2 DBase = content ;3 StateManager = state ;4 Menu = menu; �

Go�1 context Art is t : :Go ( ) :2 (− ) Elements are layered with the newest item3 (− ) being placed on top of the rest of the screen .4

5 (− ) Screens take precedence over game objects6 i f StateManager . State == GameState . SplashScreen :7 DrawTitleScreen ( ) ;8 else i f StateManager . State == GameState .GamePaused9 DrawTable ( ) ;

10 DrawBalls ( ) ;11 i f !DBase. IsMoving :12 DrawStick ( ) ;13 DrawPauseScreen ( ) ;14 else i f StateManager . State == GameState . FileOperations


15 DrawTable ( ) ;16 DrawBalls ( ) ;17 DrawFileMenuScreen ( ) ;18 else i f StateManager . State == GameState .ExitGame19 DrawExitConfirmationScreen ( ) ;20 else i f StateManager . State == GameState . ShotPrep21 DrawTable ( ) ;22 DrawBalls ( ) ;23 DrawStick ( ) ;24 else i f StateManager . State == GameState .CuePlacement25 DrawTable ( ) ;26 DrawBalls ( ) ;27 else i f StateManager . State == GameState .BallMovement28 DrawTable ( ) ;29 DrawBalls ( ) ;30 else31 (− ) Do Nothing32

33 DrawClock (gameTime) ; �6.2.2 Draw Balls�

1 context Art is t : : DrawBalls ( ) :2 Bucket . Begin ( ) ;3 foreach Ball x in DBase. Balls4 Bucket .Draw( x . Sprite , x . Position ) ;5 Bucket .End ( ) ; �

Draw Table�1 context Art is t : : DrawTable ( ) :2 Bucket . Begin ( ) ;3 foreach Table x in DBase. Tables4 Bucket .Draw( x . Sprite , x . Position ) ;5 Bucket .End ( ) ; �

Draw Stick�1 context Art is t : : DrawStick ( ) :2 ballRadius = new Float ;3 Bucket . Begin ( ) ;


4 foreach GameObject x in DBase. Sticks5 ballRadius = 0;6 foreach Ball y in DBase. Balls7 i f y . IsCue8 ballRadius = y . Radius ;9

10 positionDelta = new Float ;11 (− ) Calculate radius of cue spr i te12 positionDelta .Y = Math. Sqrt ( ballRadius∗ballRadius +

x . Sprite . Height/2 ∗ x . Scale ) ;13 (− ) Calculate the angle from the top l e f t corner of

the st i ck ’s posi t ion14 positionDelta .X = x . Velocity .X + Math. PI −

Math. ArcCos ( ballRadius/positionDelta .Y ) ;15 positionDelta =

Physics . VelocityBoundaryResolution ( positionDelta ) ;16

17 (− ) Offset posi t ion based o f f of delta18 stickPosit ion = new Float ;19 stickPosit ion .Y = Math. Sin ( PositionDeltaVelocity .X)

∗ PositionDeltaVelocity .Y;20 stickPosit ion .X = a . Position .Y + 25.0 f −

Math.Cos ( PositionDeltaVelocity .X) ∗PositionDeltaVelocity .Y;

21

22 x . Rotation = x . Velocity .X + Math. PI / 2f ;23 Bucket .Draw( x . Sprite , x . Position ) ;24

25 Bucket .End ( ) ; �Draw Clock�

1 context Art is t : : DrawClock ( ) :2 Bucket . Begin ( ) ;3 (− ) u t i l i t y clock4 String str = String . Concat (5 gameTime.TotalGameTime . Minutes . ToString ( ) , " : " ,6 gameTime.TotalGameTime .Seconds . ToString ( ) , " : " ,7 gameTime.TotalGameTime . Milliseconds . ToString ( ) ) ;8

9 (− ) Get size of st r ing in pixels to r igh t al ign text10 textSize = ut i l . MeasureString ( str ) .Width ;11 TraceTime = graphics . GraphicsDevice . Viewport .Width −

textSize .X;


12 Bucket .Draw( str , TraceTime ) ;13 Bucket .End ( ) ; �

Draw Pause Screen�1 context Art is t : : DrawPauseScreen ( ) :2 position = new {3 start = new Float { x , y } ;4 end = new Float { x , y } ;5 } ;6

7 position . start .X = Screen .Width / 2 −Menu.PauseManagerData .Background .Width / 2;

8 position .end .X = Screen .Width / 2 +Menu.PauseManagerData .Background .Width / 2;

9 position . start .Y = Screen . Height / 2 −Menu.PauseManagerData .Background . Height / 2;

10 position .end .Y = Screen . Height / 2 +Menu.PauseManagerData .Background . Height / 2;

11

12 Bucket . Begin ( ) ;13 Bucket .Draw(Menu.PauseManagerData . Overlay , position ) ;14 for i from 0:Menu.PauseManagerData . ListOptions .Count15 sh i f t =

Menu.PauseManagerData . ListOptions [ i ] . StringHeight ( ) ;16 i f i == Menu.PauseManagerData . CurrentOption17 Bucket .Draw(DBase. Balls [ " eight " ] ,18 { position . start .X +

Menu.PauseManagerData . StartPosition .X−Menu.PauseManagerData . OptionIndicator .Width ∗Menu.PauseManagerData . Scale ,

19 position . start .Y +Menu.PauseManagerData . StartPosition .Y + sh i f t∗ i ,

20 Menu.PauseManagerData . OptionIndicator .Width ∗Menu.PauseManagerData . Scale ,

21 Menu.PauseManagerData . OptionIndicator . Height ∗Menu.PauseManagerData . Scale

22 } ) ) ;23

24 Bucket .Draw(Menu.PauseManagerData . ListOptions [ i ] ,25 { Menu.PauseManagerData . StartPosition .X +

position . start .X,


26 Menu.PauseManagerData . StartPosition .Y +position . start .Y+ sh i f t ∗ i

27 } ) ;28

29 Bucket .End ( ) ; �Draw File Menu Screen�

1 context Art is t : : DrawFileMenuScreen ( ) :2 position = new {3 start = new Float { x , y } ;4 end = new Float { x , y } ;5 } ;6 position . start .X = Screen .Width / 2 −

Menu.LoadSaveManagerData .Background .Width / 2;7 position .end .X = Screen .Width / 2 +

Menu.LoadSaveManagerData .Background .Width / 2;8 position . start .Y = Screen . Height / 2 −

Menu.LoadSaveManagerData .Background . Height / 2;9 position .end .Y = Screen . Height / 2 +

Menu.LoadSaveManagerData .Background . Height / 2;10

11 Bucket . Begin ( ) ;12 Bucket .Draw(Menu.LoadSaveManagerData . Overlay , position ) ;13 for i from 0:Menu.LoadSaveManagerData . ListOptions .Count14 sh i f t =

Menu.LoadSaveManagerData . ListOptions [ i ] . StringHeight ( ) ;15 i f i == Menu.LoadSaveManagerData . CurrentOption16 Bucket .Draw(DBase. Balls [ " eight " ] ,17 { position . start .X +

Menu.LoadSaveManagerData . StartPosition .X −Menu.PauseManagerData . OptionIndicator .Width ∗Menu.PauseManagerData . Scale ,

18 position . start .Y +Menu.LoadSaveManagerData . StartPosition .Y +sh i f t ∗ i ,

19 Menu.LoadSaveManagerData . OptionIndicator .Width ∗DBase. Balls [ " eight " ] . Scale ,

20 Menu.LoadSaveManagerData . OptionIndicator . Height∗ DBase. Balls [ " eight " ] . Scale

21 } ) ) ;22

23 Bucket .Draw(Menu.LoadSaveManagerData . ListOptions [ i ] ,


24 { Menu.LoadSaveManagerData . StartPosition .X +position . start .X,

25 Menu.LoadSaveManagerData . StartPosition .Y +position . start .Y+ sh i f t ∗ i

26 } ) ;27

28 Bucket .End ( ) ; �Draw Title Screen�

1 context Art is t : : DrawFileMenuScreen ( ) :2 position = new {3 start = new Float { x , y } ;4 end = new Float { x , y } ;5 } ;6 position . start .X = Screen .Width / 2 −

Menu. TitleManagerData .Background .Width / 2;7 position .end .X = Screen .Width / 2 +

Menu. TitleManagerData .Background .Width / 2;8 position . start .Y = Screen . Height / 2 −

Menu. TitleManagerData .Background . Height / 2;9 position .end .Y = Screen . Height / 2 +

Menu. TitleManagerData .Background . Height / 2;10

11 Bucket . Begin ( ) ;12 Bucket .Draw(Menu. TitleManagerData . Overlay , position ) ;13 for i from 0:Menu. TitleManagerData . ListOptions .Count14 sh i f t =

Menu. TitleManagerData . ListOptions [ i ] . StringHeight ( ) ;15 i f i == Menu. TitleManagerData . CurrentOption16 Bucket .Draw(DBase. Balls [ " eight " ] ,17 { position . start .X +

Menu. TitleManagerData . StartPosition .X −DBase. Balls [ " eight " ] . Sprite .Width ∗DBase. Balls [ " eight " ] . Scale ,

18 position . start .Y +Menu. TitleManagerData . StartPosition .Y + sh i f t∗ i ,

19 Menu. TileManagerData . OptionIndicator .Width ∗Menu. TileManagerData . Scale ,

20 Menu. TileManagerData . OptionIndicator . Height ∗Menu. TileManagerData . Scale

21 } ) ;22


23 Bucket .Draw(Menu. TitleManagerData . ListOptions [ i ] ,24 { Menu. TitleManagerData . StartPosition .X +

position . start .X,25 Menu. TitleManagerData . StartPosition .Y +

position . start .Y + sh i f t ∗ i26 } ) ;27

28 Bucket .End ( ) ; �6.2.3 Ball

6.2.4 BallManager

Resolve�1 context BallManager : : Resolve (GameContent content ,

GameStateManager stateManager ) : GameContent2

3 Float movement = 0;4 Rectangle tableRectangle = new Rectangle ;5 Rectangle cueRectangle = new Rectangle ;6 Boolean notWarp = true ;7 deltaPosit ion = new {0 ,0 ,0 } ;8 Float distance = 0;9 Integer methodCounter = 0;

10 Float f ract ional = 1 / this . NumberIterations ;11

12 while methodCounter < this .Number Iterat ions :13 foreach bal l in content . bal ls14 i f ( bal l . Velocity .Mag > 0) or

( stateManager . State ( ! BallMovement ) :15 bal l . Position .X += Math. Sin ( bal l . Velocity . Dir ) ∗

bal l . Velocity .Mag ∗ f ract ional ;16 bal l . Position .Y −= Cos ( bal l . Velocity . Dir ) ∗

bal l . Velocity .Mag ∗ f ract ional ;17 tableRectangle = BallManager . BoundaryRectangle

( content . Tables [ content . Level ] . Bounds,bal l . Radius ) ;

18 bal l . Position =BallManager . BoundaryCheckMovingObjectRectangle( bal l . Position , bal l . Velocity ,tableRectangle ) ;

19 bal l . Velocity = Physics . AdjustObjectSpeed (bal l . Velocity , f ract ional ) ;

20 movement += bal l . Velocity .Mag;


21

22 i f ( bal l . IsCue )23 content . Stick [ 0 ] . Position = bal l . Position ;24

25 i f bal l .WarpingWarpID >= 0:26 notWarp = true ;27 foreach warp in content .Warps28 i f warp.WarpID == bal l .WarpingID :29 deltaPosit ion .X = warp . Position .X −

bal l . Position .X;30 deltaPosit ion .Y = warp . Position .Y −

bal l . Position .Y;31 distance = Math. Sqrt ( deltaPosit ion .X ^ 2 +

deltaPosit ion .Y ^ 2 ) ;32 i f ( warp . Radius + bal l . Radius − distance >=

0.1 )33 notWarp = fa lse ;34

35 i f notWarp :36 bal l .WarpingWarpID = −1;37

38 i f movement < 0.001:39 content . IsMoving = f lase ;40 stateManager .Movement = fa lse ;41 foreach bal l in content . bal ls42 i f ( bal l . IsCue )43 i f ( bal l . Position .Z < 0 )44 bal l . Al ive = true ;45 bal l . Position =

content . Tables [ content . Level ] . Position . Center ;46 content . Stick [ 0 ] . Position = bal l . Position ;47

48 i f ( this . UpdateCueBallPosition )49 bal l . Postiion .X +=

this . CueBallLocationUpdate .X;50 bal l . Position .Y +=

this . CueBallLocationUpdate .Y;51 bal l . Position .Z = thi . CueBallLocationUpdate .Z;52 cueRectangle = BallManager . BoundaryRectangle (53 content . Tables [ content . Level ] . CueBounds,54 bal l . Radius ) ;55 bal l . Position =

BallManager . BoundaryCheckStaticObjectRectangle (56 bal l . Position ,57 cueRecctangle ) ;58 Me. UpdateCueBallPosition = fa lse ;


59

60 else61 content . IsMoving = true ;62 stateManager .Movement = true ;63

64 content = BallManager . DetectColl isions (65 content ,66 stateManager ) ;67 methodCounter += 1;68

69 return content ; �MoveCueBallPosition�

1 context BallManager : : MoveCueBallPosition ( Vector3newPosition ) :

2 UpdateCueBallPosition = true ;3 CueBallLocationUpdate = newPosition ;4 return ; �

DetectCollison�1 context BallManager : : DetectColl ision (GameContent

content , GameStateManager stateManager ) : GameContent2 objectSeparation = new { 0 ,0 } ;3 f l oa t distance = 0;4 Rectangle tableRectangle = new Rectangle ;5 returnVector2 = new {X=0,Y=0} ;6 returnVector4 = new {X=0,Y=0,Z=0,W=0};7

8 for ball1 from 0: content . Balls .Count−19 for ball2 from ball1 +1:content . Balls .Count

10 i f ( ball1 . Position .Z == ball2 . Position .Z ANDball1 . Position .Z >= 0 )

11 objectSeparation .X = ball1 .X − ball2 .X;12 objectSeparation .Y = ball1 .Y − ball2 .Y;13 distance = Math. Sqrt ( objectSeparation .X ^ 2 +

objectSeparation .Y ^ 2 ) ;14 i f ( ball1 . Radius + ball2 . Radius − distance >

0.1 )15 returnVector4 =

ObjectManager .BoundaryCheckObject (16 ball1 . Position ,


17 ball1 . Velocity ,18 ball1 . Radius ,19 ball2 . Position ,20 ball2 . Velocity ,21 ball2 . Radius ) ;22 ball1 .X = returnVector4 .X;23 ball1 .Y = returnVector4 .Y;24 ball2 .X = returnVector4 .Z;25 ball2 .Y = returnVector4 .W;26

27 returnVector4 =Physics . CalculateObjectObjectCollision (

28 ball1 . Position ,29 ball1 . Velocity ,30 ball2 . Position ,31 ball2 . Velocity ) ;32 ball1 . Dir = returnVector4 .X;33 ball1 .Mag = returnVector4 .Y;34 ball2 . Dir = returnVector4 .Z;35 ball2 .Mag = returnVector4 .W;36

37 foreach bal l in content . Balls38 tableRectangle = BoundaryRectangle (39 content . Tables [ 0 ] .Bounds,40 bal l . Radius ) ;41 i f tableRectangle . Contains ( bal l . Position ) :42 else43 returnVector2 =

Physics . CalculateObjectRectangleCollision (44 bal l . Position ,45 bal l . Velocity ,46 tableRectangle ) ;47 bal l . Velocity = returnVector2 ;48

49 foreach bal l in content . Balls50 foreach pocket in content . Pockets51 i f bal l . Position .Z = pocket . Position .Z52 objectSeparation .X = bal l . Position .X −

pocket . Position .X + pocket . Center .X;53 objectSeparation .Y = bal l . Position .Y −

pocket . Position .Y − pocket . Center .Y;54 distance = SquareRoot ( objectSeparation .X ^ 2 +

objectSeparation .Y ^ 2 ) ;55 i f distance < ( bal l . Radius + pocket . Radius ) :56 bal l . a l i ve = fa lse ;57 bal l . Velocity = 0;


58 i f ( bal l . IsCue )59 stateManager . Scratch = true ;60 stateManager . ScratchLevel = bal l . Position .Z;61

62 bal l . Position .Z = −1;63

64 return content ; �6.2.5 GameContent

AddBall�1 context GameContent : : AddBall ( Ball newBall ) :2 Balls .Add( newBall ) ; �

AddPocket�1 context GameContent : : AddPocket ( Pocket newPocket ) :2 Pockets .Add( newPocket ) ; �

AddTable�1 context GameContent : : AddTable ( Table newTable ) :2 Tables .Add( newTable ) ; �

AddStick�1 context GameContent : : AddStick ( Stick newStick ) :2 Stick .Add( newStick ) ; �

AddWarp�1 context GameContent : :AddWarp(Warp newWarp) :2 Warps.Add(newWarp) ; �


6.2.6 GameObject

6.2.7 GameStateManager

UpdateState�1 context GameStateManager : : UpdateState ( ) :2 i f State == ShotPrep :3 i f Movement4 previousState = state ;5 state = BallMovement ;6 else i f pause :7 previousState = state ;8 prePauseState = state ;9 state = gamePaused

10 else i f state == ballMovement :11 i f not movement12 i f scratch13 state = cuePlacement ;14 scratch = fa lse ;15 else16 state = shotPrep ;17

18 i f pause19 previousState = state ;20 prePauseState = state ;21 state = gamePaused;22 pause = fa lse ;23 else i f state == cuePlacement24 i f cueplaced25 state = shotPrep ;26 cuePlaced = fa lse ;27 i f paused28 previousState = state ;29 prePauseState = state ;30 state = gamePaused;31 pause = fa lse ;32 else i f state == gamePaused33 i f pause34 state = prePauseState ;35 pause = fa lse ;36 else i f loadSave37 prevoiusState = state ;38 state = fi leOperations ;39 loadSave = fa lse ;40 else i f setGameAttributes


41 previousState = state ;42 preSettingsState = state ;43 state = gameSettings ;44 setGameAttributes = fa lse ;45 else i f ex i t46 previousState = state ;47 state = splashScreen ;48 ex i t = fa lse ;49

50 else i f state == fi leOperations51

52 i f ex i t53 state = previousState ;54 previousState = fi leOperations ;55 ex i t = fa lse ;56

57 else i f state == splashScreen58 i f next59 previousState = state ;60 state = shotPrep ;61 next = fa lse ;62 else i f loadSave63 previousState = state ;64 state = fi leOperations ;65 loadSave = fa lse ;66 else i f setGameAttributes67 previousState = state ;68 preSettingsState = state ;69 state = gameSettings ;70 setGameAttributes = fa lse ;71 else i f ex i t72 previousState = state ;73 state = exitGame ;74 ex i t = fa lse ;75 else i f state == exitGame76

77 else i f state == gameSettings78 i f ex i t79 state = preSettingsState ;80 ex i t = fa lse ;81 else i f placement82 previousState = state ;83 state = warpPlacement ;84 placement = fa lse ;85 else i f state == warpPlacement86 i f ex i t


87 state = previousState ;88 ex i t = fa lse ;89

90 else �6.2.8 Game

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

LoadContent�1 context Game: : LoadContent ( ) :2 (− ) Load a l l spritesheets and content �

UnloadContent�1 context Game: : UnloadContent ( ) :2 (− ) No added data �

Update�1 context Game: : Update ( ) :2 UserInput = Input . PlayerOne ;3 GameLevel = (GameLevel + UserInput . LevelChange ) %

MAXIMUM_LEVEL;4

5 i f GameLevel < 0:6 GameLevel = MAXIMUM_LEVEL − 1;7

8 Game.Speed = UserInput .GameSpeed;9

10 i f StateManager . State == State .BallMovement :11 BallManager . Resolve ( ) ;12 WarpManager. Resolve ( ) ;13 i f UserInput . UpdatePauseState :14 StateManager .Pause = true ;15 else i f StateManager . State == State . ShotPrep :


16 UserInput . SetFreezeLevel ( ) ;17 StickManager . UpdateStick ( UserInput . Angle ( ) ) ;18 i f UserInput .HasShot :19 UserInput . SetFreezeLevel (1 ) ;20 StickManager . UpdateStick (21 UserInput . Angle ( ) ,22 UserInput . GetForce ( ) ;23 ) ;24

25 BallManager . Resolve ( ) ;26 WarpManager. Resolve ( ) ;27 i f UserInput . UpdatePauseState :28 StateManager .Pause = true ;29

30 else i f StateManager . State = State .CuePlacement :31 BallManager . MoveCueBallPosition (32 { UserInput . DirectionalMovement ( ) ,33 StateManager . ScratchLevel }34 ) ;35 i f UserInput . UpdatePauseStatus :36 StateManager .Pause = true ;37

38 else i f StateManager . State == State . SplashScreen :39 TitleManagerData . CurrentOption +=

UserInput .MenuMovement ( ) ;40 i f TitleManagerData . CurrentOption < 0:41 TitleManagerData . CurrentOption = 0;42 else i f TitleManagerData . CurrentOption >

TitleManagerData . ListOptions .Count :43 TitleManagerDta . CurrentOption =

TitleManagerData . ListOptions .Count ;44

45 i f UserInput . MenuSelection :46 TitleManagerData . SelectOption ( StateManager ) ;47

48 else i f StateManager . State == State . FileOperations :49 FileDataManager . I n i t i a l i z e ( ) ;50 LoadSaveManagerData . CurrentOption +=

UserInput .MenuMovement ( ) ;51 i f LoadSaveManagerData . CurrentOption < 0:52 LoadSaveManagerData . CurrentOption = 0;53 else i f LoadSaveManagerData . CurrentOption >

LoadSaveManagerData . ListOptions .Count :54 LoadSaveManagerData . CurrentOption =

LoadSaveManagerData . ListOptions .Count ;55


56 i f UserInput . MenuSelection ( ) :57 LoadSaveManagerData . SelectOption ( StateManager ) ;58 i f LoadSaveManagerData . State == LoadSaveState .Load :59 Game = FileDataManager .ReadData (Me) ;60 LoadSaveManagerData . State = LoadSaveState . Id le ;61 else i f LoadSaveManagerData . State ==

LoadSaveState . Save :62 FileDataManager .SnapShot ( ) ;63 FileDataManager . WriteData ( ) ;64 LoadSaveManagerData . State = LoadSaveState . Id le ;65

66 else i f StateManager . State == State .GamePaused:67 PauseManagerData . CurrentOption +=

UserInput .MenuMovement ( ) ;68 i f PauseManagerData . CurrentOption < 0:69 PauseManagerData . CurrentOption = 0;70 else i f PauseManagerData . CurrentOption >

PauseManagerData . ListOptions .Count :71 PauseManagerData . CurrentOption =

PauseManagerData . ListOptions .Count ;72

73 i f UserInput . MenuSelection ( ) :74 PauseManagerData . SelectOption ( StateManager ) ;75

76 else i f StateManager . State == State . GameSettings :77 SettingsData . CurrentOption +=

UserInput .MenuMovement ( ) ;78 i f SettingsData . CurrentOption < 0:79 SettingsData . CurrentOption = 0;80 else i f SettingsData . CurrentOptions >

SettingsData . ListOptions .Count81 SettingsData . CurrentOption =

SettingsData . Listoptions .Count ;82

83 i f ( UserInput . MenuSelection ( ) :84 SettingsData . SelectOption ( StateManager ) ;85 SettingsData . UpdateStettings (Me) ;86

87 else i f StateManager . State == State .ExitGame:88 Me. Exit (0 ) ;89

90 else i f StateManager . State == State>WarpPlacement :91 WarpManager. MoveWarpPosition (92 { UserInput . DirectionalMovement ( ) ,93 GameLevel } ) ;94 i f UserInput . PlacementDone


95 StateManager . Exit = true ;96 while WarpPairCounter > 097 Warps.RemoveAt (Warps.Count−1) ;98 WarpPairCounter −= 1;99

100 i f UserInput . MenuSelection :101 i f WarpPairCounter == 0:102 StateManager . Exit == true ;103

104 StateManager . UpdateState ( ) ;105 (− ) Store for next cycle106 UserInput = Input . PlayerOne ; �

Draw�1 context Game: :Draw ( ) :2 Art is t . Snapshot (DBase) ;3 Art is t .Go ( ) ; �6.2.9 Input

SetFreezeLevel�1 context Input : : SetFreezeLevel ( int a ) :2 pre : a<=0;3

4 FreezeLevel = 0;5

6 context Input : : SetFreezeLevel ( int a ) :7 pre : a>0;8

9 FreezeLevel = a ; �HasShot�

1 context Input : : HasShot ( ) : Boolean2 return Shot ; �


Angle�1 context Input : : Angle ( ) : Float2 return DeltaAngle ; �

getForce�1 context Input : : GetForce ( ) : Float2 return Force ; �

PlacementDone�1 context Input : : PlacementDone ( ) : Boolean2 return Placed ; �

SignalPrepareShot�1 context Input : : SignalPrepareShot ( ) : Boolean2 return PrepareShot ; �

DirectionalShift�1 context Input : : Direct ionalShift ( ) : Float2 return DeltaView ; �

DirectionalMovement�1 context Input : : DirectionalMovement ( ) : Vector2 return DeltaMovement ; �6.2.10 LoadSaveManager

SelectOption


�1 context LoadSaveManager : : SelectOption (GameStateManager

stateManager ) :2

3 i f currentOption == 0:4 state = load ;5 else i f currentOption == 1:6 state = save ;7 else i f currentOption == 2:8 stateManager . ex i t = true ;9 else

10 currentOption = 0; �6.2.11 MenuContent

SetTitleManager�1 context MenuContent : : SetTitleManager ( TitleManager t i t l e ) :2 TitleManagerData = t i t l e ; �

SetPauseManager�1 context MenuContent : : SetPauseManager ( PauseManager pause ) :2 PauseManagerData = pause ; �6.2.12 SetLoadSaveManager�

1 context MenuContent : : SetLoadSaveManager ( LoadSaveManagerf i l e i o ) :

2 LoadSaveManagerData = f i l e i o ; �SetGameSettingsManager�

1 contextMenuContent : : SetGameSettingsManager ( GameSettingsManagersett ings ) :

2 SettingsData = sett ings ; �


6.2.13 MenuManager

AddOption�1 context MenuManager : : AddOption ( string option ) : Null2 ListOptions .add ( option ) ; �6.2.14 ObjectManager

Resolve�1 context ObjectManager : : Resolve (GameContent content ,

GameStateManager stateManager ) : GameContent2

3 return content ; �DetectCollision�

1 context ObjectManager : : DetectColl ision (GameContentcontent , GameStateManager stateManager ) : GameContent

2

3 return content ; �BoundaryCheckMovingObjectRectangle�

1 contextObjectManager : : BoundaryCheckMovingObjectRectangle ( Vectorposition , Vector velocity , Rectangle boundary ) : Vector

2

3 delta = new {X=0,Y=0} ;4 i f ( boundary . Contains ( position ) )5 else6 i f ( boundary .Top > position .Y ) :7 delta .Y = boundary .Top − 0.0001 − position .Y;8 position .Y = boundary .Top − 0.0001;9 delta .X = delta .Y / Cos ( ve loc i ty . Dir ) ∗

Sin ( ve loc i ty . Dir ) ;10 position .X −= delta .X;11

12 else i f ( boundary . bottom < position .Y ) :13 delta .Y = position .Y − boundary .Bottom + 0.0001;14 position .Y = boundary .Bottom + 0.0001;


15 delta .X = delta .Y / Math.Cos ( ve loc i ty . Dir ) ∗Math. Sin ( ve loc i ty . Dir ) ;

16 position .X += delta .X;17

18 else i f ( boundary . Right < position .X) :19 delta .X = position .X − boundary . Right + 0.0001;20 position .X = boundary . Right + 0.0001;21 delta .Y = delta .X / Math. Sin ( ve loc i ty . Dir ) ∗

Math.Cos ( ve loc i ty . Dir ) ;22 position .Y −= delta .Y;23

24 else25 delta .X = Boundary . Left − 0.0001 − position .X26 position .X = boundary . Left − 0.001;27 delta .Y = delta .X / Math. Sin ( ve loc i ty . Dir ) ∗

Math.Cos ( ve loc i ty . Dir ) ;28 position .Y += delta .Y;29

30 return position ; �BoundaryCheckObject�

1 context ObjectManager : : BoundaryCheckObject ( Vector3position1 , Vector2 velocity1 , f l oa t radius1 , Vector3position2 , Vector2 velocity2 , f l oa t radius2 ) : Vector4

2

3 results = new {X=0,Y=0,Z=0,W=0};4 f l oa t slomo = 0.01;5 f l oa t magnitude = 0;6 f l oa t distance = Math. Sqrt ( ( position1 .X − position2 .X)

^ 2 + ( position1 .Y − position2 .Y ) ^ 2) ;7 f l oa t previous = distance ;8 magnitude = velocity1 .Mag + velocity2 .Mag;9

10 i f ( magnitude < 0.1 ) :11 velocity1 .Mag = 1;12

13 while ( distance < previous ) :14 position1 .X −= Math. Sin ( velocity1 . Dir ) ∗

velocity1 .Mag ∗ slomo ;15 position1 .Y += Math.Cos ( velocity1 . Dir ) ∗

velocity1 .Mag ∗ slomo ;16 position2 .X −= Math. Sin ( velocity2 . Dir ) ∗

velocity2 .Mag ∗ slomo ;


17 position2 .Y += Math.Cos ( velocity2 . Dir ) ∗velocity2 .Mag ∗ slomo ;

18 previous = distance ;19 distance = Math. Sqrt ( ( position1 .X − position2 .X) ^ 2

+ ( position1 .Y − position2 .Y ) ^ 2) ;20 i f ( distance < previous ) :21 velocity1 . Dir += Pi ;22

23 results .X = position1 .X;24 results .Y = position1 .Y;25 results .Z = position2 .X;26 results .W = position2 .Y;27

28 return results ; �BoundaryCheckStaticObjectRectangle�

1 contextObjectManager : : BoundaryCheckStaticObjectRectangle( Vector3 position , Rectangle perimiter ) : Vector3

2

3 i f ( ! perimiter . Contains ( position ) )4 position .X = Math.Clamp( position .X, perimiter ) ;5 position .Y = Math.Clamp( position .X, perimiter ) ;6

7 return position ; �BoundaryRectangle�

1 context ObjectManager : : BoundaryRectangle ( Rectangleperimiter , f l oa t radius ) : Rectangle

2

3 f l oa t X;4 f l oa t Y5 f l oa t height6 f l oa t width ;7 Rectangle boundary ;8 boundary .X = perimiter .X + radius ;9 boundary .Y = perimiter .Y + radius ;

10 boundary . Height = perimiter .Width − 2∗radius ;11 boundary . Height = preimiter . Height − 2∗radius ;12

13 return boundary ; �


6.2.15 PauseManager

SelectOption�1 context PauseManager : : SelectOption (GameStateManager

stateManager ) :2

3 i f currentOption == 0:4 stateManager .pause = true ;5 else i f currentOption == 1:6 stateManager . loadsave = true ;7 else i f currentOption == 2:8 stateManager . setgameattributes = true ;9 else i f currentOption == 3:

10 stateManager . ex i t = true ;11 else12

13 currentoption = 0; �6.2.16 PersistentDataManager

Snapshot�1 context PersistentDataManager : : Snapshot (GameContent

content ) :2 gameContent = content ; �

Initialize�1 context PersistentDataManager : : I n i t i a l i z e ( ) :2

3 i f ( storageDevice != Null ) and ( storageDevice Selected== fa lse ) :

4 stoarageContainer f i lecontainer =storageDevice . OpenContainer ;

5 string fileName = path . combine ( f i l econta inter ) ;6 i f ! F i le . Exists ( fileName ) :7 newfile = Fi le . create ( fileName ) ;8 f i l econta iner . dispose ;9 storageDeviceSelected = true ;

10 else11 i f ! storageDeviceSelectionInit iated :12 result = Guide . BeginShowStorageDeviceSelector ;


13 storageDeviceSelectionInit iated = true ;14

15 else i f result . iscompleted &&storageDeviceSelectionInit iated == fa lse :

16 storageDevice = Guide . EndShowStorageDeviceSelector ;17 deviceEnd = true ; �

WriteData�1 context PersistentDataManager : : WriteData ( ) :2 PackGameSaveData;3 device = StorageDevice . OpenContainer ( " Hoststicks " ) ;4 string filename = Path . combine ( device ) ;5 FileStream save = Fi le . open ( filename ) ;6 DataSerializer . Ser ia l i ze ( save , GameSave) ;7 save . close ;8 device . Dispose ; �

ReadData�1 context PersistentDataManager : : WriteData (Game game) :

GameContent2 device = StorageDevice . OpenContainer ( " Hoststicks " ) ;3 string filename = Path . combine ( device ) ;4 i f filename . Exists5 FileStream load = Fi le . open ( filename ) ;6 GameSave = DataSerializer . Deserial ize ( load ) ;7 load . close ;8 device . Dispose ;9

10 Me.UnpackGameSaveData (Game) ;11 return content ; �

PackGameSaveData�1 context PersistentDataManager : : PackGameSaveData ( ) :2 GameLevel = GameContent .GameLevel ;3 Layers = GameContent . Tables .Count ;4 GameSave. BallPosit ions . Clear ;5 GameSave. BallIDs . Clear ;6 foreach bal l in GameContent . Balls :7 GameSave. BallPosit ions .Add( bal l ) ;


8 GameSave. BallIds .Add( bal l ) ;9

10 GameSave. WarpPositions . Clear ;11 GameSave. WarpVelocities . Clear ;12 GameSave.WarpIDs. Clear ;13 foreach warp in GameContent .Warps:14 GameSave. WarpPositions .Add(warp ) ;15 GameSave. WarpVelocities .Add(warp ) ;16 GameSave.WarpIDs.Add(warp ) ; �

UnpackGameSaveData�1 context PersistentDataManager : : UnpackGameSaveData (Game

game) :2 GameContent .GameLevel = GameLevel ;3 GameContent . Balls . Clear ;4 bal l = new Ball ;5 bal l . Position = GameSave. BallPositions [ 0 ] ;6 bal l . IsCue = true ;7 GameContent . Balls .Add( bal l ) ;8

9 for i from 1:GameSave. BallIDs . count :10 bal l = new Ball ;11 bal l . Position = GameSave. Ballpositions [ i ] ;12 GameContent . Balls .Add( bal l ) ;13

14 GameContent .Warps. clear ;15 for i from 1:GameSave.WarpIDs. count16 warp = new Warp;17 warp. Position = GameSave. WarpPositions [ i ] ;18 warp. Velocity = GameSave. WarpVelocities [ i ] ;19 warp. ID = GameSave.WarpIDs [ i ] ;20 GameContent .Warps.Add(warp ) ; �

6.2.17 Physics

CalculateObjectRectangleCollision�1 context

Physics : : CalculateObjectRectangleCollision ( Vector3position , Vector2 velocity , Rectangle rectangle ) :Vector


2 i f ( rectangle .Top > position .Y ) or ( rectangle .Bottom <position .Y ) :

3 i f ( ve loc i ty . Dir < Pi )4 ve loc i ty . Dir = Pi − ve loc i ty . Dir ) ;5 else6 ve loc i ty . Dir = 3Pi − ve loc i ty . Dir ;7 else i f ( rectangle . Right < position .X OR

rectangle . Left > position .X)8 ve loc i ty .X = 2Pi − ve loc i ty . Dir ;9 else

10

11 return ve loc i ty ; �AdjustObjectSpeed�

1 context Physics : : AdjustObjectSpeed ( Vector2 velocity ,f l oa t factor ) : Vector

2 i f ( ve loc i ty .Mag > 3)3 ve loc i ty .Mag −= ( 0.085 ∗ factor ) ;4 else5 ve loc i ty .Mag ∗= 0.96 ^ factor ;6

7 i f ( ve loc i ty .Mag < 0.05) :8 ve loc i ty .Mag = 0;9

10 return ve loc i ty ; �CalculateAbsoluteVelocityFromComponentVector�

1 contextPhysics : : CalculateAbsoluteAngleFromRelative ( Vector2component ) : Vector

2 vector result = new {X=0,Y=0} ;3 result .Mag = Math. Sqrt ( component .X ^ 2 + component .Y

^ 2) ;4

5 i f ( result .Mag == 0)6 result . Dir = 0;7 else8 result . Dir = ArcSin ( component .Mag / result .Mag) ) ;9 i f ( component . Dir >= 0)

10 result . Dir = ( Pi / 2) + result . Dir ;11 else


12 result . Dir = (3 Pi / 2) − result . Dir ;13

14 return result ; �CalculateAbsoluteAngleFromRelative�

1 contextPhysics : : CalculateAbsoluteAngleFromRelative ( Vector2absolute , Vector2 re la t i ve ) : Vector

2 vector result = new { Dir=0, Res=0} ;3 result . Dir = absolute . Dir + re la t i ve . Dir ;4 result .Res = VelocityBoundaryResolution ( result ) ;5 return result ; �

CalculateComponentVectorFromVelocity�1 context Physics : : CalculateComponentVectorFromVelocity

( Vector2 ve loc i ty ) : Vector2 Vector2 result = new {X=0,Y=0} ;3 result .X = ve loc i ty .Mag ∗ Sin ( ve loc i ty . Dir ) ;4 result .Y = ve loc i ty .Mag ∗ −Cos ( ve loc i ty . Dir ) ;5 return result ; �

VelocityBoundaryResolution�1 context Physics : : VelocityBoundaryResolution ( Vector2

ve loc i ty ) : Vector2 i f ( ve loc i ty . Dir < 0.0 f )3 ve loc i ty . Dir = ve loc i ty . Dir + 2Pi ;4 else i f ( ve loc i ty . Dir > 2Pi )5 ve loc i ty . Dir = ve loc i ty . Dir − 2Pi ;6

7 i f ( ve loc i ty .Mag < 0.01)8 Velocity .Y = 0.0 f ;9

10 return ve loc i ty ; �VelocityVectorAddition


�1 context Physics : : VelocityVectorAddition ( Vector2 vector1 ,

Vector2 vector2 ) : Vector2 Vector component1 = new {X=0,Y=0} ;3 Vector component2 = new {X=0,Y=0} ;4 Vector componentSum = new {X=0,Y=0} ;5 Vector result = new {X=0,Y=0} ;6 component1 =

CalculateComponentVectorFromVelocity ( vector1 ) ;7 component2 =

CalculateComponentVectorFromVelocity ( vector2 ) ;8 componentSum.X = Component1.X + Component2.X;9 componentSum.Y = Component1.Y + Component2.Y;

10 result =CalculateAbsoluteVelocityFromComponentVector (componentSum) ;

11

12 return result ; �

6.2.18 Pocket

6.2.19 StickManager

UpdateStick

�1 context StickManager : : UpdateStick (GameContent content ,

f l oa t angle , f l oa t force ) : GameContent2 stickVector = new Vector (

content . Stick . Velocity .X+=angle , force ) ;3 stickVector = Physics . VelocityBoundaryResolution (

stickVector ) ;4 content . Stick . Velocity .X = stickVector .X;5 content . Stick . Velocity .Y = stickVector .Y;6

7 foreach Ball in content . Balls8 i f Ball .Cue == true9 Ball . Velocity .X += stickVector .X;

10 Ball . Velocity .Y += stickVector .Y;11

12 return content ; �


6.2.20 Table

6.2.21 TitleManager

SelectOption�1 context TitleManager : : SelectOption (GameStateManager

stateManager ) :2 i f currentOption == 0:3 stateManager . next = true ;4 else i f currentOption == 1:5 stateManager . loadsave = true ;6 else i f currentOption == 2:7 stateManager . setgameattributes = true ;8 else i f currentOption == 3:9 stateManager . ex i t = true ;

10 else11

12 currentoption = 0; �6.2.22 WarpManager

Resolve�1 context WarpManager : : Resolve (GameContent content ) :

GameContent2 content = WarpManager. DetectColl isions ( content ) ;3 content = adjustWarpPosition ( content ) ;4 return Content ; �

DetectCollision�1 context WarpManager : : DetectColl ision (GameContent

content ) : GameContent2 Vector2 separation = new Vector2 ;3 f l oa t distance = new f l oa t 0.0 f ;4 bool warpMateFound = fa lse ;5

6 foreach bal l in content . Balls7 foreach warp in content .Warps8 i f warp. Position .Z = bal l . Position .Z:9 separation .X = warp . Position .X − bal l . Position .X;

10 separation .Y = warp . Position .Y − bal l . Position .Y;


11 distance = Math. Sqrt ( separation .X ^ 2 +separation .Y ^ 2) ;

12 i f (warp . Radius + bal l . Radius − distance > 0.1)and ( bal l .WarpingWarpID < 0) :

13 foreach warp2 in content .Warps14 i f (warp .warpID == warp2.WarpID) and

(warp . Position != warp2. Position ) :15 bal l . Position = warp2. Position ;16 bal l .WarpingWarpID = warp2.WarpID;17 warpMateFound = true ;18

19

20 i f !warpMateFound:21 int randomIndex = random# ( 0 to

content .Waprs. count − 1 ) ;22 bal l . Position =

content .Warps [ randomIndex ] . Position ;23 bal l .WarpingWarpID =

content .Warps [ randomIndex ] . WarpID;24

25 i f ( bal l . IsCue )26 content .GameLevel = bal l . Position .Z;27

28 return content ; �AdjustWarpPosition�

1 context WarpManager : : AdjustWarpPosition (GameContentcontent ) : GameContent

2 rectangle = new rectangle3

4 foreach warp in Warps5 i f warp ve loc i ty > 06 warp. x += sin ( direction ) ∗ magnitude ;7 warp. y −= cos ( direction ) ∗ magnitude ;8 rectangle = boundaryRectangle ;9 warp. position =

BoundaryCheckMovingObjectRectangle (warp . position ,warp . velocity , rectangle ) ;

10

11 return Content ; �DetectWarpWarpCollision


�1 context WarpManager : : DetectWarpWarpCollision (GameContent

content ) : GameContent2

3 rectangle = new rectangle ;4 separation = new vector2 ;5 distance = 0;6 returnvector2 = new {X=0,Y=0} ;7 returnvector4 = new {X=0,Y=0,Z=0,W=0};8

9 for i from 0:warps . count −110 for j from i :warps . count11 i f warps [ i ] . position . z == warps [ j ] . position . z12 separation . x = warps [ i ] . x − warps [ j ] . x ;13 separation . y = warps [ i ] . y − warps [ j ] . y ;14 distance = squareroot ( x^2 + y^2) ;15

16 i f warps [ i ] . radius + warps [ j ] . radius − distance > 0.117 returnvector4 = BoundaryCheckObject ;18 warp [ i ] . x = returnvector4 . x ;19 warp [ i ] . y = returnvector4 . y ;20 warp [ j ] . x = returnvector4 . z ;21 warp [ j ] . y = returnvector4 .w;22 returnvector4 =

Physics . CalculateObjectObjectCollision ;23 warp [ i ] . ve loc i ty = returnvector4 ( x , y ) ;24 warp [ j ] . ve loc i ty = returnvector4 ( z ,w) ;25

26 foreach warp in Warps27 rectangle = BoundaryRectangle ;28 i f rectangle . contains (warp )29 (− ) Do Nothing30 else31 returnvector2 =

Physics . CalculateObjectRectangleCollision ;32 warp. ve loc i ty = returnvector2 ;33

34 return Content ; �MoveWarpPosition�

1 context WarpManager : : MoveWarpPosition (GameContentcontent , vector3 adjustment ) : GameContent

2 rectangle = new rectangle ;3 rectangle = BoundaryRectangle ;


4 Warps [Warps. count − pairCounter ] . x += adjustment . x ;5 Warps [Warps. count − pairCounter ] . y += adjustment . y ;6 Warps [Warps. count − pairCounter ] . z = adjustment . z ;7 Warps [Warps. count − pairCounter ] . position =

BoundaryCheckStaticObjectRectangle ;8

9 return Content ; �6.2.23 Warp

6.3 Data Detailed Design

The Hot Sticks application detailed data design is defined in this sub-section of the Software Design Document. Currently, there are no datastructures or methods which are not contained or defined within thedetailed module decompositions.

Annex A: GameScreenshots

A.1 Title Screen

171

172 ANNEX A: GAME SCREENSHOTS

A.2 Game Screen

A.3. MID SHOT 173

A.3 Mid Shot

A.4 Settings Menu

174 ANNEX A: GAME SCREENSHOTS

A.5 Pause Screen

A.6 Save Menu

Annex B: APIDocumentation

175

176 ANNEX B: API DOCUMENTATION

DocumentationConventions

C.7 Dates

C.7.1 In Prose

When writing dates in prose, it shall adhere to the Gregorian Cal-endar, and written out completely and in Big Endian format. Thismeans that a date in a paragraph shall be written as Month Date (withst|nd|rd|th), Year, where the month is written out completely, the nu-merical date without leading zeros, and the year is the full year. Afterwriting the year, it is to be followed with a comma, unless the sentenceends with the date. In addition, no sentence is permitted to begin witha 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 CalendarISO 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 cfgIndex idxTemporary tmpUser usrVariable var

Table C.1: Global Project Abbreviations Table

Correct Incorrect

Class Variables

Radius radiusBallTexture balltexture ball_textureABall aBall a_ball

Local Variables

tempRadius TempRadiustheBall 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 byOMG. If a method has the need to use pseudocode to illustrate part ofit’s operations, the entire method shall be written in pseudocode.

C.8.1 Naming Conventions

Variables used in Pseudocode elements must be descriptive of whatthe data it holds. Do not use terms like bd to represent a ball’s data,instead use the full words, ball and data. Exceptions to this can beseen in Table C.1.

Classes, Methods, and Class Variables

These shall be written using capital camel case, meaning that the firstletter of these elements are capitalized, there are no underscores, hy-phens, or spaces, and the letter of each word is capitalized. A fewexamples 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 classvariables, only they will be normal camel case. See below for someexamples

Looping Variables

The usage of foreach loops are preferred, but should you need a loopingvariable, use i, j, and k, in that order.

C.8.2 Reserved Words

The common development words below are reserved for special pur-poses,

context a class scoping operator that specifies the start of a new func-tion.

rec identifier used when defining a method to specify that it is a recur-sive method.

pre test a guard operation that only runs a method if the test conditionis true.

if test a block identifier that executes only when the test condition istrue.

else if test a block identifier that executes only when the previous blockedidentifier results in false and if the test condition is true.

else a block identifier which executes only when all associated blockstatements fail.

for initial, test, post looping operator which has an initialization, testcondition for determining when the loop operation shall termi-nate, and a post execution operation that runs at the end of theloop bock.

for var **from** range looping operator which steps on each numberin a range and assigns the value to var.

foreach DataType Var in List anonymous looping operator that iteratesover every element in array, storing the current array’s value inthe datatype var.

return ?var identifies what shall be returned after execution. If noth-ing is provided, the value passed is null


var = new ?DataType ?Size Initializes a variable. If a datatype is speci-fied, it places the constraint of the datatype on the variable. If sizeis provided, it allocates an array for the variable.

C.8.3 Included Libraries

There exists a few special libraries the define several utility functionsthat act as static classes.

Math

All standard math operators perform operations operate as floatingpoint 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 Varwhere if Var is less than the LowerBound, it is the value of theLowerBound, and if it’s greater than the UpperBound, it is theUpperBound.

Lists

All variables are considered as lists of variables, where the default sizeof a variable is a dimension one. Below are methods which a list canuse to manipulate themselves.

list[index ] Access the data held at the position of index. If the passedindex is negative, it starts from the end of the list. If the passedindex is larger than the list size, it wraps back to the beginning.

list.Find(var) Returns the index where the passed variable is locatedat. 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. Doesnothing 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 alist. This is the same as calling a foreach block and setting theoperation equal to the currently working element. For examplea.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 OCaml’smap function. Note that only in the scope of a ForEach method isa special variable called Me, which represents the current elementduring it’s iteration.

C.8.4 Construction

Elements with the same level of indention are members of the sameblock of execution. The basic flow of produced pseudocode shall startwith a method identifier which specifies the context, method name, in-putted datatypes with associated names, and the return type, followedby any form of preconditions, then to the algorithm of the method, andfinally to a return statement.

Examples�1 context Demo: : Factorial ( Integer Number) : Integer2 (− ) Computes fac t o r i a l3 pre : Number > 0;4

5 f = new;6 for i from 1:Number7 f ∗= i ;8

9 return f ; �Breaking this down we see several elementary elements,

• Note the formation of the first line: context class::method(DataTypeData): ReturnType

• Notice the single line comment is done by typing (-). This is morereadable than the common double slash.

• The pre command is typed first, and given a test condition. Thiscondition test if a number is greater than zero, because a factorialthat is negative does not make much sense.

• The usage of the new operator to identify the creation of a type-less variable. This means that anything can be put inside thevariable f.


• The for-from loop, which takes each value of 1 to Number, andstores it inside of i until the end of looping.

• The return construct.�1 context rec Demo: : Factorial ( Integer number) : Integer2 (− )Computes fac t o r i a l recursively3 pre : number > 0;4

5 i f number <= 16 return 1;7 else8 return number ∗ Factorial (number−1) ; �

The most notable thing in this code fragment is the addition of therec command at its definition. This ensures that the reader will knowthis function will be used again within itself. Notice the usage of return.It can be sent a static value, a variable, and methods.�

1 (∗ Gets an English l e t t e r grade based o f f of ∗ )2 (∗ a f loa t ing point percentage ∗ )3 context Demo: : GetLetterGrade ( Float percent ) : String4 pre : Percent < 1;5 pre : Percent > 0;6

7 letterGrade = new;8 i f percent >= 0.99 letterGrade = "A" ;

10 else i f percent >= 0.811 letterGrade = "B" ;12 else i f percent >= 0.713 letterGrade = "C" ;14 else i f percent >= 0.615 letterGrade = "D" ;16 else17 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 defi-nition shall not run.

C.8. PSEUDOCODE 183

�1 (∗2 ∗ Pushes a object to the class l i s t3 ∗ )4 context Demo: : Push(Some element ) :5 ObjectList .Add( element ) ; �

This tiny entry notes several new things,

• When a definition has no return type, you do not have to specifyany datatype on the head line.

• You don’t have to explicitly type the word return at the end of it’sdefinition.

• A return, however, may be placed at a location you wish to breakout of the definition.

• Notice the lack of a pre condition. If there are no restrictions onthe method definition’s calling, then you may simply drop any precondition.

• Note the variable ObjectList. There is not a previous definition forthis variable, because it is a class variable.

• Look at the datatype Some. This can represent any type of ele-ment: Integer, Float, Numeric, Boolean, or String.�

1 (∗2 ∗ Performs a scanning square root , which is essent ia l ly3 ∗ the square root function performed over an ent i re l i s t4 ∗ of values .5 ∗ )6 context Demo: : ScanSquareRoot (Numeric number) : Float7 pre : number.ForEach( >0) ;8

9 answer = new Float number. Size ;10 for i =0, i <number. Size , i ++11 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 toexpand lists and tests all conditions. This means that the pre conditionhere performs a test on every single Number which evaluates as trueonly when greater than zero.


Next, notice how the variable answer has both a datatype constraintand a size constraint. Also, note how the vanilla for loop is written, andhow the math operator is accessed.

Since we now have use the ForEach list operator, let’s revise theabove code a bit.�

1 (∗2 ∗ Performs a scanning square root , which is essent ia l ly3 ∗ the square root funct ion performed over an ent i re l i s t4 ∗ of values .5 ∗ )6 context Demo: : ScanSquareRoot (Numeric number) : Float7 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 callillustrates the power of the foreach construct, as it saves space, andconceptually makes sense.

COCOMO Estimation

D.9 Tasks

Cost Estimating For cost estimation, the publicly available COCOMOsystem will offer a cost estimate for Hot Sticks. Instead of calculat-ing SLOCs, we shall use the point values calculated by FPA. The keymodules shall be defined by the top level class diagram generated inDomain Analysis. This value shall be reviewed in each delivery of aworking product.

D.10 Module Decision

Breaking down our project, there are twelve definable classes that wewill calculate as a module.

• GUI : A generic interface for displaying data on a screen

• Collision : A manager that monitors collisions and actions to betaken 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 canbe 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 LowFLEX LowRESL Very LowTEAM HighPMAT High

RCPX Very HighRUSE HighPDIF HighPERS HighPREX LowFCIL LowSCED Low

Figure D.3: Coefficient Overview

• AI : The User Agent that can understand the game environmentand suggests/acts with artificial intelligence.

• Network : Network Dataflow manager that transmits and decodesmultiplayer information.

D.11 Point Calculation

As we’re still quite new to the actual concept of game development,every member is well educated in the meta-documents that revolvearound this. Because of that, we’ve noticed that the scale factors re-sulted in rather low numbers, but the effort multipliers were high.

D.11.1 Reasoning

PREC

• Understanding of Project: Considerable, as every has a generalunderstanding of the project requirements.

• Experience: Moderate, due to the lack of game development knowl-edge

• Concurrent: Some, as our platform, the XBox, does not change

• Innovation: Considerable, as there’s a considerable amount ofphysics computation.

D.11. POINT CALCULATION 187

FLEX

• Conformance to Standards: Basic, as our user right now onlyrequires 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 ex-treme of waterfall.

• Percent Architects: 60, as the Architects branch into the develop-ment side shortly after the coding begins next semester.

• Uncertainty in Key Elements: Considerable, as all staff are unfa-miliar 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 shallnot 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 workedtogether for about 5 months.

• Team Building for Vision: Basic, as DDD has a collective under-standing of the project, but not a unified vision yet.


Type Value Aggregate (x*1000)

RM 75 208SPP 75 208SPT 50 138

SSM DNA 0SQA 35 97SCM 42 110OPF 90 250OPD 90 250

TP 35 97ISM N/A 0SPE DN 0

IC 75 208PR 90 250

QPM 50 138SQM 75 208

DP 75 208TCM N/A 0PCM DN 0

Figure D.4: PMAT calculations

PMAT

RCPX

Rated very high, because the stability and reaction of data in videogames have to be realistic, or the user will not be totally immersed init. Also, the quality of the documentation will heavily drive the devel-opment of the program.

RUSE

Reuse will be high, due to the nature of pool having several similarelements (balls/warps and their applied forms on the GUI screens).Also, we will be adapting XNA into the game, thus, we will be reusing awhole library of code in our project.

PDIF

This is also high, as the platform is extremely stable. The hardwareand programming logic of embedded systems such as the XBox doesnot change without strong backward compatibility.

D.11. POINT CALCULATION 189

PERS

This is high, because our staffing will not change unless there are out-standing circumstances beyond the scope of the project.

PREX

This is low. The development of this project has no external costs; Theonly cost is man hours.

FCIL

There are very few tools needed for the development of this project, sothis 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 environmentand planning around 12 hour days, this means that the available timeis 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 hasworked with the C# programming language and XNA libraries; but weall have a strong background in programming in C++.

SUSE

• Structure: Nominal, as we all know how to write clean code, andthe documentation will support this.

• Application Clarity: This is clear, as all objects, by nature of ourgame, will have a high level of cohesion.

• Self Description: High, as our documentation model says to writewhat a section of code is supposed to do first, and then the codeis written to model this.


Figure D.5: First COCOMO calculation

Annex E: Weekly ProgressReports

191

192 ANNEX E: WEEKLY PROGRESS REPORTS

Annex F: Bug Reports

193