Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Previously we looked at how certain clauses might affect when and how a developer gets paid by its publisher. This post looks at potential timing issues that might affect a developer's ability to carry out its obligations under the publishing contract.
What I talk about when I talk about running (a tenuous analogy for the developer-publisher relationship)
While the game development process may be made up of a series of sprints, developing a game is most definitely a marathon. If you will excuse the use of a tenuous analogy of a timed running race - the developer is the runner running the race working their way to the finish line. The publisher is the race marshal making sure that the runner doesn’t cut corners, and helping keep the runner on the right track. When all goes well the runner completes all sections of the race with support from the race marshal who may also provide guidance (production support and feedback), drinks (marketing) and snacks (QA) along the way.
But what happens where the race marshal blocks the runner’s path, or impedes the runner’s ability to get to the finish line or complete a section of the race in time? In such case the race marshal is clearly at fault and the runner shouldn’t be blamed for not finishing the race within a set time.
What if the race marshal disqualifies the runner for not completing a section of the race in a certain time? In such case it will depend on whether the circumstances for the runner not meeting the time requirements were caused by the runner or the marshal (or a combination of the two).
Developer shouldn’t be liable for publisher delays
Analogies aside – I hope the point is clear that a developer should not be penalised for failures or delays in meeting its obligations under a publishing contract if such failures or delays were caused by the publisher. This should also extend to any third parties that the publisher requires the developer to work with - such as outsourcers or porting houses. A publishing contract is there to protect the publisher more than anything, but that doesn’t mean a developer should be penalised for issues or delays that the publisher causes. If your contract doesn't include provisions to protect you against publisher delays then it is reasonable for you to add them in.
Time heals all wounds (and late delivery of milestones)
The above analogy also notes that the publisher is not always at fault for the developer being late in delivering a build. In a publishing contract the obligation of development and delivery of game builds on time ultimately falls on the developer. Many publishers will offer production support to help mitigate any delays, but development times and processes can overrun. It happens, and publishers know it happens.
Missing a milestone would be considered a "material breach" of most publishing agreements. Material breaches usually come with a "cure period" during which the party at fault can put right any wrongs. Developers should check the contact to see if it includes a "cure period" for any late milestone delivery – this will usually be found in a contracts “Termination” section.
A cure period doesn’t give a developer a free pass to continually deliver builds late – and doing so is a sure-fire way to burn bridges with your publisher – but it is reasonable for a developer to have time to fix any errors or to rectify late delivery of a build. However, you shouldn’t have to crunch to get a build in on time. If slippage occurs (or looks likely to occur) then communicate this to your publisher. Publishers are game businesses too and they (should) understand the reality of the development process, but communication between developer and publisher around milestone delivery dates is important for maintaining good working relationships.
For both front-end and back-end payments, Timing is everything
As with Front End Payments (see Part 1), the publisher will usually set out their time scales for paying backend payments to the developer. As such you need to be aware of what these are and change them if you think this may cause cashflow issues.
In particular developers should check the following relating to the timing of backend-payments:
Royalty Statements: It is reasonable for the publisher to provide you with a statement in each payment period showing a breakdown of game sales across platform and territory (as well as other information you might reasonably ask for). Ask for the details to be provided if it isn’t in the contract already. Some publisher have example royalty statements that they will provide for your information prior to you signing the contract.
Statement then Payment: Getting a royalty statement is all well and good, but check if the publisher provides you with a statement first before it makes payment. This can increase the time period for you to receive back-end payments. Again, check the time period in the contract by which the publisher has to provide you with a royalty statement – and then check how long it takes for them to pay you after receiving each statement.
Payment Terms: check how often the publisher accounts any back-end payments to you, and calculate how long it will be for you to actually receive the cash into your bank. For example, if a publisher’s payment terms for back-end payments are 45 days from the end of the month then you could be waiting 75 days to get paid if the publisher had received that money on the 1st of the month.
Front End Payments – after a milestone is approved how long does it take the publisher to pay you the applicable development fees? For example, if front end payments are paid by the publisher 30 days after approval then you will be waiting for a month to receive a payment after you have completed the relevant milestone – and you might need that cash now to progress with the next milestone/build.
Thanks for reading. Part 4 of Contract Killers will be out soon.
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
