Securing a Development Contract: The Art

Một phần của tài liệu Secrets fo the game business game development series (Trang 212 - 233)

Overview

Ed Bartlett, business development director, The Bitmap Brothers

<ed@bitmap-brothers.co.uk>

<bartlett_ed@hotmail.com>

Gone are the days when it was possible to sign a development deal from a handful of buzzwords shouted during a post-E3 party. With team sizes, development schedules and product budgets on a seemingly unstoppable upward trend, and a noticeable bias toward what publishers consider "safe" product such as sequels and licenses, pitching new product to publishers is becoming increasingly unpredictable, complex, and frustrating, particularly for smaller, lesser-known teams.

This article looks at the pitching process in detail and explains the rudimentary criteria that should be fulfilled in order to maximize the impact of your pitch and help streamline the signing process.

What Is Pitching?

pitch1 (pich)

v. pitched, pitchãing, pitchães v. tr.

A form of words used to persuade.

1.

To attempt to promote or sell, often in a high-pressure manner.

2.

Set or aim at a particular level, target or audience.

3.

Almost every industry has to pitch for work in some way, shape, or form, and this applies particularly to creative industries, in which companies compete against others in their sector for key accounts and contracts.

Pitching is the established way for a client to evaluate exactly what an individual, team, or company can offer them in terms of services and skills by allowing them to prepare a highly specific presentation containing not only details of any relevant products, but also important peripheral aspects such as background and company history, staff profiles, and previous work samples.

In the case of videogames, publishers have limited budgets and resources allocated for each quarter, so even if their game concepts are different, developers are still competing for a slice of the same pie as well as regularly pitching directly against each other for "work for hire" deals, usually based around publisher-owned intellectual properties (IPs) or licenses.

Numerous pitch types take place within the videogame industry, ranging from middleware vendors touting tools and technology, to publishers selling in their latest lineup to retail, but in this article we will concentrate on the most nebulous of pitch type: developer deals.

Deal and Product Types

Before touting your development skills, it is important to understand the different deal and product types on offer.

Deal Types

Work for hire. The most straightforward of contracts, this "cash for content" deal generally sees

developers pitching for the right to work on one of the publishers own IPs or acquired licenses. Publishers are looking for emphasis on professional production techniques, stability, and a proven team or track record. "Work for hire" teams rarely secure more than a basic royalty rate, although many such deals involve working on franchised or licensed products, which tend to have a greater potential of realizing royalties for the developer.

Prototyping deal. As publishers look to minimize their long-term development risks, many are starting to offer prototyping deals. Here, the publisher pays the developers' costs, or "burn rate" for a short period of time (usually three to six months) to allow them to produce a more detailed "proof of concept" demo to evaluate before making the final decision on a product. Some publishers also use external development teams to create prototypes of games they intend to develop internally rather than tie up their own teams, in which case the developer will factor a larger percentage profit margin into their burn rate.

Development deal. The most common deal type, where the publisher funds a new product through a royalty advance, a set number of milestone payments to cover development overheads, and an agreed royalty rate once the publisher has recouped the advance.

Publishing deal. Effectively a marketing and distribution deal, here the developer approaches the publisher with a finished or near-finished product, negating the publishers' risk as much as possible and maximizing the opportunity for the developer to negotiate a substantial advance and higher-than-average royalty rates. With the massive budgets and protracted development cycles of modern AAA titles

(publishers grade products internally according to its quality and sales potential, with AAA at the top of the scale), the straight publishing deal is now the Holy Grail for all but the biggest and best developers.

Product Types

It is important to consider that the parameters of any potential deal will also be dictated to an extent by the type of product in question.

Original IP. A developer approaching a publisher with a totally new, untested IP needs the sharpest of pitches in order to convince publishers of its merits. Publishers regard new IPs as the biggest risk, as they are an untested and therefore unknown quantity. The risk factor is exacerbated if the product is devoid of a compelling character, environment, storyline, or gameplay "hook" for the marketing department to work with, which is why it is increasingly important for developers to consider such factors from inception.

