Game Architecture And Design A New Edition (New Riders) pdf

  I Game Design

  13 Procedures and “Process” 327

  Glossary 893 Index 897 Game Architecture and Design:

  IV Appendixes A Sample Game Design Documents 785 B Bibliography and References 887

  24 The Future of Game Development 747

  23 Postmortem 719

  22 The Run-Up to Release 687

  21 Development 637

  20 Initial Architecture Design 607

  19 Building Blocks 553

  18 Use of Technology 511

  17 Initial Design 457

  16 Current Development Methods 433

  III Game Architecture

  15 The Future of the Industry 409

  14 Troubleshooting 367

  12 Milestones and Deadlines 293

  1 First Concept

  87

  3

  2 Core Design

  35

  3 Gameplay

  59

  4 Detailed Design

  5 Game Balance 105

  11 The Software Factory 263

  6 Look and Feel 141

  7 Wrapping Up 171

  8 The Future of Game Design 197

  II Team Building and Management

  9 Current Methods of Team Management 227

  10 Roles and Divisions 245

  A New Edition Contents at a Glance

  800 East 96 th

  Street, 3

rd

  Floor, Indianapolis, Indiana 46240 An Imprint of Pearson Education Game Architecture and Design:

  A New Edition Andrew Rollings Dave Morris

  Game Architecture and Design: A New Edition Copyright © 2004 by New Riders Publishing All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means— electronic, mechanical, photocopying, recording, or otherwise— without written permission from the publisher, except for the inclusion of brief quotations in a review. International Standard Book Number: 0-7357-1363-4 Library of Congress Catalog Card Number: 2003111600 Printed in the United States of America First printing: November, 2003 08 07 06 05 04 7 6 5 4 3 2 1 Interpretation of the printing code: The rightmost double-digit number is the year of the book’s printing; the rightmost single- digit number is the number of the book’s printing. For example, the printing code 04-1 shows that the first printing of the book occurred in 2004.

  Trademarks All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. New Riders Publishing cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

  Warning and Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty of fitness is implied. The information is provided on an as-is basis. The authors and New Riders Publishing shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.

  Publisher Stephanie Wall Production Manager Gina Kanouse Senior Project Editor Kristy Hart Copy Editor Chrissy Andry Senior Indexer Cheryl Lenser Composition Gloria Schurick Manufacturing Coordinator Dan Uhrig Interior Designer Kim Scott Cover Designer Aren Howell Media Developer Jay Payne Marketing Scott Cowlin Tammy Detrich Hannah Onstad Latham Publicity Manager Susan Nixon

  This book is dedicated to the memory of Ram De Silva, respected colleague and beloved friend.

  ‰ Andrew Rollings In loving memory of my father, Victor Morris.

  ‰ Dave Morris

  vi Game Architecture and Design: A New Edition Table of Contents

  Introduction xxiii

  Part I Game Design Chapter 1 First Concept

  3 The Shock of the New

  3 The Creative Road Map

  4 Having the Idea

  6 Inspiration 7 Synthesis 8 Resonance 9 Convergence 10

  Shaping the Idea

  11 Dramatic Effect

  11 The Treatment

  15 Taking Stock

  16 Analysis 16 Evaluation 17 Justification 17 Case Study 1.1 The One-Page Pitch

  18 Feasibility 20 Commercial 20 Technological 20 Developmental 21

  Getting it Down

  21 Case Study 1.2 Initial Treatment for Conquerors

  22 Chapter 2 Core Design

  35 What Is a Game?

  35 Cool Features

  36 Fancy Graphics

  36 Puzzles 37 Setting and Story

  37 Games Aren’t Everything

  38 Case Study 2.1 Story Versus Gameplay

  39 Table of Contents vii Games Mean Gameplay

  39 Case Study 2.2 A Missed Opportunity?

  61 The Dominant Strategy Problem

  82 “Why?” Versus “What?”

  81 Case Study 3.5 A Different Kind of Interactivity

  79 Interactivity 80 Kinds of Interactivity

  77 Synergies 78

