Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing (Focal Press Game Design Workshops) by Jere Miles, PDF, EPUB, 1138921777

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing (Focal Press Game Design Workshops) by Jere Miles

  • Print Length: 506 Pages
  • Publisher: A K Peters/CRC Press
  • Publication Date: July 27, 2016
  • Language: English
  • ASIN: B01MSRE0K0
  • ISBN-10: 1138921777
  • ISBN-13: 978-1138921771
  • File Format: PDF, EPUB

 

”Preview”

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxiii

Section i Background

Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

1.1 Who Plays Games? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1.2 How Are Games Made? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

1.2.1 AAA Studios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

1.2.2 The Indie Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

1.3 Who Can Make Games?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

1.3.1 Skills and Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

1.3.2 Working in the Industry. . . . . . . . . . . . . . . . . . . . . . . . . . .8

1.4 What Types of Games Are There? . . . . . . . . . . . . . . . . . . . . . . . .10

1.4.1 Role-Playing Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

1.4.2 Adventure Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

1.4.3 Platformer Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

1.4.4 Shooter Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

1.4.5 Action Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

1.4.6 Strategy Games. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

1.4.7 Simulation Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

1.4.8 Sports Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

1.4.9 Puzzle Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

1.4.10 MMO Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

1.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Vocabulary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Review Quiz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Design Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Chapter 2: Design Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1 Introduction to the Design Document . . . . . . . . . . . . . . . . . . .24

2.1.1 Do We Need a Design Document?. . . . . . . . . . . . . . . .25

2.1.2 Methods of Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

2.1.3 Logical Design versus Descriptive Design . . . . . . . .27

2.1.4 Mission and Vision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

2.2 Sections of the Design Document . . . . . . . . . . . . . . . . . . . . . . .29

2.2.1 Game Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

2.2.2 Game Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

2.2.3 Game Story. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

vii

2.2.4 The Game World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

2.2.5 Game Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

2.2.6 Game Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

Vocabulary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Review Quiz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Design Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Chapter 3: Using Unity and PlayMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1 Installing Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

3.2 Unity’s Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3 Using Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

3.4 Installing PlayMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.5 PlayMaker’s Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

3.6 State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

3.7 Using PlayMaker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70

3.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Vocabulary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Review Quiz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Design Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Section ii Building Blocks

Chapter 4: Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.1 The Purpose of Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.2 Do Games Need Characters?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.3 Traditional Character Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

4.3.1 The Hero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

4.3.2 The Shadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

4.3.3 The Mentor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

4.3.4 The Ally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

4.3.5 The Herald . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

4.3.6 The Trickster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

4.3.7 The Shapeshifter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.3.8 The Threshold Guardian . . . . . . . . . . . . . . . . . . . . . . . . 96

4.4 Game Character Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

4.4.1 Merchants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

4.4.2 The Quest Giver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.4.3 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.5 Character Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.6 Character Asset Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

viii

4.7 Importing Assets in Unity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.7.1 Back to Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.7.2 Importing 3D Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.7.3 Settings for Imported 3D Assets. . . . . . . . . . . . . . . . .111

4.7.4 From 3D Assets to Player Controllable Assets . . . 120

4.8 Character Control Systems with PlayMaker . . . . . . . . . . . . . 122

4.8.1 Designing the Character Response System . . . . . 123

4.8.2 Getting Input through Unity . . . . . . . . . . . . . . . . . . . 126

4.8.3 Building State Machines in PlayMaker . . . . . . . . . . 126

4.8.3.1 Moving Sancho . . . . . . . . . . . . . . . . . . . . . . .127

4.8.3.2 Rotating Sancho. . . . . . . . . . . . . . . . . . . . . . 138

4.8.3.3 Jumping Sancho . . . . . . . . . . . . . . . . . . . . . 140

4.8.3.4 The Camera Follows Sancho . . . . . . . . . . 145

4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147

Vocabulary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147

Review Quiz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Design Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Chapter 5: Non-Player Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

5.1 What Is Artificial Intelligence?. . . . . . . . . . . . . . . . . . . . . . . . . . 152

5.2 Some Different Types of Artificial Intelligence . . . . . . . . . . 152

5.2.1 Scripted Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

5.2.2 Random Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

5.2.3 Expert Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

5.2.4 Mathematical Behavior Modeling . . . . . . . . . . . . . . 157

5.2.5 Evolutionary Systems . . . . . . . . . . . . . . . . . . . . . . . . . . .159

5.3 Selecting an Artificial Intelligence System . . . . . . . . . . . . . . .161

5.4 Designing a Threshold Guardian. . . . . . . . . . . . . . . . . . . . . . . 162

5.5 Implementing the Threshold Guardian. . . . . . . . . . . . . . . . . 167

5.5.1 The Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

5.5.2 Patrolling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

5.5.3 Spotting the Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

5.5.4 Attacking the Player . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

5.5.5 Hurting the Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

5.5.6 Connecting the Attack and Health States. . . . . . . 194

5.5.7 Final Tweaks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

5.6 Prefabs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Vocabulary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Review Quiz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Design Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Chapter 6: Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

6.1 What Is a Story? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

6.2 Does My Game Need a Story?. . . . . . . . . . . . . . . . . . . . . . . . . . 204

ix

6.3 How to Tell a Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

6.4 The Building Blocks of a Story. . . . . . . . . . . . . . . . . . . . . . . . . . 206

6.4.1 Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

6.4.2 Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

6.4.3 The Problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

6.4.4 The Plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

6.4.5 The Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

6.4.6 The Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

6.5 Aristotle and the Greeks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211

6.5.1 Plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212

6.5.2 Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214

6.5.3 Thought. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215

6.5.4 Diction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215

6.5.5 Melody. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216

6.5.6 The Spectacle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216

6.6 The Return of Joseph Campbell. . . . . . . . . . . . . . . . . . . . . . . . .217

6.6.1 The Ordinary World. . . . . . . . . . . . . . . . . . . . . . . . . . . . .219

6.6.2 Call to Adventure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219

6.6.3 Refusal of the Call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219

6.6.4 Meeting the Mentor . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

6.6.5 Crossing the Threshold . . . . . . . . . . . . . . . . . . . . . . . . 220

6.6.6 Tests, Allies, and Enemies . . . . . . . . . . . . . . . . . . . . . . 220

6.6.7 Approaching the Cave . . . . . . . . . . . . . . . . . . . . . . . . . 221

6.6.8 The Ordeal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

6.6.9 The Reward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

6.6.10 The Road Back. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

6.6.11 Resurrection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

6.6.12 Return with Elixir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

6.7 Story Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

6.7.1 The Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

6.7.2 Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

6.7.3 Setting and Backstory . . . . . . . . . . . . . . . . . . . . . . . . . 225

6.7.4 The Problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

6.7.5 The Plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

6.7.6 The Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

6.7.7 Dialogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

6.8 Putting the Story into the Game . . . . . . . . . . . . . . . . . . . . . . . 231

6.8.1 Voice-Over Narration . . . . . . . . . . . . . . . . . . . . . . . . . . 232

6.8.2 Written Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

6.8.3 Character Dialogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

6.8.4 Journal Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

6.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Vocabulary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Review Quiz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Design Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

x

Chapter 7: Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

7.1 Environments for Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

7.2 Environments for Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

7.2.1 Controlling the Player. . . . . . . . . . . . . . . . . . . . . . . . . . 261

7.2.2 Informing the Player . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

7.2.3 Challenging the Player. . . . . . . . . . . . . . . . . . . . . . . . . 264

7.2.4 The Final Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

7.3 Creating the Terrain in Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

7.3.1 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

7.3.2 Terrain Collider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

7.3.3 Height Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

7.4 Dressing a Terrain with Standard Content . . . . . . . . . . . . . . 279

7.4.1 Painting Textures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

7.4.2 Adding Water. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

7.4.3 Adding Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

7.4.4 Adding Grass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

7.5 Adding Imported Assets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

7.6 Lighting the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

7.7 Boundaries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

7.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .310

Vocabulary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311

Review Quiz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311

Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312

Design Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312

Chapter 8: Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

8.1 What Are Game Mechanics? . . . . . . . . . . . . . . . . . . . . . . . . . . . .314

8.1.1 The Core Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . .314

8.1.2 Victory and Loss Conditions. . . . . . . . . . . . . . . . . . . . .315

8.1.3 Balance Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316

8.1.4 Story Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316

8.1.5 System Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317

8.2 Where Do Mechanics Come From?. . . . . . . . . . . . . . . . . . . . . .317

8.3 Designing Our Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318

8.3.1 The Checkpoint System. . . . . . . . . . . . . . . . . . . . . . . . .319

8.3.2 Respawning Sancho . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

8.3.3 Sancho and Water . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

8.3.4 Sancho’s Collection System . . . . . . . . . . . . . . . . . . . . 323

8.4 Implementing Our Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . 325

8.4.1 The Checkpoint System. . . . . . . . . . . . . . . . . . . . . . . . 325

8.4.2 Sancho and Water . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

8.4.3 Respawning Sancho . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

8.4.4 Sancho’s Collection System . . . . . . . . . . . . . . . . . . . . 338

8.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

xi

Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Review Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Design Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Section iii Bringing it together

Chapter 9: Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

9.1 How Audio Is Used in Games . . . . . . . . . . . . . . . . . . . . . . . . . 350

9.1.1 Music. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

9.1.2 Ambience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

9.1.3 Sound Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

9.2 Finding Audio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

9.3 Introduction to Audacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

9.3.1 Cutting Up an Audio File . . . . . . . . . . . . . . . . . . . . . . 357

9.3.2 Applying Effects to Audio . . . . . . . . . . . . . . . . . . . . . 360

9.3.3 Adjusting Volume Levels . . . . . . . . . . . . . . . . . . . . . . 364

9.4 Audio in Unity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

9.4.1 2D Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

9.4.2 3D Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

9.4.3 Playing Ambient Audio . . . . . . . . . . . . . . . . . . . . . . . 371

9.4.4 Playing Background Music . . . . . . . . . . . . . . . . . . . . 375

9.5 Using PlayMaker to Play Audio. . . . . . . . . . . . . . . . . . . . . . . . 375

9.5.1 Background Music . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

9.5.2 Ambient Sounds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

9.5.3 Effects for Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

9.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Review Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

Design Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

Chapter 10: The User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

10.1 The Types of User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 392

10.1.1 Menu-Based Systems . . . . . . . . . . . . . . . . . . . . . . . . . 392

10.1.2 Heads-Up Display Systems and Overlays. . . . . . . 392

10.2 User Interface Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

10.2.1 HUD Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

10.2.2 Menu Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

10.2.3 Basics of Color Theory . . . . . . . . . . . . . . . . . . . . . . . . 398

10.3 The User Interface System of Unity. . . . . . . . . . . . . . . . . . . . 402

10.3.1 Building Blocks of uGUI . . . . . . . . . . . . . . . . . . . . . . . 402

10.3.2 Constructing the Main Menu . . . . . . . . . . . . . . . . . . 404

10.3.3 Constructing the HUD Overlay . . . . . . . . . . . . . . . . .412

10.3.4 Polishing the Dialogue Work . . . . . . . . . . . . . . . . . . .418

xii

10.4 Updating the User Interface with PlayMaker. . . . . . . . . . . 420

10.4.1 Responses on the Main Menu . . . . . . . . . . . . . . . . . 421

10.4.2 Updating the Overlay . . . . . . . . . . . . . . . . . . . . . . . . . 430

10.4.3 Integrating the Dialogue System . . . . . . . . . . . . . . 440

10.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Review Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Design Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Chapter 11: Testing, Tweaking, and Publishing . . . . . . . . . . . . . . . . . . . . 449

11.1 What Is Testing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

11.1.1 Hunting Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

11.1.2 Play-Through Testing . . . . . . . . . . . . . . . . . . . . . . . . . 453

11.1.3 Unit Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

11.1.4 Break Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