Third-party IP. Usually a work for hire deal using one of the publishers own IPs, the developer must be able to deliver a quality product according to rigid schedule and budget guidelines.

Third-party license. Licenses are still very hit and miss within the games industry, and the pitching process for licensed products generally reflects that, as the developer often has to please both the publisher and the licensor. The majority of licensors also have little or no knowledge of the game industry

or development process. Therefore, where some licensors will require a creative solution, requiring the developer to re-work the subject matter for a gaming audience, others will demand that the IP remains untouched. Many simply don't know what they want. Fortunately, most publishers are now securing more control over licenses before commissioning them for games, and some licensors are even securing a developer and creative brief before approaching the publishers.

The Fundamentals of Pitch Preparation

While there are a number of different types of pitch, they share the same core structure needed to provide the publisher with a well-rounded overview of any potential product or deal. The following section outlines the main stages in detail, giving hints and pointers along the way.

Researching Your Concept

When developing any new product, research plays a fundamental part, and videogames are no exception. It's one thing to have a great game idea, but the sooner you gather hard facts on potential competitor products, consumer demographics, and platform statistics, the easier it will be for you to create a concise pitch that will convince the publisher that your product is more than just a good idea.

Start by looking at products that are broadly similar to your "high concept" and then compare and contrast your unique selling points (USPs). Look at which publishers tend to favor that genre of game and get your hands on platform- and territory-specific sales figures, marketing information, and any relevant press coverage for competitor titles.

It's important even at this early stage to consider how you will differentiate your product from similar titles, and if it's highly original, how will you make the most of its features and establish it as a unique brand in an overly saturated market. A frightening number of developers never consider marketability, positioning, and brand development, and are all too happy to leave such important details to the publisher, even after a deal is clinched.

Preparing Documentation

It is very likely at pre-pitch stage that you will have a short, concise document outlining the fundamental elements of your concept. Until fairly recently this was all that was required when pitching new products.

Nowadays, however, publishers are keen to read more deeply into your game mechanics and theory.

Feature-creep has cost publishers countless millions in the past, so the more concrete a design they can see in place from the beginning, the better. A good idea is to create two separate documents: a marketing/concept overview document and a design bible.

Marketing/Concept Overview Document

This document is for people who do not have the time or necessity to digest every ounce of your game design, but rather need a concentrated "shot."

It should ideally weigh in at less than 20 pages, starting with a concise, accurate, and informative overview of your concept including positioning, and subsequently detailing in a similarly concise manner elements such as:

Storyline Setting Characters Key features Competitor analysis Bullet-pointed USPs

The concept document should also be fairly graphical. Avoid filling entire pages with text; instead, try interspersing text with attractive concept and early game art.

Design Document

The nature of a design document tends to vary from game to game, designer to designer, and company to company. At the pitching stage, the advice would be to focus your designers' time on documenting, explaining, and illustrating only the key functionality, including:

Control features

Game and level progression Graphical themes

Core game systems

Any unique, unusual, or important functionality

Unlike the concept/marketing document, the design document needs only to be graphical when illustrating gameplay features.

Creating a Demo

The "proof of concept" demo has fast become the most important aspect of pitching to publishers. Demos themselves have evolved from simple technology prototypes through to impressively feature-complete previews of what the final game will offer.

With development costs escalating as they are, assigning even a small team to a demo for just a few months can cost developers dearly, especially as there are no absolute guarantees that their game will get signed, regardless of its quality. Indeed, many a developer has gone out of business during the crucial pitching

process. For these reasons, it is essential that you plan carefully and extract the most value for money or "bang for buck" from your demo.

Planning

As with a full product, it is vital when creating a demo that you plan in advance the time and cost factors. This involves working out exactly which features you intend to implement, and not necessarily what you think should be in the demo but rather what the publisher will want to see.

