Building an independent game development team or think-tank for the first time is typically an organic and exciting process. Although going with the flow and letting things happen can be wonderful for the creativity and enthusiasm of your team, it doesn’t hurt to think ahead and plan for your success or failure. Riding the euphoric tide of a brilliant idea may leave you and your team stranded on a desert island! Once the Honeymoon period is over and your idea begins to take shape as a viable project or set of projects, it’s time to think about more than your design documentation.
This means paying attention to your business and legal relationships and developing some adaptable goals that fit your motives. Don’t misunderstand—developing is your priority, and will always be your priority. It’s frustrating when you’re forced to take time away from development to concentrate on things you simply do not want to think about, like failure. However, anything you invest in, especially when you involve other people, will create risks and possible rewards. Those risks and rewards deserve due consideration and diligence on your part. They will inevitably demand the creation of a business and legal strategy. Thinking about these things early on can save you a serious headache in the future.
I’ve already discussed collaboration agreements. That’s the starting line—the bare minimum you need to get up and running. This article will cover business and legal decision-making from the ground up: who makes the decisions for your project? What’s the purpose of what may now only be a loose cooperative of likeminded individuals? What will you accomplish and how will you evolve? And just as importantly, what business and legal issues should you consider based on your answers?
Your Team: Who’s In Charge Here, Anyway?
You may start with one or two people building on a simple game concept. You might start with a larger group of like-minded individuals focused on idea-sharing and education. You could live in different countries, or you could meet in your community every few weeks through LinkedIn, Facebook, or Meetup. You might be classmates working on a project with other students, professionals, and hobbyists. Your team’s goals and their success or failure will vary as much as the composition of the teams themselves.
The most challenging question you must ask before you can even begin the decision-making process is “how do we make decisions?” The more collaborative and organic the team’s origin, the more uncomfortable teams become when discussing leadership. Sometimes leadership occurs naturally—you’ll have a charismatic voice, an “idea (wo)man”, or someone who has championed and spear-headed the project from the word “Go”. On the other hand, a team may be truly collaborative. Everyone will want to have a say in how things operate. In the case of the “key man” situation, there’s a lack of checks and balances. In the latter democratic scenario no one can act as a final arbiter in the event of a serious dispute. Looking at some examples may help illustrate these problems.
Illustration One: Mary is a recent graduate from a top notch game development program. She wants to bolster her design portfolio for the sake of her job hunt. To do this, she wants to build a team to develop a game concept she’s passionately yearned to create since her youth. The game charts the journey of Squea, an alien taking the form of a sweet, pink nosed, golden eyed white kitten. Squea seeks out the energy created through joy, which she then converts to charge her spaceship. “Joy points” are earned by finding and cheering up lonely and scared young boys and girls throughout the galaxy. Mary attracts a motley team of developers, including an odd artist cousin or two, but it’s clear to everyone that she is the driving force behind the operation.
As the game nears completion Mary’s cousin, Emily, suggests they register the game with the Copyright Office. Mary doesn’t consider this a priority and forgets along the way. Additionally, she fails to include copyright notices on the game’s assets. Because Mary has full responsibility over all aspects of the project, no one else takes it upon themselves to override her. After submitting the game to several game competitions and receiving multiple awards, Mary’s team starts selling the game through digital PC channels. A year later, Emily finds an identical copy of the game ported for free to the Android Marketplace. Furious, she contacts Mary, who subsequently contacts an attorney. The attorney informs the team that although they still own the copyright in the game, their claim for damages may be substantially reduced due to a failure to register the game and a failure to include proper notice of ownership to potential infringers. Emily holds Mary responsible for the sudden dearth of legal remedies and a massive falling out ensues. Family affairs are now tense, and Mary (without consulting the rest of the team) pulls her game from the PC marketplaces. The rest of the team sues Mary, claiming ownership and equal rights to exploit the work.
The fact that Mary was the sole person responsible for all aspects of her game, including its legal protections, worked to the team’s detriment. Most political tyrannies fail; it’s no surprise that business tyrannies meet even less success with the existence of competitors and pirates. Having a checks and balances system in place where multiple team members take mutual responsibility for ensuring the game’s critical and commercial success is an important step to securing your team’s future. However, having too many cooks in the kitchen can lead to its own problems.
Illustration Two: Bill and Carly started a game developer group on Meetyou.com, a popular local event creation site. Every month, the group meets to discuss programming and design concepts, pitch ideas, and collaborate on a variety of projects. After two years the listed members for the group number over a hundred; some are more active than others, but there are roughly 30 or 40 people who are continually involved in projects developed by the group. IP ownership is never discussed and everyone assumes they own their own contributions. Additionally, several of the members are students or employees. Several of these are improperly using third party licenses in connection with their own contributions. Bill and Carly have taken a “hands-off” approach to this; their motivation is to facilitate idea creation, collaboration, and education, and they don’t want to force rules and restrictions on the group.
However, one project becomes a break-out success and sells hundreds of thousands of digital downloads through various mobile marketplaces. Five group members who actively participated in the project’s development can’t seem to agree on who owns what. Several more group members who participated in meetings where the idea was first pitched also claim a “stake” in the game. The fight becomes heated as the game earns more and more. Finally, the group members go to the group founders seeking guidance. Unfortunately, neither Bill nor Carly developed a contingency plan for this possibility. As dissension spreads the group begins to fall apart. Bill and Carly become disheartened and stop scheduling meetings. Eventually the group is disbanded; meanwhile, at least one suit has been filed against the other group members involved in the dispute.
Bill and Carly wanted to engender a wholesome, developer-friendly environment; unfortunately, a total lack of leadership or guidance in any collective that produces a commercial project poses a legal danger to the collective and its individuals. Several alternatives to the laissez-fair approach taken by Bill and Carly include creating a voting membership of core members, creating a set of guidelines for project management, or formalizing as a non-profit or LLC that assists developers in organizing their own projects. These alternatives may permit Bill and Carly to remain in the background while still engendering the type of environment they hope to create.
Your Goals: What Are We Doing?
Both scenarios described above include specific reasons behind the decision to do (or lack thereof). Goals are important. A goal to “make something”, even if you don’t know what, is still a goal. Your goal is the soil in which you will plant the seeds of your ideas—the richer and more substantial your goals are, the greater the likelihood of a good harvest. A goal becomes substantial when it goes beyond “what” and “how” you develop and includes “what happens after we’ve finished?” However, it’s also important that your goals be flexible. This is especially true in the beginning. Finally, it is important that the key players within your team understand the end game and want to accomplish the same or similar goals. Many of your decisions and the way you make those decisions will flow from your underlying purpose.
Let’s re-examine the scenarios mentioned above. In Mary’s case, registering the game’s copyright may not have seemed important because she wasn’t thinking of commercial success. She wanted to bolster her portfolio and she wanted to see her brilliant idea come to life. Without discussing this goal with her teammates, she created a high likelihood that her teammates would participate in the project for entirely different reasons. Certain decisions, such as the decision to formalize, determine IP ownership, and establish profit distribution seem unnecessary when the project is a hobby portfolio builder. These decisions are mandatory when you want to create a commercially successful game.
Similarly, the decision to not focus on commercial projects is just as important to your decision-making process. Bill and Carly only hoped to bring people together and create a community of likeminded friends and developers. Collectives, Start-up Weekends, and Co-Ops are popping up everywhere for iOS, XBLA, and Android/Google game development. The original organizers themselves may seek only to bring people together; they may not have an active interest in making a profit off of the games produced by the collective. In those cases, you have an entire bevy of options both simple and complex: formalizing as a non-profit with a robust IP management and asset distribution assistance program; organizing as a for-profit business entity that also helps distribute the games produced and taking a commission; may provide both financial stability and legal protection for the collective.
Documentation and Assets
When you formalize the design and technical elements of your game, you put that in a document. Your game documentation is the roadmap for your game, and project leadership relies on this roadmap to complete the game. Your team’s collaboration agreement, operating agreement, bylaws, articles of incorporation, or organizing documents all serve the same purpose—they provide a roadmap, and also spell out how those assets should be distributed and managed. Many, many conflicts are the result of a misunderstanding because something wasn’t “spelled out” in an agreement, or because the parties didn’t anticipate certain possibilities such as failure, dissension, and the investment they may be forced to make to finish the project. Sometimes nothing was written down in the first place. While this may not result in the failure of a project, it may certainly result in the collapse of your team.
Once you’ve decided to put things in writing, and as with design documentation, you may need to reevaluate what you originally wrote down. If you have something in writing and check it frequently when things change, you are taking an important step to keeping the peace. Your agreements let you know how decisions should be made and what decisions are already determined. This goes a long way to clearing up future disputes and the legal costs associated with those disputes.
Finally, knowing the assets that you are creating /contributing and putting a value to those assets is imperative. This is especially true in Bill and Carly’s illustration, where teams are constantly changing and the underlying group is constantly expanding. Determining ownership, distribution, and control of the various intellectual properties (including copyrightable content, trademarks, trade secrets, proprietary and prior works) embodied in a project can be a massive undertaking late in the project’s development. However, an adaptable approach can be taken at the outset to avoid the kinds of problems Bill and Carly experienced. For example, a simplified project documentation form that lists team members, their roles, and their initial ownership interest is a good starting point. Elaborating on that with provisions that spell out what happens in the event of a teammate’s withdrawal, removal, or replacement also goes a long way to avoiding future conflict.
Conclusion
Even if you don’t expect your team to live past the first project, it’s always important to consider the road ahead. “Let’s make a game!” involves a lot of technical and creative elements, but “Let’s make a game people can play!” also involves decisions that have little to do with the creative and programming processes of your game and more to do with your team’s goals and underlying business. Finding time to make those decisions early and often will go a long way toward preparing you for all of the thousands of possibilities and inevitabilities that await your team.
