What is revenue sharing in game development?

The basic idea

In a salaried studio, the studio carries the risk: it pays people whether or not the game sells, and keeps the upside if it does. In a revenue-share team, the contributors carry the risk with the studio — they work now, get paid only if the game earns, and in exchange take a share of that income rather than a wage.

Each person's share is usually based on how much they contributed. An artist who produced most of the game's visual content has a larger claim than someone who did one week of bug fixing, and a fair model reflects that.

That's the whole concept. Everything difficult about revenue sharing is in the details: measuring contribution, handling people joining and leaving, and writing down the agreement before anyone has a reason to dispute it.

How the split is usually calculated

The common approach is a contribution-weighted split. Work is tracked as it's completed, each piece carries a weight reflecting effort and difficulty, and the totals determine each person's percentage of the revenue pool.

The alternative — fixed percentages agreed at the start — is simpler but ages badly. It assumes you can predict, on day one, how much each person will actually contribute over two years. Teams usually can't, and the person who over-delivers ends up resentful.

A middle path is common in practice: a pool split by tracked contribution, with the percentages reviewed at agreed checkpoints so nobody is locked into a stale assumption. See royalty points for how contribution becomes a number.

The ways it goes wrong

Nobody wrote it down. The single most common failure. The team agrees verbally, the game earns, and five people have five recollections.

Contribution was never tracked. Without a record, the split is negotiated from memory, and memory favours the confident over the diligent.

Someone left and nothing was agreed. Departures are guaranteed on a multi-year project. If the agreement doesn't say what happens to a departing contributor's share, you're deciding it during a conflict.

Fixed percentages set on day one. Reality diverges from the plan, and a percentage that made sense at kickoff can look absurd two years later.

Rev-share confused with equity. They're different things with different legal and tax consequences — see the comparison page before you promise either.

Common questions

Is revenue sharing legal?

Revenue-sharing arrangements are ordinary commercial agreements in most jurisdictions, but the specifics — how income is taxed, whether contributors count as employees or contractors, what happens on dissolution — vary by country and by how the arrangement is structured. This page is general information, not legal advice; get a professional to look at anything you plan to sign.

What percentage should each person get?

There's no standard answer, because it depends on what each person contributes and what else they're being given. Contribution-weighted models avoid the question by deriving shares from tracked work rather than negotiating them up front.

Does revenue share mean giving away ownership of the game?

Not necessarily. A revenue share is a claim on income; ownership of the IP is a separate question that your agreement should address explicitly. Many teams share revenue while ownership stays with one entity.

When do people actually get paid?

When the project distributes revenue, which is usually after platform cuts and any agreed expenses. The agreement should state what comes off the top before the split, because that's a frequent source of surprise.

Can someone be on both a salary and a revenue share?

Yes, and it's common for a partly-funded studio. It needs to be explicit, since someone drawing a wage and a full contributor share is a structure the rest of the team will reasonably want to understand.