Dabe Alan

Starting an indie studio? This is your crash course on video game law

Starting an indie studio? This is your crash course on video game law

Ben here! I heard about New Media Rights through a story on Joystiq, and reached out to Intellectual Property Attorney Shaun Spalding about writing a brief primer on some best practices for indie studios. As more and more developers self-publish, indies are asked to be experts on not just game development, but things like marketing and law, and those are tricky subjects for anyone to simply jump into. If you found any of Spaulding’s advice useful or interesting, consider making a donation to allow New Media Rights to provide free legal guidance to smaller developers. This stuff can save your company, or your game. Enjoy!

Indie game development is supposed to be fun, right? That’s why people work on projects for hundreds of hours knowing only ten people (who aren’t members of the team) are going to buy or play them.

Learning about the law and business isn’t fun. I know that because I went to law school. So… my job for the next two pages is to teach you in five easy steps what you need to know about this un-fun stuff so you can avoid legal threats and continue to do what you were really born to do: make games.

My non-profit, New Media Rights, helps game developers whose projects go off-the-rails because of legal issues. Penny Arcade Report thought it would be good to talk about a few of the major ones, so you can prevent issues before they happen. I’ve tried to avoid complicated law-talk when possible and concentrate on best practices.

And if you don’t like to read, I’ve also included links to some of the videos we’ve made called LAGD that explain these concepts in six minute chunks. Game developers are visual and auditory learners (that’s why you’re not novelists), so I know reading lots of complex text is probably the last thing you want to do.

As a disclaimer, keep in mind that this is a simplification of complicated rules, and these generalizations only apply in full to people in the United States.

Make sure everyone is on the same page

Most legal problems indie developers face are from who worked on their projects rather than from external sources giving them trouble. That’s why the most important “legal” tip for indie devs make is actually the least legally complicated thing to work out.

Everyone who works on your project needs to understand the scope and nature of the project up front.  Someone may have told you, “It’s good to have a contract before you start working together,” but never told you how you actually do that. This should get you started.

Ideally, you could work out the details of the project in a written, formal contract. You could hire a lawyer to do it, or you could find a template and then customize it to fit your own needs. Understand that not all templates are created the same.

If all of that is too formal for your project, that a contract could be in an email thread. After all of the details are finalized in the thread, at the end, you should get everyone to confirm they understand and agree. Email threads can often be just as enforceable as formal, more-lawyerly-worded contracts in certain situations.

If even that doesn’t work for some reason, these details could be discussed in an informal meeting, then you could send a written summary to everyone at the end that they acknowledge and confirm. Any way you work it out, just ensure that everyone is always in the loop about “important details.”

So now that you know how these details can get worked out, here are the three most important of those important details that need to be worked out:

A. Who owns the creative output of each individual working on the project?

Does your company own it or does each individual own their own creative input? Generally, the best thing for the company (if you’re a project manager) would be for the company to own it. Generally, the best thing for an individual would be that they own it themselves. Your job is to figure out what the mid-ground is and then get everyone to agree to it.

B. Who gets paid, how much, and when?

You need to work out who, if anyone, will get paid, and what source of money will that payment come from. Questions include:

Will everyone get a percentage, and if so, how much? When will that payment start? After the game starts selling (revenue), or after the game breaks even after costs (profit)? Will everyone get the same percentage, or will you divvy it based on how many hours everyone puts in? What happens if another person enters the project unexpectedly, will everyone’s percentages change? Is anyone being paid out of pocket by some other team member? If so, will that team member who fronted the money be reimbursed first? Does the amount of money everyone gets change if the game randomly becomes a hit and makes $500,000? Is the percentage that you get counted before, or after the cost of distribution (for example, iTunes and Steam’s percentages)? Blah, blah, blah, etc.

These seem like complicated questions, but they’re actually not. You can really make these arrangements as complicated or non-complicated as you think the project needs. Assuming that you all work well together, these things will probably change on-the-fly several times during the development process as people drop out and join on anyway. As with all of these tips, use your best judgement.

C. Who controls business decisions and creative decisions?

Someone has to be the person chosen to make decisions. Think about it this way, when two partners with equal votes don’t agree about a direction for the project, there’s always a deadlock. When there are three people with equal votes, there is always one person who gets their feelings hurt when he/she loses. To avoid hurt feelings, figure out ahead of time who can make what decisions and stick to it.

Keep in mind, the “final decision maker” doesn’t always have to be the same person in control for all decisions. For example, one person can have the last word on creative choices. Another person can have the last word on money choices. Be flexible. Be realistic.

So once you get all those “important details” locked in, keep in mind that each person should know about them to the extent that those decisions affect that person. If someone new joins on, you should bring that person up to speed in the same thorough way to confirm their agreement to your terms. Just because it may take a little extra time, or just because this person will only be working with you for a week, doesn’t mean that you should cut corners.

Also, if anything substantial changes between your first agreement and what is happening, it’s a good idea to update everyone and get confirmation that the new path you’re on is the new proper path.

So now you know how to do it and what to work out, let’s talk about why this is important.

It’s a fact: people who like each other don’t sue (or threaten to sue) each other. Partners who are happy don’t cause problems. People who are surprised by sudden, unexpected shifts in how the project they’re working on is being run, or how they are being paid, or how they’re credited, will inevitably cause problems. Having a personal blow-up about a project you’ve been working on for weeks and months is the best way to lose a friend.

At worse, you’ve made an enemy for life who can limit your ability to distribute, make money off of, and do public relations for your game. At best, you’ve lost one person who will play your game and wasted your time.

New Media Rights made a 15 minute episode of LAGD that talks about confidentiality, one of the details you could discuss up front. Another episode talks about independent contractors versus employees which may help you to work out how you pay people. If we get to do a season two of our video series, we’ll hopefully have more episodes to all of what we’ve explained above.

NEXT PAGE

  1. 1
  2. 2
  3. View All

2 Pages