Contract Killers: What developers should eliminate from their publishing agreement (part 1)

This year saw the release of the latest instalment in IO Interactive’s long running stealth series, Hitman, featuring the return of everybody’s favourite barcoded assassin. However, in this series we are less concerned with the exploits of Agent 47, and instead focus our attention on those parts of a publishing contract that might kill your game or your business.

Developers have every right to negotiate their publishing contract

Publishers are not actively trying to get developers to sign a bad deal, but their publishing terms will invariably favour their business over that of the developer. That’s because publishers are games businesses too. Like you, they are looking to make a profit and their contract is intended to protect their business in the event that things between you go wrong.

If a publisher has given you a contract they want your game…

…so approach your contract negotiation with confidence. As a developer you have every right to negotiate your publishing contract. That includes revising both commercial and legal terms if they don’t suit your business. That doesn’t mean you can expect a publisher to sign your game on completely different terms, but the end result of any negotiation should be a compromise that both sides are happy with.

In this series of posts I will be suggesting how developers can snuff out any red flags that could cause issues as you develop and launch your game.

CONTRACT KILLER 1: Bad Payment Terms (Front End)

Getting Paid

The primary reason for most developers wanting publisher support is access to funding. That is cash during development to help you finish and launch your game (Front End Payments), and then revenue payments generated by game sales (Back End Payments).

Front End Payments made during development usually come in the form of development fees (also called development advances, minimum guarantees, etc.). Back End Payments are usually in the form of revenue share – and we will look at Back End payment terms in more detail in Part 2.

Front End Payment Terms

Front End Payments – those being development fees tied to a developer completing and delivering agreed milestones – are almost always tied to the publisher providing their approval in respect of each milestone.

Milestones can be structured in a number of ways, but a common example is for these deliverables to be monthly. This requires the developer to deliver builds to the publisher each month for the publisher to approve. Once the publisher has provided such approval the developer can invoice for the applicable development fee payment. This process repeats until the gold master or release version of the game is approved by the publisher for launch. 

Development fees are normally tied to your delivery (and publisher’s approval) of certain milestones

As you may have noticed from the above example - the developer only receives front end payments where the publisher has given its approval. That is not an issue where a publisher is engaged in providing you with feedback on your build, but what happens where the publisher goes silent?

The consequences of this are grossly unfair. A perfectly good build could be sat on the publisher’s shelf – but you don't get paid because they haven’t approved it, and then you get penalised for not hitting your next milestone. This puts you in breach of the publishing contract and allows the publisher to walk away without penalty or, in some cases, with your game.

 Timing is everything.

To avoid delays that aren’t your fault you can put time limits on the publisher to perform certain tasks - in particular their obligations relating to the evaluation and approval of builds and milestone deliverables. This is normal practice, and publishers are generally amenable to having a reasonable amount of time to review each milestone (say, 10 working days).

Computer says “yes”

To avoid the mentioned situation above it also common practice for a developer to ask for any build to be automatically approved for payment purposes where a publisher has not explicitly provide its approval or rejection of a certain build within this agreed time limit.

This allows you to submit your invoice (and get paid) for that delivered milestone, but also gives the publisher flexibility to ask for you to make fixes in the event that they do not approve of the build.

Quick Fixes

Thanks for reading. Part 2 of Contract Killers looks at bad payment terms that could affect you on the back end. Out soon!