top of page
  • Brad

Indie Dev Contract Conundrums

FOREWORD: This blog post is about the custom contracts I made for the One Lonely Outpost team, unlike any indie project contract I've seen before. This might not be so interesting to most people, but I hope it can help some other indie team out there figure out a better solution to how they organize their rights contracts.

Indie projects need a contract. Without one, the game can be slain by any member working on the project at the drop of a hat. And no matter how good of friends you are, no one can know how things will turn out on something as stressful, work intensive, and personal as an indie game project.

THE QUEST: A lot of the contract is simple; NDA, contract jurisdiction, and other legal boilerplate. However, when I set out to handle the revenue shares, I had heard lots of horror stories and solutions that either ended in the game's complete failure or were grossly unfair to some of the team members (usually artists). Those that worked only did because the developers all had the same skill level, or were long-time friends who just trusted eachother. OLO consisted originally of only a couple friends, but I knew we would end up with a much larger team comprised mostly of people with diverse skill levels and whom we've never met previously. This meant that I would have to find a robust solution.

I reached out to a lot of people and read a lot of articles, and the solutions for how to handle revenue share all seemed to be way too risky for the project, or way too dangerous for the contributing artists and developers. How do you measure how much an artist has contributed? How do you ensure team members are putting in the hours they say they are? Are the hours of a 20 year industry veteran the same as a college student? How does commissioned work fit into this? What happens if the programmers drag their feet and the artists had put out a ton of work only to be left in limbo? How to handle artists and programmers joining and leaving the team over the game's development? And many more.

The existing solutions felt insufficient. However, I had noticed a striking similarity between programming and legal contracts, and having a strong background in programming, I decided to write my own contract. After weeks of deliberation and making drafts, I came up with an idea that just might work: it would be a bounty system of sorts. A minimum total percentage of the revenue gets allocated to each part of the game; Art, Programming, Audio. Then, point amounts are assigned to each contribution completed and approved. So, one member might contribute work totalling 300 points, and another 100 points. In that case, the first member would get 3/4th of the total share for the kind of work completed. This way, the number of members can change, and they will all be rewareded according to their work.

After points are assigned and the contributing member accepts (or does not object to) the point allotment, The rights are transfered to the founders of the project (known as the 'project controllers') so that no joining member can grind the project to a halt. To ensure that the contributing members make a return and the 'project controllers' can't just slack off, if significant revenue isn't generated within 3 years, all the rights return to the respective members so that they can go find someone else to finish the game if they want.

Further, there's several protections baked in for the contributing members. First, their shares count towards all standalone works using the artwork. This includes toys, sequels, and so on, but not DLC. The logic behind this is that in order to buy DLC, the player has to own the base game. Therefore the contributors have already gotten their share. This does mean that it's unlikely the game will get a sequel with the same art or code unless the contributors are willing to negotiate a smaller share, but it is pretty fair all told.

Another aspect that this tackles is money contributions. If someone pays for work, they get bounty points in lieu of the person who made it - after all, they got their reward already (payment).

Concerning the Art Contract

