Summary
Legal and business basics covers the non-design questions that nonetheless shape whether a project survives: who owns what, who gets credited, what obligations a contract creates, how revenue splits work, and how public promises create delivery responsibilities. These questions are commonly deferred until they become urgent — at which point they are far more expensive to resolve.
This page is intentionally educational rather than prescriptive. As the IGDA makes explicit in its own contract resource: this is orientation, not legal advice. A team facing real contract, IP, or tax decisions needs qualified legal and accounting counsel, not a wiki page (IGDA, Contract Walk-through: Effects on Quality of Life, see source-igda-qa-and-contracts).
IP ownership and work-for-hire
Who owns what by default
Intellectual property (IP) — the game’s code, art, audio, design documents, and brand — must be owned by someone. Who that is depends on jurisdiction, employment status, and the presence or absence of a written agreement.
The key distinction in most jurisdictions is between:
| Situation | Default ownership |
|---|---|
| Employee creates work within the scope of employment | Employer owns the IP (work-for-hire doctrine) |
| Contractor creates work under a written work-for-hire agreement | Client owns the IP (if the agreement is valid for that jurisdiction) |
| Contractor creates work with no written agreement | Contractor retains copyright in most jurisdictions |
| Co-founders create work together with no agreement | Joint ownership — either party can potentially exploit the work independently |
| Volunteer contributor creates work for a project | Contributor retains copyright unless assigned in writing |
The practical implication for student and indie teams: if no written agreement exists, everyone who contributed substantial creative or technical work may have a legal ownership interest in the result. This matters when the project becomes commercial, when a member leaves, or when a publisher wants to acquire the IP.
Resolve this before work begins. Retrospective IP assignment is possible but requires all contributors to agree; a single holdout can create an unresolvable problem.
Work-for-hire in practice
Paid contractors, freelancers, and composers brought in during development should ideally sign a brief written agreement that addresses:
- Scope of work — what exactly is being created
- Ownership assignment — who will own the resulting work
- Usage rights — if full ownership transfer is not used, what rights the project has (exclusive/non-exclusive, territory, duration)
- Payment terms — amount, milestones, and when payment occurs
- Credit — how the contributor will be credited on release
Sweet (Writing Interactive Music for Video Games) notes that composers routinely negotiate usage rights, rights-for-hire versus licensing, and synchronisation licences. The principles apply equally to audio, art, and writing from external contributors (Sweet, Writing Interactive Music for Video Games, see source-writing-interactive-music).
Contracts and what they cover
The quality-of-life dimension
IGDA’s contract walk-through frames development agreements not only as financial documents but as documents that determine how a team lives during development. Milestone obligations, approval rights, credit provisions, and termination clauses all affect day-to-day working conditions (IGDA, Contract Walk-through: Effects on Quality of Life, see source-igda-qa-and-contracts).
What a development or publishing deal typically contains
A publisher or investor deal with a development studio typically covers some or all of the following:
| Clause | What it determines |
|---|---|
| Milestones | Defined deliverables tied to payment tranches — missing a milestone delays or cancels payment |
| Advance | Upfront funding from the publisher, to be recouped from future royalties before profit-share begins |
| Recoupment | The publisher recoups its advance (and sometimes marketing and distribution costs) from the developer’s share before the developer earns a royalty |
| Royalty rate | The developer’s share of revenue after recoupment — commonly 15–30% for a developer in a traditional publisher deal |
| Approval rights | Publisher right to approve milestones, creative direction changes, or marketing materials |
| IP ownership | Whether the developer or publisher owns the franchise; this determines who controls sequels, ports, and licensing |
| Termination rights | Conditions under which either party can end the deal and what happens to IP, code, and advance obligations |
| Credit obligations | How the developer and publisher are credited in the final product and in marketing |
Recoupment means profit arrives late
The mechanics of recoupment mean that a developer may generate substantial revenue for a publisher while receiving no royalties for months or years, because the advance has not yet been recovered. The cash flow implications are significant: see game-industry-realities for a worked cash flow collapse scenario.
Payment terms compound the problem. Publisher royalties are commonly paid 60–120 days in arrears. A studio may be generating strong revenue in January and be unable to make payroll in May because the January revenue has not yet arrived (Hiwiller, Players Making Decisions, Ch. 33, see source-players-making-decisions).
Credits as production practice
IGDA crediting guidelines
The IGDA Game Crediting Guidelines (v10.1, 2023) treat credits as a professional and ethical obligation rather than a courtesy. Their recommendations:
- Formalise credit records from the start of production. Reconstructing contribution history after launch is unreliable; people leave, memories diverge, and disputes arise.
- Notify contributors of their credit before the game ships, so errors can be corrected before the record becomes public.
- Audit credits before the final build. The launch version of the credits is the canonical record. Corrections made in a post-launch patch are better than none, but they are not guaranteed to be seen by the same audience.
- Include all meaningful contributors, including contractors, freelancers, and temporary contributors. The IGDA defines thresholds for inclusion; the practical guidance is to err toward inclusion.
(IGDA, Game Crediting Guidelines, see source-igda-qa-and-contracts)
Why credits matter professionally
Credits are a primary professional credential for many game developers, particularly those in roles where portfolio work is difficult to demonstrate directly (QA, production management, audio implementation). A missing or incorrect credit can affect a person’s employment opportunities for years after a project ships. Treating credit disputes as unimportant is both ethically poor practice and a source of team conflict.
Revenue and revenue share
Platform cuts
Before any revenue reaches the developer, platform holders take their share. Standard cuts:
| Platform | Standard cut |
|---|---|
| Apple App Store | 30% (15% for small developers earning under 1M USD/year) |
| Google Play Store | 30% (15% for first 1M USD per year) |
| Steam | 30% (scaling to 25% at 10M USD, 20% at 50M USD) |
| PlayStation / Xbox / Nintendo eShop | 30% |
| itch.io | Variable; creator-determined revenue share |
These are non-negotiable for most developers and must be factored into any P&L before projecting developer revenue.
Revenue share between team members
For teams self-publishing without a publisher, revenue share agreements define how income is split among contributors. Common patterns:
- Equal share — appropriate for teams of equals who contributed similar amounts
- Weighted by role contribution — founder/lead designers take more; part-time contributors take less; often formalised as percentage points agreed at project start
- Salary plus back-end — salaried employees take a fixed income during development; profit share applies only to revenue above a threshold
Whatever the pattern, the split should be agreed in writing, before production begins. Verbal agreements are difficult to enforce and cause the most common form of indie team conflict: a successful game generates money, the team’s memory of who was promised what diverges, and the relationship breaks down.
Crowdfunding obligations
Public promises become delivery obligations
Kickstarter and similar platforms create a legal and reputational obligation when a campaign is funded. A successfully funded campaign is not free money — it is money paid in advance for a product that backers expect to receive.
Kickstarter’s official creator guidance makes this explicit: the budgeting and timeline work required before a campaign launch exists precisely because scope, shipping, and fulfilment obligations are set by the campaign page, not the team’s later preferences (Kickstarter Creator Guidance, see source-kickstarter-creator-guides).
Key implications:
- Stretch goals are promises. Features added to a campaign page as stretch goals are delivery commitments. Teams that list stretch goals they cannot deliver create legal exposure and severe reputational damage.
- Scope changes require communication. If production realities require cutting a promised feature, backers should be notified proactively — not at launch.
- Fulfilment timelines must account for real schedules. Kickstarter guidance explicitly mentions “wiggle room” in timelines — a recognition that teams routinely underestimate how long post-funding development takes.
- Funds must cover what was promised. Budgeting that only accounts for development, not manufacturing (for physical rewards), shipping, VAT/customs, and platform fees has caused significant crowdfunding failures.
Launch readiness
Kickstarter’s pre-launch guidance recommends building an audience and organising communication plans before the campaign goes live — not as a marketing convenience but because campaign momentum in the first 48 hours is disproportionately important to final outcome. The guidance recommends identifying at least ten potential backers who can follow the pre-launch page before the campaign is public (Kickstarter Creator Guidance, see source-kickstarter-creator-guides).
In practice
For a small team, the minimum useful questions to resolve at project start:
- Who owns the IP? Is this a joint venture? Does everyone have the same share? Is there a lead owner?
- Are any contributors contractors rather than co-founders? If yes, are there written agreements covering ownership and usage rights?
- How will contributors be credited? Start the credit list now, not at ship.
- Is any revenue-share arrangement documented? Even a simple email trail is better than nothing.
- What are the deliverable commitments? If crowdfunding or publishing deals are involved, what has been promised and to whom?
- What are the payment terms in any deal? Advance size, recoupment structure, royalty rate, and payment timing all affect cash flow.
- When is a lawyer or accountant needed? For any deal involving significant money, third-party IP, or formal corporate structure, seek qualified counsel.
For student teams making a non-commercial university project: questions 1–3 still apply. If the project later becomes commercial, agreements made (or not made) during development will matter retroactively.
Evidence
IGDA explicitly states that its contract walk-through is for education, not legal advice — which is exactly the appropriate framing for introductory teaching on this topic (IGDA, Contract Walk-through: Effects on Quality of Life, see source-igda-qa-and-contracts).
The IGDA crediting guidelines (v10.1, 2023) recommend formal processes for notifying contributors and auditing credits before launch, with corrections added in the next post-launch update if issues are discovered after ship (IGDA, Game Crediting Guidelines, see source-igda-qa-and-contracts).
Kickstarter’s creator materials demonstrate how quickly pre-launch decisions become fixed obligations once a campaign goes live — the importance of pre-campaign planning is a structural feature of the platform, not optional advice (Kickstarter Creator Guidance, see source-kickstarter-creator-guides).
Hiwiller’s P&L and cash flow analysis shows how publisher payment terms (60-day delays, recoupment before royalties) create cash flow exposure that is distinct from and more immediate than profitability concerns (Hiwiller, Players Making Decisions, Ch. 33, see source-players-making-decisions).
Implications
- IP ownership and revenue share are most expensive to dispute after a project succeeds. Resolve them before production, not after.
- Platform cuts and payment delays mean that a financially healthy game on paper may create a cash crisis in practice. Know the numbers before signing.
- Credits should be maintained as a live production record, not assembled from memory in the final week of development.
- Crowdfunding and publishing choices convert internal scope decisions into external obligations. Every feature promised publicly is a commitment.
- “We will sort it out later” is the start of most preventable team conflicts over commercial games.
Open questions
- What is the minimum legal/business literacy a games student should leave university with? The IGDA’s educational framing is a useful model, but the content has to be grounded enough to be actionable.
- Which template agreements (co-founder agreements, contractor IP assignment forms, revenue share memoranda) can be discussed pedagogically without implying they are safe substitutes for proper counsel?
- How should student teams handle informal collaborations that later become commercial? The most common scenario — a university project picked up by a small publisher — has no standard protocol.
- As work-for-hire AI-generated content becomes more common in production, what ownership implications arise? Current copyright doctrine in most jurisdictions does not protect purely AI-generated work; this creates uncertainty for projects using AI asset pipelines.
Related
game-industry-realities | publishing-and-funding | team-dynamics-and-roles | qa-and-bug-triage | game-design-documentation | post-launch-and-live-ops | overview-full-game-development-pipeline | source-igda-qa-and-contracts | source-kickstarter-creator-guides | source-writing-interactive-music | source-players-making-decisions