分析游戏开发团队管理者的作用和重要性
发布时间： 18:25:45
作者：Rampant Coyote
在我的游戏开发生涯早期，我很幸运能够与一些优秀的制作人/管理者共事。后来，在我的其它工作中（也包括一些与游戏产业无关的工作），我便再也没有遇到这种运气了。几天前，为了回应关于一些有趣报道所做出的评论，我们就游戏产业中一些制作人展开了激烈的讨论。Late White Rabbit，这位有着丰富商业经验的元老甚至质疑那些管理者和制作人的存在价值。
当我在发行第一款独立游戏时，最让我感到震惊的是时间问题，特别是在游戏发行后期，我花费于游戏管理的时间竟然远远多于我的想象。原本我以为作为独立游戏开发者，只有一个很小的团队（再加上外包人员的帮助），我将不会遇到这些繁琐的问题。但是事实并非如此，所以我想在此与你们分享我的亲身经验，谈谈我理想中的管理模式。在游戏发行后期，我花费了大量的时间发电子邮件给外包人员并与他们进行沟通，与电子商务公司和发行网站签订相关文件，制定出游戏发行计划和市场营销策略（显然我在这方面做得不够好，因为我的游戏并没有赢取多大的市场效应），接受记者的访谈，致力于网站上的完善等等。
对于独立游戏开发者来说，这些都是很有帮助的。
首先我们来说说一些理论上的问题。这些观点都是显而易见的道理，你可能也已经对此颇为熟悉。
作为独立游戏开发者，你总是单独行动。你擅长于所有东西。我讨厌所有像你们一样有才能的人（当然，这只是出于一种嫉妒心里）。不管怎样，作为一名独行侠，你可以将一整天的时间投入于游戏中（把游戏开发当成全职工作或者边兼职边制作游戏）。让我们把工作量称作“zot”。即你的产量是1.0zot，你的游戏获得1个完整的zot。
每款游戏的投入为1个zot(from rampantgames)
现在让我们假设你擅于游戏编程但是却不擅美工。而这时候你的游戏开发过程的效率可能只有0.25zot。而如果可以不受关卡设计，对话等因素的影响，你将可能获得完整的游戏生产率。不论是什么情况，如果你有一个合作伙伴，那么情况都将有所改变。当你的团队中有2个人一起开发游戏时，是否效率就会较之前快了1倍？不一定。只要你的的开发团队多了一个人，你就需要挪出更多的日常开支于彼此间的沟通与交流。这需要0.1zot的代价。但是相信我，比起那些未进行交流和沟通而引起混乱的团队来说，这种代价真的小太多了。就像我之致力于Jet Moto项目时发现，团队里的成员们对于游戏具有更多不同的观点，而因此导致最终制作出来的游戏与他们预期的游戏设置（和编码）相矛盾。
2人团队对游戏的投入为1.8个zot(from rampantgames)
不管怎么样，你现在将花费0.1zot与团队交流和协作，并投入0.9zot于游戏中。那么游戏便得到了1.8zot的总投入，而如此平均分摊到2个人的身上也正为合适。
如果增加到3个人又是什么情况呢？即一名设计师兼测试者，美工者和程序员。每个人花费0.1zot于彼此间的交流，并留下0.8zot给游戏。即他们每天总共花费2.4zot于游戏中。以此推算，4个人就变成2.9zot，5个人是3.0zot（5*0.6=3.0)。当团队人数变成6时，结果与5人是一样。每一名成员花费0.1zot于交流和协作中，就等于他们花费了0.5zot于日常开支上而只剩下0.5zot于游戏中，所以他们每天花费于游戏中也只有3.0zot。
6人团队的工作效率并不比5人团队更高(from rampantgames)
为何提升到5人的团队成员结构也没有让结果得到改善，甚至更糟？当团队成员提升到6人时，生产率甚至下降到与5人相当的境况。
也许我这种数字分配方法并不妥当，在现实中人们也许会花费更多时间与部分人交流，而没有与另一部分人进行沟通，但是，根据我的经验，这种人员分解经常是从4至6名团员变化开始。一旦你的团员从2名开始往上增加，你的团队政策将会发生相应变化。民主政策将能够帮助你的团队成员和平共处，但是它们却不能帮助你提高工作效率。你的团队拥有更多不同角色的成员，你将面对更多潜在的风险，并且在情况还未变得最糟糕前你未能发现这些风险。
拥有一名管理者后的工作效率大为提升(from rampantgames)
而这时你就需要采取一些管理工作。你按照等级结构去区分一些事物，如上图所示那样，我们现在有7名成员，但是他们只与制作人（比起进行单纯的交流，他的作用是推动其他成员间的沟通）进行交流。所以再次，增加第7名成员以充当制作人的身份，将形成6*0.9=5.4zot。而因为制作人本身还有0.2zot可以直接用于游戏本身，最终的工作效率便可想而知了。
对于那些同时开发两款游戏的大团队来说，这种方法更为重要。随着工作室的发展，你的游戏在开发过程中将会需要不同的人力。而让一些人站在较高的级别去明确更多工作和资源需求，将会对你的游戏开发更有帮助。
显然的，比起那些有一名成员单纯地进行着“管理”工作的策略，这种方法看起来好多了（游戏邦注：小团队尤其如此）。但是这个也只是用于解释为何3，4名成员以上的团队不适用于平面模式，而需要采取等级模式的一种理论观点。不管怎么样，如果你的团队中有一名优秀的制作人，能够帮助你管理好整个团队，那么这就是最好的实际理论。以下我将根据自己所遇到的情况谈一些个人观点/理论。
首先是关于管理人员的等级或者位置。这是一个很棘手的问题。这就是为何我图上所有成员是围绕着管理者而非位于其下方的原因。我认为（特别是在一些小公司里），管理人员在薪资/级别上应与其他团队成员相同，或者至少不能在所有“利益相关者”之间“搞特殊”。不过小团队聘请他人扮演管理者角色的情况也并不鲜见。我承认，没有权威的管理者确实比较头疼。但是我并不认为这是“领导者”所需要的唯一一种才能，我认为，作为一个团队中的管理者，他还必须对自己所领导的成员们负起责任。
其次，在一些小团队（或者特别是在一些小团队）中也有一些领导角色。并非意味着所有人都要听这个领导角色的话，而是指他能承担起团队中的相关责任。这个人将是游戏的领导者/管理人/制作人等等。不论什么时候，只要是1个人以上的团队进行任务，那么他们就需要一个与任务相关的领导。你将会有美工领导，编程领导，设计领导，市场影响领导，业务处理领导（特别是在与第三方或者发行商签订合同时）等等。你可以派遣团队中的一人担当领导角色。这是很多独立游戏开发者所采取的措施，即让一个人承担起领导任务，并签订一系列合同条约等。
不管怎样，这种领导者的角色始终存在于团队中，甚至是对于那些需要扮演不同角色的独立开发者而言也如此。需要有些人去确认游戏的发行时间是否适当，确保所有的开销不会超过预算，并保证游戏的质量能够满足玩家的需求。换句话说，这个领导者正是带领整个开发团队走向成功的重要角色。这个人既需要有足够的威信，也需要有准确的判断力。任何决定都不能只是停留在表面工作，需要一个人来做最终的决定。
我所钦佩的团队领导者/管理者需要管理各种琐事。不论他是谁，作为领导者，他最好能够扫清阻碍游戏成功的各种障碍，解决团队美工和编程成员间的争吵，决定是否购买帮助提高生产力的新工具等等。
不幸的是，就像Late White Rabbit的评论中阐述的，即使在整个软件产业里这种领导者也不算是一个完整的“产业标准”，更别说在单单一个游戏产业里了。反倒是这些领导者所做的事经常有悖于我们的期待。他们频繁地召开会议只是想让让人觉得他们很忙，其收集一些信息则是希望能对上级有所交代。他们对一些小事情吹毛求疵，但是对于一些大事情却往往不敢下决定。更糟糕的是，他们总是扮演着暴君的角色，不经过团队其他成员的同意便妄自下决定。最可怕的是，他们常常不把自己当成是团队中的一员，总是想着如何做才能逃避团队中的争执。
游戏邦注：原文发表于日，所涉事件和数据均以当时为准。（本文为游戏邦/编译，如需转载请联系：游戏邦）
What Does a Game Producer / Manager / Leader Actually Do?
Posted by Rampant Coyote on February 23, 2011
When I was in the trenches of game development early in my career, I was lucky enough to have some producers / managers who were pretty good at their job. Later on, in other jobs (including many outside of the games biz), I wasn’t always so lucky. A couple of days ago, in response to my little commentary on interesting bug reports, we got into a lively discussion about some producers in the games biz who are pretty much useless. Late White Rabbit even asked – as an experienced Marine with a business degree – questioned the value of managers or “producers” (as they were called in my first company) at all.
One of the things that really shocked me when I released my first indie game was how much of my time – particularly during the latter stages of the project – I spent doing “management” type things. Here I thought, as an indie with a principle team of one (plus contracted help), I’d be rid of that entirely. So I figured I’d post on this – based on my experiences (good and bad), and my ideals of what I think management SHOULD be like in my own little imaginary world. But I was spending a lot of time emailing or talking to contractors, signing paperwork with e-commerce and distribution sites, working out launch & marketing plans (evidently I didn’t do so well, as the game was never a big seller), talking to journalists, working on the website, etc.
So this is valuable stuff for indies, too.
First – a quick review. How things work in theory. These lessons come directly from Mount Obvious, so you should already be familiar with them.
Let’s say you are a “lone wolf” developer. You are really good at just about everything. I hate talented guys (and gals) like you.
(Actually, I want to be a guy like that, but I hide my aspirations with jealousy.) Anyway, you the lone-wolf can devote your full attention in a
day to your game
– whether that’s a full-time day, or a 2-hour evening working part time, doesn’t matter. Let’s call that amount of work a “zot.” So your productivity is 1.0 zots, and the game gets the full zot. Life is awesome. Ain’t being a lone-wolf indie grand?
Now lets say you are awesome at programming, but not so good at art. Maybe that part of the game development process only has you operating at 0.25 zot efficiency. Or maybe you think you can only achieve your full productivity if you don’t have to be distracted by things like level design, dialog, and so forth. Whatever the case, you decide it’s best if you have a partner. Now there’s two of you working on the game. Should get things done twice as fast, right? Well, not quite. As soon as you have other people working on the game, there’s some overhead introduced involving communicating and coordinating with each other. Let’s say it’s a cost of 0.1 zot. Believe me, it’s cheap compared to the alternative – major, major disasters have been caused by teams NOT paying that cost and the project descending into utter chaos. While not a disaster, we ran into similar issues when I was working on Jet Moto, where some team members had a different vision of the game than others, and ended up generating assets that were totally incongruous with the expected gameplay (and code).
Anyway, both of you are now spending 0.1 zot coordinating and communicating, and then putting 0.9 zots into the game. Now the game is receiving a combined total of 1.8 zots, for 2 people. Not too bad.
Rev it up to three people – say a designer who is also taking on the role of tester, an art guy, and a programmer. With everyone spending 0.1 zot talking to each of their other two team members, that leaves them 0.8 zots working on the game . That’s 2.4 zots spent per day on the game, total. Four guys, the total is 2.9. Five guys, it goes up only a tiny bit, to 5 x 0.6 = 3.0. And then… we bring the team size of six people. same values. If every team member is spending 0.1 zot coordinating and communicating with the other five members, then they are spending 0.5 zots on overhead, and only 0.5 zots on the game itself – for a total of still only 3.0 zots per day.
What? No improvement at all over a team size of five guys? And it gets worse! As the team size expands above six, productivity drops even more with a flat team hierarchy.
I may be pulling numbers out of the air, and in reality guys may spend more time talking to some and not to others, but in my experience the break-down usually starts occurring somewhere between four and six team members where “flat” fails. Also, once you get more than two people involved, politics may happen. Democracies are great for getting people to coexist freely and peacefully with each other, but they don’t work well for getting
a job done. And the more people you have with different roles, the more potential there is for something “falling through the cracks” and not getting done until it’s a bad, expensive surprise.
And that’s where you get some kind of management involved. You break things into a hierarchy. Even something as dumb as the picture to the left will work — now we have seven people working, but only “talking” to the producer (who is probably, in reality, facilitating coordination between members rather than just acting as a single point of communication — this is all theoretical here…) So in this example, adding a seventh person as the producer theoretically brings everybody up to 6 x 0.9 = 5.4 zots. And even the producer may have 0.2 zots left over to do some direct work on the game himself, right?
This gets even more important with larger teams that may have two projects in development at a time. As studios grow, this is key, as games have different manpower needs during development. Having someone at a higher level who can perceive the “greatest need” and shuffle resources as needed can be very helpful.
Obviously, there are probably much better ways of doing this that would be cleaner than having one dude doing little more than just “managing,” especially for a very small team.
But this was a theoretical exercise to illustrate about where a “flat” model breaks down very quickly, and why some kind of hierarchy gets needed after about three or four people. Anyway, that’s the basic theory, if you have a good producer managing a team. Now we’re going to some personal theories / ideals of my own -
based loosely on what I’ve seen work.
First of all – the rank or position of the manager. This is a tricky situation. And this is why I drew the picture with the team surrounding the manager instead of being “under” him. I do believe, especially for small companies, that management should be pretty much equal in pay / rank to the rest of the team – or at least no different from any of the other “stakeholders.” It’s not unheard of that a small team might actually hire someone to manage them – making the manager their employee. I do acknowledge that the lack of authority may cost them some of their tools. But I do not believe that is necessarily the case, and I think there’s something inherently healthy about the “leader” of a team also being answerable to the people he leads.
Secondly – there are lots of leadership roles on even a small team. Or maybe especially on a small team. Not all belong to one person, but I do believe there should be one person for whom the buck stops with them.
That person is the project lead / manager / producer / whatever. But whenever more than one person may be involved in a task, one person should have the leadership role related to that task. You have the art lead. The programming lead. The design lead (or “keeper of the vision.”) Someone leading marketing efforts. Someone handling the business end of things – particularly when it comes to setting up contracts with third-parties or distributors.
You could have one person doing that role. For many indies it comes exactly down to that, as there’s one person running the show and working with contractors.
But the role is always there, even for lone wolves who must wear a dozen hats daily. Someone needs to be making sure the project ships in a timely manner, doesn’t blow its budget too badly, is of reasonable quality and addresses the needs of its intended audience. In other words, they have to lead the team to success.
Someone needs to have both the will and the authority to cut features and make other hard decisions necessary. It shouldn’t be done in a vacuum, but someone has to have the final say.
One final role I admired in team leads / managers was to be the “mother hen.”
This person, whoever they are, may also be in charge of removing obstacles to the team’s success – whether it is in internal argument between art and programming, or deciding whether or not to buy a new tool for the team that would theoretically boost their productivity.
Unfortunately, as Late White Rabbit noted in his comments, this isn’t all “industry standard” even in the software industry as a whole, let alone the games biz.
Too often they end up doing the opposite of
what I feel their jobs should be. They create long meetings to feel busy and collect information so they can report to their own superiors as if they actually knew what was going on. They nitpick the small stuff, and are afraid to make a decision on the big stuff. Or worse, they play tyrant, and make fiat decisions without gathering information from the rest of the team.
And worst of all, they don’t seem to consider themselves part of the team, but rather someone aloof to the fray.(）
CopyRight Since 2010 GamerBoom All rights reserved &&闽ICP备&号-1网络游戏开发_百度百科
网络游戏开发
本书出自两位世界级资深网络游戏专家之手，全面介绍了如何构架、发行和维护网络游戏，专业而又详尽地讲述了网络游戏制作、发行及运营中的一些实际细节。书中汇集了网络游戏开发历程中的经验与教训。 对于从事网络游戏开发的业内人土，特别是管理人员，本书是不可多得的佳作。本书同样适合于对网络游戏开发有兴趣的玩家和读者。网络游戏：英文名称为Online Game，又称 “”，简称“网游”。指以互联网为传输媒介，以服务器和用户计算机为处理终端，以游戏客户端软件为窗口的旨在实现娱乐、休闲、交流和取得虚拟成就的具有可持续性的个体性多人在线游戏。“本书汇集了许多大型网络游戏开发的优秀经验，采用书中的这些建议可以为公司节省数百万美元的成本 ” Gordon Walton，公司副总裁，《模拟人生在线》执行制作人 你已经准备好要制作顶级的网络游戏，在这个利闰丰厚的行业一展身手了吗？要达到这个目标，最好的方法就是去学习他人的经验！但要获取成功的秘诀并不容易 业界领军人物Jessica Mulligan和Bridgette Patrovsky带你进入幕后，分享成功秘诀，而这些都来自作者30年的从业经验。本书的精彩之处： 在开发者还未开始编码之前最常犯和最致命的错误（第6章） 如何正确地发行游戏，了解产品和服务何者才是重点（第11章） 在大规模发行之前最关键的因素（第10章） 网络游戏开发团队最需要却最容易被忽视的人（第3章）
网络游戏开发图书信息
图书作者： [美]Jessica Mulligan、Bridgette Patrovsky 著 姚晓光 等译
出版时间： 版
印刷时间： 次印刷
开 本： 16
价 格(元)： 39
网络游戏开发相关介绍
研发：中国网游新起点
学习使人进步
不是精品不动心
第一部分 执行
第1章 市场
第2章 计划与
第3章 项目管理与项目经理
第4章 营销与发布：零售、下载或是二者并行？
第5章 计算并扩大利润率：成本控制
第二部分 设计与开发
第6章 基础设计与开发思路
第7章 深入探讨开发与设计
第8章 学会设计
第9章 其他设计与开发问题
第三部分 发行与管理
第10章 发行期
第11章 游戏发行后的管理
第12章 游戏运营期间开发团队该做什么？
第四部分 专家的文章
第13章微软的《超级兵团》：为什么这个回合制游戏失败了
第14章 《》回忆录
第15章 荣誉与耻辱：网络游戏中的强力心理学
第16章 案例研究：网络游戏生命周期
第17章 大型多人游戏热血玩家之狱火重生
第18章 回顾：《卡洛特的黑暗时代》的神话
第19章 管理在线世界中的出轨行为
第20章 《》的历史影迹
附录A 游戏制作人需考虑的事项清单
附录B 被访者说
附录C 商及部分结果
附录D、、方块、黑桃分类
附录E网络游戏大号年记
附录F 术语表
游戏开发的组织架构
游戏研发的组织架构移动游戏发行商Scopely的成功秘诀是什么？
[导读]Scopely已经发行了四款上过App Store免费榜首位的游戏应用。
腾讯科技 林靖东 11月29日编译游戏行业是一个成王败寇的世界，游戏公司的业务与其产品的热门程度息息相关。多少曾经风靡一时的游戏公司最终都因为无法维持长期的成功而惨谈收场，普通投资者一般都不敢进入这个领域，因为其中的风险实在太高。然而，洛杉矶的移动游戏发行商Scopely却连续发布了4款最热门的免费游戏，它是否破解了游戏行业的成功密码？Scopely的创始人兼首席执行官沃尔特德奈弗（Walter Driver）回答说，是的。当然，这个答案还是有一定的前提。发行和推广独立团队的游戏Scopely自己并不开发游戏，而是与独立开发团队合作，Scopely主要负责发行和推广那些游戏。它已经建立其一个分销平台并且总结出一套似乎行之有效的发行方法，它主要依靠开发合作伙伴来提供有吸引力的内容。Scopely可以协助开发合作伙伴精益求精，最终让团队具备开发出精品游戏的实力。Scopely就象是一家好莱坞工作室，寻求与其他公司达成分销合作，将他们的影片投放到电影院、Netflix和等销售平台上，以及压制成DVD影碟出售。这就意味着，Scopely在决定与某家游戏开发商合作之前，必须对对方的游戏进行市场实测，寻找目标受众和潜在的广告商。德奈弗称：“在将合适的产品提供给合适的用户并与广告客户建立合作方面，移动应用市场目前的效率很低。我们的工作就是为三者牵线搭桥。”Scopely的方法就是在将每一款游戏推广到更广泛的网络中之前，首先测试游戏的市场销路。公司聘请了很多人际交流方面的专家，他们会详细观察参与游戏测试的众多玩家玩游戏的过程，记录下很多有用的信息，比如玩家在哪里玩游戏，在哪里下线等等。然后Scopely就会利用专家们搜集到的反馈信息对游戏进行更新，再对更新后的游戏进行内测，然后再进一步搜集更多的反馈信息。如果一切顺利并且游戏在得到多次更新后达到可以正式发行的状态，Scopely就会在海外的一个小市场比如新西兰进行发行，这也是公司最终在北美那样的大市场正式推出游戏之前的最后一项品质保证措施。德奈弗称：“我们在美国市场推出某款游戏的时候，我们已经能够确定人们一定会喜欢它。”如何让游戏在应用商店中脱颖而出然而，成功的道路还只走了一半。更大的难题是如何让那款游戏在iTunes App Store和Google Play商店的100多万个应用中脱颖而出，让用户们注意到它。这就体现出Scopely的分销平台的重要作用和实力了。到目前为止，Scopely一直都未公开它推广游戏的方法，因此有些人指责它是通过“购买”的方法来推广游戏的，也就是说它的推广方法有欺骗的成分，因此它的成功并没有太大的意义。那些人的想法是：如果你可以通过钱让自己的游戏登上应用商店排行榜的榜首，然后其他用户就会看到那款游戏，它的下载量就会越来越大，然后你就可以用其中的付费玩家贡献的收入去冲抵之前为冲榜而花费的开支。但是这种做法只有在付费玩家和冲榜行为给游戏带来足够多的新用户的情况下才有用。德奈弗并不否认Scopely采取了上述方法。外界和竞争对手称为欺骗的东西，他认为是正常的经营手段。需要说明的是，Scopely的目的是让它获得的那些付费用户最终变成公司的长期、忠实用户。还记得Scopely在推广游戏之前所做的前期市场调查吗？德奈弗称：“我们通过冲榜让更多的人能够注意到我们的游戏，我们当然想从中获益。但是有些用户对玩游戏是没有兴趣的，我们不会花钱去购买他们的流量。”阴谋理论家真该死。但是如果Scopely不是利用中国的僵尸农场或其他见不得人的手段取得成功的话，那么它成功的秘诀是什么呢？德奈弗说：“我们最高质量的流量来源于我们现有的用户。这部分流量的效益比其他渠道贡献的流量高出很多倍。我们认为这证明了我们正在构建的社区对我们的信任。”Scopely的用户社区现在已经发展到超过2500万人的规模，德奈弗称，用户们希望第一时间获得公司发布新产品的消息。Scopely主要是通过应用内交叉推广和邮件推广的方法获得这样多的用户的。它使用的方法与著名社交游戏开发商Zynga推广游戏的方法很相似。从另一个角度来说，Scopely的这种方法让小型独立开发商有机会利用大型出版商的战略去开拓大规模的市场。这可能还不是人们想要的最终答案，但是规模效应却是有目共睹的。未来的风险德奈弗称，Scopely发现每次发行新游戏，转换率都在上升。它刚刚发行了第六款游戏，尽管只有Skee-Ball Arcade、Wordly、Mini Golf MatchUp和Bubble Galaxy With Buddies这4款游戏到达过榜首，但它仍凭借着这6款游戏挤进了App Store前五大发行商行列。现在问题就变成了：游戏公司的成功是否一定是由热门游戏推动的？Scopely的成功有一部分要归功于其网络的发展，但是它也改进了市场研究和游戏开发的方法。另外，为了获得最高的投资回报，Scopely还放弃了一些成效不大的用户获得渠道。德奈弗说：“随着时间的推移，我们在分销这些产品方面做得越来越好；而且我认为我们可以继续表现得很好。市场观察员们认为，这个行业是由热门游戏推动的，但是热门游戏毕竟是少数。热门游戏每年可以创造上千万美元的收入，但是我们认为我们可以用我们的方法持续获得那样的成绩。”最后一步就是将这些游戏与广告客户联系起来。Scopely之前与可口可乐、星巴克、和三星一同举办过品牌宣传活动。Scopely的开发者合作伙伴们自己可能很难吸引到这个层次的广告客户，因为他们没有广告位和专业销售团队。Scopely目前共筹集到850万美元投资，共有员工90多人，其中包括它从游戏和广告业界的大腕比如Zynga、Supercell和LinkedIn等公司挖来的不少人才。除了拥有庞大的人才队伍和快速成长的忠实用户社区，Scopely获得成功的另一个关键是它在短期内制定出一套有效的战略，因此得以快速地改进其营销方法。德奈弗称：“如果你是一家传统的游戏工作室，每年能够开发出两款游戏，但是在获得成功之前，你不知道那些游戏是否能够在全球市场取得成功。而且你也无法决定在本地化和分销方面与哪些合作伙伴进行合作，在尝试之前你也不知道排序中最重要的是什么。我们每一次发行新游戏，都会剔除一些效率不高的渠道，因此变得比以前更有效率。”Scopely目前面临的一项大风险是应用分销有可能会变得商品化。如今，应用商店发现还是支离破碎的，很多开发商还在学习各种商业技巧以便在这个快速成长的行业里取得成功。不难想象，几年后和()将利用传统搜索、发现和营销工具去帮助开发商和用户更好地使用应用商店。在这种环境下，Scopely的系统也许就没有太大的价值了。利用早期的秘密经营和庸俗但有效的招募技巧，Scopely似乎已经建立起一种可重复的、人造热门移动游戏的方法。这可不是小聪明，但是世界上的聪明人也不少，也有不少人使用类似的方法去争夺应用商店排行榜的排名。Scopely面临的下一个挑战就是它必须证明它可以在这场竞争中保持领先。德奈弗称：“确实，我们建立的网络是系统性的，但是我们还需要不断去改进和发展这个系统。”
[责任编辑：loiswang]
您认为这篇文章与"新一网（08008.HK）"相关度高吗？
Copyright & 1998 - 2017 Tencent. All Rights Reserved
还能输入140字