11.2 Fixing and Tweaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

11.2.1 Fixing the Following Sheep . . . . . . . . . . . . . . . . . . . 458

11.3 Building the Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

11.3.1 Game Development Life Cycle . . . . . . . . . . . . . . . . 462

11.3.2 Build Options in Unity. . . . . . . . . . . . . . . . . . . . . . . . . 463

11.3.3 Creating a Stand-Alone Build. . . . . . . . . . . . . . . . . . 465

11.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

Review Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472

Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472

Design Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

xiii

Page Intentionally Left Blank

Preface

As we begin the process of looking into how to use Unity and PlayMaker to

create video games, we need to ensure that we are all on the same page,

pardon the pun. It is important that you know what this book is about and

what this book isn’t about. It is also important to be aware of the expected

skills and skill levels as we begin this book together.

What this Book is About

The focus of this book is to introduce you to game development. Through

this book you will get an overview of how to create video games. The process

of creating a video game includes developing scripts and programmed

behavior for the objects that are within the game to be played. As far as

the development of programmed behaviors, we will be able to ease the

transition into this process through the use of the PlayMaker visual scripting

plugin, which will allow us to bypass all the syntax and technical aspects

of programming and instead focus solely on the logical construction of a

program or behavior script. When it comes to developing a game, it is created

through the programming of the game, and the other parts (the graphics,

for instance) define what the game looks like, not how it is played or how it

behaves. As an example we could create a platform game with nothing but

colored blocks running around the game world jumping over empty areas.

The game would have all of the behaviors and playability of a platformer;

however, it would not look nearly as cool as the platformer games that are

currently on the market. The wonderfully cool graphics and animations of

video games are not what we will be creating in this book.

Who this Book is For

The concept for this book originated as a textbook for an introduction to a

game development course (SGD 111) taught at Wilkes Community College in

North Carolina. As a result, the target audience for this book is anyone who

is interested in learning about game development and how to create games.

It is assumed that the reader does not actually already know how to create

video games. For instance, if you have extensive experience using another

game engine such as Game Maker, you may be ready for a slightly more

advanced book than this one. However, if you have not worked with any

other game engine or if you have tried working with a couple but just could

not seem to get the hang of it, then this book should be a good starting

point to get you up and going with the Unity game engine.

Likewise, if you have extensive experience writing code in Java or C++ or

some other language, you may be better suited to find a book that works

xv

with the C# scripting language within Unity. This being said, PlayMaker

can be a very powerful tool for quickly prototyping an idea to see how

things work, in which case it can be useful to add PlayMaker to your skill

set. However, if you do have extensive programming experience, then you

may find the pace of this book a little slow as the target audience is for

those who have no experience with programming or those who have tried

programming but are a little fuzzy on it.

If you are an artist that would like to learn how to put your artwork into

Unity and get it to work with some game ideas of your own, then this book

should be very helpful in getting you started with the game engine and

also accomplishing the behaviors that you want associated with the art

content so that you can demonstrate your own game concepts and even

fully develop them into final products.

How this Book is organized

Each chapter of this book is laid out to focus on a specific topic with the

topics building on each other so that by the end of the book we will have

looked into all of the topics relevant to creating a game of our own. The

chapters each begin with a theory section, discussing the background and

various approaches to the given topic. Following the theory section, the

chapter will work on designing components for the game project based

upon the theories that were just presented. Finally, the chapter text will

conclude with an implementation section in which the created designs

will be built within Unity and PlayMaker to bring the theory of the topic to

life within our game project. Each chapter also ends with a set of review

questions that you can use to test your understanding of the concepts, and a

set of exercises that are intended to expand upon the examples presented in

the text of the chapter.

The idea of a design document will also be discussed during the course of

the book with each chapter adding to the design document for a game idea

of your own creation. By the end of the book, you should be able to take

your design document and create the game that you have designed. Within

each chapter, there are download boxes where you can get the version of the

game project that is within the book or other content to add to the project

as well as any video tutorials that have been developed to supplement the

chapter contents.

Book content

Section i: Background

• Chapter 1—Introduction

• Theory: Students will be introduced to the overall process of game

development including a discussion of the tools used, the skills

needed, the various jobs within the industry, and the vocabulary of

xvi

game development. A brief overview of the various genres and their

characteristics is also provided.

• Chapter 2—Design Document

• Theory: The design document is introduced, placing emphasis on

the rationale behind each section and the role that each section

plays in the overall development process of a video game project.

While much of this content is covered in the chapters that follow, it is

important for the reader to recognize the role of design, as it forms

the foundation for the vision of a game project.

• Design: We will introduce the overall vision of the Sancho Panza

project, which we will be working on during the course of the book

while encouraging the reader to begin the design work on a game

idea of their own by focusing on the primary game concept with

respect to the targets and vision of the game.

• Implementation: Based on the information from the chapter, we will

begin the creation of our design document that will cover the Sancho

Panza project and continue to add to it with each chapter.

• Chapter 3—Using Unity and PlayMaker

• Theory: We will introduce the tools that the book will focus on,

detailing how to download and install the software and providing

overviews of the user interfaces for both applications. A discussion

of the resources that are available on both websites is also

included.

• Design: The discussion focuses on what a finite state machine (FSM) is

and how to construct one based upon the plain English description

of what is intended to occur. Creating state machines to accomplish

examples are presented in the practical section.

• Implementation: We will demonstrate how to place objects within

Unity and move them around and manipulate other primary

components. Import assets and packages are discussed. Readers will

learn how to develop state machines to alter the properties of various

game objects placed within a scene. Through these state machines we

will dynamically make the changes that were originally done as static

changes in the previous demonstration of moving and manipulating

objects within Unity.

Section ii: Building Blocks

• Chapter 4—Characters

• Theory: We provide a background discussion of characters focusing

on the Jungian character types and their roles within a story and how

they interact with one another. The chapter also discusses the other

components of a character such as background, physical appearance,

emotional construction, psychological construction, environment,

and so on.

• Design: We will create algorithms (plain English) to define the

controller behaviors that our character should have based upon

xvii

decisions we made as the character idea was developed through the

theory discussion. From the algorithms, we will demonstrate how to

sketch state machines for these functionalities.

• Implementation: We will introduce the lead character of our book’s

example project, Sancho Panza, and demonstrate how to bring him

into Unity, and through the use of PlayMaker turn him into a character

that the player can control and play. The PlayMaker FSMs developed

will be the implementation of those constructed during the design

phase.

• Chapter 5—Non-Player Characters

• Theory: Based upon the characters that were developed in the last

chapter, we will look at how we can bring those characters to life

within our game project and begin to populate the world around

Sancho Panza. We will explore artificial intelligence (AI) by developing

our own definition of it and looking at the major types of AI that can

be developed and eventually deployed.

• Design: Based upon our work with the player character and the needs

of the project, we will design the behavior system that will govern the

decision-making process of a threshold guardian character during

the game so that they will be able to respond to events and actions

that occur as the player plays our game.

• Implementation: We will use PlayMaker to get our design working

with a spider added to the Sancho Panza project that will attack

and eventually kill the player character. This spider will have a

rudimentary AI system that will give it the abilities we need for this

project. These same basic principles will be applicable to any other

non-player character (NPC) within the game.

• Chapter 6—Story

• Theory: We will provide background information on the story, such

as the theme, plot and devices, backstory, premise, and so on. This

chapter includes a discussion of Aristotle’s ideas about stories. We will

also discuss the Hollywood 3-act structure and how it helps to guide

a story along. Joseph Campbell’s “Journey of a Hero” will also be

demonstrated as a potential blueprint for story creation.

• Design: This chapter covers the development of the backstory and

other story components for a game project. While much of this

design work may not make a direct appearance within the game,

we need to know the story of the game in order to know what will

happen during game play. We will also create potential quest systems

based upon the story and dialogue trees between the NPC and the

player character.

• Implementation: We will construct the basis for a quest system for

Sancho as well as an elementary dialogue between Sancho and his

wife Teresa. In addition, we will add a narrative introduction to the

game based upon the game’s backstory, explaining who the player is

and why they are on the island that they are on.

xviii

• Chapter 7—Environment

• Theory: We provide an overview of the level design including the

theme, atmosphere, and purpose. We focus on the level design as an

episodic structure, specifically as a chapter of the overall story that

is being told within the game. By recognizing the level as a chapter

in the story, it becomes more apparent what purpose the level must

serve and therefore what we as developers must do to keep our

players on track within the story.

• Design: Based upon the game design document and an

understanding of the purpose of a level, we will sketch out a first-

level environment for Sancho Panza to be dropped into. This level will

consist of the island that the story is going to take place on.

• Implementation: We demonstrate how to construct a level out of

standard assets within Unity as well as importing external assets. The

standard assets will be utilized to construct an exterior terrain for the

game world while the provided assets will build the town and other

props, all based upon our design work for this island.

• Chapter 8—Mechanics

• Theory: Mechanics are the underlying rules that govern the behaviors

of games; we discuss the guiding principles of these mechanics

within video games by placing them within different categories

to see how they impact the games that we play and ultimately the

games that we design.

• Design: Based upon the components and uses of game mechanics,

we will determine and plan various obstacles for Sancho to deal with

in the level that was constructed during the previous chapter. We will

demonstrate several different game mechanics within this design.

• Implementation: With a working Sancho Panza from previous

chapters, we will add things for Sancho to interact with (collecting

various objects, for instance) and tweak his controller system to

provide for the game mechanic functionality as depicted in the

design phase just completed based upon the original design

document.

Section iii: Bringing it together

• Chapter 9—Audio

• Theory: What role does audio play within a game? We introduce the

different types of audio that can be utilized and their specific purpose

within the overall game-play experience: music, ambience, effects,

and voice-overs.

• Design: We create an audio list that can be used within the project

that has been developed thus far. Along with this list, we will

sketch out locations of audio sources and potential areas of impact;

the purpose of this design component is to check for dead and

overpopulated areas within our overall audio scheme and plan “what

and where” before trying to add it.

xix

• Implementation: We will add various audio to our Sancho Panza

example game and learn how Unity 3D handles and works with

audio. Along with the audio being added, we will demonstrate how

to use PlayMaker to script when audio will play and when it will not,

so that user feedback (theoretical component) can be understood.

A section incorporating the use of Audacity (a free audio editing

application) for tweaking the audio files used in the game is also

included.

• Chapter 10—The User Interface

• Theory: Without a user interface, the player is very limited in what

they know of the game world. We discuss the various uses of the

system interfaces, ranging from menus to heads-up displays and

how to consider the impact of these components, both positive and

negative, to the overall game-play experience of the player.

• Design: We will create sample sketches of how the user interface

could look within our game. The purpose of designing the interface

through sketching is to consider what information should be

provided to the player and how to lay it out in a functional manner.

In addition, we will create menu systems, which means that we will

need to consider what options should be provided to the player of

the game.

• Implementation: We will add graphical user interface (GUI)

components to our Sancho Panza game project including a menu

system and heads-up display to provide information during game

play. PlayMaker will be used to update the GUI information and also

to respond to user interaction on the menu system.

• Chapter 11—Testing, Tweaking, and Publishing

• Theory: We will explore the various types of testing and how

to approach the testing of a game project with a specific focus

on our Sancho Panza game project. In addition, we will look

at the different stages of a life cycle of a video game project,

concentrating on the types of content that should be emerging

from each of the stages.

• Design: We will need to take into account the target platform from

our initial design and determine how to best build a deliverable

of our game for that system. It is also important to consider the

potential similarities between other builds. Finally, we will design

solutions to the bugs that we find through our methodical testing

of the Sancho Panza project.

• Implementation: We will demonstrate how to deploy our Sancho

Panza game as a stand-alone Windows deliverable, focusing on