At demo stage, publishers nowadays are rarely moved by amazing graphical routines. What they really want to see is proof that your core game systems—particularly those that are new or different, or that feature strongly in the USP list—work as planned.

Consider the first presentation of your demo and if at any point you would have to say to the publisher "now imagine . . .," then you need to do more work. Never take for granted that other people will have the same vision of your concept as you do.

Once you have an understanding of what is required for your demo, you should sit down with your department heads to prepare a schedule. Again, be realistic. Always remember there are no guarantees that you will ever sell your game or recoup the cost of creating the demo, so while an increased content and quality level within the demo presents a stronger case to publishers, if you still fail to secure a deal your financial loss will be even greater. Pitching is a very delicate balancing act.

Choosing a Platform

Another key consideration when preparing a demo is the target platform. As the vast majority of development work is done via the PC, this is for many the obvious choice, but not always the best one. Presuming that you have researched your concept, you will have a fair idea as to the platform(s) that best suit it. If your primary shelf keeping unit (SKU—i.e., version) is console-based, however, most publishers will want to see the demo running on that platform before committing, both to show that you are a registered developer and are capable of creating content for that platform, and that the key features you are including are possible within the fixed limits of the target hardware.

If you are already in possession of the necessary equipment, then this is less of a problem. However, for startups and PC-only developers, both the time and cost of obtaining hardware and finding experienced staff must be taken into consideration. If for any reason it is not possible to develop your demo on target hardware, then consider options such as keeping your PC content in line with console specs, show demo footage running on a TV, and develop your control system using one of the many console joypad adapters on the market so that at least the publisher can feel as though they are playing it on the relevant system.

Using Middleware

Middleware is one of the biggest stories in recent development history and has in a short space of time evolved from simple component software such as video codices to complete game engines at the bleeding edge of technology.

Middleware can greatly enhance your development process—RenderWare Studio, for example, can be used to develop simultaneously for PC, PlayStation 2, Xbox, and GameCube. Moreover, such software is especially useful when developing your demo, as they already contain much of the core functionality you will require, thus allowing you to concentrate your limited time and resources on implementing the key features.

Bear in mind, however, that middleware is not a magic cure for all game development issues, nor is it suitable for all developers and all games, and time saved at the demo stage might be lost later in development. Unlike proprietary technology, when using middleware, you are never 100% in control, and middleware vendors work to different ideals and deadlines than your team and product do.

Although many publishers are warming to middleware solutions thanks in part to the success of games such as Grand Theft Auto 3, some still favor developers with proprietary technology, and others even have exclusive deals with certain vendors or buy licenses in bulk. This also needs to be taken into consideration when deciding on your technical solution.

Schedule and Budget

Although a detailed schedule and budget analysis are rarely required until after the initial pitching stage, you will obviously be required to give the publisher some indication of the cost of the product, and at the very least an estimate of which quarter of the year you will deliver it in.

Diligent developers will create accurate breakdowns as early as possible using spreadsheets specifically designed to allow fast and accurate assessment of project budgets using predetermined hardware, software, and overhead figures. It is also useful to develop two different breakdowns detailing the game features you can deliver on varying budgets. This shows that you are flexible, and can save a lot of time at the negotiating stage.

Most publishers will naturally try to knock down your price, so always go in slightly higher than necessary without pricing yourself out of the market.

Case Study 3.2.1: Team 17

The pitching process has changed dramatically since the early days of the industry. We asked veteran Team 17 Creative Director, Martyn Brown, how they have adapted over the years.

Q: How has the pitching process changed for developers over the years?

Q: What types of materials do you prepare before approaching publishers?

Q: How many publishers do you approach initially, and what do you look for?

Q: Do you tailor your pitches to the individual publishers?

Q: What do you think is the most important thing a developer can offer a publisher?

