Well, another week where I was too busy to write a good blog entry. So, I'm gonna take the cheap way out and dump one of my handy text files here, one that I use to keep track of contractual deal points for future agreements. This is real behind-the-scenes stuff.
I started this doc about 7-8 years ago, and every now and then I'll add a little more too it, especially if I've talked to another developer who tells me of a technique they use, or a publisher trap they try to avoid. Whenever I enter into a new agreement, I make sure that all of these points are considered and covered, if possible. It works as a reminder list.
The hope is that others will benefit from it. So, here it is, warts and all, a full, unedited dump:
o We have full approval rights on the product.
o We have full approval rights on all marketing of the product.
o We must have audit rights. There must be a interest penalty for late payment.
o We must have credit/logo on packaging, at least equal to the publisher's logo size and placement
o COGs must be precisely defined and capped -- never leave this open-ended.
o Make sure there's a clause that prevents the game from being assigned to another company under any condition, including the sale of the company.
o If there's ever a port or remake (or otherwise) opportunity, and the publisher doesn't want to pursue it, then rights revert to us.
o Credits: Original developer's credits are always listed first, even in ports (even if ported by a third party).
o Marketing costs should not come out of COGs -- this is a publisher expense.
o We need to see the top 12 countries' quarterly sales reports, broken out individually so that we can see how the game is selling in each of those countries.
o We get all awards, plaques and trophies for the game. (The publisher may pay for duplicates for themselves.)
o Reserves for returns should be capped at 15% of royalty.
o Reserves must be paid the following quarter.
o Penalties for leaks during development (e.g. penalty of 25k per leaked screenshot or demo, penalty 250k for leaked build).
o Currency risk to publisher i.e. payments locked into our currency (USD).
o Updates (patch obligation) limited to one year after release.
o Penalty for late advance or royalty payments -- and if late beyond a certain cure period (say 60 days), then the term of the agreement and all rights are negated.
o Three late payment notices, by Fedex or other tracked service, is considered material breach of contract and can be cause to severe all agreements, including those for games still under development. Quite simply, make payments on time. Being paid is the entire point of the relationship!
o No console rentals for the first five months of each individual's console release. Rentals destroy retail sales.
o If the publisher makes royalties or bonuses from rentals (i.e. console rentals), then we get 50%.
o Limit the number of games that can be used for promotional purposes, or for sales incentives, to 1000 games. Otherwise, the publisher can shrewdly use your game as part of a sales package, and move 1000's of them without your benefit.
o Make sure indemnity works both ways.
o Kill Fee. The rationale behind asking for a kill fee is that the publisher can cancel the project at any time, in which case the developer may be in dire straits. Often times the developer has added staff and increased expenses to accommodate a project. A kill fee should buy you enough time to land another deal, and also make the publisher think twice about canceling the project. At the very least the kill fee should cover the current and next milestone payments.
o IP. Most developers in the console world work on games who's IP is owned by another party or by the publisher. Regardless of who owns the game IP, it is crucial to maintain ownership and control of your code. A proprietary engine for example is something that console developers will use on multiple projects with multiple publishers. You can't do this if you give the rights away to one publisher. It is unreasonable for a publisher to expect that just because they pay for the game, that they get rights to your code also. Especially if the code existed prior to this publishing deal. Don't agree to ship code to the publisher by request. You should be able to argue that the code will be held in escrow. This will prevent the publisher from accidentally borrowing code.
o Passive royalties. It is fair to expect a passive royalty on ports based off of this game that are not done by you. A passive royalty of 5% is pretty standard. If the publisher decides to do a sequel with another developer, but wants to use assets that you've created for the franchise, it is fair to expect a 5% passive each time it's used. Royalties from one game should never be cross collateralized with royalties from sequels.
o Ports & Sequel rights. You should be able to get sequel and port rights to this game if the publisher decides to do them. It's a good idea to spell out the terms of the sequels and ports in this contract too. You should include royalty rate, recoup rate, and game budget.
o Budget. When asking for a bid on a project, several console developers will also ask for an expense break down for things like salaries, overhead, etc. *NEVER* *NEVER* *NEVER* give a publisher information about how much you pay your people. It is none of their business. The most you should tell them is that the bid you are providing includes salaries, overhead and a small margin to cover unexpected costs. If you give out specific numbers, you will only be whittled down. Also, advances should under any circumstance, ever be refundable.
o Key Employee List. It is fair for a publisher to ask for a key employee list for the project, but that list should be limited to lead artist, lead designer, and lead programmer. Also, the terms of the Key Employee List should not state that these people will work only on this title, but that these people will give priority to this title. Console developers with multiple teams will often share resources for efficiency, i.e.. an engine team, a tools team, art director, creative director, technical director. These people should never be contractually bound to one title.
o Dependencies. In the console world, where working on a licensed IP is common, the developer is dependent on timely delivery of certain things by the publisher in order to get the job done. It is important for the contract to state that any delay in getting material or approvals needed to develop the game, will cause a delay to the schedule. Any such delay will result in cost overages which are to be paid by the publisher, and not held recoupable versus royalties. Dependencies should include things that are the publishers responsibility, for example, providing audio, materials & approvals for the IP, etc.
And to wrap up, if you liked this stuff and want a little more, you can jump over to the IGDA where you'll find an article I wrote in 1998 (as one of the owner/founders of Gathering of Developers), The Ten Developer Commandments. If you have any similar contractual deal points, please do share...
"It's true that the hardcore gamers do often pirate many games and either a)don't buy any, or b)buy only those they love enough to 'support'. I don't think this is much of a problem; I could be wrong."
I think you're wrong. At one point I had a friend who was CEO of a minor development studio with a large following for one specific product. Through heavy research they had managed to establish via multiple studies independently researched that four times more pirated versions of their software existed than legally distributed versions.
That same CEO decided that the loyal customer base who had initially pirated the software would probably be willing to pay, but may have been unable to do so at the time, and so granted "Amnesty" in that if a person registered their software for a 15 dollar fee they would receive an original CD key and the program would be thereafter considered a legally licensed version.
The result? Practically no one responded, while the community surrounding the software went up in arms because they felt that a product they'd paid for was being given away for a steal to those who had acquired it.
With the next release, the studio decided to avoid the entire ordeal by using a very reliable form of copy protection that required every end user to register their version by phone, mail, or through a direct link to the company site. The process took about 3 minutes.
In response, the same user base once again publically bashed the company until they had little choice but to remove the copy protection scheme with a publically available patch.
Granted, this is just one story from personal experience, but it illustrates yet another paradox of the software and games industry. Software piracy cripples sales, and copy protection methods turn off customers.
Posted by: Paul Jenkins | Monday, January 19, 2004 at 04:33 AM
The best way to beat piracy is to have a game with multiplayer, implemented with a very good CD-Key system.
All other forms of protection for single player games (no net connection needed) are quite eaisly beaten. Even the likes of XIII which had 'the latest and greatest' protection was disabled in a week.
If you try to implement that into a SP game then gamers will go up in arms about needing to connect just to verify the CD-key to play a _single_ player game.
My solution? Don't include copy protection. Your just wasting money licencing or inventing a protection that doesn't stop pirates and just annoys the buying market. Just got to keep them out of multiplayer with the cd-key system.
Of course, it's not ideal for the devs and pubs but so far there's really no other way.
Posted by: wormstrangler | Monday, January 19, 2004 at 05:11 AM
Actually I was talking console piracy, but I really didn't make that clear. I agree, computer software piracy is an entirely different deal. And an insanely larger one. My bad.
Posted by: Jeffool | Monday, January 19, 2004 at 05:37 AM
A question I have to raise every time piracy is being discussed: how many pirates would have bought the product in the first place if piracy hadn't been an option. Businesses always offer the most radical estimates possible on piracy losses (for obvious reasons) by assuming that every pirated copy means a lost sale, and that is so far from the reality of the matter it's crazy. Some of the most active pirates are people who wouldn't spend a dime on media / software if piracy weren't an option. For this reason I am deeply skeptical of any self-published piracy statistics. Yes, it's a problem, but most businesses are living in a fantasy world.
Posted by: JP | Monday, January 19, 2004 at 10:27 AM
Regarding piracy:
If you are in the business of distributing media - be it music, movies, games, books, or otherwise - you'd better just accept that a certain number of people are going to pirate your product. Period. If you can't make money in that environment then get out of the business, because it's never going away.
That said, one way to ensure that you make money is to attempt to foil the pirates as much as possible. I like the approach Insomniac took for Spyro: Year of the Dragon (see Game Developer, 3/2001 or http://www.gamasutra.com/features/20011017/dodd_01.htm).
The basic idea here was not to prevent piracy outright, but to make a "crack protection" scheme complex enough that it took a couple of months for the pirates to truly crack the game. By that time, Insomniac had already sold the majority of copies they were going to sell anyway. An interesting approach IMO.
Posted by: Brian Krueger | Monday, January 19, 2004 at 01:58 PM
a quick look at what you have here and i can already see some handy hints for me to use in the music biz.
great work.
Posted by: Brut | Tuesday, August 23, 2005 at 11:30 PM