天美策划：技术策划该如何摆脱工具人的设定？

技术策划是干什么的？这个职位会长期存在吗？

为了尝试搞清楚这些问题，近日腾讯游戏学堂联合天美工作室群，在知乎举办了“游戏是门技术活”主题圆桌，邀请游戏从业者探讨了“游戏技术策划核心竞争力是什么？在团队中能够起到怎样的关键作用？”的行业话题。

以下为圆桌部分讨论内容的摘录：

“像一家帮助游戏项目通往

目的地的旅行机构”

答者：菠萝王子

腾讯天美F1工作室高级技术策划

说到技术策划，大家会发现这个岗位也就是在最近 1-2 年里开始兴起，所以首先可能会好奇为什么最近突然间会冒出这样一个岗位？

目前游戏行业立项了大量的开放世界向/3A 向的项目，高复杂、高精细、重叙事、重细节的游戏项目开始成为主流。同时，比起以往我们开发的常规手机游戏相比，现在 3A 类游戏的设计纵向带宽被大幅增加。从游戏设计方案到功能制作完成落地，一个功能模块的细节设计量已经大幅提高。

比如同样是按下一个攻击键，在红白机的《小蜜蜂》上，玩家按下按钮后，子弹直接就飞了出来；而在《战神》里，同是按下攻击按键，这个攻击动作就会涉及到前摇、碰撞判定、后摇、Combo、打断与取消、受击与霸体等等一系列的细节设计。

同样是攻击功能模块，但是它的设计纵向带宽已非同日而语，每一模块和特性都需要深入的细节设计。

在现在的分工中，技术策划聚焦解决这些需要细节设计的模块，所以技术策划是服务于特性的，比如对于 3A 游戏开发里常有的 3C 线、摄像机线、AI 线、战斗线、叙事线、关卡事件线、动画线、工具线等等。每个项目方向不一样，就会导致特性不一样，从而对技术策划的需求也会有些区别。

在这样的分工下，策划本身可以更聚焦于设计的目的性（为什么要设计这个）以及系统性（增加这个设计对其他设计的影响，它在整个设计体系中的定位和权重），而程序也可以更聚焦在代码和底层，提高代码的稳定性以及程序员使用效率。

为了更清晰地说明技术策划在团队中的分工与价值，我也想用旅游来做一个比喻。

图源《微软模拟飞行》

我们在旅行前，一般都会做规划。而当准备去的地方比较遥远和陌生的时候，一些人还会考虑寻求旅游机构的帮助。

在这样的合作中，游戏策划就像是旅行者。旅行者对于旅行有具体的目标，比如去哪里玩、玩几天、大概什么时候出发、想要获得什么体验等等。

技术策划则更像是旅游机构。旅游机构会根据旅行者的需求，去做一个旅行方案。

比如机构会考虑到旅行者的工作性质，尽量把双休日安排进行程；在旅游路线的设计上，也会尽可能把景点以更效率的方式安排在一起。目的都是为了帮助旅行者提高游玩效率，获得更好的旅游体验。

在两方配合下，作为旅行者的策划就可以更聚焦在旅游的目的与意义上，即游戏设计中的目的和系统统筹。

作为旅游机构的技术策划，则聚焦于方案设计层面，即如何达到设计目标，如何获得更完美的体验，如何把设计尽可能完美落地。

此时有人可能会说：我不需要旅游机构，可以自己做攻略啊！

没错，对大部分人来说，如果只是去距离近、甚至熟悉的目的地，我们并不需要找人来做方案。同理，对于体量小、复杂度低的游戏项目，团队也的确不一定需要技术策划。

这也是为什么在体量大、复杂度高、相对陌生的项目中，技术策划才会有更好的发挥空间。

不过大家有没有过这个体验？我们经常兴致勃勃地做完旅游攻略，但在实际玩耍过程中，发现各种安排无法落地，导致一些行程泡汤。

现在做游戏也是这样。一方面，当游戏注重细节、体验的时候，策划的设计方案不可能把所有细节都完整写在案子中，加之更好的游戏体验设计本身就需要在迭代中发现。

另一方面，传统程序更多专注代码本身，在迭代策划纸面需求的时候，相较于策划，程序对于设计的理解可能会有偏差，导致迭代效率偏低。

这样的沟通壁垒，会导致团队在开发游戏的过程中，常常遇到策划觉得方案没问题，但落地了就是和想象的不一样的局面。