the various settings that we can customize. In addition, we will

discover bugs within the project and properly document their

cause in order to repair them from the developer’s perspective.

xx

companion Website

Over the course of this book, we will be utilizing many resources that are

not included with the default installation on Unity 3D. These resources

include models, sounds, and textures. All of these can be obtained from

the companion website that has been created to accompany this book.

The website also includes links to video tutorials to enhance the content of

the book and a complete version of the project developed over the course

of the many examples. This project file includes the full and final project, but

scene files have been created to correspond with each chapter and section

as needed. The companion website also includes content for instructors

such as PowerPoints for each chapter and a set of sample test questions

for each chapter. Finally, the design documents developed through this

book are also available on the website: http://www.darkglass-studio.com/

Unity_PlayMaker_Essentials.

xxi

Page Intentionally Left Blank

Acknowledgments

Wilkes Community College Simulation and Game Development students

for serving as a test bed for the development of the content and the flow of

the material.

Sean Connelly at Focal Press for editing my rambling writing and putting

up with my incessant e-mails.

Unity Creative magazine, unfortunately no longer in print, for the availability

of the animated knight character for free use (Issue #3, September–October

2010).

Alex Chouls at Hutong Games for getting us into the Beta for version 1.8 of

PlayMaker.

Steve Finney at Arteria3D for the wonderful medieval town and the

characters that are used over the course of the example project.

Timothy Bivans at Enlitanment Studios, LLC, for some early feedback and

general advice on this project and then stepping up to do a full review of

the content of the book.

xxiii

Page Intentionally Left Blank

Section i

Background

Page Intentionally Left Blank

chapter 1

Introduction

Welcome to the essentials of game development with Unity and PlayMaker.

In this chapter, we will lay the basic groundwork for the game development

process by focusing on the tools and skills used as well as looking into who

plays games and what types of games there are to play. These topics may,

at first glance, seem to be obvious to all of us. However, there is a specific

vocabulary that is used within the game industry, and it is important that

we make sure we are all on the same page with these terms and with these

concepts. Game development is a wonderfully entertaining industry to get

into; however, it is not necessarily for everyone, and it is through this chapter

that we intend to help clarify some aspects of the industry and dispel some

potential myths, beginning with the idea that playing games and making

games are not the same thing.

• Who Plays Games?

• How Are Games Made?

• Who Can Make Games?

• What Types of Games Are There?

3

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

1.1 Who Plays Games?

Historically, this would have been considered to be teenage boys in their

bedrooms on Saturday nights. Interestingly enough, this classic misconception

of who plays video games is just as common today as it was back in the 1980s.

Many average people consider video games to be the activity and hobby of

the socially awkward teenage male. It is not our goal here to argue the merits

one way or the other with this view of gamers; we are just stating how gamers

are generally viewed by non-gamers. But what exactly is a non-gamer? Given

today’s society of smartphones, mobile technology, Facebook, gamification,

and the emergence of virtual reality and augmented reality, it is very difficult

to find someone that is an active member of our society that genuinely does

not play video games. Games today can be used for training, education,

scientific visualization, advertising, and, of course, entertainment. Table 1.1

outlines the actual statistics of who is playing video games today as compiled

by the Entertainment Software Association in 2014. As can be seen from this

information, the average video gamer is most definitely not the stereotype.

Keep in mind that these statistics are only for American gamers.

The idea of judging gamers and placing them within cute little boxes is not

only one that non-gamers engage in, but even gamers themselves want

to label each other and specifically label themselves to differentiate from

other gamers. This has led to the distinction of gamers as casual or hard core.

Originally, hard-core gamers were ones that invested a lot of time in the

games that they play and became experts at those games, knowing all of

the tricks and intricacies of their games. A casual gamer, on the other hand,

was one that played from time to time and did not take gaming seriously.

A casual gamer would play a game until it became too difficult and would

then quit, not wanting to invest the time required to become skilled enough

at the game to advance past those stages. However, with the birth of the

social gaming scene, the idea that a hard-core gamer is one that invests a

tremendous amount of time in the games they play, meant that the millions

of people investing hours into a game like Farmvil e were hard-core gamers,

taBLe 1.1 Video Game Players in 2014

59% of Americans play video

Average of two gamers in each

games

game-playing household

51% of American households own

Average household has at least one

a dedicated game console

game-playing device:

68% play on a console

53% play on a smartphone

41% play on a wireless device

Average age of gamer is 31

29% of gamers are under 18

32% of gamers are 18–35

39% of gamers are over 36

52% of gamers are male, 48% female

Source: ESA, 2014 Sales, Demographics, and Usage Data, Entertainment Software Association, http://www.theesa.com/

wp-content/uploads/2014/10/ESA_EF_2014.pdf, 2014.

4

Introduction

not casual gamers. As a result, the label hard-core gamer has shifted in recent

years to be those gamers that play games on consoles, or specifically those

gamers that do not play social games. But, once again, which of us does

not play a game on our smartphone from time to time? These traditional

labels are becoming more difficult to easily apply to a broad range of game

players. Thankfully, this need to label gamers as either hard core or casual is

beginning to fade as the amount of gamers and the types of games that we

play continues to grow and to cross traditional boundaries. More important

than whether we are casual or hard core, are the motivations behind why we

play, or to put it another way, what we do when we play games.

A researcher named Richard Bartle looked into the ways that people played

MUDs (multi-user dungeons) and discovered that there are essentially four

distinct player classifications or motivations as shown in Figure 1.1. As we

move to the left on this graph, players are more interested in the other

players that are in the game, while moving to the right leads to players

that are more interested in the environment. In today’s vernacular, we are

looking at the distinction between the PvP (Player versus Player) players

and the PvE (Player versus Environment) players. However, as we can see

with Bartle’s characteristics, those who are interested in other players in

the game world may not necessarily want to kill them, the player Killers

in the top-left quadrant, they may just want to hang out with them and

chat, the Socializers of the bottom-left quadrant. Swinging back the

other way, we have players who want to conquer the environment—the

Achievers in the top-right quadrant who want all the achievements and

unlocks, with the those who just want to explore the vast game world, their

only reward is knowing that they have seen what is just over the horizon—

the Explorers in the bottom-right quadrant.

At first glance, this may seem like a bunch of academic babble about why people

play games. However, knowing why people play games will help us create games

that they will enjoy playing, it is not enough to copy the features and mechanics

of other successful games, we need to understand what it is about those games

Acting

Killers

Achievers

Players

World

Socializers

Explorers

Interacting

FiG 1.1 The Bartle player types.

5

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

that the players enjoyed. In order to create rich and diverse video games, it will be

necessary for us to expand our gamer experience and try different things; in fact,

we may even need to try to figure out why these other gamer types exist and

what exactly they are getting out of playing the games that they do. As gamers,

we have our favorite games and genres, as gamers we play games for fun. But,

as developers we play games for work, we play games for research, and to be fair

on occasion we play our favorite games for fun. As developers, we need to move

out of our typical gaming experience and start looking at some different types

of games, what can we learn from them as developers and what can we learn

about the players of those games as developers.

Note

You are encouraged to look at the work of Jason VandenBerghe—he

started with the work of Bartle and expanded upon it to include more

extensive psychological modeling based upon the OCEAN personality

traits and merged those with player motivations to be able to map

personalities to games.

1.2 How Are Games Made?

There are essentially two approaches to the development of video games,

from an industry perspective. These include the AAA studio and indie studio

viewpoints. The way that these two approach the development of video

games has some similarities, but also some distinct differences that can be

attributed to scope of the game project and target audience. The scope of the

project refers to the size of the project as well as the amount of features to be

included. A game such as World of Warcraft has a much larger scope than does

a game such as Farmvil e. Notice that the scope of the game had nothing to

do with the success of a game; this is a vital concept for us early on as it is easy

for us to think that we need to build enormous game worlds in order to be

successful at game development. Success in game development is ultimately

measured differently by different people based upon your goals. If your goal

is to create a WoW killer, then unless your project passes World of Warcraft, the

project will be a failure. However, if your goal is to build a game that you and

your friends can play together then you will be a success if you can get the

project finished and into your friend’s hands. This may make it seem as though

the second example would be easier to be successful at, but as we break these

two approaches down, we will see that they are both equally challenging.

1.2.1 AAA Studios

AAA studios are what many of us think of when we consider the game

development industry; these are the big names that create the big titles.

Companies, such as Electronic Arts, BioWare, Bethesda, and Insomniac, are

all examples of AAA studios. With this approach to game development, large

teams are created for each project with the responsibilities divided among

6

Introduction

the various team members. This type of approach creates an environment of

very deep specializations, with each team member only responsible for their

small portion of the project.

AAA studios may easily spend 2 to 4 years with over 200 developers working

to bring a project to the market. Along with the time and personnel, there may

also be an enormous monetary investment into the project. This investment

means that the game must be successful enough as a commercial project in

order for the parent company to recoup the initial money invested, it is just

basic business. If it is necessary to maximize the likelihood of getting a certain

amount of money back once the game has been released, then it is less likely

that you would be willing to experiment and try new things that may not work.

Rather, you would be more interested in looking at what has been successful

and trying to leverage that within your own project; once again this is just basic

business. This is not to say that big studios do not develop amazing games,

as they most definitely do, we are simply pointing out that the bigger the

studio the more business decisions there are that must be made. We are also

not trying to imply that AAA studios do not innovate, as many of them do, we

are only pointing out that there are times when decisions must be made with a

business perspective as opposed to a game design or game-play perspective.

1.2.2 the indie Studio

The indie studio is a relatively newcomer to the game development process, at

least as a viable business venture for individuals. With the release of powerful

game engines such as Unity and Unreal, the average person can develop video

games using the same tools and technologies as the big studios. Also, with

the rise of digital delivery mechanisms, it is easier for a small studio to get their

games to market and find buyers, especially with the rise of the mobile systems

as a gaming platform. Indie studios are usually small operations with less than

50 people working on projects, though many independent studios have fewer

than 10 people toiling away on a given video game. With this smaller approach

to game development, there are many things that the indie studio simply

cannot do as the skills available to the studio are limited to those possessed by

the few employees or those that may be purchased through contract workers.

It is very common for an indie studio to divide the labor up very differently

from the AAA studio approach; one or two programmers will be responsible

for all of the coding, and one or two art people will be responsible for all of the

three-dimensional work including animations and one person may be handling

all of the two-dimensional work. Indie studios can develop some amazing

games; however, due to the number of people working on the projects, there

are business decisions that these smaller studios will have to make as well,

namely the size and scope of the projects that they work on.

1.3 Who can Make Games?

As technology has changed over the years, the creation of games is no longer

limited to only those that can program a computer. With the introduction of

tools such as PlayMaker, we can start making games without having to focus

7

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

on the intricacies of programming languages. This is freeing up the possibility

for many people to begin to make video games. We have worked with kids

as young as fifth graders and on into the collegiate years and beyond. The

only trick to making video games is that it will require a commitment of time

on your part, a willingness to work through some very challenging and at

times frustrating topics and skills until you have mastered them to a level that

you can use them to make what you would like to make. The bottom line is

that if you are interested and if you are willing to practice then you can make

games. If, however, you are not willing to put the game controller down to

practice your game development skills then being a game developer is not

a good fit for you. It is best to be completely honest with yourself and to

recognize that if you want to be a game developer, you will have to work at

it and practice it; parts of it will be very challenging to master. You will not

become a great game developer in a weekend, or a week, or a month, or even

after reading this book. To become a great game developer will take time,

dedication, patience, and practice. You will learn something new with every

project that you work on which is part of what makes this field so exciting

and fun to work in.

1.3.1 Skills and Jobs

There are a wide range of skills needed to create video games, though it is

