Game Architecture and Design : A New Edition

by Andrew Rollings, David Morris

Overview

Game Architecture and Design: A New Edition is a revision of the classic that you have been waiting for! This is a detailed guide to game design and planning from first concept to the start of development, including case studies of well known games. Originally published in 1999, Game Architecture and Design, has been updated by the original authors Andrew Rollings and Dave Morris. They tap back into what they teach so well and update this classic with skills and techniques found in the industry today. With more than just re-usable code, it's a comprehensive study that deals specifically with the issues of game design, team building and management, and game architecture. Through the use of real-world experiences and case studies, Andrew and Dave share it all. They show you what's worked and why as well as what to avoid and how to fix any errors. This intelligent and well-argued book is a glimpse into the often-disordered world of game development. Readers will gain solid advice and know-how that can bring some order to the often-chaotic world found in game development.

Product Details

ISBN-13:	9780735713635
Publisher:	New Riders
Publication date:	07/24/2003
Series:	New Riders Games Series
Edition description:	Revised
Pages:	960
Product dimensions:	7.38(w) x 9.10(h) x 1.80(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 [e-mail].

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 [e-mail].

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.

Preface

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

© Copyright Pearson Education. All rights reserved.