在大型项目中，技术策划就是策划与程序之间的重要桥梁。我下面将用两张图具体展示技术策划是如何配合策划与程序来推进工作的。

第一张为横向的结构铺开，大家可以看到在这样的结构下，一个策划在能力模型支持的情况下，可以同时负责多个特性的设计工作推进，更聚焦以及思考设计本身，而对于程序也可以大幅提高一个程序人员对多个特性的全面支持（到了程序底层层面，不涉及到游戏设计，大部分游戏程序员都是能互通支持）。

第二张图是以相机特性线为例，展示纵向单一条线，技术策划是如何开展工作内容的拆分，以实现从纸面设计到最终的功能体验落地的全流程。

红色部分为策划负责的工作，蓝色为技术策划负责的工作，黄色为程序负责的工作。

结合上图的技术策划职责，以及工作流程中与程序和策划的工作流，我们再谈谈技术策划的三条核心竞争力（这里只罗列了最重要的三条）：

第一：丰富的游戏设计能力与体验细节落地经验。这点是所有竞争力里最重要的，也是最终决定技术策划的天花板的能力。

技术策划这个岗位说到底还是归属于策划，只有拥有足够深厚的游戏设计能力，才能达到对别人策划需求一看就懂，一说就通的水平。

一般来说，有多年玩法设计或关卡设计经验的策划，会站在一条更好的起跑线上。如果一位策划的设计能力不足，难免就会落下沟通费劲，或者理解力不够的问题。

作为技术策划，一定不能浮于设计理论，而要实践来检验。纸上得来终觉浅，绝知此事要躬行。

第二：逻辑能力，代码基础。这个就是对技术的要求，通俗说，要能把对需求的理解用游戏代码做出来，比如用 UE 引擎的蓝图能把完整的游戏功能或者设计原型做出来，以传达设计表现，体现技术力。

第三：数学基础。游戏制作里或多或少会涉及到一些算法、表现是需要有足够数学基础作为能力兜底。在解决一些特定的需求的时候，没有足够的数学基础，必然会让需求制作遇阻。比如如何在游戏场景里，动态判定某一个角色在另一角色的左手边还是右手边？这种问题就需要你有数学知识来解出。

“像一位手艺人”

答者：童大颜

腾讯天美L1工作室高级技术策划

随着游戏行业的发展，TD 这一岗位也慢慢地被业界认知和接受。我自己在这个岗位也做了快 7 年的时间，如果 5 年前让我来回答这个问题，我可能会觉得，逻辑表达能力，沟通能力，学习能力，适应环境能力，或者大量项目经历是这个岗位的核心竞争力。

随着岗位工作的积累，以及接触更多国内外的同行，现在让我来回答这个问题，我会认为“匠心”或者“匠人精神”是核心竞争力。我相信科学和经验可以让结果接近完美，但只有人的工艺才能突破最后的关卡。

具备匠心是手艺人精进、精通技艺、出类拔萃的最重要因素，我所在团队的制作人一直称我们做游戏的都是手艺人，我很认同这个观点，所以相信大家也就不难理解我为什么认为匠心是 TD 的核心竞争力了。

现在简单地聊下我所认知的匠人精神在工作中的一些思考。

图源 shutterstock 官网

0、择一事终一生

人的一生有两天是最重要的，一天是出生，一天是知道自己为什么要出生。当你认定了一个行业为之毕生奋斗，才能不忘初心，耐得住寂寞地将之做好。

在技术和策划经验极度欠缺的 90 年代，我们的前辈都是因为热爱选择了这个行业，抱着极强的信念和目标在做游戏，通过几代人的努力，游戏行业在国内才能够从“不务正业”变得被更多人的认可。

今天我相信有很多的同学也是因为热爱才选择游戏行业，才选择 TD 岗位，但是一时的热爱并不能解决一切问题，只有怀着终其一生的目标，才能决定你最后的高度。

1、追求极致

我认为对于 TD 来说，追求极致大体可以分为两个方面，一是生产工具上的极致，二是生产内容上的极致。

工具上的极致可以理解为在设计或者制作游戏管线工具的时候，应该不惜花费时间和精力做到最好，所谓磨刀不误砍柴工。

