当前位置： >>
开发者外包游戏项目所需注意的事项及准备
摘要：外包经理为自己有着现今最新颖的工作而感到自豪，但是这份工作就像空中交通管制员和社会工作者那样可能让你的寿命缩短。我或许说的有点夸张，可能是因为这些年来该领域给我的重重压力。这是个可能让你愁白头发或罹患心脏病的工作。也就是说，这个工作可能带有一定的职业危险。
第1页:开发者外包游戏项目所需注意的事项及准备
第2页:开发者外包游戏项目所需注意的事项及准备
　　我多年来担任总监并领导过数个艺术工作室，经历过外包过程的各个阶段。我将在下文中从外包管理者的方向来阐述，解释为何这成为行业中相对较新颖的职业，而且对现代游戏开发工作室至关重要。这个职业没有很长的发展历史，而且工具仍在设计完善之中。各工作室的外包管理者也有所不同，但通常来说，外包经理身兼艺术总监、人事经理和制作人等多职。安排时间、评论艺术、猎头、检查文件、管理合同、审核提案、谈判和处理发票，这些只是外包经理的日常事务的些许内容。如此多的工作很容易让人感到不知所措，而且如果没有一整套合适的工具，你会觉得头昏脑胀。
　　与外包经理相对的是艺术工作室。从工作室的角度来说，外包经理是所有项目的关键所在。如果交流不善或者无法获得项目所需的信息、材料和工具，那么就有可能让项目进展不顺。工作室通常也需要通过多个项目来迎合多种类型的客户。如果外包经理和工作室间的关系紧张，那么便会加剧在这个压力重重的行业中制作游戏的压力。对于这种结果，双方都负有责任。通常这个行业中并没有恶人，都只是些兢兢业业的职业人士，只是这个行业的本质导致某些困难情况的产生。所有人都有着相同的目标。我们都想要尽可能地把游戏做到最好。没有任何一方希望自己因工作患上心脏病，或者凌晨3点在桌旁吃着冷嗖嗖的比萨。避免出现这种情况的最佳方法是培养你们之间的关系。
　　我们的工作就是处理好关系。作为外包总监，我的价值体现在有能力召集合适的人群来将工作完成。寻找我相信而且能够相信我的人。对我来说，我的工具就是在需要时可以调用的大量工作室和承包人。当艺术总监对你说需要在两周时间内拿到4个角色的模型，你可以拿起电话联系StickyMonkeyMushroomStudios的Joe，你知道他可以快速地提供高质量的角色模型。能做到以上这种程度，你就是个英雄。通过这种方式，你体现了工作的价值。你之所以可以这么做，是因为与StickyMonkeyMushroomStudios培养起的互信关系，而你从与该工作室来往的首封邮件起就开始培养这种关系。或许最早的这封邮件只是让工作室提些建议而已。
　　我想在下文中提出某些可供其他外包经理遵循的指导原则。无论你是这个过程中的哪一方，你或许会觉得这些提案很有用。编写这些指导原则的目标只是为了传达有关某个仍然新颖且正在发展中的过程的信息。因为这篇博文很可能被人当成小说来看，所以我把文章的重点放在外包过程的提案阶段。我之所以要着重阐述这个阶段，是因为客户和工作室的其他关系的产生都源于这个阶段，拥有好的开始总是个不错的想法。本篇文章的目标在于，为这个压力重重的过程增添某些新颖的想法。我希望这些建议能够帮助改善涉及该行业的人的工作。
　　向我们提供所有的信息
　　我知道，这时候可能有人会为&向我提供你所有的信息&这种想法感到很惊恐，我也不例外，这确实有充足的理由感到担心。但我们不会不负责任地对外提供信息，我们相信你也不会这样做。我们即将要踏入的是业务关系这个领域，所以所有的意图都必须非常清楚，需要建立起信任并且信息必须能够自由流动。如果我们能够预先在这个阶段中投入时间和精力，那么就会节省随后需要的时间和精力，而这些节省下来的资源可能有更大的作用，比如对整个项目进行润色。我们调用所有的资源，针对你的项目提供最好的服务。我们不是麦当劳。我们没有制定适合所有项目的提案。我们知道单个解决方案不可能适合每个项目。我曾经对多数艺术工作室说过这些话。我们想要尽可能地将工作做好。我们想帮助你做成市场上视觉效果最好的游戏。我们想要让你的客户感到高兴。我们希望能够发挥自己的长处来提供帮助。
　　提案文件
　　当你要求多个工作室递交提案时，机会就来了。处理多个工作室意味着你必须不断地重复自己的想法。制作提案文件几乎可以帮助你避免上述麻烦，这这份文件中包含所有你能想到的工作室或承包人在项目投标中所需要的信息。如果你有艺术背景，那么你就很容易知道文件中需要包含哪些信息。如果你没有艺术背景，那么就要同团队中的艺术总监、艺术师和程序员交谈。尽你所能获得尽可能多的信息。最好将精力放在现在而不是以后，回复每个工作室发来的有关项目投标的邮件。如果你运气好的话，你的艺术总监或许已经编写完成了艺术标准，你可以从中获得许多信息。如果没有的话，你就要自己完成这项工作。编写这种包含所有信息的文件对你的团队和工作室都有益处。你的文件应当包含如下信息：
本文地址： 网友评论:
条 阅读次数：
版权声明：凡本站原创文章，未经授权，禁止转载，否则追究法律责任。
·····
《哈佛商业评论》前执行主编Nick
美国联邦储备局理事会在新的战略
Netflix最近开设了一项金额为10努力加载中，稍等...
暂无新消息
努力加载中，稍等...
已无更多消息...
这些人最近关注了你
努力加载中，稍等...
已无更多消息
努力加载中，稍等...
已无更多消息
为什么越受重视的游戏项目越难开发好（一）
声明：本文不影射任何行业产品，请勿对号入座，保留删除评论权利。在国外的游戏行业里面，有一类游戏称为AAA游戏，Wikipedia上面的定义是：In the video game industry, AAA (pronounced "triple A") is a classification term used for games with the highest development budgets and levels of promotion or the highest ratings by a consensus of professional reviewers. A title considered to be AAA is therefore expected to be a high quality game or to be among the year's bestsellers.[5][not in citation given] For a title to remain AAA post-launch, it must be either commercially or critically successful.上述引用文字纯粹用来增加逼格，只要看这段中文就好了：简单来说，AAA游戏就是一些开发预算非常高、推广预算非常充足、质量很高的三高游戏，通常都被期望能有很好的商业成功。开发AAA游戏是大型游戏开发企业的最终追求，每年他们都会投入大量资源开发AAA游戏。目前单机游戏不算太景气，单机行业主要的推动力量，还是依赖这些名称后面有个数字，数字每年+1的产品。类似的做法在国内也比比皆是，每一个大型开发商都有自己的旗舰产品，我们也可以认为这些产品就是国内的AAA游戏。毋庸置疑，对AAA游戏开发的重视，会让这些公司从上到下，都对这些产品投入资源和重视。但是一个有趣的现象，就是很多大作往往难产，或者拖上很多年，就像一个无底洞，吸引公司不停投入，但进展缓慢。同样的现象，在很多项目里面不停的重现。这里面一定有什么地方不对，导致投入和产出不成比例。我们来分析几个原因：早期原型阶段的高效造成了效率错觉在项目早期的原型阶段，往往1-2个程序员在很短的时间内就能做出很多东西，这会让团队低估整个游戏的开发难度。这里面又有几个不同的情况：在早期阶段，如果是用unity、cryengine或者unreal这样的商业引擎，那一开始就可以根据自己要做的游戏类型，直接套用引擎自带的现成的框架或者demo，还有market place给你直接选择原型。刨除学习成本，在很短的时间里面，一个大致的游戏原型就出现了。如果用成熟的自研引擎，那参考上一条，肯定有之前成功的项目，一下就拉来一大票可用的代码和资源，简单拼凑一下就有demo了。如果是从头开发的自研引擎，那开发早期团队规模小，引擎规模也小，系统少，不需要考虑多人合作，不需要考虑各个系统能和谐工作，简单hack一下，就把原型搞完了。负担少，自然跑得快。很快，一个出色的Demo做出来了，领导龙颜大悦，这几个人果然靠谱，才花了这么一点点时间和资金，就做了一个好原型。往往管理层就会产生一个错觉，这是一个优秀的团队，我多投点钱，组建一个大点的团队，分分钟搞出一个AAA游戏去赚一笔。但作为一个成熟的开发者，请一定要抵制这样乐观的想法。你们的团队或许很强，你们积累应该很多，你们背后站着整个公司的支持，你们手捏几千万的预算，但是这一切并不一定代表一个成功的游戏。没有谁欠你一个成功，再好的产品原型也可能无疾而终。原型阶段的高效，来源于规模小，小带来了高效。因为规模小，你们自己的东西不多，所以可以考虑用现成的demo改改就上因为规模小，团队不用磨合，没有政治，没有八字相合相冲，大家为了一个目标奋斗上去就搞，沟通成本也很低，不用预约什么会议室，吼一嗓子，明天游戏里面就看见你要的特性了。因为规模小，各个系统关联不多，不容易有一周做完一个特性原型，整合进版本分支，把方方面面流程理顺，crash调完，最终额外多花了二周的事情发生因为规模小，每个人的意见都容易被尊重到，大家都有一种在创业的感觉。因为规模小，大家期望也低，做什么出来都让人眼前一亮。小demo，往往美术资源都是东拼西凑，很快能凑出来。开发效率递减问题紫棋实际情况非常残忍，作为AAA游戏，规模一定会变大，游戏规模导致的开发效率递减问题会逐渐提上议事日程。你不能总做demoDemo终于做完了，立项了，大家意气风发，准备大干特干。但你却发现，引擎上似乎有一点点小问题。商业引擎带来的早期红利很快就会消失，你总要脚踏实地一个个做自己要的特性，到时候你就会发现，对引擎不熟悉，改个什么东西总是很别扭; 或者引擎有大量你不要的特性，带来了额外的负担; 或者卖引擎的时候说的天花乱坠，拿到手一看怎么和说好的不一样呢; 引擎开发商说好的24小时支持呢？如果是自研引擎，操心的事情也一样不少。程序Hack的特性，没法让策划、美术进行多人协作，你说要不要改一下？那边一堆硬编码，应付demo的，必须要数据驱动啊，数据驱动以后就可以扔给内容开发人员去维护了，程序员肯定不能拒绝这个诱惑；demo里面一大堆没做完的镜头特性，优先级不高，汇报的时候让领导自行脑补的，你不会打算让玩家也脑补吧？一面是程序承诺的一堆特性迟迟做不出，一面是闲着没事的策划和美术开始唱起了家乡的歌谣，四面楚歌的压力应该可以想象吧？Demo完成后通常要一段不小的时间，重新组织队伍，整理重构架构，这个downtime，在每个项目中都不少见，但通常都比较隐性，不容易被注意到。他和我不一样团队总会扩大，你会发现林子大了什么鸟都有。有些人就是没法谈到一起去，交流效率变低；有些人理解和你不一样，一个特性做来做去就是不到位；有些人能力超强但是不能合作，一个人在一边solo；有些人加班太少，东西来不及做也不管；有些人加班太多，弄得团队人心惶惶；有人太不好学，跟不上项目的节奏；有些人太好学，一直兜售各种不成熟的技术，试图整合进项目来添乱。每个参与项目的新员工，都会带来交流成本的提升，大家的背景不一定一样，习惯也未必相同。有人想来刷项目经验，有人纯粹来学习，有人赶来救火，有人不情愿却被领导扔进来。人多的地方就有文化，搞搞文化建设，组织学习活动，经常面试一下新人，这要花多少时间啊..重建pipeline场景资源不能靠拼凑其他游戏的资源了，是不是要搞个合适的外包流程，再去申请点外包经费？策划填xml都快要起义了，咱们是镇压他们呢，还是让程序给他们做个图形化工具？UI不能硬编码了，咱们上一个scaleform吧？前面做的东西翻新一遍，分分钟搞定看上去是不太可能了。人肉构建受不了了，做个版本要2个小时，每次出版本整个项目留下来等，还要不要回家了。做个自动构建 + 每日构建 + 自动单元测试 + 数据自动convert + 构建权限管理 + 自动冒烟测试 + 自动部署 + 代码review系统 + 分布式编译，能有的全加上，怎么也不是1个月能搞定的事情吧。。。美术反映某一关的开发进度来不及了，要多人一起上去群P。尼玛做编辑器的时候没有打算让你们群P啊，做点临时merge方案应应急吧。公司内部各种技术评审，流程繁琐，咱们是大项目了，也该尊重一下流程，写点文档，阐述一下思路吧。一通加班，终于连滚带爬搞定了，每天上班，看见程序、策划、美术团队都彼此独立的高效并行开发，心情很好。但你以为这就是全部的挑战吗？未完待续。。。
分类：(原创)项目管理
版权所有，禁止匿名转载；禁止商业使用；禁止个人使用。
登录后参与讨论。点击
请勿发表无意义的内容请勿发表重复内容请勿发表交易类内容禁止发表广告宣传贴请使用文明用语其它
淫秽色情政治倾向人身攻击抄袭剽窃广告刷屏恶意挖坟冒充他人其它Service Unavailable
Service Unavailable
HTTP Error 503. The service is unavailable.}