not necessary for one person to possess all of these skills in order to work

within the game industry. For our task, we will focus on the types of skills

needed in order to create games and the software tools that can be used to

practice those skills. It is not our goal to advertise or sell a specific application

over any of the others; however, there are some that are industry standard,

and as such if your goal is to work within the game industry as a content

creator or game developer, you would be well served to go ahead and learn

those tools rather than the alternatives, though we have included alternative

applications with our list of recommended software. We are not going to

list every single skill that could exist; rather it is our goal to focus on a high

view of the skills. Table 1.2 lists the skills as well as the potential software

tools and job titles that could be associated with these skills. As can be seen

from this list, to create a game requires a lot of different skills, meaning that

we as individuals may be able to find our niche within the industry without

necessarily knowing all of the skills, then again it would be fun to be able to

do it all, especially if you are an indie developer. However, for AAA studios,

focusing on a couple of these skills that you most enjoy would be the way to

go as far as preparing yourself for potential employment at a major studio.

1.3.2 Working in the industry

The first step is to decide if you want a job in the industry or if you want to be

a game developer. In order to get a job as a game developer, you will need to

develop the skills to do the work. There are no magic degrees to guarantee

that a studio will hire you. In order to develop the skills, however, you may

want to experiment with the different aspects of game development to find

8

Introduction

taBLe 1.2 Skills and Some of the Associated Job Titles

Skill

Description

Software

Jobs

Three-dimensional

Creation of all

3ds Max

Character modeling

modeling

three-dimensional mesh

Maya

Prop modeler

content: characters, props,

zBrush

Environment modeler

environments, etc.

Blender

Hard-surface modeler

Three-dimensional

Building animation sequences

3ds Max

Character animator

animation

to provide motion for

Maya

Character rigger

three-dimensional meshes.

Blender

Three-dimensional

animator

Texture artist

Creation of two-dimensional

Photoshop

Texture artist

graphical content to be used as

Illustrator

UI artist

textures on three-dimensional

GiMP

meshes or as skins of user

interfaces.

Concept artist

Develop sketches of worlds and

Photoshop

Concept artist

characters in order to assist the

modelers with their job.

Programming

Develop the scripts to get the

C++

AI programmer

game and content to behave

C#

System programmer

and respond the way that it

UI programmer

should.

Level design

Combine the graphical assets

Unity

Level designer

within a game engine in order

Unreal

Environment designer

to create playable levels for the

CryEngine

game.

Audio editing

Create and edit audio for use in

Audition

Sound engineer

video games including both

Vegas

Music composer

music and sound effects.

Audacity

an area that really excites you and that you enjoy—this is where college

programs in game development can be enormously beneficial in providing

guidance and training into the various aspects of the industry. In order to

get the skills needed, you will need to work very hard at making games.

It is the goal of this book to introduce you to the process of creating a game,

but not the processes of creating the assets that go into the game, that is,

an entirely different topic for another book. The game industry essentially

has three major categories: business, content creation, and game creation.

The business component is all of the financial, marketing, and legal kinds

of things that go into having a business in today’s global economy; this is a

very important aspect, and this would be a job within the game industry.

Generally speaking, though, when we say that we want to work in the game

industry, we mean that we want to make games. This brings us to the other

two categories: content creation and game creation. Content creation

involves all of the skills needed to create the many things that we see and

hear when playing a game. Music, sounds, characters, buildings, lights, and

so on—all of the content that is in a game must be created by someone as

9

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

mentioned previously; we will not be focusing on these skills. The game

creation process generally involves the programming and compiling of the

assets that have been created; it is this process that we intend to introduce

through the course of this book to help you to decide if making games is for

you or not.

There is a final way of looking at working within the game industry and that

is making games as a hobby. There is nothing wrong with making some

games on the side for you and your friends to knock around with. The goal

is simply to make a few games that you have fun playing with your friends or

other people. In many ways, being a hobby game developer is far easier as

there is no restriction on what you can or cannot do, you are limited only by

your imagination and the amount of time that you are willing to put into the

various ideas that you have.

1.4 What types of Games Are there?

Types of games are defined and categorized as genres. A game genre

provides an outline of a specific game as far as how the game might look as

well as the essential game-playing elements. Game genres are important

to us as developers as they assist us in defining game types but also help us

to communicate basic game features to help streamline some components

of the design process. For instance, if we were to say that we have a cool

idea for a platform game, the people that we are talking to will immediately

picture the basic elements of platform games, thereby saving us from

having to describe all of those details. There is a flipside to this, however, in

that our gamers will have certain expectations from our game as well, and

it is difficult for us to break out of those expectations. As another example,

players of a first-person shooter game expect to have some information

on the screen informing them how many bullets they have left and how

healthy they currently are. This may seem fine, but what if we want to create

a hyperrealistic shooter in which the player needs to either count the rounds

they fire or check the clip to see how many shots are left. While that example

is technically still a first-person shooter, it will not be matching the gamer’s

expectations of games within that genre. The following sections will detail

these genres.

1.4.1 Role-Playing Games

Role-playing games are ones which allow the player to create a character

representation of themselves within the game. The created character may

be one that closely matches the real person or may have nothing at all in

common with the player of the game. The character will be defined by a set

of attributes and skills which they can perform; and how well the character

does certain actions within the game will be determined by these skill values.

Over the course of game play, the player will be able to level this character by

performing actions that wil grant experience points; these experience points

may then be applied to the character to improve skills or acquire new skills.

10

Introduction

FiG 1.2 Skyrim by Bethesda, is an example of a role-playing game.

Players can also acquire items to equip their character with, such as armor and

weapons to help the character be more successful within the game world.

These games have their origin in the heritage of the pencil and paper

role-playing games such as Dungeons & Dragons but have matured on their

own within the video game world. These games may be played in either a

first-person perspective, in which the game is viewed through the eyes of

the character, or a third-person perspective, in which the game character

is visible. Bethesda is famous for making role-playing games such as Skyrim

(shown in Figure 1.2) or Fal out.

1.4.2 Adventure Games

Adventure games had their heyday in the 1980s and 1990s, especially under

the guidance of studios like Sierra. There are a couple of types of adventure

games that we will look at: the traditional point and click and the text

adventure. Generally speaking, this style of game lacks violence and is not

dependent on the reflex abilities of the game player; rather the focus of

game play is on solving puzzles and riddles, some of which may be incredibly

obtuse. With the point and click variety, the player is presented with a scene

and they are able to click items within the scene to interact with things, for

instance, clicking a roll of tape will pick up the tape and add it to the player’s

inventory. As the player interacts with objects on the screen, they can solve

potential puzzles that are presented to them. For instance, in The Book of

Unwritten Tales: The Critter Chronicles (shown in Figure 1.3), it is the player’s

responsibility to figure out how to get the human character away from the

monster (at least in the depicted scene). The player has various hints and

clues within the scene and as they click on things and combine objects in

their inventory they can solve the puzzle that the developers have created.

11

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

FiG 1.3 The Book of Unwritten Tales: The Critter Chronicles developed by KING Art.

Text adventures, on the other hand, do not utilize any graphics at all so there

is nothing to point and click. These games commonly called interactive

fiction are entirely in text with the world being verbally described and the

player entering commands through a text prompt. The systems of these

games can be extremely picky about the exact words that they recognize,

leading the player’s to sometimes have to solve the riddle of how the system

wants them to word a specific command aside from the other puzzles and

riddles that are presented. This genre was once a very large genre in the PC

world when graphics were not very powerful; however, today this is a niche

genre at best. Still, for narrative developers, the text adventure genre can

be an excellent place to spread your wings and experiment on story ideas

without having to focus on graphics and other content.

1.4.3 Platformer Games

Traditional and classic arcade games from the golden era of the arcade are

members of the platform genre. These games include such classics as Pac-Man

and Donkey Kong. Games of this genre are defined by the player being

required to complete certain tasks that require reflexes or quick thinking in

order to avoid being destroyed by something within the game. While there

may be enemies that challenge the player and that can be destroyed by the

player, these confrontations are not the primary focus of the game; the game

play is more centered on solving puzzles and challenges through reflex skills

than on fighting and violence. Even the fighting that does occur, such as boss

battles at the end of levels, require a degree of problem solving in order to

discover the boss’ pattern and counteract it. These games generally have a life

system in which the player has so many lives and after they have lost those

lives the game is over. The game play is entirely dependent on the game

12

Introduction

FiG 1.4 Super Mario Galaxy by Nintendo.

player’s skill with pushing buttons and other control mechanisms. While the

examples thus far have been two-dimensional games, we can create platform

style games within the three-dimensional game world as well; Super Mario

Galaxy (shown in Figure 1.4) is an example of a three-dimensional platformer

game as it contains all of the elements of this style of game.

1.4.4 Shooter Games

Shooter-based games revolve around the player fighting with and destroying

bad guys. When we hear the genre shooter, we immediately think of guns;

however, a shooter game could be created without using a gun as the primary

weapon for the main character. Keep in mind that these genres are intended

to provide a generic outline of the game play and game experience, not

necessarily a literal perspective of those. A shooter game can be either a first-

person perspective, in which the player sees the game world through the eyes

of the in-game character; or a third-person perspective, in which the character

controlled by the player is visible. In either case, the player will be given a wide

variety of weapons to use as they attempt to defeat the enemy of the game.

The game’s enemy may be alien invaders, in the case of Halo, or a terrorist

organization, in the case of Call of Duty, or it may even be other players in the

case of Team Fortress 2 (shown in Figure 1.5). With shooter-type games, there

are no puzzles to solve, or if there are they are rudimentary in nature. The only

challenge presented to the player is the number of enemies that are trying

to destroy the player and the limited ammunition and health that the player

has for the current level. These games can exist in single-player or multiplayer

modes and can also have complex story lines for the players to experience or

no story at all except for what the player creates during their game play.

13

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

FiG 1.5 Team Fortress 2 developed by Valve.

1.4.5 Action Games

The action genre of games is almost a catchall in that it contains so many

games that could almost fit into other categories. Racing games, for

instance, could be labeled as a simulation or a sports game, but are many

times thrown in with action games. The same goes for what has become

known as the action–adventure genre—games such as Assassin’s Creed IV:

Black Flag (shown in Figure 1.6) have much in common with the shooter

genre but also much in common with the platform genre. Fighter games

FiG 1.6 Assassin’s Creed IV: Black Flag developed by Ubisoft Montreal.

14

Introduction

such as Street Fighter and Mortal Kombat also fall into this action genre of

games. Essentially, an action game is a game in which there are many things

for the player to do or a conflict type of game in which there are attack

combinations and other rapid button sequences. Game play varies slightly

depending on the specific game, but as a hybrid type of genre, the game

play can be heavily influenced by the other genre that the specific game

is drawing upon. At its core, the action genre requires fast reflexes from

the player as well as knowledge of the different button combinations and

sequences possible with the controllers.

1.4.6 Strategy Games

Strategy games have two subcategories that need to be considered: real-time

strategy and turn-based strategy. In either case, the central feature of a

strategy game is the player’s ability to process data and information in order

to determine the best potential way to beat opponents. Strategy games

can be played against artificial intelligence (AI) opponents or against other

human players or can be played in teams (against other teams of humans or

computer-control ed teams). Strategy games require resource management

as there are limited quantities of resources within games that must be utilized

for the construction of other game units needed to become more powerful

or in some other way expand your side’s advantage over the other side.

Examples of strategy games include Civilization V and Europa Universalis IV

(shown in Figure 1.7). Turn-based strategy games allow the game play to

pause between turns as each player develops a plan of action for their side

to perform during the next turn sequence. Generally speaking, the player

is allowed to take as long as they want to formulate a strategy during a

turn-based game making these very mental and completely independent