这是一个很简单的数学问题，管线工具的使用者人数远远大于工具的生产者人数，我们应该极致地减少使用者的使用时长，而工具生产者的生产效率是其次要考虑的事情，这样两者的总耗时才会最低。

作为 TD 需要不断地问自己管线是否已经设计到最简且易于操作，工具的内存磁盘消耗是否最优，运行是否够快。

TD 的工作也会有游戏内容的生产，也同样也需要追求极致，因为你所生产的内容会变成其他同事所参考的标杆，他们后面会按照你的思考继续进行制作，甚至粘贴复制你的东西进行加工。

只有在清楚程序实现的本质和策划设计的意图之上，才能把内容做到最好，极致简单、极致清晰、配套详尽的规范文档，以便你所制作的内容成为标准并且传承下去。

2、专注

我一直感觉能做好 TD 不是需要顶级聪明的脑袋或者强悍的技术能力，而是需要绝对的专注。

专注于你手上所研发的游戏品类，不停想办法了解同品类的游戏是用什么管线做的，用了哪些思路，哪些可以学习到自身的项目，随时学习吸收国内外先进的技术思路。

专注于同事在工作时候出现的问题，TD 是策划工作品质最好的守护者，如果你不专注于同事日常工作中出现的管线问题，不专注于帮他们及时解决问题，那么游戏的灵魂很有可能出现问题，你能想象一个画家如果每天都要操心自己的画笔怎么又坏了，今天的颜料还够不够，他能完成好自己的艺术创作吗？

往往在项目初期，一些人会觉得同样类型的游戏之间管线应该都差不多，借鉴一个成功项目的过来为我所用就好了。

我不能完全认同，TD 需要专注于自己团队中的人员情况，技术情况，项目周期等参数进行管线的搭建和优化迭代，才能达到最优解。

所以说专注于管线上的所有细节是想要做好 TD 所需要追求的，这也是很有难度的，但作为管线的设计者或者优化者，你对管线的细枝末节掌握地越少，把控优化管线的能力就会越差，团队就需要花更多的人力时间来实现原有的目标。

图源 daviddendy.com

3、客观

能够客观看待、解决问题，我认为也是重要的一部分。

为什么这么说呢，因为 TD 在工作时会和很多工种打交道，和程序、美术、策划是接触最多的，如果你作为 TD 不能从本质出发，客观处理解决问题，而是随风倒，谁强势听谁的，那么你所负责的管线设计和内容标准可能就会严重脱离正轨，极大概率导致整个团队一直在低效的管线中进行生产。

再来回答第二个问题：TD 在团队中能够起到什么样的关键作用？

这个问题我一直都会有思考，不同时期都会有不一样的心得。

初期我认识 TD 的作用就是把设计的时间还给策划，减少策划搬砖的时间占比，提高设计时间占比，做好策划和程序沟通的桥梁。

现在我想用三个词来表达 TD 在团队中起到的关键作用：“品质”，“效率”，“文化”。

品质：确保策划能够产出高品质的内容。

效率：提高管线的制作和验证效率。

文化：建立团队中的工具使用文化，靠脑力而非体力解决问题。

比较喜欢GDC2021-“Avoid an Identity Crisis as a Technical Designer”中一个对于 TD 的描述，希望 TD 都能够成为六边形战士，为国产游戏能够站在世界之巅添砖加瓦。

图源 GDC 2021

“像一个创意发动机，

而非工具人”

答者：董海阳Zero

腾讯天美J3工作室关卡主策划

技术策划这几年热度挺高，又是 Tech 又是 Designer，听起来屌屌的。很多人会把技术策划作为一个职业生涯的目标，但国内关于技术策划的能力/定位又极其模糊，更何况即使海外 AAA 公司的技术策划（Technical Designer,简称 TD）职位，所做的工作也各不相同。正好借这个问题，分享下我自己和周围几个 TD 的故事。

5年前的某个早上，正在撸玩法原型的我看到一条自己工作室的招聘信息：诚招高级技术策划，岗位要求 xxxxxxx。我一拍脑袋，闯进老板的办公室：老板，这个我行啊！你看 xxxxxxxx（省略 500 字）。

老板说了什么已经忘记了，大意是确实是在招聘，你现在做的方向也没毛病，不要在意职位的名字，继续加油哦！