A Final Word About Gameplay

  77 Case Study 3.4 Shadow Costs in Age of Empires

  75 Impermanence 76 Shadow Costs

  74 Case Study 3.3 Balancing Compensating Factors

  72 Compensating Factors

  70 Versatility 71 Case Study 3.2 Unexpected Versatility

  67 Supporting Investments

  63 Case Study 3.1 Environment Plus Rules Equals Gameplay

  62 Near Dominance

  60 Implementing Gameplay

  40 Creating the Game Spec

  59 What Is Gameplay?

  58 Chapter 3 Gameplay

  57 …And the Necessity of Documents

  53 The Value of Prototypes…

  53 Case Study 2.8 Game Spec

  51 Example Game Spec

  50 Case Study 2.7 Interesting Level Design

  49 Level Design

  48 Rules 48 Case Study 2.6 The Rules Must Serve the Features

  45 Gameplay 45 Interface 47 Case Study 2.5 An Elegant Interface

  43 Features 43 Case Study 2.4 An Instance of Emergence

  42 Case Study 2.3 Integrating Game Objectives

  84 Chapter 4 Detailed Design

  87 The Designer’s Role

  98 Case Study 4.3 Planning the Mini-Specs to Fit the Architecture 100 Why Use Documents at All? 102

  Chapter 6 Look and Feel 141

  Achieve Balance 132 A Game Balance Checklist 139

  Dungeon Keeper 119 Intransitive Game Mechanics Guarantees Balance 120 Case Study 5.4 Attribute Balance Using SPS 126 Case Study 5.5 Using Game Theory Analysis to

  Case Study 5.1 Is This Supposed to Be Fun? 111 Reward the Player 113 Let the Machine do the Work 113 Make a Game You Play With, Not Against 114 Case Study 5.2 The Save Game Problem 114 Gameplay/Gameplay Balance 116 Component and Attribute Balance 117 Case Study 5.3 Component and Attribute Balance in

  Player/Player Balance 106 Symmetry 107 Player/Gameplay Balance 111

  Chapter 5 Game Balance 105

  97 Tiers and Testbeds

  87 Case Study 4.1 A Development Timeline

  95 Fitting Design to Development

  94 Using The Design Documents

  93 Case Study 4.2 The Need for Documenting the Spec

  92 The Designer’s Notes

  92 The Gameplay Spec

  88 Design Documentation

  Ambience 142 Sound 143 Case Study 6.1 Sound Effects at Their Best 143 Vision 144 Case Study 6.2 A Discordant Note 146 Game Architecture and Design: A New Edition viii

  Touch 147 Interface 148 Case Study 6.3 Meshing the Interface with Look and Feel 148 Case Study 6.4 Sometimes Less Is Less 150

  Storytelling 152 A Toolbox of Storytelling Techniques 153 Case Study 6.5 An Example of a Look-and-Feel Document 157 Case Study 6.6 An Unexpected Development 162 Case Study 6.7 An Unsatisfying Conclusion 167 The Sum of the Parts 169

  Chapter 7 Wrapping Up 171

  The Professionals 172 The Game Concept 173

  Planning for Change 174 The Technology 180 Development 182 The Team

  186 Costs and Timelines 187 Gameplay 189 The Future

  192

  Chapter 8 The Future of Game Design 197 The Necessity of Design 197 Don’t Be Afraid to Plan 198 Case Study 8.1 Design Saves Time 198 Why Design Is Fine 200 Case Study 8.2 Keep the Design up to Date 202 Essentials of Game Design 203 Is it Original?

  204 Is it Coherent? 204 Is it Interactive? 205

  Is it Interesting? 206 Is it Fun? 206 The Future of Design 207

  Making Designs More Generic 208 Nonsymbolic Design 209 Case Study 8.3 Comparing Nonsymbolic and Symbolic Design 211

  Table of Contents ix

  x Game Architecture and Design: A New Edition The Future of Games 212 The Next Decade 213

  The Strengths of Software 214 The Crossroads of Creativity 215 Case Study 8.4 An Example of Mise En Scene 219 Games as Entertainment 222

  The Way Forward 224

  Part II Team Building and Management Chapter 9 Current Methods of Team Management 227 The Current Development Model 228 The Origins of the Industry 228 The Trouble with Game Developers 231 The Problem Developer 234 Excessive Long Hours Mean an Unsuccessful Project 241 Exceptions to the Rule 242 Case Study 9.1 Quake, StarCraft, and XCOM: Interceptor 243 Chapter 10 Roles and Divisions 245 Assigning Personnel 245 Management and Design Division 247 Programming Division 249 Art Division 250 Music and Miscellaneous Division 251

  Support and Quality Assurance Division 253 Improving Morale and the Working Environment 255 Morale Boosters 255 Morale Booster Caveats and Warnings 261

  Spreading the Risk 262

  Chapter 11 The Software Factory 263 What Is a Software Factory? 263 Why Use a Software Factory? 265 Solving Game Development Issues 266 Case Study 11.1 The Effects of Losing Key Personnel 268 Case Study 11.2 Code Reuse 269

  Organizing a Software Factory 271 A Structural Overview 271 Group Responsibilities and Interactions 273 Case Study 11.3 Ineffective Problem Handling in Action 274 Case Study 11.4 Effective Problem Handling in Action 276 Case Study 11.5 The Benefits Of Tool Reuse 281

  Applying the Software Factory Structure and Methodology 285 Getting off the Ground 286 Knowing When to Use Each Team—a Parallel Development Timeline 287 Rotating and Reassigning Team Members 289 Case Study 11.6 The Indispensables 289

  The Suitability of a Software Factory 290 Smaller Teams 290 The Final Word 291

  Chapter 12 Milestones and Deadlines 293 How Milestones Currently Work 294 Case Study 12.1 What Fuzzy Milestones Can Do to

  a Project 297 Fuzzy Milestones 299 Milestones and Mini-Milestones 299

  When to Use Milestones 301 Making Your Milestones Accurate 301 Case Study 12.2 The Costs of Canceling Projects 304 Checkpoint 1.0 General Requirements Gathering 305 Checkpoint 1.1 Technological Requirements Gathering 307 Checkpoint 1.2 Resource Requirements Gathering 308 Checkpoint 2.0 General Feasibility Study 309 Checkpoint 2.1 Technological Feasibility Study 311 Checkpoint 2.2 Resource Availability Study 312 Checkpoint 3.0 Draft Architecture Specification 312 Checkpoint 3.1 Project Initialization 313 The Next Steps

  314 Defining Milestones 314 Bad Milestones 316 Good Milestones 321 Case Study 12.3 A Real-Life Milestone 322 Research Versus Deadlines 323

  Table of Contents xi Chapter 13 Procedures and “Process” 327 Procedures

  328 Reviews 329 Testing in General 333

  “Process” 341 Case Study 13.1 Process Gone Mad 345

  Procedures: Where to Use Them? 348 The Design Phase 349 The Development Phase 352 The Testing Phase 354

  Source Control and Code Reviews: A Synergy 355 Case Study 13.2 Source Control? We Don’t Need No Steenkin’ Source Control! 355 What Should Source Control Be Used For? 358

  The Importance of Information Transmission 358 Proactive and Reactive Information Transmission 362

  Chapter 14 Troubleshooting 367

  Risks 372 Design and Architecture Problems 376 Case Study 14.1 The Case of the Deaf Manager 379 Schedule Threats 388 Case Study 14.2 Applied Schedule Readjustment 394 Organizational Problems 396 Contractor Problems 398 Personnel Problems 399 Development Problems 401 Process Problems 406

  Chapter 15 The Future of the Industry 409 The State of the Industry 409 The First Era

  410 The Second Era 411 The Third Era

  411 Violence in Games 415 The New Model Developers 421 Case Study 15.1 It’s Hard for Developers 423 The Online Revolution 427 Delivering Games Online 427

  Playing Games Online 428 Game Architecture and Design: A New Edition xii

  Part III Game Architecture Chapter 16 Current Development Methods 433 The History of Development Techniques 436 The Rise and Fall of the Original Game Idea? 437 The Development Environment 441 The Present Day 452 Reusability 453

  Chapter 17 Initial Design 457

  The Beginning 459 Case Study 17.1 Abstraction in Quake II 461

  Hardware Abstraction 462 Graphics Hardware Abstraction 463 Sound Hardware Abstraction 468 Other Hardware Considerations 470 “Not Built Here” Can Be Better 476 The Twilight Zone 478

  The Problem Domain 479 What Is a Game? (Revisited) 480 Thinking in Tokens 482 Tokenization of Pong 483

  Tokenization of Pac-Man 493 State Transitions and Properties 500 Case Study 17.2 The Inflexibility Trap 502

  Chapter 18 Use of Technology 511

  The State of the Art 515 The Rise and Fall of the 3D Engine 516 The Perception of Technology 522 Case Study 18.1 A First Impression 523

  Blue-Sky Research 528 Research Types 531 Case Study 18.2 Losing Sight of the Ball 533

  Case Study 18.3 Tetris: A Caveat 538 Case Study 18.4 Outcast: Good Use of Technology 539 Keeping a Journal 541 Reinventing the Wheel 542

  Use of Object Technology 543 Table of Contents xiii Chapter 19 Building Blocks 553

  Reusability in Software 555 Code Reuse 555 Case Study 19.1 Reuse of Engines 556

  Design Reuse: Patterns 558 Game-Specific Patterns 606

  Chapter 20 Initial Architecture Design 607 The Birth of an Architecture 608 Architectural Concepts 610 The Tier System

  617 Tier Zero: The Prototype 617 Case Study 20.1 A Database-Driven Approach 623 Tier One and Beyond 623

  Architecture Design 628 Applying the Tier-Based Approach to Architecture Design 631 Case Study 20.2 Discussing the Architecture of Warbots 633 Architecture Orthogonality 635

  Chapter 21 Development 637

  The Development Process 638 Code Quality 641 Coding Standards 642

  Coding Priorities 668 Speed 669

  Size 670 Flexibility 671 Portability 671 Maintainability 671

  Debugging and Module Completion 672 Types of Bugs 674 Case Study 21.1 Class A Bugs or Not? 675

  The Seven Golden Gambits 681 Reuse 681 Case Study 21.2 Reusable Architecture 682 Documentation 682 Design First

  683 Schedule 684 Catch Mistakes as You Go Along 684 Game Architecture and Design: A New Edition xiv Limit R&D 684 Know When to Draw the Line 685

  The Three Lead Balloons 685 Bad Management 685 Feature Creep

  686 Coder Insularity 686

  Chapter 22 The Run-Up to Release 687 Late Evaluation

  688 Final Analysis 689 Is the Game Pp to Scratch? 691

  Case Study 22.1 A Self-Inflicted Disaster 692 Case Study 22.2 A Recovery Plan 694 Case Study 22.3 Licensing Hell 700 Case Study 22.4 Last-Minute Madness 701

  Late Localization 703 Licenses 703

  Languages 704 Demos 706 Case Study 22.5 Giving the Game Away 707 Case Study 22.6 Keep Something Back 708

  Playtesting 708 Case Study 22.7 How Did They Miss These!? 710 Focus Groups

  712 The Web Site 713 Getting Ready for the Gold Master 714

  Patches 715

  Chapter 23 Postmortem 719

  Case Study 23.1 A Tale of Two Projects 722 Team Dynamics 725 Case Study 23.2 It’s All Gone Horribly Wrong! 726

  Concept 730 Climate 730 Case Study 23.3 Misjudging the Climate 731 Accessibility 734

  Development 737 Software Planning 738 Case Study 23.4 Oubliette 739 Table of Contents xv Coding 741 Testing 742 Business Aspects

  742 Case Study 23.5 Secure Your Revenue Stream 743 The Postmortem Postmortem 745

  Chapter 24 The Future of Game Development 747 Development in Context 748 Future Development 752 Marketing 752 Case Study 24.1 Marketing Means Targeting 754 Content 756 Case Study 24.2 Development Without Strategy 757 Planning 760 Developers 762 Small Is Beautiful Too 763 Building the Team of the Future 764 Character 764 Motivation 767 Morale 769 New Directions in Development 771 The Holistic Approach 771

  “Jurassic Park” Software 773 Immanent and Transcendent Worlds 775 The Shape of Things to Come? 780

  Part IV Appendixes A Sample Game Design Documents 785 Detailed Design Discussions 785

  1. Balls! Introduction 785

  2. Overview of Gameplay 786

  3. Platforms 787

  4. Time Scales 788

  5. Why Puzzle Games Aren’t as Good as They Used to Be 789

  6. Puzzle Game Appeal 790

  7. Why Balls! Would Be Good 791

  8. Game Design: User Interface Elements 794 Game Architecture and Design: A New Edition xvi

  9. Physics of Balls! 799

  10. Joints 839

  897

  B Bibliography and References 887 Glossary 893 Index

  886

  857 Code Review Form 885 Test Scripts

  3. How Does it Play? 854 Technical Specifications 856 Technical Specification: Fully 3D Plug-In Graphics Module for Balls!

  2. Game Elements 849

  1. Introduction 847

  13. Target Platform 846 Postscript 846 Liberator 847

  12. Tutorial Campaign 844

  11. Messages 843

  9. The Game World 835

  10. Blocks 805

  8. Combat 834

  7. Orders 833

  6. Personality 831

  5. Character Types 825 Gangsters 826 Non-Gang Members 829

  4. Playing a Game 824

  3. Graphics 821

  2. Game Objectives 819

  1. Overview 818

  13. Further Embellishments 813 Initial Treatments and Sample Designs 817 Racketeers: Gang Warfare in the Roaring Twenties 817

  12. Playing the Game 810

  11. Special Case Block-Block Collisions 808

  Table of Contents xvii

  xviii Game Architecture and Design: A New Edition About the Authors

  Andrew Rollings has a B.S. in Physics from Imperial College,

  London, and Bristol University. He has worked since 1995 as a technical and design consultant spanning many industries. Andrew lives in Auburn, Alabama, and can be contacted at a.rollings@hiive.com .

  Dave Morris has worked as a designer and creative consultant on PC and console games for several major publishers, most notably Eidos.

  His strategy game Warrior Kings reached number six in the United Kingdom PC charts. He has done creative development and scriptwrit- ing on television shows for Endemol, Pearson, TV2 Norway, and the BBC. He has also written more than a dozen novels, gamebooks, and movie novelizations, and in 1991 he was the UK’s top-selling author. He is currently writing the screenplay for the film version of the classic adventure game The Seventh

  Guest. Dave lives in London, England, and can be contacted at david.j.morris@dial.pipex.com .

  Acknowledgments xix Acknowledgments

  A work of this kind, drawing on our combined experiences over many years in the games industry, owes a debt of gratitude to all the people we have worked with. The impossibility of acknowledging everyone in person does not mean that we fail to value every contribution, suggestion, or conversation that has helped us to refine these ideas. So, let us start by thanking all who have been our colleagues on any development project, great or small.

  It is possible to single out a few individuals among the many. Roz Morris, though no gamer, proofread the manuscript and made many valuable suggestions to improve its clarity based on her professional expertise as a journalist and writer. As she is married to one of the authors, it goes without saying that she also contributed a very great deal of moral support. Sam Kerbeck, that rare combination of gentleman and genius, gave us the benefit of his technical advice, and we are indebted to him for ably clarifying many of the more abstruse issues of architecture and coding. As Co-Founder and CEO of Turn3D, he has provided us with state-of-the-art realtime graphics, and as a colleague of long standing, he has also given his valued friendship over many years. Ian Turnbull, former Development Director at Eidos Interactive, now Commercial Director of Black Cactus Games, contributed enormously with his wise counsel regard- ing the economic realities of the industry. Without his guidance, this book would be merely a theoretical work. It is Ian’s down-to-earth clear-headedness that reminded us to make it more than that: a practical handbook for developers.

  We would also like to thank Steve Foster, who has been extraordinarily patient over the course of many speculative discussions, often stretching long into the night, con- cerning the future directions and methodology of game development. His contribution has been much more than merely academic, however. When problem projects have weighed us down, it has been Steve’s cheerful encouragement that has given us the resolve to keep going.

  Special thanks are due also to Leo Hartas, Tim Harford, Matt Kelland, Dave Lloyd, Tim Gummer, Jamie Thomson, and David Bailey.

  xx Game Architecture and Design: A New Edition

  The fact that you are holding this book at all is due to the sterling efforts of the folks at New Riders—in particular Stephanie Wall, who was also head honcho on the original edition from Coriolis Press. Despite having had to chivvy us along once before, she was willing to put herself through it all over again. We would like to thank Kristy Hart, our editor, who is nothing short of a saint for her patience in tolerating broken promis- es and overlooked deadlines. And thanks also to our agent Jawahara Saidullah of Waterside Productions, for making the whole thing happen in the first place.

  Andrew would also like to thank his wife, Stephanie Park, for her continued encour- agement and tolerance for his budding writing career.

  Tell Us What You Think xxi Tell Us What You Think

  As the reader of this book, you are the most important critic and commentator. We value your opinion and want to know what we’re doing right, what we could do better, what areas you’d like to see us publish in, and any other words of wisdom you’re will- ing to pass our way.

  As the Publisher for New Riders Publishing, I welcome your comments. You can fax, email, or write me directly to let me know what you did or didn’t like about this book—as well as what we can do to make our books stronger. When you write, please be sure to include this book’s title, ISBN, and author, as well as your name and phone or fax number. I will carefully review your comments and share them with the author and editors who worked on the book.

  Please note that I cannot help you with technical problems related to the topic of this book, and that due to the high volume of email I receive, I might not be able to reply to every message.

  Fax: 317-428-3382 Email: stephanie.wall@newriders.com Mail: Stephanie Wall

  Publisher New Riders Publishing

  th rd

  800 East 96 Street, 3 Floor Indianapolis, IN 46240 USA

  Introduction Andrew Rollings’s Introduction to this New Edition

  I must confess to being more than a little surprised at the success of Game Architecture

  and Design. When we originally pitched the idea, back in 1999, we sent off proposals to

  about ten different publishers. Only Coriolis, and more specifically, Stephanie Wall at New Riders Publishing, got back to us. I bet those others are kicking themselves now. I am especially pleased that, despite the implosion of Coriolis and the subsequent legal adventures involved in ensuring the rights of this book reverting to us, Stephanie Wall is still handling the book, but this time at New Riders. I’m very sure that after five years of having to deal with me as a reluctant author, she’s more than fed up with me by now. So here we are with the second edition of Game Architecture & Design. Things have changed in the four intervening years, though not as much as we’d like. We’ve come a long way since 1999, but there’s still a long way to go. I’m sure we’ll get there…eventu- ally. I hope that this new edition of the book continues to serve as a useful reference for the aspiring and professional game developer in the same way as the first. Enjoy.

  —Andrew Rollings Auburn, Alabama, July 2003

  xxiv Game Architecture and Design: A New Edition Dave Morris’s Introduction to this New Edition

  The temptation when revising one’s work of several years past is often to rewrite history a little. There are always those embarrassing predictions that come back to haunt you. And yet with a few keystrokes, it’s possible to seem to a new generation of readers as if we were always infallible. What an enticing position to be in.

  In fact we have left most of our forecasts from the twentieth century intact. That’s because in many cases—for example, the rise of middleware—we turned out to be cor- rect. Frankly, like everyone else we enjoy being able to say, “We told you so!” In cases where we were wrong, we move on and try to learn from the mistakes. In a way, that’s at the heart of our design philosophy. Having a methodology can’t always prevent you making a mistake, but it makes darned sure you don’t make the same mistake twice.

  The case studies are culled from our mutual experiences and those of colleagues. People ask if these case studies could really be true. No, in fact not. The real truth in almost every case was much worse! But the encouraging thing is that the games industry is changing. Four years ago, our rallying cry for a formal development methodology rang like a lone voice in the wilder- ness. Nowadays games development is becoming a much more structured process. And publishers have a better understanding of what the process entails. In another four years, a developer coming across the first edition of Game Architecture & Design will be astounded that development could ever have been so ramshackle. We are happy to think that, in however small a part, we helped contribute to this evolution of the industry.

  Even better, as the production process becomes better understood and more stream- lined, it consumes less of the developers’ time. The extra creative energy this frees up can now be devoted to the game content itself. We are starting to see the first signs that games really are moving from being the equivalent of silent movie one-reelers. They are acquiring depth, beauty, and emotion.

  Introduction xxv

  Tolstoy wrote, “Art is not a handicraft, it is the transmission of feeling the artist has experienced.” Great art doesn’t simply entertain you—it does that, granted, but it does more. Art changes your life. In the next decade, we will see videogaming’s Birth of a Nation and the Citizen Kane of the console generation.

  Bliss it is in this dawn to be alive!

  —Dave Morris London, England, July 2003

  xxvi Game Architecture and Design: A New Edition Introduction to the First Edition

  The philosophy behind this book is simple, stark, and absolutely true. If you are failing to plan, then you are planning to fail. Of course, games are unique. Game development constantly throws up unexpected issues. Coping with accelerating technology is like holding onto the tiger’s tail. Worse, sometimes the client revises their requirements halfway through. But these are not reasons to forego planning. A good design provides a goal to aim for that will guide you when changes are unavoidable. Frequently, the design anticipates at least the domain of future changes. A full project plan establishes a framework for change. Planning does not end where development begins. Rather, you sustain the plan through any changes that need to be made so that, although the target may shift, you never lose sight of where you’re going. So, yes, games are unique. For that reason, they require a unique kind of planning. That is the methodology that we have set out in this book. To illustrate these points, we make copious use of case studies. These are based on common circumstances in the industry, but are fictional—any similarity to real company or product names is unintentional, except where explicitly stated otherwise. (In addition, we have refer- enced several trademarked games and replicated trademarked images such as Pac-Man, owned by Namco. These references are included to enhance the instructional and visual delivery of game concepts specific to this book and should not be construed as a challenge to such trademarks.) Who should read this book? The short answer is everyone who is, or intends to be, involved in game development. All members of a team can benefit from understanding each other’s area of responsibility. However, each section addresses issues specific to one part of the development team. We recommend that you begin by reading the section of primary relevance to your own expertise.

  Introduction xxvii

  Part I: Game Design The book treats pure game design separately from architecture and formal planning. The game design constitutes a feature-based description of the end product that can

  be used as a shared creative vision by the whole team. As development progresses and change becomes obligatory, it is the designer’s task to evolve the game design also so that the intent of the project remains clear. We reject the assertion that gameplay is entirely unpredictable and thus cannot be designed. In this section, well-understood techniques from game theory, mathematics, and creative writing are applied to the design process in order to elaborate a develop- ment model based on successive iterations of the product.

  It is clear that many games contain a spark of gameplay brilliance that could have been nurtured into a flame if the designers better understood the basic issues of gameplay.

  Part I shows you how to achieve this in your own designs. Part II: Team Building and Management The book advocates formal process because we have found it to work. Many develop- ers are wary of formal process because they fear it will lead to bureaucracy and over- management. In fact, the reverse is true. Consider an analogy. In the Japanese martial arts, much emphasis during training is placed on constant repetition of predefined sequences of movement, called kata. The student may wonder how a formal routine of countering blows to the head, chest, and abdomen can possibly be of use in the infinite combinations of moves that can occur in real-life. And then, one day, somebody takes a swing at you and your arm comes up to block. You didn’t even need to think about it. Similarly, we espouse the application of formal process precisely because it lessens the need for management. Instead the emphasis is on honing everyone’s skills as part of a team, with the developers themselves taking responsibility through self-management. Thus, Part II details simple, common-sense procedures that are easy to adopt and will soon become second nature. The payoff will be seen in increased efficiency, reliability, and team morale.

  xxviii Game Architecture and Design: A New Edition

  Part III: Game Architecture The architectural plan of the project is the point of contact that draws together the

  conceptual, artistic or gameplay factors with the technical requirements. Envisage the design as an ideal view of what the game should be. The architecture maps out how to converge reality with that ideal view. A perfect architecture should aim to achieve all of the following:

  Modularity

  Separating the project into completely encapsulated modules allows each to be independently tested, modified, or replaced without impacting the rest of the system.

  Reusability

  Reinventing the wheel every time makes no sense. Modules should be designed to be extensible and portable so that they can be plugged into other projects.

  Robustness

  A high degree of reliability is best attained by building architecture free of module interdependencies. The final goal is a meta-architecture capable of building games that are always able to function in unexpected circumstances—in short, that are crash- proof. Though such a goal is considerably beyond the scope of this book, the subject is treated in an introductory manner by means of object-oriented design patterns.

  Trackability

  The project plan is derived directly from the architecture, yielding a schedule that allows realistic measurement of progress. Projects fail because of poorly thought-out architecture that fails to assist in creating the intended game or, worse, constrains development in an unsuitable format. We show how design shades into architecture, which shades into the technical design and documentation, which in turn shades into code—as a continuous cohesive process always directed towards the (evolving) vision described in the game design.

  Introduction xxix

  Part IV: Appendixes Here we use real-life projects as case studies to illustrate the techniques of the book. We show how to begin with a feature-based description of the desired end product—

  the vision document that we call the gameplay design. When this is mapped to a logical abstraction of the game environment then you have the software plan, which describes discrete modules of the game and how they will interface. Finally, the details of imple- mentation are added to create the technical design of the project. Then the coding starts.

  Summing Up

  Game developers are the most enthusiastic, creative and motivated workers in the soft- ware industry. But they have been ill served by the development models in place today. Too often, the development teams are left baling water when it would make more sense to fix the leak instead.

  Many development houses have finally seen the need for change, but few know what changes are needed. In this book we set out a new development model for game soft- ware. Beginning with the core concept, the book covers all you need to know to organ- ize a team, plan your project, and commence development with confidence.

  Rest assured, these are not abstract theories. We have applied our methodology in practice with great success. This development model is one that works. Our aim is to tell you how to fix that leak so that you can get on with the important business of cre- ating games. Good luck!

  xxx Game Architecture and Design: A New Edition Conventions

  This book follows a few typographical conventions: ➤ A new term is set in italics the first time it is introduced.

  ➤ Program text, functions, variables, and other “computer language” are set in a insert example from book here fixed-pitch font—for example, .

  ➤ Code lines that do not fit within the margins of the printed page are continued on the next line and are preceded by a code continuation character ➥.

  Part I Game Design Chapter 1 First Concept Chapter 2 Core Design Chapter 3 Gameplay Chapter 4 Detailed Design Chapter 5 Game Balance Chapter 6 Look and Feel Chapter 7 Wrapping Up Chapter 8 The Future of Game Design

