游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

法律人士对独立游戏开发团队运营的几点建议

发布时间:2011-02-23 18:40:18 Tags:,,,

首次成立独立游戏开发团队或智囊团着实令人激动。追随大潮将此举付诸行动有益于提升团队的创造力和工作热情,但是也应该深思熟虑,为即将面对的成功或失败早做打算。

盲目跟从这个振奋人心的想法可能使整个团队宛如置身荒岛,进退两难!激动过后,无论想法转变成某个切实可行的项目或是一系列项目,应该考虑的就不仅仅是设计资料的问题了。此刻,团队必须关注商业运营和法律关系,制定出某些符合发展方向的目标。当然,发展永远高于一切。

被迫从发展中挤出时间来关注某些人们根本不愿意去想的事情(比如失败),这总让人产生挫败感。但是,任何投资都存在风险和利益,何况项目还牵扯到其他人。考虑这些可能存在的利益和风险是组织者的义务,而且不可避免地要为此制定相应的运营和法律策略。早些思索这些问题可避免将来团队内部发生大麻烦。

游戏邦编译的这篇文章分析了运营和法律决策的相关事宜,包括:谁是项目的决策者?与志同道合者保持宽松合作关系的目的是什么?需要达成的目标以及如何发展才能实现?另外,需要考虑哪些运营和法律事务?

game-studio-story

game-studio-story

团队:谁才是真正的负责人?

也许刚开始时,萌生游戏想法的人只有一两个。随后,组织者可能会召集大批有类似想法的人,相互交流各自的观点。或许这些人正处在不同的地区,经常通过LinkedIn、Facebook或Meetup来与团队成员会面交流。参与者也有可能是同学,与其他学生、专业人士和兴趣爱好者努力完成项目。成员不同,团队的目标和结果的成功或失败也各不相同。

在决策前,必须思考最具挑战性的问题——“我们要如何做出决定?”团队越有活力,成员间的合作性越强,讨论起领导权问题时,就越让人觉得别扭。某些团队可能有个别具有超凡魅力的成员,或者有人在该项目上一马当先,那么领导人自然而然就产生了。

但从另一方面来讲,团队成员间必须有合作。对于项目如何运转,可能每个人都有自己的看法。如果只依靠领军人物,那么此人做出的决定可能难以得到检验和平衡。但是如果在征求意见的过程中发生激烈争论,却无人最终做出裁决,也会面临很多问题。看看以下这些例子就会明白这两点。

例1:玛丽刚从某个顶级游戏开发项目上获得成功。她想要保住自己设计部领导人的职位,这对自己将来找工作有所帮助。为达成这个目标,她希望成立团队开发一款构思已久的游戏,实现其年轻时的想法。

游戏讲述的是Squea的旅程,这个外星人脸上带着甜蜜的微笑,有粉红色的鼻子和金色的眼睛,还带着一只白色的小猫。Squea找寻欢乐并将其转变为能量用于为她的宇宙飞船充能,在星系中独自追寻快乐的踪迹可以赚取“欢乐点数”。玛丽组建起复杂的开发团队,其中包括一两个美术设计师,不过所有人都清楚她才是项目背后的主导力量。

游戏开发接近尾声时,玛丽的同事艾米丽建议在著作权机构注册这款游戏的版权。玛丽认为这并非当务之急,于是就把这件事抛在脑后。而且,她还忽略了游戏资产的版权标识。由于玛丽全权掌控了项目的所有事宜,其他人都不认为自己有义务提出建议。这款游戏开始在市场上与其他竞争者角逐,在获得多项大奖后,玛丽的团队决定通过数码PC渠道销售此游戏。1年之后,艾米丽发现Android应用商店正免费出售与之完全相同的游戏。盛怒之下,她马上联系玛丽,后者立即咨询了律师。

律师告知开发团队,虽然他们仍享有这款游戏的版权,但是由于游戏没有注册,所以无法向侵权嫌疑人出示相关所有权证明,因此他们提出的赔偿金额可能会有所减少。艾米丽认为之所以缺乏法律证据完全是玛丽的责任。整个团队的关系十分紧张,玛丽没有和团队其他人商量就让游戏退出PC市场。团队其他成员向玛丽提出控诉,要求维护自己享有的游戏所有权和其他平等的权利。