后来边搞设计边陆陆续续做了一些些 AI（GAS 框架下人形射击的 AI、多足乱窜的 AI、BOSS AI）、一些些工具（随用随做，关卡模组化工具、UE4 延时摄影、3C 可视化调试工具、关卡分层管理工具），数不清的关卡内玩法和原型，各种能交互不能交互的 Cutscene 和 LevelSequence.......但再没找老板聊过 TD 这事儿，算是一个不合格的 TD，也挺快乐。

后来自己的项目和身边的项目，也都有 TD 同学加入，小进和小远的故事都很有代表性（勿对号入座）。

小进，是一个技术能力很不错的人，因此主要负责策划相关工具的开发和策划原型的实现工作，他希望能成为策划的助推器，也成为策划和程序之间的一座桥。

小进的工作要对接策划，密切沟通工具使用和新工具的制作，给策划兄弟们提供弹药。也要帮着策划把想法转化为可玩的原型，定好技术选型和方案并最终交付到程序开发。但是搞着搞着，小进有点不快乐，经常找我来喝酒。

“设计的决策权不在我，不是我出设计，最终做出来的东西我也不负责，成就感很弱……”

“工具没少做，但创意的事儿哪能量化，合作的策划说好，但周围更多人对我没感知……”

“只是单纯地接原型需求，再给客户端的程序，功能没少做，脏活苦活全做了，技术上却不如程序同学深入……”

“这次升职晋级又没过，作为一个策划很难，评审的人不懂球！”

小进猛干一杯，能看的出来搞的挺郁闷。

小远，是从程序员、独立制作人转为一个 AI 方向的 TD 策划，刚来项目时候小远更习惯在制作和技术上发力，但没有解决设计问题。后来想明白了，设计和实现两手抓，两手硬。

从游戏内的一个玩法 AI 设计着手，最终交付了一个创意、品质都很棒的 AI 系统，玩家给的体验反馈也很好。得到信任后小远再接再厉，设计了这个玩法的 AI 开发路线图（Roadmap），从一个长远设计的角度，深入挖掘了后续玩法设计。

直到现在，小远依然在负责 AI 管线的设计工作，AI 的技术路线从行为树 AI 到深度学习 AI，业务范围从单一玩法到横跨多个玩法的 10 几种不同风格 AI，AI 团队也从小远一个策划，到牵头带领 3 个策划十几位开发，成为项目最重要的团队之一，小远也成为了策划里最信赖最给力的伙伴。

一个成功的 AI 系统少不了 TD 的深度主导

这是我身边两个真实的故事，我们会发现对于所谓技术策划，不同团队、不同业务方向的 TD 工作内容差异是很大的，比如：战斗、3C、关卡、AI，不同方向对 TD 的技术能力、设计能力要求差异很大，在游戏工业化逐渐提升的今天，有越来越多的玩法设计工作要处理，对于玩法/关卡方向的策划来说，很多时候更需要某个垂直领域的专家，来解决各种深入的问题。

那么 TD 的核心竞争力到底是什么呢？是作为团队的工具开发者？是接策划需求的实现者？还是决定马尾巴的技术选型者？我的答案都不是。

Technical Designer 的能力应该更偏向设计能力，而非实现和可用性，如果一个客户端程序员能做的工作为什么要交给一个 TD 来实现呢？所有技术的手段，都应该为了推动自己的设计，更快速地验证，或者更有效地呈现。

所以我眼中的 TD，既要为设计结果负责，也要通过技术能力帮助团队达成好的设计。这些技术方向的工作可以是过程中的工具，也可以是可玩的原型，但最终的目标都是面向玩家面向用户的体验。

这里分享几个我眼中好的项目示例，这其中策划或者说所谓“技术策划”都有相当程度的参与：

1、《守望先锋》早期英雄战斗的原型，可以看出设计师已经基本上做出了最核心的玩法原型，并且验证了乐趣和独特性。

OW早期英雄的玩法原型

2、《神秘海域》关卡原型创意，从全流程的关卡桥段开始，展现了一段令人印象深刻情绪紧张的屋顶逃跑关卡。

神海中经典的关卡全流程原型

3、《战地 V》中的 AI 系统，在研发期撑起了模拟 64 人的攻防验证和性能评判工作，为最终战地的大战场对战体验，关卡设计，做出了非常好的推动工作，可以看到最终 AI 自动跑测与实际玩家的对比情况。

利用海量 AI 模拟一场攻防战斗