Not a darn thing. Look, in a beginner indie game team, the ideas are considerably less important than the mousepads. Teams live or die on their ability to execute their concepts, not the strength of the concepts themselves.

Look, lemme put it this way. I have a really killer game idea. I'll even tell it to you, if you want. Now, do you want to steal my game idea and turn it into a reality, or would you rather make your own game idea into a reality?

Do you think anybody else is different?

Quote:Original post by Sneftel
Teams live or die on their ability to execute their concepts, not the strength of the concepts themselves.

Bingo.

You could go down the whole route of non-disclosure agreements or no-competition clauses in contracts, but it's a big mess to deal with, especially with indie games. Even if you had a signed NDA and someone ran off with your idea, you'd have to spend the money to pursue your case legally.

Quote:Original post by trapdoor
Thank you, this is exactly what I wanted to hear. that such extensive protection hurts the company more than protect it. That and why would anyone want to steal my little idea.

Let's see some perspective.


I work closely with about 50 different developers. We work on three AAA titles.

We have frequent discussions about game play ideas. Some of us have had front page articles into Gamasutra, and many other publications. Many of us have independant projects both as pet projects and also as multiple shipping indie games. If we could all turn all of our ideas into reality, we would have several hundred titles, not just three.

So notice the ratio there.

50 professional developers -> 3 AAA games per year that are all "someone else's idea".
50 professional developers -> many thousands of good ideas per year.


Knowing that, I'd like to know why any game developer would bother stealing an unimplemented idea.

It would be wise to get contracts and NDA agreements. I've done so, even though the people on the team are my friends. Better to hash out who gets how much of what, and who is investing in it prior to starting any work. I know Tom Buscaglia has a kit for a few hundred USD, which is a steal. There's also nolo books, or you could go to a library and check out the reference section, if you're pressed for money.

However, nothing beats having an actual paid lawyer draw up contracts to your specific conditions.

Of course the level of ownership management you need to do depends on how indy you are? If you actually think your game is going to be sold for money, then you need to get ownership issues nailed down. That said however, if you aren't paying a salary you can pretty much kiss any ownership ideas out the window ...

What I worked out for my indie projects is a system where every developer retains full rights to any code they developed, and the group itself retains full rights as well, code which is developed by more than 1 person is equally possesed by everyone with more than 25% of the development credit (on a LOC basis, because that's the only objective measure possible).

The group uses simple majority vote to make executive decisions, and 2/3 vote to add / remove members (but members still retain rights to their code as above). The group of course can grant any rights it wants to anyone it wants, by majority vote ... but it cannot remove rights from anyone, ever, for any reason.

Also, a minimum of 20% of all money recieved for a project (gross) be shared will all significant contributors (work on > 5% of total project) in a formula to be approved no less than once-per-year, and adjusted no more than once-per-quarter ... the formula determines things like relative value of code, design, testing, art, sound, polish, ... any amount recieved is allocated by simply group approval, as long as 20% minimum sharing is observed (group cannot even vote to forfeit their share, but they can individually reinvestor donate if they so choose).

So if someone comes in, writes 10% of final code, leaves in a big argument, they still get a share of profits, period. And in all future output in which their code portion is still greater than 5% of total project.

The point of these rules of mine is NOT to enforce them, or sue about them, or anything else. The point is to properly set expectations of all parties to prevent conflict and wastefull attempts to exert too much control over the eventual use of code, just because of involvement or perceived value (that usually never materializes). I think we also have a clause that shares less than $50 / quarter or $100 / year are not considered significant and may be retained by the group if the member has left the team.

all of the above are still a work in progress (I have yet to use exactly the same system on any 2 projects, because I'm trying to improve and yet simplify it) - but the point is to foster shared ownership on teams which do not involve enourmous capitol outlays (salaries, offices, etc) but might involve wildly different contribution levels.