Home > Articles > Royalties

Toward an Alternative to the Advances, Recoupment, & Royalty Model for Developers

by Jim Charne
© 2002 Jim Charne

Advance= “A prepayment of developer royalties.”
Recoupment = “To reimburse. To repay. To deduct or withhold.”

Is it time to scrap the advance, recoupment, and royalty model for games development?

Short of a Harry Potter or Black & White, how many developers see royalties for their efforts? Tales of royalties for all but the tiniest handful of games are fast becoming the stuff of urban legend - like crocodiles in the New York City sewer system, or Walt Disney’s cryogenically preserved remains.

Characterizing publisher payment of development expenses as an “advance” means developers happily use their own royalties to pay production costs for games that are owned and controlled by publishers. That is because recoupment means that the publisher retains developer royalties until it has repaid itself for the full cost of development.

From where did this business model come? It’s the norm in book and recorded music deals. When it was adopted early on by the games industry, an average advance was £10k or so, the retail price of a game around £20, and royalty percentages were equal or better than current rates.

Compare this to today. Advances can be 100 times higher because projects are that much more complex. However, the retail price has only increased by a factor of two or three, and royalty percentages are the same or lower. It doesn’t take a rocket scientist to see that the possibility of earning enough in royalties to recoup the big advance is far less today than when games were played on Ataris, Sinclairs and Commodore 64s.

The advance and royalty model may have worked in the early days when there were royalties to be earned, and projects were short and very manageable. But in today’s industry, where game development can take two years or more, and where designs, producers, and even companies can change repeatedly during the course of development, there has to be a better way.

One alternative would be a time and materials model. “Time and materials” (known as T&M) means the developer bills the publisher for its costs based on its staffing and overhead, and receives regular payments at the agreed upon rate as work is performed.

T&M has advantages that both sides could appreciate.

For developers, who are highly labor intensive service businesses, there is certainty. T&M evens out cash flow by assuring that all costs plus an agreed upon profit margin are covered.

Because development costs are paid by the publisher with no issue of recoupment, the publisher can make a stronger case that it should really own the code (other than developer’s tools and technology); and that the work truly is a “work-for-hire” (a topic for another day!).

In a typical heavily backloaded advance and royalty deal, the developer may be forced to scramble behind the scenes and assign resources to other projects that generate cash flow. Without the developer having to “improvise” to deal with the uncertainty of payment delays, publisher’s subjective approval of milestones, and heavily backloaded payments, projects could run leaner, tighter, more focused, and maybe even cheaper. Publishers like cheaper.

The T&M model places new responsibilities on both developer and publisher. Both must do a better, more detail-oriented job managing their businesses.

Are publisher producers capable of handling it? Do publishers really trust their own producers? For the T&M model to succeed, the publisher producer must work through a comprehensive pre-production phase with the developer and fully understand the technology, game design, staffing requirements, and development plan. He must also be qualified to project manage so that he knows immediately when the project may be veering off plan and be capable of setting it back on course. Appropriate training for this responsibility could be a graduate level degree in management and love of gaming.

The developer must be open to more intimate involvement by the publisher producer in its development process. And the developer must be a better financial planner so it can truly calculate the cost of a project including support, overhead, management, benefits, hiring, equipment, financing, insurance, legal and all other real business costs that are incurred, including developer profit.

What is appropriate developer profit? For me, this is the least difficult issue. Publishers are quick to point out that developers are partners in creating a great game. I’d suggest looking to the most recent annual report of your publisher and figuring the same net before tax profit percentage as your publisher reported. If he’s not in the black, a quick soul searching might suggest the average pre-tax profit percentage of profitable companies in the industry, or it may cause the developer to question altogether whether this is a good idea to be developing for a company operating in the red.

How about royalties? Under this T&M model, the developer has already achieved the same historic profit margin as its publisher. Since there is no “advance” to recoup, a lower royalty rate is appropriate, payable after the game achieves pre-determined levels of success and profitability for the publisher. In today’s climate when the possibility of royalties is too often illusory, getting into a royalty situation may be greatest incentive to deliver a great game!

 

Author Bio

Jim Charne practices law in Santa Monica, CA (www.charnelaw.com) where he represents developers, designers, and other clients in the games industry. For the past five years, he has been chair of the all-day legal and business tutorial at GDC. He writes “Famous Last Words", a monthly column on development contracting issues.Jim is a voting member of IGDA, AIAS, and NARAS (the recording Academy), and from 1998 to early 2001, served as President of the Academy of Interactive Arts and Sciences.

A version of this article first appeared in the May issue of Develop magazine.

 

The opinions expressed in this article do not necessarily represent the IGDA.