ISBN-10:
0735713634
ISBN-13:
2900735713634
Pub. Date:
07/24/2003
Publisher:
New Riders
Game Architecture and Design : A New Edition / Edition 2

Game Architecture and Design : A New Edition / Edition 2

by Andrew Rollings
Current price is , Original price is $84.99. You
  • $46.69 $84.99 Save 45% Current price is $46.69, Original price is $84.99. You Save 45%.
    Note: Access code and/or supplemental material are not guaranteed to be included with textbook rental or used textbook.

    Temporarily Out of Stock Online

    Please check back later for updated availability.

  • This Item is Not Available

  • Product Details

    ISBN-13: 2900735713634
    Publisher: New Riders
    Publication date: 07/24/2003
    Series: New Riders Games Series
    Edition description: Revised
    Pages: 960
    Product dimensions: 6.00(w) x 1.25(h) x 9.00(d)

    About the Author

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

    Read an Excerpt

    IntroductionIntroductionAndrew 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...eventually.

    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 2003Dave 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 alwaysinfallible. 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 correct. 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 wilderness. 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 streamlined, 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.

    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 2003Introduction 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 referenced 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.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 development 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 developers 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.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.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 implementation 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 software 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 software. Beginning with the core concept, the book covers all you need to know to organize 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 creating games. Good luck!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 fixed-pitch font—for example, insert example from book here.

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


    © Copyright Pearson Education. All rights reserved.

    Table of Contents

    Introduction.

    I. GAME DESIGN.

    1. First Concept.

    The Shock of the New. The Creative Road Map. Having the Idea. Shaping the Idea. The Treatment. Taking Stock. Feasibility. Getting it Down.

    2. Core Design.

    What Is a Game? Games Aren't Everything. Games Mean Gameplay. Creating the Game Spec. Example Game Spec.

    3. Gameplay.

    What Is Gameplay? Interactivity.

    4. Detailed Design.

    The Designer's Role. Design Documentation. Using The Design Documents. Fitting Design to Development. Why Use Documents at All?

    5. Game Balance.

    Player/Player Balance. Player/Gameplay Balance. Gameplay/Gameplay Balance. A Game Balance Checklist.

    6. Look and Feel.

    Ambience. Interface. Storytelling. The Sum of the Parts.

    7. Wrapping Up.

    The Professionals.

    8. The Future of Game Design.

    The Necessity of Design. Essentials of Game Design. The Future of Design. The Future of Games. Games as Entertainment. The Way Forward.

    II. TEAM BUILDING AND MANAGEMENT.

    9. Current Methods.

    The Current Development Model.

    10. Roles and Divisions.

    Assigning Personnel. Improving Morale and the Working Environment. Spreading the Risk.

    11. The Software Factory.

    What Is a Software Factory? Why Use a Software Factory? Organizing a Software Factory. Applying the Software Factory Structure and Methodology. The Suitability of a Software Factory. Smaller Teams. The Final Word.

    12. Milestones and Deadlines.

    How Milestones Currently Work. Fuzzy Milestones. Milestones and Mini-Milestones. When to Use Milestones. Making Your Milestones Accurate. Defining Milestones.

    13. Procedures and “Process”.

    Procedures. “Process”. Procedures: Where to Use Them? Source Control and Code Reviews: A Synergy. The Importance of Information Transmission.

    14. Troubleshooting.

    Risks.

    15. The Future of the Industry.

    The State of the Industry. The New Model Developers. The Online Revolution.

    III. GAME ARCHITECTURE.

    16. Current Development Methods.

    The History of Development Techniques. The Present Day.

    17. Initial Design.

    The Beginning. Hardware Abstraction. The Problem Domain. Thinking in Tokens.

    18. Use of Technology.

    The State of the Art. Blue-Sky Research. Reinventing the Wheel. Use of Object Technology.

    19. Building Bricks.

    Reusability in Software.

    20. Initial Architecture Design.

    The Birth of an Architecture. The Tier System. Architecture Design.

    21. Development.

    The Development Process. Code Quality. Coding Priorities. Debugging and Module Completion. The Seven Golden Gambits. The Three Lead Balloons.

    22. The Run-Up to Release.

    Late Evaluation. Late Localization. Playtesting. Focus Groups. The Web Site. Getting Ready for the Gold Master. Patches.

    23. Postmortem.

    Case Study 23.1A Tale of Two Projects. Team Dynamics. Concept. Development. Business Aspects. The Postmortem Postmortem.

    24. The Future of Game Development.

    Development in Context. Future Development. Small Is Beautiful Too. Building the Team of the Future. New Directions in Development. The Shape of Things to Come?

    IV. APPENDIXES.

    Appendix A: Sample Game Design Documents.

    Detailed Design Discussions. Initial Treatments and Sample Designs. Racketeers: Gang Warfare in the Roaring Twenties. Technical Specifications. Code Review Form. Test Scripts.

    Appendix B: Bibliography.

    Glossary.

    Index.

    Introduction

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

    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

    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 leftmost 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 correct. 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 wilderness. 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 streamlined, 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.

    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

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

    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 development 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 developers 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.

    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.

    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 implementation 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 software 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 software. Beginning with the core concept, the book covers all you need to know to organize 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 creating games. Good luck!

    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 fixed-pitch font—for example, insert example from book here.

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


    Customer Reviews

    Most Helpful Customer Reviews

    See All Customer Reviews