FiG 1.7 Europa Universalis IV by Paradox Interactive.

15

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

of the gamer’s reflexes or memorization of shortcut keys. Real-time strategy,

on the other hand, has all of the players taking their turns at the exact same

time with no pause in the game action. Whichever player can locate and

get a worker to that treasured pile of wood is the player that gets to keep it,

unless the other players come flying in with massive troops and kill the initial

player’s lone worker. Either type of strategy game presents the player with

a view of the game world with some parts of it hidden until the player has

discovered those regions. The player makes the best choices that they can

with the information that they have available to them at the time that a

choice must be made.

1.4.7 Simulation Games

The goal of a simulation game is to mimic, as closely as possible, some

real-world system. We can create games that are simulations of the business

world such as Capitalism Plus or simulations of city management such as

Sim City. It is common for simulation games of those types to get somewhat

confused with strategy games due to the strategic elements of the game.

However, the games are simulating a real-world system. Whatever is

simulated, we must get the game to not only act like that thing, such as an

airplane in Microsoft Flight Simulator X (shown in Figure 1.8), but the game

must also accurately simulate the appearances of the control mechanisms

for what is being simulated, such as a crane. These types of games have

often been viewed as a niche market due to the level of expertise and

knowledge that the player is required to obtain in order to play the game

successfully; however, with the rise of gamification, which is using game

technology to create applications that are not explicitly a game, these

types of games are becoming more popular outside of the gamer world,

FiG 1.8 Microsoft Flight Simulator X developed by Microsoft Game Studios.

16

Introduction

thereby making them a more popular type than they used to be. Just as

these games are very demanding on the player, they are equally demanding

on the developer as we must become extremely knowledgeable in the

subject matter that we are simulating in order to know what should happen

and why so that we can properly develop the software to generate that

required behavior.

1.4.8 Sports Games

Sports gamers are an interesting hybrid genre. They are a hybrid because

many of them will utilize the reflex systems of a platform game by requiring

the player to click the correct button at the proper time in order to throw

or hit a ball in combination with the simulation genre as the goal of these

games is to get as close to the real sport as possible. Within the sports

genre, there are entire simulation systems that do not utilize any direct

player control during the games, such as Out of the Park Baseball or Football

Manager. These games have a very strong simulation engine at their core

and through statistical modeling are able to provide the gamers with a

simulation of these sports and the businesses of these sports. On the other

side of the sports genre are games such as Madden or FIFA in which the

player takes direct control of a participant within the sport and through

reflex button presses can take an active role in determining the outcome of

each individual game played. These games are attempting to provide the

player with an experience that is as close to the real sport as possible, and

it will be very interesting to see how these games utilize virtual reality over

the next few years (Figure 1.9).

FiG 1.9 R.B.I. Basebal 15 developed by MLB.com.

17

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

1.4.9 Puzzle Games

With the explosion of Facebook and mobile gaming, the puzzle category

of games has found a new home and is enjoying a huge popularity at the

moment. Puzzle games revolve around requiring the player to find a solution

to a specific puzzle before them. Unlike adventure games, there is no story

or reason for the puzzle per se; it is just a puzzle that the player must solve to

win. Hidden object games are puzzle-type games as players try to find the

objects that are hidden among other objects on the screen within a specified

time limit. Matching games such as Bubble Pop or Bejeweled 3 (shown in

Figure 1.10) are also puzzle games in which the puzzle is to figure out how

to move your pieces around in order to create a match of at least three of a

kind. Due to their quick play nature, these games are very good choices for

mobile gaming and can even be inserted into other genres to provide the

player with a puzzle to solve in order to advance within a level. Stories can be

added to the game experience to provide a background for why the player is

solving the puzzles; however, the story is not necessary to the experience of

the game as the player’s focus is to score as many points as possible within

the small amount of time that is allotted for each game-play session.

1.4.10 MMo Games

Online games provide players with the opportunity to explore the virtual

game worlds as an individual or with groups of players. Players are given the

opportunity to create a character that will be their representation within the

game world, just like with role-playing games, and through the game-play

experience allow these characters to grow and become better at performing

FiG 1.10 Bejeweled 3 developed by PopCap Games, Inc.

18

Introduction

FiG 1.11 Star Trek Online developed by Cryptic Studios.

certain tasks. The game play itself is generally of the action–adventure game

style combined with the role-playing style along with the added benefit

of being able to play the game with small or large groups of other players,

including playing against those players. Traditionally speaking, MMO games

charged a monthly subscription fee, but in recent years there has been a

trend toward a free-to-play model in which gamers can get and play the

game for free, but there are certain cosmetic features which will cost money

if a player desires those additions in their game. These games also have large

story lines with many quests along both the primary story and also along

other side story lines that may involve the player’s selected class or character

race. It is interesting to note that while these games are very popular,

according to the Entertainment Software Association (ESA), among online

games that are played, only 4% of the online games played are MMOs, most

of them are casual or puzzle games, once again due to the explosion of

Facebook and mobile gaming (Figure 1.11).

1.5 Summary

Throughout this chapter, we looked at game development from a bird’s-eye

type of perspective. It was not our goal to get into the nuts and bolts of

game development and come out of this chapter with a full knowledge of

how to create a game. Rather, we have emerged with an understanding and

realization that games, gamers, and game developers are a wide range of

areas with different specializations and preferences. Now that we have a basic

foundation for the background of the video game industry and how things

theoretically work in this world, we are ready to continue and begin the

19

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

process of designing a game of our own. We have come face to face with the

reality that playing games and making games are two very different things

and that our vast experience as game players may help give us ideas to draw

upon as game developers. We have also taken a look at the many different

skills that are used when creating a video game, and while this book will

only focus on a specific subset of those skills, we are aware that what we will

learn and practice throughout this book is part of the larger family of game

development skil s.

Vocabulary

Gamification

Role-playing game

Hybrid

Simulation game

Strategy game

Adventure game

Text adventure game

Sports game

Puzzle game

Action game

Shooter game

Platformer game

Genre

AAA studio

Indie studio

Casual gamer

Hard-core gamer

Real-time strategy game

Turn-based strategy game

Review Quiz

1. What are the differences in the Bartle character types?

2. What are the differences between an AAA and an indie studio?

3. What is the average age of a gamer?

4. Approximately how many Americans play video games?

5. What software can be used to create character models?

6. What software can be used to create levels for games?

exercises

1. What types of games do you like to play?

a. Why do you like to play these games?

2. Given the two options of an AAA studio or indie studio, which route

would you be more interested in pursuing and why?

20

Introduction

3. Considering your favorite genre of games, what could you add to it to

make it a hybrid with another genre?

4. Considering the games that you like the least, try playing games from

those genres with the goal of discovering what those players get from

the game. Keep in mind that the goal is not the cliché answer defining the

genre characteristics; rather the goal is to actually try to understand these

games and gamers.

Design Document

Throughout this book, we will be demonstrating the design document for

the Sancho Panza project that is built during the writing of this book. Each

chapter will add a new section to the document, and in each chapter, you

will be working on a design document for your own game idea, whatever

that may be. The next chapter will introduce you to the design document

and get this process started; for now, take a deep breath and let’s start

making a game.

21

Page Intentionally Left Blank

chapter 2

Design Document

Generally speaking, once we have a cool idea for a game, we are all in a

rush to get to our computers and start building the game. However, as we

will see in this chapter, it is important for us to take some time and think

our game idea through more thoroughly and make sure we are ready to

build this game. Design documents are an interesting aspect of game

development as they are often overlooked, but at the same time, they

are very difficult (if not impossible) to fully develop without. This leads to

a chicken-and-egg type of situation in which we need to create a design

document in order to build a game, but in order to create the design

document, we need to know how to build a game. We will address this

throughout the book by building our own design document as we go along

and also by having you work on your own design document as you learn

new concepts and skills. Rather than create a full design document in one

go, we will only create the pieces that we are ready for and finish with a full

23

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

document by the end of this book. In this chapter, we will introduce the

design document and why we should use one.

• What Is a Design Document?

• Do We Actually Need a Design Document?

• Are There Other Ways We Can Make a Design Document?

• What Are the Parts of the Game That We Should Design?

2.1 introduction to the Design Document

The design document is often an intimidating aspect of game development.

Throughout software development the role of the design document serves

as a guiding light for the project that is under development. During the

development of a design document, developers force themselves to focus

on both the small and the big picture of the project at hand, including a

game project. Before we sit at our computer and begin to implement a

game idea, we need to know what it is that we are going to be building;

otherwise, we will have issues with continuity and consistency within our

game idea.

This may be better illustrated through a couple of quick examples.

Consider that your friend calls you up and says “Hey, wouldn’t it be really

cool if we made a game where the player could have infrared vision?”

Our immediate response may be to agree that this would be cool and to

charge over to the nearest computer and start creating some textures

in Photoshop to mimic objects as they may appear when viewed with

infrared light. However, as you have probably already noticed, we actually

do not know what objects to create, so should we just start creating

anything that comes to mind or should we spend a little more time with

this idea and flesh out some more details to get a better idea of exactly

what this game could possibly be and if we should even continue working

on it. Other questions that come up may include whether the infrared

vision is a constant or something that the player can turn on and off. If it

can be turned on and off, then we will also need to create textures for the

noninfrared versions of the objects. This infrared idea may be a great start

for a game concept, but we are going to need to know quite a bit more

about the game before we are ready to start building it and this is where

the design document comes into play.

Design documents should contain as much information and detail about

your game idea that you can think of, even if it is not going to show up

in the game. This document is your repository of every thought that

you have had about your game. It should also include any sketches or

pictures that carry some significance for the game whether it be an exact

concept of what you want something to look like or just some really cool

building that you saw somewhere that could be a good inspiration for

something in your game. We also need to consider how the game is going

to be built, the logical flow of how these ideas will go from abstract cool

24

Design Document

things to functioning behaviors within our game world. The more detail

and the more thought that we put into this design process, the less time

we will spend doing unnecessary activities once we begin the actual

implementation process of our game.

2.1.1 Do We need a Design Document?

The short answer to this question is “Yes, we do need it.” But the longer

answer to this question is a little more interesting. We need a design

document, but our design document does not need to be your design

document, necessarily. More importantly, we need to quickly recognize

that the design document is intended to be a guideline for the game

project and that each game project is unique and somewhat different

than previous projects. There have been many games that have been

released that have also had a design document appear on the Internet.

In these cases, we can see that the final product of the game does not

always match what was specified in the original design document; the

game Neverwinter Nights is an interesting example of this. As long as we

remember that the design document is a guideline for the project and

not the final word on any aspect of the project, we should not have any

difficulties. Always remember that the most important parts of a game are

whether it is playable and whether it is fun. If there is an idea within the

design document that turns out to not be fun, then the idea should be

dropped. At the same time, if something is in the document that just does

not work within the game itself, the idea should be dropped or be seriously

reconsidered as to how it is being implemented and working within the

game. For instance, consider the previous thought of a character with

infrared vision, if implementing that concept suddenly makes it difficult for

the player to differentiate between a wall and a door, because they are the

same temperature, and as a result of this difficulty, the player cannot figure

out how to get out of a room, then this infrared idea needs to be reworked

and might even be dropped from the game altogether.

The bottom line is that we need to spend some time designing our

game before we ever try to build the game. We need to make sure that

we understand what it is we will be building before the implementation

begins. There is a trend in the game industry at the moment to move

away from this formulistic approach to a more fluid and agile style of

development. However, even with this trend, there is still some level

of design that is going on prior to any building. Another example may

help to bring this idea home. We have decided to hire a 3D modeler

and animator to help with our current game project. After hiring the

new modeler, we sent the modeler an e-mail letting them know that we