KEY TOPICS

  • Types of games
  • Storylines

  First Concept

  • Originality • Feasibility

  his chapter focuses on how to assemble the basic game- play treatment, which is really just a document of no T more than five or six pages. It is a proto-manifesto to communicate your concept for the game, and, most of all, your feeling of what the game would be like to play.

  Eventually, the treatment will grow into a full specification for the game, but writing this initial treatment will help you solidify your thoughts. You can return to the treatment later, whenever you feel in danger of getting lost in the details of the design, to get back on track with your original idea. Even better, the treatment is something you can use to sell the game to others—the publishers, programmers, and artists who will be developing the game.

  To begin, you’ll learn ways to find, shape, and refine your concepts. We’ll view a sample treatment and examine why the game took the form it did.

  The Shock of the New The designer’s job is to create something new. Everybody thinks his or her job is difficult, but this one truly is. The poet from the Book of Ecclesiastes says, “Under the sun there is no new thing.” If the statement is true, isn’t it the kiss of death to creativity? Why bother to try to create anything if it isn’t going to be original?

  4 Chapter 1

  Of course, it’s not all bad news. Occasionally there is the opportunity to rework one of the old ideas in completely new ways, and we are lucky to live in an age that is rife with these opportunities. The advent of computers has allowed us to formulate, calculate, and express our ideas in new ways. And the field of computer gaming has provided us with a new means of recreation, taking all the old ideas and obsessions that have occupied mankind since long before Ecclesiastes and giving them a new spin.

  Artists of every generation have drawn on the ideas and works that have come before them. Your own creativity is a result of the sources that you borrow from, the unique mix of ideas that synthesize in your own work. And there’s something else that’s encouraging to the creative artist. Ideas aren’t like seams of ore; you don’t deplete them and then they’re gone. Rather, they’re like living things. Ideas that are overused can become inactive for a while. They regenerate. So when you’re searching around for a first concept, take the path less traveled. Start by looking for inspiration where others haven’t been for a while. Bad game concepts are mere plagiarism: “I’m going to do Command & Conquer but with more light-armor vehicles.” Good game concepts bring something fresh: “It’s a Frankenstein strategy game where you plunder graves and battlegrounds for spare parts.” Some ideas may be just too plain wacky to work, which doesn’t necessarily mean that they are bad ideas. Maybe their time has not yet come, either because the technology isn’t there (Wolfenstein came first, but Doom did all the business) or because the market has not yet been created. Would we have been ready for Pac-Man two years earlier?

  The Creative Road Map

  There are three kinds of skill involved in creating any new work. These are creativity, craft, and technique. They are quite different from each other, but they overlap. Take painting. The first step is to decide what to paint. Then you plan how you’re going to do it, probably by sketching out a rough in charcoal. The third stage is the actual brushwork.

  First Concept

  5 In creating a game, the stages are: concept, structure, and design. For example,

  suppose you wake up one morning with the idea of doing a game based on War &

  Peace. That’s the concept. Next you decide that because war lends itself to action—and

  hence interaction—you will focus the gameplay itself on the periods of conflict. The cutscenes will be flashbacks to a time before the war. Hence the cutscenes won’t fit chronologically in place with the game levels, their purpose being not to advance to “plot” of the game but rather to give context to the action in the game levels by gradu- ally revealing the characters’ backstories. That’s your structure. Lastly, you start plan- ning out the core game mechanics—what the player sees on screen, the actions he or she can take, the objective, and the “play intent” of the game. And that’s the design.

  In most art forms, the third kind of creative ability is relatively common. Many painters, given a plan to work from and regular direction, can execute the details of the work. This is how the great artists of the Renaissance were able to create such prodigious works—they had a staff of brush technicians and paint mixers working under them.

  The ability to structure a work is less common—but it can be learned. A host of books on how to write bestsellers or hit screenplays all exploit the fact that you can teach somebody how to structure. Hollywood movies tend almost exclusively to use the three-act redemptive, or restorative, story structure because it is a formula that works. It might not make a great movie, but it’s like a table that you store in your garage. As long as the legs are the right length and the surface is planed smooth, it may not win any design awards, but it’ll do for stacking your tools on. The first skill is raw creativity. Almost by definition, it is extremely rare. It’s also not something you can learn, although you can hone creative ability if you have it to begin with. There are many things that can go wrong with game development, but perhaps the most common and avoidable pitfall is a lack of creative vision. The successful games companies are the ones that recognize that their business is entertainment, not software:

  