The question arose then - how is artwork scored? Hours? Quantity? Quality? Art is subjective by nature, and so there ultimately is no way to codify scoring into a contract for a perfectly fair mechanical system. Someone would have to score it. In the end I settled on having a subjective scoring by the project lead, but backed by a reference table for scoring points, which provides a range for each kind of art. This way artwork that doesn't meet standards of quality need not be given points, but in order for us to use any art, it must be given points first. Below is the scoring table, and the first applicable method is used (note that 'PPT' is 'Points per Thousand Pixels', and measures all fully opaque pixels in an asset):

  1. Pixelization render of non-pixelated artwork (plants, natural objects, structures, character portraits, and furniture): Allotted 4-10 PPT, Minimum 20 points. May also apply to significant but not complete reworks of existing pixel art of any kind.

  2. Pixelization render of non-pixelated artwork (character/animal sprites and man-made machines): Allotted 8-20 PPT, Minimum 30 points.

  3. Pixel Art Character Sprites Idle/Pose: Allotted 40 points for each sprite.

  4. Pixel Art Character Sprites Animations: Allotted 2-10 for each idle sprite animations, 10 to 20 points for each walking or action animation.

  5. Pixel Art Animal Sprites Idle: Allotted 30 points for each sprite.

  6. Pixel Art Animal Sprites Animations and Poses: Allotted 15 points for each sprite.

  7. Pixel Art Crop Sprites: Allotted 15-25 points for each sprite.

  8. Pixel Art Portraits: Allotted 200 points for the first portrait per character, 90 points for all others.

  9. Pixel Art Tileset: Allotted 100-200 points for each complete tileset and 70 for each variant tileset.

  10. Pixel Art Furniture (not specific to or part of a Structure): Allotted 15-25 points for each sprite.

  11. Pixel Art Individual Terrain Rocks & features: Allotted 5-15 PPT, Minimum 15 points.

  12. Pixel Art Item Icons: Allotted 20 points for each sprite.

  13. Pixel Art Animation: Pixel art assets which is part of an animation shall be allotted 2-10 PPT, Minimum 5 points.

  14. Pixel Art: Pixel Art Assets which are used apart from an animation shall be allotted 4-30 PPT, Minimum 15 points.

  15. Colored Concept Art & Promotional Artwork: Allotted 20 to 400 points for each image. Extremely complex and detailed artwork may be allotted up to 800, but this should only be done in exceptional cases, such as a landscape with many detailed buildings and several characters.

  16. Uncolored Concept Art: Allotted from 20 to 150 points for each image.

  17. UI & Iconography Unpolished Mockups & concepts: Allotted 10-40 points each accepted mockup or concept.

  18. Other Unpolished Concept Art Sketches: Sketches which mark significant progress in the design process but are not accepted as finished works shall be allotted 20-30 points for each image.

I definitely think the amounts can be improved, but overall, it's worked out pretty well so far. The biggest drawback of this method is that someone has to go over all the artwork made and score it & distribute it for review every month (soon to be every quarter), which takes more time than I'd like. None the less, the fairness of the system is worth it to me.

Concerning the Technical Contract

Moving on to the technical work contract (programming, Unity work, etc), the needs were different. A categorization table doesn't work for programming tasks, nor does arbitrary point assignments without some kind of check. So, for technical work, I decided on a bidding system. Each week, the project lead or lead programmer assigns an openning bid value to all tasks, and suggests them for team members. If someone doesn't want to do a task, or is willing to pick up a task someone else has for fewer points, they can do so using a bidding system.

There is also the option to penalize a member who bids on tasks and does not finish them within two weeks. This exists to prevent a member from grabbing all the tasks when they don't have the time or ability to finish them. The penalty has never been applied so far in the year that we have used this contract.

In practice it's been a little unweildy, so I'll be changing the wording in the contract to make it less rigid, allowing for arbitrary assignment of tasks with a unanimous active programmer vote each week. Mostly, the bidding option is there to act as a 'sword of dameclese' - the mere option of going through a bidding war helps keep the point amounts and task assignments fair.

Nothing is Perfect

There's lots of details, protections, provisions, and so forth in both of the full contracts that further ensure that no one member can throw a wrench into the project, but no one is cheated either. There's certainly still some room for abuse, but I've done my best to mitigate it. As David put it, "At some point, you just have to trust people to not be jerks."

Let me know what you think, and if you have any feedback via Discord, Twitter, or anywhere else! And if this helped you and your indie team!

DISCLAIMER: I have no legal experience, and wrote this contract without formally consulting a lawyer. This is not a safe thing to do, but I was willing to accept that to have what I consider a significantly more fair contract. I will link the current draft of both art and technical team contracts below for anyone to view, comment on, and (COMPLETELY AT YOUR OWN PERIL) use. I claim no rights to it, nor responsability for consequences of it being used by anyone besides myself.

Full Technical Contract (docx):

Full Art Contract (docx):

500 views0 comments

Recent Posts

See All

If I told you that NES and SNES games Metroid and Mario were inspirations for how I’m making One Lonely Outpost, that’d seem strange, right? But they none the less are. It’s not the exact mechanics th

It's been a while, but we're back with something cool to share! The following is a short story for one of the NPC Colonists who join you over the course of One Lonely Outpost. There will ultimately be

When we started OLO with just David (lead programmer), Joe R. (first lead artist), and myself (supporting programmer and everything else at the time), it was a one-and-done idea; meant to take about n

bottom of page