For an industry whose value is estimated to lie somewhere between music and the movies, and is by any standard measured in billions of pounds, the legal considerations relevant to the games industry are seldom discussed. But to approach a games development contract as if it were any other software contract would be a mistake. Why is that the case?
First, in common with any specialist area, there are peculiarities of the industry which need to be understood. One has to be prepared for clauses and terminology which would seem unusual in a standard software development contract, know which to concentrate on, and how to deal with them effectively.
Secondly, one needs to appreciate the dynamics between the parties, and in particular the balance of power in the industry. Power is concentrated in the hands of games publishers and platform manufacturers. Developers, typically smaller, are rarely in a strong negotiating position, unless on the back of a strong track record. When acting for the developer, to approach each clause in a publisher’s contract as fair game for negotiation is an exercise doomed to failure.
Finally, it is important to understand that the economics of games development are quite different from standard software development. Notwithstanding the size of the market, but in common with both music and movies, there is oversupply of content. As a result, only a small percentage of games releases are truly successful. The finances of publishers and developers are often strained through the lifetime of a development. Cancellation of projects is not uncommon. The consequence is that eventualities which are remote or theoretical in standard software development contracts cannot be ignored when drafting or negotiating games contracts.
This article will explain how these issues should be addressed. Firstly we will look at the various players in the industry, and explain their role and status. Then, the major differences between games contracts and standard software agreements will be explained. Finally, the ten key clauses in a games contract will be analysed, with hints on how to approach negotiations, and basic mistakes to avoid.
Who’s Who in the Games Industry?
Like any industry, the roles played by its major players are constantly evolving. Platform manufacturers are developing and publishing games, publishers have in-house developers, and developers want to take advantage of new distribution media to get higher up the food chain. The following description still holds good though in most cases.
Platform manufacturers
Dominated by Sony and Nintendo, with Microsoft gaining ground from a standing start. As well as manufacturing the hardware, these companies grant licences to developers to enable them to produce games for their respective platforms. Platform manufacturers retain a right of approval of any game to be released, and charge publishers a licence fee for each game manufactured for their platform.
Publishers
They generally do not write the games, but names such as EA, Eidos, Activision and Rockstar are those mostly closely associated with games in the minds of the public. Publishers take the risk in relation to the project, bankrolling the production of the game and retaining the largest share of the profits.
Developers
These are the companies which produce the games. Typically they are small design houses, but there are some larger players. Developing a game will often take a major portion of a developer’s resources for a year or more. Developers contain the programming, artistic, animation and musical talent needed to produce a modern game.
Licensors
Often the central theme or major characters of a game will come from a film or book, or a game may be endorsed by a current sports star. A licence is needed to use these rights in a game. Typically this licence will be obtained by the publisher and made available to the developer. Particularly as its reputation grows, a developer may seek to obtain licences directly, to enable it to pitch games ideas to publishers.
Standard Software Development – Games Development
What are the differences between a games contract and a standard software development contract? There are several, but the following are the most important:
Success of development not judged solely by reference to specification
In a standard software development, the project will be a success if the software complies with the agreed specification, operates robustly and is delivered on time. Not so for game developments. The acceptance process focuses instead on the commercial suitability of the game as judged by the publisher, which, as well as being essentially subjective, often cannot be assessed until very close to the end of the project.
Requirement for third-party approval
Not only is it more difficult to secure approval from a publisher than a standard software procurer, but a further hurdle exists in games development. A publisher will retain the right to reject a game if the platform manufacturer refuses to accept it as suitable for the platform, or if the licensor disapproves of the way its rights are used. While outline approval will be sought at the beginning of a project, this will not guarantee acceptance at the end. Final approval is given only when the game is complete, and so the development can remain on risk until very late in the project.
Risk and reward based payment mechanism
In a standard software development, the developer is paid for reaching milestones. While this is the starting point in games development contracts, these milestone payments are treated as an advance on royalties. Both parties hope that the level of sales will be enough for royalties to exceed the advance. Otherwise, the game will not be judged a commercial success.
Typically, a developer will get a handful of chances to produce a commercial success. After this, it will find it much more difficult to secure a deal where it is paid an advance which fully covers costs. Conversely, a major success will shift the balance of power back to the hands of the developer, and it will find itself able to secure more lucrative royalty payments.
Likelihood of cancellation/ abandonment much greater
A games publisher has no interest in continuing to fund a development of a game which it does not think will succeed. In a standard software development, the software is often accepted (albeit reluctantly) even if it fails to meet all the expectations of the commissioning party, because it fulfills a business process need. No such considerations apply to games development. If the market for a game disappears, the development will be cancelled. Even if not cancelled, the publisher is generally under no obligation to market the game to any level or indeed at all. The developer cannot guarantee royalties other than by producing a game that the publisher wants to market and people want to buy.
Ten Key Clauses and How to Approach Them
With that background in mind, here are the clauses worth most attention.
1. Specification
The first step in a games development contract is agreeing the specification. This may seem curious when, as we have seen, compliance will not necessarily ensure ‘success’ (in both the sense of leading to final acceptance and in the sense of producing a commercially profitable game). However, if a developer can deliver to the specification, it will not be in breach of contract, and therefore not all the development fees will be at risk. By the same token, a publisher needs to have a document which it can refer to, so that it is not obliged to make milestone payments on developments which are going badly wrong.
The drafting of the specification will typically be done by the clients. The lawyer’s role is to ensure that what has to be achieved at each stage is clear. Industry terminology can be useful shorthand, but it should not be assumed without checking that everyone has the same understanding of what it means.
2. Acceptance
It is unwise to approve a contract which does not contain a process for acceptance of the game at each stage of its development. In its most basic form, the publisher should be given a period of time to satisfy itself that the deliverables comply with the specification. The consequences of success and failure should also be set out. The consequences of success are reasonably straightforward – the milestone payment should be made and the next phase of the development commenced. The consequences of failure are however harder to agree.
As a point of principle, the publisher should not suffer because of the developer’s failure to deliver to specification. Often though, a publisher will try to insist on fairly onerous remedies for late or incomplete delivery, such as holding the developer in material breach for any delay. On the other hand, a developer will want some leeway to make up for lost time, and ideally for time limits to run from the acceptance of the last milestone.
The publisher’s role in acceptance is often overlooked. The developer needs the publisher to carry out any acceptance tests promptly. It may also need materials, software tools, or artistic materials from the publisher to allow it to complete the game. It is important that the contract is not silent on this point. Any delay should extend the period for performance for the developer. The cost of staff who cannot immediately be redeployed and other costs should also be recoverable, although this tends to be strongly resisted by publishers.
3. Milestone Payments and Royalties
Payments to the developer take two forms – payments on acceptance of milestones, and a share in the revenue of the game. Milestone payments are treated as an advance on royalties, and so additional royalties will be payable only if the level of the advance is exceeded. It is important to ensure, if acting for the developer, that the advance is non-returnable if the royalties do not exceed the advance.
Because final approval rests with the platform manufacturer and/or the licensor, and can be refused even if the developer has met the specification, it is not reasonable to have all or the major part of payment linked to this final milestone. No more than 10-20% should be at risk at this stage.
As regards royalties, the method for arriving at the amount should be clear. If a percentage of publisher’s net income is used, it is vitally important that the method for calculating net income, (including the permitted deductions) is agreed in advance.
It is also important to agree which income will be included in the royalty base. Today, the vast majority of games are sold on a physical medium in return for an up-front payment. This is set to change in the future. It is possible that entire games will be provided online, as a service rather than as a product, and in such a case identifying the revenue stream applicable to the game itself might not be straightforward. Since contracts are typically signed 18-24 months before the game is released, it is prudent to ‘future-proof’ the payment mechanism.
4. Payments on early termination
A development contract can come to an end prematurely for a variety of reasons. The most obvious is where one party terminates for material breach, but a contract can also end if the platform manufacturer or licensor refuses to accept the game. Most publishers also want to retain the right to terminate the development part way through if, in their opinion, the game will not be a success.
Where the developer is in breach, it is reasonable for the publisher to seek to recover its losses. That does not mean however that the developer should forfeit all payments. For if a publisher can terminate on the developer’s breach, recover all the milestone payments, and give the work to another developer to finish at lower cost, then the publisher will have gained from the breach and the developer will have been penalised. The guiding principle is that if the work done by the developer can be used then it should be paid for, albeit with the possibly of deduction applied or no royalties payable, as a method of acknowledging the developer’s failure.
If the publisher wishes to cancel a game part way through, it should be obliged to pay for all work done and committed to be done. There is also an argument for the developer to be able to receive some payment in addition by way of compensation for non-redeployed staff.
5. Transfer of IPR
A publisher will want unrestricted rights in a game. This generally means ownership of all IPR generated by the developer. On this point a developer will find it difficult to make much headway. However, it is important for a developer to ensure that it is not transferring its ‘background’ IPR at the same time.
A sensible compromise is to identify at the outset any routines, programs, or techniques which are to remain the property of the developer, along with the underlying games concept if this was produced by the developer. This will be licensed to the publisher on a non-exclusive basis for the game in question. Everything else will be assigned to the publisher.
Whatever the position with IPR, the developer should request that all rights which it transfers to the publisher revert to it where the publisher does not exploit them within a given amount of time.
6. Timing of IPR transfers
If acting for the developer, try to provide that the IPR assignment takes place only once all milestone payments have been made. This is a useful incentive for payment. In addition, if the publisher becomes insolvent and sums are outstanding, the developer will not simply have to rank for payment as an ordinary creditor. Instead, it can reuse the work or (more realistically) deal directly as owner of the rights with the platform manufacturer or licensor.
7. Sequels and Conversions
A conversion involves taking a game designed for one platform, and rewriting it for another. How much work this involves depends both on the nature of the game and the platforms in question, but a conversion would typically take several months but not more than a year. A sequel on the other hand is an entirely new game, but it retains the central characters and/or theme from the original.
The developer wants the option to produce both, and the publisher will generally give this if it is satisfied that the developer has the necessary capability. However, this will be in the form of an ‘agreement to agree’, and so it is perfectly possible for the publisher to choose a third party to produce the conversion or sequel. What is the position in such case?
A conversion or sequel will generally re-use code produced by the developer. For this reason, the developer should seek to agree a royalty in the original contract if its code is used by a third party. If acting for a publisher, you should seek to ensure that this additional royalty is payable only where it is the developer’s background IPR which is reused, as opposed to any of the IPR generated in the development.
8. Warranties and Indemnities
A publisher will look for warranties as to freedom from errors, and as to ownership of IPR which is used in the development. As to the first, the typical warranty given is for the game to be free from material errors for one year from delivery. Bear in mind that remedying a breach of this warranty generally cannot be done simply by issuing patches or updates, and so a limit of liability clause (if acting for the developer) should be considered.
As regards IPR, a publisher will rightly want comfort as to ownership of the rights used. Given the mobility of staff in the industry, it is wise, if acting for the developer, to ensure that your client is confident as to the source of the IPR brought to the project by each member of the party.
9. Non-Solicitation of Employees
A development team walking out halfway through a development would be a serious problem. The publisher should not be able to encourage this as a simple way of forcing breach of contract. Ensure that there is adequate protection for the developer.
10. Restrictions on Developer
It is likely that a publisher will derive most of its profit from just a few of the games it releases. Naturally, it will want to protect its investment in the successful games. It does not want a developer free to produce a similar game either at the same time or shortly afterwards. Therefore, a publisher generally seeks to restrict the developer from developing a game with a similar theme for a period of six months or longer after release of the game.
This is an area for negotiation, and there are no hard and fast rules. However, if a developer does agree such a restriction, it should ensure that it is tightly defined. A restriction which refers simply to a particular theme, such as a driving game, is too broad to be acceptable. Using that case as an example, the restriction could be tightened by reference to type of racing (F1, road car, fantasy vehicles), perspective (first person or overhead), or associated themes (eg crime solving, crime participation).
Bear in mind also that the actual release date of the game is not within the control of the developer, and so this form of restriction could last for longer than anticipated. It is good practice therefore to agree a long-stop date.
Conclusion
The basis for this article was that games development contracts need to be approached differently from normal software development contracts. The superficial similarities hide a number of important differences. What is and what is not a standard clause, what can and cannot reasonably be negotiated on, and how matters not obvious from the face of the contract affect how one should advise on otherwise everyday clauses are all issues which are unique to this industry. Only with an appreciation of why this is so, how these issues should be dealt with, and what can go wrong can you give the best possible advice to your client.
John McKinlay is an Associate with McGrigor Donald. The author wishes to express his thanks to Peter Baillie of VIS Entertainment plc for commenting on a draft of this article. © McGrigor Donald 2002.
