原文标题：【CEDEC 24】《萨尔达传说 王国之泪》打造“可动的规格书”重构开发环境
原文网址：https://gnn.gamer.com.tw/detail.php?sn=273545
让开发团队全员都深入了解游戏整体，并不论担任职务都可以提出点子的平行制作手法。
为了实现这种理想，所以下定决心重新建构游戏的开发环境。在日本游戏开发者会议“
CEDEC2024”最后一天，有一场以“了解、创作、连结 在《萨尔达传说 王国之泪》中重
新建构的开发环境与音效制作案例”为题的讲座，在其中解说了任天堂开发团队实际制作
的案例。
https://p2.bahamut.com.tw/B/2KU/45/e43a4b0df6c593f30f434dd7e11rdld5.JPG
登台主讲
冈村祐一郎（任天堂 企画制作部 首席程式设计师）
长田润也（任天堂 企画制作部 音效程式设计负责人）
日高祥藏（任天堂 企画制作部 游戏制作工具开发负责人）
https://p2.bahamut.com.tw/B/2KU/46/c16c7d18d53da7bfc7bb0c2d361rdle5.JPG
为了实现平行式创作手法，决定完全翻新开发环境
过去在开发游戏时，因为开发规模都比较小，所以进行决策时的节奏轻快，在沟通交流方
面比很顺畅，但近年来因为游戏开发规模不断在膨胀的关系，技术的分枝数量增加，开发
时的分工合作也变得更细腻。
想要在这种环境下创作游戏，通常就会采用让各个部门的领袖人物下去思考游戏制作方针
，再分配工作给各个部下的所谓由上至下的创作手法。
只不过在《萨尔达传说 王国之泪》（以下简称为《王国之泪》）的开发工作当中，却是
以“团队所有人都可以构思游戏开发方向并不断尝试的平行式创作手法”为目标。可能会
看到美术设计师在考虑到游戏平衡的前提下去设计新招式这种情况发生，是一种不论担任
什么职务都可以尽情提出自己创意点子的制作手法。
虽然团队当中当然还是会有领袖人物存在，但开发团队是认为，能够让每一个人都像过去
那个时代一样亲自参与创作过程，应该是更容易激出发优秀的点子才对。
https://p2.bahamut.com.tw/B/2KU/48/536c946014f558c40c1f2251931rdlg5.JPG
https://p2.bahamut.com.tw/B/2KU/49/6934aee546b36f3b21077535f81rdlh5.JPG
https://p2.bahamut.com.tw/B/2KU/50/8645b5e56cc20f26a2838156141rdli5.JPG
https://p2.bahamut.com.tw/B/2KU/51/555979c8714687e94f1f18e1511rdlj5.JPG
为了达成这个理想，重点就是必须要让担任各种不同职务的成员，都能够清楚了解到自己
正在制作一款什么样的游戏，冈村祐一良表示在达到这个前提之后，才能够去“创作”。
虽然后面还会再次提到，但大家可以注意在这边主讲者并不是用“制作”，而是包含了创
造性在内的“创作”字眼，可以从中感受到其重点所在。
https://p2.bahamut.com.tw/B/2KU/52/2587329de780b1b480b22131ee1rdlk5.JPG
想要了解游戏，可以游玩正在开发中的版本，请教其他的开发者，又或者是阅读规格书等
等不同的手段存在。只不过光是游玩，常常会没有办法完全把握规格，而想要找人请教，
又必须要该部份的负责人刚好有空才可以，就算是去阅读规格书，也会碰上加入游戏时采
用的规格其实并不一样的案例。
想要实现平行式创作手法，由于游戏在开发过程中会不断变化的关系，所以让实现的难度
也随之提升。在前作《萨尔达传说 旷野之息》（以下简称为《旷野之息》）当中，是采
用将游戏各方面的动作方法和数值等，原本会以规格书说明的部份转化为资料，以资料驱
动式手法进行开发。
将从资料中读取到的情报，制作出表格、圆饼图或者是投影片等视觉化资料，并且同时去
游玩游戏。透过这种兼并两者方式的“可动规格书”下去了解游戏，然后再连结到创作行
动上。另外冈村祐一郎特别强调“这并不是指不应该要去制作出规格书”，是表示规格书
虽然可以用来整理游戏开发者脑海当中的想法，但是并不适合用来了解关于游戏的最新情
报。
https://p2.bahamut.com.tw/B/2KU/53/6e67984d5e3c5133988e4e6ce51rdll5.JPG
https://p2.bahamut.com.tw/B/2KU/54/9943daeaf151d0a2c05af4d2621rdlm5.JPG
https://p2.bahamut.com.tw/B/2KU/55/a63c486d58f3c4775e616725b31rdln5.JPG
https://p2.bahamut.com.tw/B/2KU/56/9ec380f7680faf376e1fbea6621rdlo5.JPG
在现在一般的游戏开发过程当中，通常是由核心团队利用共通的框架去制作出各种不同开
发工具，打造出整合型开发工具让大家使用，但是在《旷野之息》当中，其实是采用每一
个不同的部份，全都使用不一样的程式语言和技术去制作的综合组成方式。
虽然这是一种比起整合型开发工具来说，较为古老的开发手法，但同时也有柔软性更高，
更容易去应对各式各样不同游戏设计的长处。因为只要有构想，不管是谁都可以下去制作
开发工具，所以更容易激发出全新的点子，也比较容易采用全新技术来累积不同的经验，
促进开发团队成员的技能成长，其实有相当多不同的长处。
比如说在开发《健身环大冒险》时制作出来的记录用工具，就有转用到其他游戏开发工作
的成果。
但是另一方面，综合组成方式与整合型开发工具相比之下，各个开发工具之间的连结力较
弱。有时候想要在某个开发工具里加入一个方便使用的功能，就必须要去解析另一个不同
开发工具的情报才行。而且为了要了解游戏整体的架构，就必须要同时使用复数不同开发
工具，并且去理解各个资料之间的连结才可以。
而且《旷野之息》的开发工具，因为将加入速度摆在第一优先的关系，有些工具其实没有
什么扩充的空间可言。再加上《王国之泪》的游戏内容与前作相比之下更加复杂，内容量
自然也变得更为庞大。
于是包含冈村祐一郎在内的开发团队成员，就决定要从头打造一个全新的开发环境。开始
制作设置在各个开发者电脑里的“本地数据库（LocalDB）”、用来管理资料版本的“公
用数据库（GlobalDB）”，以及让各资料之间连结视觉化的“专案入口（Project Portal
）”等等开发工具程式。
https://p2.bahamut.com.tw/B/2KU/57/a936383f8cc94a388cffc04c9c1rdlp5.JPG
https://p2.bahamut.com.tw/B/2KU/58/8b55e35bdfaee1c0b4f6f87b941rdlq5.JPG
https://p2.bahamut.com.tw/B/2KU/59/9a74771cd047127d1b5183cd391rdlr5.JPG
https://p2.bahamut.com.tw/B/2KU/61/55f6fde2b1a321e37915672da41rdlt5.JPG
使用数据库来连结不同的开发工具以及每个人的作业进度
“本地数据库”是为了解决旧有开发环境的问题之一，也就是各开发工具之间连结力较弱
这个问题的工具。基本构想是先准备作为所有开发工具共用基础来使用的数据库，让开发
工具透过数据库去读取各种档案。只不过单纯只是准备一个数据库，开发第一线人员也不
会去使用。于是就采用了能够利用在各种不同程式上面的 SQL 工具，让不管是使用什么
开发工具，都可以直接读取到数据库里面的档案。
另外关于要在数据库里写入各种情报的时候，基本上是让有最了解该档案的人会下去执行
这个动作。比如说如果是游戏的 3D 模型，那就是由 3D 模型工具的开发者下去将资料登
录到数据库里面。
虽然这样的确会增加特定开发者的工作量，但是因为数据库成为可以共用的基础部份，所
以即使会有复数开发工具都需要使用到 3D 模型，也就不用再分开来一一去应对，因此反
而能够降低整体的负担。
https://p2.bahamut.com.tw/B/2KU/62/4d440d737afa8876a4615d28b31rdlu5.JPG
https://p2.bahamut.com.tw/B/2KU/64/903ce7af843ee34b3c74d179101rdlw5.JPG
https://p2.bahamut.com.tw/B/2KU/65/46b87db46654392e9b91daac721rdlx5.JPG
只不过话虽如此，但即使是对该项档案最了解的人，实际上也很难去预测其他不同开发工
具，会需要哪一些项目的资料。而且如果采用有人提出需求，就一一去对应该项目的方式
，那反而又会增加负担，并不现实。
于是就决定在制作“本地数据库”的时候，采用加入“尽可能多种不同的资料”这种方针
。举例来说像是 3D 模型的档案，就会记载包含顶点数量、骨架的名称以及原型骨架、材
质名称和使用着色器……等等，数据库里面记载的项目越多，就越方便其他开发者尝试各
种不同的方案。
虽然在构思不同点子的时候，很难事前去预测会让人想要对哪些项目动手调整，但只要事
先记载好尽可能多样化的资料，那就能够立刻对应突如其来的发想。
而且会记载在数据库里面的资料，包含 3D 模式、材质、关卡、事件、演员、特效、动画
、数值以及背景音乐等等构成游戏的档案，还有用来制作这些档案的 Maya 的 .ma 档案
、 Photoshop 的 .psd 档案，以及各项程式的源代码等等，有各种不同种类的资料，可
说是包罗万象（只不过像是顶点串流（Vertex stream）之类巨大的资料就会被视为例外
）。
https://p2.bahamut.com.tw/B/2KU/67/a9ce0a10e64ad5b16e73e353691rdlz5.JPG
不过就在这样建构数据库的过程当中，有人提出了“那数据库应该要设置在哪里”这个问
题。一般来说通常会把数据库设置在服务器上面，让每人个使用自己的电脑去读取数据库
。只不过在开发过程中进行各种作业需要使用的档案，基本上是放在每个人自己的电脑里
面，而且还会因为开发游戏时出现的不同构想持续加入变动。
这也就是说就算是同一份档案，也会因为每一个人作业进度不同而产生差异，这样子自然
就会让每个人依照自己想法加入的变更，与服务器上的档案版本发生冲突，产生“同一份
档案却有复数不同版本，那到底是谁的版本才正确？”，这个在游戏开发过程中大家都很
熟悉的问题。
于是日高祥藏就表示，这时候就必须要换一个想法。既然每一个人在开发过程中都需要进
行不同的作业，那么就让每一个人都有专属于自己的数据库不就好了吗……在这个想法当
作前提之下，最后就采用了在每一个人的电脑里面，都设置一个存在于本地的数据库这种
做法。而因为是存在本地的数据库，所以就命名为“本地数据库”。
https://p2.bahamut.com.tw/B/2KU/68/f5498b47691f120224e258af011rdm05.JPG
https://p2.bahamut.com.tw/B/2KU/69/7cc5f99f5e178e1e0a4c29eb3a1rdm15.JPG
https://p2.bahamut.com.tw/B/2KU/70/0661c17a8fa0ba8f45dd8007e11rdm25.JPG
但虽然说是存在本地，可是每一个人的数据库都还是有互相连结。而且各种开发工具，也
会透过数据库互相连结。比如说有人使用 Maya 编辑某个角色模型并且更改了骨架的名称
，那有用到这个骨架名称的其他工具，也会更新资料将这个全新的名称覆写上去。
而且其他开发者只要有变更档案内容，并且使用版本管理系统的话，这些变更也会反应到
自己的档案里面。这样就不用去判断到底谁的版本才正确，而是最新的变更会持续反应到
所有人持有的档案当中。
只不过在这个系统里，为了要提升反应速度，所以刻意排除了不需要的档案。所以因为对
自己担任职务没有必要性，因此没有存在本地数据库里的档案，就没有办法下去更改。
然而就算是这样说，有时也是会需要用到这些档案，于是就决定要在“本地数据库”的系
统中，准备一个设置在服务器上面的共用型数据库，也就是“公用数据库”来管理各种不
同档案的版本资料。所以在想要使用自己手头上没有的档案时，就可以连进“公用数据库
”里面去读取这些档案。
https://p2.bahamut.com.tw/B/2KU/71/19920e60ddefff44f7352381381rdm35.JPG
https://p2.bahamut.com.tw/B/2KU/72/8714c5f14b3465b6343e0c4d1c1rdm45.JPG
https://p2.bahamut.com.tw/B/2KU/73/728db2a3cf0e1545bdf26ce2f61rdm55.JPG
https://p2.bahamut.com.tw/B/2KU/74/acce08486d2b893b5052de829f1rdm65.JPG
以“本地数据库”和“公用数据库”，解决了开发工具之间连结力较弱的问题。
那现在就要开始处理另外一个问题，也就是“无法理解游戏构造”。因为游戏十分复杂，
会记录在“本地数据库”里的情报量十分庞大的关系，很难只看这些情报就去了解到整体
游戏的构造。
但既然如此就应该要去适当处理分类这些情报，所以就开始构想出一个可以选择资料的种
类，并且尽可能缩限要读取的情报范围，让使用者可以去追查资料与资料之间关联的开发
工具，而这就是让资料关联视觉化的“专案入口”。
https://p2.bahamut.com.tw/B/2KU/75/c38bb69e4d9bbad9a5e21070451rdm75.JPG
在“专案入口”可以筛选想要寻找的资料种类，并且靠资料名称以及加在各个资料上的标
签来进行搜寻。
比如说以“大师之剑（マスターソード）”当关键字进行搜寻，除了大师之剑本身以外，
还会看到剑鞘以及台座等关联项目也列在搜寻结果的清单里，如果是想要找会被雷劈到的
武器，那就可以使用“金属制”这个标签来筛选要搜寻的范围。
而且因为标签本身也可以加入各式各样的条件来进行筛选，所以就准备了相当庞大数量的
标签。就和前面提到的“本地数据库”里要刊载的档案种类一样，加入的标签数量越多，
就越能够灵活对应每个人发挥出来的创意构想。
在加入的标签当中，还有“前作就存在的武器”、“会从宝箱掉出来的武器”、“拿弓箭
的敌人”、“会遇见敌人的 NPC 角色”以及“会出现在神殿的设置物件”等等，可以看
出开发团队为了要打造一个让人可以进行“创作”的环境，付出了多少努力。
只不过正因为标签十分详细而且又多样化，所以要靠人手去加入标签就有极限存在。于是
在“专案入口”这个开发工具当中，就会把演员（在这里指会出现在游戏中的物件）的数
值也全部都当作是标签来处理。
由于演员的性质会在资料内以数值化的方式来记载（比如说像是可以燃烧的演员，就会设
定一个可以燃烧的数值），所以只要将这些数值当作标签对 SQL 送出请求就好。
这个在“专案入口”的设定中被称为“请求标签”，和一般的标签一起搭配运用，就可以
使用十分复杂的条件来进行筛选。
应该可以说是参考自己想要使用的条件数值，直接去产生一个可以在当下使用的标签吧。
也因为有这个设计，所以关于会使用数值来记载的性质，就不需要以人力来主动去加上标
签了。
https://p2.bahamut.com.tw/B/2KU/76/10abc7d5cf39d4ba43f2b828d01rdm85.JPG
https://p2.bahamut.com.tw/B/2KU/77/59e6078c31630535a45086b8581rdm95.JPG
https://p2.bahamut.com.tw/B/2KU/78/5a03bdbcb65921e10b34ca901d1rdma5.JPG
https://p2.bahamut.com.tw/B/2KU/80/e5f6a71536f3e4650386d503751rdmc5.JPG
然后为了要把握游戏的构造，还制作出可以直接看到资料之间连结（参考关系）的功能。
参考关系的箭头在依照事件→演员→模型设定……这样顺向来表现时，直接使用一般的树
状图就可以，但是要显示出逆向树状图的时候，就会发生可能会显示出重复资料的问题，
于是就采用在显示逆向关系的时候，改用清单方式的手法。
https://p2.bahamut.com.tw/B/2KU/81/4ea5f59e556a915f60035580281rdmd5.JPG
https://p2.bahamut.com.tw/B/2KU/83/2edc26746709d1229ac38ad1971rdmf5.JPG
而就演员和物理设定以及 3D 模型这种没有直接关联（离散程度较高）的资料来说，则是
提供了可以查询各自资料的连结，取得必要情报后显示成一览表的功能。
比如说宝箱的配置情报，与放在里面的演员，还有演员的卖价，这些原本应该是写在不同
档案里面的情报，就会加工为一览表，并且加上可以直接跳到情报所在位置的按钮。
另外就波克布林（ボコブリン）来说，在演员表格里面会有名称和内容标签，而在 3D 模
型表格里会有名称和边界框架，在物理设定表格里则是会记载质量，在这种情况下只要使
用 SQL 就可以制造出将名称、产生出的缩图与边界框架、质量一览表，以及除错产生用
的按钮都一字排开的一览表。
本来应该要自己去参考每一个不同的资料，从中去理解资料之间的连结，但是透过“专案
入口”就可以加工成一览表，提供让人可以马上就参考所有关联资料的按钮。
这样子就可以量产出 SQL 或者是加工方法，于是就把这个功能称为“资源表格”。当然
像这类试算表也可以直接用人手制作，但是自动化生产一定比较少会出现失误。
https://p2.bahamut.com.tw/B/2KU/84/f98eda06597cee8f9498974bbb1rdmg5.JPG
https://p2.bahamut.com.tw/B/2KU/86/1b60c9f856200fdb2c9b0ab65f1rdmi5.JPG
https://p2.bahamut.com.tw/B/2KU/87/6617171cb1f46c81147a9780a91rdmj5.JPG
利用“本地数据库”和“专案入口”，制作音效演出细节
接下来登台的长田润也，则是以音效团队的角度，举出实例来解说活用“本地数据库”和
“专案入口”的范例。
由于音效团队工作性质之故，通常都是在游戏开发后期才开始动工，但团队一直都有希望
可以在早期就开始主动参与游戏制作的想法。只要有“本地数据库”和“专案入口”这两
个开发工具，就可以在播放动画片段的同时加入音效，又或者是介接到用来编辑动画资料
的开发工具上。
而且还有加入在其他开发者变更动画资料的时候，就会自动通知关联音效制作者的设计，
让整体作业效率有明显提升。
https://p2.bahamut.com.tw/B/2KU/88/598293de6f43ffb114ebd6f7531rdmk5.JPG
https://p2.bahamut.com.tw/B/2KU/89/a24ff0e624a0affe8aada446321rdml5.JPG
而且在格鲁德小镇（ゲルドの街）防卫战这个游戏事件中，还能够让音效演出变得更加紧
密。由于这在游戏故事上也是一个十分重要的场面，所以就有人提出希望可以加入依照战
斗当下状况，让音效出现变化的演出这种提案。
于是就在利用“专案入口”仔细把握这个事件的规格之后，成功加入了在适当的时机去切
换战斗背景音乐，以及每一次破坏吉波得（ギブド）巢穴时乐曲都会发生变化等等，更具
有互动性的演出手法。
而在本作中玩家使用的武器，可以透过“余料建造（スクラビルド）”黏贴上不同素材甚
至是其他的武器，每次黏贴后音效都会出现变化，设计可说是十分复杂，而在这方面“专
案入口”也是帮上很大的忙。
虽然只调查余料建造的数值，也很难去了解比如说是用什么方式黏贴上哪一种道具，也就
是整体产生了什么样的变化，但只要利用在“专案入口”当中，为了方便游戏设计师调整
数值而加入的预览，就可以完全理解当下使用的武器规格。
虽然说有的时候，在使用余料建造黏贴上素材前后，音效也不会出现变化，但只要透过“
专案入口”调查，就可以马上了解到这是刻意为之的设定，还是单纯设定时出现失误。
长田润也表示，“专案入口”可以说是一个可信度极高的情报收集基础建设工具，让团队
能够放心打造游戏细节到最后一刻，给这项开发工具相当高的评价。
https://p2.bahamut.com.tw/B/2KU/90/0f75556b05c0b4be9a4ba5c4b21rdmm5.JPG
https://p2.bahamut.com.tw/B/2KU/91/c5f6b7f8af839d20c4bd524fb41rdmn5.JPG
https://p2.bahamut.com.tw/B/2KU/92/96cf0638a05cc28c2e4a019fda1rdmo5.JPG
https://p2.bahamut.com.tw/B/2KU/93/8b20ab7b5a706cccd8dd1ca9dc1rdmp5.JPG
让参与开发的所有开发者，不论其职务都可以提出点子，透过从不同视角出发的创意发想
让游戏变得更加完善……这应该是游戏开发工作的理想状态之一。然而当专案规模越变越
庞大，距离这种理想也就越来越远。可以说在《王国之泪》的开发工作当中，就是透过打
造出各种不同的开发工具，尽最大努力去维持这种理想的状态。
在近年来所谓 3A 大作当道，因为大规模游戏作品成为主流，让开发工作越来越高度分工
的时代里，负责游戏末端工程的开发者，真的是很难去把握游戏的全貌，实际上也有人指
出这种状况，甚至会影响到开发者投入开发游戏的动力，本次讲座中讲解的这些工具，从
笔者个人角度来看，也明确感受到是一种能够去解决这种问题的手法。
虽然这只是笔者个人的感想，但是冈村祐一郎在这场讲座当中，会特别强调“创作”这个
用字，而不是单纯使用“制作”，应该就是想要强调大家不应该只把游戏开发当作一种工
作，只是机械性地去投入制作，而是要在其中加入创意发想去完成一场创作才对。
从不同职务角度出发能看到的事情不同，所以能够催生出的点子也不一样。如果能够透过
自己本身职务特有的观点和创造性，去参与游戏开发工作的话，想当然是一定可以大幅提
升开发第一线人员的士气才对吧。
正如同冈村祐一郎本人指出的一样，就算是采用让领导人物决定一切的由上至下方式，还
是可以顺利完成游戏开发。而且即使费尽苦心开发出一大堆开发工具，也不能保证一定可
以完成比由上至下方式还要出色的游戏。只不过《王国之泪》即使是如此，依然选择了这
条要克服许多难关的道路。
本作之所以能够在全世界各个国家，让各个不同年龄层的玩家都给予极高评价，应该就是
因为费的这些苦功，的确有开花结果获得成效的关系才对吧。当然这绝对不是一种能够马
上就让所有游戏开发现场模彷的手法，但是就在必须要在截止期限之前完成游戏的现实考
验当中，还能够坚持要去追求理想，的确是件让人感觉到十分精彩感动的事情。
https://p2.bahamut.com.tw/B/2KU/94/d5d0f446ed13b67a855d3089891rdmq5.JPG

