游戏开发合同的谈判

htly insist that it withhold a portion of royalties to cover for the likelihood that much of what it “sells in” at retail may not “sell through” to consumers and may instead be returned. The question is, what does a license agreement mean if it provides only for a “reasonable reserve” for those expected returns？ Is 10 percent enough？ A publisher may insist that even 40 percent doesn't represent its true returns figure for certain types of games. The developer and its counsel should ask themselves whether a high returns reserve proves that the publisher is willing to take risks to build hits, that the publisher simply kicks product out the door whenever it needs to puff up the bottom line or issue a press release, or that the publisher's lawyer was just hoping no one would ask. Whatever the reserve, the developer should counter that it be liquidated within a prescribed period. An annual liquidation is customary.

　　Development Schedule： Milestones

　　Delivery of the game is typically made in accordance with a multiphase development plan articulated in the publishing agreement, most commonly structured in the form of a milestone schedule. There are customarily between eight and 15 milestones. While the first milestone is often the execution of the agreement itself, each subsequent milestone will likely be for delivery of game work product, each to be presented to the publisher by the developer for comment, approval and payment.

　　Although well-written milestone schedules are rarely identical, there are certain standard deliverables that most milestone schedules contain. One is for the original design document, which outlines the story, method of play, objectives, puzzles, level design, technical capabilities and specifications, and which contains preliminary artwork. There also may be a subsequent milestone for delivery of a prototype, which consists of a small segment of the game in its earliest, minimally playable form, filled with placeholders. Indeed, in a prototype-based deal, the balance of the milestone schedule may not even be agreed on （and the project given the green light） until after approval of the prototype. Whatever the structure of the milestone s

chedule, the last three milestones will almost invariably be carefully defined： the alpha, beta and gold master versions. The alpha version will likely be the game in a form that is more than 95 percent complete； some levels and details will be incomplete, however, and the version likely will contain bugs. The beta version must have the game in a form ready for full quality assurance testing. Any major bugs in the beta version must be closed prior to the delivery of the gold master for distribution and sale. Given that the elimination of all bugs is almost impossible, it is important for the developer to ask for the contract to state clearly what constitutes an unacceptable bug for the purposes of quality assurance testing.

　　When agreeing to the milestone schedule, a developer should set realistic goals for itself. That is because the publisher will almost certainly have the right to consider any unexcused delay in delivery to be a breach of the publishing contract. Publishing contracts sometimes provide for a pocket veto, whereby the publisher's failure to approve a deliverable item （even if delivered on time by the developer） has the same effect as an explicit rejection by the publisher.

　　If the publisher rejects a delivery, the developer must resubmit the deliverable for that milestone, potentially placing the project behind schedule and further delaying the developer's receipt of crucial advance payments. It is therefore in the developer's interest to press for a milestone schedule that pushes back the deadline for all deliverables in the event of reasonable delay caused by the need to rework and resubmit any deliverable due to its rejection. Just as important is a provision in the contract requiring the publisher to accept a particular deliverable （where appropriate） based on an objective technical standard, or at least a standard based on reasonably acceptable commercial standards.

　　Sequel Rights and Later Projects

　　The fact that this is an industry that can announce a major title called “Final Fantasy XI” without a trace of irony indicates how important sequels are to the market. The developer may take the position that it should retain sequel rights. The publisher will likely counter that having spent the time and money to launch a title good enough to warrant a sequel, the publisher deserves the right to participate in the revenue, regardless of whether it is ultimately the publisher of the sequel.

　　The parties may agree to a provision whereby either of them would have the right to call for the creation of a sequel and give the other an opportunity to participate financially under each of the following contingencies： The developer makes the sequel and it is published by the original publisher； the developer makes the sequel but another publisher picks it up； or another developer makes the sequel but it is published by the original publisher. An alternative arrangement would be to grant a limited sequel option to the initial publisher, one that would expire within a certain period of time following the release of the initial game. The contract also should consider the potential that the publisher will seek the rights not only to a sequel or two, but to an entire franchise arising from a hit game.

　　Related to the franchise question is the broader issue of later projects. As in the music business and the book-publishing business, entertainment software publishers often take the position that they are investing in talent, not merely a particular project. There is logic behind this： Consumers generally don't choose games based on the publisher's brand any more than they choose music recordings based on the record label or select books based on the publisher's imprint. （One notable exception is the EA Sports brand, which generally means more to consumers than the names of the development studios that create the titles.） For that reason, a developer receiving its first co

ntract from a publisher may be surprised to find a clause that gives the publisher first dibs on one or more future projects, even if they are not part of the instant product's franchise. At the least, the developer should insist that future projects will have advances appropriate for the specific work required to develop them.

　　Cross-Collateralization

　　If the publisher expects multiple releases, either through different versions of a game or through sequels or later projects, it may ask that royalties from most or all of them be “cross-collateralized.” That odd term of art, sounding as if it more properly belongs in a contract of indebtedness, could, at its worst, make the developer's employees feel that they have become debtors of the publisher. Cross-collateralization means that royalties for one project that has earned back its advance may be used to recoup advances on another project that has not yet earned back its advance. The strongest kind of cross-collateralization clause makes every game in every version “fully crossed.” In theory, a developer that is steadily delivering games for a publisher could find itself being paid nothing under such an arrangement, because royalties that would have been paid to it for games that have been on the market for some time will instead be applied toward the recoupment of advances for games that have just been released.

　　The solution for the developer is to gain at least a partial uncrossing. For instance, the developer could take the position that once sales of a game have allowed the publisher to recoup the advance for it, royalties from that game should no longer be applied toward any other advance. In that way, a developer with one game that is earning royalties and two that are not may continue to obtain royalties from the one game that is in the black. There are other possible compromises, but the main lesson to be learned from cross-collateralization is that careful drafting and knowledge of the financial implications of what has been drafted are the best protections against later disappointment.

　　Copyright, Trademark, Advertising and Packaging

　　In a license agreement of the kind discussed here, the developer will retain copyright ownership, but it may be asked to cede to the publisher the trademarks in the game. If the developer owns the copyright in the game itself and the publisher owns the trademarks （for the title, logotypes and characters, among other elements）, things can get murky—and, if there is a creative or business disagreement, things can get ugly—if the agreement does not clearly delineate the rights of the parties.

　　When it comes to packaging, advertising and public-relations issues, it is nearly always the publisher, rather than the developer, who has the final word. The publishing contract also may restrict the developer from issuing press releases about the product without prior approval by the publisher. The contract may further provide that key development personnel must be available for promotional activities arranged by the publisher. These small but potentially sticky issues—being more personal in nature than others—should be given due consideration by the developer and its counsel, even if, at first blush, they don't appear as important as issues directly affecting revenue.

　　Conclusion

　　Negotiating a workable development contract is critical to a development studio that hopes to reap financial rewards commensurate with its hard work. Careful drafting and consideration of all the issues prior to signing an agreement can help a studio avoid unnecessary risks and allow it to

┨网页设计特效库┠ http://www。z┗co⊙l。com/网页特效/