《最终幻想XII》开发总结
2007-11-10 22:52 | otarma
《最终幻想XII》开发总结
原载于《Game Developer》2007年8月刊
游戏数据：
开发商：Square Enix
发行商：Square Enix
平台：PlayStation 2
发行时间：2006年10月31日（美版）/2006年3月16日（日版）
使用软件：Autodesk Maya, Softimage XSI, OPTPiX iMageStudio
怪物种类：250
Boss数量：30
NPC数量：1000
作者：村田琢（Taku Murata）
Square Enix（以下简称SE）有限公司研发总负责人，《最终幻想XII》（以下简称FFXII）监督，同时在公司的PlayOnline网络业务开发中也起到了很重要的作用。
翻译：otarma
FF系列乃是SE的一线知名游戏品牌。当我们预备开发十二代时，实际上有3款游戏可以算得上是其前作：FF IX、X、XI。这三款游戏都是同时在2000年1月的新闻发布会上公布的。
这三款游戏每一款是此系列的新篇章：FFIX是PlayStation平台上的最后一款FF，FFX是PlayStation 2平台上的第一款FF，FFXI则是SE的首款网络游戏，并且该游戏是PlayOnline网络业务的核心部分。
在我们着手开发FFXII的时候，FFX有了续作——FFX-2，于是FFX游戏制作组就原班上阵。同时，FFXI的业务取得的成功远超我们预期，于是FFXI制作组也就继续乘势开发后面的内容。
鉴于FFX和XI都在开发中，Final Fantasy Tactics（《最终幻想战略版》）和Vagrant Story（《放浪冒险谭》，又译《漂泊的故事》）的制作组便聚集到一起来制作FFXII，这便构成了第三个FF的家用机以及PC平台的制作组。
制作组的成员（包括我）都有过开发实时/动作战斗系统（action/real-time-based battle system）的经验，这样的系统让场景和战斗产生了互动。我们决定利用之前积累的经验，将实时动作战斗系统融入FF系列中。这可谓是巨大的挑战，因为此前发售的FF使用的都是随机遇敌的战斗系统。
于是项目便启动了。但很快，我们便遇到了各种问题，复杂得完全超出了之前的想象。整个开发的过程实在是让人学到了很多。
成功之处
1 崭新独特的开发团队
虽然我们名义上组建的是FF系列的第三个开发队伍，但实际上，所有的开发队伍构成并非停滞不变，他们在不断发展，而且人员组成也不断变化。
这个独特的新团队各个成员之前的多种多样的工作经历造就了不同以往的团体氛围。而队伍中还有许多成员从前从未参与过像FF这样一个开发经费充裕、人员规模巨大、花费时间漫长的游戏系列的开发——。
有新人加入可以说是“成功之处”，因为这样团队便可以从崭新的角度来审视开发进程，而且也利用到了新的技术。后者我会在下文详谈。
2 公司内部开发工具
“公司内部开发工具的使用”是我在2007年游戏开发者大会（Game Developers Conference）的演讲主题。我们有许多内部编写工具，再加上商业数字信息制作工具，比如Photoshop、Maya和Softimage XSI，一个良好的工作环境便形成了。我们可以在反复尝试新工具的同时通过使用已经熟稔的工具来提高生产率。
内部开发工具实在给工作带来了巨大的好处：我们可以使用游戏的渲染引擎进行实时预览。而且由于开发FFXII时内部开发工具效果不错，使得公司也做出决策，在公司内部的其他开发进程中也使用内部开发工具。
3 数据管理
对海量的资源进行数据管理，尤其是在公司内部的任务安排到完成这一过程中的数据管理，对于游戏开发进程可谓是举足轻重。我们专为此项目的数据监控制作了一个网站，这样我们便可搜集信息，对总体开发进程进行系统化管理，从而最终使得数据管理能顺利进行。
之前我们的项目连中等规模都还算不上，所以当时的项目只是通过投入人力来解决数据管理问题。不过在FFXII项目中，我们则开发了相应的工具让用户可以直观地进行状态检查，其中也包括对开发密切相关部分进程的检查。
只要是参与过中等规模项目管理的人，都知道项目中很有必要有一种能够简单而有效地管理联络的工具。而如今，基础型的软件设定管理系统就能够让数据管理方便许多。但是在当时，能够凭自己的力量来制作一个自家的内部开发工具，我们已经很高兴了。
4 领导班子和人力资源配置
SE需要大规模地发掘人力资源来开发FF系列作品。但是项目规模一旦变大，那些处在领导位置的人就很容易产生盲点，忽视一些情况，这样会导致开发的瓶颈。
为了避免这个问题，公司让团队的好几个成员担当起了不同的领导位置。他们不仅要在自己的特长领域里努力表现，还要在自己的本职之外的其他许多位置上工作。许多优秀的团队成员也在开发当中涌现出来，并最终获得了晋升。
此外，这样的大型项目还有一个好处，就是开发组成员的个人关系网络得到了扩展。而且由于有更多的人进入了导演的视线，大家也可以拓展提高不同领域的技能。
结果，我们作为“第三团队”的地位得到了巩固，而且开发人员——当中许多是图像设计师——技能获得了极大提升。
5 在早期稳定了游戏系统
在开发的早期阶段，程序员就将稳定游戏的基本系统作为首要任务来抓。QA部门也在早期就开始了测试，不过这也是因为要在2004年的E3展上拿出一个可以试玩的ROM的缘故。虽然对游戏系统的各项设定的反对之声不绝于耳，但我们却完全无视，这样才让游戏总体系统很早就真正完全稳定下来。而这样的反对在之前的项目中时常发生。
对于QA部门来说，游戏系统稳定了就意味着他们可以把更多的精力集中在游戏本身的测试上，而且他们的工作也相当有意义。
失误之处
回顾FFXII的开发历程，我所意识到的问题可以大略分为两方面：计划安排和目标定位。首先，我们本该早些觉察到，这个项目（直到在工作日程安排上非常明显了才发现）超出了我们预想的规模。其次，项目的有些内容简直失去了控制，要实施的想法越来越多，但是资源和交流却没有随之增加。
虽然有使文章结构失去平衡的危险，我还是想把重心放到“失误之处”而不是“成功之处”上，因为纠正失误的过程对我这个研发部门总经理来说是非常有意义的。
就跟现实生活一样，开发游戏的过程中，一个人在克服困难时所学到的要比四平八稳时学到的要多。克服困难可谓是研发部门的真正核心工作所在。而通过所得的教训，我们也在公司内构建了新的体系。
1 不可预见性
FFXII开发中的重大挑战之一便是整合新的实时动作战斗系统。这项工作使得开发的难度呈几何级数增长。
公司里对于开发实时动作战斗系统以及传统的FF游戏都已经有了能力和经验。但是当我们这个新的团队想要将这两点融合起来时，大家早已预想了一个自认为会成功的理念。而同时，每个成员对于FF系列还有他们自己的想法。我们该做的，便是考虑这些想法，并建立测试模型和做出雏形来评估风险以及后果。而最终摆在我们面前的，却是一个在许多方面都充满不可预见性的结果。
我们无法决定从哪里来给相关部门分配工作量，或者对游戏进行部分改动会如何影响目前规划的游戏标准。最后，开发组陷入了不断的讨论和调整中。诸多质疑直接影响到了开发进度，从而对总体开发有了很严重的影响，并且还造成了各项事务的延迟，如规格的确定，游戏平衡度，还有QA队伍的组建等等，制作过程中的某些仓促决定也受此影响。
2 内部对开发施加压力
我们当时在工作环境中的压力可以比作一个装满了东西的高温压力锅。公司内过高的压力是SE作为一个整体都存在而且必须要面对的一个问题，而且这个问题在图像资源开发中尤为显著。
虽然说起来，在不断的求新求变中，SE提高了员工的技能和能动性，而且目前公司已经在声音-图像领域中取得了世界一流的地位，拥有海量的开发团队和他们不计其数的创意、技术和资源。但在FFXII开发过程中，成功的压力实在太过沉重，只要遇到一丝的误解我们就差不多要失控了。于是我们的团队便有了可以在开发的各个阶段做出更改的自由，但是这自由也带来了不利一面——沟通不畅、昏头昏脑。工作分配不清不楚也是个问题。
3 捉襟见肘
有了内部开发工具的协助，美工便能够在前期艺术设定时进行反复摸索修正，但是这并没有消除开发环境中存在的问题。
因为游戏制作周期过于漫长，潜在问题十分突出，内容流程也拖得很长，因此我们在设计时就不得不经常缩短“试错”检验的时间。我们在任务安排上一点错都不能犯，也没有时间去尝试有趣的新想法，尽管那可能给游戏设计带来更有趣的细节。
此后，因为重构了内容流程，用于分发的构建环境（distributed build environment）也进行了支持，系统得到了很大改善，但是在我们开发FFXII期间，这的确是一块巨大的绊脚石。
4 老一套行不通
因为在加入FFXII开发团队前，我开发过一个中等规模的项目，所以我起初是想用我之前所知晓的方式进行管理的。不管是就团队整体还是个人而言，我都觉得按照这个模式就能够获得成功。但事实却表明，我太依赖人对人的信息传递了。
由于FFXII项目规模十分庞大，我们需要更加系统化的信息交流方式来处理数据管理方面的问题。幸好我们还是注意到了因为系统不够完善导致沟通不便的现象。随着开发团队人数不断膨胀，我们重设了管理大规模数据的方法，于是交流不畅的问题尚未造成严重影响就已经得到了妥善解决。我们根据项目规模调整了管理方法。而这样废弃传统、建立新的系统来管理大量数据，才使我们最终走向了成功。
5 QA部门的难题
如我在“成功之处”章节所述，我们在开发早期就成功稳定了游戏系统。但是到了开发末期，QA部门却面临了巨大的难题。以往，出于对游戏复杂性以及容量的考虑，FF系列的游戏在debug和测试阶段都作了极其认真的组织。但是到了这个项目，系统的稳定却使开发问题的预测工作松懈下来。
我们错误估算了这样一个有实时动作战斗系统的游戏容量积累上升所需要的时间。先前Vagrant Story（游戏也采用了类似的战斗系统）的经验，到了FFXII这里也没有多大帮助。
此外，内部对开发团队施加的压力还导致了其他两个问题。第一，团队把精力投入到了纠错校正中，而这些校正造成了先前没有预见到的bug。这就使QA部门面临两难窘境：是努力达到质量要求呢，还是按进度安排操作呢？
第二个问题则是调整难度。早先开发团队似乎把某些区域调整得超出了FF系列所要求的难度，而本系列需要照顾到不怎么玩游戏的玩家。于是我们便收集并分析了测试者的第一印象来努力重新调整游戏平衡性。但到了最终阶段，我们已经没有足够时间来debug了。而且因为当时财年即将结束，我们无力雇更多的QA测试员，压力便显得更加沉重。之所以最后能够度过这道难关，全靠QA部门的不懈努力啊。
泼凉水（surprising water）
FFXII开发的最终阶段完全是抵抗内部压力的一场卓绝战役。为了写这片文章，我们还特意召集了主要的参加测试的玩家来开了个开发经验座谈会。在会上，游戏的设计导演伊藤裕之（Hiroyuki Ito）向大家讲述了以下的故事——
为了使他的开发团队不再膨胀，伊藤让他手下的策划停下已经在开发进度里拖后腿的探索任务部分。即便当时他们已经快要完成计划的开发进程了，伊藤还是下令让手下把这些东西完全抛弃。他这种休克疗法之所以能够成功，是因为他知道要完成这个游戏，目前完成的这些探索任务已经足够了，他也明白团队因此担负了太多艰难困苦。
伊藤承认，在亲口向团队说出“制作的这些资源全都不使用，减轻一下你们的负担”之前，他一直怀有疑虑。在日本，游戏项目的前期策划总是相当的多，而且到了最后也一般不会把素材砍掉。
在日本饮食文化中，在煮豆子时如果水开了，厨师会把凉水（surprising water）泼进锅里去，之后才会把豆子煮好。据说，把水温降低一会儿的话，吃起来嚼劲（resistance）会更足。砍掉完成的素材这种壮士断臂的大胆举措对于整个团队也有了相近的影响，从而带来了开发结束这一重要转折。
自然，并不是所有的部门都直接进行了这样强烈的改变。比如地图制作部门就不但成功地进行了软着陆，还添上了最后精彩的一笔。不过，对开发进程施压过大所造成的危险只能经由人为努力才能避免。如何改善这样的情况呢？这个问题将来一定要得到妥善解决。我们的话，恐怕要缓过劲之后才能够进行次世代游戏的开发了。
经验总结
本文写作之时，FFXII在全球出货已经超过了500万。开发团队的全体成员都为能够克服重重困难，制作出这样一款畅销全球的游戏感到由衷的自豪。此前从未尝试过的游戏系统将FF系列带到了一个新的高度，大家也为此而感到骄傲。
我之所以相信我们这个独特的团队能够成功，是因为我们奉行了独特的企业文化，而这样的企业文化在本公司之前的项目中也有所展现。
目前，我在SE的研发部门担任领导，这个部门的任务是应对将来我们更加充实和复杂的游戏内容，同时也在集中精力进行技术平台和基础技术的开发，藉此为玩家提供有趣的游戏体验。我参与FFXII这样大型的游戏的开发工作的经验对于集团的运作和制定将来的方针路线十分有用。
FFXII主要开发人员（照糊了 ）：
后排从左到右：片野尚志( Takashi Katano)，主程序和事件程序员。秋山淳（Jun Akiyama）事件导演。皆川裕史（Hiroshi Minagawa），视效导演。片冈和裕（Kazuhiro Kataoka），地图系统首席设计师，伊藤裕之（Hiroyuki Itoh），游戏设计导演。
前排从左到右：Yoshinori Tsuchida，实时渲染程序员。吉田明彦（Akihiko Yoshida），主要角色设计。村田琢（Taku Murata），监督。Hiroaki Kato，项目经理。
这文翻好真不容易= =到这一步为止好了，时间精力付不起……给杂志的叉包你，还有某某人，ありがとうございます……
原载于《Game Developer》2007年8月刊
游戏数据：
开发商：Square Enix
发行商：Square Enix
平台：PlayStation 2
发行时间：2006年10月31日（美版）/2006年3月16日（日版）
使用软件：Autodesk Maya, Softimage XSI, OPTPiX iMageStudio
怪物种类：250
Boss数量：30
NPC数量：1000
作者：村田琢（Taku Murata）
Square Enix（以下简称SE）有限公司研发总负责人，《最终幻想XII》（以下简称FFXII）监督，同时在公司的PlayOnline网络业务开发中也起到了很重要的作用。
翻译：otarma
FF系列乃是SE的一线知名游戏品牌。当我们预备开发十二代时，实际上有3款游戏可以算得上是其前作：FF IX、X、XI。这三款游戏都是同时在2000年1月的新闻发布会上公布的。
这三款游戏每一款是此系列的新篇章：FFIX是PlayStation平台上的最后一款FF，FFX是PlayStation 2平台上的第一款FF，FFXI则是SE的首款网络游戏，并且该游戏是PlayOnline网络业务的核心部分。
在我们着手开发FFXII的时候，FFX有了续作——FFX-2，于是FFX游戏制作组就原班上阵。同时，FFXI的业务取得的成功远超我们预期，于是FFXI制作组也就继续乘势开发后面的内容。
鉴于FFX和XI都在开发中，Final Fantasy Tactics（《最终幻想战略版》）和Vagrant Story（《放浪冒险谭》，又译《漂泊的故事》）的制作组便聚集到一起来制作FFXII，这便构成了第三个FF的家用机以及PC平台的制作组。
制作组的成员（包括我）都有过开发实时/动作战斗系统（action/real-time-based battle system）的经验，这样的系统让场景和战斗产生了互动。我们决定利用之前积累的经验，将实时动作战斗系统融入FF系列中。这可谓是巨大的挑战，因为此前发售的FF使用的都是随机遇敌的战斗系统。
于是项目便启动了。但很快，我们便遇到了各种问题，复杂得完全超出了之前的想象。整个开发的过程实在是让人学到了很多。
成功之处
1 崭新独特的开发团队
虽然我们名义上组建的是FF系列的第三个开发队伍，但实际上，所有的开发队伍构成并非停滞不变，他们在不断发展，而且人员组成也不断变化。
这个独特的新团队各个成员之前的多种多样的工作经历造就了不同以往的团体氛围。而队伍中还有许多成员从前从未参与过像FF这样一个开发经费充裕、人员规模巨大、花费时间漫长的游戏系列的开发——。
有新人加入可以说是“成功之处”，因为这样团队便可以从崭新的角度来审视开发进程，而且也利用到了新的技术。后者我会在下文详谈。
2 公司内部开发工具
“公司内部开发工具的使用”是我在2007年游戏开发者大会（Game Developers Conference）的演讲主题。我们有许多内部编写工具，再加上商业数字信息制作工具，比如Photoshop、Maya和Softimage XSI，一个良好的工作环境便形成了。我们可以在反复尝试新工具的同时通过使用已经熟稔的工具来提高生产率。
内部开发工具实在给工作带来了巨大的好处：我们可以使用游戏的渲染引擎进行实时预览。而且由于开发FFXII时内部开发工具效果不错，使得公司也做出决策，在公司内部的其他开发进程中也使用内部开发工具。
3 数据管理
对海量的资源进行数据管理，尤其是在公司内部的任务安排到完成这一过程中的数据管理，对于游戏开发进程可谓是举足轻重。我们专为此项目的数据监控制作了一个网站，这样我们便可搜集信息，对总体开发进程进行系统化管理，从而最终使得数据管理能顺利进行。
之前我们的项目连中等规模都还算不上，所以当时的项目只是通过投入人力来解决数据管理问题。不过在FFXII项目中，我们则开发了相应的工具让用户可以直观地进行状态检查，其中也包括对开发密切相关部分进程的检查。
只要是参与过中等规模项目管理的人，都知道项目中很有必要有一种能够简单而有效地管理联络的工具。而如今，基础型的软件设定管理系统就能够让数据管理方便许多。但是在当时，能够凭自己的力量来制作一个自家的内部开发工具，我们已经很高兴了。
4 领导班子和人力资源配置
SE需要大规模地发掘人力资源来开发FF系列作品。但是项目规模一旦变大，那些处在领导位置的人就很容易产生盲点，忽视一些情况，这样会导致开发的瓶颈。
为了避免这个问题，公司让团队的好几个成员担当起了不同的领导位置。他们不仅要在自己的特长领域里努力表现，还要在自己的本职之外的其他许多位置上工作。许多优秀的团队成员也在开发当中涌现出来，并最终获得了晋升。
此外，这样的大型项目还有一个好处，就是开发组成员的个人关系网络得到了扩展。而且由于有更多的人进入了导演的视线，大家也可以拓展提高不同领域的技能。
结果，我们作为“第三团队”的地位得到了巩固，而且开发人员——当中许多是图像设计师——技能获得了极大提升。
5 在早期稳定了游戏系统
在开发的早期阶段，程序员就将稳定游戏的基本系统作为首要任务来抓。QA部门也在早期就开始了测试，不过这也是因为要在2004年的E3展上拿出一个可以试玩的ROM的缘故。虽然对游戏系统的各项设定的反对之声不绝于耳，但我们却完全无视，这样才让游戏总体系统很早就真正完全稳定下来。而这样的反对在之前的项目中时常发生。
对于QA部门来说，游戏系统稳定了就意味着他们可以把更多的精力集中在游戏本身的测试上，而且他们的工作也相当有意义。
失误之处
回顾FFXII的开发历程，我所意识到的问题可以大略分为两方面：计划安排和目标定位。首先，我们本该早些觉察到，这个项目（直到在工作日程安排上非常明显了才发现）超出了我们预想的规模。其次，项目的有些内容简直失去了控制，要实施的想法越来越多，但是资源和交流却没有随之增加。
虽然有使文章结构失去平衡的危险，我还是想把重心放到“失误之处”而不是“成功之处”上，因为纠正失误的过程对我这个研发部门总经理来说是非常有意义的。
就跟现实生活一样，开发游戏的过程中，一个人在克服困难时所学到的要比四平八稳时学到的要多。克服困难可谓是研发部门的真正核心工作所在。而通过所得的教训，我们也在公司内构建了新的体系。
1 不可预见性
FFXII开发中的重大挑战之一便是整合新的实时动作战斗系统。这项工作使得开发的难度呈几何级数增长。
公司里对于开发实时动作战斗系统以及传统的FF游戏都已经有了能力和经验。但是当我们这个新的团队想要将这两点融合起来时，大家早已预想了一个自认为会成功的理念。而同时，每个成员对于FF系列还有他们自己的想法。我们该做的，便是考虑这些想法，并建立测试模型和做出雏形来评估风险以及后果。而最终摆在我们面前的，却是一个在许多方面都充满不可预见性的结果。
我们无法决定从哪里来给相关部门分配工作量，或者对游戏进行部分改动会如何影响目前规划的游戏标准。最后，开发组陷入了不断的讨论和调整中。诸多质疑直接影响到了开发进度，从而对总体开发有了很严重的影响，并且还造成了各项事务的延迟，如规格的确定，游戏平衡度，还有QA队伍的组建等等，制作过程中的某些仓促决定也受此影响。
2 内部对开发施加压力
我们当时在工作环境中的压力可以比作一个装满了东西的高温压力锅。公司内过高的压力是SE作为一个整体都存在而且必须要面对的一个问题，而且这个问题在图像资源开发中尤为显著。
虽然说起来，在不断的求新求变中，SE提高了员工的技能和能动性，而且目前公司已经在声音-图像领域中取得了世界一流的地位，拥有海量的开发团队和他们不计其数的创意、技术和资源。但在FFXII开发过程中，成功的压力实在太过沉重，只要遇到一丝的误解我们就差不多要失控了。于是我们的团队便有了可以在开发的各个阶段做出更改的自由，但是这自由也带来了不利一面——沟通不畅、昏头昏脑。工作分配不清不楚也是个问题。
3 捉襟见肘
有了内部开发工具的协助，美工便能够在前期艺术设定时进行反复摸索修正，但是这并没有消除开发环境中存在的问题。
因为游戏制作周期过于漫长，潜在问题十分突出，内容流程也拖得很长，因此我们在设计时就不得不经常缩短“试错”检验的时间。我们在任务安排上一点错都不能犯，也没有时间去尝试有趣的新想法，尽管那可能给游戏设计带来更有趣的细节。
此后，因为重构了内容流程，用于分发的构建环境（distributed build environment）也进行了支持，系统得到了很大改善，但是在我们开发FFXII期间，这的确是一块巨大的绊脚石。
4 老一套行不通
因为在加入FFXII开发团队前，我开发过一个中等规模的项目，所以我起初是想用我之前所知晓的方式进行管理的。不管是就团队整体还是个人而言，我都觉得按照这个模式就能够获得成功。但事实却表明，我太依赖人对人的信息传递了。
由于FFXII项目规模十分庞大，我们需要更加系统化的信息交流方式来处理数据管理方面的问题。幸好我们还是注意到了因为系统不够完善导致沟通不便的现象。随着开发团队人数不断膨胀，我们重设了管理大规模数据的方法，于是交流不畅的问题尚未造成严重影响就已经得到了妥善解决。我们根据项目规模调整了管理方法。而这样废弃传统、建立新的系统来管理大量数据，才使我们最终走向了成功。
5 QA部门的难题
如我在“成功之处”章节所述，我们在开发早期就成功稳定了游戏系统。但是到了开发末期，QA部门却面临了巨大的难题。以往，出于对游戏复杂性以及容量的考虑，FF系列的游戏在debug和测试阶段都作了极其认真的组织。但是到了这个项目，系统的稳定却使开发问题的预测工作松懈下来。
我们错误估算了这样一个有实时动作战斗系统的游戏容量积累上升所需要的时间。先前Vagrant Story（游戏也采用了类似的战斗系统）的经验，到了FFXII这里也没有多大帮助。
此外，内部对开发团队施加的压力还导致了其他两个问题。第一，团队把精力投入到了纠错校正中，而这些校正造成了先前没有预见到的bug。这就使QA部门面临两难窘境：是努力达到质量要求呢，还是按进度安排操作呢？
第二个问题则是调整难度。早先开发团队似乎把某些区域调整得超出了FF系列所要求的难度，而本系列需要照顾到不怎么玩游戏的玩家。于是我们便收集并分析了测试者的第一印象来努力重新调整游戏平衡性。但到了最终阶段，我们已经没有足够时间来debug了。而且因为当时财年即将结束，我们无力雇更多的QA测试员，压力便显得更加沉重。之所以最后能够度过这道难关，全靠QA部门的不懈努力啊。
泼凉水（surprising water）
FFXII开发的最终阶段完全是抵抗内部压力的一场卓绝战役。为了写这片文章，我们还特意召集了主要的参加测试的玩家来开了个开发经验座谈会。在会上，游戏的设计导演伊藤裕之（Hiroyuki Ito）向大家讲述了以下的故事——
为了使他的开发团队不再膨胀，伊藤让他手下的策划停下已经在开发进度里拖后腿的探索任务部分。即便当时他们已经快要完成计划的开发进程了，伊藤还是下令让手下把这些东西完全抛弃。他这种休克疗法之所以能够成功，是因为他知道要完成这个游戏，目前完成的这些探索任务已经足够了，他也明白团队因此担负了太多艰难困苦。
伊藤承认，在亲口向团队说出“制作的这些资源全都不使用，减轻一下你们的负担”之前，他一直怀有疑虑。在日本，游戏项目的前期策划总是相当的多，而且到了最后也一般不会把素材砍掉。
在日本饮食文化中，在煮豆子时如果水开了，厨师会把凉水（surprising water）泼进锅里去，之后才会把豆子煮好。据说，把水温降低一会儿的话，吃起来嚼劲（resistance）会更足。砍掉完成的素材这种壮士断臂的大胆举措对于整个团队也有了相近的影响，从而带来了开发结束这一重要转折。
自然，并不是所有的部门都直接进行了这样强烈的改变。比如地图制作部门就不但成功地进行了软着陆，还添上了最后精彩的一笔。不过，对开发进程施压过大所造成的危险只能经由人为努力才能避免。如何改善这样的情况呢？这个问题将来一定要得到妥善解决。我们的话，恐怕要缓过劲之后才能够进行次世代游戏的开发了。
经验总结
本文写作之时，FFXII在全球出货已经超过了500万。开发团队的全体成员都为能够克服重重困难，制作出这样一款畅销全球的游戏感到由衷的自豪。此前从未尝试过的游戏系统将FF系列带到了一个新的高度，大家也为此而感到骄傲。
我之所以相信我们这个独特的团队能够成功，是因为我们奉行了独特的企业文化，而这样的企业文化在本公司之前的项目中也有所展现。
目前，我在SE的研发部门担任领导，这个部门的任务是应对将来我们更加充实和复杂的游戏内容，同时也在集中精力进行技术平台和基础技术的开发，藉此为玩家提供有趣的游戏体验。我参与FFXII这样大型的游戏的开发工作的经验对于集团的运作和制定将来的方针路线十分有用。
FFXII主要开发人员（照糊了 ）：
后排从左到右：片野尚志( Takashi Katano)，主程序和事件程序员。秋山淳（Jun Akiyama）事件导演。皆川裕史（Hiroshi Minagawa），视效导演。片冈和裕（Kazuhiro Kataoka），地图系统首席设计师，伊藤裕之（Hiroyuki Itoh），游戏设计导演。
前排从左到右：Yoshinori Tsuchida，实时渲染程序员。吉田明彦（Akihiko Yoshida），主要角色设计。村田琢（Taku Murata），监督。Hiroaki Kato，项目经理。
这文翻好真不容易= =到这一步为止好了，时间精力付不起……给杂志的叉包你，还有某某人，ありがとうございます……