“Bruno Bonnell, Atari’s chairman and chief executive, maintains that the [games]

business—worth some $30 billion (£18bn) worldwide at retail prices—is breaking free of its hard-core audience and penetrating the mainstream market. Accordingly, he says: ‘We need technical and entertainment values at the same quality level as in other main- stream media like movies and TV.’”

  6 Chapter 1 “This is not an altogether welcome development. ‘I like it and I fear it,’ he says. It has already inverted the basic cost structure of his business. ‘It used to be two-thirds of the budget for technology and one-third for the creative,’ he says. ‘It is now the reverse, and in future it will be a quarter for coding and three-quarters for the entertainment value.’”

  —Christopher Parkes writing in the Financial Times, July 2, 2003

  As competition grows among the leading games developers, the semi-technical skills of structuring and designing gameplay are becoming less important than the raw creativity required to come up with world-class characters, settings, and stories. The future belongs to the shaman. The visionary. The dreamer.

  Having the Idea

  How many industries can claim to deal in daydreams? Dreams are where every game begins. Before the code, before the software plan, before the concept artwork, even before the first document, the game starts life as a spark in the designer’s imagination, and the idea is the single most persistent entity in the game development cycle. It can evolve and develop as the game progresses, but it was there from the start. It is the seed from which the game grows. Just as programmers are often warned not to rush into coding (as we’ll see later in the book), designers must guard against rushing to get their ideas down on paper. When that daydream comes, give it time. Resist the urge to go straight to the word processor. We firmly believe ideas have a gestation period, the time your subconscious takes to mull over the concept and hand it up to you in its raw form. Writing anything down too soon warps the process because it allows your critical and analytical faculties to come into play, which can kill the idea before it’s been fully formed. When you start to hear quotes from the treatment document in your head and when you’re scribbling pic- tures to show what the game screens will be like—then it’s time to start.

  So indulge your subconscious mind and kindle your creative spark. Author Stephen King refers to these subconscious thought processes as “the boys in the basement.” Allow yourself to daydream, but, when you have finished daydreaming, get ready for

  First Concept

  7 some serious effort. Edison said that genius is 1% inspiration and 99% perspiration.

  Well, enjoy this 1%; everything after is pure hard work. We’ll deal successively with the four phases of the creative process:

  ➤ Inspiration—Where to get ideas ➤ Synthesis—Combining ideas ➤ Resonance—Creating synergy from ideas ➤ Convergence—Finishing the concept

  Inspiration