玛丽独自负责游戏的所有事务,包括法律保护等,正是这点损害了整个团队的利益。领导独断专权是许多公司失败的原因之一,因此有些游戏巨头被其他竞争者打败也就不足为奇。团队中存在校验和平衡系统,这样所有的成员都可以承担起各自的责任,确保游戏能在商业运营上取得成功,这是影响团队未来安危的关键因素。但是,如果参与决策的人太多,也会出现问题。

例2:比尔和卡莉在Meetyou.com上组建了一个游戏开发小组。这个小组每月都碰头商议项目和设计的观点以及如何在计划上展开合作。两年后,小组成员已突破百人。虽然有些人较为活跃,但小组开发的项目中通常都会牵扯到30至40个人。小组从未商讨过IP所有权的人选,因此每个人都觉得自己是所有人。而且,某些成员是学生或公司职员,有些人在发布作品时并没有取得合格的第三方许可证。比尔和卡莉对这个问题置若罔闻,他们的目标是启发成员萌生各种想法并促进成员间的合作和交流,并不想在小组内定下条条框框的规矩。

然而,当某个项目取得突破性进展,在各个手机平台创造数十万次的下载量后,问题产生了。小组中5位积极参与该项目研发的成员就所有权问题争论不休,还有许多小组成员参与商讨而且其提出的意见也曾被采纳,这些人认为游戏的成功也有他们的贡献。游戏收益越来越多,争论也越来越激烈。最终,这些成员寻求小组创建者的帮助。不幸的是,比尔和卡莉从未想过会发生这种意外。因成员间的纠纷不断加剧,整个开发小组分崩离析。比尔和卡莉觉得很气馁,也停止组织成员会谈。最后,整个小组解散,同时在引发争论的成员间已发生数起诉讼案件。

比尔和卡莉想要营造一个开发者们和谐相处的友善环境,但不幸的是,由于缺乏领导人和集体性指导意见,商业项目的成功反而给整个团队和成员带来法律危机。某些方式可有效替代比尔和卡莉采取的放任政策,如核心会员参与表决、制定一套项目管理的指导方针或成立非盈利性组织、有限责任公司来帮助开发人员管理自己的项目。这些方式不仅可以让比尔和卡莉在后台运作,也可以产生他们希望塑造的那种开放式氛围。

目标:我们在做什么?

上述例子探讨的是决策者问题,目标同样非常重要。即使还不知道具体要做什么,“做出点事情来”也算是个目标。“想法”只有在“目标”这片土地上才能生根发芽,土地越肥沃越有实质性,收成也就越好。

目标的实质性包括明确开发产物和过程,以及对问题“如果完成后,会发生什么?”的思考。第二,灵活变动目标同样很重要,这一点在项目开始时表现得尤为突出。第三,团队的关键成员能够理解并希望最终达成目标,这也是十分重要的。游戏邦觉得,做出决策的方式和结果会受潜在目标的影响。

重新回顾下上文的例子,玛丽或许并没有想过要在商业运作上取得成功,因此她觉得注册游戏版权并不重要。她想的只是将自己睿智的想法变成现实,为谋职添砖加瓦。但是,她并没有和团队成员商量过这个目标,因此这些人参与项目的原因很可能与她的目标并不一致。

游戏邦认为,如果做项目只是个人爱好或为求职谋利,那么实施诸如决定IP所有权、建立盈利分配制度等使团队完善的决策完全没有必要。但是,如果想要让开发的游戏在商业营销上取得成功,就必须实行这些措施。

同样,非商业项目的决策与决策的制定过程同等重要。比尔和卡莉只是希望将这些朋友和开发者聚集起来,建造出志同道合者的交流平台。到处都有为iOS、XBLA和Android/Google开发游戏的集体,这些组织人员可能只是想汇集开发者,并不打算利用整个集体开发的游戏来获利。

在这种情况下,就会出现各种不同的业务重点和选择:团队可以选择开发非盈利性但拥有健全IP管理方法和资产分配的项目;或是组织成立以盈利为目的的运营公司,成员开发和发布游戏后,领取委托金或酬劳;或者也可以选择融合各种组织形式,保证整个集体财政稳定并提供法律保护。

在执行计划前定位目标很有必要,只有所有成员理解并同意,才可以面向目标开展工作。下一步就是将动机和目标落实成书面文件。

文件和资产

