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