卡

有些概念在资策会的课程也有听过就是不知道台湾的游戏业落实到什么程度

鬼

厉害欸

干那PM要超猛...

老任的专案管理真的超猛

先跪

设计出这种做法感觉也是很花钱花时间花精力，真不愧是充斥着鬼才的任天堂

SVN++?

某些有点像git的概念 但又更贴近游戏设计 厉害

鬼

猛

竟然能结合不同程式语言的个别开发成果，老任真的有黑科技。（褒

这种技术老任愿意分享真的好猛*技术概念跟心得

这pm有点猛

鬼神般的专案管理因为他们其实也知道这些他们认为基本的东西别人也学不来吧

老任的游戏理念一直都是“共荣”的，抓一堆专利在手上却不私藏也不拿来赚钱，只为了让大家都能轻松用上他们的专利来开发游戏，这样才能一直有心血注入，作为三大主机厂中唯一一个游戏专门，才能不断推出新游戏

其实还是有啦 十字键专利还在的时候是收钱的当时DC的控制器就有付钱

真的很感动 原来是这样制作出来的 能实践这种管理真的要超猛

并不是不藏私，而是大部分这些概念都不是新东西理想中的最佳结构，但实际要实行是会被白眼说"做梦比较快"，然后任天堂她妈真的办到了*这种规模下要实行他们的PM到底是什么妖魔鬼怪