need four new characters created with animation sequences by next

month. To which the modeler responds by e-mail asking what characters

they need to make. At this point, it would be wonderful to send them a

design document of some sort so that they could see what we need; and

it would not be good if our response was something along the lines of

25

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

“well, we’re not really sure yet, but we are going to have infrared vision

in the game, so, you know something like that.” Design is very important;

it tells us where we are going; however, we may not take the exact path

we documented to get there, but we do need to know where it is that we

are going.

2.1.2 Methods of Design

Thus far, we have been referring to the design document; however, this

wording brings certain images to mind and those images may cause us to

restrict our thinking of how to create a design document. The first step, even

though A Word document is being used and even though we have included

a Microsoft Word document with this chapter as an example, does not mean

that it actually needs to be something that is formally typed and entered into

a computer. Our preferred method of design documentation is actually a

composition journal that can be picked up at almost any store. We tend to keep

the journal and pen in our backpack, which is with us wherever we go and as a

result if a thought or idea comes up, it can be quickly written down before it is

forgotten.

Perhaps typing and writing is not your thing, in which case feel free to use

a sound recorder on your cell phone and dictate your design ideas, or buy

a whiteboard and keep it in your room to jot down ideas. We have even

known someone that bought whiteboard-type paint to paint the walls in

one of his rooms with this special material that can be written on and erased,

with this approach the whole wall became his design document for various

projects.

There are some pros and cons to be aware of and to consider, but ultimately the

documentation choice that works best for you is the one that you should use.

A computer document is nice as it can provide one source or location where all

of your game design ideas are located. Any pictures or sketches that you may

have can easily be added to your document rather than being stored in some

other location. However, a potential problem with the computer document

approach is that we tend to spend a lot of time worrying about layout and how

it looks, which can end up making the documentation process very frustrating

and annoying. If something is frustrating, we are less likely to do it.

Using a pen and paper journal, on the other hand, is easy and convenient

as well as very quick to use. It is very easy to quickly sketch some concept

idea into your journal without having to worry about scanning it or using

some 2D art program to create a rough sketch. But organization can

become an issue with the pen and paper journal approach as pages are

filled up we have to use other pages at other places within the journal

for any new ideas and sometimes ideas can get lost because we do not

remember where in the journal they were written down. We generally

use the pen and paper approach, as previously mentioned, but then add

any information from that journal into a computer document later when

26

Design Document

we have time and access, although with the growth of mobile devices we

can also use a cell phone to quickly pull up a design document and make

additions or changes to it.

2.1.3 Logical Design versus Descriptive Design

As a general rule, the more descriptive that you can be about a character or

an object within your game world, the more likely you are to get that out of

your head and into the game exactly as you want it to be. This descriptive

aspect is easily overlooked as we tend to make assumptions about details.

We see or are aware of details within our heads, but fail to share those details

with others because we work under the assumption that the information is

common knowledge. A good rule of thumb is to have a friend read what you

have so far and see if they have any questions. Encourage your readers to ask

those questions and if you already know the answer then add them to the

document, if you do not know the answer, then it is time to figure it out. It is

easier to remove details later than it is to try to come up with more details

and more information.

Along with the descriptive aspect of a design document, we also need

to consider the logical needs for the implementation of behaviors within

the game project. It is through the design of the logical side of the

game that we start to find dependencies as well as recognize the needs

of the things in our game projects. By this we mean, for instance, that if

we are going to allow a player character to have checkpoints that they

can activate during a specific level, this in turn means that we will have

to have a variable somewhere that will store the location of the last

checkpoint that the player touched. It also means that we will need to

make sure that the initial value of that variable is not outside of the game

world somewhere just in case the player dies before finding another

checkpoint and they try to respawn to that initial value. The player

character is also going to need to have a method of determining whether

they have contacted one of these checkpoints or not. That information

may have seemed trivial to us as gamers; however, that kind of

information can easily slip through the cracks when designing and then

later when building the game project that error will continue into the

functional game. Eventually, this problem should be detected, through

testing; however, the bug within the game may not be immediately

obvious to us by that point in time, especially if the game code has

become quite complex. Descriptive text works best for describing levels,

characters, stories, dialogues, and events; however, it is oftentimes better

to create some logical diagram to depict the flow of the behaviors that

we are going to develop. Figure 2.1 shows a logical diagram of this same

checkpoint type of system that we have described. Notice that it contains

the same information, but through this diagram style display, it is easier

to follow how this system could be constructed once we know how to do

such things. It is also easier to understand the checkpoint system as the

descriptive version was somewhat confusing.

27

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

Start game

Initialize starting checkpoint

Saved point = Starting location

Task complete

Wait for collision with checkpoint

Task complete

Collision with checkpoint

Save point = Location of checkpoint we collided with

FiG 2.1 The logical diagram for a checkpoint respawn system.

Note

The more information that we provide in our design document, the

easier it will be to construct our game later. We can always drop some of

the detail and information if needed.

2.1.4 Mission and Vision

The last thing that we would like to mention in regard to the reasoning

behind a design document is this idea of mission and focus. Within the

business world, a mission statement is something that defines the goal of

the business. Businesses spend large amounts of money hiring consultants

to help with the development of a mission statement. These statements

allow everyone working for the company understand what their goal is,

why the business is there, and how the business will go about reaching its

goal. For example, part of the mission of Dark Glass Studio, our indie game

development studio, is to create games that do not rely on mature content

to deliver the story and experience. This is not to say that mature games

should not be developed, it is just part of the mission of our studio to make

games without that. Knowing this mission, knowing this method of game

28

Design Document

development, helps those that work with us to recognize the type of content

that will be developed for each game. This example can be extended with the

following question: Which game studio would you like to work for and why?

Most likely, the answer for this question is going to be because you enjoy the

games that that studio makes and if the studio were to suddenly start making

completely different games you probably would not be interested in working

for them. While the type of games they make may not be an inherent part of

their mission statement, this does illustrate the idea of understanding how

the company works or how the game will be constructed. Design documents

help us to get this mission of the game across by listing and describing so

much of the game that it is clear what will be included within the game as

well as what will not be included in the game.

The other aspect is the vision of the game. Where the mission is how and

what will be done by a business or game, the vision is more of an inspirational

guide for where the business may be in a few years, think of this as goals for

the business to accomplish. We can apply this to a game project by asking the

question why we are making this game. What do we want people to get out

of this game? The answers to those questions are the vision of the game. Now,

to be realistic and honest, this type of question is most commonly answered

with two specific answers: we want the players to have fun playing our game

and we want to be able to sell the game and make money. There is absolutely

nothing wrong with those as a vision for the game, but sometimes, every now

and then, a game project comes along that has a different vision. An example

of a game vision being something other than players having fun and making

money is an ongoing project that we are working on with students at Wilkes

Community College, which is a Facebook-based game developed for a local

horse rescue ranch. The vision of the game, why it is being developed, is to

provide students with an opportunity to work on something that is not just

a “school project” and to also help raise awareness in our community about

the game development program. The project is also being developed to

meet the needs of the horse rescue ranch, raising awareness of the plight for

abandoned and abused animals while giving their financial donors something

interesting to do rather than just mailing a check. Vision—why we are making

a game is very important and it is something that everyone on the team needs

to be aware of and be onboard with.

2.2 Sections of the Design Document

There are many design document templates available online. Google Docs

has one listed and there is also the very thorough template developed by

Chris Taylor, which is also available online. These templates form wonderful

starting points for the development of a design document as oftentimes the

first question is where to even begin with such a seemingly daunting task.

However, both of these templates have a depth of information that we have

opted to avoid in this introductory look at the design document and at this

process in general. We have provided a much stripped down and streamlined

version that is available from the companion website for this text.

29

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

Download

Our design document template can be downloaded from the companion

website in the Chapter Resources section, the file name is: “Design

Document—template.”

Before we jump into the document and start editing it for our great game

idea, however, we need to look at what each section is about and why

we even need to consider thinking about such sections. Some of these

sections will immediately strike us as so obvious that we would do just fine

by skipping over them and not even worrying about them; however, as we

will see, the design document not only describes the game we are creating

but also defines the overall vision of the game, and it is vital that everyone

working on the project be on the same page and working toward the

same goal.

2.2.1 Game concept

Our design document should begin with a concise discussion of the game

itself. This section should not be very long, a page or two should be more

than enough. The goal in this section is for the reader to get the mission and

the vision of the game right away, rather than having to wade through many

pages of information to try and figure it out. If this section cannot be done

in under two pages or if it is extremely difficult to write, then we are not yet

sure what the game is that we want to make. Essentially, this section is the

traditional high concept or elevator speech portion of a design document.

We should be able to knock this part out pretty quickly.

This section begins with the game description, which is what the game is

about. If we need 15 minutes to tell someone what a game is about, then,

in actuality, we do not even know what it is about. As an example, what

is Super Mario Bros. about? It is about the main character, Mario, rescuing

Princess Toadstool from Bowser and his stooges in the Mushroom Kingdom.

Notice that the description of the game does not go into what all the players

can do or even how it is the player does anything, it is just a quick sentence

or two describing what the point of the game is. Even modern games can

be described in a couple of sentences, no matter how complex the game

may be. For instance, Civilization by Sid Meier, is about the player leading

their society from a nomadic lifestyle all the way through the space race. How

the player does this is not the point at all.

Following the description of the game, we have the opportunity to expand

on the game concept by providing some target information for the game.

Who are the players for our game? This may seem like a question that is

not very important or we may want to whitewash it by saying the target

audience is whoever will buy our game. But we need to consider it a little

more carefully than that as the target audience of the game, as well as

target genre, rating, and platform, will have an impact on many decisions

30

Design Document

later, and remember this is the vision and mission of the game. Consider

creating a first-person shooter game for military use versus creating one

for kids that enjoy water gun fights. Both games are first-person shooters,

but the behaviors of the weapons, as well as the weapons themselves, will

be drastically different between the two. Going along with this is the genre

or style of game that we want to make. When we say that we are making

a first-person shooter, there are certain things that all of us picture in our

heads that go with a first-person shooter. These things range from the

camera perspective of the game to the activities involved in the game to the

in-game user interface. However, if we were to say that we are going to create

a strategy game, suddenly what we have in our heads looks completely

different. Remember the primary goal of a design document is to make sure

that everyone on the development team is on the same page, the more

information we know about the game the better off we will be.

In our targeting section, we also have the Entertainment Software Rating

Board (ESRB) rating and the type of system that the game will run on. These

both are very important as a game created for the WII will have a very different

control scheme than a game created for the PC or a game created for a mobile

device. We need to know what type of system we are targeting to make sure

that what we are building is suitable and also to take advantage of the various

aspects of the system. As an example, constructing a text adventure game

for a mobile device would not be the best of ideas, sure it can be done, but as

soon as someone reads our target platform and target genre they should ask if

that specific genre is best suited for that platform. There are always times and

reasons to break genre stereotypes, but there are also reasons to stay within

the expectations of players and the playability of the devices.

The ESRB ratings, as shown in Table 2.1, help us understand the type of

content we will be developing to incorporate into our game. For instance,

taBLe 2.1 Current Entertainment Software Rating Board Rating System

Rating

Meaning

Type of Content

eC

Early Childhood

The content is specifically intended for young children.

E

Everyone

The content is suitable for anyone. May contain minimal mild violence

including cartoon or fantasy violence, or infrequent use of mild

language.

E10+

Everyone 10+

Anyone over the age of 10. May contain mild violence, or violence in

cartoon or fantasy depiction, mild language, or minimal suggestive

themes.

T

Teen

Suitable for anyone over the age of 13. May contain violence, suggestive

themes, crude humor, blood (in small amounts), gambling with fake

money, or occasional strong language (profanity).

