技术策划（Technical Designer）这个岗位真的是有必要的吗？
其实从道理上来说，游戏策划应该是具备这些能力的，这本应是作为一个游戏策划的最基本的能力，这个问题我在2017年开年（3年多前）就回答过： 因为如果游戏策划不具备一定的编程逻辑，那游戏项目几乎是做不好的。所以，如果每一个策划都有这个能力，完全不应该存在TD这个职位。所以今天的TD，其实是从“兵种”上弥补了游戏策划的缺陷。 其实我在知乎发过一篇文，是帮助回答一个问题用的，这篇文章的内容是关于一个刷怪系统的： 刷怪系统看起来不是一件大事，但是实际上很多游戏的刷怪系统却完全不合格，这很简单，因为团队里缺乏一个我这样能“跟程序谈策划，跟策划谈程序的废物”（事实上我一般不跟策划谈程序，也不会跟程序谈策划，鸡同鸭讲的事情没啥意义），所以设计不了这样的结构。 设计好游戏的数据结构好处是什么？我们不谈对于程序运行来说的重要性，那都是废话。我们就说策划这里，好的数据结构会让填表等工作更加的轻松——我见过很多公司有很多100-300列的数据表，这些表的数据还都是上万行甚至上10W行的（有人吐槽过老版本excel都打不开），这其实是数据结构建立和抽象的严重问题，这导致了策划绝大多数的工作时间和经历不在设计，而在维护表，所以别小看这件事情的重要性。 而就拿你们这代游戏人眼下最关注的东西之一——UE4的蓝图来说，蓝图本质上是一个类似excel功能的数据输入工具，但是能做出蓝图，需要的是一个好的抽象——怎样把逻辑数据化，怎样建立数据之间的关系，怎样建立依赖性都在蓝图的模块设计中（即策划在ue4的UI上拖拽的每一个用于连线的方块）。 每一个能做出项目（不说项目最后有多成功，因为项目能否成功，跟开发的关系基本不大）的团队，里面一定有至少一个人能游走于程序和策划之间游刃有余，可能是制作人、可能是主程、可能是主策。但事实上今天的招聘制度下，我们往往要求“专业人才”从而忽略了这件事情，像我这样的“综合型人才”只能失业在家，自己创办公司做游戏了。但是公司里如果没有我这样的人呢（因为本来就容不下而已）？项目就会变得不太好做，甚至多半难产，所以特地招募这个岗位，做到名正言顺。这说明什么？说明越来越多团队终于发现了这些早在上世纪任何做游戏的人就知道的道理了。到今天还不明白为什么要TD（这里仅指工作内容，而非职位），那真的只可能是你主导项目的经验太欠缺了（注意，所谓主导，是你带领团队开发出游戏，而不是以什么职位参与过项目，谁成就了谁是key）。 巧了，刚好群里发生了一个问题，恰好就是缺少TD的表现： 这个问题其实有一定原因是设计问题，策划在思考设计的时候欠缺专业性，所以问题的逻辑是有矛盾的： 之所以说这个策划没有想清楚就提出这个需求，是因为： 这种“看似没问题”的设计，往往是因为缺少一个能了解业务和开发的人辅导。