Answers

A: "The most apparent change is the risk assessment and due-diligence carried out by publishers nowadays. A few years ago, pitches were relatively simple, brief, and to the point. The industry has matured; no matter how good the developer, you need a commercial or business manager to help with the pitching process."

A: "We prepare many items, from the obvious game design overview and concept materials to a business plan, sales forecasts, and marketing ideas. This can differ from publisher to publisher depending on their individual approach and prior requests."

A: "I think in the current marketplace there are only a handful of publishers that are capable of doing justice to our titles, so we approach only the major players, most of whom are U.S. based. In terms of publishing, we look for security, presence in the marketplace, distribution capability, and how we can fit into their 'machine'."

A: "We produce a main core of generic presentation materials that the majority of publishers will see.

We have produced publisher-specific content where it is applicable or it has been requested.

However, I think it's important to have a well-covered, well-rehearsed pitch in terms of consistent content."

A: "There are a number of things that are vital to a successful pitch, and I would personally think that the

ability, organization, resources, and reputation of the developer are first and foremost.

"A prototype that reassures publishers on technical implementation (upon the core platform where possible) is also extremely useful since few, if any, original pitches are made on concept ideas these days. In all cases, developers need to identify areas of publishing risk and allay those fears."

Product Presentation

Before making contact with publishers, you should create a digital presentation using software such as

Microsoft PowerPoint. This presentation should be used as the first point of contact for anybody evaluating your game. Its purpose is to educate newcomers to your product in the most concise and attractive way possible, leaving little of your ideas for the game open to interpretation, but without going into design-doc-size detail.

The basic structure of the presentation should be fairly similar to that of your cut-down concept/marketing document, but with bullet point summaries replacing paragraphs of text.

Using no more than a single slide per heading, and following a similar order, key content should include:

Introduction. The first few pages should include an attractive title page and suitable game-related imagery and company logo branding; an introductory paragraph outlining your new concept focusing on the

storyline, game genre, target audience, and platforms; the top two or three features that make the game stand out; and a page detailing your perception and research on the market for such a game and why you believe your particular title will be successful. Be wary of making any overly assertive assumptions at this stage.

Sales figures. If your product is part of an illustrious franchise and boasts fantastic sales figures, be sure to insert them early on to get the publisher's attention. If you can break them down per SKU and per territory, all the better.

Game features and USPs. The next several pages should cover all key game features in a purely bullet- pointed fashion, starting with engine and technology details, focusing primarily on the core gameplay and single-player features, and ending with an overview of any multiplayer features, if applicable.

Visuals. At this point in the document, you should break the monotony of pages of text by showing off two to three pages of concept art, game models, screenshots, and videos, depending on what you have available. Line them up neatly as thumbnails within the presentation and link them to full-size versions on the CD so they can be experienced in their full glory.

Press coverage. Developers are increasingly using the specialist press as a tool to help secure deals by releasing details of the game almost from inception. If you have any positive press coverage, it's good to include links and details to help marketing teams gauge potential press and public opinion.

Competitive analysis. The worthiness of a competitive analysis depends largely on how far away from completion your product is. If you are at the start of an 18-month development cycle, it is unlikely you will have an accurate picture of the games with which your product will eventually compete. However, at the very least it is worth listing key titles in the same genre, and briefly comparing and contrasting key features and USPs.

Demo. If you are including playable code with the presentation, you should link the appropriate file into the presentation to ensure that the publisher is aware of that fact, and allow them to install the program before continuing with the presentation. If you are not including playable code, you should at least attempt to supply a crisply edited video clip of your game or technology in action to whet the appetite.

Company profile. At the end of the document, you should include a brief company profile, including softography and any relevant links, allowing the publisher to find out more about you without having to ask.

Một phần của tài liệu Secrets fo the game business game development series (Trang 212 - 233)

Tải bản đầy đủ (PDF)

(404 trang)