M

Mature

Suitable for those over the age of 17. May contain strong violence, blood,

gore, sexual content (not explicit), or strong language (profanity).

AO

Adults Only

Only suitable for adults 18 and up. May contain long scenes of intense

violence, explicit sexual content, or gambling with real money.

31

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

if we know that the game is going to be E or T rated, then we also know that

there will not be any gore spatter or profanity in the game. If we want to

include those components, then we need a different rating for the game.

Likewise, if I want to work on a game with mature content, then perhaps

this project is not one that I would want to consider being a team member

on. We are returning to that idea of mission and vision and making sure that

everyone is on board. Granted in mainstream industry, it is a job and we do

what is required of the job, but as an indie developer, we have the flexibility

to explicitly pick the projects that we want to work on.

The features of the game provide a list of all the player can do during the

game and what can be done to the player. It is not necessary that this list be

exhaustive and all inclusive, but the reader should be able to read through

this list and know what the player can and cannot do during a typical

game-play session. As an example, if the player has the ability to see in

infrared then this should definitely be listed as a game feature. Be careful of

feature creep, which is the process of new features being added to a game

project during the development process. While it is important for our game

designs to be flexible and adaptable to what is playable and fun in the game,

it is also important that new features do not keep getting added to the

project; otherwise, we will never get it finished. Another issue with feature

creep is that some features actually cannot be added without doing a major

rework of the underlying game system. Flying is an example, if we were to

decide that it would be wonderful if our Sancho Panza character could fly

then we will need to return to the model and create an animation system

for this. We will also need to rework our control scheme to allow the player

to activate this feature and then redo our level layouts as currently there is

nothing in the sky for him to do, not to mention that he could fly right over

the artificial boundary systems we have constructed.

Whenever we are introduced to a game, our first questions tend to go in

the following order: what is the game about, what can I do in the game,

and how do I win the game. We have already addressed the first two

questions and now it is time to take on the third. For instance, Mario can

win by rescuing Princess Toadstool, and the player in Civilization can win

by being the first to be in space or destroying all the other civilizations.

Generally speaking, this category is fairly straightforward and easily

derived from the description of the game, but once again, it is important

to make sure that we know exactly where we are going with this game.

Along with this are the similar games, these are games that may be

inspirational to the current project. For instance, our horse rescue ranch

game, mentioned earlier, may be similar to Farmville, PetCity, and Zoo

World. We are not saying that we are copying these games or even that the

project will have the same features as these, only that these are similar to

it and perhaps we would like to incorporate some components from those

games into our project.

With this section of the design document complete, we should now have

a pretty solid understanding of the game that we would like to make.

32

Design Document

We should have a good idea of how it is going to behave based on the game

features and the target genre. We should also have a strong idea of what it

is going to contain based on the ESRB rating, audience, and similar games.

All of these put together have given us a strong concept of the mission and

vision of this game, and the pages that will follow in the design document

will all relate back to this quick introduction to the game.

2.2.2 Game characters

Most games have characters; there are notable exceptions to this, but

generally speaking, games have characters that are either representations

of the player within the game world or are something that the player can

interact with during game play. We need to consider the characters of

our game and get to know them as well as we possibly can. This section

will include both verbal descriptions as well as concept art to go along

with these characters. The more that we put into this, the more that we

know about the characters within the game, the closer we can get the

game versions of these characters to the initial ideas in our head. Another

interesting aspect of this section is that we also need to start considering

how these characters behave within the game world. This varies from how

the player can control their main character to what the other characters

in the game can do and how they make these decisions. As you may have

noticed, it is difficult to design the logical flow for this if we do not know how

to program. We could view this as trying to make a blueprint for a house

without knowing how a house is built; for instance, things like load-bearing

walls are pretty important in the design of the house.

When creating characters for a game, there are essentially two main

categories of characters. The first are the primary characters which include

not only the player’s character but also the main characters that the player

will interact with during game play. For instance, in our Sancho project,

we will be adding in a character to serve as his wife, Teresa, which will be

the primary source of quests and objectives for the game. We will also be

adding in a spider character that will be there for the sole purpose of trying

to bite and kill Sancho. Here in the design document, we need to describe

these characters: their background, their personality, why they are in the

game, what they want, and also how they do whatever it is that they do

within the game. The more detail, the easier it will be for us to construct

these characters. The other group of characters are window dressing, or

characters that are in the game but just do not really do all that much. An

example of such a character for Sancho will be the sheep that he can go

around and gather. All they do is stand there, eat grass, and follow Sancho

around after he has found them. They do not fight anything and nothing

fights them. Once Sancho has returned them to their pen they just stay

there and eat grass. Not an overly exciting life, but that is what we need

them to do.

We will hit this section pretty hard when we get to our chapters on the player

character and non-player characters. However, before we leave this section,

33

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

notice also that we need to begin to consider the art assets that will have to

be developed for all of the characters for the game. Not only do we need to

construct the models and animations for the characters, but also any other

objects that they may need to use. For instance, if we were to decide that

Sancho Panza could swing a sword as part of the player control system, then

that means that we will need to construct the model of a sword for Sancho

to hold and also an animation system of him swinging that sword. This

information is very important for the art team of any project to know, we

need to know what exactly it is that the developers need built for the game

project—remember our example from earlier about hiring a 3D modeler

and asking them to build some characters by next month. When working

on this section do not expect to sit down and run through the whole thing

in one go, there are characters that may be added as the game continues to

develop, but we really do need to get the primary characters down as quickly

as possible.

2.2.3 Game Story

After developing our game characters, or perhaps before creating them

depending on our preference, we need to determine the story of our

game. There are many games that do not contain stories and that do not

need stories at all. However, if we consider a story at its most basic level, it

is nothing more than what the game is about in a little bit more detail. For

instance, our Sancho Panza project is about the main character, Sancho

Panza, returning peace and tranquility to an island kingdom called Barataria.

That is what the game is about; however the story of the game is far more

than just that. As we read the description of this game, we should have

questions that pop into our heads. Questions such as:

• Where is this island of Barataria?

• Why is it not peaceful?

• Where was Sancho before the island?

• How did Sancho get to the island?

• How did Sancho hear about the island?

• Why does Sancho want to save this island?

There may be other questions that come to you, but these serve as a strong

starting point. All of these questions can and should be answered by the

story of the game. The backstory or background will provide the information

as to what has happened prior to the game starting whereas the story

itself will provide the information of what happens during the game. The

interesting thing about this story stuff is that the plot within the story ends

up becoming the challenges and obstacles that our character must overcome

during the game, or more specifically the things that the player must

accomplish in order to beat the game. Remember that beating the game is

a victory condition, so while we have already specified the victory condition

the story may describe how the main character gets from the beginning of

34

Design Document

the game to that victory condition, assuming that the player performs the

required tasks with the needed skill level.

The story section also allows us to provide a descriptive account of what this

world is like, the basic questions of who, what, when, where, why, and how

are all generally answered through the story of the game. While the game

description and victory conditions may provide a hint to this information,

the game story fleshes out those details. It is interesting to note that in all

probability much of our story work may not even show up in the game itself

for various reasons, at any rate we will get into this in much detail with our

chapter on story and development.

2.2.4 the Game World

The game world is the environment in which the game actually takes place.

While the story section describes what occurs as well as a solid foundation for

the environment of the story, the game world is more focused on the artistic

aspect as well as game-play components for our game project. It is important

for us to have a clear understanding of what our game world looks like

artistically; there is a vast difference between a cartoony cel-shaded game

world and a gritty photo-realistic one, and we need to know what it is we

are trying to create before we start creating anything. This is a great place to

gather concept images, which are images and photos that give ideas about

what this world would look like. These images do not have to be exact, they

are just inspirational for the eventual art work that will go into constructing

the various game levels and world.

While the appearance and styling of the game world is very important, from

a game-play perspective, it is more important for us as developers to know

what the levels actually look like and what the players can do within the

levels. A top-down map sketch of each level is very beneficial so that when it

comes time to start building these levels we know exactly where it is that we

need to put all of the various pieces that have been made. We also need to

consider what the player can and cannot do within each level; for instance,

Sancho cannot run off the island and go find mainland Europe, we just are

not going to allow that mainly because we do not want to have to build all of

that stuff on the off chance that some player decides to see what is out there.

Being aware of this, our descriptions and concept sketches for the island will

contain barrier information to keep Sancho locked on the island itself.

We should also consider how each level ties back into the story itself. As we

will discover later, stories tend to be episodic in nature, that is to say, that

they tend to have chapters. As it turns out, games tend to have separate and

distinct levels that correlate very nicely into episodes or chapters of our story.

So, each level may correspond to a specific part of the story that we have

developed for the game, we need to know this information as the challenges

from that portion of the story should be incorporated into the level design

in some way. We are not saying that each level must exactly match a part

of the story, only that they should represent a part of the story. How much of

35

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

that story component is included in the level will ultimately depend on the

playability and fun factor of that level as we will see in our chapter on game

worlds and environments.

2.2.5 Game Audio

Game audio, as we will discover in Chapter 9, is an easily overlooked aspect

of game development. It is very easy for us to think that we will just grab

a couple of music files from here or there and a couple of sound effects

from here or there and the audio will be done, it will be easy. The irony here

is that audio actually is quite easy to implement within a game project,

especially in Unity; however, it tends to take a whole lot longer to both

find the correct audio and to tweak it in the game than we expect. This is

where design can come in to save the day. It is surprising how just making a

list helps us to realize that a given task is going to require more effort than

initially thought. For instance, consider the following statements, “I need

you to pick up a couple of things from the grocery store” versus “I have a list

for you next time you go to the grocery store.” Notice that in both examples

the amount of things to get is not specified and for all we know the amount

is exactly the same. However, as soon as someone says they have a list for

us we immediately imagine all of this work we have to do. How many times

have you looked at a list and responded with “Oh, well this isn’t too bad,

I can do this.”

The primary purpose of the audio section in our design document is to force

us to start thinking about the audio in our game and start gathering those

assets. Music is surprisingly tricky due to copyright and legal issues. Finding

the music that exactly matches what we want and having the legal rights to

use the music is going to take some time; the sooner we get started on it the

better off we will be. If we wait until we are ready for the music to be thrown

into the game, the search becomes frustrating instead of fun as the music

really does help to define the overall feeling of our game. By describing the

music that we want and providing some quality examples of it, this task of

getting the music can then be delegated to someone and what they come

back with later should match what we want, or at least be close enough that

we are good with it.

The same thing goes for sound effects within a game. We do not fully realize

how many events and actions in our game we want sounds for until we start

making a list. Many of those actions that we put into the character control

systems will need sounds to go with them. This includes seemingly simple

things; for instance, consider a character jumping:

• Do they make a sound, grunt maybe, when they jump?

• Do they make any sounds when they are in the air?

• Do they make a sound when they land?

• Do they make any sounds while they are falling?

• Do they make different sounds based on the surface they land on?

36

Design Document

If we wait until later in the game, we are more likely to decide that feature X

is not really that important because we are burned out looking for sounds

and just want to advance the game project and get it finished. This brings us

back to the role of a design document, to help keep us on track and help keep

us focused. If we have already gathered a whole bunch of audio files that we

think we might want to use for various actions in the game, then when we start

implementing those it goes much smoother and the game feels like it is really

coming together instead of starting to fall apart at that point in time. We will

spend a chapter on the audio and implementing it within our game project.

2.2.6 Game interface

The final section for our version of a design document is the interface system

that we will be using within the game. This is another area that can be viewed

as really easy until we start to do it. Many times the creation of a user interface,

whether a menu system or an in-game overlay system, is going to involve

quite a bit of 2D art work. If we do not have the art work available when we

get to those stages, then the project can slow down drastically as we go off