决定游戏的设计和所采用的技术后,应该制成相关文件,这份文件就如同游戏开发的地图。项目领导人需要依靠这份地图完成游戏的开发,整个团队的合作协议、经营协议、附则、条例和组织相关文件都应指向同样的目标,这就是资产分配和管理的指导性文件。许多冲突都源于误解,因为事情没有在协议中说清楚。订立协议的人没有清楚说明IP的所有权归属问题以及取得成功后盈利将如何分配。游戏邦了解到,某些团队甚至从一开始就没有订立任何协议。虽然此举不会导致项目失败,但是很可能使整个团队解散。

写成书面文件是第一步,保证这些文件实时更新,使其可以跟上项目的发展和目标的变更同样重要。就像设计资料一样,必须重新评估最初写下的条款。

比如,假设玛丽的团队制定了项目合作协议,如果有成员退出或新成员加入时,团队就需要重新修正协议。如果团队制定相关书面文件且在事态发生改变时校正,那么就可以避免将来游戏取得成功时的经济纠纷。

第三,熟知正在创造或分配的资产并对其进行合理的估价同样很重要。决定项目中各种知识产权(包括版权、商标、商业机密、所有权和之前的工作)的归属、分配和控制问题在项目发展后期是一项艰巨的任务。

例如,比尔和卡莉的团队不断发生变化,其属下的成员逐渐增加。其实从刚开始就有方法可以避免比尔和卡莉遇到的问题,只需简单地制定出项目文件表,列上团队成员、职位和所有者的权益,权益可在项目进展过程中逐渐增加。以各种条款不断完善这份表格,就可以明确团队成员退出或更换时需要采取的措施,也同样可以避免将来可能引起的冲突。

最后,新决策制定后,需要记录会谈的时间。如果决策诞生后产生纠纷,但是协议还未正式修订添加本决策,那么此举有助于提供确凿的证据。协议可以让整个团队明白如何做出决策以及之前决策的内容,这对未来清算争端以及争端引起的诉讼费有益。

结论

即使只希望团队完成一个项目,也需要认真考虑下未来可能面临的问题。“让我们来开发一款游戏吧!”,这个口号包含的可能只是技术和创造性思维的问题。但是“让我们来开发一款大家都爱玩的游戏吧!”还包含着与创造性思维和游戏项目进展关系不大的决策问题,而这些决策恰恰与团队的目标和业务运营有着很深的关联。尽早花点时间考虑这些问题,才能为团队可能遇到的成千上万种冲突做好准备。(本文为游戏邦/gamerboom.com编译,转载请注明来源:游戏邦)

Analysis: Business Tips For Building Your Indie Game Team

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.

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 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. 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-faire 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 or portfolio builder. However, following through with those decisions is 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, an entirely different set of priorities and options arise: a group may decide to formalize as a non-profit with a robust IP management and asset distribution assistance program; organize as a for-profit business entity that helps produce and distribute games while taking a commission or fee; or they may elect to create any number of association or organizational models that can provide both financial stability and legal protection for the collective.

It’s necessary to work through the process of categorizing and fleshing out your goals before proceeding. Only when everyone understands and agrees upon the best possible scenario can you begin working toward that motive. The next step is putting that motive to paper.

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. 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 spell out how 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 clearly specify who owns what IP and how profits should be distributed when amazing success happens. 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.

Putting things in writing is the first step. Keeping those documents up to date so that they accurately reflect the evolution of your projects and your goals is equally important. As with design documentation, you may need to reevaluate what you originally wrote down.

For example, if Mary’s team creates a collaboration agreement for their project, they may need to amend that agreement if a member drops out or if a new recruit joins the project. If you have something in writing and check it frequently when things change, you are taking an important step to keeping the peace should your game see financial success.

To that end, knowing the assets that you are creating /contributing and putting a value to those assets as they come into being is also imperative. 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.

For example, in Bill and Carly’s illustration teams are constantly changing and the underlying group is constantly expanding. An adaptable approach can be adopted at the outset to avoid the kinds of problems Bill and Carly experienced. This might include a simplified project documentation form that lists team members, their roles, and their initial ownership interest, which can be expanded upon as the project nears completion. Fleshing out that basic form 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.

Finally, it’s important to record meeting minutes when new decisions are reached. If a conflict arises after a decision is reached but that decision wasn’t formally recorded in an amendment to your agreements, it’s helpful to have something to refer back to as a means of getting a clear picture. Your agreements let you know how decisions should be made and what decisions are pre-determined. This goes a long way to clearing up future disputes and the legal costs associated with those disputes.

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. (Source: GameSetWatch)


上一篇:

下一篇: