How To Make The Next Game

By Brent Knowles

Practical advice for designers already working in the games industry and wishing to hone their skills as well as for those aspiring to such a career.
The author, an industry veteran with over ten years experience (lead designer Dragon Age - Origins) explains how companies decide which videogames to make, how to build designer-friendly game engines and pipelines and how to prototype and test.
Along the way the author explores his own experiences with game development and the difficulties he encountered adjusting to life at his dream job. With practical and blunt advice, the Lazy Designer will give you the skills necessary for becoming a valued, and maybe even essential, member of any development team.

• Language: English
• Publisher: Brent Knowles
• Release date: May 3, 2012
• ISBN: 9780987687135

Brent Knowles

Brent Knowles is a writer, programmer, and game designer. He worked at the role-playing game studio BioWare (Baldur's Gate 2, Neverwinter Nights, Jade Empire, Dragon Age) for ten years, during most of which he was a Lead Designer/Creative Director. Now he writes full time. He has been published in a variety of magazines including Neo-Opsis, On Spec, and Tales of the Talisman. In 2009 Brent placed first in the third quarter of the Writer’s of the Future Contest. He is also a member of SF Canada: Canada’s National Association for Speculative Fiction Professionals

Book preview

Lazy Designer 2: How to Make the Next Game

by

Brent Knowles

Smashwords.com Edition

#

PUBLISHED BY:

Brent Knowles on Smashwords.com

Lazy Designer 2: How to Make the Next Game Copyright 2013 by Brent Knowles

http://blog.brentknowles.com

Discover other titles by Brent Knowles

License Notes

This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person you share it with. If you're reading this book and did not purchase it, or it was not purchased for your use only, then you should return to Smashwords.com and purchase your own copy. Thank you for respecting the author's work.

Preface

Introduction

Welcome to the second book in the Lazy Designer game design series!

Though this book assumes some familiarity with the content from the first Lazy Designer book it can be read independent of that volume. The overall intent with this volume is to dig deeper into the actual details of game design. How does a company decide which game to build? How do we make a content pipeline that empowers content creators? How do we prototype and test?

As with the first, this book contains my thoughts on design based on ten years of experience with the game developer BioWare (Electronic Arts). It also includes newer lessons based on my contract work in the social gaming zone and some homebrew gaming projects.

This is not an academic book, neither am I attempting to distill a theory of design or a one-way-to-do-things approach to game design. They are merely my methods and my tools and my failures and my successes. Use what resonates; discard the rest.

What to Expect?

The ideal reader I think for this volume is a relatively new designer with limited experience on one or two titles and looking for ways to hone their skills at crafting design experiences. For them CHAPTER 4 - Starting a Seed and CHAPTER 5 - Designing Experience, will be of greatest value.

More experienced designers will benefit from my discussion of data management (game design pipelines and tools in CHAPTER 6). Testing and prototyping techniques are described in CHAPTER 7 and finally, a designer in transition between projects with idle or research time to make use of should find something of interest in CHAPTER 8 where I describe the tasks I busied myself with between games.

Please note that this book's chapter numbering continues from the previous volume to simplify referring between the two books.

About the Lazy Designer series

Throughout this work I'll make reference to other books in the Lazy Designer series. This is the second of four titles, each exploring a subset of the game development experience, mirroring my own career from new employee to specialist to manager.

Before we start delving into content I would like to make a couple points clear.

Feedback. I thrive on feedback. Please let me know when you find mistakes. My Contact Page has a variety of methods to reach me. I'm eager to know if there are topics you would like to see covered in later books, discussed on my blog, or even added to a later edition of this book. I want this to be a cooperative process where I'm learning too.

You, the Reader. I will often delve into topics of a higher level than a new employee needs to know. I do this because this is what I am familiar with. For most of my career I was a manager. I also do it because I think it helps prepare you for when you yourself might be leading teams. Even if that is not something you aspire towards it might help you understand the influence behind the decisions that your manager makes.

Buyer Beware. Some of the content in this book is already available free at my website www.brentknowles.com, in the form of blog posts I made over the past few years though it has been rewritten and reorganized here.

Why Lazy?

I believe in enhancing the work experience, no matter the task I am engaged in.

There is a time for designers to roll up their sleeves and just get the work done but when possible I think it is important that designers understand how valuable their time is. Should you waste days doing a task that could be automated and completed in a couple minutes? Doesn't it make more sense to devote your time to creative tasks?

I believe in getting tools and procedures in place so that design effort is spent in the right way — making the game entertaining. In that regard I am lazy. I don't want to do the hard, boring work. I want to work hard at the fun stuff.

Conventions Used in this Book

Anecdotes

Occasional anecdotes, generally from my time at BioWare, will appear formatted like this.

Notes

Important points clarifying the preceding text will be shown like this.

Code

Any code examples will be shown like so.

Reference

References to other chapters will be capitalized. For example, if you want to read more about designing cyborg assistants, please consult CHAPTER 96.

Chapter 1 A Beginning

You have shipped your first title, basked in the glowing praise it has received and taken a well deserved break. A couple weeks (or days or hours) later you are assigned to your next project. No longer are you the fresh from the street newbie looking to impress your coworkers... now everybody stares at you with admiration. You are a veteran.

Though you may still be in a junior role your responsibilities will likely increase on your second title and more and more often you will be challenged to generate the creative solutions your company needs to be successful. In time you may even help define the kinds of games your company makes.

A New Game

Overview

In previous chapters I wrote under the assumption that you were thrown onto a project midway through production and had little say in the core design of the project. Here I will tackle things from a different angle... imagine you are on a project that is just beginning. You might not be the design lead or even a senior designer but you, along with your other coworkers, will be involved with developing and fleshing out the gameplay for this new title.

What Game Will Be Made?

A question I am asked often by outsiders is how a studio decides on which game to make. Sometimes this question is driven by the outsider's hope (a hope very much misplaced) that game studios are sitting around and waiting for the perfect new game pitch before they start their next project. Other times the question is more of an attempt to find out why a particular title was made instead of another.

So, what is the answer?

Well, what I can tell you is that even as the lead designer of several titles I only ever influenced the direction of a game. I never pitched my game or developed a game concept completely from scratch. In a large studio even senior leads might be only tangentially involved in the choice of which game to make, the decision resting at higher levels of management. On the other hand in a small indie house more of the team will likely be involved in the decision.

Even if you are not directly involved in this decision making it is advantageous for you to understand why the decision makers choose a particular path over another.

Developer and Publisher

I want to step back a moment to clarify the relationship between a developer and a publisher.

A developer is the company that builds the game, whether entirely on their own or assisted by various contracts with other companies (i.e., a development studio might outsource their art but do programming and design in studio).

A publisher distributes a finished game. Traditionally publishers had deals with major stores and controlled distribution. If you wanted your game on a shelf in Best Buy you had to have a publisher. Also the publisher would handle packaging, localization (usually) and marketing (sometimes).

The lines are blurred now because through portals like the App Store on iOS devices game developers can reach gamers directly. But for most major titles the traditional publisher-developer relationship still exists.

For the first few years of my employment with them BioWare was an independent developer making deals with various publishers to publish their games (i.e., Interplay, Atari, Lucasarts). Eventually, as happens to many developers, BioWare was purchased by a publisher (Electronic Arts) so they have merged.

Why Make *This* Game?

Let's discuss some of the more salient points when it comes to deciding which game to build. How is a particular concept chosen?

Sequel Perhaps a game the company has recently shipped has done well enough commercially to justify a sequel (or a sequel was in the works to begin with). This is the easiest game to justify. Companies want to build upon past success.

Gameplay/Technology Maybe somebody in the company has created a compelling new gameplay feature. This might be gameplay spun-off from another project that did not use it or the company may have access to a new game engine and are looking for a suitable design concept to exploit the technology.

Wish Fulfillment Sometimes a key stakeholder in the company has had a vision of a game for a long time and feels the company is finally in a position to make the game. They have already done the initial legwork to build support for the title and will likely have a great deal of expectations and past documentation/ideas that will influence the initial design.

Setting Opportunity Your company might have been approached (or approached) a third party and has been granted a license to make a game based on prominent intellectual property. This might be a game set in the Dungeons and Dragons universe or a Star Trek title, for example. For a small studio an opportunity like this is a great way to build exposure. There are a few things to consider here.

What do you want out of your setting? If you want to tell deep stories with branching plot arcs and grim but realistic characters the choice of setting has to support this. Likewise if your gameplay will be more similar to the light-hearted actions from a comic book then you should not choose a dour and depressing setting.

Does the setting you choose give you room to grow? Does it support the gameplay you want? A Mario-like side-scrolling game about jumping, for example, might feel out of place in a setting like George R.R. Martin's dark fantasy series.

Look for a setting that allows the art style to be distinctive and something that stands out from other games on the market.

Watch out for a setting that has heavy fan bias. It might seem attractive to develop a game for a niche setting that while relatively popular is not so hugely popular that it would be impossible for a small studio to obtain the game rights for it. The danger of these smaller franchises is that in addition to the franchise being unable to give you a large pool of potential customers, the fans it does have could be incredibly vocal. If they do not like the design direction you are taking with their franchise they can make development difficult.

Very often answering why will lead directly into answering what kind of game needs to be made.

Expectations

During the early planning genre (both in terms of gameplay, such as RTS or First Person Shooter and in setting, such as fantasy or science fiction) needs to be locked down. That does not mean every detail of gameplay will be solidified during the initial decision making but the broad strokes will be painted. This title will either be a game about controlling and managing multiple medieval battle units in battle against opponents or you will be playing a single character traversing hostile territory on a derelict spaceship. Or something else.

There are caveats to keep in mind when choosing genre however. Your company may have a predilection towards a particular genre of play and if the new game being considered has a radically different style of gameplay it is likely that the company's existing fan base will have some expectation that gameplay will resemble past titles.

This is where new studios have some advantages over others... once a company has success it starts to become known for a particular brand of gameplay and when it deviates from that it risks alienating its customer base (or at the very least rousing the customer base to vocal and distracting protest). These expectations influence more than just the genre and major gameplay... expectations define everything about the title.

And not just fan expectations but also internal expectations. Often these internal expectations are even more distracting because they are not necessarily codified anywhere. You have to ferret them out.

How do you do that?

Talk to team members who have been around longer than you. Find out what their experience has been in the past. This is important to avoid wasted effort. I've seen situations where a content generator has felt they have been given free reign to do something new only to find that their weeks or months of work has been wasted. Because of an unspoken requirement. An expectation that they did not fulfill.

You have to really understand not just what you are being asked to but also why. Often what is not said is more important that what has been said.

(And yes, this is a problem of communication... in a studio that communicates perfectly the unspoken will seldom be an issue... but I'm not sure how many perfect studios exist.)

At different stages in BioWare's evolution as a studio there were different mandates. Occasionally these were explicitly defined (such as being aware of how much time would be spent