and work on that. Also, if we have not considered the overall layout as far as

colors, fonts, and positioning, then we will spend quite a bit of time trying

different ideas until we figure out what it is that we want to do with the game.

We have returned, once again, to the idea that the design document should

serve as a guideline for our game project; it keeps us on track and helps us

to know where it is we are going and possibly even how we will get there in

the case of many of the sketches and diagrams that are developed. If we are

utilizing menu systems in our game, what role they serve and how the player

interacts with them are just as important to consider as what the systems will

actually look like. Many times during this questioning and designing stage of

game development we will discover aspects of the game that we did not even

realize we were going to have to create or we may even discover parts of the

game that really just do not fit after we think about them some more.

Fonts are a tricky thing and we need to make sure that we have the legal

rights and licenses to use any fonts that we are incorporating into our

game projects. When working on noncommercial projects there is a lot of

legal leeway with what we can do; however, as soon as we start selling a

game or trying to make money from a game, the legal landscape changes

drastically and these are issues that we should consider while designing

the game, not after it has been released. We will focus on the various

interface systems available in Unity and how to update them through

PlayMaker later in the book.

2.3 Summary

Throughout this chapter, we looked at the design document for a game

project. We have focused on the initial section of the design document,

the game concept, and will fill in the other sections as we go through this

37

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

book. At first glance, we may overlook the design document as something

of drudgery that we really do not want to do or perhaps something that

we will do after we have built the game, but after this chapter, we can see

how having a guideline and direction for where we are going will have a

very positive and beneficial influence on the rest of the game development

process. While it is definitely not necessary to focus on a formal document

within a computer word processing program, some kind of documentation

should be done for our game projects; otherwise, we will forget some of our

great ideas and may even lose focus during the development of our project.

This document helps us to stay on track and as we will see throughout

the rest of this book there are many diversions and detours during game

development that can send us off on wild goose chases and prevent us from

finishing our game. The best way to learn game development and to become

better at it is to finish games, starting a game and not finishing it really does

not help us and the design document can help us to finish a project, which is

a good thing.

Vocabulary

Design document

Mission statement

Vision statement

Descriptive design

Logical design

Target audience

Target platform

Target ESRB rating

eC

E

E10+

T

M

AO

Review Quiz

1. How can the expression “a picture is worth a thousand words” be applied

to a game design document?

2. What is the difference between a rating of E and a rating of T?

3. Are we required to use a computer and word processor for the creation of

a design document?

4. What is the primary role of a design document?

5. Can we create a game without a design document?

6. Why would we need to know what system we are building a game for?

7. What is the difference between a game genre and a target audience?

38

Design Document

exercises

1. Consider one of your favorite games:

a. What is that game about?

b. What are the features of the game?

c. What other games are similar to the game?

i. In what ways are they similar and what ways are they different?

d. What is the rating of this game and what would have to be changed

to go to a rating of T (if the game is currently M) or M (if the game is

currently not M)?

i. Would this positively or negatively impact the game? Why?

2. Consider your favorite game platform:

a. What advantages does it have over other platforms?

b. What disadvantages does it have over other platforms?

c. If you were to design a game for this platform, how would you try to

leverage the advantages and minimize the disadvantages?

Design Document

In this addition to the Sancho Panza design document, we have started the

work on our design document by filling out the title pages as well as the

game concept section.

Download

The updated version of the Sancho Panza design document can be

downloaded from the companion website within the Design Document

archive, this chapter’s document is named: “Design Document_Chapter 2.”

Take some time to consider one of the many amazing game ideas that you

have had over the years. As you think about these, pick one to focus on

during the course of this book as a design document exercise and start

constructing your design document for that idea. Add the following to it:

1. Name of the game, this can be changed later or even skipped for now.

2. Your name.

3. Game concept section.

a. Game description, what is your game about?

b. What and who are you targeting with your game?

i. Why are those the target?

c. What features will you put into the game?

i. This section can most definitely be expanded as we continue, but

you may want to jot down some initial ideas.

d. How does the player win or lose your game?

e. What other games are like this one or what games have inspired you

to want to make this game?

39

Page Intentionally Left Blank

chapter 3

Using Unity and PlayMaker

Now that we have some background information on the various

development tasks that need to be done and a basic overview of how to

approach these, it is time to get our development environment configured

and get to know our way around it. It is a common mistake to try to learn

every aspect of a development tool in one go; as a result, in this chapter, we

will focus on the basics that we need to know in order to get started with our

game project. As we need to know more about either Unity or PlayMaker we

will add to our knowledge base at that time, rather than try to get our heads

around all of it right now. Just as creating games is an iterative development

process, so too is learning the tools and techniques. Each new piece of

knowledge will stand on the foundation of some previous piece that we have

already gotten a good grip on. With these ideas in mind, in this chapter, we

will focus on

• Getting and Installing Unity 3D

• The User Interface of Unity 3D

• Game Objects and Their Components

• Projects and Scenes

41

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

• Getting and Adding PlayMaker to Our Project

• The User Interface of PlayMaker

• Finite State Machines in Design and Implementation

3.1 installing Unity

Before we can install the Unity game engine, it will have to be downloaded

from the Unity website: http://www.unity3d.com. While at the website,

it is worth it to take a few moments and browse around the links that are

available in the top-level site navigation as seen in Figure 3.1. Unity provides

a showcase gallery to view other products that have been made with Unity;

they also have a hashtag (#madewithunity) for use with any Twitter posts to

help get the word out not only on the Unity game engine but also on any

project that you may be working on. Through this showcase link on the main

page, you can browse through all of the games that have been posted with

this hashtag. Browsing through this directory will reveal many interesting

titles, and it is an encouraging process to play what others have made with

Unity as it can help us stay focused and also realize that what we are trying to

do is possible, if we stick with it.

The Community link will give you access to the Unity forums and a Q&A

knowledge base. Both of these are very active with questions and solutions

being posted on a regular basis. It is reassuring to know that if we run into any

problems with Unity during development that there is a community willing

to help find solutions. Not only can questions be posted about Unity issues

specifically, but also implementation questions can be posted here as well;

these would be questions specific to how to get something working the way

that we want within our game project. For instance, if we were trying to figure

out how to create an explosion with the Shuriken particle system we could post

a question and get help from someone that would either solve the problem or

guide in the right direction so that we can build our own solution.

Unity also provides a Learn link that serves as a starting page for many

tutorials with the game engine. Long gone are the days of game development

being a cryptic and secretive practice. The developers of Unity want you

to know how to use the tools that are being placed at your fingertips. The

more that you know about Unity, the more that you can do with Unity. It is

a win–win situation for everyone involved and this tutorial resource can be

very valuable in the learning process. Along with the tutorials, there are also

links to both the Unity manual and the Unity scripting API. While the scripting

API may not be overly relevant to this book, it is of significance to note that

the actions we will be using within PlayMaker are derived directly from the

FiG 3.1 Top-level site navigation on the Unity 3D website.

42

Using Unity and PlayMaker

scripting API; in fact, they even use the same names. This means that through

learning PlayMaker, we will also become familiar with many aspects of the

scripting API without even knowing that we are learning that content.

The final stop on the top-level navigation is the Get Unity or download page.

From this page, we can get the current free version of Unity or a previous

version if for some reason we need an earlier release of the application.

It is also possible to look at the system requirements for the Unity game

engine. It is important to ensure that your system meets these requirements

prior to attempting to install the engine and developing a game with it.

Having a computer that does not meet these specifications will create a

very frustrating development experience. There are also links to a license

comparison, release notes, and patch downloads. The license comparison

provides valuable information in helping you to decide when and if you will

need to purchase the Professional version of the software. For the project

that we will be working on in this book and many other game projects as

well, the Personal Edition of Unity has all of the features that will be needed.

Note

As of the release of Unity 5, the free version has been named

the Personal Edition and includes all of the engine features that

were originally available only in the Professional version. These

features include the advanced lighting system, advanced water, and

advanced shadows along with others. And the Personal Edition is

royalty free until you reach an income level of $100,000 with your

Unity projects.

Now that we have looked around their website some and ensured that

our computer can handle running Unity, go ahead and download the

newest version of Unity available from their download page and begin the

installation process. While installing Unity, you will be greeted with several

screens asking for clarification from you. All of the default options will work,

including the option to install the example projects, although we will not be

looking at that project, during your reading of this book it may prove to be a

useful reference. After Unity has completed installing, a link on your desktop

as well as a start menu shortcut will appear. With the completion of the

installation process, we can launch the Unity development environment and

move forward to the next section.

Note

The version of Unity used during the writing of this book is Unity 5.0.0.

While there will undoubtedly be many exciting new features added

during the 5.x version, all of the content of this book should be

compatible throughout the lifespan of Unity 5.

43

Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing

3.2 Unity’s interface

When we launch Unity, the screen that will appear is the Project Wizard, the

default version of which is depicted in Figure 3.2. There are two tabs at the

top left and two buttons at the top right within the Project Wizard browser.

Beginning with the tabs to the left, the Projects tab allows us to select a

previously loaded Unity project to launch and continue working with (if you

have downloaded and installed the Example Project then it will be listed

here). The “Get started” tab will present a short video introducing Unity as

well as some of the resources we mentioned in the previous section. With

the Open Other button, located at the top right of the Project Wizard we can

browse to a location where another project is located and open it. Keep in

mind that when opening a project through the Open Other project browser

what you will be pointing Unity toward is the project directory or folder, not

to a specific file. This point can cause some confusion when first using Unity

as we are used to using applications to open files, but with Unity we direct it

to a folder that contains the project that we want to open. This is a point that

we will return to when we discuss using Unity in the next section. The last

button is the New Project button, which will begin the process of creating

a new project. Go ahead and click the New Project button as we currently

do not have a project to open and would like to begin our Sancho Panza

game project.

Creating a new Unity 3D project is accomplished by selecting the Create New

Project tab and providing the required information for the new project to

be created; the view of this tab is shown in Figure 3.3. When creating a new

project there are two aspects that need to be considered: the first is where

FiG 3.2 Default Project Wizard browser.

 

 

In introducing new students to video game development, there are two crucial components to consider: design and implementation. Unity 3D and PlayMaker Essentials: Game Development from Concept to Publishing provides theoretical background on topics such as characters, stories, level design, interface design, audio, game mechanics, and tools and skills needed.

Each chapter focuses on a specific topic, with topics building upon each other so that by the end of the book you will have looked into all the subjects relevant to creating your own game. The book transitions from discussion to demonstrations of how to implement techniques and concepts into practice by using Unity3D and PlayMaker. Download boxes are included throughout the book where you can get the version of the game project under discussion or other content to add to the project, as well as any supplementary video tutorials that have been developed.

Addressing both theoretical and practical aspects, Unity 3D and PlayMaker Essentials enables you to understand how to create a game by having you make a game. By gradually completing your own design document through the course of the book, you will become familiar with core design principles while learning the practical skills needed to bring your unique game to life.


Related posts

Mastering SASS by Luke Watts, PDF 1785883364
Expanding Perspectives on Open Science: Communities, Cultures and Diversity in Concepts and Practices, Proceedings of the 21st International Conference on Electronic Publishing by F., PDF 1614997683
Honeypots and Routers by David Easter, PDF 1979671036
Cyberspies: The Secret History of Surveillance, Hacking, and Digital Espionage by Gordon Corera, PDF 1681774593
The Five Step Web: Successfully Manage the Design and Delivery of your next Business Website by Peter J. Fagen, PDF 1521912106
The Geeky Girl’s Guide To Creating Your Online Brand: The only tool you need to start building your business online by Angela M R B Mondor, PDF 1522838961

Leave a Reply

Your email address will not be published. Required fields are marked *