没有相关业界经验，看不懂欸

能够确切执行真的很厉害相关经验能够传承并应用在其他游戏上也很厉害某些游戏公司明明有上一代开发经验了还是要从头到尾再踩一次

讲解的也太细了，这就是所谓的把饼做大吗...

天下第一高手不藏私，广发九阴真经抄本的感觉

老任：就是基本功而已，我们没什么特别的，只是普通的做游戏，说不定下一个超越任天堂的工作室正呱呱落地

这是什么鬼(称赞语调

任天堂系统厉害

这是管理学教材吗？

我知道了，任天堂PM最强

老任，真的好强

有当过工程师都知道他们讲的这些一般公司根本不可能做到

这是个很鬼神的管理系统... 反正别人抄不起来

推个，跟鬼一样

收下我的膝盖

推详尽的介绍说明

任天堂PM是鬼

又要被抄了

理想很丰满，现实很骨感，任天堂能兼顾真的是鬼

超鬼，就我的想像把这个系统做出来可能还好，但管理跟维护里面的资料怎么想都超难的

台湾由上而下: BOSS (一页PPT > 一份PPT > gitlab) RD

任天堂教你做游戏

看了真是有点想哭

其实对专案来说很基本 但现实几乎难以实践的东西现实都是陨石式开发然后版本数据库对不起来 ：（

推

越大的专案项目管理越重要

基础概念不难懂 小团队实践也不难 但这是鬼扯的破200人大型专案阿 真的只能跪着看

这个系统的架构和管理的人真的是神鬼来着