Production 101 - #8 Legal Documents Every Game Producer Should Know
The contracts you didn’t sign are still your problem
Game producers are rarely the ones who sign contracts, but they live inside them every day
Understanding fixed-price versus time-and-materials agreements changes how you track scope and manage risk
Work-for-hire, publishing, licensing, outsourcing, and software agreements each carry specific obligations that land on the producer
Early involvement in negotiations prevents the most expensive execution problems
This is part of the Production 101 series, a practical introduction to game production for people new to the craft.
I’m not a lawyer. I don’t play one on TV either, though I once worked alongside enough of them to pick up the basics. Nothing in this post is legal advice. Laws vary by region, business practices vary by studio, and if you are dealing with a contract dispute, you need a qualified solicitor or barrister, not a blog post. What I can give you is a working producer’s map of the agreements you will encounter, so you know what you are looking at when someone hands you a document and asks you to make sure the team delivers against it.
Producers rarely sign development contracts. Senior business stakeholders, executives, or legal teams handle that. But once ink is dry, the producer is the person who has to make the project actually do what the contract says. You track milestones. You flag when scope is drifting. You explain to the development team why a particular deliverable has specific acceptance criteria attached to it. If you don’t understand the agreements shaping your project, you are managing blind.
Why contract literacy matters for producers
The gap between what a contract says and what a team thinks they agreed to build is where most production problems start. I have seen developers assume a milestone meant “feature complete” when the contract defined it as “playable build approved by QA.” I have seen publishers request changes that were clearly out of scope, and producers who didn’t know the original scope well enough to push back. Both situations are avoidable.
Understanding contracts doesn’t mean you need to interpret legal language independently. It means you need to know what questions to ask, what details to verify, and when to escalate to someone with authority to act on those details. The practical skills are: knowing which document governs your project, knowing the milestone and payment structure inside that document, and knowing how change requests are handled.
Producers help bridge the gap between creative ambitions and commercial obligations. That bridging only works if the producer actually knows what the obligations are.
If you don’t have access to the full contract, ask for a redacted version that covers scope, milestones, IP ownership, and termination terms. Executives sometimes hesitate to share commercial agreements because of sensitivity around pricing or deal terms. That’s fair. But you can be specific about what you need and why. “I need to understand the milestone acceptance criteria so I can manage the team’s deliverables against them” is a reasonable request that most stakeholders will grant.
One more thing before we get to the agreements themselves. Contract language is dense and often archaic because it is built on legal precedent that predates the games industry by several centuries. When I started working with contracts, I had no good way to decode the terminology quickly. These days you can use a large language model to explain contract clauses in plain English. I would not recommend uploading sensitive corporate documents to a public platform, but for general terminology questions, it is genuinely useful.
Fixed-price versus time-and-materials: the foundational choice
Most game development agreements follow one of two payment structures, and which structure your project uses shapes almost everything about how you manage it.
A fixed-price agreement means the developer commits to delivering a defined scope of work for a set fee. The client knows the total cost from the start. The risk sits primarily with the developer, because if the work takes longer or costs more than anticipated, the developer absorbs that difference. This makes a clearly defined scope critical. Any changes requested by the client after signing require a formal change request, which usually means additional cost and a revised schedule. As a producer on a fixed-price project, scope control is your most important job. Every feature request, every “small tweak,” every “can we just add...” needs to go through the change request process, or you are letting your margin bleed away.
A time-and-materials agreement is different. The client pays for the actual hours worked and resources consumed. Scope can shift as development progresses, which suits projects where requirements are uncertain or where creative decisions are being made during production. The trade-off is cost uncertainty. Without tight oversight, a T&M project can run significantly over the original budget estimate. The producer’s job on a T&M engagement is to give the client regular, transparent visibility into progress, hours, and cost, so there are no surprises.
Fixed-price works best when the scope is well defined and stable. T&M works best when it isn’t. In my experience, most game projects are more suited to T&M than the people signing the contracts want to admit.
The agreements you will actually encounter
Work-for-hire development agreements
A work-for-hire agreement is the most common contract structure in third-party game development. A client, typically a publisher or IP holder, hires a developer to build a game according to specific requirements. The defining feature of work-for-hire is IP ownership: all creative work produced under the agreement belongs to the client from the moment of creation. Design, code, art, audio, everything transfers automatically.
This matters for producers because it shapes what the team can and can’t do with their own work. The developer may retain the right to include the project in their portfolio or to use certain tools or technologies developed during the project, but only if those rights are explicitly written into the contract. If they’re not, they don’t exist.
Work-for-hire agreements contain several components that the producer works against daily.
The scope of work defines what the developer is hired to build: the platform, the genre, the key features, and the tools or technologies required. It also defines the milestones, which is where your project management lives. Common milestones include concept approval, pre-alpha, alpha, beta, and gold master. Each milestone is typically tied to a payment. The developer receives a portion of the total fee when that phase is approved by the client. Your milestone schedule is effectively your cashflow plan.
The testing and acceptance section defines what “done” means. This is where I have seen the most friction between developers and clients. “Gold master” sounds self-explanatory, but contracts often define acceptance criteria that go beyond “the game runs without crashing.” Know what’s in this section before your team thinks they’ve shipped.
Work-for-hire agreements often include a key-person clause, sometimes called a key-man clause. I don’t like the phrase “key-man” and have started using “key-person” in my own vocabulary, but you will see both in contracts. The clause names specific individuals whose involvement is considered essential to the project. If one of those people leaves the project, the contract may give the client the right to approve their replacement or, in extreme cases, to pause the project. If you are the producer named in a key-person clause, you need to understand what that means for your own availability.
The Game Design Document, or GDD, is often a schedule attached to the main agreement. It is a living document, updated throughout development, and signed-off GDD versions frequently correspond to milestone approval points. Amendments to the main agreement are how scope changes get formalised. Any change to deliverables, timelines, or payment terms that is agreed after the contract is signed should be captured as a written amendment. Verbal agreements don’t hold up.
Publishing agreements
Publishing agreements define the commercial relationship between a developer and a publisher. They cover how revenue from game sales is divided, what marketing and promotional commitments the publisher makes, what milestones and deliverables the developer must hit to receive payments, and who owns the IP when the project is complete.
The revenue share structure is the number everyone in the room knows and argues about. The producer’s job is less about negotiating that number and more about understanding what events trigger payments and what the developer needs to deliver to receive them. A milestone payment held up because a build didn’t meet acceptance criteria is a cashflow problem. Know the criteria before the build submission.
IP rights in publishing agreements vary considerably. Some publishers require a full IP transfer as a condition of funding. Others licence the IP while the developer retains ownership. The producer needs to know which scenario applies to their project, because it affects how the team documents and protects their own creative contributions.
Licensing agreements
An IP licensing agreement lets one party, the licensor, grant another party, the licensee, the right to use specific intellectual property: characters, music, brand names, visual assets. In games this comes up most often when you are building a game around an existing IP, such as a film licence, a sports league, or a branded character.
The scope-of-use section is where problems lurk. It specifies how, where, and on which platforms the IP can be used. Exclusive versus non-exclusive rights. Geographic restrictions. Industry-specific limits. If the scope-of-use is ambiguous, you will spend time and goodwill in dispute later. The licensor’s quality control requirements are also worth understanding early. Licensed IP owners often have approval rights over how their IP is represented, which adds review steps to your production schedule that you need to account for.
Royalty structures in licensing agreements can be complex. Fixed fees, percentage royalties, minimum guarantees, audit rights. You don’t need to understand every mechanism, but you need to understand the payment schedule and what delivery events trigger or terminate licence rights.
Outsourcing agreements
When a developer brings in a subcontractor for specific work, an outsourcing agreement governs that relationship. The producer often works most directly with outsourced partners, so these contracts are worth understanding in some detail.
The scope-of-work section defines exactly what the subcontractor is responsible for delivering: which assets, which features, by when, and to what technical specification. Without a precise scope, subcontractors and developers develop different ideas about what “complete” means. The IP ownership clause matters here too. All work produced under an outsourcing agreement should specify that ownership transfers to the hiring developer on delivery. Without that clause, a subcontractor could technically claim ownership over assets they created.
Confidentiality clauses protect the project from information leaks. Subcontractors often work across multiple clients, and your game design, technical specifications, and business plans should not be travelling to other studios. Make sure NDAs are in place before sharing sensitive materials.
Master agreements and statements of work
When a developer and client have an ongoing commercial relationship across multiple projects, they often use a master agreement to set the overarching terms, then individual Statements of Work, known as SOWs, to define the specifics of each project. The master agreement covers IP ownership, general payment terms, confidentiality, and dispute resolution. The SOW covers scope, milestones, deliverables, and project-specific payment terms.
The advantage for producers is that once a master agreement exists, new projects start faster. The commercial framework is already agreed. You go straight to scoping the work rather than negotiating the baseline terms from scratch.
Service level agreements
An SLA defines the performance commitments between a service provider and a client. In game development, SLAs appear most often in live service contexts, governing things like server uptime, bug fix response times, and customer support response rates. They specify how performance is measured, what happens if the provider fails to meet the agreed level, and who is responsible for what.
If your project has an SLA attached to it, know what the metrics are and how they are tracked. SLA breaches can trigger financial penalties or contract termination.
Software licensing agreements
Producers don’t always think of software licences as contracts, but they are. The game engine licence, SDK agreements with platform holders, the fonts used in the UI, the stock audio in the build: all of these are licensed, and all of those licences have terms.
Engine licences are the most significant. Unity and Unreal Engine both have pricing models tied to revenue thresholds and usage terms that change periodically. Platform holder development agreements, covering PlayStation, Xbox, and Nintendo hardware and certification requirements, are non-negotiable but require compliance. Software development kit licences for analytics, monetisation, or social features can have their own revenue share terms buried in the small print. The producer’s role here is less about negotiating these agreements and more about making sure the team is using software in accordance with its licence, tracking costs, and flagging when a licence needs renewal or upgrade.
Common challenges
Getting access to the agreements
Executives sometimes won’t share the full contract because it contains commercially sensitive pricing or deal terms. The practical response is to ask for what you specifically need. A redacted version covering scope, milestones, IP ownership, and termination terms is usually enough to manage the project. Be specific about what you need and why, and most stakeholders will accommodate you.
Decoding the language
Legal documents are dense because they are built on centuries of precedent. Terms that seem straightforward often have specific legal meanings that differ from ordinary usage. Use a large language model as a general-purpose decoder. I would not upload sensitive corporate documents to a public AI platform, but asking “what does ‘time is of the essence’ mean in a contract context” is exactly the kind of question these tools handle well. I wish I’d had that option earlier in my career.
Being brought in after commitments are made
This is one of the most frustrating situations a producer can find themselves in. The contract is signed. The scope is committed. The timeline is set. And you are handed the project to execute against commitments nobody consulted you on. The commitments may be optimistic, unclear, or internally inconsistent.
The earlier a producer gets involved in the negotiation process, the more expensive problems they can prevent. This is one of the strongest arguments for involving production leadership before contracts are finalised, not after.
If you are brought in after the fact, the first thing to do is read the contract carefully and map the agreed scope against reality. Identify the gaps. Escalate the ones that are genuinely undeliverable. You can’t always fix a bad contract, but you can make sure the right people know what they are dealing with before it becomes a crisis.
Misalignment between teams
Contracts often require input from legal, finance, operations, and sales, all of whom have different priorities. Finance wants cost certainty. Legal wants clean IP. Sales wants flexibility on scope to close the deal. These interests are not always compatible, and the resulting contract can reflect compromises that create execution problems. The producer’s job is to spot where those compromises create practical delivery risks, and flag them early.
Unrealistic expectations
Some agreements are built on assumptions that were optimistic at the time and are actively wrong by the time the project starts. If scope is underestimated, timelines are compressed, or dependencies are overlooked, you need to surface that clearly and early. The solution is rarely to just try harder. It is to get the relevant parties to agree on a realistic baseline, and document that revised baseline formally.
Production 101 is a series for people new to game production. The series index, with links to all instalments, is at
.